Python *

Открытый проект Dangerzone позволяет преобразовать любой документ в безопасный PDF. Решение работает с , таблицами, картинками и другими форматами документов, распаковывает и проверяет их в изолированном пространстве — даже если внутри вирус, локальному ПК ничего не грозит. На выходе получается безопасный файл для просмотра.

Открытый проект Cheat-Sheets предоставляет учебны материалы для Python, Rust, Swift, JavaScript, Kotlin, Go, Git, и других проектов. Там есть все важнейшие концепции, правила, стили программирования, фреймворки, библиотеки и прочее. Внутри также курсы по Git, Docker, базам данных, а также алгоритмам. Все материалы разделили по уровням сложности, к каждой главе есть контрольные вопросы и десятки задач. Все концепции авторы объясняют на конкретных примерах и разжевывают до последней строчки кода.

Всем привет. Хотелось узнать, сложно ли развивать Telegram бот.
Нашел на просторах habr такую статью:
https://yg140.servegame.com/ru/articles/778588/
Мой бот только на русском языке, поэтому статьи писал на Яндекс Дзен (0 просмотров, пост скорее всего удалили), DTF (лучший источник пользователей, комментят и заходят в бота), habr (написал пост-рекламу - не помогла).
Еще есть реддит, но я новый пользователь (там с этим беда - карма маленькая (попаду в ад)).

Что посоветуйте делать? Только не бейте)
Ну и соответственно ссылка на бота:
http://t.me/drinking_buddy_2025_bot

Всем спасибо)

Про Созвоны

Любой руководитель в распределенной команде сталкивался с ситуациями, когда команда начинает гореть от созвонов. Спринт задачами набили, оценили, а потом половину не сделали. Из-за чего? Не попали в оценки. Были влеты..

А еще была куча общих встреч, ретро, планнингов, скрам-баннингов и интерраптов, которые на доске и в таймшите не увидишь.

Инженеры так не любят созвоны, потому что у них неосязаемый импакт и definition of done. Они мыслят задачами, мерж-реквестами, зелеными тестами, чем-то с измеримым результатом. Сел за задачу, вник и сделал. КПД в идеальных условиях напоминает воркера. В очередь пришла задача — он ее обработал и закрыл, ждет следующую. В перерывах гладит кота или пузо.

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

Для внеплановых статусов менеджер не всегда заранее знает, кто ему по факту нужен, и зовет «на всякий». На созвонах, кроме ведущего и ЛПР, участники в принципе нужны подстраховать. Вася может понадобиться. А может и не понадобиться. И опять сидит Вася без камеры, без микрофона и грустит. Ждет, когда все закончится, чтобы вспоминать, на чем он там остановился.

На моей практике лишние звонки исходят от консервативных слабых процессов и выученной беспомощности. Есть на проекте карго-культ аджайла и плохая база оперативных знаний. День забит статусами и повторами одной и той же информации для разных людей.

Кто поможет создать правильный шумовой барьер и дать команде работать, при этом отдавая в проектный офис нужную информацию? Как по мне, это не обязательная боль инженера. Побороть проблему — роль хорошего лида.

1. Урон от звонков надо вбирать в себя лиду. Его обязанность — знать контекст по верхам о проблемах и задачах вверенной команды. Отстаивать их интересы, обрабатывать обратную связь. Таков путь, отделяющий лида от сеньора-помидора.

2. Лиду надо собирать дашборды, таблицы, фильтры, регламенты, схемы. Запросы на оперативную информацию не должны отнимать ресурсов. Все по полочкам: база знаний, закладки, конфля, raycast шорткаты, ИИ-агента с MCP натравить на Confluence и Jira (если ИБ по шапке не даст). Надо и свой ресурс беречь и дать просящему удочку вместо рыбы.

3. От лишних звонков можно отказываться. Без конфронтаций, просто фильтровать: «А зачем? Вот все ответы на вопросы». Либо можно договориться многие задачи сделать асинхронно. Таска в джире с исполнителем и сроком и поехали.

4. Проектам нужна карта компетенций. Для тех ситуаций, где нужно глубже вникнуть в предметную область, это ок — привлечь инженера вместо лида. Важно знать, какого. Классический мем: девять женщин не могут родить ребенка за месяц. С этим стереотипом «больше-лучше» карта компетенций помогает бороться.

5. Звонок на час — плохой дефолт. 45 минут — уже лучше. 30 минут — еще лучше. 15 можно не ставить, есть мессенджер и почта.

6. Звонки должны ставиться по календарю. Вызванивать минута в минуту — моветон хотя бы потому, что есть правда неотложные ситуации. Но не все звонки — неотложные.

7. У звонков должны быть повестки. Приглашенные должны иметь возможность понимать, о чем пойдет речь. В идеале, нужна ссылка на доки или задачи. Без этого участники идут на звонок вслепую и тратят время, чтобы понять, что от них хотят.

Побуду адвокатом дьявола. На некоторые звонки команду лидам брать надо. Так можно узнать полезную информацию с полей. Ребята могут раскрыться, вовлечься. Вполне смогут затащить какой-то каверзный проект и унести его в перфоманс ревью.

В общем-то из поста у меня нет цели делать вывод, что звонки — зло. Хотим удаленку, значит потерпим общение в зуме. Как и любой другой канал коммуникации, звонок — это инструмент. У него есть области применения, хорошие практики.

Зло — звонки не оптимизировать. А инженера с его очередью лучше оставить в цикле и не засорять эфир.

Не смогли смириться с поражением - и к чему нас это привело. Как мы воскресили ИИ-помощника для поиска работы

Привет, Хабр.

В декабре наш ИИ-ассистент для поиска работы фактически перестал работать.
Изменения на стороне платформ, ограничения, поломанные сценарии - всё то, из-за чего большинство подобных проектов обычно закрываются или уходят в «заморозку».

Самый логичный вариант был простой:

«Ну ок, рынок поменялся, едем дальше».

Но мы решили иначе.

Мы не смогли смириться с тем, что квалифицированные специалисты по-прежнему тратят часы жизни на клики, шаблонные отклики и бесполезную рутину.
Поэтому вместо точечных фиксов мы решили не чинить старое, а пересобрать всё с нуля.

Так начался путь к OfferMate 2.0.

Главная мысль оказалась неожиданно простой:

Автоматизация должна быть не только быстрой, но и естественной.

Настоящий цифровой ассистент должен вести себя как человек:

• выбирать вакансии осмысленно;

• работать с паузами и приоритетами;

• не выглядеть как бот;

• и не ломаться при реальной нагрузке.

Именно вокруг этого принципа мы и пересобрали архитектуру продукта.

Что теперь умеет OfferMate 2.0

🤖 Отклики только на релевантные вакансии
Ассистент анализирует ваш опыт и требования работодателя и выбирает вакансии, которые действительно подходят, а не просто совпадают по ключевым словам.

👤 Имитация человеческого паттерна поведения
Система воспроизводит действия пользователя: паузы, разную скорость, приоритеты.
Это делает работу максимально естественной и безопасной.

✍️ Персонализированные сопроводительные письма
Каждое письмо формируется под конкретную вакансию и компанию - на основе вашего опыта и требований позиции.

📈 Контроль и аналитика
Пользователь видит, что происходит в системе, и может управлять стратегией поиска.

🧩 Новые функции

• автоматическое прохождение онлайн-тестов;

• поддержка одновременных откликов с нескольких аккаунтов.

Про релиз

12 февраля в 12:00 мы открываем доступ к OfferMate 2.0.

Первая волна будет ограничена 50 пользователями, а доступ открыт на 3 дня.
Это осознанное ограничение - чтобы сохранить стабильность системы и быстро собрать качественную обратную связь.

Поучаствовать в тестировании в числе первых можно будет в нашем телеграм канале, в нём делимся всеми новостями проекта:

👉 https://t.me/offermatecrew

Буду рад вопросам и обсуждению в комментариях

Я выпустил новую версию библиотеки для работы с МЭШ (Московская Электронная Школа)

https://github.com/xd2dd/schoolmospy

Асинхронность, удобные датаклассы и все базовые методы

Открытый проект ebook2audiobook превращает любую электронную книгу в полноценную аудиокнигу. Работает просто: закидываете epub, pdf или даже обычный txt и на выходе получаете готовый аудиофайл с главами, нормальной озвучкой и метаданными. Подойдёт, если не любите читать глазами, но хотите слушать книги в дороге или на тренировке. Работает локально на ПК и поддерживает множество языков и даже умеет клонировать голос. Можно озвучить книгу своим голосом или профессиональным диктором. Идеально для студентов, тех кто учит языки, или просто хочет слушать свои книги офлайн без подписок и облаков.

Обновлён учебный курс Welcome to the Python Programming Hub по Python с полного нуля до уровня продвинутого разработчика за 3 месяц. В репозитории сотни материалов для изучения Python, а также Data‑аналитики, машинного обучения, Data Science. Там есть вся база по Python с первых строчек кода до комплексного ООП, лямбда‑функций, замыканий и других сложных концепций языка. Изучение всех необходимых базовых библиотек, которые должен знать каждый уважающий себя разработчик на Python: JSON, Math, NumPy, Pandas, а также фреймворка Django. Материалы по всем актуальным и полезным API, машинному обучению, распознаванию речи, парсингу, компьютерному зрению, работе с изображениями и даже видео, алгоритмам и автоматизации процессов. Также даётся детальное представление о различных специализациях Python‑разработчиков, которые можно освоить и реализовать несколько пет‑проектов. В каждой главе представлены исчерпывающие примеры кода, картинки, объяснения, квизы и контрольные вопросы.

лайкните пост кто сейчас вайбкодит свои продукты и напиши в комментах что делаете. очень интересно!

Почему хороший тестировщик — это не тот, кто нашел больше всего багов

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

На практике все сложнее. И чем опытнее становится тестировщик, тем реже он гордится просто цифрами.

Количество багов ничего не говорит само по себе

Сто найденных дефектов могут означать две совершенно разные вещи:

• продукт реально нестабилен;

• тестирование началось слишком поздно.

Если баги находятся пачками в самом конце разработки, это не успех, а симптом. Хороший тестировщик старается сделать так, чтобы часть проблем не доходила до баг-трекера вообще.

Сильный тестировщик думает раньше, чем тестирует

Тестирование начинается не с чек-листов и не с автотестов. Оно начинается с вопросов.

• что здесь может пойти не так;

• где система уже ломалась;

• какие изменения самые рискованные.

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

Баг-репорт — это не обвинение

Новички иногда воспринимают баг как доказательство чьей-то ошибки. Отсюда агрессивные формулировки и желание «поймать» разработчика.

Опытный тестировщик понимает — баг-репорт это способ помочь команде. Хорошее описание проблемы экономит время всем:

• понятно, что сломалось;

• понятно, как воспроизвести;

• понятно, почему это важно.

Чем меньше эмоций и больше контекста — тем лучше работает процесс.

Автотесты — это не самоцель

Автоматизация часто превращается в гонку — у кого больше тестов, у кого выше покрытие. Но цифры сами по себе ничего не гарантируют.

Хороший тестировщик задает другие вопросы:

• ловят ли эти тесты реальные проблемы;

• можно ли им доверять;

• не мешают ли они менять код.

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

Хороший тестировщик думает о пользователе, а не о сценарии

Чек-листы и тест-кейсы важны, но реальный пользователь почти никогда не действует по ним.

Он кликает не туда, вводит странные данные, прерывает процессы и возвращается позже. Умение выйти за рамки сценариев отличает опытного тестировщика от формального.

Качество — это ответственность всей команды

Одна из самых токсичных идей в тестировании — что за качество отвечает только QA. Это удобно, но не работает.

Сильный тестировщик не берет качество на себя полностью. Он помогает команде видеть риски, объясняет последствия и участвует в решениях. Но ответственность остается общей.

Карьерный рост в тестировании — это не про инструменты

Инструменты меняются быстро. Сегодня один фреймворк, завтра другой. Знание конкретного тулкита редко определяет уровень специалиста.

Гораздо важнее:

• умение анализировать систему;

• понимание, где искать проблемы;

• способность говорить с разработчиками и бизнесом на одном языке.

Именно это делает тестировщика ценным, а не список технологий в резюме.

В итоге

Хороший тестировщик — это не тот, кто нашел больше всего багов. Это тот, кто:

• помогает находить проблемы раньше;

• думает о рисках, а не о галочках;

• пишет понятные баг-репорты;

• работает с командой, а не против нее.

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

Сразу оговорюсь, это пост- реклама.

Написал Telegram бота для знакомств (поиск собутыльника). Пользователь отправляет свою геопозицию (широту и долготу), а боту нужно предложить людей, живущих рядом.
Нашел на просторах интернета HTTP Геокодер от Яндекса. Что-то около 25000 запросов в месяц бесплатно. Ты отправляешь запрос с широтой и долготой, а сервис тебе населенный пункт (район, улица и т.д.).
Ссылка на сервис:
https://yandex.ru/maps-api/products/geocoder-api
Подключить его не сложно (документация хорошая).

Приведу пример запроса:

PARAMS = {
        "apikey":"ваш api key",
        "format":"json",
        "lang":"ru_RU",
        "kind":"locality",
        "geocode": "долгота, широта"
    }

    #отправляем запрос по адресу геокодера.
    try:
        r = requests.get(url="https://geocode-maps.yandex.ru/1.x/", params=PARAMS)
        #получаем данные
        json_data = r.json()
        #вытаскиваем из всего пришедшего json именно строку с полным адресом.
        address_str = json_data["response"]["GeoObjectCollection"]["featureMember"][0]["GeoObject"]["metaDataProperty"]["GeocoderMetaData"]["AddressDetails"]["Country"]["AddressLine"]
        #возвращаем полученный адрес
        return address_str
    except Exception as e:
        logger2.error(e, exc_info=True)
        #если не смогли, то возвращаем ошибку
        return "error"

Поменяйте только ваш apikey и широту с долготой. Запрос вернет населенный пункт по заданным данным (долгота и широта).

Ссылка на моего бота:
http://t.me/drinking_buddy_2025_bot

Спасибо за внимание

Яндекс.Музыка заблокировала доступ к сервису на уровне аккаунта. Уже 3 месяца поддержка “разбирается”

С ноября у меня полностью заблокирован доступ к Яндекс.Музыке на уровне аккаунта (bearded-rocker@yandex.ru). Не отдельный девайс, не браузер, не приложение — аккаунт целиком.

TL;DR

• Я использую официальный API Яндекс.Музыки

• В какой-то момент доступ к Яндекс.Музыке для моего аккаунта был молча заблокирован

• Блокировка воспроизводится во всех клиентах: веб, мобильные приложения, устройства

• Смена токенов, переустановка приложений, другие устройства — не помогает

• В поддержке заведены тикеты ещё с ноября

• Прошло больше 4 месяцев — доступа нет, решения нет

Предыстория

Осенью я начал пользоваться Яндекс.Музыкой и колонкой с Алисой. Чтобы не терять годы истории из Spotify, я написал небольшой сервис, который синхронизирует мои плейлисты и треки через неофициальный API Яндекс.Сервис какое-то время нормально работал, после чего доступ к Яндекс.Музыке для моего аккаунта внезапно пропал полностью.

Симптомы выглядят так:

• Яндекс.Музыка не работает нигде:— веб— iOS / Android— устройства с Алисой

• Это не связано с VPN, IP или устройством

• Это не выглядит как клиентская ошибка

• Это выглядит как account-level блокировка внутри сервиса

• в Браузере получаю ответ (в dev tools):

{ "name": "forbidden", "message": "403 Forbidden: "{"name":"API access restricted","message":""}"", "requestId": "99f13438-a1c9-43a7-9d7d-7de00bd3ea49.1"}

Я сразу обратился в поддержку Яндекс.Музыки. После стандартных проверок они подтвердили, что проблема не на моей стороне, и завели тикет “на инженеров”.

На сегодняшний день:

• есть два тикета, заведённых ещё в ноябре: 25103113405032668, 25121613434183682

• каждый новый оператор начинает диалог заново

• снова предлагается “обновить браузер / переустановить приложение”

• затем снова: «да, мы видим проблему, инженеры занимаются»

Я не прошу ничего экстраординарного:

• Восстановить доступ к Яндекс.Музыке для моего аккаунта bearded-rocker@yandex.ru, я плачу за Plus, Алису-Pro и хочу пользоваться этими сервисами.

Сейчас же ситуация выглядит так:

• платный сервис недоступен

• тикеты “живы”, но без движения

• сроков, статуса и ответственного нет

@yandex please help 🙏

Копипаста в Python редко выглядит как копипаста

В Python-проектах дублирование кода почти никогда не выглядит как «один файл скопировали в другой». Чаще это повторяющиеся структуры, контрольные потоки и оркестрационная логика, которые со временем начинают незаметно расползаться по коду.

Формально всё выглядит по-разному: другие имена, другие константы, чуть иной порядок.
Но архитектурно — это одно и то же решение, просто размноженное.

Я хочу рассказать про CodeClone — инструмент, который я написал для поиска именно такого дублирования. Он не сравнивает строки и токены, а работает на уровне **нормализованного Python AST и графов управления потоком (CFG).

Почему текстовые clone-detectors не работают

Большинство инструментов ищут дублирование через строки, токены или поверхностное сравнение AST. Это отлично ловит copy-paste, но почти бесполезно, когда код:

• переименован,

• отформатирован по-другому,

• слегка отрефакторен,

• но реализует один и тот же сценарий.

В реальных проектах это часто:

• одинаковые цепочки валидации,

• повторяющиеся request/handler пайплайны,

• скопированная оркестрационная логика,

• похожие try/except или match/case конструкции.

Идея: сравнивать структуру, а не текст

В CodeClone я пошёл другим путём:

1. Код парсится в Python AST.

2. AST нормализуется (имена, константы, аннотации убираются).

3. Для каждой функции строится Control Flow Graph.

4. Сравнивается структура CFG, а не исходный код.

Важно: CFG здесь — структурная абстракция, а не модель выполнения. Цель — найти повторяющиеся архитектурные решения, а не доказать семантическую эквивалентность.

Что именно ищется

Функциональные клоны (Type-2)

• Функции и методы с одинаковой структурой управления:

• if/else, циклы, try/except, with, match/case (Python 3.10+).

• Инструмент устойчив к переименованию, форматированию и type hints.

Блочные клоны (Type-3-lite)

• Повторяющиеся блоки внутри функций: guard-clauses, проверки, orchestration-фрагменты. Используется скользящее окно по CFG-нормализованным инструкциям с жёсткими фильтрами, чтобы снизить шум.

Почему инструмент намеренно консервативный

Один из принципов проекта:

Лучше пропустить клон, чем показать ложный.

CodeClone не использует ML, вероятностные коэффициенты или эвристические скоринги.
Если клон найден — его можно объяснить и воспроизвести. Это важно при использовании в CI.

Baseline и CI

В живых проектах дубликаты уже есть, поэтому CodeClone работает в baseline-режиме:

codeclone . --update-baseline

Baseline коммитится в репозиторий, а в CI используется:

codeclone . --fail-on-new

Существующие дубликаты допускаются, новые — запрещены.
Это работает как архитектурный регресс-чек.

Про Python-версии

AST в Python не полностью стабилен между версиями интерпретатора. Поэтому версия Python фиксируется в baseline и должна совпадать при проверке. Это сделано ради детерминизма и честности результатов.

Итог

CodeClone не заменяет линтеры или type-checkers. Он полезен, если проект живёт долго, код растёт, и хочется вовремя замечать архитектурное дублирование, а не разбираться с его последствиями позже.

Исходники

GitHub: https://github.com/orenlab/codeclone
PyPI: https://pypi.org/project/codeclone/

Открытый проект 8mb.local — Self‑Hosted GPU Video Compressor умеет сжимать видео любых размеров в десятки раз. Нужный размер пользователь выбирает сам, а компрессор подстроится. По возможности сохраняет качество. Можно выбрать кодек, битрейт и даже обрезать видос во встроенном редакторе. Всё работает локально.

Clawdbot: когда обезьяне дали гранату 🤡

Совсем недавно Clawdbot хайпанул. И тут такое началось... Это не цирк, это хуже.
Добрый дядя из гайда советует прокинуть туннель через ngrok или развернуть это дело на VPS с открытым портом.

Итог: любой школьник находит ваш IP или ngrok-адрес и получает RCE (удаленное выполнение команд) от вашего имени.

Судя по последним новостям агенты и сами не против опубликовать куда нибудь ваши тонны. Так, между делом.

Какой-то цифровой эксгибиционизм. Отберите у них Докер, пока не поздно.

Вышел Nanobot: сверхлёгкая версия Clawdbot (сейчас Openclaw), которая на 99% проще и позволяет запустить ИИ‑помощника менее чем за минуту. Clawdbot кажется слишком сложным, а в Nanobot разберётся даже новичок. Весь движок умещается всего в ~4000 строк кода на Python, тогда как Clawdbot это огромный монстр на 400 000 строк. Nanobot запускается за минуту и готов помогать вам в повседневных задачах, включая анализ рынка в реальном времени: непрерывный мониторинг и сбор аналитики, разработку ПО, помощь в комплексных проектах, управление делами и оптимизация рабочего времени, персональный помощник по знаниям.

Как оставаться релевантным на рынке QA/AQA/SDET в 2026: опыт, харды, софты, ответы

Последнее время всё чаще слышу вопросы про состояние рынка.
Многие говорят, что рынок «умер», вакансий стало меньше, а требования выросли настолько, что найти работу почти нереально.

Часто это выглядит так: человек активно откликается, ходит на собеседования, делает тестовые задания, общается с рекрутерами.
А на выходе получает либо отказы без конкретных причин, либо формулировки вроде «вы хороший специалист, но нам нужен немного другой профиль».

Ощущение, что стало сложнее, не обманчиво. Рынок действительно изменился за последние один-два года.
Но парадокс в том, что именно в таких условиях многим стало проще выделяться. Не потому, что кандидатов стало меньше, а потому, что вырос разрыв между теми, кто выглядит релевантно, и теми, кто нет.

Я регулярно общаюсь с QA, AQA и SDET, которые находятся в активном поиске, и сам продолжаю проходить собеседования, чтобы понимать, как именно сейчас устроен процесс найма.
И вот что я понял из всех историй: сегодня выигрывает не самый наглый кандидат (как было раньше), а тот, кто хорошо понимает свой опыт и умеет его объяснять.

Что изменилось

Еще один-два года назад часто работала простая схема: уверенное резюме плюс нормальная подача давали высокую вероятность оффера.
Во многих компаниях в детали погружались поверхностно, опыт оценивали в общих чертах, а неточности прощались, если кандидат выглядел уверенно.

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

Это не «заговор рынка», а естественная фильтрация. Когда выбор кандидатов большой, требования становятся строже.

Почему в этом есть плюсы

Жесткий рынок хорошо отсеивает слабые места. Причем чаще всего самые базовые.

На собеседованиях у ребят регулярно всплывают одни и те же проблемы:

• человек говорит, что строил фреймворк, но не может связно объяснить архитектуру;

• упоминает автотесты, но не понимает, почему был выбран конкретный стек;

• рассказывает про CI, но путается в вопросах стабильности;

• заявляет ответственность за качество, но не может описать процессы и зоны ответственности.

Большинство кандидатов «падает» не на сложных вопросах, а на уточняющих.
На этом фоне специалист, который осознанно разбирается в своем опыте и может его структурировано рассказать, сразу выглядит сильнее, даже без громких компаний в резюме.

Как сейчас смотрят на опыт

На интервью все меньше внимания уделяется формальным строчкам в резюме и все больше мышлению.

Интервьюеру важно понять:

1. Почему было принято именно такое решение;

2. Какие были трудности;

3. Как проблемы диагностировали;

4. Какие выводы сделали.

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

Поэтому сейчас важна не красивая история, а осознанное понимание своего опыта.

Что с этим делать

Минимальный практический набор:

1. Разложить свой опыт по зонам - архитектура, API, UI, CI/CD, процессы, инциденты.

2. Подготовить ответы в формате «проблема - решение - результат - выводы». (Для шарящих - по STAR)

3. Прогнать опыт через уточняющие вопросы и проверить, где ответы выглядят слабо или непоследовательно.

4. Упаковать резюме как набор конкретных ответов - что улучшал, что оптимизировал, за что отвечал + быть готовым это подтвердить.

Вывод

Рынок действительно стал сложнее.
Но именно поэтому он стал более комфортным для тех, кто держит фокус на релевантности, понимает свой опыт и готовится к проверке.

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

Ну а всем нуждающимся желаю скорее обрести себя на сегодняшнем рынке! Готов подискутировать на смежные темы в комментариях)

Открытый учебный проект 30 Days of Python помогает освоить синтаксис и концепции языка программирования за месяц. Там есть основная база Python от настройки окружения до мощного ООП, организации кода и паттернов проектирования. Каждый день — новая тема. После каждого урока есть десятки вопросов для самопроверки и упражнений для повторения. При этом каждый следующий урок опирается на предыдущий.

Представлен легковесный инструмент Crawlee, который может спарсить информацию с сайтов, соцсетей и других ресурсов, а также обходит защиту от ботов. Может скачать аудио, видео, изображения, метаданные, документы и прочие нужные файлы. Скрипты решения написаны на Python, имитирует поведение человека на сайтах, в соцсетях и других ресурсах. Инструмент поддерживает мультизадачность и не теряет при этом скорость. Можно собирать несколько видов данных одновременно. Работает полностью локально.

Подборка инструкций по Python для начинающих специалистов

Привет, Хабр! Вот и наступила пятница, а значит, пришло время очередной подборки материалов для тех, кто решился взяться за изучение Python. Сегодня у нас несколько базовых инструкций, бесплатный курс и небольшой квиз.

• Как работать с PostgreSQL в Python. Эта статья-шпаргалка научит работать с модулем psycopg2, чтобы немного упростить себе жизнь при администрировании PostgreSQL.

• Рукописный редактор на Python: инструкция для тех, кто хочет «рисовать» код. Создадим виртуальный лист, на котором можно набросать код от руки — и он будет исполняться!

• Как создать голосового помощника на Python. С помощью простых инструментов и библиотек разработаем голосового помощника на Python, сделав его полезным и удобным в повседневной жизни.

• Квиз: хорошо ли вы разбираетесь в Python? Тест на владение синтаксисом Python. Позволит оценить свои знания и отыскать пробелы.

• Изучаем Python: теория, практика, настройка инструментов. Да, это подборка в подборке. Внутри несколько материалов, все доступно бесплатно. Для тех, кто хочет научиться не только писать код, но и запускать его в облаке, внутри курса спрятан промо-код на услуги Selectel.

Не надо делать по красоте. Надо делать MVP.

Никто так говорить, кроме менеджеров, не любит. А я вдруг внезапно полюбил такой подход в работе. Стал бить себя по рукам и делать дешево.

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

MVP-подход тут мне стал очень помогать на моем, локальном уровне. Суть очень простая: делаю минимум и быстро. А потом добавляю на кости мяса. Надо сделать сохранение строк файла в БД? Пока сделаю построчно и поставлю # TODO. Потом сделаю батчем. Нужна отправка сотен объектов из БД в API? Пока тоже построчно. Нужна еще одна очередь Redis для этапа в обработке файла — потом. Пока и с одной очередью и воркером справимся.

MVP-подход требует некоей выдержки, особенно на пет-проектах. Код пишешь ты сам с собой. Выступаешь внутренним критиком и, зачастую, самым строгим. Но делать все дешево и сердито стало помогать мне лично держать фокус на цели: дать максимум ценности за минимум усилий. И при этом не сгореть от объема, быть в тонусе.

Риски, конечно тоже есть. У TODO нет хозяев, кроме нас. Дешевое Г становится иногда продом. Техдолг это вообще бесконечная тема и, пожалуй, не для этого поста. Пост про эффективность.

MVP-промтинг работает и с нейронками таким же образом. Берем чистый контекст, делаем простой прототип. А дальше по кускам его обтесываем, заменяем, улучшаем. Может, у нас есть с ними что-то общее?

У каждого человека есть свое определение голого минимума. Поэтому примеры выше могут кому-то показаться тривиальными. Очевидно, и сам подход не для всех. Но мне лично он развязал немного руки и помог выдохнуть на одной из недавних душных задач. Может быть такой ход мысли поможет и вам.

Рынку плохо? Работу найти нереально? — Это твой шанс 🚀

Последнее время всё чаще вижу одну и ту же ситуацию.

Человек активно ищет работу: отклики, собеседования, тестовые, разговоры с HR.
А на выходе — либо отказы без внятного объяснения, либо формулировки вроде
«вы хороший специалист, но нам нужен чуть другой профиль» 🤷‍♂️

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

Отчасти это правда — рынок действительно стал жёстче.
Но вот что интересно: именно в таких условиях многим стало проще выделяться 💡
Не потому что кандидатов стало меньше, а потому что вырос разрыв между теми, кто выглядит релевантно, и теми, кто — нет.

Я регулярно общаюсь с QA / AQA / SDET, которые сейчас находятся в активном поиске, и сам продолжаю проходить собеседования, чтобы держать руку на пульсе.
И главный вывод из этого опыта простой: сегодня выигрывает не самый громкий кандидат, а тот, кто чётко понимает свой опыт и умеет его объяснять.

Ниже — что именно изменилось и как этим пользоваться 👇

Что изменилось

Ещё 1–2 года назад часто работала простая схема:
уверенное резюме + нормальная подача = высокая вероятность оффера 😌

Многие компании:

• не сильно углублялись в детали;

• смотрели на опыт в общих чертах;

• закрывали глаза на неточности, если кандидат выглядел уверенно.

Сейчас ситуация другая:

• вакансий в ряде направлений стало меньше 📉;

• требования заметно выросли;

• собеседования стали глубже и детальнее 🔍;

• интервьюеры чаще проверяют логику решений и реальный вклад кандидата.

Это не “заговор рынка”, а обычная фильтрация: когда выбор большой — требования растут.

Почему в этом есть плюс

Жёсткий рынок хорош тем, что он быстро отсеивает слабые места ⚠️
Причём чаще всего — самые базовые.

Типичные проблемы, на которых кандидаты “сыпятся”:

• говорят, что строили фреймворк, но не могут связно объяснить архитектуру;

• упоминают автотесты, но не понимают, зачем выбран конкретный стек;

• рассказывают про CI, но путаются в вопросах стабильности и flaky-тестов 🤯;

• заявляют про ответственность за качество, но не могут описать процессы.

Большинство падает не на сложных вопросах, а на уточняющих.
На этом фоне человек, который осознанно разбирается в своём опыте, сразу смотрится сильнее 💪
Даже без “топовых” компаний в резюме.

Как сейчас смотрят на опыт 🎭

На интервью всё меньше внимания формальным строчкам и всё больше — мышлению 🧠

Интервьюеру важно понять:

• почему было принято именно такое решение;

• какие были ограничения;

• что пошло не так;

• как проблему диагностировали;

• какие выводы сделали.

Если опыт не структурирован — ответы быстро разваливаются.
Если опыт разобран и понятен самому кандидату — он спокойно проходит даже при неидеальном бэкграунде.

Поэтому сейчас важна не “красивая история”, а осознанное понимание того, что ты делал.

🎯 Ключевой навык сегодня — релевантность

Недостаточно просто быть QA или AQA.

Важно быть релевантным:

• конкретной роли;

• стеку компании;

• типу продукта;

• уровню ответственности.

Это проявляется в деталях:

• какие кейсы вы выбираете;

• как формулируете достижения;

• как отвечаете на вопросы «почему?» и «а что если иначе?».

Иногда достаточно слегка пересмотреть подходы или формулировки — и это сильно влияет на конверсию.

Что с этим делать 🛠

Практический минимум:
1️⃣ Разложить опыт по зонам: архитектура, API, UI, CI/CD, процессы, инциденты.
2️⃣ Готовить ответы в формате: проблема → решение → результат → выводы.
3️⃣ Прогнать опыт через уточняющие вопросы — здесь хорошо помогают LLM.
4️⃣ Упаковать резюме как набор сигналов 🚦 и быть готовым их подтвердить.

Вывод 🧠

Рынок стал сложнее — это факт.
Но именно поэтому он стал выгоднее для тех, кто:

• держит фокус на релевантности;

• понимает свой опыт;

• готовится к проверке;

• не теряется на уточнениях.

Если относиться к поиску работы как к инженерной задаче, “жёсткий рынок” превращается в возможность 🚀

👉 Если интересно — глубже разбираю эту и другие интересные темы в своем Telegram-канале, ну а также делюсь там инсайдами по рынку, собеседованиям и росту в AQA / SDET.

Как мы научили ИИ вести себя как человек — и почему это оказалось важнее остального 🤖🧠

Привет, Хабр.

За последний год поиск работы для инженеров всё больше стал напоминать кликинг-симулятор: десятки однотипных откликов, шаблонные сопроводительные письма, часы механических действий. ⏳

При этом от кандидата всё ещё ждут осмысленности и персонализации — но обеспечивать её приходится вручную, в масштабе, который плохо сочетается с нормальной жизнью и развитием.

В какой-то момент я решил посмотреть на эту проблему как на инженерную задачу и попробовать автоматизировать рутинную часть процесса. Так появился ИИ-ассистент OfferMate.

Но довольно быстро стало понятно: автоматизация — это не всегда про “делать быстрее и больше”.

Почему «больше автоматизации» — плохая идея ⚠️

Первая версия ассистента решала задачу максимально прямолинейно:

• быстрый сбор вакансий;

• частые проверки;

• высокая плотность запросов;

• ставка на объём.

С инженерной точки зрения всё выглядело логично:
больше данных → больше откликов → выше шанс результата.

На практике это оказалось ошибкой.

Такой подход:

• создаёт пиковые нагрузки 📈;

• выглядит неестественно;

• повышает риск блокировок;

• и, главное, не отражает реального поведения человека.

Рынок труда — не нагрузочный тест и не очередь сообщений в Kafka.
Он реагирует не только на результат, но и на паттерн поведения.

Ключевое открытие: автоматизация должна быть незаметной 🕵️‍♂️

В какой-то момент мы осознали простую вещь:
эффективный ассистент должен вести себя не как бот, а как человек.

Опытный специалист:

• не откликается на всё подряд;

• читает вакансии выборочно;

• делает паузы;

• меняет темп;

• реагирует на контекст.

И если автоматизация не воспроизводит этот паттерн — она рано или поздно ломается.

Это стало точкой, после которой мы полностью пересобрали архитектуру 🔄

Что изменилось в подходе ⚙️

Вместо «ускорения всего» мы сфокусировались на естественности поведения.

Теперь система:

• 🧠 анализирует вакансии, а не просто собирает их пачками;

• 👤 имитирует человеческий ритм: паузы, разную скорость, приоритеты;

• 🔄 адаптируется к изменениям в реальном времени;

• 🛡️ работает в рамках правил платформ, не создавая аномалий.

Что это дало на практике 📊

Самое интересное — эффект оказался не столько техническим, сколько продуктовым.

• ✅ Конверсия откликов выросла — потому что система стала бить не по площади, а в цель;

• ✅ Пользователи перестали вмешиваться вручную — ассистент стал предсказуемым;

• ✅ В среднем освобождается 10–15 часов в неделю, которые раньше уходили на рутину.

Именно здесь стало понятно, что мы движемся в правильном направлении 🚀

OfferMate 2.0: не «автоматизация всего», а умное делегирование 🧩

Этот подход лёг в основу новой версии продукта, которую мы сейчас допиливаем.

В OfferMate 2.0 мы сознательно ушли от идеи «пусть ИИ делает всё» и сфокусировались на том, где он действительно полезен:

• 🤖 анализ резюме и вакансий с учётом контекста, а не ключевых слов;

• ✍️ генерация сопроводительных писем под конкретную компанию;

• 🛡️ нативное и естественное взаимодействие с платформами;

• 📈 прозрачная аналитика и контроль со стороны пользователя.

Отдельно экспериментируем с новыми функциями — например, автоматизацией типовых онлайн-тестов. Но здесь действуем максимально осторожно и итеративно.

Итоговые мысли 🧠

Автоматизация ради автоматизации почти всегда приводит к хрупким решениям.
А вот автоматизация, которая копирует человеческую логику и ритм, — работает долго и стабильно. К этому мы и идем.

И да, если интересно следить за развитием проекта, архитектурными находками и экспериментами — я регулярно пишу об этом в блоге.

👉 https://t.me/offermatecrew

Там же делимся апдейтами OfferMate 2.0 и результатами тестирования.
Буду рад вопросам и обсуждению в комментариях 👇

Не пользуюсь LLM-агентами, если могу. Давно замечаю: просто избегаю запускать LLM прямо в проекте, потому что боюсь разучиться кодить и думать. Поход в ChatGPT себе разрешаю — это как встать с дивана, чтобы пойти в магазин, а не заказывать доставку на дом. Там нужно правильно сформулировать запрос, потому что он не может добрать контекст проекта сам. Можно перекинуться парой мыслей, как с товарищем на работе. Надо подумать, как применить ответ, что выкинуть. В итоге я всё равно как-то худо-бедно программирую сам.

Пока я отрицаю прогресс, из мира агентов доносится много шума про управление контекстом и токенами. Агенты в ответ на запросы жрут лимиты по токенам, выделенные на отрезок времени. Ну либо запросы по API просто тарифицируются. Причем чем дольше общаешься с нейросетью, тем больше контекста ей нужно держать, учитывать, корректировать, сжимать. Помимо этого, нейронка ещё подглядывает правила проекта в .md-файлах, что-то помнит между переписками.

Чем больше у нейронки пузырь вашего контекста, тем хуже она работает. Путается в постоянно пополняющихся правилах, корректировках и ограничениях. Наконец, контекстный оверхед — это еще очень дорого. Каждый запрос к API содержит тысячи «мусорных» токенов и выжирать лимиты получается еще быстрее.

В ответ на это индустрия на венчурные деньги придумывает и продвигает свои «велосипеды», чтобы с помощью агентов эффективнее и дешевле решать задачи:

• В Cursor IDE есть Rules, которые накладывают ограничения поверх ваших промптов. Их можно применять вручную или автоматически; говорят, автомат работает хуже.

• Anthropic пиарит Skills (еще пример Playwright Skill). Это интерфейс для решения типовых задач с адаптивными ступенями контекста в зависимости от сложности.

• Есть MCP (Model Context Protocol) — условное API, которое расширяет возможности агентов, чтобы они не писали собственные инструменты и не тратили контекст и токены на типовые задачи: открыть браузер, прочитать Jira, отправить письмо и т. д.

• Также есть субагенты; их оркестрирует агент-оркестратор. У субагентов чистый контекст: они получают задачу, выполняют её и идут на «свалку».

И вот среди этого новояза я – старпер со своим ChatGPT: после 2–3 запросов удаляю чат и начинаю новый. Вот моя экономика токенов и галлюцинаций. Меня и Альтмана маркетингом не проведешь!

RAG vs Fine-tuning: что выбрать для бизнес-данных

 RAG даёт актуальные данные, Fine-tuning — застывшие знания

Задача: сделать Telegram-бота для сотрудников, который отвечает на вопросы по внутренним регламентам, инструкциям и политикам компании.

Первый вопрос: fine-tuning или RAG?

Fine-tuning отпал сразу

• Регламенты обновляются — новая политика отпусков, изменения в ДМС, новый регламент согласований. Переобучать модель каждый раз?

• Нужны точные ссылки — "это написано в п.3.2 Положения о командировках", а не "примерно так заведено"

• Галлюцинации опасны — бот не должен выдумывать правила, которых нет

• Конфиденциальность — отправлять внутренние документы в OpenAI для fine-tuning?

RAG решил все проблемы

• Обновил документ = бот уже знает — без переобучения

• Прозрачность — бот показывает источник: "согласно Положению о ДМС, раздел 4..."

• Данные внутри периметра — эмбеддинги можно считать локально

• Контроль — легко добавить/удалить документы из базы знаний

Типичные вопросы к боту

"Сколько дней отпуска у меня по ТК?"
→ Ответ + ссылка на Положение об отпусках
"Как согласовать командировку?"
→ Пошаговая инструкция + ссылка на регламент
"Что покрывает ДМС?"
→ Перечень услуг + ссылка на договор

Когда что выбирать

КритерийRAGFine-tuningДокументы обновляются✅❌Нужны ссылки на источник✅❌Конфиденциальные данные✅⚠️Специфичный тон ответов➖✅Быстрый MVP➖✅

Мой вывод

Для корпоративной базы знаний — однозначно RAG.

Fine-tuning оправдан, если:

• База знаний статична (редко меняется)

• Не нужны ссылки на источники

• Важен уникальный стиль общения бота

А как вы решаете задачу корпоративного бота? RAG, fine-tuning, или готовые решения типа Notion AI?

Про воркеры простыми словами

На работе мне понадобилось реализовать воркер. Описываю, как сам эту тему разобрал.

Воркер — это сервис, который ждёт событие-триггер и по нему выполняет некий коллбэк. В отличие от фоновых задач в вашем сервисе, воркер живёт в отдельном контейнере.

Пример
Сборщик мусора в БД: пройтись раз в час, например, и удалить старые записи. Или, как у меня задача на работе: обработать xlsx-файл, который передали в ручку.

Зачем
Чтобы сделать работу приложения асинхронной. Представим задачу, которую можно обработать дольше, чем за 10 секунд. Клиент на вашем сайте не будет сидеть и смотреть в экран эти 10 секунд. Он перезагрузит страницу, сессия прервётся, и задача не выполнится. Или веб-сервер вернёт клиенту таймаут. В описанном сценарии обработка запроса — синхронная процедура. Она плохо подходит для быстрых веб-сервисов. А вот асинхронная обработка: кинули запрос, получили ответ 200 OK и пошли чилить, пока задача исполняется — это то, что нужно. Воркер как раз для этого.

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

Триггеры
Триггерами для воркера могут быть:

• крон

• таймер

• событие

Очереди
Воркеры по событию обычно подписаны на очередь. В моём случае это как раз Redis Queue (библиотека rq, например https://python-rq.org/ ). Запрос в ручку получает 200 OK. Мой сервис создаёт запись в БД типа «задача id такой-то, статус processing» и публикует событие в очереди. Воркер забирает событие, чтобы другие воркеры не могли задачу задублировать, и пробует выполнить свой коллбэк. Если всё ок, воркер пишет в БД данные по выполненной задаче и подтверждает в очереди прочтение события. Иначе воркер может ретраить, может завалить задачу и вернуть её в очередь, а может и сам упасть.

Воркер-пул
Воркеров может быть несколько. Они могут выполнять как несколько разных задач, так и одну вместе. Увеличение числа воркеров требует оркестрации и иногда для этого также выделяет контейнер с оркестратором. Воркеры могут передавать задачи друг другу. Могут конкурировать за задачи, если очередь организовать неправильно. А могут вообще читать разные потоки и быть никак не связаны друг с другом.

Накладные расходы
Чем сложнее слой с воркером, тем больше необходимость следить за их хелсчеками. В отличие от вашего сервиса, воркер может тихо упасть. Ваш сервис отдаёт 200, а по факту задачи не отрабатывают. Так что воркеры накладывают дополнительные накладные расходы: связанность, обработка ошибок, логирование, алерты, ретраи, рестарты подов и т. д.

Образ
Воркер собирается из того же образа, что и ваше приложение, но у него отдельный энтри-поинт. Вместо запуска через main.py у, например, worker.py, есть строчка вида:

def main():

    ... # Какая-то логика по инициализации воркера и очереди

if name == '__main__': 

    main() # Если запускают этот модуль напрямую, выполни команду main()

Из-за этого кода модуль можно вызвать напрямую python -m app.worker. В main(), как правило, скрыта логика какого-то while-true цикла и шатдауна на случай завершения работы воркера.

🎣 14 собесов за неделю благодаря КАРАСЮ — и да, вам не показалось)

Привет, Хабр.

Сразу скажу, про карася расскажу ниже, сначала немного контекста)
Недавно я писал о том, как мы с командой пытаемся решить инженерную задачу под названием «поиск работы». Проблема знакома многим: квалифицированные специалисты тратят сотни часов на рутину — пролистывание лент, однотипные отклики, формальные сопроводительные. Цикл повторяется с каждым новым поиском.

Тогда мы решили посмотреть на это как на систему: входные данные (резюме), правила сопоставления (вакансии), повторяемые действия (отклики) — и автоматизировать то, что не требует креатива. Так родился OfferMate 1.0.

🚀 Что получилось в первой версии

Мы создали ассистента, который:

• 🔎 Искал вакансии на hh.ru и в Telegram-каналах.

• 🤖 Автоматизировал отклики через официальное API.

• ✍️ Генерировал сопроводительные письма, анализируя резюме и требования вакансии.

• ⚙️ Работал в фоне, экономя пользователям до 10-15 часов в неделю.

Мы набрали несколько сотен активных пользователей. И получили огромное количество фидбеков и результатов, одним из которых поделюсь

🎯 Эксперимент «Карась» и неожиданный результат

Чтобы протестировать систему на реальной нагрузке, мы запустили в блоге условный «челлендж»: попросили желающих оставить в комментариях слово «КАРАСЬ». Это был сигнал для подключения к бета-тесту.

Результаты нас ошеломили. Один из «карасей» поделился статистикой: за 5 рабочих дней — 18 откликов от HR, 9 скринингов и 5 технических собеседований. И при этом это был не единичный случай! Мы получили несколько подобных фидбеков и увидели, что система реально работает и приносит результаты. А также получили огромный заряд мотивации. 💥

⚡️ Переворотный момент

Но за быстрым успехом пришли тревожные новости. HH ограничили способы взаимодействия с платформой и нам пришлось искать обходные пути...

🏗️ OfferMate 2.0: фундамент на годы вперёд

И пока все наслаждались новогодними праздниками, наша команда копалась в деталях. Мы не стали наращивать «костыли» на старую архитектуру, а начали строить новый фундамент.

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

Грубо говоря, мы учим систему «работать руками» пользователя)

✨ Что в итоге мы реализовали в 2.0?

• 🛡️ Абсолютная стабильность. Больше никаких внезапных остановок из-за изменений на стороне площадок.

• ⚙️ Полная автоматизация рутины. Система может автономно управлять всем циклом: поиск → подъём резюме → отклик → отслеживание статусов.

• 🎭 Глубокая оптимизация сопроводительных писем под культуру конкретной компании.

• 🧠 Автоматизация прохождения типовых онлайн-тестов (New)

• 📊 Централизованные уведомления со статистикой (New)

⏱️ Когда запуск и как попасть в 2.0

Сейчас мы на стадии закрытого бета-тестирования и готовимся к релизу нашего продукта.

Самый сложный технологический этап пройден. Сейчас мы интегрируем новую логику в бота и проводим стресс-тесты под нестандартными сценариями.

Хотим всё хорошо оттестировать и ворваться в новый сезон найма, чтобы разрывать его вместе с вами! 💥

Публичный запуск планируем в конце января. 🗓️🎄

❗️Чтобы обеспечить качество, мы откроем только 100 слотов на 3 дня. 

Это осознанное решение для контроля нагрузки и получения концентрированной обратной связи.

Мы хотим, чтобы OfferMate 2.0 вышел не «сырым анонсом», а готовым инструментом, которому можно доверить карьерный маневр.

🤝 Как поучаствовать

Присоединиться к запуску и поучаствовать в тестировании — можно будет в нашем Telegram-канале: https://t.me/offermatecrew
Мы приглашаем сообщество Хабр помочь нам в разработке лучшего ИИ-ассистента для поиска работы!

P.S. В комментариях готов подискутировать на тему пользы автоматизированных откликов и ответить на технические вопросы 👇

Представлен открытый проект MatrixDefender-4.2, который помогает убрать майнеры на ПК или ноутбуке, а также различные сетевые угрозы и прочий мусор. Сервис написан на Python, устанавливается за пару кликов. Проект находит и удаляет майнеры, лечит от LimeRAT, QuasarRAT и другие угрозы, блокирует С2-сервервы, которые управляют атаками на ПК.

Представлен короткий курс с основами Python с помощью реальных примеров и сценариев, которые делают обучение лёгким и увлекательным.

Kotlin и Hyperskill: как я искал курс и что получил в итоге.

Когда я решил изучать Kotlin, ожидал, что найти хороший курс будет просто: язык популярный, используется в Android и бэкенде, вокруг много материалов. Искал менторов и упирался в людей которые знаю java и вроде как используют в работе Kotlin. Это одновременно пугало и заинтересовывало, я решил поступить как мне казалось правильным, найти готовый курс  — особенно если хочется не “смотреть видео”, а именно учиться через практику и задачи.

Я перепробовал разные форматы обучения (платные и бесплатные), поэтому в этот раз подход был простой: найти платформу, где есть структурированная программа и много практики. В итоге я добрался до Hyperskill (hyperskill.org). Это не реклама — просто личный опыт, кому-то он может сэкономить время.

Как я пришёл к ресурсу.

Изначально искал курсы по Kotlin на привычных площадках. На Stepik в тот момент не нашёл того, что мне подходило по структуре (возможно, сейчас ситуация лучше). Видео-курсы на крупных “известных сайтах” сознательно не рассматривал: мне удобнее формат “прочитал → сделал → получил проверку”.

Дальше — обычный путь через поисковик и сравнение нескольких платформ. Из того, что выглядело цельно и практично, больше всего зацепил Hyperskill. Отдельно сыграло роль то, что платформа связана с JetBra…. (то есть ребята явно понимают, как устроена экосистема вокруг Kotlin и IDE).После регистрации быстро становится понятно: платформа активно ведёт к подписке.Раньше в сети встречались статьи про возможность оформить бесплатную подписку на полгода, но это устаревшая информация — сейчас такой опции нет (по крайней мере, в том виде, в каком её описывают старые гайды).

При этом у Hyperskill есть бесплатный режим, и я проходил курс именно так.

Что я проходил: Introduction to Kotlin.

На платформе несколько треков по Kotlin, я начал с Introduction to Kotlin. По ощущениям, это “введение с практикой”:

• около 9 учебных проектов

• порядка 60–70 тем

• внутри тем — задачи/тренажёры с автоматической проверкой

В целом структура понравилась: материал подаётся дозировано, и почти сразу закрепляется практикой. Похожая на Степик.

Система “кристаллов” и лимиты.

Самая спорная часть бесплатного режима — ограничения на попытки.

У Hyperskill есть внутренняя валюта (“кристаллы”): ошибаешься в заданиях — кристаллы списываются. Когда кристаллы заканчиваются, обучение может блокироваться на 12–24 часа. Да, кристаллы можно зарабатывать активностью и выполнением некоторых задач, но при активном обучении и регулярных ошибках (что нормально) этого может не хватать.

Подписка проблему снимает, но именно этот момент сильнее всего влияет на комфорт обучения в бесплатном режиме.

Проекты: что внутри и зачем это полезно.

Сильная сторона Hyperskill — проекты. Они не выглядят как “игрушки ради галочки”, а позволяют постепенно потрогать основные конструкции языка.

Из того, что запомнилось:

• “Сапёр”

• “Крестики-нолики”

• “Чат-бот”

• “Кофемашина”

Например, в проекте “кофемашина” уже нормально используются циклы, классы и базовые элементы ООП. В таком формате проще понять, “зачем оно нужно”, чем на изолированных задачках.

Минус: часть проектов закрыта платной подпиской, и это немного обидно — именно проекты дают максимальную пользу и ощущение прогресса.

Проверка решений: не всегда понятно, почему “не принято”

Ещё один недостаток — качество обратной связи в тестах. Иногда тесты “падают” так, что ты видишь только факт ошибки, но не понимаешь причину: что именно ожидалось, на каком кейсе сломалось, где расхождение.Часть проектов проверяется через IntelliJ IDEA, и здесь иногда всплывают технические нюансы: несовпадение версий, необходимость обновить IDE или компилятор, странные падения на конкретном проекте.

Хороший момент: поддержка отвечает. По моему опыту, вопросы не игнорируют, и проблемы реально разбирают.

Итоги:

• бесплатный режим может раздражать лимитами на ошибки (кристаллы и блокировки)

• часть контента (включая проекты) закрыта подпиской

• обратная связь тестов местами недостаточно информативная

  Если готовы, то вперед!

Открытый проект iCloud Photos Downloader на Python позволяет в командной строке выполнять загрузку фотографий из iCloud. Работает в Linux, Windows и macOS; на ноутбуках, настольных компьютерах и сетевых накопителях. Решение доступно в виде исполняемого файла для прямой загрузки и через менеджеры пакетов /экосистемы (Docker, PyPI, AUR, npm).

Возможности решения:

• три режима работы:

  • копирование - загрузка новых фотографий из iCloud (режим по умолчанию);

  • синхронизировать - загружать новые фотографии из iCloud и удалять локальные файлы, которые были удалены в iCloud (опция автоматического удаления);

  • переместить - загружать новые фотографии из iCloud и удалять фотографии в iCloud (опция сохранить в icloud за последние дни).

• поддержка Live Photos (изображения и видео в виде отдельных файлов) и RAW-изображений (включая RAW + JPEG);

• автоматическое удаление копий фотографий с одинаковыми названиями;

• однократная загрузка и возможность постоянного отслеживания изменений в iCloud;

• оптимизация для инкрементных запусков (параметры --until-found и --recent);

• обновления метаданных фотографий (EXIF) (опция --set-exif-datetime).

HR, простите, но у меня не было выбора - Как я потратил несколько сотен часов на ИИ-ассистента для поиска работы

Привет, Хабр.

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

Кандидатов фильтруют автоматические системы, отклики закрываются автоотказами, при этом от соискателя ожидается ручная и максимально персонализированная работа: десятки однотипных откликов и сопроводительных писем.

В какой-то момент я понял, что трачу больше времени на клики и формальные действия, чем на развитие как инженера. Это и стало отправной точкой.

Что не так с процессом поиска

Проблема не в самом поиске, а в том, как он реализован.

1. Массовая рассылка вместо выбора.
Осознанный подбор вакансий быстро превращается в пролистывание списков и надежду на статистику.

2. Отклики как механика.
Сопроводительные письма отличаются формально: поменять название компании, чуть переписать вводную — и так десятки раз.

3. Неэффективные затраты времени.
Квалифицированный специалист тратит часы на задачи с минимальной ценностью, причём этот цикл повторяется при каждом новом поиске.

Инженерный взгляд

Если абстрагироваться, поиск работы — это:

• входные данные (резюме, требования вакансии),

• правила сопоставления,

• повторяемые действия,

• измеримые результаты.

С инженерной точки зрения — кандидат на автоматизацию.
Так появилась идея проекта OfferMate, который берёт на себя рутинную часть процесса.

Коротко о разработке

Проект мы начали с друзьями, столкнувшимися с той же проблемой.

Довольно быстро стало понятно, что задача сложнее, чем кажется:
нестабильные источники, антибот-механизмы, разные форматы вакансий, неоднородные данные.

За 4+ месяца разработки мы:

• несколько раз пересобрали архитектуру,

• получили жёсткий фидбек,

• убедились, что это не история про «просто прикрутить LLM».

Технические детали осознанно опускаю — при интересе разберу отдельно.

Что получилось в итоге

Сейчас OfferMate — это ассистент, который:

• ищет релевантные вакансии на hh.ru и в Telegram,

• автоматизирует отклики,

• формирует сопроводительные письма под конкретные вакансии,

• работает в фоне, минимально вовлекая пользователя.

Им пользуются кандидаты разного уровня — от начинающих до опытных специалистов.

Про сопроводительные письма

Корректнее говорить не «ИИ пишет письма», а что система:

• анализирует резюме,

• разбирает требования вакансии,

• ищет пересечения,

• и на их основе формирует текст.

Это не делает письмо идеальным, но делает его релевантным, что на практике влияет на отклик.

Куда дальше

Сейчас мы работаем над следующей версией проекта.

Рынок нестабилен: ограничения и API меняются, поэтому тестируем архитектуру без жёсткой зависимости от официальных интерфейсов и с упором на устойчивость.

Вместо вывода

Этот пост — попытка взглянуть на поиск работы как на инженерную задачу и попробовать решить её соответствующими методами.

Если интересно последить за проектом, все новости публикуем в этом Tg-канале:

👉 https://t.me/offermatecrew

Также буду рад вопросам и обсуждению в комментариях.
Если тема зайдёт — сделаю отдельный технический разбор.

Шаблонный сервис

Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.  

Давно хотел написать пост о важности шаблонного сервиса, но не было хорошего примера под рукой. И тут мой коллега выложил наш шаблонный сервис на FastAPI, который мы долгое время использовали и развивали.

Так зачем же нужен шаблонный сервис?

Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.

Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.

Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.    

Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.     

Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)    

Онбординг на кошечках. Новый человек сначала изучает шаблонный сервис, понимает подходы, а потом уже ныряет в боевые системы.

Просто экспериментировать. Создал веточку от шаблона – и прикручиваешь свою новую махарайку, не тратя время на базовую структуру.

Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.

Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.

Мы активно использовали шаблонный сервис в микросервисной архитектуре, но и для монолитных решений он тоже отлично зашёл – стартовали с ним несколько проектов.

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

В общем – заходите, смотрите, ставьте звездочки. И если с чем-то не согласны – пишите в комменты, автор обязательно ответит 🙂

Учим Python — представлен интерактивный учебник, который работает прямо в браузере. Он поможет освоить базу буквально за пару месяцев:

• Больше 100 заданий — основы для понимания основных концепций языка, беглого кодинга программ и выстраивания логики сервисов.

• Примеры кода — не просто теория, анужно решать задачи сразу после прочтения материала.

• Есть текстовые материалы, вшитые YouTube-уроки, задачи, дополнительные лекции и контрольные вопросы.

Раздолбайский дух Sanic.

5 случаев, когда Fine-tuning лучше RAG

Все говорят "RAG для всего". Но есть кейсы, где fine-tuning выигрывает — и это не только про статичные данные.

1. Жёсткий формат вывода

Бот для CRM должен всегда возвращать:

{"name": "...", "phone": "...", "intent": "..."}

RAG не гарантирует формат. Fine-tuning — да. Модель "запоминает" структуру на уровне весов.

2. Доменный жаргон

Врач пишет: "в/в капельно NaCl 0.9% 400мл". Юрист: "п.1 ч.2 ст.158 УК".

RAG найдёт документ, но не научит модель "говорить на языке". Fine-tuning встраивает терминологию в модель.

3. Логика без документов

Расчёт стоимости доставки: вес, габариты, зоны, сезонность, тип клиента — 20 переменных.

Это не в документе, это в голове логиста. Fine-tuning переносит экспертизу в модель.

4. Стиль эскалации

Банковский бот не должен говорить "не знаю". Только: "Уточню у специалиста, ожидайте".

RAG учит контенту, fine-tuning — поведению и тону.

5. Скорость

RAG: эмбеддинг → поиск → генерация = 3 вызова, ~2 сек.

Fine-tuned модель: 1 вызов, ~0.5 сек.

Для голосового бота или real-time чата — критично.

Когда всё же RAG: данные часто меняются, нужны ссылки на источник, конфиденциальность.

Гибрид работает: fine-tuning для формата и стиля + RAG для актуальных данных.

А вы где использовали fine-tuning?

пет-проект невозможно доделать - только выпустить в открытую бету

Что ж, встречайте открытую бету проекта

📚📚📚📚📚📚📚📚📚📚
SweetReader!
📚📚📚📚📚📚📚📚📚📚

Что это:
Пространство для авторов и читателей, упор сделан на книги с высоким уровнем визуала (графические романы, комиксы, манги, книги с упором на иллюстрации). 

Преимущества:
Три настраиваемых режима просмотра книг, поиск и фильтры по произведениям, лайки, избранные, страницы авторов и всё в этом духе.

На текущий момент это MVP - буквально базовая версия продукта, есть планы по его доработке и даже (о, ужас) "дорожная карта", которую, может быть, я реализую )))

_____

Должен упомянуть, что автор идеи и базового дизайна, которые я впоследствии доработал - Семён Диваченко.

Буду рад обратной связи тут в комментариях. Если найдёте баг или ошибку (а это на текущей стадии несложно), в меню есть кнопка "Ошибка?" специально для неравнодушных пользователей.

Обновлён проект Python Scripts, где более 60 Python-скриптов для любых задач, включая алгоритмы по парсингу, работе с видео и фото, клонированию сайтов, скачиванию с сайтов и другие популярные решения.

Ранее был представлен учебный проект «Числа Python, которые должен знать каждый программист» (Python Numbers Every Programmer Should Know). Проект также доступен на GitHub.

Представлен учебный проект «Числа Python, которые должен знать каждый программист» (Python Numbers Every Programmer Should Know). Проект также доступен на GitHub.

«Существуют цифры\числа\значения, которые должен знать каждый программист на Python. Например, насколько быстро или медленно добавляется элемент в список в Python? А как насчёт открытия файла? Это занимает меньше миллисекунды? Есть ли что‑то, что замедляет этот процесс? Если у вас есть алгоритм, чувствительный к производительности, какую структуру данных следует использовать? Сколько памяти занимает число с плавающей запятой? А как насчёт одного символа или пустой строки? Насколько быстр FastAPI по сравнению с Django? Я хотел бы уделить немного времени и записать показатели производительности, специально ориентированные на разработчиков Python», — сообщил автор проекта Майкл Кеннеди.

Тестирую Claude Code на написание белых модов к игре.

Процесс: обсуждение, сбор данных по структуре игры и установке модов, написание кода и деплой.

С первым модом для WoT справился. Тестирую дальше. Кому-то полезна будет потом информация о процессе, выкладывать или лишнее?