
История эта началась в феврале 2021-го года. Когда мы привычно выставили счет за наше ПО и получили звонок с бухгалтерии клиента с вопросом "а НДС гдеЧитать полностью »

История эта началась в феврале 2021-го года. Когда мы привычно выставили счет за наше ПО и получили звонок с бухгалтерии клиента с вопросом "а НДС гдеЧитать полностью »

Конец декабря, многие подводят свои итоги, а мы решили оглянуться и посмотреть, что хорошего (и не очень) случилось в мире .NET-разработки за этот год, и спросили об этом наших разработчиков.
Из хорошего называли появление рекордов в С# 9Читать полностью »

Меня раздражает традиционная архитектура бизнес-приложений — об этом я уже говорил. Я критикую — я предлагаю. Сейчас я расскажу, к чему меня привели поиски решений для проблем из предыдущей статьи.
Мне нравится перебирать архитектурные концепции. Всю жизнь я пытаюсь найти в области архитектуры и дизайна ПО что-то работающее и в то же время простое. Не требующее разрыва мозга для понимания и кардинальной смены парадигмы. Идей накопилось порядочно и я решил объединить лучшие из них в своём фреймворке — Reinforced.Tecture. Разработка таких штук даёт гигантское количество пищи для размышлений, я хочу ими поделиться.
Тексты про такие технические вещи обычно до ужаса нудные. Я честно постарался не нудить, поэтому мой текст получился слегка агрессивным. Если вам с этим норм и интересно почитать про архитектуры .NET-приложений — заходите.

Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы — быдлокод и беспорядок. Месиво из сервисов, UoW, DTO-шек, классов-хелперов. В иных местах и прямой доступ в базу данных руками, логика в статических классах, километровые портянки конфигурации IoC.
Когда я был молодым и резвым мидлом — я тоже так писал. Потом бил кулаком в стену с криками: "Хватит! В следующий раз сделаю по-другому". Следующий раз действительно начинался "по-другому" — с холодной головой и строгим подходом к архитектуре — а на выходе все равно получалась та же субстанция, лучше на пару миллиметров.
Однако, эволюция — беспощадная штука: моя последняя система показалась мне более-менее близкой к идеалу. Сложность не сильно росла, скорость разработки не падала довольно долго, в систему худо-бедно въезжают новые сотрудники. Эти результаты я взял за основу, улучшил и теперь анонсирую вам свою новую разработку: Reinforced.Tecture.

Недавно мне на глаза попалась одна статья на Хабре. В ней сравниваются C# и JavaScript. На мой взгляд, сравнивать их — всё равно что сравнивать луну и солнце, которые, если верить классику, не враждуют на небе. Эта статья напомнила мне о другой публикации. В ней речь идёт о сценариях неожиданного и неочевидного поведения JavaScript, а C# не упоминается от слова совсем, но живое любопытство сподвигло меня попытаться повторить подобное поведение на другом языке.
Читать полностью »

Представлять Джона Скита особо не требуется: самый известный пользователь Stack Overflow (с кармой более миллиона), автор книги «C# in Depth», создатель библиотеки Noda Time и вообще человек, про которого шутят «даже Джон Скит не смог бы распарсить HTML регулярками».
В 2017-м Джон выступил у нас на DotNext. Тогда мы опубликовали на Хабре большое интервью с ним о состоянии дел в .NET и C#, где прозвучали громкие слова вроде «потеснит Java», и в комментариях возникли оживлённые дискуссии.
За прошедшие три года много оперативки утекло. Поэтому теперь, когда Джон выступит с двумя докладами на онлайновом DotNext, мы решили задать ему схожие вопросы, чтобы посмотреть, как изменились ответы.
А в качестве бонуса добавили в пост ещё один небольшой разговор со Скитом из онлайн-трансляции DotNext 2017 Piter: тогда его увидели только зрители трансляции, а теперь хабрачитатели получают и видео, и текстовую расшифровку.
Читать полностью »
За несколько недель до 14 февраля системе Dodo IS немного поплохело под нагрузкой. Одной из причин стало то, что в backend’ах мобильного приложения и сайта не совсем корректно работали политики поверх HttpClient’а (Retry, Circuit Breaker, Timeout). В этой статье я хочу поделиться с вами потенциальными проблемами, которые могут возникнуть при неправильном использовании таких политик.

Инлайнинг — одна из самых важных оптимизаций в компиляторах. Она не только убирает оверхед от вызова, но и открывает много возможностей для других оптимизаций, например, constant folding, dead code elimination и т.д. Более того, иногда инлайнинг приводит к уменьшению размера вызывающей ф-ции! Я опросил несколько человек на предмет знают ли они по каким правилам инлайнятся ф-ции в C# и большинство ответили, что JIT смотрит на размер IL кода и инлайнит только маленькие ф-ции размером, скажем, до 32 байт. Поэтому я решил написать этот пост, чтобы раскрыть детали реализации при помощи вот такого примера, который покажет сразу несколько эвристик в деле:
В .Net Core есть встроенный механизм Model Binding, позволяющий не просто принимать входные параметры в контроллерах, а получать сразу объекты с заполненными полями. Это позволяет встроить в такой объект все нужные проверки с помощью Model Validation.
Вот только данные, нужные для работы API, приходят нам не только из Query или Body. Какие-то данные нужно получить из Headers (в моем случае там был json в base64), какие-то — из внешних сервисов или ActionRoute, если вы используете REST. Для получения данных оттуда можно использовать свой Binding. Правда и тут есть проблема: если вы решили не нарушать инкапсуляцию и инициализировать модель через конструктор, то придется пошаманить.
Для себя и для будущих поколений я решил написать что-то вроде инструкции по использованию Binding и шаманство с ним.
Читать полностью »