Обновился неделю назад. Впечатления довольно приятные, обратно откатываться не планирую. Иногда падают приложения, иногда «рабочий стол» перестаёт отвечать. Проблемы эти возникают редко и меня сильно не беспокоят. По отзывчивости ухудшения(и улучшения) не заметил. Возможно, что чуть больше жрет батарейку. Новые универсальные приложения Mail/Calendar/Groove Music выглядят свежо. Со старыми проблем тоже не возникло. Разве что VK при запуске показывает прямоугольник.
В какой-то момент обновления, правда, телефон впал в цикл «шестеренки > reboot > Nokia logo > шестеренки». После часа наблюдения за тем, как мучается телефон, я решил его всё же прибить. В итоге накатил официальную Lumia Denim с потерей данных. После этого обновление до 10ки успешно завершилось. Грешу на то, что многочисленные Developers Preview, которые я ставил до этого, не пошли системе на пользу :-)
Слот памяти, кстати, обещают в Lumia 950. В основном именно из-за слота памяти и адекватных размеров экрана до сих пор сижу на 820.
Сброс состояния приложения во многом зависит от разработчиков конкретных приложений, как и неприлично долгий Resuming. После обновления до Windows 10, кстати, стал замечать, что приложения, которыми я пользовался недавно, восстанавливаются моментально. Я подозреваю, что они вовсе не удаляются из памяти какое-то время. Возможно, что это было и в 8.1.
Меня больше разочаровывает отсутствие каких-то видимых изменений в Windows 10, хотя Settings наконец-то стал более адекватным. Я с удовольствием бы почитал о том, что же изменилось внутри.
Вот здесь есть сравнение производительности наиболее известных сериализаторов в .NET: theburningmonk.com/2015/04/binary-and-json-benchmarks-updated-2
Кстати, если верить результатам, то некоторые JSON сериализаторы уже почти догнали protobuf, а в некоторых ситуациях могут и обгонять (по-крайней мере по тестам самих авторов).
Поддержку комментаторов выше. Примеры 1-4, по-крайней мере в том виде, в котором вы их описали, — это следствие неправильного использования ООП, попробуйте посмотреть в сторону принципов SOLID.
Название статьи исказило смысл оригинала. В оригинале это всё же не «признаки хорошего интерфейса», а идеи, как повысить конверсию и улучшить user experience. Причем именно идеи, которые на тех или иных проектах увеличили те или иные показатели, а не руководство к действию. Отсюда и спорность этих «признаков», так как не все из них можно назвать «хорошим интерфейсом». Тот факт, что «ценовая иллюзия», к примеру, увеличила продажи на 5% в американском магазине нижнего белья, ещё не указывает на то, что это хороший интерфейс. И не факт, что это сработает в магазине, торгующем гаджетами.
Асинхронная регистрация — это довольно странный подход. Особенно, если решается задача асинхронной инициализации компонент. Почему бы не зарегистрировать компоненты отдельно, а уже затем в подходящий момент срезолвить все нужные компоненты и инициализировать их? В этом случае метод Initialize будет возвращать Task, компоненты можно срезолвить при старте приложения в нужном порядке, и вызвать соответствующие методы.
Плюсы:
1) мухи и котлеты будут отдельно — регистрация зависимостей занимается только своим делом.
2) инициализация будет асинхронной и за асинхронность отвечает сам компонент. Это чуть более правильно, так как Task — это не обязательно поток, вполне возможно, что внутри компонента происходят IO операции, которые можно запустить асинхронно.
Когда открываешь сравнительно простой чужой проект с точки зрения бизнес-логики и видишь в инициализации IoC-контейнера адскую мешанину из многоэтажных конструкций RegisterType, Resolve и InjectionConstructor, то… тоска и желание закрыть это и больше никогда не открывать. Очень тяжело разобраться сходу какая реализация интерфейса будет использоваться в качестве зависимости (реализаций часто несколько), какой конструктор вызван и т.д.
Это факт, что Unity имеет чрезмерно усложненный API, но здравомыслящие программисты обычно оборачивают его в нечто более понятное. Более того, если регистрация компонент сложна, состоит из каких-то хитро-закрученных кастомных регистраций, и компоненты имеют по двум-трем конструкторам, то это вероятнее всего сигнализирует о проблемах в архитектуре. Я работал с очень сложными проектами, где вся регистрация сводится по сути к чему-то вроде container.RegisterSingleton<SomeService, ISomeService>() или container.RegisterPerRequest<SomeService, ISomeService>().
Я всегда считал, что нормальный Senior Developer должен прекрасно разбираться в первых четырех пунктах, и хотя бы в общих чертах понимать что-то в остальных. Ну и драйвера уметь писать.
Это не будет работать, т.к.:
1) Миллионы леммингов всё же ошибаются.
2) Система основана на субъективном мнении, а субъективным мнением легко манипулировать. И к объективной реальности это мнение не имеет никакого отношения. Вы можете считать человека идиотом, но в то же время он может делать действительно полезное дело. Обычные люди вообще порой не способны воспринять точку зрения умного человека.
3) Я боюсь, что в России можно с легкостью найти 100 000 недалеких людей.
не имеют возможности общаться с пользователями других социальных сетей без самостоятельного подключения к ним, а подчас не видят и их пользовательские страницы с начальными биографическими данными. Я вижу в этом перспективу для возрождения и повторного стремительного роста популярности Фидонета.
Простите, но не вижу никакой связи между невозможностью общения пользователей разных социальных сетей между собой, и стремительным ростом популярности Фидонета. В контексте социальных сетей, фидо — по сути такая же социальная сеть, пользователи которой не имеют возможности общаться с пользователями других социальных сетей. И пользователи других социальных сетей не могут общаться с пользователями фидо. Так в чём по сути принципиальная разница между фидо и тем же вконтактиком, за исключением, конечно, несколько разных аудиторий, если рассматривать именно аспект общения?
Мне нравится разговаривать с людьми, глядя на них, в то время как я продолжаю печатать текст/код. Выглядит довольно забавно :-) Буфер, правда, быстро кончается и приходится прерываться, чтобы занести в буфер следующий кусок текста.
TypeScript пока что сыроват, плагин для студии полог глюков, тормозов и время от времени подвешивает студию намертво (разумеется при работе с более или менее большим проектом). Сам компилятор не всегда обратно совместим, и пока что TypeScript подходит лишь для экспериментов. Возможно, что через год он достигнет определенной стабильности.
Не понятно, за что минусуют. Если верить ФЗ РФ «ОБ ОСНОВНЫХ ДОКУМЕНТАХ, УДОСТОВЕРЯЮЩИХ ЛИЧНОСТЬ ГРАЖДАНИНА РОССИЙСКОЙ ФЕДЕРАЦИИ» от 17 октября 2003 года:
Статья 1. Основные документы, удостоверяющие личность гражданина Российской Федерации
3. К основным документам относятся:
…
паспорт гражданина Российской Федерации для выезда из Российской Федерации и въезда в Российскую Федерацию, удостоверяющий личность гражданина Российской Федерации за пределами территории Российской Федерации и на территории Российской Федерации в случае, предусмотренном настоящим Федеральным законом (далее — заграничный паспорт);
…
Статья 17. Назначение заграничного паспорта
1. Заграничный паспорт, оформленный и выданный гражданину Российской Федерации в соответствии с настоящим Федеральным законом и Федеральным законом «О порядке выезда из Российской Федерации и въезда в Российскую Федерацию», удостоверяет личность гражданина Российской Федерации за пределами территории Российской Федерации, а также при выезде из Российской Федерации и въезде в Российскую Федерацию.
2. В случае въезда в Российскую Федерацию и пребывания на территории Российской Федерации гражданина Российской Федерации, имеющего место жительства за пределами территории Российской Федерации и не имеющего паспорта, его личность до получения паспорта удостоверяется заграничным паспортом.
Поддерживаю, паттерны как таковы, скорее нужны для объяснения своей идеи другому разработчику. Паттерн — это не кирпич, и не бетонная плита, вы не построете приложение из паттернов, как дом из кирпичей. это скорее «best practices», это советы и рекомендации. Это как набор типичных дебютов в шахматах — знать полезно, но целиком игру на одном лишь знании дебютов не выиграть, да и иногда для победы бывает полезно использовать какой-нибудь нетипичный дебют.
Рано или поздно, проектируя сложную систему, вы так или иначе придёте к паттернам, но, зная лишь паттерны и не имея опыта, вряд ли у вас получится действительно красивая система.
P.S. ИМХО, олимпиаднику сложно объяснить значение паттернов :-) В спортивном программировании практически не требуется умение проектирования систем.
Дело во вкусах, конечно, хотя я перешел из-за:
1) Кроссплатформенность.
2) Ctrl+P. Возможность перейти к любому файлу по его имени или частям имени. Удобно при работе с проектом. Не сомневаюсь, что в NPP такое тоже есть, но сходу не обнаружил.
3) Удобный пакетный менеджер. Например, в NPP найти плагины для SVN не так просто, так как нет поиска. Плюс множество различных плагинов. Вероятно плагины для Sublime писать проще.
4) Ориентированность на работу с клавиатурой.
5) Нравится внешний вид и интерфейсные решения. У меня стоит тема Soda. По поводу интерфейсных решений — множество мелочей. Например, при поиске по Ctrl+F в NPP нужно нажать Ctrl+F, ввести текст, нажать enter, потом esc (чтобы скрыть мешающее окошко поиска), и далее F3 для дальнейшего поиска. В Sublime же Ctrl+F, текст (вы уже получите первое вхождение), и для просмотра каждого следующего результата enter. И т.п., довольно много приятных мелочей.
В целом, я считаю Sublime хорошим редактором для программирования в тех случаях, когда не нужна полноценная IDE. Основной минус — долго запускается, плохо работает с большими файлами, и в целом медленнее NPP.
Красиво, конечно, минималистично, но лично для меня совершенно бесполезно. Я убежден, что человек использует прогноз погоды в нескольких ситуациях:
1) Узнать текущую погоду за окном и дальнейшую динамику в течение дня/ночи.
2) Узнать динамику погоды на ближайшую неделю.
Текущее приложение не решает ни одну из этих задач. Динамики в течение дня нет, а для просмотра погоды на неделю приходится делать N кликов.
Кроме того, вместо Санкт-Петербурга почему-то меня перекинуло в Одессу по умолчанию, хотя тот же Google определяет даже район, в котором я нахожусь.
Да, конечно, такая проблема есть всегда, когда поверх одной системы строится другая, чуть более упрощенная и призванная скрыть детали реализации первой. Закон дырявых абстракций, как назвал это Джоэль Спольски. Согласен, что это не имеет прямого отношения к концепции ORM. Просто хотел напомнить, что у любого инструмента, у ORM, у SQL, у использованного фреймворка, у использованных протоколов, у железа, и т.п. есть ограничения и узкие места, о которых нужно помнить, и что серебряной пули не может быть. Причем, чем сложнее сценарий использования, тем чаще натыкаешься на узкое место, поэтому постоянно приходится балансировать между полученными выигрышем по одним из критериев и проигрышем по другим.
Во втором случае там не просто Join, а выборка задач клиентов, проживающих в стране, у которой среди государственных языков присутствует английский. Ну т.е. 4 join'а.
В этом, кстати, кроется проблема ORM — дырявая абстракция. Да, Linq2SQL/EF сам сгенерирует правильный запрос, и в некоторых случаях даже более оптимальный, чем написали бы некоторые программисты, но иногда люди забывают, что кроется за «Client.Address.Country.Languages.Contains», и что вероятнее всего есть более простой и оптимальный способ решения задачи.
В какой-то момент обновления, правда, телефон впал в цикл «шестеренки > reboot > Nokia logo > шестеренки». После часа наблюдения за тем, как мучается телефон, я решил его всё же прибить. В итоге накатил официальную Lumia Denim с потерей данных. После этого обновление до 10ки успешно завершилось. Грешу на то, что многочисленные Developers Preview, которые я ставил до этого, не пошли системе на пользу :-)
Сброс состояния приложения во многом зависит от разработчиков конкретных приложений, как и неприлично долгий Resuming. После обновления до Windows 10, кстати, стал замечать, что приложения, которыми я пользовался недавно, восстанавливаются моментально. Я подозреваю, что они вовсе не удаляются из памяти какое-то время. Возможно, что это было и в 8.1.
Меня больше разочаровывает отсутствие каких-то видимых изменений в Windows 10, хотя Settings наконец-то стал более адекватным. Я с удовольствием бы почитал о том, что же изменилось внутри.
Кстати, если верить результатам, то некоторые JSON сериализаторы уже почти догнали protobuf, а в некоторых ситуациях могут и обгонять (по-крайней мере по тестам самих авторов).
Плюсы:
1) мухи и котлеты будут отдельно — регистрация зависимостей занимается только своим делом.
2) инициализация будет асинхронной и за асинхронность отвечает сам компонент. Это чуть более правильно, так как Task — это не обязательно поток, вполне возможно, что внутри компонента происходят IO операции, которые можно запустить асинхронно.
Это факт, что Unity имеет чрезмерно усложненный API, но здравомыслящие программисты обычно оборачивают его в нечто более понятное. Более того, если регистрация компонент сложна, состоит из каких-то хитро-закрученных кастомных регистраций, и компоненты имеют по двум-трем конструкторам, то это вероятнее всего сигнализирует о проблемах в архитектуре. Я работал с очень сложными проектами, где вся регистрация сводится по сути к чему-то вроде container.RegisterSingleton<SomeService, ISomeService>() или container.RegisterPerRequest<SomeService, ISomeService>().
1) Миллионы леммингов всё же ошибаются.
2) Система основана на субъективном мнении, а субъективным мнением легко манипулировать. И к объективной реальности это мнение не имеет никакого отношения. Вы можете считать человека идиотом, но в то же время он может делать действительно полезное дело. Обычные люди вообще порой не способны воспринять точку зрения умного человека.
3) Я боюсь, что в России можно с легкостью найти 100 000 недалеких людей.
Простите, но не вижу никакой связи между невозможностью общения пользователей разных социальных сетей между собой, и стремительным ростом популярности Фидонета. В контексте социальных сетей, фидо — по сути такая же социальная сеть, пользователи которой не имеют возможности общаться с пользователями других социальных сетей. И пользователи других социальных сетей не могут общаться с пользователями фидо. Так в чём по сути принципиальная разница между фидо и тем же вконтактиком, за исключением, конечно, несколько разных аудиторий, если рассматривать именно аспект общения?
Статья 1. Основные документы, удостоверяющие личность гражданина Российской Федерации
3. К основным документам относятся:
…
паспорт гражданина Российской Федерации для выезда из Российской Федерации и въезда в Российскую Федерацию, удостоверяющий личность гражданина Российской Федерации за пределами территории Российской Федерации и на территории Российской Федерации в случае, предусмотренном настоящим Федеральным законом (далее — заграничный паспорт);
…
Статья 17. Назначение заграничного паспорта
1. Заграничный паспорт, оформленный и выданный гражданину Российской Федерации в соответствии с настоящим Федеральным законом и Федеральным законом «О порядке выезда из Российской Федерации и въезда в Российскую Федерацию», удостоверяет личность гражданина Российской Федерации за пределами территории Российской Федерации, а также при выезде из Российской Федерации и въезде в Российскую Федерацию.
2. В случае въезда в Российскую Федерацию и пребывания на территории Российской Федерации гражданина Российской Федерации, имеющего место жительства за пределами территории Российской Федерации и не имеющего паспорта, его личность до получения паспорта удостоверяется заграничным паспортом.
Рано или поздно, проектируя сложную систему, вы так или иначе придёте к паттернам, но, зная лишь паттерны и не имея опыта, вряд ли у вас получится действительно красивая система.
P.S. ИМХО, олимпиаднику сложно объяснить значение паттернов :-) В спортивном программировании практически не требуется умение проектирования систем.
1) Кроссплатформенность.
2) Ctrl+P. Возможность перейти к любому файлу по его имени или частям имени. Удобно при работе с проектом. Не сомневаюсь, что в NPP такое тоже есть, но сходу не обнаружил.
3) Удобный пакетный менеджер. Например, в NPP найти плагины для SVN не так просто, так как нет поиска. Плюс множество различных плагинов. Вероятно плагины для Sublime писать проще.
4) Ориентированность на работу с клавиатурой.
5) Нравится внешний вид и интерфейсные решения. У меня стоит тема Soda. По поводу интерфейсных решений — множество мелочей. Например, при поиске по Ctrl+F в NPP нужно нажать Ctrl+F, ввести текст, нажать enter, потом esc (чтобы скрыть мешающее окошко поиска), и далее F3 для дальнейшего поиска. В Sublime же Ctrl+F, текст (вы уже получите первое вхождение), и для просмотра каждого следующего результата enter. И т.п., довольно много приятных мелочей.
В целом, я считаю Sublime хорошим редактором для программирования в тех случаях, когда не нужна полноценная IDE. Основной минус — долго запускается, плохо работает с большими файлами, и в целом медленнее NPP.
1) Узнать текущую погоду за окном и дальнейшую динамику в течение дня/ночи.
2) Узнать динамику погоды на ближайшую неделю.
Текущее приложение не решает ни одну из этих задач. Динамики в течение дня нет, а для просмотра погоды на неделю приходится делать N кликов.
Кроме того, вместо Санкт-Петербурга почему-то меня перекинуло в Одессу по умолчанию, хотя тот же Google определяет даже район, в котором я нахожусь.
habrastorage.org/storage2/1a3/605/2c9/1a36052c9ded63f465e7a42a5514f8ee.png
Что, как вам кажется, читается проще?
В этом, кстати, кроется проблема ORM — дырявая абстракция. Да, Linq2SQL/EF сам сгенерирует правильный запрос, и в некоторых случаях даже более оптимальный, чем написали бы некоторые программисты, но иногда люди забывают, что кроется за «Client.Address.Country.Languages.Contains», и что вероятнее всего есть более простой и оптимальный способ решения задачи.