Артем
ахха
mishhgun
базовый курс со степик + пет проект во время которого сталкиваешься с большинством трудностей и проблем и вычитываешь помощь на Хабре - лучший путь, как по мне
Егор
базовый курс со степик + пет проект во время которого сталкиваешься с большинством трудностей и проблем и вычитываешь помощь на Хабре - лучший путь, как по мне
на собеседовании только не говори про это
Артём
базовый курс со степик + пет проект во время которого сталкиваешься с большинством трудностей и проблем и вычитываешь помощь на Хабре - лучший путь, как по мне
Интересно, мне лично чаще на stackoverflow нужное находилось.
mishhgun
ну одно дело - когда гуглишь ошибку, другую - когда ищешь гайд по библиотекам для того же postgresql или роутера или гайд по middleware
Alexander
базовый курс со степик + пет проект во время которого сталкиваешься с большинством трудностей и проблем и вычитываешь помощь на Хабре - лучший путь, как по мне
Это может привести копипасте языковых конструкций из примеров без понимания их устройства. Зачем, если можно прочитать нормально книгу, а потом уже идти по всем этим примерам с пониманием? Отсюда ещё всякие пропускальщики ошибок вырастают
Alexander
То есть как бы да, достаточно прошаренный и умный человек так может, но никто же сам себе не признаётся, что таковым не является, если это так.
Alexander
Вообще, надо пройти курс степика, чтобы оценить на сколько он полон. Может я ошибаюсь, хз
Илья
курс Go на практике очень неплох
Alexander
То есть как бы да, достаточно прошаренный и умный человек так может, но никто же сам себе не признаётся, что таковым не является, если это так.
Тут ещё в копилку желание не использовать паттерны написания кода с предыдущих языков. Это ещё хуже может результат произвести, чем просто ноль в программировании
Сидредин
Вместо того чтобы искать «идеальное объяснение» бери и делай, + эти книги читаются на самом деле легко, почитай отзывы
Какие именно книги? (кроме той, что с мостом)
Rostislav
Всем привет!
Начал изучать Go.
Порекомендуйте курсы, ютуберов, книги или задачи где можно решить
начал со stepik
Боднер Джон - Go: идиомы и паттерны проектирования
donovan kernighan - go programming language
shindos
Кіт ✙
У меня есть свой сервер, и есть два экзампла - обычный хелловорлд, и такой же хелловорлд, но использующий группы обработчиков.
Тестирую производительность через wrk. Обычный хелловорлд живет, а вот при идентичных параметрах пример с группами обработчиков падает. Причём падает кто где: там в отправке в канал, там в приеме, там чтение из сокета, там вообще где-то в runtime_pollWait
Почему так может быть? Ulimit -n повышал
Исходники - github.com/fakefloordiv/indigo/tree/dev, см. examples/helloworld/helloworld.go и examples/pathgroups/pathgroups.go
Кіт ✙
хм, сейчас попробую увеличить и глянуть
Rostislav
а там какой-нибудь дедлок или паника из-за конкурентного доступа мб в мапу
Кіт ✙
а там какой-нибудь дедлок или паника из-за конкурентного доступа мб в мапу
мсье, передаю вам свой магический шар. Проблема действительно в конкурентной записи и чтении мапы, спасибо огромное
Егор
Есть такие люди которые начинали в проге сразу с GO и в дальнейшем успешно устроились на работу?
Поделитесь опытом пожалуйста)
Grigorij
шо там делиться.
читаешь про ос, сети, бд, язык. пишешь пет проект. апплаишься, через Х собеседований получаешь оффер. done.
Emin Zalaev
Есть такие люди которые начинали в проге сразу с GO и в дальнейшем успешно устроились на работу?
Поделитесь опытом пожалуйста)
курс на степике за 2 недели + 2 недели рест апишки как пет проект и залетел на стажировку
Сидредин
Grigorij
у каждого разная исходная ситуация
образование/имеющиеся знания
Emin Zalaev
в среднем 3-6 мес думаю можно залететь
Emin Zalaev
у каждого разная исходная ситуация
образование/имеющиеся знания
да максимум мог на сишке массив создать функцию и цикл))))
Emin Zalaev
ну добавьте 1-2 недели
Emin Zalaev
я особо не прогал там
Sebor▂▅▇█▓▒░
Grigorij
если ты заканчивал, вам там всё равно че нидь про ОС, сети, бд рассказывали. во всяком случае обычно это в программе вроде должно быть
Grigorij
и это уже не мало
Emin Zalaev
ну я говорю максимум 1-2 недели изучения
Emin Zalaev
потому что я лекции не посещал а лабы списывал/покупал
Emin Zalaev
щас конечно сильно жалею
Grigorij
ок
Emin Zalaev
но в то время я уже работал проектировщиком и думал проектировщиком стану
Grigorij
потом всё равно приходится эти знания закрывать. нет смысла их скипать
Nikita
Ребят. Подскажите пожалуйста. Примерно такая ситуация.
Есть маленькое приложение на http rest. К нему хочу подключить поддержку gRPC.
Как это будет правильно сделать, что все было в одном репозитории? Чтобы контракты лежали, клиент и сервер. Сервер запускался вместе с http.
Может быть у кого пример есть?
Очень не хочется городить 3 репозитория под контракты,сервер и клиент.
anhckie
ребята, ряд вопросов по чистой архитектуре или около того)
вводные данные: в проекте будет с некоторой периодичностью (каждые n времени) посылаться запрос во внешние независимые друг от друга API (горутины и синк группы на первый взгляд).
ответы этих API составляют 1 единственную сущность.
вопросы:
1. в контексте чистой архитектуры юзкейсом является бизнес-логика? т.е. в рамках юзкейсов будет происходить запрос в api, получение ответа и его дальнейшее хранение? к апишкам надо будет аутентфикацию скорее всего приделывать - это тоже ведь зона ответственности юзкейса, как. японимаю?
2. для сохранения в бд хочу использовать "репозиторий". как я понимаю, репозиторий это именно тот слой, который будет заниматься крудом сущности при работе с базой?
anhckie
😅 а я на твой ответ надеялся ))))
Юра (Юрий Александрович)
Хотя... 1 может быть и тоже да.
anhckie
если что, ориентируюсь по https://github.com/evrone/go-clean-template решению. + смотрел его доклад, но все же нет уверенности, что я не порю чепуху )
Юра (Юрий Александрович)
Юзкейс - это способ взаимодействия с системой определенной внешней сущностью. Т.е. та "польза", которую система может дать внешнему миру.
anhckie
ну, внешняя сущность - это реквест разве что. по любому из доступных протоколов
Юра (Юрий Александрович)
т.е. в клиент-серверной архитектуре юзкейсы - это реакции сервера на различные запросы к нему.
anhckie
я так понимаю, что юзкейс - это способ коммуникации между внешним запросом и бизнес-сущностью - т.е. бизнес-логика...
anhckie
мы вроде разными словами про одно говорим, да? )
Юра (Юрий Александрович)
похоже. Дело даже не в способе коммуникации, а в поведении
Илья
по идее для сервиса не должно быть разницы между вызовом бд или другого сервера, потому что это скрыто под репозиторием
Юра (Юрий Александрович)
Например юз кейс "юзер нажал на кнопку - и дверь открылась" - это не столько про коммуникацию с юзером (она тут односторонняя), сколько о последствиях этой коммуникации
anhckie
ну, да. не способ коммуникации - а что происходить должно
anhckie
по идее для сервиса не должно быть разницы между вызовом бд или другого сервера, потому что это скрыто под репозиторием
так а если вызов другого сервера по грпс, например, это же не задача репы? или не)
Илья
ну вот я думаю, что задача репы
Илья
реально хотел об этом вечером спросить
Юра (Юрий Александрович)
я думаю, что для данной задачи будут два юзкейса:
1) от клиента пришел запрос
2) серверу поступил сигнал (от таймера, или крона), что пора обновлять вот то, что он там у себя хранит и отдает.
Юра (Юрий Александрович)
И на эти две ситуации сервер реагирует различным определенным образом, и правильная реакция и определяет суть его работы.
Юра (Юрий Александрович)
А то, что касается аутентификации для обращения к сторонним сервисам - это уже будут юзкейсы не всей системы вцелом, а каких-то ее отдельных частей, которые проявятся при декомпозиции сервиса на составляющие.
anhckie
Юра (Юрий Александрович)
т.е. "авторизация" не может быть юзкейсом для всего сервиса вцелом, т.к. у него нет конкретного сценария, при котором бы выполнилась только она. Но внутри у сервиса будет, например, клиент к API1, у которого будут свои юзкейсы.
Юра (Юрий Александрович)
первого даже не будет, только 2-й
Тогда я не совсем понял. У вас есть некоторая сущность, которая иногда посылает запросы к двум разным API, лепит из них одну сущность и...?
И что дальше она с этой сущностью делает? Ради чего мы обращались к API1 и API2?
anhckie
есть некоторая сущность, которая состоит из несколько "частей". чтобы ее создать и сохранить в бд, сервис должен будет ходить в апи1 и апи2, собирая частями инфу, после чего сохранять в какой-то типа дто, передавать в репу и сохранять в бд
anhckie
то есть мы не принимаем запросов от юзера, но по плану ходим в апи и складируем данные в бд
anhckie
а в бд уже другие сервисы будут ходить
Юра (Юрий Александрович)
аа. А дальше применение этой сущности уже какие-то другие компоненты системы найдут?
Да, тогда юзкейс только один: "пора обращаться к Апям"
anhckie
да, все так