The Hippy Hacker

RVM + Bundler + RubyMine

Fri, 29 Jan 2010 14:09:27 GMT

On my current project, we needed to be able to use RVM with Bundler but we want access to our bundled gems from Rubymine.

You’re going to want to write an alias in your .bashrc/.zshrc/.whatevershrc for this one. You can use most of the below:

export PROJECT_PATH=the_path_to_your_Rails_project_using_bundler_goes_here
alias rubymine="rvm ruby-1.8.6-tv1_8_6_287 ;\
export GEM_HOME=#{PROJECT_PATH}/vendor/bundler_gems/ruby/1.8;\
export GEM_PATH=${GEM_HOME};/Applications/RubyMine\ 2.0.1.app/Contents/MacOS/rubymine"

What we’re doing here:

We then override the gem repo to point to our bundled gems (which are conveniently formatted as a gem repo)
Then we fire up Ruby Mine with the above environment (Thanks to Brennan Dunn here).

Now close and reopen your shell.

From there, you go into RubyMine’s settings, click on “Add SDK”…

… unhide the hidden directories like so…

… then navigate to your Ruby VM and hit OK:

Voila!

Mocking mocking (or "Why I am learning to hate isolating the unit under test")

Mon, 25 Jan 2010 20:47:11 GMT

Mocking basically sucks.

There. I said it.

Using mocks in your tests almost always results in fragile tests.

Why?

A case against mocking

Let’s say that you’re working on a hypothetical (simplified) financial application:

class AccountTest < ActiveSupport::TestCase
  setup do
    @balance = 42.00
    @account = factory_to_create_a_test_account :with_balance => @balance
    @mock_bank_manager = mock(BankManager)
  end

  def test_overdrawing_account_sends_notification
    @mock_manager.expects(:notify_of, :overdrawn_account, :amount => 1)
    @account.withdraw(@balance + 1)
  end
end

The above example is attempting to illustrate how mocks can be useful for specifying a causal relationship. “Overdrawing the account” results in “notifying the bank manager of the amount over balance”.

Mocking seems like such a natural and even expressive way to design an API. It’s, quite literally, behavior driven development: your tests/specifications, where you are mocking the API, are helping you design the API itself! That’s terrific.

So let’s pretend that, like a good TDDer, I’ve gone and implemented the BankManager class.

class BankManager
  def notify_of(event_type, options = {})
    case event_type:
    when :notify_of
      # send the notification
    when ...
      ...
    end
  end
end

Perhaps I even wrote a test/spec for BankManager. But, then, in a fit of refactoring rage, I decide that I must have a second argument to BankManager#notify_of:

class BankManager
  def notify_of(event_type, account, options = {})
    case event_type:
    when :notify_of
      # send the notification
    when ...
      ...
    end
  end
end

Our old friend AccountTest above will still pass because it’s using a mock. However, the API to BankManager has changed; we want AccountTest#test_overdrawing_account_sends_notification to fail!

So, in short, mocking an internal API is a recipe for pain and (Ni!) woe.

After you implement the API, you still have mocks lying around in the test that helped you mock out the API design in the first place. This test is now fragile. If the API changes, the tests containing the mocks will still pass!
You can double back and replace those mocks with actual calls to the API but you just made more work for yourself

Where mocking makes sense

In my experience, the only place that mocks have served me at all well is when I’m interfacing with an external service from a unit test. I certainly don’t want my unit test invoking services beyond my own system. I usually write an interface layer between my business logic and the external service. In my unit tests, I then mock the interface layer only. Testing integration with the external service, predictably, becomes a chore solely for the integration test.

We have the technology. We can rebuild it.

I believe that there is a better path: one that will let us have our mocking cake but now force us to eat brittle tests. I’ve had some ideas about this on the back burner for about a year now. However, I hope to have something concrete to discuss in a few weeks.

On Craftsmanship and Practice

Mon, 11 Jan 2010 23:26:06 GMT

Reading a passage from the “E-Myth Contractor” got me to thinking about how we practice (when we practice) our skills that we apply on a regular basis.

When we practice our craft, performing “katas” as they have come to be called, why do we perform them on arcane problems such as Langdon’s Ant or Conway’s Game of Life?

You don’t encounter these problems in your day-to-day work.

I agree that solving these problems a few times over may improve your overall problem solving skills. But that’s only true until you settle on an optimal implementation.

Given the above then there seems to be greater value in routinely exercising what we consider routine.

If I can build a signup, login,and forgotten password capability, a text-based search across multiple model objects, or a recurring payment ecommerce system rapidly and reliably, isn’t that more valuable to most customers than finding clever ways to move a hypothetical ant around a grid? These are the sorts of tasks that we routinely encounter in our work. Or perhaps not. Maybe you typically employ a CMS to expedite these chores. This is because craftsmen use tools to work in their craft.

So you should be practicing with those same tools.

If you have a good toolbox, full of tools ideally suited to solving problems your typical problems, then these tools are your weapons. Each tool probably does certain things better than others. You should then practice “weapon katas.”

You should master your tools.

Let’s assume for a moment that your current project/product/service du jour is not a unique and special snowflake. If what we do is a craft, then repetition and understanding of the routine tasks should enable us to deliver faster, more reliably, and more consistently.

Perhaps studying Langdon’s and Conway’s, ultimately, is a study of basic forms, i.e. this is how I BDD something different. Once we grasp these basic forms, it is then time to move on to how we employ our tools, i.e., our favorite plugins and gems, until we’ve mastered those as well.

Doesn’t this make us better craftsmen?

… that is, until someone introduces a better weapon.

I freely admit that this is not how I currently practice. I feel that my basic form is solid. Howver, I admit, I do need to better acquaint myself with my weapons. As of now, this is what I intend to practice. I will try to report on how it goes.

Shouldn't developer tools be for developers first?

Mon, 04 Jan 2010 22:45:18 GMT

As (I believe) Jonas Nicklas pointed out in response to ThoughtBot’s post on integration testing, Cucumber is largely ineffectual in a project until you build up a library of domain-specific matchers and their respective code blocks.

What this represents is external domain-specific language design via regular expression.

The reasonable use of this is to facilitate the expression of desired behaviors by non-developers. For example, I have tell of organizations where QA people, for instance, write automated acceptance tests using Cucumber.

I share the Cucumber team’s belief that customer communication is essential. That’s facilitated, in Cucumber, by writing features in plain text (Gherkin). Cost is saved when issues are addressed in specs versus code – likely why the waterfall model was so popular at first. It’s just common sense.

It’s a form of risk management.

Every feature goes hand in hand with the risk that it will fail to be implemented to meet customer expectation. A risk becomes an issue, in this case, when a feature is implemented in a fashion differing from the customer’s expectation. The earlier that risk is mitigated, the less money/effort/time is wasted on the project handling risks that manifest into issues.

One way of mitigating that risk is to communicate to the customer how that feature will behave in the language of the customer’s domain.

Coulda solves the same problem. It has a rake task for marshaling the Feature, contained Scenarios, and all of the statements (Givens/Whens/Thens) into plain text.

However, Coulda shares many of the considerations Dan cites above:

“Features” are just Test::Unit::TestCases
“Scenarios” are just tests
“Statements” (Given/When/Then) are just steps taken within a particular test

When I use Coulda on a project (I’ve used it on the job at this point), I don’t start with the intent of building a language. I know that I probably will, because I have, as my work progresses. I start by writing pending Features, pending Scenarios, pending Statements, and then I begin putting flesh on the bones. I refactor my tests. When I encounter duplication within a Feature, I Extract Method. When I encounter duplication across Features, I Extract Module (I’m guessing that’s in Ruby Refactoring but you likely get the intent: I create a module, move my method into the module, and include the module in my Coulda Features), and so on.

What bothers me so much about so many libraries, in general, is that they try to solve all of my problems.

That’s great but I don’t want that. Just like I don’t want to buy a car with a 500hp engine because I simply won’t need it. I just need a car.

So I kept Coulda simple. If you need more, great, then write it! If you find that you need the same thing repeatedly, great, make a new gem from it!

Automate what you need to do often. If you have an edge case, keep it out of your libraries, thank you! My brain has a hard enough time absorbing the ever-increasing size of the Rails API (and this from a guy who worked in J2EE hell for years).

Remember, these are the kinds of practices that gave us Rails. Don’t try to solve everyone’s problems. Focus on the frequently recurring problems. Scratch your own itch (I did!).

"Grid" layout in Android

Sat, 28 Nov 2009 15:09:25 GMT

You know how your mother (or, in this case, your front end developer friends/colleagues) always say “never use a table for formatting unless you’re really making a table”

That may be true for HTML. However, it doesn’t seem to hold when you’re working with Google’s Android.

You see, now that I have a shiny new Motorola Droid (see my previous post), I’m now working with Android in my spare time.

I was struggling with using Android’s UI XML to layout a simple login page. And I was going nuts.

I was trying to use A LinearLayout containing several RelativeLayouts, one for each row. “Row” should have been the clue.

After poking through the PragProg Hello, Android book for a bit, I found an example later in the book that used a TableLayout.

That was my aha moment.

TableLayout is pretty simple to use. It is designed to contain several TableRow (a ViewGroup child as are other *Layouts). A TableRow looks thus:

<TableLayout
  android:layoutwidth="fillparent" 
  android:layoutheight="wrapcontent"
  android:stretchColumns="1" 
  android:padding="10dip" >
  <TableRow
    android:layout_marginBottom="10dip">
    <TextView
      android:id="@+id/login_label"

      android:layoutheight="wrapcontent" 
      android:text="@string/login" />
    <EditText
      android:id="@+id/login_field" 
      android:layoutwidth="fillparent" 
      android:layoutheight="wrapcontent" 
      android:lines="1" />
  </TableRow>
  <TableRow
    android:layout_marginBottom="10dip">
    <TextView
      android:id="@+id/password_label" 
      android:layoutheight="wrapcontent" 
      android:text="@string/password" />
    <EditText
      android:id="@+id/password_field" 
      android:layoutwidth="fillparent" 
      android:layoutheight="wrapcontent" 
      android:lines="1" />
  </TableRow>

</TableLayout>

The android:layout_marginBottom attributes on the TableRows are entirely optional. However, odds are that you will want to add some sort of formatting to your TableRows.

Incidentally, there may be DRYer ways of representing rows in Android XML (i.e., something similar to a Rails partial); however, admittedly, I’m still very much learning Android.

A brief review of the Motorola/Verizon Droid

Sun, 08 Nov 2009 14:37:25 GMT

On the last leg of the return from my road trip, I picked up a Droid from the Best Buy in Salisbury, MD.

In a nutshell: I love it.

And, yes, more than an iPhone.

Why?

The Device

From photos, I had thought that the Droid was just an ugly brick. In the “flesh”, it’s more like an F-22: oblique surfaces but with rounded edges. This results in a device that is comfortable to hold with or without the keyboard open (which, sadly, I could not say the same of my former Palm Pre; it could be painful to type upon).

The Droid is a heft to it. It feels like it means business. And it’s solid: no flimsy plastic casing here that gives when you squeeze it.

The keyboard slides open easily enough, snapping in place when fully open. However, there are no springs involved; the slider requires gentle but constant pressure. The keyboard itself is spacious enough. However, I haven’t seen keys like this since the old Timex Sinclair home computer. The keyboard is covered in a slightly flexible but thick sealed plastic. The keys are only barely raised above the slider with the actuators themselves set in the slider.

While the keyboard takes some getting used to, I can tell that my typing is already improving.

The speaker on this thing is amazing. In fact, audio, overall, is lovely. But the speaker is simply the loudest that I’ve heard in any smartphone – even louder than the Pre.

Oh, and the device uses micro USB. I had never seen this connector before the Amazon Kindle. However, it seems to be becoming more common on contemporary smart phones.

The Software

Speaking of keyboards, Android 2.0 comes with a soft keyboard. However, I’m sad to say that this is not an iPhone keyboard. I could type lightning fast on the iPhone. When I start to work up a head of steam on the Droid’s virtual keyboard, I notice that the virtual keyboard seems to acknowledge that I’m tapping keys; however, the letters themselves do not always make it into the text area that I’m editing. However, I don’t encounter this problem when using the physical keyboard.

Do I really need to tell you about Google Navigation? It’s awesome. Jaw droppingly awesome.

Otherwise, it’s an Android phone. However, that is not a bad thing, as it happens.

Customizing the Droid

Unlike Apple, neither Google nor Verizon put much in the way of restrictions on the Droid. Background apps? Check (although watch that battery, folks). Re-skinnable user interface? Check. Crappy Facebook app? Check (woops. Nice one, Facebook).

Quirks

I’ve had a few minor problems with the Droid in the first 48 hours.

Occasionally, the Droid has a difficult time connecting to my wifi network. That may be because I run an 802.11g network with a range extender; the Droid may occasionally have a difficult time selecting which access point to use.

Also, this morning, I noticed that the devices speaker volume dropped significantly. Rebooting the phone solved the problem.

A few times, I’ve had an app randomly open unbidden while I was in another app. The android revolution begins? At least it didn’t a suction cup, an eye stalk, and intone, “Exterminate!”

And then there’s the virtual keyboard issue that I mentioned above.

Overall

I’m extremely pleased. Yes, so pleased that I don’t miss my iPhone (although I do miss Cultured Code’s Things).

Now if only the API wasn’t pure Java and/or the Dalvik team would fix this damn bug so that I could write Android apps in JRuby (or pick your interpreted JVM language of choice that relies on reflection to get anything done).

In the meantime, it’s time to learn some Scala…

A meditation for the (aspiring) Rubyist

Sat, 07 Nov 2009 17:56:04 GMT

You’re new to programming. You’ve got an idea that you’re aching to make manifest. You’ve heard of this awesome Ruby on Rails thing. You’ve even bought Agile Web Development with Rails [AWDR]. Now what?

Yes, you can probably take AWDR and try to use Rails right away. However, if you want to do anything the least bit different from the examples in AWDR, you’re in for some trouble.

Hold your horses there, cowboy. You’re just starting to learn how to walk, someone gives you an airplane, and you’re going to fly it?

Bad idea.

So where to begin?

First learn some Ruby

Over the past couple of months, I’ve given several informal introduction to Ruby classes – sometimes on a one-on-one basis and other times for small groups of five to ten people. In that time, I’ve received the same good question a couple of times: can you point me at a few good books and or blogs to read that will help get me started?

Well, maybe. The Pragmatic Programmers offer a book called Learn to Program which, as it happens, uses Ruby as its language of choice. Lacking firsthand knowledge of the book, I’m a little hard-pressed to recommend it.

Most of the technical books that I consume are targeted at programmers with at least a modicum of programming experience in some language. Even the the “Pickaxe” or the O’Reilly Matz-Flannigan (sp?) Ruby books are really aimed at, at a minimum, the somewhat experienced programmer.

Besides, we learn by doing, not reading. This is why several small businesses offer Ruby training. However, training is expensive. It’s short. It’s chock full of knowledge. And if you don’t use that knowledge right away, you lose it before it can become experience.

Where’s an aspiring Rails/Ruby developer to turn?

Meditate on it

Jim Weirich created a wonderful teaching tool called the Ruby Koans. The Koans come complete with the simple instructions necessary to execute them. Learning comes from solving each tiny problem, one after another, that Jim presents along the path.

While I haven’t discussed the Koans with Jim (maybe at Scottish Ruby Conf next year), I believe that the Koans may have been initially aimed at rounding out experienced Rubyists. However, I’ve found that they are so simple yet so informative that I recommend them to nearly every Rubyist, beginner and otherwise.

A side-effect and bonus resulting from the Koans being hosted on Github: several people who have completed the Koans have posted their work on Github as well. If you get stuck, you’ve already rifled through your “Pickaxe” or O’Reilly Ruby book, and are pulling your hair out in frustration, you can look at how someone else solved the particular Koan.

Just be sure to meditate on those easily acquired answers.

Playing with Proc#bind

Thu, 05 Nov 2009 22:23:53 GMT

When I write internal DSLs in Ruby, I tend to do so by leveraging Object#instance_eval. #instance_eval is powerful because it’s yet another way that you can repoint self in Ruby. Object#instance_eval executes its supplied Proc in the context of the calling Object Below is a simple example.

  def car(&block)
    # self is "main" (an Object) here
    c = Car.new
    # self refers to Car instance when Proc is evaluated on the line below
    c.instanceeval(&block) if blockgiven?
    c
  end

class Car

    def make(v); @make = v; end
    def model(v); @model = v; end
    def engine(v); @engine = v; end
  end

car do
    make "Ford"
    model "Fusion"
    engine :piece_of_crap
  end

You could implement the same code by replacing Object#instance_eval with calls to Proc#bind as follows:

  def car(&block)
    # self is "main" (an Object) here
    c = Car.new
    # self refers to Car instance when Proc is evaluated on the line below
    block.bind(c).call if block_given?
    c
  end

Remember, Procs are also closures. That is, they take the context within which they were created along with them. For example:

  def make_incrementer
    x = 0
    Proc.new { puts self; x += 1}
  end

inc = make_incrementer
  # Will print 1 to 5 interleaved with "main"
  5.times { puts inc.call }

… gives us …

  # >> main
  # >> 1
  # >> main
  # >> 2
  # >> main
  # >> 3
  # >> main
  # >> 4
  # >> main
  # >> 5

Wherever you pass that Proc, when you call it, puts self would always say main (which is just the “root” Object of the Ruby interpreter).

So now we add the following code:

  class Foo
  end    

foo = Foo.new
  rebound_inc = inc.bind(foo)

5.times { puts rebound_inc.call }

We didn’t change the Proc. We just created a Method, rebound_inc, where self now points to our instance of Foo_. So our code, with the above additions, when executed, now returns:

    # >> main
    # >> 1
    # >> main
    # >> 2
    # >> main
    # >> 3
    # >> main
    # >> 4
    # >> main
    # >> 5
    # >> #<Foo:0x10019092>
    # >> 6

    # >> #<Foo:0x10019092>
    # >> 7

    # >> #<Foo:0x10019092>
    # >> 8

    # >> #<Foo:0x10019092>
    # >> 9

    # >> #<Foo:0x10019092>
    # >> 10

In the example above, reboundinc_ is still a closure over x, defined in make_incrementer, but it’s self now points to whatever object we like.

Proc#Bind with Bobby Wilson

Wed, 04 Nov 2009 20:53:02 GMT

The Friday before I left Floyd, I had the opportunity to sit down with Bobby Wilson of Entryway. Bobby and I had been hacking earlier on a hypothesis of mine that ActiveSupport’s Proc#bind could be used effectively to write a DSL instead of somewhat more evil/ugly approaches using Object#instance_eval. Ironically, I found earlier this week that Shoulda already does just that. However, it was fun coming to the same conclusion on my own.

Proc#bind is a funny beast. It effectively converts a Proc into a Method object where self refers to the parameter passed to Proc#bind.

class Proc #:nodoc:
  def bind(object)
    block, time = self, Time.now
    (class << object; self end).class_eval do
      methodname = "bind#{time.to_i}_#{time.usec}"
      definemethod(methodname, &block)
      method = instancemethod(methodname)
      removemethod(methodname)
      method
    end.bind(object)
  end
end

Here’s how it works:

Defines a method on self’s (a Proc) singleton class using the Proc itself as the method implementation
Grabs a handle to the UnboundMethod representing the Proc
Removes the method from the Proc’s singleton class (but we still have the UnboundMethod from step 2)
Binds the UnboundMethod to the object passed to Proc#bind, returning a Method object

Afterward, Bobby and I sat down to BS for a bit about how much we needed beer (hey, it was Friday evening), discuss Proc#bind, and the merits of describing oneself to non-software craftsman as a software craftsman.

Interview with Bobby Wilson from Evan Light on Vimeo.

Facebook Connect w/ Facebooker

Tue, 03 Nov 2009 14:10:50 GMT

Facebook Connect seems to be well on its way to becoming the most popular third party authenticator on the market. While Facebooker provides support for Facebook Connect, the Connect features are given only a light treatment in a blog entry by Mike Mangino (one of Facebooker’s authors). In this article, I will attempt to fill in some of the blanks left by that entry.

After following Mike’s example, I put _fb_logout_link in my template, clicked on it, but found that my web app was still convinced that I was logged into Facebook. That is, I still had the facebook_session object in my webap. Mike’s article show’s how to handle logging in to Facebook Connect; however, logging out was causing me frustration.

The below seemed to work for me:

In your ERB (for example), you will want:

<%= fb_logout_link "Logout", "/logout" %>

fb_logout_link will log you out of Facebook; however, it does not seem to nil out the the facebook_session object referred to in Mike’s example. As such, you’ll want to map “/logout” to an action that will do this for you. The logout operation should look something like:

def logout
  # ...
  clear_facebook_session_information
  # your redirect here    
end

clear_facebook_session_information is a method in the Facebooker::Rails::Controller module that will do exactly as the name says