nil-не всегда тот, за кого себя выдает(с) Где то заплакал питонист.))

Далеко не самое лучшее объяснение. Те, кто не знают про интерфейсы ничего не поймут

Видео супер

Общие требования к CLI утилитам из этой презентации 10:42 наличие мануала, актуального утилите. От себя добавлю: имеется юридический аспект, если утилита поставляется пользователю за пределы компании-разработчика. В случае если использование утилиты привело к убыткам у пользователя возможны иски к поставщику утилиты. 11:10 должен быть help вызываемый при помощи флагов -h, --help или при вызове утилиты без аргументов. 14:40 вывод команды: человеко читаемый (по умолчанию) и машинно читаемые форматы, например, json (может быть ещё csv?). 17:15 возможность запуска критических операций в режиме Dry Run. От себя добавлю: должен быть запрос на подтверждение критической операции: yes/no? $ 19:30 отображать ход выполнения длительных операций 20:30 для отображения DEBUG сообщений использовать режим Verbose 21:20 тексты ошибок должны быть понятны пользователю и не должны содержать внутреннюю информацию понятную только программистам 23:10 позиционные аргументы и флаги командной строки должны представлять единообразную систему 24:00 число позиционных аргументов не должно быть больше 2, чтобы пользователь не запутался 24:40 желательно иметь короткие версии для флагов - экономит место 28:10 если много команд, то желательно их поместить в иерархию или дерево команд 29:15 именование команд из 2 позиционных аргументов: object action либо, более редко встречается, - action object. Далее идут флаговые аргументы. 29:55 порядок object action либо action object должен быть единообразным для CLI утилиты 30:45 если выполняется длительная операция, то должен быть graceful shutdown, то есть обработка прерывания от клавиатуры Ctrl+C - закрытие открытых, заблокированных и т.п. ресурсов 31:55 передача аргументов через конфигурационные файлы и переменные окружения 32:40 при смешанной системе передачи аргументов утилите должны быть приоритеты: наибольший приоритет имеют флаги, потом переменные окружения, потом конфиги 33:20 дистрибуция должна требовать от пользователя наименьшее количество шагов по установке 39:30 коды завершения утилиты (exit codes) важны для использования CLI утилиты в сценариях (скриптах) автоматизации

Чудесно звучит 🎉 Когда будет продолжение этой темы разговора

вы здорово объясняете. спасибо

Отличное видео, спасибо вам.

спасибо брат

чего вы там все изучаете? мне кто-то лет 25 назад дал конфиг на vim и с тех пор я этим конфигом пользуюсь и чего-то там изучать никакой нужды нет. Мои познания самого vim ограничиваются 15 минутами, которые понадобились на чтение vimtutor. В 99% случаев ничего за пределами этих знаний вам не понадобится. Поэтому сама постановка вопроса стоит ли изучать vim звучит как-то странно, как будто вы теорию супер струн собрались изучать. Взяли да потратили 20 минут времени на vimtutor вот и все изучение.

13:26 4 аксиома действительна только для небуферизированных каналов func main() { ch := make(chan int, 1) ch <- 1 close(ch) fmt.Println(<-ch, <-ch, "surprise") }

Иногда линтер жалуется на интерфейсы. Например нельзя делать возврат интерфейсов

perfect

func (m *SQLMap) getContext() context.Context { const DefaultTimeout = time.Duration(60 * time.Second) ctx, cancel := context.WithTimeout(context.Background(), DefaultTimeout) defer cancel() newCtx, cancel := context.WithTimeout(ctx, m.timeout) defer cancel() return newCtx } Так допустимо делать?

Круто, респект! Хотелось бы ещё примеров с использованием deadline-ов и работы с БД через контексты.

Привет! На 45:45 ты предлагаешь обернуть все в транзакции. Как это сделать правильно? Переписать методы стора и добавить дополнительное поле к методам или как?

рановато я сюда зашёл)) на assert уже проблемы появились(

интересное, а главное, понятное и доступное видео)

Здравствуйте! Подскажите пожалуйста, как можно с вами связаться, email или что-ещё. Нужна небольшая консультация

1 0 1 мой друг, хочу в backend, выбираю между C#, Golang, Node.js, Java, что посоветуешь, чтобы легче было устроиться на работу с перспективой? Или с какого языка посоветуешь начать?

Я предлагаю вам пройтись по этому документу и разобрать каждый пункт" - Автор. 0:30 На этом моменте чуть не выключил видео что бы найти в инете этот документ и пройтись по нему. На деле посыл автора был - Вместе пройтись . А сколько людей выключило на этом моменте ?

Спасибо за видос, если ещё не пробовал - рекомендую посмотреть модальные редакторы helix или kakouine. В них используется другая, более логичная и удобная парадигма управления ­- вместо action-movement (как в виме) там selection-action. Я уже около года на helix, доволен

дальше "подготавливаем окружение" не ушел, и postgres стоит и docker, а работать не хотят((

Использование собственных кастомных библиотек, и проектирование некоторых моментов «не по гошному» я могу понять только в собственном проекте, но никак не в обучающем видео, которое показано остальным как пример для сохранения в свой репозиторий. Считаю такое максимально бестактным.

как называется IDE на видео? upd: Goland нашел снизу в коменнтах, оставлю тут)

Спасибо за очень качественный контент

Большое спасибо за полезную информацию!

Подача 10/10

In memory + с надежной персистентностью это tarantool, протестированное многими корпами решение

Лучшее видео по этой теме, что я видел в интернете. Есть смысл на бусти подписаться!

Поверхностный взгляд на код: - В storage идет чтение из БД напрямую в структуры model. Это очень плохой подход, т.к. у нас фактически получается что общие модели зависят от структуры БД. Правильнее чтобы в storage были свои структуры, которые на выходе конвертируются в структуры model. - Имена интерфейсов лучше писать так, чтобы они заканчивались на er, т.к. в противном случае получается не интерфейс, ориентированный на какой-то набор операций, а просто непонятное нечно. Например ArticleStorage - интерфейс, отвечающий за что? Глобально за работу с хранилищем? Нет - у него всего один метод Store. Значит это нечто вроде ArticleSaver. - В Notifier передается указатель на объект tgbotapi.BotAPI вместо того чтобы определить интерфейс с методом Send и передавать уже его. - Неструктурированные логи. Вместо log лучше сразу привыкать к zap (причем без Sugar), slog и т.п.

Такие миграции никогда не пройдут ревью в серьезной команде: - поля времени без таймзоны - varchar вместо text (это бессмысленно, т.к. varchar это просто text с навершенным на него ограничением на длину) - устаревший синтаксис (SERIAL вместо IDENTITY, CONSTRAINT вместо REFERENCES) - goose StatementBegin/StatementEnd там где он не нужен Это только то что сразу бросается в глаза Кроме того, миграции это то, что доступно извне и используются внешними утилитами при деплое, т.е. идеологически не должно быть в Internal. Но это уже холиварная тема.

Чтобы это все понять, надо поработать какое-то время в хайлоаде. Иначе, скорее всего, в одно ухо влетит - из другого вылетит, т.к. нет базы.

Пишу телеграм-бота, пытался вручную написать middleware для того, чтобы бот не читал слишком старые сообщения, как вдруг увидел эту библиотеку. Спасибо за объяснение.

Отличная подача материала, а так же качество презентации

Хорошая подача, спасибо за информацию, было оч приятно послушать

Очень полезная информация! Спасите большое!

Спасибо. Хороший материал

спасибо за видео, очень полезно 🙂

Приветствую, не знаю как на других языках, но в GO, все логеры, которые я видел, выдают логи в os.StdErr, а не в Out (небольшая поправочка). Засим вопрос от человека пишущего свой логер: есть ли смысл Fprintf (или функцию с ним) оборачивать в горутину, ибо в GO вроде отдельная очередь на I/O. Естественно , только нагрузочное может дать ответ на этот вопрос со 100% точностью, но до этого еще далеко.

😮

Спасибо! Отличное освещение темы.

1

Спасибо автору, очень качественное видео и сильно экономит время перед собесом

00:00 - Вступление 02:01 - №1. Кодовая база 04:50 - №2. Зависимости 07:04 - №3. Конфигурация 09:26 - №4. Внешние сервисы 10:40 - №5. Сборка, релиз и выполнение 13:02 - №6. Процессы без состояния 14:42 - №7. Привязка портов (port binding) 16:04 - №8. Конкурентность 17:10 - №9. Одноразовые и утилитарные процессы 19:54 - №10. Паритет окружений 23:40 - №11. Логи 25:32 - №12. Инструменты администрирования Полезные ссылки: - Оригинальный документ “The Twelve-Factor App”: 12factor.net/ - Сигналы в UNIX: ru.wikipedia.org/wiki/%D0%A1%D0%B8%D0%B3%D0%BD%D0%B0%D0%BB_(Unix) - Patterns of Enterprise Application Architecture, Martin Fowler: books.google.ge/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC&redir_esc=y - Logs Are Streams, Not files: adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/

спасибо тебе огромное за это мега полезное видео!

Нет, есть более удобные редакторы. Точка)

Спасибо!