Иногда технологии подводят — зато случайность делает то, чего не смог бы ни один расчёт.
Шестьдесят лет назад два инженера из Bell Labs, Арно Пензиас и Роберт Уилсон, просто хотели измерить радиошум Млечного Пути. Но в антенне постоянно появлялся странный фон, будто кто-то шептал из ниоткуда. Оказалось, это не сбой и не помеха — это эхо самого рождения Вселенной.
Проектирование мостов — это особый мир со своей логикой. Здесь все начинается с оси, а любое ее изменение влечет за собой пересчет всей конструкции. Минимум прямоугольного, максимум сложных кривых, разверток и работы с большими координатами.
В этом кейсе мы расскажем, как один из лидеров транспортного проектирования, АО «Институт «Стройпроект», применяет Платформу nanoCAD и nanoCAD BIM Строительство.
Статья будет интересна инженерам, проектировщикам, архитекторам, и всем, кто интересуется строительством сложных объектов.
Спрос на префаб-дома (собранные на участке из панелей заводского изготовления) с полной автоматизацией климата пока невелик. Большинство заказчиков сосредоточено на планировке, отделке и стоимости, а «умные» функции откладывает на потом.
Между тем именно заводской формат дает редкую возможность сделать автоматизацию по уму: скрыто проложить кабели, предусмотреть закладные под датчики и оборудование. В уже построенном доме это потребует либо масштабных работ, либо открытой прокладки коммуникаций, которая портит интерьер и сводит на нет преимущество чистого монтажа.
Мы побывали в демонстрационном префаб-доме, который собрали из панелей за три дня, а затем оснастили системами вентиляции, кондиционирования, увлажнения и автоматикой, управляющей климатом как единым целым.
Разработать электронную начинку радиоэлектронного прибора — половина дела. Вторая половина — корпус.
Освоить CAD на минимальном уровне реально за выходные; еще за выходные спроектировать простой корпус и выгрузить развертки и чертежи. Чтобы произвести детали, потребуются длинная воля, твердость, самообладание, время, знакомства и удача.
Привет, Хабр!
Меня зовут Андрей, я – специалист по оптическим системам, расчётчик и конструктор в одном лице.
Это третья статья из курса основ прикладной оптики, созданного несколько лет назад для внутреннего обучения CV-разработчиков организации, где я работаю.
В этой статье мы поговорим о диафрагмах: что они из себя представляют, какие бывают и как влияют на изображение. Также разберёмся, откуда берётся виньетирование и как с ним бороться.
Тема при кажущейся простоте весьма сложна — даже в оптической литературе нет единой последовательности её изложения. При подготовке статьи самым сложным оказалось выбрать, какой необходимый минимум рассказывать (а что опустить) и как выстроить текст так, чтобы он легко читался и воспринимался.
Думаю, и фотографы, и специалисты по компьютерному зрению найдут здесь для себя что-то новое. Если что-то останется непонятным — прошу в комментарии.
Статья сочетает как упрощённые идеи из теории оптических систем, так и мой личный опыт, накопленный при работе с системами технического зрения.
Привет, Хабр! Сегодня с вами Анна Асабина, главный инженер по тестированию, и Ольга Султанова, руководитель направления тестирования в Рунити. Мы расскажем о нашем опыте внедрения метрик в тестировании: какие метрики для нас работают, зачем мы автоматизировали их сбор и что в итоге изменилось.
В каждой крупной компании есть своя невидимая конституция — документ, который решает, как работает каждый датчик, какой цвет у кнопки «Пуск» и как должен называться тег в контроллере.
Эти внутренние стандарты автоматизации редко показывают публике, но именно они превращают сотни заводов в один живой организм, где каждая линия, каждая установка подчиняется общей инженерной логике.
Там, где другие строят с нуля, Nestlé просто открывает шаблон. Где кто-то ищет «как сделать», Iberdrola просто следует собственному кодексу автоматики.
И чем сложнее технологии, тем ценнее становится не оборудование — а порядок.
Как выглядела сантехническая инфраструктура, где нашли водонагревательный бойлер 1 века до нашей эры и как римляне строили грандиозные гидротехнические сооружения. Во время чтения вы будто попадете в натуральные двемерские руины, а на некоторых фотках узнаете кран из бабкиной ванной.
В этой статье мы впервые представляем результаты, полученные с помощью фононового детектора на основе сахара, использующего кристаллы сахарозы (C₁₂H₂₂O₁₁), способного к обнаружению частиц с сопутствующим сцинтилляционным светом..
Представьте — вы молодой врач-кардиолог, только пришли работать в новую больницу. И замечаете, что при уровне смертности в 35% среди пациентов с инфарктом миокарда, никто не пытается ничего с этим сделать. Нет ежедневного контроля (а если и есть, то медсестры не знают, что и как правильно измерять); есть старое аналоговое оборудование, информирующее только об остановке сердца; не проводится никаких конференций для повышения квалификации персонала.
Если вы — ответственный и честный человек, мириться с таким положением вы не станете. Ровно так думал и Джулиан Хейвуд. И именно его энтузиазм привел к появлению одного из первых цифровых кардиомониторов, спасшего десятки жизней.
Митапы про микросервисы, хайп вокруг новых фреймворков, кеш и перекрашенные кнопки — привычная рутина современного айтишника…
Но мы-то знаем: есть и другое IT. Там пишут код, от которого зависят тонны синтетических материалов или выплавленной стали, скорость производственной линии и бесперебойная работа энергосети. Это мир Heavy Digital. И он становится всё больше.
Мы захотели выяснить, почему всё больше IT-специалистов осознанно выбрали работу на заводах и в промышленных гигантах. Что за мотивы ими движут, какие задачи вызывают настоящий драйв и чувство сопричастности к чему-то большому? Мы собрали эти и другие вопросы и приглашаем всех причастных к IT в промышленности ответить на них в ветке «Я эксперт в Heavy Digital».
А ещё мы хотим узнать мнение тех, кто слышал о Heavy Digital и только стоит на пороге выбора. Чтобы понять ваши ожидания и страхи, мы создали ветку опроса «Я пока не в Heavy Digital».
Спойлер: в конце ветки для экспертов у вас будет возможность рассказать о самом запоминающемся профессиональном вызове. Авторы 10 лучших историй смогут получить ачивку «Герой Heavy Digital» в своем профиле на Хабре.
Готовы? Тогда выбирайте свою ветку — и вперёд!
Портфель прикладных систем (Application Portfolio) - это ключевое понятие в управлении ИТ-архитектурой, описывает потребности бизнес-процессов предприятия в информационных технологиях, которые способны обеспечить автоматизированное ведение деятельности. Включает в себя набор интегрированных информационных систем. Как существующих, так и вакантных на данный момент, то есть тех, которые потребуются в будущем для обеспечения новых потребностей бизнеса и деятельности организации.
Таким образом он позволяет определить актуальный уровень покрытия необходимой функциональности бизнес-архитектуры, цифровыми решениями. А также устанавливает ответственность и приоритетность каждого приложения и варианты достижения результата, посредством либо разработки системы, либо приобретения готовых приложений, учитывая интеграцию и использование возможностей уже имеющихся ИС.
Рассмотрим эффект применения этого инструмента с разных ракурсов.
С точки зрения установления актуального состояния архитектуры, портфель описывает текущее положение компенсированности бизнес процессов предприятия - цифровыми решениями.
С точки зрения стратегии развития архитектуры, портфель презентует набор целевых прикладных систем, которые должны в перспективе удовлетворять потребности бизнес-процессов предприятия.
С точки же зрения процесса реализации планов развития, под портфелем понимается совокупность проектов, выполняемых на общем пуле ресурсов предприятия (финансы, люди, оборудование, материалы, энергия и прочее), направленных на трансформацию бизнес-процессов организации путем внедрения их цифровых двойников.
Может ли древняя мечта воздухоплавания наконец стать реальностью благодаря новому союзу — инженера и алгоритма?
Помню, как впервые наткнулся на эту идею в учебнике по истории техники. Схематичный рисунок, похожий на яйцо, и подпись: «Вакуумный дирижабль Франческо Лана де Терци, 1670 год».
Мы в LogistiX, внедряя технологические инновации, неизбежно сталкиваемся не только с техническими задачами, но и с человеческим фактором. На стороне заказчика это часто проявляется как пассивный саботаж, сомнения или эмоциональное отторжение, что ставит под угрозу сроки и качество проекта.
Важно понимать, что сопротивление персонала — это не «поломка» системы, а совершенно нормальная реакция на неопределенность. Люди боятся возможной потери контроля и изменения привычных ролей.
Эта проблема имеет предсказуемую логику, и ею можно управлять. Ответственность за снижение сопротивления лежит, прежде всего, на стороне заказчика, поскольку именно у него есть полномочия и каналы коммуникации с сотрудниками.
В этой статье мы разберем, почему автоматизация часто буксует из-за конфликта с персоналом и как системные инструменты превращают это сопротивление в ресурс для развития.
Статья начинает цикл материалов по разработке электроприводов, подходов и технических нюансов, которые используются при их проектировании. Охватим большую часть силовой электроники для электропривода, промышленные сети (PROFINET, EtherCAT, CC-Link, EtherNet/IP (CIP) и др.), энкодеры (абсолютные: Hiperface DSL, SSI, BISS и др., а также инкрементные). Датчиковое и бездатчиковое векторное ориентированное управление (sensored/sensorless FOC - EKF/MRAS/SMO/HFI), рассмотрим электродвигатели PMSM (СДПМ), ACIM (асинхронный ЭД), BLDC (бесколлекторный двигатель постоянного тока) и другие их виды.
Привет, Хабр! Мы все читаем одни и те же новости: ИИ пишет код, управляет дронами и вот-вот отберёт у людей всю работу. Кажется, он везде. Но на самом деле есть одна интересная сфера, куда нейросетям пока вход закрыт. Ещё удивительнее то, что речь идёт именно о той деятельности, которая связана с рождением всех этих умных алгоритмов — дата-центры. И тут возникает парадокс: туда, где создают LLM, наотрез отказываются пускать их к рулю. Почему?
На выставке «Рудник-2025» в Екатеринбурге состоялась конференция инженеров, механиков и технологов, где обсуждались практические решения для водоочистки на горнодобывающих предприятиях. Среди представленных работ — доклад Евгении Петуховой, ведущего технолога компании «Кайрос Инжиниринг» (г. Пермь), посвящённый альтернативным методам очистки шахтных и карьерных вод.
В предыдущей части мы обсудили общие аспекты ИТ Архитектуры, и подробно затронули такой ее слой, как архитектура Данных, которая охватывает все многообразие бизнес-информации предприятия, знания о потоках ее распределения, сборе, обработке и использовании, представляемой в виде различных моделей данных.
Теперь обратимся к слою Приложений, который соотнесет используемые данные и правила их обработки с компьютерными программами, для их хранения, получения и преобразования в ходе автоматизированного выполнения бизнес-процессов.
Архитектура прикладных решений (ESA –Enterprise Solution Architecture) — это организационный дизайн всего программного приложения, включая все подкомпоненты и внешние приложения, интерфейсы для их взаимодействия, а также их поведения в рамках сотрудничества структурных элементов.
Используются этот инструмент для описания модели того, как приложение будет обеспечивать жизненный цикл необходимых бизнес-процессов, соответствующих бизнес-архитектуре предприятия. Архитектура приложений покрывает достаточно широкую область, начиная с идентификации прикладных систем необходимых предприятию для выполнения бизнес-процессов, и захватывает такие аспекты, как проектирование, разработку (или приобретение) и интеграцию прикладных систем в комплексные решения.
Потому для упрощения восприятия, как правило, разделяют две основные области ее применимости:
Я уволился из своей первой работы SRE‑инженером после особенно тяжелой недели дежурства. Семь ночей подряд я просыпался от PagerDuty. Семь ночей подряд я чинил одну и ту же проблему с памятью, которую никто не хотел исправлять «по‑настоящему», потому что «горячий фикс же работает». На восьмое утро я пришел в офис и положил заявление на стол.
Это было пять лет назад. С тех пор я прошел через четыре компании, построил on‑call процессы с нуля в двух из них, и научился главному: дежурства не должны убивать людей. Физически и морально. Давайте поговорим о том, как построить on‑call ротацию, которая не приведет к массовым увольнениям.
Помню, как на собеседовании в одну крупную компанию мне задали вопрос: "Чем отличается observability от monitoring?" Я уверенно ответил что-то про "три столпа" и "unknown unknowns". Интервьюер кивнул, но потом спросил: "А зачем платить $100k в год за Datadog, если можно поставить бесплатный Prometheus?"
Тогда я не смог внятно ответить. Сейчас, спустя три года и несколько миграций между системами мониторинга, я знаю ответ. И он стоил нашей компании около полумиллиона долларов в экспериментах. Давайте разберемся, за что же мы платим такие деньги.
