spec‑first является единственно-верным подходом, как бы это категорично не звучало, потому как если контракт является производной от кода - это уже не контракт. как-то приводил пример с банком - представьте, что банк хранит ваши деньги, но не по условиям договора/контракта, который вы изначально с ним заключили (и банк его обязан соблюдать), а по сегодняшнему желанию банка, строго по настроению его менеджеров (читай - тому, как в конкретный момент решил написать разработчик). контракты API слоя - та же песня.
Но у них общее свойство: они хотят, чтобы вы писали код по‑другому
Та с чего же такой вывод? Нет, и еще раз нет, и более того - вы вольны кастомизировать шаблонизацию генерируемого кода (если мы говорим про тот же oapi‑codegen), что было так, как хочется вам (главное, опять же - понимать что ваши кастомизации не должны “ломать” контракт, и только).
p.s. хорошо бы помечать в readme и в статье, что код был написан ии (частично/полностью; мне показалось что почти полностью), и не жалеть уж токены на написание unit-тестов.
ansible + k3s + helm/argo? (если не облака, а свое железо)
ansible + docker swarm? (если хочется попроще)
Все они хорошо проверены временем, известны, и достаточно просты. Да и тулинга вокруг них полно, включая всякие web морды, и будет вам rolling update из коробки, да и много чего сверху
Позвольте стать первым в комментариях к вашему труду (спасибо за него, вы не дурно излагаете!), кто скажет что использовать слово “framework” в одном предложении с “Go” сразу вызовет если не волну, то некоторый всплеск негодования - почти наверняка.
Хотел бы задать лишь один вопрос - чем (на ваш взгляд) плох подход “поглядывай на project-layout, когда сомневаешься как разместить файлики, да на большие проекты типа k8s/docker, но воспринимай их просто лучшую устоявшуюся практику, но не ограничивай себя ими”?
разрешите поинтересоваться, а в чем в (общем и) целом смысл?
если вы устали от рутины шлепать однотипные сервисы - может быть проблема в архитектуре?
если цель это экономия времени - вы действительно выпускаете в прод то что llm написало, само “протестировало” и сказало “я сделаль” без детального ревью и сотен “u did a bulshit, coz … and … should be …”
если llm пишет код лучше чем тот, кто её использует, то (токсичный текст тут был замечен НЛО и удален)
нет, вы не подумайте, ваш покорный не из лагеря “llm-на-вилы”, сам пользуюсь каждый день, но с оговоркой - только для ревью написанного кода (руками), перевода текста с ну-понятно-но-коряво на православно-английский и изредка траблшутинга (понять какого хрена контекст отменился где-то где не надо в реально сложной цепочке, или пошукать в тернистой SDK или объемной доке подсказки).
Ох, как я вас понимаю, дорогой топикстартер. С год/два назад в своем продуктовом проекте тоже написал свой билдер (qb), а сейчас, когда все более и менее устаканилось - буду переписывать обратно на raw sql, ибо все билдеры по итогу от лукавого. В отличии от эпохи “до билдера” - будет минимум рантайм манипуляций, все по максимуму на go generate + embed.
Та я к тому, что так и нак нужен секрет для доступа к api - в вашем случае от gitlab, с случае с vault/doppler - он него. Вот только последние как раз спроектированы для работы с секретами, а gitlab env он даже называется именно env, и не очень хорош для работы с чувствительными данными, как будто в вашем случае он несколько не по прямому назначению используется что-ли (хотя и сам так и делал, и делаю в мелких проектах, но постоянно грызет совесть за это).
Так же не покидает ощущение что ваш комментарий сгенерирован ии - длинные дефисы, нет разговорных оборотов, слишком "вылизанный" текст. Я прав, или мне это показалось?
Чтоб не забывать запускать кодоген, часто достаточно не хранить сгенерированные файлы под гитом, и писать тесты ;) В общем и целом, выбрали бы вы дорожку с генерацией кода - ваш покорный (и, уверен, много кто еще) прониклись и глубже бы стали смотреть ваш проект. И сравнивать его с sqlc, разумеется :D
Но магия ключей мап, и оверхед на запуск как минимум для меня выглядят как редфлаги, заставляющие пройти мимо :(
Вы наверняка рассматривали вероятность использования кодогена, чтоб не зависеть от магических ключей мапы и не иметь оверхеда на запуск, когда надо добро все прочитать да распарсить. Почему вместо генерации обертки над sql в виде как раз go кода отказались? Ведь такой подход выглядел бы логичнее, строже, и гибче?
В дополнение, крайние несколько лет являюсь адептом секты "config-less", когда все что нужно сконфигурировать - должно иметь cli/env ручки для этого, и знаете - этот подход более чем жизнеспособен! И строгие правила, и валидация, и генерация документации из этого кода - прям хорошо. Да что уж говорить - великий и могучий Traefik и тот умеет себя конфигурировать флагами без сильной боли ниже поясницы (если понимаешь что делаешь), а он тот еще комбаин.
Ну и раз уж мы здесь, то крохотный совет - лучше не использовать hub.docker.com как единственное место, где живет образ. ghcr.io + quay.io (в дополнение в hub-у) есть наше все, да и крайнее падение hub-а показало кто делает мирроринг, а кто нет ;)
ctrl+f "max" ничего не показал, у вас именно separate repository а не форк (но в ридми есть ссылка, правда), да и структура репозитория не мэтчится с оригинальным даже визуально, отсюда и поспешный вывод :)
Как-то мне приходилось собирать проект на ноде, который в зависимоятях тянул пакет что использует python, который через свое подобие FFI запускал функции из rust. А потом его надо было собрать под arm или какая-то из зависимостей обновилась, но не ее зависимость.. Ад был тот еще. Да и не только с нодовыми проектами в такое влетал.
Позиция заключается в том, что "если ты можешь - это не значит что ты должен" + Hell is paved with good intentions. Если ты хочешь делать что-то подобное то, скорее всего, твоя дорога сворачивает не туда. Да, ваш проект крохотный, но импакт и пример другим заставит их думать "ну норм же, вон, другие так делают".
Очень много инструментов использует подобный подход
Скорее всего тех, где просто нет возможности иначе. Вот нет её. Вот совсем. Ну невозможно иначе. Никак, ваапще. Если есть хоть малейшая возможность не раздувать зависимости - не надо делать этого. Пардон, но вы имеете желание ради парсинга строк и сисколов создания директорий/записи файлов, в которые нода умеет прекрасно - тянуть целиком компилятор другого языка с исходниками собственной тулы, да компилить на целевой тачке во время установки зависимостей. Неужели этого не смущает по умолчанию? ;)
spec‑first является единственно-верным подходом, как бы это категорично не звучало, потому как если контракт является производной от кода - это уже не контракт. как-то приводил пример с банком - представьте, что банк хранит ваши деньги, но не по условиям договора/контракта, который вы изначально с ним заключили (и банк его обязан соблюдать), а по сегодняшнему желанию банка, строго по настроению его менеджеров (читай - тому, как в конкретный момент решил написать разработчик). контракты API слоя - та же песня.
Та с чего же такой вывод? Нет, и еще раз нет, и более того - вы вольны кастомизировать шаблонизацию генерируемого кода (если мы говорим про тот же oapi‑codegen), что было так, как хочется вам (главное, опять же - понимать что ваши кастомизации не должны “ломать” контракт, и только).
p.s. хорошо бы помечать в readme и в статье, что код был написан ии (частично/полностью; мне показалось что почти полностью), и не жалеть уж токены на написание unit-тестов.
Разрешите поинтересоваться, почему не:
terraform + k3s + helm/argo? (если хочется хорошо)
ansible + k3s + helm/argo? (если не облака, а свое железо)
ansible + docker swarm? (если хочется попроще)
Все они хорошо проверены временем, известны, и достаточно просты. Да и тулинга вокруг них полно, включая всякие web морды, и будет вам rolling update из коробки, да и много чего сверху
Наконец-то интересная и искренне любопытная статья, а не очередной нейро-слоп. Спасибо!
Вы хабами ошиблись. Вместо всех перечисленных вам, видимо, только в один - https://habr.com/en/hubs/i_am_advertising/
Продаю гараж, за ценой - в личку
Простите, вы, блин, серьезно?
Или это вам имитация интетелекта так написала, а вы “а давай, чего там проверять, коммит, пуш, в релиз”?
Позвольте стать первым в комментариях к вашему труду (спасибо за него, вы не дурно излагаете!), кто скажет что использовать слово “framework” в одном предложении с “Go” сразу вызовет если не волну, то некоторый всплеск негодования - почти наверняка.
Хотел бы задать лишь один вопрос - чем (на ваш взгляд) плох подход “поглядывай на project-layout, когда сомневаешься как разместить файлики, да на большие проекты типа k8s/docker, но воспринимай их просто
лучшуюустоявшуюся практику, но не ограничивай себя ими”?разрешите поинтересоваться, а в чем в (общем и) целом смысл?
если вы устали от рутины шлепать однотипные сервисы - может быть проблема в архитектуре?
если цель это экономия времени - вы действительно выпускаете в прод то что llm написало, само “протестировало” и сказало “я сделаль” без детального ревью и сотен “u did a bulshit, coz … and … should be …”
если llm пишет код лучше чем тот, кто её использует, то (токсичный текст тут был замечен НЛО и удален)
нет, вы не подумайте, ваш покорный не из лагеря “llm-на-вилы”, сам пользуюсь каждый день, но с оговоркой - только для ревью написанного кода (руками), перевода текста с ну-понятно-но-коряво на православно-английский и изредка траблшутинга (понять какого хрена контекст отменился где-то где не надо в реально сложной цепочке, или пошукать в тернистой SDK или объемной доке подсказки).
я правда пытаюсь понять - зачем?
Ох, как я вас понимаю, дорогой топикстартер. С год/два назад в своем продуктовом проекте тоже написал свой билдер (qb), а сейчас, когда все более и менее устаканилось - буду переписывать обратно на raw sql, ибо все билдеры по итогу от лукавого. В отличии от эпохи “до билдера” - будет минимум рантайм манипуляций, все по максимуму на go generate + embed.
Видимо, вы ошибке опубликовали и в хаб *Go, хорошо бы это поправить. И удачно вам победить все жизненные передряги!
Та я к тому, что так и нак нужен секрет для доступа к api - в вашем случае от gitlab, с случае с vault/doppler - он него. Вот только последние как раз спроектированы для работы с секретами, а gitlab env он даже называется именно env, и не очень хорош для работы с чувствительными данными, как будто в вашем случае он несколько не по прямому назначению используется что-ли (хотя и сам так и делал, и делаю в мелких проектах, но постоянно грызет совесть за это).
Так же не покидает ощущение что ваш комментарий сгенерирован ии - длинные дефисы, нет разговорных оборотов, слишком "вылизанный" текст. Я прав, или мне это показалось?
Разрешите вопрос - а почему не мигрировали с env в сторону vault/doppler/etc? (может я был не внимателен и не заметил ответа в теле поста...)
Чтоб не забывать запускать кодоген, часто достаточно не хранить сгенерированные файлы под гитом, и писать тесты ;)
В общем и целом, выбрали бы вы дорожку с генерацией кода - ваш покорный (и, уверен, много кто еще) прониклись и глубже бы стали смотреть ваш проект. И сравнивать его с sqlc, разумеется :D
Но магия ключей мап, и оверхед на запуск как минимум для меня выглядят как редфлаги, заставляющие пройти мимо :(
Удачи с проектом, не бойтесь экспериментировать!
Вы наверняка рассматривали вероятность использования кодогена, чтоб не зависеть от магических ключей мапы и не иметь оверхеда на запуск, когда надо добро все прочитать да распарсить. Почему вместо генерации обертки над sql в виде как раз go кода отказались? Ведь такой подход выглядел бы логичнее, строже, и гибче?
Нет CI
Нет тестов
Комментарии в коде на русском языке
Раздувает зависимости (мне не нужна монго в моем проекте, но заюзав ваш пакет - клиент для монги все равно будет тянуться), идеал - 0 зависимостей
Когда напишите тесты, увидите где у вас гонки (даже в stderr/stdout нельзя писать без синхронизации)
Удачи с проектом!
В дополнение, крайние несколько лет являюсь адептом секты "config-less", когда все что нужно сконфигурировать - должно иметь cli/env ручки для этого, и знаете - этот подход более чем жизнеспособен! И строгие правила, и валидация, и генерация документации из этого кода - прям хорошо. Да что уж говорить - великий и могучий Traefik и тот умеет себя конфигурировать флагами без сильной боли ниже поясницы (если понимаешь что делаешь), а он тот еще комбаин.
Ну и раз уж мы здесь, то крохотный совет - лучше не использовать hub.docker.com как единственное место, где живет образ. ghcr.io + quay.io (в дополнение в hub-у) есть наше все, да и крайнее падение hub-а показало кто делает мирроринг, а кто нет ;)
ctrl+f "max" ничего не показал, у вас именно separate repository а не форк (но в ридми есть ссылка, правда), да и структура репозитория не мэтчится с оригинальным даже визуально, отсюда и поспешный вывод :)
Просто оставлю это здесь - https://github.com/crazy-max/swarm-cronjob
Как-то мне приходилось собирать проект на ноде, который в зависимоятях тянул пакет что использует python, который через свое подобие FFI запускал функции из rust. А потом его надо было собрать под arm или какая-то из зависимостей обновилась, но не ее зависимость.. Ад был тот еще. Да и не только с нодовыми проектами в такое влетал.
Позиция заключается в том, что "если ты можешь - это не значит что ты должен" + Hell is paved with good intentions. Если ты хочешь делать что-то подобное то, скорее всего, твоя дорога сворачивает не туда. Да, ваш проект крохотный, но импакт и пример другим заставит их думать "ну норм же, вон, другие так делают".
Скорее всего тех, где просто нет возможности иначе. Вот нет её. Вот совсем. Ну невозможно иначе. Никак, ваапще. Если есть хоть малейшая возможность не раздувать зависимости - не надо делать этого. Пардон, но вы имеете желание ради парсинга строк и сисколов создания директорий/записи файлов, в которые нода умеет прекрасно - тянуть целиком компилятор другого языка с исходниками собственной тулы, да компилить на целевой тачке во время установки зависимостей. Неужели этого не смущает по умолчанию? ;)
Пожалуйста, не надо так делать :( Хотя, npm-экосистему уже врятли что-то спасет..