Привет!
Я Генри, разработчик и техлид с опытом более 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

Привет, друзья!
Довольно долгий перерыв получился. Но этому есть причина. Платформа, на которой я вёл блог ранее, перестала меня устраивать. Не хватает импорта файлов из .md и нативной поддержки таблиц, которая есть в самом простом Markdown.
Поэтому я решил сделать собственную минималистичную страничку с поддержкой Markdown и возможностью дальнейшей кастомизации. "Яж разработчик", в конце концов.
Но как это бывает, простенький проект растянулся из-за нехватки времени. А писать что-то дальше на старом уже не хотелось.
За основу взял статический генератор Hugo, и GitHub actions в качестве инструмента деплоя, настроил сервер, прикрутил домен и сертификат, перенёс статьи в Markdown. Дайте знать, если нужно будет больше технических подробностей - сделаю отдельный пост.

Вот ссылка: blog.henrydev.me

Как всегда, буду рад обратной связи. Спасибо!

#blog

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

#lfe

Типы рендеринга веб-приложений

Сколько типов ренедринга веб приложений вы знаете? Создавая веб-приложения на протяжении многих лет, я понял, что даже опытные разработчики могут не знать всех подходов к рендерингу, которые используются сегодня. Эти знания помогают лучше разбираться в архитектуре современных приложений и осознанно выбирать тип, который подходит под конкретные задачи. Я изучил их и постарался структурировать знания в этой статье, как понял сам.

Server-Side Rendering (SSR)

SSR — это классический подход, при котором вся работа по рендерингу страницы происходит на сервере. Пользователь получает готовую HTML-страницу с контентом. При каждом переходе на новую страницу браузер отправляет запрос серверу, который формирует и возвращает новую страницу.
SSR подходит для сайтов, где важно SEO и актуальность контента (пр: новостные порталы).

Client-Side Rendering (CSR)

CSR предполагает, что браузер загружает минимальную HTML-страницу вместе с JavaScript, который отвечает за рендеринг всего контента. Данные подтягиваются из API через асинхронные запросы к бэку.
CSR выбор для приложений с высокой интерактивностью и сложным пользовательским интерфейсом (пр: сервисы).

Static Site Generation (SSG)

SSG генерирует HTML-страницы заранее на этапе сборки и размещает их на сервере. Такой подход подходит для сайтов с преимущественно статическим контентом.
SSG лучший вариант для сайтов с редко меняющимся контентом (пр: блоги, документация).

Incremental Static Regeneration (ISR)

ISR — это улучшение SSG, позволяющее частично решать проблему обновления контента. Если пользователь запрашивает страницу, которая ещё не сгенерирована или требует обновления, сервер обращается к API для генерации новой версии страницы и сохраняет её для последующего использования.
ISR идеален для больших сайтов с динамическим контентом, где важна производительность (пр: маркетплейсы).

Edge Side Rendering (ESR)

ESR переносит рендеринг на уровень инфраструктуры, ближе к пользователю, например, на edge-серверы CDN. Это позволяет сократить задержки и персонализировать контент.
ESR используется для персонализированных и высоконагруженных приложений (пр: e-commerce).

Progressive Hydration (Прогрессивная гидратация)

Этот подход оптимизирует CSR, активируя компоненты на странице поэтапно. Сначала загружается статический HTML, затем элементы интерфейса оживляются в зависимости от их приоритета.
Progressive Hydration оптимален для масштабируемых SPA, требующих высокой производительности.

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

#webdev #development #frontend

Henry Developer | Статья полностью