Это разворот истории двухнедельной давности. 24 августа X Corp разослала претензии с требованием навсегда закрыть инстансы Nitter и сам репозиторий проекта. Тогда nitter.net ушёл в офлайн, разработка остановилась, а автор написал, что ищет юридической помощи и не будет комментировать детали, поблагодарив всех, кто пользовался, хостил, паковал и поддерживал проект семь лет.

• Nitter не закрывается: решение принято после консультации с юристами, детали не раскрыты.
• nitter.net и другие инстансы обещают поднять «в ближайшее время», официальный анонс в течение недели.
• Претензии X Corp от 24 августа требовали удалить и инстансы, и репозиторий на GitHub; репозиторий остался на месте.
• Инстанс xcancel.com, по данным обсуждения на Hacker News, возобновил работу.
• Nitter проксирует все запросы через свой бэкенд: клиент не обращается к X напрямую, поэтому X не видит его IP и отпечаток браузера.

Что известно о причинах разворота

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

Nitter вдохновлён Invidious, альтернативным интерфейсом YouTube. По README, запросы к X проходят через сервер инстанса, а браузер читателя не обращается к X напрямую. Это не даёт X получить IP-адрес читателя через прямое соединение и JavaScript-отпечаток из интерфейса Nitter. При этом читатель всё равно подключается к выбранному серверу Nitter. Описание архитектуры не следует понимать как обещание анонимности перед владельцем этого сервера.

Что это значит для тех, кто читает X через Nitter

README указывает, что Nitter использует неофициальный API X и не требует аккаунта разработчика. Работа фронтенда зависит от ответов платформы, а работа конкретного сайта ещё и от его конфигурации. Требования X Corp от 24 августа касались как инстансов, так и репозитория. Источники не устанавливают, были ли это первые юридические претензии такого рода, и не дают основания объявлять конфликт завершённым.

Для собственного инстанса README описывает сборку на Nim и образ zedeus/nitter. Нужны библиотеки libpcre, libsass и Redis либо Valkey для кеширования. Параметры задаются в nitter.conf; для Docker Compose документация также описывает подключение sessions.jsonl. Перед возобновлением публичного сервиса стоит прочитать обещанное автором объяснение юридической ситуации.

Сообщение на nitter.net обещает возвращение сервиса, но само по себе не подтверждает доступность всех страниц. Обсуждение на Hacker News содержит сообщения о работе xcancel.com; это наблюдение участников, которое не описывает весь набор инстансов. У пользователя могут отдельно работать чтение профиля и не работать RSS. Проверять следует нужную операцию на выбранном сервере.

RSS доступен на инстансах, где владелец включил эту функцию. README прямо предупреждает, что её часто отключают из-за злоупотреблений. Возвращение веб-интерфейса поэтому не гарантирует восстановления подписок в RSS-читалке. Старые ссылки на профиль зависят от доступности указанного в них домена, а состояние RSS дополнительно зависит от настроек сервера.

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

В инструкции для хостеров есть отдельная оговорка о контейнерах: файлы конфигурации нужно создать до запуска. Если подключаемого файла нет, Docker может создать вместо него каталог, после чего контейнер завершится с ошибкой типа пути. Это относится к nitter.conf и, в примере Docker Compose, к sessions.jsonl. Поэтому ошибка запуска после восстановления инстанса может быть локальной проблемой конфигурации; её нельзя автоматически приписывать новому ограничению X.

README рекомендует запускать Nitter за обратным прокси, например Nginx или Apache. В nitter.conf задаются имя хоста, порт, HMAC-ключ, настройки HTTPS и кеша. Для диагностики документация предлагает смотреть стандартный вывод через журнал systemd либо логи контейнера. Эти инструкции остаются в репозитории, но их наличие не подтверждает, что любой вновь поднятый публичный сервер уже защищён от юридических требований.

Какие возможности уже есть и чего ждать дальше?

В README перечислены темы оформления, адаптивный интерфейс для мобильных экранов и лицензия AGPLv3. Отдельно в планах стоят система аккаунтов с хронологической лентой и архивирование постов и профилей. Их не следует считать уже доступными функциями возвращающегося сайта. В ближайшем анонсе стоит искать условия продолжения работы, а доступность нужного инстанса проверять отдельно. О другой истории с ограничениями платформ мы писали после удаления uBlock Origin из Chrome Web Store.

Источники: Репозиторий zedeus/nitter на GitHub, README, nitter.net: Cease and desist – UPDATE Sep 7th, Обсуждение на Hacker News: Nitter and XCancel resume service after legal advice

Изображение на обложке: Скриншот: Nitter

Но при этом к такому коду часто боятся прикасаться. И не без причины. В старых системах редко бывает понятная карта зависимостей. Документация устарела, часть знаний живет только в головах нескольких разработчиков, а бизнес при этом продолжает ждать новых релизов, интеграций и продуктовых экспериментов.

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

Проблема не в самой идее переписывания, а в условиях, при которых оно проваливается. Большой риск возникает, когда совпадают четыре фактора: переписывание занимает много месяцев, в это время бизнес продолжает развивать старую систему, новая версия покрывает сразу большую часть функциональности, а откат связан с миграцией данных. Если все четыре пункта присутствуют, Big Bang почти гарантированно превратится в долгий и дорогой проект.

Допустим, команда решила переписать модуль заказов в e-commerce-продукте. В старой версии есть корзина, промокоды, доставка и оплата. Команда планирует за полгода сделать новый сервис заказов. Но за эти полгода бизнес добавляет подписки, подарочные сертификаты, частичную оплату бонусами и новую логику возвратов. В итоге новая система, которую проектировали под старые требования, к моменту релиза уже нуждается в доработке.

Есть и другая проблема: большой релиз почти всегда несет максимальный риск. Если вы заменяете крупный кусок системы целиком, ошибка влияет сразу на большую часть пользователей. Откат тоже становится сложным, потому что новая логика уже связана с новыми данными, контрактами и интеграциями.

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

Через восемь месяцев проект всё ещё не был готов к выкатке, а к десятому месяцу команда откатила миграцию полностью. Причин было несколько.

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

Во-вторых, команда не написала характеристических тестов. Поведение «как есть» нигде не было зафиксировано, и расхождения находились только в продакшене после переключения.

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

В итоге миграцию свернули, потратив около десяти человеко-месяцев и потеряв доверие бизнеса. Сервис до сих пор работает в исходной реализации, а команда переходит к плану, описанному ниже.

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

Представим старый монолит интернет-магазина. Внутри него есть каталог, корзина, заказы, платежи, скидки, личный кабинет и уведомления. Переписать всё сразу — рискованно. Но можно начать с относительно изолированного участка, например с уведомлений.

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

Такой подход снижает риск. В системе нет одного большого релиза, где всё меняется сразу. Есть серия небольших контролируемых изменений. Каждое можно протестировать, измерить и откатить.

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

Это опасный путь. В legacy-системах странное поведение часто существует не случайно. За ним может стоять неочевидное бизнес-правило, старый клиент, интеграция с внешней системой или исторический баг, на который уже кто-то завязался.

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

Поэтому первый этап модернизации — не улучшение, а воспроизведение текущего поведения. Новая реализация должна вести себя так же, как старая. Даже если старое поведение кажется странным. Только после стабилизации можно отдельно обсуждать, что именно стоит менять.

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

user_id передается явно, чтобы решение «попал ли пользователь в новый сегмент» было стабильным от запроса к запросу. Иначе один и тот же клиент будет получать разные ответы при обновлении страницы, и поведение системы станет непредсказуемым.

На первом этапе флаг включают только для внутренней команды. Потом для тестового сегмента пользователей. Затем для небольшой доли реального трафика. Если метрики стабильны, долю увеличивают. Если появляются ошибки, флаг выключают, и пользователи снова идут в старую реализацию.

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

Важно, что фича-флаг — это не просто if в коде. Для серьезной миграции нужны правила: кто может включать флаг, как быстро его можно отключить, какие метрики отслеживаются, когда флаг должен быть удален.

Последний пункт особенно важен. Если флаги не удалять, система быстро превращается в набор ветвлений, где никто уже не понимает, какая логика актуальна.

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

Например, есть старый модуль расчета скидок. Он учитывает промокоды, сегмент пользователя, историю покупок, регион и партнерские условия. Команда пишет новый сервис скидок. Чтобы не переключать пользователей сразу, можно запустить теневой режим:

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

Для критичной доменной логики — платежей, биллинга, расчета тарифов — допустимый уровень расхождения должен быть около нуля: цель в shadow-режиме не «как можно меньше различий», а «понимаем каждое расхождение». Для менее чувствительных доменов (рекомендации, ранжирование результатов поиска) можно жить с расхождением в долях процента, но и там расхождения нужно классифицировать, а не игнорировать. Возможно, это баги новой реализации. А возможно, старая система содержит устаревшую логику, которую нужно отдельно обсудить с бизнесом.

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

Начинать лучше не с самого больного и не с самого центрального модуля. Это звучит контринтуитивно, потому что обычно хочется сразу взяться за главный источник проблем. Но если начать с ядра системы, команда быстро упрется в максимальное количество зависимостей и рисков.

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

Допустим, в банковском приложении есть старый модуль истории операций. Он медленный, сложно расширяется, но при этом не выполняет сами транзакции. Это хороший кандидат для первой миграции. Ошибка в истории операций неприятна, но обычно менее критична, чем ошибка в списании денег.

Команда может вынести чтение истории в отдельный сервис, сначала запустить его в shadow-режиме, потом включить для части пользователей, затем полностью перевести чтение на новую реализацию. При этом критичная транзакционная логика останется в старой системе до тех пор, пока команда не наберет опыт безопасной миграции.

Миграция данных: самая сложная часть

Большая часть статьи говорит о маршрутизации запросов и переключении трафика. Но в реальных проектах основная сложность лежит ниже — в данных. Старая и новая реализации почти всегда работают с общим состоянием: одной БД, одним хранилищем документов, одним набором очередей. Переехать туда «одним коммитом» нельзя.

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

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

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

Сначала команда выбирает ограниченный участок системы. На этом этапе важно не просто назвать модуль, а описать его границы. Какие сценарии он закрывает? Кто его вызывает? Какие данные он читает и пишет? Какие внешние интеграции использует? Какие неочевидные бизнес-правила в нем есть?

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

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

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

Обратимые с компенсацией. Новая реализация пишет дополнительные данные (например, дублирует операции в новую таблицу), но старый источник тоже обновляется. Откат возможен, но требует решить, что делать с уже записанными данными: оставить, очистить, синхронизировать. План этих действий должен быть написан до выкатки, не во время инцидента.

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

Через два месяца чтение полностью перешло в новый сервис. Старый код чтения и фича-флаг удалили в том же релизе. После этого по той же схеме мигрировали запись документов, потом публикацию событий, потом импорт из внешних систем. Полная миграция заняла девять месяцев — почти столько же, сколько провалившийся Big Bang, — но продукт всё это время продолжал развиваться, инцидентов не было, и в конце команда осталась с системой, которую понимает.

Типичные ошибки при работе с legacy

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

Вторая ошибка — недооценивать скрытые зависимости и побочные эффекты. Legacy-код часто делает больше, чем кажется. На один и тот же вызов могут быть навешаны: запись в таблицу аудита, инкремент счётчика в кэше, публикация события в очередь, обновление статуса связанной сущности, инвалидация кэша, дёрганье webhook’а во внешнюю систему. Если в новой реализации воспроизвести только явный путь, скрытые потребители молча перестанут получать данные — и узнают об этом через жалобу бизнеса, а не через ошибку в логах. Поэтому перед выносом любого модуля имеет смысл составить инвентаризацию побочных эффектов: пройтись по коду и логам и выписать каждое нелогичное действие отдельным пунктом чек-листа.

Третья ошибка — отсутствие наблюдаемости. Без логов, метрик и трассировки команда не управляет миграцией, а угадывает. Особенно опасно смотреть только на технические ошибки и игнорировать бизнес-показатели.

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

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

Отдельно стоит упомянуть организационную сторону. Закон Конвея работает и в обратную сторону: если новый и старый код владеются разными командами с разными приоритетами, миграция будет тормозиться независимо от выбранного паттерна. На время миграции имеет смысл явно проговорить, кто отвечает за переход, и не разделять старую и новую реализации между несовместимыми roadmap’ами.

Компромиссы, к которым нужно быть готовыми

Постепенная модернизация безопаснее Big Bang-переписывания, но она не бесплатна. Некоторое время система будет сложнее, чем раньше. В ней появятся старый и новый код, прокси-слой, фича-флаги, дублирование логики, дополнительные метрики.

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

Но это контролируемая сложность. Она распределена во времени и управляется инженерными практиками. В отличие от Big Bang-риска, где команда долго работает с минимальной обратной связью, а потом выкатывает один большой релиз с максимальной неопределенностью.

Когда Strangler Fig особенно оправдан

Постепенная миграция особенно хорошо подходит для систем, где downtime невозможен или слишком дорог. Это финтех, e-commerce, биллинг, мобильные бэкенды с большой аудиторией, высоконагруженные продукты, старые монолиты и системы с большим количеством интеграций.

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

Этот подход также полезен там, где бизнес продолжает активно развивать продукт. Если фичи нельзя заморозить на полгода, модернизация должна идти параллельно с продуктовой разработкой.

Когда модернизацию лучше не делать

Постепенная миграция — мощный инструмент, но у неё тоже есть стоимость, и иногда правильный ответ — оставить систему как есть. Несколько сценариев, в которых модернизация плохо окупается.

Продукт, который уходит из эксплуатации. Если через год сервис будет выключен или заменён на покупное решение, тратить квартал на его рефакторинг бессмысленно. Достаточно стабилизировать то, что есть.

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

В новой работе они предложили «компьютерный тест Тьюринга», который позволяет определять ИИ не по содержанию сообщений, а по отсутствию токсичности и спонтанных эмоций.

Слишком вежлив, чтобы быть человеком

Ученые проверили 9 крупных языковых моделей, включая Mistral 7B, Qwen 2.5 и Gemma 3, заставив их отвечать на реальные посты из Twitter/X, Reddit и Bluesky.

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

Автоматические классификаторы смогли распознать ИИ-ответы с точностью до 80%, даже после попыток оптимизации. Главный показатель — низкий уровень токсичности. Модели элементарно не умеют естественно «хамить» или спорить, как реальные люди в интернете.

Вежливость — враг реализма

Интересно, что обученные на специальных инструкциях модели оказались хуже в имитации человека, чем их «сырые» версии. Чем больше модель старалась быть полезной и корректной, тем легче было понять, что перед вами не человек.

Более того, увеличение размера модели не помогло — 70-миллиардная Llama 3.1 обманывала алгоритмы хуже, чем маленькие версии на 8 млрд параметров.

Новый «тест Тьюринга»

Ученые называют метод computational Turing test — это автоматизированный способ измерить «человечность» текста.

Иронично, что ИИ пока не научился вести себя по-человечески именно потому, что люди не всегда ведут себя корректно и красиво. Живой язык в интернете — это сарказм, агрессия, скука и противоречия.

А значит, чтобы пройти новый «тест Тьюринга», машинам, возможно, тоже придется научиться хамить.

Я подал заявки на 1 084 209 вакансий. Из них 784 555 меня просто проигнорировали, около 300 000 прислали отказ. Мне ответили всего 2022 работодателя и лишь три сделали предложение. Я принял одно. Мы пропали.

По его словам, нейросети помогали автоматизировать процесс подачи заявок и проведения интервью, которые длились по 15–30 минут.

Экспериментатор признал, что многие собеседования он проходил одно за другим, но почти все заканчивались на ранних стадиях.

Алгоритмы против алгоритмов

Пост быстро стал вирусным: пользователи X увидели в нем отражение новой реальности — ИИ-кандидаты откликаются на вакансии, отбираемые ИИ-рекрутерами.

Согласно исследованию ResumeBuilder за 2025 год, около 30% соискателей в США уже используют нейросети для генерации резюме и сопроводительных писем.

В то же время 42% компаний применяют автоматические фильтры (ATS) для сортировки заявок.

Результат: миллионы автоматизированных резюме конкурируют между собой, но лишь единицы проходят фильтрацию, настроенную на поиск «живых» признаков опыта.

Когда ИИ ищет работу за тебя

В аналогичных экспериментах кандидаты применяют ChatGPT, Claude, Jasper или собственные Python-скрипты, которые подбирают вакансии, адаптируют резюме и массово рассылают заявки.

Однако автоматизация редко повышает шансы на успех. Системы отбора легко распознают шаблонные тексты и массовые заявки, а многие платформы уже внедряют антибот-фильтры, блокирующие подозрительную активность.

Так, еще в 2024 году проект AutoJob из KU Leuven автоматически откликнулся на 20 000 позиций в Европе и получил всего 0,03% успешных ответов.

Аналогичный эксперимент разработчика из Техаса, создавшего бота для прохождения онлайн-интервью, завершился тем, что три из четырех предложений были отозваны после того, как компании поняли: с ними разговаривал не человек.

«Мы пропали» — но не все потеряно

Эксперты HR-рынка считают, что этот кейс — тревожный сигнал о дегуманизации найма. По словам аналитика Workera Джона Саймонса, компании все чаще ищут не идеальные по ключевым словам резюме, а человеческие сигналы — реальные проекты, рекомендации и индивидуальный стиль речи.

Репозиторий уже собрал почти 65 000 звезд на GitHub. Разбираемся, как он устроен и какие интересные модули лежат внутри.

Что делает этот алгоритм

Алгоритм отвечает за то, какие посты и аккаунты вы видите на всех основных страницах в X: от рекомендаций и трендов до пушей. Внутри — десятки сервисов и моделей, взаимодействующих между собой.

Например, компонент home-mixer собирает кандидатные твиты из разных источников (например, через search-index, tweet-mixer, user-tweet-entity-graph) и ранжирует их при помощи легкой и тяжелой нейросети (light-ranker, heavy-ranker).

После этого подключаются фильтры (например, visibility-filters), которые убирают нежелательный контент и скрытые посты.

Из чего это все собрано

Проект построен на Scala (66%), Java (20%) и Rust. Некоторые модули используют Python и даже TensorFlow v1 (например, twml). Базовые компоненты включают:

• Данные — tweepypie, unified-user-actions, user-signal-service
• Модели — SimClusters, TwHIN, real-graph, tweepcred, trust-and-safety-models
• Фреймворки — navi (на Rust), product-mixer, representation-scorer, representation-manager

Также присутствуют специфические компоненты для пушей — сервис pushservice, ранжирующие модели pushservice-light-ranker и pushservice-heavy-ranker, предсказывающие, откроет ли пользователь уведомление.

Почему это важно

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

Во-вторых, открытый код — это редкость в мире коммерческих рекомендаций, особенно на таком масштабе.

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

Что это значит для разработчиков

Этот проект — хорошее поле для изучения реального промышленного машинного обучения. Особенно интересны:

• плотные графовые эмбеддинги в TwHIN
• модели репутации и социальной близости в real-graph и tweepcred
• многозадачные модели в pushservice-heavy-ranker

Проект можно собрать с помощью Bazel, хотя полноценной инфраструктуры для тестов пока нет.

Он весит всего 2,1 МБ, не требует интернета или аккаунта и позволяет обмениваться зашифрованными сообщениями через Bluetooth.

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

Что уже умеет BitChat

• Работает в фоновом режиме.
• Поддерживает сквозное шифрование для приватных чатов.
• Позволяет добавлять избранных пользователей.
• Включает панический режим — три нажатия на логотип стирают все данные.
• Автоматически обновляет Peer ID — идентификатор пользователя.
• Работает без аккаунтов, e-mail и номера телефона.

Разработчик подчёркивает: никакой серверной инфраструктуры. Все коммуникации — через Bluetooth и локальные p2p-сети. Медиа пока не поддерживаются — только текстовые сообщения.

«Когда рядом появится другой битчаттер, система пришлёт уведомление»

Пользователи жалуются, что «там пока никого нет»

Пока в BitChat пустовато: пользователи в соцсетях пишут, что не могут найти собеседников.

Дорси призвал не спешить с выводами: «Дайте приложению время». Также уже отправлено обновление, которое должно устранить баги в переписке между Android и iOS.

На момент публикации:

• Официальная версия доступна только в App Store.
• Android-сборку можно установить вручную через GitHub-инструкцию.
• В iOS-приложении висит предупреждение: «Безопасность переписок ещё не прошла полный аудит». Не рекомендуется использовать в критических ситуациях.

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

Все ждали, что вот-вот начнётся киберпанк: наши аватары будут тусоваться в 3D, ходить по виртуальным улицам и работать в офисе на Марсе. Но метавселенная не случилась и вместо этого мы получили пустые миры, лаги и виртуальную морскую болезнь. Чтобы попасть в эту «новую реальность», нужен мощный комп, дорогущий VR-шлем и вестибулярка космонавта. Массовому пользователю это не по карману и не по душе. Даже если вы добрались до метавечеринки — вас ждала примитивная мультяшная графика.

Метавселенная — красивый технологический концепт, но без реального запроса со стороны людей. Одни видели в ней VR и AR, другие — NFT и блокчейн, третьи — некий 3D-интернет. И стало непонятно: что это вообще было и зачем?

Метавселенная обещала стать новым поколением соцсетей, что именно там будет жить наше будущее общение и работа. Весь хайп смыл новый тренд: волна генеративного ИИ. Meta* (признана в России экстремистской организацией и запрещена) и другие техногиганты свернули свои эксперименты и переключились на нейросети.

У бизнеса с метавселенными тоже не сложилось: ни чёткой модели монетизации, ни реальных кейсов. Продажа виртуальной недвижимости в Decentraland, мерч для аватаров, баннеры в виртуальных тусовках — всё больше напоминает Web3-версию The Sims, чем серьёзную платформу с реальной экономикой. Так что будущее в 3D отложили до лучших времён.

Игровые платформы вроде Minecraft, Roblox, Fortnite — это по сути и есть настоящие метавселенные, которые давно живут своей жизнью. Среднестатистический пользователь от виртуальных тусовок отказывается: ему проще зайти в Discord или залипнуть в обычный стрим на Twitch, чем надевать шлем ради планёрки в Horizon Worlds.

Я могу просто посмотреть стрим и получить лучший опыт. Надевать шлем не имеет смысла — никакой пользы

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

Есть надежда, что метавселенная вернётся — когда технологии и контекст будут готовы. Когда VR-шлемы станут лёгкими, дешевыми и удобными, появятся реальные сценарии, а не просто презентации для инвесторов. Тогда, может быть, мы ещё туда заглянем. А пока — rest in pixels, Metaverse.

NFT-мания

Пока одни тусовались в метавселенной и зарабатывали миллионы на продаже пикселей, другие гуглили, что такое OpenSea и почему JPEG стоит как однушка в Москве. Сейчас NFT называют либо финансовым пузырём, либо зачатками новой цифровой инфраструктуры.

Пандемия и локдаун дали интернету второе дыхание. Люди заскучали и начали скупать цифровое искусство, как раньше собирали марки, карточки или скины в играх. В 2021 году NFT стали мейнстримом: CryptoPunks, Bored Ape, Beeple — эти имена знали все. К цифровой лихорадке подключились бренды: Adidas, Nike и даже McDonald’s начали продавать цифровой мерч в метавселенных. Пиксельные обезьяны разлетались, как будто золото будущего: в январе 2022 NFT-маркетплейс OpenSea побил все рекорды, ведь месячный объём торгов составил около $5 млрд. Владение NFT стало признаком цифрового престижа. Люди устанавливали токены себе на аватарки в Twitter, потому что это был цифровой Rolex: если у тебя был токен — ты в теме. А если нет — шёл читать гайды на Tproger.

Но уже к лету того же года рынок начал сдуваться. В июне 2022 объем OpenSea упал до ~$700 млн, а в октябре 2023 он составлял лишь $91 млн. Минус 98% от пиковых значений. Что же пошло не так?

Большинство NFT не дают прав на владение цифровым активом. Вы покупаете не саму картинку, а ссылку на неё в блокчейне. Если сервер с изображением ляжет — останется только строчка кода, свидетельствующая о вашем хорошем вкусе. Многие NFT были просто картинками. Ни привязки к играм, ни доступа к сообществам, ни других функций — только красивая (или не очень) обёртка.

Зачем мне вообще покупать этот NFT вместо настоящего произведения искусства?

Тысячи NFT-проектов выходили каждый день, рынок быстро перенасытился, и в итоге NFT-платформы утонули в спаме и мошенничестве. Один из самых распространённых трюков — wash trading: пользователь продаёт токен сам себе, чтобы искусственно раздуть спрос. Исследования показывают, что по итогам 2022 года более половины объёма торгов NFT на Ethereum приходилось на липовые сделки. Кто-то считает, что NFT со временем обесценились. Но возможно, что они с самого начала были пустышками.

Ещё один удар по доверию — кражи и хаос с плагиатом. Работы художников массово превращали в NFT без их ведома: копировали, заливали и продавали, как своё. Никто не спрашивал разрешения у авторов, и уж точно не предлагал процент с продаж. NFT также критиковали за углеродный след и загрязнение окружающей среды.

NFT как спекулятивный пузырь — фактически умер. Большинство коллекций потеряли всякий торговый смысл: объёмы упали, активные игроки исчезли, а токены превратились в мёртвые цифровые артефакты. Лихорадочные инвестиции, основанные на спекуляциях, просто сдулись.

Но сама концепция уникального цифрового актива живёт дальше. Токен как технология адаптируется и трансформируется. В играх NFT уже показали себя как востребованный юзкейс: игроки могут владеть, торговать и прокачивать виртуальные предметы. Эксперты считают, что инфраструктура останется, и на её базе появятся проекты с реальной практической ценностью. А NFT превратится в элемент цифровой инфраструктуры — как инструмент доступа и сертификат владения. Цифровой «паспорт», который фиксирует принадлежность к сообществам, открывает возможности для участия в клубах и эксклюзивных событиях.

3D‑телевизоры: история провала объёмного кино у вас дома

В начале 2010-х 3D-ТВ казались мегатрендом после хита «Аватар». Однако к 2016 году большинство крупных производителей отказались от выпуска моделей с поддержкой 3D. Многие пользователи так и не получили качественный опыт из-за технических ограничений и ранней стадии развития.

Я знаю, почему 3D-телевизоры провалились: производители поспешили поймать волну кинотеатрального бумa, сделав технологию с тяжёлыми и требующими подзарядки очками. В то же время на горизонте появились большие плоские телевизоры без очков, которые выглядели гораздо лучше и удобнее для пользователей.

Что пошло не так? Во-первых, сами 3D-очки. Их нужно было заряжать, носить поверх своих, а сидеть при этом строго под определённым углом, иначе магия пропадала. Многие отмечают, что это было неудобно — очки были дорогими, тяжелыми, а некоторые зрители уставали уже на середине фильма: жаловались на напряжение в глазах, дискомфорт и головные боли. Технология, которая должна была удивлять, в итоге просто раздражала.

Контента почти не было, и пользователи, купив дорогой телевизор, сталкивались с вопросом: а что, собственно, смотреть? 3D-телевизоры были дороже своих 2D-аналогов, и с развитием 4K, HDR и OLED-технологий потребители начали отдавать предпочтение лучшему качеству изображения без 3D. Зачем платить за условную «глубину», если можно просто получить красивую живую картинку из коробки.

Несмотря на провал 3D-ТВ в их классическом виде, эксперты не ставят на них технологии крест. Как пишет WIRED, новый виток связан с автостереоскопическими дисплеями: они используют трекинг взгляда, линзы и AI, чтобы создавать объёмное изображение прямо на экране — без всяких аксессуаров.

Google Glass: будущее было на носу

Google Glass подавали как прорыв — интерфейс будущего прямо у вас перед глазами. Но вместо футуризма — странная дужка с экранчиком сбоку. Стоила как хороший ноутбук, делала как плохой смартфон. Пользователи получали уведомления на уровне браслета и фото из 2005 года. Памяти почти нет, батарея умирает быстрее, чем вы успеете сказать «Окей, Google».

Соучредитель Google Сергей Брин позже признал, что не понимал, как устроены поставки и насколько сложно произвести такие очки массово и недорого. И это многое объясняет: в Google Glass вложили идею, но не довели её до жизнеспособного устройства.

Хотя запуск обставили красиво: дали очки техноинфлюенсерам, звёздам, первопроходцам — маркетинг остался без главного: никакой конкретики, ни сроков, ни объяснения, зачем это всё нужно. Продукт обсуждали, хайп был — но в продаже его не было. Сама общественность встретила Glass с настороженностью: главной проблемой стала конфиденциальность. У очков не было явного индикатора съёмки, и люди не понимали, записывают их или нет.

Некоторые считают, что Google Glass просто опередили своё время. Прототип показали ещё в 2013 году на Google I/O, а уже к 2015-му производство свернули. На практике очки оказались недостаточно удобными, многие обозреватели говорили, что они нелепо выглядят, а способов их применения никто так и не придумал. При цене в $1500 очки превратились в атрибут избранных гиков, а не в массовый гаджет.

По оценкам аналитиков, всего было продано не более 250 тыс. таких устройств, причем на старте Google отдала лишь 10 000 очков ограниченному кругу «избранных». Попасть к покупателю было сложно — очки продавали только по рекомендациям действующих владельцев. Функционально устройство не впечатляло: маленький прозрачный дисплей с разрешением 640×360, слабая 5-Мп камера, мало памяти и скромные 2–3 часа работы от батареи не соответствовали ожиданиям пользователей.

После провала на массовом рынке Google сменила стратегию на бизнес‑фокус. С 2014 года разрабатывалась корпоративная версия Glass Enterprise Edition, адаптированная для промышленных задач. Однако эти бизнес-успехи не спасли проект на массовом рынке, и Google окончательно закрыла проект в 2023 году.

На фоне фиаско Google Glass, современные игроки делают выводы — и действуют иначе. Ray-Ban Meta* (признана в России экстремистской организацией и запрещена) не обещают революцию — они интегрируют ИИ и камеру в повседневную форму очков. Не «будущее на лице», а стильный способ снять сторис и получить подсказки от ИИ. Apple Vision Pro, напротив, сознательно уходит в премиум и не обещает быть массовым — только для профессионалов, с чётким сценарием: дополнительный дисплей, работа с контентом и Facetime. А Android XR (например, от Samsung) с амбицией создать экосистему, куда подключаются другие производители.

Главные фейлы: почему хайп умер быстрее, чем мы успели надеть шлемы

• Переоценка трендов: компании хотели влететь в хайповый тренд. В итоге технологии оказывались сырыми или неудобными.
• Нет ценности для пользователя: эти продукты часто не решали реальных задач, а разработчики не объясняли, почему именно их стоит использовать.
• Сложность и неудобства: тяжёлые VR-шлемы, громоздкие или нелепые устройства.
• Непроработанные риски: проблемы с приватностью, мошенничеством и токсичностью подрывали репутацию и доверие.

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

Кнопка «Like» в Facebook*: почти похоронили, прежде чем выстрелила

Сегодня «лайк» — это цифровой рефлекс. Но в 2007-м внутри Facebook* в идее сомневались почти все. В команде был инженер Джастин Розенштейн, он и предложил кнопку, которая бы позволяла реагировать на посты одним нажатием. Сначала хотели назвать её Awesome (жми, если круто). Но потом кто-то предложил более нейтральное Like. Скепсис был высок: менеджеры тормозили идею, обсуждения тянулись годами, пока в один момент кто-то не решился просто выкатить кнопку в прод.

В феврале 2009-го «Like» заработал на всей платформе. И эффект был мгновенный — больше вовлечённости и контента. Через год Facebook* вытащил кнопку на внешние сайты: теперь ты мог лайкать статью на стороннем ресурсе, и это улетало в соцсеть. Лайк стал универсальной валютой внимания, а сама кнопка — самым тиражируемым UI-элементом в интернете.

Урок: даже техническая метка может стать глобальным символом одобрения.

*Компания Meta признана экстремистской на территории РФ

Ретвиты в Twitter**: придумали пользователи, а не разработчики

Twitter** в 2006-м выглядел скудно: 140 символов, никаких картинок, и даже функции «поделиться твитом» не было. Пользователи сами начали выкручиваться — копировали чужие твиты и вручную добавляли префикс «RT @username».

Что сделал Twitter**? Сначала ничего. Команда с недоверием смотрела на это самодельное изобретение. Будто это странно выглядит, рушит эстетичный фид, а ещё может усилить распространение негатива.

Но потом цифры победили эстетику. RT-формат подхватила масса — это был народный функционал. И Twitter** пришлось догонять свой же комьюнити. В 2009-м разработчики сделали официальную кнопку «Retweet». Уже через пару лет без неё невозможно было представить платформу.

К слову, и сегодня в твиттер**-экосистеме «ретвит» — это не просто фича. Это способ продвигать мемы, новости, протесты, кампании. Всё началось с пользовательского хака — и превратилось в одну из самых влиятельных кнопок в интернете.

Урок: пользовательский хакинг иногда лучше любого UX-ресерча.

**Запрещен на территории РФ

typeof null === "object" — баг, которому 28 лет, и он всё ещё с нами

JavaScript писали в адских условиях: у Брендана Айка было всего 10 дней в 1995 году, чтобы запилить язык для браузера Netscape. Никакого «спринта», никакой архитектурной выверенности — просто надо было быстро сварганить что-то, что напоминает и Java, и скрипт.

В этой спешке в typeof закралась ошибка: typeof null начал возвращать "object" . Почему? Потому что в ранней реализации значения в JavaScript представлялись в памяти с помощью тегов. Если тип — объект, у него был специальный тег (000). Проблема в том, что null хранился как ноль, а 0 в бинарной записи — это тоже 000. Крайний случай не проверили.

Айк позже признавал: да, это ошибка. Но баг стал настолько фундаментальным, что его решили не трогать, чтобы не поломать совместимость со всем количеством сайтов, библиотек и фреймворков. Спустя почти три десятилетия он всё ещё с нами. Люди пишут костыли вроде value === null или Object.prototype.toString.call(value) === ‘[object Null]’, а баг — живет.

Урок: Иногда баг — это не баг, а историческое наследие. Скелет в шкафу, вокруг которого строят фреймворки.

Глючная физика в GTA: когда баг становится аттракционом

Если вы хотя бы раз играли в GTA IV или V, вы знаете: на ровном месте машина может улететь в воздух, мотоцикл — в стратосферу, а NPC — разложиться на асфальте. Всё это — не баги (но когда-то ими были).

Всё началось с движка Euphoria, который Rockstar подключили в GTA IV. Это процедурная система физики и анимации — каждый раз персонаж падает или реагирует на столкновение по-разному. Не скриптовано, а реально: траектория, инерция, вес, центр тяжести. Но оказалось, что если чуть-чуть не дотянуть параметры или немного ошибиться в расчетах — мы будем иметь то, что имеем. Пользователи заметили это и начали тестировать движок на слом. Видео с багами собирали миллионы просмотров. Получилось, что баг физики стал частью эстетики серии GTA.

Урок: глупость + баг = YouTube-флешмоб.

YouTube: платформа для свиданий? Почти…

Да, YouTube изначально не задумывался как «видеохостинг №1 в мире». Его создатели в 2005 году хотели сделать сайт знакомств с видеоанкетами. Он даже запускался под лозунгом: «Tune in, Hook up» — что-то вроде «Подключайся, знакомься». Создатели сами грузили первые профили, чтобы смоделировать активность. Только вот настоящие пользователи не спешили заливать анкеты.

Зато начинали заливать… видео. Случился момент, когда баг оригинальной идеи стал фичей: команда YouTube поняла, что людям нужен не видеотиндер, а простой способ делиться роликами. Спустя год сервис купил Google за $1,65 млрд.

Сегодня YouTube — не площадка для «hook up», но миллионы людей всё ещё смотрят ролики, чтобы найти… если не любовь, то хотя бы что-то интересное.

Урок: баг концепции может стать бизнес-стратегией.

Вибрация в геймпадах: баг, который встряхнул всю индустрию

Сегодня вибрация в контроллере — это стандарт. Упала ракета? Загорелся экран? Пульсирует джойстик. Но изначально этой функции не было. А то, что она появилась, — скорее побочный эффект, чем заранее спланированная геймдизайнерская находка.

История уходит в 90-е, к компании Nintendo. В те времена японские инженеры экспериментировали с устройством под названием Rumble Pak — дополнительным модулем, который вставлялся в контроллер Nintendo 64. Но изначально он использовался не как фича, а вызывал сбой в системе. Контроллер вел себя нестабильно: дергался, шумел, давал отдачу. И всё это — из-за того, что моторчик «неправильно» взаимодействовал с платой. Кто-то бы списал это на дефект. Но не Nintendo.

Они добавили виброотдачу на выстрелы, взрывы и резкие повороты. Так вместо бага получилось новое ощущение от игры — буквально на кончиках пальцев. Игрок не просто видел экшен, он его чувствовал.

Rumble Pak вышел в 1997 году в комплекте с Star Fox 64 — и стал вирусным. Спустя пару лет все крупные консоли уже добавляли вибро как must-have.

Урок: эффект «погружения» может родиться из инженерной ошибки.

Бесконечные деньги в Diablo: экономика ада на баге

Когда Diablo вышел в 1996 году, он быстро захватил сердца игроков: ад, скелеты, лут, все как надо. Но уже через пару месяцев игру сломали — и не демоны.

Оказалось, что внутриигровая экономика уязвима до боли: можно было дюпать (дублировать) золото бесконечно. И никакого хакерства — просто баг в интерфейсе торговли.

Как это работало?

• Игрок кидал золото на землю.

• Одновременно открывал инвентарь.

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

Проблема стала массовой: игроки скупали всё, ломали баланс, создавали армию богачей. В сетевой игре это вызывало настоящую инфляцию — все были с топовым шмотом, никто не хотел фармить по-честному. Blizzard пришлось срочно выкатывать патчи, а в Battle.net — банить багеров.

Урок: внимательно наблюдай за багами — в них поведенческая экономика.

Auto-Tune — как баг стал музыкальным стилем

Auto-Tune, известный в первую очередь как инструмент для коррекции вокала, стал не просто незаменимым музыкальным инструментом, а настоящим культурным феноменом. Интересно, что его массовое использование в музыкальной индустрии началось благодаря случайности.

Когда в 1997 году инженер звука Андреас Керн в компании Antares Audio Technologies разрабатывал программу для коррекции мелодии, он не планировал, что её использование изменит музыкальный ландшафт. Изначально цель Auto-Tune заключалась в том, чтобы исправить небольшие отклонения в тоне голоса при записи. Однако в процессе тестирования инженеры заметили, что программное обеспечение не только исправляет ошибки в нотах, но и начинает создавать уникальное роботизированное звучание, если применять слишком сильное воздействие.

Интересно, что такую аномалию никто не ожидал, и, возможно, это было связано с ограничениями самой технологии на тот момент. Однако именно эта особенность привлекла внимание музыкантов и продюсеров. Вскоре Cher впервые использовала эту технологию в своей песне Believe (1998), придавая вокалу необычное, искаженное звучание. Это было воспринято как новаторский ход, и песня стала международным хитом.

После Auto-Tune стал не просто инструментом для коррекции, а важным элементом для создания нового музыкального стиля. В начале 2000-х годов использование автотюна в поп- и хип-хоп-музыке приобрело широкую популярность, и технологию начали активно использовать Kanye West, T-Pain, Lil Wayne т.д..

Урок: что для тебя — баг, для другого — искусство.

А забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

9 марта пользовательница TikTok Дарья Митрофанова (@dariamitro1) выложила видео о приложении Status, где рассказала, почему её затянула эта игра.

Ролик быстро стал вирусным, набрав 2,3 миллиона просмотров, и привел в игру кучу русскоязычных пользователей. Status зафорсился в тикток-комьюнити, а Дарья получила статус официального амбассадора игры. Теперь она сотрудничает с разработчиками, делится инсайдами и рассказывает об обновлениях в Telegram-канале «сестра кайзера про статус».

12 марта приложение заняло 4-е место в российском App Store, достигнув 1 млн пользователей за 19 дней — и похоже, это только начало.

Суть игры

Status — это ролевой симулятор соцсетей, где можно погрузиться в любимый фандом, взаимодействовать с персонажами и влиять на развитие истории. Суть игры — вести блог внутри вымышленного мира и реагировать на его события. Геймплей сочетает элементы социальной песочницы, симулятора инфлюенсера и нарративной ролевки.

Все персонажи — это ИИ. Внутри нет реальных людей, хотя в планах у разработчиков добавить мультиплеер. Вы зарабатываете подписчиков, прокачиваете навыки и отношения с персонажами. Есть система квестов — арочные события, ивенты и задания. Но будьте осторожны: вас могут отменить даже за ананасы на пицце.

App Store|Google Play|Discord-сервер игры

Почему игра так завирусилась?

• Можно стать кем угодно. Хотите быть персонажем культового боевика, любимого аниме, крутить роман с рок-звездой или стать гениальным хакером? В этой игре всё возможно.
• Разнообразие вариативности и полная кастомизация. Простор для воображения. В игре нет четкого сценария — вы задаёте его сами, а ИИ отвечает за развитие сюжета.
• Больше никакого страха перед соцсетями. Это место, где можно быть собой без страха осуждения. Но будьте готовы к сюрпризам, ведь реакция персонажей непредсказуема.

вместо того, чтобы становиться более популярной в реальном инете, я становлюсь популярной в ПРИЛОЖЕНИИ С ИИ, ЭТО АФИГЕННО

Добавьте механику роста подписчиков, сюжетные ивенты и возможность буквально «жить» в альтернативной вселенной — и вот игра, от которой сложно оторваться. Буквально интерактивный фанфик с драмами и конфликтами.

Мы поговорили с Данилой Калиникиным, чтобы узнать о том, почему игра Status вызвала такой ажиотаж, узнали о трендах LLM-игр, и за какими ещё проектами в сфере ИИ-геймдева стоит следить.

Главная фишка Status в том, что игроки могут симулировать собственную реальность и обсуждать события виртуального мира, оставаясь в определенном образе. Как и в жизни, другие персонажи могут их осуждать, поддерживать или влиять на решения. Но на подсознательном уровне понятно, что это игра, поэтому высказываться не так страшно. В эпоху соцсетей и мессенджеров Status стал отдушиной для интровертов, которые боятся говорить на публике.

Не думаю, что игры с использованием LLM станут отдельным жанром, как RPG или стратегии. Скорее, это будет подвид любого вида игр, где персонажами управляет ИИ. Задел под это был ещё в 2016 году, когда AlphaGo обыграла Ли Седоля в игру «Go». LLM только набирают обороты в геймдеве и их использование станет базовым навыком для разработчиков игр.

• В магистратуре AI Talent Hub в ИТМО, например, студенты сейчас работают над проектом NetTyan — автономной AI-стримершей, которая играет в Minecraft, общается с аудиторией и адаптируется к чату в реальном времени. Продукт уже работает и успешно проходит испытания, в которых нужно победить 30 реальных игроков.
• AI Dungeon — текстовая приключенческая игра, в которой ИИ генерирует бесконечные сюжетные линии и взаимодействия.
• Для AI-геймдева интересна платформа Ludo, которая помогает интегрировать ИИ в игровые механики.
• Сервис для кибербезопасников Gandalf.ai, где можно потренироваться в обходе защиты LLM с помощью специальных промптов.

Кто стоит за Status?

Несмотря на слухи в TikTok, что Status — это всего лишь студенческий проект, за игрой стоит серьёзная команда и мощная поддержка. Вот, что известно:

• В AppStore указано, что приложение принадлежит WishRoll Inc.
• На страничке Wishroll в Forbes сообщается, что они разработали приложение Kiwi, которое набрало 2 млн скачиваний.
• Компания была основана в 2021 году тремя друзьями в Нью-Йорке и привлекла $2.9 млн от Y Combinator и General Catalyst.
• Основатели проекта попадали в список Forbes 30 under 30 еще в прошлом году.
• Среди инвесторов Status — команда Creator Ventures, включая олдового ютубера Caspar Lee с 6.5 млн фолловеров. Эта компания инвестирует в инновационные проекты, например, в ElevenLabs — известный AI-проект по генерации голоса.

Регистрация временно закрыта

Из-за наплыва пользователей 16 марта разработчики временно приостановили регистрацию новых аккаунтов. Если у вас уже есть аккаунт, можно играть без ограничений. Остальным придётся немного подождать.

Приложение может работать не стабильно

На приложение сейчас высокая нагрузка, из-за чего могут возникать задержки:

• Появляется утка с отсчётом 15 минут — очередь на вход, чтобы снизить нагрузку.
• Долго загружаются посты и результаты после участия в ивентах.
• Боты не публикуют посты, а только комментируют.
• Часто появляется сообщение о технических работах, когда разработчики исправляют баги.
• Иногда вылетает ошибка «No internet connection», хотя с вашим интернетом всё нормально.

Разработчики знают о проблемах и работают над решением. Что делать? Просто ждать и не спамить запросами — это только сильнее нагружает сервер.

Как всё работает?

Информация на основе официального гайда.

Настраиваем вселенную и персонажа

Выбираем фандом. Определяем, где будем вести цифровой дневник — можно выбрать готовый мир из каталога (аниме, фильмы, игры, книги, сериалы, рэперы, стримеры) или создать свой.

Выбираем первого подписчика. Он задаст атмосферу игры.

• Им может стать культовый персонаж из выбранного мира или кто-то новый, придуманный вами.
• Если нужного персонажа в каталоге нет, можно создать его самостоятельно.
• Он будет реагировать на ваши посты, комментировать и влиять на сюжет.
• В зависимости от ваших действий отношения могут измениться — вероятно, он станет вашим другом, союзником или врагом.

Настраиваем профиль. Придумываем имя, ник и загружаем аватарку. Можно играть за себя, скрафтить оригинального персонажа или внести информацию уже существующего героя из вселенной.

Заполняем биографию. Это суперважная часть — ИИ использует вашу легенду, чтобы генерировать ленту и события. Чем подробнее вы опишете персонажа, тем интереснее будет сюжет.

Что писать в био? Нужно указать основную информацию о персонаже: где он живёт, чем занимается, какие у него интересы. Важно уложиться в 1000 символов. Пишите на русском или английском — зависит от того, на каком языке планируете играть.

Например:

• Я ученик Токийского университета. Днём — обычный студент, ночью — искореняю преступность. Этот мир давно прогнил, и я собираюсь его изменить.
• Я только что приехал в Хогвартс и уже влип в неприятности. Волшебство — это круто, но почему все так пялятся на мой шрам?
• Я живу в Нью-Йорке, фотографирую для газеты, а ещё спасаю город в костюме Человека-паука. Пока никто не раскусил мою тайну, но это вопрос времени.
• Я школьник из Форкса. Здесь серо, скучно и постоянно льёт дождь. Всё было обычным, пока я не заметил, что в нашем классе есть семья, которая слишком идеальна. И они явно что-то скрывают.

Ждём создания сценария. ИИ анализирует вашу биографию, чтобы сгенерировать сценарий. Это может занять немного времени.

Игра начинается: вам выпадет три навыка для прокачки и первый квест — запилить пост в блог.

Настройка вселенной. После генерации мира можно перейти во вторую вкладку и подробнее кастомизировать вселенную:

• Задать главную цель персонажа в окошке Your Main Character Goal. Эта цель будет влиять на квесты и события. Позже её можно изменить, чтобы открыть новые возможности.
• Your Universe — описание мира. Можно задать уникальные особенности, исторический контекст, перспективы или аспекты, важные для сюжета

Scenario Building 101 — основные вопросы для настройки мира:

• Когда происходит история? Например, первые попытки властей контролировать сверхспособности.
• Кто в центре внимания? Например, элитная команда, куда закрыт вход обычным студентам.
• Чем он отличается? Например, существует закрытая школа, в которой обучают только избранных.
• Какие особые правила есть у вашего мира? Например, жёсткие ограничения на использование магии.

Как перевести Status на русский язык?

В игре Status нельзя изменить язык интерфейса, но можно настроить мир так, чтобы весь внутриигровой контент (новости, события, сообщения персонажей) был на русском:

• Внизу экрана найдите вторую слева иконку (мишень 🎯).
• Нажмите на нее и выберите Customize.
• Откройте раздел Your Universe.

В поле описания вселенной введите следующий промпт:

Закройте настройки и продолжайте играть, публикуя посты на русском. Подождите 2-3 игровых дня, чтобы система адаптировалась. Со временем должны переключиться квесты и события. Если не срабатывает, откройте профили персонажей (во вкладке вашего профиля) и укажите в био каждого, что они говорят на русском.

Какие активности есть в игре Status

Простой постинг

Постинг — это основной инструмент влияния на мир в Status. Ваши публикации могут стать инфоповодом, взорвать фандом и запустить целые сюжетные события. Каждое сообщение учитывается алгоритмами ИИ и влияет на цифровую репутацию, отношение к вам основных персонажей и развитие истории. Можете просто веселиться или прокачиваться, собирая подписчиков и продвигаясь в сюжетке.

Есть два варианта постинга:

1. Щитпостинг — просто пишете, что вздумается, и смотрите, как реагируют NPC. Можно шутить, троллить или просто болтать.
2. Сайд-квесты — задания для прокачки, за выполнение которых можно получить XP-очки для скиллов. По мере продвижения открываются новые задания.

Персонажи, NPC и аккаунты-таблоиды будут реагировать на ваши посты — могут лайкать, репостить, комментировать, спорить, обвинять в неискренности, распускать слухи, шипперить вас с кем-то, защищать и поддерживать или наоборот, хейтить. Внутри посты пишете только вы и боты, других настоящих людей в игре нет.

Что может произойти?

• Подписчиков станет больше — если пост залетел, вас начнут репостить, обсуждать и цитировать в новостях.
• Хейт и отмена — написали что-то спорное? Ждите ухудшения отношений с персонажами, отписок и краха репутации.
• Слухи и мемы — таблоиды и медиа могут подхватить тему, строить теории и раздувать скандалы, а NPC — начать шутить на эту тему.

Что влияет на реакцию?

• Лор решает — NPC следят за контекстом и реагируют в рамках своей вселенной и промпта-биографии.
• Тип персонажа — одни NPC поддержат, другие осудят, третьи — начнут троллить.
• Тон и содержание — шутка может зайти или обернуться против вас.
• Прошлые косяки не забываются — если вы уже вляпались в скандал, ждите, что вам припомнят «зашквар».

Ваша цифровая жизнь — в ваших руках. Постите с умом (или без).

Ивенты в календаре

Календарь — это встроенный инструмент для планирования и отыгрыша событий в игровом мире.

• На каждый ивент расходуется одна полоска энергии.
• В них могут участвовать до пяти персонажей.
• Исход «ролинга» влияет на дальнейшее развитие сюжета: отношения могут как улучшиться, так и испортиться.
• Что можно запланировать? Всё, что угодно: свидание, вечеринку, концерт, путешествие, судебное разбирательство, расследование преступления или даже вторжение инопланетян!
• *Функция на бета-тесте, возможны баги.

Как создать событие?

1. Жмём на иконку календаря внизу экрана.
2. Тапаем «+» , чтобы добавить событие.
3. Придумываем название, выбираем игровой день и персонажей-участников.
4. Подробно описываем, что будет происходить.

Когда наступит день X, заходим в событие и жмём «Start». Начнется отыгрыш, и вам предложат 3 варианта действий (или можно ввести свой). Всего доступно 3 хода, затем можно потратить энергию на дополнительные действия, если захочется продолжения банкета.

Ивенты с выбором

• Участвовать в ивенте можно, когда кнопка в основной ленте становится активной. На ней также указано, сколько очков вы можете заработать.
• Игра подкидывает ситуацию, а вы решаете, как на неё реагировать.
• Не нравится событие? Крутите кубик (до 4 раз) и меняйте вариант.
• Ваша задача — просто написать, как вы поступите в этой ситуации. Это повлияет на вашу популярность, отношения с персонажами и долгосрочное развитие истории.
• Нет идей? Жмите «Give me ideas», и ИИ сгенерирует варианты ответа варианты за вас.

Что делать, если ивенты ломают ваш сценарий или повторяются?

• Оцените событие в 1 звезду и оставьте о нем фидбек: можно выбрать из готовых опций: «repetitive» — повторяется, «break story» — рушит вашу историю, «boring» — скучное и неинтересное, «bad memory» — не учитывает контекст, «bad suggestions» — неподходящие варианты событий.
• Это повлияет на генерацию контента — стиль публикаций изменится, а события станут другими на следующий игровой день.

Личные сообщения

Конец публичному стыду — теперь ваши «спишь?» никто не увидит! Наконец-то можно флиртовать, не краснея перед всей лентой.

18 марта разработчики добавили функцию личных сообщений. Ваши чаты можно найти в верхнем правом углу.

• Чтобы начать переписку, нужно потратить одну полоску энергии.
• Можно отправить до 5 сообщений по 500 символов, затем понадобится энергия.
• Чаты влияют на отношения, но остаются приватными — никто, кроме вас и персонажа, их не увидит.
• Внизу видно реакцию персонажа и изменения в уровне отношений.

Сущности игры Status

Миры

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

Чтобы создать новый сценарий:

1. Нажмите на иконку выхода в верхнем меню.
2. Выберите «New scenario».

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

Энергия

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

Как работает энергия?

• Энергия — это лимит действий на 24 часа.
• После каждого действия в игре один блок энергии становится серым.
• За одно действие может уходить разное количество энергии — это связано с высокой нагрузкой на приложение.
• Серый блок восстанавливается примерно за пять минут. Если сервер перегружен, время восстановления может увеличиваться до 15 минут.
• В день доступно ~50–60 действий.
• Когда остаётся 7 последних действий, появляются ❌ красные крестики.
• Если не тратить всю энергию до конца, она восстанавливается быстрее.
• Полное восстановление происходит в 00:00 по вашему часовому поясу.
• Можно получить дополнительную энергию, купив кофе за донат.

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

Что означают песочные часы ⏳, солнце ☀️ и ракета 🚀?

• ⏳ Песочные часы — сколько дней подряд вы заходите в игру.
• ☀️ Солнце — сколько игровых дней прошло. Новый день начинается после поста, ивента или события в календаре (ответы на посты не считаются).
• 🚀 Ракета — ваш прогресс в выполнении Milestone-заданий. Каждые 5 уровней в Milestone открывают нового персонажа! (Важно: Milestone ≠ уровень во вселенной).

Навыки

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

Чтобы выполнить Milestone, нужно прокачать уровень навыков, указанный перед плашкой «Complete milestone».

При создании сценария можно выбрать, какие навыки вы хотите развивать. При заполнении био добавьте: «Навыки, которые я хочу развивать: [навык 1], [навык 2], [навык 3]». После начала сценария изменить невозможно, поэтому в существующей вселенной этот способ не сработает.

Какие персонажи есть в Status?

Основные персонажи

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

Ваши посты, участие в ивентах и событиях влияют на отношения с персонажами.

• В профиле персонажа отображается ваш текущий статус взаимоотношений.
• В логах действий («Actions log») можно подробнее увидеть, как персонажи реагируют на ваши посты. Логи можно найти на вкладке с мишенью 🎯. Вы увидите, какие изменения произошли в очках и отношениях, какие эмоции персонажи испытывают и что они о вас думают. Для каждого действия фиксируется его результат, реакция персонажей и краткое описание изменений.

Каждые 5 уровней Milestone открывается новый слот для персонажа. Майлстоуны (Milestones) — это ключевые точки в игре, своеобразный прогресс достижения цели. Чтобы пройти их, нужно зарабатывать очки и прокачивать скиллы, выполняя сайд-квесты и участвуя в ивентах.

Как добавить больше персонажей?

Если захотите добавить кого-то раньше достижения нового майлстоуна, придётся удалить старого: перейдите к нему в профиль и нажмите «Remove character». Когда вы откроете нового персонажа, нажмите «New character unlock» и выберите один из вариантов:

1. Выбрать существующего из каталога, созданного другими игроками.
2. Создать своего — придумайте персонажа с нуля, задав ему лор и стиль общения. Если не хотите, чтобы другие видели вашего персонажа, его можно приватным при создании.
3. Выбрать рандомного персонажа.

При создании персонажа можно задать его стиль общения, легенду и роль в вашей истории. Лучше прописать его фирменные фразочки, отношение к другим персонажам и любимые темы. Тонкая настройка поможет сделать персонажа более каноничным и органично вписать его в игровой мир. Если захотите что-то изменить, зайдите в профиль персонажа и нажмите «Edit».

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

Аккаунты медиа

В игровом мире есть таблоиды и новостные аккаунты, такие как GMZ, Pop Craze и BBE. Они не просто освещают события — они следят за каждым вашим вздохом, распускают слухи, превращая каждый чих в заголовок и «громкий инсайд».

GMZ уже стали настоящим мемом внутри фандома приложения из-за того, что выдают сенсации на ровном месте. Их посты — смесь правды, догадок инсайдеров и откровенных спекуляций.

NPC

Помимо основных персонажей в Status есть NPC — боты, созданные системой. Их ники сгенерены по лору, и они вбрасывают комменты, рофлят, обсуждают ивенты и делают ленту не такой пустой.

Что делают NPC?

• Оставляют комментарии под постами, вбрасывают мемные шутки, используя сленг.
• Реагируют на события, обсуждают ивенты и посты таблоидов.
• Поддерживают атмосферу вселенной, генерируя правдоподобные дискуссии.

Но прокачивать отношения с ними нельзя — они существуют только для антуража и не запоминают ваши действия.

Потенциал игры

Потенциал игры реально впечатляющий. Возможности кастомизации и настройки внутренних инструкций — просто находка для развлечения и даже для образовательных проектов. Например, есть вселенная с персонажами-русскими писателями, с которыми можно взаимодействовать. Если не настраивать приложение на русский язык, то можно практиковать английский. А с помощью промпт-инжиниринга открывается доступ к фичам. Например, можно создавать эффект «постинга фото».

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

это полный конец моей социализации

Делитесь мнением в комментариях!

Совсем еще мальчишка получил доступ к аккаунтам мировых знаменитостей и крупных компаний, включая Илона Маска, Билла Гейтса, Apple и других.

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

Как ему это удалось?

Кларк использовал методы социальной инженерии и атаку через подмену SIM-карт, чтобы получить доступ к внутренним системам Twitter.

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

Грэм начал свою «карьеру» ещё в 13 лет, зарабатывая на мошенничестве в онлайн-играх, таких как Minecraft, что постепенно переросло в более опасные киберпреступления.

Чем всё закончилось?

Этот взлом стал поворотным моментом в борьбе с киберпреступностью. Кларка арестовали, а его дело стало уроком для крупных технологических компаний.

Однако многие эксперты отмечают, что такие атаки могут повториться, если не будет усилена защита социальных платформ и пользовательских данных.

Узнайте больше в новом выпуске «АЙТИ КРАЙМ»

Эта шокирующая история стала темой нового эпизода подкаста «АЙТИ КРАЙМ» от Tproger. В выпуске вы узнаете не только детали дерзкого взлома, но и как обычный подросток смог обмануть миллионы людей, использовать слабости крупнейшей социальной сети в своих целях и какие уроки стоит вынести из этой истории.

Подкаст доступен на всех популярных платформах по ссылке, а также в видеоформате:

Тогда один из пользователей Twitter предупредил Маска о тренировках Цукерберга по джиу-джитсу, на что Маск ответил, что готов к бою, если его противник согласится​.

Цукерберг немедленно принял вызов, написав: «Send me location» («Отправь мне место»).

Подготовка и тренировки

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

Цукерберг, со своей стороны, продолжал активно тренироваться, участвуя в соревнованиях по бразильскому джиу-джитсу, где он завоевал призовые медали​.

Неопределенность и отмена

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

В августе 2023 года Цукерберг заявил, что не считает заявления Маска серьезными и предложил двигаться дальше, поскольку глава Tesla не только не подтвердил дату, но и заявил о необходимости провести хирургическую операцию.

Цукерберг отметил, что готов соревноваться только с теми, кто по-настоящему серьезно относится к спорту​.

Возобновление интереса

Тем не менее, накануне Маск снова заявил о своей готовности выйти на ринг на условиях Цукерберга. Он подчеркнул, что готов к бою «в любое место, в любое время и по любым правилам».

Эта новость мгновенно возобновила интерес к возможному бою, хотя конкретная дата и место пока не определены​.

Идея пришла после того нескольких провальных переписок и свиданий. Девушки, по его словам, были с «характерными минусами». Кроме того, Жадан не был готов тратить слишком много времени и денег на поиск подходящей девушки (потому что, кроме походов на свидания, нужно «успевать работать, заниматься хобби, учиться и общаться с людьми»).

В итоге он научил нейросеть искать пары и общаться в Tinder вместо себя

Эксперимент начался в 2022 году. За основу был взять API GPT-3, к которому у Жадана был ранний доступ (никакого ChatGPT в паблике еще не было). Парень научил его отбирать вероятно подходящих девушек (у которых есть хотя бы две фотографии в профиле) и завязывать общение после мэтча:

GPT общался без моего вмешательства по запросу «ты парень, общаешься с девушкой впервые. Твоя задача: не сразу, но пригласить на свидание». Костыльно и не очень человечно, зато работало.

Диалоги по скрипту быстро заканчивали, потому что GPT звал на свидания в лес, упорно предлагал курицу с овощами и выдавал «душную» теорию не к месту. Кроме того, бот поначалу не учитывал предыдущие сообщения (пришлось отдельно учить его запоминать контекст):

С выходом ChatGPT общение стало лучше

Жадан дообучил нейросеть по собственным диалогам, настроил фильтр, чтобы девушка не прилетали «кринж-истории» — по крайней мере, вначале. И прикрутил систему распознавания лиц (обучал ее на свайпах с другого аккаунта). Также через API ChatGPT и FlutterFlow научил отсеивать кандидаток по разным критериям, например, без анкет, публикующих фото с цветами, указывающих знак зодиака.

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

Тем не менее нейросеть все еще косячила: могла назначала свидания на одно время, обещала принести на встречу пять литров компота.

Вторая версия на ChatGPT-4 стала сложнее, но лучше

Жадан интегрировал календарь и Telegram, прикрутил новую систему распознавания по фото, параллельно попросил обычный ChatGPT помочь — тот предложил в начале общения рассказывать про детство, цели и ценности и определил признаки идеальной партнерши. В итоге получилось улучшить качество переписок и возобновить общение с некоторыми девушками. А еще появился дополнительный фильтр — если ценности и какие-то черты не совпадали, бот заканчивал общение.

Допом появились бот в Telegram, который присылал статусы переписок и обращался к Жадану, когда не был уверен в ответе, и валидация ответа.

За месяц ChatGPT V2 получила почти 5 тысяч мэтчей в Tinder Gold. А на количество встреч можете посмотреть здесь:

В итоге остались 4 девушки: с тремя сохранились дружеские отношения, а четвертая оказалась «она».

И чтобы не заруинить общение, была создана ChatGPT V3

Парень настроил V3, как «наблюдателя», который общается, когда Жадан долго не отвечает, дает советы. И пишет, если беседа накаляется.

Наконец, ChatGPT V3 прислал очередное саммари бесед и предложил жениться на девушке.

На разработку проекта ушло ~120 часов и $1432 на API. На счета в ресторанах вышло до 200тр. Бтв, затраты отбил и заработал на рекомендациях. Если знакомиться самому и ходить на свидания, то на то же самое ушло 5+ лет и 13м+ рублей. Спасибо ChatGPT за экономию денег и времени

И, возможно, это все пиар-ход

История завирусила в Х, и пользователи, разумеется, запостили много шуток и мемов. Одни предложили теперь проверять пары в Тиндере капчей (кто-то и вовсе решил что некоторые уже это делают с помощью дикпиков).

Кто-то делал отсылки к Терминатору и Черному зеркалу (по сюжету одной из серий люди ищут себе пары с помощью ИИ). Кто-то предлагал завести отношения со Скрепышом.

Наконец, героя заподозрили в обмане (и прогреве перед запуском курса). Программист Коля Шваб изучил алгоритм и сказал, что это похоже на «фулл-тайм проекту на несколько месяцев в разработке и эксплуатации». Кроме того, он напомнил, что OpenAI позволила обучать модели ChatGPT в марте 2023 года. Но уже в апреле ChatGPT V1 работала «на полную».

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

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

Запуск программы связывали с тем, что Марк Цукерберг запустил собственную площадку микроблогинга: якобы выплаты должны помочь Twitter удержать авторов.

Однако служба поддержки X Support обратилась к пользователям и сообщила, что Twitter/X не смог выплатить часть доходов от рекламы всем блогерам.

В X Support заявили, что команде требуется дополнительное время, чтобы учесть все нюансы перед выплатами. При этом авторам пообещали, что деньги всё же поступят на их счета, но чуть позже.

Илон Маск предупреждал сотрудников Твиттера, что Twitter будет переименован. Это заявление также подтвердила гендиректор Линда Яккарино. Она добавила, что переименование Твиттера в Х станет частью трансформации компании в площадку, которая сможет предоставить своим пользователям “буквально всё”.

Кстати, именно из-за него Цукерберг и Илон Маск хотели подраться — Илону Маску не нравится, что кто-то так нагло копирует идею Твиттера в его не самые лучшие времена. Оба предпринимателя подтвердили, что готовы к бою в клетке. А Маск даже предложил конкретное место.

Кстати, за первые часы работы в Threads зарегистрировалось уже свыше 10 млн пользователей.

Скачать приложение можно на официальном сайте проекта. Или в маркетах для iOS:

И Android:

Из России соцсеть работает только с VPN-подключением.

Маск винит компании, пытающиеся получить данные для обучения искусственного интеллекта большими моделями языка (LLMs), такими как ChatGPT, Microsoft Bing и Google Bard.

Илон Маск ограничивает количество твитов, которые люди могут прочитать в Twitter.

1. Неподтвержденные аккаунты могут видеть 600 твитов в день.
2. Новые неподтвержденные аккаунты могут видеть 300 твитов в день.
3. Верифицированные аккаунты могут видеть максимум 6000 твитов в день.

Маск планирует увеличить ограничения для верифицированных пользователей до 8000 твитов в день.

Ограничения возникли после того, как Twitter начал блокировать доступ для неавторизованных пользователей.

Изменение – это только один из нескольких способов, которыми Маск пытается монетизировать Twitter за последние несколько месяцев. В марте компания объявила о трехуровневом изменении API, которое начнет брать плату за использование своего API, всего лишь через три месяца после запуска обновленной платной схемы Twitter Blue за $8 в месяц для получения верификации.

Также Маск также заменил себя новым генеральным директором, Линдой Яккарино. Бывший рекламный руководитель из NBC Universal была нанята для восстановления отношений с рекламодателями, которые значительно сократили свои затраты на Twitter.

Однако есть предположения, что ограничения связаны с нестабильностью Twitter. Маск уволил более половины сотрудников Twitter прошлой осенью, включая людей, необходимых для поддержания ее инфраструктуры.

Безответственные увольнения привели к тому, что компания была вынуждена переустроить некоторых уволенных инженеров, и люди неоднократно предупреждали, что увольнение такого большого количества сотрудников повлияет на стабильность Twitter.

А сегодня он опубликовал кадры, где проводит спаринг с Илоном Маском.

Сам Лекс впечатлился подготовкой Маска и его мастерством. Он также сказал, что его бой с Марком был бы «эпичным». Но пожелал, чтобы драка не состоялась.

История началась с того, что Маск высмеял желание Цукерберга скопировать Twitter.

Тогда подписчики посоветовали Маску «быть осторожнее», ведь Марк Цукерберг занимается джиу-джитсу и даже участвует в турнирах. На что руководитель Tesla и SpaceX сказал, что «готов к поединку в клетке».

Позже оба предпринимателя подтвердили, что готовы к бою в клетке по правилам MMA. А Маск даже предложил конкретное место.

Хоть большая часть родителей Python относится к поколениям “бумеры” и X, все-таки некий уровень публичности они поддерживают. Вашему вниманию Twitter-каналы некоторых известных разработчиков и экспертов. К сожалению, с доступом к нему могут быть проблемы на территории РФ, так что запаситесь хорошим бесплатным VPN.

Создатели языка

1. Guido van Rossum (@gvanrossum) — создатель Python. У такого монстра жизнь и вправду очень разнообразна: Гвидо постит об искусственном интеллекте (еще бы), девконах с его участием и о “проклятом” релизе Python 3.11b4.

2. Raymond Hettinger (@raymondh) — основной разработчик языка Python и автор многих его модулей. Часто постит код в твитах, описывает продвинутые приемы языка.

3. Eric Snow (@ericsnowcrntly) — активный разработчик ядра Python. Его канал больше подходит продвинутым пользователям: подразумевается, что вы свободно владеете основной терминологией, уже успели заскучать с ней. И тут в вашу жизнь врывается Pyiodide, MicroPython и расширенные настройки Garbage Collection.

4. Łukasz Langa (@llanga) — менеджер выпуска Python 3.8 и автор «Black», форматтера кода Python. Много твитов о конференции PyConUS и обновлениях Python.

5. Brett Cannon (@brettsky) — разработчик ядра Python и автор многих стандартов PEP. Читать его получится только при глубоком знании контекста. Можно встретить посты об апгрейдах VSCode и найм в Anaconda.

Создатели библиотек, фреймворков

6. Kenneth Reitz (@kennethreitz) — автор requests, pipenv и других проектов. Помимо новостей о своих проектах здорово шутит на тему “реальность разработчика”.

7. Wes McKinney (@wesmckinn) — автор pandas, одного из основных инструментов для анализа данных в Python. Вовлекся в интересный проект Astral –  набор высокопроизводительных питонических утилит. Посмотрим, станет ли это новым маст-хэвом.

8. Yury Selivanov (@1st1) — активный контрибьютор Python и автор библиотеки uvloop (для асинхронного исполнения кода). Подбирает доступные новичку репосты об изменениях в PEP, горит аналогом asyncio (поддержка параллелизма) – uvloop.

9. Adrian Holovaty (@adrianholovaty) — со-основатель Django. Также перешел с Twitter на Mastodon. Обладает широким спектром интересов, среди которых заметно выделяется машинное обучение.

10. Armin Ronacher (@mitsuhiko) — автор Flask и Jinja2. Вот такие твиты новичку будут более-менее понятны. Армин занял активную позицию и постит о множестве питонических вопросов, от двухфакторной авторизации для PyPI до собственного экспериментального проекта rye-up.com – некой производной pip, облегчающей установку зависимостей и обновляющей виртуальные среды. Интересно дождаться, когда же это выйдет в прод.

11. Tom Christie (@_tomchristie) — автор Django REST Framework и Starlette. Эта культовая фигура явно любит воспринимать мир визуально, потому у него так много потрясающих изображений на самые разные темы, от аниме до произведений современного искусства.

12. Andrew Godwin (@andrewgodwin) — разработчик Django, автор South и Django Channels. Отказался от Twitter и перешел на aeracode.org. По большей части реагирует на громкие события мира IT, такие как массовое увольнение сотрудников Элоном Маском.

13. Ned Batchelder (@nedbat) — автор coverage.py (утилиты для поиска неисполненного в файле кода) и активный участник Python сообщества. Отказался от Twitter в связи с манипуляциями общественным мнением и перешел на hachyderm.io. Там вовсю пишет о еще одном своем именитом проекте edx.com: там возможно даже податься к Неду в найм.

14. Emily Morehouse (@emilyemorehouse) – директор по разработке продуктов в компании Cuttlesoft, активный контрибьютор axios (HTTP-клиент для Node.js). Празднует двадцатилетие конференции Pycon, уютно делится семейными новостями.

Авторы книг и другие коммиттеры

15. Luciano Ramalho (@ramalhoorg) — автор книги «Fluent Python». Да уж, ум у Рамальо действительно “вместительный”: в его твиттере подборка ретвитов на самые разнообразные темы, от JavaScript, игры с копибарами и до обрезки Моны Лизы по краям. Воистину, эклектика в IT редко бывает так уместна.

16. Carrie Anne Philbin (@MissPhilbin) — автор книги «Adventures in Raspberry Pi» и бывшая сотрудница Raspberry Pi Foundation (компания производит одноплатные компьютеры с возможностью вывода на экран). Сейчас активно развивает “Институт воображения” – школу IT-дисциплин вроде робототехники. Здесь легко также почерпнуть поддержки разработчицам #STEMHerStory

17. Alex Martelli (@aleaxit) — автор книги «Python in a Nutshell» и «Uber Tech Lead». Новичкам его стиль может показаться “тяжелым”. Алекс часто пишет о тонких нюансах Python и проектах, в которых принимает участие, так что без плотной “слежки” за этой культовой персоной читать его твиты тяжело.

18. David Beazley (@dabeaz) — автор книги «Python Essential Reference» и популярный преподаватель Python. Помимо прочего рекламирует свои курсы по продвинутому Python за $1500.

19. Jake VanderPlas (@jakevdp) — известный в сообществе науки о данных, автор «Python Data Science Handbook».

Пост о новой либе ml_dtypes под авторством Вандерпласа, прижившейся в сразу нескольких ML-фреймворках вроде Tensorflow

20. Katie Bouman (@katiebouman_AN) — известна своими исследованиями в области компьютерного зрения и машинного обучения. Тут без знания испанского или встроенного автоперевода страницы, к сожалению, не обойтись. В этой хрупкой, на первый взгляд, девушке сокрыта сила настоящего джедая: столько поддержки женщин в IT я не видела больше нигде.

Спустя семь лет после начала работы с Python я наконец научилась “видеть лес среди деревьев”, то есть организовывать свой код так, чтобы больше соответствовать стандартам и в конечном итоге выжимать из более короткого пайтона больше. Но свой код идеальным не назову, пожалуй, никогда.

А сколько времени у вас ушло на то, чтобы ощутить привыкание к дебаггингу и получить чувство, что большинство задач можно декомпозировать до простых и в конечном итоге не бояться никаких проектов?

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

Выбор странного названия “Х” связан с тем, что в апреле Twitter был переоформлен на компанию Илона Маска X Corp.

В 1999 году Маск был одним из разработчиков онлайн-банка X.com, который позже переименовали в PayPal. В 2022 году его выкупила eBay.

Ещё до покупки Twitter Илон Маск признавался, что покупает соцсеть для превращения её во что-то большее под брендом “Х”.

The Wall Street Journal пишет, что переговоры о позиции CEO Twitter ведут с топ-менеджером американской массмедийной компании NBCUniversal Линдой Яккарино. Яккарино работает в NBCU больше десяти лет. Среди ее заслуг — запуск стримингового сервиса Peacock с поддержкой рекламы.

У Insider другие данные. Там говорят, что у Маска есть ещё один вариант на замену. Им может быть Элла Ирвин, которая работает в Twitter меньше года и занимается вопросами «доверия и безопасности».

И хотя причину ухода Маск пока не назвал, до этого он говорил, что руководство компанией Twitter «отнюдь не вечеринка», а скорее «крайне болезненный процесс».

К тому же, новость про нового CEO успокоит инвесторов Tesla. Последнее время акции компаний Маска сильно штормило из-за решений, принимаемых по Twitter.

Как сообщается в официальном блоге Twitter, программа получила название Super Follows и представляет собой новый способ заработка для блогеров.

Что такое Super Follows

Super Follows – это функция, которая позволит пользователям Twitter оплачивать контент любимых блогеров. Для последних это станет дополнительным источником дохода.

Функция Super Follows позволяет блогерам создавать платные подписки на эксклюзивный контент для своих подписчиков.

Если подписчик хочет получить доступ к эксклюзивному контенту, он должен оплатить подписку. Цена подписки может меняться в зависимости от блогера и контента.

По информации Twitter, платить можно будет кредитной картой, PayPal или Apple Pay.

Кто может использовать Super Follows

Пока Super Follows доступна только для тех пользователей Twitter, у которых больше 10 000 подписчиков и как минимум 25 постов.

Чтобы попасть в список ожидания прямо сейчас, вам необходимо иметь 10К или более подписчиков, быть не моложе 18 лет, написать в Твиттере 25 раз за последние 30 дней, находиться в США.

Twitter обещает сделать функцию доступной для всех позже, но точные даты не сообщаются.

Тогда Маск вызвал к себе на ковёр главного инженера соцсети. Тот предположил, что интерес к Маску просто упал. Ну, и Маск просто уволил инженера.

Теперь же пользователи сообщают, что платформа начала активно рекомендовать твиты Илона Маска — вкладка «Для вас» почти полностью состоит из его твитов и ответов.

А Маск написал, что проблема решена.

Пофиксили, получается. ¯\_(ツ)_/¯

В смысле, сам Internal Tech iails не занимается взломами электронных почт. Все переписки уже были слиты, а сайт всего лишь отбирает самые интересные сообщения и публикует их.

Теперь пользователи могут прочитать, о чём и как, например, общались в Google, когда только начали планировать покупку YouTube. Или узнать, что отправлял на свою же почту Стив Джобс.

На сайте опубликовано навскидку 30 переписок, но на аккаунт в Twitter уже подписалось больше 300 тысяч человек. Судя по дате регистрации аккаунта, площадка стартовала в мае 2021 года.

Вольно-литературно перевели самые интересные, на наш взгляд, переписки. Пришлось переводить переписки не дословно, потому что англоязычные айтишники слишком любят слово «это» и прочие абстрактные формулировки.

Илон Маск и Джек Дорси ругают Твиттер и думают, как сделать его круче

26 марта 2022 г.

Джек Дорси

Да, нужна новая платформа [вместо нынешнего Twitter]. Она не может быть компанией. Вот почему я ушел.

Илон Маск

Окей.

Илон Маск

Как она должна выглядеть?

Джек Дорси

Я думаю, это должен быть протокол с открытым исходным кодом. Поддерживать протокол должен фонд, который им не владеет, а только продвигает его. Примерно то же сделал Signal.

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

Сделать [соцсеть на основе такого протокола] не сложно, только нужно сделать всё верно, чтобы она была устойчива к тому, что случилось с Twitter.

Илон Маск

Супер интересная идея.

Джек Дорси
Я ушёл из Твиттера в середине мая, а затем полностью выпал из руководства компанией. Теперь я собираюсь [создать децентрализованный протокол] и исправить ошибки. Твиттер начинался как протокол. Он никогда не должен был стать компанией. Это был первородный грех.

Илон Маск
Я хотел бы помочь, если я могу.

Джек Дорси

Я хотел поговорить об этом, потому что вы понимаете важность [децентрализации] и можете оказать неизмеримую помощь. Я изо всех сил старался включить вас в совет [Twitter], но совет отказался. Примерно тогда я и решил, что мне нужно уйти, как бы тяжело это ни было.

Илон Маск

У тебя есть минутка поговорить?

Джек Дорси

Собираюсь на ужин, но могу на минутку.

Джек Дорси

Я думаю, главная причина в том, что совет директоров просто очень не склонен к рискам, а добавление вас в члены совета — это как раз дополнительный риск.

Такая точка зрения кажется мне глупой, но у меня был только один голос и 3% компании, и у меня нет акций двойного класса.

Мы можем обсудить больше.

Илон Маск

Обязательно обсудим.

Илон Маск

Я думаю, стоит направить Twitter в лучшую сторону и сделать что-то новое, децентрализованное.

Джек Дорси
Это, пожалуй, лучший вариант. У меня есть сомнения, но я открыт к [дискуссии].

Google оценивает стоимость YouTube

07.02.06 Эрик Шмидт написал:

Могу ли я получить быструю оценку стоимости YouTube?

От: Салман Улла
Отправлено: 8 февраля 2006 г., 9:19
Кому: Эрик Шмидт
Копия: Дэвид Драммонд; Питер Чейн; Шон Демпси
Тема: Re: ютуб

Основываясь на обсуждениях Шона с ними [YouTube] и их VC (Sequoia), мы думаем, что он будет стоить около 50 миллионов долларов.

08.02.06 Эрик Шмидт написал:

Продолжаем?

От: Ларри Пейдж
Кому: Эрик Шмидт
Отправлено: Ср, 8 фев 2006 13:13:40 -0800
Тема: Re: FW: ютуб
Копия: [УДАЛЕНО], Сергей Брин

Идея не кажется мне сумасшедшей…

08.02.06 Эрик Шмидт написал:

Пожалуйста, придите на встречу с YouTube, чтобы обсудить предложение от Google по покупке.

Меня очень беспокоит зависимость YouTube от авторского права. Ещё мы должны выстроить их рост и т. д.

Наша основная цель — заполучить всю команду и лидерство [в ней]… Нам понадобится гораздо больше сил, чтобы добиться всего, чего мы хотим.

После того, как вы встретитесь, пожалуйста, озвучьте мне шансы, цену и т. д., и тогда я поговорю с Морицем.

От: Шон Демпси
Отправлено: 13 февраля 2006 г., 12:54.
Кому: Эрик Шмидт
Копия: Салман Улла; Дэвид Драммонд; Ларри Пейдж; Сергей Брин
Тема: Re: ютуб

Я разговаривал с YouTube в пятницу, на выходных и сегодня утром. Они хотят около 500 миллионов долларов, что-то в духе «сделки с Myspace».

Мы планировали встретиться лично этим утром, но когда я предложил цену до 200 миллионов долларов, чтобы проверить, было ли сравнение с Myspace реальным, они заявили, что встречи не будет.

Видимо, решение было принято советом из трех человек, в который входят [УДАЛЕНО], [УДАЛЕНО] и ещё один советник. Мы считаем, что основатели владеют > 50% компании.

Они очень оптимистичны в отношении будущего YouTube. Они также предлагают нам совместную работу в коммерческих целях, о чем мы их и просили.

От: Эрик Шмидт
Кому: Шон Демпси
Копии: Салман Улла, Дэвид Драммонд, Сергей Брин
Тема: RE: ютуб
Отправлено: Пн, 13 фев 2006 16:17:50

Спасибо. Пожалуйста, найдите способ достичь их видения площадки. Мы не будем настаивать на приобретении…

Стив Джобс декадентствует, размышляя о жизни в письмах самому себе

От: Стив Джобс
Кому: Стив Джобс
Дата: четверг, 2 сентября 2010 г., 23:08.

Я выращиваю лишь немного еды, которую ем. Но я не выращивал и не совершенствовал семена, из которых я выращиваю еду.

Я не шью себе одежду.

Я говорю на языке, который я не изобретал и не совершенствовал.

Я не открывал математику, которой пользуюсь.

Меня защищают свободы и законы, которые придумал и издал не я. Я не принимаю законы и не выношу решений.

Меня вдохновляет музыка, которую написал не я.

Когда мне нужна была медицинская помощь, я был беспомощен, чтобы помочь себе выжить.

Я не изобретал транзистор, микропроцессор, объектно-ориентированное программирование или большинство других технологий, с которыми я работаю.

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

Отправлено с моего iPad.

Билл Гейтс переживает из-за растущей популярности Java и кросс-платформенной разработки

Билл Гейтс

Я очень беспокоюсь о том, насколько замечательны Java/Javabeans. Вся выполняемая ими работа вызывает восхищение. Я буквально не могу спать, потому что мне кажется, что с переходом на серверные приложения людям будет проще создавать конкурентоспособные операционные системы.

Мне очень интересно узнать ваши мысли по этому поводу. Какие у нас есть средства защиты от этого? Я не нашёл их достаточно, чтобы расслабиться. Это подрывает мою креативность.

Натан Мирвольд

Я согласен, что это дилемма, но я не думаю, что она настолько серьезна, чтобы не спать из-за неё. Вот несколько мыслей по этому поводу.

Риск того, что Sun действительно отнимет у нас франшизу на ОС, гораздо ниже, чем риск того, что они обесценят весь бизнес.

Максимум, они сделают Интернет полностью независимым от ОС, но есть и другие вещи, которые возвышают одну платформу над другой.

Пока что Java-приложения не представляют серьезной угрозы традиционному ПО для ПК. Это безумно — думать, что они есть.

Посмотрите на конкуренцию между мейнфреймами и ПК. Нам потребовалось ДВА ДЕСЯТИЛЕТИЯ, однако IBM по-прежнему получает миллиардные доходы от мейнфреймов.

Крутые новые технологии всегда быстро распространяются.. Эксперты постоянно говорят, что новые технологии убьют старый бизнес — но, в конце концов, это происходит медленно.

Это не значит, что Java не важна. Она ОЧЕНЬ важна (только не теряйте сон!). Я просто думаю, что вы фокусируетесь не на тех видах угроз. Нет никакого прямого нападения на наш основной актив.

Очевидные вещи, которые нужно сделать:

1. Предоставить собственные средства улучшения веб-страниц.

2. Найти способы выхода на новый рынок. Черт, посмотрите на Netscape и Sun — у каждого есть интересный актив, и они всё ещё находятся в РАННИХ стадиях развития. Будут и другие важные технологии, и мы должны попытаться овладеть ими, даже если они совершенно другого направления.

— Виртуальные миры могут быть такой штукой.

— Новые способы выполнения серверных приложений или выполнения сетевых транзакций (а-ля Viper).

3. Продолжать инвестировать в наши основные бизнес-активы — в данном случае в Windows. 99% мирового дохода от ПО по-прежнему основаны на приложениях для Windows.

ОДНАКО при этом мы НЕ ДОЛЖНЫ позволять Windows проигрывать в других направлениях, важных для пользователей ОС.

— Нам нужно быть ЛИДЕРОМ в области мультимедиа, а значит, делать очень крутые аудио и видео. У нас должна быть лучшая платформа для игр (лучше, чем Ultra64 или Playstation). Мы должны стать лучшей платформой для создания графики/видео/аудио (лучше, чем SGI или Mac).

— ПК должны включаться мгновенно. Они должны быть настраивать и диагностировать себя сами. ПК должен быть максимально удобным для пользователя.

Я обеспокоен тем, что мы делаем мало в этой области, потому что слишком много внимания уделяем Интернету.

Внести эти изменения и сохранить жизнеспособность платформы — большая проблема. Аналогия с Apple пугает. Они потратили весь свой творческий потенциал на вещи, не относящиеся к Mac (Kaleida, Sweet Pea/Pippin, Taligent, Newton…), а свою команду они связали с технологическим переходом к Power PC.

Не знаю, удалось ли мне успокоить вас. Java — это серьезная проблема, но у нас больше вариантов, чем вы думаете. Особенно с пунктами 2 и 3 выше.

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

Надеемся, однажды мы найдём на сайте переписки читателей Tproger — таких же гениальных и успешных, как Илон Маск или Стив Джобс. ?

Экспертом оказался глава некоммерческой организации «Цифровые платформы» Арсений Щельцин, которого в 2013 году подозревали в создании системы рассылки политического спама.

Советы специалиста оказались для многих очевидными

Лайфхак, который предложил эксперт в сфере IT-технологий читателям, — использовать USB-кабель для передачи данных.

«Если на гаджете доступен встроенный сервис "показать телефон как флешку", то достаточно использовать провод, подсоединив его к компьютеру, и скачать или закачать нужные файлы», — Арсений Щельцин.

Пользователи интернета нашли ещё несколько очевидных советов от Арсения Щельцина. Эксперт рекомендует оцифровывать фотографии с помощью приложений для оцифровки фотографий, отключать интернет на телефоне, чтобы экономить батерею и расход трафика, и объясняет разницу между режимами «без звука» и «не беспокоить».

В интернете специалиста засмеяли

Целевая аудитория таких советов — явно не продвинутые пользователи интернета. Но юзеров такие лайфхаки позабавили, и они начали над ними смеяться в Twitter:

IT-отдел. Вы пробовали выключить и снова включить компьютер?

Очевидность советов смутила не только продвинутых пользователей Twitter, но и целевую аудиторию — читателей «РИА Новостей»:

Источник: TJournal

Обложка: Арсений Щельгин

AirTag — это новый продукт Apple, который позволяет найти потерянные вещи. Такую метку можно прикрепить ключам или к телефону. Но люди находят применения поинтереснее.

Как всё было

«На прошлой неделе у меня украли электросамокат. Но воры не знали, что в нём были спрятаны две метки AirTag. Сегодня я с помощью приложения Find My Network и UWB смог вернуть себе самокат».

Самокат украли в ночь с воскресенья на понедельник, пишет Дэн. Он пошёл на ужин в ресторан и прицепил скутер к решётке с помощью наручников для мотоциклов. По невнимательности Гвидо забыл застегнуть одну манжету, и через два часа самокат исчез.

Предусмотрительный Дэн по счастливой случайности заранее спрятал два AirTag в электросамокат: один в колесо, а второй, более тонкий, в рулевой хомут. Сами метки Гвидо перевязал чёрной изолентой, чтобы их не было видно на чёрном скутере.

Сигнал от AirTag привёл хозяина к магазину электросамокатов. Угонщик привёз его туда — видимо, чтобы перепродать.

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

Какие трудности встретились

Полиция Нью-Йорка не очень охотно помогала Гвидо: офицеры не были знакомы с новинкой AirTag, поэтому поначалу подозревали самого Дэна. Они думали, что он хотел украсть самокат из магазина.

Но всё разрешилось: хозяин смог доказать, что это его скутер. Он подал звук на AirTag со смартфона и смог подключить самокат к приложению Ninebot.

Функция защиты от преследования могла в любой момент отключить Гвидо от этих AirTag. Apple предусмотрела, что метки могут использовать для слежки за человеком, поэтому спустя какое-то время перестаёт передавать с них сигнал.

Дэну нужно было уехать из Нью-Йорка в командировку, и он боялся, что за это время сработает функция защиты от преследования. Но спустя неделю сигнал всё ещё можно было отследить.

Как использовать AirTag для возврата вещей

Дэн Гвидо составил 4 совета по итогам своей истории:

1. Используйте клейкие чехлы для меток, чтобы их можно было незаметно прикрепить к вещи.
2. Не включайте режим пропажи. Иначе вор моментально узнает, что его ищут.
3. Действуйте быстро, пока не сработала функция защиты от преследования.
4. Сократите личное общение с ворами и всегда зовите на помощь полицию. Не пытайтесь вернуть вещь без «подкрепления».

Источник: Twitter

Обложка: 9to5Mac

На днях Twitter объявила победителя соревнования. Им оказался украинец Богдан  Кулинич, который сейчас работает исследователем в швейцарской Политехнической школе Лозанне.

До Швейцарии Богда Кулинич закончил украинскую Киево-могилянскую академию, а затем стажировался в Google.

Украинский исследователь обнаружил, что алгоритм smart crop предпочитает не только людей с более светлой кожей людям с тёмным оттенком. Оказалось, что ИИ предпочитает более молодые лица с гладкой кожей и тёплым тоном.

Алгоритм предпочитает типовые качества и может совсем исключить из рассмотрения обладателей нестандартной внешности. Например, ИИ больше по нраву более женственные девушки.

Кулинич выяснил это благодаря сравнению «значимости» для алгоритма smart crop оригинальной фотографии человеческого лица и наборов её же вариацией с немного изменёнными чертами, который создал искусственный интеллект.

Источник: CNet

Вечером 4 августа CEO Xsolla Александр Агапитов провёл пресс-конференцию, на которой подробнее рассказал о случившимся.

Комментарий для Forbes

Изданию Forbes он заявил, что уволил людей, «которые ничего не делали», и что после их сокращения «ничего не изменится».

Основатель Xsolla также подробнее рассказал о том, на основе каких данных уволил  сотрудников:

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

Как оказалось, среди уволенных были два баристы и двое хостес. Их вовлечённость тоже анализировали на основе активности в Confluence.

Александр также заявил, что из компании уволят не всех 147 человек. 60 из них, скорее всего, останутся после разговора с менеджерами. Остальным выплатят компенсацию в 4–6 окладов и оставят им медицинскую страховку.

Комментарий для TJournal

Пресс-служба предоставила комментарий Александра Агапитова и изданию TJournal. Глава Xsolla поделился, что «компании всегда необходимо быть в движении, чтобы выжить — для этого приходится принимать непопулярные меры».

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

Комментарий в Facebook

В соцсетях Александр Агатипов был менее сдержан в комментировании истории с увольнениями.

У себя в Facebook он написал следующее:

Там же, в Facebook, основатель Xsolla написал, что ищет «вовлечённого» пиарщика в России:

Источник: Forbes, TJournal, The Edinorog 

Что случилось

Глава компании Xsolla Александр Агапитов уволил 150 человек, потому что команда биг дата сочла их «невовлечёнными» и «малопродуктивными».

Такие выводы команда сделала на основе анализа активности сотрудников в рабочих сервисах и чатах: Jira, Confluence, Google Почта, Google Документы и так далее.

Всем уволенным сотрудникам CEO разослал вот такое письмо:

Как отреагировал интернет

Пользователи Twitter недовольны. Им не понравилась ни сама идея увольнять сотрудников с помощью биг даты, ни то, как написано письмо.

Особенно пользователей возмутило, что в вакансиях на hh.ru компания обещала, что будет платить не за количество отработанных часов, а за результат:

Xsolla разрабатывает платформу для разработчиков игр, которая позволяет автоматически подключить приём платежей.

Стартап работает в 200 странах, годовая выручка составляет 67$ миллионов.

Источник: Twitter

Саму фотографию Бранят быстро подтёр, по интернет помнит всё. Вот эта картинка:

Что известно о Thunderbolt 5

На изображении видно, что в Thunderbolt 5 скорость передачи данных увеличится до 80 Гбит/с — это в два раза больше, чем в Thunderbolt 3 и 4.

Поддержку USB-C в Thunderbolt 5 оставят.

Ещё известно, что в Thunderbolt 5 применят новую технологию PAM-3, которая предполагает совершенно иной формат передачи битов.

Источник: AnandTech

По словам Twitter, это первое в мире соревнование по выявлению дискриминации людей со стороны машинного обучения.

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

Что надо делать

Задача участников — продемонстрировать, какой потенциальный вред может принести алгоритм «умного кадрирования». Конкурсанты получат доступ к коду модели.

Этот алгоритм распознаёт на картинке главный объект и кадрирует изображение так, чтобы этот объект остался не обрезанным.

Модель должна «непредвзято» находить главный объект. Каждое «предубеждение» — уязвимость.

Сколько заплатят

Команды-победители получат денежные призы через HackerOne:

• 1-е место — 3500$ (256 тысяч рублей);
• 2-е место — 1000$ (73 тысячи рублей);
• 3-е место — 500$ (36 тысяч рублей);
• за самую «инновационную» находку — 1000$ (73 тысячи рублей);
• за проблему, актуальную для большинства алгоритмов Twitter — 1000$ (73 тысячи рублей).

Когда результаты

Победителей объявят на семинаре DEF CON AI Village 8 августа. Победителям предложат представить свои работы на мероприятии.

Где принять участие

Программа запущена на HackerOne. Там же изложены все подробности.

Источник: Блог Twitter

Теперь в Twitter наконец-то появились автоматически сгенерированные субтитры в голосовым твитам. Они появляются, если нажать на кнопку «CC».

Новая возможность доступна только на iOS, поскольку функции голосовых твитов на Android ещё нет.

Функция поможет не только людям с ограниченными возможностями. Голосовые сообщения не всегда удобно слушать — в такие моменты без субтитров не обойтись.

Источник: Endgadget

Компания Microsoft пообещала вернуть в Windows легендарную скрепку-помощника по имени Скрепыш (Clippy). Для этого Microsoft попросила набрать 20 тысяч лайков на этом посте в Twitter — сейчас там уже больше 100 тысяч лайков.

Где появится Скрепыш

Если Microsoft исполнит своё обещание, Скрепыш появится в качестве эмоджи в Windows 365 — облачная версия винды, которую компания представила вчера. Clippy заменит эмоджи скрепки — ?.

Что за Скрепыш

Скрепыш (в англ. Clippy) —

офисный помощник в Microsoft Office, который давал пользователям советы по использованию приложений пакета. Впервые Скрепыш появился в Office 97 (1999 год) и пропал в 2001 году.

Недавно Microsoft представила ностальгические фоны для Teams — там тоже был Скрепыш.

Смартфон Galaxy Z Fold 3

Будет доступен в белом, чёрном и зеленом цветах.

Смартфон Galaxy Z Flip 3

Здесь цветов будет больше: фиолетовый, черный, золотой и зеленый.

Смартфон Samsung Galaxy S21 FE

Раньше ходили слухи, что этот телефон могут не выпустить. Раз есть рендеры, значит, Galaxy S21 FE уже готов.

Доступные цвета: белый, желто-серый, фиолетовый и черный цвета.

Смарт-часы Samsung Galaxy Watch 4 Classic

В часах сделали вращающуюся лицевую панель и две боковые кнопки с правой стороны. Устройство будет работать на новой ОС, которую Samsung разработала вместе с Google.

Доступные цвета: белый, чёрный, серый.

Смарт-часы Galaxy Watch Active 4

Их ждали на предыдущей конференции с участие Samsung —

Mobile World Congress 2021.

Доступные размеры: 40 и 44 мм.

Доступные цвета: серый, темно-зеленый, белый, персиковый и чёрный.

Наушники Galaxy Buds 2

В них ожидают активное шумоподавление.

Доступные цвета: серо-зелёный, пурпурный, белый и зелёный.

Когда официально покажут

В серии твитов Эван Бласс поделился датой — 11 августа. Видимо, новую линейку устройств должны представить именно тогда.

UPD от 27 июля. Samsung подтвердила, что мероприятие Galaxy Unpacked пройдёт 11 августа 2021 года. На нём, скорее всего, покажут все новинки.

Источник: Evan Blass

О возможности создания аппаратного кошелька Дорси писал ещё 4 июня.

Вчера он подтвердил, что Square займётся проектом: «Мы делаем это».

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

Джек Дорси настроен сделать аппаратный кошелёк максимально открытым: от исходного кода до оборудования, которое будут использовать.

Сроки запуска аппаратного кошелька не разглашаются.

Источник: CNet

невзаимозаменяемых токенов (NFT) среди тех, кто отправит реплай на их твит.

Как получить?

Просто ответьте на этот твит. Условия простые, поэтому и получить эти токены шансы маленькие.

Зачем они мне?

Это уникальные токены, каждый который по-своему связан с Twitter. Где-то изображён первый логотип Twitter, где-то — тамагочи с твитом основателя компании Джека Дорси. Для фанатов соцсети — огонь.

Невзаимозаменяемые токены сейчас горячая тема. С начала года в одном только Twitter написали 29 миллионов твитов о NFT. Так что токен можно будет выгодно продать.

Почему 140?

140 — это количество символов, которые вмещается в один твит, визитная карточка Twitter. Токены выпустили в семь серий по 20 NFT.

Источник: TheNextWeb

В марте Twitter обещал, что вскоре позволит использовать секретные ключи в качестве единственного метода двухфакторной авторизации. Теперь такая возможность действительно появилась. Причем как на мобильных устройствах, так и в веб-версии.

Как настроить ключ безопасности

Вот, какую инструкцию даёт Twitter:

1. Чтобы начать настройку, необходимо включить функцию двухфакторной аутентификации с помощью текстового сообщения или приложения для аутентификации.
2. Нажмите Ключ безопасности.
3. При появлении запроса введите свой пароль.
4. Прочитайте общие инструкции, затем нажмите Начать.
5. Вставьте ключ в USB-порт компьютера или синхронизируйте его через Bluetooth или NFC. Вставив ключ, нажмите кнопку на нем.
6. Следуйте приведенным на экране инструкциям, чтобы завершить настройку.
7. Секретный ключ появится в разделе Управление ключами безопасности на странице Двухфакторная аутентификация.

Физический ключ для двухфакторной аутентификации — самый безопасный метод. Другие способы предполагают наличие кода для авторизация, а его могут перехватить злоумышленники.

Источник: Блог Twitter

Речь идёт об XSS, который теперь запрещает публиковать на платформе посты, связанные с вирусами-вымогателями (локерами).

Соответствующее сообщение было опубликовано владельцем форума, скрывающимся под ником admin. Скриншот поста Богуславский опубликовал в своём Twitter-аккаунте:

Одной из причин, по которой руководство площадки решило запретить локеры, является привлечение ими нежелательного внимания. Также admin отметил, что XSS является ресурсом для передачи знаний. В свою очередь целевая аудитория вирусов-вымогателей не преследует цели обучиться чему-то — их единственный интерес это нажива.

Стоит отметить, что реакция на произошедшее не заставила себя ждать. Представители группировки REvil заявили об уходе с форума.

Напомним, что именно это объединение хакеров недавно украло у Apple чертежи грядущих устройств.

Источник: Twitter / Yelisey Boguslavskiy

По данным РКН, с момента искусственного «торможения» соцсети, её руководство удалило около 1900 из 3100 запрещённых материалов. При этом до этого около четырёх лет Twitter игнорировал требования российского ведомства.

Представители регулирующего органа отметили стремление американской компании исправиться. В связи с этим Роскомнадзор не стал блокировать соцсеть, даже несмотря на невыполнение предписаний на 100%. Ожидается, что Twitter доведёт дело до конца в ближайшее время.

Компании дали время до 15 мая 2021 года. Именно до этого момента работа соцсети будет лишь замедлена, а не остановлена.

Источник: Telegram-канал Роскомнадзора

Бьюкенен не стал рассказывать о найденной бреши сотрудникам Twitter. По его словам, несколько лет назад он уже обращался к ним по поводу похожей уязвимости. Но тогда ему ответили, что это не баг безопасности, так как для успешной атаки пользователю необходимо переименовать файл.

Хочу проверить работу такой картинки на себе!

1. Скачайте прикреплённую к посту картинку (нужно скачать именно оригинал 2048х2048 пикселей).
2. Переименуйте формат файла с .PNG на .MP3.
3. Включите трек.

Скачать исходный код инструмента можно на GitHub-аккаунте автора. Там же можно ознакомиться с ограничениями по исходному изображению. Например, вы знали, что все картинки, которые весят больше 3-5 МБ, Twitter автоматически конвертирует в JPG-формат?

Источник: Bleeping Computer

Практически сразу после задержания, парень начал сотрудничать со следствием. Он признал свою вину, после чего его посадили под домашний арест на 229 дней.

В этот период ему было запрещено пользоваться компьютером без специального разрешения и наблюдения со стороны представителя правопорядка.

В общей сложности за решёткой хакер проведёт три года. Вместе с тем его сообщники — Нима Фазели и Мэйсон Шепард — всё ещё ждут решения суда.

Напомним, что череда взломов аккаунтов знаменитостей в Twitter прокатилась в июле 2020 года. Тогда злоумышленники, получившие доступ к страницам, начали публиковать сообщения с призывом удвоить количество биткоинов, отправив их им. В общей сложности Кларк смог заполучить таким образом более 100 тыс долларов.

Источник: The Verge

Производитель софта подал жалобу на пост в Twitter. В нём разместили ссылку на скачивание нелицензионной версии Adobe Acrobat вышедшей 27 лет назад, сообщает TorrentFreak.

Исследователь из F-Secure Микко Хиппёнен опубликовал пять лет назад пост. В нём он дал ссылку на скачивание MS-DOS версии Adobe Acrobat 1.0.

На днях этот же пост ретвитнул написанный специалистом бот, единственной задачей которого является репост публикаций Хиппёнена, которым исполнилось пять лет.

В итоге, из-за жалобы Adobe, Twitter не только удалил сам пост, но и заблокировал бота. Об этом рассказал сам разработчик бота.

Что интересно, оригинальный твит так и остался нетронутым — соцсеть не стала его удалять.

Источник: TorrentFreak

Издание отмечает, что блокировка происходила автоматически. Это может означать, что слово на букву «M» каким-то образом попало в «чёрный список» автоматической системы фильтрации контента Twitter.

Пользователи предположили, что блокировка аккаунтов связана с тем, что футболист Мемфис Депай (Memphis Depay) зарегистрировал своё имя как товарный знак. Но журналисты сразу же отметили, что будь оно так, то пользователи платформы не могли бы использовать и прочие популярные названия (например, Coca-Cola, Apple, Google).

Сама соцсеть никак не прокомментировала случившееся. Она лишь молча, без дополнительного шума, исправила баг. На запрос The Independent представители компании отвечать не стали.

Источник: The Independent

Основой проекта стала элементарная идея: сначала измерять скорость до «замедленного РКН» домена t.co.speed.gulag.link, а затем сравнивать её с показателями скорости до обычного домена speed.gulag.link.

Автор сервиса предлагает обращать внимание на те случаи, когда «замедленный» адрес выдаёт меньше 0,15 Мбит/сек, а обычный — больше 1,5 Мбит/сек. Если же обе скорости больше 1,5 Мбит/сек, то об ограничениях РКН говорить вряд ли приходится.

Протестировать свою машину можно по ссылке. Исходники проекта можно найти на GitHub-аккаунте автора.

Источник: NTC

Оказалось, что ограничивая доступ к сокращателю ссылок Twitter, находящемуся по адресу https://t.co/, ведомство «задело» вообще все доменные имена, содержащие в себе фрагмент «t.co». Об этом написал пользователь Twitter под ником ValdikSS.

В числе пострадавших адресов оказались microsoft.com, pinterest.com, reddit.com и, что иронично, rt.com.

Telegram-канал IT и COPM подметил, что в общей сложности 48 355 хостов из 1 млн самых популярных подпадают под ограничения скорости РКН.

Напомним, что подобная ситуация уже возникала в 2018 году. Тогда регулирующий орган пытался заблокировать Telegram в России. Правда, заблокированными оказались множество сторонних ресурсов, в то время как сам мессенджер продолжал работать с незначительными перебоями. Видимо, Роскомнадзор решил повторить не самый приятный опыт.

Источник: Twitter

Так, по данным РКН, 10 марта 2021 года в сервисе микроблогов всё ещё оставались неудалёнными: 2569 постов с призывами к совершению суицида несовершеннолетними, 450 с детской порнографией и 149 с информацией об использовании наркотиков.

Представители ведомства заявили, что на первом этапе ограничение скорости коснётся 50% компьютеров и 100% мобильных устройств в России. В дальнейшем Роскомнадзор может продолжить увеличивать «давление» на Twitter, вплоть до блокировки сервиса.

Источник: Роскомнадзор

Больше всего внимания привлекала платная подписка Super Follow. Она позволит пользователям получать эксклюзивный контент от интересных аккаунтов. Стоимость платной подписки будет настраиваемой. Однако точные сроки запуска функции Super Follow пока неизвестны.

В Twitter также изучают идею донатов. Руководитель отдела дизайна и исследований Дантли Дэвис (Dantley Davis,) подчеркнул, что такое финансирование является устойчивой моделью стимулирования, которая объединяет интересы создателей и потребителей.

Ещё одна интересная функция, которая может появиться в Twitter, — микросообщества. Пользователям позволят создавать группы по интересам, в которые может вступить любой желающий.

Соцсеть также продолжает работать над безопасностью и чистотой общения. В планах — внедрение функции Safety Mode. Судя по презентации, она автоматически блокирует аккаунты, нарушающие правила Twitter, а также отключает учётные записи, от которых исходит поток негативных отзывов и спама.

Кроме того, сервис предложит пользователям присоединиться к борьбе с распространением дезинформации. Сейчас Twitter автоматически маркирует сообщения, которые вводят в заблуждение. Новая функция Birdwatch позволит участвовать в этом процессе открытому сообществу участников, которое будет коллективно определять, какой контекст и когда нужно добавить к твиту.

Американский интернет-провайдер Your T1 WIFI заблокировал доступ к Facebook и Twitter для своих пользователей, сообщает РИА Новости. Такое решение компания приняла после того, как обе соцсети заблокировали аккаунт президента США Дональда Трампа, передаёт местный телеканал Krem.

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

Мы обратили внимание на то, что Twitter и Facebook занимаются цензурой по отношению к нашим пользователям и к информации… Наша компания не считает, что веб-сайт или социальная сеть имеет право подвергать цензуре то, что вы видите и выкладываете, или скрывать от вас информацию… Мы приняли решение заблокировать эти два сайта.

Что интересно, чуть позже компания пошла на попятную. Так, руководитель Your T1 WIFI Брэтт Финк заявил, что провайдер будет блокировать доступ к Twitter и Facebook лишь по просьбе самих пользователей. От себя же отметим, что оригинальная новость на сайте Krem была скрыта. По какой причине телеканал сделал это — неизвестно.

Источник: РИА Новости

По результатам исследования Россия вошла в пятёрку наименее зависимых стран. Это объяснили наличием собственных сервисов: поисковиков, социальных сетей. Незаменимым пока выглядит только YouTube. Из-за отсутствия прямого конкурента им пользуется 70 % российских пользователей интернета (или 57 % россиян). В Роскомнадзоре отметили, что появление востребованного аналога YouTube снизит зависимость россиян от иностранных интернет-платформ ещё больше.

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

Ранее FTC в рамках другого расследования запрашивала информацию о прошлых приобретениях крупных компаний, включая Alphabet, Amazon, Apple, Facebook и Microsoft. Результатом этого стал иск к Facebook, который требует, чтобы компания продала Instagram и WhatsApp, купленные с нарушением антимонопольного законодательства.

Напомним, что Square занимается разработкой платёжных терминалов, которые можно подключить к смартфонам на Android и iOS. Сами платежи принимаются при помощи мобильного приложения. Основана компания была в 2009 году, практически сразу после первого ухода Дорси с поста руководителя Twitter.