Возможно, makefile гибче, но мне больше нравится формат и синтаксис taskfile, и я пока не упирался ни разу в предел его возможностей
Миграции у меня не в internal, а в корне лежат. Похоже, вы ошиблись. Ну или у меня где-то опечатка (где?)
Мне slog очень понравился, и в него можно обернуть и тот же zap при желании. В видео я объяснял - slog хорош тем, что он универсален. Если использовать zap, то будет очень сложно в будущем переехать на что-то другое.
Я сначала пишу проект целиком, а потом уже пишу по нему статью. При таком подходе местами приходится воспроизводить некоторые старые куски кода по памяти (например, сначала написали одним способом, потом переписали иначе).
Статью я писал долго, и даже после написания опубликовал далеко не сразу. Параллельно я и проект дорабатывал, что-то улучшал, переделывал. Соответственно, в статье некоторые куски кода тоже надо было обновлять. А мой markdown-редактор, увы, не пытается компилировать куски кода и проверять их на наличие ошибок.
Кроме того, во время написания часто возникают новые мысли, хочется написать какие-то куски кода иначе, что-то забывается и множество других факторов.
Статья получилась очень большая, и лично я удивился бы скорее отсутствию ошибок в ней. Попробуйте написать что-то соразмерное, поймёте о чем я говорю.
Вообще, то о чем вы говорите элементарно проверяется. В статье есть ссылка на видео, в котором я пишу этот же код вживую и намного подробнее объясняю происходящее. Там видно, что всё прекрасно компилируется, запускается. Кроме того, загуглить и найти плагиат в наше время может даже ребёнок. Почему бы вам это не сделать, и не скинуть сразу пруфы и ссылки на оригинал?
Но, конечно, гораздо проще бросаться необоснованными обвинениями в плагиате и воровстве.
Тут все очень по разному говорят. Я в таких случаях обычно опрос у себя в ТГ-канале провожу — что людям больше хочется увидеть в гайде, то и беру для примера.
Понял. Окей, спасибо. Я такие замечания учитываю, потому что самому сложно понять, насколько это удобно.
Крупный шрифт тут для того, чтобы видео было удобно смотреть на разных устройствах, в том числе на маленьких экранах. Хуже всего, когда автор записывает на каком-нибудь 4к экране, а ты пытаешься смотреть это на 13-дюймовом ноуте или на планшете.
Но можно попробовать в следующий раз как-то плавнее перемещаться по коду и между файлами.
Окей, теперь понял, что вы имели ввиду. Да, это имеет смысл, и в рабочих проектах я именно так и делаю.
В этом проекте решил немного упростить, т.к. это пет-проект — тут и три окружения то вряд ли наберется, скорее только локал и прод. Но, возможно, даже в этом случае стоило явно передавать параметры логгера, для прозрачности.
Очень зря вы не читали внимательно, потому что именно так у меня и сделано — конфиуграцию я беру из конфиг файла, и объясняю как брать из переменных окружения (тут уже на выбор читателя). В названных вами константах хранятся лишь значения, с которыми мы сравниваем то, что получили из конфига.
А место, в котором я проверяю текущее окружение (if env prod) — это просто сборка логгера, который немного отличается в разных окружениях. Тип текущего окружения берётся всё из того же конфига.
graceful shutdown — тут да, стоило его упомянуть. Но не беда, расскажу в следующем посте / ролике.
Это точно будет в отдельном видео про мониторинг, на примере этого же сервиса. Я не хотел, чтобы эта статья / ролик распухали слишком сильно, и без того получилось очень объёмно.
Там также будет разобрана настройка Grafana и Loki, кстати. То есть и метрики, и логи, и алерты будут уходить туда.
Будет ли статья на эту тему, не уверен. Возможно, только видео.
Если человек обратился за помощью, а вы отмахиваетесь книжками про алгоритмы, это значит только то, что вы абсолютно не желаете и не пытаетесь ему помочь.
Во-первых, при всей моей любви к книгам, их ценность в этой статье сильно преувеличена. В случае программирования, на первое место должна вставать практика. Можно трижды прочитать книгу по алгоритмам, понять каждую строчку, но при этом не овладеть этими самыми алгоритмами. Обучение более сложный процесс.
Во-вторых, тот факт, что человек не готов читать подобные книги и прошибать лбом стены, не значит что человек плохой, бездарный и т.п. Это просто данность. Если хочется реально помочь человеку, нужно помочь ему найти такой способ обучения, который ему будет интересен. Нужно нащупать, что цепляет человека, какие каналы информации он лучше усваивает и т.п.
Вот это будет ценная помощь. Но это непросто, тут нужно подключать мозг, тратить на человека время, вникать в его проблемы. Гораздо проще поставить на человеке крест и решить, что он сам виноват.
Да, есть и крайности — есть люди, которым достаточно задать направление, а дальше они сами разберутся. Но давать им сразу Кнута, это так себе затея. Велик риск на годы отбить у человека страсть к программированию.
Есть и другие крайности — сколько с человеком не возись, он так и не вырастет в хорошего программиста. Возможно, программирование просто не их область.
Автор упомянутой в начале статьи как раз пытается вникнуть в проблемы людей, которые почему-то не осилили. Он бы мог сказать — «просто люди тупые, что с них взять?». Вместо этого он решил проанализировать и разобраться, в чем конкретно проблема, и можно ли её «пофиксить».
Спасибо, рад что понравилось :)
Возможно, makefile гибче, но мне больше нравится формат и синтаксис taskfile, и я пока не упирался ни разу в предел его возможностей
Миграции у меня не в internal, а в корне лежат. Похоже, вы ошиблись. Ну или у меня где-то опечатка (где?)
Мне slog очень понравился, и в него можно обернуть и тот же zap при желании. В видео я объяснял - slog хорош тем, что он универсален. Если использовать zap, то будет очень сложно в будущем переехать на что-то другое.
Спасибо, я как раз заканчиваю новую статью — аналогичную этой, но вместо REST API будет gRPC. Видео тоже будет.
Я сначала пишу проект целиком, а потом уже пишу по нему статью. При таком подходе местами приходится воспроизводить некоторые старые куски кода по памяти (например, сначала написали одним способом, потом переписали иначе).
Статью я писал долго, и даже после написания опубликовал далеко не сразу. Параллельно я и проект дорабатывал, что-то улучшал, переделывал. Соответственно, в статье некоторые куски кода тоже надо было обновлять. А мой markdown-редактор, увы, не пытается компилировать куски кода и проверять их на наличие ошибок.
Кроме того, во время написания часто возникают новые мысли, хочется написать какие-то куски кода иначе, что-то забывается и множество других факторов.
Статья получилась очень большая, и лично я удивился бы скорее отсутствию ошибок в ней. Попробуйте написать что-то соразмерное, поймёте о чем я говорю.
Вообще, то о чем вы говорите элементарно проверяется. В статье есть ссылка на видео, в котором я пишу этот же код вживую и намного подробнее объясняю происходящее. Там видно, что всё прекрасно компилируется, запускается. Кроме того, загуглить и найти плагиат в наше время может даже ребёнок. Почему бы вам это не сделать, и не скинуть сразу пруфы и ссылки на оригинал?
Но, конечно, гораздо проще бросаться необоснованными обвинениями в плагиате и воровстве.
Да, это ошибка, поправил. Недостающую обработку empty request тоже добавил.
Спасибо.
Понял, спасибо. Поправил тоже.
Да, есть такой момент, я в ролике об этом тоже говорил. Статью старался сделать не слишком огромной, поэтому некоторые моменты пришлось сократить.
Это один из многих важных моментов, которые, вроде бы, нельзя выкидывать. Но если всё это оставлять, то получится не статья, а книга ?
А тут не не понял, в чем ошибка? Вроде, всё ок.
Спасибо, поправил
Тут все очень по разному говорят. Я в таких случаях обычно опрос у себя в ТГ-канале провожу — что людям больше хочется увидеть в гайде, то и беру для примера.
Понял. Окей, спасибо. Я такие замечания учитываю, потому что самому сложно понять, насколько это удобно.
Крупный шрифт тут для того, чтобы видео было удобно смотреть на разных устройствах, в том числе на маленьких экранах. Хуже всего, когда автор записывает на каком-нибудь 4к экране, а ты пытаешься смотреть это на 13-дюймовом ноуте или на планшете.
Но можно попробовать в следующий раз как-то плавнее перемещаться по коду и между файлами.
В каком смысле увеличивал? В какие-то конкретные моменты, или напротяжении всего видео было слишком крупно?
Окей, теперь понял, что вы имели ввиду. Да, это имеет смысл, и в рабочих проектах я именно так и делаю.
В этом проекте решил немного упростить, т.к. это пет-проект — тут и три окружения то вряд ли наберется, скорее только локал и прод. Но, возможно, даже в этом случае стоило явно передавать параметры логгера, для прозрачности.
Очень зря вы не читали внимательно, потому что именно так у меня и сделано — конфиуграцию я беру из конфиг файла, и объясняю как брать из переменных окружения (тут уже на выбор читателя). В названных вами константах хранятся лишь значения, с которыми мы сравниваем то, что получили из конфига.
А место, в котором я проверяю текущее окружение (if env prod) — это просто сборка логгера, который немного отличается в разных окружениях. Тип текущего окружения берётся всё из того же конфига.
graceful shutdown — тут да, стоило его упомянуть. Но не беда, расскажу в следующем посте / ролике.
Все по разному усваивают гайды — кому-то лучше заходит текст, кому-то видео.
Если эта статья хорошо зайдёт, то буду стараться все новые ролики также публиковать в виде постов.
Это точно будет в отдельном видео про мониторинг, на примере этого же сервиса. Я не хотел, чтобы эта статья / ролик распухали слишком сильно, и без того получилось очень объёмно.
Там также будет разобрана настройка Grafana и Loki, кстати. То есть и метрики, и логи, и алерты будут уходить туда.
Будет ли статья на эту тему, не уверен. Возможно, только видео.
Читаю каждый раз
Во-первых, при всей моей любви к книгам, их ценность в этой статье сильно преувеличена. В случае программирования, на первое место должна вставать практика. Можно трижды прочитать книгу по алгоритмам, понять каждую строчку, но при этом не овладеть этими самыми алгоритмами. Обучение более сложный процесс.
Во-вторых, тот факт, что человек не готов читать подобные книги и прошибать лбом стены, не значит что человек плохой, бездарный и т.п. Это просто данность. Если хочется реально помочь человеку, нужно помочь ему найти такой способ обучения, который ему будет интересен. Нужно нащупать, что цепляет человека, какие каналы информации он лучше усваивает и т.п.
Вот это будет ценная помощь. Но это непросто, тут нужно подключать мозг, тратить на человека время, вникать в его проблемы. Гораздо проще поставить на человеке крест и решить, что он сам виноват.
Да, есть и крайности — есть люди, которым достаточно задать направление, а дальше они сами разберутся. Но давать им сразу Кнута, это так себе затея. Велик риск на годы отбить у человека страсть к программированию.
Есть и другие крайности — сколько с человеком не возись, он так и не вырастет в хорошего программиста. Возможно, программирование просто не их область.
Автор упомянутой в начале статьи как раз пытается вникнуть в проблемы людей, которые почему-то не осилили. Он бы мог сказать — «просто люди тупые, что с них взять?». Вместо этого он решил проанализировать и разобраться, в чем конкретно проблема, и можно ли её «пофиксить».