Yehuda's GoRuCo talk was on the subject of Rails as a Ruby citizen - that while Rails was already a pretty good Ruby Citizen with 2.3, 3.0 is about making it a better citizen.

Ben Stein of Mobile Commons is giving a talk on Cross-platform Mobile App development. They hadn't done any client mobile work, but lately clients have been asking "what about iPhone?," "what about Android?" and the like. Whether or not this question of navigating the mobile client world is important to you now, Ben predicts it will soon be, as that's where we're headed.

Thoughts and experiences from Mobile Commons' first mobile client apps:

Jake Howerton gave a GoRuCo talk about Rails Anti-Patterns, drawn from his years as a rails developer.

Over lunch with Jake, I'd wondered aloud "where are all the wide-eyed optimistic presentations?" and Jake starts by saying he's sorry that this will not be one of those talks.

We've been programming in Rails for several years now, and now more than ever we're left with the problem of how to deal with, maintain and correct projects which may be riddled with out-dated thinking, mistaken ideas and problematic implementations.

In other skilled enterprises there are core ideas which are repeated by for practice and for their general utility. In martial arts, these are called "katas," in programming, we have "patterns." Patterns are general, reusable solutions to common problems in software engineering, which are often arrived at through emergent design. Anti-patterns, likewise, emerge in the general work on a project, but their presence is harmful. They're the mistakes we make again and again in our projects.

Jake then laid out a few patterns and anti-patterns for your consideration:

I came across an interesting post on Overcoming Bias today about the Planning Fallacy. In short, the evidence shows that individual predictions generally occur in a rosy inaccurate world where everything goes according to plan, even when interruptions and setbacks are inevitable:

Buehler et. al. (1995) asked their students for estimates of when they (the students) thought they would complete their personal academic projects. Specifically, the researchers asked for estimated times by which the students thought it was 50%, 75%, and 99% probable their personal projects would be done. Would you care to guess how many students finished on or before their estimated 50%, 75%, and 99% probability levels?

• 13% of subjects finished their project by the time they had assigned a 50% probability level;
• 19% finished by the time assigned a 75% probability level;
• and only 45% (less than half!) finished by the time of their 99% probability level.

As Buehler et. al. (2002) wrote, "The results for the 99% probability level are especially striking: Even when asked to make a highly conservative forecast, a prediction that they felt virtually certain that they would fulfill, students' confidence in their time estimates far exceeded their accomplishments."

But it seems one can overcome this bias towards optimism by getting an "outside view" on the problem as it relates to the timelines on previous similar projects:

Buehler et. al. (2002), found that Japanese students expected to finish their essays 10 days before deadline. They actually finished 1 day before deadline. Asked when they had previously completed similar tasks, they responded, "1 day before deadline." This is the power of the outside view over the inside view.

So there is a fairly reliable way to fix the planning fallacy, if you're doing something broadly similar to a reference class of previous projects. Just ask how long similar projects have taken in the past, without considering any of the special properties of this project. Better yet, ask an experienced outsider how long similar projects have taken.

Pivotal Tracker, unlike other project management software, is built on exactly this idea of the outside view, via points and emergent iterations:

Tracker calculates future iterations based on historical performance. Focus on prioritizing and completing your stories; let Tracker take care of planning future iterations, based on actual progress.

It's gratifying to see that the emergent iterations are not just easier for the user, as there's no need to manually specify them - they're also more likely to be accurate, as they're based on an external view of your own progress. Yet another reason to look to Tracker for your project management needs.

A problem I had as a git newbie, and one I've seen others struggle with, is the problem of how to conveniently stage the deletion of files which are already deleted from disk, but aren't yet reflected in the index? That is, without 'git rm'ing them one at a time or using some other hack (e.g. 'git ls-files --deleted') to do so.

The answer is 'git add'

Recently, one of the Pivots was called out for that civil duty of jurification. That is, he was called to sit and decide on trial.

Now, my only interaction with juries thus far has been to watch depictions of them in media, but while many seem to speak about trying to get out of this duty, I think I'd consider it an honor. It seems to me that being the victim or accused in a crime is a time of extreme need - we know that it has happened that the wrongly accused have been found guilty, and likewise, that guilty have gone free - and while no system is perfect, one of the few protections against these outcomes is the presence of a discerning, unbiased jury.

As such, I'm glad to know that a Pivot was out there, doing their civic duty, and I'll be happy to do the same if the occasion arises. But the interesting thing which came out of this were his requests at Standup one morning: that there's a duty non-jurors have to jurors over the time of the trial. Which is,

• not to ask about the trial: Jurors are asked not to speak about a trial to protect the decision-making process from undue influence. There are strict rules about what evidence is admissible in a court-room, to protect one side or the other from presenting faulty evidence such as hear-say. Discussing the trial introduces the risk of improper influence, and it's best to respect the process by leaving the subject aside.

• not to joke about the trial: Trials range from the frivolous to the truly weighty, and jurors are sometimes asked to shoulder an intimate knowledge of event not discussed in polite company. Also, the consequences of a jurors decision are serious and not to be belittled. It's best to avoid making light of the situation.

So keep these in mind, the next time a friend or colleague serves on a jury; it's a serious act for which they deserve your deference and respect.

Old Version Woes

At standup today, it's been reported that Hpricot 0.6.161 doesn't work on our Windows VM sandbox setup, while the newest version: 0.6.164, is just peachy. So watch for this and perhaps get to upgradin'.

Likewise a bug in Rake 0.8.3 breaks our CI behavior, but is apparently solved in the 0.8.4 release candidate, a.k.a. 0.8.3.99, which can be found on Jim Weirich's github.

So that's it for now. This is one of the hazards and boons of the world of fast-moving open-source projects. Bugs happen, as in all software, but they seem to be solved quickly, or else there's always room for you to dig in. So be aware and look out for the next version!