Pull to refresh
64K+
40
Шубин Данила@ShyDamn

FullStack-разработчик, CEO Synapsea Agency

137,1
Rating
78
Subscribers
Send message

Поисковики на это не опираются. В сайтах зашит 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, а в целом возможно расскажу разные способы, как обезопасить свой трафик :)

Я выбрал AGH потому что он уже был установлен на моём роутере как пакет OpenWrt, и я не хотел поднимать отдельный PI. И лично для меня в AGH чуть удобнее веб-интерфейс, чем у Pi.

Что касается DoT/DoH, это действительно следующий уровень защиты, я уже отвечал на этот вопрос ранее. Я намеренно не стал углубляться в это в статье, так как она и так довольно объёмная. Полный разбор блокировки DoH - это тема для отдельной статьи, которую я, возможно, напишу позже.

С любого Android/Google TV полностью отключить сбор данных не выйдет, ведь часть информации собирается системными службами даже без дополнительных настроек.

Чтобы свести сбор данных к минимуму, нужно сделать три вещи:

  1. В настройках конфиденциальности отключить «Персонализированный контент» и «Релевантная реклама».

  2. В общих настройках Android TV выключить рекомендации и «использование данных».

  3. Заблокировать ряд доменов через DNS (как в первом комменте с uBlock пример).

Если телевизор нужен для всей семьи, особенно для Кинопоиска и ВК Видео, проще использовать отдельное устройство. Это может быть Apple TV или тот же Mini-PC с Kodi (как советовал @numark ниже), так как вы сможете целиком контролировать установки

Hijack работает только с обычным DNS. DoT и DoH нужно блокировать отдельно.

DoT блокируется на 853 порту файрвола, так как по нему почти ничего другого не передается.

DoH сложнее, потому что использует 443 порт и не отличается от обычного HTTPS. Чтобы его обойти, можно блокировать известные DoH-серверы, например, dns.google или cloudflare-dns.com. AdGuard Home делает это с помощью списка «DNS-серверы» в фильтрах. Без знания IP-адреса DoH-сервер не будет работать.

Для максимальной защиты можно блокировать 443 порт на известных IP-адресах DoH-серверов, но это скорее погоня, так как их IP-адреса постоянно меняются.

Круто сделал, попробую себе тоже прикрутить uBlock. Сравню результаты и отпишу :)

1
23 ...

Information

Rating
38-th
Location
Воронеж, Воронежская обл., Россия
Date of birth
Registered
Activity

Specialization

Фулстек разработчик, Веб-разработчик
Старший
From 250,000 ₽
Python
PHP
MySQL
REST
TypeScript
React
Next.js
NestJS
Vue.js
Node.js