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

В современной фронтенд-разработке реактивность стала стандартом дефакто. Мы привыкли к ней в Vue, React (если через хуки/стейт - здесь появляется спорный момент), Angular (Signals) и RxJS. Однако тяжелые фреймворки не всегда уместны, если вам нужно построить чистую, легковесную бизнес-логику, абстрагированную от DOM-дерева.

Вот что я хочу Вам показать: https://www.npmjs.com/package/@pravosleva/reactive-engine

NPM-пакет @pravosleva/reactive-engine решает именно эту задачу, предоставляя разработчикам специализированный движок (Reactive Engine) для управления реактивными состояниями и автоматического вычисления зависимостей на чистом JavaScript / TypeScript.

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

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

В этой гонке побеждает не самый громкий. Побеждает самый понятный.

С момента создания блога, примерно половина запросов на платный контент, рекламу и продвижение, которые мне присылают — про ИИ.

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

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

Ракрываю тему.

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

Знаете это чувство, когда правишь JSON и ищешь, где же ты забыл запятую? Я устал и сделал редактор, где JSON — это таблица. А теперь он ещё и открывает папку проекта целиком: дерево файлов, Ctrl+S прямо в файл, drag & drop. Как в VS Code, только заточено под данные.

Я бизнес-аналитик. Обычно пишу функциональные требования, моделирую процессы и учу пользователей. Это стандартная работа аналитика в большой компании. А последние полгода я разбирался, как устроен бизнес тепличных помидоров и огурцов. Теперь знаю, чем медовый черри отличается от Помисольки, какие нормы выработки у агрономов в крупных теплицах и в чем поедет помидор от грядки до магазинной полки.

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

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

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

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

В прошлой части я рассказывал о файлах и их форматах, которые я получил после полногеномного секвенирования.

В этой статье поговорим о трактовке результатов секвенирования с помощью ИИ, опенсорсного инструмента Just-DNA-Lite, а также о пересборке генома.

Кто ходит в гости по утрам, тот поступает мудро. А кто ходит в гости в инженерный центр, становится еще мудрее. 16 июля встречаемся в офисе YADRO в Санкт-Петербурге, чтобы обсудить тестирование за рамками классического QA и побывать в инженерном центре, где создаются и тестируются энтерпрайз- и телеком-продукты.

Встреча пройдет без трансляции и записи докладов — только живое общение и максимальное погружение в тему. Эксперты расскажут о полевом тестировании базовой станции и особенностях тестирования «железа», а затем для гостей проведут экскурсию по лабораториям, ЦОД и инженерным пространствам.

Как мы провели проект через четыре «эпохи» — от ручных запусков на Windows‑планировщике до Spark + k8s на масштабе сети

Привет, Хабр! Меня зовут Имиль Валиуллин, я тимлид команды разработки платформы OSA. В предыдущих статьях цикла On Shelf Availability (OSA) уже разбирали с разных сторон: что такое OSA как продукт, как устроен алгоритм детекции аномалий и весь конвейер генерации сигналов — эвристики, ML‑модели, фильтры, обратная связь, A/B и оценка эффекта (ссылки на предыдущие статьи: 1, 2, 3). В этой статье мы раскрываем следующий слой — инженерный. Потому что всё перечисленное было бы невозможно без большой работы под капотом: данных, транспорта, оркестрации, SLA, мониторинга, качества данных, обратной связи, API и доставки сигналов в торговые точки. Многие забывают, что даже самая крутая ML‑модель — это только верхушка айсберга. Результат появляется только тогда, когда под ней есть надёжный фундамент: чистые данные, стабильный транспорт и бесперебойная доставка. Как говорится, garbage in — garbage out, и наоборот: качественный фундамент позволяет получить качественный результат.

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

Показать это мы хотим через эволюцию продукта — от legacy и ручных запусков до промышленной платформы, работающей на масштабе сети. С точки зрения пользователя это всё тот же продукт — сигналы на торговых точках (ТТ), помощь сотрудникам магазина, рост доступности товара. Но под капотом OSA прошёл несколько серьёзных инженерных перерождений, которые мы для удобства назвали «эпохами»: каменный век, бронзовый, железный и индустриальная эпоха. 

О карго‑культе аналитики, невидимых потерях и важном вопросе, который стоит задать до старта

1. Когда процесс есть, а смысла нет

Скорость давно перестала быть управленческим выбором — она стала условием контракта бизнеса с рынком. Отчетные циклы, давление на результат, внутренняя конкуренция за ресурс и внимание первых лиц сформировали среду, в которой «давайте сначала разберёмся» читается не как грамотная профессиональная позиция, а как прямое уклонение от распоряжения руководства.

Я не начинал с идеи написать «убийцу JavaScript». Честно говоря, такие заявления обычно только мешают думать.

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

Это нормально. Веб таким стал не случайно. Но мне было интересно проверить другую гипотезу: можно ли писать заметную часть браузерного приложения на Go, не превращая интерфейс в кашу из ручной сборки дерева узлов?

Так появился мой небольшой экспериментальный проект GoFrame. Сейчас это не готовый фреймворк для продакшена, а исследование в сторону Go‑first подхода для браузера через WebAssembly: маленький рантайм, JSX‑подобная разметка .gox, компиляция этой разметки в обычный Go‑код и утилита goxc, которая способна сгенерировать, собрать и упаковать приложение. В README проекта это прямо описано как экспериментальный Go‑first фреймворк и набор инструментов для интерактивных браузерных приложений на WebAssembly; там же честно указано, что проект не заявляет готовность к продакшену, стабильный API 1.0, SSR, гидратацию, серверные API, форматтер или LSP.

В этой статье я не хочу пересказывать ридми. Интереснее другое: как маленькая идея «а что если сделать JSX для Go?» довольно быстро потянула за собой компилятор, компонентную идентичность, состояния, эффекты, маршрутизацию, проверки в браузере и даже бюджет размера WebAssembly‑бандла.

В ключе цифровизации и оптимизации, в компании, возник вопрос — как сократить время на закупку материалов для производства и сократить ошибки? На данный момент в подразделении разработки изделий эксплуатируется связка CREO+Windchill (замена пока не рассматривается), а в закупках трудится 1С. Компания работает в области машиностроения.

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

В марте состоялся второй эпизод DevSecOps-митапа CyberCamp, в программу которого вошли киберучения на платформе Jet CyberCamp. Три задания, максимально приближенных к реальным задачам специалиста по безопасности приложений — в этом материале разберем их все. Вы узнаете, какие идеи закладывались в задания, где авторы расставили ловушки, и какие реальные кейсы из практики за ними стоят.

P.S. А пока вы с головой уходите в разбор этих кейсов, мы уже вовсю готовимся к новому формату — 17 июля в Москве на свежем воздухе пройдёт первый опен-эйр-фестиваль «Лето в Киберкэмпе 2026» с новыми киберучениями, докладами про ИИ, DFIR и живым общением у воды. Не пропустите!

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

А все дело в пресловутых софт-скиллах и айти-конфликтологии, о которой я и собираюсь рассказать вам в этой статье.

Создали единое окно доступа к 300+ генеративным ИИ-моделям, добавили новые образы в маркетплейс, обновили каталог ИИ-моделей, выпустили новую версию SELECTOS, а еще запланировали для вас несколько полезных вебинаров. В июле реализовали десяток обновлений — под катом раскрываем все детали.

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

В этот раз мы рассмотрим три совершенно разных новинки. ONEXPLAYER X2 совмещает игровой ПК, планшет и мини-ноутбук. MSI Claw 8 EX AI+ делает ставку на производительность нового поколения и бросает вызов лидерам сегмента. Acer Nitro Blaze Link идет еще дальше — это стриминговая система без мощного железа внутри. Сравнивать их особенно интересно: каждое устройство предлагает собственное видение будущего портативного гейминга.

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

Преамбула

У меня есть друг который работает сетевым администратором. Когда заходит разговор о том что ИИ заменит всех айтишников, он улыбается и говорит что это не про его профессию. Он говорит что ИИ плохо выполняет задачи с которыми он работает - многое надо делать руками в прямом смысле слова. У меня появилась идея проверить универсального ИИ агента - сможет ли он справиться с типовыми задачами сетевого администратора. Генерировать конфиги сетевого оборудования по промту или диагностировать проблему по логам эти задачи не выглядят как вызов для ИИ. Я выбрал задачу которая на мой взгляд более сложная - сбросить пароль на маршрутизаторе. Тут и подключение по COM-порту, работа с ROMMON и специфические тайминги. Да и ранее я не встречал решений которые автоматизируют этот процесс. 

Хакер приходит в общественную столовую и с возмущением обнаруживает, что солонку на столе может открутить кто попало. Помните эту старую хохму?

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

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

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

Итак, приходит Хакер в магазин и обнаруживает: 

• Кассы-трансформеры и терминалы самообслуживания — лицо современного ритейла и его ахиллесова пята.

• Кнопки вызова сотрудников — радиопередатчики с фиксированным кодом, который можно перехватить и воспроизвести.

• Беспроводные трубки стандарта DECT, которые до сих пор используют в торговых залах.

• Терминалы сбора данных — Android-устройства без пароля, с доступом к настройкам Wi-Fi.

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

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

Даже если явно попросить ответ по JSON Schema, модель может добавить пояснение, пропустить поле или вернуть не тот тип. Нативный structured output у части провайдеров есть, но он работает не везде и не одинаково.

В новом переводе от команды Spring АйО разбираем, как в Spring AI 2.0 решается эта проблема.