PHP *

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

Итак вы узнаете:

• Базовую информацию о том, что такое автодокументация и как она делается в PHP
• Настройка генератора документации phpDocumentor в NetBeans 7.01
• Ссылка на исправленную мной библиотеку phpDocumentor со списком внесенных изменений, думаю некоторым может сразу же понадобиться
• Ссылки на почитать

На проекте столкнулся с тем, что потребовалось создать нормальную документацию. Писать отдельно документацию не самый лучший способ, базовое описание библиотеки можно выполнить и в стиле автодокументации. Начал разбираться в вопросе и о чудо, в NetBeans 7.01 оказывается поддерживается PHPDoc, вполне достойно и удобно. Был удивлен бедностью информации по этой тематике в русском сегменте сети. Кроме того, я нашел несколько подводных камней, которые создавали проблемы при настройке под Windows.

Если заинтересовались, то добро пожаловать под кат

Вышел очередной релиз — кандидат новой ветки PHP 5.4. Отличия от предыдущей сборки:

• Добавлена конфигурационная переменная max_input_vars, позволяющая бороться с атаками, основанными на совпадении хэшей (hash collision attacks)
• Исправлен segfault в работе traits
• Исправлен баг с некорректным чтением и записью при использовании traits
• Исправлен segfault после 2 POST запросов с типом multipart/form-data (коды 200 + 404)
• Исправлена ошибка с неотображением ошибок PHP в некоторых браузерах, использующих SAPI
• Исправлен segfault при использовании старых версий OpenSSL
• Исправлены неработающие функции bindValue и bindParam в драйвере PDO для Firebird

Кстати для тех, кто хочет попробовать новые возможности PHP 5.4 (например, traits), не разбираясь в тонкостях сборки PHP из исходных кодов в своей Debian-based системе, можете использовать пакеты версии 5.3.99 с сайта http://apt.damz.org/(для Ubuntu 11.04).

Внимание! Все рассуждения относятся к запуску PHP в режиме CLI, а не как модуль веб-сервера!

Если вы когда-либо использовали функцию system() в PHP, вы наверняка задавались вопросом: каким образом system() возвращает последнюю строку для команды, да ещё и выводит результаты исполнения команды на веб-страницу, а не себе куда-то в stdout веб-сервера? И почему system() работает не так, как system() в Си? Ответ, в общем-то, проще, чем может показаться.

Тема пришла из далекого детства, когда я только начинал программировать, разбирал особенности PHP. На тот момент меня удивляла такая несправедливость: c сессией можно было работать как с обычным ассоциативным массивом($_SESSION), а для кукисов необходимо было использовать функцию setcookie(). Потом я уже поднабрался опыта и понял зачем это сделано именно так.
Время идет и PHP не стоит на месте, в нем появилась такая прекрасная вещь как SPL, одна из возможностей которой — обращение к объекту как к массиву, т.е. реализация ArrayAccess интерфейса.
И вот сейчас я вспомнил о своей детской идее, о массиве $_COOKIE, и реализовал ее:

<?php
/*
достаточно этой строчки чтобы создать куку как на стороне сервера так и клиента
*/
$_COOKIE['lang'] = 'ru'; 

Реализацию можно посмотреть под катом

Скажу сразу: у меня создание PEAR-канала и публикация пакета заняли около часа. Но, если отбросить все тупиковые способы, сэкономить на гуглении, и не использовать сомнительные утилиты, то вполне возможно уложиться в 10 минут.

У PHP программистов больше поводов не любить PEAR, чем любить. Действительно, создается впечатление, что за последние 5 лет ни библиотеки в репозиториях, ни сам инсталлятор, практически не изменились.
Тем не менее, до сих пор, установить PHP-бибиотеку проще всего посредством PEAR. Это, конечно, при условии, что она будет одинаково востребована для всей системы. Например, такие продукты, как PHPUnit и Docblox устанавливаются именно через PEAR, и крайне неудобно устанавливать их другими способами: например, клонированием GitHub репозитория.

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

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

MongoDB — документо-ориентированная система управления базами данных хранящая данные в виде наборов JSON-подобных документов. Для работы с MondoDB в PHP используется pecl расширение mongo, позволяющее полноценно работать с СУБД используя объекты доступа.
В статье пойдет речь об ORM (Object-relational mapping) standalone библиотеках и фреймворках позволяющих упростить использование Mongo в PHP проектах и предоставляющих интерфейс к работе с данными.

Долгое время в своих проектах в случае необходимости шифрования, практически автоматически, выбирал AES (он же Rijndael), входящий в библиотеку Mcrypt.

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

Есть такая штука, называется Phalanger.

Как следует из заголовка, проект компилирует PHP->.Net.
Зачем? Говорят, работает быстрей стандартного метода.

Памятка начинающему экзорцисту.

Прежде, чем начать: я знаю, что такое phpDaemon и System_Daemon. Я читал статьи по этой тематике, и на хабре тоже.

Итак, предположим, что вы уже определились, что вам нужен именно демон. Что он должен уметь?

• Запускаться из консоли и отвязываться от неё
• Всю информацию писать в логи, ничего не выводить в консоль
• Уметь плодить дочерние процессы и контролировать их
• Выполнять поставленную задачу
• Корректно завершать работу

Отвязываемся от консоли

// Создаем дочерний процесс
// весь код после pcntl_fork() будет выполняться двумя процессами: родительским и дочерним
$child_pid = pcntl_fork();
if ($child_pid) {
    // Выходим из родительского, привязанного к консоли, процесса
    exit();
}
// Делаем основным процессом дочерний.
posix_setsid();

// Дальнейший код выполнится только дочерним процессом, который уже отвязан от консоли

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

Например, встречались такие варианты:

if ($error['type'] == E_ERROR || $error['type'] == E_PARSE || $error['type'] == E_COMPILE_ERROR){…}

или

if(in_array($error['type'], array(E_ERROR, E_PARSE,  E_COMPILE_ERROR)) {…}

В связи с этим решил написать небольшую статью о битовых операциях с примерами их использования.

В сети гуляет довольно много решений для эмуляции многопоточности в php. Чаще всего они основываются на форках, но есть и вариации на тему с использованием curl, proc_open и т.п.

Все встреченные варианты по тем или иным причинам меня не устроили и пришлось написать свое решение.
Набор требований у меня был следующий:

• Использование форков;
• Синхронный режим с сохранением интерфейса при отсутствии необходимых расширений;
• Многократное использование дочерних процессов;
• Полноценный обмен данными между процессами. Т.е. запуск с аргументами и получение результата по завершении;
• Возможность обмена событиями между дочерним процессом-«потоком» и основным процессом во время работы;
• Работа с пулом потоков с сохранением многократного использования, передачи аргументов и получения результатов;
• Обработка ошибок выполнения;
• Таймауты на выполнение работы, ожидание работы потоком, инициализацию;
• Максимум производительности;

В результате получилась библиотека AzaThread (старое название — CThread).

Те, кто до этого времени использовали класс vk.wallpost.php, возможно, столкнулись с проблемой работы данного скрипта на хостинге. Данный класс был написан пользователем xbreaker и подробно разобран по частям в статьях: Часть 1 и Часть 2.

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

В статье описан функционал, который доступен в PHP (актуально для 5.3.х) для обработки ошибок всех типов, включая ошибки интерпретации кода (E_ERROR, E_PARSE, E_WARNING, etc). Эта обработка поможет вам для управляемого отображения страницы в случае возникновения таких проблем. В статье присутствует множество описаний и рабочих примеров(архитектуры) для того, что бы сразу воспользоваться в своем программном продукте. В конце концов, ну немного сломали сайт, ну надо же, об этом сообщить поисковику с заголовком 4хх или 5хх и повеселить пользователя, вместо возврата белого экрана (или что хуже экрана со священной информацией, для хакеров) с ответом 200 Ok.



Идея написать этот топик возникла, когда я на храбре задал 2 вопроса:

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

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

Если заинтересовались, то подробности под катом…

Часть первая (надеюсь, что не последняя)

Долгое время для меня OpenOffice оставался вещью-в-себе. Я знал, что он прекрасно автоматизируется питонами и бейсиками, но, вот, для PHP никак не мог найти подходящего инструмента. Совершенно случайно обнаружил такую интересную возможность OpenOffice: получение доступа к содержимому буфера обмена Windows. Тогда мне очень не хватало возможности писать простые CLI-скрипты, обрабатывающие текст в буфере на языке PHP. Поэтому я решил основательно разобраться, как можно рулить опен-офисом с помощью рнр из-под винды.

При разработке Web-приложений мы обязательно сталкиваемся с проблемами рендеринга HTML-страниц. Обычно эти проблемы решает шаблонизатор — собственно PHP или какой-нибудь парсер шаблонов. Если приложение большое и страницы содержат множество блоков, то сложность шаблонов может резко возрасти, а у разработчиков появляется желание упростить работу с ними. В ход идут разные техники, но обычно это выделение в шаблонах повторяющихся блоков и правильная их декомпозиция — включая наследование шаблонов.

Уходя от использования роутинга в .htaccess файле, в первую очередь пришёл к стандартному направлению на index.php: разбирал там URL и вызывал соответствующие контроллеры — долгое время был доволен такой техникой. Однако совсем недавно осознал, что что-то делаю не так, что можно сделать эффективнее и лучше.
Далее я расскажу о своём роутинге, использующем XML для хранения правил и в последующем использующем его сериализованный вид.

 

Задача

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

Описание проблемы

Представим среднестатистический высоконагруженный сайт. Обычно на таких сайтах между backend'ом и DB ставят прослойку кеша. С увеличением количества посетителей, вероятность того, что несколько пользователей одновременно наткнутся на "протухший" кеш увеличивается. Если такое случается, то нагрузка на backend и DB возрастает, что в свою очередь увеличивает время обработки запроса и увеличивает вероятность возникновения подобной ситуации. Вот такая вот система с положительной обратной связью:Маленькие красные горбики — это "затупившие" на множественном обновлении кеша запросы. Эта статья будет описывать один из подходов к решению проблемы на примере(patch attached) связки PHP/APC, однако теоретическая база применима к любому языку и системе кеширования.