Всем привет!

Уже совсем скоро ожидается выход .NET 6, а вместе с ним и C# 10. В связи с этим, на канале выйдет видео, посвященное новым возможностям в C# 10. Ролик выйдет на канале завтра (16 октября 2021 г.), в 11:00 (GMT+3). Не пропустите, будет интересно!

Всем хорошей пятницы! Отдыхайте аккуратно! 🙂🥤

Всем привет!

Завтра (30 октября, в 11:00 по Москве) поговорим о паттернах проектирования. Я подготовил для вас один из моих любимых паттернов.
Как думаете, какой паттерн мы рассмотрим?
Кстати, предлагайте паттерны о которых хотели бы поговорить именно вы. Паттерн с наибольшим количеством лайков точно попадёт на обзор 😊

Хорошей вам пятницы и до завтра! 🙂🥤

Кто проживает на дне океана? 🐟

Всем привет!

На дне океана, конечно, проживает Спанч Боб Сквэр Пэнтс, а завтра нам будет помогать его сосед - Сквидвард. Еще у Сквидварда будет вантуз (без него не получится). Мы обсудим еще один популярный паттерн проектирования, который набрал больше всего комментариев и лайков на YouTube и Telegram каналах #codaza.

Всем позитивной пятницы и до завтра!

30% - ровно такой процент кандидатов не отвечает на один из ключевых вопросов касающихся разработки на ASP.NET. Данная цифра взята из моего личного опыта проведения технических интервью. Как правило, кандидаты дают неполный ответ, неправильный ответ или не отвечают вовсе (и такое бывает).

Что это за вопрос? Узнаем завтра 😉 На повестке ASP.NET!

Нескучной пятницы и до завтра! 🥤

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, когда ваши коллекции не содержат элементов ✅