CLRium #2: Семинар по анатомии .Net

03-04 Апреля в Москве и 29-30 мая — в Санкт-Петербурге (а возможно и в вашем городе) пройдет серия семинаров CLRium. У данного семинара нет определенной целевой аудиотрии,  мы рады всем. И начинающим свою карьеру, разработчикам и махровым, повидавшим виды, архитекторам.

Как люди и хотят, у нас все будет не просто технические доклады, без воды и маркетинга. У нас будет:

1. Максимально глубокие, отборные доклады по редко-раскрываемым вопросам
2. Целый вечер, посвященный исключительно ядру.Net. Как с ним работать "без перчаток", напрямую, со структурами в памяти, без рефлексии.
3. Ставшие популярными зоны свободного общения в перерыве.

Чем мы гордимся:

1. Наш материал не встретишь в сети Интернет: он полностью авторский
2. Материал освещает самые интересные области.Net, которые почему-то не покрыты материалом.
3. Мы не берем лишних денег с вас и потому у нас — самая дешевая конференция и всех существующих. 2,000 рублей за два дня — такого не предлагает никто.

Анатомия .Net Framework CLR

В данном вопросе я варюсь уже около года и достаточно плотно изучил как устроен CLR в качестве структур данных чтобы рассказать вам о них максимально подробно. Интерес к данному мероприятию должен возникнуть как минимум потому что эта тема практически не освещена в Интернете и знания, которые вы получите, помогут Вам взглянуть на платформу под совершенно новым углом. Также данный раздел знаний по CLR является чрезвычайно интересным. Microsoft с каждым днем давит на нас словом "безопасность". А так ли она безопасна, эта CLR? А так ли много там "магии", позволяющей нам не думать о безопасности? Это авторский проект и является результатом исследований с отладчиком: каково строение.Net объектов в памяти и что с этим можно сделать.

1. Во-первых, мы посмотрим на реальное строение объектов в памяти
2. Во-вторых, мы исследуем структуры данных в памяти, относящиеся к построению виртуальных методов, реализации интерфейсов и классов (этого не было на CLRium #1)
3. Далее, на основе полученных данных мы построим прокси-тип в памяти
4. И исследуем возможность сделать множественное наследование в.Net
5. Также попробуем совместить в обном объекте и Java и.Net объект, запустив одновременно оба рантайма (привет, Xamarin)
6. После чего, воспользовавшись полученным опытом расшарим объект.Net между процессами так чтобы он одновременно существовал бы в обоих мирах.
7. Полученные знания мы используем для ответа на вопрос: какие стандартные конструкции языка приводят к проседанию производительности и каким образом?
8. Подключим компилятор и сделаем собственный JIT.

Roslyn:

1. Мы не будем делать вводную: в интернете все доклады – это вводные и вы их видели
2. Мы разберем от простого к сложному, как устроены существующие правила в поставке Roslyn (C# 6 features). Но рассмотрим не список, как это делают на конференциях, а их исходный код
3. Как только мы их рассмотрим, мы рассмотрим существующие метрики на Roslyn. Как они написаны, как строятся метрики кода.
4. Далее мы напишем не просто «подсчитаем количество букв «а» во всех словах исходных текстов, мы напишем поддержку кортежей для C#:
   var (x,y) = CalcCoords();
   public (int,int) CalcCoords()
   {
      return (0,0);
   }
5. И сделаем Nemerle оператор match (описание).
6. ​​Это очень сложные примеры, которые так просто не напишешь за вечерок и это то, что вы хотите найти в сети Интернет, но не можете.

JetBrains Nitra
Почему JetBrains выкупила себе всех разработчиков проекта N2 и сделала ставку на его будущее? Потому что возможно перед нами будущая часть ядра или плагин для ReSharper: тула создания языков и трансляторов к ним. Мы рассмотрим все ее преимущества и попробуем в бою на примере создания парсеров языков DSL.

1. Мы рассмотрим по шагам существующие примеры парсинга и попробуем в действии существующие тулы, которые его поддерживают
2. Мы сделаем парсер собственной DSL и оценим трудозатраты, которые необходимы на построение собственного языка и поддержки IntelliSense
3. Мы рассмотрим создание языка SpecFlow для поддержки тестирования.

RyuJIT

1. Мы опишем что нам даст его использование
2. Попробуем запустить на нем проект и померить производительность приложения с ним и без него на наборе синтетических тестов
3. Рассмотрим сценарии, когда бы его открытость, которая близится с каждым днем, дала бы нам преимущества

CoreFx

Многие говорят что открытость.Net Framework для сообщества и предоставление сообществу возможностей для свободного внесения правок — это плохо и чревато бесконечными багами, небрежным кодом и не стабильным API. Так ли это?

1. Итоги полугода открытого.Net Framework CoreFx.
2. Возросшая производительность от 10х до 1000х кратной в некоторых местах
3. Закрытые баги
4. Соотношение кода сообщества к коду команды.Net Framework
5. Попробуем скомпилировать и разобрать по косточкам приложение, написанное под CoreFx