У нас есть традиция: каждый раз перед очередной конференцией DotNext мы открываем видеозаписи предыдущей и рассказываем, какие 10 докладов особенно понравились участникам. Вот и сейчас: уже в этом месяце пройдёт новый DotNext, а мы пока что открыли видеозаписи предыдущего и представляем Хабру главную десятку. Темы самые разные: и внутреннее устройство Random, и улучшения производительности в .NET 6, и SIMD-интринсики, и «пайплайн-ориентированное программирование». А как думаете, что на самых верхних строчках? Для интриги расположили доклады в обратном порядке, чтобы до вершины надо было ещё добраться: Random пользуются все, и из-за своей привычности он может ошибочно казаться простым. На самом деле под капотом тесно сплетаются математика, производительность и безопасность. И при этом в легаси-версиях System.Random и RandomNumberGenerator есть много подводных камней, о которых знают опытные .NET-разработчики. Microsoft решила тихо «исправить» реализацию Random в .NET 6, и изменения для пользователей не очевидны.  Стэн — известный специалист по безопасности и автор книг — рассмотрел в докладе изменения и рассказал, какие проблемы Microsoft стремится решить, какие намеренно сохраняет, а какие добавляет. Хотите понимать, что происходит под капотом у необходимой вам вещи? Вам сюда. GraphQL становится все более популярным на рынке как один из наиболее широко используемых стандартов связи для сервисного слоя. Есть несколько преимуществ его использования по сравнению с классическим RESTful API слоем: гибкость, безусловно, является основным, но кроме этого вы также получаете расширенные возможности — уведомления, кэширование и поддержку микросервисных архитектур практически бесплатно.  Марко показал несколько примеров того, как использовать особенности GraphQL в приложении ASP.NET Core, чтобы построить совместимый сервисный слой, работающий с Blazor.  В Додо есть частые запросы, причем бывает, что с телом ответа в несколько мегабайт (например, столько весит меню для мобильного приложения). При росте числа пользователей в команде столкнулись с проблемой — сервера перестали справляться. Добавлять сервера не хотелось, и в итоге сели за кеширование. Антон и Андрей рассказали: какие пути кеширования данных прошли (внутренние in-memory и распределенные кеши, кеширование ответов на стороне приложения, кеширование на nginx); какие проблемы поймали с каждыми из них; как сделали так, что самый частый запрос к API сайта работает совсем без кешей; что планируют делать дальше. Доклад будет интересен для разработчиков массовых сервисов. Интринсик — метод, компилирующийся в конкретную процессорную инструкцию. SIMD-интринсики появились ещё в .NET Core 3, но, несмотря на высокую производительность, в продакшне они используются довольно редко из-за кажущейся сложности.  Степан Артемьев увлекается низкоуровневой оптимизацией — так что он подходящий человек для такой темы. В докладе он рассказал про интринсики в .NET на примере обработки изображений: рассмотрел несколько реальных алгоритмов, разберёт, как была решена проблема низкой производительности и расскажет, какие этапы были пройдены для наилучшей оптимизации. Если вам в принципе интересна тема SIMD, но разобраться с ней не доходили руки, или вы хотите посмотреть на применение перформансных оптимизаций в понятном проекте из реальной жизни, то этот доклад для вас. Передача данных через «пайплайн преобразований» — это альтернативный подход к классическому ООП. Методы LINQ в .NET разработаны в этом духе, но пайплайн-подход можно использовать далеко не только для манипулирования коллекциями. Скотт Влашин — один из главных популяризаторов F# и «функциональщины» (мы как-то брали у него интервью об этом). Ранее на DotNext он рассказывал о принципах композиции из функционального программирования — мы даже сделали текстовый перевод для Хабра. А вот в этом докладе Скотт рассмотрел «пайплайн-ориентированное программирование» и то, как оно связано с функциональным программированием, принципом открытости/закрытости, юнит-тестированием, луковичной архитектурой и многим другим. А еще показал, как можно построить полноценное веб-приложение, используя только этот подход. В этом докладе вы узнаете про ближайшее будущее разработки, когда большая часть работы по тестированию и верификации программ будет происходить автоматически по щелчку мыши. Не все программисты любят писать юнит-тесты. И винить их в этом сложно: творчества в этом процессе зачастую гораздо меньше, чем рутины. Можно ли сгенерировать все тесты автоматом и получить при этом стопроцентное покрытие? Символьное исполнение — мощная техника анализа программ и генерации тестов, которая набирает популярность в последние годы. Мы погрузимся в теорию, которая стоит за Microsoft IntelliTest и поймём, как использовать символьное исполнение для ваших целей. Ребята рассмотрели символьную виртуальную машину V# с примерами применения. Также мы получим знания о практическом применении базового элемента символьного исполнения — SMT-солвера. Увидим, как можно закодировать такие головоломки, как Судоку и Сапёр в несколько строк SMT-ограничений и попросим солвер их решить. Наконец, в докладе говорилось о приближающейся революции в разработке ПО, которая может изменить нашу профессию — о синтезе программ. Встроенный ThreadPool хорош во всем. Будучи реализованным через алгоритм hill climbing, он умеет грамотно утилизировать ресурсы. Однако история с сервисами, работающими через протокол SMB, продолжается. Как итог — хочется иметь такое решение по скачиванию файлов с удалённого сервера, которое бы с одной стороны максимально утилизировало CPU и сеть, а с другой — не мешало бы остальной системе, гибко сокращая утилизируемые ресурсы при возрастании нагрузки на более высокоприоритетных сервисах. Станислав попал в топ-10 предыдущего DotNext с докладом «Точечная переработка драйвера MongoDB», а осенью 2021 года поговорил на не самую поверхностную тему и снова попал в топ. В .NET 6 было реализовано невероятное количество улучшений производительности (перформанса). В этом докладе рассмотрены некоторые из наиболее интересных примеров — Стивен заглядывает под капот, чтобы понять, что и как улучшилось, и что это значит для приложений и сервисов, переходящих на этот волнующий новый релиз. До этого на предыдущем DotNext Стивен уже делал о производительности доклад Unlocking performance improvements in .NET, и он тогда тоже попал в топ. Егора не требуется особо представлять участникам DotNext — у его предыдущих докладов множество просмотров и лайков. Неудивительно: ранее он работал в команде Mono, а затем стал трудиться над JIT-компилятором над CoreCLR, так что отлично разбирается в низкоуровневом хардкоре и знает платформу изнутри. Вот и в этот раз его опыт пригодился, в докладе он рассказал об улучшениях в JIT-компиляторе в рамках .NET 6.0 релиза: микро- и макрооптимизации, баг-фиксы, улучшения для ReadyToRun и т. п. Доклад будет интересен тем, кто интересуется перформансом и низкоуровневыми оптимизациями. Почти любой разработчик на C# по дампу памяти может быстро определить, что делало приложение, какие потоки были активными и заблокированными, и легко сможет сказать, что приложение подвисло вследствие взаимной блокировки. Но когда дело касается асинхронного кода и асинхронных дедлоков, все становится намного сложнее. Без асинхронности сегодня уже никуда, но ее отладка — боль. Что можно сделать? Сергей Тепляков кому-то знаком по книге «Паттерны проектирования на платформе .NET», кому-то по анализаторам ErrorProne.NET, кому-то — по блог-постам. В докладе он рассмотрел типичные проблемы «зависания» асинхронных операций, подходы для анализа и отладке таких проблем, а также лучшие практики, которые позволят уменьшить количество проблем в вездесущем асинхронном коде. В комментариях можете рассказать, какой из этих докладов выглядит интереснее всего для вас. А мы напомним о том, что скоро можно будет не только увидеть новые доклады, но и увидеть друг друга: у нового DotNext, помимо онлайн-части, будет специальный офлайн-день. Все подробности — на сайте.  ContentProvider