Kurgan-Telecom Ru | Информационные технологии

В культурном сознании перфокарта плотно привязалась к эпохе огромных компьютеров, лабиринтообразных НИИ и прото-программистов в толстых роговых очках, задумчиво смолящих папиросы перед монолитными манипуляторами ЭВМ.

Но история ее началась гораздо раньше и в итоге привела к появлению первой поисковой системы и, наверно, первого аналогового компьютера в то время, когда люди еще щипали у гусей перья для письма.

Изначально хотел написать каждый пост для отдельного задания в инфре, но некоторые задания настолько короткие, что писать там даже особо нечего, тем более подсказки в буткемпе очень сильно облегчают решение.

Начнем с первой инфры.

Midjourney — одна из самых известных нейросетей для создания изображений по текстовому описанию. С ее помощью можно генерировать реалистичные фото, иллюстрации, концепты персонажей, идеи для дизайна и картинки почти под любую задачу. Пользователь пишет, что хочет увидеть, а нейросеть превращает этот запрос в готовое изображение. 

Миджорни нейросеть особенно ценят за выразительный стиль. Картинки часто получаются атмосферными, кинематографичными и визуально «дорогими» уже с первых генераций. Поэтому сервис используют не только художники и дизайнеры, но и маркетологи, предприниматели, авторы контента и обычные пользователи, которым нужно быстро получить сильную визуальную идею без сложной работы в графических редакторах.

Если в вашем доме система резервного питания или альтернативной энергии собрана на компонентах 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: местную снасть для извлечения премудрости из собственных свитков. Внутри — устройство, грабли, история про утраченный указатель и попытка рассказать всё это без единого заморского слова.

Готова версия эмулятора ZX Spectrum Glukalka версии 3.1 для десктопа. Новое в этой версии:

• Полная функциональность на всех версиях Qt 4-6 (работает загрузка игр с веба).
• Восстановлена работоспособность в режиме OpenGL.
• Улучшен алгоритм разбиения на файлы при дампе музыки.
• Звук воспроизводится через OpenAL (Mac), QtMultimedia (при наличии плагина), и Alsa (Linux).
• Мелкие фиксы и улучшения, фиксы Big Engian.
• Бинарные сборки для Windows (32 и 64 бит), Linux (build system - ASTRA 1.7.5, Qt5), MacOS (Intel и ARM64).

Для чего нужен эмулятор ZX Spectrum в 2026-м году? Чтобы вынимать из ПО музыку для последующего прослушивания.

На первом скриншоте — запущенный на эмуляторе плеер для трекерной и конвертированной музыки. Это Solaris 10, Sparc. Помимо оригинальной и всем известной музыки для классических игр, для ZX Spectrum написано очень много оригинальных треков и каверов в формате популярных трекеров. Искать такие сборники можно по запросам вроде «ZX-Spectrum music collection». Хотя звук в эмуляторе не претендует на прецизионное звучание, он неплох. Да и нет никакого эталонного звучания, все чипы и схемы звучат по-разному.

Иногда на эмуляторе ещё можно играть. На втором скриншоте запущена игра Videopool, одна из немногих всё ещё играбельных на сегодня. ОС — Astra 1.7.5, удалённая работа. Эмулятор работоспособен и интерактивен при удалённой работе через ssh -X.

Программа работает на широком диапазоне платформ Windows, Mac, Linux. Требуется библиотека Qt версий 4-6. 32, 64 бит. В разумных пределах, он не требователен к аппаратному обеспечению. На компьютерах с частотой примерно от 1000 Mhz, он работоспособен без ограничений и потери производительности.

Желающим собрать эмулятор из исходников, может понадобиться библиотека libasound2, и расширения Qt — opengl, network, multimedia. Не очень разбирающимся в специфике ZX-Spectrum и его эмуляции, но желающим попробовать, совет загружать игры в формате Z80 — он максимально беспроблемен.

 glukalka, zx spectrum, от автора, эмулятор

27 мая состоялся выпуск 2.93.0 консольной утилиты GitHub CLI, предназначенной для работы с репозиториями GitHub.

Утилита написана на языке Go и распространяется по лицензии MIT.

Основные изменения

• Безопасность

  • Обнаружена и устранена уязвимость безопасности, при которой в запросах API к зеркалам репозитория TUF с помощью команд gh attestation, gh release verify и gh release verify-asset некорректно включался заголовок авторизации. Пользователям рекомендуется как можно скорее обновить gh до версии 2.93.0.

• Поддержка «ИИ»-агентов в наборе команд gh secret. Подробнее: «Configuring secrets and variables for Copilot cloud agent».

• Другие улучшения и исправления ошибок.

А 30 мая состоялся выпуск консольной утилиты GCLI, поддерживающей API нескольких популярных сервисов хостинга Git-проектов, и позволяет создавать, просматривать и взаимодействовать с проблемами, запросами на слияние, метками и комментариями к ним, проверять состояние CI и конвейеров, и многое другое.
В отличие от GitHub CLI, GCLI поддерживает не только API GitHub, но и API Codeberg, Forgejo, Gitea, GitLab и Bugzilla.

Утилита написана на языке C и распространяется по лицензии BSD-2.

( читать дальше... )

 gcli, gh, github, gitlab, утилита

Как правило, у продуктовых команд нет дефицита идей. Проблема обычно в другом: идей слишком много, они приходят из разных источников, не связаны между собой, дублируются и в какой-то момент превращаются в огромную «свалку» предложений и заметок. Команда при этом ощущает, что работает напряжённо, постоянно что-то обсуждает, проводит встречи, рисует схемы и обновляет бэклог, но число действительно сильных продуктовых решений от этого не растёт.

Снаружи это часто выглядит как вполне нормальная «творческая кухня». Кто-то сообщает инсайт после интервью с пользователем. Кто-то вдохновляется недавним обновлением продукта конкурента. Кто-то предлагает срочно внедрить искусственный интеллект, потому что «тогда можно обходиться без 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), но правила применимы в любом стеке.

Представьте: вас уволили с работы. Причина в приказе: «Вы нарушили правила компании». Вы спрашиваете: «Какие именно? Что я сделал?» Ответ: «Не скажем. Внутренняя информация. Обжалованию не подлежит».

Абсурд? Да. Но в цифровой среде это давно стало нормой. YouTube, ВК, Telegram, профильные форумы, магазины приложений — все они блокируют аккаунты, каналы и софт с одной дежурной формулировкой: «Нарушение правил сообщества». Каких? Где? Когда? В ответ — тишина.

Чем это опасно:

Вводные данные:

а) Имеются довольно старые, но до сих весьма высокотехнологичные умные часы - 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;

результат возвращается через указатель.

В последнее время слышны активные разговоры о том, что самозанятые айтишники и целые компании переезжают в Минск. Логика такого поведения очевидна: в соседнем дружественном государстве нет ограничений интернета, почти все западные сервисы в свободном доступе, банковские карты Visa и оплата услуг работают без санкционных барьеров. Казалось бы, идеальный хаб для релокации. 

Мегаплан открыл офис в Минске в 2012 году, и, как показывает наш опыт, есть определённые моменты, которые необходимо учесть. Особенности, с которыми мы столкнулись тогда и в последние годы, могут коснуться каждого, кто сегодня рассматривает белорусскую столицу как точку расширения.

Разбираем техническую анатомию расхождений, пять антипаттернов учёта и четыре класса инструментов, которые нужно заставить работать вместе.

На складе производителя стройматериалов под погрузку приходят десятки фур в день: габариты фиксированные, машины разные. Часть фур приезжает с кривым кузовом: занижена высота к кабине, неровные борта, наваренные крючки и кронштейны на стойках у дверей. Внутрь такой кузов выглядит нормально, пока в него не заедет погрузчик с паллетой шириной 2,40 м и не упрётся в выступ, которого там быть не должно.

Цена ошибки — повреждённый груз, развёрнутая на КПП машина, простой ворот и сорванный график отгрузки. Для исключения таких ошибок, было принято решение об инспекции фуры человеком: кто-то заглядывает в кузов и по визуальному осмотру решает, грузить фуру или разворачивать. Это медленно, субъективно и не масштабируется — а отказы по геометрии кузова составляют заметную долю разворотов.

Задача, которая стояла перед командой: автоматизировать этот осмотр. Убрать человека из точки принятия решения и выдавать вердикт «грузить / не грузить» по объективным числам, а не по взгляду грузчика.

Требования заказчика сразу задали высокую планку. Нужно мерить три габарита: ширину свободного прохода, высоту от пола до горизонтальной балки, длину — и находить посторонние предметы внутри кузова. Пороги жёсткие: ширина меньше 2,43 м — отказ, высота меньше 2,60 м — отказ, длина меньше 8 м — отказ. Зазор между «входит» и «не входит» — 2 см: паллета шириной 2,40 м идёт впритык, и выступающий на стойке крючок, съедающий эти 2 см, делает кузов непригодным. То есть мерить надо с точностью лучше сантиметра — и не у ворот, а на всей глубине кузова, до 15 м от точки установки.