CoderDojo Dublin

Jan 22, 2012

There’s been some buzz about CoderDojo in the news recently. The CoderDojo was founded by James Whelton in 2011 to introduce kids to coding at an age when they are still in school, in an environment that supports learning. With support from Bill Liao, CoderDojos have sprung up in nine locations around Ireland.

This is relevant to my interests, and I wanted to see what the whole thing was about. To get in, you need a kid, so I brought the ten year old rugby fanatic that hangs around my house and eats the food. He chose the Programming Games with Python session - no doubt wanting to fulfill his dream of getting a decent rugby game on his iPod touch at some point.

Let me digress briefly on the subject of teaching kids how to manipulate computers with software code. We use physical tools to supplement our physical selves - pushing a nail into a piece of timber with your thumb is rarely successful. We need to use computational tools to supplement our own mental computing capabilities and allow us to enhance our reasoning processes. We are already equipped to pick up a hammer, see a nail and get a fair idea what to do next, but pick up an iPod Touch and put a rugby game on it? It’s not obvious how to get there, so instruction is required. And instruction needs to be imparted early, not because we want to make more developers, not because we want kids choosing a career in coding, but because we want to give them the tools they need in the 21st century to allow them to take advantage of every opportunity that comes their way.

Back to the dojo. Our host Eugene had his work cut out for him: 25 or more young humans, with vastly different capabilities in the area, short attention spans and different laptops all around. I decided take Mr. Rugby ahead with a copy of a simple Python text game involving choosing a cave and hoping the dragon therein doesn’t eat you, taken from the syllabus book.

The programming journey went like this - at each stage we thought of a goal and massaged the existing code and added new code to get to it. The kid did all the typing, saving, running, copying, pasting. I just pointed out now and then similar chunks of code that he could reuse and got him through any blocks.

• I say - let’s extend the game from a choice between two caves, to a choice between three.
• Kid says - let’s print out which cave was which at the end of the game, so you can see which was the right one.
• We discover that strings and integers were different :)
• We discover that when one chooses three random numbers in the range 1..3, there’s a good chance two will be the same, and it doesn’t make sense to have a bad dragon and a good dragon in the one cave - they are territorial.
• Kid surprises me by coming up with a simple but effective way to make sure that the numbers wouldn’t clash, and we implement it - without using the modulo operator

Then we were done with where we wanted to go. Eugene was taking the kids along, helping each individually if he need to do so, and going down the same path initially, making an extra cave in the game.

But our local journey hadn’t finished after all. The kid had decided that now it was time to do some visuals and had sketched out a picture with three caves with numbers over them. Here’s where having a software savvy dad and the internet is a win: we grabbed a free pixel art program, muddled out how to use it, and while he drew the screen, I frantically researched free Python game libraries.

Aside - before we got onto the visuals, I spotted a few areas in the code to put in a couple of for loops, and suggested we ‘tidy up’ the code a bit so that I could show these and explain them. Why? was the response, the thing worked didn’t it? The important thing at this point is to shrug and agree - the lad is not a professional coder, he doesn’t need to refactor, he just needs results. In fact the whole thing needs to be results-driven. This is why you use a tool - not because it’s lovely or elegant or makes you feel special, but because you have a job to sort out. Then you put the tool down. It’s only when you get trained in how tools work can you start making your own tools. cf. lightsabre etc

Eventually I stumbled over pygame, which turned out to be just the tool we needed. We made a plan to write a small programme to try it out, and there was palpable excitement when our extremely amateurish drawing of caves popped up, surmounted by a hand-scrawled Danger!! sign.

On the way home on the train, we designed an rugby-themed 8-bit scroller for the iPod Touch and set up the kid’s github account. When we arrived home the kid insisted, with uncharacteristic determination, that we finish the Dragon game - adding keyboard control, putting in dragon graphics, conveying the result visually. Next challenge: the rugby game. Yikes!

Very little of this article has been on the details of the CoderDojo, but you may have already realized how the CoderDojo was instrumental in making this tiny but important success work. It provided us (and I write ‘us’ deliberately) a place in which learning was the norm; it provided a place where myself and himself were on the same team working towards an external goal; it provided a place that wasn’t dominated by adults. And that last one is the key one I think.

Many thanks to Eugene and the team behind CoderDojo Dublin for their commitment and patience in putting the series together, they are providing an really valuable service, on their own time.

Xcake - Web Services with Sinatra and Heroku

Feb 10, 2011

On Feb 8, I gave a talk at the local Xcake monthly meetup at the Science Gallery in Dublin. These meetings are predominantly loaded with mobile developers, with a worthy smattering of other creative professionals. The talk was on Web services, and how easy it can be to lash something together to test your mobile application development. Many of the mobile dev shops interact with client data through a web service, and making your own local copy with test data can give you a speed advantage in getting your (client's) app to market. The talk uses Ruby, Sinatra and Heroku as the core tech behind a RESTafarian style of service, with persistence and a public deployment.

The good news is that neither the bucket of tar nor the sack of feathers was required by the audience, there was a distinct lack of torches/pitchforks, et cetera. As a result I've posted the slides on Slideshare. They are mostly composed of screengrabs and codedumps, so make sure you view the presenter notes, in which I have expanded on the sparsely populated slides themselves. You can get the sample code on GitHub. I'll buy beers for anyone who implements simple database authentication and sends me a successful pull request :)

Note: I've spotted some rendering weirdness with Chrome - if you can't see the slides, try another browser, or hit the download button.

Awesome Regex Ninja

Dec 20, 2007

^(0*|-?0*[1-9]\d{0,8}|-?0*1\d{9}|-?0*20\d{8}|-?0*21[0-3]\d{7}|-?0*214[0-6]\d {6}|-?0*2147[0-3]\d{5}|-?0*21474[0-7]\d{4}|-?0*214748[0-2]\d{3}|-?0*2147483[ 0-5]\d{2}|-?0*21474836[0-3]\d|-?0*214748364[0-7]|-0*2147483648)$

An Infestation of Snails (was: Java Annotation Madness)

Sep 19, 2007

I was just reading an article on JPA, posted on TheServerSide. In it we see a simple 'real-world' example - a mocked-up blog application. The object model looked fine, the DB schema representation looked fine, but then I got to see the Java, annotated JPA-stylee.

import javax.persistence.*;

@MappedSuperclass
@EntityListeners({ModelListener.class})
public abstract class ModelBase {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name="id")
    private Long id;

    @Version
    @Column(name="version")
    private Integer version;

    @ManyToOne(fetch=FetchType.LAZY)
    @JoinColumn(name="created_by_user_id")
    private User createdByUser;

    @Temporal(value = TemporalType.TIMESTAMP)
    @Column(name = "date_created", nullable = false)
    private Date dateCreated;

    @ManyToOne(fetch=FetchType.LAZY)
    @JoinColumn(name="updated_by_user_id")
    private User updatedByUser;

    @Temporal(value = TemporalType.TIMESTAMP)
    @Column(name = "date_updated", nullable = false)
    private Date dateUpdated;
    // methods removed for readability (LOL)
}

I got a bit of a chuckle out of the comment at the end of class declaration, but my overall feeling was one of giddiness at the sight of Annotations Gone Mad. It's fashionable, it appears, to bang in as many annotations as possible in Java 'frameworks'. If you have dealt with debugging C# webservices clients, you might recall the brain damage that was introduced when trying to fish through dozens of C# annotations in the generated code. Is this going to happen all over again, but for Java this time?

My particular complaint is not about using annotations, which I do think are wickedly useful for getting rid of the omnipresent and immiscible configuration APIs in thousands of products. Being able to inject values into class members is brilliant. There are even some gnarly uses where annotation declarations may themselves have annotations (go look at the Apache Camel source code). But using annotations to tie Java programs to what are irreducible and unmappable resources - ports, URLs, even DB tables - doesn't make a lick of sense to me.

Update: Benson Margulies has given this condition a name - an infestation of snails (@) - in a cxf-dev posting. This is so good I had to change the name of this entry.

Release the Hounds!

Dec 4, 2006

Or, in this case, the incubating projects. Apache Yoko incubator has published an M1 release. Yoko (no, I don't know why it's called that) is a fast Java CORBA server which can be used in Open Source JVM and JEE implementations. Hot on it's heels, it looks like the Apache CXF (yes, I know why it is called that - don't ask) is gearing up to an imminent 2.0-M1 release. CXF should be very interesting to people who are doing JAX-WS service development - I have been using it myself in another project and it has worked very well.

Back in the SOA Tools Platform project we're adding UI support for JAX-WS service development and we are testing against CXF to make sure that we are generating the correct classes and dealing with the JAX-WS and other annotations in the right way.

WSDL to *

Nov 14, 2006

It's expected that once you have an interface language, like WSDL or CORBA IDL, that you will have a suite of tools that allows you to generate stubs, skeletons, starting code, tests and so forth from the basic interface description in the implementation language of your choice. This is a very important productivity element for any developer, as having to code up server skeletons by hand is just an outrageously dull task.

When I was putting together CORBA systems, I used a tool called idlgen which saved huge amounts of time by generating complete test suites with randomized data, and allowed you to produce stubs, skeletons and mainline code in a jiffy. In my current work, I'm using EMF to represent a suite of models, from which I generate implementation code.

But there's one thing that's starting to bug me about some code generation tools, and here I'm talking about one particular tool that is almost always called wsdl2java, and that is there are so many of them. Everyone! Stop writing new wsdl2java tools and just write a wsdl2star tool instead! Take wsdl4j or Woden as your model and write some backend processing that allows people to develop Velocity templates, or write JavaScript/E4X code to generate the necessary. Wrap all of this up in a single Open Source project and kick-off a community of Open Source script/template developers so that other projects can contribute their code generation incantations (there's your regression test suite too, by the way).

Is there someone doing this already? Let me know if you find them!