Без маркетинга и успешного успеха. Только боль, костыли и суровый прод! Мой пет-проект - бот «Щёлк-ГДЗ». Это ИИ-помощник, который решает школьные задачки по фоткам, видео, гс, тг-кружкам и PDF. Под капотом Python 3.12.3, aiogram 3, aiosqlite, апи OpenRouter (модель Gemini 3.0 Flash) и Робокасса. Крутится всё это на дешёвом VPS в Нидерландах. Держит 2500+ пользователей и не падает.

В этой статье расскажу, как за 9 месяцев построил логичную архитектуру, победил ошибку FloodWait при стриминге ответа ИИ и почему в условиях 1 гига RAM обычная SQLite - отличное решение.

Нейронка вместо джуна и Уроборос багов

Сразу признаюсь... С нуля я это не писал :) Синтаксис мне генерили LLM-ки. Начинал с Gemini 2.5 Pro, затем перешел на 3.0 Pro, а сейчас использую 3.1 Pro.

Многие думают, что нейронка сама напишет проект "под ключ", но это миф. Я никогда не доверял ИИ проектирование архитектуры и использовал его как продвинутый StackOverflow (скармливал конкретную задачу (например, написать SQL-миграцию) и получал кусок кода).

ИИ — это не архитектор, а джун на спидах.

Как только логика усложнялась - гемини ловил «Уроборос багов». Кидаешь баг А - он его фиксит, но появляется ошибка Б. Скармливаешь и её - фиксит, но возвращается баг А. Цикл замкнулся. Лечилось только созданием новых чатов, в которые я кидал код и писал запросы типа "Найди критические ошибки, логические дыры и баги".

Про продуктовую логику нейронка вообще не слышала. В первой версии рефералки был баг, где любой(если его аккаунта ещё нет в БД) мог написать в конце ссылки что любые 9 цифр (?start=1234567890) и получить бонусы.

Также были ошибки с гонкой состояний при оплатах и активациях промокодов, которые тоже фиксил запросами в новые чаты с ИИ. Так я исправил около 20 архитектурных дыр.

Немного про архитектуру.

Чтобы код не превратился в нечитаемую лапшу на 5000 строк, я жестко разбил всё на модули. Архитектура бота выглядит так:

main.py - это точка входа с настройкой логгеров, коннетами aiohttp и запуском APScheduler

database.py - вся работа с БД

neiro.py - логика общения с апи OpenRouter (стриминг, сжатие фоток через Pillow, JSON-контекст)

states.py - классы состояний aiogram.fsm.state (например, PaymentProcess, GdzMode)

utils.py - легковесные утилиты. Например лок пользователей (защита от спама запросами):

Хэндлеры вынесены в отдельную папку handlers/:

handlers/common_handlers.py - главное меню с обработкой /start (рефералки, utm-метки).

handlers/gdz_handlers.py - сам процесс ИИ-решения (вход в GdzMode, прием фото, видео, кружочков).

handlers/pay_handlers.py - это логика платежей (Robokassa) и "Умная корзина".

handlers/tasks_handlers.py - квесты (выдача премиума за подписку на каналы спонсоров).

Сборку интерфейсов вынес в all_def.py. Не люблю, когда в хэндлерах генерится полотно текста с кнопками. Там же лежат функции склонения слов (1 запрос, 2 запроса, 5 запросов). А в settings.py лежат списки с рандомными ответами бота, чтоб казался живым.

Так же в settings.py я сделал кэширование картинок, тоесть при первом запуске бот грузит фото меню как BufferedInputFile, сохраняет file_id от Телеграма и дальше шлет картинки моментально по ID. Сервак говорит спасибо за сэкономленный трафик)

В handlers/common_handlers.py находится первичная маршрутизация. Вот так обрабатываются рефералки, переходы с сайта, с рекламы и другое при старте:

Диета по токенам

Хранить бесконечную историю диалогов дорого и бессмысленно. В бесплатной версии храню 10 последних сообщений (5 пар вопрос-ответ), а в преме — 30.

Но фотки весят большое кол-во токенов. Если премиум-юзер закинет 30 фоток, OpenRouter выставит мне огромный счет. В итоге я прикрутил ограничение: Из 30 сообщений ИИ видит только 10 последних картинок.

Старые фотки тупо вырезаю из JSON. Подменяю на системный промпт:

С довольно неплохой моделью (gemini 3.0 flash) это работает как часы (она честно признается, что забыла картинку, а не выдумывает что-то из воздуха).

Стриминг, FloodWait и защита баланса

Чтобы бот не выглядел тормозом, я сделал стриминг ответа от ИИ в neiro.py. Я обновляю сообщение в Телеграме чанками по мере получения их от ОпенРоутера.

Но если делать message.edit_text слишком часто, ловишь FloodWait. В итоге я выставил интервал в 0.7 секунд и обернул всё в жесткий try/except:

Стрим при этом не прерывается. Поспали и погнали дальше :) Если на этапе обработки файла или стриминга падает критическая ошибка - честно возвращаю юзеру запрос на баланс.

В handlers/gdz_handlers.py это выглядит так:

SQLite тащит

Почему не Postgre? Потому что для микро-SaaS с 2,5к пользователей SQLite хватает за глаза. Но в асинхронной среде она любит кидать ошибку database is locked.

Чтобы этого избежать, я включил WAL-режим при инициализации пула, разделил коннекты на db_writer и db_reader, а сложные операции доверил самому SQL.

Например, 00:00 запускается крон-таска, которая собирает огромную аналитику, начисляет всем активным юзерам +1 ежедневный запрос и сбрасывает просроченные подписки. И это всё это работает атомарно внутри database.py:

Умная корзина на APScheduler

Когда дело дошло до монетизации, всплыли две проблемы:

Первая: юзер оплатил, но забыл нажать кнопку «✅ Я оплатил» в боте. Бот ждет, юзер ждет, товар не выдается, поддержка кипит.

Вторая: юзер сформировал счёт и передумал ("брошенная корзина").

Вместе с LLM я с нуля изучил apscheduler и убил двух зайцев фоновыми задачами. Теперь в handlers/pay_handlers.py при генерации ссылки на оплату я создаю две отложенные таски:

Как это работает?

Через 5 минут срабатывает async def auto_check_payment(), которая тихо стучится в робокассу. Если статус success - бот сам начисляет запросы на баланс и радует клиента. Если статус pending - таска умирает, и в дело вступает 30-минутная таска.

Но она не шлёт спам вслепую, а лезит в БД и проверяет 3 бизнес-правила:

1. await db.has_successful_payment_recently - Не купил ли он другой товар за последние 3 часа?

2. await db.get_latest_invoice_id - А это точно самый последний сгенерированный им счет?

3. await db.can_send_agitation - Не присылали ли мы ему агитацию недавно?

Если проверки пройдены, то юзер получает сообщение: "⏳ Домашка сама себя не решит! Ты начал оформлять покупку, но оплата так и не прошла...". Это поднимает конверсию оплат.

Финал

Почему я не использую Redis для стейтов? Ответ банален: мой дешевый VPS имеет всего 1 гб оперативки. Пул aiohttp, In-Memory стейты и асинхронные таски и так жрут 70% RAM. Редис тупо не влезет.

Как говорится, работает — не трогай.

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

Готов ответить на вопросы по архитектуре и послушать советы в комментариях \(^^)/

P.s. вот ссылка на первую статью о моём проекте:

P.s. Если кто-то хочет потестить вживую(не реклама), то юз бота в тг @gdzshchelk_bot

Он объясняет, почему хорошая фича, первые пользователи и даже выручка ещё не гарантируют бизнес. В статье разберём, с чего на самом деле начинается бизнес, как проверить идею до запуска, почему MBA плохо подходит для старта с нуля и где можно научиться запускать успешные продукты.

Бизнес начинается не с технологии, а с чужой проблемы

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

Вячеслав Чикин говорит, что начинать нужно с другого:

Предпринимательство начинается не с технологии. Оно начинается с проблем, которые есть у тех, кто будет пользоваться продуктом», — объясняет он. Разработчик по природе смотрит на то, что он создал, и ищет, куда это применить. Предприниматель смотрит в обратную сторону: вот проблема, вот человек, который в ней застрял, — что из имеющегося в мире поможет её решить? Технология при этом не обязательно должна быть своей.

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

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

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

Придумать пользу из головы не получится

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

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

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

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

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

Предприниматель ≠ менеджер (и почему тимлид не равно фаундер)

Есть распространённая логика карьерного роста в IT: джун → мидл → сеньор → тимлид → руководитель разработки. Каждый шаг — больше ответственности, людей в подчинении и лучше понимание, как работает система. Кажется, следующий шаг — собственный бизнес — просто продолжение того же трека, но и это тоже не так!

Вячеслав Николаевич Чикин разводит предпринимателя и менеджера по базовому признаку: с чего начинается их работа.

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

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

Стать фаундером или найти фаундера

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

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

Продукт — это артефакт. Бизнес — система, которая его производит

Многие разработчики, запуская своё, думают примерно так: есть работающий сервис, есть первые пользователи, есть MRR — значит, есть бизнес. Вячеслав Чикин с этим не согласен, потому что рабочий продукт — это артефакт, а бизнес — это система, которая производит этот артефакт регулярно, в нужном объёме и без того, чтобы всё держалось на одном человеке.

Разница простая: если вы уходите в отпуск на две недели и всё останавливается, у вас пока не бизнес. У вас есть продукт, а главный производственный ресурс — вы сами.

Возьмите Bugatti. Разбейте её об забор — материал останется тот же: металл, резина, стекло, пластик. Но стоимость упадёт в тысячу раз. Потому что ценность была не в материале, а в том, как он организован. Бизнес работает так же: ценность не в коде, не в алгоритме и не в команде по отдельности, а в том, как всё это собрано и работает вместе.

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

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

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

Как же стать предпринимателем

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

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

Второй вариант — это онлайн-магистратура «Технологическое предпринимательство» от МФТИ и Сколково. Программе уже 15 лет: онлайн-формат существует с 2017 года, а оффлайн — с 2011-го. За это время выпустили более 350 магистров, а учат студентов более 50 менторов-практиков с реальным предпринимательским опытом.

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

Если хочется для начала быстро понять, ваш пет-проект вообще имеет шанс стать бизнесом, есть вход полегче — онлайн-школа «Предпринимательское планирование: от идеи до бизнес-модели».

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

Всего за 5 недель и 4 учебных модуля вы получите из идеи — готовый бизнес-план, в программе вас за ручку проведут по всем этапам:

• Знакомство: разбираете свой проект, знакомитесь с преподавателями и другими участниками;
• Продукт предпринимателя: актуальные подходы к предпринимательству — применяете их к своей идее;
• Jobs To Be Done: методология исследования потребителей — используете на своём проекте;
• Бизнес-модель: архитектура предприятия с учётом конкурентов и ресурсов;
• Бизнес-план и защита: собираете всё в цельный план и презентуете его группе.

В итоге у вас на руках после школы — готовый бизнес-план, удостоверение МФТИ о повышении квалификации и, если решите пойти дальше, льготный вход в магистратуру.

Подробности по школе и магистратуре, стоимость и запись — на techpredschool.ru.

Если у вас есть пет-проект есть и вы давно откладываете момент, когда наконец разберётесь, бизнес это или нет — вот он, момент.

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006211, erid: 2W5zFGjZd5B

В 2025-м кажется, что решение очевидно: открыл ChatGPT/Claude, описал симптомы, получил ответ. Я так и делал — до тех пор, пока не стало понятно: голого чат-ИИ мне не хватает.

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

Так появился Telegram-бот @NoPanicHealthBot, который я сначала делал исключительно для своей семьи, а уже потом увидел в нём архитектурный паттерн, масштабируемый на широкую аудиторию.

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

Три вещи, которых нет у «голого» ChatGPT

1. ИИ не знает человека:

• какие анализы уже были;
• на что есть аллергии;
• какие хронические истории у конкретного ребёнка;
• что уже пробовали из лечения и как это сработало.

Каждый раз получается мини-эпикриз: «Смотри, это Маша, 7 лет, в прошлом году…» — и так по кругу.

Это утомляет, а главное — нет гарантии, что модель вытащит действительно важные детали.

2. Память одноразовая

Сегодня вы честно выгрузили полгода истории ребёнка в чат, а через пару месяцев:

• вы снова ищете те же анализы;
• снова объясняете те же эпизоды;
• снова прогреваете контекст.

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

3. Нет нормального контура управления

У голого чата нет:

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

Да, можно как-то промптить, но это быстро превращается в мешанину из правил, которые сложно проверять, обновлять и объяснять.

Что я в итоге сделал: бот как внутренний MCP-сервер

В какой-то момент я перестал думать «как бы получше промптнуть ChatGPT», и стал думать так:

«Пусть LLM будет просто умным, но амнезирующим вычислителем.

Архитектурно это выглядит как личный MCP-сервер:

• Telegram-бот @NoPanicHealthBot — только интерфейс.

• Внутри — сервис, который хранит: людей и членов семьи;обращения; анализы; файлы; историю рекомендаций.

• LLM подключается к этому сервису как клиент к набору инструментов (tools).

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

• «дай профиль этого ребёнка»;
• «дай последние анализы такого-то типа»;
• «дай прошлые обращения по теме горла»;
• «сохрани вот такое summary и список рисков».

Модель вообще не знает ни про Telegram, ни про БД.

Она видит интерфейс инструментов и работает в рамках этих границ.

Типичный кейс: «у дочки снова болит горло» Разберём, как это выглядит изнутри (упрощённо).

1. Пользовательский слой Родитель пишет в @NoPanicHealthBot:

«У дочки снова болит горло».

Бот задаёт стандартные уточняющие вопросы:

• сколько длится;
• температура;
• есть ли кашель/насморк;
• были ли такие эпизоды раньше;
• что уже приняли.

Это не ИИ-магия, а обычная детерминированная «машина состояний», чтобы ничего критичного не забыть.

2. Слой памяти

Дальше сервис:

• находит в базе соответствующего ребёнка (member_id);
• поднимает: возраст; прошлые обращения по ЛОР-темам; последние анализы; аллергии и хронические заболевания.
• возраст;
• прошлые обращения по ЛОР-темам;
• последние анализы;
• аллергии и хронические заболевания.

На этом шаге появляется структурированная «карточка случая», а не просто текст:

• жалоба + длительность;
• ключевые симптомы;
• вытащенные значения из анализов;
• релевантные куски истории.

3. Слой ИИ как инструмента

Затем включается LLM. Внутри у меня несколько «виртуальных врачей»:

• условно отечественная школа;
• западная доказательная;
• более мягкий / «восточный» профиль;
• отдельный профиль под косметологию.

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

Модель на вход получает:

• системное описание роли («ты врач такой-то школы, твоя задача…»);
• структурированный кейс;
• ограничения: когда нужно отправить к живому врачу, что нельзя советовать детям и т.п.

На выходе я прошу не просто «ответ текстом», а набор полей:

• краткое человеческое summary;
• список рисков / поводов для офлайна;
• список наблюдений;
• текст объяснения для родителя.

Бот показывает объяснение, а сервис записывает всё это в историю конкретного визита.

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

Косметология: тот же подход, другая предметка

Косметология родилась почти автоматически — на тех же рельсах.

Сценарий:

1. Бот спрашивает про кожу и цели (зона лица, жалобы, уход).
2. Пользователь кидает селфи.
3. Сервис: сохраняет оригинальное фото; прогоняет через распознавание; превращает в набор признаков: тип кожи, наличие покраснений, пигментации и т.п.
4. сохраняет оригинальное фото;
5. прогоняет через распознавание;
6. превращает в набор признаков: тип кожи, наличие покраснений, пигментации и т.п.
7. В LLM уходит уже структурированное описание кожи + история прошлых рекомендаций по этому человеку.
8. Профиль «косметолог» строит план ухода, который бот показывает и складывает в историю.

Для модели это всё те же инструменты:

• «дай мне признаки кожи по этому человеку»;
• «дай историю прошлых назначений»;
• «запиши новые рекомендации».

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

Почему я не стал просто «увеличивать контекст»

На этом месте обычно спрашивают:

«Ну ок, а если просто давать модели побольше текста? Контекст-то растёт».

Проблемы не исчезают:

1. Окно всё равно конечно. В какой-то момент вы всё равно обрезаете историю. Чем — эвристикой и удачей.
2. Шум. В реальной жизни диалог с ботом полон случайных реплик, уточнений, опечаток. Модель тратит токены и внимание на то, что в медицинском смысле ничему не помогает.
3. Сложно объяснить решение. Когда всё завязано на текст, тяжело честно ответить: откуда модель взяла тот или иной вывод; какие анализы были учтены, а какие нет; не опирается ли она на устаревшую рекомендацию полугодичной давности.
4. откуда модель взяла тот или иной вывод;
5. какие анализы были учтены, а какие нет;
6. не опирается ли она на устаревшую рекомендацию полугодичной давности.

Когда у вас есть MCP-подход, вы:

• явно определяете, какие факты входят в кейс;
• можете логировать именно «факты, на основе которых работала модель»;
• в любой момент воспроизводите ситуацию: тот же кейс → та же или другая модель → сравнение результатов.

Зачем это всё мне — и почему это не только про мою семью

Первая мотивация была очень приземлённой:

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

Для моей семьи @NoPanicHealthBot уже стал чем-то вроде

«семейной медицинской карты с умным слоем сверху».

Но по мере развития стало очевидно, что:

• паттерн «личный MCP-сервер для человека» универсален;
• сверху можно подключать разные LLM (облачные, локальные, self-hosted);
• интерфейсом может быть не только Telegram, но и веб, мобильные приложения, интеграции с клиниками или страховыми.

То есть из «домашнего проекта» это легко превращается в продукт для широкой аудитории — с тем же ядром:

структурированная персональная память + слой инструментов для ИИ.

Что можно утащить из этого опыта

Если вы работаете с LLM и вам тесно в формате «ещё один чат-бот», вот три идеи, которые я вынес:

1. Разделяйте интеллект и память. Модель не обязана помнить вашу доменную историю. Память должна быть в вашем сервисе.
2. Смотрите на свой бэкенд как на MCP-сервер. Опишите, какие именно инструменты нужны модели: не «текст диалога», а функции с чёткими контрактами над вашей предметкой.
3. Стройте контуры управления вокруг ИИ, а не внутри промпта. Ограничения, проверка, аудит — это нормальная инженерная работа, а не «магия подсказок».

Голый ChatGPT отлично отвечает на разовые вопросы.

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

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

🔥 Помогал с публикацией Игорь Панасюк — Software Engineer и автор канала Igor Panasyuk | IGORoutine Programming.

Регистрация бота в Телеграм

Откройте Телеграм и найдите @BotFather — это официальный бот, он создаёт других ботов. Отправьте ему команду /newbot.

BotFather сначала спросит имя бота, оно может быть любым. Далее придумайте username, чтобы он заканчивался на «bot», например hello_chat_bot. Если юзернейм свободен, BotFather пришлёт токен для управления. Выглядит токен как длинная строка: 8201115114:AAGNII8UA3kjcz9qvV8znl77pK-YldkWMmQ.

В BotFather есть несколько команд для настройки оформления:

• /setname — меняет имя бота (то, что видят пользователи);
• /setdescription — добавляет описание, которое отображается при первом запуске;
• /setabouttext — добавляет короткий текст для страницы бота;
• /setuserpic — загружает аватарку (квадратное изображение от 512×512 px).

Имя можно менять сколько угодно раз. Username (тот, что заканчивается на _bot) изменить нельзя.

Создаём Телеграм-бота на Rust

В качестве примера напишем эхо-бота. Он будет получать строку текста и её же присылать в ответ.

Создайте новый проект:

Откройте Cargo.toml и добавьте зависимости:

Создайте файл .env в корне проекта:

Откройте src/main.rs и вставьте код:

teloxide::repl() запускает цикл обработки сообщений. Функция внутри получает сообщение и отправляет текст обратно пользователю.

msg.text() извлекает текст из сообщения. Если пользователь отправил стикер или фото, бот их проигнорирует. Как читать разные типы сообщений — разберём далее.

bot.send_message() отправляет ответ. Первый параметр — ID чата, второй — текст. Методы отправки с форматированием, кнопками и файлами рассмотрим в следующих разделах.

Скомпилируйте проект:

Откройте мессенджер, найдите своего бота по юзернейму и напишите ему любое сообщение. Если бот ответил, значит всё сделали правильно.

Перенос бота на хостинг

Сейчас бот работает локально на вашем компьютере. Чтобы он отвечал круглосуточно, нужен сервер. Есть три варианта:

• Виртуальный сервер (VPS).
• Облачные платформы.
• Домашний сервер.

Проще и дешевле взять VPS, подойдёт любой Linux-сервер за 200-300 рублей/месяц.

После оплаты хостинга вы получите IP-адрес сервера, логин и пароль. Откройте терминал и подключитесь: ssh root@123.45.67.89, введите пароль.

Установите Rust:

Клонируйте проект с GitHub или создайте новый:

Создайте на сервере файл .env с токеном:

Соберите релизную версию:

Если закроете терминал, бот остановится. Чтобы он работал постоянно, используйте утилиту screen:

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

Чтение сообщений

Телеграм отправляет боту данные через API. Каждое сообщение приходит в виде объекта:

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

Библиотека teloxide распарсила JSON от Телеграм и превратила его в удобные структуры. Нужен лишь обработчик, который срабатывает на новое сообщение:

Бот как-то должен узнавать о новых сообщениях от пользователей. Самый простой способ — метод getUpdates. Бот каждые несколько секунд спрашивает: «Есть что-то новое?». Получает ответ, обрабатывает сообщения и снова спрашивает.

Под капотом teloxide делает примерно следующее:

Есть другой вариант — вебхуки. Вы один раз говорите Телеграму: «Вот адрес моего сервера, присылай сюда все обновления».

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

С getUpdates сами решаете, когда проверять новые сообщения. С вебхуками Телеграм решает за вас — он шлёт данные сразу, как только что-то происходит. Если вы пишете бота для себя или учитесь, начните с getUpdates.

Отправка сообщений

Базовая отправка текста выглядит так:

chat_id — это идентификатор чата, откуда пришло сообщение. Бот отправит ответ туда же.

Телеграм ограничивает длину одного сообщения 4096 символами. Если попытаетесь отправить больше, API вернёт ошибку. Проблему решает функция, которая разбивает текст на части:

Бот может отправлять не только текст. Методы send_photo, send_document, send_video работают с файлами до 50 МБ. Передавайте либо URL, либо загружайте файл с диска:

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

Иногда нужно отправить сообщение с задержкой. В Rust нет встроенного планировщика задач, но есть tokio::time::sleep:

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

Добавление меню и кнопок

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

В Телеграме есть два типа кнопок:

• Reply — появляются вместо обычной клавиатуры для ввода текста.
• Inline — прикрепляются прямо к сообщению.

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

Создадим простое меню с двумя кнопками:

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

Inline-кнопки отправляют callback-запросы:

«Да» — это текст на кнопке, «answer_yes» — данные, которые получит бот. Чтобы поймать нажатие, нужен обработчик callback-запросов.

Ограничения ботов и ddos-атаки

Telegram API ограничивает количество сообщений, которые бот отправляет одному пользователю или в группу. Если превысите лимит, получите ошибку 429:

• 30 сообщений в секунду.
• 20 сообщений в минуту в один чат.

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

Основное правило — не держать бота напрямую за getUpdates, а использовать вебхуки с ограничением соединений и прокси. Telegram уже фильтрует большую часть мусорного трафика, но важно добавить rate limit (например, через nginx) и иметь таймауты.

Добавьте простую защиту: храните HashMap с user_id и временем последнего сообщения. Если пользователь пишет чаще раза в секунду — игнорируйте его запросы. Ещё один вариант — подключить Redis и вести счётчики запросов там.

Библиотеки для создания ботов на Rust

В экосистеме Rust для тг-ботов есть три основные библиотеки.

teloxide

Вы пишете bot.answer("Привет") — библиотека сама формирует HTTP-запрос, отправляет его в Телеграм API, обрабатывает ответ и возвращает результат.

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

Ещё в teloxide есть диспетчер команд. Вы пишете функцию start(), помечаете её атрибутом #[command], и библиотека автоматически вызывает эту функцию, когда пользователь отправляет /start. Не нужно вручную парсить текст сообщения и проверять, что там написано.

Минус — teloxide тянет за собой много зависимостей. Поэтому увеличивается время компиляции, размер бинарника тоже.

Размер бинарного файла напрямую на производительность не влияет — Rust-компилятор делает статическую линковку, так что даже 20 МБ бинарник работает с той же скоростью. Если размер критичен при деплое, можно попробовать собирать с флагами, которые удаляют служебную информацию из бинарника.

frankenstein

Генерирует структуры данных из официальной спецификации Telegram Bot API. Вы получаете типы SendMessage, Message, User — они точно соответствуют тому, что описано в документации Telegram.

Библиотека не добавляет абстракций. Хотите отправить сообщение — создаёте структуру SendMessageParams, заполняете chat_id и text, вызываете метод api.send_message(). Хотите обработать команду — сами проверяете, начинается ли текст сообщения со /start.

frankenstein компилируется быстрее teloxide и создаёт меньший бинарник.

teloxide-core

Основа teloxide без диспетчера команд и системы диалогов. Вы работаете напрямую с методами API, но библиотека всё ещё помогает с типами и обработкой ошибок.

Используйте teloxide-core, если архитектура вашего бота не вписывается в teloxide и вы не хотите писать всю логику с нуля в frankenstein.

Подведём итоги

Вы создали бота, который читает сообщения, отвечает на команды, показывает кнопки и работает на сервере. База готова — добавляйте логику под свои задачи:

• Подключите базу данных (PostgreSQL через tokio-postgres или SQLite через rusqlite).
• Добавьте HTTP-запросы к внешним API (reqwest).
• Настройте логирование в файл (log4rs).

Код из статьи — это каркас. Теперь у вас есть работающая основа, которую можно развивать в любом направлении.

Павел, аналитик данных

Мне было чуть за 40, когда я решил уйти в никуда. На тот момент почти десять лет работал замруководителя в небольшой компании. С IT работа была не связана — только плотно сидел в Excel. Контролировал бухгалтерию и делал базовые финансовые исследования.

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

Мысль об IT крутилась в голове без конкретики. В итоге случайно наткнулся в соцсетях на обсуждение аналитики данных. Также почитал посты Тимура, который набирал учеников. У него была живая группа и прозрачные условия, не чувствовалось конвейера. Я решился.

С первых недель меня затянула учёба: мог сидеть по 8–12 часов за ноутбуком, пока семья не оттаскивала. Потом сознательно снизил темп, чтобы не выгореть. За полгода прошёл путь от нулевых знаний до первых пет‑проектов. SQL дался легко, Python — тяжело, но интерес появился, когда начали появляться практические задачи с библиотеками pandas, NumPy, matplotlib.

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

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

Сейчас я работаю аналитиком данных на мидловской позиции, полностью удалённо. Использую SQL, Python и BI‑системы. Больше всего люблю находить и оптимизировать логику запросов. Для себя сделал вывод: даже если что-то не получится в будущем, я уже знаю, что могу перестроиться. Переход в IT считаю удачным: интересная работа, достойный доход и ощущение свободы. Мы учимся всю жизнь. Возраст — это не барьер, а опыт.

Виталий, разработчик и тимлид

До IT я больше 13 лет работал на телевидении и радио: был звукорежиссёром, диктором, создавал рекламу. У меня была музыкальная группа. Потом ушёл в фотографию: своя студия в Петербурге, команда. Параллельно делал сайты для группы, студии и клиентов — в основном на WordPress, с примесью HTML и PHP. Это нельзя было назвать полноценным коммерческим опытом, но техническая жилка была.

В какой-то момент я понял: удовольствия от работы с сайтами больше, чем от съёмки. Семья отнеслась с пониманием. У нас были сбережения, поэтому я смог позволить себе почти год заниматься только учёбой. Начал с книг, прошёл курс CS50 от Гарварда, потом нашёл ментора, который помог скорректировать направление. Учёба занимала всё время — от утра до поздней ночи. Это было непросто и для семьи, но другого способа быстро освоиться не было.

Через полтора года я получил первый коммерческий заказ — систему автоматической торговли на маркетплейсе. Она позволила бизнесу снизить расходы на маркетологов в пять раз и до сих пор работает. Эта работа во многом определила моё будущее направление: серверные разработки для крупного бизнеса. Сейчас это торговля, доставка, BI‑системы, финансы.

Были моменты, когда хотелось всё бросить. Когда начался бум искусственного интеллекта, то казалось, что всё напрасно, скоро нас заменят. Но я продолжал. И понял: писать код — это просто. Сложно понимать заказчика, строить систему, проектировать архитектуру. Но именно это приносит кайф. Любимый момент — когда создаёшь проект и видишь, что удалось максимально развязать компоненты. Тогда работа перестаёт быть болью.

Первая должность — Python‑разработчик на позиции джуна. Потом мидл, тимлид. Сейчас я веду команду и остаюсь разработчиком одновременно. Это непросто, потому что не хочу уходить в чистый менеджмент. Но именно здесь помогает возраст: когда отбираешь кандидатов, смотришь не на цифры в паспорте, а на зрелость и умение работать. В моей команде были ребята и за 40, и по 21 год — и все классные.

Сейчас параллельно я осваиваю Go. Чтобы было по-настоящему интересно, запустил пет‑проект 5Place — бэкенд для мобильного приложения, которое помогает находить интересные места в городе. На Go всё получилось ближе к реальности: пространственная база данных, интеграции, архитектурные решения.

У меня есть каналы на YouTube и в Telegram. Это способ делиться опытом и глубже погружаться в темы. Когда преподаёшь, ты учишься сам. Иногда на собеседованиях встречаю своих бывших учеников, и это очень приятно.

Если говорить честно, то учиться после 40 тяжело. Первую работу найти сложно. Но дальше начинается удовольствие. Поэтому главный совет — идти в IT только если вы горите этим делом. Возраст точно не барьер: я сам никогда не сталкивался с предвзятостью. А мифы о том, что после 40 не берут, — это просто мифы.

Алексей, тестировщик

До IT я больше десяти лет был коммерческим директором в торговой компании. За это время накопились противоречия и конфликты с руководством. В 49 я спросил себя, хочу ли ещё 10 лет заниматься тем же. Ответ был «нет».

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

IT был мне не совсем чужим: инженер‑системотехник по образованию, навыки выше среднего, технику всегда любил. Начинал с платформы Utest: разные проекты, гибкий график, первые выплаты — мощная мотивация. Но постепенно понял, что реальное тестирование сложнее. Тогда я стал учиться системно: брал курсы по автоматизации на Java у Алексея Баранцева, читал и смотрел видео. Пройти обучение до конца мотивировали потраченные деньги. Если заплатил, значит, должен дойти до конца.

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

Постепенно автоматизация превратилась в рутину. Хотелось больше развиваться — так я оказался в нагрузочном тестировании. Здесь важно понимать, как работает железо, базы данных, JVM. Это новое измерение задач: нужно искать узкие места, анализировать производительность, понимать систему на глубоком уровне.

Сейчас я пишу код на Java в Gatling, иногда и на других языках, если нужно. Люблю задачи, в которых не знаю решения заранее. Когда удаётся разобраться в новом инструменте или протоколе, приходит настоящее удовлетворение.

Работа в IT вернула мне уверенность. Оказалось, что и после 50 можно учиться и быть востребованным. Конечно, мне важна стабильность, но я стараюсь не засиживаться: беру сложные задачи, чтобы расти. Вне работы поддерживаю форму — велосипед летом, лыжи зимой, путешествия. Это помогает оставаться в тонусе.

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

Вывод

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

Советы тем, кто стартует после 40:

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

Дмитрий Борцов — руководитель разработки клиентских интерфейсов в PREMIER.ONE. В его подчинении более 60 инженеров, распределённых между вебом, Android, iOS и SmartTV. В индустрии он уже 15 лет: прошёл путь от фриланса и собственной студии до руководства крупными командами. Такой опыт, как он сам говорит, позволяет видеть рынок «с двух сторон» — понимать, что нужно бизнесу и какие компетенции позволяют разработчику стоить дороже. Сегодня Дмитрий совмещает управленческую роль с менторством: вместе с техлидом PREMIER.ONE Андреем Автушенко он развивает платформу Frontend Alliance, где в формате парного наставничества помогает фронтендерам — от джунов до тимлидов — прокачивать хард и софт скиллы, готовиться к собеседованиям и строить карьеру с опорой на реальную практику.

Фронтенд под давлением: рынок стал жёстче, но не умер

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

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

Тем не менее, говорить о «смерти» фронтенда было бы ошибкой. Спрос не исчез, он просто сузился до тех, кто способен приносить реальную ценность. И здесь проявляется давний раскол: 95% специалистов ограничиваются задачами уровня интерфейсной косметики, а оставшиеся 5% умеют проектировать системы, предлагать архитектурные решения и смотреть шире макета. Именно за этих людей компании будут бороться при любых условиях.

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

Что должен уметь фронтендер в 2025 году и как попасть в «5% из 95»

Уровень middle и senior во фронтенде больше не определяется знанием пары фреймворков. Базовый «джентльменский набор» очевиден: HTML, CSS, JavaScript и хотя бы один современный фреймворк — React, Vue, Angular или Svelte. Сегодня к нему де-факто добавился TypeScript: без него в резюме вы рискуете выглядеть устаревшими, даже если на проекте TS практически не используется. Работодатели хотят видеть уверенную работу с ним, потому что это напрямую ассоциируется со стабильностью и предсказуемостью кода.

Дальше идут надстройки, которые начинают выделять кандидата. Это метафреймворки вроде Next.js или альтернативы с упором на SSR и SSG, понимание разных паттернов рендера и умение применять их под конкретный продукт. Сюда же — юнит-тесты. Никто не будет устраивать экзамен на знание Jest, но сам факт владения тестированием сразу повышает ценность инженера.

Самый заметный маркер — архитектурные практики. Фронтендер, который мыслит архитектурно, понимает FSD, может объяснить, зачем нужны микрофронты (и когда они не нужны), сразу выделяется на фоне тех, кто «просто собирает фичи». Настроить приложение так, чтобы через два года его не пришлось переписывать, — это компетенция, которая превращает разработчика в дорогого специалиста.

При этом стек сам по себе не делает из мидла сеньора. Настоящее отличие — в мышлении. Сеньор умеет общаться с соседними командами, отстаивать нужные изменения в API или инфраструктуре, учитывать долгосрочные риски продукта. Это опыт, который не заменят ни курсы, ни туториалы. И именно он отличает того, кто «пишет код», от того, кто создаёт систему.

Найм и подготовка кандидата: где спотыкаются фронтендеры

Первое, что бросается в глаза при просмотре резюме фронтендеров, — это ошибки самопрезентации. Человек может написать «переписал приложение на новый фреймворк» и не уточнить, что это сократило время загрузки на 30% или сняло половину багов в проде. Для HR выглядит как рядовая строчка, хотя на деле это серьёзное достижение. Добавим сюда непонимание того, как работает HeadHunter: большинство кандидатов просто игнорируют логику поиска и фильтров, и их резюме тонет в выдаче. В итоге, 85% проблем — это не недостаток скиллов, а то, как они упакованы.

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

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

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

Кейс «Кода найма»: как Ярослав Грачёв выбил оффер в 380К

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

Первое, что пришлось менять, — резюме. Вместо сухого «работал три года» появилось описание проектов и секция «Обо мне». Ярослав даже перефотографировался, чтобы профиль выглядел живым. Параллельно он учился работать с алгоритмами HeadHunter и GPT: HH поднимал резюме в выдаче, а бот имитировал собеседования. Через две недели у кандидата уже был первый оффер.

Ситуация была интересной: предложение на 300 тысяч выглядело заманчиво, но ментор настоял не торопиться. Аргументы были простыми: поток откликов и приглашений уже пошёл, значит, офферы будут и дальше. Они вместе придумали безопасную отговорку для HR и договорились ждать неделю. Ставка сыграла — скоро пришёл новый оффер на 360 тысяч.

И тут началась работа с переговорами. Дмитрий считал, что Ярослав стоит дороже, и предложил сыграть на личных обстоятельствах: «Переезд, ипотека, второй ребёнок — дайте больше». Обычно такой прямолинейный запрос не работает, но в этот раз HR пошёл навстречу и поднял ставку ещё на 20 тысяч. Сработало сочетание доверительной коммуникации и того, что за спиной у кандидата был запасной оффер.

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

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

Итог кейса Ярослава показал, как за 14 дней можно пройти путь от шаблонного резюме до оффера выше ожиданий. Но за этим стояла системная работа: переписанное CV, домашка с тренировками, переговорные сценарии и дисциплина кандидата.

Советы начинающим фронтендерам

Дмитрий выделяет несколько аспектов, которым стоит уделять внимание в вопросе оффера мечты:

Не рассчитывайте только на ментора

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

Начинайте с основы, а не с фреймворка

Ключевой навык фронтендера — JavaScript. «Все есть JavaScript», — как сказал Илья Климов. React, Vue, Angular, Svelte — это лишь надстройки. Если понимаете сам язык и то, как он работает под капотом, вы сможете писать на чем угодно, хоть в фронте, хоть на Node.js в бэке.

Не ведитесь на быстрые рецепты успеха

Онлайн-школы и ютуберы любят обещать: «выучишь React — и всё в шоколаде». Но без знания JS никакой React не спасёт. На собеседованиях почти всегда спрашивают именно JavaScript, а не то, как вы намагичили интерфейс на очередном фреймворке.

Думайте о том, зачем работает код

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

История Дмитрия Борцова и Ярослава Грачёва — это иллюстрация того, что даже в перегретом и избирательном рынке фронтенда можно найти своё место. Ключ к успеху — не только в технической базе, но и в умении правильно упаковать опыт, показать насмотренность и держать фокус на том, что важно работодателю. Для джунов это часто означает вложиться в JavaScript, а не в очередной модный фреймворк. Для мидлов и выше — развивать софты и стратегически подходить к собеседованиям. А для всех уровней — не замыкаться в одиночном обучении, а искать наставников и сообщество, которые помогают расти быстрее.

Фронтенд в 2025-м всё ещё щедр, но не прощает случайности. И чем раньше разработчик перестанет полагаться на удачу и начнёт работать над собой системно, тем выше шансы получить оффер, который изменит карьеру.

Вместо стандартного похода к специалистам, он решил собрать уникальный слайдер, объединив корпус, плату и экран Z Flip5 с физической клавиатурой от BlackBerry Q10.

Получился кастомный смартфон-франкенштейн, который не только работает, но еще и вызывает ностальгию по эпохе слайдеров вроде Nokia N97 и Samsung D500.

Как устроен самодельный гибрид

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

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

Затем он:

• изготовил две алюминиевые рамки на фрезере — для верхней части с экраном и нижней с клавиатурой;
• встроил магнитный механизм слайдера, как у старых телефонов-раскладушек;
• подключил клавиатуру от BlackBerry Q10, спаяв проводку и установив Arduino Pro Micro — для эмуляции клавиатуры через USB;
• разработал и припаял собственную печатную плату, отвечающую за интерфейс между клавишами и системой Android.

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

Работает — даже в Minecraft

Проверить результат Плаза решил максимально просто: он запустил YouTube, Minecraft и Terraria, набрал текст и поиграл — все через физическую клавиатуру.

Управление действительно работает: клавиши не просто нажимаются, а отправляют события в систему как обычная USB-клава.

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

Ниже — текстовая версия выпуска. Подкаст можно посмотреть здесь.

Хобби№1: Косплей — от создания костюмов до выступлений на фестивалях

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

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

/Подкаст Антона о Косплее — здесь https://cosplay.mave.digital/ /

А каких героев ты обычно выбираешь?

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

А какие персонажи у тебя уже были? Может, есть любимые?

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

Первый персонаж — если вы знакомы с трилогией Mass Effect — это Шепард. Его можно модифицировать: менять внешность, плюс он носит шлем. Такая универсальная опция — любой человек подойдёт. Я как раз делал Шепарда для первого фестиваля в 2015 году, постепенно дорабатывал костюм, устранял недостатки. Участвовал с ним на Игромире и Комикконе в том же году.

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

После этого был Хищник из фильма «Чужой против Хищника». Грим не делал, потому что использовал маску, хотя сейчас многие заморачиваются и делают силиконовые маски с подвижными мандибулами. Потом был Маккри из Overwatch, Тор из «Тор: Рагнарёк», Иванушка из «Морозко», Айзек Кларк из Dead Space. В костюме Айзека Кларка удалось добавить кучу ардуиновских прибамбасов, чтобы шевелились разные части костюма.

У Айзека космический костюм — там и подсветка, и сервомоторчики. В костюме Хищника тоже были подобные элементы. Вот, это те персонажи, которых сейчас вспомнил.

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

Сколько ей сейчас?

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

Скажи, пожалуйста, сколько времени уходит на изготовление костюма?

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

Можно заказать индивидуальный пошив, можно сделать самому — тут всё упирается в свободное время и навыки. Я обычно делал примерно один костюм в год, потому что не спешил: вечером что-то поделал, потом ещё немного, и так постепенно. К дедлайну, к фестивалю, конечно, приходилось ускоряться, чтобы успеть подать заявку. Обычно нужно за месяц-два, иногда за три-четыре, отправить фотографии костюма хотя бы на 80% готовности, чтобы тебя рассмотрели и приняли.

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

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

Ну, то есть это ради атмосферы и удовольствия?

По-разному. Есть ребята, которые уже открыли мастерские и превратили хобби в работу. К ним можно прийти и сказать: «Хочу вот такую штуку, сделайте мне, я заплачу». Они уже работают на заказ.

Есть отдельные мастера по парикам, есть те, кто шьёт, кто занимается крафтом.

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

Есть и те, кто выступает на сцене, демонстрируя свои костюмы — показывают, на что способны. Другие выкладывают свои работы, процессы создания и обучающие материалы на Патреоне, Озоне и подобных платформах, получая оттуда доход и монетизируя своё хобби. Конечно, существует и более откровенное направление косплея — для фанатов, где больше открытых образов. Это тоже довольно популярно, и такие косплееры зарабатывают на Патреоне, Бусти и других сервисах.

Понятно. Я, кстати, заказывала сыну на день рождения квест, и там был этот Дэви Джонс. Костюм был классный.

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

Там был действительно впечатляющий костюм — настолько мощный, что даже дети испугались. Он выглядел очень эффектно.

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

Это те же мастера, которые делали крафт по комиксам Bubble — для сериала «Кибердеревня». Помнишь этих роботов, которые там играли главные роли? Вот есть мастерские, которые уже вышли на такой уровень и качество работ. Конечно, это уже не просто хобби, а настоящая профессиональная деятельность.

Я так понимаю, большинство всё-таки занимается этим для души?

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

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

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

Приятно просто провести время, а если у кого-то есть желание проявить себя на сцене, подготовить интересное выступление — это тоже здорово. У каждого свои приоритеты: кому-то важнее само общение, а кто-то хочет именно выступить.

Помню, когда ещё проходили Игромиры и Комикконы — кажется, это был 2018 или 2019 год, — приезжал Хидео Кодзима. Насколько я понимаю, тогда это было самое масштабное выступление: в зале собралось тысяч двадцать, а может, и тридцать человек. Мы выступали как раз перед ним, и получилось, что выступили перед огромной аудиторией, которую вряд ли где-то ещё соберёшь. Такой опыт, конечно, запоминается.

А вообще, это ведь западная культура? То есть всё это пришло к нам из Штатов, правильно я понимаю?

Если углубиться в историю, всё немного пересекается. Научно-фантастические конвенты, костюмированные мероприятия действительно появились в США ещё в середине прошлого века, если не ошибаюсь. Но толчок пришёл не только с Запада — огромную роль сыграл и Восток: аниме-фестивали тоже внесли свой вклад.

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

У меня тоже косплей ассоциируется прежде всего с аниме, а Комиккон — почему-то уже с косплеем. Для меня, как для обывателя, мероприятие скорее связано с сериалом «Теория большого взрыва».

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

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

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

Много и других интересных работ встречается. Были, например, Бабы Яги, был парный косплей на Шапокляк и почтальона Печкина — люди в возрасте сделали, получилось очень мощно. Таких примеров тоже немало.

Смотри, а ты говорил, что сам шил костюмы. Это же надо уметь шить.

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

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

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

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

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

Понимаю, но если в среднем — какой стартовый чек? Вот кто-то решит заняться.

Если хочется что-то простое, например, по китайским играм вроде Star Rail или Honkai — те, в которые сейчас много кто играет на телефонах, — у китайцев можно купить готовый костюм за 5–9 тысяч рублей или собрать что-то самому.

У меня бюджеты обычно выходили в районе 20, 30, иногда 40 тысяч — относительно недорого. Грубо говоря, начиная от 10 тысяч уже можно что-то сделать, а дальше цены могут уходить в бесконечность — всё зависит от материалов и сложности образа. Например, если брать персонажей из игры или сериала The Last of Us, где постапокалипсис, у них одежда в основном довольно обычная. Нужно просто найти похожие вещи в обычных магазинах, состарить их, добавить пару характерных деталей, сделать грим, подобрать парик. Или, может быть, ты уже внешне похож на Педро Паскаля или Джоэла из игры — тогда вообще всё просто. В итоге можно уложиться в очень скромный бюджет. Всякое бывает.

То есть есть варианты, если хорошо поискать.

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

Хобби№2: 3D-печать — от костюмных деталей до домашних проектов

Скажи, пожалуйста, а как тебе помогает такое хобби отвлечься от работы?

Как я уже говорил, во-первых, это возможность что-то сделать руками. Во-вторых, постоянно осваиваешь новые техники — сейчас ведь многое делается с помощью 3D-печати, печатают разные элементы костюма. Я сам тоже постепенно напечатал много разных деталей. Опять же, сделал что-то своими руками, освоил что-то новое, получил реальный результат — и это очень заряжает.

Получается, ты два года был без этого хобби, пока ребёнок был маленький?

Да, последний раз на фестиваль ходил, кажется, в двадцать третьем году, когда дочери ещё не было и года. А так — действительно, не успевал, потому что всё время приходилось следить за ней, как хамелеон одним глазом. Мама, конечно, присматривала, но в любой момент дочка могла подкрасться к кому-нибудь с фломастером и что-нибудь нарисовать. Так что да, времени не было. Сейчас детские сады постепенно возвращаются, в сентябре снова пойдём. Будет чуть больше свободного времени и чуть меньше синяков под глазами — появится минутка и на что-то ещё.

А как тебе эти два года без хобби? Тяжелее восстанавливаться после работы?

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

Выход из декрета: «Давайте мне всю работу, я буду работать».

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

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

Я тоже так делаю. Всё нормально.

А всё-таки есть у тебя какая-то рекомендация для сотрудников или коллег — нужно ли отвлекаться от работы?

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

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

Я бы не сказал, что у них есть какое-то преимущество. Представь, если человек, например, продавец, двенадцать часов в «Пятёрочке» пробивает товары и расставляет их по полкам — разве ему не захочется заняться чем-то другим, отвлечься? Думаю, что нет разницы. Просто у IT-специалистов обычно больше возможностей для разных хобби.

Почему я упоминал работу руками? Она особенно популярна у многих именно потому, что позволяет переключиться на другое поле применения своих навыков. Возможно, я не могу сравнивать, но те, кто весь день работает руками, наоборот, часто хотят заняться чем-то отвлечённым от физического труда.

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

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

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

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

У меня похожая история, я тебя прекрасно понимаю. Например, посмотреть какую-нибудь комедию кажется глупым и бесполезным. Нужно обязательно выбрать арт-хаус, после которого сидишь, смотришь в стену полчаса и думаешь: зачем?

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

Да, я тоже только после тридцати поняла, что можно спокойно закрыть неинтересную книгу, выключить фильм, который не зацепил, и делать что-то для себя, а не ради мифического успеха. К этому действительно приходишь со временем. Кстати, ты говорил, что печатал на 3D-принтере. Расскажешь подробнее, насколько это сложно? Насколько нужно быть инженером?

Смотри, сейчас 3D-принтеры стоят недорого — даже шесть лет назад они были вполне доступны. Первый свой принтер я купил за 15 тысяч — это был простой Anycubic Mega S. Он спокойно прослужил пять лет, и до сих пор работает: если что-то сломается, я его починю, и на даче он будет трудиться дальше.

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

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

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

А потом, если появляется желание, многие начинают сами заниматься 3D-моделированием. Есть разные программы — например, Compass, Fusion, параметрическое моделирование — где можно рисовать и чертить нужные детали. Создаёшь модель, и вперёд — печатать. Хочется, скажем, для машины напечатать какую-нибудь рамку, как у меня коллега делал, или сделать заглушку для какой-то детали — и понеслось. В принципе, можно даже скульптурить персонажей или что-то подобное и тоже печатать.

Вот, например, сейчас у меня есть подпроект: я напечатал фигурки персонажей для города Рыбинска. Идея такая — вместе с приложением я потом тайно расставлю их по городу.

Люди смогут, как в Pokemon Go, ходить, сканировать QR-коды на них и собирать коллекцию в приложении. Простоят, как говорится, до первого вандала, но почему бы и нет.

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

Мы с женой как-то сделали бренд под названием «Skull Pin» — заколки для волос в виде черепов, щупалец и тому подобного. Участвовали с ними на нескольких маркетах в Петербурге. Все мероприятия проходили в Севкабеле — тоже было интересно, прикольно.

А скажи, расходники для 3D-принтера вообще дорогие?

Слушай, для домашнего использования есть два основных типа 3D-принтеров. Одни работают с пластиковым прутком: он проходит через нагревательный элемент и печатает полоской. А есть фотополимерные принтеры — там снизу экран, который засвечивает жидкую смолу ультрафиолетом, и она застывает слой за слоем, формируя 3D-модель. Фотополимерные модели получаются гораздо более детальными, например, для фигурок персонажей — самое то.

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

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

Да, я сейчас смотрю, на маркетплейсах много всяких — дракончики, динозаврики.

Потому что 3D-модели есть в открытом доступе: бери и печатай. Сейчас на любую ярмарку придёшь — обязательно найдётся лоток с такими поделками. И это по всему миру так. Многие мастерские и ярмарки этим занимаются. Но, честно говоря, хоть бы кто-нибудь свою модель придумал, а то все одну и ту же друг у друга копируют.

У меня сын ходил на робототехнику, и там им выдавали какие-то билетики, вроде игрушечных денег. Они их копили, а потом могли обменять на игрушку, напечатанную на 3D-принтере — прямо там, на месте. Я сама видела: стоит 3D-принтер, печатает.

Вполне интересный вариант. Сейчас в некоторых школах уже ставят 3D-принтеры — можно что-нибудь напечатать, поделать. Только нужно учитывать, что печать обычно идёт не быстро.

Да, я видела сам процесс — всё происходит довольно медленно и непросто.

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

Расскажи, пожалуйста, а что ты для костюмов печатал на 3D-принтере?

Например, для костюма Тора я делал бляшки, которые держат плащ — их печатал на принтере. Для косплея по «Морозко», по Иванушке, я прототипировал и делал челюсти, потому что там есть медвежья голова. Саму голову я лепил из специального материала и обклеивал шерстью, а челюсть должна была открываться. Я смоделировал и напечатал две пластиковые основы для челюсти, на которые потом крепится остальная часть маски.

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

Правда, чтобы всё это придумать, нужно быть инженером.

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

А ты сам рисовал чертёж этой челюсти?

Сначала сделал эскиз на бумаге, сфотографировал его, а потом уже по нему нарисовал чертёж во Fusion 360. Напечатал первый вариант — оказался маловат, напечатал второй, потом третий — вот этот уже подошёл, и процесс пошёл.

Видишь, всё-таки быть инженером полезно.

Возможно. Хотя, может, художник нарисовал бы эту челюсть ещё лучше и быстрее, сразу в 3D. Почему бы и нет?

Хобби№3: Озвучка аудиокниг и пет-проекты

Пэт-проекты мы все пишем — это развлечение у нас до сих пор остаётся. А из совсем необычных хобби… Недавно попробовал озвучку аудиокниг — вдруг кому-то тоже захочется попробовать.

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

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

И когда редактируешь запись, после того как записал какой-нибудь кусочек текста, думаешь: «Боже мой, сколько же у меня там всяких звуков изо рта вылезает, ужас!» Забавная тренировка. На этом даже можно зарабатывать, если озвучивать хотя бы немного популярные книги.

Я, например, участвовал через Литрес Чтец — у меня там вроде 12 книг: часть — книги, часть — рассказы. С этого я зарабатываю гигантскую сумму — хорошо, если тысячу рублей за полгода.

Книги не особо популярные, конечно. Так что, если рассматривать это как заработок, времени оно не стоит. Но как интересный опыт — вполне забавная штука.

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

Почему пет-проекты остаются самым понятным способом войти в IT

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

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

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

Для опытных специалистов пет-проекты остаются способом выйти за рамки своей узкой специализации. Они помогают увидеть полный цикл: от взаимодействия с оборудованием и выбора форматов данных до интеграции в интерфейс и настройки мониторинга.

Как работают петы для разных грейдов:

• Для начинающих и мидлов пет-проекты — понятный маркер потенциала. Публичный репозиторий с живой историей коммитов показывает процесс мышления. Это сигнал инициативности и самостоятельности.
• Для middle-разработчиков активный проект говорит о зрелости и желании расти, а также о способности мыслить архитектурно и предлагать решения с нуля. Часто именно такие проекты помогают вырасти до роли тимлида.
• Для senior-уровня личные проекты могут быть признаком глубокой вовлечённости и лидерских качеств. Однако в некоторых компаниях это может вызвать вопросы о приоритетах и рисках отвлечения от основных задач — здесь всё зависит от контекста.

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

Как выбрать идею пет-проекта

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

Признаки «живой» идеи

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

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

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

Где искать идеи

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

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

Работа в команде даёт дополнительный ресурс — внутренние боли, на которые не хватает рук. Даже простой internal tool с внятным UX может стать ценным проектом.

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

Форматы пет-проектов, которые реально прокачивают

«Витринные» проекты против реальных

Так называемые «витринные» пет-проекты — это работы для портфолио, обычно размещённые на GitHub или другой публичной платформе. Их цель — показать навыки и интерес к определённым технологиям. Как правило, это одноразовые демонстрации, которые не получают развития.

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

Типы проектов, которые чаще приводят к офферам

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

Тип проекта — бот, API, open-source-библиотека или мини-продукт — не так важен. Ключевые критерии:

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

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

Форматы, которые развивают

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

Иногда такие проекты перерастают в полноценный продукт — с регистрацией прав, подачей в акселератор, созданием команды. Даже если этого не произойдёт, сам процесс — ценный опыт.

Что убивает пет-проекты

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

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

Привычные ошибки, которые мешают доводить до результата

• Гипер сложность на старте. Вместо того чтобы упростить задачу и разбить её на этапы, многие бросают проект, когда понимают, что не тянут.
• Уход во второстепенные фичи. Неделями можно оттачивать анимации или кастомные библиотеки, забывая, что основной функционал ещё не работает.
• Неправильные приоритеты. Вместо итерационного подхода («сначала сделать главное, потом расширять») ресурсы тратятся не туда.
• Отсутствие финальной точки. Если нет чётко определённого результата, к которому можно прийти, нет и ощущения успеха — а значит, пропадает энергия двигаться дальше.

Как правильно выстроить пет-проект

У пет-проекта нет менеджера, дедлайна или бизнес-заказчика — значит, вся организация работы лежит на вас. От того, как вы её построите с самого начала, зависит, дойдёт ли проект хотя бы до рабочей версии.

С чего начать — минимальная версия

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

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

Приоритеты: фичи, архитектура, документация

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

• Сложность реализации (1–3 балла)
• Ценность/интересность (для вас или проекта в целом)

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

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

Тестирование и фидбэк на ранних этапах

Ранняя обратная связь спасает от лишней работы и блуждания в идеях.

• Если проект понятный и бытовой — тестируйте на друзьях и родственниках. Подготовьте набор вопросов: что удобно? что запутало? чего не хватает?
• Если проект технический (например, API), ищите тестировщиков в профильных чатах, вузовских группах, на тематических форумах. Можно предложить бесплатный доступ в обмен на комментарии.

Не бойтесь показывать «сырой» продукт — просто объясните, что это черновик, и вам нужен честный фидбек. Чем раньше получите фидбэк, тем меньше сил уйдёт в пустоту.

Как масштабировать своего «питомца»

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

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

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

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

Советы по масштабированию

1. Вести осмысленные разговоры с потенциальными пользователями, экспертами и теми, кто решал похожие задачи — это поможет понять, что действительно ценно, а что мешает.
2. Оценить масштабируемость: проект может быть полезным на малом масштабе, но рушиться при росте.
3. Определить вектор: B2B или B2C, чёткий портрет потребителя. Без этого презентация будет размыта.
4. При планах на инвестиции — предварительная оценка рынка, прогноз доли и гипотеза роста.
5. После подготовки — выход «в поле»: участие в отраслевых событиях, акселераторах и деловые знакомства.

Упаковка — это проверка зрелости проекта. Если его можно показать и объяснить, значит, он готов к следующему этапу.

Что дальше: превращаем проект в карьеру

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

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

Когда стоит показывать проект миру

1. Если он открыт на GitHub, уже доступен. Активно рассказывать о нём лучше после минимальной упаковки: README, описание, структура, работающая ключевая функция.
2. Для продвижения себя как продуктового специалиста, поиска команды или инвестиций нужно полноценное оформление: описание, демо, фидбэк, проработанная аудитория и сценарии применения.
3. Для портфолио или аргумента на собеседовании достаточно, чтобы проект был рабочим, логичным и понятным.

Удачи в петах!

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

1. H3LLO.CLOUD: для быстрого старта

Если вы запускаете стартап, делаете MVP или просто не хотите платить больше за инфраструктуру — у H3LLO.CLOUD есть стартовый набор на 12 месяцев, который бесплатно выдается при создании аккаунта.

Специально собрали предложения под запросы небольших команд и стартапов: 2 базовые ВМ Capsule.S (1vCPU/2GB RAM/12,5 NVMe), 5GB Network SSD, 5GB Object Storage, 1 Basic LoadBalancer, 1 IPv4, мониторинг.

Этого набора более чем хватит, даже для довольно посещаемых проектов. А тем, кому нужно больше, в ассортименте полный набор IaaS и PaaS решений и дружелюбная команда, которая помогает с их внедрением.

Облако H3LLO CLOUD подойдет тем, кто:

• запускает MVP и хочет минимизировать издержки на старте;
• работает с Big Data и аналитикой;
• использует Kubernetes или контейнеризацию;
• разворачивает inference-серверы под ИИ-модели;
• делает бэкапы и настраивает восстановление после сбоев.

H3LLO CLOUD работает с посекундной тарификацией: платите только за то, чем действительно пользуетесь. Можно выставлять счета на юрлицо, есть постоплата. Обещают добавить Cloud API, шаблоны деплоя, маркетплейс SaaS-решений и serverless — но даже сейчас по функциональности всё покрыто: базы управляемые, биллинг гибкий, интерфейс понятный.

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

2. L1veStack: полный контроль бюджетов

Если вы только запускаете проект и хотите чётко контролировать, за что платите — L1veStack делает ставку на полную прозрачность. Никаких округлений, скрытых тарифов и загадочного биллинга. Всё просто: используете ресурсы — платите посекундно, не используете — не платите вообще.

Что вы получаете на старте:

• На этапе беты L1veStack можно запустить до 3 проектов, каждый из которых может использовать до 1 vCPU и 4 ГБ RAM.
• У них есть уникальный вариант тарификации: существует нетарифицируемый пороговый уровень для небольших проектов, и оплата начинается только при превышении этих значений. Идеально для пет-проектов и стартапов, когда вы еще не знаете точных потребностей в мощности.

L1veStack построен как платформа, которая растёт вместе с вами:

• Этап 1: Пет-проекты и небольшие стартапы. Здесь вы используете нетарифицируемый порог.
• Этап 2: Команды и фрилансеры. Сервис выгодно использовать для управления Dev и Stage окружениями.
• Этап 3: Инструмент разработки для команд внутри enterprise. Предлагаются выгодные тарифы для dev/stage окружений и возможность переводить продакшен на собственные сервера под контроль ваших DevOps специалистов.

Из дополнительного и про биллинг:

В целом, всё удобно, гибко, прозрачно — есть все необходимые функции: GitHub wizard, автоматический SSL-сертификат (авто-SSL) и понятные объяснения для переменных.

Плата только за фактические минуты использования CPU и RAM. Есть поминутный счетчик и предиктивная симуляция затрат, чтобы прогнозировать расходы до того, как они возникнут.

Сервис предоставляет Live-индикаторы, который отслеживает нагрузку в реальном времени, human-friendly ошибки и мгновенный preview изменений.

3. Облачная платформа Selectel: Масштаб, безопасность и опытная поддержка

Selectel предлагает более 50 продуктов — от виртуальных и выделенных серверов до готовых к работе баз данных, кластеров Kubernetes, объектного хранилища, CDN и решений для безопасности. Всё запускается за пару кликов через удобную панель управления, API или Terraform.

Для стартапов действует акция: Кешбэк до 1 000 000 бонусов. Каждый месяц Selectel возвращает 30% бонусами от расходов на инфраструктуру. Кешбэк начисляется в течение 12 месяцев.

Selectel подходит под задачи любой сложности:

1. Разворачивать MVP и первые версии приложений — настраивать среды разработки и тестирования.
2. Запускать приложение в продакшен и масштабироваться под нагрузкой.
3. Хранить и обрабатывать данные — платформа позволяет хранить большие объемы данных на дисках объемом до 10 ТБ и более.
4. Защитить данные от сетевых атак — есть готовые инструменты защиты от DDoS-атак и инструменты резервного копирования ,
5. Соответствовать требованиям безопасности — платформа хранит персональные данные до 1 уровня защищенности и следует требованиям 152-ФЗ, 21 приказа ФСТЭК, PCI DSS, ISO 27001, ГОСТ Р 57580.

Насколько удобно работать

Инфраструктура строится как конструктор: 50+ продуктов и сервисов можно объединить через глобальный роутер, связать с собственной инфраструктурой (настраивать гибридные решения), масштабироваться в несколько кликов. Не нужно разбираться со сложными настройками — запустить сервис можно в несколько кликов из панели управления или с помощью Terraform. Есть IAM-система для разграничения доступов и определения ролей пользователей, чтобы настроить федерации удостоверений через SSO и соответствовать требованиям корпоративной безопасности.

Биллинг и поддержка

Биллинг облачной платформы работает по модели pay-as-you-go: платите только за то, что реально используется. При этом можно сэкономить до 75%, с прерываемыми ВМ и функцией заморозки — удобно, если нужно приостановить проект или снизить расходы ночью.

Техподдержка работает 24/7, специалисты помогают с подбором необходимой инфраструктуры и решений, настройками и функциональностью. Берут полную ответственность за работу инфраструктуры и быстро решают любые возникающие вопросы. Для сложных задач, например, миграции на инфраструктуру Selectel можно подключить услугу Администрирования.

4. RTCLOUD: Гибридное облако для стартапов с масштабом и безопасностью

RTCLOUD — это гибридное облако, объединяющее локальные ресурсы с публичным облаком провайдера для создания гибкой, масштабируемой и безопасной ИТ-инфраструктуры. Подходит стартапам, которым нужно быстро адаптироваться к нагрузкам без крупных затрат.

RTCLOUD предлагает гибридное облако, объединяющее частное и публичное облако:

• Единый каталог приложений: Доступ к приложениям в обоих облаках без разделения.
• Единое адресное пространство: Перемещение виртуальных машин и приложений без изменения сетевых настроек.
• Унифицированное управление: Просмотр, копирование и перемещение нагрузок (виртуальные машины, vApp, шаблоны) между облаками.
• Инструменты мировых лидеров: Veeam Backup & Replication для репликации и управления восстановлением, vCloud Availability для миграции и Disaster Recovery (DR).

Поддерживаются сценарии:

• Уменьшение нагрузки на локальные ресурсы.
• Запуск сервисов с непроверенной нагрузкой.
• Организация тестовой площадки.
• Резервирование инфраструктуры.

Дополнительные возможности

• Облачный ЦОД: Инфраструктура без капитальных затрат, высокая надёжность, масштабирование.
• Резервный ЦОД: Быстрое восстановление с минимальным RTO.
• Объектное хранилище S3: Хранение архивов, резервных копий и медиа-контента.
• Kubernetes-as-a-Service: Готовая контейнерная инфраструктура с контролируемым периметром безопасности.
• Облачный десктоп (VDI и VDI GPU): Доступ к рабочим местам, включая производительные для конструкторов.
• Backup as a Service (BaaS): Управление копиями и расписанием для надёжного хранения.
• Размещение оборудования: Дата-центры TIER III с интеграцией облачных сервисов.

Биллинг и поддержка

• Гибкая оплата: Pay-as-you-go, без инсталляционных платежей, платите только за потреблённые ресурсы.
• Экономия: Нет затрат на покупку или модернизацию оборудования, масштабирование по потребностям.
• Техподдержка: 24/7, помощь с настройкой инфраструктуры, миграцией и решением задач.

На что ориентироваться при выборе облака

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

H3LLO.CLOUD делает ставку на доступность, предлагая стартовый набор за 5 000 рублей с виртуальными машинами, базами данных и объектным хранилищем, что идеально для небольших команд, работающих с Big Data или ИИ.

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

Selectel обеспечивает масштабируемость и безопасность, с инструментами для защиты данных, что важно для проектов с высокими требованиями к соответствию 152-ФЗ.

RTCLOUD предлагает гибридное облако, которое объединяет локальные и публичные ресурсы, позволяя масштабироваться под пиковые нагрузки и минимизировать расходы благодаря модели pay-as-you-go без инсталляционных платежей.

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

P.s. Это перевод зарубежной статьи. Предлагаем подискутировать о вопросе в комментариях.

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

Через несколько месяцев после того, как вы почувствуете усталость, console.log() начнет казаться непосильной задачей, а баг, который обычно исправлялся за час, ломает изнутри.

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

И статистика это подтверждает: по данным Stack Overflow, 32% разработчиков несчастны на работе, а еще 47% выживают на автомате, не чувствуя вовлеченности. Это значит, что почти 80% специалистов находятся в зоне риска эмоционального выгорания, хотя снаружи всё выглядит стабильно.

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

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

Пятиминутная привычка, которая меняет всё

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

Формула успеха звучит так: Минимальные усилия → Последовательность → Идентичность → Восстановление связи. Начав с малого, можно постепенно вернуть уверенность и интерес к профессии.

Как работает эта практика:

1. Выберите простое действие: например, написать одну функцию или изучить один метод в документации.
2. Установите таймер на 5 минут: это снижает порог входа и делает задачу необременительной.
3. Делайте это каждый день: даже если результат минимален, регулярность формирует привычку.
4. Не ждите вдохновения: действие само по себе создает мотивацию.

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

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

Как вернуться к программированию и не выгореть снова

Если хочется вернуться к программированию без риска снова выгореть, помогут простые принципы:

Опустите планку — и опустите её ещё раз. Если на старт уходит больше минуты, задача слишком сложная.

Не отслеживайте результат. Никаких счётчиков строк, коммитов и диаграмм продуктивности. Задача — восстановить доверие к себе, а не нарастить темп.

Избавьтесь от чувства вины. Пропустили день? Не страшно. Один пропуск не должен превращаться в цикл стыда. Выход из выгорания — не марафон продуктивности.

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

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

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

• Книги: «Атомные привычки» Джеймса Клира для понимания силы маленьких шагов.
• Курсы: платформы вроде Codecademy или freeCodeCamp для легкого возвращения к основам.
• Сообщества: нишевые Discord-серверы (например, по Python или Rust) или Reddit (r/learnprogramming).
• Трекеры привычек: приложения вроде Habitica для отслеживания прогресса.

Вместо итогов

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

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

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

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

Бонус от экспертов: как пережить выгорание и вернуться к работе

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

Елизавета Якушева, тестировщик, автор тг-канала Press F to Debug:

Для меня выгорание — самая большая и страшная проблема в карьере. Абсолютно всё зависит от неправильно выстроенных ожиданий

Елизавета выделяет два разных типа выгорания:

1. От самой работы — стресс, рутина, груз ответственности.
2. От постоянной учёбы и самосовершенствования — давление трендов, ощущение собственной «недостаточности», переизбыток бесполезной информации.

На её взгляд, большинство советов работают только в рамках «программирования для себя», но они не решают главного — внутренней мотивации.

Чтобы справиться, она предлагает задать себе простой, но важный вопрос:

«Зачем я это делаю? Что будет, если я перестану?»

Мы ходим на работу, чтобы получать деньги. Без этого мы не можем оплатить свои счета за ипотеку или продукты.

Стресс от груза ответственности решается простой мыслью: "Я здесь, чтобы выполнять работу так, как могу. Если я не успеваю что-то сделать вовремя, я умираю, у меня температура под 40, у меня отвалилась нога — вселенная не остановится, если ты возьмёшь тайм-аут в виде отпуска или day-off. Ракета не полетит в космос, и никто глобально не умрёт."

Для пет-проектов помогает осознанность: понимание, зачем ты вообще этим занимаешься.

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

Анастасия Егорова, фронтенд-разработчик, автор канала «Код и кофе»:

Анастасия комментирует технику «5-минутных привычек», описанную в оригинальной статье, и делится, как адаптировала её под свой сложный ритм:

У меня был период жизни, когда я полтора года работала на двух фуллтайм-работах… Иногда, просыпаясь зимним утром в 6:45, чтобы выйти на удалённый созвон в 7:00, я думала, что больше всего хочу уволиться со второй работы. Но нужно было работать.

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

Где-то на второй–третьей пятиминутке меня затягивало, и 5 минут превращались в полноценный час-два работы без переключения. Несколько таких подходов в течение дня — и к вечеру работа была сделана, а иногда ещё и сварен борщ, и приготовлены котлетки.

Да, бывают и провальные дни — но даже тогда, по её словам, важно просто не бросить всё совсем.

Я реально работала 5 минут, а потом 10 минут отдыхала… и к концу дня с помощью этих пятиминуток было сделано не так много. В такие дни я просто от себя отставала, радовалась, что я сделала хотя бы эти пятиминутные задачи, а не прокрастинировала весь день.

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

Новички, когда сталкиваются с пет-проектами, бросаются в две крайности. Создают очередной To-Do list, который ничем не выделяется, либо пытаются сделать что-то слишком сложное, например, убийцу Notion, и забрасывают работу на полпути. Так как же выбрать идею, которую получится довести до конца?

Ключевые нюансы при выборе идеи пет-проекта

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

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

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

Как-то я пришёл на хакатон — занимался рекомендательными системами. Тогда был пик популярности Word2Vec — это модель, которая переводит слова в векторы и позволяет находить между ними смысловую близость. Я посмотрел на статистику и увидел: на одном из сайтов 25% запросов не давали результатов. Тут возникла идея, как это улучшить.

Решил собрать демку и сделал прототип: например, на запрос «кресло из крокодиловой кожи» модель показывала зелёные кожаные кресла. Не крокодиловые, но всё равно релевантные запросу.

За неделю допилил прототип до презентабельного состояния, показал коллегам и руководителю. Они дали «зелёный свет», через 2 месяца была первая MVP, которую уже начали продавать существующим клиентам. Ещё через месяц — первый клиент, интеграция, запуск.

Спустя ~5 лет количество клиентов уже измерялось сотнями :)

Подумайте, какие навыки хотите показать

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

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

Не затягивайте со сроками

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

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

Основная ошибка — это незаконченные, «сырые» решения. HR смотрят на проекты, в том числе, как на способность завершать начатое. Если в портфолио много таких работ, это наводит на мысли, что разработчик быстро теряет интерес, плохо планирует время или бросает задачи при первых трудностях.

Не используйте учебные работы, либо используйте их правильно

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

1. У вас и ваших одногруппников эти работы одинаковые. Представьте лицо HR, когда он увидит несколько похожих проектов в разных резюме.
2. Учебные проекты не совсем ваши, ведь вы повторяли код и основные конструкции за преподавателями. Работодателю важно, как вы пишете сами, а не копируете.

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

Всё равно не могу ничего придумать, что делать?

Если самостоятельно не получается что-то придумать, то можно спросить у ИИ.

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

Пример промпта для идеи пет-проекта:

Возьмите задачу с фриланса

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

Спросите друзей или аудиторию в соцсетях

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

У меня был разработчик, уставший от хаоса в списках фильмов, которые он хочет посмотреть. Сделал пет-проект — личный медиапланировщик с нейтральным UI. Проект не стал стартапом, но в портфолио смотрелся отлично. Если сложно — можно взять существующую идею и улучшить. Например, сделать привычный To do-лист с уклоном в UX, нейросети или интеграции. Главное — показать свою силу, а не сделать ещё один клон.

Как довести пет-проект до конца и не забросить его

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

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

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

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

Разбейте проект на задачи и подзадачи. Например, дизайн плеера, его вкладок, основная логика, подключение API, отладка.

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

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

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

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

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

Если очень грубо, то ориентир выглядит так: 80% кода — это знакомый нам стек, 20% — место для экспериментов и обучения. Такой подход позволяет прокачать новые навыки и довести проект до финала без выгорания.

Занимайтесь регулярно по чуть-чуть. Берегите себя, отдыхайте, не надо сидеть по 5 часов в день над проектом, если за него не платят. Вначале можно выезжать на мотивации, но со временем это приведёт к выгоранию.

Лучше постараться выработать привычку и заниматься петом, например, каждый день по 30 минут. Не можете соблюдать эту привычку по каким-то причинам? Не проблема, вместо 30 минут найдите 5. Да, за это время вы ничего не успеете, но сохраните «регулярность» — на следующий день будет проще.

Делитесь результатами. Не держите всё в столе, делитесь ходом работы и результатом. Покажите ваш MVP друзьям, обсудите его на форуме, заведите репозиторий на GitHub. Без обратной связи можно легко что-то упустить.

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

А вот ещё несколько советов от Анастасии Егоровой — фронтенд-разработчика, автора программы курса SkillBox по Vue 3 и ведущей ютуб-канала CosyFrontend.

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

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

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

2. Избегать перфекционизма — сначала сделать рабочую версию, а потом постепенно ее улучшать.

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

P.S. Когда мы обсуждали тему пет-проектов и их забрасывания в одном из айтишных чатов, один из разработчиков отметил: «А никак не нужно доводить их до конца — пет-проекты для того и существуют, чтобы попробовать на них новую идею и забросить». Так что такое мнение тоже есть, но справедливо ли оно для вас — решайте сами 😀

Как оформить пет-проект

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

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

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

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

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

Добавьте скриншоты, гифки, видео работы сервиса. А ещё лучше его демоверсию.

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

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

Опишите результаты по конкретным метрикам, если, конечно, это возможно. Опубликовали приложение в Google play и получили хорошее удержание пользователей? Расскажите об этом. Вашу фичу оценили в социальных сетях? Поделитесь приятным фидбеком. Метрик нет, делали проект только под себя? Расскажите, как он помог вам решить проблему.

Лучше всего оформить проект на GitHub с описанием задач, технологий и особенностей реализации. Выделяются разработчики, которые показывают, что не просто пишут код, но и обосновывают решение и объясняют, как всё устроено.

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

Распишите проект как кейс. Подготовьте шпаргалку. Это мини-история, где вы рассказываете о проекте. Какая проблема побудила вас его сделать, какие возникли трудности на этапе разработки, как их решали, какой получили результат. У вас получится подробное описание пути разработки от идеи до финала.

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

Главное, не делайте проект ради проекта, старайтесь принести какую-то пользу и здраво оценивайте свои возможности.

У меня в голове появилась идея AI тьютора. Это синергия двух популярных сегодня концепция: онлайн-обучения и ИИ. По сути, я создал сервис генерации образовательного контента с возможностью проверить знания и доступом к умному виртуальному помощнику.

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

Что получилось

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

В ответ AI, используя заранее описанный в скрипте промпт, формирует список уроков.

Затем можно попасть в каждый отдельный урок и сгенерировать лекцию. Можно просто нажать кнопку, а можно написать дополнительные пожелания, которые в скрипте подтянутся к промпту.

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

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

Не так давно я добавил функционал озвучки лекций с помощью Yandex Speechkit. Звучит вполне сносно, если, конечно, контент — не англоязычный.

Вобщем, содержание уроков получается адекватным. Особенно, если тема — гуманитарная.

Что под капотом?

По умолчанию я использовал open-source модель Qwen2.5-32b, которую спустя время сменил на Qwen3-32b. При этом пользователь может в личном кабинете подключить свой аккаунт от другой более продвинутой и быстрой модели для генерации более качественного контента. Например, GPT от OpenAI. Лично я тестировал разные варианты и все они +- одинаково справлялись с генерацией текстов. Но GPT от Open AI, конечно, справляются с задачей немного быстрее — примерно на 20-30.%

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

Запросы к LLM идут с заранее прописанными промптами, в которые вставляется пользовательский ввод. Единственное, что из-за ограничений OpenAI для РФ пришлось хостить сервис в Digital Ocean. Забавно, что изначально он вообще был установлен просто дома на подоконнике на Raspberry Pi. Потом пару раз заглючил провайдер. Я посмотрел на это и решил, что потратить 1000р в месяц не жалко, если сервис будет работать стабильно. К тому же, не пришлось организовывать отдельный прокси, чтобы запросы в OpenAI отрабатывали корректно. Я, конечно, такой вариант тоже протестировал и в целом он оказался рабочим. Но иностранное облако оказалось более простым и изящным решением.

Сложности

Основная проблема — стриминг ответов на страницу из-за проблем с LLM. Когда стоит флаге stream=True, а запуск происходит через Nginx + Runserver, то всё работает нормально, ответ модели выводится на страничке. Но в случае uvicorn и gunicorn решение не работает. Весь ответ на каком-то этапе буферизируется и потом кучно попадает на фронтенд. То есть, у нас одни и и те же конфиг nginx, бекенд и JS на странице. Но без Runserver ничего не стримится. Моих знаний пока не достаточно, чтобы разобраться, в чём же именно причина.

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

Сам сервис написан на классическом варианте стека: Django + Jinja Templates. Нет никакого модного фронтенд-фреймворка, т.к. я вообще в них ничего не понимаю. Вся эта история задумывалась как учебный пет-проект, который неожиданно перерос в нечто большее.

Дальнейшие планы

Внедрить возможность выдавать доступ к курсам определённым юзерам по email. Сейчас можно опубликовать курс для всех в общую библиотеку. Но есть мнение, что не всем пользователям захочется делиться созданным контентом со всеми подряд.

Двигаться в сторону RAG. Сейчас это реализовано, но полноценно я им ещё не пользовался. Если в личном кабинете добавить свою GPT- модель, то можно создавать курс на основе загруженных файлов. Под капотом используется OpenAI Assistants API.

Сейчас есть редактор уроков, что позволяет полученный от ИИ контент самостоятельно отредактировать через WYSIWYG редактор. Но стоило бы ещё проработать создание авторских курсов, когда пользователь использует свои заметки и дорабатывает их с помощью нейросети. Затем, конечно же, финально правит полученный результат в редакторе, дополняя видео, картинками или файлами. Вуаля: курс можно опубликовать в библиотеку или поделиться с конкретными пользователями с помощью ссылки. Ну или выгрузить в PDF — эта функция доступна уже сейчас.

Если вам интересно, мой сервис уже можно протестировать . Для этого авторизуйтесь через google-почту и на open source-модели qwen 3 сгенерируйте парочку курсов на любую тему. Поделитесь в комментариях, как всё прошло и что получилось в итоге;

В будущем планирую написать вторую часть статьи и рассказать, что происходит в сервисе на уровне кода.

Аким Саввин, тимлид команды бэкэнда в ВСК, ментор Эйч Навыки и автор тг-канала, расскажет, зачем разработчики скручивают и накручивают опыт и как это помогает им попасть в компанию.

Опыт — новая нефть

Недавно мы писали про то, что рынок IT перегрет, зарплаты падают, джунов — не берут на работу. Усугубляется ситуация тем, что молодых специалистов стало очень много. Например, на hh.ru количество откликов на джуниор-вакансию может достигать нескольких тысяч. И самые банальные критерии, по которым кандидатов будут отсеивать эйчары — вуз, опыт и возраст. Даже если в объявлении указан минимальный опыт и «базовые знания», на собеседования будут звать тех, у кого был серьезный опыт в разработке — и то, далеко не всех.

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

Недавно в ТикТоке завирусились видео одного «разработчика», который решил провести эксперимент, сможет ли он выдумать резюме, пройти эйчаров и попасть в компанию на зарплату 500+ тысяч. Вы не поверите, но у него получилось — он уже прошел одно техсобеседование, а скоро его ждет второе в другой компании. Отвечать на вопросы, кстати, ему помогает искусственный интеллект. Считайте, он накрутил себе огромный стаж и полностью придумал все достижения на предыдущих местах работы. Здесь возникают вопросы: по каким критериям в принципе эйчары и команда отбирают специалистов? Получается, врать в резюме — просто необходимость? И можно ли оправдать тех, кто скручивает или накручивает опыт, чтобы попасть в компанию?

А этот опыт — он сейчас с вами в одной комнате?

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

Один из простых, но не самых честных вариантов для нашего Паши — банально накинуть себе еще 1-2 года опыта. Это реальный способ пробиться через жесткие фильтры HR и ATS-систем, которые часто отсекают кандидатов с недостаточным стажем. Главное здесь — не переусердствовать, иначе этого разговора из небезызвестного фильма не избежать:

Лично я никогда не крутил опыт, но зачем другие люди это делают? Опыт крутят, чтобы было больше шансов попасть на собеседование. Задача HR’ов и нанимающих менеджеров максимально сузить круг подходящих кандидатов. Главная задача — найти самого скилового кандидата. Хороший опыт дает человеку возможность опробовать себя в разных условиях, пообщаться с разными людьми и получить больше практики на разных задачах, а, соответственно, и больше хард- и софт-скиллов.

Кейс 2: Дмитрий Александрович, Java-разработчик с 20-летним стажем хочет перейти в новую компанию по личным причинам, допустим, ему наскучили задачи. Однако такой количество такого большого опыта совершенно не значит, что компании будут стучаться к нему в профиль каждые 3 минуты, поскольку это тоже может быть ред-флагом для эйчаров.

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

Какие в этой системе проблемы

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

Потеря доверия

Представим, Антон, 24-летний выпускник курсов по Python и стажер в небольшом стартапе, решил, что ему пора уходить в бигтех. После нескольких месяцев безуспешных откликов он решил усилить свое резюме и добавил два года вымышленного опыта работы над проектами в другом стартапе. Его план сработал: резюме прошло фильтр HR, и Антон получил приглашение на собеседование в компанию мечты. Он тщательно подготовился, выучил ответы на типичные вопросы и даже прошел техническое интервью (с трудом).

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

Несоответствие ожиданиям

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

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

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

Репутационные риски

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

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

Вместо заключения: как сделать реальный опыт

Накрутка и скрутка — не единственные способы вырасти в айти. Вот несколько альтернативных вариантов:

1. Фриланс и open-source. Новички могут брать небольшие проекты на фриланс-платформах или участвовать в open-source проектах, чтобы набраться реального опыта.
2. Стажировки. Многие компании предлагают стажировки для джуниоров, которые помогают получить первый опыт без необходимости «накручивать» стаж.
3. Портфолио. Хорошо оформленное портфолио с реальными или пет-проектами точно усилят ваше резюме, если будут выбирать из нескольких человек с одинаковым опытом.
4. Честная самопрезентация. Если вы опытный специалист, фокусируйтесь на реальных навыках и четко объясняйте, почему предыдущий опыт не будет препятствием.
5. Нетворкинг. Посещайте ярмарки вакансий, конференции и хакатоны — там вас могут заметить и позвать в команду.

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

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

Больше новостей — в нашем тг-канале «Представляешь»

Он просто хотел заменить phpMyAdmin чем-то более безопасным и понятным для клиентов. Сегодня у его проекта — более 30 000 звезд, клиенты из списка Fortune 500 и команда из 50 человек.

10 лет в одиночку

Первые 10 лет инструмент был сугубо личным. Без сообщества, без поддержки, без амбиций. Только PHP, MySQL и Бен. Когда-то он просто поставил на стол счетчик звезд с GitHub — и каждая новая звезда ощущалась как маленькая победа.

10 000 звезд: первая волна

Где-то в 2015 году о проекте начали говорить — в Reddit, Slack, GitHub Explore. К проекту присоединился Рейк ван Зантен, будущий со-основатель.

Вместе они вычистили кучу спагетти-кода, переписали все с PHP на Node и Backbone на Vue. Тогда же их позвали в Сан-Франциско — крупная компания хотела внедрить проект, но испугалась, что за ним стоит всего два человека без юрлица.

20 000 звезд: время становиться бизнесом

Хейнс закрыл имевшееся у него агентство и оформил компанию. Поднял $1 млн, собрал команду, запустил облачный сервис.

Затем, после сотни встреч с инвесторами и обвала венчурного рынка, нашел партнера, который понял ценность OSS. Удалось закрыть $8 млн — и с этого момента встал вопрос устойчивости: как зарабатывать, не предавая open-source?

Ответ — собственная лицензия с бесплатным использованием для всех, кроме корпораций. Работали даже с Брюсом Перенсом, сооснователем OSI.

30 000 звезд: устойчивость

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

И да, недавно они тихо подняли еще $9 млн — на новый архитектурный рефакторинг.

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

Немного базы

В этих статьях рассказываем о том, что нужно знать новичкам и не только.

• ReactJS на изи: что реально нужно знать фронтенд-разработчику в 2025 году — помогаем новичкам войти войти и показываем опытным разработчикам, что они могли упустить.
• Какие есть паттерны в React и для чего они нужны: часть 1 и Какие есть паттерны в React и для чего они нужны: часть 2 — здесь объясняем популярные архитектурные паттерны в React, когда и зачем их применять.
• 7 библиотек для анимаций на React / Tproger — собрали актуальные библиотеки для анимации в React; сравнение, демо и рекомендации.
• Типичные ошибки джунов, использующих React — показываем типичные ошибки junior-разработчиков в React, рассказываем, как писать чище и стабильнее.
• Подготовка окружения React-приложения: VSCode, Prettier, ESLint, Stylelint, Husky — рассказываем, как начать работу с приложениями на Реакте и что должно быть на рабочем столе.
• React Native против Flutter: что лучше (для общего развития) — сравниваем популярные фреймворки для кроссплатформенной разработки; плюсы, минусы и рекомендации.
• Deeplink в React Native: Полное руководств для новичков — рассказываем, что такое deeplink и как их писать на Реакте.

Практикуемся

• Современный Drag and Drop в React с помощью dndkit: создаем перетаскиваемое меню — здесь о том, как сделать меню, кнопки и все с помощью dndkit.
• Пишем приложение с бэкендом на Django и фронтендом на React — рассказываем, как создать REST API на Джанго, добавить React и объединить это в один проект.
• Создание ToDo-листа бесконечной вложенности на React, TypeScript и MobX — пошагово создаем вложенные задачи в ToDo-приложении, используем MobX, React и TypeScript.
• Создание Typing Test приложения на React + TypeScript + Redux Toolkit — учимся создавать приложение для проверки скорости набора текста, используем Redux Toolkit.
• Найди ошибку в React-компоненте: Функциональное Карри — практический кейс: ищем ошибку в React и заодно изучаем каррирование функций.
• Создание приложений для Windows на React Native — разбираем, как запускать и разрабатывать React Native-приложения под Windows, примеры и инструменты.
• Оптимизация графиков Recharts — ускоряем отрисовку графиков на React с помощью Recharts, практика, кейсы и улучшения.
• Как разработать своё первое приложение на React Native — инструкция по созданию первого мобильного приложения на React Native, от идеи до запуска.
• Пет-проект на React. Как мы «озвучивали» интернет — история реализации проекта с Web Speech API и React. Учим браузер говорить.

Кстати, похожий гайд мы уже делали — про Python. Можно заценить здесь.

В рейтинге языков программирования TIOBE Rust занимает 14 место. Для сравнения — в прошлом марте он был на 17 позиции. Вместе с экспертами Solvery Василием Кузенковым, full-stack разработчиком в Web3 стартапе, и Дмитрием Беляевым, Rust developer в Wildberries, разбираемся, как стать разрабом на Расте в 2025 году.

Немного об особенностях

Если вы до этого программировали на ООП языках, то вам, возможно, бросалось в глаза отсутствие привычных классов. Вместо них здесь алгебраические типы данных и трейты для решения expression problem. Их механизм куда больше похож на typeclasses из Haskell, что также будет для вас новой концепцией при построении крупных приложений, и нужно будет перестраивать мышление.

Также когда стартуешь, немного непривычно работать с move-семантикой, RAII, borrow checker’ом и лайф-таймами. Но компилятор сыпет довольно подробными ошибками, которые можно легко поправить, если разобраться.

А еще у Rust очень строгая типизация и очень мощная система типов, а сами типы построены так, чтобы предоставлять некоторые гарантии программисту. Например, ссылки в Rust всегда ссылаются на объект, гарантировано существующий в памяти, а стандартные строки содержат только валидный UTF-8. При этом в подавляющем большинстве случаев тип необязательно указывать явно, компилятор способен выводить типы, анализируя контекст функции целиком. Кроме того, Rust следует идеологии «компилируется, значит, работает». От логических ошибок, конечно, Раст не спасёт, но тем не менее очень большой пласт багов можно отловить на этапе кодинга. Да, это сложно, но лучше помучиться при разработке, чем потом разбираться почему упал прод.

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

Хороший пример здесь — итерация по различным коллекциям. Многие языки позволяют использовать итераторы с их абстракциями вроде map или filter. Только такой код, как правило, будет в несколько раз медленнее, чем если то же самое переписать на циклы. Компилятор Rust способен развернуть такой итератор в обычные циклы сам, и производительность будет сравнима, а порой даже лучше, так как программисты часто при написании низкоуровневого кода заставляют процессор делать много лишних вычислений.

Сложно ли переходить на Rust

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

На рынке фактически все вакансии требуют уже какого-то опыта в разработке. И сложность перехода сильно разнится от вашего текущего стека. Для Go-программиста переход будет средне-сложным, а язык, возможно, покажется перегруженным. Для С++ — менее сложным, но язык покажется местами ограничивающим. Я переходил на него с JS/TS’а и столкнулся со множеством низкоуровневых концепций, о которых раньше мог не задумываться. Но если у вас есть опыт в системном программировании — переходить будет в разы проще.

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

В моей практике менторства много успешных кейсов перехода на Rust с самых разных языков, но проще всего он даётся тем, кто раньше писал на современном C++ и уже понимает такие концепции, как move-семантика и RAII. Много привычного здесь обнаружат и те, кто писал на функциональных языках (Haskell или OCaml). Но в целом, для остальных тоже нет никаких проблем, даже если вы совсем новичок.

С чего начать изучать Rust

Вместе со стартом в изучении языка с The Rust Book — бесплатной официальной книгой по Rust’у — стоит углубить свои знания в более низкоуровневых вещах: в чем разница стека и кучи, что такое разметка памяти и адресация в памяти, как работает процессор, подходы и проблемы многопоточного программирования, плюс почитать про операционные системы и сети. Если вы решили осознанно применять Rust, оно вам пригодится.

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

Вот примерный список того, что нужно учить на старте:

• Переменные. Они по умолчанию неизменяемые (let x). Чтобы x стал изменяемым, нужно указать это явно через let mut. Константы (const) и статические переменные (static) вам будут нужны редко, они имеют свои особенности.
• Типы. Стоит разобраться с составными типами, такими как массивы и кортежи, а также с пользовательскими объявляемыми конструкциями struct (тип-произведение) и enum (тип-сумма). Также типы данных в Расте есть стандартные: bool, i32, u64 и прочие числовые, но строки могут удивить, так как их видов сильно больше.
• Match. Нужно понять такую вещь, как pattern-matching, познакомиться с оператором match, а также осознать, что pattern-matching применяется не только в нём, а везде, где возможно объявление переменных.

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

Здесь мы сразу проверили и присвоили:

Тут нам потребовалась дополнительная изменяемая переменная.

Что такое Cargo

Cargo — это консольная утилита, которая устанавливается вместе с компилятором языка. Она служит одновременно для управления зависимостями, сборки проекта и запуска тестов. Плюс для Cargo есть расширения, например, в поставке по умолчанию уже есть форматтер и линтер clippy.

Cargo рассчитан на то, что вы будете запускать его через терминал, самые полезные команды это:

• cargo new — создаёт новый шаблонный проект в указанной папке;
• cargo build — собирает проект;
• cargo run — собирает проект и запускает получившийся исполняемый файл;
• cargo check — dry-run сборки, делает все проверки компилятора, но ничего не собирает, что заметно быстрее полноценной сборки;
• cargo test — собирает проект со всеми тестами и запускает их;
• cargo fmt — форматирует проект в общепринятый стиль кода;
• cargo clippy — запускает линтер, очень полезно, можно подсказать более оптимальные варианты кода, найти некоторые потенциальные логические ошибки;
• cargo install — устанавливает пакет, содержащий исполняемые файлы;
• cargo clean — очищает все артефакты сборки.

Cargo позволяет описать структуру, настройки (профили сборки, описание крейта) и зависимости вашего крейта или даже монорепозитория (с помощью workspace). Кроме непосредственного запуска через терминал, многие вещи могут запускаться через средства интеграции в IDE, такие как rust-analyzer для VSCode.

Как работать с ownership, borrowing и lifetimes?

Для многих новичков системы владения (ownership), заимствования (borrowing) и времен жизни (lifetimes) выливаются в борьбу с компилятором раста. Эти механизмы нужны в первую очередь для безопасности памяти без сборщика мусора. Общее правило владения такое:

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

Когда значение перемещается (передается другой переменной или функции), владение переходит, и исходная переменная становится недействительной.

Для типов, реализующих трейт Copy (например, целые числа, булевы значения), значения копируются автоматически:

Для более сложных типов нужно использовать метод clone(), чтобы создать глубокую копию. В местах программы, где производительность не так важна — использование clone() не возбраняется.

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

Заимствование позволяет использовать значение без получения владения через ссылки (& и &mut). Для мутабельных ссылок `&mut` есть дополнительные ограничения: в каждый момент времени может существовать только одна изменяемая ссылка на значение.

Нельзя иметь изменяемую ссылку, если уже есть неизменяемая ссылка на то же значение.

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

Аннотация 'a указывает, что возвращаемая ссылка будет жить как минимум столько же, сколько кратчайшая из входных ссылок.

Общие советы по заимствованию здесь такие:

• Используйте ссылки, когда не нужно владение.
• Возвращайте значения из функций для передачи владения обратно.
• Используйте клонирование для создания новых экземпляров (с пониманием стоимости).
• Используйте типы с трейтом Copy, когда это возможно.
• Еще полезно не забывать о контейнерах. Rc<T> позволяет иметь несколько владельцев одного значения через счетчик ссылок, а RefCell<T> обеспечивает проверку правил заимствования в рантайме.

О структурах, перечислениях, модулях и функциях, замыканиях, итераторах

Структуры (structs) в Rust позволяют создавать пользовательские типы данных, объединяющие связанные значения и выступающие типом произведения.

Перечисления (enum) позволяют определить тип, перечисляя все возможные варианты значений.

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

Тип Shape представляет объединение (сумму) всех возможных вариантов. И к этому есть мощное сопоставление с образцом для работы с ADT:

Модули позволяют организовать код и контролировать видимость элементов. Определяются они через синтаксис mod <name> {} и могут быть вложенны друг в друга:

Также модули могут быть организованы в различных файлах (имя файла в таком случае будет именем модуля):

Импорт модуля осуществляется через ключевое слово use:

Функции в Rust определяются через ключевое слово fn:

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

Еще одним элементом функционального программирования в Rust выступает итератор:

Здесь мы создаем собственный итератор Counter, реализуя стандартный трейт Iterator. Он используется для многих встроенных коллекций, таких как Vec или HashMap. Этот трейт особенно удобен из-за различных функциональных комбинаторов из стандартной библиотеки:

Трейт Iterator предоставляет множество методов адаптеров, таких как enumerate, filter или map, которые возвращают новый итератор. Методы адаптеров ленивые, они не запускают итерацию. Также есть методы исполнители, которые итерируют пока не закончатся значения, например, collect, fold или count.

Большинство коллекций (и ссылки на них) реализуют трейт IntoIterator (способность кастоваться в Iterator). Также IntoIterator автоматически реализуется для любого Iterator (ничего не стоящий каст сам в себя). Цикл for в Rust работает только с объектами, реализующими IntoIterator.

Как обрабатывать ошибки в Rust

В Rust принято разделять ошибки на 2 вида: паники и результаты операций:

• Паники используются для непредвиденных ситуаций и ошибок программиста, например, деление целочисленного типа на 0 или выход за границу массива. И хотя паники можно отловить, стандартное и рекомендуемое поведение при них — программа упадёт, будет напечатан стектрейс.
• Результаты операций выражаются типом Result<T, E>, который является перечислением из двух вариантов — Ok(T) и Err(E). Такой подход гарантирует, что все ошибки строго типизированы, а без обработки ошибки невозможно извлечь результат операции.

Option<T> используется для представления значения, которое может отсутствовать:

Result<T, E> используется для операций, которые могут завершиться ошибкой:

Для удобства проброса ошибок наверх существует оператор ?, который пишется после любого выражения, возвращающего Result, и возвращает Ok вариант. В случае Err варианта будет выход из функции с возвращением ошибки.

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

Про асинхронное программирование

Асинхронное программирование в Rust строится вокруг трейта Future— его реализуют для типов, представляющих значение, которое будет доступно в будущем.

Также в Rust есть синтаксис async/await. Ключевым словом async могут быть отмечены функции и блоки кода — они будут возвращать анонимный тип, реализующий Future. Async-блоки также могут захватывать окружение подобно замыканиям. Внутри async-блоков и функций возможно использовать ключевое слово await на любом выражении, возвращающем Future или IntoFuture (способность кастоваться к Future). В отличие от других языков с подобным синтаксисом, await записывается через точку после выражения, что очень удобно для построения цепочек вычислений.

Для исполнения асинхронного кода необходим рантайм, но стандартная библиотека такого рантайма не предоставляет, поэтому приходится использовать сторонние библиотеки. Самым популярным рантаймом является библиотека tokio.

В асинхронное программирование на Rust я рекомендую приходить уже после углубленного изучения языка, первых пет-проектов и небольшой работы с многопоточным кодом. Хотя синтаксис и общие правила работы с асинхронным кодом покажутся знакомыми тем, кто знает JS или C#, из-за более низкоуровневой природы языка работать с ним немного сложнее.

Что еще должен знать новичок в Rust

Вот примерный список:

• Очень желательно погрузиться в устройство памяти процесса, узнать, что помимо стека и кучи существуют и другие области (например, исполняемый машинный код так же отражён на память, а static-переменные хранятся не в стеке и не в куче, а в своей собственной области). Неплохо было бы и разобраться с тем, что у типов помимо размера есть выравнивание. Что в Rust бывают ZST (zero size type) — типы, размер которых честный 0, и DST (dynamic size type) — типы, размер которых неизвестен во время компиляции.
• Обязательно разобраться, как Rust освобождает память, не используя сборщик мусора. Почитать, что такое RAII. Понять, как работает трейт Drop.
• Избавится от стереотипов о Rust. Rust — не самый сложный язык, как только вы поймёте, как он работает. Плюс платят за Rust, как правило, больше, чем на аналогичных позициях на других языках.
• Оставить свои привычки из других языков (за исключением разве что Haskell/OCaml). Здесь не получится писать, как на C++/Java/Go и т.д. Привыкайте к хорошему и станете лучше, чем были до освоения Rust.

Что изучать, если есть вся база: чек-лист

• Макросы и метапрограммирование
• Unsafe Rust для низкоуровневого контроля
• Интеграция с C/C++ через FFI
• Разработка встраиваемых систем
• WebAssembly
• rustnomicon
• Undefined Behavior
• unsafe-код

Тренды на 2025 год

На Rust’е пишут все. Более полный список можно посмотреть тут: https://github.com/rust-unofficial/awesome-rust

Вот несколько топовых фреймворков и библиотек:

• serde — фреймворк для сериализации/десериализации
• tokio, futures — для асинхронного программирования
• clap — парсер аргументов командной строки
• anyhow, thiserror — удобная работа с ошибками
• chrono — работа с датой и временем
• dashmap — многопоточная hashmap
• bytes — эффективная работа с сырыми байтами
• log, tracing — для логирования
• reqwest — для http запросов
• axum — для http сервера и REST api
• mockall, test-case — упростит написание тестов
• bevy — игры
• clippy — линтер

Впервые идея создать приложение для подбора меню появилась в начале 2024 года. На тот момент в моей жизни было две главные проблемы:

• Я работала в Учи.ру, где мы писали браузерную игру на чистом JS, поэтому я очень скучала по реакту.
• Мне надоело придумывать, что готовить. Из-за этого мы с мужем перешли на готовые рационы. Но, во-первых, питаться только доставками дорого. А во-вторых, всё равно приходилось мыть посуду, потому что мы сознательные разработчики, которые сортируют мусор и сдают пластик в переработку.

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

Подготовка

Первое, что я сделала — набросала схему в FigJam. Здесь отметила, какие функции обязательно должны быть в MVP, а какие войдут в следующие версии проекта (v1.5, v2 и даже v3).

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

Чтобы ничего не забыть, все задачи отмечала в Notion, а когда он закрылся, перешла в AnyType. Кому-то он нравится больше, но лично мне не хватило возможности переносить таски из одного столбика в другой (или я просто не поняла, как это делать). Поэтому в скором времени планирую переезд в Obsidian.

Кое-что по технарю

Для разработки я выбрала эти инструменты:

• Библиотека: ReactJS. Думаю, пояснения будут излишни.
• Стор: Redux Toolkit. Много раз видела его в вакансиях, но ни разу с ним не работала, поэтому было интересно пощупать на практике.
• Базы данных: Supabase — аналог Firebase. Тоже взяла впервые.
• Сборка: Vite, потому что он быстрый и классный.
• Деплой: Vercel. В отличие от GitHub Pages может делать всё за одно нажатие кнопки.

Ещё хотела использовать UI-библиотеку, но так как приложение небольшое, то решила не тащить лишние килобайты и сверстать всё сама.

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

Как работают алгоритмы

Основа приложения — это три главных экрана:

• рецепты,
• холодильник,
• список покупок.

Работает это просто: я заполняю раздел «Холодильник» и отмечаю, какие продукты уже есть дома, а приложение подбирает подходящие рецепты из базы данных.

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

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

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

Немного проблем

В процессе работы было несколько трудностей:

• Нехватка времени. Я начала делать приложение на новогодних каникулах, а потом они кончились, и свободного времени не осталось.
• Лень. Если честно, заполнять базу данных рецептами довольно муторно, поэтому со временем мы снова перешли на доставку готовых рационов.
• Странности с Supabase. На бесплатном тарифе база данных замораживается, если не пользоваться ей неделю. Потом можно опять активировать, но я думаю перейти на Nitra, чтобы ни от кого не зависеть.
• Уход от плана. В какой-то момент я настолько вошла во вкус, что забыла про свои схемы и черновики. В итоге актуальная версия приложения очень отличается от той, что была запланирована.

Планы на будущее

Сейчас приложение на этапе MVP, но есть много идей, куда и как его можно развивать. Вот что точно хочу сделать в будущем:

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

Ещё думаю над тем, чтобы вывести приложение в паблик и дать возможность всем желающим подключить свою базу данных. С open-source всё сложнее — пока не настолько доверяю людям, чтобы дать им возможность решать, что будет у меня на завтрак 🙂

Зачем делать пет-проект

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

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

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

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

Самые перспективные направления: ИИ-инструменты для персонализации (здоровье, созвоны, управление проектами), AR/VR-приложения и децентрализованные DApps.

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

Для начинающих: скрипт организации файлов, веб-заметки на Python/Reflex или биржа с ML-прогнозом цен на акциях (Flask + scikit-learn + pandas).

Скорость разработки критична для мотивации: чат-боты для Telegram/VK дают быстрый старт и результат, который можно сразу показать.

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

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

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

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

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

Изначально считая себя не достаточно компетентными мы начинали исследование совместно с РАН, так как себя мы считали не достаточно компетентными. Конкретно Мы исследовали парадоксальный сон, но для того, что бы до него добраться нам пришлось изучить всё фазы и аномалии сновидений которые есть и могли бы возникнуть гипотетически. В частности расстройства сна и такое распространённое явление как бессонница. Об этом в СМИ вышел ряд публикаций, публикаций о нашем исследовании, ссылки на некоторые из них ниже:

1. Сон в зимнюю ночь, или Как победить инсомнию
2. Аргументы и Факты - Бессонница не приговор. Что делать, если не получается заснуть?
   
3. СеверПост Мурманск — Эксперт рассказал, что поможет уснуть в полярный день — Эксперт рассказал, что поможет уснуть в полярный день.
   

Исследование начиналось совместно с Российской Академией Наук (РАН), конкретно с Институтом Высшей Нервной Деятельности и Нейрофизиологии РАН г. Москва.

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

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

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

От пет-проекта к научному моделированию

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

В самом начале мы использовали три основные технологии, “Banchenko's Mnemonic Dream Synchronization Method”, “Blokhin's Dreaming Cell Concept” и “Kapustin's AI Dream Matching Model”.

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

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

Гипотезы и результаты

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

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

Искусственный интеллект и анализ снов

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

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

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

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

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

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

AR/VR

Я сам хочу начать проект на основе технологий дополненной реальности. Есть идея приложения, которое превращает разбросанные по дому вещи в огромных мерзких пауков — и так приучает детей поддерживать порядок. Подробнее об AR-разработке читайте в нашем гайде для новичков.

Ещё мне нравится идея приложений IKEA и HOFF, которые позволяют «примерить» мебель к дому. Почему не сделать аналогичное решение, позволяющее прикинуть проект ландшафтного дизайна к загородному участку или к двору городского многоквартирного дома?

Перевод стека

Было бы интересно использовать ИИ для перевода приложений с одного стека на другой. Реальный пример: в компании есть набор сервисов на Java, но последний Java-специалист покинул корабль полгода назад. Можно разбираться с поддержкой непрофильного кода. А можно подключить ИИ и перевести Java-код на .NET или Go.

Управление рисками на проекте

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

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

IoT

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

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

И да, работая над пет-проектами, стoит ориентироваться на технологии Яндекса, потому что облако Amazon в России на грани вымирания из-за санкций, а аренда виртуалок заметно проигрывает в цене и удобству SaaS-решениям.

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

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

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

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

В начале стоит сказать, что идей для проектов — бесконечное множество. Если вы беретесь за реализацию одной из них, важно, чтобы это не стало «работой в стол», так что я не буду советовать написать свой калькулятор (хотя это и может прокачать ваши навыки и научить работать с польской нотацией). Главное — чтобы пет проект был актуальным и приносил пользу. Если приложением, которое вы написали, не будете пользоваться даже вы сами, то смысла от него не очень много и мотивации его писать тоже будет маловато.

Опишу варианты актуальных пет проектов по мере возрастания сложности.

Скрипты

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

1. Работать в фоновом режиме;
2. Открываться при запуске системы;
   
3. Наводить порядок на рабочем столе или в папке загрузок.
   

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

Веб

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

Искусственный интеллект

Звучит сложно, но на самом деле это не так! Искусственный интеллект все еще на волне хайпа, так что будет полезно его освоить. Например, вы можете написать свою собственную биржу с прогнозом цен на акции. Сервер, линейная регрессия для машинного обучения и шаблон веб-страницы — звучит достаточно сложно, но на практике вполне реализуемо даже для новичка. Достаточно всего трех библиотек (Flask, scikit-learn, pandas), а результат точно заставит вас гордиться собой! Сервер позволит вам хранить данные и отображать прогноз (подробнее о ML с Python), в интерфейс достаточно выводить текущую цену и прогноз, а для обучения модели используйте реальные данные по акциям вашей любимой компании.

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

Один из таких — Smartpig, проект направленный на автоматизацию свиноводческих комплексов и комплексов КРС и ориентированный на импортозамещение продукта Cloud farm, который благополучно ушел с нашего рынка. Особенностью проекта считаем использование различных предиктивных моделей. Мы взяли лучшее, что было у Cloud farm, и добавили инструменты, необходимые для нашего рынка, в том числе интеграцию с ветеринарной системой «Хорриот», другими отечественными ERP-системами, использовали платформу российского вендора 1С.

В настоящее время идет процесс включения данного проекта в перечень отечественного ПО, то есть двигаемся к тому, чтобы продвинуть этот проект на российский рынок.

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

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

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

1. Система анализа документов. Документооборот достаточно обширная область. Интересной идеей может быть реализоваться проект который помогает анализировать контент различных документов, группировать их, строить связи, производить поиск по большому количеству документов.
2. Система управления проектами. Данная сфера очень разнообразная. Проект может включать в себя как простой набор задач для выполнения, так и сложную систему планирования с наличием сроков, ресурсов, управление состояниями задач, и мониторинг прогресса. Размер и сложность проекта может варьироваться от фантазии и наличии свободного времени.
   
3. Трекер полезных привычек. Сейчас очень популярная тема саморазвития и формирования лучшей версии себя. Приложение по мониторингу приобретения той или иной привычки с ежедневным прогрессом и постановкой целей может стать полезным проектом.
   
4. Агрегатор сообщений. Сейчас мы пользуемся большим количеством мессенджеров. Проект по интеграции большого количества учетных записей в различных мессенджерах в единое приложение может помочь в большом потоке информации и упростить коммуникацию между разными платформами.
   

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

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

Если переходить к конкретике, то можно разработать чат-бота для Telegram или VK. Они дают быстрый старт и возможность быстро показать знакомым, что вы сделали. Скорость разработки для пет проектов очень важна, так как сильно влияет на мотивацию. Маленькие победы приведут вас к большому результату.

Например, сделайте бота, который будет советовать вам разный контент (книги, фильмы, игры) на основе ваших интересов. А если вы фронтенд разработчик, то можете добавить к нему UI, а потом захостить самостоятельно или на платформах для веб-приложений, таких как VK Mini Apps и Telegram Mini Apps.

Также пользуются популярностью различные гиперказуальные игры: Wordly, вариации 2048, квизы и тому подобное. Поэтому если у вас есть идеи и желание развиваться в этом направлении, то обязательно попробуйте. Сейчас есть много площадок, которые помогут вам разместить вашу игру, привлечь аудиторию и даже немного заработать. К примеру, уже упомянутые VK и Telegram Mini Apps.

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

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Внимательно выбирайте сферу

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

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

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

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

Прорабатывайте USP

USP — это уникальное торговое предложение. То, что «выделяет» продукт.

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

• Miro, как самое популярное решение, оброс чрезмерным функционалом. Он уже давно ориентируется на Enterprise-сегмент, а не специализируется на определенной нише;
• FigJam — относительно новый продукт от Figma и больше ориентирован на продуктовые команды: разработку креативов, коллективный брейншторм.

Отталкиваясь от собранных данных, мы конкретизировали видение доски:

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

Постройте план и поделите обязанности

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

На этапе планирования и составления плана работы рекомендую особенно уделить внимание нескольким деталям:

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

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

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

• Александр: фронтенд, WEB-редактор, протокол мультиплеера, UX/UI, Identity Service;
• Иван: бэкенд, инфраструктура, надёжность, данные;
• вместе: продвижение и нетворкинг.

А все трудности, с которыми сталкивались по ходу работы, обсуждали между собой. Сейчас, в МТС Линк мы работаем по методологии Agile: разбиваем работу на двухнедельные спринты. Если над одним проектом трудятся 6-10 человек — то такая методология замечательно работает. В противном случае, когда команда меньше, вы больше времени потратите на планирование задач, чем на сам продукт.

Работайте над узнаваемостью

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

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

Работайте с критикой

Пользователи чаще всего позитивно реагировали на статьи. Как правило, просили что-то улучшить или добавить, обогащая бэклог.

Была, конечно, и откровенная критика: вы делаете то же самое, что Miro. Вы выглядите так же, как FigJam.

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

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

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

Пишите большим компаниям

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

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

Поддерживайте связь с заинтересованными людьми

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

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

Выкладывайтесь на все 100%

Когда что-то делаете — делайте это в первую очередь качественно. Ориентируйтесь на уровень успешных проектов.

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