Risk Complete Failure

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. Most well managed teams create measurable goals - increase X number by Y percent and so on. However, when you chuck something as mutable as social systems into the balance it is difficult to avoid putting in numbers that qualify as vanity metrics , rather than useful data. Vanity metrics is a term from the world of lean start-ups, and refers to numbers that people quote because it makes t

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. The de-facto library for this sort of work is OpenSSL, but this has a couple of problems. The first is that usually openssl manages the TCP connection itself, which could be an option for some ZeroMQ cases, but doesn't fit if the user wanted to use a different transport, or an unusual topology. TLS or SSL also require a handshake at the start of the communication, which means we may have to send messages back and forth without there being any application data.   For the first part, OpenSSL includes support for usage as a filter thanks to it's BIO IO abstraction