Я буду там 👀

https://www.tgoop.com/staff_engineers/107

Подумал о такой теме для видео, когда читал книгу Время UNIX. A History and a Memoir, Брайан Керниган.

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

Интересно должно быть даже тем, кому все равно на Vim. Это видео про интересную историю о людях из мира разработки ПО.

YouTube

Круглые цифры на YouTube. Давно не смотрел, приятно удивился. Спасибо вам!

Особенно приятно видеть обсуждения в чате, получилось уже сообщество, в котором люди общаются на отвлеченные темы.

Привет! Кто-то пользуется tmuxinator/tmuxinator или его аналогами? Утилита позволяет настроить алгоритм создания рабочего окружения в tmux. Конечно, это все можно делать через bash, благо tmux позволяет.

#!/bin/zsh                                                                                                   

SESSIONNAME="script"
tmux has-session -t $SESSIONNAME &> /dev/null

if [ $? != 0 ] 
 then
    tmux new-session -s $SESSIONNAME -n script -d
    tmux send-keys -t $SESSIONNAME "~/bin/script" C-m 
fi

tmux attach -t $SESSIONNAME

Знаете что-то интереснее - буду раз за ссылочку.

Кто не использует tmux, может как-то иначе настраивайте себе рабочее пространство для работы над задачей? Делитесь - было бы интересно, и я думаю не только мне.

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

Контракты vs. реализация
Для меня взаимодействие модуля через контракт с другим модулем — это естественная абстракция, а не привязка к реализации. Аналогичный подход мы применяем в модульном тестировании: проверяем один сервис, а не всю цепочку зависимостей. Например, достаточно убедиться, что сервис публикует сообщение в Kafka. Проверять обработку сообщений подписчиками — уже зона их ответственности.

Проблемы на практике
Однако есть нюансы, которые могут нарушить эту парадигму:

- Слабые контракты в статически типизированных языках
В Java или Go интерфейсы не гарантируют неизменность параметров, если те являются изменяемыми объектами. Реализация может модифицировать переданные данные, а мок-объекты — нет (если явно не продублировать эту логику в тестах). Это создаёт расхождение между реальным поведением и тестовой заглушкой.

- Риск нарушения обратной совместимости
Любое изменение в реализации (например, добавление новых обязательных полей) может сломать существующий контракт. Моки, жёстко зависящие от текущей версии интерфейса, не защищают от таких сценариев.

Поиск решений
Эти вопросы заставили меня вернуться к книге «Growing Object-Oriented Software, Guided by Tests». Планирую систематизировать insights в отдельном материале — тема оказалась глубже, чем казалось.

P.S. На написание этого текста меня вдохновила недавняя статья на Хабре о похожих проблемах.

Я скоро лечу в отпуск на 9 дней.

Специально для этого купил интересную камеру (название на самом видео видно). Будем в Аней постить интересности в истории и сюда в @kydavoiti_live.

Был бы вам интересен полноценный видео-ролик о полете на Кубу?

🔥 TDD в новом формате: онлайн-мастер-класс!

Знаете, как я люблю TDD и очные мастер-классы — каждый раз ухожу «доволен как слон» 🐘💥

Теперь ребята зажигают онлайн! Не уверен, будет ли это так же заряжено энергетикой зала, но точно удобно (пижама + кофе = ваш идеальный код).

🎯 Что? Онлайн-встреча по TDD
📆 Когда? Скоро! (Точная дата на сайте)
🔗 Регистрация: https://scrum.ru/code_retreat_spring_2025

👉 P.S. Даже если выйдет не идеально — будет повод обсудить за чашкой чая. Но я бы рискнул! 💻🚨

#TDD_без_границ #ПишемКодКакСлоны

Поговорим о том, на чем читать книги: бумага, e-ink, планшет. В чем плюсы вариантов? На чем остановился я?

Читать нужно, поэтому тема важная. Никто не начнет читать, если ему процесс "не нравится".

Электронные книги устарели? 📚💻

Привет! Сегодня послушал подкаст Саши про Code Review. Классно, как всегда.

Раз уж такая пьянка, то вот вам на посмотреть еще материалы со встречи, которая проходила в выходные. Там тоже есть интересности про Review. Еще там Concurrency в Python + самописный Hot Reload, смотреть надо.

Буду дальше делиться тем, как я пробую AI.

Кто смотрел мое видео про то, как я настраиваю свою рабочую машину - знают про pyinfra.

Сидел я, не знал чем заняться. Пришла в голову идея: "переписать всю эту штуку на bash". Показалось интереснымм, потому что LLM должны быть в этом хороши.

Я попросил переписать сначала всю установку пакетов на bash. Получилось неплохо. Надо было немного отрефакторить и поправить пути до файлов (он везде сделал lower-case, а я хотел названия Title-like). Выделил кучу добра в helpers, чтобы удобнее было дальше писать своик скрипты. После этого всего я попросил его переписать файл для обновления системы на bash. Используя новые helpers. Вышло немлохо, после правок. И да, еще местами он портил мои настройки, почему-то ему хотелось изменять то, как я ставлю node version manager.

В конце у меня получилось:

- dotfiles/setup-mac.sh
- dotfiles/update-mac.sh
- dotfiles/helpers.sh

Неплохо вышло. Но я решил пойти дальше. Захотел негенерить README.md, а че нет? Я не знал как нейронке показать весь мой проект. Нет у меня ваших модных IDE, да и не хотелось мне их ставить ради этого. Я решил запихнуть весь репозиторий в один файл. Для этого я опять пошел в нейронку. Она мне сгенерила вот это: dotfiles/blob/master/bin/ilyasyoy-repo-in-file.sh. Я использовал его, чтобы закинуть его в нейронку и получить удобный ответ. Мне сгенерили неверно форматированный MD файл, но я его поправил, вышло это: dotfiles/README.md

Держу в курсе.

PS. Кстати, вам может быть интересно посомтреть мои dotfiles, там есть разные штучки.

Буквально вчера записал видео про электронные книги. Думаю выйдет на этой или другой неделе..

Да-да, не удивлятесь, еще одно, оказалось есть еще что сказать. Понял я это, пока летали на Кубу. Можно сказать, что я выхожу из спячки, а то давно затишье.

---

Еще я потрогал aider:

- Мне понравился он как приложение. Очень приятно в нем работать.
- Мне понравилась идея 2 этапов: архитектура и изменение кода. Я сам работаю похожим методом, интересно что нейронки так тоже дают выхлоп лучше, если верить выкладкам.
- Мне нравится, что там можно вызывать любые команды терминала и удобно отдавать их LLM. Очень хорошо они пользуются тем, что мы работает в терминале.
- Понравилось, как они сделали "интеграцию с IDE". Ее просто нет, мы пользуемся комментами, чтобы просить LLM что-то сделать или пояснить.
- Насчет нейронок, как таковых - сложнее. Продуктивности я не ощутил. Попробовал Ping-Pong Pair Programming TDD в паре с LLM. Получилось забавно, но я задолбался писать ей пояснения: что я хочу и что она сделал не так. Проще сделать самому. Забавнее всего показалось то, как долго думает нейронка с reasoning, выдавая решение на 2 строки в простейшей задаче: сделать, чтобы дубликат не ломал вставку в Postgres.
- Как с любым инструментом, иногда получалось метко ударить, чтобы мне выдало много полезного кода за один шаг. Чаще случалось такое, когда я просил нейронку саму написать новый тест. Сделать тест зеленым ей было сложнее, почему-то.

Aider мне посоветовали в чате, за что большое спасибо. Это одно из самых полезных последствий ведения канала. Вокруг было и так много классных и толковых ребят. Сейчас их целый чат и не только. Вы крутые!

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

https://github.com/IlyasYOY/dotfiles/blob/40bf8af390d1d6a4fa26498e743e831c8a54e1e7/sh/helpers.sh#L12-L15

aider-ollama() {
    local selected_model=$(ollama list | awk 'NR>1 {print $1}' | fzf --prompt="Select a model: ")
    [[ -n "$selected_model" ]] && aider --model ollama_chat/"$selected_model"
}

Вообще, это одно из лучших применений LLM - генерить такие вот простые команды в терминале. Она неплохо их комбинирует.

ЗЗЫ. Ребята пробовали его на стриме, можете глянуть.

Записал выпуск про TDD с Ильей Ильиных. Получилось очень насыщенно. Прошлись по мокам, пирамиде, зацепили фреймворки, orm, spring boot и кучу разных языков
https://www.youtube.com/watch?v=SEfAGnQURQs

Кто какое-то время следит за моим каналом, знают что я помогаю в организации встреч в СПб. У меня есть видео, где я говорю почему вам надо ходить и общаться с коллегами.

Все говорят про ИИ и то, как он будет влиять на индустрию: программисты не нужны, обучение в 100 раз быстрее, всех заменят LLM. Может быть это так, а может и нет. Одно я могу сказать точно — бизнесу надо экономить на программистах. Экономить будут. Уже экономят. Мне кажется, что сейчас это делается жертвуя качеством (последний подкаст про TDD в тему), но это пока. Условия лучше с будет искать все сложнее и сложнее. Поэтому надо делать две вещи: прокачиваться самому, помогать коллегам.

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

И вот история: есть одна компания — Леста Игры. Она часто помогала и помогает сообществам в проведении событий. Рассказывать, что это за компания можно долго, но я просто скажу, что это те ребята, которые остались и продолжают делать Танки в России. Сейчас с ними происходит странная история: https://www.tgoop.com/channellesta/395. Трудности для компании — трудности для работников. Все это влияет на коллектив. Радует, что в комментах у ребят много поддержки, таким не каждая компания может похвастаться. Смущает меня, что вокруг этой истории в профильных каналах — тишина. Надеюсь, что все будет хорошо, и они смогут продолжить делать свою работу в спокойной обстановке, коллеги этого заслуживают.

Привет! Недавно нашёл видео Романа Елизарова про разработку платформы.

Роман Елизаров — это ex-глава разработки Kotlin. Сейчас он руководит отделом Development Experience в Яндексе. Слушать его надо — он голова.

Мне очень близко его видение того, что такое платформенная разработка. Кто не видел, у меня есть видео про эту же тему. Тема особенно важна, потому что команда разработки платформы находится со своими клиентами на расстоянии вытянутой руки. Это не какой-то непонятный бизнес-заказчик, это твой брат-разработчик. Глупо не пользоваться такой возможностью понимать своего клиента. Ещё вчера ты делал то же, что и он, а теперь ты ему помогаешь не отвлекаться на технические детали.

Есть тема, которая мне кажется нераскрытой — возможность погружения команды платформы в проблемы бизнес-команды. Если вы читали книгу Team Topologies, то вы знаете, что кроме платформенных команд есть ещё enabling teams. Из того, что я вижу вокруг, подход включателей используется почти никогда. Для меня это удивительно, потому что это прекрасный способ погрузиться в проблемы клиента — помочь ему в решении бизнес-задач средствами, которые разработала платформенная команда.

В любом случае, рекомендую этот доклад, как и любой доклад автора.