Сегодня только смотрел документацию по Actions для Ассистента, так и не понял, поддерживают ли они следующий кейс:
1. Пользователь говорит: «Окей, Гугл, открой дверь Foobar через AppName».
2. Ассистент распознает фразу, понимает, что нужно использовать AppName, и посылает Android приложению интент либо со всем распознанным запросом, либо ту часть запроса, в которой приложение заинтересовано, то есть Foobar.
3. Приложение подхватывает Foobar, само делает запрос и, возможно, возвращает результат Ассистенту.
Насколько я понимаю, это не поддерживается как минимум в двух пунктах:
1. Ассистент не умеет работать с кастомными интентами, то есть через actions.xml можно определять только те действия, которые разрешает Гугл.
2. Действие должно запускать Activity, нет возможности запустить Service.
Разработка и жизнь в Берлине дешевле, чем в других немецких городах (Мюнхен и Кельн)
В Мюнхене, насколько помню, и зп выше чем в Берлине, в среднем по больнице мобильный разработчик в Мюнхене может получать в год на 15-20К больше, чем в Берлине.
А в английской википедии почему-то очень спокойно используются и native language и native speaker, хотя, судя по статье, англоговорящие так не говорят.
Точно так же, пару настолок и книгу Milfgard взял только основываясь на впечатлении, полученном от чтения его текстов. При этом я никогда в жизни настолок, кроме этих двух, не покупал, просто когда возникла необходимость, я сразу знал, куда мне идти.
Да уж, с JRebel-то совсем неожиданно вышло. Если кто из разработчиков читает комментарии — спасибо вам огромное, вашим продуктом было очень приятно пользоваться!
Мне кажется, опасения насчет enum на Андроиде были валидны в самом начале существования Андроида, лет так семь назад, когда устройства были слабее, памяти было мало, и Dalvik был на самой заре своего существования. Сейчас отказываться от enum-ов — это экономия на спичках в большинстве случаев.
Так вполне себе обоснованное удивление же. Никто же не приходит в комментарии к видео «Меняем масло в Ладе-Весте своими руками» со словами: «А почему Веста? По информации с сайта kolesa.ru, Солярис самое популярное авто в России, так на каком основании вы тут делаете видео о Весте?»
Да и не понятно, насколько глубоко должны уходить эти вопросы. Например: «Почему Gson, а не Jackson? Почему json, а не protobuf? Зачем вам вообще сериализовать-десериализовать данные?» Какой из этих вопросов уже не подходит под «автор вопроса вполне справедливо посчитал, что автор статьи имел возможность ознакомиться с обеими альтернативами, и поделится с нами результатами своего сравнительного анализа»? Статья рассматривает один-единственный вопрос: «Как работать с Gson», а те, кому нужно сравнение с альтернативами, могут и другие источники поискать.
А иногда и обратное происходит работодатели, нанимая удаленного сотрудника, предлагают платить ему меньше просто потому, что он живёт в небольшом городе.
Я уверен, что сегодня React Native гораздо более зрелый и уже давно готов для написания production-кода.
Насколько я знаю, React Native уже сейчас используется в Airbnb при написании их iOS и Android приложений. Целиком переписывать всё на RN они не стали, там у них сейчас смесь нативного кода и RN.
Ну на 7000$ вы, насколько я понимаю, в СФ претендовали, где уровень зарплат немного другой, чем в целом по России. Поэтому не совсем понятно, сколько вы просили — среднюю зп по рынку, или же выше её процентов на 20-30.
Поэтому оптимально будет настроиться на работу философски и по возможности быть готовым сидеть и кодить с исполнителем онлайн. К примеру, мой напарник посылал индийцу код функции реализованный в версии под Андроид на Java, чтобы он быстрее понял как это можно было реализовать под iOS на Objective C, что сделало их обоих более счастливыми: программиста от того, что он понимал что нужно, а моего напарника от того, что работа шла намного быстрее.
Может быть, просто не стоило нанимать человека, настолько не способного работать самостоятельно (возможно по причине отсутствия релевантного опыта), что нужно с ним сидеть в Скайпе и заниматься парным программированием? Ваш напарник убил кучу времени на то, что вообще не должно было быть его головной болью.
Послушайте вот этот выпуск подкаста Fragmented, там как раз Вилсон давал свой взгляд на проблемы HttpComponents, и причины, побудившие его создать OkHttp. Просто сейчас ваша статья излагает довольно односторонний взгляд на проблему.
К сожалению, большинство разработчиков слепо верят Google и сразу считают, что библиотека Apache “плохая”, и нужно бежать выкидывать её из своего кода.
После этого ожидал увидеть сравнение OkHttp и Apache HttpComponents, чтобы понять, какая из бибилотек объективно лучше. Вместо этого увидел следующее:
Например, тот же OkHttp. Сам его не пробовал, но говорят, что библиотека хорошая… Ну и касательно именно OkHttp — я бы не стал использовать столь неприятно пахнущий форк.
Ну вот, точно такое же предубеждение и слепая вера в то, что HttpComponents лучше, потому что он пахнет приятнее.
А вы всё ещё помните милого парня Джесси Вилсона из Dalvik team?
Да.
А вы знаете, что сейчас он работает в Square? И именно он является создателем OkHttp?
Да.
Более того, вы знате, что OkHttp начинался как форк куска AOSP (Android Open Source Project), который в свою очередь брал свой код из Apache Harmony?
Да.
Так что это и есть по сути создание форка Apache с последующим выкидыванием оригинала из обращения (второй вариант из озвученных ранее Джесси в общении с Apache). Звучит довольно гнусно, не правда ли? Единственное что непонятно — была ли это инициатива Google или самого Джесси. Но поступил он крайне некрасиво, выкинув конкурентов с помощью Google и придя весь в белом со своим решением.
Я конечно не знаю всей истории, но в вашем изложении это звучит как какая-то теория заговора. Может быть всё куда проще, и OkHttp был создан как попытка улучшить HttpComponents? Может апачевская библиотека страдает от каких-то косяков, которые можно было исправить только переписыванием всего проекта, что Вилсон и сделал в OkHttp? Я не сравнивал их api, но может быть на OkHttp советуют переходить потому, что он лучше/удобнее/написан с учётом работы на Android-устройствах, в отличие от апачевского оригинала, а не потому, что Google и Вилсон коварны и вероломны?
У вас на картинке не тот Майк Шеридан; приведённый вами — это датский диджей, родившийся в 1991-м году, и по этой причине вряд ли принимавший участие в Stealth Project, запущенном в декабре 1990-го. Пруф.
1. Пользователь говорит: «Окей, Гугл, открой дверь Foobar через AppName».
2. Ассистент распознает фразу, понимает, что нужно использовать AppName, и посылает Android приложению интент либо со всем распознанным запросом, либо ту часть запроса, в которой приложение заинтересовано, то есть Foobar.
3. Приложение подхватывает Foobar, само делает запрос и, возможно, возвращает результат Ассистенту.
Насколько я понимаю, это не поддерживается как минимум в двух пунктах:
1. Ассистент не умеет работать с кастомными интентами, то есть через actions.xml можно определять только те действия, которые разрешает Гугл.
2. Действие должно запускать Activity, нет возможности запустить Service.
Я прав, или я где-то что-то недосмотрел?
В Мюнхене, насколько помню, и зп выше чем в Берлине, в среднем по больнице мобильный разработчик в Мюнхене может получать в год на 15-20К больше, чем в Берлине.
Это именно в долларах, не в евро? Можно еще взглянуть на первоисточники? Интересно посмотреть нижнюю-верхнюю границу, если она там была указана.
Да и не понятно, насколько глубоко должны уходить эти вопросы. Например: «Почему Gson, а не Jackson? Почему json, а не protobuf? Зачем вам вообще сериализовать-десериализовать данные?» Какой из этих вопросов уже не подходит под «автор вопроса вполне справедливо посчитал, что автор статьи имел возможность ознакомиться с обеими альтернативами, и поделится с нами результатами своего сравнительного анализа»? Статья рассматривает один-единственный вопрос: «Как работать с Gson», а те, кому нужно сравнение с альтернативами, могут и другие источники поискать.
Насколько я знаю, React Native уже сейчас используется в Airbnb при написании их iOS и Android приложений. Целиком переписывать всё на RN они не стали, там у них сейчас смесь нативного кода и RN.
Может быть, просто не стоило нанимать человека, настолько не способного работать самостоятельно (возможно по причине отсутствия релевантного опыта), что нужно с ним сидеть в Скайпе и заниматься парным программированием? Ваш напарник убил кучу времени на то, что вообще не должно было быть его головной болью.
После этого ожидал увидеть сравнение OkHttp и Apache HttpComponents, чтобы понять, какая из бибилотек объективно лучше. Вместо этого увидел следующее:
Ну вот, точно такое же предубеждение и слепая вера в то, что HttpComponents лучше, потому что он пахнет приятнее.
Да.
Да.
Да.
Я конечно не знаю всей истории, но в вашем изложении это звучит как какая-то теория заговора. Может быть всё куда проще, и OkHttp был создан как попытка улучшить HttpComponents? Может апачевская библиотека страдает от каких-то косяков, которые можно было исправить только переписыванием всего проекта, что Вилсон и сделал в OkHttp? Я не сравнивал их api, но может быть на OkHttp советуют переходить потому, что он лучше/удобнее/написан с учётом работы на Android-устройствах, в отличие от апачевского оригинала, а не потому, что Google и Вилсон коварны и вероломны?