Technotext

«ИИ-агент» — финалист слова 2025 года по версии Грамоты.ру. На vc.ru и Хабре выходят по несколько статей в день с десятками тысяч просмотров. Gartner прогнозирует, что к 2028 году 80% корпоративных процессов будут автоматизированы с помощью ИИ-агентов. Крупнейшие компании мира включили «внедрение агентов» в планы на 2026 год. Бюджеты выделены, тендеры объявлены, команды сформированы. А теперь открываю Яндекс Вордстат и проверяю, ищет ли кто-нибудь этих агентов на самом деле.

Речь пойдёт о реализации реакции веб-интерфейса на наклон устройства, смещение бликов, теней, для придания ему таким образом интерактивности и объёма.

Device Orientation API существует уже давно. Мобильные устройства с гироскопом стали пожалуй основным окном для приложений и сайтов. Всевозможные эффекты "блеска" / градиентов в дизайне встречаются регулярно, тренд на эмоциональный дизайн и кажется пора это всё объединить!
И ведь Apple выкатили эту фишку в liquid glass! Но... лично по моему мнению, как-то не "дожали" или она померкла на фоне других нововведений... а жаль, я считаю реакцию ui на положение устройства гораздо более перспективной темой чем новая прозрачность с крутой физикой преломлений которую тут же все побежали повторять. В отличии от преломления фона, адекватная реакция на наклон устройства это не графон ради графона, а микро‑взаимодействие дающее ощущение контроля, отзывчивости, даже "живости" интерфейса. Ведь даже если пользователь не тапает по экрану - он очень даже взаимодействует с интерфейсом(смотрит/читает) и слегка "покачивает" телефон в руке, и UI на эти микродвижения уже чуть-чуть отвечает, маленькая физика (свет/тень/глубина), как будто элементы не нарисованы, а существуют как объекты... Ну это моё субъективное восприятие... тут есть похожие мысли про роль микровзаимодействий и баланс эмоций.
Знаю что некоторых людей "лишние" анимации наоборот нервируют, или даже "укачивают", чтож... прекрасно что для них есть опция reduce-motion, для меня такой замечательной обратной опции "сделать красиво" нет )))
Если всё ещё не понятно о чём я, можете глянуть это видео:

Представьте: вы гуляете по ночному парку с прекрасной девушкой после романтического вечера в ресторане. Тут перед вами открывается полянка, а над ней — летнее небо, полное звезд. Вы невзначай говорите: “о, смотри, сейчас Плеяды особенно яркие”! Показываете на небо, девушка прижимается к вам поближе, чтобы разглядеть, куда же вы показываете, и…Ну дальше все в ваших руках. А вот не знали бы, где Плеяды — и все, так и пошли бы грустно по домам. В этом посте расскажу, как научиться различать созвездия, что можно наблюдать невооруженным взглядом, как выбрать первые девайсы и всякое такое.

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

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

Привет, Хабр! Меня зовут Кияшева Екатерина, я занимаюсь качеством. Сегодня хочу поделиться опытом о метриках качества системно. Предложить примеры, провести взаимосвязи: Метрики ⇔ Процессы ⇔ Области управления. Эта статья для руководителей, кто и сам ищет решения, чтобы метрики: 

• не ломали команду,

• не показывали погоду, 

• работали в пользу продукта и бизнеса. 

Ограничения и рекомендации:

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

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

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

Я выбрала метрики завершенного цикла (рефлексии): они строятся на основе операционных и служат фундаментом для стратегических. Это позволило рассмотреть QA со всех ракурсов и не закопаться в деталях. Определение типов метрик приведено в разделе «О метриках».

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

Всем привет! Мы создаем простую, быструю и компактную диффузионную модель, которую можно обучать и запускать на обычных видеокартах, сохранив при этом высокое качество. Simple Diffusion (sdxs-1b) — это первый результат наших опытов, мы публикуем её как альфа‑версию под лицензией Apache-2.0 вместе с открытым кодом подготовки данных и обучения. https://huggingface.co/AiArtLab/sdxs-1b

TLDR; На обучение SDXL потребовалось ~6 млн долларов. Z‑Image говорят обучили всего за 600к. У нас была RTX-4080 и два чемодана  желание сделать небольшой прототип быстрой и дешевой модели на imagenet. В процессе мы немного увлеклись. Вероятно удалось создать модель примерно в сотни раз дешевле/быстрее относительно быстро обучаемой SDXL с генерацией близко к реальному времени в высоком разрешении, и без характерных проблем в анатомии, но качество пока в целом ниже (но надеемся будет выше).

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

В статье покажу этапы, очень похожие на стадии принятия Кюблер-Росс (отрицание, гнев, торг, депрессия и принятие), которые я наблюдал у разработчиков в процессе нашего с ними общения. Мы пройдём путь от отрицания наличия проблемы, через благодарность за информирование (о проблеме) до негодования в адрес MITRE (и мой адрес, не стесняясь выражений). Помимо оформления CVE, за эту уязвимость я попал в Топ-10 Pentest Award 2025 (№9 Out Of Scope).

Дисклеймер: в статье приведены скриншоты из моих личных переписок с разработчиками. Публикация таких переписок одной из сторон не требует согласия другой (согласно законодательства РФ).

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

Меня зовут Сергей Кукуруз, я руковожу ML‑проектами в центре технологий для общества Yandex Cloud. В этой статье расскажу, как мы совместно со студентами Школы анализа данных (ШАД), а также с движением добровольцев «СтопБорщевик» автоматизировали этот процесс с помощью машинного обучения. Мы подробно разберём технический пайплайн: от нормализации GeoTIFF‑файлов и извлечения признаков (индекс CIVE) до обучения модели в CatBoost.

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

История ремонта этой пишущей машинки тянется уже 8 лет! Шутка что ли, это Самый Первый Артефакт моего YouTube-канала!

Robotron S6130 — многофункциональная пишущая машинка формата A2 на базе процессора Z80, с функцией запоминания набранных текстов во встроенной оперативной памяти, с записью и воспроизведением на магнитофон, а также возможностью приема и передачи текстов с ЭВМ по последовательному порту!

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

Всем привет, меня зовут Макс. Я TeamLead Backend, автор YouTube-канала PyLounge, бывший преподаватель классического университета и просто человек, который много общается с другими людьми. Нам всем в современном мире так или иначе необходимо общаться с людьми. Даже если вы программист, вы не просто пишете код, вы постоянно с кем-то коммуницируете, причём много. И многие люди с большим трудом будут добиваться успеха в карьере, в отношениях, если не научатся одной простой вещи – говорить ртом.

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

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

17 июля я сдал анализы крови в компании Гемотест. Спустя полтора дня мне пришёл email с результатами на адрес, который я указал перед сдачей. К счастью, с анализами было всё хорошо: у меня нет ВИЧ, гепатита B, гепатита C, сифилиса, ура! PDF с анализами было заверено приложенной электронной подписью с инструкцией по проверке. Было внутри даже такое:

УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: Это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.

А потом ещё и то же самое на английском. Ну кайф. Вроде всё хорошо, можно не волноваться. Но одна вещь всё-таки лишила меня покоя.

Всем привет! Меня зовут Артём Сидоров. Я ведущий разработчик из ИТ-команды «Северстали». Сегодня хочу рассказать, как мы реализовали «Универсальный сервис по сбору телеметрии с CAN-шин на технике».

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

Когда вы прокладываете маршрут в горах в 2ГИС или рассматриваете вид на дом в 3D, вы вряд ли задумываетесь, что под капотом карты происходит серьёзная вычислительная работа. За каждой формой рельефа — тысячи треугольников, интерполяции и алгоритмы, которые превращают цифровую модель местности в реалистичную поверхность.

Впервые рельеф мы добавили в веб‑версию 2ГИС в 2022 году. С тех пор мы не останавливались на достигнутом: доработали алгоритмы, улучшили качество исходных данных, научили дороги и здания влиять на поверхность. А недавно мы выкатили рельеф и в мобильное приложение.

В этой статье расскажем, как мы пересмотрели подход к данным, зачем нам понадобился нерегулярный меш, что общего у RTIN с Делоне и почему даже рельеф иногда приходится «чинить».

Меня зовут Юрий Морозов, я главный архитектор компании «Гарда».

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

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

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

Хороших технических статей про Go было написано немало, и эта — не одна из них. Эта статья — графомания о моём субъективном и эмоциональном опыте перехода со Scala на Go.

^{Руководитель: Хочешь техлидить новый проект?}

^{Я: Да, конечно. А что за проект?}

^{Руководитель: Распределённые бэкенды на Go.}

^{Я: Go? Но я же скалист-функциональщик…}

^{Чуть позже}

^{Коллега: Слышал, что ты будешь техлидить другой проект — вы там тоже Scala завозить будете?}

^{Я: Нет, будем писать на Go.}

^{Коллега: Ты что, бросаешь Scala и нашу тусовку?!}

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

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

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

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

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

Однажды на онлайн-барахолке мне на глаза попался так называемый «дисплей покупателя» — алфавитно-цифровое табло, которое стоит на кассе и показывает текущий товар в чеке и сумму покупки. Это был старый экземпляр, с красивым зелёным VFD-дисплеем, да и стоил он копейки. Пройти мимо я не смог. Ну а потом, как и многие обладатели очумелых ручек до меня, захотел сделать какую-нибудь самоделку на его основе.

Конечно, можно было бы засунуть туда ESP-шку и сделать погодную станцию, часы, или транслировать уведомления о новых сообщениях в ТГ и WhatsApp. Это всё, безусловно, по-своему интересно. Но самым большим моим увлечением являются игры. И поэтому я решил сделать из табло электронную игру. Как говорится, «но зачем?» Ответа у меня нет. Но есть рассказ, что и как я сделал.

Всем привет, меня зовут Юрий Пузыня, я занимаюсь развитием платформы документации Diplodoc в Yandex Infrastructure, которую мы пару лет назад выложили в опенсорс. И сегодня я расскажу лёгкую историю невероятного везения в опенсорсе.

Мой первый коммит как контрибьютора в опенсорс‑проект был смёржен спустя два с половиной года мной же в качестве мейнтейнера этого проекта. И в чём тут история успеха — спросите вы. Но давайте я расскажу всё по порядку.