Интересное чтиво про производительность .NET 7 - судя по всему некоторые проекты могут получить буст на десятки процентов, просто обновившись до .NET 7 #dotnet #start
https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/

Лёгкая, понятная и удобная штука нарисовать простые временнЫе диаграммы #ui #tools
https://swimlanes.io/

MagicOnion - RPC Framework based on gRPC, по заверениям автора - быстрый и компактный. У того же автора есть MessagePipe (pipeline сообщений) и MemoryPack (бинарный сериализер, который в 10 раз быстрее MessagePack). #dotnet

Отличная штука для реверс-инжиниринга протоколов, данных и даже исполнимых файлов (включая пост-обработку и экспорт) #tools
https://github.com/WerWolv/ImHex

Длинночтиво по структурам .net, garbage collector и другим кишкам от Maoni Stephens (главной разработчицы GC в .NET) #dotnet
https://github.com/Maoni0/mem-doc

Решение задачи коммивояжера с помощью самоорганизующихся карт на #python
https://github.com/diego-vicente/som-tsp

Удивительно красивый проект - вероятностный язык программирования, в котором программы представляют собой комбинации правил перезаписи, а вывод выполняется посредством распространения ограничений. С полным объяснением как это происходит, на примере генерации рандомных правдоподобных зданий #dotnet
https://github.com/mxgmn/MarkovJunior

Интересный подход к хранению дополнительных данных в enum дотнета. Используется #sourcegenerator для compile-time генерации исходников. #dotnet
https://github.com/MMaximus111/StaticDictionaries

Design Patterns Library - с несколькими примерами на C# по каждому паттерну #dotnet

upd: взгляд с другой стороны

ULID - реализация на C# Universally Unique Lexicographically Sortable Identifier вида 01ARZ3NDEKTSV4RRFFQ69G5FAV #dotnet

MassTransit - отличная шина сообщений, которая умеет работать как InMemory (например внутри монолита), так и использовать RabbitMQ/Azure/SQS для микросервисной архитектуры. Вообще думаю, что если есть шанс масштабирования проекта - можно пилить CQRS сразу с использованием MassTransit - потом будет значительно легче распилить на микросервисы и задействовать вышеуказаные брокеры сообщений.

Умеет всё, что полагается - адресную и broadcast отправку сообщений, хорошее логирование и интеграцию в MS DI, возможность навесить интерцепторы (например для диагностики) и т.д. Также есть возможность назначить сообщениям correlation id, если множество сообщений имеет отношение к какой-то одной операции. Уже есть встроенный mediator, который тоже интегрируется соответственно как с MS DI так и с MassTransit. Есть пакет Automatonymous, который представляет собой state-машину для реализации в т.ч. паттерна Saga.

Вообщем проект живёт и развивается, все детские болячки уже вылечены. Настоятельно рекомендуется к использованию :) #dotnet

upd: вдогонку - твиттер-тред по настройке RabbitMQ

Регулярно читая в соседних каналах боль людей, которые используют штатные EF Core миграции - никак не могу донести до них и понять, почему они не используют прекрасный инструмент FluentMigrator.

В нём тоже есть всё что нужно, но это всё не требует костылей и телодвижений - все миграции являются code first. Помимо штатных средств работы с полями, таблицами, индексами - и если возникнет нужда сделать что-либо очень специфичное (например провести конвертацию данных во время миграции) - можно сделать и это да, внутри миграции и внутри транзакции. Ну и плюсом - миграции из коробки поддерживаются для полутора десятков СУБД. Использовал FluentMigrator лично на нескольких проектах, свои новые проекты (если они подразумевают работу с БД) - всегда начинаю с FluentMigrator :)) #dotnet

Новый атрибут в .net 7, который показывает как студии расцвечивать строку в IDE #dotnet #net7

Orleans - уже третий год всё хочу попробовать на каком-нибудь живом проекте этот прекрасный фреймворк для создания масштабируемых приложений на модели акторов (эта тема достаточно старая кстати, родилась ещё в 70-ые годы).

Вкратце, простым языком и для тех кто не вкурсе, суть идеи фреймворка: вынести логику и экземпляры классов (grain's) в отдельные контейнеры (silo = дословно "бункер"), которые (опционально) живут на других узлах, которые в свою очреедь объединяются в кластер. Клиент взаимодействует с кластером по эффективному бинарному протоколу, получая отказоустойчивость (если сдох один silo - запрошенный grain оживёт в другом), балансировку нагрузки и прочие штуки. Что ещё интересно: в Orleans используется compile-time генерация прокси-DTO для сериализации параметров и результатов и поддерживается версионирование grain'ов - в одном silo могут жить grain'ы для разных версий API.

Из коробки можно сделать много чего - например, задавать срок жизни grain'ов и можно в несколько строк кода или сделать свой strategy placement, который объяснит инфраструктуре как делить grain's между silo по разным критериям (например grain's одного клиента в один silo, grain's всех остальных - в другой). Традиционно для MS DI это всё решается через Configure<T>.

Также есть опциональный persistance для grain'ов, который может быть изкоробочный, а можно написать свою реализацию (там несложно), что в итоге приводит к тому что grain при рестарте silo и запросе его клиентом оживает с уже нужным состоянием.

Например, боты для телеги и других сетей отлично ложаться на механизм акторов - state актора храница в БД, по id юзера поднимается в любой момент, изменяется и пишется обратно в БД, при отсутствии активности юзера grain диспозица (время жизни простаивающего без работы актора задаётся) и как результат - хоть миллион юзеров акторов живёт и работает на одном silo.

За прошедшие три года Microsoft доложил в комплект полтора десятка примеров, написал приличную документацию, также никуда не делись tutorials (и несмотря на то что там 2017й год - они по прежнему актуальны), прикрутил мониторинг, причесал и интегрировал логирование. Сам Microsoft использует Orleans как бакенд для игры Halo. И уже апдейтнул его до .NET 7. Вобщем выглядит всё это очень красиво.

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

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

Akka.NET - заявляется, что по capability это порт фреймворка Akka с Java/Scala и оно умеет 50 million msg/sec on a single machine. Small memory footprint; ~2.5 million actors per GB of heap, что прямо таки интересно. Несколько статей-tutorial'ов (помимо штатной доки конечно):
Неплохое пошаговое руководство + исходники.
Actor-Model System with Akka.
Working with Akka.NET and Akka.Cluster
First steps, Calling actors from another actor и другие статьи A.Brandão Lustosa

Proto.Actor - более простой фреймворк на мой взгляд (по сравнению с Orleans или Akka), но позволяет без каких либо телодвижений попробовать как это работает. Примера на основной странице хватит, чтобы получить рабочий проект. Примеров там штук 30, на любой вкус. Тоже умеет persistence состояний в разные места и кластеризацию с помощью кубера или Consul.
#dotnet