при таком подходе разраб не видел новый код)

Свят-свят

При этом он его и не запускал

Вообще, мне кажется, что такие кейсы - они уже не в компетенции гошного компилятора

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

ненене, не CI, а make-скрипт

Если оно реально требует контроля, то уж билд-систему пилить всяко надо

ненене, не CI, а make-скрипт

это про другое) искать не буду, о речь шла про ci

Ага, читал

Там было про "сгенеренный код кодом не считается, и держать его в Гите не надо"

Вот такая позиция, вроде, была

Вот такая позиция, вроде, была

и что-то такое было. но это все разные кейсы. многое обсудили)

Там было про "сгенеренный код кодом не считается, и держать его в Гите не надо"

моя позиция была такова: "сгенеренный код - это тоже код, но не исходный, потому-что его не человек писал. Исходным кодом считается только то, что писал человек или сопостовимый интеллект" основываясь на https://softwareengineering.stackexchange.com/a/361460

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

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

... но при этом кешировать дабы снизить её стоимость.

А ci/не ci, коммитить/не коммитить - это уже другое дело.

... но при этом кешировать дабы снизить её стоимость.

Да, с кешированием разумеется.

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

И прошу обратить внимание что тут написано "должна запускаться при компиляции", а не "должна запускаться только при компиляции".

И прошу обратить внимание что тут написано "должна запускаться при компиляции", а не "должна запускаться только при компиляции".

однако с этим тоже есть небольшая проблемка... autocompletion будет партачить если вручную не запускать

ну для автокомплита уж руками, или может ide сможет

ну для автокомплита уж руками, или может ide сможет

в таком случае лучше чтоб IDE генерила при сохранении исходника

вот да

но, это не отменяет нужду генерации при сборке, просто она пройдёт из кеша

точнее можно при сохранении запускать каждый раз генерацию

если есть кеширование, то будет быстро

и при сохранении исходника и при сборке

точнее можно при сохранении запускать каждый раз генерацию

При сохранении чего?

При сохранении чего?

Но ведь же можно прочитать сообщение выше.

и при сохранении исходника и при сборке

вот это вот

Какого исходника?

Любого файла? Файла го? Джисон?

Я даже не знаю как на это реагировать

ну ведь можно же наверное прочитать сообщения выше и понять о чём идёт речь

Я почитал, там не сказано, там просто говорится что при изменении исходника

Схема на основе которой генерится коды может быть в JSON, xml, yaml, а может в го коде

Вот я и спрашиваю при изменении чего должна запускаться генерация

Я почитал, там не сказано, там просто говорится что при изменении исходника

из контекста понятно что не всех файлов, "исходника" -> одного, значит того, из которого генерится код, не "исходников"

из контекста понятно что не всех файлов, "исходника" -> одного, значит того, из которого генерится код, не "исходников"

Вопрос как раз в этом - как иде поймёт после изменения какого файла надо запускать генерацию?

Вопрос как раз в этом - как иде поймёт после изменения какого файла надо запускать генерацию?

make скрипт

go run make.go -g

оптимизировать можно дальше, конечно

А зачем? Почему просто не запустить генерацию, если мейк файл все равно руками запускаем?

в VSC есть такие полезные вещи как workspaces, где можно прописать выполнение скрипта на разные файлы: generated_api.json -> go run make.go -g generated_api.json

Автоматизация ради автоматизации без реальной пользы и это я не про vsc

Автоматизация ради автоматизации без реальной пользы и это я не про vsc

из оперы "если мнение не моё - значит оно неверное"

из оперы "если мнение не моё - значит оно неверное"

Так ты же не смог объяснить в чем польза, запускаем мейк файл руками, чтобы не запускать генерацию руками Ну охереть автоматизатор)))

Так ты же не смог объяснить в чем польза, запускаем мейк файл руками, чтобы не запускать генерацию руками Ну охереть автоматизатор)))

аргументация вся озвучена, вернее описана, выше. ты совершенно не понял о чём идёт речь

Watch "JavaScript: Understanding the Weird Parts - The First 3.5 Hours" on YouTube https://youtu.be/Bv_5Zv5c-Ts

"The first 3.5 hours"

аргументация вся озвучена, вернее описана, выше. ты совершенно не понял о чём идёт речь

Я как раз понимаю, а ты теоретизируешь и высасываешь из пальца

Watch "JavaScript: Understanding the Weird Parts - The First 3.5 Hours" on YouTube https://youtu.be/Bv_5Zv5c-Ts

How to write good JavaScript code, a step-by-step instruction: 1. Install TypeScript... *offtop*

Я как раз понимаю, а ты теоретизируешь и высасываешь из пальца

считай как хочешь

А почему может не работать ldflags? Делаю в пакете system переменную var Branch string, собираю через go build -ldflags "-X system.Branch=master" и при запуске в переменной пустая строка все равно.

эм

насколько я помню это работает только для пакета main

но могу нагло врать

нагло

это работает везде

но могу нагло врать

Врешь)

Вот у меня в main работает а в отдельном пакете почему-то нет.

А почему может не работать ldflags? Делаю в пакете system переменную var Branch string, собираю через go build -ldflags "-X system.Branch=master" и при запуске в переменной пустая строка все равно.

если я правильно помню, нужно указывать полный путь к package

И правда, так работает.

что-то попробывал с DI

ну "такое"

ERROR: S client not available

как мокать такие хедлеры не понятно

придется мокать весь "супер обьект"

придется мокать весь "супер обьект"

в чем проблема?

покажи свой хэндлер

type UsersHandler struct { app *application.MyApplication } func (h * UsersHandler) Index(w http.ResponseWriter, r *http.Request, p httprouter.Params) { ... h.app.GetResponce().EmptySuccess(w) }

ну что-то в этом стиле

самый минимальный показал

ну и конструктор конечно: func NewClinicHandler(app *application.MyApplication) *UsersHandler { return &UsersHandler{ app: app, } }

хэндлер у тебя зависит от приложения? странно

обычно он зависит например от db-слоя, сервисов

у меня есть пакет application

в нем в фабрике - NewApplication стартуют все подключения, все что при инициализации делается

так является ли application зависимостью для хэндлера?

они свои "коннекты" кидают в стуктуру и эта структура уже начинает везде фигурировать

так является ли application зависимостью для хэндлера?

она прозрачно прокидывает во все связи

на самом деле там есть абстракция webserver, потом уже от нее идет прокидывания в хедлер того же самого

я пытался избавиться от нудной правки зависимостей каждый раз

это такое аналог DI

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

а что есть dic?

di container

контейнер твоих зависимостей

так

а как тогда правильно? если мы хотим таки DI

прокидывать не dic, а конкретные зависимости

а зачем нам тогда DI?

а зачем нам тогда DI?

в вики прочти)

да читал

я думал что в этом и заключается

что мы контейнер лихо пихаем везде и забывает про зависимости

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

Не понял позицию, то есть делать руками DI это хорошо (оно и понятно), а взять fx от uber уже плохо?

Не понял позицию, то есть делать руками DI это хорошо (оно и понятно), а взять fx от uber уже плохо?

нет, это вообще не про то речь