This is as much an aide-mémoire for myself as anything else, but in case you’re using the Objective-C Google API client, you may at some point need to use the simple API access method. This is where you pass an API key to identify the call as being under a certain project, rater than using a full OAuth2 authentication flow. This doesn’t allow access to personal data, but does mean that any calls will be tracked under the quota for your project, rather than a (lower) IP based quota.

One pretty common request around Google+ hangouts is the ability to programmatically schedule them, and have a URL which everyone can join in the future. This is useful for being able to send out links beforehand, and make sure people are ready to go.

At Devoxx the other week I spoke about Clojure, and as an example looked at how it could be used to access the Google+ public data API. Because the Google+ APIs are part of the general Google APIs Discovery Service we looked at how to process and generate functions to call this library automatically (more on which in later blog posts). However, for use now the easiest way to access any Google API via Clojure is probably via the Java client libraries using the Java interop in Clojure.

I was reminded of one of my pet social peeves as part of a conversation with one of the, astonishingly smart, Google interns. One of the most challenging aspects of social networks is that, broadly, people within companies don’t really know what “doing a good job” looks like. Depending on the organisation, social media can be part of marketing, PR, customer service, a specialised department, even IT. The aim of these departments is often mis-matched with the potential or the audience the brand has across their social media, so it is difficult to create effective performance measures.

It’s pretty straightforward to use synchronous encryption over ZeroMQ - just a case of encrypting and decrypting at each end with some previously shared key. Asynchronous encryption is a bit more interesting, as it allows signing for message integrity and authenticity, as well as data hiding. There have been some good examples of crypto over Pub/Sub (notably Salt), but not a lot of examples of direct messaging.

Had a question earlier about whether it was possible to retrieve comments from an event on Google+, and the answer is yes! As long as it’s public, you can grab it via the REST public data APIs.

The History functionality in Google+ is an interesting answer to a pretty common question of “where’s the write API?” It allows creating moments in a user’s (private) history, which can then be reshared. It’s currently in developer preview, for the express purpose of getting feedback on the API. 

It has been a long time since I touched any IOS code, so I was quite looking forward to a chance to do some when the IOS team within Google+ released the SDK into preview at Google I/O last month. Luckily, the documentation on the SDK page on developers.google.com is excellent, and covers the basics of the setup, but in part because I’ve forgotten almost everything about XCode and IOS, I thought it best to just write down what I did and what I encountered, primarily as an Aide-mémoire for the future. Anyone building a new app should follow the documentation - but perhaps some developers will hit an issue I did and get something out of this post!

In one of his talks at QCon, John Allspaw mentioned using Holt-Winter exponential smoothing on various monitoring instances. Wikipedia has a good entry on the subject, of course, but the basic idea is to take a noisy/spikey time series and smooth it out, so that unexpected changes will stand out even more. That’s often initially done by taking a moving average, so say averaging the last 7 days of data and using that as the current day’s value. More complicated schemes weight that average, so that the older data contributes less.