Какая-то «не здоровая пьянка» пошла последнее время на хабре про собеседования. Люди, хватит уже, нет ничего страшного и особенного в собеседованиях, я уже несколько лет провожу их с IT-шниками, и в 95% случаев это адекватные и приятные люди. Потому хочу поделиться с вами «дзеном» о том, как лучше проводить именно техническое собеседование, да и вообще оценивать навыки тех. специалистов, так как вопрос оценки компетентности технического специалиста может быть довольно сложным, особенно если вы не хотите проводить собеседование на 3 часа к ряду. С данной моделью вы вполне можете уложить тех. собеседование в 40-50 минут (а то и быстрее) и быть уверенным в решении на 80-90%. Если про оценку эмоционального интеллекта, базовой мотивации и просто уровня адекватности, информации довольно много, то вот про то, как эффективно оценивать технические навыки специалиста, зачастую, «кто в лес, кто по дрова». Данная статья может быть также полезна и тем, кто просто хочет эффективно расти как специалист, потому как именно их знания и рассматриваются.
Данной статьей я хотел описать явление организационного характера, которое возникает в работе многих компаний. Суть его заключается в том, что когда что-то идет не так в работе, например малоэффективные бизнес-процессы или ухудшающийся с каждым днем код, могут появляются люди, которые будут гореть желанием это изменить, просто потому что им этого самим хочется, хочется в каком-то роде «сделать мир лучше». И эту энергию очень важно правильно использовать. Если она не будет эффективно направлена в нужное русло, то, не реализовавшись, она начнет «выжигать» инициатора изнутри и в конце концов демотивирует его, а то и вовсе приведет к потере сотрудника. Если же ее использовать адекватно, то вы сможете не только с высоким уровнем мотивации произвести полезные для организации изменения, но и дополнительно развить сотрудника.
Никогда не думали, а что если паттерны ООП спроецировать на работу программистов? 
Коллеги, у меня для вас есть замечательная новость, мы получили чудесный проект, его несколько лет писали неизвестные нам разработчики, адрес которых мы вряд ли узнаем (чтобы «поделиться обратной связью»), писали очень давно и не известно под чем, и нам предстоит его поддерживать и развивать. Проект сейчас находится на пике своей производительности и мы скоро упремся, любые неаккуратные изменения могут его положить, но мы будем его развивать. Ура!
Почти в каждом более менее динамическом проекте бывает возникает необходимость выполнять очереди задач в фоне (отправка email, обновления кеша, реиндексация поиска и т.д.). Job сервера (Gearman и т.п.) хороши, но для большинства простых задач они избыточны. Классическая реализация очередей в MySQL (при помощи SELECT … LOCK FOR UPDATE) при росте нагрузки со временем начинает приводить к проблемам с блокировкой. Потому, как это обычно бывает, пришлось написать свой «велосипед» для работы с фоновыми задачами, который бы «точно работал» и был предельно прост.
В связи с 
Само наличие психологической деформации у какой-либо профессии, как правило, достаточно спорный момент ввиду того, что у разных людей она проявляется по-разному. Однако общую тенденцию можно выделить и, пожалуй, настало то время когда можно достаточно смело говорить, что программисты всё же имеют свой особенный психологический портрет который обусловлен их профессиональной деятельностью.
Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно. 
Существует распространенное мнение, что «рядовому» PHP разработчику практически не нужно заботиться об управлении памятью, однако «заботиться» и «знать» всё же немного разные понятия. Попытаюсь осветить некоторые аспекты управлению памятью при работе с переменными и массивами, а также интересные «подводные камни» внутренней оптимизации PHP. Как вы сможете убедиться, оптимизация это хорошо, но если не знать как именно она «оптимизирует», то можно столкнуться с «неочевидными граблями», которые могут вас заставить изрядно понервничать.
