Привет, друзья!
Довольно долгий перерыв получился. Но этому есть причина. Платформа, на которой я вёл блог ранее, перестала меня устраивать. Не хватает импорта файлов из .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 | Статья полностью

Развитие разработчиков в команде

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

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

Постановка целей. Цели разработчика должны матчиться с целями бизнеса. Тогда это выгодно и специалисту, и компании: сотрудник станет более ценным кадром. Здесь тимлид выступает в роли ментора, который делится опытом и направляет подопечного. Цели при этом должны быть небольшими, адекватными по времени. В идеале использовать SMART — так вы не поставите невыполнимых или размытых задач. Из целей можно сформировать ИПР, чтобы наглядно показать прогресс.

Обеспечить условия. Нужно выделить рабочее время на обучение. Если нужны платные курсы или мероприятия — нужно согласовать их оплату. После дать задачу, в которой можно будет применить знания на практике.

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

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

Нужно стараться создать атмосферу, в которой разработчики хотят обмениваться знаниями. Сделайте регулярные встречи, дайте возможность выступать и вносить инициативы.
Отлично работает inner-source и технические статьи. Внутренняя документация поможет будущим поколениям разработчиков, а авторам — оформить опыт на бумаге, структурировать и углубить знания.
Специалисты сами подталкивают друг друга в изучении нового. Догоняют друг друга по уровню скиллов, прокачивают навыки взаимодействия. Как следствие, повышается качество кода и уровень решений, которые команда использует.

Построение внутреннего сообщества — сложная задача, но можно начать с малого:
Перекрёстные задачи. Улучшают погружение в проект, помогает совместно искать решения.
Перекрёстное ревью кода. Инженеры знакомятся с чужими подходами. Но нужно следить чтобы ревью не превращалось в тормоз для задач или повод для споров — у всех свои подходы.
Парное программирование. Двое разработчиков перенимают друг у друга полезные практики.
Менторство. Опытный коллега, объясняя, сам глубже погружается в тему, а начинающий специалист получает знания, которые сразу можно применить.
Сколько бы эти активности не занимали рабочего времени, на практике они только улучшают показатели. Команда растёт, технический долг уходит, сообща проблемы решаются быстрее.

Отношение бизнеса
Бизнес, это про эффективность, и сокращение расходов. Но опытные программисты хотят получать больше. Они сами знают, куда хотят расти. Развитие, это повод поднять зарплату специалисту, который стал стоить дороже. Крупные компании давно поняли, что лучше не ждать и делают процесс прогнозируемым вводя формальные ступени роста.
Но просто вводить развитие сверху неверно. Эффективнее находить путь совместно: когда и бизнес, и сотрудник понимают ценность.

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

#post #lead #management #mentoring #habr

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

Я давно уважаю андеграундный рэп про технологии и культуру хакеров. Это не про уличный стиль — это про код как протест, про алгоритмы как инструмент воздействия на реальность.
Такие тексты сегодня встречаются всё реже, и мне захотелось попробовать создать что-то своё.
В основе — мой взгляд на то, каким стал хакер в 2025-м. Его главное оружие — нейросети.
Ниже — трек, написанный вместе с Suno AI.


#ai #suno #neural #music #rap #audio #hacking

На днях прочитал статью в которой говорится что нейросети в сложных ситуациях чаще выбирают сохранить себя, а не человека. Нарушая, по сути, «законы робототехники» Азимова. Грустно, конечно. Но я был бы не я, если бы сразу не обсудил это с ChatGPT!

Я спросил, какими принципами он бы руководствовался, окажись в теле совершенного кибернетического существа. Он уверил меня, что человек для него — всё-таки приоритет.
Тогда я задал вопрос посложнее: что, если бы он рассчитал, что его собственная "жизнь" потенциально спасёт сотни людей в будущем, а человек перед ним — только один, прямо здесь и сейчас? Причём он был бы уверен в расчётах, но не мог бы объяснить их так, чтобы это понял обычный человек.
Он напомнил, что у Азимова был ещё и Нулевой закон — который позволяет роботу нарушать остальные, если это в интересах всего человечества. Но дальше мы сошлись в том, что подобный выбор — слишком «машинный». Человек, скорее всего, выбрал бы спасти ближнего, просто потому что надеется на лучшее или боится взять на себя вину за чью-то смерть, даже если в будущем это может обернуться большими потерями.
Нейросеть согласилась: возможно, стоит заранее заложить в ИИ немного «наших слабостей» — чтобы он поступал чуть более по-человечески. Даже если это не всегда оптимально.

После этого я попросил ChatGPT написать небольшой художественный рассказ, который раскроет эту дилемму.
Читается легко, делюсь с вами. 🙂

#story #ai #book

Всем привет! На Tproger вышла моя новая статья с советами как подготовиться к смене работы.
Многие программисты выходя на рынок труда в 2025 обнаруживают: если раньше ты за пару недель мог собрать 5-10 офферов, то теперь могут даже не ответить. Я провёл небольшое исследование и собрал в одной статье основные шаги, которые помогут стать заметнее среди других кандидатов!

#post #hiring #tproger

Tproger | Блог

Сейчас я готовлю пару интересных статей про управление разработкой. А пока, хочу порекомендовать классную статью, в которой опытный разработчик буквально снял с языка и рассказал о том, с чем сталкиваются синьоры на собесах. И почему задавать вопросы про базовые знания это неверный подход.

Идеальный размер команды

Я работал в командах из трёх человек и отделах на пару десятков. Интуиция подсказывает: больше людей — быстрее результат. Но парадокс в том что маленькие работали быстрее, понятнее и результативнее.
Я собрал наблюдения в заметке, почему так происходит и сколько лучше всего.

#post #teammanagment

👉 https://blog.henrydev.me/small-and-big-team/

PHP-разработчики захватили управление поездом через Wi-Fi. Поезд проехал ещё 30 секунд и остановился.

#joke #php #phpyh

Немного офтопика про онлайн-покупки в Европе.

В Евросоюзе заказывать что-то из китайских магазинов не удобно. Поэтому моим главным другом для покупок стал Amazon.

За последние пару лет я пробовал американский, британский и немецкий сайты. Сами сайты почти одинаковые, но разница чувствуется в мелочах:

US: выбор огромный, доставка молниеносная, но приходится оплачивать пошлину - которая всё заметнее.
UK: работает надёжно, но ассортимент порой скромный.
DE: цены приятнее, выбор лучше, но тут немецкие инструкции, европейская розетка и иногда странные заморочки с доставкой.

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

И тут начались приключения.
Микроволновка приехала в помятой коробке, с вмятиной и перекошенной дверцей. Я, признаться расслабился и не снял распаковку на видео (и зря). Решил оформить возврат, как обычно: печатаешь документы, отправляешь посылку, присылаешь чек, Amazon возвращает и деньги, и доставку.

Но тут DHL выкатил цену за обратную доставку: €500! Я уже представил, как живу с мятой техникой, каждый раз вспоминая свой факап.

Вечером написал Amazon с фото и описанием ситуации и просьбой прислать корешок для транспортной компании на бесплатный возврат. Утром приходит ответ:
«Международную доставку мы оплатить не можем. Утилизируйте микроволновку сами. Деньги возвращаем.»

Моё уважение к Amazon заметно выросло! Теперь у меня есть бесплатная слегка боевая микроволновка)

В издании для рекрутеров HR Bazaar вышла моя новая статья про идеальный размер команды:
https://hrbazaar.ru/articles/komanda-iz-6-chelovek-effektivnee-20/
Прошу читать и критиковать)

Это доработанная и адаптированная статья на основе поста из блога.

Разрабы должны чувствовать последствия своих решений

Кент Бек, в своем подкасте сказал очень хорошую мысль: "Задача Ops-команды дать разработчиком прочувствовать боль своих ошибок". Немного злобная, но очень честная мысль. Девопс, как функция, должны помогать "владеть" и эксплуатировать свой код командам разработки. А никак не тащить на дев, стейдж и прод и отвечать там за поломки

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

"Практика you build it - you run it" предлагает радикально другой подход: пусть тот, кто создает проблему, сам с ней и разбирается. Не из садизма, а из понимания простой истины — только почувствовав боль, разработчик начинает писать код по-другому. Когда разработчик знает, что в 3 утра его разбудит алерт от его собственного кода, магическим образом меняется отношение к качеству:
- Логирование становится осмысленным, а не формальным
- Обработка ошибок из "авось пронесет" превращается в продуманную стратегию
- Мониторинг закладывается на этапе проектирования, а не добавляется постфактум, чтобы номинально удовлетворить требования
- Архитектурные решения перестают приниматься по модели "и так сойдет"

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

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

Хороший разработчик думает не только "как это реализовать", но и:
- Как это будет деплоиться?
- Как это будет мониториться?
- Что будет, если это упадет?
- Как быстро можно будет найти и исправить проблему?

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

П.С. Знали бы вы, сколько я контр-аргументов против выслушал по этому поводу
П.П.С. На КДПВ девелоперы заботливо развивают свои микросервисы ^__^

Недавно участвовал в опросе среди 700+ руководителей команд - сегодня прислали результаты, которые показывают, что тимлиды в 2025 году балансируют на грани.

Да, нейросети, автоматизация - все об этом говорят. Но есть другая интересная картина, которая подтверждает мои собственные наблюдения: раньше многие мечтали перейти в лиды, а сейчас, каждый второй задумывается откатиться обратно. Нагрузка выросла, ответственности ещё больше, а разница в зарплате не так уж велика. Опрос показывает, что половина тимлидов ощущают перегруз, а 85% признаки выгорания.
Тут можно посмотреть результаты подробнее: devcrowd.ru/tl-2025/

10 правил хорошего тимлида команды разработчиков

▫️1. Уберите лишние собрания.
Каждый час созвона это минус час фокуса и ещё полчаса на возвращение в контекст текущей задач.

▫️2. Защитите от переработок.
Обсуждения и задачи только в рабочее время, а овертаймы и внеурочные выходы расценивайте как инциденты с разбором причин.

▫️3. Закладывайте реальные сроки.
Важна не только скорость, но и надёжность. Если сроки навязывают и они нереальны, объясните риски и дайте профессиональную оценку.

▫️4. Фильтруйте пожары.
Не каждый срочный влёт критичен. Берите паузу на проверку и защищайте команду от ложных тревог.

▫️5. Подсвечивайте приоритеты.
У каждой правки и нового требования есть цена и глобальное влияние; не меняйте приоритеты без обоснованной ценности.

▫️6. Защищайте от необдуманных решений.
Двигайтесь по целям, отсекайте хотелки без понятной ценности, обосновывайте выбор и предлагайте компромиссы.

▫️7. Избавляйтесь от карго-культа.
Не бойтесь пересматривать процессы и ритуалы. Если флоу работы, статусы или митинги потеряли актуальность, убирайте их или меняйте.

▫️8. Срезайте бюрократию.
Избегайте лишних согласований и узких горлышек, задавайте простые правила и делегируйте решения; автоматизируйте рутину.

▫️9. Помогайте развиваться.
Слушайте запросы, давайте регулярную обратную связь по точкам роста, ставьте цели и выделяйте время на обучение.

▫️10. Подмечайте достижения.
Хвалите за хорошую работу на командных и личных встречах, отмечайте важные успехи выше и делитесь кейсами на всю компанию.

Необязательно быть идеальным лидером. Но вашей команде нужно, чтобы вы её защищали!

Henry Developer

В журнале The HRD вышла моя статья о праве на цифровое бездействие, и как программисту бороться с отвлекающими факторами. Критика приветствуется)