Writing Code is the Easy Part is the new slogan for the website. It basically boils down to the fact that putting up syntacticly correct code is the simplest part of coding. More difficult is solving problems and all of the other things that come with having a job or working for clients.
Here are some of the things that I listed as the harder parts of coding:
Translating Behavior into Code
Finding a Job
Hiring and Firing
Working on Boring stuff
Here are affiliate links to some of the books that I mentioned:
Quick Ruby Tip: The inject method is useful for aggregating data across a dataset. For example a summation could be done with inject (by aggregating each number into the sum.) Download 49.1 MB Download (iphone & ipod) 7.6 MB
Not only can you find a single record by calling find_by_id, you can find multiple records by providing an array of ids.
User.find_by_id([1, 12, 55])
# Returns 3 User objects with ids of 1, 12, and 55. If any isn't found, then RecordNotFound is raised.
2. Locking database records
If you have multiple processes that may update the same record (like incrementing a counter), then you may run into a problem where they both pull the record when the counter = 42. They each update the counter to 43 and save the record. This results in a deviation from reality of 1.
One problem that seems to face people when they’re attempting to move their applications into production is the best way to manage deployment of their application. This is where tools like capistrano comes in.
Capistrano was written by Jamis Buck of 37signals. In a lot of ways it has become the defacto way to deploy Ruby on Rails applications. It has also had tools like webistrano build on top of it to provide a graphical interface to the command line tool.
To get started, you need to install the capistrano gem:
Last week, my development team and I ran across a problem with a library we had written several months before that parsed spreadsheets given to us by one of our clients and inserted the data provided into the database. At the time we weren’t sure what the problem was. We decided to run the tests and two frustratingly useless things occurred. First, all of the tests passed. Second, the test suite took 3 hours to run.
Here’s what we had done in our “unit tests.” We had placed several of these spreadsheets as examples into our fixtures folder. Then, we had created the importer object and told it to import. We then checked the results. These tests take a long time, specifically because an import can sometimes take 15 minutes depending on the amount of data we need to import. So, how do you fix something like that? Here are some ideas.
I just started building a new Rails application in version 2.3.4. One feature that I thought was particularly handy is the data seeding that is now built into Ruby on Rails.
Before this feature, you would have to do one of two things. You could seed your data in your migrations. The problem with this approach is that it clutters up your migrations, and can make for more brittle migrations. It also may or may not propagate to your test database when you run your tests, meaning that if you’re counting on it, it may not bee there.
Your second option was to create fixtures and a rake task to import the fixture data into your Rails application. The problem with this is the need to create multiple related objects across multiple files to make all of your data match up, which can create maintenance problems.
So, without further ado, here is the solution now included in Rails. You simple create a file at db/seeds.rb and place ActiveRecord create calls in the file. Here’s an example seeds.rb. [click to continue…]