Geoffrey Grosenbach spoke from his university background in philosophy and interest in music, and wondered interestingly if developers are less aware that modern methodologies derive from the scientific method because they’re stuck in the implementation phase, without necessarily being involved in coming up with the original ideas or validating the experiments. The link from Spinoza to cloud computing was a long but entertaining stretch. Invoking the Sapir-Whorf hypothesis as a good reason to do a desktop app instead of a web app every so often (or vice versa), for the wider perspective, struck home.

John Lam spoke of how you gravitate to the same problems over and over, drawing lines from IronRuby to his early days metaprogramming in assembler on a Commodore 64 and building bridges between components, and of how you can change your mind, remembering his early paper on how dynamic languages suck. He explained his move to Microsoft on the grounds that he really wanted to build stuff that people would use: you can build stuff in open source, but brilliance alone won’t guarantee that people use it.

Hampton Catlin spoke about Jabl, which he cheerfully billed “the language you will hate”, his attempt to fix javascript (which he sees as a good if verbose general-purpose language but a terrible browser language that needs frameworks to fix it). Jabl will compile into javascript, is backed by JQuery and provides a compact DSL for client-side DOM manipulation. It look neat and quite compact (a good deal more compact than the equivalent JQuery, and a great deal more compact than the equivalent raw javascript), and as soon as there’s a compiler it will be well worth checking out.

Giles Bowkett (note from 2014: if you haven’t already seen it, go watch the video, which is amazing) gave a high-energy performance, demonstrating his Archaeopteryx MIDI software and making an impassioned plea to do what you love and build what you want. Make profit by providing a superior service at the same price point as the competitors: we’re still banging the drum of making your offering less painful than the competition. Also, Leonardo da Vinci was an artist who didn’t ship and so, by “release early, release often” standards, a failure, there were several images of Cthulhu, references to using a lambda to determine which lambda to use (a meta-strategy pattern), and Bowkett’s thought that it was irresponsible in Ruby not to use the power the language gives you. He added that Archaeopteryx may be insane but it’s also great, and “insanely great” he can live with, and that while he may not be able to say (as Jay Phillips used to of Adhearsion) “my career is Archaeopteryx”, being able to say “my career includes Archaeopteryx” is still very good.

Damien Katz spoke about the long and hard road that led to him being the guy building the cool stuff, in his case CouchDB. It felt in part like a counterpoint to Bowkett’s story: took longer to pay off, but he did what he really wanted to do on the chance that someone might recognize it, and pay off it finally did. Katz also noted that while it was easier to get something working in Java than in Erlang, it was easier to get it working reliably in Erlang than in Java.

Reginald Braithwaite spoke about rewrite, which enables rewriting Ruby code without opening and modifying core classes. This makes it easier to scope changes to specific parts of your code. Reg likes the power of opening classes, but doesn’t think it sustainable. If you open a class in a gem, all the downstream users will be affected, whether they want the change or not. Reg also mused on adverbs, like .andand. or .not., modifiers that affect the verbs, the methods, instead of the more usual noun/object orientation. (Reg has since blogged a riff between his talk and Giles’s.)

Tom Preston-Werner spoke about conceptual algorithms, not applied to coding patterns but to higher-level thinking patterns. He gave an extended example of the full circle of the scientific method and its effectiveness in debugging, noting the usefulness of Evan Weaver’s bleak_house plugin in tracing memory leaks. He previewed the upcoming git feature gist, basically pasties backed by github. He discussed some other algorithms more briefly. Memory Initialization starts with disregarding everything you think you know about a problem and working from first principles (it worked for George Dantzig). Iteration is exemplified by the James Dyson new vacuum cleaner design, which after 5126 failures became a resounding succes. Dyson remarked, taking us right back to Nick Sieger’s jazzers, “Making mistakes is the most important thing you can do”. Breadth-First Search relies on the fact that there are over 2500 computer languages, and learning some others just for the different perspective is useful. (He shared a tip from his time learning Erlang and being weirded out by the syntax: just say to yourself, over and over in an affirming manner, “the syntax is OK”. And that helps you get past it and get on to the good stuff.) Imagining the Ideal Solution feels like a cousin of TDD: if you’re not sure how to implement the solution, write out your best case of what the god config file (say) or the Jabl syntax (say) would be, and then proceed to implement that. And Dedicated Thinking Time was an unexpected reflection of a point I first came across in Robertson Davies: it’s important to set aside time for just thinking about things. Sure it’s simple, but it’s sometimes ridiculously hard to implement.

Blake Mizerany spoke about Sinatra, one of the Ruby web app microframeworks, built (in line with Jeremy McAnally’s thoughts yesterday) because Rails was too slow for his needs. He noted some apps in Sinatra: git-wiki (a wiki served by Sinatra and backed by git), down4.net, and the admin interfaces of heroku. He also suggested that for RESTful resources, rest-client (which he called “the reverse Sinatra”) and Sinatra was all you needed, making ActiveResource look like overkill and curl look cumbersome. To complaints that Sinatra wasn’t MVC, he noted that he thought it was, actually, but in any case, insisting on a web framework being MVC felt like over-eager application of patterns instead of starting with the problem. Asked what Sinatra was tailored for, he said back end services or other small bits of functionality. If you’ve got more than a few screens of Sinatra code, it’s probably time to move to another framework.

Leila Boujnane spoke about the importance of being good, and being useful, and making the world a better place by making something that people want. Don’t start with a business model: start by building something useful, and build it well, because a crappy product upsets both the customers and the people working on it. Making the customers feel good about the product is not only good in itself, it’s the least limiting approach, because if your product doesn’t do that on its own you need to cheat or fool people into thinking it’s terrific. In a way, we’re back where the conference started: find a pain point and build something useful to fix it, to everyone’s benefit.

Oh, and the Toronto Erlang group was founded over lunch.

High praise to the folks at Unspace for making the conference happen. It was thought-provoking and loads of fun.

Joey deVilla’s more expansive account: one, two, three.

Jay Phillips talked about Adhearsion, his framework for integration VoIP building on top of and simplifying the use of Asterisk. He noted that it can be surprisingly profitable to find a pain point a bit off the beaten track and fix it. This chimed well with Zed Shaw’s remark from QCon London 2007 that if you want to succeed beyond your wildest dreams, you should find a problem and solve it in a way which is less painful than any of the competing alternatives.

Dan Grigsby noted that entrepreneurship was easier for a developer than perhaps it had ever been, because the sweet spot for team size was about 3. If you’re a really good programmer, all you need on the code side is one or two other really good programmers. This matches Pete McBreen’s point in Software Craftsmanship, that a smaller team of really good people will probably be better and more productive than a larger team. The trick that corporations don’t seem to have solved yet is finding that small great team in the first place.

Grigsby added that a more pragmatic test-driven approach to the developer’s dilemma of picking the winners among all the possible project ideas is to build a whole bunch of narrowly-focussed projects, send them out, measure them to within an inch of their lives, and quickly kill off the failing ones. For a similar amount of effort as honing one or two projects for a much longer period before sending them out, you’re left with a couple of projects that are less well developed but you already know they are successful.

Grigsby’s engaging talk continued into more explicitly market-focused directions, discussing finding hacks in the market for the disproportionate reward, suggesting that there are marketing techniques that match Ruby’s better-known programming claim to 10x better productivity, and that exploiting non-obvious relationships was among them.

Tobias Lütke spoke about memcached.

Yehuda Katz spoke about several neat projects, from Merb and DataMapper (coming to 1.0 this summer so almost no longer Edge-y) to sake (for system-wide rather than project-specific rake tasks), thor (scripting in Ruby), YARD (a neat-looking better Ruby documentation tool), and johnson (a ruby-javascript bridge).

Luke Francl spoke on testing being over-rated. He made clear that testing is great, it’s just that there are a lot of other things we need to do (code inspection, usability testing, manual testing), some of which will find different bugs and none of which will find all the bugs. As he pointed out, you can have the most complete set of unit tests imaginable, and it won’t tell you if your app sucks. Sitting and watching a user interacting with the app may be the only way of being sure of that. Francl also pointed out that in addition to writing code and writing tests, developers are good at criticizing the code of others, and the best measure of code quality may be not rcov stats but the number of WTFs per minute in a code review. And, as a side benefit, knowing that your code will be subject to a code review will probably make you tighten up your code in anticipation. (Francl’s paper was also notable for following the Presentation Zen advice of having clear uncluttered slides and a handout that was an efficient text summary of the presentation that bore no relation to the slides at all.)

ETA from RubyConf 2014: see also Paul Gross’s Testing Isn’t Enough: Fighting Bugs with Hacks.

Nick Sieger spoke about Jazzers and Programmers. Go read his summary and savour the quotations (from a different field but still deeply appropriate) from great jazz musicians. “Learn the changes, then forget them” (Charlie Parker). Or the idea of The Real Book (the body of tunes that all jazz musicians learned and created a shared vocabulary that allowed musicians to play together on their first meeting) as the GoF for jazzers in the 70s.

Obie Fernandez spoke about marketing and practical details of contracts. Not only about accepting contracts but about rejecting them, noting that a key acceptance criterion should be if you’re going to want to show off the project when it’s done and keep it in your portfolio. Following on from patterns and The Real Book, he noted the importance when setting up a consultancy of defining projects and of having names for them, and of writing down your client criteria and acceptance criteria and keeping them constant. Noted Secrets of Power Negotiating, Predictably Irrational, and Seth Godin’s Purple Cow as books to check out.

Matt Todd spoke about the importance of just going ahead and making mistakes and learning from them. (Going back to one of Sieger’s quotations, as Ornette Coleman put it, “It was when I found out I could make mistakes I knew I was on to something.”)

Jeremy McAnally spoke of how we should resist the urge to make Rails do everything, even outside its comfort zone where it would be a lot simpler and more maintainable to, say, just write some Ruby code and hook it up to with Rack. How Rails is designed for database-backed web apps, and taking it outside of its 80% comfort zone, while perfectly possible, may not be the best solution, and if you find yourself in a place where the joy:pain ratio has flipped or where you find you’re writing more spaghetti code to fit the solution into Rails than you would be to write the solution on its own, it’s probably time to switch.

Zed Shaw briefly presented some dangerous ideas and then went on to an impromptu music-making session. He left us with the thought that while he was done with Ruby, he was never going to stop coding, because code was the only artform that you could create that other people could then play with.

Joey deVilla’s more expansive account: one, two.