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

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

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

В октября-ноябре проходит юбилейный, пятый всеукраинский чемпионат для веб-специалистов.

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

Добрый день.
Недавно одни из наших заказчиков выразили желание получать дополнительную информацию о посетителях своего сайта, конкретнее — о людях, заполнивших контактную форму. Это крупная европейская компания и им хотелось бы «фильтровать» своих потенциальных клиентов. Поясню на примере — допустим, решают они организовать выставку своего оборудования в Венгрии и им нужно решить, кто из венгров, оставлявших им свои контакты, скорее всего стоящий клиент, а кто «мимо проходил».
Основными показателями «надежности» клиента для нас стали: число посещений сайта, время проведенное на сайте, количество просмотренных страниц. Всю эту информацию мы получили из Google Analytics Cookies.

Что же из себя представляют печеньки от Google?

Введение

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

Сегодня мы поставим MongoDB, ниже рассмотрим свежеиспеченный ХабраЛоггер и пошпионим за главной страницей Хабра в реальном времени.

Введение

Коллеги, при разработке приложений, мы каждый день сталкиваемся с потребностью в гибком хранении информации (обновлении, поиске по ней, и т.д.). Класс продуктов, которые решают этот круг задач, как все мы знаем — Базы данных. Но что это такое в нашем понимании? У многих «база данных» твердо ассоциируется с MySQL, таблицами и SQL-запросами. И это устраивает до определенного момента. Действительно, реляционные базы данных дают массу преимуществ в работе: поскольку данные имеют сильную связанность, не нужно контролировать целостность базы данных. Используя простой под-запрос можно выбрать количество комментариев к каждому посту в блоге. Используя JOIN нетрудно делать сложные связанные выборки и получать данные сразу о нескольких сущностях.

Каждый, кому приходилось писать объемные куски осмысленного кода на javascript, рано или поздно понимал, что ему многого не хватает в этом языке или просто неудобны некоторые врожденные конструкции. Для сглаживания шероховатостей применяются jQuery, Prototype, MooTools etc. Кто-то уже мало представляет себе, как можно кодить без них. Сегодня я расскажу о еще одной маааленькой библиотечке, которая делает мир javascript-программиста еще прекраснее. Речь пойдет о Underscore.js

Перевод статьи Sara Golemon «Extension Writing Part I: Introduction to PHP and Zend».

Существует цепочка в мозгу: мы напишем юнит тесты, затем эти тесты нам расскажут если мы что-то сломали, затем они нам почту будут отправлять о том, что проект поломался.
Это ничто иное, как иллюстрация непрерывной интеграции (Continious Integration) нычне крайне модного направления гибкой разработки. Единственный недостающий элемент цепочки — «КАК». Ниже коротенький рецепт, как бы отвечающий «очень просто».

Сейчас, пожалуй, только староверы в глубокой тайге не знают, что такое фриланс. Причем те из них, кто еще не отдал добычу еды на аутсорсинг. И вместе с тем, как набирает обороты движение свободных разработчиков, рождается множество забавных, а, порою, опасных религий, с этим связанных. Про одну из них мне и хотелось бы поведать. Мотиватором для этого послужила данная статья на Хабре — habrahabr.ru/blogs/pm/95548.
NB: Статья, разумеется, шутливая и позже была перенесена в ХабраЮмор, но нас ведь не проведешь и мы прекрасно понимаем, что юмор используется для того, чтобы на рынок умов могло проникнуть то, что не пустят через парадный вход. Как говориться, политический анекдот — это тоже шутка. В общем обратите внимание, что рассматривается не упомянутая статья, а религия, частным порождением которой эта статья и является..

Итак, есть такая партиярелигия: заказчик — Враг, потому что он Виноват Во Всем. Именно так, с большой буквы «В». Иногда он Гад, Мерзавец и Подонок, но в итоге он все равно Виноват. Сорваны сроки — виноват заказчик, проснулись с больной головой — виноват заказчик, молоко убежало — виноват заказчик. Любое письмо от заказчика вызывает нервный тик, звонок — приступы бешенства, а уж встреча — это ринг микс-файтинга и DeathTrack'а без каких-либо правил.

Естественно, мы любим его, когда он нас выбирает в качестве подрядчика. Воодушевляемся, когда получаем аванс и т.п. Но речь идет о тех моментах, когда проект пошел не туда, куда мы его направляли. Или не направляли, но тайно в душе надеялись, что он туда пойдет. Вот в такие периоды и проявляется наша «темная сторона» и мы начинаем искать его вину… Впоследствии различные «виноватости» группируются, сортируются и каталогизируются, рождая множество притч, легенд и статей аналогичных вышеупомянутой. Но разрешите вам представить и другую точку зрения.

Задрало.
Настолько плотно прижилась кругом эта дрянь, что и не встретить уже человеческого отношения к себе, как к пользователю.

Этот материал открывает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Уже около года регулярно собираю, публикую и расшариваю эти ссылки в тематической Friendfeed-комнате User Experience, но помимо общей ленты полезным оказался и дайджест. Это первый выпуск — апрель 2010 года.

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

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