Из чего это собрано

В основе — Playwright, библиотека для управления браузером из кода. По сути это тот же браузер, что открывается у тебя на компьютере, только им управляет скрипт: он умеет кликать, скроллить, читать текст со страницы, заполнять формы. Я специально запускаю его не в headless-режиме, а с видимым окном — так проще заметить, если что-то пошло не так, и вручную вмешаться.

Для распознавания «подходит вакансия или нет» используется та же связка, что и в телеграм-версии — локальная модель через Ollama. Ключевые слова и правила фильтрации вынесены в отдельный файл filters.txt, чтобы не лезть в код каждый раз, когда нужно подправить список профессий. Модель получает текст вакансии и по инструкции решает: да, подходит, вот название должности — или нет.

Как проходит один цикл

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

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

Дальше идёт проверка на «вакансию с тестом» — на hh.ru часто вместо обычного отклика просят сначала пройти тестовое задание или ответить на вопросы прямо на странице. Такие вакансии скрипт узнаёт по характерным фразам в описании вроде «пройти тест» или «заполните анкету», а также по слову question в самой ссылке. Если это тестовая вакансия — скрипт помечает её как обработанную, но вкладку намеренно не закрывает, чтобы я потом мог сам вручную пройти тест, если вакансия того стоит. Автоматизировать прохождение произвольных тестов — идея так себе, там слишком много нестандартного.

Если тестов нет, весь текст страницы отправляется в модель на вердикт. Если ответ отрицательный, вакансия просто помечается пройденной и скрипт идёт дальше. Если положительный — начинается самое интересное.

Автоматический отклик

Скрипт ищет кнопку отклика на странице, кликает по ней, и дальше по цепочке разбирает возможные всплывающие окна: предупреждение про переезд в другой город («Всё равно откликнуться»), выбор резюме из списка, если их несколько, поле для сопроводительного письма. Письмо берётся не из головы модели, а из заранее заготовленных шаблонов в файле templates.txt — они чередуются по кругу через itertools.cycle, чтобы не заваливать разных работодателей одинаковым текстом слово в слово. После заполнения скрипт нажимает «Отправить» и записывает результат.

Каждый успешный отклик попадает в Excel-таблицу — через pandas дописывается строка с названием вакансии, компанией, ссылкой, статусом и датой. Получается что-то вроде личного трекера откликов, который ведётся сам, без единой лишней вкладки Google Sheets.

Мелочи, которые оказались важны на практике

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

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

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

В какой-то момент я решил, что раз я умею писать код, глупо продолжать заниматься этим руками. Так появился скрипт, который я в шутку назвал stalker.py — он действительно «выслеживает» вакансии по каналам, только не человека, а посты нужного профиля.

Что он вообще делает

Логика простая, если разложить по шагам. Скрипт подключается к моему телеграм-аккаунту через Pyrogram — это библиотека, которая позволяет работать с Telegram API как с обычным пользователем, а не через бота. Разница важна: боту нельзя просто так читать историю каналов, на которые он не подписан от имени владельца, а через юзер-аккаунт — можно, если ты сам туда вступил.

Дальше он проходит по списку каналов из файла channels.txt и смотрит последние сообщения. Есть два режима глубины поиска: если скрипт запустился утром, между 11:40 и 11:59, он сканирует последние 15 часов — то есть подчищает всё, что накопилось за ночь. В остальное время смотрит только последний час. Это запускается через cron или планировщик — сам скрипт не крутится в фоне постоянно, а стартует по расписанию, делает свою работу и завершается.

Фильтрация в два прохода

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

Поэтому первым делом идёт грубый фильтр по ключевым словам. Список стоп-слов (GARBAGE_KEYWORDS) отсекает явно нерелевантные посты сразу, без всякого ИИ — просто проверка вхождения подстроки. Отдельно отсекаются резюме — по фразам вроде «меня зовут» или «ищу проекты», потому что это не вакансия, а чьё-то самопродвижение. И только если пост прошёл эти фильтры и в нём встретилось хоть одно слово из списка нужных тем (3D, motion, Cinema 4D, Houdini, Redshift и так далее), он попадает на следующий этап.

Второй этап — локальная модель. Скрипт стучится в Ollama, который крутится на том же компьютере на порту 11434, и просит модель gpt-oss:20b вынести финальный вердикт: подходит вакансия под профиль 3D/motion-дизайнера или нет. Тут смысл в том, что ключевые слова — штука грубая, они ловят и ложные срабатывания («ищем UI/UX дизайнера с опытом в 3D-иконках» тоже пройдёт по словам). Модель уже смотрит на контекст и отсеивает то, что формально совпало, но по сути не подходит.

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

Что происходит с найденным

Если модель говорит «да», скрипт формирует короткую карточку — заголовок вакансии, название канала, ссылка на пост (или пометка «Private Link», если у канала нет юзернейма) и обрезанное описание — и отправляет всё это самому себе в Telegram, в «Избранное». Получается что-то вроде личной ленты уже отфильтрованных вакансий, куда можно просто иногда заглядывать вместо того, чтобы шерстить два десятка каналов.

Чтобы не присылать одно и то же дважды, есть простейшая база данных — обычный текстовый файл sent_tasks.txt, куда пишется уникальный идентификатор сообщения (айди чата плюс айди поста). Перед обработкой скрипт проверяет, нет ли такого идентификатора уже в файле. Никакой базы данных в полном смысле слова тут не нужно — задача маленькая, и текстовый файл справляется без проблем.

Почему так, а не иначе

Можно было бы сделать то же самое через официальный Bot API, но тогда пришлось бы добавлять бота в каждый канал отдельно, а часть каналов админы просто не пустят. Через юзер-сессию эта проблема снимается — если я сам состою в канале, скрипт может читать историю переписки.

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

Скрипт на Python для Cinema 4D, заменяющий ручной перебор десятков комбинаций «профиль × наполнитель × поддон × угол × материал» единым GUI-инструментом с автоматическим сопоставлением файлов и пакетным рендером.

Контекст и задача

Проект выполнен для компании «Техностиль», занимающейся изготовлением стеновых и кровельных сэндвич-панелей (профилированный металлический лист + утеплитель). Отдел визуализации использует Cinema 4D для генерации PNG-иконок каждого профиля панели, наполнителя (утеплителя — минвата/пенополистирол/PIR-PUR) и поддона — эти изображения затем используются в веб-конфигураторе продукции на сайте компании, где клиент собирает панель нужной комплектации «по кубикам».

До автоматизации 3D-художнику приходилось вручную для каждой единицы номенклатуры: подгружать нужный .ai-файл контура профиля панели, переключать видимость слоёв в сцене, выставлять углы стыковки (90°/135°), задавать материал утеплителя (вата/пенополистирол/PIR-PUR), запускать рендер и раскладывать PNG по правильным папкам. При десятках профилей и наполнителей это часы монотонной ручной работы и источник ошибок в путях сохранения.

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

Технологический стек

—  Python (Cinema 4D Python API — модуль c4d)

—  c4d.gui.GeDialog — кастомные модальные GUI-диалоги (чекбоксы, группы, кнопки)

—  c4d.documents.RenderDocument + MultipassBitmap — программный рендер и сохранение PNG с альфа-каналом

—  User Data сцены (ID_USERDATA) — как «пульт управления» видимостью объектов и назначением текстур из скрипта

—  os / файловая система — сканирование, парсинг имён файлов, построение путей сохранения

Архитектура решения

Скрипт построен вокруг одного управляющего объекта сцены RENDER_CONTROL, чьи User Data-параметры выступают интерфейсом между Python-кодом и содержимым 3D-сцены: путь к .ai-файлу контура, путь к файлу наполнителя, путь к поддону, набор булевых «выключателей видимости» (профиль/вата/поддон, замки LZ/PR/PZ, matte-параметры торцов lw/pw) и переключатели угла. Это классический паттерн «оживления» статичной сцены данными снаружи — сцена не меняется, меняются только входные параметры перед каждым рендером.

Логика выполнения делится на пять последовательных этапов:

—  Выбор угла раскроя (90° / 135° / без угла) — через нативный c4d.gui.ShowPopupDialog.

—  Выбор материала наполнителя (VATA / POLY / PIR) — с автоматическим подбором материала сцены по имени и donастройкой UV-тайлинга текстуры под конкретный материал.

—  Выбор логического режима рендера (всё вместе, весь профиль, LZ/PR/PZ по отдельности, только наполнитель, только поддон).

—  Сканирование каталога источника, разбор имён .ai-файлов и группировка через собственные GUI-диалоги (ProfileSelectDialog, NapolnitelSelectDialog).

—  Цикл рендера: для каждой выбранной позиции скрипт выставляет нужную комбинацию «переключателей» через set_all_switches(), инициирует пересчёт сцены и рендерит кадр в вычисленную по правилам папку.

Ключевые инженерные решения

Самодокументируемый диспетчер состояний сцены

Функция set_all_switches() — сердце скрипта. Вместо разбросанных по коду присвоений она собирает все восемь переключателей сцены (видимость профиля/ваты/поддона, три типа замков, два matte-флага торцов) в одну именованную сигнатуру с понятными умолчаниями и докстрингом, объясняющим смысл каждого флага. Любой следующий разработчик может понять логику состояния сцены за 10 секунд, не читая C4D-документацию.

Эвристический парсер и «спаривание» файлов

Файлы поставляются с говорящими, но не строго стандартизированными именами (profil_lz.ai, napolnitel_lz pirpur.ai и т.п.). Функция find_paired_file() очищает префикс и расширение, нормализует регистр и пробелы/подчёркивания и ищет по «чистому» имени соответствующий файл наполнителя или поддона для текущего профиля — с поддержкой суффикса материала (например, pirpur), который отличает, скажем, наполнитель под PIR-PUR от такого же наполнителя под вату.

Собственные GUI-диалоги с группировкой по смыслу

Вместо стандартного системного диалога «выбери файлы» реализованы два кастомных c4d.gui.GeDialog:

—  ProfileSelectDialog — список профилей, автоматически разделённый на «обычные» и «замковые» (по суффиксу _z), с кнопками «Выбрать все» / «Снять все».

—  NapolnitelSelectDialog — трёхколоночный диалог наполнителей (без префикса / группа Z / группа VENT) с быстрыми фильтрами «только Z», «только VENT» и т. д., чтобы не листать десятки чекбоксов вручную.

Оба диалога используют единый приём: диапазон ID чекбоксов (CHECK_BASE) плюс индекс в объединённом списке, что позволяет одной строкой восстановить, какие позиции пользователь отметил, без хранения отдельного состояния на каждый чекбокс.

Предсказуемая структура сохранения результатов

Путь сохранения PNG собирается динамически из нескольких независимых переменных: базовая папка → флаг «замки» → тип объекта (profil/napolnitel/poddon) → материал наполнителя → подпапка угла (90°/135°). Такой подход гарантирует, что структура папок веб-конфигуратора всегда предсказуема и не зависит от порядка выбора пользователем — а для повторяющегося поддона (одинакового для группы профилей) отдельный флаг poddon_rendered_once исключает лишние дубли рендера.

Защита от «пустого» рендера

Перед каждым фактическим рендером сцена дважды прогоняется через wait_for_scene() (ExecutePasses + GeSyncMessage), чтобы Cinema 4D успела пересчитать зависимые генераторы и текстуры после смены User Data — иначе первый кадр в серии рискует захватить ещё не обновлённое состояние сцены. Это распространённая, но неочевидная проблема программного рендера в C4D, решённая явным ожиданием синхронизации.

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

—  находит парный файл наполнителя под PIR-PUR и рендерит его отдельным проходом с другим набором переключателей видимости;

—  рендерит поддон один раз на группу профилей без замков;

—  сохраняет все PNG по маршруту вида .../zamki/profil/uglovie/135°/... и по завершении открывает соответствующие папки в проводнике.

Итог

Скрипт превращает многочасовую рутинную задачу подготовки графики для конфигуратора в управляемый процесс из нескольких кликов: 3D-художник задаёт только высокоуровневые параметры (угол, материал, что рендерить), а сопоставление файлов, переключение состояний сцены, построение путей и пакетный рендер выполняются автоматически и воспроизводимо.

С инженерной точки зрения работа демонстрирует практическое владение Python-интеграцией со сторонним DCC-приложением (Cinema 4D SDK), проектирование пользовательских GUI поверх непривычного тулкита, устойчивый к вариативности входных данных парсинг имён файлов и аккуратную декомпозицию сложной ветвящейся логики (шесть режимов рендера) на переиспользуемые функции.

Контекст и решаемая задача

Комплекс скриптов написан на JavaScript / ExtendScript для автоматизации повседневных рутинных операций в Adobe Illustrator. Набор инструментов полностью убирает человеческий фактор при предпечатной подготовке (prepress), построении модульных сеток, выравнивании элементов и адаптивном экспорте.

Ключевые показатели эффективности:

• В 10–15 раз ускорение пакетного экспорта и верстки ресайзов.
• 0% ошибок при предпечатной подготовке (исключены пропущенные шрифты, незалинкованные файлы и некорректная цветовая модель).
• 100% соблюдение гайдлайнов за счёт математического расчёта полей и отступов

Разбор ключевых модулей

Модульная сетка и гайды (runT2Grid, scriptOne, scriptTwo)

• Что делает: Автоматически строит внешнюю рамку безопасности и 6 опорных направляющих (центральные оси + пропорциональные сдвиги).
• Логика: Все отступы рассчитываются динамически от меньшей стороны артборда: var minSide = Math.min(width, height).
• Зачем: Мгновенная разметка артборда любого формата под требования брендбука.

Умное распределение элементов (runPaddings, scriptSeven, scriptEight)

• Что делает: Выравнивает выбранные объекты вдоль вертикальной или горизонтальной оси с фиксированным шагом.
• Логика: Определяет координаты, сортирует объекты по порядку (top или left) и выстраивает их с идеальным равным интервалом, не позволяя вылезти за края артборда.

Пропорциональное скругление углов (runRoundCorners, scriptThree, scriptFour)

• Что делает: Находит среди выделения замкнутые прямоугольники и применяет к ним адаптивный радиус скругления.
• Логика: Проверяет топологию объекта (4 точки, равенство противоположных сторон) и пересоздаёт его как roundedRectangle с сохранением исходных заливок и обводок.

Пакетный Prepress и экспорт (scriptFive, scriptSix, scriptTwelve)

• Что делает: Полный цикл подготовки к печати:
1. Автоматический перевод всего текста в кривые.
2. Сбор всех связанных изображений (placed items) в единую папку /links.
3. Экспорт векторов в PDF с вылетами под обрез и метками реза.
4. Генерация сборных JPEG-превью для всех артбордов.

Пакетный поиск и замена «Ищейка» (scriptThirteen_Ischeika)

• Что делает: Рекурсивно сканирует вложенные папки, находит текстовые блоки в AI-файлах, делает замену, пересчитывает размеры рамок и сохраняет результаты.
• Уникальная фича (fitTextInFrame): Если новый текст не помещается, скрипт автоматически конвертирует PointText в AreaText и динамически увеличивает рамку вниз до устранения переполнения (overflows === false).

Генерация ресайзов из данных (scriptTen, scriptEleven_MassVizitki)

• Что делает: Считывает CSV-файлы с размерами или техническими данными и автоматически генерирует файлы нужных габаритов с точной привязкой элементов.

Технические особенности реализации

Безопасная работа с файловой системой (I/O): Реализованы кастомные функции контроля записи waitForFileWritten и освобождения памяти waitForDocClosed, что исключает появление битых PDF/JPG или зависание Illustrator при фоновой обработке сотен файлов.

Адаптивная математика (Relative Scaling): Отсутствие жесткого хардкода размеры/отступы считаются в процентах/долях от меньшей стороны текущего артборда (Math.min(W, H)), что делает скрипты универсальными для макетов любого масштаба.

UI/UX интерфейс: Все сложные скрипты снабжены удобными диалоговыми окнами (ScriptUI) с выбором параметров экспорта (DPI 72/150/300, качество JPEG, метки реза, выбор папок).

Эти скрипты — пример того, как я оптимизирую рутину в дизайне и верстке. Вместо того чтобы вручную переводить 50 макетов в кривые, выставлять метки реза и раскладывать файлы по папкам, я написал скрипты на JS/ExtendScript. Они выполняют часовую работу за пару минут, гарантируют отсутствие технических ошибок и позволяют команде фокусироваться на креативных задачах, а не на технической рутине