Конверторы являются одной из важнейшей особенностью механизма привязки в WPF. Они позволяют управлять тем, как источник привязки будет представлен в UI. В данной статье я покажу, как немного упростить использование конвертеров в XAML коде.

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

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

Топик тогда собрал 100500 комментов (в основном «супер! хочу!»), а особо заразительные собрались в команды и стали воплощать идею в жизнь. Так что же было сделано за эти два года?

Как я уже говорил, наша компания много работает с задачами real-time обработки данных. Решая различные задачи, мы сталкивались с довольно любопытными и интересными решениями, о которых порой на хабре никто попросту не писал. Вот об одной такой интересной системе мы сегодня вам и расскажем. Сделала ее компания Microsoft, называется она StreamInsight и представляет из себя реализацию так называемого паттерна Complex Event Processing. О том, что это и зачем нужно, мы подробно расскажем внутри.

Плохо думал, когда удалял текущую статью. Дам сразу ссылку на релиз

… или как я получил «Аленку» за консольное приложение

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

Представьте, что ваш коллега-нытик пришел рассказать о своей непростой задаче — ему нужно не просто упорядочить по возрастанию набор целых чисел, а выдать все элементы упорядоченного набора с L-го по R-й включительно!
Вы заявили, что это элементарная задача и, чтобы написать решение на языке C#, вам нужно десять минут. Ну, или час. Или два. Или шоколадка «Алёнка»

Предполагается, что в наборе допускаются дубликаты, и количество элементов будет не больше, чем 10^6.

К оценке решения есть несколько комментариев:

Ваш код будут оценивать и тестировать три программиста:

• Билл будет запускать ваше решение на тестах размером не больше 10Кб.
• В тестах Стивена количество запросов будет не больше 10^5, при этом количество запросов на добавление будет не больше 100.
• В тестах Марка количество запросов будет не больше 10^5.

Решение может быть очень интересным, поэтому я посчитал нужным его описать.

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

В этой статье даются ответы на нижеследующие вопросы, основываясь на личном опыте и опыте коллег.

1. Почему стоит начать работать «в белую»
2. Почему на начальном этапе ИП лучше ООО
3. Что делать, если партнёров несколько

Если вы – начинающий или уже опытный фрилансер и подумываете о работе «в белую», но ещё точно не определились с вопросами «Стоит ли оно того?» и «ИП или ООО?», вэлком

Все нетривиальные абстракции дырявы

Джоэл Спольски – Закон дырявых абстракций

А иногда дырявятся и довольно простые абстракции

Автор этой статьи


Большинство современных разработчиков знакомы с «законом дырявых абстракций» по знаменитой заметке Джоэла Спольски с одноименным названием. Заключается этот закон в том, что как бы ни был хорош протокол взаимодействия, фреймворк или набор классов, моделирующих предметную область, рано или поздно нам приходится спускаться на уровень ниже и разбираться с тем, как же эта абстракция устроена. Внутреннее устройство абстракции должно быть проблемой самой абстракции, но возможно это только в наиболее общих случаев и лишь до тех пор, пока все идет хорошо (*).

Когда-то давно, в «небольшой» мелкомягкой компании решили, а почему бы нам не «абстрагироваться» от местоположения объекта и сделать сам факт того, является ли объект локальным или удаленным, лишь «деталью реализации». Так появились технологии DCOM и ее наследник .NET Remoting, которые скрывали от разработчика, является ли объект удаленным или нет. При этом появились все эти «прозрачные прокси», которые позволяли работать с удаленным объектом, даже не зная об этом. Однако, со временем выяснилось, что эта информация архиважна для разработчика, поскольку удаленный объект может генерировать совершенно другой перечень исключений, да и стоимость работы с ним несравнимо выше, чем взаимодействие с локальным объектом.

Здравствуйте. Что такое миграции и зачем они нужны хорошо рассказано в статье Версионная миграция структуры базы данных: основные подходы.
Я же хочу вам рассказать о системе версионных миграций: FluentMigrator. Почему мне нравится именно этот проект? Из-за приятного синтаксиса миграций и поддержки различных СУБД. Заинтересовались? Добро пожаловать под кат.

Наверное многие из вас уже видели скриншоты нового Team Explorer в посте рассказывающем об улучшениях в области контроля исходного кода. В этом топике хотелось бы сосредоточиться на общих новинках Team Explorer.
Вы помните, что Team Explorer в Visual Studio 2010 имеет древовидную структуру, и очень похож на обозреватель проекта (Solution Explorer). Долгое время мы внутри команды считали, что этой модели будет достаточно, хотя и налагает некоторые ограничения. Но когда я создал Team Members Power Tools пару лет назад, мне захотелось более широких возможностей которые, например, показывали бы картинки, списки пользователей. Team Explorer с его деревом ограничивал или вообще не давал сделать такие вещи. Как только мы стали проектировать TFS 11, в том числе планируя включить функциональность ревью кода, стало понятно, что нам необходим новый подход. В том числе мы получили много отзывов от людей использующих наш продукт с просьбами реализовать новую дополнительную функциональность.

Не так давно на Хабре была опубликована статья (ссылка на топик) моего коллеги AlexanderByndyu, описывающая уход от использования Repository в сторону применения связки QueryFactory + классы запросов Query. При этом в комментариях разгорелся весьма интересный диспут, касающийся целесообразности приведенного в статье решения. Было достаточно много интересных отзывов, среди которых особенно выделялись высказывания о том, что, дескать, QueryFactory не нужен и является лишней обузой, мешающей безболезненному добавлению, изменению и удалению классов запросов. В данной статье я хочу показать подход, который позволяет избавиться от применения QueryFactory, через активное использование IoC контейнера. Данную организацию работы со структурой классов запросов мы использовали в одном из наших недавних проектов, где в качестве IoC использовался Castle.Windsor.

Всем доброго времени суток!

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

Дерево ван Эмде Боаса (van Emde Boas tree) — ассоциативный массив, который позволяет хранить целые числа в диапазоне [0; U), где U = 2^k, проще говоря, числа, состоящие не более чем из k бит. Казалось бы, зачем нужно еще какое-то дерево, да еще позволяющее хранить только целые числа, когда существует множество различных сбалансриованных двоичных деревьев поиска, позволяющих выполнять операции вставки, удаления и прочие за O(log n), где n — количество элементов в дереве?

Главная особенность этой структуры — выполнение всех операций за время O(log(log(U))) независимо от количества хранящихся в ней элементов.

Изначально автор хотел назвать эту статью следующим образом: «О синглтонах, статических конструкторах и инициализаторах статических полей, о флаге beforeFieldInit и о его влиянии на deadlock-и статических конструкторов при старте сервисов релизных билдов в .Net Framework 3.5», однако в связи с тем, что многострочные названия по неведомой автору причине так и не прижились в современном компьютерном сообществе, он (автор) решил сократить это название, чудовищным образом исказив его исходный смысл.

-------------------------

Любая реализация паттерна Синглтон в общем случае преследует две цели: во-первых, реализация должна быть потокобезопасной, чтобы предотвратить создание более одного экземпляра в многопоточном мире .Net; а во-вторых, эта реализация должна быть «отложенной» (lazy), чтобы не создавать экземпляр (потенциально) дорого объекта раньше времени или в тех случаях, когда он вообще может не понадобиться. Но поскольку основное внимание при прочтении любой статьи про реализацию Синглтона отводится многопоточности, то на «ленивость» зачастую не хватает ни времени не желания.

Базовое понимание
 
Помню, еще в университете перед реализацией любого алгоритма мы описывали его в виде блок схемы, и только после этого переходили непосредственно к кодированию. Workflow, как одна из парадигм программирования, на ряду с процедурным и объектно ориентированным подходами, как раз и позволяет нам визуально реализовать любой процесс, используя набор предопределенных функциональных блоков (Activity), при этом, избавляя от его последующего кодирования.

Библиотека WF, являясь одной из реализаций парадигмы Workflow, предоставляет следующие основные возможности:

— богатый набор функциональных блоков;
— расширение набора стандартных функциональных блоков пользовательскими;
— сохранение и возобновление экземпляров Workflow в процессе их исполнения;
— использование Workflow дизайнера в вашем приложении;
— интеграция с WCF;
— пошаговая диагностика непосредственно в Workflow дизайнере;
— и многое другое.

Критерии применения

Как известно, каждой технологии своя область применения. Для определения необходимости использования WF при реализации конкретного алгоритма/процесса я применяю 3 критерия:

1. Реализация алгоритма/процесса постоянно меняется.

В нашей компании мы разработали подсистему Workflow, которая является ядром всех продуктов. Имея, к примеру, десятки клиентов наших продуктов, у которых десятки процессов, получаем сотни разных изменяющихся процессов.

2. Процесс/алгоритм имеет длительный срок выполнения.

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

3. Нужно предоставить возможность изменения алгоритма/процесса конечному пользователю без вмешательства программиста.

Мы разработали свой собственный дизайнер, чтобы максимально упростить и облегчить редактирование процессов конечному пользователю (бизнес-аналитику). Это позволяет снять нагрузку с разработчиков. А возможность видеть и самим с легкостью менять свои процессы очень привлекательна для клиентов.

Это, конечно, не статья, а небольшая путевая заметка, но тем не менее. Так получилось, что 99% архивов попадают на мой компьютер, чтобы быть тут же распакованными, дабы добраться до их содержимого. И если в маке сафари сам это делает за меня, то в windows приходится каждый раз нажимать пункт в контекстном меню.

В какой-то момент мне это безумно надоело и я написал простой сервис, который распаковывает все самостоятельно. Мне он показался удобным и я решил поделиться с народом.

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

Итак, грехи:

1. Медлительность
2. Блокирующее взаимодействие
3. Неуместные ограничения
4. Ненастроенность
5. Несамостоятельность
6. Забывчивость
7. Гордыня

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

В последние годы тема юнит-тестов, регрессивного тестирования, continuous integration, TDD, BDD, etc становится все популярней и все больше разработчиков начинают активно применять данные техники в своих проектах. При этом отдельным вопросом встает проблема автоматического тестирования пользовательского интерфейса в десктопных приложениях. В этой статье я постараюсь рассмотреть уже существующие решения, а так же привести вариант своего велосипеда написания тестов для UI на .net.

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

Но зачастую всё бывает иначе. Сайт запущен, а клиентов не прибавляется. В то же время у конкурентов дела идут как нельзя лучше. Заказчик обвиняет во всем разработчиков сайта, обращается к новым разработчикам, сайт переделывается, но история повторяется. В чем же ошибка? Давайте разберемся.

Сделать в России простую и удобную платёжную систему как для продавца, так и для покупателя — серьёзный вызов для любого UX-специалиста/проектировщика интерфейсов. Чем интереснее и сложнее задача, тем больше опыта и знаний получаешь в процессе работы. Именно над такой задачей я работаю и в этой статье хотел бы поделиться полученным опытом по перепроектированию и доработке системы интернет-платежей A1Pay.

В статье рассмотрены этапы работы, решения, которые были приняты и то, на чём они основывались. Описать в одной статье все интересные идеи, возникшие трудности и их решения, находки и т.д. -. не простая задача. Часть важных вопросов, например, измеряемые KPI и их значения, по понятным причинам, остались совсем за рамками.

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

Проблема в том, что никто не знает, как на самом деле писать классный софт быстро и правильно. Waterfall благополучно скончался на рубеже веков, а новые методы разработки (agile) пока не могут решить фундаментальные проблемы.