Какая-то «не здоровая пьянка» пошла последнее время на хабре про собеседования. Люди, хватит уже, нет ничего страшного и особенного в собеседованиях, я уже несколько лет провожу их с IT-шниками, и в 95% случаев это адекватные и приятные люди. Потому хочу поделиться с вами «дзеном» о том, как лучше проводить именно техническое собеседование, да и вообще оценивать навыки тех. специалистов, так как вопрос оценки компетентности технического специалиста может быть довольно сложным, особенно если вы не хотите проводить собеседование на 3 часа к ряду. С данной моделью вы вполне можете уложить тех. собеседование в 40-50 минут (а то и быстрее) и быть уверенным в решении на 80-90%. Если про оценку эмоционального интеллекта, базовой мотивации и просто уровня адекватности, информации довольно много, то вот про то, как эффективно оценивать технические навыки специалиста, зачастую, «кто в лес, кто по дрова». Данная статья может быть также полезна и тем, кто просто хочет эффективно расти как специалист, потому как именно их знания и рассматриваются.

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

Никогда не думали, а что если паттерны ООП спроецировать на работу программистов?

Singleton-разработчик
Разработчик с bus-factor=1. Как правило, один из «старожилов» проекта, который приложил руку ко многим компонентам и только он знает как эти части работают вместе. Практически «невыпиливаемый» из проекта, либо без него все начинает «работать как-то не так». По любому вопросу «как оно работает» всегда отвечает «да мне проще самому запилить» и запиливает.

Коллеги, у меня для вас есть замечательная новость, мы получили чудесный проект, его несколько лет писали неизвестные нам разработчики, адрес которых мы вряд ли узнаем (чтобы «поделиться обратной связью»), писали очень давно и не известно под чем, и нам предстоит его поддерживать и развивать. Проект сейчас находится на пике своей производительности и мы скоро упремся, любые неаккуратные изменения могут его положить, но мы будем его развивать. Ура!

Согласитесь, странно звучит? Как бред больного на голову программиста. Кто же любит legacy? Это же всегда говнокод (ведь только мы сами пишем идеально), в нем полно багов (а мы сами пишем без ошибок), ужасные решения (ведь только мы сами выбираем подходящую архитектуру), и почти всегда его сложно читать (ведь только мы сами пишем понятно и красиво).

Почти в каждом более менее динамическом проекте бывает возникает необходимость выполнять очереди задач в фоне (отправка email, обновления кеша, реиндексация поиска и т.д.). Job сервера (Gearman и т.п.) хороши, но для большинства простых задач они избыточны. Классическая реализация очередей в MySQL (при помощи SELECT … LOCK FOR UPDATE) при росте нагрузки со временем начинает приводить к проблемам с блокировкой. Потому, как это обычно бывает, пришлось написать свой «велосипед» для работы с фоновыми задачами, который бы «точно работал» и был предельно прост.

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

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

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

Я достаточно часто сталкивался с подобным мнением и не придавал ему особого значения, но когда женский коллектив нашей организации поздравил программистов с 23-м февраля по доброму назвав их «космическими войсками», решил всё же расставить определенные акценты в данном вопросе, т.к. одна из моих профессий связана напрямую с психоанализом. Да и баш уже не молчит.

Парадигма MVC во многом позволяет упростить поддержку кода за счет разделения логики и создания абстракций, однако часто, следуя принципу Thick Model & Thin Controller (он же Fat Model & Skinny Controller), разработчикам приходится упираться в краеугольный камень использования любого объекта-модели, а именно — в потребление памяти. Что особенно актуально при работе с моделями, которые реализуют ORM (или ActiveRecord паттерн).
В данной статье хочу вкратце продемонстрировать стандартные подходы к решению данной проблемы.

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

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

Сообщения твиттера позволяют использовать пользователей в качестве «живых датчиков». Инженеры из университета Rice и Motorola Mobility нашли способ замерять уровень взволнованности и активности фанатов, а также отслеживать ключевые моменты игр Национальной Футбольной Лиги (NFL) (прим.: речь идет об американском футболе). Программа, анализирующая твиты, может в течении нескольких секунд сказать когда произошел тачдаун, перехват или другой важный игровой момент, а также показать то, насколько фанаты взволнованы данным моментом.

На хабре уже имеется много информации по этому состязанию, однако вся она освещает отдельные моменты реализации, но не картину в целом. Постараюсь исправить это положение как можно более кратко, но в целом.
Данное описание предназначено для тех, кто что-то слышал о данном мероприятии, но всё желание что-то сделать отбила необходимость разбираться в тонкостях реализации. Пост состоит частично из перевода материалов с официального сайта, частично из анализа стратегий других ботов и чистой логики. Также в конце поста будет ссылочка на PHP-бота (чуть сложнее чем из starter-pack), который позволит вам попробовать собственные силы дописав имеющийся код. Официальный сайт состязания: aichallenge.org