Why isn't this a library?What heuristics do you use to decide when to build (or extract) a service versus building (or extracting) a library?

How do you plan to deploy your microservices?What is your deployable unit?Will you be deploying each microservice in isolation or deploying the set of microservices needed to implement some business functionality?Are you capable of deploying different instances (where an instance may represent multiple processes on multiple machines) of the same microservice with different configurations?

Is it acceptable for another team to take your code and spin up another instance of your microservice?Can team A use team B's microservice or are they only used within rather than between teams?Do you have consumer contacts for your microservices or is it the consumer's responsibility to keep up with the changes to your API?

Is each microservice a snowflake or are there common conventions?How are these conventions enforced?How are these conventions documented?What's involved in supporting these conventions?Are there common libraries that help with supporting these conventions?

How do you plan to monitor your microservices?How do you plan to trace the interactions between different microservices in a production environment?

What constitutes a production-ready microservice in your environment?What does the smallest possible deployable microservice look like in your environment?

The start of the year is a good time to be thinking about the end of the year and the kind of world I would like to see. Usually this leads to resolutions and predictions. Unfortunately I find most predictions worthless since the pundits seldom go back to check on their previous predictions. The other problem is that people start out making predictions and then the articles turn into wishlists. That's why this year I'm just going to write a wishlist.

Wikipedia starting to use identity technology to improve the user experience. For example if I donate or become a member then I'd like to stop seeing obnoxious adverts (and they really are adverts) asking for money. The Guardian's membership programme is a good model that Wikipedia should adopt.

a viable successor to the Leica M9. The Leica M Type 240 just isn't a big enough improvement.

a viable replacement for Aperture. I have zero faith in the upcoming Apple Photos app and there isn't enough official support for migrating from Aperture to Lightroom.

a viable replacement for the old Mac Pro. The new Mac Pro abandons all of the strengths of the old Mac Pro.

less hype/advocacy for microservices and more documentation/descriptions of techniques that work with collections of small services. You'll be able to tell if you're seeing hype by the number of awkward questions that they raise.

Firstly these apps are special because they can use every sensor and transmitter on your mobile phone. That means they will also be the first to get access to new sensors and transmitters as they are added to these devices. This gives them more power than any other apps that have ever existed.

Secondly these apps are special because they're installed in a device that the user will carry around all day every day. That means that they will see more usage per user since there will be so many more opportunities to use them. It may even be time to start measuring average usage per user (AUPU) as a more quantitative version of Larry Page's 'toothbrush test.'

Finally these apps are special because they're on devices that will eventually end up in the hands of every post-pubescent person on the planet. That means they will eventually end up with more users than anything we've seen so far.

I meet a lot of people in my job. Consequently I get to see lots of different companies trying to create the best possible Android sharing experience. Just about all of them start off with the standard sharing system based on intents and the standard chooser dialog.

It's compatible with just about all devices but it gives users an alphabetical list of applications even though many of these may not make sense in the given context. For example the list below shows the stock Email app even though I'm a Gmail user who has never configured the other email app on my tablet. This dialog also has issues for users who install lots of apps and its alphabetical ordering means we're starting to see developers gaming the system in order to be at the top of the list.There's also the problem that the intents system doesn't let you customise the recipient other than by passing in a set of key-value pairs so developers (like The Guardian and Soundwave) offer an explicit Google+ share button in the action bar for users who are signed-in with Google+. This gives their users direct access to interactive posts. They also offer the standard chooser dialog as well.

The Gallery and Keep apps try to remember the last N apps the user has shared and present them to the user by using the ShareActionProvider added in Ice Cream Sandwich. Shazam's implementation is built on the same idea but does something slightly more sophisticated with it. It shows a list of the apps I've recently shared content to but adds various social services to the top of the list. It also knows which social service I signed-in with and adds it to the action bar as a separate button. The assumption is that I'm more likely to want to share newly discovered music to that social network than with the random assortment of apps on my device.

Snapette and Fancy implement simpler variants on the same idea. They hardcode a small set of social services (including Google+, Twitter and Facebook) even if they're not installed on the user's device. Clicking on those options takes users to a sign-in dialog before they can share. In their defence Fancy does offer a 'More' button that goes to the standard chooser dialog. This offers an escape hatch for users who want to share to contexts other than social networks.

If the screen is large enough then you should have your preferred share option in the action bar next to a button that launches a custom share list that shows your preferred apps with a More button that sends the user to the standard share dialog. This pushes users towards the developer's preferred networks (these could be the app's network or the services that the user has used to sign-in) but still gives users a way to get to all of apps they've installed.

On smaller screens you should have a share button that sends the user to a custom list containing the developer's preferred networks with a More button that sends users to the standard chooser dialog.

This approach balances simplicity of implementation, predictability (users shouldn't have to wonder why options are appearing and disappearing from their chooser dialog), extensibility, value to the developer and responsiveness to device size. This may seem complicated but fortunately a large amount of this can be implemented using the ShareActionProvider and its support for fine-grained tracking of history.

This is a complex and subtle topic with many different approaches being explored by lots of very smart people. I'm not going to pretend that this blog post is the final answer. After all, there's always the option of building something completely specific to your needs.

I strongly recommend reading it. Or at least skimming it since the social login market is bigger and more complicated than it seems. The following is merely a high-level restatement of the migration guide for people who aren't really sure which of the aforementioned technologies they're using.

If your existing system captures the user's email address using a Google identity solution then you can just:

associate them with the existing record that matches that email address since Google guarantees that the email addresses are valid

If your existing system doesn't capture the user's email address then life gets interesting.

If you're sure you're using OAuth1+OpenID2 then you can follow the instructions here: https://developers.google.com/+/api/auth-migration#oid2 which tell you how to fetch your old identifier and find out the equivalent identifier with Google+ Sign. Once that's done you can just associate the new identifier with the existing record and the user can sign-in in future with Google+ Sign-in.

If you're using something else then you can ask the user to sign-in twice: firstly with your existing Google identity solution then with Google+ Sign-in. Now that you have both identities you can associate them in your database. Once a critical mass of your users have gone through this process then you can stop using the legacy identity solution. If you have to use this option then I would also recommend reading Michael Mahemoff's experience report from Player.fm's migration: http://softwareas.com/migrating-user-accounts-from-google-openid-to-google-oauth-to-google-plus since I got the idea from him.

Through historical accident, television has come to be seen as the first screen with our mobile devices as the second screen. This implies a mental model that's usually driven by television people who really mean that television is the primary screen whilst all others are merely secondary screens. When these devices are viewed from the perspective of the programme makers that is correct. But things change if we look at them from the perspective of the user.

The first screen is the one in your pocket. All others are secondary.— Adewale Oshineye (@ade_oshineye) May 26, 2013

When we look at usage it becomes clear that mobile devices (currently just phones and tablets) are the primary screen whilst television and desktop computers are the secondary screens.

The mobile (phone) screen is the most personal screen. It tends to belong to one person who carries it everywhere and seldom shares it. That person will customise it with a combination of apps and bookmarks that's practically a fingerprint.

The tablet is large enough to be viewed by multiple people and is often shared within a family. As such it accumulates layers of choices from all the people who have used it. However it still tends to feel like a device that belongs to a small set of people. Whilst both of these devices empower people by giving them control over usage and content, the television is different.

Whilst it may belong to one or many you're never allowed to forget that the content on your television is decided by other people. They decide what you can watch and when you can watch it. As for customisation…forget it.

The final step is to realise that we shouldn't be thinking about a fixed number of screens. We're facing a multi-screen future. That means there are going to be N categories of M screens in your life. And the values of N and M will only increase over time.

This is not a problem we will solve by building responsive websites with a fixed number of breakpoints. This is not a even problem we will solve by pouring the same content into a fixed number of buckets or screen sizes.

This is a Cambrian Explosion of contexts, interactions between contexts and user journeys across contexts. Time to adapt.

Valuable accounts. Are the accounts attached to real people who have been SMS verified? Does the IDP fight off attempts to create fake and spammy accounts?

Security. Are the accounts stored using salting and hashing? Do users authenticate using multiple factors? Are precautions being taken to ensure that user accounts are protected?

Rich profiles. Does the IDP offer data that you can use to personalise your service such as profile data, photos and social/interest graphs?

Ubiquitous APIs. Does the IDP offer ReSTful APIs, native SDKs, client libraries in various languages and support for RTL languages?

Escape hatches. Does the IDP lock-in RPs and/or users? Can the RP obtain the user's verified email address so that the user has the option of using a different IDP with the same RP account? Is the RP forced to build their own post-registration flow?

Business model. Does the IDP make money or otherwise benefit from providing this service? Do they have a compelling incentive to stay in this business?

The final and most controversial ingredient is scale. Most people would say that all other things being equal an IDP with more accounts is better than an IDP with fewer accounts. I'd suggest that it's better to have accounts that are appropriate to the service the RP is trying to provide. For instance for Statigram the best IDP is Instagram but for Favstar.fm the best IDP is Twitter and, of course, for any service that uses Google services (like Youtube, Android, Drive, etc) the best IDP is Google+.

The items listed above are just the necessary but not sufficient features of a viable IDP. Successful IDPs will still have to identify and provide additional value in order to get widespread adoption by users and RPs.

They worry that showing a large set of buttons will hurt conversion rates (because of the paradox of choice) and confuse users who don't remember which IDP (identity provider) they used on a particular site+device combination.

I don't think that's a big problem nowadays.

That's because we're down to a fairly small set of viable identity providers (henceforth known as IDPs). Most of the others are either dead(MyOpenId), new (Amazon Login) or only useful in specific niches (GitHub, Instagram, Tumblr, LinkedIn etc).

If we look at Stack Overflow's data we see that 5 IDPs are used by 98.6% of visitors but everybody has to deal with the cognitive load of choosing between the 12 buttons and 1 form field.

Reducing the set of buttons to 3 would still give users a choice whilst reducing cognitive load. By cutting down to just these 3 IDPs they'd have covered the vast majority (in Stack Overflow's case 92.02%) of potential users of their site and greatly simplified the experience.

However if you prioritise providing access for 100% of your users over providing the best possible experience for the majority then you have several alternative strategies available to you:

create your own username/password system (but then you have the responsibility of building a first-class security system)

However there's still the situation where a user prefers different IDPs on different machines: for instance if they work in a company that blocks Facebook at the firewall or they prefer Google+ on Android but Facebook on iOS. For those users a naive NASCAR implementation leaves them with one account on your service per IDP.

The easiest solution to is to ask for the user's email address and use that to correlate all the accounts they use to login to your service. That way the user never has to worry about creating duplicate accounts. Of course this does restrict you to IDPs who can offer a verified email address.

The only IDP this excludes is Twitter. If you are using Twitter as an IDP then you'll have to either capture (and verify) the user's email address in a post-registration step.

Sometimes you have to do things the hard way. Usually it's because you have large numbers of accounts with unverified email addresses (for instance if you used a standard OpenID IDP or used Twitter without capturing and verifying email addresses) or you're migrating users from one IDP to another.

In that case you have to provide a 'connect flow.' This is where the user signs-in to your service with one IDP and you ask them to 'connect' with additional IDPs. Afterwards you know that the same person owns that set of accounts even if they have different email addresses associated with them.

The heuristics above mean that the NASCAR anti-pattern doesn't have to harm conversion rates or UX.

If you'd like to learn more about this stuff I'll be attending Over The Air 2013 where I'll be walking people through examples of these heuristics in production and talking about the multi-device multi-platform post-NASCAR future of identity. Join me.

Should your blog have comments? That's one of the perennial questions that every blogger faces. Are comments a way to bring in vital feedback from the-people-formerly-known-as-the-audience or are they merely a mechanism for enabling strangers to spew hatred and bile on a page with your name attached?

Historically my position has been "comments are bad, run away." My reasons included:

I really don't want to deal with spam. The only thing worse than having spam on your blog is using moderation systems that mean I have to read every spammy comment in order for you to get a better experience. I like you but I don't like you that much.

BuzzGoogle+ is a better conversational network than my blog. Every post on my blog ends up on my blog's Google+ Page as well.

BuzzGoogle+ also has the advantage that there can be multiple conversations by completely disjoint communities about the same blog post.

- BuzzGoogle+ emphasises Real Namesand Serial Identity. This means I can look at people's activity stream to see what they've been posting about, commenting upon and sharing. Of course, just because you're using your real name doesn't mean that you won't say or do things that I find objectionable but which your community finds laudable.

I think it's a terrible idea to put everybody who has an opinion on a topic into the same room. That invariably leads to name-calling because they have so little common ground or shared vocabulary. For every person who understands the topic and wants to discuss nuances there'll be 10 people who would like a clearer explanation of the fundamentals.

All of the above are good and sound reasons for disabling comments. So why have I just enabled comments on this blog?

The main reason is that I have new technology and I want to see if, just this once, technology can solve a social problem. The secondary reason is that I'm interested in aggregating the conversations around my blog posts. My hope is that this aggregation will help me discover people who are saying interesting and insightful things about what I've written.