Недавно я посмотрел интересное видео YouTube‑канала «Physics for the Birds». Это видео посвящено матрицам, но для объяснения некоторых операций с матрицами автор использовал флаги. Он показал, как можно разбить флаги по осям, чтобы представить их в виде матриц и сэкономить место на диске. В конце этот пример был применён к реальным матрицам и вычислениям с ними.

Однако это видео дало мне вдохновение: часто флаги бывают очень простыми — несколько разноцветных полос, распространённые элементы наподобие звезды, полумесяца или креста. Если использовать какую‑нибудь схему кодирования, то удастся ли описать флаг Франции

в формате «три полосы: синяя, белая, красная», чтобы декодеру и рендереру достаточно было всего нескольких бит? Как может выглядеть такое кодирование?

Я решил создать нечто подобное.

Пятиклассник имеет полное право писать всероссийскую олимпиаду за 9 класс. За младший класс нельзя, за старший — сколько угодно, это прямо прописано в порядке проведения. Почти никто этим не пользуется.

А смысл начинается именно с девятого: региональный этап проводится только для 9-11 классов, и до него олимпиада не даёт ни льгот, ни денег. Отсюда наша стратегия — пять попыток вместо одной.

В статье: что нейросети сделали со школьным этапом, сколько регионы платят за победу (разброс почти в сто раз) и чем закончилась наша попытка набрать бесплатную группу — уведомили 400 человек, пришло ноль.

Среди тех, кто работает с мультиаккаунтингом, да и вообще использует прокси, существует такая страшилка: если приложение, через которое вы проксируете трафик (читай — антидетект-браузер), не поддерживает UDP (или базово не контролирует сетевые маршруты), ваш реальный IP-адрес может утечь — и тогда сама идея использования прокси теряет смысл. Вы хотите скрыть реальный IP-адрес, но из-за отсутствия поддержки UDP, наоборот, раскрываете его. 

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

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

WebGPU даёт прямой доступ к современным возможностям видеокарты: не только к рендерингу, но и к вычислениям общего назначения через compute shaders.

Но насколько далеко это можно довести в обычном браузере? Что произойдёт, если вычисления — это полноценная симуляция с десятками миллионов объектов? Разберемся в этой статье.

Публике не доступны внутренние модели фронтиер лабораторий. Я не очень верю про конспирологию в духе «у OpenAI в подвале сидит настоящий AGI, а наружу выдают обрезанный ChatGPT». Модель, которой пользуются её собственные исследователи, и модель, которую она продает вам через API, не обязаны быть одной и той же. Фронтиер лаба создает не одну нейросеть, а фабрику моделей: research-чекпоинты > экспериментальные модели > reward-модели > модели-учителя > модели для генерации синтетических данных > модели-evaluators > дистиллированные студенты > production-модели, и наружу попадает только последний элемент цепочки.

Зачем нужна дистилляция

Допустим, вы обучили чудовищно дорогую модель, которая хорошо рассуждает, пишет код и решает математику, но каждый запрос к ней стоит огромных вычислений. Для исследователя внутри компании это рабочий инструмент, и он того стоит, если на кону триллионные рынки. Для продукта со 100 млн пользователей масштабировать доступ к таким моделям выгодно, поэтому вместо того чтобы гонять её на каждом запросе, её делают учителем: она генерирует качественные ответы, решения, траектории ризонинга, синтетические данные, иногда сами распределения вероятностей, а на этом поведении обучается студент поменьше, которому не нужно воспроизводить учителя целиком, достаточно перенести нужные возможности. Это одна из форм дистилляции знаний, и практика настолько распространенная, что OpenAI прямо предоставляет разработчикам официальный Model Distillation workflow: брать ответы более сильной модели, например GPT-4o или o1-preview, и обучать на них модель дешевле. Формулировка самой OpenAI довольно точная: взять продвинутую модель и получить сопоставимое качество на конкретной задаче при существенно меньшей стоимости. Из этого следует довольно простая вещь: лучшая research-модель и лучшая production-модель оптимизируются по разным функциям, потому что research-модель максимизирует возможности, а production-модель приходится одновременно вытягивать по intelligence, latency, стоимости GPU, throughput, reliability и safety.

7 000 лайков, сотня плейлистов — и ни один сервис переноса не справился: у Яндекс Музыки нет API, а Spotify с 2025 года пускает в Extended quota только юрлица с 250k MAU и режет всех остальных суточной квотой. Разбираю, почему ломаются посредники, и показываю код: журнал прогресса с fsync, корректная обработка 429 без urllib3, матчинг треков по длительности вместо первого результата поиска, и три бага тихой потери данных, которые нашлись по дороге.

На одном из проектов (4Х историческая стратегия) появилась задача убрать часть логики в потоки, отдав им снапшот игрового состояния, чтобы пока основной поток считает свой тик, остальные (AI, поиск пути, UI и др) могли крутить свою логику, вроде "кто стоит в этой локации" и делать это без блокировок или риска увидеть половину чужой записи. Чтобы реализовать такую систему, надо придумать как получить обратный индекс полка по локации, причем сделать поиск дешевым для потоков, т.е. у потока должен быть свой снапшот состояния некоторой части игрового мира на момент старта апдейта (кадра, тика логики, дня, месяца и т.д)

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

std::vector<std::vector<unsigned int>> regiments(location_count);

Такая структура называется jagged array, массив массивов (зачем она и как с ней работать я показывал в книге Game++), или, если вам ближе академическая терминология, CSR (compressed sparse row) немного другая форма записи таких массивов, либо разреженные матрицы. И такие структуры довольно частое явление в играх, если у вас много локаций и вам надо узнать какой лут разложен в каждой локации, какие армии принадлежат каждой области, или какие монстры живут в локации, какие локации входят в область, какие области в регион, или почекать соседей локации на карте, adjacency region, на чем строится весь поиск путей и вся заливка областей в глобальных стратегих;

Я тут недавно пытался попасть на бесплатные курсы от Aston, но получил отказ с такой формулировкой.

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

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

Сегодня хочу попробовать пройти тестовое задание от клауд.ру. Оно охватывает тот самый стек для devops, linux, docker, git, kubernetes.

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

Тестовое задание состоит из 4 задач, начнем с первой.

Три атрибута, которые меняют результат компиляции. Один запускает метод раньше Main. Второй передаёт текст выражения вместо результата. Третий ускоряет stackalloc в 50 раз.

Все три описаны в документации и применяются внутри .NET. А в рабочем коде я их ни разу не видел.

Ранее в «Базовые модели надежности отказоустойчивого кластера» [2] были показаны теоретические подходы к построению моделей (непрерывная цепь Маркова, CTMC, Continuous‑Time Markov Chain) отказоустойчивого кластера (fault‑tolerant cluster).

Предлагаемый ниже практикум «Промпт‑инжиниринг для моделей надежности отказоустойчивого кластера» имеет цель популяризации практических расчетов надежности «подручными средствами» — через ИИ/AI (искусственный интеллект через AI‑чат, например, ChatGPT). Задача — формализовать промпты для формирования модели надежности и проведения по ней расчета стационарного коэффициента готовности, Кг.

Промпт (prompt) — запрос, текстовая инструкция, которую пользователь даёт нейросети.

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

Коэффициента готовности, напомним [1], что Кг — численно равен вероятности застать систему (в данном случае кластер) в одном из ее работоспособных состояний (сложение вероятностей каждого такого состояния). Предлагаемые подходы могут быть применены и для других сложных резервируемых структур с учетом ограничений СТМС: случайный процесс «без памяти» с дискретными состояниями и непрерывным временем, а также экспоненциальное распределение времён до отказа/восстановления, независимость отказов компонентов, см. [6], [7].

Специализированные для расчетов надёжности пакеты RAS (Reliability, Availability, and Serviceability) типа SHARPE, MEADEP, RAScad, CARMS, RAPTOR и тому подобное позволяют строить и рассчитывать сложные модели. Есть более простые системы (и бесплатные), которые можно использовать для рассмотренных ранее моделей надежности отказоустойчивого кластера, например, relind.ru. Можно использовать универсальные средства (не специализированные под расчет надёжности), например, для расчета марковских цепей, или расчеты делать непосредственно в Matlab и Mathcad и подобных. Однако все это требует достаточно высокий «порог входа» и имеет встроенные в конкретный soft‑продукт ограничения, как, по существу, так и по визуализации.

Почему миллионы начинающих пользователей боятся «нажать не туда», а видеоуроки не формируют практических навыков? Рассказываю, как создала интерактивный симулятор настольных ОС (Windows 10, 11 и Linux) с уроками и мини-играми и как это помогает безопасно осваивать компьютерную грамотность прямо со смартфона.

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

Минимальный объём данных, необходимых для работы

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

Сложность классов, а также разнообразие условий здесь играют важную роль. Если объект крупный и его легко различить, то нам потребуется одно покрытие. Если же объект маленький и находится на заднем плане, то в таком случае необходимо другое покрытие. Иногда приходится использовать сотни тысяч реальных размеченных кадров, и тогда, как правило, применяется аугментация. Чтобы проверить, готова ли модель к production, нужно прогнать её на тестовой выборке. Если данных много - это хорошо, но важно понимать, представлены ли в этих данных условия, в которых системе предстоит работать.

В статье мы рассмотрим специализированные PaaS-облака и особенности хостинга сайтов с SSR (рендерингом на стороне сервера) на React (Next.js, Remix, Astro), Vue (Nuxt.js, Quasar) и Angular. Рассмотрим сильные и слабые стороны сервисов. А также рассмотрим хостинг у VPS и Serverless-провайдеров. И приведём пример деплоя Node.js приложения с BullMQ и Redis.

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

Мало того, что ИИ позволяет обрабатывать и разбирать данные намного быстрее, чем это делалось вручную, так еще и современные BI системы уже позволяют внутри себя задавать вопросы к данным. Это я узнал не так давно, так как сам с этим не сталкивался еще, но это натолкнуло меня на размышления аналитического бытия.

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

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

Старый Intel Mac с Catalina ещё рано списывать. VLESS + Reality на нём работает — но ручная настройка через V2RayXS, JSON и системный proxy быстро превращается в рутину.

Я собрал AUTO Xray: компактный клиент для macOS Catalina, который берёт на себя разбор подписки, выбор узлов и настройку proxy. В статье — как из ручного решения вырос готовый инструмент и что пришлось сделать, чтобы он стабильно работал на iMac 2013 года.

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

Две наиболее опасные уязвимости имеют одинаковый рейтинг 9,2 балла по шкале CVSS. Проблема CVE-2026-67276 позволяет обойти аутентификацию по SSH в том случае, если атакующему известно имя пользователя и модуль публичного ключа. Ошибка CVE-2026-86060, в свою очередь, открывает возможность эскалации привилегий при использовании имени пользователя, содержащего некорректные символы.

Один и тот же JSON может привести систему к разным выводам. Валидатор пропустит поле, которое Go‑сервис спокойно прочитает, nil‑слайс превратится в неожиданный для клиента null, а ошибка в имени параметра останется незамеченной до самого продакшена.

Разбираем пять случаев, где поведение encoding/json в Go способно создать расхождение между компонентами системы, и смотрим, что меняет переход на encoding/json/v2.

🔥 Выходит Java 27!

• Compact Object Headers включаются по умолчанию. Метаданные каждого объекта становятся компактнее, что может уменьшить потребление heap примерно на 20% и снизить нагрузку на GC. Раньше для этого требовался флаг -XX:+UseCompactObjectHeaders.

• G1 становится сборщиком мусора по умолчанию во всех окружениях. Раньше JVM могла выбирать Serial GC на машинах и в контейнерах с небольшим количеством ресурсов. Поэтому после обновления стоит перепроверить память, паузы и CPU именно на маленьких инстансах.

• JFR начинает автоматически скрывать чувствительные данные. Пароли, токены, API-ключи и секреты в аргументах JVM, переменных окружения и системных свойствах больше не должны случайно попадать в запись Flight Recorder.

Этот пост для разработчиков, которые еще скептически относятся к кодингу с ИИ агентами и не используют его. Мир стремительно меняется и пора «проснуться» и поменять методику работы.

Ниже я расскажу личный опыт, чтобы было нагляднее.

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

Про HTTP/2 и HTTP/3 обычно пишут, что они ускоряют всё подряд. Я собрал стенд и померил сам: Caddy отдаёт одни и те же данные по всем трём протоколам, tc netem изображает шесть сетей — от дата-центра до края соты.

Результаты вышли неудобными. На десяти файлах HTTP/2 проигрывает старому HTTP/1.1. На одном крупном файле все три протокола показывают одинаковое время. В дата-центре новые протоколы отстают вчетверо. Выигрыш есть, но узкий и адресный.

Кейс по мотивам исследования SKILL.state: немного инженерии контекста, бенчмарков и графиков. Эксперименты с памятью coding-агентов в OpenCode и Codex и размышления о перспективах идеи.

Совет оптимизировать сайт под Claude смешивает два инструмента Anthropic: Claude и агента Claude Code. Profound снял 24 135 ответов на одних запросах, и у двух инструментов разошёлся почти каждый показатель. Я прошёл по документации путь запроса в обоих инструментах. Для владельца сайта из разбора следуют три вещи: какие боты Anthropic заходят на сайт, что закрыть в robots.txt и как проверить заходы по access-логу.

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

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

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

Путешествие редко состоит из одной операции: нужно совместить транспорт, даты, жилье, бюджет и иногда несколько пассажиров. Поэтому в начале лета мы открыли сервисы Туту для ИИ-агентов через Model Context Protocol (MCP), а в августе дали эту инфраструктуру участникам всероссийского хакатона.

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

Прототип к исследовательскому проекту «Планировщик инструкций для VLIW‑архитектур». Главный тезис:

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

Проще говоря, NEX CLI x Elbrus берет граф и модель e2k‑v6 и показывает: сколько насчитал жадный, сколько мог бы идеальный, и на какой операции и каком канале разница.

( https://ru.wikipedia.org/wiki/Скатерть_Улама https://en.wikipedia.org/wiki/Ulam_spiral )

немного её усовершенствовал в косынку и померял с разных сторон.

Но вот если рисовать точки не по квадрату? Скатерть Улама рисуется обходом точки в форме квадрата, а если обходить по треуголнику или пятиугольнику?

Сохранится тонкая структура линий?

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

Zed — новый редактор, написанный почти полностью на Rust. Своим слоганом он сразу заяляет то, для чего предназначен: Zed — Your last next editor.

Для меня Zed оказался нужен по следующим причинам: не устраивало наличие 5+ редакторов под разные языки программирования; требовалось иметь интеграцию с ИИ, чтобы тот мог вносить точечные изменения в код с автозапуском тестов и генерировать коммиты; хотелось найти что-то полегковеснее условных PyCharm, Intellij IDEA и им подобных; искал редактор, который без проблем сможет работать с WSL (в принципе, подходит большинство, но возвращаемся к вопросу о числе редакторов для разных проектов, так что нужно было “1 раз и чтобы навсегда”)

Я прошел через стадию отрицания при настройке (нет обычных кнопок Run и Debug, повсюду! Максимально непривычный интерфейс), но когда всё заработало, остался лишь один вопрос: почему я не слышал о Zed раньше?

Разбираю по полям usage, куда именно уходят токены. Оказывается, типов не два, а пять: обычный ввод, запись в кэш, чтение из кэша, вывод и reasoning. Последний виден не всегда, а платите вы за него по цене вывода: в одном из примеров из 234 токенов ответа 230 оказались рассуждениями, а полезного текста — одно слово.

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

Обычно под термином транслитерация подразумевают написание русскоязычного текста latinskimi bukvami. Однако это лишь одна сторона транслитерации — романизация.

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

Более того, существующие библиотеки часто не учитывают контекст и преобразовывают побуквенно. Результаты могут быть трудночитаемыми и нарушать всевозможные языковые правила. Например, 北海道 (Хоккайдо) становится Bei Hai Dao, بغداد (Багдад) становится bGdd, и так далее

Что, если нужна бесплатная библиотека, которая живёт на нашем сервере, и которая каждый раз выдаёт предсказуемые результаты? Что, если нужна правильная, удобочитаемая транслитерация? Что, если нужна не только романизация, но и транслитерация между самыми разнообразными письменностями и языками?

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

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

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

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

Разрабатывать собственный SSH-клиент за такой срок было бы интересным способом познакомиться с бессонницей, но плохим способом выполнить проект. Поэтому в 2024 году мы пошли по максимально прагматичному пути: взяли open source, сделали форк, адаптировали его под требования заказчика и примерно за 35 дней превратили задачу по импортозамещению в продукт, который можно было закупать.

Мы тогда совершенно не планировали следующие два года переписывать интерфейс, спорить с архитектурой Electron/NodeJS, самостоятельно переделывать RDP и VNC, добавлять клиент баз данных, десяток администраторских инструментов, а в итоге выбрасывать почти весь старый backend и переносить приложение на Rust. Но именно это и произошло.

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

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

С 1 сентября действуют новые Правила продажи товаров - ПП № 657. Прежние, ПП № 2463, утратили силу. Это не поправки, а новый документ: в начало добавили три пункта, и дальше вся нумерация сдвинулась на три.

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

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

Сервис принимал запрос, писал строку в базу, отвечал 201. Никто не пишет статей про такой код, потому что в нём нечего обсуждать.

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

Значит нужно асинхронно, через брокер. И почти всегда этим брокером оказывается Kafka.

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

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

Можно быстро сделать вывод: вот он, большой массив интереса к MODX. Остаётся посмотреть, что именно люди ищут, разбить запросы по темам и работать дальше.

Проблема обнаруживается после раскрытия списка.

Задача звучала просто: создать ВКС с jitsi и чатом нарисовать красивый интерфейс в корп стиле.

Решение — написать собственный тонкий веб‑клиент поверх matrix-js-sdk, который разговаривает с уже существующим Synapse‑сервером и Jitsi‑сервером, но выглядит и ведёт себя как часть внутреннего портала компании.

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

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

Ниже я разберу типичные UX‑ошибки на уровне сценария, примеры «как не надо» и «как лучше», а также простые метрики, по которым можно заметить проблему в своём боте.