Все потоки

redb 4.2.0: единый контракт трассировки, коннектор AS4 и семь шаблонов проектов

Вышла 4.2.0 сразу по четырём продуктам экосистемы: хранилище redb, интеграционный фреймворк redb.Route, рантайм redb.Tsak и OpenID-сервер redb.Identity.

Коротко о главном.

Безопасность. В Identity выход из сессии теперь действует на сессию самого браузера: userId в запросе больше не выбирает, кого разлогинить. Полный выход отзывает не только сессии, но и гранты. Отозванный ключ подписи больше не предлагается никому по построению, а не по порядку регистрации. В Tsak модуль с http-входом, у которого никто не проверял учётные данные, теперь просто не стартует. В Route ssl=true у RabbitMQ honoured на всех путях подключения, включая именованные фабрики, где TLS не включался вовсе.

Ломающее. Трассировка стала единым контрактом в ядре, и ему следуют все транспорты: спаны приёма стали корневыми, сообщение без контекста открывает свой корень, имена спанов несут назначение. Форма трасс меняется на полутора десятках коннекторов, от Kafka и RabbitMQ до gRPC, SOAP, AS2 и AS4. Очереди seda: и vm: ограничены по умолчанию тысячей, как в Camel. Типизированное чтение заголовка или тела падает на непарсящемся значении вместо тихого значения по умолчанию.

Новое. Коннектор AS4 (eDelivery AS4 1.16 поверх ebMS 3.0) рядом с AS2.

Коллекция из семи шаблонов проектов redb.Templates. Входная аутентификация Basic и Bearer на http:-потребителях и Rest(...).

тут страничка с чего начать

RedbQuery умеет вернуть один объект, количество или да/нет, фильтровать и сортировать по базовым полям.

Полный текст выпуска со всеми ломающими изменениями и ссылками на релизы: redb 4.2.0.

Если было полезно, ⭐ на GitHub поможет другим это найти.

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

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

Один рассказывает, что взял на бирже проект компьютерного клуба, нужно на их сайте сделать лидерборд для чемпионата. Сказал, что сделал за несколько вечеров, сейчас не может со своего сервера перенести на их сервер. Говорит, на моем запускается, копирую всю папку, на их не работает. Сейчас с ботом разбираются, в чем проблема. Токены, говорит, уходят влёт! Каждый вечер аккаунты меняет. Другой советует, ты им отдай вместе с сервером, себе новый возьмёшь, первый говорит, у меня там ещё 2 проекта. Думаю, огонь — облачные технологии, кубернетис с неймспейсами!

Дочь, к сожалению, качели недолюбливает, трусиха, быстро расхотела качаться, пожелала лазить по забору, тут уж я трусиха, пришлось идти подстраховывать, а эти кореша продолжили свой бэкенд толкс, аж завидно, я б послушал!!!

Сильно сомнительно, что на этом они много зарабатывают — я б лидерборд без всяких ботов за пару вечеров вкрутил лет 20 назад (когда с качельками проблем не было — у меня в то время вечер заканчивался утром) — и это стоило копейки. Важнее то, что это тоже навык, тоже прокачивается, и при известной доле настойчивости и везения, они быстро научатся зашибать лёгкую деньгу. Тем более у них есть такой хороший инструмент, который туупыые америкосы нахаляву раздают! И никаких тестировщиков, никаких аналитиков, архитекторов, менеджеров — навайбкодил и в продакшон! ))

Мм, лепота!

Тестирую недавно вышедшую SOM (system one model) Laya для наделения CanvasDesk сверхсилами по автодополнению.

Как пользователь, я хочу чтобы проектирование в CanvasDesk было с молниеносным флоу. Я решил тестово прикрутить под это Laya - свежий open-source аналог нашумевшего облачного движка Jev от TypeSafe AI.

Почему не обычная LLM? Большие языковые модели для подсказок в реальном времени не годятся их генерация съедает от секунды до трёх. Я бы не стал ждать автогенерацию так долго. Jev и Laya - из класса System One Models: модели "быстрых интуитивных реакций". Они не разворачивают текст токен за токеном, а за один проход решают типизированные задачи: классифицируют, ранжируют варианты и выдают калиброванную вероятность.

Jev сидит в закрытом облаке по API. Laya вышла под Apache 2.0 и полностью совместима с ним по протоколу, но разворачивается локально. Размер ~421 миллионов параметров. Задержка около 33 мс на GPU и 200–450 мс на обычном офисном CPU. Не требует гонять контекст схемы через внешнюю сеть - для CanvasDesk в b2b исполнении это принципиально.

Что это даёт на практике:
1/ автодополнение формул и переменных: набираешь расчёт нагрузки, система цепляет переменные из апстрим-узлов и предлагает формулу, проверенную локальным парсером,
2/ next-node подсказки: поставил шаблон балансировщика - движок предлагает связать его с очередью и пулом воркеров,
3/ адаптация под роль: архитектору - параметры теории очередей, продакту - связки конверсий и когортного LTV.

Задача Laya - работать умным стрелочником: отбирать лучшие паттерны из каталога за доли секунды и отдавать их только при высокой уверенности. Если эксперимент взлетит, сборка схем перестанет быть укладкой асфальта вручную.

Пока заворачиваю Laya в локальный sidecar на базе python. Результаты теста и замеров скорости выкачу отдельным постом.

А пока можно самостоятельно потестить WASM версию CanvasDesk и написать в комментарий про свой опыт

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

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

Поэтому я пилю MyTinyIDP — Internal Developer Platform на основе CNCF-подхода, Kubernetes и GitOps.

Идея простая: через единый портал разработчик — и его старший брат его менеджер продукта — создаёт проект или сервис, а платформа сама подготавливает репозиторий, окружение, доступы, инфраструктуру и доставку приложения.

Сервис собирается без ручного написания Dockerfile: Cloud Native Buildpacks определяют стек, собирают OCI-образ и публикуют его в registry, после чего Argo CD доставляет приложение в Kubernetes.

Под капотом — Backstage, Argo CD, Argo Workflows, Argo Events, Crossplane. Открытые компоненты, декларативная модель и минимум привязки к конкретному облаку.

Рабочий прототип уже есть.

Ну, «рабочий» — ну так :) Пока вопросов там больше, чем ответов. Но оно уже живёт, что-то создаёт, что-то деплоит...

Так что если в этом чатике есть люди, которым близки Platform Engineering, CNCF, GitOps и нормальный Developer Experience, и которые тоже считают, что пора перестать в каждой компании заново изобретать собственный DevOps — давайте пилить вместе.

Что будет с монетизацией — пока не знаю.

Зато свой golden path устроим. То есть вдруг есть энтузиасты, пишите, расшарю репо и тд. :)

З.Ы. Может показаться что это чатик написал, но нет. У меня реальная попаболь от всего происходящего и я хочу поменять правила игры.

Напишем сами. С ИИ за год

После ухода SAP и Oracle компании надеялись, что западные вендоры вернутся. По наблюдению Алексея Телкова, генерального директора «Галактики», сегодня ждать перестали точно все и некоторые перешли на модель «сами напишем». На вайб-коде и за год. Касается это любого корпоративного ПО, которое не хочется менять на продукт российского вендора. 

Звучит почти бесплатно. Потом в смету приходят видеокарты последнего поколения, подписки на модели, свои серверы и команда из 50 с лишним человек. Которая, как предполагается, тоже ничего не стоит.

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

Как правильно считать TCO своей разработки и что будет с рынком интеграторов, в пятом выпуске подкаста «IT-фронтир». 

Смотреть на VK Video, Rutube и YouTube.

Open-Spec вместо Open-Source

Пытаюсь тут написать сервис полностью по SDD (описываешь спеку и агент генерит по ней код) и такая мысль пришла. Раньше, когда ты хотел показать, что в твоем коде нет закладок или его можно переиспользовать — то выкладывал исходники. А сейчас, по идее, можешь выложить очень подробную спеку и твой сервис по ней пересоберут.

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

Отсюда другая мысль: мы теперь системные аналитики или технические писатели? Ведь по сути анализ (до какой-то границы) можно так же скинуть на агента

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

С карты произошло внезапное списание, прямо на глазах

Проверил в сбербанк — онлайн, списание действительно произошло.
При том что карта условно лежит в кошельке, который лежит на столе (и она действительно там). Первая мысль — это где‑то были спалены/слиты реквизиты.

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

Быстрый поиск показал, что действительно существует сети магазинов «Классный колбасный», но ближайший из них в 1000 км.

Зачем этот пост? Я до сегодняшнего момента был уверен что это не возможно, и решил поделиться с сообществом. Кроме того было бы клёво получить комментарии @Sber на этот счёт. Какова вероятность ошибки «Оплаты улыбкой» и как часто возникают такие ситуации?

Представлен клон MS Word — открытый проект под названием EdenText для работы с docx‑ и dot‑документами прямо в браузере. Возможности проекта:

• автоматическая нумерация, колонтитулы, оглавление, сноски, поля и прочее.

• можно устанавливать стили абзацев, таблиц и других элементов.

• возможности по работе с таблицами и даже формулы как в Excel.

• вставка изображений и подписей к ним.

• знает русский язык и правила орфографии и грамматики.

• работает без интернета, без регистрации и без лицензионных ключей.

Недоумения пост...

В п. 5 ч. 2 и п. 5 ч. 3 ст. 6 Федерального закона от 26.07.2026 № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации» сказано:

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

Надеваем шляпу разработчика БФМ и размышляем: а как мне научить мою будущую ИИ-модель не просто духовно-нравственным ценностям, а именно традиционным и именно российским? Ждать упомянутый акт Правительства РФ бессмысленно: он о порядке подтверждения, т.е. это процедурный документ. А нам тут над смыслами надо думать…

В Основах государственной политики по сохранению и укреплению традиционных российских духовно-нравственных ценностей, утв. Указом Президента РФ от 09.11.2022 № 809, есть определение «традиционные ценности» (п. 4) и что к ним относится (п. 5). Человеку это все более-менее понятно. А как этому научить ИИ-модель?

Ну хорошо, обучение модели – это вопрос данных. Для каждой ценности можно попробовать подобрать соответствующий корпус, тезаурус и/или онтологию, а то и не один/одну. И вроде как научить модель тому, что «хорошо», может получиться. Но что там с единством противоположностей, диалектикой Гегеля и/или материалистической диалектикой Маркса/Энгельса? Даже не философ легко вспомнит Владимира Маяковского «Что такое хорошо и что такое плохо?». Без «плохого» не получится обозначить «хорошее». Соответственно, ИИ-модель надо «научить» и плохим вещам, конечно же сопровождая это отрицательными весами и другими маркерами со знаком минус.

Допустим, молодой неокрепший разум зашел в сеть и спросил очередную БФМ: «Вокруг все говорят, что быть экстремистом нехорошо. Кто такие экстремисты? Я не хочу быть на них похож». Если модель не видела ни байта экстремистских материалов, то она в ответ может просто сгаллюцинировать. И ладно бы просто придумает что-то абстрактное и несуществующее, а если возьмет и отнесет, например, какую-то из мировых религий к экстремизму? А молодой разум все это возьмет на вооружение (ведь БФМ же прошла проверку, врать в этом вопросе не может) – и вот оно готовое «разжигание»…

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

1) размещение экстремистских материалов запрещено (ч. 6 ст. 13.15, ст. 13.37, ст. 20.3, ст. 20.29 КоАП РФ; ст. 282.4 УК РФ);

2) поиск экстремистских материалов запрещен (ст. 13.53 КоАП РФ).

Т.е. искать и негде, и нельзя.

Не понимаю, как эту проблему преодолевать: инженерная задача (обучить модель) превратилась в юридическое препятствие (как научить правильному и правильно научить неправильному). Тут либо ждать какое-то специальное законодательное разрешение наподобие ч. 2 ст. 10 закона № 243-ФЗ, либо вместо книги одного небезызвестного австрийского художника отдавать ИИ-модели материалы Нюрнбергских процессов (с какими-то направлениями экстремизма это может сработать, но не со всеми). Впрочем, если под эгидой государства и под контролем правительственных структур создать специальный банк экстремистских материалов (не просто заголовки с кратким описанием, а полностью с содержимым, с разметкой, весами и т.п.) исключительно для обучения ИИ-моделей и с предоставлением доступа исключительно сертифицированным/лицензированным разработчикам БФМ – как вариант…

На Бирже заказов Инфостарта за неделю с 23 по 30 сентября появились задачи для разработчиков, консультантов и аналитиков 1С.

Заказчикам нужны специалисты по Бухгалтерии, УНФ, УТ, Документообороту, КА, УПП, ERP, мобильной платформе, ККМ, обменам, маркетплейсам и интеграциям.

• Обследовать три базы 1С:БК 3.0 для выгрузки денежных данных в SQL/DWH

• Отложенный платеж для заявок на оплату

• Доработка выгрузки данных из 1С 7.7. в формате EnterpriseData 1.6

• Разработать схему перепродаж в группе компаний с Автоматизацией в УНФ 3.0

• Доработка «Подключение сканера к 1С:Предприятие 8.3 в режиме совместимости с 8.2»

• Проверить формат обмена данными ККМ с «Честным Знаком»

• Обучение работе в конфигурации 1С:Транспортная логистика, экспедирование и управление автотранспортом КОРП.

• Восстановить исходный код конфигурации 1С из APK мобильного приложения для ТСД

• Заказ по статье «Где деньги, Зин? Или как загрузить информацию из банка, если у вас 200 000 операций в день?»

• Доработка «Прием оплат от клиентов через PayKeeper в 1С:Управление предприятием 2»

• Настройка сопоставления и выгрузки товаров (с характеристиками и фото) через Synchrozon и SynchroWB в 1С:УНФ 3.0

• Написать обработку трансляции контрагентов и их договоров из УТ 11 в справочники расширения контур логистика.

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

🔖 Наконец‑то дождались: git branch ‑delete‑merged

У нас у всех есть куча проектов. Мы работаем над фичами. Каждая фича — отдельная локальная ветка. Мы её делаем, пушим, открываем PR, PR мержат, ветку на сервере удаляют.

А локальная ветка остаётся. И так каждый раз. Через полгода у тебя в git branch тридцать восемь веток:

  feature/login
  feature/login-fix
  fix/typo
  topic/auth
  topic/auth-v2
  ...
  main

И ты такой сидишь и думаешь: «Какая из них ещё живая? Какие уже смержены? Можно ли что‑то удалить или я что‑то потеряю?».

И вот ты уже пишешь скрипт на коленке, который тебе должен всё почистить. Запускаешь его и вуаля, ты слегка ошибся и больше в твоей репе нет бранчей, паника и судорожный поиск решения на ohshitgit.com.

В общем, короче. Harald Nordgren походу сам задолбался с этим и ребята только что релизнули Git 2.56, в котором запилили опцию delete‑merged.

Самое классное, что команда супер простая и простая как полено (хоспадепрости patch‑format с 100 500 аргументами).

$ git branch --delete-merged 'origin/*' --dry-run
Would delete branch feature/login (was abc1234).
Would delete branch feature/login-fix (was def5678).
Would delete branch fix/typo (was 9876fed).

Посмотрел. Всё выглядит нормально. Запускаешь без --dry-run:

$ git branch --delete-merged 'origin/*'
Deleted branch feature/login (was abc1234).
Deleted branch feature/login-fix (was def5678).
Deleted branch fix/typo (was 9876fed).

Всё. Ветки, которые уже влиты в свой origin, снесены. Ветки, где есть неотправленная работа, — остались. Ветки с deleteMerged = false — остались. Ветки, которые ты вычеканил в другом worktree, — остались.

Это безопасно. Свои скрипты можно выкинуть. Также можно точечно чистить категориями topic-*, feature/*, origin/*.

В общем, если git branch уже не помещается в терминал — обновляемся на 2.56 и теперь вы знаете что делать.

Telegram | Github | YouTube | X

API Security на практике: что проверить в API перед продом

API может быть закрыт авторизацией, работать по HTTPS и стоять за WAF — и при этом оставаться уязвимым. Например, пользователь успешно вошел в аккаунт и запрашивает /orders/125. Если сервер позволяет заменить 125 на 126 и получить чужой заказ, пароль взламывать вообще не нужно: проблема не в аутентификации, а в том, что API не проверяет права на конкретный объект. 

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

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

• Входные данные и запросы сервера. Параметры, JSON, имена файлов и URL нельзя без проверки передавать дальше в SQL-запросы, команды или внутренние сервисы. Иначе появляются инъекции и SSRF — вплоть до запросов к ресурсам, которые вообще не должны быть доступны извне. 

• Бизнес-логику. Иногда API технически работает правильно, но им легко злоупотребить: бот может перебрать промокоды, занять все слоты бронирования или отправить тысячи SMS-кодов, за каждый из которых платит компания. Обычного общего rate limit здесь бывает недостаточно — ограничения нужно задавать именно на чувствительные операции. 

• Старые и тестовые версии. API меняется, а забытый endpoint может продолжать работать со старой аутентификацией, лишними правами или уязвимыми зависимостями. Поэтому важно вести инвентаризацию методов и версий и отключать то, что больше не используется. 

• Защиту на уровне инфраструктуры. WAF может отфильтровать часть веб-атак, API Gateway — централизовать правила доступа и лимиты, DDoS-защита — отсечь большой поток до сервера. Но эти инструменты не исправят ситуацию, если само API не проверяет, имеет ли пользователь право выполнить конкретное действие. 

В статье собрали основные риски из рейтинга OWASP API Security Top 10, разобрали аутентификацию и авторизацию, SSRF и инъекции, атаки на бизнес-логику, работу с секретами, WAF, API Gateway, rate limiting и мониторинг. В конце — чек-лист, по которому можно пройтись по своему API и понять, где искать основные пробелы в защите. Если хотите пройти проверку целиком, читайте материал в блоге Рег.облака.

Лента за 29.09.2026 г.

В bodyscript.me (канал об издевательствах над собой) порассуждали о том, как ставить и контролировать эксперименты с весом.

Теперь про алгоритм проведения экспериментов и контроля их результата.

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

Сейчас идём от простой отправной точки: предиктор выбран, споры с самим собой и окружающими о его бессмысленности прекратились, надо просто проверить, работает он или нет.

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

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

Единственное изменение — предиктор. Не пить во время еды и после неё 2 часа.

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

Если отклонился от эксперимента, неважно по какой причине — начинай заново, со следующего дня.

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

Если за неделю результат очевидно есть — можно на этом и остановиться (в смысле эксперимент остановить). Если результата нет, или он невнятный (типа минус 200 г. за неделю) — лучше потерпеть ещё неделю.

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

В Жёлтым по белому вышла первая серия курса «Бизнес‑скелет».

1. https://vkvideo.ru/video-208482299_456239504

2. https://youtu.be/ULVxj6TlS14

Один мой друг, не я, проходил собеседования на Java Senior. Любопытна статистика результатов. 13 собеседований.

Общие вопросы разработки (теория, кодревью, иногда простой лив-кодинг) были на 12 собесах, в 11 случаях всех все устроило (правда, в одном случае поставили чуть ниже ожиданий, но не заблокировало). Это 11/13, но там где не провели интервью - там посмотрели предыдущие фидбеки (то есть по умолчанию ОКнули). Так что 12/13=92% ОК

Алгоритмическая секция была на 4 интервью, в 1 случае выше ожиданий, в 1 по норме, в 1 чуть ниже ожиданий (по мнению интервьюера) но формально отказ, в 1 прям так себе. Кто не проводил - очевидно для них не очень важна эта составляющая, так что считаем от них ОК и пишем 10/13=75% ОК

Системдизайн был по плану на 3 интервью, хотя внезапно вылез еще на 2 посреди другого этапа :) в 2 случаях ОК, в 3 посчитали что слабовато. По тому же принципу что если не спросили то не важно (но не учитываем те где кандидат не добрался до дизайна а он должен был быть) - (13+2 лишних)-3 отказа=9, а в знаменателе (13+2 - 3 непроведенных но где это важно)=75% OK

Финалки/знакомства были в 5 треках, тут можно смело считать что они предусмотрены везде, поэтому проценты считаем только по тем где провели. Из 6 кейсов 6 отказов (2 оверквалификация, 1 опасение что кандидату не понравится используемый стек, 1 несовместимость с командой по вайбу, в 1 случае на финалках спрашивались специфические важные для данной организации технические подробности - вроде того, как производится handshaking в протоколе TCP. 5 кейсов и 5 отказов = 0% OK.

Почему нахожу эти цифры интересными. По каждому из показателей (кроме финалки) кандидат устроил 75-90% работодателей. И однако по совокупности он устроил 0%. Нетрудно посчитать, что вероятность пройти по 3 этапам-критериям исходя из этой статистики - 92%*75%*75%=50%, кажется что система должна работать и давать разумный шанс. На самом деле примерно столько и вышло, но это без учета финалок, на которых тоже теперь проявляют придирчивость. Разумно ли, что на выходе получился 0?

Впрочем по-хорошему оба кейса оверквалификации и один кейс с хардами в финалках следовало исключить уже на этапе первичного скрининга, чтобы не тратить ничье время. Если вакансия на самом деле не сеньорного уровня или требует специфического hands-on experience, кандидат должен был об этом узнать и вовсе не подаваться. Тогда остается только 2 отказа на финале, оба вполне валидных. Но... тогда надо из общей статистики эти вакансии убрать целиком, и получится что из 10 оставшихся проведено только 2 финалки, 20% уже выглядит как слишком низкая востребованность если большинство интервьюеров довольны каждым критерием в отдельности, нет?

Ну и выглядит забавно (хотя это уже искажение перспективы)

• если ты можешь пройти все этапы трека, мы подкинем тебе еще обручей (+1 сисдизайн например)

• если ты и тут не слился, то ты для нас слишком хорош

А мы продолжаем серию вебинаров про защиту Identity.

Завтра стартует наш следующий вебинар, при информационной поддержке партнера «Шексна‑Автоматизация»

2FA: on‑prem или облако — что выбрать?

На вебинаре разберем плюсы и минусы обоих вариантов.

2FA — уже не дополнительная защита, а базовый уровень безопасности

Компрометация пароля не должна автоматически означать компрометацию корпоративной учётной записи.

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

Покажем, как это решается с помощью двух сценариев: on‑prem решения Avanpost MFA+ и SaaS Avanpost Identity Cloud.

Avanpost MFA+ полностью разворачивается в инфраструктуре компании и поддерживает интеграцию с корпоративными системами через RADIUS, SAML, OpenID Connect, LDAP, Credential Provider и другие механизмы.

Avanpost Identity Cloud — защищенный доступ к корпоративным ресурсам для сотрудников и подрядчиков, созданный на базе эталонной облачной архитектуры. Все секреты и чувствительные данные остаются в периметре заказчика.

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

Продемонстрируем на тестовом стенде:

✅ Привязку аутентификатора в момент входа на рабочую станцию (on‑prem решение)

✅ Внедрение второго фактора для VPN (облачное решение)

Сделайте 2FA частью базовой кибергигиены без остановки рабочих процессов.

Когда: 1 октября в 11.00

Спикеры:

• Светлана Лихоманова, Директор по развитию стандартизированных продуктов

• Михаил Юров, Пресейл‑инженер, Отдел технической экспертизы

Зарегистрироваться на вебинар

Сколько вакансий на каждом грейде и сколько за них платят?

Новая аналитика по уже более 180.000 IT вакансий с HH, карьерных сайтов, сайтов организаций, job-бордов и телеграмм каналов.

Я построил 12 графиков отвечающих на разные вопросы связанные с IT наймом в 2026 году.

На Хабре буду выкладывать новые графики каждую неделю по средам!

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

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

Содержание
✔️ Креативная разминка.
✔️ Презентация метанавыков и школ.
✔️ Кейс. ИИ-решение персонализации рассылок показало интересные результаты при запуске, но потом отпугнуло пользователей. Как быть?
✔️ Разберём эту ситуацию через три линзы — три школы метанавыков:
— Креативное мышление поможет переформулировать задачу.
— Системное мышление создаст структуру.
— Продуктовое мышление разложит идею на компоненты по ценности и риску.
✔️ Подведём итоги, ответим на вопросы.

📆 Когда: 5 октября в 17:00 (Мск)
👨‍🎓 ️Спикер: Гафитулин Тимур, эксперт по техникам мышления

✍️ Записаться

Открытый проект Unofficial search plugins позволяет искать торренты прямо в qBittorrent. Это каталог поисковых плагинов, которые подключают торрент-сайты к самому клиенту. Можно выбрать нужные источники и искать по нескольким местам сразу с помощью одного запроса. В списке проекта есть Rutor, Nyaa, The Pirate Bay и даже Academic Torrents с научными данными.

Пришло письмо с конференции. На неё я не регистрировалась. 3 дня назад пришло письмо, где мне предложили зарегистрироваться, но его я просто проигнорировала, так как не моя тематика, да и планы уже есть. Честно говоря, за 4 дня до конфы звучит как крик о помощи. А теперь так вообще - добро пожаловать на онлайн, куда я даже не регистрировалась.

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

Внимание, вопрос: что будет, если нажать на грустный смайлик??

• Оставить отзыв

• Отписаться

• Переход на сайт конференции

А что будет если нажать на радостный? Сайт конференции! А если на покерфейс? Сайт конференции!

Почему при нажатии на грустный смайлик на вопрос "Как вам письмо?" я перехожу на сайт конференции?!

Как выглядят эти люди, которые не довольны рассылкой о конференции, но хотят на неё попасть? 😳

Чисто технически, конечно, вопрос был о письме. Письмо плохое, на конференцию хочу 🫠

Стоимость вычислений.

ИИ дешевеет быстрее, чем любая другая преобразующая технология в истории. При одном и том же уровне производительности стоимость с 2023 года снижалась примерно на 47% в квартал.

Это в 4 раза быстрее, чем секвенирование ДНК, в 6 раз быстрее, чем вычислительные мощности, в 18 раз быстрее, чем литиевые аккумуляторы, и в 54 раза быстрее, чем дешевела электроэнергия (если брать период до 1973 года).

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis