RFCs

For a good long while, my fellow developers and I excelled at being our own worst enemy.

Our teams had silo-ed themselves off quite effectively. It reached the point at which almost no inter-team communication took place. Any inter-team email had a better than even chance of inciting a flame war. Inter-team talks consisted mostly of just that—talk—and very little listening.

The worst part about the silos was that several silos worked on the same codebase and would routinely trample each others' code or introduce a plugin/gem that broke the application for everyone else. And then we had flame war.

I do not think that is an exaggeration. It was not that we hated each other. It was more that we lacked respect for each other.

And then I read Stevey's Blog Rant about Rhino on Rails. About half way though the rant he mentioned that, at Google, any significant piece of code requires a design document to be signed off on by two reviewers of your choice.

Now, we are by no means Google. Moreover we have little hope of becoming Google by emulating everything we know about Google. That would be like trying to reproduce the elegance of a 37signals design by repeating steps. It is not a checklist, it is an attitude.

Still, the idea of reviewers for new ideas seemed like it might help to resolve many of our problems.

We structured the Request For Comments process such that:

• all significant, developer driven changes had to go through the RFC process


• it had to be publicized so that all could add comments (though only two had final say)


• it had to be completed between 2 & 5 days (to allow adequate discussion, but to ensure that things did not drag on indefinitely)


• both reviewers had to be from a team other than your current team

Immediately, we stopped introducing new plugins before first ensuring that everyone was comfortable with them.

The more import result of the process was brought about by the last bullet point—no one could rubber stamp an RFC by having her or his team approve it. All RFCs had to gain approval from outside the team. That meant, if you wanted to get something accomplished, you actually had to talk to others.

And the beauty was, if we actually listened to each other, it turned out that everyone on the other team wasn't a flaming asshole after all.

ISO 8601 is the Only Date Format

I hate dates.

I hate having to convert between dates and times. I hate date calculations (stupid leap year). I even hate date formatting (why must every client have their own preferred format?). Dates are just plain messy.

ISO 8601 (a.k.a. YYYY-MM-DD) eases the mess.

Quick question: what day of the month are the following dates representing?

1. 2009-01-09 20:18:53
2. 20090203181210
3. 02/11/2009
4. Mar 2, 2009

Either #1 or #4 yield quick, easy answers. Sure, you can figure out #2 with a little work, but why work for simple answers? Format #3 is hopeless because the answer depends on who you ask (and where they're from)—some (mostly to the left of the Atlantic) will insist that the answer is the eleventh day of February, while most others will answer the second day of November.

Follow up question: how would you sort dates in each format? For either #3 or #4, you first need to convert to an internal date representation before comparing. Either #1 or #2 can be compared with no conversion. The string "2009-01-09 20:18:53" is less than "2009-02-08 00:12:30":

>> "2009-01-09 20:18:53" < "2009-02-08 00:12:30"
=> true

The comparison holds true in any language that supports strings (so pretty much every programming language ever designed). Consider javascript:

if ("2009-01-09 20:18:53" < "2009-02-08 00:12:30") alert("yup");

Hell, it even works in fake languages like XSL¹.

Another important benefit of ISO 8601 is its ease of conversion to native date format—simply split on dashes. This makes it ideal for a simple yet robust data interchange format.

So format #1 (ISO 8601) is easiest for human readability while still making for simple comparisons and conversions. Ease and simplicity always trump any other concerns.

Ease and simplicity == fewer bugs.

Ease and simplicity == more maintainable code.

I am not arguing that dates should be ISO 8601 no matter what. In the final UI, go with whatever localizes best. But until design aesthetics become significant, ISO 8601 is the format.

Client wants mm/dd/yyyy in a CSV dump? Tough. It lacks readability and can not be easily compared.

Want to save space in a DB string field by dropping the dashes? Wrong. It lacks readability.

Think sticking with the application default of Mon D, YYYY is good for consistency? Consistency, when adding complexity, is the bane of application development.

Always strive for simplicity, for maintainability. In 6 months, which is the easiest for you or another developer to grok? Which is the least likely to cause bugs down the line?

IS0 8601 is the cleanser for life's messy dates.

---

¹ Just because I have this lying about, in XSL:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                version="1.0">

  <xsl:template match="/">
    <results>
      <xsl:apply-templates select="results/result">
        <xsl:sort select="date" order="descending"/>
      </xsl:apply-templates>
    </results>
  </xsl:template>
</xsl:stylesheet>

Logrotate

Because I am too lazy to run

rake log:clear

I created /etc/logrotate.d/repos with these contents:

/home/*/repos/*/log/*.log {
  daily
  missingok
  rotate 3
  compress
  notifempty
}

All of my projects (rails and otherwise) are in the repos directory of my home directory.

Quick summary of the options: rotate every day, do not worry if there are no logs, keep a compressed, daily log about for 3 days (just in case), do not bother rotating if the log is empty.

Makes for quick acks (--thppt) without having to something else first.