1. App-specific workarounds: sometimes feasible, sometimes not
2. Local modifications: wherein we dork around with the library code on our end, fix the bugs, and then maintain our own separate branch of the library. These made merging in new changes from upstream fun (in that why was I programmed to feel pain kind of way).
3. Find/Write a replacement: You’d be shocked at how often we didn’t do this. Or, alternatively, underestimated how difficult a particular issue is.

In the last few weeks alone, GitHub’s changed that. Now, the libraries I want are on GitHub as rubygems or PHP tarballs or what have you. And when we encounter issues, the process is smooth:

1. Fork project. GitHub has a button for this.
2. Get our fork, make local changes, commit and push up to GitHub.
3. Send a “pull request” to the original author to let them know we have patches that they may want. GitHub has a button for this.

My contributions are available for whoever wants them.

Now, if the original project checks in a few bugfixes I want, I can cleanly merge them in and keep my local fixes. And if upstream wants my fixes for the “canonical” repository for a project, then they’re welcome to them whenever they like. Git makes the magic happen, and GitHub makes the magic ridiculously easy.

How the hell did we develop software before this?

Kent had pulled some changes from our central git repository to a staging environment. These changes weren’t tested very well in IE6, so he wanted to remove them entirely from the staging environment. In Subversion, we’d have done something like svn update -r120 if we were on revision 121.

After a little digging – Kent says I only roll 3d20 for Source Control now, because we’re geeks – I found that Kent could go into the staging environment and do git reset --hard HEAD^; that is, revert everything in this repository to the state it was in one commit before the current HEAD. Then, after making a second commit from dev and pushing it, we can do a normal git pull and it will fast-forward us to the new commit.

So this isn’t much different from Subversion so far. What you can do that SVN explicitly is designed to not let you do, is use that in your dev environment. If you haven’t yet pushed the changes to a remote repository, you can willy-nilly undo commits you’ve made.

Did you accidentally add and commit a file that shouldn’t be in the repository at all? git reset --hard HEAD^, just like before. Did you commit a little prematurely? git reset HEAD^, which does a soft reset, which leaves all the changes intact but removes them from the repository like they were never committed.

Put that in SVN’s pipe and smoke it.

Their answer is “February”.

Ask PHP: print date('m/d/Y', strtotime('next month')); (In english: PHP, please give me a date that looks like MM/DD/YYYY for next month.)

03/01/2009 (1 March 2009)

As it turns out, like all things with computers, you’re asking it wrong. You should write print date('m/d/Y', strtotime(date('Y-m') . '-01 next month')) which is a convoluted way of saying “Give me a date, MM/DD/YYYY, for next month calculated from the first of this month.”

Okay, but this is a bug, right? I mean, php has a strtotime() function for the purpose of letting people write english statements and parsing them into real time values, and it’s acting incorrectly.

Wrong-o.

According to the PHP devs on numerous occasions this is purely correct behavior, and they even cite the GNU date format documentation as proof:

• PHP says “add one to the month on the date you gave us”
• You get 31 Feb 2009
• PHP says “that doesn’t exist!” and rolls it up to the next available real date, 1 March 2009

Except this is bullshit.

By their own admission (in the second linked bug above), the PHP developers get a bunch of bug reports because this doesn’t work as expected. Waving your hands and pointing at the GNU guys doesn’t make it okay, that’s passing the buck. Pointing back at the PHP manual in your standard form reply to these doesn’t help either: the manual page for strtotime() mentions nothing of how it might not work the way you expect it to.

Lesson to be taken away: if your users think it’s a bug, take a good look at it. It might be a bug.

if (empty(trim($string)))

This will exert a Fatal Error every single time. With a horrible message: “Can’t use function return value in write context.”

WTF?

Sympathizers: I know what you’re about to say. empty() is a language construct that specifically looks at a variable. You just have to assign the trim() result back to a variable first for this to work. If you’d read the manual entry for empty() you’d know that!

Fuck that noise. I don’t care if it’s well documented. I don’t care that technically speaking the empty() construct can only check variables. It does not matter. This is shit behavior.

Sympathizers: grow some balls backbone. PHP sucks. It’s okay to admit it. Yeah, it has some redeeming value, else we wouldn’t be discussing it now. But you’re letting the PHP developers get away with murder here.

PHP Core Developers: Yes, the language you write powers a metric shit-ton of awesome businesses, Innvoa included. That doesn’t give you a free pass to do fucking idiotic things like this. Fix it!

First blood, so to speak, goes to a Facebook App Chad wrote in Rails, but this app is more of a classic pattern for Innova: we get some data from a client, import it into Microsoft SQL Server, and clean things up as we go. These things don’t necessarily scream “Rails,” but she was up to the task nonetheless.

Coming from PHP development, there are several things that rocked my house as I was developing this app, things that our old Zend Framework or PHP simply couldn’t do:

• script/console Being able to spawn an interactive session inside your application’s environment is ridiculously helpful. I had the basic application logic finished the first day because I was able to fire up a console and run some quick ActiveRecord commands to see what worked. And if something broke, I was able to fire up a console and start firing off commands and inspecting results. Much quicker than the var_dump then die style of PHP development we were using.

• Plugins, esp. will_paginate Rails plugins are drop-in chunks of code that give you functionality you didn’t have before. In my case, I needed to paginate a set of database rows, which isn’t the most fun task. After I installed will_paginate, the work was done. I had an easy way to get paginated results from my models, and a one-step way to generate the page selection HTML. A lot of people cry about Ruby’s open classes, but things like this wouldn’t be possible otherwise.

• Routes In PHP, we had to write several library functions to generate URLs for our site, for use in HTML links. Rails’ built in named routes and link\_to helper meant I never had to write any kind of setup code beyond the initial route.

That last one might seem like I’m really scraping the bottom of the barrel, but that’s just one example of a pattern I’ve noticed in Rails. link_to_unless_current is another: \writing a function that either generates a link or some non-link text based on what page you’re on isn’t hard, but since almost every web application does this you don’t have to write it. The number of times I’ve said something like “Crap, Rails has a built-in feature that handles that” or “oh, I just need this plugin, it takes care of it” is really astonishing.