Не кажется ли вам странным то, что когда вы собираетесь поменять место работы и возникает необходимость пройти интервью, то в первую очередь вы думаете «надо подготовиться к интервью». Прорешать задачи на HackerRank, почитать Crack the coding interview, зазубрить как устроен ArrayList и чем она отличается от LinkedList. Ах да, еще сортировки спросить могут, и явно будет непрофессионально сказать, что quick sort скорее всего будет лучшим выбором.
Но постойте, вы ведь программируете 8 часов в день, решаете интересные и нетривиальные задачи, и на новом месте работы будете делать плюс-минус тоже самое. Но тем не менее, чтобы пройти интервью необходимо как-то дополнительно готовиться, даже не оттачивать ежедневные навыки, а выучить то, что вам не понадобилось ни на текущем месте работы, ни вряд ли понадобиться на следующем. На ваши возражения о том, computer science у нас в крови, и разбуди нас посреди ночи мы обязаны написать с закрытыми глазами на наволочке обход дерева в ширину даже не приходя в сознание, я отвечу, что если я буду устраиваться в цирк, и моим главным трюком будет именно это — то пожалуй да, я согласен. Нужно этот навык проверить.

Gearman — фреймворк для распределения задач. Подробней о нем можно почитать: Здесь или Здесь. Этот инструмент — находка для решения целого ряда задач. Но при его эксплуатации на боевых серверах мы столкнулись с некоторыми проблемами, решением которых я хочу поделится:
— Как автоматически запускать демонов и следить за их здоровьем?
— Как запустить несколько инстансов воркеров?
— Куда демоны будут писать сообщения, предназначенные для вывода на экран?
— А как следить, чтобы демоны не отвлекались на грудастых гаргулий, а работали. словом следить за нагрузкой.
Для этого есть довольно удобные инструменты:

Тестировать или нет классы, взаимодействующие с Базой данных — вопрос куда более холиварный, чем спор «покрывать код тестами или нет». Просмотрев свой проект, нам стало очевидно, что львиная доля классов основана на взаимодействии с базой данных. Поэтому было однозначно решено: «тестированию быть».
Далее я хочу поделится опытом написания модульных тестов для кода, работающего с базой данных.

PHPUnit содержит расширение для тестирования базы данных. Расширение выполняет следующие функции:

• перевод базы данных в заранее известное состояние,
• выполнение необходимых модификаций данных,
• проверка, что в базе данных созданы ожидаемые записи.

К сожалению в этом списке отсутствует одна очень нужная нам фича — восстановление данных в состояние, в котором они находились до тестов. Я хочу предложить 2 варианта решения этой проблемы. Так же попутно остановлюсь на проблеме внешних ключей, которая часто возникает при накатывании не полных тестовых данных на «рабочую» базу.

Итак, я предлагаю 2 варианта решения проблемы: как после проведения юнит теста вернуть базу данных в исходное состояние:
Первый путь — «Транзакционный». Суть которого сводится к выполнению всего теста в рамках одной транзакции, и последующему rollback'у транзакции.
Второй — Перед выполнением теста скопировать структуру «рабочей» базы и проводить тестирование на ней.