PHP *

Преамбула:

SOAP — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался, в основном, для реализации удалённого вызова процедур (RPC), а название было аббревиатурой: Simple Object Access Protocol — простой протокол доступа к объектам. Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

Итак, делаем proxy-class

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

А надо-то, на самом деле, почти всегда совсем немного.

Под катом — пара полезных, на мой взгляд, советов для начинающих программистов.

Навеяно постом http://habrahabr.ru/blogs/python/59236/.
Почитав вышеуказанный пост, предположил, что не каждый сможет использовать домашний комп для таких целей (например потому, что он включен не постоянно). Но зато многие из нас имеют php-хостинг, который так же поддерживает cron. Для разминки написал данный скрипт.

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

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

Может быть, то, о чем я собираюсь рассказать, уже всем известно, а может, и нет.

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

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

Изучив синтаксис конструкции 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%, так же не учитываются жесткие модификации (повороты, инверсия, обрезка) – для этого нужно доводить и доводить. Лично для меня самым главным оказались два параметра: скорость, независимость от разрешения изображения и возможность сравнивать «изображения» прямо в базе данных.