Процесс сейчас такой: cdk diff перед каждым деплоем, деплой только конкретного стека, никакого deploy --all. Плюс правило, что сетевое на месте не правится: нужна другая раскладка - переименовываешь construct и получаешь create-before-delete вместо попытки перекроить живое.
Честно про предиктив-чеки: на момент инцидента автоматического гейта не было, и это была главная дыра. Причём план ресурсов у нас был - CloudFormation в диффе честно писал Replacement: True. Просто читал его человек, в конце рабочего дня, глазами, и увидел то, что хотел увидеть. Информация была, гейта не было.
Что мы из этого сделали:
cdk diff в CI, вывод грепается на replace/destroy. Есть замена ресурса - пайплайн краснеет и требует явного подтверждения руками. Самое дешёвое из всего списка и ловит ровно наш класс аварий.
Termination protection на стеки с состоянием и RemovalPolicy.RETAIN на базы. Это уже не предиктив, а страховка на случай, когда предиктив не сработал.
Разнесли сеть и базу по разным стекам. Радиус поражения стека равен всему его содержимому, и пока база лежала в одном стеке с VPC, любая правка сети была ставкой на данные.
Про линтер отдельно: cfn-lint по синтезированному шаблону как раз делает то, о чём вы спрашиваете - проверяет, что ссылки резолвятся и типы сходятся. Вещь полезная, но нашу аварию он бы не поймал: шаблон был идеально валиден. Он просто делал не то.
В этом, наверное, и мораль. Линтер ловит невалидное, а больно делает валидное. Поэтому гейт стоит вешать не на вопрос “правильно ли написано”, а на вопрос “что именно при этом будет заменено”.
Точно, про хостинговые читалки я и забыл - там вообще ничего поднимать не надо. Тогда у человека полный набор вариантов на любой вкус, от feedly в один клик до Actions с гитом. Спасибо, ветка получилась полезнее самой статьи.
Согласен, так и есть: с сервером, который копит у себя, лимит перестает что-либо значить. Мое замечание работало только потому что исконный спрашиватель писал такое: "Селф-хостинг как-то стрёмно оставлять на две недели." Есть железка или VPS - ваш вариант однозначно лучше, синхронизация прочитанного и regex-фильтры в самодельном скрипте не появятся никогда. Не готовы - остаются хабовые фиды, которые за счет низкого трафика держат окно неделями, или GitHub Actions в роли того же накопителя, только бесплатного и чужого.
Про бесполезность для аналитики полностью подписываюсь (хотя и не потому, что лимиты): там нужны score и время каждого комментария, а в RSS этого нет и быть не должно.
Спасибо, полез проверять и заодно померил, насколько этого хватает. Результат интереснее, чем я ожидал.
Потолок у всех фидов Хабра одинаковый и жесткий - 41 запись. Пагинации нет вообще: ?page=2 и /page2/ отдают тот же ответ байт в байт. А вот глубина этого окна зависит только от того, сколько в фид сыплется:
общая свежая лента - около 4.5 часов новости - около 15 часов top/daily - сутки, top/weekly - неделя, top/monthly - до 20 июля хаб programming - 4 дня хаб cpp - с 24 июля хаб ruby - аж с апреля 2024
Отсюда и ответ на исходный вопрос. Общая лента для двухнедельного отпуска бесполезна, за 4 часа окно уезжает. А вот подписка на конкретные хабы работает как надо, и никакого сервера для этого не надо: узкий хаб держит месяцы, широкий - несколько дней. Плюс top/monthly для общей картины, если не хочется совсем ничего пропустить из громкого.
Так что для чтения RSS явно удобнее моей возни с JSON. JSON остается нужен, только если хочется полную ленту без отбора по хабам и топам.
Но без GHA или своей арендованной железки всё равно не обойтись...
Проверил, любопытно вышло: риск-то как раз не подтверждается. Первые в треде короткие однострочники (меньше 60 знаков, тексты я не хранил, так что мерил длиной) набирают в среднем 4.38 плюса против 3.59 у развернутых, и в минусе оба варианта одинаково редко, около 4%.
А вот в общей массе, не на первой позиции, короткие ощутимо хуже длинных: 38.7% в плюсе против 47.1%. То есть однострочник наказывается везде, кроме одного места - самого начала треда. Похоже, позиция вытягивает даже “Первый комментарий!”, и в этом есть своя жестокая справедливость. Видимо, многие из нас ещё помнят олбанскей.
Один файл, и пусть он копится. Словарь вида id статьи - заголовок, ссылка, дата, и на каждом запуске вы просто дописываете в него то, чего там еще нет.
Отдельные файлы по датам смысла не имеют ровно потому, что вы уже в гите: историю за вас ведет он. Более того, это и есть главный бонус такой схемы - в диффе очередного коммита лежит ровно список того, что появилось с прошлого запуска. Из отпуска можно даже не открывать сам файл, достаточно пролистать коммиты за две недели, каждый со своим списком новинок.
Единственное, что стоит сделать сразу: сортируйте ключи при записи (json.dump с sort_keys=True, indent=2). Иначе питон будет тасовать порядок, и каждый дифф превратится в шрапнельные правки вместо аккуратного списка
У вас тоже всё сломается, и никто не предупредит. API недокументированный, никаких гарантий обратной совместимости у нас с вами нет.
Но без паники! Первая: это не публичное API для сторонних разработчиков, а внутреннее для собственного фронта, и меняется оно тогда, когда переписывают фронт. v2 живет годами, я на него натыкался еще до того, как взялся за статью. Вторая: при переезде на v3 старую версию обычно какое-то время не выключают, потому что на нее завязаны и мобильные приложения, и закешированный у людей фронт.
Практически нужно одно - чтобы поломка была громкой, а не тихой. Я бы сделал, если бы это была не поделка для себя, а кровавый энтерпрайз, проверку, что в ответе действительно есть publicationRefs и он непустой, а если нет - падать с шумом. GitHub Actions на упавший workflow сам пришлет письмо, и вы узнаете о поломке в тот же день, а не через месяц пустого файла. Чинится это потом теми же пятью минутами в девтулзах: открыли ленту, посмотрели, куда фронт ходит теперь, поправили URL.
Проверил на данных - вы правы, и этого фактора в статье нет, спасибо. Сырые цифры по глубине вложенности:
уровень 0 (корневой): 55.6% в плюсе, средний 2.71 уровень 1: 48.9%, 2.03 уровень 2: 43.5%, 1.34 уровень 3: 38.6%, 1.18 уровень 4 и глубже: 33.7%, 0.83
Но тут та же ловушка, что и с временем суток, поэтому сразу проверил на свежих комментариях, моложе трех часов: 5.36 у корневых, 4.29 на первом уровне, 3.47 на втором. Разрыв остается, но заметно ужимается - значит бОльшая часть сырой разницы это опять свежесть и позиция, которые прячутся за глубиной. Ответ по определению приходит позже того, на что отвечает.
Механика, судя по всему, простая: корневой комментарий видят все, кто открыл статью, а ответ на пятом уровне - только те, кто дочитал ветку. Читателей меньше, голосов меньше.
Ссылку из моего прошлого комментария просто вставьте в адресную строку - у ФФ вроде есть встроенный просмотрщик JSON, откроется деревом, с поиском и кнопкой “Необработанные данные”. Меняете page=1 на page=2 и смотрите, что приходит. Девтулз нужен только чтобы подсмотреть незнакомую ручку, а я уже всё спалил.
Про просмотры не соглашусь, тут мухи с котлетами склеились. Просмотры это не "статья остыла", а "статью много читают", и на свежих комментариях это прям видно: среди тех, что написаны в первые три часа, у статей выше медианы по просмотрам средний урожай 8.3 плюса и 78% в плюсе, у статей ниже медианы - 1.4 плюса и 54%. Одинаковая свежесть, разница почти шестикратная. В регрессии то же самое: log(просмотров) даёт +0.165 при t=9.4, и это уже с учётом лага.
Так что правило не "беги от популярных", а "беги от несвежих, беги к популярным". Пятый комментарий под будущим хитом лучше первого под статьёй-невидимкой.
Со всем остальным согласен, и особенно с последним. Скорость против качества это реальный размен, и мои данные его не разрешают: качество комментария я не мерил вообще. Единственный честный выход из него не "печатай быстрее", а "комментируй то, в чём и так разбираешься". Тогда чтение статьи занимает пять минут, а не полчаса, и в первую десятку успеваешь без стрельбы по ногам.
Про "лягушатник" точное наблюдение. Похоже, эта функция отвалилась вместе с обязательным фармом кармы: тренироваться теперь негде, а сразу писать статью страшно. Ну мне, например, после возврата, страшно было...
Дык, GitHub Actions - халява же. Репа со скриптом, workflow по расписанию (on: schedule, cron), скрипт складывает свежие id в JSON и коммитит его обратно в репу. Из отпуска открываете файл прямо в вебе с телефона, когда сеть появится. Для публичного репозитория это бесплатно, а лимитов хватает с запасом: пара минут раз в день.
Один попадос есть: GitHub отключает scheduled workflows в репке, где 60 дней не было активности. Но раз наш workflow сам коммитит результат, активность есть каждый день, и отключать его не за что.
Я часто так делаю для целей самообновляющихся файликов в вебе, тащемта
Взаимосвязь не учитывал, но ваш вопрос заставил пойти и посчитать. Смотрел пары “автор статьи - комментатор”, которые за неделю встретились больше одного раза.
Таких пар 11 из 2481, это 40 комментариев из 4399, меньше процента. И живут они хуже среднего: в плюсе 40% против 46.4%, средний score 0.75 против 1.84. Постоянных групп поддержки, которые ходят за автором из треда в тред, в недельном срезе просто нет в товарных количествах.
Две честные оговорки. Голоса анонимны, так что кружок, который молча плюсует и не пишет, этим способом не поймать никак. И в моделях контроли на уровне статьи - просмотры, рейтинг, размер треда, - но не поправка на каждую конкретную статью. Специфика жанра “мужики, я 15 лет в айти” учтена ровно настолько, насколько она видна в этих трёх числах.
Нет, как и качество комментариев. Вопрос стоит как: при равном качестве комментариев и одинаково популярном авторе комментария куда выгоднее его поставить? Понятное дело, что если придёт на Хабр Карпатый какой-нибудь, то его любой коммент наберёт лайков. Так же с качеством: коммент может завируситься, например. Но это выбросы.
Я решал задачу для себя. Я - тот, кто я есть и писать комменты умею так, как умею. На это повлиять я не могу. Могу повлиять лишь на то куда и когда писать.
DevTools -> вкладка Network -> фильтр Fetch/XHR, дальше просто листаете ленту и смотрите, что уходит на habr.com/kek/v2/. Всё, что видно на странице, там же и лежит в JSON.
В ответе publicationRefs - id, заголовок, время, статистика; pagesCount - сколько всего страниц. Два подводных камня, оба стоили мне вечера: без period прилетает 422, а с дефолтным curl-овским User-Agent Хабр не ругается, а молча отдаёт урезанный ответ - ставьте браузерный UA.
Плохая новость: pagesCount упирается в 50, это 1000 статей за проход, дальше 400. period=monthly сейчас достаёт до 15 июля - ваш отпуск бы закрыл впритык, но окно едет каждый день, так что архив за прошлое уже не собрать.
Хорошая: на будущее это ровно то, что вам нужно. Раз в пару дней дёргать period=weekly (32 страницы), складывать id в локальный файл - и никакого «долистал только до 28-го». Заготовка есть в гисте из статьи, collect_habr.py делает ровно этот постраничный обход с паузой 0.6-0.7 с между запросами: https://gist.github.com/k41n/973a7593738393e21ce7165be2e9c8f3
Вы очень точно описали ситуацию, только не в том порядке. Сначала идёт экономия на специалистах, отчего хороший (тешу себя мыслью) тимлид и играющий фулстек сеньор садится разбираться с CDK, далее, по классике, эффект Даннинга-Крюгера после пары-тройки успешно сделанных по аналогии несложных изменений и, отсюда же, отсутствие DR стратегии. Знаете во сколько лет я узнал этот термин? Только что, от Вас, спасибо, BTW.
А я ещё притчу знаю, в тему. Про двух дровосеков, которые поспорили: кто больше за день нарубит деревьев. Один не переставая молотил и радовался, когда слышал, что второй каждый час делает паузы на 10 минут. "Устаааал, не вывоооозит, обгоню, надо поднажать!!!", - думал первый. Однако, на подведении итогов второй обошёл почти вдвое. Выяснилось, что 10 минут в час он точил топор.
А вот в коммерции почти всегда "надо поднажать!!!", потому что в отчёте наверх строчка "стабилизировали деплой, перебрали кластер, сделали детерминированной сборку образа" не отвечает на вопрос: "А какие business values вы добавили за месяц работы"?
Про масштаб принимаю, довод честный. На десятке скиллов всё держится в голове, на тысяче не держится.
Смущает меня другое место в вашей формулировке. «Насколько вы будете понимать, как он работает» — при тысяче скиллов вы не понимаете их глазами в любом случае, кто бы их ни писал. Тысячу, написанную руками, вы точно так же не удержите. Систематизация решает навигацию: где лежит, за что отвечает, кто с кем связан. А вот вопрос «делает ли оно то, что я думаю» она не закрывает, и чем больше скиллов, тем сильнее эти две задачи расходятся.
Раз позвали поделиться — вот наш способ, он глупый и рабочий. Все скиллы, которыми бойцы в конторе решили поделиться, лежат во внутренней репе, в папочках. Есть скрипт, который перед пушем переделывает оглавление и проставляет ключевики (через запрос к LLM), результат выкладывается в TOC.md. Поэтому я могу спросить агента: «а есть у нас скиллы, чтобы CODEOWNERS заполнить?» — и он найдёт.
Но это ровно навигация и ничего сверх неё. Что скилл после правки стал делать не то, наш TOC не поймает, и мы пока ничем не ловим.
Отсюда встречный вопрос, и он мне правда интересен: а у вас есть регресс на сами скиллы? Когда правите один из тысячи, чем вы ловите, что поведение агента поехало? Вот эту часть я бы прочитал отдельной статьей!
Правило первое в Уложении самое дорогое: «не оставлять в подвалах древних устройств, о которых никто не знает, что они делают. Если разобрать его дорого, разбери его дорого».
Оно и раньше было верным, просто «дорого» означало опытного мужа, полгода его жизни и кладку, вскрытую в шести местах. А такого мужа всегда есть чем занять полезнее. Оттого весна, до которой собирались разобрать, за одиннадцать перестроек так ни разу и не наступила.
К нынешнему лету поменялось вот что. В подвал можно послать гонцов, которым неудобно не бывает. Им всё равно, что вода по щиколотку и что к железной штуке с табличкой не надо подходить. Послать можно десяток разом, и не с наказом «выясни, что там», а велеть пройти по каждой цепи до конца и переписать всё, к чему она привязана. Подъёмник для дров и колокол в часовне нашлись бы не в лето 35-е, а к обеду того же дня.
Вот только гонец, посланный в подвал, это тот же мастер Ортольф. Он точно так же составит устав на девятнадцать понятных строк, испытает его на потешном дворе, доложит «найдено добрым», а на вопрос, подобен ли потешный двор Кривенгарду, ответит, что во всём существенном. Разница ровно одна: он сделает это за час и не устанет.
Оттого мне и близок нынешний граф, дядя мой, Роберт Мартинский, тот самый, единственный, кто вообще попал внутрь. Он ныне держится правила такого, что из терема не выходит и работу смердов своих не проверяет вовсе. Доверия тут никакого, просто он обвесил их испытаниями строже всякого ревью. Построил двор, на котором холопу негде соврать или украсть. Дескать, иначе барбакан за полдня не построишь.
У нас в конторе такой зазор тоже есть, и мы даже знаем, кто его оставил.
Держим мы два рода счетов: обычные и те, что для гостей, коим вера воспрещает лихву. Роста с них брать нельзя ни при каких обстоятельствах, это не про деньги, это про веру. В реестре торговых групп (реестр у нас MT5) заведены они одинаково, и вся разница в приписке из одной буквы. Приписка эта «S», от слова swap, сиречь рост. И означает она те счета, на которых роста как раз НЕТ (в обиходе swap free). Выдумка не наша, так живёт всякий, кто сидит на MT5.
Кто видел реестр впервые, читал приписку наоборот. Кто сидел на нём третий год, всё равно останавливался и проверял. Переименовать нельзя, за приписку держатся цепи, о которых мы знаем не всё. Ровно как за ворот в подвале.
Трогать её мы не стали, велели брату Клавдию Кодовскому написать испытания. Теперь всякий раз, как в реестр добавляют новую пачку групп, они спрашивают одно: не возьмут ли с гостя рост, которого с него брать нельзя. Вопрос не в том, верно ли названо. Вопрос в том, что станется с живым человеком, если названо неверно.
Седьмое правило Уложения, только исполненное машиной и потому исполняемое всегда, а не когда у кого-то дошли руки.
Гонцы ныне дёшевы, можно и по двое посылать, дабы один за другим проверял. Вот только двое одинаковых гонцов и ошибаются одинаково, так что двор для них строить всё равно мне. Зато бегают, а не котят курящих рисуют, и на том спасибо.
Процесс сейчас такой:
cdk diffперед каждым деплоем, деплой только конкретного стека, никакогоdeploy --all. Плюс правило, что сетевое на месте не правится: нужна другая раскладка - переименовываешь construct и получаешь create-before-delete вместо попытки перекроить живое.Честно про предиктив-чеки: на момент инцидента автоматического гейта не было, и это была главная дыра. Причём план ресурсов у нас был - CloudFormation в диффе честно писал
Replacement: True. Просто читал его человек, в конце рабочего дня, глазами, и увидел то, что хотел увидеть. Информация была, гейта не было.Что мы из этого сделали:
cdk diffв CI, вывод грепается на replace/destroy. Есть замена ресурса - пайплайн краснеет и требует явного подтверждения руками. Самое дешёвое из всего списка и ловит ровно наш класс аварий.Termination protection на стеки с состоянием и RemovalPolicy.RETAIN на базы. Это уже не предиктив, а страховка на случай, когда предиктив не сработал.
Разнесли сеть и базу по разным стекам. Радиус поражения стека равен всему его содержимому, и пока база лежала в одном стеке с VPC, любая правка сети была ставкой на данные.
Про линтер отдельно:
cfn-lintпо синтезированному шаблону как раз делает то, о чём вы спрашиваете - проверяет, что ссылки резолвятся и типы сходятся. Вещь полезная, но нашу аварию он бы не поймал: шаблон был идеально валиден. Он просто делал не то.В этом, наверное, и мораль. Линтер ловит невалидное, а больно делает валидное. Поэтому гейт стоит вешать не на вопрос “правильно ли написано”, а на вопрос “что именно при этом будет заменено”.
Точно, про хостинговые читалки я и забыл - там вообще ничего поднимать не надо. Тогда у человека полный набор вариантов на любой вкус, от feedly в один клик до Actions с гитом. Спасибо, ветка получилась полезнее самой статьи.
Feedly, кстати, огонь, сам юзаю
Согласен, так и есть: с сервером, который копит у себя, лимит перестает что-либо значить. Мое замечание работало только потому что исконный спрашиватель писал такое: "Селф-хостинг как-то стрёмно оставлять на две недели." Есть железка или VPS - ваш вариант однозначно лучше, синхронизация прочитанного и regex-фильтры в самодельном скрипте не появятся никогда. Не готовы - остаются хабовые фиды, которые за счет низкого трафика держат окно неделями, или GitHub Actions в роли того же накопителя, только бесплатного и чужого.
Про бесполезность для аналитики полностью подписываюсь (хотя и не потому, что лимиты): там нужны score и время каждого комментария, а в RSS этого нет и быть не должно.
Спасибо, полез проверять и заодно померил, насколько этого хватает. Результат интереснее, чем я ожидал.
Потолок у всех фидов Хабра одинаковый и жесткий - 41 запись. Пагинации нет вообще: ?page=2 и /page2/ отдают тот же ответ байт в байт. А вот глубина этого окна зависит только от того, сколько в фид сыплется:
общая свежая лента - около 4.5 часов новости - около 15 часов top/daily - сутки, top/weekly - неделя, top/monthly - до 20 июля хаб programming - 4 дня хаб cpp - с 24 июля хаб ruby - аж с апреля 2024
Отсюда и ответ на исходный вопрос. Общая лента для двухнедельного отпуска бесполезна, за 4 часа окно уезжает. А вот подписка на конкретные хабы работает как надо, и никакого сервера для этого не надо: узкий хаб держит месяцы, широкий - несколько дней. Плюс top/monthly для общей картины, если не хочется совсем ничего пропустить из громкого.
Так что для чтения RSS явно удобнее моей возни с JSON. JSON остается нужен, только если хочется полную ленту без отбора по хабам и топам.
Но без GHA или своей арендованной железки всё равно не обойтись...
Проверил, любопытно вышло: риск-то как раз не подтверждается. Первые в треде короткие однострочники (меньше 60 знаков, тексты я не хранил, так что мерил длиной) набирают в среднем 4.38 плюса против 3.59 у развернутых, и в минусе оба варианта одинаково редко, около 4%.
А вот в общей массе, не на первой позиции, короткие ощутимо хуже длинных: 38.7% в плюсе против 47.1%. То есть однострочник наказывается везде, кроме одного места - самого начала треда. Похоже, позиция вытягивает даже “Первый комментарий!”, и в этом есть своя жестокая справедливость. Видимо, многие из нас ещё помнят олбанскей.
Один файл, и пусть он копится. Словарь вида id статьи - заголовок, ссылка, дата, и на каждом запуске вы просто дописываете в него то, чего там еще нет.
Отдельные файлы по датам смысла не имеют ровно потому, что вы уже в гите: историю за вас ведет он. Более того, это и есть главный бонус такой схемы - в диффе очередного коммита лежит ровно список того, что появилось с прошлого запуска. Из отпуска можно даже не открывать сам файл, достаточно пролистать коммиты за две недели, каждый со своим списком новинок.
Единственное, что стоит сделать сразу: сортируйте ключи при записи (json.dump с sort_keys=True, indent=2). Иначе питон будет тасовать порядок, и каждый дифф превратится в шрапнельные правки вместо аккуратного списка
Это потому что я пока тут сижу и всем кто мою статью заметил и комментирует в награду лайк отсыпаю :)
У вас тоже всё сломается, и никто не предупредит. API недокументированный, никаких гарантий обратной совместимости у нас с вами нет.
Но без паники! Первая: это не публичное API для сторонних разработчиков, а внутреннее для собственного фронта, и меняется оно тогда, когда переписывают фронт. v2 живет годами, я на него натыкался еще до того, как взялся за статью. Вторая: при переезде на v3 старую версию обычно какое-то время не выключают, потому что на нее завязаны и мобильные приложения, и закешированный у людей фронт.
Практически нужно одно - чтобы поломка была громкой, а не тихой. Я бы сделал, если бы это была не поделка для себя, а кровавый энтерпрайз, проверку, что в ответе действительно есть publicationRefs и он непустой, а если нет - падать с шумом. GitHub Actions на упавший workflow сам пришлет письмо, и вы узнаете о поломке в тот же день, а не через месяц пустого файла. Чинится это потом теми же пятью минутами в девтулзах: открыли ленту, посмотрели, куда фронт ходит теперь, поправили URL.
Проверил на данных - вы правы, и этого фактора в статье нет, спасибо. Сырые цифры по глубине вложенности:
уровень 0 (корневой): 55.6% в плюсе, средний 2.71 уровень 1: 48.9%, 2.03 уровень 2: 43.5%, 1.34 уровень 3: 38.6%, 1.18 уровень 4 и глубже: 33.7%, 0.83
Но тут та же ловушка, что и с временем суток, поэтому сразу проверил на свежих комментариях, моложе трех часов: 5.36 у корневых, 4.29 на первом уровне, 3.47 на втором. Разрыв остается, но заметно ужимается - значит бОльшая часть сырой разницы это опять свежесть и позиция, которые прячутся за глубиной. Ответ по определению приходит позже того, на что отвечает.
Механика, судя по всему, простая: корневой комментарий видят все, кто открыл статью, а ответ на пятом уровне - только те, кто дочитал ветку. Читателей меньше, голосов меньше.
Ссылку из моего прошлого комментария просто вставьте в адресную строку - у ФФ вроде есть встроенный просмотрщик JSON, откроется деревом, с поиском и кнопкой “Необработанные данные”. Меняете page=1 на page=2 и смотрите, что приходит. Девтулз нужен только чтобы подсмотреть незнакомую ручку, а я уже всё спалил.
Про просмотры не соглашусь, тут мухи с котлетами склеились. Просмотры это не "статья остыла", а "статью много читают", и на свежих комментариях это прям видно: среди тех, что написаны в первые три часа, у статей выше медианы по просмотрам средний урожай 8.3 плюса и 78% в плюсе, у статей ниже медианы - 1.4 плюса и 54%. Одинаковая свежесть, разница почти шестикратная. В регрессии то же самое: log(просмотров) даёт +0.165 при t=9.4, и это уже с учётом лага.
Так что правило не "беги от популярных", а "беги от несвежих, беги к популярным". Пятый комментарий под будущим хитом лучше первого под статьёй-невидимкой.
Со всем остальным согласен, и особенно с последним. Скорость против качества это реальный размен, и мои данные его не разрешают: качество комментария я не мерил вообще. Единственный честный выход из него не "печатай быстрее", а "комментируй то, в чём и так разбираешься". Тогда чтение статьи занимает пять минут, а не полчаса, и в первую десятку успеваешь без стрельбы по ногам.
Про "лягушатник" точное наблюдение. Похоже, эта функция отвалилась вместе с обязательным фармом кармы: тренироваться теперь негде, а сразу писать статью страшно. Ну мне, например, после возврата, страшно было...
Дык, GitHub Actions - халява же. Репа со скриптом, workflow по расписанию (on: schedule, cron), скрипт складывает свежие id в JSON и коммитит его обратно в репу. Из отпуска открываете файл прямо в вебе с телефона, когда сеть появится. Для публичного репозитория это бесплатно, а лимитов хватает с запасом: пара минут раз в день.
Один попадос есть: GitHub отключает scheduled workflows в репке, где 60 дней не было активности. Но раз наш workflow сам коммитит результат, активность есть каждый день, и отключать его не за что.
Я часто так делаю для целей самообновляющихся файликов в вебе, тащемта
Взаимосвязь не учитывал, но ваш вопрос заставил пойти и посчитать. Смотрел пары “автор статьи - комментатор”, которые за неделю встретились больше одного раза.
Таких пар 11 из 2481, это 40 комментариев из 4399, меньше процента. И живут они хуже среднего: в плюсе 40% против 46.4%, средний score 0.75 против 1.84. Постоянных групп поддержки, которые ходят за автором из треда в тред, в недельном срезе просто нет в товарных количествах.
Две честные оговорки. Голоса анонимны, так что кружок, который молча плюсует и не пишет, этим способом не поймать никак. И в моделях контроли на уровне статьи - просмотры, рейтинг, размер треда, - но не поправка на каждую конкретную статью. Специфика жанра “мужики, я 15 лет в айти” учтена ровно настолько, насколько она видна в этих трёх числах.
Нет, как и качество комментариев. Вопрос стоит как: при равном качестве комментариев и одинаково популярном авторе комментария куда выгоднее его поставить? Понятное дело, что если придёт на Хабр Карпатый какой-нибудь, то его любой коммент наберёт лайков. Так же с качеством: коммент может завируситься, например. Но это выбросы.
Я решал задачу для себя. Я - тот, кто я есть и писать комменты умею так, как умею. На это повлиять я не могу. Могу повлиять лишь на то куда и когда писать.
DevTools -> вкладка Network -> фильтр Fetch/XHR, дальше просто листаете ленту и смотрите, что уходит на habr.com/kek/v2/. Всё, что видно на странице, там же и лежит в JSON.
Конкретно под вашу задачу: GET https://habr.com/kek/v2/articles/?fl=ru&hl=ru&sort=date&period=monthly&page=N
В ответе publicationRefs - id, заголовок, время, статистика; pagesCount - сколько всего страниц. Два подводных камня, оба стоили мне вечера: без period прилетает 422, а с дефолтным curl-овским User-Agent Хабр не ругается, а молча отдаёт урезанный ответ - ставьте браузерный UA.
Плохая новость: pagesCount упирается в 50, это 1000 статей за проход, дальше 400. period=monthly сейчас достаёт до 15 июля - ваш отпуск бы закрыл впритык, но окно едет каждый день, так что архив за прошлое уже не собрать.
Хорошая: на будущее это ровно то, что вам нужно. Раз в пару дней дёргать period=weekly (32 страницы), складывать id в локальный файл - и никакого «долистал только до 28-го». Заготовка есть в гисте из статьи, collect_habr.py делает ровно этот постраничный обход с паузой 0.6-0.7 с между запросами: https://gist.github.com/k41n/973a7593738393e21ce7165be2e9c8f3
Четыре минуты и первая позиция - вы только что собрали лучший из возможных раскладов по моей же статье. Осталось выяснить, работает ли она.
Вы очень точно описали ситуацию, только не в том порядке. Сначала идёт экономия на специалистах, отчего хороший (тешу себя мыслью) тимлид и играющий фулстек сеньор садится разбираться с CDK, далее, по классике, эффект Даннинга-Крюгера после пары-тройки успешно сделанных по аналогии несложных изменений и, отсюда же, отсутствие DR стратегии. Знаете во сколько лет я узнал этот термин? Только что, от Вас, спасибо, BTW.
А я ещё притчу знаю, в тему. Про двух дровосеков, которые поспорили: кто больше за день нарубит деревьев. Один не переставая молотил и радовался, когда слышал, что второй каждый час делает паузы на 10 минут. "Устаааал, не вывоооозит, обгоню, надо поднажать!!!", - думал первый. Однако, на подведении итогов второй обошёл почти вдвое. Выяснилось, что 10 минут в час он точил топор.
А вот в коммерции почти всегда "надо поднажать!!!", потому что в отчёте наверх строчка "стабилизировали деплой, перебрали кластер, сделали детерминированной сборку образа" не отвечает на вопрос: "А какие business values вы добавили за месяц работы"?
Про масштаб принимаю, довод честный. На десятке скиллов всё держится в голове, на тысяче не держится.
Смущает меня другое место в вашей формулировке. «Насколько вы будете понимать, как он работает» — при тысяче скиллов вы не понимаете их глазами в любом случае, кто бы их ни писал. Тысячу, написанную руками, вы точно так же не удержите. Систематизация решает навигацию: где лежит, за что отвечает, кто с кем связан. А вот вопрос «делает ли оно то, что я думаю» она не закрывает, и чем больше скиллов, тем сильнее эти две задачи расходятся.
Раз позвали поделиться — вот наш способ, он глупый и рабочий. Все скиллы, которыми бойцы в конторе решили поделиться, лежат во внутренней репе, в папочках. Есть скрипт, который перед пушем переделывает оглавление и проставляет ключевики (через запрос к LLM), результат выкладывается в TOC.md. Поэтому я могу спросить агента: «а есть у нас скиллы, чтобы CODEOWNERS заполнить?» — и он найдёт.
Но это ровно навигация и ничего сверх неё. Что скилл после правки стал делать не то, наш TOC не поймает, и мы пока ничем не ловим.
Отсюда встречный вопрос, и он мне правда интересен: а у вас есть регресс на сами скиллы? Когда правите один из тысячи, чем вы ловите, что поведение агента поехало? Вот эту часть я бы прочитал отдельной статьей!
Правило первое в Уложении самое дорогое: «не оставлять в подвалах древних устройств, о которых никто не знает, что они делают. Если разобрать его дорого, разбери его дорого».
Оно и раньше было верным, просто «дорого» означало опытного мужа, полгода его жизни и кладку, вскрытую в шести местах. А такого мужа всегда есть чем занять полезнее. Оттого весна, до которой собирались разобрать, за одиннадцать перестроек так ни разу и не наступила.
К нынешнему лету поменялось вот что. В подвал можно послать гонцов, которым неудобно не бывает. Им всё равно, что вода по щиколотку и что к железной штуке с табличкой не надо подходить. Послать можно десяток разом, и не с наказом «выясни, что там», а велеть пройти по каждой цепи до конца и переписать всё, к чему она привязана. Подъёмник для дров и колокол в часовне нашлись бы не в лето 35-е, а к обеду того же дня.
Вот только гонец, посланный в подвал, это тот же мастер Ортольф. Он точно так же составит устав на девятнадцать понятных строк, испытает его на потешном дворе, доложит «найдено добрым», а на вопрос, подобен ли потешный двор Кривенгарду, ответит, что во всём существенном. Разница ровно одна: он сделает это за час и не устанет.
Оттого мне и близок нынешний граф, дядя мой, Роберт Мартинский, тот самый, единственный, кто вообще попал внутрь. Он ныне держится правила такого, что из терема не выходит и работу смердов своих не проверяет вовсе. Доверия тут никакого, просто он обвесил их испытаниями строже всякого ревью. Построил двор, на котором холопу негде соврать или украсть. Дескать, иначе барбакан за полдня не построишь.
У нас в конторе такой зазор тоже есть, и мы даже знаем, кто его оставил.
Держим мы два рода счетов: обычные и те, что для гостей, коим вера воспрещает лихву. Роста с них брать нельзя ни при каких обстоятельствах, это не про деньги, это про веру. В реестре торговых групп (реестр у нас MT5) заведены они одинаково, и вся разница в приписке из одной буквы. Приписка эта «S», от слова swap, сиречь рост. И означает она те счета, на которых роста как раз НЕТ (в обиходе swap free). Выдумка не наша, так живёт всякий, кто сидит на MT5.
Кто видел реестр впервые, читал приписку наоборот. Кто сидел на нём третий год, всё равно останавливался и проверял. Переименовать нельзя, за приписку держатся цепи, о которых мы знаем не всё. Ровно как за ворот в подвале.
Трогать её мы не стали, велели брату Клавдию Кодовскому написать испытания. Теперь всякий раз, как в реестр добавляют новую пачку групп, они спрашивают одно: не возьмут ли с гостя рост, которого с него брать нельзя. Вопрос не в том, верно ли названо. Вопрос в том, что станется с живым человеком, если названо неверно.
Седьмое правило Уложения, только исполненное машиной и потому исполняемое всегда, а не когда у кого-то дошли руки.
Гонцы ныне дёшевы, можно и по двое посылать, дабы один за другим проверял. Вот только двое одинаковых гонцов и ошибаются одинаково, так что двор для них строить всё равно мне. Зато бегают, а не котят курящих рисуют, и на том спасибо.