🚀 Стартап в соло #1

Именно этим я занимаюсь с сентября 2024 и, пожалуй, пришло время начать делиться процессом с миром.

Предыстория.

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

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

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

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

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

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

#стартап_в_соло@machine_head_ru

Стартапы крутятся, коды мутятся, разве что денег с этого пока нет 😁 классика )

Но речь пойдет не о доходах, а о нюансах процесса. У любого стартапа с мультиплатформенным продуктом всегда встает дилемма - какие технологии применить, чтобы сократить time-to-market. Мне как инженеру должно быть просто, подумаете вы, и ошибетесь. Инженеру-предпринимателю еще сложнее. Как инженер я не боюсь технической сложности, но как предприниматель боюсь быть втянут в решение технических, а не продуктовых проблем

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

Опытным путем доказано - Kotlin не является кроссплатформенным решением, экономически выгодным для стартапа. Ниже ряд причин:

- Родная среда для Kotlin - JVM и Android. Понадобятся годы, чтобы инструментарий для разработки под другие среды стал годен к использованию из коробки. Всё, что сейчас есть для разработки под iOS и Desktop предельно сыро - на iOS нет интеропа со Swift, а на десктопе тут и там торчат волосатые уши Java Swing. Тут и там нужны какие-то плагины к компилятору, настройка в Gradle - черная магия.

- Compose Multiplatfrom - безбожно тормозит на прокрутки даже простых списков, а Kotlin Multiplatform в быстрорастущих проектах обрастает такой сложностью, что нужна отдельная команда, вникающая в нюансы сборки и платформенной интеграции

- Единственным местом где можно что-то взять и сделать на Kotlin - это бекенд. Тут правят Spring и Quarkus. Вероятно, их использование было бы оправдано в all-in Kotlin стеке. Но как мы поняли концепция провалилась, а значит и корпоративных тяжеловесов из мира Java в стартап тянуть смысла нет.

Kotlin на беке больше Java чем Koltin: корутинами даже не пахнет, тащить в проект родные Kotlin-зависимости резона нет.

Еще один минус - JVM не для экономных. Даже оптимизированный Dockerfile на выходе дает образ минимум в 250-300 МБ. В рантайме инстанс тоже не мал и не блеснет производительностью. Нативные компиляторы типа GraalVM чтобы удешевить владение инфраструктурой -
лишние приседания, вредные для стартапа.

В итоге весь написанный Kotlin-код был заархивирован. Опыт получен. Бекенд был переписан с кучей новых фич Golang за 1,5 недели. Продуктивность стартаперская, docker-образ 9Мб, производительность чудовищная.

Мобильное приложение будет нативное. На Swift. Потому что я в нем эксперт.

Вывод. Берите то, что хорошо знаете или способны адаптировать в кратчайшие сроки. И если это не Kotlin, то он не станет для вас универсальным решением.

#стартап_в_соло@machine_head_ru

Риторической идеи пост

В предпоследнем комментарии, отчаянный борец за кибер-демократию и наш соотечественник Павел Дуров, объявил об эксклюзивном партнерстве с TON Foundation, в качестве финансовой инфраструктуры для экосистемы Телеграм.

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

Итак, что же нам предложил Павел в качестве новой альтернативной площадки для приложений и бизнеса:
- прием оплат только звездами где, например, уже заложена 30% комиссия Apple/Google
- 4% административные расходы Телеграм
- шкурный обменный курс из TON в фиатные деньги в официальном кошельке

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

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

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

Как сказал John Gall “Системы стремятся провалиться сразу же после своего величайшего триумфа”.

БДУИ или как мы решали одну проблему, а получили 10 других

Ребята из Авито в этой статье поделились описанием их реализации Backend-driven UI.

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

Какую проблему решали в Авито, по версии автора статьи:

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

Перевожу:

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

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

Классно же звучит, не так ли? Кажется, все проблемы решены.

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

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

И самая большая проблема, от которой бежали, но в которую напоролись: BDUI также развивается как любой продукт, который надо обновлять. Его инфраструктура обновляется через сторы: фиксятся баги, добавляются фичи. Через какое-то время возникает чудовищная фрагментация возможностей фреймворка на девайсах юзеров. А JSON-то общий! Как для любого API приходится вводить фолбеки и версионирование. На практике же логгеры сыплют ошибками парсинга, интерфейс на глазах у юзера моргает и откатывается к дефолтному, написанному руками без всяких bdui, ну или к предыдущему стабильному макету, а это уже, напомню, возврат к третьей проблеме доставки фич в разное время.

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

BDUI, кто бы его не начал пилить, всегда лежит между нативом и кроссплатформой, вроде React Native, который, к слову, решает те же проблемы примерно тем же подходом. Но вместо объединения преимуществ, объединяются недостатки:

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

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

Напомню, что ios приложение Telegram практически полностью написал 1 человек. Это недостижимый уровень доверия и менеджмента, на который многие известные компании просто неспособны. Отсюда и БДУИ.

Яндекс за всё платит. Или обосрался. Смотрите видео, комментарии излишни 😂😂😂

Проверьте, у кого еще так же работает )

С праздником Великой Победы!

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

Рассказывайте своим детям о подвиге наших дедов и прадедов, о героях этой невообразимой по масштабам войны. 100-летие Победы организовывать им!

#80летпобеды

Фулстеков не бывает?

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

На заре популяризации профессии (я считаю 2000-2010 этим периодом) стек типичного программиста был… любой! Я после школы спокойно кодил на Си утилиты для MS-DOS/Windows, десктопные приложения на Delphi, в универе автоматизацию БД на FoxPro, анимировал на ныне почившем ActionScript в Macromedia Flash, вдохновляясь роликами Happy Tree Friends 💀. Помню, написал приложение на J2ME под Symbian, чтобы искать и качать музыку с зайцев.нет с возможностью дозагрузки при обрыве (из-за обрывов мобильной связи в Opera Mini приходилось постоянно перекачивать, а мегабайты недешевые, особенно для студента). Принцип был простой: стало интересно, пошел ковырнул совершенно ублюдскую на вид документацию, (если вообще была) написал 20-30 классов, собрал с матюками и готово. И уж чего я не припомню, так это желание пройти курсы по новому языку или фреймворку, чтобы что-то с ним закодить.

Так какая у меня тогда была специализация? Правильно, тыжпрограммист. Фуллстеками тогда и не пахло. Придумали их позже не программисты, а HR-ы. Им комфортнее всех разделить по департаментам, по скилам, по грейдам, чтобы стало проще понимать кто перед ними. В период с 2010-го по 2015-ый, на который пришелся резкий рост запроса на кодеров, оказалось, что на рынке совершенно отсутствуют кадры. В компаниях осознали, получить “Symphony/Angular/Android/Spring/<название фреймворка>” разработчиков можно быстрее, чем дожидаться магистров информатики.

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

Так всё таки, фуллстеки существуют или нет? На мой взгляд, уважающий себя программист должен быть способен разобраться как в сетевом стеке, так и в пайплайне рендеринга фреймов на экране смартфона, написать сервер с веб-сокетами и скрипты развертывания. У современных айтишников типичный аргумент против этого тезиса - всё знать невозможно. Так вот, всё знать и не нужно! Программные системы - это фрактал, большой «треугольник», состоящий из множества малых, таких же треугольничков. Из знания о малом, можно вывести знание о бóльшем, а не наоборот, как стремятся делать люди в погоне за сакральными знаниями из курсов. Именно поэтому, адекватные технические руководители при найме смотрят на мышление и предлагают писать код на любом комфортном языке.

Фуллстек это или нет, решайте сами или поделитесь мнением в комментариях.