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

Skills стали одной из самых популярных точек расширения в Claude Code. Они гибкие, их легко создавать и распространять.

Но эта гибкость усложняет понимание. Что работает лучше всего? Какие skills стоит делать? Как написать хороший skill? Когда имеет смысл делиться ими с другими?

Мы в Anthropic активно используем skills в Claude Code — сейчас у нас их сотни в работе. Ниже — уроки, которые мы извлекли из этого опыта.

У каждого сервиса в Иви есть свои хранители. У веба — команда «Гамбит», которая делает так, чтобы сайт оставался тем самым местом, с которого начинается путь зрителя в мир контента. Они не просто пишут код, а выстраивают целую экосистему, где скорость, стабильность и забота о пользователе переплетаются с экспериментами, AI-инструментами и собственным мерчем. В этой статье Дмитрий Абраменко, технический менеджер платформы веб, приоткроет завесу тайн своего направления и расскажет больше о команде.

В прошлой статье мы сделали первое пробное фронтенд-приложение.

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

Для проекта используем специально подготовленный для работы с AI-агентами шаблон AI-стартера, где уже заложены подробные инструкции для работы с ИИ.

В статье — описание всех изменений, возможных проблем во время работы и их решения. И ссылка на репозиторий с проектом, конечно.

Привет! На связи команда Yandex Monium, это вторая часть серии про эффективный мониторинг. Исторически Monium был разработан командой Yandex Infrastructure как внутренняя observability‑платформа и использовался для мониторинга критических сервисов внутри Яндекса. В прошлый раз мы рассказали о том, что важно знать про мониторинг в целом, а также рассмотрели подробнее асинхронные задачи. На примере кейса с таинственным зависанием задач мы увидели, как с помощью метрик можно определить не очевидную проблему, вызванную скрытым багом. 

Но вполне возможно, что у вас всё взаимодействие происходит через очереди, а не через асинхронные задачи. Далее в этой статье:

— В первой части разберём кейсы на примере in‑memory‑очереди. Это также применимо для различных типов очередей, в том числе для Apache Kafka. 

— Во второй части перейдём к клиент‑серверному взаимодействию.

Совсем недавно вышла Resident Evil: Requiem, которая сейчас вовсю хайпует. Капкомовцы, конечно, молодцы: умеют в сотый раз рассказать то же самое, что было в прошлых играх. К сюжету и контенту в целом есть вопросы. Для номерной части серии игра коротковата и ей не хватает эпичности (особенно в финале). Хотя назвать игру плохой язык все же не повернется.

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

Мы уже рассказывали о том, как видеокарты изменили киноиндустрию. Пришло время поговорить о них на примере игр.

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

Хабр, привет! Меня зовут Александр Скугарев, я работаю продуктовым лидом в Яндекс Практикуме. В этом тексте я вместе с главным экспертом модуля Александром Головко расскажу, зачем разработчикам нужна Computer Science и как мы работаем с этой областью знаний в курсах Практикума.

Отличительной особенностью научного подхода является отсутствие веры на слово. Любое утверждение не может считаться фактом, пока не будет установлена его истинность. А для этого необходимо задать множество вопросов, провести множество измерений, тестов, моделирований и т. д. Все, что есть во Вселенной, осязаемое или нет, может быть в той или иной степени измерено. Не исключением являются знания, которые проверяются как в школах, так и в университетах с помощью специально составленных экзаменов. С появлением генеративных ИИ не утихаю дебаты об уровне их знаний и достоверности той информации, которую они выдают на запрос. Те тесты, которые ранее считались показательными, более не могут полноценно оценить ИИ. По этой причине ученые из Техасского университета 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 году мы живем в странной информационной реальности. С одной стороны, руководители крупнейших ИИ-компаний заявляют, что искусственный интеллект вот-вот заменит программистов и половину офисных сотрудников. С другой — данные по занятости в развитых странах не показывают массовой безработицы. 

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

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

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