Эта магия началась не вчера и не в айфонах, и завтра точно не закончится.
Я думаю, что это слишком заманчивая цель, что бы от нее просто так отказались.
Так что подобные функции, в том или ином виде, будут во всех аппаратах.
В том же «чистом» андроиде, возможно и нет ничего подобного.
Но кто гарантирует, что в прошивках от производителя все чисто?
Походу вы вообще не поняли о чем идет речь.
Джонатан прекрасно понимает что делают сервисы. Именно поэтому он поднял тему.
Он не понимает, совсем другое.
Почему Apple скрывает подробную информацию о этих сервисах? Зачем режим отладки включен вообще на всех устройствах? Почему его работой нельзя управлять? Зачем эти сервисы собирают больше информации чем необходимо для отладки? И т.д.
Эти топорные, тупые методы работают далеко не во всех случаях.
Гораздо эффективнее получать информацию, когда источник даже не в курсе, что он сливает инфу.
А вы уверены, что в документации описано все что делают эти сервисы?
И да, конечно безопасность держится на обладании ключом. Но тут вопрос не в принципиальном подходе к безопасности (ключ, пароль, еще что-то), а в ее реализации. Вы можете достать/заменить ключ в iPhone? А вы управляете на каких спаренных устройствах будут хранится копии ключей? А легко (и можно ли вообще простыми средствами) удалить ключи со спаренных устройств? И т.д.
Ключами же к sshd я полностью рулю сам. Знаю где они лежат. Управляю местом хранения. Могу пересоздать в любой момент. И т.д.
Улавливаете разницу, во вроде бы одинаковом подходе к безопасности по ключам?
Джонатан говорит, что в документации описано далеко не все.
К тому же, ключ находится не только на самом телефоне, поэтому шансы его получить сильно увеличиваются.
>С помощью депонированных ключей (escrow file) возможна расшифровка защищённых данных и без знания пароля на включение устройства. Файлы депонированных ключей создаются на любом компьютере, к которому устройство подключалось с целью синхронизации.
Скорее всего второй вариант.
Ибо даже с учетом джейлбрейка, наличие в свободной продаже, за какие-то 80к рублей, такого софта, подрывает все доверие к производителю. Что уж говорить о не афишируемых возможностях?
Да, но естественно не к любым проектам.
Для большинства мобильных, флеш и им подобных проектов так и есть. Игры в сторах на 90% братья близнецы.
А это и есть, то самое, массовое производство.
Если бы, Goole, Amazon, Yandex и Mail.ru занимали хотя бы 70% рынка разработки, я бы с вами согласился.
А так даже внутри этих компаний, этим самой наукоемкой разработкой занимаются хорошо если половина разработчиков. А в реале я думаю процентов 30 максимум.
В целом все верно, хоть статья и капитанская.
Если подходить к разработке как к разработке чего-то уникального, то да. Методы макдональдс не подходят.
Но, к сожалению, мы живем не в идеальном мире. Подавляющее большинство программ, которые пишут сейчас программисты это типичные сайты. И вот там-то как раз творчества у программистов минимум. Все творчество в этих проектах у дизайнеров.
Конвеер тут как раз подходит. Ибо организация довольно быстро вырабатывает свой стек технологий и пилит на них проект за проектом. Это уже не художники, а маляры. А работу маляров уже можно нормировать, что собственно и происходит. И таких программистов большинство. Это не плохо и не хорошо, это просто жизнь. Программы стремительно ворвались во все сферы деятельности и из творческой работы, программирование превращается в обычную работу. Процент творчество/процесс доходит до обычных соотношений
других профессий, по мере развития технологий.
По поводу Play Framework или связки Spray + Akka полностью согласен.
Но в использовании привычного многим SpringMVC не вижу каких-то проблем. Это еще один приятный момент в Scala. Можно использовать проверенные библиотеки.
Начальство часто тяжело уломать использовать какой-то Play. Да и на Spring-то часто несогласны, ибо «За покупку IBM еще никого не увольняли» )) А это нормальный вариант, чтобы уж совсем не погрязнуть в Java EE Bean'ах и в тоже время изучить новые технологии.
У меня был проект, где JavaEE писали полностью на Scala, со всеми EE-шными аннотациями и прочими прелестями. Этакий ScalaEE. Только потому, что был продакшен стек, в котором просто нет места всяким (со слов техлида, про Play и Lift) «Хипстерским технологиям». Да и Scala-то попробовать еле уломали. И только после демонстрационного проекта, который ребята пилили на выходных, в надежде глотнуть свежего воздуха со Scala. Ибо JavaEE уже порядочно всех за долбала.
И вполне себе отлично пишется. Хоть и выглядит странно)
Почти в каждом посте про Scala, есть такой камент.
И меня всегда удивлял такой подход. Что это вообще значит «на Java на Scala»? Мы же не в секте какой-то.
Напомню, для тех кто на бронетехнике, Scala это мультипарадигменный язык. Это значит, что можно писать как простой ООП код, так и зубодробительную функциональщину.
В примерах приведен простой ООП подход. Ну зачем, скажите мне, везде пихать навороченную функциональщину, на которую способна Scala? Ну в Java вы же не пишете все на дженериках или интерфейсах, только потому что они там есть? А если вдруг увидели простой класс без дженериков, не говорите многозначительно «На Java на C»?..
Сами создатели языка разделяют разработчиков на 2 категории. Создатели библиотек/фреймворков и прикладные программисты.
Вот для фреймворков подходы разработки свои, там и проявляется вся мощь языка. А на прикладном уровне это не так ярко выражается. К тому же, на прикладном уровне работают разного уровня разработчики. Код, приведенный в примерах может понять и начинающий разработчик на Scala. Мало того понять, он и писать сможет. А в реальных проектах это не маловажный факт.
Ну не получится сесть и моментом начать писать все в Scala стиле. А такой подход он вполне хорошо подходит для переезда или добавления Scala в существующий проект.
Я думаю, что это слишком заманчивая цель, что бы от нее просто так отказались.
Так что подобные функции, в том или ином виде, будут во всех аппаратах.
В том же «чистом» андроиде, возможно и нет ничего подобного.
Но кто гарантирует, что в прошивках от производителя все чисто?
Джонатан прекрасно понимает что делают сервисы. Именно поэтому он поднял тему.
Он не понимает, совсем другое.
Почему Apple скрывает подробную информацию о этих сервисах? Зачем режим отладки включен вообще на всех устройствах? Почему его работой нельзя управлять? Зачем эти сервисы собирают больше информации чем необходимо для отладки? И т.д.
Гораздо эффективнее получать информацию, когда источник даже не в курсе, что он сливает инфу.
И да, конечно безопасность держится на обладании ключом. Но тут вопрос не в принципиальном подходе к безопасности (ключ, пароль, еще что-то), а в ее реализации. Вы можете достать/заменить ключ в iPhone? А вы управляете на каких спаренных устройствах будут хранится копии ключей? А легко (и можно ли вообще простыми средствами) удалить ключи со спаренных устройств? И т.д.
Ключами же к sshd я полностью рулю сам. Знаю где они лежат. Управляю местом хранения. Могу пересоздать в любой момент. И т.д.
Улавливаете разницу, во вроде бы одинаковом подходе к безопасности по ключам?
К тому же, ключ находится не только на самом телефоне, поэтому шансы его получить сильно увеличиваются.
>С помощью депонированных ключей (escrow file) возможна расшифровка защищённых данных и без знания пароля на включение устройства. Файлы депонированных ключей создаются на любом компьютере, к которому устройство подключалось с целью синхронизации.
Ибо даже с учетом джейлбрейка, наличие в свободной продаже, за какие-то 80к рублей, такого софта, подрывает все доверие к производителю. Что уж говорить о не афишируемых возможностях?
Для большинства мобильных, флеш и им подобных проектов так и есть. Игры в сторах на 90% братья близнецы.
А это и есть, то самое, массовое производство.
А так даже внутри этих компаний, этим самой наукоемкой разработкой занимаются хорошо если половина разработчиков. А в реале я думаю процентов 30 максимум.
Если подходить к разработке как к разработке чего-то уникального, то да. Методы макдональдс не подходят.
Но, к сожалению, мы живем не в идеальном мире. Подавляющее большинство программ, которые пишут сейчас программисты это типичные сайты. И вот там-то как раз творчества у программистов минимум. Все творчество в этих проектах у дизайнеров.
Конвеер тут как раз подходит. Ибо организация довольно быстро вырабатывает свой стек технологий и пилит на них проект за проектом. Это уже не художники, а маляры. А работу маляров уже можно нормировать, что собственно и происходит. И таких программистов большинство. Это не плохо и не хорошо, это просто жизнь. Программы стремительно ворвались во все сферы деятельности и из творческой работы, программирование превращается в обычную работу. Процент творчество/процесс доходит до обычных соотношений
других профессий, по мере развития технологий.
Но в использовании привычного многим SpringMVC не вижу каких-то проблем. Это еще один приятный момент в Scala. Можно использовать проверенные библиотеки.
Начальство часто тяжело уломать использовать какой-то Play. Да и на Spring-то часто несогласны, ибо «За покупку IBM еще никого не увольняли» )) А это нормальный вариант, чтобы уж совсем не погрязнуть в Java EE Bean'ах и в тоже время изучить новые технологии.
У меня был проект, где JavaEE писали полностью на Scala, со всеми EE-шными аннотациями и прочими прелестями. Этакий ScalaEE. Только потому, что был продакшен стек, в котором просто нет места всяким (со слов техлида, про Play и Lift) «Хипстерским технологиям». Да и Scala-то попробовать еле уломали. И только после демонстрационного проекта, который ребята пилили на выходных, в надежде глотнуть свежего воздуха со Scala. Ибо JavaEE уже порядочно всех за долбала.
И вполне себе отлично пишется. Хоть и выглядит странно)
И меня всегда удивлял такой подход. Что это вообще значит «на Java на Scala»? Мы же не в секте какой-то.
Напомню, для тех кто на бронетехнике, Scala это мультипарадигменный язык. Это значит, что можно писать как простой ООП код, так и зубодробительную функциональщину.
В примерах приведен простой ООП подход. Ну зачем, скажите мне, везде пихать навороченную функциональщину, на которую способна Scala? Ну в Java вы же не пишете все на дженериках или интерфейсах, только потому что они там есть? А если вдруг увидели простой класс без дженериков, не говорите многозначительно «На Java на C»?..
Сами создатели языка разделяют разработчиков на 2 категории. Создатели библиотек/фреймворков и прикладные программисты.
Вот для фреймворков подходы разработки свои, там и проявляется вся мощь языка. А на прикладном уровне это не так ярко выражается. К тому же, на прикладном уровне работают разного уровня разработчики. Код, приведенный в примерах может понять и начинающий разработчик на Scala. Мало того понять, он и писать сможет. А в реальных проектах это не маловажный факт.
Ну не получится сесть и моментом начать писать все в Scala стиле. А такой подход он вполне хорошо подходит для переезда или добавления Scala в существующий проект.
А так как инфы минимум, да еще и с левого акка — это чисто рекламная акция.