Kurgan-Telecom Ru | Информационные технологии

История фронтенда хорошо показывает, что инструменты редко исчезают мгновенно. Чаще они проходят понятный цикл: сначала решают конкретную проблему и быстро набирают популярность, потом становятся привычной частью стека, а со временем уступают место следующему подходу. Примерно так развивается и CSS-in-JS. Когда он появился, это выглядело логичным шагом: стили рядом с компонентами, темы, токены и удобная интеграция с React. Со временем стало ясно, что у этой модели есть и ограничения — стили генерируются в рантайме, усложняется SSR, а в больших приложениях начинают накапливаться накладные расходы. Появились попытки сделать CSS-in-JS легче и быстрее. Одной из них стал Stitches: он сохранил удобный DX и заметно сократил рантайм. Но развитие проекта остановилось, а требования к фронтенду продолжают расти. Поэтому всё чаще обсуждают другой подход — перенос генерации стилей на этап сборки. В этой логике и появился StyleX.

Многие мои читатели называли меня циничным, когда я делал заявления наподобие «вам всегда нужно угождать своему менеджеру» или «большие технологические компании имеют право решать, над какими проектами вы работаете». Алекс Веннерберг привёл веские доводы того, что я циник, в своём посте Software Engineers Are Not Politicians («Разработчики — это не политики»). Вот некоторые выдержки из него:

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

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

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

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

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

С главной проблемой Vision-моделей я столкнулся в первый же день закрытых тестов. Я скормил Gemini свой тестовый снимок: крупный портрет собаки, положившей морду на лапы.

Модель уверенно выдала:

В поддержке было 148 инцидентов по одной проблеме, а в бэклоге разработки — всего 3 дефекта

Для разработки проблема выглядела редкой. Для поддержки — массовой

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

Представьте: менеджер по продажам уходит из компании. Уходит со скандалом, забрав часть клиентской базы. Через три месяца он всё ещё состоит в рабочем Telegram-чате отдела, читает обсуждения новых сделок, видит, кто из клиентов недоволен. Использует эту информацию или просто злорадствует — неважно. Важно то, что компания об этом не знает.

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

Первое, к чему стоит привыкнуть: творить каждый день. Хоть по пять минут, хоть по часу, но творить. Ждать вдохновения не следует. Вдохновение - это для мажоров с большим количеством свободного времени. Придётся выдавливать из себя, по-чеховски, раба по капле. Для этого своё хобби придётся носить с собой в сумке/рюкзаке/клатче/редикюле (нужное подчеркнуть).

Платные модели embedding не гарантируют качество на малоресурсных языках. На задаче кроссязыкового сопоставления EPG-заголовков (EN/RU/HY) бесплатная LaBSE набирает R@1 = 0,83, а OpenAI text-embedding-3-large -- 0,21. Протестировано 19 моделей, код и данные открыты.

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

К концу XIX века Сандуновские бани выглядели как классический спагетти-код. Ветхая застройка, никакой документации плюс «кусочная» система управления: разные зоны отданы разным арендаторам, каждый живёт своей логикой и оптимизирует только свой кусок. 

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

Но они выбрали второй вариант.  

Дальше вскрылась проблема нагрузки. Новые бани требовали 20000 вёдер воды в час, а городской водопровод падал по тайм-ауту и блокировал других пользователей. Чтобы уйти от зависимости от внешнего вендора, пришлось строить собственную инфраструктуру — прокладывать водовод от Бабьегорской плотины и бурить скважины. Внедрили тройное резервирование: городская вода + своя труба + скважины. Внутри здания реализовали переход на мазут и установку гигантского теплоаккумулятора (12 тонн чугуна). Топка ночью обеспечивала отдачу тепла днём.

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

Сами бани давали лишь 60% выручки, допмонетизация шла через сервисы аренды жилья, ресторанов и медицины. Главным вызовом стала балансировка продукта: нужно было сделать так, чтобы «бесплатные пользователи» (отделения за пять копеек) не распугали «премиум-подписчиков» (нумерные бани) и при этом инфраструктура выдержала общую нагрузку.  

Оправдан ли был такой риск? История показала, что да.

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

Вы открываете горячую функцию в профилировщике, видите миллионы вызовов, добавляете #[inline(always)]. Бинарник распухает, время сборки подскакивает, а производительность не меняется. Или ваще падает. Проблема не в атрибуте. Проблема в том, что #[inline] делает совсем не то, что подсказывает интуиция.

Раньше наш способ собрать данные из всех микросервисов в одно место (в витрину) напоминал копролит (только не древний, а наш собственный ИТ-артефакт). Он был сложный, медленный, постоянно ломался и требовал много ручной работы. Данные размазывались по куче баз данных. Чтобы сделать отчёт или отправить данные во внешнюю систему, надо было собирать их вместе. 

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

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

В чём были наши ошибки:

— Спроектировали сложную доменную модель для витрины, которая не соответствовала ни моделям в исходных сервисах, ни требованиям пользователей. Одна таблица из микросервиса могла раскладываться на 5 таблиц в витрине.

— Превращали данные из сервисов в эту модель — это был ад.

— Схема данных на фронте, в сервисе, в витрине и у потребителя была везде разная. Это постоянные баги из-за того, что кто-то ждёт ID, а ему приходит business_number.

— Чтобы отдать данные потребителю, приходилось делать кучу JOIN-ов. Это ломало SLA по производительности.

— Любое изменение в схеме БД микросервиса (добавил колонку) требовало сложной доработки витрины. Всё тесно связано и хрупко.

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

— Разработчики сервисов вместо одного события «Заказ сохранён» генерировали 20 событий на каждое изменение поля в UI. Это забивало очередь и создавало дикую нагрузку.

— Тестирование — тоже ад.

Для таких ситуаций есть понятный шаблон — трёхслойная архитектура с понятным дата-пайплайном.

В Wordle принято начинать с «хороших» слов – с частыми гласными и согласными. Однако анализ показывает, что менее очевидные варианты иногда дают больше информации. Возникает простой, но неудобный вопрос, можно ли доказать, что одно стартовое слово лучше другого. Краткий ответ – да. Я рассмотрел Wordle как задачу теории информации и количественно оценил каждый ход, используя Excel и официальный словарь игры. Эту статью я публикую в блоге ЛАНИТ, чтобы обсудить полученные результаты с техническим сообществом.

Привет, Хабр! Меня зовут Андрей Шукшов. Я пишу YNMT в Яндекс R&D — это движок инференса, на котором работают почти все наши большие языковые модели (LLM). Бо́льшую часть времени я пытаюсь понять, почему некоторые вещи работают медленно и как сделать так, чтобы у них это получалось чуточку быстрее.

Если вы запускали локальную LLM, то, возможно, тоже удивлялись: почему железо, способное рендерить фотореалистичные миры в реальном времени, работает в темпе печатной машинки? В своей статье я попробую хотя бы отчасти ответить на этот вопрос. Под микроскопом посмотрим на механизм Attention в режиме генерации (декодирования) и, вооружившись лучшими современными практиками ускорения на GPU, объединим всю математику в один эффективный kernel, который выжмет максимум производительности из имеющегося у нас железа.

Каждый раз, когда вы соединяете ноды в Blueprint и нажимаете Play, Unreal Engine запускает маленький процессор. У него свои инструкции, свой стек, своя защита от бесконечных циклов. Он написан в ~4000 строках C++ и живёт в одном файле. Через него проходит каждый Event Tick, каждый Event BeginPlay, каждый вызов Blueprint-функции.

Этот процессор - Blueprint VM (Virtual Machine). И сегодня мы разберём его по винтикам.

Эта статья продолжает цикл BPMN: Beyond the Basics, и сегодня мы поговорим о том, как BPMN управляет временем. Спойлер: весьма посредственно.

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

Привет всем, на связи снова Дарья Борисова, системный аналитик из ПСБ. Продолжаю развеивать мифы о REST API.  В первой статье цикла мы разобрали фундаментальные заблуждения о природе REST. Сегодня переходим к более прикладным, но не менее спорным вопросам — к мифам о реализации. Мы разберем тонкости работы с методами, поговорим о настоящем смысле «stateless» и выясним, правда ли, что новые технологии отправляют REST на покой. Погружаемся глубже.

В 1988 году бортовой компьютер с памятью 128 КБ посадил космический корабль в шторм. Сегодня ваш смартфон с многоядерным процессором заикается при скролле списка контактов. Мы привыкли думать, что данные невесомы, а JSON – это «просто текст». В этой статье мы препарируем один обычный fetch-запрос и посчитаем его реальную цену: в байтах, миллисекундах и скрытых архитектурных издержках. Разберемся, почему мы стали «поколением JSON» и как вернуть себе инженерную осознанность в эпоху избыточности.

Привет, Хабр! Меня зовут Владимир и это вторая часть материала о трассировке LLM-агентов. В первой части мы настроили инфраструктуру: подняли LangFuse, организовали трассировку и научились управлять промптами как кодом. Если вы ещё не читали — рекомендую начать с неё.

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

Предыстория. Ну как ИИ-стартап, в общем-то обычный SaaS но с ключевыми задачками в бизнес-процессах для LLM. 

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

На первом этапе архитектура ИИ-слоя выглядела очень просто и типично:

user request ⭢ RAG retrieval ⭢ LLM ⭢ answer

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

«Первый этап любого проекта — неправильно оценить сроки и бюджет проекта.»

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