если отсечь от чего-то платного всех иностранных покупателей, актив же ценность потеряет. Т.е. если кому-то нужны шпионские шняги, чтобы в обязаловку их ставить на Российских устройствах или типа того, то могли спокойно форкнуть и в сторонке упражняться, не обязательно убивать корову, которую еще можно доить и доить
то, о чем Вы говорите, не относится к отличникам. Это свойство характера, помноженное на родителей. Могут быть такие же тянутые из последних сил троешники. Или неудачники в футболе и бальных танцах. Психологические проблемы преодолеваются размышлениями и возможно работой с психологом. А не призывами начать пахать на радость всем. Т.е. в вашем тексте я следов преодоления не вижу. Плохо быть отличником, но пахать на радость всем все равно остается лозунгом. Жить на радость себе. Можно даже не пахать, если пахота не приносит радости.
«не возникало проблем» — не равно «никогда не возникнет». Расписываешься, они бумажку рвут и говорят «попробуйте еще раз». Пробуешь еще раз, они тебе дают твой образец и говорят «вот как тут». Я один раз ооочень долго тренировалась. Не знаю, как пожилые справляются, которые еще и видят плохо
вас не парит, а в банке девушек парит. Там они даже хранят бумажку с образцом прошлой подписи, и иногда даже сравнивают. А некоторые вообще с подписью в паспорте сличают
про подписи — в Японии каждому делают печать, чтобы руками не расписываться. Ставишь штампик и все. Я б себе тоже сделала, если бы у нас это дело приняли. Когда ручкой редко пользуешься, большая проблема одинаковую подпись каждый раз изображать.
он для этого просто не предназначен. ИМХО, UWP — это был такой первый шаг к кроссплатформенности, дальше будет Xamarin (если конечно хорошо пойдет). А это и iOs, и андроид, и все на свете. Какие там произвольные бинарники и сервисы Windows?
А про вашу боль — гораздо проще жить, если разрабатывать сразу под UWP и WPF. Там есть общее зерно, многие вещи можно сделать одинаково, если сразу про это думать. А вот если начинать с одной платформы и переувлечься чем-нибудь, что есть только там, то потом под другую платформу портировать может быть тяжело.
это вы к автору или к словарю. Зачем-то есть разные слова. ИМХО, svn это инструмент, который в это сравнение не должен попадать, потому что он про другое. Иначе надо включать сюда операционки и браузеры, которые тоже кто-то может назвать технологиями
про sql-server-2008 скорей всего тэг появился, когда 2008 версия была в бета версии. И естественным образом ушел, когда вышла следующая версия. Тут надо наверное группировать тэги от всех SQL Server'ов и считать их за один. В общем, если добавить корректности, список может получиться совсем другой. Хотя stack overflow каждый год вывешивает свою статистику, вот самая свежая: insights.stackoverflow.com/survey/2017
Технологии, языки и фреймворки там тоже есть, можно сравнить
что именно не так? Т.е. чтобы операционка сказала, что у тебя процессор не той архитектуры, не поставлю-ка я очередной апдейт — это я лично первый раз встречаю. Хотя может быть что-то такое было в каком-нибудь тридевятом обновлении WinXP. В смысле WinForms или WPF сейчас редко что-то меняется, они уже устоялись. А последние обновления Windows касаются в основном Windows 10 как системы и UWP, потому что MS их в данный момент времени параллельно развивает. Не обновилась система — нету акрила и прекрасного гамбургер меню из коробки
когда в коде создаешь — долго перемещается в другое место, вот и все. Расходы на парсинг замла сравнительно со всем остальным — это копейки. Хотя конечно это зависит от кривизны рук и степени понимания, как надо работать с замлом.
Без конкретных примеров холиварить нет смысла, да.
угу, а из c# кода вы конечно же никакое дерево объектов не создаете, а только рисуете как в винформах. Дураки платформу-то делали, не догадывались до этого
ооо. Вы вообще в курсе, как это в рантайме работает? Рантайму вообще все равно, что над чем абстракция. Ему существенно, сделали ли вы так, чтобы тяжелая работа выполнялась видеокартой, или все на CPU повесили. И насколько сложный лейаут. А в коде это сделано или в замле — какая разница-то?
это очень зависит от конкретного юз-кейза. Т.е. в одном случае может быть так, а в другом — наоборот. Зависит от того, как используются байндинги, как переключаются состояния и т.д. Т.е. например можно менять видимость чего-то с помощью байндинга к какому-то свойству, а можно — через VisualStates. Можно сделать хороший темплейт для ячейки грида в xaml, который будет загружаться всего один раз за время жизни приложения и кэшироваться, и при тяжелом UI это может быть быстрее, чем делать то же самое в коде. Ну и т.д. Т.е. тут нет общего решения. Каждый конкретный случай надо смотреть в профайлере. И смотреть не просто развесистые контролы, а в том числе каждую их мелкую часть отдельно.
Или например анимации выполняются на GPU, и это обычно быстрее, чем менять какие-то свойства из кода. Хотя можно и анимации в коде делать, но тут большой разницы не будет, чтобы заморачиваться.
смотря что вы делаете в xaml, и смотря что вы делаете в коде. Испортить можно абсолютно все. Xaml хорош, когда вам надо поддерживать произвольный контент. В одном списке вы хотите показать просто текст, а в другом — кнопки с картинками. Код может быть один, а xaml разный. Писать эту разницу в коде? За счет чего оно будет быстрее?
А про вашу боль — гораздо проще жить, если разрабатывать сразу под UWP и WPF. Там есть общее зерно, многие вещи можно сделать одинаково, если сразу про это думать. А вот если начинать с одной платформы и переувлечься чем-нибудь, что есть только там, то потом под другую платформу портировать может быть тяжело.
Технологии, языки и фреймворки там тоже есть, можно сравнить
Без конкретных примеров холиварить нет смысла, да.
Или например анимации выполняются на GPU, и это обычно быстрее, чем менять какие-то свойства из кода. Хотя можно и анимации в коде делать, но тут большой разницы не будет, чтобы заморачиваться.