• To get query caching to work in console you have to put your code between code blocks.
  
Person.cache do
Person.find(1)
Person.find(1)
end
• You no longer have to do this to cache associations. Rails does that by default now.

The following are some of my favorite parts about the software development methodology known as Agile:

1. Short iterations. By organizing tickets into one- or two-week sprints, you avoid having to cram tons of work in at the end. You're application is constantly progressing. One of our new team agreements is to have a working demo with Selenium coverage at the end of each iteration. With short iterations that goal is infinitely more realistic.

2. User Stories and Prioritizing.  Clearly defining functionalities of your application makes it easier to write the code. It also makes it easier to discuss the relative importance of features. This helps decide which tickets make an iteration and which tickets remain in the backlog. And when you get the sense that you're working on the stuff that is the most important to the application, that makes the work more satisfying.

3. Testing and Behavior-Driven Development. You write a test for a user story. You watch it fail. You write some code to implement that feature. You watch it pass. You repeat. It is without a doubt the most gratifying way I've found to write code yet. You're cranking through tickets. You're bit by bit producing an awesome application. And you constantly see the tests pass so you know the code is safe.

These aspects of Agile make it really fun. It's much easier to be productive and much more satisfying seeing yourself (hopefully) completing your goal every iteration. Iterations are realistic, yet aggressive. In addition, using Behavior-Driven Development you get a little ego boost every time your code makes tests pass. Life's little victories.

Completely unrelated, but check this out:

g-speak overview 1828121108 from john underkoffler on Vimeo.

We here at the community group have committed to the software development methodology known as Agile. Agile makes working in small groups better by, among other things, shortening the development cycle, encouraging knowledge transfer, and offering programming paradigms to make coding more efficient and enjoyable. But Agile is still new to many of us, and we're still experiencing some growing pains.

Pair programming is tough. The idea is simple: two coders working on one machine will produce code in less time that is more bug-free. The reality so far has been that time spent coding hasn't improved much and bug-freeness is arguably worse. Granted, there has been some knowledge transfer (though not nearly enough) as a result of pairing, but all told the process hasn't been nearly as effective as advertised. That being said, we're not doing pair programming correctly - it's impossible to with our group. We have people working on non-project related work. We have people who can't screen share for one reason or another. We have too much work to pair all the time. When we do pair, the non-coding programmer often has their own laptop with them, doing other work (we all have too much); they aren't always actively participating and keeping an eye out for inefficiencies and buggy code. But I also believe we the coders aren't solely culpable.

The scientific evidence backing pair programming is shoddy at best. Also, the learning curve is steep, and the potential gains are not necessarily worth it. Personally, pair programming still feels weird to me. Often I find myself just watching someone code. Usually it's with Cody who happens to be an excellent, dare I say expert, coder. So while I've definitely learned a lot pairing with him, I've only really caught typos watching him code. I haven't seen any glaring bugs in his code, nor any glaring examples of inefficient code. And I don't want to speak for him, but I think for the most part the experience for him has been similar while watching me code. So is it worth it to lose the code we could be producing separately in order to have us sitting together watching each other code? I'm not sold that it is.

Behavior Driven Development with RSpec is a programming paradigm our group has made a priority. In a nutshell it involves writing specs first, defining how your program should behave, making sure they initially fail, and then writing the code to make them pass. Henry and I used RSpec and BDD when building Envoy and it was really, really fun! We produced an extremely lightweight, yet powerful, application with 100% test coverage. And as is mentioned by BDD supporters everywhere, the psychological boost you get from seeing your tests pass as you're coding (using autotest) is not inconsequential. Every time that autotest goes green your pride gets a little boost. But BDD is also not without its problems; namely, doing it. Our group is having an awful time getting itself to write tests for its new code, partially stemming from our existing projects having very little test coverage (which I assume makes us subconsciously ask, "Why start now?"). And RSpec is fairly difficult to learn. There are the Peepcode screencasts. And there is an upcoming book - we really need this David! So hopefully as we get moving on to new projects our test coverage will consistently be at or near 100%, and we'll all become comfortable with Behavior Driven Development as a programming style.

In addition to these two coding factors, Agile as a group and project management style is a little too touchy-feely for me We have weekly meetings where we thank people and reflect. I could see the guy in this video liking it a lot (and I pick this video because this is my favorite Gilberto Gil song and I'm mildly obsessed with Brazil). It often feels excessive and over-the-top. Maybe if we had longer iterations - 2 weeks (1 month?) instead of a week - retrospectives wouldn't feel like such a drag. And perhaps as we move onto bigger and much, much better things that feeling will subside.

But Agile has some good parts. I have no qualms about User Stories, which are an extremely effective way of organizing project features. Due to my overwhelming competitive side, I of course like the point system aspect of Agile. Although with that there is the danger of becoming a workaholic. I like it when Ed, our boss, gets involved with projects as a pseudo-product owner. I think it brings an interesting perspective on the work we're doing. So while overall I have a sincere fondness for most of Agile as a programming methodology, some of it is either detrimental or superfluous to our group's ability to produce good code efficiently and many of the parts that aren't are a pain to adopt as part of our group's official programming and management style.

Version 3.1.1 has been released. There a few cool improvements such as auto-reloading when .autotest is updated and git support, as well as a whole mess of stuff that I have to assume are improvements. Full text of the update here:

http://blog.zenspider.com/2008/10/zentest-version-3110-has-been.html

We'll be implementing some of these features in Fan Profiles to make Flash messages more useful and to further split logic out of views and into the model layer.

Here's the episode

Alex Iskold's really cool list of the Top 10 Concepts That Every Software Engineer Should Know has completely whetted my appetite. Add Flex and Open Social development to this list and that's like the next year of my life. Hell yea.

Just came across this awesome post that describes how to fix an annoying bug with autotest that causes it not to show up like half the time. I hated having to go back to the terminal whenever growl didn't popup; every time it was another half second of my life wasted. I must've wasted upwards of 3 minutes because of this bug. I could've killed like 3 level 11 Goretusks in that time (just started playing WoW - level 15 Human Lock, username merckens, keep an eye out for me - I'll be the guy dominating everyone). If you've noticed this problem with your autotest-growl interaction, read the post. Worked for me.

Rails has come a long way quickly, but one of the biggest problems with our favorite MVC framework is support for multiple databases.

Sure you can use self.table_name and/or establish_connection to force a model to point to a table in a different db, but try running a freaking test with fixtures for the offshoot models, and you'll see what I'm talking about.

Even more depressing is SQLite3's lack of cross-database query join support, making this statement impossible:

has_and_belongs_to_many :blocked_users,
:class_name => 'User', :join_table => :blocked_users,
:foreign_key => "user_id", :association_foreign_key => "blocked_user_id"

Here's the kicker: All of our apps are multi-database apps, so that means no more SQLite allowed for us, and I really loved it until now.

If I'm wrong, let me know. I'd love to go back to using SQLite for local development. Same for an easy way to load fixtures.

I love this: Reddit, Stumbleupon, Del.icio.us and Hacker News Algorithms Exposed!

Reddit's algorithm is probably my favorite, using logarithms to weight earlier votes more heavily. Although I do enjoy the StumbleUpon "safety variable" (which keeps it from being totally gamed). And the del.icio.us algorithm is kind of remarkable in its simplicity. As Danny says though, the "10,000 Pound Gorilla in the Room" is of course Digg's algorithm, which is stored in a single machine buried 5 miles below the surface of the Earth.

Opened up irb and had a little fun this morning:

%w(good morning dary).each {|w| system("say -v Victoria #{w}")}

Awww. Good morning to you too Victoria