วีดีโอ

почему в примере с такси иногда возникает дедлок? upd: мне объяснили, почему возникает дэдлок. Объясните плз, как это исправить. Как написать всё правильно. Пример то вроде хороший, и хотелось бы знать, как такое реализовать

я сидел на неовиме несколько лет и спрыгнул в jetbrains + vim plugin, осознал что у меня помимо обычной работы еще появилась работа по поддержке своего конфига в нвиме

Ты это сеньорам расскаживаешь ? 😊

Качественный контент. Хочется нажать кнопку лайк несколько раз. TDD и mocks можно отдельными роликами сделать.

Классное видео, но есть большая проблема для новичков - монтаж, в процессе много простых действий пропускается, хотя возможно рассчитано, на немного более опытных "студентов"

зоопарк горутин:) (подача материала/звук/голос топ)

Нихрена не понятно

все отлично спасибо. меня раздражало только то как ты громко глотаешь. а в целом все полезно!

хорошее видео я посмотрел сорри за ожидание теперь можешь удалять

понравилось название канала :D

20:40 тут нету синхронизации. Мы все еще можем прочитать сначало из одной горутины, переключиться на другую, прочитать из другой еще до того как первая обновит значение. При таком подходе баланс точно так же может уйти в минус

Поначалу рассказывал нормально, а в последние 5 минут пролетел галопом по Европам. Почти как в лекции про мосты из "Как я встретил вашу маму"

Насколько хорошо нужно знать go, чтобы написать такого бота? Что именно нужно знать, просьба подсказать

бит топ

Хорошее видео* *по версии меня

хотелось бы еще побольше ньюансов о том как передаются параметры с типом заданным как итерфейс. например есть интерфейс context.Context и переменную ctx безопасно передавать из ф-и в ф-ю "по значению". потому что под капотом ctx это уже указатель а не сама структура. а почему оно указатель - непонятно. и как это увидеть не копая исходники пакета context.go - неясно.

спасибо

ok == false значит канал закрыт !

Непонятно. Рассказываются догмы, которые нужно самому искать где-то и доказывать, что оно действительно так и применяется вот таким образом. Короче, конспект из лекции, в котором студент сам же не разберётся к концу семестра

Для более лёгкого входа можно попробовать готовые сборки (AstroVim, LunarVim, NvChad)

Уважаемый человек!

великолепно, очень доходчиво. спасибо!

очень нужно разобраться в теме интерфейсов, посоветуйте еще видосов, тут ничего не понял. Может есть что-то прпроще

Все же ключевым аргументом в пользу перехода на vim из vscode для меня стал unix way. Когда очередной раз сталкиваешься с петушинной реализацией логики нужного плагина, задумываешься о правильности концепции программных комбайнов.

Привет, мне очень нравится твоя подача материала, а так же формат видео в доступной форме. У меня есть предложение для видео, не мог бы ты рассказать, так же показать на примере паттерн Repository в Golang ?

как хочется сделать такой бот, но как и парень в предыдущих комментах застряла на подготовке окружения( goose не видит совсем ни на винде, ни на линуксе. или накосячила на предыдущих этапах. когда-нибудь я его одолею!

девушка не сказала ничего полезного под конец, разве что повторила о том что нельзя проверить приоритет

Я в шоке, ты пишешь быстрее чем я успеваю понимать что вокруг происходит

По-моему самое адекватное объяснение. Спасибо!

очень крутое и понятное видео!

вся эта хрень про мышку и отрыв руки не касается мака да, можно сказать, что можно даже сэкономить на пользовании трэкпадом, но это уже сомнительно - выглядит так, что в vscode многое делается лучше и быстрее. Года полтора назад зарелизили профайлы, теперь 20 профайлов (я использую их под стеки, можно про проекты и что угодно)

Очень полезный материал для тех кто планирует работать в рефлексии

Vim - для людей с феноменальной памятью. Со мной в универе училась девушка, которая смотрела тетрадь с лекциями, потом закрывала и говорила на какой странице в каком углу находится любой текст. Вот для таких людей Vim идеален. Для меня же необходимость запоминать больше 10 сложных клавиатурных комбинаций - это сразу "нет", безотносительно возможных выгод. Я в школе учил 8 строк стихов примерно весь вечер и всё равно не мог их запомнить. Помучился в Vim и бросил. Видео смотрел в надежде узнать, что Vim бесполезен и не нужен. Увы, автор не обрадовал :)

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 } Так допустимо делать?