Microsoft анонсирует эволюцию IDE Visual Studio 2026, ориентированную на ускорение современного разработки. Основной акцент — на переходе к непрерывным обновлениям, чтобы соответствовать быстрому темпу создания ПО.
Согласно Misrosoft, Visual Studio превращается в современный, "живой" IDE, адаптированный под быстрый ритм разработки, с ежемесячными обновлениями и ежегодными релизами.
Планируется разделение IDE от инструментов сборки дает свободу и контроль, минимизируя риски для команд, а также новый цикл поддержки, который призван повысить надежность, безопасность и адаптивность — от индивидуальных разработчиков до корпоратов.

Некоторые ключевые моменты:
- Непрерывные обновления: Ежемесячные обновления функций и ежегодный крупный релиз в ноябре (синхронизирован с .NET). Это позволяет разработчикам получать свежие инструменты без задержек.
- Новый цикл поддержки: 1 год ежемесячных обновлений + 1 год только исправлений безопасности. Введены каналы Insiders (для раннего доступа) и Stable (стабильный), плюс опциональный LTSC для корпоратов (дополнительный год статичных функций).
- Разделение IDE и инструментов сборки: IDE обновляется независимо от .NET, C++ (MSVC), SDK и runtime. Компиляторы MSVC теперь обновляются раз в 6 месяцев, с долгосрочными версиями раз в 2 года.
- Лицензирование: Бесплатно для Community (для квалифицированных пользователей); для Professional/Enterprise — ежегодное обновление ключей для standalone-лицензий, подписки без изменений.

Новые функции для современной разработки:
- Ежемесячная доставка улучшений производительности, интеграции GitHub Copilot и новых возможностей (AI-инструменты, расширения).
- Полная совместимость: Проекты, решения и расширения работают без изменений после обновлений.
- Гибкость сборки: Поддержка нескольких версий инструментов, позволяющая командам выбирать график обновлений.

Улучшения производительности:
- Ускорение инноваций: Быстрый доступ к новым функциям без квартальных пауз.
- Минимизация простоев: Автоматические обновления без нарушения сборок или окружений.
- Фокус на разработке: Меньше времени на обслуживание, больше — на код.

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

https://devblogs.microsoft.com/visualstudio/visual-studio-built-for-the-speed-of-modern-development/

Наглядно как выглядит выравнивание данных в памяти

IPv6-адреса: описание и классификация
(продолжение в следующем посте)

IPv6-адреса: описание и классификация
(продолжение предыдущего поста)

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

1. Общая характеристика IPv6-адресов


- Длина: 128 бит (в отличие от 32 бит в IPv4).
- Формат: шестнадцатеричная нотация, значения разделены двоеточиями.
- Особенности записи:
- ведущие нули в любом 16-битном поле могут быть опущены;
- последовательные поля нулей могут быть заменены на :: (только один раз в адресе).

2. Типы IPv6-адресов

Адреса IPv6 делятся на две основные категории:

a) Unicast Addresses (индивидуальные адреса) — для идентификации конкретного интерфейса устройства. Включают:

- Global Unicast (глобальные индивидуальные адреса):
- уникальны во всём мире, маршрутизируются через интернет;
- префикс: 2000::/3 (первые три бита — 001);
- структура: Global Routing Prefix (45 бит) + Subnet (16 бит) + Interface ID (64 бит);
- пример: 2001:db8:85a3::8a2e:370:7334.

- Link-Local (локальные адреса канала):
- используются для обмена данными в пределах одного канала (подсети);
- не маршрутизируются за пределы канала;
- префикс: fe80::/10;
- структура: 10 бит + 54 бита + Interface ID (64 бита);
- пример: fe80::1234:5678:9abc.

- Unique Local (уникальные локальные адреса):
- аналогичны частным адресам IPv4 (RFC 1918), но не маршрутизируются глобально;
- диапазон: fc00::/7 — fdff::/7;
- структура: Global Routing Prefix (40 бит) + Subnet (16 бит) + Interface ID (64 бита);
- пример: fd12:3456:789a:1::1.

- Loopback (адрес обратной связи):
- используется узлом для отправки пакетов самому себе;
- формат: ::1/128 (или просто ::1);
- аналог 127.0.0.1 в IPv4.

- Unspecified (неопределённый адрес):
- состоит из нулей, формат: ::/128 (или просто ::);
- используется, когда устройству ещё не назначен постоянный IPv6-адрес или источник пакета не относится к месту назначения.

- Embedded IPv4 (встроенные IPv4-адреса):
- помогают в переходе с IPv4 на IPv6;
- префикс: ::ffff:0:0/96;
- пример: ::ffff:192.168.1.1.

b) Multicast Addresses (групповые адреса) — для отправки пакетов нескольким адресатам одновременно (заменяют broadcast-адреса IPv4). Включают:

- Assigned Multicast (присвоенные групповые адреса):
- зарезервированы для определённых групп устройств и сервисов;
- префикс: ff00::/8;
- пример: ff02::1 (все узлы в сегменте сети).

- Solicited-Node (адреса запрошенного узла):
- используются протоколом обнаружения соседей (Neighbor Discovery Protocol);
- префикс: ff02::1:ff00:0/104;
- пример: ff02::1:ff00:1234.

3. Важные примечания

- В IPv6 нет broadcast-адресов (в отличие от IPv4) — их функцию выполняют multicast-адреса.
- Anycast-адреса синтаксически идентичны unicast-адресам, но могут назначаться нескольким устройствам. Пакет, отправленный на anycast-адрес, направляется к ближайшему устройству с этим адресом.

4. Распространённые зарезервированные multicast-адреса

- ff02::1 — все узлы в локальном сегменте сети;
- ff02::2 — все маршрутизаторы в локальном сегменте сети;
- ff02::5 — все маршрутизаторы OSPF;
- ff02::1:2 — все DHCP-серверы/ретрансляторы.

Три основных типа функций

Обработка ошибок и отладка
(продолжение в следующем посте)

Обработка ошибок и отладка
(продолжение предыдущего поста)

Что такое обработка ошибок и отладка?

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

Методы обработки ошибок

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

Практики отладки

→ Вывод сообщений (print/log) — быстрая проверка с помощью логов или вывода в консоль.
→ Инструменты отладки — использование отладчиков в средах разработки, точек останова и трассировки стека.
→ Инструменты мониторинга — выявление проблем в реальном времени через журналы ошибок и оповещения.
→ Воспроизведение ошибки — выделение условий, при которых возникает сбой.

Распространённые типы ошибок

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

Рекомендации по предупреждению ошибок:

→ Проверка входные данные
→ Использование понятных сообщений об ошибках.
→ Запись ошибок с достаточной детализацией.
→ Отсутствие конфиденциальной системной информацию в сообщениях об ошибках.
→ Автоматизация оповещений о критических сбоях.

Forward Proxy vs Reverse Proxy

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

Прямой прокси-сервер располагается перед клиентом.

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

Обратный прокси-сервер находится перед сервером.

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

Простой способ запомнить: прямой прокси-сервер защищает клиента, обратный прокси-сервер — сервер.

Наглядно метод Крамера и вычисление определителя матрицы

Разница между типами токенов JWT и PASETO, используемых при аутентификации
(продолжение в следующем посте)

Разница между типами токенов JWT и PASETO, используемых при аутентификации
(продолжение предыдущего поста)

1. Определение и назначение

- JWT (JSON Web Token) — стандарт для передачи информации между двумя сторонами в формате JSON. Используется для аутентификации и передачи данных о пользователе.
- PASETO (Platform-Agnostic Security Tokens) — современная альтернатива JWT, разработанная для устранения уязвимостей JWT. Ориентирована на обеспечение безопасных по умолчанию настроек и чётких инструкций по реализации.

2. Структура токена

- JWT состоит из трёх частей:
- Header (заголовок) — указывает тип токена («JWT») и алгоритм подписи (например, «HS256»).
- Payload (полезная нагрузка) — содержит утверждения (claims) о пользователе и метаданные (например, userid, email, exp — время истечения).
- Signature (подпись) — обеспечивает целостность токена с помощью секретного ключа.

- PASETO имеет следующую структуру:
- Version (версия) — V1 или V2.
- Purpose (назначение) — локальный (local) или публичный (public) токен.
- Payload (полезная нагрузка) — может быть зашифрованной или в виде открытого текста.
- Footer (опционально) — содержит аутентифицированные метаданные для контекста.

3. Типы токенов

- JWT не разделяет токены по типам — все JWT подписываются и могут быть проверены с использованием одного и того же механизма.
- PASETO предлагает два типа токенов:
- Public Token (подписанный) — для безгосударственных систем, использует криптографию с открытым ключом.
- Local Token (зашифрованный) — для серверных сессий с состоянием, использует симметричное шифрование.

4. Механизмы безопасности

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

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

5. Механизмы отзыва токенов

- JWT: отзыв токенов сложен без внешних механизмов (например, чёрных списков, привязки токенов или специальных сервисов отзыва).
- PASETO: отзыв локальных токенов упрощён, так как сервер поддерживает состояние токенов.

6. Гибкость и сложность реализации

- JWT:
- высокая гибкость — подходит для различных архитектур;
- простая реализация, но подвержена неправильной настройке.
- PASETO:
- чётко определённые сценарии использования (локальные/публичные токены);
- чуть более сложная реализация, но обеспечивает большую безопасность.

7. Поддержка экосистемы

- JWT: широко распространён, имеет обширную библиотеку инструментов и поддержку.
- PASETO: поддержка растёт, но пока менее зрелая по сравнению с JWT.

8. Сценарии использования

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

McKinsey Global Institute опубликовал доклад, в котором озвучено, что уже сегодня ИИ-агенты и роботы могли бы автоматизировать до 57% всех рабочих часов в США, если компании радикально перестроят процессы. По расчетам аналитиков, под ударом в таком сценарии оказывается около 40% рабочих мест. При этом примерно треть нынешних профессий в США McKinsey относит к труднозаменимым: там критичны физическое присутствие, эмпатия, гибкое мышление и работа в непредсказуемой среде, а главным барьером масштабной автоматизации становятся не технологии, а политика, инвестиции и готовность бизнеса полностью переформатировать рабочие процессы.

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

Зато медсестры, сиделки, персонал по уходу, учителя, а также специалисты по обслуживанию и ремонту выглядят гораздо устойчивее. В таких профессиях значительная доля задач требует (не всегда сразу) физического труда, развитой моторики, эмпатии, наблюдательности и контекстного мышления — то, что современные системы имитируют хуже всего.
https://www.mckinsey.com/mgi/our-research/agents-robots-and-us-skill-partnerships-in-the-age-of-ai

Работа балансировщика нагрузки
(описание в следующем посте)

Работа балансировщика нагрузки
(продолжение предыдущего поста)

Балансировщик нагрузки - один из неотъемлимых компонентов высоконагруженного приложения. Он обеспечивает:
* Распределение нагрузки между серверами для предотвращения перегрузки.
* Высокую доступность за счёт исключения неработающих серверов из обработки запросов.
* Гибкость в маршрутизации запросов (разные пути направляются к разным группам серверов).
* Улучшение пользовательского опыта за счёт быстрого и надёжного обслуживания запросов.

Рассмотрим, как работает балансировщик нагрузки

1. Приём запросов от клиентов (Listener)

Процесс начинается с того, что клиенты (устройства, подключённые к интернету) отправляют запросы на балансировщик нагрузки. Запросы поступают на Listener (прослушиватель), который настроен на определённый порт и протокол (например, HTTP:80). Listener служит «точкой входа» для входящих запросов.

2. Маршрутизация запросов (Routing Rules & Policies)

После приёма запроса балансировщик определяет, куда его направить, используя правила маршрутизации (Routing Rules). Эти правила основаны на различных параметрах:
* путь (Path) в URL (например, /api/* или /images/*);
* хост (Host);
* заголовки (Header) HTTP-запроса.

На изображении показаны два основных правила:
* Rule 1: /api/\*** — направляет запросы, начинающиеся с `/api/`, в **Target Group 1 (API Servers).
* Rule 2: /images/\*** — направляет запросы, начинающиеся с `/images/`, в **Target Group 2 (Image Servers).

3. Распределение нагрузки по целевым группам (Target Groups)

Целевые группы (Target Groups) — это наборы серверов или ресурсов, которые обрабатывают запросы. На изображении есть две целевые группы:
* Target Group 1: API Servers — включает EC2 Instance A, EC2 Instance B и Container C. Обрабатывает API-запросы.
* Target Group 2: Image Servers — включает S3 Bucket и EC2 Instance D. Обрабатывает запросы к изображениям.

Когда запрос соответствует определённому правилу маршрутизации, он перенаправляется в соответствующую целевую группу.

4. Выбор конкретного сервера (алгоритмы балансировки)

Внутри целевой группы балансировщик выбирает конкретный сервер для обработки запроса, используя алгоритмы балансировки нагрузки. Пример алгоритма — Round Robin (циклическое распределение запросов между серверами).

Например, если клиент отправил запрос GET /api/users, процесс будет следующим:
1. Listener принимает запрос на порту 80.
2. Routing Rule определяет, что путь /api/users соответствует правилу /api/*.
3. Запрос перенаправляется в Target Group 1 (API Servers).
4. Балансировщик выбирает, например, EC2 Instance A для обработки запроса (на основе алгоритма Round Robin).
5. EC2 Instance A обрабатывает запрос и возвращает ответ клиенту.

5. Политики (Policies) для повышения надёжности и удобства

Для эффективной работы балансировщика используются политики (Policies):
* Health Checks (проверки работоспособности) — балансировщик регулярно проверяет состояние серверов в целевых группах (например, каждые 30 секунд, Threshold: 2). Если сервер не проходит проверку, он временно исключается из обработки запросов.
* Sticky Sessions (прилипающие сессии) — политика, которая привязывает клиента к одному серверу на время сессии. Это полезно для приложений, где важна непрерывность взаимодействия (например, корзины покупок). На изображении эта политика включена для Target Group 2.

6. Обработка различных типов ресурсов

Балансировщик нагрузки может работать не только с EC2-инстансами, но и с другими ресурсами:
* EC2 Instance — виртуальные машины в облаке.
* Container — контейнеры (например, Docker), которые могут быстро масштабироваться.
* S3 Bucket — хранилище объектов (например, для статических файлов, изображений).

Microsoft представляет будущее, в котором ИИ управляет всем на компьютере. Более того, компания сама активно внедряет ИИ в производственные процессы: ранее в этом году генеральный директор Microsoft Сатья Наделла заявил, что до 30% кода "некоторых проектов" написано ИИ. Однако сами сотрудники Microsoft относятся к внедрению ИИ не столь однозначно.

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

Microsoft заявляет, что 91% её команд разработчиков используют GitHub Copilot, но источники поделились данными, которые свидетельствуют о том, что в некоторых подразделениях компании общий уровень внедрения инструментов ИИ гораздо ниже — ближе к 51% разработчиков, которые сообщили Stack Overflow, что теперь профессионально используют инструменты ИИ каждый день.

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

Один источник в Microsoft рассказал, что некоторые инструменты не так хороши, как их представляют. "ES Chat экономит мне время, потому что я им не пользуюсь", — пошутил собеседник.

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

https://www.theverge.com/tech/831379/microsoft-developer-ai-usage-stats-notepad

Сетевые протоколы, которые работают на разных уровнях сетевой модели OSI
(описание в следующем посте)

Вкратце об уровнях сетевой модели OSI
(продолжение предыдущего поста)

🔌 Уровень 1 — Физический (Physical)

Передаёт необработанные биты по физическим каналам связи.
Протоколы: 10BASE‑T, DSL, ISDN, USB, RS‑232, SONET/SDH.
Устройства: кабели, концентраторы (hubs), повторители (repeaters).

🔗 Уровень 2 — Канальный (Data Link)

Обеспечивает передачу данных между узлами, MAC‑адресацию и формирование кадров.
Протоколы: Ethernet, PPP, STP, VLAN, LLDP.
Устройства: коммутаторы (switches), мосты (bridges).

🗺 Уровень 3 — Сетевой (Network)

Отвечает за маршрутизацию и логическую адресацию.
Протоколы: IPv4/IPv6, OSPF, EIGRP, RIP, MPLS, ICMP, NAT.
Устройства: маршрутизаторы (routers), коммутаторы L3 (L3 switches).

⚙️ Уровень 4 — Транспортный (Transport)

Гарантирует надёжную сквозную передачу данных.
Протоколы: TCP, UDP, SCTP, DCCP.
Ключевые элементы: порты, сегментация, управление потоком (flow control).

📊 Уровень 5 — Сеансовый (Session)

Устанавливает, поддерживает и завершает сеансы связи.
Протоколы: SIP, SMB, RPC, PPTP, TLS.
Ключевые элементы: аутентификация, управление сеансами.

🎛 Уровень 6 — Представительный (Presentation)

Форматирует и преобразует данные для приложений.
Функции: шифрование, сжатие, кодирование данных.
Примеры: шифрование SSL/TLS, JPEG, MP3, ASCII, JSON.

🎨 Уровень 7 — Прикладной (Application)

Предоставляет сервисы непосредственно пользовательским приложениям.
Протоколы: HTTP/S, DNS, DHCP, SSH, SMTP, FTP, SNMP.
Примеры использования: просмотр веб‑страниц, электронная почта, передача файлов.

Вопрос дня

Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(описание в следующем посте)

Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(продолжение предыдущего поста)

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

Компоненты

→ Представление (UI) → Отображает данные и обрабатывает взаимодействия пользователя (веб‑страницы, экраны мобильных приложений).
→ Контроллер → Получает ввод от Представления, интерпретирует его, вызывает Модель или обновляет Представление.
→ Модель → Содержит данные приложения и бизнес‑логику; уведомляет Представление об изменениях состояния.
→ База данных / Хранилище → Постоянное хранилище, из которого Модель считывает данные и в которое записывает их.

Поток данных (упрощённо)

→ Представление —(ввод пользователя)→ Контроллер —(вызывает)→ Модель —(считывает/записывает)→ База данных
→ Модель —(уведомляет)→ Представление —(отображает обновлённые данные)→ Пользователь

Преимущества

→ Чёткое разделение ответственностей → упрощение тестирования и параллельной разработки.
→ Повторное использование компонентов — несколько Представлений могут использовать одну и ту же Модель.
→ Более чёткая организация логики интерфейса по сравнению с бизнес‑логикой.

Недостатки

→ Может стать избыточным при большом количестве контроллеров/представлений в крупных приложениях.
→ Возможна тесная связность, если ответственности не разделены чётко.
→ Не всегда оптимально подходит для высокоинтерактивных клиентских интерфейсов без адаптации (например, MVVM или Flux могут быть предпочтительнее).

Распространенные рекомендации по использованию

→ Делайте Контроллеры «лёгкими» — делегируйте бизнес‑логику Моделям или сервисам.
→ Представления без бизнес-логики только для отображения данных и передачи событий
→ Применение шаблона Наблюдатель (observer) или привязки данных, чтобы Представления автоматически обновлялись при изменении Модели.
→ Отедбные юнит‑тесты для Моделей и Контроллеров
→ В крупных проектах организуйте код по функциональным возможностям, а не только по уровням MVC.

Глава Alphabet (Google) Сундар Пичаи сравнил вайб-кодинг с ростом популярности блогов и YouTube, но предупредил, что явление не должно затрагивать критически важные системы.

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

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

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

https://www.techspot.com/news/110434-google-ceo-vibe-coding-reshaping-who-gets-write.html