воскресенье, 25 ноября 2018 г.

Конференция dotnext 2018 - отчет

В этом году мне удалось побывать на конференции Dotnext 2018 для .Net разработчиков, которая проводилась в Москве 22-23 ноября. Мероприятие проходило на территории гостиницы Украина на Кутузовском проспекте и была организована по высшему разряду с питанием, кофебрейками, ништяками и прочим.



На конференцию были приглашены такие известные личности как Джефри Рихтер, Павел Йосифович и др.



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

Доклад Джефри Рихтера - Generics

Маэстро рассказывал про дженерики в .Net. Уровень материала - разжевывание дженериков студентам второго курса для подготовки к сдаче лабы.
Однако, одна прозвучавшая мысль меня порадовала. Рихтер рассказал, чем отличаются шаблоны в .Net framework от шаблонов в C++. Я и раньше мог на пальцах объяснить, в чем отличие, но не хватало общего понимания картины. Теперь же пазл сложился :) Основная и главная особенность дженериков в .Net состоит в том, что в .Net дженерики остаются дженериками после компиляции в байт код :) Всё, точка. Этого ответа достаточно на вопрос, в чем различия между дженериками в плюсах и в дотнете. Всё остальное просто следствия это факта.

Доклад Джефри Рихтера - Building responsive and scalable applications

Джефри, как и на первом своем докладе про дженерики, просто перечитывал на память главы из своей книги. Уровень сложности материала можно оценить как для начинающих.
При каждом переключении контекстов потоков Windows выполняет следующие операции:
1. Сохранение регистров текущего потока в оперативной памяти
2. Вычисление того, какой поток должен выполняться следующим.
3. Загрузка данных нового потока в регистры процессора.
4. Переключение контекстов может приводить к промахам при поиске по кешам процессора.
Всё это приводит к деградации производительности.
Вывод: используйте потоки, как можно реже. Для работы с диском, сетью и др. следует использовать асинхронное API.

Системные метрики: собираем подводные камни

Доклад про то, как программно получать и логировать какие-нибудь интересные метрики. Для этого есть следующие доступные варианты:
1. Получение performance counters через стандартные .Net методы из пространства имен System.Diagnostics. Надо иметь в виду, что категория Process весьма медленная.
2. Еще один способ сбора метрик - это использование функции RegQueryValueEx(HKEY_PERFORMANCE_DATA, "230 784", ...). Всегда лучше сравнивать разные способы сбора метрик.
3. Performance Data Helpers (pdh.dll). Имеет смысл использовать PDH, если уперлись в ограничения .Net обертки.
4. ETW - event tracing for Windows. Записывает евенты от различных провайдеров: .Net CLR provier, Kernel-Network provider, custom provider.
Также докладчик приводил интересные примеры из собственной практики, с какими проблемами ему приходилось сталкиваться при сборке метрик, и как он их решал.
Хороший блог Bruce Dawson, в котором много интересных статей на тему вопросов performance в Windows.
Рекомендую этот доклад к просмотру!

Создание окружения для интеграционных тестов на основе Docker-контейнеров

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

Windows 10 internals for .NET developers Pavel Yosifovich

1. Для лучшего понимания положения .Net в операционной системе Windows показал всю цепочку вызовов функций при обращении к методу File.Read(), начиная с библиотеки типов .Net и заканчивая HAL.
2. Рассказывал про jobs: как их создавать, как использовать с примерами.
3. Приоритеты потоков
4. Processor Affinity. Это про то, на каком процессоре должен выполняться тот или иной поток, и как этим можно управлять.
5. Waitable kernel objects: семафоры, мьютексы, евенты.
К сожалению, ничего нового не узнал.

Yield и async-await: как оно все устроено внутри и как этим воспользоваться

Также хочется отметить этот доклад. В этом докладе докладчик рассказал про ICFP Contest - соревнование для программистов. И показал на примере решения одной из задач с этого соревнования, каким образом можно применять конструкции yield return и async await. В ходе рассказал было подобно описано, как эти конструкции устроены внутри, как выглядит byte код для них, и как они работают.
Из этого доклада вряд ли можно будет получить много полезной информации с точки зрения практического применения. Однако, содержимое доклада и подача материала докладчиком показались мне весьма увлекательными. В итоге, посмотрел доклад с удовольствием.
Рекомендую этот доклад к просмотру!

От монолита к микросервисам: история и практика

1. С преимуществами микросервисной архитектуры всё понятно:
- Модульность. Все компоненты системы разделены на модули, которые можно разрабатывать, поддерживать и деплоить независимо от остальных.
- Проще разделить зону ответственности между разработчиками.
- Высокая отказоустойчивость.
- Разнообразие технологий.
2. Все микросервисы должны быть логически независимыми функциональными единицами, которые общаются через какую-то общую шину данных. Если у вас один микросервис обращается к другому, а то к третьему, то это антипаттерн.
3. Для управление контейнерами хорошо бы использовать какую-нибудь систему оркестрации, например, Kubrnetes.
4. Грамотно настроенная система мониторинга микросервисов может сильно облегчить жизнь.
5. При переходе от монолита к микросервисам не обязательно сразу начинать всё ломать и крушить. Можно постепенно по мере готовности микросервисов отрезать те или иные куски монолита, переключая систему на использование публичного API микросервисов.
6. Сложнее всего разделять базу данных.
Полезные ссылки:
Мартин Фаулер про микросервисы.
Хорошая статья про микросервисы на хабре.

Domain-driven design: рецепт для прагматика

Основные принципы DDD:
1. Общий язык, используемый в терминологии, между всеми участниками проекта: начиная с разработчиков, закачивая бизнесом.
2. Контекст доменной модели. Все бизнес сущности, используемые при проектировании системы, должны не выходить за рамки принятого контест доменной модели. Модели должны быть ограничены своими контекстами.
3. Больше общения между девеломентом и бизнесом.
4. Максимально выразительный код интерфейсов бизнес логики.
Хорошая статья на хабре про проектирование и архитектуру - Как мы попробовали DDD, CQRS и Event Sourcing и какие выводы сделали.

Комментариев нет:

Отправить комментарий