C# *

Как вам известно, в .NET 5 появился новый вид кучи — Pinned Object Heap (POH, Куча Закрепленных Объектов). В отличие от других видов кучи, эта доступна разработчикам явно (что не характерно для сборщика мусора). В этой статье я объясню внутреннее устройство POH, чтобы вы лучше понимали сценарии ее использования.

Приехал ко мне брат. Отдохнуть, повидать родственников, посмотреть на родной город. А ему на машине заднее стекло разбили. Прямо во дворе нашего дома. Неприятно.

Вдохновившись парой статей на Хабре, посвященных созданию блокчейна на коленке, я и сам решил ввязаться во все это, написав блокчейн на C#. Если вам интересно, что получилось, добро пожаловать.

Не секрет, что Q# и Quantum Development Kit позволяют легко писать квантовые программы и запускать их на симуляторах и на оборудовании через службу Azure Quantum, с использованием Python, .NET или даже через Jupyter Notebook. Более того, инфраструктура, которая поддерживает все эти различные способы использования Q#, также позволяет создавать новые и захватывающие способы написания и выполнения квантовых программ. В этой статье мы немного рассмотрим эту инфраструктуру и то, как вы можете использовать эту инфраструктуру для подключения Q# к вашим любимым языкам и платформам.

Сегодня мы вновь говорим о качестве C# кода и разнообразии возможных ошибок. На нашем операционном столе – CMS DotNetNuke, в исходный код которой мы и залезем. И лучше сразу заварите себе кофе...

Сборщик мусора в .NET предрекал конец ручного управления памятью и защиту от ее утечек. Идея в том, что при наличии сборщика мусора, работающего в фоновом режиме, разработчикам больше не нужно беспокоиться о необходимости управления жизненным циклом объектов — сборщик сам позаботится о них, когда они станут не нужны.

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

Думаю, что каждый программист рано или поздно сталкивается с кодом, который работает «не так, как ты от него ожидаешь». Именно это и подтолкнуло меня к написанию следующей статьи, в которой я пытаюсь понять, почему Except в Linq работает так, как написан, а не так, как я хочу.

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

.NET Foundation – независимая организация, основанная Microsoft с целью поддержки open source проектов на платформе DotNet. Под их крылом на данный момент собралось множество библиотек, некоторые из которых уже проходили проверку анализатором PVS-Studio. Следующим проектом для проверки анализатором будет LINQ to DB.

Давным-давно наш коллега @novar разместил на Хабре статью с описанием вот такого незатейливого ТЗ, полученного им от потенциального работодателя:

Реализовать класс для задания и расчета времени по расписанию. Расписание задано в стиле crontab (точный формат см. во вложении), требуется находить ближайшие в будущем или прошлом моменты, попадающие в это расписание. Обращаю Ваше внимание, что класс должен быть эффективным и не использовать много памяти и ресурсов даже тогда, когда в расписании задано много значений. Например очень много значений с шагом в одну миллисекунду.

Хочу предложить алгоритм, приближающийся к O(1) во всех возможных ситуациях, вместо оригинального O(n). Интересующихся прошу под кат.

Ах да. Если вы тот самый работодатель, вот готовый код под ваше ТЗ. Правда на Java, а не на C#. Но вы же не думали, что всё будет так просто?

Еще один курс по C# в онлайн формате. В чем фишка?

Если кратко, то в том, чтобы продолжать заниматься любимым делом - развивать лучший курс для начинающих разработчиков на C# :).

Veeam Академия стартовала в 2017 году и всегда проводилась исключительно в очном формате. Мы всегда были жестко ограничены по времени. Весь курс нужно было уложить в осенний или весенний семестр, чтобы ребята смогли успеть уйти на сессию в своих ВУЗах. Таким образом, в нашем распоряжении было не более четырех месяцев, из которых пара недель выпадала на организационные мероприятия.

Нас часто спрашивали, почему нет Veeam Академии в онлайн формате. Желание сделать онлайн версию курса зрело давно, но "Интенсив по программированию на C#" был настолько интенсивным, что все такие темы каждый раз приходилось откладывать на потом. А полтора года назад известные пандемийные события закрыли нам доступ в класс, и мы поняли, что пора заняться онлайн форматом. Так что мы заперлись по домам и принялись за дело.

Опытные .NET-разработчики знают, что даже несмотря на наличие в .NET сборщика мусора (Garbage Collector), утечки памяти все равно возникают с завидной регулярностью. Утечки возможны не из-за ошибок в сборщике мусора, а потому что даже в управляемом коде есть множество способов их появления.

В этой статье мы пройдемся по наиболее частым причинам возникновения утечек памяти в .NET-приложениях. Все примеры написаны на C#, но описанные проблемы и способы их решения справедливы и для других .NET-языков.

Не все тестовые задания удостаиваются внимания на Хабре. Почему — примерно, понятно. Однако бывают исключения. Так, некоторое время тому назад одно, в общем-то, ничем не примечательное тестовое задание на Хабре породило аж целых две статьи про него.

Первая из них — "История одного фееричного провала тестового задания на C#" — была написана в жанре пространной жалобы соискателя на невежливый ответ (дословно: "отвратительно, халтурно") нанимателя на решение тестового задания, которое автору дали при попытке устройства на работу. В принципе, у меня эта статья особого интереса не вызвала: там было вполне рабочее решение — но без всякого блеска и с явными следами торопливости (похоже, именно они не понравились нанимателю) — не слишком интересной задачи — сделать класс, разбирающий строку расписания в cron-подобном формате и реализующий методы поиска в этом расписании.

Однако через некоторое время на Хабре появилась вторая посвященная этому тестовому заданию статья. Его решение в той статье было с монадами и goto, и оно произвело на меня сильное впечатление. Первая мысль после прочтения у меня была "Круто!" (или, как выразился автор первого же комментария "Шикарно"). В частности, одна из примечательных особенностей решения — использование для разбора строки не своего "велосипеда", а хорошей сторонней библиотеки.

Тем не менее, на второй взгляд все оказалось не так хорошо, на как на первый. Та часть решения, которая представляет собой программу-разборщик строки расписания, могла быть существенно улучшена, с сокращением объема и улучшением понятности, если для этого полнее использовать методы той же самой библиотеки для построения разборщиков (ну, и не забывать, что мы пишем на языке C#). Если вам интересно, как, почему и что может быть сделано — добро пожаловать под кат.

Работа в поддержке часто воспринимается как что-то негативное. Напрасно! Сегодня мы постараемся взглянуть на неё под иным углом. За основу возьмём реальное общение: больше 100 писем в переписке, исключения, анализ, который не завершается за трое суток...

В жизни каждого инженера может произойти ситуация, когда процесс его приложения «завис» и не выполняет ту работу, которую должен. Причины могут быть разные и чтобы узнать их, нужно заглянуть во внутренности процесса и расследовать, что же там происходит. Для этого, можно снять дамп и проанализировать его. Каждый такой случай уникальный, но подходы к анализу дампов — общие. В этой статье я покажу, как расследовал одну из подобных ситуаций и пришёл к неожиданным выводам.

Расширенные настройки печати в nanoCAD являются дополнением к базовым настройкам.

Через пользовательский интерфейс nanoCAD невозможно увидеть, какая настройка является базовой, а какая – расширенной, однако при работе с API nanoCAD разница видна четко. В качестве примера можно взять настройку выравнивания области печати на листе. Если бы существовала возможность использовать только базовую настройку, то область печати удавалось бы выровнять лишь по центру листа. Расширенная настройка позволяет выравнивать область печати не только по центру, но и по сторонам листа.

В этой статье будут подробно рассмотрены настройки печати, которые относятся к расширенным, а также способы их изменения через API nanoCAD.

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

Спустя некоторое время я увидел интересный метод "12 проектов за 12 месяцев". Суть метода состоит в том, что ты каждый месяц делаешь 1 продукт и показываешь его людям. Неважно насколько он готов.

Regexoop - переосмысление подхода написания regex. 30 сентября я подумал - "Хм, regex такой сложный. НУ ПОЧЕМУ? Может его можно сделать как-то проще?".