Hack day sounds fun. Two days of hacking and socialising at Alexandra Palace. All the cool kids[1] are going to be there. Are you?
The language on the official site is a bit "legal". Tom Coates explains in English.
[1] Places are limited. I hope I'm cool enough :-)
I'm currently building a web site that will involve plotting the positions of buildings onto maps. I'm going to be using Google maps for that. Unfortunately, the data that I need to plot is a list of postcodes and as far as I can see, the best way to plot stuff on a Google map is by using its latitude and longitude.
So I needed a way to convert UK postcodes to lat/long. The frustrating part is that I know that the BBC has an application that does that (and many, many other things) and that they have been planning to release it as part of Backstage for some time but that licensing issues have been preventing that from happening.
And licensing is at the heart of the problems faced by people trying to write geographical systems for the UK. Most of the truely useful data is owned by commercial organisations who want to make money out of it. Postcode information is owned by the Post Office and a lot of other data is owned by the Ordnance Survey. And the licenses for this data are expensive enough to prevent most people from using it. This is the basis of the Guardian's Free Our Data campaign.
At this point, I should point out a couple of projects that are trying to address this problem by building a free database of postcodes - Free The Postcode and New Popular Edition Maps. I'd urge you to visit both of these sites and tell them about any postcodes that you know.
Unfortunately, the coverage of both of these projects was too patchy to be of any use to me. But then someone pointed me at nearby.org.uk and all my problems were solved. This site converts between many UK geographical coordinate systems - including converting postcodes to lat/long. And it has a nice web services API which made it simple to write a program to grab the hundred or so values that I wanted.
All in all, a successful afternoon's work.
Oh, and whilst experimenting with Google maps, I built this - places I have lived in London
This is very cool. An article in Wired features a member of london.pm
Some DJs spin vinyl or twiddle fader knobs. Others write subroutines in C++.
A new brand of music maestro is turning programming into performance, eschewing turntables for a compiler and a mind for syntax structure. "Livecoding" practitioners improvise using Perl or homemade programming architectures to build compositions from the ground up, replacing instruments and samples with raw code authoring before a live audience.
Alex Maclean, a U.K. livecoder and art student, said he traded in his guitar when he found he could be more creative with code than with strings. He touch-types using Perl at raves and dance clubs, creating a unique visual and musical experience. Sessions with drummers, MCs and other livecoders can be reminiscent of traditional free-jazz improvisation.
I've been a bit busy this week, so I haven't mentioned the Amazon Web Services talk that I went to on Monday evening. Amazon Web Service Evangelist (cool job title) Jeff Barr talked for almost two hours about what Amazon are making available. It was all very interesting and I wish I had more time to investigate it in depth.
I had an idea for an application during the talk but then Jeff mentioned Wish List Buddy as an example. It doesn't do all that I was thinking of, but it's a start. Maybe I'll find time to work on my version at some point in the next few weeks.
Oh, and I loved the phrase "artificial artificial intelligence" to describe Amazon's Mechanical Turk service where you can use human input as part of your application.
Thanks to Jeff for giving the talk and Dean for organising it.
From the Guardian
Ashley Highfield, the BBC director of new media and technology, also announced proposals to put the corporation's entire programme catalogue online for the first time from tomorrow in written archive form, as an "experimental prototype"
This is the cool Ruby on Rails project that Matt Biddulph was working on last year.
More announcements tomorrow apparently.
Update: It's alive
Joel Spolsky has been playing with Ruby on Rails. He's written about some of the problems that he found. This has upset some members of the Rails community.
On of the best points that Spolsky makes is one I've mentioned here before - the fact that ActiveRecord is a horribly crippled ORM system - it seems to have been written by people who are afraid to let their database do what it does best (i.e. deal with data).
Update: As Mike points out below, the article wasn't written by Joel Spolsky, but by an anonymous contributor to the "Joel on Software" discussion boards. Apologies for any confusion caused.
Update: Oh look. these people saw my error and spent an amusing hour or so taking the piss out of me. Glad I amused them so much.
It's been a few weeks since we've had a "Java is dying" post. But it seems that the idea is really starting to take hold. There's a story in Business Week this week which covers much of the same ground as we've seen before. Previously I've only seen this kind of analysis in media aimed at techies. Business Week is read by management. I wonder if having the story covered in places like that will make it a self-fulfilling prophecy.
It's interesting to see the various parts of the LAMP stack described as "upstarts" - given that most of them have been around at least as long as Java.
In my opinion one of the best and most important talks at last Saturday's London Perl Workshop was the first talk in the beginners track where Greg McCarroll talked about "Rediscovering the Joys of Perl". Greg introduced a couple of quick hacks that he had written to make his life better. He went on to say that the best way for a programming language to prove itself is for people to stop building over-complex frameworks (or, worse, talking about building over-complex frameworks) and to just get on and write useful applications. If people took just one idea from from the LPW then I hope if was Greg's message of "JFDI"[1].
Greg and I were talking about this in more depth last night and we agreed that the Perl community often suffers from a lack of JFDI. In many ways CPAN has proved to be a double-edged sword. Of course it's great that it enourages people to write and, more importantly, share reusable code. But on the other hand it often seems that writing reusable code libraries is all that Perl programmers do. There's precious little evidence of them ever writing useful end-user applications. Of course there are great Perl applications out there, but they seem to be the exception rather than the rule.
During our discussion we came up with a rough and ready way to measure whether what you're currently doing is JFDI or not. The idea is that if a programmer knows that what they are doing isn't currently JFDI then they have a strong indication that they would be more productive if they reordered their priorities.
So, I give you the McCarroll-Cross Productivity Indicator (MCPI):
If you can't explain what you are currently doing to a non-technical person in one short sentence, then you are not JFDI
[1] "Just Fucking Do It".
When I saw him in Amsterdam, Matt was talking about a secret project he was doing for the BBC. And now he has revealed what it is. He's putting a web front end on the BBC Programme Catalogue. That's a database that contains details of almost a million programmes that the BBC have broadcast over the last few decades. It all sounds really exciting. Matt is ably assisted by Ben (who seems to be following me around on my 2005 tour of old media outlets) and Murray - both chaps who really know their stuff.
First previews should appear within a few weeks. I'm looking forward to it.
Last week David Heinemeier Hansson wrote a rather controversial piece about the use of stored procedures, triggers and relational constraints in databases. Later in the week Alex Bunardzic backed him up. What they both seem to be saying is that because we now have powerful tools to represent our data models in code[1] then there is no longer any requirement for the database to use any of these features which model parts of an application's business logic. The argument seems to be that they want to model all of the business logic in the application code and that splitting it between the code and the database only complicates matters unnecessarily.
I just can't agree with this point of view. If there are business rules which describe the valid states of your data then those rules belong in the database. The most obvious reason for this is that there will always be other applications that want to access the data in your database. These systems might not be built using the same tools as your original application and that makes it unlikely that they will be able to use your carefully constructed ActiveRecord code. Which means that someone else will need to reimplement the same business rules using their own favourite technology. And everytime the same logic gets reimplemented, there's a chance that discrepancies will creep in. This is the Don't Repeat Yourself principle in action.
The original articles recognise this problem and they think they have an answer. They talk about the difference between application databases and integration databases. They say that their rules only apply to "application databases", which are database that only support a single application, as opposed to "integration databases" which are there to share data between multiple applications.
I think that this distinction is nonsense. In the real world, these "application databases" simply don't exist. Or, rather, there are so of them that it's not worth considering them separately. Oh sure, most databases start out supporting a single application. But once you start getting an interesing amount of data in it, there will be other applications that want to use it. And then they'll want to start adding their data to your database. And before you know it your "single application" database is the company data warehouse.
Yes I'm exaggerating. But it happens. I've been building databases for almost twenty years and I don't think I've every seen one that didn't eventually become an "integration database". And for a multi-application database you need to put as much as possible of the business logic into the database.
If the Ruby on Rails people are seeing a lot of single application databases then good luck to them. But I think it puts a serious question mark over their experiences with databases in the real world.
[1] They are tailking about the Ruby on Rails database access layer, ActiveRecord, but their points are just as applicable to things like Perl's Class::DBI or Java's HIberate.
Recent Comments