Выпуск про тимлидов уже доступен для просмотра. Вы узнаете, как устроена настоящая командная динамика, что делать, если «всё рушится», и почему работа тимлида — это не про власть, а про ответственность. Не пропустите — разговор откровенный, местами жёсткий, но крайне полезный для всех, кто хочет расти в IT.
https://www.youtube.com/watch?v=_qJ_rU8-S90
Альтернативные ссылки: Аудио | vk
https://www.youtube.com/watch?v=_qJ_rU8-S90
Альтернативные ссылки: Аудио | vk
YouTube
Тимлидерство от А до Я: влияние, управление, делегирование | Александр Кучук #41
В этом выпуске мы поговорили с Сашей Кучуком — тимлидом с 11-летним опытом, который последние шесть лет работает в крупных и малых компаниях, включая топовые бигтехи. Обсудили, как на самом деле устроена жизнь тимлида, почему программирование — не стрессовая…
Универсальный стек для работы без 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:
Но даже в этом случае, подготовить сетап не сложнее чем написать docker-compose.yml (в реальности последний написать сложнее, если это связано с конфигурацией сервисов под работу внутри контейнеров). А вот использование будет на порядок проще.
Ссылки: Телеграм | Youtube | VK
Удивительное рядом. Как оказалось, многие разработчики зашли в разработку когда в их проекте уже был 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. Что дальше?
Если повезет через
* удалить файлы модели, миграции, контроллера, вьюх,
* откатить миграцию,
* удалить строчки в routes,
* проверить, ничего ли не осталось.
И без команды удаления это прямо задалбывает. Так например происходит в Laravel, особенно если косякнул с именем чего-нибудь. Потом сидишь и ручками трешь.
Для всего этого добра можно было бы придумать обратную команду, которая чистит любой сгенерированный ресурс с его связями, но почему-то так получилось, что это есть в небольшом количестве фреймворков. В первую очередь я говорю про Rails, который это в принципе популяризировал.
В Rails есть команда, которая удаляет всё одним движением. То есть на каждый генератор, есть “удалятел”, который подчищает все то, что было добавлено генератором.
Генерация
Удаление
Крутяк да? А как вы удаляете то, что вам нагенерилось?
Ссылки: Телеграм | Youtube | VK
Если повезет через
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
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Хекслет.Клуб - общаемся, растем технически и в карьере, строим личный бренд
Организованное программирование | Кирилл Мокевнин pinned «Хекслет.Клуб - общаемся, растем технически и в карьере, строим личный бренд»
Хекслет.Клуб официально открыт! Значит рассказываю. У меня давно была идея, объединять не только тех кто хочет вкатываться в it, но и тех кто уже работает и кому важен профессиональный рост, карьерный рост, возможность увеличить свой нетворк, если нужно переехать и устроиться куда-то зарубеж.
Как устроен клуб (к чему мы идем)
Внутри находится чат, в котором присутствуют как обычные участники, так и менторы, которые специализируются на помощи в прокачке. Чат состоит разговорных и автоматических топиков, в которые попадают истории от участников:
- Собеседования: Опыт прохождения участниками мидловых и синьорских собеседований с вопросами и требованиями
- Компании: Отзывы и рассказ о внутренней кухне работы компаний, в которых работают участники
- Менторы: Отчеты менторов и о менторах, с описанием планов развития
В разговорных чатах обсуждается все от алгоритмов и курсов до построения личного бренда.
Сам клуб управляется через бота https://t.me/HexletClubBot Через него дается доступ к чату, в этом же боте собраны полезные ссылки и база знаний клуба.
Ну что, поехали) Жду всех там
Ссылки: Телеграм | Youtube | VK
Как устроен клуб (к чему мы идем)
Внутри находится чат, в котором присутствуют как обычные участники, так и менторы, которые специализируются на помощи в прокачке. Чат состоит разговорных и автоматических топиков, в которые попадают истории от участников:
- Собеседования: Опыт прохождения участниками мидловых и синьорских собеседований с вопросами и требованиями
- Компании: Отзывы и рассказ о внутренней кухне работы компаний, в которых работают участники
- Менторы: Отчеты менторов и о менторах, с описанием планов развития
В разговорных чатах обсуждается все от алгоритмов и курсов до построения личного бренда.
Сам клуб управляется через бота https://t.me/HexletClubBot Через него дается доступ к чату, в этом же боте собраны полезные ссылки и база знаний клуба.
Ну что, поехали) Жду всех там
Ссылки: Телеграм | Youtube | VK
Telegram
Хекслет Клуб (Бот)
Наш клуб помогает разработчиком расти в карьере и зарплате. От создателей Хекслета
Заменит ли ИИ программистов? Вокруг себя вижу много панических настроений на эту тему, поэтому пост. Начну с анекдота
Клиент вызывает мастера починить сломавшийся станок.
Мастер приходит, осматривает станок, берет молоток, слегка ударяет в одном месте — станок снова работает.
Мастер выписывает счет на $500.
Клиент возмущается:
— За что $500? Вы же только один раз молотком ударили!
Мастер спокойно отвечает:
— За удар молотком — $5. За то, чтобы знать, куда ударить — $495.
ИИ действительно может генерировать куски кода, но написать код != создать работающую систему. Программирование это не только набор символов в редакторе. Это анализ требований, архитектура, проектирование системных взаимодействий, поддержка, развитие. ИИ не умеет брать на себя всю полноту инженерной ответственности: понимать зачем, почему и в каком контексте разрабатывается продукт.
Кроме того, задача программиста - не просто написать решение, а проанализировать его стоимость: насколько оно сложно в поддержке, сколько ресурсов потребует в будущем, сколько будет стоить исправление ошибок и адаптация под изменения. Иногда работа специалиста не в том, чтобы реализовать то, что попросили, а в том, чтобы предложить более дешевую, простую и надежную альтернативу.
Еще один важный момент: ИИ в своей природе в основном "копипастит" уже существующие паттерны кода, но не создает новых абстракций. Создание абстракций требует понимания сути задачи, компромиссов между сложностью и гибкостью, предвидения будущих изменений. Это работа мышления, а не перебора вариантов. Создание правильных абстракций определяет, насколько система будет масштабируемой, понятной и живучей. ИИ пока остается на уровне механического исполнения без глубокого понимания задач.
И наконец: реальные проекты - это не изолированные кусочки кода. Это сложные системы с множеством взаимосвязанных компонентов: базы данных, кэш-сервисы, очереди, микросервисы, балансировщики нагрузки, десятки или сотни серверов. Ошибки в таких системах проявляются не там, где был написан код, а на стыках между частями, под нагрузкой, в редких пограничных случаях. Диагностика и исправление таких ошибок требуют системного мышления, опыта и понимания работы всей инфраструктуры целиком. Пока ИИ не способен взять на себя такую ответственность.
Миф: ИИ сделает всех равными
Кажется, что с ИИ теперь каждый сможет делать то же самое, что и крутой разработчик. Но на практике ИИ становится инструментом в руках человека. Чем опытнее человек, тем лучше он ставит задачи ИИ, проверяет результаты и направляет процесс. Это усиливает разницу между сильными и слабыми разработчиками: кто умеет думать становится еще продуктивнее, кто не умеет, тонет в посредственных результатах.
Миф: ИИ заменит джунов
В этом утверждении зашито представление, что джуны нужны для выполнения каких-то базовых задач с которыми справится любой дурак. Поэтому без ии нам приходилось их нанимать, а вот с ии они больше будут не нужны. Компании нанимают джунов по другим причинам. Они готовы вкладываться в людей, чтобы вырастить из них квалифицированных специалистов. То есть никто не нанимает джуна, для того, чтобы он остался джуном. Тогда это был бы не джун, а вполне себе опытный, но очень низкоквалицированный специалист на низковалифицированную задачу.
Миф: Нужно срочно менять профессию
Как и с любой новой технологией, реальный сценарий это не исчезновение профессии, а её изменение. Появится больше задач по интеграции ИИ в продукты, по проектированию взаимодействия между человеком и машиной, по валидации и контролю качества того, что делает ИИ. Уйдут рутинные задачи, вырастет ценность проектирования, системного мышления и креативности.
Что действительно меняется
* Рутинные задачи действительно будут автоматизироваться.
* Навыки работы с ИИ становятся частью базового набора разработчика.
* Возрастет ценность знаний о системах, архитектуре, бизнесе.
Что вы об этом думаете?
Ссылки: Телеграм | Youtube | VK
Клиент вызывает мастера починить сломавшийся станок.
Мастер приходит, осматривает станок, берет молоток, слегка ударяет в одном месте — станок снова работает.
Мастер выписывает счет на $500.
Клиент возмущается:
— За что $500? Вы же только один раз молотком ударили!
Мастер спокойно отвечает:
— За удар молотком — $5. За то, чтобы знать, куда ударить — $495.
ИИ действительно может генерировать куски кода, но написать код != создать работающую систему. Программирование это не только набор символов в редакторе. Это анализ требований, архитектура, проектирование системных взаимодействий, поддержка, развитие. ИИ не умеет брать на себя всю полноту инженерной ответственности: понимать зачем, почему и в каком контексте разрабатывается продукт.
Кроме того, задача программиста - не просто написать решение, а проанализировать его стоимость: насколько оно сложно в поддержке, сколько ресурсов потребует в будущем, сколько будет стоить исправление ошибок и адаптация под изменения. Иногда работа специалиста не в том, чтобы реализовать то, что попросили, а в том, чтобы предложить более дешевую, простую и надежную альтернативу.
Еще один важный момент: ИИ в своей природе в основном "копипастит" уже существующие паттерны кода, но не создает новых абстракций. Создание абстракций требует понимания сути задачи, компромиссов между сложностью и гибкостью, предвидения будущих изменений. Это работа мышления, а не перебора вариантов. Создание правильных абстракций определяет, насколько система будет масштабируемой, понятной и живучей. ИИ пока остается на уровне механического исполнения без глубокого понимания задач.
И наконец: реальные проекты - это не изолированные кусочки кода. Это сложные системы с множеством взаимосвязанных компонентов: базы данных, кэш-сервисы, очереди, микросервисы, балансировщики нагрузки, десятки или сотни серверов. Ошибки в таких системах проявляются не там, где был написан код, а на стыках между частями, под нагрузкой, в редких пограничных случаях. Диагностика и исправление таких ошибок требуют системного мышления, опыта и понимания работы всей инфраструктуры целиком. Пока ИИ не способен взять на себя такую ответственность.
Миф: ИИ сделает всех равными
Кажется, что с ИИ теперь каждый сможет делать то же самое, что и крутой разработчик. Но на практике ИИ становится инструментом в руках человека. Чем опытнее человек, тем лучше он ставит задачи ИИ, проверяет результаты и направляет процесс. Это усиливает разницу между сильными и слабыми разработчиками: кто умеет думать становится еще продуктивнее, кто не умеет, тонет в посредственных результатах.
Миф: ИИ заменит джунов
В этом утверждении зашито представление, что джуны нужны для выполнения каких-то базовых задач с которыми справится любой дурак. Поэтому без ии нам приходилось их нанимать, а вот с ии они больше будут не нужны. Компании нанимают джунов по другим причинам. Они готовы вкладываться в людей, чтобы вырастить из них квалифицированных специалистов. То есть никто не нанимает джуна, для того, чтобы он остался джуном. Тогда это был бы не джун, а вполне себе опытный, но очень низкоквалицированный специалист на низковалифицированную задачу.
Миф: Нужно срочно менять профессию
Как и с любой новой технологией, реальный сценарий это не исчезновение профессии, а её изменение. Появится больше задач по интеграции ИИ в продукты, по проектированию взаимодействия между человеком и машиной, по валидации и контролю качества того, что делает ИИ. Уйдут рутинные задачи, вырастет ценность проектирования, системного мышления и креативности.
Что действительно меняется
* Рутинные задачи действительно будут автоматизироваться.
* Навыки работы с ИИ становятся частью базового набора разработчика.
* Возрастет ценность знаний о системах, архитектуре, бизнесе.
Что вы об этом думаете?
Ссылки: Телеграм | Youtube | VK
В этом выпуске подкаста «Организованное программирование» у меня в гостях Евгений Кот — легендарный эксперт, известный своими увлекательными разборами психологических и социальных тем. Мы глубоко погрузились в тему культурного кода, обсудили разницу в подходах к работе и тонкости взаимодействия в международных командах. Поговорили о том, какое значение имеют софт-скиллы в США, Европе и других странах, и поделились личными историями успешной (и не очень) адаптации к новым профессиональным и жизненным реалиям. Вы узнаете, как выстроить эффективную коммуникацию в многонациональных коллективах, как воспитание и культурные установки влияют на прxофессиональный рост, и почему культурные различия могут стать не только препятствием, но и серьезным преимуществом для вашей карьеры. Не пропустите — вас ждут уникальные инсайты и полезные практические советы, которые помогут вам успешно реализоваться в международной среде!
https://www.youtube.com/watch?v=V0Du67scNvU
Альтернативные ссылки: Аудио | vk
https://www.youtube.com/watch?v=V0Du67scNvU
Альтернативные ссылки: Аудио | vk
YouTube
Почему ваша амбициозность в Европе может обернуться одиночеством | Евгений Кот #42
В этом выпуске подкаста «Организованное программирование» у меня в гостях Евгений Кот — легендарный эксперт, известный своими увлекательными разборами психологических и социальных тем. Мы глубоко погрузились в тему культурного кода, обсудили разницу в подходах…
Как я делаю подкасты?
Не знаю пригодится вам или нет, но поделюсь тем, какой я использую подход для организации подкаста.
Подкаст я делаю не один, у меня есть помощник (буду говорить “продюсер”), который помогает с подготовкой гостей, монтажом и выкладкой подкаста. Это можно делать и самостоятельно, но я бы тратил реально очень много времени. Так что оно того стоит.
Темы и гости
Начальный план был поговорить с друзьями :) Потом уже в процесс стало вырисовываться, что классно идти по языкам, это нравится аудитории. Классно делать дебаты (я планирую несколько в ближайшее время), тут ИИ подтянулся и другие идеи появились. В общем пока оно идет, идей появляется больше чем слотов для вебинаров, поэтому тут все просто.
Что касается гостей, то недостатка в них нет. Я смотрю ребят которые выступали на конфах, других подкастах, много и часто пишут или являются признанными экспертами и адвокатами в их стеке. Ну и друзья конечно :)
Процесс
Выглядит так:
1. я договариваюсь с гостем о подкасте и времени. Заношу все это в спец табличку где есть график записей и отдельный список гостей с контактами
2. Гость бронирует слот и ему в календарь падает мероприятие с ссылкой на памятку, где написаны правила, рекомендации, как подготовиться, как оно будет проходить и так далее.
3. Продюсер высылает гостю форму, в которой гость отмечает как его представить, чем он занимается, какие штуки хочет попиарить и так далее.
4. Продюсер проводит с ними плановый техчек за 3-2 дня. Иногда это приводит к тому, что гость берет таймаут на докупку оборудования или смены локации. Плюс тут же проверяется что была заполнена форма и даются рекомендации по тому, как лучше провести подкаст
5. В день X мы записываемся и прощаемся с гостем
6. Продюсер берет исходники, делает из них аудио и видео версии, иногда (если требуется) дает послушать для доработки и готовит все это добро к выкладке. В этот момент он присылает мне варианты заголовков и описаний на согласование. Тут включается seo и chatgpt.
7. В воскресение с утра подкаст выходит на всех площадках (включая аудио).
8. Я делаю посты в соц сети.
Время
Самый гемморой это договариваться о времени. У всех разные часовые зоны, дети, планы, отпуска. Поэтому я сразу сделал ход конем, создал отдельный календарь под запись с единственным слотом в неделю в cal.com. Ну и просто сбрасываю его гостю, пока договариваемся о подкасте, а гость уже сам вписывается когда ему удобно. Изредка мой слот им не подходит и только в таких случаях мы начинаем договариваться вручную о конкретном дне. Буквально вчера я записал такой подкаст, а вот сегодня уже записываюсь по расписанию (пришлось два раза в неделю, чтобы нагнать график).
Само планирование я делаю раз в месяц-два. Сажусь, выбираю гостей и начинаю всем писать. Обычно после этого календарь забивается на пару месяцев вперед. Кстати, это всегда удивляет гостей, когда они видят, что ближайший слот только через месяц. Далеко не у всех такой горизонт планирования.
Техника
Мы долго искали комбинацию инструментов, которая бы нас устроила и остановились на микрофоне podmic и встроенной в мак камере. Мы сознательно отказались от камеры сбоку, которую часто применяют в записи подкастов. Это довольно сложная конфигурация для нас и гостей, при этом влияние на просмотр подкаста это вроде как не оказывает.
Софт
Стандартная схема записи подкастов это довольно утомительное занятие. Скачать и вовремя и правильно запустить audacity, записывать видео с двух устройств и потом все это залить на файлообменник. Я сразу хотел от всего этого убежать. Перепробовав десяток разных сервисов, мы вернулись к старому доброму стримярду, который за прошедшие годы научился делать локальную запись (то есть интернет как в зуме уже не влияет) и автоматически закачивать ее в облако. Поэтому для гостя и меня запись выглядит так, мы заходим в студию стримярда, жмякаем record и в конце end record. Дожидаемся пока студия скажет что все залито (обычно это происходит моментально) и расходимся.
Для выкладки аудио подкаста юзаем https://transistor.fm/
Не знаю пригодится вам или нет, но поделюсь тем, какой я использую подход для организации подкаста.
Подкаст я делаю не один, у меня есть помощник (буду говорить “продюсер”), который помогает с подготовкой гостей, монтажом и выкладкой подкаста. Это можно делать и самостоятельно, но я бы тратил реально очень много времени. Так что оно того стоит.
Темы и гости
Начальный план был поговорить с друзьями :) Потом уже в процесс стало вырисовываться, что классно идти по языкам, это нравится аудитории. Классно делать дебаты (я планирую несколько в ближайшее время), тут ИИ подтянулся и другие идеи появились. В общем пока оно идет, идей появляется больше чем слотов для вебинаров, поэтому тут все просто.
Что касается гостей, то недостатка в них нет. Я смотрю ребят которые выступали на конфах, других подкастах, много и часто пишут или являются признанными экспертами и адвокатами в их стеке. Ну и друзья конечно :)
Процесс
Выглядит так:
1. я договариваюсь с гостем о подкасте и времени. Заношу все это в спец табличку где есть график записей и отдельный список гостей с контактами
2. Гость бронирует слот и ему в календарь падает мероприятие с ссылкой на памятку, где написаны правила, рекомендации, как подготовиться, как оно будет проходить и так далее.
3. Продюсер высылает гостю форму, в которой гость отмечает как его представить, чем он занимается, какие штуки хочет попиарить и так далее.
4. Продюсер проводит с ними плановый техчек за 3-2 дня. Иногда это приводит к тому, что гость берет таймаут на докупку оборудования или смены локации. Плюс тут же проверяется что была заполнена форма и даются рекомендации по тому, как лучше провести подкаст
5. В день X мы записываемся и прощаемся с гостем
6. Продюсер берет исходники, делает из них аудио и видео версии, иногда (если требуется) дает послушать для доработки и готовит все это добро к выкладке. В этот момент он присылает мне варианты заголовков и описаний на согласование. Тут включается seo и chatgpt.
7. В воскресение с утра подкаст выходит на всех площадках (включая аудио).
8. Я делаю посты в соц сети.
Время
Самый гемморой это договариваться о времени. У всех разные часовые зоны, дети, планы, отпуска. Поэтому я сразу сделал ход конем, создал отдельный календарь под запись с единственным слотом в неделю в cal.com. Ну и просто сбрасываю его гостю, пока договариваемся о подкасте, а гость уже сам вписывается когда ему удобно. Изредка мой слот им не подходит и только в таких случаях мы начинаем договариваться вручную о конкретном дне. Буквально вчера я записал такой подкаст, а вот сегодня уже записываюсь по расписанию (пришлось два раза в неделю, чтобы нагнать график).
Само планирование я делаю раз в месяц-два. Сажусь, выбираю гостей и начинаю всем писать. Обычно после этого календарь забивается на пару месяцев вперед. Кстати, это всегда удивляет гостей, когда они видят, что ближайший слот только через месяц. Далеко не у всех такой горизонт планирования.
Техника
Мы долго искали комбинацию инструментов, которая бы нас устроила и остановились на микрофоне podmic и встроенной в мак камере. Мы сознательно отказались от камеры сбоку, которую часто применяют в записи подкастов. Это довольно сложная конфигурация для нас и гостей, при этом влияние на просмотр подкаста это вроде как не оказывает.
Софт
Стандартная схема записи подкастов это довольно утомительное занятие. Скачать и вовремя и правильно запустить audacity, записывать видео с двух устройств и потом все это залить на файлообменник. Я сразу хотел от всего этого убежать. Перепробовав десяток разных сервисов, мы вернулись к старому доброму стримярду, который за прошедшие годы научился делать локальную запись (то есть интернет как в зуме уже не влияет) и автоматически закачивать ее в облако. Поэтому для гостя и меня запись выглядит так, мы заходим в студию стримярда, жмякаем record и в конце end record. Дожидаемся пока студия скажет что все залито (обычно это происходит моментально) и расходимся.
Для выкладки аудио подкаста юзаем https://transistor.fm/
Статистика прохождений курсов на https://code-basics.com/ru за последние 28 дней. Из очевидного: к праздникам активность падает, а питон традиционно самый востребованный курс. Из неожиданного: ts уделывает js, а c# занимает по популярности аж второе место
Правда надо учитывать, часть курсов есть номинально, то есть внутри уроков то кот наплакал. Но все это можно накоммитить прямо гитхаб: https://github.com/hexlet-basics
Правда надо учитывать, часть курсов есть номинально, то есть внутри уроков то кот наплакал. Но все это можно накоммитить прямо гитхаб: https://github.com/hexlet-basics
В этом выпуске мы поговорили с Борисом Трушиным — учителем математики с 26-летним стажем в «Фоксфорде» и автором популярных YouTube-каналов. Jбсудили, зачем программистам нужна математика, какие навыки она развивает и как алгоритмическое мышление помогает в любой профессии. Разобрали распространённые стереотипы о «гуманитариях» и IQ-клубах, выяснили, почему не стоит сводить образование к запоминанию формул и механическому списыванию задач.
Поговорили о роли родителей и преподавателей в поддержке интереса ребёнка, о том, как важно давать возможность учиться на ошибках и сосредоточиться на понимании, а не на оценках. Затронули тему ЕГЭ: что в нём работает, а что можно улучшить, чтобы экзамен проверял по-настоящему глубокие знания, а не умение «тренироваться под тест». И, конечно, обсудили, чем искусственный интеллект уже сегодня помогает учиться и какие риски несёт будущее, где ChatGPT и подобные системы становятся персональными ассистентами.
Вы узнаете живые истории из школьной практики, получите советы по развитию логики и сможете применить их в подготовке к любому вызову — от собеседования в IT до повседневных задач. Не пропустите — этот выпуск даст вам чёткое представление о том, как математика формирует мышление и какую роль в обучении играет человек и технологии!
https://youtube.com/watch?v=QVOA8QrgJvA
Альтернативные ссылки: Аудио | vk
Поговорили о роли родителей и преподавателей в поддержке интереса ребёнка, о том, как важно давать возможность учиться на ошибках и сосредоточиться на понимании, а не на оценках. Затронули тему ЕГЭ: что в нём работает, а что можно улучшить, чтобы экзамен проверял по-настоящему глубокие знания, а не умение «тренироваться под тест». И, конечно, обсудили, чем искусственный интеллект уже сегодня помогает учиться и какие риски несёт будущее, где ChatGPT и подобные системы становятся персональными ассистентами.
Вы узнаете живые истории из школьной практики, получите советы по развитию логики и сможете применить их в подготовке к любому вызову — от собеседования в IT до повседневных задач. Не пропустите — этот выпуск даст вам чёткое представление о том, как математика формирует мышление и какую роль в обучении играет человек и технологии!
https://youtube.com/watch?v=QVOA8QrgJvA
Альтернативные ссылки: Аудио | vk
YouTube
Математики vs. гуманитарии в IT-профессиях | Борис Трушин #43
В этом выпуске мы поговорили с Борисом Трушиным — учителем математики с 26-летним стажем в «Фоксфорде» и автором популярных YouTube-каналов. Обсудили, зачем программистам нужна математика, какие навыки она развивает и как алгоритмическое мышление помогает…
Обновления без боли за счет версионирования конфигов
У рельсы есть одна крутая фишка, которую, как мне кажется, было бы полезно адаптировать и другим фреймворкам (если еще нет). Она связана с тем, как работает конфигурация самого фреймворка при обновлениях на новые версии.
Представьте себе ситуацию, выходит новая версия вашего любимого фреймворка, вы обновляетесь и часть кода перестает работать нормально, потому что появились новые дефолты. Перед вами стоит выбор, либо пойти все поправить под новую версию, что не всегда возможно сделать за короткий срок, либо искать что за конфигурация поменялась и фиксировать ее в нужном для вас варианте.
В рейлс такая ситуация разруливается автоматически. По дефолту все будет работать ровно как вы ожидаете и ни один элемент конфигурации не изменится. Достигается это за счет того, что каждый конфигурационный набор версионируется вместе с самим фреймворком и при инициализации проекта, эта версия фиксируется:
Обратите внимание на строчку
Ссылки: Телеграм | Youtube | VK
У рельсы есть одна крутая фишка, которую, как мне кажется, было бы полезно адаптировать и другим фреймворкам (если еще нет). Она связана с тем, как работает конфигурация самого фреймворка при обновлениях на новые версии.
Представьте себе ситуацию, выходит новая версия вашего любимого фреймворка, вы обновляетесь и часть кода перестает работать нормально, потому что появились новые дефолты. Перед вами стоит выбор, либо пойти все поправить под новую версию, что не всегда возможно сделать за короткий срок, либо искать что за конфигурация поменялась и фиксировать ее в нужном для вас варианте.
В рейлс такая ситуация разруливается автоматически. По дефолту все будет работать ровно как вы ожидаете и ни один элемент конфигурации не изменится. Достигается это за счет того, что каждый конфигурационный набор версионируется вместе с самим фреймворком и при инициализации проекта, эта версия фиксируется:
module Hexlet
class Application < Rails::Application
config.load_defaults "8.0"
config.require_master_key = false
config.active_record.schema_format = :sql
config.active_record.query_log_tags_enabled = true
config.active_model.i18n_customize_full_message = true
end
end
Обратите внимание на строчку
config.load_defaults “8.0”
. Это значит, что вообще все параметры, будут такими, как они были в версии 8. Если обновится версия фреймворка, скажем до 9, то с самой конфигурацией ничего не случится, так как она зафиксирована. Дальше я смогу либо сразу переключиться на новое поведение поменяв общую версию конфига, либо делать это постепенно указывая нужные параметры сразу за этой строчкой, тогда они будут переписывать дефолты.Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Записал разбор видео Егора Бугаенко "Взлет и падение ооп". Изначально начал смотреть его для подготовки к подкасту с Егором, но не смог удержаться, чтобы не разобрать, а там есть о чем поговорить. Наслаждайтесь https://www.youtube.com/watch?v=GdQxgjj8lbY
Альтернативные ссылки: Аудио | vk
Альтернативные ссылки: Аудио | vk
YouTube
Разбор лекции Егора Бугаенко о настоящем ООП | Организованное программирование
В этом выпуске я открываю новое направление на канале — разборы. Начинаю с лекции Егора Бугаенко «Взлёт и падение ООП», которую он читал в Новосибирске.
✅ Подписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog
– Список…
✅ Подписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog
– Список…
ООП (неочевидные плюсы)
По следам последнего видео. У ООПшных языков, есть одна киллер фича и одно удобство, которые редко встречаются в других местах. Сейчас будет шок 🙂
Если у вас структура вызова сущность.метод, вы получаете автокомплит. Если у вас вызов функция(данные), то хрен вам, а не автокомплит. Как вам такое? Является ли это фишкой ооп? Вообще-то нет, да так совпало что в ооп это повсеместно, но это всего лишь вопрос синтаксиса языка. Зацените пример на go:
И на nim
и rust через трейты:
Ну и аналог (хотя и через классы) это экстеншены в Swift, Kotlin и C#
Кстати это довольно интересно, многие ассоцириуют синтаксис сущность.метод() только с ООП, но как вы видите, это вообще не так.
p.s. А как вы думаете, какая вторая деталь, про которую я упомянул в начале поста ? 🙂
Ссылки: Телеграм | Youtube | VK
По следам последнего видео. У ООПшных языков, есть одна киллер фича и одно удобство, которые редко встречаются в других местах. Сейчас будет шок 🙂
Если у вас структура вызова сущность.метод, вы получаете автокомплит. Если у вас вызов функция(данные), то хрен вам, а не автокомплит. Как вам такое? Является ли это фишкой ооп? Вообще-то нет, да так совпало что в ооп это повсеместно, но это всего лишь вопрос синтаксиса языка. Зацените пример на go:
type User struct {
Name string
}
func (u *User) Greet() {
fmt.Println("Hello,", u.Name)
}
func main() {
user := &User{Name: "Kirill"}
user.Greet() // автокомплит: .Greet
}
И на nim
type User = object
name: string
proc greet(u: User) {.method.} =
echo "Hello, ", u.name
let user = User(name: "Kirill")
user.greet() # автокомплит есть
и rust через трейты:
struct User {
name: String,
}
// trait описан отдельно от User
trait Greet {
fn greet(&self);
}
impl Greet for User {
fn greet(&self) {
println!("Hello, {}", self.name);
}
}
fn main() {
let user = User { name: "Kirill".to_string() };
user.greet(); // автокомплит срабатывает!
}
Ну и аналог (хотя и через классы) это экстеншены в Swift, Kotlin и C#
Кстати это довольно интересно, многие ассоцириуют синтаксис сущность.метод() только с ООП, но как вы видите, это вообще не так.
p.s. А как вы думаете, какая вторая деталь, про которую я упомянул в начале поста ? 🙂
Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Записал выпуск про TDD с Ильей Ильиных. Получилось очень насыщенно. Прошлись по мокам, пирамиде, зацепили фреймворки, orm, spring boot и кучу разных языков
https://www.youtube.com/watch?v=SEfAGnQURQs
Альтернативные ссылки: Аудио | vk
https://www.youtube.com/watch?v=SEfAGnQURQs
Альтернативные ссылки: Аудио | vk
YouTube
Нужно ли писать юнит-тесты? Дебаты о TDD, моках и бережливом тестировании | Илья Ильиных | #45
В этом выпуске мы поговорили с Ильёй Ильиных , автором канала «Куда войти», и вместе выяснили, что на самом деле скрывается за трёхбуквием TDD. Обсудили бережливое тестирование, разобрали плюсы и минусы diamond-подхода, поспорили о юнит-тестах, интеграционных…
Когда речь заходит про создание проектов, многие любят приводить в качестве иллюстрации этот круг со словами “ты можешь выбрать только два”. Но что если я скажу, что этот круг полная херня?
Считается что качественно это значит долго, но это далеко не всегда так. Например любой парикмахер вам скажет, что качественная прическа должна делаться быстро (допустим 20 минут). Если ее делают час, значит это не опытный парикмахер. Да бывают сложные прически, которые так быстро не сделаешь, но в таких ситуациях неопытный даже не возьмется, потому что не сможет этого сделать.
Примерно тоже самое происходит в коде. Качественное решение это не решение которое максимально расширяемое и способное выдерживать любые нагрузки. Это достаточно хорошее решение в рамках текущих условий и ближайших планов на изменение. Опытный разработчик справится с такими задачами за разумное время, а вот не опытный, как бы ни старался, в любой не тривиальной ситуации выдаст решение не очень (мягко говоря), просто потому что он не знает как правильно и не набил нужных шишек.
Теперь посмотрим на круг. Там написано качественно + дешево = долго. Так вот долго это всегда дорого, потому что вам надо платить людям зарплату, а это далеко не только разработчики. У вас либо быстро и дешево, либо долго и тогда дорого. Либо там на самом деле никто не работает и просто создается видимость долгого процесса.
Если бы схема с качественно + дешево = долго работала, то в мире существовали супер успешные бизнесы построенные на Джунах, но этого не происходит. Любой кто пытался так сделать, в какой-то момент понимал, что это тупиковый путь. Вы видели чтобы заказчики радовались то, что на той стороне Джуны? Они не просто не радуются, но еще и проводят собесы, чтобы убедиться, что на той стороне профессионалы.
Но вообще каждый элемент в той схеме зависит от контекста. Дешево относительно чего? Например наш подрядчик по SEO взял миллион за работу. Это дешево или нет? А если в результате его работы мы смогли заработать 10 миллионов? Тогда это крайне дешево. А если выручка не изменилась? Значит мы заплатили очень дорого, за плохую работу. Правда? То есть получается стоимость определяется не фактической ценой, а относительна результата, который заранее не всегда возможно предсказать точно.
Точно так же тут можно продолжать разносить все остальные связки, но это я оставлю на ваше усмотрение :)
Ссылки: Телеграм | Youtube | VK
Считается что качественно это значит долго, но это далеко не всегда так. Например любой парикмахер вам скажет, что качественная прическа должна делаться быстро (допустим 20 минут). Если ее делают час, значит это не опытный парикмахер. Да бывают сложные прически, которые так быстро не сделаешь, но в таких ситуациях неопытный даже не возьмется, потому что не сможет этого сделать.
Примерно тоже самое происходит в коде. Качественное решение это не решение которое максимально расширяемое и способное выдерживать любые нагрузки. Это достаточно хорошее решение в рамках текущих условий и ближайших планов на изменение. Опытный разработчик справится с такими задачами за разумное время, а вот не опытный, как бы ни старался, в любой не тривиальной ситуации выдаст решение не очень (мягко говоря), просто потому что он не знает как правильно и не набил нужных шишек.
Теперь посмотрим на круг. Там написано качественно + дешево = долго. Так вот долго это всегда дорого, потому что вам надо платить людям зарплату, а это далеко не только разработчики. У вас либо быстро и дешево, либо долго и тогда дорого. Либо там на самом деле никто не работает и просто создается видимость долгого процесса.
Если бы схема с качественно + дешево = долго работала, то в мире существовали супер успешные бизнесы построенные на Джунах, но этого не происходит. Любой кто пытался так сделать, в какой-то момент понимал, что это тупиковый путь. Вы видели чтобы заказчики радовались то, что на той стороне Джуны? Они не просто не радуются, но еще и проводят собесы, чтобы убедиться, что на той стороне профессионалы.
Но вообще каждый элемент в той схеме зависит от контекста. Дешево относительно чего? Например наш подрядчик по SEO взял миллион за работу. Это дешево или нет? А если в результате его работы мы смогли заработать 10 миллионов? Тогда это крайне дешево. А если выручка не изменилась? Значит мы заплатили очень дорого, за плохую работу. Правда? То есть получается стоимость определяется не фактической ценой, а относительна результата, который заранее не всегда возможно предсказать точно.
Точно так же тут можно продолжать разносить все остальные связки, но это я оставлю на ваше усмотрение :)
Ссылки: Телеграм | Youtube | VK
Организованное программирование | Кирилл Мокевнин pinned «Записал разбор видео Егора Бугаенко "Взлет и падение ооп". Изначально начал смотреть его для подготовки к подкасту с Егором, но не смог удержаться, чтобы не разобрать, а там есть о чем поговорить. Наслаждайтесь https://www.youtube.com/watch?v=GdQxgjj8lbY …»
В этом выпуске мы поговорили с Егором Бугаенко — автором «Elegant Objects» и сторонником «честного» ООП-мышления. Он раскрыл, почему классическое объектно-ориентированное программирование — это не архитектура, а иллюзия порядка, за которой скрывается хаос.
Разобрали, почему null, static и наследование — главные разрушители систем, как мышление «в классах» ведёт к техдолгу, и почему ORM прячет от нас реальные ошибки в работе с данными. Егор настаивает: код должен быть сконструирован, а не написан, иначе система становится неуправляемой — особенно в эпоху LLM, когда ИИ сыплет автопатчами и код перестаёт быть осмысленным.
Также обсудили:
Почему композиция объектов — основа устойчивой архитектуры
Как мыслить модулями, а не строками кода
Что такое Fail Fast и зачем системе «падать» сразу
Почему архитектурное мышление — навык разработчика будущего
Как LLM усиливают хаос, если нет модели
Роль дизайн-долга и как он убивает бизнес-процессы
https://www.youtube.com/watch?v=X1HSGEADAhE
Альтернативные ссылки: Аудио | vk
Разобрали, почему null, static и наследование — главные разрушители систем, как мышление «в классах» ведёт к техдолгу, и почему ORM прячет от нас реальные ошибки в работе с данными. Егор настаивает: код должен быть сконструирован, а не написан, иначе система становится неуправляемой — особенно в эпоху LLM, когда ИИ сыплет автопатчами и код перестаёт быть осмысленным.
Также обсудили:
Почему композиция объектов — основа устойчивой архитектуры
Как мыслить модулями, а не строками кода
Что такое Fail Fast и зачем системе «падать» сразу
Почему архитектурное мышление — навык разработчика будущего
Как LLM усиливают хаос, если нет модели
Роль дизайн-долга и как он убивает бизнес-процессы
https://www.youtube.com/watch?v=X1HSGEADAhE
Альтернативные ссылки: Аудио | vk
YouTube
Егор Бугаенко про будущее программирования | Организованное программирование #46
В этом выпуске мы поговорили с Егором Бугаенко — автором «Elegant Objects» и сторонником «честного» ООП-мышления. Он раскрыл, почему классическое объектно-ориентированное программирование — это не архитектура, а иллюзия порядка, за которой скрывается хаос.…
Вы уже проходили? https://gosuslugi.ru/itskills Я только что получил сертификат по PHP (начинающий) с вопросами где нужно знать SQL и Веб (html + http). Защита от ИИ в стиле: "не используйте ИИ". Как бы там ни было, будем добавлять подготовку на Хекслет (ибо начнут спрашивать)
Конфигурация: данные vs код
Существует два основных подхода к описанию конфигурации: использовать код на каком-то языке (возможно dsх) или описывать все через универсальные форматы (yaml, json).
Например большинство линтеров и форматеров используют конфигурацию через json файлы. Хотя в JS экосистеме происходит сдвиг в сторону написания конфигурации для таких инструментов в js файлы. Системы сборки чаще делают кодом, например gradle или классический Make, хотя тот же maven использует xml.
Оба подхода широко распространены даже в рамках одной задачи, но разных стеках. Выбор не всегда очевиден и любой разработчик, которому приходится его делать, находится какое-то время в замешательстве.
Конфигурация на данных кажется классной идеей и практически незаменима, когда нам надо шарить ее между разными экосистемами. Классный пример это openapi спека. Она нужна и на беке и во фронте и внешним клиентам, которые пишутся на бог знает чем. При том что писать ручками саму спеку еще тот геморрой, поэтому вокруг созданы целые языки (не тьюринг полные) типа typespec, которые умеют генерить openapi спеку.
Но у такого подхода есть и масса ограничений. Во-первых сразу забываем про синхронизацию с кодом. Если конфигурация содержит имена модулей, классов, в целом какие-то связи с кодом, то в lsp придется встраивать доп поддержку, что вообще врядли кто-то будет делать. Во-вторых, есть места, где нужно иметь какое-то кастомное поведение, типовая задача замутить что-то этакое во время сборки. Если у вас конфигурация описана данными, то вы физически не сможете реализовать кастомное поведение без расширение языка конфигурации. Такое тоже, кстати, встречается. Возьмите ansible, можно написать свои модули.
Если описывать все это кодом, то мы получаем возможность достаточно легко писать кастомную логику, у нас включается lsp, начинает работать автокомплит проверка типов и многое другое. Но пожалуй главная проблема, в том что такой уровень свободы приводит к ситуациям, когда конфигурация превращается в полноценный код, который хрен поймешь и который желательно еще и тестировать из-за его сложности. А уж отладку каких-нибудь хитрых штук многие вспоминают как в страшном сне.
Иногда это приводит к решению пойти третим путем. Создать под конфигурацию свой собственный язык, который и конфигурацию на выходе может дать и при этом позволяет делать больше и удобнее чем тот же json. Например terraform. Но это не самый легкий путь, потому что для него нужно писать целую экосистему инструментов, но для фундаментальных вещей, как мы видим, это работает. При этом даже терраформ довольно ограничен и есть альтернативные решения, где все по настоящему программируется.
Так и что выбирать и на что ориентироваться? Как будто универсального ответа нет, видно как инструменты постоянно прыгают туда сюда и часто есть альтернатива для тех кто хочет гибкость (язык) или наоборот строгость (данные) со всеми плюсами и минусами описанными выше
p.s. Лиспофилы щас бы сказали что у нас два в одном и конфигурация и код описываются данными. Но это немного лукавство, потому что код как данные в лиспах имеет значение только внутри самих лиспов при написании макросов. Для внешних систем это не данные, которые можно взять и использовать
Ссылки: Телеграм | Youtube | VK
Существует два основных подхода к описанию конфигурации: использовать код на каком-то языке (возможно dsх) или описывать все через универсальные форматы (yaml, json).
Например большинство линтеров и форматеров используют конфигурацию через json файлы. Хотя в JS экосистеме происходит сдвиг в сторону написания конфигурации для таких инструментов в js файлы. Системы сборки чаще делают кодом, например gradle или классический Make, хотя тот же maven использует xml.
Оба подхода широко распространены даже в рамках одной задачи, но разных стеках. Выбор не всегда очевиден и любой разработчик, которому приходится его делать, находится какое-то время в замешательстве.
Конфигурация на данных кажется классной идеей и практически незаменима, когда нам надо шарить ее между разными экосистемами. Классный пример это openapi спека. Она нужна и на беке и во фронте и внешним клиентам, которые пишутся на бог знает чем. При том что писать ручками саму спеку еще тот геморрой, поэтому вокруг созданы целые языки (не тьюринг полные) типа typespec, которые умеют генерить openapi спеку.
@route("/stores")
interface Stores {
list(@query filter: string): Store[];
read(@path id: Store): Store;
}
Но у такого подхода есть и масса ограничений. Во-первых сразу забываем про синхронизацию с кодом. Если конфигурация содержит имена модулей, классов, в целом какие-то связи с кодом, то в lsp придется встраивать доп поддержку, что вообще врядли кто-то будет делать. Во-вторых, есть места, где нужно иметь какое-то кастомное поведение, типовая задача замутить что-то этакое во время сборки. Если у вас конфигурация описана данными, то вы физически не сможете реализовать кастомное поведение без расширение языка конфигурации. Такое тоже, кстати, встречается. Возьмите ansible, можно написать свои модули.
Если описывать все это кодом, то мы получаем возможность достаточно легко писать кастомную логику, у нас включается lsp, начинает работать автокомплит проверка типов и многое другое. Но пожалуй главная проблема, в том что такой уровень свободы приводит к ситуациям, когда конфигурация превращается в полноценный код, который хрен поймешь и который желательно еще и тестировать из-за его сложности. А уж отладку каких-нибудь хитрых штук многие вспоминают как в страшном сне.
Иногда это приводит к решению пойти третим путем. Создать под конфигурацию свой собственный язык, который и конфигурацию на выходе может дать и при этом позволяет делать больше и удобнее чем тот же json. Например terraform. Но это не самый легкий путь, потому что для него нужно писать целую экосистему инструментов, но для фундаментальных вещей, как мы видим, это работает. При этом даже терраформ довольно ограничен и есть альтернативные решения, где все по настоящему программируется.
Так и что выбирать и на что ориентироваться? Как будто универсального ответа нет, видно как инструменты постоянно прыгают туда сюда и часто есть альтернатива для тех кто хочет гибкость (язык) или наоборот строгость (данные) со всеми плюсами и минусами описанными выше
p.s. Лиспофилы щас бы сказали что у нас два в одном и конфигурация и код описываются данными. Но это немного лукавство, потому что код как данные в лиспах имеет значение только внутри самих лиспов при написании макросов. Для внешних систем это не данные, которые можно взять и использовать
Ссылки: Телеграм | Youtube | VK