Я думаю, что Microsoft пытается продать нам F# как что-то новое и крутое, но у меня серьезные проблемы с пониманием приемуществ F# перед C#.

Перевод статьи Automating Undo/Redo with .NET Generics Сергея Архипенко.

Введение

Эта статья описывает библиотеку, которая предоставляет undo/redo функциональность для каждого действия в вашем приложении. Вы можете использовать сложные структуры данных и сложные алгоритмы не задумываясь о том, как они будут переведены в предыдущее состояния по запросу пользователя или в результате возникновения ошибки.

Предпосылки

Если вы когда-нибудь разрабатывали графический редактор или дизайнер для сложных данных, вы сталкивались с трудоёмкой задачей реализации undo/redo функциональности, которая бы поддерживалась во всём приложении. Реализация парных Do и Undo методов для каждой операции скучный и подверженный ошибкам процесс, когда вы разрабытываете что-либо более серьёзное, чем калькулятор. В результате моих экспериментов я нашёл способ сделать поддержку undo/redo прозрачной для бизнес логики. Чтобы этого добиться, мы будем использовать магию generics.
Этот проект опубликован на CodePlex, чтобы каждый мог его использовать или внести свой вклад.

Как правило, при написании .NET программ используются не только классы из .NET BCL, но и сторонние библиотеки. Во время выполнения программы все используемые библиотеки должны быть найдены. Для этого зависимые dll кладут в одну папку с exe файлом.

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

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

От переводчика

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

Совсем недавно мы получили релиз .NET / C# 4.0. Мы много говорили (и еще будем говорить) о новых возможностях и нововведениях новой платформы и языка. Но уже можно сделать какие-то выводы и подумать, что же мы хотим увидеть в новой версии .NET / C# 5.0?

Основная идея юнит (или модульного, как его еще называют) тестирования – тестирование отдельных компонентов программы, т.е. классов и их методов. Разрабатывать код, покрытый тестами, весьма полезно, потому что при их правильном использовании практически исключается возможность регресии в истории развитии программы – «что-то новое добавили, половина старого слегла». Также сейчас весьма модна методология разработки “TDD” — Test Driven Development. Согласно ей, программист вначале разрабатывает набор тестов для будущей функциональности, просчитывает все варианты выполнения, и лишь потом начинает писать непосредственно рабочий код, подходящий под уже написанные тесты.

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

Возможно, вам нравятся головоломки и C#, и, может быть, вы даже решали некоторые из них в моем блоге здесь, на Хабре.

Теперь у вас есть возможность попробовать свои силы в решении головоломок более высокого уровня.

Если вы не слышали о парне по имени Эрик Липперт, то очень советую почитать его блог. Эрик — один из разработчиков компилятора C# и часто пишет о разных необычностях и странностях в работе компилятора и среды исполнения .NET, а главное, объясняет причины такого поведения. Он пишет настолько интересно и увлекательно, что у его блога даже есть перевод на русский.

В своей записи от 8 июля Эрик дает ссылку на видео, в котором он и Neal Gafter (который также является одним из разработчиков платформы .NET) рассматривают несколько головоломок на языке C#. Пока я успел посмотреть только три из них, но мне уже нравится их уровень. (Внимание: за каждой головоломкой идет ответ, если хотите подумать самостоятельно, не забывайте нажимать на паузу)

Рекомендую всем, кто хочет расширить свой познания в C#/.NET.

UPD: поскольку с отображением видео есть определенные проблемы, можно скачать видео напрямую. Для этого идем сюда, вводим в строке поиска puzzlers и выбираем справа Download

UPD2: проблемы с воспроизведением видео на исходном сайте скорее правило, чем исключение, поэтому я залил файл на файлообменник: depositfiles.com/files/7ej8pu7zt

Вот такая штука мне сегодня пришла по почте:



Это development board для разработки для ChipworkX от GHI Electronics.
Пока-что я только открыл коробку, и проверил работает ли оно.

Постараюсь писать на хабр по мере ознакомления с этим устройством, т.к. в Embedded программировании я полный новичок.

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



Итак, коробку распаковали, кнопочки потыкали, повтыкали на отладочный вывод при запуске. Круто! Железяка-то работает.

Хотя, с другой стороны, она не делает ничего полезного.

Столкнулся на работе с интересной точкой зрения. В проекте все мало-мальские data transfer objects сделаны структурами. На вопрос, зачем так было сделано, получил ответ, что таким образом данные защищаются от изменений. С одной стороны, да, звучит, в принципе, логично, любые методы получают только копию и не в силах ничего подменить.

Меня дико бесит OnPropertyChanged. Он требует передачи ему строки с именем идентификатора… Мало того, что такой код не верифицируется компилятором, так еще и никакого Intellisence — тайпи весь идентификатор от начала до конца… А если опечатаешся — так проглотит и во время выполнения. Вобщем, нехорошая вещь. Но в MVVM без нее никуда, как и в WPF без MVVM.

Последняя проблема худо-бедно решалась вот таким костылем, содранным отсюда, который вызывался из OnPropertyChanged:

[Conditional("DEBUG")]
[DebuggerStepThrough]
public void VerifyPropertyName(string propertyName)
{
  // Verify that the property name matches a real, 
  // public, instance property on this object.
  if (TypeDescriptor.GetProperties(this)[propertyName] == null)
  {
    string msg = "Invalid property name: " + propertyName;

    if (this.ThrowOnInvalidPropertyName)
      throw new Exception(msg);
    else
      Debug.Fail(msg);
  }
}


И вот сегодня я совершенно случайно нашел красивый способ избавится от него.

Предлагаемые решения в .NET 4

Это вторая часть статьи, посвященной распараллеливанию идеальных циклов. В первой части были рассмотрены проблемы, возникающие при этом, и общие подходы к их решению. В этой мы поговорим о конкретных библиотечных компонентах, предоставляемых .NET 4.0 для поддержки этих задач.

Для распараллеливания «идеальных» циклов предоставляются следующие варианты:

• класс System.Threading.Tasks.Parallel с методами For (), ForEach ()
• Parallel LINQ с методом расширения AsParallel ().

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

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

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

В этом топике я затрону важную для многих тему — тему рисования графиков в платформе .NET. Вспомните: ведь наверняка когда-то было просто необходимо вывести на экран красивый график… И что происходило? Правильно, появлялся новый велосипед.

Часть первая из серии

Топик опубликован по просьбе itdevelop, так что он будет отвечать на все ваши вопросы, а также плюсы кидать на его аккаунт. Спасибо за понимание.

Это первая лекция большого видео-курса для тех, кто хочет научиться программировать на языке С#. Поскольку это — вводная лекция, то хочу сразу предупредить, что сам процесс программирования начнется только со второй лекции. Здесь же я хочу вас познакомить с .NET Framework, чем удобна эта платформа, и как происходит перевод написанного вами кода на C# в код, понятный операционной системе.

Прежде всего, хотелось бы поблагодарить arinoki за публикацию первой лекции видеокурса, который вызвал большой интерес среди хабрапользователей. Благодаря вашим голосам, я могу выкладывать новые лекции от своего имени, а, прочитав комментарии я понял, что тема программирования на С# очень актуальна, а значит я буду и дальше стараться для вас и публиковать новые лекции.

А теперь — по теме:

Вышла вторая лекция видеокурса для начинающих программировать на C#. Вы познакомитесь со средой разработки приложений Visual C# Express, а также напишете свое первое "Hello, World!" приложение. Также для студентов прилагается еще некоторая полезная информация. Приятного просмотра!
Разбор синтаксиса языка C# начнется уже в следующей лекции!

Приветствую вас, хабражители!

По плану публикую очередную лекцию для желающих начать программировать на языке C#.

Продолжение по ссылкам: часть II и часть III.

На PDC2010 Хейсберг объявил, что следующая версия C# будет поддерживать примитивы для удобной организации асинхронных вычислений, кроме анонса была представлена CTP версия расширения для студии (скачать), которая позволяет попробовать улучшенное асинхронное программирование уже сейчас.

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

Не смотря на то, что упрошенное асинхронное программирование является нововведением в C#, сам подход нельзя назвать инновационным, так как реализация async на основе монад есть в Haskell, F# и Nemerle. На самом деле поддержка языком монад позволяет реализовать даже большее, поэтому я был немного удивлен, когда посмотрел презентацию Хейсберга и понял, что в язык был встроен только частный случай.

Продолжение: часть III.

Прошлая заметка о async (часть I) была введением. В этой я продолжу начатую тему: я расскажу о том, что async взаимодействует с SynchronizationContext, и как это влияет на разработку асинхронных графических приложений.

Тестовым полигоном будет пример DiningPhilosophers, который идет вместе с расширением для асинхронного программирования. Это программа — визуализация знаменитой задачи Дейкстры об обедающих философах (ссылка). Прежде, чем читать дальше, лучше ознакомиться с условиями задачи.

Первый раз достаточно близко я познакомился с тестированием лет 5-6 назад, как раз начало моей карьеры. Тогда, я помню, мне рассказывали про покрытие кода тестами. Причем никаких Unit тестов меня не просили писать, просто говорили: “вот видишь if с тремя условиями, который ты написал, ты должен проверить все эти три условия”. Подразумевалось, что я, после того как напишу код, должен его проанализировать, и полностью протестировать обычным проходом по интерфейсу приложения. Как вам? Со временем знания в тестировании у меня немного выросли, я немного научился писать тесты. Я до сих пор не видел и не участвовал ни в одном живом проекте, написанным при помощи Test Driven Development (TDD) подхода. Основа моих знаний была в подглядывании того, как делают это коллеги в предыдущей моей конторе, чтении статей (например, у Алесандра Бындю была отличная статья “TDD для начинающих. Ответы на популярные вопросы”), просмотра пару сринкастов. Я решил покончить с безграмотностью и проникнуться темой, для этого я сел за прочтение книги The art of Unit Testing with Examples in .NET. Притом, что в текущей конторе? можно сказать, что тесты пишу только я для своего кода. Нужно быть образцом.