I spoke at CodeMash for a second year in a row. I think this year’s conference was even better than last year’s, particularly for me because I was only able to attend for one day last year. It’s a shame that CodeMash has such regional attendance, because where else do you find a conference with talks on C#, LINQ, Silverlight, Python (3 talks!), Rails, Dojo, Concurrency in Java and more?
It might seem like such a broad range of topics dilutes the conference, but it’s really cool because it gives you a chance to gain exposure to things you wouldn’t normally encounter. There are a lot of interesting things going on in the Microsoft world, but I don’t normally encounter those since I travel mostly in the “open source” world.
The only thing that keeps CodeMash regional, I believe, is that it’s in Sandusky, Ohio. There’s nothing wrong with a cool conference in the midwest, but Sandusky is just not very easy to get to from most places. The biggest nearby airport would be in Cleveland, and that’s not a huge airport and is probably an hour away from the conference.
For me, personally, the location is nice. The Kalahari resort is nicely done and the waterpark is fun, and the drive is only 2 hours for me. But, this location will definitely skew the crowd to a midwest one.
The best talk I attended, not counting open spaces, was Brian Goetz’s talk about concurrency. Brian works for Sun and knows his concurrency (he’s a co-author of “Java Concurrency in Practice”). Concurrency is becoming an increasingly hot topic, as it’s common now for machines to have two or more CPU cores. He used Java as a backdrop and had a great example of how threads are hard. What made the example perfect was its simplicity: an object representing a bank account that had only three methods.
Fairly quickly, you come to the conclusion that shared state is hard to handle well concurrently. This is part of the reason that Python’s creator, Guido van Rossum, has favored using multiple processes for concurrency. Some promising approaches to concurrency mentioned by Brian:
- Software transactional memory. It sounds like a silver bullet, for people who like the threaded model, but it’s still very much a research project. The idea is that you can declare that an operation is atomic and if two atomic operations try to manipulate the same data, one will fail. This is an optimistic kind of concurrency, because you don’t actively lock the data. You just assume everything will work out okay and deal with it if it doesn’t.
- Erlang’s Actor model has proven to be quite a successful way for doing many things concurrently. However, Erlang is a functional programming language that doesn’t have many of the language features that people today are used to (like, say, class-based OO).
- Scala includes an Actor library modeled after Erlang’s. It combines functional and OO styles and provides access to the Java libraries. If you write programs in Scala’s Actor style, you can get excellent, reliable concurrency… you just have to be careful about Java code that you import
Brian also pointed out that you can improve your concurrency picture in Java by making your objects immutable. If operations that change the object return new copies of the object instead of mutating in place, your code is much more concurrency friendly. Unfortunately, you’ll still need to watch out for libraries that other people created.
The conference-opening keynote was Neal Ford’s talk about Software Engineering and Polyglot Programming. He talked about software development as an engineering discipline and said that, compared to things like bridge building, we’re still in the very early days. In the early days of any engineering, you need to do a lot of testing to see if what you’re doing is actually working, and that’s the stage we’re at with software. In other words, write tests for your code if you want to consider yourself a software “engineer”.
I’ve been a test-driven development fan for a while, and I definitely agree with Neal on the importance of testing.
Neal framed a few of his examples as “static typing vs. dynamic typing”, using Java examples to represent the “static” side of things. I really dislike when the “static vs. dynamic” debate has more to do with Java’s painful syntax than differences in typing. If you want to frame a discussion around “static vs. dynamic typing”, use a language like Scala or even C# that has type inference, operator overloading, etc. so that the statically typed examples aren’t bloated messes.
I attended a couple other formal talks, but I don’t really have much to say about them.
Something I did learn from the Hobo talk is the idea of using small (say, 30 seconds), soundless screencasts for doing demos. You embed the screencast directly in your Keynote presentation. It’s a way to do a demo where you know everything will work, you don’t need internet access, and people can see how things run. The only drawback is that the demo is fixed and you can’t change it based on realtime audience feedback. For some demos, this is a good technique that I’ll try to keep in mind.
Running in parallel to the formal talks, there were open space sessions. Anyone can post a topic and claim a room and people can join a discussion about something. As Bruce Eckel pointed out at the beginning of the conference, open spaces are awesome because they give you something you can’t have from your own home: a real conversation with other interesting people. You can view a presentation remotely, but having a real talk about something works much better with physical proximity.
Next year, there may be more emphasis on the open spaces. This year, I thought there was too much competition in each time slot (my introduction to Dojo was up against 5 other formal talks plus who knows how many open spaces sessions). I don’t think it’s good to have so many parallel tracks in a conference with 350 attendees. I think the CodeMash organizers are considering some alternative time slot layouts for next year.
I hosted two open spaces sessions. The first was about non-relational databases. We discussed when you might consider using a non-relational DB and many of the available options. CouchDB has gotten a lot of press, but Persevere seems more “done”. We talked a bit about tuplespaces and Gigaspaces. The ZODB is a nice option for Python programmers, though I still long for a ZODB storage that doesn’t require packing. Amazon has SimpleDB. There’s also MonetDB, a column-oriented database. We did also talk a bit about OR mapping, though the focus of the discussion was alternative database technologies.
The mismatch between the kinds of problems we’re solving and the kinds of development tools we use (largely OO languages today) make other kinds of databases an interesting line of experimentation. Some are ready for prime time use (the ZODB has been used in production environments for a decade), but you have to figure out which problems you’re trying to solve.
The Next Big Language
The second open space session I hosted was about the next big language after Java. This is a topic I’ve been thinking about a fair bit lately, and I have a lot more to say on the subject. The discussion was fun and interesting.
Python Web Frameworks
Mark Ramm hosted a Python Web Frameworks open spaces discussion. We talked about things people wanted to see, and we were fortunate to have a couple of Ruby people in the session to bring their perspective in. This was also good timing for Mark, who led an international TurboGears 2 sprint this past weekend.
The Experts Zone
A new feature at CodeMash 2008 was the “Experts Zone”, where the speakers can be found to discuss things in more depth. I didn’t see a whole lot of activity in the room, and I think that’s partly because it was one more thing in competition with the talks that were lined up. The schedule for the Experts Zone was also tucked away in the back of the program.
That said, Dick Wall had no trouble attracting people to his Experts Zone session where he was showing off Android tools a bit.
Software Documentation Tools
During my time in the Experts Zone, I ended up in a conversation with Bruce Eckel and Mark Ramm about programming tool documentation. There are competing needs for nice formatting, code samples that can be run by the reader and code samples that actually work.
Bruce writes his books in Microsoft Word, because he likes to be able to work on the document with all formatting intact. He uses a text editor initially on his code samples, but then copies the code into Word. Word is the authoritative source for the code in his books.
The magic here is that he’s got a Python script that uses COM to tell Word to export the document as text. Then, it rips through the text file, extracts the code samples, compiles them and tests them.
This seems like a good way to go when your primary output is the printed form. You get complete formatting capability, tables of contents and indices, and it’s easy to insert pictures and make everything look perfect. This might be even easier to implement with Apple’s Pages, since Pages documents are actually stored in XML (which I’m guessing is more readable than that of Word).
I wonder if the same can be applied to Keynote presentations?
Mark told us about another way to go that is more “open source compatible”. Mike Bayer put together tools for SQLAlchemy that let him write his docs in Markdown and have his code automatically colorized and executed to generate the SQL, which is also placed into the final HTML document.
This setup seems ideal for producing high-quality docs like the kind that SQLAlchemy has. You could easily support multiple languages and provide ways to handle setup and teardown code for tests. Some people really go for doctest, but I’d like the ability to have more code that does not necessarily appear in the final output.
This year, I actually got to spend a little time in the waterpark at the Kalahari. That was a lot of fun! The place was much bigger than I expected, and there were slides that others reported as being new this year.
My favorite was a slide where you slide down on a 4 person raft. The raft goes down a surprisingly steep hill and into what can best be described as a toilet bowl. That thing was probably 50 feet in diameter. You go sliding around it once and then there’s a big spray of water that drenches you, slows the raft down and guides you into a tunnel down to the pool below. I rode on that one with Bruce Eckel, Mark Ramm and Dick Wall while James Ward graciously stood off to the side taking pictures.
Of course, James didn’t just walk back down the stairs after taking pictures. He went down the one person version of that toilet bowl… I found that one a bit more disturbing. You start off in a completely dark tunnel before coming out into the bowl which just has a big hole in the middle. Gravity seems to want to pull you head first into the hole (I steered myself to fall a bit more sideways through the hole), and then you plunge into the pool below.
I also rode on that 4 person one with David Stanek and the other guys from American Greetings. We probably rode that one four times.
The other slides were fun as well… just avoid the waterpark if you’re afraid of the dark. Most of the slides have you in almost total darkness for much of the ride.
Oh yeah, I had two talks this year: an intro to Dojo and another about Dojo Offline. The talks seemed well-received (we’ll find out when the evaluations come in!), but the crowds were relatively small given the serious competition for interest that existed in every timeslot.
CodeMash is a fantastic conference for people wanting to get together with other geeks who care about the craft. The organizers have already declared that CodeMash 2009 is a go, so start planning your trip to Sandusky for January 2009!