Here’s the presentation I did this weekend
Of course, just as I was about to start, my laptop died and refused to start again. Lost me some precious minutes, but fortunately I had a USB key with a backup, and my coworker Alain Ravet lent me his laptop (Julian Fischer also kindly offered, but his computer didn’t like my presentation). Murphy’s law in all its glory. After that, things went more or less smoothly.
If you had the opportunity to attend, I would really appreciate your feedback on speakerrate, as I’m going to give this talk another couple of times. I sensed when it worked, and when it didn’t, but the more input, the better I can fine-tune it.
Time flies, and next week already,
I’m going to talk about how to evaluate a Rails application very quickly: the title of my talk is “12 hours to rate a Rails application”
This is useful in following situations:
- in case of acquisitions (I’ve been asked to look over an application as an outside expert)
- when you’re going to take over legacy codebase
I’m going the extra mile on metrics (or quantitative code analysis), which are excellent tools to judge a large-ish codebase.
Whoo ! Large and interesting subject, all compressed in 45 minutes. A day might come when I’ll be totally relaxed about giving talks, but I’m not there yet. Cross fingers.
“Why do I do these things to myself ?” is a question that came to mind this weekend, during the Rails Rumble. The principle of the weekend is simple: you develop an app in 48 hours, from midnight GMT on friday to midnight GMT on sunday.
Hendrik, Yoni and I came together at the office i share to have a go (Tom helped us for a few hours). Hendrik did the front-end integration, Yoni the design and CSS, Tom is a Rails developer. We’d brainstormed beforehand and came up with a nice and simple concept: Same Same, an application that allows you to create before-after stories with pictures. Loads of potential for storytelling (before-after haircut, after 1 beer, 2 beers, 3 beers, before-after food fight, the stages of pregnancy) .
Well, it took caffeine, chocolate, pizza, blood, sweat and tears, but we made it, goddammit.
- I do my best refactoring in my sleep, or in the shower. None of which were available in any great quantities during the weekend
- Simple is better: in this case, adding more functionality made the application more difficult to understand. We probably should throw out the voting mechanism, and add a big and obvious ‘next’ button.
- Lots of little technical things, like Rails templates I hadn’t used before, jQuery live validation, uploadify, …
What I’d do differently, if i did it again:
- more than 1 (full-time) developer is necessary. You need a pair, or at least someone to do sanity checks – by hour 25 you’re starting to lose your edge.
- Tests: i threw out testing thinking I’d gain time, but I didn’t – test sets immediately show breakages, and these occur even in the most sane situations, which this wasn’t.
- sleep more, like 6 hours in the middle – i slept 3. What you lose in time, you gain in focus. When i woke up on monday, i knew how to solve the app’s most obvious bugs in about 3 code lines … frustrating🙂 No patching is allowed after the 48 hours …
I liked working with Hendrik and Yoni, and I think we made a good team, overall. We should have recorded our conversations from hour 45, it got fairly surreal. It was a good experience, one that, I think, made me a better developer. I’m intending to pick up Same Same later, rework it a little bit and put it online in a proper manner.
Better late than never: if you’re into Rails, but have never had the time to get involved in Rails Core, do participate to the next Bugmash !
Not only was it very instructive, it was also lots of fun, like resolving chinese puzzles in group, and against a clock. The core team members on the IRC channel (#railsbridge on Freenode) made sure you could got an answer to every question. Thanks again to the folks of Railsbridge for organizing the whole thing.
The core team people had singled out a pool of bugs that needed cleaning up or looked at, and had tagged them so they could be retrieved easily. Patches, comments, test sets, all got different types of points. Everyone was pleasantly surprised with the number of bugs processed during the weekend.
I didn’t really see it as a contest, more as an occasion to get involved, so I had a fairly normal weekend, with a dinner party on saturday and a movie on sunday, and I bugmashed on a terrasse part of the time. Still, I was chuffed to land in the first page of results and to get a price (Lighthouse subscription for one year, nice).
So yes, much recommended … after all, don’t you want to know the internals of the platform you’re using every day, and help it evolve ? (some strange and puzzling things in there, let me tell you).
This weekend, we have an unique opportunity to get involved (or attempt to) in the Rails core development: the Rails Bugmash, organized by RailsBridge.
The idea is to resolve as many bugs as possible on the stable version of Rails (2.3.x) – with some assistance of established Rails core members (through IRC on Freenode #railsbridge). A level of playfulness, or competition, is added by the fact that you get awarded points for bug reduction, and there’s a few small prizes. The main prize, in my opinion, is the opportunity to participate to a well-managed open source project like Rails.
A few notes that might be useful:
- I installed a variant of Relevance’s ruby switcher. I’m using zsh myself, not bash: if this is your case, you’ll find the relevant dotfiles in the spicy-code’s repository. Good source of inspiration, but since I’m fairly happy with my configs, I just took over ruby_switcher.rb and ruby_installer.rb. Since I didn’t want to reinstall versions i already had on my machine, I changed ruby_switcher.rb to use the paths of existing installations (look at the update_path function to see what to use) and then i added the following line to my .zshrc .
- To run the activerecord test set, you need a few databases, and a user ‘rails’.
create user rails;
create database activerecord_unittest;
create database activerecord_unittest2;
grant all on activerecord_unittest.* to rails@localhost;
grant all on activerecord_unittest2.* to rails@localhost;
on postgres the grants of course are
create user rails password 'password';
grant all on database activerecord_unittest to rails;
grant all on database activerecord_unittest2 to rails;
Strictly speaking, you need to test on as many dbs at possible – i’ve got mysql, posgres and (duh) sqlite3 – might add the jdbc’s to that list.
You can change configs in activerecord/test/connections/native_/connection.rb . For mysql, I had to add my :socket in there, which defaulted to something strange. For postgres, i had to add user and password (though i suppose you could grant to PUBLIC).
If you want to just test activerecord for one type of database, you go into the activerecord directory, and do
and similar. In fact, it’s adviseable to run ONLY the tests you need at first, because the test set is obviously sizeable, and takes a wee while to run (using env variable TEST=).
Note: I must be missing a grant for postgresql, because i get a load of errors – I’ll update if i fix this Update: i ended up using the superuser.
- You also need to start memcached. 11211 is the default port.
memcached -p 11211 -d
- especially this week-end, i’d do git pull regularly, to avoid surprises.
I really liked Rails Underground, for several reason. First, where some Rails conferences (like last Railsconf Europe) was a bit disappointing in the levels of the presentations, here all technical presentations were relatively advanced.
Secondly, the audience came in a wide range of ages. At the hight of the Rails hype, conferences were attended by a majority of 20-year olds – which is fine, but it’s reassuring when a community contains a good percentage of software veterans, who’ve been around the block and judged that Ruby and Rails is Good Stuff.
And lastly, it was medium-scale – about 200 people. Seems to be an ideal number: there is enough weight to get some big names, and it’s still small enough to have a good atmosphere. You can approach people much more easily. Met lots of interesting people, amongst them some interesting women (!) like Desi McAdam from Devchix, Eleanor McHugh (who always does strange but interesting things with Ruby), Lena from Berlin, Allison Beckwith from Portland.
Rails Underground is proving to be extremely interesting – I’ll do a separate post about the talks I enjoyed later on.
Although to be honest the first day passed in a haze of nerves for me, since i was doing a talk that evening. Note to self: attempt to talk early on.
I had some expert advice beforehand from my friend Baudouin, who’s doing coaching for presentations, which I duly memorized. But of course, once i came on stage, all the good advice went out of the window. I talked too fast, I moved around, I pulled on my shirt, etc.
Well, despite all this, the subject matter seems to have interested people: a surprising number of people came to me afterwards telling me it was inspirational, and made them want to get started themselves ! So all’s well.
The video should be published later, apparently.
Update: the videos are already online ! Impressive.
I made a Rails plugin as a kind of adapter for Tokyo Cabinet. Tokyo Cabinet, apart from having a funny name, is a database engine from (duh) Japan, allowing a few different data storage paradigms.
I got to know it through this post of Ilya Grigorik where he basically says it’s blazingly fast. And when he says it’s fast, I tend to believe him.
So what did I use it for ? I needed to do a multiple shortest path calculation, using the Floyd-Warshall algorithm. I figured storing intermediate results in a Tokyo B+Tree, and table database (for random-length paths) is certainly faster than storing it in your garden variety relational database. It’s definitely slower than doing results in memory … until it isn’t. Storing everything in memory is not a good idea if you want your calculation to be scalable to any size of graph.
I wrote this small plugin tokyo_cabinet4r, which has no greater ambition than to make the use of Tokyo Cabinet in Rails easier, and to a certain extent similar to the use of ActiveRecord (using the Ruby API). If you have any suggestion at all, or you want to use it and a feature’s lacking, let me know. I’ll probably fine-tune and fiddle with it in the next few days, amongst other things.