Как стать автором

7 метрик, которых не хватало моему AI‑хуманизатору. Спасибо Хабровской модерации

Я делаю open-source хуманизатор для русского AI-текста. 27 апреля Хабр забанил мою же статью про этот хуманизатор как AI-генерацию.

Хронология. Я отправил материал про русские AI-паттерны на Хабр. Перед отправкой прогнал черновик через собственный скилл-хуманизатор, нашёл у себя слово «являются» в разделе про слово «являются», переписал, упомянул это в постскриптуме. Через несколько дней пришёл ответ от автомодератора:

К сожалению, данная публикация не сможет пройти модерацию, поскольку большая часть текста с высокой вероятностью создана с помощью генеративной модели ИИ.

Перечитал три раза. Статья про маркеры AI заблокирована как AI. Хуманизатор, через который я её только что прогнал, не сработал. Это не баг. Это его слепое пятно, о котором я узнал только в момент бана.

Возникает разумный вопрос, что вообще делает мой скилл, если не вытягивает текст, который сам про чистку от AI-маркеров. Полез разбираться. Из этого вылезло несколько вещей, которые до бана были мне самому непонятны, и я думаю, что они могут быть полезны любому, кто работает с русским контентом и думает про автоматическую детекцию.

Реализация экранной клавиатуры на C# с использованием GDI+.

В статье рассказано, как создать пользовательский отрисованный элемент управления аналогичный встроенной клавиатуре Windows, но с более гибкими настройками.

Привет! Меня зовут Даниил Ткаченко, я веб‑разработчик в ИТ‑компании «Активика». В статье я поделюсь опытом развёртывания Sentry self‑hosted для высоконагруженного проекта. Несмотря на обилие материалов по SaaS‑версии, актуальных гайдов по self‑hosted‑установке почти нет — особенно с учётом современных требований к производительности и отказоустойчивости.

Мы столкнулись с рядом проблем: нестабильностью на базовом хостинге, отсутствием перехвата HTTP‑ошибок и быстрым заполнением диска. Под катом разберу каждую проблему, покажу код решений и дам рекомендации для тех, кто планирует развернуть Sentry самостоятельно.

Статья будет полезна разработчикам и DevOps‑инженерам без опыта работы с self‑hosted Sentry.

Три года я делал браузерную игру, в которой игроки управляли настоящими RC‑машинками через браузер. В итоге, у меня получилось потратить 2млн рублей и получить огромный опыт...

Клиент пришёл с простой задачей: заказы с сайта на Tilda должны автоматически попадать в СБИС Presto. Казалось бы, популярные инструменты — должно быть готовое решение. Его не оказалось.

Написали свой сервис месяц в продакшене, всё работает. Рассказываем как — с кодом, граблями и объяснением неочевидных мест в документации СБИС.

Стек: Python, FastAPI, Pydantic, httpx, cachetools.

Как усилить процесс разработки с применением ИИ на базе Obsidian и Claude. Не теряем контекст в крупных проектах, тратим меньше токенов на задачи.

Практический туториал. Как организовать базу знаний для проекта, как настроить нужные плагины и как конфигурировать Obsidian с Claude.

Создаём крупные проекты с ИИ в команде с другими разработчиками без боли.

MCP-серверы не умеют в авторизацию, n8n не умеет в per-user токены, а OAuth-клиенты говорят на разных диалектах. Рассказываем, как один Auth Proxy перед FastMCP Gateway закрыл все три проблемы — и почему в итоге бот переехал на LangGraph

Понадобилась мне семантика - не в смысле «один раз глянуть Wordstat в браузере», а программно, чтобы прогонять по 50-100 фраз в день и складывать результаты в свою базу. Контекст: веду контент-маркетинг для агентства разработки чат-ботов BotKraft, статьи под Яндекс Нейро. Веб-Wordstat для такого объёма не вариант - копировать вручную из таблички полдня. Direct API - слишком дорогой вход: нужен рекламный аккаунт, отдельный OAuth, у меня этого не было и заводить ради одного метода не хотелось.

Случайно полез в новые сервисы Yandex Cloud AI Studio (там сейчас живёт YandexGPT) и обнаружил, что Wordstat теперь есть в Search API v2 - отдельным сервисом без зависимости от Direct. Доступ - обычный API-ключ из AI Studio, тот же что и для YandexGPT. По сути в один клик получаешь ещё и доступ к семантике.

Подключал, по дороге собрал коллекцию граблей. Этим и поделюсь.

В последнее время у меня ощущение, что на рынке разработки что-то «сломалось».

Нанимают как будто бы только сеньоров. Требования на сеньора ниже, чем на джуна, с учетом конкуренции. Из-за этого опыт начинают крутить почти все новички: те, кто не делает этого сразу, часто не находят работу и в итоге приходят к тому же.

Можно представить, что это новая система сдержек и противовесов, где все врут, знают об этом, и в итоге оцениваются реальные знания. Но нет: оценивается только умение себя подать, подстроиться под все искусственные барьеры, не связанные с реальностью.

Моя интуиция подсказывает, что есть ребята с небольшим опытом, но умеющие писать код и справляться с большинством задач.

Речь пойдёт о разработке системы алгоритмической торговли с использованием обучения с подкреплением. Пройдём путь от идеи до работающей системы с разумной детализацией. Расскажу про свои ошибки: радовался single-seed успехам, верил Claude Code на слово, считал лучшую модель годной для production, в то время как на самом деле это был верхний квартиль сид-шума. Внутри Mixture-of-Experts по рыночным режимам, shadow-routing на rolling Sharpe, hybrid expert-swap, методология валидации, а также небольшой список всего того, что не сработало. Подойдёт в качестве инструкция для ai-агента, чтобы повторить опыт и понять почему работает.

Знакомая ситуация: бот вроде бы работает. Люди тыкают кнопки, получают ответы, всё хорошо. Но иногда случается странное.

Прилетает сообщение в поддержку: «Бот не отвечает». Или ещё хуже: «Бот выдал какую‑то ошибку и всё». Вы бежите к терминалу, поднимаете историю... и ничего не видите. Ни ошибки, ни стека, ни даже намёка на то, где именно всё сломалось.

Вы просто слепы.

Без нормальных логов вы не понимаете ровно ничего: обработчик не сработал, API молчит, база данных упала или вы просто забыли зарегистрировать хендлер. Спойлер: я через это проходил, и не раз.

Объектный построитель SQL-запросов без ORM и моделей. Позволяет писать сложные SQL-запросы в виде цепочек Python-методов (table[‘person’].filter(…).join(…).get()) и получать результат в виде списка словарей. Под капотом — параметризованные запросы для защиты от инъекций, продуманная система кеширования с инвалидацией по таблицам (in-memory и Redis), поддержка синхронного и асинхронного кода из коробки. Для тех случаев, когда ORM избыточна, а сырой SQL небезопасен.

Дисклеймер: Данный материал в большей степени подходит тем, кто может отнести свой склад ума к «техническому».

Привет! Твой стартовый персонаж не появился на свет с выигрышной колодой, но есть ли у него шансы на лучшую жизнь?

Постараюсь быть краток. В двух словах об авторе: 25 лет, студент 4го курса электротехнического факультета, с претензией на высший балл по выпуску, AI инженер в настоящем — менеджер в прошлом.

Но эта статья не столько о чем‑то позитивном, сколько скорее о попытке закрыть кейс «человека без ничего». В детстве я занимался большим теннисом и мой тренер заложил в меня очень полезную мысль «Опередить соперника в состязании на один выигранный мяч, это не победа, победа это опередить соперника на десять мячей» — именно с этой мыслью в голове я подошел к этой статье. На хабре можно найти сколько угодно статей о технике, науке, программировании. И ни одной, я повторюсь — ни одной, о том, что же может считаться правильным, не для государства или определенной индустрии, а для самого человека. Что я имею ввиду?

Давай представим что ты родился в деревне, и выяснилось что ты гений. Однако на дворе 2026й год и ты бегаешь за водой на колонку, а покинуть дом не можешь потому что присматриваешь не дай бог за родственником инвалидом. Что же делать тогда? Ну допустим ты выучился на ракетостроение из дому, найдя некоторую образовательную программу от MIT, но что делать дальше? Ты в деревне и не можешь ее покинуть, ракетостроителем работать ты не сможешь, из доступных вариантов — работа в колхозе. Но ты точно знаешь что ты способен на большее, что же делать в таком случае?

Хабр, привет!

Если вы скажете знакомому разработчику (особенно фронтэндеру или Python-разработчику), что хотите выучить плюсы с нуля, скорее всего на вас посмотрят с сочувствием. В IT-сообществе укоренилось мнение, что плюсы - это темный лес с какими-то непонятными указателями, ручным управлением памятью и прочими прелестями языка. В целом они правы, кроме одного момента. Это было десятки лет назад. Начиная с С++11, а уж тем более в эпоху С++20, язык стал другим. Разработчику больше не нужно следить за жизнью переменной, выделенной через new, бояться обратиться за пределы массива, жонглировать сырыми указателями. На многое появились удобные обертки, которые упрощают жизнь разработчику. А некоторые из них еще и никак не влияют на производительность. Если вы студент, человек из другой сферы или разработчик, который хочет потрогать новый инструмент - не бойтесь. Главное - правильно начать.

Cursor или его аналоги, здорово облегчают написание кода, когда речь идет о каких‑то не очень больших проектах. Но стоит попробовать применить их к серьезному, сложному проекту, состоящему из нескольких репозиториев, и тут же сталкиваешься с тем, что эти «чудеса» оборачиваются просто огромными счетами за токены. Я в этой статье поделюсь, как мне удалось перестать впустую сжигать миллионы токенов. Для этого пришлось собрать и запустить три MCP‑сервера по протоколу Model Context Protocol, что позволило сэкономить до 90% бюджета, при этом совершенно не потеряв в эффективности модели при работе с кодом.

В программировании частая задача это работа с последовательными элементами. В этой, порой непростой задаче, нам часто помогают вектора. Вектора бывают самыми разными от queue и set до unordered_map и обычных массивов. Все они позволяют работать с данными по разному, где то быстрее вставка, где то быстрее доступ, но все они выполняют одну важную задачу это хранение данных.

И не смотря на их всеобъемлющую вариативность, в жизни встречаются ситуации когда один вектор не может решить задачу. Точнее может, но через костыли...

О чем я?

В 2026 для VPN нужна маскировка. А нет никакой лучшей маскировки, чем уже работающий легитимный сервис. Силами NGINX-streams и HTTP2 это сделать довольно легко.

Когда сервис поднимается по 8-15 минут, команда почти всегда начинает крутить одни и те же ручки: увеличивает initialDelaySeconds, добавляет startupProbe, поднимает progressDeadlineSeconds, иногда переносит миграцию в initContainer и считает, что стало «по-кубернетесному». Обычно это не лечение. Это способ аккуратнее завернуть проблему в YAML. Если тяжёлая миграция живёт внутри старта приложения, вы связали жизненный цикл Pod, rollout Deployment и поведение базы в один общий узел. А такие узлы в проде рвутся не там, где их ждут.

Обобщение знаний и опыта для базового использования Docker, которые накопились за время использования.

Представьте далекое будущее: вы на лунной базе. К вам подходит человек в скафандре. Кто он? Астронавт NASA? Космонавт из Роскосмоса? Частный турист SpaceX? Откуда он? Какой у него опыт? Может он вообще марсианин?

Вот с этой мысли всё и началось. Я хотел немного систематизировать ситуацию и придумать красивые нашивки-шевроны, которые могли ответить на эти вопросы с первого взгляда. А в итоге получилась целая система.