Всем привет. Начал писать открытую книгу про архитектуру безопасных AI-агентов.
Делаю не обзор фреймворков и не коллекцию «магических демо», а практический инженерный reference: control plane, policy boundaries, tool gateway, memory, observability, evals, approval flows, governance и production-подход к агентным системам.
Всем привет! Меня зовут Александр Дориф, я химик, молекулярный генетик и сисадмин-инфраструктурщик в компании WebHostMost, многие знают меня по нику Father Nurgle.
Итак, на дворе осень 2022 года, я, на тот момент аспирант, разрабатываю способы диагностики болезней экспансии коротких повторов (хорея Хантингтона, синдром ломкой Х хромосомы...) или с изменением количества локусов в геноме (инсерции/делеции, анеуплоидии). Я активно использую капиллярный электрофорез на ABI 3500 Dx и фрагментный анализ с помощью GeneMapper 5. И это стало проблемой. Компов в лабе мало, денег тоже, лицензия GeneMapper одна (а дополнительная стоит больше 10к$), комп с GeneMapper часто занят, софт сам по себе прибит к венде и БД Oracle. А сам я работаю на ноуте, устаревшем ещё в конце нулевых. Да, есть NCBI OSIRIS, но для него нужен Wine, а это лишний слой абстракции, да и интерфейс у него переусложнён на мой взгляд, Fragman не поддерживал импорт файлов с 3500, fatools не развивались и автор не отвечал на сообщения.
Так я решил писать FragalyseQt. Я изначально видел его как кроссплатформенный и свободный софт, поэтому выбрал за основу Python (для него есть много полезного типа BioPython) и Qt для интерфейса. Учитывая то, что у меня не было опыта написания десктопных приложений, несколько дней я изучал мануалы, после чего тёмным вечером 6 октября 2022 выпустил самую первую версию FragalyseQt с номером 0.1 и кодовым именем «Huntington». Это была смотрелка файлов FSA, умеющая селективно скрывать выбранные каналы флуоресценции и экспортировать данные внутреннего анализа (для ABI 3500 и SeqStudio) в CSV.
В версии 0.2 «Friedreich», добавилась возможность независимого от прибора поиска и базового анализа пиков на электрофореграммах, я познакомился со SciPy и табличными возможностями Qt.
Версия 0.3 «DiGeorge» принесла возможность правки базовой линии и тонкой настройки поиска пиков. И... Я упёрся в фундаментальную проблему: определение размера фрагментов на электрофореграммах требовало теории приблизительных вычислений, которую нам в своё время не давали, давая математику по остаточному принципу. Без сайзинга, FragalyseQt будет всего лишь смотрелкой. Я начал ботать матан. Мозги плавились, времени не хватало, к аспирантуре добавились заботы о дочке, но я учил. Здесь же случилось знакомство с реальностью: не каждая декларация «мы поддерживаем формат ABIF» значит «мы поддерживаем ПОЛНУЮ спецификацию ABIF». Также пришлось столкнуться с древними вариантами ABIF, полученными до его стандартизации. Была работа в Okteta, написание парсеров, FragalaseQt стал читать и старый ABIF, и его криминалистическое подмножество — HID.
1 сентября 2024 вышла FragalyseQt 0.4 «Jeffreys» с сайзингом пиков методами степенных сплайнов, взвешенных степенных сплайнов и МНК. README стал подробнее, стремясь к полноценному мануалу. Позже добавил локальный и глобальный методы Саузерна. Софт стал реально аналитическим, с его помощью была опубликована работа на ESHG 2025 ( https://doi.org/10.13140/RG.2.2.14637.81123 ). Потом развитие опять затянулось — задержки ЗП в начале года по 3-4 месяца не способствовали размышлениям о чём-то, кроме выживания. В сентябре я перешёл в WebHostMost и, внезапно, у меня появились адекватные задачи, время и поддержка коллег. Была переработанна структура для соответствия PEP 517, добавлен гибкий интерфейс и экспериментальная поддержка импорта сырых данных российского Нанофор-05 (формат реверсил).
20 марта 2026 вышла FragalyseQt 0.5 «Southern» с импортом панелей GeneMapper, GeneMarker и NCBI OSIRIS, фильтрацией статтеров, экспортом в CODIS XML. Для скриншота мне было скучно использовать стандартные заглушки для данных (и ясно, что невозможно взять реальные данные дел), поэтому демо сделано как опознание тел после Резни в Зоне Высадки, Исстваан 5.
FragalyseQt 0.5 - экспорт данных после применения панелей в формат CODIS XML: выбираются вкладки с данными для экспорта, назначаются роли в рамках дела (жертва, персонал, подозреваемый, предполагаемый родитель и т.д.), заполняются данные лаборатории и экспортируются. Экспортированные данные могут быть внесены в совместимую с CODIS систему (например, SmallPond).
Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 80%, 90%, а то и вовсе 100%. И вот тут начинается проблема: зелёные тесты ≠ хорошие тесты.
Проблема в метрике, которой мы все привыкли доверять. Code coverage считает строку протестированной, если она выполнилась во время теста. Всё. Не «поймает ли тест баг в этой строке», не «проверяет ли он правильность результата» — просто выполнилась. Можно написать тест без единого assert, и покрытие вырастет. 500 тестов, 90% coverage, а пользы ноль.
Мутационное тестирование — это совершенно другой путь. В простейшей реализации этот инструмент тупо берёт твой код и намеренно ломает его: меняет > на >=, + на ‑, True на False. Каждая такая поломка — мутант. Если после мутации все тесты по‑прежнему зелёные — значит они ничего не проверяют. Покрытие есть, защиты нет.
Почему это важно именно сейчас?
Потому что нейронка любит зелёненькое. Чем больше зелёных тестов — тем субъективно лучше. 100 тестов внушают больше доверия, чем 10, правда? А внутри там assert response.status_code == 200. assert result is not None. assert len(items) > 0. Тест проверяет, что функция вернула хоть что‑то — и радостно зеленеет. Поменяй логику условия, перепутай знак, сломай граничный случай — тест всё равно зелёный. Потому что он проверяет не правильность, а наличие.
Мутационное тестирование — единственный автоматический способ это поймать. Метрика называется mutation score: процент убитых мутантов. 60% — плохо. 90%+ — тесты реально что‑то защищают.
Кое‑какие инструменты для такого тестирования уже есть: mutmut и cosmic‑ray для Python, Stryker для JS/TS, PIT для Java. Медленно? Да, значительно медленнее обычного тест‑рана. Но запускать его не нужно на каждый коммит — достаточно на PR в критические модули.
Но есть нюансы. А где их нет, правда?
Первый: мутации рандомные. Замена > на >= — это не баг, который кто‑то реально допустит. Это синтетическая поломка. Половина мутантов генерирует код, который в реальности никогда не появится. Ты тратишь время на убийство мутантов, которые не имеют отношения к настоящим ошибкам. Это как тестировать замок, ковыряя его вилкой — формально проверка, по факту мимо.
Второй — ещё хуже. Чтобы убить мутанта, тест должен зафиксировать конкретное поведение. Каждую ветку, каждое значение, каждый edge case. Доведи mutation score до 100% — и ты прибил гвоздями каждую строчку кода. Буквально. Теперь попробуй отрефакторить. Переименовал внутренний метод — 40 тестов красные. Поменял порядок полей в ответе — ещё 20. Тесты превращаются из страховки в кандалы: код работает правильно, но тесты падают, потому что они проверяют не поведение, а реализацию.
Это реально ловушка. Слишком гонишься за mutation score — получаешь хрупкие тесты. Не гонишься — получаешь видимость тестирования.
Перемены — впереди!
И вот тут становится по‑настоящему интересно. Представь, что мутации генерирует не тупой набор правил «замени плюс на минус», а нейронка, которая понимает контекст. Которая знает, какие баги реально встречаются в таком коде. Которая мутирует не синтаксис, а логику: меняет порядок проверок, путает граничные условия, забывает обработать edge case — ровно так, как ошибается человек. Или другая нейронка.
Сейчас есть явный сдвиг в сторону таких инструментов, но всё еще ничего достойного не вышло. Но уже скоро точно появится. И это будет совсем другой уровень. Не «выжили ли тесты после рандомной поломки», а «выжили ли тесты после правдоподобной ошибки».
Парадокс в том, что мутационное тестирование было нишевым инструментом, пока тесты писали люди. Когда тесты пишет нейронка — идея становится обязательной. Правда инструменты пока не успели дозреть.
Один забавный факт привел меня к открытию другого :)
Читал Fluent Python и наткнулся на пример кода, который меня заинтересовал (помимо миллиона других, книга – топ). В главе про конкурентность и работу GIL была константа NUMBERS с необычным значением:
NUMBERS = 5_000_111_000_222_021
Нижние подчеркивания
Если не встречали в работе или документации, то вряд ли знаете (как и я): в числах можно использовать _ для читаемости. Интерпретатор их игнорирует:
>>> x = 1_2
>>> y = 12
>>> x == y
True
>>> x is y
True
Особенно удобно в высокоразрядных числах. Согласитесь 5_000_111_000_222_021 куда проще читать, чем 5000111000222021
Кеш малых чисел
Примеры ниже разбирал на домашнем ноуте с Cpython 3.13.11 и 3.14.3.
Пока игрался, меня заинтересовал один прикол. Я попробовал тот же пример с большими числами:
>>> x = 100_500
>>> y = 100500
>>> x == y
True
>>> x is y
False # Но ведь в примере выше было True..
Почему переменные больше не ссылаются на один объект?
В Cpython есть кеш для маленьких чисел, чтобы частые значения переменных не занимали много памяти и код был отзывчивее.
Ответ на вопрос: «где граница, до которой числа закешированы?» я решил не гуглить, проверил небольшим скриптом:
>>> x = 0
>>> y = 0
>>> for n in range(1000):
... print(f'If {x=} and {y=}, x is y: {x is y}')
... x += 1
... y += 1
# Пропустим часть строк
If x=254 and y=254, x is y: True
If x=255 and y=255, x is y: True
If x=256 and y=256, x is y: True
If x=257 and y=257, x is y: False # Вот и граница
If x=258 and y=258, x is y: False
...
Сначала я сделал эмпирически вывод, что закеширован диапазон 0 – 256. Но после самопроверки с гуглом узнал, что также в амортизированный диапазон входят числа от -5 до -1. Итого : от -5 до 256 включительно.
UPD 15.03.2026. Добрый дядя в комментах принес ссылку на pr в Cpython 3.15, где кеш малых чисел увеличен до 1024 :). Ух, заживем..
Для присвоения переменным чисел вне диапазона, интерпретатор начнет выделять уже раздельные области памяти и is станет возвращать False.
Так то. В оптимизации пригодится вряд ли, но удивить друзей в баре сможете.
Разрабатываете VK Mini Apps и хотите быть уверены, что HTTP-запросы на backend приходят именно из приложения VK, а не откуда угодно? Для этого нужна корректная проверка Init Data.
Наш backend-разработчик @dmvasiliev выложил Open Source-проект, который упрощает эту задачу. Это Python-пакет с готовыми алгоритмами проверки подлинности данных, передаваемых из VK Mini Apps. Он помогает быстро и безопасно настроить авторизацию и аутентификацию на backend-стороне приложения.
Когда мы только начинали работать с VK Mini Apps, информации было немного: редкие кейсы, почти не у кого было спросить совета. За это время мы запустили несколько приложений, разобрались в нюансах платформы и накопили собственную экспертизу. Теперь делимся ею с сообществом через Open Source-проекты и вносим вклад в развитие технологии.
Репозиторий открыт — берите в работу, делитесь постом с коллегами.
А если вам нужен VK, Telegram Mini App или спецпроект на другой платформе — команда Doubletapp поможет пройти путь от идеи до работающего продукта. Примеры наших проектов — на сайте.
В продолжение прошлого поста, собрал новый трек курса из вашей обратной связи. Углубил тему, сделал ориентир на уже более опытных. Если есть куда еще копать - пишите в комментарии.
P.S. Все также бесплатно и таким останется, пока у меня есть деньги на поддержку и развитие ресурса.
Пока статья набирает просмотры, выкатили DCL Evaluator - v1.1.0 с webhook API. Любой LLM pipeline получает криптографическое доказательство каждого решения за 3 строки кода. Tamper-evident. Offline-capable. 🔗 fronesislabs.com ⭐ GitHub
Команда разработчиков языка программирования Python визуализировала изменение кодовой базы интерпретатора CPython в привязке к основным событиям, произошедшим за 36 лет существования проекта. За последние 10 лет объём кода на языках Python и Си в CPython практически удвоился. Для подсчёта числа строк кода использовалась утилита cloc.
44 собеса за месяца — Жив ли рынок QA/AQA на самом деле?
Календарь AQA собесов за декабрь
Последний год в IT регулярно обсуждают одну и ту же тему — рынок стал сложнее. Вакансий меньше, требования выросли, конкуренция усилилась.
Особенно часто это можно услышать от специалистов из QA/AQA: Мол, тестирование переполнено, вакансий мало, а найти новую работу стало почти нереально.
Я давно консультирую ребят в сфере QA и автоматизации тестирования (AQA) и регулярно наблюдаю, как специалисты выходят на рынок. Поэтому иногда вижу довольно наглядные примеры того, как ситуация выглядит на практике.
Как раз недавно один из ребят показал в нашем чатике свой календарь собеседований за декабрь — этот календарь приложил выше.
И, честно говоря, даже меня это немного удивило. За месяц у него набралось 44 собеседования.
Причём: Во-первых, всё это происходило параллельно с основной работой. Человек не уходил в отпуск и не ставил поиск работы на полный день — все интервью проходили между рабочими задачами.
Во-вторых, это был декабрь. Если смотреть на рынок найма в IT, конец года традиционно считается не самым активным периодом: компании закрывают бюджеты, команды уходят в отпуска, процессы замедляются.
Тем не менее календарь получился очень плотным.
Иногда у него было по несколько интервью в день: HR, технички, финалки, снова HR.
А если представить его лицо 11го декабря — то лучше не надо)
P.S. Выходил на рынок он как Fullstack QA/AQA, если что. В ручном тестировании естественно ситуация похуже. Но наверное основной моей задачей и являлось помочь ему с этим переходом (QA->AQA), т.к. именно тут наилучшая конверсия для QA.
И что по итогу? Оправдались ли такие усилия?
Думаю, всем это тоже будет интересно. Стоило ли оно вообще того.
Вы реально думаете, что человек, который проходил по 6 собесов в день, мог не добиться своего?)
Всё-таки в подобной ситуации очень быстро прокачиваются навыки интервью. С каждым новым собеседованием ответы становятся точнее, технические вопросы разбираются быстрее, а уверенность растёт.
В итоге этот кандидат получил 6 офферов.
Один из них оказался особенно сильным — около 490 000 рублей gross для позиции в автоматизации тестирования.
На мой взгляд, это хороший пример того, как сейчас устроен рынок.
Да, он действительно стал сложнее. Да, требования выросли.
Но при этом рынок далеко не мёртв. Он просто стал требовательнее к кандидатам.
Те, кто активно выходят на рынок, много собеседуются, анализируют обратную связь и продолжают двигаться дальше — как правило, всё равно получают результат.
А те, кто не пытается, чаще находят объяснение, почему сейчас «не время».
Поэтому, когда в очередной раз услышите, что рынок QA/AQA окончательно умер, просто вспомните календарь из 44 собеседований за один месяц.
Спасибо, что дочитали пост до конца! Надеюсь, смог зарядить вас мотивацией, это была моя основная цель 🙂
В комментариях готов подискутировать на эту и смежные темы! Ну а в своем блоге Telegram также пишу про тестирование и автоматизацию, иногда затрагивая и общие темы развития в сфере IT. Всегда рад новым читателям!)
Меня зовут Дима. Я разработчик и последние пару лет занимаюсь карьерным консультированием. Через меня прошло множество кейсов и за это время я чётко увидел одну вещь: поиск работы стал слишком выматывающим.
Не потому что люди слабые, а потому что процесс стал сложным, долгим и алгоритмическим.
Отклики уходят в пустоту. Резюме читают секунды. При этом сопроводительные письма либо не читают вообще, либо одним глазом.
В какой-то момент я понял: советов уже недостаточно. Нужен инструмент, который сам будет применять эти советы.
Так я решил заняться своим проектом — ИИ-ассистентом для поиска работы.
С чего всё начиналось
Идея была простой: Находим вакансии → анализируем → генерируем письмо → отправляем отклик.
Технически всё работало. По факту — конверсия почти не изменилась. (Кто бы мог ожидать)
Быстро стало понятно, что делать быстрее — не значит лучше.
Базовая LLM пишет слишком «правильно»: канцеляризмы, одинаковая структура, списки. Мы долго работали над стилистикой и вариативностью, чтобы письмо выглядело так, будто кандидат реально вчитался в вакансию.
3. Отчетность
У нас нет режима, который всё делает за спиной.
Вы видите какие вакансии найдены, какие письма сформированы, какие отклики отправляются, какие результаты получены.
При этом можно настраивать стратегию, скоро добавляем чёрный список компаний — по запросу пользователей.
4. Работает аккуратно
Мы сознательно внедрили естественные паузы, человеческую скорость действий, защиту от перегрузок, контроль стабильности.
В день первого запуска мы словили такую нагрузку, что пришлось экстренно масштабировать обработчик взаимодействия с hh. Это был хороший урок.
Зачем это всё
Как карьерный консультант я вижу главное: люди тратят слишком много энергии на рутину.
Этот проект (он, кстати, называется OfferMate) не волшебная кнопка «оффер». Это инструмент, который:
снимает техническую нагрузку,
ускоряет касание с рынком,
делает процесс управляемым.
Если интересен такой подход, то вот ссылки:
Блог проекта — здесь можно принять участие в тестировании и уточнить важные для себя моменты Лэндинг проекта — тут базовая информация, можно почитать про функции и т.д.
Новую работу гарантировать не могу, но рутину из поиска точно уберет)
Русский FAANG: карьерный буст или выгорание за 400к? Что выбрать QA/AQA
В русском IT регулярно всплывает формулировка «русский FAANG» и многие хотят туда попасть. В этом посте на основе своего опыта разберу, стоит ли оно того.
Начнем с того, что каждый под словосочетанием русский FAANG подразумевает разное. Есть как минимум: 1. ВАСЯ: ВК, Альфа, Сбер, Яндекс 2. МЯСОВАТА: Mail (VK), Яндекс, Сбер, Озон, Валдберрис, Авито, Теле2, Альфа 3. Мой любимый - ОБОСРАЛСЯ: Озон, Билайн, ОККО, Сбер, Рамблер, Атол, ЛамодаТех, Совкомбанк, Яндекс
В целом есть множество различных вариаций и аббревиатур, но нет одной единственно правильной. Почему - везде есть свои проблемы и преимущества. Всё в большей степени зависит от проекта. Внутри одной и той же компании может быть и круто, и очень плохо. Поэтому и нет четкого списка "топ компаний", все оценивают по разным критериям.
Так стоит ли QA/AQA и другим стремится в ВАСЯ или можно ограничится ОБОСРАЛСЯ или даже обычными мелкими компаниями / стартапами?
Чего стоит попасть туда (насколько это сложно)
У многих есть ощущение, что российский бигтех - это нечто недосягаемое. Почти как западный FAANG.
Если говорить про автоматизацию тестирования и смежные роли, картина выглядит иначе. Я скажу больше, выходя на рынок как AQA - вы с большей долей вероятности попадете именно в бигтех.
Автоматизация сегодня - одна из самых востребованных зон в крупных компаниях. Большой продукт, частые релизы, много интеграций - без автотестов это сложно поддерживать.
Плюс последние годы усилили тренд на оптимизацию затрат. Ручное тестирование постепенно сокращается, а автоматизация растет. Считается, что один AQA может закрывать задачи нескольких QA.
Поэтому спрос на автоматизаторов в бигтехе стабильно высокий. И в этом смысле двери туда открыты куда шире, чем кажется со стороны.
Где лучше и стоит ли оно того
Я поработал много где как AQA - Ozon, WB, VK, несколько российских и западных стартапов, бигтех US. И могу с уверенностью сказать, что тут не угадаешь, везде всё по разному. Например, в одном из криптостартапов я встретил лучшие процессы, что видел в жизни, а в двух из бигтехов - миллион токсиков, невероятную бюрократию и в целом не очень классные процессы.
Поэтому мое личное мнение - умирать ради работы в конкретной компании вообще того не стоит.
Проекты могут быть плохие и хорошие как в бигтехах, так и в мелких компаниях. Да, в бигтехах часто процессы получше, но это далеко не всегда так. Ну а хороший оффер могут дать и там, и там.
В общем, тут стоит выбирать по сумме условий и не руководствоваться именем компании, т.к. оно часто ничего не значит.
Те же самые "интересные задачи" есть везде, а в стартапах они часто даже круче и челленджовее.
Что в сухом остатке
При прочих равных условиях кроме записи в резюме работа в бигтехе не дает ровным счетом ничего. Везде всё по разному и может оказаться так, что в стартапе проект будет в миллион раз лучше по всем параметрам. Ну а строчку в резюме всегда можно придумать, если так уж хочется.
Всем спасибо за внимание! В комментариях готов подискутировать на эту и смежные темы! В своем блоге Telegram также пишу про тестирование и автоматизацию, ну и в целом про карьеру в сфере IT. Всегда рад новым читателям!)
ТРЕК 1 / NO-CODE 1.1 Введение в AI-агентов 1.2 Промпт-инжиниринг 1.3 Платформы и модели 1.4 Практика no-code 1.5 Безопасность и этика AI 1.6 Финальный проект ТРЕК 2 / РАЗРАБОТЧИКИ 2.1 Введение в AI-кодинг 2.2 Claude Code 2.3 Gemini CLI 2.4 Codex CLI 2.5 Cursor и IDE-агенты 2.6 AGENTS.md и документация 2.7 MCP 2.8 Российские модели 2.9 Воркфлоу и OpenClaw 2.10 Финальный проект ТРЕК 3 / OPENCLAW 3.1 Знакомство с OpenClaw 3.2 Подключение каналов 3.3 Настройка и автоматизация 3.4 Мультиагентная архитектура
Привет, Хабр! Как насчет небольшой задачи, чтобы вкатиться в рабочую неделю?
Условие
В IT-компанию N привезли экспериментальное устройство для автоматизации расчетов. Оно работает на урезанном интерпретаторе Python: никаких условий, сравнений или встроенных функций — только арифметика и битовые операции.
Знаки сравнения (>, < == и другие) использовать не получится, интерпретатор их не поймет и выдаст ошибку. Однако без них писать код довольно сложно. Придется реализовать базовую логику выбора большего из двух чисел.
Задача
Есть два числа: a и b. Найдите наибольшее из них, используя только сложение, вычитание, деление и умножение, а также битовые операции.
Нельзя использовать операторы сравнения (>, <, ==, != и т. д.), тернарный оператор, функции вроде max(), min() и прочее.
Попробуйте справиться с заданием. А один из вариантов решения показываем в Академии Selectel.
Детерминистический аудит-слой для LLM-агентов — открытое демо
Мультиагентные системы уже работают в финтехе и госсекторе — но их решения остаются чёрным ящиком. Я собрала eval pipeline, который аудирует поведение агентов в реальном времени:
→ Нарушения KYC/AML правил → Зацикливание в цепочках решений → Галлюцинированные обоснования
Архитектура: LangGraph агент → структурированные логи → метрики (consistency, anomaly detection) → audit report с PASS/FAIL по каждой цепочке.
Работает на любой модели через LiteLLM — меняешь модель одной строкой в config.yaml. API-ключ не нужен, есть рабочий Jupyter notebook.
Ориентировано на финтех и госсектор: EU AI Act, ФСТЭК.
В Python атрибуты классов по-умолчанию хранятся в специальном dunder-атрибуте __dict__. В описании класса его задавать не надо, он есть неявно и доступен для просмотра при необходимости. Каждый экземпляр класса также имеет свой __dict__:
class Standard:
def __init__(self, x, y):
self.x = x
self.y = y
std = Standard(100, 200)
std.__dict__ # {'x': 100, 'y': 200}
Помимо того, что и класс и экземпляры отдельно занимают своими __dict__ место в памяти, хранение данных в словарях само по себе несет большие накладные расходы. Хеш-таблица в основе словаря хранит служебные структуры и растёт скачками при увеличении числа атрибутов, поэтому на больших количествах объектов затраты памяти ощутимы:
Один из эффективных способов сэкономить память, это реализовать в классе специальный атрибут __slots__ и объявить в нем последовательность атрибутов экземпляра. Тогда вместо __dict__, Python будет использовать альтернативную структуру хранения атрибутов с помощью дескрипторов. __slots__ для экземпляров классов отдельно не создается и хранится только на уровне класса:
class Slot:
__slots__ = ('x', 'y') # Неизменный кортеж из имен атрибутов
def __init__(self, x, y): # Остальное – без изменений
self.x = x
self.y = y
slt = Slot(100, 200)
slt.__dict__ # **AttributeError**: 'Slot' object has no attribute '__dict__'. Did you mean: '__dir__'?
slt_size = getsizeof(slt)
slt_size # 48 байтов
Так добавив одну строчку кода, можно сэкономить расходы памяти в приложении, где требуется создавать миллионы одинаковых объектов.
--- Важные ограничения
Стоит отметить, что реализация __slots__ запрещает динамически добавлять экземпляру класса атрибуты, в отличие от __dict__. В ситуациях, где такое необходимо, __slots__ не подойдет.
std.z = 300
std.__dict__ # {'x': 100, 'y': 200, 'z': 300}
slt.z = 300 # **AttributeError**: 'Slot' object has no attribute 'z' and no __dict__ for setting new attributes
Важно, не забывать расширять слоты, если мы добавляем в код класса новые атрибуты:
class PartialSlots:
__slots__ = ('x', 'y') # Не добавили атрибут экземпляра 'z'
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
p = PartialSlots(100, 200, 300) # **AttributeError**: 'PartialSlots' object has no attribute 'z' and no __dict__ for setting new attributes
В подклассах от класса со __slots__ наследование этого атрибута проходит лишь частично. Для полноценного использования, его стоит определить еще раз, включив новые атрибуты подкласса:
# Подкласс без доп. логики
class InheritSlot(Slot):
pass
inh_slt = InheritSlot(100, 200)
inh_slt.__dict__ # {}, атрибут снова доступен
inh_slt.z = 300 # Нет ошибок при динамическом расширении атрибутов
inh_slt.__dict__ # {'z': 300}, словарь подкласса снова занимает память
# Поправим
class InheritSlot(Slot):
__slots__ = ('z', ) # Слоты суперкласса добавятся в начало кортежа. В конце не забываем запятую, так как это кортеж из одного элемента.
inh_slt2 = InheritSlot(100, 200, 300)
inh_slt2.__dict__ # AttributeError ... теперь слоты используются корректно в подклассе
Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»
Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».
Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.
1. Программист — это не «печатающая машинка»
Главная ошибка паникеров в том, что они путают набор текста с программированием. Если ваша работа заключалась в том, чтобы копипастить методы из Stack Overflow и менять там названия переменных — да, у меня для вас плохие новости. ChatGPT делает это быстрее и без обеденного перерыва.
Но программист — это не тот, кто знает, где поставить точку с запятой. Программист — это переводчик. Мы переводим смутные человеческие «хотелки» на жесткий язык логики, понятный машине.
2. Эволюция «костылей»
Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.
ИИ — это просто следующий уровень абстракции. Это новый «язык программирования», где вместо скобочек мы используем новый язык -конструктычистого смысла
3. Проблема «идеального мусора»
ИИ — это зеркало вашего мышления. Если вы дадите нейронке кривое, логически дырявое задание — она выдаст вам идеально написанный, быстрый, оптимизированный... мусор. Чтобы управлять ИИ, вам нужно иметь в голове структуру еще более четкую, чем раньше. Теперь цена ошибки в логике выросла. Если раньше вы ошибались в синтаксисе — программа не заводилась. Теперь она заведется, но уедет не туда.
4. ИТ-поликлиника
Представьте, что в больнице появился робот-санитар, который идеально моет полы и делает уколы. Означает ли это, что врачи-хирурги или диагносты больше не нужны? Наоборот! Теперь им не нужно отвлекаться на мытье полов.
А кого вообще не заденет? (Спойлер: Работы будет завались)
Если вы думаете, что ИИ — это такой терминатор, который выкосит всё ИТ-отделение, то вы плохо представляете, как устроена реальная «цифровая больница». Есть куча специализаций, где человеческий фактор — это не баг, а фича.
Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.
Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))
SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.
Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».
Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?
Итог
Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.
ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.
Так что идите пить чай, делайте зарядку для мозгов и учитесь формулировать. Это единственный навык, который у вас никто не отберет.
Как я написал 87 000 сопроводительных писем - про разработку помощника для поиска работы.
Сразу уточню - писал сопроводительные само собой не сам. Мы с командой работаем над ИИ-ассистентом для поиска работы и эти 87 000 писем были отправлены пользователями сервиса в рамках бета-тестирования.
За этой цифрой - месяцы экспериментов, правок и неудачных гипотез. В этом посте поделюсь, с какими сложностями мы столкнулись и как их решили.
Задача
Изначально мы хотели решить довольно простую на первый взгляд проблему: автоматизировать написание сопроводительных писем.
Но быстро стало понятно, что «просто генерировать текст» - бессмысленно.
Цель изменилась. Нужно было не просто прикладывать письмо к отклику, а сделать его:
релевантным конкретной вакансии
не шаблонным
не выглядящим как типовой текст нейросети
понятным для HR за несколько секунд
И вот тут начались сложности.
С чем столкнулись
Шаблонность моделей. Даже при хорошем промптинге тексты начинали повторяться по структуре и формулировкам.
Разные ожидания HR. Кто-то предпочитает краткость, кто-то - структуру, кто-то - конкретные достижения в цифрах.
Изменяющиеся требования вакансий. Один и тот же стек может быть описан по-разному, и формальное совпадение по ключевым словам не гарантирует релевантности.
Ограничения платформ. Изменения на стороне hh влияли на логику работы системы, и часть архитектуры приходилось пересобирать.
В какой-то момент стало ясно, что проблема глубже.
Главный вывод
После десятков тысяч писем стало очевидно:
Проблема не в том, что сопроводительные «плохие». Проблема в том, что в них не видно релевантности.
HR тратит на письмо буквально несколько секунд. Если за это время не становится понятно, почему кандидат подходит - письмо закрывается.
Поэтому мы изменили подход.
Система теперь не «пишет красиво». Она сначала сопоставляет требования вакансии с опытом пользователя и только потом формирует текст, где это соответствие явно показано.
Что изменилось в результате
После 87 000 отправленных писем тексты стали короче, конкретнее, привязанными к требованиям вакансии, менее шаблонными.
Ну а параллельно дорабатывались и другие части системы:
фильтрация релевантных вакансий
автоматизация откликов
работа с онлайн-тестами
механизмы приоритизации
Что по итогу имеем сейчас
Проект находится в стадии бета-тестирования. Мы продолжаем собирать фидбек и корректировать логику, особенно в части сопоставления опыта и требований.
История с сопроводами по большей части пройдена, но осталось ещё множество аспектов для улучшений.
Кому интересно - могут попробовать бота бесплатно. В блоге можно найти более подробную информацию. Также там пишу про развитие проекта и проблемы, с которыми сталкиваемся.
Представлен открытый проект rembg — легковесный скрипт на Python, который поможет убрать фон даже с самых сложных картинок. Удаляет фон за секунды и не грузит ПК.
Открытый проект Dangerzone позволяет преобразовать любой документ в безопасный PDF. Решение работает с , таблицами, картинками и другими форматами документов, распаковывает и проверяет их в изолированном пространстве — даже если внутри вирус, локальному ПК ничего не грозит. На выходе получается безопасный файл для просмотра.
