Странные олдскульные технологии, которые так и не взлетели, часть 3

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

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

В статье - практический кейс создания корпоративного RAG-сервиса для поиска по внутренним регламентным и нормативным документам. Мы прошли путь от стандартного пайплайна на n8n и Qdrant до гибридной архитектуры с BM25, embeddings, RRF, reranking, структурным chunking и обработкой сложных таблиц и документов. Отдельно разбирается, почему обычная нарезка текста плохо работает на нормативных документах, как мы использовали Natasha, словари корпоративных терминов и мультимодальные модели, а также как построили систему измерения качества через Arize Phoenix и LLM-as-a-Judge. Показаны реальные результаты A/B-теста с реранкером по 9 метрикам с объяснением, почему в production-RAG важнее не «самая умная LLM», а качество подготовки документов, retrieval и воспроизводимая оценка изменений.

Представим ситуацию: у вас есть примитивное веб-приложение онлайн-редактора, которое уже набрало среднюю нагрузку под 100 RPS. И вы, как тимлид, дождались того самого дня, когда вся кропотливая работа над обновлением и бессонные ночи наконец завершились.
Настал момент релиза.
Вы радуетесь, что пользователи вашего приложения станут ещё счастливее. Они доверяют вашему сервису свои важные задачи, а вы расширите их возможности и сделаете их жизнь ещё немного лучше.
И вот момент.
3, 2, 1…
Релиз состоялся.
Вы рады. Ваши коллеги тоже рады. Всё прошло успешно.
Но спустя некоторое время к вам заходит начальство с максимально неприятным выражением лица...

тобы приложение работало одинаково хорошо у пользователей с разными моделями смартфонов, его желательно протестировать на таких же устройствах. Но что делать, если аудитория насчитывает десятки тысяч человек и у каждого разные смартфоны: у кого-то Samsung последней модели, флагманский Huawei, REALME, INFINIX или старенький Xiaomi, а кто-то из ностальгии купил iPhone 4? Разные модели, разные операционные системы… Как вариант, в таком случае можно использовать мобильную ферму — собрать свою или использовать готовое облачное решение.
Привет, Хабр! Я Саша, руководитель направления поддержки в Selectel. Мне стало интересно посчитать, сколько стоит собрать мобильную ферму своими руками и насколько это выгодно для среднего и крупного бизнеса в сравнении с облачным решением. Что получилось — рассказываю под катом.

Привет, Хабр! Какой стиль управления командой вы предпочитаете? Можно ли оставаться «мягким» и при этом сохранить продуктивность команды на 100%? И каких принципов придерживаться, чтобы выстроить эффективную коммуникацию без излишнего давления? Я Лена, эксперт Directum Projects. В этой статье расскажу, когда не обойтись без кнута и какой пряник «испечь», чтобы все остались довольны.

Если вы любите образовательный контент также, как его люблю я, вы обязательно оцените мои революционные решения в управлении видеопотоком, которые я упаковал в собственный браузер для мобильных устройств.
Когда пытаешься осмыслить Семихатова переходящего с кораблей бороздящих просторы космоса на эрмитовы операторы в гильбертовом пространстве. Когда вглядываешься в расположение пальцев каждого слайда “Dark Blues Music To Escape To...” в скользящей технике Justin Johnson. Когда разучиваешь каждое движение праздничного танца пятницы в жизнектвеождпющем стейтменте — выжил. Ну или просто ресечишь техники массажа и упражнений в зале…

Один settings.py удобен только в начале проекта. Когда появляются несколько окружений, Celery, Redis, внешние API и объектное хранилище, настройки быстро превращаются в источник скрытых ошибок. Разбираю практическую структуру django-split-settings: без магии, неявных переключений и случайного запуска с production-конфигурацией.

Из новостей: Unity 6.6, Blizzard начала тизерить новости по StarCraft, Хидетака Миядзаки не фут-фетишист (но это не точно), ArtStation блокирует ИИ-краулеры, Double Fine прогревает на Kickstarter.
Из интересностей: почему искусство должно оставаться за человеком, в геймдев с нуля после 40, зачем выбирать LibGDX для разработки игр на Java в 2026 году, 13 лет в Unity.

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

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

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

Приветствуем, Хабр. Совсем недавно мы делали обзор о ближайших наших книгах, в которых рассматриваются большие языковые модели (LLM) и искусственный интеллект. В частности, там упоминалась книга Камиля Гадеева @Kamil_GRо промпт-инжиниринге и работе с LLM. Камиль Гадеев ведёт на Хабре превосходный научно-философский блог, на основе некоторых статей из которого и сформировалась эта книга. Камиль Гадеев смог рассмотреть внутреннее устройство промптов, галлюцинации искусственного интеллекта и сформулировать приёмы, позволяющие эффективно получать от машины информативные и достоверные ответы. Книгу "Промт-инжиниринг и работа с LLM. Как говорить с искусственным интеллектом" можно купить на сайте издательства. Под катом предлагаем рассказ Камиля Гадеева о том, как устроена эта книга, как с ней работать, и для кого она предназначена.

Привет, Хаброжители! Мы перевели для Вас свежую статью Мартина Клеппманна о том, почему формальная верификация благодаря ИИ вот-вот перестанет быть уделом единиц и станет обычной практикой.
Сейчас много говорят о влиянии ИИ на разработку, но есть ракурс, который почти не рассматривают. Клеппманн считает, что ИИ превратит формальную верификацию, десятилетиями жившую на периферии, в программно-инженерный мейнстрим.
Предположим, что вы участвуете в игровом шоу, известном тем, что все его участники рассуждают совершенно логично. Вы и другой участник стремитесь согласовать свои действия, чтобы выиграть главный приз. А именно, вам нужно действовать сообща так, чтобы одновременно назвать один и тот же цвет.
Вас и другого участника по отдельности проводят в ваши личные комнаты, в каждой из которых есть стол и оборудование для обмена сообщениями. Игра проходит по раундам, в каждом из которых вы действуете одновременно. В каждом раунде каждый из вас независимо выбирает одно из двух действий: либо завершить игру и официально назвать свой цвет, либо отправить сообщение другому участнику. Сообщение может быть практически сколь угодно длинным, при условии, что его можно набрать за разумное время. Участники изолированы друг от друга, и во время раунда ни один из них не знает, какое действие другой выберет в этом раунде, пока оно не будет совершено. Сообщения доставляются сразу после завершения раунда. У каждого участника есть лишь одна возможность завершить игру и назвать цвет - поэтому важно не ошибиться!
Если в каком-либо раунде оба участника завершают игру и называют в точности один и тот же цвет, то оба выигрывают главный приз. Но если названные цвета различаются или если только один участник решает в этом раунде завершить игру и назвать цвет, то оба проигрывают, и игра заканчивается.
Скоро начнется раунд 1. Что вы будете делать?

История парадокса Гиббса неплохо изложена в книге С. Д. Хайтуна 'История парадокса Гиббса' и обзоре Оливье Дарриголя 'Парадокс Гиббса: ранняя история и пути решения'. Меня удивило, что как в книге Хайтуна, так и обзоре Дарриголя выражались сомнения в возможности разрешения парадокса Гиббса в классической термодинамике. В конце 19-го - начала 20-го века понятие энтропии в химии приживалось с трудом, и можно понять вопросы и колебания, возникающие в те времена у ученых в связи с энтропией смешения. С другой стороны, в настоящее время химическая термодинамика является сложившейся наукой, и я бы сказал, что парадокс заключается в том, что люди по-прежнему находят парадокс в энтропии смешения в классической термодинамике.

Искусственный интеллект проник уже почти во все сферы деятельности человека, но вместе с этим в мире появляется всё больше запретов на его использование, в частности, когда речь идёт о молодом поколении. Многие страны начинают ограничивать использование ИИ в том или ином виде для детей и школьников до определённого возраста.
Привет, Хабр. Предлагаем вам почитать и обсудить наше интервью с Вячеславом Васильевым, Senior Data Scientist в Управлении базовых моделей Kandinsky, блок «Развитие генеративного ИИ». Вячеслав — опытный исследователь в области Gen AI и один из создателей нескольких поколений нейросетей Kandinsky. Его совместные с коллегами научные статьи регулярно попадают на ведущие международные конференции по машинному обучению.
Вячеслав рассказал, как написать хорошую научную статью и почему важно лично представлять свои работы на больших международных конференциях, поделился мнением о генеративных сетях и актуальных проблемах индустрии ИИ, а также раскрылся с неожиданной для исследователя стороны.

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

Не так давно мы решили запустить свой собственный MCP-сервер для GoCD. Ну а что, у всех есть MCP, а у нас не было. И у GoCD не было такого, который бы подошел нам. Мы уже больше месяца им активно пользуемся. Сам проект тоже живет и развивается — его версия за это время выросла до 1.2.0: https://github.com/Ivinco/gocd-mcp
После того как прошел первый восторг от осознания важности собственного вклада в мир open source, перед нами встал еще один вопрос. Да, у нас есть MCP. Но зачем нам MCP. И на этот вопрос, если хорошо подумать, не так уж и просто ответить.

Это моя вторая статья. После первой я посмотрел на статистику и понял простую вещь: начинать издалека и пытаться рассказать сразу обо всём — плохая идея. Поэтому сейчас будет одна задача, один странный баг и одна строка, которая его исправила.
Я добавлял в админку сайта портфолио. У проекта есть заголовок, описание и несколько изображений. После загрузки файла API должен вернуть обновлённый проект, чтобы интерфейс сразу показал новую картинку.
Файл сохранялся. Строка появлялась в базе. Повторный GET тоже находил изображение. Но ответ самого запроса загрузки выглядел так: