PHP *

1) Какой бы ерундой вы не занимались с PHP, узкое место _всегда_ — БД. PHP — он как Буратино — тупОЙКАк… дрова. Lighttpd и Nginx позволяют разнести его по множеству физических серверов на раз без шума и пыли. Зарплата адекватного спеца по PHP в Москве — 30-45 тыс. рублей в месяц, стоимость аренды нормального сервера — от 3 тыс. рублей в месяц. А вы не знали ;)?

2) Какой бы ерундой вы не занимались — 30-60% производительности (возможно и больше) PHP-кода решит правильно выбранный и настроенный акселератор.

3) Серебряной пули нет. Не важно, какой концепт вы применяете — строгое ООП (в стиле Zend Framework), функции в стиле PHP4 (или ограниченное ООП) или вообще лапшу в стиле «PHP для чайников» — ни одна из этих парадигм не даст ощутимый прирост производительности, если конечно ваши программисты не выше как минимум на голову.

Всем доброго времени суток.

Перевод заметки "40 Tips for optimizing your php code". Автор — Reinhold Weber.

1. Если метод может быть статическим, объявляйте его статическим.
2. echo быстрее, чем print.
3. Передавайте в echo несколько параметров, вместо того, чтобы использовать конкатенацию строк.
4. Устанавливайте максимальное количество проходов ваших циклов for до цикла, а не во время его выполнения.
5. Удаляйте свои переменные для освобождения памяти, тем более, если это большие массивы.
6. Остерегайтесь магических методов, таких как __set, __get, __autoload.
7. require_once дорого обходится.
8. Указывайте полные пути в конструкциях include/require, меньше времени будет тратится на поиск файла.
9. Если вам необходимо определить время, когда скрипт был запущен, используйте $_SERVER[’REQUEST_TIME’] вместо time().
10. Старайтесь использовать strncasecmp, strpbrk и stripos вместо регулярных выражений.

 

Отчего-то всегда хотел сделать свой сервис для загрузки файлов. Всевозможные slil/zalil не устраивали своей скоростью. ifolder — обилием рекламы. Пользовался не очень популярным (от этого он ни чуть хуже не становился) сервисом up.spbland.ru. Но это как-то не правильно. И тут я решил написать свой сервис. Не буду вдаваться в подробности и рутину, только концепция.

 

В общем, начинаю постепенно выкладывать троды плудов на суд общественности. На www.frwk.net появились уже трак проекта и блог, куда я мало-помалу буду постить информацию о фреймворке.
Вкратце: Frontier предоставляет связи между компонентами, легко помогает подключать различные прикладные библиотеки, а сам предлагает только структуру приложения, общую конфигурацию и т.п. Краткое описание оформлено одним из постов там же: www.frontierframework.net/blog/2008/03/29/the-travel-begins

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

Буду рад всяческим комментам.

По просьбе: www.frontierframework.net/release/hello.tar.gz — это минимальное приложение с комментариями на русском.

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

Хорошие фреймворки предлагают инструменты для полного кэширования страниц, фрагментарного, или кэширования экшенов. Недавно я посмотрел 90 выпуск подкаста Railscasts, посвященный именно фрагментарному кэшированию в Ruby on Rails и уважаемый автор решал проблему, как мне показалось, неоптимально.

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

Два дня назад один из разработчиков PHP Дмитрий Стогов (dmitry+at+zend+dot+com) опубликовал результаты тестов новой версии php 5.3

Он не описывает какие именно тесты он производил, но статистика впечатляет
Drupal 20% быстрее
Qdig 2% быстрее
typo3 30% быстрее
wordpress 15% быстрее
xoops 10% быстрее

PHP 5.3 станет быстрее (http://news.php.net/php.internals/36484)

<p />Итак, мы решили начать программировать «по понятиям» и наконец разобраться с каким-нибудь фреймворком.
<p />Перед нами встаёт мучительный выбор, какой же фреймворк для этого использовать. Для этого можно найти кучу статей, обзоров, сравнительных анализов скорости, производительности, удобства использования и установки, а можно просто набрать в гугле «php framework» и кликнуть

Поискал ссылки поиском по хабру, не нашел.

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

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

Итак, вот они:
www.hotscripts.com
www.planet-source-code.com
php.resourceindex.com
cgi.resourceindex.com
www.scripts.com/php-scripts
www.phpclasses.org
mymans.org/category/php

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

Risearch.org — хорошая, полная версия на Перле и платая. MnogoSearch — очень громоздкая в настройке, мне столько опций не нужно. В ряде других вариантов — простые стеммеры, либо вообще отсутсвие любой поддержки русского языка. Ладно, пусть будет даже стеммер, но у результатов должна быть высокая релевантность.

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

Несколько дней назад скачал ZF 1.5.0 RC3 и собирался его использовать в живом проекте, несмотря на RC3.
Естесвенно вчерашняя новость о релизе ZF очень порадовала. И перед тем как заменить файлы я решил посмотреть, чем собсвтенно релиз отличается от релиз кандидат (я думал, что особо ничем), который я уже закинул в проект.
В общем сделал диф, и так как на Хабре уже стал вопрос о отличиях релиза от кандидата, то решил запостить этот диф. Изменилась регулярка и версия.
Команда
diff -r ZendFramework-1.5.0/library/Zend/ ZendFramework-1.5.0RC3/library/Zend/ > zend_diff
Результат ниже.

 

Добро пожаловать в третью статью о xdebug. Уже сейчас вы должны были попробовать xdebug, если нет, сделайте это сегодня ;-).
В первой статье рассказывалось о том, как установить и настроить xdebug, описывались некоторые простейшие возможности, такие как улучшение вывода функции var_dump() или вывод трассировки стека вызовов при получении сообщения об ошибке. Во второй части мы рассмотрели такую возможность xdebug как трассировку. Трассировка содержит все вызовы функций и методов в программе, время запуска, опционально размер памяти, передаваемые и возвращаемые параметры. Лог трассировки может помочь вам понять пути выполнения сложной программы. Вместо того чтобы вставлять отладочный код внутрь программы, вы включаете или выключаете трассировку в тем места где нужно, а потом используете утилиты подобные grep или собственно написанные приложения на PHP для анализа лог файла.

Зашел только что посмотреть ссылочку на Zend Framework 1.5.0PR, а вместо этого увидел следующее:



Сегодня Zend Framework перерос из стадии beta в релиз.

Пробуем? ;)

P.S.: Подробнее здесь. А вот release notes я пока не нашел, соответственно, где почитать что поменялось — пока не знаю…

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

Довольно часто (постоянно) мне приходиться проводить собеседование людей желающих устроитсья в мой отдел на должность «junior PHP developer» и «PHP developer». И, с завидным постоянством, я и team-lead отдела задаем одни и те же вопросы…

Добро пожаловать во вторую серию нашего повествования про xdebug. Установка xdebug и его базовые возможности были рассмотрены в первой серии. В данной статье мы рассмотрим трассировку программы.
Предыдущая серия цикла Introducing xdebug

Данная статья расчитана для двух типов разработчиков:
— кто еще не знаком с исключениями
— кто пытается найти более разумное использование исключениям

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

Эволюция языков программирования приводит иногда к кардинальным изменениям в мировоззрении разработчиков. В мире РНР такое случилось при появлении пятой ветки, которая принесла новую объектную модель, новые наборы встроенных функций и новые методы обработки ошибок…

Те, кто начинал знакомиться с PHP (тут и далее я буду подразумевать пятую версию), после другого процедурного языка программирования, так и не поняли что же такого в переходе от 4ки к 5ке и продолжают оформлять код привычными функциями, которые находятся на одном уровне по отношению друг к другу, а так же каждое действие проверяют на удачный код возврата. Но те кто знали об исключениях и классах…