Это небольшое дополнение к статье Проект по Air Quality sensor, идея, концепция, дизайн и почти: реализация. Если вы её не читали, то лучше начать с неё, будет понятна предыстория и как развивалась концепция взаимодействия с пользователем и AQ. А мы пойдем по классикам и коротко разберем, разработку проекта от потребностей до дизайна.
В последнее время идут баталии между сторонниками vibe‑кодинга (использование ИИ инструментов без понимания в коде) и сторонниками классического программирования. В зависимости от того к группе менеджеров или программистов относятся первые, их мотивация отличается, но она по сути про одно — менеджерам кажется, что наконец у них появился священный грааль с помощью которого они избавятся от зависимости в «зажравшихся» программистах, на любой проект можно будет посадить несколько человек с улицы. Главное, чтобы могли уметь писать или хотя бы голосом в микрофон излагать связанно мысли.
В интернете есть книги и множество статей, таких как эта, в которых авторы приводят аргументы в пользу использования Postgres для всего. Я решил рассмотреть один из вариантов использования — применение Postgres вместо Redis для кэширования. Я довольно часто работаю с API, поэтому я создал очень простой HTTP-сервер, который отвечает данными из этого кэша. Я начал с Redis, так как часто сталкиваюсь с этим на работе, а затем переключился на Postgres с использованием нежурналируемых таблиц и посмотрел, есть ли разница.
В мире микросервисов десятки, а то и сотни сервисов живут своей жизнью. Каждый со своим адресом, своими правилами, своей аутентификацией. Для внешнего клиента это выглядит как город без улиц и указателей. API Gateway — это попытка навести порядок. Он становится единым фасадом, центральным КПП для всего вашего бэкенда.
Но эта простота обманчива. Внедрение шлюза порождает свой собственный набор сложных архитектурных проблем. Решить их неправильно — значит построить себе очень дорогую и хрупкую тюрьму.
Статья о том, какие бывают ограничения самописных планировщиков задач и как мы перевели весь процесс планирования в NiFi, сделав его более прозрачным.
2025 год должен был стать годом триумфа Искусственного Интеллекта. И если смотреть на заголовки, так оно и есть: 78% организаций по всему миру заявляют, что используют ИИ хотя бы в одной бизнес-функции, а общие корпоративные инвестиции в технологию за 2024 год перевалили за $250 миллиардов. Деньги льются рекой: половина лидеров планирует удвоить бюджеты на ИИ, а средние месячные расходы компаний готовятся вырасти с $63,000 до $85,000. Кажется, что машина хайпа несется на полной скорости.
Но если присмотреться к приборам, а не к пейзажу за окном, картина становится куда интереснее. И тревожнее.
Впервые за два года непрерывного роста крупные компании (250+ сотрудников) внезапно нажали на тормоз: уровень внедрения ИИ в их производственные процессы за лето 2025-го снизился с 14% до 12%. В это же время свежий отчет MIT бьет наотмашь: 95% пилотных проектов по генеративному ИИ проваливаются, не доходя до реального использования.
Что происходит?
Добро пожаловать в эпоху "отрезвления". Период, когда эйфория от первых успехов ChatGPT сменяется жестким похмельем от столкновения с реальностью. Реальностью, в которой 42% лидеров втихую признаются, что громкие заявления их компаний об ИИ - просто раздутый хайп, а 82% людей в целом скептически относятся к технологии. Внутри корпораций назревает настоящий раскол между лагерем "скептиков", которые видят риски и провалы, и лагерем "реалистов", которые продолжают верить в технологию.
Эта статья - глубокое погружение в цифры и настроения сентября 2025-го.
Что делать, если продукт перестал соответствовать потребностям или больше не поддерживается вендором? Можно притворяться, что проблемы нет с вами в комнате, допиливать своими силами, подставлять «костыли» из других систем — или решиться на миграцию.
Привет, Хабр! Меня зовут Ксения, я — бизнес-аналитик в ITSM 365, организую переезды клиентов на наш сервис деск. Опыт накоплен большой, давайте вместе разберемся на реальных кейсах:
- внешняя и внутренняя миграция — в чем особенности,
- зачем мигрировать на новую конфигурацию продукта,
- как подготовиться к переезду и минимизировать риски,
- для кого миграция — не выход, и что делать в этом случае.
«Workslop» - новая чума офисной продуктивности
Представьте: понедельник, утро. Вы открываете почту, а там - отчет от коллеги из соседнего отдела. Называется «Стратегический анализ синергии рыночных векторов на Q4». Звучит солидно. Вы открываете. Тридцать страниц, графики, красивые диаграммы, текст пестрит выражениями вроде «масштабирование инсайтов» и «кросс‑функциональное взаимодействие». Выглядит профессионально. Даже слишком.
Вы тратите на это два часа. Два часа, Карл! Пытаетесь продраться через словесную шелуху, найти хоть одну конкретную цифру, хоть один дельный вывод, хоть намек на то, что вам, собственно, делать дальше. И в конце понимаете: ничего. Это пустышка. Красиво оформленный, абсолютно бессодержательный текст, который нейросеть сгенерировала за пять минут. А вы потратили на него два часа своей жизни.
Поздравляю, вы только что столкнулись с «workslop».
И если вы думаете, что это единичный случай, у меня для вас плохие новости. Это новая чума 2025 года, которая тихо, но уверенно пожирает нашу продуктивность. Исследователи из Стэнфорда и BetterUp Labs недавно взорвали инфополе своей статьей в Harvard Business Review, где привели шокирующие цифры. Оказывается, уже 40% из нас регулярно получают такой «цифровой мусор». И тратят в среднем по два часа на то, чтобы просто его разгрести и понять, что имелось в виду.
Звучит как сюжет для антиутопии? Увы, это наша новая реальность.
«Workslop»- это не просто технологическая проблема. Это симптом болезни. Болезни, имя которой - слепая вера в «магию» ИИ и прогрессирующая атрофия собственного мозга. Это новый, более изощренный вид лени, который научился очень хорошо маскироваться под продуктивность. И он угрожает не только нашим дедлайнам и бюджетам (а потери, по оценкам, достигают $9 миллионов в год на крупную компанию). Он угрожает главному - доверию внутри команд.
Эта статья - о том, как распознать эту заразу, понять, откуда она берется, и, самое главное, как с ней бороться.
Привет, Хабр! Я Игорь Морозов, архитектор в Platformeco. Мы более семи лет развиваем методологию композитных предприятий (Composable Enterprise), изначально разработанную с Google и Gartner, а также делаем продукты iPaaS, API-management и Workflow automation. На True Tech Arch #7, конференции для IT-архитекторов я рассказывал, как ИИ меняет интеграцию и автоматизацию. В этом материале по мотивам моего доклада я покажу, при каких обстоятельствах создание ИТ-продуктов уйдет доменным экспертам, появится возможность автоматизации недоступных ранее процессов и с какими вызовами это столкнется.
Информации о компании или продукте зачастую так много, что становится невозможно описать все на одной схеме или интеллектуальной карте. Есть такой подход — описывать отдельные контексты, т. е. конкретные, значимые для бизнеса ситуации с четкими границами, внешними участниками и целями.
Каждый трейдер знаком с этим неприятным чувством: цена идеально идет к вашей цели, но за мгновение до этого делает резкий рывок в обратную сторону, выбивает ваш стоп-лосс и только потом разворачивается. Кажется, будто вас специально выбивает Маркетмейкер.
Концепция "Smart Money" (SMC) в трейдинге базируется на идее отслеживания действий крупных, или "информированных", участников рынка. Практические методики, предлагают набор визуальных паттернов (Order Blocks, FVG, Break of Structure) для идентификации зон потенциального интереса этих игроков. Однако для систематической проверки и автоматизации данных подходов требуется переход от качественного визуального анализа к количественной формализации.
Два с половиной года проработала — зарплату не подняли. Пришлось искать другую компанию, чтобы вырасти в зарплате — перешла на 125 тысяч.
Роботы становятся частью реальных процессов — от производства до медицины. Поэтому создание умных машин требует быстрой разработки, высокой надежности и цифрового контроля. В этом помогает ключевая технология — виртуальный двойник. Это не просто симуляция, а точная цифровая копия реальной роботизированной системы, которая обеспечивает связь между физическим и цифровым миром. Что такое цифровой двойник и чем он полезен для создания и тестирования роботов, расскажем в этой статье.
Представьте: у вас 17 предприятий, на каждом работают сотни операторов, слесарей, аппаратчиков. Каждый должен знать свое оборудование, уметь его обслуживать и — главное — работать безопасно. А еще каждый завод ведет учет по-своему: кто в Excel, кто на бумаге, кто как придумал.
Такой разнобой плохо сказывается на всём бизнесе: сложно понять, какие компетенции реально закрыты, кто готов к аттестации, где есть риски для безопасности. Масштабировать процессы на всю компанию при такой «лоскутной системе» невозможно.
Именно с этой задачей к нам в ИТ пришли коллеги из бизнеса. Вопрос звучал не как «сделайте нам новую систему», а как «нам сложно управлять компетенциями в текущем виде, помогите». Это важный момент: мы в СИБУРе не создаем продукты ради самой разработки. Производство приходит к нам с проблемой или потребностью, а ИТ подключается как партнёр, который превращает методологию и практики бизнеса в работающий цифровой сервис.
Так появился проект «Инженерный стандарт» — разработка на стыке бизнеса и ИТ, цель которой была не просто автоматизировать Excel, а выстроить единый, масштабируемый и прозрачный процесс управления компетенциями.
Привет, Хабр! В прошлой статье я рассказывал о гибридных RFID метках и том, как мы решали проблему маркировки оборудования в локомотивном депо. Сегодня история побольше — как за 40 лет два поколения инженеров прошли путь от полного отсутствия диагностики электровозов до создания системы цифрового двойники и удаленного управления диагностическим оборудованием.
Я учусь на факультете, который продает студентов в компании партнеры. После окончания второго курса все обязаны пойти на круглогодичную стажировку. Я прошел десяток собеседований на позицию стажера системного аналитика, а через полгода уже сам проводил собеседование.
В статье пытаемся разобраться какой ключевой навык аналитика и как его можно проверять на собеседовании...
Привет, Хабр! Меня зовут Дарья Борисова, я системный аналитик в ПСБ.
Однажды я попробовала интеграции... и теперь они преследуют меня везде, как навязчивый мотив из песни.
Пришлось изучать и внедрять разные подходы, а заодно накопить вагон и маленькую тележку лайфхаков. Сегодня я работаю с Системой быстрых платежей в ПСБ — и готова поделиться тем, что спасло нас в критичных ситуациях.
Почти наверняка вы бывали в ситуациях, когда всё выпустили в прод, а сервер нагрузку не тянет. Или бизнес давит сроками, а времени на идеальные решения нет. Приходится подставлять костыли и ставить быстрые заплатки. Вопрос в том, могут ли они стать надежным решением? И какие компромиссы придется принять — об этом и поговорим.
А точнее: об оптимизации REST API в бою: как снизить количество запросов без потери данных, где проводить расчеты (и чем это грозит), зачем стандартизировать ответы, как кешировать с умом и почему health-check — это не просто «жив/мертв».
История о том, как очередная «быстрая костыль-интеграция» на коленке неожиданно превратилась в почти полноценную Order Management System (OMS) с элементами event-driven архитектуры. Всё это — без предварительного проектирования и без единой строчки кода на Java/Scala/Python (хотя тут немного лукавства, так как пару скриптов на Groovy все-таки имеется), на чистом Apache NiFi и SQLite.
Девизом этого проекта мог бы стать слоган: «Мы не ищем лёгких путей, мы ищем работающие решения». Я инженер в одной ритейл компании, который любит решать задачи, и сегодня расскажу, как закрыл боль бизнеса малой кровью, используя не совсем типичный для веб-сервисов инструмент.
Вот здесь можно посмотреть исходники
Архитектура — основа любого IT-продукта. Для ее создания нужно видеть систему целиком, понимать требования бизнеса и учитывать бюджет. Но вот проблема: научиться думать как архитектор непросто. Нужно держать в голове десятки взаимосвязей и находить решения, которые будут жить годами.
Меня зовут Арина Николаева, я занимаюсь развитием архитектурного сообщества в MWS. Вместе с коллегами мы придумали Arch Kata — игру, которая позволяет попробовать свои силы: участники должны решить сложный бизнес-кейс, а наши эксперты оценят проект и объяснят, что в нем хорошо или не очень.
Сегодня расскажу, откуда взялась Arch Kata, чем она отличается от привычного хакатона, как проходит и почему в ней стоит участвовать не только архитекторам, но и разработчикам, аналитикам и менеджерам. А в конце покажу пример, который мы давали участникам последней игры.
Серия: Чем болен средний бизнес? Статья 5.LLM + ДРАКОН: доступный инструмент процессного управления для МСБ
Классические BPM-проекты дороги, сложны и часто проваливаются в МСБ. Вы получаете схемы, которые никто не понимает, и зависимость от консультантов, а хаос остается.
В этой статье мы разбираем прагматичный подход, доступный уже сегодня:
LLM как аналитик: Используем нейросети для быстрого анализа «цифровых следов» процесса (почта, CRM, логи) и выявления узких мест.
ДРАКОН как интерфейс: Превращаем выводы LLM в наглядные и понятные схемы, которые может прочитать любой сотрудник, а не только IT‑специалист.
Человек как архитектор: Показываем, как на основе этих данных принимать управленческие решения и моделировать улучшения.
Внутри - пошаговый разбор смоделированного кейса по оптимизации процесса согласования счетов, расчет ROI и дорожная карта внедрения. Никакой магии, только методология и здравый смысл.
[Искусственный интеллект*] [Управление процессами*] [Визуализация данных*] [МСБ*]
