Структуры данных, которые уже присутсвуют в библиотеке классов, отлично решают задачи заявленные перед ними. Но что делать, если понимаешь что придётся столкнуться с задачей, которая решается очередью с приоритетом? Здесь уже нет готового SDK, и придётся либо тянуть чужую реализацию (или целую библиотеку) себе в проект, либо всё писать самому на коленке. Давайте сравним хотя-бы в первом приближении на базе какой структуры данных оптимальнее, в плане скорости работы и используемой памяти, реализовать очередь с приоритетом. Попробуем понять, что нам больше подойдёт двусвязный список (LinkedList), массив, список (List) и SortedSet. В большинстве случаев список, будет универсальной структурой данных. Но так ли это будет и при решении нашей проблемы?

От переводчика: рекомендую к Вашему внимаию перевод статьи Reuben Bond-а Performance Tuning for .NET Core. Тут, пожалуй, описаны почти все последние инструменты dotnet, которые помогут вашим приложениям достичь новых высот производительности. Статья интересна ещё и ссылками, которые просто must read!

Кто-то из вас, возможно, знает, что я трачу все свое время на то, чтобы завершить разработку новой .NET библиотеки сериализации. Сериализатор, должен вам сказать, оказался очень сложным в реализации. Он должен быть надежным, гибким и быстрым, безупречным в работе. Я не буду убеждать вас, что библиотеки сериализации должны быть быстрыми - в этом посте это само собой разумеется. Вот несколько советов из моего опыта по оптимизации производительности Hagar. Большая часть этих советов применима к другим типам библиотек или приложений.

Что такое паттерн предохранитель?

При разработке приложений enterprise уровня нам часто приходится вызывать внешние сервисы и ресурсы. Этими службами могут быть сетевые папки, сервера баз данных или веб-службы. Всякий раз, когда мы обращаемся к этим сервисам, существует вероятность того, что проблема с сетью или самой службой может вызвать сбой нашей системы. Один из способов работы со сбоями вызываемой службы состоит в том, чтобы ставить запросы в очередь и периодически повторять попытки. Это позволяет нам продолжать обработку запросов, пока сервис снова не станет доступным. Тем не менее, если в сети или сервисе возникают проблемы, то такие попытки повторной отправки запроса не помогут восстановить службу, особенно если она находится под повышенной нагрузкой. Такие запросы могут нанести еще больший ущерб и помешать работе служб. Если мы знаем, что потенциально могут быть проблемы со службой, мы можем помочь решить некоторые проблемы, внедрив шаблон предохранитель в клиентском приложении.

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

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

Вы когда-нибудь пытались ожидать завершение выполнения задачи внутри блока lock на C#? Если Вам приходила в голову такая идея но никак не доходили руки до воплощения, то предлагаю не спешить. Во-первых компилятор не даст это сделать, а во-вторых у разработчиков dotnet есть другие возможности решать проблему блокировки раделяемых ресурсов в асинхронном коде. Предлагаю с ними ознакомится под катом.

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

Предисловие переводчика: если Вам хочется попробовать немного Machine Learning и не хочется выходить за пределы родного dotnet - Вы можете воспользоваться фреймворком Accord Net. Статья за авторством César Souza создателя вышеупомянутого фреймворка поможет сделать первые шаги в этом направлении и в качестве примера решить небольшую задачку при помощи алгоритма деревьев принятия решений.

Ещё хотел бы добавить замечательный перевод Андрея Будая проясняющий работу алгоритмов ID3 и C4.5 и математику стоящую за ними

Как можно отделить юнит тесты от механизма Dependency Injection? В этой статье описывается паттерн юнит тестов (unit test), называемый автомок (Auto-mocking Container). Его можно использовать для устранения проблемы хрупких тестов (Fragile Test), которые так часто происходят при создании тестируемой системы (system under tests - SUT) при помощи антипаттерна Мать объекта. На этот вопрос отвечает Mark Seemann.

Предисловие переводчика: Уже не помню, что сподвигло меня заинтересоваться этим паттерном, скорее всего это то что в какой-то момент мне пришлось столкнуться с javascript библиотекой redux-saga.
Знакомство началось с описания паттерна от Bernd Rücker и прекрасной презентации Caitie McCaffrey. После ознакомления с этими материалами у меня всё ещё оставались вопросы. Очень хотелось увидеть этот код “в живую” в виде какого либо PoC-a.

Вашему вниманию представлена статья Clemens Vasters-a, которая поможет разобраться уже в деталях с конкретной реализацией.

Сегодня был оживленный день в тех уголках Twitter-а, где обсуждался паттерн Saga. Существует несколько .NET фреймворков, которые используют термин «сага» и которые представляют из себя реализацию конечного автомата или воркфлоу.

Проблема в том, что это всё не сага!

Что такое паттерн сага?

Сага - это шаблон управления сбоями. Saga появилась из осознания того, что долгоживущие транзакции (первоначально даже транзакции внутри базы данных), и особенно далеко распределенные транзакции, пересекающие границы местоположения и / или доверия, не могут быть обработаны с использованием классической модели ACID с двухфазной фиксацией и удерживанием блокировки на время работы (2PC). Вместо этого сага разбивает работу на отдельные транзакции, результаты которых могут быть каким-то образом отменены после того, как работа выполнена и совершена.