После моего предыдущего поста о выборе легкого Фреймворка я погуглил и увидел что для некоторых из них нет ни одного русскоязычного туториала. Так вот я решил написать серию постов дабы заполнить эту нишу. Я думаю стоит начать с тех на которых я в конце остановился, а так как для Silex написано уже достаточно много то этот пост будет посвящен PHPixie.

Для тех кто не читал моего сравнения фреймворков, PHPixie — маленький и по моим меркам очень быстрый фреймворк с модульной структурой, хорошо реализованным DI, отсутствием статиков и простой архитектурой.

Для начала скажу что я очень большой любитель что-то попатчить и потвикать, даже если для этого нету особой необходимости. И вот недавно рассматривая статистику XCache на своем сервере я подумал что смог бы оптимизировать объем памяти который он тратит на опкеш (opcache) файлов различных фреймворков. Сделать это просто — переписать все используя только один, файлы которого были бы общими для всех сайтов, каких у меня порядка 20-ти, но в большинстве они довольно простенькие и особого труда их переписать мне бы не предоставило. И тут я начал поиск того самого фреймворка, который в идеале имел бы достаточно фич чтобы разработка была простой, и в тоже время был легким и быстрым. Вот те которые мне понравились и мои мысли о них.

Язык PHP очень легок для изучения. Это, а так же обилие литературы «Освой _что_угодно_ за 24 часа» породило большое количество, мягко говоря, некачественного кода. Как следствие, рано или поздно любой программист, который выходит за рамки создания гостевой книги или сайта-визитки сталкивается с вопросом: «а если я здесь немножко добавлю, все остальное не ляжет?» Дать ответ на этот вопрос и на многие другие может юнит-тестирование.

В самом начале хочется оговориться — здесь речь не будет идти о TDD и методологиях разработки ПО. В данной статье я попробую показать начинающему PHP-разработчику основы использования модульного тестирования на базе фреймворка PHPUnit

Думаю, каждому программисту знаком принцип единственной ответственности, ведь не зря он существует: соблюдая его, можно написать код лучше, он будет более понятным, его будет легче дорабатывать.

Но чем больше каждый из нас работает с кодом, тем больше приходит понимание того, что на существующем уровне языка — объектно-ориентированном — этого сделать невозможно. А мешает нам в соблюдении принципа единственной ответственности такой факт, как сквозная функциональность.

Эта статья о том, как можно избавиться от дублирования сквозного кода, и как сделать его чуточку лучше с помощью АОП.

Gulp.js это потоковый сборщик проектов на JS. Он использует Stream и действительно является очень быстрым. Для примера у меня есть проект где около тысячи stylus файлов, GruntJS нужно примерно 2.5 секунды на сборку и 2 секунды на обработку autoprefixer'ом. Gulp все это делает за 0.5 секунды выигрывая у GruntJS минимум в 4 раза.



Вас может отпугнуть молодость проекта, отсутствие плагинов и небольшое сообщество. Но это не так, на данный момент ведется активная разработка проекта, написано достаточное количество плагинов под задачи для популярных инструментов. На данный момент существует 165 плагинов, посмотреть их вы можете тут.

В этой статье будет больше практики, мы соберем среду разработки фронтенда используя Jade и Stylus, запустим локальный сервер и подключим Livereload. Проект я выложил на Github, экспериментируйте.

Автовставка точек с запятой (";") — одна из наиболее спорных особенностей яваскрипта, вокруг которой скопилось много непонимания.

Некоторые программисты ставят ";" в конце каждого оператора, некоторые — только там, где строго необходимо. Большинство же где-то посередине, хотя есть и такие, которые добавляют лишние ";" из стилистических соображений.

Даже если вы всегда ставите ";" в конце каждого оператора, некоторые конструкции парсятся неочевидным образом. Вне зависимости от ваших предпочтений касательно ";", правила такого парсинга надо знать, чтобы использовать язык профессионально. Запомнив несколько простых правил, приведённых ниже, вы поймёте, как будет парситься любая программа, и станете экспертом в автовставке ";" в яваскрипте.

Когда передо мной в очередной раз встала задача об одновременной загрузке нескольких файлов на сервер (без перезагрузки страницы, само собой), я стал блуждать по интернетам в поисках довольно корявого jQuery-плагина, который позволяет имитировать ajax-загрузку файла (того самого плагина, который со скрытым фрэймом: от java- и flash- плагинов сразу было решено отказаться). В процессе поиска я вспомнил, что в грядущем стандарте html 5 возможности по работе с файлами должны быть существенно расширены, и часть этих возможностей доступна уже сейчас. В итоге было решено опробовать их в действии.

Рассматривать возможности File API будем на примере одновременной загрузки нескольких картинок на сервер. В конце статьи приводится готовое решение, оформленное в виде jQuery-плагина.

Недавно мне понадобилось в своём проекте реализовать выбор цвета, встал выбор использовать уже готовое решение или писать самому. Быстрый гуглопоиск не дал ни одной подходящей реализации. Было принято решение написать свой.

Буквально несколько часов назад на HTML5 Rocks появилась замечательная статья о текущем положении дел, касающихся загрузки скриптов на странице. Представляю вашему вниманию ее перевод. Поправки можете присылать в личные сообщения.

По мотивам этой трансляции.

Вместо предисловия скажу, что есть такой сайт yeoman.io, где собраны наиболее популярные технологии, автоматизирующие разработку фронтенда (сборку, параметризацию CSS и проч.). Обратите на него внимание в начале работы над проектом.

С ростом популярности node.js он становится всё более привлекательным для разработки приложений. По крайней мере я в последнее время очень часто использую эту технологию для быстрой разработки оных. И на данный момент, технологически нет никаких препятствий для разработки кроссплатформенных приложений на одном языке. И не только классических Web-приложений (клиент-сервер) но и десктопных.

Проблемы индейцев
Одним из остававшихся до недавнего времени недостатком Node.js, который отпугивал бекенд-разработчиков от использования Node.js, был тот факт, что непойманное исключение в потоке рушило воркера, и все клиенты, которые ждали от него ответа, не получали ничего.

tl;dr Eсть новое API для асинхронного try\catch. Из статьи можно скопипастить пример и поиграться.

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

Модули или подобные структуры это неотъемлемая часть любого взрослого языка программирования. Просто иначе никак. Модули позволяют ограничить область видимости, позволяют реиспользовать части приложения, делают приложение более структурированным, отделяют ресурсы от шума и вообще делают код нагляднее.

Вот в JavaScript своя атмосфера — в языке нет официальных модулей, более того все файлы лежат удаленно, один поток приложения. Приходится постоянно решать какие-то странные проблемы с загрузкой, хитро паковать модули в один файлы, чтобы ускорить время загрузки. Бывает, что нужно воевать с двойными стандартами, адаптировать модули другого формата.

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

На мой взгляд, директивы являются основной изюминкой декларативного стиля Angularjs. Однако, если открыть комментарии пользователей в разделе официальной документации Angularjs, посвященной директивам, то вы увидите, что самый популярный из них: «Пожалуйста, перепишите документацию, сделайте ее более доступной и структурированной. Начинающему разработчику на Angularjs сложно в ней разобраться» («Please rewrite a clearer well structured documentation of directives., this is not friendly to first time angular developers»). С этим трудно не согласится, документация пока еще сыровата и в некоторых моментах приходится прилагать большие усилия, чтобы разобраться в логике и сути функционала. Поэтому я предлагаю вам свой вольный пересказ данной главы в надежде, что кому-то это позволит сэкономить время, а так же рассчитываю на вашу поддержку и участие в комментариях. Итак, поехали!
Часть 1

После года работы с большим проектом на AngularJS, думаю поделиться некоторыми, извлеченными в процессе, уроками. Во-первых, мне нравится Ангуляр. Он отлично удовлетворяет моим потребности и, думаю, полностью перейти на него в обозримом будущем, когда мне потребуется надежный фреймворк для одностраничного «толстого клиента». Он потрясающий. Над ним работает команда мирового уровня, сообщество фантастическое, и он содержит (или предлагает сообщество) целый комбайн функций для создания веб-приложений.

Метод численного интегрирования Верле издавна использовался для вычисления траекторий частиц. Сам метод был впервые использован ещё в 1791 году французским астрономом Жаном-Батистом-Жозефом Деламбром. В 1907 норвежский математик и физик Карл Штёрмер использовал его для моделирования движения частиц в магнитном поле, поэтому иногда этот метод называют методом Штёрмера. Современное название этот алгоритм получил от имени французского физика Лу Верле, который в 1967 году использовал его в моделировании молекулярной динамики. В последнее время метод Верле применяется и в разработке компьютерных игр.

Привет, хабр!
С удивлением обнаружил отсутствие на хабре развернутой статьи о сабже, что немедленно сподвигло меня исправить эту вопиющую несправедливость.

В условиях когда клиентская часть веб-приложений становится все более толстой, бизнес-логика неумолимо переползает на клиент, а на суверенитет серверных технологий все более смело посягает node.js нельзя не задуматься о приемах проектирования архитектуры на javaScript. И в этом деле нам несомненно должны помочь паттерны проектирования — шаблонные приемы решения часто встречающихся задач. Паттерны помогают построить архитектуру, которая потребует от вас наименьших усилий при необходимости внести изменения. Но не стоит воспринимать их как панацею, т.е., грубо говоря, если качество кода «не фонтан», он кишит хардкодом и жесткой связью между логически независимыми модулями, то никакие паттерны его не спасут. Но если стоит задача спроектировать масштабируемую архитектуру, то паттерны могут стать хорошим подспорьем.
Но впрочем эта статья не о паттернах проектирования как таковых, а о их применении в javaScript. В первой части этой статьи я напишу о применении порождающих паттернах.

Для начала, ликбез и несколько фактов:

• ECMAScript — это официальный стандарт языка JavaScript (Слово JavaScript не могло быть использовано, потому что слово Java являлось торговой маркой компании Sun) Т.е. JavaScript — это имплементация стандарта ECMAScript.
• TC39 — комитет, развивающий стандарт ECMAScript и принимающий решения по включению фич в него.
• ECMAScript стандартов много. Самый популярный из них — ECMA-262.
• ECMAScript 5 — последняя редакция стандарта ECMA-262 (утвержден в 2009 году).
• Предыдущие версии стандарта ECMA-262 были (совсем старые не упоминаю):
  
  • ECMAScript 3 — поддерживается большинством браузеров (утвержден в 1999 году).
  • ECMAScript 4 — не принят в виду слишком радикальных изменений в стандарте. Позднее в июле 2008 году в урезанном варианте (но все же намного богаче, чем ECMAScript 3) вылился в новый проект ECMAScript Harmony.
  
  
• ECMAScript 6 (кодовое имя ECMAScript.next) должен утвердиться до конца 2013 года.

Итак, что же нас ждет в новой версии JavaScript?

Все jQuery UI виджеты создаются на простой основе — Фабрике Виджетов. Она обеспечивает гибкую основу для создания сложных, структурированных плагинов с совместимым API. С её помощью можно создавать не только плагины jQuery UI, но и любые объектно-ориентированные компоненты, не изобретая велосипедов. Она не зависит от других компонентов jQuery UI, наоборот, большая часть компонентов UI зависит от неё.

Что это?

Фабрика виджетов это метод глобального объекта jQuery —

TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.

У JavaScript очень удивительная судьба. Он преодолел путь от самого не понимаемого до самого удивительного языка. У него было тяжелое детство:
Изначально Автор хотел написать функциональный язык. Но менеджеры хотели получить, «обычный» объектно-ориентированный. И чтобы было легко искать разработчиков для новоиспеченного языка синтаксис решили сделать похожим на Java и даже название сделали похожим.
Но на этом история не заканчивается. Java, JavaScript это торговые марки Sun (а теперь Oracle). Microsoft не мог воспользоваться именем JavaScript (Netcape и Sun дружили против Microsoft). В результате Microsoft решил сделать реверс инжиниринг JavaScript и назвал его JScript. Сделали реверс инжиниринг, и сделали его настолько хорошо, что даже содрали все баги в реализации. Позже решили сделать стандарт и назвали его ECMAScript.