Добрый день все любители программирования!
То о чем так долго говорили большевики разработчики процессоров, математики да все кому не лень свершилось. Мир стал многопроцессорным и многоядерным. Сегодня уже не так то просто найти одноядерный однопроцессорный компьютер. Многие ругают разработчиков(особенно ругают ms office), что их ПО не умеет использовать более 1 процессора(ядра). Это плохо. Ведь мощность есть, но не используется, а вместо этого ваш мощный (2-4-8 ядерный) процессор просто греет воздух в ваших квартирах(серверных).
У такой ситуации есть несколько причин. Старый софт, не очень хорошие разработчики(скорее им просто не приходилось использовать более 1 процессора для своих программ) и еще десяток других причин. Что бы использовать новые возможности процессоров, разработчики платформ и сред разработки прикладного программного обеспечения создают среды разработки поддерживающие возможности работы над параллельными программами(список инструментария для с/c++ Intel® Thread Checker, Intel® Thread Profiler, Intel® VTune Analyzer, Intel® MKL, Intel® Parallel Studio и это далеко не весь)
Разработчикам программ на управляемом коде тоже хочется использовать все преимущества параллельного исполнения их программ, но в определенной мере их сдерживали возможности frameworkов. Но наши мольбы были услышаны! Разработчики .Net framework 4.0 большое внимания уделили именно возможностям для параллельных программ. Весело и задорно об этом рассказывает член команды разработчиков на channel9 Но и я расскажу немного о том, что появилось в .Net 4.0, что описано VS2010TrainingKit январского.
Предупреждаю- много букв, но ведь и тема обширная!

Чем отличаются популярные платформы и среды разработки от не популярных?! Количеством разработчиком скажите Вы и будете правы. Но почему столько разработчиков выбрало эту платформу и среду разработки? Наверное потому, что:
1- востребованность
2- удобство
3- простота
4- мощь
…
N-что то еще.

Все любят рассказывать как удобен, востребован, прост (добавить по вкусу) тот или иной язык. Таких рассказов тысячи. Но я считаю что не заслужено забывают или говорят лишь мельком, о все возможных компонентах и вспомогательных инструментах разработки, делающих использования языка(платформы) обоснованным. Хотя многие из них затем входят в среду разработки, многие из разработчиков на платформе (языке) об этих расширениях не знают.
Хочу немного исправить эту ситуацию и рассказать о том, что сделали Telerik для .net разработчиков.
Начну с Telerik WebUI Testing Studio, далее если будет интерес расскажу о остальных разработках Telerik.

Добрый день!

Общими усилиями DioNNiS, ohoncharuk и немножко меня была создана брошюра «ASP.NET 4.0: руководство для разработчиков». Это руководство на 64 страницах содержит краткое описание нововведений новой версии популярной технологии ASP.NET.

О чем речь?

Речь в этой заметке пойдет о библиотеках для автоматического копирования полей одного объекта в поля другого (мэппинг объектов). О том, для чего это надо можно почитать, например, тут.

Предлагаю рассмотреть следующие библиотеки, с помощью которых можно решить вышеописанную задачу:

1) AutoMapper
2) BLToolkit
3) EmitMapper

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

Проект, описанный в данной статье, являет собой мой первый опыт программирования на C# .NET, посему прошу не судить строго.

Многие из нас пользуются Microsoft Visual Studio и, я полагаю, большинство для обмена кодом использует клевый ресурс .

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

Для работы я использую Microsoft Visual Studio 2008, но в 2005 все абсолютно аналогично.

Небольшое лирическое отступление

Так получилось, что в последнее время я занимаюсь разработкой программ работающих в связке с различным оборудованием. На прошлой работе это были роботы и станции тестирования для полупроводниковой промышленности, на текущей – масс-спектрометры для химии и медицины. Казалось бы, совершенно различные отрасли и назначение программ, но с точки зрения разработчика есть много общих моментов.

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

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

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

Недавно, DiverOfDark предложил мне написать что нибудь на русском о PEX, раз уж я все равно сейчас все изучаю до чего дотягиваются руки. Т.к. в новогодние праздники делать ничего все равно не чего, то я решил согласиться.

На chanel9 есть несколько видео на английском, объясняющее что это за проект и что он делает. Вот теоретическое видео, а вот небольшое применение. Честно говоря проект не самый новый. Первые публикации датированы 2008 годом. Но надеюсь, что на хабре есть люди, которые о нем не слышали ранее и им мой рассказ будет полезен.

Для тех, кому не хочется смотреть видео, я расскажу о своем опыте использования:
Основная задача PEX заключается в создании unit тестов, которые:
1. Покроют тестируемый модуль на 100% При этом PEX умеет работать только с публичными методами — модификатор доступа к которым «public»! С «private» он не работает.
2. Выдают все возможные ошибки, которые можно получить при выполнении данного, тестируемого модуля. Для этого используется обширный перебор входных параметров модуля, с простой целью: модуль должен выдать ошибку. К примеру, в качестве параметров методу, могут быть переданы null-значения (естественно для случаев, где это позволяется). В тех случаях, когда переменные численные, будет предпринята попытка передать отрицательные, нулевые и очень большие значения чисел. Вместо каких то сложных объектов опять же может быть передан null.
Таким образом, PEX выявляет все возможные и невозможные проблемы вашего кода. Работает это чудо по заявлению создатей с .NET Framework 2.0, 3.0, 3.5, 4.0 Beta2 на Visual Studio 2008/2010 Team Dev или Team Test.(Лично от себя хочу добавить, что в vs2010beta 2 у меня появилась в контекстном меню строчка PEX, но содержимое у нее не становилось активным, что бы я не делал. По этому будем считать, что сейчас это «чудо инженерной мысли» работает с версией .net 3.5sp1 максимум на 2008 студии). Проект, еще дорабатывается его создателями, постоянно появляются новые сборки, а это значит, что проект жив, и рано или поздно попадет из Microsoft Research в продуктовый отдел, и вот тогда всем: и разработчикам и тестировщикам — наступит Счастье!.. Если вам интересены создатели PEX, то милости прошу в блоги его разработчиков Nikolai Tillmann и Peli de Halleux's.

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

Для тестирования приложений написанных под .net существует несколько framework для unit тестирования. Есть встроенный в Visual Studio framework -MSTEST, который предоставляет непосредственно сам Microsoft.
Есть и сторонние наработки такие как: NUnit, MBUnit, XUnit
Для тех кто любит выбор(демократию) просто счастье, целых 4 кандидата на использование в качестве frameworkа для тестирования.
Что же они из себя представляют и умеют?

Уверен что про geotagging слышало подавляющее большинство хабраюзеров, особенно те кто интересуется фотографией. Для тех же, кто все таки не слышал поясню — в двух словах geotagging есть внедрение Exif тегов содержащих информацию с координатами GPS в фотографии с последующей привязкой фотографий к карте.

Возможность просмотра привязанных к картам фотографий предоставляет большинство современных фото-хостингов — PicasaWeb, Flickr, Яндекс-Фотки и прочие, да и десктопные программы подтягиваются, например Picasa.

Люблю писать про frameworkи о которых на русском мало очень сказано и о тестировании приложений. В эфире очередной неизвестный герой- XUnit

Существуют различные frameworkи для тестирования (MSTest,MBUnit, NUnit.)Зачем же писать очередной?! Что в нем такого особенного (Framework для тестирования — это не дистрибутивы Linux, которые каждым ИТшник раз в жизни должен собрать свой.) Фундаментальной особенностью XUnit.net я бы назвал возможность гибко программировать и настраивать тесты под свой вкус и нужды (unix way, который действительно нужен некотором продвинутым тестировщикам.). XUnit.net включает возможность расширения функциональности платформы с помощью пользовательских компараторов, методов тестирования и классов. Это основной философский принцип заложенный в XUnit. Вы можете настроить свои тесты как считаете нужным ВЫ а не как считает кто-то, кто не сталкивался с вашей предметной областью и особенностью вашего приложения. Статья представляет из себя перевод, который я добавил комментариями(не сочтите за наглость) и исходными кодами примеров Подробнее под Хабракатом.