Risk Complete Failure

One of the nice things about working in developer relations is I get exposed to an awful lot of code written by an awful lot of different people, which means I regularly encounter techniques I haven't seen before. I wanted to quickly post on one that is possibly very familiar to iOS developers, but that I only saw recently - though I have to say that for readability's sake I would recommend some good commenting if you do decide to use it!The code came from an iOS codelab for the excellent Google Play Games service, written by the mighty Kerp. The code was a header file doing something pretty normal: defining a list of constants for use in game. What was a little unusual in that it had the values both declared and defined in the header, and that there seemed to be some business with macros occurring.This took me a little bit of parsing! In general the normal way of defining these sorts of constants in Objective-C is to have an extern'd definition in the header file, and the…

In a previous post I talked about some of the ideas that drove QUIC, but in this one I want to got a little more into how it actually works to get data from host to host. Again this is all from the notes I made looking through the source and spec - so always go to the code for the latest!All networking is constructed as a series of layers - each layer defining its own mechanisms for reliability, name resolution and other fundamentals. Though QUIC is a single protocol, the layering is still present within it - an individual piece of app data (say a HTML page) will be encapsulated with several different layers of framing: the stream frame, the QUIC session, and a cryptographic channel.This means any given QUIC packet can be peeled back. For example, a regular packet containing part of a web connection might look like: [[CRYPO HEADER] [ENCRYPTED DATA: [QUIC HEADER [STREAM FRAME HEADER [THE STUFF YOU ACTUALLY WANT]]]]]. While this looks like a lot of overhead, there are a few tricks that …

Had a couple of questions recently about Google+ Sign-In in different languages. While its rather common to want to use custom graphics instead of the supplied sign-in button, one of the nice benefits of using the supplied buttons on Android, iOS and the web is that they automatically adapt to the language of the user. Pretty much this post could end there, but there are a few interesting edge cases that are worth mentioning.JavascriptOn the web the Javascript Google+ buttons will attempt to choose the language based on the browser settings. This should be (mostly) fine, but if you have a specific user setting for language you can output some configuration to force the language for all buttons (including the sign-in, +1 and so on).These kind of global parameters are generally configured in the ___gfg property of the window, which the Google Javascript API checks when it loads. You'll need to put the following before (or in the same script tag where you load the Javascript:Which lo…