Привет!
Я Генри, разработчик и техлид с опытом более 20 лет в ИТ. За эти годы прошёл путь от junior-разработчика до руководителя команды. Создаю проекты, руковожу командой, помогаю развиваться разработчикам и начинающим тимлидам расти и справляться с трудностями. Иногда пишу статьи на волнующие меня темы.

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

Мои страницы: Блог, Сайт, LinkedIn, Twitter (X), GetMentor, Solvery

Про опыт у джунов.
Мои первые шаги в ИТ пришлись на времена, когда требования к программистам был самые поверхностные. Сейчас же, ситуация сильно поменялась. И если с наймом сеньоров и мидлов всё более-менее понятно, то джунам приходится буквально биться за “место под солнцем”, чтобы получить первый опыт!
Читать дальше

#hiring #junior #post

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

#php #post

Небольшая статья про то как быстро развернуть локальную БД в Docker.
Ничего такого, чего не знает опытный программист, просто короткий гайд для быстрой базовой настройки.

#code #docker #db #guideline

Простой PHP сервер
Набросал небольшой бойлерплейт, чтобы быстро поднимать пыху и отлаживать скрипты локально.
GitHub: simple-php

По сути, это Dockerfile с минимальным набором программ, Composer, а также Makefile для запуска одной командой: make up.

Замечания и pull-ревесты приветствуются 🙂

#code #docker #php

Шпаргалка по сбору требований системного дизайна

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

1. Функциональные требования (Functional):

- Какую задачу будет решать система, какие у неё будут функции.
- Бизнес требования которые решаются этой системой. Какой ожидается результат.
- Взаимодействие с пользователем. Как пользователь будет использовать приложение. Например, через UI, API или командный интерфейс.
- Требования к интерфейсу. Юзабилити, доступность для разных людей, документация, поддержка, обучение.

2. Производительность и нагрузка (Performance). Сколько ожидается пользователей и запросов от них (каких). Это нужно, чтобы рассчитать предполагаемый RPS.

3. Объём данных (Capacity). Сколько данных будет храниться и сколько данных будут генерировать пользователи. От этого зависит тип и размер БД.

4. Задержка (Latency). Какая допустима задержка в ответах. Вполне очевидно, что например для конвертера больших файлов - задержка будет не так важна, как например в мессенджере, где данные нужно получать в реальном времени.

5. Гео-распределённость (Distribution). Понадобится ли шардировать данные по регионам, а также задействовать кеширующие сервера (CDN).

6. Надёжность (Reliability) описывает, как часто система выходит из строя, тогда как доступность (Availability) — это процент времени, когда система доступна для использования.

7. Отказоустойчивость (Fault tolerance). Как система должна реагировать на сбои в сети или аппаратном обеспечении. Насколько важна целостность данных и как быстро они должны восстанавливаться после сбоя.

8. Масштабируемость (Scalability). Должна ли система подстраиваться при увеличении нагрузки. Будет ли она постоянно испытывать высокие нагрузки или она будет чаще простаивать и нагружаться только раз в сутки. Какую максимальную нагрузку система должна выдерживать.

9. Совместимость (Compatibility). Будет ли система интегрироваться с другими системами через API? Поддерживает ли она обратную совместимость с предыдущими версиями.

10. Безопасность (Security). Требуется ли аутентификация и авторизация. Какие права доступа у разных типов пользователей. Нужно ли шифровать данные при передаче (TLS) и хранении (AES)? Какие данные.

11. Юридические и региональные ограничения (Restrictions). В каких странах будет использоваться система и какие правовые нормы важны (например, GDPR, HIPAA). Нужно ли соблюдать промышленные стандарты.

12. Срок жизни и поддерживаемость (SLA). Какой жизненный цикл у приложения, сколько времени планируется его поддержка после релиза. А также, есть ли специфичные требования к фреймворкам, языкам, архитектуре. Например, предпочтение может быть отдано популярным технологиям для упрощения найма разработчиков. Либо нужен сайт для разового мероприятия, и дальнейшая поддержка и развитие не потребуется.

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

#systemdesign #requirements

Henry Developer | Блог

Всем привет! На днях Хабр предложил поучаствовать в челлендже помощи в поиске работы для тех у кого есть страхи на собеседовании и другие проблемы с развитием карьеры. Теперь ссылка на мои ресурсы красуется в редакторской колонке Хабра. Приятно)

#hiring #interview #habr

Не зря я вписался в этот карьерный челлендж! Он ещё не начался, но истории ребят показывают тревожную тенденцию на рынке труда в IT.

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

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

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

#hiring #longread #junior

Каждый раз, когда я помогаю кому-то как ментор, я вижу, как в их глазах загорается огонёк — понимание того, куда двигаться дальше. Это вдохновляет и наполняет уверенностью.

Иногда менти оставляют отзывы. Порой приятно почитать. Эти слова помогают мне лучше осознавать ценность своего опыта.

https://blog.henrydev.me/mentee-feedback

#mentoring@henryhdev

Разработчик не должен спрашивать разрешения на то, чтобы:

• писать понятный и поддерживаемый код
• улучшать код через рефакторинг
• документировать решения
• покрывать код тестами

Это естественная часть рабочего процесса, так как служит инвестициями в будущее продукта, в конечном итоге снижая издержки и ускоряя разработку!

#code #refactoring

#hiring #habr #mentoring

Поучаствовал в обсуждении мифов о причинах отказов на собесах с экспертами Хабра и том как это выглядит с обратной стороны!
https://habr.com/ru/companies/habr_career/articles/868400

Расскажите, что вы об этом думаете, и согласны ли со мной.

#habr