Посмотрел ещё раз на bolt.new и на replit agent, ссылку на который мне прислали в комментариях к предыдущему посту. И тот, и другой (и, наверняка, ещё какое-то количество аналогичных сервисов) — это инструменты для того, чтобы нагнать побольше проектов хоститься на их родительских сервисах. ChatGPT объяснил мне что они умеют:

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

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

StackBlitz и Replit подходят для быстрого прототипирования и небольших проектов, в то время как AWS — мощная платформа для построения и масштабирования сложных приложений и распределенных систем.

А я теперь сижу с противоречивыми чувствами — вроде, я хочу как раз быстро прототипировать небольшие проекты. Но при этом меня не покидает ощущение, что StackBlitz и Replit слишком сильно ограничивают меня по тому, что в них можно сделать. И вместо того, чтобы под каждый проект подбирать свою платформу, где оно может хоститься, хочется остановиться на максимально универсальной мощной платформе. Но вот не оверкилл ли это?

Есть тут у кого-нибудь опыт разворачивания проектов на таких вот платформах для быстрого прототипирования? Я бы с удовольствием созвонился, вопросы позадавал.

Вот это подгон от Revolut Premium. И я сейчас не про то, что каждая доставка лучших суши в Пафосе теперь будет обходиться мне на 2.45€ дешевле. А про то, что жаба душила платить за Perplexity Pro 20 баксов в месяц, когда уже платишь их за ChatGPT.

Если вам было жалко 100€ в год за премиумную подписку Revolut, но вы пользуетесь AI-помощниками, то посчитайте всё ещё раз. Возможно, теперь она заиграет новыми красками. А если у вас до сих пор нет Революта, но есть возможность его оформить (в смысле, есть европейский ВНЖ), то вот вам реферальная ссылка. Не, ну мало ли.

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

Хочешь сделать достаточно хорошо — поручи кому-нибудь.

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

Возможно, поэтому для меня так притягательно идея, что код должен писать не я сам, а AI. Не, ну а чего от него ждать-то. Явно ж не идеальной реализации. Мы же знаем на каком говнокоде его обучали 😂

Мы с @aamik каждую неделю

Никак не могу выработать режим, в котором я буду регулярно тратить время на эксперименты с написанием кода LLM'ками и рассказывать об этом в канале. Так что сегодня снова будет очень краткий обзор того, что удалось сделать на предыдущей неделе.

Итак, цель всё та же — production-ready разработка без написания кода руками 🤖. Подход к разворачиванию тоже сохраняется — Serverless в AWS ☁️. И вот за две недели регулярного выделения часа-двух по будням и нескольких часов в выходные, мне в Cursor IDE с помощью Claude в качестве модели удалось собрать ту схему, которая приложена к этому посту.

Причём, когда я говорю "собрать", то это прям вот deploy-ready во всех смыслах:

📝 Написать весь код для AWS Lambda;
💡Написать код для взаимодействия со внешними сервисами, включая промты для обработки запросов силами OpenAI API;
🔧 Описать класс в AWS CDK для разворачивания этого с нуля в аккаунте AWS;
⚙️ Написать скрипт для GitHub Actions, который деплоит это в dev или в prod, в зависимости от того, в какую ветку коммит;
📦 Добавить сборку AWS Lambda Layers в сборку для тех функций, которые требуют дополнительных зависимостей;
📖 Написать базовую документацию для README.md, включающую схему, нарисованную выше;
🧪 Покрыть (пока) одну из лямбд полноценными юнит-тестами с замоканными AWS-сервисами.

Для меня это огромный шаг вперёд не только в разработке с AI-помощниками, но и в разработке вообще. Если честно, я никогда не выстраивал весь конвейер с тестами и dev-развёртыванием своими руками — только руками команды. И с точки зрения качества разработки pet-проектов, которыми я иногда занимался, это огромный шаг вперёд, позволяющий выйти на принципиально другой уровень качества и возможности постепенного развития. Документация, тестовое окружение и полноценное покрытие тестами сильно помогает, когда к проекту возвращаешься эпизодически, а не постоянно имеешь весь контекст в голове 🧠.

Что мне пока не нравится? То, что много повторяющихся функций в разных лямбдах тупо скопипащено. Но, кажется, это тоже довольно просто решаемо, когда весь процесс сборки автоматизирован. Можно вынести это всё в общие модули и добавлять необходимые зависимости куда надо. Когда надо всё деплоить руками, следить за этим замучаешься 😅.

Короче, две недели не мог оторваться и тупо шёл и шёл дальше к своей мечте про production-ready разработку без собственно написания кода. Кажется, что она где-то совсем рядом 🏁.

Вот, наконец, нашёл немного времени написать об этом и спросить: а кто-то хочет больше деталей про это всё услышать и увидеть? Может, вебинарчик какой-то с live-coding в Cursor замутить, где подготовим всё вышеперечисленное для какого-нибудь сервиса и задеплоим? 🎥

P.S. Вопрос границ применимости подхода всё ещё самый мучительный 🤔. Но чем дальше, тем шире они кажутся. И тем меньше скепсиса у меня к подходу при условии, что запросы в чат Cursor пишет человек, разбирающийся в разработке 👨‍💻. Вот если не разбирающийся, тогда пока не знаю.

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

Spittoon overflow

Надо так назвать сайт для виноделов, у которых вино не билдится 😅

Зачем писать что-то серьезное, если можно поделиться смешной опечаткой по Фрейду:
Вместо стейкхолдеров написал плейсхолдеров.

Подсознание не обманешь 😅

Я уже рассказывал про свои эксперименты с разворачиванием бекендов для телеграм-ботов в AWS. А сейчас решил, что вместо 1000 слов лучше одна ссылка на github. Так что ловите — https://github.com/dmgritsan/aws-serverless-tg-bot. 99% кода написал Claude в Cursor'е.

Именно как бот он пока не умеет ничего кроме команд start и help, но скоро добавлю отправку текста в ChatGPT с настраиваемым промтом. Зато как проект, он умеет деплоиться в продового и тестового бота.

Следите за issues, комментируйте, форкайте.

P.S. Если честно, я хотел написать большой пост, но вместо этого фиксил скрипт деплоя через GitHub Actions

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

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

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

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

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

И тут на помощь внезапно пришёл amazon.co.uk. Мало того, что там была скидка на ноут с M4 Pro и, естественно, клавиатура только английская. Они ещё и доставили его меньше, чем за неделю. А в качестве дополнительного бонуса у него подходящая для Кипра вилка на адаптере!

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

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

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

А теперь немного про то, почему я выбрал эту позицию. Если попытаться найти одну главную причину, то это “AI-driven development”, прошедший красной нитью через весь процесс найма — от первого сообщения в личку от CPO, с которым мы несколько лет назад запускали Яндекс.Сплит, в котором он отметил, что компания проявляет к этому активный интерес, до финального собеседования с COO и фаундером, примерно половину которого он рассказывал, как организовывал хакатоны для внедрения AI-подходов к разработке как раз в команде биллинга.

Я так сильно верю, что сейчас благодаря AI-помощникам полностью меняется подход к разработке, что решил, что заниматься этим только в свободное от работы время в корне неправильно. И когда нашёлся работодатель, который считает так же, как и я, который не просто готов к экспериментам, а активно всех на эти эксперименты толкает, понял, что это мой шанс заниматься тем, во что я действительно верю!

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

И вот это, хоть и сложное, но довольно освобождающее решение. Мы сами занялись своей легализацией здесь и место жительства теперь напрямую не связано с работодателем. Так что теперь ещё на один страх (о котором я писал в предыдущем посте) и на одну несвободу меньше!

За последние несколько недель я чётко понял, что на пути к быстрому запуску микропродуктов, которые под капотом используют LLM’ки, есть две большие, пересекающиеся между собой проблемы:
❓ Сложно понять, где граница применимости разных AI-моделей.
🎯 Неочевидно, как подобрать максимально хорошие цепочки промтов для решения конкретной задачи.

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

Решил поискать что-нибудь готовое. Спросил у Perplexity, какие тулы есть для промт-инженеров. Ведь если уже появилась целая отдельная профессия, то наверняка есть и специальные сервисы. Оказалось, что действительно есть много инструментов: кто-то умеет версионировать промты и проксировать запросы к LLM’ке, кто-то предлагает Prompt IDE или CMS (так и не понял, это одно и то же или нет), кто-то пытается улучшать промты с помощью AI.

Из того, что нашлось, больше всего по описанию мне понравилась Agenta. В ней есть всё, что мне хотелось получить:
🛠 Инструменты для тестирования промтов, включая Chain of Prompts и RAG.
🤖 Автоматическая оценка результатов, в том числе на смысловую схожесть, плюс разметка вручную через удобный интерфейс.
🌐 Проксирование запросов в LLM для использования актуальных версий промтов.
⚙️ API-доступ к последним версиям промтов для использования в своих запросах.

Честно, я пока не пробовал, но звучит многообещающе. А у вас был опыт работы с инструментами для подбора промтов? Посоветуете что-нибудь?

━━━━━━━━━━━━━━━━
P.S. Кстати, в том проекте, с которого начались мои поиски инструмента, надо было оценивать результат обработки не текста, а картинки. И вот под эту задачу я так ничего готового и не нашёл. 🤷‍♂️

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

Первая - маленькая, но очень порадовавшая фича то ли последнего Андроида, то ли конкретно последнего Пикселя. Когда после включения авиарежима включаешь WiFi или Bluetooth, появляется уведомление, что при следующем включении авиарежима, он запомнит текущее состояние. Неужели, наконец-то включение авиарежима не будет обрывать прослушивание контена? Меня это очень сильно раздражало, особенно, когда я летал с короткими пересадками. Кстати, это я просто слишком долго на древнем Хуавее с неактуальным Андроидом сидел, или это всё-таки Гугл красавчики?

А вот кто точно не красавчики в IT сервисах, так это Cyprus Airways или их подрядчики. Как это сейчас бывает почти у всех авиакомпаний, они запустили свою Inflight Entertainment System, к которой можно подключиться по WiFi. Всё бы хорошо, но когда подключаешься к бортовой сети с телефона, перебросить открывшуюся страницу в Chrome не получается. Ну, ничего, для таких случаев они сделали QR-код на флаерах, вложенных во впереди стоящее кресло. Правда, зачем-то сделали его через сокращатель ссылок bit.ly. И, сюрприз-сюрприз, без Интернета ссылка не открывается 😂 Причем, я вот прям отлично представляю, откуда взялся именно такой QR-код, как тз на него поставили, как сгенерили и как протестили.

Но, кстати, раз уж речь зашла про юзабилити, фича покорившая нас с женой больше всего за последний месяц, была обнаружена в приложении Apple TV+. Когда перематываешь на 10 секунд назад, оно автоматически на эти 10 секунд включает субтитры. Это просто гениально, особенно, когда во время вечернего просмотра сериалов, твою собаку регулярно посещает желание поболтать.

А вас кто и какими фичами порадовал за последнее время?

Обсуждали сегодня с коллегами в неформальной обстановке всякое, в том числе про AI-driven разработку. Все сходятся в том, что главное, что нужно, чтобы LLM-ка нормально написала код - это качественные требования. Но, блин, с качественными требованиями и разработчик может 😅

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

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

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

Я всегда поражаюсь тому, как удачная метафора меняет моё восприятие ситуации. Как и на яхтинге в Британии, где я получал лицензию Coastal Skipper, в управлении продуктом четко определенные миссия и видение могут помочь использовать течение вместо того, чтобы бороться с ним.

Я уже рассказывал, что одна из главных причин, почему я выбрал Tabby — это эксперименты с AI-driven разработкой. Мы не просто зпизодически используем ИИ, а строим процессы так, чтобы он стал их естественной частью.

Но есть еще один неожиданный момент, как прошлогодние сайд-проекты пересекаются с моей новой работой.

Я несколько месяцев помогал другу найти CTO для нового high-load сервиса. Этот проект оказался, пожалуй, самым интересным, что я делал за год, потому что включал в себя совершенно разные задачи:
✅ Декомпозиция продукта
✅ Определение стека технологий
✅ Выбор архитектурных подходов
✅ Написание вакансий
✅ Ну и, конечно, много-много интервью

Так как мой друг хотел нанять действительно крутого CTO, я проводил интервью не один. Мне повезло работать в паре с Сашей Кирилловым (CTO Evrone, член программного комитета HighLoad++), который знает всё о разработке сложных IT-проектов — от системного дизайна до управления командами. Особенно меня впечаталяли его комментарии к архитектурам сервисов пользовательских балансов, которые предлагали кандидаты.

После 10+ интервью я разобрался в разных архитектурных решениях, их плюсах и минусах. И знаете, что грумит сейчас моя команда в Tabby? Да, мы проектируем Ledger-сервис! То есть что-то очень близкое по смыслу. Все обсуждения про event sourcing и кэширование, которые мы вели осенью, теперь выходят для меня на совершенно новый уровень. Потому что теперь это не просто теория — это реальный сервис, с которым мы будем жить годами.

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

Поэтому я возвращаюсь к этой практике! Пиши мне, если ты:
🔹 Хочешь честный разбор своей IT-продуктовой идеи — покажу подводные камни, которые ты не замечаешь, и короткие пути, о которых не знаешь
🔹 Планируешь запустить IT-бизнес в одиночку (особенно без опыта в коде) и хочешь эффективно использовать LLM — помогу сэкономить часы (а может и дни!), объяснив тебе, что на самом деле ты делаешь и как правильно формулировать свой запрос к AI-ассистенту про это

📅 Консультации — по утрам в рабочие дни с 8 до 9 (по Кипрскому времени), начиная со следующей недели. Позже сделаю лендинг и Calendly, а пока просто пиши в личку 👉 @dmgritsan!

Давайте делать крутые вещи вместе! 🚀

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

Полтора года назад я переехал на Кипр. Деревня моя, конечно, не в горах, но море — достойная альтернатива. За это время я хорошо обустроился: решил бытовые вопросы, выстроил удобный график, наполнил дом тем, что мне важно. И главное — перестал куда-то бежать. Жизнь стала размеренной, порой даже слишком — иногда казалось, что я закисаю.

А потом случилась командировка в Дубай.

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

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

А потом я вернулся домой. Спокойствие, 80+% рекавери, всё на своих местах и в своём ритме. Но и от пары новых идей, и от уже объявленного возвращения к консультациям никуда не деться.

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

На Кипре всё иначе. Особенно если жить не в Лимассоле, а в пригороде небольшого Пафоса. От развлечений тебя может отделять час-полтора езды, а в повседневной жизни дорога редко занимает больше 15 минут. И этот часовой барьер защищает меня от FOMO. Теперь я не иду куда-то не потому, что у меня нет времени, а потому, что не хочу этого настолько сильно, чтобы ехать так долго.

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

Что общего у сырников и медитации?

На первый взгляд — ничего. Но для меня завтрак, приготовленный своими руками, — это не просто еда. Это способ поймать момент «здесь и сейчас» и получить удовлетворение от процесса и заряд позитивной энергии на день.

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

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

Из этих троих сырники — мой фаворит. Потому что это:
💪 Полезный завтрак (качковская еда, по версии моего тренера)
🍽️ Сытный завтрак (не хочется есть уже через пару часов)
🎨 Гибкий завтрак (топпинги под настроение)
😊 Завтрак, который радует меня
❤️ Завтрак, за который я получаю благодарность от жены
🏡 Скрепа по версии очень большого числа понауехавших

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

А на таком топливе уже можно и горы сворачивать 🚀

P.S. Если кто-то хочет напроситься на сырники в выходные, считайте это знаком.

Сегодня, наводя порядок в своих AWS-аккаунтах, удаляя лишние Lambda-функции и очереди, вспомнил, как несколько лет назад хакал cron-таски в AWS.

Летом 2022 года, когда записаться на шенген в Москве стало практически невозможно, но привычка ездить в Европу у жителей столицы ещё не пропала, появились всевозможные “помогаторы”. Они за деньги записывали людей в консульства на редкие свободные слоты.

Мне тоже хотелось куда-нибудь в Альпы, а ещё у меня был приличный опыт парсинга страниц. На тот момент я уже несколько месяцев ковырял сайты производителей шин, вытягивая все возможные комбинации моделей, фичей и размерностей (не спрашивайте 😅). В общем, решил, что раз уж помогаторы могут записывать людей, то и я себя записать смогу. Главное — найти самое дырявое посольство.

Небольшой ресёрч показал: проще всего пробиться к итальянцам. Я быстро разобрался, как мониторить свободные окошки, и для начала решил просто слать себе уведомления, когда они появлялись. Парсер был простым Python-скриптом, так что я развернул его в AWS Lambda и настроил запуск раз в секунду через EventBridge (читай: cron-таски, но для Lambda).

На следующий день стало ясно: окна появляются регулярно, но живут меньше секунды. Явно идёт война ботов 🤖💥.

Из чего я сделал два вывода:
1️⃣ Записывать меня тоже должен бот.
2️⃣ Мониторить слоты раз в секунду — слишком медленно.

Но как запускаться чаще, если в cron минимальная размерность — секунда?

Вспомнил, что AWS Lambda умеет триггериться при появлении сообщений в SQS, и немного доработал скрипт. Теперь перед началом парсинга он проверял, в какой доле секунды находится. Если это было до 0.75, то он слал в очередь новое сообщение с таймаутом видимости 250 мс.

В результате, если первый вызов приходился на начало секунды, скрипт отрабатывал до 4 раз в секунду. Чаще всего — действительно 4, иногда 3.

📈 Количество найденных окон увеличилось примерно вдвое. Но ненадолго.

Сначала подтянулись конкуренты. Потом и само консульство поставило защиту против таких вот “мамкиных хакеров” 😅. Но к тому моменту я уже успел податься на визу и запланировать отпуск, из которого, кстати, в Москву так и не вернулся.

А вам приходилось запускать что-то чаще, чем раз в секунду? Как решали такие задачи? 🤔

Интересно, кстати, почему ChatGPT при редактировании текстов на русском ставит пробелы вокруг длинного тире, а на английском нет 🤔