![](https://habrastorage.org/getpro/habr/upload_files/aee/58c/604/aee58c604114791cf6e493e61c72f433.png)
Порой жизнь разработчика превращается в кошмар. Вариантов тут много: «миграция большого проекта», «отладка асинхронного кода», «работа с запущенным легаси» или «зоопарк технологий». Уже скоро мы проведем .NET-конференцию DotNext, и поучаствовать в ней не только интересно, но и помогает от подобных кошмаров.
Среди тем конференции — и низкоуровневый хардкор, и нестандартные подходы, и личные истории преодоления препятствий. А рассказывать обо всём этом будут яркие спикеры, уже знакомые многим .NET-разработчикам: например, Скотт Влашин, Дилан Битти, Стивен Тауб, Егор Богатов, Евгений Пешков.
Сейчас в программу вносятся последние штрихи, так что возможны небольшие изменения, но в целом доклады будет такими, как описано под катом. А кроме докладов, будут ещё и активности от программного комитета (вроде интеллектуальной викторины о разработке), о них позже расскажем отдельно.
Оглавление
Спецформаты
Пара выступлений указаны в сетке докладов, но заметно отличаются от стандартного формата «монолог со слайдами»:
![](https://habrastorage.org/getpro/habr/upload_files/dab/6da/750/dab6da750efb8b375ce013a702df05bf.jpeg)
Udi Dahan
Particular Software Ltd
Уди Дахан — один из ведущих мировых экспертов по сервисно-ориентированной архитектуре и предметно-ориентированному проектированию, а также создатель NServiceBus (самой популярной сервисной шины для .NET).
На конференции он будет не выступать с докладом, а отвечать на вопросы от программного комитета и участников. Ответы будут в прямом эфире — но вот вопросы получаются интереснее, когда о них задумываешься заранее, а не сочиняешь на ходу. Так что можете уже сейчас подумать, о чем хотели бы спросить такого человека, и смело писать свои варианты прямо в комментариях к этому посту, все учтем.
Рефакторим сложный проект в прямом эфире
![](https://habrastorage.org/getpro/habr/upload_files/d7c/325/5d0/d7c3255d0cfeb07575a2049d4f295c2b.jpeg)
Роман Неволин
Kontur
Тут вместо общих рассуждений будут происходить конкретные практические вещи.
Все мы сталкивались с ситуациями, когда при первом взгляде на проект хочется немедленно похоронить его, напиться и пойти писать заявление по собственному желанию. Это неизбежно, все мы сталкиваемся с устаревшим или попросту плохим кодом. А как с ним все-таки работать? Как довести некачественный код до приемлемого состояния, не разломав все вокруг? Как сделать это быстро, качественно и надежно?
А давайте вместо теоретических советов мы возьмем большой и запущенный проект, вместе ужаснемся и пойдем исправлять его, совместно обсуждая возникающие проблемы и их решения.
Internals
![](https://habrastorage.org/getpro/habr/upload_files/d29/1d2/32e/d291d232e74be1e7011d13bbc2c8500a.jpeg)
Егор Богатов
Microsoft
Егора не требуется особо представлять участникам DotNext — у его предыдущих докладов множество просмотров и лайков. Неудивительно: ранее он работал в команде Mono, а теперь трудится над JIT-компилятором над CoreCLR, так что отлично разбирается в низкоуровневом хардкоре и знает платформу изнутри. Вот и в этот раз его опыт пригодится, в докладе он расскажет об улучшениях в JIT-компиляторе в рамках .NET 6.0 релиза: микро- и макрооптимизации, баг-фиксы, улучшения для ReadyToRun и т. п.
Доклад будет интересен тем, кто интересуется перформансом и низкоуровневыми оптимизациями.
How random is Random? Pitfalls of randomness in .NET 6
![](https://habrastorage.org/getpro/habr/upload_files/c95/dd1/004/c95dd100473d164eae7e3b5375775e17.jpeg)
Stan Drapkin
Автор книги «Security Driven .NET»
Random — один из тех классов, которыми пользуется каждый разработчик. Несмотря на кажущуюся примитивность его функций, под капотом тесно сплетаются математика, производительность и безопасность. И при этом в легаси-версиях System.Random и RandomNumberGenerator есть много подводных камней, о которых знают опытные .NET-разработчики.Microsoft решила тихо «исправить» реализацию Random в .NET 6, и изменения для пользователей не очевидны. Стэн — известный специалист по безопасности и автор книг — рассмотрит в докладе изменения и расскажет, какие проблемы Microsoft стремится решить, какие намеренно сохраняет, а какие добавляет. Хотите понимать, что происходит под капотом у необходимой вам вещи? Вам сюда.
Если вам важно понимать, что происходит под капотом важных алгоритмов, то не пропустите этот доклад.
SIMD в .NET: Обработка изображений на интринсиках
![](https://habrastorage.org/getpro/habr/upload_files/e9b/168/77b/e9b16877b9fe7bcf2d4b56b679d11163.jpg)
Степан Артемьев
Тинькофф
Интринсик — метод, компилирующийся в конкретную процессорную инструкцию. SIMD-интринсики появились ещё в .NET Core 3, но, несмотря на высокую производительность, в продакшне они используются довольно редко из-за кажущейся сложности.
Степан Артемьев увлекается низкоуровневой оптимизацией — так что он подходящий человек для такой темы. В докладе он расскажет про интринсики в .NET на примере обработки изображений: рассмотрит несколько реальных алгоритмов, разберёт, как была решена проблема низкой производительности и расскажет, какие этапы были пройдены для наилучшей оптимизации.
Если вам в принципе интересна тема SIMD, но разобраться с ней не доходили руки, или вы хотите посмотреть на применение перформансных оптимизаций в понятном проекте из реальной жизни, то этот доклад для вас.
Диагностика асинхронного C# кода
![](https://habrastorage.org/getpro/habr/upload_files/bc0/b1f/8e2/bc0b1f8e29aed2dacd8a79ca6f6edd44.jpeg)
Сергей Тепляков
Microsoft
Почти любой разработчик на C# по дампу памяти может быстро определить, что делало приложение, какие потоки были активными и заблокированными, и легко сможет сказать, что приложение подвисло вследствие взаимной блокировки. Но когда дело касается асинхронного кода и асинхронных дедлоков, все становится намного сложнее. Без асинхронности сегодня уже никуда, но ее отладка — боль. Что можно сделать?
Сергей Тепляков кому-то знаком по книге «Паттерны проектирования на платформе .NET», кому-то по анализаторам ErrorProne.NET, кому-то — по блог-постам. И теперь он рассмотрит типичные проблемы «зависания» асинхронных операций, подходы для анализа и отладке таких проблем, а также лучшие практики, которые позволят уменьшить количество проблем в вездесущем асинхронном коде.
![](https://habrastorage.org/getpro/habr/upload_files/a73/ed8/310/a73ed831023ae820661ab6010ca8e52a.jpeg)
Kevin Sheldrake
Microsoft
![](https://habrastorage.org/getpro/habr/upload_files/df6/6ec/4e1/df66ec4e10f26646dd8fd7497fcc685c.jpeg)
Mario Hewardt
Microsoft
Sysinternals — популярный набор инструментов для получения низкоуровневого представления о поведении системы. Он широко используется разработчиками, сисадминами, тестировщиками и не только. Раньше набор инструментов Sysinternals был доступен только для Windows, а недавно были предприняты шаги по переносу некоторых инструментов на Linux. Поскольку .NET теперь кроссплатформенный, эти шаги важны, но вот информации по ним пока что мало.
Марио и Кевин исправят эту ситуацию — расскажут, зачем подобные тулы нужны .NET-разработчику, продемонстрируют доступные сегодня инструменты (procdump, procmon и sysmon) и погрузятся в глубины eBPF, которая является очень мощной технологией трассировки Linux.
![](https://habrastorage.org/getpro/habr/upload_files/3a2/148/b4e/3a2148b4e4b6650d305d9556c8f65fc0.jpeg)
Adam Sitnik
Microsoft
Для .NET 6 File IO был почти полностью переписан. Он стал в несколько раз быстрее, а также более надежным. А Адам Ситник как раз и специализируется на производительности и надежности — например, на одном из предыдущих DotNext говорил о перформансных расследованиях в .NET. А теперь расскажет, что именно было изменено, почему, и какие новые API были введены. И о том, как добиться максимальной производительности при работе с файлами в .NET.
Loop alignment and performance stability in .NET 6
![](https://habrastorage.org/getpro/habr/upload_files/d1f/199/a0d/d1f199a0d18f2eeabbec7d52d6b3d19b.jpeg)
Kunal Pathak
Microsoft
У команды .NET тысячи микробенчмарков, которые запускаются несколько раз в день при коммитах, чтобы убедиться в отсутствии регресса производительности. Некоторые бенчмарки нестабильны, и трудно понять, показывает ли метрика реальный регресс: или это просто шум. В .NET 6 команда исследовала стоящую за этим проблему и добавила различные средства защиты от неё вроде выравнивания кода, которые принесут пользу не только бенчмаркам, но и коду из реальных проектов.
Кунал — один людей, вносящих оптимизации в .NET runtime. Так что в этом докладе можно будет узнать из первых рук о том, как команда устраняет непостоянные показатели производительности, а затем он подробно остановится на «автоматическом выравнивании циклов», добавленном в .NET 6 для снижения такой нестабильности. В общем, как можно понять, доклад будет интересен любителям оптимизаций и низкоуровневого хардкора.
Performance Improvements in .NET 6
![](https://habrastorage.org/getpro/habr/upload_files/646/cb4/d52/646cb4d52586cf4798215b998896ed8c.jpg)
Stephen Toub
Microsoft
В .NET 6 было реализовано невероятное количество улучшений производительности (перформанса). В этом докладе будут рассмотрены некоторые из наиболее интересных примеров — мы заглянем под капот, чтобы понять, что и как улучшилось, и что это значит для приложений и сервисов, переходящих на этот волнующий новый релиз.
Доклад Стивена Unlocking performance improvements in .NET с весеннего DotNext 2021 был признан участниками одним из лучших на конференции — так что и новое выступление обещает быть интересным.
Best practices
Source generators v2.0 — инкрементальные генераторы
![](https://habrastorage.org/getpro/habr/upload_files/551/0f9/fd1/5510f9fd10e3192ecb0ee7dcd82b9843.jpeg)
Андрей Дятлов
JetBrains
Андрей уже раскрывал тему source generators на предыдущем DotNext, но в этой сфере произошло столько нового, что докладу понадобился сиквел. Хотя с появления генераторов в С# прошло меньше года, их популярность в сообществе уже позволила найти распространенные проблемы, с которыми сталкиваются как пользователи, так и разработчики генераторов. Разработчики компилятора в свою очередь готовы предложить решение для многих из них в новой версии SDK.
В докладе Андрей расскажет о том, что нового появилось за год как в API генераторов, так и в тулинге для них, и какие проблемы потребителей и разработчиков генераторов решают эти изменения. Вы узнаете, что такое инкрементальные генераторы, как они влияют на производительность IDE, зачем понадобилось вводить новый интерфейс, как мигрировать свой старый генератор и нужно ли вам это делать.
![](https://habrastorage.org/getpro/habr/upload_files/9ec/65b/6bc/9ec65b6bcc4aa9957b3de2678fcd7976.jpeg)
Dylan Beattie
Ursatile Ltd
Раньше софт был простым. Вы создавали сайт, подключали его к базе данных, и все было готово. Затем люди захотели API, мобильные приложения, уведомления по почте, чат в реальном времени. Потом облачный хостинг предложил создавать «эластичные» системы — приложения, способные масштабироваться по требованию, там используются такие протоколы и шаблоны, чтобы обрабатывать скачки трафика и нагрузки без ущерба для пользователей.
А теперь в .NET и вовсе имеешь дело с таким количеством вещей, что в этом всём можно утонуть. Сервисные шины, очереди сообщений, REST, GraphQL, gRPC, SignalR: для чего они все нужны? Как работают? С чего начать?
Дилан поможет не утонуть, пробежавшись по многому из мира распределенных систем на .NET: асинхронным веб-интерфейсам, очередям сообщений, буферам протоколов, уведомлениям в браузере — и все это будет с множеством лайв-демо.
Участники DotNext уже хорошо знают Дилана и по его докладам, и по его IT-песням. А судя по описанию доклада, тут поможет, что он занимается разработкой еще с 90-х: он лично застал времена, когда «софт был простым», и видит ситуацию в перспективе.
![](https://habrastorage.org/getpro/habr/upload_files/fe0/793/fdd/fe0793fdd43d2398319c939598fe471b.jpeg)
Достаточно ли ваш код хорош для облака. Что не так с Azure Functions
![](https://habrastorage.org/getpro/habr/upload_files/730/c41/1e9/730c411e9a54b1e5e6086b342b5a4e93.png)
Юрий Пастушенко
Dodo Engineering
Serverless-технологии появились несколько лет назад и поначалу были «Новыми микросервисами» — все хотели их использовать, но мало кому это удавалось. Однако в отличие от микросервисов, нашедших свою нишу в Enterprise-разработке, serverless используют немногие. В чём причина? В стоимости? В сложности? Или в кривых руках разработчиков? В этом докладе Юрий расскажет о внутренностях Azure Functions и поделится своим опытом в использовании этой технологии.
The JSON evolution with SQL Database
![](https://habrastorage.org/getpro/habr/upload_files/8aa/443/bc0/8aa443bc0051552b6da1b36b83ab5e6b.jpeg)
Roberto Freato
Witailer
Тезис «не храните большие объекты в базе данных» устарел. Мы увидим, как база данных вроде Azure SQL Database, которую привыкли воспринимать как реляционную, может эффективно работать с прорвой JSON-объектов. И увидим, как это позволяет сократить путь между необработанными данными, изначально хранящимися в озере данных, и реляционным представлением, используемым аналитическими приложениями.
CosmosDB: использование в реальном проекте
![](https://habrastorage.org/getpro/habr/upload_files/678/f8f/96f/678f8f96f692395bf05c7b2981eb7dac.png)
Анна Морозова
Dodo Engineering
В разработке мобильного приложения и сайта всегда важен клиент. И когда Анна с командой делали историю заказов клиентов, то поняли, что ее негде хранить.
В докладе Анна расскажет:
почему не подошел Redis;
как команда выбирала новую базу и как ее затаскивала;
особенности этой базы и ее подводные камни;
как оптимизировать запросы и цену инфраструктуры.
Если вы тоже хотите «сдаться облаку», то приходите послушать этот доклад.
Как Додо училось отдавать много данных без регистрации и СМС
![](https://habrastorage.org/getpro/habr/upload_files/14b/695/618/14b6956182b37466120e5c62fe484399.jpeg)
Антон Оникийчук
Dodo Engineering
![](https://habrastorage.org/getpro/habr/upload_files/d51/108/46a/d5110846af713bad6812a7136888bf33.jpeg)
Андрей Парамонов
Dodo Engineering
В Додо есть частые запросы, причем бывает, что с телом ответа в несколько мегабайт (например, столько весит меню для мобильного приложения). При росте пользовательской базы (и увеличении количества запросов), в команде столкнулись с проблемой — сервера перестали справляться. Добавлять новых серверов не хотелось и в итоге сели за кеширование.
Антон и Андрей хотят рассказать:
какие пути кеширования данных прошли (внутренние in-memory и распределенные кеши, кеширование ответов на стороне приложения, кеширование на nginx);
какие проблемы поймали с каждыми из них;
как сделали так, что самый частый запрос к API сайта работает совсем без кешей;
что планируют делать дальше.
Доклад будет интересен для тех, кто создает массовые сервисы с большим количеством пользователей.
Дорога монолита в облако и обратно
![](https://habrastorage.org/getpro/habr/upload_files/4e8/e65/ff5/4e8e65ff50c9cdfcc4000a261ce1ebcb.jpeg)
Ростислав Листеренко
Mindbox
Понятно, что при миграции нагруженного приложения в облако можно встретиться с большим количеством ожидаемых сложностей и еще большим количеством неожиданных. Но одно дело — теоретически это понимать, а другое — услышать реальную историю с конкретными цифрами, реальной болью и практическими выводами. Ростислав поделится опытом такой миграции на примере платформы Mindbox: расскажет про путь к .NET Core, препятствия в кодовой базе, сложности работы с Yandex.Cloud, влияние миграции на остальную инфраструктуру. Обсудим возможные пути решения подобных проблем и к чему пришли в итоге.
ThreadPool для сервиса, адаптирующегося под внешнюю нагрузку
![](https://habrastorage.org/getpro/habr/upload_files/8f5/073/c48/8f5073c48831c675f9c54f7c3031bd58.jpeg)
Станислав Сидристый
ЦРТ
Встроенный ThreadPool хорош во всем. Будучи реализованным через алгоритм hill climbing, он умеет грамотно утилизировать ресурсы. Однако история с сервисами, работающими через протокол SMB, продолжается. Как итог — хочется иметь такое решение по скачиванию файлов с удалённого сервера, которое бы с одной стороны максимально утилизировало CPU и сеть, а с другой — не мешало бы остальной системе, гибко сокращая утилизируемые ресурсы при возрастании нагрузки на более высокоприоритетных сервисах.
Станислав попал в топ-10 предыдущего DotNext с докладом «Точечная переработка драйвера MongoDB», теперь снова разбирает не самую поверхностную тему — наверняка и в этот раз будет интересно.
Клиентский HTTP в .NET: От WebRequest до SocketsHttpHandler
![](https://habrastorage.org/getpro/habr/upload_files/edd/432/0ac/edd4320ac84b096edc3a640b162e8369.jpeg)
Евгений Пешков
JetBrains
На первый взгляд кажется, что отправить HTTP запрос — это очень просто. Тем не менее, даже HTTP/1.1 достаточно нетривиален: RFC на него содержит более 150 страниц, кроме того, браузеры уже поддерживают HTTP/2 и HTTP/3. Это не оставляет никакого выбора: стандартный клиент в платформе должен быть реализован на высоком уровне.
На пути от .NET Framework 1.0 к .NET 5 клиентские API для работы с HTTP и его реализации претерпели множество изменений. В некоторых версиях они были удачными, в некоторых же — провальными и явно временными.
В докладе Евгений расскажет о истории развития клиентского HTTP API в .NET, его особенностях, о миграции приложений с Framework на Core с их учётом. Спикер также разберет некоторые хаки, полезные при работе с HTTP API. Мы заглянем в NuGet и рассмотрим представленные в нём обёртки над HTTP API с точки зрения эффективности и кроссплатформенности.
В итоге участники:
узнают о неявных особенностях протокола HTTP;
научатся писать эффективный код с использованием HTTP API в .NET;
напишут библиотеки с использованием HTTP API, универсальные для различных реализаций .NET;
будут готовы к возможным проблемам с производительностью при написании клиентского кода;
подготовятся к миграции приложений с .NET Framework и старых версий .NET Core на .NET 5;
получат актуальную информацию о поддержке HTTP/2 в .NET, с тестами производительности.
Тренды
Символьное исполнение в .NET: Автоматическое тестирование, верификация и синтез программ
![](https://habrastorage.org/getpro/habr/upload_files/348/0eb/050/3480eb0506a80f76b88776eb55acac2a.jpeg)
Дмитрий Иванов
Huawei
![](https://habrastorage.org/getpro/habr/upload_files/c67/f40/de8/c67f40de82d816a81eb26377081cf59f.jpg)
Дмитрий Мордвинов
JetBrains Research
В этом докладе вы узнаете про ближайшее будущее разработки, когда большая часть работы по тестированию и верификации программ будет происходить автоматически по щелчку мыши. Не все программисты любят писать юнит-тесты. И винить их в этом сложно: творчества в этом процессе зачастую гораздо меньше, чем рутины. Можно ли сгенерировать все тесты автоматом и получить при этом стопроцентное покрытие?
Символьное исполнение — мощная техника анализа программ и генерации тестов, которая набирает популярность в последние годы. Мы погрузимся в теорию, которая стоит за Microsoft IntelliTest и поймём, как использовать символьное исполнение для ваших целей. Рассмотрим символьную виртуальную машину V# с примерами применения. Также получим знания о практическом применении базового элемента символьного исполнения — SMT-солвера. Увидим, как можно закодировать такие головоломки, как Судоку и Сапёр в несколько строк SMT-ограничений и попросим солвер их решить. Наконец, мы поговорим о приближающейся революции в разработке ПО, которая может изменить нашу профессию — о синтезе программ.
![](https://habrastorage.org/getpro/habr/upload_files/bef/329/ca5/bef329ca52d5483491f68187d3d730aa.jpeg)
Julie Lerman
The Data Farm
EF Core 6 выходит в ноябре вместе с .NET 6 — и обещают изменения, в некоторых сценариях улучшающие производительность в разы. Когда что-то меняется настолько сильно, в таком явно стоит разобраться всем разработчикам, имеющим с этим дело. А Джули Лерман, хоть и работает не в Microsoft, является одним из главных в мире экспертов в этих вопросах — так что разбираться, что меняется, стоит как раз с ней.
![](https://habrastorage.org/getpro/habr/upload_files/6b9/506/8ee/6b95068ee4792fa1e9806e926022d6b8.jpeg)
Bartosz Adamczewski
Iyuno-SDI
На конференции CppCon 2014 многим запомнились слова Майка Эктона о том, что компилятор может помочь решить только около 10% проблемной области — остальное вы должны сделать сами. Изменилось ли что-то с тех пор? Да — с появлением новых компиляторов и JIT-компиляторов ситуация стала намного хуже, и чтобы иметь оптимальный код, часто нужно уделять больше внимания тому, что делает компилятор (а не меньше).
Этот доклад объяснит, почему компиляторы очень сложны и почему оптимальная генерация нативного кода трудна и может испортить вам день. И хотя компиляторы — это сложно, а Бартош очень глубоко погружен в тему (потому что сам их пишет), это совершенно не значит, что доклад будет заумной нудятиной: о такой теме тоже можно рассказать увлекательно и понятно.
Разработка кросс-платформенных приложений с использованием Uno Platform и Elmish подход на F#
![](https://habrastorage.org/getpro/habr/upload_files/f1e/c41/a9b/f1ec41a9b3233bc09aa7aa899a84c469.jpeg)
Андрей Чебукин
The Secret Circle Solutions
Uno Platform — это единственная платформа для создания кроссплатформенных приложений, которая позволяет создавать идеальные до пикселей пользовательские интерфейсы на всех возможных платформах и реализовать сценарии бесшовного перетекания с платформы на платформу, используя UWP XAML и API как основу. А как же F#? Ведь UWP не поддерживает F#... На самом деле это не так. WinUI 3 работает с F# на .NET 5. Как создать приложение Uno с помощью F#? Это просто: компания Андрея подготовила шаблон «dotnet new» корпоративного уровня, чтобы легко начать. Андрей подробно расскажет о нем в своем докладе.
Creating a GraphQL API with ASP.NET Core
![](https://habrastorage.org/getpro/habr/upload_files/b0d/87c/7d5/b0d87c7d5822f929185ab9746289a2f7.jpeg)
Marco de Sanctis
Cloud Consult London Ltd
GraphQL становится все более популярным на рынке как один из наиболее широко используемых стандартов связи для сервисного слоя.
Есть несколько преимуществ его использования по сравнению с классическим RESTful API слоем: гибкость, безусловно, является основным, но кроме этого вы также получаете расширенные возможности — уведомления, кэширование и поддержку микросервисных архитектур практически бесплатно.
Марко покажет несколько примеров того, как использовать особенности GraphQL в приложении ASP.NET Core, чтобы построить совместимый сервисный слой, работающий с Blazor.
Архитектура
![](https://habrastorage.org/getpro/habr/upload_files/9eb/ac9/7de/9ebac97dea352f6eada691548c42bc1d.jpeg)
Scott Wlaschin
автор книги Domain «Modeling Made Functional»
Передача данных через «пайплайн преобразований» — это альтернативный подход к классическому ООП. Методы LINQ в .NET разработаны в этом духе, но пайплайн-подход можно использовать далеко не только для манипулирования коллекциями.
Скотт Влашин — один из главных популяризаторов F# и «функциональщины» (мы как-то брали у него интервью об этом). Ранее на DotNext он рассказывал о принципах композиции из функционального программирования — мы даже сделали текстовый перевод для Хабра. А теперь он рассмотрит «пайплайн-ориентированное программирование» и то, как оно связано с функциональным программированием, принципом открытости/закрытости, юнит-тестированием, луковичной архитектурой и многим другим. В завершение Скотт покажет, как можно построить полноценное веб-приложение, используя только этот подход.
![](https://habrastorage.org/getpro/habr/upload_files/039/bfb/4d7/039bfb4d7cfa9cddbf03db739fec3f37.png)
Черная магия паттерна «Посетитель»
![](https://habrastorage.org/getpro/habr/upload_files/5f4/73e/86b/5f473e86b116e7cf7aa1661cc6f5c711.jpeg)
Дмитрий Нестерук
Квант и разработчик
«Посетитель» (visitor) — один из самых сложных паттернов Банды Четырех. Благодаря гибкости языка C#, у этого паттерна есть много возможных реализаций и вариаций, которые и будут рассмотрены в этом докладе.
Рассматривать будет Дмитрий Нестерук, которого некоторые участники знают давно: ещё в 2014-м его кейноут открывал самый-самый первый DotNext. Кстати, этим летом мы расспрашивали Дмитрия по совсем другому поводу — о работе кванта.
High Optionality Programming: Software Architectures that Reduce Technical Debt
![](https://habrastorage.org/getpro/habr/upload_files/88a/a80/540/88aa80540545a9a2c9a945e175b13cea.jpeg)
Aaron Stannard
Petabridge
Технического долга боятся все разработчики, поскольку он означает необходимость расплачиваться сегодня за негибкий выбор, сделанный вчера (часто усугубленный годами последующих решений).
А что, если бы был способ сделать другой выбор на начальном этапе создания программных систем, который привел бы к созданию более гибких программных систем, способных развиваться с меньшими затратами и меньшими мучениями? В этом докладе пойдет речь о создании программных систем, которые сохраняют будущие возможности выбора и снижают их стоимость.
В докладе будут представлены концепции и язык для программирования с «высокой степенью опциональности», а также некоторые проверенные временем паттерны для его реализации.
Автор сосредоточится на event-sourcing и CQRS в .NET, Akka.NET, F# и функциональном программировании на C#, а также на некоторых других комбинациях технологий, которые позволят разработчикам .NET войти в будущее с меньшим технологическим долгом в целом.
Для затравки Аарон уже написал статью по этой теме, а на конференции вопрос будет разобран подробнее.
Architecting a large social network without breaking the bank
![](https://habrastorage.org/getpro/habr/upload_files/c41/f4e/996/c41f4e996acf0882ffcef4b2b2413f5a.jpeg)
Oren Eini
Hibernating Rhinos
Мы призваны создавать крупномасштабные системы, но обычные инструменты, которыми мы располагаем для этого, могут иметь огромные затраты при масштабировании. В этом докладе Орен Эйни расскажет о том, как можно построить высокомасштабируемую систему, способную обслуживать сотни миллионов пользователей, и при этом не разориться. Оказывается, правильная архитектура может гарантировать, что у вас есть пространство для роста без чрезмерных затрат и что вы можете спокойно спать, зная, что ваши системы надежны и могут выдержать все, что вы им поручите.
Мы рассмотрим как высокоуровневые детали архитектуры, так и ограничения на уровне системы, которые могут превратить невыполнимую задачу в пустяковое дело. Затем мы погрузимся в некоторые низкоуровневые детали реализации, которые могут сделать вашу систему отзывчивой и быстрой даже при огромной нагрузке.
Расскажет обо всём этом создатель RavenDB и автор блога, известный сразу под двумя именами — Oren Eini и Ayende Rahien.
Модульный монолит вместо микросервисов: как, когда и зачем
![](https://habrastorage.org/getpro/habr/upload_files/b66/55a/88e/b6655a88e6eea2cc0f651ed276476d06.jpeg)
Денис Цветцих
DevBrothers
Микросервисы сегодня — это хайп, о котором говорят из каждого утюга. Складывается мнение, что старый добрый монолит — это плохо, а микросервисы — таблетка от всех болезней. Но так ли это на самом деле?
В своем докладе Денис расскажет о том, когда стоит предпочесть монолит микросервисам. А также о том, что монолиты бывают разные, это не обязательно большой комок грязи. Модульный монолит позволяет сделать такую же качественную изоляцию частей системы друг от друга, как это предлагают микросервисы, при этом сохранив простоту отладки, деплоя и работу в рамках одной транзакции. Да, писать хорошие монолиты тоже нужно уметь :)
Также спикер расскажет, когда обычному монолиту пора становиться модульным и как перейти от обычного монолита к модульному. И, конечно, как выделять модули в отдельные сервисы.
Overcome model versioning nightmare using Semantic Driven Modeling (SDM) in distributed systems
![](https://habrastorage.org/getpro/habr/upload_files/bc0/9be/58f/bc09be58f26d12defa01c733695f3f76.jpeg)
Raffaele Rialdi
Vevy Europe
В мире распределенных вычислений мы научились разделять проблемы и распределять задачи между несколькими различными (микро) сервисами. Этот подход хорош для целей масштабируемости, но открывает большую дилемму в контексте версионности. Связь между этими сервисами трудно поддерживать каждый раз, когда в соответствующих моделях происходят какие-то изменения. Эти трудности еще больше возрастают в событийно-ориентированных архитектурах, где хранящиеся события могут иметь разные версии с течением времени.
В этом докладе мы рассмотрим новый подход, основанный на семантических метаданных и методах генерации кода .NET, которые позволяют свободно изменять модели без необходимости перекомпиляции или перезапуска потребителей. Пример кода полностью основан на .NET и компиляторе Roslyn C#.
Заключение
Напоследок напомним, что конференция — это не только слушать: после каждого доклада будет возможность как следует расспросить спикера.
И отдельно упомянем расписание. Раньше мы «размазывали» доклады по четырём дням, но многим это неудобно, так что в этот раз будут два супернасыщенных дня. Очень советуем компаниям, сотрудники которых участвуют в DotNext, на эти два дня свести их рабочие задачи к минимуму: если в офлайне вы отпускали разработчиков на конференции и не ожидали от них закрытых тикетов, то почему в онлайне должно быть иначе? Воспринимать хардкорный технический контент в обоих случаях требует концентрации.
Напоминаем, что сами эти два дня — 21-22 октября (четверг-пятница). Ознакомиться с точным расписанием и другими подробностями можно на сайте, билеты там же.
Увидимся на DotNext!