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

Отличительной особенностью научного подхода является отсутствие веры на слово. Любое утверждение не может считаться фактом, пока не будет установлена его истинность. А для этого необходимо задать множество вопросов, провести множество измерений, тестов, моделирований и т. д. Все, что есть во Вселенной, осязаемое или нет, может быть в той или иной степени измерено. Не исключением являются знания, которые проверяются как в школах, так и в университетах с помощью специально составленных экзаменов. С появлением генеративных ИИ не утихаю дебаты об уровне их знаний и достоверности той информации, которую они выдают на запрос. Те тесты, которые ранее считались показательными, более не могут полноценно оценить ИИ. По этой причине ученые из Техасского университета A&M (Колледж-Стейшен, Техас, США) разработали «Последний экзамен человечества» - всеобъемлющий текст знаний по различным направлениям для ИИ. Из каких вопросов состоял тест, и как себя показали самые популярные генеративные ИИ? Ответы на эти вопросы мы найдем в докладе ученых.

Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.

С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).

Мы привыкли думать о вычислениях как о битах, регистрах и арифметике. А что, если базовой единицей вычисления сделать не бит, а локальную геометрическую конфигурацию тетраэдров? В этой статье я покажу дискретный тетраэдрический движок состояний, симметрийную канонизацию, аттракторы, иерархические jump-таблицы и реальные замеры на RTX 3090 — с измеренным exact-ускорением в 554.92 раза на одной и той же задаче.

Асинхронность в Python — одна из тех тем где на собеседовании начинают плыть.

Почему await не делает код параллельным?
Как на самом деле работает event loop?
Когда asyncio — правильный выбор, а когда лучше использовать потоки или процессы?

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

Материал рассчитан на тех, кто хочет не просто отвечать по документации, а уверенно объяснять поведение системы и принимать инженерные решения.

В моменте идея развертывания дома почтового сервера может показаться излишеством, ведь вполне для отправки различного рода уведомлений можно использовать Telegram или любой другой мессенджер, а для переписок со своего домена почту можно завернуть на какой-нибудь почтовый сервис, предлагающий возможность использования своего домена бесплатно, например mail.ru. Однако с учетом последних телодвижений РКН в сторону блокировки Telegram и ограничение в 5 ящиков на mail.ru (а с недавнего времени и использование сторонних почтовых клиентов только на платных тарифах), вариант использования собственного почтового сервера кажется все более интересной альтернативой.

Если в случае классических приложений нефункциональное тестирование часто переносят в разряд “было бы неплохо” и оставляют на потом, то при тестировании AI-приложений так уже не получится.

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

В подразделении, где я работаю, есть традиция - новичку при онбординге вручается ссылка на Wiki с легендарными багами, приведшими к заметным последствиям. Недавно мне пришла в голову идея сделать такую же страницу, но уже со ссылками на Хабр, потому что на русском о багах пишут с бОльшим огоньком. Но, увы, оказалось, что каскадному падению серверов AT&T 15 января 1990 года внимание как-то не уделено. А ведь история получилась, прямо-таки эпическая.

Итак, 15 января 1990 года из-за одной строчки кода телефонная сеть AT&T получила 9 часов даунтайма, 70 миллионов несовершенных звонков, а общий убыток насчитали в $60 миллионов еще не инфляционных долларов. И нет, там не было неудачного релиза, развернутого сразу и везде. Все было гораздо интереснее.

Недавно на Хабре вышла статья «Почему наш язык — худший язык для программирования». Автор справедливо отметил проблему двусмысленности естественного языка (ЕЯ) и предупредил, что программирование словами приведет к хаосу.

Я начну с неожиданного: автор оригинальной статьи абсолютно прав.

Он прав, если мы говорим о программировании заклинаниями (vibe-coding) — популярном сегодня подходе, когда человек пишет в окно чата: «Сделай мне интернет-магазин с красивым дизайном», а потом тонет в неконтролируемой лапше сгенерированного кода. В формате свободной болтовни с ботом естественный язык для написания кода действительно ужасен.

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

Инструменты вроде CodeSpeak (публичная альфа-версия от создателя Kotlin Андрея Бреслава, о которой я подробно писал в своей статье) уже сегодня демонстрируют свой огромный потенциал: если загнать естественный язык в рамки контрактов, он способен стать лучшим, самым высоким из доступных нам уровней абстракции.

У вычислительной программы есть два ресурса: время (циклы CPU) и пространство (оперативная память). Но как они заменяют друг от друга? Правда ли задачу, которая решается в полиномиальном пространстве , можно решить за полиномиальное время ?

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

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

Привет! Меня зовут Вероника, я руководитель проекта по разработке ГИС. Эту статью мы писали вместе с Евгением — нашим DevOps-инженером, который отвечает за CI/CD, релизы и за то, чтобы наши обновления не превращались в ночной кошмар.

…

Однажды темным хмурым вечером в ожидании очередного деплоя я имела неосторожность задеть DevOps-инженера вопросом: «Что ты там часами делаешь, тебе же всего одну кнопку надо нажать?». Он объяснил, что это не совсем так. Я предложила:

— А давай сделаем одну «большую зеленую кнопку», которая все сама задеплоит?

— Технически можно, но…

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

Если вы хоть раз встраивали Lua в свой проект — будь то игровой движок, высоконагруженный веб-сервер на OpenResty или конфигуратор сложного сетевого оборудования — вы знаете, за что мы его любим:)
А любим мы его — за компактность, быстроту, встраиваемость и предсказуемость. Не любим — за аскетичный синтаксис, отсутствие привычных конструкций и постоянное «изобретение велосипеда».
Эта статья — обзор диалекта Lattelua: зачем он нужен, чем отличается от других диалектов, и почему его особенно удобно использовать в уже существующих проектах, где Lua — встраиваемый язык.

Привет! Меня зовут Дмитрий Ивахненко из команды Автономного транспорта Яндекса. В этой статье я подробно разберу, как устроены сервисы удалённого управления автономными юнитами — роботакси, роботами‑доставщиками и грузовиками. 

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

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

Разбираемся, что говорят данные, экономическая история и исследования о влиянии искусственного интеллекта на рынок труда.

Привет, Хабр! Меня зовут Владимир Дробот, я SRE Lead и руководитель центра технической поддержки в кластере рекламных технологий в компании «МТС Веб Сервисы». 

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

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

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

Кто прав? Паникеры или оптимисты?

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

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

Сегодня мы обсудим тему, которая из «скучной технической прослойки» превратилась в главный стратегический актив — ESB (Enterprise Service Bus). Почему в 2025–2026 годах без единого интеграционного ландшафта бизнес рискует захлебнуться в собственном ИТ‑«зоопарке»? Давайте разбираться.

Этот текст не претендует на «академический» обзор TAPe и не заменяет будущие формальные бенчмарки на COCO‑подобных датасетах. Скорее это рабочие ответы на самые частые вопросы инженеров и исследователей, которые всерьёз присматриваются к проекту.

О чем речь

Мы делаем TAPe‑модель (вот здесь понятней, о чем речь: тыц, другой тыц) под задачи детекции объектов на COCO‑подобных данных, с возможностью добавлять свои классы и кастомизировать под конкретного заказчика. TAPe работает не с пикселями и не с жёсткой N×N‑сеткой, как YOLO, а с осмысленными регионами (патчами) в TAPe‑представлении. В экспериментах стремимся к тому, чтобы за один «ход» модель отсекала точно неинтересные области и выделяла кандидатов, где вообще есть смысл что‑то детектировать.​

На маленьком датасете из 4 классов и 1256 изображений с частично шумной разметкой пилотный TAPe‑детектор с ≈115k параметров даёт 98.94% попаданий по объектам по прикладной метрике «центроид бокса в 32 пикселя от центра разметки», причём без аугментаций и с обучением на CPU.​ В роли baseline’а брали YOLO11s (линейка Ultralytics/YOLOv8‑s): на том же датасете она плохо сходилась, давала низкую детекцию и много ложных срабатываний. Впрочем, выводы пока делать рано.​

TAPe‑архитектура за несколько итераций ушла от громоздкого (для нас) dictionary‑подхода с 100k+ параметров к более компактной схеме без классического градиентного спуска: описания классов собираются из TAPe‑векторов и сжимаются через k‑means, а не обучаются как отдельная нейросеть.​ На подмножестве COCO (около 2% датасета, ~2400 изображений) эта же компактная модель без спецоптимизаций даёт 60.59% попаданий по центрам объектов — для такого размера детектора это неожиданно много и хороший аргумент в пользу того, что TAPe‑данные позволяют «маленьким» моделям сходиться там, где стандартные подходы ожидаемо захлёбываются.

Через несколько минут после публикации этой статьи NVIDIA представит то, что ещё недавно считалось бы первым в отрасли: разделённое (disaggregated) аппаратное решение для ИИ.

Но Amazon на этот раз оказалась быстрее. Она представила свою версию этого нового форм-фактора за несколько дней до анонса Дженсена Хуанга. Форм-фактора, который, по моему убеждению, меняет парадигму ИИ-оборудования.

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

Вот как это работает — и почему открывает новую эру в железе.

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

Недавно увидел вот такую диаграмму. На ней я в серой зоне — как типовой представитель народонаселения, потому что не вижу, как использовать AI в жизни. На зелёные квадратики можно не смотреть, а желтые и красные — это та часть 8-ми миллиардного населения планеты, которая действительно регулярно использует LLM-ки.

А вот тех, кто пользуется ИИ профессионально, так мало, что они находятся в зоне статистической погрешности? Почему 16% пользователей не покупают подписку на ИИ-шки? И почему оставшиеся 84%, что составляют 6 миллиардов с хвостиком знать не хотят про ИИ?

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

В данном интервью я поговорил с Иваном Гордынцем — экспертом по 1С и автором крупного образовательного YouTube-канала — о том, как он пришёл в профессию, почему 1С «везде», чем платформа сильнее Excel и что на самом деле стоит за её репутацией.