If you develop in Rails you know that the current defacto setup runs with Sqlite3 for the database. This helps create a nice, light environment for developing. However, in a recent deployment of a rails application, I found an inconsistency between our development database of Sqlite3 and our production database, MySQL. The problem came when trying to store the info entered into a datetime field, using the CalendarDateSelect plugin, which is a really sweet little plugin for, you guessed it, selecting the date (and time) from a small pop-up calendar.

CalendarDateSelect dropped values like “June 13, 2008 1:30 AM” into my associated text_field, which, unaltered, MySQL apparently hates to accept as a valid datetime value.

The frusterating part is that Sqlite3 has no problems with this format. This doesn’t sound like a huge deal, but when you deploy an application that is flawless on your development machine, you sort of expect it in production as well, and when suddenly, the additions you are making to the data in your application are suddenly devoid of the date and time you’ve selected when you created it, panic begins to ensue.

Trouble shooting errors like this are not easy in a production environment when changes to the app code require a reboot of the server to be seen. This led to many a harrowing hour trying to understand why this value is no good.

Eventually, a Google search revealed that simply appending .to_s to the value in the controller before saving the record, fixes the problem.

1
2
3

topic.start_time = params[:topic][:start_time].to_s
topic.end_time = params[:topic][:end_time].to_s
topic.save

We’ve since made a rule to develop our applications in as close to the same environment that they will encounter in production, which means switching to the more robust MySQL.

Well, I don’t know what the word means, but Heroku is a gift from heaven.

Heroku is an online, full stack, IDE for developing Ruby on Rails applications. Yes, that’s right, I said online. It has a code editor in which you can view and edit all aspects of your Rails application. It has built in scripts, such as rake and generate. Best of all, your Rails application is already deployed to Heroku servers. This means you develop and view from anywhere.

Let’s say you go and visit your mom on the weekend but her house is soooooo boring and you are wishing you brought your Macbook Pro 17 with you so you could tinker with your latest Rails app. Well, hop on her Pentium III running Windows ME (remember the one you set up for her when you were in highschool?) and log into your Heroku account. Develop away.

And what could be better for testing. Are you the unlucky developer who just upgraded to Vista and you want to test your application in IE6? Grab an old machine running XP and IE6 and log in.

Where Heroku really comes in handy, for me at least, is the ability to allow collaborators edit access to your projects. This way you can edit away and view all the changes that each collaborator has made before committing.

If you develop Rails applications, you have to check it out.

Well, while working on a Rails project recently, I was implementing the attachment_fu plugin, which, as you may or may not know is an ultra-versatile file upload plugin used widely for adding images to various Rails applications.

The anomaly came when, for reasons to still be discovered, after submitting the form containing a file to be uploaded, the ensuing page broke, giving a “page cannot be found” type error; just like as if you were to open a web browser but are not connected to the internet. The strange part is that it was only happening in IE 6/7 and Safari. Firefox and Opera worked fine. The other strange part is that, though the page broke, the upload still completed perfectly. That is to say, the file was saved to the correct location, and the details in the form were saved to the database, this tells me that my controller is operating normally, but for some reason, when doing the redirect back to the upload page, the server balks.

This app is being developed in Rails 2.02, Ruby 1.8.6, running Mongrel 1.1.4 and Sqlite3, and I’m still banging my head against the wall for the fix. No luck so far but I will update as soon as I find one.

***Update: Well, here it is. It was the simplest problem in my code that cause the error. I got all hung up on the seeming incompatibility issue with the browser and I overlooked the solution by a mile. Rather than typing it all out again, I’ll just link you over to the long story.