<rmcreative>

Как вы могли заметить, в меню появилась новая кнопочка "English Pages". На английский переведена статья о создании красивых адресов на сайте.

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

Для php сред разработки, как оказалось, написано довольно много (особенно если включить в их список "продвинутые блокноты"). И как у всех продуктов у многих из них имеется огромная куча недостатков. Итак, что же выбрать?

Как и многие другие программисты, я сначала боялся навороченных IDE, поэтому присматривался только к блокнотам с подсветкой кода. Для маленьких проектов больше и не надо было.

Так однажды я наткнулся на PSPad - "продвинутый блокнот", который до сих пор используется мной, когда надо что-то быстро подправить или нет под рукой более подходящего инструмента. На PSPad я сидел очень долго. Не знаю уж, чем он мне приглянулся... вроде нет некоторых возможностей как в scite или notepad++, работает тоже не сказать, чтобы быстрее. Но что-то всё-таки в нём есть.

Из основных его плюсов стоит отметить: мультитабность, настраиваемую подсветку всего, чего только душа пожелает, инспектор кода, дополнение функций php. Из минусов... отсутствие Code Folding. Конечно, можно и ещё минусов отыскать, но это же всё-таки не IDE, так что не будем ;)

В принципе можно было и дальше писать код в PSPad. Но после того, как поработал с Java в удобных IDE JDeveloper и Eclipse захотелось того же для php, а именно нормального автодополнения, возможности отладки и проверки кода на лету.

Всё это нашлось в самой полной и продвинутой среде Zend ZDE.

Правда, просидел я на ней совсем недолго. Доставала скорость её работы. Тормозила не на шутку. И это на Athlon 2000+ c 512 DDR оперативной памяти... ужас, в общем.

Конечно, есть у данной среды и неоспоримые преимущества. Она полностью направлена на разработку php приложений и имеет, пожалуй, самый полный и продуманный механизм автодополнения, отладчик и проверку кода на лету.

Но, к сожалению, тормознутость и коммерционализированность не дают как следует всем этим насладится.

Через неделю сменяющих друг-друга восхищения возможностями и негодования по поводу тормозов, ZDE был снесён. Вернулся к PSPadу. Радовался отсутствию тормозов, но тайно мечтал об автодополнении и проверке на лету.

И тут произошло чудо. Как-то работая с Java в Eclipse я заглянул в настройки и увидел список подключенных плагинов. Ага... есть поддержка плагинов... а нет ли плагина под php? Полез в google и... нашел!

Со скептическим настроением выкачав плагин установил как написано в readme, перезапустил Eclipse и офигел...

По возможностям может потягаться с ZDE, была моя первая мысль. После дня работы я был полностью убеждён, что плагин лучше ZDE.

Первое и самое огромное преимущество PHPEclipse (да-да, именно так он и называется) - всё довольно быстро работает. Дискомфорта никакого.

Второе, что бросилось в глаза - приятные цвета и шрифты, да плюс ещё хорошая подсветка синтаксиса. Так как я работаю с Smarty, то ещё очень порадовала подсветка его шаблонов.

Как и в основном Eclipse для Java в PHPEclipse имеется Code Folding (сворачивание блока кода в одну строчку... чтобы не мешался). Мелочь, а приятно.

Как не странно в PHPEclipse есть и автодополнение функций php, переменных в пределах файла, автодополнение методов и полей всех подключенных классов.

Ну, для полной картины имеется замечательная проверка на лету, автоматическая расстановка отступов, закрытие скобок, кавычек. Имеется возможность отладки.

Прибавим сюда полную бесплатность как самого Eclipse, так и PHPEclipse и полную кроссплатформенность...

За последние три-четыре месяца у меня полностью отпало желание даже пробовать другие среды разработки. В PHPEclipse всё удобно и хорошо. Может, конечно, есть что-то лучше, но я пока не встречал...

Дополнение от 25 декабря 2006

Встретил... Действительно нашёлся IDE лучше PHPEclipse... Тоже созданный на базе Eclipse, тоже бесплатный и очень похожий: PHP IDE.

Преимущества перед PHPEclipse:

• Меньше размер дистрибутива.

• Более правильное и удобное дополнение кода.

• Встроенный дебаггер от Zend.

• Постоянное развитие проекта.

Недостатков пока не выявлено...

Дополнение от 27 декабря 2006

Вот и первый недостаток: PHPIDE упорно не хочет работать с чем-либо не в кодировке utf-8. Даже если в проекте выставить cp1251, упорно старается сохранять в unicode.

Выводы:

Для небольших проектов вполне сгодится PSPad или другие "продвинутые блокноты". Как только дело доходит до крупных проектов - лучше перейти на PHP IDE или PHPEclipse, если не хочется работать с unicode.

p.s. возможно кому-то поможет справится с проблемами при переходе на utf-8 статья "My SQL 4.1+ и любые проблемы с русскими буквами" .

Сегодня был обновлён класс INI, позволяющий работать с INI-файлами. Были добавлены новые методы для более удобной работы.

Типичная команда веб-разработчиков обычно состоит из программистов, дизайнеров и верстальщиков. Как им ужиться вместе? Ведь программист ничего не понимает в дизайне, а дизайнер (да и верстальщик чаще всего тоже) не очень хорошо представляет себе, что такое программирование.

Очевидно, необходимо распределить роли в проекте: дизайнеру - дизайн, верстальщику - вёрстка, программисту - код. Но не всё так просто. Ведь надо ещё и собрать все в единый рабочий продукт...

Чтобы упростить жизнь всем участникам проекта были придуманы системы шаблонов. С их помощью можно добиться полного (ну или почти полного) разделения труда.

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

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

Если не вдаваться в подробности, то простейшая шаблонная система работает примерно так:

1. Программист получил данные, отдал их шаблонной системе.

2. Шаблонная система нашла и загрузила соответствующий данным шаблон.

3. Шаблонная система подставила данные в шаблон и отдала полученный документ пользователю.

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

Если же было решено сменить ассортимент товара или, например, перенести базу данных на другой сервер - всем займётся программист. И при этом он ни разу не заглянет в код шаблонов. Они останутся прежними.

Итак, главное назначение шаблонов - отделить данные от их визуального представления.

Шаблоны приятно использовать даже в маленьких проектах, но истинную их пользу можно почувствовать лишь в средних и крупных проектах.

Среди огромного количества шаблонных систем можно выделить две группы:

1. Системы, призванные полностью отделить оформление от программирования.

2. Системы, призванные отделить бизнес логику (работу с данными) от логики визуального представления.

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

Во втором случае верстальщику даётся больше свободы. Теперь он самостоятельно может, например, обрезать строку текста до заданной величины, чтобы она не растягивала дизайн, представить переданный программистом массив данных в виде таблицы, текста, диаграммы. В этом случае верстальщику приходится изучить синтаксис шаблонов. Это конечно минус, но небольшой: обычно язык шаблонов не такой уж и сложный и состоит из 10-20 конструкций и правил.

Какого же направления придерживаться? Вопрос кажется не таким уж простым, но ответ не так уж и сложен:

В зависимости от ситуации.

Если верстальщик одновременно является дизайнером и ровным счётом ничего не понимает в программировании (а главное - не желает понимать), ему невозможно объяснить что такое массив, цикл и т.д. - используем первый вариант. Не показываем верстальщику код, объясняем, что если написать "такой специальный тэг", то вместо него будут наши данные. Верстальщик останется доволен. А вот программисту придётся попотеть - передать всё в удобном для верстальщика виде.

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

Если же ваш верстальщик не лентяй и может учиться - ваш выбор - второй вариант. Дадим верстальщику полное описание "как оформлять шаблон" и через два дня он будет знать всё, что необходимо. Теперь хорошо будет всем. Верстальщику не надо будет бегать к программисту, и просить: "а нельзя переименовать вот этот специальный тэг?". Программист не будет расходовать своё время на удобное для верстальщика представление данных: гораздо проще передать в шаблон объект и рассказать верстальщику, как получить то или иное поле.

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

Выводы:

Шаблоны использовать определённо стоит. Они являются гибким и элегантным решением для разделения данных и их визуального представления.

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

p.s. конкретные шаблонные системы, возможно, будут рассмотрены позже, а пока отмечу двух лучших, на мой взгляд, представителей выделенных групп шаблонных систем для PHP:

KTemplate призван полностью отделить оформление от программирования.

Smarty призван отделить бизнес логику от логики визуального представления.

Всем фанатам Опреры на радость вышла финальная версия 9.0. Она представляет собой то же, что и бета билд 8501.

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

Заходим, смотрим, качаем.

Утилита умеет менять разрешение экрана, цветность, частоту обновления экрана. Недопустимые режимы не выставляются. Имеется возможность откатата к предыдущему состоянию.

Загрузить

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

Параметры командной строки:

Изменение разрешения:

res.exe   [bpp] [refresh rate]

Восстановление исходного разрешения:

res.exe -restore

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

Вот к чему стоит присмотреться:

Web Developer для Firefox

IE Developer Toolbar

Opera Developer Tools

Добавил проверку полей в гостевой книге. Осуществляется она с помощью Java Script. С помощью него же сделал наконец сохранение полей вроде имени, icq и др.

...зря я раньше думал, что JS легко заменить при помощи PHP...

Выкладываю ещё работ. Все разных периодов.

p.s. свинку закончил сегодня ;)

Как и обещал - обновление модификатора.

Выкинуто немного ненужного кода, окончателно (надеюсь) поправлено отображение тэгов HTML.