C# *

Как известно, недавно была опубликована книга по паттернам проектирования за авторством Сергея Теплякова.

Дабы поддержать мною уважаемого нашего разработчика (сам Сергей, несмотря на переезд заграницу, всё ещё считает себя нашим — за пруфом идите к нему в блог), не пожалел денег и сразу же купил электронную версию. До этого я читал банду четырёх и Design Patterns Head First, поэтому, в принципе, есть с чем сравнить.
Книга занимает чуть более 300 страниц, что вполне можно осилить за неделю неторопливого чтения. Книга разбита на 4 части:

1. Паттерны поведения
2. Порождающие паттерны
3. Структурные паттерны
4. Принципы проектирования

.NET-конференция .NEXT, в декабре покорявшая Москву, теперь снова прошла в родном для нее Петербурге. Напрашивается вопрос: возможно ли после столичного размаха сделать питерский вариант не уступающим, или в Северной столице неизбежно труба будет пониже, а дым — пожиже? Под катом — подробный рассказ, позволяющий сделать выводы.

Всегда ли нужно использовать то, что предлагают?

Разобравшись с посетителем и слушателем, пришло время попробовать «Велосипед». Изучая способы построения внешних DSL я столкнулся с проблемой получения практики. Не буду далеко ходить книга Фаулера про то, как построить язык мечты «DSL», к сожалению, оказалась совсем не обезболивающим, а скорее на оборот тропой в кустах крапивы.

Глава 12 Symbol Table

Место для хранения во время синтаксического анализа всех
идентифицируемых объектов для разрешения ссылок.

Понятно? Конечно понятно, к описанию претензий нет.

Многим языкам приходится ссылаться на объекты во многих точках кода. Если есть
язык, который определяет конфигурацию задач и их зависимости, значит, нужен способ,
которым одна задача могла бы сослаться на зависимые задачи в своем определении.

Пришло время выложить вторую часть заметок по .NET.

Посещать или слушать? Дело вкуса – не более. Или нет?
Предыстория.

Разобрав исходный текст, на выходе образовалось дерево:



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

1. Visitor

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

2. Listener

Новшество, появившееся в четвертой версии. Поведение этого класса уже далеко не классическое (Observer или Publish/Subscribe). В классическом исполнении наблюдается менеджер который оповещает подписчиков о наступлении событий. Поведения рассматриваемого слушателя больше похоже на работу инспектора. Инспектор перед проверкой узла делает заметку “Я проверяю Х узел”, далее идет обход потомков узла, после обхода, которых можно сделать “Заключение о результатах обхода узла Х”.

1. Пролог

Несколько лет назад разработал внутренний язык для расчета отчетов, который используется в нашей фирме. Язык получился странным, в нем нет ни циклов, ни стандартных условных операторов (if), динамическая типизация, но со своими функциями он справлялся. Идея языка была реализовать простой expression evaluator. Со временем требований становилось все больше, как следствие язык стал расширяться, пришлось разработать простой сценарий добавления новых функций.

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

Добрый день! Не так давно прошла серия семинаров CLRium по новейшим технологиям и редко-раскрываемым темам CLRium #2. Мы собрали у себя в залах около 740 человек, что для нас является — фантастическим результатом. Сегодня хотелось представить вам свежие видеозаписи семинара и ссылки на репозитории спикеров:

День 1:

Ссылки с привязкой ко времени:

• Андрей Акиньшин — с самого начала
• Станислав Сидристый — .NET objects in Shared Memory

Привет, Хабр!

Не так давно я сходил на конференцию CLRium от sidristij, где увидел довольно простой и удобный способ для анализа исходного кода C# в MSVS 2015.

Задача взята из проекта, в котором я участвую: каждый аргумент со ссылочным типом должен иметь аттрибут NotNull или CanBeNull (которые потом использует ReSharper). В реальности, конечно, в самом проекты атрибуты являются только частью проверок, однако это не мешает им быть обязательными. Уже есть тесты, которые проверяют сборку и падают, если методы или конструкторы не содержат требуемых атрибутов, однако разработчики все равно довольно часто забывают их проставить, что приводит к падениям билдов, обновлению кода и т.д. Вот если бы Visual Studio вместе с ReSharper выдавали бы предупреждения, что код не совсем хороший, то можно было бы сэкономить время и нервы…

И, на самом деле, вместе с новой студией это становится возможным! Более того, сделать свои проверки нереально просто.

Исходный код можно посмотреть тут.

Думаю, многим хорошо знаком класс DataTable. Вычитывая из БД на клиент большие таблицы через ADO.NET, иногда приходится продлевать время жизни экземпляров этого класса на продолжительное время. Например, если нужна обработка и анализ полученных данных, не прибегая к ORM материализации (да, лучше бы это делать в БД, но далеко не всё порой удаётся туда вынести). Когда объём данных невелик, то особой проблемы с этим не возникает. Однако на широких таблицах с большим числом строк можно получить довольно толстые объекты в памяти. Сопоставив объём данных, приходящих из БД, и размер получаемого DataTable, можно прийти к двум выводам:

• При больших объёмах varchar данных, среди которых есть дублирование, можно попробовать организовать некое подобие интернирования строковых данных внутри DataTable;
• DataTable содержит довольно увесистую внутреннюю инфраструктуру. Манипулируя с типами данных и числом строк в таблице, удалось установить, что процент накладных расходов составляет 15-20% для таблиц от 100 тыс. записей. Большая часть инфраструктуры обеспечивает корректное редактирование и прочий функционал таблицы. В случае, когда вам требуется, чтобы DataTable был простым контейнером для данных, полученных из БД, то можно написать лёгкий выпотрошенный аналог этого класса.

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

Не так давно столкнулся по службе с весьма любопытной задачей. Но нет ничего нового под луной — и задача вам давно знакома: двойная диспетчеризация в C# в терминах статической типизации. Подробнее объясню ниже, но тем, кто и так всё понял, скажу: да, я буду применять «посетителя», но довольно необычно.

Ещё несколько оговорок, перед тем, как сформулировать задачу строже: я не буду останавливаться на том, почему мне не подходят dynamic, явная проверка типов через приведение и рефлексия. Тому две причины: 1) цель — избавиться от runtime исключений 2) хочу показать, что язык достаточно выразителен, даже если не прибегать к перечисленным средствам и оставаться в рамках строгой типизации.

Неделю назад я рассказал о том, что будет твориться в следующую пятницу на питерской конференции .NEXT до обеда: открытие конференции, keynote от Dino Esposito и 9 докладов. Сегодня я расскажу о том, что нас ждет во второй половине дня.

Уважаемые читатели! Представляю вашему вниманию перевод статьи Скота Ханселмана под названием "Proper benchmarking to diagnose and solve a .NET serialization bottleneck".

Для начала, несколько оговорок и комментариев. Во-первых, процесс оценки производительности сложен. Трудно выполнять измерения. Но настоящая проблема состоит в том, что часто мы забываем, ДЛЯ ЧЕГО мы оцениваем производительность чего-либо. Мы берем сложную многомашинную финансовую систему и внезапно чрезвычайно фокусируемся на куске кода, выполняющем сериализацию, который, по нашему убеждению, и ЕСТЬ проблема. «Если я смогу оптимизировать эту сериализацию, написав for-цикл из 10000 итерации и сократив время его выполнения на x миллисекунд, все будет путем».

До очередной питерской конференции .NEXT осталась буквально пара недель. Сегодня я сделаю традиционный обзор докладов. А точнее, половины из них. Мы пойдем по временной шкале, продвигаясь по программе от забора открытия до обеда.



10:00 – 10:25 — Открытие конференции
Традиционный для нас формат конференции начинается с «церемонии открытия». Организаторы (обычно это я и real_ales, реже jetliner) поприветствуем участников (вас) и обозначим основные положения: формат конференции, устройство площадки, чего от кого ожидать и на что надеяться.

После нашей пятиминутки слово перейдет к спонсорам, которые рассказывают о том, какие они классные и, самое для меня загадочное, зачем они спонсируют .NEXT. В принципе, с ними все и так понятно — Михаил Самарин из финского Futurice коротенько расскажет о том, как классно работать у них в Хельсинки на крупнейшие мировые бренды, а парни из JetBrains (обычно это mezastel) прибавят к рассказу о карьерных возможностях пару слов о своих замечательных тулах.

Написано не мало хороших статей на тему «Что, как и где кешировать». Так почему же ещё раз мусолить эту тему? А потому что тема достаточно важная, а многие, пока не столкнуться с конкретными проблемами, не считают нужным с ней разбираться. Так что аудитория, на которую я рассчитываю, это те, кто к моменту выхода уже существующих статей были в них не заинтересованы, но сейчас интерес есть, и они не пройдут мимо.

Я постараюсь кратко осветить основные моменты организации кеширования, после чего рассмотрю новшества .Net Framework 4.0, которые должны упростить жизнь разработчиков (речь пойдёт о In-memory кеше вне ASP.NET инфраструктуры).

Эта небольшая статья поможет:

• Ознакомиться с событийной моделью построения проектов и решений MS Visual Studio;
• Понять, как получить поддержку Command-Line режима devenv.exe для VSPackage (где он изначально не предусмотрен);
• Понять, как эмулировать схожую модель событий от MSBuild Tools и транслировать на главный плагин;
• Узнать, как работать по приоритетной подписке;
• Узнать варианты получения контекста построения при обработке событий Visual Studio / MSBuild Tools;
• Узнать об оценке MSBuild Property & MSBuild Property Functions;
• Получить общие сведения межмодульного взаимодействия на слое абстракции для разнородных компонентов системы.

Синопсис

Мне довольно часто приходиться заниматься автоматизацией тех или иных процессов, поэтому не мудрено, что часть решений рано или поздно коснулись и Visual Studio.

На самом деле, эта статья, или даже заметка — результат рабочего и уже давно написанного плагина, который еще года 2 назад являлся лишь побочным продуктом при работе над одним проектом на C++. Однако мой дебют на Хабрахабре будет, пожалуй, с этого.

Для кого эта статья

Странно говорить о таких понятиях, как расширение функционала такого продукта, как Visual Studio в контексте «для чайников», но есть люди, которые и журналы смотрят с последней страницы. Эта статья для тех, кто уже имеет представление как обращаться со студией, но пока мало знает, чем она может помочь, и уже очень хочется добавить свою фичу.

Ожидаемые результаты

Научиться создавать и встраивать VSPackage расширения в VS 2012, на примере расширения для запуска калькулятора прямо из студии.

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

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



У меня есть некоторые свои собственные соображения и наработки для решения этой проблемы в рамках своей специальности — способа изучения языка программирования C#, речь пойдёт о проекте www.videosharp.info

Создание Windows Runtime (WinRT) в качестве API, с одной стороны, можно только приветствовать, так как предыдущий — WinAPI — особой простотой и человеколюбием не отличался. С другой стороны, в полный рост при этом всплывает проблема обратной совместимости. Что делать, если нужно заиспользовать какую-то приятную мелочь, появившуюся в Win8, но при этом не терять совместимости с Win7, все еще бодро шагающей в строю?

Официальный MSDN к этому относится весьма однозначно: если нужен WinRT, то забываем про версии Windows, старше восьмерки; если нужно поддерживать всякое старье, то собираем приложение отдельно без упоминания об WinRT. Такие вот простые и незатейливые парни работают в Microsoft. Тем не менее, решение проблемы, причем достаточно простое, удалось отыскать.

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

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

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

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