Pete On Rails

In my post about clever code vs. terse code, I showed some distaste for code that attempts to put a bunch of logical statements on one line. I have a particular coding prejudice that lines of code should be short from left-to-right, if at all possible.

The reason? I like sidebar comments.

Maybe this is my showing my age. Back in the day, we didn’t have widescreen MacBook Pro laptops that could display 600 characters across the screen. (And we liked it! While walking uphill both ways in the snow to school…) Between 17″ CRT monitors and the IDE, I was lucky to get 100 characters across.

So instead of writing long lines of code, I prefer to use a couple extra lines and simplify each discrete statement. Then I will sometimes put comments (aligned with each other) out in the right margin that map to my pseudo-code (which is usually just in my head….I don’t actually write much pseudo-code in Ruby).

For example:

1
2
3
4
5
6
7
8

# Spawn a set of threads to process the queue
1.upto(threadcount) do |thread_id|
  threads << Thread.new(thread_id) do |i| # Each thread
    until @queue.empty?() do                    # grabs an item from the queue
      yield(thread_id, @queue.deq())            # and yields it to the block
    end
  end
end

Some people call this “code smell.” The meaning, I guess, is that if I have to write comments that outline what the code does, the code must be too complicated.

I beg to differ.

Imagine for a moment that you are a fresh-out-of-college programmer, and you open up my codebase to maintain it. You find this:

1
2

# Spawn a set of threads and process the queue all on one line
1.upto(threadcount) { |thread_id| threads << Thread.new(thread_id) { |i| yield(thread_id, @queue.deq()) until @queue.empty?  } }

You might run away screaming after a few dozen lines like that. I sure would. Smaller lines with comments make it easier to follow. And I think sticking them out on the right margin where they don’t interrupt the flow of code makes it easier to ignore them if you’re an experienced programmer who doesn’t need them.

In 21 Ruby Tricks You Should Be Using In Your Own Code, Peter Cooper outlines some really useful best practices that programmers could benefit from. However, I think that there’s a tendency to over-obfuscate code from time to time in the Ruby world.

I like terse code. I like beautiful code. But I dislike tricky code. For example, let’s look at two tricks Peter Cooper outlines in his post:

Trick #7: Cut down on local variable definitions.

1
2
3
4
5
6
7

 
# Cooper says do this: 
(z ||= []) << 'test'
 
# Instead of this: 
z ||= []
z << "test"

Counting whitespace characters, Cooper’s version of the code is 20 characters long. The second version of the code is 20 characters long. Personally I find the second version easier to read.

Trick #9: 9 - Use ‘and’ and ‘or’ to group operations for single liners.

1
2
3
4
5
6
7
8
9
10
11

# Cooper likes this:
queue = []
%w{hello x world}.each do |word|
  queue << word and puts "Added to queue" unless word.length <  2
end
puts queue.inspect
 
# Output:
#   Added to queue
#   Added to queue
#   [”hello”, “world”]

Hm. While I think this does terse up the code by grouping statements that do a single logical operation onto one line, I think it’s still easier to read this way:

1
2
3
4
5
6
7
8
9

# I like this:
queue = []
%w{hello x world}.each do |word|
  unless word.length < 2 do
    queue << word
    puts "Added to queue" 
  end
end
puts queue.inspect

I think this method makes it easier to modify the discrete elements of the queue operations. For example, I may want to comment out that call to “puts” someday, which would be tougher if I’d used the “and” operator to string it all together on one line. I might also want to add a debug log statement. Again, it gets tough when you’re trying to fit it all onto one line.

My opinion is that finding tricks in the language that allow you to string a bunch of steps onto one line aren’t always the best way to make good code. Sometimes, finding a way to make a set of statements look like a logical unit is a better choice.

I’m considering moving my comment system to disqus. I really like how their service helps keep online conversations easy to follow across multiple sites while making it easy not to lose track of the blog where the conversation began. It also lets users see more about a random commenter they come across on a blog.

Anyone else done this move on a Typo system?

Good grief. It’s amazing how fast you get buried in comment and trackback Spam. I had a tough week last week, so I hadn’t posted much or reviewed comments. This weekend, when I had some time to pay attention to my blog, I found that I had hundreds of spam comments and trackbacks.

I know. “Quit your complaining, Pete. That’s life. We all deal with that crap.”

Well, I hadn’t realized just how inundating it can be. So:

1. I turned on Akismet spam filtering.
2. I closed older posts to new comments.
3. I tuned some other settings, including requiring comments to be posted via AJAX. If you have Javascript turned off, you won’t be able to comment.

While I was at it, I enabled Gravatars. Woot!

Have you ever found yourself explaining to a co-worker or a boss the intricate details about why something CANNOT be done?

In working as a software engineer, a product manager, an agile practitioner, a pragmatist, and a director of a tech startup, I’ve often found myself responsible for introducing a “healthy dose of reality”. Often, stakeholders will cook up great ideas that are difficult or costly to execute on.

After reading Fred Wilson’s blog post on Words Of Wisdom, I had to reflect a bit on the balance between healthy pragmatism and “being a roadblock.”

As a practicing Scrum master, I know one of my jobs is to be realistic about what can be achieved, and to say, “No, you cannot have the world in two weeks. But you can have a little piece of it.”

As an engineer, I know one of my jobs is to point our that “If you build a house out of cards, it’ll eventually fall down.”

But as a signatory to the Agile Manifesto, I am also responsible for placing value on “responding to change over following a plan.”

It’s easy to dismiss “change” (or new ideas) that threaten a well designed plan. But be careful. Don’t be someone’s roadblock. Be the way around it.

I was paying a parking ticket online to Montgomery County, MD. When the site processed my payment, it submitted to the action shown below. Haha.

I am pretty sure I wouldn’t make that mistake with rails routes.

I use Mac OS X 10.5.2.

I was in the process of setting up a master repository for the source code to a couple of projects I am working on that I am not hosting on github. Since I work on them from a couple locations, I figured I’d set up my workstation at home as a git “server” (to use the SVN terminology) and then use “git pull” on both that workstation and on my laptop to grab working copies, and keep them in sync.

Hey, git’s made for distributed development. Who says I can’t pretend to be two remote developers?

I set up my “origin” repository like this. All went well until I tried to push my master branch to it.

1
2
3
4
5
6
7
8
9
10
11

myhost: Pete$ mkdir -p /var/git/pete_on_rails.git
myhost: Pete$ cd /var/git/pete_on_rails.git/
myhost: Pete$ git --bare init
Initialized empty Git repository in /private/var/git/pete_on_rails.git/
 
myhost: Pete$ cd ~/workspace/pete_on_rails/
myhost: Pete$git remote add origin ssh://myhost.local/var/git/pete_on_rails.git
myhost: Pete$  git push origin master
Password:
bash: git-receive-pack: command not found
fatal: The remote end hung up unexpectedly

Boom.

Unfortunately, “SSH” isn’t so smart about paths on OSX. It doesn’t read ~/.bash_profile or /etc/bashrc or /etc/profile or /etc/login or ~/.login.

It usually DOES, however, read ~/.bashrc. That’s not where I like to set up my pathing, but adding this to the file fixed the issue:

1
2

# in ~/.bashrc
export PATH=/usr/local/git/bin:$PATH

Here’s what happened after I ran the command:

1
2
3
4
5
6
7
8

myhost: Pete$ git push origin master
Password:
Counting objects: 2663, done.
Compressing objects: 100% (2460/2460), done.
Writing objects: 100% (2663/2663), 5.13 MiB | 2271 KiB/s, done.
Total 2663 (delta 292), reused 0 (delta 0)
To ssh://myhost.local/var/git/pete_on_rails.git
 * [new branch]      master -> master

If you need a hint as to what SSH thinks the path is, take a peek in /etc/ssh/sshd_config.

Ben Hughes has created a simpler github badge for his typo blog that renders a little more smoothly in Typo than Dr. Nic’s badge.

I added support for YAGHB to githubsidebar today. If you like the look of YAGHB better, you can grab the latest sidebar from github. In the configuration pane, you should now see a set of radio buttons that let you choose which badge to render.

Personally, I like the original badge quite a bit, but Typo users who are having trouble getting it to look right with their theme may want to give YAGHB a try.

Well, it’s happened. The Rails 2.1 RC1 release has been tagged at github. If you haven’t already downloaded it after hearing the news on your iPhone RSS Railscast feed, then head on over to Railscasts.com and watch Ryan’s short video on how to install it.

I liked Dr Nic’s github badge so much that I wrapped a sidebar plugin around it for Typo users. You can get it from github.

Or install it into typo like this:

# cd typo/vendor/plugins
# git clone git://github.com/peteonrails/githubsidebar.git github_sidebar