Wednesday, 21 August 2013

The Java Hammer and Learning Functional Programming

Ribbing other developers about their programming language of choice is all part of the culture.  I nearly succumbed myself today.

The obvious joke being surely if you debug PHP you just end up with Perl6.  Usually just a bit of a larf, but often dismissive humor is a quick way to avoid having to understand and learn something new.  Occasionally, as in the case of the PHP Hammer, things can go perhaps a little to far.

This is my hammer:

I made it when I used to big wall climb a lot.  Where I learnt to climb you couldn't walk into the local climbing store and buy a hammer so I made one (along with a lot of my other gear).  I bought a geologist's hammer, cut part of the pick off, ground in a notch for pulling pitons and drilled a hole for attaching a funkness for ripping out stubborn pitons and busted bolts.  It worked really well and I helped a couple of friends make their own hammers.

I don't big wall climb any more but I hung onto the hammer.  I still use it when I work around the house or garden and it works just fine to whack in nails.  The handle is a bit longer and the head is heavier than a typical framing hammer so you can really punch a nail home with it.  Of course because it's heavier my feeble geek arms get tired quicker than they might with a smaller hammer.  If I help a friend out on a project they always take the time to make fun of my hammer.  However, it's when I need to pull a nail out that the real problems start.  I can't just flip this hammer over and use the claws on the back, I have to resort to this tool:

Which is fine until the nails get large and then I have to break out Fat Max:

Somehow I've ended up with three tools to do the job of one.

I could go get a new hammer that's more appropriate for the job, but when I just need to put in a few nails I never bother making the trip to the hardware store.  I'd have to wade through shiny nail guns and battery powered impact drivers just to get one simple tool to do a straight forward job, so I stick with what I've got.

I realised today that this is exactly how I feel about Java.  This is the Java Hammer; not always the right tool but I reach for it because it's familiar.

Like most people who have been programming for a while I'm truly proficient (be honest) in a small number of languages, can muddle my way through in a few more, and I've written hello world in more languages than I can remember.  I haven't properly learnt a new language every year because it often ends up being relearning object oriented programming with different syntax.

Lately I've become interested in functional programming, particularly Scala.  I can see that it will suit a lot of the programming problems that I have.  What really interests me is the paradigm shift to functional programming.  The trouble is, it's hard to break the habit of the familiar especially when there is work to be done.  I've been to presentations and tutorials about Scala and functional programming and the most useful for me was this one by Dianne Marsh.  Dianne's talk helped steer me off the inevitable path of being a functional fascist: behaviour that would make adoption at work difficult.  Instead, she suggested ways to start using Scala in daily coding, beginning with non production code like tests and simple scripts and building out from there.  Also, Dianne encouraged me to start out using Scala in an object oriented way, and to worry about writing functional code later. Sound advice for making a daunting change!

When the world stops shaking or erupting and I have the energy to look at a computer in the evenings, I'm going to finish working my way through Atomic Scala by Dianne Marsh and Bruce Eckel.  It's really great and I'm pretty sure that if I stick at it that one day I will be able to look at some code and realise that I can write in a truly functional style.  It will be a nice break from the Java Hammer.

Footnote: This blog is about me learning something new that suits the programming problems I have.  Don't bother flaming, trolling, extolling the virtues of your favorite language, or any of that other pointless behavior.  I won't be listening.  Put your energy into learning something new yourself.

Disclaimer: I have never coded in PHP and have no opinions about it.  I do notice that it's used for a lot of things on the web so it must be good for getting stuff done.

Tuesday, 30 July 2013

Notifying You

The GeoNet Project provides a range of ways that you can stay up to date with geohazards information for New Zealand.  This includes smart phone applications that provide near real time earthquake push notifications for both Android and iOS devices.  I've worked with the internet for a long time but some days it still amazes me - receiving an earthquake notification on a phone in my pocket within moments of an earthquake occurring is one of those times.  It's both disarmingly simple and complex at the same time.  Here's how we get the earthquake location to the phone in your hand.

Getting push notifications to your phone involves services in several countries.  The numbered steps are described below.

1. The Application on Your Phone

To receive near real time push notifications you have to have the GeoNet app for Android or iOS installed on your phone, it has to be connected to the internet, and you have to have your quake preferences set appropriately.

2. Pushing to the Phone

We don't connect to your phone directly to send the push notifications, Apple or Google do this for us via either the Apple Push Notification Service or Google Cloud Messaging. When it's on the internet (and you've given it permission) your phone maintains a connection to the Apple or Google servers and receives push notification messages over that connection.    When your phone isn't connected those servers store messages to send to your phone next time it connects to the internet.  Using these services also allow the application on the phone to receive messages even when it's in the background.

We use Urban Airship to send push notifications to the Apple and Google messaging services.  Urban Airship give us a single API to send messages to and do all the hard work of maintaining the connection to the Apple and Google service as well as staying up to date with any changes to those services.  Urban Airship also provide some handy reporting tools for us.

3. Managing Your Preferences

We run a back end application to store your quake notification preferences.  When a quake message is received the preferences are used to decide which phones should be notified about this quake and a push message is sent to Urban Airship.  We run the back end application in AWS Elastic Beanstalk in the Sydney region.  This gives us very easy deployment, high availability, and easy scaling as demand increases (like it did after the recent earthquakes).

4. Locating the Quake

This is done by GeoNet Rapid, automatically in near real time and reviewed by the duty officer as required.  It's using all that great data coming from the remote seismic sensor network.

The Internet is Amazing!

When the notification arrives on my phone it has started from a message about an earthquake location in New Zealand, been sent to Sydney, forwarded onto America, and sent back to my phone in New Zealand.  This all happens within moments of the earthquake occurring.  A journey of over 25,000 km passing through several cloud services.  This might not be magic but every time it happens it seems pretty close to it to me.

Friday, 19 July 2013

Earthquake Stats: Magnitude 5.7, Friday, July 19 2013 at 9:06:39 am

This morning's earthquake shook a good bit of the country including myself. We have so far collected 6167, 6219, 6556 Felt Reports - thanks to all who have submitted them.  We've been using a couple of new things to monitor the web site and this has been their first real work out. Here's what we saw.

Real User Monitoring with Pingdom

We're using Pingdom for Real User Monitoring (RUM).  This lets us find out how the web site performs from your point of view, in the browser.  As I've written before we spend a lot of time on web site optimization and RUM with Pingdom gives a window into the results of that (and nothing else, we're not tracking you here, just web site performance).  RUM is a big improvement over what we used to do (post processing server logs with awstats) because we get to see page loads and how long they take in the browser in real time instead of just requests per second.  Here's what it looked like for this morning:

The top graph shows page load time in the browser.  The darker blue line is today, overlaid on yesterday (the lighter grey line).  The median page load time over this time period is 0.67s.  Fast!  The graph below this shows the number of page views in 5 minute windows.  The traffic goes from the usual low background to 44,480 views in 5 minutes very very quickly.  Below the graphs is a map showing page load time by country.  What's really nice is when the traffic hits the page load time doesn't go up - in fact it goes down a little, probably due to improved caching.

We also use Pingdom for uptime monitoring on our web servers.

Application Server Monitoring for Felt Reports

The application that collects Felt Reports got overloaded for a little while.  Thanks for your patience in submitting them.  To monitor the application server that hosts Felt we use two tools.  The first is Jolokia  which provides a JMX-HTTP bridge.  If you've ever worked with JMX and the inevitable firewall issues you will know what I mean when I say that Jolokia is breath of fresh air for JVM monitoring.  With Jolokia in place it is easy to write a script to query for JVM metrics.  We send the metrics to  Librato Metrics to store and visualize them.  Libarto Metrics provides a fantastic online tool for visualizing any time series data you care to send them.  What's more, for the 100 or so metrics we send at the moment it's costing about $7 per month - a total bargain.  Here's what we saw this morning:

In the graph Tomcat JK-8009 we see that the Felt app couldn't create more threads to serve additional requests for about 8 minutes.  Everything else was fine.  We'd like to never see this happen but it's a difficult situation to improve.  Eight minutes is to short a time to to spin up additional capacity quickly enough to make a big difference and we can't justify the cost of having extra capacity sitting around doing nothing for most of the time.  We've got some ideas for rewriting this application but we're currently very busy working on improving data and data access for science.  I hope we will have time to sneak in some work on Felt later this year.

I've also been doing a little work recently to modernize the monitoring for our 500 or so remote field sites and that data is going to go to Librato Metrics.  If I get time I'll write about it in the future.

Tools like Pingdom, Librato Metrics, and Jolokia have been very useful for gaining real time insight into our systems.  The arrival of great services in the cloud is providing huge benefit for us: we can spend less time building our own monitoring systems and more time focusing on the business problems and, unfortunately, with all these earthquakes business is good.