Строго типизированная конфигурация в ASP.NET Core

Система конфигурации в .NET очень гибкая. Она позволяет загружать параметры из разных мест: JSON файлы, YAML файлы, переменные окружения, Azure Key Vault и многое другое. В статье предлагается использовать конечный объект IConfiguration в приложении чтобы настроить строгую типизацию.

Строго типизированная конфигурация с помощью простых объектов описывает часть вашей конфигурации вместо обычного хранения пар "ключ-значение" в IConfiguration.

Допустим, вы настраиваете интеграцию со Slack, и для отправки сообщений в канал используете вебхуки. Вам понадобится URL вебхука, и какие-нибудь дополнительные параметры, например имя приложения, которое будет использоваться для отправки сообщений в канал:

public class SlackApiSettings {
    public string WebhookUrl { get; set; }
    public string DisplayName { get; set; }
    public bool ShouldNotify { get; set; }
}

Этот объект можно привязать к вашей конфигурации в Program.cs используя метод расширения Configure<T>(). Когда вам понадобится этот объект в контроллере, вы можете внедрить зависимость IOptions<SlackApiSettings> в его контроллер. Например, чтобы внедрить конфиги в Minimal API эндпоинт и вернуть JSON с ними можно сделать так:

using Microsoft.Extensions.Options;

var builder = WebApplication.CreateBuilder(args);

// связка конфигурации с секцией SlackApi
// например SlackApi:WebhookUrl и SlackApi:DisplayName 
builder.Services.Configure<SlackApiSettings>(
    builder.Configuration.GetSection("SlackApi")); 

var app = builder.Build();

// вернуть объект конфига
app.MapGet("/", (IOptions<SlackApiSettings> options) => options.Value);

app.Run();

Под капотом система конфигурации ASP.NET Core создаёт новый объект SlackApiConfiguration и пытается сопоставить каждое свойство в объекте со значениями в секции IConfiguration.

Чтобы получить объект конфигурации, обратитесь к IOptions<T>.Value, как показано в обработчике эндпоинта.

Избегание зависимости IOptions

Некоторым людям (мне в том числе) не нравится зависимость эндпоинтов от IOptions вместо объекта конфигурации напрямую. Вы можете избежать зависимости от IOptions<T> сопоставив объект конфигурации вручную, как описано здесь, вместо использования метода расширения Configure<T>. Более простой подход (по моему мнению) это явно зарегистрировать объект SlackApiSettings в приложении и делегировать его определение на объект IOptions. Например:

using Microsoft.Extensions.Options;

var builder = WebApplication.CreateBuilder(args);

// Регистрируем объект IOptions
builder.Services.Configure<SlackApiSettings>(
    builder.Configuration.GetSection("SlackApi"));

// Явно регистрируем объект конфигурации, делегируя определение на IOptions
builder.Services.AddSingleton(resolver => 
        resolver.GetRequiredService<IOptions<SlackApiSettings>>().Value);

var app = builder.Build();

Теперь в контроллеры можно внедрять "сырой" объект настроек, без зависимости от пакета Microsoft.Extensions.Options. Я думаю, что это более предпочтительный способ, потому что в этом случае интерфейс IOptions<T> не нужен.

app.MapGet("/", (SlackApiSettings options) => options);

app.Run();

Обычно это работает хорошо, хотя тут есть пара нюансов:

• В примере выше не будет работать "перезагрузка файла" для конфигурации, так как я использовал Singleton (можно использовать Scoped, если вам нужна эта функция)
• При регистрации IOption появляется дополнительный уровень косвенности, вместо регистрации объекта SlackApiSettings напрямую в механизме внедрения зависимостей. Лично мне нравится такой подход, но вы можете использовать IOptions. Есть еще один подход, описанный в этом посте.

Наличие отличной поддержки загрузки конфигурации из разных источников это хорошо, но что будет, если вы ошибётесь в конфигурации, например допустите опечатку в JSON файле?

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

Что случится, если сопоставление проваливается?

Есть несколько случаев, когда что-то может пойти не так при сопоставлении строго типизированных объектов с конфигурацией. Я покажу несколько примеров ошибок в JSON конфигурации, используя пример обработчика, написанный выше.

Опечатка в названии секции

При сопоставлении конфигурации вы указываете имя секции, откуда брать значения. Если думать в терминах файла appsettings.json, секция — это название ключа объекта в JSON. "Logging" и "SlackApi" это секции в приведённом ниже .json файле:

{
 "Logging": {
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "AllowedHosts": "*",
  "SlackApi": {
    "WebhookUrl": "http://example.com/test/url",
    "DisplayName": "My fancy bot",
    "ShouldNotify": true
  }
}

Чтобы связать SlackApiSettings с секцией "SlackApi", можно сделать:

builder.Services.Configure<SlackApiSettings>(
    Configuration.GetSection("SlackApi")
); 

Но что если в названии секции будет допущена опечатка? Например вместо SlackApi укажем SlackApiSettings:

builder.Services.Configure<SlackApiSettings>(
    Configuration.GetSection("SlackApiSettings")
); 

Вызов эндпоинта даст:

{"webhookUrl":null,"displayName":null,"shouldNotify":false}

Все ключи получили значение по умолчанию, но никаких ошибок не произошло. Сопоставление произошло, но с пустой секцией конфигурации. Наверное, это плохо, потому что ваш код ожидает, что в webhookUrl будет валидный Uri.

Примечание переводчика: Вообще, чтобы решить эту проблему можно вместо Configuration.GetSection использовать Configuration.GetRequiredSection. Тогда при попытке сопоставить объект с несуществующей секцией возникнет исключение.

Опечатка в названии свойства

Что произойдёт, если название секции верно, но неверно название свойства?
Например, что если WebhookUrl будет записан в файле как Url?

{
  "SlackApi": {
    "Url": "http://example.com/test/url",
    "DisplayName": "My fancy bot",
    "ShouldNotify": true
  }
}

Посмотрим на результат:

{"webhookUrl":null,"displayName":"My fancy bot","shouldNotify":true}

Так как название секции правильное, DisplayName и ShouldNotify попали в объект конфигурации правильно. Но WebhookUrl равен null, так как в конфигурации нет такого поля (Url вместо него). И снова никаких сообщений о том, что поле не обработалось корректно.

Несвязываемые поля

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

public class SlackApiSettings
{
    public string WebhookUrl { get; }
    public string DisplayName { get; }
    public bool ShouldNotify { get; }
}

и снова посмотрим на ответ эндпоинта, мы получим объект со значениями по умолчанию так как парсер не сможет установить значение в объект:

{"webhookUrl":null,"displayName":null,"shouldNotify":false}

Несовместимые типы данных

И последняя ошибка в этом посте происходит, когда парсер пытается связать поля с несовместимыми типами данных. В конфигурации всё представлено в виде строк, но парсер может преобразовывать простые типы. Например "true" или "FALSE" нормально преобразуется в поле bool ShouldNotify, но если вы попытаетесь запихать туда что-нибудь ещё, например "THE VALUE", вы получите исключение, когда будете дёргать эндпоинт и парсер попытается собрать объект IOptions<T>:

Факт получения ошибки не очень хороший, но хотя бы парсер вообще кидает исключение, которое чётко даёт понять в чём проблема! Я слишком много раз попадал в ситуации, когда вызовы к внешнему API не отрабатывали только потому, что в объект конфигурации не попадала строка подключения или базовый URL из-за ошибки связывания.

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

Валидация значений IOptions

Валидация значений в IOptions появилась еще в .NET Core 2.2 с методами Validate<> и ValidateDataAnnotations(). Их проблема в том, что они не запускаются со стартом приложения, только в момент получения доступа к IOptions. Это было частичным решением проблемы, поэтому я создал NuGet пакет, который запускал валидацию на старте приложения.

К счастью, в .NET 6 появился метод ValidateOnStart(), который делает в точности то, что нам нужно — запускает валидацию при старте приложения!

Если вам интересно, как это реализовано: Фишка в использовании IHostedService для валидации. Реализацию можно посмотреть в этом PR.

Чтобы использовать такую валидацию, нужно сделать четыре вещи:

• Переключиться на services.AddOptions<T>().Bind() вместо services.Configure<T>()
• Добавить атрибуты валидации к объекту конфигурации
• Вызвать ValidateDateAnnotations() OptionsBuilder'а, возвращённого из AddOptions<T>()
• Вызвать ValidateOnStart() OptionsBuilder'а.

Метод расширения IServiceCollection.AddOptions<T>() ведёт себя как альтернативная версия Configure<T>():

• AddOptions<T>() возвращает объект OptionsBuilder<T> вместо IServiceCollection
• Нужно вызвать Bind() объекта OptionsBuilder<T> чтобы связать конфиг с объектом.

Использование объекта OptionsBuilder<T> открывает новые возможности для добавления нового функционала вроде валидации.

Вспомогательное расширение BindConfiguration() было добавлено в OptionsBuilder, чтобы упростить связывание секций конфигураций. В следующем блоке будет показано, как это сделать.

Добавим атрибуты валидации к SlackApiSettings и настроим валидацию в приложении:

using System.ComponentModel.DataAnnotations;
using Microsoft.Extensions.Options;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOptions<SlackApiSettings>()
    .BindConfiguration("SlackApi") // 👈 Связать секцию SlackApi
    .ValidateDataAnnotations() // 👈 Включить валидацию
    .ValidateOnStart(); // 👈 Валидировать при старте

// Явно зарегистрируем объект конфигурации,
// делегировав его объекту IOptions
builder.Services.AddSingleton(resolver => 
        resolver.GetRequiredService<IOptions<SlackApiSettings>>().Value);

var app = builder.Build();

app.MapGet("/", (SlackApiSettings options) => options);

app.Run();

public class SlackApiSettings
{
    [Required, Url]
    public string WebhookUrl { get; set; }
    [Required]
    public string DisplayName { get; set; }
    public bool ShouldNotify { get; set; }
}

Обратите внимание, что здесь я использовал DataAnnotations, но можно использовать другие фреймворки для валидации [п/п: У автора есть статья про подключение FluentValidation к этому механизму, её перевод выйдет следующим]

Тестирование конфигурации на старте приложения

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

Unhandled exception. Microsoft.Extensions.Options.OptionsValidationException: 
  DataAnnotation validation failed for 'SlackApiSettings' members: 
    'DisplayName' with the error: 'The DisplayName field is required.'.
   at Microsoft.Extensions.Options.OptionsFactory`1.Create(String name)
   at Microsoft.Extensions.Options.OptionsMonitor`1.<>c__DisplayClass10_0.<Get>b__0()

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

Вывод

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

В этом посте я показал как использовать ValidateOnStart() метод, появившийся в .NET 6 для того, чтобы проверять конфигурацию на старте приложения. Это позволит как можно раньше убедиться в том, что приложение получило правильную конфигурацию.

Сейчас я сижу на Windows 11, Beta Channel, мой стек технологий это .NET и React.js. Да, я из тех людей, что пишут на .NET на линуксе, и им норм. Хотя казалось бы, технология майков, бла-бла-бла... Но на самом деле, когда майки выпустили .NET официально на все платформы и открыли исходники, отпала необходимость в Mono и стало вообще хорошо.

IDE

Я человек простой. Обожаю всё, что выпускаетJetbrains, поэтому в этом плане переезд затруднений не вызвал. Rider и Webstorm как работали на линуксе, так и работают здесь.

Искренне презираю Visual Studio. По моему мнению, у нее перегруженный интерфейс, неинтуитивное управление вкладками, убогие комбинации клавиш и паршивый редактор.

К сожалению, Rider не всесилен и не имеет всех возможностей студии + не сразу получает поддержку новых версий платформы, так что иногда приходится-таки включать студию. Но разрабы молодцы и достаточно быстро вносят нужные изменения.

CLI

Люблю консольные приложения в линуксе за их простоту и очевидность. Вообще мне близка философия Unix "всё есть файл". Это очень удобно, когда конфиг любого приложения находится там, где ты его ожидаешь увидеть и это просто текстовый файл, который можно открыть чем угодно и прочитать его глазами.

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

А как вам синтаксис Powershell?

Например для того, чтобы в линуксе получить путь до бинарника (иногда бывает нужен в скриптах) используется программа which (или where, зависит от дистрибутива). В Powershell для этого нужен целый (get-command binary).Path

Или вот еще — достаточно частая встречаемая штука — поиск в текстовом файле. Типичный линуксовый cat + grep: cat textfile.txt | grep 'searchquery'. Что же нам нужно сделать для того же в Powershell? Select-String -Path "textfile.txt" -Pattern "searchquery". Очень удобно, и писать немного нужно...

Кто-то может сказать мол "Используй WSL". Если коротко, то я считаю, что это очен странная попытка майков залезть на территорию линя. По факту, это нативная виртуалка с по умолчанию подмонтированным системным диском. Я пользовался этим исключительно в связке с докером (м-м-м, супер, виртуалка в виртуалке) и думаю, что всё это достаточно ненадёжно. Так, например, у меня так и не вышло заставить вебшторм запускать npm'овские скрипты в WSL, хотя там такая фича есть. Точнее не просто npm'овские, а еще с системными командами в комплекте (mv, rm и вот это всё)

"Горе от ума"

Это моя старая шутка про то, что винда считает, что знает, что нужно пользователю, больше чем пользователь. Например, я закрыл студию и проект, который в ней был открыт, иду в проводник, пытаюсь удалить этот проект, а мне говорят, что папка используется каким-то процессом. Хм, странно. Смотрю в "Мониторе ресурсов" — и правда, папка проекта на кой-то чёрт занята процессом System. WTF?! Естественно, это не тот процесс, который можно просто взять и остановить. Спустя несколько выходов из спящего режима, система эту папку так и не отпустила. И зачем она ей нужна, вопрос...

Вместо вывода

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

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

Тот же докер лучше работает под линуксом (если это не так, тогда почему авторы докера не стали воротить своих костылей с виртуализацией винды и просто завернулись под WSL?). Поэтому для обучения DevOps я тоже буду использовать линь.

С Java я и мои ленивые распиз бравые коллеги познакомились по долгу учёбы. Небольшой проект, размером в семестр, казалось бы, что может пойти не так? Оказалось что многое, и даже очень.

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

Поэтому здесь не будет громких заявлений в духе "Java — говно, Python — лучше всех!". Я всё ещё считаю Python — лучшим второстепенным языком, который прекрасно решает многие задачи, но не любые, иногда его лучше заменить на что-то более производительное. Java же, наверняка хороша чем-то по-своему, но просто не для меня.

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

А что за проект-то собственно?

И правда, что я заладил "проект" да "проект"? Прошу любить, жаловать и не жаловаться — "Student Archive". Мде, полное название оригинальностью не блещет... "STAR" — во, так-то лучше. Это наша первая попытка в EdTech.

Мы попытались автоматизировать то, что у нас не получилось сделать вручную — собрать архив лабораторных работ, методических материалов и прочих полезностей студента. Не, ну а что? Оно всё равно годами не устаревает.

На этот семестр стояла задача написать бэкенд. Для этого был выбран классический REST API, без всякого хипстерского выпендрёжа вроде GraphQL или gRPC.

Через семестр к этому мракобесию ещё предстоит вернуться, чтобы написать к нему графический интерфейс.

Почему Java? Честно, я бы с радостью туда вообще не лез, но предмет "Платформонезависимое программирование " к этому обязывал.

Отвратительная документация

Для начала — маленькое лирическое отступление: что я считаю хорошей технической документацией?

• Хорошо структурирована
• Снабжена примерами кода (но не состоит из них полностью)
• Отдельные страницы индексируются поисковиками
• Желательно содержит мануал по старту работы с технологией
• Не сгенерирована из комментариев к коду

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

Что же мы видим, например у Hibernate-ORM?

Во-первых: с её помощью можно настраивать подключение к базе данных и описывать таблицы и связи между ними двумя кардинально разными способами

1. Через XML-файл, в котором вручную описываются все таблицы, типы данных и связи между таблицами, затем поверх этого пишутся POJO (или "простые старые Java-объекты"). По мне, так этот способ дикость. Как минимум потому, что приходится одну и ту же работу выполнять дважды. По неясной причине документация фокусируется именно на этом способе, фактически игнорируя второй, более "новый" способ (мне кажется забавным употреблять слово "новый", говоря о Java-мире. Сложилось впечатление, что инновации там происходят раз в 15 лет, но существующий софт совершенно игнорирует их чтобы избежать рефактора)
2. "Новый" же способ заключается в описании моделей через обычные классы, на поля которых навешиваются аннотации, обозначающие обязательность, связи и пр. И никакого XML! Увы, но по этой штуке документации практически нет.

И тут возникает один вопрос — какого чёрта одна библиотека реализует настолько разные способы описания моделей? В смысле, почему бы не разбить её на две части?

Во-вторых документация отвратительно структурирована, а страницы совершенно не гуглятся.

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

Нерабочие туториалы

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

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

Платный софт и пакеты

Возвращаясь к Hibernate. Одно время я подумывал о том, чтобы писать модели, используя XML.

Естественно, поскольку я человек крайне ленивый стремящийся оптимизировать противные задачи, я стал искать хоть какие-то инструменты, которые избавят меня от необходимости писать XML вручную. Что поделать, меня на физическом уровне отворачивает от этого формата. И почему в Java мире его так любят? Весит относительно много, читается тяжело, парсить — больно.

Подошло бы что угодно: GUI, DSL...

Как-то я наткнулся на одну программу, которая могла бы решить мою проблему (названия не помню, давно это было): С помощью графического интерфейса нужно было рисовать таблицы, соединять их линиями, чтобы на выходе получить Hibernate-совместимый XML файл. Окей, кажется это то, что нужно. Но вместо кнопки "Скачать" вижу лишь "Купить". Какое разочарование... Не, я конечно не против платить за лицензионный софт, но не такой, который мне понадобится буквально один раз и который стоит две сотни долларов.

Может есть какие-то альтернативы Hibernate? Нахожу парочку каких-то решений с закрытым исходным кодом и опять же платных. Серьёзно? Кажется я слишком привык к Python-миру, который держится на куче энтузиастов, которые выкладывают свои, бесспорно, огромные труды, в открытый доступ. Мде, Даня, добро пожаловать в суровый мир Enterprise-разработки.

Надо что-то делать

Пока я экспериментировал, пытаясь сделать "хорошо" неумолимо приближался дедлайн. Поэтому пришлось засунуть перфекционизм подальше и писать как придётся. В конечном счёте в основу лёг Spark, какой-то малоизвестный и минималистичный веб-фреймворк, достаточно неплохая документация которого поместилась на одну страницу. Ну а доступ к базе данных организовали с помощью JDBC, прямо в коде бросив сырые SQL-запросы. Умеем, практикуем!

За нехваткой времени в итоге многие эндпоинты были брошены возвращать 501 Not Implemented. Только т-с-с-с!

Впрочем какая разница, если в итоге проект был сдан на "отлично"?

Вместо вывода

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

Гудбай Java, нам с тобой не по пути. А я погнал учить C# для следущего гигантского проекта.

Всему причиной моё стремление пробовать разные штуки.

Я давно хотел поднять свою экосистему сайтов с портфолио, резюме, возможно даже Git-хранилище (хотя не уверен, зачем оно может быть надо)

Для начала я попробовал вспомнить молодость и написать что-то простенькое без всяких ваших новомодных фреймворков. Это было больно и очень неудобно.

Тогда я пошёл в ютуб и наткнулся на очень ламповый ролик одного японца, который, используя только neovim написал красивый сайт-портфолио на react и next.js. Я взял его за основу и написал почти такой же сайт.

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

Что ж. Значит пришло время строить экосистему. Я купил домен и прикрутил его к Vercel, хостингу от создателей Next.js. Что самое крутое, это интеграция с гитхабом — Vercel автоматически деплоит сайт на привязанные домены на каждый пуш в мастер.

Что я могу сказать по итогу трёх недель колупания в современном фронтенде. Честно говоря, впечатления очень смешанные. Местами удобно, местами неприятно.

Плюсы

• Низкий порог входа (я, практически не зная Javascript, начал понимать, что списываю из видео за два вечера)
• Live Reload (можно просто запустить сервер и писать код, не отвлекаясь на перекомпиляцию)
• Next.js берёт на себя весь геморрой со сборкой и запуском проекта, оптимизацией бандлов (даже вебпак работает под капотом, его конфиг не пишется напрямую)

Пока я это всё писал, я осознал, что объективных-то минусов и нет. Думал, что разосру тут весь фронт, а оказалось, что всё это пустые придирки. Что ж, я поражён, господа.

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

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

В итоге наткнулся на эту статью, в которой рассказывается про nimporter в связке с nimpy. Nimpy позволяет nimporter импортировать нимовские модули прямо в питонячий код и работать с ними как обычно. Ну не магия ли это?

Самый кайф в том, что nim-код компилируется в статический бинарь, которому для запуска не нужны никакие зависимости, скорость на уровне Си, а синтаксис очень простой и сильно напоминает Python (и никаких указателей).

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

И тут недавно я переустановил себе Linux (недавно написал статью с обзором конфигов) и как это у меня обычно бывает — начал смотреть “а чего бы такого автоматизировать?”. Листаю свой конфиг шелла и вижу громозкое описание переменной PATH (не нравится мне идея туеву хучу бинарей пихать в системные каталоги, поэтому кастомных путей у меня там полно).

Есть идея — запихать все пути из конфига шелла в отдельный файлик и оттуда его считывать в конфиг.

Что обычно берут люди, когда нужно что-то заскриптовать в линуксе? Правильно — Bash. Bash это что? Попаболь. Возиться с ним не очень-то хочется, ибо синтаксис неочевидный, дебажить проблематично, один гемор короче.

Попробовал сначала решить эту задачу на Python. Получилось чертовски медленно, а в конфиге шелла скорость очень важна, ведь пока не отработает скрипт конфига, промпт не отрисуется.

Хорошо, питон отбрасываем. Что у нас еще есть? Раст? Как из пушки по воробьям стрелять… Нужно что-то простое и быстрое. Вспоминаю про Nim. За пару часов написал маленький скриптик. Получилось красиво, быстро, удобно.

Теперь вместо длиннющего export PATH="$PATH:/home/dadyarri/.nimble/bin:/home/dadyarri/.npm/packages/bin:/home/dadyarri/bin:/home/dadyarri/scripts:/home/dadyarri/.local/bin"

стало export PATH="$PATH:$(/home/dadyarri/bin/getpath)"

Ну не супер ли?

Плюсы:

• Красивый, питоноподобный синтаксис;
• Статическая типизация;
• Высокая скорость запуска;
• Для запуска не нужны зависимости.
• Удобный менеджер пакетов nimble (своего репозитория у nim нет, используется git)

Минусы:

• Бардак в стандартной библиотеке (std/parsexml, std/xmlparser, std/xmltree, например);
• Опциональные круглые скобки при вызове фукнкций (это конечно больше придирка);
• Очень странное ООП. Допустим есть let file: File = open("somefile.txt", fileMode.FmWrite). Можно прочесть его содержимое, вызвав (в моём понимании, как в прочих языках) метод объекта: file.write("some text"), а можно, вызвав функцию: write(file, "some text");
• Паршивая документация, которая обычно сводится к автоматически сгенерированным из кода спискам методов, перечислений и прочего, причём даже не у всех элементов есть описание;
• Местами идиотские сообщения об ошибках, которые вообще не дают никаких подсказок о факапе и единственный способ их решить — лезть в код или в ишью.

Энивей, nim классный, есть куда развиваться. Не думаю, что он может стать чем-то серьёзным вроде дотнета (по крайней мере не скоро), но как альтернатива башу для скриптинга вполне себе неплохо.

Я в очередной раз сменил дистрибутив (на этот раз Fedora с KDE) и пересобрал с нуля конфигурационные файлы многих программ. Мне нравятся минималистичные интерфейсы, но жертвовать удобством ради этого я не хочу. О том, что в итоге получилось — под катом.

Шелл

В разное время я несколько раз прыгал от zsh к fish и обратно, но в текущей итерации вернулся на z-shell. Получилась ультимативная штука, которой очень удобно пользоваться. Вот такой набор плагинов я накидал:

• enhancd — Плагин, который запоминает последние посещённые директории и позволяет переходить по ним по ключевым словам или с помощью fzf

• fast-syntax-highlighting — Быстрая подсветка синтаксиса. Альтернатива к решению от zsh-users, которым я пользовался долгое время, но лишённый его проблем. Уж не знаю, насколько быстрее, но точно красивее.

• zsh-history-substring-search — Плагин который добавляет виджет поиска по подстроке в истории команд. По факту это работает просто — вводится часть команды и стрелками вверх-вниз выбирается нужная команда из истории

• zsh-autosuggestions — Плагин, который генерирует подсказки автодополнения, основываясь на истории запущенных команд

• powerlevel10k — красивая тема с множеством настроек и подключаемых виджетов

• fzf-tab — Плагин, заменяющий стандартный механизм отрисовки автоподсказок на fzf. Работает с огромным множеством команд, и даже может показать описание флагов некоторых команд

• autopair — Плагин, который автоматически закрывает парные скобки при вводе открывающей. Прямо как взрослые IDE!
• fzf-history-search — И еще один плагин для работы с историей. Этот открывает fzf со историей запуска команд. Благодаря ему можно быстро по неточному поиску найти нужную команду, вместо того, чтобы вечность тыкать стрелку вверх

Управляет всем этим великолепием Sheldon — универсальный менеджер плагинов, который работает как с bash, так и с zsh. Кстати, написан на Rust.

Менеджер конфигов

Все конфиги у меня лежат на гитхабе. Ими нужно как-то управлять, и чтобы не держать в домашней папке гитовый репозиторий (неудобно, есть риск добавить лишнее), я использую chezmoi. Он даёт возможность в одну команду без установки сторонних программ быстро перенести все конфиги на новую машину (потому что распространяется маленьким бинарником, который легко скачать), запустить все скрипты и получить готовую систему.

sh -c "$(curl -fsLS https://chezmoi.io/get)" -- init --apply dadyarri

(Сработает только на федоре, потому что там есть автоматически запускаемый скрипт, который устанавливает кучу пакетов через dnf)

Скрипты

Последнее время пишу разные скриптики разной степени замороченности, чтобы упростить себе жизнь (и заодно не скиснуть от безделия).

ex

Скрипт, изначально стыренный с реддита, но немного докрученный для повышения удобства. Автоматически определяет тип архива и распаковывывает его нужной программой. Опционально можно указать путь назначения, и, если программа поддерживает такое колдунство содержимое архива попадёт в указанную папку.

fdups

Самописный скрипт, ищущий дубликаты файлов в указанной директории (имя не имеет значения, поиск ведётся по хеш-сумме)

upd

Самописный скрипт, автоматизирующий обновление системы и всевозможных пакетов из кучи разных источников (сейчас доступен dnf, flatpak, neovim, мои бинарники и глобальные npm пакеты)

addpath

Переменную $PATH я не храню статически в конфиге, а держу все нужные мне пути в отдельном файлике и специальным скриптом читаю оттуда и передаю в .zshrc. Этот скрипт (в отличие от всех предыдущих, написанный на nim) записывает новый путь в указанный файл (примерно как fish_add_path только текущий шел не изменяется).

getpath

Тот скрипт, который собирает все пути из файла .paths и печатает их в формате, необходимом для $PATH, заодно проверяя, существует ли путь, чтобы лишнее не копилось в переменных окружения.

dotversion

Еще один самописный скрипт на nim. Я тут начал активно переходить на .NET и оказалось, что у них нет встроенного инструмента для управления версиями приложений (типа npm version). В итоге я потратил пару вечеров и написал свой такой инструмент, в чём-то даже превосходящий упомянутый джаваскриптовый.

В основе находится semver, поддерживается генерация мажор, минор, патч, альфа, бета, релиз-кандидат, альфа-{мажор, минор, патч}, бета-{мажор, минор, патч}, релиз-кандидат-{мажор, минор, патч} версий. Приложение автоматически найдёт файл csproj возьмет оттуда версию и запишет новую (есть флаг, запускающий вычисление новой версии, без перезаписи файла)

Ну, вроде бы и всё. Stay in touch!

Ахтунг, много текста и нет картинок, потому что пишу я это, когда удалил игру, потому что она мне осточертела.

Итак, Control. Шутер с элементами RPG от третьего лица, выпущенный несколько лет назад финской Remedy Entertainment (та, что создала Alan Wake и еще кучу неплохих игр).

Всю игру мы находимся в одном огромном здании, называющимся Федеральное Бюро Контроля или же Старейший Дом. У меня огромные проблемы с ориентированием в играх, и Control не стал исключением. Большое количество связанных помещений, уйма бектрекинга и убогая карта явно не улучшают ситуацию.

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

Сюжет

Концепция Старейшего Дома мне сильно напоминает фонд SCP (коллективный сборник статей про разнообразные паранормальные объекты). ФБК тоже изучает различные объекты, которые здесь называются Предметами Силы, по всему зданию разбросаны Исследования с пометками [Данные засекречены].

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

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

Оказывается, здание и людей в нём заразили некие астральные существа (Джесси назвала их Шумами, и всё Бюро, включая людей, которые закрыты в других секторах, начали их так называть), из-за которых люди обретают красное свечение и некоторые спецспособности, вроде метания осколков стен и левитирования.

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

Наша глобальная задача (помимо поиска брата), кто бы сомневался?, спасти Бюро от нашествия Шумов.

Боёвка и способности

Было бы странно отправлять человека с одним лишь пистолетом сражаться с Шумами. Поэтому нам постепенно (как через основные, так и через побочные квесты) выдают новые способности.

Я прошёл не всю игру (полагаю, что я даже не близко к середине), но уже получил Метание (способность хватать практически любые предметы и кидать их во врагов), Уклонение (быстрый рывок в любую сторону) и Щит (поднятие впереди себя кусков пола, которое даёт некоторую, но не абсолютную защиту героине).

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

Табельное оружие — пистолет, для которого можно открывать разные формы, благодаря которым он становится дробовиком, автоматом, и еще каким-то типами оружия, которые я еще не успел открыть. “Патроны” к табельному — это, видимо, какая-то энергия, которая тоже пополняется автоматически и ничего по локациям искать не нужно, она просто берётся из воздуха.

Стрельба приятная, казуальная, отдачи нет вообще.

Оружие модифицируется через Моды, которые выпадают из противников или лежат в заныканных ящиках (их действительно приходится иногда поискать, потому что стоят они не на виду)

Квесты

Их в игре приличное количество, но все они сводятся к одному — сходи в далёкий сектор, перестреляй несколько волн спавнящихся из воздуха Шумов. Иногда нужно запитать какие-нибудь механизмы, с помощью Левитации кинув валяющиеся рядом "батареи" (понятия не имею что это) в предусмотренные слоты.

Есть еще странная механика "Уведомлений Бюро". Это квесты, время выполнения которых ограничено. За 20 минут нужно добраться в другой сектор и убить всех врагов. Cмерть сбрасывает такие квесты, а появляются они нечасто и обычно во время замеса, что сильно отвлекает от игрового процесса.

Даже побочные квесты здесь очень нудные (те, что выдают неписи по ходу развития сюжета) — собери несколько летающих по дурацкой траектории писем или уничтожь огромный якорь, за которые дают лишь несколько очков прокачки

Противники

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

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

Сохранения

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

Итог

Ух, что-то я разогнался. В общем, Control — это красивая игра, которую я бросил и никогда не вернусь, о чём вообще не жалею. Визуально — замечательная, музыка "Старых богов Асгарда" — потрясающая, локализация от GameVoice — отличная, но слишком много спорных геймдизайнерских решений, которые меня оттолкнули.

Модификация интерфейса

В последнее время я все чаще сижу на винде, ибо огромная куча работ в универе зависит от проприетарного софта (mathcad, visual studio, excel). Раньше я писал, что использую notion-enhancer, но когда я начал активно переезжать на винду, понял, что не так уж оно и необходимо, notion сам по себе неплох. (ага, мне просто лень было его ставить, потому что он зависит от node.js)

Сегодня я попробовал обновившийся прямо перед новым годом notion-enhancer, и знаете, прям хорошо стало. Если раньше нужно было устанавливать node.js, notion-enhancer через терминал (мне в принципе пофиг, я привык работать в консоли, но представьте на месте меня обычного хомячка пользователя), то сейчас стало совсем хорошо. Они взяли официальную сборку Notion для Windows, запаковали в нее notion-enhancer со всеми зависимостями и сделали из этого маленький экзешник. Ну не красота ли?

Я не буду рассказывать о том, какие твики выбрал (тем более что нынешний список практически не отличается от прошлого), просто дам ссылку на документацию: https://notion-enhancer.github.io/

Дашборд

На этой странице просто содержатся ссылки на другие странице, тут нет ничего интересного

Учебный дашборд

Ссылки, недели, счётчик

Слева расположены ссылки на учебные ресурсы и таблица, в которой автоматически вычисляется текущая учебная неделя (какой же у Notion мерзкий синтаксис формул).

Справа - счетчик дней до конца учебы, сделанный с помощью https://indify.co

Информация о семестрах

В этом блоке находятся страницы с подробным описанием семестра (об этом ниже) и кнопка "новый год", по которой можно продублировать страницы

Список заданий

Слева перечислены актуальные задания (не выполненные, и с дедлайном меньше чем, две недели), справа - календарное представление всех созданных заданий.

Страница семестра

Вверху страницы дублируется блок со ссылками и учебной неделей (это встроенная функция Notion — Synced block, которая автоматически синхронизирует блоки между разными страницами).

Расписание

Блок с расписанием (формируется вручную и не меняется в зависимости от учебной недели). Внизу под каждой колонкой находится кнопка "Добавить пару", при нажатии на которую создается шаблон пары

Предметы

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

Есть блок с возможностью добавить лекции по предметам (он пустой, потому что мне лень таскать ноут в универ)

И блок, в который можно складировать полезные ссылки по семестру

Предмет

Вверху страницы с предметом указаны контакты преподавателя и вставлен документ с учебным планом по предмету

Затем список заданий по этому предмету и таблица с лекциями.

Список фильмов/сериалов

Этот шаблон я нашел на реддите (потрясающая штука для поиска чего бы такого прихватизировать вдохновения). u/flxp49 написал приложение, которое подключается к вашей базе данных, и автоматически подхватывает всю информацию о фильме/сериале из TMDB. Работает быстро, доступно бесплатно. Один минус - TMDB - англоязычный ресурс и поэтому искать иностранные фильмы на русском не получится, хотя русские фильмы по оригинальному названию находит и вставляет английское. В целом это не мешает использованию, так что и минусом назвать это не получается.

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

Конечно, есть фильтры, позволяющие указать год, выбрать между сериалом или фильмом и пр. Также можно искать по iMDB id.

Итог

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

Не так давно наткнулся на классный проект plashiki.su - сайт, агрегирующий разные озвучки аниме и позволяющий в один клик отмечать серии как просмотренные на Шикимори (огромная база знаний об аниме/манге/ранобэ).

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

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

Первая пришедшая в голову идея — написать свой аналог плашики. Я потратил на это где-то часов 10 (за два дня) и ничего рабочего не получил (github.com/shiki-watch). В целом, идея интересная, наверное, когда-нибудь я возьмусь за неё серьёзнее.

Jacob Reborn (v4.x)

После очередной безуспешной попытки отрефакторить код Якоба, я начал всё с начала: https://github.com/uni-jacob/jacob/tree/dev-4x. Готова система регистрации, в разработке модуль расписания. Планируется наладить сотрудничество с администрацией ВлГУ для получения свежего расписания в режиме реального времени для любой группы университета.

Основной упор сделаю на автоматические линтеры, чтобы обеспечить высокое качество кода, своевременное избавление от технического долга (поменьше "ай, и так сойдет") и написание тестов

Учеба

Закрыл долг по математике (Ура!), пытаюсь наверстать лабы, которые не делал за время подготовки. Чертовски муторное занятие...

Работа

Прошёл собеседование в Hawking Bros., и как мне показалось, проявил себя неплохо. Сказали, что работы сейчас нет и предложили подождать декабря/января, когда запустится стажировка по моему направлению. Дали список тем и технологий, которые мне нужно наверстать. Пока нарабатываю портфолио, делая для себя всякие проекты.

CRM для работы с шоколадом

Я во Владимире занимаюсь продажей шоколада в килограммовых брикетах. Мне надоели постоянные рассинхроны по остаткам в гугл табличке и фактически на складе. Поэтому пишу систему (на базе бота ВКонтакте) для автоматизации управления этим делом. Вот только в API контача нет функционала, который критически необходим для этой системы. Они где-то с полгода назад (а может и больше) добавили поддержку остатков в карточках товаров в маркете сообщества. А методы API для получения / редактирования этой циферки не обновили. Так что пока оно работает очень неполноценно, изменяя значения только во внутреннем хранилище системы.

Впереди куча планов и новостей, stay tuned!

Структура

Dashboard

Так выглядит главная страница моего воркспейса (чёрт, какой бы аналог подобрать). Слева ссылки на учебные сайты и ссылки на отдельные страницы с образовательными дисцилинами по семестрам, справа — личные страницы, не связанные с универом; внизу текущий список задач. На скрине например, предстоящие домашние задания. В этой базе данных есть еще несколько представлений:

Универ

Как я и говорил, блок "Универ" состоит из нескольких страниц с семестрами. На странице семестра есть список с изучаемыми дисциплинами, каждая с пометкой о типе аттестации по итогам семестра:

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

На странице дисциплины собрана информация о преподавателях, их контактах, расписании и домашних работах по этой дисциплине (зеркало таблицы с дашборда, в Notion называется "Linked Database")

Списки

Это отдельная страница, где я храню все, что можно категоризировать — фильмы, сериалы, игры и прочее.

Например — страница "Фильмы", другие показывать не буду, они все +- аналогичны

Организация списка дел

Статус выполнения

Это поле с выбором одного варианта из "Сделать", "В процессе" или "Выполнено".

Проект

Это поле нужно только для удобства поиска задач, на постоянной основе оно нигде не используется

Дисциплина

Основное фильтрующее поле на страницах дисциплин

Блокирующий фактор

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

Дедлайн

Дата крайнего срока выполнения задачи

И самое интересное:

Просрочено?

Это вычисляемое поле, значение которого зависит от каких-то условий, например, от значения других полей. Там находится не очень сложная формула, которая выводит "Ахтунг!", если до дедлайна осталось меньше двух дней или "Просрочено", если дедлайн прошел. Но синтаксис у Notion`а ужасен:

Notion-enhancer

Это плагин, который работает с Windows, Mac или Linux/AUR версией приложения Notion и предоставляет набор улучшений для интерфейса Notion.

Ссылка на проект

Из этого пакета я использую несколько улучшений:

• Close window to the tray — вместо закрытия окна сворачивает его в трей
• Выключил по умолчанию включенный Integrated titlebar, он отнимает слишком много места
• Integrated scrollbars — полосы прокрутки выглядят согласно выбранной теме
• Bypass preview — выключает открытие страницы в виде небольшого превью и сразу разворачивает ее на полный экран
• Font Chooser — изменяет шрифты приложения. Когда я установил шрифт Times New Roman для написания отчетов в универ, Notion решил, что нужно использовать этот шрифт во всем приложении.

• Neutral — на мой взгляд, самая приятная темная тема из всех в notion-enhancer. Ее можно видеть на всех скриншотах в этом посте.
• Property layout — по умолчанию скрывает список свойств страницы под спойлер

• Weekly view — расширение, дающее способ создания представления с календарем на неделю, вместо месяца по умолчанию. Для этого достаточно создать представление Calendar и дать ему имя weekly, что на мой взгляд не самое удачное решение не-англоязычной аудитории

Спасибо за прочтение, надеюсь эта статья была вам полезна. Я думаю, что буду иногда писать такие большие статьи с рассуждениями на разные темы, так что stay tuned!

(c) Dadyarri's corner