C# - язык года по версии TIOBE

Рейтинг TIOBE второй раз за 3 года назвал C# языком программирования года (2025 года). В комментарии от TIOBE отмечается, что "C# заслужил это звание, показав наибольший годовой рост в рейтинге. За эти годы язык претерпел фундаментальные изменения. С точки зрения проектирования языка, C# часто был одним из первых, кто перенимал новые тенденции среди основных языков. В то же время он успешно совершил два крупных парадигмальных сдвига: от языка, предназначенного только для Windows, к кроссплатформенному, и от языка, принадлежащего Microsoft, к языку с открытым исходным кодом. C# постоянно развивался в нужный момент."

Среди других победителей - Perl, который, поднялся с 32-й позиции на 11-ю и вновь вошел в топ-20, и R - вернулся в топ-10 во многом благодаря продолжающемуся росту в области науки о данных и стат. вычислений.
Среди проигравших - Go - окончательно потерял место в топ-10 в 2025 г, и Ruby, который выпал из топ-20.

https://www.tiobe.com/tiobe-index/

Базы данных NoSQL
(продолжение в следующем посте)

Базы данных NoSQL
(продолжение предыдущего поста)

Когда говорят о NoSQL, то естественно имеют ввиду базы данных, которые не используют SQL для выполнения запросов к БД. Однако в реальности мир NoSQL очень многогранен, и каждая NoSQL-БД оптимизирована под конкретные задачи. Рассмотрим основные типы БД NoSQL.

1. MongoDB (Document Store)
- Тип: Документоориентированная БД.
- Особенности:
- использует формат BSON (Binary JSON);
- схема не фиксирована (schema-less);
- горизонтальное масштабирование (sharding);
- репликация для высокой доступности.
- Сценарии использования:
- системы управления контентом (CMS);
- управление каталогами.

2. Cassandra (Wide-Column Store)
- Тип: Колоночная БД.
- Особенности:
- столбцы могут варьироваться в разных строках (wide-column);
- распределённая архитектура;
- язык запросов CQL (SQL-подобный для NoSQL);
- оптимизирована для аналитических запросов.
- Сценарии использования:
- управление временными рядами данных;
- рекомендательные системы.

3. Redis (Key-Value Store)
- Тип: Хранилище «ключ-значение».
- Особенности:
- работает в оперативной памяти (in-memory store);
- поддерживает сложные структуры данных;
- механизмы персистентности (RDB, AOF);
- репликация (primary-replica).
- Сценарии использования:
- кэширование данных;
- управление сессиями;
- таблицы лидеров в играх (gaming leaderboard).

4. Couchbase (Document Store with Key-Value Capabilities)
- Тип: Гибридная БД (документоориентированная + хранилище «ключ-значение»).
- Особенности:
- работает в режиме памяти (memory first);
- репликация между центрами обработки данных (XDCR);
- сочетает операции с документами и хранилищем «ключ-значение».
- Сценарии использования:
- системы управления контентом (CMS);
- платформы электронной коммерции.

5. Neo4j (Graph DB)
- Тип: Графовая БД.
- Особенности:
- поддерживает ACID-транзакции;
- использует язык запросов Cypher;
- индексация без дополнительных таблиц (index-free adjacency);
- кластеризация (HA cluster).
- Сценарии использования:
- социальные сети;
- системы обнаружения мошенничества (fraud detection).

6. Amazon DynamoDB (Key-Value and Document Store)
- Тип: Хранилище «ключ-значение» с поддержкой документов.
- Особенности:
- автоматическое масштабирование;
- управление через AWS;
- распределение данных между узлами;
- поддержка DynamoDB Streams.
- Сценарии использования:
- бессерверные приложения (serverless applications);
- IoT-приложения.

7. Apache HBase (Wide-Column Store)
- Тип: Колоночная БД.
- Особенности:
- основана на Google Bigtable;
- интеграция с Hadoop;
- автоматическое шардирование (auto-sharding);
- сильная согласованность (strong consistency).
- Сценарии использования:
- хранилища данных (data warehouse);
- крупномасштабная обработка данных (large-scale data processing).

8. Elasticsearch (Search Engine)
- Тип: Поисковая система на основе документов.
- Особенности:
- построена на Apache Lucene;
- ориентирована на документы;
- шардирование и репликация;
- RESTful API.
- Сценарии использования:
- полнотекстовый поиск (full-text search);
- анализ логов и событий (log and event data analysis).

9. CouchDB (Document Store)
- Тип: Документоориентированная БД.
- Особенности:
- обеспечивает согласованность данных без блокировок;
- использует RESTful API;
- модель согласованности «в конечном счёте» (eventual consistency).
- Сценарии использования:
- мобильные приложения;
- системы управления контентом (CMS).

В итоге каждая NoSQL БД оптимизирована под конкретные задачи:
- документоориентированные (MongoDB, CouchDB) — для веб-приложений и CMS;
- колоночные (Cassandra, HBase) — для аналитических запросов и временных рядов;
- хранилища «ключ-значение» (Redis, DynamoDB) — для кэширования и сессий;
- графовые (Neo4j) — для моделирования сложных связей (социальные сети, рекомендации);
- поисковые (Elasticsearch) — для полнотекстового поиска и анализа логов.

Lenovo представила первый в мире складной игровой ноутбук - Legion Pro Rollable
Его главная особенность - уникальный сворачиваемый OLED-экран. Дисплей диагональю 16 дюймов может плавно расширяться с двух сторон до 21,5 или даже 24 дюймов.
Правда, с учетом начинки (высокопроизводительная начинка от Intel и видеокарта NVIDIA GeForce RTX 5090 и т.д.) цена, наверное, будет космическая

https://hi-tech.mail.ru/news/140485-lenovo-predstavila-pervyj-v-mire-skladnoj-igrovoj-noutbuk-i-portativnuyu-konsol-na-steamos

Ограничение скорости по API (rate limiting)
(продолжение в следующем посте)

Ограничение скорости по API (rate limiting)
(продолжение предыдущего поста)

Ограничение скорости по API (rate limiting) — это механизм контроля числа запросов к API, который защищает сервер от перегрузки и злоупотреблений. На изображении показаны основные методы ограничения скорости, каждый из которых работает по-своему:

1. Time Windows (временные окна):
* устанавливает фиксированные интервалы времени, в течение которых ограничивается количество запросов;
* если лимит запросов в заданный интервал превышен, система возвращает ошибку «RATE LIMIT EXCEEDED!»;
* подходит для контроля частоты обращений к API.

2. Quota-Based (квотирование):
* задаёт общее количество запросов, разрешённых за определённый период времени (например, в день или месяц);
* как только квота исчерпана, дальнейшие запросы блокируются с сообщением «REQUEST LIMIT REACHED!»;
* позволяет равномерно распределить нагрузку на API в течение заданного периода.

3. Token Bucket (алгоритм «ведра с токенами»):
* использует систему токенов для контроля потока запросов: клиент может отправлять запросы только при наличии токенов;
* токены накапливаются с фиксированной скоростью, что обеспечивает равномерный доступ к API;
* если токенов нет, запросы задерживаются до их появления;
* эффективно сглаживает пики нагрузки.

4. IP-Based Rate (ограничение по IP-адресу):
* ограничивает количество запросов, исходящих с одного IP-адреса;
* помогает предотвратить злоупотребления со стороны отдельных клиентов или ботов;
* система анализирует IP-адрес источника запроса и блокирует дальнейшие обращения, если лимит превышен.

5. API Key-Based (ограничение по ключу API):
* связывает лимиты с конкретным API-ключом, выданным клиенту;
* позволяет настраивать индивидуальные квоты и интервалы для разных пользователей или приложений;
* обеспечивает гибкое управление доступом — например, премиум-клиентам можно выделить больше запросов;
* защищает от несанкционированного использования API.

6. Exponential Backoff (экспоненциальное замедление):
* механизм, который заставляет клиента увеличивать интервал между повторными запросами в случае ошибок или превышения лимитов;
* интервал ожидания растёт экспоненциально с каждой неудачной попыткой;
* снижает нагрузку на сервер при массовых ошибках или перегрузках.

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

Анализ исправления ошибок в ядре Linux - в среднем ошибки замечают через 2 года

В результате анализа исправления 125 тысяч ошибок, помеченных в Git-репозитории тегом "Fixes:", оказалось, что среднее время обнаружения ошибок в ядре Linux составило 2.1 года. Если рассматривать только ошибки, исправленные в 2025 году, данный показатель составил 2.8 года.

30% ошибок были исправлены теми же разработчиками, что и внесли ошибки. 56.9% ошибок устраняют в течение года. 13.5% ошибок оставались незамеченными более 5 лет (если рассматривать только ошибки, исправленные в 2025 году - 19.4%). Из-за неравномерности распределения медианное время существования ошибки в коде ядра составило 8 месяцев для выборки с 2005 года и 1 год для ошибок, исправленных в 2025 году. Наиболее долго сохранявшейся в коде ошибкой стало переполнение буфера в ethtool, устранённое спустя 20.7 лет.

Cреднее время обнаружения ошибок, связанных с состояниями гонки, составило 5.1 лет, целочисленным переполнением - 3.9, обращением после освобождения памяти - 3.2, переполнением буфера и утечкой памяти - 3.1, подсчётом ссылок - 2.8, разыменованием нулевого указателя и взаимными блокировками - 2.2 года.

https://pebblebed.com/blog/kernel-bugs

Google добавил Gemini 3 в Gmail - теперь ИИ будет копаться в переписке за пользователей

Google запустил в Gmail новую модель Gemini 3, превратив почтовый клиент в "персонального проактивного ассистента" для 3 миллиардов пользователей.

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

Функция Help Me Write, которая помогает писать письма с нуля или редактировать черновики, теперь доступна всем бесплатно. Suggested Replies (обновленная версия Smart Reply) анализирует контекст переписки и предлагает ответы в стиле пользователя. Proofread проверяет грамматику, тон и стиль перед отправкой — но эта функция только для подписчиков Google AI Pro и Ultra.

Добавлен AI Inbox - своего рода персональный фильтр, который отсеивает шум и выделяет важное (пока доступен только тестировщикам, широкий запуск обещают в ближайшие месяцы).

Новые функции начали обкатывать в США на английском языке. Часть возможностей бесплатна, расширенные — для подписчиков Google AI Pro и Ultra. Другие регионы и языки — позже.

https://blog.google/products-and-platforms/products/gmail/gmail-is-entering-the-gemini-era/

PS. Интересно, как скоро все эти данные можно будет увидеть в ответах Gemini или в открытом поиске...

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

Архитектура микросервисов
(продолжение предыдущего поста)

Архитектура микросервисов состоит из ряда звеньев/уровней. Рассмотрим типичную архитектуру микросервисов.

1. Уровень клиента (Client)
На верхнем уровне находятся клиентские приложения, которые взаимодействуют с системой:
* Web (веб-браузер);
* Mobile (мобильное приложение);
* PC (десктопное приложение).

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

2. Промежуточный уровень (инфраструктура доставки контента и балансировки нагрузки)
* CDN (Content Delivery Network) — распределённая сеть доставки статического контента (изображений, CSS, JS-файлов), ускоряет загрузку за счёт кэширования данных ближе к пользователю.
* Static Content — хранилище статических ресурсов, обслуживаемых через CDN.
* Load Balancer (балансировщик нагрузки) — распределяет входящие запросы между микросервисами для оптимизации производительности и обеспечения отказоустойчивости.

3. API Gateway (шлюз API)
* Единая точка входа для клиентских запросов.
* Выполняет маршрутизацию запросов к соответствующим микросервисам.
* Агрегирует ответы от микросервисов.
* Обеспечивает сквозные функции: аутентификацию, авторизацию, мониторинг, логирование.
* Взаимодействует с Identity Provider (поставщиком идентификации) для управления доступом пользователей.

4. Уровень микросервисов (Microservices)
* Система разбита на домены (Domain 1, Domain 2) — логически связанные группы сервисов, отвечающие за отдельные бизнес-задачи.
* Внутри доменов работают микросервисы (Service A, Service B, Service C):
* каждый сервис — независимый модуль с собственной логикой и базой данных;
* сервисы взаимодействуют друг с другом через API или брокер сообщений;
* могут разрабатываться, развёртываться и масштабироваться независимо.

5. Сервисная регистрация и обнаружение (Service Registry and Discovery)
* Хранит информацию о всех запущенных микросервисах (IP-адреса, порты, статусы).
* Позволяет сервисам динамически находить друг друга без жёсткой привязки к адресам.
* Ключевой компонент для обеспечения гибкости и масштабируемости системы.

6. Координация сервисов (Service Coordination, Zookeeper)
* Обеспечивает согласованность работы микросервисов.
* Управляет распределёнными блокировками, конфигурациями и состоянием сервисов.
* Использует Apache Zookeeper или аналогичные инструменты.

7. Брокер сообщений (Message Broker)
* Обеспечивает асинхронную коммуникацию между сервисами.
* Примеры: RabbitMQ, Kafka, ActiveMQ.
* Позволяет сервисам обмениваться событиями и сообщениями без прямого соединения.
* Повышает устойчивость системы к временным сбоям.

8. Уровень хранения данных (Databases)
* Каждый домен или сервис может использовать собственную базу данных (Database A, Database B):
* обеспечивает изоляцию данных и независимость развёртывания;
* позволяет выбирать оптимальные СУБД для каждой задачи (например, MongoDB для документов, PostgreSQL для реляционных данных).

9. Дополнительные компоненты
* Identity Provider — управляет учётными записями пользователей, аутентификацией и авторизацией.
* API Gateway, Load Balancer и CDN работают совместно для обеспечения высокой доступности и безопасности системы.

В итоге микросервисная архитектура, представленная на схеме, обеспечивает:
* модульность (каждый сервис независим);
* масштабируемость (можно масштабировать отдельные сервисы);
* устойчивость (сбои в одном сервисе не влияют на работу других);
* гибкость (можно использовать разные технологии для разных сервисов);
* эффективное распределение нагрузки (благодаря балансировщику и CDN);
* безопасный доступ (через API Gateway и Identity Provider).

Сервис по поиску работы LinkedIn опубликовал список из 25 профессий, на которые за последние три года спрос в США вырос сильнее всего. Лидерами рейтинга оказались ИИ‑инженеры.

Весь топ-5:
1. Artificial Intelligence Engineers (ИИ‑инженеры)
2. AI Consultants and Strategists (ИИ‑консультанты и стратеги)
3. New Home Sales Specialists (специалисты по продаже недвижимости)
4. Data Annotators (специалисты по разметке данных для обучения ИИ)
5. AI/Machine Learning Researchers (исследователи ИИ и машинного обучения)

Таким образом, в топ-5 есть лишь одна специальность, не связанная с ИИ.

В целом опубликованный LinkedIn список показывает, что связанные с ИИ‑профессии стали наиболее востребованными на рынке в последние годы.

Из специальностей, связанных с ИТ, в 25 также Data center technicians (технические специалисты дата‑центров), что опять же связано с ИИ.

Другие данные LinkedIn выявили проблемы на рынке труда для многих людей: количество соискателей на одну открытую вакансию в среднем увеличилось более чем вдвое с весны 2022 года, в то время как объем найма по состоянию на ноябрь был на 23% ниже допандемического уровня.


https://www.linkedin.com/pulse/linkedin-jobs-rise-2026-25-fastest-growing-roles-us-linkedin-news-dlb1c/
https://www.businessinsider.com/fastest-growing-jobs-in-the-us-linkedin-2026-1

Сервис DB-Engines обновил рейтинг популярности систем баз данных, который отслеживает популярность 428 различных СУБД.
Методика расчета рейтинга учитывает популярность запросов в поисковых системах, число результатов в поисковой выдаче, объем обсуждений на популярных дискуссионных площадках и социальных сетях, число вакансий в агентствах по найму персонала и упоминаний в профилях пользователей.

Первые 5 мест продолжают занимать Oracle, MySQL, Microsoft SQL Server, PostgreSQL и MongoDB. По сравнению с январем 2025 года в десятке лидеров произошли две перестановки: Elasticsearch спустился с 8 на 10 место, а Databricks поднялся с 13 на 8 место. Остальные лидеры сохранили свои позиции в рейтинге, но снижение популярности наблюдается для MySQL (-130 баллов), MS SQL Server (-92), Elasticsearch (-27), MongoDB (-25), Oracle (-21) и Redis (-9). Рост популярности фиксируется для Snowflake (+53), Databricks (+53) и PostgreSQL (+3).

https://db-engines.com/en/ranking

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

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

1. Single Node architecture (одноузловая архитектура):
* состоит из одного узла (Primary Node), который включает компоненты: compute1 (вычисления), cache (кэш) и data1 (хранилище данных);
* все операции (от обработки запросов до хранения данных) выполняются на одном узле;
* проста в реализации, но имеет ограничения по масштабируемости и отказоустойчивости — если узел выходит из строя, вся система становится недоступной;
* подходит для небольших проектов с низкой нагрузкой.

2. Shared Nothing Architecture (архитектура без общего доступа):
* включает несколько независимых узлов (Node 1, Node 2, Node 3), каждый из которых имеет собственные компоненты: compute (вычисления), cache (кэш) и data (локальное хранилище данных);
* запросы от клиента распределяются с помощью Load Balancer (балансировщика нагрузки) между узлами;
* узлы не делят ресурсы — каждый работает автономно, что обеспечивает высокую масштабируемость и отказоустойчивость (выход из строя одного узла не влияет на работу остальных);
* используется в системах с высокой нагрузкой, где требуется распределение нагрузки и независимость узлов (например, в распределённых СУБД).

3. (Decoupled) Shared Nothing Architecture (развязанная архитектура без общего доступа):
* похожа на классическую Shared Nothing, но имеет разделение на вычислительные узлы (с компонентами compute и cache) и узлы хранения (Storage Nodes с компонентами data);
* вычислительные узлы взаимодействуют с узлами хранения через сеть;
* такая декомпозиция позволяет ещё лучше масштабировать систему — можно независимо наращивать вычислительные мощности и объём хранилища;
* подходит для сложных распределённых систем, где требуется чёткое разделение между обработкой и хранением данных (например, в Big Data решениях).

4. Shared Storage Architecture (архитектура с общим хранилищем):
* состоит из нескольких вычислительных узлов (Node 1, Node 2, Node 3 с компонентами compute и cache), которые обращаются к единому централизованному хранилищу данных — Object Store (например, AWS S3);
* балансировщик нагрузки (Load Balancer) распределяет запросы между вычислительными узлами;
* все узлы имеют доступ к одним и тем же данным, что упрощает синхронизацию, но создаёт «бутылочное горлышко» на уровне хранилища при высокой нагрузке;
* преимущества: простота управления данными, централизованное хранение;
* недостатки: потенциальная точка отказа (если хранилище становится недоступным), ограничения по пропускной способности хранилища;
* применяется в системах, где важна централизованность данных, но не требуется экстремальная масштабируемость (например, в корпоративных системах с умеренной нагрузкой).

Ключевые отличия между архитектурами:
* Single Node — минимализм, простота, низкая отказоустойчивость;
* Shared Nothing — независимость узлов, высокая масштабируемость, но сложность синхронизации данных;
* (Decoupled) Shared Nothing — чёткое разделение ролей (вычисления/хранение), максимальная гибкость масштабирования;
* Shared Storage — централизованное управление данными, простота, но потенциальные проблемы с производительностью и отказоустойчивостью.

ПО итогам голосования на канале на звание языка 2025 года победил C#, с чем мы его поздравляем.
Я лично голосовал за Python и Rust, хотя ни один из них не является моим любимым языком. За Python голосовал в основном из-за ML/Deep Learning/AI/Data Science и за то, что Python все чаще рассматривается в качестве стартового
За Rust голосовал из-за его внедрения в Windows, Linux, Android, плюс этот язык все чаще применяется как базовый для приложений, где требуется высокая производительность, которые иначе разрабатывались бы на C/C++. Да здесь есть немало хайпа. Тем не менее экосистема Rust развивалась в прошлом году очень активно
Мог бы проголосовать еще за Go - тоже очень активно внедряется, особенно активно откусывает долю PHP в корпорат. секторе. Но это развитие было менее выраженным
В конечном счете, голосовал за Python и Rust только из-за развития экосистемы. С точки зрения же непосредственно развития самого языка ни один язык из списка голосования, по моему мнению, ничего экстраординарного не показал