Это первый, пробный выпуск подборки интересных ссылок на статьи по разработке веб-приложений на платформе .NET (и не только). Сегодня я представляю первую подборку статей, которые будет полезно почитать в свободные минуты на выходных. Большинство статей написаны на английском, но, со временем, я надеюсь публиковать больше ссылок на русскоязычные статьи.

Тема номера:

Мега-подборка видео-материалов по разработке на ASP.NET WebForms, ASP.NET MVC и WebMatrix:

• 35 видео: что нового в ASP.NET и быстрое введение в новые функции [link];
• 114 видео: руководства по доступу к данным в ASP.NET [link];
• 155 видео: руководства по AJAX, AJAX Control Toolkit [link];
• 29 видео: руководства по вопросам безопасности ASP.NET [link];
• 17 видео: введение в разработку на WebMatrix [link];
• 24 видео: работа с IIS, развертывание ASP.NET-сайтов [link];
• 61 видео: руководства по построению приложений на ASP.NET MVC [link];
• 17 видео: руководства по доступу к данным в ASP.NET MVC [link];
• 5 видео: руководства по вопросам безопасности в ASP.NET MVC [link].

WebForms:

Много слов сказано о достоинствах юнит-тестов (TDD, BDD — в данном случае неважно), а также о том, почему люди всё-таки их не используют.

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

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

Об этом и пойдёт речь:

Введение

Если Вы когда-нибудь слышали такие слова, как IoC, DI, AoP, но не имеете четкого понимания этих терминов, надеюсь, эта статья поможет в них разораться на примере работы с Microsoft Unity контейнером.

В данной статье рассказывается как работать с блоком логирования из библиотеки Microsoft Enterprise Library 4.1. Решил разобраться после посещения Patterns & Practices Roadmap Kiev.

Установка Enterprise Library

Загрузить Enterprise Library 4.1 можно отсюда. Помните, что кроме блока логирования устанавливается много других компонентов.

1. Анонимные чаты: omegle.com, chatroulette.com
2. Сайты-помощники: kwiz.me, kimir.org, englishtips.org
3. Подкастинг: eslpod.com, effortlessenglish.com, npr.podcast.com, businessenglishpod.com,
4. Качаем фильмы/сериалы, затем субтитры к ним. Просматривать можно с замедлением в VLC плеере чтобы лучше переваривать. Еще рекомендую комик шоу, например Important Things with Demetri Martin — не пожалеете.
5. В скайпе ищем каких нибудь индусов со статусом SkypeMe и не стенсняясь знакомимся.
6. При прочтении какой-то книги или просмотра фильма неплохо бы подготовится таким образом: берем текст, устанавливаем длину слова и частоту употребления в тексте и запускаем, например, этот скрипт (PHP): pastebin.com/m7672c2a9
В итоге имеем дайджест слов большинство из которых вы уже знаете но остальные стоит подучить. И когда вы будете смотреть фильм или читать книгу вы автоматом поймете это слово.
7. Произношение слов — ставим в Google.translate режим Русский->English и в поле текста пишем английское слово — оно без перевода встанет справа вместе с флэшкой которое произносит слово. Также forvo.com, howjsay.com
8. Социальные сервисы ответов:
answers.yahoo.com, vark.com
9. Социальные сети для изучения языка:
livemocha.com, lingq.com, italki.com
10. Остальное:
nytimes.com, ecenglish.com, urbandictionary.com
allengl.narod.ru/top/phvTOP170.htm

Надеюсь каждый нашел для себя что-то полезное:)

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

Начнем с пары историй.

История А.

На днях разговаривал с одним программистом. Пишет он на С++, работает в крупной компании в Чикаго; софтом, к созданию которого он причастен, активно пользуются финансовые и трейдерские компании. У нас, говорит, в продукте 600 тысяч строк кода. Начиналось все с небольшого приложения для анализа биржевой статистики, и вот за 20 лет вымахал такой монстр. Здорово, говорю. Внушает уважение. И как вы его тестируете, вашего монстра? Для этого, отвечает мне программист, есть специальный индус. Он какие-то тест кейсы выполняет, отчеты пишет. А до него этим менеджер один занимался, но тот все больше ручное тестирование делал. Новые функции проверял, например. Теперь вот индус. Хорошо, продолжаю выпытывать я, это функциональное тестирование. А производительность вы как-то тестируете? Нет, говорит, если клиенты начинают жаловаться на медленную работу, мы тогда сами ищем узкие места и сами же из исправляем. Кто разрабатывает продукт, тот его и знает лучше. Какой тестер с этим справится?

Умный человек, подумал я, а говорит глупости.

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

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

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

Предлагаю устроить спортивное программирование — написание ИИ на Javascript для игры в дворовой бридж. Предоставляю уже готовую игру на libcanvas и изящный интерфейс для создания AI. Все, что вам надо — браузер, немного азарта и знание JavaScript. Первый этап — вы программируете свой ИИ, играя против него. Второй этап — вы программируете свой ИИ и он играет против лучших из первого этапа. После второго этапа проводим турнир и объявляем итоги. Уверен, что получим много фана и удовольствия. Победителям — слава и почет. Если победят не зарегистрированные на Хабре — готов предоставить инвайты.

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


Посмотреть можно здесь:
часть1
video.yandex.ru/users/ya-events/view/129
часть2
video.yandex.ru/users/ya-events/view/128

Как вы поняли из названия, речь пойдет о продукте от Microsoft Research – Microsoft Moles Isolation Framework. Я познакомился с ним впервые после прочтения поста хабраюзера alek_sys. Моль мне настолько понравилась, что я решил поделиться своим опытом её использования.

Зачем?

Для начала попробуем определиться, для каких целей предназначена Microsoft.Moles и чего мы можем с ней добиться:

• Полная изоляция тестируемой логики от внешнего окружения.
• Возможность быстрого и просто создания юнит-тестов, при чём тестирование логики класса становится возможным даже при отсутсвии реализации классов, пользователем которых является тестируемый класс.
• Становится просто организовать наборы тестовых данных или моделировать состояние связанных обьектов для создания тестовых условий
• В разы сокращается время выполнения юнит-тестов, становится реальным частый запуск тестов
• Нарушение логики юнита не влечет за собой падение сотни-другой не предназначенных для его тестирования тестов
• Удобное тестирование методов со сложным workflow

Команда Patterns & Practices фокусирует свою деятельность на аккумулировании и описании архитектурных практик и рекомендаций для разработчиков прикладных систем. Именно P&P являются авторами таких руководств, как Microsoft Application Architecture Guide, Developing Applications for SharePoint 2010, Enterprise Library 5.0, Windows Azure Architecture Guide и многие другие.

Конференция, впервые проведенная в России в прошлом году, становится хорошей традицией и теперь проходит в рамках международной серии конференций P&P Symposium. На конференции выступят ведущие члены команды Patterns & Practices из главной штаб-квартиры Microsoft в Редмонде, а также ряд российских экспертов. Учитывая значимость темы “облачных вычислений”, в рамках конференции выделен специальный трек, посвященный различным сценариям cloud computing. Подробности на сайте саммита.

Нас часто просят порекомендовать продукты eCommerce, которые могут интегрироваться с CMS или использоваться совместно с к.л. CMS. Ниже опубликован список ПО с открытым исходным кодом, пригодного для этих целей.
Примечание: русскоязычных пользователей, прежде всего, интересует наличие локализованных версий, поддержка отечественных платёжных систем и русское сообщество. В комментариях по тексту, выделенных курсивом, по-возможности указана эта информация.

Обнаружение пешеходов используется главным образом в исследованиях, посвященных беспилотным автомобилям. Общая цель обнаружения пешеходов — предотвращение столкновения автомобиля с человеком. На Хабре недавно был топик про «умные машины». Создание подобных систем очень популярное направление исследований (Darpa challenge). Я занимаюсь распознаванием пешеходов для подобного проекта интеллектуальных автомобилей. Очевидно, что проблема обнаружения пешеходов — программная, а предотвращение столкновения — аппаратная. В данной статье я упомяну лишь о программной части, кратко расскажу об одном способе обнаружения людей на изображении и алгоритме классификации.