• Continuous Integration с Unity
    0
    С Bamboo работал долгое время, больше года. Теперь имею дело с Jenkins. С TeamCity опыта нет.

    Пока мне нравится Jenkins по одной причине — Jenkins Job DSL плагин. Как для разработчика, для меня это была настоящая находка. Я могу генерировать билд планы (проекты?) автоматически с помощью Groovy скрипта. Причем этот скрипт может быть сколь угодно гибким и я получаю возможность использовать Java код, классы, наследование и все эти ООП прелести, плюс кучу библиотек и т.д. и т.д. В Job DSL добавлена поддержка для большинства популярных плагинов и сообщество активно добавляет новые фичи. Можно также генерировать новые View (вкладки), группировать проекты по папкам и многое другое. Короче, легче было бы перечислить что этот плагин не умеет.

    Один из минусов — порог вхождения, но по большому счету выучить Groovy на базовом уровне будет достаточно для начала.

    У Bamboo ничего подобного и близко нет. Насчет TeamCity не знаю.
  • Continuous Integration с Unity
    +1
    Зависит от ваших требований к CI. У автора была задача «CI за день» и UCB с ней справился.

    Если компания достаточно крупная и имеет желание и средства настроить свой CI/CD тогда Jenkins, Bamboo, TeamCity и т.д.
    Мне приходилось раньше работать с Bamboo, сейчас с Jenkins, только специфика — мобильные приложения.

    Конечно преимуществ в своем собственном CI много, только по моему опыту настроить все это дело а потом и поддерживать — задача непростая. Но с другой стороны это очень интересная область и все больше и больше контор, занятых разработкой мобильных приложений, задумываются о серьезном подходе к CI.
  • Подходы к созданию скриптового языка описания настольных игр
    0
    Точно, если спрашивать игроков случайным образом, будет близко к живому оригиналу.
    Вместо «кто первый, тот и успел» будет выбор игрока случайным образом, по-прежнему сохранится элемент такой себе хаотичности и все также можно позволить подкидывать больше положенного, чтобы потом бить на выбор.

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

    Я попробовал практически все варианты Дурака из App Store, везде на данный момент реализован простой подход, когда игроки подкидывают строго по часовой стрелке.
  • Архитектурный дизайн мобильных приложений
    –1
    Скажите пожалуйста, каким образом было достигнуто переиспользование сущности х*як? И как можно избежать разрастания х*яка? :)
  • Подходы к созданию скриптового языка описания настольных игр
    0
    Когда я играл в Дурака в детстве, то можно было и подкидывать одновременно и бить на выбор и т.п., т.е. утверждение «В один момент времени всегда ходит 1 игрок» для такого Дурака — не верно.
    Конечно же, реализовать такую игру гораздо сложнее, особенно если добавить режим мультиплеера. Там уже задачи из разряда синхронизации сразу нескольких процессов, разделенные ресурсы и подобное.
  • Автоматизация тестирования iOS-приложений с применением Calabash и Cucumber
    0
    Это не совсем минусы Calabash. Как я уже сказал, они точно также используют Automator скрипт для сброса симулятора. Т.е. раз их скрипт сломался, то нет гарантии что ваш не сломается точно также. Это на самом деле стандартные заморочки при обновлении Xcode или Mac OS X, всегда есть вероятность что где-то что-то сломается. Ну и даже если что-то сломается фикс рано или поздно найдется. Вот вы например нашли как пофиксить проблему с локалями, по идее ничего не мешает открыть пул реквест с этим фиксом чтобы он попал в следующий релиз Calabash :)

    Да, shell скрипты хороши тем, что их легче использовать повторно. В вашем случае, если вдруг не станет хватать мощностей одной Mac OS машины, и вы добавите еще одну, тогда CI-сервер и агенты подойдут лучше. Но это всегда итеративный процесс, постоянные улучшения — норма.
  • Автоматизация тестирования iOS-приложений с применением Calabash и Cucumber
    0
    Сам занимался этим полтора года на прошлой работе. У Calabash большие перспективы. Основное преимущество по-сравнению с другими фреймворками — очень гибкий язык запросов.

    Calabash пусть и не кросс-платформенный на все 100%, но уж мульти-платформенный это точно, я имею ввиду что есть еще Calabash for Android. API у них, к сожалению не совпадают полностью и даже есть определенные различия в синтаксисе запросов, но это вполне решаемо с помощью одного уровня абстракции в коде или даже пул реквестов.

    Меня вот немного удивило использование Automator-а, почти все можно сделать с помощью shell/ruby скриптов и ios-sim. Например calabash-ios sim reset сбрасывает настройки симулятора, с помощью DEVICE_TARGET переменной окружения можно ресетить только один какой-то симулятор. Ну естественно эта команда использует Automator скрипт, во многом похожий на ваш.

    К тому же разве все это не должно происходить как часть процесса Continuous Integration? Т.е. в данном примере как часть build pnan/job на TeamCity? Если будете масштабировать, добавлять новые билд боксы, получите децентрализованную систему где на каждой машине крутится свой автоматор. Именно для этого у TeamCity, также как и у Bamboo, Jenkins и других есть поддержка билд агентов. Но тогда все эти задачи (git, calabash.framework, xcodebuild, тесты и отчеты) должны выполняться как часть билда (build job или build plan, или что там у TeamCity). Один и тот же план может выполняться параллельно на нескольких агентах.

    И если будете вдруг поддерживать Андроид, то тесты для андроида можно гонять на Linux машинах, где Automator-а нет.
  • История создания iOS игры о быстрой реакции и стальных нервах
    0
    Вы так много написали про локализацию и при этом нет кнопки переключения языка в настройках… ((

    А насколько большой спрос на подобную фичу? Если судить по себе, то в 99.9% случаев меня устраивает дефолтный язык операционки и нет необходимости его менять отдельно в играх. Возможно в детских приложениях может быть спрос на такую опцию.
  • История создания iOS игры о быстрой реакции и стальных нервах
    0
    210 скриншотов… Не было мысли схитрить и сделать один набор скринов нейтральных по отношению к языку? Добавить какие-нибудь вставки поверх текста внизу, «замылить» или что-то подобное. Некоторые разработчики так и поступают, в качестве скриншотов используется какой-нибудь арт или компонуют сразу 4 экрана в одном скрине, при этом избегая текста.

    Спасибо за наводку на uploader, по сути это продвинутый генератор XML метаданных для iTMSTransporter. Мне кажется образовалась ниша для OSX приложения, которое будет удобной оберкой для iTMSTransporter. Там большое количество задач, которые требуют автоматизации и удобного интерфейса.

    А как так получилось использовать cocos2d-swift и зарелизить приложение? Ведь Swift доступен только в Xcode 6 Beta, а насколько я помню, приложения собранные в beta версиях Xcode Apple никогда не принимала…

    И последний вопрос :) В плане локализации использовали старые добрые .strings или XLIFF добавленный в Xcode 6? Не посоветуете простой софт для работы с XLIFF? Я перепробовал все опенсорсные программы, которые смог найти, все со старта отпугнули сложностью и избыточностью интерфейса, а я искал что-то «для чайников», типа слева оригинал — справа пиши перевод.
  • Кросскомпиляция библиотек под iOS, делаем это правильно
    0
    Полезный пост, спасибо.
    Раз такое дело, у меня есть вопрос. Вам не приходилось собирать boost для iOS?
    Я сделал скрипт на основе других решений: github.com/mgrebenets/boost-xcode5-iosx.
    Тем не менее у людей возникают проблемы, когда им нужно собрать, например, locale библиотеку, которая имеет зависимость от icu или iconv.
  • Zillion приключений (миниобзор)
    +1
    Каждый раз, кога читаю посты про ZoG, меня мучает один и тот же вопрос — «на чем написан этот движок и почему его еще не портировали под мобильные платформы?»

    Если там C/C++ то это можно собрать под iOS, Android и вообще что угодно.
    С таким количеством игр успех обеспечен. Можно зарабатывать на рекламе, или на встроенных покупках.
    Ради интереса поискал ZoG и Zillon в iTunes AppStore и ничего не нашел.

    Еще мне интересно, мультиплеер в ZoG реализован?
    И как обстоят дела с карточными играми, вроде дурака или даже преферанса?
  • Секрет успеха LINE, новый способ монетизации от Facebook, альянс против Apple, тренд Android launcher и другие новости недели для мобильного разработчика
    0
    Ума не приложу, как можно «запатентовать слово»? Другое дело — зарегистрировать торговую марку «Candy».
  • Собираем Акулу под iOS и OSX
    0
    Да, ссылка неправильная. Я подправил статью, вот то самое обсуждение.
    Сообщение об ошибке будет такое
    error: addition of default argument on redeclaration makes this constructor a default constructor
  • Собираем Акулу под iOS и OSX
    0
    Да, конечно, это как раз и есть arm64 архитектура.
  • Практическое руководство по Jekyll
    0
    Да уж, все оказалось достаточно просто.
    Зашел повторно в Settings репозитория и там в разделе GitHub Pages черным по белому написано
    Update your site
    Easily change your content or theme with the page generator.

    To publish a page manually, push an HTML or jekyll site to your gh-pages branch. More info.


    Там можно и текст поменять и тему.
    В общем, плохо смотрел.
  • Практическое руководство по Jekyll
    0
    Вопрос от Jekyll-нуба.
    Совсем недавно хотел добавить GitHub Pages к своему репозиторию. Воспользовался простым путем — автогенерация, выбрал шаблон, набил пару абзацев текста в Markdown (рассчитывал отредактировать позже), нажал OK и через 10 минут сайт готов.

    Вот только когда я захотел отредактировать текст, начались непонятки. Когда я клонировал gh-pages ветку, там был уже сгенерированный index.html, и нигде нет markdown файла. Я так и не понял, что же делать если я хочу поправить markdown текст, запушить изменения в gh-pages и подождать пока Jekyll сгенерирует обновленную страницу. Или я в упор не вижу какой-то очевидный способ, или фиг знает что еще. В доках github-а ничего полезного не нашел, нагуглить тоже не удалось.

    В результате использовал комбайн jekyll-bootstrap, хотя меня вполне устраивала дефолтная тема, если бы была возможность редактировать текст.
  • Автоматизация тестирования Android приложений с помощью UIAutomator
    +1
    Работал и работаю с calabash.
    Из плюсов — Ruby и кросс-платформенность. Cucumber и BDD тоже можно отнести к плюсам. Тесная интеграция с Xamarin, в будущем calabash станет плагином к Frank. Ну и конечно же активное сообщество, частые коммиты и релизы.

    Минусы свои тоже есть, например некоторые вещи сломались с выходом iOS 7, но со временем фиксят или находят обходные пути.

    Не могу напрямую сравнивать с UIAutomation для iOS или Android, не достаточно опыта работы с этими фреймворками. Пробовали сначала MonkeyTalk — calabash гораздо лучше.
  • Автоматическое тестирование iOS приложений
    0
    Но насколько я знаю, без JB вы не сможете установить приложение.

    Почему же, можно. Существует несколько утилит способных сделать это. Вот например одна из них: github.com/tborys/fruitstrap.git
  • Continuous Integration в XCode5
    +1
    Мы используем github.com/calabash/calabash-ios, который скоро станет частью уже упомянутого Frank-a.
    Один из плюсов в сравнении с KIF — кросс-платформеность. Есть поддержка Android github.com/calabash/calabash-android.
    К тому же не так давно Xamarin купил Less Painful вместе с основными разработчиками Calabash. Так что это плюс для тех, кто использует Xamarin.

    Тесты можно писать используя Cucumber, под капотом — Ruby, т.е. огромный выбор gem-ов для любых задач.
  • Рано или поздно нам придется это сделать
    +4
    Начало за здравие… а потом, внезапно утверждается что рабство и интеллектуальная собственность это одно и то же. Вот прям так, с бухты барахты, тождественно равно и все тут. Такой себе риторический прием, интеллектуальная собственность = рабство, а рабство это плохо, очень плохо.

    Но давайте посмотрим правде в глаза — большинству этих людей не нужны многомиллионные прибыли.

    Не согласен. Чем то можно подтвердить это факт? Опросы, статистика, вера в человечество?
    Конечно, они хотят зарабатывать деньги.

    Так в чего же они хотят в конце концов?

    И с играми не совсем ясно. Ведь эта модель уже практически существует. Многие фримиум игры дают поиграть бесплатно, а различные фичи — за деньги, в том числе, например, мультиплеер. Тем не менее in-app покупки ломают налево и направо и оправдывают это пиратство именно такими аргументами, как у вас в статье или схожими.

    Нельзя так просто валить все в одну кучу, жадных издателей/правообладателей и тех, кто пытается продать свое творчество без посредников. Ведь на сегодняшний день «пираты» воруют у всех без разбора и у «хороших» и у «плохих».

    Имхо, очень сложный вопрос. Я не вижу «светлого» будущего, где все доступно за «просто так» и при этом авторы как-то умудряются зарабатывать. Это какая-то утопия, глобальный коммунизм, где каждому по способностям или по количеству сожженных калорий, или как-то еще. Утопия, в общем.
    Убирать посредников — нужно, чем больше площадок для продажи контента напрямую по приемлемым ценам, тем лучше. Только закоренелых халявщиков это не остановит.
  • Чего не хватает инди разработчику?
    0
    Впервые увидел его в том самом фильме, ни до ни после ничего не слышал ни про него самого, ни про игру Fez. Хотя нет, в одном из Humble бандлов ее увидел и подумал «неужели закончил все-таки?». Т.е. я судить могу только по этому фильму.

    Он конечно же, эгоист, инфантильный и что там еще про него говорят. И творческая личность, без кавычек. В фильме показывали как он вырисовывает буквально каждый пиксель в игре, буквально… Он сам рассказывает как ему вдруг показалось что «что-то не то» и он начал улучшать и перерисовывать всю графику в игре почти с нуля. Его больше всего интересует сам процесс, а точнее, его роль в этом процессе, при этом он болезненно реагирует на любую мелочь. Он не способен поставить перед собой задачу «довести до релиза», и выполнить ее, куча новых идей и фич постоянно продлевают разработку и появления хоть какого-то законченного продукта. В том же фильме показывают как на PAX пользователи пробуют его игру и она крешится, часто, очень часто. И он сам объясняет, «мы запушили очень много изменений вчера ночью...». На этом моменте я прифигел. Он пол фильма плачется насколько важен PAX, какой это big deal для него, как он сильно нервничает, как он готовился к этому моменту все последние годы и т.д. и т.п. Тем не менее, за все эти годы он так и не удосужился приготовить один стабильный билд. Благодаря своему перфекционизму и чему там еще он пушит кучу изменений за ночь до важного события… При этом он бегает с глазами по 5 копеек, на грани срыва, который сам себе же и организовал. Может он из тех людей, которые ищут где бы и на кого бы обидеться, да посильнее… Drama queen.

    К такому художнику и творцу нужен просто уникальный менеджер, который сможет довести дело до конца, с учетом всех бзиков разработчика, а последний дрожит чуть ли не над каждой строчкой кода и каждым пикселом, как таким управлять?

    Короче, хорошо, что он все-таки зарелизил Fez, а то точно самоубился бы…
    Если он возьмется за следующий проект, можно смело ждать его лет 7 или 10.
  • Бирюльки и Гуглосервис
    0
    Самый простой способ
    # Podspec
    pod 'AdMob'
    pod 'AdMobMediationAdapterIAd'
    


    Кстати, вопрос, в посте ничего не сказано про iAd Mediation Adapter а ведь без этой библиотеки iAd показываться не будет. Более того, в отладочной консоли будет выскакивать сообщение что не удалось подгрузить адаптер для iAd.

    Т.е. игрушку вы пропиарили, причем не в «Я пиарюсь», а в блоге разработки, но при этом собственно переход с AdWhirl на чистый AdMob описан не полностью :)
  • Мобильное приложение HTML5: ошибка или успех. Попытка №0
    +2
    Возможно, только с множеством оговорок.
    Уже сейчас мобильных платформ много, а действительно популярных среди них — 2 (iOS и Android), хотя я лично считаю что у WP большой потенциал и должна образоваться такая себе «большая тройка» (ну или как там дела у BlackBerry?). Во чем-то напоминает ситуацию на рынке десктопных ОС. Несмотря на то, что новые платформы действительно появляются как грибы, многие из них так же быстро и исчезают (Bada, MeeGo, и т.д.) На данный момент я не вижу другие 2-3 платформы, которые способны сильно потеснить лидеров на рынке и увеличить число популярных осей до 6 и больше. По-моему, в обозримом будущем момент «сложно писать нативные приложения под каждую платформу» пока еще не наступит, недостаточно много этих платформ. Взять хотя бы промежуток с момента появления iOS — 7 лет (уже много), за это время из крупных игроков на рынке мы получили Android, WP, ну как бы и все, наверное.

    Даже в сфере бизнес приложений. Да, действительно, все больше компаний вводят политику BYOD и приходится разрабатывать свои in-house приложения для всех платформ, которые приносят сотрудники. Но сотрудники, опять же, покупают в основном телефоны, которые самые популярные на рынке, т.е. имеем дело все с теми же iOS и Android.

    Ну и даже если число платформ внезапно вырастет, и бизнес захочет поддерживать их все, это не означает что существующие проблемы веб подхода исчезнут сами по себе.

    Так что да, все будет развиваться, но я бы не стал так быстро хоронить «эпоху» нативной разработки. Если бы я попытался дать прогноз на следующие 7 лет, я бы с увереностью сказал что нативная разработка будет также востребована, как и сейчас.
  • Мобильное приложение HTML5: ошибка или успех. Попытка №0
    +2
    Был еще топик на эту тему, я сам там поучаствовал в холиваре.
    Почитал другие статьи, оценил зеленость коментариев, чтобы посмотреть как в общем и целом настроена аудитория хабра по этому вопросу.
    Этот комент точнее всего выражает мою позицию, особенно первое предложение.

    А если об этой конкретно статье, то как-то пытаться выяснить «ошибка или успех», мне кажется, еще рано. Вот когда будет что пощупать на реальном устройстве, тогда можно будет сказать что-то более конкретное.

    Я не могу не согласиться, что у подобных решений найдется своя ниша на рынке, в холивары я встрявал когда слышал ультимативные утверждения о том, что веб подход в его нынешнем состоянии во всех отношениях на голову выше нативного и все тут.
  • Самостоятельная сборка cURL для iOS и Android
    0
    Осталось только грамотно оформить podspec и добавить эту либу в CocoaPods.org, после этого можете считать свою миссию завершенной :)
  • Архитектура мобильных ОС. Тенденции и впечатления пользователей
    0
    Ясно, действительно перевод не искажает смысла. Что сказано в источнике — уже другой вопрос.
    Как я понял PhoneGap взял на себя все усилия по созданию «недостающих» API, в том числе для iOS. iOS в чистом виде поддерживает CSS, HTML5 и JavaScript — основные элементы, необходимые для веб разработки, но нигде и никак iOS не заявляет официальной поддержки именно PhoneGap, хотя и не запрещает публикацию PhoneGap приложений в апсторе. А статья утверждает «all have supported PhoneGap», вместо, например, «all support PhoneGap». Всего одно слово, а разница значительная.

    Ну да ладно, просто думал я где-то упустил важные изменения в жизни iOS.

  • Архитектура мобильных ОС. Тенденции и впечатления пользователей
    0
    Для преодоления несовместимости создан фреймворк PhoneGap, который поддерживается всеми основными мобильными ОС.

    А разве Apple iOS как-то конкретно поддерживает PhoneGap?
    Мне всегда казалось что PhoneGap возник в ответ на отсутствие должной «родной» поддержки веба и HTML5 со стороны iOS и дургих платформ. Я сейчас говорю о том, что в статье названо «среда исполнения», ясное дело что в iOS есть WebKit со всей необходимой поддержкой для веба.

    Или тут должно быть что-то вроде «который поддерживает все основные мобильные ОС.»?
  • 2037. Смерть копирайту — 2
    +3
    Да, слова «Найдете, где еще вам дадут столько же – расскажите мне!» немного убивают интригу. Если их убрать — то второй вариант (12 месяцев отключки) также возможен, как и первый (виртуальный сон).

    Если по тексту, то Алексей в квартиру к себе не ходил, значит никаую пыль не видел. Он сразу побрел за город, шел 3 часа и при этом ни разу не взглянул на смартфон. В отключке он был ровно год, т.е. очнулся в то же время года, скорее всего в то в такое же время, т.е. мог не особо заметить разницу в погоде или времени суток.

    Но мистер Руби фразой про «дадут столько же» загубил такой расклад :)
    И «приход первого платежа» тоже намекает.
  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    0
    Кто-нибудь открыл это дело на мобильном устройстве?
    Даже без каких-либо тролкостей, этот конкретный пример невозможно погонять на iPad Mini, хотя он то как раз должен демонстрировать возможности JS на мобильном устройстве…
  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    0
    А вы не нервничайте. Попробуйте снова сами эту процедуру наложения на себя рук, раз так хорошо знакомы с ней

    А вы предсказуемы :) Не я первый начал мешать другую сторону с говном (зачеркнуто) навозом — вот уж действительно «сильный» агрумент и неоспоримый факт, не более того ) Можно делать это тонко, можно толсто, а можно просто скатиться до оскорблений. Последний вариант — самый простой, но не самый лучший. А нервничать из-за срачей в вебе — извольте, себе дороже.

    Мой основной довод, аргумент и факт — объективная реальность на данный момент времени, в разрезе популярных на данный момент мобильных осей, именно в контексте статьи, без прогнозов на будущее браузерных ОС и т.д. И эта реальность — спрос на рынке на разработчиков Android и iOS, который продолжает расти на протяжении последних 7 лет. А вот вы слышали про открытую позицию разработчика Hy5? Вы вообще слышали про Hy5 (Hybrid HTML5, если что)? Почему monster.com (первое что пришло в голову) на запрос «ios developer» выдает 233 совпадения, а «phonegap developer» только 2?

    Эта же реальность — количественный перевес нативных приложений в апсторах, быстрые темпы развития как iOS так и Android (в плане средств разработки (ЯП, компиляторы, IDE, я не хочу здесь говорить о внешнем виде и о том что видно пользователю на поверхности — это другое) и т.д. Эти аргументы можно «пощупать» и проверить прямо сейчас, они везде, они, наверняка, лежат у вас на столе в виде смартфона (если это не Firefox OS, конечно же).

    Ваши же аргументы — «не наигрались еще», «навоз», «удерживают пользователей», «автор — хер с горы, который ничего из себя не представляет», «автор, как и Цукреберг, ниасилил» и самый частый — «всему свое время». И таких «агрументов и фактов» — большая часть, поэтому и возникает вопрос предвзятости, поэтому почти каждый ваш комент и вызывает флейм.

  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    0
    Надеюсь, я ответил на Ваш вопрос, почему веб-разработчики не бегут и спотыкаются, сломя голову переходить на натив?

    А где я такой вопрос задал? Цитату что ли? Мой вопрос был не совсем такой. Я спрашивал где эти сотни и тысячи чистых веб, а еще лучше гибридных HTML5+JS приложений, которые работают на реальных устройствах (популярных сейчас на рынке) и ни в чем не уступают нативным, а даже превосходят их? Где? Я вовсе не призывал всю армию веб девелоперов сломя голову ломиться в натив, нет уж, сами этот хлеб съедим, спасибо.
    До тех пор пока iOS и Android не станут браузерными ОС (aka «всему свое время»), каждый второй PhoneGap и RhoMobile будет нуждаться в Native Extensions чтобы просто-напросто прочитать файлы из файловой системы (привет, offline storage).

    И в статье речь идет об iOS, Android и других актуальных операционках на сегодняшний день, никто не говорит о браузерных ОС, какой там вообще «натив vs веб», если натив и есть веб? Вообще нечего обсуждать.

    Просто в ваших коментах сквозит исключительная предвзятость, безоговочная уверенность в своей правоте, в том что веб приложения на голову выше по-сравнению с нативными iOS и Android приложениями, просто «все вокруг заблуждаются», как же иначе-то… Вы хоть интересовались какой стек технологий спрятан под капотом iOS или Android? Поинтересуйтесь, найдете для себя объяснение, почему на специалистов в этой области есть спрос, несмотря на ваше видение мира. Зачем эти соскоки в возню с навозом и прочее? Если так тяжело держать себя в руках, попробуйте держать себя сначала правой рукой, а потом левой, а потом опять правой, ну и т.д. — поможет не срываться в какие-то говнистые сравнения.
  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    0
    Тут у вас немного теории заговора. По-крайней мере iOS (не знаю насчет полной истории Android) вырос из Mac OS. Не было «элементарно простой» причины — «подсадить» пользователей на платформу, чтобы они никуда не убежали. Не было всемирного заговора любой ценой не использовать веб.

    И эти эталонные цитаты.
    тут априори считается, что разработчику достаточно один раз написать приложение, правильно, по стандартам написать, и оно будет работать практически везде

    Мне бы в вашу реальность. Стандарты не меняются что ли? Почему каждый уважающий себя движок имеет какие-то специфичные только для него флаги, разные движки по-своему реализуют новые фичи из стандартов, раньше чем эти фичи стандартом окончательно утверждаются, даже ваш хваленный HTML5 по-прежнему candidate recommendation, и никак не финальная версия. Почему гибридные средства появляются бытсрее, чем грибы после дождя и каждый фреймворк считает своим долгом использовать ЯП отличающийся от всех других и вообще отличаться от остальных? По ходу чтобы наравне с нативными разработчиками появлялись RhoMobile-разработчки или какие-то еще. Как так получается что выбор JS фреймворка становится мини-исследованием, особенно если ему суждено работать на iPad 1?

    Какие могут быть еще доказательства состоявшейся и работоспособной технологии?

    Никто не ставит под сомнение технологию, когда речь идет о вебе. А когда утверждается что эта технология — идеальное решение для мобильных приложений, возникают вопросы. Да простые доказательства, например подавляющее большинство веб приложений (чистых или гибридов) во всех возможных апсторах, желательно для популярных сервисов, желательно с положительными отзывами. Чем не доказательство, что мешает этому случиться? Армия веб разработчиков есть, стандарты хорошие и прекрасные есть, интернет есть. Все механизмы давно испробованы на практике и вообще космические корабли бороздят просторы вселенной… Нет, блин, конечно заговор, а не объективная реальность.
  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    0
    Та лох какой-то.
    А если серьезно, я не могу судить о его «бывалости» в вебе. В наши дни одного только титула Xoogler достаточно, чтобы показать «крутизну». Как можно объективно судить о его достижениях? Разве что на его старничке говорящие достижения и в Гугле он выдавал на гора что-то гениальное.
    Бывший гуглер, основатель стартапов, владелец заводов, газет, пароходов… Ну уж наверное не хрен с горы, что-то из себя представляет.
  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    +2
    Видимо устоявшееся выражение в английском языке — Going Native
    Типа автор был воинствующим противником натива и сторонником веб подхода, а теперь «going native» и занимает противоположную позицию, даже игра слов получается, «native» из оригинального выражения также означает «native apps».
    Как Лоуренс Аравийский.
    Нужно, кстати, посмотреть фильм.
  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    0
    А когда веб победит, интернет будет везде и быстрый.
    Другой вопрос — а когда это будет? Я его уже выше задавал.
    Мы так скатились с рассуждениям вроде, принимаем за данность супер быстрые облачные сервисы, кому тогда нужен натив? Все крутится на серваках, на мобиле исключительно веб морда, для того же objective-c в этом мире просто нет места. Вообще все устройства превращаются в терминал для доступа к облаку, это если утрировать.

    Но, я повторюсь, когда это будет? В некоторых странах, не будем тыкать пальцем (и нет, я не про Россию :) ), до сих пор в разработке проекты типа National Broadband, т.е. проводной интернет развивается и развиваться будет долго. Что уж говорить про мобильный интернет.
  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    +2
    Ну что-то этот переходный период затянулся, несмотря на все пророчества, может дать ему какое-то более гордое название, типа «20-ти летка нативных приложений»? Или уж сразу «век нативной разработки», с запасом :)

    Это время придет, безусловно, когда скорость мобильной связи догонит и перегонит сегодняшнее оптоволокно и все что только можно. Действительно, нафига нативные приложения, если все крутится в облаках и скорость доступа просто молниеносна.

    Но вот у вас хотя бы приблизительная оценка по времени есть когда это случится? Не только в развитых странах, а более менее в большей части мира. «Всему свое время» — слишком смелая оценка :) В это «свое время» и HTML5 может превратиться в HTML15, а может вообще уйдет на покой и ему на смену придет новый стандарт нового Веб 7.0.

    А сейчас и скорее всего в течении следующих долгих лет мы имеен нативные приложения, гибриды, которые с трудом поспевают за обновлениями операционок (но тем не менее для определенных задач имеет смысл их использовать) и чистый веб. И вокруг этого вечный спор — что лучше на данный момент. Спорить что будет лучше в будущем — вообще неблагодарное занятие.

  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    +1
    Так а пользователям и заказчикам вы также скажете «немного подождать»?
    Как уже было сказано, многие ждут с момента выхода первого iPhone, а воз и ныне там…
  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    0
    Вы так яро отстаиваете позицию веб приложений и так сильно пытаетесь принизить преимущества нативных, что остается только удивляться. Да, можно подумать, у нативных приложений одно ничтожное преимущество работы с оборудованием как бы (а почему, кстати, «как бы») напрямую.

    Нет, безусловно, и в Apple и в Google сидят толпы зашоренных идиотов, которые ни в какую не хотят признавать силу и могущество веб приложений и продолжают выкатывать iOS 7, Android 4.2 и прочие.
    В каждой новой версии оси добавляют новые фичи и т.д.

    Каковы аналоги Grand Central Dispatch, XPC, Operation Queues, Core Data и остальных в современных чистых и гибридных HTML5 фреймворках?
    Ну хотя бы приблизительно какой из них позволяет создать такой же отзывчивый UI как нативные средства? Какой из гибридов толково умеет работать с main queue в iOS?

    Я не буду говорить за все инструменты из этой серии, их уже десятка три, если не больше.
    Мне лично приходилось сталкиваться с RhoMobile. В кратце — чур меня, если это считается сравнимым с нативными средствами, то уж извольте… я тоже что-то пропустил.

    Что удивляет еще больше, каждая контора считает своим долгом создать свой собственный гибридный HTML5 фреймворк и потом впихивать его под соусом «напиши один раз — работает везде (и поддерживать потом будем годами за твой счет)». Большинство этих средств не успевает за выпусками основных версий мобильных операционок, не успевает добавлять поддержку новых фич в свои гибридные недра. RhoMobile поди до сих пор генерирует проекты для Xcode версии 3.1 (!), которые «из коробки» даже не собираются.

    Можете как угодно защищать свою позицию, правда вы в основном пытаетесь агрессивно принизить нативные средства. Хотя да, были люди в истории способные искажать реальность :)

    Это как с религией, когда мне докажут что бог реален, я просто начну верить (хотя как можно верить в реальность...). Точно также когда веб одержит безоговорочную победу на мобильных девайсах, я буду в числе первых его адептов.

  • Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям
    0
    А незадолго до этого другой представитель Facebook сказал
    But last September at TechCrunch's Disrupt conference, Mark Zuckerberg announced that «betting completely on HTML5 is one of the, if not the biggest strategic mistake we've made».
  • О комментариях в коде замолвите слово
    +1
    Поможет тем, у кого еще не выработались хорошие/вредные привычки.