Наверное, любому программисту, который разрабатывает пользовательский интерфейс на C#/XAML, приходилось писать нестандартные элементы управления. В нашей веселой команде 2GIS для Windows Phone мы довольно часто делаем это, и такие задачи стали почти рутиной. Но об одном случае мне хочется рассказать подробнее. Все началось с того, что однажды нам понадобилось написать весьма своеобразный прогресс-бар.

Введение

Паттерн MVVM хорошо известен, о нем написано много статей, наверное каждый NET-разработчик сталкивался или слышал об этом паттерне. Цель этой статьи – рассказать о собственной реализации этого паттерна.
MugenMvvmToolkit — является кроссплатформенной реализацией паттерна MVVM и на текущий момент поддерживает следующие платформы:

• WinForms
• WPF
• Silverlight 5
• Silverlight for WP7.1, WP8, WP8.1
• Xamarin.Android
• Xamarin.iOS
• Xamarin.Forms
• WinRT XAML framework for Windows 8 Store apps

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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

Многие давно похоронили Myspace. Но похоже он не собирается сдаваться.

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

Введение (от переводчика)

Так вышло, что одна из моих самых любимых игр — Warcraft II.
Каждый раз, когда эта игра где-то упоминается, или кто-то про неё вспоминает, я обычно очень радуюсь. Перед Warcraft II, разумеется, был просто Warcraft.

И вот недавно случилось интересное — Патрик Вайат (Patrick Wyatt), один из тех людей, кто стоял у истоков Blizzard, и человек, который затеял разработку Warcraft начал цикл воспоминаний о тех временах. Первая статья, которую я вам предлагаю прочитать ниже — о начале разработки Warcraft. О том, откуда появилась идея; о том, какая сеть была организована у ребят в офисе, пока они грезили о мультиплеере; о EMS и тонкостях эстетики программирования под DOS; о команде проекта и так далее.

Я, увы, совсем не специалист в разработке под DOS, поэтому если читатели укажут мне на неточности в переводе, связанные с техническими деталями — буду рад и тут же исправлюсь.

Это касается, понятное дело, и любых других неточностей, опечаток, пунктуации и стилистики.

---

Давным давно, в начале времен, когда игры для PC писались под операционной системой DOS, я начал работать над игрой под названием Warcraft.

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

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

На днях, после долгого перерыва, надо было поработать на WPF, и возникло желание заменить поднадоевший стандартный вид окон Windows 7 на что-нибудь более вдохновляющее, скажем в стиле Visual Studio 2012:

Введение

В данной статье я хочу рассмотреть разработку клиентской библиотеки к условному api сервису. В качестве такого сервиса я буду использовать воображаемый Rest-api Хабрахабра.

Чтобы такая рутинная задача стала немного интереснее, мы усложним требования, добавив кэширование и приправим всё это библиотекой Reactive Extensions.

Всех заинтересовавшихся приглашаю под кат.

Разработка приложений для платформ WPF, Silverlight, Windows Store и Windows Phone, почти всегда подразумевает использование паттерна MVVM. Это закономерно, так как базовой философией этих платформ, является разделение представления (так же я буду использовать термин интерфейс пользователя) и остальной логики программы. Этот подход позволяет получить следующие преимущества:

1. Разделение пользовательского интерфейса и логики представления: что позволяет дизайнерам работать над пользовательским интерфейсом, а программистам над бизнес логикой приложения используя для взаимодействия абстрактный интерфейс модели представления
2. Расширенные возможности автоматизированного тестирования: отделение пользовательского интерфейса от остальной логики, позволяет полностью протестировать логику представления без ограничений накладываемых автоматизацией тестирования через пользовательский интерфейс
3. Множественные представления для одной модели представления: одна модель представления может использоваться многими реализациями интерфейса пользователя. Например, сокращенный и полный вариант представления данных, интерфейс зависящий от прав пользователя. Возможность использовать одну реализацию модели представления на различных платформах
4. Расширенные возможности повторного использования компонентов: так как модели представления отделены от реализации представления, возможны любые варианты их использования, наследование от базовых моделей, композиция нескольких моделей и т.п.

Разрабатывая приложения под платформу Windows Phone, я столкнулся с тем, что большинство статей описывают базовую реализацию паттерна MVVM, которая обычно сводится к реализации в классе модели представления интерфейса INotifyPropertyChanged, создания простой реализации ICommand и простые сценарии связывания этих данных с представлением. К сожалению, остаются за рамками обсуждения такие важные вопросы как, реализация обобщенных классов с удобным интерфейсом, синхронизация потоков при асинхронном исполнении, навигация на уровне модели представления и многие другие.

Это руководство для WPF-разработчиков, стремящихся добиться максимально чёткой картинки в своих приложениях. Графическая система WPF до мозга костей векторная, но конечным результатом её работы по-прежнему является растр. Если не уделить этому факту должного внимания, можно столкнуться с различными сортами «мыла» — паразитными артефактами растеризации. В такой ситуации важно не терять присутствия духа, причины их возникновения вполне рациональны, а методы борьбы достаточно просты и эффективны.

Доброго времени суток.

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

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

Как известно, в Visual Studio 2013 более не поддерживается разработка приложений для Windows Phone 7. В тоже время, только в 13-й версии можно разрабатывать приложения для Windows 8.1. Все бы ничего, если бы отказ от поддержки WP7 не коснулся и Portable Class Libraries(PCL). При первом запуске проекта 13я Visual Studio предлагает сконвертировать кросс-платформенный PCL проект, оставив только поддержку Windows Phone 8.
Не вступая в споры о целесообразности этого решения и мотивации Microsoft, отметим, что у множества разработчиков более или менее ощутимый процент пользовательской базы пользуется Windows Phone 7 устройствами. Одновременно хочется использовать все вкусности, которые предоставляет разработчику новая версия Visual Studio.
Решение проблемы предлагается под катом.

Захотелось мне посмотреть, как работает реализация .NET на Linux. Решено было развернуть Ubuntu Server на нашем гипервизоре, установить свежий пакет mono и через nginx запустить ASP.NET MVC4 сайт.

На официальном сайте mono готовый пакет для Ubuntu только 2-х летней давности. С этого момента начались поиски в сети путей осуществления задуманного. Результатом полученного опыта стал скрипт для автоматического развертывания на голой Ubuntu Server 12.04.3 или 13.04 всего необходимого для запуска сайтов ASP.NET MVC4:

• Соберем из исходников и установим mono 3.2.1
• Добавим monoserve скрипт в init.d для автоматического запуска сайтов и управления ими.
• Установим nginx 1.4.1
• Создадим и настроим простой сайт, чтобы проверить работоспособность всей связки.

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

— Прототипное наследование — это прекрасно
JavaScript — это объектно-ориентированный (ОО) язык, уходящий корнями в язык Self, несмотря на то, что внешне он выглядит как Java. Это обстоятельство делает язык действительно мощным благодаря некоторым приятным особенностям.

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

К счастью, в ECMAScript 5 появилось множество вещей, которые позволили поставить язык на правильный путь (некоторые из них раскрыты в этой статье). Также будет рассказано о недостатках дизайна JavaScript и будет произведено небольшое сравнение с классической моделью прототипного ОО (включая его достоинства и недостатки).

В свое время, в начале разработки двухмерной игры на Unity3d, мне пришлось перерыть кучу документации, сайтов, проштудировать answers.unity3d.com и forum.unity3d.com на тему: как сделать 2d-игру на этом 3d-движке. Самыми первыми вопросами были: как правильно настроить камеру, как сделать 2d-спрайт так, чтобы он отображал текстуру «пиксель в пиксель». На то время уже существовал SpriteManager (далее – SM) и даже SM2 с его мощной поддержкой редактора. Судьба сложилась так, что я не мог его тогда купить, да и пробной версии не было. В итоге, мне пришлось самому написать несколько полезных скриптов для реализации 2d на Unity3d. О том, как это сделать, пойдет речь в этой статье.

"

Для начала — что такое WiX? Технология WiX (Windows Installer XML) представляет собой набор инструментов и спецификаций упрощающих процесс создания дистрибутивов на базе MSI (Microsoft Installer). Если объяснять проще то это обертка вокруг MSI с человеческим лицом.

На мой взгляд изучать проще всего на простых примерах. В данной статье я приведу пример простейшего инсталлятора.

Оплотом современного мира являются программисты. Программисты — это самые надежные и умные люди в мире. Любая проблема обычного человека является элементарной для программиста. Программисты умеют находить решение любой проблемы в считанные минуты.

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

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

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

Прим. перев.: это перевод статьи Six years of WPF; what's changed?, написанной 3 августа 2012 года. Сейчас WPF уже не шесть, а семь лет, однако ничего не изменилось.

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

Шесть лет назад я написал статью про валидацию в WPF на Code Project. Ещё я написал свой error provider, который поддерживает IDataErrorInfo, потому что — вы не поверите! — WPF 3.0 не поддерживал IDataErrorInfo. Позже я работал над несколькими опенсорсными WPF проектами вроде Bindable LINQ (первоначального реактивного программирования для WPF, ещё до изобретения Rx) и Magellan (MVC для WPF а-ля ASP.NET). Я даже некоторое время состоял в клубе, посвящённому превозносению MVVM и киданию ссылок на Code Project, известном как WPF Disciples («Приверженцы WPF»).

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

Вот как в далёком 2006-м году выглядела разметка относительно простого окошка (код позаимствован из проекта, над которым я тогда работал):

	<Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
	  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
	  xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
	  xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
	  xmlns:system="clr-namespace:System;assembly=mscorlib"
	  Title="TrialBalance" 
	  WindowState="Maximized"
	  Width="1000"
	  Height="700"
	  Icon="{StaticResource Image_ApplicationIcon}"
	  Background="{StaticResource Brush_DefaultWindowBackground}"
	  x:Name="_this">

Только взгляните на все церемонии! x:Class! Пространства имён XML! Почему бы не объявить всё это в одном месте, почему бы стандартные пространства имён не включать неявно?

К счастью, сейчас 2013-й год, и WPF был проделан огромный путь. Вот так код будет выглядеть сегодня:

Ключевые слова async и await, введённые в C# 5.0, значительно упрощают асинхронное программирование. Они также скрывают за собой некоторые сложности, которые, если вы потеряете бдительность, могут добавить проблем в ваш код. Описанные ниже практики пригодятся вам, если вы создаёте асинхронный код для .NET приложений.