Fullstack Founder

Рубрика: Разработка

  • Разработка наоборот в Amazon

    Разработка наоборот в Amazon

    Гигант интернет-торговли Amazon внедрил у себя практику разработки “наоборот” — вместо PRD и спецификации они начинают с написания пресс-релиза и FAQ. Пресс-релиз пишут так, как будто новая фича уже вышла.

    Какие есть преимущества у этого подхода?
    – Ранняя валидация того, насколько новая фича на самом деле нужна. Менеджменту легко принять решение или опросить фокус-группы.
    – Всем участникам понятно, что именно они делают и как это должно восприниматься.
    – В самом начале понятно, какие могут возникнуть технологические вызовы.
    – Опыт и ценности для конечного пользователя становятся очевидны всем участникам процесса.

    В пресс-релиз включены:
    – Интро.
    – Проблемы пользователей, которые решает новая разработка (Jobs-to-be-Done).
    – Предлагаемое решение этих проблем.
    – Цитаты ответственного за внедрение.
    – Цитаты вымышленных персонажей с впечатлениями от продукта.

    Пресс-релиз пишется одновременно с большим FAQ с ответами на возможные вопросы как пользователей (Customer FAQ), так и команды (Internal FAQ).

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

  • Как начать вайбкодить бесплатно и без SMS

    Как начать вайбкодить бесплатно и без SMS

    Зарегистрировать аккаунт в Claude или OpenAI — целое приключение. Телефонный номер из другой страны добудь, VPN с той же страной подключи, как оплатить картой этой страны найди. Квест для технически подкованных и сильных духом.

    Попробовать вайбкодинг можно гораздо проще, бесплатно и без SMS.
    – Ставишь VS Code.
    – В расширениях ищешь и устанавливаешь Cline — AI-агент для программирования.
    – Создаёшь аккаунт на OpenRouter, используя почту.
    – В профиле выпускаешь API-ключ и вставляешь его в Cline.
    – В настройках Cline выбираешь бесплатную модель.

    Доступны различные модные модели бесплатно:
    – OpenAI gpt-oss-20b
    – Google Gemini 2.5 Pro
    – DeepSeek V3 и R1
    – Qwen 3 Coder
    – Kimi K2
    – Mistral
    – Llama 3

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

    Cline сам по себе прекрасно сделан. Помимо OpenRouter, можно прописать ключи от любого AI API. Доступны MCP, работа с браузером, раздельные режимы планирования и выполнения, опциональное подтверждение опасных действий. Также Cline показывает все шаги, каждый запрос в API и количество затраченных токенов. Прямо видишь в ходе работы, как он думает и отсылает запросы.

  • Похоже, что GPT-5 и правда лучшая доступная на сегодня модель

    Похоже, что GPT-5 и правда лучшая доступная на сегодня модель

    Похоже, что GPT-5 и правда лучшая доступная на сегодня модель.

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

  • Превью для пересылаемых ссылок

    Превью для пересылаемых ссылок

    Пересылал в телеграме ссылку на свой блог fullstackfounder.ru и обратил внимание, что ссылка голая — в чате не отображается картинка и описание. Я хочу, чтобы ссылки были привлекательными, вдруг кто-то в чате поделится статьёй.

    За эти улучшения отвечает протокол Open Graph. Чтобы он заработал, нужно добавлять в HTML-код страницы дополнительные поля, которые пользователь не увидит на сайте. Зато их прочитает робот социальной сети, когда кто-то перешлёт ссылку.

    В WordPress из коробки Open Graph почему-то нет, поэтому ставлю плагин. Так сложилось, что в экосистеме WordPress за это отвечают сеошные плагины. Лидер — перегруженный старичок Yoast SEO. Но его я ставить не хочу — там слишком много невостребованных мной функций, он снижает производительность сайта и грубо вставляет куски своего интерфейса в админку.

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

    • Автоматическое добавление Open Graph нескольких видов
    • Поля с мета-тегами при редактировании страниц в админке
    • Шаблоны для автоматического формирования мета-тегов
    • Управление редиректами
    • Управление индексированием разделов
      Всё бесплатно, ненавязчиво, большинство настроек применились автоматически. Нет AI-помощников, слежения за позициями и трансляции ошибок из консоли поиска. Да мне и не надо, я улучшаю технические факторы.

    Поставил и включил плагин. Протестировал как работает Open Graph в удобном онлайн-тестировщике. Всё заработало, ссылки стали полноценными! Попробуйте переслать эту статью.

    Частая проблема — социальная сеть не обновляет ссылку, после того как мы поменяли картинку или текст. Нужно попросить соцсеть сбросить кэш.
    Бот для сброса кэша в Telegram
    Обнулятор от Callibri
    Сброс кэша для LinkedIn

  • Фуллстек парадокс

    Фуллстек парадокс

    В начале 2000-х в веб-разработке не было фронтэндов или бэкэндов.
    Была профессия вебмастер. Этот человек мог сделать сайт целиком. Он умел общаться с полиграфическим дизайнером про внешний вид сайта, верстать HTML таблицами, оптимизировать графику, писать java script. Стек был небольшой и было мало слоёв абстракции.
    Если было нужно что-то покруче, звали программиста и он писал CGI-скрипты на Perl, PHP или C.

    Прошло 25 лет. В этом году искал для клиента fullstack-разработчика. Вакансии такие на рынке есть. Например, одновременно с моей вакансией продвигали объявление от Теремка на такой же стек. На такую вакансию массово откликаются фронтэнд-разработчики. Почему так?

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

    Современный бэкенд разработчик часто знает HTML, CSS и Java Script. Может так случиться, что был у него опыт разработки на React, но он не будет считать это значительным достижением. Хорошо, если в резюме укажет. Его территория упирается с одной стороны в серверное администрирование и облака, с другой находится уровень железа: производительность процессора, работа с памятью, операции чтения и записи на жесткий диск. Пляж фронтэндов находится на периферии его владений и занимает небольшой участок с выходом в море.

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

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

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

  • Продажи в чатах для агентств

    Продажи в чатах для агентств

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

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

    Как это было устроено:
    – Завели роль Лидоруб — сотрудник, который первый сталкивается с лидами или ловит их в интернете. Его задача — быстро реагировать. Не нужно быть классным продажником, достаточно уметь общаться.
    – Завели тг-аккаунт, в котором постоянно сидел наш Лидоруб.
    – Аккаунт был подписан на несколько сотен чатов с предпринимателями, диджитал-специалистами, агентствами, обучающими курсами. Всё, что смогли найти.
    – Чаты отсортированы по папкам. Самые качественные вынесены в отдельные папки, чтобы быстрее реагировать.
    – Лидоруб половину рабочего дня просматривал чаты на предмет запросов на услуги.
    – Если видел сообщение с запросом “а подскажите хорошего директолога”, то публично отвечал “могу порекомендовать Никиту” и давал контакт нашего продажника.
    – Другой вариант — лидоруб сам откликался на запрос и проводил первичный диалог, выявлял потребность (что именно нужно) и квалифицировал клиента (а скиньте ссылку на ваш сайт).
    – Продажник ждал лиды, поэтому оперативно реагировал. Писал клиенту сам, подхватывал диалоги, назначал встречи.
    – Мы откликались на любые запросы, в том числе мелкие. Задача была наладить коммуникацию и завоевать доверие. Целевому клиенту можно было сделать самую маленькую задачу, а потом продавать комплекс услуг или долгий проект.

    Мой личный рекорд продажи из чатов в тот период — сделка на 1.3 млн рублей.

    Этой схемы хватало, чтобы создать в небольшом агентстве постоянный приток новых клиентов. Без каких-либо автоматических сервисов и спама. В чатах разнородные клиенты, разные ниши, очень разные чеки. Клиенты в чатах точно есть и они хотят покупать!

    Посты по теме:
    – Виды лидгена в агентство
    – Лидген на отраслевых выставках
    – Подборка материалов для агентств

  • Попробовал модный веб-сервер Caddy вместо Nginx

    Попробовал модный веб-сервер Caddy вместо Nginx

    Попробовал модный веб-сервер Caddy вместо Nginx.

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

    NGINX (Engine X) — самый популярный веб-сервер (33% рынка), написанный на C. Изначально был написан 20 лет назад программистом из Rambler.
    Раньше Nginx многие использовали как обратный прокси для Apache2, чтобы его ускорить. Nginx занимался статичными файлами (картинки, CSS), а Apache2 запускал PHP-скрипты. Постепенно Apache2 стали убирать и всю работу переносить на Nginx, потому что он быстрее и лучше держит большие нагрузки. Есть большая экосистема дополнений, отличная документация и множество примеров использования. Стабильный продукт, с которым я работаю на всех проектах.

    А тут в инфополе стал мелькать Caddy. Чем же он покоряет разработчиков?
    – Более лёгкая конфигурация SSL-сертификатов. Точнее, её нет, Caddy делает всё сам — пользователю больше не нужно настраивать стандартные сертификаты Let’s Encrypt.
    – Поддержка HTTP/2 и HTTP/3 из коробки.
    – Поддержка компрессии gzip и zstd из коробки.
    – Простой синтаксис конфигурационных файлов. Очень похож на Nginx, но проще и яснее. Конфиги сокращаются в размере, вероятность ошибки ниже.
    – Caddy — это всего один исполняемый файл без зависимостей. Его легко устанавливать и обновлять.
    – Новый плагин можно подключить к Caddy без перезагрузки и простоя в работе.
    – После установки Caddy показал симпатичную страницу по-умолчанию с небольшой инструкцией.

    Есть у него и минус:
    – Caddy на предельной нагрузке может обработать меньше запросов, чем Nginx. Приоритет Caddy на простоте использования и автоматизации. На этом бенчмарке разница начинается от 10 тысяч запросов в секунду, что практически недостижимо для маленьких проектов.

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

    На моём сайте пока что висит статическая заглушка, вот весь конфиг:

    fullstackfounder.ru {  
       root * /var/www/fullstackfounder.ru/public  
       file_server  
       encode zstd gzip  
}  
  
www.fullstackfounder.ru {  
       redir https://fullstackfounder.ru{uri} permanent  
}

    Аналогичный конфиг у Nginx выглядел бы вот так:

    server {
    listen 80;
    server_name fullstackfounder.ru www.fullstackfounder.ru;

    # Redirect all HTTP to HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name fullstackfounder.ru;

    ssl_certificate     /etc/letsencrypt/live/fullstackfounder.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/fullstackfounder.ru/privkey.pem;
    include             /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam         /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/fullstackfounder.ru/public;
    index index.html index.htm;

    # Enable gzip
    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    # Canonical redirect: www → non-www
    if ($host = 'www.fullstackfounder.ru') {
        return 301 https://fullstackfounder.ru$request_uri;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

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

    Буду запускать на нём WordPress, посмотрим, что из этого выйдет.

  • Time & Materials: снижение рисков

    Time & Materials: снижение рисков

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

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

    В проектах с неопределённостью нужно подписывать контракты по схеме Time&Materials:
    – Клиент оплачивает фактические трудозатраты (почасовка).
    – Клиент оплачивает потраченные материалы и инструменты.
    – Клиент оплачивает привлечённых субподрядчиков.

    Какие риски мы снимаем, переходя на T&M:
    – Убыточные проекты — себестоимость всегда оплачена клиентом.
    – Бесконечные правки за счёт агентства уходят в прошлое — клиент платит за свой перфекционизм.
    – Низкое качество работы при промахе в оценке — в фиксированной цене агентство будет стоять перед выбором: снизить качество или сделать в минус.
    – Конфликты с клиентом — стороны недовольны друг другом. Клиент не доплачивает, агентство не дорабатывает. Возникает это ближе к финалу работ, когда становится очевидно, что проект выходит за рамки бюджета.
    – Провал в мотивации — кому интересно делать убыточные проекты низкого качества и конфликтовать?

    В T&M агентство продаёт то, что закупило у сотрудников — часы работы. Агентству становится выгодно и комфортно делать крутые и сложные проекты.

  • Пройти Тест Джоэля

    Пройти Тест Джоэля

    В 2000 году Джоэль Сполски — сооснователь StackOverflow и Trello, написал список из 12 вопросов, известные как Тест Джоэля. Часто ссылаюсь на этот тест, поэтому прокомментирую эти вопросы.

    1. Используете систему контроля версий?
    Кажется, что git — уже обязательная вещь. Но до сих пор встречаются проекты без системы контроля версий.
    Для тех, кто уже использует, вопрос всё ещё актуален, но теперь звучит так: Вы действительно используете систему контроля версий? У вас есть стратегия ветвления, процедура слияния веток, понятные правила для работы с репозиторием?

    2. Сборка проекта происходит в один шаг?
    Проект должен собираться в 1 команду и она должна быть написана в readme. Если для запуска проекта требуется поставить несколько сервисов, иметь нужную версию компилятора и запущенную базу данных — стоит прописать все эти зависимости в docker-compose и запускать одной командой. После прихода виртуализации оправданий для многошаговой сборки и зависимости от среды больше нет.

    3. У вас настроен CI/CD?
    В оригинале Джоэль говорит про daily build — оперативная сборка софта каждый день. Сейчас в большинстве команд нет нужды синхронизировать код раз в день, можно делать это автоматически каждый раз, когда код попадает в репозиторий.
    Настройте автоматическую сборку и выкатку приложения на тестовый сервер.

    4. У вас же есть база багов? Правда?
    Громоздкая Джира не единственный вариант. Эксель тоже подойдёт! Если у вас есть общий зафиксированный список проблем, вы можете с ними работать и планировать их устранение.

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

    6. У вас есть план работ со сроками?
    План, который знают все и который связан с реальностью. Roadmap, этапы или просто дата, в которую надо запуститься.
    Работа ведёт себя как газ — занимает всё выделенное время. Ставьте сроки.

    7. У вас есть спецификация?
    Банально, но без ТЗ результат ХЗ. Сейчас не нужно писать исчерпывающее финальное тех задание — требования поменяются по ходу разработки. Достаточно написать концепцию, сделать прототипы, записать user story и опубликовать. Задачи тоже нужно записать и поставить в трекер.

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

    9. У разработчиков лучшая техника и инструменты?
    Быстрый комп, 2ой монитор, современный софт, быстрые серверы — стоят копейки относительно времени программиста. Планка памяти стоит как час работы разработчика. Ускоряйте их всеми доступными способами, это очень дёшево.

    10. У вас есть тестировщики?
    Если баги ищут только разработчики — значит, баги находят пользователи.
    Менеджеры и программисты проверяют, что код работает. Тестировщики проверяют, ищут где он не работает. У вас должен быть хотя бы 1 тестировщик в команде на нескольких разработчиков.

    11. Пишут ли кандидаты код на собеседовании?
    Это единственный пункт, с которым я сейчас не полностью согласен в его изначальной формулировке. Изучить код и мышление кандидата на собеседовании получится, а вот показать реальные навыки в стрессовой ситуации собеседования — вряд ли. Мой рецепт — выводить подходящих кандидатов на тестовую неделю и смотреть совместимость без давления в реальной обстановке.

    12. Вы делаете usability тесты на добровольцах?
    Соберите группу для тестирования. Первые 5 случайных пользователей укажут вам на 95% проблем. Находите этих пользователей и проводите тестирование до большого релиза. Это дёшево и просто. В оригинале предлагается поймать добровольца в коридоре компании, но сейчас эра удалёнки — найдите их онлайн.

    Если вы фаундер или руководитель и у вас есть ответы “Нет” — их точно стоит обсудить с командой.

  • Горшочек с мёдом

    Горшочек с мёдом

    Honeypot — в переводе с английского “горшочек с мёдом”. Красивое и безобидное название, которое в веб-разработке обозначает хитрую ловушку. Ловим роботов! Ловим в естественной среде обитания — на нашем сайте, на самую обычную форму регистрации, комментария или обратной связи.
    Обычный пользователь видит свою обычную форму:
    Имя: ____________
    Email: ___________
    Ваш комментарий: ____________________

    Робот не смотрит глазами на монитор — он читает исходный код. И видит робот ещё одно поле.
    Фамилия: __________
    Ничего подозрительного, просто ещё одно поле. Нужно заполнить! А это и есть наш горшочек с мёдом.
    Настоящий пользователь это поле не увидел — мы его скрыли с помощью CSS. Он отправил форму с пустой фамилией. А старательный робот фамилию заполнил.

    Попался!
    Мы его игнорируем: заполненная форма уничтожается, письма не отсылаются, аккаунт не регистрируется. Спам не прошёл!