Возврат ссылки на структуру из метода, объявленную в этом самом методе, является одним из самых классических примеров "висячих ссылок". Но что если возвращается не ссылка, а структура, содержащая ссылку? И не явно, а через вызов другого метода? Как понять, где у нас явный "провис ссылки", а где нормальный код? Звучит как какая то "дичь", но подобный кейс - вполне реальная боль для автором языков программирования.

Давайте посмотрим на примере Rust и C# как авторы решают эту неоднозначную проблему.

Хочу поделиться своим опытом выхода из выгорания, возможно кому либо будет интересно. Надеюсь у меня получится помочь Вам решить для себя проблемы "я ж прогать начал чтобы игры делать, а не инвестиционные платформы", "время разрабов-одиночек прошло", "ничего нового не придумать".

Поздравляем наших любимых слушателей с Новым Годом! Это был очень интересный год для нас, DotNet разработчиков, полный приятных (например YARP) неожиданностей, новых возможностей и ... Blazor все еще не убил React.

В честь праздника, мы хотим Вам сделать небольшой подарок, ТОП 5 самых недооцененных выпусков за 2021 год.

Меня очень возмутил вчерашний пост Что будет с C# и причём здесь Страуструп? Конечно, каждый имеет право на мнение, но автор использует множество манипулятивных техник, таким образом негативно влияя на мнение молодых читателей. Да и сам текст является маркетинговым переводом, что меня сильно удивляет. Потому и захотелось развенчать мифы из данной статьи.

Не поймите меня неправильно, я не фанбой C#. Буквально недавно в подкасте DotNet & More №53 C# 10 и не только я жаловался на то, что C#10 не впечатляет. Но в своих высказываниях необходимо стараться быть хоть немного объективным. Или, хотя бы, иронизировать над необъективностью.

В 53 выпуске подкаста DotNet & More (site, youtube) мы обсуждали фичи C# 10 и разбирали их применимость в будущем. И уже потом возник вопрос: все ли языковые конструкции из C#1, 2, 3, 4 и т.д. мы применяем? И даже если они безбожно устарели, существуют ли ситуации, в которых им найдется применение?

В недавнем выпуске подкаста DotNet & More мы обсуждали полезные материалы для тимлидов и всплыла классическая проблема: как совмещать управление командой и написание кода. Этой осенью я рассказывал о лайвхаках, которые помогают мне продолжать программировать на позиции лида и мне показалось полезным, в этом контексте, выложить текстовую расшифровку доклада.

В недавнем выпуске подкаста DotNet&More мы обсуждали с Максимом Аршиновым его предстоящий доклад на Московский .Next "Блеск и нищета предметной модели". С позицией Максима можно будет легко познакомиться непосредственно на конференции. И, в качестве дополнения, я бы хотел рассмотреть видение великого спора Анемичная VS "Богатая" ("Насыщенная") доменные модели через призму некогда популярных GRASP шаблонов

Дискуссии идут достаточно давно, например:

• Anemic Domain Model [Перевод]
• [Перевод] Анемичная модель предметной области — не анти-шаблон, а архитектура по принципам SOLID
  Судя по 190 комментариями к последней статье, данная тема не теряет актуальности.

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

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

В недавнем выпуске подкаста DotNet & More Blazor, NetCore 3.0 Preview, C#8 и не только мы лишь вскользь упомянули такую животрепещущую тему, как C#8. Рассказ об опыте работы с C# 8 был недостаточно большим, что-бы посвящать ему отдельный выпуск, так что было решено поделиться им средствами эпистолярного жанра.

В данной статье я бы хотел рассказать о своем опыте использования C#8 на продакшене в течение 4 месяцев. Ниже Вы сможете найти ответы на следующие вопросы:

• Как "пишется" на новом C#
• Какие возможности оказались действительно полезными
• Что разочаровало