В публикации опишу подход к использованию контейнеров docker и make который я практиковал последние несколько лет в своих рабочих командах и личных pet-проектах. Подход сформировался в процессе поиска минималистичного и унифицированного способа запуска проектов на php. Чтобы любой разработчик мог в пару простейших команд получить рабочую копию для разработки, располагая только доступом к репозиторию, без бубнов, обновляемых инструкций и тимлида на соседнем стуле.

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

Тема не раз обсуждалась на хабре под разными углами. Как с высоты опыта старожилов, так и виде историй успеха/провала нововошедшых/"тут же вышедших".

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

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

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

Самое досадное, что повреждения коснулись системы регулировки скорости, что-то более крупное я бы смог починить самостоятельно, а эта новомодная электроника была очень плохо приспособлена к ремонту. Я не раз себя ругал, за то что взял электронный автомат, но пойди найди в наше время ракету с ручным механическим управлением. Комфортно конечно, но уж если что-то начинает сбоить, то сбоит самым нелепым и непредсказуемым образом, а чинить такие вещи самостоятельно в открытом космосе практически невозможно. И гарантии лишаешься. Разумеется, читатель может возразить, что сервисные боты вдоль всех космических трасс расположены на каждом парсеке. Но, вырываясь из метеоритной тучи, я вылетел с трассы в пустынный уголок, где никакого сервиса не было на несколько световых недель, а ждать помощи так долго я позволить себе не мог. Шпикачки были съедены ещё вчера, и кроме пары банок с ромовыми бабами, у меня оставался лишь килограмм сублимированных кнедлей, на которых долго не протянешь.

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

В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.

Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.

Я провел небольшое исследование и обнаружил что большинство публикаций по этой теме на habrahabr освещают тему участия (contributing), либо просто мотивируют каким-нибудь образом примкнуть к Open Source, но не дают исчерпывающей инструкции как правильно оформить свой проект. В целом в рунете, если верить Яндекс, тема освещена со стороны мотивации, этикета контрибуции и основ пользования github. Но не с точки зрения конкретных шагов, которые следует предпринять.

Так что из себя представляет стильный, модный, молодёжный Open Source проект в 201* году?

Задача публикации: доступно изложить способ организации иерархии исключений и их обработки в приложении. Без привязки к фреймворкам и конкретной архитектуре. Описываемый способ является де-факто стандартом в сообществе: он используется во многих серьёзных библиотеках и фреймворках. В том числе Zend, Symfony. Не смотря на его логичность и универсальность, формального описания предлагаемого подхода на русском языке я не нашёл. После неоднократного устного изложения концепции коллегам, родилась мысль оформить её в виде публикации на Хабрахабр.

В языке PHP, начиная с 5-ой версии, доступен механизм исключений. В актуальной, 7-ой, версии этот механизм был улучшен и переработан с целью единнобразной обработки разных ошибок при помощи конструкции try{} catch...

В стандартной библиотеке (SPL) PHP предоставляет готовый набор базовых классов и интерфейсов для исключений. В 7-ой версии этот набор был расширен интерфейсом Throwable. Вот диаграмма всех имеющихся в версии 7 типов (изображение — ссылка):

Один из аспектов профессии разработчика — посвящение профанов в особенности процесса разработки ПО.
С. Макконнелл, Совершенный код

• разработчикам принимающим аналогичное решение, чтобы взвесить за и против
• менеджерам «непростых» проектов, чтобы лучше понять причины и следствия технических проблем
• и, конечно, просто любопытствующим

• Низкая компетенция разработчиков, и что с этим можно поделать?
• Какие аргументы убедительны в глазах заказчика для нефункциональных изменений в проекте?
• Почему работа аналитиков и QA очень важна с точки зрения разработки в частности и для проекта в целом?

1. Главные достоинства и недостатки
2. Тестирование
3. Нюансы использования ActiveRecord
4. Сервис-ориентированный подход
5. Новшества языка
6. Расширение фреймворка