Slides from "Hacker 101/102" code4lib pre-conference

Monday I gave a whole-day pre-conference at code4lib 2010 in Asheville called "Hacker 101/102" and "Hacker 201/202". The morning ("Hacker 101/102") seemed to go well - the thirty or so people who attended seemed to move smoothly through the material, asked a lot of great questions, and offered a lot of positive feedback. Here are the slides (also attached as a pdf) from that part, which give a full tour of basic programming concepts using Processing:

Hacker 101 - Intro w/Processing

View more presentations from Dan Chudnov.

The afternoon session ("Hacker 201/202") started off poorly, as I'd not figured out the "what platform can we use to move a little further with this stuff" problem and we all stumbled around trying to get some stuff going on our desktops. Fortunately Mark Matienzo was there to give a tour of pymarc and Mike Giarlo was there to fix my crappy example code and many other people helped each other out when I was fumbling. The latter part of the afternoon was saved by dropping the "let's get this working" bit and instead opening discussion up to why unit testing is a good idea, with a tour of how pymarc unit testing works, and a walkthrough of the Kohana web framework by Eric Palmitesta and a similar discussion of what Django offers from me.

Surprisingly the room didn't empty in the afternoon, and I'm just sorry that I hadn't thought things through better. Running into problems getting language libraries installed and running on diverse platforms is, in a way, the kind of stuff that all of us deal with all the time, even very experienced folks. So it was kind of natural that that would happen. Unfortunately running into that kind of frustration is the kind of stuff that keeps newer developers from progressing past the basics, and before I attempt a session like that again I'd prefer to have a radically different strategy that builds up confidence in a more controlled way. I just don't know what that is yet. I hope that at least it was reassuring to the 50 or so attendees in the afternoon session that this kind of crap does really happen to all of us and the first thing you have to be willing to do is stop beating your head against the wall and ask somebody else for help. Many participants did exactly that and made progress getting things going, so I hope that small set of victories will help in some way.

In any case I'd like to think the morning was a full success and I'd like to give a Hacker 101/102 pre-conference session again for sure. We still have the list we set up for the pre-conf and I hope participants will share their thoughts on how it all went here or on the list. I also hope that everyone will consider asking for help when getting stuck on whatever folks get stuck on back at our regular jobs, either on the preconf list or on the code4lib list or whatever forum might be appropriate.

20100222-c4lc-hacker101.pdf2.08 MB



Sorry you folks had trouble -- it happens pretty much every year. I think it's time to make it a requirement for pre-confs that involve hacking that everyone show up able to run some specified VM, and that the presenters/instructors show up with a couple USB drives with said VM on it.

Hacker 101/201


I missed your hacker session this year, but I'll be there next year.

@Bill - well, it's not quite

@Bill - well, it's not quite that easy. It's my fault we had trouble, I should have routed around the problem. When a large number of participants have netbooks, you can't expect them to run VMs. Next time I'll just skip that complicated part, probably.

@Matthew - I hope so! Glad that you made it and want to go again, and that we had time to catch up.

One-click installers

To me, this is a big win for Ruby in these situations, where you have a couple of choices for drop dead simple installations: JRuby runs on any machine with a Hotspot JVM and for Windows, there's the "One-click Ruby installer" (and for *nix, there are package managers).

Was there a specific language or library that presented a lot of trouble?

@Ross Ruby would be a good

@Ross Ruby would be a good choice, too, especially if I knew it. But the problem isn't really about the language choice - it's about lowering barriers so people can focus on what the code is about. Processing is a great choice because it installs easily and is fun to work with and has its own editor. Javascript is a great choice because you can play with it right in the browser with Firebug.

The problem shows up when you add in a full-on language and a standalone editor and libraries for that and sample data and sample code. It's just not easy to get people with diverse machinery up to the same speed quickly, no matter how much easier things like one-click installers get. Everybody got Python working just fine, as I'm sure we would have done with Ruby, too. It was getting it to work with PyMARC and and all of that which is the key point you want to get people to so they can see it all together and put it all together for themselves, but getting all that together is not easy.