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

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

В июле прошлого года я рассказывал, что мы готовим к запуску спутник с бортовым компьютером, к которому можно будет подключаться по SSH. Прямо как к нашему VPS, только он летит над головой со скоростью 7,8 км/с. Звучало как фантастика, но мы это сделали.

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

Здравствуйте, уважаемые читатели! Безусловно, все слышали про игру Pacman. А слышали ли Вы про Pacgirl? Это подруга Pacman — она с бантиком...

Основная «фишка» эксперимента этой статьи — это, конечно, сеть ИОЛА, построенная из советских комплектующих. Её основа — сетевые адаптеры, собранные на «рассыпухе» малой степени интеграции, работающие по сей день. Самая старшая микросхема в сетевой плате — почтенная К155ЛА3 — датируется аж 1985 годом. Ей «стукнул» 41 год.

Для демонстрации сетевого взаимодействия мы выберем развлекательно-игровую среду. В качестве сетевого теста у нас будет Pacman! Простейшая и в то же время класснейшая игрушка. В нашем эксперименте данные между двумя машинами мы будем передавать не дискетками и не нуль-модемным кабелем. Мы увидим, как работает FTP-сервер, запущенный под MS-DOS.

Гоним мистера Пакмана, Пакгёл, догоняй...

В прошлый раз я рассказывал, как работает Guardrails Filter: зачем вообще понадобился отдельный слой защиты данных при работе с LLM и какие задачи он решает.

В этот раз хочу обсудить то, какие подводные камни могут оказаться под капотом этой технологии. Пока мы делали свой Guardrails Filter, быстро выяснилось, что найти персональные данные — далеко не самая сложная часть задачи. Гораздо сложнее оказалось встроиться между приложением и моделью так, чтобы ничего не сломать.

Как это сделать? Сейчас расскажу.

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

О количестве моделей, их особенностях, что было после и при чём тут «Электроника Д3-28», — в этом очерке цикла.

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

Важно отметить, что на первом этапе ядро Лиспа не вычисляет значения аргументов вызова.

Использование макро в гомоиконном Лиспе позволяет добавлять в Лисп новые “операторы” (именно поэтому знаменитый лиспер Пол Грэм назвал Лисп программируемым языком программирования).

Однако, у медали имеется и обратная сторона: если код содержит большое количество макро, то при интерпретации Лиспа будет тратиться значительное время на макрогенерацию.

Цель этой небольшой заметки состоит в том, чтобы указать вполне очевидный способ снизить отмеченный недостаток использования макро. Этот способ состоит в том, что весь исполняемый код предварительно обрабатывается, в нём отыскиваются макровызовы и “раскрываются” (заменяются на результат макрогенерации).

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

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

-         мacroexpand (функция, которая строит макрорасширение);

-         proplist (получение списка свойств символа для того, чтобы отличить макровызов от вызова функции);

-         stat (функция, которая включает режим статистики);

Всем привет! Меня зовут Александр Цай, я ведущий инженер-аналитик в МТС Web Services.
Занимаюсь всем, что связано с данными и ИИ. Найти, заполучить, обработать, спроектировать, развернуть — это все ко мне.

Опущу все нудные подробности, решили мы развернуть себе Superset 6.1.0 — последнюю версию, но столкнулись с тем, что заказчику категорически не нравится штатный фильтр по датам и он не хочет пересаживаться со своего BI, а хочет он календарик. А еще — пару плагинов с оглядкой на PowerBI. Поэтому встал вопрос создания собственного плагина-фильтра.

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

А что все это значит? Время написать свой собственный!
Об этом и расскажу в сегодняшнем материале. 

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

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

На связи Андрей, руководитель направления безопасности облака в Selectel. В статье расскажу, как работать с индексами Wazuh напрямую через OpenSearch. Такой подход пригодится, когда встроенных возможностей Wazuh уже не хватает: нужно собрать собственный отчет, посчитать статистику по всей инфраструктуре, настроить нестандартный алертинг или выгрузить данные для BI и других внешних систем. Вместо того чтобы обходить ограничения дашбордов, мы научимся работать с тем, где эти данные хранятся на самом деле.

Под катом разберем, какие индексы есть в Wazuh 4.14, как устроены документы внутри них, как безопасно читать данные из Python и не создавать лишнюю нагрузку на кластер. А в конце посмотрим, что изменится в Wazuh 5.0 и к чему стоит подготовить свои скрипты уже сейчас. Небольшой спойлер: индексы там переименовали целиком.

Привет! Я Дмитрий, старший Angular-разработчик в команде Klecks — платформы для разметки данных AI-Центра Т-Банка.

Последние годы мы жили с NSwag: один api.ts на 13 000 строк, Docker-сборка бэкенда и ожидание по 15—17 минут каждый раз, когда менялся контракт. В рамках одной из задач мы решили перейти к модели, где OpenAPI-файлы лежат в репозитории, а клиент генерируется через ng-openapi-gen. Расскажу, какие проблемы мы пытались решить, что пробовали на стороне ASP.NET Core и какой workflow получился в итоге.

Какова основная задача любого живого организма? Выживание и размножение для сохранения вида. Эта базовая мотивация является решающим фактором того, по какому пути идет эволюция того или иного вида. Эволюция нашего вида подарила нам весьма развитый интеллект, который сильно сместил приоритеты, управляющие поведением менее развитых организмов. Но понятие мотивации сохранилось. Любой тип добровольной деятельности подразумевает некое вознаграждение за выполнение определенных задач. Не всегда это нечто материальное, абстрактное вознаграждение также имеет вес. Но что именно мотивирует нас продолжать делать что-то, когда вознаграждение кажется все менее и менее вероятным? Короткий ответ — мозг. Более длинный ответ нашли ученые из Нагойского университета (Япония). Они провели исследование, в ходе которого установили, что орексиновые нейроны могут активироваться/инактивироваться в зависимости от мотивационных нужд. Как именно работают эти нейроны, и что происходит при их полной блокировке? Ответы на эти вопросы мы найдем в докладе ученых.

Благодаря искусственному интеллекту код удешевился. Но ошибочные архитектурные решения остаются такими же дорогими, как и раньше.

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

Давайте объясню это на конкретном примере. Система электронных продаж, написанная на Java — как раз такая штука, с которой большинство бэкендеров сталкивались хотя бы раз на протяжении карьеры.

Итак, два ряда чисел. Первый — насколько высоко пик каждого цикла стоял над трендом:

1.03 → 0.81 → 0.46 → 0.06

Второй — насколько глубоко дно уходило под тренд:

−0.28 · −0.24 · −0.38 · −0.37

Верхний ряд схлопывается монотонно, четыре цикла подряд, пятнадцать лет. Нижний стоит на месте: все четыре дна укладываются в коридор шириной 0.14. Пик декабря 2013 года стоял над трендом в десять раз. Пик октября 2025 превысил тренд на 15%.

Расхожая формулировка «четырёхлетний цикл умер» склеивает три разные вещи в одну. Тайминг цикла держится как держался: пики приходили на 13, 17, 18 и 18-й месяц после халвинга, максимальные падения — на 26, 29, 30 и 26-й. Дно не затухло вообще. Умер эйфорический верх.

Из этого наблюдения выросла интерактивная сквозная модель:

Cross-scale Bitcoin price model (исходники, русская версия).

Далее — что там внутри, где оно ломается, и что должно или может произойти.

Когда система мониторинга отправляет алерт, он редко выглядит так, как хотелось бы дежурному инженеру.

Один источник пишет critical, другой — disaster, третий передаёт severity: 5. В одном payload сервис называется checkout, в другом — payments-api, а в третьем его приходится угадывать по namespace.

Если все эти события приходят через общий Alertmanager или webhook, одной статической настройки маршрута быстро становится недостаточно.

Обычно проблему решают одним из трёх способов:

В ИТ-проектах я всё чаще вижу новую норму: когда руководитель проекта, заказчик или HR рассматривает специалиста в команду, он уже не ограничивается присланным резюме. Гораздо проще открыть ChatGPT, Gemini, DeepSeek или другую привычную модель и спросить: «Что известно об этом человеке как о профессионале?» И вот здесь начинается самое интересное: машина собирает ответ не из того, что человек хотел о себе рассказать, а из того, что о нём действительно осталось в цифровой среде.

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

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

Помните, как лет 5-7 назад все сидели на Yup или Ajv и всех всё устраивало? Потом появилось «Parse, don’t validate», стало настольной книгой для кучи разработчиков и в итоге выстрелило и у нас, в JavaScript и TypeScript. Тысячи библиотек со схемами - лучшее тому подтверждение.

Но это уже решённая проблема. А вот что не решено — обратная сторона:

JSON.stringify({ price: Infinity }) // => ‘{“price”:null}’

Ни падения, ни предупреждения. Где-то сломалась математика, а клиент получил null и нарисовал пустую ячейку. И это только один пункт из списка: undefined там, где в типах написано string; молча пропавшие ключи; Map и Set, превращающиеся в {}; и вообще отправляется всё - включая поля, которые вы отправлять не собирались.

Кажется, за 7 лет разработки я собрал все эти грабли. В статье разбираю каждый пункт и показываю как это чинится - “Encode, don’t stringify”

Моя Roadmap разработчика имитационных моделей в AnyLogic породила в моём канале больше вопросов, чем ответов. Суммируя которые можно прийти к медианному:: «А что это вообще за зверь?». Поэтому к вашему вниманию новая статья, позволяющая хоть и не приручить, но по крайней мере погладить эту животинку. Для этого нам понадобится: 1) познать ИМ суть, 2) понять ареол обитания и 3) осознать незаменимость в дикой природе сложных систем.

У нас в среднем два релиза в день, бандл весит 7,76 МиБ после brotli, и половина клиентов качает его заново по несколько раз в сутки: хеш в имени файла поменялся - значит, кеш мимо. Compression Dictionary Transport (RFC 9842) позволяет объявить вчерашнюю сборку словарём для сегодняшней, и вместо 7,76 МиБ уезжает 15 КБ.

Рассказываю, что из этого работает на практике при непрерывной поставке: почему дельты только к предыдущей сборке хватает лишь на 43% визитов, как считать окно словарей по своим логам, как отдавать дельты из nginx без reload на каждый релиз, и что ломается на откатах, канарейках и бампах зависимостей. Все цифры - с нашего портала, методика в конце.

Это четвертая статья серии о том, почему акустика, которая хорошо измеряется, может плохо звучать

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

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

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

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

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

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

После нескольких таких запусков я пришла к выводу, что спор «вебинар или видео» в 2026 году сформулирован не совсем правильно. Покупатель выбирает не столько формат. Он выбирает, сколько собственного времени и общения с продавцом готов потратить, чтобы принять решение.

Классическая корпоративная воронка часто выглядит примерно так: Хотите посмотреть продукт? Оставьте заявку → менеджер позвонит → договоримся о времени → проведем демонстрацию.

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

Внутри:

- Как избавиться от тех, кто ПОСТОЯННО кликает по вашей рекламе.
- Защищаем сайт БЕЗ КАПЧИ: рисуем кнопку, которая будет невидима для бота.
- Как вычесть мусорные визиты из Яндекс.Директа.
- Как кормить Директ конверсиями, чтобы он НЕ учился на МУСОРЕ.

И ТОПовый лайвхак! Ловушка для ботов, которую может повторить каждый.

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