что бы он был универсальным

Ну это я так вижу +-

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

ну с другими языками не работал?

ну чисто в школе паскаль))

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

ясно)

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

но пока можно все делать в пакете main

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

Ты уже обратил внимание на модификаторы доступа в ГО?)))))

Я когда не читая сам разбирался и понял про то как это работает немного прифигел)

про большую букву?

Ага))))

https://www.youtube.com/channel/UCHF0TTrKzOASxt4aFByKpnQ

ну вот такой специфический язык)

Вот тут парень доступно всё рассказывает

и не только про го

Сам смотрю

но там прям явно не junior уровень

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

вроде у него смотрел

просто мне нужно что то типа []Topic.shuffle()

func (s *[]Topic) shuffle() { } по моему так можно

возможно, я не в курсе)

По архитектуре я у него смотрел и много по чему ещё

func (s *[]Topic) shuffle() { } по моему так можно

нельзя похоже)

https://play.golang.org/p/ha2cbGURFn_T

я вот чет такое предлагал но так тоже можно)

так даже наверное лучше

я о таком не знал)

а на интерфейсы завязаться я так понял не получится? byd

ну да, по второму способу работает, а по первому нет)

ну типо сделать не конкретный тип а срез интерфейса или структур

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

Лучше написать пакет который будет тебе шафлить срезы и возвращать срез измененный наверное

без создания нового типа

всё зависит от задачи, варианты есть

но начинать надо с простого, ничего не делать или просто не делать лишнего )

Ничего не делать звучит как девиз)))

чисто я на работе)

я не брал) Мне достаточно обычно поверхностной инфы)

что бы дальше самому закопаться

кстати в го же нет енамов?

а, там есть некоторая его реализация, но не в традиционном виде

Я вот сам ищу

но ничего не понимаю

сколько бы не смотрел ничего не ясно

У меня сейчас 30+ микросервисов

но я пока не вкурил как это всё работает на самом деле

Особенно меня интересует секурность, авторизация, всякое такое

https://www.youtube.com/c/GopherSchool

между сервисами

советую кстати по gRPC тоже изучать инфу если хочется в го разрабы пойти. Активно юзают в микросервисах в озоне

мы о микро или сервисах?

Вообще я для себя вижу идеальным флоу такой. У тебя единая точка входе, которая проверяет токен и права пользователя. А дальше уже в нужные микросервисы шарит. А сами микросервисы закрыты наружу. Так называемый API Gateway

Я скорее о микро

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

Что бы проверить права пользователя

Но это по сути разные подходы в реализации микросервисов

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

Всем здаров ребята. Кто ниб c cucumber для написания тестов работал? В частности кто ниб пробовал rollback делать после каждого сценария ?

да, на этом примере можно понять как работают микросервисы и как их пишут

Можешь рассказать что такое кукумбер этот? Что за "овощ" такой

https://github.com/cucumber/godog

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

Какова задача кукумбера? тестировать бэкенд?

Какова задача кукумбера? тестировать бэкенд?

да , в крайне удобном виде, fixture прописываешь

Фикстуры это по идеи наборы данных, которые должны быть в бд.

Пацаны, если в родном регионе не ремонтируют видеокарт, что делать?

типа "на голую" бд накатывать.

Покупать новую)

Покупать новую)

Это проблема ( высокие цены)

типа "на голую" бд накатывать.

да)

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

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

смотря для какой архитектуры и для какого масштаба

юнит тестами громоздко может быть

какой то идеал очка получается .. я такого не встречал

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

Но это мое видение, жду более умных мыслей конечно же)