Python *

Открытый учебный проект 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 - буквально базовая версия продукта, есть планы по его доработке и даже (о, ужас) "дорожная карта", которую, может быть, я реализую )))

_____

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

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