Fred Hwang pointed to this post by Steve Jones about the problem of the LAMP acronym with Ruby for the language instead of PHP. The problem being that it would be called LAMR.
For those so inclined to drop buzzwords, I think they should call the platform LASR. Just consider the database to be SQL (a compromise between MySQL, Postgresql, and SQLite), and it fits nicely.
Quick tip…
When working on a rails project you need to have REAL DATA to work with in your development environment. The easiest way is to grab data from a production database. Ah, but won\’t that require SQL and effort?
The answer is no. Luckily, 99% of the work involving this is done for you. You will not have to code a single bit of SQL to accomplish this.
Here is what we do here:
So, on my production machine, I do the following.
rake extract_fixtures RAILS_ENV=production
Then I copy the resulting files to my development environment. I then change the data to protect the innocent and avoid leaking any sensitive information. Once that is done, I rename the files over their blank/empty/unused fixtures of the same name (for example mv fruit.yml.bak fruit.yml) and check them in.
Once all the fixtures are sufficiently populated, I then do the following on my development workspace:
rake db:fixtures:load
I have just given myself (and every developer on the team) great test data that is also useful for developing new features. It is just too hard to code new features without real data. For example, that bar chart you are working on will not impress anyone when all the bars are at 0. 
So, again, a few simple,easy steps and significant improvement on the development cycle for all parties.
So I finally have some time to handle a series of posts on Ruby and Ruby on Rails.
I’ve been playing with Rails for a while, at least over 1 year. I like it and I wouldn’t consider using anything else. The framework is well designed. For example, the form editing pattern is just so smart. The code looks simple, but only because the infrastructure was the result of some thoughtful debates. No other framework seems to get this right, out of the box. (In the same way programming languages love to demo the fibonacci code, yet falls apart in a real-world application)
Here are two other observations. The most popular observation is that people are just more productive in this system over any other system. This is a result of the language, the framework, and the best practices for the development environment. One personal observation is that I’m productive when changing older code in the system. The system is easy to navigate and consistent. It doesn’t take long to figure out what the intention was.
Overall, I would highly recommend this environment and will not expound any more on this. Try it out.
Also, although I’ve been productive in Rails and Ruby… I haven’t really known the language. Just recently I broke down and got the book. I know that may sound a bit odd, but the reality is that I could be productive in Rails and with Ruby in a project without really understanding Ruby. This says something about the language.
So, after doing some more generic projects in Ruby, I’ve come around to liking the language. I can be just as productive in that language as I can in Python now. It will be the first choice for any project.
Two other interesting points.
I’ve been getting a bit of flack from some people about the whole being CTO and still doing the coding thing. IMHO, if you have a CTO that can’t code something real and useful, they are too disconnected from reality to be effective.
I’m going to get some of the code I’ve worked on available as open source. It is time to give back to the Ruby and Rails communities.
