Эффект стратегий масштабирования
(продолжение предыдущего поста)
Стратегии масштабирования можно разделить на две категории: с ограниченным воздействием и с высокой эффективностью.
Стратегии масштабирования с ограниченным воздействием проще реализовать, они требуют меньше времени и обычно предполагают минимальные изменения в текущей системе. Они идеально подходят для обеспечения немедленного или умеренного роста.
Стратегии с высокой эффективностью обеспечивают более значительные долгосрочные преимущества, но требуют существенных изменений в архитектуре системы.
Разберем четыре простых примера:
1. Вертикальное масштабирование
Вертикальное масштабирование подразумевает модернизацию ресурсов существующего сервера — увеличение мощности процессора, добавление оперативной памяти или расширение хранилища — для обработки повышенной нагрузки.
Когда использовать: идеально подходит для быстрого решения текущих проблем с производительностью без внесения изменений в приложение.
Плюсы:
* Быстрота и простота реализации, не требуется вносить изменения в приложение.
* Низкая сложность и минимальные операционные издержки.
Минусы:
* Ограниченная масштабируемость — в конечном итоге достигаются аппаратные ограничения.
* Единый сервер означает единую точку отказа.
* Значительный рост затрат на оборудование при достижении высоких уровней нагрузки.
2. Горизонтальное дублирование
Запуск нескольких копий приложения на отдельных серверах с распределением трафика через балансировщик нагрузки.
Когда использовать: полезно, когда требуется обеспечить надёжность и простой поэтапный рост.
Плюсы:
* Высокая доступность и отказоустойчивость.
* Простое масштабирование за счёт добавления новых экземпляров.
Минусы:
* Усложнение управления системой.
* Возможные проблемы с поддержанием согласованного состояния данных на разных экземплярах.
3. Разбиение данных (шардинг)
Разбиение данных предполагает разделение данных на несколько баз данных на основе определённых критериев — например, диапазонов идентификаторов пользователей, географического положения или категорий товаров. При этом каждая база данных обрабатывает часть общей нагрузки.
Когда использовать: когда база данных достигает пределов ёмкости или начинает работать медленнее, разбиение помогает распределить нагрузку и справиться со значительным ростом объёма данных.
Плюсы:
* Высокая масштабируемость за счёт распределения данных.
* Эффективное использование ресурсов.
Минусы:
* Сложная реализация и необходимость постоянного обслуживания.
* Трудности при выполнении запросов, затрагивающих несколько разделов данных.
4. Функциональная декомпозиция (микросервисы)
Функциональная декомпозиция подразумевает разбиение монолитного приложения на более мелкие, независимо развёртываемые микросервисы, каждый из которых отвечает за определённый бизнес‑процесс (например, заказы, клиенты, складские запасы).
Когда использовать: когда приложение становится слишком сложным для поддержки и масштабирования, микросервисы позволяют масштабировать отдельные компоненты независимо и упрощают обслуживание.
Плюсы:
* Максимальная масштабируемость и гибкость.
* Независимые сервисы могут развиваться отдельно друг от друга.
* Лучшая изоляция сбоев.
Минусы:
* Сложная архитектура, требующая тщательной координации.
* Усложняются обеспечение согласованности данных и взаимодействие между сервисами.
* Вероятно, потребуется увеличить штат сотрудников.
(продолжение предыдущего поста)
Стратегии масштабирования можно разделить на две категории: с ограниченным воздействием и с высокой эффективностью.
Стратегии масштабирования с ограниченным воздействием проще реализовать, они требуют меньше времени и обычно предполагают минимальные изменения в текущей системе. Они идеально подходят для обеспечения немедленного или умеренного роста.
Стратегии с высокой эффективностью обеспечивают более значительные долгосрочные преимущества, но требуют существенных изменений в архитектуре системы.
Разберем четыре простых примера:
1. Вертикальное масштабирование
Вертикальное масштабирование подразумевает модернизацию ресурсов существующего сервера — увеличение мощности процессора, добавление оперативной памяти или расширение хранилища — для обработки повышенной нагрузки.
Когда использовать: идеально подходит для быстрого решения текущих проблем с производительностью без внесения изменений в приложение.
Плюсы:
* Быстрота и простота реализации, не требуется вносить изменения в приложение.
* Низкая сложность и минимальные операционные издержки.
Минусы:
* Ограниченная масштабируемость — в конечном итоге достигаются аппаратные ограничения.
* Единый сервер означает единую точку отказа.
* Значительный рост затрат на оборудование при достижении высоких уровней нагрузки.
2. Горизонтальное дублирование
Запуск нескольких копий приложения на отдельных серверах с распределением трафика через балансировщик нагрузки.
Когда использовать: полезно, когда требуется обеспечить надёжность и простой поэтапный рост.
Плюсы:
* Высокая доступность и отказоустойчивость.
* Простое масштабирование за счёт добавления новых экземпляров.
Минусы:
* Усложнение управления системой.
* Возможные проблемы с поддержанием согласованного состояния данных на разных экземплярах.
3. Разбиение данных (шардинг)
Разбиение данных предполагает разделение данных на несколько баз данных на основе определённых критериев — например, диапазонов идентификаторов пользователей, географического положения или категорий товаров. При этом каждая база данных обрабатывает часть общей нагрузки.
Когда использовать: когда база данных достигает пределов ёмкости или начинает работать медленнее, разбиение помогает распределить нагрузку и справиться со значительным ростом объёма данных.
Плюсы:
* Высокая масштабируемость за счёт распределения данных.
* Эффективное использование ресурсов.
Минусы:
* Сложная реализация и необходимость постоянного обслуживания.
* Трудности при выполнении запросов, затрагивающих несколько разделов данных.
4. Функциональная декомпозиция (микросервисы)
Функциональная декомпозиция подразумевает разбиение монолитного приложения на более мелкие, независимо развёртываемые микросервисы, каждый из которых отвечает за определённый бизнес‑процесс (например, заказы, клиенты, складские запасы).
Когда использовать: когда приложение становится слишком сложным для поддержки и масштабирования, микросервисы позволяют масштабировать отдельные компоненты независимо и упрощают обслуживание.
Плюсы:
* Максимальная масштабируемость и гибкость.
* Независимые сервисы могут развиваться отдельно друг от друга.
* Лучшая изоляция сбоев.
Минусы:
* Сложная архитектура, требующая тщательной координации.
* Усложняются обеспечение согласованности данных и взаимодействие между сервисами.
* Вероятно, потребуется увеличить штат сотрудников.
Telegram
METANIT.COM
Эффект стратегий масштабирования
(продолжение в следующем посте)
(продолжение в следующем посте)
❤6👍2🤝2
РКН опроверг информацию о закрытии прямого подключения к иностранным VPN
Роскомнадзор опроверг информацию о закрытии возможности прямого подключения к иностранным VPN-серверам, заявили в ведомстве.
Ранее в понедельник Telegram-каналы написали, что Роскомнадзор закрыл возможность прямого подключения к иностранным серверам: теперь специальная нейросеть Роскомнадзора отслеживает поведение сетей в поисках характерных признаков VPN-протоколов, а затем перекрывает их узлы.
"Информация о закрытии возможности прямого подключения к иностранным серверам, сформулированная в вашем запросе, не соответствует действительности. Настоятельно рекомендуем проверять публикуемые данные, напоминаем о недопустимости распространения недостоверной информации", - заявили в Роскомнадзоре.
https://ria.ru/20260302/vpn-2077991897.html
Роскомнадзор опроверг информацию о закрытии возможности прямого подключения к иностранным VPN-серверам, заявили в ведомстве.
Ранее в понедельник Telegram-каналы написали, что Роскомнадзор закрыл возможность прямого подключения к иностранным серверам: теперь специальная нейросеть Роскомнадзора отслеживает поведение сетей в поисках характерных признаков VPN-протоколов, а затем перекрывает их узлы.
"Информация о закрытии возможности прямого подключения к иностранным серверам, сформулированная в вашем запросе, не соответствует действительности. Настоятельно рекомендуем проверять публикуемые данные, напоминаем о недопустимости распространения недостоверной информации", - заявили в Роскомнадзоре.
https://ria.ru/20260302/vpn-2077991897.html
РИА Новости
РКН опроверг информацию о закрытии подключения к иностранным VPN
Роскомнадзор опроверг информацию о закрытии возможности прямого подключения к иностранным VPN-серверам, заявили РИА Новости в ведомстве. РИА Новости, 02.03.2026
🤡19🍌8🥴3😁2😭1
Сервис по подбору персонала Хедхантер выкатил свежую статистику по состоянию рынка труда за прошедший февраль. И несмотря на то, что почти весь предыдущий год ситуация в сфере найма в ИТ постепенно ухудшалась, в феврале есть некоторые улучшения.
Прежде всего увеличились предлагаемые зарплаты - с 94 442 до 100 000 и по этому показателю сравнялись с ожидаемыми зарплатами.
hh-индекс (соотношение количества активных резюме к количеству активных вакансий на рынке) также улучшилсz - с 21.3 до 19.6. Хотя и это значение очень высокое.
Количество вакансий по отношению к прошлому месяцу снова стало рости - количество вакансий увеличилось на 18%. Количество резюме выросло лишь на 8%.
Несмотря на некоторое улучшение, это может быть вызвано сезонностью - предыдущим январем с его длинными выходными, так как прошлый февраль была похожая динамика
https://stats.hh.ru/?countrySalaryDynamicChartProfArea=information_technology&hhIndexProfArea=information_technology&vacanciesProfArea=information_technology
Прежде всего увеличились предлагаемые зарплаты - с 94 442 до 100 000 и по этому показателю сравнялись с ожидаемыми зарплатами.
hh-индекс (соотношение количества активных резюме к количеству активных вакансий на рынке) также улучшилсz - с 21.3 до 19.6. Хотя и это значение очень высокое.
Количество вакансий по отношению к прошлому месяцу снова стало рости - количество вакансий увеличилось на 18%. Количество резюме выросло лишь на 8%.
Несмотря на некоторое улучшение, это может быть вызвано сезонностью - предыдущим январем с его длинными выходными, так как прошлый февраль была похожая динамика
https://stats.hh.ru/?countrySalaryDynamicChartProfArea=information_technology&hhIndexProfArea=information_technology&vacanciesProfArea=information_technology
🤔7🤡3
Шаблон конкурирующих потребителей
(продолжение предыдущего поста)
Суть паттерна:
Шаблон конкурирующих потребителей (Competing Consumer Pattern) — это архитектурный шаблон, позволяющий нескольким потребителям (consumers) параллельно обрабатывать сообщения (задачи) из общей очереди. Цель — эффективно распределить нагрузку и повысить пропускную способность системы, обеспечив её отказоустойчивость
Компоненты на схеме:
1. Producers (производители) — генерируют задачи (сообщения), которые помещаются в очередь. На схеме это Admin API, отправляющие данные в хранилище (Storage) и очередь (Queue)
2. Queue (очередь) — централизованное хранилище сообщений, ожидающих обработки. Служит буфером между производителями и потребителями
3. File Processors Pool (пул процессоров файлов) — группа независимых потребителей (File processor), которые «соревнуются» за обработку сообщений из очереди. Каждый процессор обрабатывает только одно сообщение за раз
4. Consumers (потребители) — конечные сервисы, получающие результаты обработки (например, Products API на схеме)
5. Storage (хранилище) — место временного хранения данных (файлов), которые нужно обработать
Как работает паттерн (по схеме):
1. Producers отправляют задачи (например, файлы) в Storage и ставят сообщения о задачах в Queue.
2. File Processors Pool подписывается на очередь и «соревнуется» за сообщения: как только сообщение появляется в Queue, процессоры пытаются его «захватить».
3. Как только File processor получает сообщение, он:
- извлекает задачу (например, файл из Storage);
- обрабатывает её (например, преобразует или анализирует файл);
- отправляет результат в Consumers (Products API).
4. После успешной обработки процессор подтверждает получение сообщения — оно удаляется из очереди
5. Параллельная работа нескольких File processor обеспечивает увеличение пропускной способности (указано на схеме: «Parallel work to boost throughput»)
Ключевые особенности:
- Конкуренция: потребители «соревнуются» за сообщения — каждое сообщение обрабатывается только одним потребителем
- Параллелизм: несколько процессоров работают одновременно, что ускоряет обработку
- Отказоустойчивость: если один процессор выходит из строя, другие продолжают обработку
- Масштабируемость: можно добавлять процессоры для увеличения нагрузки
- Асинхронность: производители не ждут завершения обработки — задачи помещаются в очередь и обрабатываются позже
Пример из схемы:
- Admin API (производители) отправляют файлы в Storage и уведомляют Queue.
- File processor (из пула) забирает уведомление, читает файл из Storage, обрабатывает его и передаёт результат в Products API (потребители).
- Другие File processor параллельно обрабатывают другие файлы, конкурируя за сообщения в Queue.
Преимущества:
- оптимизация пропускной способности;
- балансировка нагрузки;
- устойчивость к сбоям отдельных потребителей;
- возможность горизонтального масштабирования (добавление процессоров)
Возможные проблемы:
- дублирование сообщений (требуется идемпотентная обработка);
- неравномерное распределение нагрузки;
- переполнение очереди при высокой нагрузке;
- «ядовитые сообщения» (poison messages), которые невозможно обработать
Шаблон конкурирующих потребителей идеально подходит для систем с переменной нагрузкой, где задачи независимы и могут выполняться параллельно — например, обработка изображений, отправка писем, анализ логов. Схема наглядно демонстрирует распределение ролей и взаимодействие компонентов в этом паттерне.
(продолжение предыдущего поста)
Суть паттерна:
Шаблон конкурирующих потребителей (Competing Consumer Pattern) — это архитектурный шаблон, позволяющий нескольким потребителям (consumers) параллельно обрабатывать сообщения (задачи) из общей очереди. Цель — эффективно распределить нагрузку и повысить пропускную способность системы, обеспечив её отказоустойчивость
Компоненты на схеме:
1. Producers (производители) — генерируют задачи (сообщения), которые помещаются в очередь. На схеме это Admin API, отправляющие данные в хранилище (Storage) и очередь (Queue)
2. Queue (очередь) — централизованное хранилище сообщений, ожидающих обработки. Служит буфером между производителями и потребителями
3. File Processors Pool (пул процессоров файлов) — группа независимых потребителей (File processor), которые «соревнуются» за обработку сообщений из очереди. Каждый процессор обрабатывает только одно сообщение за раз
4. Consumers (потребители) — конечные сервисы, получающие результаты обработки (например, Products API на схеме)
5. Storage (хранилище) — место временного хранения данных (файлов), которые нужно обработать
Как работает паттерн (по схеме):
1. Producers отправляют задачи (например, файлы) в Storage и ставят сообщения о задачах в Queue.
2. File Processors Pool подписывается на очередь и «соревнуется» за сообщения: как только сообщение появляется в Queue, процессоры пытаются его «захватить».
3. Как только File processor получает сообщение, он:
- извлекает задачу (например, файл из Storage);
- обрабатывает её (например, преобразует или анализирует файл);
- отправляет результат в Consumers (Products API).
4. После успешной обработки процессор подтверждает получение сообщения — оно удаляется из очереди
5. Параллельная работа нескольких File processor обеспечивает увеличение пропускной способности (указано на схеме: «Parallel work to boost throughput»)
Ключевые особенности:
- Конкуренция: потребители «соревнуются» за сообщения — каждое сообщение обрабатывается только одним потребителем
- Параллелизм: несколько процессоров работают одновременно, что ускоряет обработку
- Отказоустойчивость: если один процессор выходит из строя, другие продолжают обработку
- Масштабируемость: можно добавлять процессоры для увеличения нагрузки
- Асинхронность: производители не ждут завершения обработки — задачи помещаются в очередь и обрабатываются позже
Пример из схемы:
- Admin API (производители) отправляют файлы в Storage и уведомляют Queue.
- File processor (из пула) забирает уведомление, читает файл из Storage, обрабатывает его и передаёт результат в Products API (потребители).
- Другие File processor параллельно обрабатывают другие файлы, конкурируя за сообщения в Queue.
Преимущества:
- оптимизация пропускной способности;
- балансировка нагрузки;
- устойчивость к сбоям отдельных потребителей;
- возможность горизонтального масштабирования (добавление процессоров)
Возможные проблемы:
- дублирование сообщений (требуется идемпотентная обработка);
- неравномерное распределение нагрузки;
- переполнение очереди при высокой нагрузке;
- «ядовитые сообщения» (poison messages), которые невозможно обработать
Шаблон конкурирующих потребителей идеально подходит для систем с переменной нагрузкой, где задачи независимы и могут выполняться параллельно — например, обработка изображений, отправка писем, анализ логов. Схема наглядно демонстрирует распределение ролей и взаимодействие компонентов в этом паттерне.
Telegram
METANIT.COM
Шаблон конкурирующих потребителей
(продолжение в следующем посте)
(продолжение в следующем посте)
❤5👍3🤝2
Индустрия видеоигр стоимостью 200 миллиардов долларов раздирается разногласиями по поводу того, как интегрировать ИИ в творческие процессы. Некоторые называют эту новую технологию следующей большой революцией, другие же критикуют как угрозу, подавляющую человеческую креативность и снижающую качество
Некоторые студии ожидают повышения производительности ИИ на 30-50% при выполнении базовых задач, таких как генерация изображений, но по-настоящему революционные изменения, такие как новые стили игр или человекоподобные персонажи, произойдут еще через несколько лет из-за сложной, междисциплинарной природы разработки игр
Вместе с этим разработчики игр теряют уверенность в потенциале ИИ. Почти половина ожидает, что использование ИИ ухудшит качество игр в следующем году. Так, около 47% разработчиков, опрошенных исследовательской компанией Omdia в прошлом году, заявили, что ожидают снижения качества игр из-за использования генеративного ИИ, что является негативным явлением по сравнению с предыдущим годом.
При этом количество тех, кто считает, что ИИ улучшит качество игр - около 15%
Кроме того, сами игроки становятся всё менее терпимыми к ошибкам искусственного интеллекта. Геймеры жалуются на роботизированные диалоги, повторяющиеся ошибки и классические проблемы генеративного ИИ, включая шестипалые кисти рук или странные глаза персонажей. Многие игроки считают, что ИИ лишает игры души и человеческого творчества.
https://www.bloomberg.com/news/articles/2026-02-25/ai-mistakes-are-infuriating-gamers-as-developers-seek-savings
Некоторые студии ожидают повышения производительности ИИ на 30-50% при выполнении базовых задач, таких как генерация изображений, но по-настоящему революционные изменения, такие как новые стили игр или человекоподобные персонажи, произойдут еще через несколько лет из-за сложной, междисциплинарной природы разработки игр
Вместе с этим разработчики игр теряют уверенность в потенциале ИИ. Почти половина ожидает, что использование ИИ ухудшит качество игр в следующем году. Так, около 47% разработчиков, опрошенных исследовательской компанией Omdia в прошлом году, заявили, что ожидают снижения качества игр из-за использования генеративного ИИ, что является негативным явлением по сравнению с предыдущим годом.
При этом количество тех, кто считает, что ИИ улучшит качество игр - около 15%
Кроме того, сами игроки становятся всё менее терпимыми к ошибкам искусственного интеллекта. Геймеры жалуются на роботизированные диалоги, повторяющиеся ошибки и классические проблемы генеративного ИИ, включая шестипалые кисти рук или странные глаза персонажей. Многие игроки считают, что ИИ лишает игры души и человеческого творчества.
https://www.bloomberg.com/news/articles/2026-02-25/ai-mistakes-are-infuriating-gamers-as-developers-seek-savings
Bloomberg.com
AI Mistakes Are Infuriating Gamers as Developers Seek Savings
Games and AI, seemingly a perfect match, are off to a rocky start
💯16❤5🤔4🤮1
В Max твердо и четко опровергли данные о распространении вируса
Специалисты центра безопасности мессенджера в проактивном режиме блокируют вредоносное программное обеспечение
Информация о распространении вируса в национальном мессенджере Max не соответствует действительности, специалисты центра безопасности платформы в проактивном режиме блокируют вредоносное программное обеспечение (ПО). Об этом сообщили в пресс-службе платформы.
Ранее в СМИ и соцсетях появилась информация, что в мессенджере Max якобы зафиксирован резкий всплеск активности киберпреступников, распространяющих опасный Android-вирус "Мамонт", который ворует деньги со смартфонов. "Информация о распространении вируса в Max не соответствует действительности. Специалисты центра безопасности проактивно выявляют и блокируют вредоносное ПО", - рассказали в пресс-службе. Там также подчеркнули, что все данные пользователей надежно защищены.
https://tass.ru/ekonomika/26630155
Специалисты центра безопасности мессенджера в проактивном режиме блокируют вредоносное программное обеспечение
Информация о распространении вируса в национальном мессенджере Max не соответствует действительности, специалисты центра безопасности платформы в проактивном режиме блокируют вредоносное программное обеспечение (ПО). Об этом сообщили в пресс-службе платформы.
Ранее в СМИ и соцсетях появилась информация, что в мессенджере Max якобы зафиксирован резкий всплеск активности киберпреступников, распространяющих опасный Android-вирус "Мамонт", который ворует деньги со смартфонов. "Информация о распространении вируса в Max не соответствует действительности. Специалисты центра безопасности проактивно выявляют и блокируют вредоносное ПО", - рассказали в пресс-службе. Там также подчеркнули, что все данные пользователей надежно защищены.
https://tass.ru/ekonomika/26630155
TACC
В Max опровергли данные о распространении вируса
Специалисты центра безопасности мессенджера в проактивном режиме блокируют вредоносное программное обеспечение
🤡60🤣10👍4
Для работы Windows 12 потребуется NPU с поддержкой ИИ и производительностью 40 TOPS
Согласно источникам, для работы Windows 12 потребуется выделенный NPU-чип с вычислительной мощностью не менее 40 TOPS.
Выпуск ОС с кодовым названием «Hudson Valley Next» запланирован на 2026 год, что совпадёт с окончанием поддержки Windows 10 в октябре. Окно выпуска соответствует схеме Microsoft по запуску крупных версий Windows каждые несколько лет, при этом Windows 11 продолжает получать поддержку и обновления.
Партнёры по аппаратному обеспечению Intel и AMD уже позиционируют процессоры со встроенным ускорением ИИ, а производители оборудования маркируют новые системы как «готовые к Windows 12».
Ожидается, что новая ОС представит модульную архитектуру CorePC, которая коренным образом изменит её структуру. Компоненты Windows станут более изолированными друг от друга, что позволит осуществлять поэтапные обновления и масштабируемые версии для различных категорий устройств, от планшетов до высокопроизводительных рабочих станций.
Наиболее значительным изменением станет интеграция ИИ. В отличие от помощника Copilot в Windows 11, в Windows 12 ИИ станет центральной системой управления. Контекстно-зависимые рекомендации задач, сводки контента в реальном времени, автоматическая категоризация документов и семантический поиск будут работать на уровне всей системы, а не как отдельные функции.
Windows 12 также получит плавающую панель задач со скруглёнными углами, которая отсоединяется от нижней части экрана, прозрачные стеклянные элементы по всему интерфейсу и системные индикаторы в верхнем правом углу. В верхней части экрана по центру расположится строка поиска с прямой интеграцией с Copilot.
Таким образом, устройства без NPU достаточной мощности могут не поддерживать некоторые функции ИИ, либо же им полностью заблокируют возможность обновления до Windows 12.
Судя по коду, Windows 12 сохранит традиционную разовую лицензию для базовой версии Home, но добавит элементы подписки для премиальных функций ИИ. Эта гибридная модель может предложить дополнительные вычислительные мощности в облаке и эксклюзивные возможности ИИ через среду Windows 365.
https://tbreak.com/windows-12-leaked-2026-ai-npu-requirement/
Согласно источникам, для работы Windows 12 потребуется выделенный NPU-чип с вычислительной мощностью не менее 40 TOPS.
Выпуск ОС с кодовым названием «Hudson Valley Next» запланирован на 2026 год, что совпадёт с окончанием поддержки Windows 10 в октябре. Окно выпуска соответствует схеме Microsoft по запуску крупных версий Windows каждые несколько лет, при этом Windows 11 продолжает получать поддержку и обновления.
Партнёры по аппаратному обеспечению Intel и AMD уже позиционируют процессоры со встроенным ускорением ИИ, а производители оборудования маркируют новые системы как «готовые к Windows 12».
Ожидается, что новая ОС представит модульную архитектуру CorePC, которая коренным образом изменит её структуру. Компоненты Windows станут более изолированными друг от друга, что позволит осуществлять поэтапные обновления и масштабируемые версии для различных категорий устройств, от планшетов до высокопроизводительных рабочих станций.
Наиболее значительным изменением станет интеграция ИИ. В отличие от помощника Copilot в Windows 11, в Windows 12 ИИ станет центральной системой управления. Контекстно-зависимые рекомендации задач, сводки контента в реальном времени, автоматическая категоризация документов и семантический поиск будут работать на уровне всей системы, а не как отдельные функции.
Windows 12 также получит плавающую панель задач со скруглёнными углами, которая отсоединяется от нижней части экрана, прозрачные стеклянные элементы по всему интерфейсу и системные индикаторы в верхнем правом углу. В верхней части экрана по центру расположится строка поиска с прямой интеграцией с Copilot.
Таким образом, устройства без NPU достаточной мощности могут не поддерживать некоторые функции ИИ, либо же им полностью заблокируют возможность обновления до Windows 12.
Судя по коду, Windows 12 сохранит традиционную разовую лицензию для базовой версии Home, но добавит элементы подписки для премиальных функций ИИ. Эта гибридная модель может предложить дополнительные вычислительные мощности в облаке и эксклюзивные возможности ИИ через среду Windows 365.
https://tbreak.com/windows-12-leaked-2026-ai-npu-requirement/
Tbreak Media
Windows 12 leaked: 2026 release needs AI NPU chip | tbreak
Microsoft's next OS demands 40 TOPS NPU chips and launches when Windows 10 support ends in 2026. The leaked 'Hudson Valley Next' features floating taskbars, system-wide AI, and potential subscription models for premium features.
🤡54🥴5❤2🤔2💩2⚡1🖕1
OpenAI работает над альтернативой GitHub
OpenAI приступила к созданию собственной альтернативы популярной платформе для размещения кода GitHub. Проект призван снизить зависимость компании от Microsoft. Новый сервис находится на ранней стадии и используется как внутренняя альтернатива GitHub, но компания уже обсуждает возможность продавать его существующим клиентам.
Как полагают эксперты, создание собственной платформы поможет снизить зависимость от Microsoft. Кроме того, решение может быть вызвано серией серьёзных сбоев на GitHub, которые наблюдались с октября 2025 года.
https://www.theinformation.com/articles/openai-developing-alternative-microsofts-github
OpenAI приступила к созданию собственной альтернативы популярной платформе для размещения кода GitHub. Проект призван снизить зависимость компании от Microsoft. Новый сервис находится на ранней стадии и используется как внутренняя альтернатива GitHub, но компания уже обсуждает возможность продавать его существующим клиентам.
Как полагают эксперты, создание собственной платформы поможет снизить зависимость от Microsoft. Кроме того, решение может быть вызвано серией серьёзных сбоев на GitHub, которые наблюдались с октября 2025 года.
https://www.theinformation.com/articles/openai-developing-alternative-microsofts-github
The Information
OpenAI Is Developing an Internal Alternative to Microsoft’s GitHub
OpenAI is developing an alternative to GitHub, Microsoft’s popular code repository that lets software engineers store, share and collaborate on computer code, according to a person with knowledge of the project. The decision to embark on the new product came…
🤔11🖕9👀1
«Яндекс» начал тестировать ИИ-агента для Android
В бета‑версии поискового приложения «Яндекс — с Алисой AI» появилось упоминание о запуске тестирования нового ИИ‑агента для Android. Речь идёт о глубокой интеграции голосового ассистента в интерфейс смартфонов на базе ОС. В компании подтвердили начало тестирования технологии.
Как сообщили в «Яндексе», пользователи смогут отправлять сообщения в мессенджерах без ручного ввода, искать информацию на устройстве и устанавливать приложения с помощью голосовых команд. Фактически ассистент получает расширенный доступ к функциям операционной системы.
Пока новая возможность доступна ограниченному числу пользователей, подавших заявки на участие в тестировании. В дальнейшем технологию планируют интегрировать в нейросеть «Алиса AI», рассказал источник, знакомый с планами компании.
https://www.kommersant.ru/doc/8479320
В бета‑версии поискового приложения «Яндекс — с Алисой AI» появилось упоминание о запуске тестирования нового ИИ‑агента для Android. Речь идёт о глубокой интеграции голосового ассистента в интерфейс смартфонов на базе ОС. В компании подтвердили начало тестирования технологии.
Как сообщили в «Яндексе», пользователи смогут отправлять сообщения в мессенджерах без ручного ввода, искать информацию на устройстве и устанавливать приложения с помощью голосовых команд. Фактически ассистент получает расширенный доступ к функциям операционной системы.
Пока новая возможность доступна ограниченному числу пользователей, подавших заявки на участие в тестировании. В дальнейшем технологию планируют интегрировать в нейросеть «Алиса AI», рассказал источник, знакомый с планами компании.
https://www.kommersant.ru/doc/8479320
Коммерсантъ
«Яндекс» возьмет смартфоны под управление
Подробнее на сайте
🤡17😁7🤮6👍2💩2🌭1🤨1
Исследование показало, что агенты могут радикально менять стратегию даже при идентичном вводе — и это напрямую снижает точность их работы
Группа исследователей в области обработки естественного языка из нескольких американских университетов провела совместное исследование, в ходе которого выяснилось, что агенты часто выбирают разные последовательности действий даже при идентичных входах. И это влияет на точность ответа.
Всего было проведено 3 000 экспериментов (100 задач × 10 запусков × 3 модели) на трёх моделях (Llama 3.1 70B, GPT-4o, Claude Sonnet 4.5) с использованием датасета HotpotQA.
В среднем исследователи зафиксировали 2,0–4,2 уникальных траектории на 10 запусков, а разброс по количеству шагов достигает 55%.
Высокая согласованность поведения (≤2 уникальных траектории) приводит к точности 80–92%, тогда как при высокой вариативности (≥6 траекторий) точность падает до 25–60%. Причём 69% расхождений возникают уже на втором шаге — при первом запросе. Длина траектории также коррелирует с точностью: короткие (3 шага) дают 90% правильных ответов, длинные (8+ шагов) — лишь 43%.
Работа подчёркивает: даже при минимальном наборе инструментов агенты демонстрируют значительную вариативность, а с ростом сложности задач проблема только усугубляется. Для практических применений важно не только повышать точность, но и обеспечивать стабильность поведения — это позволит строить более надёжные и предсказуемые системы.
https://arxiv.org/html/2602.11619v1
Группа исследователей в области обработки естественного языка из нескольких американских университетов провела совместное исследование, в ходе которого выяснилось, что агенты часто выбирают разные последовательности действий даже при идентичных входах. И это влияет на точность ответа.
Всего было проведено 3 000 экспериментов (100 задач × 10 запусков × 3 модели) на трёх моделях (Llama 3.1 70B, GPT-4o, Claude Sonnet 4.5) с использованием датасета HotpotQA.
В среднем исследователи зафиксировали 2,0–4,2 уникальных траектории на 10 запусков, а разброс по количеству шагов достигает 55%.
Высокая согласованность поведения (≤2 уникальных траектории) приводит к точности 80–92%, тогда как при высокой вариативности (≥6 траекторий) точность падает до 25–60%. Причём 69% расхождений возникают уже на втором шаге — при первом запросе. Длина траектории также коррелирует с точностью: короткие (3 шага) дают 90% правильных ответов, длинные (8+ шагов) — лишь 43%.
Работа подчёркивает: даже при минимальном наборе инструментов агенты демонстрируют значительную вариативность, а с ростом сложности задач проблема только усугубляется. Для практических применений важно не только повышать точность, но и обеспечивать стабильность поведения — это позволит строить более надёжные и предсказуемые системы.
https://arxiv.org/html/2602.11619v1
👍5🤔3🤝2
Apple официально представила самый дешевый макбук - MacBook Neoмобильного чипа A18 Pro
Apple анонсировала бюджетный MacBook Neo. Устройство построено на базе процессора A18 Pro, который использовали в iPhone 16 Pro и 16 Pro Max, оснащено 8 ГБ ОЗУ и SSD объёмом до 512 ГБ. Главное преимущество устройства — его цена. Ноутбук стоит от 600 долларов, а продажи начнутся уже 11 марта.
MacBook Neo работает на базе мобильного чипа A18 Pro с 6 ядрами CPU (2 производительных и 4 эффективных), 5 ядрами GPU и 16 ядрами NPU. Есть аппаратная трассировка лучей. Из оперативной памяти доступно всего 8 ГБ с пропускной способностью до 60 ГБ/с. Объём SSD-накопителя можно выбрать: 256 или 512 ГБ.
Изображение выводится на 13-дюймовый IPS-дисплей с LED-подсветкой. Разрешение составляет 2408 × 1506 пикселей, а пиковая яркость — 500 нит. Монитор полностью охватывает пространство цветов sRGB, но без поддержки P3. Для созвонов добавили веб-камеру с разрешением 1080p.
Для связи предусмотрены модули Wi-Fi 6E и Bluetooth 6. Звук выводится на систему из двух динамиков, а для записи голоса есть два микрофона с шумоподавлением. Версия на 512 ГБ оснащена сканером отпечатка пальцев Touch ID. За автономность отвечает аккумулятор на 36,5 Вт·ч. Apple отмечает, что этого должно хватить на 16 часов просмотра видео или 11 часов работы в интернете.
По сообщениям, в российских магазинах стоимость новинки составит от 69 999 рублей.
https://www.apple.com/newsroom/2026/03/say-hello-to-macbook-neo/
Для среднестатистической разработки это чудо вряд ли подойдет, если для чего-то более менее легковесного.
Apple анонсировала бюджетный MacBook Neo. Устройство построено на базе процессора A18 Pro, который использовали в iPhone 16 Pro и 16 Pro Max, оснащено 8 ГБ ОЗУ и SSD объёмом до 512 ГБ. Главное преимущество устройства — его цена. Ноутбук стоит от 600 долларов, а продажи начнутся уже 11 марта.
MacBook Neo работает на базе мобильного чипа A18 Pro с 6 ядрами CPU (2 производительных и 4 эффективных), 5 ядрами GPU и 16 ядрами NPU. Есть аппаратная трассировка лучей. Из оперативной памяти доступно всего 8 ГБ с пропускной способностью до 60 ГБ/с. Объём SSD-накопителя можно выбрать: 256 или 512 ГБ.
Изображение выводится на 13-дюймовый IPS-дисплей с LED-подсветкой. Разрешение составляет 2408 × 1506 пикселей, а пиковая яркость — 500 нит. Монитор полностью охватывает пространство цветов sRGB, но без поддержки P3. Для созвонов добавили веб-камеру с разрешением 1080p.
Для связи предусмотрены модули Wi-Fi 6E и Bluetooth 6. Звук выводится на систему из двух динамиков, а для записи голоса есть два микрофона с шумоподавлением. Версия на 512 ГБ оснащена сканером отпечатка пальцев Touch ID. За автономность отвечает аккумулятор на 36,5 Вт·ч. Apple отмечает, что этого должно хватить на 16 часов просмотра видео или 11 часов работы в интернете.
По сообщениям, в российских магазинах стоимость новинки составит от 69 999 рублей.
https://www.apple.com/newsroom/2026/03/say-hello-to-macbook-neo/
Для среднестатистической разработки это чудо вряд ли подойдет, если для чего-то более менее легковесного.
Apple Newsroom
Say hello to MacBook Neo
Apple today unveiled MacBook Neo, an all-new laptop that delivers the magic of the Mac at a breakthrough price.
🤔10👍4❤3👎2
Google представил третий квартальный релиз Android 16 (QPR3).
Основное новшество - это добавление режима рабочего стола, который активируется при подключении устройства к внешнему экрану.
По аналогии с традиционной средой рабочего стола новый режим позволяет одновременно работать с окнами нескольких приложений, менять размер окон и использовать для навигации панель задач, показывающую активные приложения и допускающую закрепление ярлыков наиболее часто используемых программ.
Возможно подключение клавиатуры и мыши, и назначение собственных комбинаций клавиш. На внешнем экране создаётся новый сеанс рабочего стола, а на телефоне можно продолжать работать в мобильном интерфейсе.
Мобильные приложения, созданные с использованием механизмов адаптивного интерфейса, в десктоп-режиме выглядят как типовые настольные приложения.
Для разработчиков для работы с большими экрана добавлен ряд API:
- Объект Display — позволяет отслеживать изменение настроек экрана и перемещения приложения на другой экран.
- API для обработки событий с клавиатуры и мыши.
- В оконный менеджер Jetpack WindowManager добавлены новые классы экранов — Large (между 1200dp и 1600dp) и Extra-large (более 1600dp)
- Добавлены библиотеки Navigation 3 и Compose Material 3 Adaptive для создания интерфейсов, подстраивающихся под размер экрана.
https://android-developers.googleblog.com/2026/03/android-devices-extend-seamlessly-to.html
Основное новшество - это добавление режима рабочего стола, который активируется при подключении устройства к внешнему экрану.
По аналогии с традиционной средой рабочего стола новый режим позволяет одновременно работать с окнами нескольких приложений, менять размер окон и использовать для навигации панель задач, показывающую активные приложения и допускающую закрепление ярлыков наиболее часто используемых программ.
Возможно подключение клавиатуры и мыши, и назначение собственных комбинаций клавиш. На внешнем экране создаётся новый сеанс рабочего стола, а на телефоне можно продолжать работать в мобильном интерфейсе.
Мобильные приложения, созданные с использованием механизмов адаптивного интерфейса, в десктоп-режиме выглядят как типовые настольные приложения.
Для разработчиков для работы с большими экрана добавлен ряд API:
- Объект Display — позволяет отслеживать изменение настроек экрана и перемещения приложения на другой экран.
- API для обработки событий с клавиатуры и мыши.
- В оконный менеджер Jetpack WindowManager добавлены новые классы экранов — Large (между 1200dp и 1600dp) и Extra-large (более 1600dp)
- Добавлены библиотеки Navigation 3 и Compose Material 3 Adaptive для создания интерфейсов, подстраивающихся под размер экрана.
https://android-developers.googleblog.com/2026/03/android-devices-extend-seamlessly-to.html
Android Developers Blog
Android devices extend seamlessly to connected displays
News and insights on the Android platform, developer tools, and events.
👍9❤4❤🔥4🤝1
Паттерны микросервисов
(продолжение предыдущего поста)
Реализация микросервисов часто сопроваждается применением ряда паттернов. Рассмотрим некоторые ключевые из них.
1. Database Per Service Pattern (база данных на сервис)
- Суть: каждый микросервис имеет собственную базу данных, изолированную от других сервисов. Взаимодействие между сервисами происходит через API, а не напрямую с БД.
- Схема (на изображении): показаны два микросервиса, каждый со своей базой данных.
- Преимущества:
- слабая связанность сервисов (изменения в БД одного сервиса не влияют на другие);
- возможность использовать разные типы БД для разных сервисов;
- упрощение масштабирования и развёртывания.
- Недостатки:
- усложнение обмена данными между сервисами;
- увеличение затрат на инфраструктуру (множество БД);
- сложность обеспечения транзакционной целостности.
- Подходит для: крупномасштабных проектов с большим числом микросервисов.
2. API Gateway Pattern (паттерн API-шлюза)
- Суть: создание единой точки входа для клиентских запросов. Шлюз маршрутизирует запросы к соответствующим микросервисам, агрегирует ответы и возвращает их клиенту.
- Схема (на изображении): клиент отправляет запрос к API Gateway, который перенаправляет его к нужным микросервисам.
- Функции API Gateway:
- маршрутизация запросов;
- агрегация ответов;
- аутентификация и авторизация;
- кэширование;
- ограничение скорости запросов (rate limiting).
- Преимущества:
- упрощение взаимодействия клиента с системой;
- централизованное управление безопасностью и логированием;
- оптимизация числа сетевых вызовов.
- Недостатки:
- риск единой точки отказа;
- необходимость дополнительного обслуживания шлюза.
- Подходит для: сложных систем с множеством микросервисов и разных клиентских приложений.
3. BFF Pattern (Backends for Frontends — бэкенды для фронтендов)
- Суть: создание отдельных бэкендов (шлюзов) для разных типов клиентов (веб, мобильное приложение, десктоп). Каждый BFF адаптирует API под специфические требования клиента.
- Схема (на изображении): показаны Web UI BFF и App BFF, которые взаимодействуют с микросервисами и адаптируют данные для соответствующих клиентов.
- Преимущества:
- оптимизация ответов под конкретный интерфейс пользователя;
- уменьшение объёма данных, передаваемых клиенту;
- изоляция изменений в клиентских приложениях от бэкенда.
- Недостатки:
- увеличение числа компонентов системы;
- дублирование логики для разных BFF.
- Подходит для: систем с разными требованиями к API у клиентов (например, веб и мобильное приложение).
4. CQRS (Command Query Responsibility Segregation — разделение команд и запросов)
- Суть: разделение операций изменения данных (команды — Command) и чтения данных (запросы — Query). Используются отдельные модели для записи и чтения данных.
- Схема (на изображении): показаны потоки Command (запись в Write DB) и Query (чтение из Read DB).
- Преимущества:
- оптимизация операций чтения и записи;
- возможность использовать разные хранилища для чтения и записи;
- повышение производительности и масштабируемости.
- Недостатки:
- увеличение сложности системы;
- необходимость синхронизации между хранилищами.
- Подходит для: систем с интенсивными операциями чтения (например, аналитические системы).
5. Event Sourcing Pattern (паттерн источника событий)
- Суть: хранение состояния приложения в виде последовательности событий, а не в виде текущего состояния. Все изменения системы записываются как события в Event Store.
- Схема (на изображении): показаны события (Event Profile Created, Event Hobbies Updated и т. д.), которые сохраняются в Event Store, а затем используются для чтения данных.
- Преимущества:
- полный журнал истории изменений системы;
- возможность отката состояния системы к любой точке во времени;
- упрощение реализации сложных бизнес-процессов.
- Недостатки:
- высокая сложность реализации;
- увеличение объёма хранилища данных.
- Подходит для: систем с критическими бизнес-процессами, где важна история изменений (например, финансовые системы).
6. Saga Pattern (паттерн саги)
(продолжение предыдущего поста)
Реализация микросервисов часто сопроваждается применением ряда паттернов. Рассмотрим некоторые ключевые из них.
1. Database Per Service Pattern (база данных на сервис)
- Суть: каждый микросервис имеет собственную базу данных, изолированную от других сервисов. Взаимодействие между сервисами происходит через API, а не напрямую с БД.
- Схема (на изображении): показаны два микросервиса, каждый со своей базой данных.
- Преимущества:
- слабая связанность сервисов (изменения в БД одного сервиса не влияют на другие);
- возможность использовать разные типы БД для разных сервисов;
- упрощение масштабирования и развёртывания.
- Недостатки:
- усложнение обмена данными между сервисами;
- увеличение затрат на инфраструктуру (множество БД);
- сложность обеспечения транзакционной целостности.
- Подходит для: крупномасштабных проектов с большим числом микросервисов.
2. API Gateway Pattern (паттерн API-шлюза)
- Суть: создание единой точки входа для клиентских запросов. Шлюз маршрутизирует запросы к соответствующим микросервисам, агрегирует ответы и возвращает их клиенту.
- Схема (на изображении): клиент отправляет запрос к API Gateway, который перенаправляет его к нужным микросервисам.
- Функции API Gateway:
- маршрутизация запросов;
- агрегация ответов;
- аутентификация и авторизация;
- кэширование;
- ограничение скорости запросов (rate limiting).
- Преимущества:
- упрощение взаимодействия клиента с системой;
- централизованное управление безопасностью и логированием;
- оптимизация числа сетевых вызовов.
- Недостатки:
- риск единой точки отказа;
- необходимость дополнительного обслуживания шлюза.
- Подходит для: сложных систем с множеством микросервисов и разных клиентских приложений.
3. BFF Pattern (Backends for Frontends — бэкенды для фронтендов)
- Суть: создание отдельных бэкендов (шлюзов) для разных типов клиентов (веб, мобильное приложение, десктоп). Каждый BFF адаптирует API под специфические требования клиента.
- Схема (на изображении): показаны Web UI BFF и App BFF, которые взаимодействуют с микросервисами и адаптируют данные для соответствующих клиентов.
- Преимущества:
- оптимизация ответов под конкретный интерфейс пользователя;
- уменьшение объёма данных, передаваемых клиенту;
- изоляция изменений в клиентских приложениях от бэкенда.
- Недостатки:
- увеличение числа компонентов системы;
- дублирование логики для разных BFF.
- Подходит для: систем с разными требованиями к API у клиентов (например, веб и мобильное приложение).
4. CQRS (Command Query Responsibility Segregation — разделение команд и запросов)
- Суть: разделение операций изменения данных (команды — Command) и чтения данных (запросы — Query). Используются отдельные модели для записи и чтения данных.
- Схема (на изображении): показаны потоки Command (запись в Write DB) и Query (чтение из Read DB).
- Преимущества:
- оптимизация операций чтения и записи;
- возможность использовать разные хранилища для чтения и записи;
- повышение производительности и масштабируемости.
- Недостатки:
- увеличение сложности системы;
- необходимость синхронизации между хранилищами.
- Подходит для: систем с интенсивными операциями чтения (например, аналитические системы).
5. Event Sourcing Pattern (паттерн источника событий)
- Суть: хранение состояния приложения в виде последовательности событий, а не в виде текущего состояния. Все изменения системы записываются как события в Event Store.
- Схема (на изображении): показаны события (Event Profile Created, Event Hobbies Updated и т. д.), которые сохраняются в Event Store, а затем используются для чтения данных.
- Преимущества:
- полный журнал истории изменений системы;
- возможность отката состояния системы к любой точке во времени;
- упрощение реализации сложных бизнес-процессов.
- Недостатки:
- высокая сложность реализации;
- увеличение объёма хранилища данных.
- Подходит для: систем с критическими бизнес-процессами, где важна история изменений (например, финансовые системы).
6. Saga Pattern (паттерн саги)
❤5👍2🔥2🤝1
- Суть: управление длительными бизнес-процессами, состоящими из последовательности локальных транзакций. Сага координирует выполнение шагов процесса и обрабатывает откаты в случае ошибок.
- Схема (на изображении): показана последовательность шагов (Service A → Service B → Service C) с координацией через Saga Orchestrator.
- Компоненты:
- Saga Orchestrator (оркестратор саги) — управляет порядком выполнения шагов;
- локальные транзакции — отдельные шаги бизнес-процесса;
- компенсационные действия — откат изменений при ошибке.
- Преимущества:
- поддержка длительных транзакций;
- обеспечение согласованности данных в распределённой системе;
- возможность параллельного выполнения независимых шагов.
- Недостатки:
- сложность реализации и отладки;
- необходимость управления состоянием саги.
- Подходит для: сложных бизнес-процессов с несколькими этапами (например, оформление заказа в e-commerce).
- Схема (на изображении): показана последовательность шагов (Service A → Service B → Service C) с координацией через Saga Orchestrator.
- Компоненты:
- Saga Orchestrator (оркестратор саги) — управляет порядком выполнения шагов;
- локальные транзакции — отдельные шаги бизнес-процесса;
- компенсационные действия — откат изменений при ошибке.
- Преимущества:
- поддержка длительных транзакций;
- обеспечение согласованности данных в распределённой системе;
- возможность параллельного выполнения независимых шагов.
- Недостатки:
- сложность реализации и отладки;
- необходимость управления состоянием саги.
- Подходит для: сложных бизнес-процессов с несколькими этапами (например, оформление заказа в e-commerce).
Telegram
METANIT.COM
Паттерны микросервисов
(продолжение в следующем посте)
(продолжение в следующем посте)
❤6🔥3👍2