Videos from first Node.js meetup in Dublin

Thanks to Cian O’Maidin, the videos from the first Node.js meetup in Dublin are available!

A couple of weeks ago, we presented a short (~15m) talk about how we use Node.js to render Javascript charts to SVG and PNG images.

At this event, we announced three things:

Watch the video for some details on how and why we run Highcharts server-side under Node.js, what we liked/didn’t like about Node, and for the open sourcing announcement.

Sorry about the poor audio – hopefully we’ll have a better recording setup for the next event.

In case you’re wondering, yes, that is our Big Red Button being used as a slide advancing tool. :D

Building the Big Red Button

Metricfire's Big Red ButtonEveryone loves our giant red button. We’ve used it at three events so far – a Dublin Beta startup demo evening, our PyCon 2012 booth, and most recently as the most awesome slide advancing controller ever at the first Node.js meetup in Dublin.

We get a lot of questions about how we made it and how it talks to the computer. It’s about time we did a little show and tell, with lots of pictures and code!

Image from - go buy one of their buttons!

The main element, the actual button, is one of SparkFun’s “Big Dome Push Button” units. Two of these have been sitting in Charlie’s electronics parts boxes for a year or so, waiting for just the right project.

Inside the button


PCB from a small USB numeric keypad

The second major component is deceptively simple and cheap – the PCB from a small USB numeric keypad. Modern membrane keyboards have a row of contacts that mate with the flexible plastic sheets with conductive traces that form the key contact points.

After some trial and error with a piece of wire, you can identify the pair of contacts that correspond to any key on the keyboard. If you solder those up to a big push-to-make switch, you’re basically done. A press of the big button will cause the controller board to send a USB keyboard event to the OS.


1W white LED on a custom mount

A little poking around with a multimeter will find you a good point on the PCB to pull 5v to power the light inside the button. Though SparkFun now sell a version with an LED, our one used an older incandescent bulb, which requires 12v and would probably draw more power than the keyboard controller was designed for. Charlie built a suitably shonky mount for a 1W white LED and it replaced the incandescent bulb.




Vinyl sticker inside the button

How’d we get our logo in there? We had some spare vinyl stickers for the backs of our macbooks, and one just happened to fit perfectly inside the button. If you need excellent decals/stickers, talk to Jeff and Neece of SmartDecals and tell them Metricfire sent you!

After that, the easy bit was making a wooden case for the whole thing. A grotty concrete-encrusted wooden plank turned out to make a solid enclosure, once it was cleaned up a bit!



Where’s the code?

As promised, there’s some code involved here. Sometimes, having the button appear to the OS as a regular HID keyboard is undesirable. When we’re demoing our (almost) real-time graphs and dashboards at events like Dublin Beta and PyCon, we don’t want button presses to be interpreted by the browser running the demo. We need something a little deeper catching those button presses so we can generate metric events.

For this, we use Python, libusb, and some hardcoded magic numbers. The code:

So there you go. If you’d like a Big Red Button of your own, you have complete instructions and sample code. Quick, to the workshop!

Replacing SmokePing with a very small shell script

For a while, I ran a small IRC bot for keeping the members of a local hackerspace informed about when the space is open for visitors. This bot needed to check a status page every minute or so.

The problem was that for a few days there were regular connection problems. The server running the bot couldn’t connect to the server hosting the status page. The error messages weren’t helpful – just connect() timeouts. To try to better understand the intermittent problem, I wanted to measure the latency and connectivity between these hosts on an ongoing basis.

The natural choice for long term latency measurement is, of course, SmokePing.

The only trouble is the amount of effort involved in installing SmokePing, configuring it, configuring a httpd to serve the content and run a Perl CGI, keep the content private, etc. None of that is hard, but it is certainly annoying and I was not interested. I wanted to measure latency between two machines, not spend a good half hour, if lucky, setting up all that.

So I used Metricfire instead. I wrote a one line snippet of shell script to make 20 ICMP ping requests, format the latency results, and send it to Metricfire’s HTTP API.

I handed that off to cron to run once a minute, and now you can see the complete recipe:

* * * * * curl -s\
etric/smokecheap/tog-dot-ie --data-binary "[$(ping -c 20 | awk \
'/bytes from/{print $8}' | cut -b6-10 | xargs | tr ' ' ',')]"

After a little clicking around, I had a graph of the min/avg/max latency between these two machines.

The whole thing took less than five minutes. It’s obviously not as complete as SmokePing, but it gave me the result I wanted with a fraction of the effort. 80% of the functionality with much less work. I’m pretty satisfied with that.

The twist to the story is that the intermittent connectivity problem disappeared before I got a chance to observe it! Definitely glad I didn’t set up SmokePing just for this. If it happens again I’ll be ready with this historical data to help me spot patterns.

- Charlie

Playing with competition data from SparkFun’s Free Day

Yesterday, SparkFun Electronics had their annual Free Day, where this year they gave away $200,000 in credit to their customers just because they felt like it.

The Metricfire founders are big fans of SparkFun, we both love electronics and tinkering. One of my desks is covered in microcontrollers and other components. When I’m not working on Metricfire, I’m soldering! (Or ordering parts from SparkFun…)

This year, people entered the competition to win a $100 credit by repeatedly solving captchas to prove their humanity. The competition was set to run for several hours. Several hours solving captchas? That sucks. A lot of people are going to get bored after a few minutes and wander away, but many will come back. If I don’t want to spend several hours solving infuriating captchas, can I figure out the best time for me to compete?

Wait... this is to prove I'm *not* a robot?

The answer is yes, we can work it out! SparkFun published some live statistics about the number of winning and losing attempts using Pachube. This is cool, but I didn’t find the graphs very useful. Here’s what it looked like:

That’s cool, but not very useful. It’s vanity data, and not even very pretty. We can do better and pull some meaning out it. I set about scraping this data from Pachube and getting it into Metricfire where I can better work with it.

After some quick tinkering in Python and applying some data transformations in Metricfire here’s what I ended up with:

Much better. Now can I see some trends in that data. Most importantly, I had a graph of how tough the competition was as people entered/left:

I used this graph to figure out when I should invest a few minutes in solving captchas. It looks like the best chance of winning was almost 0.06%, about five and a half hours into the competition. Watching this graph change as the day went on was fascinating – a little like watching a stock market graph.

I didn’t win anything from Free Day this year, but I had a lot of fun crunching the numbers during the event. Metricfire was a big help with that – once I decided I wanted a graph of something, it was only a couple of lines of code to get my data into the service and on a graph. This is why Metricfire exists.

- Charlie