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