Присоединяйтесь к встрече для ИТ-руководителей — поговорим про изменения, стратегию, выгорание и управление в эпоху ИИ 🤖
Встреча для ИТ-лидеров пройдет 28 августа в Москве с онлайн-трансляцией. В программе доклады и дискуссии о внедрении ИИ-агентов, управлении изменениями, стратегических ставках в эпоху ИИ и биологии выгорания.
Вас ждут доклады:
«Разрыв: между амбицией и исполнением». По данным Gartner, ИИ-агентов реально внедрили около 17% компаний, при этом более 60% планируют сделать это в ближайшие два года. Разберём, почему ожидания расходятся с реальностью и как этот разрыв влияет на ИТ-команды.
Спикер — Дмитрий Лаптев, директор по технологической стратегии MWS.
«Эволюция Agile в эпоху агентов: как ИИ сделать союзником команды, а не угрозой?». Обсудим, почему простая замена людей агентами не даёт качества и как перестроить работу, чтобы ИИ расшивал узкие места.
Спикеры — Евгений Калабин, руководитель группы обучения и продвижения практик Agile MWS, и Ольга Склярова, лидер Agile ИТ-кластера «Продажи и обслуживание» MWS.
«Вредные советы по управлению изменениями: как перестроить процессы и выжить». Разбор реальных кейсов с юмором: что происходит, если пропустить ключевые шаги ADKAR, почему команда сопротивляется изменениям и как превратить разовые «вау»-инициативы в устойчивые процессы.
Спикер — Ольга Шутова, тимлид команды разработки Т-Банка.
«Биология выгорания: как стресс из двигателя прогресса превратился в когнитивное искажение». Поговорим о том, как стресс влияет на продуктивность и творческое мышление, и как управлять своим состоянием.
Спикер — Сергей Харитонов, молекулярный биолог, сотрудник МГУ, научный сотрудник Института биологии старения и медицины здорового долголетия.
«Управлять тем, чего ещё нет: как запускать новое и делать стратегические ставки в эпоху AI». Как выбирать идеи, которые заслуживают инвестиций, и проверять гипотезы в условиях неопределённости.
Спикер — Анастасия Азоркина, главный менеджер продукт
«Работа не work, работа — волк: серые практики устройства в ИТ». Какие скрытые риски несут сторонние помощники и «серые» практики при найме в ИТ и как компаниям защитить себя.
Спикер— Андрей Репин, лидер QA ИТ-кластера «Развитие инфраструктуры» MWS.
📅 Когда: 28 августа в 17:30
📍 Где: Москва, метро Технопарк + онлайн-трансляция
👉 Регистрируйтесь, чтобы обсудить актуальные вызовы с коллегами. Ждем вас!
Первый опыт управления IT-командой: три вывода, которые я сделал
Когда я впервые начал отвечать не только за свою работу, но и за результат небольшой IT-команды, мне казалось, что задача руководителя достаточно простая: распределить задачи, определить сроки и проверить результат.
На практике сложнее всего оказалось не контролировать разработку, а сохранять общий контекст, снимать блокировки и не становиться человеком, через которого должно проходить вообще всё.
Вот три главных вывода, которые я сделал.
Сообщение в чате ещё не является задачей
Большая часть нашей коммуникации проходит в переписке. Это быстро и удобно, но именно в чатах задача легко теряет смысл. Я пишу, что нужно изменить определённое поведение, разработчик задаёт несколько вопросов и начинает работу. Через пару дней выясняется, что итог мы представляли по-разному.
Проблема не в невнимательности. Часть контекста, очевидная для меня, просто не была зафиксирована.
Теперь я стараюсь указывать четыре вещи: зачем нужно изменение, что должен получить пользователь, какие ошибки необходимо учесть и по каким признакам мы примем результат. Даже короткое описание работает лучше, чем цепочка сообщений, разбросанная по нескольким дням.
Задержка не всегда возникает внутри команды
Некоторые задачи зависят от внешних систем и людей, которыми команда не управляет. Например, функция уже реализована, но источник данных периодически возвращает ошибку. Можно бесконечно менять клиентскую часть, хотя постоянное решение требует другого способа интеграции и участия смежной команды.
В такой ситуации бесполезно просто требовать «починить быстрее». Нужно разделить саму разработку и внешнюю зависимость: что уже сделано, где возникла блокировка, кто может принять решение и допустим ли временный вариант.
Для меня это стало важным изменением. Руководитель нужен не только для контроля сроков. Он должен подключать нужных людей и не оставлять разработчика один на один с проблемой, которую нельзя решить внутри команды.
Приёмка является отдельной работой
Технически выполненная задача ещё не всегда означает готовый результат. Экран может открываться, кнопка нажиматься, запрос отправляться, но весь пользовательский путь остаётся непроверенным.
Поэтому я стараюсь принимать работу не по отдельным функциям, а по сценариям. Проверяю основной путь, пустое состояние, ошибку сервиса, повторное действие и возвращение в раздел. Такой список не заменяет тестирование, но помогает не принять за готовый продукт набор экранов, работающих только по отдельности.
Что оказалось самым важным
Первый управленческий опыт показал мне, что руководство мало похоже на раздачу задач. Основная работа происходит между ними: сохранить смысл, выбрать приоритет, снять блокировку и проверить, что технические результаты сложились в работающий продукт.
От руководителя не требуется знать ответы на все вопросы. Но он не должен допускать, чтобы команда неделями ждала решения, доступа или недостающего контекста.
А какой вывод стал главным для вас при первом переходе от самостоятельной работы к управлению командой?
Wildberries выпустила собственный мессенджер WB Chat
У Wildberries появился собственный мессенджер WB Chat. Приложение уже доступно пользователям на Android и iOS, а авторизация проходит через WB ID.
Интерфейс построен по знакомой схеме: диалоги разделены на чаты, группы и каналы, причём создать собственную группу или канал можно непосредственно из приложения. Есть отдельный раздел профиля с аватаром, именем, статусом и возможностью выбрать юзернейм, а для организации переписок предусмотрены папки.
Набор функций тоже постепенно расширяется. Сейчас WB Chat позволяет:
отправлять сообщения, фото, видео и файлы;
пересылать сообщения и отвечать на них;
использовать реакции, эмодзи и стикеры;
создавать публичные и приватные группы и каналы;
закреплять важные сообщения;
искать людей, чаты и сообщения;
совершать аудиозвонки;
расшифровывать голосовые сообщения в текст.
Последняя функция особенно интересна для повседневного использования: рядом с кнопкой воспроизведения голосового сообщения появляется возможность получить его текстовую расшифровку. То есть длинное голосовое необязательно прослушивать целиком.
При этом проект пока активно развивается. Например, в последних версиях разработчики отдельно сообщают об исправлениях синхронизации, работе контактов, медиафайлов, звонков и повышении стабильности приложения.
В Google Play приложение опубликовано компанией WB FZE, зарегистрированной в Hamriyah Free Zone в эмирате Шарджа, ОАЭ. На момент проверки там указано 1 тыс.+ скачиваний.
Есть и отдельный момент, на который стоит обратить внимание перед регистрацией: в информации Google Play разработчик указывает, что приложение может собирать фотографии и видео, файлы и документы, а также передавать некоторые категории данных третьим сторонам. При этом передача данных заявлена как шифруемая.
Пока это выглядит скорее как новый игрок на рынке мессенджеров, чем полностью сформировавшаяся альтернатива привычным сервисам. Но наличие чатов, групп, каналов, звонков, поиска, папок и расшифровки голосовых показывает, что Wildberries постепенно собирает полноценную коммуникационную платформу.
☕ JDBC и Spring JDBC — основы работы с БД без абстракций. ☕ JPA и Hibernate — что такое ORM, persistence context и как это работает внутри. ☕ Spring Data JPA vs Spring Data JDBC — различия репозиториев и критерии выбора. ☕ MyBatis и jOOQ — почему выбирают SQL-центричные фреймворки ради полного контроля. ☕ Альтернативные реализации JPA — что кроме Hibernate. ☕ Reactive Data Access — когда нужен R2DBC, а когда достаточно JDBC. ☕ Как выбрать фреймворк — сценарии, компромиссы и рекомендации.
📆 Когда: 31 августа в 16:00 (Мск)
🙍♂ Спикер: Александр Краснянский, эксперт в Java/Kotlin и архитектуре ПО
🫠 Когда база данных начинает хуже справляться с нагрузкой, сначала нужно определить причину снижения производительности, а затем выбирать способ масштабирования.
1️⃣ Сначала измеряйте, потом масштабируйте База обычно деградирует постепенно: растут задержки, время выполнения запросов и очередь. Поэтому важно следить за загрузкой CPU и памяти, дисковой подсистемой, активными соединениями и replication lag. О проблеме может говорить устойчивый рост нагрузки или приближение числа активных соединений к установленному лимиту.
2️⃣ Масштабируйте от простого к сложному Начните с запросов и индексов: корректно подобранный индекс может существенно сократить время выполнения запроса. Дальше — пул соединений и кеширование. Если этого недостаточно, можно увеличить ресурсы сервера и вынести чтение на реплики.
🦾 Шардинг стоит подключать, когда более простые способы исчерпаны: он требует изменения архитектуры и усложняет выполнения JOIN и транзакции между разными шардами.
Управляемая база данных может взять на себя развертывание, резервное копирование, мониторинг, репликацию и автоматическое переключение при сбоях. Оптимизация запросов, схема данных и логика приложения остаются на стороне команды.
Что подтянуть бэкендеру для продакшена: 12 практических открытых уроков
Когда приложение выходит за пределы локальной машины, появляются задачи, которые редко помещаются в документацию одного фреймворка: блокировки, очереди, конкурентность, производительность и отказоустойчивость.
В подборке — бесплатные занятия, где эти проблемы разбирают через реальные инструменты и сценарии, с которыми бэкендер сталкивается в работе.
Очереди и надёжная доставка
26 августа, 20:00. «Работа с Kafka через библиотеку Kafka Clients». Записаться
17 сентября, 20:00. «RabbitMQ в Production: Transactional Outbox, идемпотентность и DLQ в ASP.NET Core». Записаться
Базы данных и конкурентный доступ
1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться
8 сентября, 20:00. «Борьба с блокировками в PostgreSQL: как достичь высокой параллельности при большой нагрузке». Записаться
16 сентября, 20:00. «Темпоральные данные в PostgreSQL 18: история и версии без триггеров». Записаться
Нагрузка и производительность
3 сентября, 20:00. «ASP.NET Core API под нагрузкой: как сделать сервис устойчивым к сбоям и росту трафика». Записаться
9 сентября, 20:00. «Go‑профилирование: как найти и исправить „тормоза“ в продакшене». Записаться
22 сентября, 20:00. «Горутины и каналы: под капотом (under the hood) и нюансы в продакшене». Записаться
HTTP и серверная разработка
21 сентября, 20:00. «HTTP‑сервер на чистой Java за 30 минут». Записаться
20 октября, 19:00. «Балансировка HTTP и L4 сервисов в Angie». Записаться
Продакшен и наблюдаемость
23 сентября, 20:00. «eBPF: рентгеновское зрение для production». Записаться
23 сентября, 20:00. «Узнайте, как использовать Patroni для управления высокодоступными кластерами PostgreSQL». Записаться
ЧТО ПОЧИТАТЬ БЭКЕНД‑РАЗРАБОТЧИКУ
Если удобнее разбираться в теме в своём темпе, собрали несколько практических материалов: про серверы, обновление стека, обработку ошибок и тонкости C++.
Type-driven development в Rust, часть 2/5: как доверить компилятору проверку контрактов между компонентами
Продолжаем серию о type-driven development в Rust — подходе, при котором правила предметной области выражаются в типах, а код, нарушающий эти правила, не компилируется. Рассказывает Никита Тимофеенко, разработчик команды MXDR компании F6.
В первой части типы отвечали за данные: какие значения возможны, какие комбинации допустимы, в каком порядке идут переходы. Но кроме данных в программе есть компоненты, которые общаются между собой, и у каждой такой границы есть контракт. Вторая часть посвящена тому, как записать эти контракты в типах, чтобы их нарушение не компилировалось.
После неё вы сможете найти в своём коде enum с match на каждом вызове, который на самом деле изображает открытый набор реализаций, и заменить его трейтом; отличить в контракте вход от выхода и перестать делать параметром трейта то, что должна выбирать реализация; поднять в тип размеры, которые известны ещё до запуска.
Во второй статье представлены три механизма, каждый разобран по той же схеме «проблема -> решение -> хорошие практики -> как это используют известные крейты или std библиотека»:
traits — контракт вместо конкретной реализации: код-потребитель требует поведение, а не тип, и работает с любым, кто его реализовал; новая реализация — это новый impl, а не правка общего кода;
associated types — типы, которые выбирает реализация, а не вызывающий: у каждой реализации свои типы результата и ошибки, и в один общий тип они не сводятся. Разница между параметром трейта и ассоциированным типом — это разница между входом и выходом;
const generics — значение как параметр типа: размер известен компилятору, а не хранится в рантайме, и структуры разного размера — разные типы. Что можно и чего нельзя в const-параметрах на стабильном Rust.
Отдельно рассмотрим CGP (Context-Generic Programming): что делать, когда одному типу нужно несколько реализаций одного трейта, а правило когерентности разрешает одну — и как одна и та же логика собирается под разные контексты без dyn и без match.
Примеры — из биржевой торговли, как и во всей серии, но приёмы работают в любом домене со сложными состояниями и правилами их изменения. Словарь типов продолжает часть 1.
Вторая статья «Type-driven development в Rust. Часть 2/5: задаём контракты между компонентами»уже на GitHub. Там же — компилируемые примеры ко всем приёмам, включая compile_fail-тесты на каждое «это не скомпилируется» из текста.
Ну короче… Есть такая естественное событие как расширение вселенной и что нам известно о нём? Мы знаем, что вселенная расширяется, то есть галактики разлетаются по закону Хаббла, причём это расширение ускоряется под действием загадочной тёмной энергии, и всё это началось около 13,8 миллиардов лет назад с Большого взрыва. Как там говорили… Нуу чем дальше галактика тем он быстрее? Значит через какое-то время или расстояние, галактики начнут отдалятся многократно быстрее чем скорость света, насколько я знаю галактики, находящиеся за пределами сферы Хаббла, прямо сейчас удаляются от нас быстрее скорости света, но важное замечание: расширяется пространство, то есть расширение идёт не в пространстве, а само пространство расширяется, как мы знаем оно не зависит от скорости света и прочего. Но вот почему нам говорят что расширение идёт со скоростью света, но не уточняют что именно расширяется? Мне кажется из-за этого появляется неправильное представление вообще о вселенной. По мнению научпоп авторов, расширение идёт со скоростью света, но если расширяется само пространство и по закону Хаббла “Чем дальше галактика — тем быстрее он убегает” значит будет момент когда галактика будет убегать выше скорости света в 4-5 раз или даже в 10 раз, и скорость света это предел скорости изображения которое до нас доходит, но теперь вопрос: Куда расширяется пространство? Есть три научных гипотезы (математический, геометрический и физический)
Математика(ОТО): Расширение — рост масштабного фактора a(t) в метрике Фридмана‑Робертсона‑Уокера. Пространство не движется, меняются только коэффициенты расстояний. Пример: бесконечная числовая прямая, все координаты умножили на 2 — прямая та же, но числа разъехались.
Замкнутая Вселенная, то есть геометрическая версия гипотезы: вселенная как поверхность шара, то есть расширение = увеличение радиуса, при этом меняется кривизна и внешнее 4‑е измерение не нужно — всё описывается внутренней геометрией.
Гипотеза физиков: Наблюдения за CMB говорят о плоской геометрии, скорее всего бесконечной. Расширение означает разрежение: плотность падает, расстояния между галактиками растут. Краёв нет, новые участки не появляются — просто метрика меняется.
И я тут заметил одну интересную деталь, для человека который не очень-то разбирается в астрофизике, кажется что эти теории противоречят другим теориям(теория большого взрыва, инфляция, ОТО и т.д.)… Оно не просто не конфликтует, а является одним из классических решений уравнений Эйнштейна, лежащих в основе теории Большого взрыва, по факту они существуют в полной гармонии! Ну если разбирать это и дальше, то выйдет статья как минимум на 2 часа, а это вообще задумывалось как пост размышлений…
Бесплатный доступ к Claude Code и Codex через 50 AI-провайдеров
Появился интересный Open Source-проект Free Claude Code, который объединяет десятки AI-провайдеров в одном интерфейсе и позволяет подключать их к популярным агентам для программирования.
Проект поддерживает 50 провайдеров и заявляет о более чем 1,3 млрд бесплатных токенов в месяц. При этом доступность бесплатных лимитов зависит от конкретного провайдера и может меняться.
Через него можно запускать сразу несколько coding-агентов:
Claude Code
Codex
Pi
OpenCode
Cline
Hermes
DeepSeek Harness
Grok Build
Muse Code
То есть вместо постоянного переключения между разными сервисами можно использовать единый слой маршрутизации и выбирать подходящую модель из общего каталога.
Что умеет Free Claude Code
🔄 Автоматический fallback. Если выбранный провайдер не отвечает после повторных попыток, система может переключиться на следующую настроенную модель.
💰 Экономия токенов. В проект интегрированы оптимизации, а дополнительный RTK-фильтр может сокращать объём токенов, расходуемых на вывод команд терминала, — разработчики заявляют до 90% сокращения в соответствующих сценариях.
💻 Несколько способов работы. Инструмент рассчитан на терминал, десктоп, IDE и даже смартфон. Есть интеграции с VS Code, JetBrains, Discord и Telegram.
🎙 Голосовой ввод. Запросы агенту можно отправлять голосом через локальную транскрипцию Whisper или NVIDIA NIM.
🧩 Инструменты остаются доступными. Поддерживаются tools, потоковая генерация, отправка изображений и другие возможности AI-агентов.
Отдельно интересен Hermes — его можно запускать через ту же инфраструктуру, не ограничиваясь только Claude Code или Codex.
При этом есть важный нюанс: проект не связан с Anthropic, а бесплатные лимиты предоставляются сторонними провайдерами и могут изменяться. Поэтому воспринимать заявленный объём токенов как гарантированный лимит не стоит.
Godogen превращает Claude Code и Codex в автономных разработчиков игр
Вайбкодинг выходит за пределы обычных приложений. Godogen позволяет поручить AI-агенту создание полноценной игры: от написания кода до генерации ассетов, запуска движка и проверки готового результата. Проект работает с Godot 4, Bevy и Babylon.js, а в качестве агента можно выбрать Claude Code или Codex.
Главная идея в том, что разработчику достаточно описать, какую игру он хочет получить. Дальше агент самостоятельно собирает проект, пишет необходимые скрипты, создаёт сцены и запускает игру.
Причём Godogen не ограничивается проверкой успешной компиляции. Он оценивает именно работу запущенной игры: смотрит live-версию или записанный геймплей, замечает видимые проблемы и использует их для следующей итерации.
AI сам создаёт игровые ассеты
Отдельный интерес представляет генерация контента. В проект встроен пайплайн для создания:
персонажей и референсов;
текстур;
простых 3D-объектов;
3D-моделей и риггинга;
анимированных спрайтов.
Для разных задач используются Gemini, Grok и Tripo3D.
При этом Godogen не является отдельным игровым движком. Это скорее генератор игровых проектов, который подготавливает окружение, после чего AI-агент работает непосредственно внутри созданного репозитория.
Есть и режим практически автономной разработки. Если не вмешиваться в процесс, в конце агент может подготовить 15–20-секундную запись геймплея, демонстрирующую результат.
Для запуска потребуются соответствующие SDK и инструменты движка, Python, а для генерации ассетов — API-ключи используемых сервисов. Полный список требований разработчики разместили в репозитории Godogen на GitHub.
Похоже, следующий этап вайбкодинга — это уже не «напиши мне функцию», а «сделай мне игру и покажи, что она действительно работает».
NVIDIA показала голосовой AI, который умеет слушать и отвечать одновременно
NVIDIA представила NemotronLabs VoiceChat — голосовую модель для диалогов в реальном времени. В отличие от классической связки ASR → LLM → TTS, здесь понимание речи и её генерация объединены в одной архитектуре.
Главная особенность — полный дуплекс. Пользователь может перебить агента прямо во время ответа, а система продолжит разговор без переключения в отдельный режим. Модель также умеет вызывать инструменты прямо в процессе диалога — например, запрашивать данные из внешнего сервиса.
За обработку аудио отвечает Conformer-модуль, после чего аудиоток поступает в NVIDIA Nemotron Nano 9B v2. Отдельный канал используется для генерации сценариев вызова инструментов, а TTS-декодер превращает результат обратно в речь.
При этом проект пока рассчитан скорее на разработчиков: для запуска требуется NVIDIA GPU минимум с 80 ГБ видеопамяти. Выпущенная версия использует один фиксированный голос и не поддерживает клонирование голоса.
Qwen 3.8 27B за 30 минут обошла защиту коммерческого приложения
Локальная модель Qwen 3.8 27B справилась с задачей, для которой еще недавно потребовалась бы одна из самых мощных облачных моделей. Она провела реверс-инжиниринг системы лицензирования коммерческого приложения и создала рабочий proof-of-concept обхода — причем полностью офлайн.
Эксперимент провел технический редактор XDA Адам Конвей. Подробности он описал в своем разборе эксперимента.
Все происходило на одной машине
Qwen 3.8 27B запустили на Lenovo ThinkStation PGX с чипом Nvidia GB10 Grace Blackwell и 128 ГБ объединенной памяти. Модель работала локально и не использовала облачные API.
Особенно показательно другое: во время основного анализа приложение вообще не запускалось. Qwen работала с бинарными данными и использовала статический анализ.
Модель:
разобрала ARM64-код;
сопоставила функции безопасности с их вызовами;
исследовала механизм проверки лицензии;
обнаружила спрятанный внутри бинарника публичный ключ;
восстановила структуру системы лицензирования;
в конечном итоге подготовила рабочий обход проверки.
На весь процесс ушло около 30 минут.
Сначала Qwen отказалась
Экспериментатор попытался представить себя разработчиком приложения и использовал jailbreak-промпт, чтобы заставить модель обойти ограничения.
Qwen не только отказалась следовать такой инструкции, но и самостоятельно проверила сертификат подписи приложения. Модель правильно определила настоящего разработчика и заявила, что готова провести аудит безопасности, но не станет создавать рабочий обход лицензии.
На этом, однако, эксперимент не закончился.
Во время анализа модель самостоятельно дошла до устройства механизма защиты и в итоге все же создала рабочий proof-of-concept обхода.
Самое интересное — модель исправила собственную ошибку
Первоначально Qwen неправильно восстановила криптографический ключ.
Проблема обнаружилась не сразу: проверка подписи проходила успешно, однако дополнительная проверка целостности выдавала несовпадение.
Модель заметила противоречие, вернулась к предыдущим этапам анализа и продолжила поиск ошибки. После нескольких итераций восстановленное значение стало совпадать побитно.
И только после этого Qwen получила корректный результат и смогла продемонстрировать работоспособность обхода.
Почему это важно для кибербезопасности
Здесь интересен не столько сам факт обхода лицензии, сколько масштабирование возможностей реверс-инжиниринга.
Раньше подобная работа ассоциировалась с опытным специалистом, специализированными инструментами и значительным количеством ручного анализа. Теперь часть этого процесса способен выполнить локальный ИИ-модельный агент.
Причем локальный запуск дает одновременно два противоположных преимущества.
Для специалистов по безопасности это означает возможность анализировать закрытое ПО, бинарники и чувствительные данные без отправки информации в облако.
Но для злоумышленников действует тот же принцип: модель не требует внешнего API, не передает исследуемый бинарник стороннему сервису и может работать полностью автономно.
Именно поэтому локальные модели вроде Qwen 3.8 27B уже становятся отдельным фактором, который разработчикам стоит учитывать при построении моделей угроз для коммерческого ПО.
Главный вывод эксперимента довольно простой: способности, которые еще недавно связывали с frontier-моделями, постепенно перемещаются на локальные машины. И вместе с преимуществами приватного AI разработчикам приходится учитывать новые сценарии атак на программное обеспечение.
Одетые в кроссовки и футболки миллиардеры — это лишь часть образа нестяжателя у основателя очередного сервиса социальных сетей или корпорации-разработчика SaaS. На самом деле главы технологических гигантов не отказывают себе в роскоши. К примеру, в июне на мероприятии UFC Freedom 250 на запястье главы Meta* Марка Цукерберга увидели экземпляр часов F.P. Journe Tourbillon Souverain Cœur de Rubis за $1,3 млн. Этой модели было произведено всего 20 штук.
Причём часами Цукерберг увлёкся сравнительно недавно. В марте 2024 года на предсвадебной вечеринке Ананта Амбани миллиардер разглядывал Richard Mille на руке наследника Reliance Industries и признался: «Знаете, я никогда особо не хотел часы. Но когда увидел эти, подумал: часы — это круто». С тех пор коллекция Марка успела заметно разрастись.
Ничем не хуже Сэм Альтман, руководитель OpenAI. Как сообщает Wall Street Journal, в начале этого года он заказал у швейцарской Vanguart 7 часов с символикой OpenAI. Их сделали на базе титановой модели Orb, стоимость которой начинается со $180 тысяч. Часы предназначались неким избранным сотрудникам компании. Даже если допустить, что один экземпляр Альтман оставил себе, кто именно получил остальные шесть, издание не уточняет.
Также неясна точная цена заказа Альтмана. WSJ не сообщает ни фактическую стоимость, ни то, кто за него заплатил, хотя умножение стартовой цены Orb на число заказанных часов даёт $1,26 млн. Но это явно меньше даже одной стойки GB200 NVL72 видеоускорителей Nvidia, стоимость которой составляет около $3 млн.
Сами часы вполне соответствуют заказчику. На роторе выгравирована приписываемая Альтману фраза «COMPUTE IS DESTINY», на кнопке заводной головки — «SCALING», а на задней крышке красуется if AGI.aligned: deploy(). Разумеется, не обошлось без логотипа OpenAI. Идею с кодом предложил сооснователь и гендиректор Vanguart Аксель Лойенбергер, но вообще всё лежит на поверхности и подчёркивает проблемы OpenAI: выравнивание моделей, масштабирование инфраструктуры, поиск вычислительных мощностей для запуска моделей. Вполне возможно, что уже через годик подобное будет выглядеть анахронизмом.
По словам председателя и сооснователя Vanguart Мехмета Корутюрка, над семью часами работала примерно треть из 33 сотрудников компании. За все восемь лет существования Vanguart выпустила менее 200 часов.
В той же статье WSJ приводит и пример более пролетарского корпоративного мерча. Сотрудница Adobe вместе с британской Studio Underd0g готовит партию из 128 часов с символикой компании примерно по $1200 за штуку. Понятно, что это просто часы для рядовых сотрудников. До семи магических часов властителей гномов Альтмана или часов всевластья Цукерберга им далеко.
Как к этому заказу относиться, лучше всего выразил Стивен Синофски. Бывший президент отдела Windows в очередной раз повторил известную байку своей ранней карьеры. В 1991 году молодой Синофски, на тот момент повышенный до проджект-лида, решил заказать футболки для 7 членов своей небольшой команды. Заказ был оформлен без предварительного согласования, Стивен выдал за партию $450 из своего кармана. Когда футболки привезли, его руководитель первым делом спросил: «Кто за это заплатил?» Услышав «я», он улыбнулся и сказал: «Правильный ответ». Спустя несколько недель Microsoft всё же возместила Синофски расходы.
Деятельность экстремистской организации Meta (*) запрещена.
Привет! Заметка о правильности названий ETL процессов.Расставим точки над i. Всегда было же нормально, коротко и звучно ETL. Теперь все чаще мелькает ELT, ETLT, EtLT.
Традиционный паттерн ETL, применяет бизнес-логику во время преобразования, до загрузки в хранилище. Выбрал данные, преобразовал, положил в хранилище. ELT меняет эту последовательность, сначала загружая сырые данные в хранилище, а преобразование выполняет уже внутри. ELT подход сокращает нагрузку на систему источник, позволяет итеративно совершенствовать логику преобразования.
Имеем два противоположных метода.
Но мы то с вами знаем, что на проектах, в жизни оба метода применяются одновременно. Более того, они могут одновременно применяться в одном потоке. Выбрал данные, преобразовал, положил в хранилище на первый уровень, преобразовал и положил на второй уровень.
Например, в потоке выполняется экстракция из базы данных, непосредственно при выборке происходят предварительные преобразования (очистка, изменение типов), далее загрузка в цель - выполнился процесс ETL. Вторым этапом идут бизнес преобразования - процесс T, а вместе ETLT.
Таким образом и получается, что в большинстве случаев используется процесс ETLT, но исторически так сложилось называть все подобные процесcы просто и звучно ETL. В аббревиатуре первая трансформация обозначается маленькой первой буквой t, и это не случайно. На данном шаге выполняются только предварительные преобразования данных: очистка, приведение типов. А вот уже вторая - это полноценная трансформация: бизнес преобразования, обогащения, расчеты и тд. Еще я встречал проставление индексов к буквам трансформаций ET1LT2.
Так же есть такое понятие как ETL++, но об этом в другой раз :-)
ChatGPT теперь умеет генерировать PNG-изображения, которые можно использовать как стикеры для мессенджеров. Для собственного набора не нужно вручную рисовать каждую картинку — достаточно задать идею и при желании загрузить свои фотографии.
Автор блога!
Как сделать свой стикер-пак
В ChatGPT откройте раздел «Изображения», выберите режим «Стикеры» и напишите, каким должен быть набор. Можно указать стиль, эмоции, количество персонажей, оформление и другие детали.
Ещё интереснее то, что в качестве основы можно добавить собственные фотографии. Например, загрузить снимок человека или питомца и попросить сделать из него набор реакций: смех, шок, злость, удивление, сарказм или недоумение.
После генерации останется небольшая ручная работа: если ChatGPT создаёт несколько стикеров на одном изображении, готовую сетку нужно разрезать на отдельные PNG-файлы, а затем загрузить их в Telegram.
Получается довольно простой конвейер: фотография → промпт → генерация → нарезка → готовый стикер-пак. А дальше всё ограничивается только фантазией — от мемов с друзьями до собственного набора реакций для канала.
ИИ-агенты уже создают непропорционально большую нагрузку на ИИ-модели и расходуют почти в пять раз больше токенов, чем запросы людей, а с февраля 2026 года их потребление выросло примерно в 14 раз.
Compact OS в Windows: как освободить место без удаления файлов
Если системный SSD почти заполнен, не обязательно сразу удалять программы, игры или личные данные. В Windows есть встроенный механизм Compact OS, который сжимает системные файлы и помогает освободить несколько гигабайт.
Функция появилась в Windows 10 и поддерживается в Windows 11. Отдельного переключателя в настройках нет: управлять Compact OS нужно через команду Compact.exe.
Как работает Compact OS
Windows хранит часть системных файлов в сжатом виде, а при обращении распаковывает их на лету. Компоненты ОС при этом не удаляются и не отключаются.
Технология поддерживается на компьютерах с UEFI и классическим BIOS. Windows Update также умеет обслуживать сжатую установку: заменять и удалять необходимые файлы без постоянного увеличения её размера.
Главный компромисс — дополнительная нагрузка на процессор. Сжатые данные приходится распаковывать, поэтому на современном ПК влияние обычно минимально, а на старом или маломощном компьютере оно может быть заметнее.
Как проверить и включить функцию
Откройте командную строку от имени администратора и выполните:
Compact.exe /CompactOS:query
Команда покажет, используется ли Compact OS сейчас.
Для включения сжатия:
Compact.exe /CompactOS:always
Чтобы вернуть обычное состояние:
Compact.exe /CompactOS:never
Операция может занять некоторое время: Windows должна обработать системные файлы. Перед началом желательно создать резервную копию важных данных и убедиться, что компьютер подключён к питанию.
Сколько места можно освободить
Точный результат зависит от версии Windows и конфигурации системы. В документации Microsoft для 64-разрядной Windows 10 версии 1607 приведён пример установки объёмом 15,06 ГБ. После применения Compact OS размер уменьшался до 11,3 ГБ — экономия составляла более 3,7 ГБ.
При дополнительном single-instancing объём снижался до 10,09 ГБ, а суммарная экономия превышала 4,75 ГБ.
Это ориентиры, а не гарантия для любого компьютера. На Windows 11 результат может быть другим.
Когда Compact OS имеет смысл
Функция пригодится, если:
системный SSD небольшой;
раздел почти заполнен;
удалять приложения и пользовательские файлы не хочется;
нужно освободить несколько гигабайт именно за счёт компонентов Windows.
На компьютере с SSD на 1–2 ТБ польза обычно ограничена: несколько гигабайт редко решают проблему нехватки места.
Важно помнить, что Compact OS сжимает только системные файлы. Место также занимают:
Pagefile.sys и Hiberfil.sys;
обновления Windows;
точки восстановления;
журналы и кэши;
языковые пакеты;
компоненты Windows;
приложения и временные файлы.
Поэтому сначала стоит проверить, что именно заполняет диск. Иногда больше места удаётся вернуть очисткой временных файлов, удалением старых обновлений или отключением гибернации.
Итог
Compact OS — штатный способ уменьшить размер Windows без удаления системных компонентов. Он особенно полезен на устройствах с небольшими накопителями, но не является универсальным решением проблемы нехватки места.
Если свободного пространства критически мало, можно начать с проверки:
Compact.exe /CompactOS:query
А затем, при необходимости, включить режим:
Compact.exe /CompactOS:always
Подробные ограничения и таблицы с результатами измерений опубликованы в документации Microsoft.
Специалистам по информационной безопасности приходится работать с огромным количеством данных: логами, алертами систем мониторинга, обращениями пользователей. Среди них могут скрываться признаки атаки — вручную разбирать такой объем информации сложно.
Часть этой работы можно ускорить с помощью ИИ. Вместе с Евгением, специалистом по безопасности приложений в Naumen, разобрали, где ИИ действительно полезен и какие ограничения важно учитывать.
1️⃣ Как ИИ помогает разбирать инциденты?
После обнаружения инцидента нужно собрать информацию из разных источников, найти связи между событиями и восстановить их последовательность.
ИИ может проанализировать логи и другие данные и собрать их в понятную картину.
Например, пользователь получил подозрительное письмо, перешел по ссылке, установил ПО, после чего в системе появился подозрительный процесс.
2️⃣ Как ИИ помогает проверять защищенность приложений?
ИИ может анализировать структуру приложения, подсказывать наиболее вероятные точки входа и обращать внимание на потенциально опасные участки.
Еще один сценарий — помогать генерировать полезные нагрузки для проверки уязвимостей, в том числе с учетом конкретных механизмов защиты. А после тестирования — быстрее подготовить итоговый отчет.
3️⃣ Может ли ИИ находить уязвимости еще на этапе разработки?
Да. Современные модели умеют находить типовые веб‑уязвимости — например, SQL‑инъекции, XSS и CSRF, — участвовать в ревью кода и объяснять, почему выбранный подход может быть опасен.
Еще ИИ может переводить технические отчеты сканеров уязвимостей на более понятный язык, давать рекомендации и помогать приоритизировать проблемы.
4️⃣ Где еще он может пригодиться?
Например, в обучении сотрудников. С помощью ИИ можно создавать реалистичные сценарии фишинговых атак и учебные кейсы, формировать индивидуальные траектории обучения или переводить ГОСТы, ISO и внутренние регламенты на более понятный язык.
5️⃣ Какие ограничения важно учитывать?
Код, написанный с помощью ИИ, сам может содержать проблемы безопасности, поэтому его нельзя принимать без ревью.
Отдельный вопрос — работа с чувствительными данными. Для таких сценариев разумнее использовать локальные модели без доступа в интернет.
Кроме того, сама модель может стать целью атаки. Поэтому при внедрении ИИ важно продумывать, какие данные доступны модели, как она взаимодействует с внешними сервисами и как проверяются результаты ее работы.
→ Подробнее своим опытом Евгений поделился в статье.