Каким запомнился VTB API Hackathon и зачем это банку
В этой статье мои коллеги — лидеры треков VTB API Hackathon Александр Галкин, Диана Налегач и Камилла Куликова — расскажут, какие задачи моделировали, какие архитектурные решения видели у команд и почему именно такие задачи сегодня определяют развитие финтеха.
Недавно ходили в нашу филармонию на прекрасный концерт молодёжного оркестра. Я смотрел на орган и видел не просто музыкальный инструмент, а грандиозный, исторический аналоговый интерфейс. И уровень его сложности прям впечатляет!
Работать с Kafka в DBaaS — удобно: инфраструктура поддерживается сильно проще, пока вы фокусируетесь на логике приложения. Но есть нюанс: прямой доступ к брокерам и CLI ограничен. Это усложняет отладку, анализ данных и диагностику consumer — особенно если у вас десятки топиков и групп.
Kafka UI — это Open Source-инструмент, который решает описанную проблему: он предоставляет веб-интерфейс для просмотра топиков, сообщений и состояния consumer groups без прямого доступа к брокерам.
На связи Ксения Ершова, проектировщик интерфейсов в Selectel. В статье расскажу, как развернуть на облачном сервере Kafka UI в публичном доступе, подключить его к Kafka-кластеру в DBaaS Selectel и проверить, что все работает.
Изменения интерфейса мобильного приложения часто упираются не в сложность реализации, а в скорость релизного цикла: даже простые правки проходят через полный конвейер — разработку, рецензирование, сборку и публикацию. При высокой частоте изменений это увеличивает time-to-market, перегружает команду и делает быстрые итерации по интерфейсу практически невозможными.
Меня зовут Михаил Рыбочкин, я бэкенд-разработчик в компании GRI. Участвую в разработке и поддержке платформы для крупного ювелирного ритейлера. Я расскажу, как реализован Server-Driven UI для интернет-торговли с более чем 1000 розничных магазинов; как устроено управление конфигурацией интерфейса через Django Admin и как это позволяет менять интерфейс без релизов приложения; какие у этого подхода есть ограничения и какой инцидент произошёл в эксплуатации. Особенность нашего подхода в том, что SDUI одновременно обслуживает и нативные мобильные приложения, и веб на Vue. Один конфиг, один API, две целевых платформы
На предприятии, где я работаю, купили пускатель ПБР10А производства «Овен». Мне выдали его для опробования, изучения свойств. Кто-то вычитал где-то, что им можно заменить, применяемые нами на предприятии приборы ПКП1 того же производителя.
Привет! Я Оля, лид дизайн‑системы Альфа‑Банка на мобильных платформах и я всерьёз считаю, что знания о вёрстке незаслуженно списали со счетов, особенно в 2026 году, когда дизайнеры всё чаще думают, что ИИ сделает за них всю работу, а вёрстку вообще можно не трогать.
Увы и ах. Вёрстка — это не просто «разложить прямоугольники на макете». Это мост между дизайном и кодом.
И — спойлер: ИИ тоже нужно учить, и учить на правильных примерах, но сначала стоило бы научиться вёрстке самому. Про ИИ в этой статье не будет — но зато будет много про православную ручную вёрстку: расскажу, почему считаю важным обращать на неё внимание при создании макетов и заранее закладывать правила, по которым она формируется. Особенно в эпоху, когда конкуренция высока, а ИИ кажется волшебной таблеткой.
Проводной телефон по воздуху
Пришёл как‑то внук к деду в деревню. Посидел, чай попил, по огороду прошёлся — и давай в телефоне ковыряться. Потыкав по экрану, вздохнул и говорит:
— Дед, тут у вас связь какая‑то лесная. То одна палка, то «только экстренные вызовы». А поговорить нормально — по своим городским тарифам — вообще разориться можно. У меня за пару дней в деревенском роуминге счёт набежал, как за месяц дома.
Дед усмехнулся, поправил очки и отвечает:
— Так ты к кому пришёл жаловаться? Я у нас в деревне главный по проводам и связи. Если мобильный дорогой — будем делать проводной. Только у нас провод будет не под землёй, а по воздуху.
— Дед, какой ещё провод по воздуху? Это же уже почти магия.
— Это не магия, — говорит дед. — Это нормальная инженерия и немного хитрости. У нас же уже есть всё, что нужно: стабильный интернет через NR‑712, коробочка, которая умеет переводить старый добрый аналог в IP, и телефонный провайдер, который даёт отдельный номер с тарифом дешевле, чем у твоего мобильного оператора. Надо только правильно это собрать.
Внук смотрит на него, как на шамана от электроники.
— То есть в доме будет стоять обычный проводной телефон, а разговаривать он будет через интернет по воздуху, а не по медному кабелю?
— Именно. Для тебя — обычная трубка на столе и нормальный номер. Для инженера — радиоканал, SIP и немного танцев с бубном вокруг железа.
На следующее утро дед начал колдовать. Сначала он достал из чулана пыльный VoIP‑шлюз — «коробочку», о которой говорил вчера. Подключил к нему старый телефонный аппарат, оставшийся от бабушки. Затем вытащил NR‑712 — беспроводной интернет‑модуль, который цеплялся к ближайшей вышке на холме.
Как только дизайн-система разрастается больше, чем на 10-20 кнопок, а брендов у вас становится несколько — JSON-файлы с токенами превращаются в кошмар. Дизайнеры экспортируют токены из Figma, разработчики получают пулл-реквест на 5000 строк измененного кода, и никто в здравом уме не может сказать: "А что именно поменялось и ничего ли мы не сломали?"
А если вместо английской буквы "c" в коде будет русская? А что если токен зациклился сам на себя? А если у одних токенов более 3-х уровней вложенности, то как поведет себя система? А если нужного токена нет в одном из модов? Да и вообще, как узнать, какие токены можно вынести в примитивы, а какие в семантику и отдельные файлы для брендов?
Чтобы решить эти проблемы, я написал веб-интерфейс Tokens Dashboard — ты кидаешь в него JSON (архив, папку, файл, несколько файлов — не важно), а он выдает красивую и понятную аналитику. И сегодня мы разберемся, как это работает.
Программа полностью бесплатная и доступна как для пользователей Mac OS, так и Linux / Windows. Она портативна и не мусорит в системе — вы просто удаляете папку, если она вам больше не нужна.
Что подразумевается у Хаммера и Чампи под «переносите процесс с учётом ограничений технологий»? Технологии меняют структуру правил организации процесса, позволяя делать его более плоскими. Но на что указали авторы манифеста примером с коровьими тропами?
Это интуиция авторов манифества, которую можно раскрыть с помощью классических трудов по культурологии (Хёйзинга для свойств динамики человеческих институтов), социологии (для переложение культурной онтологии на техно‑социальное пространство) и базовых понятий CS.
Когда продукт растёт, хаос в интерфейсах появляется почти незаметно. Одинаковые сценарии начинают решаться по-разному, команда тратит всё больше времени на повторяющиеся вопросы, а пользователи сталкиваются с непредсказуемым опытом. Удержать продукт от такого распада помогают понятные гайды и стандарты проектирования, которые фиксируют общие правила и собирают работу команды в единую систему.
Меня зовут Владимир Фрадков, я руковожу группой дизайна «Стандарты и развитие» в личном кабинете продавца Ozon. В этой статье я хочу поговорить о том, как упорядоченность и системность помогают в дизайне и почему единый документ с правилами может стать тем самым «кольцом всевластия» для вашего продукта.
Пока все в погоне за всё более универсальными ИИ-агентами пытаясь создать тот самый AGI по нашему подобию, мне кажется полезным спуститься на уровень ниже и посмотреть на более приземлённую инженерную проблему.
Мы неплохо научили модели работать с текстом, кодом, изображениями и инструментами. Мы научили их вызывать функции, научили эти ИИ писать собственные инструменты каждый раз для задач которые повторяются миллионы раз, видеть как мы(фото), думать как мы(рассуждения). Мы научились – дообучать их под новые сценарии через fine-tuning.
Но если убрать хайп, остаётся неприятный факт: во многих практических задачах модели по-прежнему работают грубо и дорого. Особенно хорошо это видно на фронтенде.
Сегодня у модели есть два типовых способа "увидеть" сайт. Первый – читать код: HTML, CSS, JS, и серверную логику (если вы предоставили модели доступ). Второй – смотреть на скриншоты, а в более дорогом варианте – на видео (хоть и таких решений я не видел, и скорее не видео, а слайд-шоу, но считаю логичным внедрением для некоторых сценариев).
И эти оба подхода неудобны. А обучать модель внутреннему представлению через имеющиеся виды зрения – как правильно, – как распознать кнопку итд – дорого, требует ещё больших данных, больше вычислений. А банально небольшое отклонение стиля уже ломает верстку. Да с бэкендом мы можем строить среду в которой благодаря RL обучению модель научится решать задачу.
Но как быть с интерфейсом? Фото дает слишком много шума в виде пикселей, а код дает много лишнего шума в виде разметки, скриптов. Когда обычному пользователю: не нужно смотреть на каждый серый пиксель фона кнопки, или изучать все стили, js и html разметку сайта, он видит овал на котором написано "войти" – и понимает что это – кнопка, особенно, если при наведении или нажатии цвет фона кнопки меняется.
Перевод подготовил автор канала Друг Опенсурса, приятного прочтения, заранее благодарю за подписку
В статье описывается навигационная структура из 20 UX-паттернов, разделенных на уровень стабильности, фокуса, ясности и контроля. Подход предполагает использование чата как механизма обработки, а документа как основной рабочей области.
Думали, что в количестве ответов на пост надо считать только живые ответы? А вот и нет, мы всё делали неправильно!
Баг, странная логика или «так задумано»?
Меня зовут Динара, я владелец продукта Naumen Service Desk и аналитик в команде внедрения, занимаюсь настройкой интерфейсов для Enterprise-клиентов.
В работе регулярно сталкиваюсь с одним и тем же конфликтом. С одной стороны — система как инструмент бизнеса: эффективность, снижение затрат. С другой — опыт пользователя: его привычки, когнитивная нагрузка и эмоциональный отклик.
Где здесь золотая середина? И как получилось, что от интерфейсов, которые должны упрощать жизнь, пользователи порой устают сильнее, чем от физического труда?
В этой статье я разберу, как развивались интерфейсы, почему «упрощение» не всегда делает продукт понятнее и какие принципы помогают находить баланс между функциональностью и удобством.
…В какой-то момент, ковыряясь в своём геоорганайзере «Места» (я писал о нём на Хабре), я поймал себя на простой мысли:
Всё работает — но не живёт
Нет, я не адепт восстания машин. Я о другом…
В первой части я показал, как пузырьковая диаграмма помогает увидеть связи в данных, которые не видны в таблице. Но как только данных становится больше — всё начинает ломаться: пузырьки наезжают друг на друга, цвета путают, а статичная картинка перестаёт что-то объяснять.
Это тот момент, где многие говорят: «Ну значит, инструмент не подходит».
На практике — подходит. Просто его нужно довести до рабочего состояния.
В этой части разберу три вещи, без которых bubble chart в реальных задачах не живёт:
• как справляться с наслоением,
• как использовать цвет без визуального шума,
• и как добавить время, чтобы график начал показывать не только «что есть», но и «что происходит».
Покажу на том же кейсе складской аналитики — с интерактивными приёмами, которые реально работают в дашбордах и на встречах.
Честно говоря, я долго не мог решиться написать и опубликовать эту статью. Зачем, думал я, возиться с не самой популярной технологией и изобретать велосипед — реализовывать функции, которые уже где‑то есть? На этот вопрос у меня нет универсального ответа — каждому своё.
Сначала мне казалось, что рассказывать о таких «подвигах» не слишком интересно. Все любят истории об успешном успехе. Потом я вспомнил: главное — не итог, а путь, опыт и знания, которые ты получаешь по дороге. Как только я начал смотреть на материал как на обучающий, делиться им стало намного проще.
Бывает так: с какой то технологией уже разобрался, а вот перейти к новой боязно. Учить новые движки непросто, да и текущий инструмент уже не справляется с задумкой… Сомнения часто мешают двигаться вперёд, но народная мудрость «глаза боятся, а руки делают» никогда не подводит.
В итоге я решился и попробовал FXGL для 3D‑рендеринга. Но не для того, чтобы сделать полноценную игру(хотя она и получилась), а чтобы соединить расчёты по системному моделированию с элементами геймификации. Уточню: я не призываю использовать FXGL во всех случаях. Для серьёзных 3D‑проектов есть отличные инструменты — Unigine, jMonkeyEngine, Godot, Unreal Engine. Я попытался собрать и упорядочить знания, которые получил в ходе своего небольшого эксперимента.
Модальные окна — пожалуй, самый спорный элемент любого интерфейса. Они врываются в процесс, требуют внимания и вынуждают принимать решение прямо сейчас. Поэтому хорошая «модалка» — это не про красивый внешний вид, а про уместность. Про то, чтобы вмешаться в нужный момент и не навредить.
Но чтобы понять, где эта грань, стоит сначала разобраться: а что вообще происходит, когда модальное окно появляется на экране?
Привет, я Таня — работаю ведущим продуктовым дизайнером опыта покупателя в Ozon. Среди моих продуктов «Избранное», «Вишлисты», мини-апп «Доставки посылок», а в прошлом я дизайнила «Карточку товара». Год назад я ротировалась в команду «Корзины», потому что хотела для себя новых вызовов.
На примере редизайна «Корзины», я хочу показать, как сегодня меняется роль дизайнера в продукте, чем дизайн-стратегия отличается от просто красивого концепта, почему такие изменения невозможно делать в одиночку.
28 марта 2026 года инженер Midjourney Cheng Lou выложил в открытый доступ библиотеку, которая за неделю набрала почти 40 тысяч звёзд на GitHub. И имя ей — Pretext. Это движок текстовой верстки на чистом TypeScript, который полностью обходит DOM и браузерный layout рефлоу. За этим стоит вполне большая проблема и красивое решение.
Давайте разберемся, что это такое, зачем оно нужно, как устроено и стоит ли тащить к себе в проект.
