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

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

Каждый предстоящий доклад возможно обсудить на форуме ZF-сообщества. Ваше мнение очень важно для авторов.

Планируемые доклады:

• Жизненный цикл предложений (proposals) в проекте Zend Framework
  Александр Веремьев (Zend Technologies, Zend Framework Core команда)
• Zend_Search_Lucene в деталях
  Александр Веремьев (Zend Technologies, Zend Framework Core команда)
• Zend Framework и производительность
  Александр Махомет (создатель сообщества ZendFramework.ru)
• Zend Framework и MVC, «толстая» модель
  Александр Стешенко (Norada Corporation, PHP-разработчик)
• ФотоСтрана.ru: Прототипирование с использованием ZF (история боевого применения Zend Framework в highload-проекте)
  Леонид Жаворонков (ФотоСтрана.ru, тимлид)
• Использование очередей сообщений в повседневных проектах
  Денис Баклыков (Обновление, веб-разработчик)
• Zend Framework и Doctrine
  Степан Танасийчук (руководитель веб-студии stfalcon.com)
• Zend Framework и мультиязычность
  Степан Танасийчук (руководитель веб-студии stfalcon.com)
• История проекта e-Штаб
  Анатолий Ларин (e-Легион, веб-программист)
• Что нового несет нам Zend Framework 2.0?
  Надежда Блинова (Wizartech, веб-программист), Георгий Туревич (Wizartech, ведущий веб-программист)
• Интеграция Zend Framework c Javascript-фрэймворками jQuery и Dojo Toolkit
  Георгий Туревич (Wizartech, ведущий веб-программист)

Смело обсуждайте доклады и регистрируйтесь!

За последними новостями можно следить здесь:

• RSS-канал: http://feeds.feedburner.com/zfconf
• Twitter: @zfconf
• Группа Вконтакте: http://vkontakte.ru/club14951507

К участию приглашаются информационные и финансовые спонсоры.

Упомянутая инструкция представляет собой двухстраничный перечень операций, последовательность которых местами может показаться довольно неочевидной. Кроме того, объем и рутинность такой работы удручает на фоне относительной простоты процесса запуска скриптов на базе других распространенных языков и фреймворков.

Недавний релиз многообещающего модуля mod_rails для Apache, разработанного Нидерландской компанией Phusion, был довольно предсказуем. Основное его предназначение — автоматизация скучного процесса внедрения RoR-приложений на веб-сервере. Попросту говоря, теперь для запуска понадобится просто загрузить файлы. И все будет работать. На мой взгляд, даже странно, почему такая востребованная возможность появилась настолько нескоро, при условии всенародного признания Ruby и Rails.

Официальном сайт mod_rails чем-то похож на подарочную упаковку

mod_rails довольно неплохо документирован. На полное ознакомление с инструкцией хватит минут 20-40: первичная настройка модуля действительно довольно проста, а развертывание Rails-приложений по сути представляет простое добавление новых виртуальных хосто в конфиге Apache.

На сайте можно посмотреть скринкаст, в котором вкратце объясняется, как установить модуль на примере OS X. Есть так же верcии для Linux и FreeBSD. Что же касается Windows…

Passenger works on any POSIX-compliant operating system. In other words: practically any operating system on earth, except Microsoft Windows.

Это значит, желающие локально отлаживать скрипты под этой ОС будут вынуждены громоздить какую-нибудь Убунту на каком-нибудь VMWare, что не есть хорошо и правильно. Учитывая, что сам Ruby, да и Apache прекрасно дышат под Windows, отсутствие порта mod_rails выглядит недочетом. А перспектива его появления пока выглядит туманной (приведенная выше цитата — это вообще единственное упоминание слова Windows на всем сайте :). Google со своим App Engine такого не допустил.

Ссылки на тему

• Некоторые дополнительные интересные сведения, в частности, ответ на вопрос, почему mod_rails называется именно mod_rails, а не mod_ruby, и сравнительный график производительности этого модуля и традиционного Mongrel (у mod_rails — длиннее).
• Блог с новостями проекта.
• Подробный отчет об установке mod_rails на Ubuntu 7.10 на блоге Rails Garden.

Даже странно, что в официальной документации не сделали графического представления.

(клик ту зум)

Уже четвертый пост подряд про WordPress. Надо что-то менять.

Проще говоря, теперь любой желающий сможет в своих проектах пользоваться распределенной базой данных Google, системой авторизации Google Accounts и другими элементами их инфраструктуры. Работающие на базе App Engine приложения смогут без труда выдерживать такую нагрузку, которую вне Google возможно было бы получить только за довольно немалые деньги. А именно, по усредненной оценке, выделенных ресурсов должно быть достаточно на 5 миллионов загрузок страниц в месяц (ограничение дискового пространства — 500 Мб, а трафика — 10 Gb в сутки).

App Engine находится еще на стадии разработки и то, что доступно сечас, — это демонстрационная версия. На официальном сайте можно скачать SDK и зарегистрировать себе аккаунт для публикации в сети своих приложений.

SDK представляет собой работающий локально веб-сервер, на котором эмулируется среда App Engine (кстати, все написано на Python). Приложения, разработанные и отлаженные в этой среде, можно без каких-либо изменений переносить на «настоящие» сервера Google. Кстати, дистрибутив SDK занимает всего 2.5 Мб. Правда, в комплект поставки обязательно должен входить Python 2.5, который весит еще 12.

Стоит отметить, что по заявлению разработчиков, GAE не будет жестко связан с конкретным языком программирования. Первым поддерживаемым языком стал Python (2.5, естесственно). Выбор следующего языка будет основан на мнении потенциальных пользователей. Мне самому кажется, что следующим будет либо Java, либо Ruby.

В докладе на Campfire несколько раз подчеркнули, что поддержка Python — полная, включающая все сторонние библиотеки и любые фреймворки. Можно использовать Django, CherryPy, Pylons и web.py. Любимый многими Django даже включен в комплект SDK и используется в демонстрационном примере, при создании гостевой книги.

Особый интерес представляет собой административная панель Apps Engine.
С ее помощью можно мониторить работу приложений и управлять версиями. Панель демонстрировали в том же докладе, но попробовать вживую пока не получилось (как я уже говорил, аккаунт мне еще не открыли).

В заключении, еще одна деталь: к проектам, работающим на Apps Engine, можно будет привязывать собственные доменные имена, либо беплатно размещать их на субдоменах appspot.com.

Анонс Google App Engine на Campfire (7/04/2008)

Ссылки по теме

• Официальный сайт Google Apps Engine.
• Страница загрузки SDK.
• Описание установки и пример использования основных средств SDK для написания простого приложения.
• Python — страница скачивания.

Как известно, задачей любого парсера темплейтов является полумифическое отделение кода (и данных) от оформления страниц. Я говорю полумифического, т.к. в действительности ни один развитый шаблонизатор не может похвастаться реализованной в полной мере такой возможностью. Когда требования к функциональности шаблонов возрастают, их синтаксис усложняется, постепенно перерастая в специализированный язык. Показательный пример тому — Smarty и многие другие распространенные движки темплейтов. Строго говоря, сам PHP можно отнести к категории очень навороченного генератора страниц.

В итоге, одним из основных критериев при выборе шаблонизатора становится не качество (или степень) отделения кода от оформления, а скорее читаемость этого кода — достаточно субъективная характеристика, которая сильно зависит не только от шаблонизатора, но и от стиля кодинга. Показательный пример: XSLT является одним из наиболее идеологически-грамотных шаблонизаторов, тем не менее он сейчас пользуется не самой большой популярностью. Одна из причин тому — очень навороченный синтаксис.

В контексте сказанного выше, мне понравилась идеология, заложенная в синтаксис Blitz. цитата из официального источника:

Blitz не поддерживает по принципиальным соображениям сложные выражения:

{{if(if($foo, 0, 1), ’bar’, ’foobar’)}}

Данный код работать не будет. Не надо превращать код в спагетти.

И это очень правильный подход. Гибкие возможности строить сложные синтаксические конструкции — не всегда хорошо. Часто это служит причиной возникновения настолько запутанного кода, что в него не то что сторонний разработкич побоится залезть, но и сам автор, через пару месяцев после написания, предпочтет полную переработку корректировке деталей.

Упрощение синтаксиса хорошо еще и потому, что у кода шаблонов есть своя специфика: зачастую в темплейтах осознанно не делают форматирования (чтобы не портить форматирование генерируемого HTML и/или не утяжелять его излишним количеством пробельных символов), кроме того в текстовых редакторах обычно нет синтаксической подсветки кода темплейтов, которая облегчила бы работу (исключения — XSLT и, опять же, PHP).

Возвращаясь к вопросу производительности: Blitz работает быстрее, чем шаблоны, собираемые из отдельных PHP файлов (include-ами), но, по понятным причинам, медленее сплошного PHP кода. Учитывая, что нежелание использовать темплейтов на базе PHP — одна из самых важных причин использования сторонних шаблонизаторов вообще, можно считать, что Blitz фактически является лидером по скорости среди других систем своего класса.

Отдельно стоит упомянуть процесс тестирования, точнее обстоятельный подход, с котором он выполнен и описан на сайте разработчика. Неоднократно видел, как производительность шаблонизаторов, фреймворков и CMS измеряют на примерах уровня сложности «Hello world», а потом кричат «Сенсация! PHP работает быстрее кода на C++!». Что касается Blitz — тесты проводились в условиях, близких к боевым, и полностью обоснованы.

Вывод: на Blitz стоит обратить пристальное внимание при проектировании высокопроизводительных CMS для сайтов, работающих на выделенных серверах. В тех случаях, когда серьезных требований к производительности нет, его использование, к сожалению, будет не всегда оправдано экономически (пользовательские модули PHP — вещь не для shared хостинга).

Ссылки по теме

• Blitz Templates — официальная страница разработки с описанием синтаксиса и результатами сравнительных тестов.
• Другие шаблонизаторы: Smarty, Template Lite (облегченная и более быстрая версия Smarty), PEAR::HTML_Template_* (средства PEAR для генерации страниц по шаблонам).