C# *

Иногда приходится разбираться, почему .NET приложение работает "плохо". Не так, как мы ожидали. Тупит, медленно работает, зависает, запросы «не исполняются», утекает память или потребляется слишком много CPU.

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

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

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

Как вы наверняка знаете, LINQ (Language Integrated Query) - это очень мощный и гибкий язык, встроенный в C# и существует он начиная аж с .NET Framework 3.5. Однако, несмотря на свои возможности, синтаксис запросов часто игнорируется в пользу более популярного аналога - синтаксиса методов. Хотя синтаксис методов действительно мощный, в этой статье я на практических примерах покажу преимущества query-синтаксиса и его полезность для опытных разработчиков на C#.

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

Привет, хабражитель! Ты когда-нибудь задумывался, почему C# такой особенный по сравнению с другими языками программирования? Если нет (и если да), то приготовься, потому что сейчас мы погрузимся в различия между C# и самыми популярными его языковыми "братьями": C++, Java, Python и JavaScript. Надеюсь, что это сравнение лучше поможет лучше понять роль и место C#, а также то, что это лучший язык в мире (шучу). Ладно, вперед к сравнениям!

В этой заметке разберём уязвимость CVE-2020-36620 и посмотрим, как NuGet-пакет для конвертации string в enum может сделать C# приложение уязвимым к DoS-атакам.

Привет, меня зовут Евгений Думчев, я разработчик в DD Planet. Сегодня хочу поделиться опытом подключения платежного шлюза Сбера, чем мы занимались в рамках одного из проектов. Кажется, это будет полезная история, ведь в нынешние непростые времена многие из нас задумываются о том, чтобы открыть свой «маленький свечной заводик» – какой-нибудь небольшой бизнес на черный день. Тортики там печь, платы паять, в общем, что-нибудь, что бы обеспечило дополнительный доход. Раньше для коммерции подобных сайд-проектов не требовалось ничего, кроме условного Пейпала (к тому же он расширял географию продаж). А теперь волей-неволей приходится задумываться об отечественных решениях для проведения оплат.

Платежный шлюз – как раз такое решение. И оно на самом деле очень простое, любой посетитель Хабра, скорее всего, сможет его развернуть, достаточно хотя бы примерно представлять устройство REST API. В этой статье я расскажу, как подключить и настроить шлюз от Сбера – но в принципе эта инструкция пригодится со шлюзом от любого банка.

Меня зовут Миша, и я старший разработчик группы «Отгрузка и планирование логистики продавца» в Ozon.

C# можно встретить везде: в огромных монолитах, в десктопных приложениях, в мобильной разработке, даже в геймдеве, не говоря уже о самых передовых разработках на  микросервисной архитектуре. У нас в Ozon C# — один из основных языков, даже есть свои курсы Route 256 для Net-разработчиков, где мы в течение двух месяцев делимся опытом разработки микросервисов в лидирующем e-com, и, кстати, я там преподаю. 

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

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

Как-то раз была поставлена задача ускорить работу с Dictionary<int,?>, где ключом всегда выступал int, а значением - структура. Имеющаяся скорость не устраивала. Более того, очень бы хотелось иметь возможность получать ссылку (ref) на значение в Dictionary, чтобы можно было изменять содержимое извне. В настоящий момент полнофункциональный словарь из dotnet такого поведения не поддерживает.

В статье, как и в предыдущей, речь пойдёт о наносекундах и экономии байтиков. Уверен, что 99% программистов этого не нужно, а подобные эксперименты без изучения environment'a будут даже опасны. Однако, если ваш профиль high-load или геймдев, данная информация может быть востребована.

Я много работаю с массивами, поэтому хотел бы освежить тему того, как наиболее быстро по нему перемещаться в C#. Речь пойдёт об экономии наносекунд и оптимизации на уровне IL-кода. Кажется, что в 99% случаев вам это знать не нужно и задумываться об этом не стоит. Тем не менее, для горячих сценариев или если вы из high-load или геймдева, вам это может пригодиться.

В процессе написания source generators для наших внутренних нужд я столкнулся с тем, что на большой кодовой базе обычные генераторы работают, скажем так, небыстро, существенно влияя на производительность IntelliSense в Visual Studio (который и так не то чтобы порхает как бабочка в таких условиях). Наткнувшись на описание более современного API — incremental generators, я обрадовался и обновил наши генераторы, чтобы они его реализовывали, однако ожидаемого прироста скорости не увидел (он был, но незначительный).

Наверняка вы вызывали методы в C#. И казалось бы, что тут может быть интересного. Но тут есть о чем поговорить, есть что интересного рассказать.

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

В эпоху невероятной популярности ChatGPT и OpentAI все кинулись играть с их инструментами и использовать API в своих продуктах. Я был в общих рядах и сделал продукт для тех, кому затруднительно воспользоваться официальным сайтом ChatGPT. Но в этой статье речь пойдет не о восхитительных продуктах MS, а о создании интерфейса с котиками на основе этого продукта.

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

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

Одна из многословных конструкций .NET связана с деталями реализации асинхронности и обросла кучей мифов. Про неё спрашивают на собеседованиях, код-ревью, делают обязательной, добавляя в правила линтера. Это .ConfigureAwait(false), сопровождающий каждый await в коде.

В этой статье я расскажу, зачем нужен ConfigureAwait(false) и как обойтись без него.

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

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

Хабр, привет!

Сегодня я предлагаю совершить небольшое исследование на тему "как нам обустроить интеграционное тестирование и встроить его в сиайку".
Написать эту заметку меня сподвигла дискуссия, случившаяся недавно на работе. Инициативная группа "четырехглазых в свитерах" пыталась родить меры по улучшению качества нашего изделия и снижения трудозатрат QA-инженеров на проведение рутинного регрессионного тестирования. Как это часто бывает, разработчики если и писали тесты, то только модульные, оставляя интеграционные и end-to-end для тестировщиков. Для выполнения интеграционного тестирования QA-инженеры используют "тестовый стенд", на котором развернуты компоненты приложения (еще около 40, с позволения сказать, "микросервисов"), сервер базы данных (с не всегда ясным наполнением этой самой базы), брокер сообщений (RabbitMQ) и все остальное, что может потребоваться для запуска приложения. На этот тестовый стенд натравливаются автотесты, которые шатают приложение за все доступные снаружи конечные точки, таблицы БД и элементы UI пытаясь проверить максимальное количество тестовых сценариев в границах (и за ними!) возможных входных данных.

Мне последнее время приходится заниматься интерфейсом приложения для анализа данных, визуальным представлением данных на разных слоях анализа, а также навигацией по слоям и по данным. Соответственно, пришлось разбираться c новомодным WPF, который продвигает концепцию реализующую возможность параллельной (независимой) работы дизайнеров, занимающихся внешним видом приложения и разработчиков, реализующих поведение приложения. Дизайнер, конечно, из меня не очень (мягко говоря), а вот с реализованной концепцией программирования внешнего вида элементов управления в приложениях, мне, кажется, удалось разобраться. Собственно, вот этим пониманием некоторых аспектов концепции я и хочу поделиться, в том числе для того, чтобы расширить это понимание по результатам критики и/или обсуждения.

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