David Bolton Strikes Again

Last month, I gave a talk at the Ruby on Rails Oceania (RORO) Sydney meeting about a charity that a good friend of mine is involved in, Crossroads.  They’re based in Hong Kong, and began moving their systems to Rails earlier this year.

So I’ve acted as a facilitator in trying to get a few local Rails developers together to do some charitable work for Crossroads.  Last night we had our first meeting, and all systems are GO!  We’ve decided provisionally to meet perhaps one day a month to work on some Crossroads code.  As Matt from Crossroads says, the help we can give is very highly leveraged in that every hour we volunteer is actually worth many times that, since we will be helping create more efficient systems for delivering tens of thousands of tonnes of charitable goods around the world each year.

This is the beginning, and I hope to report back in the future with news of some very good and useful work done for our friends in Hong Kong.

Great quote from Steve Yegge (in a much longer transcript on javascript):

JSON and XML are muscling in on each others’ space, and there are bristles, OK, and it’s so silly! It’s silly. The whole thing, right? I mean, XML is better if you have more text and fewer tags. And JSON is better if you have more tags and less text. Argh! I mean, come on, it’s that easy. But you know, there’s a big debate about it.

I’ve just made my first contribution on GitHub:

http://github.com/lightningdb/activescaffold/

Basically, I forked Active Scaffold, patched it to work with Rails 2.1, and committed back to GitHub, then sent out “pull” requests to others with related forks.  Now I’ve been notified that my patch has been pulled into other forks, excellent!

Getting my head around Git hasn’t been a priority, but even with my scant knowledge, this was relatively painless.  And colloborating on GitHub (even from my early impressions) just seems so natural and easy, even brilliant.

For a trip down memory lane, Jeff Atwood’s latest blog post about growing up with BASIC is a must read.

I grew up with GW-BASIC in the mid-80s.  I loved programming, and I actually made some reasonably complex software.  I’m convinced the accounting software I created was what landed me a scholarship to a prestigious private school here in Sydney.  Other software: a graphics program, many, many games (culminating in a loderunner type game with *a level designer*), a text editor and many others.  I even built an interpreted language *IN BASIC* (these days the cool kids would call it a DSL, and yes, I was crazy and young).

There’s an interesting article on running Rails on Glassfish and why this could make sense for you. And it’s an easy sell to me: one of the things that bother me most about Rails is resource usage, so database connection pooling is an instant winner in my book. But I’d love to know more about the performance characteristics of such a setup.

Ideally I’d have a few hours on a weekend to play around with Glassfish and Rails, but the coursework for my Masters is starting to bite. Maybe in a couple of months…

I wouldn’t normally participate in this sort of thing, but …

64 ls
62 svn
41 cd
40 rake
39 rdebug
24 ss
18 exit
17 rm
17 ./script/server
15 cap


I really should alias cd & ls together huh

Further to my post about AMC using Rails, here is a comprehensive post on where Rails is being used in large companies, from Obie Fernandez.  Also, buy Obie’s book on Rails, it is very, very good.

The Australian Medical Council is now running systems on Rails. (via Rex Chung)

Cedric Beust has written a well considered counter to TDD extremism.  He is right in that TDD can seem compelling when writing simple class structures, but that it can become a hindrance when coding more complex cases.  The argument to that, of course, is that TDD will help refine your API and integration points, but I think the point really is that it’s perfectly possible to have an elegant interface without TDD.  As Cedric says, TDD should be considered simply one of an array of tools.

Cedric’s “rules of thumb” are good:

• “Tests first” or “tests last” is unimportant as long as there are tests.
• Try to think about testing as early as possible in your development process.
• Don’t let one liners contradict your experience. For example, don’t listen to people who tell you to write “the simplest possible thing that could possibly work”, also known as YAGNI. If your experience tells you you’re going to need this extra class in the future even if it’s not needed right now, follow your judgment and add it now.
• Keep in mind that functional tests are the only tests that really matter to your users. Unit tests are just a convenience for you, the developer. A luxury. If you have time to write unit tests, great: they will save you time down the road when you need to track bugs. But if you don’t, make sure that your functional tests cover what your users expect from your product.
• Don’t feel bad if you are not doing Test-Driven Development. There are a lot of factors that make this practice a bad fit for a lot of projects and developer personalities (aspects which are very often never mentioned by TDD extremists).

I’m not at all against TDD, and indeed, I use RSpec with Rails consistently before coding implementations, but the point is let’s not get fanatical about this.  It’s not a cure-all.

Okay, I’m out of net contact (and thus svn repo contact) for the next three days — what better opportunity to try out Git? I hear about it constantly, and I’m starting to tear my hair out with waiting for svn commits.

But installing git and the git-svn tool on OS X appears to be problematic. Everyone seems to have their own magic voodoo to make it work. And in this regard, I’m no different. I had to blend 4 different recipes to get it going.

Here’s how I did it:

1. installed subversion and it’s language bindings from http://downloads.open.collab.net/binaries.html
2. built expat and git from source:
   
   curl -O http://surfnet.dl.sourceforge.net/sourceforge/expat/expat-2.0.1.tar.gz
   tar xvzf expat-2.0.1.tar.gz
   cd expat-2.0.1
   ./configure --prefix=/usr/local
   make
   sudo make install
   cd..

   curl -O http://kernel.org/pub/software/scm/git/git-1.5.4.tar.gz
tar xvzf git-1.5.4.tar.gz
cd git-1.5.4
./configure --prefix=/usr/local
make
sudo make install
cd ..


3. To remove an error about “can’t find SVN/Core.pm”, I added /usr/local/lib/svn-perl to $PERL5LIB.

And the litmus test is:

git-svn --version

Now, peepcode screencast in view, I start in the git world. How excitement.