Анализируй и проектируй
Когда человек впервые слышит про одногодичную магистратуру, обычно возникает один из двух вопросов:
«А так вообще можно?»
«Что из обычной двухлетней программы пришлось выбросить?»
На первый вопрос ответить просто: да, можно. Рассказали про нашу одногодичную программу «Большие данные и машинное обучение».
Когда начинаешь разговор о видеоаналитике, обычно он переходит в русло про точность моделей, архитектуру и алгоритмы. Но за последние три года работы с внедрением данной системы я понял одно — самая сложная часть проекта это не технология. Это люди. И самое неожиданно сильное сопротивление приходит не оттуда откуда ожидаешь.
Под катом — три рассказа о внедрении, три типовых истории из жизни.
«Это же бюрократия, у нас и так всё работает!» / «Документация — это отлично, но у нас есть задачи поважнее» / «Катя, я пришла на проект, а у них ничего, а у нас аудит». Эти фразы и еще много подобного я слышала так много раз, что кажется, время этой статьи пришло).
Мой путь от скептика к как меня в шутку называют коллеги «документатору‑злодею» и мысли о том, зачем же нам все таки нужно уметь и делать проектную документацию.
Пять пробелов, которые не видны на архитектурных блок-схемах.
Пользователь нажимает «Place Order» (Сделать заказ).
API возвращает 200 OK. Заказ появляется в базе данных. На странице оформления заказа выводится сообщение «success» (успех). Извне всё выглядит нормально.
А потом в службу поддержки прилетает тикет.
Представьте, что любой человек, выйдя на улицу или посмотрев в окно, может стать частью распределенной системы раннего обнаружения воздушных угроз. Не как оператор или специалист, а как источник дополнительного сенсорного наблюдения.
Современный смартфон представляет собой доступную COTS‑платформу с набором встроенных датчиков: камерой, GNSS‑приемником, 6-DoF IMU, барометром и микрофонами. По отдельности эти сенсоры ограничены, однако их совместное использование в распределенной сети потенциально позволяет создавать новые подходы к обнаружению низколетящих БПЛА.
Это не задача создания «смартфонного радара», а инженерная задача на стыке краудсорсинга, Edge Computing, машинного обучения и обработки сигналов.
Как превратить множество пользовательских устройств в единую распределенную апертуру? Попробуем рассмотреть возможную архитектуру такой системы.
Мы, как потребители, крайне редко задумываемся над тем, как создаются продукты, товары, которые делают нашу жизнь, быт проще, чище, интереснее, вкуснее и т.д.
На просторах интернета можно без особого труда найти видеоролики, рассказывающие о производителях различных товаров, о том, каким образом выстроены процессы производства.
Сегодня речь пойдет о процессе, без которого производство невозможно представить, но потребитель зачастую даже не задумывается об этом. Мы поговорим о процессе планирования производства, а именно, о формировании детального плана-графика, и тех задачах, которые находятся в зоне ответственности специалистов по планированию. С какой целью? Чтобы понять, какой большой объем работы сосредотачивается зачастую на одном специалисте, и какие возможности существуют, чтобы ему помочь.
Цель статьи
Цель данной статьи хотя бы в сжатом варианте рассказать о том, из каких шагов состоит построение графика производства и какой труд стоит за красивой картинкой в виде очереди ПЗ на диаграмме Ганта.
Привет, Хабр! На связи команда Research & Insights Департамента стратегического развития МТС. В первом материале из цикла мы разобрали, чем пятое поколение связи отличается от предыдущих стандартов, какие технологии лежат в его основе и почему операторы рассматривают 5G как фундамент для нового этапа цифровой экономики. Сегодня поговорим о том, как эта технология распространяется по миру.
На 2025 год в 5G инвестируют 642 мобильных оператора, а коммерчески запустили технологию около 374 раз, но сам факт запуска технологии мало что говорит о зрелости рынка. Заходите под кат, если хотите узнать, как 5G внедряли в США, Китае, Южной Корее, Великобритании и Германии, почему у них получились разные модели монетизации и чего ждать в России.
Программа nanoCAD Механика PRO в первую очередь предназначена для создания проектов машиностроительной отрасли (детали, механизмы и оборудование). Возможности продукта позволяют решать задачи для выпуска документации с деталями высотой точности. Строительное направление отличается тем, что погрешность на монтаже может доходить до 1 см. Но есть отдельные направления на стыке строительства и машиностроения, это малые архитектурные формы, которые поставляются высокой заводской готовности из металла, пластика и дерева. С учетом развития науки и техники, изготовление таких объектов возможно в короткие сроки и с высокой точностью сборки на монтаже.
Применение nanoCAD Механика PRO позволяет решать задачи не только оформления проектной документации, но и формирования 3D-модели для передачи ее на производство со станками с ЧПУ. Дополнительно 3D-модель может использоваться для передачи геометрии в ТИМ-проекты с целью наполнения базы данных проекта и визуализации, так как малые архитектурные формы могут быть частью строительного проекта. Использование продуктов экосистемы nanoCAD позволяет комплексно решать подобные задачи.
В этой статье рассматриваются практические приемы работы в nanoCAD Механика PRO на примере малых архитектурных форм, которые помогут ускорить процесс конструирования и избежать типичных ошибок. Материал является продолжением вебинара и ориентирован на пользователей, уже знакомых с базовым функционалом программы.
Речь о процедурно‑параметрическом программировании, о котором почти никто не пишет. Я реализовал одну и ту же задачу в ООП и в этой парадигме и сравнил их численно. Одна из метрик разошлась в 6 раз.
В прошлой статье мы подробно разбирали, как автоматизировать создание чек-листов и ускорить рутинные проверки с помощью нейросетей. Эта практика отлично прижилась на наших проектах: инженеры получили удобный инструмент, который за считанные секунды выдает готовую базу для тестирования задачи и освобождает от необходимости писать первый черновик с нуля. Но со временем вылезла ожидаемая проблема. AI не всегда находил все требования по задаче, иногда додумывал связь между документами, а к части источников у него вообще не было доступа.
В результате следующий промпт получал неполный контекст, а сформированный чек-лист тоже оказывался неполным. И это неприятный случай, потому что внешне чек-лист выглядит аккуратно и уверенно, но какого-то бизнес-правила там просто нет.
При этом цель осталась прежней – сократить время QA на анализ требований. Раньше приходилось руками собирать всё по ссылкам, искать недостающую информацию, проверять версии файлов, находить таблицы с калькуляциями, файлы с эмуляторами и иногда просто выяснять, какой документ сейчас считается актуальным. Поэтому мы пошли на уровень раньше и начали отдельно собирать корпус требований в Codex (но это уже следующая статья). А в данном материале покажу общий подход и несколько правил из промптов, возможно кому-то они пригодятся.
В предыдущей статье о ГОЭЛРО я писал о программе «А»: прежде чем строить новые мощности, план предусматривал восстановление и реконструкцию существовавшего энергохозяйства. Сначала вернуть основанию работоспособность — и лишь затем возводить на нём новое. Исторически эта часть плана действительно называлась программой «А»; такое описание приводит, в частности, Минэнерго России.
В автоматизации эту последовательность постоянно пытаются перепрыгнуть. Компании хотят сразу перейти к целевой архитектуре, единому информационному пространству, сквозным процессам, искусственному интеллекту и управлению на основе данных. Но нередко выясняется, что под будущей системой пока нет основания: бизнес не договорился, какой процесс строит, кто им владеет, какие данные считать достоверными и какой результат вообще должен измениться после внедрения.
За двадцать с лишним лет в ИТ я наблюдал эту ситуацию с разных сторон. Начинал программистом 1С, руководил ИТ розничной сети, был партнёром-интегратором, участвовал в крупных проектах замены зарубежных корпоративных систем российскими решениями, а затем оказался на стороне заказчика и стал принимать работу других интеграторов.
По обе стороны баррикады спор обычно формулируют одинаково: кто должен диктовать автоматизацию — бизнес или ИТ?
Я всё больше думаю, что это неправильный вопрос.
Бизнес должен иметь последнее слово в вопросах «зачем» и «что»: какую проблему решать, какого эффекта добиваться, чем пожертвовать и какие изменения считать приоритетными. ИТ отвечает за «как»: архитектуру, данные, технологические ограничения, интеграции и жизнеспособность будущего решения.
Всем привет! С вами на связи Евгений Певцов, эксперт по качеству данных группы развития методологии из МТС. Около года назад мои коллеги уже рассказывали, зачем нам потребовались формализованные соглашения об обмене данными и какую проблему они должны были решить.
Тогда нашей главной целью было — зафиксировать договоренности между Поставщиком и Потребителем данных: какие из них передаем, в каком формате, кто отвечает за сопровождение и как нужно вносить изменения, чтобы они неожиданно не приводили к сбоям сразу в нескольких десятках зависимых сервисов.
Сейчас дата-контракты — это полноценный сервис, встроенный в существующие ETL-процессы на всем жизненной пути данных. Им ежедневно пользуются продуктовые команды, архитекторы, аналитики и Владельцы данных.
И сегодня я хочу поделиться практическим опытом, накопленным командами за время использования нашего сервиса: какие идеи сработали, что мы поменяли или доработали, где добавили автоматизацию, а также что еще планируем изменить или улучшить.
В предыдущей статье мы разобрали третье базовое понятие BABOK — Изменение (Change). Мы выяснили, что изменение — это не событие, а процесс, и что 70% инициатив проваливаются не потому что техника плохая, а потому что человеческая сторона проигнорирована. Но предположим, вы всё сделали правильно: нашли нужных заинтересованных сторон, сформулировали истинную потребность, спроектировали переход. Следующий вопрос — самый дорогостоящий в буквальном смысле слова:
Что именно мы будем строить или менять?
Именно здесь в игру вступает четвёртое базовое понятие BABOK — Решение (Solution). И именно здесь совершается ошибка, за которую бизнес платит дороже всего: команда влюбляется в первое пришедшее в голову техническое решение и перестаёт искать альтернативы.
Склад может работать «в плюс» по всем видимым статьям — и при этом системно терять рентабельность. Не из-за ошибок персонала и не из-за дорогой аренды, а из-за структуры ассортимента.
Возьмём типичный пример: неликвидные позиции на складе оценены в 5 млн рублей. При обычной для рынка стоимости хранения запаса 20–30% в год, только за то, что эти позиции занимают место и держат замороженный капитал, склад теряет от 1 до 1,5 млн рублей ежегодно. Через 3–4 года такого хранения суммарные затраты превышают закупочную цену товара. Дальше держать — терять деньги наверняка, продать — терять деньги один раз.
Эта статья — о том, как увидеть эту математику в данных WMS и принять решение раньше, чем она окончательно съест маржу.
Привет, Хаброжители! Системная инженерия — ключевой инструмент для разработки сложных систем на всех этапах их жизненного цикла. В обновленном издании эксперт в области системной инженерии подробно рассказывает, что следует учитывать при проектировании надежных и эффективных систем.
Привет, Хабр! Мы — команда разработки кредитных продуктов для физических лиц в Т-Банке. Делимся опытом нагрузочного тестирования workflow-движка Zeebe (основы Camunda 8), который проводили, когда искали альтернативу Camunda 7.
Вокруг Zeebe ходит немало стереотипов: медленный, сложный в настройке, нестабильный. Но большинство мнений основаны на данных, актуальных для устаревших версий. Мы приняли во внимание развитие продукта и провели собственное исследование.
Компания «Нанософт» – ведущий разработчик инженерного программного обеспечения объявляет о выходе версии 26 nanoCAD Облака точек.
nanoCAD Облака точек – специализированное решение на Платформе nanoCAD, предназначенное для обработки данных 3D-сканирования и решения инженерных и информационных задач в области геодезии, машиностроения, строительства, инфраструктурного и метрологического мониторинга.
Версия nanoCAD Облака точек 26 доступна в трех конфигурациях: «ReClouds», «Метрология» и «Геотехнический мониторинг».
Что нового в конфигурации «ReClouds»
Создание ортофотопланов
Новая команда формирует ортофотопланы по набору перекрывающихся снимков прямо в nanoCAD, поэтому пользователю не надо переключаться в сторонние программные продукты для получения плоской привязанной картографической подложки.
Точное указание уровней сечений при послойной векторизации
В инструменте Послойная векторизация высота каждого сечения теперь может задаваться индивидуально относительно начального уровня для более точного отображения контуров объекта в облаке точек.
Прореживание облака без потери исходных измерений
В команде Прореживание облака точек добавлен режим, который не генерирует новые точки, а выбирает внутри каждого вокселя реальную измеренную вершину, ближайшую к центру масс, появились дополнительные способы прореживания. С итоговым облаком становится легче работать, но при этом оно остается «честным», без искажения исходных данных.
Плавные переходы цвета при раскраске по высоте
В инструменте Раскраска сети по высоте реализовано сглаживание границ цветовых интервалов для дискретной раскраски, за счет этого визуализация сети выглядит менее ступенчатой.
Я проектирую системы на LLM, и после каждого громкого ИИ‑инцидента мне прилетает одна и та же ссылка с одним и тем же вопросом: «а у нас такое может случиться?» Чтобы отвечать не на глазок, я завёл привычку разбирать каждый такой инцидент до конкретной технической причины. За последние месяцы таких разборов набралось три, и они удивили меня не сходством, а различием. Дыры, в совершенно разных местах: у одного проекта не проверялись источники, у другого, данные на границах системы, у третьего, права автономного агента. А вот причина одна: системы вокруг LLM строили люди, которые умеют писать промпты, но не умеют проектировать архитектуру.
Судите сами. Deloitte Australia возвращает правительству деньги за отчёт, в котором ИИ выдумал источники. В Миннесоте полиция четырьмя машинами блокирует на парковке журналиста, потому что сеть ИИ‑камер несколько дней вела его как угонщика, из‑за опечатки, сделанной за две тысячи миль от него. А основатель инди‑SaaS просыпается и обнаруживает, что написанный моделью код ночью отменил все подписки его клиентов и оставил бизнесу $38 месячной выручки.
Эта статья НЕ является ни шпаргалкой по заявленной теме, ни учебником, ни истиной в последней инстанции. Она написана преподавателем, имеющим опыт моделирования бизнес-процессов, на основе опыта преподавания, но не продакшена непосредственно баз данных, и рассказывает прежде всего о том, чего и почему не понимают современные студенты, изучающие программирование баз данных, в чём корень их дальнейших проблем в проектировании баз данных. На примере задачи проектирования приложения для ведения расписания занятий учебного заведения показан мой порядок проектирования и разработки базы данных.
Несмотря на самостоятельность этой публикации, она раскрывает некоторые вопросы, поднятые ранее в статье "Как пройти… к третьей нормальной форме?"
Привет, Хабр! Сегодня System Design интервью стало неотъемлемой и, пожалуй, самой трудной частью найма разработчиков. От кандидатов требуют за короткое время спроектировать условный YouTube, Google Drive или Telegram, способный выдерживать миллионные нагрузки, не падать при отказе дата-центров и отвечать пользователю за считанные миллисекунды. И здесь большинство разработчиков сталкивается с суровой реальностью. Сложность в том, что на собеседованиях дают задачи на проектирование масштабных распределенных систем, но реальным опытом их создания создания обладают немногие. Задача проектирования может быть решена несколькими способами и не имеет единственного правильного ответа: Одно и то же требование можно реализовать многими способами, и каждый будет иметь плюсы и минусы. Нужно уметь проектировать высоконагруженные системы, учитывая проблемы сети: задержки, сбои серверов, обеспечение согласованности данных и балансировку нагрузки. Также требуется разбираться во множестве технологий и понимать, когда и как их применять.
Поэтому на интервью кандидат часто совершает критические ошибки: не умеет собирать требования и путает функциональные рамки проекта с нефункциональными (SLA, RPS, масштабируемость). Не видит нюансов и узких мест, из-за чего архитектура рушится при первой же пиковой нагрузке. Пытается строить отказоустойчивость «на бумаге», не понимая, как выбранные базы данных или очереди сообщений будут вести себя в реальном облаке. Лучший способ разобраться в тонкостях проектирования распределенных систем и увереннее чувствовать себя на архитектурных секциях — это создать такую систему с нуля в виде пет-проекта. Этой публикацией я начинаю серию статей, целью которой является желание поделиться опытом создания такой системы с нуля. Начнем с проектирования архитектуры, далее шаг за шагом реализуем ее на языке Go, развернем в облаке и оценим производительность. Будем проектировать систему сокращения ссылок из классической книги по системному дизайну.