В конце прошлого года на этом канале было 19 человек. Сейчас 174. Это же целая аудитория в университете! Круто, что меня читает так много инженеров. Спасибо вам за интерес и поддержку в течение этого года.
За год было написано много статей, большая часть которых публиковалась здесь. Полноценные статьи также выходили на Хабре, а переводы на Reddit. Часть из них была высоко оценена сообществом. Например, статью про FrozenDictionary репостили многие каналы и разбирали на подкасте DotNetRu.
Моя цель — сделать канал ещё полезнее для инженеров, продолжить обсуждать сложные темы простым языком. Буду рад вашим идеям и пожеланиям.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍29
🇷🇸 Жизнь в Сербии. Часть 1. Стоимость жизни.
Давно хотел рассказать про жизнь в Сербии, поэтому начнём этот год с нетехнической статьи.
Предыстория
В Сербию мы впервые приехали в августе 2022 года. Тогда я ещё работал на проекте Fujitsu. Мы обеспечивали работу приложений в Японии, Южной Корее и Австралии. На тот момент серьёзно ходили слухи об отключении России от глобального интернета. Поскольку компания должна была обеспечивать непрерывную поддержку сервисов, инженеров периодически направляли в офис в Сербии. В августе пришла очередь и до меня. После этого было короткое возвращение на Родину, месячная командировка в Индию, смена работы и окончательный переезд в Сербию в октябре 2022 года.
Жильё
Мы снимаем «евродвушку» площадью 45 кв.м. за 650 € в месяц. Это медианная цена для района Новый Белград. Знаю людей, которые находили квартиры чуть больше за те же деньги, а также тех, кто платил значительно больше за аналогичное жильё. Кстати, понятие «евродвушка» в Сербии отсутствует — такие квартиры считаются однокомнатными.
Коммунальные услуги
Стоимость коммунальных услуг сильно зависит от сезона. Зима здесь мягкая, но отопление всё равно необходимо — оно составляет добрую половину платежа. Например, в декабре 2024 года отопление обошлось в 50 €. Летом же стоимость высока из-за кондиционера, так как 40-градусная жара в июле и августе — обычное явление в Белграде. Средняя стоимость коммуналки за последний год составила 97 €.
Связь
Интернет в квартире обходится в 14 € в месяц, при этом скорость составляет 500 Мбит/с. Мобильная связь в среднем стоит около 10 € на человека.
Транспорт
С 1 января 2025 года общественный транспорт в Белграде стал бесплатным. До этого единый безлимитный проездной на автобусы, троллейбусы и трамваи стоил около 19 € в месяц (2200 динар).
Такси я использую редко — за весь прошлый год было всего шесть поездок, каждая обошлась от 5 € до 22 €.
Продукты
Большую часть продуктов мы покупаем в супермаркетах Lidl, поэтому подсчитать расходы было просто — я просто сложил все чеки из приложения. Средний месячный расход на продукты за 2024 год составил около 300 €.
Медицина
Медицина в Сербии делится на государственную и частную. Государственная медицина практически бесплатная — за приём врача нужно заплатить около 0.5 €.
Частная медицина дороже. Без страховки на приём врача лучше заложить 50 €. Если потребуется диагностика, например УЗИ или МРТ, то стоимость может увеличиться до 100–200 €.
Итог
Сложим основные ежемесячные расходы:
- Аренда: 650 €
- Коммунальные услуги: 90 €
- Интернет: 14 €
- Мобильная связь (на двоих): 20 €
- Продукты: 300 €
Итоговая сумма: 1074 € в месяц
Эта цифра включает только базовые траты и может варьироваться в зависимости от личных потребностей и стиля жизни. В следующих частях я расскажу про другие аспекты жизни в Сербии.
Давно хотел рассказать про жизнь в Сербии, поэтому начнём этот год с нетехнической статьи.
Предыстория
В Сербию мы впервые приехали в августе 2022 года. Тогда я ещё работал на проекте Fujitsu. Мы обеспечивали работу приложений в Японии, Южной Корее и Австралии. На тот момент серьёзно ходили слухи об отключении России от глобального интернета. Поскольку компания должна была обеспечивать непрерывную поддержку сервисов, инженеров периодически направляли в офис в Сербии. В августе пришла очередь и до меня. После этого было короткое возвращение на Родину, месячная командировка в Индию, смена работы и окончательный переезд в Сербию в октябре 2022 года.
Жильё
Мы снимаем «евродвушку» площадью 45 кв.м. за 650 € в месяц. Это медианная цена для района Новый Белград. Знаю людей, которые находили квартиры чуть больше за те же деньги, а также тех, кто платил значительно больше за аналогичное жильё. Кстати, понятие «евродвушка» в Сербии отсутствует — такие квартиры считаются однокомнатными.
Коммунальные услуги
Стоимость коммунальных услуг сильно зависит от сезона. Зима здесь мягкая, но отопление всё равно необходимо — оно составляет добрую половину платежа. Например, в декабре 2024 года отопление обошлось в 50 €. Летом же стоимость высока из-за кондиционера, так как 40-градусная жара в июле и августе — обычное явление в Белграде. Средняя стоимость коммуналки за последний год составила 97 €.
Связь
Интернет в квартире обходится в 14 € в месяц, при этом скорость составляет 500 Мбит/с. Мобильная связь в среднем стоит около 10 € на человека.
Транспорт
С 1 января 2025 года общественный транспорт в Белграде стал бесплатным. До этого единый безлимитный проездной на автобусы, троллейбусы и трамваи стоил около 19 € в месяц (2200 динар).
Такси я использую редко — за весь прошлый год было всего шесть поездок, каждая обошлась от 5 € до 22 €.
Продукты
Большую часть продуктов мы покупаем в супермаркетах Lidl, поэтому подсчитать расходы было просто — я просто сложил все чеки из приложения. Средний месячный расход на продукты за 2024 год составил около 300 €.
Медицина
Медицина в Сербии делится на государственную и частную. Государственная медицина практически бесплатная — за приём врача нужно заплатить около 0.5 €.
Частная медицина дороже. Без страховки на приём врача лучше заложить 50 €. Если потребуется диагностика, например УЗИ или МРТ, то стоимость может увеличиться до 100–200 €.
Итог
Сложим основные ежемесячные расходы:
- Аренда: 650 €
- Коммунальные услуги: 90 €
- Интернет: 14 €
- Мобильная связь (на двоих): 20 €
- Продукты: 300 €
Итоговая сумма: 1074 € в месяц
Эта цифра включает только базовые траты и может варьироваться в зависимости от личных потребностей и стиля жизни. В следующих частях я расскажу про другие аспекты жизни в Сербии.
👍15
Сообщество DotNetRu на подкасте разбирает статью про пулы объектов в C#
Сегодня ребята из DotNetRu выложили подкаст, на котором разобрали мою статью про паттерн ObjectPool.
Если вы пропустили эту статью и вам интересен формат подкаста, то вот ссылка.
Сегодня ребята из DotNetRu выложили подкаст, на котором разобрали мою статью про паттерн ObjectPool.
Если вы пропустили эту статью и вам интересен формат подкаста, то вот ссылка.
Telegram
DotNetRu
Пулы объектов в деталях, невольный null в F#, весёлые ошибки в топе
Подкаст RadioDotNet выпуск №108 от 3 февраля 2025 года
https://radiodotnet.mave.digital/ep-109
Темы:
[00:01:45] — Пулы объектов в C#
• https://habr.com/ru/articles/864902/
[00:22:10]…
Подкаст RadioDotNet выпуск №108 от 3 февраля 2025 года
https://radiodotnet.mave.digital/ep-109
Темы:
[00:01:45] — Пулы объектов в C#
• https://habr.com/ru/articles/864902/
[00:22:10]…
👍9
Оптимизация JIT-компилятора при работе с коллекциями
Помните я писал статью про производительность foreach при работе с коллекциями через интерфейс IEnumerable?
Вкратце напомню в чём дело. Когда мы используем, например массивы и списки через интерфейс IEnumerable<T>, то их энумератор приводится к интерфейсу IEnumerator. У массивов и списков энумератор – это структура. Следовательно, при приведении происходит упаковка.
Так вот, команда .NET собирается добавить в .NET 10 оптимизацию для таких случаев, по крайней мере для массивов.
По моему, это круто. Теоретически, работа с массивами через LINQ должна ускориться. Будет интересно проверить этот функционал, когда появится первый релиз .NET 10.
Помните я писал статью про производительность foreach при работе с коллекциями через интерфейс IEnumerable?
Вкратце напомню в чём дело. Когда мы используем, например массивы и списки через интерфейс IEnumerable<T>, то их энумератор приводится к интерфейсу IEnumerator. У массивов и списков энумератор – это структура. Следовательно, при приведении происходит упаковка.
Так вот, команда .NET собирается добавить в .NET 10 оптимизацию для таких случаев, по крайней мере для массивов.
По моему, это круто. Теоретически, работа с массивами через LINQ должна ускориться. Будет интересно проверить этот функционал, когда появится первый релиз .NET 10.
Telegram
yet another dev
👩💻 Пишем производительный C# код при работе с коллекциями
Публикую следующую часть статьи про производительность коллекций. Сегодня про Enumerator.
---
Предположим, у нас есть массив _transactionsArray и список _transactionsList. Сама транзакция выглядит…
Публикую следующую часть статьи про производительность коллекций. Сегодня про Enumerator.
---
Предположим, у нас есть массив _transactionsArray и список _transactionsList. Сама транзакция выглядит…
👍7
FluentAssertions стала платной
Коллеги, если вы вдруг пропустили новость, то сообщаю. Библиотека для тестирования FluentAssertions стала платной около месяца назад. Теперь стандартная лицензия для 1 разработчика стоит $129.95 в год, а для небольших компаний – $49.95 в год.
Новость довольно неприятная. Мы, например, используем её повсеместно на наших проектах.
Какие есть альтернативы:
1. Остаться на FluentAssertions не выше версии 7.0.0.
2. Перейти на AwesomeAssertions – форк FluentAssertions с лицензией Apache 2.0, который продолжит развиваться сообществом.
3. Перейти на Shouldly – бесплатную библиотеку с лицензией BSD.
4. Перейти на NFluent – ещё одну бесплатную библиотеку.
5. Вернуться к классическому Assert.
Если вы уже используете FluentAssertions, самым простым вариантом будет переход на AwesomeAssertions.
Коллеги, если вы вдруг пропустили новость, то сообщаю. Библиотека для тестирования FluentAssertions стала платной около месяца назад. Теперь стандартная лицензия для 1 разработчика стоит $129.95 в год, а для небольших компаний – $49.95 в год.
Новость довольно неприятная. Мы, например, используем её повсеместно на наших проектах.
Какие есть альтернативы:
1. Остаться на FluentAssertions не выше версии 7.0.0.
2. Перейти на AwesomeAssertions – форк FluentAssertions с лицензией Apache 2.0, который продолжит развиваться сообществом.
3. Перейти на Shouldly – бесплатную библиотеку с лицензией BSD.
4. Перейти на NFluent – ещё одну бесплатную библиотеку.
5. Вернуться к классическому Assert.
Если вы уже используете FluentAssertions, самым простым вариантом будет переход на AwesomeAssertions.
👍11
English is below.
Возвращаюсь к работе после отпуска.
В ноябре я рассказывал про EventFlow — библиотеку, предназначенную для DDD и Event Sourcing. Наша команда активно её использует. Спустя несколько месяцев работы с ней я заметил, что часто приходится писать повторяющийся код, что довольно утомительно.
// Чтобы создать событие для агрегата OrderAggregate,
// приходится каждый раз указывать тип агрегата и тип его ID
public class OrderCreated :
IAggregateEvent<OrderAggregate, OrderAggregateId>
// При подписке на события необходимо
// указывать тип события, агрегата и ID
public class OrderAggregateSubscribers :
ISubscribeSynchronousTo<OrderAggregate, OrderAggregateId, OrderCreated>
Можно объявить абстрактный класс для всех событий агрегата и использовать его:
public abstract class OrderAggregateEvent :
IAggregateEvent<OrderAggregate, OrderAggregateId>;
Создать новый интерфейс, принимающий только тип события:
public interface ISubscribeSynchronousTo<TEvent> :
ISubscribeSynchronousTo<OrderAggregate, OrderAggregateId, TEvent>
Но даже в этом случае всё равно приходится вручную дублировать код для каждого агрегата. А как гласит известная айтишная мудрость:
«Никогда не тратьте 10 минут, чтобы сделать что-то вручную, если можно потратить 10 часов пытаясь это автоматизировать».
Поэтому в начале февраля я занялся написанием генератора кода для EventFlow. Через 2 недели и 7 коммитов библиотека EventFlow.SourceGenerators была готова и на днях Расмус Микелсен (автор EventFlow) принял изменения.
Теперь вся рутинная работа ложится на компилятор, и можно писать меньше кода, который к тому же лучше читается.
// Добавляем атрибут AggregateExtensions к агрегату
[AggregateExtensions]
public class OrderAggregate(OrderAggregateId id) :
AggregateRoot<OrderAggregate, OrderAggregateId>(id)
// Объявляем события
// OrderAggregateEvent создан автоматически
public class OrderCreated : OrderAggregateEvent;
// Подписываемся на события
// Новый интерфейс создан автоматически
public class OrderAggregateSubscribers :
ISubscribeSynchronousTo<OrderCreated>
Как видите, код стал заметно чище, и теперь нам не приходится снова и снова указывать тип агрегата и тип ID.
Стоит отметить, что генераторы кода — непростая тема. Существует множество ограничений и сложностей. Например, с чем я столкнулся:
1. Генераторы можно писать только под .NET Standard 2.0.
2. Возможны коллизии названий сгенерированных объектов.
3. Тестирование сгенерированного кода имеет свои особенности.
Если вам интересна тема генераторов кода, рекомендую начать с этого видео от Microsoft.
Затем изучите следующие материалы:
- Creating an incremental generator.
- Introducing C# Source Generators.
- Incremental Generators Cookbook.
В качестве примера можно заглядывать в исходный код библиотеки EventFlow.SourceGenerators и её тестов. Она довольна простая. Больше примеров её применения можно найти в документации.
Please open Telegram to view this post
VIEW IN TELEGRAM
alexeyfv
Code Generators in C#
In November, I wrote about EventFlow library designed for DDD and Event Sourcing. Our team actively uses it. After working with it for several months, I noticed that I often had to write repetitive code, which became quite tedious.
👍14
Наверное, многие слышали о сокращениях в российской IT-сфере. Например, пару месяцев назад уволили мою однокурсницу из «Купера». По её словам, там сократили ещё множество сотрудников. Кроме того, я заметил, что HR почти перестали писать мне с предложениями о работе. Хотя не исключаю, что компании просто избегают релокантов. Так или иначе, мне стало интересно, какие вакансии для C# разработчиков сейчас публикуются на сайтах по поиску работы. Я решил написать скрепер для hh.ru.
Методология сбора данных
Данные собирается по следующим параметрам:
1. Общее количество вакансий.
2. Количество вакансий по месту работы (офис/удалёнка).
3. Количество вакансий по образованию.
4. Количество вакансий по опыту.
5. Количество вакансий по указанной зарплате.
В выборку попадают все вакансии, где указан навык C#. Это не только разработчики, но и, например, тимлиды и AQA.
Важно учитывать, что:
- Одна вакансия может быть на несколько позиций. Например, когда требуется нанять сразу несколько C# программистов на один проект.
- Разные вакансии могут быть на одну и ту же позицию, но размещены в нескольких городах.
- В зарплатах указываются как нижний, так и верхний предел вилки.
Поэтому диаграммы лишь приблизительно отражают реальную картину.
Результаты
1. Без фильтров hh.ru показывает 2574 вакансий с навыком C#. Большая часть из них — разработка. С фильтрами, почему-то суммарное количество получается немного другое. Например, если разбивать по образованию, то суммарное количество вакансий будет 2624 — на 40 больше.
2. Удалёнка разрешена в 36% вакансий.
3. Для 28% вакансий требуется высшее образование.
4. Для начинающих айтишников доступно 11% вакансий.
5. Зарплата указана для 33% вакансий. Судя по распределению, медианная зарплата находится где-то в районе 150к - 175к рублей.
Что дальше
Интересно понаблюдать за вакансиями в динамике. Также планирую анализировать вакансии с Хабр Карьеры. Если знаете другие популярные сайты с вакансиями — напишите в комментариях.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
Уже вторую неделю встречаю комментарии в духе: «Если C# такой быстрый и хороший, то почему Microsoft переписала компилятор TypeScript на Go, а не на C#?»
Среди множества спекуляций на эту тему мне попался один комментарий на Хабре, который, как мне кажется, ясно объясняет причину.
Btw, компилятор C# (Roslyn) написан на C#.
Среди множества спекуляций на эту тему мне попался один комментарий на Хабре, который, как мне кажется, ясно объясняет причину.
Btw, компилятор C# (Roslyn) написан на C#.
👍8
yet another dev
Photo
Куда-то делись комментарии. 🤔
Please open Telegram to view this post
VIEW IN TELEGRAM
Пришёл вчера вечером домой и решил-таки почитать тред Why Go?.
Оказывается, комментарий на Хабре, о котором я писал, это перевод вот этого комментария. У него, к слову, больше дизлайков, чем лайков, т.к. написан AI. Но, судя по всему, портировать (именно портировать, не переписывать) TypeScript на Go всё же легче.
В самом низу есть и ответ Андерса Хейлсберга. Приведу цитату:
Короче говоря, это техническое решение обусловленное финансовыми ограничениями. Переписать на Rust/C# можно было бы, но кто за это будет платить?
Оказывается, комментарий на Хабре, о котором я писал, это перевод вот этого комментария. У него, к слову, больше дизлайков, чем лайков, т.к. написан AI. Но, судя по всему, портировать (именно портировать, не переписывать) TypeScript на Go всё же легче.
В самом низу есть и ответ Андерса Хейлсберга. Приведу цитату:
The TypeScript compiler's move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. After evaluating numerous languages and making multiple prototypes — including in C# — Go emerged as the optimal choice, providing excellent ergonomics for tree traversal, ease of memory allocation, and a code structure that closely mirrors the existing compiler, enabling easier maintenance and compatibility.
In a green field, this would have been a totally different conversation. But this was not a green field - it's a port of an existing codebase with 100 man-years of investment. Yes, we could have redesigned the compiler in C# from scratch, and it would have worked. In fact, C#'s own compiler, Roslyn, is written in C# and bootstraps itself. But this wasn't a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping. Our existing codebase is all functions and data structures - no classes. Idiomatic Go looked just like our existing codebase so the port was greatly simplified.
Короче говоря, это техническое решение обусловленное финансовыми ограничениями. Переписать на Rust/C# можно было бы, но кто за это будет платить?
👍7
ИИ впечатляет всё больше и больше
Последние несколько дней я занимаюсь миграцией своего блога с Jekyll на Astro, и в этом мне очень помогает ИИ.
1. Частично пишу код с помощью ИИ-агентов в GitHub Copilot (тот самый Vibe Coding). Особенно полезно, когда нужно выполнить много рутинных задач: заменить <img/> на <Image>, добавить краткие описания ко всем постам, отредактировать теги и привести их к единому стилю.
2. В Astro у каждого поста должна быть обложка, тогда как в Jekyll она была не обязательной. Здесь на помощь приходит генерация картинок в ChatGPT. Впечатляет, что нейросети уже умеют корректно генерировать текст.
Последние несколько дней я занимаюсь миграцией своего блога с Jekyll на Astro, и в этом мне очень помогает ИИ.
1. Частично пишу код с помощью ИИ-агентов в GitHub Copilot (тот самый Vibe Coding). Особенно полезно, когда нужно выполнить много рутинных задач: заменить <img/> на <Image>, добавить краткие описания ко всем постам, отредактировать теги и привести их к единому стилю.
2. В Astro у каждого поста должна быть обложка, тогда как в Jekyll она была не обязательной. Здесь на помощь приходит генерация картинок в ChatGPT. Впечатляет, что нейросети уже умеют корректно генерировать текст.
👍7
Утиная типизация в C#
English version.
Думаю, опытные C#-разработчики знают ответ на вопрос: «Что нужно сделать, чтобы можно было перечислить объекты при помощи foreach?»
Для этого не обязательно наследовать класс от интерфейса IEnumerable. Достаточно, чтобы класс имел публичный метод GetEnumerator, который возвращает объект, реализующий IEnumerator.
Такое поведение иногда называют утиной типизацией — компилятору неважно, реализует ли класс интерфейс IEnumerable или нет. Главное, чтобы в нём был метод, возвращающий перечислитель.
Аналогичное поведение встречается и при работе с async-await. Чтобы «ожидать» тип, достаточно, чтобы у него был метод GetAwaiter(), возвращающий тип TaskAwaiter или ValueTaskAwaiter. При этом даже не обязательно, чтобы этот метод был внутри самого ожидаемого типа.
Недавно я наткнулся на ещё один случай, который можно считать примером утиной типизации. Начиная с версии 12, в C# появился упрощённый способ инициализации коллекций:
Этот лаконичный синтаксис работает не со всеми коллекциями. Например, следующий код не скомпилируется:
Компилятор ожидает, что у типа коллекции будет метод Add, но в Queue вместо него используется Enqueue, а в Stack — Push. Изменить эти типы мы не можем, поэтому можно сделать следующий финт и помочь компилятору обнаружить метод Add:
Упрощённая инициализация работает и с кастомными коллекциями, при условии, что для них есть соответствующий метод Add — неважно, внутри типа или в методе-расширении.
UPD: В комментариях выяснили, что оператор using может быть использован с ref struct без IDisposable начиная с C# 8.0.
UPD2: В комментариях выяснили, что foreach может обойтись без IEnumerator.
English version.
Думаю, опытные C#-разработчики знают ответ на вопрос: «Что нужно сделать, чтобы можно было перечислить объекты при помощи foreach?»
Для этого не обязательно наследовать класс от интерфейса IEnumerable. Достаточно, чтобы класс имел публичный метод GetEnumerator, который возвращает объект, реализующий IEnumerator.
// Этот код компилируется
var obj = new MyType();
foreach (var item in obj);
class MyType {
public IEnumerator GetEnumerator() {
throw new Exception();
}
}
Такое поведение иногда называют утиной типизацией — компилятору неважно, реализует ли класс интерфейс IEnumerable или нет. Главное, чтобы в нём был метод, возвращающий перечислитель.
Аналогичное поведение встречается и при работе с async-await. Чтобы «ожидать» тип, достаточно, чтобы у него был метод GetAwaiter(), возвращающий тип TaskAwaiter или ValueTaskAwaiter. При этом даже не обязательно, чтобы этот метод был внутри самого ожидаемого типа.
cs
// Этот код тоже компилируется
var obj = new MyType();
await obj;
class MyType {
}
static class MyTypeExtensions {
public static TaskAwaiter GetAwaiter(
this MyType @object) {
throw new Exception();
}
}
Недавно я наткнулся на ещё один случай, который можно считать примером утиной типизации. Начиная с версии 12, в C# появился упрощённый способ инициализации коллекций:
int[] array = [1, 2, 3, 4, 5];
List<int> list = [1, 2, 3, 4, 5];
Этот лаконичный синтаксис работает не со всеми коллекциями. Например, следующий код не скомпилируется:
Queue<int> queue = [1, 2, 3, 4, 5];
Stack<int> stack = [1, 2, 3, 4, 5];
Компилятор ожидает, что у типа коллекции будет метод Add, но в Queue вместо него используется Enqueue, а в Stack — Push. Изменить эти типы мы не можем, поэтому можно сделать следующий финт и помочь компилятору обнаружить метод Add:
public static class CollectionExtensions {
public static void Add<T>(
this Queue<T> collection,
T item) => collection.Enqueue(item);
public static void Add<T>(
this Stack<T> collection,
T item) => collection.Push(item);
}Упрощённая инициализация работает и с кастомными коллекциями, при условии, что для них есть соответствующий метод Add — неважно, внутри типа или в методе-расширении.
// и этот код компилируется
MyType collection = [1, 2, 3];
class MyType : IEnumerable {
public IEnumerator GetEnumerator() {
throw new Exception();
}
}
static class MyTypeExtensions {
public static void Add(
this MyType o,
int value) { }
}
UPD: В комментариях выяснили, что оператор using может быть использован с ref struct без IDisposable начиная с C# 8.0.
using var obj = new MyType();
ref struct MyType {
public void Dispose() { }
}
UPD2: В комментариях выяснили, что foreach может обойтись без IEnumerator.
// Этот код компилируется
var obj = new MyType();
foreach (var item in obj);
class MyType {
public MyEnumerator GetEnumerator() => new();
}
class MyEnumerator {
public object Current => new();
public bool MoveNext() => false;
}
👍17❤1
Ещё больше опенсорсных проектов становятся платными
Две свежие новости из мира open-source software (OSS) в .NET:
1. MassTransit станет платным, начиная с версии 9. Новая версия будет распространяться по коммерческой лицензии. При этом версия 8 останется OSS и будет получать только критические патчи и багфиксы.
2. Джимми Богарт, автор AutoMapper и MediatR, также сообщил, что переводит свои проекты на коммерческую модель. Он больше не может поддерживать их в свободное от работы время, как раньше, и хочет создать устойчивую модель развития. Конкретные детали монетизации пока не объявлены. Забавно, что всего 2 месяца назад он писал, что никогда не сделает MediatR платным.
Что происходит?
Не сказать, что я большой фанат AutoMapper и MediatR. По-моему, от них даже больше проблем, чем пользы. Но поддержка OSS – действительно сложная штука. Людей, которые тратят личное время на такие проекты можно понять. Я это вижу даже по EventFlow. У библиотеки 2.4 тыс. звёзд на GitHub и миллионы загрузок на NuGet. Но при этом автор пишет, что почти нет пул-реквестов от компаний, не говоря уже о финансовой поддержке.
Можно вспомнить свежий случай с FluentAssertions. Ещё 2 года назад автор с иронией «хвастался», что кто-то задонатил $31. Неудивительно, что он решил продать своё детище компании. Правда это не отменяет текущий неадекватный ценник на библиотеку – сейчас она стоит почти как Rider.
Также можно привести в пример Avalonia UI. У проекта 27.3 тыс. звёзд на GitHub, десятки миллионов загрузок на NuGet и всего 43 спонсора. Даже если предположить, что каждый из них донатит по $100 в месяц (что маловероятно), это всего $4300 — немного для команды из 11 человек. Да, они наверняка дополнительно зарабатывают на консалтинге, но если говорить исключительно о добровольной поддержке через донаты — ситуация грустная.
Короче говоря, заниматься OSS — это интересно, полезно и вдохновляюще. Но когда проект становится популярным, трудно продолжать работать над ним бесплатно с учётом возрастающей нагрузки. В какой-то момент разработчик выгорает и начинает хотеть справедливой компенсации за свой труд. И вместо поддержки часто получает волну критики, причём от своих же коллег по цеху.
В итоге от всей этой ситуации выигрывают только корпорации. Одни просто используют OSS в своих коммерческих продуктах. Другие скупают права на библиотеки, фактически присваивая результат многолетнего труда десятков разработчиков, которые вкладывали в проект своё время, знания и энтузиазм.
Две свежие новости из мира open-source software (OSS) в .NET:
1. MassTransit станет платным, начиная с версии 9. Новая версия будет распространяться по коммерческой лицензии. При этом версия 8 останется OSS и будет получать только критические патчи и багфиксы.
2. Джимми Богарт, автор AutoMapper и MediatR, также сообщил, что переводит свои проекты на коммерческую модель. Он больше не может поддерживать их в свободное от работы время, как раньше, и хочет создать устойчивую модель развития. Конкретные детали монетизации пока не объявлены. Забавно, что всего 2 месяца назад он писал, что никогда не сделает MediatR платным.
Что происходит?
Не сказать, что я большой фанат AutoMapper и MediatR. По-моему, от них даже больше проблем, чем пользы. Но поддержка OSS – действительно сложная штука. Людей, которые тратят личное время на такие проекты можно понять. Я это вижу даже по EventFlow. У библиотеки 2.4 тыс. звёзд на GitHub и миллионы загрузок на NuGet. Но при этом автор пишет, что почти нет пул-реквестов от компаний, не говоря уже о финансовой поддержке.
Можно вспомнить свежий случай с FluentAssertions. Ещё 2 года назад автор с иронией «хвастался», что кто-то задонатил $31. Неудивительно, что он решил продать своё детище компании. Правда это не отменяет текущий неадекватный ценник на библиотеку – сейчас она стоит почти как Rider.
Также можно привести в пример Avalonia UI. У проекта 27.3 тыс. звёзд на GitHub, десятки миллионов загрузок на NuGet и всего 43 спонсора. Даже если предположить, что каждый из них донатит по $100 в месяц (что маловероятно), это всего $4300 — немного для команды из 11 человек. Да, они наверняка дополнительно зарабатывают на консалтинге, но если говорить исключительно о добровольной поддержке через донаты — ситуация грустная.
Короче говоря, заниматься OSS — это интересно, полезно и вдохновляюще. Но когда проект становится популярным, трудно продолжать работать над ним бесплатно с учётом возрастающей нагрузки. В какой-то момент разработчик выгорает и начинает хотеть справедливой компенсации за свой труд. И вместо поддержки часто получает волну критики, причём от своих же коллег по цеху.
В итоге от всей этой ситуации выигрывают только корпорации. Одни просто используют OSS в своих коммерческих продуктах. Другие скупают права на библиотеки, фактически присваивая результат многолетнего труда десятков разработчиков, которые вкладывали в проект своё время, знания и энтузиазм.
👍10
Коллеги, посоветуйте, пожалуйста, бесплатные Postgres-as-a-Service решения.
Цены у облачных провайдеров совсем не подходят для pet-проектов. Например, тот же Яндекс стоит больше 5000 рублей / месяц.
Основные требования:
- Бесплатно навсегда, без триал периода.
- Наличие резервных копий с возможностью восстановления хотя бы за последние 1–3 дня.
- Без обязательной привязки банковской карты.
- Локация — Европа.
- Объём — достаточно пары сотен мегабайт.
Google Sheets не предлагать. Я уже использую её в качестве базы данных.
Цены у облачных провайдеров совсем не подходят для pet-проектов. Например, тот же Яндекс стоит больше 5000 рублей / месяц.
Основные требования:
- Бесплатно навсегда, без триал периода.
- Наличие резервных копий с возможностью восстановления хотя бы за последние 1–3 дня.
- Без обязательной привязки банковской карты.
- Локация — Европа.
- Объём — достаточно пары сотен мегабайт.
👍4
SharpLab мёртв?
Сегодня буднично писал код. В какой-то момент мне понадобилось быстро вспомнить работу одной коллекции. Для таких случаях я обычно использую sharplab.io.
Открыв сайт и начав писать код я понял, что пользоваться им очень трудно из-за раздражающего бага: при вводе всплывает окно автокомплита, и если нажать Tab или Enter, редактор просто удаляет весь текст.
Я пошёл проверить, открыт ли issue. Оказалось, что да — и уже почти три месяца. Но никто его не правит, а пул реквесты в репозиторий вообще не принимаются.
Последняя активность в проекте — 18 ноября 2024 года. С тех пор — тишина.
На всякий случай я открыл issue с вопросом. Посмотрим, что ответит Андрей (автор SharpLab) и будет ли вообще ответ.
Сегодня буднично писал код. В какой-то момент мне понадобилось быстро вспомнить работу одной коллекции. Для таких случаях я обычно использую sharplab.io.
Открыв сайт и начав писать код я понял, что пользоваться им очень трудно из-за раздражающего бага: при вводе всплывает окно автокомплита, и если нажать Tab или Enter, редактор просто удаляет весь текст.
Я пошёл проверить, открыт ли issue. Оказалось, что да — и уже почти три месяца. Но никто его не правит, а пул реквесты в репозиторий вообще не принимаются.
Последняя активность в проекте — 18 ноября 2024 года. С тех пор — тишина.
На всякий случай я открыл issue с вопросом. Посмотрим, что ответит Андрей (автор SharpLab) и будет ли вообще ответ.
👍5
Альтернативы SharpLab
В продолжение вчерашнего поста публикую список инструментов, которые могут служить заменой SharpLab.
👩💻 C# Interactive в Visual Studio — встроенный REPL, который запускается через меню View → Other Windows → C# Interactive. Позволяет писать и выполнять C# код в отдельном окне.
👩💻 C# Interactive в Rider — аналогичный инструмент от JetBrains.
👩💻 csharprepl — опенсорсная REPL-утилита. Устанавливается через .NET CLI:
👩💻 dotnet-repl — ещё одна опенсорсная REPL-утилита. Также устанавливается через .NET CLI:
👩💻 Polyglot Notebook — расширение для VS Code. Использовать очень просто: установить, создать .dib файл, выбрать С# и можно писать код. Функционал аналогичен Jupiter Notebook.
⚙️ LINQPad — старая добрая десктопная программа, которая, пожалуй, больше всего по внешнему виду и функционалу похожа на SharpLab. Работает только на Windows и Mac (бета). К сожалению, полноценный функционал доступен только в платной версии, поэтому не очень подходит для рабочей тачки.
🌐 Compiler Explorer — онлайн дизассемблер. Позволяет просматривать только ASM. Поддерживает множество языков и C#, в том числе.
👩💻 dotPeek — бесплатный декомпайлер от JetBrains. Удобен тем, что позволяет смотреть C#, IL и ASM в одном окне. Работает только на Windows.
За рекомендации спасибо @ishvedov и @NSent.
В продолжение вчерашнего поста публикую список инструментов, которые могут служить заменой SharpLab.
dotnet tool install -g csharprepl. Есть автокомплит, Intellisense, подсветка синтаксиса, просмотр IL-кода и даже поддержка OpenAI через Bring Your Own Token. Примеры использования можно посмотреть в репозитории.dotnet tool install -g dotnet-repl. По сравнению с csharprepl, хуже работает подсветка синтаксиса. Совсем нет автокомплита, Intellisense и других фичей.⚙️ LINQPad — старая добрая десктопная программа, которая, пожалуй, больше всего по внешнему виду и функционалу похожа на SharpLab. Работает только на Windows и Mac (бета). К сожалению, полноценный функционал доступен только в платной версии, поэтому не очень подходит для рабочей тачки.
🌐 Compiler Explorer — онлайн дизассемблер. Позволяет просматривать только ASM. Поддерживает множество языков и C#, в том числе.
За рекомендации спасибо @ishvedov и @NSent.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10