На днях по AI пабликам завирусился робот 1X Neo, который заявляется разработчиками как человекоподобный робот для помощи по дому. Мне стало жутко интересно покопаться в устройстве и начинке этого робота, потому что скрещивание VLM и механизмов может привести к огромному прорыву в индустрии и новым большим изменениям.
Поговорим про устройство робота, железо и софт на борту, прикладные задачи и ближайшее будущее.
Ночь. Курсор мигает, как маяк в тумане. Логи шепчут о том, что в коде — своя улица, свои правила и кодекс общения. Объекты — не безмолвные элементы системы. У каждого свой характер, привычки и слабости. Один щёлчок и поведение меняется: кто-то отдаёт приказы, кто-то внимательно прислушивается, а кто-то терпеливо ждёт сигнала. Эта статья — карта такого города.
Всем привет! Меня зовут Бромбин Андрей и сегодня разберёмся в поведенческих паттернах ООП. Короткие определения, идеи через ясные метафоры и рабочие примеры на Java. Всё это для того, чтобы система не трещала по швам, а решения были ясными, предсказуемыми и поддерживаемыми.
События разворачивались в нескольких реальностях. В первой заказ не пришёл. Во второй - произошло несколько списаний средств. В третьей система упала посередине процесса, оставив данные в не консистентном состоянии.
А четвертая оказалось самой интересной. Где даже с неполадками сети и падениями сервиса был сделан лишь один заказ. И произведена одна оплата. Благодаря чему пришла желаемая теплая пицца. Которую хотел наш дорогой покупатель.
Погрузимся в проблематику оформления заказа, консистентности данных. И схлопнем все реальности в нужную с помощью Outbox Pattern.
Mobile System Design — один из ключевых навыков мобильного инженера.
Именно он часто определяет уровень зрелости: в реальной работе, на собеседованиях и в матрицах компетенций компаний.
Но вокруг этой темы полно разночтений и разных трактовок — отсюда споры, путаница и хаос.
В этой статье я систематизирую Mobile System Design как дисциплину: покажу, какие навыки действительно важны и как они проверяются. Это не личное мнение, а выжимка из опыта инженеров, требований собеседований, литературы и практики команд.
Эта статья была написана мной и опубликована в отраслевом научном журнале более четверти века назад, когда я работал в головном НИИ железнодорожной отрасли (ВНИИЖТ МПС) в должности заместителя заведующего лабораторией и занимался вопросами научно-методического обеспечения задач управления производственными процессами путевого хозяйства железных дорог России, автоматизацией функций и применением информационных технологий для нужд путевого хозяйства.
В статье рассматриваются вопросы управления техническим состоянием объектов путевого хозяйства с применением информационных технологий.
Привет, коллеги. Меня зовут Александр Попов, я представляю группу продуктовых дизайнеров и UX-исследователей группы компаний «Цифра».
Сегодня поговорим о теме, которая заставляет многих из нас чесать в затылке, — как измерить удовлетворенность пользователей в суровом мире enterprise-продуктов? В том самом, где пользователи ваш продукт не выбирают, а получают его «в нагрузку» к своей работе. Это как со школьной формой: носить надо, нравится или нет — вопрос десятый. Но если форма жмет, трет и расползается по швам, учеба превращается в пытку.
LLM умеют многое: генерировать тексты, анализировать документы, писать код. Но на практике их работа часто непредсказуема — сегодня модель даёт точный ответ, а завтра на тех же данных ошибается, пропускает ключевые шаги или придумывает факты.
Для AI-инженеров это системная проблема. Возьмём автоматизацию документооборота: нужно классифицировать договоры, извлекать реквизиты, проверять стандарты. Но модель работает как лотерея — результат не поддаётся логике или меняется при повторном запуске с одинаковыми данными. Как встроить такой результат в бизнес-процесс?
Для решения этой задачи появился подход Schema-Guided Reasoning (SGR). Его активно продвигает Ринат Абдуллин в материалах по работе с LLM. Идея проста и эффективна: заставить модель мыслить не хаотично, а внутри заданной схемы. Это не панацея, но SGR серьёзно снижает количество ошибок, делает процесс прозрачнее, а также позволяет тестировать отдельные компоненты рассуждений.
Однажды в одной компании решили: «Сделаем процессы в ITSM-системе точь-в-точь такими, как в жизни! Только ни в коем случае не продумаем все как следует…» После этого их сервис деск задушили баги, а клиенты похоронили саппорт своими заявками. Бу!
Привет, Хабр, с вами команда ITSM 365. Мы собрали для вас рекомендации, следуя которым вы гарантированно превратите вашу сервисную систему в источник ужаса для бизнеса и пользователей. Пойдемте читать и бояться вместе.
Митапы про микросервисы, хайп вокруг новых фреймворков, кеш и перекрашенные кнопки — привычная рутина современного айтишника…
Но мы-то знаем: есть и другое IT. Там пишут код, от которого зависят тонны синтетических материалов или выплавленной стали, скорость производственной линии и бесперебойная работа энергосети. Это мир Heavy Digital. И он становится всё больше.
Мы захотели выяснить, почему всё больше IT-специалистов осознанно выбрали работу на заводах и в промышленных гигантах. Что за мотивы ими движут, какие задачи вызывают настоящий драйв и чувство сопричастности к чему-то большому? Мы собрали эти и другие вопросы и приглашаем всех причастных к IT в промышленности ответить на них в ветке «Я эксперт в Heavy Digital».
А ещё мы хотим узнать мнение тех, кто слышал о Heavy Digital и только стоит на пороге выбора. Чтобы понять ваши ожидания и страхи, мы создали ветку опроса «Я пока не в Heavy Digital».
Спойлер: в конце ветки для экспертов у вас будет возможность рассказать о самом запоминающемся профессиональном вызове. Авторы 10 лучших историй смогут получить ачивку «Герой Heavy Digital» в своем профиле на Хабре.
Готовы? Тогда выбирайте свою ветку — и вперёд!
Портфель прикладных систем (Application Portfolio) - это ключевое понятие в управлении ИТ-архитектурой, описывает потребности бизнес-процессов предприятия в информационных технологиях, которые способны обеспечить автоматизированное ведение деятельности. Включает в себя набор интегрированных информационных систем. Как существующих, так и вакантных на данный момент, то есть тех, которые потребуются в будущем для обеспечения новых потребностей бизнеса и деятельности организации.
Таким образом он позволяет определить актуальный уровень покрытия необходимой функциональности бизнес-архитектуры, цифровыми решениями. А также устанавливает ответственность и приоритетность каждого приложения и варианты достижения результата, посредством либо разработки системы, либо приобретения готовых приложений, учитывая интеграцию и использование возможностей уже имеющихся ИС.
Рассмотрим эффект применения этого инструмента с разных ракурсов.
С точки зрения установления актуального состояния архитектуры, портфель описывает текущее положение компенсированности бизнес процессов предприятия - цифровыми решениями.
С точки зрения стратегии развития архитектуры, портфель презентует набор целевых прикладных систем, которые должны в перспективе удовлетворять потребности бизнес-процессов предприятия.
С точки же зрения процесса реализации планов развития, под портфелем понимается совокупность проектов, выполняемых на общем пуле ресурсов предприятия (финансы, люди, оборудование, материалы, энергия и прочее), направленных на трансформацию бизнес-процессов организации путем внедрения их цифровых двойников.
Это вторая часть серии «23 фичи Luxms BI, которыми мы гордимся». В первой (прочитать можно здесь) мы говорили о платформенности и архитектуре — о том, на чём держится система.
А сегодня расскажем о базе, о функционале классической BI-системы, который и делает систему BI-системой.
Этот раздел про то, без чего не обходится ни одна зрелая BI-система — визуализации, переменные, геоаналитика, сводные таблицы и внутренний язык. Мы не столько гордимся самим фактом их наличия — всё это действительно есть во многих решениях, сколько тем, как именно эти возможности реализованы в Luxms BI — у нас всё заточено под скорость, гибкость и удобство.
Язык Archimate часто используется для описания слоя приложений, функциональности информационных систем и интеграционных сценариев между информационными системами. Но в этой статье я хочу рассказать о применении бизнес-слоя в Archimate, а именно — как описать бизнес-процессы на языке Archimate.
Автоматизацией процессов первым занялся Фредерик Тейлор в начале 1920-х — он это делал в железе и жестко хардкодил, гибкость не была предусмотрена. Но то были производственные процессы, приставку ‘бизнес-‘ к ним еще не приделали.
Логично было применить его метод и к офисной работе, но это произошло гораздо позже — когда началась эпоха персоналок и локальных сетей, во второй половине 1980-х. Тогда и заговорили о «маршрутизации задач» между исполнителями.
Итак, давайте посмотрим, как с течением времени менялись рыночные ярлыки для систем управления процессами...
Привет, Хабр. Это дайджест по ИТ-архитектуре: системный дизайн и практики от Kafka/gRPC и RabbitMQ до наблюдаемости на Prometheus/Grafana, PostgreSQL HA (Patroni+etcd), TOGAF 10/ArchiMate, CQRS/Event Sourcing, Cassandra и Kubernetes/Nomad. Внутри — актуальные программы повышения квалификации и приглашения на бесплатные открытые уроки от действующих практиков.
Статья начинает цикл материалов по разработке электроприводов, подходов и технических нюансов, которые используются при их проектировании. Охватим большую часть силовой электроники для электропривода, промышленные сети (PROFINET, EtherCAT, CC-Link, EtherNet/IP (CIP) и др.), энкодеры (абсолютные: Hiperface DSL, SSI, BISS и др., а также инкрементные). Датчиковое и бездатчиковое векторное ориентированное управление (sensored/sensorless FOC - EKF/MRAS/SMO/HFI), рассмотрим электродвигатели PMSM (СДПМ), ACIM (асинхронный ЭД), BLDC (бесколлекторный двигатель постоянного тока) и другие их виды.
В этой статье я сделал обзор основных векторных баз данных: Milvus, Qdrant, Weaviate, ChromaDB, pgvector, Redis, pgvectorscale, LanceDB, ClickHouse, Vespa, Marqo, ElasticSearch.
Если вы запутались в разнообразии векторных баз данных или хочется верхнеуровнево понимать как они устроены, чем отличаются и для чего вообще нужны, то эта статья будет очень полезна. Мы пошагово соберем все ожидания от векторных БД, посмотрим бенчмарки, а затем попробуем собрать все воедино.
Представьте, что у вас есть карта города, способная «рассказывать истории» про людей, дороги, дожди и события — прямо сейчас, вживую. С помощью платформы Atlas анализ города превращается в чтение интерактивной хроники, а не в просмотр сухой статистики.
Привет! Меня зовут Аня, я руковожу службой аналитических платформ в Яндексе. Сегодня я расскажу про один из наших инструментов — SaaS‑платформу Atlas. Ей пользуются аналитики из Яндекс Такси, Доставки, Лавки и других сервисов Яндекса. Atlas помогает визуализировать данные, быстро находить и проверять гипотезы, а ещё — оперативно делиться инсайтами. Под катом — подробности о том, как работает платформа и с какими кейсами она помогает справляться, а также как вы можете попробовать её в деле.
Привет, Хабр! Меня зовут Станислав, я аналитик данных с трехлетним опытом и выпускник курса «Специалист по Data Science» в Яндекс Практикуме. Я расскажу, как проходил собеседования, с какими сложностями столкнулся и почему ходить на интервью стоит всегда — даже если у вас есть работа.
БигДата всегда звучит красиво — пока не нужно по ним искать и за нее платить.
Когда данные перестают влезать в индекс, а поиск тормозит — дело не в БД, а в архитектуре.Рассказываю, как мы перестроили систему на связке PostGIS + OpenSearch и добились отклика в десятки миллисекунд.
В предыдущей части мы обсудили общие аспекты ИТ Архитектуры, и подробно затронули такой ее слой, как архитектура Данных, которая охватывает все многообразие бизнес-информации предприятия, знания о потоках ее распределения, сборе, обработке и использовании, представляемой в виде различных моделей данных.
Теперь обратимся к слою Приложений, который соотнесет используемые данные и правила их обработки с компьютерными программами, для их хранения, получения и преобразования в ходе автоматизированного выполнения бизнес-процессов.
Архитектура прикладных решений (ESA –Enterprise Solution Architecture) — это организационный дизайн всего программного приложения, включая все подкомпоненты и внешние приложения, интерфейсы для их взаимодействия, а также их поведения в рамках сотрудничества структурных элементов.
Используются этот инструмент для описания модели того, как приложение будет обеспечивать жизненный цикл необходимых бизнес-процессов, соответствующих бизнес-архитектуре предприятия. Архитектура приложений покрывает достаточно широкую область, начиная с идентификации прикладных систем необходимых предприятию для выполнения бизнес-процессов, и захватывает такие аспекты, как проектирование, разработку (или приобретение) и интеграцию прикладных систем в комплексные решения.
Потому для упрощения восприятия, как правило, разделяют две основные области ее применимости:
