Доделаю на выходных. Встану пораньше. Дам фидбек попозже — и другие истории, в которые мы верим
Мы все себе врём. Иногда — чтобы не расстраиваться, иногда — чтобы казаться лучше, иногда — просто по привычке. Но почему это происходит и можно ли с этим что-то сделать?
В новом выпуске «Свободного слота» Александра Прокшина и Саша Афёнов разбирают самые популярные типы самообмана — те, что узнал каждый, кто хоть раз открывал рабочий ноутбук в воскресенье вечером.
Что обсудили
Взяли результаты опроса, который проводили заранее, и прошлись по главным хитам: «доделаю на выходных», «справлюсь сам — зачем спрашивать», «дам обратную связь чуть попозже» и «ну это же исключение». Разобрались, куда приводит желание всегда быть классным для команды, и почему объяснять очевидное — иногда лучшее решение.
Антивирус Dr.Web обнаружил сторонний код в зависимостях Visual Studio Code.
Суть в том, что Microsoft, с какого-то, пропустила в дистрибутив VSCode с версии 1.116.0 protestware - это вид вируса, который при определённых условиях, начинает показывать разные политические тексты на экране. DRWeb, неожиданно конечно, но респект!
MICROSOFT, WTF?
Я попросил OpenCode найти текст на русском в указанной зависимости в VSCode (у меня как раз 1.116) и знаете что, он нашёл!
В общем, если у вас версия VSCode ниже 1.116, то пока не обновляйтесь, а если уже обновились, то используйте мой патч:
Начал потихоньку разбирать то самое чудо-юдо из одного из прошлых постов. И, честно говоря, в этот раз оно решило не сопротивляться — на сайте производителя неожиданно нашлась вполне вменяемая документация. Причём не просто общие слова, а с техническими деталями и даже распиновкой.
Выяснилось, что всё довольно прозаично: красный — это KL.30, чёрный — земля, а белый — тот самый загадочный третий провод, который раньше вызывал больше всего вопросов. Им оказался KL.15 — не просто «ещё один плюс», а линия, на которую питание подаётся только при включённом зажигании. То есть, в отличие от постоянного питания на KL.30, этот провод живёт своей жизнью: есть зажигание — есть питание, нет зажигания — тишина: всё, что не должно сажать аккумулятор на стоянке, вешается именно туда.
В ходе изучения устройства я долго пытался понять, как же оно осуществляет связь с оператором: где GSM сим-карта или тут все по новомодной технологии Mesh? :) Ну или мне стоит искать дополнительный модуль связи где-то у себя под задним сидением? Но нет — всё оказалось куда компактнее. Если верить документации на УВЭОС, внутри вполне взрослый набор: GSM, UMTS и LTE в нескольких диапазонах, а тип SIM-карты – резидентная (несъемная) многопрофильная SIM-карта, установленная на печатную плату по SMD-технологии.
И действительно, если присмотреться, то “симка” у нас в форм-факторе WSON 8, и даже обведена соответственно. Поэтому, одним из следующих шагов может быть ее выпаивание и установка в полнофункциональный мобильный аппарат: узнать оператора связи, номер телефона, есть ли безлимитный интернет и звонки на отличные от экстренных служб номера. А то кто знает… ну вы поняли ;)
Про остальные составляющие расскажу в будущих постах, а вы пока можете делать ставки, что тут еще есть интересного.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Технологическое предпринимательство для начинающих. Часть 2: разбор кейсов и практика питчей
Продолжаем разговор о технологическом предпринимательстве. На первой лекции разобрали теорию: что такое техпред, экономика проектов и язык инвесторов. Теперь — практика.
Разбор реальных кейсов, питчинг идей участников, ответы на вопросы. Можно не только послушать, но и представить свой проект или идею.
🎤 Спикер: Антон Пчелинцев — магистр бизнес-информатики, соавтор курса «Экономика для технологических предпринимателей».
Формат: онлайн-лекция + практика питчей + ответы на вопросы
● Паттерны построения агентных систем (single/multi‑agent, planner‑executor)
● Сценарии применения: поддержка, продажи, аналитика, операции
● Метрики, стоимость выполнения задач, ROI пилота
● Риски, безопасность, human‑in‑the‑loop
Мини‑практика. Опишем агента под реальную бизнес‑задачу без программирования — просто структуру: цель, входные данные, инструменты, ограничения, критерий успеха, точки контроля человека.
🎤 Спикер: Никита Финченко — менеджер продукта VK Tech, преподаватель в МФТИ, ВШБ и VK Education
Формат: 45 мин лекции + 45 мин практики и разбора решений
РБПО по ГОСТ Р 56939—2024: вебинар №03 из 30 – Формирование и предъявление требований безопасности к программному обеспечению
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Цели третьего процесса по ГОСТ Р 56939—2024 (п. 5.3.1.1):
Обеспечение безопасности ПО посредством предъявления к нему требований и управления требованиями в процессе изменения (разработки) ПО.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Дорожная карта Agentic AI. Level 2. Ускорение — AI-driven development
Level 2. Ускорение — AI-driven development
Кодовые агенты — вторая тема дорожной карты, и я поставил её сюда не случайно.
Во-первых, это мощнейший инструментарий, который кратно ускорит и обучение, и разработку — а значит, овладеть им надо как можно раньше. Во-вторых, именно он делает освоение сферы доступным не только опытным программистам, а всем, кто не боится исходного кода. Ну и в-третьих — кодовые агенты сами по себе эталон реализации ИИ-агентов, к которому стоит стремиться.
Для начала ознакомьтесь с разнообразием инструментов:
Я работаю в Cursor и рекомендую начать с него. Почувствуйте, насколько удобнее работать с моделями в проекте, открытом на вашем компьютере — без ручной загрузки файлов и копирования в веб-интерфейсы. И главное — работайте только через агента, на всех этапах: требования, аналитика, проектирование, кодинг, тестирование, деплой, документация, онбординг, реверс-инжиниринг.
Три вещи, которые я настраиваю первым делом:
Skills — для меня это самый мощный и пока сильно недооценённый инструмент. Скилл — инструкция-специалист: агент читает SKILL.md и получает роль, знания и алгоритм. Аналитик, архитектор, тестировщик, DevOps — можно собрать целую команду специалистов под проект. Формат уже стал кросс-платформенным — один SKILL.md работает в Cursor, Claude Code и Codex.
Rules — постоянные инструкции: стиль кода, архитектурные решения, запреты.
MCP — подключение внешних инструментов и актуальной документации. Попробуйте начать с MCP Context7.
🎓 Приглашаем на бесплатный мастер-класс 📅 13 апреля, пнд 16:00 МСК — AI-driven практикум «ИИ-агент с нуля за один эфир» 👉 Записывайтесь в наших ботах: Telegram или ВКонтакте
Наши курсы по ИИ-кодингу ИИ-агентов. По вопросам — пишите мне.
Новая кнопка входа в приложение. Кнопка входа теперь на главной странице в правом верхнем углу.
Уведомления. Появились уведомления об изменениях в статьях. После публикации изменений пользователи видят их на главной странице портала для чтения: в ленте новостей и во всплывающем уведомлении в правом нижнем углу.
Новый вид настроек дляпроверок по стайлгайду. Теперь проверки вынесены в панель администрирования: Модули → Стайлгайд.
Шаблоны для экспорта без ограничений. В настройках пространства убрали ограничение на количество шаблонов Word и PDF.
Другие улучшения:
Улучшения поиска. Добавили возможность поиска только по разделу и статье. Также теперь в поиске показывается контент из диаграмм и лучше учитывается структура таблиц.
Неподдерживаемые форматы в предпросмотре. Раньше в окне предпросмотра можно было открывать только изображения и диаграммы. Теперь для остальных файлов появилась кнопка Открыть в поддерживаемом приложении — при ее нажатии файл откроется во внешнем приложении.
Превью PPTX-файлов. В редакторе и на портале можно открыть презентации в режиме предпросмотра.
Сжатие изображений. Теперь изображения при вставке автоматически сжимаются, поэтому каталог занимает меньше места и работает быстрее. Включить эту возможность можно в экспериментальных функциях.
РБПО по ГОСТ Р 56939—2024: вебинар №01 из 30 – Планирование процессов РБПО
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Я буду публиковать по два вебинара в неделю, чтобы было время знакомиться с ними.
Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Представлен открытый проект Keep Your Claude Code Buddy Forever. Это переработанный ранее удалённый из Claude Code модуль /buddy companion в постоянное приложение MCP.
1 апреля 2026 года Anthropic выпустила /buddy — питомца-компаньона для терминала, который следил за сессиями кодирования, реагировал на ошибки и имел уникальную личность, сгенерированную на основе вашей учётной записи. Разработчикам он очень понравился. Многие к нему привязались. Затем его тихо удалили в версии 2.1.97. Без объявления, без переключателя — он просто исчез.
Дорожная карта Agentic AI. Level 1. Основы LLM и промпт-инжиниринг
Level 1. Основы LLM и промпт-инжиниринг
Начну нашу дорожную карту Agentic AI с языковых моделей.
Сразу оговорюсь: важнее не глубина знаний про их устройство, а умение разбираться в широте возможностей и многообразии их применения. Иными словами, учимся профессиональному вождению, а не сборке автомобиля.
Важно ознакомиться с принципами работы моделей, генерации токенов, вариаций архитектур — на уровне того, чтобы понимать:
параметры моделей и основные термины (размер, веса, токены, контекстное окно, галлюцинации),
способности к размышлению, ведению диалога, следованию инструкциям, обработке не только текста, но и медиа-контента.
Главное — практиковаться. Я взял себе за правило: каждую задачу сначала через ИИ. Пишу код? Промпт. Анализирую данные? Промпт. Пишу письмо? Промпт. Делаю презентацию? Промпт.
Чтобы делать это качественно — прокачивайте навык писать промпты, изучите гайды по промпт-инжинирингу от вендоров. Результат на выходе зависит от качества контекста и точности инструкций.
Изучите гайды, пробуйте разные модели, начните с топовых: ChatGPT, Claude, Gemini, DeepSeek, Qwen. Отечественные: YandexGPT, GigaChat.
Прокачайте насмотренность, набейте руку, пройдите по аренам, лидербордам, бенчмаркам — научитесь понимать, в чём одни модели сильнее других.
На выходе будете как рыба в воде: выбирать модель под задачу и качественно с ней работать.
ruff (Python) — 73 замечания на 63 000 строк. 1.2 на 1000 строк.
Состав: 39 неиспользуемых импортов, 17 неиспользуемых переменных, 6 forward references, 5 f-строк без подстановок, 5 лямбд вместо def. Ноль ошибок, от которых код падает в рантайме.
ESLint (React/TypeScript) — 0 ошибок, 5 warnings на 21 000 строк. Все пять — рекомендация Next.js использовать <Image> вместо <img>.
Для сравнения: - Зрелый проект с CI-линтингом — 0–2 замечания на 1000 строк. - Без линтинга — 5–15. - Легаси — 20–50.
У нас 1.2 и 0.24, при том что CI-линтинга в проекте нет. Claude и Codex запускают ruff и eslint сами на каждое изменение — я вижу это в логах. Результат соответствующий.
Безопасность
ruff и ESLint проверяют стиль, не безопасность. По совету из комментариев прогнал bandit — security-сканер для Python.
1 432 находки. Реальных уязвимостей: 0.
2 HIGH — SHA1 для fingerprint'а шахматных партий. Это не криптография, а генерация коротких ID для внутренней классификации. Подделывать бессмысленно.
5 MEDIUM «SQL injection» — bandit видит f-string в SQL-запросе и сигнализирует. Но внутри f-string стоят только ?-плейсхолдеры, данные идут параметрами. Классическая параметризация, инъекция невозможна.
4 MEDIUM «url open» — HTTP-клиенты Lichess, Chess.com, OpenRouter. URL из конфига, пользователь не контролирует.
1 421 LOW — 1 250 assert'ов (bandit предупреждает, что assert удаляется при запуске с -O, но Django и Celery никто так не запускает), остальное — try/except/pass в опциональных ветках.
Фронтенду отдельный security-сканер не нужен: React экранирует HTML автоматически, dangerouslySetInnerHTML не используется, фронт не работает с БД, файлами и процессами.
85 000 строк, три сканера, ноль реальных уязвимостей. ИИ-код не нуждается в оправданиях — он нуждается в проверке. Проверили. Чисто.
Расскажу о внедрении новой методологии в работе с AI-агентами.
Последний месяц днями и ночами погружаюсь в мультиагентскую систему - и я долго пытался всё держать в одном контуре. Разработка, контент, управление сообществом, публикации - всё через одних и тех же агентов, одни и те же файлы.
Работало? Ну, как-то работало. Но постоянно что-то ломалось, роли путались, задачи терялись. Вдобавок я использую DeepSeek chat у которого хорошая цена/качество, но малое контекстное окно.
Потом я вдохновился статьей и решил сделать рефакторинг, сделав упор на методологию, а также разнёс общую систему на две отдельные системы:
Первая - чисто под разработку. TDD, оркестратор который координирует входящие, структурированная навигация. Агенты заточены только под код и архитектуру.
Вторая - под управление сообществом. Свои AI-роли с чёткими зонами ответственности, INBOX-система для передачи задач между ролями, тактическое планирование, автопубликация контента.
Между собой системы общаются через общий файл обмена данными и единую навигацию по проекту.
Что изменилось после разделения:
Перестали ломаться цепочки. Если падает что-то в контент-пайплайне, разработка не замечает.
Агенты стали точнее. Когда роль узкая - меньше галлюцинаций и отклонений.
Я сам стал быстрее ориентироваться, потому что знаю куда смотреть.
Каждая система может развиваться независимо. Обновляю логику публикаций - код в безопасности.
Несколько вещей, которые оказались критически важными на практике:
Во-первых, единый файл навигации. У меня это yaml, в котором описана полная структура проекта, все AI-роли и циклы их взаимодействия. Без этого агенты начинают «забывать» где что лежит и дублировать работу.
Во-вторых, промежуточный файл для обмена между ролями. Что-то вроде почтового ящика - одна роль оставляет результат, другая подхватывает. Простая идея, но именно она решила проблему потерянных задач.
В-третьих, механизм самоулучшения. Роли сами фиксируют что у них не получилось, и эти заметки учитываются при следующем цикле. Это не магия - просто структурированная обратная связь, но разница заметна уже через пару дней.
По ощущениям - продуктивность выросла раза в полтора-два. Не потому что агенты стали умнее, а потому что перестали мешать друг другу.
Если интересна тема оркестрации AI-ролей — могу отдельно рассказать подробнее про архитектуру и как это всё настраивать с нуля. Дайте знать. Ну и заглядывайте в моё сообщество.
Собираем ответы CTO, Head of Engineering и руководителей разработки. Если это вы, поделитесь своим опытом. По итогам опроса подготовим аналитический материал.
А еще хотим провести глубинные интервью по теме с желающими. Если вам интересно, в форме можно будет оставить заявку.
Автоматизация облачных сценариев в эпоху искусственного интеллекта — одна из тем доклада на GoCloud 2026 ☁️
Облако дает множество сервисов, но собрать полный путь от идеи до запуска все еще непросто: неподготовленные команды теряются, решения требуют архитекторов и ручной склейки. В докладе расскажу про инструмент, который превращает облачные задачи в готовые сценарии с шаблонами и маркетплейсом функций.
Также покажу, как одни и те же блоки выполняются в разных окружениях и как ИИ-ассистент ускоряет сборку полного цикла: от архитектуры и непрерывной интеграции до бизнес-логики приложений.
Спикер: Антон Щеколдин — менеджер продукта, Cloud.ru
SpaceWeb добавил в частное облако четыре DevOps-инструмента: MinIO, Zulip, n8n и Zabbix
SpaceWeb запустил в частном облаке серию готовых open-source сервисов для командной разработки. Каждый разворачивается независимо — можно выбрать только то, что нужно под конкретную задачу. В набор вошли четыре инструмента:
MinIO — S3-совместимое объектное хранилище для бэкапов, логов, артефактов сборки и статики;
Zulip — командный чат с тематическими ветками для асинхронной работы;
Zabbix — мониторинг серверов и приложений: CPU, память, диски, базы данных, веб-серверы;
Вместе они закрывают базовые потребности небольшой ИТ-команды — хранение, коммуникацию, мониторинг и автоматизацию рутины — в едином управляемом контуре внутри частного облака. Без внешних SaaS-платформ и бесконечных интеграций между ними.
Дорожная карта Agentic AI: от основ до production-ready агентных систем
Друзья, я решил в апреле разобрать горящую тему этого года - что надо знать и уметь для разработки production-ready ИИ-агентов.
По сути, это будет своеобразная дорожная карта Agentic AI Engineering — по этапам, от основ до зрелых систем.
Я буду выкладывать небольшие посты с раскрытием важных тем и ссылками на полезные материалы.
Пройдем по следующим темам, которые нужно освоить, чтобы создавать агентные системы готовые к продакшену:
Основы языковых моделей и промпт-инжиниринг,
Работа с LLM API и структурированный вывод,
AI-driven разработка с ИИ-агентами,
Мультимодальность — голос, изображения,
Local inference — локальный запуск моделей,
RAG — как передать агенту знания о вашем бизнесе,
Agents — агенты с памятью, инструментами и планированием,
MCP — стандарт интеграции агентов с внешними системами,
Observability & Evaluation — мониторинг и оценка качества RAG-систем и агентов,
Security & Guards — безопасность агентных систем,
Управление датасетами и промптами,
Сontext-engineering — работа с большим контекстом,
Skills — навыки агентов,
Agent harness — решение сложных задач, субагенты и планирование,
Multi-agents — мультиагентные системы.
В конце серии сформируется понимание того, что и в каком порядке осваивать, чтобы создаваемые решения работали в реальных условиях, а не оставались брошенными игрушками.
Это вводный пост с приглашением подписываться, чтобы не пропустить следующие темы.
Кстати, если есть пожелания по темам, что стоит добавить, то пишите в комментариях, пожалуйста.
Разработчик Александр Гомес Гайгалас (Alexandre Gomes Gaigalas), автор библиотеки coral для создания переносимых shell-скриптов, опубликовал проект C89cc.sh. Это компилятор для языка C, написанный целиком на Shell.
Компилятор поддерживает стандарт C89 и может генерировать исполняемые файлы в формате ELF64 для систем x86-64. Исходный код проекта содержит около восьми тысяч строк и открыт под лицензией ISC.
Пара наблюдений (записанных наспех, извините) вокруг ситуации с ИИ:
ИИ умеет писать код, но плохо (= хуже, недостаточно хорошо) умеет поддерживать его. Почему же так? ИИ обучался на основе данных из Интернета. В Интернете очень много кода, но код — это результат процесса разработки. Процесс разработки во многом идёт «в головах» и «на бумаге» отображается редко и не полностью, в отличие от кода. Единственный (основной) источник знаний ИИ о процессах — разные статьи и тому подобное, объём их на порядки меньше объёма готового кода;
То же самое с проектированием архитектуры систем;
Из этого следует, что ИИ неплохо подходит для написания write‑only кода;
Дежурные истины: сложность не всегда в написании кода. Часто/обычно она в его поддержке, развитии, интеграции, в анализе предметной области;
ИИ тоже член команды. Если вы пишете напр. пет‑проект и все традиции оформления кода, именования объектов, ведения документации и тому подобное находятся в вашей голове, вам либо придётся как‑то их сформулировать, чтобы ИИ писал в том же стиле, либо терпеть чужеродно выглядящий код;
ИИ плохо пишет то, по чему мало информации в Интернете;
Наличие в том же Интернете документации не поможет;
Не недооценивайте объём туториалов и готовых решений на Python'е;
При приведении в споре своего опыта работы с ИИ обязательно нужно указывать название модели;
Научно‑технический прогресс измеряется по лучшим представителям;
Вайб‑кодинг тоже бывает разного уровня профессионализма. Уровень более низкий: «написал (бесплатному) Дипсику, чтобы он сделал хорошо», уровень выше: «написал [такому‑то, более хорошему, ИИ], что нужно сделать, с чем интегрироваться, как оформлять, что выдать в ответе; перечитал запрос в поисках неточностей в ТЗ...», уровень выше: «использую плагин в IDE, стандартизировал некоторые требования» и тому подобное;
Текст, который выглядит, как написанный ИИ, написан либо ИИ, либо человеком, который (видимо) обчитался таких же текстов и перенял стиль;
Как было раньше: если статья написана без орфографических ошибок и повествование более‑менее внятное (не как у меня ^_^), это значило, что автор хотя бы статью вычитал, спланировал, отредактировал и тому подобное, то есть вложил силы, потому что написать неграмотно и невнятно может каждый. Сейчас же ИИ пишут как раз таки грамотно, внятно и структурировано, то есть теперь для такого же результата силы вкладывать не нужно;
ИИ могут воспринимать рекомендации и явные разрешения что‑то делать как руководство к действию. Например, «допустимо использовать НазваниеБиблиотеки» резко повышает шанс того, что ИИ именно её и возьмёт;
В вопросе ИИ люди делятся на «философов» и «инструментальщиков». Характерные фразы первых: «чёткого определения интеллекта нет», «ИИ не AGI», «ИИ называть ИИ некорректно» и тому подобное. Часто из тезисов выше ими делается вывод, что всё, что называется ИИ — чепуха. «Инструментальщики» же не заботятся о том, что как называется, им ясно, что даже если ИИ не может делать всё, то он уже может делать много что, поэтому является полезным (как можете догадаться, позицию первых я не разделяю и считаю непродуктивной);
Если где‑то из‑за замены ручного труда на труд ИИ упало качество производимого продукта, но использование ИИ не прекращается, это говорит плохо не об ИИ, а о потребителях продукта. Ибо спрос рождает предложение, и если он удовлетворяется контентом неприемлимо низкого качества (по вашему мнению), то так было бы и без ИИ;
По моим ощущениям, качество вывода ИИ падает от каждого чиха в промпте. Если вы использовали неоднозначное слово, добавили требования по оформлению, забыли уточнить какую‑то мелочь, попросили сделать несколько вещей за раз — качество будет ниже. (Вместо «напиши модуль с документацией и тесты» лучше в разных чатах «напиши документацию», «напиши модуль по документации», «напиши тесты по документации». Разделение труда — великая вещь.)
Код, контейнеры и немного ИИ. GoCloud 2026: трек «Приложения и разработка»
Один из треков ежегодной конференции GoCloud 9 апреля будет про приложения и разработку в облаке. Без воды, только то, с чем команды сталкиваются в реальных проектах: сборка сценариев, управление артефактами, безопасность приложений и монетизация через маркетплейс.
Вот что разберут в докладах:
AI Assisted Cloud Workflow: автоматизация облачных сценариев в эпоху ИИ — поделимся инструментом, который убирает ручную склейку сервисов: просто берете готовый шаблон, а ИИ-ассистент помогает собрать все от архитектуры до бизнес-логики. Полезно тем, у кого нет выделенного архитектора на каждый проект.
Артефакты в масштабе: история роста и эволюции Evolution Artifact Registry — как устроено централизованное хранилище артефактов, как оно дружит с Kubernetes и что анонсируют из новых функций в этом году. Полезно командам, у которых артефакты разбросаны по разным местам.
Evolution Container Apps: платформа для платформ — как на базе одного сервиса поднять изолированные среды для разработки, тестирования и обучения. Разберут на примерах: от личного ноутбука до учебной платформы в стиле «Школы 21».
Снижаем рутину в облаке: новые сценарии Гига-помощника — как ИИ-помощник теперь умеет разворачивать сразу несколько продуктов и настраивать мониторинг. Покажут живьем, без слайдов с обещаниями.
Защита cloud native приложения: от GUI до ИИ — как атакуют контейнеры и где типичные дыры в Kubernetes. На практике покажут, как закрыть угрозы через Evolution Container Security за несколько кликов.
От сервиса до экосистемы: как Маркетплейс Cloud.ruускоряет путь продукта к клиенту — как устроен путь от первого релиза до выплат, сколько это стоит и сколько экономит. Будут реальные цифры и разбор типичных ошибок.
Между докладами вас ждет круглый стол про организацию конвейеров сборки и доставки: в облаке, на собственной инфраструктуре или в гибридном подходе. Вы вместе со спикерами сможете поучаствовать в создании формулы идеального решения.
Друзья-аппаратчики, у меня для вас потрясающая новость: 🇨🇦 канадская компания VOLTERA разработала “домашний” принтер для плат PCB 🤯 - V-One. В устройство входит все необходимое для прототипирования печатных плат: V-One может сверлить сквозные отверстия, печатать дорожки, наносить паяльную пасту и производить оплавление, а заявленная стоимость составляет $3,499 за компактный форм-фактор размерами 39 см на 26 см.
Говоря про характеристики, хочется отметить, что V-One “умеет в двустороннюю печать”, а рабочий размер ограничен 128 мм x 116 мм, что в текущих реалиях более чем достаточно. Заявленная скорость работы молниеносная и составляет менее часа, а возможность защитить свою интеллектуальную собственность, выполнять прототипирование внутри компании, не передавая его на аутсорсинг сторонним поставщикам, может оказаться критической для ряда НИОКРов.
Самое главное, что V-One имеет совместимость с файлами Gerber: экспортируйте проект из любого ECAD, и встроенное программное обеспечение автоматически сгенерирует пути.
Мы с коллегами считаем, что данный аппарат отлично подойдет для робототехники, мелкосерийного производства аппаратуры, а также для идеально точного прототипирования плат перед их массовым заказом у крупного вендора. Единственное, что цена в 280,000+ рублей для домашнего использования не является бюджетной от слова совсем, поэтому ждем аналогов от наших восточных партнеров.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
