Изначально хотел написать каждый пост для отдельного задания в инфре, но некоторые задания настолько короткие, что писать там даже особо нечего, тем более подсказки в буткемпе очень сильно облегчают решение.
Начнем с первой инфры.
Если в вашем доме система резервного питания или альтернативной энергии собрана на компонентах Xantrex/Schneider Electric, то эта статья может быть полезна. Собственно, у меня как раз инвертор Xantrex XW 6048, панель управления Conext SCP, солнечный контроллер Conext MPPT 60 150. И всё это связано проприетарной сетью Xanbus. Система работает с 2010 года, солнечный контроллер с 2014г. В 2016г. я начал заниматься умным домом и возникла потребность получения электрических параметров системы для контроля и использования в алгоритмах. Например, для ограничения мощности электрического котла при наличии других потребителей. Часть этих правил описана здесь, но с тех пор их стало больше и они стали сложнее. На сайте производителя к моменту написания этой статьи ссылки на использованный мною Conext ComBox, я найти уже не смог, но изображение этого устройства — на заставке к статье, причем это реальная фотография моей установки.
В 2024г. ComBox перестал работать без объяснения причин. Оживить его известными способами не получилось. Нового такого же на рынке в России ни у кого в наличии по понятным причинам не оказалось, несмотря даже на вывешенные цены. Покупка по параллельному импорту оказалась такой дорогой, что проще отказаться от умного дома :). Однако, без электрических параметров DIY-энтузиасту и любителю умных домов жить совершенно некомфортно.
Пришлось идти по пути сбора электрических параметров с помощью внешних датчиков. Плюс такого решения как минимум в том, что оно переносимо на любое другое оборудование, так как не зависит ни от Xanbus ни от конкретных реализаций Modbus протокола других производителей. И, к тому же, может использоваться для сравнения показаний встроенных датчиков и внешних, если, конечно, к ним будет доступ.
Привет, Хабр! Меня зовут Владимир и я стал немного более GPU-rich. А это значит, что пора сдуть пыль со старого проекта)
В этой части статьи мы создадим необходимую инфраструктуру, напишем простого агента, а также добавим нашему агенту MCP-инструменты.
Дело моё — программы писать, а сходиться им положено с мастеровой грамотой: ГОСТами, СТО, спецификациями. Хочу спросить оракула в писарне про точный пункт — получаю складную околесицу со ссылками на то, чего никто не писал. Тогда я сложил себе doc-rag: местную снасть для извлечения премудрости из собственных свитков. Внутри — устройство, грабли, история про утраченный указатель и попытка рассказать всё это без единого заморского слова.
Как правило, у продуктовых команд нет дефицита идей. Проблема обычно в другом: идей слишком много, они приходят из разных источников, не связаны между собой, дублируются и в какой-то момент превращаются в огромную «свалку» предложений и заметок. Команда при этом ощущает, что работает напряжённо, постоянно что-то обсуждает, проводит встречи, рисует схемы и обновляет бэклог, но число действительно сильных продуктовых решений от этого не растёт.
Снаружи это часто выглядит как вполне нормальная «творческая кухня». Кто-то сообщает инсайт после интервью с пользователем. Кто-то вдохновляется недавним обновлением продукта конкурента. Кто-то предлагает срочно внедрить искусственный интеллект, потому что «тогда можно обходиться без CustDev’а, получать готовые гипотезы за секунды и вообще все уже делают это». Кто-то пересылает обратную связь от продаж, очередной отчёт от клиентского сервиса или поступает новая вводная от топ-менеджмента. Проблема начинается позже, когда становится трудно ответить на простые вопросы: какие следующие идеи брать в работу первыми, какие из них принесут наилучший эффект, какие уже неактуальны, и как ускорить обработку и воплощение идей в продуктах. Если же поток инсайтов и рацпредложений превышает возможности продуктовой команды с ними разбираться, то к списку вопросов добавляются – какие идеи вообще были в работе, какие из них проверяли и какой это дало результат, что было отложено, что отклонено и почему. При этом бэклог разрастается, потому у продактов просто нет времени с этим разбираться – надо успевать закрывать срочные задачи.
Функциональный архитектор 1С — это не «аналитик посильнее» и не человек, который просто рисует красивые схемы. Это специалист, который держит в голове бизнес, ограничения платформы, логику процессов, риски внедрения и границы проекта.
Разбираемся, чем на самом деле занимается архитектор 1С, кому стоит идти в эту роль и почему на крупных проектах без него быстро начинается хаос.
Продолжаем серию про redb.Route — вводная и разбор четырёх in-memory каналов уже вышли. Сегодня не статья серии, а релизная заметка: в 3.0.1 три конкретных изменения в DSL, каждое с боевым примером из демо.
До 3.0.1 глубоко вложенные scope-ы требовали закрывать себя в строго обратном порядке — утомительно и легко ошибиться. Три вещи изменились.
Я всё чаще ловлю себя на том, что задаю вопрос непосредственно LLM, отказавшись от долгого поиска в интернете, изучения профильных форумов, отзывов и претензий. С одной стороны это гораздо быстрее, ответы выглядят логично, и гораздо легче согласиться с нейросетью, чем тратить силы и время. Но с другой стороны, насколько хорош совет модели? Почему это выбрала нейросеть, и как выбрала? Этим вопросом мало кто задаётся, поэтому я решил навскидку оценить экспертность решения.
Сценарий эксперимента: я выступаю в роли it-фрилансера и мне нужно выбрать облачный провайдер, который лучше всего подходит для маленького проекта. Опрошены основные бренды LLM с доступом к поиску.
На примере 1С:ТОИР
EAM-система давно перестала быть «программой для ремонтников». Для промышленного, энергетического, транспортного или инфраструктурного предприятия это один из ключевых цифровых контуров управления физическими активами. Именно здесь сходятся данные о составе оборудования, нормативы обслуживания, история отказов и дефектов, планы ТОиР, потребность в материалах и трудовых ресурсах, данные о состоянии объектов и управленческая аналитика. В терминах ISO 55000 управление активами — это системный подход к извлечению ценности из активов на всем их жизненном цикле. EAM в этой модели становится практическим инструментом, который переводит стратегию управления активами в процессы, роли, данные и измеримые результаты.
Для российского рынка один из наиболее показательных примеров такого класса решений — 1С:ТОИР. В официальном каталоге 1С решение прямо отнесено к классу EAM/CMM и позиционируется как система управления ремонтами и обслуживанием материальных активов. В составе поддерживаются учет оборудования и нормативов, эксплуатационные показатели, планирование ТОиР, МТО, управление персоналом, нарядная система, документация, KPI, мобильные сценарии и интеграции с ERP, кадровыми и производственными системами. Именно поэтому 1С:ТОИР удобно использовать как референсную модель для разговора не о конкретном продукте, а об архитектуре современной EAM-системы как класса.
Большинство современных архитектурных подходов учат нас строить всё больше слоёв абстракции: контроллеры, сервисы, репозитории, адаптеры, транспортеры… Но что, если сложность системы растёт не из-за предметной области, а из-за самой архитектуры?
В этой статье я представляю FASA (Flat Adaptive Software ARchitecture) — спецификацию, которая предлагает радикально простой ответ: всего три сущности, строгие правила зависимостей и никаких промежуточных слоёв.
Вы узнаете, почему «плоский» граф компонентов может быть устойчивее многослойной архитектуры, как версионировать интерфейсы без боли, используя правило двойной поддержки (N-1) и где проходит граница между семантикой приложения и инфраструктурой — и почему это важно.
Спецификация языково-независима: примеры приведены для разных контекстов (Rust, сетевые протоколы, IPC), но правила применимы в любом стеке.
Вводные данные:
— Имеются довольно старые, но до сих весьма высокотехнологичные умные часы — Garmin Fenix 6 Pro Solar, работающие на проприетарной системе компании Garmin.
— Умные интернет‑розетки от Xiaomi Smart Plug 2 Wi‑Fi.
Появилась задача, а скорее просто очередное дико зудящее желание в стиле «кулибинство» — управлять такими розетками (хотя бы удаленно включать и выключать их) прямо с указанных часов.
Желание есть, начинаю изучать задачу. И решать её, как это у меня обычно происходит, нестандартным путем.
Для начала выясняю, как вообще реализовано управление данными интернет‑розетками Xiaomi? Умные устройства Xiaomi преимущественно управляются через фирменное приложение Xiaomi Home, которое отлично работает, например, в OS Android. Приложение огромное по размеру, громоздкое, по сути — целый программный «комбайн» для управления огромным множеством умных устройств Xiaomi. Очень быстро становится понятно, что на часы Garmin никакого подобного приложения, или какого‑либо компактного форка нет и быть не может. Слишком уж скромные программные возможности у часов Garmin при работе с таким монструозным софтом!
И поэтому я решил пойти другим путём:
FFI, P/Invoke, EmbeddedResource, DllImportResolver и кроссплатформенная доставка без ручного копирования .dll, .so и .dylib.
Когда .NET-коду нужно вызвать Rust-библиотеку, первый прототип обычно заводится быстро:
Rust собирается как cdylib;
функции экспортируются через extern "C";
C# вызывает их через DllImport;
результат возвращается через указатель.
Передача АV-сигналов на основе технологии AVoIP (Audio Video over IP) постепенно вытесняет классическую коммутацию: маршрутизация по Ethernet более удобна и масштабируема по сравнению с матричной, ограниченной количеством портов коммутатора. Однако помимо озвученных преимуществ она наследует уязвимости IP-сетей.
Согласно данным AVIXA(Ассоциация Аудиовизуального и Интеграционного Опыта), инциденты в AVoIP инфраструктуре, связанные с сетевой безопасностью, происходят по весьма банальной причине: зачастую AV‑инженеры не считают себя сетевыми специалистами, а IT‑отдел не контролирует AV‑сегмент.
В этой статье разберем, чем обоснован переход от классической матричной коммутации на AVoIP, узнаем причины возникновения и ключевые уязвимости, а также основные методы защиты.
В последнее время слышны активные разговоры о том, что самозанятые айтишники и целые компании переезжают в Минск. Логика такого поведения очевидна: в соседнем дружественном государстве нет ограничений интернета, почти все западные сервисы в свободном доступе, банковские карты Visa и оплата услуг работают без санкционных барьеров. Казалось бы, идеальный хаб для релокации.
Мегаплан открыл офис в Минске в 2012 году, и, как показывает наш опыт, есть определённые моменты, которые необходимо учесть. Особенности, с которыми мы столкнулись тогда и в последние годы, могут коснуться каждого, кто сегодня рассматривает белорусскую столицу как точку расширения.
Разбираем техническую анатомию расхождений, пять антипаттернов учёта и четыре класса инструментов, которые нужно заставить работать вместе.
На складе производителя стройматериалов под погрузку приходят десятки фур в день: габариты фиксированные, машины разные. Часть фур приезжает с кривым кузовом: занижена высота к кабине, неровные борта, наваренные крючки и кронштейны на стойках у дверей. Внутрь такой кузов выглядит нормально, пока в него не заедет погрузчик с паллетой шириной 2,40 м и не упрётся в выступ, которого там быть не должно.
Цена ошибки — повреждённый груз, развёрнутая на КПП машина, простой ворот и сорванный график отгрузки. Для исключения таких ошибок, было принято решение об инспекции фуры человеком: кто‑то заглядывает в кузов и по визуальному осмотру решает, грузить фуру или разворачивать. Это медленно, субъективно и не масштабируется — а отказы по геометрии кузова составляют заметную долю разворотов.
Задача, которая стояла перед командой: автоматизировать этот осмотр. Убрать человека из точки принятия решения и выдавать вердикт «грузить / не грузить» по объективным числам, а не по взгляду грузчика.
Требования заказчика сразу задали высокую планку. Нужно мерить три габарита: ширину свободного прохода, высоту от пола до горизонтальной балки, длину — и находить посторонние предметы внутри кузова. Пороги жёсткие: ширина меньше 2,43 м — отказ, высота меньше 2,60 м — отказ, длина меньше 8 м — отказ. Зазор между «входит» и «не входит» — 2 см: паллета шириной 2,40 м идёт впритык, и выступающий на стойке крючок, съедающий эти 2 см, делает кузов непригодным. То есть мерить надо с точностью лучше сантиметра — и не у ворот, а на всей глубине кузова, до 15 м от точки установки.
Иногда мне кажется, что домашние животные — что-то вроде великого уравнителя. Сеньор вы, стажер или даже CEO — в моменты удаленной работы это становится неважно. Ведь если в доме обитает кто-то шерстяной, мы одинаково обезоружены перед огромной силой жалобного взгляда и раскинутых лапок.
Привет! Я Лиза, редактор в МТС Web Services. Уже больше пяти лет работаю с котом из дома, и, признаюсь, этот все обрастающий историями опыт скрывает под собой неоднозначные эмоции и переживания, временами ставит под сомнение мои собственные представления о себе, а еще порождает внутренние дискуссии на философские вопросы. Например, о личных границах, воле и возможности мирного урегулирования прав на домашнюю территорию.
Чтобы наконец внести хоть какую-то ясность в ситуацию и проверить подозрения (а так ли у всех?), я пошла с вопросами к коллегам. У нас как раз есть внутренне сообщество, в котором мы делимся фотографиями питомцев, обсуждаем лайфхаки, а еще делаем полезное: ищем для них новый дом и помогаем приютам. Так что участники охотно и честно поделились личными историями.
Привет, Хабр!
Меня зовут Сергей Волков, я фронтенд-разработчик в компании VK. Мы используем MobX для работы с реактивными значениями в веб-приложениях, поэтому я хочу познакомить вас с этим инструментом и показать, почему на него стоит обратить внимание.
В этой статье я хочу поделиться своими мыслями о MobX - инструменте, который я искренне полюбил после многих лет разработки интерфейсов. Приятного чтения! :)
Ресторанная сеть из 10 заведений обратилась с первичным запросом на доработку Telegram Mini App. В процессе стало понятно, что задача шире: компании нужен не отдельный подрядчик под приложение, а внешний продуктово-технический контур, который сможет развивать несколько цифровых продуктов, поддерживать инфраструктуру, закрывать интеграции и сопровождать эксплуатацию.
За 7 месяцев работы были запущены 6 продуктов:
Полгода разработки, десятки миллионов бюджета, команды аналитиков, разработчиков и архитекторов. А потом заказчик за две недели показывает прототип похожей системы, собранный на вайбкоде за несколько сотен долларов. Кажется, мы начинаем жить в моменте, когда стоимость проверки идей и визуализации бизнес-процессов резко падает. И это может изменить энтерпрайз сильнее, чем кажется.