Поисковики на это не опираются. В сайтах зашит robots.txt - по сути это разрешение от сайта, что и в каком объёме индексировать.И поисковик не замещает источник, тк он отдаёт сниппет со ссылкой и возвращает читателя на площадку. В той же 1335.1 ключевое ограничение звучит как «необоснованное ущемление интересов изготовителя базы», а поисковик их наоборот обслуживает. Плюс у поисковиков есть отдельный статус информационного посредника (1253.1 ГК) со своим режимом ответственности, а это вообще другая правовая конструкция, чем извлечение материалов пользователем.
Вашу гипотезу проверил. Длинные статьи (3000+ слов) в будни дают медианный рейтинг 10, в выходные 9, разница незначима (p=0.65). Короткие: 6 против 4, тоже незначимо. Утро против вечера также, ни для длинных, ни для коротких значимой разницы нет. длина работает одинаково во все дни. Интересно то, что длинные стабильно берут выше коротких (8–11 против 3–7), и это держится и в понедельник, и в субботу. То есть взаимодействия день x длина нет, есть просто эффект длины сам по себе.
Также воскресенье проваливает всё подряд независимо от длины (рейтинг 3–4), а суббота даёт лучший охват, но скорее всего это просто потому что публикаций в этот день вдвое меньше и конкуренция за ленту ниже.
Расширение не обходит никакой защиты. Оно читает открытые статьи через сессию самого пользователя, держит полторы секунды между запросами и замолкает на три минуты по первому же 429. Сохраняет локально, с указанием автора и ссылкой на оригинал, никуда не публикует.
По ГК на личное использование обнародованного есть 1273 и 1335.1, а соглашение Хабра само делает исключение для личного некоммерческого сохранения с сохранением атрибуции. Так что герру майору показывать особо нечего :)
По цифрам соглашусь, как отдельный ESP оно зарплату не отбивает :) И не задумывалось так. Это часть связки своих сервисов, которой пользуемся сами и предлагаем клиентам с данными в РФ. Экономика не от объёма писем, а от достроенного куска своего продукта.
Мы просто сделали сервис полностью попадающий под 152-ФЗ и данные в РФ. Тк согласно текущему законодательству сервисы типа Postmark и подобных, которые не из РФ, компаниям использовать нельзя
Да, вы правы, но я в статью это решил не добавлять, тк раздел был про записи в своей зоне, а PTR ставится на стороне провайдера IP. Но по важности пункт того же порядка, соглашусь. У нас он проставлен и совпадает с HELO.
Формулировка немного неточная. DMARC не третья проверка в ряд, а политика поверх SPF и DKIM: хватает одного выровненного механизма. По Mail.ru и Яндексу логика та же, они отличаются только весами.
Спасибо, замечания справедливые. С колонками я действительно накосячил: сравнил разные Y. Перепроверил на одинаковом рейтинге - знаки всё равно меняются, так что вывод остался тем же, но показать это сразу было бы честнее.
С log тоже верно: я обрезал отрицательные рейтинги до нуля. Это не лучшая обработка данных. Если использовать рейтинг как есть, качество модели было бы даже ниже.
На главный вывод это не влияет: форма статьи объясняет очень мало. Но оформить и объяснить методику стоило аккуратнее. Учту на будущее.
Вы правы, на обложке визуализация того, что написано в тексте, а не реальный scatter по датасету. Я чуть позже сделаю график и пришлю вам сюда, чтобы вы могли ознакомиться :)
Про разные скорости вы точно сформулировали то, что у меня в статье осталось между строк: рейтинг набирается в первые сутки-двое и потом почти замирает, а охват копится месяцами через поиск и внешние ссылки. Это две отдельные метрики с разной динамикой, и оптимизируются они тоже по-разному: рейтинг через форму и первое впечатление на день публикации, охват же через тему, которую ищут годами. Ваша "FullHD vs 4K с integer scaling" и "освещённость рабочего места" - это то, что будет тянуть трафик из поиска ещё долго, даже с рейтингом 3 и 12.
Про формат не обязательно поздно, я не знаю точно, реагирует ли алгоритм на смену метки уже опубликованного материала, но в интерфейсе она меняется. Если поменяете "Туториал" на "Кейс", то интересно будет посмотреть через недельку, сдвинется ли что-то. Если да, то это будет полезное наблюдение для следующей итерации моего разбора.
Я согласен, что в интерфейсе нет порога >=7, и через неделю статью с рейтингом 7 почти не видно, вы правы. Я имел в виду, что нужно понимать, чего ожидать сразу после публикации. Если у статьи через сутки 7 плюсов, автор может посчитать это провалом, хотя это средний показатель для этой площадки. А вот то, как долго статья будет находиться в поиске, - это уже другой показатель, и там действительно нужно 10 плюсов.
Заглянул в ваши статьи. По охлаждению Mini-PC хабы у вас как раз сильные - DIY и Читальный зал, у них медианный рейтинг 18 и 14, то есть с хабами всё правильно,И 9 рейтинга при них уже нижняя часть распределения, а не провал. А вот у "3D-игр на слабой видеокарте" стоит формат "Туториал", и это как раз тот единственный формат, который по моим данным на личных блогах значимо проседает, там медиана 4 против 7 у неуказанного, p=0.018. Кейс или просто снять формат, по идее, должно тянуть вверх. Но это только гипотиза :)
free -h в BusyBox выводит в килобайтах без суффикса, то есть 496724 это 496 МБ, а не 500 КБ :)
Про подкачку вы правы, для самого журнала полгигабайта хватает с запасом (даже за пять суток набралось 337 тысяч записей, порядка 100 МБ, и AGH держит из этого почти 30 МБ в памяти по size_memory). Свап понадобился не для журнала, а для установки пакетов через apk: earlyoom при нехватке памяти во время apk install убивал сам установщик. Полгигабайта свапа вставил именно чтобы это нормально работало, а не под нужды AdGuard.
Логи добавлю в следующем обновлении, а насчёт описания картинок спасибо, исправлю это
Сохранение присутствует, надо включить в настройках
В настройках можно включить сохранение по типу и по хабу
Вот это очень полезно, спасибо!
Поисковики на это не опираются. В сайтах зашит robots.txt - по сути это разрешение от сайта, что и в каком объёме индексировать.И поисковик не замещает источник, тк он отдаёт сниппет со ссылкой и возвращает читателя на площадку. В той же 1335.1 ключевое ограничение звучит как «необоснованное ущемление интересов изготовителя базы», а поисковик их наоборот обслуживает. Плюс у поисковиков есть отдельный статус информационного посредника (1253.1 ГК) со своим режимом ответственности, а это вообще другая правовая конструкция, чем извлечение материалов пользователем.
Прикольно сделали, спасибо, что поделились
Интересная идея, спасибо, подумаю над этим на досуге :)
Вашу гипотезу проверил. Длинные статьи (3000+ слов) в будни дают медианный рейтинг 10, в выходные 9, разница незначима (p=0.65). Короткие: 6 против 4, тоже незначимо. Утро против вечера также, ни для длинных, ни для коротких значимой разницы нет. длина работает одинаково во все дни. Интересно то, что длинные стабильно берут выше коротких (8–11 против 3–7), и это держится и в понедельник, и в субботу. То есть взаимодействия день x длина нет, есть просто эффект длины сам по себе.
Также воскресенье проваливает всё подряд независимо от длины (рейтинг 3–4), а суббота даёт лучший охват, но скорее всего это просто потому что публикаций в этот день вдвое меньше и конкуренция за ленту ниже.
Расширение не обходит никакой защиты. Оно читает открытые статьи через сессию самого пользователя, держит полторы секунды между запросами и замолкает на три минуты по первому же 429. Сохраняет локально, с указанием автора и ссылкой на оригинал, никуда не публикует.
По ГК на личное использование обнародованного есть 1273 и 1335.1, а соглашение Хабра само делает исключение для личного некоммерческого сохранения с сохранением атрибуции. Так что герру майору показывать особо нечего :)
По цифрам соглашусь, как отдельный ESP оно зарплату не отбивает :)
И не задумывалось так. Это часть связки своих сервисов, которой пользуемся сами и предлагаем клиентам с данными в РФ. Экономика не от объёма писем, а от достроенного куска своего продукта.
Мы просто сделали сервис полностью попадающий под 152-ФЗ и данные в РФ. Тк согласно текущему законодательству сервисы типа Postmark и подобных, которые не из РФ, компаниям использовать нельзя
Да, вы правы, но я в статью это решил не добавлять, тк раздел был про записи в своей зоне, а PTR ставится на стороне провайдера IP. Но по важности пункт того же порядка, соглашусь. У нас он проставлен и совпадает с HELO.
Формулировка немного неточная. DMARC не третья проверка в ряд, а политика поверх SPF и DKIM: хватает одного выровненного механизма. По Mail.ru и Яндексу логика та же, они отличаются только весами.
Спасибо, замечания справедливые. С колонками я действительно накосячил: сравнил разные Y. Перепроверил на одинаковом рейтинге - знаки всё равно меняются, так что вывод остался тем же, но показать это сразу было бы честнее.
С
logтоже верно: я обрезал отрицательные рейтинги до нуля. Это не лучшая обработка данных. Если использовать рейтинг как есть, качество модели было бы даже ниже.На главный вывод это не влияет: форма статьи объясняет очень мало. Но оформить и объяснить методику стоило аккуратнее. Учту на будущее.
Вы правы, на обложке визуализация того, что написано в тексте, а не реальный scatter по датасету. Я чуть позже сделаю график и пришлю вам сюда, чтобы вы могли ознакомиться :)
Про разные скорости вы точно сформулировали то, что у меня в статье осталось между строк: рейтинг набирается в первые сутки-двое и потом почти замирает, а охват копится месяцами через поиск и внешние ссылки. Это две отдельные метрики с разной динамикой, и оптимизируются они тоже по-разному: рейтинг через форму и первое впечатление на день публикации, охват же через тему, которую ищут годами. Ваша "FullHD vs 4K с integer scaling" и "освещённость рабочего места" - это то, что будет тянуть трафик из поиска ещё долго, даже с рейтингом 3 и 12.
Про формат не обязательно поздно, я не знаю точно, реагирует ли алгоритм на смену метки уже опубликованного материала, но в интерфейсе она меняется. Если поменяете "Туториал" на "Кейс", то интересно будет посмотреть через недельку, сдвинется ли что-то. Если да, то это будет полезное наблюдение для следующей итерации моего разбора.
Я согласен, что в интерфейсе нет порога >=7, и через неделю статью с рейтингом 7 почти не видно, вы правы. Я имел в виду, что нужно понимать, чего ожидать сразу после публикации. Если у статьи через сутки 7 плюсов, автор может посчитать это провалом, хотя это средний показатель для этой площадки. А вот то, как долго статья будет находиться в поиске, - это уже другой показатель, и там действительно нужно 10 плюсов.
Заглянул в ваши статьи. По охлаждению Mini-PC хабы у вас как раз сильные - DIY и Читальный зал, у них медианный рейтинг 18 и 14, то есть с хабами всё правильно,И 9 рейтинга при них уже нижняя часть распределения, а не провал. А вот у "3D-игр на слабой видеокарте" стоит формат "Туториал", и это как раз тот единственный формат, который по моим данным на личных блогах значимо проседает, там медиана 4 против 7 у неуказанного, p=0.018. Кейс или просто снять формат, по идее, должно тянуть вверх. Но это только гипотиза :)
Самый простой вариант - вынести AdGuard Home с роутера на любое устройство в сети (NAS, мини-ПК, старый ноутбук) и указать его как DNS в DHCP
free -hв BusyBox выводит в килобайтах без суффикса, то есть 496724 это 496 МБ, а не 500 КБ :)Про подкачку вы правы, для самого журнала полгигабайта хватает с запасом (даже за пять суток набралось 337 тысяч записей, порядка 100 МБ, и AGH держит из этого почти 30 МБ в памяти по
size_memory). Свап понадобился не для журнала, а для установки пакетов черезapk:earlyoomпри нехватке памяти во времяapk installубивал сам установщик. Полгигабайта свапа вставил именно чтобы это нормально работало, а не под нужды AdGuard.Не только ради этого XD, а в целом возможно расскажу разные способы, как обезопасить свой трафик :)