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

Изучив синтаксис конструкции try{...}catch(Exception $e){...}, узнав о возможности создавать собственные классы исключений, наследуя их от класса Exception и поверхностно осознав мощь оказавшегося в ваших руках механизма, дальше вы можете пойти по одному из двух путей:

• Начать тут же использовать исключения. Скажем, прикручивать их к системе, в которой они никогда не использовались. Или приколачивать их к проекту, в котором ООП и не пахнет. Или, что самое ужасное, пытаться использовать их повсеместно, особенно там, где это не нужно.
• Попытаться понять, где их применять, как делать это правильно, и зачем они нужны.

Если PHP-функции preg_match в качестве исходной строки передать строку состоящую из 100000 (ста тысяч) или более силволов, то она вернёт неверный результат. Точнее результатом в этом случае всегда будет false.

Проверяется очень просто.

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

Основы будущего: размышления о прорывах на конференции по искусственному интеллекту ICML 2008

Июль месяц, прохладный Хельсинки, на 25-й Международной конференции по машинному обучению (ICML 2008) было жарко. Ощущение — как будто новое будущее на пороге и осталось совсем немного.

Докладов вместе с письменными работами было более 500, но расскажу только о двух из них. Если и, правда, это сбудется, то всё, о чём пишут авторы, перевернёт наше понимание того, что такое интеллект, ра, и как машины смогут учиться, видеть и думать “самостоятельно” — а это, поверьте, совсем не за горами.

Итак, в новой версии PHP появилась интересный концепт — «horizontal inheritance» (горизонтальное наследование), который был добавлен в язык с помощью конструкции «namespace». Это позволяет объединять функциональность из нескольких классов без наследования их от одного класса-родителя. Вместо этого, теперь можно объединять методы и свойства из разных классов в одном классе через использование пространства имен.

Memcached community предприняло немало попыток написать «родные» патчи для кода memcached, добавляющие в него поддержку тэгов. Наиболее известный из таких патчей — проект memcached-tag. К сожалению, memcached-tag все еще очень далек от стабильной версии: нетрудно написать скрипт, приводящий к зависанию пропатченного memcached-сервера. Похоже, на момент написания данной статьи не существует ни одного надежного решения проблемы тэгирования на уровне самого memcached-сервера.

Библиотека Dklab_Cache

Dklab_Cache — это (в основном) библиотека поддержки тэгирования ключей для memcached, использующая интерфейсы Zend Framework. Сама библиотека написана на чистом PHP. Вот полный список возможностей библиотеки:

• Backend_TagEmuWrapper: тэги для memcached и любых других backend-систем кэширования Zend Framework;
• Backend_NamespaceWrapper: поддержка пространств имен для memcached и др.;
• Backend_Profiler: подсчет статистики по использованию memcached и др. backend-ов;
• Frontend_Slot, Frontent_Tag: каркас для высокоуровневого построения систем кэшиирования в сложных проектах.

Собственно, для поддержки тэгов имеется класс TagEmuWrapper. Он представляет собой декоратор («обертку») для backend-классов кэширования Zend Framework. Другими словами, вы можете с его помощью «прозрачно» добавить поддержку тэгов в любую подсистему кэширования Zend Framework. Мы будем рассматривать backend для работы с memcached: Zend_Cache_Backend_Memcached, но, если в вашем проекте используется какой-то другой backend-класс, вы можете подключить тэгирование и к нему без каких-либо особенностей.

TagEmuWrapper реализует стандартный backend-интерфейс Zend_Cache_Backend_Interface, поэтому с точки зрения вызывающей системы он сам является кэш-backend'ом. Вообще, Zend Framework хорош тем, что на уровне интерфейса он поддерживает тэги с самого начала! Например, в методе save() уже имеется параметр, позволяющий снабдить ключ тэгами. Однако ни один из backend-ов в составе Zend Framework тэги не поддерживает: попытка добавить тэг к некоторому ключу вызывает исключение (в частности, для Zend_Cache_Backend_Memcached).

Технические подробности, документацию, а также примеры использования можно посмотреть тут: dklab.ru/lib/Dklab_Cache

Что такое тэги?

Работа с типичной кэширующей системой (в том числе с memcached) заключается в выполнении трех основных операций:

• save($data, $id, $lifetime): сохранить данные $data в ячейке кэша с ключом $id. Можно указать «время жизни» ключа $lifetime; спустя это время данные в кэше «протухнут» и удалятся.
• load($id): загрузить данные из ячейки с ключом $id. Если данные недоступны, возвращается false.
• remove($id): очистить ячейку кэша с ключом $id.

Итак в феврале этого года была выпущена новая стабильная версия PHP — PHP 5.3.0. Эта версия включает множество новых функций и улучшений, в том числе:

Задача:
Использовать класс, в который можно добавлять новые методы воздействия, чтобы в последующем можно было ими пользоваться. При этом отделить эти методы по разным файлам.
Представим космический корабль, в котором используются:
a) методы перемещения по пространству, связанные с двигателем
б) методы зарядки энергии, связанные с его солнечными батареями
в) итд

Есть варианты:
1) Создание в объекте переменных и инициализация их через __construct, как новые классы.
Но, при создании каждого нового объекта — мы получаем снижение производительности и постоянную модификацию класса (что может осложнять работу нескольких программистов).
2) Работа через функции __call, __get, __set.
В 3-10 раз более медленная работа этих функций. Особенно при вызове call_user_func_array с параметрами.

Я предлагаю свой вариант.
Быстрый, оптимизированный, но при этом есть небольшая сложность в отладке.

В этом хабратопике я затрону темы:
1. Overloading
2. Ускорение загрузки модулей. Объединение модулей.
3. Оптимизация

«Студент-второкурсник старшей школы Бретт Тайсон был отстранен от занятий, после того как учитель узнал, что Тайсон вероятно употребляет PHP.»

Понадобилось мне тут вдруг для одной прикладной задачи генерировать PNG-шки на PHP, чтобы затем их можно было вставлять в документы и распечатывать. Но вот проблема, никак с помощью GD в PHP при сохранении нельзя задать разрешение в dpi, а ведь это очень важно при печати. С ImageMagick мне связываться не хотелось, поэтому я быстренько нагуглил PNG (Portable Network Graphics) Specification и написал вот такой код:

Никогда мне не нравился дебагер для Смарти: огромные полотна массивов, невозможность посмотреть длинный текст, не отображении отладки для объектов — эти недостатки были исправлен в шаблонизаторе Quicky, но до сих пор многие пользуются Smarty (и у меня часть проектов), поэтому сел я как-то и написал нормальный дебагер для смарти тоже — всем кому нужно пользуйтесь, комментируйте

Отличия:
— древовидное раскрытие массивов
— дебаг объектов
— возможность посмотреть всю текстовую переменную

скачать побаловаться|посмотреть|попробовать|полюбить здесь:
pagin.ru/download/smarty_debug.zip

UPD: минусовщики вы хоть обоснуйте за что минусуете, а то не красиво так

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

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

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

Встала проблема загрузки заранее посчитанных данных в программу поиска пути между двумя точками (не важно какую). Проблема встала настолько сильно, что загрузка просчитанных данных стала занимать 90% всех последующих расчётов.
Мои данные — двухмерный массив, состоящий из 200 на 200 ячеек примерно.

Тестирую unserialize, json_decode

с буквенными ключами
json_decode — 0.080sec
unserialize — 0.072sec

только цифровые ключи
json_decode — 0.041 sec (170kb)
unserialize — 0.037 sec (500kb)

Сам маршрут ищется за 0.0004-0.0012 sec :)
Значит, надо ещё что-нибудь придумать.

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

Речь пойдет о том, как можно использовать переменные окружения, описанные в файле ~/.bash_profile в программах на PHP, и о том, как сопоставить каталог пользователя ОС с URL из серверного PHP процесса, для того чтобы интерпретатор PHP подключал классы именно из этого каталога. Все это нужно для того чтобы рабочая версия проекта лежала в домашней директории одного пользователя, а тестовые версии — в домашних директориях других пользователей.

Алгоритм возможно не новый, и не является идеалом, но, на удивление, работает. Никаких графов и корелляции.

Для начала, стоит отметить, что сравнение очень приблизительно (по крайней мере, на данном этапе), временами две совершенно разные фотографии оказываются похожими процентов на 60%, так же не учитываются жесткие модификации (повороты, инверсия, обрезка) – для этого нужно доводить и доводить. Лично для меня самым главным оказались два параметра: скорость, независимость от разрешения изображения и возможность сравнивать «изображения» прямо в базе данных.

Очень простая, но полезная библиотека PHP_Exceptionizer позволяет преобразовывать нотисы (E_NOTICE), предупреждения (E_WARNING) и т. д. в исключения PHP.

// Где-то в начальном коде инициализации скрипта.
error_reporting(E_ALL);
if (<is debug mode active>) {
    $exceptionizer = new PHP_Exceptionizer(E_ALL);
    // И оставьте эту переменную, чтобы она не удалялась до окончания 
    // скрипта. Удаление переменной вызовет отключение PHP_Exceptionizer.
}
...
// Далее можно ловить нотисы как исключения:
try {
    echo $undefinedVariable;
} catch (E_NOTICE $e) {
    echo "Notice raised: " . $e->getMessage();
}
...
// Если вы ловите E_WARNING, то поймаете и E_NOTICE тоже:
try {
    echo $undefinedVariable;
} catch (E_WARNING $e) {
    echo "Warning or better raised: " . $e->getMessage();
}
...
// А можно и не ловить, тогда нотис вызовет завершение программы.
echo $undefinedVariable;

 

Доброго времени суток,

Хочу рассказать о своём шаблонизаторе для проектов на PHP.
Понимаю, что рискую быть обвинённым в изобретении велосипеда, поэтому объясню свои мотивы: Большинство шаблонизаторов меня не устраивают изначально, среди них Smarty, Quicky и все им подобные, причина — мне кажется, что шаблонизатор должен избавлять от использования логики в шаблонах, а не навязывать свой синтаксис для той же логики.
Иначе говоря, такой:

1. {?$x = 2+2}

, или такой

1. {foreach name=my from=array('One','Two','Three') key="i" item="text"}

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

1. $tpl->assigned_var='abc';

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

1. $thl->assign('assigned_var','abc');

Не смотря на то, что я в последнее время программирую на .NET, недавно мне пришлось работать над небольшим проектом на PHP. В связи с этим я занялся поиском удобной, но в тоже время, бесплатной IDE. Конечно, я знаком с Eclipse и PHP Development Tools for Eclipse, но все же хотелось узнать, а есть ли другие бесплатные программы с приличным функционалом. В результате, я вспомнил о NetBeans.