January’s London Clojure Dojo

January meant Battleships. More specifically battling battleships. Five teams created players and duked it out during the dojo with a tremendously narrow margin of victory. So what did we learn?

Well first of all randomly placing ships and shooting is actually a pretty good strategy. This is what the default player does and any deviation from it can be pretty badly punished by it.

One simple thing that people did to start improving over the random start was restricting placement of ships to a single half or quarter of the board. Doing this allowed most teams to start beating the initial strategy.

However clustering your ships is only effective against random shot placement so when people start implementing targeting you actually become more vulnerable. The first effective targeting strategy was surprisingly simple, if you hit something choose an adjacent square as your next target.

The team that squeezed to the top refined this by choosing an adjacent square that hadn’t already been fired at. The next level of improvement would probably be a non-trivial look at the probability that another ship square lay in the adjacent squares by looking at the information surrounding them.

There was a lot of work around the concepts of adjacency and whether the square had been fired at and the teams all seemed to converge towards the clojure.set library (if they were aware of it).

I’m now thinking of what fiendish problem would force and exploration of this library as it seems incredibly powerful for all different kinds of problems.

Silicon Milkroundabout Roundup

Interesting time at Silicon Milkroundabout this Sunday. There were kind of three levels of activity going on, first of all there was the element of developer goofing off with arcade machines and free stuff. Then there was the opportunity to network, first of all between the startups and secondly between the developers (although I am not sure how much mixing between different dev teams was actually going on).

Finally there was the recruitment activity. Unlike the first event this really was more of a milkround with a younger, less experienced audience. The format did seem to be pitching for talent which is interesting as I am not convinced that people are going to find the best role by going with the best sales pitch. There has to be a better way of understanding the culture of the firm you are potentially joining.

The different streams of activity make the event quite weird in its nature and purposes. It feels like there is a need for a kind of startup expo to allow startups to see and meet one another without the pretext of seeking to employ people. There is also a need for a kind of elite coder event on a quarterly basis that is maybe a little select, a bit like a mini-conference, that allows for networking and swapping of intelligence and gossip on what is really going on at various firms.

Clojure metadata, the compromise solution

One thing I think is really great about Clojure is the deep reflection and runtime manipulation capabilities that are on offer (it is one thing that I really miss in Scala for example). Last night at the London Clojure Dojo (website needs to be created this month I feel) we needed to distinguish a subset of functions. Now ideally we should have put this subset in a different namespace but you know code that is written by many hands doesn’t always make sense and now we are where we are.

We knew it was possible to examine all the functions in our namespace and that the relevant functions would take two arguments with particular names (we are at least consistent in that respect). My initial view was “hell, lets just find every function taking the the right names”, at the other end of the spectrum were people who thought we should explicitly declare the list of valid functions. In the end we settled on adding some metadata to the relevant functions.

This seemed a reasonable compromise, it means that applicable functions are explicitly defined but that in terms of code maintenance we only have to write one function that generates a list of all the valid functions and this will correctly respond to changes in the code as they are made.

This led to another conversation at work about whether a function’s metadata is mutable or not. Now it seems that as map it should be possible to edit it but it’s an interesting question.

Eddie Izzard

Looking pretty cool in glasses and leather jacket, strutting (or staggering) up to Seven Dials while listening to his iPod. Looks like a proper “famous person”.

John Hodgeman

Walking into Neal’s Yard at lunchtime. Thinner hair and shorter than TV suggests but genuinely possessing that beautiful, melodic, broadcast voice. In many ways looked more like a nervous office worker. Here for the Coraline opening according to Twitter.

London Zine Symposium

On Sunday I took a trip to the London Zine Symposium in the East End and filled up on a lot of zines, falafel and flapjack. Unfortunately due to other commitments I wasn’t able to spend the whole afternoon there but I was glad to get along to it and enjoyed a lot of what I saw.

The venue was pretty good, a slightly musty workshop-style space that was slightly overcrowded and under-ventilated but with a nice open courtyard and space for a wide variety of stalls. The organisation was also excellent with a lovely programme, a series of talks and a zine in a day effort. I always enjoy having an active, creative element to an event like this and the talks were really welcome as a way of having a bit more depth than just buying zines.

Personally I was looking for what has been happening in the zine scene as I haven’t really been that involved for a couple of years (I have been looking more towards the internet, of which more later) but I was also looking for relatively heavyweight zines that focussed on prose as I have enough poetry, sketchbooks, comics and collage books to last a life time. One thing that immediately struck me is that there is a wave of graphic design sweeping through and in particular screen printing seems to have taken off and people are really good at it.

In terms of content though I was disappointed, I haven’t gone through all my purchases carefully enough but there was very little that I was immediately excited about. The revolution still hasn’t come, grrrls and queers are still upset, girly kitsch is timeless and all the DIY guides still come from America. There was a sense that the topics are the same and in fact the forms are being recycled by a new generation to experience something for themselves. That’s a shame because actually when revitalising and reinventing something like DIY (as an aesthetic) or zines then everything should be up for grabs. It actually felt that a lot of the technology stuff I’ve been doing in the last year (unconferences, Social Innovation Camp) actually feel a lot more radical because they are pushing the boundaries of everything to do with their organisation, running and communication.

Of course things like zines are very broad church or at least should be. The old tensions are still there between the politics, the aesthetics, the purism but there also felt like there was now this tension between the artists and those people capable of organising very high production values and the older lo-fi crowd. It is all nonsense as usual and is probably a good sign as factionalism only occurs in large groups. The marginal tend to have to stick together out of necessity.

One thing that was clear though was that the Internet was often dismissed out of hand. That might seem natural at an event dedicated to physical works but I was disappointed as the next logical transition is to combine on and offline works in a continuum. I am a huge DIY zine fan and I have espoused the importance of the physical zine for a while. I have also been looking at the idea of Constructivism and the mass produced artefact. The photocopied booklet seems to me the logical extension of a lot of those ideas.

However as Internet access becomes more pervasive and the ability to create and host content online becomes less and less mediated it seems against the goals of the culture not to embrace it. The photocopy seems democratic but the truth is that by itself the handmade limited edition is more elitist or ghettoised than the webpage. Valuing the physicality of something is fine, valuing it over the ability to connect to an audience is an ideological limitation. The internet has done more to achieve the creation of communities and the connectedness of individuals than the physical zine has ever managed. We cannot pretend it is the 70s anymore.

For me the event itself showed a good example of how to combine the power of the web to organise and co-ordinate the event with physical tokens of attendance in the form of the programme. I will also be following the reaction to the event online via people’s blogs rather than through the zines. However in six months time the things I have seen and read will go on to form some kind of zine because it is something I still love and a format I feel is still enjoyable.

So what would have excited me? Well having a look at the pages people were creating for the on day zine I think that there is an undue emphasis on the personal or single creator zine currently. I found only one anthology zine (although there may have been two punk collectives who seemed to be creating single collective titles but collections of reviews, gig reports and interviews don’t really have the cohesive editorial content I was looking for) I would have liked a few more. I also would have liked more words, something really text heavy with an emphasis not on impressionist feeling but actually essays and arguments. Things that appeared to engage outside the personal, domestic world.

Things I did like were zines made up of digital camera photos and text messages, I enjoyed the way they reflected both changing creative possibilities but also the way our world is changing. I liked stalls that had a synopsis of the zines they were selling. I liked the artist’s books, but only so far as their cost made it feel difficult to buy something that might have good and bad moments. I liked the collectives who mixed the books with prints, cards and more conventional black and white photocopies.

I also really liked people who were selling their own food and cakes. What an obvious gap in most shows I’ve been to, don’t just sell the recipe booklets! The Symposium t-shirts were pretty cool too. It was a good afternoon and I would have liked a little more time but hopefully there will be another one next year.

Django in 24 hours

Last Saturday afternoon I decided to learn Django. It was 2pm on the first day of SiCamp 2008 in London and being the only developer in the room at that point I decided that I should do whatever I felt would be the best option to get an application running by 2pm the next day.

Previously I have done some Google App Engine and the experience convinced me to give Django a go after I found myself, by intuition, creating a GAE project structure of handlers.py (views), models.py and a directory called templates that contained templates. I was then disappointed to find the whole world had got there before me.

So, Django in 24 hours, baptism of fire. What do I think now looking back on the experience?

Everyone has told me that the Django documentation is good and I think I have to concur. Not everything is so clear that when you’re speed reading in one window and typing in another it works first time but importantly nothing in the documentation is actually wrong. When stuff is not working a second, careful look at the documentation got me back on track.

Importantly Django’s core model of web development is sound and intuitive. My editor had around ten files open for the project and the flow of adding something to the application did naturally flow from url to handler to view to model. Maybe the only quibble I have is that the views.py file is deceptively named in MVC terms.

The core of the framework is amazingly concise, I spent the majority of my time thinking about the problem not about the framework API. Binding a URL to function made sense, having to specify a template instead of having one inferred from the method name was maybe my one criticism in the method handler but on the plus side it does allow for flexibility in handling requests. Handing off from one request handler to another was very easy.

Django templates are both amazing and annoying. The syntax and principles are amazing, it was easy to play around with the pages and the template inheritance was really powerful for avoiding duplication. However when I transferred the application from self-serving to mod_python the template generation was very wobbly when compiling changes from the file system. Of course this could also have been mod_python but it was the latest 3 series stable source compiled for the machine. I’ve used Jinja2 previously when generating HTML in Python and might be tempted to stick with it in future.

Django models are great, I hate ORM but I really liked syntax for defining persistence properties and I liked the way that you don’t have the fact that you are really dealing with SQL hidden away from you. It genuinely seemed a more convenient way of expressing the data model rather than an OO wallpaper over relational data storage. I didn’t feel the need to add domain logic to the models but I felt like it wasn’t really polluting the model to do that either.

One thing that didn’t work at all was changing the relations between models; it took me two or three attempts to finally model the relationships between the data concepts. Each time I changed a Foreign Key or Many to Many relationship I ended up deleting the database (SQLite3) as I couldn’t figure how to migrate from the old schema to the new.

One reason for choosing Django was the idea that I wouldn’t have to write the backend code as the admin stuff would be right there for me. It took me a while to get the 1.0 admin to fire up but once it was running it did perform as advertised. One of the attractive things about the application was that the data model followed the conceptual language of the solution in a really powerful way. You could use the admin interface to have a Devotee perform Devotion to an Action. My geek excitement peaked anyway, YMMV.

So them’s the highlights of the experience. Overall Django delivered me a rapid web development process in an intuitive, powerful way and lived up to nearly all of the claims made on the tin. Deploying to Apache/mod_python was painful but most of the pain surrounded the infrastructure of my box (multiple versions of Python, Apache config files) and my lack of mad Apache admin skillz.

I would happily tackle another project in it again.

Perhaps of interest is how the Django development experience matches up against Rails or GAE  which would have been the other obvious choices. GAE would have been very similar but the deployment would have been better and I wouldn’t have had any automatic admin. In retrospect it may have been a better choice for a hack party type event. It certainly would have been my choice for personal projects for easy of deployment but now I have one Django app running perhaps that isn’t as relevant any more. Certainly the thing that has kept me from GAE before, the pain of data migration, doesn’t seem that better in Django (except that you control the datastore and its contents).

Compared to Rails?

• Admin is much more awesome than scaffolding.
• Django ORM is much less complex than Active Record, all the data required to create, deploy and use the object is in one place. Django doesn’t have Migrations but has its own brand of database versioning pain.
• RSpec is awesome (despite its monkey patching of Object) so you aren’t going to beat Rails for easy testing.
• Django templates are more powerful and easier to use than Erb but you have a lot of Ruby templating options so it’s hard to make a complete comparision. They probably both similar in the sense that you can find a template library that suits your preferences. Django is the purely solution out of the box.
• Routing and Controllers are much less involved in Django than Rails.
• Django is less opinionated about how you structure your application directories, which I like.
• Django doesn’t bake-in AJAX components but is “batteries included”, Rails probably generates better Web2.0 style apps for less effort.
• Finally Django uses only a few code generators because its basic structure is far less involved. It also generates far less “stuff” for each MVC element which I quite like as I don’t tend to use everything Rails generates.

Okay detailed analysis over, what’s the high-level view? Django and Rails are similar experiences but I think the major differences between them are almost what you could say about Python and Ruby. In Django you are going to get simplicity, clarity and a real choice of how you plug your infrastructure components together. In Rails you are going to get magic up front which is cool but also magic at the back end, which is not cool. Ultimately I think the answer is how opinionated you like your software. Well punk? How opinionated do you like it?

Jarvis, Upper Street

C’mon there’s only one Jarvis! It’s Jarvis Cocker with huge, ragged hair, razor sharp jawline and a general air of being the most expensive tramp in the village. And to think that he lives in France now…

London Scala User Group Meeting

Had a good meeting (I thought anyway) at the TW offices that featured a talk from Jamie Webb introducing Scala and then a quick dojo. Scala has a much terser syntax than Java but I managed to do my classic thing of mixing my languages and putting my constructs in the wrong place. The other thing that doing rather discussing taught me is that Scala’s constructor syntax is much better defined than Java with the default constructor going into the declaration of the class. That’s the kind of improvement on Java that I really like in Java. It seems to distill all these lessons you’ve been learning if you write good Java code.

The pub after the event also saw a lot of discussion, there was quite a bit of discussion about testing and dynamic versus static typing. Personally I have decided to follow Neal Ford and reject the issue. To me both Ruby and Scala are low ceremony, high essence languages that choose different approaches to address the same issue. As such I don’t think there is any contradiction in liking and wanting to learn both languages.

Similarly I love compile time checking but I’m not giving up on testing. It’s a synergistic practice and I want to get the benefits from TDD/BDD/Tests as Specification. To me there is some irony that if I do have a test suite then actually I have more flexibility about my choice of languages. Not testing means you get much higher value from strong compile checking and therefore something like Scala is going to deliver much more benefit quickly. At the end of the day though I don’t want to have treat my tests as the gamekeeper of my wild code. I do expect the language and the compiler to give some structure and help to the development process.

Despite (because of?) my mistakes  want to do some more and I think Aaron (the founder of the group) suggested converting an existing Java program to Scala. That seems pretty sensible and I have an old Java program that I use a lot hanging around that needs some TLC.

If you are interested in Scala and in London I would recommend coming along to this meetings because you have the chance to meet and talk to everyone who is really engaged in Scala in the city. And to the guy who came all the way from Belgium; I salute you, you are a real hero!

John Rocha, Mayfair

John Rocha, locking up his office. Awesome! I thought the John Rocha offices were just where they did office admin but there’s Rocha himself, smoking a cigarillo and chatting to a Bubble apparel-like employee, locking the goddamn office by himself.

Does he open up and take in the milk I wonder?