Дочитал на днях сабжевую книжку. Вышла она еще в 2008 году (а предыдущее издание и того раньше), но мне она попалась только недавно. По идее, читать ее надо было бы после книги Фаулера «Рефакторинг. Улучшение существующего кода», на которую Кириевски постоянно ссылается, но до Фаулера я пока не добрался, хотя это и не особо затруднило чтение. Вторая книга, которую лучше всего прочитать заранее, это «Приемы объектно-ориентированного проектирования. Паттерны проектирования» банды четырех.

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

Dune2 — как много в этом звуке, для сердца русского слилось...

Немного истории из Wiki Dune2:
Dune II: The Building of a Dynasty — одна из первых компьютерных стратегических игр в реальном времени. Игра вышла в далеком нынче 1992 году, требовала i80286 процессор, VGA видеокарту, 7 Мб свободного места на жестком диске и MS-DOS.

Как часто вы пишете велосипеды? Можно я тоже тут рядом пристроюсь? Но дело в том, что мой велосипед, он особенный. Казалось бы, простенький, трехколесненький, склепанный всего за один день. Но есть одна хитрость — он работает на движке от болида. Что он умеет?

А смотрите:

<?php
$class = MySingleton::getInstance();
var_dump($class instanceof MySingleton); // => (bool)true
var_dump($class instanceof DOMDocument); // => (bool)false

// а теперь немного магии
test::double('MySingleton', ['getInstance' => new DOMDocument]);

var_dump($class instanceof MySingleton); // => (bool)false
var_dump($class instanceof DOMDocument); // => (bool)true
?>

О нет, мы изменили синглтон! Мы переопределили статический метод. Как же теперь жить?
Но вопрос теперь в другом: как мы жили до этого?

Встречайте AspectMock. Самый простой, но самый мощный фреймворк для моков и стабов на PHP.
Ваш новый суперпростой помощник в тестировании. Основан на Go AOP от NightTiger.

Добрый день!

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

Для этого нам нужны утилиты командной строки для ELB: aws.amazon.com/developertools/2536. Распакуем их в папку /opt/aws/elb.

Добрый день!

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

В качестве инициатора маштабирования будет выступать Cloud Watch. Метрикой будет наша кастомная метрика Load Average.

Итак, начнём-с. Первое, как тру линуксоид, я советую и рекомендую использовать в настройке автоскейлинга утилиты командной строки (Command Line Tools — CLT) по следующим причинам:

• из CLT можно сделать всё;
• удобнее копипастить в консоль, чем кликать мышкой.

PHP очень популярный язык программирования, но тестирование в нем, это скорее прерогатива экспертов, а не жизненная необходимость. Неужели это от того, что PHP-разработчики поголовно быдло-кодеры? Я считаю, что нет. Скорее всё от того, что системы тестирования порой излишне усложнены. А тесты, наоборот, должны были предельно просты: легко читаться, писаться, отлаживаться, и конечно же, быстро выполняться. Мое виденье того как это можно воплотить в PHP вылилось в проект под названием Codeception.

С ним тесты для ваших веб-приложений могут выглядеть так:

<?php
$I = new TestGuy($scenario);
$I->wantTo('create new blog post');
$I->amOnPage('/blog/posts');
$I->click('Create new post');
$I->fillField('Title','Codeception, a new way of testing!');
$I->fillField('Text','Codeception is new PHP full-stack testing framework.');
$I->click('Send');
$I->see('Congratulations, your post is successfully created!');

Согласитесь, такой тест понятен без дополнительных комментариев.
А теперь самое интересное: этот код без всяких изменений может быть выполнен как функциональный тест в фреймворках symfony, Symfony2,Zend Framework, а также в браузерном эмуляторе Goutte и даже через Selenium. Таким образом, вам предлагается единый интерфейс для написания функциональных тестов практически для любого сайта.

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

Боевая задача.

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

• Виртуальный сервер в формате micro на основе Linux с доступом по SSH.
• 30Гб места в Elastic Block Storage плюс 1Гб под бэкапы.
• 15 Гб трафика в месяц.
• Выделенный внешний IP адрес.

Причем все это при желании можно зарегистрировать и подготовить к работе за полчаса, но понадобится кредитная карта, которую примет Amazon (и снимет 2 доллара) и сотовый телефон под рукой (домашний не подойдет).

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

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

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

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

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

Давно хотел поделиться с общественностью способом тестировать код, использующий функции для работы с внешней средой: с сокетами, БД, файлами и чем угодно ещё. Сегодня, увидев статью Runkit + PHPUnit = 100% покрытие тестами, решил, что сейчас самое время.
Решение с Runkit красивое, но есть одна проблема — Runkit не распространяется вместе PHP, его надо ставить отдельно. Я же хочу предложить подход, работающий в обычной поставке PHP 5.3+, при одном условии — проект должен использовать пространства имён.

Здравствуйте, уважаемые коллеги.

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

Другим же условием хороших тестов является отсутствие сторонних эффектов (side effects), как например создание/удаление файлов, установка сетевых соединений, запись в порты и т.д.

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

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

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

Прокси — это новые объекты JavaScript для которых программист должен определить своё поведение. Стандартное поведение всех объектов определено в движке JavaScript, который чаще всего написан на C++. Прокси позволяют программисту определить практически любое поведение объекта JavaScript, они полезны для написания базовых объектов или оберток функций или для создания абстракций виртуальных объектов и предоставляют API для мета-программирования. Сейчас Прокси не входит в стандарт, но его стандартизация запланирована в ECMAScript Harmony. Чтобы избежать путаницы уточню, что эти Прокси не имеют ничего общего с прокси серверами.

Где их можно использовать

1. Общие промежуточные абстракции
2. Создание виртуальных объектов: обертки существующих объектов, удаленные(от слова далекий) объекты, ленивое создание объектов (Пример ORM — Ruby ActiveRecord, Groovy GORM)
3. Прозрачное ведение логов, трассировки, профилирования
4. Внедрение предметно-ориентированных языков
5. Динамический перехват несуществующих методов, создание отсутствующих методов (__noSuchMethod__)
6. База для специфичных итераторов

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Видели ли вы, когда на небольшой торговой точке, после продажи, продавец записывает что то в толстую тетрадку? Учет продаж и товаров в вашем бизнесе это толстая тетрадь и калькулятор? А что, если бы существовала небольшая бесплатная программа, работать с которой могла бы даже «блондинка», а добавить продажу можно с помощью пары щелчков мышкой, не открывая несколько окон, и не вводя ненужные для небольшой торговой точки поля. Программа, в которой можно вести учет товаров, всегда видеть остатки, и легко и просто проводить инвентаризацию. Программа, в которой можно было бы заводить несколько продавцов, и смотреть потом их продажи за день, месяц, год.
Плюс к этому всему возможность просматривать продажи удаленно на сайте, на любой из ваших торговых точек.
И все это бесплатно, с открытым исходным кодом, и с возможность написания плагинов на языке программирования python.

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

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

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

Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.

Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.

Прошелся по закладкам и образовалась такая толстенькая подборочка ресурсов с бесплатными и качественными иконками, с которой спешу поделиться с тобой %username%!

Iconfinder

Все, все будут писать тесты

Уже 3 года прошло, с тех пор как я увидел свою первую красную полоску. Что меня дернуло начать писать тесты, уже не важно. Я начал собирать информацию, перечитал весь wiki.agiledev.ru и торжественно запустил свой первый тест на SimpleTest. Конечно, эти тесты были ужасны, да и архитектура тоже (в моем сегодняшнем понимании). Тогда я, наверное, словил большинство ошибок, но зато замечательно провел время :)

Потом перешел на PHPUnit — просто было интересно, чем он отличается от SimpleTest и что в нем такого «навороченного».

А lime — гадость. Чего ребята из Symfony в него так вцепились? Понимаю ветка 1.*, наследие и все такое. Но 2.0 можно было бы и на PHPUnit начинать.

Да, мне это было интересно. Я активно писал тесты, даже честно пытался делать это перед тем, как писать код. Что-то не получалось, читал разные статьи на тему, как надо и не надо писать тесты, перечитывал wiki.agiledev.ru. Но внутри явно чего-то не хватало.

Здравствуйте.

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

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

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

Меньшие конторы, фрилансеры этим грешат, да и на маленьких проектах это не всегда нужно. Согласитесь, если класс на 100 строк, то писать тесты на 200 строк кажется лишней тратой времени.

Тем не менее, не буду вдаваться в подробности кому надо кому нет.

Я хочу показать как можно клево тестировать код на NetBeans с удобным GUI.

Когда я в очередной раз использовал LogParser, то чтобы проникнуться и чужим опытом, ввел его название в поиск на Хабре. Как результат — сообщение «Удивительно, но поиск не дал результатов». Вот уж воистину удивительно, когда столь интересный инструмент обойден вниманием. Пришла пора восполнить этот пробел. Итак, встречайте LogParser. Маленькая, но чертовски полезная утилита для любителей SQL.

Из названия инструмента, казалось бы, очень непросто понять, что он делает в разделе SQL. А правда заключается в том, что он такой же LogParser, как и ChartGenerator. В то смысле, что он справляется с обоими задачами с одинаковыми успехом. В целом я бы его охарактеризовал как SQL-процессор гетерогенных данных. Концепция работы в общем такова, что он берет данные из некоторого формата и преобразует их в табличный вид (собственно говоря, только на этом этапе и выполняется иногда парсинг). Затем, посредством выполнения над этими табличными данными некоторого SQL-запроса формирует таблицу с результатом и сохраняет ее опять же в некотором формате. Если коротко, то цепочка выглядит как подготовка входных данных->SQL-процессинг->генерация выходных данных.