Вышла первая бета-версия Zend Framework 2.0.0. Установочные дистрибутивы и инструкции доступны по адресу: http://packages.zendframework.com. Как пишут на официальном сайте Zend, это первая бета из серии планируемых бета-релизов. В дальнейшем, разработчики планируют придерживаться релизов в «gmail»-стиле. А именно новые возможности и фичи будут добавляться в каждой новой-бета версии, которые будут выходить не реже чем каждые шесть недель.

Надеюсь, что данный пост окажется полезным многим разработчикам, т.к. судя по многочисленным тредам в интернете, проблема-то довольно частая. Суть проблемы в следующем: неправильное наименование кодировки utf-8 в настройках nginx/apache. При этом отдаваемый сервером контент воспринимается нормально во всех браузерах, кроме Internet Explorer-a.
 
 

Сегодня хочу рассказать об одной проблеме, с которой я столкнулся совсем недавно. Надеюсь, что мой опыт, описанный в данной статье, поможет сэкономить часы и нервные клетки тем людям, кто занимается разработкой SOAP сервисов с использованием Zend Framework, и в частности класса Zend_Soap_AutoDiscover.
Проблема заключается в том, что Zend_Soap_AutoDiscover отрабатывает некорректно вкупе с использованием известного оптимизатора кода eAccelerator. А именно, если быть точным некорректно работает метод ReflectionClass::getDocComment(). Но…обо всем по порядку.

Хочу поделиться одной интересной находкой, откопанной среди плагинов Firefox-а. Называется этот плагин Illuminations for Developers for Firebug и представляет из себя дополнение к Firebug для работы с тяжеловесными JS либами, преимущественно с ExtJS и Sencha Touch. Помимо этого, создателями заявлено, что в beta-версии плагин поддерживает Dojo Toolkit, SproutCore, qooxdoo, YUI, Google Closure Library, jQuery UI. Поскольку по работе мне в основном приходится использовать ExtJS, то в первую очередь было интересно, как данный плагин поможет в разработке именно на основе этой библиотеки.

Столкнулся я с этой странностью совершенно случайно. Один мой коллега по ошибке забыл добавить расширение к подключаемому JavaScript-файлу. В коде страницы выглядело это примерно так:
<script type='text/javascript' src='/js/some'></script>
Каково же было мое удивление, когда Apache вместо вполне ожидаемой 404 страницы и ответа в духе «пошел нафик, такого файла не существует», выдавал корректный JS как ни в чем не бывало. Спрашивается, как же так? Почему Apache при запросе файла без расширения отдаёт тот файл, у которого совпадает имя до расширения? o.O

Не так давно, а именно в октябре 2010 года, компания Zend немного обновила систему сертификации PHP5 инженеров. Так, если раньше тестирование проводилось по версии 5.1, то теперь проводится по 5.3 (привет namespaces, late static bindings и замыкания ). Были переформированы темы тестирования — вместо 12ти прежних, теперь их 10. И что самое главное, из Zend маркета убрали подготовительные тесты. Раньше их можно было приобрести в количестве 1, 5 или 10 штук за относительно скромные деньги (10 стоили порядка 22$). Сейчас же вместо них за довольно-таки нехилую сумму в 1000$ можно приобрести так называемый Test Prep: Zend PHP 5.3 Certification Training (подготовительный online-треннинг для продвинутых php-программистов) и ваучер на прохождение тестирования. Кстати, о ваучере… если для версии 5.1 он стоил 125$, то теперь цену подняли до 195$.

Ни для кого не секрет, что в PHP существует так называемый «garbage collector» — сборщик мусора для удаления устаревших сессионных данных. По умолчанию, garbage collector подчищает только те сессии, которые не были использваны в течении предыдущих 24х минут (время задается в директиве session.gc_maxlifetime файла конфигурации php.ini), а сами сессии храняться в файлах. Так же garbage collector запускается при старте механизма сессий (т. е.session_start()), но не каждый раз, а с некой периодичностью, определяемой соотношением величин session.gc_probability / session.gc_divisor — это «вероятность» запуска сборщика мусора. И вообщем-то казалось бы все довольно очевидно и кроссплатформено, но … оказывается что в Debian-е все устроено не совсем так, как у всех

Так получилось, что разработчики славного дистрибутива Ubuntu (которым я пользуюсь в качестве основной системы вот уже более полутора лет) совершенно не запариваются по поводу багов и глюков софта новых версий. Фактически через некоторое время после обновления некой софтины до новой стабильной версии, непременно появляется её обновление в официальном репозитории Ubuntu. Ядро Linux не исключение — так после пары месяцев работы с этим дистрибом в системе скапливается порядочное количество ядер самых разных версий. В принципе, ничего страшного в этом нет, но в большинстве случаев старые ядра лежат мертвым грузом и лишь занимают драгоценное место на HDD (которое можно было бы портатить более рациональным образом, например на фильмы и музыку )) ). А ещё немного раздражает тот факт, что при загрузке системы GRUB выдает весь этот здоровенный список ядер, что может приводить в небольшое недоумение
Итак, данный очерк посвящен удалению этих самых старых ядер.

Так или иначе рано или поздно любой web-разработчик сталкивается с проблемой того, что «надо что-то подковырять на сервачке, где крутится проект». Само собой работая на локали, мы не задумываемся порой над проблемой распаковки архивов и тому подобных рутинных операций. Совсем другое дело, когда работа начинается с удаленный сервером, где крутится проект. В большинстве случаев на таких серверах расположена Unix-like OS без какого-либо user friendly интерфейса (в целях экономии ресурсов конечно же), а все действия с сервером осуществляются через ssh-туннель прямо в консоли. Приведу небольшой список операций, которые мне приходилось выполнять чаще всего.