другого, к сожалению, нет, только строковый

стектрейс не в виде строки ?

в виде сериализованного линкед листа, конечно же

в виде сериализованного линкед листа, конечно же

двунаправленого или однонаправленого ?

конечно двунаправленного

конечно двунаправленного

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

(даже не знаю, как тебе намекнуть, что это троллинг)

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

будет хранится в виде мапы map[string]{ value, next_ptr }

где ключ — адрес ячейки, а next_ptr — строка, указывающая на следующую ячейку

все, что под рукой - из живых проектов. но вот я обычно нуждаюсь в типе, значении, сообщении и стектрейсе

а что за значение ?

Вашими молитвами, спасибо, разорбрался. @ejilay @di3young @zelenin всем спасибо ребята.

Вашими молитвами, спасибо, разорбрался. @ejilay @di3young @zelenin всем спасибо ребята.

грац

где ключ — адрес ячейки, а next_ptr — строка, указывающая на следующую ячейку

мьютексы использбуете или собственую имплементацию мапы ?

а что за значение ?

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

мьютексы использбуете или собственую имплементацию мапы ?

странный вопрос, не очень понял

/save. Спасибо

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

ну вобщем то вы пытаетесь вынести контект ошибки за пределы места где произошла ошибка. по моему мнению если вы не смогли обработать ее на месте, то не сможете ее нормально обработать и выше. тоесть ошибки вида "x компьютеров запустились, y компьютеров отказали" не должно обрабатываться в зависимости от значения x и y.

а чо, этого еще кто-то не знал? О_о

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

ну вобщем то вы пытаетесь вынести контект ошибки за пределы места где произошла ошибка. по моему мнению если вы не смогли обработать ее на месте, то не сможете ее нормально обработать и выше. тоесть ошибки вида "x компьютеров запустились, y компьютеров отказали" не должно обрабатываться в зависимости от значения x и y.

коллега, подумайте вот о чем: 1. или я вытаскиваю контекст ошибки туда, где у меня есть логгер, или затаскиваю логгер туда, где произошла ошибка 2. даже если я это сделал - я все равно должен что-то вернуть, правда? 3. то, что я вернул, должно быть содержательным, так? иначе мы бы возвращали bool и не парились

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

хорошая идея. а то моду взяли в других чатиках

коллега, подумайте вот о чем: 1. или я вытаскиваю контекст ошибки туда, где у меня есть логгер, или затаскиваю логгер туда, где произошла ошибка 2. даже если я это сделал - я все равно должен что-то вернуть, правда? 3. то, что я вернул, должно быть содержательным, так? иначе мы бы возвращали bool и не парились

1. протаскивай в логер структуру с строкой-описанием ошибки. 2. возвращаешь структуру которая возвращает строкуошибку из метода error. 3. тип структуры ошибки самодостаточен

И что? Это в пользу какого тезиса аргумент?

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

Спасибо за совет, бро

И что? Это в пользу какого тезиса аргумент?

это в пользу того тезиса что вызывающий код знает ттолько то что ошибка удовлетворяет интерфейсу Error

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

Там выше кто про структуру писал?

кто? где? когда ?

Если все, что у меня есть, это интерфейс error (c маленькой) - ничего, кроме строки, я не передам. Уникальной строки, если я хочу хоть что-то о контексте ошибки сообщить

Если все, что у меня есть, это интерфейс error (c маленькой) - ничего, кроме строки, я не передам. Уникальной строки, если я хочу хоть что-то о контексте ошибки сообщить

еще тип структуры. этого в подавляющем большинстве случаев достаточно

Откуда я узнаю тип?!

x,ok := e.(MyError) ?

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

Это тупняк, коллега, примите что-нибудь

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

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

только без явного указания в интерфейсе error. это фраза непонятна

Коллеги, скажите, плиз, каким образом хранятся в структуре, поля структуры. Там лежит поитер? type Config struct { Database Database HttpServer HttpServer }

при передаче Config по ссылке и изменении там Config.Database.field1 измениться ли это поле в исходной структуре Config?

а то на ночь глядя запутался

Там лежит что положите

Но - да, изменится

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

@supmea, @onokonem спасибо!

@onokonem мастер, ты как раз тут ))

а не, ночью был ?

в общем у меня такой вопрос, кто как хранит сваггер доку и генерируемый код

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

в общем у меня такой вопрос, кто как хранит сваггер доку и генерируемый код

генерированный код я коммичу в репу, репу на протокол стараюсь делать отдельную, тогда можно ее шарить, например, с фронтендерами.

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

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

у меня есть swagger.yml и генерированное из него - это одна репа, и сервисы, которые его используют - в своих

ну - по уму так

я верно понимаю, что это прям жирный репозиторище?

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

это ты опытным путем дошел?))

ну - да

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

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

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

а какие варианты?

вот я тут поднял идею писать для каждого сервиса свой свагер. А для общей доки со всеми сервисами написать какой-ниудь js скрипт для мержа

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

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

Я слышал очень хорошие отзывы об использовании Базеля как системы сборки под такие вещи

Типа там это просто, удобно и очевидно

ERROR: S client not available

Вова, дай ссылочку плиз ))

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

ага

для меня ленивого ?

ага

безумие...

KISS в чистом виде ?

обколоться

это ж микросервисы в конце-концов, юзера мы ж описываем во всем репо его испльзующих

Вова, дай ссылочку плиз ))

https://bazel.build

Опенсорс реимелементация Google blaze

ага-ага

Статей по ней маловато, но есть примеры

https://github.com/laramiel/bazel-example-golang типа такого

Читал про Базель, что он не для слабых духом. И для маленьких проектов - такое себе. Ну и большой под него переделывать заманаешься. Хорош только если с самого начала под него затачиваться

Читал про Базель, что он не для слабых духом. И для маленьких проектов - такое себе. Ну и большой под него переделывать заманаешься. Хорош только если с самого начала под него затачиваться

Он как раз под микросервисы с кучей общих библиотек хорош. А миграция на новую систему сборки всегда такое себе

Так-то да. Ну и сукссес-стори не особо видно, кроме гугла. По-моему ещё дропбокс с ним игрался

Вообще есть а-ля Bazel только на go написанный. https://please.build

Так-то да. Ну и сукссес-стори не особо видно, кроме гугла. По-моему ещё дропбокс с ним игрался

Ну в Гугле блейз

А не Базель

Так-то да. Ну и сукссес-стори не особо видно, кроме гугла. По-моему ещё дропбокс с ним игрался

Я уговариваю @spuzirev написать про него

Ну понятно, но хочется верить что концепция однотипная

Ну понятно, но хочется верить что концепция однотипная

там не только концепция. там уши blaze торчат из всех щелей

кое где прямо в ошибочных сообщениях Blaze

Читал про Базель, что он не для слабых духом. И для маленьких проектов - такое себе. Ну и большой под него переделывать заманаешься. Хорош только если с самого начала под него затачиваться

порог входа высокий, да

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

а как описываются эти зависимости?

а как описываются эти зависимости?

для гошки есть gazelle, которая инспектит сырцы и генерирует BUILD-файлы

в общем случае в BUILD-файлах (а-ля Makefile) описываются не зависимости, а "как собрать"

посмотрите на кубернетес или на енвой

там в почти каждой директории есть файл BUILD

кубернетес - та еще альтернативно ориентированные

?