Все потоки

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

Допустим, вы разработчик. Вам в Jira прилетает задача — сделать на странице пользователя кнопку «Дать денег». Вы делаете кнопку, она появляется на странице, нажимается, запрос уходит на бэк, бэк отвечает 200 OK. Технически все выполнено верно, но заказчик недоволен и вопрошает: «Я уже пять раз нажал на кнопку, почему деньги так и не пришли?».

И где-то между «в ТЗ было написано просто добавить кнопку» и «давайте срочно переделаем фичу до релиза, перепишем кнопку на тумблер и подрубим биллинг» возникает вопрос: кто виноват и почему именно аналитик?

Привет, Хабр. Я Арина, системный аналитик в Selectel. Я пишу требования к внутренним сервисам, ботам, интеграциям и прочим штукам, которые сначала кажутся маленькими, а потом обрастают ролями, статусами, ретраями, правами доступами и фразой «а это точно MVP?». 

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

На связи Андрей, руководитель направления безопасности облака в Selectel. Под катом расскажу, как настроить автоматический сбор данных о работающих Docker-контейнерах — образах, привилегиях и capabilities — и передать их в Wazuh для мониторинга и алертинга.

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

Ярким кейсом стал проект к премьере сериала «Кибердеревня». Мы сканировали гостей мероприятия, создавали их 3DGS‑аватары (3D Gaussian Splatting) и интегрировали в подготовленные Unity‑сцены. Этот пайплайн наглядно подсветил узкое место: при масштабировании производства скорость упирается не в креатив или алгоритмы реконструкции, а в возможности инфраструктуры рендеринга. Стало очевидно, что нам нужно решение, способное ускорить обработку в десятки раз.

Традиционно такие задачи решаются на локальных рабочих станциях или через специализированные внешние рендер‑фермы. Однако в Яндексе уже есть YTsaurus — распределённая система с GPU‑кластерами, поддержкой контейнеризации и отработанными механизмами планирования задач. Меня зовут Анатолий Томилов, я разработчик инфраструктуры VR и 3D‑реконструкции, в Фантехе. В статье я расскажу, почему идея использовать YTsaurus в качестве внутренней рендер‑фермы выглядела логичной, но её реализация оказалась нетривиальной.

В прошлой статье я рассказал, как получил Starter Kit для сбора материалов для секвенирования и отправил его в США. А также о встроенном в Nebula функционале для его анализа.

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

В 1994 году у меня появился первый компьютер: Intel i486 DX2-66 с 4 МБ ОЗУ и жёстким диском на 512 МБ. На нём были установлены IBM OS/2 и Microsoft Windows 3.11. Следующие четыре года я апгрейдил эту машину каждые несколько месяцев, добавляя больше ОЗУ (до 16 МБ), привод CD-ROM и карту SoundBlaster. Так я научился апгрейдить эту машину, устанавливать новое ПО, а потом и писать ПО на BASIC. Но я ни разу не касался процесса запуска и тонкостей MS-DOS.

В 2026 году, 32 года спустя, я узнал из скриншотов DDX3216, что в Behringer использовался настоящий процессор 386. В моём мозгу сразу же активировались какие-то нейроны и я начал размышлять о том, можно ли запускать на этом устройстве ПО или даже полнофункциональную операционную систему. Для этого мне нужно было разобраться, как запускается система x86, когда управление перехватывает DOS и что необходимо для попадания в оболочку.

Продакшен. 23:52. Пятница. Восстанавливаем схему БД. Нет, не случайная авария. Просто я удалил поле, потому что Кирилл был уверен, что оно не нужно и не затронет всех внешних потребителей нашего API. Эх, подумал я. Опять было нарушено первое правило леса. Сколько раз я уже на этом попадался, и вот опять. Неужели так сложно было проверить? Нет, не сложно. Но зачем? Кирилл на проекте уже 5 лет. Он реально гений, ещё и суперответственный, мне до него далеко. Он уж точно должен был знать, насколько сильно заафектит систему это изменение, он же сам писал этот модуль, черт побери! Ладно, это был последний раз. В следующий раз я точно не проигнорирую правила леса!

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

Продолжаем исторический обзор странных, но порой гениальный нательных технологий! Во второй части мы поговорим о более новых наработках, исторически близких к нам по времени.

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

Потому что, самое первое, с чем придётся иметь дело при попытках разобраться с этим вопросом, так это с тем, что в глаза бросается просто какое-то безумное количество плат расширения, какое-то безумное количество датчиков, подключаемых удобным и не совсем образом…. 

А двигатели? А двигатели в пролёте в прокруте (на первый взгляд)…:-B 

Ниже я рассмотрел пару решений, которые нашёл для себя в разные моменты времени в прошлом — возможно, они, в чём-то, будут полезны и для вас! ;-) 

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

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

Я несколько лет проработала в банке со строгим дресс-кодом ‒  костюм, каблуки, стандартный 8-часовой рабочий день. После смены профессии перешла на кроссовки и обувь на невысоком каблуке. 

Неприятные ощущения стали заметнее: икры постоянно тянуло, мышцы стали жесткими. 

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

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

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

Привет, Хабр! Меня зовут Кирилл Кулаков, я занимаюсь развитием MLOps-платформы в Uzum Fintech.

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

И тут коллеги начали задавать вопросы «Почему мы не разворачиваем каждый компонент последовательно, настраивая все досконально?». Для меня это звучало как: «Ты сделал неправильно, сейчас будем разбирать твою работу и от половины откажемся». 

Мы строим MLOps-платформу под широкий спектр AI-задач и по ходу работы постоянно сталкиваемся с архитектурными вызовами и альтернативными решениями. 

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

И потом я задумался, а на самом ли деле в разных компаниях и командах бывают настолько разные подходы к этому делу?

В статье предлагаю поисследовать эту тему вместе со мной.

Первым перевод на русский этой работы Роберта Зубрина, выдающегося американского аэрокосмического инженера, писателя, публициста и главного идеолога пилотируемой колонизации Марса, сделал ЖЖ-юзер keldoor в Живом Журнале, в сообществе Движение за Русский Космос’s Journal.

Однако, тот перевод был распределен по нескольким постам, журналы уже давно не ведутся, и с того времени (статья впервые опубликована в октябре 1995 года, перевод на русский сделан в 2012) появилось много новых данных о возможности и технологиях колонизации Марса. Поэтому я взял на себя смелость сделать новый перевод, снабдив его своими комментариями с точки зрения ситуации на середину 2026 года.

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

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

Одна из самых необычных историй такого рода — прохождение SpongeBob SquarePants: Battle for Bikini Bottom («Губка Боб: Битва за Бикини Боттом») на оригинальном Xbox. Группа энтузиастов обнаружила, что специальным образом запачканные диски способны вызывать контролируемые задержки чтения данных, которые открывают путь к пропускам частей уровней и заметной экономии времени.

Я Игорь Юрченко, backend-разработчик Сбера, в этой статье расскажу о нашем опыте автоматизации деплоя потоков Apache NiFi.

Apache NiFi — инструмент для управления потоками данных между автоматизированными системами (реализует подход ETL — extract, transform, load). Документация: https://nifi.apache.org/documentation/v1 (на момент написания статьи актуальна версия 2.x, но тут речь про 1.x). Физически это Java-приложение с графическим web-интерфейсом, в котором настраивается поток — в общем случае набор процессоров, которые получают на вход какие-то данные от предыдущего процессора или из внешней системы, обрабатывают их определённым образом и передают следующему процессору или во внешнюю систему. Процессор — готовый модуль с параметрами интеграции и/или обработки данных (например, строка подключения к БД, или схема трансформации данных). То есть ETL настраивается графически, без написания кода. NiFi обладает возможностями горизонтального масштабирования (ноды кластера имеют одинаковую копию настроек потока, обрабатывают данные параллельно), и расширения (пользователь может писать custom процессоры и использовать их в потоках наравне со штатными). Из коробки поддерживается множество внешних систем и протоколов передачи данных.

Apache NiFi Registry — инструмент версионирования потоков, Java-приложение с web-интерфейсом, интегрировано с NiFi. Что-то вроде системы контроля версий исходного кода, но проще. Пользователь может сохранять в Registry, просматривать и восстанавливать старые версии потока. Документация: https://nifi.apache.org/docs/nifi-registry-docs.

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

Наш экспертно-аналитический центр InfoWatch (ЭАЦ) выпустил большой отчёт о киберпреступности в области децентрализованных финансов. В этой статье мы поделимся некоторыми данными из него. Для затравки — лишь за неполные пять месяцев 2026 финансовые потери DeFi-протоколов превысили 770 миллионов долларов. Худший месяц для индустрии в этом плане — апрель, на который пришлось 606 похищенных миллионов.

Впрочем, обо всём по порядку.

Привет, Хабр!

На связи Андрей, продуктовый дизайнер Garage Eight. Июнь выдался насыщенным: тут нам и долгожданная WWDC26 с переработанной Siri, и победители Apple Design Awards, и свежий кит от Apple в фигме, и целая россыпь ребрендингов — от KFC и Schweppes до Циана. А еще посмотрим на навигацию для Сестрорецкого курорта, новый кейс Koto для Norton Museum of Art и, конечно, CONFIG26.

Сегодня в выпуске:

1. Apple WWDC26

2. Apple Design Awards 2026

3. iOS and iPadOS 27 in Figma

4. KFC Rebrand

5. Schweppes Rebrand

6. Ребрендинг Циан

7. Навигация для Сестрорецкого курорта

8. Norton Museum of Art

9. CONFIG26

Привет, Хабр! Меня зовут Антон Алексеев, я MLOps-инженер в Авито. 

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

Статья будет полезна не только тем, кто разрабатывает и использует платформы в больших компаниях, но и тем, кто работает на DevBox-машинах или небольших платформах для юнит-команд от 10 до 100 человек.

Привет, Хабр! Я Наталья, занимаюсь технологическим развитием агропромышленного комплекса в Россельхозбанке. Наша команда активно помогает инновационным компаниям расти, а агрохолдингам внедрять новые решения первыми. Кажется, тренд на эффективность и экологию дошёл и до удобрений, и теперь фермеры не готовы бесконтрольно вносить в землю обычные минеральные удобрения, повышающие урожайность. В этой статье хочу рассказать вам об одной из самых обсуждаемых тем в агро — удобрениях с программируемым высвобождением и биоудобрениях. Что это такое и с чем это едят?

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

Всех приветствую. В сотовой связи я, страшно подумать, уже третий десяток лет. Начинал еще в двухтысячных, в сетях 2G. Своими руками довелось обслуживать как CDMAone от Qualcomm, так и GSM от Alcatel, а позже строил третье поколение на Ericsson и четвертое на Huawei.

Конечно, я стараюсь следить за всеми новостями рынка сотовой связи. И просто не мог пройти мимо свежего исследования «Технология 5G: обзор российского и мирового рынка» от команды Research & Insights Центра стратегии цифровых продуктов МТС. Исследование крайне любопытное, и я бы хотел особенно отметить несколько деталей, которые мне там показались важными. Спойлер: как раньше, сети уже не окупятся — придется придумывать новые модели монетизации. А еще у нас сложности с оборудованием и частотами.