Привет.

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

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

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

Ждите постов по Solid, хорошего дня 🙂

Напоследок покажу пример. У нас наверняка в каждом приложении будет какой-нибудь файлик (или компонент), который описывает стили для текущей платформы. Например, для iOS у нас один шрифт, для Android — другой.

Чтобы корректно использовать плагин, нужно завести вот такие файлы:

// GlobalStyles.common.scss
// This file contains global styles used across all platforms. It should be imported
// by all other platform-specific styles files.
body {
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
padding: 0;
margin: 0;
}

// GlobalStyles.android.scss
@use "GlobalStyles.common";

body {
font-family: "Roboto", "Helvetica Neue", sans-serif;
}

// GlobalStyles.ios.scss
@use "GlobalStyles.common";

body {
font-family: -apple-system, 'SF Pro', BlinkMacSystemFont, 'Helvetica Neue', sans-serif;
}

Ну и сам блок (из методологии BEM) GlobalStyles:

// GlobalStyles.platformed.ts
import './GlobalStyles.common.scss';
import './GlobalStyles.ios.scss';
import './GlobalStyles.android.scss';

При сборке под iOS, импорты GlobalStyles.common.scss и GlobalStyles.android.scss будут порезаны 🔪 и в итоге в бандл их CSS-код не попадет.

Плагин расписывать не буду, вы можете найти исходники в отдельном репозитории, который я под всю эту идею выделил — conditional-substitution-example (сам плагин). С позавчерашней трансляции я его подпилил, чтобы учесть больше кейсов и срезать больше ненужного кода. В каких-то местах пришлось отказаться от регулярных выражений в пользу парсинга в AST (начинается вот тут), так как их стало совсем недостаточно.


git clone git@github.com:heyqbnk/conditional-substitution-example.git
cd conditional-substitution-example
pnpm i
pnpm run build
pnpm dlx serve dist
# Открываете браузер и переходите на ссылки типа
# - localhost:3000/common/index.html
# - localhost:3000/ios/index.html
# - localhost:3000/android/index.html

// Заключение

Какой итог? Мы сделали так, что имея одно приложение, мы генерируем N отдельных бандлов, которые загружаются пользователями без overhead-а. Клиент берет только тот бандл, который специфичен для его платформы.

Теперь знаете где это использовать еще эффективнее? В Платформере. Он позволяет указывать разные ссылки для разных платформ. Вы собираете приложение, получаете N бандлов, выгружаете в Mate, а Платформеру под каждую платформу отдаете ссылку на index-файл специфичный для этой платформы. И всё.

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

Не бойтесь писать полезные плагины, не бойтесь писать эффективные решения. Это не всегда так сложно, как кажется. На этом у меня всё, пользуйтесь на здоровье, и продуктивной недели! 😇

// Погнали

Что-ж, давайте попробуем написать самое первое решение, которое лезет в голову. Буквально, решение в лоб:

import { ButtonCommon } from './Button.common.js';
import { ButtonIos } from './Button.ios.js';
import { ButtonAndroid } from './Button.android.js';

const Button = platformed({
common: ButtonCommon,
ios: ButtonIos,
android: ButtonAndroid,
});

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

common — это тот компонент, который будет выбран в случае, если под целевую платформу не нашлось своего компонента. Это также нужно в случае, если вы когда-нибудь соберетесь добавлять новую платформу, и вам не пришлось пробегаться по всем вот таким platformed-компонентам и прописывать новую платформу.

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

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

Как сделать так, чтобы не пришлось скачивать код всех компонентов, а лишь тот, что нужен для текущей платформы? Нужно резать🔪 Резать, вырезать, конечно же, ненужный код.

Вернемся к нашему примеру, но перед этим скажу, что такое virtual:platformed. Так как работаем мы с Vite и пишем под него плагин, в сборщике есть специальная конвенция наименования виртуальных модулей. Виртуальные модули — это те модули, имплементация которых определяется самим сборщиком, а точнее каким-либо конкретным плагином (то есть нами, по сути). Мы можем динамически из таких модулей возвращать всё, что нам угодно.

Так вот, virtual:platformed — это наш модуль, из которого на самом деле ничего возвращаться не будет.

import { platformed } from 'virtual:platformed';
import { ButtonCommon } from './Button.common.js';
import { ButtonIos } from './Button.ios.js';
import { ButtonAndroid } from './Button.android.js';

const Button = platformed({
common: ButtonCommon,
ios: ButtonIos,
android: ButtonAndroid,
});

Представим, что сборку мы делаем под Android. Какой мы результат хотим видеть? Вот такой:

import { ButtonAndroid } from './Button.android.js';

const Button = ButtonAndroid;

Чего делаем? Режем 🔪 код.

Плагин, который я написал, делает следующее:
— Все мутации, описанные в плагине, должны происходить только в файлах, расширение которых оканчивается на .platformed.(tsx?|jsx?). Это берется за правило, дабы не было каких-то ошибочных ожиданий касательно того, где плагин применит свою работу.
— Проверяет, что импорт из virtual:platformed происходит только в файлах с расширением указанным выше. Опять же, чтобы разработчик не допустил ошибки.
— Находит все специфичные для платформ импорты и оставляет только те, которые совпадают с целевой собираемой платформой. Если оказалось так, что импортов непосредственно для целевой платформы не нашлось, оставляет импорты из common-уровня.

Таким образом, плагин подготавливает для сборщика код таким образом, чтобы тот даже не знал ни о каких импортах кода от других платформ. Из-за этого нагрузка на tree-shaking будет меньше, а также решается проблема с тем, что CSS априори не tree-shake-ается.

✍️ Conditional Build-Time Substitution

Примерно так мы позавчера назвали подход, подразумевающий разбиение одного дерева приложения на множество окружений. От себя сегодня я добавил ещё "build-time", чтобы название было более говорящим.

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

// Проблема

Еще 10-ого февраля я рассказывал про так называемые изоморфные компоненты в контексте разработки библиотеки Telegram UI, но давайте я кратко освежу вашу память и напомню про их плюсы и минусы

➕ Плюсы (а он тут всего один):
Компоненты автоматически подстраиваются под текущее окружение и мимикрируют под него. Нет необходимости использовать множество компонентов одного назначения, но разного платформенного контекста.

➖ Минусы:
— Дополнительный трафик: клиент вынужден скачивать JavaScript-код, а также CSS-код, который вообще не относится к его платформе. Таким образом, мы получаем внушительный overhead, и чем больше платформ мы собираемся поддерживать, тем значительнее будет проблема.
— Один интерфейс компонента под все платформы — это не дар, это проклятье. По этой причине компонент может получить свойства, которые используются на одной платформе, но не на другой. А еще важно помнить, что за этими свойствами может стоять какая-то раннее указанная логика, которая по итогу попросту не будет использована приложением.
— Тяжесть поддержки: изоморфные компоненты через какое-то время станет тяжелее поддерживать из-за того, что он — Франкенштейн. Этот компонент может использоваться сразу в куче разных контекстов, и допустить ошибку при внесении каких-либо правок достаточно легко.

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

// Теоретическое решение проблемы

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

✍️ Наши хотелки:
— Не хотим поддерживать N отдельных приложений, потому что поддержка этого слишком трудозатратна.
— Не хотим, чтобы пользователь Android версии Telegram качал JS и CSS, который связан с iOS версией приложения. Как минимум потому, что пользователь динамически не может изменить операционную систему.
— Хотим иметь изолированные компоненты, чтобы у каждого из них были свои свойства и логика, специфичная только для своей платформы.
— Хотим иметь fallback-компоненты, чтобы в случае, если для указанной платформы компонента не нашлось, мы использовали какой-то по умолчанию.

"Харя не треснет?", спросите вы меня. Не треснет, мы уже всё это практически реализовали.

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

// Дополнительные вводные

Ввиду того, что мы обитаем с вами сейчас преимущественно в Telegram Mini Apps, важно понимать, какие у нас есть окружения. На данный момент их как минимум 2 — iOS и Android, но по необходимости, можно добавить ещё какие-нибудь.

Тем не менее, подход, описанный в этой статье, применим и к немного другому формату "платформ" — разбиению не по платформам, а на отдельные полноценные проекты, но об этом не в этот раз.

Job is done! 👍

За эти выходные добил-таки дашборд с недоработками по Telegram Mini Apps. Хотел бы сказать большое спасибо всем тем, кто принял участие, и извиниться перед теми, чей репорт не попал в дашборд по тем или иным причинам. Мы собирали только те проблемы, которые бросаются в глаза, которые невозможно замечать, и при этом всплывают достаточно часто.

Репорт Павлу был отправлен, остаётся только ждать результатов 😉

P.S. На самом деле после такой проделанной работы, я ощущаю себя персонажем из фильма "Зеленая миля". Как оказалось, впитывать и фиксировать такой список недоработок морально вышло не так уж и просто.

Криптоинвестор в подарки Telegram, когда его опекун не дал ему ⭐️25 000 (41 000 рублей) на апгрейд пасхального яйца.

Осторожно, маты

Трансляция запущена!

Разработка Android UI в Platformer-е / Solid.js

— Software and Game Development
— twitch.tv/qbnk

Привет.

Работа над документом практически окончена, отправлять будем в понедельник — в начале рабочей недели.

Сегодня постримим, но ближе к вечеру, наверное. Если не успею доделать док, то доделаем на стриме. В противном случае поработаем над Android UI в Платформере.

В любом случае, держите ухо востро. Увидимся! 🙂

Захожу вчера вечером к Владу на дубайский балкон, а он смотрит на меня с таким лицом и говорит:
«Я, кажется, уязвимость в клиенте Телеграм нашел»

🫵 We Need You, Developer

Это не учебная тревога. Вчера Павел согласился принять нашу помощь, поэтому приглашаю всех, кому не безразлична судьба Telegram Mini Apps, принять участие в групповом сексе волонтерском событии для разработчиков.

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

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

Если хотите участвовать, то следуйте правилам:
— Полностью описывайте кейс воспроизведения. Указывайте платформу и пошагово расписывайте, что нужно сделать для воспроизведения проблемы. Всегда проверяйте, что используете актуальную версию клиента.
— Опционально. Описывайте причины возникновения проблемы и возможные способы её решения.

Я буду перепроверять все репорты, приводить их к необходимому формату, приоритизировать, и добавлять в документ. Публичный дашборд будет в Notion, его мы, вероятно, и передадим Павлу: ссылка на дашборд.

Павел ответил. Работаем.

Вы ведь знали, что Solid.js используется в Telegram Web K еще с октября 2023-ого года, да? 😏

Привет!

Хотел бы еще раз поблагодарить всех принявших участие в сборе на лечение на сообщение Павлу, а в особенности @dumov, @coalus и @tophackr, которые оказались топ-3 по пожертвованиям.

Павел поднял ценник на сообщение, но так как мы собрали практически целых ⭐️9.000, сообщение отправлено было 🤩

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

Трансляция запущена!

Работаю у Павла Дурова на балконе в Дубае

— Software and Game Development
— twitch.tv/qbnk

Трансляция запущена!

Работаю у Павла Дурова на балконе в Дубаи

— Software and Game Development
— twitch.tv/qbnk

💪 Сила в сообществе (и в правде, брат)

Нашли какой-то баг в платформе? Сообщите об этом в чате разработчиков — @devs_cis. А лучше посодействуйте решению проблемы. Можно сходить к разработчикам Telegram напрямую, можно предоставить качественный пример кода, который решает проблему, можно завести issue в связанных репозиториях Telegram. Да, нет никакой гарантии того, что что-то будет исправлено, но лучше попытаться что-то сделать и провалиться, чем не делать ничего.

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

👍 Используйте готовые решения

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

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

Также стоит понимать, что нужно использовать проверенные готовые решения, потому что Telegram SDK, например, многие проблемы скрывает, и о некорректном поведении вы даже не узнаете. Возможно по этой причине какие-то баги не фиксятся — из-за того, что кажется, что библиотека корректно работает.

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

Ну и, конечно же, важно не забывать про библиотеки @telegram-apps. Повторяться не буду, это просто мощная замена Telegram SDK. Кстати, используя Telegram SDK, пользоваться Платформером не выйдет. И это не потому, что я такой вредный и давайте используйте мою библиотеку, а потому, что в некоторых клиентах неправильно (что потенциально даже открывает уязвимости) реализована коммуникация клиента Telegram и мини-приложения. Telegram SDK эту проблему не решает, @telegram-apps/sdk@3 — решает.

Сюда же напоследок добавлю пример того, что самопис — далеко не всегда хорошо. В какой-то момент Команда Telegram наконец-таки открыла доступ к полю user.photo_url из данных инициализации, из-за чего у многих разработчиков слетел их кастомный код для проверки init data. Приходя в чаты разработчиков, они были крайней недовольны тем, что "Telegram что-то сломал", хотя проблема, на самом деле, была на их стороне. В это же время с публичными библиотеками, такими как @telegram-apps/init-data-node, проблем не было.

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

😬 Вы точно что-то не учли

Этот заголовок стоит запомнить, потому что основных клиентов Telegram — шесть:
— Telegram for macOS
— Telegram for iOS
— Telegram for Android
— Telegram Desktop
— Telegram Web K
— Telegram Web A

Все они работают по-разному, везде свои баги и своё поведение методов Telegram Mini Apps. Разное поведение, это скорее неправильно, конечно же, потому что у Telegram Mini Apps есть своего рода манифест, который описывает события, передаваемые между клиентом Telegram и мини-приложением. К сожалению, по тем или иным причинам, какие-то клиенты Telegram некорректно следуют этому манифесту, из-за чего возникают специфичные проблемы.

Разрабатывая мини-приложение важно понимать, что ваше приложение может быть открыто в одном из этих шести (не учитывая неофициальные) клиентов, и тестировать, соответственно, нужно во всех них.

🤚 Не используйте Telegram SDK

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

В Telegram Apps Center мы используем Telegram SDK, но в будущем переключимся на @telegram-apps. Сказать, что я дико недоволен опытом использования = не сказать ничего. Используя React и абсолютно не-реактивную библиотеку в виде Telegram SDK в одном флаконе, мне приходится выдумывать крайне плохие решения проблем. Telegram SDK не имеет реактивности, разве что через какие-то обходные пути, признаки, которые можно с чистой совестью считать костыльными.

В наборе пакетов @telegram-apps под известные библиотеки для создания интерфейсов написаны специальные биндинги, которые по сути выражены одной функцией useSignal. Сам SDK написан в реактивной манере, что позволяет отслеживать вообще любые изменения, а биндинги являются лишь адаптерами под реактивность в SDK. Это также позволяет написать любые другие биндинги, либо же не пользоваться ими вовсе, если вы пишите на обычном JS/TS.

В итоге использование в каком-нибудь React сводится к этому:

import { useEffect } from 'react';
import { useSignal, themeParamsBackgroundColor } from '@telegram-apps/sdk-react';

function Component() {
const backgroundColor = useSignal(themeParamsBackgroundColor);

useEffect(() => {
console.log('Background color', backgroundColor);
}, [backgroundColor]);
}

Чтобы в Telegram SDK сделать именно это, придется написать что-то в этом духе:
import { useEffect } from 'react';

function Component() {
const [backgroundColor, setBackgroundColor] = useState(window.Telegram.WebApp.themeParams.bg_color);

useEffect(() => {
function handler(event) {
setBackgroundColor(event.theme_params.bg_color);
}
window.Telegram.WebView.onEvent('theme_changed', handler);
return () => {
window.Telegram.WebView.offEvent('theme_changed', handler);
};
}, []);

useEffect(() => {
console.log('Background color', backgroundColor);
}, [backgroundColor]);
}

Не думаю, что кто-то из вас хочет вот этим заниматься со всеми данными из библиотеки, особенно учитывая тот факт, что это логически некорректная реализация, потому как вызов события theme_changed никак не связан с реактивностью в window.Telegram.WebApp.themeParams. А другую сделать и не выйдет.

Советы для разработчиков мини-приложений

В этом посте хотел бы передать свой опыт как разработчика, который с абсолютного нуля реализовывал два разных по сути приложения — панель управления (admin panel) и лаучнер мини-приложений Telegram Платформера. Сюда же добавим и то, что я поддерживаю клиентскую часть Telegram Apps Center, который на данный момент основан не на моих библиотеках (@telegram-apps), а на Telegram SDK.

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

✏️ Введение

Приходя в разработку мини-приложений на базе Telegram Mini Apps, важно понимать, что многое здесь работает не так, как ожидается, и проблема скорее не в том, что поведение отличается от ожидаемого, а скорее в том, что какой-то функционал просто работает неправильно из-за некорректной реализации на неподконтрольной вам стороне.

Используя что-то популярное, мы привыкли, что оно работает безотказно, либо же вероятность встретить какую-то проблему будет крайне низкой. Почему? Потому что уже многие разработчики это "популярное" попробовали, с проблемами столкнулись, о них сообщили, и их скорее всего исправили. Тем не менее, с Telegram Mini Apps работает всё не совсем так, к сожалению.

На платформе достаточно большое количество проблем, иногда недостаёт документации, а повлиять на исправление багов клиентов Telegram вы не в состоянии из-за ограниченного количества ресурсов со стороны Команды Telegram, pull request-ы в production с большой долей вероятности просто не попадут. Именно по этой причине я прошу использовать готовые решения, которые находят компромисс с проблемами, либо их закрывают.

Можно считать себя супер-крутым разработчиком клиентской части, который может написать любое приложение, но не стоит забывать, что опыт в обычном вебе может быть не применим к Telegram Mini Apps, потому как окружение, буквально, другое, другие баги.

Sup, lads!

Эту неделю скорее всего без трансляций, разве что на выходных. Готовим в Telegram Apps Center еще один большой релиз, поэтому придется сфокусироваться на рабочих задачах.

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

По Платформеру вечерами допиливаю всякие полезные мелочи и постепенно готовлюсь к следующем этапу — Android UI, либо же структурным изменениям в проекте. Там есть фичи и багфиксы, которые требуют структурных изменений. Не хочется на текущем этапе париться по поводу обратной совместимости, поэтому скорее всего будут изменения, а потом вайп (снос) БД. Изменения там связаны не только с улучшением того, что уже есть, но и связанные с безопасностью данных пользователей.

На этом пока что всё, хорошего рабочего дня! 👨‍💻

Трансляция запущена!

Development and shit! Working on Platformer today.

— Software and Game Development
— twitch.tv/qbnk

Помните, когда Павла задержали во Франции? Ещё тогда, в его поддержку, совсем небольшой командой, за 1-2 дня мы создали мини-приложение Digital Resistance, в котором каждый пользователь мог подписать петицию в качестве несогласия с действиями французских властей. В петиции и было то самое Открытое Письмо. Да, все мы знаем, как работают петиции, но цели при помощи неё высвободить Павла из багетной тюрьмы не было. Цель была лишь одна — оказать моральную поддержку, показать, что людям не всё равно.

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

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

Если же после этого сообщения Павел действительно повлияет на платформу, топ-1 донатера постараюсь как-нибудь отблагодарить, либо же придумаем что-то в рамках паблика.

🍷 Открытое письмо Павлу Дурову

Первое апреля уже давно прошло, поэтому этот пост — не шутка.

15 октября 2022-ого года был отправлен мой первый коммит, связанный с Telegram Mini Apps, в еще тогда созданной мной организации на GitHub под названием Telegram Web Apps. Я отчетливо помню те времена, когда мы на трансляциях с вами, подписчики, изучали исходный код SDK от Команды Telegram, таили в себе надежду там что-то исправить, и в конце концов пришли к решению создать что-то новое. Этому новому мы давали много разных имён, но сейчас все мы знаем его как коллекцию библиотек под штандартом @telegram-apps.

Еще тогда, в далеком 2022-ом году, будучи сотрудником ВКонтакте, фанатом мини-приложений этой компании, за символические 50.000 рублей в месяц мне было предложено стать энтузиастом платформы от Telegram — Telegram Mini Apps. Недолго думая, не из финансового, а сугубо личного интереса, я согласился, но до финансового сотрудничества тогда так и не дошло. Как можно понять, это никак не повлияло на мою заинтересованность в платформе, потому что иначе вы бы не читали этот пост.

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

Признаться честно, довольно непросто быть евангелистом технологии, на развитие которой не можешь оказывать прямого влияния. Ты не можешь просто взять и поменять исходный код клиентов Telegram, чтобы в них появились какие-то новые фичи, ты не можешь прийти к Павлу и сказать "смотри, у меня есть док, в котором есть фичи, которые очень нужны разработчикам, там всё расписано, что требуется сделать от Команды. Сделаем?". И самая боль далеко не в том, что нет какого-то полезного функционала, а в том, что в клиентах полно багов, и на это ты повлиять тоже не в состоянии.

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

На дворе 2025-ый год. Зрители на трансляциях наблюдают за развлекательным контентом в виде Влада, который вайнит по поводу багов, которые нашел ещё 15 октября 2022-ого года. Влад на трансляциях наблюдает за выдуманными зрителями.

Вторая часть далее

Вчера сидел мозговал над решением проблемы в админке Платформера связанной с тем, что не совсем понятно, как правильно мутировать кешированные данные от сервера. Напомню, что у нас используется SWR (Stale-While-Revalidate), который локально кеширует данные на определенный период для более отзывчивого интерфейса.

Ввиду того, что мы используем GraphQL, множество запросов, которые мы отправляем, могут работать с одними и теми же данными. Условно, есть вот такая схема:
type App {
title: String!
description: String!
}

type Query {
app: App
updateApp(title: String, description: String): App
}

И есть 2 таких query:

query Query1 {
app {
title
}
}

query Query2 {
app {
title
description
}
}

Так как по сути Query1 является подмножеством Query2, хотелось бы, чтобы клиент в качестве кешированного результата смотрел не только в раннее выполненный им запрос, но и в Query2. Но это я придумал только пока писал этот пост. Изначальная проблема немного в другом. Представим, что есть еще и мутация:

mutation Update {
updateApp(title: "Test") {
title
}
}

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

У приложения должно быть какое-то состояние, в котором все эти данные хранятся, верно? Но что конкретно там должно храниться и как с этим работать? Без понятия.

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

Сейчас в коде SWR используется вот примерно так:

const [a, b] = useGqlQuery(Query1, ...);
const [c, d] = useGqlQuery(Query2, ...);
const [e, f] = useGqlMutation(UpdateApp, ...);

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

То же касается и хука для Query2. После получения данных, он может сгенерировать событие full-app-received, который будет прослушиваться хуком для Query1. Тот в свою очередь обновит свой кеш.

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

Отчитываюсь перед руководством о посте, связанном с Telegram

Осторожно, маты

🏃 Про бег

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

В университете выяснилось, что у меня не сказать, что большой объем лёгких по сравнению с одногруппниками. Если мне не изменяет память, то ЖЕЛ (жизненная емкость легких) составляет чуть меньше 3.5л, когда у взрослых мужчин это обычно 3.5 - 4 литра. Добавляем сюда мышечный объем спринтера и получаем жуткий недостаток кислорода. Проявляется это всё в ранней одышке и закислении мышц, когда те не в состоянии выполнять свою функцию — сокращаться.

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

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

Упрощенно говоря, процесс дыхания состоит из двух частей — вдоха и выдоха. Каждая из этих частей занимает буквально 50% одного цикла дыхания. Логично предположить, что есть участки времени, когда в легких будет достаточно мало кислорода, либо его не будет совсем — к концу выдоха и началу вдоха.

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

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

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

P.S. Может быть сегодня постримим, но обещать не буду. Скорее всего завтра.

Придумайте IT-шную подпись

https://t.me/contest/406
Судьи завершили оценку всех представленных работ.

Основная задача – доработка текстового редактора – оказалась довольно сложной для большинства участников.

Мы решили расширить рамки этого конкурса. В настоящее время ведется окончательный подсчет голосов, и мы объявим результаты 8 апреля 2025 года вместе с подробностями второго раунда.

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

Трансляция запущена!

Development and shit! Working on Platformer today.

— Software and Game Development
— twitch.tv/qbnk

Привет, чач. С тренировки иду за кофе, потом домой и подрубаю. Ориентировочно через 40 минут. Будем пилить Платформер.

До встречи 👋

Нашел вот такое занимательное описание поля homepage в файле package.json, используя WebStorm

Это не то же самое, что "url". Если вы укажете поле "url", реестр примет это за редирект на ваш пакет, который был опубликован в другом месте, и плюнет на вас.

Буквально. Плюнет. Я серьезно.

Ну вот мы и запустились:
https://t.me/platformer_hq/26

Это был долгий путь, но самое интересное и сложное ещё впереди. Рад, что работает, как мне надо, и выглядит приемлемо. Но править там, конечно, есть еще много чего.

Может быть сегодня включу стрим, но во сколько конкретно не скажу. Держите ухо востро 🥪

Трансляция запущена!

Development and shit!

— Software and Game Development
— twitch.tv/qbnk

🥸 Про VK Max

Как-то тут пропустил пост про VK Max на vc.ru, сегодня напомнили про его существование.

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

Есть один очень большой вопрос — зачем? У вас есть ВКонтакте — гигантская социальная сеть. У вас есть VK Мессенджер — тоже мессенджер, как и VK Max. Как и зачем нужно поддерживать два (возьмем ВКонтакте и VK Max) сильно схожих продукта, когда один, по сути, входит в другой? Смею предположить, что новый продукт выпускается в целях репутационной отвязки от других, так как про VK Мессенджер вообще ничего не слышно (это плохо), а у ВКонтакте репутация смешанная — ни хорошая, ни плохая. Таким образом, VK Max будет псевдо-отдельным продуктом. Ещё важно понимать, что Max непублично предоставляется как замена Telegram, дальше поймете почему.

Почему я вообще пишу про VK Max? У них есть платформа мини-приложений. И вот здесь они уже сделали больший акцент на копировании, чем при копировании визуала приложения:

— Скопировали флоу создания мини-приложений. Идёте в MasterBot (а-ля BotFather), создаете бота, создаете мини-приложение.
— Скопировали часть API Telegram Mini Apps. Взято под копирку, те же наименования, свойства, идея, и так далее.
— API для работы с ботом очень сильно напоминает Telegram Bot API. Вижу множество знакомых сущностей.

Ради интереса глянул исходники SDK, аналога Telegram SDK, и скажу, что у Max код куда лучше, как бы прескорбно это не звучало. Косяки есть, да, но придраться особо не к чему.

У Max на старте уже есть Max UI — библиотека UI-компонентов. Мажорных релизов пока не было, но это дело времени.

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

В общем, вот что я вам скажу. Если Max не умрёт спустя небольшое время после релиза, и при этом компания будет до последнего пушить площадку, то, как бы это смешно не звучало, у Telegram могут быть ощутимые проблемы. Если по тем или иным причинам пользователи из СНГ, которые составляют внушительную часть базы пользователей Telegram, вдруг решат, что в Max совсем неплохо, и "это то же самое, что и Telegram", то Telegram может остаться без пользователей. И как бы кто не хейтил ВКонтакте, бюджетников заставят, а обычный люд думает совсем разношерстно. Хейтит, но пользуется.

А теперь давайте я напомню очень важную деталь. VK — гигантская организация, в которой работает очень много разработчиков. Если в Max отсыпать, условно, 90 человек, это уже в 3 раза больше чем весь технический штат Telegram. Как думаете, насколько сильно это повлияет на скорость разработки новых фич в новом мессенджере VK? Я считаю, что очень сильно. Вот и думайте.

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

На всякий случай в Платформере поддержку Max я всё-таки добавлю.

🥸 Про VK Max

Как-то тут пропустил пост про VK Max на vc.ru, сегодня напомнили про его существование.

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

Есть один очень большой вопрос — зачем? У вас есть ВКонтакте — гигантская социальная сеть. У вас есть VK Мессенджер — тоже мессенджер, как и VK Max. Как и зачем нужно поддерживать два (возьмем ВКонтакте и VK Max) сильно схожих продукта, когда один, по сути, входит в другой? Смею предположить, что новый продукт выпускается в целях репутационной отвязки от других, так как про VK Мессенджер вообще ничего не слышно (это плохо), а у ВКонтакте репутация смешанная — ни хорошая, ни плохая. Таким образом, VK Max будет псевдо-отдельным продуктом. Ещё важно понимать, что Max непублично предоставляется как замена Telegram, дальше поймете почему.

Почему я вообще пишу про VK Max? У них есть платформа мини-приложений. И вот здесь они уже сделали больший акцент на копировании, чем при копировании визуала приложения:

— Скопировали флоу создания мини-приложений. Идёте в MasterBot (а-ля BotFather), создаете бота, создаете мини-приложение.
— Скопировали часть API Telegram Mini Apps. Взято под копирку, те же наименования, свойства, идея, и так далее.
— API для работы с ботом очень сильно напоминает Telegram Bot API. Вижу множество знакомых сущностей.

Ради интереса глянул исходники SDK, аналога Telegram SDK, и скажу, что у Max код куда лучше, как бы прескорбно это не звучало. Косяки есть, да, но придраться особо не к чему.

У Max на старте уже есть Max UI — библиотека UI-компонентов. Мажорных релизов пока не было, но это дело времени.

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

В общем, вот что я вам скажу. Если Max не умрёт спустя небольшое время после релиза, и при этом компания будет до последнего пушить площадку, то, как бы это смешно не звучало, у Telegram охренеть какие проблемы. Все мы знаем, что за аудитория в Telegram — 1 миллиард пользователей, из них реальных миллионов 300, 95% из которых это СНГ. Если по тем или иным причинам пользователи из СНГ вдруг решат, что в Max совсем неплохо, и "это то же самое, что и Telegram", то Telegram просто останется без пользователей. И как бы кто не хейтил ВКонтакте, бюджетников заставят, а обычный люд думает совсем разношерстно. Хейтит, но пользуется.

А теперь давайте я напомню очень важную деталь. VK — гигантская организация, в которой работает очень много разработчиков. Если в Max отсыпать, условно, 90 человек, это уже в 3 раза больше чем весь технический штат Telegram. Как думаете, насколько сильно это повлияет на скорость разработки новых фич в новом мессенджере VK? Я считаю, что очень сильно. Вот и думайте. И представьте, если разработка будет фокусироваться не на каких-нибудь финтифлюшках для лохов, а на качественном функционале? Жесть.

Короче говоря, если Max не загнется спустя год после релиза, будет подсаживать на мессенджер больше пользователей, а потом к этому подключится правительство и заблокирует доступ к Telegram, то белому самолётику не позавидуешь.

Но на всякий случай в Платформере поддержку Max я всё-таки добавлю.

Как порядочный гражданин, купил лицензию на WebStorm и GoLand на год. Обидно было осознать, что я потерял свою скидку из-за того, что получил Open Source лицензию на год. Эх..

Что удивительно, WebStorm перестал показывать уведомление о том, что услуги в России они не предоставляют. То-ли баг, то-ли повезло так.

Трансляция запущена!

29 лет. Запомните меня таким

— Just Chatting
— twitch.tv/qbnk

🥳 Вот и 29 мне уже

Очередная достигнутая вершина в жизни любого живого организма — прожить год и не помереть. Этого, в целом, достаточно 😀

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

Как я уже когда-то говорил, День Рождения — это один из немногих дней в моей жизни, который буквально ощущается по-другому. Он будто бы улыбается тебе. Воздух пропитан какой-то атмосферой, которая говорит тебе, что это твой день. Жаль, конечно, что выпал он на рабочий день, но что уж тут поделаешь? ☹️

В общем, расписывать тут шибко не буду, остановлюсь на этом. Запомните меня таким в 29 — со смешными усиками, улыбкой и мимическими морщинами 😎

P.S. Сегодня с определенной долей вероятности включу трансляцию в 18:30. Работать не будем, поболтаем по душам, посмотрим видео, обсудим будущее канала на твиче.

Трансляция запущена!

Заканчиваем работу над Платформером

— Software and Game Development
— twitch.tv/qbnk

Привет. Сегодня включаемся в 14:30, будем дорабатывать Платформер. Осталось совсем немного. Расскажу интересных вещей, связанных с разработкой и не только.

Не опаздывайте! 🥸

Telegram Edition

😏 Я нашел идеальное решение

Идеального решения не существует, это кликбейт, но я нашел отличное решение. Речь, конечно же, о том, чем мы занимаемся на трансляциях — Telegram UI Kit for Solid.js.

На прошлом стриме я рассказывал о потенциальной не столь значительной проблеме как сложная структура компонентов. Ловите пример списка с одним элементом:




}/>



Item label
Item subtitle


Item right label






Толстовато выглядит, неправда-ли? Тогда я сказал, что в этом ничего плохого нет (в этом и правда ничего плохого нет), потому как в моем понимании задача разрабатываемой мной библиотеки — дать максимально гибкий и простой набор компонентов не выходящий за то, что есть в UI Kit-е. Пользователь уже сам решает как эту гибкость использовать, и если она не нужна, то он может написать переиспользуемые компоненты, состоящие из вот этих непростых структур.

В данном примере каждый из компонентов отвечает за определенную часть структуры более сложного вышестоящего компонента. У ListIosItem может быть только 2 элемента — ListIosItemLeft и ListIosItemBody. У ListIosItemBody только ListIosItemBodyLeft и ListIosItemBodyRight. Каждый из этих компонентов описывает определенный элемент в родительском компоненте, и двинуться в сторону от этой структуры не выйдет, можно лишь повлиять на сами элементы, их атрибуты и события.

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

Ну а вот если говорить о минусах — то это громоздкость. Для описания элемента списка с одним лэйблом придется использовать 5 компонентов, что не очень удобно.

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



}/>
Item label
Item subtitle
Item right label




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



}/>

Item label
Item subtitle
Item right label





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

UI Платформера сделаем до конца месяца, бета будет открытой 🫰

Всем хорошей рабочей недели!

Трансляция запущена!

Developing Platformer UI and Telegram UI Kit using Solid.js!

— Software and Game Development
— twitch.tv/qbnk

Sup, lads! 👋

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

Хорошего дня и до встречи!

Я уже даже не знаю, над чем конкретно тут посмеяться, так много идей.

Давайте поясню, потому что у нас наверняка много новичков-программистов.

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

Во-вторых, будучи ИБ-шником по образованию, слышать термин "дешифровка" просто уморительно. Дешифровка — это про взлом алгоритма шифрования, либо же подбор его параметров с попыткой получить исходные данные из зашифрованных. Расшифровка — процесс, обратный шифрованию, то есть преобразование зашифрованных данных к первоначальному виду, имея необходимые для этого данные. Видимо, автор имел ввиду "парсинг" или "валидацию", но как при этом в голову могло прийти слово "дешифровка", вообще непонятно.

В-третьих, строгость типизации не имеет ничего общего с валидацией данных, полученных из третьих источников. Ты хоть на C# пиши, данные валидировать все равно придется, и это проблема абсолютно любого языка. То что кто-то используя TypeScript пишет "response as MyType" — не проблема TypeScript-а, а разработчика с руками из попы.

В общем, кек. Или как там принято? Ауф?

🪙 Платная личка в Telegram

Совсем недавно Telegram обзавёлся новым полезным функционалом, позволяющим взымать плату за сообщения от пользователей, не находящихся в списке контактов. Продублирую своё мнение, которое озвучивал на трансляции.

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

Уже долгое время вокруг проблемы с личкой придумывались всякие workaround-ы, и вот, появилось более-менее конечное, рабочее решение. До появления Telegram Premium ограничивать список пользователей, которые могут тебе писать, нельзя было от слова "совсем". После появления премиума, у пользователей появилась возможность ограничить список пользователей контактами и другими пользователями с премиумом. Сами понимаете, это всё ещё не решает изначальную проблему, так как у многих пользователей / ботов есть премиум.

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

Стоимость сообщения настраивается и варьируется от 1 до 10 000 звезд. Да, наличие лимита всё ещё нельзя считать невозможностью написать в личку, но важно понимать, что если поставить лимит в 10 000, то вам вряд ли кто-то напишет, а если и напишет, то вы на этом неплохо заработаете 🫰 Ну а что боты? Они точно с таким ценником писать не станут.

Напоследок отмечу, что кроме того, что изначальная проблема решена, Команда выработала отличную идею, которая помогает заработать не только Telegram (через покупку звезд), но и пользователям. Такой подход к реализации функционала можно взять на заметку, потому как так хорошо монетизировать функционал, который в других проектах по умолчанию бесплатный, не так уж и просто, и чаще заканчивается провалом.

В общем, фича однозначно полезная, буду пользоваться 💯

Трансляция запущена!

Видео про FPI Bank, потом разработка!

— Just Chatting
— twitch.tv/qbnk

Трансляция запущена!

Development and shit!

— Software and Game Development
— twitch.tv/qbnk

Привет. Запускаем стрим в ~11:45. Сходим за кофе и начинаем. Посмотрим видео про ФПИ банк и продолжим работу над Платформером и UI-китом. Задерживаться в начале не будем, поэтому не опаздывайте! 🙂

😈 Рассуждения из мира backend-разработки

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

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

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

Ограничение по RPS

На входе у нас всегда есть какой-то промежуток, в течение которого мы производим замеры, а также количество запросов, которое можно выполнить в рамках этого самого промежутка. Давайте возьмем следующие лимиты — 3 запроса за 3 секунды. Отмечу, что это не то же самое, что и 1 запрос за 1 секунду, потому как в первом случае можно выполнить 3 запроса за самую последнюю секунду временного отрезка, но зависеть это наверное будет все равно от реализации, потому как можно взять за правило начинать замер с 3 запросами в 3 секунды начиная с первого полученного запроса (или смотреть назад на 3 секунды относительно текущего запроса). Тем не менее, это может оказаться чуть менее производительным, об этом будет подробнее.

Возьмем N за временной промежуток в секундах, а M — количество запросов, разрешенное в этот промежуток. N и M в нашем случае равны 3.

Самым поверхностным решением кажется следующее:

В Redis при получении запроса, по ключу формата {user_id}-{unix_timestamp} мы сохраняем единичку. При очередном запросе мы получаем N ключей — {user_id}-{now-1...now-N}. Срок жизни ключа равен времени замера — то есть N секундам. Нам не за чем эти ключи дольше держать, а берем именно N секунд, потому что если ставить меньше, то к моменту замера нужные ключи будут гарантированно пропадать. Соответственно, если мы смогли получить M записей или больше, то лимит достигнут.

Но как будто бы есть в этом что-то неоптимальное, правда? Как будто бы хранить целых N ключей избыточно. Что если всю временную линию начиная от какой-то заранее оговоренной точки до текущего момента разбить на промежутки по N секунд, и наполнять их запросами пользователя? Договоримся, что этой точкой является дата 01.01.2025 00:00.000.

При получении запроса, мы вычисляем, в какой временной блок попадает текущий запрос. Чтобы сделать это, находим разницу текущего времени и точки начала отсчета, а далее делим нацело на N. Представим, что в момент запроса время было равно 01.01.2025 00:05.000. Тогда нашим, будет блок с номером floor(300 / N), 300 мы получили разницей 1735689900 (01.01.2025 00:05.000) и 1735689600 (01.01.2025 00:00.000). В Redis мы находим ключ {user_id}-{floor(300 / N)}, смотрим, больше оно или равно M, и если да, то отклоняем запрос. В противном случае вызываем функцию инкремента с этим же ключом.

Таким образом мы всё так же храним ключи N секунд, только в N раз меньшем количестве.

Если что, я никаких гайдов и прочего не смотрел. Эти размышления построены сугубо с точки зрения решения вопроса "А как бы ты вот такую проблему решил без сторонних сервисов?"

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

В рабочем процессе часто задействованы следующие окна:
1. 2 окна с IDE — серверное и клиентское приложения
2. Фигма с дизайном
3. Браузер, в котором открыто разрабатываемое приложение в dev-режиме
4. Трансляция или видео. Их смотреть не во весь экран не могу

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

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

🙊 О доверии к Павлу

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

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

С некоторыми из билдеров у нас возникло общее предположение на тему того, в какой именно момент что-то пошло не так. Наверняка вы помните о том, что когда-то в инфополе появилась информация (да и собственно сами фотографии) о том, что Павел начал тусить с Гусейном Гасановым — общеизвестным на всю Россию инфоцыганом. Именно тогда, а может даже и чуть раньше, у билдеров начали появляться вопросики.

Зная всю правду про memhash, и видя ту ложь в лицо, которую откровенно пытаются пропихнуть, у билдеров закрепляется всё прочнее идея о смене платформы. Не уверен, что утилитарные проекты смогут набрать какую-то здоровую популярность в Telegram. Этого не произошло и во ВКонтакте, что уж тут говорить про Telegram. Во ВКонтакте вкладывались прямо-таки здоровенные ресурсы для улучшения платформы, для связки нативного функционала устройств с мини-приложениями, для улучшения качества всей платформы. По моим ощущениям, за ~3 года работы с Telegram Mini Apps, в платформу усилий практически никаких не вкладывается. И честно признаться, я вообще ума не приложу, куда именно они прикладываются.

По нашему общему мнению именно игры завоюют рынок в Telegram, а играм, уж простите, есть куда идти. Такими темпами, уже полностью потеряв доверие к фаундеру Telegram, рано или поздно билдеры просто полностью потеряют веру и в идею мессенджера, в следствие чего просто уйдут в другие аналогичные платформы с куда большим профитом.

Плюх #memhash #сделалодинчеловек #сделалзадвадня #вдохновилсятелеграмипавлом

Как же страшно меня бесит «фича» Телеграм, при которой ты можешь отправлять сообщение от лица группы, но при этом более не можешь делать это от своего лица. Скажите мне, кто догадался реализовать это именно так?

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

Это такая дебильная фича или баг?

Трансляция запущена!

Development and shit!

— Software and Game Development
— twitch.tv/qbnk

🗓️ О распорядке дня

Я тут открыл для себя новый подход к планированию распорядка дня и хотел бы поделиться интересными наблюдениями.

Из-за большого объема работ и подавленного состояния, примерно 2 месяца назад, если не больше, я забросил занятия в спортзале. Для тех кто не знает, спорт в моей жизни был практически всю жизнь. За свою недо-карьеру я успел официально получить первый взрослый разряд по легкой атлетике в забегах на 60, 100 и 200 метров (неофициально КМС на 60), и этот же разряд по пауэрлифтингу, хотя до этого занимался этим лишь 2 месяца. Да, я при этом был на пике натуральной формы и больше просто выжать никак не смог бы, но пауэрлифтинг я попробовал просто по приколу, времена такие были. Ну и со временем я забросил около-профессиональный спорт и стал просто заниматься в зале, дабы поддерживать форму.

Как можно предположить, после тяжелого трудового дня абсолютно нет никакого желания и сил идти 30 минут в зал, заниматься там 1.5 часа, а потом топать обратно эти же 30 минут. Времени это съедает достаточно много, народу в зале столько, что на стойках для жима лежа, люди лежат друг на друге и жмут одну штангу. То же самое и на приседе — люди приседают вдвоем с одной штангой. Особенно это примечательно сейчас, в период, когда все начинают готовиться к лету.

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

Ранее я был противником утренних посещений зала оттого, что состояние буквально ватное, и проводить силовые тренировки просто невозможно. Что-ж. Как выяснилось, у меня это зависит от того, как ты этот день начинаешь. У нас с Ксю есть договоренность, что 1 день мы едим дома, другой — ходим в кафе неподалёку. Вспомнив про это и учитывая тот факт, что тренировки тоже проводятся день через день, у меня возникла идея совместить эту идею с утренними походами в зал. Таким образом, теперь тренировочный день проходит так:

— Встаем в 10 утра, в 10:30 уже в кафе
— Кушаем, не обжираемся настолько, что ходить не можем, просто в меру
— Выхожу в 11 из кафе и иду 30 минут до зала, растрясываю пищу, работаю в голове (буквально, да, я просто занимаю мозг работой)
— В 11:40 начинаю тренировку и уже в 12:30 ее заканчиваю. Да, тренировка достаточно быстрая, но понимание того, что идет рабочий день, дисциплинирует тебя и вынуждает отдыхать между подходами не больше положенного.
— Обязательно принимаю контрастный душ в зале и в 12:45 выхожу в сторону дома, по пути захожу за кофе
— Около 13:10 я на рабочем месте, в отличном состоянии, совсем немного уставший, но понимающий, что вечер будет свободен и сейчас можно спокойно работать

Да, я не работаю по 8 часов в день, но работаю по 12, когда этого требует ситуация. В конечном итоге получается так, что и в форме ты себя держишь, и поддерживаешь отличное рабочее настроение. Вечер же при этом у тебя остается на прочие занятия. Например, на трансляции 🎤

На этом у меня всё. Сегодня постримим вечерком, держите ухо востро! 😏

✍️ О стратегии Telegram

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

Я периодически читаю канал Ghost In The Block и вот недавно наткнулся там на вот такой интересный пост, где автор канала подкалывает команду Telegram на тему того, что те еще не догадались до реализации какого-то нового, полезного функционала. Да, Ghost — человек очень специфичный, этого ему не занимать, но он не редко пишет здравые мысли, да и накидывает интересное чтиво на тему расследований, связанных с Telegram. Верить этому или нет, уже решать читателю, но сейчас не об этом. Собственно, я хотел бы поразмышлять на тему того, почему еще "не догадались".

Важно помнить про то, что команда Telegram достаточно мала. Как когда-то сообщал Павел, техническая команда составляет порядка 30 человек. Из этого несложно сделать вывод о том, что какие-то здоровые фичи, требующие больших ресурсов не только разработки, но и поддержки, реализованы скорее всего не будут. Если только те не будет приносить значительный финансовый поток. В противном случае пользователи получат очередную заброшенную фичу, на которую когда-то было потрачено множество ресурсов.

Это предположение подтверждается тем, что Telegram привык перекладывать ответственность на другие проекты, но готов сделать для них какой-то built-in функционал. Самый просто пример — third-party верификация. Telegram выдает проекту право выдавать эту верификацию, а как её проводить, проект уже решает сам. Аналогично и с верификацией пабликов, когда для того, чтобы получить галку, нужно иметь 2 галки в разных известных веб-сервисах. Ну и, конечно же, нельзя не упомянуть @wallet, ради которого команда сделала просто огромное количество почти эксклюзивного функционала.

В общем, Telegram ожидает, что разные области функционала будут закрываться разными командами, с которыми потом можно будет просто коммуницировать. Это не только переложит всю ответственность на сами проекты, но и не будет требовать от Telegram вложения каких-либо усилий.

Ищейки сидят и мониторят уязвимости с момента запуска. Главный поставщик RPS в нашем проекте

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

Честно признаться, даже как-то не верится. Наконец, удалось довести начатое до конца. Даже представить сложно, сколько в это было вложено раздумий, усилий, времени. Лично для меня это большой и важный шаг, потому что это пока единственный мой полноценный, большой проект, идею которого пришлось придумывать единолично и доводить до ума, а теперь ещё и запускать.

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

🦄 Ready... Set... Go! Beta has started!

This weekend, we finalized the first Platformer closed beta release, and the server is now ready to accept connections.

All closed beta test requests have been processed, and all compatible users have been added to the API whitelist. If you missed the beta form, you can still apply here: Beta Form.

We’d like to remind you that this release is GraphQL schema-only. We're currently working on the UI, which will be released next month. But for now, you can start testing Platformer functionality using the GraphQL interface. To help you dive into Platformer with ease, we've written a guide for Early Adopters: For Early Adopters. This guide should help you get started quickly and reduce any initial questions. Keep in mind that this document only covers the main API methods, so be sure to explore the full GraphQL schema at the following endpoint: https://mini-apps.store/gql.

If you discover anything not working as expected, have any questions, or have suggestions, feel free to join the chat: Platformer Chat and let us know.

That's all for now. Enjoy testing Platformer and have a great day!

Страх разработчика #2213: залив огромного количества изменений в production

На самом деле готовлю кодовую базу для нового разработчика

Трансляция запущена!

Development and shit!

— Software and Game Development
— twitch.tv/qbnk

Боевая готовность 20 минут — включаем трансляцию

UPD: Еще 30 минут, технические неполадки
UPD2: Перенос на 14:00 Мск, может раньше. Всё оказалось чуть хуже, чем думал
UPD3: Отмена UPD2

Из консоли разработчика в виджете Donation Alerts. Ну и стыд.

Предполагаемая история появления:
Чет не пойму, этот скрипт вызывается вообще? Добавлю console.log

Правда, не писать такой непотребный лог не догадались

🖥 Про культурный код

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

Все мы знаем, что идеального кода не существует, ведь термин "понятность" сам по себе субъективен. Тем не менее, я глубоко убежден, что можно достичь той планки, которая будет понятна большей части кибер-населения программистов.

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

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

Тем не менее, если мы говорим об IT-сфере, то университет, как и школа, просто предоставляет какую-то базу, но узконаправленную и более высокого уровня. Не стоит ожидать, что в университете будут рассказывать про какой-нибудь Vue.js, Solid.js и прочие, хотя GoLang, например, как я знаю, в программу завозится, как минимум в моем университете. Цель IT-университета — дать основу для образовательного роста, научить эффективным подходам к решению проблем, а также привить логическое мышление. Ни один курс по программированию, ни одно видео в интернете вас этому не научит, потому что там никто вам в задницу лезть не будет, лишь бы всё это в вас вбить. Университет — это как раз тот самый анальный крот, который просто вынудит вас обучаться, и в конце концов добьется поставленных задач. Мы не будем здесь рассуждать на тему хороший-плохой университет, потому что это уже отдельный топик. Ладно, может громко говорить "ни один курс/видео", но по ощущениям таковых практически нет. Авторы дают пережёванный материал и "пояснительную записку" почему так работает, но сами думать, почему это так устроено, вы не будете, а надо.

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

— Владислав Кибенко, 75 год до нашей эры

Так вот, к чему я вообще это. Мы привыкли считать, что чем больше у человека лет опыта за плечами, тем более он подкован в своей профессии. Ясно, что не станешь ожидать какого-то объективно плохого, бескультурного кода от человека, у которого 15 лет стажа работы. Важно понимать, что речь именно про ситуацию, когда сам человек не понимает проблемы, и считает, что с кодом всё в порядке. Что-ж, этот паттерн иногда нарушается, потому что опыт, всё-таки, бывает разный, как и база, а также уровень культуры.

Писать культурный код очень важно по нескольким причинам:

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

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

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

💬 Заключение

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

Помните — культурный программист некультурного может легко отличить по коду. На этом у меня всё, до встречи! 👋

😡 Это был процессор

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

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

Перейдя к процессору, я вспомнил про то, как в чате писали о проблемах с 13-ым и 14-ым поколениями i9, и начал гуглить. И правда, в Интернете тонна негативных отзывах об этих процессорах, в частности из-за их ранней деградации.

Посмотрев в настройки биоса, никаких оверклоков обнаружено не было, все настройки абсолютно стандартные, не подкрученные. Понимая, что проблема, вероятно, в ЦПУ, я полез в его настройки. Ну и long story short — проблема в процессоре. Мой кусок кала i9-14900K за 60 тысяч рублей надорвался примерно через год с абсолютно базовыми настройками и последними обновлениями биоса.

Чтобы решить проблемы с закрытием приложений, в настройках биоса нужно отключить Intel Turbo Boost и Intel Turbo Boost Max Technology 3.0, которые с какого-то перепугу включены по умолчанию, хотя выглядят как технологии для оверклока.

Отключив их, система начала стабильно работать, но при этом перфоманс заметно упал. Когда в Cinebench тесты набирали 1900 очков, то теперь набирают от силы 1200-1300. Сами понимаете, ни о чем хорошем это не говорит. Попробую еще отключить только Intel Turbo Boost Max Technology 3.0, но предполагаю, что процессор деградировал бесповоротно, и придётся брать новый.

Так вот, чач, чего делаем? Купить какой-нибудь i9-12900K, чтобы снова в капкан не наступить, или может AMD попробовать? AMD не использовал раньше никогда, но говорят, что их крутить надо, а я не очень хочу.

Или попробовать снова взять i9-14900K, но заранее покрутить настройки в биосе?

Тут напоследок есть вам совет — при покупке чего-либо обращайте внимание на срок гарантии на продукт. Как выяснилось, на мой кал была гарантия в полгода, что говорит о том, что он скорее всего недолговечный. Раньше вот как-то внимания не обращал, теперь буду.

Трансляция запущена!

Development and shit!

— Software and Game Development
— twitch.tv/qbnk

Сегодня французские новости пестрят информацией о задержании местными жандармами сошедшего с ума иностранца.

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

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

Привет, коллеги-подневольные.

Вчера, покурив кальяна, и поразмышляя о тщетности бытия, пришёл домой, и буквально за 2.5 часа наклепал документацию по всем новым мажорным версиям в telegram-apps. Напоминаю, где находится документация. Если не забуду, вытащу философские вопросы, которые иногда всплывают в голове во время и после дымо-сосательной сессии на трансляцию. Может и вам будет о чём задуматься.

По поводу Платформера—там запустили форму для доступа к закрытой бете, поэтому если ещё не видели, то не пропустите, вот пост. Достаточно подробно расписали, как это всё будет происходить.

На этом пока всё, неделя загруженная выйдет, поэтому могу пропадать. Тем не менее, постараюсь на днях включить поток. Хорошего дня! 👋

🥸 Про разработку UI-библиотеки для Telegram

Бывает такое, что вот не пишешь неделю, а потом как "бац!", и появляется желание о чем-то рассказать, да побольше. В этот раз поделюсь своими мыслями по поводу той библиотеки, которую делаю в фоне—Solid Telegram UI.

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

💭 Изоморфность

Сложностей в разработке именно текущей библиотеки достаточно много, с какими-то из них придётся мириться, с другими—справляться. Когда пытаешься сделать какую-то UI-библиотеку, которая пытается мимикрировать под текущее окружение, первая проблема, с которой ты сталкиваешься—это изоморфность (если, конечно, я терминологию не попутал).

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

Самые простые примеры изоморфных компонентов—Typography (типографика, просто текст), Button, Checkbox и так далее. Мы хотим использовать компоненты, не задумываясь о том, в каком окружении они будут отображены.

В этом примере нет ничего специфичного для какой-либо платформы, и выглядит, в целом, неплохо:

import { Button } from 'lib';

function MyComponent() {
return console.log('Clicked')}>Click me
}

Но что если появится что-то специцифичное для конкретной платформы? Что если, таких специфичных вещей станет больше?

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

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

💭 Решение

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

На самом деле, всё предельно просто. Под каждую платформу я сделаю отдельный компонент. Например, вот есть у нас Android и iOS. Мы хотим реализовать кнопку, значит будет 2 кнопки — ButtonAndroid и ButtonIos. У каждой кнопки может быть свой набор свойств, равно как и стили. Вы можете сказать "так это же в 2 раза больше работы", но это не совсем так. На самом деле, работы будет примерно столько же, потому что при реализации изоморфного компонента вам придётся как-то набор свойств и стилей сдружить, а сделать это так просто не выйдет. Ну и в конце концов, результат работы выйдет хуже, потому что API из-за объединения двух компонентов в один, лучше быть не может.

Как этим пользоваться? Есть 2 варианта: используя компонент для разделения, который дает библиотека, либо же написать свой, который свойства и будет "дружить", то есть делать то, о чем я писал в параграфе выше. Своим решением я даю возможность сторонникам двух идеологий (оптимальности и простоты использования) возможность реализовать свой подход.

Есть небольшой набросок, как может выглядеть разделенный компонент в Solid:

import {
SwitchPlatform,
WhenAndroid,
WhenIos,
ButtonAndroid,
ButtonIos
} from 'solid-telegram-ui';

function App() {
return (








);
}

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

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

import {
SwitchPlatform,
WhenAndroid,
WhenIos,
ButtonAndroid,
type ButtonAndroidProps,
ButtonIos
type ButtonIosProps,
} from 'solid-telegram-ui';

function Button(props: ButtonAndroidProps & ButtonIosProps) {
return (








);
}

Важно помнить, что никто не мешает комбинировать 2 подхода. Один можно использовать там, где вам нужна гранулярность, другой — там, где достаточно обобщенного компонента.

⭐️ "Conditional compilation"

Заголовок тут в кавычках, потому что не припомню, чтобы такой механизм был встроен в какой-нибудь сборщик. У нас как бы вообще нет компиляции никакой, но есть tree shaking, и правильнее бы это наверное называть Code Splitting. Так вот, подход с разделением компонентов чем невероятно полезен, так это тем, что вы не тащите лишнее.

Условно, вы делаете приложение только для iOS, значит используете только компоненты этой платформы. Вам не надо тащить еще N-1 платформ в бандл, которые пользователь никогда не увидит. Более того, код можно написать таким образом, что под каждую платформу вы сгенерируете отдельный бандл, и воспользуетесь функционалом чудесного Платформера с разными ссылками для разных платформ, в следствие чего, работа вашего приложения будет максимально оптимальной. Пользователь просто грузит приложение в таком виде, будто бы оно именно под его платформу и написано.

Но о том, как такое написать, я расскажу когда-нибудь в будущем 😇

Теперь про минусы 😒

У меня регулярно крашится игра, чаще всего во время сна, в промежуток 5-6 часов ночи. Видать, игра в этот момент что-то делает, что приводит к крашу. Была такая проблема с первой частью, но тут я больше грешу на свой ПК. В последнее время он в принципе не особо стабильно работает. Ещё есть проблема с тем, что какие-то настройки графики просто не применяются, хз почему.

Наворовав кучу вещей, их просто некуда сбыть. У меня куча брони стоимостью выше 1к, но продать их некому, так как все купцы — бичи. У них 300 грошей в кармане и как бы всё на этом. У меня в кармане сейчас около 8 000 грошей, и куда их деть, тоже ума не приложу. Надеюсь, далее откроются опции.

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

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

В общем, прикольная игра. Прямо как глоток свежего воздуха в нынешней обстановке в гейм-индустрии. Даже не пожалел кровных ~5-6k рублей на игру. На этом всё, хорошей рабочей недели! 👋

🚩 Про Kingdom Come: Deliverance 2

Все эти выходные я провёл за игрой, первая часть которой мне была интересна, и которую я до конца так и не осилил пройти—Kingdom Come: Deliverance 2. И вот, хочу накидать небольшой отзыв. Спойлеров не будет, поэтому можно читать спокойно.

Наиграв 42 часа в игре, я добрался до момента, когда тебя и еще 2 персонажей игры пытают в одном замке. Говорю специально абстрактно, дабы не заспойлерить тем, кто играл, или собирается играть. А те, кто уже играл, понимает про какой момент речь.

К этому моменту многие из скиллов в игре уже прокачены. Взлом, конечно же, уже максимального 30-ого уровня, многие другие около 20-ого. Отстают только алхимия, верховая езда, псарь. Хз зачем они вообще в игре нужны.

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

Далее, интерфейс. Вообще всё устраивает, работу выполнили очень качественно. Особенно нравится меню инвентаря с двигающейся "тумбочкой" с персонажем при переключении на лошадь. Не помню, было ли такое в первой части, но в этой есть наборы экипировки, которые сильно упрощают переключения между "режимами". Я собрал 3 сета:

— Броня для гачи-разборок, чтобы показывать, кто тут dungeon master.
— Незаметный, скрытный для взлома жопы. Не могу в таких играх без того, чтобы залезть к кому-то в карман или дом и своровать вяленую колбасу из погреба.
— Костюм клоуна, который имеет максимальное обаяние, дабы зад лизать шляхтичам.

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

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

Будучи бывшим сотрудником Яндекса, улыбнуло 😀

Особенно последние 12 секунд

🥺 Telegram UI for Solid

Этим постом уведомляю, что начал работу над Telegram UI под Solid. Реализация библиотеки не будет иметь ничего общего с тем, что есть в @telegram-apps/telegram-ui.

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

Через какое-то время дизайн-система будет опубликована, а за ней и сама библиотека компонентов. На данный момент там реализовано уже достаточно много, но к шерингу проект не готов.

На что тут прошу обратить внимание:

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

— Я занимаюсь этим не от лица TON Studio и сугубо в рамках исследования, поэтому вообще не факт, что эта библиотека появится в рамках @telegram-apps. Скорее всего это будет SDK-agnostic сторонняя библиотека.

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

В общем, как только появится чем поделиться, я обязательно это сделаю. Хорошего рабочего дня! 🙂

TON-холдеры сегодня с утра такие типа

Трансляция запущена!

Telegram Mini Apps v8 in @telegram-apps/sdk

— Software and Game Development
— twitch.tv/qbnk

Павел Дуров в ожидании аффилированного с Roxman-ом проекта, чтобы его прорекламировать

Павел Дуров выбирает какой бы проект аффилированный с Roxman-ом прорекламировать

Цена одна, прелести разные. У каждого свои.

Анбоксинг косметики телефона сделаем на трансляции. Теперь хоть смогу тестировать на Андроиде. И не говорите мне про эмуляторы

Французские доменные регистраторы живут в каком-то своём мире, ей-Богу. У меня английский включен, если что.

Я такие контролы в первый раз в жизни вижу

💬 Документация

Написание документации по обновлению потребует какого-то времени, поэтому в ближайшее время её ждать не стоит. Тем не менее, я верю в вас, вы быстро поймёте, что да как устроено. Тем более, что я скорее выпилил ненужный код, нежели чем добавил какой-то новый.

⭐️ @telegram-apps/types@2.0.0

Как уже и было упомянуто раннее, библиотека теперь содержит лишь типы, специфичные для самой платформы. Типы описаны так, как изначально задуманы разработчиками Telegram.

⭐️ @telegram-apps/transformers@2.0.0

Теперь библиотека в значительной мере использует другую — valibot. Пакет предоставляет набор функций для работы с самыми распространенными типами данных в Telegram Mini Apps.

⭐️ @telegram-apps/init-data-node@2.0.0

Ввиду того, что типы у нас теперь по умолчанию в snake case, тут тоже был сделан major release. Функции возвращают и принимают объекты в нотации snake case.

⭐️ @telegram-apps/bridge@2.0.0

Удаленные функции

В связи с переходом на mitt и переиспользованием его кода, я отказался от функций subscribe и unsubscribe в пользу on и off. Теперь для того, чтобы подписаться на все события, необходимо использовать код такого формата:

import { on } from '@telegram-apps/bridge';

on('*', event => {
if (event[0] === 'theme_changed') {
const { theme_params } = event[1];
// ..
};
});

Из библиотеки также была удалена функция defineEventHandlers. Теперь нет необходимости вызывать её явно, можно сразу использовать on.

Переменная $targetOrigin была переименована в targetOrigin, а из экспорта пропала переменная $debug. Теперь для установки debug-режима используется функция setDebug.

Улучшенная функция mockTelegramEnv

Функция mockTelegramEnv была значительно улучшена. Теперь она позволяет не только задать параметры запуска в среде, но и задать кастомную обработку вызываемых методов Telegram Mini Apps. Теперь вы сами решаете, как реагировать на методы, вызываемые приложением.

import { mockTelegramEnv, emitEvent } from '@telegram-apps/bridge';

mockTelegramEnv({
launchParams: { ... },
onEvent(event) {
if (event[0] === 'web_app_request_theme') {
emitEvent('theme_changed', { theme_params: { ... } })
}
}
})

Изменения в isTMA

Теперь по умолчанию функция isTMA использует простую проверку. Таким образом, вы не можете вызвать код isTMA('simple'), но можете вызвать isTMA() или await isTMA('complete').

Напомню, что под простой проверкой подразумевается попытка извлечь параметры запуска из текущей среды. Сложная заключается в вызове метода Telegram Mini Apps и ожидании ответа. Таким образом, вторая проверка более надежная, но может быть излишней.

Прочие изменения

Функция retrieveLaunchParams была немного упрощена и теперь позволяет извлекать параметры запуска как в snake case, так и camel case нотациях.

В библиотеке мы ушли от класса TypedError в пользу отдельных классов под каждую ошибку.

⭐️ @telegram-apps/sdk@3.0.0

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

Про sendData

Функция получила дополнительную проверку на inline-режим. Если приложение открыто вне inline-режима, isAvailable вернет false.

Про themeParams и miniApp

Теперь оба этих компонента монтируются асинхронно. Как выяснилось, предыдущая реализация themeParams.mount() была не совсем корректной.

Учтите, что miniApp.mount() под капотом монтирует themeParams, поэтому нет нужды вызывать themeParams.mount(), когда вы уже вызвали miniApp.mount().

Прочие изменения

Как и в bridge, было добавлено множество кастомных ошибок. Помните, что SDK почти полностью экспортирует bridge, поэтому изменения, представленные в секции @telegram-apps/bridge, коснулись и этой библиотеки.

💬 Заключение

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

Комфортной разработки! 👋

📣 @telegram-apps Major Release

Привет, разработчики.

Вчера был произведен каскадный major-release многих библиотек в @telegram-apps и в этом сообщении хочу рассказать, что же произошло в этом релизе.

💬 Почему?

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

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

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

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

💬 Новая философия

Ранее, мы описывали все типы, поставляемые клиентом Telegram, используя верблюжью нотацию (camel case). Например, у нас был тип InitData, в котором было поле authDate. В этом релизе я отказался от этой идеи и дам пояснение, дабы в дальнейшем это было интуитивно понятно и разработчикам.

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

В качестве примера возьмём то же поле auth_date. Да, от Telegram данные инициализации приходят как query-параметры, но это не значит, что в качестве значений у нас будут string или string[]. Поле auth_date задумывалось как поле, описывающее время создания init data, поэтому и в выводе вы будете видеть Date из JavaScript, а не значение вида "170000000".

Это же изменение коснулось и параметров запуска. Теперь в LaunchParams ключи описаны буквально так, как передаются нам от клиента. Таким образом поле platform заменилось на tgWebAppPlatform, а themeParams на tgWebAppThemeParams, и так далее. В конечном итоге мы будем работать с наименованиями полей, которые и задумывались разработчиками из Telegram, а искать документацию по таким полям будет значительно проще, как и писать её, собственно.

Для удобства, некоторые функции получили опцию для конвертации вывода в camel case. Например, retrieveLaunchParams.
⚠️ Важно
В утилитах, извлекающих init data или параметры запуска, возвращаемый тип включает неизвестные поля, они будут иметь тип unknown. Это нужно для будущей обратной совместимости. После обновления перепроверьте, что не используете код типа retrieveLaunchParams().initData, потому что такого поля не существует. Такой код надо заменить на retrieveLaunchParams().tgWebAppData. В некоторых случаях, TypeScript в этом коде ошибки может не усмотреть, поэтому будьте осторожны.

💬 Third-party библиотеки

Создавая @telegram-apps, я придерживался принципов Telegram, связанных с опаской и нежеланием использования third-party библиотек. По этой причине у нас никогда не было таких библиотек в экосистеме пакетов.

Мной было принято решение более не ожидать от Команды каких-либо действий в сторону поддержки @telegram-apps (странно было вообще этого ожидать), благодаря чему вы теперь можете поприветствовать новых "родственников" экосистемы — mitt, better-promises, error-kid и valibot. Не обращайте внимания на небольшое количество загрузок у better-promises и error-kid — эти библиотеки являются выходцами из @telegram-apps, которые были выделены в отдельные библиотеки для переиспользования.

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

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

Трансляция запущена!

Допинываю @telegram-apps/sdk 3.0

— Software and Game Development
— twitch.tv/qbnk