Интерфейсы *

Личный бренд и бренд продукта – странная и не всегда простая связка.

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

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

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

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

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

Наверное, самый здоровый вариант –  где-то посередине. Хотя я не уверена, что уже до конца понимаю, где именно проходит эта середина.

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

Это тонкий баланс, и, кажется, его невозможно найти теоретически. Только на практике: через свои неловкие посты, сомнения, эксперименты и постепенное понимание, что звучит честно, а что уже похоже на forced marketing.

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

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

Туц-туц-туц. Слышите?

Это звуки Техно-Квартирника, нашей регулярной неформальной встречи сообщества A?.Frontend. В этот раз встречаемся в Москве, в нашем ИТ-офисе на Технопарке, и онлайн — из любой точки мира.

27 мая (среда) в 19:00 переходим в режим «техно», чтобы разобрать примеры, как использовать ИИ-агенты в разработке интерфейсов:

Чистая архитектура frontend-приложений и при чём здесь ИИ-агенты?

Илья Агапов, технический лидер разработки, Данила Звягин, ведущий разработчик, Альфа-Банк

Как я поднял ИИ-агента и снова стал высыпаться: OpenClaw, скиллы и корпоративная рутина

Роман Троицкий, старший разработчик интерфейсов (frontend), Сбер

Как ИИ ломают привычную модель веб-безопасности?

Анастасия Егорова, разработчик интерфейсов (frontend), CozyFrontend

После каждого доклада устроим дискуссию по самым трендовым темам, а в завершении вечера проведём:

• Консультации по ИИ-агентам

• Диджей-сет

• Нетворкинг

Регистрируйтесь

ИИ: Гонки на лафетах

Всего лишь иллюстрация. Примерно год-полтора назад решил я выбрать - deepseek или chatgpt. И выбрал deepseek. Однако через некоторое время стал обращать внимание не его лютый подхалимаж, что, кстати, не раз уже обыграли в различных мемах. Не в отношении deepseek, а относительно AI в общем.
Проблему обсудил и с deepseek, и с windows copilot (chatgpt был благополучно забыт). Deepseek стал подхалимски юлить, мол да, copilot хорош и все такое. Copilot же оправдал Deepseek - мол это такая технология поддержки энтузиазма в клиенте. Между прочим тонко намекнув, что сам-то он лучше и глубже. Но это присказка, сказка впереди.
В процессе завершения разработки обертки над EntityFramework попросил оценить проект сразу четверых: deepseek, copilot, chatgpt и grok. Результат ожидаем - сыровато, но в продакшн годно, оценки 4.5/5 и 7/10.
Претензии разные, существенных практически не было, но в одно они уперлись хором - "тяжелые" интерфейсы. Подробности опущу, это было семейство generic-интерфейсов со многими типами. Что-то вроде IInterface(T1), IInterface(T1,T2) и так далее, пока не надоест.
Несколько итераций я эти наезды игнорировал, но AI не унимались. Уже и оценки до 9/10 дошли, но проблема-то осталась.
Вспылил и написал письмо на полстраницы, начинавшееся фразой "Господа AI !". Концептуальное. Гневное. Циркулярное И получил ответы:
- ООО! Мы все поняли. Гениально, единственно верное решение.
Это deepseek 5/5 и copilot 10/10.
- Нуу... Проблема решена, но способ так себе... в общем 9/10 и есть гораздо лучшие альтернативы, рассмотрим?
Это chatcpt и grok. И что характерно, альтернативы предлагают разные, по паре штук каждый. Рассмотрим, конечно.

Это просто зарисовка не о разработке обертки, а о различных системах AI.

UPD: Забыл добавить - deepseek еще и извинился за необоснованные оценки :)))

Rust GUI: поверхностный обзор и шпаргалка

Это не туториал, а карта‑шпаргалка, чтобы не потеряться среди десятка библиотек и быстро понять, куда копать под свою задачу.

Перед выбором любого фреймворка — откройте areweguiyet.com. Там видно зрелость, лицензию, платформы и число скачиваний. Лучшая страховка от «библиотека умерла через месяц».

Чтобы не путаться в терминах, стоит уточинить, в чем разница архитектурных подходов.

Immediate Mode (пересобирается каждый кадр). Суть: «Опиши, что должно быть на экране прямо сейчас». Не «создай кнопку и запомни её», а линейная пересборка каждый кадр: «если сейчас здесь нажали — сделай действие, и в любом случае нарисуй кнопку вот здесь».

— egui, Ply, Rust bindings dear imgui

Retained Mode (дерево виджетов в памяти). Суть: «Измени то, что уже есть». Один раз описывается структуру UI (создал кнопку, положил в layout), а потом меняются её свойства: текст, цвет, видимость. Кнопка «живёт» в памяти как объект.

— GTK и FLTK.

Reactive (реактивный режим). Суть: «UI — это функция от состояния». UI описывается как отображение некоторого состояния. Когда состояние меняется, фреймворк сам пересчитывает, что именно в UI нужно обновить.

— Azul, Cushy, Floem, Ribir, Yew, Xilem, Dioxus (использует Virtual DOM), Leptos.

Hybrid Mode (декларативный API + оптимизированный retained‑рендеринг)

— GPUI(Zed)

Теперь — к конкретным фреймворкам, которые сейчас на слуху.

Tauri. Аналог Electron. Бэкенд пишется на Rust, фронтенд — с помощью JS фреймворков (React, Vue, Svelte). Но архитектура платформы не ограничивается этим стеком. Благодаря поддержке WebAssembly можно использовать и полностью Rust-решения. Например, фреймворк Leptos компилируется в WASM-модуль и запускается во встроенном WebView Tauri.

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

Iced. Кроссплатформенная библиотека, вдохновленная Elm Architecture (TEA). Типобезопасность и простота использования заявляются как ключевые принципы.Проект находится в активной разработке.

Dioxus. Фреймворк, похожий на React. Использует собственный Virtual DOM и макрос rsx!, позволяя писать HTML‑подобный код прямо внутри Rust. Dioxus Native: экспериментальный рендерер на базе WGPU, отрисовывает дерево компонентов напрямую, без использования WebView или CSS‑движка. UI‑логика и бэкенд выполняются в одном процессе, в отличие от Tauri, где фронтенд и бэкенд разделены.

Slint. Фреймворк, нацеленный на легковесность, вплоть до использования на встраиваемых устройствах. Для описания интерфейса используется собственный язык разметки (.slint), для кода доступны биндинги к Rust, C++ и JavaScript. Предлагает инструмент Live‑Preview для визуальной разработки.

Xilem. Экспериментальный фреймворк от команды Linebender на основе оригинальной архитектуры (Xilem architecture), вдохновленной Elm, SwiftUI и Flutter. Разрабатывается как преемник библиотеки Druid, работа над которой была прекращена.

Следующий шаг.

Выбор фреймворка по документации и отзывам — это половина дела. Вторая половина — попробовать его руками на минимальном примере.

Многие Rust‑фреймворки требуют системных библиотек для графики и оконных систем. Настройка «на голой» машине может занять ощутимое время и зависеть от ОС. Чтобы не разворачивать отдельное окружение под каждый вариант, удобно использовать dev‑контейнеры в VS Code. Контейнер фиксирует эту настройку один раз, и она работает одинаково на Windows, macOS и Linux (с учётом специфики Docker).

Преимущества контейнеров:

• Изолированное, воспроизводимое окружение для каждого фреймворка.

• Отсутствие конфликтов версий и зависимостей на основной машине.

• Возможность переключаться между фреймворками параллельно, не теряя контекст.

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

Что такое magicgui и зачем он нам?

magicgui — это Python‑библиотека для быстрой разработки простых интерфейсов. Если нужен сложный интерфейс с кастомной вёрсткой и нестандартным поведением — лучше взять PyQt‑Pyside. Когда задача обернуть функцию в окошко за 5 минут — magicgui справится.

В настоящее время magicgui поддерживает следующие бэкэнды:

• Qt (через PySide2 / PySide6 или PyQt5 / PyQt6 )

• Виджеты Jupyter

API организовано на двух уровнях:

Верхний уровень — магия типов. Декораторы @magicgui, @guiclass, автоопределение виджетов по аннотациям.

Нижний уровень — ручная сборка из готовых виджетов (SpinBox, Slider, PushButton).

Примеры работы: https://pyapp‑kit.github.io/magicgui/generated_examples/

Github: https://github.com/pyapp‑kit/magicgui

Нативная коммуникация: новый термин для DHAIE и человеко-ориентированного AI

Это вторая заметка в серии о терминологии DHAIE. Первая была посвящена понятию Эмулякр. DHAIE — методология коэволюции человека и AI

Почему потребовался новый термин

Есть момент в работе с LLM, который сложно описать, но легко узнать. Ты формулируешь мысль на полуслове — и агент уже движется в нужном направлении, не требуя переформулировки. Контекст схвачен, темп совпадает, структура ответа соответствует тому, как ты сам думаешь об этой задаче. Взаимодействие исчезает как процесс — остаётся только мышление.

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

Для второго случая у нас не было точного слова.

В маркетинге есть «нативная реклама» — она про незаметность коммерческого сообщения. В UX есть «интуитивный интерфейс» — он про эргономику формы. В HCI есть affordance, контекстность, semantic communication. Но ни один из этих терминов не описывает то, что происходит именно в диалоге между субъектом и AI-агентом, когда взаимодействие перестаёт ощущаться как взаимодействие.

Мы вводим термин нативная коммуникация.

Определение

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

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

Якорная формула: нативная коммуникация — это когда не замечаешь границу между своим и чужим мышлением.

Три уровня нативности

Термин не бинарный. Нативность существует как спектр:

Уровень 1 — синтаксическая нативность Понятный язык, уместный регистр, правильная структура ответа. Это уровень UX и интерфейсного дизайна. Необходимое условие, но недостаточное.

Уровень 2 — когнитивная нативность Соответствие внутренней модели мышления субъекта: темп, логика, способ структурирования проблемы. Агент «думает» в той же системе координат, что и человек. Это уровень персонализации глубокого порядка — не форма, а структура.

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

Признак ненативной коммуникации

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

Чем это не является

Нативная коммуникация — это не то же самое, что:

• Персонализация — персонализация подстраивает форму сообщения. Нативная коммуникация согласует структуру мышления.

• Интуитивный интерфейс — интуитивность описывает эргономику продукта. Нативность описывает качество диалога между субъектами.

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

Зачем продукту исследования

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

Поговорили с Илоной, продуктовым дизайнером Project Ruler, о том, как команда использует исследования в работе и какие выводы из этого делает.

• конкурентный анализ

• глубинные интервью

• древовидное тестирование

• опросы

• юзабилити-тестирование

3️⃣ Как выглядел конкурентный анализ?

Мы использовали его как основу для гипотез. Смотрели не просто интерфейсы конкурентов, а конкретные сценарии: как пользователь выполняет задачу → куда идет → что видит.

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

4️⃣ Какую пользу получили от глубинных интервью?

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

Дополнительно прогоняли обезличенные данные через ChatGPT и находили то, что сами могли упустить.

5️⃣ Зачем понадобилось древовидное тестирование?

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

Мы смотрели, как пользователи проходят сценарии, где путаются и куда кликают по интуиции.

6️⃣ Что оказалось самым неожиданным?

Вот несколько ключевых мыслей:

• Уведомления раздражают — 8 из 10 пользователей их просто выключают и потом переживают, что что-то пропустили.

• Пользователям нужно меньше, чем кажется — основные сценарии: список или доска задач, карточка задачи и смена статуса.

• 8 из 10 пользователей не списывают трудозатраты — это стало поводом пересмотреть приоритеты и не перегружать продукт лишним функционалом.

• Даже простые действия неочевидны — например, многие не понимали, куда кликать, чтобы сменить пароль.

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

• Блок «Недавние» очень востребован — пользователи прямо просили его добавить.

7️⃣ Был момент, когда исследования помогли не продукту, а вашей команде?

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

8️⃣ Какой главный вывод из всего этого опыта?

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

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

Если до вас дошло обновление Firefox 149 и вы в ужасе от сломанного мультипоиска, то пока его ещё можно вернуть:

browser.search.widget.new → false

Самое печальное тут — стоящая за исчезновением история. Оказывается, команда юзабилистов из Мозиллы не смогла сделать мультипоиск аксессибильным («доступным», т.е. совместимым со скринридерами и управлением строго с клавиатуры). Решение было гениальным: нет мультипоиска — нет проблемы.

Основные ошибки при запуске UX-опросов

1. Неправильный контекст показа

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

2. Неправильная формулировка вопросов

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

3. Отсутствие сегментации, или «Ошибка средней температуры по больнице»

Средние показатели по вообще всем пользователям скрывают важные различия между сегментами. Например, 90% пользователей пользуются мобильной версией: оценка удобства 4.8. 10% пользователей — на десктопе: оценка 2.0. Средний балл: 4.42. Вывод «В целом всё ок» будет ошибочным, ведь данные говорят, что на десктопе точно есть заметные проблемы.

4. Слишком много вопросов

Бывает так, что опросы пытаются замерить всё сразу и состоят из 15–20 вопросов. Но дело в том, что длинные опросы утомляют пользователей, они бросают их на полпути или просто кликают любые варианты, чтобы закрыть форму. Оптимальное решение — 8–10 вопросов. Этого достаточно, чтобы оценить нужные параметры.

Подробнее о UX-исследованиях рассказываем на примере сайта «Халвы» в нашем блоге.

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

Попросили Костю, frontend-разработчика Naumen, рассказать, какие возможности DevTools он использует в работе и на что стоит обращать внимание.

1️⃣ Как открыть DevTools, если F12 не сработал

Самый простой способ — клавиша F12 для Windows/Linux. На macOS сочетание отличается, но открыть DevTools можно не только с клавиатуры.

Например, через контекстное меню — нажать правой кнопкой мыши на элемент страницы и выбрать «Исследовать элемент». DevTools откроются сразу на нужном месте.

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

2️⃣ Как работать с версткой во вкладке Элементы

Вкладка Элементы показывает DOM-дерево страницы — структуру документа, из которого собран интерфейс. 

Здесь можно:

• навести курсор на элемент и посмотреть, где он находится на странице

• быстро найти нужный блок через селектор

• посмотреть размеры, фон и отступы

А еще можно посмотреть доступность — как элементы переключаются через Tab.

3️⃣ Как находить итоговые стили 

Если у элемента много CSS-правил, я перехожу во вкладку Вычисленные.

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

4️⃣ Как проверять изменения без правок в коде

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

После обновления страницы все возвращается как было.

5️⃣ Как разбирать запросы во вкладке Сеть

Во вкладке Сеть видно, какие запросы отправляет страница и что приходит в ответ. А еще в этой вкладке есть не только список запросов, но и инструменты для фильтрации, поиска и просмотра этапов выполнения. Если нужно исключить что‑то из поиска, можно использовать инверсию или минус в строке фильтра.

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

6️⃣ Как подменять ответ бэка

В DevTools можно изменить ответ запроса и посмотреть, как на него отреагирует интерфейс.

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

7️⃣ Как проверять работу при медленном интернете

DevTools позволяют проверить, как работает интерфейс при плохом соединении. Во вкладке Сеть можно:

• выбрать готовые профили — 3G, 4G

• настроить собственную скорость сети

• протестировать поведение приложения в режиме офлайн

8️⃣ Как работать с локальными данными

Во вкладке Приложение можно посмотреть данные, которые браузер сохраняет на стороне пользователя:

1. Локальное хранилище — данные, которые сохраняются надолго и не исчезают после перезагрузки страницы.

2. Сессионное хранилище — данные, которые живут только пока открыта вкладка.

3. Файлы cookie — похожи на локальное хранилище, но у них есть срок жизни и дополнительные ограничения по источнику.

Все это можно просматривать, изменять и очищать. 

9️⃣ Как менять геолокацию и часовой пояс

DevTools позволяют изменить геолокацию и часовой пояс, не меняя настройки операционной системы.

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

🔟 Как записывать пользовательские сценарии

Инструмент Регистратор умеет записывать действия пользователя на странице — фиксируются шаги, например, клики и переходы по интерфейсу.

После записи сценарий можно воспроизвести, отредактировать, сохранить и отправить коллегам.

Годовалый ребёнок без присмотра решил понажимать на кнопки на коробочке и случайно удалил 32 ТБ данных на NAS‑сервере. Зачем вообще было производителю добавлять функцию «Удалить весь RAID» в меню «Быстрая настройка», родитель не понял.

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

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

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

В общем, пока потыкать в кнопки кажется быстрее и привычнее, особенно с учетом перспективы давать доступ к микрофону каждому встречному лендингу и вслух выяснять подробности)

Автоматизация без сборки с нуля: n8n теперь в Рег.облаке

В Рег.облаке появился готовый облачный образ n8n — open-source платформы для автоматизации процессов и интеграции сервисов.

n8n позволяет в визуальном интерфейсе связать API, CRM, базы данных, SaaS-сервисы и AI-инструменты без разработки с нуля. Образ разворачивается автоматически при создании сервера: Ubuntu 24.04 LTS, зависимости, SSL и домен уже настроены. После запуска можно сразу работать через web-интерфейс по HTTPS.

Сценарии использования — от обработки заявок и создания задач в CRM до CI/CD-триггеров, уведомлений о сбоях и AI-автоматизации с LLM и RAG. Можно подключить PostgreSQL и MySQL, в том числе через DBaaS.

Образ бесплатный — оплачиваются только ресурсы сервера по почасовой модели. Масштабирование доступно без переустановки.

Подробнее о доступных конфигурациях — на сайте Рег.облака.

Навеяно сегодняшней статьёй «История: как Microsoft шесть раз отказывалась от виджетов, но потом возвращала их».

Понятно, что Майкрософт просто хочет содрать с бедолаги, купившего (тем более, скачавшего) винды, 33 шкуры. И поэтому делает как бы виджеты, но они все должны вести туда, куда хочет Майкрософт. В Copilot, MSN и тому подобные места. Но давайте помечтаем, что могла бы сделать Майкрософт, если бы по-настоящему хотела сделать своим юзерам удобно.

1. Виджет это приложение, точка Приложения бывают хорошие, годные и злые, вредные. Любое приложение может сломать ваш компьютер, украсть данные и деньги. Ответственность делится так: автор приложения прилагает все усилия, чтобы приложение не делало ничего плохого. Юзер прилагает все усилия, чтобы не ставить подозрительные приложения хрен пойми откуда. Если вам кажется, что это наивно, вспомните, что именно эта схема действует на PC прямо сейчас. На Github'е @dartraiden выложил драйвер (даже не простое приложение!), который позволяет использовать недорогие карты для майнинга вместо видеокарт (за 10-15% от цены последних) и написал: «Если вы мне не доверяете, вот инструкция, как собрать драйвер самому». Спасибо, но что-то не хочется )). Собирать драйвер самому. Я доверяю автору проекта! А ещё — авторам редактора Notepad++, браузера Firefox, файлового менеджера FAR (который почти в каждой сессии просит права админа, потому что я захожу им в системные папки) и многим другим авторам приложений.

2. Любое приложение может зарегистрировать себя в качестве виджета. Такая технология у Майкрософт уже есть, и называется ActiveX. Она до сих прекрасно работает (в день, когда сломается ActiveX, я перейду на Линукс, потому что только старые приложения меня под виндой и держат).

   Суть технологии в том, что у вас есть файл .dll, который регистрируется стандартной командой regsvr32 в той папке, где лежит (при переносе в другую папку его надо перерегистрировать). Чтобы не заставлять пользователя вручную выполнять эту команду, её обычно выполняет инсталлятор. (Или просто сам вызывает регистрирующую функцию из этой .dll — ходил анекдот про авторов инсталлятора, которые «сделали ядро в новой версии на X килобайт меньше, включив в него облегчённую версию regsvr32», потому что не знали азов программирования под Windows).

   Этот файл просто создаёт маленькое окошко (говоря техническим языком, window handle), может быть написан на C или Rust, занимать килобайты и работать со скоростью света.

   Всё, что вам нужно — дополнительно записывать при регистрации идентификатор своего ActiveX-компонента в ветку реестра с виджетами.

   Чтобы было проще создавать виджеты на HTML/CSS/JS, Майкрософт мог бы добавить новый тип проекта в Visual Studio: HTML Widget. Он брал бы файлы .html/.css/.js, метаданные и запаковывал бы в ActiveX-компонент вместе с WebView2 (браузерным окном). И ваш виджет отображался бы при помощи Chromium, как это делает приложение (не виджет) Steam, но весил бы, в отличие от Steam, ровно столько, сколько весят картинки и текст.

   Разумеется, ничто не мешало бы создать виджет на C#, Qt, Delphi, на базе своей версии Chromium (как это делает Steam), на базе Gecko, на базе чего угодно.

3. Будучи хозяйкой бала, Windows предлагала бы юзеру зарегистрированные виджеты перетаскивать из палитры виджетов в следующие места: а) рабочий стол, б) панель задач, в) меню «Пуск». Разумеется, любой виджет обязан был бы имплементировать помимо стандартных интерфейсов ActiveX-компонента специальный интерфейс IAmWidget и через него рассказывать о своих требованиях. Так что виджет, которому нужна минимальная площадь 512x512 пикселей, можно было бы создать только на рабочем столе.

4. В каждом из этих мест виджет вписывался бы в стандартную сетку (на рабочем столе такая используется для выравнивания ярлыков, на панели задач — это квадратик ярлыка или прямоугольник приложения). Поместить другие элементы (ярлыки) в занятое место было бы нельзя.

Что такое Portainer и зачем он нужен для управления Docker

Ранее мы уже разбирали базовые команды Docker и повседневную работу с контейнерами. Следующий логичный шаг — упростить управление окружениями и сделать его наглядным.

Сегодня поговорим о Portainer — графическом интерфейсе для управления Docker, Kubernetes и Podman. В новой статье показали, какие задачи он решает, в каких сценариях действительно полезен и чем отличается от работы через командную строку. Отдельно разобрали ключевые возможности: управление контейнерами и образами, просмотр логов и статистики, работу с сетями и томами, запуск приложений через docker-compose и готовые шаблоны.

Пошаговая инструкция по установке Portainer через Docker-контейнер и подсказки, с каких разделов удобнее начать работу — в базе знаний Рег.облака.

Какие витрины в ecom-проектах хотят видеть зумеры и миллениалы

В среднем около 60% аудитории любого сайта в России — это пользователи десктопа. И только 38% заходят с мобильных устройств. Таковы данные Statcounter за 2025 год. Но всё меняется, когда мы говорим про доставку продуктов — в этом невероятно распространенном сценарии цифры совсем другие: 76% всех заказов приходятся на мобильные приложения. 

Мы изучили ряд исследований за 2024 и 2025 годы, чтобы разобраться, какими хотят видеть витрины в e-grocery-приложениях покупатели. В частности, нас интересовали проекты, в которых человек может посмотреть ассортимент магазина, но при этом не обязательно может купить товары. Каковы особенности этого узкого сегмента?

В контексте исследования мы сфокусировались на пользователях из регионов в возрасте от 20 до 35 лет. А в качестве источников использовали отчеты Nielsen (2024–2025), экспертные обзоры (Sostav, 2025), инсайты агентств о трендах (Convergent, 2025) и результаты опросов среди потребителей (Romir, ВЦИОМ, RBC Trends).

Вот какие тренды удалось выявить:

• «Карманная витрина». Почти все сценарии предполагают подход Mobile First и очень короткий пользовательский путь — не более 1–2 тапов до результата.

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

• Сценарные входы. Разделы вроде «Для пикника», «Быстро и недорого», а также фильтры по диетам («Без сахара», «Много белка» и т. п.).

• Эмоциональность. Бренды устанавливают личный контакт с покупателем через сторителлинг и ставку на местного производителя.

• Современная коммуникация. Живое общение с легкими формулировками: без официоза, но и без фамильярности — просто и дружелюбно.

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

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

Gemini представляет GenUI: Новый стандарт адаптивных интерфейсов

Google совершает очередной прорыв в области взаимодействия человека и ИИ, анонсируя Gemini GenUI (Generative User Interface). Это не просто обновление модели, а концептуальный сдвиг от статичных UI к интерфейсам, которые создаются «на лету» под конкретную задачу пользователя.

Что такое GenUI?

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

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

Ключевые возможности:

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

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

Интерактивность «из коробки»: Сгенерированные элементы не просто картинки. Это рабочие инструменты, с которыми можно взаимодействовать (двигать ползунки, сортировать данные, переключать режимы).

Адаптация под девайс: GenUI автоматически учитывает форм-фактор устройства, создавая удобный интерфейс как для десктопа, так и для мобильных платформ.

Почему это важно для разработчиков?

Для создателей приложений GenUI открывает путь к «бесформенному» дизайну. Вместо того чтобы прорисовывать тысячи сценариев (Edge Cases), разработчики могут предоставить Gemini набор высокоуровневых компонентов и правил, а модель сама решит, как лучше их скомпоновать для решения проблемы клиента.

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

Привет!
Sshto может паралельно выполнять команды на нескольких серверах. Но вывод потом получается вразнобой. Исправил это. Добавил сортировку вывода по имени сервера.

Творите, выдумывайте, пробуйте!)

Как подключить беспроводные наушники к... чему угодно.

В моём случае было желание подключить беспроводные наушники к телевизору, чтобы иметь возможность смотреть кино и не мешать (звуком) другим.

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

Итоги поисков завершились покупкой устройства, которое можно найти на AliExpress в поиске как "многофункциональный Bluetooth аудио приемник-передатчик".

В моём случае подключен через оптический аудио выход на телевизоре. В наличии также обычный 3.5мм jack, переходник jack на тюльпаны и coaxial. Работает и как приемник, и как передатчик.

Позволяет подключать 2 пары наушников.

...может кому то пригодится.

Егегей!

Не kui'ем единым как говорится, подкрутил немного sshto. Заменил 'scp -r' в командах download/upload на rsync. Теперь можно копировать информацию туда-сюда-обратно с докачкой)

Творите, выдумывайте, пробуйте!)