ASP *

Сейчас я нахожусь в процессе переноса части старых WebForms моего сайта, которые пока работают на голом железе, в ASP.NET Core и службы приложений Azure. В процессе я понял, что хочу убедиться, что мои сайты не индексируются в Google, Яндекс, Bing и в других поисковых системах.

У меня уже есть файл robots.txt, но я хочу, чтобы один служил только для продакшена, а другие — для разработки. Я думал о нескольких способах решить эту проблему. Я мог бы иметь статический файл robots.txt, файл robots-staging.txt и условно скопировать один поверх другого в моем Azure DevOps CI/CD pipeline.

Затем я понял, что самое простое — сделать robots.txt динамичным. Я думал о написании собственного промежуточного ПО, но это казалось хлопотным занятием с большим количеством кода. Я хотел посмотреть, насколько просто это может быть.

Классический VB и эра Visual

Давайте отложим разговоры о DDD и рефлексии на время. Предлагаю поговорить о простом, об организации настроек приложения.

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

public IConfiguration Configuration { get; set; }
public IHostingEnvironment Environment { get; set; }

public Startup(IConfiguration configuration, IHostingEnvironment environment)
{
   Environment = environment;
   Configuration = new ConfigurationBuilder()
            .AddJsonFile("appsettings.json")
            .AddJsonFile($"appsettings.{Environment.EnvironmentName}.json")
            .Build();
}

Но давайте разберемся, как работает конфигурация, и в каких случаях использовать данный подход, а в каких довериться разработчикам .NET Core. Прошу под кат.

Парадигма CQRS в том или ином виде предполагает, что вызовы Query не будут менять состояние приложения. То есть многократные вызовы одной и той же query, в рамках одного запроса, будут иметь один и тот же результат.

Пусть все интерфейсы, использующиеся в рамках запроса будут иметь тип IQuery или IAsyncQuery:

public interface IQuery<TIn, TOut>
{
   TOut Query(TIn input);
}

public interface IAsyncQuery<TIn, TOut>: IQuery<TIn, Task<TOut>
{
}

Blazor 0.9.0 уже доступен! Этот релиз добавляет в Blazor улучшения компонентов Razor в .NET Core 3.0 Preview 3.

Новые улучшения Razor Component теперь доступны для приложений Blazor:

• Улучшена обработка событий
• Формы и валидация

JavaScript Engine Switcher изначально создавался как вспомогательная библиотека и его развитие во многом определялось потребностями библиотек, которые его использовали. Фактически каждая его мажорная версия решала одну или несколько крупных задач необходимых для дальнейшего развития других библиотек:

1. В первой версии такой задачей было добавление как можно большего количества модулей-адаптеров для популярных JS-движков, поддерживающих платформу .NET. И это дало пользователям Bundle Transformer определенную гибкость: на компьютерах разработчика они могли использовать модуль MSIE, поддерживающий отладку JS-кода с помощью Visual Studio, а на серверах, на которых не было современной версии Internet Explorer или он не был установлен вовсе, они могли использовать модуль V8. Некоторым даже удавалось запускать Bundle Transformer в среде Mono на Linux и Mac, используя модули Jurassic и Jint.
2. Основной задачей второй версии была реализация поддержки .NET Core, которая требовалась для новой версии библиотеки ReactJS.NET. Другой немаловажной задачей было создание кроссплатформенного модуля, способного быстро обрабатывать большие объемы JS-кода (модули Jurassic и Jint не подходили для этого), и таким модулем, после ряда доработок, стал модуль ChakraCore.
3. В третьей версии основной акцент был сделан на улучшение интеграции с библиотекой ReactJS.NET и повышение производительности.

В этой статье мы рассмотрим некоторые нововведения третьей версии, которые для многих оказались неочевидными даже после прочтения текста релиза и раздела документации «How to upgrade applications to version 3.X»: изменения в классе JsEngineSwitcher, реорганизация исключений, более информативные сообщения об ошибках, прерывание и предварительная компиляция скриптов, возможность изменения максимального размера стека в модулях ChakraCore и MSIE, а также новый модуль на основе NiL.JS.

Приложения ASP.NET Core по-настоящему кросс-платформенны и могут запускаться в «никсах», а соответственно, и в Docker. Посмотрим, как их можно упаковать, чтобы развертывать на Linux и использовать в связке с Nginx. Подробности под катом!

Сколько в Альфе вообще .NET и для чего он нам нужен

4 декабря вышел ASP.NET Core 2.2, он входит в поставку .NET Core 2.2. Про .NET Core 2.2 я писал совсем недавно и теперь нужно раскрыть тему в глубину. Давайте посмотрим, чего новенького нам приготовили.

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

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

Ладно, ребята, у меня есть идея… И нет, Я НЕ ИДЕЯ-ПАРЕНЬ… Большинство из вас используют разный набор информационных ресурсов, таких как Ludum Dare, Gamedev.net, Indie Game Developers (и другие группы Facebook), Unity Connect, IndieDb, Itch.io, Game Jolt и т.д. Что, если бы мы могли объединиться, чтобы создать централизованное место, где вы могли бы остаться, чтобы обмениваться информацией о геймдеве или быть перенаправленным на внешний ресурс, упомянутый выше?

НЕТ, я не хочу по типу 50-на-50, а вы делаете всю работу. Я уже делаю это! Совершенно точно! С вами или без вас, ребята. Я мог бы лишь использовать некоторую помощь сообщества разработчиков игр.

Так в чем же суть IndieVisible?