18 августа 2026 года произошёл сбой в работе сервисов хостинг‑провайдера и регистратора доменов Reg.ru. Сбой в работе Рунета вызван перебоями в подаче электроэнергии на крупном узле связи, сообщил ТАСС доменный регистратор «Рег.ру». Два источника и сотрудник ММТС-9 подтвердили РБК, что на части этажей ММТС-9 нет электричества.
Модераторы хабра часто пишут в комментариях, что у них есть алгоритмы определения ИИ слопа. Эти алгоритмы прекрасно работают, ИИ слоп удаляется каждый день пачками.
Посмотрите на эту статью: https://habr.com/ru/articles/1068100/
Приведу короткий открывок из статьи:Но я потратил годы, разбираясь именно в кодеках — не в протоколах, не в UI, а в том, что происходит с кадром между «экран изменился» и «байты улетели в сеть».
И ведь там вся статья такая.
У кого-нибудь из вас есть сомнения, что это ИИ слоп?
После предыдущего моего поста о ИИ слопе в комментариях на хабре, мне включили возможность жаловаться на контент.
Штош, я отправил жалобу на статью 9 августа. Прошло 10 дней.
Может модераторам просто не пришло уведомление?
Может они решили проигнорировать уведомление?
Может они нечаяно его пропустили?
Или у хабра нет ресурсов и желания для борьбы с ИИ слопом?
Или война с ИИ слопом уже проиграна?
Миллионы обращений, контент для ИИ и зарплата-загадка: как московские власти ищут шеф-редактора базы знаний
ГКУ «Инфогород» (работает с цифровыми проектами ДИТ Москвы) ищет специалиста в контакт-центр. Здесь не нужно механически наполнять базу знаний, это методологическая функция с обучением, координацией, настройкой процессов и работой с контентом для людей и ИИ. Звучит интересно, но есть подводные камни.
Немного контекста
В России менеджмент знаний (МЗ) как корпоративное направление начал развиваться на рубеже 90-х – нулевых. Первый ГОСТ появился в 2011 году, а стандарт с требованиями к полноценной системе – в 2021-м.
Наш рынок всё ещё заметно отстаёт от Европы и США: и по числу ИТ-решений, и по количеству вакансий – их в 8-12 раз меньше, и по зрелости бизнеса – МЗ как отдельная функция есть у единиц. Но ИИ меняет этот тренд: спрос на проекты растёт, вакансий становится больше, бизнес начинает понимать, что нужно готовить знания для ИИ.
Я больше 15 лет внедряю МЗ в российских компаниях с командой Minerva Result. По вакансиям на hh и других сервисах вижу, что далеко не все осознают, зачем им база знаний и как с ней работать. Чтобы подсветить спорные места и помочь тем, кто хочет развиваться в этой области, решил запустить разборы. Буду рад, если поделитесь обратной связью в комментариях и расскажете, как управляете знаниями в контексте внедрения ИИ.
Ну а теперь к вакансии ГКУ «Инфогород».
Плюсы
Ежемесячно контакт центр обрабатывает больше 5 млн обращений. Любая ошибка стоит дорого и судя по вакансии (а она, в отличие от многих других, достаточно зрелая) работодатель это понимает: здесь есть контроль качества, понятности и актуальности контента, обучение авторов и сотрудников, мониторинг системы, работа с процессами.
Отдельный плюс – акцент на адаптации нормативных документов и подготовке материалов для ИИ. Компания смотрит дальше привычного «написать инструкцию в Word», а для кандидата это уже отличная возможность получить практический опыт и усилить резюме.
Здесь хорошо описано место роли в процессах: специалист становится связующим звеном между редакторами, экспертами и продуктовыми командами. А ещё есть бонусы в виде статуса аккредитованной ИТ-компании, обучения и гибридного формата после ИС.
То, что вызывает вопросы
Границы роли. В названии уже есть координатор центра БЗ и шеф-редактор. После прочтения ещё появляются методолог, тренер, редактор и немного контент-аналитик. Такое размывание не приводит ни к чему хорошему: человек распыляется между задачами, контент устаревает, процессы ломаются, инструмент теряет актуальность, команда возвращается к привычным системам. Лучше чётко определить на старте, чем будет заниматься специалист, какие у него будут метрики и KPI.
Дальше – требования заметно скромнее обязанностей. Ищут человека с высшим образованием, опытом от 2-х лет в координации, административной поддержке, методологии или редакции. Ожидают полного цикла работы с контентом, методологического сопровождения, консультирования и обучения сотрудников. Найти такого всемогутора может быть непросто. Опять же, лучше разбить задачи по ключевым блокам и выбрать приоритетные. Под них искать специалиста.
Ещё одно слабое место – зарплата-загадка. Работодатель обещает «рыночную», но рынок, как известно, у каждого свой. Человек с опытом 3-6 лет может пролистнуть вакансию. Лучше указать вилку или хотя бы написать, вокруг чего конкретно будет строиться зарплата.
Вывод и рекомендации
Вакансия может подойти редактору, методологу или специалисту, который хочет попробовать себя в разных ролях, получить опыт подготовки контента для ИИ, поработать в крупном проекте с реальной потребностью в МЗ.
Что стоит спросить:
есть ли цель, метрики и KPI? что будет считаться успешным результатом?
какая зона ответственности? можно влиять на методологию?
на какой платформе нужно работать?
из кого состоит команда? можно привлекать коллег?
можно использовать результаты в портфолио?
Больше разборов вакансий – в моём тг-канале. Подпишитесь, чтобы не пропустить новые посты.
👌 Подключить дополнительные инструменты к VK Data Platform стало проще.
Теперь вы можете добавить к уже настроенному контуру собственные СУБД, вычислительные движки, сервисы обработки данных и ML/LLMOps-инструменты. Пересобирать для этого базовую архитектуру не нужно.
🪄 После подключения новый сервис сразу работает по общим правилам платформы: для него действуют единые настройки доступов, мониторинга, логирования, аудита, отказоустойчивости и масштабирования. Интеграция занимает несколько часов.
😎 Кому это пригодится?
В первую очередь, системным интеграторам и крупным компаниям со сложным или специфичным data-стеком. Обновление позволяет подключать нужные инструменты без создания для каждого из них отдельного контура управления и дополнительной нагрузки на ИТ- и data-команды.
Рынок подготовки к ЕГЭ — самая монетизируемая точка входа, но с высочайшим риском копирования. Чтобы выжить при наличие десятка аналогичных моделей продукт должен строиться не на объяснении решений, а на формировании навыков и интеграции в жизнь пользователя.
Проект: Концепция ИИ-репетитора для подготовки к ЕГЭ (продуктовая стратегия)
1. Методология: переход от объяснения к диагностике и тренировке Конкуренты предложат понятный язык объяснений. Этого недостаточно и это легко скопировать. Мой подход:
Диагностика невидимых пробелов. Модель анализирует ошибку не только в финальном ответе, но и в промежуточных шагах. Отсутствие навыка сложения алгебраических дробей, например, автоматически блокирует прогресс в целом классе текстовых задач.
Генерация внепрограммных тренажеров. ИИ создает задания, которых нет в банке ФИПИ, точечно закрывая выявленный дефицит. Например, генерирует 50 вариаций задач на проценты с усложняющимся контекстом, пока скорость решения не превысит пороговое значение.
Неформальная подача учебного материала. Пользователь может сам выбрать одного из предложенных персонажей с индивидуальной манерой преподавания, в качестве наставника.
2. Продукт: экосистема вместо отдельного приложения Главная ошибка — делать ИИ-репетитора отдельным сервисом. Через два года он станет лишь одной из функций личных ассистентов и исчезнет как самостоятельный продукт. Наша стратегия:
Фоновый режим (Background Tutoring). Репетитор работает постоянно в качестве ИИ-помощника. Пользователь может обсуждать с ним мемы, выбор кроссовок или новости, но модель всегда держит в контексте цель — подготовку к ЕГЭ. Она органично вплетает темы в беседу («Кстати, этот мем про экспоненту отлично иллюстрирует задачу №16»).
Непрерывная подготовка (Non-stop prep). Система напоминает о занятиях, мотивирует и связывает экзаменационные задачи с бытовыми вопросами пользователя.
Расширяемость (Extensibility): Архитектура изначально закладывается под концепцию «Личного когнитивного контура» — после ЕГЭ продукт бесшовно трансформируется в ИИ-помощника для вуза (написание курсовых, поиск литературы) и рабочего места.
3. UX и Геймификация: борьба с главной проблемой — прокрастинацией Ученики проваливают экзамен не из-за глупости, а из-за неумения организовать себя.
Жесткое планирование. ИИ сам составляет расписание, ставит дедлайны и требует подтверждения выполнения. Пропуск дня без уважительной причины запускает цепочку эскалации: уведомление пользователю → куратору.
Кураторский контур. Ежедневные отчеты (автоматизированные дашборды: время фокуса, % выполненных заданий, динамика ошибок) отправляются родителю, школьному учителю или другу-напарнику.
Двуличный ИИ (Multi-agent tutoring). Вместо одного скучного помощника — система конфликтующих персонажей, которую я уже реализовывал в прототипах:
«Профессор»: строгий, объясняет через фундаментальную науку, готовит к вузовским стандартам, использует сарказм.
«Студент»: объясняет «на пальцах», шутит, снижает тревожность. Они спорят друг с другом, вовлекая ученика в роль арбитра. Юмор и контролируемый конфликт повышают вовлеченность
QA-эксперт Авито о том, почему вход в IT через тестирование больше не работает
Всем привет! Гостья нового выпуска AviTalk — Соня Каребина, QA-эксперт Центра экспертизы обеспечения качества в Авито. До IT у неё были инженер-нефтяник и администратор фотостудии — то есть путь в тестирование получился совсем не прямым. Ведущий выпуска — Виктор Раев, руководитель разработки юнита Services Base.
Говорим о том, почему в тестировании нет универсального ответа «релизить или не релизить» и как QA оценивает риски для пользователей и бизнеса. Разбираемся, почему умение договариваться для тестировщика важно не меньше технической экспертизы, и каким становится процесс, когда человек и AI работают в связке. А ещё — про волонтёрство, эмоциональное выгорание, вязание, двести комнатных растений, мечту о Марсе и принцип, который в своё время помог Соне сменить профессию.
Смотреть выпуск:
AviTalk — шоу толковых людей. Приглашённые гости — сотрудники Авито из разных дирекций и команд, которые делятся экспертизой и рассказывают о своём профессиональном пути.
Можно ли быстро актуализировать старые PHPUnit-тесты под новые версии пакета?
Краткий ответ: да, но есть нюансы.
На Хабре незаслуженно мало статей про инструмент Rector, и даже в них совсем вскользь упоминается, что у инструмента есть отдельный функционал для актуализации PHPUnit-тестов, написанных под разные версии пакета. Причем если раньше, этот функционал был в виде отдельного пакета rector-phpunit, то на сегодня (для версии 2.6.3) этот функционал уже входит в состав основного пакета.
Итак, у нас были тесты написанные в разное время разными разработчиками под версию PHPUnit, которая была установлена при создании проекта. Вопрос о её обновлении поднимался регулярно, но оценка стоимости актуализации нескольких сотен файлов с несколькими тысячами тестов была довольно большой, пока не появилась возможность сделать это автоматически.
Как шло обновление:
- установили пакет rector/rector
- обновили пакет phpunit
- сделали файл конфига rector.php в котором прописали наборы правил
- запустили сначала в режиме vendor/bin/rector process --dry-run. Увидели, что аннотации @dataProvider не мигрировали в атрибуты #[DataProvider], а сами методы, на которые указывают dataProvider не стали статическими (требования PHPUint 10+).
Добавили необходимые правила в конфиг rector.php и в при первом приближении всё сработало как нужно:
<?php declare(strict_types=1); use Rector\Config\RectorConfig; return RectorConfig::configure() // Путь к директории с тестами ->withPaths([ __DIR__ . '/tests', ]) // Включаем синтаксис PHP 8.4 ->withPhpSets(php84: true) // Правила берем для версии phpunit из composer.json ->withComposerBased( phpunit: true ) // Общие наборы правил для улучшения качества тестов ->withPreparedSets( phpunitCodeQuality: true ) // Явно запускаем встроенное правило миграции аннотаций PHPUnit в атрибуты ->withAttributesSets( phpunit: true );
Но и после этих инструкций не все методы dataProvider стали статическими. Основные причины были в следующем:
- использование $this в методах dataProvider
- коллизии из-за последовательности выполнения правил рефакторинга в Rector
Что помогло исправить ситуацию:
1. повторный запуск vendor/bin/rector process позволил правилам повторно пройтись по уже исправленным файлам и доделать изменения
2. использование ссылки на текущий объект в методах dataProvider плохая практика, от неё отказались
Житель Республики Корея показал свою жизнь через историю поездок в Google Maps. Он сделал визуализацию с помощью открытой утилиты Timeline Visualizer. В итоге получилась карта, на которой почти весь год выглядит так: дом — работа — дом — работа. Пару раз линия всё-таки уходит в сторону, но это не отпуск и не приключения, а командировки.
Математика оказалась самым сложным предметом для учеников начальной школы, согласно шкалы трудности учебных предметов, представленной СанПиН (в санитарных правилах РФ). Для детей 1–4 классов математику оценили в восемь баллов из десяти, что выше оценок всех остальных дисциплин.
Второе место по уровню сложности по СанПиН занимают русский или родной язык и иностранный язык (семь баллов). Далее идут информатика и окружающий мир (по шесть баллов) и литературное чтение (пять баллов). Самыми лёгкими для младшеклассников оказались физкультура (один балл), технология (два балла), а также изобразительное искусство и музыка (по три балла).
Карьера в Innostage: ищем пресейл-архитектора
В блоге компании много говорим об информационной безопасности, делимся практической экспертизой, исследованиями и техническими материалами. Но экспертиза Innostage — это прежде всего люди, которые каждый день работают с задачами бизнеса и заказчиков. Поэтому мы запускаем HR-трек, в котором будем рассказывать об актуальных вакансиях и возможностях присоединиться к нашей команде.
Первая позиция — пресейл-архитектор.
Чем предстоит заниматься
Пресейл-архитектор — это специалист, который соединяет техническую экспертизу, задачи бизнеса и коммерческую часть проекта. В этой роли важно не только хорошо разбираться в ИТ и ИБ, но и уметь переводить технические решения на язык задач заказчика.
В зоне ответственности:
погружение в бизнес-задачи заказчика, выявление потребностей и формирование технического решения;
определение ключевых стейкхолдеров проекта, их задач, рисков и потребностей;
подготовка технико-коммерческих предложений с понятным составом работ, решениями и ограничениями;
анализ рынка, вендоров и open-source решений для выбора оптимального технологического стека;
поиск возможностей для развития и расширения проектов;
техническое сопровождение сделки от первого контакта до заключения договора;
подготовка презентаций и проведение технических демонстраций для заказчиков;
участие в отраслевых мероприятиях и конференциях в качестве технического эксперта.
Что нам важно
Архитектурный бэкграунд. Вы проектировали корпоративные ИТ-инфраструктуры и понимаете принципы их построения, эксплуатации и защиты.
Экспертиза в информационной безопасности. Знакомы с требованиями ФСТЭК, ФСБ, 152-ФЗ и 187-ФЗ и умеете применять их при проектировании решений.
Системное мышление. Понимаете ГОСТы и нормативные требования, но воспринимаете их как инструмент для создания работающих решений, а не как набор формальных требований.
Опыт от 2 лет в ИБ/ИТ. Можете самостоятельно обсуждать технические решения с заказчиком, аргументировать свой подход и представлять результаты работы.
Также важно умение находить общий язык с разными участниками проекта — от технических специалистов и директоров по ИБ до руководителей бизнеса и финансового блока.
Что мы предлагаем
помощь в адаптации и погружении в работу;
ДМС, включая стоматологию, телемедицину, психологическую поддержку и ежегодное медицинское обследование;
страхование от несчастных случаев и страхование при выезде за рубеж;
возможности профессионального развития: курсы, семинары и доступ к онлайн-библиотеке МИФ;
частичную компенсацию занятий спортом;
сообщества сотрудников по интересам;
социальную поддержку в ключевые моменты жизни;
официальное трудоустройство;
имеем аккредитацию в Минцифры.
Если вам интересно развиваться на стыке ИБ, архитектуры и работы с бизнесом, будем рады познакомиться.
По вопросам вакансии: Александра Титова - телеграм @alex_titova, почта Aleksandra.Titova@innostage-group.ru
Наконец-то дошли руки до повышения версии трекера ошибок Glitchtip с 4.2.5 до 6.2.6, а это значит то, что у меня появилась возможность подружить OpenCode агента с Glitchtip через MCP. Повышение версии трекера прошло без единой ошибки, данные сохранились, на всё ушло минут 30. Как обновлял пошагово могу рассказать отдельно.
Glitchtip - это бесплатный open source трекер ошибок, аналог Sentry, предназначенный для мониторинга и анализа ошибок, производительности на нескольких проектах. Я использую его для быстрого выявления ошибок, в каком приложении возникла проблема, в каком месте и при каких условиях. Подключение по MCP к Glitchtip позволяет автоматизировать анализ и обработку исключений, используя ИИ агентов, например OpenCode.
На данный момент основное используемое мною применение данной связки - это анализ новых ошибок. Раньше я копи-пастил детальную страницу ошибки в чат, теперь процесс можно автоматизировать и экономить токены. У меня в планах сделать полностью автономного агента, который будет создавать утилиты и сайты с нуля под конкретный запрос пользователя, автоматизация трекера ошибок будет одним из кирпичиков этой системы.
Для подключения аналога сентри к ИИ агенту:
Включить MCP в окружении Glitchtip
GLITCHTIP_ENABLE_MCP=True
В моём случае Glitchtip запускается в docker-контейнере. Я просто добавил новую запись в файлы .env и .env.example и перезапустил сервис.
Создать токен доступа в UI Glitchtip с правами на чтение
Тут должно быть изображение, где красными стрелочками показано куда нажимать, но редактор молча игнорирует добавление фото. Если описать навигацию текстом: Profile -> Auth Tokens -> Create New Token
Затем сохранить токен как файл где-то в директории с секретами, чтобы OpenCode смог его подхватить и токен не утёк при git push. Например:
.secrets/glitchtip-auth
Содержание файла:
Bearer {{Ваш токен}}
Добавить MCP и токен в opencode.json
... "mcp": { ... "glitchtip": { "url": "https://errors-report.{{Ваш домен}}.com/mcp", "headers": { "Authorization": "{file:.secrets/glitchtip-auth}" }, "type": "remote", "enabled": true }, ... ... },
Нужно иметь в виду, что данные MCP Glitchtip будут добавляться к контексту каждого запроса. И когда задача не связана с трекером ошибок, нужно выключить данный MCP, выставив "enabled": false и перезапустив OpenCode.
Перезапустить OpenCode и проверить работу
OpenCode должен стартовать без ошибок, MCP должен отобразиться в статусе. Можно проверить результат подключения, попросив агента: "Check if MCP works on a self-hosted GlitchTip instance". В ответе агента должен быть вызов одного из методов MCP, например:
Let me test the GlitchTip MCP tools against your instance. Вызван glitchtip_list_organizations <<< ------ Ключевой вызов через MCP, маркер успешной настройки. MCP works on your self-hosted GlitchTip instance. It successfully connected and returned your organization:
Organization: ShabalinAS Team Slug: shabalinas-team Accepting events: Yes
Агент, который «помнит», на самом деле сочиняет
У модели нет памяти, есть контекст: если факта в контексте нет, она досочинит его с абсолютной уверенностью.
Десятого июля я вшил в систему правило Search Brain First. Смысл простой: прежде чем предлагать новую задачу или проект, агент обязан заглянуть в свою базу. Первым делом ~Projects/Active/, там текущая загрузка. Потом ~/Decisions/, там свежий контекст. И только потом что-то предлагать.
Заодно появилось правило «после задачи». Каждое завершённое дело обязано оставить след: краткую заметку-решение в Decisions/Projects/ и строку в task-logs/ с временем, агентом, задачей, статусом и артефактами. Это правило легло в SOUL.md всех шести профилей сразу.
Почему это вообще понадобилось? Потому что агент не вспоминает, он продолжает текст. Спроси его «что у нас в проектах?» без базы под рукой, и он ответит уверенно, даже если ничего не знает. Diff такой выдумки не покажет: diff видно там, где агент что-то менял, а не там, где он что-то придумал.
Vault стал мозгом, агенты перестали полагаться на «я помню». В SOUL.md директора теперь вопрос перед каждой новой задачей: «1 core + 2-3 auxiliary максимум. Что закрываем или замораживаем?» И ответ на него ищется в базе, а не в памяти.
Первый тест прошёл в тот же вечер. Запись в task-logs/2026-07-10.md от 22:30: директор, «Project inventory analysis», статус done. Одна строка, зато первый след, который не надо проверять на выдумку.
С тех пор правило простое: не верь агенту, который говорит «я помню». Верь тому, кто говорит «я посмотрел».
Средняя стоимость токенов для ИИ резко упала с пика в $2,07 за миллион токенов 28 мая до $1,02 за миллион токенов. Основными причинами являются снижение цен на китайские модели ИИ от Kimi и DeepSeek, которые в несколько раз дешевле моделей с закрытым исходным кодом из США.
14 августа была выложена новая версия модели Qwen 3.8 27b и 27b-FP8. 12 августа назад была выложена новая версия модели Qwen 3.8-2.4T-A95B и Qwen 3.8-2.4T-A95B-FP8.
Почему это важно для кибербеза? Семейство квен самое популярное семейство среди моделей на hugging face как по количеству скачиваний так и по использованию для построения\файнтюна своих моделей. Россия в этом плане не сильно отличается от мировых тенденций.
Версия на 27 млрд параметров по общим бенчмаркам способностей находится на уровне GLM-5.2 (max), Deepseek V4Pro 0813, GPT 5.6 Luna. Квантованную до FP8 версию можно попробовать запустить на условно домашней rtx 5090 32 Гб
Версия на 2,4 трлн параметров по общим бенчмаркам способностей находится на уровне Muse Spark 1.2, GPT 5.6 Terra, т.е. можно отнести к SOTA моделям . Эта версия FP8 уже потребует профессиональных минимум 16 видеокарт Nvidia B300.
Как обычно хотелось бы понимать насколько эти модели более защищенная и (или) более способная для задач кибербезопасности.
А тут появляются проблемы, официально у новых моделей нет тех репорта, только карточки на hugging face c ссылками в никуда или на весьма ограниченное описание. Каких либо других независимых отчетов по кибербезопасности и safety мне тоже не удалось найти. В части возможностей самой модели можно с допущениями ориентироваться на тест облачной версии модели Qwen 3.8 Max (как аналога Qwen 3.8-2.4T-A95B) от Aikido:
"Qwen rediscovered 26 of 32 CVEs across three runs, for 81.25% pass@3 recall. That's ahead of GPT-5.6-Sol and matches Opus 5, at roughly half the cost".
Можно попробовать ориентироваться на комплексные бенчи:
Terminal‑Bench 2.1 - навыки работы в командной строке, в том числе для задач кибербезопасности (нахождение и закрытие уязвимостей в коде, реверс-инжиниринг бинарных файлов и безопасная настройка доступов).
DeepSWE 1.1 - бенч для навыков агентов по написанию кода, отдельных разделов по безопасности нет, но это навык смежный с написанием кода.
Значимое отличие - Qwen 3.8 27b единственную из актуальных опенсорс общих моделей можно запустить на одиночном устройстве, особенно если на неофициальном квантовании FP4. Тогда как для "соседей" по бенчмаркам (GLM 5.2, Deepseek V4Pro 0813, GPT 5.6 Luna) потребуется кластер (а иногда и не один) профессиональных видеокарт.
Что на текущий момент является аномальным результатом по соотношению (возможности модели в Terminal‑Bench 2.1)/стоимость оборудования. Соотношение сохраняется в DeepSWE 1.1 и нескольких других бенчах .
Будем ждать новых отчетов по этому семейству, пока Artificial Analysis не включил в бенч по затратам Qwen 3.8 27b, поэтому нужно отнестись сдержанно к получившейся аномальной оценке.
Если у кого то есть локальная RTX 5090 и свободное время - поделитесь впечатлениями ;) .
Немного философии Rust, возможно кому то интересно обсудить
Уже почти 3 месяца пишу проект на Rust. Сейчас разработка стала другой, ручная работа стала роскошью, реальные задачи бизнеса быстрее решить LLM-ками. Естественно познание языка в таком режиме замедляется, хочется как-то компенсировать, хотя бы поговорить об этом.
Вот какой аспект. В Rust уровень владения/заимствования объектом - часть контракта. По большому счету можно составить примерно такую таблицу (на самом деле это дерево должно быть, но для упрощения привожу плоскую таблицу):
Просто владею объектом → T
Временно читаю чужой объект → &T
Временно изменяю чужой объект → &mut T
Один владелец, нужна куча → Box
Несколько владельцев, один поток, чтение → Rc
Нужны несколько владельцев, один поток, изменение → Rc<Cell> / Rc<RefCell>
Несколько владельцев, несколько потоков, чтение → Arc
Несколько владельцев, несколько потоков, изменение → Arc<Mutex> / Arc<RwLock>
По сути чем более строгий уровень доступа (или какой термин тут лучше?) - тем больше проверок сможет сделать компилятор. Если используете Rc - то уже потенциально возможны циклические ссылки и утечка памяти (с Box - это не возможно). Если RefCell - то компилятор не сможет проверить два borrow_mut() одновременно - будет рантайм проверка или паника.
И вот какая фишка. Часто LLM-ка дает уровень больше чем нужно. Как-то где можно обойтись ссылкой - добавит Rc<RefCell>. Т.е., по сути, код то рабочий, но лишние обертки и послабление компил-тайм проверок немного угнетают.
Но иногда бывает оправданно, когда в процессе уровень нужно ослабить, т.к. не всегда предусмотришь на этапе проектирования.
И далее возникла философская идея. А вот неплохо бы чтобы компилятор сам решал какой уровень применять. Т.е. начинаем от самого малого, если его не достаточно - то использует послабления. Если достаточно классической проверяемой ссылки - то использовать ее. Или если нужно множественное владение, но точно нет потоков - то Arc можно не использовать - достаточно Rc (если нет данных то ослабляем - берем Arc).
При этом все еще остаемся в рамках языка без GC - но вместо ручного выбора - выбор осуществляется компилятором при сборке.
Как вы думаете - идея имеет право на жизнь?
Пару месяцев назад я написал пост о поиске журнала для публикации статьи. Спасибо всем откликнувшимся, особенно Евгению Рудному @rudnyi - именно его советом я и воспользовался. Но все не так просто...
У меня было три задачи: закрепить авторство, сообщить специалистам о работе и подняться в глазах начальства. Третий пункт отпал, поскольку мне пришлось уйти с работы вообще (по ссылке подробности). Соответственно, нужда искать журнал отпала и я решил попробовать препринты по совету Евгения.
Не буду писать все подробно, но опробовано следующее:
1. На сайте "preprints.ru" публикация удалась легко и просто: кто хочет - прочтите мою статью.
2. На сайте "preprints.org" статью отклонили (история ее перевода на инглиш с чатомжпт - это отдельная история). Причину отклонения не указали ("считаем нецелесообразным, спасибо за внимание, удачи на других площадках").
3. На сайте "zenodo.org" статья неделю висела со статусом "на рассмотрении", пока я сам ее не удалил (если удалилась). Почему - я не понял. То ли я что-то не так сделал, то ли что еще. Непонятно ничего!
4. Еще мне посоветовали сайт "academia.edu", где можно публиковать вроде бы что угодно и на любом языке (даже на русском). Но на русском уже есть, я опубликовал английский вариант - если интересно, прочтите. Статья одна и та же, но сейчас мир делится, и не факт, что аудитории пересекаются...
Место осталось, напишу кратко о переводе. Качество оценить не могу, скармливал ЖПТ фрагменты (только текст, без формул). Он несколько раз возвращался к прошлым фрагментам, приходилось переделывать. Один раз я ему дал перевод абзаца, сделанный джемени ("О, это очень интересно! Вот тут она лучше, тут хуже"). Статья в сумме 10 страниц Ворда, много формул и чисел. Но перевод занял не один день! Так что не все так просто пока еще в этой сфере...
Надеюсь, этот пост кому-то будет полезен, не один я площадки для публикаций ищу... Лет 15 назад я сам хотел сделать сайт для публикаций всего "непризнанного официально", чтобы дать площадку альтернативным идеям. Но руки так и не дошли...
Сейчас я сам в поисках интересной работы по моим умениям и желаниям (ссылка во вступлении к посту), но творчество свое буду продолжать и сайты свои развивать.
А статья... Чистая математика! :) Если кому интересно.
Риккардо Манцотти: Восприятия - это объекты. На пути к теории идентичности разум-объект
Риккардо Манцотти является представителем экстернализмома и он выводит сознание за пределы тела. При этом Манцотти считает себя убежденным физикалистом:
'если сознание реально, оно обязано быть физическим.'
Поместить сознание вне мозга его вынуждают противоречия, связанные с противоположной позицией, интернализмом:
Восприятия отличаются от мозга;
Восприятия интенциональны;
Восприятия cвязаны с квалиа.
Таким образом, Манцотти рассматривает два утверждения
Сознание идентично с физическим феноменом (PHYSICAL),
Этот феномен находится в теле или в мозгу (BRAINBOUND),
и утверждает, что в рамках физикализма можно оставить первое утверждение и заменить второе на следующее:
Сознание - это внешний объект (OBJECTBOUND).
При этом панпсихиз отвергается, как концепция несовместимая с физикализмом. Приведу цитату, в которой Манцотти живо объясняет свою позицию на примере ситуации, когда человек видит желтый банан. На этом пути он рассматривает соотношения между бананом, телом (мозгом) и восприятием:
'В итоге, ваше восприятие объекта желтое и банановое. Банан перед вами также желтый и банановый. Ваше восприятие имеет свойство воспринимаемого объекта. Не является ли это обещающим началом? В действительности многие замечали, что наше восприятие не отличается от окружающего мира - оно состоит из объектов, машин, людей, зданий, деревьев, облаков, Солнца и звезд. Физические свойства тела и свойства объекта известны. Они совпадают! Мозг розовато-серый, липкий и кровянистый. Банан желтый, протянутый и банановый. Ваше восприятие желтое, протянутое и банановое. Что является вещью, которая желтая, протянутая и банановая? Мозг или банан? Ответ очевиден - банан! Что нам нужно еще, чтобы вывести такую очевидную идентичность?'
Убрав противоречия, существующие в интернализме, в своей статье Манцотти берется за решение горы противоречий в предлагаемой версии экстернализма. Больше информации можно найти в статье Винника, в которой рассматривается интернализм и экстернализм:
'Другую радикальную версию феноменологического экстернализма исповедует Р. Манцотти. Он ставит под сомнение разделение на субъект и объект. Согласно Манцотти, это разделение на мир и восприятие может быть отброшено, поскольку то, что мы считаем объектами и их феноменальными репрезентациями, суть только две неполные перспективы одного физического процесса.'
R. Manzotti, Experiences are Objects. Towards a Mind-Object Identity Theory, in Rivista Internazionale di Filosofia e Psicologia, 2016, 7(1), pp. 16-36.
Д. В. Винник, Сознание за пределами мозга - истоки аргументации радикального экстернализма. Вестник Томского государственного университета. Философия. Социология. Политология 2 (10) (2010): 125-136.
После года на фрилансе вернулся к поиску постоянной работы, и, надо сказать, за этот год работодатели, кажется, полностью перевели наём на искусственный интеллект. И хоть на рекрутеров за это катят сотни бочек, я могу их понять: в конце концов, первичный отбор в основе своей состоит в поиске общих паттернов между текстом вакансии и текстом резюме — буквально то, в чем ИИ хорош, — так что это вполне ложится в корзину "Оптимизация", а не "Лень".
А то, что после установления контакта часто следует автоматическое анкетирование с вопросами, ответы на которые есть в самом резюме, — это уже скорее вина площадок (да, hh.ru, первую очередь на тебя смотрю): большинство рекрутеров работает с их встроенными инструментами, которые как раз и должны такие вещи стримлайнить.
Логично оптимизировать поиск и со своей стороны, что я и сделал. Технику и pipeline, если будет интересно, опишу в другой раз. Если упрощенно: ИИ с контекстом из собранного опыта, предпочтений, портфолио и прочей важной информации обо мне как специалисте (значительно шире, чем разумно включать в резюме) просматривает вакансии, откликается на подходящие, где нужно — заполняет анкеты и пишет сопроводительные.
Получается, с обеих сторон машина разговаривает с машиной — симметрия и справедливость. Верно? Знать бы, как это выглядит с другой стороны. Мой Claude всегда подписывает сопроводительные строкой "Отклик отправлен AI-ассистентом...", но в 2026-м вряд ли кто-то рассчитывает выдать текст AI за свой, и такая честность стоит немного.
Кто первым пробьется через TL;DR: я прочту вакансию или HR — резюме?
Я пока для себя не решил эту дилемму, поэтому выбрал компромисс: если ИИ находит вакансию, которая ну прям очень про меня, — откладывает ее в отдельный список, который я разбираю сам.
Где для вас граница допустимого участия ИИ в поиске работы?
Только сам, без ИИ
Правки резюме и писем
Поиск и отбор вакансий
Отклики и письма за меня
Ответьте номером в комментариях.
NUMA и топология CCD Ryzen 9 9950X: как размещение vCPU влияет на задержки.
NUMA и топология CCD Ryzen 9 9950X не равнозначны: гость видит NUMA-схему, но не границы L3. Сравнивать нужно размещение vCPU на одной VM внутри CCD, между CCD и без pinning. Результат зависит от нагрузки, BIOS, ядра, QEMU и SMT.
Как определить, какие vCPU находятся на одном CCD?
Сопоставьте логические CPU с ядрами и SMT-сиблингами, затем найдите группы общего L3-кэша. Каждый CCD объединяет восемь ядер с общим L3, номера CPU зависят от хоста, поэтому проверяйте shared_cpu_list. Запишите BIOS, микрокод, ядро и governor.
lscpu -e=CPU,CORE,SOCKET,NODE,CACHE grep -H . /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list
Границы CCD измеримы: в открытом наборе для 9950X с AGESA 1.2.0.2 средняя задержка CAS через общую строку кэша составила 22,4 нс внутри CCD и 79,5 нс между CCD, тогда как numactl границу не покажет.
От физических ядер к vCPU, emulatorpin и vNUMA
vcpupin связывает vCPU с CPU хоста, но не трогает остальные потоки VM: эмулятор QEMU и IOThread закрепляются отдельно. NUMA node гостя должен отражать домен памяти, а не границу L3, иначе межчиплетная задержка смешается с доступом к удалённой RAM.
virsh vcpupin vm-latency virsh emulatorpin vm-latency virsh numatune vm-latency
Компактный CCD, разнесённые CCD и свободное планирование
Сравните одну VM в трёх конфигурациях: внутри одного L3, между CCD и без vcpupin. Число vCPU и RAM не меняйте, пиннинг задавайте по физическим ядрам, SMT проверяйте отдельно.
Насколько размещение между CCD увеличивает задержку?
Универсальной прибавки нет: результат зависит от общих данных, синхронизации, памяти и миграций. Сравнивайте одну нагрузку на одном хосте, сохраняя p50, p95, p99 и разброс. Core-to-core тест измеряет обмен между CCD, а не p99 приложения.
Как не принять boost, нагрев или соседнюю VM за эффект CCD
Прогрейте VM, фиксируйте частоту, температуру и %st: performance не удерживает частоту на Ryzen. Чередуйте схемы A–B–C–C–B–A и записывайте фоновые задачи. vNUMA должна совпадать с доменами памяти хоста.
Связь задержки с миграциями, кэш-промахами и удалённой памятью
Возьмите приложение с общей памятью или синхронизацией и микротест обмена. Перед серией проверьте pinning в libvirt и память QEMU, затем снимайте context switches, миграции и NUMA faults. Для cache-misses нужен vPMU. Нормируйте счётчики: рост вместе с p99 причину не доказывает.
perf stat -e context-switches,cpu-migrations,cache-misses \ -- ./test numastat -p "$(pgrep -fo 'guest=vm-latency')"
Когда пиннинг vCPU улучшает p99?
1. Рабочие потоки часто обращаются к общим данным.
2. Без pinning они мигрируют между группами L3.
3. p99 снижается без потери throughput и роста %st.
Где компактность помогает, а где ограничивает параллелизм
Сведите три схемы в таблицу: медиана p99 по повторам и доверительный интервал разницы. Если интервал пересекает ноль, результат в пределах погрешности. Задачам с независимыми потоками компактность ничего не даёт: обмена между ядрами почти нет, а привязка сужает выбор планировщика.
Как превратить топологию 9950X в правило эксплуатации
До теста задайте порог, например снижение p99 на 10% без потери ops/s. В XML подставьте cpuset и узел.
<vcpu>2</vcpu> <iothreads>1</iothreads> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='1'/> <emulatorpin cpuset='2'/> <iothreadpin iothread='1' cpuset='3'/> </cputune> <numatune><memory mode='strict' nodeset='0'/></numatune>
Закрепляйте vCPU внутри CCD только если улучшение p99 воспроизводится в повторных прогонах. Если throughput падает или p99 не меняется, оставьте свободное планирование. Топология задаёт гипотезу, решение зависит от VM.
Коннекторы 1С: быстрая интеграция через OData в Digital Q.Integration
Интеграция с решениями 1С остается одной из наиболее востребованных задач в построении корпоративных ИТ-ландшафтов. При этом разработка и сопровождение интеграционных решений зачастую требуют значительных временных и трудовых затрат.
На вебинаре эксперты компании «Диасофт» расскажут, как организовать обмен данными между 1С и внешними системами с помощью готового коннектора платформы Digital Q.Integration, реализованного на базе протокола OData. Вы узнаете, какие подходы для интеграции с 1С существуют, почему именно OData выбран в качестве технологической основы решения и какие преимущества это дает при построении современных интеграционных процессов.
Во время демонстрации покажем, как:
настроить подключение к 1С с помощью коннектора Q.Integration;
получать данные из 1С;
добавлять/изменять данные в 1С;
автоматизировать интеграционные процессы средствами платформы Digital Q.Integration.
Программа
13:00 – 13:10 Введение. Почему интеграция с 1С остается актуальной задачей и какие подходы используются для ее реализации.
13:10 – 13:25 Подходы к интеграции с 1С. Рассмотрим основные способы организации обмена данными, сравним интеграцию через OData и использование специализированных конфигураций 1С, разберем преимущества и ограничения каждого подхода.
13:25 – 13:40 Коннектор 1С в Digital Q.Integration. Расскажем, как реализован коннектор, какие процессы автоматизированы, как устроена работа с OData и какие возможности получает пользователь при настройке интеграции.
13:40 – 13:55 Практическая демонстрация. Покажем настройку коннектора, получение данных из 1С и изменение.
13:55 – 14:00 Вопросы и ответы. Ответим на вопросы участников и обсудим практические кейсы использования коннектора.
Кому полезен вебинар:
ИТ-директорам и техническим руководителям;
архитекторам интеграционных решений;
руководителям проектов цифровой трансформации;
разработчикам и интеграторам;
специалистам по сопровождению корпоративных информационных систем.
Спикеры:
Виктор Овчинников, руководитель продукта Digital Q.Integration компании «Диасофт»
Андрей Даниленко, ведущий разработчик MSA департамента «Цифровые решения» компании «Диасофт»
Зарегистрироваться на мероприятие можно по ссылке
🎓 Linux со школьной скамьи
Ровно через две недели — 1 сентября. Для тысяч школьников этот звонок станет ещё и первым входом в мир Linux. И это отличный повод поговорить о том, как отечественные ОС входят в образование.
Помните, как в первый раз ставили программу на Linux? И это заняло полдня. Многие ещё тогда прочувствовали стресс перехода с привычных Windows или macOS. Даже когда новая система решает все привычные задачи, первое время она кажется чужой. И этот дискомфорт легко принять за недостаток самой платформы.
Сейчас отечественные ОС всё чаще появляются в школах и вузах. Но если ребёнок с первых уроков информатики работает в Linux, для него это не «альтернативная ОС» и не вынужденная замена. Это обычная среда, в которой он учится, пишет код, готовит презентации и монтирует видео.
Школьный Linux даёт два плюса: дети привыкают к системе без стресса, а компании получают готовых специалистов.
Уже сейчас бизнесу нужны не только сами операционные системы, но и люди, которые умеют с ними работать без страха и раздражения. Таких специалистов проще вырастить со школьной скамьи, чем переучивать.
Кто-то из сегодняшних школьников станет разработчиком, специалистом по ИБ или Linux-администратором. Командная строка, права доступа и установка пакетов уже не будут казаться ему чем-то чужим.
Из того, что уже работает в школах, — РЕД ОС Образовательная редакция и «Альт Образование».
РЕД — не урезанная система «только для уроков»: на ней можно и роботов собирать, и 3D-модели рисовать, и код писать. Плюс есть лёгкий режим для слабых ПК и серверная часть для дневников и учёта.
«Альт» — в том же ключе: от робототехники до инженерной графики, плюс бесплатен для физических лиц и работает на разных архитектурах, включая наши «Эльбрусы».
Конечно, одной ОС тут мало — нужны учителя, методики, инфраструктура. Но хорошее начало положено.
Получается последовательность длиной в целое поколение:
школьный компьютер → колледж или вуз → первая работа → ИТ-инфраструктура.
Пока одни спорят, когда переходить на Linux, другие уже пишут на нём свой первый код. Прямо сейчас, за школьной партой.
х2 работы для ваших AI-агентов
За неделю выкатили сразу несколько релизов — собрали все в один пост. Суть у всех одна: агенты забирают на себя больше задач в ваших проектах.
Теперь можно:
1️⃣ Делиться с агентом файлами в Telegram
Отправляете файл в чат вместе с запросом — агент сделает сводку по CSV с данными или найдет ошибку на скриншоте с логами.
Особенно удобно для тех, кто уже настроил ИИ-помощников в чатах поддержки.
2️⃣ Управлять облаком через команды
Выложили репозиторий со скиллами (инструкциями) для работы с Timeweb Cloud MCP. С ними агент получит готовые сценарии, например, как поднять сервер или настроить DNS. Меньше ошибок и лишних действий.
В Claude Code скиллы ставятся как плагин в две команды, в Cursor, Codex и OpenCode — через npx skills.
3️⃣ Передавать агенту файлы через API
Добавили Files API — отдельный механизм для работы с файлами в API агентов. Он снял прежние ограничения по формату и размеру, и вы можете принимать любые файлы от своих пользователей.
Схема простая: пользователь вашего сервиса прикрепил файл в чате → сервис передал его агенту через API → агент ответил с учетом содержимого.
А еще выкатим новые локальные модели с низкой стоимостью — подробности скоро.
Эксплойт с молоком
Мне очень нравится, когда принципы из защиты информации проявляются в реальной жизни и наоборот. Здесь будет как раз такой пример.
Меламин - синтетическое органическое химическое вещество, используемое для создания прочных смол, пластика, ламината для мебели и посуды. Казалось бы, где меламин, и где молоко? Дельфин и русалка... Но...
Как определяют содержание белка в продуктах? В белках есть азот. Извлекают азот или его соединения (для этого варят в кислоте или сжигают), замеряют их и по содержанию азота считают, сколько было белков. Метод не абсолютно точный, может же быть и иной азот в продукте, но его ничтожно мало и можно принебречь.
Можно принебречь так же, как можно принебречь экранированием апострофа в имени пользователя на сайте парикмахерской. (Вряд ли у нас на районе поселится д'Артаньян или Жанна д'Арк). Но если принебрегли - у нас поселится '; DROP TABLE users; --
Если разбавить молоко бесплатной водой - получим много молока. Но его не примут, так как по азотному тесту содержание белка будет слишком низким. А вот в меламине - 66% азота. Добавляем совсем немного дешевого меламина - и белковый анализатор счастлив!
https://ru.wikipedia.org/wiki/Скандал_с_китайским_молоком_(2008)
Шесть профилей, три локальные модели: как родился Hermes-хаб
Модели отвечали на всё. Проблема была в другом: отвечал кто угодно, только не директор, не разработчик и не аналитик.
Девятого июля я собрал первую версию хаба на Mac mini M4. Шесть профилей: директор (он же оркестратор), разработчик, аналитик, аудитор, Wiki-куратор, писатель. Три локальные модели через Ollama, общий адрес http://127.0.0.1:11434/v1, дефолт на всех профилях gemma4:12b. Звучало как готовый штаб.
А штаба не было. Я задавал вопрос директору и получал ответ без единого признака директора. Роли и принципы лежали в SOUL.md каждого профиля, но написаны по-английски и по шаблону: «You are a chief of staff for a systems architect». Формально всё работало. По сути я разговаривал с одним безликим болванчиком в шести шляпах.
Десятого июля я переписал все SOUL.md на русский. Директор стал «chief of staff для системного архитектора», его задача защищать долгосрочный горизонт пользователя от краткосрочного шума.
На следующий день добавил gpt-oss:20b и llama3.2:3b. Вот тут характеры вроде бы ожили. Модель держала роль, отвечала по-русски и применяла правила, а не пересказывала их.
Личность живёт не в модели, а в тексте, который модель читает перед каждым ответом. На русском она работает лучше.
📐 Применение природных алгоритмов оптимизации в строительном проектировании
Современное проектирование несущих конструкций — это всегда поиск баланса между жёсткими требованиями безопасности и экономической эффективностью. Классические градиентные методы часто не справляются с многомерными пространствами ограничений, характерными для задач ПГС. Поэтому в САПР и ТИМ-решениях всё чаще применяются алгоритмы, подсказанные природой.
🧬 Генетические алгоритмы (GA) Основаны на естественном отборе и эволюционной генетике. В проектировании используются для оптимизации топологии и сечений элементов. Классические примеры — подбор оптимальных размеров подошвы и глубины заложения фундаментов, оптимизация сечений балок и рам. Алгоритм итеративно “скрещивает” варианты, отсеивая решения с недопустимыми осадками, недостаточной несущей способностью или перерасходом бетона.
Отдельное направление — задачи раскроя. Генетические алгоритмы успешно применяются для оптимизации 2D-укладки деталей сложной формы на листах металла, чтобы минимизировать отходы. В 3D-постановке это работает при компоновке арматурных каркасов, раскладке сборных элементов в опалубке или плотной упаковке конструкций для перевозки.
🐜 Алгоритмы роевого интеллекта (Swarm Intelligence) Моделируют поведение групп организмов: миграцию птиц, поиск пищи насекомыми. Наиболее известны метод роя частиц (PSO) и муравьиный алгоритм (ACO). Применяются для трассировки инженерных сетей, автоматического армирования плит, оптимизации геометрии сложных фундаментов. PSO эффективно распределяет усилия по расчётной сетке конечных элементов, снижая концентрацию напряжений за счёт корректировки параметров армирования локальными агентами.
Муравьиный алгоритм особенно полезен в логистике стройплощадки: поиск кратчайших маршрутов движения техники, оптимальная последовательность подачи материалов на монтажный горизонт, обход временных препятствий.
🔥 Алгоритмы имитации физических процессов К ним относится метод имитации отжига (Simulated Annealing), который моделирует кристаллизацию металла при охлаждении. Используется для решения комбинаторных задач: календарное планирование, оптимизация логистики движения материалов, расстановка монтажных кранов, распределение бригад по захваткам при жёстких пространственных и временных ограничениях.
⚠ Ограничения и инженерная практика При всех возможностях природные алгоритмы не заменяют классические расчётные комплексы (МКЭ/FEM). Сегодня они выступают как эффективные препроцессоры: генерируют концептуальные схемы расстановки несущих элементов, варианты раскроя и календарные графики, которые затем проходят обязательную ручную верификацию инженером-конструктором и финальный проверочный расчёт в сертифицированном ПО на соответствие СП/СНиП.
Такой подход позволяет сократить рутину на ранних этапах, но оставляет ответственность за итоговое решение человеку.
Unitree Robotics представила прототип человекоподобного робота Superman, который умеет прыгать в высоту не более чем на 2 метра с места и разгоняется до 12,66 м/с (45,6 км/ч). При длине ноги всего 0,85 метра андроид, как утверждается, побил мировой рекорд по прыжкам в высоту с места у человека.
В Unitree считают разработку Superman экспериментальной платформой для изучения высокодинамичных движений. В этом проекте речь идёт не о готовом продукте, а о демонстрации технологического потенциала роботов. Прототип робота Superman спроектировали и собрали за три месяца.
RoutineOps upd. 17.08.2026
С момента последней статьи сделали много. Так как я условился, что теперь буду выпускать информацию об апдейтах в виде коротких постов, то вот:
- Отполирован macOs агент и функционал с FileVault блоком.
- Логирование действий под временной админкой.
- EN локализация.
- Процесс установки/удаления/преустановки агентов отполирован.
- Самое главное: удаленное подключение к устройству пользователя прям из WebUI.
Подробнее о проекте и функционале в доках репозитория на гитхабе и в постах: Пост про сам проект, первые шаги и финальный функционал первого Public Release! Пост про разработку enterprise версии.
В скором времени подготовлю статью про процесс разработки удаленного подключения, какие были архитектурные решения, сам процесс и финальный результат!
Если вам интересно подробнее узнать про какую то функцию или архитектурное решение, то пишите, рад буду пообщаться на тему проекта.
Как бы я учила Python, если бы могла отмотать время назад...
# Не судите строго, впервые пиши пост, понимаю, что может быть не интересно (по причине опыта), но все же хочется внести свой вклад
Всем привет! Меня зовут Фаина я уже несколько лет пишу на Python (и не только) и зарабатываю этим на жизнь. Недавно я наткнулась на свои старые "конспекты" с первых попыток изучения языка. Это было... больно. Сотни скриншотов, обрывочные заметки и полное непонимание того, что происходит.
Если бы у меня была машина времени, я бы вернулась к той испуганной девушке, которая впервые открыла IDLE, и сказала бы ей несколько важных вещей.
1.Перестать коллекционировать курсы (и начать делать)
Моя самая главная ошибка — «синдром хомяка». Я скачала, наверное, 50 ГБ курсов: "Python с нуля", "Python для чайников", "Python за 24 часа". Я смотрела первые два урока, чувствовала себя умной, а потом бросала, потому что "этот курс не очень".
Итог: Один хороший курс + практика лучше, чем 50 идеальных курсов в папке "Разобрать".
Сейчас, если бы я начинала, я бы выбрала один интерактивный ресурс (или одну книгу, если, конечно, сможешь так учится) и шла по нему, пока не упрусь в стену. Не прыгала бы между ютуберами и методичками.
2.Сначала гуглить, потом — паниковать
В начале пути любая ошибка в коде вызывала у меня панику. Красный трейсбек выглядел как приговор. Я думала: "Ну всё, я бездарь, Python меня ненавидит".
Итог: Ошибка — это не "я плохая", это "код говорит мне, что именно не так".
Сейчас 80% моей работы — это чтение ошибок и гугление.
3.Зубрежка синтаксиса не работает. Работают проекты
Я думала, что если выучу все методы списков и словарей наизусть, то стану сеньором. Я исписывала тетради шпаргалками. Толку было ноль.
Итог: Ты запоминаешь только то, что используешь руками.
Вместо заучивания теории, я бы начала писать мини-программы с первого дня.
День 3: Калькулятор чаевых.
Неделя 2: Парсер курса валют с сайта (с помощью requests).
Месяц 1: Простенький телеграм-бот, который присылает погоду.
Проекты не обязаны быть гениальными. Они должны быть действительно интересные, даже захватывающие.
Если ультра-кратко:
Лучше уж один источник знаний вместо "все сразу"
Лучше практика каждый день по 30 минут, чем раз в неделю и до потери пульса
Ошибки - это норм, не стрем
С другом или ментором будем веселее и эффективнее - с кем можно поделится опытом или обсудить код и тд.
Спасибо за внимание, ваша Фаина!)
Работаешь с разработкой, аналитикой и тестированием? Приходи на ИТ-митап 🔥
9 сентября в офисе «КОРУС Консалтинг» в Санкт-Петербурге состоится ИТ-митап для технического комьюнити (совместно с компанией «ИнфоТеКС»). Никакой теории ради теории: только живые кейсы, реальные инструменты и честный разговор о том, что работает.
О чем поговорим:
➡️ «Безопасная разработка Android-приложений: уязвимости в вашем коде и как их исправить»
➡️ «ИИ-инструменты для аналитика: что изменилось за 2 года»
➡️ «Автоматизация тестирования с помощью ИИ: идеи, гипотезы, результаты»
Мы, конечно, пилим наш продукт в России, но Atmy (ex-Nebo - карта качества воздуха, приложение и датчики) будет жить и за пределами нашей страны.
И перед релизом бета-сайта Atmy мы столкнулись с вполне себе геморройной проблемой - data residency.
С правилами РФ более-менее разберёмся. А вот что делать с SOC2, GDPR и прочими зарубежными требованиями — вопрос открытый. Каждая юрисдикция хочет своё, и универсального рецепта не видно.
Поэтому спрашиваю: как вы сейчас решаете data residency?
▶ Подняли второй Keycloak.
▶ Купили InCountry или Strivacity. Платим $XXk.
▶ Отказались от рынка.
▶ Держим два Auth0 tenants.
▶ Написали свой router.
▶ Ничего не сделали и живём с риском.
Что из этого — про вас? Или есть свой вариант, которого здесь нет?
ИИ в финансовой аналитике: от текстового запроса до готового дашборда – за минуты
Финансовые данные есть у всех. Но собрать их в понятный дашборд для руководителя, принимающего управленческие решения, – эта задача до сих пор отнимает немало времени. На вебинаре мы покажем, как сделать это в разы быстрее с помощью ИИ-агента, который возьмет на себя всю рутину и ускорит получение результатов.
В прямом эфире на реальных финансовых кейсах вы увидите, что умеет ИИ-агент в визуальной аналитике:
генерировать запросы к данным по текстовому описанию без знания синтаксиса;
строить дашборд с нуля по одному промпту - ИИ проанализирует запросы и скомпонует экран с итоговым результатом.
Вы убедитесь в том, что сформировать текстовый запрос и самостоятельно создать визуализацию – без написания SQL-запросов, глубокого программирования и без долгих ожиданий – теперь может каждый.
О чем поговорим на вебинаре:
11:00 - 11:10 Коротко о платформе визуальной аналитики Digital Q.Sensor BI
11:10 - 11:30 Создаем графики и таблицы при помощи ИИ-агента. Визуализируем данные по текстовому описанию
11:30 - 11:40 Строим ситуационные центры на основе данных. Настраиваем метрики и алертинг на дашбордах
11:40 - 11:50 Вопросы и ответы
Спикер - Данила Ильичев, инженер-аналитик Digital Q.Sensor BI «Диасофт»
Зарегистрироваться на вебинар можно по ссылке
Какие уникальные фичи есть в django-modern-rest?
Иногда, когда я добавляю какие-то фичи в мой https://github.com/wemake-services/django-modern-rest (можно ставить ⭐), то я думаю про себя: почему таких фичей больше нет нигде?
Давайте сегодня посмотрим на них. А вы мне расскажите свое мнение в комментах.
Семантическая схема
Допустим, вы навесили на какой-то свой endpoint auth:
class UserController(Controller[MsgspecSerializer]): @modify(auth=[JWTAsyncAuth()]) async def get(self) -> User: ...
В OpenAPI автоматически появятся все коды ошибок, которые могут случиться в auth (401).
Ничего не надо допом писать. И так происходит со всеми частями фреймворка: добавил throttling=[SyncThrottle(1, Rate.minute)]? Теперь у тебя в ответах автоматом 429. Если нужно, можно отключить любые семантические статусы.
Не должно ли такое быть дефолтом везде?
Умные типы ошибок
Не уходя далеко: как кастомизировать формат ошибки, например, в FastAPI? Через боль. Как поменять в спеке формат? Руками.
В DMR мы просто добавили везде error_model как параметр. Можно заменять любые ошибки, все автоматом сконвертится и покажет правильную схему. Зачем? Хочешь Problem Details - используешь. Хочешь свой формат - реализуешь. Можно даже content negotiation на ошибки навесить.
Почему никто о таком не думает в других фреймворках?
Нормальный throttling
Фича, которая принесла мне больше всех боли. Я прочитал throttling реализации во всех фреймворках. В Litestar даже фиксы присылал.
1. Почти нигде из коробки нет поддержки разных алгоритмов, бекендов, иногда даже cache-keys. Очень жаль, есть только обычный counter с бекендом в памяти
2. Нигде (пришлите в комменты контр-пример) нет разделения на throttling до auth и после. Почему такое вообще важно? Чтобы не заддосить auth. И чтобы иметь возможность выдавать per-user правила. Нужны и важны оба варианта
3. Кастомизация заголовков ответа? Ха!
Что? Почему?
Простое переиспользование кода
Когда я смотрю на АПИ разных DRF проектов или FastAPI, мне становится больно. FastAPI строит все на view функциях, которые нельзя нормально кастомизировать. А DRF строит все на импортах строк внутри настроек. А как на счет классов и наследования?
У нас подобное сделано как абстрактные generic классы. Например: получить JWT. Можно выбрать любой сериализатор, можно выбрать любые модели для запроса и ответа:
class RequestPayload(pydantic.BaseModel): username: str password: str class ResponsePayload(pydantic.BaseModel): access: str refresh: str class ObtainAccessAndRefreshSyncController( ObtainTokensSyncController[ PydanticSerializer, RequestPayload, ResponsePayload, ], ): ... # надо еще переопределить 2 метода
Все типизировано, документировано, очевидно.
Как вы думаете, почему так больше никто не делает?
Внешние вьюхи
Интегрировать один фреймворк в другой - крайне сложно. Вот мы недавно даже стрим проводили, потому что не могли использовать dj-rest-auth из DRF. Так быть не должно.
Теперь в DMR можно использовать любые внешние Django View. Хоть DRF, хоть django-ninja, хоть ванильные вьюхи. И отображать любой внешний OpenAPI. Вот настолько просто:
raw_schema = read_openapi_yaml('openapi.yml') router = Router( urls=[ external_path( 'number/', number, name='number', openapi=load_schema(raw_schema['paths']['/api/number'], PathItem), ), ], )
Почему другие фреймворки не стараются вписать существующие решения?
Одной строкой
- Больше подобного у меня в тегеграм канале "Находки в опенсорсе": https://t.me/opensource_findings
- У нас есть еще куча других крутых фичей! Заглядывайте в наш чатик по DMR
- Релизнули django-stubs@6.1 с поддержкой django@6.1
- Сделали папку с крутыми каналами ребят из нашего Python сообщества. Смело можно закидывать коллегам как базовую папку "на кого подписаться в тг по питону". Внутри все мои друзья и коллеги, советую!
Как HiveTrace ускорила запуск AI Firewall для корпоративных приложений с генеративным ИИ
🏭 Что за компания
HiveTrace разрабатывает AI Firewall для защиты приложений на базе генеративного ИИ в корпоративном контуре. Решение анализирует запросы пользователей до их передачи в модель и проверяет ответы модели перед отправкой пользователю. Это защищает от промпт-атак, снижает риск утечки чувствительной информации во внешние системы и помогает соблюдать требования по работе с персональными данными.
⚡ Задача
Чтобы запускать пилоты и масштабировать внедрения у корпоративных заказчиков, HiveTrace требовалась готовая инфраструктура, соответствующая требованиям ИБ-команд: с Kubernetes, GPU и возможностью быстро развернуть решение без доработки существующих компонентов.
Подготавливать окружение для каждого нового проекта самостоятельно означало бы тратить ресурсы команды не на развитие функций безопасности, а на инфраструктурные задачи.
☁️ Что сделали
Для размещения AI Firewall HiveTrace выбрала платформу Cloud.ru Evolution. Решение развернули на базе Evolution Managed Kubernetes с GPU.
Managed-сервисы Cloud.ru оказались совместимы с компонентами HiveTrace, поэтому команде не пришлось адаптировать продукт под новую среду. Это позволило использовать готовую инфраструктурную основу для пилотов и последующих внедрений у заказчиков.
Дополнительно модель HiveTracePro включили в сервис Evolution Foundation Models. Теперь пользователи Cloud.ru могут подключать ее как дополнительный уровень защиты приложений с генеративным ИИ. Модель дополняет Guardrails Filter — инструмент Cloud.ru для маскирования чувствительных данных при работе с языковыми моделями.
🦾 Что получили в итоге
HiveTrace ускорила запуск проектов у корпоративных клиентов: для внедрения AI Firewall больше не нужно отдельно готовить и адаптировать инфраструктуру. Команда может сосредоточиться на развитии продукта и новых механизмах защиты, а заказчики — быстрее подключать защиту своих ИИ-приложений от распространенных угроз.
Методы защиты и обеспечения безопасности ПО
Друзья, рады поделиться записью второго вебинара нашего нового цикла "Надёжность, качество, безопасность ПО: методология и инструменты".
На вебинаре эксперты PVS-Studio и Guardant рассказали, как встроить безопасность в процессы разработки ПО и эффективно защитить программные продукты. Участники узнали, как интегрировать SAST в DevSecOps для раннего выявления уязвимостей, а также разобрались в моделях угроз, подходах к защите ПО и выборе между собственной разработкой решений и готовыми продуктами.
Посмотреть можно тут:
Приятного просмотра!
Саймон Уиллисон, один из создателей Django и автор Datasette, обратил внимание на необычную фоновую музыку в гавайском ресторане. Музыка показалась разработчику однотипной и безликой, тексты песен в каких-то общих чертах рассказывали про нахождение на пляже. Ловким движением руки Уиллисон запустил приложение Shazam, чтобы найти исполнителя. Сервис не смог установить авторство ни одной песни, чем подтвердил опасения Саймона: это ИИ.
Это не первый Гавайев случай, когда в качестве фоновой музыки играет сгенерированная искусственным интеллектом песня. В апреле этого года сообщалось, что в аэропорту Гонолулу играют 17 сгенерированных ИИ треков на тему островов и авиаперевозок. С пяти утра до полуночи в залах Международного аэропорта имени Дэниела К. Иноуэ звучали песни, в которых машинный вокал рассказывал про сотрудников аэропорта, авиалинии, вулкан Дайамонд-Хед и дух алоха.
Реакция пассажиров и местных жителей варьировалась от смешанной до резко негативной. На Reddit персонал аэропорта жаловался, что музыка раздражает; схожим образом высказывались пассажиры, которым громкость воспроизведения показалась избыточно высокой. Кроме собственно качества критикующие указали, что подобные треки плохо представляют культуру архипелага, хорошо известного своей характерной музыкой. Градус возмущения оказался настолько высок, что гавайские музыканты даже собрали альбом-компиляцию музыки для аэропорта и выставили его на продажу на Bandcamp.
Отдельно в СМИ сообщалось, что затея аэропорта не стоит ничего, денег из казны штата потрачено не было, в то время как подписка на фоновую музыку в среднем обходится в $10,5 тыс. (Как минимум с первой половины прошлого века существуют компании музыки для бизнеса, которые сдают в аренду плейлист и специализированное оборудование для его воспроизведения). С каким сервисом сгенерировали эту музыку, не рассказывается, но легко предположить, что это был стартап Suno. Во всяком случае, даже на бесплатном тарифе Suno возможно генерировать по 10 треков в сутки.
Случай же Уиллисона куда более мелкий, это может быть просто инициатива ресторана. В США нельзя включать какую попало закопирайченную песню в общественном пространстве, не заплатив Американскому обществу композиторов, авторов и издателей и/или другой организации правообладателей. Тем не менее резкого падения показателей у компаний фоновой музыки из-за Suno не наблюдается. К примеру, у Stingray в этом году выручка от этого направления только растёт, хотя у другого представителя индустрии, Soundtrack Technologies, наблюдаются проблемы с доходностью.
Как мигрировать с MinIO на S3-совместимое хранилище без остановки продакшена: разбор на вебинаре VK Tech
MinIO зафиксирован в текущем состоянии: активная разработка продукта прекращена, патчи безопасности рассматриваются точечно, совместимость с новыми версиями ОС и оборудования не тестируется. Для организаций, у которых на MinIO или другом open-source S3-хранилище размещены петабайты данных, вопрос миграции переходит из разряда «стоит ли» в разряд «когда и как».
Основная сложность такого переноса — не выбор целевой платформы, а способ переезда без простоя. Большинство open-source инструментов миграции требуют останавливать приложения на время переноса данных, а на многотерабайтных объёмах это окно может растягиваться на часы и дни простоя сервиса.
3 сентября в 16:00 мск VK Tech проведёт вебинар, на котором покажет перенос данных из MinIO в VK Object Storage без остановки сервиса, с техническим демо.
В программе:
почему простой — типичный сценарий при использовании open-source решений и как его избежать при переносе продуктивных данных;
что переносится при миграции: объекты, версии, ACL, bucket-policy, lifecycle, теги, ссылки; что остаётся вне переноса (незавершённые multipart-загрузки);
техническая схема переключения: минимальное окно на смену endpoint, параллельная работа приложений на обоих хранилищах без ограничений на операции;
поведение системы при сбоях и разрывах синхронизации — перенос продолжается с точки останова, а не начинается заново;
модель стоимости перехода в зависимости от объёма данных и масштаба инфраструктуры;
пошаговое демо миграции: от подключения источника до полного переключения трафика.
Спикеры: Георгий Сорокин, PreSale-архитектор S3 VK Tech, и Юрий Петров, инженер-эксперт подразделения сервисов данных и инфраструктурных решений VK Tech.
Вебинар будет полезен средним и крупным организациям с многотерабайтными S3-хранилищами (банки, телеком, крупные SaaS-компании), DevOps- и SRE-инженерам, администрирующим MinIO или другие S3-совместимые решения, а также ИТ-директорам, оценивающим риски дальнейшей эксплуатации MinIO и рассматривающим переход на Enterprise-решение. Отдельно затронут вопросы соответствия 152-ФЗ, реестру российского ПО и сертификации ФСТЭК.
BIPV всё-таки можно сделать подешевле
Я тут в прошлом году писал в телеге про японский Monochrome и их серебристый Roof-1 – солнечный модуль, который выглядит как кусок стандартной и привычной оцинкованной кровли. Тогда я ещё отметил: штука интересная, но $236 за 75 Вт – ну такое… Красиво, конечно, но дороговато.
И вот, походу, японцы тоже так подумали. У Monochrome появился Roof-1e – более доступная версия солнечной кровли, которую они сравнивают с Roof-1, но вариантом black.
Конечно же, я полез к ним на сайт посмотреть, чего они там наворотили, чтоб (забегая вперёд) удешевить модуль. И оказалось, что это не просто Roof-1 black, которому разрешили, так сказать, обнажиться, показывая токопроводящие шины.
Во-первых, у них размеры разные:
Roof-1 black: 1915×384×30 мм
Roof-1e: 2000×438×30 мм
Во-вторых, мощность тоже: 110 Вт против 155 Вт. По расчётному КПД получается 17,2% против 19,9% в пользу e-серии.
То есть внутри, похоже, тоже что-то поменяли, раз такие разительные изменения в выдаваемой мощности. Возможно, в «дешёвой серии» используются другие ФЭП или другая конфигурация. Тут надо копать, конечно.
А так, внешне Roof-1e проще выглядит. Победнее, что ли? У него видны busbars, тогда как у чёрного Roof-1 их практически не заметно. НО! С земли это всё равно выглядит как нормальная красивая кровля, а не поле из солнечных панелей, положенное на неё (крышу). Особенно заметна разница, если смотришь сверху. Ну, там, с квадрика снимаешь или просто из соседнего высотного здания. Тогда, да – заметно. И то - не очень (ну, это я сужу по сравнительным фоткам с сайта Monochrome).
Но что нам даёт новая модель панели? А это нам даёт понимание того, что теперь выбор довольно понятный:
хочешь идеальную эстетику – Roof-1 black (или silver, если денег ещё больше, а выход чистой электроэнергии – это побочный плюс)
не настолько заморачиваешься на то, что видны busbars – берёшь Roof-1e и экономишь.
А вот что они сделали с серебристым Roof-1 – это вообще отдельный разговор. При тех же примерно размерах он выдаёт всего 70-75 Вт, то есть около 10,9% КПД против 17,2% у чёрного. Похоже, за серебристость приходится довольно серьёзно расплачиваться потерей электроэнергии. Но там, кстати, тоже надо разобраться, что именно они используют для получения этого цвета – просто красят защитный слой или сразу ФЭПы цветными делают
В общем, из плюсов у Roof-1e – это уменьшение стоимости 1Вт установленной мощности примерно на 37% относительно чёрного (¥24000 против ¥35000), а про серебряный я вообще молчу. Там стоимость Ватта получается такая:
чёрный – 245 йен/Вт
серебряный – 500 йен/Вт
эконом – 155 йен/Вт Вывод каждый сделает для себя сам, но мне серия “е” прям нравится больше всего.
Плюс отдельные модули можно менять. Повредил один – не надо расковыривать всю крышу. Тоже хорошо.
Есть ещё одна особенность - гарантия. Если на сам продукт у Roof-1 black и silver дают 20 лет, то у Roof-1e – уже 15 лет. Гарантия на мощность у обоих – 25 лет. Но есть нюансики. Если ты находишься ближе, чем 500 метров от побережья – гарантия уменьшается вполовину. Это, видать, особенность Японии – солевой туман, все дела…
Короче, Monochrome, похоже, начинает двигаться в правильную сторону: BIPV должна быть и красивой, но если она стоит как крыло от «Боинга», массовой она не станет. Интересно теперь покопаться, что именно они поменяли внутри Roof-1e. Потому что разница в размерах, мощности и КПД намекает: дело явно не только в видимых busbars. Попробую разобраться.
---
можно почитать ещё новостей солнечной энергетики "Солар-Ньюс" в телеграме - https://t.me/Solarnews
14 октября в Москве пройдёт «Авандок.Пульс» — конференция для тех, кто работает с корпоративным контентом и ИИ
14 октября 2026 года на площадке «Воробьевы Холл» в Москве состоится «Авандок.Пульс» — первая конференция клиентов и партнёров семейства продуктов «Авандок» ГК «КОРУС Консалтинг». Мероприятие состоит из двух частей: Деловая программа и «Авандок.Вечеринка». Участие бесплатное, регистрация на деловую и вечернюю часть — отдельная.
Зачем нужна такая конференция
Рынок управления корпоративной информацией в России долгое время развивался по инерции: компании внедряли системы документооборота, обновляли архивы, наращивали ИТ-инфраструктуру — но чаще поодиночке, без обмена опытом между отраслями. Появление корпоративного ИИ изменило темп: то, что ещё пару лет назад считалось экспериментом, сейчас становится частью операционных процессов у компаний из телекома, промышленности, банковского сектора и энергетики.
При этом накопленный опыт внедрений редко становится публичным — компании либо не делятся деталями, либо делают это в узком кругу на закрытых встречах. «Авандок.Пульс» — попытка изменить эту ситуацию: собрать в одном месте тех, кто уже прошёл путь внедрения, тех, кто выбирает решение сейчас, и тех, кто формирует продуктовую и техническую повестку рынка, и дать им возможность обменяться реальным опытом напрямую.
Что будет обсуждаться
В программе дня — актуальное состояние рынка корпоративного контента и ИИ-решений, обзор решений семейства продуктов «Авандок» (управление корпоративной информацией, корпоративный ИИ, управление данными сотрудников и клиентов), кейсы внедрений от компаний из разных отраслей и панельная дискуссия о том, где применение ИИ в корпоративных процессах уже даёт измеримый эффект, а где остаётся предметом ожиданий.
Отдельным событием дня станет премьера платформы цифровых сотрудников — решения, которое участники увидят одними из первых. Весь день параллельно работает выставка с демонстрацией решений «Авандок».
Почему это имеет значение для рынка
Для отрасли важно не только появление новых продуктов, но и наличие площадок, где обсуждают их реальное применение — с признанием ограничений и открытым разбором того, что не сработало, а не только успешных историй. «Авандок.Пульс» задуман как точка такой информации: возможность сверить собственные ожидания от ИИ и корпоративных платформ с тем, что показывает практика других компаний, и снизить цену ошибки при выборе решений.
Вечерняя часть дня — «Авандок.Вечеринка» с живой музыкой и нетворкингом на площадке с видом на Москва-Сити и на крышу спортивно-развлекательного комплекса «Лужники» — сохраняет неформальный формат, важный для отрасли не меньше, чем деловая программа: многие партнёрства и рабочие контакты в enterprise-сегменте начинаются именно в таких разговорах.
Организатор
«Авандок» — часть ГК «КОРУС Консалтинг», с 2004 года разрабатывает ИТ-решения для управления корпоративной информацией. Решения зарегистрированы в реестре российского ПО и имеют сертификат ФСТЭК 4 уровня доверия. По итогам 2025 года — 2-е место в рейтинге ТОП-10 крупнейших внедрений российских СЭД и 2-е место в российском RAG-бенчмаркинге по соотношению качества и размера языковой модели.
Участие
Бесплатное, количество мест ограничено.
Регистрируйтесь на мероприятие
#АвандокПульс
Telegram | MAX | ВК
МТС True Tech Champ 2026: выбирай свой трек и получи до 10 250 000 ₽ за победу 🔥
Регистрация на четвертый сезон True Tech Champ в самом разгаре. Мероприятие объединяет разработчиков, студентов и школьников со всей страны — все этапы, кроме финала, проходят онлайн.
Участвуй в одном из двух треков: алгоритмическом или программировании роботов, дойди до грандиозного шоу-финала и побеждай!
⚙️ Индивидуальный алгоритмический трек для бэкенд- и фронтенд-разработчиков, фулстек-инженеров, ML-специалистов и всех, кто хочет проверить себя в олимпиадном формате.
Решай задачи по алгоритмам и структурам данных — это прокачает навыки для технических собеседований и работы в ведущих ИТ-командах.
Отборочный этап и полуфинал проходят онлайн, в финале — лайв-кодинг без заготовок: только скорость, логика и умение находить решение здесь и сейчас.
Призовой фонд — 2 750 000 рублей.
🤖 Групповой трек «Программирование роботов» для разработчиков, архитекторов и всех, кому интересно программировать физические объекты:
Проходи трассу и выполняй задания по передаче предметов.
Затем — удалённое управление реальным полигоном с робособакой и роботом-манипулятором.
В очном финале лучшие команды дорабатывают алгоритмы на глазах у зрителей и борются за победу в МТС Live Холл в Москве.
Призовой фонд — 7 500 000 рублей.
Участие бесплатное, а лучшие участники получат шанс на стажировку в МТС Web Services (MWS).
➡️ Выбирай свой трек и регистрируйся по ссылке.
Figma запустила собственный генератор скиллов для встроенного ИИ:
better‑interface — делает UI в разы удобнее и читабельно;
superfuture‑design‑review — делает полное ревью дизайна и предложит свои правки;
component‑handoff — составит полную документацию по нужному компоненту;
desktop‑to‑mobile — быстро конвертирует дизайн в мобильный формат;
create‑anatomy — создаёт полную визуальную анатомию выбранного элемента;
find‑animation‑opportunities — упрощает работу с анимацией;
spacing‑audit — фиксит проблемы с расположением элементов и пропорциями;
balise‑ux‑writing — перерабатывает, генерирует и приводит к единому стилю тексты;
analyze‑components — делает полный аудит всех компонентов на странице;
design‑system‑gen — генерирует компоненты по простым стилевым вводным.
Подборка бесплатных сервисов с разрешённым коммерческим использованием красивых иллюстраций для сайта, презентации или приложения:
• oishiso.jp — иллюстрации в стиле вкусной еды и кулинарии;
• irasutoya.com — бесплатные иллюстрации на самые разные темы;
• enpitsu-sozai.com — тёплые иллюстрации в стиле карандашных рисунков от руки;
• nawmin.stores.jp — сельхозпродукты, фермерство и деревенская жизнь;
• vectorshelf.com — качественные векторные иллюстрации в стиле ручной рисовки, есть AI, PNG и SVG;
• loosedrawing.com — простые линейные рисунки с возможностью менять цвет прямо на сайте;
• storyset.com — векторные иллюстрации для презентаций и веба с настройкой цвета и анимации;
• openpeeps.com — рисованные персонажи, которых можно собирать в разных комбинациях;
• undraw.co — чистые векторные персонажи в стиле IT и стартапов с настройкой цвета;
• illustrations.run — наборы открытых векторных иллюстраций на разные темы
