В подкасте мы поговорили с Александром Валялкиным, сооснователем и core-разработчиком VictoriaMetrics — одного из самых популярных инструментов для мониторинга, конкурирующего с Prometheus.
Разобрали, как программисту стать предпринимателем, обсудили, как создать продукт, который нужен рынку, и где искать первых клиентов.

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

https://youtu.be/8xkCykuJwKs

Альтернативные площадки ВК Видео | Аудио
https://youtu.be/8xkCykuJwKs

Пару месяцев назад я рассказывал про то что мы начали активно снимать для ютуба Хекслета. Спустя какое-то количество попыток у нас начало получаться выдавать интересные ролики и одним из них я хочу поделиться: “Почему компании не берут джунов без опыта работы, и что с этим делать?” Это видео длинной почти полтора часа, для ребят, которые хотят понять, что же такое коммерческий опыт. Чо как вам?

p.s. И не забудьте скинуть видос знакомым, кто только учится
https://www.youtube.com/watch?v=Iq0vqta4uq8&lc=UgxFdDrWJqI8xI2ypKF4AaABAg

Крах Vibe Coding: как ИИ-помощник едва не уничтожил стартап. Лео Мартинес, 30-летний предприниматель без формального опыта в программировании, сидел в своей квартире в Майами с панорамным видом на город. В его руках была не клавиатура с кодом, а ноутбук с открытым редактором Cursor — ИИ-инструментом, который помогал ему писать код. Так родился VibeFlow — SaaS-платформа, позволяющая создавать сайты, просто описывая их словами. Этот метод, который получил название "vibe coding", завоевал популярность, а Лео делился успехами в соцсетях, набирая тысячи лайков и репостов.

Но 17 марта 2025 года его мечта едва не рухнула.

Утром Лео, наслаждаясь кофе, заметил поток тревожных уведомлений: ошибки API, превышенные лимиты, пользователи получали премиум-доступ бесплатно. В панике он написал в X (бывший Twitter):
"Ребята, меня взломали. Кажется, меня наказывают за ‘vibe coding’."

Ответы не заставили себя ждать. Один из пользователей предположил SQL-инъекцию:
"Если у тебя в базе появились случайные данные, это может быть SQL-инъекция. Любой может войти под логином ' OR 1+1=2 --."

Лео похолодел. Он почти ничего не знал о SQL-инъекциях, но понимал, что безопасность данных пользователей оказалась под угрозой.

Без сна и отдыха он пытался исправить ситуацию, следуя подсказкам Cursor и советам комментаторов. Он сбросил API-ключи, вынес их в переменные окружения, добавил аутентификацию. Затем закрыл доступ к API для неавторизованных пользователей и ужесточил CORS-настройки.

Но интернет был безжалостен. На Reddit его высмеивали:
"Безопасность? Просто доверяй вайбу."

Лео сдержал злость и написал:
"Я должен был просто молчать. Спасибо тем, кто действительно помогает. Сделаю выводы."

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

Vibe coding дал ему возможность создать продукт без знаний программирования, но он же и стал причиной его проблем. Теперь каждый сгенерированный Cursor фрагмент кода казался ему потенциальной уязвимостью.

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

Если вы думаете, что я решил потренироваться в написании повестей, то нет, это реальная история чувака, который потеет над своим проектом прямо щас. Я чувствую эти вайбы.

Ссылки: Телеграм | Youtube | VK

https://x.com/leojr94_/status/1901560276488511759

Подумалось, что забытый всеми HATEOAS, без которого любой REST это недоREST с точки зрения идей создателя, может наконец-то стать востребованным из-за AI агентов, которые сами рыскают в поиске информации по интернету. Навеяно выходом протокола https://www.anthropic.com/news/model-context-protocol

В подкасте мы поговорили с Валентином Ульяновым — фронтенд-разработчиком.
Разобрали, как CSS за последние годы превратился в полноценный инструмент для создания сложных интерфейсов, и обсудили его современные возможности.

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

https://youtu.be/mmmmllrf3ws

Альтернативные площадки: ВК Видео | Аудио
https://youtu.be/mmmmllrf3ws

📢 Телетекст, посвященный обработке ошибок в Go
Когда: 27 марта 14:00 мск
Где: в сообществе в телеграме
⠀
ПРИНЯТЬ УЧАСТИЕ
⠀
Почему в Go нет исключений в классическом понимании? Как правильно обрабатывать ошибки? Эти и другие вопросы обсудим с Валентином Чащиным, руководителем отдела серверной разработки Go в ecom.tech (ex. Samokat.tech).
⠀
🎁 Спикер будет публиковать доклад в текстовом формате. Вы сможете читать его в своем темпе, оставлять комментарии и задавать вопросы. Автор самого интересного вопроса получит в подарок дни доступа к платформе.
⠀
Обязательно зарегистрируйтесь в боте, чтобы принять участие и получить возможность забрать подарок.

Пропал на неделю, потому что как не в себя коммитил в code-basics.com
В общем я давно хотел добавить ассистента, который бы помогал учиться. Неделя тыкания в openai, изучение либ для бека, фронта, подключение стримминга (привет ActionCable), создание утилиты для загрузки курсов а асистента. В общем проделан большой путь и получилось вроде как неплохо.

Отдельно написал загрузчика курсов в асситенты. Писать было одно удовольствие, зацените код https://github.com/hexlet-basics/hexlet-basics-assistant

Что по пути узнал и чему научился:

⁃ В openai внутри есть RAG, соответственно считай готовая база куда надо просто вгрузить данные, дальше все работает само.
⁃ Работу со стримами для подготовки файлов мне полностью сделал chatgpt, так как либы в js не умеют в последовательную запись (либо устарели)
⁃ Количеством параллельно обрабатываемых файлов с уроками можно рулить через пакет p-queue, очень простая и полезная либа

Вот так работает:

➜  hexlet-basics-assistant git:(main) make assistant-load L=css
bin/dev.js load css
Repository: https://github.com//hexlet-basics/exercises-css
Clone to: /var/folders/mk/qlh1ntvj27581bntpj_gx9qh0000gn/T/hexlet-basics/exercises-css
Cloning repository...
Repository cloned
Directory for prepared files: /var/folders/mk/qlh1ntvj27581bntpj_gx9qh0000gn/T
css-10-basics-10-introduction.txt
css-10-basics-20-connection.txt
css-10-basics-35-basics-style.txt
css-10-basics-30-style.txt

На самом code-basics подрубил либу ruby-openai и соединил ее со стримингом через ActionCable. Шок в том, что этот код мне полностью написал chatgpt и он оказался рабочим с первого раза. Как фронт так и бек. Правда сначала я попробовал работать через ActionController::LIve, но уперся в то что он рвал коннекты и был не надежен. С ActionCable я до этого не работал, но готовая реализация получилась за час.

На фронте я потратил пару дней на либу ai/sdk от Vercel. Все проклял, у них вроде как все есть и бек с фронтом дружат из коробки. Но там свой хитрый алгоритм, который не доописан, поэтому я долго не мог добиться того чтобы с бека приходило все как надо (он мешал сообщения). В итоге оно еще и не работает с ws, поэтому пришлось chatgpt просить написать реализацию для ActionCable и он сделал это сходу. При этом я полностью перерыл исходники этого sdk и с помощью chatgpt разобрался в его кишках.

По пути выяснилось две проблемы:

⁃ На фронт надо передавать дельты без обработки, а то теряются \n и потом на выводе сломанный маркдаун
⁃ ActionCable асинхронный поэтому чанки путаются, пришлось дополнительно внедрять нумерацию и выпрямления порядка

Вот тут можно посмотреть исходник: https://github.com/hexlet-basics/hexlet-basics/blob/8d83e74d398b47571997b4d04eef1b010cedbf55/app/javascript/components/Chat.tsx

Ну и затестите как оно работает: https://code-basics.com/ru/languages/javascript/lessons/logic-combine-expressions

p.s. там в процессе еще немного секьюрити в порядок привести надо, я этим занимаюсь :)

В подкасте вместе с Ириной Назаровой (CEO «Злых марсиан») мы разобрали, почему модель Open Core стала одним из доступных способов для разработчиков запустить собственный бизнес без чрезмерных инвестиций в маркетинг и продажи.

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

https://youtu.be/OY62kYMdM4M

Альтернативные платформы: ВК Видео | Аудио
https://youtu.be/OY62kYMdM4M

Чот я завалился на первом вопросе у ai помощника для подготовки к собесу. Похоже с фронтендом придется завязать

Принцип на все времена: Command-Query Separation

CQS очень простой принцип программирования, применение которого встречается на каждом шагу. Обычно его формулируют так: “задавая вопрос, не изменяй ответ”. Представьте что у вас есть функция, которая проверяет валидность объекта user.isValid(). По смыслу эта функция проверяет данные по каким-то правилам и возвращает true/false.

Может ли она что-то менять? Большинство скажет что это не логично и будет право. Она не должна ничего менять. На практике же, это происходит тут и там. В тех же Rails, вы легко встретите внутри модели колбек before_validation, в котором можно сделать любое изменение, которое сработает на вызов valid?. И этим часто пользуются, я был свидетелем, как в коде удалялись связи у пользователя. Но тоже самое встречается налево и направо у программистов во всех языках.

Однажды, когда я собесил человека на наставника в Хекслет, мы как-то по пути выяснили, что у них там в коде во время запроса каких-то опций, они удалялись из списка опций, мы обсудили этот момент, я чуть-чуть рассказал про CQS и разработчик мне ответил, что после разговора пойдет переписывать код :)

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

Кстати да, это правило распространяется на все вокруг. Именно поэтому в HTTP существует GET, который можно кешировать так как он сам не меняет данные (но данные могут поменяться по другим причинам), а POST всегда меняет, поэтому кеширование к нему не применяется.

Буквально недавно мы разговаривали с Тагиром и он поделился тем как в Java работает форматирование дат. Оказалось, что в Java есть объект SimpleDateFormat, и он непотокобезопасен. Почему? Потому что метод, который вроде бы просто форматирует дату в строку, на самом деле меняет внутреннее состояние объекта. И если два потока одновременно вызовут .format(…), то они могут получить некорректный результат. Это классический пример нарушения CQS: метод, выглядящий как query (просто возвращает значение), внезапно ведёт себя как command — вносит изменения.

В результате приходится либо каждый раз создавать новый SimpleDateFormat, либо оборачивать его в ThreadLocal, либо использовать DateTimeFormatter из более нового API, который как раз спроектирован с учётом CQS — он ничего не мутирует.

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

Но это что касается вопросов. А что насчет команд? Тут уже не так очевидно, почему если мы выполняем действие (`setSomething()`, doSomething(), то данные лучше не возвращать?

Во-первых, это снова вопрос читаемости и предсказуемости. Метод с названием deleteUser(id) должен просто удалить пользователя, а не возвращать его профиль. Когда действие возвращает что-то, разработчики начинают полагаться на это значение: передавать его дальше, использовать как флаг, делать выводы.

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

Это не значит, что действия никогда ничего не возвращают. Иногда они могут вернуть, например, true или false, чтобы явно показать успех или неудачу. Более того, в некоторых ситуациях невозможно соблюдать CQS, например, при открытии файла на запись (создается файловый дескриптор).

Ссылки: Телеграм | Youtube | VK


p.s. Признавайтесь, писали такой код?

Смотрите что я вам принес. Отлично поболтали с Мурычем про js и программирование в целом. Деды бухтят https://www.youtube.com/watch?v=wv_qgOI60ao

Альтернативные ссылки: Аудио | vk

Как программист, я больше всего люблю:

- Удалять код, а не добавлять его
- Уменьшать количество используемых систем
- Заменять кастомные решения, на стандартные
- Использовать готовые решения, вместо написания своих
- Принимать административные решения, а не технические

В этом выпуске мы поговорили с Петром Зайцевым из Percona, который раскрыл историю и эволюцию популярных баз данных: MySQL, Postgres, MariaDB и других решений. Обсудили, как MySQL оказалась в руках Oracle и к чему это привело, как возникли форки вроде MariaDB и почему в итоге всё чаще стали выбирать Postgres. Пётр также рассказал, почему баз данных становится всё больше, как бизнес-модель и «идеология» вендоров влияют на то, что мы видим под капотом, и почему он продолжает верить в open source-подход.

youtube.com/watch?v=TgT7fjyzZzY

Альтернативные ссылки: Аудио | vk

Ух, последнее время навалило и я плотно занялся разработкой платформы Хекслета спустя несколько лет, после того, как я перестал писать туда код. На днях мы делаем большой релиз с выкаткой ИИ-ассиснта вроде того, что я сделал в code-basics.com. Хочу поделиться несколькими историями, которые в процессе возникли и как ИИ немного поменял мой подход к работе.

Удаление Docker Compose

Возможно вы скажете что я сошел с ума, но упрощая одно, Docker Compose делает сложным многое другое. Работа редактора, постоянное переключение внутри/снаружи (опять же история команд), сложности с сервисами (например интеграционные тесты), сложности с рестартом (когда это происходит по внутренним причинам а не снаружи). Все это сопровождает работу в Compose каждый день, а сетап окружения, по факту, делается один раз, в самом начале. Поэтому лучше один раз потратить чуть больше времени, зато потом не париться. Тем более сейчас все не так уж сложно: mise, overmind, caddy + базы и другие штуки прямо в докере, вместе работают как надо. Даже обвязка в виде команд занимает меньше строк чем docker-compose конфигурации:

# Procfile.dev
webserver: make services-webserver-run
vite: make services-frontend-run
app: make services-app-run
jobs: make services-jobs-run

В общем сначала я сделал это на code-basics.com, теперь мы это делаем и на репе Хекслета

Замена старья на Chatgpt

В коде наших проектов, как и во многих других, очень много мелких изолированных задачек, которые не всегда можно решить с помощью готовых библиотек. Например автокомплит для серверного html с поддержкой нужного UI, небольшой markdown редактор для разных textarea (крупные не подходят) с поддержкой bootstrap, все это либо отсутствует и надо пилить самим, либо крайне устарело. Подобные штуки редко поддерживают постоянно.

Я всегда избегал писать все это самостоятельно и мы долгое время были на устаревших либах, переодически вставляя туда костыли. А тут я попробовал просто генерить эти штуки. И пошло, за короткое время мы выкинули кучку либ, которые годами не обновлялись, при этом получили на каждую задачу по одному файлу от 50 до 150 строк, которые почти целиком сделал chatgpt.

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

Такая же история у меня была с интеграцией @sdk/ai от vercel. Я потратил целый день пытаясь его завести, мне даже пришлось полностью перелопатить его кишки в итоге я не смог его нормально завести для своих задач (смог, но с большим количеством подпорок). В конце я просто плюнул и сгенерил себе react hook, который делает все нужное (коммуникация с сервером, отправка прием данных). Посмотрите какая красота: https://github.com/hexlet-basics/hexlet-basics/blob/main/app/javascript/hooks/useAssistantStream.ts

Я не уверен что решился бы сам его писать. Не потому что не могу, а потому что не хочу тратить на это время. А щас это перестало быть проблемой.

Ссылки: Телеграм | Youtube | VK

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

Выпуск про тимлидов уже доступен для просмотра. Вы узнаете, как устроена настоящая командная динамика, что делать, если «всё рушится», и почему работа тимлида — это не про власть, а про ответственность. Не пропустите — разговор откровенный, местами жёсткий, но крайне полезный для всех, кто хочет расти в IT.

https://www.youtube.com/watch?v=_qJ_rU8-S90

Альтернативные ссылки: Аудио | vk

Универсальный стек для работы без Docker Compose

Удивительное рядом. Как оказалось, многие разработчики зашли в разработку когда в их проекте уже был Docker Compose и они не видели других способов работы. Когда-то я рассказывал как перейти на Docker Compose, а теперь пришла пора говорить о том, как работать без него :)

Docker Compose, в первую очередь, нужен для унификации среды разработки, чтобы сетап был единым независимо от того, где вы его разворачиваете и что там на машине было установлено. Как ни странно, все это было и до него, например через Vagrant (Кто еще застал разработку через него?). Переход на Compose произошел из-за повального движения в сторону легковестных контейнеров, а не полноценных виртуальных машин. К тому же Docker становился стандартом в продакшене, что давало возможность переиспользовать Dockerfile для разработки и продакшена. Но реальная жизнь оказалась сложнее. По порядку:

1. Единый Dockerfile для продакшена и девелопмента это миф и работает только в примитивных случаях
2. Постоянные сложности с настройкой сервисов, так как работа внутри контейнера часто требует особой конфигурации, запуска в хедлес режимах и указания специальных переменных окружений.
3. Compose значительно усложняет процесс разработки: внутри/снаружи, установка зависимостей, персистентность (игра с волюмами).
4. Compose требует шаманств в работе с редактором. Чтобы заставить работать lsp сервера и линтеры, нужно научить их ходить во внутрь контейнера, либо как-то имитировать идентичный сетап снаружи.

В итоге решая буквально одноразовую задачу по первоначальному сетапу, Compose значительно ухудшает сам процесс разработки, с которым мы сталкиваемся каждый день. Можно ли отказаться от него, не потеряв те преимущества, которые он дал? На 100% нельзя, но можно сделать достаточно хороший сетап, который уберет большую часть проблем и точно будет намного приятнее в использовании. Что для этого надо?

1. Автоматизация команд с зависимостями. Тут берем Make или его аналог https://www.youtube.com/watch?v=pK9mF5aK05Q
2. Mise - универсальная тулза для установки языков: https://mise.jdx.dev/
3. Overmind: Менеджер процессов, позволяет запускать наборы сервисов как DC: https://github.com/DarthSim/overmind (раньше для этого использовали Foreman, формат кстати остался тот же)
4. Как ни странно тот же Docker. Например не имеет смысл ставить базу прямо в систему, ее можно запускать так же в контейнере, но без Compose

Все это можно подсмотреть в нашем продакшен проекте https://github.com/hexlet-basics/hexlet-basics/blob/main/Makefile

Что еще? Пожалуй главная засада это первоначальная настройка вашей операционки. В маке что-то надо поставить через brew, в ubuntu через apt. Но опять же, решается все это крайне просто через тот же Make:

macos-setup:
    brew install overmind caddy

Но даже в этом случае, подготовить сетап не сложнее чем написать docker-compose.yml (в реальности последний написать сложнее, если это связано с конфигурацией сервисов под работу внутри контейнеров). А вот использование будет на порядок проще.

Ссылки: Телеграм | Youtube | VK

Во многих фреймворках создание нового ресурса - это одна команда. А вот удаление - ручной, многосоставный, рутинный ад. Вы создаёте файлы: модель, миграцию, контроллер, тесты. Потом передумываете, а файлы уже лежат в git. Что дальше?

Если повезет через git clean, но обычно руками:

* удалить файлы модели, миграции, контроллера, вьюх,
* откатить миграцию,
* удалить строчки в routes,
* проверить, ничего ли не осталось.

И без команды удаления это прямо задалбывает. Так например происходит в Laravel, особенно если косякнул с именем чего-нибудь. Потом сидишь и ручками трешь.

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

В Rails есть команда, которая удаляет всё одним движением. То есть на каждый генератор, есть “удалятел”, который подчищает все то, что было добавлено генератором.

Генерация

bin/rails generate model User name:string
      invoke  active_record
      create    db/migrate/20250424120000_create_users.rb
      create    app/models/user.rb
      invoke    test_unit
      create      test/models/user_test.rb
      create      test/fixtures/users.yml

Удаление

bin/rails destroy model User
      remove  db/migrate/20250424120000_create_users.rb
      remove  app/models/user.rb
      remove  test/models/user_test.rb
      remove  test/fixtures/users.yml

Крутяк да? А как вы удаляете то, что вам нагенерилось?

Ссылки: Телеграм | Youtube | VK

Хекслет.Клуб - общаемся, растем технически и в карьере, строим личный бренд