Disposable без границ

Когда эти ресурсы требуют освобождения? Обычно такие объекты регистрируются как синглтон и умирают вместе с процессом. Соответственно, такой объект не должен быть idisposable.

Disposable без границ

Несколько классов зависят от одного disposable класса? Просто не надо так делать.
Лучше? )

Disposable без границ

При использовании Dependency Injection объект класса не только не должен отвечать за жизненный цикл своих зависимостей, он просто физически не может это делать: зависимость может разделяться между несколькими клиентами

Несколько владельцев у одного disposable объекта? Просто не надо так делать.

Анимированное изменение ориентации экрана в приложении Windows Phone

Ага, по-хорошему, приложение должно рассказывать об этом при первом запуске.

PhoneGap vs. Cordova

Смотря что понимать под «html5-приложением». Можно взять WebView и отображать в нём всё, что душе угодно.

Анимированное изменение ориентации экрана в приложении Windows Phone

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

А что в них такого полезного? Ориентация экрана во время работы приложения меняется редко, обычно один раз, чтобы привести его в удобное положение. Зависимость функционала от ориентации, как в калькуляторе — редкость.
Чтобы было больше приложений, оно должно быть если не из коробки, то хотя бы подключаться с помощью нехитрых библиотек. Руками всё это делать мало кто захочет.

Циклические срезы, сдвиги и вращения коллекций

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

Циклические срезы, сдвиги и вращения коллекций

Хвост удобно не включать, поскольку длина выборки тогда легко вычисляется по индексам без лишнего инкремента на единицу и не вызывает путаницы (5-2 = 3 вместо 5-2+1 = 4)

А где тут путаница? Голову включаем, а хвост нет — это скорее ведёт к путанице. Написанное далее в статье является тому подтверждением.

Вызываем обработчики событий потокобезопасно без лишнего присваивания в C# 6

если нужен лишь факт срабатывания события без каких-либо параметров, можно написать

public event Action Foo = delegate {}

и рейзить его очень просто, без метода-обёртки

Foo();

Вызываем обработчики событий потокобезопасно без лишнего присваивания в C# 6

Полагаю, для подавляющего большинства проектов на C# такая потеря производительности не стоит внимания. Но вообще да, надо понимать, что пустой делегат не бесплатен.

Вызываем обработчики событий потокобезопасно без лишнего присваивания в C# 6

1. Это не очень красиво.

Почему? По-моему красивее, чем описанные в статье варианты, в т.ч. c новым оператором.

2. Используем не самый последний список подписчиков.

А разве вариант с?.. решает эту проблему?

Вызываем обработчики событий потокобезопасно без лишнего присваивания в C# 6

А разве нельзя так, без Volatile, Read, Invoke

public event EventHandler Foo = delegate {}

public void OnFoo()
{    
    Foo(this, EventArgs.Empty);
}

?

Третья альфа версия Perspex UI Framework с поддержкой iOS/Android

Можно как в полимере сделать {{My.Property.Path}}.

А почему одинарные скобки нельзя оставить? Потому что конфликтовать с MarkupExtensions будет? А оно поддерживается, кстати?

Третья альфа версия Perspex UI Framework с поддержкой iOS/Android

Очень рад, что XAML живёт и развивается благодаря проектам вроде вашего! Не планируете поддержку web (html5 или может webgl), как замену Сильверлайту?
Насчёт биндингов. Раз уж вы решили сокращать их запись, может вообще избавиться от слова «Binding»? Это как идея :)

Можно ли заниматься разработкой на iPad?

Под него софта для программирования нет пока.

Можно ли заниматься разработкой на iPad?

Не могу ничего сказать на счёт WebStorm, но у меня на Acer W510 вполне приемлемо работала VS 2013. Солюшн не сильно большой, да, где-то с десяток проектов.
И да, если говорить именно о программировании, то устройства на Windows для этого больше походят, нежели iPad.

Любовь или брак по расчету с Dependency Injection?

Что это за опциональные зависимости такие? Типа есть работаю, а нет начинаю менять поведение?

Да. Достигается с помощью создания нескольких конструкторов, либо, как было сказано выше, через property injection. Есть мнение, и я с ним согласен по большому счёту, что это антипаттерн.

Любовь или брак по расчету с Dependency Injection?

И ещё. При использовании Constructor Injection в случае невозможности разрешить зависимость вы получите ошибку сразу при создании объекта зависимого класса, а не неизвестно когда в процессе работы.

Любовь или брак по расчету с Dependency Injection?

На мой взгляд единственный серьёзный аргумент «против» — использование одновременно двух подходов. Остальные — надуманны.
Чем неудобен Constructor Injection?
Писать больше кода? А если сервис нужен в нескольких местах? Писать

GetService<IQuery<IQueryable<DisconnectedAppDomain>, DisconnectedAppFilter>>();

несколько раз?

SafeThreadUpdate() для wpf-контролов

this.ThreadSafeUpdate(() =>Visibility = Visibility.Hidden);

Dispatcher.BeginInvoke(() =>Visibility = Visibility.Hidden);

И чем первое лучше второго? :)

И да, при использовании MVVM с Dispatcher сталкиваешься редко, т.к. Binding свойств — потокобезопасен.