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

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

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

В какой‑то момент я осознал, что у меня много источников данных, есть мощная машинка в виде MacBook Pro M4 Max со 128 гигами оперативки, и надо как‑то это объединить, чтобы эффективно использовать. Всё же такую покупку согласовывали под использование ИИ, а не просто так я решил потратить деньги.

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

В целом Hermes выглядел идеально: есть память, скиллы, которые он пишет сам (ну и ты, конечно, тоже можешь написать), простота установки и использования, крон‑задачи. В общем, полный комплект.

Я радовался, что всё работает. Потом понял, что это была видимость работы, и разочаровался. Пересмотрел подходы и переизобрёл то, о чём, естественно, писали не раз, но зато у меня всё стало работать.

В статье не буду рассказывать о том, как установить Hermes, подключить Codex и наслаждаться. Будут локальные модели, виртуалки, шишки и преодоление в истинно инженерном стиле.

Я долго хотел собрать NAS сам, но в итоге выбрал готовое решение. Рассказываю, где ломается идея «сделаю дешевле», почему роутер с Docker — это не сервер, и как я пришёл к устройству, которое закрывает сразу всё: хранение, сервисы и эксперименты.

Я собрал минимальный набор практик, без которых микросервис очень быстро превращается в «чёрный ящик»: логи, трассировка, метрики, конфигурация, feature flags, тестирование и чуть-чуть документации. Это не теория — это вещи, которые я выстрадал, пока делал Go-шаблон для коллег, переходящих после Ruby/PHP, и пытался сделать так, чтобы сервис было реально удобно запускать, отлаживать и поддерживать.

Внутри — простые объяснения, почему эти штуки окупаются, и примеры на Go: как разделить логи и связать их с trace_id, как руками добавить span, какие метрики имеет смысл считать, как организовать конфиг, зачем OpenFeature, почему testcontainers — это не боль, и почему Makefile иногда экономит больше времени, чем очередной «идеальный рефакторинг».

Мне кажется, что уже есть сотни разных статей на эту тему, но каждый раз мне чего-то не хватало. Поэтому я решил написать свою статью, в которой покажу, как я реализую авторизацию и аутентификацию в своих проектах. Это именно гайд: вы можете взять готовый код и адаптировать его под свои нужды. В рамках статьи будут использоваться Ory Hydra и Ory Kratos, Apache APISIX в качестве API Gateway и несколько микросервисов на Golang. Всё это будет работать в Docker, чтобы вы могли легко запустить и поиграться.

В первой части мы развернули базовый стек для сбора метрик, логов и трейсов и интегрировали его с приложением на Laravel. Теперь покажу настройку Observability на примере простого Golang-приложения — настроим в нём структурированные логи, распределённый трейсинг и метрики, а также интегрируем с нашим стеком.

Это в какой-то степени продолжение моей статьи — История создания идеального Docker для Laravel. В ней я рассказывал о том, как собрал идеальный Docker-образ для Laravel с Nginx Unit. Это был один из первых шагов по оптимизации моей инфраструктуры. Как я уже упоминал, у меня есть несколько pet-проектов, запущенных на VPS в docker-compose, и я хотел не только отслеживать их состояние, но и прокачать навыки в области Observability.

Казалось бы, упаковать PHP в контейнер и настроить GitHub Actions - дело пяти минут. Но как часто бывает, реальность оказалась сложнее. Это история о том, как я вернулся к разработке на PHP и решал накопившиеся проблемы с деплоем Laravel-проекта. О том, как готовил Docker-образ, несколько раз переписывал процесс деплоя, находил компромиссы там, где это было возможно, и полностью перестраивал архитектуру там, где компромиссы были неприемлемы.

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

Если у нас простая задача, например отправлять уведомления по вызову и событиям, то в целом проблем нет (только нюансы реализации). Но если мы хотим один или несколько микросервисов, или целое приложение разделить на serverless функции - тут начинаются интересные вещи. Нужно так спланировать свое приложение, чтобы оно было разделено по функциям, при этом его легко можно было масштабировать и расширять.

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

Привет, Хабр! Пол года назад на AnalystDays #18 я рассказывал про API-контракты, и доклад вызвал большой интерес у аудитории. Пока видео не опубликовали, решил адаптировать материал в формат статьи.

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

Недавно я опубликовал статью OrbStack: Почему я забыл про Docker Desktop, которая вызвала оживленную дискуссию в комментариях. Основные вопросы возникли вокруг производительности различных Docker-подобных решений. Мои аргументы, основанные в первую очередь на личном опыте использования, оказались недостаточно убедительными.

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

Работая на MacBook с Docker Desktop, я часто сталкивался с тем, что система становилась менее отзывчивой, особенно при запуске нескольких контейнеров одновременно. Высокая нагрузка на CPU и память заметно влияла на время автономной работы.

Но недавно я наткнулся на OrbStack, и это изменило мой рабочий процесс настолько, что я решил поделиться своим опытом. Спойлер: теперь мой MacBook не превращается в печку, батарея держится дольше, а Docker-контейнеры летают.

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

Недавно вышла статья, мимо которой я не мог пройти — "Программист не должен решать задачи бизнеса". Неожиданно мой комментарий вырос до мини-статьи. Я не согласен с мнением автора статьи, все сказано ниже ИМХО, с удовольствием подискутирую в комментариях. Сразу замечу, что я веб-разработчик, и все примеры я привожу в контексте своего опыта.

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