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

Продолжаю радиолюбительскую тему.

Китайская компания Xiegu предлагает радиолюбителям не только трансиверы, но и два весьма годных усилителя с выходной мощностью 100 Вт для совместного использования с портативными QRP аппаратами. Конечно же, они в основном предназначены для работы с трансиверами Xiegu — G90, X6100 и X6200. Но эти усилители популярны и среди пользователей других QRP трансиверов, например, IC-705. И тут возникает проблема несовместимости ALC, заставляющей внимательно следить за уровнем мощности, подаваемым на усилитель. Другой момент связан с использованием внешнего автоматического тюнера: если стационарные трансиверы Icom автоматически снижают мощность до нескольких ватт при настройке тюнера, тюнер, подключенный к IC-705 и усилителю, требует внимательности: перед настройкой нужно нажать на усилителе кнопку BYPASS (BYP), и если этого не сделать, сжечь можно и тюнер, и выходной каскад усилителя. Предлагаемое устройство решает обе эти проблемы.

Привет, Хабр, меня зовут Денис Власов, я руковожу службой внешних сайтов холдинга. Несколько месяцев назад я поймал себя на странном ощущении посреди разговора с большой языковой моделью (LLM). Я объяснял ей задачу — подробно, с контекстом и примерами. Модель ответила развёрнуто и по делу. Я написал ещё. Она снова ответила. Мы «общались» уже минут двадцать, и в какой‑то момент я остановился и подумал: «А она вообще поняла, что я имею в виду? Или просто очень убедительно имитирует понимание?»

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

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

Это раздражение, не экзистенциальное, а вполне практическое, и стало отправной точкой. Так я пришёл к идее создания RFC-протокола «Треть». Это моя попытка сделать пространство диалога немного более прозрачным.

В первой части материала мы разобрали, что необходимо контролировать в корпоративном хранилище данных - от инфраструктуры и ETL/ELT-процессов до Data Quality и выполнения запросов:

Мониторинг и логирование DWH, часть 1: уровни контроля, метрики и типовые проблемы

Во второй части перейдем к конкретным инструментам: Prometheus, Grafana, Zabbix, ELK Stack, OpenSearch, Loki. Разберем, как они устроены, какие задачи решают, чем отличаются друг от друга и на что обратить внимание при выборе стека для мониторинга и логирования DWH.

Хайп вокруг ИИ заставляет компании искать «серебряную пулю». Но как только проект доходит до этапа реализации, он разбивается о классические 6 слоев сопротивления Голдратта (Теория ограничений).

Для бизнес-аналитика понимание этих слоев — это не психология, а маршрут с критическими точками. Разберем их суть на примере внедрения ИИ в бизнес-процессы.

Привет, Хабр! Меня зовут Никита Ивкин, я — ведущий DevOps-инженер РТЛабс, работаю с инфраструктурой Госуслуг. Сегодня я покажу один из наших реальных сценариев: как мы разворачиваем ClickHouse через Arenadata, почему выбрали именно такую топологию и какие нюансы появляются между кнопкой Install и действительно рабочим кластером. Мы разберём причины выбора такой схемы, увидим, где ADCM действительно упрощает эксплуатацию, какие мелочи всплывают вокруг SSH и Ansible и почему после успешного Install хост всё ещё может выглядеть «жёлтым». В конце — проверки со стороны самого ClickHouse и несколько вещей, которыми мы дополнили кластер уже после раскатки.

T-Shape часто понимают как универсала, который умеет понемногу всё и может закрывать несколько ролей. Но исходная модель устроена иначе: в центре остаётся глубокая экспертиза, а вокруг неё растёт понимание смежных областей.

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

За последний год я проверил около двадцати торговых идей. Каждая сначала выглядела убедительно: приличная t-статистика, гладкая кривая доходности, понятная история. И каждая умерла на конкретной проверке. В этой статье собраны эти проверки с реальными цифрами «до» и «после».

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

Привет, постоянные и не очень читатели!

В первой части цикла я разобрал технологию DLSS во всех её версиях — с предпосылками и историей появления, байками и мемами про Хуанга и даже применением в бизнес-приложениях (чиво?). Материал вышел огромным, и, вероятно, самым подробным про DLSS в Рунете. Почитать можно здесь: «Судный день грядёт [часть 1]: глобальный разбор апскейлера DLSS — от игр к работе»

Теперь пора обозреть пролетарскую FSR (FidelityFX Super Resolution) — технологию улучшения изображения от AMD, которая, по моему мнению, превосходит DLSS от NVIDIA. Почему? Расскажу в конце статьи.

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

В этой статье я расскажу про источники радиации и средства её измерения. В практической части статьи будет описана погодная станция, способная измерять не только температуру, давление и влажность, но и уровень радиационного фона.

На связи Анна Астахова, директор по развитию ИТ-интегратора «Белый код». Расскажу, как мы перенесли 197 интеграционных потоков крупного девелопера на DATAREON Platform без остановки рабочих систем — и почему за задачей «перенести работающие обмены» скрывалась ревизия дублирующегося кода, забытых механизмов синхронизации и накопленной бизнес-логики.

Всем привет! Меня зовут Магомед, я инженер поддержки в команде Контента в Банки.ру. За 4 месяца я собрал на n8n несколько автоматизаций. Часть из них дежурит вместе со мной: утренний дайджест по состоянию сервисов, сторож аномалий после релизов и ИИ-агент, который знает наши сервисы, работает с Jira и умеет оценивать задачи. Другая часть работает на авторов контента: уведомляет о комментариях и просмотрах и проверяет, подходят ли к материалу прикреплённые виджеты.

В этой статье я не буду уходить в детали устройства воркфлоу: схем из n8n, промптов и разбора нод здесь не будет. Хочу показать, как конкретно я, инженер поддержки, применяю ИИ в ежедневной работе. Если захочется подробностей по какому-то из ботов, спрашивайте в комментариях, расскажу.

Привет, Хабр! Меня зовут Александр Шевченко, я техлид команды ASR ML (направление ASR/TTS-платформы Audiogram) в MWS AI. Мы занимаемся совершенствованием технологий распознаванием речи. Сегодня выкладываем в открытый доступ сразу два инструмента, которые выросли из нашей внутренней кухни за последний год: RESON (Research Engine for Speech & Observation Notes) — инструмент для анализа качества ASR-моделей, RESON OSD — открытый бенч для моделей распознавания русскоязычной речи.

Описание и ссылки — под катом.

Привет, Хабр! Меня зовут Александр Шевченко, я техлид команды ASR ML (направление ASR/TTS-платформы Audiogram) в MWS AI. Мы занимаемся совершенствованием технологий распознаванием речи. Сегодня выкладываем в открытый доступ сразу два инструмента, которые выросли из нашей внутренней кухни за последний год: RESON (Research Engine for Speech & Observation Notes) — инструмент для анализа качества ASR-моделей, RESON OSD — открытый бенч для моделей распознавания русскоязычной речи.

Описание и ссылки — под катом.

История эта началась два года назад, когда подписчики моего канала начали регулярно и настойчиво интересоваться, когда же в «Селените появится режим автономной обработки сигналов». Базовый блок трансивера получился достаточно компактным, 100х62х23 без выступающих частей, и желание пользователей «отвязать» его от компьютера, где как раз и производилась обработка сигнала, было вполне резонным.

Cloud Tracing — сервис распределённой трассировки в VK Cloud. Приложения отправляют в него спаны по протоколу OpenTelemetry, сервис хранит их и отдаёт через Jaeger-совместимое API. Поэтому трейсы можно открывать в привычных Jaeger UI и Grafana без доработок.

За этой совместимостью стоит выбор хранилища, который для публичного облака оказывается сложнее, чем кажется. Сервис принимает поток спанов от сотен несвязанных клиентов, хранит десятки терабайт телеметрии и должен надёжно изолировать данные проектов друг от друга. По умолчанию один проект может отправлять до 1 МБ/с, а доступ к данным контролируется токенами IAM. При таких ограничениях недостаточно просто выбрать базу, которая быстро записывает спаны или умеет находить трейс по trace ID.

На странице развёртывания Jaeger на момент проектирования сервиса были перечислены шесть вариантов: Cassandra, Elasticsearch, Kafka, gRPC-плагин, Badger и memory. На первый взгляд это полноценный список кандидатов. Но локальные хранилища отпадают для прода, Kafka оказывается буфером перед настоящим хранилищем, а gRPC-плагин служит способом подключить систему, которой в списке нет. В результате сравнивать приходится Cassandra и Elasticsearch, а через плагин появляется третий вариант — ClickHouse.

Я Леонид Левин, архитектор PaaS в VK Cloud. Этот разбор мы подготовили вместе с технологическим евангелистом Стасом Погоржельским и инженерами сервиса. Мы разберём, почему Cassandra и Elasticsearch по-разному подходят для хранения трейсов, что дали чужие продовые кейсы и наши замеры до 362 тысяч спанов в секунду на четырёх ядрах коллектора, а также как схема хранения на ClickHouse закрыла точечное чтение и поиск по атрибутам.

Cloud Tracing — сервис распределённой трассировки в VK Cloud. Приложения отправляют в него спаны по протоколу OpenTelemetry, сервис хранит их и отдаёт через Jaeger-совместимое API. Поэтому трейсы можно открывать в привычных Jaeger UI и Grafana без доработок.

За этой совместимостью стоит выбор хранилища, который для публичного облака оказывается сложнее, чем кажется. Сервис принимает поток спанов от сотен несвязанных клиентов, хранит десятки терабайт телеметрии и должен надёжно изолировать данные проектов друг от друга. По умолчанию один проект может отправлять до 1 МБ/с, а доступ к данным контролируется токенами IAM. При таких ограничениях недостаточно просто выбрать базу, которая быстро записывает спаны или умеет находить трейс по trace ID.

На странице развёртывания Jaeger на момент проектирования сервиса были перечислены шесть вариантов: Cassandra, Elasticsearch, Kafka, gRPC-плагин, Badger и memory. На первый взгляд это полноценный список кандидатов. Но локальные хранилища отпадают для прода, Kafka оказывается буфером перед настоящим хранилищем, а gRPC-плагин служит способом подключить систему, которой в списке нет. В результате сравнивать приходится Cassandra и Elasticsearch, а через плагин появляется третий вариант — ClickHouse.

Я Леонид Левин, архитектор PaaS в VK Cloud. Этот разбор мы подготовили вместе с технологическим евангелистом Стасом Погоржельским и инженерами сервиса. Мы разберём, почему Cassandra и Elasticsearch по-разному подходят для хранения трейсов, что дали чужие продовые кейсы и наши замеры до 362 тысяч спанов в секунду на четырёх ядрах коллектора, а также как схема хранения на ClickHouse закрыла точечное чтение и поиск по атрибутам.

Привет, Хабр! Меня зовут Максим Шуматбаев, я инженер технической поддержки в Arenadata. Это вторая часть разбора, что на самом деле происходит при работе клиентских приложений с Kafka-кластером. В первой части мы проследили запись от получения метаданных до транзакций и exactly-once. Теперь очередь второй половины пути: как потребитель получает данные, делит партиции с другими участниками группы, фиксирует прогресс и почему иногда начинает отставать.

Старший фронтенд-разработчик Mindbox Игорь Уваров рассказывает, как делегировал агенту исследование задачи. Теперь агент изучает документацию и код в репозиториях, ищет зависимости и ограничения, а затем приносит вопросы к грумингу. Внутри — история о том, как создавался плагин, который заменил системного аналитика.

Грамотно написанные YARA-правила обеспечивают высокую скорость и точность сканирования. Однако при неправильном подходе этот полезный инструмент «легким движением руки» превращается в пожирателя CPU, особенно когда сигнатуры исчисляются десятками, а количество файлов для анализа — миллионами.

В статье приведем полезные лайфхаки, которые помогут оптимизировать правила, сократить избыточные вычисления и избежать распространенных ошибок. Для подготовки данного гайда мы использовали материалы, размещенные в открытом доступе на гитхабе. Рекомендации статьи применимы ко всем версиям YARA, начиная с 3.7 и выше. 

Всё еще пишете YARA-правила «на глазок»? Тогда мы идем к вам…

Как Splash ускоряет локальные языковые модели на Mac? Разбираем спекулятивное декодирование DFlash 2, результаты тестов разработчиков и ограничения движка. Объясняем, что учитывать при выборе Q4 или Q8, сколько памяти и места на диске потребуется и как запустить Splash на macOS.