Никакой ротации IP, проксей и тд - тема не раскрыта. Какой то временный лайфхак в надежде что хостера не забанят.
Хранение данных в seen.json - отдельная жесть при потенциальной нагрузке и рейтам публикации новых объявлений. Никакой обработки сигналов. Что там будет на Ctrl+C?
Архитектура уровня "один файл — весь проект". Никакого разделения на модули: API, логика, Telegram, конфиг, никаких тестов.
А это точно парсер? Игнорирование базовых анти-скрапинг мер (headers, cookies, рандомизация запросов)
На самом деле все зависит от желания учиться и страдать. А страдать придется очень много: хоть из разраба приходи, хоть из админа.
Обычно приходят из админов: если человек понимает за Linux, может строчить большие скрипты это уже очень хорошая точка входа. А если под админом понимать эникей - то эникею лучше сначала в хорошего админа расти.
Возможно, это не тема данной статьи, но, кажется, нужно было раскрыть тему и про этапы калибровки алертов и тестирования. Это всё важные этапы спокойствия дежурных на oncall
https://samber.github.io/awesome-prometheus-alerts/ можно начинать отсюда, адаптируя под свои нужды. Также много есть просто поиском на github. Флоу простой: смотрите какие метрики экспортер отдает и ищите в github примеры алертов
Я не очень понял, Вас напугало выставление галочки? Или вы решили что за 139 у вас будет штат инженеров, которые решат все вопросики, включая настройку сертификатов. Поищите статьи которые рассказывают как настроить сайты-визитки на их vps серваках и вы очень удивитесь насколько там все сложнее описано. Но мы то знаем зачем они гонят туда народ ;)
Примерно по той же причине почему мы не собираем локально программы и не выкладываем их руками.
Но вы можете делать так как вам нравится и все выкладывать руками. Я предпочитаю вариант когда все собралось и выложилось, а вариант локального запуска оставить для отладки
После пуша github actions пнет hugo чтобы тот из md файлов собрал вам статичный сайт, который будет содержать связанные html страницы, картинки, js и тд. Те по сути готовый статичный сайт. И далее actions опубликует его в pages
Так иногда случается, что где то можно ошибиться - было 5 различных источников. Не всегда получается сделать все идеально. Предлагаю вам самому попробовать написать идеальную статью, а мы посмотрим что получится.
А картинку и факты что вы указали я проверю и поправлю.
Ну лично я потратил где то 4 часа в сумме чтобы подготовить материал. И вот упрекать в том, что это небрежно надерганные факты как минимум некрасиво с вашей стороны
Мне понравился формат подачи. Как мне кажется, эта статья не заменяет технические в процессе изучения куба, а дополняет его, позволяя простым языком ответить аналогиями на вопрос зачем эта сущность.
Я говорю про кейсы когда поиск делается по истории в самом git - есть более сложные сценарии чем просто поиск по пулрекам. В любом случае смысл статьи не в том, чтобы сказать что надо делать именно так. Это всего лишь пост про один из возможных сценариев - использовать его или нет - дело лично каждого.
Никакой ротации IP, проксей и тд - тема не раскрыта. Какой то временный лайфхак в надежде что хостера не забанят.
Хранение данных в seen.json - отдельная жесть при потенциальной нагрузке и рейтам публикации новых объявлений. Никакой обработки сигналов. Что там будет на Ctrl+C?
Архитектура уровня "один файл — весь проект". Никакого разделения на модули: API, логика, Telegram, конфиг, никаких тестов.
А это точно парсер? Игнорирование базовых анти-скрапинг мер (headers, cookies, рандомизация запросов)
На самом деле все зависит от желания учиться и страдать. А страдать придется очень много: хоть из разраба приходи, хоть из админа.
Обычно приходят из админов: если человек понимает за Linux, может строчить большие скрипты это уже очень хорошая точка входа. А если под админом понимать эникей - то эникею лучше сначала в хорошего админа расти.
В голову приходит мем "программиравай"
Возможно, это не тема данной статьи, но, кажется, нужно было раскрыть тему и про этапы калибровки алертов и тестирования. Это всё важные этапы спокойствия дежурных на oncall
https://samber.github.io/awesome-prometheus-alerts/ можно начинать отсюда, адаптируя под свои нужды. Также много есть просто поиском на github. Флоу простой: смотрите какие метрики экспортер отдает и ищите в github примеры алертов
Рад, что удалось разобраться
Я не очень понял, Вас напугало выставление галочки? Или вы решили что за 139 у вас будет штат инженеров, которые решат все вопросики, включая настройку сертификатов. Поищите статьи которые рассказывают как настроить сайты-визитки на их vps серваках и вы очень удивитесь насколько там все сложнее описано. Но мы то знаем зачем они гонят туда народ ;)
Примерно по той же причине почему мы не собираем локально программы и не выкладываем их руками.
Но вы можете делать так как вам нравится и все выкладывать руками. Я предпочитаю вариант когда все собралось и выложилось, а вариант локального запуска оставить для отладки
После пуша github actions пнет hugo чтобы тот из md файлов собрал вам статичный сайт, который будет содержать связанные html страницы, картинки, js и тд. Те по сути готовый статичный сайт. И далее actions опубликует его в pages
Из моего опыта - всегда найдется тот кому что-то не нравится, это в природе человека. Поэтому вопрос идеальности тут совсем не стоит.
Вопрос только в том, что критика конструктивна или у условного комментатора плохое настроение и он решил поделиться им с остальными.
По поводу потраченного времени - тут все очень индивидуально. И да, количество потраченного времени не эквивалент успешности в любом деле.
Ваш изначальный комментарий не критика, а вброс. Никакой пользы он не несёт и критике не имеет отношения.
Так иногда случается, что где то можно ошибиться - было 5 различных источников. Не всегда получается сделать все идеально. Предлагаю вам самому попробовать написать идеальную статью, а мы посмотрим что получится.
А картинку и факты что вы указали я проверю и поправлю.
Ну лично я потратил где то 4 часа в сумме чтобы подготовить материал. И вот упрекать в том, что это небрежно надерганные факты как минимум некрасиво с вашей стороны
Мне понравился формат подачи. Как мне кажется, эта статья не заменяет технические в процессе изучения куба, а дополняет его, позволяя простым языком ответить аналогиями на вопрос зачем эта сущность.
--amend --no-edit вы ж к последнему коммиту применяете. В примере мы меняем не последний коммит.
Я говорю про кейсы когда поиск делается по истории в самом git - есть более сложные сценарии чем просто поиск по пулрекам. В любом случае смысл статьи не в том, чтобы сказать что надо делать именно так. Это всего лишь пост про один из возможных сценариев - использовать его или нет - дело лично каждого.
Если использовать поиск по истории - то commit message это довольна важная штука.
лучше, но в целом можно и так сказать =)
Согласен, так лучше
В точку!