На официальном сайте ASP.NET опубликовано новое подробное руководство по вопросам публикации веб-проектов с помощью Visual Studio 2010. Руководство состоит из 12 частей и охватывает всевозможные аспекты публикации: подготовку проекта, публикацию баз данных, тестирование, безопасность и так далее.

Список из 12 статей со ссылками представлен под катом.

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

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

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

В прошлый раз, я писал о создании веток, Опыт использования TFS 2010: (Система контроля.Ветки.Создание) и одном из вариантов их иерархии. В этой части я попытаюсь раскрыть работу с системой контроля и более подробно и остановлюсь на средствах контроля доступа к коду в ветках и политики CheckIn.

Приветствую, Хабр!

Сегодня мы поговорим о рутине. Время от времени каждому программисту приходится совершать много нудной, объемной и шаблонной работы, которую постоянно так и хочется автоматизировать, да руки не доходят. Вот об одном малоизвестном способе упростить себе жизнь с помощью кодогенерации я и хочу сегодня рассказать сообществу дотнетчиков. Способ известен как Text Template Transformation Toolkit или попросту T4.

Проблема связанности в архитектуре приложений в последнее время получила очень много огласки, и породила большое количество фреймворков DI-характера и приложений для статического разбора и «умного рефакторинга». Об одном таком приложении под названием NDepend я и хочу рассказать.

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

Предположим, что у нас готова или почти готова некоторая .NET библиотека для разработчиков (они же конечные пользователи). API библиотеки безупречен, количество багов впечатляюще мало, да и вообще это не библиотека, а просто кладезь совершенного кода. Дело за малым – объяснить пользователям, как работать с этим замечательным продуктом.

Есть разные подходы к написанию документации. Некоторые команды предпочитают начинать создание документации в момент начала создания продукта. Другие откладывают написание мануалов на окончание работ. В некоторых командах документацию пишут специальные люди, которые ходят от разработчика к разработчику и от менеджера к менеджеру, аккумулируя знания о продукте. Во многих небольших командах таких специальных людей нет, а потому документацию часто пишет разработчик или разработчики. Кто-то использует сторонние средства вроде Help & Manual, в которых, как в заправском текстовом редакторе, можно создавать очень сложную верстку и на выходе получать документацию в многообразии форматов. Многие используют другой подход, широко пропагандируемый в последнее время – написание документации прямо в коде программы/библиотеки.

Последнее время на популярно-технических форумах я часто встречаю ожесточённые споры приверженцев и противников .NET. Эти споры, как правило, начинаются из-за недоразумения, и заканчиваются жестким троллингом, беседами “за жизнь” и сравнением радиусов и удельных плотностей материала различных сферических коней. Обе стороны силятся доказать и аргументировать, но ни одна не хочет посмотреть на предмет спора другими глазами. Хабрахабр не исключение, увы.

Накалу страстей такой беседы позавидовали бы религиозные фанатики. Единственное, что спасает противников от крестовых походов друг на друга, вооружившись вилами и LangSpec’ами — то, что они разделены интернетом.

Так жить нельзя, господа. Мне захотелось исправить эту ситуацию, и выступить с одной из сторон. Этим постом я попробую нанести сообществу непоправимую пользу и разобраться с мифами, на обсуждение которых, а не на взаимное членовредительство, к сожалению, и уходят силы спорщиков. А так как я в своё время перелез с C++ на C# и всё вокруг него, то я буду развенчивать негативные мифы, прибавлять позитива и всячески приукрашивать действительность — а как без этого. И — заметьте — это обойдется совершенно бесплатно для M$. Ну а сделать я это хочу в формате Q&A.

Я уже достаточно много лет занимаюсь разработкой на java и повидал довольно много чужого кода. Как это не странно, но постоянно от одного проекта к другому я вижу одни и те же проблемы. Этот топик — попытка ликбеза в наиболее часто используемых конструкциях языка. Часть описанного — это довольно банальные вещи, тем не менее, как показывает мой опыт, все эти банальности до сих пор актуальны. Надеюсь, статья пригодится многим java программистам. Итак, поехали:

new vs valueOf

//медленно
Integer i = new Integer(100);
Long l = new Long(100);
String s = new String("A");

//быстро
Integer i = Integer.valueOf(100);
Long l = 100L;//это тоже самое что Long.valueOf(100L);
String s = "A";

Старайтесь всегда использовать метод valueOf вместо конструктора в стандартных классах оболочках примитивных типов, кроме случаев, когда вам нужно конкретно выделить память под новое значение. Это связано с тем, что все они, кроме чисел с плавающей точкой, от Byte до Long имеют кеш. По умолчанию этот кеш содержит значения от -128 до 127. Следовательно, если ваше значение попадает в этот диапазон, то значение вернется из кеша. Значение из кеша достается в 3.5 раза быстрее чем при использовании конструктора + экономия памяти. Помимо этого, наиболее часто используемые значения могут также быть закэшированы компилятором и виртуальной машиной. В случае, если ваше приложение очень часто использует целые типы, можно увеличить кеш для Integer через системное свойство «java.lang.Integer.IntegerCache.high», а так же через параметр виртуальной машины -XX:AutoBoxCacheMax=<size>.

Эта тема не относится к IT напрямую, но все знают, что без нее никуда. К сожалению, далеко не у всех есть возможность изучать английский с преподавателями. Ну что ж, попробуем заняться этим дома и с максимальной отдачей!

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

Основы программирования

• codebetter.com/karlseguin/2008/06/25/foundations-of-programming-ebook
• pine.fm/LearnToProgram
• netlib.bell-labs.com/cm/cs/pearls
• www.faqs.org/docs/artu
• savannah.nongnu.org/projects/pgubook

Добрый день!

Я попробовал описать здесь свой опыт автоматизации сборки приложений .NET (в основном, речь идет о web-приложениях).

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

Недавно я попал на новый проект, с задачей создать небольшое приложение с нуля. Разговариваю с тестером:
— А как тебе новые версии поставлять?
— Можешь как все остальные на проекте, через SVN.
— То-есть ты сама билдить будешь?
— Да нет… Бинарники оттуда беру.

Оказывается, очень много программистов, даже имеющих в подписях слова вроде Senior или Superior никогда в жизни не стыкались с понятием CI, или слабо себе представляют что это такое. Не найдя отдельных публикаций на Хабре на эту тему, решил восполнить пробел, а заодно и по возможности заработать желанный инвайт.

Введение

Локализация приложения на WPF — не легкое занятие. Практически любое пособие по локализации WPF изобилует деталями и ручными шагами для реализации локализованного приложения.

Существующие решения

Локализация с помощью утилиты LocBaml, описанная в руководстве по локализации от Microsoft имеет множество преимуществ, однако сложна для поддержки. André van heerwaarde, в своей статье предложил упростить это решение с помощью настроенного шага сборки, он же написал утилиты для слияния переведенных текстовых фрагментов. Однако, в его статье, так же много ручных шагов.

Шаблон проекта Visual Studio

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

В процессе разработки приложения вы добавляете новые XAML файлы, не заботясь о локализации. По завершению внесения изменений выполните сборку проекта.

Хотелось бы рассказать об инструментах автоматизации сборки под Windows.
Это не коим образом не реклама, а только обзор средств.
Буду рад за ссылки на другие продукты и отзовы об их использовании.

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

Новые архитектурные инструменты в Visual Studio Team System 2010 помогут вам понять имеющееся приложение, спроектировать необходимую вам новую функциональность и проверить что ваша реализация соответствует вашему дизайну.

3 марта 2011 года Careerlab и ScrumTrek при поддержке компании Microsoft проведут семинар, который будет посвящен разработке проектов с использованием методологии Agile в среде Visual Studio.

Среди многих команд занимающихся разработкой все большую популярность приобретает подход Scrum. Действительно, лаконичную, в 20 страниц текста методологию, легко понять и после некоторой практики начать использовать. Вот почему Microsoft выпустил дополнительный шаблон Scrum, который позволяет использовать эту методологию вместе с Team Foundation Server.

Данная статья будет полезна тем, кто не устанавливал и не использовал Visual Studio Team Foundation Server раньше. TFS может быть частью очень сложной инфраструктуры, которая включает отчеты, интеграцию с SharePoint, множественные домены, распределенные базы данных и т.д., но я не собираюсь затрагивать эти области. Моя основная задача – это помочь разобраться с базовыми элементами TFS (система контроля версий, система отслеживания ошибок и заданий и система автоматических сборок) и начать использовать данную систему.

Многие команды, которые используют Subversion для хранения исходных кодов к некоторому моменту начинают задумываться о построении полноценной среды управления жизненным циклом разработки (Application Lifecycle Management). При этом возникают непростые вопросы. В первую очередь это то, как объединить средства контроля версий, управления задачами, багами, артефактами и сборками проекта в единую систему. Путей тут два – либо развивать текущий комплекс, постепенно подключая к нему недостающие компоненты, либо мигрировать на систему, которая все эти компоненты содержит. Для тех команд, которые используют в качестве основного инструмента Visual Studio, подходящим вариантом является Team Foundation Server. Но при этом возникает несколько важных вопросов – как минимизировать время простоя команды, а еще лучше сделать процесс миграции незаметным.