будни

Что нового в нашем приложении?

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

Во вторых, мы поняли, что нужно всё-таки садиться рисовать «нормальный дизайн».

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

Что уже есть?

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

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

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

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

Меня больше достают интеграции. Когда разные системы должны работать вместе.

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

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

Только коды эти приходят по почте. Поэтому они попросили завести в почтовой системе клиента адреса для отправки и получения. Что может пойти не так? Да всё!

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

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

Жду, когда эти письма начнут попадать в спам.

Если можно обойтись без внешних зависимостей и интеграций — лучше без них!

Сделали классный внутренний инструмент для эйчаров высокочастотного трейдера Wunder Fund. Силами одного (!) программиста за 7 недель!

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

Подробности — в новом кейсе на сайте.

Хотите классную разработку в срок? Пишите @samatg

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

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

Я сначала написал: «а вот если бы у финдира в сейфе в запечатанном конверте были бы ключи доступа и инструкция по входу…».

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

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

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

Мы уже вовсю работаем над новым, 13 сезоном; скоро запуск. Только что записали эпизод про ИИ-инфлюенсеров, у меня было 6 утра, у гостя — 8 вечера, у редактора вообще 11 ночи.

Уже записали один из самых сложных эпизодов сезона — про ИИ-психотерапию. 3 часа готовили вопросы! (обычно от часу до двух) Гостья — известный подкастер, практикующий психотерапевт.

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

Новый публичный сезон — скоро!

Очень волнительно. В какой-то момент, после 10 сезонов была усталость, а теперь как будто новое дыхание — пробуем новые темы, новые форматы. Идеи и предложения можно обсудить в чате подкаста (нас там уже 1500!) или отправить записку команде через бота.

Сегодня подвели итоги AI-хакатона от Ани Булдаковой. Больше тысячи участников из 80 городов, онлайн и офлайн!

Я как член жюри отсмотрел около 20 работ. На масштабе заметил, как сложно участникам четко сформулировать ключевую гипотезу проекта и сфокусированно её проверить. Финалисты выделялись именно этим умением не разбрасываться, а сделать ключевое.

Во вторых, приятно видеть, как много людей «scratch their own itch», то есть делают продукт «для себя», для решения задач, с которыми столкнулись сами. Волейболисты сделали приложение для организации турниров и игр, люди, которые не могли найти работу — тренажер интервью и так далее.

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

Спасибо Ане Булдаковой за организацию, а всем участникам — за участие. Надеюсь, что не последний! Запись трансляции финала — на ютубе.

P. S. Кажется, что для меня лично главное — это как классно потусили с жюри ❤️

На прошлой неделе было удивительное:

1. Федя признался, что понял кайф вайб-кодинга (до этого он всё время говорил, что понимает, что это такое, но я бы описал его прошлую позицию как просвещённый луддизм); надеюсь, сделаем про это с Федей отдельный эпизод подкаста.

2. Настя, наш операционный директор (не программист), завайбкодила прототип для клиента в lovable. Раньше бы мы назначили встречу с продуктовым дизайнером, он бы нарисовал макеты, мы бы сделали пару встреч и итераций, дальше бы мы его, может быть, сделали кликабельным, дальше бы посадили фронтендеров его заверстать. А тут Настя сделала всё сама за пару часов. И отправила клиенту не просто макеты, а полноценный прототип. Клиент — стартап, в котором нужна возможность связать врачей и пациентов, так эта шайтан-машина нашла бесплатное решение для видеосвязи и прикрутила его к прототипу.

Настя выглядела поражённой и даже встревоженной: «Самат, с помощью этого можно перестроить работу с клиентами». И спросила: «А нужны ли будут программисты?» и вообще: «Какое наше место в этом новом мире?»

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

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

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

—

Ну и наконец, если в каком-то будущем мы сможем делать крутые программные продукты «совсем без программистов» — то:

1. долгосрочно, у нас будут гораздо большие проблемы, потому что перестроится вообще весь рынок интеллектуального (а с развитием физических роботов — вообще всего) труда, мир изменится;

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

—

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

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

Если вы продакт, дизайнер или основатель бизнеса и у вас есть вопросы про разработку или трудности с разработкой — пишите, буду рад помочь! @samatg

Как перезапустить проект технически?

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

Они пользуются уже третьей версией своей платформы. Фронтенд на low-code платформе Bubble, бэкенд частично на flask и частично n8n. Всё работает, приносит пользу, проект поднял больше миллиона долларов инвестиций.

Как навести порядок, радикально увеличить скорость доставки фич и гарантировать масштабируемость?

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

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

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

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

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

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

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

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

На фотографии тот самый фикус-душитель опутывает дерево, как новый бэкенд опутывает старый.