Posted on
by

Following on from my post yesterday, I would like to introduce something I quickly hacked together to show how the kind of thing I was talking about might work.

As discussed in yesterday’s article, I already use twitter to provide a data feed for selective traffic alerts.

Street Level URLs provides a simple wrapper around this search, providing you with a nice summary page and the option to access the data in a number of different formats.

It uses twitter for the actual data and uses mod_rewrite rules to wrap the actual search up into an addressable URL.

Have fun!

» Street Level URLs

Posted on
by

I like feeds and APIs.

Feeds and APIs provide ways for others to access a service and to recombine the data in new and unexpected ways. Ways that have consistently been proven to be beneficial to both parties (which makes google’s increasing antipathy towards them an interesting, not to mention short sighted, trend).

Anyway, it was one morning when I was attempting to find a route to work for my girlfriend which bypassed the numerous arterial route crashes that had happened that morning and I found myself pondering thus…

… wouldn’t it be cool if roads and junctions had permanent URLs, and better yet if you could get a data feed on them?

This would let you do many cool things, for example you could enter your route to work and get a status of the traffic en route – or at the very least attach a particular traffic blackspot (in our case the 13 bends of death on the A4074) to ifttt and get SMS alerts if there was a problem.

Giving roads and junctions addressable urls would be an obvious extension to the google maps API, but given that Google won’t even let you embed a map in a page if it contains a traffic data overlay it seems unlikely they’ll provide such access to their data. Other sources such as the Yahoo’s traffic API has long since been shut down.

So, what alternative traffic data sources could we use?

One possible data source we could use would be to parse a twitter search for the road in question. We both currently use ifttt hookups to get alerts for certain key roads, so the basic concept is sound.

This isn’t perfect, for example there is no understanding of the context of a message – so for example a message saying “No traffic problems on the A4074” and “Terrible crash on the A4074” would both trigger the alert, but only the latter would indicate a problem.

The other problem of course is that it also relies on people tweeting, but in effect this would actually pull in quite a diverse range of secondary sources – in my case, for example, it also pulls in any source that feed into the local radio station – which includes reports from their traffic spotter plane.

As an individual without access to data from traffic sensors, or any ability to collect data directly (unlike, say, google who can use position reports from android phones), we are pretty much limited to collecting data from secondary sources as far as I can see.

What other sources could we use?

Posted on
by

Opinion: If you embark on building a major project without implementing some sort of automated testing/regression testing framework along side then you are a fool.

What?

Regression testing is nothing more than a set of automated tests that are written to test certain parts of your code. Tests can be written to test core bits of functionality, or be written to replicate certain bugs.

Crucially, these tests are run automatically – perhaps daily or on code commit – and make sure that core functionality remains functional as your development moves forward, and that known bugs don’t re-surface.

There are numerous test suits out there, but in all honesty you don’t have to be fancy. In my projects I often find myself reusing a test suite I initially put together in an afternoon (and have improved on ever since) and which is far from the most sophisticated bit of software ever written (although it is nonetheless exceedingly powerful if I do say so myself!).

Why?

Primarily, this sort of testing gives you confidence in the code you write.

It requires a little discipline from your team – namely that you write a test as part of your development process as you build out new features or squish bugs – but this actually fits quite nicely into the development workflow (afterall, you have to test your code somehow).

However, once you’ve got into the habit of doing it you can then rest easy to know that a new feature hasn’t silently broken something you wrote ages ago, or that a nasty bug hasn’t resurfaced.

In other words, your code is provably correct – this saves you time, as well as saving you the embarrassment and cost of inconveniencing paying customers.

Tests are also (quickly) repeatable, systematic and deterministic.. unlike the standard “run once and click a few buttons” method of testing adopted by many software developers out there.

An Example

Here’s a personal example of the ass-saving power of having a regression testing framework in place..

A couple of weeks ago I was deep in Latakoo’s server infrastructure making all kinds of performance optimisations to the page loading and database handling code. To get some more data as to where some of the bottlenecks were I performed extensive profiling (more on that later) and added sections of debug to collect statistics on various parts of the system.

All good stuff.

However, one apparently minor change I made had an unexpected and not immediately visible effect of completely breaking the Latakoo API. This API is what all the clients use to get video into our infrastructure, and so had this code change made it through to our production servers it would have prevented anyone from using our service and have cost the company untold $ in lost revenue.

The performance of the API is something that is naturally tested by the regression testing framework, and no sooner had I applied the patch on our test server than I received an email telling me that I had broken the API.

A quick fix later and a potentially costly and embarrassing show stopper of a bug was caught and fixed before anyone else knew it existed.

The moral of the story…

Bugs happen. Software development is hard and even the best of us make honking mistakes from time to time. What matters is that you acknowledge this and have the necessary early warning systems in place to prevent them becoming a serious problem.

All it requires is a little discipline and this is what grown-ups do.

So write those damn tests already!