Результаты ежегодного исследования StackOverflow — про технологии, зарплаты, счастье и кофе

Про зарплату «на руки» в оригинальном тексте не говорится. Конечно же, считается просто годовая белая запрлата.

Часть команды, часть корабля

Спасибо. Да, в старом ИБ дата рождения отображается верно. Судя по вашему официальному твиттеру — это известный баг.

Часть команды, часть корабля

При первом логине в новый ИБ мне показали ссылку на старую версию, теперь её не найти.
Из того, что я заметил: в новом ИБ дата моего рождения указана неверно (отличается на один день). Можно ли получить ссылку на старый ИБ и сравнить? Если они там разные, то буду репортить вам баг.

Поговорим про отличия Mono от MS.NET

Помнится, году в 2012-м мы пытались портировать Silverlight-приложение на Moonlight, закопались в проблемах и багах. В итоге нашли такой печальный твит:
twitter.com/migueldeicaza/status/263816476551700481
и официально отказались от поддержки мунлайта.
С тех пор что-то изменилось?

MVVM Framework для Windows Phone своими руками. Часть 1

Можно пойти дальше.

UI-related свойства у ViewModel автоматически дают нам следующие «преимущества»:
* ViewModel получается платформозависимая (без хаков не получится шарить её между SL, WP8, W8 и WP7
* Обламываемся с нормальным запуском юнит-тестов.

Пишите чистый код с Реактивными Расширениями (Reactive Extensions)

Good point, может в этом и дело.

Пишите чистый код с Реактивными Расширениями (Reactive Extensions)

Я в рамках популяризации rx на работе переписал один сервис с TPL на Rx. Код получается компактный, красиво всё пайплайнится, всё читабельно, с небольшии примесями TPL получилась приличная параллелизация. Но итоговая скорость работы меня очень расстроила. Раза в полтора медленнее оригинального кода.
Потратил ещё несколько вечеров на профилирование и оптимизацию, а потом так этот форк и забросил.

Может я их готовить не умею нормально, но для performance critical приложений я бы Rx не рекомендовал.
Хотя, вот, Netflix свои сервера на Rx-Java пишут, и вроде довольны.

Еще раз про учебу и работу ИТ-шника в Германии

Вот вам ещё плюсов:
* хороший интернет
* дешевая мобильная связь

Статистика российских IT-специалистов на stackoverflow.com и github.com

Там дело и происходило. На careers можно в описании вакансий указывать so профили сотрудников. Так я и заинтересовался компанией.

Статистика российских IT-специалистов на stackoverflow.com и github.com

Узнавать людей — это хороший бонус. Я так откликался на вакансию в другой стране только лишь из-за того, что в компании работал человек, которого я по SO знаю. На скорость с ним отвечали :)

Статистика российских IT-специалистов на stackoverflow.com и github.com

Бытро появляются ответы на базовые вопросы типа «как прочитать файл на c++?».
Если же вы специалист по какой-нибудь теме, то отвечать на вопросы не напряжно. Тем более, что это позволяет ещё больше прокачаться в данной области.
На простые вопросы отвечать не очень интересно, но начинающий разработчик может поучиться изясняться на иностранном языке. Это как с блогами и статьями или преподаванием: учишься сам, объясняя другим.

Потокобезопасные события в C# или Джон Скит против Джеффри Рихтера

Общий ресурс — это уже другая проблема. Для наблюдаемого объекта нет опасности получить NRE и ObjectDisposedException. А это именно та проблема, которая описывается в статье.

Потокобезопасные события в C# или Джон Скит против Джеффри Рихтера

Так у вас всё та же подписка на события, коллбэки и прочее. Это ни чем концептуально не отличается от механизма event-ов, о которых говорится в статье. А выше предлагают другой механизм, без коллбэков. Где push-модель заменяется на pull (подписчик сам берёт сообщение из очереди, если оно ему нужно). Получается, что у наблюдаемого объекта нет коллекции колбэков, а это значит, что никто обработчик события не вызовет, если наблюдатель этого уже не хочет.

Потокобезопасные события в C# или Джон Скит против Джеффри Рихтера

Так вот в случае fire-and-forget мы выкинули сообщение и не знаем про подписчиков. Т.е. для нас отправка сообщения атомарна. Мы просто кладём его в очередь.

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

Потокобезопасные события в C# или Джон Скит против Джеффри Рихтера

Ну, почему же? Если рассматривать событие, как «сообщение», то асинхронная отправка сообщения через некую шину проблему решает. Если кто-то отписался, значит сообщение не дойдёт к такому подписчику.

Reactive Extensions: клиент для условного api со стратегией Cache-Aside & Refresh-Ahead

Я ваш код на C# перевёл. Вот, что у меня получилось: RxHabraClient

.WithCache получился даже generic и не зависящий от ICache. Пожалуй так даже и лучше.

 public static IObservable<T> WithCache<T>(this IObservable<T> source, 
                                                Func<T> get, 
                                                Action<T> put) where T : class
        {
            return Observable.Create<T>(observer =>
            {
                var cached = get();
                if (cached != null)
                {
                    observer.OnNext(cached);
                }
                source.Subscribe(item =>
                {
                    put(item);
                    observer.OnNext(item);

                    observer.OnCompleted();
                }, observer.OnError);
                return Disposable.Empty;
            });
        }

И его использование:

.WithCache(() => Cache.GetCachedItem(userName), model => Cache.Put(model))

Reactive Extensions: клиент для условного api со стратегией Cache-Aside & Refresh-Ahead

Эх, в C# так просто объект из интерфейса не создать.

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

Reactive Extensions: клиент для условного api со стратегией Cache-Aside & Refresh-Ahead

Ну, что я могу сказать? Снимаю шляпу — получилось достойно.

Не очень только понял в чём выгода с отдельным кэшем для каждого конкретного ключа?

Reactive Extensions: клиент для условного api со стратегией Cache-Aside & Refresh-Ahead

Ох, надеюсь вы не всерьёз критикуете максимально упрощённый демо-код? :) Замечания-то правильные, продакшн-код был бы другой.

Что касается MVVM, то использовал разные: как самописные, так и стандартные (MVVMLight и надстройки над старым форком CalibrumMicro). Связку из Xamarin и MvvmCross использовал дома, а потом кончился триал.

Rx под Xamarin работают нормально. GitHub своё Android приложение пилит на Xamarin и там активно используют Rx и Rx-UI.

Reactive Extensions: клиент для условного api со стратегией Cache-Aside & Refresh-Ahead

А можно подробнее про кэширование в виде Observable? Мне с ходу приходит в голову лишь асинхронная модель положили-достали.