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

Если юнит-тестирование — неотъемлемая часть вашего процесса разработки, значит вы регулярно запускаете многочисленные тесты проверяющие функциональность приложения. А теперь представьте, что вы можете написать некие специальные «тесты на использование памяти». Например, тест, обнаруживающий утечку при помощи проверки памяти на наличие объектов определенного типа, или тест, который отслеживает трафик памяти и «падает», если трафик (аллоцированный объем) превысит заданный порог. Это в точности то, что позволяет делать dotMemory Unit фреймворк. dotMemory Unit распространяется в виде NuGet пакета и позволяет выполнять следующие сценарии:

• Проверка памяти на наличие объектов определенного типа.
• Проверка трафика памяти.
• Сравнение снимков (далее 'снэпшотов') памяти.
• Сохранение снэпшотов на диск с целью последующего анализа в dotMemory (профиляторе памяти от JetBrains).

Иными словами, dotMemory Unit расширяет возможности вашего юнит-тестинг фреймворка функциональностью профилятора памяти.

Введение

На сегодняшний день QR-коды (quick-response) широко используются в различных сферах. Структура QR-кода была разработана в Японии Масахиро Хара.

Хочу поделиться с читателями «Хабрахабра» способом формирования QR-кода в формате машинной вышивки Tajima DST. Данный метод позволяет исключить ручные операции по формированию QR-кода и последующего преобразования полученной картинки в дизайн машинной вышивки. Если у вас или ваших знакомых есть вышивальная машина, то загрузив полученный файл в память машины и выполнив вышивку, можно получить следующее:

29 апреля 2015 года в Москве прошла бесплатная конференция сообщества SkillsWiki о профессиональном развитии.

Что интересного было на конференции? Какие навыки требуются от .NET-разработчика на американском рынке? Вы смогли бы оценить, шагаете ли вы в ногу со временем. Только ли знания и навыки определяют уровень вашей заработной платы, или есть еще важные факторы, которые определяют вашу ценность с точки зрения работодателя? Как говорить с работодателем о вашем росте и повышении заработной платы?

Не смогли принять участие в конференции? Ничего страшного. В этой заметке представлены все материалы конференции. Но в будущем не пропускайте наши конференции и вступайте в сообщество SkillsWiki!

Эта статья — продолжение статьи C#: коллекции только для чтения и LSP. Сегодня мы посмотрим на интерфейс IEnumerable с точки зрения принципа подстановки Барбары Лисков (LSP), а также разберемся, нарушает ли этот принцип код, имплементирующий IEnumerable.

Итак, в воскресенье я выложил на хабре видео докладов, занявшие в рейтинге места с 6го по 10ое. Пришло время опубликовать доклады из первой пятерки.

5 место

Дмитрий Сошников, Microsoft — Функциональное реактивное программирование на F#

Средняя оценка: 4.44



В отличие от большинства докладов про F#, этот доклад — практический. Дмитрий делает обзор языка, показывая несколько демо:

• вычисление доброты романа «Война и мир»
• вычисление доброты твиттера
• вычисление корреляции между автомобильными авариями и алкогольным опьянением
• и разумеется, управление роботом

С одной стороны, монады, Y-комбинатор и неподвижные точки, а с другой — котики и доброта твиттера. Так и живем.

Обратный отсчет перед очередной конференцией .NEXT давно запущен. Пришло время рассказать о тех докладах, которые были на декабрьской конференцией в Москве. Причем рассказывать будем сразу о лучших из них, чтобы не тратить ваше время. Методика выбора лучших описана подробно в предыдущем посте.



Сегодня я расскажу о местах во второй половине первой десятки. Как всегда, в обратном порядке.

OrmLite — это дружелюбная micro-ORM с открытым исходным кодом и коммерческой лицензией (бесплатна для небольших проектов с ограничением в 10 таблиц). Входит в состав известного фреймворка ServiceStack (и обладает высокой производительностью — взгляните на benchmark от разработчиков Dapper). В данной статье мы рассмотрим основы работы с OrmLite в связке с SQL Server. Если сравнивать OrmLite и Entity Framework, то сразу бросается в глаза отсутствие контекста и отслеживания изменений (change tracking). И это далеко не единственные отличия.

План статьи:

• Подготовка к работе. Code-first и database-first подходы
• Запросы к БД
• JOIN и navigation properties
• Lazy и Async
• Транзакции
• Сравнение производительности OrmLite и Entity Framework
• Заключение

Заинтересовавшихся приглашаю под кат.

Продолжая серию статей о новшествах в С#7, акцентирую внимание на, пожалуй, главных нововведениях — Pattern matching и Record type(Примерный перевод «регистрируемые типы»). Эти функционалы дополняют друг друга, поэтому лучше рассказывать о них вместе.

Очередная конференция .NEXT состоится уже через месяц в Питере. Пришло время провести небольшую ретроспективу докладов и показать вам, какие доклады стали лучшими в Питере год назад.

Как мы собираем фидбэк

После каждой из конференций мы собираем фидбэк с участников, рассылая им в почту анкету. Мы просим участников оценить каждый из посещенных докладов по «школьной» шкале:

• плохо — 2 балла
• нормально — 3 балла
• хорошо — 4 балла
• отлично — 5 баллов

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

Вы успеваете отслеживать все свежее, что происходит в мире .NET в последнее время? Выход своей мини-IDE под Linux и MAC OS? Забор исходников от referencesource в проект Mono 4? Более ранний релиз C# 6 под mono, чем под .NET в Windows? Даже гуру .NET не успевают все узнать, чего уж говорить про разработчиков, у которых помимо работы есть множество семейных проблем? Как раз чтобы решить все проблемы такого рода, придуманы конференции и семинары. И в особенности — семинары, где в отличии от конференций упор сделан — на код и практику.

В Москве семинар собрал 380 разработчиков всех уровней познания платформы .NET, на котором были не только граждане РФ, но также присутствовали гости из Штатов, Германии, Чехии, Украины и Белоруссии.

Приглашаем на семинар по платформе .NET в Санкт-Петербурге, который пройдет уже совсем скоро — 29-30 мая. Подробности:

Требования

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

• самозацикленные графы объектов (деревья с back-references)
• массивы структур (value types)
• классы/структуры с readonly полями
• инстансы существующих .Net коллекций (Dictionary, List), которые внутренне используют custom-сериализацию
• большое кол-во инстансов типов, специализированных для конкретной задачи

Речь пойдёт о трёх аспектах, которые очень важны в распределённых кластерных системах:

• скорость сериализации/десериализации
• объём объектов в сериализированном виде
• возможность использовать существующие объекты без надобности “украшения” этих объектов и их полей вспомогательными атрибутами для сериализации

Я бы хотел обсудить подводные камни, которые наиболее часто встречаются при работе с фичей async/await в C#, а также написать про то, как их можно обойти.

— Сделали поддержку C# 6 по-умолчанию
— Потюнили в плане улучшения производительности GC и рантайм
— Ускорили операции с float на 30-40%
— Добавили поддержку PowerPC64 LE
— И, самое главное импортировали очень большой кусок BCL из .NET Framework.

Камень преткновения — GC

Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

Но проблема всё равно есть в тех случаях, когда объекты должны жить долго. Например, кэш. В нём должны находиться миллионы объектов. Особенно, учитывая возрастание объемов оперативки на типичном современном серваке. Получается, что в кэше потенциально можно хранить сотни миллионов бизнес-объектов (например, Person с дюжиной полей) на машине с 64GB памяти.

Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
Что же делать? Не хранить много объектов долго?

Зачем

Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

Вот другая задача. Кэширование социальных данных, которых скапливаются сотни миллионов за 2-3 недели, а обслуживать необходимо десятки тысяч read-запросов в секунду.

Сегодня Microsoft анонсировала запуск Visual Studio Code. Это кроссплатформенный редактор для работы с современным стеком .NET. Visual Studio Code будет работать в OS X, Linux и Windows. Приложение уже доступно для скачивания.

Visual Studio Code может похвастаться всеми возможностями, что присутствуют в современных редакторах, включая автодополнение, сниппеты и поддержку систем контроля версий. Редактор поддерживает несколько языков и технологий, среди них: JavaScript, TypeScript, Node.js, C# и ASP.NET 5.



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

Еще не было официального релиза C# 6 и его нового компилятора «Roslyn», а уже становятся известны подробности следующей редакции — C# 7. И она обещает нам много всяких «вкусностей», которые должны облегчить наше с вами существование. Хотя это все пока предварительно, но все равно интересно, чем нас порадует Microsoft в не совсем ближайшем будущем.

О реализации этого алгоритма шифрования уже рассказывал FTM: как в общем и целом, так и про режим простой замены. После изучения существующих библиотек и отдельных реализаций этого ГОСТа на C# я решил написать свой велосипед, в первую очередь, ради интереса и опыта. Результатами этой работы мне и хотелось бы поделиться с уважаемым сообществом.

Все что нам понадобится для отправки SMS это 3G USB модем, SIM карта, Visual Studio и немного времени. Моей целью не является описать все возможные настройки COM порта или формата PDU. Я хотел бы предоставить вам готовое решение, которое можно использовать в качестве сниппета в своих проектах.
В качестве примера рассмотрим 2 консольных приложения. Почему консольных? Да потому, что в них нет ничего лишнего и проще разобрать код. Почему два? Потому, что есть два распространенных варианта отправки сообщений. Самый простой вариант – это отправка сообщений в текстовом режиме. Минусом этого варианта является то, что он не поддерживает отправку кириллицы. Плюсом то, что возможна отправка 160-ти символов. Второй вариант, более сложный, позволяет отправлять текст длиной до 70-ти символов в формате Unicode.

Здравствуйте, уважаемые Хаброобитатели!

UPD
Могу всех порадовать. Мы приступаем к переводу Unity in Action: Multiplatform Game Development in C#. Постараемся все сделать как можно быстрее, но при этом качественно.

Пришла нам в голову безумная мысль, а не пора ли перевести на русский язык книгу по Unity? Тем более сейчас, когда доступна полноценная пятая версия (да еще и бесплатно).
Книг на английском языке вышло немало, но хочется выбрать не слишком старую и самую интересную.
Если мы упустили что-либо интересное, напишите в комментариях, будем рады.

Средства LINQ позволяют .Net-разработчикам единообразно работать как с коллекциями объектов в памяти, так и с объектами, хранящимися в базе данных или ином удаленном источнике. Например, для запроса десяти красных яблок из списка в памяти и из БД средствами Entity Framework мы можем использовать абсолютно идентичный код:

List<Apple> appleList; 
DbSet<Apple> appleDbSet;
var applesFromList = appleList.Where(apple => apple.Color == “red”).Take(10);
var applesFromDb = appleDbSet.Where(apple => apple.Color == “red”).Take(10);

Однако, выполняются эти запросы по-разному. В первом случае при перечислении результата с помощью foreach яблоки будут отфильтрованы с помощью заданного предиката, после чего будут взяты первые 10 из них. Во втором случае синтаксическое дерево с выражением запроса будет передано специальному LINQ-провайдеру, который транслирует его в SQL-запрос к базе данных и выполнит, после чего сформирует для 10 найденных записей объекты С# и вернет их. Обеспечить такое поведение позволяет интерфейс IQueryable<T>, предназначенный для создания LINQ-провайдеров к внешним источникам данных. Ниже мы попробуем разобраться с принципами организации и использования этого интерфейса.