Влад Кибенко // qbnk // Mini Apps, Development and Me

Хватит отправлять мне это д*рьмо

Трансляция запущена! Рефакторинг, новые фичи, AI-free / Vue / GoLang / !project — Software and Game Development — twitch.tv/qbnk

Я с ума схожу, или что? По рабочей задаче появилась необходимость вставить видео одного из прошлых анонсов Telegram про автоматизацию. Я вставил, а потом присмотрелся. Аватарку ставил 2 мая, пост выложили 7 мая. Нигде подобных иллюстраций людей в последних анонсах Telegram не нашёл, но скорее всего такую вставили, так как реальное фото Динеша вставлять вряд ли стоило. Скорее всего просто совпадение. Прикольная отсылка к Силиконовой Долине в видео, кстати. Только сейчас приметил.

Telegram в X поставили тот баннер, что мы выбрали на стриме. Он, кстати, был на предпоследнем месте в голосовании. Для тех, кто не был, на стриме я не оценил идею ставить на баннер с 9/11 (трагедия в США с башнями-близнецами), а у этого варианта сейчас 58.2%. Не оценил со стратегической точки зрения. Когда хочешь усилить своё присутствие на западе, будет странным прикалываться на такие темы в соц. сетях. Этот мем мне показался самым забавным из всего того, что было предложено. Молодцы!

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

Трансляция запущена! Разработка npm-пакета для проекта / Vue / GoLang / !project — Software and Game Development — twitch.tv/qbnk

Привет! Я к вам с работой! 👨‍💻 Мы постепенно расширяем команду в @mira (The Open Platform — TOP), поэтому в штат ищем себе новых коллег, готовых к плотному сотрудничеству. Кого ищем: — CTO. Очень важная и непростая роль. У нас достаточно обширный спектр технологий и зон ответственности, и будет здорово, если во всех них будет какой-то опыт. Если не во всех, то не страшно. Нужно будет принимать ключевые инфраструктурные решения и руководить небольшой группой разработчиков. — Backend Engineer. Мы пишем на Node.js, разрабатываем бота в Telegram, используем GraphQL, постепенно ковыряемся в Web 3, много времени отводим под работу с провайдерами AI. Ищем человека, который впишется в наш небольшой зоопарк из контекстов. — Product Designer. Чмок-чмок, туда-сюда. В поисках крутого дизайнера, который всегда готов сделать из приложения не только конфетку, но и ультимативный полезный инструмент. У нас много интересных и непростых дизайн-задач, которые хочется отдать готовому к этому профессионалу. — Senior Product Manager. Наша Даша громко плачет, придавили Дашу задачи. По этой причине требуется человек, у которого есть сильный опыт в развитии продукта, готового вывести его на новые вершины. Не бойтесь подавать резюме, даже если чуть-чуть не вписываетесь по требованиям. Наш HR и Даша с этим разберутся. Когда будете подавать резюме, укажите, пожалуйста, что пришли от меня. Это не для того, чтобы мне финансовое вознаграждение выдали. Просто мне приятно понимать, что я кому-то смог своим ресурсом помочь 🙂 ——— А стрим сегодня.

Трансляция запущена! Разработка npm-пакета для проекта / Vue / GoLang / !project — Software and Game Development — twitch.tv/qbnk

😐 Про DRY и Франкенштейнов Не так давно попался shorts IT-блогера и разработчика ThePrimeagen, где он рассказывал про одну из 3 проблем веб-разработки — DRY. Для тех кто не знает, DRY (Don't Repeat Yourself) — это подход, который призван как можно чаще переиспользовать код в рамках кодовой базы, а также сужать ответственность к какому-то определенному участку кода. Что-ж, подход вполне себе неплохой, но по моим ощущениям он не всегда понимается корректно, а из-за этого непонимания создаёт массу других проблем. Сколько-то лет назад я слепо следовал этому подходу, считая, что чем меньше кода пишу, тем лучше. Нужно переиспользовать как можно больше кода, выделять что-то в библиотеки, и снова переиспользовать. Как можно догадаться, слепая вера ни к чему хорошему не приводит. С моей точки зрения, основная проблема DRY — Франкенштейны. Под Франкенштейнами следует понимать сущности, которые разрослись в следствие расширений в попытках переиспользовать сущность. Иными словами, это те сущности, которые потеряли свою идентичность. Это можно попробовать представить как какой-то React- или Vue-компонент, который изначально выполнял свою узкоспециализированную роль, но из-за того, что кому-то показалось, что он вписывается в другой части проекта, было принято решение его немного расширить. Несколько таких итераций спустя, компонент может превратиться во Франкенштейна. Следует понимать, что ничего плохого в таких расширениях нет. Тут важно лишь следующее: 1. Не сломаете ли вы ничего, если расширите сущность? 2. Точно ли данное расширение следует применять, а не реализовать отдельную сущность? Не потеряет ли сущность свою идентичность? 3. Точно ли при реализации текущей задачи вам нужна именно эта сущность? Когда-то давно, то ли в чате, то ли на трансляции, мы обсуждали такое явление как генерализация. Простыми словами — это попытка обобщить что-то, связать одно с другим, объединить. Так вот, ещё тогда мы решили, что именно излишняя генерализация является корнем многих проблем в любой разработке. Да, это наверное почти одно и то же с DRY, но "генерализация" звучит как термин общего характера и больше мне нравится. Вчера в кодовой базе Платформера я закончил метаморфозы, связанные с отвязкой от @tma.js/vue-kit (который только в этой монорепе и существовал). То же самое я сделал и в рабочем проекте. Тогда я думал, что "когда-нибудь зарелижу это как отдельную библиотеку", что добавляло накладных расходов и ограничений на поддержку. Я пытался разрабатывать библиотеку таким образом, чтобы её можно было переиспользовать, чтобы она была абстрагированной от текущего проекта, но понял, что как минимум сейчас это не нужно. Я просто тратил сильно больше ресурсов ради ничего. Выводы — Дублировать код — не плохо. В рабочем проекте я не стесняюсь иногда называть компоненты, типа "Button2", но запоминаю, что это нужно будет переработать (какой-то из двух таких компонентов надо выбросить). Периодически я копирую код из одной части проекта в другую, и это просто быстрее, чем сидеть и пытаться это обобщить в какой-нибудь одной функции. Чаще всего это никак не аукается, а если потом повторения будут слишком частыми, можно и порефакторить. — Обобщайте с умом. Помните про то, что обобщение чего-то !== сделал всё правильно. Во-первых, обобщение может быть не всегда корректным, как минимум идейно. Во-вторых, поправив что-то в обобщенной сущности, есть риск поломать приложение там, где эта сущность используется. Обобщая какой-то код в функции, вы берёте на себя дополнительную ответственность — такая функция становится зависимостью для всех тех мест, где используется. А в чем большая проблема зависимостей? Правильно, в случайном нарушении работы в неизвестных местах в следствие правок кода зависимости. При отсутствии обобщения такой проблемы нет, но есть другая — если в копируемом коде обнаружится ошибка, придётся пройтись по всему проекту и поправить её. В общем, ищите баланс 🍷

Вайбкодеры открыли для себя кронджобы и создали loops. Попалось интересное видео от NeetCode про новый тренд в разработке при помощи AI — loops: https://www.youtube.com/watch?v=vM6DNlsdpsg Честно говоря, прикола я тоже так и не понял. Это и правда, будто бы, обычные кронджобы, которые запускают своих назначенных агентов. NeetCode привёл интересный кейс с тем, что если некий флоу состоит из 10 частей, в котором успех выполнения каждой составляет 95% (100% достичь вряд ли выйдет), то вероятность того, что результатом флоу будет успешный результат — примерно 59%. Как будто, не тот показатель, который хотелось бы иметь в реальной разработке. Это мы сюда ещё не включаем то, какие решения принимает AI в плане модификаций кода, что в будущем может привести к бОльшим проблемам. Складывается впечатление, что без какого-то оператора такие флоу достаточно опасно и контр-продуктивно заводить.

Трансляция запущена! Serverless-функции в Платформере #4 / Vue / GoLang / !project — Software and Game Development — twitch.tv/qbnk

👩‍💻 Я отказался от Apidog в пользу Postman Привет! На последнем стриме рассказывал, что Apidog мне не нравится из-за того, что интерфейс просто невероятно медленный, и пользоваться таким продуктом очень тяжело. Анимации долгие, интерфейс часто достаточно долго реагирует на ввод, и это создаёт ощущение того, что приложение страшно тормозит. Именно по этой причине я начал искать альтернативы. Я посмотрел некоторые из предложений, которые вкидывали на трансляции, и пришёл к выводу, что хотелось бы чуть больше функционала, чем есть в предлагаемых приложениях. В связи с этим я решил попробовать вернуться к Postman, ибо не пользовался им уже достаточно давно, а посмотреть на изменения хотелось. Ну и вот, потыкался, и понял, что Postman мне очень даже подходит. Я хотел нормальную интеграцию GraphQL-запросов (в этом плане в Postman как будто стало получше с момента последнего использования, но там ещё есть над чем работать), и Postman тут оказался неплох. Я хотел нормальную скорость работы интерфейса, и Postman тут тоже оказался на приемлемом уровне. Да, он тоже, не сказать, что шустрый, но работает заметно быстрее, чем Apidog. Исходя из моего опыта, в Postman самый широкий функционал, который потенциально может закрыть и мои будущие потребности. Таким образом, Apidog дизлайк 👎, Postman — лайк 👍 #devtools ——— Стрим сегодня вечером. Расскажу о последних изменениях, об идейных проблемах, и будем дальше допиливать функционал с функциями приложений уже на фронте.

👩‍💻 Разобрался с serverless-функциями в Платформере Сегодня на трансляции мы наконец допинали serverless-функции на серверной стороне Платформера. Дело осталось за не совсем малым: ➖ В админке реализовать UI для управления serverless-функциями. Это уже практически полностью готово, но в связи с последними правками, нужно будет ещё подкрутить. Займёмся на следующем стриме. ➖ В лаучнчере реализовать мост для вызова таковых функций. Будем, по сути, заниматься тем же, что и разработчики клиентов Telegram, в контексте Telegram Mini Apps — накидаем манифест, который декларирует, какие методы известны лаунчеру, и какие у них есть параметры. Но сделаем сразу правильно. ➖ Реализовать библиотеку для разработчиков. Чтобы разработчикам не пришлось пользоваться сырым postMessage с "угадай какими параметрами", накидаем типизированную библиотеку с уже вложенной логикой. По сути, реализуем @tma.js/bridge, но для Платформера. С блэкджэком и... Ну вы поняли. Закончил сегодня стрим в небольшом тильте оттого, что зависли из-за какой-то ошибки в сторонней библиотеке для исполнения JS в Go. Как уже и сказал, я разберусь, а потом расскажу в чём дело. Так вот, копнул я в исходники, и выяснил — дело в том, что если мы пытаемся вызвать исполнение JS-скрипта из горутины, отключающйся от той, в которой создали JS-рантайм, библиотека будет тихонько не работать, но об этом узнаете только в проде. Чтобы отключить проверку горутины, там есть специальная опция, которую Claude, конечно же, попытался пропихнуть. Сообщить о том, что в таком случае каждый вызов JS-скрипта будет стоить 110kB памяти, он не решился. Это к сегодняшнему вопросу о том, "нужно ли мне учиться быть программистом, если нейронки всё умеют?". Нужно.

Трансляция запущена! Облачные функции в Платформере #3 / Vue / GoLang / !project — Software and Game Development — twitch.tv/qbnk

Трансляция запущена! Хранимые функции в Платформере #2 / Vue / GoLang / !project — Software and Game Development — twitch.tv/qbnk