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

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

Последнее время в опенсорсе много драмы: продолжаются споры о системах ИИ, позволяющих за минуту переписать проект и изменить его лицензию на разрешительную, и опенвошинге, когда доступный код выдают за открытый. Теперь на первые полосы вышла новая проблема — массовый наплыв пулл-реквестов, сгенерированных системами ИИ [ситуацию уже окрестили «слопмагеддоном»]. Обстановка дошла до того, что мейнтейнеры закрывают возможность участия в развитии открытых проектов. Мы в Beeline Cloud решили обсудить проблему и то, как быть контрибьютерам и мейнтейнерам в сложившейся ситуации.

Если Вы безоговорочный поклонник искусственного интеллекта (Ai) в нынешней его трактовке и не приемлете другие решения, то я бы не рекомендовал читать и комментировать эту статью. Если Вы занимаетесь приложениями для банковской сферы, или для торговли, или создаёте чат-боты общего назначения, то эта статья, скорее всего, будет Вам не интересна. Разработчики игр, так же не найдут в этой статье ничего полезного.

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

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

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

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

Опираясь на международные исследования и собственный анализ базы протестных пакетов, мы в CodeScoring попытались понять – остаётся ли protestware временной реакцией на кризисы или превращается в устойчивый элемент экосистем.

Если вы работаете с Codex, то наверняка замечали  следующее - нажимаешь кнопку “Обновить”, Codex перезапускается, но визуально ничего не меняется.

На самом деле изменения есть - просто чаще всего это не что-то глобальное, а внутреннее: скорость, MCP-инструменты, работа с Git и т.д.

Я посмотрел свежие релизы Codex за последние сутки: 0.142.2, 0.142.1 и несколько 0.143.0-alpha.*. В статье разберём, что уже вышло в свет, а что пока тестируется и возможно выйдет в ближайших обновлениях.

Спойлер: возможно скоро будет новый режим модели Ultra!

Сотни тысяч I/O-задач, десятки воркеров и гигабайты памяти на обработку очередей. В какой-то момент мне стало интересно, можно ли решить эту задачу иначе. Так появился Thrun —runtime worker на потоках и сопрограммах. В статье разбираю архитектуру и результаты сравнений с Horizon.

Привет, Хабр!

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

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

Мы с Кайтеном вошли в реестр Минцифры и поставляем джирозаменитель и трекер отечественным компаниям. В том числе крупным. В том числе с госучастием и государственным.

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

Все цены и условия — по публичным данным на официальных сайтах на начало июня 2026.

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

С марта 2022-го из России стремительно исчезают иностранные компании. Большинство зарубежных вендоров, включая Atlassian, Microsoft, Notion и Wrike, перестали продавать лицензии и продлевать подписки. Несмотря на это, около 70% российских компаний продолжают сидеть на серых джирах.

Почти каждый, кто админит VDS/VPS, хоть раз перезагружал сервер при DDoS-атаках или при подозрительно резком росте трафика. Это не помогает, ну а что ещё делать… Для того, чтобы этого не было, в статье под катом разберу, что происходит при разных видах DDoS, как правильно их диагностировать и с помощью чего можно отличить атаку от органического роста. 

Каждый раз когда я помогаю кому-то с электрикой, происходит одно и то же. Человек спрашивает «какой кабель на розетки?». Я говорю «2.5 мм²». Он спрашивает «а автомат?». Я говорю «C16». Потом: «а сколько метров нужно?», «а УЗО куда?», «а сколько это будет стоить?». И вот уже час объяснений, Excel непонятного происхождения и ощущение что что-то всё равно забыли.

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

Получился один HTML-файл на ~1400 строк ванильного JS.

https://darkenamber.github.io/electrokit/

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

Это вторая часть серии про LLM Sandbox. В первой части мы разобрали риски исполнения кода от LLM, ограничения песочницы, способы изоляции (Docker, Wasm, gVisor, microVM) и минимальную архитектуру агент+песочница.

Код реализации агента, skills, полные логи и артефакты примера — в открытом GitHub-репозитории.

Привет, Хабр! На связи Егор Лаптев — QA Fullstack Java в SENSE на проекте крупного российского банка.

End-to-end тесты UI проверяют только то, что видно на экране: кнопка нажалась, форма открылась, данные отобразились. Но в распределённых системах значительная часть бизнес-логики уходит за кадр — в асинхронные события, которые летят через Kafka. Если событие не дошло до топика или пришло с неверным payload, пользователь этого не увидит, а бизнес-процесс сломается.

В этой статье расскажу, как мы научились проверять Kafka-события прямо в автотестах — без Kafka UI, kcat и обёрточных сервисов, одной зависимостью и так, чтобы это работало в корпоративной сети с SSL. Покажу архитектуру коннектора, разберу три основных проблемы (SSL-сертификаты, конфликты consumer group и асинхронные тайминги), и поделюсь моделью работы инженера в связке с AI-агентом.

Кому будет полезно: QA-инженерам и специалистам по автоматизации, которые тестируют распределённые системы и хотят проверять Kafka-события прямо в автотестах; и инженерам, которым интересна практическая модель работы в связке с AI-агентом — как она ускоряет разработку тестовой инфраструктуры.

IT — дело молодых? Десять лет назад я в это свято верил и готовился почистить штат от сотрудников, которым шёл пятый, а то и восьмой десяток. То, что случилось вместо увольнений, изменило моё отношение к возрасту в профессии — и сегодня, в эпоху нейросетей, звучит особенно остро.

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

В статье — подробный обзор Аспро.Cloud, YouGile, Мегаплан, Битрикс24 и Планфикс. Расскажем про возможности каждой системы и дадим советы по выбору. В конце — сравнение CRM для управления проектами в удобной таблице для быстрого принятия решения.

Сервер может состоять из нескольких десятков компонентов, закупленных в разное время по нескольким контрактам на гарантийное обслуживание. Инвентарный номер есть у сервера, а также может свой у каждого комплектующего копмонента. Когда горит диск – вы знаете, к кому звонить и по какому контракту?

Если не сразу – эта статья для вас.

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

Можно ли доверять ответу нейросети?

Получить ответ от нейросети — только половина задачи. Не менее важно понять, насколько этому ответу можно доверять.

В новой статье делюсь своим взглядом на существующие методы верификации.

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

Мы были уверены, что наш DRC-движок универсален.

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

Мы эту мысль не проверили. Мы в неё поверили. И это разные вещи, как выяснилось.

Совершенно точно каждый из нас (java-разработчиков), когда-либо встречал в своей жизни понятие "прокси" из Spring. Кто-то на уровне подготовки к собесам, а-ля "@Async создает прокси", а кто-то споткнувшись на self-invocation в собственном классе.

И большинство, собственно как и я до определенного момента, часто удовлетворяются простым объяснением: "Spring использует AOP, создает прокси вокруг нашего бина и тем самым добавляет дополнительную логику до и после вызова метода."

Но на мой взгляд этого понимания крайне недостаточно в современных условиях.

Сегодня мы разберемся:
Что такое этот $$SpringCGLIB$$0, который неожиданно оказался вместо моего класса? Кто и в какой момент решил заменить мой бин?
Откуда берутся загадочные Advisor и TransactionInterceptor, которые я никогда не создавал? Почему порядок выполнения аспектов именно такой?
И что вообще физически находится внутри этого самого Proxy?

Приглашаю Вас шаг за шагом проследить путь одного объекта: от обычного Java-бина до полностью собранного Spring Proxy. По дороге заглянуть в исходники Spring и посмотреть, как рождаются Advisor'ы, как они сортируются, кто собирает прокси и из каких объектов он на самом деле состоит.

Я занимаюсь разработкой, и как большинство людей с техническим складом ума, когда что‑то работает не так — ищу способ это починить. Желательно программно.

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

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

Начнём с самого очевидного инструмента — амплитудно‑частотной характеристики (АЧХ).