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

«Я не могу понять одного, почему библиотека или ее автор решает за меня как ее использовать? Если есть инструмент для маппинга, то его домен это маппинг и основная задача - предоставить апи для решения задач маппинга. Вместо этого создатели автомаппера гнут свою линию, причем доходит до смешного: в одном ответе на стековерфлоу они советуют юзать какой-то новый метод, а уже в другом говорят что это плохая идея, а метод мы удалили навсегда. И эти парни не знают слов deprecated, obsolete и тп. Мы художники - мы так видим, а вы переписывайте как хотите ваши маппинги - напрасная трата человеко-часов. Мало того, они как бы дают вам возможность вернуть часть функционала, если очень надо, но код примеров еще надо найти в каком-то из обсуждений и самое главное - этот код бажный, какое-то издевательство. Этого достаточно, чтобы начать обходить эту либу стороной, неизвестно что они решат удалить или запретить завтра, а переписывать сотни мапингов нет никакого желания.

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

async void это костыль .NET’а

Многие .NET разработчики знают, что с 5й версии C# в языке появились инструменты для реализации концепции асинхронного программирования.
Ключевые слова async/await, типы данных Task и Task<T>, библиотека TPL.

Однако, мало кто знает почему два слова, async void, можно написать друг за другом, а компилятор не отругается, в отличие от бородатого сеньора-помидора на код ревью.

Казалось бы, всё просто: если метод возвращает что-то типа T, то его асинхронный вариант вернёт Task<T>.
Если не возвращается ничего, то есть стоит void, то асинхронный вариант имеет тип Task.

Однако, при внедрении киллер фичи, разрабам сишарпа было важно не поломать обратную совместимость и консистентность парадигм. Да-да, C# - это мультипарадигмальный язык программирования. И помимо всего прочего там на уровне языка встроена событийная система.

То есть, можно кидать события, создавать обработчики, регистрировать их, реализовать паттерн Publisher-Subscriber и многое другое. Но, для событийно-ориентированного программирования странно, когда обработчик имеет возвращаемый тип.

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

Почему async void нельзя применять в реализации типовых задач асинхронного программирования?
У него совершенно другая семантика.

1️⃣ Исключения, выброшенные в такой среде не отлавливаются через catch. Они не оборачиваются в задачу, а вызываются прямо на контексте синхронизации. Отследить такое можно только с помощью глобальных «ловцов всего», что есть прямая дорога к неподдерживаемости.

2️⃣ Методы с такой сигнатурой нельзя компоновать с другими асинхронными вызовами через общий API. Цепочки задач, коллбеки при продолжении, общее ожидание - всё это недоступно.

3️⃣ Такой код сложно тестировать и поддерживать. Например, MS Test вовсе работает только с асинхронным кодом, возвращающим Task и Task<T>. Для каждого конкретного случая придётся писать свой собственный контекст синхронизации. Решение не простое и далеко не оптимальное.

Ну а больше деталей - на странице MSDN

Не знаю подводят ли другие блоггеры итоги года, но для меня 2022 однозначно был хорошим.

Я ротировался на senior должность, оказался в гостях у Антона Назарова, выпустил немало успешных статей на Хабре и, конечно, завёл этот замечательный канал!

Уверен, дальше - больше 🚀⚡️💪
Всех с наступающим🎄
Счастливого Нового Года 🥳

Год начинается с хороших новостей 😊

Как объяснить обывателю что такое программирование?

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

Всё это далеко от истины.
Начиная от бесполезности и до притворства в работе.

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

Мне кажется, аналогия очевидна. Программисты - инженеры XXI века.
Только механизмы и детали - цифровые.
Разрабатываемые системы нельзя потрогать, только представить в голове или выразить с помощью некоторой нотации.

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

Do I need to run tests before push?

На текущем проекте мы используем Kafka. Так вышло, что я - MacBook enjoyer и пишу код на m1 машине.

Соответственно, интеграционные тесты, задействующие Kafka тупо не запускаются.
И какое-то время назад у меня в голове возник вопрос: «а должно ли это вообще меня волновать?»

Ладно, Kafka. Но в большом коммерческом проекте есть ещё много других вещей, которые нужно было бы поднимать на своей машине, просто чтобы запустить приложение:

▪️Эмулятор внешних систем (mock интеграций);

▪️Базы данных;

▪️Кэш;

▪️Gateway микросервисов;

И многое другое…

Зачем мне засорять компьютер, когда уже есть облако с окружением, где крутятся пайплайны, триггернутые коммитом? CI/CD - это автоматизация всей вот этой рутины. И я воспользуюсь этим технологическим достижением, чтобы упростить себе жизнь.

Смысл прогонять тесты на машине, если репорт будет читаться из пайплайна в гитлабе?

marker interface

Для чего их вообще используют?
Допустим, в коде используется некий объект, который реализует указанный интерфейс. Тогда, появляется возможность проверить реализуется ли он и скорректировать на основе этого обработку объекта.

Также, маркерный интерфейс может быть необходимым злом при отсутствии поддержки в языке discriminated union types.
К сожалению, в объектно-ориентированных языках вроде C# объявить тип, который будет чем-то конкретным из указанного набора, невозможно.

Поэтому, приходится прибегать к таким уловкам.

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

Объект сам по себе теперь обладает неявным контролем над возможностями внешнего использования. Более того, он знает окружение, в котором будет использоваться.

Применение маркерного интерфейса подразумевает, что где-то будет находится проверка на этот маркер. Это противоречит идее инкапсуляции, потому что у объекта появляется знание о реализации той части системы, которая находится совершенно вне зоны его «полномочий».

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

Привет, я - компилятор!

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

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

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

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

Да. Всё это за доли секунд. И только потому что человек знает, что я могу, а он - нет.

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

Подготовка к новой статье на Хабр идёт полным ходом!

А вы знали, что на сайте Microsoft Developer Blogs есть полноценный блог о Java на китайском?

Microsoft, что за дела???

Swagger и полиморфные контракты в .NET 7

Наконец, мой лонгрид о внедрении полиморфных контрактов как формата данных межсервисного взаимодействия увидел свет.

Читаем и ставим плюсы!

#хабр

Пока я писал статью про .NET 7

Microsoft успели выпустить первый превью .NET 8.
Новая итерация платформы в первую очередь интересна тем, что будет LTS. Поэтому её и ждут.

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

Ну а если вы хотите узнать больше про перфоманс в .NET или узнать как новые оптимизации влияют на генерируемый IL, то добро пожаловать на канал моего хорошего знакомого @csharp_gepard

Он пишет об этом давно, интересно, и самое главное понятно.

Ссылка на новость про превью:
https://devblogs.microsoft.com/dotnet/announcing-dotnet-8-preview-1/

Убийца Hadoop здесь

На этой неделе произошло значимое событие для open source, по крайней мере, России.

Неожиданно, но в открытый доступ вышел десятилетний труд Яндекса - YTsaurus, BigData система для хранения и обработки данных.
Да, и от Яндекса временами могут быть хорошие новости)

Этот распределённый монстр может масштабироваться на миллионы cpu и экзабайты данных. Теперь весь этот богатый функционал в ваших руках:

▪️обширный модуль MapReduce;

▪️распределённые ACID транзакции;

▪️надёжная изоляция вычислительных ресурсов;

и многое другое.

Сделать вклад или просто поддержать проект можно вот в этом репозитории GitHub.

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

…

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

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

Нам всегда будут нужны люди, способные заполнить брешь между задачей реального мира, которую нужно решить, и компьютером, предназначенным для решения этой задачи. Эти люди будут называться программистами независимо от того, манипулируют они машинными регистрами на ассемблере или диалоговыми окнами в Microsoft Visual Basic. Пока у нас есть компьютеры, нам будут нужны люди, которые говорят компьютерам, чтó делать, и эта деятельность будет называться программированием.

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

Стив Макконнелл, 1993 год.

Совершенный код, глава 30, раздел 30.6

Завезли превью версию C# 12

Только недавно говорили о том, что пока у Microsoft мало чего есть, что можно было бы показать.
Впрочем, так и оказалось)

Новых фич всего три:

1️⃣ Первичные конструкторы для class и struct

2️⃣ Полноценный type alias

3️⃣ Значения по умолчанию для параметров в лямбдах

В целом ничего groundbreaking 🤷‍♂️

Как изменить таймаут для конкретного запроса в HttpClient?

Одной из лучших практик по работе с HttpClient в C# считается переиспользование одного экземпляра клиента для множества запросов. Как минимум во избежание port exhaustion.

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

Проблема в том, что HttpClient.Timeout устанавливается единожды, во время создания клиента. И несмотря на наличие public set'тера, это значение не может быть изменено впоследствии. Любые попытки пресекаются выбрасыванием InvalidOperationException.

Но я бы не писал этот пост, если бы не существовало решения проблемы. А решение довольно простое:

TimeSpan timeout = GetMyTimeout();
using (var tokenSource = new CancellationTokenSource(timeout))
{
 var response = await httpClient.GetAsync(uri, tokenSource.Token);
 HandleResponse(response);
}

Такое решение можно не только использовать "в лоб", но и обернуть в пайплайн из DelegatingHandler'ов. Для того чтобы оно работало, потребуется убедиться в двух вещах:

1️⃣ Пользовательский таймаут меньше того, что установлен в HttpClient.Timeout

2️⃣ Пользовательский таймаут валиден. Проще говоря, время ожидания больше 0 секунд.

.NET не идеален

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

Это влияет и на пользовательский опыт, и на финансовые показатели продукта, его конкурентоспособность, репутацию.

Но даже проверенные временем платформы разработки не могут гарантировать ожидаемого поведения на 100% при соблюдении всех правил.

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

Также, автор доклада ведёт канал @epeshkblog, где можно прочитать про готовящееся им решение проблемы и множество других интересных аспектов платформы, о которых вы даже не догадывались.