Dion Almaer

Software, Development, Products

Google

Google I/O 2018: Integration in the Open

Leave a Comment


With Google I/O 2018 kicking into gear, I found myself looking back at my thoughts on last years event and thinking about what is changing and what is continuing with respect to the journey for our developer platforms and ecosystems.

Technology exists within the framework of what is going on in the world. On the one hand, the world gets better for more people every day, but on the other hand we also know how fragile things are, and how much pain people are in as we see growing inequality in areas. Within this context we are seeing technology companies look deeper into themselves, thinking more about what is being created. Are we building experiences that are meaningful for people? That is the question at hand, and the consumer keynote shows some of what Google is thinking about here.

The Integration Story

One of the foundations of integration is componentization, and we are seeing great strides here across our platforms.

Android’s new Jetpack libraries accelerate development

This year builds on last years Kotlin news, and shows our vision for mobile Android development. App bundling and dynamic delivery allows you to split up your app, giving users the ability to download the pieces they need. If you want to reach all of your potential users and deliver the best possible experience to them, you should be focusing on the vitals, and our tooling and platform is working on making life much easier for you here. With Actions and Slices, you can bring pieces of your app to new surfaces on Android to surface where users want them.

Android Studio 3.3 brings a slew of improvements and cuts a huge amount of time out of your development. Did you see Tor demo how quickly the emulator starts now? With Jetpack, we bring together the best of architecture components with the support library, allowing you to develop much faster, reach more users with the results, and all with top notch Kotlin support.

And this year Android really hits new form factors hard with great updates across Wear, TV, and Android Things hitting 1.0.

Spotify shows off their Desktop PWA

On Web, if you follow the Lighthouse (newly updated for I/O!) well-lit path, you will be able to deliver ephemeral experiences that integrate deeply with the host operating system. Performance is still the number one area of focus, but you will see that we are broadly looking to get rid of friction wherever it lay. Web packaging takes fast and makes it instant, and it is now simple to get your users signed up, signed in, and able to quickly pay.

While the first PWAs that drew attention were mobile, with desktop PWA support we get to see how your investment scales. Twitter has been able to take their “lite” mobile app and bring it to the desktop/tablet, Windows store, and with the Chrome desktop PWA affordances you get an amazing experience that marries the your own focused app with browser features such as URL sharing, find in page, casting, etc. This has allowed Spotify to integrate their web experience, for Starbucks to double the usage of their PWA.

Chrome DevTools continue to improve with end to end support for the latest in layout (grid), JavaScript (eager eval, async/await, etc), and even end to end debugging for your node services. With Lighthouse baked in and lighting the way, you can see how far the frameworks are coming along to help deliver the fast experiences the Web needs. Polymer 3 and lit-html allow you to build blazingly fast experiences that are close to the metal, and integrate so well with Redux and friends. Angular 6 joins the custom elements party and the Ivy runtime shows how much of a diet it has been on for great enterprise products. And AMP is here for an opinionated fast path with support for Stories and other new components that you can drop in and use. The Web is here for you, from rich content to complex apps that can tie into new ecosystems with WebAssembly.

Turn on the new Linux support in ChromeOS settings

You may notice more Pixelbooks at I/O this year. I have been using desktop PWAs a lot recently, as I have been living on a Pixelbook. I had tried to make the switch to ChromeOS several times, and this is the first time that it has stuck.

I used to feel constrained inside a browser, but this has flipped since I changed the way I used the system. On my desktop, I normally have a set of pin’d tabs and Ctrl/Command-# to jump to a particular main app (email, calendar, tasks, chat). On ChromeOS I pin those as apps and Alt+# to jump to them.

This frees up my browser. The “email” browser turns out to be my main source of tabs, and I see a new pattern forming. It turns out that a lot of “apps” are sources for browser tabs. I click on links in Gmail AND from Calendar AND Asana AND Chat AND Twitter. This drives an interesting world where the first tab is the main source of other experiences that can be tied to that app instance.

Having the desktop UI (three vertical dots) available brings the best of the browser to the app. The user agent is out of the way, but you have a quick path to find in page, font sizing, casting, autofill, and copying the URL for easy sharing…. and you can imagine so much more.

With the release of secure Linux apps via VM/container goodness, I am able to run my favorite developer tools (Visual Studio Code, Atom, Android Studio) as well as other key Linux apps (including other browsers for testing). It’s still early, but it’s already great to be able to develop here.

Linux and the Web is great, but what about access to the entire Android and Assistant ecosystem? It’s all here, and with the world class security of ChromeOS (and ability to login to a new machine and be right where you left off… which feels like my college days with XWindows!).

Reach the assistant through Web and Android

In fact, the Assistant, and Actions on Google in general, is another perfect example of integration. Web developers, Android developers, and backend developers should all be able to get their experiences in front of Assistant users. With Actions for these platforms, you can get a broad reach, from something quick and direct all the way to a full conversational experience across text and voice, and with RCS you can leverage the texting experience all the way to Android Auto.

ARCore: now with Sceneform, Augmented Images, and Cloud Anchors

AR and VR is yet another example, where the technology is available for you to use the world around you. I can’t wait for a future browser for the world (whether it be Earth or something else immersive), and that world is a lot closer with the new tools that we announced today:

  • Sceneform is a new 3D SDK for Java developers
  • Augmented Images allows you to associate AR content with the real world
  • Cloud Anchors bring a shared collaborative environment to life. Your apps, on iOS or Android, can manipulate space in a way that all of your users can see.

ML SDK across the platforms; from edge to cloud

The other piece of integration is the role of client and server. We continue to live in a disconnected world, with variable levels of compute and network power on our devices married to amazing levels of compute on the server. Developers need the ability to drive as much as possible on the edge where it makes sense, but also use the power of the data center where needed. A strong theme at I/O continues to be the role of machine learning and AI, and not only do we have a lot to share on the side of Google Cloud and TensorFlow, but we keep bringing that to the client with APIs such as ML Kit, able to reach all platforms via Firebase.

In fact, ML Kit is able to infer on device, but also use the Cloud to get more detail (e.g. maybe on device detects a “bridge” in a photo, but the Cloud comes back with a more detailed “Golden Gate Bridge”).

The APIs in the initial kit include:

  • Text recognition
  • Image labeling
  • Barcode scanning
  • Face detection
  • Landmark recognition
  • Smart reply

And you can expect a lot more to come!

Same great design system, themed your way

The last piece is the UI, and we have a major upgrade to the world of Material Design this year. People have noticed our own properties get large upgrades, such as the recent Gmail redesign, and this work is on the back of the new Material Theming approach. Companies have wanted to take the material design system, and really brand it to their needs, and with the new theming system it is much much easier to do just that.

The new system comes with new tools, such as the Theme Editor, which are one of a series of updates where we try to help you build rich experiences with more ease. All of the components are released as open source, for Android, iOS, Web, and now also for Flutter. Flutter announced beta 3 which brings large improvements, and could be a perfect fit for your cross platform needs.

Phew, this is only the tip of the iceberg on what we have in store for I/O this week. The teams have been working hard to build useful things, and share them throughout the week with great talks. We will be rushing to get the content up as soon we can after the livestream.

One last thing. Watching and listening in is great, but there is nothing like touching the technology and seeing where things really are. This is why I always dart over to the codelabs area and try everything out.

Google I/O is truly about the integration of everything that we have to offer across our ecosystems. In that spirit, it’s most fun to see how these things work together and build bridges.

https://mobile.twitter.com/kelseyhightower/status/993846267976470528

I have always been drawn to open ecosystems, so I love that openness is baked into our DNA. I love looking at the history of Android, Chromium, TensorFlow, Kubernetes, Flutter, Polymer, Angular, AMP, gVisor, and the myriad of over initiatives that have open source at the core.

“platforms integrate
together in the open
all for us humans” — Steven Colbert #io18

Google I/O 2017: Invented w/ Others

Leave a Comment

Watch live!

I am so excited the time has come for Google I/O to kick off for the second year in our backyard, with thousands of developers coming to join hundreds of Google engineers as we geek out on tech in a festival atmosphere. I have already been at several pre-events, and what blows me away the most about conferences like this is how international they are. With all that is going on in the world, it feels great to come together as one. An immense amount of work goes into putting on the event, crafting great content for developers, and of course building the products that come to life. This isn’t just about the products that we build at Google, but a ton of partners work incredibly hard to get things ready to showcase platforms and ecosystems.

As I reflect on what I am most proud about this year, one theme is exactly this: working together with partners and ecosystems. We are fortunate enough to have a few large and mature platforms out there such as Android and the Web, and each is still pushing the boundaries and innovating. We also have new platforms and extensions that tie together our own services as well as these ecosystems. I have seen an increased effort to unifying and working together where it makes sense. For example, running Android apps on ChromeOS, running Web apps as first class experiences via PWA, having immersive reality (VR and AR) come to various platforms, and glueing things together with IoT and Actions on Google.

Computing is unbundling, and individual components have more wiggle room and ability to connect and compose with each other. These connections are supported by empowering glue such as Cloud Functions, and machine learning is there to make experiences work optimally for uses. When mobile first hit, much of the UX hit was around coming up with the right interaction on the small device and how it tied into the context it now had about you (from your location to your contacts). Now, the best experiences take that attention to detail, and they marry it with smarter services. Google Photos is a canonical example that has a very nice UI for sure, but the magic is in how I can search for [my son in green when he was four] and get results. Slack has done a great job with their UI, but it was their search functionality that originally won me over from Campfire. It is becoming a given that you should be thinking about how you can best use data to up level your experiences. We have a lot of talks on TensorFlow from beginner to advanced, but we also have many APIs that do the work for you (e.g. vision APIs). You don’t have to take a linear algebra course again to get started (but I recommend this fun way of doing so!).


Not Just Invented Here

I am really excited to hear how Android developers react to the Kotlin announcement today. I have heard developers ask about our support for such as long time, I am really excited to let them know that we are standing by it. I first used Kotlin several years back when I was frustrated at the level of Java language support, and it is a fantastic modern language. Since then the community has grown, and it has broadened its targets. I am so happy that we have embraced this rather than trying to do something new for the sake of it. We have a lot of great information on how to get started.

Beyond Kotlin, we have great new improvements in the tools and SDKs. The new architecture components such as the lifecycle management helpers are going to save so much time (and frustration). Chet, Tor, and Romain are going to have a whale of a time on stage this year showing off all the goodness. This has been the best developer-focused Android release in awhile, and this is just the start for Kotlin and these developer tools.


All boats rising

The Web has always been about community and shared evolution. It is the democracy that, yes requires compromise and working together, but results in shared change that doesn’t give too much power to a particular entity. This year we see the Web innovate faster than ever, resulting in great new experiences such as Twitter’s new PWA that comes in at a tiny bundle to get going quickly and picks up steam from there. And then there is the amazing Wego experience. The story behind that is particularly fun, as an app developer picked up Polymer (2.0 just released!) and two months later had it up and running.

We have new tools to help you take your web experience to the next level. Lighthouse 2.0 was announced and now comes baked into Chrome DevTools, and Workbox takes our battle tested sw-toolbox and sw-precache and packages it in a nicer bundle that lets you pick and choose what you want to bring service workers to your app. But again, it isn’t about what we are doing. Microsoft talked about their support for PWAs at Build last week, and other browser vendors are working with us to support the latest and greatest as soon as possible. Outside of the browsers, the framework and app developers are busy working on how to optimize for the constraints and opportunities of mobile, whilst also getting their support to desktop and other (sometimes surprising!) form factors. The Web continues to be about reaching out to all of your users and meeting them where they are.

We built a fun Google I/O action!

Reaching the full bundle

As the mature platforms continue to push the bar, we are seeing other form factors come to life too. Whether it be Actions on Google that can reach users through their Google Home, phones (and more!) giving you multi-modal access to services at the flick of a voice or text gesture, immersive new VR and AR experiences, or Android Things packaging IoT in a manner that makes it incredibly approachable and powerful.


Bringing it together

This year we brought Fabric together with Firebase, and today we are open sourcing more of the product (with more coming!) right as we add new functionality across the platform, including large new initiatives such as Firebase Performance.

What I love about Firebase is how it brings you the best tools to help you build your applications, all packed with a top notch API console and SDKs that work together.

This is all the tip of the iceberg. Unifying the unbundle, together is the cheesiest thing I have written in some time, but that is what I see when I look at where things are coming together this year. All platforms innovating quickly, but coming together where it makes sense to solve problems.

All the prep is done, now the fun part…. getting to meet old friends and new at Google I/O.

If you can’t be here in person or at an I/O Extended event, please tune in, and we are bringing more Google Developer Days to you this year!

“platforms innovate

together computing unbundles

and then we all unify.” — Stephen Colbert

What I love about Google DevRel

Leave a Comment

That tweet resonated strongly with me. I feel very fortunate to be able fight for developer success at a great company that is fortunate enough to have large platforms that both rely on developers and can also reward them. I am bloody lucky. You can say that in your head with an Aussie accent as I am flying back from a fantastic experience with great friends that I have on the DevRel team, including the local Sydney DevRellers.

DevRel as a discipline is still pretty new, and it is something that I am constantly thinking about. Different situations require very different DevRel strategies, but there are many core values that we have across all of our DevRel teams.

Engineering

Developer Relations at some companies is marketing-driven. Some cynical companies consider this akin to developer marketing, but they use DevRel as a way to stay away from the marketing label, worrying about negative connotations from developers. Google DevRel is engineering driven. This isn’t surprising, coming from such an engineering driven company as a whole, and it is very akin to the way that we have applied DevOps. You could argue that we pioneered the DevOps discipline through our SRE teams. If you read the book you see how we have strong opinions on how to run and implement SRE in a way that massively scales. SRE teams are interesting in many ways, but one of which is that they have ties to both the product teams (e.g. Gmail SRE wants Gmail to be successful) and also users and production (Gmail has to be reliable, and user privacy is key).

Our SRE teams are the result of attacking ops issues from an engineering mindset. It is important to note that this is holistic engineering, and not the same thing as “so you just write code all the time”. Solving the problem from an engineering perspective allows you to scale non-linearly.

With DevRel we look to scale this way too. Rather than having to rely on scaling armies of evangelists, we have smaller teams that do high leverage work for developers, the community, and their areas of focus. If you work on the Android DevRel team, for example, you are looking for any areas to help developers in that ecosystem. A fantastic example of success here is Chris Banes looking at fragmentation and building support libraries. You wouldn’t write an app without them.

Another good example is the Lighthouse project that stemmed from Paul Lewis and has spread throughout the team. What if developers could run a tool on their codebase that proactively tells them what they should be doing for users? The initial focus was on performance (still a major issue on the Web), but it has grown skills across the PWA spectrum and beyond. Guidance through docs, samples, and talks are vital, but they are amplified by tools like these.

I could go through every DevRel team and share stories like these where DevRel was able to improve the lives of developers at scale. One area that you may not know about is how we have shared services folk who help domain knowledge experts focus. For example, when I was doing videos back in the day they were very low-fi and simple. Over time the team built up a competence and we have a Google Developer Studio that isn’t just able to have top quality production values, but understands how to work with the developer audience. These central teams enable scaling whilst also pushing on universally high quality outputs. Another one of these teams is partner engineering, a group that works across the areas that Google has to offer. The team of world class engineers, being separate from one area, is able to focus on the success of partners.

Advocates

Long, long, ago, I wrote about the name advocates instead of evangelists and I still agree with myself (although there are many things that I would disagree with Young Dion on). It is really important that DevRel is a two way street. We do what we can to help developers through outreach for sure, but we also do so by bringing in their feedback to product teams. We are the bridge between the teams. When done incorrectly this can have some bad side effects. A product team can think “ok, my devrel is on that so I don’t have to think about it at all!” but that is not going to lead to the best success, just as if a development team ignored their architecture wrt ops. If a product team disconnects you run into situations where they begin to wonder “do developers really think this or is this just what devrel thinks?” To make sure this doesn’t happen we make sure to bring product teams and developers together. We bring them to events, run internal programs, etc…. but then know that while we are living in the community, the product teams have to spend more time making and improving on the product.

Ecosystems

We naturally think about long term ecosystems. Product teams are working on the next version, whereas we are much more naturally tied more to the now of developer pain. Our best work is done when we have strong metrics on the ecosystem at large and the problems that we are looking to solve in there. We try to understand the ecosystem deeply, to be able to fight for developers needs.

Healthy ecosystems are sustainable and allow for success much beyond a platform. Microsoft may have had a ruthless streak back in the day, but I always appreciated Bill Gates’ thinking about the platforms. He talked about how he didn’t want to be taking too much of the profit else the other players wouldn’t be able to benefit and it wouldn’t grow. The best long term platforms have enough for everyone to thrive (including users) and the ones we worry about at the moment at those where business models aren’t fully working. DevRel fights for developers getting what they need from a platform, and making sure their model is sustainable.

Walk then talk; Develop then Relate; Repeat

It is easy to get soft and lose your way. In SRE they protect their teams from getting stuck on manual admin tasks by watching to make sure that they are engineering at least 50% of the time. In DevRel it is important for everyone to be engineering on their platform. This is how you keep your empathy with the developers that we are trying to help. It is how you find the rough edges. It is how to deeply understand issues well enough to be able to work with your product teams. Always Be Coding. The flip side to this though is that there is a “relations” aspect to DevRel. It isn’t enough to be coding in the corner, we need to get out there participating with the community and sharing our information.

We are definitely a new discipline with much to learn. I love looking around the various devrel teams who are all different, but who share the same passion for developer success. We love working on an area that we deeply understand as we are developers ourselves. It is very humbling to see the people on the team who are world experts in their fields, but they decide that DevRel is their path to help developers, a path that has huge leverage.

In a world that is being eaten by software, we want to help fuel the developers to improve that world using all that Google has to offer.

p.s. I should also note that the term “Developer” has broadened over the years. It doesn’t just mean “Coder”. For example, we have a Design Relations team 🙂

The right thing to do, is the right thing to do.