Разработка

Данных вокруг — океаны. А инструменты для работы за ними не поспевают. Мы как будто пытаемся переплыть эти океаны на дырявой шлюпке. Пробовали решить эту проблему по-разному, каждый подход был шагом вперед. Но ни один не дотянул до финиша.

Подход Инмона обещал «единый источник истины» в корпоративном хранилище — и обернулся бюрократией и запредельной стоимостью любого изменения. Подход Кимбалла дал скорость за счет удобных витрин, но ценой стали хаос, дублирование и информационные «силосы». Data Vault 2.0 — гибкий, аудируемый и мощный — без автоматизации превратился в проклятие для многих команд. И, наконец, Data Mesh: отличная организационная модель, которая дала командам автономию. Каждый домен сам владеет данными, сам отвечает за качество, сам развивается.

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

А что, если изменить непосредственно природу платформы данных? Сделать ее не пассивным набором инструментов, а системой, которая сама понимает данные, сама связывает домены, сама управляет качеством и развивается вместе с бизнесом?

Про концепцию такой платформы мы и хотим рассказать. Мы назвали ее AIDA (Adaptive Intelligence Data Architecture).

Команда Go for Devs подготовила перевод статьи о том, как GoLand помогает разработчикам вовремя находить и устранять утечки ресурсов. Файлы, соединения, HTTP-ответы, SQL-строки — всё это может незаметно накапливаться и ломать сервис под нагрузкой. В статье на реальных примерах показано, как одна пропущенная Close() приводит к сбоям, и почему встроенный анализ утечек становится незаменимым инструментом для стабильного продакшена.

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

Предыдущие статьи: "Геометрическая головоломка на выходные", "Электродинамика виртуальной Вселенной", "Механика виртуальной Вселенной", "Квантовая механика виртуальной Вселенной (часть I), (часть II)

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

Итак, приступим. Получится длинновато, но интересно.

СПЕЦИАЛЬНАЯ И ОБЩАЯ ТЕОРИИ ОТНОСИТЕЛЬНОСТИ

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

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

Нормативно‑справочная информация (НСИ) — это язык предприятий. Через наименования, коды и атрибуты описываются материалы, оборудование, комплектующие, инструменты — все, что используется в производстве, логистике, закупках, эксплуатации и ремонте. Именно НСИ обеспечивает согласованность ERP, MDM, BI и десятков других систем.

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

Меня зовут Дмитрий Романов, управляющий директор «Преферентум» (кластер SL Soft AI). В этой статье поделюсь, почему именно справочники материально‑технических ресурсов (МТР) превращаются в точку боли, почему «ручные чистки» и классические MDM‑подходы не помогают, и какие технологические решения действительно работают.

Для понимания меня, наверно нужно знать мой путь разработчика.

Закончен университет Имени Ярослава Мудрого в Великом Новгороде по специальности радиотехника.
Практика в КБ Планета, диплом считыватель R-FID меток. защита на 4, кажется никто не понял с моих слов сути устройства и каков был мой вклад.

первая работа:
2010 год сентябрь трудоустройство в НПК СПП в отдел систем видеорегистрации

мы делали видеорегистраторы полетной информации для Сухих и других крутых КБ

дальше меня после 9ти лет стажа и отсутствия перспектив из-за карьерных косяков закинуло в Diakont в 2020 году мы переехали с женой под рождение сына в Алмазово но это отдельная история...

Началась разработка средств доставки и диагностики бесконтактным методом ЭМА и другими...
Роботы были разные, все внутритрубной диагностики. Самый пик и интерес был робот для Малазийцев в проекте стоимостью в 300+ мультов русских. И даже некоторые из команды побывали в Куала-Лумпур, но не я...

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

Все мы любим быстрые программы и высокие показатели в бенчмарках. Когда гоняешь тесты производительности, так и тянет включить все оптимизации компилятора, чтобы выжать максимум. Но если вы имели дело с пакетами тестов SPEC (например, SPEC CPU), то, вероятно, замечали, результаты там делятся на две категории Base и Peak.

В тестах SPEC CPU есть концепция базового прогона (base run) и пикового (peak run). Это строго определенные режимы с разными правилами оптимизации. Base про честность и сопоставимость, Peak про максимальную производительность любой ценой (ну, почти любой).

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

Команда Python for Devs подготовила перевод обзора обновлений Django 6.0. В свежем релизе фреймворк усиливает совместимость между СУБД, упрощает работу с email, улучшает ORM, добавляет удобства в шаблонах и снижает риск «выгорания» первичных ключей.

Привет, Хаброжители!

Как только вы освоитесь с синтаксисом Rust, с его уникальным и мощным компилятором и начнете использовать его в реальных проектах, перед вами откроется совершенно новое измерение. Как правильно применять стандартные паттерны проектирования в приложениях на Rust? Как и когда следует использовать IntoIterator? Почему Rust-разработчики любят тип PhantomData? Ответы на эти и многие другие вопросы вы найдете в книге.

Что внутри:

- создание великолепных API;

- применение паттерна Строитель (Builder) и других классических паттернов проектирования;

- паттерны функционального программирования;

- антипаттерны Rust.

Привет! На связи Read IT Club — сообщество рецензентов и переводчиков ИТ-литературы. Мы делимся проверенными книгами, которые помогают не просто читать про ИТ, а по-настоящему понимать, как все устроено внутри. На этот раз — три издания о том, как проектировать надежные системы, создавать архитектуры, способные к изменениям, и выстраивать понятные API без избыточной сложности.

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

Недавно я наткнулась на статью «How Functional Programming Shaped Modern Frontend» и неожиданно поймала себя на мысли: мы уже настолько привыкли к функциональному программированию (ФП) в JavaScript, что забыли, как всё начиналось и почему многие идеи казались почти спасением. Чтобы лучше понять эволюцию, я решила посмотреть, что писали разработчики о ФП во фронтенде 10 лет назад, примерно в 2013-2016 годах.

Контраст получился довольно яркий: от искреннего восторга до постепенного прозрения.

Я решила поделиться своим анализом, основанным на современных наблюдениях и на тех статьях прошлого, где ФП воспринималось как путь к «правильному» фронтенду.

Сегодня мы делимся техрепортом, в котором разобран полный цикл создания нового семейства моделей Alice AI: базовая текстовая Alice AI LLM и специализированная LLM Search, мультимодальная Alice AI VLM и картиночная Alice AI ART. 

В части про Alice AI LLM расскажем, как сделали упор в Alignment на RL и Reward Modeling: мы минимизируем число разрозненных RL-стадий, собирая «общий RL». Вместо хрупкого «суперсигнала» используем аспектную формулировку качества и агрегируем её в целевую функцию, чтобы изменения критериев не требовали пересборки всей разметки. В главе про Alice AI LLM Search расскажем про многократные последовательные походы в Поиск с последующей фильтрацией/ранжированием источников. А также о том, как готовим ответы с использованием документов разной модальности (веб-документы, картинки, видео, гео).

Чтобы «вывезти» MoE-модель на сотни миллиардов параметров, мы целенаправленно сняли инфраструктурные ограничения обучения и инференса: в обучении используется YaFSDP (которую мы выложили в опенсорс) и собственная библиотека коллективных коммуникаций YCCL. В прод-инференсе мы работаем под SLA (avg TPOT ≤ 70 ms, p95 TTFT ≤ 2 s) и достигаем их комбинацией TP Attention/EP FFN, KV cache reuse, FP8 w8a8kv8 (в т. ч. сжатие KV cache ~3,05→~1,52 GB) и спекулятивного декодинга EAGLE‑3, что в сумме даёт 5.8× ускорение относительно BF16 (и 1,32× относительно лучшего open-source). Параллельно для Alice AI VLM нарастили в 1,5 раза объем претрейна, контекст до 32k и обновили OCR-датасет; VLM-генератор работает «из коробки», а для математики/геометрии выделен специализированный VLM‑решатель. В пайплайне Alice AI ART повышение релевантности к промпту начинается с диагностики смещений в датасете с помощью VLM и последующей адресной коррекции обнаруженных проблем.

Недавно все эти модели и решения легли в основу нашего нового ИИ-ассистента, и уже к ноябрю, согласно исследованию Mediascope, Алиса AI вышла на первое место по используемости среди россиян (14,3%), обойдя ранее доминировавший DeepSeek (9,4%). Кроме того, модель Alice AI LLM теперь доступна и для разработки собственных AI-решений на платформе Yandex AI Studio.

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

Привет, на связи Андрей Шведов, руководитель проектов ГРАН Груп!

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

Привет! Меня зовут Денис. В августе 2024 года я присоединился к компании ЮMoney в роли Fullstack-тестировщика с автоматизацией на Kotlin. Наша команда тестирует и фронтенд, и бэкенд. Автотесты в основном интеграционные — они охватывают интерфейс пользователя и внутренние процессы.

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

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

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

Меня зовут Александра Кузнецова, я бэкенд-разработчик в СберТехе, в команде Platform V Kintsugi — это графический инструмент для сопровождения, разработки и диагностики СУБД на основе PostgreSQL. Расскажу о том, как мы с коллегами интегрировали сбор данных о блокировках в наш мониторинг сессий. Решение работает в фоне и не нагружает БД. И дерево блокировок можно построить для любого момента в прошлом, даже через несколько дней после инцидента. Начнём.

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

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

Как Python помогает находить симметрии в поэтическом тексте. Простой код для поиска палиндромов (слов и фраз, читающихся одинаково в обе стороны) в творчестве Владимира Маяковского.

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

Привет, Хабр. Меня зовут Люба Вайгель. Я системный аналитик в СберЗдоровье — MedTech компании №1 в России. Я довольно давно работаю системным аналитиком: помимо медтеха, на моем счету опыт в финтехе, госсекторе. В этой статье я хочу поделиться материалами, которые в своё время помогли мне и могут быть полезны всем, кто только делает первые шаги в системном анализе.