Очень понравился практический кейс и подача материала с последующим рефакторингом (видимо под "чистую архитектуру"), главное нет воды и все уместилось в 40 минут. Очень жду еще в том же стиле!)
Я редко пишу комментарии под такими видео, но тут просто не могу пройти мимо не оставивши коммент. Очень круто, что ты разжевываешь, а не бежишь по своему тексту.
Спасибо за видео, всё круто. Единственное чтобы я поменял, так это 36:10 Вы тут проверяете не просто роль, а конкретно, то что пользователь админ, можно сделать более явное название у метода, но это не критично :)
Я обычно пишу на другом языке, первый раз увидел Go. материал хорошо рассказан. Правда мне не понравилось логика коротких названий s, e и тд а также названием ендопоинта) а так большое спасибо было интересно.
Привет! Спасибо за отзыв😅 Короткие названия для переменных и полей структур это визитная карточка go. Даже исходный код компилятора языка изобилует таким подходом.
Я тоже пишу на другом языке, сейчас посматриваю в сторону Go. И меня аж подбесили эти буквы в полях и методах, это максимально нечитаемо, у нас бы код ревью точно не прошло ;))
Вряд ли такое расположение пакетов в директории internal сделано верно. Я искал проекты с таким же расположением, чтобы убедить себя в обратном, но увы, не нашел. А вот, что говорит ридми-файл на том проекте, который вы взяли за пример: Your actual application code can go in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib). Перевод: Фактический код вашего приложения может находиться в каталоге /internal/app (например, /internal/app/myapp), а код, используемый этими приложениями, - в каталоге /internal/pkg (например, /internal/pkg/myprivlib). myapp - это имя вашего приложения: umbrella-test-task. Как я это узнал? В ридми есть другая отсылка: The directory name for each application should match the name of the executable you want to have (e.g., /cmd/myapp). Подытожив, раз ваш главный пакет имеет путь: /cmd/umbrella-test-task То тогда и остальные пакеты должны быть расположены по таким путям: /internal/app/umbrella-test-task /internal/pkg/endpoint /internal/pkg/mw /internal/pkg/service Возможно, вы и получите сочный офер, сделав подобное расположение пакетов и у вас заработает приложение. Но, всегда не лишне будет подумать своей головой, и проверить информацию.
Привет! Спасибо вам большое, очень подробно расписали расположение, со ссылкой на рекомендации (!) go-project-layout. Каюсь, привычка остаётся со мной ещё со времен Ozon'а, и во всех проектах, с которыми мне приходилось и приходится работать часто вижу её воплощение как у меня. Однако, приведённый вами пример мне кажется даже более логичным. Единственное, что я бы не стал в реальном проекте уносить в internal/pkg что-то типо endpoint'ов и сервисного слоя, ибо они прямо реализуют логику приложения. А вот middleware могло бы знатно там уместиться.
@@ipavlyukov А что, если размещать endpoint'ы там же - в internal/pkg, только делать субдиректроии? Когда я писал REST-проект, то мне нужно было уместить по 3 слоя (пакета) для каждого эндпоинта и инициализировать их всех в специальном для этого месте. На данный момент пишу другое "большое" приложение, где поначалу думал, что возможно стоит разделить его на 2 - каждое со своими внутренними пакетами-эндпоинтами. Но, подумав о пакетах в субдиректроиях и едином месте их инициализации, решил оставить монолит. UPD: фигню написал, упустив суть, что вам надо держать эндпоинты открытыми (не находящимися в internal).
Круто, спасибо за видео. Как раз учу го, и код который был написан сначала я бы тоже смог бы написать. Но код после разделения на файлы и раскидывания по разным папкам, использование методов и интерфейсов (итоговый код) вгоняет меня в уныние, тем что я, наверное, никогда, как джун, не напишу такой код. И возникает вопрос: если так должен писать джун, то какие тогда требования к синьорам???
Такие же требования к сеньорам по коду. К ним просто ужесточаются требования обосновать почему они положили код в эти папочки и сделали эти интерфейсы :)
да ладно, такое стажер написать же может свободно... Использование интерфейсов - база, разложить правильно по пакетикам - база. Есть стандартные практики, как это делать. Я имею всего 4 месяца опыта работы с go, но использование интерфейсов и пакетов - слишком базово для джуна, джун такое должен уметь
Можете объяснить следующий код с минуты 29:40 - почему так надо писать (примерно понимаю, что это связано с концепцией чистого кода, паттернами и т.д), но хотелось бы простым языком получить детальное объяснение
Я только начал ради интереса осваивать го. Не стоило ли задать для функции DaysLeft параметр для указания даты, количество дней до которой считаем? Например, func DaysLeft(year int64, month int16, day int16). Или не?)
Видео крутое. Хотелось бы добавить, что конструкцию ``` if err != nill { return err } return nill ``` можно заменить на простое ``` return err ``` смысл не поменяется.
Несколько замечаний: 1. Количество дней вычисляется неправильно, отбрасывая дробную часть теряется один день. Правильно перед преобразованием в целое вызвать math.Ceil() на результат деления 2. Однобуквенные переменные выглядят очень нечитаемо, по крайне мере для меня Senior Java разработчика. Неужели в Go так принято? 3. Не хватает тестирования. 4. Не хватает файла .gitignore со строкой .idea/ 5. Название корпорации выдуманное (из фильма Resident Evil), то есть задание придумал автор ролика. Поэтому вопрос: зачем вообще использовать какие либо сторонние библиотеки, когда стандартного net/http из самого Go хватит более чем полностью?
зачастую действительное однобуквенные названия используются, потому что в го все сводят к минимализму. Например, d := time.Date(...) -> и так понятно, что мы получим. Аналогично и если мы пишем функцию New в пакете server. Нам не надо писать NewServer(), ибо и так понятно, что New() вернет нам объект server, а вызов будет таким: s := server.New(). Можно записать и так: server := server.NewServer(), но зачем, если и так было понятно, но только длиннее стало. Сам раньше писал на Java и когда в Go пришел то не понимал, а че все пишут переменные из 1-2 символов, особенно в приемниках методов структур. Потом со временем понял всю прелесть такого подхода)
Мммда, есть ощущение, что чистый код прошел мимо данного кода. Кто-то будет говорить, что однобуквенные переменные это ОК для го, но я работаю с го в бигтех компании и это далеко не так
7:57 зачем в функции Handler писать всю эту лишнюю ерунду если можно сделать сразу return ctx.String(...). Если будет ошибка, он вернут ошибку, нет ошибки вернет nil. Но вместо этого мы написали всякую ерунду по типу, если есть ошибка возвращаем ошибку, иначе nil. Что с логикой?
Пытаюсь освоить Go сейчас. Если такая реализация соответствует требованиям для джуна, то я пожалуй просто рядом с офисом компании постою, в окна позаглядываю.
Решил задание, взяли на работу. Когда понял что эта медицинская компания делает-решил уволиться. Теперь за мной гоняется какой-то верзила без глаза в кожаном плаще (затирает про какой-то старс) и какой-то недоариец (так-же в плаще и еще в очках солнцезащитных, хз зачем они ему). Дальше -то что делать?
Объясните плиз не гоферу почему вот так a := &App{} a.s = service.New() a.e = endpoint.New(a.s) А не a := App{service.New(), endpoint.New(service.New())} Так, например
@@ipavlyukov блин, сегодня к вам в команду не взяли)) Тема голанг в принципе интересна, может задачки на литкоде поразобрать. Ты очень прикольно подаёшь материал. Доступно.
@@ipavlyukov это понятно, что можешь разобрать другие темы и можно предлагать их в коментах. а смотреть-то где? вроде умный чел, а на вопрос не ответил =)
@@SavenkoRoman привет, друг! Потому что не на что кидать ссылку. Ведение своего блога очень большая работа. Чаще я публикуюсь на вот таких каналах как этот, поэтому следовало бы ожидать тут 💀
А зачем мы добавляем endpoint в App? Ну тут, понятно, мы показываем, что умеем. Но вот если представить реальное приложение с несколькими endpoint'ами, то есть ли смысл их вообще определять в структуре App, если мы их используем только в рамках app.New()?
Подача очень хорошая. Единственное мне не нравится что вы сокращаете название переменных до s вместо того чтобы написать полностью. Если взять из контекста эту функцию и показать кому либо вряд ли человек поймет что там ожидается какой то сервис или что либо еще.
Согласен: хотя и есть общепринятая практика что переменные, если контекст их использования ограничен, например в пределах видимости нескольких строк на экране, допускают короткие наименования (и однобуквенные). Но тут человек явно переборщил. Особенно дико выглядят эти `a.s = ...; a.e = ...`, мне кажется в структуре такой нейминг не допустим.
Был бы, но ведь нам нужно показать, что мы знаем как применить интерфейс для инъекции зависимости. Не буду лукавить, видео неполное, изначально в планах были еще юнит тесты.
извиняюсь но у меня кажется с самого начала ничего не получается . скачал я все что нужно для GO но visual studio у меня хз как работает и саблайм . в терминале вс я написал го мод инит и у меня пишет ошибка какая та :go : Имя "go" не распознано как имя командлета, функции, файла сценария или выполняемой программы. Проверьте правильность написания имени, а также наличие и правильность пути , после чего повторите попытку. и вот после такого уже вообще какой язык учить
@@andreysakharov6210 все таки приятно ж быть пользователем линуха) все по умолчанию думают что ты запросто можешь писать свои драйвера на ассемблере, вот лишний раз и не рассказывают как там ссылочки открывать😁😅
Прекрасная подача материала, легко и увлекательно, спасибо за ваш труд и ждем новых роликов по гошке.
Спасибо, отличное видео, и приятная подача. За медицинскую компанию - лайк)
Отличная подача, смотреть реально в удовольствие. Хотелось бы еще выпусков по Go
Заметил, что видео длится 40 минут только когда начал читать комментарии. Вообще на одном дыхании
Давай ещё разбор, это очень познавательно ✨
Очень понравился практический кейс и подача материала с последующим рефакторингом (видимо под "чистую архитектуру"), главное нет воды и все уместилось в 40 минут. Очень жду еще в том же стиле!)
Наконец-то узнал как раскидать проект по директориям микросервиса
Чудесный урок. Спасибо! Понятно тому, кто знаком с C, C++, Java, Node.js.
просто то, что искал. Огромное спасибо! просто - огонь!
Спасибо большое, очень полезно, и у тебя подача материала такая прям приятно и интересно слушать
Отдельное спасибо за разъяснение того, что такое middleware !
Очень хорошо объясняете легко понят спасибо 🙏🏻 добавьте в проектах транзакции 🙏🏻
Шикарный материал, ещё бы похожее только с БД объяснение как правильно подключать
Я редко пишу комментарии под такими видео, но тут просто не могу пройти мимо не оставивши коммент. Очень круто, что ты разжевываешь, а не бежишь по своему тексту.
Ещё 20 минут осталось, чтобы тесты написать)
Спасибо ! Ждём ещё разборы ))
Отличное объяснение, спасибо вам )
Очень хорошо рассказываете. Без запинки. Далеко не все так умеют.Даже отбросил метлу и го учить го.
Даёшь больше такого контента))))) Прям на пальцах объяснил. Спасибо!
Всё классно, только одно но: в задании CONTAINS admin, а не EQUALS admin, т.е. "Super-admin" строка тоже должна проходить :-)
Кстати, хороший поинт!
Отличная подача, внятно, содержательно, в меру кратко. Благодарю!
очень понятно рассказывает автор, интересно смотреть!
Очень хорошее и понятное объяснение. Спасибо большое! Делай еще!
Благодарю за Вашу прекрасную работу! ждем новых роликов)
балдёжно объясняет
Меняю профессию, хочу перейти на го, работаю строителем, и вижу у тя та же проблема, никак с люстрой не определишься;)
Заржал, когда увидел логотип) "Медицинская компания"
Спасибо большое) но хотелось бы задачек на уровень повыше
Главное чтобы куда-нибудь в Африку в командировку не отправили)
Отличное видео. Спасибо большое.
да это действительно так, лайк, буду советовать данный видос)
s.g.r.t.y.r.GetDays()
это так в озоне нейминг делают?
прекрасная подача материала
чтобы отправлять заголовок из браузера можно поставить расширение типо ModHeader и в путь
Спасибо за урок!!!
"Запрети ! Не запретил. Я упаковал." Смеюсь 🤣
Собеседование в амбреллу, интересно.
Спасибо за видео, всё круто. Единственное чтобы я поменял, так это 36:10 Вы тут проверяете не просто роль, а конкретно, то что пользователь админ, можно сделать более явное название у метода, но это не критично :)
Разбор задания нужен, где в ТЗ есть спецификация сваггера
на тоненького про umbrella corporation
Я обычно пишу на другом языке, первый раз увидел Go. материал хорошо рассказан. Правда мне не понравилось логика коротких названий s, e и тд а также названием ендопоинта) а так большое спасибо было интересно.
Привет!
Спасибо за отзыв😅
Короткие названия для переменных и полей структур это визитная карточка go. Даже исходный код компилятора языка изобилует таким подходом.
@@SeverSiter1 все же это не оправдание
У нас в Go буквы платные. На самом деле это такой конвент. Чем ближе реализация, тем короче именование.
Я тоже пишу на другом языке, сейчас посматриваю в сторону Go. И меня аж подбесили эти буквы в полях и методах, это максимально нечитаемо, у нас бы код ревью точно не прошло ;))
@@dmitriym4620а на каком языке сейчас пишите, и почему решили на Го перейти?
Спасибо большое, очень полезно
🍉🍉🍉🍉
Подскажите пожалуйста профессию и школу для новичков, где меньше "воды" и больше практики❤
Меня больше всего напрягяет его одежда😂😂😂
вообще класс спасибо
Это самый лучший разбор кода который я только видел💥 Огромное спасибо что рассказываешь комбинации в ide это правда очень помогает при обучении 🙏🏻
Вряд ли такое расположение пакетов в директории internal сделано верно. Я искал проекты с таким же расположением, чтобы убедить себя в обратном, но увы, не нашел.
А вот, что говорит ридми-файл на том проекте, который вы взяли за пример:
Your actual application code can go in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib).
Перевод:
Фактический код вашего приложения может находиться в каталоге /internal/app (например, /internal/app/myapp), а код, используемый этими приложениями, - в каталоге /internal/pkg (например, /internal/pkg/myprivlib).
myapp - это имя вашего приложения: umbrella-test-task. Как я это узнал? В ридми есть другая отсылка:
The directory name for each application should match the name of the executable you want to have (e.g., /cmd/myapp).
Подытожив, раз ваш главный пакет имеет путь: /cmd/umbrella-test-task
То тогда и остальные пакеты должны быть расположены по таким путям:
/internal/app/umbrella-test-task
/internal/pkg/endpoint
/internal/pkg/mw
/internal/pkg/service
Возможно, вы и получите сочный офер, сделав подобное расположение пакетов и у вас заработает приложение. Но, всегда не лишне будет подумать своей головой, и проверить информацию.
Привет!
Спасибо вам большое, очень подробно расписали расположение, со ссылкой на рекомендации (!) go-project-layout.
Каюсь, привычка остаётся со мной ещё со времен Ozon'а, и во всех проектах, с которыми мне приходилось и приходится работать часто вижу её воплощение как у меня. Однако, приведённый вами пример мне кажется даже более логичным. Единственное, что я бы не стал в реальном проекте уносить в internal/pkg что-то типо endpoint'ов и сервисного слоя, ибо они прямо реализуют логику приложения. А вот middleware могло бы знатно там уместиться.
@@ipavlyukov А что, если размещать endpoint'ы там же - в internal/pkg, только делать субдиректроии?
Когда я писал REST-проект, то мне нужно было уместить по 3 слоя (пакета) для каждого эндпоинта и инициализировать их всех в специальном для этого месте.
На данный момент пишу другое "большое" приложение, где поначалу думал, что возможно стоит разделить его на 2 - каждое со своими внутренними пакетами-эндпоинтами. Но, подумав о пакетах в субдиректроиях и едином месте их инициализации, решил оставить монолит.
UPD: фигню написал, упустив суть, что вам надо держать эндпоинты открытыми (не находящимися в internal).
@@MikhailRumyantsev-r1n Главная мысль здесь, это достичь предсказуемого положения кода для тех, кто работает над проектом.
@@ipavlyukov Это да, безусловно.
Круто, спасибо за видео. Как раз учу го, и код который был написан сначала я бы тоже смог бы написать. Но код после разделения на файлы и раскидывания по разным папкам, использование методов и интерфейсов (итоговый код) вгоняет меня в уныние, тем что я, наверное, никогда, как джун, не напишу такой код. И возникает вопрос: если так должен писать джун, то какие тогда требования к синьорам???
Такие же требования к сеньорам по коду. К ним просто ужесточаются требования обосновать почему они положили код в эти папочки и сделали эти интерфейсы :)
да ладно, такое стажер написать же может свободно... Использование интерфейсов - база, разложить правильно по пакетикам - база. Есть стандартные практики, как это делать. Я имею всего 4 месяца опыта работы с go, но использование интерфейсов и пакетов - слишком базово для джуна, джун такое должен уметь
Можете объяснить следующий код с минуты 29:40 - почему так надо писать (примерно понимаю, что это связано с концепцией чистого кода, паттернами и т.д), но хотелось бы простым языком получить детальное объяснение
Я только начал ради интереса осваивать го. Не стоило ли задать для функции DaysLeft параметр для указания даты, количество дней до которой считаем? Например, func DaysLeft(year int64, month int16, day int16). Или не?)
То что в 11-13 минутах рассказываешь, называется обертка (wrap, wrap function, wrapper)
Видео крутое. Хотелось бы добавить, что конструкцию
```
if err != nill {
return err
}
return nill
```
можно заменить на простое
```
return err
```
смысл не поменяется.
Очень даже поменяется. Это стандартная обработка ошибок в го. Ретурн без условий всегда будет возвращать
Несколько замечаний:
1. Количество дней вычисляется неправильно, отбрасывая дробную часть теряется один день. Правильно перед преобразованием в целое вызвать math.Ceil() на результат деления
2. Однобуквенные переменные выглядят очень нечитаемо, по крайне мере для меня Senior Java разработчика. Неужели в Go так принято?
3. Не хватает тестирования.
4. Не хватает файла .gitignore со строкой .idea/
5. Название корпорации выдуманное (из фильма Resident Evil), то есть задание придумал автор ролика. Поэтому вопрос: зачем вообще использовать какие либо сторонние библиотеки, когда стандартного net/http из самого Go хватит более чем полностью?
зачастую действительное однобуквенные названия используются, потому что в го все сводят к минимализму. Например, d := time.Date(...) -> и так понятно, что мы получим. Аналогично и если мы пишем функцию New в пакете server. Нам не надо писать NewServer(), ибо и так понятно, что New() вернет нам объект server, а вызов будет таким: s := server.New(). Можно записать и так: server := server.NewServer(), но зачем, если и так было понятно, но только длиннее стало.
Сам раньше писал на Java и когда в Go пришел то не понимал, а че все пишут переменные из 1-2 символов, особенно в приемниках методов структур. Потом со временем понял всю прелесть такого подхода)
Огонь
как твой app.New() роботает если не нописал какие аргументи должен возврошат функция New(), почемы у темя роботает ?
Мммда, есть ощущение, что чистый код прошел мимо данного кода. Кто-то будет говорить, что однобуквенные переменные это ОК для го, но я работаю с го в бигтех компании и это далеко не так
Как говорится, есть только две сложные задачи - кэширование и нейминг переменных :)
@@MaximBondarenko отличная фраза)
@@MaximBondarenkoа чем кеширование сложное?
@@linuxoidovichнаверное речь о том, что сложно решить когда обновлять данные в кеше, т.к. они устаревают
Правильной инвалидацией
7:57 зачем в функции Handler писать всю эту лишнюю ерунду если можно сделать сразу return ctx.String(...). Если будет ошибка, он вернут ошибку, нет ошибки вернет nil. Но вместо этого мы написали всякую ерунду по типу, если есть ошибка возвращаем ошибку, иначе nil. Что с логикой?
Логика была при Сталине, сейчас время абсурда
Не вижу новых задачек для оффера(
Есть новое видео про таймслоты, но на другом канале
Пытаюсь освоить Go сейчас. Если такая реализация соответствует требованиям для джуна, то я пожалуй просто рядом с офисом компании постою, в окна позаглядываю.
Что, всё так плохо?
@@denisbogdanov8976 Нет, ещё хуже)
Ну как дела, освоили?
service - s, app -a и тд, а вы точно сеньор-помидор?)
А как же swagger, config, graceful shutdown и многое другое?
Решил задание, взяли на работу. Когда понял что эта медицинская компания делает-решил уволиться. Теперь за мной гоняется какой-то верзила без глаза в кожаном плаще (затирает про какой-то старс) и какой-то недоариец (так-же в плаще и еще в очках солнцезащитных, хз зачем они ему). Дальше -то что делать?
а калькулятор как написать не подскажите саму концепцию написания особенно с римскими цифрами
но в школе не вижу курса по golang
Лайк за ркзидкн ивел)
Объясните плиз не гоферу почему вот так
a := &App{}
a.s = service.New()
a.e = endpoint.New(a.s)
А не
a := App{service.New(), endpoint.New(service.New())}
Так, например
Потому что два разных сервиса создается во втором примере
Очень простое задание как по мне
Если бы я увидел в коде функцию названную "MW", переменные "a, e, s" - закрыл бы и выбросил в корзину.
Это нормально для го
@@ВалерийТкачев-к1к это нормально только для обфускаторов и для BASIC в школе 😅
this is Go
@@IgorYegorkinпочти все примеры кода на Го в интернете, именно такие
Это как если увидеть программиста в рубашке белой .) парень очень круто объясняет , ждём новых видео
Very good!
а что дома в пальто?
Так, где смотреть твои уроки?
Если есть спрос, то могу разобрать и другие темы. Предлагай их прямо здесь, в комментариях!
@@ipavlyukov блин, сегодня к вам в команду не взяли))
Тема голанг в принципе интересна, может задачки на литкоде поразобрать. Ты очень прикольно подаёшь материал. Доступно.
@@ipavlyukov это понятно, что можешь разобрать другие темы и можно предлагать их в коментах. а смотреть-то где? вроде умный чел, а на вопрос не ответил =)
@@SavenkoRoman привет, друг!
Потому что не на что кидать ссылку. Ведение своего блога очень большая работа. Чаще я публикуюсь на вот таких каналах как этот, поэтому следовало бы ожидать тут 💀
@@ipavlyukov привет! Я пока нашел только 2 ролика твоих. Где другие глянуть?
Скоро будут языки , где каждой функции - отдельный файл. И три тонны импортов в хедере Все к этому идет.
подскажите для винды как обновить сервер?
почему даже упоминания нету о тестах?
А зачем мы добавляем endpoint в App? Ну тут, понятно, мы показываем, что умеем. Но вот если представить реальное приложение с несколькими endpoint'ами, то есть ли смысл их вообще определять в структуре App, если мы их используем только в рамках app.New()?
Для http-сервера с hello word тащить левый "фреймворк" с гитхаба - ну-ну, отличный вкус ))
Так задание оговаривало использование именно echo а не стандартного пакета
Балдёж!
Посоветуйте норм курс по го
middleware это proxy? очень похоже
Подача очень хорошая. Единственное мне не нравится что вы сокращаете название переменных до s вместо того чтобы написать полностью.
Если взять из контекста эту функцию и показать кому либо вряд ли человек поймет что там ожидается какой то сервис или что либо еще.
особенно это заметно когда вы вызываете e.s.DaysLeft()
Краткость именования полей - визитная карточка Go. Но, конечно, стоит опираться на стандарты компании в которой вы работаете.
За усилия плюс, за суть скорее минус.
Это уровень джуна?
чтобы получать сочные оферы надо скипать тестовые задания.
Он так сочно рассказывает как тот повар из мема который говорит "Еее, бой"
Спасибо, интересно. Но почему int64? Можно было int32, или даже int16
А если дата поменяется и кол-во дней будет большое?
Больше чем 32768? Нет ну может в теории... В любом случае int32 точно бы хватило.
Меня одного смущают названия переменных из одной буквы? Дядя Боб не одобрил бы... Хотя видос по делу.
Согласен: хотя и есть общепринятая практика что переменные, если контекст их использования ограничен, например в пределах видимости нескольких строк на экране, допускают короткие наименования (и однобуквенные). Но тут человек явно переборщил. Особенно дико выглядят эти `a.s = ...; a.e = ...`, мне кажется в структуре такой нейминг не допустим.
А где DI и тесты ?
Класс
Не работайте на Umbrella Corporation! Они не те, за кого себя выдают
вопрос: а если бы мы в эндпоинте не описывали интерфейс, а просто передали бы сервис - это уже не был бы депенденси-инжекшион?
Был бы, но ведь нам нужно показать, что мы знаем как применить интерфейс для инъекции зависимости.
Не буду лукавить, видео неполное, изначально в планах были еще юнит тесты.
Я бы еще добавил блокчейн и кубер
извиняюсь но у меня кажется с самого начала ничего не получается . скачал я все что нужно для GO но visual studio у меня хз как работает и саблайм . в терминале вс я написал го мод инит и у меня пишет ошибка какая та :go : Имя "go" не распознано как имя командлета, функции, файла сценария или выполняемой
программы. Проверьте правильность написания имени, а также наличие и правильность пути
, после чего повторите попытку. и вот после такого уже вообще какой язык учить
Нужно убедиться, что go установлен в систему и может быть вызван из командной строки.
@@SeverSiter1 как
@@magnat7045 следуя инструкциям с официального сайта
@@SeverSiter1 C:\Users\user>go install 1.19.4@latest
go: 1.19.4@latest: unrecognized import path "1.19.4": https fetch: Get "1.19.4/?go-get=1": dial tcp: lookup 1.19.4: no such host
@@magnat7045 думаю проще с сайта скачать установщик
Прекрасный симбиот в стиле для чайников с последующей полной жестью!)) Нихрена не понял...
Найс компания 😂
Всё отлично, но нет тестов
Топ
В руби это задание делается за 2 минуты
Очень много бойлерплейта
счас бы назвать spring-like архитектурой "когда есть эндпоинт, сервис, репозиторий"
но главное что синьор и работал везде-везде
👍 HO на фейс не обязательно переключать кажд 5 мин , главное код
похоже на Express JS
ужасная несправедливость. почему рассказано как открыть ссылку в браузере на маке и на винде, а как на линукс не сказано?
Тыж на линуксе)
Напиши свой бразуер просто
@@erik_james видимо поэтому и не сказано, что написание браузера не умещается в хронометраж видео))
@@andreysakharov6210 все таки приятно ж быть пользователем линуха) все по умолчанию думают что ты запросто можешь писать свои драйвера на ассемблере, вот лишний раз и не рассказывают как там ссылочки открывать😁😅
Смотрю видео и задаюсь одним вопросом - не жарко ли сидеть в свитере и пиджаке в квартире?
всё классно, но по сравнению со Спрингом - весь этот Гоу какая-то боль 😖