Jer on Rails - Ruby on Rails and More

A Kick in the Sass: Making slow functional tests faster

noreply@blogger.com (Jeremy Weiskotten) — Tue, 08 Dec 2009 16:28:00 +0000

We started using Sass a while ago for all new styles, and recently converted all of our CSS to Sass. We noticed that after the conversion to Sass our test suite was suddenly taking a lot longer to run, in the neighborhood of 50% longer. Specifically, our functional and integration tests were a lot slower.

It turns out that, out of the box, Sass updates the "compiled" stylesheets on every request unless you're running in production mode. This is really handy in development when you're making incremental edits in a .sass file and refreshing the browser to see the results, but it's completely unnecessary when running tests since the .sass files aren't changing while the tests are running, and chances are your functional tests aren't dependent on any CSS files anyway.

To change this behavior in our test environment, we added the following to config/environments/test.rb:

Now Sass will only compile the stylesheets once (the first time one is needed), and our entire test suite is about 60% faster (YMMV).

The worst wide receiver in professional football: ME?

noreply@blogger.com (Jeremy Weiskotten) — Tue, 08 Dec 2009 04:14:00 +0000

I was recently interviewed for EcontentMag. Strange being referred to as "Weiskotten", but now I'm a little more Internet-famous!

If you're bored, check it out.

Hiring Rails Developers and QA

noreply@blogger.com (Jeremy Weiskotten) — Tue, 27 Oct 2009 23:27:00 +0000

PatientsLikeMe is growing! We're looking for a few great Rails developers. If you don't know Rails but are eager to learn, start learning now and get in touch.

We're also looking for an experienced QA engineer to keep us honest and help us with automated acceptance/regression testing, among other things.

To get you psyched up about coming to work with us, I thought I'd share a little about our team, our culture, and how we get things done.

We have a couple of amazing designers on staff, Kate and Scott. We get to bring their works of art to life. Kate has lots of insight into usability and user testing, and Scott brings a wealth of knowledge about visualizations (and he paints astronauts, which is awesome).

We still support IE6. Yeah, that sucks, but a good chunk of our users (mostly patients) still use it. Lucky for us, Cris and Adam know all the tricks. Semantic markup, IE hacks, accessibility... we've got it all. Well, except mobile, but that can change.

We do all kinds of crazy, awesome things in our free time. You already know about Scott's astro-art. I created Twackit to play around with the Twitter API. James created a really cool visualization of the MBTA system. Steve is a Solar System Ambassador for the NASA Jet Propulsion Lab and a school committee member. Jeff "Mav" Dwyer wrote a book about GWT (don't worry, we won't make you read it) and hands out Google Wave invites like they're candy. Rich helped Dan Cederholm (yes, the Dan Cederholm) build Dribbble, and he barely beat me in the finals of our Darts Madness tournament. Joe, Kate and I helped get HealthDataRights.org off the ground. Joe, Steve, Cris, and I participated in last year's Rails Rumble and launched The Quest for Life. I'm sure I'm forgetting someone or something, but that should give you an idea of how we roll.

Also, everyone loves Star Trek IV but me -- that's the one where they go back in time to save the humpback whales, which is stupid.

We have an in-house research team that sometimes makes me feel like I don't know shit about shit. The stack of journal publications and presentations of their research can probably be blamed for most of the deforestation of the past 10 years. Our researchers help us figure out what data is interesting to patients and what's interesting for research purposes, and they make sure we ask the right questions the right way (something about science and bias and blah blah, etc.).

Everyone has a MacBook Pro and an external monitor. We use VirtualBox to do IE testing. Some of us commute from out of town so we usually telecommute a couple days a week, but we stay in touch with IM and Campfire.

We use Git for version control. It's pretty awesome. It's super-easy to work on branches. We're always creating remote branches to work on new features in isolation, and short-lived local branches for quick bug fixes.

We release in 2 week iterations. Fast enough to get stuff out, not so fast you lose track of what's going on.

There's still a lot of legacy stuff that uses ERB and regular CSS, but all our new stuff is Haml and Sass.

We have dartboard that gets a lot of use, a Nintendo Wii (with Rock Band, of course), and we've been known to watch an episode of Star Trek or a certain movie featuring The Dude after work while we sip White Russians (or Caucasians, if you prefer). Three desks double as a conference room table which doubles as a ping pong table, and lo the balls fly furiously.

It's rare to find a job that's challenging, fun, or makes a difference in people's lives, but PatientsLikeMe offers all of that in one place. A really great perk of working at PatientsLikeMe is that we have an opportunity to improve the lives of real people -- thousands of patients with life-changing conditions. They're a very involved user-base, with no shortage of ideas and feedback.

Oh, and we have direct deposit! You gotta have direct deposit.

Setting up a Rails development environment on Leopard

noreply@blogger.com (Jeremy Weiskotten) — Sat, 17 Oct 2009 19:43:00 +0000

I recently set up a new Rails environment on Mac OS X 10.5 (Leopard). I googled for various bits and pieces. I have no idea how much of this translates to 10.6 (Snow Leopard).

I leaned on MacPorts to install Git, Ruby, RubyGems, PostgreSQL, and some other stuff that my Rails work depends on.

Xcode and MacPorts

Install Xcode from OSX DVD.
Install MacPorts via http://www.macports.org/install.php

Git

sudo port install git-core +svn+bash_completion+doc

To configure Git, including some handy aliases, add the following to ~/.gitconfig:

[user]
email = {your@email.com}
name = {Your Name}
[core]
editor = mate -w
[color]
status = auto
diff = auto
branch = auto
[alias]
co = checkout
st = status
ci = commit
df = !git diff | mate
[push]
default = tracking

To enable bash_completion, add the following lines to the end of your .bash_profile or .profile:

if [ -f /opt/local/etc/bash_completion ]; then
. /opt/local/etc/bash_completion
fi

Ruby 1.8.7 and RubyGems

sudo port install ruby
sudo port install rb-rubygems

(Note that gems will be installed to /opt/local/lib/ruby/gems/1.8.)

Symlink /usr/local/bin/ruby to MacPorts install

sudo ln -s /opt/local/bin/ruby /usr/local/bin/ruby

ImageMagick and RMagick
http://rmagick.rubyforge.org/install-osx.html

sudo port install imagemagick +gs +q16
sudo gem install rmagick

PostgreSQL 8.3
http://shifteleven.com/articles/2008/03/21/installing-postgresql-on-leopard-using-macports

sudo port install postgresql83 postgresql83-server
sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb
sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb
sudo su postgres -c '/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb'

And so that pg server launches at system startup...

sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist

PostgreSQL Ruby adapter

sudo env ARCHFLAGS="-arch i386" gem install postgres -- --with-pgsql-lib=/opt/local/lib/postgresql83 --with-pgsql-include=/opt/local/include/postgresql83

Sphinx

sudo port install sphinx +postgresql83

Common gems

sudo gem install rails fastercsv redgreen git_remote_branch capistrano capistrano-ext ruby-debug ruby-prof sqlite3-ruby

SSH key

ssh-keygen (Enter to select all defaults)
Add public key to GitHub account.

My Git Workflow

noreply@blogger.com (Jeremy Weiskotten) — Thu, 30 Apr 2009 00:23:00 +0000

(Or, how I learned to stop worrying and love the Git.)

Git is awesome. If you're using it, you know what I mean. If you're not, don't be afraid to give it a try! Git is the gateway to a new generation of code sharing on GitHub and convenient deployment to Heroku. It's built around fast branching, so it's really easy (and did I mention fast?) to create and throw away experimental branches.

I'm pretty new to Git. I used it a bit in the past (with GitHub) but hadn't really gotten into it until the past month or so when we made the switch at PatientsLikeMe from Subversion. It took me a couple of weeks to really understand what was going on, feel comfortable, and settle into a rhythm and workflow. This post will probably be old news to Git veterans, but I think there are enough Git noobs still out there that some will find this interesting or valuable (let me know if you're one of them!).

Here's how I use Git day-to-day, whether for new feature development or fixing bugs:

A. Work in a local branch

git checkout -b dev-branch-name (to create and switch to a local branch, where "dev-branch-name" is something meaningful)
Do some awesome (more or less) work.
git status, git add, git commit -am "Something about what I did"

B. Integrate with the latest

git checkout master
git pull (gets the stuff my teammates have pushed)
git checkout dev-branch-name
git rebase master (integrates my work with my teammates')
Run the test suite.

C. Merge with the rest of the team

git checkout master
git merge dev-branch-name
git push

It looks like a lot of steps and a lot to remember, but you can automate much of it if you'd like to save some keystrokes. I still like to go through the motions. You could use a simpler, more traditional (read: SVN) workflow, doing all of your work in master, but then you're missing out on a lot of the benefit of Git.

To make git a bit more user-friendly, I set up most of the aliases suggested by Justin French, so I actually use "git co" for checkout and "git ci" for commit, and I have a git completion bash script set up so that I don't have to type out full branch names.

Switching between master and various local branches can get a bit confusing. To keep myself on track, and to try to avoid working in the wrong branch, I set up a shell prompt that displays the current branch for the git-aware working directory that I'm in. Here's the actual prompt I'm using:


function parse_git_branch
{
ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
echo ${ref#refs/heads/}
}
export PS1='\[\033[0;34m\]\A \[\033[00m\]\w \[\033[01;31m\]$(parse_git_branch)\[\033[00m\] $ '

I've also started using grb to make working with (read: tracking) remote branches easier. It's easy to install and has good documentation to get you started. Then there's GitX, a powerful tool to browse your repository and to see which code is on what branches. I don't lean on GitX as much as I could, but it comes in handy.

There's a lot about Git that I still need to learn, so please leave a comment with your tips and tricks.

Announcing Twackit

noreply@blogger.com (Jeremy Weiskotten) — Tue, 21 Apr 2009 17:34:00 +0000

Last weekend I launched Twackit, which gives you a simple way to use Twitter to keep track of different kinds of metrics that are important to you... stuff like your weight, gas mileage, expenses, caloric intake, hours of sleep -- pretty much anything with a simple numeric value and a hashtaggable category that you might want to keep track of over time.

There's some basic content and reports are generated from the data you tweet to @twackit. I've gotten some good feedback, and a couple people are already using it for things I never thought of, which is really cool! I wanted to get something simple up and running and try to get people using it, then see what kinds of requirements shake out from real-world use cases.

Since this is a Rails-oriented blog, I thought I'd share a few technical details:

Twackit is running on Rails 2.3.2, the current stable version.
I'm using SQLite3 for development, but Heroku ignores your database.yml and uses Postgres, which is cool with me.
It's hosted on Heroku, which was very easy to set up in part because...
I'm using Git for version control. The code is not open source (at least not yet), and I'm only using a local repo, so no GitHub.
I used Haml for the layout and views, except for a few partials that encapsulate HTML and Javascript for third-party stuff, like Google Analytics and UserVoice. I just pasted their code into ERB templates.
The reports use the Google Visualization API for things like the Annotated Time Line, which is really cool but not very useful until you have a lot of data. (So start adding data, everyone!)
The Annotated Time Line wants Javascript Date objects. Unfortunately, Rails implements Date#to_json to return a String representation of the date, so I ended up hacking it to build a String of the form "new Date(year, month, day)". I'll keep looking for a better way.
I used John Nunemaker's Twitter gem to call the Twitter search API and to get the user's name and photo URL to make the report a little prettier.
Twackit searches for new tweets every hour or so. To support very basic background jobs, Heroku invokes a rake task named "cron" (which I think is a terrible choice because of the name collision, but at least it's intuitive).
The cron rake task records some stats about each cron import, like how long it took, how many tweets were imported, and for how many distinct users. The task finishes in less than a second, since there isn't much data coming in (yet!).

So please check Twackit out and let me know what you think. And of course, tell everyone about it!

Generating TinyURLs from Rails

noreply@blogger.com (Jeremy Weiskotten) — Sun, 11 Jan 2009 21:36:00 +0000

Sometimes URLs are just too long, especially if you have constraints like the 140 character limit on Twitter. Free services like TinyURL have been around for years, providing short URLs that issue a permanent redirect to the long URL.
TinyURL has a micro-API. Issuing a simple HTTP GET request to:

http://tinyurl.com/api-create.php?url=http://www.myreallyreallylongurl.com/its-really-long

renders a response like:

http://tinyurl.com/8y94xz

I recently created a Ruby on Rails plugin called tinify_urls that encapsulates this kind of thing, supporting the TinyURL, SnipURL, and is.gd APIs. The plugin has been tested against Rails 2.1.

I'm looking forward to feedback so let me know if you have a chance to try it out. To install the plugin:

script/plugin install git://github.com/patientslikeme/tinify_urls.git

Caching ActiveRecord Objects with Rails.cache file_store

noreply@blogger.com (Jeremy Weiskotten) — Sat, 26 Jul 2008 01:09:00 +0000

Rails 2.1 presents Rails.cache, a clean little interface for caching stuff. It makes it easy to switch between different cache stores. For example, we are using memcached in production but something else, like the file system, in development where performance and scalability aren't as important as forward progress.

Memcached supports the caching of ActiveRecord objects, so you can do something simple like this:

all_things = Rails.cache.fetch('Thing.all') { Thing.all }

This single line of code looks for a cache entry by the key "Thing.all". If it's not found, the code in the block is executed and the results are added to the cache and returned. If that cache entry is found, the value is returned from the cache, avoiding a trip to the database. Very useful for things that rarely change.

This works great with memcached store, but not with file store, which seems to prefer simple strings. A workaround is to convert the ActiveRecord objects to YAML when putting them in the cache and converting back from YAML when reading:

all_things = YAML::load(Rails.cache.fetch('Thing.all') { Thing.all.to_yaml })

I recommend encapsulating this in a class method:


class Thing < ActiveRecord::Base
  def self.all_cached
    YAML::load(Rails.cache.fetch('Thing.all') { all.to_yaml })
  end
end

Rails Blogs I Read

noreply@blogger.com (Jeremy Weiskotten) — Thu, 10 Apr 2008 02:02:00 +0000

We recently hired a new developer at PatientsLikeMe who, like I was when I started, is new to Ruby and Rails. To help him get started, I compiled this list of Rails-focused blogs that I enjoy. No particular order. They're not all updated extremely regularly, but they're all interesting, and they have good archives. Thanks to all of the writers who spread Railsy goodness!

http://blog.jayfields.com/
http://errtheblog.com/
http://www.softiesonrails.com/
http://giantrobots.thoughtbot.com/
http://weblog.jamisbuck.org/
http://drnicwilliams.com/
http://www.railsenvy.com/
http://www.therailsway.com/
http://www.clarkware.com/cgi/blosxom
http://nubyonrails.com/
http://blog.hungrymachine.com/
http://blog.hasmanythrough.com/
http://www.koziarski.net/
http://www.railsjitsu.com/
http://onrails.org/

http://bokardo.com/ - Not really a Rails blog, but Josh Porter is a thought leader on social networking, which is very relevant to my job.

I also highly recommend Ryan Bates' Railscasts. They're free, and only about 10-minutes apiece so they're highly focused and easily digestible. You may know Ryan from the Rails Forum.

I'm sure there are a million other great Rails blogs in this great web of interwebitubes, so post your favorites!

You Should Use Foreign Key Constraints in Rails

noreply@blogger.com (Jeremy Weiskotten) — Thu, 10 Jan 2008 03:11:00 +0000

Updated 4/24/09: If you want to use foreign keys in your Rails project, checkout the migration_helpers and sexy_migrations plugins for a couple of options.

Jeff from Softies on Rails recommends doing without foreign keys and posted You Don't Need Foreign Key Constraints In Rails to ask for our opinions.

He's right. You don't need foreign key constraints, just like you don't need a seatbelt in your car. Your car will drive perfectly fine without one. You can drive cross-country at 120 miles per hour without a seatbelt, but may the Flying Spaghetti Monster have mercy on your soul you if you hit a tree.

It looks like everyone is on the FK side so far in the discussion. Of course, DHH hasn't commented yet, so that may change. Rails is notorious for being "opinionated software", and this is one of those opinions that a lot of people happen to disagree with, and is one of very few (the only?) cases where the majority of Rails users overwhelmingly, strongly disagree with the Rails philosophy.

One argument against FKs is that Rails' ActiveRecord provides nifty relationship wiring and validation utilities, like belongs_to, has_many, and has_and_belongs_to_many. Since this logic is defined in the model, repeating it in the database is not DRY. Plus, FKs make it harder to deal with complicated relationships. You can't delete an entity without first deleting its child entities (which :dependent => :destroy will do for you if you want closure).

These aren't bad reasons, but they're not good enough to outweigh the benefits of foreign keys, or to offset the potential cost of a weird bug that creates inconsistent data. A fairly common problem in Rails with foreign keys is setting up and tearing down test fixtures -- but let's face it, fixtures pretty much suck, and there are ways to deal with the problem. Referential integrity is more important than cheap, lazy fixtures.

Foreign keys may repeat something that's already defined in the model code, but so what? Relationships rarely change, and when they do, you're probably going to be changing the database anyway. It's not as if they're likely to get out of sync.

Foreign keys are pretty easy to create, especially if you use a plugin like sexy migrations, and they don't add much overhead. (Oddly, Rails 2.0 borrowed quite a bit from sexy migrations but didn't include the foreign key stuff.)

Some databases provide the option to automatically index the columns that are foreign keys, saving you the trouble of adding the indexes yourself. (Foreign keys tend to be columns that you'd want to index. Consider fetching a post's comments: SELECT * FROM comments WHERE post_id = 1 should use an index on post_id.)

And of course, without foreign keys how can you generate an ER diagram to hang on the wall for everyone to admire? (Note: I don't do that.)

Fluent Builders

noreply@blogger.com (Jeremy Weiskotten) — Sun, 23 Dec 2007 20:28:00 +0000

(This post is a bit "off the Rails"... I do still think about Java every now and then, like an old girlfriend... a bloated corporate girlfriend who talks a lot without saying much.)

I've been a fan of the Builder pattern for a while, and appreciate Martin Fowler's article on fluent interfaces as well as a variety of real-world examples. Combining the two is pretty sexy, especially in a relatively noisy language like Java -- I like to call the combination a "fluent builder". In many cases, a fluent builder provides a form of named parameters, making code that uses the API very easy to read and understand. Fluent builders are useful in constructing immutable objects (love 'em!) without requiring overloaded/telescoping constructors with lots of arguments, particularly when some or all of the arguments are of the same type (an obvious use case for named parameters).

I seem to be in good company. I came across a presentation by Josh Bloch that discusses this as part of his work on a long overdue version of his outstanding book Effective Java. I'd really like to see some of his examples make their way into the JDK, like the HashMap factory.

As discussed in Bloch's presentation and elsewhere, static factory methods are a simple alternative to constructors, but are much more powerful. You can't have more than one constructor with the same set of argument types, but you can have multiple factory methods. You can't return a cached/singleton/pooled instance from a constructor, but you can from a factory method. You can't return an instance of a sub-type from a constructor, but you can from a factory method. Each static factory method can have a meaningful name that contributes to readable, fluent code.

The point is that static factory methods are an important part of building a flexible fluent interface. You don't always need them, but the cost of writing them is so low, and the potential benefit is so great (even if YAGNI), you might as well.

Here's a contrived example of some code that doesn't use a fluent builder (yet):


Car car = new Car();
car.setYear(2007);
car.setMake("Toyota");
car.setModel("Camry");
car.setColor("blue");

This is perfectly fine, but we can do better. A car's year, make, and model are certainly not going to change, and for our purposes we'll assume that it will never be repainted. Let's pass these args to the constructor instead of using setters, which allows us to make these attributes immutable.


Car car = new Car(2007, "Toyota", "Camry", "blue");

Much more concise, but it's not going to be easy to remember the order of all of those arguments, especially since there are three Strings. Let's try it now with a fluent builder:


Car car = Car.builder()
   .year(2007)
   .make("Toyota")
   .model("Camry")
   .color("blue")
   .build();

Let's examine what this code is doing. First, we call the static factory Car.builder() to get our fluent builder object. Then we call methods on the builder object to initialize the year, make, model, and color. It's very clear which fields have which values. The methods are chained together, which isn't necessary (we could cache the builder in a local variable) but is usually preferable because it reduces noise. Finally, we call the builder's build() method, which creates the Car object with the attributes we've given the builder.

We could put all of the chained method calls (year, make, model, color) on a single line, but it's usually more readable to put each on a separate line. It may be useful to note that we have some leeway when it comes to the order, as long as we finish the chain with a call to the build method (which returns the immutable Car instance).


# It doesn't matter what order we set the values in.
Car car = Car.builder()
   .color("blue")
   .make("Toyota")
   .model("Camry")
   .year(2007)
   .build();

Here's the code for the Car and its Builder:


public class Car {

  public static class Builder {
      private int year;
      private String make;
        private String model;
        private String color;

        public Builder year(int year) { this.year = year; return this; }
        public Builder make(String make) { this.make = make; return this; }
        public Builder model(String model) { this.model = model; return this; }
        public Builder color(String color) { this.color = color; return this; }

        public Car build() {
          return new Car(year, make, model, color);
      }
   }

   private final int year;
   private final String make;
   private final String model;
   private final String color;

   private Car(int year, String make, String model, String color) {
      this.year = year;
        this.make = make;
        this.model = model;
        this.color = color;
  }

  public static Builder builder() {
      return new Builder();
  }

}

There is some repetition. The Builder must duplicate all of the fields that it needs to build the Car. There's some potential refactoring, particularly to abstract a simple interface and some generic and reusable behavior, maybe backing it with a HashMap.

The code is much more complex than just using setters or a constructor. The benefits may not be clear right away, but I think that using the fluent builder provides a much more pleasant, programmer-friendly API in the long run.

Rails and the Enterprise

noreply@blogger.com (Jeremy Weiskotten) — Wed, 19 Sep 2007 15:04:00 +0000

Ask 100 enterprise developers (who are probably using Java or C#) if Rails is ready for the enterprise. My guess is that 75 will say no, 1 will say yes, 9 will say "I don't know", and the other 15 will ask "What's Rails?"

Assuming my estimates bear some resemblance to reality, this tells us a couple of things:

A good chunk of enterprise developers have never even heard of Rails, or have heard of it but don't really know what it is.
Many enterprise developers don't know enough about Rails to understand its qualities, weaknesses, and enterprise-readiness.
Many enterprise developers believe that Rails is a toy framework. This is often attributable to DHH's "Build a blog in 15-minutes with scaffolding (WHOOPS!)" screencast, which was a great way to generate excitement about a new framework, but didn't demonstrate the depth and breath of Rails.
Very few enterprise developers believe that Rails is capable of solving enterprise problems, or have a religious devotion to the familiar and tend to fear change.

I know that Rails is being used in the enterprise, which implies that it is ready for at least some enterprise problems. ThoughtWorks is certainly leading the pack in this area, and they're making progress with their enterprise clients by running on JRuby, which allows them to deploy Rails apps in a WAR and integrate more easily with legacy Java products. They also built Mingle, an Agile project management tool that is designed for the enterprise (but presumably is easy enough for small teams to use too).

So why aren't more enterprise projects using Rails? I think one reason is that Rails has only been around for about 3 years, and enterprises are notoriously slow at adopting new technology, especially radically new platforms like Rails. There are a lot of enterprise Java shops still using JDK 1.4 or 1.3! (If you're one of them, my condolences.) It's often a struggle just to introduce a new dependency on an open source project -- something as small as Apache Commons to something as big as Hibernate. Lawyers are called in to examine licenses. Security auditing may be done. Integration concerns are brought up. And then you have to actually teach dozens or hundreds of developers how to use it.

Another reason for the lack of enterprise adoption is the FUD around Ruby's and Rails' performance, scalability, and maintainability. Sound familiar? These are the same arguments that dogged Java for years, and still do today in some circles. Religious debates abound between static vs dynamic typing, compiled vs interpreted, explicit vs meta-programming magic.

I think the answer is that it depends on the enterprise, and it depends on the problems. (Answers that begin with "it depends" sound like a cop-out, but in this case I think it's true.) A good craftsman uses the right tool for the job. Sometimes Java is the right tool, and low-level JDBC is needed to integrate with legacy databases. Sometimes you really need great Unicode support, and I agree that Rails is really lacking there. But there are plenty of cases where a greenfield project needs be produced quickly featuring all the latest hotness (Ajax, REST, and the rest), or a legacy database can be migrated into something Rails-friendly.

Jay Fields: Array#collect_with_remaining

noreply@blogger.com (Jeremy Weiskotten) — Sat, 15 Sep 2007 03:24:00 +0000

Jay Fields posted another interesting Ruby example and a call for alternate solutions. (Check his post out for problem details.) After some digging in the Ruby API docs and a lot of experimenting in tests and irb, here's my offering:


def collect_with_remaining
  enum_with_index.inject([]) do |result, (element, index)|
    result << yield(element, values_at(*(0...size).to_a - [index]))
  end
end

I took the opportunity to learn about #enum_with_index, particularly how it's used in conjunction with #inject. I also learned how the asterisk prefix expands an Array into parameters -- I've seen this before somewhere (Rails source?) but never really understood what it was doing. It came in handy here, because I had an array but #values_at only takes Ranges or indices as raw parameters.

So how this method works...

In order to get the elements of the array other than "element" at "index", we create a range of every index in the array, (0...size).
We convert this range to an array (#to_a) and we remove the index of the current element ( - [index]). This gives us an array of every index but the current element's.
We send the elements in this array to #values_at, thanks to the aforementioned asterisk notation, and we get ba all of the elements except for the current one.

One thing I don't like about this solution is that it creates the same range of indexes and converts it to the same array of indexes for each element. If I did some profiling and weren't happy with performance, I would pull that code out of the block so that it's only done once, and would only add one line of code doing so.

Other than that, I think this example really benefits from the elegance afforded by Ruby, not to mention the powerful features of some core APIs. It's terse but doesn't seem too obtuse or obscure; while it uses some relatively advanced Ruby, it shouldn't be too hard to figure out.

Job Title

noreply@blogger.com (Jeremy Weiskotten) — Fri, 14 Sep 2007 12:47:00 +0000

What do we call people who create software? Here's a list off the top of my head of common titles, either official or self-applied within the industry, in no particular order:

computer programmer
software engineer
software designer
software architect
(software/application/solutions/language or framework name) developer
coder
hacker
technologist
geek/ninja/pirate

One could argue that there are distinctions between some of these titles based on experience, education, role, or skills in the good old-fashioned art of bullshitting. I'm sure there is some nuance, the sore thumb being "architect" which is typically reserved for the top-tier, who often find themselves acting more as a project manager than a hands-on creator of software.

Some of these titles can be modified with adjectives to imply experience, or lack thereof; for example: "junior", "lead", "senior", "principal", "distinguished", or "chief". Sometimes titles are used to narrow or expand the role, like "Junior UI Developer" or "Senior Systems Architect".

So what do I call myself? My company is currently filling a spot for a Senior Application Developer, which is basically the role I'm in, but my official title is "Senior Software Engineer". When people ask, I just tell them I'm a software engineer (without the "senior" modifier so I don't come off as a pompous dork) -- and if they don't know what that means, I tell them I'm a computer programmer.

Ultimately, I don't care what my title is, as long as I'm fairly compensated, have plenty of interesting problems to solve, and have the opportunity to learn and teach (often at the same time). I think most people, regardless of title or industry, feel the same.

First Class

noreply@blogger.com (Jeremy Weiskotten) — Thu, 13 Sep 2007 16:12:00 +0000

We have a collection of items that we're semantically marking up as an unordered list of links. The catch is that the first item should be styled differently, by having a CSS class, than the rest of the items (which have no specific class).

We can do this using each_with_index and testing for index == 0 to determine what class to use. Or we can pass the :collection to render :partial and use a :spacer_template.

Here's another approach, which doesn't need an index and keeps the whole thing all in one place:


<ul>
<li class="first">
<%= items.map { |item| link_to item.name, :action => 'show' }.join('</li><li>') %>
</li>
</ul>

This should be extracted into a helper method to hide the complexity (the calls to #map and #join), especially if something like this will be done in more than one place:


def list_items(items, first_class, others_class='') 
  first_style = " class=\"#{first_class}\"" unless first_class.blank?
  others_style = " class=\"#{others_class}\"" unless others_class.blank?
  sep = "<li#{others_style}>"
  "<li#{first_style}>#{items.map { |item| yield(item) }.join(sep)}"
end

<ul>
<%= list_items (people, 'head_of_household') { |person| link_to person.name, :action => 'show' } %>
</ul>

I heart surrogate keys

noreply@blogger.com (Jeremy Weiskotten) — Wed, 12 Sep 2007 15:36:00 +0000

Brad Hudson argues against surrogate keys in favor of using natural keys. (His main point is in regards to what he calls "relationship tables", a.k.a. a table that forms a many-to-many relationship between two others, but I want to discuss the topic in a broader sense.)

I'm not a DBA by any means, but I have a lot of (over 10 years) experience designing relational schemas and using them with a variety of languages and ORM strategies.

I wouldn't want a database that doesn't use surrogate keys -- particularly integer IDs.

First, some basic definitions behind the discussion.

A "key" is the attribute or set of attributes (columns) that uniquely identifies an entity (a row).

A "natural key" is an attribute that has some business or domain value; for example, an ISBN number identifies a book.

A "composite" or "composite natural key" is a set of attributes that have business or domain value that together identify an entity; for example, the name of a city and the state you'd find it in identify a city (you need the state to distinguish between Springfield, Illinois, and Springfield, Massachusetts).

A "surrogate key" is an attribute that does not have business or domain value, and only exists for the purposes of identifying an entity. Also commonly called an "id" or "sequence number", surrogate keys are usually a numeric/integer type, but may be a GUID or other more complex type.

There is just no way, absolutely none, that a natural key can be more time-efficient than a surrogate key composed of a single integer. The only way it can be AS efficient is if your natural key happens to be a single integer (which is rare in my experience). I don't know of any other data type that can be indexed/looked up as efficiently. Composite natural keys, which usually include at least one varchar, just can't be as fast.

Surrogate keys do require an extra column per table, typically a 4- or 8-byte integer, in addition to the natural key columns. At first this sounds like it's less space-efficient -- an extra column with no business value? However, keep in mind that this is a relational database -- foreign keys would otherwise have to be defined by duplicating the entire natural key, consuming much more space for no better performance. Surrogate keys, on the other hand, make for simple foreign keys.

Sometimes it is useful for performance or convenience to duplicate (denormalize) the natural key even when a surrogate is used, but wiring your relationships through a simple integer column is significantly easier to use and maps much more easily to an object-oriented model. Modern ORM tools like Hibernate and Rails' ActiveRecord do a good job of eager fetching with complex JOIN queries to prevent n+1 SELECTs, so denormalization often isn't necessary.

I haven't even gotten into cases where a table doesn't have an obvious natural key, or natural keys that don't change 99% of the time but are hell when they do. A good example of this is social security numbers -- they can change!

Jay Fields: Array#chunk

noreply@blogger.com (Jeremy Weiskotten) — Tue, 11 Sep 2007 15:09:00 +0000

Jay Fields of ThoughtWorks posted an interesting problem: break an Array up into a given number of "chunks". He provides an example implementation and unit tests that define the expected behavior.

I posted my solution in a comment, but here it is again (I really need to figure out how to get syntax coloring...):


class Array
  def chunk(number_of_chunks)
    chunks = (1..number_of_chunks).collect { [] }
    self.each_with_index do |item, index|
      chunks[index % number_of_chunks] << item
    end
    chunks
  end

  alias / chunk
end

My solution is a little different than his. First, mine doesn't modify the contents of the Array; his does. Since his does, the method should really be named "chunk!", that exclamation point being the convention that indicates that it mutates the instance on which it is called. The unit tests don't enforce one or the other, so I decided to follow convention.

Second, I've got one loop, which is over the Array being chunked. He's got a nested loop, which I think increases the complexity quite a bit.

There's a little bit of cleverness in my solution. I figure out which chunk to add the item to using the % modulus operator. This may not be a very common idiom, but it works and you don't need a separate counter with boundary testing to cycle back to zero.

The Wisdom of Crowds: Fantasy Football Edition

noreply@blogger.com (Jeremy Weiskotten) — Mon, 10 Sep 2007 01:21:00 +0000

Every fantasy football team owner/manager has a weekly, daily, or even minutely ritual of analyzing, researching, scrutinizing, guessing, second-guessing, and finally deciding which of their players they'll put the fate of their Tuesday-morning happiness on. There are lots of resources available to dig through -- sports magazines and websites, fantasy-focused magazines and websites, pre-game analysts on the TV, the guy two cubicles over. These resources all have one thing in common: they rely on the wisdom of a handful of "experts" to give you the inside scoop.

The problem is that these experts are often wrong, or by the time you get the information it's out of date.

My fantasy football league is run on Yahoo, which provides good enough tools for us amateurs. Every year the geniuses at the Y! give us cool new features. One of this year's additions is called "Sit or Start", and is Yahoo's attempt to introduce wisdom of the crowd to fantasy sports. Basically players across all of Yahoo's leagues can vote for who to sit and who to start. If you choose to vote, you're presented with two players (same position) and you vote for one the other (to start). Then you're presented with two more, and you repeat until you get bored, which in my experience might be an hour or two later.

The end result is that thousands of players just like you weigh in with their varying levels of expert-opinion. Like other "wisdom of crowds" experiments (see almost any social network) it's debatable whether the information derived this way is any more accurate or reliable than that provided by experts, but I think it's a great tool. If nothing else, it's one more bit of data that I can use to micromanage my team.

On a side note, I'm kicking ass in week 1!

The Forgotten Benefit of Unit Testing

noreply@blogger.com (Jeremy Weiskotten) — Thu, 06 Sep 2007 21:11:00 +0000

Why Write Test Code is a good overview of some of the benefits of writing automated tests, including unit tests. There's another benefit that's frequently forgotten when people discuss this topic.

High cohesion and low coupling. Better known as good encapsulation.

Unit tested code is often designed (in a pure test-first TDD process) or refactored into well-defined classes that take responsibility for their own state and behavior. This is necessary in order to isolate the class (or unit) under test, giving components better-defined interfaces and minimizing dependencies between collaborators. Otherwise your tests tend to be complicated to set up, slow, and brittle -- harder to create and harder to maintain.

So unit testing isn't just about testing, it's about code design, and at some level it's about architecture. Testing considerations drive small (micro) design decisions which inevitably influence larger (macro) design decisions. I think this is a key difference between the "Agile" and "waterfall" design processes. Agile projects are designed from within based on evolving requirements, from the micro to the macro, where waterfall projects are designed more from the "big picture" by Man Behind the Curtain, cascading down into the minutia.

Rails Rumble 2007

noreply@blogger.com (Jeremy Weiskotten) — Thu, 06 Sep 2007 19:36:00 +0000

I wish I had learned about Rails Rumble sooner! Wishful thinking: I might have been able to make time to participate & put a team together.

Maybe I'll at least get to judge some cool, innovative Rails apps. I look forward to seeing what comes out of this competition -- if this year's results aren't too intimidating, I'll try to get a team together next year!
Don't miss the title belt supplied by thoughtbot.

On Continuous Integration

noreply@blogger.com (Jeremy Weiskotten) — Thu, 06 Sep 2007 17:18:00 +0000

"Nightly builds are nice, but may be overkill for most teams."
- Isaac Sacolick, Best Practices for Software Developers

There's a lot of truth in this article, but I disagree with Isaac's final point.

Nightly builds may be overkill, but only if you are building frequently; that is, practicing continuous integration. I've heard first-hand of teams that build (on an isolated, non-development box) only once a week, or even once a month. These delayed builds rarely succeed without significant human intervention, turning what should be a simple process into hours or days of scrambling, wasting valuable development hours on integration.

Ideally a build would occur automatically whenever someone checks in code. If that's not feasible (because the build takes too long), there are some options:

1. Make the build faster if you can. Optimize it like you would any other software issue -- identify and remove the biggest bottleneck, retest, repeat until it's fast enough.

2. Reduce your build process to a minimal set of tasks to verify the code. If you're working in a compiled language like C++ or Java, compile the code. If you're doing any unit testing, automate the tests. Things that change less frequently, like install/deployment scripts, may not need to be exercised as frequently.

3. If you've optimized and reduced as much as you can and it's still not fast enough to build at every check-in, build at frequent intervals throughout the day. Every 10 minutes, every hour, every 4 hours -- whatever you can afford, but the more frequently the better.

It's also important to note that a broken build is not the end of the world (at least you know the system works!) but it should be fixed ASAP. No one should updated from or commit to a repository that can't be built, and development more or less halts until the build is fixed. If your team is integrating and building continuously, most build issues are relatively easy and quick to fix ("oh, I forgot to add this new file...").

PatientsLikeMe is Hiring!

noreply@blogger.com (Jeremy Weiskotten) — Thu, 06 Sep 2007 15:58:00 +0000

PatientsLikeMe is looking for some smart people. We're a small, well-funded startup in Cambridge, Massachusetts, building communities (aka "social networks") and tools for people with challenging, life-changing diseases and conditions.

PatientsLikeMe was recently featured in Business 2.0 magazine as a disruptor that will change the world. We currently support ALS (Lou Gehrig's disease), multiple sclerosis, and Parkinson's disease, and we're close to rolling out support for HIV.

We're growing fast and our talented (and very busy) team needs some help. We're looking for a Junior Web Designer/UI Engineer and a Senior Application Developer who has or really really wants some experience with Ruby on Rails.

Feel free to contact me if you'd like more information, a developer's perspective, or to submit your resume.

Fat Models

noreply@blogger.com (Jeremy Weiskotten) — Thu, 23 Aug 2007 13:36:00 +0000

Unlike the fashion world, we Rails geeks prefer fat models. When we see Kirstie Alley we say, “That’s what I’m talkin’ about.”

We all know that Kip only has eyes for Lafawnduh.

A fat model, um, carries its weight. Not slacking off, it does everything it’s capable of doing for itself. This makes a fat model responsible for itself. It’s responsible for managing its own associations; for wiring its dependent objects to itself. It’s responsible for any business logic that it should be taking care of, including validation of its state. A fat model is more likely to be reusable; at a minimum it will be easier to use. Fat models are not deadbeats.

Fat models, consuming all that responsibility for themselves, result in skinny controllers. The role of a controller is to drive the application flow, not baby-sit the model. Controllers respond to input, use the model to get state and behavior, and render the right responses. When the controller is doing work that the model should be taking care of itself, it’s much harder to reuse that behavior.

Encapsulation

To any experienced OO advocate this sounds like basic encapsulation, and it is. In an MVC world, it sounds like basic separation of concerns, and it is. Fat models encapsulate their state (typically what’s stored in the database) and behavior (business logic, relationships, validation). However, I think it bears repeating for a couple of reasons:

It’s easy, and therefore tempting, to hack some business logic into a controller, even a view. Not even Rails, which embraces MVC like few other frameworks, can do much to prevent laziness and sloppiness.
Not everyone is an experienced OO advocate.

Benefits

Besides reusability, another benefit of fat models, and encapsulation in general, is testability. It’s easier to write a unit test for a model than to write a functional test for a controller. It’s just less work; there are fewer dependencies/collaborators/fingers in the pie, and you can test the model in relative isolation. You’ll still want to write a functional test for every controller, but you should have to test little more than the responses to different requests, not the business logic, because business logic is covered by your simpler unit tests.

You’ll also find that your controllers, where much of the complicated interaction between the crazy user and your application is handled, are much simpler. They’ll be easier to read and maintain, which at least as important as how easy they were to create. When responsibilities are focused, noise is reduced, and we’re more capable of understanding intent. That makes us better at identifying patterns and where we can improve design by refactoring away repetition.

Lesser of two weebles

noreply@blogger.com (Jeremy Weiskotten) — Wed, 22 Aug 2007 21:22:00 +0000

In Java, if you want to determine the lesser of two numbers, you can do this:

min = (x < y)? x : y;

...which is shorthand for:

if (x < y) {
min = x;
} else {
min = y;
}

For better code clarity, you can use the overloaded static utility methods in the Math class:

min = Math.min(x, y);

In Ruby, you can do it with similar longhand:

min = (x < y) ? x : y
# or
if x < y
min = x
else
min = y
end

Ruby's Math class doesn't have min/max utility methods. Instead, you contain the values in an array and use Array#min/max:

min = [x, y].min

I think that's pretty terse and elegant. I suppose you could complain about the allocation of an extra array, but memory is cheap and fast.

Days and Seconds

noreply@blogger.com (Jeremy Weiskotten) — Wed, 22 Aug 2007 00:37:00 +0000

I've been bit more than once by something like this bit of Ruby (with Rails' ActiveSupport extensions to Core):

yesterday = Date.today - 1.day

Seems innocent enough. We're going to subtract one day from today to get yesterday's date. But as of today, August 21, 2007, this code tells us that yesterday is 1771-01-30. 19th Century: I hardly knew ya.

Obviously 1.day isn't a day. In fact, it's the number of seconds in a day, which happens to be 86400. Go ahead, multiple 24 * 60 * 60 if you don't believe me. The Date#- (minus) operator expects, sanely, a number of days. So we're subtracting 86400 days. (Time#- expects seconds, but can't go back too far in time, so it's not always usable.)

Here's the (obvious) answer:

yesterday = Date.today - 1

If I'm dealing with a larger number of days, say 3 years, I could multiple 365 (ignoring leap year rounding issues) by 3:

ye_good_old_days = Date.today - (365 * 3)
# or I do the math...
ye_good_old_days = Date.today - 1095 #3 years

Here's another way, which is a little more verbose, but also a little more expressive:

ye_good_old_days = Date.today - (3.years / 1.day)

This gets the number of seconds in 3 years, then divides by the number of seconds in a day, to get the number of days in 3 years. I can take it or leave it.

Thoughts?