Архив недели @ftsymbal
Понедельник
Всем здравствуйте! Меня зовут Федор. Я из Нижнего Новгорода. Должность - технический менеджер в компании Orion Innovations. Основная область экспертизы – Android Platform. Про то, что это такое, расскажу в первый день.
Хотя я и из Нижнего, всю эту неделю я буду писать из Шерегеша. Так что твиты про Андроид могу разбавлять твитами о каталке на лыжах. Никто не против?
План на неделю такой:
Пн. Чем в Андроиде занимаются платформщики
Вт. Архитектура Android OS
Ср. Обновления Андроида
Чт. Модули ОС
Пт. Мотивация – зачем мы кодим?
Сб. Андроид на автомобилях
Вс. Пока не определился
Ничего в плане гвоздями не прибито. Планы могут и поменяться. Вообще – основное желание, за неделю обсудить будущее Андроида. Куда, так сказать, катится вся эта операционка. Если у вас есть мнение на эту тему, то я всецело призываю его не скрывать и делиться.
Итак, кто такой Android Platform разработчик: Если очень коротко, то так называют всех, кто правит код AOSP. Как правило, платформный разработчик участвует в разработке прошивки для Android устройства.
Определение довольно широкое. Под него попадают, в принципе, и разработчики системных приложений и лончеров. Так что платформенные разработчики тоже делятся на категории.
Высшая (в плане архитектуры системы, а не грейда) каста – это как раз разработчики системных приложений. По сути работа этих ребят мало отличается от разработки обычных приложений. Разве что, пишут они под один или несколько конкретных устройств.
Ну и билдить AOSP им все-равно, как правило, приходится. Как и всем остальным. А это не так просто бывает. Чистый билд Android OS занимает 3-4 часа на нормальном билд сервере.
Ниже на уровень владения Framework разработчиков. Они пишут системные сервисы. Как правило, пишут на Java. Зачастую это все одна команда с разработчиками приложений. Не всегда у компании достаточно денег на две независимые команды.
Собственно говоря, на Framework уровне пишется большая часть внутренней логики и пропиетарных фич данного устройства.
Ну и ниже всех BSP разработчики. По сути, это Embedded разработчики. Они ковыряются в дровах, HALах и бутлоадере. Их задача – сделать так, чтобы устройство стартовало и все железки работали. Пишут на Си и плюсах. Иногда "плафтормщиками" называют только эту подгруппу.
Как правило, джавистов и плюсистов все же разделяют на две команды. Но не всегда. Иногда у заказчика не хватает денег на две команды и тогда все занимаются всем. И плюсами, и джавой, и котлином. Самый прикольный вариант, на мой взгляд.
Вообще, основной кайф платформенной разработки, на мой взгляд, именно в том, что можно залезть поглубже и посмотреть как оно работает изнутри. Хотя, по идее, весь Андроид – это Open Source. Кто угодно может посмотреть реализацию того или иного метода фреймворка.
Из интереса, хочу спросить общественность: а вы когда-нибудь смотрели в код AOSP?
Есть, кстати, еще один вариант платформенной разработки – кастомные ROMы. Те, что публикуют на 4pda и XDA-developers. Вообще говоря, на этих сайтах много всего интересного для платформееного разработчика.
Судя по результатам опроса большинство все же не боится смотреть в исходники AOSP. Это обнадеживает.
Если вам вдруг интересно углубиться в тему платформенной разработки, то лучше всего начать с книги Embedded Android by Karim Yaghmour.
На source.android.com конечно тоже полно информации. Но там еще нужно постараться, чтобы понять, с чего лучше начать.
Вторник
Сегодня у нас по плану архитектура Android OS. Тема весьма большая, и есть у меня сомнения, что я её всю смогу покрыть. Ну да посмотрим, как пойдет.
Вариант 1.
Вариант 2.
Вариант 3.
Вариант 4.
Какая вам больше нравится?
Все четыре картинки из официальной документации. Я думаю у гугла есть специальная должность по рисованию этой картинки. Зачем иначе нужны 4ре варианта - я не знаю.
Система скипассов в Геше напоминает конкурирующие фреймворки:
1.Их много разных и они друг-друга не очень любят
2.Каждый имеет свои преимущества (подъемники/фичи)
3.В итоге оказывается, что половина из них не работает при малейшем ветре
По картинкам можно догадаться, что в основе Андроида ядро Linux. Но про это все уже слышали, я думаю.
Но я полагаю, далеко не все знают, насколько сильно ядро нужно "доработать" чтобы поверх него запустился Андроид.
Из интереса, как вы думаете, ядро Linux в Андроиде отличается от «ванильного» ядра – того что выпускают Линус Торвальдс, GKH и компания?
На самом деле, все три ответа имеют право на существование. Все зависит от того, про какую версию ядра, Андроида и про какой телефон мы говорим.
Дело в том, что Андроид изначально требовал некоторых фич (напр. Binder, Wake Locks), которых в ядре по умолчанию не было и ядро приходилось патчить. Но потом эти фичи в Mainline подтянули.
Однако Андроид за это время тоже не стоял на месте и стал требовать уже новых фич. Плюс некоторые из новых фич опциональны, и андроид без них работать будет, но какую-то из фич Андроида придется отключить.
То есть это непрерывный процесс, и в зависимости от того, какую версию Андроида с какими фичами и на каком ядре мы поднимаем патчить нужно больше, меньше или совсем не нужно.
В последнее время этот процесс Гугл активно формализует. Вот еще одна красивая диаграмка:
LTS – Это версия ядра от Торвальдса и компании. И как можно догадаться по диаграмке она несколько отличается от Android Common Kernel (ACK). На данный момент, как я слышал, отличается не так уж сильно. Буквально одной фичи, необходимой для запуска Андроида, в LTS не хватает.
ACK - это сравнительно новая фишка. Это такая версия ядра, котороя основана на LTS и куда добавлены все фичи, необходимые для запуска Android.
Но важно понимать, что в ACK не входят драйвера устройств (так как они у каждого устройства свои). Драйвера будут добавлены потом, вендором чипа и производителем устройства.
Кстати, интересный момент – в платформенной документации под вендором, как правило, понимают вендора чипа. А производитель устройства – это OEM.
Самое интересное, что сейчас происодит с ядром – это Generic Kernel Image (GKI). По-сути, Гугл поделил ядро на “Core Kernel” и обвязку в виде Vendor Modules. “Core Kernel”, кстати, в русском переводе документации звучит как «ядро ядра». Это не я придумал – это оно там реально так
Так вот, самое интересное, что это ядро ядра скоро будет одинаково на всех Андроид устройствах. Начиная с 12го Андроида это будет обязательно. Драйвера и всю свою обвязку вендоры и OEMы будут через модули подцеплять.
И есть у меня большое подозрение, что GKI этот будет обновляться как APEX модуль через Google Play. Официально это пока не объявлено, но по всему оно к тому идет. Но это я уже вперед забегаю: про модули и APEX будем в другой день говорить
Я смотрю, самый новый вариант картинки побеждает. Видимо, чувак что их рисует не зря свои 400к получает.
Несмотря на то, что картинки, которые я постил выше меняются не так сильно, в реальности, архитектура ОС эволюционирует довольно бодро.
Самое большое изменение архитектуры -это наверное был Project Treble (из 8го Адроида). По-сути, до него, картиночки не слишком соответствовали действительности - слишком много было зависимостей между различными уровнями.
А с приходом Treble в архитектуре андроида еще большую важность обрел Binder IPC. По сути, большинство компонент системы сейчас общаются друг с другом именно через Binder.
Вернее даже через BinderЫ. Не все наверное в курсе, но Binderов в Андроиде сейчас 3:
binder-это для обычных приложений и фреймворка
hwbinder-для HALов. Там интерфейсы определяются не через AIDL а через HIDL
vndbinder-для вендоров, если они хотят использовать AIDL вместо HIDL
Ходят слухи, что Гугл планирует полностью уйти от HIDL и оставить только AIDL (ввиду того что теперь появилась такая штука как Stable AIDL). Тогда hwbinder возможно исчезнет.
Вообще, Treble не очень новая тема - 8й Андроид был давно. Так что остановлюсь на том, что пропиарю для интересующихся мой доклад с Мобиуса 2хлетней давности: youtu.be/ctYJno7dx4s
Среда
Погода в Шерегеше обнадёживает.
Так, сегодня был powder day и я укатался. Но долг превыше всего - буду писать по плану. А то @igrekde паспорт не отдаст
Благо, сегодня любимая мной тема - обновления Андроида. Я про неё не так давно статью целую накатал - грех не пропиарить: medium.com/swlh/the-epic-…
Пересказывать все что там написано наверное не буду, смысла нет. Если читать совсем лень, то вывод такой: после Project Treble в Андроиде с апдейтами на новую версию ОС стало лучше, а после Project Mainline апдейты уже не так релевантны, как раньше.
Вообще, для начала устроим два опроса. Первый будет с точки зрения пользователя. Когда вы выбираете себе телефон, насколько вам важно, чтобы на нем крутилась последняя версия ОС?
И второй вопрос, для разработчиков. Вы смотрите на Distibution версий, когда выбираете Minimal SDK?
И, если не сложно, напишите какой Min SDK у вас в проектах преобладает?
Кстати да. А есть те, кто выбрал iPhone именно из-за того, что там лучше с обновлениями?
Когда камера не очень и закреплена на шлеме, эпичный фрирайд превращается в шатание пьяного медведя по лесу
Да и высоту не всегда правильно рассчитываешь
По результатам пока выходит, что людям важны обновления на последнюю версию. Это, в принципе, соответствует тому, что я слышал от производителей телефонов. На форумах поддержки вопрос: "Когда обновитесь до последней версии?" всегда в топе.
Многих вендоров это смущает, так как им кажется, что стабильность, производительность, безопасность и пр. важнее.
Мне лично кажется, что все дело в том, что такие параметры как удобство интерфейса, например, очень трудно измерить. Зато версия Андроида это очень четкая метрика. Поэтому при выборе телефона многие используют её и параметры железа.
Пока результаты выглядят ожидаемо. Большинство разработчиков готовы отбросить 5-25% потенциальных пользователей, в зависимости от того, какие API им нужны.
Но даже если вы выбрали потерять четверть пользователей, то вам нужен 24й SDK. А ему уже 4 года...
Вообще, интересно посмотреть, поменяется ли ситуация после Project Mainline (про него будет подробнее завтра). По идее, чем больше вещей будут апдейтится через модули, тем меньше пользователю надо беспокоится о версии Андроида. Но знают ли люди про модульные апдейты...
Some of our users, primarily in Europe and the Middle East are currently experiencing connection issues. We're working to bring them back online. 🤠 Please hang on, and sorry for the inconvenience!
Сначала Facebook, потом Гугл, теперь Телега. И все в течении недели. Нам очень не хватает нормальной теории заговора. twitter.com/telegram/statu…
@mobileunderhood Это такой адвент - провожаем 2020
Какой год, такой и Адвент... twitter.com/freken_kate/st…
Четверг
Сегодня утром у меня был вот такой термос в рюкзаке. Очень хорошо тепло держал, кстати. А потом я обнаружил что где-то в лесу я его поменял на сосновую ветку и килограмм снега. Лучше надо рюкзак закрывать, короче.
Сегодня говорим про Project Mainline и модули. Можно сказать, что это продолжение вчерашней темы.
Статьи про Mainline у меня нет – есть выступление на GDG Devfest - youtu.be/zbebx1Kvqho . Пиарится, так по полной.
Что нужно самое главное понимать про Project Mainline:
Он не сделает апдейты Андроида быстрее. Он сделает их менее релевантными.
Из трех целей Mainline - Security, Privicy, Consistency третье самое важное.
Consistency - это в первую очередь Developer Consistency. Идея в том, чтобы самые критичные вещи работали одинаково на всех телефонах, вне зависимости от вендора.
По сути, Гугл пытается пройти по тонкой грани, между стандартизацией и гибкостью системы. Им нравится, когда вендоры придумывают что-то новое. Но придумывать они должны "правильно".
И эти самые модули - это такой заборчик, за который вендоры заходить не должны, чтобы грядки Гугла не потоптать. И этих заборчиков в Андроиде будет становиться только больше.
Означает ли это, что в скором времени телефоны друг от друга будут отличаться только лончером и характеристиками железа? Скорее всего нет - Гугл все-же оставляет вендорам некоторые возможности кастомизации. Но возможности эти все более четко расписаны.
Кто практически точно в выигрыше - так это разработчики приложений. Чем дальше, тем меньше нужно будет телефонов для тестирования.
Из всех модулей самый интересный - это безусловно Runtime. В него входит ART и много всего другого, критичного для работы системы. По-сути, этот модуль - самое важное, что есть в Android OS.
Кроме того, это единственный модуль, про который в документации написано: Unlike other modules, the Runtime module isn't updatable and doesn't receive updates to functionality outside of the normal Android release cycle.
То есть модуль есть, но апдейтить его отдельно нельзя. Зачем же, спрашивается, он тогда нужен?
Кроме того, Runtime почему-то не фигурирует в официальных пресс-релизах Гугла. Хотя казалось бы, что может быть важнее?
Из-за этого, кстати случаются новости типа вот этой, которую много кто перепечатал. xda-developers.com/google-android…
Если лень читать, там один чувак заметил такой коммент в код ревью Андроида: "In Android S, ART becomes an updatable Mainline module." На основании этого идет куча рассуждений на тему, что все это значит.
Но фишка в том, что в официальной документации Runtime является модулем еще с 10го Андроида. Я по этому поводу даже общался с @MishaalRahman. По его словам Runtime не является обязательным для вендоров и в реальности существует только на Пикселях. Так это или нет - я не проверял
Объяснение, которое кажется мне возможным такое: Гугл планировал сделать Runtime модулем еще с 10го Андроида. Однако вендоры этому сильно воспротивились. Видимо, Гугл согласился дать им отсрочку на 2 года. К 12й версии все должны будут свои изменения из Runtime убрать
Возможно часть этих изменений Гугл даже затащит в базовый код Андроида. Но только от самых крупных вендоров. Остальные наверняка пойдут лесом.
Но это все мои спекуляции. Я в Гугле не работаю. Если тут есть Гуглеры, поделитесь инсайдом :).
📈 Project Treble is making OS updates faster and easier to deploy. Qualcomm mobile platforms will now offer an extended period of OS and security updates, allowing customers to lower the costs of upgrades and launches. Learn more ↓ goo.gle/3r3Ptpj
Только вчера говорили про Treble и тут такая новость. Я статью прочитал, но понял только то, что Куалкомму сделали зашибись. Как конкретно они сделали зашибись и будет ли зашибись другим SoC вендорам в статье не уточняется. twitter.com/AndroidDev/sta…
Вообще модульность и как её правильно готовить сейчас популярная тема. И неудивительно...
Но Гугл тут со своими модулями конечно всех превзошел. Все-таки им нужно модули шарить не только внутри одного приложения и даже не внутри одной компании. Модули Андроида должны быть совместимы друг с другом, с остальной ОС и со всем тем, что потенциально могут придумать вендоры
Это не такая простая задача, и они её решили приняв всего 3 принципа:
Модульные апдейты не меняют API модуля
Модули используют только API, которые покрыты CTS
Модули используют только стабильные интерфейсы
Первый принцип вполне понятен. Если при обновлении поменяется API модуля, то вещи, использующие данный API перестанут работать.
Второй принцип говорит про CTS, а это, в основном, Юнит тесты, которые обязан пройти каждый Android телефон. Таким образом модуль может быть уверен в своих внешних зависимостях.
Третий принцип требует пояснения понятия стабильности. Оно сводится к отсутствию неструктурированных типов данных и к обратной совместимости. Более побробно можно почитать здесь:source.android.com/devices/archit…
В какой-то мере, как мне кажется, эти принципы могут быть применимы и в разработке приложений. Хотя, вероятно, многие найдут их уж слишком ограничивающими.
Сегодня познакомился с отчаянным бордером. Вот он быстро от меня уезжает в лесу. Его инстаграмм instagram.com/tinvorobev/
Кстати, в Шерегеше, по моим ощущениям, бордеров гораздо больше, чем лыжников. На большинстве курортов ситуация обратная. Давайте посчитаемся: вы на чем катаете?
Пятница
Сегодня по плану у нас была мотивация. Но был запрос на то, чтобы рассказать про Андроид на автомобилях пораньше. Поэтому давайте немного переиграем и сегодня поговорим про Android Automtotive и про Android Auto
Я обычно тут рассказываю про то, что Automotive то не Auto, а совсем другая система. Почему Гугл решил назвать их столь похоже я не в курсе. Какой-то кризис креатива.
В документации Андроида, даже есть специальный пункт, объясняющий отличия одного и другого: source.android.com/devices/automo…
Раз у Гугла такие проблемы с креативом, давайте попробуем придумать оригинальное название для Android Automotive OS. Мой вариант - Cardroid. Пишите ваши в комментариях.
А вы знали про то что Autmotive это не Auto?
Вся суть Android Automotive в том, что крутиться он будет не на телефоне, а на машине. А машин в мире много - по 90млн в год новых штампуют. И живут они подольше, чем телефончики
Плюс, вся Automotive индустрия, на самом деле, очень богатая. Общая стоимость машины такова, что 100-200 баксов за новый продвинутый девайс с Андроидом легко в ней растворятся. Зато красивый, знакомы пользователю UI это отличный selling point.
Да и опыт выхода на новые рынки у Андроида есть. Android TV отожрал огромную долю на рынке Smart TV, при том , что отличий от мобильной версии Андроида там совсем немного.
Так что перспективы новой ОС мне кажутся весьма радужными. А это значит, что скоро будет большой спрос на допиливание приложений под новую ОС. Так что если есть желание и время поизучать что-то новое, то Automotive будет неплохой строчкой в резюме.
Одна из возможных причин, почему Гугл раньше не заточил Андроид под машинки - это безопасность. Глюк приложения на 100км/ч может иметь весьма печальные последствия.
А Американская судебная система может их сделать печальными еще и для Гугла- подавать в суд на корпорации там любят.
Да и злобные русские хакеры не дремлют. Если в системе будет дыра - пролезут и выключат у машины тормоза. Или печку включат - а в Калифорнии неизвестно, что хуже.
Так что Гугл в Automоtive очень заморочился по поводу того, как сделать систему безопасной для водителя во всех смыслах. Отличий от мобильного Андроида в новой OS гораздо больше, чем в Android TV или в WearOS.
Вообще, автомобильных IVI систем на Андроиде уже хватает. Однако у них есть пара важных недостатков:
Oни очень ограниченно интегрируются с машиной.
Там нет Play Store и набор приложений оответсвенно ограничен.
Первый недостаток у Automotive отчасти сохраняется. Сама система позволяет производителям машин интегрировать Андроид с внутренними подсистемами. Но не факт, что все будут готовы это сделать.
А вот второй недостаток исчезнет - устройства на Automotive Гугл будет сертифицировать и PlayStore Там появится. Но на приложения будет наложены дополнительные ограничения в виде Driver Distraction Guidelines.
Driver Distraction Guidelines это то, что обязательно нужно изучить, прежде чем начинать писать под Android Automotive. Основная идея очень простая: Приложение не должно отвлекать водителя от дороги.
Более детально это выражается в новых рекомендациях для дизайнеров (developers.google.com/cars/design/au…) и в том, что называется UX Restrictions
UX Restrictions можно кратко описать такой картинкой:
UX Restrictions это, например: No Video или Limit String Lenght. Активити должны на эти рестрикшены подписаться и реагировать на их изменения. Если они это делают правильно, то их в манифесте разрешается помаркать как Distraction Optimized.
Когда на машине передача поменятется с Pаrked на что-то другое система врубит рестрикшены. И только те активити, что помарканы Distraction Optimized смогут работать. Остальных система убьет.
А вот имел ли разработчик право помаркать активити как Optimized будет решаться на PlayStore Review. Так что в теории, если вы не будете выкладывать ваше приложение в маркет, то можете смело помаркать все активити как optimized и они будут работать. Но вообще так низя.
Но вообще в Automotive еще очень много всего перефигачили относительно обычной мобильной версии: Power Management совсем по-другому устроен, Multi-Zone audio, поддержка внешних камер, и.т.д.
Если про это все писать, то недели не хватит.
Давайте еще, для привлечения внимания, 2 картиночки с машинками на которых Android Automotive уже работает:
Обе машинки, кстати, электрические. Не знаю, совпадение это, или Гугл целенаправленно смотрит в сторону именно этого сегмента рынка.
Да не писал еще сегодня про Шерегеш. Погода испортилась. Завтра беру гида - пойдем искать снег.
Пока выходит, что я в меньшинстве. Лыжники, где вы?
Суббота
Не махнуть ли в горы...
Всех, кто еще не в отпуске, поздравляю с выходными. Сегодня будем философствовать на позитивную тему: "Зачем оно все ваще?"
Для начала, давайте устроим пару опросов. Первый такой: как так получилось, что вы стали кодить? Выбирайте самую важную причину.
Если быть абсолютно честным, то мой вариант это 4. Если у вас свой вариант - пишите в комментах.
Второй вопрос такой: почему вам важно писать хороший код?
Собственно, есть две причины, почему тема мотивации кажется мне интересной:
Многие менеджеры не совсем понимают зачем их сотрудники пишут код.
Многие разработчики теряют мотивацию из-за того, что их ожидания оказываются обманутыми.
Пару лет назад у нас в компании HR придумал что-то типа "портрета компетенций идеального разработчика". Там было все, вплоть до активности на тимбилдингах и посещения курсов по английскому. Качество кода, правда, отсутствовало.
У всех компетенций, кстати, был одинаковый вес. То есть участие в развлекательных мероприятиях и общительность ценились одинаково с "выполнением задач грамотно и в срок". Предлагалось эту модель использовать для оценки и премирования сотрудников.
Модель в компании как-то не прижилась. Даже не знаю почему...
Первый промежуточный результат опроса: за деньгами в кодеры идут менее 20% людей. Для остальных деньги, как минимум, не были основной мотивацией. При этом зарплаты в IT всем на зависть. Видимо, гнаться за деньгами и правда не стоит...
На мой взгляд есть 3 главных мотиватора в работе:
Комфорт
Интерес
Результат
Комфорт это и зарплата, и хорошая команда, и удобное кресло и адекватный менеджмент, и много еще всего. И одно может компенсировать другое, до определенной степени.
Интерес - это и сложные задачи, и креатив, и модные технологии. Причем у разных людей интересы разные. Кто-то любит дизайн, а кто-то багфикс.
Результат - это то, насколько круто и важно то, что вы делаете. Рисовать кнопки гораздо прикольнее, если они будут управлять марсоходом.
У @parahall был отличный доклад, про то, что результат может быть даже важнее, чем интерес- youtu.be/cqPrIksyXtM
Давайте еще один вопрос задам. Что для вас важнее в работе?
Еще один интересный момент из опроса про качество кода. Практически никого на это не мотивирует код ревью. А ведь это один из самых распространенных инструментов... И нафига он тогда нужен получается?
Смотрите, для большинства здесь основным мотиватором является интерес. Для довольно творческой профессии кодера это ожидаемо. Проблема в том, что зачастую бизнесу нужно не интересно, а быстро и дешево.
Ну и напишу очевидное, что и по опросам видно. Люди все разные и мотивация у них разная. Кому-то нужно баблище, кому-то сделать марсоход, кому-то самый модный фреймворк заюзать. И это нормально. Главное понимать что в первую очередь нужно вам и выбирать работу по себе.
Что интересно, меньше всего людей выбрали "Результат", как главный мотиватор. Но с точки зрения бизнеса такие работники наиболее ценные - они и за продукт душой болеют, и работу неинтересную делают и денег не просят постоянно.
Воскресенье
Итак, воскресенье, моя вахта на @mobileunderhood подходит к концу. Сегодня будем говорить обо всем подряд и подводить итоги. Если есть интересная тема - пишите, обсудим.
Давайте расскажу мои впечатления от Шерегеша. Возможно кому-то это поможет решить, стоит сюда ехать или нет.
Во-первых, добраться из Москвы сюда довольно просто. Рейсов до Новокузнецка хватает. А оттуда на такси за 2-3 часа и вы уже на месте.
Подъемников, в принципе, хватает. Особых толп, как в Поляне, я не заметил. Правда их частенько закрывают из-за ветра. И много старых подъемников. Зачастую это кресла без купола и подогрева. При местной погоде это не всегда комфортно.
Вообще, погода в декабре весьма здесь суровая. Солнце бывает нечасто, ветер, холодно...
Трассы в Геше под стать погоде. Готовят их весьма расслаблено. На красной трассе посреди вельвета вполне может оказаться яма или здоровенный камень, которые не будут ничем обозначены. Кроме того, по ним легко могут подниматься снегоходы, оставляя за собой глубокие борозды.
Так что если вы катаетесь только по трассам, то в Геше вам будет тяжело. Возможно местные просто считают, что кататься по трассам здесь глупо. Ведь здесь есть лес.
Леса в Геше полно -он покрывает всю гору. В нем красиво и полно снега. И он выкатывается почти весь - через два дня после снегопада найти нераскатаный пухляк уже проблема.
Чего в Геше не хватает, так это уклона. Гора довольно плоская. Крутые места есть, но их не так много, и после них как правило длинный пологий выкат. Для продвинутых это немного скучновато, но для большинства такой уклон будет в самый раз.
Самое замечательное, что есть в Геше - это снег. Он искупает все недостатки: его много, он мягкий, пушистый. Это идеальный пухляк и его здесь довольно легко застать.
В общем, отличное место - всем рекомендую.
Вообще, в продолжение вчерашней темы можно было бы написать про выгорание и Work/Life balance. Но я всю неделю в отпуске сижу в твиттере и пишу про Андроид...
На этой неделе Гугл забил еще несколько гвоздей в крышку гроба Android Things. developer.android.com/things . Кто не в курсе, это была попытка приткнуть Android в IoT.
Возможно, на смену придет Fuchsia OS. Про нее сегодня поговорим.
Так, как обещал, про Фуксию. ( Кто не в курсе -это нова ОС от Гугла). Если коротко - пока хрен знает зачем она нужна.
Мы её в начале этого года покрутили немного из интереса: пособирали код, позапускали на том железе, что было, и на эмуляторе. И как-то не впечатлило.
Во-первых, функционал Fuchsia OS пока очень ограничен. Во всяком случае, на начало года в системе мало что можно было сделать.
Во-вторых не очень понятно, на какой сегмент устройств нацелена данная ОС. Если читать документацию, то получается, что это вообще такая система на все устройства, которая за все хорошее и против всего плохого.
У Android Things хотя бы было понятно, на какой маркет они ориентируются. А Fuchsia - это просто ОС, типа Линукса. Но чем она принципиально будет лучше Линукса - пока не ясно.
При этом Google Фуксию вроде-бы активно разрабатывает. Недавно он даже открыл её для Public Contribution. то есть, видимо какую-то цель Google в этом всем видит, но с нами пока не делится.
Возможно Fucsia - это и правда просто желание сделать ещё одну ОС, просто, чтоб была.
Возможно, обжегшись на Dalvik, Google теперь дует на Linux, чтобы заменить его ядро в Андроиде. В пользу этого говорит тот факт, что ART можно запустить поверх Фуксии.
Возможно, Фуксия - это замена самому Андроиду, кода он пользователям почему-то надоест.
А возможно Фуксия- это просто такой полигон испытания различных идей, самые удачные из которых будут потом перетянуты в Андроид.
Но скорее всего это какая-то комбинация данных мотивов, и Гугл еще сам до конца не решил, как в итоге новую ОС спозиционировать.
А вы верите в будущее Фуксии?
Те, кто верит в будущее Фуксии, напишите как вы его видите. А то пока ваша точка зрения как-то не представлена.
По результатам недели - тема о мотивации получила гораздо больший отклик, чем любая техническая. И это на канале о мобильной разработке. Переквалифицироваться что ли в мотивационные спикеры...
В общем, тут уже довольно поздно, пора закругляться и сдавать пост следующему автору. Надеюсь, что вам было интересно, и всем удачи в следующем году.
