YouTube решил ускорить процесс с публикацией видео 😆
Welcome 👉 https://youtu.be/zcCPBtvHBFk

🎄Вы уже нарядили ёлку?

Если нет, то скорее ловите 30-ти секундный гайд

https://youtu.be/PIMVMkU-9rw

#codaza_спрашивает

Как думаете, с кодом всё ок? 🤔

Это вам, чтобы после НГ немного в себя прийти 😉

#codaza_отвечает

С кодом из предыдущего поста не всё ок. Ему не хватает асинхронности. Если не ожидать результат выполнения метода GetStringAsync() у объекта client (строка 5), то его освобождение из памяти произойдет раньше, чем выполнится метод, так как мы используем using (строка 3). Поэтому, перед dispose объекта client, нам необходимо дождаться результата выполнения метода, а не просто возвращать task.

Подписчик Aidar дал точный ответ в комментариях 👍

Всем привет! 👻

Если всё еще путаетесь c Left Join в LINQ, то ловите гайд, который поможет распутаться раз и навсегда 😀

Приятного просмотра!

https://youtu.be/nObBd7cqpTQ

#codaza_спрашивает

Всех с пятницей! 🥤

Пока мчитесь до паба, у меня небольшой кусочек кода для вас. Код вроде рабочий, но.. может еще что-нибудь эдакого добавить\удалить\изменить\оптимизировать? Или так в продакшн пульнём?

Жду идеи в комментариях 😊

Как проходят ваши выходные? Надеюсь, вы проводите их классно и не за компом 😉

Я не стал рисковать и пулять код из предыдущего поста в продакшн, так как DevOps'ы точно нашли бы меня и прижали к стенке, а я хотел спокойно отдохнуть в эти выходные. Они могли это сделать из-за того, что микросервис мог начать потреблять больше памяти, чем планировалось. Если вы присмотритесь к коду, то в самом начале (на 5-ой строке), мы смотрим на готовность коллекции к процессингу и, если она не готова, то возвращаем 0 обработанных записей. Из-за этого, нам совершенно не нужна аллокация памяти под Task, так как мы и не планировали ожидать результат выполнения метода SaveAsync() (строка 6). В таких случаях применяют ValueTask, что позволяет избежать избыточных аллокаций. Если наш hot path (горячий путь) будет чаще идти туда, где коллекция не готова к процессингу (строка 4), то сокращение потребляемой память может порадовать ваших DevOps'ов до умопомрачения. Для высоконагруженных систем это будет очень ощутимой оптимизацией.

Хорошего начала рабочей недели 👋

#codaza_спрашивает

"Пятница, она уже не работница, но еще и не отпускница, — одним словом, ожидательница.” (с) Джон Стейнбек

Всем привет! 👋

Я уже практически убежал катать на склон, как меня попросили по-быстрому провести код-ревью junior-разработчика. В целом, всё норм, но с этим кусочком кода что-то не так. Или всё так... 🤯

Будем апрувить? 🤔

Очень круто получилось с последним вопросом! Сейчас расскажу 🙂

Я хотел сделать основной фокус на отложенном выполнении (Deferred Execution) запросов в LINQ. Что значит “отложенное выполнение”? А это значит, что LINQ-запрос будет исполнен только там, где будет востребован непосредственный результат его выполнения. На 3-ей строке мы не получаем непосредственный результат выполнения, так как переменная result имеет тип IQueryable<Trades>. Проще говоря, мы только определили некоторый запрос, результат выполнения которого, нам потребуется в будущем.
Где же мы получаем результат? А получаем мы его на строках 8, 9 и 10. То есть, мы обращаемся к базе данных аж 3 раза. Если вы не делаете лабу для универа, то это непозволительная роскошь для профессиональной разработки. Как избежать трехкратного обращения к базе данных? Очень просто, нужно сразу запросить результат путём вызова метода ToList(). Таким образом, на 8, 9 и 10 строках, мы будем оперировать с данными, которые будут находиться в оперативной памяти и за ними не нужно “ходить” в базу данных.

Подписчик Руслан Петряев дал точный ответ в комментариях 👍

Кроме того, Руслан увидел еще одну проблему, которая была вызвана запросом приведения к List. Посмотрите на код, а нужен ли нам вообще этот List? Ведь нам совершенно не нужны данные из этого списка. Всё что нам нужно – это общее число отфильтрованных записей, минимальная и максимальная цены. Тогда зачем мы держим эти данные в оперативной памяти? Всё что нам нужно по логике метода:

1. Обратиться к базе данных.
2. Забрать Count, MinPrice и MaxPrice для отфильтрованных записей.
3. Сохранить данные в объект TradeData и вернуть его.

Это можно сделать так:

TradeData result = DbContext.Set<Trades>
.Where(t => t.Status == TradeStatuses.Completed)
.GroupBy(t => t.Status == TradeStatuses.Completed)
.Select(t =>
new TradeData
{
PricesCount = t.Count(),
PriceMin = t.Min(r => r.Price),
PriceMax = t.Max(r => r.Price)
}).FirstOrDefault();

Супер! От вопроса получилась двойная польза для всех!

Всем хорошего вечера! 👋

#капитану_на_заметку

Очень часто, если коллекция не содержит искомых элементов, разработчик принимает решение вернуть null. Такое может быть, когда возвращается пустая выборка из БД, коллекция не может быть сгенерирована ввиду ошибочных условий и т. д. Подобное решение приводит к избыточным проверкам во внешнем коде, а также повышает вероятность появления исключения NullReferenceException. Хорошим тоном является возврат пустых коллекций. Старайтесь не возвращать null, когда ваши коллекции не содержат элементов ✅

Всем привет! 👻

Продолжаем разбираться с LINQ и сегодня на повестке: группировка данных с помощью операции GroupBy. Если вы еще никогда не делали группировку данных, то этот гайд будет для вас красной ковровой дорожкой 🪄

Приятного просмотра! 💙

https://youtu.be/G7ytatcF7GY

#codaza_спрашивает

Всем привет! 👋

Сижу я сегодня за компом, спокойно себе отмечаю день пельменей (сегодня день пельменей, если вы не знали) и мне звонит мой хороший знакомый Junior-разработчик Леонид. Лёня, рыдая в трубку, говорит: Уже который раз отклоняют merge в master с пометкой: 'Просадка в производительности'. Я посмотрел код, Лёня там чё-то шифрует-перешифрует.. наверное, ему так надо. Я ничего не понял, сказал что у меня в группе codaza отличные ребята и девушки, они точно разберутся, где у тебя там просадка в производительности.

Поможем Леониду? Или спасение утопающих — дело рук самих утопающих?

Ура! 🎉

Леонид был спасён уже через 5 минут после публикации поста в пятницу. Всё благодаря опытным подписчикам #codaza, которые не дали джуну утонуть в неведомых дебрях асинхронного кода C#. Лёне одобрили его первый merge в master, от чего он начал праздновать День Пельменей с невиданным размахом!

В чём же была проблема? Почему злой тим лид отмахивался комментарием “Просадка в производительности” и отклонял merge? Всё дело в 3-ей и 5-ой строках исходного кода. Что делает Леонид:

1. Запускает асинхронное выполнение задачи GroupDataChunkAsync().
2. Ожидает окончания её выполнения.
3. Запускает асинхронное выполнение задачи CalculateCypherPhraseAsync().
4. Ожидает окончания её выполнения.

Все эти 4 действия выполняются последовательно. Но Лёня не задаётся вопросом, а нужно ли выполнять эти действия последовательно? Может быть, они могут быть выполнены параллельно? И, как вы уже догадались, эти действия могут быть выполнены параллельно. Мы можем вызвать асинхронное выполнение методов GroupDataChunkAsync() и CalculateCypherPhraseAsync() независимо, так как результат их выполнения потребуется только на 7-ой строке. То есть, следовало сделать так:

1. Запустить асинхронное выполнение задачи GroupDataChunkAsync().
2. Запустить асинхронное выполнение задачи CalculateCypherPhraseAsync().
3. Дождаться результата выполнения обеих задач и продолжить логику метода ProcessItemsAsync().

Один из вариантов, который предложил подписчик Eugene Potashkin, это воспользоваться статическим методом WhenAll, который реализован в классе Task. То есть, код будет выглядеть так:

var groupTask = GroupDataChunksAsync(limit);
var phraseTask = CalculateCypherPhraseAsync(limit);
await Task.WhenAll(groupTask, phraseTask);
bool check = CheckEncryption(groupTask.Result, phraseTask.Result, limit);

Но более лаконичный вариант для данной конкретной реализации, предложил подписчик Руслан Петряев, где мы ожидаем результата выполнения задач непосредственно в вызове метода CheckEncryption(). Именно такую реализацию вы можете видеть на картинке выше. Так или иначе, оба варианты равнозначны и являются верными.

Всем хорошего вечера! ☕️

#капитану_на_заметку

Всем привет!

Вы когда-нибудь заглядывали в System.Collections.Concurrent? Если вам доводилось писать многопоточный код, скорее всего вы там были неоднократно. Как только мне нужно писать многопоточный код, я на 99% уверен, что найду там структуру данных, которая решит большинство моих технических вопросов. Но есть коллекция, которая была разработана для очень специфических случаев - ConcurrentBag<T>.

ConcurrentBag<T> - это потокобезопасная реализация коллекции, оптимизированная для сценариев, в которых один и тот же поток будет создавать и потреблять данные, хранящиеся в ней.

Не рекомендуется использовать её без предварительного бенчмаркинга (замеров производительности). Если вы на 100% не уверены, что вам нужен именно ConcurrentBag<T>, отдайте предпочтение ConcurrentQueue<T> ✅

#капитану_на_заметку

Всем привет!

Вы уже знаете про очень полезный атрибут [DebuggerDisplay], который находится в пространстве имён System.Diagnostics? Если нет, то только что ваш дебаггинг вышел на уровень комфорт-класса 😎. С помощью этого атрибута мы можем указать способ отображения экземпляра класса во всплывающем окне дебаггера переменной, которое появляется при наведении курсора мыши.

+1 к премудростям дебага ✅

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

#капитану_на_заметку

Всем привет!

Сегодня понедельник, а значит, нужно сделать еще один шаг к чистому коду. Вы слышали про конструкцию "catch - when" в C#?

Это ещё одна суперспособность на уровне языка, которая делает программирование на C# по-настоящему чем-то особенным. Фишка в том, что мы можем фильтровать одно и то же исключение в блоке catch написав логическое выражение после оператора when. Это позволит ловить исключения одного и того же типа несколько раз, но фильтровать их по разным условиям. Данный подход сделает обработку исключений более структурной и системной. Мне нравится применять этот способ при обработке исключений, где логика обработки выходит за рамки определения типа исключения.

+1 к чистому коду ✅

Всем спокойной недели!

#codaza_спрашивает

Единственная причина для существования времени — чтобы все не случилось одновременно.

Альберт Эйнштейн

Всем привет!

Вчера не code review мне попался этот фрагмент кода. Метод проходит все модульные тесты. Я думаю, этот код сможет работать в production. Но... Кажется, он может тратить меньше времени... 🕙

Что думаете?

Любые улучшения только приветствуются 🙂