копипастить - плохая идея

копипастить - плохая идея

копипаст это как бы технология го, без нее ни как

Stackoverflow Driven Development

Ахаха)) Ну годный подход

лучше посмотреть способ, понять что да как и написать нормально

копипаста != плохо, если что)

Коллеги

@onokonem а вы если я ничего не путаю со сваггером работали?

Пацаны, те у кого стоит вимгоу, есть трабл с автокомплитом. Упорно выдает панику, когда пытаюсь автокомплить

go 1.8, vim 8.0

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

ты себе зрение еще не посадил синим скрином?

народ я туплю, неед хелп

dep ensure генерирует же Gopkg.toml ?

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

а потом уже Gopkg.lock создать

dep init, же

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

это учебный код

@onokonem а вы если я ничего не путаю со сваггером работали?

Работал

ты себе зрение еще не посадил синим скрином?

Чисто ностальгирую по досу

дос черный был

это фар синий был

Работал

а можно вам глупый вопрос в личку написать? не могу найти в доках на него ответа.

Можно

дос черный был

Синий был нортон коммандер, который был первый

ну фар, нортом да

хотя фар по идее не дос

Не дос

Синий был нортон коммандер, который был первый

не, он черный был.

Крч первый мой комп имел такую тему

сваггер для крупных проектов - так себе идея

особенно если использовать вложенности и ссылки для "оптимизации" yaml

у нас там накрутили в ООП стиле все на ссылках на другие части

километровые блин структуры получились, он же 1 к 1

сваггер для крупных проектов - так себе идея

Думает Александр Попов

как добиться выполнение принципа DIP, у меня верхний уровень, пользуется статой нижнего уровня, стату можно в интерфейс загнать, но там еще и структура данных с методом для хранения этих данных

Думает Александр Попов

ну я лично юзал

особенно если использовать вложенности и ссылки для "оптимизации" yaml

со ссылками я уже разробрался, получилось хорошо и красиво

кстати сваггер корректно проблему "исчезающих полей" так и не решили

а схема json у нас статическая, если поле не обьявлено то его все равно надо

оно должно быть по крайне мере null

особенно весело с int у которых значение по умолчанию 0 и они "пропадают"

*int

Да нет, не надо. Но и проблемы такой нет.

ну как нет

есть у вас поле count для какого либо клиента

оно бах и пропало из выдачи

на JS например, а оно бабах и сломалось

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

Ну так отключите omitempty

а он не отключаемый 🙂

Насколько я понял - для required он невключаемый

это да, но делать поле обязательным это странно

Так оно у вас обязательное же?

неа с чего бы это?

например у пользователя не знаю там, количество яблок

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

Желание сделать поломанную спеку - корень всех бед

ну JS клиенты они такие, им не все всегда удобно

Гонево

плюс сваггера в том, что есть общая спека, по которой тот же js может сгенерить клиент, который будет слать все поля описанные в спеке. если фронтэнд начинает отходить от спеки и заниматься самодеятельностью, то тут и начинаются описанные проблемы

ну бывает что есть некие бизнес требования

и они вылезают за "красиво"

и тут начинаются проблемы

как только мы делаем что-то "поперек" так сразу отгребаем

а менять требовать под "у нас так не работает" это по классике "хвост виляет собакой"

сколько человекочасов было затрачено на "костыли" в разных библиотеках, потому что надо сделать именно так и не иначе а гибкости нет - не пересчитать, поэтому предпочитаю чистый код

ну бывает что есть некие бизнес требования

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

а спецификацию даже не мы пишем

форматы идут "сверху" как по мнению будет хорошо для бизнес требований к сервису

так это же ничего не меняет) кто мешает генерировать код в одном формате?

я привел только один из примеров выше

классическое appleCount

можно ли обойти? можно.

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

лан, это уже холивар какой-то не по теме, извини

ну по теме сваггера

я просто сказал что он не достаточно гибкий для больших проектов

а что есть "большой проект"?

ну по обьему он конечно не очень большой, где то на 7 сущностей