В предыдущей статье я начал свой рассказ динамические методы.

Мы узнали, как создать простейший динамический метод, в общих чертах обсудили, как работает стековая машина и рассмотрели некоторые простейшие операции Common Intermediate Language, которые можно использовать при генерации методов в runtime, такие как работу с константами, математические и битовые операции, а также работу с аргументами методов и локальными переменными.

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

Кроме этого поговорим про динамические методы, привязанные к объектам, и рассмотрим возможность вызова одних динамических методов из других.

На сегодняшний день в.NET существует несколько видов кодогенерации: новомодные Source Generators, компилируемые Expression Trees, динамические сборки и динамические методы. Каждый способ имеет свои области применения, плюсы и минусы.

В этой статье я хочу рассказать про динамические методы. Мы разберёмся как создавать их, как работает стековая машина и рассмотрим некоторые базовые операции Common Intermediate Language: работу с константами, математические и битовые операции, а также работу с аргументами методов и локальными переменными.

Сразу хочу сказать, что статья не содержит какого‑то хардкора и написана в большей степени для новичков. Если к теме будет интерес, постараюсь в следующей статье рассмотреть более сложные примеры (эта и так получилась достаточно длинной).

Будучи .NET разработчиком, я стараюсь периодически просматривать различные ресурсы, связанные с .NET тематикой. Как правило, это различные блоги. Иногда то тут, то там появляются какие-нибудь интересные статьи, на которые стоит обратить внимание.

Недавно я поймал себя на мысли, что делать это вручную мне как-то поднадоело. Тем более, что просматриваю я обычно одни и те же сайты. А значит время заняться автоматизацией.

Идея была достаточно проста. Нужен скрипт, который сходит по разным ссылкам, разберёт содержимое и отправит обновление в какой-нибудь telegram-канал. Нужно было только придумать, как этот скрипт запускать и где сохранять результат его работы, чтобы знать, что уже было отправлено, а что нет.

Я решил использовать в качестве хранилища GitHub, а сам скрипт (написан на TypeScript) запускать по расписанию с помощью GitHub Actions. В этой статье я хочу рассказать про некоторые технические детали реализации и поделиться полученным результатом.

Недавно я решил немного привести в порядок несколько своих .NET pet-проектов на GitHub, настроить для них нормальный CI/CD через GitHub Actions и вынести всё в отдельный репозиторий, чтобы все скрипты лежали в одном месте. Для этого пришлось как следует изучить документацию, примеры и существующие GitHub Actions, выложенные в Marketplace.

В данной статье я решил собрать самую основную информацию, которая нужна для того, чтобы написать простейший GitHub Action с использованием TypeScript.

Статья в первую очередь рассчитана на начинающих, тех, кто никогда не использовал GitHub Actions, но хотел бы быстро начать. Тем не менее, даже если у вас уже есть подобный опыт, но вы, например, не использовали ncc, то, возможно, и для вас в ней будет что-то полезное.

За последние несколько лет я очень полюбил GitLab CI. В основном за его простоту и функциональность. Достаточно просто создать в корне репозитория файл .gitlab-ci.yml , добавить туда несколько строчек кода и при следующем коммите запустится пайплайн с набором джобов, которые будут выполнять указанные команды.

А если добавить к этому возможности include и extends, можно делать достаточно интересные вещи: создавать шаблонные джобы и пайплайны, выносить их в отдельные репозитории и повторно использовать в разных проектах без копирования кода.

Но к сожалению, не всё так радужно, как хотелось бы. Инструкция script в GitLab CI очень низкоуровневая. Она просто выполняет те команды, которые ей переданы в виде строк. Писать большие скрипты внутри YAML не очень удобно. По мере усложнения логики количество скриптов увеличивается, они перемешиваются с YAML делая конфиги нечитаемыми и усложняя их поддержку.

Мне очень не хватало какого-то механизма, который бы упростил разработку больших скриптов. В результате у меня родился микрофреймворк для разработки GitLab CI, про который я и хочу рассказать в этой статье (на примере простого пайплайна для сборки docker-образов).

За последние пару лет мне довольно часто приходилось сталкиваться с Kubernetes, однако обычно это всегда происходило с позиции разработчика. Посмотреть список подов, их статусы, логи и т.п. В общем, ничего сложного.

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

Обычно изучение Kubernetes стоит начинать с minikube - консольной утилиты, которая умеет быстро создавать кластер из одного узла с использованием VirtualBox. Это самый лучший вариант для быстрого старта.

Но есть и другой вариант. Можно взять VirtualBox, создать несколько виртуальных машин, например, с Ubuntu Server и настроить небольшой кластер Kubernetes прямо на своём домашнем компьютере.

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

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

Осторожно, трафик! В статье очень много скриншотов.

В предыдущей статье я рассказал про механизм DiagnosticSource и на простом примере показал, как с его помощью можно перехватывать запросы в базу данных через классы SqlConnection и SqlCommand и измерять время их выполнения.

В настоящее время DiagnosticSource уже используется в AspNetCore, EntityFrameworkCore, HttpClient и SqlClient — каждый из них отправляет собственные события, которые могут быть перехвачены и обработаны.

В этой статье я хочу рассмотреть несколько примеров того, как можно на практике использовать DiagnosticSource в приложениях ASP.NET Core.

• CorrelationID и пробрасывание заголовков между сервисами
• Сбор метрик и трассировок
• Логирование

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

DiagnosticSource — это простой, но весьма полезный набор API (доступен в NuGet пакете System.Diagnostics.DiagnosticSource), который, с одной стороны, позволяет различным библиотекам отправлять именованные события о своей работе, а с другой — позволяет приложениям подписываться на эти события и обрабатывать их.

Каждое такое событие содержит дополнительную информацию (payload), а поскольку обработка событий происходит в том же процессе, что и отправка, эта информация может содержать практически любые объекты без необходимости сериализации/десереализации.

DiagnosticSource уже используется в AspNetCore, EntityFrameworkCore, HttpClient и SqlClient, что фактически даёт разработчикам возможность перехватывать входящие/исходящие http запросы, запросы к базам данных, получать доступ к таким объектам, как HttpContext, DbConnection, DbCommand, HttpRequestMessage и многим другим и даже изменять эти объекты при необходимости.

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

• Кэш может зависеть не только от параметров строки запроса, но и от каких-то других параметров, например от файлов-cookie или типа пользователя (например, в интернет-магазине это может быть физическое или юридическое лицо)
• Весь кэш не должен пропадать при перекомпиляции проекта (это обычно происходит при изменении файла конфигурации web.config)
• При необходимости нужно иметь возможность очистить весь кэш

В качестве вступления