Millarian

Tonight, at one of our (in)famous hack-a-mania nights at Integrum, we released a gem for accessing Twitter through XMPP. Read the full Integrum release article and then go get hacking!

I’m excited because not only did I have a hand in the creation of the twitter_bot gem, but I also helped in the development of Props & Drops, aka. TwitterProps, a Twitter application that uses this gem. So If you want to see it in action, give someone props (or drops) via twitter:

props @username for doing something cool

OR

drops @username for being a jerk

Go try it out!

DISCLAIMER: TwitterProps and twitter_bot only work when Twitter has their track feature enabled, which recently has been scarce…

I’ll be heading to RailsConf 2008 this week in beautiful Portland, OR. I can’t wait to be in one of my favorite cities again. Especially because I’ll not only be enjoying the city, but also learning from and interacting with the Rails community. If you’re going to be in Portland this weekend, then feel free to contact me.

This trip is brought to me by the awesomest rails development shop, Integrum! And if you see any of the other Integremlins there, say “Hi”, you never know what could happen. That’s what I did last year and now I get to work there building amazing Rails applications every day. Oh, and we have stickers.

As I stated in a previous post, I attended the Gotham Ruby Conference this past weekend in NYC. It was a great time with many interesting talks. The weather was amazing as well. I don’t want to spend a lot of time rehashing the conference because you can view the GoRuCo 2008 presentations for yourself, but I did want to mention a few things I got out of it.

Bryan Helmkamp gave an interesting introduction to story driven development using rspec and story runner. This is something we’ve been talking about at Integrum, but haven’t had a chance to use in a real setting yet. Derek and I got to spend some time at the WePlay offices (where Bryan works) and they showed us some of the stuff they’re doing, including using story runner. It was awesome to hear about their experiences and hopefully we’ll get a chance to use it soon.

Next up was “Archaeopteryx: A Ruby MIDI Generator.” I was skeptical about this one, but was blown away by Giles Bowkett’s presentation. From recounting his life adventures, including a “psycho throwing rocks at his dad until he threatened him with a piece of rebar” to calling venture capitalists “weasel-brained muppet fuckers… they’re not fools, they’re liars.” He kept the crowd well entertained, but threw in some really interesting and well-delivered points about startups and life. It is well worth watching.

Another one that really stood out was Ryan Davis’ presentation about “Hurting code for fun and profit.” He had a lot of really great things to say about being a developer, so go watch it already!

These speakers helped me to become aware of a few things:

• I don’t read enough. Ryan mentioned that the average developer reads 1 book a year. Is one book a month really so hard?
• I don’t hurt my code enough. I don’t use flog or heckle consistently and I often don’t take the time to correct code that I know should be improved.

I definitely have some things to work on… how about you?

I was recently inspired to create some cached, dynamic JavaScript files for a project I am working on after watching Ryan Bates Railscasts episodes 88 and 89.

The basic concept is to create a JavaScript controller that dynamically renders some JavaScript file(s). This allows you to take advantage of ERB in your JavaScript files. However, this can become slow as every request for that JavaScript file must be processed by Rails. In episode 89, Ryan showed how to cache the dynamic JavaScript file to improve performance. These episodes were great, except I had one problem… The dynamic portion of the JavaScript files I was working with were translated strings.

This meant that I couldn’t just cache the JavaScript file because the translation would need to be different based on the locale setting of the user. It turns out there’s a pretty easy solution to this. If you follow the lessons from the episodes then you will have a general caching mechanism for the dynamic JavaScript files. Assuming you are using a translation mechanism like Globalize then you have access to a locale for the current session. Simply use this locale when including the JavaScript file (e.g., dynamic_states):

<%= javascript_include_tag "#{locale}/dynamic_states" -%>

This will try to include the dynamic_states.js file from the javascripts/locale directory where locale is something like en, es, zh, etc. The only other thing to do is define a custom route to handle this new pattern.

map.connect ':controller/:locale/:action.:format'

That’s it. You should now have locale-specific dynamic JavaScript files. For what I was working on, I also nested the locale directory within another directory (e.g., cache) just for ease of removal in case you need to wipe out the entire cache of dynamic JS.

Resources

• Dynamic Select Menus
• Page Caching

Next week I will be traveling to New York for the Gotham Ruby Conference courtesy of my favorite Ruby on Rails consulting company in Phoenix. I’ll be attending with Integrum’s resident Agile methodology expert. If you’re in NY or attending the conference, be sure to look us up – see my contact information.

I ran into a strange Ruby on Rails counter_cache problem today. Given the following example models:

class Poll < ActiveRecord::Base
  has_many :poll_choices
  has_many :poll_votes
end

class PollChoice < ActiveRecord::Base
  belongs_to :poll
  has_many :poll_votes
end

class PollVote < ActiveRecord::Base
  belongs_to :poll, :counter_cache => :votes_count
  belongs_to :poll_choice, :counter_cache => :votes_count
end

We want to ensure that the Poll maintains the total vote count. We also want the PollChoice to maintain the votes for that specific choice. In our controller we might be tempted to add a PollVote through either the Poll or PollChoice association with PollVote, but that’s where the problem appears.

It turns out that both of the following approaches will only update the votes_count for one or the other instance, but not both.

@poll.poll_votes.create(:poll_choice_id => @poll_choice.id)

OR

@poll_choice.poll_votes.create(:poll_id => @poll.id)

Instead, if we create the PollVote directly we will get the desired result of both the Poll and PollChoice having their votes_count updated appropriately.

PollVote.create(:poll_id => @poll.id, :poll_choice_id => @poll_choice.id)

Strange behavior or expected result?

Update: Another solution is to not assign using the ID, but instead assign using the object itself.

@poll.poll_votes.create(:poll_choice => @poll_choice)

OR

@poll_choice.poll_votes.create(:poll => @poll)

A quick test showed this worked as well. (Thanks Arya A)

The first real day of the conference. I’m not gonna lie to you, the first day seemed pretty light. Registration was from 10:00am until 2:30pm with no panels, sessions, etc. scheduled during that time.

We got to the convention center in Austin at about 11:00am, registered with ease and proceeded to B. D. Riley’s Irish Pub for an Austin Refresh meetup. Not wanting to partake in the suds before noon, Gist and I headed for Starbucks for some early afternoon pick-me-up.

After the Refresh meeting we headed back to the convention center to prepare for the first panel of the day. Then a strange thing happened… While we were shooting the shit, Gist comes up with a great idea for a simple application for Twitter. We laugh about it, throw some ideas around and viola we have the beginnings of a new project. After taking a poll amongst the others, we decided to devote a triple to working on a first release – me, Jade, and Gist.

While Gist drew some sketches, Jade and I borrowed a laptop from Heidmo to begin development. Just a few short hours later we have our first version of an app we are calling “Props and Drops”. It is a way for people to give props (or drops) via Twitter. It’s pretty easy to get started, just visit http://props.integrumtech.com and click ‘About’ to get started. It also has a nifty iPhone interface, so if you’re lucky enough to have an iPhone check it out!

It was really awesome to see an idea progress so quickly. Here is a brief timeline of the day (totally estimated):

• 1:00pm – Mother jokes
• 1:07pm – Gist mentions way to vote people up or down via Twitter
• 1:08pm – Someone says props
• 1:12pm – More mother jokes
• 1:17pm – The idea turns serious and Jade, Gist and I volunteer to build it in the few hours before the 5:00pm panel
• 1:21pm – Another mom joke…
• 1:35pm – Gist sketches interface
• 1:30pm to 3:30pm – Jade controls laptop while I pair and we write the app in under 2 hours
• 3:30pm to 4:52pm – Deployment takes about another hour, including minor tweaks discovered on deployment
• 5:00pm – People begin to use ‘Props and Drops’ during the 5:00pm panel
• 5:45pm – Strebel gains a substantial props lead over all others
• 6:10pm – High fives are exchanged amongst Integremlins
• 6:11pm – Mother jokes resume
• 6:40pm to 2:00am – Alcohol is consumed

What a completely awesome day. Thanks to Jade and Gist for kicking ass to get this app out there and ready for use. Thanks to everyone already partaking of the Twitter Props and Drops goodness. Send us feature requests!!

Props and Drops

What a long day! We traveled by RV from Phoenix, AZ to Austin, TX in just about 19 hours. Not record time by any means, but we had a blast. Josh provided the RV and both he and Derek drove.

Highlights of the trip include stopping to discover the mysteries of ‘The Thing’, talking politics and religion with Jade and Erica, Curtis hacking on a new side project and me hacking on a side project (details soon).

It was really nice to spend some quality time with some of my co-workers outside of work and the pressures and demands of customers. Looking forward to participating in SxSW!

In August 2006, I left my employer to embark on a journey to change my skill set and mind set. My previous employer was a very large defense contractor who offered a decent workplace, average salary, excellent benefits, and, of course, job stability. I announced to my friends and family that I would be leaving this employer, returning to Arizona and leaving the ranks of the employed for an undetermined amount of time. It seemed ludicrous to most people at the time, myself included. I was sure of only one thing at that time: I intended to refocus my career goals in an entirely different direction.

Unemployment

I had attempted to take my career in a different direction while still working, but I found that after 60-80 hour work weeks, a Master’s program in Computer Science and a wife and two young children, I didn’t have the energy. Voluntary unemployment was a calculated risk that I could learn what I needed to enter my newly chosen career path before I was forced to declare bankruptcy.

Unemployment is not really as bad as I thought it would be. I was able to spend time learning the things I was truly interested in, including Ruby on Rails. I spent a lot of time with my family and generally enjoyed myself. I found that I could actually work longer with more focus that I ever did at a previous employer without feeling tired or burnt out.

Eventually, our finances drained to the point of alarm and I began to look for a professional position working with Ruby on Rails.

Contracting

Since early 2007, I have been contracting my Ruby on Rails services to various employers. While this was lucrative it was also very frustrating. During that time I learned a little about myself and the environment in which I work best. I invest myself in what I do and as a contractor I found it hard to not get involved beyond what was required of me.

My first contract position was a fixed bid contract that was referred to me by my brother. It allowed me to choose the technology and create a simple student tracking system for a wellness center. It was deployed internally in January of 2007 and as far as I know it is still being used. My first real, deployed and used application! With that experience under my belt, I placed my resume on various websites advertising my interest in Ruby on Rails development positions. In a few short days I was contacted.

My second contracting position was an 18 month contract to create an EMR system for a local, privately held behavioral health organization. This was the big test for me to gauge if my calculated risk would pay off. Unlike the previous contract I was interviewed about my knowledge of Ruby on Rails, databases and Agile development. Two weeks after advertising my resume, I was hired to work professionally with Ruby on Rails. I learned a lot during my time contracting for that company, including how much I didn’t know, and met a great Phoenix Ruby on Rails developer, Josh Huckabee. I also attended my first RailsConf in Portland, OR in May with Josh and a few of the full-time employees.

Attending RailsConf was a real turning point for me, in many ways. Part of what I was missing as a lone wolf developer was the sense of community and interaction with other Rubyists – I met some great people at RailsConf! Upon returning, I began attending the Ruby User’s Group in Phoenix, Phoenix Rails Group and Refresh Phoenix to connect at a local level with other enthusiastic Rubyists, developers and designers.

This was the beginning of the end of my time at my current contract. As I discovered more about agile Ruby on Rails projects I realized that it would be highly improbable to influence the current direction of my contract employer. For three more months Josh and I attempted to influence the direction of our project and rescue it from impending failure. In August, we made our exit and, because of RailsConf and local networking, we began contracting for a Phoenix Ruby on Rails consulting company, Integrum Technologies.

Integrum and Me

In January 2008, Josh and I became full-time Integrum code monkeys. Integrum is an amazing place to work and completely unlike any company I’ve worked for. There is a level of openness and transparency that I have only read and dreamed about. Of course, Integrum is not perfect, but we are working hard to constantly improve ourselves while still having a blast. My wife constantly reminds me that Integrum is fueled by fun :) I believe that this year will be an important one for our company. You can keep up on what’s going on with us by reading, or subscribing to, the Integrum blog.

A year and a half has passed since I resigned my comfortable, full-time position in California. In that time I have accomplished more that I could have hoped for and am happier than I’ve been in some time – my calculated risk paid off.

A recent update to Textmate added a variable to the do snippet. So when you type ‘do’ followed by a tab, you get

do |variable|

end

Most of the time I don’t need a variable, so I want the default ‘do’ snippet to not have a variable.

Open TextMate and use the keyboard shortcut to open the Snippet editor (Ctrl+Alt+⌘) Click Ruby in the Snippets area, click the plus sign (+) in the bottom left corner and click ‘New Snippet’.

Name the snippet ‘Insert do … end’, assign Activation (Tab Trigger) the value ‘do’ and Scope Selector the value ‘source.ruby’. The snippet text should be

do
  $0
end

Finally, change the existing Snippet named ‘Insert do |variable| ... end’ Activation (Tab Trigger) the value ‘dov’. Now when you type ‘do[tab]’ you will get the ‘do … end’ block without a variable. When you type ‘dov[tab]’ you will get the ‘do |variable| ... end’ block.

I was recently asked about the difference between using or versus || in Ruby and thought it might make a good tip. They essentially do the same thing, but with one difference: operator precedence. You see || is evaluated before an assignment whereas or is evaluated after an assignment. This is why you can create conditional assignments like so:

user = User.find_by_id(1) || User.new

In the above code, if a user is found, then the variable is assigned that user. If a user is not found, then find_by_id returns nil (evaluates to false) and a new User is instantiated and assigned to the variable. If you were to use or in the code above, then when find_by_id returned nil the variable would be assigned nil as the assignment operator takes precedence over the or operator.

Example

Here’s a contrived example to show the difference between the two. Given the following class:

class Tester
  def self.a
    p "In Tester.a" 
    return true
  end

  def self.b
    p "In Tester.b" 
    return false
  end
end

Here are some expressions and their results:

>> x = Tester.a || Tester.b
"In Tester.a" 
=> true
>> x
true
x = Tester.a or Tester.b
"In Tester.a" 
=> true
>> x
=> true

So far they look identical… But, let’s change the order things are invoked.

>> x = Tester.b || Tester.a
"In Tester.b" 
"In Tester.a" 
=> true
>> x
=> true
>> x = Tester.b or Tester.a
"In Tester.b" 
"In Tester.a" 
=> true
>> x
=> false

Now we see the difference! When the invocation of Tester.b finishes, then the assignment operator is invoked, thus assigning false to the variable. Notice that Tester.a is still invoked, but it is ORed with the result of the assignment.

Lazy (Shortcircuit) Evaluation

Both and and && evaluate to true only if both operands are true. They evaluate the second operand only if the first is true (this is sometimes known as shortcircuit evaluation). The only difference in the two forms is precedence (and binds lower than &&).

Similarly, both or and || evaluate to true if either operand is true. They evaluate their second operand only if the first is false. As with and, the only difference between or and || is their precedence.

Precedence of and and or

Conclusion

Update: Jay Fields has a post about this same topic. Marcel Molina, Jr. said in the comments that he prefers not to use either form as it is easy to introduce subtle errors.

Have you ever had the feeling that something was missing, but you weren’t quite sure what it was? I was looking at my code coverage the other day and thought to myself that it seemed like I was missing something. Rather than go through each file manually to see if it had an associated spec, I created a small rake task that does this for you.

The rake task looks at all the files in your app directory and tries to find an associated file in the spec directory. It follows the current Rspec generator naming conventions and if it doesn’t find the associated file it runs the generator to create it. It assumes that your app directory and spec directory follow the same directory structure and that you should at least have one test file for every application file.

You may find this as part of the Rake Tasks plugin over at Integrum.

To install:

script/plugin install http://svn.integrumtech.com/public/plugins/rake_tasks/

OR

piston import http://svn.integrumtech.com/public/plugins/rake_tasks/ vendro/plugins/rake_tasks

(Piston is one of my new favorite tools)

My additions are two rake tasks:

rake spec:check     # Check files in the app directory for corresponding test files in the spec directory.
rake spec:sync      # Check for missing test files in the spec directory and create them if they don't exist.

If you’re using Subversion, then you can also use the Subversion tasks that come with the Rake Tasks plugin to add the new spec files to your repository:

rake svn:add        # Adds new files to subversion
rake svn:remove     # Removes missing files from subversion
rake svn:ignore     # Configures svn:ignore properties on log, tmp, db/schema.rb and config/database.yml
rake svn:conflicts  # Resolves all svn conflicts by keeping the working file

This plugin was also the original home of some tasks that you may already be familiar with (I use them all the time):

rake db:create      # Creates the databases defined in your config/database.yml (unless they already exist)
rake db:drop        # Drops the database for your currenet RAILS_ENV as defined in config/database.yml
rake db:reset       # Drops, creates and then migrates the database for your current RAILS_ENV

Those three were merged into Rails edge in May of this year.

Thanks to Josh Knowles, Derek Neighbors, and Josh Huckabee for their feedback on the addition. If you have any comments, bugs, patches, questions, etc. please send them my way.

When I switched the blog to Mephisto I had installed the Gravatar caching plugin. It seemed to be working fine prior to deployment, but once in production it was not working as expected. Today I finally tried to track down what was wrong. hopefully this will fix any problems with Gravatar images, creating comments, etc. I won’t be so bold as to say this will work for everyone, but it works for me :)

My first problem was that Gravatar images were not displaying at all, even when the email address had an associated Gravatar and the plugin had cached the file. I could navigate to the image directly and see it was correct, but the plugin was not finding it. After some debugging, I noticed the file exists check was using a relative path. By changing this to an absolute path I was able to see images. Woohoo!

lib/mephisto_gravatar_cache.rb (line 14)

- if File.exists?("#{GravatarAPI.cache_dir}#{md5_email}.gif")
+ if File.exists?(File.expand_path("../#{GravatarAPI.cache_dir}#{md5_email}.gif"))

Next up was an annoying error message that was appearing whenever someone posted a comment. It looked something like this:

Cache Gravatar for => somebody@gmail.com
=> gravatar NOT FOUND at www.gravatar.com
Content-Type: text/html; charset=utf-8
Status: 302 Found
Location: http://millarian.com/2007/8/22/striving-for-100-percent/comments/121#comment-121
X-Runtime: 8.55324
Cache-Control: no-cache
Content-Length: 146

<html><body>You are being <a href="http://millarian.com/2007/8/22/striving-for-100-percent/comments/121#comment-121">redirected</a>.</body></html>

Same thing happened even when a Gravatar image was found… Nobody was safe from this problem. I did a search in the source for where “gravatar NOT FOUND” was being output. This message was being logged and put to the console, so I simply wrapped it in a conditional to output the results only in development mode, like so:

lib/gravatar_api.rb

def self.explain(msg)
  # create a new logger if it doesnt already exist
+ if ENV['RAILS_ENV'] == 'development'
    log.info(msg)
    puts(msg)
+ end
end

This seemed to solve that problem.

While I was exploring the Gravatar cache plugin I also rewrote the cache_gravatars rake task to be a little more efficient and, since I exclude the explain for production, to output a listing of what’s happening.

tasks/mephisto_gravatar_cache_tasks.rake

desc "WGET all gravatars for all email addresses in contents table (comments). Call with RAILS_ENV=production (else defaults to development env)" 
task :cache_gravatars => :environment do |t|

  # get all the comments that have an email address
  ActiveRecord::Base.establish_connection(RAILS_ENV.to_sym)
- comments = (Comment.find :all).collect {|c| c if c.author_email?}.compact
+ comments = Comment.find(:all, :select => "author_email", :conditions => "author_email IS NOT NULL AND author_email != ''", :group => "author_email")

+ puts "Caching Gravatars for:" 

  # try caching a gravatar for each comment
  comments.each do |comment|
+   puts " - #{comment.author_email}" 
    GravatarAPI.cache_gravatar comment.author_email

    # be nice to gravatar.com, wait a second before next request
    sleep(1)
  end
end

Please let me know of any other oddities using the information in about. Thanks!

If it wasn’t obvious from my last two posts I’ve been doing a lot of testing. In fact, I spent almost the entire day yesterday writing tests. This got me thinking about the value of testing.

With the testing I’ve done recently, I feel like I’ve uncovered several problems that would have made it through to production. This is good. Testing first forces you to think about what you’ll be developing before you ever develop it. I think this has helped me to write better code and, to me, this has value.

However, when I consider the quest for attaining 100% code coverage I start to waffle on the value of that activity. It seems like a blind generalization such as “we must have 100% code coverage” is neither practical nor valuable. When it comes to coverage, it seems that high profile functionality should be well tested, probably 100% covered. High profile functionality being functionality that is executed easily and often, functionality with high consequences, etc. But does it really make sense to spend a lot of time trying to get code coverage on something that will probably never happen and where, even if it does, it has little to no impact on the system? To me, this doesn’t seem like a valuable activity. If it’s easy to test, then go for it. But if it starts to become a time-sink then it might be time to think about whether you’re really adding value.

If testing should be as easy to do as not, then should 100% really be the goal? Is not striving for 100% a cop-out?

I’ve been doing a lot of Rspec testing lately. Although I’ve been using it for a while to do BDD I realize that I have not been testing things as well as I should. Yesterday I was trying to add tests for a helper method that ensures the passed in block is only output if the user is logged in and an administrator. It’s a fairly simple helper method.

def admin_accessible(&block)
  if logged_in? and current_user.admin
    concat(capture(&block), block.binding)
  end
end

I stumbled in the test though as I was unsure of how to test a helper that accepts a block. With the help of my colleague we came up with the following two solutions to this problem.

describe ApplicationHelper, 'invoke admin_accessible helper, when logged in as admin' do
  before(:each) do
    @user = mock("user")
    @user.stub!(:admin).and_return(true)

    self.stub!(:logged_in?).and_return(true)
    @block = "Testing admin_accessible" 
  end

  # Solution 1
  it 'shall return captured block' do
    html = eval_erb <<-ERB
      <% admin_accessible do %>
        <div><%= @block %></div>
      <% end %>
    ERB
    html.should have_tag('div', @block)
  end

  # Solution 2
  it 'shall return captured block' do
    _erbout = "" 
    html = admin_accessible do
       _erbout << "<div>#{@block}</div>" 
    end    
    html.should have_tag('div', @block)
  end
end

Do you know of a better solution?