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