День семьсот сорок седьмой. #ЗаметкиНаПолях #Blazor
10 Функций Blazor, о Которых Вы Вероятно не Знали. Окончание
Начало 1-2
Продолжение 3-4
Продолжение 5-6
Продолжение 7-8
9. Ленивая загрузка кода .NET
В .NET 5.0 для Blazor была добавлена новая инфраструктура для загрузки библиотек по запросу. Загрузка сборок по запросу сокращает время начальной загрузки приложения за счёт откладывания запроса ресурса до тех пор, пока он не понадобится. Хотя поддержка включена в платформу Blazor, она не включена по умолчанию, и Blazor необходимо указать, когда загружать ресурс. Одним из преимуществ ручной настройки является то, что спецификации для загрузки сборки настраиваются в соответствии с потребностями приложения.
Настройка ленивой загрузки
Чтобы включить ленивую загрузку в приложении, необходимо:
1. Описать сборки, которые будут лениво загружаться, в файле конфигурации приложения csproj:
В .NET 5.0 появилась возможность отложенной загрузки модулей через JavaScript interop.
Источник: https://www.telerik.com/blogs/10-blazor-features-you-probably-didnt-know
10 Функций Blazor, о Которых Вы Вероятно не Знали. Окончание
Начало 1-2
Продолжение 3-4
Продолжение 5-6
Продолжение 7-8
9. Ленивая загрузка кода .NET
В .NET 5.0 для Blazor была добавлена новая инфраструктура для загрузки библиотек по запросу. Загрузка сборок по запросу сокращает время начальной загрузки приложения за счёт откладывания запроса ресурса до тех пор, пока он не понадобится. Хотя поддержка включена в платформу Blazor, она не включена по умолчанию, и Blazor необходимо указать, когда загружать ресурс. Одним из преимуществ ручной настройки является то, что спецификации для загрузки сборки настраиваются в соответствии с потребностями приложения.
Настройка ленивой загрузки
Чтобы включить ленивую загрузку в приложении, необходимо:
1. Описать сборки, которые будут лениво загружаться, в файле конфигурации приложения csproj:
<ItemGroup>2. Зарегистрировать сервис
<BlazorWebAssemblyLazyLoad Include="LoadMe.dll" />
</ItemGroup>
LazyAssemblyLoader
посредством внедрения зависимостей в корневой компонент приложения, App.razor
:services.AddScoped<LazyAssemblyLoader>();3. В
App.razor
навигация перехватывается с помощью события OnNavigateAsync
, которое может использоваться для ленивой загрузки сборок на основе информации о маршруте. При возникновении события сборки извлекаются и загружаются с помощью метода LoadAssembliesAsync
сервиса LazyAssemblyLoader
:@inject LazyAssemblyLoader loader10. Ленивая загрузка JavaScript
<Router AppAssembly="@typeof(Program).Assembly"
OnNavigateAsync="@OnNavigateAsync">
…
@code {
private async Task
OnNavigateAsync(NavigationContext args) {
try {
if (args.Path.EndsWith("/lazy")) {
var assemblies =
await loader.LoadAssembliesAsync(
new List<string>(){"LoadMe.dll"});
lazyLoadedAssemblies.AddRange(assemblies);
}
}
catch (Exception ex){…}
}
}
В .NET 5.0 появилась возможность отложенной загрузки модулей через JavaScript interop.
@code {При использовании модулей JavaScript важно удалять их, если они больше не нужны. Для этого выше используется метод
IJSObjectReference module;
string result;
//Загружаем модуль
protected override async
Task OnAfterRenderAsync(bool firstRender) {
if (firstRender) {
module = await JS
.InvokeAsync<IJSObjectReference>(
"import", "./exampleJsInterop.js");
}
}
//вызываем метод модуля
Task Prompt(string message) {
result = await module
.InvokeAsync<string>(
"showPrompt", message);
}
private async ValueTask
IAsyncDisposable.DisposeAsync() {
await module.DisposeAsync();
}
}
DisposeAsync
.Источник: https://www.telerik.com/blogs/10-blazor-features-you-probably-didnt-know
День семьсот сорок восьмой. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
8. Смиритесь со страхом
В прошлом году я работал над второстепенным проектом, который провалился. Это был один из тех проектов, где я изучал новый язык, новый способ ведения дел и проверял гипотезу о нужности такого продукта на рынке. Мне было на удивление сложно продолжать работу над проектом, я чувствовал страх всякий раз, когда думал об этом.
Это был огромный клубок чувств, которые я не мог игнорировать. Но этот опыт помог мне начать замечать и менее выраженные приступы того же чувства, особенно на работе. Когда передо мной стоит грандиозная задача, и я еще не знаю, как её решить, это чувство возвращается. «Ой, как это будет работать? А как реализовать вот это? Я пока не знаю. Я ничего не знаю.»
Я научился принимать и мириться с этим чувством. Теперь это чувство возбуждает меня и стимулирует к действию. Это значит, что я узнаю что-то новое, получу новый навык и стану лучше как специалист. Я зашел так далеко, что начал отслеживать это в моём журнале: «Чувствовал ли я страх на этой неделе?» Если несколько недель подряд я вижу ответ «нет», это значит, что я слишком успокоился и не развиваюсь. Страх - это информация.
Этот мета-навык - замечать, что происходит в мозгу, - является мощным инструментом мониторинга и диагностики. Как Health Check периодически обследует и оценивает «состояние здоровья» программной системы, ведение и периодические обзоры журнала вашего состояния помогают мониторить и улучшают со временем ваше здоровье: умственное и физическое.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
8. Смиритесь со страхом
В прошлом году я работал над второстепенным проектом, который провалился. Это был один из тех проектов, где я изучал новый язык, новый способ ведения дел и проверял гипотезу о нужности такого продукта на рынке. Мне было на удивление сложно продолжать работу над проектом, я чувствовал страх всякий раз, когда думал об этом.
Это был огромный клубок чувств, которые я не мог игнорировать. Но этот опыт помог мне начать замечать и менее выраженные приступы того же чувства, особенно на работе. Когда передо мной стоит грандиозная задача, и я еще не знаю, как её решить, это чувство возвращается. «Ой, как это будет работать? А как реализовать вот это? Я пока не знаю. Я ничего не знаю.»
Я научился принимать и мириться с этим чувством. Теперь это чувство возбуждает меня и стимулирует к действию. Это значит, что я узнаю что-то новое, получу новый навык и стану лучше как специалист. Я зашел так далеко, что начал отслеживать это в моём журнале: «Чувствовал ли я страх на этой неделе?» Если несколько недель подряд я вижу ответ «нет», это значит, что я слишком успокоился и не развиваюсь. Страх - это информация.
Этот мета-навык - замечать, что происходит в мозгу, - является мощным инструментом мониторинга и диагностики. Как Health Check периодически обследует и оценивает «состояние здоровья» программной системы, ведение и периодические обзоры журнала вашего состояния помогают мониторить и улучшают со временем ваше здоровье: умственное и физическое.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
На каком языке вы написали свой первый "Hello World"?
Anonymous Poll
17%
Basic
7%
С
19%
С++
14%
С#
2%
Java
3%
JavaScript
32%
Pascal
1%
PHP
3%
Python
3%
другой
День семьсот пятидесятый. #книги
Сегодня вытащу из чата, чтобы не забыть, интересную книжку. CLR Book, или полное название «Архитектура платформы .NET» от Станислава Сидристого.
«Эта книга задумана как максимально полное описание работы .NET CLR, и частично .NET Framework и призвана в первую очередь заставить посмотреть читателя на его внутреннюю структуру под несколько другим углом: не так, как это делается обычно. Связано это в первую очередь с утверждением, которое может показаться многим очень спорным: любой разработчик обязан пройти школу C/C++. Почему? Да потому что из высокоуровневых эти языки наиболее близки к процессору, и, программируя на них, начинаешь чувствовать работу программы сильнее. Однако мир устроен несколько иначе и у нас зачастую нет никакого времени изучать то, чем мы не будем напрямую пользоваться. Поэтому в книге объяснение всех вопросов идёт с более глубокой, чем обычно, позиции и с более сложными примерами, чтобы у вас возникло чувство понимания работы CLR до последнего винтика.»
Книга доступна бесплатно на GitHub https://github.com/sidristij/dotnetbook
И, чтоб два раза не вставать, ещё одна онлайн книга «Architecture Playbook» от Maikel Mardjan.
«Умные люди думали о том, как создавать ИТ-архитектуры, с самого зарождения компьютеров. Идеи приходят и уходят, однако создание хорошей архитектуры может быть сложным и трудоёмким. Особенно когда пытаешься изобрести велосипед для себя. С помощью этого интерактивного учебника вы сможете лучше и быстрее создать свою ИТ-архитектуру. Основное внимание в этом руководстве уделяется:
1. Повторному использованию знаний.
Зачем снова изобретать велосипед? Гораздо лучше настроить велосипед, под задачи вашей организации или ИТ-проекта. Сосредоточьтесь на сложных проблемах, специфичных для контекста. Используйте известные открытые инструменты и знания для 80% проекта.
2. Более лёгкому созданию архитектурных документов.
В пособии приводится обширный список открытых инструментов, доступных для создания вашей ИТ-архитектуры. Использование этих открытых инструментов ускорит процесс создания и снизит ваши риски.
3. Улучшению качества.
Используя известные шаблоны различных архитектур или их части, вы снизите свои риски. Сложные проекты терпят неудачу. Но если вы воспользуетесь проверенными методами и инструментами, разработанными в результате десятилетий научных исследований ИТ-архитектуры, вы снизите риск для своего проекта.»
Эта книга также доступна бесплатно, правда, только на английском: https://nocomplexity.com/documents/arplaybook/introduction.html
Сегодня вытащу из чата, чтобы не забыть, интересную книжку. CLR Book, или полное название «Архитектура платформы .NET» от Станислава Сидристого.
«Эта книга задумана как максимально полное описание работы .NET CLR, и частично .NET Framework и призвана в первую очередь заставить посмотреть читателя на его внутреннюю структуру под несколько другим углом: не так, как это делается обычно. Связано это в первую очередь с утверждением, которое может показаться многим очень спорным: любой разработчик обязан пройти школу C/C++. Почему? Да потому что из высокоуровневых эти языки наиболее близки к процессору, и, программируя на них, начинаешь чувствовать работу программы сильнее. Однако мир устроен несколько иначе и у нас зачастую нет никакого времени изучать то, чем мы не будем напрямую пользоваться. Поэтому в книге объяснение всех вопросов идёт с более глубокой, чем обычно, позиции и с более сложными примерами, чтобы у вас возникло чувство понимания работы CLR до последнего винтика.»
Книга доступна бесплатно на GitHub https://github.com/sidristij/dotnetbook
И, чтоб два раза не вставать, ещё одна онлайн книга «Architecture Playbook» от Maikel Mardjan.
«Умные люди думали о том, как создавать ИТ-архитектуры, с самого зарождения компьютеров. Идеи приходят и уходят, однако создание хорошей архитектуры может быть сложным и трудоёмким. Особенно когда пытаешься изобрести велосипед для себя. С помощью этого интерактивного учебника вы сможете лучше и быстрее создать свою ИТ-архитектуру. Основное внимание в этом руководстве уделяется:
1. Повторному использованию знаний.
Зачем снова изобретать велосипед? Гораздо лучше настроить велосипед, под задачи вашей организации или ИТ-проекта. Сосредоточьтесь на сложных проблемах, специфичных для контекста. Используйте известные открытые инструменты и знания для 80% проекта.
2. Более лёгкому созданию архитектурных документов.
В пособии приводится обширный список открытых инструментов, доступных для создания вашей ИТ-архитектуры. Использование этих открытых инструментов ускорит процесс создания и снизит ваши риски.
3. Улучшению качества.
Используя известные шаблоны различных архитектур или их части, вы снизите свои риски. Сложные проекты терпят неудачу. Но если вы воспользуетесь проверенными методами и инструментами, разработанными в результате десятилетий научных исследований ИТ-архитектуры, вы снизите риск для своего проекта.»
Эта книга также доступна бесплатно, правда, только на английском: https://nocomplexity.com/documents/arplaybook/introduction.html
День семьсот пятьдесят первый.
В чём разница между DTO и POCO? Часть 1: DTO
Некоторые разработчики используют термины DTO и POCO как синонимы. Но правы ли они, и в чём разница между DTO и POCO?
DTO
Data Transfer Object - это объект, предназначенный для передачи данных. По определению DTO должен содержать только данные, без логики или поведения, т.е. не должен содержать методов. В C# DTO должен иметь только свойства, которые должны только получать и устанавливать данные, но не проверять их и не выполнять с ними других операций.
Что насчёт атрибутов и аннотаций данных?
Нет ничего необычного в добавлении метаданных в DTO, чтобы он поддерживал, например, проверку модели. Такие атрибуты не добавляют поведения самому DTO. Поведение находится вне объекта.
А как же модели представления, модели API и т.п.?
Термин DTO ничего не говорит о предполагаемом использовании объекта. Во многих архитектурах DTO могут выполнять несколько ролей. Например, в большинстве архитектур MVC с представлениями, которые поддерживают привязку к типу данных, DTO используются для передачи и привязки данных к представлению (модели представления). В идеале они не должны иметь никакого поведения, только данные, отформатированные так, как этого ожидает представление. Но не все модели представления являются DTO, поскольку в архитектурах MVVM модели обычно включают логику поведения. И даже в приложениях MVC иногда в модель представления добавляется логика, так что они больше не являются DTO.
По возможности называйте свои DTO в соответствии с их предполагаемым использованием. Имя FooDTO не указывает на то, как и где этот тип следует использовать в архитектуре приложения. Вместо этого отдавайте предпочтение именам, раскрывающим намерения, например FooViewModel.
Ниже приведен пример объекта DTO на C#:
Инкапсуляция - важный принцип ООП, но он не относится к DTO. Поскольку DTO не имеют операций или поведения и не должны иметь скрытого состояния, они не нуждаются в инкапсуляции. Не усложняйте себе жизнь, используя закрытые мутаторы или пытаясь заставить ваши DTO вести себя как неизменяемые объекты. DTO должны быть простыми в создании, написании и чтении, и поддерживать сериализацию без дополнительных усилий.
Поля или свойства
Вы можете использовать как поля, так и свойства, но некоторые платформы сериализации работают только со свойствами. Соглашение в C# предписывает использовать свойства, но, если вам больше нравятся поля или есть причина их использовать, ничто вам не мешает.
Неизменяемость и записи
Неизменяемость имеет много преимуществ при разработке ПО, а также может быть полезной функцией в DTO. Неизменяемые DTO были головной болью разработчиков из-за невозможности использовать инициализаторы для свойств только для чтения и ограниченной поддержки сериализаторами. Однако это может измениться с появлением C# 9 и записей. Кстати, вы можете встретить ещё одну аббревиатуру - Data Transfer Record, (DTR). Вот один из способов определить DTR в C# 9 (позиционное объявление):
Продолжение следует…
Источник: https://ardalis.com/dto-or-poco/
В чём разница между DTO и POCO? Часть 1: DTO
Некоторые разработчики используют термины DTO и POCO как синонимы. Но правы ли они, и в чём разница между DTO и POCO?
DTO
Data Transfer Object - это объект, предназначенный для передачи данных. По определению DTO должен содержать только данные, без логики или поведения, т.е. не должен содержать методов. В C# DTO должен иметь только свойства, которые должны только получать и устанавливать данные, но не проверять их и не выполнять с ними других операций.
Что насчёт атрибутов и аннотаций данных?
Нет ничего необычного в добавлении метаданных в DTO, чтобы он поддерживал, например, проверку модели. Такие атрибуты не добавляют поведения самому DTO. Поведение находится вне объекта.
А как же модели представления, модели API и т.п.?
Термин DTO ничего не говорит о предполагаемом использовании объекта. Во многих архитектурах DTO могут выполнять несколько ролей. Например, в большинстве архитектур MVC с представлениями, которые поддерживают привязку к типу данных, DTO используются для передачи и привязки данных к представлению (модели представления). В идеале они не должны иметь никакого поведения, только данные, отформатированные так, как этого ожидает представление. Но не все модели представления являются DTO, поскольку в архитектурах MVVM модели обычно включают логику поведения. И даже в приложениях MVC иногда в модель представления добавляется логика, так что они больше не являются DTO.
По возможности называйте свои DTO в соответствии с их предполагаемым использованием. Имя FooDTO не указывает на то, как и где этот тип следует использовать в архитектуре приложения. Вместо этого отдавайте предпочтение именам, раскрывающим намерения, например FooViewModel.
Ниже приведен пример объекта DTO на C#:
public class ProductViewModel {Инкапсуляция и DTO
public int ProductId { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public decimal UnitPrice { get; set; }
}
Инкапсуляция - важный принцип ООП, но он не относится к DTO. Поскольку DTO не имеют операций или поведения и не должны иметь скрытого состояния, они не нуждаются в инкапсуляции. Не усложняйте себе жизнь, используя закрытые мутаторы или пытаясь заставить ваши DTO вести себя как неизменяемые объекты. DTO должны быть простыми в создании, написании и чтении, и поддерживать сериализацию без дополнительных усилий.
Поля или свойства
Вы можете использовать как поля, так и свойства, но некоторые платформы сериализации работают только со свойствами. Соглашение в C# предписывает использовать свойства, но, если вам больше нравятся поля или есть причина их использовать, ничто вам не мешает.
Неизменяемость и записи
Неизменяемость имеет много преимуществ при разработке ПО, а также может быть полезной функцией в DTO. Неизменяемые DTO были головной болью разработчиков из-за невозможности использовать инициализаторы для свойств только для чтения и ограниченной поддержки сериализаторами. Однако это может измениться с появлением C# 9 и записей. Кстати, вы можете встретить ещё одну аббревиатуру - Data Transfer Record, (DTR). Вот один из способов определить DTR в C# 9 (позиционное объявление):
public record ProductDTO(int Id, string Name, string Description);Кроме того, можно использовать init-свойства:
public record ProductDTOInit-свойства поддерживают инициализацию при создании, а дальше доступны только для чтения, сохраняя неизменяемость записи. Также записи поддерживают сериализацию даже при позиционном объявлении. Вам может потребоваться несколько подсказок для сериализатора, если вы создадите свой собственный конструктор. Записи набирают популярность с выходом C# 9 и .NET 5, поэтому думаю, что они всё чаще будут использоваться для DTR.
{
public int Id { get; init; }
public string Name { get; init; }
}
Продолжение следует…
Источник: https://ardalis.com/dto-or-poco/
День семьсот пятьдесят второй.
В чём разница между DTO и POCO? Часть 2: POCO
Часть 1: DTO
Plain Old CLR/C# Object(POCO)
Обычные старые объекты CLR/C#. Что это значит? По сути, это значит, что объект не полагается на определённую структуру или библиотеку для своей работы. POCO может быть создан в любом месте приложения или в тестах, и для его работы не требуется задействовать какую-то конкретную базу данных или фреймворк.
Проще всего продемонстрировать POCO на контрпримере. Следующий класс зависит от некоторых статических методов, которые ссылаются на базу данных, что делает класс полностью зависимым от наличия базы данных для работы. Он также наследуется от типа, определённого в сторонней библиотеке:
Также мы можем предположить, что оба этих класса Product включают методы с поведением в дополнение к показанным конструкторам и свойствам. Их можно использовать как объекты DDD в приложении, моделируя состояние и поведение продуктов в системе.
POCO и DTO
Итак, почему же разработчики так часто путают эти два термина? Скорее всего потому, что все DTO являются POCO. Помните, что единственная цель DTO - как можно проще передавать данные. Их должно быть легко создавать, читать и писать. Любая зависимость, которую они могут иметь от специализированных базовых классов, нарушит правила, которые делают класс DTO. Чтобы быть DTO, класс должен быть POCO.
Если было бы верно и обратное, то можно было бы сказать, что эти два термина эквивалентны. Но мы знаем, что это не так. В предыдущем примере Product используется с Entity Framework, имеет закрытый мутатор и поведение, что лишает класс права быть DTO. Но, как мы видели, это хороший пример POCO. Итак, хотя все DTO являются POCO, не все POCO являются DTO.
Источник: https://ardalis.com/dto-or-poco/
В чём разница между DTO и POCO? Часть 2: POCO
Часть 1: DTO
Plain Old CLR/C# Object(POCO)
Обычные старые объекты CLR/C#. Что это значит? По сути, это значит, что объект не полагается на определённую структуру или библиотеку для своей работы. POCO может быть создан в любом месте приложения или в тестах, и для его работы не требуется задействовать какую-то конкретную базу данных или фреймворк.
Проще всего продемонстрировать POCO на контрпримере. Следующий класс зависит от некоторых статических методов, которые ссылаются на базу данных, что делает класс полностью зависимым от наличия базы данных для работы. Он также наследуется от типа, определённого в сторонней библиотеке:
public class Product : DataObject<Product> {Глядя на такое определение класса, представьте, что вы хотите провести модульное тестирование какого-то метода в
public Product(int id) {
Id = id;
Initialize();
}
private void Initialize() {
DataHelpers.LoadFromDB(this);
}
public int Id { get; private set; }
}
Product
. Вы пишете тест, и первое, что вы делаете, - это создаёте новый экземпляр Product
, чтобы вызвать его метод. И ваш тест сразу же терпит неудачу, потому что вы не настроили строку подключения для использования метода DataHelpers.LoadFromDB
. Это пример паттерна Active Record, который может значительно усложнить модульное тестирование. Этот класс зависит от способа его хранения. Одной из особенностей POCO является то, что они, как правило, игнорируют способ хранения. Вот пример определения POCO класса: public class Product {POCO класс не зависит от сторонних фреймворков в отношении поведения или хранения. Он не требует базового класса, особенно базового класса из сторонней библиотеки. У него нет тесной связи со статическими помощниками. Его можно без труда создать где угодно. Он более независим от способа хранения, чем предыдущий пример, хотя и не полностью. Как видно из комментария, этот закрытый конструктор без параметров существует только потому, что он нужен Entity Framework для создания экземпляра при чтении из хранилища.
public Product(int id) {
Id = id;
}
private Product() {
// для EF
}
public int Id { get; private set; }
}
Также мы можем предположить, что оба этих класса Product включают методы с поведением в дополнение к показанным конструкторам и свойствам. Их можно использовать как объекты DDD в приложении, моделируя состояние и поведение продуктов в системе.
POCO и DTO
Итак, почему же разработчики так часто путают эти два термина? Скорее всего потому, что все DTO являются POCO. Помните, что единственная цель DTO - как можно проще передавать данные. Их должно быть легко создавать, читать и писать. Любая зависимость, которую они могут иметь от специализированных базовых классов, нарушит правила, которые делают класс DTO. Чтобы быть DTO, класс должен быть POCO.
Если было бы верно и обратное, то можно было бы сказать, что эти два термина эквивалентны. Но мы знаем, что это не так. В предыдущем примере Product используется с Entity Framework, имеет закрытый мутатор и поведение, что лишает класс права быть DTO. Но, как мы видели, это хороший пример POCO. Итак, хотя все DTO являются POCO, не все POCO являются DTO.
Источник: https://ardalis.com/dto-or-poco/
День семьсот пятьдесят третий. #оффтоп #юмор
Давненько я не рекомендовал вам видосиков с ютубчика. Поэтому сегодня порекомендую целый канал. Точнее даже два… ну, то есть полтора: оригинал на английском и канал с переводами видео на русский.
Оригинальный канал называется Code Bullet. Автор использует искусственный интеллект для прохождения различных игр вроде тетриса, змейки или Flappy Bird. И делает видео с описанием процесса с уморительными комментариями.
Вот например, одно из последних (и моих любимых) видео: ИИ учится бегать.
Кто предпочитает видео на русском (а они почти все переведены), добро пожаловать на канал Code Wizer И, соответственно, вот вышеупомянутое видео на русском (осторожно, 18+).
Давненько я не рекомендовал вам видосиков с ютубчика. Поэтому сегодня порекомендую целый канал. Точнее даже два… ну, то есть полтора: оригинал на английском и канал с переводами видео на русский.
Оригинальный канал называется Code Bullet. Автор использует искусственный интеллект для прохождения различных игр вроде тетриса, змейки или Flappy Bird. И делает видео с описанием процесса с уморительными комментариями.
Вот например, одно из последних (и моих любимых) видео: ИИ учится бегать.
Кто предпочитает видео на русском (а они почти все переведены), добро пожаловать на канал Code Wizer И, соответственно, вот вышеупомянутое видео на русском (осторожно, 18+).
YouTube
A.I. Learns to Run (Creature Creator)
Have a go yourself https://www.thebigcb.com/projects/CreatureCreator (FYI it will take a while to load because i suck at websites)
Also don't use my website on mobile because it don't be workin.
Or edge don't use edge.
Or probably some other weird browsers.…
Also don't use my website on mobile because it don't be workin.
Or edge don't use edge.
Or probably some other weird browsers.…
День семьсот пятьдесят четвёртый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
77. Начинайте с «Да»
Однажды я бродил по супермаркету, пытаясь найти эдамаме (что, по моему представлению, должно быть каким-то овощем). Я не был уверен, искать его в овощном, в заморозке или в консервах. Я сдался и попросил продавщицу помочь, но она тоже не этого знала!
Она могла ответить мне по-разному. Например, могла пристыдить меня незнанием элементарных вещей, могла просто ткнуть наугад в сторону какого-нибудь отдела или даже просто ответить «нет», лишь бы отвязаться от меня. Но вместо этого она восприняла запрос как возможность найти решение и помочь клиенту. Она позвонила кому-то и через пару минут привела меня к нужному предмету, который находился отделе заморозки.
Сотрудница в этом случае рассмотрела запрос и исходила из того, что надо решить проблему и удовлетворить запрос. Она начала с «да», а не с «нет».
Когда меня впервые назначили на руководящую должность в технической сфере, я почувствовал, что моя задача - защищать своё прекрасное ПО от потока нелепых требований, исходящих от менеджеров продукта и бизнес-аналитиков. Я начинал большинство разговоров, рассматривая просьбу как что-то, что нужно отклонить, а не как что-то, что нужно удовлетворить.
В какой-то момент меня осенило, что, возможно, есть другой способ. Может стоит попробовать изменить мой подход и начинать с «да», а не с «нет». И я пришёл к выводу, что это важное качество технического лидера.
Эта простое понимание радикально изменило мой подход к работе. Оказывается, есть много способов сказать «да». Когда кто-то говорит вам: «Слушай, единственное, чего не хватает этому приложению - это сделать все окна круглыми и полупрозрачными!», - вы можете сразу отвергнуть это предложение, а также поставить вопрос о психической вменяемости коллеги. Но часто вместо этого лучше начать с вопроса: «А почему?». Часто существует какая-то реальная и веская причина, по которой этот человек ставит во главу угла круглые полупрозрачные окна. Например, возможно, вы собираетесь заключить контракт с новым крупным клиентом, который требует именно этого.
Чаще всего получается, что, когда вы знаете контекст запроса, открываются новые возможности. Например, иногда даже не надо менять существующий продукт, и можно ответить на запрос «да», не прилагая больших усилий: «На самом деле, в настройках вы можете загрузить скин круглых полупрозрачных окон и использовать его.»
Иногда у другого человека просто может быть идея, идущая в разрез с вашими взглядами на продукт. Мне в таком случае обычно помогает обратить вопрос «Почему?» к себе. Иногда вы можете обнаружить, что веских причин для отказа просто нет, и ваша первоначальная реакция была ошибочной. Возможно, вам придется поднять вопрос на ступеньку выше и привлечь других лиц, принимающих ключевые решения. Помните, цель всего этого - сказать «да» другому человеку и попытаться найти выход, который удовлетворит не только его, но и вас, и всю вашу команду.
Если вы сможете дать убедительное объяснение тому, почему запрос несовместим с существующим продуктом, то, скорее всего, следующий вопрос, который у вас возникнет - создаёте ли вы правильный продукт. Независимо от того, какой на него будет получен ответ, в итоге все в команде будут более чётко понимать, что должно быть в продукте, а что нет.
Начать с «да» означает работать вместе с коллегами, а не против них.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Alex Miller
97 Вещей, Которые Должен Знать Каждый Программист
77. Начинайте с «Да»
Однажды я бродил по супермаркету, пытаясь найти эдамаме (что, по моему представлению, должно быть каким-то овощем). Я не был уверен, искать его в овощном, в заморозке или в консервах. Я сдался и попросил продавщицу помочь, но она тоже не этого знала!
Она могла ответить мне по-разному. Например, могла пристыдить меня незнанием элементарных вещей, могла просто ткнуть наугад в сторону какого-нибудь отдела или даже просто ответить «нет», лишь бы отвязаться от меня. Но вместо этого она восприняла запрос как возможность найти решение и помочь клиенту. Она позвонила кому-то и через пару минут привела меня к нужному предмету, который находился отделе заморозки.
Сотрудница в этом случае рассмотрела запрос и исходила из того, что надо решить проблему и удовлетворить запрос. Она начала с «да», а не с «нет».
Когда меня впервые назначили на руководящую должность в технической сфере, я почувствовал, что моя задача - защищать своё прекрасное ПО от потока нелепых требований, исходящих от менеджеров продукта и бизнес-аналитиков. Я начинал большинство разговоров, рассматривая просьбу как что-то, что нужно отклонить, а не как что-то, что нужно удовлетворить.
В какой-то момент меня осенило, что, возможно, есть другой способ. Может стоит попробовать изменить мой подход и начинать с «да», а не с «нет». И я пришёл к выводу, что это важное качество технического лидера.
Эта простое понимание радикально изменило мой подход к работе. Оказывается, есть много способов сказать «да». Когда кто-то говорит вам: «Слушай, единственное, чего не хватает этому приложению - это сделать все окна круглыми и полупрозрачными!», - вы можете сразу отвергнуть это предложение, а также поставить вопрос о психической вменяемости коллеги. Но часто вместо этого лучше начать с вопроса: «А почему?». Часто существует какая-то реальная и веская причина, по которой этот человек ставит во главу угла круглые полупрозрачные окна. Например, возможно, вы собираетесь заключить контракт с новым крупным клиентом, который требует именно этого.
Чаще всего получается, что, когда вы знаете контекст запроса, открываются новые возможности. Например, иногда даже не надо менять существующий продукт, и можно ответить на запрос «да», не прилагая больших усилий: «На самом деле, в настройках вы можете загрузить скин круглых полупрозрачных окон и использовать его.»
Иногда у другого человека просто может быть идея, идущая в разрез с вашими взглядами на продукт. Мне в таком случае обычно помогает обратить вопрос «Почему?» к себе. Иногда вы можете обнаружить, что веских причин для отказа просто нет, и ваша первоначальная реакция была ошибочной. Возможно, вам придется поднять вопрос на ступеньку выше и привлечь других лиц, принимающих ключевые решения. Помните, цель всего этого - сказать «да» другому человеку и попытаться найти выход, который удовлетворит не только его, но и вас, и всю вашу команду.
Если вы сможете дать убедительное объяснение тому, почему запрос несовместим с существующим продуктом, то, скорее всего, следующий вопрос, который у вас возникнет - создаёте ли вы правильный продукт. Независимо от того, какой на него будет получен ответ, в итоге все в команде будут более чётко понимать, что должно быть в продукте, а что нет.
Начать с «да» означает работать вместе с коллегами, а не против них.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Alex Miller
День семьсот пятьдесят пятый. #Оффтоп #ЗадачиНаСобеседовании
В сегодняшний праздничный день у меня для вас сразу 2 видео. Наш старый знакомый Nick Chapsas выпустил одно из самых полезных, на мой взгляд, своих видео (в двух частях). Это одна из задач, которые вам могут дать на собеседовании. Она несколько отличается от рассмотренных нами ранее (предыдущие примеры см. по хештегу #ЗадачиНаСобеседовании).
Суть в том, что вам даётся небольшой «легаси» проект, и ваша задача – отрефакторить код, применяя все принципы, которые вы знаете: DRY, KISS, YAGNI, SOLID, вотэтовсё. Также есть ограничения. Например, вам нельзя никак изменять класс Program.cs (возможно и ещё какие-то). Кроме того, вы должны помнить, что класс является частью более крупного проекта, то есть нельзя бездумно менять открытый интерфейс класса. У вас есть обычно два часа. Можно дольше, если обоснуете, зачем вам дополнительное время. В общем, задачка показалась мне очень интересной.
Ещё интереснее было бы, конечно, взять исходный код, попытаться отрефакторить самому, а потом сравнить с тем, что получилось у Ника. Но Ник, как истинный англосакс, даёт исходники только патреонам за денюжку. Влепите ему диз за это)))
Как бы то ни было, просто посмотреть его решение тоже довольно познавательно. Так что выделите час праздничного дня, не пожалеете!
Часть 1: https://youtu.be/U3QvTaw224o
Часть 2: https://youtu.be/Yd4GnWeEkIY
В сегодняшний праздничный день у меня для вас сразу 2 видео. Наш старый знакомый Nick Chapsas выпустил одно из самых полезных, на мой взгляд, своих видео (в двух частях). Это одна из задач, которые вам могут дать на собеседовании. Она несколько отличается от рассмотренных нами ранее (предыдущие примеры см. по хештегу #ЗадачиНаСобеседовании).
Суть в том, что вам даётся небольшой «легаси» проект, и ваша задача – отрефакторить код, применяя все принципы, которые вы знаете: DRY, KISS, YAGNI, SOLID, вотэтовсё. Также есть ограничения. Например, вам нельзя никак изменять класс Program.cs (возможно и ещё какие-то). Кроме того, вы должны помнить, что класс является частью более крупного проекта, то есть нельзя бездумно менять открытый интерфейс класса. У вас есть обычно два часа. Можно дольше, если обоснуете, зачем вам дополнительное время. В общем, задачка показалась мне очень интересной.
Ещё интереснее было бы, конечно, взять исходный код, попытаться отрефакторить самому, а потом сравнить с тем, что получилось у Ника. Но Ник, как истинный англосакс, даёт исходники только патреонам за денюжку. Влепите ему диз за это)))
Как бы то ни было, просто посмотреть его решение тоже довольно познавательно. Так что выделите час праздничного дня, не пожалеете!
Часть 1: https://youtu.be/U3QvTaw224o
Часть 2: https://youtu.be/Yd4GnWeEkIY
YouTube
The refactoring test (1) - Dependency Inversion & Unit tests | Cracking the .NET interview
Become a Patreon and get source code access: https://www.patreon.com/nickchapsas
Check out my courses: https://dometrain.com
Hello everybody I'm Nick and in this video series I am teaching you how you can crack every part of the interview process as a .NET…
Check out my courses: https://dometrain.com
Hello everybody I'm Nick and in this video series I am teaching you how you can crack every part of the interview process as a .NET…
День семьсот пятьдесят шестой. #ЧтоНовенького
Выпущен .NET 6 Preview 1
Кажется, не так давно мы обсуждали вкусности .NET 5, а теперь мы уже переходим к .NET 6. Помню времена, когда даже младшие версии фреймворка иногда содержали огромные изменения. Например, async/await был добавлен в версию .NET Framework 4.5, которая в наши дни означала бы «незначительное» обновление. И вообще, между версиями 1.0 и 4.8 прошло 17 лет.
Первая версия .NET Core была выпущена в 2016 году, и вот мы в 2021 году, всего 5 лет спустя, уже готовы увидеть превью .NET Core 6. Скорость разработки современного программного обеспечения просто поражает. Прошли те времена, когда разработчики запирались в отделах и работали по три года до крупного релиза.
Вы можете скачать .NET 6 Preview 1 здесь: https://dotnet.microsoft.com/download/dotnet/6.0
Что нового?
Как правило, первый предварительный выпуск закладывает основу для будущих новинок и не обязательно содержит большого количества «игрушек», с которыми можно поиграть. Однако некоторые функции действительно были добавлены:
1. Первая итерация переноса Xamarin в .NET для унификации платформ, то есть возможности создавать приложения для Android/IOS в .NET.
2. Первая попытка использования Blazor для настольных приложений (на первый взгляд кажется, что это очень похоже на использование Electron, например, это использование элемента веб-представления в настольных приложениях).
3. Кажется, говорят об улучшении функции горячей перезагрузки. Сложно найти много информации по этому поводу. В .NET CLI уже есть «
4. Улучшение однофайловых приложений, так чтобы они фактически выполнялись из этого единственного файла, а не распаковывались во временные каталоги. Это уже имело место для однофайловых приложений под Linux в .NET 5, но в .NET 6 эта функциональность была расширена для Windows и Mac.
5. appsettings.json в Visual Studio и VSCode (с расширением C#) теперь имеет автозаполнение для часто используемых конфигураций в ASP.NET Core, включая настройку ведения журнала, фильтрации хостов и Kestrel.
6. WPF теперь поддерживается в ARM64.
Основной путь изменений в .NET 6 (и даже .NET 5) - это объединение различных платформ и фреймворков, которые находятся под знаменем .NET. В .NET 5 это была в основном разработка для настольных компьютеров, а в .NET 6 - это разработка мобильных приложений с Xamarin.
Источник: https://dotnetcoretutorials.com/2021/02/21/net-6-preview-1-has-been-released/
Выпущен .NET 6 Preview 1
Кажется, не так давно мы обсуждали вкусности .NET 5, а теперь мы уже переходим к .NET 6. Помню времена, когда даже младшие версии фреймворка иногда содержали огромные изменения. Например, async/await был добавлен в версию .NET Framework 4.5, которая в наши дни означала бы «незначительное» обновление. И вообще, между версиями 1.0 и 4.8 прошло 17 лет.
Первая версия .NET Core была выпущена в 2016 году, и вот мы в 2021 году, всего 5 лет спустя, уже готовы увидеть превью .NET Core 6. Скорость разработки современного программного обеспечения просто поражает. Прошли те времена, когда разработчики запирались в отделах и работали по три года до крупного релиза.
Вы можете скачать .NET 6 Preview 1 здесь: https://dotnet.microsoft.com/download/dotnet/6.0
Что нового?
Как правило, первый предварительный выпуск закладывает основу для будущих новинок и не обязательно содержит большого количества «игрушек», с которыми можно поиграть. Однако некоторые функции действительно были добавлены:
1. Первая итерация переноса Xamarin в .NET для унификации платформ, то есть возможности создавать приложения для Android/IOS в .NET.
2. Первая попытка использования Blazor для настольных приложений (на первый взгляд кажется, что это очень похоже на использование Electron, например, это использование элемента веб-представления в настольных приложениях).
3. Кажется, говорят об улучшении функции горячей перезагрузки. Сложно найти много информации по этому поводу. В .NET CLI уже есть «
dotnet watch
», но это скорее полная сборка, чем приятная итеративная горячая перезагрузка.4. Улучшение однофайловых приложений, так чтобы они фактически выполнялись из этого единственного файла, а не распаковывались во временные каталоги. Это уже имело место для однофайловых приложений под Linux в .NET 5, но в .NET 6 эта функциональность была расширена для Windows и Mac.
5. appsettings.json в Visual Studio и VSCode (с расширением C#) теперь имеет автозаполнение для часто используемых конфигураций в ASP.NET Core, включая настройку ведения журнала, фильтрации хостов и Kestrel.
6. WPF теперь поддерживается в ARM64.
Основной путь изменений в .NET 6 (и даже .NET 5) - это объединение различных платформ и фреймворков, которые находятся под знаменем .NET. В .NET 5 это была в основном разработка для настольных компьютеров, а в .NET 6 - это разработка мобильных приложений с Xamarin.
Источник: https://dotnetcoretutorials.com/2021/02/21/net-6-preview-1-has-been-released/
День семьсот пятьдесят седьмой. #Оффтоп #ЗадачиНаСобеседовании
Что я Узнал о C# из Собеседований. Начало
Недавно я прошел серию собеседований в нескольких крупнейших технологических компаниях. Процессы собеседований в них сильно отличались, но у них также было много общего, например, упор на задачи на написание кода. Сортировка, нахождение всех возможных комбинаций или нахождение выхода из лабиринта. Я не знаю, как это связано с реальной разработкой ПО. Я не помню, чтобы мне когда-либо приходилось самому писать алгоритм сортировки в повседневной работе. Тем не менее, очевидно, что разработчик, способный решить эти проблемы, будет лучше справляться и с проблемами реальной жизни. Поэтому я хочу описать, что я узнал о C# во время собеседований. У меня больше 10 лет опыта в C#, но повседневная разработка и прохождение интервью – это разные вещи.
1. Многомерные массивы могут быть полезны
Не думаю, что я когда-либо использовал многомерный массив в своей работе. Конечно, я иногда использовал список списков
Многомерные массивы - это не то же самое, что массивы массивов, например
Вот пример вопроса, в котором могут пригодиться многомерные массивы: для двумерного пространства размером MxN квадратных ячеек, где каждая ячейка является либо свободным пространством, либо стеной, найдите наибольшую связанную область из свободных ячеек и верните количество ячеек в ней.
2. Используйте кортежи, вместо классов
Я довольно редко использую кортежи. Вероятно потому, что я пока не привык к их более красивому синтаксису. Обычно я выбираю класс или структуру. Классы делают код более структурированным и, возможно, более читаемым. Но на самом деле у кортежей очень хороший и, что важно, более компактный синтаксис. Писать нужно меньше, менять нужно меньше. Эти вещи действительно важны на собеседовании. Нужно тратить минимум времени на ввод кода, чтобы у вас было больше времени на размышления.
Допустим, у меня есть метод, который возвращает точку в трёхмерном массиве. При использовании класса я бы написал:
Тогда как с кортежами всё проще:
Имейте в виду, что на собеседовании вы будете писать в своего рода онлайн-блокноте, где у вас нет сниппетов, автозаполнения и прочих прелестей, к которым вы привыкли в Visual Studio.
Продолжение следует…
Источник: https://michaelscodingspot.com/what-i-learned-about-c-from-job-interviews/
Автор: Michael Shpilt.
Что я Узнал о C# из Собеседований. Начало
Недавно я прошел серию собеседований в нескольких крупнейших технологических компаниях. Процессы собеседований в них сильно отличались, но у них также было много общего, например, упор на задачи на написание кода. Сортировка, нахождение всех возможных комбинаций или нахождение выхода из лабиринта. Я не знаю, как это связано с реальной разработкой ПО. Я не помню, чтобы мне когда-либо приходилось самому писать алгоритм сортировки в повседневной работе. Тем не менее, очевидно, что разработчик, способный решить эти проблемы, будет лучше справляться и с проблемами реальной жизни. Поэтому я хочу описать, что я узнал о C# во время собеседований. У меня больше 10 лет опыта в C#, но повседневная разработка и прохождение интервью – это разные вещи.
1. Многомерные массивы могут быть полезны
Не думаю, что я когда-либо использовал многомерный массив в своей работе. Конечно, я иногда использовал список списков
List<List<T>>
и, возможно, список массивов List<int[]>
, а иногда даже список словарей массивов List<Dictionary<int,string[]>>
. Но я обнаружил, что многомерные массивы очень полезны в упражнениях по кодированию.Многомерные массивы - это не то же самое, что массивы массивов, например
int[][]
(зубчатые массивы). Последние представляют собой набор массивов, каждый из которых может иметь разную длину. Многомерный массив больше подходит для решения общих задач, таких как представление двухмерного лабиринта или трехмерного куба. Если вы собираетесь на собеседование в ближайшее время, освежите в голове синтаксис:int[,] arr = new int[3, 2]
{{1, 2},{3, 4},{5, 6}};
int dimLen1 = arr.GetLength(0); //3
int dimLen2 = arr.GetLength(1); //2
var p00 = arr[0, 0]; //1
var p01 = arr[0, 1]; //2
var p10 = arr[1, 0]; //3
Вот пример вопроса, в котором могут пригодиться многомерные массивы: для двумерного пространства размером MxN квадратных ячеек, где каждая ячейка является либо свободным пространством, либо стеной, найдите наибольшую связанную область из свободных ячеек и верните количество ячеек в ней.
2. Используйте кортежи, вместо классов
Я довольно редко использую кортежи. Вероятно потому, что я пока не привык к их более красивому синтаксису. Обычно я выбираю класс или структуру. Классы делают код более структурированным и, возможно, более читаемым. Но на самом деле у кортежей очень хороший и, что важно, более компактный синтаксис. Писать нужно меньше, менять нужно меньше. Эти вещи действительно важны на собеседовании. Нужно тратить минимум времени на ввод кода, чтобы у вас было больше времени на размышления.
Допустим, у меня есть метод, который возвращает точку в трёхмерном массиве. При использовании класса я бы написал:
class Point3D {
public int X { get; set; }
public int Y { get; set; }
public int Z { get; set; }
}
private Point3D Calc() {…}
Тогда как с кортежами всё проще:
private (int X, int Y, int Z) Calc(){ ... }
Имейте в виду, что на собеседовании вы будете писать в своего рода онлайн-блокноте, где у вас нет сниппетов, автозаполнения и прочих прелестей, к которым вы привыкли в Visual Studio.
Продолжение следует…
Источник: https://michaelscodingspot.com/what-i-learned-about-c-from-job-interviews/
Автор: Michael Shpilt.
День семьсот пятьдесят восьмой. #Оффтоп #ЗадачиНаСобеседовании
Что я Узнал о C# из Собеседований. Продолжение
Начало
3. Бинарные операции – это вещь!
Как часто вы используете операторы
Теперь рассмотрим итерацию в двоичном формате от 0 до 2^3. Если каждая цифра описывает элемент массива, который присутствует или нет, то это один из способов распечатать все возможные итерации. Требуемый выше результат можно описать как:
Большинство методов, используемых в задачах, аналогичны методам, используемым в реальной жизни. Для строк это
Источник: https://michaelscodingspot.com/what-i-learned-about-c-from-job-interviews/
Автор: Michael Shpilt.
Что я Узнал о C# из Собеседований. Продолжение
Начало
3. Бинарные операции – это вещь!
Как часто вы используете операторы
<<
, >>
, &
и |
в ваших приложениях? Думаю, не часто. Я тоже, но они могут быть довольно полезны. Небольшое напоминание:int a = 15;Одна из особенностей двоичного исчисления заключается в том, что итерация по основанию 2 может быть полезна в задачах на перестановку. Например: для заданного массива элементов, распечатать все возможные комбинации этих элементов, в которых каждый элемент может либо присутствовать, либо отсутствовать. Порядок не имеет значения. То есть для массива
Convert.ToString(a, to_base: 2); //1111
//сдвиг вправо дважды (деление на 4)
a = a >> 2; //11
//сдвиг влево трижды (умножение на 8)
a = a << 3; //11000
a = a & 0b_11111; // не изменяется
// остаётся 1000, т.к. левый бит обнуляется
a = a & 0b_1111; //1000
a = a | 0b_1; // становится 1001
a = a | 0b_110; // становится 1111
["a", "b", "c"]
вывод будет следующим: "", a, b, c, ab, ac, bc, abc
Теперь рассмотрим итерацию в двоичном формате от 0 до 2^3. Если каждая цифра описывает элемент массива, который присутствует или нет, то это один из способов распечатать все возможные итерации. Требуемый выше результат можно описать как:
000, 001, 010, 100, 110, 101, 011, 1114. Полезные штуки со строками и массивами
Большинство методов, используемых в задачах, аналогичны методам, используемым в реальной жизни. Для строк это
.Substring
, .Contains
, .Replace
, string.Equals
, .ToLower
, .ToUpper
и т.д. Один из методов, полезных в этих задачах, но редко используемый в моей работе, - это string.Join
:var joined = string.Join(",",Для массивов есть полезный метод
new[]{"a","b","c"}); // "a,b,c"
Array.Sort
, который может принимать делегат Comparison<T>
для нужной вам сортировки. Предположим, вы хотите отсортировать группу строк по последней букве:var words = new[]{"cat", "job", "zebra", "row"};Еще один полезный метод -
Array.Sort(words, (w1, w2) => {
var last1 = w1[w1.Length-1];
var last2 = w2[w2.Length-1];
return last1 < last2 ? -1 : 1;
//как вариант last1.CompareTo(last2);
});
// zebra, job, cat, row
Array.Copy
. Помимо прочего, он может копировать фрагмент массива в новый массив:var words = new[]{"cat", "job", "zebra", "row"};Конечно, есть и другие способы это сделать, например, LINQ или с помощью диапазонов.
string[] dest = new string[2];
Array.Copy(words, sourceIndex: 1,
dest, destinationIndex: 0, length: 2);
// job, zebra
Источник: https://michaelscodingspot.com/what-i-learned-about-c-from-job-interviews/
Автор: Michael Shpilt.
День семьсот пятьдесят девятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
78. Шаг назад и автоматизация, автоматизация, автоматизация
Я работал с программистами, которые, когда их просили произвести подсчёт строк кода в модуле, вставляли все файлы в один текстовый редактор и использовали его функцию подсчёта строк. Затем они делали это снова на следующей неделе. И через неделю. Это было плохо.
Я работал над проектом, в котором был трудоемкий процесс развёртывания, включающий подписание кода и перенос результата на сервер, требующий множества щелчков мышью. Кто-то автоматизировал это, и скрипт запускался сотни раз во время финального тестирования, гораздо чаще, чем ожидалось. Это было хорошо.
Итак, почему люди выполняют одну и ту же задачу снова и снова, вместо того чтобы остановиться, сделать шаг назад и потратить время на её автоматизацию?
Распространённое заблуждение №1: автоматизация предназначена только для тестирования
Конечно, автоматизация тестирования - это здорово, но зачем останавливаться на достигнутом? В любом проекте изобилуют повторяющиеся задачи: контроль версий, компиляция, упаковывание, создание документации, развёртывание и отчетность. Для многих из этих задач скрипт окажется мощнее, чем мышь. Выполнение утомительных задач станет быстрее и надёжнее.
Распространённое заблуждение №2: у меня есть IDE, поэтому мне не нужно автоматизировать
Вы когда-нибудь использовали аргумент «Но это работает на моей машине?» в спорах с товарищами по команде? Современные IDE имеют тысячи потенциальных настроек, и практически невозможно гарантировать, что все члены команды имеют одинаковые конфигурации. Системы автоматизации сборки дадут вам контроль и повторяемость результата.
Распространённое заблуждение №3: чтобы автоматизировать это, мне нужно изучить экзотические инструменты
Вы можете пойти по длинному пути, используя полноценный консольный язык, например, bash или Power-Shell, и систему автоматизации сборки. Если же вам нужно взаимодействовать с веб-сайтами, можно использовать такие инструменты, как Selenium.
Распространённое заблуждение №4: я не могу автоматизировать эту задачу, потому что не могу работать с этим форматом файлов
Если для части вашего процесса требуются документы Word, электронные таблицы или изображения, это действительно может быть сложно автоматизировать. Но действительно ли это необходимо? Можете ли вы использовать обычный текст? CSV файлы вместо таблиц? XML/JSON? Часто небольшая подгонка процесса под автоматизацию может дать хорошие результаты и значительно снизить трудозатраты.
Распространённое заблуждение №5: у меня нет времени разбираться в этом
Вовсе не обязательно зазубрить все команды bash. Учитесь на ходу. Когда у вас есть задача, которую, по вашему мнению, можно и нужно автоматизировать, узнавайте об инструментах автоматизации ровно столько, сколько вам нужно. И делайте это на ранних этапах проекта, когда обычно легче найти время. Как только вы добьетесь успеха, вы (и ваш начальник) увидите, что имеет смысл инвестировать в автоматизацию.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Cay Horstmann
97 Вещей, Которые Должен Знать Каждый Программист
78. Шаг назад и автоматизация, автоматизация, автоматизация
Я работал с программистами, которые, когда их просили произвести подсчёт строк кода в модуле, вставляли все файлы в один текстовый редактор и использовали его функцию подсчёта строк. Затем они делали это снова на следующей неделе. И через неделю. Это было плохо.
Я работал над проектом, в котором был трудоемкий процесс развёртывания, включающий подписание кода и перенос результата на сервер, требующий множества щелчков мышью. Кто-то автоматизировал это, и скрипт запускался сотни раз во время финального тестирования, гораздо чаще, чем ожидалось. Это было хорошо.
Итак, почему люди выполняют одну и ту же задачу снова и снова, вместо того чтобы остановиться, сделать шаг назад и потратить время на её автоматизацию?
Распространённое заблуждение №1: автоматизация предназначена только для тестирования
Конечно, автоматизация тестирования - это здорово, но зачем останавливаться на достигнутом? В любом проекте изобилуют повторяющиеся задачи: контроль версий, компиляция, упаковывание, создание документации, развёртывание и отчетность. Для многих из этих задач скрипт окажется мощнее, чем мышь. Выполнение утомительных задач станет быстрее и надёжнее.
Распространённое заблуждение №2: у меня есть IDE, поэтому мне не нужно автоматизировать
Вы когда-нибудь использовали аргумент «Но это работает на моей машине?» в спорах с товарищами по команде? Современные IDE имеют тысячи потенциальных настроек, и практически невозможно гарантировать, что все члены команды имеют одинаковые конфигурации. Системы автоматизации сборки дадут вам контроль и повторяемость результата.
Распространённое заблуждение №3: чтобы автоматизировать это, мне нужно изучить экзотические инструменты
Вы можете пойти по длинному пути, используя полноценный консольный язык, например, bash или Power-Shell, и систему автоматизации сборки. Если же вам нужно взаимодействовать с веб-сайтами, можно использовать такие инструменты, как Selenium.
Распространённое заблуждение №4: я не могу автоматизировать эту задачу, потому что не могу работать с этим форматом файлов
Если для части вашего процесса требуются документы Word, электронные таблицы или изображения, это действительно может быть сложно автоматизировать. Но действительно ли это необходимо? Можете ли вы использовать обычный текст? CSV файлы вместо таблиц? XML/JSON? Часто небольшая подгонка процесса под автоматизацию может дать хорошие результаты и значительно снизить трудозатраты.
Распространённое заблуждение №5: у меня нет времени разбираться в этом
Вовсе не обязательно зазубрить все команды bash. Учитесь на ходу. Когда у вас есть задача, которую, по вашему мнению, можно и нужно автоматизировать, узнавайте об инструментах автоматизации ровно столько, сколько вам нужно. И делайте это на ранних этапах проекта, когда обычно легче найти время. Как только вы добьетесь успеха, вы (и ваш начальник) увидите, что имеет смысл инвестировать в автоматизацию.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Cay Horstmann
👍1
День семьсот шестидесятый. #ЧтоНовенького
Основные Запланированные Изменения в ASP.NET в .NET 6
Первая превью версия .NET 6 вышла совсем недавно. Релиз планируется в ноябре, и .NET 6 будет LTS версией .NET. В .NET 6 используетcя открытый процесс планирования, поэтому можно посмотреть список основных изменений для этой версии на сайте https://www.themesof.net. Вот некоторые из основных функций ASP.NET Core, запланированных для выпуска .NET 6.
1. Горячая перезагрузка. Возможность быстрого обновления UI и кода запущенных приложений без потери состояния приложения для более быстрой и продуктивной работы разработчика.
2. Микро API. Упрощённое создание конечных точек API с гораздо меньшим количеством кода и трудозатрат.
3. Публикация в виде одного файла. Возможность создавать небольшие автономные высокопроизводительные приложения и сервисы.
4. AoT компиляция WebAssembly. Возможность предварительной компиляции кода .NET в приложениях Blazor непосредственно в WebAssembly при публикации для значительного повышения производительности во время выполнения.
5. Обновление поддержки SPA для бесперебойной работы с новейшими современными платформами JavaScript.
6. Гибридные настольные приложения Blazor. Возможность объединить лучшее из UI мультиплатформенных приложений Blazor и .NET для создания кроссплатформенных гибридных настольных приложений.
7. Добавление поддержки HTTP/3 и QUIC.
Что нового в ASP.NET в .NET 6 Preview 1?
1. Поддержка IAsyncDisposable в MVC
Теперь вы можете реализовать
2. DynamicComponent
Это новый встроенный компонент Blazor, который можно использовать для динамической визуализации компонента, указанного в параметре Type. Параметры могут быть переданы визуализируемому компоненту с помощью словаря:
Встроенные компоненты Blazor для пользовательского ввода (
4. Команда dotnet watch теперь по умолчанию запускает dotnet watch run.
5. Аннотации обнуляемых ссылочных типов
Обнуляемые ссылочные типы появились в C#8. В ASP.NET .NET 6 большинство новых API используют эти аннотации. Подробнее об обнуляемых ссылочных типах.
Источник: https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-6-preview-1/
Основные Запланированные Изменения в ASP.NET в .NET 6
Первая превью версия .NET 6 вышла совсем недавно. Релиз планируется в ноябре, и .NET 6 будет LTS версией .NET. В .NET 6 используетcя открытый процесс планирования, поэтому можно посмотреть список основных изменений для этой версии на сайте https://www.themesof.net. Вот некоторые из основных функций ASP.NET Core, запланированных для выпуска .NET 6.
1. Горячая перезагрузка. Возможность быстрого обновления UI и кода запущенных приложений без потери состояния приложения для более быстрой и продуктивной работы разработчика.
2. Микро API. Упрощённое создание конечных точек API с гораздо меньшим количеством кода и трудозатрат.
3. Публикация в виде одного файла. Возможность создавать небольшие автономные высокопроизводительные приложения и сервисы.
4. AoT компиляция WebAssembly. Возможность предварительной компиляции кода .NET в приложениях Blazor непосредственно в WebAssembly при публикации для значительного повышения производительности во время выполнения.
5. Обновление поддержки SPA для бесперебойной работы с новейшими современными платформами JavaScript.
6. Гибридные настольные приложения Blazor. Возможность объединить лучшее из UI мультиплатформенных приложений Blazor и .NET для создания кроссплатформенных гибридных настольных приложений.
7. Добавление поддержки HTTP/3 и QUIC.
Что нового в ASP.NET в .NET 6 Preview 1?
1. Поддержка IAsyncDisposable в MVC
Теперь вы можете реализовать
IAsyncDisposable
на контроллерах, моделях страниц и компонентах представления для асинхронного удаления ресурсов.2. DynamicComponent
Это новый встроенный компонент Blazor, который можно использовать для динамической визуализации компонента, указанного в параметре Type. Параметры могут быть переданы визуализируемому компоненту с помощью словаря:
<DynamicComponent Type="@someType"3. ElementReference - ссылка на соответствующие компоненты
Parameters="@myDictionaryOfParameters" />
@code {
Type someType = ...
IDictionary<string, object> params = ...
}
Встроенные компоненты Blazor для пользовательского ввода (
InputCheckbox
, InputDate
, InputFile
, InputNumber
, InputSelect
, InputText
и InputTextArea
) теперь предоставляют удобную ссылку ElementReference
на элемент ввода, что упрощает распространённые сценарии, как, например, установка фокуса.4. Команда dotnet watch теперь по умолчанию запускает dotnet watch run.
5. Аннотации обнуляемых ссылочных типов
Обнуляемые ссылочные типы появились в C#8. В ASP.NET .NET 6 большинство новых API используют эти аннотации. Подробнее об обнуляемых ссылочных типах.
Источник: https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-6-preview-1/
День семьсот шестьдесят первый.
DotNet Boxed. Дополненные Шаблоны для .NET Core
Команда
Но шаблонов «из коробки» может быть больше. Представляю вам шаблоны dotnet-boxed. Установить это расширение можно, выполнив:
- ASP.NET Core API Boxed
- ASP.NET Core GraphQL Boxed
- ASP.NET Core Orleans Boxed
- NuGet Package Boxed
На картинке выше настройка проекта создания NuGet пакета. Как видите, можно настроить тесты, GitHub Actions, .editorconfig, информацию о лицензии, стили кодирования и многое другое. Все эти скучные настройки сделаны за вас!
Сам проект на GitHub
Источник: https://www.hanselman.com/blog/dotnet-boxed-includes-prescriptive-templates-for-net
DotNet Boxed. Дополненные Шаблоны для .NET Core
Команда
dotnet new
показывает доступные шаблонов проектов. В Visual Studio это можно выбрать в настройках «Показывать все шаблоны .NET Core в диалоговом окне Новый проект» (Show all .NET Core templates in the New Project Dialog). На основе этих шаблонов вы можете строить ваш новый проект.Но шаблонов «из коробки» может быть больше. Представляю вам шаблоны dotnet-boxed. Установить это расширение можно, выполнив:
dotnet new --install Boxed.TemplatesТеперь у вас появятся новые Boxed шаблоны:
- ASP.NET Core API Boxed
- ASP.NET Core GraphQL Boxed
- ASP.NET Core Orleans Boxed
- NuGet Package Boxed
На картинке выше настройка проекта создания NuGet пакета. Как видите, можно настроить тесты, GitHub Actions, .editorconfig, информацию о лицензии, стили кодирования и многое другое. Все эти скучные настройки сделаны за вас!
Сам проект на GitHub
Источник: https://www.hanselman.com/blog/dotnet-boxed-includes-prescriptive-templates-for-net
День семьсот шестьдесят второй. #ЗаметкиНаПолях #SQL
На третьем году существования канала я понял, что есть один язык, который я незаслуженно обходил вниманием. Восполняю упущение. Начинаю новую серию постов про SQL. Думаю, что основные основы читателям моего канала объяснять не надо (если надо, пишите в комментариях, что интересно), поэтому буду писать о «фишках». Проблема в том, что они различаются как по наличию в разных СУБД, так и по синтаксису. Поэтому буду стараться выбирать более-менее универсальные вещи и описывать концепцию, а не особенности синтаксиса.
Возвращение Данных из DML Запроса
Поначалу это может показаться странным, но возможность возвращать данные из DML - очень полезная функция.
- В запросе INSERT:
Наиболее распространённый вариант использования - получение автоматически сгенерированных значений. Например, ключей для создания записей в дочерних таблицах. Кроме того, возвращённые таким образом данные могут использоваться для аудита или логирования запросов.
- В запросе UPDATE:
Здесь выражение это используется не так часто, но всё же возможно его применение для получения значений по умолчанию, заданных в базе данных, либо для аудита запросов.
- В запросе DELETE:
Совсем редкий случай использования, в основном для целей аудита, либо, возможно, переноса данных в архивную таблицу, хотя так лучше не делать.
СУБД: Oracle, PostgreSQL, MariaDB
Выражение:
Выражение:
Пример:
- https://app.pluralsight.com/library/courses/postgresql-data-manipulation-playbook/
- https://docs.microsoft.com/en-us/sql/t-sql/queries/output-clause-transact-sql
На третьем году существования канала я понял, что есть один язык, который я незаслуженно обходил вниманием. Восполняю упущение. Начинаю новую серию постов про SQL. Думаю, что основные основы читателям моего канала объяснять не надо (если надо, пишите в комментариях, что интересно), поэтому буду писать о «фишках». Проблема в том, что они различаются как по наличию в разных СУБД, так и по синтаксису. Поэтому буду стараться выбирать более-менее универсальные вещи и описывать концепцию, а не особенности синтаксиса.
Возвращение Данных из DML Запроса
Поначалу это может показаться странным, но возможность возвращать данные из DML - очень полезная функция.
- В запросе INSERT:
Наиболее распространённый вариант использования - получение автоматически сгенерированных значений. Например, ключей для создания записей в дочерних таблицах. Кроме того, возвращённые таким образом данные могут использоваться для аудита или логирования запросов.
- В запросе UPDATE:
Здесь выражение это используется не так часто, но всё же возможно его применение для получения значений по умолчанию, заданных в базе данных, либо для аудита запросов.
- В запросе DELETE:
Совсем редкий случай использования, в основном для целей аудита, либо, возможно, переноса данных в архивную таблицу, хотя так лучше не делать.
СУБД: Oracle, PostgreSQL, MariaDB
Выражение:
RETURNING
Синтаксис:INSERT INTO | UPDATE | DELETE FROM table …Выражение
RETURNING expression1 [INTO variable1]
[, expression2 [INTO variable2]] …;
INTO variable1
позволяет вставить возвращённое значение в переменную в хранимой процедуре. Возвращать значения можно как в переменные примитивных типов, так в целую строку, используя пользовательский тип:my_row mytable%ROWTYPE;Пример:
…
RETURNING * INTO my_row;
INSERT INTO users (firstname, lastname)СУБД: MsSQL
VALUES ('Joe', 'Cool') RETURNING id;
Выражение:
OUTPUT
Синтаксис:INSERT INTO | UPDATE | DELETE FROM table …В MsSQL также можно обратиться к псевдотаблицам
OUTPUT INSERTED.expression1 [INTO variable1]
[, DELETED.expression2 [INTO variable2]] …;
INSERTED
и DELETED
. В запросе UPDATE
– DELETED
представляет заменяемое значение, INSERTED
представляет новое значение поля. В запросах INSERT
и DELETE
используется соответствующая псевдотаблица.Пример:
DELETE Sales.ShoppingCartItemИсточники:
OUTPUT DELETED.*;
- https://app.pluralsight.com/library/courses/postgresql-data-manipulation-playbook/
- https://docs.microsoft.com/en-us/sql/t-sql/queries/output-clause-transact-sql
День семьсот шестьдесят четвёртый. #BestPractices
9 «Правил» Более Чистого Кода
Следующие 9 правил относятся ко всем объектно-ориентированным языкам. Изначально они были описаны в книге Джеффа Бея «The Thoughtworks Anthology» как «Object Calisthenics» (слишком мудрёные выражения, я даже не буду пытаться их перевести, чтобы вас не путать). Правила эти, как пиратский кодекс, скорее являются рекомендациями, чем строгими законами, и, конечно, подразумевают наличие исключений. Кроме того, со многими из них можно спорить (что и призываю вас делать в комментариях).
1. Один уровень вложенности на метод
Не плодите длинные методы, в которых условные операторы содержат циклы, содержащие вложенные циклы, содержащие условные операторы. Верхний уровень кода – нулевой, код внутри цикла или условного оператора – первый уровень вложенности. Всё! Код из более высоких уровней вложенности нужно выделить в отдельный метод. Исключение – однострочные операторы,
2. Не используйте ключевое слово else
Спорное правило. Дело не в том, что нужно срочно очистить код от всех упоминаний
- используя тернарный оператор:
и т.п.
3. Оборачивайте все примитивные типы и строки
Если коротко, то суть состоит в том, чтобы не использовать примитивные типы в качестве объектов домена. А использовать вместо этого специальные типы. Например, не использовать строку или число для почтового индекса. Индекс имеет определённый формат, а поэтому должен иметь и проверку правильности введённого значения, которую лучше реализовать внутри объекта индекса.
4. Полноправные коллекции
Это правило призывает создавать отдельный класс для коллекций из непримитивных типов. Например,
5. Одна точка на строку
За исключением паттерна Строитель, LINQ или Fluent API, не увлекайтесь длинными цепочками методов или свойств. Лучше разделить их на несколько переменных. Это поможет как чтению кода, так и отладке, т.к. можно будет остановить выполнение на любой строке, чего нельзя сделать в цепочке вызовов.
6. Не используйте аббревиатуры
Не ленитесь печатать полные имена методов и переменных. Ваши коллеги или вы же из будущего скажут вам спасибо.
7. Сохраняйте небольшой размер сущностей
Тут могут быть разные советы и корпоративные стандарты на размер класса в строках или количестве методов. Но главное, не нарушайте Принцип Единственной Ответственности. Ну и насторожитесь, если класс длиннее 250 строк.
8. Не внедряйте в класс больше двух зависимостей
Это тоже довольно спорное и, наверное, слишком строгое ограничение. Например, здесь можно не учитывать логгеры или другие зависимости, требуемые для отладки. Но в общем случае, когда вы обнаруживаете, что в классе 5 и более зависимостей, то, наверное, он делает слишком много.
9. Не злоупотребляйте свойствами
Скажу честно, в оригинале это звучит как «Никаких геттеров/сеттеров/свойств», но это уже чересчур. Однако доля истины в этом правиле есть. Не позволяйте внешнему коду бездумно менять значения свойств класса. Если в классе есть счётчик, не дело внешнего кода произвольно менять его значение. Когда счётчик нужно увеличить, пусть внешний код вызывает специальный метод, который это делает.
Источник: https://youtu.be/gyrSiY4SHxI
9 «Правил» Более Чистого Кода
Следующие 9 правил относятся ко всем объектно-ориентированным языкам. Изначально они были описаны в книге Джеффа Бея «The Thoughtworks Anthology» как «Object Calisthenics» (слишком мудрёные выражения, я даже не буду пытаться их перевести, чтобы вас не путать). Правила эти, как пиратский кодекс, скорее являются рекомендациями, чем строгими законами, и, конечно, подразумевают наличие исключений. Кроме того, со многими из них можно спорить (что и призываю вас делать в комментариях).
1. Один уровень вложенности на метод
Не плодите длинные методы, в которых условные операторы содержат циклы, содержащие вложенные циклы, содержащие условные операторы. Верхний уровень кода – нулевой, код внутри цикла или условного оператора – первый уровень вложенности. Всё! Код из более высоких уровней вложенности нужно выделить в отдельный метод. Исключение – однострочные операторы,
return
, continue
и т.п. Это сильно улучшит читаемость кода.2. Не используйте ключевое слово else
Спорное правило. Дело не в том, что нужно срочно очистить код от всех упоминаний
else
. Просто на самом деле в большинстве случаев можно обойтись без него:- используя тернарный оператор:
var a = (x >= 0 ? "positive" : "negative");- задавая изначальное значение переменной перед
if
:var a = "negative";- используя return в блоке
if (x >= 0) a = "positive";
if
(тогда код после блока if
будет выполняться, как если бы он был в else
)и т.п.
3. Оборачивайте все примитивные типы и строки
Если коротко, то суть состоит в том, чтобы не использовать примитивные типы в качестве объектов домена. А использовать вместо этого специальные типы. Например, не использовать строку или число для почтового индекса. Индекс имеет определённый формат, а поэтому должен иметь и проверку правильности введённого значения, которую лучше реализовать внутри объекта индекса.
4. Полноправные коллекции
Это правило призывает создавать отдельный класс для коллекций из непримитивных типов. Например,
Dictionary<Guid, Client>
. На первый взгляд это простой словарь клиентов. Но ответьте на вопрос: позволено ли коду, использующему этот словарь, напрямую изменять его или изменять его элементы? Скорее всего нет. Таким образом эта коллекция сама должна стать полноправной сущностью домена со своими правилами обращения с элементами.5. Одна точка на строку
За исключением паттерна Строитель, LINQ или Fluent API, не увлекайтесь длинными цепочками методов или свойств. Лучше разделить их на несколько переменных. Это поможет как чтению кода, так и отладке, т.к. можно будет остановить выполнение на любой строке, чего нельзя сделать в цепочке вызовов.
6. Не используйте аббревиатуры
Не ленитесь печатать полные имена методов и переменных. Ваши коллеги или вы же из будущего скажут вам спасибо.
7. Сохраняйте небольшой размер сущностей
Тут могут быть разные советы и корпоративные стандарты на размер класса в строках или количестве методов. Но главное, не нарушайте Принцип Единственной Ответственности. Ну и насторожитесь, если класс длиннее 250 строк.
8. Не внедряйте в класс больше двух зависимостей
Это тоже довольно спорное и, наверное, слишком строгое ограничение. Например, здесь можно не учитывать логгеры или другие зависимости, требуемые для отладки. Но в общем случае, когда вы обнаруживаете, что в классе 5 и более зависимостей, то, наверное, он делает слишком много.
9. Не злоупотребляйте свойствами
Скажу честно, в оригинале это звучит как «Никаких геттеров/сеттеров/свойств», но это уже чересчур. Однако доля истины в этом правиле есть. Не позволяйте внешнему коду бездумно менять значения свойств класса. Если в классе есть счётчик, не дело внешнего кода произвольно менять его значение. Когда счётчик нужно увеличить, пусть внешний код вызывает специальный метод, который это делает.
Источник: https://youtu.be/gyrSiY4SHxI
День семьсот шестьдесят пятый. #Оффтоп
Почти год назад я писал про новую функцию языка C# - Генераторы Кода. И вот постепенно начали появляться интересные реализации, использующие их, например Mapster.
Но всё-таки до сих пор не было подробного объяснения, что это, как это всё работает, в чём плюсы и минусы, где их можно использовать и т.п. И вот недавно в открытый доступ выложили видео с последней конференции DotNext «Source Generators в действии» от Андрея Дятлова https://youtu.be/6QWZds35rGs
«В докладе вы узнаете не только о том, что скрывается за термином «Source Generators» и как его использовать, но и о том, как предоставить пользователю вашего генератора необходимую гибкость конфигурации и понятные сообщения о возникающих проблемах. Генерация кода по праву считается областью, в которой трудно понять, что пошло не так, покрыть программу тестами или взглянуть на полученный код под отладчиком. Это удерживает многих программистов от её использования, и в докладе Андрей расскажет о том, как с этим справляются генераторы. Тех, кто уже давно пользуется существующими технологиями метапрограммирования на практике, заинтересует, какие сценарии остались не поддержанными в C# 9 и сравнение новых возможностей с существующими технологиями (Fody, PostSharp, T4 и пр). Остались ли у них уникальные ниши и преимущества или же будущее за генераторами?»
Мне видео понравилось. Только имейте в виду, что требуется достаточно глубокий уровень знаний языка, чтобы более-менее понимать. Я частенько терял мысль.
Почти год назад я писал про новую функцию языка C# - Генераторы Кода. И вот постепенно начали появляться интересные реализации, использующие их, например Mapster.
Но всё-таки до сих пор не было подробного объяснения, что это, как это всё работает, в чём плюсы и минусы, где их можно использовать и т.п. И вот недавно в открытый доступ выложили видео с последней конференции DotNext «Source Generators в действии» от Андрея Дятлова https://youtu.be/6QWZds35rGs
«В докладе вы узнаете не только о том, что скрывается за термином «Source Generators» и как его использовать, но и о том, как предоставить пользователю вашего генератора необходимую гибкость конфигурации и понятные сообщения о возникающих проблемах. Генерация кода по праву считается областью, в которой трудно понять, что пошло не так, покрыть программу тестами или взглянуть на полученный код под отладчиком. Это удерживает многих программистов от её использования, и в докладе Андрей расскажет о том, как с этим справляются генераторы. Тех, кто уже давно пользуется существующими технологиями метапрограммирования на практике, заинтересует, какие сценарии остались не поддержанными в C# 9 и сравнение новых возможностей с существующими технологиями (Fody, PostSharp, T4 и пр). Остались ли у них уникальные ниши и преимущества или же будущее за генераторами?»
Мне видео понравилось. Только имейте в виду, что требуется достаточно глубокий уровень знаний языка, чтобы более-менее понимать. Я частенько терял мысль.