Давно не читались виделись

Больше 3х месяцев ни одного толкового поста 🤯 я думал это "кризис жанра", оказалось просто нет идей о чем писать. Канал - крайне требовательная штука. Писать надо регулярно, интересно и разнообразно. Так, как я пока ещё не умею.

Какие планы дальше?

Для начала, я решил опубликовать все свои айтишные заметки, хаотически собираемые в ноушене за годы работы. Там много всего и лютый разнобой. Я всё откладывал момент, чтобы причесать контент, структурировать, но похоже я не заставлю себя сделать это разом, поэтому буду делать по частям. Там материалы по Swift, Kotlin, C# (странно, но факт), по JVM и Unix, выжимки из техническо-бизнесовой литературы и так далее. Ставлю на то, что моим 8-ми подписчикам и миллионам будущих 😁 такой винегрет, вряд ли придётся по душе, но я это сделаю, скорее ради себя, столкнуть с мёртвой точки моё желание нести свет своего опыта в этот мир.

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

🚀 Стартап в соло #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 человек. Это недостижимый уровень доверия и менеджмента, на который многие известные компании просто неспособны. Отсюда и БДУИ.