Представлен сборник лучших скиллов Cursor Team Kit от разработчиков Cursor:
внутри 18 скиллов, 2 субагента и 2 правила;
есть навыки для написания точного и понятного кода, для мощного ревью, удаления код‑слопа и импорта необходимых библиотек.
А нет ли у вас ощущения, что некоторые известные ИИ модели как-то поскучнели и испортились?
Раньше, бывало, даёшь ему вопрос типа: как скрестить ежа с ужом? - и в ответ получаешь массу разнообразной информации, от религиозных запретов племен Южной Африки до особенностей днк-структур и деталей среды обитания, из которой уже самостоятельно можно извлечь для себя что-то ценное и полезное, в том числе позволяющее при определенных условиях получить такой гибрид. Или нечто функционально похожее на него.
А сейчас он тупо ответит, что так нельзя, но "если вы уточните точный размер и вид, то я смогу дать вам рекомендации" (спойлер: все равно нельзя)
Так я и без тебя знаю что нельзя, ты подумай почему и предложи варианты как обойти проблемы, а не изображай инструкцию к табуретке.
В общем, настолько поумнели, что стали все больше напоминать человека, выучившего учебники и потерявшего навык придумывать решения нерешенных задач. Зачем вы, такие - у нас и без ИИ примерно 8 миллиардов, или сколько там уже, особей, способных процитировать Вики.
AI-нагрузка пришла в прод: Serverless или Kubernetes?
Когда команда приносит очередную AI-фичу, инфраструктуре быстро приходится отвечать на вполне приземлённые вопросы: где её запускать, как масштабировать, что делать с GPU, состоянием и холодным стартом — и во сколько всё это обойдётся после выхода в прод.
Serverless выглядит удобным способом снять часть операционной нагрузки. Kubernetes даёт больше контроля, но вместе с ним добавляет сложность эксплуатации. Универсального выбора здесь нет: решение зависит от характера нагрузки, требований к задержкам, бюджета и того, насколько инфраструктурная команда готова управлять платформой самостоятельно.
21 июля в 20:00 на бесплатном уроке разберём, как сравнивать Serverless и Kubernetes для AI-ворклоадов и какие ограничения учитывать до того, как архитектурное решение превратится в дорогую миграцию. Отдельно посмотрим на холодный старт, работу с состоянием, поддержку GPU, масштабирование и гибридные сценарии.
Другие бесплатные уроки от экспертов по инфраструктуре, Linux, K8s, сетям, безопасности и наблюдаемости собрали в дайджесте.
Нанимают ли ИТ-компании летом — и стоит ли сейчас искать работу
Каждое лето среди ИТ-специалистов возникает один и тот же вопрос: есть ли смысл искать работу в июле или лучше дождаться сентября, когда все, кто принимает решения, вернутся из отпусков? Короткий ответ — искать стоит.
Летом темп найма действительно немного снижается. Часть руководителей и HR в отпусках, собеседования переносятся, некоторые проекты ждут утверждения бюджетов на вторую половину года. Но это не значит, что рынок замирает.
По данным hh.ru, рынок труда в 2026 году остается неоднородным. В одних профессиях работодатели конкурируют за специалистов, в других — конкуренция выше среди кандидатов. Для ИТ сохраняется один устойчивый тренд: опыт и реальные навыки полностью перевешивают дипломы и корочки курсов, а владение ИИ-инструментами названо одним из ключевых конкурентных преимуществ. Поэтому даже летом компании продолжают искать сильных специалистов под текущие проекты, а не откладывают всё до осени.
Теперь про наблюдение у Хабр Карьеры. По их статистике, активность найма в ИТ постепенно становится менее сезонной. Компании продолжают публиковать вакансии даже в периоды отпусков, хотя скорость принятия решений ниже. Многие работодатели используют лето для формирования кадрового резерва и проведения первых этапов отбора — чтобы быстрее закрыть позиции, когда отпускной сезон закончится.
Если вы сейчас в статусе «кандидат» — летнее затишье это ваше преимущество, а не помеха. Хорошее время, чтобы обновить резюме, привести в порядок портфолио, добавить завершенные проекты на GitHub, разобраться с каким-нибудь новым инструментом. Осенью, когда конкуренция за интересные позиции возрастет, такая подготовка будет заметна на собеседованиях.
Главное — не воспринимай лето как потерянные два-три месяца. Если бизнес запускает новый проект в июле — ждать сентября HR не станет.
Мы в SSP SOFT нанимаем сейчас
В SSP SOFT занятость — это не про «отсидеть часы». Это про задачи, которые заставляют думать, искать нестандартные решения и видеть результат своих усилий. Мы предлагаем удаленку, гибрид или офис в Москве и Томске, ДМС, обучение по выбору сотрудника и среду, где мнение сотрудников стараются слышать. Задачи — реальные, коллеги — сеньоры, у кого есть чему учиться.
Сейчас в середине июля мы ищем:
— Ведущего аналитика 1С (финансовый контур, КТ 2000)
— Системного аналитика (Ритейл)
— Разработчика ЦФТ
— Архитектора 1С (Управление Договорами)
Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую Евгении Беловой, директору по развитию персонала: @EvgVBelova в Telegram.
Не забудьте добавить «секретную фразу» в сопроводительное письмо: «Увидел(а) вашу вакансию на Хабре».
💚 Солнечного лета и До новых встреч!
Понял asyncio только когда бот начал зависать под нагрузкой
Писал на Python и честно говоря asyncio воспринимал как магию. Работает и ладно.
Пока однажды бот не завис.
Пользователей было немного, штук двадцать одновременно, но один запустил команду которая делала тяжёлый запрос к внешнему API. Пока запрос выполнялся, бот молчал. Остальные подвисли в ожидании.
Начал разбираться. Оказалось я вызывал синхронную функцию прямо внутри async хендлера. requests.get внутри async def. Это блокирует весь event loop. Все корутины ждут пока эта одна функция не завершится.
Решение простое: либо заменить requests на aiohttp, либо обернуть синхронный вызов через asyncio.to_thread. Второй вариант проще когда менять библиотеку лень:
python
result = await asyncio.to_thread(requests.get, url)
После замены бот перестал зависать. Все одновременные запросы к внешнему API обрабатываются параллельно без проблем, но теперь когда вижу синхронный вызов внутри async функции ощущение что что-то не так.
Кто сталкивался с похожим, как отлаживали?
Обещанная статья про yggvault
Эта статья должна была выйти на Хабре ещё две недели назад. Но спасибо администрации Хабра за безвовзратное удаление самописной статьи: освободившееся время я потратил на финальное доведение проекта до ума. Исправил мелкие баги, улучшил документацию и так далее.
Правда, связываться с Хабром после этого желания больше нет. Поэтому полноценное описание проекта опубликовано на Hackaday, а этот короткий пост — просто выполнение обещания опубликовать статью (в прошлом месяце, ага).
---
Что такое yggvault
yggvault — самостоятельное зеркало релизов и зависимостей, упакованное в один бинарный файл.
Оно забирает выбранные версии проектов с GitHub, GitLab, Bitbucket, Gitea или другого узла yggvault, проверяет их, сохраняет локально и публикует сразу в нескольких форматах.
Один процесс предоставляет:
совместимые с
GOPROXYмаршруты для Go-модулей;репозиторий Composer v2;
исходные архивы
.zipи.tar.gz;JSON API и OpenAPI;
Atom-ленты обновлений;
веб-интерфейс с каталогом, версиями, хешами, командами установки и ссылками на архивы.
Вся фишка в том что внешняя база данных, JVM и тд не нужны. Данные хранятся локально, а уже загруженные версии продолжают раздаваться, даже если исходный forge временно недоступен, заблокирован или упёрся в rate limit.
Зеркало можно поднять локально, на VPS или в домашней сети. Дополнительно yggvault умеет работать внутри сети Yggdrasil — без публичного IP, DNS, проброса портов, root-доступа и отдельного системного демона. (Еще одна причина для статьи — популяризация Yggdrasil)
Несколько узлов могут использовать друг друга как доверенные «братские» зеркала и синхронизировать релизы через обычный Web или Yggdrasil.
Проект не пытается быть полным реестром всех пакетов или прозрачным прокси для всего Go. Его задача проще: надёжно хранить и раздавать выбранные зависимости через контролируемую вами точку.
Репозиторий:
https://github.com/voluminor/yggvault
Работающее публичное зеркало:
https://www.ratatoskr.space/pkg/
Полная статья и технические заметки:
https://hackaday.io/project/206175-yggvault-mirror-your-dependencies-in-one-binary
Всем привет!
Очень много CTF-соревнований проводится с использованием платформы CTFd. Как они сами скромно про себя пишут:
CTFd - The best Capture The Flag framework out there for hiring hackers, training developers, and teaching students.
Я, в одной из своих статей, писал, что полностью автоматическое решение всей CTF-площадки AI- агентом затруднено и перечислил те трудности, с которыми тогда боролся.
Оказывается, у CTFd есть API!
Так вот, работа по API решает тьму из тех проблем, с которыми я тогда столкнулся! Это прям прорыв в моих исследованиях на эту тему!
Для использования API CTFd я написал skill для OpenCode, про который и хочу вам рассказать!
CTFd-Skill — skill, позволяющий ИИ-агенту играть в любой CTF на платформе CTFd через REST API от лица обычного участника: список и чтение задач, скачивание файлов, подача флагов, подсказки, рейтинг, анонсы. Покрывает только player-действия (без админ-эндпоинтов) и работает с любым инстансом CTFd — не привязан к конкретной площадке.
Ключевые возможности:
Подача флагов с обработкой всех статусов задачи и авто-backoff без риска заблокировать себя перебором;
Персистентный журнал под каждую задачу: файлы, solve-скрипты и статусы решения задач переживают случайные перезагрузки;
Авто-обнаружение новых задач и анонсов организаторов (подсказки, уточнения) с классификацией по тегам — ничего не теряется по ходу соревнований;
Интеграция с HexStrike;
... и многое другое.
github.com/Chumikov/CTFd-Skill
Теперь промт на решение всей CTF-площадки может выглядеть так:
Используя CTFd-skill, реши все задачи площадки ctf.url.com, token - ...., формат флага ctf{...}. Все задачи, по которым тебе требуются моё мнение или моя помощь, переноси в конец. Решай все задачи, которые можешь решить автоматически.
Пробуйте, пишите обратную связь, ну поставьте мне лайк тут и звезду проекту на GitHub!
Мой телеграм-канал.
WMS как инструмент контроля затрат на персонал: считаем окупаемость
WMS традиционно относят к статье IT-расходов. Это задаёт неверную точку отсчёта: систему сравнивают с другим ПО, а не с реальной альтернативой — расширением штата.
В новом выпуске подкаста «Сначала процессы» считаем окупаемость через персонал.
Несколько вопросов, которые мы разбираем:
— Почему при росте объёмов дополнительные люди в смене не дают пропорционального роста выработки?
— Куда уходит рабочее время руководителя смены, если задачи раздают голосом и в мессенджерах?
— Что происходит с операционной устойчивостью склада, когда директор по логистике, в чьей голове живёт вся бизнес-логика, уходит?
— Почему ФОТ непредсказуем от месяца к месяцу — и можно ли это контролировать?
— При кадровом дефиците в 30–50% стратегия «нанять ещё людей» остаётся планом?
К выпуску — статья с расчётами по пяти сценариям и Excel-калькулятором.
🎧 Выпуск: https://intekey.mave.digital/ep-5
📖 Статья с расчётами: https://intekey.ru/articles/skolko-stoit-wms-okupaemost-cherez-personal/
Число Пи как теория всего
Физики мечтают о нахождении теории всего. Эта теория будет выражаться уравнением, которое по словам физика Шона Кэрролла, должно поместиться на футболке, и которое позволяет точно описывать абсолютно все процессы, протекающие во Вселенной. Таким образом, теория всего будет одновременно являться полным описанием всей истории Вселенной.
С другой стороны, можно представить себе теорию всего в виде 'все-в-меню' (статья Хаттера 'Полная теория всего'). Это не то, к чему стремятся физики, но, также является вариантом описания Вселенной. Ряд физиков говорит, что число бит, содержащихся во Вселенной, находится в пределах от 10^90 до 10^120 (Universe from bit). Это большое, но конечное число и это является основанием для последующих рассуждений. В совокупности с предположением о дискретности времени предположение выше приводит к возможности записать всю историю Вселенной от Большого Взрыва до любого выбранного времени в будущем в виде одного длинного числа.
На этом пути требуется выбрать определенную кодировку: систему счисления, каким образом будет записываться состояние вселенной и каким образом состояния вселенной будут объединяться друг с другом, но это не меняет конечного вывода. Все история Вселенной будет представлена в виде одного конечного числа, то есть строки символов конечной длины.
Теперь начинается самое интересное. Размышления о вероятности появления в нерациональном числе определенной последовательности цифр привели Эмиля Бореля к понятию нормального числа. Это такое число, в котором вероятность обнаружения строки цифр длины k равняется n^(-k), где n является основанием выбранной системы счисления. Борель далее показал, что абсолютное большинство чисел обладает таким свойством, отсюда появилось и название - нормальное число. Таким образом, рациональные числа пришлось отнести к ненормальным.
Сказанное означает, что нормальное число содержит в себе любое конечное число. Таким образом история Вселенной будет являться частью нормального числа. Более того, нормальное число будет теорией мультиверса, поскольку оно будет включать также в себя все возможные истории вселенных.
Математики полагают, что число Пи является нормальным числом и, таким образом, мы приходим к заголовку заметки: для того, что понять функционирование Вселенной следует просто вычислять последовательность цифр в числе Пи. Правда, следует отметить, что математикам еще не удалось доказать, что Пи является нормальным числом. Если в нормальности Пи есть сомнения, то следует воспользоваться числами, нормальность которых уже доказана.
Идея взята из статьи ниже (см. All-a-Carte).
Hutter, M. A Complete Theory of Everything (Will Be Subjective). Algorithms 2010, 3, 329-350.
Изучаем GitHub за выходные — IT-платформа выпустила подробный роадмап для новичков-разрабочтков, где понятным языком объясняются все тонкости работы с ветками, репозиториями и контролем версий, а также рассказывают, как делать свой вклад в Open Source.
Пользователю не нужен умный ИИ. Ему нужен предсказуемый результат
У генерации LLM есть свойство, которое никакими перепроверками до конца не лечится: она недетерминирована. Как ни защищайся, какие валидации ни навешивай, всегда остаётся процент на галлюцинацию, на неверно понятый промпт, на ответ, которого вы просто не предусмотрели. Это не баг конкретной модели — это её природа.
И вот тут начинается самое неприятное — не для инженера, а для бизнеса. Человеку, далёкому от ИИ, слово «галлюцинация» ничего не объясняет и ничего не извиняет. Он не обязан знать про температуру сэмплирования и вероятностную природу вывода. Он видит другое: продукт не работает.
При этом мы сами раз за разом требуем от умной модели ровно того, чего она не умеет: понятного, повторяемого, детерминированного поведения.
Проще всего это объяснить через людей.
Есть умный сотрудник. Он придумает, как решить задачу, которую до него никто не решал. Есть исполнительный сотрудник. Он, может, и не придумает нового, зато будет исправно следовать инструкции, раз за разом выдавая один и тот же результат.
А теперь попробуйте нагрузить рутиной умного — скажем, топ-менеджера. В понедельник у него нет настроения. В среду он понял задачу по-своему и сделал красивее, чем просили. В пятницу вообще предложил всё переделать. Каждый раз — по-разному, и каждый раз со своей логикой.
С умной LLM ровно то же самое. Не нужно требовать от неё, чтобы она одинаково решала одну и ту же задачку. Нужно просить её о другом — написать инструкцию для тупой программы.
Как мы на это напоролись: документооборот для бухгалтеров
Теория теорией, а пришли мы к этому через собственные грабли.
Была небольшая автоматизация документооборота. Решали в лоб, как решают все: сделали интерфейс, где бухгалтер пишет задание, прикладывает шаблон и получает готовый документ. Логично же.
На практике вышло так. Человек получает не тот результат — сразу или со второй попытки. Пробует ещё раз, формулирует иначе, получает третий вариант, тоже не тот. И — разочаровывается. Не потому, что продукт плохой, а потому что он непредсказуемый, а бухгалтер — человек, которому предсказуемость дороже технологий.
Двухуровневая структура: LLM пишет программу, программа делает документ
Тогда мы перестроили пайплайн.
Теперь бухгалтер с помощью ИИ не делает документ. Он с помощью ИИ пишет программу, которая делает документы по шаблонам — и работает всегда детерминированно.
Разница выглядит тонкой, а меняет всё:
Написал программу один раз корректно — она будет корректно отрабатывать всегда. Не «в 95% случаев», а всегда.
Написал некорректно — можно указать на ошибку, она поправится, и правка тоже закрепится навсегда.
Вылез corner case, в котором программа должна вести себя иначе, — поправил, и это осело на уровне программного кода, а не на уровне промпта.
Вот последний пункт — самый важный. Правка в промпте живёт до следующей генерации и в любой момент может «разъехаться». Правка в коде остаётся правкой в коде. Модель отработала свой недетерминированный номер один раз — на этапе написания программы, под присмотром человека. Дальше работает обычный, скучный, честный код.
Модели отдаём разовое творчество: разобраться в задаче, перевести человеческую формулировку в логику, собрать программу. Коду отдаём исполнение: раз за разом, одинаково, без настроения и импровизаций.
Умного сотрудника не сажают заполнять накладные. Его просят написать регламент, по которому накладные будет заполнять тот, кому это нравится.
Что это даёт бизнесу
Главное — предсказуемость, а вместе с ней доверие. Пользователь перестаёт играть в рулетку и получает систему, которая ведёт себя одинаково. Ошибка становится не поводом разувериться в ИИ, а обычным багом: нашли, поправили, закрепили.
А ещё это дешевле: модель дёргается один раз при создании программы, а не на каждом прогоне.
Так у нас и заработала двухуровневая структура. Наверху — умная, творческая, непредсказуемая LLM. Внизу — тупая, надёжная, предсказуемая программа. Каждый на своём месте и занят тем, что умеет.
По роду своей деятельности нашей команде постоянно приходится сталкиваться с обходом физической безопасности: будь-то биометрия, СКУД или обычные “амбарные” замки. И как бы не казался большой металлический “кирпич” неприступной крепостью, вскрыть его (при этом вскрыть без повреждений) зачастую оказывается упражнением с низким уровнем сложности.
В рамках нашего очередного исследования, мы приобрели ряд навесных замков с биометрией по отпечатку пальца. И, очевидно, целью исследования мы ставили обход биометрии. В итоге, после детального разбора как аппаратной, так и программной части, мы нашли как минимум 2 негласных пути взлома.
Причиной вскрытия в первом методе, как можно наблюдать на видео, является слабая пружина запорной пластины, которая под действием перегрузки сдвигается и высвобождает наружную скобу. Как итог: прикладываем небольшую силу (например, удар) и замок открывается.
Второй путь - заложенный производителем бэкдор, который при наборе определенной комбинации на замке его просто открывает. Ужас начинается тогда, когда мы попробовали воспроизвести этот код на остальных образцах исследования: все замки имеют встроенную уязвимость (спасибо восточным партнерам за унификацию). В результате, 1-2 минуты и дверь открывается.
По понятным причинам, мы не будем публично раскрывать эксплойт, но уже уведомили об этом производителя и сделали запрос на присвоение CVE/BDU. Как говорится, ждем-с.
Кроме того, уязвимостью также может быть неправильный выбор материала замка (изучаем физику). Если запорная пластина выполнена из металла, подверженного намагничиванию, то отодвинуть ее можно с помощью простого магнита. Второе видео, скорее всего, является постановочным, но как вектор атаки его никто не отменял. К слову, этот метод был опробован первым в исследовании биометрических замков, однако инженеры предусмотрели такой вектор атаки: запорная пластина выполнена из дюралюминия и не подвержена действию магнита.
Подводя краткий итог, могу с уверенностью сказать, что выражение
Все замки от честных людей
появилось не просто так и действительно является правдой. Поэтому, выбирать инструменты или оборудование для организации защиты нужно с умом: злоумышленники думают не стандартно и не всегда идут напролом по предложенному пути.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
MWS AI выпустила Cotype Pro 3, мультимодальную модель для агентских сценариев
MWS AI представила новую флагманскую модель линейки Cotype — Pro 3 (27 млрд параметров). Ранее в этом году вышла компактная версия — Light 3 (9 млрд параметров). Обе модели мультимодальные: работают с текстом и изображениями и ориентированы в первую очередь на построение многошаговых ИИ-агентов и мультиагентных систем.
Коротко о технических характеристиках:
Контекстное окно обеих моделей — 262 тысячи токенов (примерно 600 страниц текста, то есть весь пакет договоров по сделке или годовой отчёт с приложениями можно держать в памяти целиком).
Обе модели разворачиваются в закрытом контуре на серверах заказчика, в том числе под управлением Astra Linux, могут быть дообучены на корпоративных данных клиента.
Минимальное железо — видеокарта A100.
Поддерживается квантование и MTP (multi-token prediction, одновременное предсказание нескольких токенов) — для более высокой скорости генерации на менее мощном железе без потери качества.
Доступны отдельно или в составе MWS AI Agents Platform.
Подтверждена совместимость со всеми компонентами отечественных программно-аппаратных комплексов.
Обучение моделей семейства Cotype проводится на мощностях MWS Cloud.
Главная фишка моделей - стабильность в агентских сценариях и русском языке
Готовых бенчмарков под корпоративные агентские сценарии на русском рынке практически нет, поэтому в MWS AI собрали собственный — из 178 задач. Каждая задача помещает модель в одну из пяти рабочих ролей:
оператор поддержки — вопросы по услугам, подпискам и списаниям абонента;
консультант по тарифам — подбор и смена тарифа под фактическое потребление;
кадровый специалист — расчёт отпускных и больничных, работа с документами;
аналитик по компаниям — досье на юрлицо по ИНН: финансы, руководители, связи с другими организациями;
инспектор налоговых рисков — расследование схем переноса бизнеса между компаниями и решение о назначении проверки.
В каждом сценарии проверяется не только правильность ответа, но и то, как модель пользуется инструментами и соблюдает бизнес-правила.
Помимо доли полностью решённых задач, отдельно считали воспроизводимость — насколько стабильно модель выдаёт одно и то же решение при повторных обращениях к одной и той же задаче. Логика простая: для продакшн-агента куда важнее не пиковый результат на бенчмарке, а гарантия, что при тысячном обращении будет тот же корректный ответ, что и при первом.
Результаты (полнота решения / воспроизводимость):
Cotype Pro 3: 92,2% / 79,1%
Cotype Light 3: 88,6% / 73,9%
Cotype Pro 2.6: 80,5% / 62,5%
Отдельно измеряли устойчивость генерации на русском (отсутствие случайных переключений на другой язык, повторов и искажений текста). Тест прогнали на корпусе почти в 304 тысячи слов, модель Pro 3 выдала 99,79% текста на русском без языкового дрейфа, Light 3 — 99,87%.
Заказ демо для бизнеса на сайте
Ближайшие события
FinOps по фасттреку: как искать экономию в облаке и не сломать сервис
FinOps часто описывают как полноценную методологию: Inform, Optimize, Operate, процессы, роли, регулярная аналитика, отчётность и культура потребления.
Но на практике российские компании часто приходят с другим запросом: “мы много платим за облако, нужно быстро понять, где можно снизить расходы”.
В новом выпуске «Практики FinOps» поговорили с Вячеславом Бессоновым, генеральным директором Hilbert Team.
Обсудили, как выглядит FinOps по фасттреку: когда не строят сразу всю методологию, а начинают с quick wins, анализа биллинга, гипотез оптимизации, расчёта ROI и проверки, не сломает ли экономия рабочий сервис.
В выпуске разбираем:
почему облачного биллинга часто хватает только для первого среза
какие задачи закрывают FinOps-инструменты, Excel и Python notebooks
почему гипотеза оптимизации не равна готовому решению
как считать оптимизацию как отдельный IT-проект
когда quick win может дать 5–10%, а когда 20–30% требуют серьёзной переработки архитектуры
почему теги у заказчиков всё ещё скорее исключение, чем правило
как делить общую инфраструктуру между продуктами и cost centers
чем отличается экономика on-prem от облака
почему будущее FinOps движется к подходу workload first
как AI-токены становятся новой частью unit-экономики
Отдельно поговорили о российском рынке: неунифицированном биллинге, сложностях мультиоблачной и гибридной инфраструктуры, резервах, внутреннем биллинге и том, почему полноценная фаза Operate часто не начинается, даже если компания уже нашла первые точки экономии.
Смотреть выпуск
Слушать выпуск
Telegram Player
Яндекс Музыка
VK Музыка
«Практики FinOps» — cообщество для тех, кто управляет затратами на IT-инфраструктуру и хочет обсуждать FinOps на практических кейсах. Мы в телеграм.
AviTalk: как за три месяца объединить два продукта и не сломать команду
Новый выпуск AviTalk — разговор с CTO направления «Авито Товары» Александром Швецом. Ведущий — Виктор Раев, руководитель разработки юнита Services Base.
Александр рассказывает, как устроена разработка в Авито Товарах: категорийный подход, слияние продуктов после объединения Яндекс Еды и Delivery Club, и почему опыт из бигтеха плохо переносится на решения «на веру» в стартапе. Отдельно — про AI в процессах команды: как быстро внедрять прототипы, зачем нужна «примерка» товаров и одежды через нейросети и куда вообще движутся такие эксперименты.
Кроме продуктовой части — разговор о людях: с чем сталкивается разработчик, дорастающий до руководителя, как справляться с синдромом самозванца и стрессом, и что Александр посоветовал бы себе в начале карьеры.
Смотреть выпуск:
AviTalk — шоу толковых людей. Гости — сотрудники Авито из разных дирекций и команд, которые делятся своей экспертизой и профессиональным путём.
В Open Source под лицензией Apache License 2.0 выложен проект Grok Build — это терминальный агент для разработки программного обеспечения на основе искусственного интеллекта от SpaceXAI.
Решение работает в виде полноэкранного интерфейса пользователя, который понимает код, редактирует файлы, выполняет команды оболочки, осуществляет поиск в интернете и управляет длительными задачами — в интерактивном режиме, в безголовом режиме для написания скриптов/CI или встроен в редакторы через протокол Agent Client Protocol (ACP).
Задача о 17 серверах и сетевом архитекторе
Привет, Хабр! Принесли задачу — попробуйте ее решить и сверить ответ с нашим.
Условие
В одной придуманной нами компании N сетевой архитектор получил задачу: развернуть изолированный контур из 17 серверов. Для обеспечения отказоустойчивости он решил соединить их напрямую патч-кордами так, чтобы от каждого сервера отходило ровно три кабеля к соседним машинам. Архитектор набросал схему и со спокойной душой ушел домой.
На следующее утро на смену заступил дежурный инженер. Взглянув на ТЗ и схему коллеги, он лишь покачал головой, налил кофе и заявил: «Сеть построить не получится, архитектор где-то просчитался».
Может, дежурный просто вредничает или не хочет обжимать лишние провода? 17 серверов — не так много, а три порта на каждом — стандартное требование для резервирования каналов. Или все-таки инженер прав, и законы математики выше в приоритете, чем фантазия архитектора?
Задача
Вы — старший системный архитектор. Помогите коллегам разобраться, кто прав: архитектор или дежурный инженер? Напишите небольшую программу на Python или другом языке, которая проверяет принципиальную возможность существования подобных сетей для любого количества серверов и соединений.
Узнайте решение в Академии Selectel.
Представлен открытый проект Send it, with PairDrop (веб-версия проекта) — AirDrop для всех. Это универсальный способ передачи файлов на ПК и мобильных устройствах в браузере между Windows, Linux, Android, iOS, macOS и другими ОС:
работает без скачиваний драйверов и утилит и дополнительного ПО;
просто открываем сайт на обоих устройствах в браузере и начинаем передачу;
если используете одну сеть Wi‑Fi — устройства сразу увидят друг друга;
если используете разные сети — нужно один раз ввести шестизначный код, создать пару устройств, и дальше устройства будут находить друг друга автоматом;
передача файлов идем напрямую между устройствами;
можно передавать большие объёмы данных без ограничений.
npm 12 больше не запускает скрипты установки зависимостей без разрешения
npm 12 больше не запускает скрипты установки зависимостей автоматически и требует отдельно разрешать установку из внешних источников и Git. Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации. В посте разбираем, что это меняет для безопасности установки пакетов и что стоит проверить перед обновлением.
8 июля 2026 года GitHub выпустил npm 12 и пометил его тегом latest. Вместе с новой версией изменился базовый сценарий установки – раньше скрипт зависимости мог выполниться автоматически, теперь проект должен заранее разрешить его через allowScripts.
Ограничение распространяется на preinstall, install, postinstall и неявные сборки через node-gyp. Если такой скрипт действительно нужен, его можно добавить в список разрешенных; для разбора уже существующего проекта npm предлагает команду npm approve-scripts --allow-scripts-pending, которая показывает зависимости без явно заданного решения и помогает сохранить настройки в package.json.
Тот же принцип теперь применяется к зависимостям из Git и удаленным архивам. Без --allow-git npm откажется устанавливать Git-зависимости, а для архивов по внешним URL понадобится --allow-remote. В июньском анонсе npm 12 GitHub отдельно отмечал, что Git-зависимости создавали обходной путь для выполнения кода даже при использовании --ignore-scripts.
Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации: в начале августа 2026 года они потеряют доступ к чувствительным операциям управления аккаунтами, пакетами и организациями, а позднее не смогут напрямую публиковать пакеты. Для автоматической публикации GitHub рекомендует переходить на доверенную публикацию через OIDC или использовать публикацию с ручным подтверждением.
Почему это важно
Новые настройки заметно сужают возможности для атак через установочные скрипты. Это хорошо видно на примере Shai-Hulud и Shai-Hulud 2.0. В первой вредоносные версии пакетов в основном запускали код через postinstall, а во второй для этого использовался preinstall. Однако важно понимать, что вредоносный пакет по-прежнему может попасть в реестр и дерево зависимостей, а нежелательный код выполнится позднее, когда его импортирует приложение или система сборки. npm 12 закрывает не весь путь заражения, а именно автоматическое выполнение кода непосредственно во время установки. Более широкий разбор атак через пакеты и другие звенья цепочки поставки есть в нашей статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».
Перед переходом на новую версию командам стоит проверить:
какие зависимости действительно используют установочные скрипты
откуда в проектах появляются Git-зависимости и удаленные архивы
есть ли в CI долгоживущие токены публикации с лишними правами
Подписывайтесь на Codescoring в Telegram, VK, YouTube и Макс.
На Бирже заказов Инфостарта опубликована новая подборка задач по 1С за неделю с 9 по 15 июля. В списке - доработки типовых и отраслевых решений, обмены, перенос данных, настройка документооборота, участие во внедрении ERP и консультации.
Биржа помогает заказчикам находить специалистов под конкретные задачи, а исполнителям — выбирать проекты по своей специализации и загрузке.
Донастроить БИТ.ФИНАНС и БИТ.СТРОИТЕЛЬСТВО по готовому техническому заданию
Настроить правило согласования договора в 1С:Документообороте 3.0
Платная консультация «Из 1С в S3 и обратно. Работа с объектным хранилищем»
Разработать обработку для УПП по формированию файла электронной транспортной накладной для РТУ
Сопровождение 1С:УАС, ЗУП, Бухгалтерии и доработка блоков под задачи
Базовая настройка и небольшие доработки для торговой компании
Настроить регулярный обмен из отдельных ЗУП ПРОФ/КОРП в общую ЗУП
Нужен консультант-аналитик 1С (Middle) для сопровождения системы в ОПЭ
На Бирже заказов Инфостарта можно найти исполнителя для консультации, исправления ошибки, доработки конфигурации, настройки обмена, переноса данных, сопровождения или участия во внедрении. Для исполнителей это источник задач разного масштаба — от небольших доработок до проектной работы.