В свое время работая в узком кругу программистов, отдельными задачами и даже проектам, мы не задумывались о проблемах связанными с текучкой кадров. Точнее думать — думали, но ни каких мер не применяли, да и в целом коллектив был сплоченный никто не уходил и никого «не уходили». С ростом внутренних проектов и корпоративных клиентов, штат начал разрастаться и казалось, что все отлично — нас больше, значит будем больше успевать и делать, но не тут то было. Мы начали тратить кучу времени на “бесполезные” обсуждения, проверки, излишние проектирование и т.д, больше всего раздражает — это проверка кода. И тут я начал думать, что “мудрые и древние” наверняка решали эти проблемы с сотнями, тысячами программистов, неужели мы не справимся? Я решил провести эксперимент, под названием “автоматизированная проверка стиля кода при комитах”. Для большинства из Вас это не новость и наверняка вы этим пользуетесь, но поделиться опытом внедрения думаю, не будет лишним.

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

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

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

Composer (getcomposer.org) — это относительно новый и уже достаточно популярный менеджер зависимостей для PHP. Вы можете описать от каких библиотек зависит ваш проект и Composer установит нужные библиотеки за вас! Причём Composer — это не менеджер пакетов в классическом понимании. Да, он оперирует с сущностями, которые мы будем называть «пакетами» или библиотеками, но устанавливаются они внутрь каждого проекта отдельно, а не глобально (это одно из основных отличий от старого-доброго PEAR).

Кратко, как это работает:

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

При создании Composer авторы черпали идеи и вдохновение из аналогичных проектов: npm для Node.js и Bundler для Ruby.

Изначально он был спроектирован и разработан двумя людьми Nils Adermann и Jordi Boggiano, сейчас в проекте участвует более двадцати контрибьюторов, Проект написан на PHP 5.3, распространяется под лицензией MIT и доступен на github.

Первые коммиты были сделаны апреле 2011 года и на сегодняшний день Composer находится в стадии «alpha3». Однако, он уже достаточно стабилен и используется многими популярными PHP проектами (например, Symfony 2). Список проектов использующих Composer можно посмотреть на сайте packagist.org — это официальный репозиторий Composer пакетов. Кстати, на недавней конференции Devconf 2012 разработчик фреймворка Yii в своём докладе упомянул, что Yii2 скорее всего тоже будет использовать Composer.

В этой статье я кратко опишу основные возможности Composer и мы попробуем создать демонстрационный проект использующий Composer для загрузки необходимых библиотек. Все примеры будут доступны на github.com и bitbucket.org.

Фреймворк для автоматического тестирования веб-приложений на PHP — Codeception живет и развивается. Но в этот раз вместо скупой порции новостей я бы хотел представить вам первый скринкаст в котором показаны азы работы с Codeception. Если вы только читали про Codeception, то вам обязательно стоит взглянуть на него в действии. Ну а если не читали, но у вас есть веб-сайт, который бы вы хотели протестировать — тоже взгляните.

Кажется, что Js — это «просто скриптовый язык» на котором я по-быстрому добавлю нужные фичи на странице, не сильно заботясь о качестве кода. Когда-то это было верным. Даже текущие стандарты Js и Html в целом располагают к этой философии.
Но времена изменились! Теперь на Js создают сложные и запутанные веб-приложения, которые просто не могут не столкнуться с проблемами своих «старших братьев» (серверных приложениях написанных на Java, C# и т.д.). А значит, чтобы не погрязнуть в тысячах строк «спагетти-кода», требуется отказаться от философии «просто скрипт». Нужно воспринимать Js как инструмент, с которым требуется создать сложную, модульную и масштабируемую систему.

В рамках новой философии «серьезного языка, для серьезных задач» я хочу начать цикл небольших статей о мире Js со стороны Java разработчика. Начнем с инструментов и различных шаблонов разработки.

Сегодня состоялся релиз стабильной версии http сервера Apache под номером 2.4.1. Первая стабильная версия ветки 2.2 была выпущена в далеком 2005 году. Не смотря на то, что в новом релизе большое множество нововведений он обратно совместим с API версии 2.2.х.

За подробным списком новшеств прошу под кат

Продолжая свои «css-раскопки» возникла новая идея, разобрать по косточкам ещё одну актуальную тему, которая касается равномерного выравнивания блоков по ширине. В принципе мои доскональные исследования я уже запостил у себя в блоге, но так как прошлая моя работа очень понравились Хабра-сообществу, то я решил сделать здесь небольшой краткий обзорчик этой статьи, чтобы ни одна хабра-душа не пропустили её наверняка. Так что, как говорил Гагарин: «Поехали».

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

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

Итак, первый совет. Забудьте всё что вы знаете о юнит-тестах. Швырните табуреткой в человека, который сказал вам, что без них не обойтись. Попробуем разобраться, в каких случаях нужно их использовать, а в каких — нецелесообразно.

На тему оптимизации MySQL запросов написано очень много, все знают как оптимизировать SELECT, INSERT, что нужно джоинить по ключу и т.д. и т.п.

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

Приветствую всех своих первых читателей!

Завязка

Написать эту самую первую статью меня толкнул всего один единственный баг в библиотеки Imagick, который отнял у меня некоторое время.

Началось всё с того, что была задача написать некий класс на php для работы с изображениями. Решил прибегнуть к помощи ImageMagick и к расширению Imagick.
Сам класс Imagick имеет обширное количество методов, однако требовалось расширить его и добавить собственные методы, такие, как проверка существования кеша изображения и получения пути к нему, собственно само кеширование ну и некоторые другие вспомогательные.

Для этих целей был написан нехитрый класс:

<?php
namespace app;
class Images extends \Imagick {
    private $_filePath = null;
    private $_cacheFile = null;

    // переопределенный метод
    public function readImage($filePath) {
        $this->_filePath = $filePath;
        parent::readImage($this->_filePath);
    }
    
    // что-то от себя
    public function myMethod() {

    }

    // дальше идёт продолжение кода...
?>

Теперь давайте разберёмся, почему этот класс работать НЕ будет.

Для определения страны по IP необходимы специальные базы данных, состоящие из диапазонов IP адресов и соответствующих им стран. Обычно такие базы данных распространяются в виде CSV или SQL файлов для использования в СУБД, либо бинарных файлов специального формата.

Для проведения тестирования была выбрана февральская база GeoLite Country, бесплатная версия GeoIP Country от MaxMind.

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

После публикации прошлой статьи, я полностью забил на попытку выполнить алгоритм при помощи HSV или Lab координат. Забил на использовании библиотек цветов и вообще на сам скрипт забил.

Но что-то стало скучно и опять зачесались руки поработать с изображениями и одновременно захотелось исправить уже имеющийся алгоритм.
Скрипт: link

Вышла новая версия офигительного UI фреймворка от Twitter — Bootstrap 2.0 Для тех кто не в курсе что это, настоятельно рекомендую ознакомиться. Этот набор позволяет создавать отличные шаблоны сайтов за считанные часы (проверено на собственном опыте) на основе готовых элементов и экономить килотонны нервов на адаптации кода под разные браузеры.

Особенности Bootstrap:

• Полный набор компонентов в виде стилей и анимаций поведения для элементов интерфейса
• Поддержка возможностей HTML5, CSS3 (но при этом работает и в IE7!)
• Поддержка идеологии 940-пиксельной сетки
• Поддержка идеологии fluid-grid
• Кросплатформенность — наборы стилей для десктопных и мобильных браузеров
• Возможность кастомизации и добавления собственных стилей
• Возможность добавлять jQuery плагины

Мастхэв для верстальщиков и проектировщиков интерфейсов!

Не один раз в комментариях замечал что народ негодует по поводу того, что веб-разработчики стали злоупотреблять использованием Bootstrap от Twitter. Признаюсь, я и сам успел закончить несколько небольших веб-приложений с использованием этого набора скриптов и стилей. Я не против использования Bootstrap от Twitter, я против злоупотребления этим когда есть столько хороших альтернатив. Я почти каждый день натыкаюсь на интерфейсы, построенные на Twitter Bootstrap, и это начинает напрягать. Последней каплей для поиска альтернативы стало изменение интерфейса биллинг панели моего хостера на шаблон Bootstrap. В этой записи я хотел бы немного рассказать про одну из альтернатив — HTML KickStart.

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

Множество удобных инструментов, найденных командой популярного онлайн журнала SmashingMagazine, приводится под катом

Какой-нибудь год назад все просто с ума сходили от Error-based MySQL, а unserialize казался чем-то сложным и не встречающимся в реальной жизни. Теперь это уже классические техники. Что уж говорить о таких динозаврах как нуль-байт в инклудах, на смену которому пришел file name truncated. Исследователи постоянно что-то раскапывают, придумывают, а тем временем уже выходят новые версии интерпретаторов, движков, а с ними – новые баги разработчиков.
По сути, есть три метода найти уязвимость: смекалка (когда исследователь придумывает какой-нибудь трюк и проверяет, работает ли он на практике), анализ исходного кода и фаззинг. Об одном интересном китайском фаззинге и его развитии с моей стороны я и хочу рассказать.

В наше время для различных сайтов нормой стали всевозможные всплывающие модальные окна — popup'ы — для регистрации, авторизации, информационные окна, — всевозможных форм и размеров. Также существует огромное количество плагинов к тому же jQuery для простого и удобного создания таких попапов — тот же Shadowbox, например.

Ранее я показал элементарную реализацию алгоритма шинглов, позволяющую определять, являются ли два документа почти дубликатами или нет. В этот раз я поясню реализацию алгоритма, описанную Зеленковым  Ю. Г. и Сегаловичем И.В. в публикации «Сравнительный анализ методов определения нечетких дубликатов для Web-документов».
Этим я начинаю серию из трех теоретических статей, в которых постараюсь доступным языком описать принцип алгоритмов шинглов, супершинглов и мегашинглов для сравнение веб-документов.

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

Когда-то смотрел документацию по Zend_Search_Lucene. Все хорошо, все понятно. Бери и встраивай в свой сайт. Только вот ни слова там нету про то, каким образом прикрутить стеммер или морфологический анализатор к этой штуке. На деле оказалось, что подружить его, например, с PHPMorphy, очень просто.
Собственно, как это сделать — под катом.
Заметка в первую очередь будет полезна разработчикам, перед которыми проблема полнотекстового поиска на сайте еще не стояла.
Тут вы не найдете мануала по настройке Lucene или PHPMorphy — этой информации и так предостаточно в интернете.