Running a developer product or a developer relations team means making trade-offs about where to invest time, money, or focus. Being able to attach values to developers can make conversations easier across different business functions, and allow more direct apples to apples comparisons of things like the potential value of activities.

Developer services are an umbrella term for any kind of pay-per-usage developer product, usually provided as a hosted service. The majority of AWS, Google Cloud and Azure services fall into this bucket, as do numerous others. It is a relatively simple model, pay for what you use, but it has a host of challenges to building a great, sustainable business.

In this post, developer platforms means multi-sided markets where one of the sides consists of software developers. Platform businesses are immensely powerful drivers of the modern tech landscape— pretty much every notable tech company has at least some aspect of a platform business in their DNA.

Thinking about developer products means thinking about developers. What is different about software development as compared to other professions or interest groups? In particular, what needs to be considered when building tools and services for developers?

DevRel, developer advocacy or developer evangelism teams are a part of almost every recent developer-services success. Many DevRel people are hired for their functional responsibilities (we need someone to do X), rather than how they fit into the business.

Serverless, with all the attendant ambiguity on what that means, tends to be discussed from the perspective of people who build services. This often leads to a focus on the differences between serverless and previous generations of infrastructure. Specifically, we talk about how the provisioning, balancing and so on have been made utility, as compute, storage, hardware and bandwidth had been in previous generations of technology.

Back in the dark ages I wrote a blog post on using Google Sign In to authorize a server from an Android client, and provided an accompanying gist with an example Activity in it. Recently, someone point out to me that gist was quite out of date, so I updated it to use the latest and greatest Google Sign In APIs on Android, with very pleasant results.

Very quick post on a problem I’ve seen a few people hit where they are upgrading a Firebase.com project which uses Google Sign In on Android.

The very first message sent over the precursor to the Internet was a log in attempt. Unfortunately, the system crashed part though, so the very first try was just “LO”. Since then, the explosion of networked systems has lead to an explosion systems to log in to.

The new Google Sign In SDK for iOS is out! With a new version number, and separated from the old Google+ SDK, the Sign-In SDK should make it easier and faster to implement Google Sign-In in your app. Lets take a look at how to use it from Swift.