C# *

Конференция DotNext 2015 Moscow уже скоро! Мне посчастливилось быть в программном комитете этого замечательного мероприятия, так что я теперь в курсе закулисной деятельности: наблюдаю за общей организацией и помогаю готовить доклады. Организаторы долгими неделями трудятся с утра и до вечера, чтобы у вас была возможность на один день погрузиться в уникальную атмосферу: послушать крутые доклады, пообщаться с умными людьми, завести полезные знакомства, покушать вкусной еды, вдохновиться на великие свершения и просто хорошо провести время.

Впрочем, самым важным на конференции является не атмосфера, а контент. В этом году программа очень насыщенная: 22 докладчика (из которых 7 являются MVP) будут в 4 потока целый день рассказывать вам про .NET. Темы будут самые разные: есть доклады про новинки .NET-мира, про современные подходы и тенденции разработки ПО, про использование хороших библиотек/инструментов и про много чего ещё. Но моя любимая тема — это внутренности .NET, потроха рантайма и прочий хардкор. Мне кажется, что рано или поздно каждый сеньор разработчик приходит к осознанию того, что для разработки действительно сложных продуктов явно не помешает понимать, что же происходит под капотом наших программ. Увы, разбираться с этим самостоятельно зачастую долго и сложно: слишком уж много всего надо изучить. Поэтому с каждой следующей конференцией DotNext мы повышаем градус хардкора и пытаемся умудриться в течение одного дня загрузить в оперативную память разработчиков максимальное количество интересной и полезной информации о том, что же на самом деле делают наши приложения и как их лучше писать.

По долгу служебных обязанностей я уже послушал почти все доклады (каждый докладчик подвергается серии изнурительных прослушиваний, тренировок и тренингов с целью повышения качества материала и изложения), так что хорошо представляю, что же вас ждёт через две недели. А сегодня мне бы хотелось немного поговорить про доклады с тэгом hardcore. Если вы любите разбираться с рантаймом также, как люблю это я, то крайне рекомендую посетить шесть нижеприведённых докладов.

Всем привет. Это снова «Без слайдов», и сегодня у меня для вас интервью с Дмитрием Нестеруком aka mezastel, техническим евангелистом компании JetBrains. Дмитрия я знаю довольно давно и, не скрою, сам очень долго ждал момента, когда мы наконец поедем на студию и запишемся. Уж больно много вопросов у меня к нему накопилось.



Мы больше часа беседовали с Дмитрием, но не успели затронуть даже половины тем, которые хотелось обсудить. Что Дмитрий успел рассказать мне:

• Чем технический евангелист отличается от Developer Advocate
• Как работает евангелизм в JetBrains
• О восприятии мира настоящими гиками
• Почему IT — это бедная индустрия
• Про маржу и инвестиции российских аутсорсеров
• Про то, какие enterprise решения позорят индустрию и почему
• Насколько далека JetBrains от своего простого потребителя
• Об том, как индустрия видеоигр смогла «вырастить» под себя целый сектор железа
• Что сейчас творится на рынке видеокарт
• Что еще могут придумать компании, для того, чтобы программы работали быстрее
• О том, как будет выживать ReSharper и о 64-битных IDE от Microsoft

Вот видео, а под катом, как обычно, текстовая версия этого интервью.


(на одиннадцатой минуте нет звука, к сожалению.)

Введение

В своих статьях о переходе на российский микроконтроллер К1986ВЕ92QI я ни раз рассказывал о генерации звука средствами микроконтроллера. Тогда передо мной стояла задача лишь воспроизвести данные. Для создания этих самих данных, получаемых из MIDI файлов, использовались весьма экзотические методы, например, как в этой статье. Да, подобные методы имеют право на жизнь, если требуется получить данные для воспроизведения пару раз в жизни. Но так как я достаточно часто сталкиваюсь с задачами, когда на контроллере нужно получить достаточно сложный звук, или же звук — лишь дополнительная опция, то задача преобразовывать MIDI файлы такими экзотическими способами, становится весьма нетривиальной. В этой небольшой серии статей я поставил для себя задачу создать (а за одно и подробно рассказать о процессе создания) универсальную программу для преобразования MIDI файлов в приемлемый для микроконтроллера формат, а так же генерирующую все необходимые для микроконтроллера данные инициализации.



Итогом данной статьи станет реализация основного функционала программы: создание массивов нота-длительность, созданного из MIDI файла. Кто заинтересовался — прошу под кат.

Привет, ребята! Многим, наверно, неудобно обращаться к Dispatcher каждый раз, когда нужно обновить контрол с не UI-потока в WPF… в общем, меня это конкретно достало, поэтому написал очень простенький extension-метод, которым и хочу поделиться с вами всеми:

static class exMethods
{
async public static void ThreadSafeUpdate(this System.Windows.Controls.Control @this, Action updateLogic)
        {
            await @this.Dispatcher.BeginInvoke(updateLogic);
        }
}

Работает вот так:

this.ThreadSafeUpdate(() => this.Visibility = Visibility.Hidden);

Расширяем функционал EPLAN при помощи Add-Inов на C#

EPLAN – это платформа для сквозного проектирования, охватывающая следующие отрасли: электротехника, КИПиА, гидравлика/пневматика и механика (проектирование шкафов и жгутов). Благодаря открытой архитектуре и стандартным интеграционным модулям EPLAN может быть экономически эффективно интегрирован с большим спектром сторонних решений: системами механического проектирования, ERP и PDM системами, системами проектирования зданий, промышленных производств и кораблей.

Для начала хочу определить, что в данной статье понимается под модульным приложением. Так вот, модульным приложением будем считать такое приложение, которое состоит из т.н. шелла и набора подключаемых модулей. Между ними нет прямой зависимости, только через контракты. Это позволяет независимо вносить изменения в каждый из компонентов, менять их состав и т.д. Думаю, всем и без меня прекрасно известны преимущества модульной архитектуры.



Пожалуй, самым известным фреймворком для создания WPF приложений с такой архитектурой является Prism. В данной статье я не буду проводить сравнительный анализ, т.к. не имею опыта использования Prism. После прочтения туториала, Prism со всеми его регионами, мефом и прочими артефактами, показался мне сильно усложнённым. Если читатель, знающий Prism, обоснованно укажет мне на мою неправоту и преимущества данного фреймворка — буду признателен.

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

С подобными задачами сталкиваешься редко, однако если это происходит, очень приятно прочитать исчерпывающую статью, которая поможет быстро начать продуктивную работу, а не ломать целый день голову вопросами «Что скачать?», «Где найти?», «Как это вообще работает?». У меня подобная задача возникла в рамках разработки автоматизированного стенда для тестирования плат. В процессе ее решения возник ряд проблем, а информации в интернете по этому поводу достаточно мало ввиду узости проблемы. Данная статья максимально подробно и емко описывает основные моменты для быстрого начала работы с осциллографами Tektronix из Visual Studio.

До единственной в России .NET-конференции DotNext осталось всего ничего — две с половиной недели. Программа конференции сформирована, и мы с гордостью вам ее представляем:

• 26 докладов — 2 кейноута и 24 сессионных.
• 22 спикера, из которых семеро(!) носят звание Microsoft MVP
• 4 зала, в которых доклады будут идти параллельно.

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



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

Месяц назад я анонсировал первые 7 из них, а сейчас пришло время коротко пробежаться и по остальным.

Введение

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

C# и app.config

На хабре уже была посвящена этому тема, поэтому… перейти

C# и Properties.Settings

Информация о Properties.Settings

Организация Properties.Settings — это обычный xml файл, который можно найти в папке пользователя:

С:\ Users \ [user name] \ AppData \ Local \ [ (Project Name) or (AssemblyCompany) ] \ [name project_cashBuild] \ [AssemblyVersion] \ user.config

Для начала нам нужно создать такие переменные для Properties.Settings. Перейдем в Properties -> Settings.settings:

Допустим, есть проект на WPF и в нём ViewModel, в которой есть два свойства Price и Quantity, и вычислимое свойство TotalPrice=Price*Quantity



Если Price будет изменен в коде, то изменения цены автоматически отобразятся в View, потому что ViewModel сообщит View об изменении Price посредством вызовом события RaisePropertyChanged(«Price»). Вычисляемое TotalPrice же не изменится в View, потому что никто не вызывает RaisePropertyChanged(«TotalPrice»). Можно вызывать RaisePropertyChanged(«TotalPrice») в тех же местах, где вызывается RaisePropertyChanged(«Price») и RaisePropertyChanged(«Quantity»), но не хотелось бы размазывать по множеству мест информацию о том, что TotalPrice зависит от Price и Quantity, а хотелось бы хранить информацию об этом в одном месте. С этой целью люди пишут разнообразные менеджеры зависимостей, но давайте посмотрим какой минимальный код на самом деле нужен для этого.

Цель: написать, протестировать и развернуть простейший плагин для R#, содержащий пользовательские Quick-Fix и Context Action.

План статьи:

1. Настройка среды разработки
2. Пример №1: простейшее расширение-заглушка
3. Установка плагина
4. Отладка, полезные советы
5. Пример №2: модификация кода с помощью R# API
6. Функциональное тестирование плагинов средствами R# API

В ролях:

Visual Studio 2015
ReSharper Ultimate 10

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

Казалось бы, данный шаблон не просто прост, а очень прост, подробно разобран не в одной известной книге.

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

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

Мотивация на примере моделей представлений для WPF UI

Начать обсуждение и познакомиться с обсуждаемой проблематикой предлагается на примере подхода к архитектуре пользовательских интерфейсов в WPF.

Как известно, одна из главных фич WPF — это мощная система байндингов, позволяющая достаточно легко отделить модель представления (далее модель) от самого представления (далее View) как такового. Обычно программист создает XAML для представления, привязывает свойства его элементов к модели в том же XAML посредством байндингов и, фактически, забывает о View. Это становится возможным поскольку большинство UI-логики может быть реализовано через воздействие на модель и автоматически прокинуто на UI посредством байндингов. При таком подходе модель играет роль состояния View, являясь его прокси для слоя, реализующего UI-логику. Например, меняя свойство модели, мы тем самым меняем соответствующее ей свойство View (или его элементов). Последнее происходит автоматически благодаря системе байндингов, которая отслеживает изменения как в модели, так и во View, синхронизируя состояния на обоих концах по мере надобности. Одним из способов, посредством которых модель может сообщить наблюдателю (коим в нашем случае является байндинг) о своем изменении, является бросание события PropertyChanged с именем изменившегося свойства в качестве параметра. Это событие принадлежит интерфейсу INotifyPropertyChanged, который, соответственно, должен быть реализован в модели.

Рассмотрим описанную идею на конкретном примере. Начнем с простой модели, которая представляет собой некий Заказ и содержит два свойства — Цена и Количество. Оба свойства будут изменяемыми, поэтому для каждого нужно реализовать нотификацию об изменении. Это делается следующим кодом:

Три дня назад я рассказал о тех докладах конференции DotNext 2015 Piter, которые, согласно опросу участников, заняли места с 6 по 10. Теперь пришло время рассказать про лучшую пятерку докладов.

---

5 место

Кирилл Скрыган, JetBrains — ReSharper vs. Roslyn
Средняя оценка: 4.33



Казалось бы, ReSharper — плагин к Visual Studio, который расширяет возможности IDE. Roslyn — компилятор (набор компиляторов). Что общего?

Дело в том, что для того, чтобы делать все возможные рефакторинги, подсказки и пр., ReSharper строит собственную модель, собственное синтаксическое дерево. А значит, в нем есть, фактически, половина компилятора, компиляторный front-end. А значит, его можно сравнить с фронтэндом Roslyn, что Кирилл и сделал в этом докладе.

Акценты Кирилл расставил не в пользу Roslyn:

• ReSharper на 10 лет старше, в нем гораздо больше фич
• Roslyn работает только для C# и VB, никаких JavaScript и прочих прелестей
• синтаксическое дерево у ReSharper изменяемое и поэтому быстрое, а у Roslyn неизменяемое, генерит много memory traffic и поэтому медленное.

Основной вывод, который сделал я — Roslyn еще пока довольно сырой продукт, а почти все описанные Кириллом болезни — «детские». Пройдет время и наверняка от всех от них Рослин избавится. Ну а что будет на самом деле — покажет время.

Привет хабр! Основная речь пойдет про разработку на .Net, то есть с использованием Microsoft Visual Studio, ReSharper, Nuget и пр.
Я думаю, многие из вас разрабатывали большие решения (в msdn — solution), со множеством подпроектов. И в этом случае нередко становилась проблема синхронизации Nuget пакетов, настроек сборки и т.д. Причем, ReSharper здесь поможет слабо, разве что он тоже начнет путаться во множестве используемых библиотек.
Чтобы проверять исходный код, было сделано Open Source решение — SolutionCop, которое бесплатно для использования.
Для начала приведу парочку примеров, когда не помешали бы проверки наших решений.

Пример 1: разные версии Nuget библиотек.

Например, есть три проекта: exe, dll1 и dll2. exe ссылается на обе библиотеки, каждая из них ссылается, например, на RX. Но dll1 использует RX 2.2.0, а dll2 — RX 2.2.5. На деле, далеко не сразу можно получить ошибку, так как сигнатуры функций более-менее совпадают, более того, MsBuild чаще всего собирает проекты в одном и то же порядке. Однако подобная конфигурация может привести к проблемам, которые появятся после deployment'а, когда все модульные тесты пройдут (т.к. они ссылаются только на свою библиотеку), и когда будет готовиться результирующий набор файлов.

Пример 2: проект ссылается на библиотеку напрямую, а не через Nuget.

Опять возьмем три наших проекта: exe, dll1 и dll2. Допустим, мы также используем еще Jetbrains.Annotations, чтобы размечать код NotNull/CanBeNull аттрибутами и получать симпатичный статический анализ. Но вот незадача: для dll1 мы честно скачали пакет версии 9.2.0, а в dll2 мы просто попросили ReSharper добавить ссылку, что он и сделал. В итоге, в packages.config файле dll2 нет пакета с аттрибутами, а значит, если проект будет собираться в порядке dll2 --> dll1 --> exe, то мы получим ошибку, ведь Nuget пакет скачается только при сборе dll1!

Сейчас команда PVS-Studio активно занимается разработкой статического анализатора C# кода. Мы планируем выпустить первую версию анализатора к концу 2015 года. А пока моя задача — написать несколько статей, чтобы заранее заинтересовать C# программистов инструментом PVS-Studio. Сегодня мне выдали обновлённый инсталлятор. Теперь стало возможным установить PVS-Studio с поддержкой C# и даже что-то проверить. Я не замедлил этим воспользоваться и решил проверить первое, что подвернется под руку. Первым подвернулся проект Umbraco. Конечно, пока текущая версия анализатора умеет мало, но этого мне уже сейчас хватит для написания маленькой статьи.

C июня этого года мы начали проводить митапы SPB .NET Community в Санкт-Петербурге и за это время у нас скопилось немало видео, которым я и хочу поделиться. Кому интересно посмотреть доклады про новшества в Visual Studio 2015, безопасность платформы ASP .NET, детали разработки многозадачных приложений и про взаимодействие с unmanaged миром из C#, прошу под кат.

В июне в Петербурге прошла третья по счету конференция DotNext, а уже через месяц в Москве пройдет четвертая — DotNext 2015 Moscow. Видеозаписи всех докладов и круглых столов питерской конференции мы опубликовали отдельным плейлистом на YouTube. Ну а чтобы вы не теряли время попусту и сразу начинали с самого сладкого — я заморочился с различной (не очень сложной) аналитикой и разобрал для вас десяток топовых докладов, тех, которым участники конференции поставили наивысшие оценки.

Как всегда, для наших оценок мы используем российскую академическую шкалу:

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

В этом посте я коротко расскажу о докладах, занявших в нашем рейтинге места с шестого по десятое. И начнем мы, как всегда, с конца.

---

10 место

Михаил Самарин, Futurice — Универсальные приложения для Windows 10
Средняя оценка: 4.19



Михаил — не только бизнес-директор финской компании Futurice, но еще и трижды Microsoft MVP, и поэтому имеет право выступать на конференциях чуть ли ни от имени Microsoft. Так получилось и на этот раз — Михаил выступил с обзорным докладом о том, как с выходом новой версии .NET и Windows 10 изменилась разработка под различные девайсы.

Как и было обещано, доклад получился обзорным. Сначала Михаил рассказал про инструменты разработки — Visual Studio 2015 и различных лицензиях на нее, Microsoft Expression Blend, изменениях в VS, которые появились для удобства разработки под мобильные устройства. Дальше речь пошла о новой схеме «версионирования» Windows, универсальных приложениях и решениях, которые принимает рантайм в зависимости от платформы, на которой выполняется приложение (теперь единый солюшен на все платформы, а не по одному для каждой). После этого речь пошла про различные расширения платформы и того, как система сборки работает с ними. Ну и ближе к концу речь пошла про адаптивный UI, физические и effective пиксели (теперь рекомендуется игнорировать физическое разрешение экрана, а использовать «эффективные» пиксели).



На московском DotNext Михаил обещает сделать доклад об использовании аппаратных API, доступных на мобильных платформах. Поскольку про мобильную разработку на .NET в России практически не рассказывают, будет особенно интересно его послушать. Так что ждем анонса.

За последние полтора месяца мне довелось поработать над backend-ом трех проектов. В каждом требовалось подготовить классы для взаимодействия с удаленным сервисом посредством обмена XML-документами; в частности, требовалось подготовить DTO-классы для каждого из типов сообщений. Для каждого из сервисов шло описание от разработчиков, с примерами XML-документов, так что работа была относительно простая: взять пример, прогнать через утилиту xsd, получить класс, поправить типы, добавить недостающие поля\свойства, протестировать. Операции рутинные, после десятка классов думать уже особо не требовалось, так что в голове начали скапливаться мысли, как ускорить процесс разработки либо улучшить выходной результат. Получилось и то, и другое.

Не так давно мне потребовалось использовать таблицу в приложении на C#. По наивности я подумал, что буду использовать всё самое свежее и выбрал для проекта WPF вместо WinForm и, конечно, взял самый свежий .net framework 4.5. Тут-то и начались проблемы. Как всегда, я решил, что в Яндексе найдётся всё, но не тут то было — в интернете (вернее в РУнете) вообще ничего о DataGrid нет. Постоянно, как бы хитро не изменял запросы, я попадал на DataGridView из WinForm. Самое интересное в том, что платформа WPF полностью переработана и многое из того, что работало в WinForm в WPF не работает вообще никак.

Интересно также и то, что WPF должен быть как бы легче в использовании, ведь в Microsoft отделили дизайнеров от программистов, добавили векторную систему визуализации, язык XAML и прочее.

После продолжительного негодования я открыл большую и толстую книгу по WPF. И вот, чудо! Там было всё, как изменить размер, переименовать и перекрасить что угодно и как угодно, но о том, как элементарно достать запись из DataGrid не было и слова.

Отчаявшись, я решил было перейти на WinForm, но вспомнив старую добрую пословицу «если программа не работает, то проблема не в коде, а в программисте», решил разобраться в проблеме и (правда не помню на каком сайте) нашёл решение (это был сайт на английском языке в самых чёрных глубинах интернета). Название сайта вспомнил, ссылка в конце документа.