Дорогая, работа с AI-агентом превратила меня в супермена.
Или супер-мема — сейчас это почти одно и то же.
Я учусь и создаю автоматизацию в разы быстрее. Это новый темп, новый стиль работы.
Помнишь «Джонни-мнемоника»? Как главный герой перевозил информацию в чипе, встроенном в череп? История материализовалась. До нас доходят фрагменты через текстовые каналы.
Где-то китайские специалисты везут 50 ТБ обученных моделей в самолёте из стран с более свободным интернетом. В неоновых лучах Токио якудза с лазерной нитью крадёт первоклассный датасет сверхновой нейросети и перепродаёт через даркнет военным подрядчикам. Проклятая Арасака.
А я тут со своим Go и unit-тестами — как уличный самурай с клавиатурой вместо катаны.
В отражениях небоскрёбов мегаполиса стильные корпораты в дизайнерских костюмах везут обученные модели в гоночных суперкарах. Машина улучшает машину. Recursive enhancement. БУМ.
Я словно с вшитым нейроимплантом: расширенная память, ускоренное написание кода на максималках, прямая связь с матрицей целей. Мои синапсы работают в режиме overdrive.
Быстрее тестирую гипотезы, исследую новые направления. Это прорыв. Digital awakening.
Я не могу объяснить всё — слишком много переварить. Я на эмоциях.
Даже читаю больше и быстрее.
Погнали к коду
Читай мой лог про то, как я за 5 часов написал сервис с тестами, прокачал CI и получил море эндорфинов.
#codemonsterslog
#code
Или супер-мема — сейчас это почти одно и то же.
Я учусь и создаю автоматизацию в разы быстрее. Это новый темп, новый стиль работы.
Помнишь «Джонни-мнемоника»? Как главный герой перевозил информацию в чипе, встроенном в череп? История материализовалась. До нас доходят фрагменты через текстовые каналы.
Где-то китайские специалисты везут 50 ТБ обученных моделей в самолёте из стран с более свободным интернетом. В неоновых лучах Токио якудза с лазерной нитью крадёт первоклассный датасет сверхновой нейросети и перепродаёт через даркнет военным подрядчикам. Проклятая Арасака.
А я тут со своим Go и unit-тестами — как уличный самурай с клавиатурой вместо катаны.
В отражениях небоскрёбов мегаполиса стильные корпораты в дизайнерских костюмах везут обученные модели в гоночных суперкарах. Машина улучшает машину. Recursive enhancement. БУМ.
Я словно с вшитым нейроимплантом: расширенная память, ускоренное написание кода на максималках, прямая связь с матрицей целей. Мои синапсы работают в режиме overdrive.
Быстрее тестирую гипотезы, исследую новые направления. Это прорыв. Digital awakening.
Я не могу объяснить всё — слишком много переварить. Я на эмоциях.
Даже читаю больше и быстрее.
Погнали к коду
Читай мой лог про то, как я за 5 часов написал сервис с тестами, прокачал CI и получил море эндорфинов.
#codemonsterslog
#code
❤4🔥4
Что я сделал за 3 х 45 мин
код теста на геркин API Unleash
коммиты эксперимента и пошаговых улучшений кодовой базы
сразу улучшил фундамент, потом вкатил анлишь
https://git.codemonsters.team/guides/mq-rest-sync-adapter/-/commits/feature/component-tests-unleash
Добавил тесты интеграции с Unleash
В двух словах:
Unleash - это хранилище тоглов, к которому может быть подключен твой сервис. В UI анлиш или API ты включаешь тогл и твой сервис переключается на использование фичи, которую включает/выключает тогл.
Что такое тогл/ фича-флаг/ фича-тогл?
Фича-флаг (feature flag/toggle) — это механизм, который позволяет включать или выключать функциональность в приложении без изменения кода и без нового деплоя.
Простая аналогия
Представьте выключатель света в комнате:
Включен → функция работает для пользователей
Выключен → функция скрыта, хотя код присутствует в приложении
пример ко
sorry(нет):
Я с подозрением отношусь к проектам спроектированным полностью на TypeScript, JS. Оно идет инзутри моего нутра. Я понимаю, что это просто инструмент. Но это не самый хороший для бэка вариант.
С апи я помучался немного. Агент тоже не сразу справился, но я его научил.
API Unleash содержит ошибки в доке, например
API создания фичи описано с кодом 200 в ответе.
https://docs.getunleash.io/reference/api/unleash/create-feature
по факту 201.
Интеграция в компонентном тестировании с Unleash позволяет
сколь угодно тестировать сервис. И это просто.
Включая и выключая тоглы програмно по API прописываешь на геркине тест сервиса:
Автоматизавтор:
Дополнительно проверил есть ли мэтч с тоглами локального компонентного теста и с анлиш на stage, prod
чтобы не катить с тоглами, которых нет в мастер-системе - обеспечил согласованность.
P.S.
Есть несколько интересных проектов, на которые можно обратить внимание:
Flagsmith
Стек: Django/Python (backend), React (frontend)
Популярность: Активно развивается, хорошее сообщество
Простота: Есть облачная версия и self-hosted
Особенности: REST API, webhooks, интеграции
GrowthBook
Стек: Node.js/TypeScript (backend), Next.js (frontend)
Популярность: Новый, но быстро растущий
Простота: Фокус на A/B тестировании
Особенности: Интеграция с аналитикой, статистический движок
Flagr
Этот инструмент я покручу следующим.
Стек: Go
Популярность: Используется в Checkr
Простота: REST API, простое развертывание
Особенности: Легковесный, хорошая производительность
Client Libraries
(нет Java)
Language Clients
Go goflagr
Javascript jsflagr
Python pyflagr
Ruby rbflagr
#codemonsterslog
код теста на геркин API Unleash
коммиты эксперимента и пошаговых улучшений кодовой базы
сразу улучшил фундамент, потом вкатил анлишь
https://git.codemonsters.team/guides/mq-rest-sync-adapter/-/commits/feature/component-tests-unleash
Добавил тесты интеграции с Unleash
В двух словах:
Unleash - это хранилище тоглов, к которому может быть подключен твой сервис. В UI анлиш или API ты включаешь тогл и твой сервис переключается на использование фичи, которую включает/выключает тогл.
Что такое тогл/ фича-флаг/ фича-тогл?
Фича-флаг (feature flag/toggle) — это механизм, который позволяет включать или выключать функциональность в приложении без изменения кода и без нового деплоя.
Простая аналогия
Представьте выключатель света в комнате:
Включен → функция работает для пользователей
Выключен → функция скрыта, хотя код присутствует в приложении
пример ко
да:
if (featureToggles.isFeatureEnabled("wallet-balance-workflow")) {
refactoredBalanceFlow(message)
} else {
legacyBalanceFlow(message)
}
sorry(нет):
Я с подозрением отношусь к проектам спроектированным полностью на TypeScript, JS. Оно идет инзутри моего нутра. Я понимаю, что это просто инструмент. Но это не самый хороший для бэка вариант.
С апи я помучался немного. Агент тоже не сразу справился, но я его научил.
API Unleash содержит ошибки в доке, например
API создания фичи описано с кодом 200 в ответе.
https://docs.getunleash.io/reference/api/unleash/create-feature
по факту 201.
Интеграция в компонентном тестировании с Unleash позволяет
сколь угодно тестировать сервис. И это просто.
Включая и выключая тоглы програмно по API прописываешь на геркине тест сервиса:
| включил тоглФича готова к установке
| прогнал тест фичи
| выключит тогл
| прогнал тест фичи
Автоматизавтор:
Дополнительно проверил есть ли мэтч с тоглами локального компонентного теста и с анлиш на stage, prod
чтобы не катить с тоглами, которых нет в мастер-системе - обеспечил согласованность.
P.S.
Есть несколько интересных проектов, на которые можно обратить внимание:
Flagsmith
Стек: Django/Python (backend), React (frontend)
Популярность: Активно развивается, хорошее сообщество
Простота: Есть облачная версия и self-hosted
Особенности: REST API, webhooks, интеграции
GrowthBook
Стек: Node.js/TypeScript (backend), Next.js (frontend)
Популярность: Новый, но быстро растущий
Простота: Фокус на A/B тестировании
Особенности: Интеграция с аналитикой, статистический движок
Flagr
Этот инструмент я покручу следующим.
Стек: Go
Популярность: Используется в Checkr
Простота: REST API, простое развертывание
Особенности: Легковесный, хорошая производительность
Client Libraries
(нет Java)
Language Clients
Go goflagr
Javascript jsflagr
Python pyflagr
Ruby rbflagr
#codemonsterslog
👍6🔥3❤2🤔1
Ну что, Оптимус.
Дэйкстра в книге
«Дисциплина программирования»
1976 года меня очаровал с первой главы в послании от автора про перделки и свистелки в программировании:
А тем временем, Оптимус, некоторые инженеры (так называемые инфлюенсеры) не видят целесообразности в Соглашении Наименований (Name Conventions) при стандартизации работы команд.
Но это уже другая увлекательная история, брат.
#codemonsterslog
Дэйкстра в книге
«Дисциплина программирования»
1976 года меня очаровал с первой главы в послании от автора про перделки и свистелки в программировании:
Наверняка разочаруются все те, кто отождествляет трудность программирования с трудностью изощренного использования громоздких и причудливых сооружений, известных под названием «языки программирования высокого уровня» или — еще хуже! — «системы программирования». Если они сочтут себя обманутыми из-за того, что я вовсе не касаюсь всех этих погремушек и свистулек, могу ответить им только одно: «А вполне ли вы уверены, что все эти погремушки и свистульки, все эти потрясающие возможности ваших, так сказать, «мощных» языков программирования имеют отношение к процессу решения, а не к самим задачам?» Мне остается лишь надеяться, что, несмотря на употребление мною мини-языка, они все же прочтут предлагаемый текст.
А тем временем, Оптимус, некоторые инженеры (так называемые инфлюенсеры) не видят целесообразности в Соглашении Наименований (Name Conventions) при стандартизации работы команд.
Но это уже другая увлекательная история, брат.
#codemonsterslog
🔥8💯2
Делегирование — скользкая дорожка
Как не стать бутылочным горлышком в своей организации, мыслить масштабно и понимать, что происходит в развитии своих направлений — работа далеко не очевидная. Я решил для себя, что должен продолжать «марать руки» как инженер.
Убежден: тех-лид должен продолжать «марать руки». CTO тоже может марать руки - этого очень не хватает в работе.
И здесь позволю себе небольшое лирическое отступление.
Часто тех-лид не понимает цели, ради которой ему нужно «марать руки». Просто раскатить минорное обновление, чтобы показать всем, что еще способен кодить? Нет. Нужно понимать, насколько удобно разработчикам использовать конвейер. Выявлять ключевые проблемы в среде разработки, чтобы помочь своим инженерам и сделать рабочую среду лучше.
Проблема «царя во дворце»
Проблема мистера «Царь во дворце» часто кроется в том, что он считает свою работу чисто стратегической. Думать масштабно и делегировать результаты своих размышлений подчиненным. Так поступают многие и теряют доверие.
О таких часто говорят на разных уровнях: «Ну все понятно, ему хорошо.
Но его не видно, и он ничего не делает».
Если только делегируешь — значит, забыл, что значит работать по-настоящему.
Мне нравится смотреть на свои направления как в стратегии (я про Starcraft, но скорее про Dawn of War 2): наблюдаю, куда движутся команды, что у них происходит в каналах коммуникации, вижу проблемные участки или нарушения коммуникации, спускаюсь на дропподе, погружаюсь в проблему до самой земли и даже до червей в земле. Ищу ключевые проблемы и работаю над тем, чтобы помочь команде увидеть общую картину, чтобы на основе стратегии применять тактику, а не просто бежать и делать.
Важность понимания корня проблемы
Если строю пайплайн — хочу видеть его в Git, хочу знать, как он работает и что будем делать для его ускорения, опираясь на дашборды, отражающие поток его работы. Хочу чувствовать и видеть стук машинного сердца каждого компонента конвейера.
Самое плохое, что может быть — когда тех-лиды и старшие инженеры от лени, возможно от эго и упоения своей властью превращаются в обычных ленивых менеджеров, которые только распределяют задачи и посредственно обучают свои команды (или вовсе не обучают). У них нет времени «замарать руки», вникнуть в проблемы, и они вечно находят отговорки в чрезмерном количестве встреч и кучи другой «полезной» работы.
Вместо того чтобы остановиться и подумать: может, стоит перестать делать кучу бесполезной работы и подумать, какие ключевые проблемы стоит решить и кому.
Задай вопрос: куда мы идем и зачем? Что мы тут строим?
тех-лид с чистыми ручками
Тех-лид, твоя работа — показывать делом и учить младших разработчиков. Ради всего святого, это же очевидно! Если ничего не делаешь, сидя на стуле в кабинете, с чего взял, что твоя команда начнет шевелиться вдохновенно и искать точки достижения успеха?
ТехЛид - это не про пенсию и покой. Это про другой уровень задач.
Если прораб ничего не умеет делать руками и появляется на стройке лениво пару раз в неделю, о каком качестве работы может идти речь в срок?
Какой толк от твоих эпизодичных умных речей?
Как ты поймешь, где у тебя проблемы? Где кривые руки, а где кривой процесс?
На ретроспективах? смешно.
Младшие разработчики порой просто не догадываются, что система должна и способна работать иначе.
Это как бытовая проблема: если никогда не пользуешься ножом, не поймешь, когда его стоит заточить.
#codemonsterslog
Как не стать бутылочным горлышком в своей организации, мыслить масштабно и понимать, что происходит в развитии своих направлений — работа далеко не очевидная. Я решил для себя, что должен продолжать «марать руки» как инженер.
Убежден: тех-лид должен продолжать «марать руки». CTO тоже может марать руки - этого очень не хватает в работе.
И здесь позволю себе небольшое лирическое отступление.
Часто тех-лид не понимает цели, ради которой ему нужно «марать руки». Просто раскатить минорное обновление, чтобы показать всем, что еще способен кодить? Нет. Нужно понимать, насколько удобно разработчикам использовать конвейер. Выявлять ключевые проблемы в среде разработки, чтобы помочь своим инженерам и сделать рабочую среду лучше.
Проблема «царя во дворце»
Проблема мистера «Царь во дворце» часто кроется в том, что он считает свою работу чисто стратегической. Думать масштабно и делегировать результаты своих размышлений подчиненным. Так поступают многие и теряют доверие.
О таких часто говорят на разных уровнях: «Ну все понятно, ему хорошо.
Но его не видно, и он ничего не делает».
Если только делегируешь — значит, забыл, что значит работать по-настоящему.
Мне нравится смотреть на свои направления как в стратегии (я про Starcraft, но скорее про Dawn of War 2): наблюдаю, куда движутся команды, что у них происходит в каналах коммуникации, вижу проблемные участки или нарушения коммуникации, спускаюсь на дропподе, погружаюсь в проблему до самой земли и даже до червей в земле. Ищу ключевые проблемы и работаю над тем, чтобы помочь команде увидеть общую картину, чтобы на основе стратегии применять тактику, а не просто бежать и делать.
Важность понимания корня проблемы
Если строю пайплайн — хочу видеть его в Git, хочу знать, как он работает и что будем делать для его ускорения, опираясь на дашборды, отражающие поток его работы. Хочу чувствовать и видеть стук машинного сердца каждого компонента конвейера.
Самое плохое, что может быть — когда тех-лиды и старшие инженеры от лени, возможно от эго и упоения своей властью превращаются в обычных ленивых менеджеров, которые только распределяют задачи и посредственно обучают свои команды (или вовсе не обучают). У них нет времени «замарать руки», вникнуть в проблемы, и они вечно находят отговорки в чрезмерном количестве встреч и кучи другой «полезной» работы.
Вместо того чтобы остановиться и подумать: может, стоит перестать делать кучу бесполезной работы и подумать, какие ключевые проблемы стоит решить и кому.
Задай вопрос: куда мы идем и зачем? Что мы тут строим?
тех-лид с чистыми ручками
Тех-лид, твоя работа — показывать делом и учить младших разработчиков. Ради всего святого, это же очевидно! Если ничего не делаешь, сидя на стуле в кабинете, с чего взял, что твоя команда начнет шевелиться вдохновенно и искать точки достижения успеха?
ТехЛид - это не про пенсию и покой. Это про другой уровень задач.
Если прораб ничего не умеет делать руками и появляется на стройке лениво пару раз в неделю, о каком качестве работы может идти речь в срок?
Какой толк от твоих эпизодичных умных речей?
Как ты поймешь, где у тебя проблемы? Где кривые руки, а где кривой процесс?
На ретроспективах? смешно.
Младшие разработчики порой просто не догадываются, что система должна и способна работать иначе.
Это как бытовая проблема: если никогда не пользуешься ножом, не поймешь, когда его стоит заточить.
#codemonsterslog
🔥18👏6❤5
Дописываем с командой утилитарный handbook. Получается круто. Я очень рад.
Приходим по средам маленькими группами и дорабатываем артефакт.
Очень эффективно работает подход для синхронизации.
Сам хендбук при лёгком сканировании погружает в нашу инженерную культуру.
Содержит ссылки которые помогут понять :
- какие API есть для разработки продуктов
- где и как мы храним доки к сервисам. Спойлер - храним в git.
- ссылки на темплэйты сервисов
Использовать его нужно при онбординге в нашу команду и культуру.
Мы строим Конвейер Непрерывной поставки (Continuous Deployment)
Внедряем практики, которые прекрасно поддерживают такой конвейер.
Наш манифест:
Меньше кода — простые архитектурные решения.
Меньше документации, но лучше — фокус на спецификации Async API 3.0, лаконичных README, понятный ландшафт API, документации в гит
Меньше тестов — акцент на 100% покрытие бизнес-логики юнит-тестами, мы пишем компонентные тесты и почти не используем E2E
Чаще устанавливаем на прод и реже ошибаемся — Continuous Deployment с автоматизированным контролем качества. Чтобы меньше совершать ошибок - нужно чаще устанавливать.
Единые артефакты ручного тестирования
Каждая глава - руководство к действию и описание задачи для реализации автоматической проверки артефакта на соответствие.
Например:
Мы используем компонентные тесты.
где они запускаются?
На этапе ci. Что это за этап?
Этап слияния в основной транк.
Мы используем trunk based development (TBD).
Как они запускаются автоматом?
Сколько таких тестов должно быть и почему?
#codemonsterslog
Приходим по средам маленькими группами и дорабатываем артефакт.
Очень эффективно работает подход для синхронизации.
Сам хендбук при лёгком сканировании погружает в нашу инженерную культуру.
Содержит ссылки которые помогут понять :
- какие API есть для разработки продуктов
- где и как мы храним доки к сервисам. Спойлер - храним в git.
- ссылки на темплэйты сервисов
Использовать его нужно при онбординге в нашу команду и культуру.
Мы строим Конвейер Непрерывной поставки (Continuous Deployment)
Внедряем практики, которые прекрасно поддерживают такой конвейер.
Наш манифест:
Меньше кода — простые архитектурные решения.
Меньше документации, но лучше — фокус на спецификации Async API 3.0, лаконичных README, понятный ландшафт API, документации в гит
Меньше тестов — акцент на 100% покрытие бизнес-логики юнит-тестами, мы пишем компонентные тесты и почти не используем E2E
Чаще устанавливаем на прод и реже ошибаемся — Continuous Deployment с автоматизированным контролем качества. Чтобы меньше совершать ошибок - нужно чаще устанавливать.
Единые артефакты ручного тестирования
Каждая глава - руководство к действию и описание задачи для реализации автоматической проверки артефакта на соответствие.
Например:
Мы используем компонентные тесты.
где они запускаются?
На этапе ci. Что это за этап?
Этап слияния в основной транк.
Мы используем trunk based development (TBD).
Как они запускаются автоматом?
Сколько таких тестов должно быть и почему?
#codemonsterslog
🔥9👍5👏2
Растворился в множестве потоков и притаился
1. Подготовил интересную программу Бэкенд академии для QA инженеров.
Доволен результатом. Будет левел ап.
Собрал крутую команду кураторов для студентов
Это невероятно интересный вызов.
Круто, что есть запрос на переквалификацию в организации и мы на него отвечаем положительно.
2. Дописываю статью про то, как за 12 часов спроектировал с машиной инструмент для проверки контрактов сервисов
3. Снял немного видео как катался в Байк-Парке Архыз
Осталось его смонтировать. Как же там красиво.
Ещё Мы ускоряем конвейер, улучшаем инструменты, укрепляем команды.
Дни пролетают как кадры из кино.
Не успеваю послушать кассету в плеере. Я тебе покажу его следующий раз. Жду ту самую кассету )
#codemonsterslog
1. Подготовил интересную программу Бэкенд академии для QA инженеров.
Доволен результатом. Будет левел ап.
Собрал крутую команду кураторов для студентов
Это невероятно интересный вызов.
Круто, что есть запрос на переквалификацию в организации и мы на него отвечаем положительно.
2. Дописываю статью про то, как за 12 часов спроектировал с машиной инструмент для проверки контрактов сервисов
3. Снял немного видео как катался в Байк-Парке Архыз
Осталось его смонтировать. Как же там красиво.
Ещё Мы ускоряем конвейер, улучшаем инструменты, укрепляем команды.
Дни пролетают как кадры из кино.
Не успеваю послушать кассету в плеере. Я тебе покажу его следующий раз. Жду ту самую кассету )
#codemonsterslog
🔥7
Вчера я прочувствовал всецело "кость в горле".
Подавился костью рыбы. Так было больно, одновременно досадно саднило. И вдохновило.
Сел - пишу статью дальше.
Так живешь, строишь планы, прыгаешь в горах как козел по камням на байке, а отъезжаешь в миг от безобидной оливки или предательской кости рыбы в горле.
Курица кажется безопаснее.
Она не пытается меня убить из тарелки.
С другой стороны: мою собаку убивает сильная аллергия на курицу.
Мы окружены, Гарри.
Ты давился костью рыбы? На сколько она была большая?
Я в этот раз задумался и пропустил большую.
Ты так не делай. Будь в моменте))
#codemonsterslog
Подавился костью рыбы. Так было больно, одновременно досадно саднило. И вдохновило.
Сел - пишу статью дальше.
Так живешь, строишь планы, прыгаешь в горах как козел по камням на байке, а отъезжаешь в миг от безобидной оливки или предательской кости рыбы в горле.
Курица кажется безопаснее.
Она не пытается меня убить из тарелки.
С другой стороны: мою собаку убивает сильная аллергия на курицу.
Мы окружены, Гарри.
Ты давился костью рыбы? На сколько она была большая?
Я в этот раз задумался и пропустил большую.
Ты так не делай. Будь в моменте))
#codemonsterslog
😁5🤯5
Я помню, когда я прочитал доклад несколько лет назад про ROP и программирование на типах в пустой колодец. Инженеры просто молчали. А ведь это крайне полезные подходы.
Недавно один инженер мне рассказывал о подомном случае, когда аудитория не реагирует на важные простые технические концепции.
ROP (Railway-oriented Programming) и программирование на типах действительно очень полезные подходы, особенно для создания надежного кода.
из серии: воспоминания деда
#codemonsterslog
Недавно один инженер мне рассказывал о подомном случае, когда аудитория не реагирует на важные простые технические концепции.
ROP (Railway-oriented Programming) и программирование на типах действительно очень полезные подходы, особенно для создания надежного кода.
из серии: воспоминания деда
#codemonsterslog
😁7
День прокрутил на хорошей скорости
С пленки вайб идёт по проводам
Продолжаю писать
Ты стримовый или аналоговый звук слушаешь?
#codemonsterslog #vibe@codemonsterslogs
С пленки вайб идёт по проводам
Продолжаю писать
Ты стримовый или аналоговый звук слушаешь?
#codemonsterslog #vibe@codemonsterslogs
❤7🤓4🔥3
Проводим митап по Doc as Code
Классная атмосфера
Интересные актуальные доклады ребят из команд.
Многие выступают впервые.
Наконец-то. 💥
#codemonsterslog #vibe@codemonsterslogs
Классная атмосфера
Интересные актуальные доклады ребят из команд.
Многие выступают впервые.
Наконец-то. 💥
#codemonsterslog #vibe@codemonsterslogs
🔥17👍1
Митап о первоисточнике истины: как мы меняем подход к документации
Провели митап о том, с чего должно начинаться погружение инженера в проект — с единого источника правды о системе.
Говорили про Doc as Code — подход, когда документация живёт рядом с кодом и обновляется вместе с ним.
Мы меняем устоявшиеся привычки и становимся современным финтехом.
На митапе инженеры:
- Показывали реальные примеры качественного описания сервисов и спецификаций
- Демонстрировали генерацию кода по OpenAPI, Async Api спекам
- Рассказывали, как каталог софта (Backstage) упрощает навигацию по ИТ-ландшафту компании
Формат изменился — стало меньше абстрактных вопросов и больше практики. Инженеры отвечали на вопросы коллег, показывали живые примеры из своих проектов, на деле демонстрировали, как работают новые подходы.
55 человек оффлайн
Онлайн:
Уникальные зрители более 700
Всего просмотров 1 322
крутится мысль
Сижу в такси после митапа, смотрю в окно и радуюсь.
5 лет назад я недоумевал: почему в корпоративной культуре не используют практики из open source сообщества? Почему не делают как на GitHub зрелые проекты?
И вот мы внедряем именно такие подходы в Газпромбанке.
Пишем документацию в Git. Больше не нужно блуждать по ресурсам среди устаревших страниц и собирать контекст.
Не нужно придумывать велосипеды — лучшие практики уже отработаны сообществом.
Если тебе интересно следить за трансформацией ИТ в ГПБ — подписывайся на наш Telegram-канал.
P.S. Мне очень нравится этот бульдоня. Розовый ему определённо идёт. Стиль.
#codemonsterslog
Провели митап о том, с чего должно начинаться погружение инженера в проект — с единого источника правды о системе.
Говорили про Doc as Code — подход, когда документация живёт рядом с кодом и обновляется вместе с ним.
Мы меняем устоявшиеся привычки и становимся современным финтехом.
На митапе инженеры:
- Показывали реальные примеры качественного описания сервисов и спецификаций
- Демонстрировали генерацию кода по OpenAPI, Async Api спекам
- Рассказывали, как каталог софта (Backstage) упрощает навигацию по ИТ-ландшафту компании
Формат изменился — стало меньше абстрактных вопросов и больше практики. Инженеры отвечали на вопросы коллег, показывали живые примеры из своих проектов, на деле демонстрировали, как работают новые подходы.
55 человек оффлайн
Онлайн:
Уникальные зрители более 700
Всего просмотров 1 322
крутится мысль
Сижу в такси после митапа, смотрю в окно и радуюсь.
5 лет назад я недоумевал: почему в корпоративной культуре не используют практики из open source сообщества? Почему не делают как на GitHub зрелые проекты?
И вот мы внедряем именно такие подходы в Газпромбанке.
Пишем документацию в Git. Больше не нужно блуждать по ресурсам среди устаревших страниц и собирать контекст.
Не нужно придумывать велосипеды — лучшие практики уже отработаны сообществом.
Если тебе интересно следить за трансформацией ИТ в ГПБ — подписывайся на наш Telegram-канал.
P.S. Мне очень нравится этот бульдоня. Розовый ему определённо идёт. Стиль.
#codemonsterslog
🔥12❤4👏1
Вирт:
Дорабатываю фрагмент статьи, нашел прекрасную цитату.
Всем хорошего дня.
#codemonsterslog
Уменьшение сложности и размера должно быть целью на каждом этапе — в спецификации системы, дизайне и детальном программировании. Компетентность программиста следует оценивать по способности находить простые решения, а не по производительности, измеряемой в «количестве строк, выбрасываемых в день».
Плодовитые программисты способствуют определенной катастрофе.
Дорабатываю фрагмент статьи, нашел прекрасную цитату.
Всем хорошего дня.
#codemonsterslog
👍12💯3🔥2
🚀 Со-творчество с машиной: как я создал валидатор контрактов без единой строки кода
Представьте: инженер надевает "костюм супергероя" в 5 утра, садится за Claude терминал и за 10 часов создает production-ready инструмент на Go с 300+ тестами, НЕ НАПИСАВ НИ ОДНОЙ СТРОКИ КОДА вручную.
Научная фантастика? Нет, реальность 2025 года.
🎯 Суть эксперимента:
Вместо Pact создал с машиной валидатор контрактов между микросервисами по AsyncAPI 3.0 спецификациям.
Идея простая: зачем писать дополнительные pact тесты в BDD-стиле, если спецификации уже содержат всю информацию о контрактах?
💡 Ключевые открытия:
TDD + ИИ = магия
- Маленькие итерации от тестов к коду
- Машина обнаружила 2 критических бага в процессе
- Ноль переписываний благодаря четкому проектированию модулей и структур сообщений для модулей
Проектирование решает всё
- Схемы иерархии модулей на бумаге
- Псевдокод основной функции
- Railway-oriented Programming для обработки ошибок, для упрощения потока программы
- "Один модуль — одна функция"
Роль инженера меняется кардинально
Из кодировщика в архитектора: формулируешь техзадание, рисуешь схемы, валидируешь результат. Машина делает всю рутину.
🔥 Результат:
Полнофункциональный валидатор контрактов с модульной архитектурой, исчерпывающим тестированием и стандартизированной обработкой ошибок. Готов к production.
💭 Главный инсайт:
Принципы структурного программирования 70-х + современные ИИ-ассистенты = мощнейшая комбинация.
Качественное проектирование становится единственным критическим навыком.
Читать статью
Мы живем в уникальном срезе реальности, где сбываются мечты программистов о "средствах автоматизации кодирования" из 1973 года.
Читать код валидатора контрактов
#codemonsterslog
Представьте: инженер надевает "костюм супергероя" в 5 утра, садится за Claude терминал и за 10 часов создает production-ready инструмент на Go с 300+ тестами, НЕ НАПИСАВ НИ ОДНОЙ СТРОКИ КОДА вручную.
Научная фантастика? Нет, реальность 2025 года.
🎯 Суть эксперимента:
Вместо Pact создал с машиной валидатор контрактов между микросервисами по AsyncAPI 3.0 спецификациям.
Идея простая: зачем писать дополнительные pact тесты в BDD-стиле, если спецификации уже содержат всю информацию о контрактах?
💡 Ключевые открытия:
TDD + ИИ = магия
- Маленькие итерации от тестов к коду
- Машина обнаружила 2 критических бага в процессе
- Ноль переписываний благодаря четкому проектированию модулей и структур сообщений для модулей
Проектирование решает всё
- Схемы иерархии модулей на бумаге
- Псевдокод основной функции
- Railway-oriented Programming для обработки ошибок, для упрощения потока программы
- "Один модуль — одна функция"
Роль инженера меняется кардинально
Из кодировщика в архитектора: формулируешь техзадание, рисуешь схемы, валидируешь результат. Машина делает всю рутину.
🔥 Результат:
Полнофункциональный валидатор контрактов с модульной архитектурой, исчерпывающим тестированием и стандартизированной обработкой ошибок. Готов к production.
💭 Главный инсайт:
Принципы структурного программирования 70-х + современные ИИ-ассистенты = мощнейшая комбинация.
Качественное проектирование становится единственным критическим навыком.
Читать статью
Мы живем в уникальном срезе реальности, где сбываются мечты программистов о "средствах автоматизации кодирования" из 1973 года.
Читать код валидатора контрактов
#codemonsterslog
🔥14👍3🤯3
Spec-driven development: программируем через спецификацию
Сначала была лаконичная спецификация. Потом был код на Go.
Без some-driven development сейчас ты не девелопер.
Наткнулся на статью, которая отлично дополняет мой эксперимент по кодированию с ИИ. Я тоже описывал задачу в README машине — и это работает.
Написать лаконичную спецификацию перед тем, как начнёшь кодить — правильный цикл разработки.
Причём сейчас, в эпоху ИИ-ассистентов, это не просто best practice, а рабочий инструмент.
Я заметил, что многие привыкли работать без предварительных «зарисовок» и описания желаемого результата.
Потом можно провести встречу без повестки, доски, стикеров, без протокола, просто походить и почесать языком часов 8 — и ты уже герой, получаешь 💰. Но результата ноль.
Цикл разработки прост:
1. Отредактируй спецификацию в
2. Попроси ИИ-агента скомпилировать её в код Go
3. Запусти и протестируй приложение
4. Если что-то работает не так — обнови спецификацию
Повторяй, пока не получишь нужный результат.
Подробнее: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-using-markdown-as-a-programming-language-when-building-with-ai/
#codemonsterslog #dev2dev
Сначала была лаконичная спецификация. Потом был код на Go.
Без some-driven development сейчас ты не девелопер.
Наткнулся на статью, которая отлично дополняет мой эксперимент по кодированию с ИИ. Я тоже описывал задачу в README машине — и это работает.
Написать лаконичную спецификацию перед тем, как начнёшь кодить — правильный цикл разработки.
Причём сейчас, в эпоху ИИ-ассистентов, это не просто best practice, а рабочий инструмент.
Я заметил, что многие привыкли работать без предварительных «зарисовок» и описания желаемого результата.
Потом можно провести встречу без повестки, доски, стикеров, без протокола, просто походить и почесать языком часов 8 — и ты уже герой, получаешь 💰. Но результата ноль.
Цикл разработки прост:
1. Отредактируй спецификацию в
main.md или README.md2. Попроси ИИ-агента скомпилировать её в код Go
3. Запусти и протестируй приложение
4. Если что-то работает не так — обнови спецификацию
Повторяй, пока не получишь нужный результат.
Подробнее: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-using-markdown-as-a-programming-language-when-building-with-ai/
#codemonsterslog #dev2dev
The GitHub Blog
Spec-driven development: Using Markdown as a programming language when building with AI
I coded my latest app entirely in Markdown and let GitHub Copilot compile it into Go. This resulted in cleaner specs and faster iteration.
❤3💯2