Microsoft уволит 200 сотрудников игровой студии King и заменит их инструментами искусственного интеллекта. Над ними трудились эти же самые разработчики, то есть Microsoft поставит вместо них их же детище.

Корпорация Microsoft собирается уволить около 200 сотрудников игровой студии King, создавшей очень популярную мобильную игру Candy Crush. Это происходит в рамках грандиозного сокращения игрового подразделения Microsoft, которое продолжается несколько месяцев и затрагивает тысячи сотрудников – только с начала июля 2025 г. работы лишились около 4000 человек.

Однако случай с King особенный с точки зрения морали и этики: Microsoft намерена заменить работников этой студии искусственным интеллектом. С одной стороны, в этом нет ничего примечательного – нейросети заменяют людей разных профессий по всему миру. С другой стороны, сотрудников King Microsoft решила променять на искусственный интеллект, который они же и создавали в течение длительного времени.
https://www.pcgamer.com/gaming-industry/microsofts-200-laid-off-king-devs-are-reportedly-being-replaced-by-ai-they-helped-build-while-its-absolute-s-show-hr-department-looks-away-and-whistles/

Структура памяти процесса в Linux (описание к рисунку из предыдущего поста)

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

Далее следует сегмент BSS (Block Started by Symbol), куда помещаются неинициализированные глобальные переменные, и система обнуляет их при запуске.

Динамическая память (heap) начинается сразу после BSS и растёт вверх по мере того, как программа динамически выделяет больше памяти с помощью таких функций, как malloc.

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

В 32-разрядных системах общее адресное пространство составляет 4 ГБ, причём верхние 1 ГБ часто резервируются для ядра. Однако в 64-разрядных системах пространство огромно — около 128 ТБ для пользовательских процессов, поэтому структура может немного различаться в зависимости от архитектуры.

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

Проверить карту памяти процесса можно с помощью таких инструментов, как pmap, или просмотрев файл /proc/pid/maps. Например, если запустить простую программу на C и изучить её карту, можно чётко увидеть эти сегменты, причём адреса начинаются с низких значений для текстового сегмента и увеличиваются вверх.

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

С 1 ноября 2025 года все новые приложения Android и обновления существующих приложений, использующих нативный код C/C++ и ориентированных на устройства с Android 15 и выше, должны поддерживать 16 КБ страницы памяти для публикации в Google Play. Это требование направлено на обеспечение максимальной производительности приложений на современных устройствах Android. Приложения, написанные исключительно на Kotlin или Java, уже совместимы, но для приложений с нативным кодом необходимы действия.

Преимущества перехода на 16 КБ страницы памяти:
- Увеличение общей производительности на 5–10%.
- Ускорение запуска приложений в среднем на 3,16%, в некоторых случаях до 30%.
- Снижение энергопотребления на 4,56%.
- Ускорение запуска камеры на 4,48–6,60%.
- Ускорение загрузки системы примерно на 0,8 секунды.

Необходимые шаги для разработчиков:
1. Проверка нативного кода: Если приложение использует C/C++ код или зависит от SDK с нативным кодом, его нужно перекомпилировать для совместимости с 16 КБ. APK Analyzer в Android Studio помогает выявить наличие нативных библиотек (.so файлы) и проверить их совместимость.
2. Обновление инструментов: Используйте Android Gradle Plugin (AGP) версии 8.5.1 или выше и Android NDK r28 или выше, которые автоматически поддерживают 16 КБ выравнивание.
3. Удаление жестко закодированных предположений: Исключите в коде зависимости от размера страницы 4 КБ (например, 4096), используя функции getpagesize() или sysconf(_SC_PAGESIZE) для получения актуального размера страницы во время выполнения.
4. Тестирование: Android Studio предоставляет эмулятор с поддержкой 16 КБ страниц для arm64 и x86_64. На устройствах Pixel 8 и новее (с Android 15 QPR1) доступна опция переключения между 4 КБ и 16 КБ для тестирования. Проверяйте размер страницы с помощью команды adb shell getconf PAGE_SIZE.

Инструменты Android Studio для упрощения перехода:
- APK Analyzer: Определяет наличие нативных библиотек и их совместимость с 16 КБ.
- Lint: Выделяет библиотеки, не соответствующие 16 КБ выравниванию.
- Эмулятор: Позволяет тестировать приложения в среде с 16 КБ страницами.

Рекомендации:
- Проверьте зависимости на совместимость с 16 КБ, при необходимости обратитесь к разработчикам SDK.
- Тестируйте приложения на устройствах и эмуляторах с 16 КБ страницами, чтобы избежать проблем с производительностью.
- Обновите код и инструменты заранее, чтобы соответствовать требованиям Google Play и обеспечить лучший пользовательский опыт.

Переход на 16 КБ страницы памяти улучшит производительность и подготовит приложения к будущим инновациям Android. Разработчикам рекомендуется начать подготовку уже сейчас, используя инструменты Android Studio и предоставленные ресурсы
https://android-developers.googleblog.com/2025/07/transition-to-16-kb-page-sizes-android-apps-games-android-studio.html

10 рекомендаций по оптимизации SQL-запросов

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

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

Несколько способов оптимизации SQL:

1. Используйте имена столбцов вместо символа * в инструкции SELECT

2. Избегайте использования предложения HAVING в SQL-запросах

3. Исключайте ненужные условия в предложении WHERE

4. Избегайте вложенных подзапросов

5. Рассмотрите возможность использования предиката IN при запросе к индексированному столбцу

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

7. Старайтесь использовать UNION ALL вместо UNION

8. Избегайте использования оператора OR в условиях соединения

9. Избегайте функций в правой части оператора

10. Удалите все избыточные вычисления

Компания JetBrains изменила политику распространения среды IntelliJ IDEA: начиная с версии 2025.3, IntelliJ IDEA будет распространяться в виде единого дистрибутива, вместо отдельных версий Community и Ultimate.

Теперь будет доступен только один установщик IntelliJ IDEA, который заменит отдельные дистрибутивы для Community Edition и Ultimate Edition. В новой схеме распространения IntelliJ IDEA все функции Ultimate по-прежнему будут требовать подписку для их активации. Однако, как обещает JetBrains, даже без подписки среда разработки останется полностью функциональной, бесплатной как для коммерческого, так и для некоммерческого использования, и будет включать больше возможностей, чем когда-либо предлагала версия Community Edition.

Если вы сейчас используете Community Edition, ваша среда разработки автоматически обновится до единого дистрибутива через стандартный механизм патч-обновлений. Вы получите доступ к дополнительным функциям бесплатно и более целостный пользовательский опыт. Кроме того, вы сможете попробовать функции Ultimate в один клик.
Для пользователей Ultimate изменения минимальны: среда разработки будет называться просто IntelliJ IDEA, без суффикса «Ultimate».

https://blog.jetbrains.com/idea/2025/07/intellij-idea-unified-distribution-plan/

10 важнейших алгоритмов работы с графами: (описание к рисунку из предыдущего поста)

1. Поиск в глубину (Depth First Search, DFS) — алгоритм обхода графа, который максимально глубоко исследует каждую ветвь перед переходом к следующей.

2. Поиск в ширину (Breadth First Search, BFS) — алгоритм обхода графа, который сначала исследует все соседние вершины, прежде чем перейти к вершинам на следующем уровне.

3. Топологическая сортировка (Topological Sort) — алгоритм упорядочивания вершин ориентированного ацикличного графа таким образом, что для каждого ребра (u, v) вершина u предшествует вершине v.

4. Объединение-поиск (Union Find) — структура данных для эффективного управления разбиением множества на непересекающиеся подмножества.

5. Обнаружение циклов (Cycle Detection) — алгоритм для выявления наличия циклов в графе.

6. Связанные компоненты (Connected Components) — алгоритм для нахождения подграфов, где между любыми двумя вершинами существует путь.

7. Двудольные графы (Bipartite Graphs) — графы, вершины которых можно разделить на две независимые группы так, что рёбра соединяют только вершины из разных групп.

8. Заполнение области (Flood Fill) — алгоритм для определения и заполнения связанных областей одинакового цвета или типа.

9. Минимальное остовное дерево (Minimum Spanning Tree) — алгоритм для нахождения подграфа-дерева с минимальным суммарным весом рёбер, включающего все вершины исходного графа.

10. Кратчайший путь (Shortest Path) — алгоритм для нахождения пути минимальной длины между двумя вершинами графа.

Количество вакансий для IT-специалистов начало сокращаться впервые за три года

Несмотря на импортозамещение и цифровизацию, число открытых вакансий для разработчиков софта в РФ впервые с 2022 года сократилось и составило, по данным HeadHunter за первое полугодие, 291 тыс. против свыше 300 тыс. год назад. Снижение числа объявлений о вакансиях для IT-специалистов заметили и в других кадровых агентствах.

По данным HeadHunter, на площадке количество размещенных объявлений снизилось за полугодие на 20%, до 220 тыс. вакансий. «Еще в прошлом году на рынке начала формироваться тенденция к сокращению персонала в крупных IT-компаниях, в том числе среди разработчиков, в пользу перераспределения нагрузки у тех, кто остается, и повышения их зарплат»,— говорит представитель HeadHunter. Однако, уточняет он, если на должности младших специалистов наблюдается профицит кадров (11,1 резюме на одну вакансию), то среди высококвалифицированных специалистов (senior) наблюдается дефицит — 2,3 резюме на одну вакансию.
Многие компании начали оптимизацию этого сегмента бизнеса, в том числе посредством сокращения дорогостоящих специалистов, объясняют участники рынка. Параллельно начинается процесс внедрения искусственного интеллекта в IT-сфере, что, по текущим оценкам, способно сэкономить до 30–50% бюджетов. Однако заменить разработчиков высокой квалификации ИИ не в состоянии, по крайней мере пока.

https://www.kommersant.ru/doc/7891622

Вкратце все версии Java/JDK #java

В ГосДуме призвали WhatsApp готовиться к уходу с российского рынка

Первый зампред Госдумы по информполитике Антон Горелкин считает, что мессенджер WhatsApp вскоре может попасть под ограничения.
По словам депутата, мессенджер может войти в список ПО из недружественных стран, который правительство разрабатывает по поручению президента России. Telegram ограничения не коснутся, но регистрация мессенджера на Виргинских островах вызывает вопросы, подчеркнул господин Горелкин.

Сейчас примерно 68% россиян пользуются WhatsApp ежедневно, около 55% заходят в Telegram, рассказал депутат, По его мнению, долю лидера в случае запрета может получить национальный мессенджер Max. Господин Горелкин ожидает, что в нем будут реализованы «уникальные функции».

Накануне Владимир Путин поручил правительству разработать ограничения для ПО, произведенного в недружественных странах. Доклад должен быть готов к 1 сентября.
https://www.kommersant.ru/doc/7897955

REST API vs GraphQL

Исследователи из Microsoft изучили, какие профессии больше всего подвержены влиянию генеративного ИИ. Результаты исследования основаны исключительно на использовании Microsoft Copilot в США и могут не распространяться на другие платформы или страны.

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

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

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

Авторы предостерегают от поспешных выводов о том, что возможности ИИ автоматически приведут к автоматизации или сокращению рабочих мест. Во многих случаях ИИ выступает в роли помощника, поддерживая и улучшая работу людей, а не заменяя её. Они приводят в пример банкоматы в банковской сфере: автоматизация изменила подход к работе, но также создала новые рабочие места в отрасли.
https://the-decoder.com/microsoft-study-shows-these-professions-are-most-affected-by-generative-ai/

Вкратце как работает аутентификация через куки, сессии, токены, JWT, SSO и OAuth2

Как работает MongoDB (описание к рисунку из предыдущего поста)

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

MongoDB в основном написана на C++, но использует JavaScript для своей оболочки и Python для некоторых инструментов и драйверов. В то время как традиционные реляционные базы данных хранят данные в таблицах и строках, MongoDB, по своей сути, — это NoSQL, документоориентированная база данных.

Но MongoDB:
* хранит данные во внутреннем бинарном формате, называемом BSON (Binary JSON).
* BSON — это расширенный набор JSON.
* Он может представлять всё, что может JSON, плюс дополнительные типы данных, такие как даты и двоичные данные.
* BSON более компактен, чем JSON, что уменьшает объём памяти и повышает производительность.
* Такая структура позволяет более естественно представлять реальные объекты и связи между ними.

Архитектура MongoDB

1. Document Model — гибкая модель хранения данных в формате JSON, позволяющая использовать различные структуры и вложенные объекты.
2. Collections — группы документов, аналогичные таблицам, но без строгой схемы, обеспечивающие гибкую организацию.
3. mongod — основной процесс, обрабатывающий хранение, запросы и администрирование.
4. mongos (если используется шардирование) — маршрутизирует запросы в распределённом кластере к правильным разделам данных.
5. Replica Sets — несколько узлов поддерживают копии данных, обеспечивая высокую доступность и отказоустойчивость.
6. Sharding — горизонтальное масштабирование путём распределения данных по нескольким серверам для больших наборов данных и высокой нагрузки.
7. Indexes — структуры данных для ускорения запросов, поддерживающие различные типы для разных шаблонов доступа.
8. WiredTiger — механизм хранения по умолчанию, оптимизированный для использования памяти и диска с контролем параллелизма.
9. Aggregation Framework — мощный конвейерный фреймворк для сложного анализа и преобразования данных.
10. Query Language — выразительный язык для фильтрации, сортировки, проецирования и агрегации данных.

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

* Системы управления контентом
* Аналитика в реальном времени
* Интернет вещей (IoT)
* Мобильные приложения
* Каталоги товаров

Проблемы и ограничения

1. Транзакции — использует модель «snapshot isolation», что может иметь последствия для приложений, требующих строгих гарантий ACID.
2. Моделирование данных — гибкость требует продуманного проектирования.
3. Joins — MongoDB не поддерживает традиционные SQL-соединения.
4. Операционные затраты — MongoDB может требовать больше опыта в эксплуатации.
5. Стоимость — эксплуатация MongoDB может быть дорогой, особенно при масштабировании.

Команды Git по категориям #git

Как работает HTTPS. (описание к предыдущему посту)

Прежде всего есть два протокола:

1. HTTP (без S) — это протокол для обмена данными, который чаще всего используется между веб-браузером и веб-сайтом.

2. HTTPS — это защищённая версия этого протокола.

Почему HTTPS защищённый? Благодаря шифрованию.

Данные шифруются таким образом, что только веб-браузер и веб-сайт (сервер) знают, как их прочитать.

Без этого атаки типа «человек посередине» (MITM) могли бы перехватить ваш трафик и прочитать конфиденциальные данные, такие как пароли, данные кредитных карт и т. д.

Протокол, используемый для шифрования данных в HTTPS, — это TLS (Transport Layer Security):

💡 HTTPS = HTTP + TLS

HTTPS использует асимметричное шифрование для шифрования данных. У вас есть:
* 🔑 один закрытый ключ — секретный ключ SSL-сертификата веб-сайта, который никому не передаётся;
* 🔑 один открытый ключ — открытый ключ сертификата, который передаётся всем, кто хочет взаимодействовать с веб-сайтом.

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

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

На самом деле HTTPS использует оба типа!

Асимметричное шифрование используется для проверки сервера и безопасного создания ключа сеанса. Ключ сеанса будет использоваться для симметричного шифрования.

Ключ сеанса, как следует из названия, существует только в течение сеанса и используется как клиентом, так и сервером для шифрования/дешифрования данных.

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

Итак, какие шаги выполняются?

1. Клиент (браузер) подключается к серверу (веб-странице).
2. Сервер отправляет свой SSL-сертификат (включающий открытый ключ).
3. Клиент и сервер выполняют TLS-рукопожатие и генерируют ключ сеанса для шифрования/дешифрования будущих HTTP-данных.
4. Всё как обычно.

Подробности находятся в TLS-рукопожатии, и это, честно говоря, самая интересная часть работы HTTPS.

TLS-рукопожатие служит трём целям:
* 🔍 проверка подлинности сервера;
* ✨ генерация ключей сеанса для шифрования во время этого сеанса;
* 🤝 выбор версии TLS и наборов шифров, которые будут использоваться.

Пошагово (используя алгоритм TLS 1.2 RSA, потому что он проще):

1. Client Hello Request: клиент инициирует рукопожатие с сообщением, включающим версию TLS и поддерживаемые шифры, а также строку случайных байтов (называемую client random).
2. Server Hello Response: сервер выбирает набор шифров и генерирует свою строку случайных байтов (server random). Он отвечает с набором шифров, своим SSL-сертификатом и server random.
3. Client Verification: клиент проверяет сертификат через доверенный центр сертификации, который его выдал. SSL-сертификат имеет цифровую подпись, которая подписана закрытым ключом CA, поэтому клиент использует открытый ключ CA для её расшифровки.

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

Примечание: он всё ещё не знает наверняка, действительно ли сервер владеет этим сертификатом (т. е. имеет закрытый ключ).

🤔 Кто определяет, какому центру сертификации можно доверять?

Компания, создавшая ваш браузер! Apple, Microsoft, Google, Mozilla и другие поддерживают свой список центров сертификации. Ваш браузер/ОС поставляется с этим списком доверенных центров сертификации.

Всё основано на доверии, так что лучше им доверять...

Продолжаем:

4. Client Key Exchange: клиент создаёт случайную строку байтов, называемую «premaster secret». Он шифрует её с помощью открытого ключа сервера, полученного из SSL-сертификата, и отправляет. Поскольку для шифрования используется алгоритм асимметричного шифрования, клиент знает, что сервер может получить секрет только если расшифрует его с помощью закрытого ключа (что подтверждает владение сертификатом).
5. Session Key Generation: сервер расшифровывает premaster secret с помощью закрытого ключа SSL-сертификата. Клиент и сервер независимо генерируют ключи сеанса локально, используя комбинацию client random, server random и premaster secret.

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

Если это не так, последующее шифрование/дешифрование данных при записи не будет соответствовать протоколу HTTP/HTTPS и завершится ошибкой.

💡 Шаг 5 косвенно подтверждает клиенту, что сервер владеет предоставленным им SSL-сертификатом (а не просто делает вид, что он у него есть).

После этого сеансовый ключ может использоваться для симметричного шифрования/дешифрования HTTP-данных.