Вот уже несколько лет в России развивается движение открытых .NET-сообществ. Первопроходцем стало питерское сообщество SpbDotNet, стартовавшем в 2015 году. Последователем питерского сообщества стало московское сообщество MskDotNet, проводящее встречи с 2016 года. Разумеется, оба сообщества очень хорошо дружат и оказывают посильную взаимопомощь. С начала создания сообществ были проведены десятки встреч, рассказаны более сотни докладов. Отлично! Давайте немного поговорим о настоящем и будущем .NET движений.

День сегодняшний

За время существования наших замечательных коммьюнити были проведены десятки встреч, обсуждены тысячи вопросов, как в форме докладов, так и в форме живого общения в кулуарах. Многие познакомились с новыми коллегами, обзавелись полезными связями, нашли ответы на интересующие их вопросы, получили море позитива, а кто-то даже нашёл новых друзей. Те, кто по каким-либо причинам не посещают, или не могут посетить наши встречи вживую — смотрят наши видео на youtube. Кстати, на данный момент наш YouTube-канал пополняется записями и с MskDotNet и c SpbDotNet. На нём выложены уже более 70 видео с докладами. Звучит просто отлично!

DotNet-коммьюнити снова на связи. Спешу сообщить, что коммьюнити .NET по-прежнему живут и развиваются! Поскольку все уже и так знают про наши .NET сообщества, не будем растекаться мыслью по древу, а перейдём сразу к делу!

Преждем чем проанонсировать новые меропириятия MskDotNet и SpbDotNet, хотелось бы сказать несколько слов о связи старшего брата — DotNext и локальных коммьюнити. Поехали!

Всем привет, MSK.NET говорит. В марте мы встречались на площадке Digital October и обсуждали Internet of Things. Встреча как всегда прошла в тёплой и дружественной атмосфере. Теперь мы знаем как и с чем едят IoT. Очень приятно было видеть множество новых лиц.

Но хватит уже отдыхать, пора браться за работу!

Всем привет, друзья!

В июне 2015 года состоялась первая встреча SPB.NET Community. Уверен, что многие из вас не только слышали о таком коммьюнити, но и смотрели отличные выступления с митапов SPB.NET (а многие и посещали встречи). Коммьюнити стало развиваться очень бодро и энтузиасты из Москвы, подхватив хороший настрой, решили создать своё локальное коммьюнити — MSK.NET.

Марк Симан написал замечательный пост «Service Locator нарушает инкапсуляцию». Название поста говорит само за себя о том, что он посвящён паттерну (анти-паттерну) Service Locator. Когда программист произвольно в коде вызывает IoC-контейнер для разрешения зависимости того или иного объекта — он использует Service Locator анти\паттерн. Марк рассматривает следующий пример:

public class OrderProcessor : IOrderProcessor
{
    public void Process(Order order)
    {
        var validator = Locator.Resolve<IOrderValidator>();
        if (validator.Validate(order))
        {
            var shipper = Locator.Resolve<IOrderShipper>();
            shipper.Ship(order);
        }
    }
}

Service Locator нарушает инкапсуляцию в статически типизированных языках, потому что этот паттерн нечётко выражает предусловия.

Лошадь уже давно мертва, но некоторые до сих пор хотят на ней поездить, так что я пну эту лошадь ещё раз. Годами я предпринимал попытки объяснить почему Service Locator это антипаттерн (например, он нарушает SOLID), но недавно меня осенила мысль, что большая часть моих аргументов фокусировалась на симптомах, упуская из внимания фундаментальную проблему.

Сейчас уже сложно вспомнить тот момент, когда я впервые осознал, что выделять функции из больших кусков полезного кода, вообще-то, хорошая идея. То ли я получил это знание из “Совершенного кода”, то ли из “Чистого кода” — сложно вспомнить. В целом, это не особенно важно. Мы все знаем, что должны разносить бизнес-логику по хорошо проименованным функциям. Самая длинная функция, которую я когда-либо видео в жизни была длиной в 5к строк. Я лично знаком с тем “программистом”, что написал тот код. Помню, как впервые встретил эту функцию. Не сложно предсказать, что моей первой реакцией было: “Какого чёрта!!! Кто произвёл на свет этот кусок дерьма???”
Да, представьте себе, этот “программист” до сих пор слоняется тут в офисе, где я сейчас работаю над текущими проектами. Не хочу углубляться в эту историю, но хочу упомянуть, что та функция длиной в 5к строк была ядром программы, размером примерно в 150к строк. Разработка программы в конце концов зашла в тупик, из-за той ужасной функции, которая крайне негативно влияла на архитектуру приложения. В конце концов было принято решение о переписывании приложения с нуля.

Я почти закончил чтение книги, написаной Джоном Сонмезом (известный блогер, разработчик ПО и автор множества курсов Pluralsight) — «Soft Skills: The software developer's life manual». Должен сказать, что книга очень легко читается, она полна ценных советов и в большой степени практична. И время от времени она смешная. В книге множество интересных разделов, но сегодня я хотел бы выжать наиболее интересные мысли из раздела, посвящённого продуктивности.

Это краткое введение в криптографию под .NET для чайников, как и следует из заголовка. Здесь будут простые вещи и никаких углубленных знаний.

Как известно, недавно была опубликована книга по паттернам проектирования за авторством Сергея Теплякова.

Дабы поддержать мною уважаемого нашего разработчика (сам Сергей, несмотря на переезд заграницу, всё ещё считает себя нашим — за пруфом идите к нему в блог), не пожалел денег и сразу же купил электронную версию. До этого я читал банду четырёх и Design Patterns Head First, поэтому, в принципе, есть с чем сравнить.
Книга занимает чуть более 300 страниц, что вполне можно осилить за неделю неторопливого чтения. Книга разбита на 4 части:

1. Паттерны поведения
2. Порождающие паттерны
3. Структурные паттерны
4. Принципы проектирования

Примечание автора: это перевод статьи Боба Мартина.
На написание этой статьи меня вдохновила статья Марка Симана «The IsNullOrWhiteSpace trap» (@ploeh). Статья Марка кратко и хорошо изложена. Пожалуйста, прочитайте сначала её, прежде чем продолжать читать данную.
Ловушка, о которой рассказывает Марк, это частный случай более общей ловушки, которую я называю воровством золота. Я могу продемонстрировать эту ловушку, возвращаясь обратно к статье Марка.

Заметьте, что первый тест, который написал Марк выглядел следующим образом:

[InlineData("Seven Lions Polarized"  , "LIONS POLARIZED SEVEN"  )]
[InlineData("seven lions polarized"  , "LIONS POLARIZED SEVEN"  )]
[InlineData("Polarized seven lions"  , "LIONS POLARIZED SEVEN"  )]
[InlineData("Au5 Crystal Mathematics", "AU5 CRYSTAL MATHEMATICS")]
[InlineData("crystal mathematics au5", "AU5 CRYSTAL MATHEMATICS")]

Он уже попал в ловушку. Почему? Потому что он уже украл золото.

Описываемая проблема в статье давно и хорошо известна, поэтому она по большей части для новичков, которые не знакомы с темой.

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

Из одной книги в другую, из статьи в статью кочует мнение о том, что выражение

try {
   //do something
}
catch(Exception ex) {
}

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

Это первый пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Известной проблемой в проектировании API является временная связность, которая получается в том случае, если в классе присутствуют скрытые отношения между двумя или более членами, требующие от клиента правильной последовательности вызовов. Это жёстко связывает члены класса во временном разрезе.

Я получил множество отзывов на мою недавнюю серию постов по Poka-yoke проектированию (я был бы расстроены, если было бы иначе). Множество из этих отзывов касаются различных технологий сериализации или трансляции, используемых обычно на границах приложения: сериализация, XML (де)гидратация (прим. переводчика: тоже самое, что и сериализация), UI-валидация и т.д. Заметьте, что такая трансляция происходит не только по периметру приложения, но также и на уровне сохраняемости (persistence). ORM-ы также являются трасляционными механизмами.
Общим для многих комментариев является утверждение о том, что большая часть технологий сериализации требует наличия конструктора по умолчанию. Например, класс XmlSerializer требует наличия конструктора по умолчанию и публичных, доступных для записи свойств. Большая часть объектно-реляционных преобразователей, которые я изучал, похоже, имеют те же требования. Контролы Windows Forms и WPF (UI – также граница приложения) почти обязаны иметь конструктор по умолчанию. Не нарушает ли это инкапсуляцию? И да и нет.

Это пятый пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Конструкторы по умолчанию являются «запахом» в коде. Именно так. Это может звучать возмутительно

Это четвёртый пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Недавно, я прочитал из какого-то технологического события Microsoft пост, написанный с энтузиазмом:

Атрибут [Required] в коде автоматически создаёт запись в БД, которая не может принимать null, а также создаёт валидацию на веб-странице – симпотично […]

Это третий пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

Автоматические свойства – одна из наиболее излишних возможностей в C#. Я знаю, что многие люди очень их любят, но они решают проблему, с которой вы и сталкиваться не должны.

Это второй пост из серии о Poka-yoke проектировании – также известном, как инкапсуляция.

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

От переводчика. Это перевод серии постов из блога Марка Симана. Я не хочу объединять некоторые из постов, несмотря на то, что они небольшие по размеру, а просто постараюсь соблюсти структуру, предложенную Марком.

Ещё немного от переводчика. POKA-YOKE можно перевести как «дуракоустойчивый» или отказоустойчивый.

Инкапсуляция является одной из самых недопонимаемых концепций в объектно-ориентированном программировании (ООП). Похоже на то, что большая часть людей думает, что, имеющая отношение к инкапсуляции, концепция «сокрытия информации», просто означает, что закрытые поля должны быть раскрыты через публичные свойства (или getter\setter-методы в языках, которые не обладают поддержкой свойств).