unmanaged constraint

Позавчера на докладе меня попросили прокомментировать этот фрагмент кода из ML NET.

В частности слушателя заинтересовало, что означает ограничение unmanaged.

Тогда ответить не вышло, честно не знал 😅

Однако я не я, если не разберусь в теме, и не напишу об этом пост 😁

Запоминаем - where T : unmanaged означает, что тип T это что-то из списка ниже:

⭐️ sbyte, byte, short, ushort, int, uint, long, ulong, nint, nuint, char, float, double, decimal, bool

🌴 любой enum тип

🎁 любой тип указателя (например void*)

👽 любой пользовательский struct с полями только из unmanaged типов

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

Task vs ValueTask

Что такое Task знают все C# разработчики - класс, олицетворяющий длительную операцию в асинхронном программировании.

А вот в 7 версии языка появилась структура ValueTask, и до сих пор не всем ясно её назначение.

Из интересного в ней два поля - первое для хранения задачи, второе для хранения результата (при наличии).

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

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

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

Однако, есть ряд ограничений, то есть, нельзя делать следующие вещи:

⭐️ Ожидать задачу конкурентно или несколько раз

⭐️ Вызывать метод AsTask несколько раз

⭐️ Использовать .Result или .GetAwaiter().GetResult(), если задача не завершена

⭐️ Использовать задачу в комбинаторах WhenAll() и WhenAny()

Почему я всегда сообщаю рекрутеру зарплатные ожидания? 🤔

Есть распространённое мнение о зарплатных переговорах: «кто первый назвал цифру, тот и проиграл».

Однако это не совсем так.

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

Во-вторых, разработчики это такие же рядовые сотрудники, как и другой персонал: для них существует вполне конкретный ФОТ.

То есть торги - это инструмент не растяжения мешка с деньгами, а прощупывания его границ.

И вот однажды я собеседовался в дом рф, попробовав всеми правдами и неправдами скрыть цифру 💵

Изворачивался и уходил от ответа так, как никогда в жизни 🤯

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

Но когда дело дошло до оффера, меня брали по верху вилки, но оказался таким, что смысл туда идти пропал абсолютно 🥵

Сказать, что чувствовал себя тогда идиотом - не сказать ничего 😁

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

А терять время не хочет никто.

На просторах рунета этого не найти 🤫

Под вчерашним постом развернулась горячая дискуссия о переговорах по зарплате🔥

Поэтому делюсь с вами топом своих любимых материалов по этому вопросу ⭐️

▪️https://www.kalzumeus.com/2012/01/23/salary-negotiation/

▪️https://bayareabelletrist.medium.com/how-i-negotiated-a-software-engineer-offer-in-silicon-valley-f11590f5c656

▪️https://faangpath.medium.com/how-to-negotiate-salary-offer-e9475ab11e3f

▪️https://www.freecodecamp.org/news/how-not-to-bomb-your-offer-negotiation-c46bb9bc7dea#.w30tfvb9r

Завтра начнётся последний месяц 2023 года, а значит пора подвести итоги ноября 🤩

В этом месяце постарался выдать побольше эксклюзивных материалов 🤫

🔥 Уникальный гайд по акклиматизации на новой работе

🔥 Разоблачение стагнации процессов собеседования OZON

🔥 Запись доклада на MskDotNet Meetup

🔥 Личная история о важности открытости в зарплатных переговорах

🔥 Эффективные секретные материалы о зарплатных переговорах впервые в telegram

В EF Core 8 узаконили Value Object 🤩

Одно из тех обновлений, которое не следует пропускать 😱

Например, есть следующая сущность заказа Order вместе с сущностью клиента Customer:

public class Customer
{
    public int Id { get; set; }
    public required string Name { get; set; }
    public required Address Address { get; set; }
    public List<Order> Orders { get; } = new();
}

public class Order
{
    public int Id { get; set; }
    public required string Contents { get; set; }
    public required Address ShippingAddress { get; set; }
    public required Address BillingAddress { get; set; }
    public Customer Customer { get; set; } = null!;
}

Кажется, что уже существует семантика работы с типами значениями, ведь никто не отменял атрибут [Owned].

Однако, при попытке сохранить сущность, которая использует один инстанс на несколько полей возникнет ошибка:

var address = GetAddress();

customer.Orders.Add(
    new Order { Contents = "Tesco Tasty Treats", BillingAddress = address, ShippingAddress = address, });

await context.SaveChangesAsync();

Кажется, что всё будет хорошо, но получим исключение InvalidOperationException с сообщением

«Cannot save instance of 'Order.ShippingAddress#Address' because it is an owned entity without any reference to its owner. Owned entities can only be saved as part of an aggregate also including the owner entity.
at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalEntityEntry.PrepareToSave()»

Теперь, достаточно разметить тип данных атрибутом [ComplexType].
При этом он может быть иммутабельным!

[ComplexType]
public record Address(string Line1, string? Line2, string City, string Country, string PostCode);

Соответственно, такое обновление сущности:

customer.Address = customer.Address with { Line1 = "Peacock Lodge" };

await context.SaveChangesAsync();

Сгенерирует следующий SQL:

UPDATE [Customers] SET [Address_Line1] = @p0
OUTPUT 1
WHERE [Id] = @p1;

То есть, это собственный тип на стероидах 💉

Релизнулся Rider 2023.3 😱

Завезли много всего интересного: поддержку .NET 8 SDK, одновременный запуск нескольких проектов, предиктивный дебаггинг, вытащили из превью AI ассистента и многое другое

Например, добавили отрисовку диаграм зависимостей типов 🎁

Теперь можно воочию увидеть архитектуру своего проекта, и убедиться, что её нужно переделать 😱

Короче говоря, побежали обновляться! 🏃‍♂️

Лучшая статья за прошедшую неделю 👍

Невольно закралась мысль о том, что все мои последние проекты могли прекрасно существовать в виде монолитов...

"Вопрос: Может ли монолит быть также эффективен как микросервисная архитектура?

Ответ: Нет, ему никогда не стать настолько же медленным" 👏

https://habr.com/ru/articles/779362/

Тут на днях разнесли в пух и прах первичные конструкторы в C# 12

В целом я согласен со многими поинтами, и поэтому хочется посмотреть, так сказать, bigger picture.

Подумайте: есть ли у вас такое ощущение, что последней крупной и продуманной до конца фичей была добавленная в C# 5 асинхронность?

Все последующие обновления чувствуются минорными - их спокойно можно было бы нумеровать 5.1, 5.2, 5.3 и так далее.

Даже обобщённую математику не доделали до конца!

Скорее всего, проблема в том, что Андерс Хейлсберг не занимается проектом, зато о TypeScript теперь кричат из каждого утюга 🤔

https://habr.com/ru/articles/779166/

Visitor NET. Уникальный проект

Когда я начал рефакторинг своего интерпретатора, передо мной встал вопрос, как реализовывать паттерн Visitor.

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

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

Ну а появляющаяся система типов выглядела слишком самодостаточной, чтобы стать частью домена моего приложения.

Так было принято решение выделить контракты для реализации паттерна в отдельную сборку, которая потом подключалась через NuGet.

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

public interface IVisitor<in TVisitable, out T> : IVisitor
    where TVisitable : IVisitable
{
    T Visit(TVisitable visitable);
}

Соответственно сам визитор выглядел примерно так:

public class TypeSystemLoader :
    IVisitor<ScriptBody>,
    IVisitor<AbstractSyntaxTreeNode>,
    IVisitor<TypeDeclaration>
{
    // ...
}

Сам посещаемый элемент должен уметь вызвать visitor.Visit(this) и для этого ему нужно знать, что у типа есть правильная перегрузка метода.

Классический ациклический вариант предлагает следующую реализацию метода Accept:

public class ScriptBody : AbstractSyntaxTreeNode
{
    public override void Accept(IVisitor visitor)
    {
        if (visitor is IVisitor<ScriptBody> typed)
            typed.Visit(this);
    }
}

Однако, прибегать к явному даункастингу в такой ситуации очень не хочется, потому что это лишает код полиморфности.

Попытка провалилась - циклическую зависимость всё-таки пришлось оставить, поскольку во избежание явного кастинга посещаемому элементу приходилось знать о конкретном посетителе:

public interface IVisitable<in TVisitor, out T> : IVisitable
    where TVisitor : IVisitor
{
    T Accept(TVisitor visitor);
}

Такая реализация нарушала OCP и LSP, поскольку в посещаемом элементе отсутствовала единая точка входа для любого посетителя, независимая от результата обработки.

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

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

Всего этого удалось добиться с помощью контравариантности и паттерна CRTP:

public interface IVisitor<in TVisitable, out TReturn>
    where TVisitable : IVisitable<TVisitable>
{
    TReturn Visit(TVisitable visitable);
}

public interface IVisitable<out TVisitable>
    where TVisitable : IVisitable<TVisitable>
{
    TReturn Accept<TReturn>(IVisitor<TVisitable, TReturn> visitor);
}

Тогда, в самом посещаемом элементе приходится писать два метода Accept: первый для корня иерархии, который будет вызывать посетитель; а второй уже для того, чтобы под капотом вызвался нужный Visit:

public record Operation(
    char Symbol,
    BinaryTreeNode Left,
    BinaryTreeNode Right) : BinaryTreeNode, IVisitable<Operation>
{
    public override TReturn Accept<TReturn>(
        IVisitor<BinaryTreeNode, TReturn> visitor) =>
        Accept(visitor);

    public TReturn Accept<TReturn>(
        IVisitor<Operation, TReturn> visitor) =>
        visitor.Visit(this);
}

С написанием этих двух методов можно не заморачиваться, так как я создал incremental source generator, который автоматизирует написание кода.

Таким образом, удалось решить нетривиальную задачу по созданию ациклической, универсальной, расширяемой и типобезопасной реализации шаблона Visitor без применения явного даункастинга.

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

Поэтому, давайте поддержим мой проект звездой на гитхаб ⭐️
https://github.com/Stepami/visitor-net

Нейросеть так не сможет.

Что означает «CAP» в CAP теореме?

1️⃣ Consistency, Availability, Partition Tolerance

2️⃣ Control, Allocation, Process

3️⃣ Code, Architecture, Pipeline

4️⃣ Connection Access Protocol

Правильный ответ: 1️⃣

Пояснение:

CAP теорема утверждает, что в любой распределённой системе можно добиться только 2 из 3 гарантий.

Consistency - данные между узлами системы согласованы и не противоречат друг другу

Availability - любой request к системе завершается response

Partition Tolerance - выход из строя отдельных узлов системы не влияет на её общую работоспособность

Ставь 🐳 если тебя это спрашивали на собесе