A Fresh Cup is Mike Gunderloy's software development weblog, covering Ruby on Rails and whatever else I find interesting in the universe of software. I'm a full-time Rails developer and contributor, available for long- or short-term consulting, with solid experience in working as part of a distributed team. If you'd like to hire me, drop me a line. I'm also the author of Rails Rescue Handbook and Rails Freelancing Handbook.


A Fresh Cup

Notes on Rails and other development


Double Shot #416

Sent most of yesterday deep in the Rails core code. Hopefully some patches will come out with me when I emerge.

  • Scrap - Rails Metal endpoint that tracks garbage and memory-related metrics.

  • Default Scopes and Inheritance to the rescue - And you thought there was no need for pure Ruby inheritance on AR classes.

  • Rails Searchable API Doc - Another version of the Rails RDoc, this one with some interesting search tools.
  • Tuesday

    Double Shot #415

    As spring sets in, the garden is trying to call me away from my computer.

  • Rails 2.3 Dictionary
    - Priit Haamer has released his OS X dictionary version of the Rails RDoc, updated to the latest.

  • Using default_scope to recreate acts_as_paranoid in ActiveRecord 2.3 - The result being an is_paranoid gem you can use.

  • TwitterAuth: For Near-Instant Twitter Apps - A useful gem/plugin for Rails applications wanting to work with Twitter.

  • Introducing HTMLEdit… errr, Espresso 1.0! - MacRabbit's new HTML development tool is released.

  • Django 1.1 beta released - That other web framework is moving along.
  • Monday

    Batting Clean-up

    I've spent a lot of time over the past few years working with Rails projects that were written by other people. Sometimes I've come on as a subcontractor to an existing codebase, sometimes I've taken over when another developer got bored or fired, sometimes I've been asked to do a code review.

    Over the course of these engagements I've come up with a strategy for getting up and running on a new-to-me Rails codebase quickly. There aren't any hard and fast rules; there are still a lot of variable factors. But overall, I find these guidelines useful:

    Start in environment.rb and figure out which version of Rails the project needs. In my case, I'm working with everything from 1.1.6 to at the moment, so using gem Rails is pretty much a non-starter. If a project doesn't have vendored Rails when I get it, it will as soon as I figure out what version it wants to see. If you do vendor Rails into a shared project where others are working with gems, don't forget to .gitignore vendor/rails.

    Next I look at bringing the database up from scratch. If at all possible, I ask for a copy of a current production database to avoid doing this. If I can't get one, I'll start by running migrations, just to see whether the migrations have been maintained. If migrating from scratch blows up, there's always schema.rb.

    Next comes searching the code for require to see if I can figure out what gems the project needs (in rare cases, there are gems specified via the gem.config route, but so far I'm not seeing much of that). I install and upgrade any gems I can see as required, and then try to actually run the project via script/server. Usually this fails a few times as I discover missing dependencies, but I like to give it a few tries so I can have the code up and running while I explore it.

    I spend a few minutes exploring vendor/plugins to see what non-gem plugins the project depends on as well. If it's using any that I'm not familiar with, I check out the readme - assuming there is one.

    With the app running, I turn to the MVC heart of things. Here, the models are my first stop. If there are a reasonable number of models (say, anything under about 30) I just start at the top and look at each one, making particular note of association declarations. I haven't found an automatic ERD tool for Rails that I like, so I use this information to sketch out an ERD by hand, sorting out how the major entities connect to each other.

    Next for me is routes.rb. Looking at this file is usually a good way to judge the sophistication of the previous developers. It also gives me some URLs to try out on the running code to see what happens. After I understand the basic routing, I'll spend some time in controller code, looking to see if it seems unduly fat or otherwise confusing.

    Finally I'll spot check some views and helpers to see how clean the code looks. Usually I don't try to read all the views, though, unless the first couple I touch on show me systemic problems.

    By the time this process is done, I usually have a rough handle on how the code is structured. Combine that with some exploratory use of the running application on my local box, and Rails' conventions, and I can go in and find the code that needs to be improved, evaluated, or fixed.

    Double Shot #414

    Looks like I've got a hole coming up in my schedule the second half of April. So it's time to nail down some work for that timeslot.

  • Rails 2.3 Support (Major Plugin Refactoring) - Exceptional joins the list of services that are ready for Rails 2.3.

  • One Laptop Battery Later And I'm a Django Fan - A review from the kinder, gentler Zed Shaw.

  • Ruby-GetText-Package-2.0.0 - I18n package now updated with support for Rails 2.3.2.

  • libxml-ruby 1.1.3 - Boosting Performance - The battle of the Ruby XML libraries continues.

  • .NET MVC vs Ruby on Rails - Rundown from someone who has tried both.

  • sinatra-tailer - Sinatra app to view log files with automatic updating.

  • sevenup - JavaScript code to pressure people to upgrade from IE6 to, well, anything.
  • Friday

    Double Shot #413

    I wonder whether more people turn to SEO as a solution in times of economic downturn.

  • Get Paid to Work on Rails - Rails is sponsoring some students in the Google Summer of Code program this year.

  • The trouble with mocks (or design versus acceptance) - The debate about mocks in testing will never end.

  • Does Ruby Dream an Eclectic Shell? - I don't do enough work in the shell to want to bother replacing bash, but here's an all-Ruby replacement coming down the pike.

  • A Rails App in Seconds - Online Rails application template generator that can install a bunch of gems and plugins, capify things, and so on.