jump to navigation

Is there anybody going to listen to my story…
Saturday, 29 September 2007

Posted by austin in: Personal, 1 comment so far

All about the girl who came to stay?
She’s the kind of girl you want so much
It makes you sorry
Still you don’t regret a single day.
Ah girl! Ffff…Girl!

With Lennon’s “Girl” begins Julie Taymore’s latest film, Across the Universe. The film is visually rich, musically gifted, and utterly confused. Nonetheless, I really enjoyed it.

This movie is divisive, make no mistake. Rotten Tomatoes marks it “Rotten” as of the date of this post, as shown below. Only 51% of the critical reviews are positive. Look at those reviews, though, and you’ll see strong feelings for or against the film.

Across the Universe: 51% / Rotten (Rotten Tomatoes)

Disclaimer: I went to see this movie because my brother’s in it, as a dancer (when Max goes into the induction centre and is stripped to his boxers, Kenneth is the first soldier to Max’s right, and dances behind him; later, he is two beds to the left of Max). I also didn’t pay anything to see it (due to some complimentary—or compensatory—tickets provided by the theatre for a screening of Pirates of the Carribean that was interrupted by a 5-year-old).

I was prepared to hate the film, because going in you know it will take every possible cliché that it can. Despite a very slow start and an often muddled middle with the various characters flitting in and out of the film, the film managed to keep me entertained for more than two hours, and came across as relevant today, at least to me.

This is art, but it’s not high art. It’s candy on the order of Moulin Rouge!, but perhaps not as well executed in the end. Still, if you enjoy the Beatles, enjoy in-jokes, and are prepared to accept a caricature of the 60s (but what movie isn’t a caricature of an era), you will probably enjoy this film.

Update: I have (hopefully) fixed the comment-posting issue.

On Derek Siver’s Return to PHP…
Sunday, 23 September 2007

Posted by austin in: Ruby, Technology, 2comments

Derek Sivers, recently abandoned his CD Baby rewrite from PHP to Rails. This isn’t bad news for Rails or Ruby, nor is it good news for PHP. It’s good news for CD Baby. Anyone who reads it otherwise is missing the lesson.

There are plenty of reasons to dislike PHP (although all of my criticisms have to be aimed at PHP4 right now, as I haven’t done anything with PHP5), but it is a useful general purpose language. It has different philosophies than Ruby, and I think that in general it isn’t nearly as good a language as either Ruby or Python. But it is just fine for a lot of people and projects.

Derek’s planned migration to Rails was probably doomed from the beginning for several reasons:

  1. Derek chose the technology for the wrong reasons. He chose it partially based on the hype of Rails, but he envisioned it as a silver bullet that would magically make his application better just because it’s in Rails. Rails has advantages (not least of which is its language, Ruby), but it has drawbacks and weaknesses, too.
  2. Rails didn’t fit Derek’s application model for CD Baby, and Derek’s application model is more important than the technology to be used, since it represents a business he understands well. Rails requires that your application fits its model, not the other way around. As Derek says:

    I hired one of the best Rails programmers…Jeremy [Kemper] could not have been more amazing, twisting the deep inner guts of Rails to make it do things it was never intended to do. But at every step, it seemed our needs clashed with Rails’ preferences.

  3. He ignored his existing experts for the new technology. Neither he nor his employees knew Ruby aside, perhaps, from playing around with it. This wasn’t a technology that was deemed to be appropriate from experience; this was a technology deemed appropriate by management (sorry Derek, you might still be getting your hands dirty with code, but you’re still management).

    I’ve wanted to introduce Ruby in my workplace for several years, but aside from a number of compile-time helper scripts, it hasn’t been appropriate to do so. First, our product isn’t in Ruby’s sweet spot. Second, none of my co-workers know how to deal with it or its development environment. Even when Ruby is a superior choice, it’s hard to introduce it, because I’m the only Ruby expert at work.

  4. Derek approached the project as a whole-environment ground-up rewrite with a One Big Day deployment, without considering ways to phase it in over time. It’s almost always possible to find interface points where you can replace one broken piece at a time. Ultimately, this is what the Rails folks wouldshould tell you anyway: replace one area at a time, each with a different codebase. Interface them as REST-ful services. Don’t make them depend on a single database schema.

Derek is wrong, though: language matters. A “better” language may not be the right choice for your environment, but its lessons will help you immensely. Without the Ruby and Rails experience, Derek would not have known to apply the lessons Ruby teaches to his PHP rewrite. I find that I write both C++ and C# with strong Ruby flavours these days. My boss, who has only used Ruby casually, has come to prefer the Ruby method naming convention (like_this) and a number of Rubyisms that I’ve introduced.

Ultimately, though, Derek’s Rails rewrite failed because he made a number of classic technology management mistakes. Not because of Ruby, Rails, or PHP. Because of management decisions made for the wrong reasons. Fortunately, he recognised this and was willing to reverse an expensive decision to fit his business better.

Ontario Votes: Voting Format Referendum
Friday, 21 September 2007

Posted by austin in: Politics, Toronto, add a comment

There’s a referendum going on in Ontario on how we will vote in the future. Others summarize it far better than I do:

I don’t think that it’s a bad system, but I am concerned about the reduction in the number of geographically-bound seats (ridings) from 107 to 90; I’d rather see us have 120 geographically-bound seats and an additional 29 “list” seats. I haven’t really decided which way I’m going to vote on it, but I am edging in favour of it.

Still, it’s interesting stuff and if you’re an Ontarian, you really need to vote on this.

Updated 2007.09.24: Added the link to the Spacing web resources for MMP. It’s important to note that MMP isn’t just a random proposal, but something strongly considered by fellow Ontarians.

FogBugz World Tour in Toronto

Posted by austin in: Technology, Toronto, 1 comment so far

So, Joel Spolsky has been making his world tour demonstrating the latest version of FogBugz (6.0), and I was able to attend last night’s demonstration. It was a small pleasure to be able to meet someone whose blog I’ve been reading for several years.

Joel doesn’t present FogBugz as a bug tracking tool, but as a communications tool. FogBugz is definitely an example of opinionated software, and works better when you adapt your work practices to it rather than trying to make it adapt to your work practices. After the demo, I asked Joel how he felt FogBugz and Basecamp work together or differ. His response suggests that there’s some similarities in how the two tools work, although he sees limitations in how Basecamp handles tasks and schedule changes. (Disclaimer: I have not used either FogBugz or Basecamp at this point.)

The software development lifecycle as presented by FogBugz is presented in its five major modules:

Of all of the features that I saw, the wiki seemed the least useful, although the WYSIWYG editor for it was pretty impressive. The value in the wiki is not the editing space that it provides, but that it provides it in the same place as you track your implementation, releases, QA, and support.

The other three pieces are all based around case management. A case in FogBugz can be a feature, a bug, or even a development task. Cases have time estimates and work times that are used in calculating estimated ship dates. FogBugz uses R-squared analysis of a developer’s estimates and actual work time to determine their reliability of estimates, and then runs Monte Carlo simulations to determine when the last feature or bug required to be fixed will likely be completed based on current task assignment, giving an estimated ship date. It’s all very impressive. (Estimates and work times aren’t immune to gaming, but that’s more of a social problem than a technological problem.)

Case entry and management is insanely simple. There are no required fields (which will, of course, bother some people), but it makes adding cases (which are tasks, bugs, and even support requests) dead simple. There’s no implicit dependency tracking, but you can easily link two cases together simply by adding a note (e.g., “waiting for case 72″) and FogBugz automatically provides a link between them. One clones bugs the same way. There’s good SCM integration into FogBugz (including for Perforce), and there’s even a VisualStudio plug-in for task/case management.

The demo was useful to see, but the hard part will be in seeing exactly how it would integrate into work’s development cycle. It’s not that expensive, so it may be worth getting a few licenses (or trying a few months of the hosted version) so that we can see whether it would work for us.