DevFest MN recap
March 16, 2018

Latest Technology Trends at Google's DevFest 2018

Developer Collaboration
Version Control

These days, there is so much rich information available online; you can learn just about any new technology without leaving your desk. But conferences give you the opportunity to test out a broader spectrum of topics in an efficient format. I also really enjoy meeting people and learning about new technologies “IRL.”

One of the best things about conferences is hearing the questions other developers ask the speakers — they have great diverse perspectives.

The Google Developer Community has monthly meetups all over the country, but somehow, I’ve never attended one, even though I’ve worked on teams developing major products using Google technologies. I recently stumbled upon the group’s annual conference in the Twin Cities, called DevFestMN 2018, and I decided to check it out.

I got a great set of introductions to several of the most important technologies in software development today.

Machine Learning (aka ML)

I almost did not attend, because I wanted to sleep in on a Saturday morning! But I made it, and I’m glad I did. The day started with a keynote by Sara Robinson (@srobtweets). She’s a Google developer advocate, and her talk was on Machine Learning with Tensorflow, titled “Zero to ML on GCP” (Google Cloud Platform).

First, while I’ve dabbled with analytics and big data, I’m not actively working with ML and AI. Sara did a great job defining machine learning as inputs > models > predictions. The challenge is getting from input to prediction. She provided some quick background on neural networks, pointing out that the first research got underway in 1957. It’s taken 50 years to “democratize” ML.

Machine Learning Is Already a Reality

Today, Sara says, revolutionary changes in hardware and software are making ML accessible for any developer or data scientist. Google’s ML APIs, their AutoML technology, and Custom Models built by data scientists and ML practitioners make “Zero to ML” a reality.

Google provides pre-trained models that accomplish sophisticated tasks – including vision, video intelligence, speech, language and translation – all in the cloud and available to developers. Examples include:

  • Optical character recognition (OCR)
  • Logo detection
  • Explicit content detection
  • Landmark detection
  • Crop hints (e.g., to make your photos look prettier)

Some code was discussed with an example of calling the Vision API from Node.js, as well as how to analyze the syntax of sentences by calling the natural language (NL) API from Node.

Train the APIs Using Your Data

She discussed how to train the APIs using your own custom data with the example of a meteorologist using the Vision API. It was a really concrete yet simple example. She showed how you could train the API to recognize the weather by identifying aspects in an image such as: where the sky and clouds are, that it is daytime, and that the sky is blue. Then she talked about commercial applications developed at Disney and Urban Outfitters.

The primary ML system Sara discussed was TensorFlow. It was created by the Google Brain team, and is now available as open source. I’d heard about it but haven’t been hands-on with this technology. Sara says it is the most popular ML project on GitHub.

Deep Learning – a Subset of Machine Learning

Deep Learning is a specialized subset of machine learning that uses the approach of building multiple hierarchical layers of connections (artificial neural networks) that in some ways resemble the connections of a biological brain. Google’s tools have some rich features, and you can build your own models using them. She described how to build such models with TensorFlow, train and serve them in the cloud with GCP, and how you could utilize Python, C++ and other popular languages on the frontend.

The ideas presented were very accessible and I felt like I could go back home and start experimenting with what I learned. I plan to take what I learned here and explore further, to see if I can use Tensorflow and the Google APIs with Perforce’s ALM suite and apply this to automated testing.


Like everyone else in software, I’ve been hearing about Kotlin since Google announced their support for it in May 2017. But I didn’t know much about it, as I haven’t had good reason to research the language. I was surprised to learn that JetBrains (whom I know from their IntelliJ, Android Studio, and TeamCity products) created this language.

Here at Perforce, we have many customers in common with JetBrains, and we count them as an integration partner on several fronts with our own Helix Core VCS and Helix TeamHub systems.

Why Traditionally Java Shops Might Embrace Kotlin

Since then, I’ve looked more closely at Kotlin and realized this would be a language that many traditionally Java shops might embrace. In a nutshell, Kotlin:

  • Is a type-safe, null-safe, functional language.
  • Is highly interoperable with Java.
  • Provides C# innovations plus type inference.
  • Is the only language (other than Java) that is officially approved for the Android platform.

Colin Lee (@colinmlee) – an Android developer at Amazon – led a session called “Kotlin all the things: Multiplatform.” Check out Colin’s slides. His session provided a “guided tour” of the multiplatform capabilities of Kotlin. And he talked about what you need to know to succeed on the platforms you’re targeting.

He started by giving an overview of the code you need to write today for each platform:

  • Android: Java 6
  • iOS: Objective-C or Swift
  • Server: Java 8 Spring, NodeJS, Python, Ruby, etc.
  • Web: One of a great many JS "noun" frameworks
  • Desktop: Objective-C and C#

In Today’s World, You Write New Code for Every Platform

Without Kotlin, you duplicate every effort. You write code six or seven times, make each patch six or seven times, and add new features repeatedly. You probably implement business models and logic that have differences because of differences in the platform and language, which can result in bugs. When you look at it objectively, it sounds pretty bad.

Kotlin has many advantages, which Colin outlined. It doesn’t replace native layouts and UI with its own abstraction. Instead, it lets developers use any native library and framework for each platform.

With Kotlin, every line compiles to native bytecode, and it is highly interoperable with Java. It even includes C# innovations plus type inference. It’s all things Java developers have been missing.

Next, Colin goes on to list all the platform combinations that Kotlin can support. He talks about a variety of multiplatform project use cases, and how to implement them, including supporting iOS. He went on to talk about what kind of code could be shared across platforms, and using actual and expect declarations across platforms.

At the time of this writing, this was very new stuff and is very exciting. I strongly recommend looking at Kotlin. With Google’s strong backing and all the benefits discussed here, maybe it is a good choice for your next project! I will definitely be using it for some of my demo projects here at Perforce.


The next session I attended – titled “Re-Architecting Applications (Without a Rewrite!)” – immediately caught my eye, because I’ve done this several times in my career. Presented by Dan Lew, this session was full of good practical advice on how to approach difficult problems.

Dan doled out a considerable amount of common sense advice, including:

  • Pure architectures require fresh code.
  • Rewrites always take longer than expected.
  • Old code is battle tested (i.e., you know it works!).

Change too many things at one time and you can end up with fragility. But you have to modernize, in order to deliver value to your users.

Test Your Ideas on Small, Unimportant Projects

Dan got to the core of the presentation by talking about experimentation, and the need to pick small projects with simplified implementations to test your ideas. Always pick smaller projects that are unimportant. That way, if they crash and burn, the repercussions will be minimal, and you won’t have wasted your time and the time of others on your team on something that won’t work.

He used some great real-world examples from Trello’s mobile app to illustrate some of the concepts of a transitional architecture to get from the old to the new. One example he shared was decoupling code. For example, having the UI talk to the database, which in turn talks to the network— instead of having all the components of the code talking to one another.

Shims was another idea he raised. In this case, a “new architecture” wrapper goes around the old database, you change the UI (or create a new one) to talk to the new database, but it can still talk to the old database via the wrapper.

The Coolest Part of the Presentation

The coolest part of the presentation was when Dan talked about the journey he and his team embarked on to create an offline mode for Trello’s mobile app. (Previously, the app always had to be connected, so it couldn’t work on airplanes, etc.)

He presented several fascinating details about how Trello works, which were very cool for those of us who have been observing and using the app for years. For example, it incorporates a “card service” that “does things to cards.” In the pre-offline mode version, it was required to be available to the app via the network.

After decoupling, there were two card services: online (which behaved as before), and offline (which accessed a database on the device that held your cards). It took a few quick iterations for Dan and his team to decide how to architecture the connections.

Even if you aren’t developing mobile apps, this presentation was full of great ideas and tips from Dan’s experience. You can view Dan’s presentation.


Another great reason to attend a developer conference — hands on. Always bring your laptop to workshops! Although I’ve read a lot about Kubernetes, I hadn’t worked with it at all.

Using Docker or Doing Microservices Development? Use Kubernetes.

Clearly, if you are using Docker, doing Microservices development (or thinking about it), you should be very interested in Kubernetes. Calvin Behling, from the IT consultancy Agosto, hosted the “Kubernetes Getting Started Workshop.” It was a perfect session for an introductory hands-on experience with the technology. In about 30 minutes, I had all the pieces I needed for Kubernetes installed on my machine, including a VM with Minikube.

I spent the next hour and a half downloading tutorials and exploring the functionality, playing with YAML, and experimenting with applications. With my fellow attendees and me exchanging tips, we were assured of success as Calvin stood by to rescue us when things didn’t work. This was a totally awesome session.

Then I went to a second Kubernetes session, called “Kubernetes: Concepts and Implementation,” presented by Ryan Morlok (@rmorlok) from Contently. This was an excellent session, too – especially after doing the hands on-session. Ryan briefly discussed the availability of “productized” versions of Kubernetes on Amazon, Azure, and GCP.

You’re Familiar With Docker, But What About How It Fits With Kubernetes?

He approached the talk from the standpoint that most people in the audience are probably familiar with Docker containers, but not how Docker and Kubernetes fit together. This described my situation going in. He described the architecture and use cases, which included:

  • The definition of a Pod
  • How to create a Pod with YAML
  • A Node
  • How to create the Node
  • A ReplicaSet
  • How to create a ReplicaSet with YAML
  • How to create a Deployment

The rest of the presentation was a simple, real world example of using Kubernetes to deploy a website that incorporated a Git repo and WordPress. Updates to the website go into the Git repo, and then go live with WordPress. Ryan explained how you can do staging, and even went into detail on how to use Kubernetes for rolling website deployments.

I am really excited to put what I learned in both of these sessions to use. I’m going to set up a new demo environment for Perforce’s Helix TeamHub, our Git code hosting and collaboration environment. I realized I can use Kubernetes to manage WordPress themes and content, then just script a Git pull to bring down the code into the live site in the container!

We also added a Docker container registry in our latest release of Helix TeamHub. That means I can even use it to manage the containers I use to build this example, experiment, and learn more about Kubernetes. Sounds like the opportunity for another blog post, coming soon!

Medical Devices and IoT/Embedded

I’m always interested in anything that is IoT or embedded, and I suppose it doesn’t get more embedded than a device that is surgically implanted in a human being!

This session was titled “Modular Architecture for Big Applications and Big Teams,” and it was presented by three Medtronic developers — Phil Brown, Evan Schnell, and Chris Harman. It was especially fascinating to me because two Perforce products — version control and application lifecycle management solutions (ALM) — are used by development teams who work in regulated industries. We have an especially high use case by developers who have very high compliance bars to overcome — notably medical device manufacture.

The trio of presenters discussed some of the well-known issues of developing hardware and software products in a regulated industry. The extensive testing and record keeping required can be difficult and costly.

Perforce Helix ALM happens to be the best system to use for managing the development of such products due to its unparalleled ability to track and trace the minutiae of specifications, requirements, agile user stories, test plans, test results, changes and numerous other artifacts in a project, even over a span of several years.

I honestly didn’t know that many medical devices are configured after they are surgically implanted into the patient. The focus of this session was using Android platforms (instead of proprietary hardware platforms) to perform that configuration.

Extensive testing of each application with each implantable device model is required. This is a big effort in and of itself in all cases. And when you add functionality, scale, and extend applications, it would normally require extensive regression testing for each new supported device.

Using an MVP Approach for Medical Devices

These presenters suggest using the concept of a minimum viable product (MVP). An uninformed observer might consider that inappropriate for the medical device industry, but that’s not the case.

With MVP, you make a bare bones device that meets your user’s needs, can be manufactured relatively quickly, and then introduced into the marketplace.

Here, the presenters talked about their solution, which used MVP and Flux methodologies to create a “leak­-resistant, event­based” solution.

Flux is an architecture Facebook uses for building client-side web applications. If you visit the Flux page on Github, you will see a talk delivered by developer Jing Chen comparing Flux to Model View Controller (MVC). He discusses why MVC doesn’t scale and explains how Flux is better.

I must say, I was surprised to see that a Facebook technology was being used to support a device inside a human, keeping humans alive. But Facebook does build great software, so I guess it makes sense.

After that, they talked about the Dagger Java dependency injection framework and managing those dependency with Gradle. I can totally see how they gravitated toward this combination of Flux and Dagger. Their premise is that this architecture decouples user interface code from proprietary communication and low­level device firmware variation.

Their summary explained that the application can grow as “the team and portfolio expands without sacrificing testability, Android best practices, or user experience.” At the risk of sounding presumptuous, I bet they’ll start using Kotlin next!


After attending this conference, I am motivated to become more involved with the Google Developer Community, and I plan to start attending the meetups here in the Twin Cities. I learned a lot and look forward to DevFest next year, too. Perhaps I’ll make it to Google I/O this year. I will most certainly be applying many of the things I learned at the conference over the coming weeks and months