Не совсем права, но недалеко от истины. Все-таки больше половины — умеют, но 38% это очень и очень немало.
В любом случае, то что многие не умеют печатать вслепую это не оправдание :)
Мне в свое время помог всем известный тренажер «Соло на клавиатуре». Сначала для русской раскладки, когда пришлось все больше кодить, прошел чуть больше половины упражнений для английской раскладки.
Нет, они этот термин не сами придумали и не они его сделали таким «громким», понятие геймификация было придумано раньше, просто сейчас оно набирает популярность и есть много проектов, где используются принципы геймификации. На coursera, например, есть целый курс Gamification
Насчет первого. Все-таки она называется iOS Developer Enterprise Program, т.е. подразумевает точно такую же разработку как и обычная Developer Program, совсем не правда что Enterprise нужна исключительно для распространения. Тогда пришлось бы покупать отдельно Developer чтобы разработать, а потом Enterprise чтобы распространить в своей компании in-house. Enterprise действительно предназначена для разработки «под себя» и не позволяет публикацию в App Store, но, например вот тут есть информация что можно устнавливать свои in-house приложения на устройства клиентов (Customer) только если эта установка происходит на территории вашей компании или проводится сотрудником вашей компании. Apple отмечает что может проверить соблюдение этого пункта в любой момент, но насколько я понял, многие его не соблюдают и используют такой способ распространения. Единственный минус — на один девайс можно ставить in-house приложения только от одного Enterprise аккаунта (опять же только читал, на практике еще не приходилось проверять). Вот как раз поэтому клиент покупает Enterprise лицензию для разработки, хотя никакой разработки фактически не делает, зато избавляется от ограничений. Люди из отдела маркетинга не очень любят такой подход, им нужно продать решение клиенту как можно более простым способом. Если приходится просить каждого клиента открыть себе Enterprise аккаунт — это не самый простой вариант с точки зрения маркетинга. Можно было бы публиковать в App Store, но этот вариант под вопросом, поскольку это специфическое B2B приложение (с завязкой на серверный компонент) и может не пройти Review. Вариант с Volume Purchase Program тоже не совсем подходит. Во-первых (может это уже и не так) но этот способ доступен только для клиентов в США, во-вторых клиент по-прежнему должен сделать лишние телодвижения и завести себе Volume Purchase Program аккаунт, зато требования к приложению будут менее жесткие и будет учитываться B2B специфика.
Ну а по второму пункту, не для всех приемлем вариант «отправить исходники клиенту», это работает когда клиент является единственным заказчиком и платит в том числе и за исходники. А если компания пишет приложение и будет потом продавать его многим клиентам как готовое решение — высылать каждому исходики никак нельзя. Поэтому обычно клиент дает доступ к своему Developer Enterprise аккаунту, а мне хотелось бы знать можно ли совсем исключить обмен какими-либо паролями или логинами.
Где-то прочитал, что на одно устройство одновременно можно установить enterprise (in-house) приложения только от одного разработчика.
Т.е. две компании А и B разрабатывают iOS приложения у каждой компании своя подписка на Enterprise program, появляется клиент C у которого один единственный iPhone и вот на этот айфон он не сможет поставить одновременно приложения от A и от B.
Кто-нибудь может подтвердить или опровергнуть? Якобы это официальное ограничение.
Именно поэтому клиент C заводит свой собственный enterprise аккаунт и дает к нему доступ разработчикам.
И кстати насчет последнего пункта. Скажем у клиента есть enterprise аккаунт а я для него разрабатываю приложение. Так ли необходимо клиенту давать мне полный доступ к iOS Developer Program (логин и пароль)? Если я соберу Xcode archive и вышлю его заказчику, сможет ли он его переподписать своим сертификатом? Я ведь могу этот архив переподписывать Ad-Hoc и Distribution сертификатами.
Идея действительно классная, реализацию сейчас пощупаю.
Но вообще Storyboards тоже можно рассматривать как хороший инструмент для прототипирования, по крайней мере для приложений, которые используют в основном стандартные элементы.
С помощью Interface Builder-a можно быстро набросать «карту» приложения, обозначить все переходы (segue), оформить внешний вид всех view controller-ов, и даже запустить на симуляторе или девайсе. Получается рабочий прототип, который можно показать заказчику, плюс хорошая «рарзвертка» всего приложения, где можно охватить взглядом все возможные пути навигации и т.д.
И на основе этого же Storyboard-а можно разрабатывать и само приложение.
Зачем же тогда опрос, если вы знаете все ответы? :)
А objective-c разработчиков должно быть немало, кому-то же Apple платит эти миллиарды от продаж в App Store, ну так, обобщенно.
Так это, 6 т.р. в руки, один поход на радиорынок, паяльник, плоскогубцы и вы обладатель новенького айфона :)
Если не ошибаюсь, себестоимость это цена запчастей и в ней не учтены трудозатраты на сборку девайса, на его доставку до потребителя и т.д., нужно все-таки ориентироваться на что-то другое, не себистоимость.
Полный оффтоп, но внезапно задумался. Как завсегдатаи соц. сетей умудряются писать «мне нравиться» в чатах, хотя каждый день десятки раз кликают на кнопку с правильным вариантом?
Кога Марк Андреессен говорит «Приложения будущего», так и хочется попросить его «define будущее».
Вот прямо сейчас приходится работать с RhoMobile. Начнем с того что порог вхождения есть, и он высок. И дело не в ruby, не в HTML5, нет, дело в общем состоянии платформы. Просто чтобы настроить рабочее окружение на Mac OS нужно основательно замучить гугл, расковырять несколько rake-файлов и в последствии натыкаться на различные проблемы. Просто запустить RhoSimulator для нужного приложения мне не удалось, на форумах несколько людей с такой же проблемой и ответа пока нет.
Дальше идет вопрос нативных расширений (native extensions), опять же, rhogen генерит Xcode проект в формате 3.1, в котором не прописан необходимый путь RHO_HOME, требуется время чтобы только обнаружить что не так, и ответа не нагуглишь, и т.д. Один и тот же код с использованием блоков и dispatch queue будет работать в вашем тестовом нативном приложении, но вылетит при запуске в rhomobile приложении. Вызов нативного picker-а вызывает неожиданный зум HTML странички, который сам по себе никуда не денется. В iOS6 изменился подход к авторотации, некоторые мои нативные приложения перестали реагировать на вращения, исправление было в одну строчку, к сожалению, все не так просто в RhoMobile, приложение просто не хочет «крутиться» и все, пока фикс не добавят в саму платформу. И «отзывчивость» — оно слово: кошмар, как-будто тычешь пальцем в какой-то резистивный тачскрин лохматых годов.
Продолжать можно долго, после всех костылей и пробем я вижу ужасно медленное и сырое приложение, над которым год работали 2 человека, при этом тестировалось оно тольком только на Android, поддержка Windows Phone, BlackBerry и iOS разве что «гарантирована» RhoMobile, а на деле там непаханное поле мелких багов и куча подводных камней, плюс целая обойма native extensions, которые необходимо реализовать для данного конкретного приложения. Т.е. если говорить прямо, работает только на Android (и не на всех версиях одинаково стабильно). За вдвое (если не втрое) меньшее время один опытный iOS и один Android разработчик сделали бы отлично бегающий клиент под каждую платформу, с общими библиотеками на том же C++. Еще остается время на другие платформы.
Вывод, исходя из моего опыта, будущее еще не наступило и еще не скоро наступит. Ни одна «универсальная» платформа не успевает идти в ногу с основными мобильными операционками (Android, iOS, Windows Phone, BB). Если вам кровь из носу необходимо писать под 3-4 операционки сразу и вы сильно ограничены в ресурсах, тогда да, подход может себя оправдать.
P.S. Я понимаю что речь в статье идет немного о другом, когда вообще все приложения доступны «просто через браузер». Но до этого будущего, имхо, еще гораздо дальше, даже не берусь делать прогнозов.
Та же мысль посетила. Вот сейчас эти людишки подберутся совсем близко, докажут зернистость/дискретность всего на свете, вот прям буквально завтра, человечество стоит на пороге великого открытия! И тут эта вневселенская сущность пойдет на вневселенскую Горбушку и купит новый проц для своего компа.
Из реальных опастностей, наверное, только наводнения. В прошлом году затопило Брисбейн в штате Виктория. В Сиднее в этом плане безопаснее вроде.
Еще лесные пожары (bush fire), хотя это опаснее для тех кто на отшибе живет.
Все всегда вспоминают про пауков, но они просто большие, могут залезть в квартиру и испугать. Мы на первых порах летом решетки на окнах не плотно закрывали, просыпаешься утром, а на потолке сидит большой черный huntsman. Вроде как безобидный вид, но ловить и выгонять из квартиры придется.
Да нет, заметил. Действительно стоило дополнительно отметить этот факт. Он еще более показательный, они пригласили блогера, который в идеале вообще должен обладать независимым мнением (насколько это вообще возможно), а относятся к нему как к своему постоянному сотруднику, требуют стопроцентной лояльности.
И еще показательный момент, когда конфликт возник, менеджеры оказались к нему абсолютно не готовы. Для них это как удар рельсой по башке — кто-то не хочет делать что говорят. Первая реакция у них обычно шок, они просто не могут поверить в реальность происходящего :) Чаще всего они просто повторяют свою просьбу/указание повторно, в надежде что со второго раза реальность перестанет искажаться :)
Ну и да, ждем постов от евангелистов Самсунга, где эти блогеры окажутся какими-нибудь авантюристами с темным прошлым.
Прекрасно. Конечно, история описана с одной стороны и все наверняка очень преувеличено. Но доля правды в этом есть. Мне приходилось работать в Корее, в том самом Самсунге. И я примерно понимаю что произошло. В кратце, у корейцев очень строгая субординация, если начальник сказал сделать, то ты должен сделать, без вопросов и каких-либо комментариев. Сами корейцы так и работают и для них это норма. Но тут появляются эти иностранцы, особенно всякие русские, украинцы и белорусы. У этих всегда есть свое собственное мнение, и, что самое страшное, многие из них не задумываясь выскажут начальнику что они думают об его очередной идее. Нет не скажут «ты дебил», а начнут анализировать что в этом подходе не так, почему в сроки не успеем, и т.д. А для корейского начальника это нонсенс. Ну и так далее.
Индусы у корейцев считаются дешевой рабочей силой, туда аутсорсят все что можно и особо с индусами не церемонятся. Индусы, в отличии от тех же славян, выполняют указания без пререканий. А тут случилось невиданное. Какой-то индус стал качать права! Реакция корейцев была жесткой и негативной, с заглаживанием конфликтов у них не очень, особенно когда «мы ему все оплатили и сказали что делать, а он не хочет!».
Многие скажут «в чужой монастырь со своим уставом не лезут», но нельзя так однобоко на все это дело смотреть. Самсунг хочет стать глобальной (global) компанией, они планируют увеличить количество иностранцев у себя в штаб-квартире вдвое. Им придется быть гибче, не получится нанять всю эту разношерстную публику и ожидать что они будут работать как обычные корейцы. Самсунгу нужно тоже изменяться и быть готовым к разным ситуациям, например как с этим блоггером.
Сначала подумал речь идет о каком-то универсальном решении, поиск прояснил что речь идет только об устройствах Kyocera. Насколько я понял по умолчанию ее в обычных моделях нет, продается дополнительно. В приницпе подобное есть у каждой компании, иногда создают на жестком диске отдельные разделы, которые зашифрованы и т.д.
А еще — МФУ с жестким диском это находка для шпиона. Когда-то читал об этом целую статью. В штатах чуваки взяли списанные МФУ, повыдергивали винты и посмотрели что можно с этих дисков прочитать. Оказалось много чего.
Сейчас с этим лучше, почти все гос. учереждения требуют чтобы были функции мгновенной и полной перезаписи (immediate overwriting, complete overwriting). Мгновенная пишет поверх данных только что удаленной работы. Причем в каждой стране свои госты на алгоритмы перезаписи.
Ну что, иницируем очередной МММ-срач. Вот прямо на глазах прошла жизнь МММ в МММиниатюре. Только здесь основатель спокойно слился вместе со всем баблом. Осталось его найти и посадить, потом он отсидит, выйдет на свободу и запустит еще 3 системы подряд.
В любом случае, то что многие не умеют печатать вслепую это не оправдание :)
Мне в свое время помог всем известный тренажер «Соло на клавиатуре». Сначала для русской раскладки, когда пришлось все больше кодить, прошел чуть больше половины упражнений для английской раскладки.
Насчет первого. Все-таки она называется iOS Developer Enterprise Program, т.е. подразумевает точно такую же разработку как и обычная Developer Program, совсем не правда что Enterprise нужна исключительно для распространения. Тогда пришлось бы покупать отдельно Developer чтобы разработать, а потом Enterprise чтобы распространить в своей компании in-house. Enterprise действительно предназначена для разработки «под себя» и не позволяет публикацию в App Store, но, например вот тут есть информация что можно устнавливать свои in-house приложения на устройства клиентов (Customer) только если эта установка происходит на территории вашей компании или проводится сотрудником вашей компании. Apple отмечает что может проверить соблюдение этого пункта в любой момент, но насколько я понял, многие его не соблюдают и используют такой способ распространения. Единственный минус — на один девайс можно ставить in-house приложения только от одного Enterprise аккаунта (опять же только читал, на практике еще не приходилось проверять). Вот как раз поэтому клиент покупает Enterprise лицензию для разработки, хотя никакой разработки фактически не делает, зато избавляется от ограничений. Люди из отдела маркетинга не очень любят такой подход, им нужно продать решение клиенту как можно более простым способом. Если приходится просить каждого клиента открыть себе Enterprise аккаунт — это не самый простой вариант с точки зрения маркетинга. Можно было бы публиковать в App Store, но этот вариант под вопросом, поскольку это специфическое B2B приложение (с завязкой на серверный компонент) и может не пройти Review. Вариант с Volume Purchase Program тоже не совсем подходит. Во-первых (может это уже и не так) но этот способ доступен только для клиентов в США, во-вторых клиент по-прежнему должен сделать лишние телодвижения и завести себе Volume Purchase Program аккаунт, зато требования к приложению будут менее жесткие и будет учитываться B2B специфика.
Ну а по второму пункту, не для всех приемлем вариант «отправить исходники клиенту», это работает когда клиент является единственным заказчиком и платит в том числе и за исходники. А если компания пишет приложение и будет потом продавать его многим клиентам как готовое решение — высылать каждому исходики никак нельзя. Поэтому обычно клиент дает доступ к своему Developer Enterprise аккаунту, а мне хотелось бы знать можно ли совсем исключить обмен какими-либо паролями или логинами.
Т.е. две компании А и B разрабатывают iOS приложения у каждой компании своя подписка на Enterprise program, появляется клиент C у которого один единственный iPhone и вот на этот айфон он не сможет поставить одновременно приложения от A и от B.
Кто-нибудь может подтвердить или опровергнуть? Якобы это официальное ограничение.
Именно поэтому клиент C заводит свой собственный enterprise аккаунт и дает к нему доступ разработчикам.
И кстати насчет последнего пункта. Скажем у клиента есть enterprise аккаунт а я для него разрабатываю приложение. Так ли необходимо клиенту давать мне полный доступ к iOS Developer Program (логин и пароль)? Если я соберу Xcode archive и вышлю его заказчику, сможет ли он его переподписать своим сертификатом? Я ведь могу этот архив переподписывать Ad-Hoc и Distribution сертификатами.
Но вообще Storyboards тоже можно рассматривать как хороший инструмент для прототипирования, по крайней мере для приложений, которые используют в основном стандартные элементы.
С помощью Interface Builder-a можно быстро набросать «карту» приложения, обозначить все переходы (segue), оформить внешний вид всех view controller-ов, и даже запустить на симуляторе или девайсе. Получается рабочий прототип, который можно показать заказчику, плюс хорошая «рарзвертка» всего приложения, где можно охватить взглядом все возможные пути навигации и т.д.
И на основе этого же Storyboard-а можно разрабатывать и само приложение.
А objective-c разработчиков должно быть немало, кому-то же Apple платит эти миллиарды от продаж в App Store, ну так, обобщенно.
или туплю, инория ведь :)
Если не ошибаюсь, себестоимость это цена запчастей и в ней не учтены трудозатраты на сборку девайса, на его доставку до потребителя и т.д., нужно все-таки ориентироваться на что-то другое, не себистоимость.
Вот прямо сейчас приходится работать с RhoMobile. Начнем с того что порог вхождения есть, и он высок. И дело не в ruby, не в HTML5, нет, дело в общем состоянии платформы. Просто чтобы настроить рабочее окружение на Mac OS нужно основательно замучить гугл, расковырять несколько rake-файлов и в последствии натыкаться на различные проблемы. Просто запустить RhoSimulator для нужного приложения мне не удалось, на форумах несколько людей с такой же проблемой и ответа пока нет.
Дальше идет вопрос нативных расширений (native extensions), опять же, rhogen генерит Xcode проект в формате 3.1, в котором не прописан необходимый путь RHO_HOME, требуется время чтобы только обнаружить что не так, и ответа не нагуглишь, и т.д. Один и тот же код с использованием блоков и dispatch queue будет работать в вашем тестовом нативном приложении, но вылетит при запуске в rhomobile приложении. Вызов нативного picker-а вызывает неожиданный зум HTML странички, который сам по себе никуда не денется. В iOS6 изменился подход к авторотации, некоторые мои нативные приложения перестали реагировать на вращения, исправление было в одну строчку, к сожалению, все не так просто в RhoMobile, приложение просто не хочет «крутиться» и все, пока фикс не добавят в саму платформу. И «отзывчивость» — оно слово: кошмар, как-будто тычешь пальцем в какой-то резистивный тачскрин лохматых годов.
Продолжать можно долго, после всех костылей и пробем я вижу ужасно медленное и сырое приложение, над которым год работали 2 человека, при этом тестировалось оно тольком только на Android, поддержка Windows Phone, BlackBerry и iOS разве что «гарантирована» RhoMobile, а на деле там непаханное поле мелких багов и куча подводных камней, плюс целая обойма native extensions, которые необходимо реализовать для данного конкретного приложения. Т.е. если говорить прямо, работает только на Android (и не на всех версиях одинаково стабильно). За вдвое (если не втрое) меньшее время один опытный iOS и один Android разработчик сделали бы отлично бегающий клиент под каждую платформу, с общими библиотеками на том же C++. Еще остается время на другие платформы.
Вывод, исходя из моего опыта, будущее еще не наступило и еще не скоро наступит. Ни одна «универсальная» платформа не успевает идти в ногу с основными мобильными операционками (Android, iOS, Windows Phone, BB). Если вам кровь из носу необходимо писать под 3-4 операционки сразу и вы сильно ограничены в ресурсах, тогда да, подход может себя оправдать.
P.S. Я понимаю что речь в статье идет немного о другом, когда вообще все приложения доступны «просто через браузер». Но до этого будущего, имхо, еще гораздо дальше, даже не берусь делать прогнозов.
Еще лесные пожары (bush fire), хотя это опаснее для тех кто на отшибе живет.
Все всегда вспоминают про пауков, но они просто большие, могут залезть в квартиру и испугать. Мы на первых порах летом решетки на окнах не плотно закрывали, просыпаешься утром, а на потолке сидит большой черный huntsman. Вроде как безобидный вид, но ловить и выгонять из квартиры придется.
И еще показательный момент, когда конфликт возник, менеджеры оказались к нему абсолютно не готовы. Для них это как удар рельсой по башке — кто-то не хочет делать что говорят. Первая реакция у них обычно шок, они просто не могут поверить в реальность происходящего :) Чаще всего они просто повторяют свою просьбу/указание повторно, в надежде что со второго раза реальность перестанет искажаться :)
Ну и да, ждем постов от евангелистов Самсунга, где эти блогеры окажутся какими-нибудь авантюристами с темным прошлым.
Индусы у корейцев считаются дешевой рабочей силой, туда аутсорсят все что можно и особо с индусами не церемонятся. Индусы, в отличии от тех же славян, выполняют указания без пререканий. А тут случилось невиданное. Какой-то индус стал качать права! Реакция корейцев была жесткой и негативной, с заглаживанием конфликтов у них не очень, особенно когда «мы ему все оплатили и сказали что делать, а он не хочет!».
Многие скажут «в чужой монастырь со своим уставом не лезут», но нельзя так однобоко на все это дело смотреть. Самсунг хочет стать глобальной (global) компанией, они планируют увеличить количество иностранцев у себя в штаб-квартире вдвое. Им придется быть гибче, не получится нанять всю эту разношерстную публику и ожидать что они будут работать как обычные корейцы. Самсунгу нужно тоже изменяться и быть готовым к разным ситуациям, например как с этим блоггером.
Сейчас с этим лучше, почти все гос. учереждения требуют чтобы были функции мгновенной и полной перезаписи (immediate overwriting, complete overwriting). Мгновенная пишет поверх данных только что удаленной работы. Причем в каждой стране свои госты на алгоритмы перезаписи.