Plasmic Peach

UK Geocoding with Google and Graticule

Momo — Wed, 12 Sep 2007 16:15:00 +0000

At long last, there’s a good, free geocoding service for the UK. Finding coordinates based on post code and/or address data has long been a free service in many countries. But in the UK, the Royal Mail’s control of post code data – coupled with the ever-changing nature of that data – has meant geocoding has been difficult or expensive. Services like Postcode Anywhere and iShareMaps have provided equivalents to Google’s geocoder, but for a fee. That changed in early July 2007, when Google released geocoding for the UK.

If you’re a Ruby programmer and you’ve been doing geocoding, it’s possible you’ve been using a gem called Graticule. This gem makes light work of plugging into various geocoding services and performing distance calculations.

Graticule includes a couple of classes for UK geocoding, one based on Postcode Anywhere and one based on Local Search Maps. The first requires a Postcode Anywhere account, which is not free. The second is free, but in my experience, not very reliable.

Neither matter anymore, though, since you can now just use the Google geocoder. This post explains how to use Graticule to take advantage of Google’s new UK geocoding service.

I’m assuming you have a Google Maps API key, and that you have the Graticule gem installed. (If you don’t have Graticule, it’s just “gem install graticule”.)

In the simplest case, using the UK geocoding service is easy right out of the box. Just pass the address data to the standard Graticule Google service, and you’re there:

require 'rubygems'
require 'graticule'

> g = Graticule.service(:google).new GMAP_API_KEY
#=> #<Graticule::Geocoder::Google:0xb73959f0 @key="xxxxxxxxxx",
@url=#<URI::HTTP:0xfdb9cabfe URL:http://maps.google.com/maps/geo>>

> g.locate "NW1 8BX"
#=> #<Graticule::Location:0xb7367064 @longitude=-0.145855,
@region="England", @precision=:zip, @latitude=51.542272,
@locality="London", @country="GB", @street=nil, @postal_code="NW1 8BX">

As you can see, the service correctly found the location in the UK.

But sometimes you don’t have such complete data. You might be using a partial post code, or a street address and no post code. In those cases, the service might find a location in the wrong country—the US, Canada, or Australia, for instance.

The easiest way to avoid that problem is to use the UK-specific geocoding service URL. Graticule’s Google geocoding class sets its URL to maps.google.com/maps/geo. What we want is maps.google.co.uk/maps/geo.

When you call the method Graticule.service, it returns a geocoder class based on the symbol argument you pass in. If you pass in :google, it returns the Graticule::Geocoder::Google class. You could just as easily call Graticule::Geocoder::Google.new. In either case, the way to get a UK-oriented geocoder is to make a new class that inherits from Graticule::Geocoder::Google, since the UK geocoding service is identical to the international one with the exception of the URL.

In fact, the only method you need to write in the new class is the initialize method, which sets the URL. Below is the code for the new class.

require 'rubygems'
require 'graticule'
module Graticule
  module Geocoder
    class GoogleUk < Graticule::Geocoder::Google
      def initialize(*args)
        super
        @url = URI.parse("http://maps.google.co.uk/maps/geo")
      end
    end
  end
end

Put this code in the file “google_uk.rb”, in the directory graticule/geocoder somewhere in Ruby’s include path. For instance, if you’re using Rails, you can put it in lib/graticule/geocoder.

Now you should be able to use the new UK-oriented geocoder as follows:

> g = Graticule.service(:google_uk).new GMAP_API_KEY
#=> #<Graticule::Geocoder::GoogleUk:0xb734bcb0 @key="xxxxxxxxxx",
@url=#<URI::HTTP:0xfdb9a4b3e URL:http://maps.google.co.uk/maps/geo>>

> g.locate "NW1 8BX"
#=> #<Graticule::Location:0xb7367064 @longitude=-0.145855,
@region="England", @precision=:zip, @latitude=51.542272,
@locality="London", @country="GB", @street=nil, @postal_code="NW1 8BX">

The UK geocoder works best if you pass it a string containing a complete postcode, or a street address (no apartment number or anything else) plus a partial post code. Eg, “AB1 3CD”, or “10 Whatever Street, AB1”.

A good way to learn more about the Graticule gem is to explore the RDoc documentation and visit the Graticule web site.

Ruby is better than PHP

Momo — Sun, 09 Sep 2007 10:18:00 +0000

Lots of web developers use PHP. It’s an open source programming language and one of the most popular for making web sites. We don’t use it, though. We use Ruby.

This is not an arbitrary choice, like preferring purple to green. We use Ruby because it’s better. That’s what we tell our clients when they ask why we use Ruby. The next question is usually, “What makes it better?”

It’s pretty hard to answer that question directly, because the reasons are all highly technical. Instead, we say something such as, “Ruby is like well-crafted writing.” Or, “It’s just better designed.” Both of them are true. But how do you know we’re right, and not just expressing our opinion? Mightn’t other people think that PHP is a better language than Ruby?

Actually, probably not. What you’ll find is that people who’ve learned Ruby and also PHP nearly all think Ruby is better. People who know PHP but not Ruby, or PHP and a little Ruby, might tell you that the two languages are equivalent.

When talking about any two programming languages used for the same purpose – call them X and Y – you’ll find one of two things. 1: everyone will agree that X and Y are equivalent; or, 2: some people will say X is better than Y, and some people will say X and Y are equivalent.

What you almost never find is some people saying “X is better than Y”, and some saying “Y is better than X”. Why not? The reason is that X really is better than Y – it’s a fact – but you have to know how to program in X pretty well before you realise it.

The people who say X and Y are equivalent are Y programmers who can’t understand the more advanced features of X. To them, X just looks like another version of Y, with a bunch of other random stuff tacked on. They don’t say “Y is better than X”, because they can at least see that X can do everything Y can do. What they can’t see is what X can do that their language can’t.

So if you find experienced Ruby programmers saying “Ruby is better than PHP”, and PHP programmers saying “Ruby and PHP are equivalent”, believe the Ruby guys.

Drawing and Programming

Momo — Sun, 17 Dec 2006 00:41:00 +0000

Even though one fairly well-known programmer has already pointed out the similarities between programming and art, most people, I would say, still do not appreciate how similar they are.

One thing that struck me recently is how good programmers and good drawers approach their work – and how they differ from the inexperienced. In both fields, people who are skilled know where to begin.

Inexperienced drawers tend to approach the task pretty randomly. Let’s say they want to draw a picture of a cat. They’ll get a piece of paper, a pencil, and maybe even a cat to look at, and off they go drawing. Maybe they’ll start with an ear or an eye, or even the tail. And they’ll progress from that point, filling in a lot of detail as they go. They’ll probably erase a lot of mistakes. Soon enough they look at their eraser-smudged picture and say, “It’s coming out all wrong.”

Their cat doesn’t look like a cat. Its ears are too big. Its feet are way too small for its body. Its tail is going off the page. And there isn’t any room left for the sofa that the cat’s meant to be sitting on.

Experienced artists do it differently. They start with the most basic shapes in rough, sketchy form, making sure they’ve got the perspective and proportions right and that the object is positioned correctly on the page. They’ve studied art, so they know something about animal anatomy and perspective. And they start filling in detail only when they’re happy with the basic form. When they’re done, the picture is balanced, everything fits, and the eye is drawn to the right details.

I think there’s a similar pattern at work in programming. People new to programming often start in the wrong place – with a trivial feature that seems cool, say. And they fill in too much detail too early, before they’ve even written the application’s core engine. Before they know it, they’ve programmed themselves into a corner – they realise that the architecture’s wrong, or that the way they implemented those features depends on too much repetition of code.

Programmers with more experience tackle the core of the application first and keep a close eye on how they will reuse the components they write. They make mistakes, but they sort out the critical ones before they’ve written much, so making changes is relatively easy. It’s also easier to see mistakes when there’s not much code – the core architecture of an application is much easier to understand when it’s not very detailed yet.

One mistake that intermediate programmers can make is to assume that planning guarantees success. It doesn’t. For one thing, plans are usually wrong, sometimes in minor ways, sometimes in major ways. So it’s still important to be able to change the actual code early, and for the early code to represent the core of the application, not trivial high-level features.

In both art and programming, there is an amount of theory that is extremely helpful for producing good work. I think the importance of theory – or “science” – in art is greatly underappreciated. But in both fields, practice is the vital ingredient that leads to an instinctive understanding of where to begin.

Why small tech companies compete so well

Momo — Sat, 28 Oct 2006 13:09:00 +0000

It’s a general principle that small teams are more efficient than big ones.Teams with the minimum number of people to cover requirements are agile and can get good ideas realised faster.

This is true for software development as well as for other industries. But in software, there’s another reason why small companies compete well: they can choose better tools.

In some industries, tools are expensive, and so it’s hard for new companies to get into the market. You don’t see too many startup car companies making Volkswagen worry, because in the car industry you have to pay a lot of money for cutting-edge manufacturing kit. But you do see this kind of thing in software—a lot. That’s because in the software industry, it’s easier to use great tools if you’re small.

It doesn’t take much kit to develop software. A computer, a text editor, a programming language. The best programming languages are actually free. The only barriers to using them are what you’re already using (legacy), what your managers tell you to use, and, of course, learning how to use them.

Companies comprised of a few good programmers can use whatever tools they want. If they start fresh there’s no legacy, so they can pick their language freely. They have no bosses telling them what to use. And learning the new language isn’t a problem, because good programmers like learning interesting things. So small, new software companies can easily select tools that are better than what the established companies are using.

That explains why established software companies are constantly threatened by startups. It’s not money that buys quality tools in software—it’s freedom. And small companies have much more of that than big ones do.

But if small software companies can produce innovative products, who can use them? In the computer industry in general, it’s other small companies that use the most innovative technologies. A lot of the time, they don’t even realise the technology is innovative. As far as they’re concerned it’s just cheap. But in the computer industry, cheap often means innovative. The reason why minicomputers took over from mainframes isn’t because big enterprises threw out their mainframes and bought minicomputers instead. Small, young companies bought minicomputers because that’s all they could afford. As the small companies grew into larger ones, they never bought mainframes.

So the companies that threaten established software companies most are small, new ones selling software to other small, new companies. Those companies have the freedom to innovate, and indeed, they have the most need to, because they don’t have much money. They need technology that is not only cheap, but good—because young companies have neither money to waste on expensive kit, nor time to waste on technology that’s clunky.

I think that the more central computer technology becomes, the more other industries will resemble the computer industry. What if someone invents a way to build cars that costs a hundredth as much as what’s in use now? Then Volkswagen might start to worry as much as Microsoft does.

The Hub is cool

Momo — Sat, 21 Oct 2006 11:37:00 +0000

Michal read about a place called The Hub a while ago in a friend’s blog. It was a place where creatives, non-profits, and startups shared office space in central London.

We thought it sounded perfect for Momo, so we checked it out. We liked it, and we joined, and we now use it as our office.

Firstly, what’s special about The Hub is the people. The folks who run the place are careful about who joins. A lot of the people work for non-profit organisations, like charities. But there are also freelancers, graphic artists, and startups like us. So it’s a good place to find collaborators, projects (perhaps), and inspiration. It’s good for a small software company because we get to witness the real, everyday problems that businesses face.

But the other thing is that the Hub’s an interesting physical space. It’s at the top of a five-story old warehouse. It’s a long trek up. Inside is a large shared space with a diversity of places to work. Chairs and desks, of course, but also more relaxed, plush places to sprawl out.

And then there are these nifty stoves. They seem to be electronically-controlled charcoal stoves. (We’ll have to find out more about how they work.) There’s one of them in the meeting room where we meet with clients. Quite cosy.

Welcome to our blog

Momo — Thu, 12 Oct 2006 19:38:00 +0000

Momo Web are pleased to launch their new blog. We’re web developers working with clients in London to efficiently create sophisticated web sites and applications. We, the founders, have been web developers for some time, and both of us started programming computers as kids.

We share a vision of how web development can be done better and more efficiently than in the past, and that’s why we set up Momo. By engaging closely with our clients and our users during development, we solve real needs and avoid overcomplication. We use Ruby on Rails, a cutting-edge development platform, for all our new projects.

We’re working with a variety of interesting clients. We’ll post updates to this blog so you can read about how our projects are going. We will also post articles relating web development, open source software, business, and other things we find interesting. Enjoy!