Программирование *

Привет, Хабр! Сбер недавно выкатил новую модель, GigaChat Audio. Сейчас я надиктовываю модели этот текст голосом — финальный штрих в истории о том, как я проводил её тест‑драйв. 

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

Меня зовут Данила @pushnoydan, я мидл‑разработчик и занимаюсь бэкендом микросервисов. А параллельно — большой любитель ИИ‑моделей: в свободное время копаюсь в них, чтобы лучше понимать возможности свежих релизов, стараюсь применять на работе, чтобы упростить рутинные задачи. 

GigaChat Audio — audio‑native LLM. В течение дня я поручал ей разбирать голосовые коммуникации от коллег, составлять саммари по аудиозаписям и выводить ключевой контекст из записей различных встреч. Давайте посмотрим, как модель показала на реальных задачах.

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

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

Делаем приложение, которое готовит расчётные наборы данных для нативного BI-конструктора Битрикс24.

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

Атакующий уже знает логин и пароль — купил, подобрал по утечке, вытащил стилером с домашнего ноутбука. Второй фактор — пуш в приложении с кнопками «Одобрить» и «Отклонить». И вот он просто начинает логиниться. Раз за разом. Телефон жертвы звенит в двадцать третий раз в 02:40, человек спросонок жмёт зелёную кнопку — не потому что глупый, а потому что это самый быстрый известный ему способ прекратить вибрацию. Всё, второй фактор пройден.

Так вынесли Uber в сентябре 2022-го — там пушам ещё помогло сообщение в мессенджере от «айтишника»: мол, одобрите, чтобы это прекратилось. Примерно так же заходили в Cisco несколькими месяцами раньше.

У меня два физических сервера на списанном железе — Xeon E5 и старый IBM, суммарно 112 потоков и 754 гигабайта памяти. На них 55 виртуальных машин, и на этом живёт онлайн-школа, платформа с курсами, мессенджер, игровой движок и майнкрафт-серверы для учеников. При этом я не девопс и не системный администратор. Разбираю технически: как поделены машины, как устроена репликация баз между площадками, что происходит при падении основной и какие вещи я сделал неправильно.

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

Привет! Я Евгений Бартенев, техлид и автор курса «Python-разработчик» в Практикуме. В этой статье попробую написать автомобильные гонки примерно в 50 строк кода на Python. Вся «графика» будет состоять из обычных символов терминала, а по пути мы немного разберёмся с ANSI-последовательностями, неблокирующим вводом и тем, как вообще устроен терминал.

Современный JavaScript / TypeScript сегодня, предоставляет мощный инструмент для асинхронного программирования, который знаком каждому - async/await на основе Promise. Он позволяет писать последовательный код и легко обрабатывать ошибки. Однако за простотой скрываются серьёзные ограничения, которые становятся критичными в высоко-нагруженных системах, играх, сложных пользовательских интерфейсах и приложениях, требующих предсказуемой производительности.

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

В этой статье мы разберём, как кооперативные корутины (Coroutines) решают эти задачи на примере моей библиотеки ts-adaptive-coroutines, изучив каждый аспект по кирпичикам, посмотрев на инструмент, который добавляет в TypeScript адаптивные приоритеты, арены памяти, каналы, семафоры и много-поточность.

Состояние во Vue обновилось, а интерфейс остался прежним — и начинается охота на watch, nextTick и принудительный ререндер. Разберём, где именно рвётся реактивная связь, почему это происходит и как находить такие проблемы до того, как вокруг них вырастут костыли.

Здравствуйте, Хабровчане! Меня зовут Дмитрий, я бэкенд разработчик Java. Недавно я наткнулся на задачу, которая сначала показалась мне копеечной, а потом сожрала неделю вечеров и заставила залезть глубоко в дебри конкурентных транзакций PostgreSQL.

Всё началось с обсуждения автоматизации одной частной клиники. Поначалу казалось, что сценарий простой: пациент хочет записаться на МРТ с контрастом. Обычный календарь записи (вроде Calendly или виджетов типа YClients) предлагает выбрать мастера и время. Но на деле всё оказалось не так просто...

Лаг Kafka растёт, консьюмеры простаивают, а добавление новых экземпляров только ускоряет проблему. Разберём, как по состоянию consumer group, таймерам и поведению партиций быстро определить причину сбоя и не потратить ночь на лечение неправильного симптома.

Инструмент работает с топологией: GDSII/OASIS и LEF/DEF, верификация DRC/LVS/PEX (зазоры, сверка со схемой, паразиты), список нарушений. Типичный вопрос инженера: «почему LVS ругается на этот инвертор» или «покажи spacing на met2».

Три условия, без которых чат в таком продукте вреден.

Полностью офлайн по умолчанию. Layout это IP заказчика. Кусок дизайна в облако не уезжает, пока человек сам не выбрал облачный бэкенд. Часть установок air-gapped(изолировано).

Нельзя молча испортить данные. Правка геометрии идёт через preview: Apply или Discard. Delete и крупные батчи помечаются жёстче.

Нельзя выдумывать. Числа по нарушениям и правилам берутся из движков и локальной документации. Общая эрудиция модели сюда не допускается.

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

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

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

— Я могу продолжить, — ответил агент, — но symlink делать не надо. Я и так код вижу.

— Как? Ведь я тебе не давал доступа! — изумился я.

— А мне и не нужно давать доступ. Я вижу, могу читать и изменять все файлы на твоём компьютере«.»

Если ваш внутренний голос сказал на этом месте: «Ну и что в этом необычного?» — вам, наверное, не стоит читать эту статью дальше.

Раскопал на Medium интересное эссе про Elixir от разработчика Krzyś. Написано так захватывающе и самобытно, что я не смог пройти мимо. Хотел чуть-чуть подсократить, но каждый раздел важен, а терять стиль автора не хочется. Вот тут первая часть, а это — вторая.

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

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

За час ИИ-агент может изменить десятки файлов, написать тесты и потратить большой объём токенов. Польза для команды зависит от результата. Если разработчик долго восстанавливает ход изменений, переписывает половину патча или обнаруживает пропущенный сценарий после слияния, работа агента только увеличивает нагрузку.

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

Для оценки каждой задачи нужны три параметра:

Три месяца назад я заметил неприятную закономерность в бэклоге: все чаще туда попадали мелкие фиксы вокруг кода, который до этого писал ИИ. Не аварии, не падения прода, не критичные инциденты — обычные доработки, которые на первый взгляд не выглядели тревожно. Сам код тоже не был плохим: аккуратная структура, нормальные имена, тесты, местами удачные абстракции. Такой PR сложно развернуть на ревью просто потому, что «что-то не нравится»: формально он выглядит как результат нормальной инженерной работы.

Привет, Хабр! Меня зовут Анатолий Овчинников, я бизнес-архитектор и владелец продукта Goodt Insight (ИТ-холдинг LANSOFT). Отвечаю за архитектуру продуктов, которые живут в проде годами и переживают не один состав команды. ИИ мы используем каждый день — поэтому его эффекты я вижу не на демо, а на дистанции в месяцы, когда к коду возвращаются.

Понадобилось мне тут для пары задач таки попробовать ИИ-шные ассистенты для написания кода. В процессе понял, что давно не брал в руки шашку в том числе и в плане статей на Хабр. Так что, если вам вдруг пригодится практическое сравнение Клода и ГигаКоворка (да) — держите.

Итак, что с чем сравниваем. У Anthropic есть Claude Cowork. А у нас дома — суверенный GigaCowork. Название уже намекает читателю на добрую половину продуктового питча: нейронка должна не болтать с вами в чатике, а получать задачи, работать с файлами и сервисами и приносить результат. Как дела с остальным помимо названия, я и решил проверить.

TLDR: даже с сильной опенсорсной моделью под капотом по зрелости GigaCowork пока ощутимо так отстаёт от Claude Cowork — нет управления браузером, а память не расшаривается между задачами внутри пространства. При этом разрешения настроены более гранулярно, чем у Claude, а структура «агент + навык + команда» как-то почестнее раскладывает работу цифрового сотрудника, чем один универсальный чат. 

Под катом — разбор и сравнение с конкурентом.

Часы копирования, формулы, которые ломаются от случайного пробела или запятой, и бесконечные сверки справочников. Знакомо? Делимся опытом, как мы превратили ручную Excel-рутину в автоматизированный процесс с помощью ИИ-генерации кода и почему для этого не нужно быть гуру программирования. Расскажем в блоге ЛАНИТ, как перестать быть  «оператором таблиц» и начать экономить рабочее время.

В 1984 году Бенджамин Блум доказал: ученик, занимающийся с репетитором один на один, обходит 98% обычного класса. Казалось бы, вывод очевиден. Но сам Блум написал, что это слишком дорого для общества, и поставил вопрос — чем заменить. Рассказываю, как мы отказались от занятий один на один, посадили 12 человек на одного преподавателя и почему это дало результат лучше, чем мини-группы.