Размышления фулстек-инженера, который начинал с небольших сайтов, а закончил системами для банков, государства и маркетплейсов.
Размышления фулстек-инженера, который начинал с небольших сайтов, а закончил системами для банков, государства и маркетплейсов.
В декабре 2016 я запустил доску объявлений. В марте 2017 написал на Спарке статью о том, как пытаюсь притащить на неё трафик. Статья была честная до неприличия: три месяца работы, около 14 тысяч рублей на рекламу, 450 рублей выручки.
Отдельным памятником стоит таргет во ВКонтакте. 515 тысяч показов, 41 переход, два поданных объявления. CTR ноль целых ноль ноль восемь. Восемь тысячных процента. Я тогда пересчитал трижды, потому что решил, что где‑то потерял запятую.
Под статьёй набежали люди и сказали примерно одно и то же: не тягайся с Авито, иди в нишу.
Я поблагодарил за фидбек и пошёл тягаться с Авито дальше.
Мне понадобилось обрабатывать десятки тысяч рекламных объявлений с помощью LLM. На выходе нужен был строго валидный JSON с датами, тегами, временем, стоимостью и другой структурированной информацией. Главные требования были простыми:
высокая точность;
стабильный Structured Output;
минимальная стоимость обработки.
Перепробовав множество вариантов, я обнаружил, что полностью бесплатные модели вроде OpenRouter действительно позволяют решить задачу без вложений, но на практике я столкнулся с двумя проблемами:
Это сложно, необходимо установить много утилит, команд для запуска и обслуживания такого проекта, и вообще, я не думаю, что держать всё в одном проекте — жизнеспособная вещь.
Именно так я думал, когда начинал разбираться в этой теме. Но разобравшись, я с уверенностью могу сказать, что это реально, такая идея имеет место быть, и обслуживать такую архитектуру легко.
В данной статье будет описан процесс реализации архитектуры веб‑приложения с удобной системой докер-контейнеров. Здесь не будет обсуждаться CI/CD, исключительно development‑side процесса разработки.
Всем привет!
В этой статье я хочу рассказать о том, как учеба в (моём случае техническом) ВУЗе может повлиять на амбиции и подход к своему хобби, при этом не всегда имея прямую связь. В пример буду ставить свой проект: приложение для моделирования физических процессов.
Я считаю, верным подходом будет сначала заглянуть в прошлое и рассказать о том, как до этого я подходил к программированию.
Привет! Когда я был мелкий, и трава зеленее, провайдеры всегда выдавали не белый, а «серый» адрес. Да, он менялся при каждом подключении, но всегда можно было открыть порт и поиграть с корешами в ту же CS 1.6 или Minecraft. Время прошло, и сейчас, чтобы получить белый IP, нужно пройти три круга ада. И то не факт, что дадут. Или: «Купите наш тариф за миллион денег, тогда дадим». Но не про то пошёл разговор.
Предыстория: от идеи к прототипу
В последние десятилетия ИТ-индустрия живет в парадигме «победившего Agile». Любое сомнение в его эффективности клеймится как приверженность «устаревшему водопаду». Однако при более глубоком анализе выясняется, что Agile — это не эволюция управления, а искусная маркетинговая надстройка, которая борется с вымышленными врагами и подменяет системное проектирование ритуальным ремесленничеством.
1. Битва с тенью: миф о «Водопаде»
Однажды я открыл биллинг и просто посмотрел, на что уходят токены. Не на «подумать над архитектурой». А на переименование переменных, генерацию тестов по готовому ТЗ и прогон миграций. Всё это считалось по тарифу флагманской модели, хотя такую работу вытянет модель в десятки раз дешевле.
Ниже – как развести действительно сложные задачи и рутину по двум моделям внутри Claude Code, не ставя ни одного стороннего форка. И три зоны, куда дешёвую модель я не пускаю принципиально.