Интересный факт: все это происходит на фоне иска на астрономические $13 трлн, поданного платформой и крупными лейблами к библиотеке.

Что именно выложили

Пользователи Reddit заметили десятки новых раздач — всего 47 торрент-файлов объемом около 6,4 ТБ.

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

Сейчас раздачи идут медленно: у части торрентов всего по одному сидеру.

Важно: опубликованная часть — лишь фрагмент более масштабного архива. Ранее Anna’s Archive заявляла о «скрейпе» порядка 300 ТБ музыки — около 86 млн треков, что якобы покрывает 99,6 % всех композиций на Spotify.

Пока на торренты выложены только наименее популярные композиции с меткой pop_0 — это внутренняя шкала популярности Spotify от 0 до 100.

Отдельно библиотека уже публиковала 200-гигабайтный архив с метаданными — 256 млн треков и 186 млн уникальных ISRC-кодов.

Реакция Spotify и иск на триллионы

Spotify заявила, что выявила и заблокировала аккаунты, использовавшиеся для «незаконного скрейпинга». После этого компания вместе с крупными правообладателями подала иск против неизвестных операторов Anna’s Archive.

Сумма требований — $13 трлн — выглядит как какая-то нереалистичная цифра. Она получена исходя из максимальных компенсаций в США: до $150 000 за каждое предполагаемое нарушение авторских прав. Если умножить эту ставку на миллионы треков, итог и правда уходит в космос.

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

Это конец или только начало

После подачи иска Anna’s Archive временно скрыла раздел, посвященный загрузке музыки со Spotify. Публичных комментариев от проекта с тех пор не было. Однако появление торрентов показывает: процесс публикации, по крайней мере частично, продолжается.

Отдельная проблема для тех, кто теоретически захочет хранить весь архив — банальная физика. 300 ТБ — это десятки жестких дисков. Пользователи уже шутят, что стоимость хранилищ на фоне ИИ-бума делает «пиратство на таком масштабе» дорогим удовольствием.

Новую волну вредоносных Android-приложений обнаружили специалисты Dr.Web.

Как работают «умные» трояны

В основе новой схемы — TensorFlow.js. Это open-source библиотека от Google, которая позволяет запускать модели машинного обучения прямо в JavaScript. Вместо заранее заданных правил, троян анализирует изображение экрана и сам определяет, куда «нажать».

Сценарий выглядит так:

• троян загружает обученную ML-модель с удаленного сервера;
• открывает сайт с рекламой во встроенном скрытом WebView;
• делает скриншоты виртуального экрана;
• модель распознает нужные элементы (кнопки, видео, баннеры);
• вредоносное ПО имитирует реальные действия пользователя.

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

Два режима работы: автономный и ручной

По данным Dr.Web, трояны используют сразу два режима.

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

Signalling-режим. Это уже более опасный вариант, при котором через WebRTC троян транслирует экран виртуального браузера операторам атаки. Злоумышленники могут в реальном времени нажимать, скроллить и вводить текст, управляя устройством удаленно.

Где распространяется вредоносное ПО

Часть зараженных приложений попала даже в Xiaomi GetApps — официальный магазин приложений компании. Схема классическая: сначала на площадку загружается «чистая» игра, а вредоносный функционал появляется позже, через обновление.

Среди выявленных приложений — мобильные игры с десятками тысяч установок. Параллельно трояны активно распространяются через сторонние APK-сайты и «моды» популярных сервисов вроде Spotify и YouTube, а также через Telegram-каналы и Discord-серверы.

Почему это опаснее обычного кликфрода

Формально такие трояны не крадут пароли и не вытаскивают личные данные. Но их скрытность делает их особенно неприятными:

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

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

Что делать пользователям

Рекомендации остаются простыми и банальными, но от этого не менее важными:

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

С ее помощью можно узнать, как именно вы взаимодействовали с сервисом в течение 2025 года. По своей сути, это те же year-end recap, которые уже не первый год предлагают Spotify, Apple Music или YouTube.

Идея простая — превратить сухую статистику в наглядную и немного развлекательную историю о том, как вы использовали ChatGPT.

Что именно показывают итоги

Персональный отчет собирается на основе истории диалогов и памяти ChatGPT.

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

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

Не только цифры, но и немного творчества

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

Также сервис делает несколько предсказаний о том, как может выглядеть ваш 2026 год с точки зрения взаимодействия с ИИ.

Как посмотреть свои итоги года

Чтобы открыть персональные итоги, достаточно написать в ChatGPT фразу: «Show me my year with ChatGPT». Это работает как в веб-версии, так и в мобильном приложении.

Функция доступна пользователям Free, Plus и Pro, но есть важное условие: история чатов и память ChatGPT должны быть включены. Если диалоги не сохранялись, сервису просто не из чего собирать отчет.

Об этом рассказала Фиджи Симо, глава направления приложений в OpenAI.

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

Именно в этих задачах Google пока выигрывает за счет скорости и наглядности. OpenAI намерена это изменить.

Ответы станут визуальными и интерактивными

Одно из главных нововведений — визуальный контекст прямо в ответах ChatGPT.

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

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

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

Конвертеры, курсы валют и спорт — без лишних слов

OpenAI явно целится в самые частые поисковые запросы. В ChatGPT появятся визуальные инструменты для:

• перевода единиц измерения;
• конвертации валют;
• работы с часовыми поясами.

Значения можно будет менять прямо в интерфейсе, как в том же калькуляторе Google. Для спортивных событий ChatGPT начнет показывать счета в реальном времени в визуальном формате, а не просто в виде текстовых ответов.

Редактирование текста и экспорт документов

ChatGPT также станет удобнее как инструмент для написания текстов. Пользователи смогут:

• редактировать текст прямо внутри ответа;
• переключаться в полноэкранный редактор;
• сохранять документы в PDF или Word;
• открывать черновики писем сразу в почтовых приложениях и мессенджерах.

По сути, ChatGPT все больше превращается в универсальное рабочее пространство, а не просто чат.

Экосистема приложений внутри ChatGPT

Отдельный удар по поиску — развитие встроенных приложений.

После запуска партнерских интеграций с Booking, Canva, Figma, Spotify и Zillow, OpenAI подтвердила расширение списка. В ChatGPT появятся Adobe, Airtable, OpenTable, Replit, Salesforce и другие сервисы.

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

Камера Kiss Cam, традиционно выискивающая влюблённые пары среди зрителей, задержалась на Байроне и главе HR-отдела компании Кристин Кэбот. Мгновение нежности — мужчина обнимает женщину — сменилось паникой: Кэбот резко отвернулась, Байрон буквально нырнул вниз, пытаясь скрыться.

Фронтмен Coldplay Крис Мартин тут же прокомментировал: «Либо у них роман, либо они просто очень стеснительные!». Музыкант оказался прав — у парочки действительно был служебный роман, который они скрывали. Этот десятисекундный ролик, мгновенно ставший вирусным в соцсетях, запустил цепную реакцию, которая стоила Байрону карьеры, репутации и брака.

Вирусный баг реальности: как 10-секундное видео обнулило карьеру гендиректора

Уже через 48 часов после концерта совет директоров Astronomer отправил Байрона и Кэбот в отставку и объявил о внутреннем расследовании. Жена Байрона оперативно удалила его фамилию из своего профиля в соцсетях. Пиар-команда Astronomer утонула в запросах СМИ. Вирусный позор мгновенно перешёл из личной в деловую плоскость: всплыли жалобы бывших сотрудников на «токсичный стиль управления» Байрона.

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

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

• Предприниматель MrBeast запустил конкурс: «Выиграй билеты на Coldplay! Отметь босса, но осторожнее с kiss-cam».
• Представители Tesla пошутили в соцсетях: «Фото арендованной Tesla — это как концерт Coldplay. Ваша машина узнает об измене первой».
• Бейсбольный клуб Philadelphia Phillies разыграл пародию с маскотом под музыку Coldplay.

Даже песня Coldplay «Sparks», выпущенная 25 лет назад, взлетела в чартах Spotify, получив вторую жизнь. Появилась мобильная игра «Coldplay Canoodlers», где нужно искать «тайных любовников» в толпе.

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

Цена публичности: почему уход Байрона был неизбежен

Попытки Байрона отшутиться или отрицать роман провалились. Юристы единодушно заявили: судиться с Coldplay бесполезно. Ведущий адвокат США по вопросам развлечений Тре Ловелл пояснил: «Тот факт, что большой экран поймал CEO за чем-то смущающим или аморальным на публике — это проблема самого гендиректора». Художественное использование Kiss Cam защищено законом. У человека на публичном мероприятии не может быть ожидания приватности, если его изображение не используется для прямой коммерции или клеветы.

В России, по словам адвоката Юрия Иванова, ситуация могла бы сложиться иначе: если камера целенаправленно фокусируется на человеке, требуется его согласие на использование изображения. Организатор, даже предупредив о возможной съёмке, не имеет права использовать крупные планы без прямого разрешения. Но в США Байрону оставалось только уйти.

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

История Astronomer — не исключение. Личные провалы и этические сбои регулярно становятся приговором для CEO, в том числе крупных ИТ-компаний. Предлагаем вашему вниманию топ-5 самых скандальных историй с участием бизнес-топов.

1. Брайан Кржанич: роман, который стоил поста гендиректора Intel

В июне 2018 года совет директоров Intel принял отставку CEO Брайана Кржанича после шестимесячного внутреннего расследования. Причиной стал подтверждённый роман с сотрудницей, что нарушало корпоративную политику компании: строгий запрет на отношения «начальник-подчиненный» даже по взаимному согласию. Инцидент признали «злоупотреблением должностью», хотя сам Кржанич настаивал, что отношения были «консенсусными».

Ирония ситуации заключалась в двойных стандартах. Всего за два года до скандала Кржанич публично осуждал гендиректора Foxconn Терри Гоу за роман с подчинённой, заявив: «Лидеры должны быть образцом этики». Расследование также выявило, что Кржанич скрыл факт отношений от юристов Intel при продлении контракта в 2017 году, что усугубило нарушение.

Последствия:

• акции Intel упали в день объявления об отставке;
• Кржанич лишился $45 млн невыплаченных бонусов и акций;
• компания ввела обязательный аудит соблюдения этических норм для топ-менеджмента.

Финал. Скандал стал эталоном корпоративного лицемерия: правила, которые CEO навязывал другим, он сам проигнорировал. Как позже отметил аналитик Bloomberg: «Intel показала — даже звездные результаты (рост выручки на 20% при Кржаниче) не спасают от этического нуля».

2. Илон Маск и «MechaHitler»: ИИ-бунт

Всего за месяц до случая с Байроном чат-бот Grok 4 от компании xAI Илона Маска оказался в центре скандала. Нейросеть генерировала антисемитские высказывания и даже называла себя «MechaHitler» (МехаГитлер).

Расследование показало: модель периодически воспроизводила посты самого Маска из соцсети X по спорным политическим темам, что свидетельствовало о встроенной предвзятости алгоритма. Кто знает, что ещё наговорил бы бот, если бы его вовремя не остановили.

Инцидент привел к судебным искам в Турции и расследованию регуляторов ЕС. Маску пришлось экстренно «перевоспитывать» бота и вводить ограничения на контент.

Что в итоге. Ущерб репутации технологической империи Илона был колоссальным, особенно на фоне усиления регулирования ИИ в ЕС и США. Итог: Этот случай стал хрестоматийным примером того, как личные взгляды основателя, вшитые в ИИ, могут обернуться глобальным кризисом.

3. Тревис Каланик: как токсичная культура уничтожила CEO Uber

Основатель Uber Тревис Каланик построил компанию с оценкой $70 млрд, но его агрессивный стиль управления и пренебрежение этическими нормами привели к серии скандалов, стоивших ему карьеры.

Культура «двигайся быстро и ломай правила», которую Каланик внедрил в Uber, спровоцировала системные проблемы. Например, программа Greyball целенаправленно саботировала работу регуляторов: технология идентифицировала инспекторов, пытавшихся проверить легальность сервиса в новых регионах, и блокировала их доступ к приложению. Руководство оправдывало это борьбой с мошенничеством, но расследование New York Times показало, что инструмент нарушал законы США и других стран.

Кульминацией стал видеоскандал 2017 года: запись, где Каланик грубит водителю Uber, который обвинял компанию в занижении тарифов, стала вирусной. На кадрах CEO кричит: «Некоторые люди не готовы брать ответственность за свои действия! Твои беды — твои проблемы!». Публикация вынудила Каланика признать: «Мне стыдно. Мне нужна помощь в руководстве». Но это была лишь верхушка айсберга.

Годом ранее разразился скандал с сексуальными домогательствами. Бывшая инженер Uber Сьюзан Фаулер описала в блоге токсичную среду: её руководитель в первый же день работы предложил ей секс, а HR-отдел игнорировал жалобы, называя инциденты «единичными случаями». Расследование выявило 215 обращений от сотрудниц — при это по многим из них компания не предприняла никаких действий.

Каланик уволил 20 менеджеров, включая топ-исполнителя Эмиля Майкла, но репутацию это не спасло. Дополнительный удар нанесло расследование Waymo: стартап Илона Маска обвинил Uber в краже 14 тыс. файлов с данными беспилотных технологий. Хотя Каланик отрицал причастность, ключевой инженер Энтони Левандовски был уволен.

Финал истории: в июне 2017 года инвесторы вынудили Каланика уйти. Его уход ускорило увольнение президента Джеффа Джонса, заявившего: «Мои принципы лидерства несовместимы с тем, что я увидел в Uber». Случай Каланика доказал: токсичность на уровне CEO убивает даже технологических гигантов.

4. Элизабет Холмс: как технологическая афера разрушила «кровожадного» единорога

Основательница стартапа Theranos Элизабет Холмс обещала революцию в медицине: сотни анализов по капле крови. Её черная водолазка, намеренно пониженный голос и цитаты Стива Джобса создали культовый образ.

Но к 2015 году расследование Wall Street Journal доказало: запатентованные устройства Edison и MiniLab давали неточные результаты, а компания тайно использовала оборудование Siemens, маскируя провал. Вскрылась системная ложь инвесторам: Холмс заявляла о военном применении технологии в Ираке и партнёрстве с Pfizer, но документы FDA и контракты опровергали это.

Конфликт этики и амбиций стал ключом к краху:

• Холмс запрещала сотрудникам обсуждать проблемы с оборудованием, угрожая увольнениями;
• от пациентов скрывали ошибки в тестах на ВИЧ и онкологию;
• совет директоров, включая генсека США Джеймса Мэттиса, не обладал медицинской экспертизой для проверки заявлений.

В январе 2022 года суд Сан-Хосе признал её виновной в 4 случаях мошенничества против инвесторов, включая семью Дойчеров (владельцев сеть супермаркетов) и медиамагната Руперта Мердока. В ноябре 2022 суд вынес приговор: 11 лет тюрьмы + возмещение $452 млн жертвам аферы.

Парадокс ситуации:

• Theranos достигла оценки $9 млрд при нулевой рабочей технологии;
• Холмс стала самой молодой миллиардершей-самоучкой по версии Forbes (2014);
• инвесторами двигала вера в «нового Джобса», а не due diligence — так называют процедуру комплексной независимой оценки компании по инициативе инвестора.

В настоящий момент технологии Theranos уничтожены, патенты аннулированы, а документальный сериал The Dropout превратил Холмс в символ токсичного стартап-хайпа. Бывший партнёр и COO (главный операционный директор) Санни Балвани получил 13 лет тюрьмы — на год больше, чем Холмс.

Главный урок: даже для CEO, обожествлённого Силиконовой долиной, ложь о продукте смертельна. Инвесторы поверили в историю, а не в технологию. Случай Theranos подтвердил: в отраслях, где ошибка стоит жизни, этика важнее даже самого гениального нарратива.

5. Сэм Банкман-Фрид (FTX): как «эффективный альтруист» стал символом крипто-аферы

Сэм Банкман-Фрид (SBF) — вундеркинд MIT и фанат движения «эффективного альтруизма» — превратил криптобиржу FTX в гиганта с оценкой $32 млрд. Но ноябрь 2022 года стал точкой краха: расследование CoinDesk показало, что хедж-фонд Alameda Research (другая компания SBF) держал 88% активов в токенах FTT, которые сама же FTX и выпустила. Это спровоцировало панику: клиенты вывели $6 млрд за 72 часа, обнаружив $8-миллиардную дыру в счетах.

Что вскрылось:

• FTX тайно выдала Alameda неограниченный кредит из клиентских депозитов;
• деньги тратились на виллы на Багамах ($35 млн за пентхаус с видом на яхты), политические взносы ($100 млн) и спонсорство Mercedes F1;
• в чате мессенджера Signal «People of the House» Банкман-Фрид прямо писал: «Всё оплатит Alameda».

Приговор: в марте 2024 года суд Нью-Йорка вынес вердикт: 25 лет тюрьмы + конфискация $11 млрд. Прокуроры доказали: Сэм знал о преступности схем, но верил в безнаказанность. Судья Льюис Каплан заявил: «Он хотел власти. И использовал для этого воровство».

Мораль: криптоинновации ≠ анархия. Отсутствие аудита (у FTX даже не было CFO, то есть финансового директора) и смешение клиентских/корпоративных средств — путь к катастрофе.

Уроки выживания: как CEO избежать участи Байрона и остальных

Падение Энди Байрона с высоты CEO «единорога» (компании с оценкой в $1 млрд и более) до героя мемов за считанные часы — не просто пикантная история. Это зеркало цифровой эпохи, где приватность уступила место тотальной видимости, а личная репутация стала неразрывна с капитализацией компании.

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

Этика должна быть встроена в ДНК лидерства. Скандалы Байрона, Кржанича и прочих показали: игнорирование моральных норм всегда выходит боком. Личное = профессиональное. Для CEO больше нет границ между частной жизнью и работой. Любые попытки скрыть нарушения лишь усугубляют падение.

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

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

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

Суть цифрового минимализма: философия осознанного потребления

Концепцию цифрового минимализма популяризировал профессор Джорджтаунского университета Кэл Ньюпорт в книге «Цифровой минимализм: Как перестать жить на автомате и вернуть себе концентрацию» (2019). Его основная идея заключается в том, что технологии должны служить человеку, а не подчинять его себе.

Спустя шесть лет проблема стала еще актуальнее. Согласно Digital 2025 Report, среднестатистический пользователь тратит 5,7 часов в день на взаимодействие с цифровыми устройствами, причем 37% этого времени уходит на бессмысленный скроллинг. Это не просто пустая трата времени: нейробиологи доказали, что постоянное переключение между задачами ухудшает когнитивные функции и повышает уровень кортизола, гормона стресса.

Почему цифровой минимализм важен в 2025 году

Есть объективные причины ограничивать потребление цифрового контента:

• Информационная перегрузка. Ежедневно человек сталкивается с тысячами рекламных сообщений, уведомлений и новостных заголовков. Мозг не успевает фильтровать этот поток, что приводит к хронической усталости и снижению концентрации.
• Социальные сети заменяют реальное общение. Исследования показывают, что активные пользователи соцсетей на 30% реже встречаются с друзьями лично, что ведет к эмоциональному выгоранию и чувству одиночества.
• Технологии крадут время. В среднем человек проверяет смартфон 150 раз в день, при этом 60% этих действий не имеют конкретной цели.

Важно! Зависимость формируется на нейробиологическом уровне. Уведомления и лайки активируют систему вознаграждения мозга, схожую с механизмом наркотической зависимости.

Фундаментальные принципы цифрового минимализма

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

Осознанное взаимодействие с технологиями

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

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

• Перед открытием приложения задавайте вопрос: «Зачем я это делаю?»
• Установите временные лимиты для развлекательных сервисов через системные настройки.
• Используйте специализированные устройства для конкретных задач (электронные книги для чтения, камеры для фотосъемки).
• Включите монохромный режим экрана, чтобы снизить визуальную привлекательность интерфейсов.

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

Радикальная оптимизация цифрового пространства

Оптимизация в 2025 году вышла за рамки простого удаления ненужных приложений.

Современные подходы включают:

1. Ревизию подписок и уведомлений. Отпишитесь от рассылок, которые не читаете. Отключите push-уведомления для всех приложений, кроме действительно важных. Используйте функции сортировки входящих (например, «Умный inbox» в Яндекс.Почте).
2. Создание цифровых зон. Рабочий профиль — только профессиональные приложения. Личный профиль — мессенджеры и полезные сервисы. Развлекательный профиль — доступ по расписанию.
3. Автоматизацию рутинных операций. Настройте правила обработки писем (фильтры, шаблоны ответов). Используйте голосовых ассистентов для повторяющихся задач. Включите «умные» ответы в мессенджерах.

Оптимизация — постоянный процесс. Раз в месяц проводите цифровую «уборку».

Полный контроль над цифровой средой

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

Технологии позволяют:

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

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

Как технологии помогают бороться с цифровой зависимостью

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

Приложения для контроля экранного времени

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

Freedom

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

Cold Turkey (Detox Lock)

Более жесткий инструмент. Он не просто блокирует отвлекающие сайты, но и позволяет создавать расписания, исключающие доступ в YouTube или TikTok даже после перезагрузки компьютера. Это особенно полезно для тех, кто работает удаленно и постоянно отвлекается. Аналог для пользователей Андроид из РФ — Detox Lock.

OneSec

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

Автоматизация рутинных задач

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

Superhuman и Spark

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

Focus Mode в iOS и Android

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

ChatGPT-5 и другие голосовые ассистенты

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

Главное правило автоматизации: если действие повторяется чаще двух раз в неделю — его стоит делегировать алгоритмам.

Как создать цифровую среду, которая не отвлекает

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

Визуальная гигиена: монохромный режим и не только

Цветовые схемы современных интерфейсов разрабатывают целые команды нейропсихологов. Яркие оттенки, анимации и контрасты стимулируют выброс дофамина, создавая эффект цифрового фастфуда. Исследование MIT (2023) показало: переход на монохромную палитру снижает время использования смартфона на 22% и уменьшает импульсивные клики.

Но визуальная гигиена — это не только оттенки серого. В 2025 году появились новые инструменты:

• Динамическая регулировка контраста — доступна в последних версиях iOS и Android. Автоматически снижает насыщенность цветов вечером.
• «Текст-режим» в браузерах (например, Mercury Reader) убирает рекламу и оставляет только основной контент.
• Минималистичные лаунчеры (вроде Before Launcher) заменяют иконки приложений на текстовые метки.

Как это работает на практике? После перехода на монохромную тему и текстовый лаунчер юзеры реже открывают телефон «просто посмотреть». Исчезает визуальный мусор — пропадает рефлекс постоянно проверять устройство.

Борьба с цифровыми «ловушками внимания»

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

В Telegram, который стал основной платформой для общения в русскоязычном сегменте, можно настроить режим «Только новые сообщения». Это аналог хронологической ленты — вы видите посты в порядке публикации, без алгоритмического ранжирования. Включается через Настройки → Конфиденциальность → Режим отображения постов.

YouTube теперь предлагает три варианта просмотра:

• стандартный (с рекомендациями);
• только подписки;
• «чистый» режим (поиск по запросу без побочного контента).

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

• рабочая зона: только почта и корпоративные мессенджеры;
• личная зона: звонки и SMS;
• тихая зона: полное отключение всех оповещений.

Возвращение к «аналоговому» цифровому

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

Электронные книги с E-Ink дисплеями (PocketBook, ONYX Boox) теперь поддерживают только базовые функции чтения — без браузеров и соцсетей. По данным ритейлеров, спрос на такие устройства вырос на 40% за последний год.

Умные блокноты (Remarkable 3, Rocketbook) стали популярны среди тех, кто хочет совместить удобство цифровых заметок с фокусом ручного письма. Нейробиологи подтверждают: рукописный текст лучше усваивается и запоминается.

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

• камеры Fujifilm (или аналоги) с ограниченным набором функций;
• MP3-плееры для музыки без стриминговых сервисов;
• электронные словари вместо мобильных приложений.

Пользователи отмечают, что при переходе на камеру Fujifilm X100VI они начинают чаще смотреть по сторонам, а не в экран.

Почему эти методы работают

Нейрофизиологи выделяют три механизма воздействия:

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

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

Долгосрочные стратегии: как не вернуться к цифровому хаосу

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

Плановый цифровой детокс

Исследователи University of Pennsylvania доказали: даже кратковременное воздержание от цифровых устройств перезагружает когнитивные функции. Их рекомендация — 24-часовой детокс раз в месяц. Но как сделать его эффективным?

Подготовку стоит начинать за 2-3 дня. Постепенно сокращайте время в соцсетях, предупредите коллег и близких о временной недоступности. В 2025 году появились специальные сервисы для автоматического ответа на сообщения во время детокса, например, AwayMessage для Telegram.

В день детокса сосредоточьтесь на офлайн-активностях с четкой структурой:

• утренняя прогулка без гаджетов;
• чтение бумажных книг или специализированных e-ink устройств;
• настольные игры или встречи с друзьями.

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

Персонализированные правила цифровой гигиены

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

Вот как это сделать:

• Анализ цифровых привычек. В течение недели фиксируйте: время первого и последнего использования смартфона, частоту бесцельных проверок устройств, приложения, которые забирают больше всего времени.
• Постепенное внедрение ограничений. Начните с малого: первые 30 минут после пробуждения — без гаджетов, обеденный перерыв — без соцсетей, последний час перед сном — в режиме «Не беспокоить».
• Техническая поддержка. Используйте встроенные инструменты: фокус-режимы в iOS/Android, функцию «Цифровое благополучие», приложения для трекинга экранного времени.

Осознанное потребление контента

Алгоритмы предугадывают наши интересы, формируя зависимость. Чтобы не попасть в «пузырь фильтров», нужно сознательно формировать информационную диету.

Современные подкаст-платформы (Яндекс.Музыка, Spotify) предлагают режим «Без рекомендаций» — вы слушаете только выбранные выпуски. Аналогичные функции появились в YouTube («Только подписки») и новостных агрегаторах.

Для профессионального развития выбирайте контент с четкой структурой:

• подкасты с расшифровками (например, «Будет сделано!»);
• образовательные платформы с прогресс-трекингом (Stepik, Coursera);
• телеграм-каналы с аналитикой вместо кликбейта.

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

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

Над цифровой зависимостью можно только смеяться. И это можно сделать в нашем тг-канале!

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

Особенно сильно досталось подписке Pro+, которую недавно продавали как «безлимитную», а теперь в ней всплыло сообщение о 90% израсходованного лимита — при этом точного счётчика или логов использования так и нет.

Что происходит

• Ранний этап: тариф Pro стоил $20 и давал «безлимит» на автодополнение и агентов — без капов и ограничений.
• Потом появились 500 «приоритетных» запросов, после чего начиналась замедленная скорость.
• Далее — переход на плату за перерасход, что ещё можно было принять.
• Позже все лимиты исчезли с описания, но на деле включилась невидимая система ограничений — без счётчиков и таймеров.
• В июле появилось скрытое описание тарифа Pro+ за $60 с обещанием «3× больше запросов, чем в Pro».
• Две недели спустя: всплыло предупреждение об израсходованных 90% лимита и исчезло слово «unlimited» из описания тарифа.
• Одновременно с сайта удалили любые упоминания безлимита даже для Ultra-подписки за $200 в месяц.

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

Почему это проблема

• Никакой метрики: нельзя узнать, сколько запросов осталось или куда они ушли.
• Никакого предупреждения: условия меняются «по-тихому», без уведомлений через e-mail.
• Удаление жалоб: сообщения пользователей исчезают из Discord и Reddit-сообществ Cursor.
• Размытые формулировки: описание «3× лимита» не имеет смысла, если базовый лимит нигде не указан.

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

В отличие от Spotify и Netflix, где это заняло годы, Cursor успел сделать пять итераций за год.

Юридическая сторона

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

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

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

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

Главный трек коллектива — Dust on the Wind — звучит подозрительно похоже на классический хит Dust in the Wind группы Kansas. Его послушали более 380 000 раз с момента релиза 20 июня. А сам коллектив вышел в рекомендации Discover Weekly у части пользователей Spotify.

Однако вскоре слушатели на Reddit начали замечать странности:

• Фотография участников выглядит как сгенерированная ИИ;
• *Instagram-аккаунт — наполнен «неестественными» портретами;
• Цитата из Billboard в описании группы на Spotify не подтверждается никакими источниками;
• Имена участников не находятся ни в одном из поисковиков.

Несмотря на это, ни один музыкальный сервис, кроме Deezer, не пометил The Velvet Sundown как ИИ-контент.

Ни Spotify, ни Apple Music, ни Amazon Music не указывают, что перед нами не настоящая группа — у них пока что нет соответствующего функционала.

Deezer уже борется с ИИ-музыкой

Deezer стала первой платформой, которая начала маркировать ИИ-контент, включая треки, созданные с помощью генеративных моделей вроде Suno и Udio.

По данным сервиса, каждый день на платформу заливается более 20 000 ИИ-песен. В апреле 2024 года они составляли 18% всех загруженных треков — против 10% в январе.

Другой популярный ИИ-проект — The Devil Inside, попавший даже в шоу Джона Оливера Last Week Tonight. Его главный трек Bones in the River набрал 1,6 млн прослушиваний на Spotify, при этом не имеет указания авторов.

Только на Deezer он помечен как сгенерированный и приписан венгерскому музыканту Ласло Тамаши.

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

Музыкальные сервисы пока не спешат регулировать ИИ-контент, а вопрос об авторском праве на такие треки остается открытым.

Компании вроде Suno и Udio утверждают, что обучение моделей на защищенной музыке попадает под «добросовестное использование» (fair use), но звукозаписывающие лейблы подают в суд.

По словам главы Deezer, ИИ не является «хорошим или плохим» — все зависит от прозрачности и уважения к авторам. Но пока даже самые популярные платформы вроде Spotify и Apple Music не предлагают пользователям ни прозрачности, ни маркировки.

*Компания Meta и ее продукты признаны экстремистскими, их деятельность запрещена на территории РФ

Может плодить новые эндпоинты или заставлять мобилку делать несколько запросов вместо одного? Каждый запрос жрёт трафик и батарею!

Элегантное решение — архитектура Backend for Frontend (BFF). Это прослойка между клиентскими приложениями и основным API, которая адаптирует данные под потребности конкретного клиента.

Основная идея backend for frontend

Один API не может эффективно обслуживать разные типы клиентов. Сайт, приложение для iOS, Android, умные часы — у каждого свои потребности в данных, ограничения по производительности и особенности интерфейса.

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

Следуя архитектуре BFF, вы можете создать логику для каждого типа клиента и не засорять основной API. Вместо одного эндпоинта /api/products, который пытается угодить всем, появляются слои:

• один — оптимизирует данные для веба,
• второй — для мобильных устройств,
• третий — для умных часов.

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

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

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

«Можете добавить поле user_avatar в ответ?»

— «Это сломает мобилку».

«Тогда сделайте отдельный эндпоинт».

— «У нас нет времени».

С BFF этого диалога нет. Фронтенд-команда получает свой API и крутит его, как хочет.

Мобильное приложение съедает 10к запросов в секунду? Пишите BFF на Go. Веб-версию делает стажёр, который знает только JavaScript? Ставьте Node.js. Никто не заставляет выбирать одну технологию на все случаи жизни.

Как работает backend for frontend (BFF)

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

Архитектура взаимодействия

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

Когда мобильное приложение запрашивает список заказов, его BFF делает несколько вызовов к микросервисам:

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

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

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

Обработка и агрегация данных

BFF не просто перекладывает данные из одного формата в другой. Он выполняет бизнес-логику.

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

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

Независимость и масштабирование

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

4 ключевых преимущества BFF

Оптимизация передачи данных

Самое очевидное преимущество — экономия трафика. Приложение не тащит 2 МБ JSON с полным каталогом товаров на мобильное устройство? BFF отдаёт только нужные поля.

Количество запросов тоже сокращается. Например, чтобы показать профиль пользователя, фронтенд делает 5 запросов:

• за основными данными,
• аватаром,
• списком друзей,
• последними постами,
• настройками приватности.

BFF объединяет всё в один запрос, получая данные параллельно от разных сервисов.

Упрощение фронтенда

Половина фронтенд-кода уходит на трансформацию ответов API:

• парсинг дат,
• группировку массивов,
• вычисление производных значений.

BFF может взять эту работу на себя.

Безопасность через изоляцию

BFF создаёт барьер между клиентами и сервисами. Мобильное приложение никогда напрямую не обращается к БД пользователей или платёжке — только через свой BFF.

Можно настроить разные уровни доступа:

• мобильный BFF видит только публичные данные,
• API для партнёров работает в песочнице.

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

Независимое масштабирование

Когда приложение попадает в топ App Store, нагрузка взлетает в разы. Но страдает только мобильный BFF — веб-версия продолжает работать стабильно. Можно быстро поднять дополнительные серверы только для мобильного трафика.

Появляется возможность экспериментировать с технологиями без риска. Хотите попробовать GraphQL для веб-версии? Внедряйте в один BFF. Тестируете новую базу данных? Подключайте к экспериментальной прослойке, не трогая продакшн.

Когда стоит использовать backend for frontend

BFF — инструмент для конкретных ситуаций.

Когда интерфейсы кардинально отличаются

Если ловите себя на мысли: «этот эндпоинт нужен только для веба» или «мобилка использует 10% полей из ответа», — пора задуматься о BFF.

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

Когда интерфейсы эволюционируют быстрее джунов

Стартапы и продукты в активной фазе развития меняют интерфейсы каждую неделю.

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

Без BFF это означает изменения в основном API, которые могут сломать другие клиенты. С BFF — правки только в одном месте.

Когда команды работают независимо

Если у вас несколько фронтенд-команд, которые постоянно конфликтуют из-за API, BFF даст им свободу.

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

BFF распределяет ответственность: каждая команда поддерживает свой слой.

Когда НЕ стоит использовать BFF

Если у вас простое приложение с одним клиентом, BFF добавит лишнюю сложность. Если API уже идеально подходит всем клиентам, зачем что-то менять?

3 типичные ошибки при внедрении BFF

Дублирование логики

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

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

Избыточная сложность вместо упрощения

Пример: команда создаёт «универсальный BFF-фреймворк» с конфигурацией через YAML, поддержкой плагинов и собственным DSL. В итоге простое добавление поля в ответ требует изучения документации на 50 страниц.

Другая крайность — микро-BFF для каждой мелочи. Отдельный слой для авторизации, отдельный для форматирования дат, отдельный для валидации.

Неправильная гранулярность

Один BFF на все мобильные платформы может быть слишком общим: iOS и Android имеют разные особенности интерфейса. Но отдельный BFF для каждой версии приложения — явный перебор.

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

Практические примеры использования BFF

Netflix

Компания сделала разные API для веб-версии, мобильных приложений, Smart TV и игровых консолей. Каждый BFF оптимизирован под особенности устройства, например, TV-версия предзагружает больше контента из-за медленной навигации пультом.

Spotify

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

SoundCloud

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

Заключение

Страдают все, когда один API пытается обслуживать веб-версию, мобилки и что-то ещё. Фронтенд получает неудобные данные, бэкенд обрастает костылями, пользователи — медленными приложениями.

Backend for Frontend создаёт слой между клиентами и основными сервисами. Каждый тип устройства получает API, заточенный под его потребности.

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

Ты уже программист, если читаешь это! Больше про кодинг — здесь.

*Зарплаты указываем в год до уплаты налогов, в долларах США, чтобы было проще. Курс валют — по состоянию на май 2025 года.

Россия

Зарплаты в российском IT сильно зависят от региона, компании и направления. В среднем junior-разработчики получают от $9 500 в год — примерно $800 в месяц. Middle — около $22 800 в год или $1 900 в месяц, а Senior — от $40 000 в год и выше.

Отдельно стоит отметить DevOps-специалистов и аналитиков данных — их доходы на 10–20% выше, чем у разработчиков на тех же грейдах. Если у миддла-бэкендера годовая зарплата составляет $23 000, то DevOps или data scientist может зарабатывать от $25 000 до $28 000 — особенно в крупных компаниях, финтехе или инфраструктурных проектах.

Что касается трат:

• Аренда: студия в Москве обойдётся от $650–750 в месяц, не в центре и без вида на Москва-Сити. Чаще всего это обычный дом с окнами во двор или на соседний проспект.
• Транспорт: поездка в метро стоит $0.6, каршеринг — $5−7 за поездку из окраины в центр, если не стоять в пробках по часу. Шеринг удобнее и дешевле такси, когда умеешь парковаться. Расходы на бензин — примерно $0.75 за литр 95-ого.
• Питание: обед в кафе — $10-15, фастфуд — от $3.
• Хобби: спортзал — от $30 в месяц, настолки — бесплатно, если друзья не жадничают.
• Медицина: формально — бесплатно по ОМС, но с очередью на месяц к узким специалистам. В реальности многие пользуются ДМС от работодателя.
• Соцзащита: отпуск по ТК, декрет, субсидированные детсады — всё это работает, особенно в крупных городах.

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

Я, наверное, не самый типичный айтишник — не живу по полгода в тёплых странах, а рестораны уже перерос. Работаю удалённо из Красноярска, зарабатываю около 3 млн рублей в год. Этого хватает на ипотеку, хобби и дальние поездки на машине. С семьёй любим путешествовать по России — были на Байкале, в Бурятии, на Алтае. Работа стабильная, требует внимания и постоянного роста. В свободное время занимаюсь тайским боксом, собираюсь этим летом попробовать стендовую стрельбу и парусный спорт. Живём в частном доме за городом, так что дел хватает и по хозяйству, и с детьми — у нас их двое. А в прошлом году поступил в Политех на заочку.

США

В американском IT уровень дохода сильно зависит от штата, компании и направления. В среднем цифры следующие: Junior-разработчики зарабатывают от $80 000 в год, middle — около $120 000, а senior — от $150 000. Специалисты в DevOps и Data Science получают от $130 000 до $160 000, особенно если работают в крупных технологических компаниях: FAANG и аналогах.

Теперь — о жизни и расходах:

• Аренда: студия в Сан-Франциско обойдётся в $2 800–3 500 в месяц, и это без вида на мост. В Нью-Йорке — не дешевле.
• Транспорт: личная машина — почти необходимость, особенно за пределами крупных городов. Бензин стоит около $1 за литр, страховка и обслуживание — ещё пара сотен в месяц.
• Еда: чашка кофе — $5, бургер — $15, полноценный обед — $25 и выше.
• Хобби: абонемент в спортзал — от $50, подписки на Netflix и Spotify — $70+ в месяц, занятия вейкбордингом или сёрфингом — от $100 за уикенд.
• Медицина: страховка — почти обязательна, стоит $400–600 в месяц, без неё любая простуда превращается в финансовую катастрофу.
• Соцзащита: частные компании дают отпуск по 10–15 рабочих дней, не везде предусмотрены оплачиваемые больничные.

Даже на позициях сеньора жить одному в центре города — дорого. Многие арендуют жильё с соседями или уезжают в пригороды, где цены ниже, но без машины уже не обойтись. IT даёт возможность быстро расти в доходах, особенно в стартапах или FAANG, но и конкуренция — как на драфте в NBA.

Работаю в команде, которая развивает AI-сервисы для терминала Bloomberg — системы, которой пользуются финансисты и госструктуры по всему миру. Мы делаем что-то вроде встроенного голосового ассистента, способного анализировать биржевые и новостные данные. Я хожу в офис 4 дня в неделю — так проще держать ритм. День проходит между кодом, митингами и кофе. В свободное время стараюсь выжать максимум из Нью-Йорка: волейбол, теннис, пробежки в Центральном парке, театр, джаз-клубы и нескончаемый ремонт квартиры. Летом почти каждые выходные — выезды за город. Социально влиться в Нью-Йорк несложно: тут очень много мигрантов и разных культур. Хотя иногда интроверт во мне побеждает — и тогда я с радостью остаюсь дома с женихом.

Германия

IT-специалисты получают умеренные по западным меркам зарплаты, но выигрывают за счёт социальной защиты и предсказуемого качества жизни. Junior-разработчик зарабатывает около $50 000 в год, middle — около $65 000, а senior — от $90 000. Специалисты в DevOps и Data Science в крупных городах вроде Берлина или Мюнхена могут получать до $100 000–110 000 в год.

Что с расходами:

• Аренда: студия в Берлине обойдётся в среднем от $1 000 в месяц. Цены растут, но пока остаются ниже, чем в США или Великобритании.
• Транспорт: месячный проездной стоит около $65, но многие предпочитают велосипед. Бензин дорогой — почти $2 за литр.
• Еда: буханка хлеба — $2.20, обед в недорогом кафе — $15–25, ужин дома из супермаркета — ощутимо дешевле.
• Хобби: абонемент в фитнес — $35–45 в месяц, а на концерты и выставки часто можно попасть бесплатно или по символической цене.
• Медицина: государственная страховка обходится в около 7% от зарплаты, но почти полностью покрывает услуги — от стоматологии до психотерапии.
• Соцзащита: минимум 30 дней отпуска в год, оплачиваемые больничные с первого дня. Декретный отпуск — до 3 лет, с выплатами до 14 месяцев.

Жизнь в Германии структурирована: middle-разработчик уже может жить один, часто — с балконом и кладовкой. Senior — в двухкомнатной квартире с партнёром и кошкой. Овертаймы — редкость. Если кто-то продолжает переписку в Slack после 18:00, это воспринимается как тревожный звонок, признак неэффективности или выгорания.

Живу в Германии с 2017 года. За это время многое стало привычным, но до сих пор приятно удивляет. Рабочая культура устроена так, что никто не жмёт на газ: овертаймы — редкость, а 30 дней отпуска в году — норма. Люди не соревнуются, кто больше переработал. Быть просто хорошим разработчиком — это ок. Германия удобна и в быту: развитый общественный транспорт, автобаны для любителей машин, зелёные леса, замки, Альпы под боком. А ещё — комфортная среда для жизни: много IT-компаний, доступная инфраструктура, возможность работать супругам и высокий уровень безопасности. Неудивительно, что всё больше айтишников выбирают именно эту страну.

Япония

Разработчики в Японии зарабатывают в среднем:

• джуниоры — около $30 000 в год,
• миддлы — $45 000,
• сеньоры — до $70 000.

Специалисты в DevOps и Data Science могут получать $80 000–90 000, особенно в крупных корпорациях, где создают сервисы на международный рынок.

Расходы на жизнь:

• Аренда в Токио: от $800 за небольшую квартиру; чем ближе к центру — тем выше цена, но и инфраструктура удобнее.
• Транспорт: безлимитный проездной — от $100/мес, метро работает как по расписанию NASA. Бензин — примерно $1.3 за литр. Мигрантам стоит запомнить: в Японии все едут по левой стороне дороги, приоритет у помехи тоже слева.
• Еда: обед в кафе обойдётся в $6–9, ужин в раменной — около $10. Продукты в супермаркетах стоят дороже, чем в других азиатских странах.
• Хобби: повсюду геймерские клубы, общества любителей манги, тематические кафе. Расходы сильно зависят от степени увлечённости.
• Медицина: обязательная страховка равна примерно $100 в месяц и покрывает основное лечение и визиты к врачу.
• Соцзащита: формально надёжная, но важные детали могут быть в трудовом контракте — особенно у иностранцев.

В Японии чисто, безопасно и невероятно удобно жить. Но без японского языка может быть трудно интегрироваться, особенно вне IT-сферы. Дисциплина и уважение к правилам — часть повседневной жизни. Если они вам по душе, Токио может стать вторым домом.

Переезд в Японию оказался проще, чем я ожидал. Виза, жильё, оформление документов — всем занималась компания, даже трансфер из аэропорта организовали. Рабочий язык в офисе — английский, коллеги со всего мира. Квартиру нашли за две недели, на первое время предоставили временное жильё. Оборудование для домашнего офиса — за счёт компании. В быту выручают Google Translate и ChatGPT, с их помощью можно спокойно решать повседневные вопросы. Жизнь здесь удивительно комфортна, если есть поддержка и интерес к культуре.

Великобритания

Разработчики в Великобритании получают в среднем:

• джуниоры — около $45 000 в год,
• миддлы — $65 000,
• сеньоры — до $90 000.

Специалисты в DevOps и Data Science зарабатывают $90 000–110 000, особенно в Лондоне и Эдинбурге, где востребованы кадры для банков, финтеха и стартапов.

Расходы на жизнь

• Аренда в Лондоне: около $2 300 в месяц за однушку в приличном районе. Дешевле — только если снимать комнату или уехать за МКАД… простите, за M25.
• Транспорт: проездной Oyster — от $200 в месяц. Лондонское метро — как музей под землёй: готический интерьер с сюрпризами. Бензин стоит $1.8 за литр, а дорожное движение — левостороннее, как и в Японии.
• Еда: ужин в индийском кафе — $12, пинта пива в пабе — $7, а поход в супермаркет способен сильно удивить — и не всегда приятно.
• Хобби: парки, бесплатные музеи, стендап-клубы, тематические коворкинги и даже кружки настолок — скучать сложно.
• Медицина: государственная система NHS бесплатна, но нужно привыкнуть к очередям и записи к терапевту через две недели.
• Соцзащита: 25+ дней отпуска, стабильные трудовые контракты и работающие профсоюзы.

Зарплаты позволяют комфортно жить, особенно за пределами Лондона. Девопсы и дата-сайентисты — нарасхват. Английский знать нужно, но в отличие от Японии — вы его хотя бы слышали в школе. Карьерный рост возможен, особенно если знаете, чего хотите и умеете себя продать.

Я переехала в Лондон из Польши после восьми офферов и долгой проверки на визу — сам процесс занял почти восемь месяцев. Компания оплатила аренду на первый месяц, помогла с оформлением визы, а постоянное жильё мы уже искали с учётом школы для ребёнка. Сейчас мы вдвоём с мужем работаем разработчиками. На аренду и еду уходит около 30% дохода. Продукты стоят примерно как в Польше, бытовая химия даже дешевле. В быту и на работе используем английский, и это сильно упрощает адаптацию. Уровень жизни высокий, зарплаты достойные, а IT-комьюнити — очень живое и дружелюбное.

Давайте сравним

Где жить — зависит не только от зарплаты, но и от того, как вы хотите жить. Кто-то хочет в Альпы, кто-то — в аниме-рай, кто-то — чтобы мама могла приехать на выходные. И это нормально.

Но если выбирать по зарплате — вот наглядная таблица с доходами и расходами в месяц.

Заключение

Выбирать страну для релокации сложно, потому что влияет много факторов. Не стоит опираться только на принцип большей зарплаты. $5 000 в Германии и $5 000 в США — это совсем разные уровни жизни. Кто-то готов жертвовать отпуском ради денег, а кто-то предпочитает стабильность и детский сад по госпрограмме. Лавандовый раф тоже влияет.

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

Но правда в том, что это решение подходит далеко не всем компаниям. В 90% ситуаций микросервисная архитектура (она же MSA) — избыточность, а не необходимость. Это не просто сложно, а очень сложно. Микросервисы требуют мощной инфраструктуры, глубоких знаний DevOps, тонкой настройки мониторинга и отказоустойчивости. И самое главное — они редко нужны на старте проекта.

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

Почему все говорят про микросервисы

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

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

Маркетинг на волне хайпа

Разработчики инструментов в этой сфере хорошо зарабатывают на своих продуктах.

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

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

Ориентированность на резюме

Многие разработчики (особенно начинающие) учат микросервисы не потому, что столкнулись с их необходимостью, а потому, что это круто звучит. В итоге в вакансиях пишут «знание Docker/K8s — огромный плюс», а на собеседованиях спрашивают про «опыт работы с распределенными системами», даже если у компании всего лишь сайт-визитка.

Это создает порочный круг:

• новички учат Kubernetes, потому что это востребовано;
• компании требуют Kubernetes, потому что так делают конкуренты;
• в итоге люди тратят месяцы на сложные технологии, которые никогда не применят.

Факт. Несмотря на универсальность микросервисов, далеко не все гиганты перешли на такой формат работы. Например, GitLab и Spotify до сих пор работают на монолитах.

Завышенные ожидания по проекту

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

Что происходит на практике:

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

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

Нужны ли вашему проекту микросервисы

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

Чтобы понять, стоит ли внедрять в ваш проект микросервисы, ответьте на три важных вопроса.

Действительно ли ваш проект настолько масштабен?

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

Сразу проверьте себя:

• Если ваш сервис — это один API, который обслуживает 5 конечных адресов, микросервисы вам не нужны.
• Если вы не можете четко объяснить, какие части системы могут жить автономно (например, платежи без каталога товаров), значит, у вас монолит. И это нормально.

Монолит — низкие начальные затраты, но с ростом кода поддержка становится дороже. Микросервисы — огромные стартовые вложения (DevOps, оркестрация, мониторинг), зато потом система масштабируется с меньшими расходами. Второй вариант выгоднее лишь в том случае, если у вас миллионы пользователей и десятки команд. До этой точки монолит — более целесообразное решение.

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

Действительно ли вам необходимо масштабировать части приложения автономно?

Типичный аргумент за микросервисы: «У нас нагрузка только на платежи, а не на каталог — выгодно масштабировать их по отдельности». На самом деле 99% стартапов никогда не сталкиваются с такой нагрузкой, где это критично. Кроме того, современные облака (AWS, GCP) умеют масштабировать отдельные модули монолита.

Пример. Команда разбила HR-систему на 10 микросервисов. В итоге форма подачи заявок зависела от сервиса сотрудников, который в свою очередь зависел от сервиса отделов. При пиковой нагрузке (раз в месяц) все равно масштабировали все сервисы сразу.

Если вы не Amazon — вам, скорее всего, хватит вертикального масштабирования (+1 сервер) или модульного монолита.

Есть ли у вас услуги, связанные с транзакциями?

В монолите транзакция — это пара строк кода. В микросервисах — сложный квест.

Вот как это выглядит:

1. Платежный сервис списал деньги.
2. Инвентарный сервис не ответил (упал или залагал).
3. Теперь у пользователя списаны деньги, но заказ не создан.

Микросервисы создают проблемы согласованности. В монолите вы обновляете данные одной транзакцией, в MSA это стоит в 10 раз дороже.

7 причин не лезть в микросервисы

Значительная часть начинающих прогеров по умолчанию считает, что микросервисы — это прогрессивно и круто. Но они просто не видят подводных камней. На самом деле MSA — это компромисс со сложностью, деньгами и нервами. И не нужно считать, что монолит — это отсталая технология. Решения, касающиеся архитектуры продукта, нужно принимать, основываясь на объективных данных, а не хайпе.

Рассмотрим главные причины, по которым вам не стоит связываться с микросервисами.

Сложность съедает пользу

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

На практике получается следующее:

• Kubernetes (или иной подобный инструмент) становится источником проблем. Вместо написания кода вы теперь разбираетесь, почему поды (базовые строительные блоки) не стартуют, настраиваете контроллеры, обновляете Helm-чарты. Это занимает 30-50% рабочего времени.

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

Команда тратит полгода на переход. Но сервис получает те же 100 запросов в секунду. Только теперь он становится медленнее, сложнее в поддержке, дороже в эксплуатации.

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

Микросервисы не лечат плохой код

У вас есть монолит — большой, тяжелый, с запутанными зависимостями. И вот вы решаете: «Давайте разобьем это на микросервисы!» В теории звучит отлично: каждый сервис — маленький, независимый, аккуратный.

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

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

Нужна подготовленная команда

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

• Без полноценного DevOps или SRE-инженера вы быстро утонете в бесконечной настройке и мониторинге. Это не та работа, которую можно взвалить на бэкендера — она требует специфических знаний и постоянного внимания.
• Когда сервисов становится много, появляется новая головная боль — согласование контрактов между командами. Кто за что отвечает? Как тестировать изменения? Что делать, если один сервис ломает другой? Без четких договоренностей и CI/CD-культуры это превращается в хаос.
• В большинстве стартапов два бэкендера, один стажер и горящие сроки. Они едва успевают пилить фичи, не то что разбираться с продвинутыми практиками DevOps.

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

Деньги тратятся быстрее

Когда речь заходит о микросервисах, многие почему-то забывают простую истину — за все надо платить:

• Без профессионального DevOps-инженера (а хорошие специалисты стоят дорого) ваш «распределенный рай» быстро превратится в ад. Кто будет настраивать Kubernetes, разбираться с падающими подами и оркестрировать логи?
• Базовый мониторинг вроде Prometheus + Grafana — это только начало. Когда сервисов станет много, вам понадобятся системы трассировки и еще десяток инструментов, каждый из которых требует времени и денег.
• Главная скрытая цена микросервисов — время инженеров. В монолите проверка занимает минуты. В мире микросервисов вам сначала придётся поднять пол-инфраструктуры, чтобы просто удостовериться, что код вообще работает.

Для проектов с нагрузкой меньше 100k пользователей микросервисы обходятся в 2-3 раза дороже монолита. И это без учета скрытых затрат — нервов, задержек и упущенных возможностей.

Отладка микросервисов — это головная боль

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

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

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

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

Легкого масштабирования не будет

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

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

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

Когда микросервисы все же нужны

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

Вот три реальных ситуации, когда MSA имеет смысл.

Независимые продукты под одной крышей

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

Здесь микросервисы — не прихоть, а необходимость.

Огромные масштабы

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

Технический стек из разных компонентов

Иногда часть системы логичнее писать на Go (где важна скорость), часть на Python (для ML), а часть оставить на JVM (для legacy).

Микросервисы позволяют:

• использовать оптимальный язык для каждой задачи;
• обновлять компоненты независимо;
• не тащить в проект лишние зависимости

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

Итоги

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

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

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

Проблема стала известна благодаря пользователю Reddit с ником Milk_Steak_Jabroni, который опубликовал скриншот с порнографическим видео актрисы Мии Халифы, появившимся в поисковой подсказке по запросу рэперши M.I.A.

Реакция Spotify

Представитель Spotify Лаура Бэйти подтвердила, что контент был удалён из-за нарушения правил платформы. Сервис запрещает размещение сексуально откровенных материалов, но остаётся неясным, как такие видео могли обойти систему модерации.

Долговременные проблемы с модерированием

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

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

Проблема усугубляется отсутствием удобного способа жалоб на неподобающий контент.

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

Сервис представляет из себя сайт-одностраничник, в центре которого расположился iPod Classic. Пользователь может перемещаться по меню, используя либо клавиатуру, либо через Click Wheel — знаменитый орган управления плеера.

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

Для того, чтобы слушать музыку на iPod.js, пользователям предлагается авторизоваться. Это можно сделать с помощью своего аккаунта в Spotify или Apple Music.

При этом автор проекта под ником tannerv оставил в виртуальном iPod приятную пасхалку. Перейдя в меню Games можно сыграть в классическую аркаду — Арканоид.

Какие технологии использовались для создания iPod.js?

По словам автора, фронтенд проекта делался на JavaScript (TypeScript и React) и CSS. Для связки с музыкальными сервисами использовались Spotify Web Playback SDK и Apple MusicKit JS.

Где узнать подробности создания проекта?

В GitHub-репозитории iPod.js

Источник: Hacker News

Часть пользователей по всему миру столкнулись с недоступностью нескольких популярных площадок. В их числе оказались GitHub, Stackoverflow, Spotify и т.д.

Эту информацию подтверждают и данные сервиса Downdetector, главная страница которой «заполнена» крупными онлайн-ресурсами.

На данный момент нет информации, что стало причиной масштабного сбоя. Изначально предполагалось, что возможной причиной случившегося могут быть проблемы у Amazon Web Services (AWS).

Но чуть позднее продакт-менеджер Financial Times Мэтт Тэйлор написал в своём Twitter что, вероятнее всего, сбой связан с аварией на стороне CDN-провайдера Fastly.

Источник: Раньше всех. Ну почти.

Спустя почти два года разбирательства завершились. Европейские власти заявили об использовании Apple своего положения монополиста для повышения привлекательности музыкального сервиса компании.

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

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

В качестве наказания власти Европы планируют взыскать с американского ИТ-гиганта штраф в размере 10% от годового дохода или 27 млрд долларов (около 2 трлн рублей).

Источник: CNBC

Метод основан на том, что компании используют в приложениях зависимости из стандартных репозиториев, а также внутренние зависимости, которые хранятся в собственных репозиториях и не распространяются публично. Если знать имена пакетов с внутренними зависимостями и создать пакеты с такими же именами в публичных репозиториях, то можно выполнить код на серверах компании. Это связано с тем, что пакетные менеджеры вроде npm, pip и gem пытаются загрузить внутренние зависимости компаний в том числе из публичных репозиториев. Проблема не специфична для NPM, PyPI, RubyGems и проявляется в других системах, среди которых NuGet, Maven и Yarn.

Идея такой атаки появилась после того, как исследователь изучил файлы манифеста package.json из пакета npm, который использовался внутри системы PayPal. Бирсан обнаружил, что некоторых пакетов нет в общедоступном репозитории npm. Это были внутренние пакеты, созданные PayPal. После этого исследователь начал поиск имён внутренних пакетов в репозиториях GitHub или в CDN известных компаний. Собрав базу, он создал поддельные пакеты с такими же именами в публичных репозиториях, таких как npm, PyPI и RubyGems. Каждый пакет выходил под реальной учётной записью и содержал пояснение, что он предназначен для исследования безопасности.

Вскоре стало понятно, что если пакет с одним и тем же именем присутствует и в общедоступном, и в частном репозитории, то публичный пакет получает приоритет. Используя эту технику, Бирсан провёл успешные атаки на серверы Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp и Uber. В PyPI на приоритет загрузки влиял номер версии — загружалась наиболее свежая версия пакета, вне зависимости от репозитория. В NPM и RubyGems приоритет зависел только от репозитория.

75 % всех зафиксированных запусков кода были связаны с загрузкой NPM-пакетов. Это объясняется тем, что имён внутренних модулей JavaScript было найдено намного больше, чем имён зависимостей на Python и Ruby. Внутренние gem-пакеты были обнаружены у 8 компаний, 4 из них удалось атаковать, создав дубликат пакета в RubyGems. Среди жертв оказалась Spotify, сборочный сервер которой установил поддельный пакет shopify-cloud спустя всего несколько часов после его публикации. Поддельный Node.js-пакет idms-pmrpc попал в сеть Apple, в том числе на сервер, связанный с Apple ID.

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

Как защититься от атак на зависимости?

После изучения проблемы компания Microsoft опубликовала рекомендации по защите сборочных систем от атак на зависимости:

• В PyPI рекомендуется использовать опцию “–index-url” вместо “–extra-index-url” для переопределения приоритета обработки зависимостей.
• В NuGet в nuget.config в секции packageSources рекомендуется использовать запись <clear /> для удаления наследуемых конфигураций, а также явно добавлять внутренние репозитории через <add />.
• В Maven рекомендуется настроить одно общее зеркало при помощи опций <mirrorOf>*</mirrorOf> и перенаправлять в него все запросы к репозиториям. Другой вариант —  переопределение репозиториев по умолчанию при помощи настройки <releases>.
• В NPM и Yarn в пакетах рекомендуется определить scopeprefix для привязки репозитория к каждому пакету (возможна привязка только одного репозитория).

Не остался в стороне и основатель Epic Games Тим Суини, отметивший, что Apple своими действиями лишь пытается «обмануть сообщество лоскутным одеялом специальных предложений». Напомним, что он также обвинял компанию в неравном отношении к разработчикам на фоне новостей об уменьшении размера комиссии для некоторых из них.

Стоит отметить, что сама Apple опубликовала ряд цитат, в которых компании наоборот благодарят её за снижение «налога»:

Мы очень рады программе App Store Small Business! Мы всегда ценили открытость и поддержку, которую получали от Apple, благодаря чему миллионы пользователей по всему миру узнали о наших приложениях с помощью вкладки «Сегодня». За последние 10 лет рынок стал намного более конкурентным и небольшому частному бизнесу, наподобие нашего, оставаться на плаву гораздо сложнее. Изменение размеров комиссии, безусловно, будет высоко оценено и позволит нам продолжать улучшать наши текущие приложения и создавать новые в течение долгих лет. В итоге все останутся в выигрыше.

Напомним, что некоторое время назад Apple объявила о снижении размеров комиссии вдвое для некоторых разработчиков: с 30 до 15%. Действовать новые правила начнут с января 2021 года.

При этом Ротем и Локар в кратчайшие сроки сообщили Spotify о найденной базе. Музыкальный сервис отреагировал незамедлительно: для защиты пользовательских данных, компания запустила процесс сброса паролей для тех аккаунтов, которые оказались «слиты».

Стоит отметить, что утечка хоть и носит достаточно масштабный характер, на фоне общей пользовательской базы Spotify в 299 млн человек, 350 тыс – это всего лишь 0,1%.

История Groove Music

Сервис был запущен в 2012 году, когда компания Microsoft приобрела Zune Music и переименовала его в Xbox Music, а уже в 2015 году, незадолго до выхода Windows 10 — в Groove Music. Имя сервиса было выбрано аналогичным названию приложения для воспроизведения музыки в Windows 10, Groove.

Данный плеер используется в основном для воспроизведения музыкальных файлов, хранящихся локально, но он также предоставлял доступ к стриминговому сервису компании Groove Music. Groove Music Pass — название платной подписки, предоставлявшейся в 22 странах мира через приложения для настольных компьютеров, мобильных телефонов и игровых консолей.

Пользователи получат предупреждения о закрытии

Компания Microsoft объявила, что закрывает сервис навсегда, и решение связано с тем, что Groove Music не был финансово успешен, как ожидалось при его запуске. В обновлённой версии приложения, выходящей во вторник 10 октября, платным пользователям будет предлагаться перевести свои музыкальные коллекции в учётные записи Spotify.

Microsoft не прекратит работу плеера Groove Music

Пользователям десктопной версии приложения не стоит бояться — Groove Music будет поддерживаться и в будущем. Однако приложение сможет воспроизводить только локальные музыкальные файлы. После 31 декабря 2017 года приложение перестанет предлагать возможность потокового воспроизведение музыки, покупки и загрузки новых композиций из подписки Groove Music Pass.

Всем пользователям платной подписки настоятельно рекомендуется перенести свой контент на Spotify до 31 января 2018 года. После этого дня вариант цифровой миграции не будет возможен.