Если в приложении есть нативный компонент, то оно должно поставляться с бинарниками для разных версий ARM.
Во-первых, многие разработчики банально не думают о поддержке старых инструкций — ведь у каждого пользователя будет телефон 3-хмесячной давности с 4-7дюймовым экраном и тремя-четырьмя ядрами в процессоре, правда?
А во-вторых, лишний бинарник увеличивает размер приложения — и не каждый хочет жертвовать размером скачиваемого кода. Андроид не дает возможности определить архитектуру процессора и «докачать» нужные версии бинарников из соображения безопасности. В свое время за это ругали Opera Mobile: my.opera.com/mobile/blog/the-components-of-opera-mobile-11-on-android
Стал в версии 2.2. До этого JIT в Дальвике не было.
Помню, как мне подарили HTC Wildfire на новый год, и он шел с 2.1. И как прилетел апдейт на 2.2 где-то в феврале-марте. Ускорение было заметно невооруженным глазом.
Автор, скажите, а зачем вы X-UA-Compatible отдаете в метатеге, а не в хедере? Микрософт же сами, когда анонсировали X-UA-Compatible, заявляли, что хедер — предпочтительнее, а метатег — это решение для тех, у кого нет доступа к серверу и нет возможности хедеры проставить.
Начиная с определенного уровня опыта (~4-5 лет) чистый доход специалиста в наших странах опережает таковой в Европе из-за разницы в структуре налогообложения. В США очень многие вещи — пенсионные и страховые отчисления — добровольное дело каждого, поэтому переезд туда может быть экономически оправдан.
7-8 часов — это обычное дело в компании, где ценится качество инженеров. Я в своей карьере сталкивался с интервью-марафонами раза 3-4, а общее число пройденным мной интервью наверняка перевалило за 70. Так вот, всегда — всегда — такой марафон — это самый верный признак того, что и компания вам понравится, и вы компании. Причем это будет именно «работа мечты».
Сейчас в такой компании работаю. О наших интервью-марафонах в городе почти никто не знает, т.к. проходят до конца только единицы из кандидатов — 1 из 150 примерно. Большинство получают стандартные 40 минут общения и «до свидания».
Решение не лучшее. Подобных решений в последнее время появляется много, и в ходе обсуждений указывается один и тот же недостаток. А именно: рендеринг страниц с помощью PhantomJS занимает время. Фантом — штука неповоротливая, да и загрузка ресурсов большого приложения может занимать время. В результате ответ на запрос поискового бота приходит с большой задержкой. В свою очередь, некоторые поисковики (Google) снижают вес вашего контента в выдаче.
Пока что наиболее рекомендуемый вариант — это оставить нормальный статический контент в -тегах. Так, например, поступает Discourse. Сам клиент написан на EmberJS и использует HTML5 History API для навигации. Пользователи видят обычные урлы, которые могут постить где угодно. Но если по урлу приходит поисковый бот, то он видит контент внутри -тега. На сервере реализовано это довольно просто: ребята сели и написали простые темплейты, которые отображают текст для поисковика. По словам одного из разработчиков (слышал интервью в каком-то подкасте), заняла вся работа у них около недели. Поскольку Ember — url-driven фреймворк, то на каждый чих у ребят в приложении уже есть урл. Handlebars — не DOM-темплейты, а строковые темплейты, поэтому не требуют наличия какой-то исполняемой JS-среды на сервере: ни jsdom, ни Phantom, поэтому страница отдается браузеру быстро.
Как мне кажется, количество публикуемых оригинальных технических статей на Хабре сильно уменьшилось за последние года 3-4. Но все равно, если появляются, то такие классные, что просто Ух! Так что не скажу, что ресурс загибается.
С другой стороны, какие-то старые форумы отживают свой век, потому что пользователи уходят на тот же StackOverflow. Но это разве плохо?
Так что да, не согласен я с этим аргументом автора, как и во многими другими.
Я ходил к логопеду несколько лет в разное время. Только после 25 перестал пытаться хоть что-то сделать. Картавлю. У меня в компании работает классный разработчик, который заикается. Заика выступает несколько лет подряд на JSConf, причем его доклады — одни из лучших.
Хм, а с чем может быть связано, что у меня отображается по умолчанию старый вариант сновой вкладки? Вообще до вашего поста никогда не видел ничего подобного. Сижу на Canary.
Кстати, в Coast и mobile.twitter.com, и TweetDeck совершенно неюзабельны: если кликнуть по ссылке и уйти на другой сайт, а потом вернуться, то страница либо жутко тормозит, либо не может нормально вернуться, либо вообще браузер роняет. Я бы на вашем месте для них сделал исключение и открывал ссылки в отдельной табе/приложении.
> В связи с предстоящим выходом на IPO, твиттер выпустил обновлённое приложение, включающее в себя несколько новых возможностей и, конечно, редизайн под 7 версию iOS.
Ага, так и представляется себе, сидят менеджеры в Твиттере и решают: «А что бы нам такое сделать, чтобы IPO прошло нормально? Точно — сделаем приложение для iOS!»
Будущее виджетам предрекают еще со времен Opera Widgets, Yahoo Widgets, Vista Gadgets и Mac Gadgets. Кроме них еще были IE8 Web Slices, и бесчетное множество реализаций на JavaScript, включая OpenSocia, Caja, Yahoo App Platform и т.д. Web Components и Iframely в этом плане — очередные боянистые попытки, которые ничего нового не приносят по сравнению с прежними идеями.
CI должен собирать все ветки, а не ждать, пока изменения смержат в Dev.
А так нормально. У нас разработка в мастере, а релизы в отдельных ветках, для каждого энва свои ветки. Используем бранчи, а не таги, т.к. бывают всякие случаи, когда коммиты приходится с мастера черрипиком переносить. Например, когда одна из фич должна попасть в релиз, а какая-то другая — еще нет.
Часто используют JAX-RS или что-то подобное в сочетании со статическим фронтендом. При этом фронтенд часто пишут на JS (или компилируемых в него языках) и оформляют в виде отдельного проекта, в которм ни строчки кода на Java. Результатом сборки является набор статических файлов, которые заливают на CDN. Общение между фронендом и бекендом либо через ajax, либо по вебсоккетам. UI в привычном понимании в Java-проекте отсутствует: сервер просто предоставляет API.
Во-первых, многие разработчики банально не думают о поддержке старых инструкций — ведь у каждого пользователя будет телефон 3-хмесячной давности с 4-7дюймовым экраном и тремя-четырьмя ядрами в процессоре, правда?
А во-вторых, лишний бинарник увеличивает размер приложения — и не каждый хочет жертвовать размером скачиваемого кода. Андроид не дает возможности определить архитектуру процессора и «докачать» нужные версии бинарников из соображения безопасности. В свое время за это ругали Opera Mobile: my.opera.com/mobile/blog/the-components-of-opera-mobile-11-on-android
Помню, как мне подарили HTC Wildfire на новый год, и он шел с 2.1. И как прилетел апдейт на 2.2 где-то в феврале-марте. Ускорение было заметно невооруженным глазом.
Сейчас в такой компании работаю. О наших интервью-марафонах в городе почти никто не знает, т.к. проходят до конца только единицы из кандидатов — 1 из 150 примерно. Большинство получают стандартные 40 минут общения и «до свидания».
Пока что наиболее рекомендуемый вариант — это оставить нормальный статический контент в -тегах. Так, например, поступает Discourse. Сам клиент написан на EmberJS и использует HTML5 History API для навигации. Пользователи видят обычные урлы, которые могут постить где угодно. Но если по урлу приходит поисковый бот, то он видит контент внутри -тега. На сервере реализовано это довольно просто: ребята сели и написали простые темплейты, которые отображают текст для поисковика. По словам одного из разработчиков (слышал интервью в каком-то подкасте), заняла вся работа у них около недели. Поскольку Ember — url-driven фреймворк, то на каждый чих у ребят в приложении уже есть урл. Handlebars — не DOM-темплейты, а строковые темплейты, поэтому не требуют наличия какой-то исполняемой JS-среды на сервере: ни jsdom, ни Phantom, поэтому страница отдается браузеру быстро.
С другой стороны, какие-то старые форумы отживают свой век, потому что пользователи уходят на тот же StackOverflow. Но это разве плохо?
Так что да, не согласен я с этим аргументом автора, как и во многими другими.
Ага, так и представляется себе, сидят менеджеры в Твиттере и решают: «А что бы нам такое сделать, чтобы IPO прошло нормально? Точно — сделаем приложение для iOS!»
Техкранч такой Техкранч.
Не хотите оставить настройку для продвинутых пользователей, чтобы включался режим Мини, а не Турбо?
Но надеюсь, что на этот раз что-то получится!
А так нормально. У нас разработка в мастере, а релизы в отдельных ветках, для каждого энва свои ветки. Используем бранчи, а не таги, т.к. бывают всякие случаи, когда коммиты приходится с мастера черрипиком переносить. Например, когда одна из фич должна попасть в релиз, а какая-то другая — еще нет.