По Таллину рассчет неверный. По сути налоги там платят также, как и в России, и социалку и налог платит работодатель. Gross не учитывает социалку, т.е. Netto = Gross — 21%.
Ну и считаю некорректными сравнивать товары и аренду. По опыту разница цены товаров обычно сильно меньше (если вообще есть), чем разница цены аренды (может различаться в разы). Например, если молоко стоит одинаково, то аренда может быть в несколько раз выше.
Не сравнивали, мы не ставили себе подобной задачи, а потому и не копали в этом направлении. Хотя я не думаю, что на столь простом приложении мы бы смогли получить какие-то серьезные результаты.
Согласен, тут скорее вопрос стилистики статьи. Мне не очень нравится, когда куча кода под спойлерами. Если можно вставить короткий кусок кода, но inline, то мне кажется это будет чуть более читабельно. А для копирования мы специально репу сделали. Но, еще раз повторюсь, я не претендую на то, что мой подход самый правильный.
Поисследовал подробнее. Да, все не так радужно, как я писал ранее, извиняюсь за дезинформацию. Для разработки конечных приложений будет нужна хостовая MacOS машина. Мы же у себя разрабатываем компоненты под Xamarin.Forms. Вот их можно билдить и под Windows. Поправил текст статьи.
Просто процитирую текст из статьи: «Все классы моделей и вью моделей будут реализовывать интерфейс INotifyPropertyChanged. Его реализацию в приводимых примерах кода я уберу для лаконичности.»
Нет, я думал просто о примерах чуть более близких к реальным приложениям. Банальный TODO лист уже лучше. Тут и несколько бОльшее количество компонентов, и как реализована работа с данными, банальные MVC/MVVM можно показать, и компоненты чуть более сложные и многогранные. Можно потенциальные косяки показать, как, например, невозможность в Xamarin Forms отключить селекшен в ListView без ухода на уровень рендеров. Наверняка в Kivy тоже есть что-то подобное. Или наоборот, все здорово и пройти по косякам конкурентов и показать как тут все удобно и хорошо получается.
Грубо говоря, если я щас на формсах напишу такой же пример, при этом любому WPF-нику он будет понятнее, чем ваш код, просто банально в силу более привычного синтаксиса и почти того же фреймворка, то я докажу что Xamarin — фреймворк №1? Нет, я просто напишу анимированные кнопки, не более того :)
Ну люди не обязательно читают все статьи. Я вот читал только эту. Здесь приведено утверждение и нет доказательства. Если оно есть где-то еще, можно было дать кросс линк, было бы интересно глянуть.
Под платформами я и имел в виду фреймворки :)
Приложение с тремя анимированными кнопками и реакцией на нажатие на них… это гораздо ближе к Hello World, чем к реальным приложениям.
Я вот что-то из статьи не понял. А чем этот фреймворк лучше ксамарина или реакта? Ну кроме того, что он подойдет тем, кто кроме питона других языков не знает? Я не защищаю ни реакт, ни ксамарин, ни в коем случае, они достаточно проблем имеют. Просто автор в начале наехал на эти платформы, а потом рассказал как классно на Kivy писать Hello World. Мне казалось, что после подобного начала должно быть сравнение платформ и разбор почему же Kivy лучше. Однако, высказывания так и остались без доказательств.
Если на продукт из 3-х разработчиков уже требуется один PMM, то боюсь представить сколько их в IntelliJ IDEA :) Если не секрет, есть какая-то корреляция между размером команды и количеством Product Marceting Manager-ов? Или просто 1 PMM на 1 команду, вне зависимости от ее размера?
Я извиняюсь за, возможно, ответы немного невпопад. Дело в том, что сейчас готовится еще одна статья, где как раз будет решаться задача, для которой мы когда-то думали использовать сравнение OriginalSource и sender, но не подошло, по причинам, которые я описал в первом комментарии. Вот я немного мыслями там :)
Да, в задаче фильтрации эвента фокуса ваш подход выглядит лучше. Просто для статьи мы немного адаптировал наш подход, который сложнее, чем описанный тут, вот и получилось такое решение :)
В OriginalSource будут лежать внутренние потроха контрола, которые нам скорее всего ничего не скажут. Для примера, если посмотреть OriginalSource у PreviewMouseDown эвента кнопки, то там будет либо Border, либо TextBlock (в зависимости от того, где клик произойдет). А если еще учесть, что мы подписаны на эвенты у Control, то становится понятно, что в данном случае никогда sender не будет равен OriginalSource, так как Border и TextBlock не являются его наследниками, а значит они нам эвент не пришлют.
Ну и считаю некорректными сравнивать товары и аренду. По опыту разница цены товаров обычно сильно меньше (если вообще есть), чем разница цены аренды (может различаться в разы). Например, если молоко стоит одинаково, то аренда может быть в несколько раз выше.
Но, лично я их пока еще не использовал, так что подробно про них ничего сказать не могу.
Xamarin позволяет iOS под виндой собирать.
Грубо говоря, если я щас на формсах напишу такой же пример, при этом любому WPF-нику он будет понятнее, чем ваш код, просто банально в силу более привычного синтаксиса и почти того же фреймворка, то я докажу что Xamarin — фреймворк №1? Нет, я просто напишу анимированные кнопки, не более того :)
Под платформами я и имел в виду фреймворки :)
Приложение с тремя анимированными кнопками и реакцией на нажатие на них… это гораздо ближе к Hello World, чем к реальным приложениям.
Да, в задаче фильтрации эвента фокуса ваш подход выглядит лучше. Просто для статьи мы немного адаптировал наш подход, который сложнее, чем описанный тут, вот и получилось такое решение :)