Очень понравился практический кейс и подача материала с последующим рефакторингом (видимо под "чистую архитектуру"), главное нет воды и все уместилось в 40 минут. Очень жду еще в том же стиле!)
Я редко пишу комментарии под такими видео, но тут просто не могу пройти мимо не оставивши коммент. Очень круто, что ты разжевываешь, а не бежишь по своему тексту.
Круто, спасибо за видео. Как раз учу го, и код который был написан сначала я бы тоже смог бы написать. Но код после разделения на файлы и раскидывания по разным папкам, использование методов и интерфейсов (итоговый код) вгоняет меня в уныние, тем что я, наверное, никогда, как джун, не напишу такой код. И возникает вопрос: если так должен писать джун, то какие тогда требования к синьорам???
Такие же требования к сеньорам по коду. К ним просто ужесточаются требования обосновать почему они положили код в эти папочки и сделали эти интерфейсы :)
да ладно, такое стажер написать же может свободно... Использование интерфейсов - база, разложить правильно по пакетикам - база. Есть стандартные практики, как это делать. Я имею всего 4 месяца опыта работы с go, но использование интерфейсов и пакетов - слишком базово для джуна, джун такое должен уметь
Я только начал ради интереса осваивать го. Не стоило ли задать для функции DaysLeft параметр для указания даты, количество дней до которой считаем? Например, func DaysLeft(year int64, month int16, day int16). Или не?)
7:57 зачем в функции Handler писать всю эту лишнюю ерунду если можно сделать сразу return ctx.String(...). Если будет ошибка, он вернут ошибку, нет ошибки вернет nil. Но вместо этого мы написали всякую ерунду по типу, если есть ошибка возвращаем ошибку, иначе nil. Что с логикой?
Можете объяснить следующий код с минуты 29:40 - почему так надо писать (примерно понимаю, что это связано с концепцией чистого кода, паттернами и т.д), но хотелось бы простым языком получить детальное объяснение
Спасибо за видео, всё круто. Единственное чтобы я поменял, так это 36:10 Вы тут проверяете не просто роль, а конкретно, то что пользователь админ, можно сделать более явное название у метода, но это не критично :)
Я обычно пишу на другом языке, первый раз увидел Go. материал хорошо рассказан. Правда мне не понравилось логика коротких названий s, e и тд а также названием ендопоинта) а так большое спасибо было интересно.
Привет! Спасибо за отзыв😅 Короткие названия для переменных и полей структур это визитная карточка go. Даже исходный код компилятора языка изобилует таким подходом.
Я тоже пишу на другом языке, сейчас посматриваю в сторону Go. И меня аж подбесили эти буквы в полях и методах, это максимально нечитаемо, у нас бы код ревью точно не прошло ;))
Несколько замечаний: 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 символов, особенно в приемниках методов структур. Потом со временем понял всю прелесть такого подхода)
Вряд ли такое расположение пакетов в директории 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).
Видео крутое. Хотелось бы добавить, что конструкцию ``` if err != nill { return err } return nill ``` можно заменить на простое ``` return err ``` смысл не поменяется.
Мммда, есть ощущение, что чистый код прошел мимо данного кода. Кто-то будет говорить, что однобуквенные переменные это ОК для го, но я работаю с го в бигтех компании и это далеко не так
Решил задание, взяли на работу. Когда понял что эта медицинская компания делает-решил уволиться. Теперь за мной гоняется какой-то верзила без глаза в кожаном плаще (затирает про какой-то старс) и какой-то недоариец (так-же в плаще и еще в очках солнцезащитных, хз зачем они ему). Дальше -то что делать?
А зачем мы добавляем endpoint в App? Ну тут, понятно, мы показываем, что умеем. Но вот если представить реальное приложение с несколькими endpoint'ами, то есть ли смысл их вообще определять в структуре App, если мы их используем только в рамках app.New()?
Объясните плиз не гоферу почему вот так a := &App{} a.s = service.New() a.e = endpoint.New(a.s) А не a := App{service.New(), endpoint.New(service.New())} Так, например
@@ipavlyukov блин, сегодня к вам в команду не взяли)) Тема голанг в принципе интересна, может задачки на литкоде поразобрать. Ты очень прикольно подаёшь материал. Доступно.
@@ipavlyukov это понятно, что можешь разобрать другие темы и можно предлагать их в коментах. а смотреть-то где? вроде умный чел, а на вопрос не ответил =)
@@SavenkoRoman привет, друг! Потому что не на что кидать ссылку. Ведение своего блога очень большая работа. Чаще я публикуюсь на вот таких каналах как этот, поэтому следовало бы ожидать тут 💀
Подача очень хорошая. Единственное мне не нравится что вы сокращаете название переменных до s вместо того чтобы написать полностью. Если взять из контекста эту функцию и показать кому либо вряд ли человек поймет что там ожидается какой то сервис или что либо еще.
Пытаюсь освоить Go сейчас. Если такая реализация соответствует требованиям для джуна, то я пожалуй просто рядом с офисом компании постою, в окна позаглядываю.
извиняюсь но у меня кажется с самого начала ничего не получается . скачал я все что нужно для GO но visual studio у меня хз как работает и саблайм . в терминале вс я написал го мод инит и у меня пишет ошибка какая та :go : Имя "go" не распознано как имя командлета, функции, файла сценария или выполняемой программы. Проверьте правильность написания имени, а также наличие и правильность пути , после чего повторите попытку. и вот после такого уже вообще какой язык учить
Был бы, но ведь нам нужно показать, что мы знаем как применить интерфейс для инъекции зависимости. Не буду лукавить, видео неполное, изначально в планах были еще юнит тесты.
Согласен: хотя и есть общепринятая практика что переменные, если контекст их использования ограничен, например в пределах видимости нескольких строк на экране, допускают короткие наименования (и однобуквенные). Но тут человек явно переборщил. Особенно дико выглядят эти `a.s = ...; a.e = ...`, мне кажется в структуре такой нейминг не допустим.
@@andreysakharov6210 все таки приятно ж быть пользователем линуха) все по умолчанию думают что ты запросто можешь писать свои драйвера на ассемблере, вот лишний раз и не рассказывают как там ссылочки открывать😁😅
Прекрасная подача материала, легко и увлекательно, спасибо за ваш труд и ждем новых роликов по гошке.
Отличная подача, смотреть реально в удовольствие. Хотелось бы еще выпусков по Go
Спасибо, отличное видео, и приятная подача. За медицинскую компанию - лайк)
Очень понравился практический кейс и подача материала с последующим рефакторингом (видимо под "чистую архитектуру"), главное нет воды и все уместилось в 40 минут. Очень жду еще в том же стиле!)
Давай ещё разбор, это очень познавательно ✨
Заметил, что видео длится 40 минут только когда начал читать комментарии. Вообще на одном дыхании
Чудесный урок. Спасибо! Понятно тому, кто знаком с C, C++, Java, Node.js.
просто то, что искал. Огромное спасибо! просто - огонь!
Спасибо большое, очень полезно, и у тебя подача материала такая прям приятно и интересно слушать
Отдельное спасибо за разъяснение того, что такое middleware !
Я редко пишу комментарии под такими видео, но тут просто не могу пройти мимо не оставивши коммент. Очень круто, что ты разжевываешь, а не бежишь по своему тексту.
Наконец-то узнал как раскидать проект по директориям микросервиса
Очень хорошо объясняете легко понят спасибо 🙏🏻 добавьте в проектах транзакции 🙏🏻
Шикарный материал, ещё бы похожее только с БД объяснение как правильно подключать
Отличная подача, внятно, содержательно, в меру кратко. Благодарю!
Благодарю за Вашу прекрасную работу! ждем новых роликов)
Спасибо ! Ждём ещё разборы ))
Даёшь больше такого контента))))) Прям на пальцах объяснил. Спасибо!
Всё классно, только одно но: в задании CONTAINS admin, а не EQUALS admin, т.е. "Super-admin" строка тоже должна проходить :-)
Кстати, хороший поинт!
Очень хорошее и понятное объяснение. Спасибо большое! Делай еще!
s.g.r.t.y.r.GetDays()
это так в озоне нейминг делают?
Отличное объяснение, спасибо вам )
очень понятно рассказывает автор, интересно смотреть!
Это самый лучший разбор кода который я только видел💥 Огромное спасибо что рассказываешь комбинации в ide это правда очень помогает при обучении 🙏🏻
балдёжно объясняет
Очень хорошо рассказываете. Без запинки. Далеко не все так умеют.Даже отбросил метлу и го учить го.
Отличное видео. Спасибо большое.
да это действительно так, лайк, буду советовать данный видос)
Круто, спасибо за видео. Как раз учу го, и код который был написан сначала я бы тоже смог бы написать. Но код после разделения на файлы и раскидывания по разным папкам, использование методов и интерфейсов (итоговый код) вгоняет меня в уныние, тем что я, наверное, никогда, как джун, не напишу такой код. И возникает вопрос: если так должен писать джун, то какие тогда требования к синьорам???
Такие же требования к сеньорам по коду. К ним просто ужесточаются требования обосновать почему они положили код в эти папочки и сделали эти интерфейсы :)
да ладно, такое стажер написать же может свободно... Использование интерфейсов - база, разложить правильно по пакетикам - база. Есть стандартные практики, как это делать. Я имею всего 4 месяца опыта работы с go, но использование интерфейсов и пакетов - слишком базово для джуна, джун такое должен уметь
прекрасная подача материала
Ещё 20 минут осталось, чтобы тесты написать)
Я только начал ради интереса осваивать го. Не стоило ли задать для функции DaysLeft параметр для указания даты, количество дней до которой считаем? Например, func DaysLeft(year int64, month int16, day int16). Или не?)
Заржал, когда увидел логотип) "Медицинская компания"
Спасибо большое) но хотелось бы задачек на уровень повыше
Главное чтобы куда-нибудь в Африку в командировку не отправили)
Спасибо за урок!!!
7:57 зачем в функции Handler писать всю эту лишнюю ерунду если можно сделать сразу return ctx.String(...). Если будет ошибка, он вернут ошибку, нет ошибки вернет nil. Но вместо этого мы написали всякую ерунду по типу, если есть ошибка возвращаем ошибку, иначе nil. Что с логикой?
Логика была при Сталине, сейчас время абсурда
"Запрети ! Не запретил. Я упаковал." Смеюсь 🤣
вообще класс спасибо
Можете объяснить следующий код с минуты 29:40 - почему так надо писать (примерно понимаю, что это связано с концепцией чистого кода, паттернами и т.д), но хотелось бы простым языком получить детальное объяснение
Спасибо большое, очень полезно
🍉🍉🍉🍉
Спасибо за видео, всё круто. Единственное чтобы я поменял, так это 36:10 Вы тут проверяете не просто роль, а конкретно, то что пользователь админ, можно сделать более явное название у метода, но это не критично :)
Я обычно пишу на другом языке, первый раз увидел Go. материал хорошо рассказан. Правда мне не понравилось логика коротких названий s, e и тд а также названием ендопоинта) а так большое спасибо было интересно.
Привет!
Спасибо за отзыв😅
Короткие названия для переменных и полей структур это визитная карточка go. Даже исходный код компилятора языка изобилует таким подходом.
@@SeverSiter1 все же это не оправдание
У нас в Go буквы платные. На самом деле это такой конвент. Чем ближе реализация, тем короче именование.
Я тоже пишу на другом языке, сейчас посматриваю в сторону Go. И меня аж подбесили эти буквы в полях и методах, это максимально нечитаемо, у нас бы код ревью точно не прошло ;))
@@dmitriym4620а на каком языке сейчас пишите, и почему решили на Го перейти?
Огонь
Подскажите пожалуйста профессию и школу для новичков, где меньше "воды" и больше практики❤
чтобы отправлять заголовок из браузера можно поставить расширение типо ModHeader и в путь
Меняю профессию, хочу перейти на го, работаю строителем, и вижу у тя та же проблема, никак с люстрой не определишься;)
Несколько замечаний:
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 символов, особенно в приемниках методов структур. Потом со временем понял всю прелесть такого подхода)
Балдёж!
Вряд ли такое расположение пакетов в директории 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 Это да, безусловно.
Видео крутое. Хотелось бы добавить, что конструкцию
```
if err != nill {
return err
}
return nill
```
можно заменить на простое
```
return err
```
смысл не поменяется.
Очень даже поменяется. Это стандартная обработка ошибок в го. Ретурн без условий всегда будет возвращать
как твой app.New() роботает если не нописал какие аргументи должен возврошат функция New(), почемы у темя роботает ?
Меня больше всего напрягяет его одежда😂😂😂
Собеседование в амбреллу, интересно.
Разбор задания нужен, где в ТЗ есть спецификация сваггера
Мммда, есть ощущение, что чистый код прошел мимо данного кода. Кто-то будет говорить, что однобуквенные переменные это ОК для го, но я работаю с го в бигтех компании и это далеко не так
Как говорится, есть только две сложные задачи - кэширование и нейминг переменных :)
@@MaximBondarenko отличная фраза)
@@MaximBondarenkoа чем кеширование сложное?
@@linuxoidovichнаверное речь о том, что сложно решить когда обновлять данные в кеше, т.к. они устаревают
Правильной инвалидацией
service - s, app -a и тд, а вы точно сеньор-помидор?)
Решил задание, взяли на работу. Когда понял что эта медицинская компания делает-решил уволиться. Теперь за мной гоняется какой-то верзила без глаза в кожаном плаще (затирает про какой-то старс) и какой-то недоариец (так-же в плаще и еще в очках солнцезащитных, хз зачем они ему). Дальше -то что делать?
а калькулятор как написать не подскажите саму концепцию написания особенно с римскими цифрами
Не работайте на Umbrella Corporation! Они не те, за кого себя выдают
А зачем мы добавляем endpoint в App? Ну тут, понятно, мы показываем, что умеем. Но вот если представить реальное приложение с несколькими endpoint'ами, то есть ли смысл их вообще определять в структуре App, если мы их используем только в рамках app.New()?
То что в 11-13 минутах рассказываешь, называется обертка (wrap, wrap function, wrapper)
Если бы я увидел в коде функцию названную "MW", переменные "a, e, s" - закрыл бы и выбросил в корзину.
Это нормально для го
@@ВалерийТкачев-к1к это нормально только для обфускаторов и для BASIC в школе 😅
this is Go
@@IgorYegorkinпочти все примеры кода на Го в интернете, именно такие
Это как если увидеть программиста в рубашке белой .) парень очень круто объясняет , ждём новых видео
Объясните плиз не гоферу почему вот так
a := &App{}
a.s = service.New()
a.e = endpoint.New(a.s)
А не
a := App{service.New(), endpoint.New(service.New())}
Так, например
Потому что два разных сервиса создается во втором примере
А как же swagger, config, graceful shutdown и многое другое?
Скоро будут языки , где каждой функции - отдельный файл. И три тонны импортов в хедере Все к этому идет.
Класс
Very good!
подскажите для винды как обновить сервер?
Для http-сервера с hello word тащить левый "фреймворк" с гитхаба - ну-ну, отличный вкус ))
Так задание оговаривало использование именно echo а не стандартного пакета
Так, где смотреть твои уроки?
Если есть спрос, то могу разобрать и другие темы. Предлагай их прямо здесь, в комментариях!
@@ipavlyukov блин, сегодня к вам в команду не взяли))
Тема голанг в принципе интересна, может задачки на литкоде поразобрать. Ты очень прикольно подаёшь материал. Доступно.
@@ipavlyukov это понятно, что можешь разобрать другие темы и можно предлагать их в коментах. а смотреть-то где? вроде умный чел, а на вопрос не ответил =)
@@SavenkoRoman привет, друг!
Потому что не на что кидать ссылку. Ведение своего блога очень большая работа. Чаще я публикуюсь на вот таких каналах как этот, поэтому следовало бы ожидать тут 💀
@@ipavlyukov привет! Я пока нашел только 2 ролика твоих. Где другие глянуть?
почему даже упоминания нету о тестах?
Лайк за ркзидкн ивел)
Это уровень джуна?
Подача очень хорошая. Единственное мне не нравится что вы сокращаете название переменных до s вместо того чтобы написать полностью.
Если взять из контекста эту функцию и показать кому либо вряд ли человек поймет что там ожидается какой то сервис или что либо еще.
особенно это заметно когда вы вызываете e.s.DaysLeft()
Краткость именования полей - визитная карточка Go. Но, конечно, стоит опираться на стандарты компании в которой вы работаете.
Пытаюсь освоить Go сейчас. Если такая реализация соответствует требованиям для джуна, то я пожалуй просто рядом с офисом компании постою, в окна позаглядываю.
Что, всё так плохо?
@@denisbogdanov8976 Нет, ещё хуже)
а что дома в пальто?
Очень простое задание как по мне
middleware это proxy? очень похоже
но в школе не вижу курса по golang
Не вижу новых задачек для оффера(
Есть новое видео про таймслоты, но на другом канале
чтобы получать сочные оферы надо скипать тестовые задания.
Прекрасный симбиот в стиле для чайников с последующей полной жестью!)) Нихрена не понял...
извиняюсь но у меня кажется с самого начала ничего не получается . скачал я все что нужно для 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 думаю проще с сайта скачать установщик
Посоветуйте норм курс по го
Спасибо, интересно. Но почему int64? Можно было int32, или даже int16
А если дата поменяется и кол-во дней будет большое?
Больше чем 32768? Нет ну может в теории... В любом случае int32 точно бы хватило.
Он так сочно рассказывает как тот повар из мема который говорит "Еее, бой"
Топ
За усилия плюс, за суть скорее минус.
вопрос: а если бы мы в эндпоинте не описывали интерфейс, а просто передали бы сервис - это уже не был бы депенденси-инжекшион?
Был бы, но ведь нам нужно показать, что мы знаем как применить интерфейс для инъекции зависимости.
Не буду лукавить, видео неполное, изначально в планах были еще юнит тесты.
Я бы еще добавил блокчейн и кубер
А где DI и тесты ?
Меня одного смущают названия переменных из одной буквы? Дядя Боб не одобрил бы... Хотя видос по делу.
Согласен: хотя и есть общепринятая практика что переменные, если контекст их использования ограничен, например в пределах видимости нескольких строк на экране, допускают короткие наименования (и однобуквенные). Но тут человек явно переборщил. Особенно дико выглядят эти `a.s = ...; a.e = ...`, мне кажется в структуре такой нейминг не допустим.
В руби это задание делается за 2 минуты
Очень много бойлерплейта
счас бы назвать spring-like архитектурой "когда есть эндпоинт, сервис, репозиторий"
но главное что синьор и работал везде-везде
Найс компания 😂
Всё отлично, но нет тестов
ужасная несправедливость. почему рассказано как открыть ссылку в браузере на маке и на винде, а как на линукс не сказано?
Тыж на линуксе)
Напиши свой бразуер просто
@@erik_james видимо поэтому и не сказано, что написание браузера не умещается в хронометраж видео))
@@andreysakharov6210 все таки приятно ж быть пользователем линуха) все по умолчанию думают что ты запросто можешь писать свои драйвера на ассемблере, вот лишний раз и не рассказывают как там ссылочки открывать😁😅
👍 HO на фейс не обязательно переключать кажд 5 мин , главное код
похоже на Express JS
блин подгорает как то немного...не нужно сокращений этих....лучше всего переменные полностью называть duration, server, timeUntill и так далее
Смотрю видео и задаюсь одним вопросом - не жарко ли сидеть в свитере и пиджаке в квартире?
это просто жесть. для кого это? для новичков? они ничего не поймут? те, кто уже что-то могут, копирование документации ничего не даст