I recently read Refactoring in Ruby. There were several things I really liked about the book and one flaw that caused me some problems.

The first thing I liked about the book was the way it pointed out code smells and how to identify them. I found several things that really affected the way I code because I recognized that I implement several of the code smells routinely in my own code. This part of the book was very clear and in my opinion alone made it worth having.

Second, the exercises are top notch. They make you think about the code you need to refactor. They also help you visualize or actually complete the changes that need to be made to the code.

Finally, it made me think about how I implement code in the first place. This is related to the first point, but there I’m talking about the mistakes I’ve already made, or at least the smells in my existing code. In this case, I’ve already approached a couple of problems only to see that there was a better way due to the principles behind the code smells.

The only problem I had with the book was that it seemed to rely on other literature to define the solutions. It would give an explicit name for the refactoring that needed to take place, but wouldn’t explain the process. Now, in most cases, you could guess from the name what the steps for refactoring might be, but this was not always clear.

Overall, I feel like the book is a great resource if you’re looking for exercises to make your code better or if you want a compilation of common code smells in Ruby. Just make sure you’re willing to look up the refactorings that are named but not explained.

books, code smells, refactoring

I’ve decided to merge http://charlesmaxwood.com with http://railscoach.com. The efforts on both sites seem to run in parallel with one site providing audio content in the podcast and the other providing content in test.

I feel like I can then focus all of the great stuff I’m doing on this one blog. This provides you a one stop shop and allows me to use this great layout created by Brandon Buttars.

Please feel free to give me feedback on this change.

Also, if you’re consuming the RSS feed, you may need to switch over to use the RailsCoach feed as I’m going to merge the feeds as well.

I started reading ActiveRecord::Base a few days ago and found 8 things that I didn’t know about that it offered. I also only made it about 1/4 of the way through the code. Here are a few new things I’ve learned upon further reading:

1. Find by multiple ids

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.

The solution is to lock the record while updating it. Here’s the code: Read More

activerecord, data, Database, development, Rails, Ruby, Ruby on Rails

I’ve been trying to read more code lately and figured that I’d be best served by reading code I use frequently. Here are some notes of things I gathered from reading the ActiveRecord base.rb file.
Read More

activerecord, api rails base query attributes

At work, we recently got all of our spec passing and determined that we needed to stay on top of keeping the test suite updated so that we knew that the quality of our product wasn’t compromised. To solve this, we implemented continuous integration with CruiseControl.rb.

Continuous Integration

The idea is to provide regular checks on the quality of your code. In our case, this means running the RSpec tests we’ve written for our Ruby on Rails application. Each time we commit to our git repository, CruiseControl connects to the repository and pulls down the latest code. It then runs all of our tests to let us know if anything has been broken in the latest commits. It provides a visible check to the entire team letting us know if someone committed broken code.

Read More