<rmcreative>

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

Особенно заслуживают внимания статья «Полосатая таблица».

p.s. Кстати, единственная и неповторимая книга по регуляркам — это:

Дж. Фридл. Регулярные выражения. Второе издание

CПб: Питер, 2003, 464 с.

Must have!

Обновлён класс для работы с INI-файлами.

Добавлен вывод предупреждений об отсутствии переменных и секций при их чтении.

Сегодня включил на сервере GZip-сжатие страничек. Будем экономить трафик и время загрузки.

p.s. данная возможность есть у многих хостеров. При этом экономия примерно такая же, как от сжатия в zip, т.е. около 70%!

Все современные браузеры, включая Internet Explorer замечательно реагируют на сжатые странички.

Для активации данной возможности создаём в корне сайта файл .htaccess(если его ещё нет) и дописываем в него следующую строчку:

php_flag zlib.output_compression On

Из Википедии:

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

Что сделает злоумышленник, который не найдёт на сайте ни одного скрипта? Кроме как сдаться ничего и не останется...

Итак, как же это всё реализовать?

Первое, что нам понадобится - обработчик ошибок. Напишем его на php.

//Файл error.php
 
  //Посылаем правильный заголовок
  header('HTTP/1.0 404 Not Found');
  //Выводим информацию для пользователя
  print('Ошибка, страница не найдена.');

В htaccess добавим:

[apache]

  ErrorDocument 404 error.php

Теперь добавляем ко всем нашим скриптам входной get параметр mode и если он не указан или неправильно указан - запускаем наш обработчик ошибок для выдачи ошибки 404. Если же всё указано правильно - выполняем скрипт.

//Файл index.php
 
//Если передан параметр и подходящее значение
if(isset($_GET['mode']) && $_GET['mode']=='display'){
    //Выполняем скрипт
    print('Результат работы скрипта');
}
else{
    //Иначе прикидываемся отсутствующим
    include('error.php');
}

Таким образом, если в адресной строке наберём

http://www.oursite.ru/index.php

получим ошибку об отсутствии такого файла на сервере.

Для обращения к скрипту используем

http://www.oursite.ru/index.php?mode=display

Далее делаем красивые, но неудобные для злоумышленника URL, как описано в моей статье "Красивые адреса на сайте".

Если вкратце, это делается это путём вписывания в htaccess

[apache]

RewriteEngine On 
RewriteRule display/? index.php?mode=display

Теперь наш скрипт доступен как

http://www.oursite.ru/display/

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

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

Делается это так:

[apache]

RewriteEngine On 
RewriteRule config/?.* error.php
RewriteRule password.txt error.php

Вот в принципе и всё. Надеюсь, статья поможет вам в защите ваших сайтов.

p.s. используйте стеганографию, но не забывайте и о защите.

Сегодня забрёл на интересный ресурс по php - PHP Developer's Journal.

Да, и в жж бывают нормальные люди...

Как вы могли заметить, в меню появилась новая кнопочка "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.

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

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