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

Наверное, через это уже прошёл каждый из нас :)

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

Короче говоря, то что мы используем агентов - конечно суперсила, но в итоге, мы все начинаем идти по “Accepted driven development” , а это уже начинает сильно отупливать влиять на наши с вами когнитивные возможности :) ну и на наши умения в разработке в целом

Спойлер: это все решается, но нет, не тем что мы перестаем читать в целом код

Меня зовут Эдгар Сипки, я founder easyp & sipki tech и отбираю доклады на Golang Conf в программном комитете. А в своём тг-канале делюсь прикладными AI-инструментами и подходами для разработки - подписывайтесь, дальше будет больше :)

Так вот, обратно к теме. В этой статье я дам промпт-генератор, который соберёт learning skills под ваш проект - чтобы агенты и дальше ускоряли вас, а понимание собственного кода оставалось вашим, а не делегировалось модели :) Но сначала про сама проблему: снаружи-то это кажется все на увеличение нашего KPI, вроде ты и быстрее двигаешься, меньше застреваешь, да и в целом не тратишь часы на написания кода, но вот позже уже начинаются проблемы

Когда надо объяснить, что именно ты только что принял. Какие инварианты поменялись? Почему решение такое? Какие edge cases теперь важны? Что сломается через месяц, если кто-то тронет соседний кусок кода? (а это будет не редко)

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

Эти рейтинги кардинально расходятся. Компания с оценкой $39 млрд поставила 150 роботов. Компания без известной оценки отгрузила 5 500. Понимание этого расхождения — ключ к пониманию того, где реально находится индустрия.

Как мы превратили панель управления NAS в платформу для расширений, зачем туда Log Manager и для чего Plugin Template.

С версии 3.6.4 Mini Bucket становится открытой платформой для плагинов.

Теперь любой желающий может дописать то, что нужно именно ему. И поделиться с сообществом.

Считается, что порт Doom можно запустить на любом технологическом устройстве. У игры изящный, быстрый, модульный код, который может работать практические везде. Порты выпустили даже для систем, появившихся до Doom, а некоторым портам помогает специальное оборудование как, например, в случае первого Doom на SNES. Чистый и изящный код написан на C, в нём не так сложно разобраться. В нём не используются никакие современные дополнения языка и какие-то устаревшие технологии, поэтому он замечательно компилируется. Кроме того, он удобен для разных endiannes, что очень важно для портируемости.

Поэтому неожиданно, что порт Doom так и не появился на Neo Geo. В конце концов, в Neo Geo работает тот же CPU Motorola 68000, что и в Sega Genesis с Commodore Amiga, а для обеих этих платформ, несмотря на их слабые характеристики, есть версии Doom. Для Neo Geo же её найти невозможно. Многие разработчики, работавшие с Neo Geo, часто говорили, что на ней практически невозможно запустить Doom. Но почему? У этой консоли есть видеодисплей, CPU, ОЗУ и всё необходимое для запуска видеоигр. Давайте же разберёмся.

Когда я первый раз пришёл на встречу со стейкхолдером в роли аналитика, я честно не знал с чего начать. Вопросы в голове были — но не в том порядке. Половину забыл по ходу. Вышел с ощущением что поговорили хорошо, но непонятно о чём.

Я поискал готовые шаблоны. Нашёл Excel-таблицы, PDF-чеклисты и десятки статей с советами. Ни одно из этого не открывалось быстро прямо на встрече и не помогало думать в реальном времени.

Поэтому я сделал BA Toolkit — набор интерактивных инструментов для структурирования BA-встреч. Открываешь в браузере, идёшь по шагам, фиксируешь всё на месте.

Три месяца спустя — три инструмента в продакшене, открытый код на GitHub и эта статья.

Привет, Хабр. Меня зовут Аскар Добряков, ведущий эксперт направления защиты данных и приложений в К2 Кибербезопасность, занимаюсь WAF и цепочками обратных прокси. В одном из недавних проектов мы с коллегами натолкнулись на странную реакцию WAF: подставляешь в запрос X-Real-IP, а WAF принимает его как реальный адрес клиента, хотя не должен так делать.

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

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

Если вы пишете код, или так или иначе задействованы в разработке ПО, или просто следите за тем, как ИИ меняет разработку, то наверняка слышали тревожный тезис: «Скоро ИИ будет писать код лучше людей, и разработчики станут не нужны». На интуитивном уровне кажется, что если машина делает ту же работу в 8 раз быстрее, то бизнесу нужно в 8 раз меньше людей. Но экономика и история индустрии говорят об обратном — и тут очень кстати оказывается старый экономический парадокс, которому уже больше 150 лет.

В базах данных в качестве первичных ключей часто используют случайные UUID. Один из известных недостатков случайных UUID заключается в том, что их неупорядоченность (UUID4) может вызывать большое количество дополнительных обращений к страницам кластеризованных индексов (clustered index), потому что строки вставляются в случайные места B-дерева, и его приходится постоянно перебалансировать. В этой статье я попытаюсь помочь вам выработать более интуитивное понимание того, как влияют на производительность все эти дополнительные операции со страницами.

Хотя статья посвящена конкретно SQLite, проблема случайных UUID касается и других баз данных, использующих кластеризованные индексы.

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

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

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

Возникает вопрос: стоит ли и дальше развивать складской модуль ERP или мы уперлись в потолок и пора переходить в специализированную систему управления складом?

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

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

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

После прошлой статьи я каждый день заходил на барахолки и искал ещё одну версию терминала «Сбера». Это более новая модель под названием Kozen P10F, её часто можно видеть в киосках самообслуживания и на кассах магазинов. Чем же она отличается от квадратного терминала? Можно ли накатить свою прошивку? Что же у неё внутри?

Исследователи Anthropic собрали LLM-агента, который читает код Python-библиотек, сам формулирует свойства, пишет property-based тесты на Hypothesis и ищет контрпримеры. В результате он нашёл баги в NumPy, aws-lambda-powertools, tokenizers и других проектах — часть патчей уже приняли мейнтейнеры. Разбираемся, как работает такой агент, почему property-based тестирование хорошо подходит для LLM и где у подхода пока границы.

Меня зовут Юлия Аравина, я карьерный стратег и коуч IT-руководителей, а также ведущая кейс-клубов на курсе «Технический директор — СТО» в Яндекс Практикуме PRO. В своей практике я замечаю одну закономерность: многие кризисы после повышения выглядят одинаково.

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

Многие объясняют это нехваткой навыков: кажется, что нужно лучше делегировать, увереннее принимать решения или пройти ещё один курс по менеджменту. Но чаще всего проблема глубже. После повышения человеку приходится перестраивать не только набор навыков, ему приходится заново отвечать на вопрос: «За что я вообще себя уважаю?» 

Давайте разбираться.

Я недавно начал пользоваться Krita, и после Фотошопа основной болью для меня было отсутствие удобного инструмента для умного выделения объектов выделения объектов.

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

Идея простая:

1. Пользователь обводит объект лассо.
2. Нажимает кнопку Select object with AI.
3. Плагин локально строит мягкую alpha-маску.
4. Krita получает обычное выделение, с которым дальше можно работать штатными
   инструментами.

Назвать плагин я решил Krita Smart Select.

Репозиторий:
https://github.com/BMFreed/krita-smart-select

Релизы:
https://github.com/BMFreed/krita-smart-select/releases

Привет, Хабр! Я Анастасия Глущенко, бизнес-аналитик направления BI в Департаменте аналитических решений, Корус Консалтинг. Люблю красивый, сочный визуал, а также яркие и емкие метафоры — короче говоря, я та еще сказочница. И в этой статье я расскажу именно о сказочных персонажах и ситуациях, которые встречаются на пути аналитика. Ведь всем знакома фраза «иди туда — не знаю куда, принеси то — не знаю что»?

Привет, Хабр. Меня зовут Сергей Фомин. Я старший менеджер продукта Tarantool DataBase. 

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

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

Начинаем разбираться — и выясняется, что есть общая проблема, которая почти всегда повторяется. А именно — изображения. В статье расскажем, что с ними делать — как оказывается, проблема распространённая и до сих пор актуальная.

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

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

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

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

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

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

Когда Алиса, ChatGPT или Perplexity отвечают пользователю и называют конкретный бренд, за этим стоит конвейер из нескольких алгоритмов извлечения и ранжирования. Я разобрал, как он устроен в Google, Bing и Яндексе, и собрал из этого практические выводы для GEO. Все ключевые цифры проверял по первоисточникам - где факт доказан публикацией, а где это исследовательское направление или вторичные данные, помечено отдельно.