Когда на нашей рабочей системе происходит какая-либо ошибка, нам хочется, чтобы логи содержали всю необходимую информацию о том, из-за чего она произошла. На достаточно сложных системах это приводит к сбору большого количества данных: какие этапы обработки были выполнены, с какими аргументами вызывались те или иные методы, что вернули запросы к внешним системам и т. д. Проблема заключается в том, что эту информацию нам приходится собирать даже в случае, если никакой ошибки не произошло. А это приводит к росту объёма наших логов, за который нам приходится платить деньги.

Уровни логирования (error, warning, information, ...) здесь помогают мало. Обычно для приложения выставляется некий целевой уровень (например, information). Это означает, что все записи с уровнем выше или равным данному попадают в логи, а менее значимые выбрасываются. Но в тот момент, когда происходит ошибка, для нас наибольший интерес представляют именно записи debug-уровня, которые обычно и выбрасываются. Хорошо, если ошибка встречается довольно часто. В это случае можно временно опустить целевой уровень логирования системы, собрать информацию об ошибке, а потом вернуть уровень назад. Таким образом объём собираемых логов возрастёт только временно. Если же ошибка встречается достаточно редко, такой подход хоть и возможен, но не очень удобен, поскольку приводит к значительному росту объёма логов.

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

В .NET приложениях часто приходится обращаться к внешним HTTP-сервисам. Для этого можно воспользоваться стандартным HttpClient, или какой-нибудь сторонней библиотекой. Мне приходилось сталкиваться с Refit и RestSharp. Но никогда мне не приходилось принимать решение о том, что именно применять. Всегда я уже приходил в проект, который использовал ту или иную библиотеку. И мне пришло в голову как-то сравнить эти библиотеки, чтобы в случае необходимости осмысленно принимать решение об их использовании. Этим я и займусь в данной статье.

Но как конкретно сравнивать эти библиотеки? Я нисколько не сомневаюсь в том, что все они способны совершать HTTP-запросы и получать ответы. В конце концов, вряд ли они стали бы настолько популярны, если бы не могли делать это. Меня больше интересуют дополнительные возможности, которые бывают весьма полезны в крупных корпоративных приложениях.

Давайте приступим.

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

Эта система имеет свою цену. Например, во время тестирования вам приходится как‑то создавать экземпляры всех принимаемых конструктором параметров, чтобы протестировать ваш класс. Для этого можно использовать что‑то типа Moq. Но в таком случае встаёт проблема изменений класса. Если вы хотите добавить или удалить какой‑нибудь параметр из конструктора, вам приходится менять и тесты, даже если на них данный параметр никак не влияет.

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

OData - очень интересная технология. В несколько строчек кода вы можете добавить к своему сервису возможность фильтрации данных, постраничной выборки, частичной выборки данных, ... Сегодня ей на смену приходит GraphQL, но OData всё ещё очень привлекательна.

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

Современные запросы к Web-сервисам представляют собой сложные вещи. Сервис, к которому вы обращаетесь, может сам вызывать другие сервисы, те - третьи и т. д. Все эти запросы могут идти параллельно. Конечно, система логирования хранит информацию со всех участвовавших в запросе сервисов, но с учётом того, что часы на разных сервисах могут быть рассинхронизированы, восстановить полную картину можут быть непросто. А если добавить сюда посылку и обработку сообщений через различные очереди (Azure EventHub, RabbitMQ, ...), то картина становится ещё более запутанной.

Здесь я попытаюсь создать такую систему, которая могла бы очень быстро строить для меня диаграмму последовательности событий (sequence diagram), происходящих во время моего запроса.

Итак, начнём.

Недавно я искал систему хранения для моей программы. Она представляет собой desktop-приложение, которому нужно хранить множество объектов и осуществлять поиск текста в них. И я подумал: "Почему бы не попробовать что-то новое". Вместо SQL базы данных типа SqLite я мог бы использовать документную базу данных. Но мне хотелось бы, чтобы для неё не требовался отдельный сервер, чтобы она работала с простым файлом. Поиск в Интернет подобных систем для .NET приложений быстро вывел меня на LiteDB. Здесь я хочу поделиться тем, что я нашёл в процессе работы с этой базой данных.

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

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

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

Но мне, как программисту, интересно, можно ли решить эту проблему так сказать программным путём. И в процессе это может быть возникнут некоторые идеи о том, как можно повысить доверие к используемым нами программным системам.

Недавно я натолкнулся в нашем коде на использование пакета MediatR. Это заинтересовало меня. Почему я должен использовать MediatR? Какие преимущества он мне предоставляет? Здесь я собираюсь рассмотреть эти вопросы.

В последнее время использование протокола HTTPS для Web-ресурсов является обязательным требованиям ко всем более-менее большим Web-проектам. Эта технология основана на использовании так называемых сертификатов. Раньше за получение своего сертификата нужно было платить. Но сегодня появление таких сервисов, как Let's Encrypt сделало возможным получение сертификатов бесплатно. Таким образом, цена больше не служит оправданием отказа от использования HTTPS.

В самом простом случае сертификат позволяет установить защищённое соединение между клиентом и сервером. Но это далеко не всё, на что они способны. В частности, недавно я смотрел на Pluralsight курс Microservices Security. И там среди прочих упоминалась такая вещь, как Mutual Transport Layer Security. Она позволяет не только клиенту убедиться в том, что он общается именно с тем сервером, с которым хочет, но и сервер может узнать, что за клиент с ним общается.

Всё это накладывает на разработчиков необходимость знать способы работы с сертификатами. Именно поэтому я и решил написать эту статью. Я задумал её как место, куда можно обратиться за основными сведениями, если что-то забудешь. Не думаю, что специалисты найдут в ней что-то новое, но надеюсь, что она будет полезна новичкам и тем, кто захочет освежить свои знания в этом вопросе.

Swagger — замечательная вещь! Он позволяет легко посмотреть, каким API обладает ваш сервис, сгенерировать клиента для него на различных языках и даже попробовать поработать с сервисом через UI. В ASP.NET Core для поддержки Swagger существует пакет Swashbuckle.AspNetCore.

Но есть один недостаток, который мне не нравится. Swashbuckle способен строить описания методов, параметров и классов, основываясь на XML-комментариях в коде .NET. Но он не показывает те описания, которые применяются непосредственно к членам перечислений.

Позвольте мне рассказать вам историю. Жили-были два разработчика: Сэм и Боб. Они вместе работали над проектом, в котором была база данных. Когда разработчик хотел внести в неё изменения, он обязан был создать файл stepNNN.sql, где NNN — некоторое число. Чтобы избежать конфликтов этих чисел между различными разработчиками, они использовали простой Web-сервис. Каждый разработчик прежде чем начать писать SQL-файл должен был зайти на этот сервис и зарезервировать за собой новое число для step-файла.

В этот раз Сэму и Бобу обоим нужно было внести изменения в базу данных. Сэм послушно отправился на сервис и зарезервировал за собой число 333. А Боб забыл сделать это. Он просто использовал 333 для своего step-файла. Так случилось, что в этот раз Боб первым залил свои изменения в систему контроля версий. Когда Сэм был готов залиться, он обнаружил, что файл step333.sql уже существует. Он связался с Бобом, объяснил ему, что номер 333 был зарезервирован за ним и попросил исправить конфликт. Но Боб ответил:

— Чувак, мой код уже в 'master'е, куча разработчиков уже используют его. К тому же он уже выкачен на production. Так что просто исправь там у себя всё, что нужно.

Надеюсь, вы заметили, что произошло. Наказанным оказался человек, который следовал всем правилам. Сэму пришлось менять свои файлы, править свою локальную базу данных и т.д. Лично я ненавижу такие ситуации. Давайте посмотрим, как мы можем избежать её.

NLog: правила и фильтры

В Confirmit мы используем библиотеку NLog для логирования в наших .NET-приложениях. Хотя для этой библиотеки существует документация, для меня было сложно понять, как все это работает. В данной статье я попытаюсь объяснить, как правила и фильтры применяются в NLog. Давайте начнем.

Cake — замечательный инструмент для создания конвеера доставки для ваших приложений. Я люблю его, поскольку он позволяет мне писать этот конвеер на языке C#, который я знаю хорошо. Прекрасным свойством Cake, PSake и дургих подобных фреймворков является то, что они создают скрипт, который можно выполнять как на локальной машине разработчика, так и на CI серверах. Здесь я объясню, как организовать взаимодействие скрипта Cake с TeamCity.

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