Темы: C# 8.0, .NET Core 2.2 и .NET Core 3.0, CLR

Вы успеваете отслеживать все свежее в мире .NET, что происходит в последнее время? C# 8.0? Span/Memory? ValueTasks? System.IO.Pipeline? CLI API & Global Tools? Если нет, то лучший способ наверстать упущенное — сходить на профильное мероприятие и ровно за один день понять сразу все темы вместе взятые и решить для себя, что будет полезным, а что должно выдержать еще одну проверку временем.

Темой четвертой серии CLRium станут как обычно — самые последние последние наработки из мира .NET: мы расскажем подробнее о том, что уже можно потрогать и бегло о том, что только планируется. Посещение данного мероприятия — прекрасный способ освежить понимание вектора развития нашей прекрасной платформы и узнать то, на что обычно не хватает времени и решить для себя что-нибудь попробовать в ближайшем будущем.

В этом году мы решили захватить лучшие практики прошлых лет:

• Доклады без продуктового какие мы классные маркетинга, только ядро платформы
• Полный апгрейд знаний до версии .NET Core 3.0
• Где возможно — максимальный хардкор (вы меня знаете)
• Прекрасная цена в 3,000 рублей за день. Все еще по цене полутора заправок
• Классные, удобные, современные залы

Интересно? Милости просим под кат!

• 19 октября в Санкт-Петербурге, в офисе компании Epam Systems
• 26 октября в Москве

Существует ряд исключительных ситуаций, которые скажем так… Несколько более исключительны чем другие. Причем если попытаться их классифицировать, то как и было сказано в самом начале главы, есть исключения родом из самого .NET приложения, а есть исключения родом из unsafe мира. Их в свою очередь можно разделить на две подкатегории: иcключительные ситуации ядра CLR (которое по своей сути — unsafe) и любой unsafe код внешних библиотек.

Давайте поговорим про эти особые исключительные ситуации.

ThreadAbortException

Вообще, это может показаться не очевидным, но существует четыре типа Thread Abort.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

События об исключительных ситуациях

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

try {
    // ...
} catch {
    // do nothing, just to make code call more safe
}

В такой ситуации может оказаться что выполнение кода уже не так безопасно как выглядит, но сообщений о том что произошли какие-то проблемы мы не имеем. Второй вариант — когда приложение глушит некоторое, пусть даже легальное, исключение. А результат — следующее исключение в случайном месте вызовет падение приложения в некотором будущем от случайной казалось бы ошибки. Тут хотелось бы иметь представление, какая была предыстория этой ошибки. Каков ход событий привел к такой ситуации. И один из способов сделать это возможным — использовать дополнительные события, которые относятся к исключительным ситуациям: AppDomain.FirstChanceException и AppDomain.UnhandledException.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

Этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать под кат.

Memory<T> и ReadOnlyMemory<T>

Визуальных отличий Memory<T> от Span<T> два. Первое — тип Memory<T> не содержит ограничения ref в заголовке типа. Т.е., другими словами, тип Memory<T> имеет право находиться не только на стеке, являясь либо локальной переменной либо параметром метода либо его возвращаемым значением, но и находиться в куче, ссылаясь оттуда на некоторые данные в памяти. Однако эта маленькая разница создает огромную разницу в поведении и возможностях Memory<T> в сравнении с Span<T>. В отличии от Span<T>, который представляет собой средство пользования неким буфером данных для некоторых методов, тип Memory<T> предназначен для хранения информации о буфере, а не для работы с ним.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать под кат.

Архитектура исключительной ситуации

Наверное, один из самых важных вопросов, который касается темы исключений — это вопрос построения архитектуры исключений в вашем приложении. Этот вопрос интересен по многим причинам. Как по мне так основная — это видимая простота, с которой не всегда очевидно, что делать. Это свойство присуще всем базовым конструкциям, которые используются повсеместно: это и IEnumerable, и IDisposable и IObservable и прочие-прочие. С одной стороны, своей простотой они манят, вовлекают в использование себя в самых разных ситуациях. А с другой стороны, они полны омутов и бродов, из которых, не зная, как иной раз и не выбраться вовсе. И, возможно, глядя на будущий объем у вас созрел вопрос: так что же такого в исключительных ситуациях?

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом (уже готово около 200 страниц книги, так что добро пожаловать в конец статьи за ссылками).

Как язык, так и платформа существуют уже много лет: и все это время существовало множество средств для работы с неуправляемым кодом. Так почему же сейчас выходит очередной API для работы с неуправляемым кодом если по сути он существовал уже много-много лет? Для того чтобы ответить на этот вопрос достаточно понять чего не хватало нам раньше.

Разработчики платформы и раньше пытались нам помочь скрасить будни разработки с использованием неуправляемых ресурсов: это и автоматические врапперы для импортируемых методов. И маршаллинг, который в большинстве случаев работатет автоматически. Это также инструкция stackallloc, о которой говорится в главе про стек потока. Однако, как по мне если ранние разработчики с использованием языка C# приходили из мира C++ (как сделал это и я), то сейчас они приходят из более высокоуровневых языков (я, например, знаю разработчика, который пришел из JavaScript). А что это означает? Это означает что люди со все большим подозрением начинают относиться к неуправляемым ресурсам и конструкциям, близким по духу к C/C++ и уж тем более — к языку Ассемблера.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. Вся книга будет доступна на GitHub (ссылка в конце статьи).

В C# существует достаточно интересное и очень редко используемое ключевое слово stackalloc. Оно настолько редко встречается в коде (тут я даже со словом «редко» преуменьшил. Скорее, «никогда»), что найти подходящий пример его использования достаточно трудно а уж придумать тем более трудно: ведь если что-то редко используется, то и опыт работы с ним слишком мал. А все почему? Потому что для тех, кто наконец решается выяснить, что делает эта команда, stackalloc становится более пугающим чем полезным: темная сторона stackalloc — unsafe код. Тот результат, что он возвращает не является managed указателем: значение — обычный указатель на участок не защищенной памяти. Причем если по этому адресу сделать запись уже после того как метод завершил работу, вы начнете писать либо в локальные переменные некоторого метода или же вообще перетрете адрес возврата из метода, после чего приложение закончит работу с ошибкой. Однако наша задача — проникнуть в самые уголки и разобраться, что в них скрыто. И понять, в частности, что если нам дали этот инструмент, то не просто же так, чтобы мы смогли найти секретные грабли и наступить на них со всего маху. Наоборот: нам дали этот инструмент чтобы мы смогли им воспользоваться и делать поистине быстрый софт. Я, надеюсь, вдохновил вас? Тогда начнем.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава, ссылка на часть `Выделение памяти на стеке: stackalloc`
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. Вся книга будет доступна на GitHub (ссылка в конце статьи). Так что Issues и Pull Requests как всегда приветствуются :)

Существует область памяти, про которую редко заходит разговор. Однако эта область является, возможно, основной в работе приложения. Самой часто используемой, достаточно ограниченной с моментальным выделением и освобождением памяти. Область эта называется «стек потока». Причем поскольку указатель на него кодируется по своей сути регистрами процессора, которые входят в контекст потока, то в рамках исполнения любого потока стек потока свой. Зачем же он необходим? Давайте вместе окунемся в мир низкоуровневых структур, на основе которых работает все: начиная от DOS программ и заканчивая .NET Framework, установленным поверх Windows 10.

Итак, разберем элементарный пример кода:

void Method1()
{
    Method2(123);
}

void Method2(int arg)
{
    // ...
}

В данном коде не происходит ничего примечательного, однако не будем его пропускать, а наоборот: посмотрим на него максимально внимательно.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом.

Вся книга будет доступна на GitHub: CLR Book. Так что Issues и Pull Requests приветствуются :)

Это — выжимка из главы про структуру типов и их VMT.

Структура объектов в памяти

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

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. Тема IDisposable была выбрана в качестве разгона, пробы пера. Теперь коснемся разницы между типами. Вся книга будет доступна на GitHub: DotNetBook. Так что Issues и Pull Requests приветствуются :)

Это — выжимка из главы про Struct / Class и их разницу.

Особенности выбора между class/struct

Давайте подумаем об особенностях обоих типов, об их достоинствах и недостатках и решим, где ими лучше пользоваться. Тут, конечно же стоит вспомнить классиков, дающих утверждение что выбор в сторону значимых типов, стоит дать если у нас тип не планирует быть наследуемым, он не станет меняться в течении своей жизни, а его размер не превышает 16 байт. Но не все так очевидно. Чтобы сделать полноценное сравнение нам необходимо задуматься о выборе типа с разных сторон, мысленно продумав сценарии его будущего использования.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

С этой статьей я начинаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. Тема IDisposable была выбрана в качестве разгона, пробы пера. Вся книга будет доступна на GitHub: DotNetBook. Так что Issues и Pull Requests приветствуются :)

Disposing (Disposable Design Principle)

Сейчас, наверное, практически любой программист, который разрабатывает на платформе .NET, скажет, что ничего проще этого паттерна нет. Что это известный из известнейших шаблонов, которые применяются на платформе. Однако даже в самой простой и известнейшей проблемной области всегда найдется второе дно, а за ним еще ряд скрытых кармашков, в которые вы никогда не заглядывали. Однако, как для тех, кто смотрит тему впервые, так и для всех прочих (просто для того, чтобы каждый из вас вспомнил основы (не пропускайте эти абзацы (я слежу!))) — опишем все от самого начала и до самого конца.

IDisposable

Если спросить, что такое IDisposable, вы наверняка ответите что это

public interface IDisposable 
{
	void Dispose();
} 

Для чего же создан интерфейс? Ведь если у нас есть умный Garbage Collector, который за нас чистит всю память, делает так, чтобы мы вообще не задумывались о том, как чистить память, то становится не совсем понятно, зачем ее вообще чистить. Однако есть нюансы.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

Все мы ходили по собеседованиям, разговаривали с представителями компаний и постоянно встречаемся с особенностями, которые рекрутеры либо культивируют, обучая друг друга, либо не обращают внимания, но при этом выглядят отталкивающими — со стороны человека, пришедшего в компанию. В моей 10-летней карьере я сменил порядка 10 компаний (в последней — Luxoft — уже 3 года, так что практику перебежчика закончил). И за это время провел как около 100 собеседований на стороне соискателя, так и порядка 150 — на стороне собеседующего, что дало мне возможность собрать Топ5 ошибок рекрутеров, которые могут так испортить собеседование, что я больше не захочу идти в компанию.

Мы сделали это. Сетка докладов практически готова. Самое главное, выжимка:

• Автоматизация тестирования серверной части и UI в ОС Linux в условиях жестких рамок настройки безопасности системы от Макса Шоничева
• Про проблемы взаимодействия между отделами QA и Dev поговорят их представители: Артур Орлов и Анастасия Леншмидт
• Мы с Яном Алексеенко проведем три мастер-класса
• Специальный гость из Германии — Алексей Виноградов (один из ведущих Radio QA и разработчиков Selenide) — познакомит нас с тремя простыми и практичными видами PageObject архитектуры — Static, Void и Fluent и продемонстрирует использование кодом, сравнит плюсы и минусы подходов
• Также из Германии — наш гость Slava Schmidt — консультант по Scala. Он нам поведует про Property-Based Testing with API-First Approach

Всем привет! Вас приветствует команда QA: Conference. Мы очень рады сообщить вам что до начала первой конференции осталось всего ничего, считанные часы и рады предоставить вам статистику и новости.

Мы очень плотно поработали чтобы сделать все хорошо и надеемся что вам понравится результаты нашей работы. Сама конференция собрала 1050+ человек как по городам, так и в онлайне. Это очень хороший показатель для первого раза. Что на самом деле не удивительно: для чтения докладов собраны лучшие докладчики и выбраны отличные темы, которые раскрыты на все 100%

Три конференции позади и мы готовы идти дальше. Пока организаторы собирают отзывы, сортируют фотографии, а страна — отдыхает, у всех нас есть шанс записаться на будущую конференцию в Новосибирске. Что же нас ожидает на будущей конференции?

• Галина Галкина — Расчет категории риска – подход к управлению регрессионной ТМ
• Дарья Ефремова — FMEA — подход к тестированию с ретроспективой
• Станислав Сидристый — Грамотное использование Groovy/Geb при автоматизации тестирования Web-приложений на Java
• Константин Нерадовский — Функциональный подход в разработке автотестов на Java
• Роман Иовлев — Jedi Power of Model-based testing
• Роман Иовлев — JDI — Future of UI Automation
• Алексей Белёв и Михаил Мациевский — Автоматизация тестирования или как мы с нуля всё поднимали
• Александр Шиповалов — Чем пахнут ваши авто-тесты
• Александр Шиповалов — BDD — Золотая книжечка, столь же полезная, сколь и забавная..
• Леншмидт Анастасия и Орлов Артур — Автотесты: QA vs Dev

Потратив множество человеко-часов над разработкой автотестов для нескольких огромных проектов, я с полной уверенностью могу сообщить, что составил может быть далеко не полный, но уж точно достаточно крупный набор практик, с которыми хочется поделиться с каждым. Итак, следуя стопам классиков, хочу (надеюсь увидеть дополнения от вас в комментариях) составить:

Шаблоны проектирования Cucumber BDD сценариев

Цели:

• получить готовый инструмент, при помощи которого станет возможным стандартизировать процессы разработки и контроля качества исполняемых сценариев, построенных для работы в Cucumber-based технологических стеках (cucubmer jvm, SpecFlow и проч.)
• получить набор правил, позволяющих специалистам с разных проектов легко мигрировать между проектами без длительной фазы привыкания
• получить чистый, легко-читаемый код сценариев, который легко расширяется и слабо подвержен полным переписываниям текстов сценариев при минимальных изменениях UI

Итак, поехали!

Мы в прошлом посту анонсировали онлайн билеты для нашей конференции QA: Conference. Сейчас я хотел бы немного раскрыть карты касательно онлайн формата. Если посмотреть на страницу трансляции, то станет видно что на ней три зоны: Сам поток (можно выбирать среди 3 залов), комментарии — снизу и справа — репортажная лента. Также мы вводим сертификаты посещения мероприятия. Для чего все это?

Репортажная лента

Прямо во время конференции помимо видео операторов и фотографов будут проводить репортаж несколько профессиональных тестировщиков. Так обычно делают Microsoft и Apple во время своих мероприятий. Один из них — это один из ведущих на Radio QA Алексей Виноградов, который провел уже более 20 выпусков своего подкаста и готов вести репортаж прямо с конференции. Для вас это означает что ведущие будут комментировать как само событие, так и доклады (причем в разных залах, давая возможность вам переключаться на те доклады, которые вам больше нравятся), освещая основные идеи из них.

Всем привет! Семинары уже совсем близко и мы рады принять на борт еще одного прекрасного докладчика: Михаила Щербакова
А для тех, кто не в курсе, повторюсь: 15 апреля в Санкт-Петербурге, 22 апреля — в Москве, 29 апреля — в Омске, 13 мая — в Екатеринбурге и 20 мая — в Новосибирске пройдет серия семинаров CLRium #3.

В прошлом году мы говорили об околохакерских штуках — разборе памяти .NET куч, приведение типов, между которыми приведение невозможно… Делили текущий поток на два… Говорили о ядре нового .NET Core и пытались понять, для чего нам нужен (и нужен ли?) Roslyn

Наша конференция по тестированию программных систем начнется совсем скоро и, как известно, пройдет в пяти городах России, а сетка докладов по всем городам практически готова. Самое главное из новостей:

• Мы делаем онлайн-трансляции с Москвы и Санкт-Петербурга. Всех докладов. По одному билету. С записью мероприятий. Трансляцию могут смотреть посетители любых городов. Главное — наличие билета на свое мероприятие
• Макс Шоничев . Центр Сетевых Технологий. Расскажет про автоматизацию тестирования серверной части и UI в ОС Linux в условиях жестких рамок настроек безопасности системы. Много хардкора.
• Артур Орлов и Анастасия Леншмидт. АвтоТрансИнфо. Поговорят про проблемы взаимодействия между отделами QA и Dev и пути их решений
• Мы с Яном Алексеенко проведем три мастер-класса
• Алексей Виноградов — наш специальный гость из Германии (он — один из ведущих Radio QA и разработчиков Selenide). Алексей познакомит нас с тремя простыми и практичными видами PageObject архитектуры — Static, Void и Fluent и продемонстрирует использование кодом, сравнит плюсы и минусы подходов
• Также из Германии — наш гость Slava Schmidt — консультант по Scala. Он нам поведует про Property-Based Testing with API-First Approach
• Дарья Ефремова из Performance Lab расскажет про методологию Failure Modes & Effects Analysis — подход к тестированию с ретроспективой
• И многие-многие другие доклады. Зачем мне переписывать их все? Заходите к нам на сайт конференции QAC

А пока мы покупаем рации для переговоров между залами, выбираем меню для кофе-брейков и выбираем дизайн и наполнение пакета участника, предлагаю собраться рабочим коллективом и погрузиться в изучение сетки докладов. Ведь мало того что можно посмотреть доклады в своем городе, так теперь можно еще и в режиме онлайн-трансляции побывать в Питере и Москве
По цене одного билета

Есть более свежий анонс: https://habrahabr.ru/company/luxoft/blog/280524

Наша конференция по тестированию программных систем начнется совсем скоро и, как известно, пройдет в пяти городах России. Напоминаем всем, то у нас:

• от 24 полноценных доклада в Москве и Питере
• до 16 докладов — в Новосибирске и Екатеринбурге
• 8 докладов — в Омске
• возможность посмотреть записи всех докладов — всем участникам
• только полноценные, 45-минутные доклады, раскрывающие все темы «от» и «до»
• в цену до 3,000 рублей включено: все доклады всех городов — в записи, кофе-брейки и огромное количество знаний

Что в совокупности дает возможность:

• Получить много ценных знаний в формате интенсива
• Перенести свои новые знания — в проекты и тем самым облегчить своей команде и компании жизнь
• Пообщаться с коллегами по вопросам, которые вас волновали
• Услышать как про положительный опыт, так и про отрицательный

Итак, докладчики, о которых мы расскажем сегодня:

• Евгений Огородников. RmBIT — развёртываем автоматизацию тестирования с нуля — советы из личного опыта
• Сергей Махетов. Центр ИТ — автоматизация тестирования на языке Scala
• Алексей Лавренюк. Яндекс — методика и инструменты нагрузочного тестирования
• Сергей Пирогов. Записки автоматизатора — автоматизация функционального тестирования Web приложений
• Дмитрий Акмаев. DINO Systems — global CI, что это такое, и чего не хватает в классическом CI
• Александр Чумакин. JUNO — автоматизация сценариев взаимодействия интеграционных систем и нагрузочного тестирования
• Екатерина Боброва. Тамтэк — представление предметной области в автотестах
• Михаил Бобков. Neoflex — автоматизация тестирования на интеграционных проектах

Хотите почитать подробнее? Добро пожаловать под кат и на наш сайт