Archives for February 2016

Don’t space walk without a tether, get a worker

February 29, 2016 Leave a Comment

I sit here on Oscar night, wearing my “science the shit out of this” Martian t-shirt, reflecting on how often we enjoy a tense moment in a space movie where we hope that an actor doesn’t get shifted off into space.

You can’t help but gasp a little for air as you think about the awful thought of slowly moving in the wrong direction in space, without a thrust ability to change momentum and get you going anywhere but slowly to your doom.

You see it coming. “REMEMBER THE TETHER!” you cry at the screen, or you look for something that will harm said flimsy chord.

I have had a similar feeling when shipping production changes that effected cache headers. You have tested and tested, but you fear a bug that sets a cache header too far into the future, a bug that has your client without a tether. The client doesn’t think it has to phone home to see if there is a new version of the content, and you have no way to fix this after the fact. ET can’t phone home.

Service Workers give you a tether

One of the great features of service workers is how it gives you power over the full installation experience and running of the web applications in your domains. You get to aggressively cache the pieces of content that can be cached, yet you also have the browser talking back to you outside of the tab to nicely swap in new versions of the service worker that controls the lifecycle, and the cache itself. The platform gives you rich programmatic power, and tools are popping up to help make common cases simpler (e.g. sw-toolbox is battle tested in production by folks such as Flipkart).

One of the important implementation details of service workers is the lifecycle and how often the browser will look to see if a new one is available (all it takes is One Byte).

The service worker is precious. When you update it you want your users to get that update in relatively short order. But blimey, what if you somehow messed up and set a far future header on this puppy? No worries, the tether is firmly in place.

As you can read in the spec you can set a cache header if browsers are hammering you for an updated worker all the time (no need to prematurely optimize of course, this is all done out of band):

“The user agent obeys Cache-Control header’s max-age value in the network layer to determine if it should bypass the browser cache”

But, the max-age can never be more than a day (or as our APIs think of it, as 86400ms:

“If the time difference in seconds calculated by the current time minus registration’s last update check time is greater than 86400”

You get some rope, but it isn’t there to hang you, it is there to make sure your update never goes beyond a day.

Can I fix more?

This is all very empowering, and in typical fashion when you give someone an inch they want a mile. Being able to programmatically dink around with the cache directly makes me with that I could do the same for the entire browser cache.

With a service worker you have a way for the user agent to talk to some of your code that can control a particular scope, outside of the typical page loading life-cycle.

What if I could have some code that would be able to fix any other mistakes that I have made. Let me clean up some of those old cookies I forgot about, or add a tether after the fact and let me say “hey if you have /path/to/foo.html please change the caching expiration. I messed up a year ago, and it feels so good that I have a way to now fix my mistake”.

Having that special bit of code is pretty special. Being able to create a true offline first application that makes everything run as fast as possible feels very progressive, but I also can’t help feel like we have only just begun to build a model that gives me amazing control over the relationship between myself and my users agent.

Hippocratic Service Worker

You want to be careful with new tethers, so how about getting the hippocratic service worker out there on your site so you can start experimenting? Get something trivial that lets you see what is happening, lets you play with updating the service worker and your kill switch system. Then you can take ownership of the dinosaur as you get on the fast path to delivering your users a fast path.

BBC of Developer Advocacy

February 26, 2016 Leave a Comment

I think that developer relations groups should strive to be the BBC, rather than the ITV, of their worlds.

Look at the mission:

“To enrich people’s lives with programmes and services that inform, educate and entertain.”

Inform and Educate

Why does the BBC create content? The BBC isn’t in the revenue generating business, it is in the citizen enriching business. The scope is all citizens, not just 18–35 year olds, so the levels of accessibility are based on equality and not limited to a slice of society that brings in the largest wads of money.

Entertain

There is no rule that the only way to inform and educate is to make boring content. In fact, engaging content will do a much better job at helping your brain focus and generate connections.

It is also true that there is no rule that every piece of content you consume should be working to make you more productive! There is a place for downtime and pure entertainment.

If you compare the BBC in the UK and PBS in the US you see a very different brand. In my experience (having scarily spend the same amount of time in both countries) the BBC plays a much more prominent role in the culture. I enjoy PBS, but it is much more niche. You could argue various reasons for this: from content to the practicalities (the UK had a more limited supply of channels compared to the US).

If you want to reach your goals for informing and educating the populace you also need to compete for engagement time. You are competing with corporations that are responsible for growing their businesses.

On Developers

I want to inform, educate and entertain the developer community in exactly the same way. We want to enrich their lives, help them grow in their craft, and enable strong businesses.

This mission goes beyond the particular products and features and has you thinking developer-first.

Yesterday, Stripe announced Atlas, a product that is a fantastic example of thinking about what they really want to enable for people around the world. They thought much broader than “what features should we adds for payments”. Of course, this also is a growth opportunity for their business, but that is a great example of a potential win win.

Republicans, The Lottery, and Apps

February 22, 2016 Leave a Comment

Without attempting to be too political, I have always been a touch confused at the working class folk who are strong supporters of the current Republican ideology. It seems pretty clear that the fiscal policy favors the rich, as is evidenced by the current discussion on income inequality (although you can argue that the democrats don’t also shoulder the blame!).

A simple view could be one of:

a) “I hate taxes. The government wastes that money so I shouldn’t have to give them anything to waste!”

b) “One day the American Dream ™ will come my way, and then it will be in my favor!”

I won’t bother to discuss a), although I am a fan of the fact that we have shared infrastructure. The attitude shared in b) is the one that relates to the rest of this discussion.

It also ties into the lottery system, and how we manage to fund programs by using the law of large numbers. If you get a lot of people to pay a couple bucks that adds up big with enough of a population but in theory doesn’t have a large effect on them. Huh, that isn’t all bad. What if we took the change from every purchase and also donated it. That scale could do so much good! However, isn’t that what taxes is for? Isn’t that what people seem to hate so much? What have taxes ever done for me!!!! (Other than pave society?)

The lottery sells hope. It is actually the lack of the american dream that paradoxically calls to many. Deep down you know that you are fighting an uphill battle to earn these riches, so you reach for luck instead. It is easy to poke fun and say that the lottery is a tax for those who are bad at Math, but it isn’t our place to judge. When you plan a vacation, you often get more joy from the build up and anticipation, so maybe some of this helps here.

Bring in the Apps

Building an app, getting it into the app store, and hoping for the customers to come raining in sure feels like a lottery these days doesn’t it? When a new platform comes along there is the rush to the gold. You can often create something new and get lucky, or you can copy history and make money selling tools and infrastructure to the miners.

At this point there is already an app for that, and if there isn’t you need to fight for mindshare in a store with masses of choices.

When creating your lovely application it sits proudly on your homescreen. This is where you envision it on a large number of users phones. This is the pride of place for the applications that need repeat engagement and access. Does your application really warrant that?

I was working with a friend who has a fantastic new group event service. It was a great example of something that it useful, but an app may not be needed. The event organizer may want the access and the rich functionality. The group they run may be an important part of their lives. But for the other members of the group? It may not be as important.

That doesn’t mean that they wouldn’t want to get notified when something important changed for their group. It doesn’t mean that if they enter the experience it should only be able to tell them basic info if they have a good internet connection.

This is why I am excited for progressive web apps. I picture a world where this application can get a broad reach and also get the engagement capabilities it needs.

You always need some luck when you come up with a new business or service. To give yourself a chance for it to grow and flourish it may be wise to not have to hit the homerun of the homescreen. Allow your business to work through frictionless links, A/B test without large delays, and don’t waste time and resource porting an experience multiple times.