Posted by Eric Stewart
Fri, 02 Dec 2005 01:43:00 GMT
You have set up your shiny new Rails application, written some code and are ready to play. You fire up script/server and point your browser to http://localhost:3000 and all is well. Now time to put it on a real server and let the hordes have at it!
You choose your webserver of choice, configure it, and choose the appropriate dispatch.x script to launch it. But when you point your web browser at the new web server you get some useless error or blank page.
Luckily checking the web server logs shows that the code loading Rails isn’t happy. Not happy at ALL! But, it’s some crazy error in code_generation.rb:68 that everyone was talking about a month ago. You are running the latest Ruby 1.8.3 however, not an older version of 1.8.2. What gives? ! ? !
Trying to run the dispatch scripts directly is worse. All you get is a dry Status: 500 Internal Server Error and no log messages. A lot of help that is!
Somehow you trudge along and remember that you changed the shebang lines your dispatch scripts to point to #!/usr/bin/env ruby like a good little unix scripter, because that’s the proper thing to do in most cases. Apparently not in this one.
You change the shebang line to reference your specific version of Ruby and try again. All is well. What’s a few lost hours of frustration?
Next time, check the least intuitive thing first!
Posted in Software Development, Ruby On Rails | Tags rails, ruby, tips | no comments
Posted by Eric Stewart
Thu, 29 Sep 2005 14:17:00 GMT
For several months now I’ve been working on a RubyOnRails project for a client with my cohort Brad. Though I had been experimenting with rails prior to this project, this is the first commercial project with the framework that I have done. And we all know how that’s where you learn the true strengths and weaknessess of a framework. I’ll be adding tips and observations from this project and wanted to start with a simple one.
Fixtures suck! And they are fantastic all at the same time. Coming from a background of heavy unit testing (we’re JUnit junkies) the concept of fixtures is a very welcome feature. I can’t ask for an easier way to write tests for a database backed application. However…..
It’s way too easy to spend a lot of time trying to get new tests working only to find you aren’t including the right fixtures in your test. It’s something that should be trivial, yet we have tripped on admittedly way too many times before developing the right habits.
The lesson that newcomers to Rails can try to learn is that it’s easy to forget new fixtures that need to be added, especially when adding new tests to existing unit tests and the functionality you are testing involves that new table you just added. When things don’t seem to run just right (tests) and you can’t figure out why, check your fixtures.
Posted in Ruby On Rails | Tags rails, ruby, tips | no comments
