C# *

Это НЕ очередная статья о том что такое P/Invoke.

Итак, допустим в сферическом C# проекте необходимо использовать какую-либо технологию, отсутствующую в .NET, и все что у нас есть это Windows SDK 8.1 в котором имеется лишь набор заголовочных файлов для C/С++. Придется объявлять кучу типов, проверять корректность выравнивания структур и писать различные обертки. Это большое количество рутинной работы, и риск допустить ошибку. Можно конечно написать парсер заголовочных файлов… Тут просто и понятно все кроме количества требуемых на это человекочасов. Поэтому этот вариант отбрасываем и постараемся как либо иначе свести к минимуму количество необходимых действий для взаимодействия с unmanaged кодом.

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

Во втором номере этого журнала, мы рады видеть Джона Скита в нашем «виртуальном» кресле. Джон Скит — настоящий помощник сообщества (взгляните на его значки на StackOverflow), ведущий C# специалист и автор множества книг. Джон является MS MVP начиная с 2003 года. В настоящее время он работает в компании Google.

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

DNC: Привет Джон, мы очень рады, что ты нашел время в своём графике для этого интервью. Для начала мы все хотим знать больше о Джоне Ските, расскажи нам как все началось? Как Джон начал работать с компьютерами?

JS: Мой первый компьютер — общий для всей семьи был Sinclair ZX Spectrum 48 K, который мы купили когда мне было 8. Со временем я покупал и другие модели Spectrum-а, но затем постепенно перешел на PC. Долгое время я проводил большинство своего времени за компьютером, просто играя в игры, но программирование так же всегда присутствовало.

DNC: С какими сложными задачами ты столкнулся при работе на Sinclair? Задачи, которые погрузили тебя глубже в компьютерные науки?

JS: Одним из моих первых «больших» проектов на Spectrum-е было написание аналога языка Logo. В школе у нас были микрокомпьютеры BBC Micros и Logo использовался как язык для введения в вычисления; я действительно им наслаждался и хотел использовать его дома, но у нас не было интерпретатора для Logo. Я не имел понятия о тригонометрии и не имел хорошего представления о структурном программировании, но я проявил упорство и закончил с достаточно неплохой реализацией. Руководство, которое было вместе с Spectrum-ом было очень хорошим, я буквально выучил оттуда всю элементарную тригонометрию, за долго до того как мы начали изучать её в школе.

Хоть проект не наш, но мы рады, то что процесс внедрения livecoding идет повсеместно. Один из авторов Unity уже больше года занимается созданием инструмента для «живого кодирования» для Unity. Сначала вышли версии для JS и Boo, а относительно недавно он выпустил Livity для C#!

Универсальные шаблоны – они же generics, являются одним из мощнейших инструментов разработки.

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

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

Признаюсь честно, описание этого паттерна мне не встречалось, соответственно его название я выдумал. Если у кого есть информация о правильном названии, буду очень рад услышать. Паттерн не привязан к языку но в данной статье я буду использовать C#.

Картинка для привлечения внимания:

Здравствуйте!

Одной из удобных функций Windows Azure Mobile Services является использования внешних служб аутентификаций, которые предоставляются Google, Facebook, Twitter и сам Microsoft Account. Это означает, что разработчику, нет необходимости имплементировать работу с каждым из них отдельно, для этого есть унифицированные методы.

Среди официально поддерживаемых платформ числится почти все кроме… обычной Windows Desktop.

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

Прочитав статью «Усиливаем контроль типов: где в типичном C#-проекте присутствует непрошеный элемент слабой типизации?» был порядком удивлен, как ошибочностью данного подхода, так и тем, что никто не обратил на это внимание.

Автор поста приводит идею того, что метод, возвращающий ссылочный тип, объект которого создается из некоего репозитория, должен, тем или иным образом, гарантировать, что возвращаемый объект не будет null. При этом в одном из примеров он использует контракты, что противоречит их принципам. Я хочу разобрать ошибочность этого подхода.

Проблема

Мы привыкли говорить о языках вроде C# как строго и статически типизированных. Это, конечно, правда, и во многих случаях тип, указываемый нами для некоторой языковой сущности хорошо выражает наше представление о ее типе. Но есть широко распространенные примеры, когда мы по привычке («и все так делают») миримся с не совсем верным выражением «желаемого типа» в «объявленном типе». Самый яркий — ссылочные типы, безальтернативно оснащенные значением «null».

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

Рассмотрим фрагмент кода:

public interface IUserRepo 
{
	User Get(int id);
	User Find(int id);
}

Этот интерфейс требует дополнительного комментария: «Get возвращает всегда не null, но кидает Exception в случае ненахождения объекта; а Find, не найдя, возвращает null». «Желаемые», подразумеваемые автором типы возврата у этих методов разные: «Обязательно User» и «Может быть, User». А «объявленный» тип — один и тот же. Если язык не заставляет нас явно выражать эту разницу, то это не означает, что мы не можем и не должны делать это по собственной инициативе.

Инфраструктура .Net содержит встроенные средства генерирования кода (On-the-Fly Code Generation). Это позволяет .Net-программе в момент своего исполнения самостоятельно (без участия программиста) скомпилировать текст, написанный на каком-либо языке программирования и исполнить получившийся код. Логично было бы ожидать, что для осуществления этих действий в стандартной .Net-библиотеке предусмотрен простейший метод соответствующего класса. Но к сожалению это не так. Microsoft, проделав огромный путь по встраиванию в среду .Net средств генерирования кода, не сделала самый последний шаг навстречу простейшим потребностям программистов. Значит, придётся сделать этот шаг самостоятельно.

Самое простое средство предлагаемое Microsoft для решения описанной задачи — это класс CSharpCodeProvider, который входит в стандартную библиотеку .Net. Использование этого класса — не очень сложная задача, но тем не менее было бы полезно иметь инструмент, превращающий использование сгенерированного на лету кода в задачу тривиальную.

Часто, передавая объект в какой-либо метод, нам бы хотелось сказать ему: «Вот, держи этот объект, но ты не имеешь право изменять его», и как-то отметить это при вызове. Плюсы очевидны: помимо того, что код становится надёжнее, он становится ещё и более читаемым. Нам не нужно заходить в реализацию каждого метода, чтобы отследить, как и где изменяется интересующий нас объект. Более того, если константность передаваемых аргументов указана в сигнатуре метода, то по самой такой сигнатуре, с той или иной точностью, уже можно предположить, что же он собственно делает. Ещё один плюс – потокобезопасность, т.к. мы знаем, что объект является read only.
В C/C++ для этих целей существует ключевое слово const. Многие скажут, что такой механизм слишком ненадёжен, однако, в C# нет и такого. И возможно он появится в будущих версиях (разработчики этого не отрицают), но как же быть сейчас?

Материал взят из журнала DotNetCurry посвященному технологиям основанным на платформе .NET.

Дорогие читатели, мы очень рады видеть Эрика Липперта в этом номере журнала DNC. Эрик не нуждается в представлении людям знакомым с C#, но для остальных Эрик известен своей работой в команде разработчиков компилятора языка С#. Он посвятил значительную часть своей карьеры компании Microsoft, работая на различных должностях. До того как придти в Microsoft, Эрик работал в компании Watcom. Наши «старички» помнят Watcom как компанию, которая создала очень хорошие компиляторы для языков C++ и Fortran. В настоящее время Эрик работает в компании Coverity, помогая создавать продукты статического анализа кода.

Статья родилась из того, что мне потребовался удобный и простой механизм перехвата для некоторых задач, который легко реализуется техниками АОП. Существует довольно много перехватчиков (Casle.net, Spring.net, LinFu и т.д.), требующих внедрять динамические дочерние классы в IL-код во время исполнения и приводящих практически всегда к одним и тем же ограничениям, накладываемым на перехватываемые классы: не статические, не запечатанные, методы и свойства должны быть виртуальными и т.д…

Другие механизмы перехвата требовали изменения процесс сборки или покупки лицензии. Ни то ни другое я себе позволить не мог…

Как то давно наткнулся на интересную статью Разработка игры под управлением WP8...

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

От переводчика. Судя по своему опыту, а также по опыту знакомых коллег-программистов, могу сказать, что для начинающего разработчика среди всех базовых функций языка C# и платформы .NET делегаты и события являются одними из наиболее сложных. Возможно, это из-за того, что необходимость делегатов и событий на первый взгляд кажется неочевидной, или же из-за некоторой путаницы в терминах. Поэтому я решил перевести статью Джона Скита, рассказывающую о делегатах и событиях на самом базовом уровне, «на пальцах». Она идеальна для тех, кто знаком с C#/.NET, однако испытывает затруднение в понимании делегатов и событий.

Представленный здесь перевод является вольным. Однако если под «вольным», как правило, понимают сокращённый перевод, с упущениями, упрощениями и пересказами, то здесь всё наоборот. Данный перевод является немного расширенной, уточнённой и обновлённой версией оригинала. Я выражаю огромную благодарность Сергею Теплякову aka SergeyT, который внёс неоценимый вклад в перевод и оформление данной статьи.

Люди часто испытывают затруднения в понимании различий между событиями и делегатами. И C# ещё больше запутывает ситуацию, так как позволяет объявлять field-like события, которые автоматически преобразуются в переменную делегата с таким же самым именем. Эта статья призвана прояснить данный вопрос. Ещё одним моментом является путаница с термином «делегат», который имеет несколько значений. Иногда его используют для обозначения типа делегата (delegate type), а иногда — для обозначения экземпляра делегата (delegate instance). Чтобы избежать путаницы, я буду явно использовать эти термины — тип делегата и экземпляр делегата, а когда буду использовать слово «делегат» — значит, я говорю о них в самом широком смысле.

Введение

Тема аутентификации и авторизации всегда будет актуальна для большинства web-приложений. Многие .NET разработчики уже успели познакомиться с Windows Identity Foundation (WIF), его подходами и возможностями для реализации так называемых «identity-aware» приложений. Для тех, кто не успел поработать с WIF, первое знакомство можно начать с изучения следующего раздела MSDN. В данной же статье я предлагаю более детально взглянуть на так называемый «claims-based» подход к авторизации пользователей путем изучения того, как это может выглядеть на примере.

Введение

Лирика

Добрый день. Мотивированный многочисленными постами на Хабре о самодельных роботах решил сделать и что-нибудь свое более менее стоящее и интересное.

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

Под рукой у меня оказалась платка Arduino Diecimila, несколько сервоприводов, веб-камера, джойстик и ультразвуковой дальномер. Соответственно сразу возникло желание сделать «компьютерное зрение» на основе веб-камеры, с возможностью как автономной работы, так и ручного управления (джойстиком).

От переводчика. Тема диапазонов (интервалов) в .NET по праву относится к вечно зелёным и молодым. Сотни заданных на форумах вопросов, десятки написанных статей… кажется, что это закончится только тогда, когда Microsoft наконец-то введёт в Framework Class Library свой механизм по работе с диапазонами. И этому есть логичное объяснение — наверное, каждый программист рано или поздно сталкивается с необходимостью использования некоего диапазона значений, будь то числа, даты или какие-либо другие величины. Возникла такая необходимость и у меня, однако, помня о том, что свои велосипеды — не лучшее решение, я прошерстил Интернет и попал на превосходную статью Джона Скита, перевод которой, собственно, и представляю вашему вниманию.

В первом издании моей книги «C# in Depth» приводился абстрактный обобщённый класс Range, в котором для прохода по элементам в диапазоне использовались виртуальные методы. К сожалению, этот класс был неидеален, так как не учитывал определённые пограничные случаи. Однако данная статья повествует не столько о проектировании идеального класса по работе с диапазонами, сколько о том, какие следует учитывать нюансы и соображения. Моя библиотека классов MiscUtil содержит класс, в котором учтено большинство вещей, рассмотренных в этой статье, но, конечно же, и этот класс далеко неидеален. Вообще, в январе 2008 года я написал небольшую статью о диапазонах в своём блоге, но с тех пор утекло много воды, я много чего переосмыслил и решил более детально раскрыть тему в виде данной статьи.

• Пример 1 – Простое использование Command
• Пример 2 — Простое использование Command в паре с лямда функциями
• Пример 3 — Простое использование Command с параметрами
• Пример 4 – Включение и отключение Command
• Пример 5 – Command вызывающие события
• Пример 6 – Асинхронные Command
• Пример 7 — Асинхронные Command обновляющие интерфейс пользователя (UI)
• Пример 8 — Асинхронные Command с возможность отмены
• Пример 9 – Привязка событий к Command
• Как это работает – Класс Command
• Как это работает – Класс асинхронных Command
• Как это работает – Класс привязки данных к Command

Вступление

На примере приложения, использующего паттерн MVVM (Model View View-Model) рассмотрим работу с командами (Commands).

Добрый день. Многие интересуются насколько сильно отличается производительность Xamarin на Android или iOS. Вопрос с iOS я пока оставлю открытым, а вот все вопросы по производительности monodroid предлагаю закрыть раз и навсегда.

Зачастую эти вопросы вызваны из-за неправильного понимания как устроен monodroid, мне например задавали вопросы типа «А Xamarin потом пересобирается под JVM?». Это конечно же не так. Важно понимать, что Xamarin выполняется на том же уровне Android где работает виртуальная машина Android Dalvik. Поэтому при сравнении производительности мы на деле имеем сравнение эффективности работы двух виртуальных машин: Mono VM и Dalvik VM.