Continuous Thinking

The Fallacy Of Fast, Putting Test Execution Speed In Its Place

2012-02-04T00:00:00-05:00

A colleague recently sent over a link to Corey Haines video on Fast Rails Tests from GoGaRuCo 2011. From watching this it got me thinking about fast tests and a common misconception that people have. For the record, Corey is not one of those people, but his talk got me thinking about this topic.

The Problem

People are becoming obsessed with execution speed, almost entirely. They’ve got umpteen thousand tests that execute in 2 seconds. On the surface this is awesome! Unfortunately, this can be a false achievement (but not always) that their tests test a whole lot of nothing and end up being quite brittle. Mocking is used, but inappropriately and way too much. The tests end up being incredibly fast but not very valuable.

Speed Kills

I’ve gone through my own Michael Angelo Batio phase in the past I’m not simply speculating. I’ve been in those trenches, I’ve experienced it, I’ve done it, and I’ve seen others succumb as well. Faster tests are better; they will be executed more frequently; they will provide faster feedback loops; they will be the cause of less idle time for the developers who sit and wait for the test suite to finish running. But fast is not the primary goal. It is merely one of the forces at play that we as developers must figure out how to resolve.

Goals of Testing

The primary goal for tests is to help continually drive the development of software over time. The broadness of this statement is intentional because there are many things at play which impact our ability to reach this goal. Things like: behavior validation, reliability, readability, frequency of execution, design/testability, etc.

Behavior Validation

Of these the most important thing is behavior validation. Without it the others don’t matter: they are pointless. If you have 100,000 examples that run in 5 seconds, but they’re not testing actual behavior of the components than you are providing nothing but empty statistics. Behavior validation is not about speed, it’s about behavior.

Greenhorns have slow, ugly, poorly designed tests. Those who have more experience and are better at testing will see a million ways to improve these tests. It’s tempting to simply throw at them all of the other things they should be doing, but all in good time. First and foremost, we need to make sure we all have this basic principle of testing under our belt. Otherwise, we’ll be putting the cart before the horse so-to-speak.

Reliability

Reliability is the next important. It may seem like a given but in many cases it is not and it often has to be learned through hard-ship and experience from people new to testing. Tests need to execute reliably all of the time. For unit level tests and examples this is the easiest because there are the fewest things at work in the test. For higher level (functional, integration, etc) this gets trickier because there are more things at play and which need to be considered.

Test Order Independence

There are multiple ways to look at reliability. One way is to run your test suite in backwards or random order (RSpec supports this). This will find tests which have dependencies on the order in which other the tests are run. Tests should reliably and consistently pass regardless of the order you run them in.

Component Independence (Isolating System Under Test)

Another way to consider reliability is thinking about it in terms of unexpected dependencies. For example, if we are testing something simple, like, the requirement that a User has a name, then when we change the Account, our test for that User validation should not fail. There are a number of cases where unexpected changes in other parts of the system impact our test. In some cases, this shows we have bugs, in other cases, it shows that our tests are not reliable because they are being impacted by things that have nothing to do with the behavior the test focuses on.

Reliability is so basic, yet it is often misunderstood. The less reliable the tests are the harder it is to trust them and have confidence in your system and continue to evolve the system swiftly. Unreliable tests put the tests themselves in question.

Readability

Readability is next down the list. As much as it pains me to make this third, I think it is the proper place for it. Being able to understand and have others understand your tests is hugely important. I have seen countless tests which test many things (some indirectly) and it is hard to determine what exactly they’re testing. Readability goes a long way to ensuring that the code can evolve, change, and maintain with much greater ease; irregardless of if its you or someone else doing the changes.

However, you can extract out readable tests from those that lack readability but still test actual behavior of the system and its components. It may be tedious and take longer, but it can be done. A good place to start here is to focus your tests around a single behavior of a component in the system and to strive to achieve one assertion per test.

Frequency of Execution

Here are we now: frequency of execution. This is where having fast tests become important. The faster they are the more they get executed. The more they get executed the quicker the feedback loop is which directly impacts all of the above things. But without the above things (except maybe for design) speed doesn’t matter: you just feel good about seeing more dots on the screen.

Having 100,000 tests pass in 5 seconds doesn’t mean you have 100,00 meaningful tests (although you may). People who get bit by the speed bug early on fall into the trap of over-mocking. They end up testing the mock library in various ways but don’t actually test their software. It’s a rather interesting phenomenon: we are providing countless creative ways to ensure mocking libraries in many application domains. This results in a meth-like high, feeling great about the number of examples, and speed of execution. At some point, the high ends.

But there are simple things you can do to increase execution speed without sacrificing value while you are learning how to best utilize things like mocking libraries. And Corey offers a great tip in his video: spec_no_rails/. Have a folder which doesn’t boot up the entire framework, but has tests for things that don’t actually depend on the framework being loaded.

Designing for testability, which is up next, is also a great way for increasing the speed of tests because you’ll be able to separate out the behavior into their rightful places and test them largely independent from one another.

Some other things that impact test execution speed is the language or framework itself. For example, Ruby 1.9.3 is much faster at loading and executing code than any earlier versions. And Rails 3.2 has a number of performance enhancements.

Design, Testability

Lastly (for this list at least), as we grow and become better at the above four we will begin to find ourselves exploring new ways of using tests to help drive and shape the design of our code. This often means we get better at applying better design practices in our code like Single Responsibility, Loose Coupling, etc.

Whether we test drive or test after we begin to use our experiences and newfound abilities to shape the design of your software so the behavior can be tested, reliably, and in a readable manner. This means that tests become a heavy influence on your design. Your code becomes testable. And before you know it you’ll be telling people you design for testability.

The Balance

In terms of balancing, we should err on the side of having good reliable tests first. It is more valuable to have a good reliable but slow test opposed to a fast, meaningless test. We can always come back to the slow test and find ways of improving its execution speed, but that should come after we are sure it’s doing its job (testing behavior) and doing it consistently (reliably).

Conclusion

Speed of execution is important but its importance is relative to the other properties at play. And all of the properties impact one another, but they are not all equally important. As we grow in all of these areas we are able to explore more advanced ways of achieving all of these. But speed must come after the ones before it are working to the advantage of our ability to ensure that our software is working. Otherwise, we may end up we good conference conversation and not much else.

There are other important things related to testing that were left out of this post. And the above areas could all have been taken to much greater depths. This post was a quick attempt to raise to the surface an issue I see with inexperienced testers latching onto things like fast tests without first understanding writing a good reliable test.

Language impacts our ability to create

2012-01-29T00:00:00-05:00

Christopher Alexander, from his infamous book The Timeless Way of Building:

If your language is empty, your buildings cannot be full. If your language is poor, you cannot make good buildings until you enrich your language. If your language is rigid, your buildings must be rigid. If your language is florid, your buildings will be florid. Your language generates the buildings you make, and the buildings live or not, according to the life your language has.

Replace buildings with software and what Alexander says still holds true. The breadth and depth of our language directly impacts our ability to craft, at every level, software.

rspec-requestable-examples

2012-01-28T00:00:00-05:00

Recently, while refactoring legacy code in a system, we found core domain rules that were not being clearly expressed in the application, neither in the code nor the end user. As a result, the burden of knowing all of the rules was pushed onto the user, and when the system did enforce a rule, it would likely just break for the user, not help the user move forward. Unfortunately, this “legacy” code was legacy because there was no test coverage for these rules; their logic was cryptically spread throughout the code of the application in a few really large classes which mixed far too many responsibilities and abstractions.

We decided to catalog all of the rules first through exploratory testing and inquiry with our client, users, and other developers. We found several simple rules like:

splits words on new lines
strips leading and trailing white-space
strips leading and trailing periods
strips double quotes
strips single quotes
strips empty lines
strips line filled only with white-space
replaces any white-space character in the middle of a term w/a single space
removes duplicate words

There were many more rules just like these (30 to be exact). None of them by themselves were very complex, but many of them were used in combination to make certain types of word lists. These rules were what we wanted to capture in good unit-level tests around the different types of word lists.

While writing these tests (specs) we found an interesting property of our rules. They wanted to break out of stock functionality provided by RSpec. This led us to create a new RSpec extension which proved valuable to us and may prove valuable to you. Here’s a quick walk through of our experience and what led us to creating a new extension. It starts with writing specs around these rules, and the word lists that would use them.

The First Word List

The first word list was pretty straightforward. We wrote an initial spec (using RSpec) to cover the rules:

describe FirstWordList do
  describe "#list_of_words=" do

    it "strips double quotes" do
      subject.list_of_words = %w("foo" "bar")
      subject.list_of_words.should eq(%w(foo bar))
    end
    
    it "strips single quotes" do
      subject.list_of_words = %w('foo' 'bar')
      subject.list_of_words.should eq(%w(foo bar))
    end
    
    # ... etc more rules ...
  end
end

Using RSpec as-is worked well until we hit the second word list.

The Second Word List

The second word list was similar to the first, and while some rules overlapped, there were others that did not. For example, single quotes were stripped in the first word list, but they were left as-is in the second list. Initially, our first goal was to clearly express the rules in our spec so we could drive code changes. We duplicated the overlapping examples:

describe SecondWordList do
  describe "#list_of_words=" do
    
    # this was copy and pasted from FirstWordList spec
    it "strips double quotes" do
      subject.list_of_words = %w("foo" "bar")
      subject.list_of_words.should eq(%w(foo bar))
    end
    
    # this is a new rule
    it "allows '!, ?, @, #, $, %, &, *, -, +, _ :, .' characters" do
      # ...
    end
    
    # ... more word list rules examples
  end
end

How Can We Re-Use These Examples?

Once we had all of the rules for both of these word lists expressed, we took a step back and asked ourselves: how can we re-use these examples? After all, we still had a third type of word list to add which would also share in overlap with many of the rules.

RSpec’s Builtin: it_should_behave_like

RSpec has a built-in utility to re-use groups of examples. It works by first defining a shared set of examples:

shared_examples_for "a word list" do
  it "strips single quotes" do
    # ...
  end
  
  it "strips double quotes" do
    # ...
  end
  
  it "allows '!, ?, @, #, $, %, &, *, -, +, _ :, .' characters" do
    # ...
  end
end

This lets you include the shared “a word list” examples into your concrete-specs, like so:

describe FirstWordList do
  it_should_behave_like "a word list"
end

describe SecondWordList do
  it_should_behave_like "a word list"
end

The problem with this is that it assumes you have a collection of examples which always go together. While we often find this feature of RSpec incredibly useful, in our case it falls short of the word list rules. We don’t want a collection of examples re-usable together as a set; rather, we want a collection of examples in which we can pick and choose which to run.

A New Approach Sharing RSpec Examples

To solve this problem, we created rspec-requestable-examples, which is an RSpec extension that gives you the ability to defined shared example groups where you can explicitly include which examples to run. We ended up with a new kind of shared example group:

requestable_examples_for "a word list" do
  requestable_it "strips double quotes" do
    subject.list_of_words = %w("foo" "bar")
    subject.list_of_words.should eq(%w(foo bar))
  end
    
  requestable_it "strips single quotes" do
    subject.list_of_words = %w('foo' 'bar')
    subject.list_of_words.should eq(%w(foo bar))
  end

  requestable_it "allows '!, ?, @, #, $, %, &, *, -, +, _ :, .' characters" do
    # ...
  end
  
  # ... more rule examples ...
end

In the above code, we created a requestable_example_for set of example groups. Inside of it we moved all of our individual rule examples from the other specs into here and changed it to requestable_it. Using requestable_it is similar to saying it except it makes the example “requestable”. You can still use it if you’d like, but it won’t be requestable, it will just be a normal example.

Here’s how we explicitly request these new examples from our FirstWordList and SecondWordList specs:

describe FirstWordList do
  it_should_behave_like "a word list", :examples => [
    "strips single quotes",
    "strips double quotes",
    # ...more rules
  ]
end

describe SecondWordList do
  it_should_behave_like "a word list", :examples => [
    "strips double quotes",
    "allows '!, ?, @, #, $, %, &, *, -, +, _ :, .' characters"
    # ...more rules
  ]
end

By pulling out all of the rule examples, we kept them together in a requestable example group. This left the concrete specs to simply specify which rules to run. It could be argued that we could have pulled out only the duplicate rules and created many shared example groups (using shared_examples_for or similar).

One reason we did not do this was for clarity. We felt that it was more important to keep the rules together in a cohesive unit. After all, they are all types of rules to apply to our word lists. This also afforded us the ability to avoid having some rules defined in shared files and others rules defined in the concrete specs. With rspec-requestable-examples, we have one file with the rules, and each concrete spec simply says which ones to use. We felt this kept the specs very robust, readable, and easy to maintain.

The Third and Fourth Word Lists

Using the new concept of requestable examples gave us extreme flexibility in introducing a third type of word list:

describe ThirdWordList do
  it_should_behave_like "a word list", :examples => [
    "strips single quotes",
    "strips double quotes",
    "strips stop words"
    # ...more rules
  ]
end

While creating the ThirdWordList we found found that there was actually a FourthWordList as well; it was as easy to introduce another combination of rules and express it for a FourthWordList:

describe FourthWordList do
  it_should_behave_like "a word list", :examples => [
    "strips double quotes",
    "strips stop words"
    "requires at least one word"
    # ...more rules
  ]
end

Experimenting, Validating, Learning

We could have written our specs and moved on, but we thought there was a better way to get more mileage out of our specs. Our initial attempt was really an experiment. Was there another way to share examples that are closely related, but which didn’t always apply? Would it benefit us to try group the examples that go together – together?

We tried to work with RSpec’s built-in tools, but we wanted to take it one step further, so we explored rspec-requestable-examples. In its initial form, it wasn’t nearly as clean as it is now, but we wanted to see if the idea was worth the time. It proved valuable for the word list rules and within a few weeks following we found it worked well when we had to refactor the user roles/permission system.

Since then we’ve put rspec-requestable-examples up on Github, cleaned up its implementation, added its own Cucumber features, tied into Travis CI, and released it as a stable and stellar RubyGem: rspec-requestable-examples.

And while this doesn’t replace any functionality currently offered in RSpec, it augments what is there to provide another tool to those using it.

More info on rspec-requestable-examples

For general information check out its Github page: https://github.com/mhs/rspec-requestable-examples

For feature requests or issues please report them to its Github issues: https://github.com/mhs/rspec-requestable-examples/issues

This post was featured on Mutually Human’s blog.

activerecord-import 0.2.9 for Rails 3.2

2012-01-20T00:00:00-05:00

Following the release of Rails 3.2 today, activerecord-import has published its 0.2.9 gem. It’s dependencies are now ActiveRecord 3.2 friendly as well as 3.1 and 3.0.

Included in the 0.2.9 release are the following updates:

make 3.2 dependency friendly (Samantha Jones)
internally use ActiveSupport #sum instead of custom #sum_sizes implementation (Ben Woosley)
use connection pool instead of actual connect on load which fixes an issue with using activerecord-import on Heroku (Nat Budin)

If you have any questions don’t hesitate to hit me up on twitter, @zachdennis, or file a github issue.

Integrated Teams: Remote People

2011-12-31T00:00:00-05:00

Five years ago, when we started Mutually Human, we shared the belief that colocation was essential to build the type of community and organization that we wanted to work in, be a part of, and invite others to join. My thinking was primarily around the social and relationship aspects of being physically present with one another. If I am going to spend the majority of my life working then I want it to be with people in situations that have the potential to develop deep, lasting, and meaningful relationships. There are people who are capable of cleanly separating their work and personal lives. I’m just not one of them. For me, it’s all intertwined.

The idea of hiring remote has always made me feel somewhat uncomfortable. Given the amount of emphasis placed on relationships it always felt like hiring remote would never work for us, at least not in the long-term. However, this past year has really challenged many of my own assumptions.

For one, it’s been hard to see people who I’d love to work with end up somewhere else. I’ve also found myself too often asking ‘what if?’ instead of ‘why not?’. As it turns out being human has a way of reinforcing the safety and comfort of colocation: thousands of years of social and genetic evolution. It hasn’t been until the recent advent of technology that being remote, in the ways possible today, has even been possible.

As social animals we’re so used to the obvious benefits of colocation: non-verbal gestures, social gatherings, information and cultural osmosis, and hallway chatter among many others. Have you ever had the feeling when you’re at the white-board with someone and you know its time to stop? Without saying a word, a mutual understanding that you’ve ‘got it’ washes over both of you. That seems rather hard to re-create when you’re not physically present with one another. There will be no more facial cues or non-verbal gestures; no more going back and forth with the marker expanding on what the other just scribbled or drew.

Our brains are quite incredible, interpreting and processing complex and intricate social interactions. This extends to environmental and cultural factors as well. Near the end of the day when I sense someone over by the couches I know its time for standup. Or when everyone in the office congregates around two desks when there are six available a sense of community washes over us. It’s a good feeling when the people prefer the company of each other despite our individual quirks and idiosyncrasies. This all reinforces the type of place we’ve always wanted Mutually Human to be. I think it’s also why considering remote workers has never been as easy as looking for non-remote people. We’re more than simply serving our clients and users, and providing a service. We’re people who like to be around each other.

But, this remote worker phenomena isn’t going to go away. It’s becoming an integrated component in the workplace. In many organizations and in many ways this is already true. 37Signals is one of many companies that is almost entirely remote (Stop Whining and Start Hiring Remote Workers); services like Amazon’s Mechanical Turk make it extremely easy to find remote individuals (different than how this article refers to remote workers) for specific tasks; and my ears are still ringing from a conversation about virtual personal assistants.

For a while now the trend has been the growing availability of remote workers and the shrinking pool of those willing to relocate. At some point, a balance will be found, but I don’t think the industry is anywhere near that yet. Of course, it would be ideal if small teams were fully co-located as we’d be able to take advantage of what social and genetic evolution has outfitted us with. But this isn’t likely to happen as there are too many variables in play culturally, socially, professionally, etc which will continue to give life to the possibilities and realities of being a remote worker. This is especially true in the world of software services and products.

As always, technology continuously has and will evolve how humans interact and organize to get things done. The discomfort felt around embracing these changes are likely a symptom of something bigger; that our social structure as it pertains to the professional world is evolving. This evolution will cause people to experiment and innovate, finding new and adapted means that can be used to achieved desired ends. This will be true whether these ends are technical/professional (e.g. quality products being built) or social/relational (e.g. strong relationships, healthy company culture).

Between the completely co-located and the completely remote lies a middle ground; one where two very different working styles co-exist in an often uncomfortable (but natural) tension; one which when looked on in the right light provides the fuel and discomfort necessary to ignite non-traditional thinking related to how we work to evolve just that – how we work.

Over the past five years, opinions have changed, both mine and those at Mutually Human. Essentially that bringing remote people into the team is more about finding effective means of working together when we can’t use the traditional channels of communicating and interacting. It’s something I look forward to exploring as we continue to grow.

Of Circumstance And Choice

2011-12-31T00:00:00-05:00

Our circumstances and choices progress in tandem pushing against each other; forever interleaving throughout time is the consciousness of our minds and the environment of our circumstance; perpetually leading to a new circumstance and a new choice. This is to say, that, circumstance can influence our choices as much as our choices can influence our circumstance as they evolve together never in isolation, directing our future, being influenced by our past, but always existing in the present.

Although, a stronger mind and a steadier heart, tips the scale in the best of ways; in favor of conscious, intentional decisions in which we are fully present; not allowing circumstance to strip us from ourselves in the temporal situations of the day.

A Day Like Today, A Day At The Office

2011-12-08T00:00:00-05:00

Today, I sat down my standing desk, glanced down momentarily at the orange HTML5 sticker on the closed lid of my Mac Book pro, closed my eyes, and took a deep breath. A moment later I lifted the lid and watched as it awoke from its sleep. So many desktop icons, so many open applications — even the dock is flush from the top to the bottom of the screen. This clutter will have to wait. There’s much to get done.

First things first, open Chrome, check my personal email which there are a handful; a few being spam; a few more being marketing emails; and a couple having originated from real people. I read and respond to those quickly. My work inbox has about three times more emails. Most are automated notifications from service-based apps I use or am working. Most of these simply informational and can be ignored. I prioritize the rest, respond letting people know I’ll get back to them, and minimize this Chrome window to avoid distraction.

With emails out of the way I’m ready to fire up Terminal, see what the latest git commits are for the project I’m working on. A quick “git fetch” and a ”git review” shows me no new commits to merge in. I can continue on the feature from yesterday from right where I left off; which I find in about two seconds — courtesy of “git status” and a convention of putting a giant YOU STOPPED HERE reminder where I left off. A lot of rich client-side JavaScript, HTML, and CSS awaited me. I launch TextMate and embraced it.

Ten minutes in I notice it’s too quiet. My mind is all over the place, focus eludes me. Six seconds later Pandora and Airfoil are filling the room with rhythm. It hooks into my brain and my brain conforms. All of my thoughts begin to move in concert with one another, a pace is set, my focus narrows in on the problem at hand.

Two hours later, I’m getting hungry. I stop typing and take a step back to review the code I just wrote. I review it for consistency with itself and with other parts of the application. I notice the usage of “word-lists”, and “sentiment_lists”. Dasherized or snake-cased? Let’s go dasherized. Next I notice “includes-exclude-list” in a similar view. In the previous examples the suffix “-lists” was pluralized. In this case the pluralization seems misplaced. I update it to “include-exclude-lists” and then do a project-wide search in TextMate and update all of the references from HTML class names to CSS selectors and their usage throughout JavaScript.

After lunch, it’s back to the code. The conventions we’re using for organizing JavaScript on this project is working nicely. If it wasn’t I would have likely switched to Backbone.js or even as far as CoffeeScript. I would love to move this to CoffeeScript, but we’ve got a good, clean, consistent, and convention-oriented approach to the JavaScript. It’s proving to be flexible, predictable, and easy to change. Someday maybe CoffeeScript will make sense, but today, it won’t solve any problems. It would just have been fun.

As it nears standup time, which at Mutually Human is at the end of the day, the feature is finished. After another detailed review of the afternoon’s changes, I discipline myself to make sure I’m being consistent and following conventions. I look over the tests and the scenarios that have been added and decide a few are missing. A few minutes later those are added, so I do a clean commit and push.

After reviewing the next card in which to start tomorrow, I go pick up the guitar and wait for our standup to commence.

Defining a Company

2011-11-19T00:00:00-05:00

Recently, I found this definition in the book Built To Last by Jim Collins and Jerry Porras:

A group of people get together and exist as an institution that we call a company so that they are able to accomplish something collectively that they could not accomplish separately.

This is a cornerstone of why Mutually Human exists and should be a foundational tenet of any company worth starting, building, or joining.

The Beginner's Mind

2011-11-10T00:00:00-05:00

The days before we had formulated opinions, conventions, and tastes; when we gleefully stumbled through unknown obstacles and challenges to garner a little understanding; when we did it whatever way we could because we had no idea what the right way might have been; when “best practice” meant whatever we were doing right then because that was the only practice we had; when every victory no matter how small felt monumental.

Personal Reflection: What I Want Out Of Life

2011-11-06T00:00:00-04:00

Everyone wants something of life. I want something out of mine. I’ve always been able to articulate parts of what I want out of life, but there have always been these elusive chunks. I’d always push them aside and tell myself I’d get to them later. There were always enough things to keep me busy.

Busy-ness, as good as it can feel sometimes, is deceptive and distracting. Identifying what you want out of life and why is hard, at least it has been for me. Today, I sat down to write down a list to act as a personal reminder for where I’m at right now. As I grow as a person these things may change, but until then…

I want to spend time with my family, specifically with my nieces and nephews. They bring a joy to my life that I never want to miss out on.

I want to be healthy.

I want to be able to enjoy life and the people I spend it with.

I want to create the kind of company that is a vessel for promoting a shared vision where a community of people can come together to make the world a better place. Currently, I want to pursue this by bringing better software into the world.

I want to have strong, honest, worthwhile relationships with my family, friends, co-workers and clients.

I want to wake up every day and feel that where I am exactly where I’m supposed to be at this time in my life.

I want to create a company where people feels that it is exactly where they are supposed to be at this time in their life.

I want to have the type of relationships with that the thought about going anywhere else never crosses their mind.

I want to create a company that is more of a community than a company.

I want to help my colleagues grow personally and professionally. I want them to push me to grow personally and professionally.

I want to become an accomplished teacher through code, writing, speaking, and instructional settings.

I never want to stop learning. I never want to lose a passion for knowledge. I want to be a student day in, day out, every day of my life. There is something to be learned from everyone and I want to learn what that might be.

I want to continue to grow in the areas that I have a great interest and passion in, such as software/product development, business, relationships/community, and writing.

I want to spend more time with people I find inspiring, motivating, and uplifting and less with folks who do the opposite.

I want to be inspiring, motivating, and uplifting to others.

There are some things missing from this list which others may find obvious. It’s not to say I don’t value other things, but those are not what I want out of life. If I am able to accomplish the above I know those other things will either follow, or they simply won’t matter.

Git: Tagging commits after the fact

2011-09-27T00:00:00-04:00

If you ever forget to tag a series of commits with the story id or issue # you can use git filter-branch to do it for you.

git filter-branch --msg-filter \
  'cat && echo [contributes \#123456]' \
  master..HEAD

The above command tags the commits in my current topic branch (that aren’t in master) with the story id. This will change the history of the branch so if it’s been shared or merged think twice before doing this. Note that the escaped hash is intentional as the bash shell will treat everything following an unescaped hash as a comment otherwise.

Mysql2 3.0.x: Waiting for a result...

2011-09-26T00:00:00-04:00

Upgrading a Rails 3.0.x app to Rails 3.1 uncovered an issue with the mysql2 gem when it comes to running features that rely on an external process like Selenium or Webkit. You can install the activerecord-mysql2-retry-ext gem to work around it until it gets resolved in mysql2 itself.

gem install -r activerecord-mysql2-retry-ext

The error we got intermittently got with mysql2 and Rails 3.1 was this:

Mysql2::Error: This connection is still waiting for a result, try again once you have the result

Sadly, this issue with the mysql2 gem has been known about since December 2010. It appears it may have been fixed as the issue was closed on June 17, 2011, but it needs to be re-opened as it is happening again. This issue has also been reported against capybara-webkit.

This issue is with mysql2 version 3.0.7 (if failed with other 3.0.x gems I could get my hands on as well). I tried downgrading to the previous mysql2 gem we had installed, but it is not compatible with ActiveRecord 3.1.0.

The activerecord-mysql2-retry-ext gem is a quick work around until the actual issue can be fixed in the mysql2 gem. Update your Gemfile:

gem "activerecord-mysql2-retry-ext"

The work around in the gem retries executed queries up to 5 times if they raise an exception before giving up and re-raising the exception to your code. You do not need to change any of your code, just install the gem. It has worked great on our project, but YMMV.

This gem should not be used run in production.

Rails 3.1 Engine namespaces can creep into URLs in application layout

2011-09-22T00:00:00-04:00

With Rails 3.1 Engines it is possible for the namespace to creep into the URL generation for your application layouts. This can occur if you are not using named routes, but instead are specifying :controller in a options Hash:

# the following route generated in an application layout
link_to "Foo", :controller => "foo", :action => "bar" 

# when rendered from the action of an engine would
# try to generate the route
link_to "Foo", :controller => "myengine/foo", :action => "bar"

This issue will manifest itself onto other areas being rendered from the layout that relied on things like Rails current_page? and url_for helpers since under the hood they all rely on the same route generation logic.

To fix this you can replace any non-named routes with named routes:

# routes.rb
match '/foo' => 'controller#action', :as => 'foo'

Now you can use foo_path instead of relying on passing around :controller into any helper that generates a route which is cleaner and preferrable IMO.

Why Does This Happen?

ActionDispatch::Routing::RouteSet tries to determine if a route is relative and if it is it will try to properly namespace the route based on current controller context. From Rails actionpack/lib/action_dispatch/routing/route_set.rb:

# if the current controller is "foo/bar/baz" and :controller => "baz/bat"
# is specified, the controller becomes "foo/baz/bat"
def use_relative_controller!
  if !named_route && different_controller?
    old_parts = current_controller.split('/')
    size = controller.count("/") + 1
    parts = old_parts[0...-size] << controller
    @controller = @options[:controller] = parts.join("/")
  end
end

It explicitly checks to see if we’re dealing with a named_route. If so, it won’t try to massage the route. This is why using an explicit controller in route generation is susceptible to this issue.

Next, it looks to see if we’re in a different controller, which for engines will always be the case since they are namespaced in their own module.

After that, the massaging occurs and thats when the problem occurs.

Easy fix though, use named routes.

Is this a bug?

It might be, but I don’t think it is. I think it is just how the Rails Engines have been designed to work in 3.1.

This post was featured on Mutually Human’s blog.

Highcharts, SVG, VML, and Auto-Sizing for Legends

2011-09-16T00:00:00-04:00

Recently we hit a limitation with Highcharts: it has no way of dynamically resizing itself or its parent container to ensure that you see the legend and the full chart at the same time. Here’s the issue at hand: http://jsfiddle.net/KYfHM/2/

This isn’t a problem if you know in advance how many data series you’ll be showing, because you can specify the proper width and height when you create the chart. We’re populating the charts on a lot of dynamic factors, so we don’t know how many series will always be displayed upfront and we don’t know how long the labels will be. For us, this meant that our legend could easily grow beyond the bounds the chart.

No one wants to see a cut-off legend.

Determined to resolve the problem we created a chart-resizing.js file which would unobtrusively define the ability for charts to automatically resize. Modern browsers support SVG, but IE7 and IE8 do not, and IE9 even has its own quirks.

We decided to start with an SVGChartResizing object which would be used to define the strategy for how the charts should be resized. This worked great in Chrome, Safari, and Firefox.

IE9

Initially our SVGChartResizing object relied on the following code to determine y position of our legend:

$(legend).position().top

Unfortunately, IE9 returns the offset from the document rather than relative to its parent. To fix that we changed the code to work along with IE9:

$(legend).position().top -$(chart).position().top;

For SVG supporting browsers we were set. Now onto non-SVG supporting browsers.

IE/7 IE8

IE7 and IE8 don’t support SVG, they supports VML, which they are both equally finicky about.

Breaking jQuery

When VML is present on the page IE breaks jQuery when using pure pseudo-selectors:

$(":text") // fails with SCRIPT16389 error

The feedback you get from IE not very helpful. Fortunately, a similar issue was discovered way back in April 2010 when integrating Cufon, jQuery, and IE. There were only a few places where a pure pseudo selector was used so we updated them to be slightly more specific:

$("input:text")

Adding the input makes it more specific so jQuery won’t try to select certain VML elements.

Getting computed heights on VML objects

A Highcharts legend is a container which groups all of the individual legend items themselves. With the SVG-capable browsers you could ask the legend for its height and it would return its computed height. This was reliable enough to get the actual height needed to display the legend.

It seems that IEs DOM interface to VML objects doesn’t quite work the same way. It seems practically impossible to determine the computed height of a VML container. So rather than asking for the legend’s height we had to find alternative paths.

In IE8 we were able to use scrollHeight:

legend_h = legend.scrollHeight

IE7’s scrollHeight didn’t work the same way so we had to resort finding the largest child node and then rely on that to determine the legend’s height:

values = $.map(legend.children(), function(e){ return e.offsetHeight; });
legend_h = Math.max.apply(Math, values);

The End

For all of the complexities that Highcharts supports it was surprising that it didn’t surprise gracefully resizing the chart and re-positioning the legend. From many Google searches it appears we aren’t alone in this feature request, although most users seem to have found their own type of work around. Until it gets resolved there will be an open issue for this.

At the end end of the day the code is cleaner than we thought would have thought given the oddities we initially hit and the time it took to sort through the problems related to IE7 and IE8.

I remember walking away from work thinking I can’t wait until I get coffee-script on this project.

You can find the full code of what it took in this source code.

This post was featured on Mutually Human’s blog.

Notable Git 1.7.6 Updates

2011-09-15T00:00:00-04:00

git merge now supports the ndash alias:

# create topic branch to work in
git checkout -b foo

# do work... make commits... get back on master
git checkout master

# merge foo into master
git merge --no-merge -

Also, git checkout also supports the ndash alias which refers to the previous branch.

The above example also works without ––no–merge. Speaking of ––no–merge, you can now configure it in your git config and stop passing it in with every command line merge.

git config --add merge.ff no

# no longer need to specify --no-ff
git merge foo

From the gitlog:

“git merge” uses “merge.ff” configuration variable to decide to always create a merge commit (i.e. ––no–ff, aka merge.ff=no), refuse to create a merge commit (i.e. ––ff–only, aka merge.ff=only). Setting merge.ff=yes (or not setting it at all) restores the default behaviour of allowing fast–forward to happen when possible.

SSH Presentation Slides

2011-09-02T00:00:00-04:00

I did a learning lunch a while ago on SSH. As developers we use SSH on a daily basis but often aren’t aware of some of the things we can do with it. These slides covers the basics of those things.

You can access the full slide deck on slideshare here.

Estimates and Commitments?

2011-07-28T00:00:00-04:00

I was scanning the Internet tonight and came across Mike Cohn’s article Separate Estimating from Committing

I respect Mike Cohn a lot, but the idea that we need to separate estimates from commitments doesn’t add up. On one hand, I can’t commit so here’s my estimate. Okay that makes sense, but then on the other hand, if I increase what I can’t commit to - my estimate - I can increase it by a factor of X and then all of a sudden we can commit. That doesn’t seem likely.

The future is too unpredictable. The farther out we’re estimating the more error prone our estimates are going to be. Simply extending our estimates so we can give a guaranteed commitment will sound nice to product owners and the like, but it’s not going to make it true.

Most product owners would rather have the commitment any ways. In my experience they don’t care about a estimate of 6 - 8 months if you also are going to give them a commitment of 9 months. Just tell them 9 months. They’ll be happier in the long run (especially when it’s not done at 6 months). But if we end up giving a commitment, what’s the point of utilizing the estimates beyond coming up with that commitment? And if the commitment ends up being the important piece of information doesn’t that put us back to square one anyways?

Keeping track of both estimates and commitments seems counter-intuitive, you either can anticipate the future and the complexities surrounding the software you’re building or you can’t. It doesn’t make sense to have it both ways. Saying so otherwise seems like pretending.

activerecord-import 0.2.6 and ar-extensions 0.9.4

2011-04-06T00:00:00-04:00

It was asked on stackoverflow this morning how to use the :synchronize option with import to synchronize based a field(s) besides the primary key field.

activerecord-import 0.2.6 (for Rails 3) and ar-extensions 0.9.4 (for Rails 2) have been released which provide the additional option synchronize-keys:

# By default, synchronize tries to use the primary key field of your model, in this case Topic.primary_key which is :id
topics = Topic.find_by_author("Zach")
Topic.import topics, :synchronize => topics

# Let's specify a different unique column in which to synchronize on
topics = Topic.find_by_author("Zach")
Topic.import topics, :synchronize => topics, :synchronize_keys => [:topic_uuid]

This can be useful if you want to reload a bunch a of new records you’re importing:

# +author+ is a unique field in this case
topics = [Topic.new(:author => "Zach"), Topic.new(:author => "Bob")]
topics.first.new_record? # => true
topics.first.id # => nil

Topic.import topics, :synchronize => topics, :synchronize_keys => [:author]
topics.first.new_record? # => false
topics.first.id # => 1

The keys you use to synchronize should be unique.

Install

gem install activerecord-import # for Rails 3
gem install ar-extensions # for Rails 2

Clarity, Important 100+ years ago, Important Today

2011-03-16T00:00:00-04:00

Ludwig Wittgenstein’s claims in philosophy hold true in today’s in the pursuit of design and software development. He claimed, “Everything that can be thought at all can be thought clearly. Everything that can be said, can be said clearly.”

Retrospectives

2011-02-18T00:00:00-05:00

This past weekend I was spending time with my brother and his family. One of the things I love about visiting with them (besides their adorable kids) is how interested they are in what I do. They seem to ask all of the right questions that make me fall back in love with what I do, how I do it, and why I do it.

Don’t get me wrong, I love what I do even on the days I’m not hanging out with the family, but I often fall into the trap of normalcy. At one point, everything I was doing was new and fresh and it was an uphill battle just to get to do a fraction of it. Now, at MHS, all of those things have become what we practice every day – it’s become my new normal…

Read the full article on at Mutually Human's blog

Why Ruby?

2011-01-25T00:00:00-05:00

After reading Why not !ruby? I felt like conversing, but since it’s my wife and I alone at the house she doesn’t speak developer-speak, I figured the interwebs might be a better place to share my thoughts.

I think Ruby as a language and as a community connects with a lot of people in more ways than just a surface level “can i accomplish X with ruby?”.

I can’t speak for other people and I’ll avoid using the ‘people I know’ as a reason to run to or run away from Ruby. I have really enjoyed Ruby over the years, so much that I don’t ever desire to go back to PHP, Perl, or Java. Ruby has been so expressive that it as challenged my assumptions about what a language should allow you as the coder to do.

This expression of creatively solving a problem has been very rewarding. The box I am constrained in is defined, but it’s less rigid then in many other languages. I like this feeling. I like working inside a slightly bigger box that provides me with more ways to solve problems, and with building blocks to let me create my own ways of solving problems.

I also love that the community is largely supportive and encouraging. This isn’t to say others aren’t, but I’ve had better experiences with feedback in the Ruby community. And I’m not sure I get what’s up with the non-Ruby world assuming Rubyists are all elitist mac fanboys. I think we know what we like and why we like it. I like my Mac. I used a PC for years and Linux for years following. And now I have a Mac. It works for me. I’m happy with it. Likewise, I’ve used PHP, Perl, and Java for years, but I like Ruby more. It works me. I solve problems and I am happy to solve them in Ruby. Again, it works me.

I don’t just love Ruby though. I love JavaScript to. A long time ago I loved PHP. Shortly after that was 4D/Active4D. There were a few scandalous programming language love affairs after that, but who’s counting, right? Most recently I tried to love Scala. I mean I really really tried. It ended up as a short-lived romance with me in the hospital and Scala in AA. It just wasn’t meant to work.

Back on point though, I don’t know why you do or don’t ruby, but I know why I ruby. And that’s all I really care about.

Heroku Autoscaling Bug

2010-11-03T00:00:00-04:00

Recently while working on autoscaling Heroku apps with Mark Van Holstyn and Chris Rittersdorf at Mutually Human we uncovered a bug with Heroku itself.

When you tell Heroku to scale down its number of dynos it will still serve requests to dynos that are being shut down and it will kill dynos that are still actively serving requests. If you manually throttle dynos infrequently then you will probably not notice this, but the problem is still there. Since we were autoscaling based on live site usage and incoming requests, it expedited the visibility of this bug since our application would scale dynos up and down much more frequently to support application usage.

This bug has been confirmed by the Heroku support team and has not yet been fixed. When it is fixed I’ll post an update. In the mean time, scaling up is no problem, but if you scale down know that someone may get a Heroku HTTP 502 App Failed To Respond error because Heroku just killed a dyno serving a request.

First grandrapids.rb Fall 2010 Meetup

2010-10-06T00:00:00-04:00

Tonight I attended the Grand Rapids ruby user group meeting. The first one since the summer hiatus! There was a great turnout of about 15 people.

Derek Kastner gave a great presentation on Bundler ). At high level Bundler is a library/tool that manages an application’s dependencies through its entire life across many machines systematically and repeatably. Derek’s slides/presentation can be found here: http://github.com/dkastner/bundler-pres

The presentation segway’d into discussing Maven and Bundler, Bundler and Rails, Bundler and Isolate (Bundler alternative), and then onto IDEs such as Eclipse, Netbeans, VIM, Emacs, TextMate, and now Redcar – which I’m rooting for Redcar. It looks awesome and has the best commit policy known to open source.

It ended with Carl Furrow showing us the world of Minecraft. All I have to say to that is Carl was like a zenmaster navigating the landscape of his 3D world, traveling to the center of the earth, dodging box-headed skeletons shooting arrow-like objects. I feel all in attendance were enlightened.

Next month should be awesome, Zach Church is giving a talk on Rails 3!

activerecord-import 0.2.2 released!

2010-10-06T00:00:00-04:00

activerecord-import 0.2.2 has been released. This contains no functionality changes, just gem dependency updates.

Updates

activerecord-import, now only depends on activerecord, the rails dependency has been removed entirely

Installing

gem install activerecord-import -v 0.2.2

Happy rubying!

activerecord-import 0.2.1 released!

2010-10-05T00:00:00-04:00

activerecord-import 0.2.1 has been released. This contains no functionality changes, just gem dependency updates.

Resolved Issues

Update gemspec to require rails “~> 3.0.0rc” rather than “>= 3.0.0rc”, which closes “issue #2”:http://github.com/zdennis/activerecord-import/issues/closed#issue/2

Installing

gem install activerecord-import -v 0.2.1

Happy rubying!

On Criticism and Encouragement

2010-09-26T00:00:00-04:00

I will do great things in this life, but never at the expense of another person. I have and will continue to make many mistakes in this life. My past mistakes have allowed me to experience the differences between criticism and encouragement at many different levels and for many different reasons. Criticism and blame have never led me to achieve anything worthwhile. On the other hand what’s been afforded to me through love, encouragement, appreciation, forgiveness, and empathy have been the starting point of every worthwhile achievement I can remember.

The biggest differences I can recall between criticism and encouragement has to do with what is planted within. Criticism generally has made me frustrated, angry, discouraged, and ultimately depressed. On a few occasions it temporarily instilled in me the will to ‘show’ the other person. This feeling quickly dissipated and was again replaced by a feeling of distress. Encouragement on the other hand has had a different life-changing quality about it – it inspired, motivated, and uplifted me. It took my mistakes and gave me energy and helped strengthen my resolve and determination to learn from those mistakes. It provided a framework for growth and in the process created respect and loyalty.

Dale Carnegie sums these experiences up nicely, ”I’ve yet to see a person who didn’t do better work under a spirit of encouragement than one of criticism.”

Every interaction in our lives happens only once. Each interaction gives us the chance to imprint something on our own lives as well as those we interact with. With every opportunity that arises I hope to provide the encouragement that so many others have given me in hopes that this will help them achieve great things in their life. If I do this, then I’ll have achieved one in mine.

activerecord-import 0.2.0 released!

2010-09-26T00:00:00-04:00

activerecord-import 0.2.0 has been released this evening! There are no changes to existing functionality, only some nice updates:

the Mysql2 adapter is now supported (in addition to SQLite3, PostgreSQL, and MySQL)

activerecord-import got stupid simple to require and use

the 0.1.0 release, um, surprise!

Mysql2 Support

Okay, the first line item – mysql2 support. This is a little late coming I know, but it’s there now. The mysql2 support is identical to the mysql support so if you’re upgrading a pre-Rails 3 app (that used ar-extensions or activerecord-import) you won’t have to change any code using #import. More on that later.

Stupid Simple Requires

activerecord-import and its predecessor (activerecord-extensions) was always a little kludgy to require and use. It was never painstaking to load up, but nonetheless it could have been better. Well, that better comes today.

Here’s the breakdown of the better: activerecord-import is now loads when your ActiveRecord connection is established. This means:

no need to separately require activerecord-import or adapter-specific code
supports you using multiple database adapters simultaneously
activerecord-import will only load once for an adapter, so no worries re-establishing connections

This isn’t earth shattering awesome, but this is a small step forward for the library and it makes it easier to use!

For more information on requiring activerecord-import in Rails and non-Rails projects see “Requiring”:http://github.com/zdennis/activerecord-import/wiki/Requiring on the wiki.

0.1.0 Release, um, Surprise!

The 0.1.0 activerecord-import gem has been out for a few months, and I know a few of you have been using it as I’ve been receiving emails and instant messages. However, if you didn’t know it was out, surprise! I apologize for not communicating when the gem became available, but hindsight is 20/20, and moving forward things I will be more communicative.

If you didn’t know activerecord-import 0.1.0 took all of the import functionality out of the activerecord-extensions gem and bundled it in its own gem. It is Rails 3 friendly whereas activerecord-extensions is not and will never be (at least by me). The 0.1.0 release launched support for the following adapters:

mysql
postgresql
sqlite3

And as of this announcement mysql2 support was added.

Well, there you have it, the world just got a little bit better today. When I pushed the gem I am pretty sure a tiny angel got its wings.

Install the gem

gem install activerecord-import -v 0.2.0

Install in your Gemfile

gem "activerecord-import", ">= 0.2.0"

Docs

For docs see the “wiki”:http://github.com/zdennis/activerecord-import/wiki/

Happy rubying!

The Customer Fallacy

2010-09-24T00:00:00-04:00

nothing so kills the spirit
as a man that jumps to conclusions
to assign blame before he knows
that what he sees are illusions

failing to see the fallacy
of the reasons he thinks it has to be
after this, then because of this
thinking he's figured it logically

but if berries are red and berry bushes are plants
surely all berries are not red
but he thinks that they must be
and so he believes
never thinking what he's thinking's absurd

A journey of possibilities with community at the core

2010-08-01T00:00:00-04:00

One of my goals for Mutually Human Software is to create an authentic community. To create a place where everyone feels that this is where they belong at this time in their life. When people feel a sense of belonging they aren’t wishing they were somewhere else, they feel like they belong right where they are. This is one of the possibilities I aspire to realize with MHS.

The question I’ve been struggling with is how do we create that kind of community? There’s a lot of conventional business wisdom about how to build, run, and lead a business. Unfortunately, a lot of it what’s there is at odds with what I view as essential for building an authentic community. My sights are much higher then simply having a profitable company or a good company. I want an exceptional one. I believe an authentic community is critical to realize this possibility.

A few years ago I focused on the culture of a company being key to whether or not they were a great company and whether or not I wanted to emulate them. Recently it hit me that culture is merely an indicator of a deeper and more meaningful metric – the health and shared values of the community. Culture is a by-product of the community, not a means to achieve it.

Another way I think about culture is that it is a reflection of the community. This has been intriguing to think about because it exposes that you can’t copy culture. You can attempt to emulate it, but likely that emulation will fail to create the culture you want because culture is an outcome of community, not a thing in and of itself.

This is a lesson I’ve learned over the past few years. I wanted to emulate companies I thought were great and while some things worked for a short period of time, nothing created the kind of relationships, cohesion, or sense of belonging that we had the possibility to achieve.

Before I looked at the results of a great company’s community, but now I am paying close attention to the shared- values, goals, and disciplines of those companies and their communities. My focus is not to take what I see and put policies in place at MHS. That would not be authentic. Rather my focus is bringing what I see and allowing others to bring what they see and to allow the community to grow and evolve – allowing people to have a hand in creating the very thing that defines us and ultimately results in a culture we all are proud of.

Today is another step towards the realization of being an exceptional company and an exceptional community. I find the possibilities and the journey so inspiring!

Accountability Can't Be Dictated

2010-07-31T00:00:00-04:00

Everyone talks about accountability. It’s one of those things we all want and expect, but it’s something that is often struggled with. No one wakes up and plans to fail holding themselves accountable. Yet, even with good intentions we often fail to follow-through. Why is it so difficult?

Whether in conversation or reading it strikes me as odd how often accountability is being dictated as opposed to owned. If I tell you to be more accountable what do you think the chances are that you will become more accountable? I bet slim to none.

We can always up the ante and impose consequences. Perhaps the more severe the consequence the more accountable you’ll become. There is some truth in this method, but it comes at a cost. An example of that cost is creating a fear-based culture which can become focused on retribution. If you’ve ever worked for an employer who ruled by fear and consequence you know what I’m referring to.

Accountability in my opinion doesn’t fail because individuals have malicious intent. I think it fails because we often try to impose it on others rather than owning it ourselves. Accountability starts with the individual. I choose to be accountable or not. I choose to be responsible with the commitments and decisions I’ve made. No one else. No matter how much you encourage me at the end of the day it’s still up to me.

In Peter Block’s book Community he points out in reference to accountability is ”… that people will be accountable and committed to what they have a hand in creating.”

I believe he’s referring to authentic creation as well. Dictating to someone how to solve a problem every step of the way isn’t allowing them to be a part of creating that solution. They have no stake in, no connection to the solution or the process of getting there. This may be perceived as creation by the individual in control, but it’s an illusion.

Instead of dictating step one, step two, etc, why not present the problem and allow the individual to own achieving the solution? You can still make yourself available, provide guidance, and set parameters. This doesn’t have to remove you from the equation, but it removes you from controlling the entire process. You’re trading your control for their freedom. It’s in their freedom they are able to be a part of the process for solving the problem. They become a creator in that instance. I believe this creates accountability that is owned by an individual opposed to that which is demanded of us by others.

While there are support measures for peers and our communities to help us be accountable, ultimately it’s up to us as individuals. Accountability can’t be dictated. It must be owned.

Daniel Parker accident

2010-05-17T00:00:00-04:00

You may know his name if you’re a developer, because so was Daniel. You may know him from his work with Quickbooks and Ruby or maybe his GMail rubygem or one of his many other projects that he authored or contributed to.

You may know him as a Christian, because so was Daniel. While he wrote code because it was fun and he was quite good at it, he first and fore-most lived for the Lord.

You may know Daniel as a fervent competitor with a kind heart and a powerfully analytical mind. You may know Daniel for a number of other reasons, and if you didn’t know Daniel then I assure you, if you did, he would have left nothing but an impact of an honest, energetic, intelligent, warm hearted, analytical, yet loving person.

I knew Daniel because of his work in the Ruby community and in the Ruby community in the midwest and specifically Michigan. Last fall I attended GRGivecamp with Daniel. Four months ago, Daniel came and began working with me at Mutually Human Software. Daniel and I worked closely together for about 30 hours a week every week. Every day we’d pair program (or party as Daniel would call it). Almost every day we’d eat lunch together and talk - sometimes about work and sometimes about everything else in life. I never imagined that four months of my life with someone could have such an impact. That’s also the kind of person Daniel was - impactful in all the best ways.

Before I had ever met Daniel personally, my colleague John Hwang had told me that he was the kind of person we wanted to work with, not just the type of developer, but the kind of person. At first I was skeptical, but after I met and began workingw ith Daniel I knew John was right. Daniel was more then just a developer – he was human. He was the kind of spirit and person who anyone would want to build a team around. He was an amazing developer, but even more-so he was an exceptional person. It’s hard to believe that Daniel was only 23 years old.

I will miss you Daniel, as a friend, as a colleague, as a human. May your life go on to impact countless lives. I know you have impacted mine.

P.S. - when you get to heaven be sure to teach everyone Rook, they’ll love it just as much as you did when I introduced it to you. That will forever be a cherished night in my life.

UNIX tee in real life

2010-04-29T00:00:00-04:00

I wrote a nice little article on using the UNIX tee command in real life. If you’re wanting to see the purpose of tee or learn something new about bash, check it out:

“http://mutuallyhuman.com/2010/4/29/unix-tee-in-real-life”:http://mutuallyhuman.com/2010/4/29/unix-tee-in-real-life

Happy coding!

activerecord-import gets basic SQLite3 and PostgreSQL support

2010-04-09T00:00:00-04:00

A few weeks back I started working on extracting the import functionality from ar-extensions into its own library. The initial extraction involved pulling out all of the MySQL functionality first, test by test, piece by piece. Well, tonight I pulled in the basic support for SQLite3 and PostgreSQL.

While it’s working great for MySQL, SQLite3, and PostgreSQL it has not been released as its own rubygem yet. I expect that to happen in the near-term future. In the meantime you can always check out the project on github:

“http://github.com/zdennis/activerecord-import/”:http://github.com/zdennis/activerecord-import/

In the past folks have emailed about sparse documentation. When the gem is released documentation will be provided by the github wiki ( “http://wiki.github.com/zdennis/activerecord-import/”:http://wiki.github.com/zdennis/activerecord-import/ ) and the most up-to-date will be provided in the RDOC itself.

I’ve ran some benchmarks recently against MySQL 5.1 and you can find the results here: “http://wiki.github.com/zdennis/activerecord-import/benchmarks”:http://wiki.github.com/zdennis/activerecord-import/benchmarks

More to come!

ActiveRecord Import Updates

2010-03-12T00:00:00-05:00

Nearly four years ago I embarked on figuring out ActiveRecord internals enough so I could have a library which allowed me to perform bulk inserts of data in an optimized way based on the database adapter being used. Over those four years, I’ve maintained and updated the functionality with contributions from the community. A big thanks to Blythe Dunham, James Herdman, Gabe da Silveira, Thibaud Guillaume-Gentil, Marcus Crafter, and Mark Van Holstyn.

Now that Rails is nearing a 3.0 release, it’s time for to revisit this import functionality, make it compatible with the heavily refactored and cleaned up ActiveRecord internals (thx Rails core team) and add some more polished features and implementation.

The import functionality which was in ActiveRecord::Extensions is being extracted into its own library, activerecord-import. This library will be smaller and its only purpose will be to provide mass import functionality.

The work has already begun over on github: “http://github.com/zdennis/activerecord-import”:http://github.com/zdennis/activerecord-import

I look forwarding to officially releasing this in the upcoming weeks!

Binary Chop Shop in Scala

2009-11-03T00:00:00-05:00

In an effort to start learning Scala again (i started in the summer then got busy) I decided to tackle a simple yet fun code kata from Dave Thomas called “karate chop”:http://codekata.pragprog.com/2007/01/kata_two_karate.html

I ended up using “Specs”:http://code.google.com/p/specs/ to make sure I passed Dave Thomas’s test criteria. I’m sure my below two solutions (recursive and while loop) are quite clunky compared to someone who’s familiar with Scala, but the goal of this was to get something running and passing. In a week or two I’ll revisit again after learning some more things about Scala and hopefully be able to tidy things up a bit.

Anyways, here’s my code:

class BinaryChopShop {
  def chopRecursive(target: Int, list: List[Int], args: Int*): Int = {
    if(list.isEmpty) return -1;

    val offset = if(args.isEmpty) 0 else args.first;

    if(list.size == 1){
      return if(list.first == target) offset else -1; 
    } else {
      val index = list.size / 2;
      val value = list(index);

      if(target < value)
        return chopRecursive(target, list.slice(0, index), offset);
      else
        return chopRecursive(target, list.slice(index, list.size), offset + index);
    }
  }

  def chopWhile(target: Int, list: List[Int]):Int = {
    var nlist = list;
    var offset = 0;

    while(!nlist.isEmpty){
      if(nlist.size == 1){
        return if(nlist.first == target) offset else -1;
      }
  
      val index = nlist.size / 2;
      val value = nlist(index);
  
      if(target == value) return index + offset;
      if(target < value){
        nlist = nlist.slice(0, index);
      } else {
        offset += index
        nlist = nlist.slice(index, nlist.size);
      }
    }
    return -1;
  }  
}

Summary of thoughts on data and migrations

2009-10-17T00:00:00-04:00

I shared a summary of my thoughts today with my project team (we’re distributed, multi-national team)… and I thought what the heck why not share with the rest of the world to. Here goes…

I’m not sure what everyone’s conventions or views are on handling the removal of data in the app that is no longer used, so here are some of the guidelines I follow to help promote sharing and consistency.

Seed data

To load data that has to exist for the application to run, I like to use seed data and I am a big fan of Michael Bleigh’s seed-fu plugin. Seed data should be setup so that it can be loaded at any point during the lifetime of an application. It should not destroy data that leaves orphaned data and it should not duplicate data.

Updating data

I like to use migrations to update existing data. If the migration and data update is complex and irreversible I will add a unit test around the migration because due to the high risk of causing irreversible damage (unless a full DB backup is loaded).

Updating application-required data

When the data that the application depends on changes (ie; the seed data) I tend to update both the seed files as well as add a migration to properly handle any existing data, whether this means removing the data, marking it as delete or inactive, etc.

Updating data

In development modifying data directly through MySQL or ruby scripts is much more forgivable and often very fast and efficient. We have no risk of causing users of the application harm or loss of data. Once something is figured out I like to either add a seed-file and/or a migration if it’s a change that needs to get made on staging and production.

In staging modifying data directly is less appealing because staging is supposed to represent what happens when we go to production. If we have to modify data directly in staging then we’ll probably have to modify it in production, so a migration and/or seed-file is a better place to track the change. I find it tempting sometimes to script/console and modify data directly.

A problem with this is that we risk screwing up staging for folks who are using it to preview features, check out bug fixes, etc. I find it better to dump the database and pull it over to my local development machine. Once I have it I can load it up locally, recreate the issue, and do whatever I need to do to find the source of the issue. This removes the risk that you fill further break staging for any users using it. Once I find the issue if I need to I will add/update a migration and/or seed file.

In production modifying data directly is super dangerous. It’s a change that occurs outside of version control and potentially without being run in development and/or staging which could catch bugs in the updates. The risk of causing irrevocable damage is so high I think doing this should be avoided.

I find it’s always been better to take an extra few minutes to make sure the fix is right and then to deploy, then it is to make a quick fix directly in production and find the change caused new issues. Production should never turn into a debugging sandbox. Pulling over a backup if necessary is safer and allows us developers more freedom to freely change the data to find the appropriate fix.

If you have to use script/console not MySQL

If you find you need to update data directly it’s better to use script/console, then by touching the database directly using MySQL. For example, Scott once asked me to change his user name. Changing his user name was a very low risk change, so I loaded up script/console and made it.

The benefit of script/console is that you let all of the rules and validations inside the application be run when you make the change. If I had made Scott’s username too short, too long, include inadmissable characters I would not find out if I did it directly through MySQL, unless I had duplicated all of the logic in MySQL stored procedures and triggers (which I cringe at the thought of).

Conclusion

Well, that’s pretty much a summary of my personal guidelines when it comes to dealing with data updates, migrations, seed-files, etc. If you have any other guidelines you follow that you find helpful please share. I think being on the same page here will help us as we push forward.

git review

2009-10-01T00:00:00-04:00

I’ve gotten into the habit of review code that comes down from every other developer, rather than blindly merging in. For a while I was typing “git log master..origin/master” but it became to tedious to type out. I’ve updated my .gitconfig to provide the following alias:

[alias]
  review = !"git log  master..origin/master"

Now I can simply say:

git review

If you want to view actual code changes rather than simply the changelog just add the -p flag:

git review -p

A little nicer.

BDD not so much, really? Part II

2009-05-28T00:00:00-04:00

Focusing on behaviour may yield different tools throughout the process. Cucumber and RSpec are just two examples. You could very well use Cucumber plus test/unit, or perhaps just RSpec, or maybe nothing at all. These are just tools to support a development style. They are NOT the development style themselves. You can use Cucumber in a way that doesn’t support BDD. Same goes for RSpec and any other tool.

I realize there are people who don’t buy into the RSpec philosophy. To them it’s just another take on unit testing. I do buy into RSpec. From day one RSpec’s goal has been to be a BDD tool that tries to get the words right. Can you use xUnit libraries in a way to achieve the same affect? Yes you can, but most of those usages have been heavily influenced by RSpec which was built on the ideas and motivation for BDD and “getting the words right”.

Without this focus many of the high level test/unit style add-ons (especially in the ruby world like context, shoulda, test/spec, etc.) wouldn’t exist. So to me, this makes the subtle differences very important as it changed how everyone wrote their tests.

For me personally, testing is an activity after you write code. I find it refreshing to talk about writing code examples to drive design and tests to talk about actual testing. Perhaps it could be phrased as, you start with examples and when you’re done you end up with tests. Similar to starting with user stories and ending up with features. Right now that works in my head, but it’s late and I may need to revisit that thought after a few hours of sleep.

Example is just a better word then test to. When you talk to someone and you don’t understand what they’re talking about you don’t say, “give me a test”, you say, “give me an example”. Well, that language is more natural. You are providing an example of how something should work. This example ends up providing regression (test) value once its implemented, but you didn’t start with a test, you started with an example of the code you wanted.

BDD not so much, really?

2009-05-28T00:00:00-04:00

Updated May 29, 2009

This rant is in response to http://robertlally.com/post/bdd-not-so-much

BDD didn’t start off as a replacement for TDD. It started off a way to better understand and explain the process of TDD. The name change as I understand it was to communicate the intent of TDD in a clearer and more direct way. You’re not writing tests for the sake of writing tests, you’re driving behaviour. Focus on the behaviour you want to achieve first and foremost. Use that behaviour as the driving force for your examples (or tests).

Corey Haines nailed it on his comment to the same post, “BDD is no longer a replacement for TDD, but, rather it is a workflow for creating a system that more closely resembles what the client is looking for.” I think two of best tools which exist to support the BDD workflow of outside-in are Cucumber and RSpec. Cucumber for higher level system behaviour and RSpec for driving lower level design.

In the article, the author criticizes the “should” language. Rather than simply scoffing at the idea of replacing “assert” with “should”, I tend to think about it in terms of natural communication. The reason I like “should” language over “assert” language is that when I’m communicating with another developer I don’t say, “assert equal one day to do things good”. That doesn’t make any sense. I say, “one day to do things to should be good”. It’s much more natural for me to write closer to the language I think and communicate than it is to translate it to assertion-speak. I want to communicate in my code more closely to how I communicate to other people.

While the term BDD is a few years old it takes a while for dialogue to happen, and understanding to occur. I’m sure a lot of people hear about BDD, read about it from Dan North’s Introducing BDD. BDD started as a way to explain and better understand BDD, but what I think was realized was that it was much more than simply TDD.

Many tools are emerging which claim to support BDD-style development. It’s important to note that BDD isn’t the tool. You can have many tools support BDD style development in different ways and to different degrees. Although a good tools makes any process easier, what makes BDD is the mindset you have and how you go about writing software. Certain tools emerged with this in mind and are thus labeled BDD tools. Cucumber, RSpec, and JBehave are some examples.

The article mistakingly sheds Cucumber in the light of solely driving the design of code and suggests its a bad tool to do that. Of course it is! It is not a tool intended to drive the design of your code from a low level. It is to communicate in plain text how the application should behave. The plain text is something that is business readable, something that adds value not at the code design level, but at a higher level: communication and understanding requirements!

Cucumber is equivalent to a high level integration test for those of you who come from a testing background. It runs the entire application (or whatever can be reached through automation, different types of systems have different limitations). It works in combination with a tool used to drive out the design of your application using lower level code examples. For example, RSpec.

The #1 output of BDD is a working application that is behaving as expected. In addition to that you have an application-level regression suite in which you can run against the code base at any time. You also end up with smaller, more focused code examples which provide regression against isolated behaviour of the system.

Combined, you end up with documentation at two critical aspects. The first is business readable scenarios that the system supports. The second is developer documentation made up of the lower level code examples. Since these are often written more clearly than assert-style syntax it’s easy to produce human readable behaviour specifications for focused pieces of behaviour. And in the end you have a repeatable process which allows you to confidently produce the working software.

I also don’t see where UML to BDD comparisons make any sense. UML is a modeling language. BDD is more of an approach or methodology. A more accurate comparison would be plain text scenarios vs. UML. Although that makes little sense as a comparison because UML is not something you can give a non technical person to write, read, and edit.

BDD by itself doesn’t fix any problems. It provides an approach which focuses on behaviour first. To me, there’s no point in building a low level library if you’re not aware what higher level problem you’re solving or objective you’re adding value to. This boils down to a person still has to “do the work” to make it successful.

At the end of the day though I cannot speak for anyone else except myself. Shifting my focus on behaviour rather than “tests” led me to write better code examples. Often times I would write less of these because I was writing better examples. It’s also helped improve communication between myself and my team, customers, and other developers. BDD may evolve into something else, or perhaps a new perspective will come around that will take the world by storm. I am all about continuous learning and improvement. And I invite any ideas Mr. Lally or anyone else brings to the table.

Also, BDD never claimed to be THE answer. Any process that claims to be THE answer will surely not be THE answer for everyone in all situations. BDD has been an answer for many people though and as of now it will continue to be an answer for me in how I work.

A good resource worth checking out for BDD, it’s philosophy, and how to apply it in practice is The RSpec Book

rspec/cucumber ML email etiquette

2009-05-09T00:00:00-04:00

Aslak Hellesoy recently requested on the rspec/cucumber mailing list the other day that folks stop top posting. His words:

I find it really hard to follow conversations that use top posting (http://en.wikipedia.org/wiki/Posting_style). If you have a [Cucumber] topic, please respond with inline comments. And use plain text email - not html.

I agree with Aslak’s request for the most part. There are times when top posting is perfectly acceptable, but those are too often blurred by the countless times where people are just plain lazy. While most of the replies have been rather humorous in response a couple recent replies have the look of actual requests to the community: snip out things not pertaining to your reply and the removal signatures.

The only part I don’t agree with is the text email. I’m sorry, but if you use an email client which can’t show html, or can’t not show the html part of an email then you need to find a new email client. I have the feeling Aslak was referring to folks that only send HTML email, void of a plain text part. If that’s the case I am in full agreement with his request.

Aslak’s request was well intended and thoughtfully brought about. I hope the replies stop before there is a giant list of dos and donts, followed by a flamewar that will most likely have a negative impact on such a wonderful community.

RSpactor, love Cucumber

2009-04-28T00:00:00-04:00

If RSpactor loved Cucumber it’d be even more amazing. From the ticket request:

It would be amazing if RSpactor integrated with Cucumber although it would need to be a different than how it currently works with RSpec. Now that Cucumber has tag support I think this good be done in a reasonable way that improved the developer workflow for projects that utilized Cucumber.

Here’s an example. When I am working on changing how money is managed in my app I know that I want to run the features tagged @accounting. At the start of my work it’d be great if I could add the @accounting tag to RSpactor so it would run those features after it successfully ran specs.

Perhaps there would also be a preference setting which auto ran the Cucumber scenarios after specs ran, or one that forced you to manually hit play. Although if you had typed in tags, it the play button would run cucumber with those tags.

Got a better idea for Cucumber integration? Join the discussion! http://github.com/rubyphunk/rspactor/issues/#issue/1

Managing Client Expectations

2009-04-08T00:00:00-04:00

Managing client expectations is simple, but like most things simple–it’s very hard to do, do right, and do consistently. I think this is a common problem in today’s web development companies. The industry has a lot of young, creative, and smart people building companies with little to no experience in customer relations. For every person who is naturally gifted or good at managing client expectations there are probably several more people who just don’t get it. And the worst part, is that they probably aren’t aware of the fact that they don’t get it.

I’m one of those young, creative, and somewhat smart people in the industry trying to build a company in the web industry, but this is an issue that has been nagging me for months, and it’s to the point where I feel like it needs to be shouted from the mountain tops (although this blog is probably more like a anthill). It may not be the best business decision on my part since it encourages competing companies to become better. If they do it will make us humans work that much harder.

I’m sorry to say it, but few web development companies seem to do a good job of development and a good job of managing client expectations. Maybe your company is good at development, but stinks at managing client expectations. Or maybe it’s the other way around and you are great with the customer, but your team is a bunch of junior developers who crank out crap. Oddly enough, if your company falls into the latter you have a much better chance of being successful and surviving than the former.

Before look at some of the effects of managing (and failing to manage) client expectations let’s start with a simple definition:

Managing client expectations is the ability communicate proactively with the client in a reasonable and realistic manner that allows them to take ownership of decisions that may affect their project or business.

Managing client expectations is about communicating honestly, openly, and often with the client. It requires informing them of things that have the potential to impact their business or their project. I use the term proactive in the definition because you’re not doing it right if you do something and than communicate after the fact. Heck, doing that is like this the plumber who came to your house and failed to manage your expectations:

A plumber comes to your house to fix your toilet. At first glance it looks like it’ll take an hour to do so you set aside $100 on the counter to cover the cost and leave so the plumber can work in peace. While working the plumber discovers a much bigger plumbing problem. He’s really in the zone though, so rather than calling you he just does what’s necessary to fix the issue. You get home later in the day, and on the counter you see your $100. Next to it is an invoice for $2,200 and a note that reads: I ran into a bigger problem, but I was really in the zone so I replaced the plumbing in the basement because it would have had to have been done.

Do you feel the plumber did a good job of managing your expectations? Would you hire that plumber back? Would you pay the bill? I would answer three hell nos. Yet, many web developers and young web entrepreneurs find this perfectly acceptable and they wouldn’t think twice about doing it. To them it’s just how you move a project along its merry little way.

For folks who aren’t aware this is a problem–_it is a problem and you should stop doing it_. For folks who do it and know they do it, wake up, its unhealthy for your client, you, and your business.

I think it’s universal knowledge that finding a new client is more costly then keeping a client. Every time you interact with a client you have a chance to increase or decrease your likelihood of keeping them as a client. When you manage their expectations well you will most likely keep them. Here are three general reasons why:

build a healthy relationship
build trust
empower the client, giving them ownership

Positive effects of managing client expectations

Build a healthy relationship

Every time you interact with a client you have the ability to build a slightly better relationship. Setting clear expectations with the client with good solid communication strengthens the bond between you and your customer. Customers who have a healthy relationship w/their suppliers are not likely to jump ship.

A new developer joins your team. Every time you work with him you notice he takes the time do things right rather than just quick. He also seem to ask questions and raise questions at all the right times. You find yourself comfortable working with him and before you know if you even think that you do better when working with him. When the developer’s 90 day review comes up you’re first to speak up and ask the team to keep him.

Build trust

Part of building a healthy relationship is trust. To me, trust is like trying to level a character in EverQuest. As you build up stats and level you gain a new skill or perhaps a new magic. The higher you level the more your character is capable of. The same is true for the relationship with a client. As you achieve new levels of trust with your client you achieve new capabilities for doing things. Perhaps your client sends you more work. Perhaps your client refers you to his peers and to other companies. Perhaps your client invites you to more business-oriented meetings because he wants you involved in streamlining technical aspects of their business. Perhaps you become the goto shop for your client’s organization. Without trust this is not possible.

A new developer joins your team. After the first few months of working with her you find she is a good, honest, hard working, and capable developer. You build up trust in her as a developer. A potential client comes in and you need to send over a couple developers to help kick off the first Planning Game and do some story estimation. You send her. You know she’ll do a good job, ask questions, and be honest.

Empower the client, giving them ownership

Empowering the client is something that we really need to do a better job of in our industry. Managing a clients expectations lets the client own the decisions that need to be made that impact their project or business. These decisions are not ours to make, they are our clients. When the client owns the decisions, they own the project, they own the direction of the project. This isn’t to say we don’t guide or assist our clients in finding that direction. This is one of the many reasons we are often hired, however, when a client gives you permission to make decisions for them, they made that decision. When that’s not the case and we make decisions for the clients we are simply being lazy and bad vendors.

As a developer who practices Behaviour Driven Development I want my customers to own the scenarios that are written to drive the development of an application. The customer may physically write any of the scenarios. I may type them while sitting with the client, or during a phone call, but I am merely being a scribe. They own the scenarios. I never want the customer to feel that scenarios are written simply to translate business speak to technical speak, I want the customer to own the scenarios so its clear to them what they are paying me to build. Doing this empowers the client, it gives them ownership. They are usually much more engaged in the project when this happens.

Negative effects of failing to manage client expectations

Now, when you don’t manage client expectations you can have the opposite effect:

hurt the relationship
lose trust
empower yourself, taking ownership away from the client
increase the risk you negatively impact the clients business

Hurt the relationship

Not managing client expectations hurts the relationship. You may get away with it once, twice, or even three times, but sooner or later you will guess wrong and your customer will be ticked off. This is usually when they start looking for a new vendor.

Your customer has a feature they want added. You estimate 50 hours. It ends up taking you 110 hours. You don’t tell the client, you simply send them a bill. The customer is ticked, he asks that you stop working until the bill can be addressed. He wants to do a phone call with you to dispute the bill. Your customer is not happy.

Lose trust

Losing trust is a part of hurting a relationship, but trust is so important on its own. Most companies want to be a partner with the client. They want the client to leverage their expertise in solving a problem. If we don’t have that kind of relationship we lack the trust required for the customer to to utilize us in that way. Every time we fail to manage a client’s expectations we lose a level of trust. At some point its gone, and we’re out of the picture.

Empower yourself, taking ownership away from the client

Making decisions that affect the client’s project or business are a big no no. It takes ownership away from the client and only empowers yourself, but that empowerment only lasts a short while. You may have won the battle, but you will surely lose the war. First of all, decisions that impact the client’s project or business are theirs to make–not yours. Sometimes an emergency arises, the app is down! Chaos ensues! What to do? One of the very first things you do is call your client and give them the ability to say “no, don’t fix it”. Even though that answer may be highly unlikely, its not your decision to make, unless you have an arrangement with your client to make those decisions. Perhaps you have an agreement which covers what to do in those circumstances. If you do, more power to you. If you don’t, you may want to consider getting one.

Maybe you’re wondering what happens if you can’t reach the client? Do you wait to fix it until they call you back? I would say that depends on the nature of the issue. At minimum you should leave a voicemail and send a quick email, both which have your contact information. Doing this allows you to do everything reasonably possible to contact the client of the issue. And it may add 30 seconds to 2 minutes of overhead. This is usually reasonable. However, this is one of those times where it depends based on the relationship you have with your client. Fixing the issue first and responding later may be acceptable based on your arrangement. My belief is that if that’s not your arrangement than you should be contacting your client. Well, you should be contacting them anyways–that’s just being a good vendor.

The client’s site goes down. You get a call from one of their programmers (not a decision maker or gold owner) about it. You log in, evaluate, and decide to tackle it. Some time later you get it fixed! Woot! Invigorating, wasn’t it? Then you send a bill to the client. The person who pays the bill and has decision making power for paying the bill is very upset. Why a $1,200 bill? And why wasn’t he made aware of it? He heard from his one of his programmers their was an issue, but that it got resolved, why is the vendor sending a bill?!!

Increasing risk negatively impacts the clients business

Every time you make a reckless decision on behalf of your client without having some kind of prior arrangement or relationship in place you increase the risk that you will negatively impact their project or business. These are risks that are not yours to own, they are your clients. They always deserve the ability to say “no” even if it seems highly unlikely. The only time they shouldn’t have that option is if someone’s physical health is in immediate danger, but I haven’t seen any webapps running medical equipment, handling stop lights, or coordinating the release of water at Hoover Dam.

BDD w/Rails Class

2009-04-03T00:00:00-04:00

Shortly after RailsConf and while The RSpec Book is hitting the printers I’m going to be teaching a BDD w/Rails class with the amazing guys at Collective Idea

Hope to see you there!

Scenario Observation

2009-03-20T00:00:00-04:00

One of the hardest things about being the developer and the scenario writer is that we’re in the thick of it. Once we get something written down we want to get it to work and then move on. This may involve copy and pasting part of an existing scenario to just get the job done. We get antsy.

One of the benefits of having the customer (or someone else) write the scenario is that we get to be the critic and not the author. We can focus on the scenario and ask questions like: does it read well? Is it doing too much? Is doing little? Can I understand its intent? etc. etc.

When working with a pair our pair should really challenge us to write good, communicating, intention revealing scenarios (just like they should be doing with code). This can be hard when we are working solo because we may just be staring at the screen for too long, and we can’t see the forest for the trees. If that’s the case grab someone else for a quick review, even if it’s after you finish implementing the scenario. Refactoring applies to scenarios to.

Scenarios are like code, if we don’t tend them well, they will grow messy and hard to maintain. We are best served to spend a little time upfront to keep them tidy rather than wait until we have hundreds of steps that don’t do a good job of communicating and require people to have to read through all of the step definitions to figure it out.

Go forth and code! ;)

ar-extensions 0.8.2 released

2009-03-17T00:00:00-04:00

ar-extensions 0.8.2 is released. This release fixes compatibility issues with Rails 2.3.1 and Rails 2.3.2. It should show up soon at a rubygems mirror near you.

Thanks to Stephen Heuer, Glenn Rempe, and Michael Murray.

gem install ar-extensions -v 0.8.2

CachingPresenter has moved

2009-02-14T00:00:00-05:00

What is CachingPresenter?

CachingPresenter is a very small presenter pattern implementation in Ruby. In short, the presenter pattern is a technique used to separate presentation logic (aka display logic or view logic) from domain logic and from the view templates themselves. There are a number of reasons this pattern is beneficial when used:

it stops presentation logic from creeping into domain objects and muddying up their implementation and their business logic
it stops unnecessary logic from creeping into the views themselves which should be as simple, flexible, and changeable as possible
it allows you to organize presentation logic in better ways than simply maintaining helper modules that are included everywhere

CachingPresenter seems to be benefit most web-based projects where there is benefit from a separation between the view templates and corresponding presentation logic. It works superbly with Rails, but it is not dependent on Rails. You can use it for any ruby project, web-based or not.

Recent Changes

:requiring is removed in favor of :accepts

The :requiring option has been removed in favor of :accepts. This allows all additional arguments to be optional. For example:

class NinjaPresenter < CachingPresenter
  presents :ninja, :accepts => [:sword, :agility]
end

# supplying all options
ninja = NinjaPresenter.new :ninja => Ninja.new, :sword => Sword.new, :agility => 100.percent

# supplying only some options, previously this would yell at you for not supplying :agility
ninja = NinjaPresenter.new :ninja => Ninja.new, :sword => Sword.new

Caches hash-reader methods

If a presenter defines the #[] method or if what is being presented on responds to the

[] methods all calls to the presenter using hash-like accessors will successfully be

cached. Previously this would die.

class SamuraiPresenter < CachingPresenter
  presents :samurai, :accepts => [:stats]

  def \[\](key)
     @stats\[key\]
  end
end

samurai = SamuraiPresenter.new :samurai, :stats => { :dexterity => 80.percent }
samurai[:dexterity] # => 80.percent

Does not try to cache writer methods

Usually you don’t use writer methods on presenters, but every now and then there is a good reason. Previously, CachingPresenter would completely fail if you writer to define an writer method, now it doesn’t. And it will successfully not be cached.

class SamuraiPresenter < CachingPresenter
  presents :samurai, :accepts => [:stats]

   # previously this line would have failed miserably
  def sword=(sword)
  end

end

Questions / Docs / Contact / Etc

Any questions, checkout the github page and its corresponding wiki . If all else fails let me know, zach dot dennis at gmail dot com

ar-extensions 0.8.1 released

2009-02-10T00:00:00-05:00

ar-extensions 0.8.1 is released. This is primarily a bug fix release to ensure it works successfully with Rails 2.2.2. Here are the changes:

fixed issue in http://zdennis.lighthouseapp.com/projects/14379/tickets/14-join-table-conditions-broken
Updated usage of Inflector to point to ActiveSupport::Inflector
Fixed bug where finder conditions which use arext-suffixed keys and normal field keys would fail when using a conditions hash. (Gabe da Silveira)
added timestamps options to not automatically add timestamps even if record timestamps is disabled in ActiveRecord::Base (Thibaud Guillaume-Gentil)
Updated to use alias_method_chain so that multiple aliased finders remain intact (Marcus Crafter)

It may take a little while for the gem to show up in the rubygem mirrors. Thanks to everyone who contributed!

Long time, no see

2009-01-06T00:00:00-05:00

It’s been a long while since I’ve written. It’s been more due to time constraints than anything. Last spring I joined Mutually Human Software full-time, then in the early summer spoke at RailsConf, and then in the late summer started working on The RSpec Book. 2008 was a very busy year all the while spearheading a project for the state of Nebraska.

I have a lot of rough draft articles I’d like to clean up and push out, as well as finish Annex – the soon-to-be 1.0 release of ar-extensions. In the meantime I am going to be pushing some things out to the Mutually Human blog like the recent post on “Using custom ActiveRecord events/callbacks.

We’ve also just wrapped up the year with finishing a project for one our clients. If you need assistance with an existing project, or are looking to get a new project off the ground, or are interested in training/consulting we do that over at Mutually Human. Our specialty is web applications. Be sure to drop us a line at zdennis at mutuallyhuman dot com.

Stay tuned, this is going to be an eventful Spring both at continuousthinking and MHS,

ar-extensions 0.8.0, forgot to mention

2008-08-16T00:00:00-04:00

Update: ar-extensions is no longer maintained for Rails 3.x and above. Please see activerecord-import.

I forgot to mention that ar-extensions no longer loads adapter specific functionality by itself. You need to tell it what you want. For example if you want to load import functionality for MySQL you’d have to require the right files, like so:

require 'ar-extensions/adapters/mysql'
require 'ar-extensions/import/mysql'

Sorry about that.

ar-extensions 0.8.0 released!

2008-08-06T00:00:00-04:00

ar-extensions 0.8.0 is finally released! All known bugs and compatibility issues with Rails 2.1.0 have been resolved.

0 does not work with the latest Rails edge due to some additional features on edge that weren’t in 2.1.0
0 should not be used with Rails 2.0.2 or below

If any feature requests or bugs please report them on lighthouse.

Installing

gem install ar-extensions

Oracle and PostgreSQL users

If you’re using ar-extensions 0.7.0 with Oracle or PostgreSQL I am very interested to find out if 0.8.0 works fine. I don’t have Oracle, and I’m not a PostgreSQL user. If you’re interested in running the test suite against one of those databases please let me know.

Thanks for your patience and enjoy!

cheat --execute

2008-08-01T00:00:00-04:00

I hate having to continuously lookup the steps to install things every few weeks. The cheat gem works for most things to find installation instructions relatively quickly, but sometimes I just want to install something, not necessarily have to search through lines of example usage to find the installation instructions. Enter two new options for the cheat gem: dash x and dash dash execute. It’s simple. For example:

cd /some/dummy/rails/project
cheat install_rspec_rails -x

  # This is to install the latest rspec/rspec-rails into 
  # a rails project. 
  script/plugin install git://github.com/dchelimsky/rspec.git
  script/plugin install git://github.com/dchelimsky/rspec-rails.git
  script/generate rspec

Would you like to execute the above sheet? (Y/N)

I’ve sent defunkt a pull request on github, I hope it includes the change. Until then, the change is only on my fork

To install do the following:

git clone git://github.com/zdennis/cheat.git
cd cheat
rake package
sudo gem install pkg/cheat-1.2.2.gem

Enjoy,

ar-extensions, Rails 2.x followup

2008-07-18T00:00:00-04:00

Update: ar-extensions is no longer maintained for Rails 3.x and above. Please see activerecord-import.

First things first, ar-extensions moved to Lighthouse and Github. So please no more tickets or patches on rubyforge. I’ll close out or move over the ones on rubyforge that currently reside there.

ar-extensions at Lighthouse
ar-extensions at GitHub

Now, the fun stuff.

ar-extensions and Rails 2.x compability

For the most part ar-extensions 0.7.0 (and below) is not compatible with Rails 2.0.x and 2.1. The import functionality works, but ar-extensions will bork on some edge cases of using ActiveRecord::Base.find methods. It won’t return the wrong value, it will simply raise an exception. So if you’re using ar-extensions in your Rails 2.x app, the app itself will probably bork (and I realize that you probably already know this). If you’re using the import functionality in isolation then you should be fine.

Some of the loading issues with ar-extensions that people had are due to ar-extensions being loaded during the time that Rails goes through the loading process (if you put require ‘ar-extensions’ in config/environments/development.rb, test.rb or production.rb). You can get around this by moving if after the Rails::Initializer.run block in your config/environment.rb file.

Tonight I made several commits to get ar-extensions closer to Rails 2.1.0 compatibility. HEAD right now is Rails 2.0.1 compatible, but not 2.0.2 or 2.1.0 compatible. As soon as ar-extensions is compatible I will release 0.8.0. I am hoping for it to be released within the next few days. And by compatible I mean that ar-extensions not only passes its own tests, but it also doesn’t break any of ActiveRecord’s tests.

Using Seed Data with RSpec Stories

2008-07-17T00:00:00-04:00

Yesterday I needed to introduce seed data into our application. In order for our story suite to continue to run I needed to populate seed data into the testing environment when the stories ran. I didn’t want to use the production seed data in my test environment, but I wanted to keep things simple. I am already using using “seed_fu”:http://github.com/mbleigh/seed-fu/tree from Michael Bleigh to handle the seed data for production. Why not leverage it for stories as well?

I made a minor modification to the task to support passing in an argument to rake or setting an environment variable so you can load “fixtures” from a different directory. In my “stories/helper.rb” file I have added near the top:

system "rake db:seed FIXTURE_PATH=stories/fixtures"

This loads the seed data from “RAILS_ROOT/stories/fixtures”. Here’s the modified seed_fu rake task:

namespace :db do
  desc "Loads seed data from db/fixtures for the current environment."
  task :seed => :environment do
    fixture_path = ENV["FIXTURE_PATH"] ? ENV["FIXTURE_PATH"] : "db/fixtures"
    Dir[File.join(RAILS_ROOT, fixture_path, '\*.rb')].sort.each { |fixture| 
      puts "\n== Seeding from #{File.split(fixture).last} " + \
         ("=" * (60 - (17 + File.split(fixture).last.length)))
      load fixture 
      puts "=" * 60 + "\n"
    }
    Dir[File.join(RAILS_ROOT, fixture_path, RAILS_ENV, '\*.rb')].sort.each { |fixture| 
      puts "\n== [#{RAILS_ENV}] Seeding from #{File.split(fixture).last} " + \
          ("=" * (60 - (20 + File.split(fixture).last.length + RAILS_ENV.length)))
      load fixture 
      puts "=" * 60 + "\n"
    }
  end
end

After this my seed data was resembling the typical format:

ExpenseCategory.transaction do
  ExpenseCategory.seed(:object_code) do |s|
     s.object_code = "1234"
     s.name = "Foo"
  end

  ExpenseCategory.seed(:object_code) do |s|
     s.object_code = "1235"
     s.name = "Bar"
  end

  ExpenseCategory.seed(:object_code) do |s|
     s.object_code = "1236"
     s.name = "Baz"
  end
end

And while I like this it’s a little verbose. So I modified seed_fu to introduce the seed_many method to consolidate that:

ExpenseCategory.transaction do
  ExpenseCategory.seed_many(:object_code, [
     { :object_code => "1234", :name => "Foo"},
     { :object_code => "1235", :name => "Bar"},
     { :object_code => "1236", :name => "Baz"}
  ])
end

It maintains a simple API and highly readable seed data. I’ve committed this to my fork of seed_fu, and am hoping that Michael accepts the patch and adds it to seed_fu.

The patch for the rake FIXTURE_PATH: “http://github.com/zdennis/seed-fu/commit/4d391aa214c369f161e37c194b07d49e55312b35”:http://github.com/zdennis/seed-fu/commit/4d391aa214c369f161e37c194b07d49e55312b35
The patch to add the seed_many method: “http://github.com/zdennis/seed-fu/commit/9f7e8b27b7cb175911474a898ea282771ab2a5c3”:http://github.com/zdennis/seed-fu/commit/9f7e8b27b7cb175911474a898ea282771ab2a5c3

ar-extensions, Rails 2.x

2008-07-17T00:00:00-04:00

There are some issues with ar-extensions and Rails 2.x. At first glance it mainly has to do with load order and what to load. I’m going to try to post an update or at least instructions tomorrow so people can use ar-extensions with Rails 2.x and up.

I’m going to be moving the codebase to github and will start work on ar-extensions to get closer to a 1.0 release later this fall. I plan to kick out 0.8 which includes some bug fixes and any Rails 2.x issues as soon as possible.

I am also looking into using Lighthouse for tickets. Rubyforge’s bug tracking isn’t the greatest and apparently there have been tickets there for a while that I had no idea about (sorry about that).

9 will be the first release where I look to improve and cleanup the codebase. Thanks for your patience.

Any questions, comments or suggestions feel free to let me know. Thanks,

Refactoring Your Rails Application - Tutorial Content

2008-06-03T00:00:00-04:00

I posted the tutorial slides and example app as well as the refactoring catalog to OReilly’s RailsConf 2008 web site, but I couldn’t tell you where to access it, because I couldn’t find the public download links. So here are the links to the material on this server:

“Rails Refactoring Catalog from the tutorial “:http://www.continuousthinking.com/railsconf2008/refactoring_your_rails_application_catalog.pdf
“Refactoring Your Rails App tutorial slides”:http://www.continuousthinking.com/railsconf2008/refactoring_your_rails_app_slides.pdf
“Refactoring Your Rails App example app from the tutorial”:http://www.continuousthinking.com/railsconf2008/example_app.zip

The example app is also available from github if you’d like to download the revisions and the different branches used for the tutorial

“http://github.com/zdennis/strac/”:http://github.com/zdennis/strac/

Just refer to the refactoring branch and any other branch with “refactoring” in the name.

The official project which the example app is based on is called Strac. The official github repository can be found at “http://github.com/mvanholstyn/strac/”:http://github.com/mvanholstyn/strac/

If you have any questions, comments or feedback on any of the material or the example app feel free to email me at zach dot dennis at gmail dot com.

RailsConf: RYRA, how'd it go?

2008-05-29T00:00:00-04:00

In regards to the tutorial on Refactoring Your Rails Application, how you felt the talk went?

I’ll post more later with slides and links for the downloadable code.

H.R. 5353 - I called, have you?

2008-05-05T00:00:00-04:00

I just got off the phone with my state representative Peter Hoekstra’s office to urge him to support the Internet Freedom Preservation Act os 2008 – “H.R. 5353”:http://www.opencongress.org/bill/110-h5353/show

For more information on the issue or to determine who to call and what to say, please see “www.savetheinternet.com”:http://www.savetheinternet.com

Net Neutrality - Save The Internet

2008-05-03T00:00:00-04:00

If you haven’t heard of “Net Neutrality”:http://en.wikipedia.org/wiki/Network_neutrality before, wikipedia describes it as:

”… a principle that is applied to residential broadband networks, and potentially to all networks. A neutral broadband network is one that is free of restrictions on the kinds of equipment that may be attached, on the modes of communication allowed, which does not restrict content, sites or platforms, and where communication is not unreasonably degraded by other communication streams.”

Unfortunately there are corporations out there which want to control access, speeds and content available to those connecting to the Internet through their services. Below is an informative 10 minute video (I found it at “http://www.matthewgood.org/2008/05/net-neutrality/”:http://www.matthewgood.org/2008/05/net-neutrality/). If you have the time please hit play.

If this issue concerns checkout “www.savetheinternet.com”:http://www.savetheinternet.com . I urge you to spread awareness of the issue and contact your congressman.

Book Review - Ruby on Rails: Enterprise Application Development

2008-05-03T00:00:00-04:00

I know Slashdot is a busy place, but come on, four months and a book review is still pending, and they don’t respond to any emails? Anyways here is my review of “Ruby on Rails: Enterprise Application Development”.

Ruby on Rails – Enterprise Application Development by Elliot Smith and Rob Nichols targets a new niche in the Rails world of published books. Its goal is to connect all of the dots that make up typical Rails development for developers who have been through the tutorials, but wonder ‘what do I do next?’

<p>The focus of this book is breadth and not depth. The authors do a good job of balancing the explanation of essential Rails concepts while letting the reader know when they are approaching a more advanced topic that won&#8217;t be covered in depth.</p>


<p>Throughout the book the authors follow a fictional, yet realistic scenario in which Rory the IT guy implements a simple web-based contacts management application. Each chapter builds on the previous walking the reader through the whole process of development to production deployment.</p>


<p>There is no Rails development until Chapter 4, pg 91. The emphasis of the first 90 pages is understanding what Rails is and why you would use it, as well as introducing the problem scenario that will be used throughout the book. This would be a bigger turn off then it was, but the authors made up for this a little walking the reader through installing everything required for Rails development on multiple operating systems.</p>


<p>Rather then focus on a single platform for development or production the authors use a mixed environment of Ubuntu Linux, <span class="caps">OSX</span> and Windows and a cross platform Eclipse <span class="caps">IDE</span>. They also take the time to walk the reader through installation and setup of each platform as it pertains to Rails development.</p>


<p>The majority of the development in this book sticks to the functionality included in Rails itself. When it comes to core components of Rails the authors do a great job of covering them: migrations, models, validations, associations, controllers, filters, views and view helpers.</p>


<p>Plugins are not covered except for acts_as_attachment, which is now deprecated in favor of attachment_fu.</p>


<p>The only issue I had with the book was with the sections on testing. The authors cover unit and functional testing with the built-in Rails testing framework. Unfortunately, the example tests are horrible and should not appear in production quality code. The sections on testing should only be used to understand how the built-in testing framework works in Rails and not as an example for writing tests. It is too bad that the authors didn&#8217;t cover integration testing either.</p>


<p>A good thing that did come out of the testing sections in this book is the encouragement for developers to write tests which expose bugs before fixing them. It&#8217;s the only way to ensure you really fixed it.</p>


<p>Rails 1.2.3 is used throughout the book so any changes, improvements or deprecations in Rails 2.0 aren&#8217;t covered. If the reader follows the book with Rails 1.2.3 they should have no issues walking through and developing the code themselves. If the reader follows the book with Rails 2.0 they should be aware of some of the changes, those can be found at <a href="http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done">http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done</a></p>


<p>The things that stuck out to me were:</p>


<ul>
<li>view template file naming conventions</li>
	<li>the verbosity of not having named routes</li>
	<li>the lack of the db:rollback rake task</li>
</ul>


<p>The authors take the time to walk the reader through setting up and using Subversion as an integral part of Rails software development. It also includes setting up and using Apache and Mongrel to serve Rails. As the book moves from development to production deployment the user is shown how to deploy automatically from Subversion to their production server using Capistrano.</p>


<p>There were a few minor typos and one redundant sentence on page 52. This is considerably lower then other technical books that I&#8217;ve read.</p>


<p>The only giant red sections marked in my copy are the ones on testing. Take those examples with a grain of salt.</p>


<p>Overall, the majority of the book is filled with good advice for novice Rails developers like, &#8220;do not wait until your application is built before you create and test the production environment&#8221; and &#8220;involve the end users throughout the process&#8221;.</p>


<p>If you are a novice Rails developer who understand bits and pieces of Rails this book does a good job of connecting the other dots because the authors take the time to go through the full process of development to production. On the other hand if you have a good grasp on the whole Rails development process you can skip this book.</p>


<p>A good chapter outline of this book can be found at PACKT's <a href="http://www.packtpub.com/Ruby-on-Rails-Enterprise-Application-Open-Source/book">web site</a></p>.

form_test_helper, select_form update

2008-04-02T00:00:00-04:00

Revision 71 of form_test_helper includes a bug fix for the select_form method. Previously calling select_form with a block would submit the form. The fix forces you to call submit on the form. So…

# THIS which used to submit the form
form = select_form 'trip' do |form|
  form.trip.destination = "bahamas"
end

# WILL NOW LOOK LIKE THIS
form = select_form 'trip' do |form|
  form.trip.destination = "bahamas"
end
form.submit

This doesn’t affect the usage of submit_form which still acts as expected.

This will be included in the next release of form_test_helper. Currently trunk for form_test_helper works with Rails 2.0.0 and higher (including today’s most recent trunk commit).

The form_test_helper edge docs have been updated as well and can be found “here”:http://continuous.rubyforge.org/form_test_helper/rdoc/

Rails Ticket #11491

2008-04-01T00:00:00-04:00

If you have a few minutes, please review and comment on Rails ticket #11491.

“http://dev.rubyonrails.org/ticket/11491”:http://dev.rubyonrails.org/ticket/11491

In short, it adds the ability for “render :partial => some_collection” to render the correct partial based on each element in some_collection. Currently Rails uses the first element to determine what to render for every element in the collection.

Thanks in advance,

More People != More Progress

2008-03-25T00:00:00-04:00

There is a common misconception that the best way to add capacity to a project and reduce its completion date is simple – just throw more people at it. Although there is some truth in this, it is usually applied at the wrong times and it ends up having a very negative impact on the project.

This mindset that project development is a series of tasks and that somehow you can just throw people at them and everything will work out is foreign to me, because it won’t work out – at least not when it’s applied in haste.

Adding value to a project is more than completing tasks. Tasks are not isolated during project development. They are features which build on top of one another. Making good responsible decisions and understanding the code base both technically and conceptually goes a long way to help exploit easier and better ways of implementing features. This also helps keep the code base well factored, which in turn helps teams progress consistently and avoid creating a giant roadblock of technical debt which may have lurked just ahead.

What is a factory and why FactoryLoader?

2008-03-22T00:00:00-04:00

This statement and question were posted to the “http://www.gr-ruby.org”:http://www.gr-ruby.org mailing list as it pertained to the release of FactoryLoader. This post should answer the question “what is a factory?” and also provide more insight into what FactoryLoader’s role is.

> I've read over your website, but I still have a lagging question which
> completely blinds my ability to see the usefulness of it: What is a factory?

A factory is “a mechanism for encapsulating complex creation logic” [0].

Here’s an example. Let’s say that you start writing an application that is a project management tool for a business. To start with they need the ability to create Projects. This is no big deal, you have a ProjectsController#create action and it makes your Project by doing something similar to the below:

def create
  project = Project.new params[:project]
  if project.save
    flash[:notice] = "successfully created the project"
    render :action => "create"
  else
    flash[:error] = "failed to create the project"
    render :action => "new"
  end
end

Now a few weeks later the customer says that in order to create a project it needs to be assigned a project manager off the bat (the currently logged in user). This is not a very big deal since you have a “current_user” already, you just update your controller to look like:

def create
  project = Project.new params[:project]
  project.manager = current_user
  if project.save
    flash[:notice] = "successfully created the project"
    render :action => "create"
  else
    flash[:error] = "failed to create the project"
    render :action => "new"
  end
end

A few more weeks go by and your customer says that projects are tied to company budgets and when they are created they need to be automatically assigned to the correct budget based on the type of project. So we update to ProjectsController#create looks like the below:

def create
  project = Project.new params[:project]
  project.manager = current_user
  project.budget = Budget.find_by_project_type(project.type)
  if project.save
    flash[:notice] = "successfully created the project"
  else
    flash[:error] = "failed to create the project"
    render :action => "new"
  end
end

Uh oh. There are important business rules being applied in the controller. The controller’s responsibility is to map an incoming request with an outgoing response and to know high level what the application needs to be doing. It should not know the intimate details of Project creation. Since we’re implementing the business rules on the controller we can’t re-use them for anything, unless we make a POST request to ProjectsController#create. This is quite limiting.

Another option to make them more reusable would be to tuck this away in the Project model itself. Perhaps we add a before_save callback which finds the appropriate budget. Even then we’ve only moved the budget logic out of the controller and there is still requirement for a Project to have a manager. If we go this route we’ll be separating two important pieces of how a Project gets constructed from each other. We would have the ProjectsController#create action setting the manager and then a before_save callback on the Project model finding a budget, both of which are required for a Project to be constructed.

One thought to remedy this would be put everything in the Project model, maybe in a before_save callback or overriding the constructor. But we quickly hit a roadblock because our Project model doesn’t know about the current user, that is application state and only the model knows about that. We could do something stupid and make the current_user global to the application, but that is a bad decision with pretty bad repercussions.

It’d be nice if we had a single object responsible for constructing a Project with these business rules. This is where a ProjectFactory comes into play. The ProjectFactory looks like:

class ProjectFactory
  def create(project_attrs, manager)
    project = Project.new project_attrs
    project.budget = Budget.find_by_project_type(project.type)
    project.save!
    project
  end
end

And the ProjectsController#create action looks like:

def create
  project = ProjectFactory.create params[:project], current_user
  flash[:notice] = "successfully created the project"
rescue 
  flash[:error] = "failed to create the project"
  render :action => "new"    
end

This is pretty straightforward. I just moved some of the lines from the action into the factory. More importantly then just moving line of code is that the act of constructing a valid project (given the customer’s requirements) isn’t the responsibility of the Project. The act of constructing a valid project is a process by itself which is important to the customer, so we isolate it in a ProjectFactory.

This is valuable because:

the business logic used to construct a project is in one spot. Should the customer change, add or remove requirements you only have to go to one spot to implement them. Granted if the method signature to this changes you have to go update the spots calling the create method, but you the actual logic for constructing the project isn’t spread throughout multiple files or classes.
it promotes reusability (the whole DRY thing), since my ProjectFactory is much more reusable then my ProjectsController.
it promotes single responsibility
it provides clearer meaning to the code base because we aren’t muddying up the controller or the Project model with creation logic
it makes for easier testing and easier to understand tests

The technical implementation of this pattern is mentioned in the GoF book [1]. The value of the pattern as it applies to Domain Driven Design is mentioned in the DDD book by Eric Evans.

Hopefully that helps clarify what a factory is, by seeing how it is used and some of the value it provides. This relates to the FactoryLoader because sometimes the progression of creation logic is over time.

For the first few weeks or months of a project you are hardcoding things like “Project.create” in multiple spots. When the customer starts introducing requirements for constructing (or updating) a Project you have to go update all of those spots with the same code (violating DRY) or go find all of those spots and refactor them to use a ProjectFactory, and then make a ProjectFactory. It doesn’t happen all the time, but when it does happen it can be time consuming, frustrating and painful to do.

What FactoryLoader would do in our example is it give us a ProjectFactory upfront w/o having to write any code. If we used FactoryLoader in the above example our ProjectsController#create action would look like:

def create
  project = ProjectFactory.create params[:project]
  if project.save
    flash[:notice] = "successfully created the project"
    render :action => "create"
  else
    flash[:error] = "failed to create the project"
    render :action => "new"
  end
end

Where the ProjectFactory is created for you by FactoryLoader (you didn’t create the class, FactoryLoader did dynamically). There’s only one line that differs between the example that uses the FactoryLoader and the one that doesn’t.

Now when the customer starts adding business rules for creating a Project you can create your own ProjectFactory class and implement the customer’s business rules. FactoryLoader will see that you have provided your own ProjectFactory so it won’t dynamically create one. Since all of the spots where you create a Project are already using a ProjectFactory they get the changes for free. Overall you get to touch less code for the changes and you get to spend less time refactoring if any refactoring is needed.

The goal of FactoryLoader is to allow developers the ability to scale to these customer requirements with less pain. The above examples have been quite trivial, hopefully they are clear enough and meaningful enough to express why I wrote FactoryLoader,

Zach Dennis http://www.continuousthinking.com

0 - Domain Driven Design by Eric Evans
1 - Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides

Factory Loader

2008-03-18T00:00:00-04:00

FactoryLoader is intended to help scale object creation with less pain and less refactoring by creating factory classes for basic object construction.

In the early stages of a project object creation is simple and dependencies are kept to a minimum. As the project grows so does the complexity of object creation and its dependencies. It doesn’t make sense to create custom factory classes upfront to deal with complex object construction that may not exist yet. But when those custom factories are needed it is usually painful and time consuming to update the code base to use them. It’s also easy for developers to give-in due to time constraints and start making bad decisions.

This is where FactoryLoader comes into play. It automatically creates a Factory class for your objects and provides a create method which passes any arguments along to your object’s constructor.

When you need to have custom factory behavior you can implement the factory without having to update other code references (assuming you’ve used the factory in the rest of your application rather then direct class references).

  project/
    init.rb
    lib/
     |--things/
            |-- foo.rb
            |-- bar.rb
     |--factories/
            |-- bar_factory.rb

Given the above project directory structure you could have the following code in init.rb:

 factory_loader = FactoryLoader.new("lib/factories")
 factory_loader.load("lib/things")

The first call constructs a factory loader telling it which directory is used to store developer-written custom factories.

The second call will create an in-memory factory class for each *.rb file in the lib/things/ directory. A FooFactory class will be created to correspond with the foo.rb file. The generated factory will provide a create method which will pass along all arguments to the constructor of the object it wraps. So…

 FooFactory.new.create :a => :b

is the same as:

 Foo.new :a => :b

Even though a bar.rb file exists a BarFactory will NOT be created. This is because we told the FactoryLoader that custom factories are storied in lib/factories/ and a bar_factory.rb file exists there, so FactoryLoader assumes you want to use a custom factory. It also assumes that the class inside of bar_factory.rb is BarFactory.

FactoryLoader dynamically creates the factory classes â€” they are not written to disk. FactoryLoader also uses file naming conventions to determine what to do. For example:

 foo.rb => FooFactory
 crazy_dolphins.rb => CrazyDolphinsFactory

Factory.new

The dynamically created factories are classes and create is an instance method on them. You have to construct a factory in order to use it. This is so the factories themselves can be easily used in dependency injection frameworks.

Making a custom factory

So you’re using FactoryLoader to do the work of creating factories for you. Let’s say our Foo object now has some creation logic that we do not want in Foo’s constructor. To put it in the FooFactory just create the file in lib/factories/foo_factory.rb. The contents of foo_factory.rb might look like:

class FooFactory  
  def create options={}
    if business_logic_passes?
      Foo.new options
    else
      raise "business logic failed"
    end
  end
end

Install it!

gem install -r factory_loader

More Info

RDOC: “http://mhs.rubyforge.org/factory_loader/rdoc/”:http://mhs.rubyforge.org/factory_loader/rdoc/
Public git repository: “git://github.com/zdennis/factory_loader.git”:git://github.com/zdennis/factory_loader.git
Homepage: “www.continuousthinking.com/factory_loader”:www.continuousthinking.com/factory_loader

Author

Me, Zach Dennis

Special Thanks

Dave Crosby at Atomic Object
Ryan Fogle at Atomic Object

Trying RSpec's Rubyesque Stories

2008-03-05T00:00:00-05:00

Today my pair and I wrote some stories using the rubyesque RSpec story style along with a corresponding step file. It went better then expected. We ended up a story like:

# in stories/expenses/a_user_creating_a_misc_expense_story.rb
Story "User creating misc. expense", %|
  As a user 
  I want be able to submit an expense reimbursement request for a misc. expense
  so that I can be reimbursed for business expenditures|,
  :steps_for => :expense,
  :type => RailsStory do

  Scenario "creating a misc. expense unsuccessfully" do
    Given "a user at a new expense reimbursement page"
    # ....
  end

  Scenario "creating a misc. expense successfully" do
    Given "a user at a new expense reimbursement page"
    # ...
  end
end


# in stories/steps/expense.rb
steps_for :expense do
  Given "a user at a new expense reimbursement page" do
    go_to_root
    click_new_expense_reimbursement_link
  end

  # ...
end

One nice thing that came out of this was a small patch to RSpec which David committed tonight involving the options you pass along to Story. Now when declaring a story you can consistently use the *steps_for* option rather then using *steps_for* and/or *steps*.

Previously you could use the *steps* option to pass in a custom StepGroup but that is no longer supported in trunk. Now you use *steps_for* when supplying a custom StepGroup, a symbol or an array of StepGroups and symbols. This helps avoid confusion of passing in *steps* or *steps_for* and not getting what you expect.

Overall there are four story styles (that I'm aware of) in RSpec: plain text stories, rubyesque stories with separate step files, rubyesque stories with inlined steps and rubyesque stories with inlined blocks. We did try using plain text stories at first, but one drawback of plain text stories is being able to run them individually from within your editor or easily from the command line. We didn't have the need for plain text stories so we opted to not use it. We started using the rubyesque stories with inlined steps secondly until we got a feel for the stories and then we moved those steps into their own file so we could achieve higher reuse and better step organization. We knew coming in that we were not going to use the inlined block style since we have used that on another project and it gets clunky really fast. If you're considering using RSpec stories try the rubyesque stories with step matchers (inlined or in separate files). If you're going to take the plunge into trying plain text stories look to RSpec itself for examples. The actual stories in the stories/ directory helped us get up and running earlier today.

Mocha's error messages suck

2008-02-26T00:00:00-05:00

Mocha’s parameter matching error messages suck.

When writing a failing test similar to the below snippet I am given the error message “undefined method `keys’ for :no_args:Symbol”

@user.should_not_receive(:update_attributes).with(has_key('name'))

I love Mocha’s parameter matching, but what kind of error message is that?

This is not the first time I’ve gawked at Mocha’s error messages, but this time just did it for me. My pair didn’t know if we should ping or if we had broken our app.

Pair Programming in 1 sentence

2008-01-29T00:00:00-05:00

Pair programming is a catalyst to writing better software.

Trying out Vlad the Deployer

2008-01-26T00:00:00-05:00

This blog wasn’t using any form of automated deployment until late last night. For the longest time rsync and ssh seemed to be adequate enough even though I’m familiar with “Capistrano”:http://www.capify.org and had been well aware of “Vlad the Deployer’s”:http://rubyhitsquad.com/Vlad_the_Deployer.html release. Since I know about Capistrano I decided to invest some time getting to know Vlad.

This site is currently running on a 0.7.3 “Mephisto”:http://mephistoblog.com/ installation with a custom theme by yours truly and it’s hosted on “Dreamhost”:http://www.dreamhost.com/ servers. Out of the box Vlad works with mongrel+apache+svn. Unfortunately Dreamhost uses apache+fastcgi, but thankfully tweaking Vlad was a piece of cake.

I followed the instructions on the “examples”:http://rubyhitsquad.com/Examples.html page for Vlad, but ultimately found I needed to do a little tweaking for my environment. Based on those basic examples I ended up making the following changes to my Rakefile and deploy.rb recipe file.

Here’s what I appended to my Rakefile:

# appended to my Rakefile
require 'vlad'
Vlad.load(:app => :apache)

Here’s my config/deploy.rb file:

set :domain,      "continuousthinking.com"
set :deploy_to,   "/my/path/to/continuousthinking.com/"
set :repository,  "http://myserver/svn/continuousthinking.com/trunk"
set :web_command, "echo skipping web "

namespace :vlad do
  remote_task :start_app do
    run "pkill -f dispatch.fcgi"
    fork do
      puts "sending a request to the domain so dispatchers restart"
      `wget http://#{domain} -O /dev/null`
    end
  end

  remote_task :update do
    Rake::Task['vlad:after_update'].invoke
  end

  remote_task :after_update do
    run "ln -s #{deploy_to}/shared/system/database.yml #{deploy_to}/current/config/database.yml"
    run "rm -f /home/zdennis/continuousthinking.com &&
         ln -s #{deploy_to}/current /home/zdennis/continuousthinking.com"      
  end

  remote_task :deploy => [:update, :start_app]
end

I overrode the :web_command setting so Vlad didn’t try to restart apache. The other tasks were added to customize specific needs for the deployment of the blog:

:start_app - kill all of dispatchers on Dreamhost and then send a request to have Dreamhost launch new ones
:update - adds this task to the :update task call chain. This simulates an after_update.
:after_update - create symlinks, etc to be performed after code has been updated.
:deploy - update code and restart the app

Overall, it was a pleasant process. I give Vlad a +1.

ar-extensions get a little praise

2008-01-20T00:00:00-05:00

Alan Miles found the import functionality of my ar-extensions gem/plugin helpful and he posted about it “here”:http://www.jobwd.com/article/show/31

I’m so glad to hear that ar-extensions is helping Alan and it’s nice to see that he’s sharing this usefulness with others via his “blog”:http://www.jobwd.com/

Ã¢ÅË-k Hotkey in bash, on linux

2007-12-29T00:00:00-05:00

I never thought I would say “I wish my console acted more like the OSX’s Terminal.app”, but the truth is that I said that two days ago. That day my MacBook Pro (MBP) went out of commission due to an accidental overdose of Raspberry Iced Tea. Ever since then I’ve been plugging away on my Kubuntu box using Yakuake and Emacs23 to develop.

I have this obsessive need to clear the terminal all the time during development, primarily when I’m going to run tests. On my MBP I would just hit ⌘-k to clear the terminal, but I don’t have that luxury in Yakuake or any other terminal that I know of. So why not roll my own?

After googling around for a while I found this “article”:http://linuxgazette.net/issue55/henderson.html by Bryan Henderson from the “Linux Gazette”:http://linuxgazette.net . Even though the article is seven years old it still applies. In addition to this article I also read the man page for readline which has a lot of cool information in it. Since bash relies on readline to do the input processing new doors have opened for what I want to tinker with on my system.

Writing Your ⌘-k Hotkey

Create a ~/.inputrc file. In that file put the following contents. Now log out and log back in (or fire up a new terminal session):

"\ek":"\C-a\C-kclear\n\C-y"
"\C-x\C-r": re-read-init-file

The first line expresses that I want Meta-k to map to the following set of keystrokes:

C-a which brings me to the beginning of the line
C-k which cuts the line
clear which is used to clear the terminal
a newline which executes the clear command just as if I typed it and hit enter
C-y which pastes what I cut with C-k back onto the terminal

And now you have a Terminal.app ⌘-k hotkey on any system that uses bash. The only difference is that its mapped to Meta-k.

The second line is a simple nicety so you can reload your ~/.inputrc file without having to log out and log back in. Just type C-x C-r to reload any changes.

On Writing Good Software

2007-12-22T00:00:00-05:00

The craft of writing is so similar to that of software development. I recently found this out by reading On Writing Well by William Zinsser. Below are some quotes from the book with commentary on how they apply to the software developer.

You will write only as well as you make yourself write.

Substitute write with write software and it remains a truism.

Writing software is easy. Writing good software is hard. It takes discipline to become a good software developer. The only way to get there is to write better software today then you wrote yesterday. And the only way to do that is to learn from what you and others have written.

Clutter is the disease of American writing.

The same can be said for writing good software. It’s very painful to create or find a bloated method or class doing something it shouldn’t be doing. It’s even more painful to maintain. Small and simple works wonders within the design of a program.

Strip every sentence to its cleanest components.

Strip every method and class to include only the functionality it needs to do its job. Methods which might be used at some point – get rid of them. Comments which try to explain away complexity or ambiguity – simplify the code so it’s readable and remove the them. Classes which try to do everything – refactor and pull out things it doesn’t need to do into their own class or module. Clever code – turn it into simple code. Simplify, simplify, simplify.

You must know what the essential tools are and what job they were designed to do.

A carpenter must know how-to hammer nails and saw wood before he can build a house. Likewise, a developer must know how-to write good code, perform object decomposition and refactor before he can build an application. Other basic tools and skills that a developer should know are: writing testable code, testing and test automation.

Take your stand with conviction.

Care about the software you develop. Stand up for customer involvement. Stand up for short iterations. Stand up for testing. Stand up for quality, even when the deadline is fast approaching, it’s the best chance you’ve got for hitting it with working software.

Never hesitate to imitate another writer.

Never hesitate to imitate another developer, especially one that writes better software than you. It will make you better in the process. Find open source projects that exceptional developers have worked on and read that code. How are they attacking a problem? How did they solve it?

A while back a coworker asked me if I had read through Mephisto’s source and I said I had scanned it, but that I didn’t think it was anything special besides the routing. A few weeks later I started reading the source. Rick Olson, the author of Mephisto, has some great techniques and code tucked away in Mephisto, things that I would be missing out on if my coworker would have never challenged me to read the source. Thanks Drew.

…it’s hard not to be intimidated by the expertise of the expert.

Ask questions. If you don’t understand something, ask. If you think it’s a dumb question, ask. Let the resident expert enlighten you. When they explain something and you still don’t get it, ask clarifying questions. They didn’t wake up one day an expert. And neither will you.

Writing is related to character. If your values are sound your writing will be sound.

Developers who have character are exceptional people to work with. They not only write better software, they inspire those around them to write better software.

Decide what you want to do. Then decide to do it. Then do it.

For all of those “I want to learn language X”, “I want to start learning TDD”, etc. statements – start learning language X, start doing TDD.

Think small.

Two immediate thoughts come to mind. First, good object decomposition. Work with simple objects that work with a single responsibility and let the overall system evolve of those simple objects. Second, short iterations over long ones and short stories over full blown specification documents. Thinking small in these regards will help you produce cleaner and simpler code as well as produce the right working features – sooner.

rak, ack and findit

2007-12-13T00:00:00-05:00

In “Helpful Command Line Tools”:http://www.continuousthinking.com/2007/11/23/helpful-command-line-tools from last month I posted on my custom findit script.

Jason Porrit commented on that post and mentioned “ack”:http://search.cpan.org/~petdance/ack-1.75_01/ack , a perl alternative to grep and find which offers terminal color highlighting to your results. I also found this morning a ruby alternative called “rak”:http://rak.rubyforge.org

All of these utilities do the same thing, they search a directory structure for files whose contents match a given pattern.

Here’s Ack

Here’s Rak

Here’s findit

Overall ack and rak beat out findit, but findit has a much better name. I think I’ll just alias findit to rak. (yes I”m biased to ruby code over perl code).

The only thing ack and rak are missing is a filename only option. If I can find every file matching a pattern from a given start directory that would rid me of findfile as well!

be gone from my view foul demon

2007-12-08T00:00:00-05:00

Let’s be disciplined and keep model constants out of our views.

If you have anything like the below in your views, remove it! You may think that it’s a harmless way to re-use a default set in your model, but that is a lie and you need to stop believing it. The above morsel of model loitering easily leads to a full fledged model invasion, which happens slowly and over time.

The view is meant to be stupid, so give it knowledge of nothing in your domain. If you need to pass in defaults then pass them in through instance variables, locals or as default settings on new ActiveRecord models. Let an object with the responsibility of knowing what should be used make that decision and let your view simply display it.

I was recently tempted to use a Avatar::NO_IMAGE_PATH default in a view – the thought lasted a few short seconds and then I banished it from my mind. The NO_IMAGE_PATH default was better handled as a default on an Avatar that didn’t have an image.

# using this in a view
Avatar::DEFAULT_IMAGE

# became

@avatar.image_path

If you keep a list of things that are good candidates for refactoring run the below script from app/views/ in a terminal. It will find all of the model constants laying dormant.

cd app/views/
grep -HnE "[A-Z].+::[A-Z]" *

You will see output like the below:

projects/show.html.erb:22:Avatar::DEFAULT_IMAGE
users/index.html.erb:4:User::SOME_SETTING
events/_list.html.erb:6:Event::DEFAULT_TIMEZONE

A small victory for clean and well factored code.

RMagick, Rubygems and Windows

2007-12-05T00:00:00-05:00

Rubygems 0.9.5 doesn’t like RMagick on Windows. Here is a useful post from a Google thread which describes how to fix this. Basically re-install 0.9.4.

I woud like to thank Robin Mayfield for indirectly resolving my 
similar issue with RMagick. 

RMagick is now installed and working. 

Here's what I did: 

1. Downloaded 0.9.4 RubyGems zip file. 

2. Ran the setup.rb 

3. From within the unzipped RMagic-win32 directory I ran: gem install 
rmagick-1.14.1-win32.gem --local 

I didn't need to insert require 'RMagick' in the environment.rb file. 

Yeeha!!

Apparently, RMagick doesn't work with RubyGems 0.9.5. 

Thanks again. 

Regards 

Walter

Thanks to Walter Lockhart for reposting this.

magic models, meh

2007-12-01T00:00:00-05:00

While catching up on RSS feeds this morning I followed a few interesting links and again came across a link to “Dr. Nic’s Magic Models”:http://magicmodels.rubyforge.org/dr_nic_magic_models . In the past I felt uneasy about this gem, but now I just don’t think it should be used for real projects, although I’m sure it was a fun exercise for the author to write.

The idea seems to be based on removing declarative statements about your model in your model. You would normally write:

class Person < ActiveRecord::Base
  has_many :memberships
  has_many :groups, :through => :memberships
  belongs_to :family
  validates_presence_of :firstname, :lastname, :email
end

The author finds an issue with this, to him it seems unncessary. So he ponders the question:

Why do I have write my own has_many, belongs_to, and validates_presence_of commands if all the data is in the database schema?

I think this is the wrong question to ask, but I can see where the author came up with the question. As I read through the entire page on magic models I see my code beginning to vanish. Something like:

class Person < ActiveRecord::Base
  has_many :memberships
  has_many :groups, :through => :memberships
  belongs_to :family
  validates_presence_of :firstname, :lastname, :email
end

to…

class Person < ActiveRecord::Base
end

to…

# no more code , the person.rb model file has been deleted

This progression bothers me because in the end you end up without any self-documenting code, and you’ve moved application logic from your application into your database. It seems that I’d rather have a database constraint (like not allowing null fields) reinforce self-documenting declarations in the model such as:

validates_presence_of :firstname, :lastname, :email

And why would you want to kill declarative relationships in your application?

  has_many :memberships
  has_many :groups, :through => :memberships
  belongs_to :family

to …

# ... nothing here ...

Self-documenting code is useful especially when you’re describing how one object relates to another object in your application.

It seems much more appealing to see that in a model rather then having to go fish in the database schema. Leave application logic in the application. There are times you need to use database constraints (among other things) to reinforce your application logic, but you shouldn’t remove self-documenting clean code just because you can.

This is just my developer preference, but I think it’s a good preference to have. I don’t want to unnecessarily spread application logic outside of my application code for the sake of being clever.

form_test_helper edge gets support for multiple submit buttons

2007-11-27T00:00:00-05:00

form_test_helper edge has been updated to support multiple submit buttons on a form. It also includes a fix to avoid namespace collisions if models are named Select, Option, etc.

If you have a view which looks like:

<form id="test">
  <input type="submit" value="yes" />
  <input type="submit" value="no" />
</form>

You can have choose which value to submit when the form is submitted:

# selecting the form and submitting it in separate steps
form = select_form "test", :submit_value => "yes"
form.submit

# submitting a form with a submit value in one step
submit_form "test", :submit_value => "yes"

# submitting a form with a submit value in one step using a block
submit_form "test", :submit_value => "yes" do |form|
   # .. 
end

You don’t have to supply a :submit_value. If you don’t the first submit value found on the form will be used. If you try to supply a non-existent value then an exception will raised.

For example:

# trying to submit on a non-existent input value
form = select_form "test", :submit_value => "fooey"
form.submit  # => raises a FormTestHelper::Form::MissingSubmitError

Installing

As an external:

./script/plugin install -x http://form-test-helper.googlecode.com/svn/form_test_helper

Not as an external:

./script/plugin install http://form-test-helper.googlecode.com/svn/form_test_helper

With piston:

cd vendor/plugins/
piston import http://form-test-helper.googlecode.com/svn/form_test_helper

Rdoc

Rdoc pages for form_test_helper edge are hosted on rubyforge. You can find them at “http://continuous.rubyforge.org/form_test_helper/rdoc/”:http://continuous.rubyforge.org/form_test_helper/rdoc/

If you have any questions feel free to ask. If you find issues, bugs or odd behavior please create an issue over at “http://code.google.com/p/form-test-helper/”:http://code.google.com/p/form-test-helper/

form_test_helper 1.0.1 and 1.1.1

2007-11-27T00:00:00-05:00

form_test_helper 1.0.1 and 1.1.1 have been released.

1 is for people who are on 1.2.x (specifically 1.2.5 and 1.2.6)
1 is for people who are on a Rails Edge revision between 6764 and 7420

If you are on Rails Edge newer then 7420 then you’ll want to use form_test_helper edge. A separate announcement will be made for that release.

The 1.0.1 and 1.1.1 releases fix a namespace collision issue if you happen to have a model named Option or Select. Thanks to Tomasz Wegrzanowski for pointing this out and supplying a patch.

For information on how-to install, or for usage examples please check out the rdoc for these releases:

“1.0.x series rdoc”:http://continuous.rubyforge.org/form_test_helper-1.0.x/rdoc/
“1.1.x series rdoc”:http://continuous.rubyforge.org/form_test_helper-1.1.x/rdoc/

This will probably be the last release for the 1.1.x branch of development since it targets such as a small set of revisions on Rails Edge and it will be out of date shortly if it isn’t already.

Helpful Command Line Tools

2007-11-23T00:00:00-05:00

Here’s a post about some of the command line tools (both standard on *nix systems and homegrown) which make software development just a little more efficient.

The homegrown tools may only work on OSX. This is because unix utilities on OSX often have different options to do the same thing (such as sed’s -E on OSX and -r in Ubuntu).

find

find is a unix utility for searching files in a directory hierarchy. find is a powerful tool that comes with a lot of options. Some are more common then others.

Here are the options I use frequently:

-name pattern - this will match filenames against the supplied pattern
-exec command argument \; - runs the specified command against each file matched

# Using -name to find all files or directories which match the pattern “*.rhtml” find ./ -name “*.rhtml”

# Using -exec to find all rhtml files whose file contents match “Continuous Thinking” find ./ -name “*.rhtml” -exec grep -Hn “Continuous Thinking” {} \;

For development the -name option doesn’t help me much as TextMate’s Apple-Tab is far superior and faster to use, but editors like TextMate lack the efficiency of doing a -name and -exec combination from the command line. Sure TextMate has Apple-Shift-F to search file contents project wide, but what about all of those files you want to exclude (like log files), plugins (vendor/plugins) or the whole rails directory (vendor/rails).

TextMate doees give you the ability to exclude certain files (or directories) from your TextMate project, but it removes all references to them from within your TextMate project. This feature will speed up Apple-Shift-F searches, but sometimes you want to include those other files or directories.

The find command given the -name and -exec options can be a pain to type out. So I’ve written a helper script called findit.

findit

findit is a wrapper around find. It’s simple and fast. It’s usage is simple:

findit where pattern

Maybe you’re looking for that view template which contains the text ‘Fuzzy Bear’:

zdennis@elijah:> findit app/views/ Fuzzy Bear
app/views//bears/new.rhtml:26:      <label for="fuzzy_bear">Fuzzy Bear</label>

Notice how you don’t have to use quotations around the arguments Fuzzy Bear. Everything after the first argument is treated as a part of the pattern.

Another example may be that you’re looking for where alias_method_chain is defined in rails. Well let’s look:

zdennis@elijah:> findit vendor/rails/ def alias_method_chain
vendor/rails//activesupport/lib/active_support/core_ext/module/aliasing.rb:23:  def alias_method_chain(target, feature)

So the power of findit comes from the fact that it’s easy to use and it handles most common occurrences of what a developer like me looks for such as the filenames that matched, the line numbers it matched on and a printout of those matching lines.

findit also ignores all .svn, CVS, .log, .project, .dylib and .o files. Of course you can change this though by editing the findit.

Download

Give it a try click “here”:http://www.continuousthinking.com/assets/2007/11/23/findit.rb

findfile

findfile is similar to findit except that it only matches on filename patterns. The usage is still the same:

findfile where pattern

Recently I had some issues with installing PostgreSQL from “ports”:http://www.macports.org and there was a patch to the Portfile for the PostgreSQL port to get it to install correctly. I had no idea where the Portfile was so I let findfile to the work:

findfile /opt/local/var/macports Portfile | grep -i postgres

Download

Give it a try click “here”:http://www.continuousthinking.com/assets/2007/11/23/findfile.rb

locate | slocate

locate (and by extension slocate) may be one of the most under utilized unix tools in the mac world.

locate is used to find files by searching a database. Since it uses a database of file paths it is almost instantaneous whereas tools like find can take a while depending on how much files you have in a directory structure.

slocate can be thought of as “secure locate”. For more information consult this “doc”:http://linux.about.com/library/cmd/blcmdl1_slocate.htm

Here’s the same example from findfile but this time using locate:

locate Portfile | grep postgres
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql7/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql80/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql80-doc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql80-server/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql81/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql81-doc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql81-server/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql82/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql82-doc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql82-server/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql83/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql83-doc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql83-server/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql_autodoc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/java/postgresql-jdbc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-postgresql-exception/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-postgresql-greentrunk/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-postgresql-layout/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-postgresql-pqueue/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-postgresql-proboscis/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/ruby/rb-postgres/Portfile

locate loses its usefulness when it’s database is out of date. Fortunately it’s easy to add it to cron. Here’s what I have in my /etc/crontab file to have slocate update it’s database every night at midnight:

0 0 * * * root /opt/local/bin/slocate -u

locate comes with Leopard, and slocate comes with ports. I have my locate aliased to actually run slocate. They use different databases so pick one and use it or alias one command over the other like I have. There’s not much of a point to have both slocate and locate.

If you decide to give slocate a try you can install easily by running:

sudo port install slocate

whatsmyip

whatsmyip is a script I use in my “screen configuration”:http://www.continuousthinking.com/2007/1/7/screenrc-configuration so I can always tell what my local ip address is. ifconfig output is pain enough to look at and I try to avoid it at all costs:

zdennis@elijah:> whatsmyip 
en1: 10.0.4.100 en2: 10.37.129.2 en3: 10.211.55.2

Download

Give it a shot, click “here”:http://www.continuousthinking.com/assets/2007/11/23/whatsmyip.rb

OSX Leopard mysql gem for ruby

2007-11-21T00:00:00-05:00

If you install mysql from ports then you can install the mysql ruby bindings in the following manner:

sudo su

ARCHFLAGS='-arch i386' gem install -r mysql -- \
   --with-mysql-include=/opt/local/include/mysql5/mysql/ \
   --with-mysql-lib=/opt/local/lib/mysql5/mysql/

If you don’t use ports then check out “http://nullcreations.net/entry/installing-ruby-mysql-gem-in-osx-10-5-leopard”:http://nullcreations.net/entry/installing-ruby-mysql-gem-in-osx-10-5-leopard

OSX Leopard sqlite-ruby and sqlite2

2007-11-18T00:00:00-05:00

OSX Leopard comes with sqlite3 and sqlite3-ruby pre-installed. If you need to install the sqlite-ruby gem for sqlite2 you’ll find that it fails to install by itself.

Here’s what you’ll probably get:

zdennis@elijah:>sudo gem install sqlite-ruby
Select which gem to install for your platform (universal-darwin9.0)
 1. sqlite-ruby 2.2.3 (ruby)
 2. sqlite-ruby 2.2.3 (mswin32)
 3. sqlite-ruby 2.2.2 (ruby)
 4. sqlite-ruby 2.2.2 (mswin32)
 5. Skip this gem
 6. Cancel installation
> 1
Building native extensions.  This could take a while...
ERROR:  While executing gem ... (Gem::Installer::ExtensionBuildError)
    ERROR: Failed to build gem native extension.

ruby extconf.rb install sqlite-ruby
checking for main() in -lsqlite... no
checking for sqlite.h... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
        --with-sqlite-dir
        --without-sqlite-dir
        --with-sqlite-include
        --without-sqlite-include=${sqlite-dir}/include
        --with-sqlite-lib
        --without-sqlite-lib=${sqlite-dir}/lib
        --with-sqlitelib
        --without-sqlitelib


Gem files will remain installed in /Library/Ruby/Gems/1.8/gems/sqlite-ruby-2.2.3 for inspection.
Results logged to /Library/Ruby/Gems/1.8/gems/sqlite-ruby-2.2.3/ext/gem_make.out

If you become root and attempt to do the install it will also fail.

Installing with sqlite2 from ports

I have “MacPorts”:http://www.macports.org/ installed and you’ll want to make sure sqlite2 is installed:

zdennis@elijah: sudo port install sqlite2

Now to install sqlite-ruby:

# run the command as root
zdennis@elijah: sudo su

sh-3.2# ARCHFLAGS="-arch i386"  gem install sqlite-ruby -- --with-sqlite-include=/opt/local/include/ --with-sqlite-lib=/opt/local/lib/

Select which gem to install for your platform (universal-darwin9.0)
 1. sqlite-ruby 2.2.3 (ruby)
 2. sqlite-ruby 2.2.3 (mswin32)
 3. sqlite-ruby 2.2.2 (ruby)
 4. sqlite-ruby 2.2.2 (mswin32)
 5. Skip this gem
 6. Cancel installation
> 1
Building native extensions.  This could take a while...
Successfully installed sqlite-ruby-2.2.3
Installing ri documentation for sqlite-ruby-2.2.3...
Installing RDoc documentation for sqlite-ruby-2.2.3...

That’s it. Now it works:

zdennis@elijah: irb
irb(main):001:0> require 'rubygems'
=> false
irb(main):002:0> require 'sqlite'
=> true
irb(main):003:0>

Food Service and Craftsmanship

2007-11-15T00:00:00-05:00

I wonder if restaurants and fast food places could learn from the craftsmanship model. Today at lunch I went to KFC and they screwed up my order. I’m somewhat of a regular at the local KFC by the office and the person who took my order I believe is new.

It hit me that this happens all of the time, regardless of it being a fast food place or a normal sit down restaurant. I’m a rather picky eater and have been dubbed “Sally” from “How Harry Met Sally”:http://www.imdb.com/title/tt0098635. Sally and I both share the “picky” part of our eating habits.

My thought is that people who are new on the job in the restaurant world often screw up orders. And after seeing “Waiting”:http://www.imdb.com/title/tt0348333 I’m even inclined to think that my orders get jacked up on purpose.

But keeping my hopes and dreams in mind (no sprinkled parsley on my mashed potatoes please) as it pertains to servers wanting to do a good job and take price in their work I think they should put more emphasis on the craftsmanship model. No junior servers or order takers w/o a senior standing by.

At least perhaps then I’ll get what I ordered.

test/unit story runner

2007-11-14T00:00:00-05:00

As you may know rspec has integrated RBehave into itself. In the rspec world it’s more recently been called Story Runner.

Some background links:

“Introducing RBehave”:http://dannorth.net/2007/06/introducing-rbehave
“User stories with RSpec’s Story Runner”:http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runner
“Story Runner in Plain English”:http://blog.davidchelimsky.net/articles/2007/10/21/story-runner-in-plain-english
“Plain Text Stories: Part III”:http://blog.davidchelimsky.net/articles/2007/10/25/plain-text-stories-part-iii

Story Runner itself hasn’t officially been released and while it has been becoming more polished myself and a colleague (Drew Colthorp) wanted higher level acceptance tests in my ruby projects (including rails).

Story Runner also has two implementations (or at least APIs). The latest is the plain text Story Runner. This requires that for every story you have at least two files. One that is plain text for the customer to write and one that is a “matcher” file developers write. Information on this can be found “here”:http://blog.davidchelimsky.net/articles/2007/10/25/plain-text-stories-part-iii

The older version of Story Runner uses the original RBehave style syntax. Lots of blocks and lots of argument passing. There is also a bug in this implementation regarding sharing blocks given to story parts. But enough about rspec, this post is on a lighter weight and simpler Story Runner.

So here’s to a working and testing implementation of a Story Runner in test/unit.

test/unit Story Runner

To start, an example:

class EventCreationTest < ActionController::IntegrationTest
  fixtures :all

  Story "As a user I should be able to create an event so that others can RSVP and attend."

  Scenario "Creating an event unsuccessfully with insufficient input" do
    Given :a_user_at_the_create_an_event_page
    When :they_submit_the_create_an_event_form_with_insufficient_input
    Then :they_will_see_an_error_explanation
    And :they_will_see_the_create_an_event_page
  end 

   #
   # HELPERS
   #
   def a_user_at_the_create_an_event_page
       # ....
   end

   def submit_the_create_an_event_form_with_insufficient_input
       # ...
   end

   def see_an_error_explanation
       # ...
   end

   def see_the_create_an_event_page
      # ...
   end
end

Some important things to note on the structure:

the Story takes a description of the story. It does NOT take a block.
multiple Story’s can be defined in a file although I prefer organizing them in separate files
all Scenario’s which follow a Story will belong to that Story.
the Scenario takes a description of the particular scenario or acceptance test for a story. It does take a block.
inside of a Scenario you describe the story parts. These are Given, When, Then, and And.

Some important things to note on the story part descriptions:

Each story part can take a string or symbol description
helper method calls are generated off from the story part description

Helper method calls are generated by taking the full story part description and then removing the leading word until a helper method is found. If there are no helper methods found then an exception is raised.

Some important things to note on the goals of this implementation:

in theory customers write acceptance tests
in practice developers translate customer desires into acceptance tests
ideally the acceptance tests should be high level enough that a customer can read/write them
since developers will most likely write these acceptance tests this implementation should allow for developer shortcuts
this should just work on a test/unit project, projects updating to this shouldn’t have to convert or make changes up front to existing code

script/plugin install

script/plugin install \
  http://continuous.rubyforge.org/svn/tags/test_unit_story_runner-0.1.0

Final Thoughts

Before I forget you can do argument passing as well on story parts:

Scenario "a user successfully making a guess in the game" do
  Given :a_user_at_the_game
  When :they_make_a_guess_of, 20_000
  Then :they_will_win_a_car
end

This feature is there, but I would advocate only using it when it helps the readability of your tests.

This is a stable (tested) experiment. It’s a thin wrapper around the test/unit framework and it works with any Test::Unit::TestCase. The price to pay for higher level acceptance tests is now next to nothing so give it a shot.

This is the creation of a trip to Madison, WI where Drew and I had a chance to discuss and vent about the state of acceptance tests in Rails projects specifically. A few days later we had this implementation, and about a month later you’ve got this post…

Suggestions and feedbacks are warmly welcomed.

Happy rubying!

rspec_on_rails render_and_receive_matcher

2007-11-14T00:00:00-05:00

Earlier today my pair and I saw a repetitious pattern in our view specs when we were using helpers. It looked similar to the following:

it "displays foo" do
   template.should_receive(:bar).with(@foo).and_return(%|<p id='bar'></p>|)
   render_it
   response.should have_tag("p#bar")
end

The repetition was in the three lines:

setup a simple should receive and return
make the call to render
verify the response had the returned element

Tonight I spent some time spiking a way to cure this repetition. I’m a bigger fan of verbosity in specs over DRYness, but I think my exploration gives us something good. The above example now looks like:

it "displays foo" do
   during_render do
     template.should receive_and_render(:bar).with(@foo)
   end
end

The receive_and_render method sets up a shouldreceive_ expectation on the template. For completeness there is also a stub_and_render method. As you might guess this method sets up a stub! on the template.

This doesn’t just work on the template object. It works on any object, but you should probably only use it on objects that show up in the view.

script/plugin install

script/plugin install \
    http://continuous.rubyforge.org/svn/trunk/rspec/matchers/rspec_on_rails_render_and_receive

Final Thoughts

This in an experiment. As I am learning more about the spirit of rspec and it’s organization there are a few things I want to change with this. Right now this is implemented as a matcher which doesn’t feel quite right, but time will tell. So in the meantime… Happy rubying!

superclass_delegating ...

2007-11-02T00:00:00-04:00

superclass delegates

Rails edge revision 8056 introduces some great new reader/writer/accessor methods:

superclass_delegating_reader
superclass_delegating_writer
superclass_delegating_accessor

This is best explained with an example:

class Foo
  superclass_delegating_accessor :name
end
class Bar < Foo ; end
class Baz < Foo ; end

Foo.name = "Mr. T"          # => "Mr. T"
Foo.name                    # => "Mr. T"
Bar.name                    # => "Mr. T"
Baz.name                    # => "Mr. T"

Bar.name = "Junkyard Dawg"  # => "Junkyard Dawg"
Foo.name                    # => "Mr. T"
Bar.name                    # => "Junkyard Dawg"
Baz.name                    # => "Mr. T"

Foo.name = "Million $$ Man" # => "Million $$ Man"
Foo.name                    # => "Million $$ Man"
Bar.name                    # => "Junkyard Dawg"
Baz.name                    # => "Million $$ Man"

There are two reasons why this rocks:

you can independently override something on a subclass without screwing up the the value for the inheritance hierarchy (which is the problem with cattr_accessor/reader/writer methods).
you can update the superclass’s value and the subclasses which don’t set their specify their own value will receive the update (which is the problem with class_inheritable_accessor/reader/writer methods).

Ruby's String#split gets explained

2007-11-01T00:00:00-04:00

I’ve posted an article on how Ruby’s String#split method works over at Atomic Spin.

“http://spin.atomicobject.com/2007/11/01/ruby-stringsplit/”:http://spin.atomicobject.com/2007/11/01/ruby-stringsplit/

Not that String#split is all that exciting, but I enjoyed exploring how it’s implementation truly works, and I’m glad I can share with with everyone who comes across this blog.

Happy rubying!

Plain Text Story Running

2007-10-23T00:00:00-04:00

David Chelimsky announced yesterday the first implementation of Plain Text Stories.

“http://blog.davidchelimsky.net/articles/2007/10/22/plain-text-stories-on-rails”:http://blog.davidchelimsky.net/articles/2007/10/22/plain-text-stories-on-rails

Story Runner - constructive ideas

2007-10-16T00:00:00-04:00

Yesterday I ranted on some criticisms that I have of RSpec’s Story Runner. This post will try to follow up the criticisms which an implementation I like.

The code we started with yesterday is:

Story "View Home Page", %{
  As a user I want to view my home page
  So that I can get a birds eye view of the system
}, :type => RailsStory do

  Scenario "Latest published article" do
    Given "an author named", "Zach" do |name|
       @user = User.create! :name => name
    end

    When "he visits the home page", "/" do |path|
       get path
    end

    Then "he should see the latest article published front and center" do
       # ... do something to see the article shows as expeted
    end
  end

end

Here is a version of this that I like, and is implemented in test/unit story runner (which has yet to make its public debut):

Story "As a user I want to view my home page so that I can get a birds eye view of the system"

Scenario "Latest published article" do
  Given "an author"
  When "he visits the home page"
  Then "he will see the latest article published front and center"
end

Story Description

It gets rid of the unnecessary description and :type parameters. It leaves only the story itself.

Story Do/End Blocks

It removes them. They are not needed. They provide unnecessary grouping which hurts readability for the customer.

Scenario Do/End Blocks

These are kept. These are the one area where I feel making a visual grouping is important for the customer and the developer. All Scenario’s will be attached to the Story declaration which precedes it.

Argument Passing

I removed the arguments from the original example. They weren’t providing value to my tests. I do believe argument passing is valuable but it must be in a way that adds value to the test. For example in a game I am ok with the 500_000 below:

  Scenario "Becoming the top scorer" do
    Given "a player"
    When "he makes a guess of", 500_000
    Then "he will see himself as the number one scorer"
  end

It seems that a lot of cases where arbitrary arguments are passed can be updated to make their descriptions more meaningful. It can do this by describing what is under test based on what may influence the test. Typically a user’s name doesn’t do this. So rather then:

Given "a user named Zach"

I’d rather see why “Zach” is special. Maybe he’s an admin:

Given "an administrator"

The Process

I haven’t explained yet how test/unit story runner is implemented so bare with me. When you add a new Story or Scenario it looks like the example posted above.

When you change or update an existing Story or Scenario it still looks like the example posted above. There is no embedded code, or horrendous blocks following every declaration (just the Scenario one!).

Reusable Code

Here’s where a high level overview of test/unit story runner comes to fruition. It takes a story part’s (Given/When/Then/And) description and turns that into a helper method using a simple mapping process.

take the description and downcase it
strip out all punctuation
then replace spaces with underscores
look for the method name
if it exists, execute it, otherwise strip the first word and repeat

So every story description maps to a method. And these methods can be included at the bottom of your story file or in a shared helper file (or both!).

Here’s a few example mappings:

Given "an administrator" # => an_administrator
When "he clicks the big button" # => clicks_the_big_button
Then "he will see a picture"  # => see_a_picture
And "he will see another button!" # => see_another_button

def an_administrator
  # ...
end

def clicks_the_big_button
  # ...
end

def see_a_picture
  # ...
end

def see_another_button
  # ...
end

What I like about this is that it is easy for developers to map a description to a method, and it separates the implementation of a Story from it’s definition. This allows the customers to work consistently to add and updates Story’s, as well as the same for developers.

Final Thoughts

One thing that lacks right now in the test/unit story runner is a way to mark Story’s as pending. I think this can be accomplished though by capitalizing the Story, Scenario or any of the story parts.

Story "Logging in"

SCENARIO "User with good credentials" do
  # this whole scenario is pending regardless of whats in it
  Given "..."
  When "..."
end

Scenario "User with bad credentials" do
  # this whole scenario is executed
end


STORY "Logging out" # marks the whole story as pending 

Scenario "logged in user" do
  # this will be marked as pending because of the story it belongs to
end

There has been recent discussion on the RSpec mailing list about this:

“http://rubyforge.org/pipermail/rspec-users/2007-October/003690.html”:http://rubyforge.org/pipermail/rspec-users/2007-October/003690.html
“http://rubyforge.org/pipermail/rspec-users/2007-October/003704.html”:http://rubyforge.org/pipermail/rspec-users/2007-October/003704.html

It seems that everyone is in agreement that the holy grail is a pure plain text file. There are drawbacks with this though that are currently being evaluated.

Pat Maddox has came up with a nice alternative to my above suggestion called SpecMatcher’s. It looks promising to the users of rspec though that Story Runner will turn into something truly beneficial to developers and customers alike.

Story Runner - constructive criticism

2007-10-15T00:00:00-04:00

If you keep up with RSpec development you’ll know that RBehave has been integrated into RSpec and is known as the “Story” Runner. This is a unfolding of current thoughts and criticism, I apologize for any lack of explanation, but I need to do a quick braindump.

I love the concept of Story Runner, but I do not like it’s current syntax. Below are the criticism’s for why. First though the code example I’ll use to discuss the Story syntax.

Story "View Home Page", %{
  As a user I want to view my home page
  So that I can get a birds eye view of the system
}, :type => RailsStory do

  Scenario "Latest published article" do
    Given "an author named", "Zach" do |name|
       @user = User.create! :name => name
    end

    When "he visits the home page", "/" do |path|
       get path
    end

    Then "he should see the latest article published front and center" do
       # ... do something to see the article shows as expeted
    end
  end

end

Story Description

The story description is hideous. It requires a description, and then the story description, and then a type flag (at least for Rails projects). The Story itself should contain it’s actual story description. The pseudo description set in the first parameter and the :type flag should be able to be dropped. Right now these two things do not add value, but decrease customer readability.

Story Do/End Blocks

Everything is organized with do/end blocks. While I love the closure capabilities of ruby I am not a big fan of overusing blocks in Story files themselves. I would much rather drop the do/end blocks unless they provide needed clarity.

I’d like to remove the do/end block on Story because it the definition of the file format should read.. “All Scenarios belong to the preceding Story declaration”. Which to me is still just as readable.

Scenario Do/End Blocks

These should stay put. To me these are essential for providing clarity amongst your acceptance tests which scenario they are pertaining to.

Story Part Do/End Blocks

Story part (Given, When, Then, And) do/end blocks need to go away completely. They allow for developers to embed code directly into the high level story, which immediately reduces the readability from both a customer and developer perspective.

It has been mentioned that you can use editors code folding techniques to hide the code, but as pointed out on the rspec mailing list I don’t want my customer to have to use a code editor to read the acceptance tests.

Argument Passing

After every story part in the above example you have the ability to pass in arguments to the do/end block. When this adds value it makes sense to do this, but when it is a trivial piece of information it doesn’t seem to add any value. Instead it detracts readability.

It detracts readability by creating new tokens a customer has to visually parse, both in the argument list for the story part and also the argument list for the do/end block. It also makes data that may not be important seem important because they are singled out as their own arguments.

Argument passing should be used to add value to the story part with something that helps identify a behavior that is going to happen that your test is going to depend on. Usually this is not the user’s name or the root path (”/”) of a site, although in some cases it may be.

The Process Is Flawed

The ideal process is having a customer write and own the stories and the acceptance tests. As these change the customer should be responsible for updating them. The developers should be responsible for implementing them.

Given the above format once you add embedded code to a Story part you immediately reduce the readability from a customer’s perspective to own and maintain that Story and it’s acceptance tests should it change in the future. Also if a customer changes a Story should he/she be responsible for deleting the developers implementation of last acceptance test?

So the process is flawed. We shouldn’t have a format which doesn’t provide consistency to both the developer and the customer. So we need to tweak the Story format to enable a format which is consistent at both creation and change/update time of a Story and/or it’s acceptance tests.

Reusable Code

Embedding code inside a Story part renders it non-reusable. So to combat this you create a helper method and call from within the Story part’s do/end block. So now you have a nice clean description and with a do/end block wrapping a helper method, like below:

Given "a user logged into the system", "Joe" do |name|
  @user = User.create! name
  login_as @user
end

I see this and I want to refactor this. Clearly the description well named. I should be able to rely on a similarly well named helper method to handle creating or finding a user and logging that user in. If I do this then why do I need a do/end block (besides the fact of RSpec using it to trigger a pending Story)?

It seems so far that you don’t need a do/end block. It doesn’t add value. It takes away value.

alias_method, what would you expect?

2007-09-21T00:00:00-04:00

What would you expect would happen with the following code?

class A
  def a ; puts 'a' ; end
end

class B < A
  def a_with_b ; puts 'b'; a_without_b ; end
  alias_method_chain :a, :b
end

class A
  def a_with_c ; puts 'c'; a_without_c ; end
  alias_method_chain :a, :c
end

A.new.a
B.new.a

Now run it.

Let me know if it meets your expectations.

form_test_helper 1.1.0 released!

2007-09-20T00:00:00-04:00

form_test_helper 1.1.0 has been released!

This update is for those who develop on Rails Edge. A recent update to Rails broke break how the tests run with form_test_helper.

So if you are on an Rails Edge revision of 7421 or higher then you should use form_test_helper trunk. The plugin repository URL is:

“http://form-test-helper.googlecode.com/svn/form_test_helper”:http://form-test-helper.googlecode.com/svn/form_test_helper

If you are on Rails Edge, but you’re not up to revision 7421 yet you will want to install and use form_test_helper-1.1.0. The plugin repository URL is:

“http://form-test-helper.googlecode.com/svn/tags/form_test_helper-1.1.0”:http://form-test-helper.googlecode.com/svn/tags/form_test_helper-1.1.0

If you are using Rails 1.2.x or a Rails Edge revision that is less then 6474 then you should use form_test_helper-1.0.0. The plugin repository URL is:

“http://form-test-helper.googlecode.com/svn/tags/form_test_helper-1.0.0”:http://form-test-helper.googlecode.com/svn/tags/form_test_helper-1.0.0

For more information please refer to the form_test_helper project page:

“http://code.google.com/p/form-test-helper/”:http://code.google.com/p/form-test-helper/

Update Feed Subscription

2007-09-18T00:00:00-04:00

In case you happen to subscribe to this feed, please re-subscribe using the new feedburner URL.

feed://feeds.feedburner.com/continuousthinking

Thanks

Not Testing Views, How Jay Tests

2007-09-18T00:00:00-04:00

Jay Fields mentions in his post “How We Test”:http://blog.jayfields.com/2007/09/rails-how-we-test.html that he doesn’t write view tests.

View tests, in my experience, aren’t necessary unless you are putting logic in your view. I prefer to keep the logic out of the view and ignore view tests entirely.

I agree with a lot of what Jay blogs about, but this I don’t think I do, but it’s hard to say because he didn’t post any context or information about his statement.

Although Jay has a point in keeping logic out of the view, view tests themselves are still an important aspect of testing rails applications. Here’s why I think you should test your views:

Integration tests should be lightweight and very high level (customer readable or as close as you can get to it)

If a customer wants information A, B and C to be on page foo then you need prove that A, B and C show up. Here you can use a view test! (An integration test would test going through the application, but view tests would test the details to make sure the right information is on the page.)

Controller/functional tests should not test anything view related, so this requires a separate view test

View tests may help keep your views organized and manageable

View tests encourage the use of using helper objects/methods because you don’t want to write tests to test logic in the view. If you don’t test your views it’s easier to put logic in there.

The thing that makes me want to keep view tests are that, if a customer says I want to see this information, then it is my job to prove that it show’s up. There are three options for this:

Put the testing of that information being displayed in your controller test. (this is painful!)

Put the testing of that information being displayed in your integration test. (bloats your high level customer readable integration test. I want to avoid this bloat at this level!)

Put the testing of that information in it’s own isolated view test (my preference of choice!)

YMMV based on your project. It may also vary based on your team setup and chemistry. On my current project the developers work with a HTML/CSS Builder to build the whole site. Several times we (our developers and HTML/CSS builder) have made pieces of information or links disappear when updating views. Without our view tests we wouldn’t have caught it as early on.

I have heard an argument against view testing which has to do with the cost of writing and maintaining view tests against the cost of letting developers, testers or customers find them. The argument is that “it’s cheaper to not write a view test and let someone find a bug rather then to write a view test and fix something before someone finds a bug”.

I disagree with this because I think there is a lot of risk involved with letting precious information slip through the cracks. Web applications these days often involve a lot of views and a lot of information. The whole point of test automation is to not require that someone remembers to test everything. Automated view tests are faster, they never forget a piece of important information to look for and they don’t require that anyone remembers everything that needs to be displayed.

There are ways to test your views which makes them feel unnecessary, brittle and painful, but this can be avoided. You can have easy, meaningful view tests which add value to your project for your development team and for your customer.

Mike Clark's - How Would You Test This

2007-09-18T00:00:00-04:00

Below is my rspec answer to Mike Clark’s recent post “How Would You Test This”:http://www.clarkware.com/cgi/blosxom/2007/09/08#TestingControllers which challenges people to post their own solution to how you’d test his MenuitemsController.

One thing Mike doesn’t mention about the frustration that people have with testing controllers is testing that testing controllers requires you to test your view associated with it (unless you are only redirecting).

There are ways around testing views, but most install a custom hack or installing a third party plugin or framework like rspec, Test::Rails or view_test.

Since Mike didn’t include any views in his original post I haven’t provided any tests for them in this post.

require File.dirname(__FILE__) + '/../spec_helper'

def do_post(attributes)
  post :create, :menu_item => attributes
end

describe MenuItemsController, 'Creating a new menu item (success)' do

  before do
    attributes = {'name' => "Enchilada", 'price' => 4.99}
    @menu_item = mock_model(MenuItem)
    MenuItem.should_receive(:new).with(attributes).once.and_return(@menu_item)
    @menu_item.should_receive(:save).with().once.and_return(true)

    do_post attributes
  end

  it 'redirects to index' do
    response.should redirect_to(menu_items_url)
  end

  it 'assigns @menu_item' do
    assigns[:menu_item].should be(@menu_item)
  end

  it 'sets the flash notice' do
    flash[:notice].should_not be(nil)    
  end
end

describe MenuItemsController, 'Creating a new menu item (failure)' do

  before do
    attributes = {'name' => "Enchilada", 'price' => 4.99}
    @menu_item = mock_model(MenuItem)
    MenuItem.should_receive(:new).with(attributes).once.and_return(@menu_item)
    @menu_item.should_receive(:save).with().once.and_return(false)

    do_post attributes
  end

  it 'renders new template on failed save' do
    response.should be_success
    response.should render_template('new')
  end

  it "assigns @menu_item" do
    assigns[:menu_item].should be(@menu_item)
  end

  it "not set the flash notice" do
    flash[:notice].should be(nil)      
  end

end

Updating Rails Edge From 7292 to 7513

2007-09-18T00:00:00-04:00

I just migrated our project from Rails Edge revision 7292 to Rails Edge revision 7513. Some of the things I ran into:

Extracted Plugins

The following common plugins have been extracted and must now be installed as plugins from http://svn.rubyonrails.org/rails/plugins/PLUGIN_NAME:

acts_as_list
acts_as_nested_set
acts_as_tree
in_place_editing

Broken Functionality

The acts_as_modified plugin has been broken with changeset “[7513]”:http://dev.rubyonrails.org/changeset/7315 .

Has Many Associations Change

Changeset “[7511]”:http://dev.rubyonrails.org/changeset/7511 made it so you can no longer call create on a has many association when the parent is a new record. To get around this you need to ensure your parent is saved first.

That’s all! Enjoy!

rspec's mocking framework is staying put

2007-09-05T00:00:00-04:00

On the rspec-users mailing list there’s been talk recently of removing the built-in mocking framework. The idea was that it offered nothing that the existing mocking frameworks like Mocha, Flexmock or Hardmock didn’t already offer.

The other day David Chelimsky announced in this “post”:http://www.nabble.com/Re%3A-Deprecating-the-mocking-framework–p12463749.html that it will be keeping rspec’s mocking framework for the foreseeable future.

form_test_helper on edge

2007-09-01T00:00:00-04:00

Well I’ve joined the Google Code project for “form_test_helper”:http://code.google.com/p/form-test-helper/ . So form_test_helper will now work with Rails Edge, trunk revisions 6764 all the way up to 7393 (todays latest commit).

If you are using Rails 1.2.x or a Rails Edge revision less then 6764 then please use the 1.0.0 tag for form_test_helper, otherwise use what we consider form_test_helper trunk.

Installing for Rails Edge greater than or equal to 6764

script/plugin install http://form-test-helper.googlecode.com/svn/form_test_helper

Installing for Rails Edge less than 6764

script/plugin install http://form-test-helper.googlecode.com/svn/tags/form_test_helper-1.0.0

I am going to put these notes on the project home page as soon as I get permissions to make that update if “Jason”:http://www.jasongarber.com/ doesn’t make the change himself.

Enjoy form_test_helper on Edge!

form_test_helper for Rails Edge

2007-08-26T00:00:00-04:00

The wonderful plugin “form_test_helper”:http://code.google.com/p/form-test-helper/ written by “Jason Garber”:http://www.jasongarber.com/ hasn’t worked with Rails Edge since this past spring. I monkey patched it to get it to work a few months ago, and tonight I submitted a patch which fixes form_test_helper with Rails Edge. The plugin has been tested to work with Rails Edge revisions 6764 to 7358.

The patch can be found “here”:http://www.continuousthinking.com/form_test_helper_edge.diff

http://www.continuousthinking.com/form_test_helper_edge.diff

I talked to Jason in July about submitting a patch and I believe it’ll be accepted and a new form_test_helper released, but in case you don’t want to wait please apply the patch yourself. You can do this by opening a terminal and following the below steps:

$> cd RAILS_ROOT/vendor/plugins
$> wget http://www.continuousthinking.com/form_test_helper_edge.diff
$> cd form_test_helper
$> patch -p0 < ../form_test_helper_edge.diff

# you should now be able to run rake
$> rake
(in /Users/zdennis/source/opensource_projects/blah/vendor/plugins/form_...
/opt/local/bin/ruby -Ilib:lib "/opt/local/lib/ruby/gems/1.8/...
Loaded suite /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake...
Started
.................................................................
Finished in 0.372041 seconds.

65 tests, 293 assertions, 0 failures, 0 errors

Enjoy!

view_test 0.10.0 released

2007-08-25T00:00:00-04:00

view_test 0.10.0 has been released. Install it now:

script/plugin install http://continuous.rubyforge.org/svn/tags/view_test-0.10.0

“David Chelimsky”:http://blog.davidchelimsky.net/ asked me the other day if view_test allowed you to write view tests without having created your controller yet. I said yes naively. Last night I fired up the MacBook Pro and looked over my specs to see if I had tested that case (I thought I did), but I didn’t so I wrote a failing spec and then implemented it.

You can now create a view test and create the correct app/views/products directory structure and have it work without having to have a ProductsController in existance. (Examples are in “Behaviors”:http://behaviors.rubyforge.org format)

class ProductsShowTest < Rails::ViewTest::TestCase

  should "display hello world when rendering products/show.html.erb" do
     render :file => "products/show"
     assert_select 'hello world'
  end

end

So, David, I didn’t lie on purpose, and hopefully this release will redeem my answer! Enjoy!

Rails, introducing view_tests

2007-08-24T00:00:00-04:00

view_test is a lightweight extension to test/unit specific to Ruby on Rails which gives you rspec like controller and view tests. It contains two key components:

Improved functional tests
View tests

If you’re developing a rails app and you’re using test/unit then view_test gives you the ability to achieve a clean separation between functional tests and view tests. view_test is a direct influence of rspec and Test::Rails by zenspider.

Improved functional tests

Functional tests are now simpler. You no longer have to set things up so your test can successfully render it’s template. Instead you can make an expectation against an explicit render call or you can render the template that would have been rendered.

Here’s a few examples: (all code examples are written with “behaviors”:http://behaviors.rubyforge.org syntax which is another extension to test/unit to give it nicer syntax):

Expecting an implicit call to the default template

# in the controller you have the action 'show'
# Note: there is no call to render
def show
end

# in the test
class ProductsControllerTest < Rails::ControllerTest::TestCase

  should "render the show template on #show" do
    expect_render :action => "show"
    get :show
  end

# ....

Expecting an explicit call to another action

# in the controller you have the action 'show'
# Note: the explicit call to render
def show
  render :action => "index"
end

# Note: the explicit call to render
def list
  render :template => "blah"
end

# in the test 
class ProductsControllerTest < Rails::ControllerTest::TestCase

  should "render the show template on #show" do
    expect_render :action => "index"
    get :show
  end

  should "render the template blah on #list" do
    expect_render :template => "blah"
    get :list
  end

# ...

Stubbing the call to render and checking the rendered template

# in the controller you have the action #show
# Note: the explicit call to render
def show
  render :action => "index"
end

# in the test
class ProductsTest < Rails::ControllerTest::TestCase

  should "render the products/index template on #show" do
    stub_render
    get :show
    assert_template "index"
  end

The benefit of this is that you can successfully use mocks in your functional tests without having to try to compensate for things in your views. Your functional tests now only really test your controllers.

Migrating to Improved Functional Tests

When you use stub_render or expect_render in an individual test only that test will be updated to use the stub or render. This allows you to migrate one test at a time to improved functional tests without having to change everything at one.

View Tests

View tests are isolated unit tests for your views. One important feature of this is that you can expect or stub “render :partial” calls inside of a view. In fact you have to expect or stub them. There is no way to allow a “render :partial” to pass through to the real view. This is a implementation decision to enforce the convention of keeping a 1:1 test to template ratio.

Here’s an example:

class ScoreboardsPartialViewTest < Rails::ViewTest::TestCase
  # this is optional if you name your test case well
  controller_name 'scoreboards' 

  def setup
	# assign view level instance variables
    assigns[:scores] = [
      stub(:player => "joe", :score => 100),
      stub(:player => "bob", :score => 200)
    ]
  end

  should "format points with commas"
    expect_helper(:format_points).with(100).returns("joe's points")
    expect_helper(:format_points).with(200).returns("bob's points")

    render :partial => "scoreboard/_scoreboard"

    assert_select '#scoreboard .points', /joe's points/, "didn't call the helper"
    assert_select '#scoreboard .points', /bob's points/, "didn't call the helper"
  end

end

Downloading / Installing

You can install view_tests as a rails plugin. It has been tested with Rails Edge REVISIONS 7155 and later.

script/plugin install http://continuous.rubyforge.org/svn/tags/view_test-0.9.0

You can also download the tgz file from “rubyforge”:http://continuous.rubyforge.org .

Dependencies

view_test relies on:

Mocha 0.5.2 or higher - “rubyforge page”:http://mocha.rubyforge.org”
Metaid 1.0 or higher - “rubyforge page”:http://rubyforge.org/frs/?groupd_id=1272 and “_why’s metaid page”:http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html

Disclaimer

The goal of view_test isn’t to stop people from migrating to rspec or Test::Rails. It exists to allow people who have decided to use test/unit on new code or existing code to achieve a better level of testing in Rails.

Agile Conference 2007, Day Four

2007-08-19T00:00:00-04:00

Day four was my last day at this year’s Agile Conference. I didn’t attend last year’s, but from what I gather from some coworkers I went with the schedule shifted a half day forward. In the morning I spent my time eating breakfast and listening to Uncle Bob and several other folks from Object Mentor carry on some interesting discussions. (This was not an official talk, I just happened to be eating where the OM team was hanging out.)

So on the fourth day I spent time at the following sessions:

Creating Change One “Tic Tac” at a Time - “Alistair Cockburn”:http://alistair.cockburn.us/ and “Jeffery Fredericks”:http://www.agitar.com/
Refactoring Databases : Evolutionary Database Design - “Scott Ambler”:http://www.ambysoft.com/ and “Pramod Sadalage”:http://databaserefactoring.com/PramodSadalage.html

Creating Change One “Tic Tac” at a Time

This session was very group oriented. Unlike some of the other sessions which involved roleplaying this session put about five to eight people at a table. The first goal was to discuss problem or obstacle that was overcome moving to some form of Agile practices. It could be a little win or a big win, but it had to be a win (Alistair and Jeffrey weren’t interested in the failures).

Each group had to vote and decide on a winning “win” for their group. Each “win” had to presented to the whole session audience. After everyone had heard all of the stories people were able to self-organize and go to the tables that had the “win” that they were interested in. Each table then had to discuss and list out the challenges and what led to them being overcome.

At the end Alistair and Jeffrey spent about 10 minutes going through some slides explaining the benefits of small tic tac changes rather then huge sweeping changes. They showed a nice graph which I haven’t been to find online yet. If anyone has a reference of it please send me a link.

What the graph portrayed was the effects of making changes and then benefiting from those changes. The idea is that for every change you make productivity goes down, and you stay in a dip and as you master the change your productivity goes back up and eventually surpasses your previous level of productivity. So this means:

the bigger the change, the deeper the dip and the longer the dip drags out
the smaller the change, the shallower the dip and the shorter you are able to surpass your old level of productivity

If you make a lot of small changes (one “tic tac”) at a time you end resulting getting a much higher level productivity in a shorter timeframe assuming each of your changes leads to better practices and higher efficiency. If you try to do too much you will be less productive then before and for a longer period of time. Alistair and Jeffrey believe that this is what causes so many teams who claim “Agile” failed for them.

Refactoring Databases : Evolutionary Database Design

Scott walked through the slides and Pramod did the real time demos. The “evolutionary” part of the discussion and probably their book, “Refactoring Database - Evolutionary Database Design”:http://databaserefactoring.com/ is more revolutionary to hard core DBAs who live a sheltered technical life which leads me to assume people from corporate america.

At the a technical level the presentation focused on:

incremental changes to the schema
versioning your database (rollback / roll forward features)
testing your data (verifying your setup data)
testing your interaction with the data (triggers, stored procedures, etc.)
use source control
developers should be able to check out and run a simple script which builds a development database for them

At a higher level the presentation focused on:

developers pairing with DBAs and vise versa
realizing that DBA is a different role, but not necessarily a different position
doing better database practices all around
communicating with the rest of the world

Scott has a lot of bundled up frustration with a developers, DBAs and “agile” people. He thinks there is too much of a barrier between developers and DBAs. He doesn’t like it when developers go around the DBAs because DBAs move too slow, although he recognizes that sometimes that’s just what you have to do. He seems somewhat ticked off about how “agile” developers focus on the practices during the application development, but that they slack when it comes to the database development. And this is going to get its own paragraph…

I agree with Scott when it comes to application development and database development. I think that too many developers consider the database a big dumb hash. At 40,000 feet I can agree with that analogy, but when you get closer to the ground the analogy stops working (with the current limitations of databases and disk storage mediums that we have today). Premature optimization is evil yes, but understanding SQL and how databases work isn’t premature optimization. Sometimes things that can be done in some simple SQL is more readable and faster to implement and test then the equivalent ruby or java code. Especially things which can be done with simple joins.

Back to the presentation…. Scott and Pramod are pushing for the same type of practices being used at the database level that are being used at the application level. Databases are archaic. SQL is archaic. It’s not elegant, but it’s still a very important piece to a lot of applications. Use the database when you should and test the hell out of what you’re doing. If you’re not using “Ruby on Rails”:http://www.rubyonrails.com one of the best advantages of its framework is its builtin database migration tools. Thee are also plugins like “Migration Test Helper”:http://spin.atomicobject.com/2007/02/27/migration-testing-in-rails/ which takes your testing of the database that much further.

After Refactoring Databases

I spent some time in the “Dungeon” where people were helping on creating a Rails web application for a non-profit group. I had some great discussion with “Paul Pagel”:http://www.8thlight.com/main/bios/paul from “8th Light”:http://www.8thlight.com and also “David Chelimsky”:http://blog.davidchelimsky.net/ who is one of developers for “RSpec”:http://rspec.rubyforge.org

Agile Conference 2007, Day Two

2007-08-15T00:00:00-04:00

Agile Conference 2007, Day Two

For the second day of Agile Conference 2007 I hit two sessions:

Agile Developer Practices for Dynamic Languages (“Paul King”:www.asert.com)
The Crystal Methods (“Alistair Cockburn”:http://alistair.cockburn.us/)

Agile Developer Practices for Dynamic Languages

This first session was alright. The presentation revolves around the presenter being well grounded in Java and its related technologies, and recently he has been moving towards dynamic languages. As he and his team are moving towards dynamic languages (he prefers “Groovy”:http://groovy.codehaus.org/ and his non-present co-presenter preferred “Ruby”:http://www.ruby-lang.org) they are realizing that a lot of design patterns, techniques and requirements of statically typed languages aren’t required, or are implemented completely different in dynamic languages.

The talk really focuses on showing people who understand things in java, but not in dynamic languages, that in fact you can do the same things (or in some cases you don’t need to do it at all) in a different way. He walked through things like:

dynamic builders (think “Markaby”:http://redhanded.hobix.com/inspect/markabyForRails.html or “Haml”:http://haml.hamptoncatlin.com/ in ruby) vs. using builder objects in java
you don’t really need factories like you do in java
delegation is much simpler then it is in java
DSLs are easier to write then in is in java
brief examples of “meta-programming” and that it sucks to do in java

Three people in the session couldn’t get over the fact that with dynamic languages you lose the ability to have auto-completion in your editors with the same level of granularity that you get with Java code and editors like IntelliJ or Eclipse. If their ability to productively program comes down to auto-completion or they think that auto-completion will hinder their ability to effectively solve problems I think there are bigger problems on there team.

The Crystal Methods

“Alistair Cockburn”:http://alistair.cockburn.us/is a great speaker. He started out by focusing on how he believes people learn. According to Alistair people learn in three states: learn (shu), collect (ha), and invent/blend (ri). These stages directly correlate to the level of understanding and experience someone has in a particular area.

People start in the “shu” stage and learn with a clear set of instructions and/or rules. Next people move to the “ha” stage where they are able to apply the rules and they are able to understand that the rules aren’t necessarily giving them the best results. Here they start to experiment with edge/exception cases and they apply different rules. In the “ri” stage the person has moved beyond the instructions/rules.

Moving on from how people learn, Alistair presents Crystal as a collection of methodologies, and he believes that different methodologies are better suited for different types of contexts and number of people. Hence there are Crystal Clear, Crystal Yellow, Crystal Orange and Crystal Red.

He points out that Crystal methodologies won’t tell you how-to do something, they will merely tell you the properties that you need to have to be successful, and as a team he expects you to find the best ways to get there, although he does assert that certain key techniques (like Reflection, high visibility, etc) are key to implement Crystal methods.

Alistair’s background for coming up with Crystal Clear started back in the early 90s when he started traveling worldwide to to talk to different team about their projects. Through his years of experience he concludes that Crystal is made up of the good things that were common among all of them.

Alistair also believes that methodologies can be classified by a given genetic code. Here is the code for Crystal:

Mindset
Design priorities
Project priorities
Design principles
Key techniques
Samples

He also focuses on the seven properties of a successful project:

Frequent delivery
Reflective improvement
Close communication
Personal Safety
Focus
Easy access to expert users
Technical Environment ** automated unit tests ** automated acceptance tests ** frequent commits and system integration

Crystal itself is based on the first three of these properties.

In the past I had read the Crystal Clear book and I have even implemented many of the properties and techniques in it so the session wasn’t completely new material, but I feel I was able to take away more from the session from having prior knowledge then if I were to come in with a blank slate.

Agile Conference 2007, Day Three

2007-08-15T00:00:00-04:00

Today involved four sessions:

Clean Code 1: Cleaning Up A Mess - “Uncle Bob”:http://www.objectmentor.com/
Clean Code 2: Craftsmanship and Professionalism - “Uncle Bob”:http://www.objectmentor.com/
Open Source Testing Tools to Support Agile Development/Testing - “Paul King”:http://www.asert.com/
Learning to Say “No” - “Stacia Broderick”:http://www.scrumalliance.org/profiles/32-stacia-broderick , “Michele Sliger”:http://theagileblog.net/2_authors/michele_sliger/

Clean Code 1: Cleaning Up A Mess

Uncle Bob delivered a great talk on cleaning up a mess. He asserts that developers want to go fast and that to the only way to go fast is to go well.

He uses a “dinner” analogy to clarify his points on messy code. The dinner analogy starts with a question, “What is the fastest way to prepare dinner?”. Regardless of ordering out or preparing it yourself, the fastest way is not do the dishes or cleanup afterwards. However, if you don’t do the dishes you are directly impeding your ability to quickly prepare dinner the next time.

There is much more to his talk, but you should really see it to experience it. I believe he’ll be at the “GLSEC”:http://www.glsec.org/ conference in west Michigan later this fall.

Clean Code 2: Craftsmanship and Professionalism

Uncle Bob’s second talk was more impressive to me then the first because it hit home a lot principles and practices that he views are required to be a professional developer and an agile developer.

While I’m not going to list all of them I would like to list a few:

Short iterations (short feedback loop)
Avoiding “solve everything” architectures (he calls them Turgid Viscous Architectures)
No Grand Redesign
Incremental improvement
TDD (minimal professionalism)
Code Coverage (strive for 100%)
Apprenticeship
and many more…

I really enjoyed one of his quotes on Grand Redesign:

Programmers like to make a huge mess and then bitch about it so they can make the next huge mess.

I haven’t read Uncle Bob’s books yet (real name Robert C. Martin) but that is going to change especially after I saw good reviews on a “blog post”:http://www.artima.com/weblogs/viewpost.jsp?thread=32026 from Guido van Rossum back in 2004.

Open Source Testing Tools to Support Agile Development/Testing

This talk just didn’t do it for me. It focused on every Java related. I’ve moved on from Java development, and what is happening in the Java world just isn’t very exciting (yes Groovy is nice). The presenter seems to know Java and everything associated with it very well. I think I just wasn’t the right type of audience.

It would have been nice if the talk was titled “Open Source Testing Tools to Support Java Development”.

Learning to Say “No”

This talk just didn’t do it for me either. The presenters did a lot of interaction and role playing with the audience on topics like saying “no” to your boss if he asks you to work late tonight, or this weekend. They gave useful ways to “preserve your self” and also work with whomever may be asking you to sacrifice personal time for their needs.

The techniques they show are useful, but most of it is common sense. This talk seems directly applicable to people who feel stuck in a corporate job who get taken advantage of, but don’t know the correct avenue to start breaking the cycle while keeping their job.

Agile Conference 2007, Day One

2007-08-14T00:00:00-04:00

Today’s the first day (or half day) of Agile Conference 2007. We’re into the wee hours of the early evening (8:46pm) and the social celebration (aka Ice Breaker) is underway. Whoever said geeks were asocial beings haven’t been to an Ice Breaker (or they didn’t serve enough beer).

I went to two sessions today.

The First Session

The first was on test driving the development of client/server application which was essentially a Shout/Echo server. It was written in ruby and the first half of the presentation was ok (I didn’t stay for the second half). The presenter drove the audience through a live coding session of implementing the server using test/unit.

I didn’t take too much away from this presentation. I know ruby, I know ruby’s socket library, I do TDD and I know test/unit very well. It was a good presentation overall and would be a good introduction for someone who perhaps wanted to learn ruby and/or TDD, or wanted to sharpen their skills on ruby’s socket library.

The Second Session

The second session was on Agile Myths. It was a collaborative and interactive session. The two presenters presented a list of 20 agile myths that they had heard while consulting. They also added in myths from the audience. After a quick high level overview of each myth they took out large manila folders and listed out each myth, and the audience formed groups of about five and every group picked a few myths.

The focus of each group was to either support the myth or debunk the myth, and they had to backup their claim. At the end each myth and supporting claim was discussed as a whole audience. This led to some very interesting discussions. After hearing opposing arguments on alot of the myths and claims I feel more confident being a true practitioner of agile methods.

Some of the myths that were debunked were:

Agile is all or nothing
Agile doesn’t produce documentation
Agile doesn’t commit to a deadline
Agile developers are just Cowboy programmers who don’t want to follow a process.

What agile myths have you heard?

extract_options bang

2007-07-25T00:00:00-04:00

I’ve seen and used a lot of slightly different mechanisms for grabbing an options hash from a passed in set of arguments. Today the Rails core team has added a helper to the Array class as part of Rails’ core extensions. It’s a simple addition, but one that I like.

With Options

arr = [ 1, 2, 3, { :validate => true } ]
options = arr.extract_options! 

# arr = [ 1, 2, 3 ]
# options => {:validate=>true}

Without Options

arr = [ 1, 2, 3 ]
options = arr.extract_options! 

# arr = [ 1, 2, 3 ]
# options => {}

DHH has removed the method extractoptions_from_args_ which used to exist in ActiveRecord::Base in favor of extract_options!. Using extract_options will be preferred over doing things like:

args.last.is_a?(Hash) ? args.pop : {}

Actual Code Example 1 - ActionView::Helpers::FormBuilder

def fields_for(object_name, *args, &block)
  raise ArgumentError, "Missing block" unless block_given?
  options = args.extract_options!
  object  = args.first

  builder = options[:builder] || ActionView::Base.default_form_builder
  yield builder.new(object_name, object, self, options, block)
end

Again it’s on Edge as of today, so if you don’t live on the Edge you won’t see it for awhile unless you implement itself for your project. Doing so may keep things tidy as you continue your projects rails development.

Model Conductor Controller Presentation

2007-07-21T00:00:00-04:00

Tonight at the “Grand Rapids BarCamp”:http://barcamp.org/BarCampGrandRapids2 they had open slots for presentations, so I threw up a quick presentation on the Model Conductor Controller ( “MCC”:http://mcc.rubyforge.org ) pattern being developed in Rails.

Although MCC isn’t officially released yet (available via svn) its goals, ideals and implementation help simplify complex interactions in Rails-based web applications by allowing objects to focus on a single responsibility.

Here is a link to the Quicktime movie. “MCC_BarCamp_GrandRapids_07-21-07.mov”:http://www.continuousthinking.com/assets/2007/7/21/MCC_BarCamp_GrandRapids_07-21-07.mov

I’ll be updating this presentation and fine tuning it some more for the “August Grand Rapids Ruby Users Group meeting”:http://gr-ruby.org/2007/7/19/august-meeting.

ActiveRecord::Extensions 0.7.0 Released!

2007-07-21T00:00:00-04:00

ActiveRecord::Extensions 0.7.0 is released! Thanks to Michael Flester and Gabe da Silveira for the patches they submitted!

Updates include:

Oracle support for better finders (but regexps only work with Oracle 10 or higher) and import (Michael Flester)
created_at/updated_at timestamps are now implemented with import functionality if they exist on the tables (Zach Dennis/Michael Flester)
fixed padding issue with MySQL by increasing the byte buffer size to 8 bytes. (thanks to Gabe da Silveira)

To install as a gem you can run:

gem install ar-extensions

To update a previously installed gem you can run:

gem update ar-extensions

To install as a script/plugin you can run:

script/plugin install http://arext.rubyforge.org/svn/tags/ar-extensions-0.7.0

To see information on the usage of ar-extensions please refer to the “arext page”:http://www.continuousthinking.com/tags/arext or refer to the “RDOC documentation”:http://www.continuousthinking.com/tags/arext/rdoc/index.html

Enjoy!

For questions, comments please feel free to email me, zach dot dennis at gmail dot com or by submitting to “rubyforge project page”:http://rubyforge.org/projects/arext for arext.

The Importance Of Winning (it all wrong)

2007-06-30T00:00:00-04:00

Winning it all wrong is getting it all wrong as it pertains to the concept of winning.

At an early age most people learn about winning. Whether it’s early in life playing games, taking toys from other children or socializing in general.

Toddlers often scream “mine” and take the toy of another child. If they get away with it they’ve started the process of learning the importance of winning.

Children whose parents emphasize the “must win” mentality during sports learn the process of winning at every event.

Teenagers who undermine and manipulate others succumb to the importance of winning as they climb the social ladder.

When you think of the “winning” mentality, sports will probably come to mind first, but the importance of winning is prevalent in the “software development” community.

Have you worked someone who’s always right (even when they’re wrong)?
Have you worked with someone who checks in lots of code during the late night or multi-day-no-sleep coding sessions?
Have you worked with someone who doesn’t want pair programming or review of their code (or they don’t listen to the feedback)?

If you’ve experienced one of the above then you’ve experienced the “winning” mentality in the world of software development. It can be frustrating to work with.

The best attitude to combat this is one of humility and modesty. There is a time to be right and to stand your ground and there is a time to shut up, listen and learn.

The best group action to actively employ against the wrong concept of winning is accountability. Accountability requires humility and modesty. Practices and actions that happen continually become habits.

The true value of winning is not to win in every argument, debate or discussion. It isn’t to ensure that “my” idea is the one that is always employed. Achieving victory triumphantly over everyone else in all circumstances is a short-sighted vision of winning. Unfortunately it’s the concept that alot of people seem to know.

A more worthy concept of winning is broader scoped:

winning involves learning when there are things to be learned
winning involves teaching when there are things to be taught
winning involves discipline when doing the right takes longer then the shortcut
winning involves patience when there is time to be spent
winning involves honesty when the alternative seems more appealing
winning involves knowing when to let the other person win
winning involves strengthening others when others need to be built up
winning involves listening because no one knows it all
winning involves humility because humbleness allows you teach more, learn more and ultimately do more

acts_as_comparable 1.2 released

2007-06-30T00:00:00-04:00

acts_as_comparable 1.2 has been released with a minor update. This includes a fix to handling additional options passed into the declarative acts_as_comparable call.

For example with acts_as_comparable 1.1:

# this work
class Model < ActiveRecord::Base
  acts_as_comparable
end

# the options passed in are ignored.
class Model < ActiveRecord::Base
  acts_as_comparable :except => [:id, :name]
end

Now in 1.2 this is fixed so you can pass the following options make calls like:

acts_as_comparable
acts_as_comparable :only=>\[:first_name, :last_name\]
acts_as_comparable :except => \[:id, :name\]

Installing as a RubyGem

gem install -r acts_as_comparable

Installing as a Plugin

Installing from a version

script/plugin install \
  http://rails.lotswholetime.com/svn/acts_as_comparable/tags/acts_as_comparable-1.2

Rails Edge Updates (06/28/2007)

2007-06-28T00:00:00-04:00

Here are some updates for life on Rails Edge. Kudos to the rails-team!

Additions

Added new date helpers: #since, #ago, #beginning_of_day, #end_of_day - “8575”:http://dev.rubyonrails.org/ticket/8575

» Date.today.beginning_of_day => Mon Jun 04 00:00:00 -0500 2007

» Date.today.end_of_day => Mon Jun 04 23:59:59 -0500 2007

» Date.today.since(4.hours) => Mon Jun 04 04:00:00 -0500 2007

»Date.today + 4.hours => Mon Jun 04 04:00:00 -0500 2007

Removals

findall_ and findfirst_ have been removed entirely

Rake Tasks

db:create - has been added to create the database for the current RAILS_ENV
db:create:all - has been added to create databases for each environment
db:version - displays the version number of your database (as shown in script/about)
routes - has been added to display route information

Command Line

script/generate can now take the ”–skip-migrations” options when generating resources

Testing

Test::Unit::TestCase.fixture_path is now a class inheritable attribute in Edge (has been there for a while now). This allows you have different paths to fixtures based on your test case without overwriting other TestCase subclass fixture paths.
collection fixtures have been added. You can now do things like:

bob, steve = users(:bob, :steve)

Enjoy!

Rails Patch 8750

2007-06-26T00:00:00-04:00

Rails ticket “8750”:http://dev.rubyonrails.org/ticket/8750 fixes a issue which led myself and a few others to believe that assert_select_rjs was broken.

Ideally I would expect the following calls and assertions to go together:

page['myid'].replace '<div>content</div>'

assert_select_rjs :replace, 'myid'

However this isn’t the case. Since you are using the page[id] syntax Rails considers this a “chained” selector so you have to use the following assertion:

assert_select_rjs :chained_replace, 'myid'

Ritarded, I know. So “ticket 8750”:http://dev.rubyonrails.org/ticket/8750 fixes this and you can now use the more intuitive syntax as demonstrated below:

page['myid'].replace '<div>content</div>'
assert_select_rjs :replace, 'myid'

page['myid'].replace_html '<div>content</div>'
assert_select_rjs :replace_html, 'myid'

basecamp goes openid

2007-06-26T00:00:00-04:00

Basecamp releases its support for “OpenID”:http://openid.net/ . The official basecamp release notes can be found “here”:http://productblog.37signals.com/products/2007/06/basecamp-gets-o.html .

A long time ago “Brandon Keepers”:http://www.opensoul.org was telling me about OpenId but I didn’t really have a use for it (lack of support by web sites and applications that I use). One of my biggest pet peeves with Basecamp has been that you have to have multiple logins for multiple projects, but now you can have one.

My favorite feature is the new project navigation toolbar. In the below screenshot you can see the three projects that I’ve converted to OpenID show up.

Although there are a few OpenID providers out there I decided to go with “My OpenID”:http://www.myopenid.com . In seven minutes I had my OpenID up and my basecamp projects converted over.

For those of you who may be interested in running your own OpenID server you can… “Run your own identify server”:http://openid.net/wiki/index.php/Run_your_own_identity_server gives you some resources to show you how.

Kudos to basecamp for putting this in place, it is so far the best added feature since basecamp has been released IMO.

Instance Variables In Ruby

2007-06-23T00:00:00-04:00

Instance variables are the heart of an object’s encapuslated data. In “ruby”:http://www.ruby-lang.org all instance variables are hidden behind the walls of an object although their exists ways to access and modify those instance variables from afar.

This post will go review:

Creating instance variables
Nil - The default value of an instance variable
Accessing instance variables
Checking for instance variable existence
Breaking encapsulation
Injecting instance variables into other objects
Using named parameters to set instance variables

Creating instance variables

Instance variables are created with a single @ symbol.

(copy and paste code example)

# the instance variable @a is initialized to 5
class A
  def initialize
     @a = 5
  end
end

Nil - The default value of an instance variable

Unlike methods that don’t exist trying to reference a uninitialized instance variable will return nil rather then raise an exception.

@b # => nil
@b.nil? # => true
@b = 5 # => 5
@b.nil? # => false

Accessing instance variables

In most languages to access an instance variable you have to write your own get/set methods.

class Person
  def name=(name)
    @name = name
  end

  def name
    @name
  end
end
joe = Person.new # => #<Person:0x524f04>
joe.name = "joe" # => "joe"
joe.name # => "joe"

In Ruby you can bypass this using builtin the accessor methods:

“attr_accessor”:http://www.ruby-doc.org/core/classes/Module.html#M001704 - this writes a getter and a setter for you
“attr_writer”:http://www.ruby-doc.org/core/classes/Module.html#M001703 - this writes a writer for you
“attr_reader”:http://www.ruby-doc.org/core/classes/Module.html#M001702 - this writes a getter for you

Here’s a modified example from the above Person class:

sally = Person.new # => #<Person:0x4e3a90>
sally.name = "sally" # => "sally"
sally.name # => "sally"

If we had used “attr_writer”:http://www.ruby-doc.org/core/classes/Module.html#M001703 we would have gotten the “name=” method for free, but we wouldn’t have been able to call “name”. Likewise, if we had used the “attr_reader”:http://www.ruby-doc.org/core/classes/Module.html#M001702 we would have been able to access Sally’s “name” but we would have never been able to set it with “name=”.

Checking for instance variable existence

Sometimes it’s useful to be able to know whether an instance variable has been defined or not. With an instance variable having the default value of nil it’s hard to rely on “@varname” to determine if nil was the defined value.

So we rely on:

“instance_variable_defined?”:http://www.ruby-doc.org/core/classes/Object.html#M000367 - can be used to determine whether an instance variable has been defined
“instance_variables”:http://www.ruby-doc.org/core/classes/Object.html#M000364 - an array of instance variables for a given object

class Person attr_accessor :name end joe = Person.new # => #Person:0x1109f40 joe.instance_variable_defined?(“@name”) # => false joe.instance_variables # => [] joe.name = “joe” # => “joe” joe.instance_variable_defined?(“@name”) # => true joe.instance_variables # => [“@name”]

In the above example notice that “@name” did not exist until we assigned it a value.

Breaking encapsulation

You can break object encapsulation in ruby pretty easily due to it’s dynamic and highly reflective nature. I’ve seen people instance_eval to get and set the value of an instance variable, but there is a more proper way to break encapsulation.

“instance_variable_get”:http://www.ruby-doc.org/core/classes/Object.html#M000365
“instance_variable_set”:http://www.ruby-doc.org/core/classes/Object.html#M000366

joe.instance_variable_set :@name, ‘joe’ # => “joe” joe.instance_variable_get :@name # => “joe”

This is also about 70x faster then using instance_eval.

Injecting instance variables into other objects

Frameworks like “Ruby on Rails”:http://www.rubyonrails.org use the power of ruby to do magical things. One of those things is injecting variables into a given object, such as in the case of controllers and views. You can do this with what we’ve just seen with “instance_variable_set” and “instance_variable_get”.

class BlankSlate ; end
class ValueHolder   
  def initialize
    @a, @b, @c = 1, 2, 3
  end
end


slate = BlankSlate.new # => #<BlankSlate:0x101a224>
slate.instance_variables # => \[\]
values = ValueHolder.new # => #<ValueHolder:0x1014ef0 @c=3, @b=2, @a=1>
values.instance_variables # => ["@c", "@b", "@a"]


values.instance_variables.each do |varname| 
  slate.instance_variable_set(varname, values.instance_variable_get(varname))
end # => ["@c", "@b", "@a"]
slate.instance_variables # => ["@c", "@b", "@a"]

Using named parameters to set instance variables

A common thing to do in JavaScript is to use object literals when calling functions to ease simulate named arguments. In Ruby the most common construct you’ll see is people passing hashes into a method call.

Person.new :first_name => "Joe", :last_name => "Gee", :middle_initial => "B"

The calling syntax looks great, but what you have to do in the constructor for Person is quite hideous:

class Person
  def initialize(options)
    @first_name = options[:first_name]
    @last_name = options[:last_name]
    @middle_initial = options[:middle_initial]
  end
end

Given this trivial example calling “options[key]” may not be so annoying, but if you had a more complex example where you were using dependency injection it can get a little cumbersome.

We can start to scratch this itch by automatically setting instance variables to their passed in named parameters:

class Person
  def initialize(options)
    options.each_pair do |key,value|
       instance_variable_set "@#{key}", value
    end
  end
end

This approach has its own set of issues though, but given a good set of tests you could confidently use this approach. You could also add code to verify the arguments being passed in.

Another solution which would give you closer syntax that you get in JavaScript is forwarding method calls to hash keys:

module ActAsNamedParameters
  def act_as_named_parameters(hsh)
    parent = class <<hsh ; self; end
    hsh.each_key do |key|
      parent.send(:define_method, key) { hsh\[key\] }
    end
  end
end

class Person
  include ActAsNamedParameters

  def initialize(attributes)
    act_as_named_parameters attributes
    @first_name = attributes.first_name
    @middle_initial = attributes.middle_initial
    @last_name = attributes.last_name
  end
end

Person.new :first_name => "Joe", :last_name => "Gee", :middle_initial => "B"

Here we’re invoking a helper module to do the dirty work for us. A downside here is that the helper module modifies the hash we pass it. In most cases side effects to method calls is undesired, but if you are using simple hashes for argument passing that may not be a large concern for you.

Even though there are lots of ways you can accomplish different ways to treat arguments in ruby I’ll leave you with one last small refactoring to our previous example. Rather then rely on a helper module that we must invoke we could always add the accessors to the Hash itself.

class Hash 
  def method_missing(method, *args)
    if self[method.to_sym] and args.empty?
      self[method.to_sym]
    else
      super
    end
  end
end

class Person
  def initialize(attributes)
    @first_name = attributes.first_name
    @middle_initial = attributes.middle_initial
    @last_name = attributes.last_name
  end
end

Person.new :first_name => "Joe", :last_name => "Gee", :middle_initial => "B"

Programmer, Developer

2007-06-13T00:00:00-04:00

I used to think that I was a software developer based on the sole fact that I was paid to write code, no matter how crappy it was. Over the past few years I’ve realized that I was no more of a software developer as a guy who picks up trash on a construction site is a contractor.

I’ve noticed that alot of so called “developers” fall into the same camp that I was in. I’ve mentally made a distinction between a Programmer and a Developer. This is much more generic dictinction of different types of coders then say an Apprentice, Journeyman or Craftsman is.

A Programmer is someone who codes. They don’t necessarily take into consideration a whole lot of things outside of fact of getting the job done.

A Developer is someone who codes with consideration. They consider:

coding quality and best practices
program design with natural decomposition
testability, automated testing, manual testing
readibility
maintainability
refactoring
code performance (when its time to evaluate performance)
teamwork
responsibility to their customer and to their fellow teammate(s)

These definitions are influenced from object-oriented thinking and agile software development practices. You may completely disagree with them entirely. I’ve raised the bar for how I develop software. If it’s less for you then we just have different expectations of what makes a Developer. I’m ok with that. But, is your customer?

Ever since I started writing code I recognized that my potential was where I wanted to be. I could see the potential of what I could become and what I could accomplish. With this I had a genuine thirst for knowledge and I was eager to quench it. I’ve spent thousands of dollars and have read tens of thousands of pages from technical books. I’ve spent countless hours coding.

I spent too long of a time in the Programmer camp. I could have been much farther ahead early on given a few degrees change in direction.

So what was my problem? My problem had to do with the following goals when I first started:

knowledge of multiple programming languages
knowledge of different types of development: web apps, cgi, standalone,daemons, libraries
coding speed
all previous items as soon as possible

I wanted to know as much as possible in as little time as possible and I wanted to be able to produce results as fast as possible. A worthy goal, but the goals fell short of what is required of a software Developer.

When you learn as much as possible in the shortest amount of time with no regard to how you take that information and you end up learning only a small amount of what was there to be learned.

When you apply what you’ve learned as fast as possible with no regard to any of the aforementioned Developer “considerations” you end up making habits out of bad practices. And it will take alot of time and discipline to break them.

Developers take on a personal responsibility for the software they write. They don’t just value the end result. They value the entire process leading up to the end result and then they value the end result.

While Programmers continually apply bad practices, Developers provide consistently good practices. From what I’ve seen it goes like the following:

while Programmers avoid testing to produce faster short-term, Developers continue test to produce faster and more consistently long-term
while Programmers copy and paste over and over again to produce faster short-term, Developers refactor and create re-usable components to produce less buggy software, faster, long-term
while Programmers avoid the use of decomposition because everything can be inlined to produce faster short-term, Developers use decomposition to provide a solution which makes more natural sense (this leads to more manageable, maintainable, readable and scalable code for the long-term)
while Programmers often code by themselves to produce faster short-term, Developers value the input and ideas generated from other people to produce better and more correct solutions (this often leads to avoiding common mistakes from not correctly understanding the problem description and solution requirements)
while Programmers often code 12+ hours several days in a row to produce more in a shorter amount of time, Developers work a sustainable-pace to produce more correct code in a shorter amount of time (when you’re brain is tired and you are tired you make mistakes, if you keep on coding you just dig yourself a bigger hole. Staying fresh with a sustainable pace minimizes this.)
while Programmers commit to unrealistic customer expectations immediately, Developers communicate why the expectation is unrealistic and work with the customer on determining a realistic set of features in a realistic amount of time.

This isn’t to say that Programmers are evil coders. The term “Programmer” encompasses alot of people. These people might be:

inexperienced,
irresponsible,
lacking discipline,
or just bad programmers

Every coder starts out in the Programmer camp. Whether they evolve to the Developer camp is simply up to them. Who determines whether they’re out of the Programmer camp? They do.

Responsible Programmers quickly evolve into effective Developers because responsibility requires discipline and discipline does the right thing in any circumstance. The sooner you take responsibility for your craft as a software developer, the sooner you’ll enjoy the benefits of being a Developer.

Planning In Software Development

2007-06-13T00:00:00-04:00

I was just reading the post “Quit Planning”:http://daniel.collectiveidea.com/blog/2007/6/4/quit-planning over at Daniel Morrison’s “blog”:http://daniel.collectiveidea.com/blog/

His comments seem to be down so I felt the need to post my thoughts here. In response to Daniel’s article I think he has it mostly right on the money. Although I would like to change the term “planning” in his article to “upfront planning”.

Dwight D. Eisenhower may have said it best:

Plans are useless, but planning is indispensable.

Unfortunately most definitions of planning involve the upfront and systematic approach rather then focusing on the continuous process which develops daily.

Developing in short iterations allows for short bursts of incremental progress which when used in combination with a quick feedback loop between the developer and the customer gives the customer an upper hand in defining and planning the needs of his software to meet the needs of his business.

It works because the process of planning is continuous and incorporates change, while upfront planning to produce a plan ignores that change will occur, which as Daniel points out, will occur.

If you remove the process of planning (which I don’t think Daniel is suggesting) then you remove a key component to any software endeavor, agile or not. Agile strives to reduce and minimize the concept of upfront planning in favor of iterative planning.

As pointed out on the Agile Journal in a “post”:http://www.agilejournal.com/content/view/200/9/

Planning isn’t bad

What I believe Daniel is focusing on in his post is that:

… the details [should] emerge throughout implementation.

High Jumping Projects

2007-05-29T00:00:00-04:00

I spent this past memorial weekend in South Haven with much of my wife’s extended, extended family. Many of the relatives were individuals that my wife has either never met or has not seen in years. My father-in-law was eager to ask me what I’ve been up to lately for work. After about two minutes he stopped me and asked me to wait to finish because he wanted me to share the news with everyone else.

A few minutes later he was introducing me to the extended family and asking me to describe my past few months of events and work. After sharing the past few months of life and work with everyone it seems that the Q&A period started.

One of the questions sticks in my mind from one of my extended family uncles.

“When you work on your projects do you have hundreds of other developers working with you?”

I was pleasantly surprised and eager to answer his question. The answer of course is that no, I have never been on a project of more then six developers. He didn’t seem entirely satisfied so he asked another set of questions.

“When are you expected to be done with the current project you’re on? Could you be done sooner with more people?”

This leads me to the example of The High Jump principle as written in “Talent Is Never Enough”:http://www.amazon.com/Talent-Never-Enough-Discover-Choices/dp/0785214038 . The principle is such that…

Winning the high jump requires one person who can jump seven feet, not seven people who can jump one foot.

Some software projects may indeed take large amounts of people (hopefully the large amounts of people are divided into small manageable teams). So far the projects I’ve been apart of have more in common with The High Jump principle.

“Brook’s Law”:http://en.wikipedia.org/wiki/Brooks’_law seems to say it best:

“Adding people to a late software project makes it later.”

As “John Maxwell”:http://en.wikipedia.org/wiki/John_C._Maxwell states in his book “Talent Is Never Enough”:http://www.amazon.com/Talent-Never-Enough-Discover-Choices/dp/0785214038 , “More isn’t always better, and some things are best done by an individual.” Or in the case of most software projects, done by a small team.

Rails patch 8277

2007-05-06T00:00:00-04:00

The synchronize functionality released in “ActiveRecord::Extensions 0.6.0”:http://www.continuousthinking.com/2007/5/6/activerecord-extensions-0-6-0-released should probably go in core. So I submitted a “patch”:http://dev.rubyonrails.org/ticket/8277

My reasoning is that is ActiveRecord::Base#reload already works on a per instance level, why not allow it work on a class level where the class can efficiently handle reloads on multiple instances at once.

The benefit of the class level reload is that you can do one query to the database regardless of how many instances you have rather then having to perform one query per instance.

If you’re in favor of the patch please encourage it gets accepted.

ActiveRecord::Extensions 0.6.0 released

2007-05-06T00:00:00-04:00

ActiveRecord::Extensions 0.6.0 is released! You can install it via RubyGems:

gem install ar-extensions

What’s New?

0 includes:

support for arrays when using the Hash arguments and the ‘_contains’ suffix.
a synchronize method which acts like ActiveRecord::Base#reload, but it works on multiple instances. The benefit being that it makes one query to reload all instances rather then one query per instance
a bug fix for URI encoded strings when using find with ActiveRecord objects

Examples

# synchronize example
post = BlogPost.find_by_author_name( 'zdennis' )
columns = [ :author_name, :title ]
values = [ [ 'yoda', 'test post' ] ]
BlogPost.import columns, values, :synchronize=>[ post ]
post.author_name # => 'yoda'

# using synchronize option with import
posts = BlogPost.find(:all)
BlogPost.import( columns, values, :synchronize=>posts)

# using arrays with the _contains suffix
BlogPost.find( 
  :all,  
  :conditions=>{ :author_name_contains=>[ 'ab', 'oc', 'ed' ] } )

Questions, Comments

zach dot dennis at gmail dot com

less shift f

2007-04-24T00:00:00-04:00

If you use a combination of piping to files and using the tail command with the -f option and/or using grep you may want to try just sticking with the less command and using the Shift-f to tell less to continue waiting for input from the file.

Before Shift-f you’ll see your normal output as shown by less:

Apr 23 20:24:39 elijah com.apple.SecurityServer: Succeeded authorizing

You can tell if its working by looking at the last line of your less output.

Apr 23 20:24:39 elijah com.apple.SecurityServer: Succeeded authorizing 
Waiting for data... (interrupt to abort)

Now less is going to get updated whenever the file you are lessing has more data appended to it. Now hit / and start looking for whatever it is you want to find.

Another way to use one tool rather then three.

Introducing acts_as_comparable

2007-04-21T00:00:00-04:00

Mark VanHolstyn and Zach Dennis kick out another ActiveRecord plugin. The previous plugin “ActiveRecord::Extensions”:http://www.continuousthinking.com/tags/arext now has a smaller, helpful cousin. This plugin has been in use for over a year but not released until tonight!

“acts_as_comparable” is plugin for ActiveRecord which allows you to easily compare and determine the differences between two ActiveRecord models.

class Person 
  acts_as_comparable :only=>\[:first_name, :last_name\]
end

joe = Person.new :first_name=>"Joe", :last_name=>"Smith"
joseph = Person.new :first_name => "Joseph", :last_name=>"Smith"

joe.same?( joseph ) # => false
joe.different?( joseph ) # => true

joe.differences( joseph ) # => {:first_name=>\["Joe", "Joseph"\]}

The usage in the above example shows the only option, but this also works with no options, the except option and also the attrsmap_ option. See it’s ruby doc for more information.

Installing as a RubyGem

gem install -r acts_as_comparable

Installing as a Plugin

Installing from a version

script/plugin install http://rails.lotswholetime.com/svn/acts_as_comparable/tags/acts_as_comparable-1.1

Communication is essential

2007-04-12T00:00:00-04:00

Models [charts, diagrams, stories, graphs, etc] are valuable only to the extent that they facilitate communication among human beings. – David West

Communication is the most essential part of a project. Sometimes the artifacts that are generated to help facilitate communication end up hindering it. If the target audience can’t understand the artifacts you’re presenting them with chances are you need to stop trying to explain it to them and find something that they can understand.

the effort required to construct the model must be less than the communication value that arises from its user. – David West

I was once the project lead on a web-based project management application for a Fortune 50 company. The GANTT chart was deemed by the customer to be the most effective form of communication since everyone else in his company used them. In fact, they all used Microsoft Project to generate them.

We spent about six weeks of development per the customer’s direction integrating support to output an exact Microsoft Project GANTT chart replica. At the end of those six weeks the GANNT chart was canceled.

I don’t know why the GANTT chart was canceled for sure, but during the time of development we discovered that our domain experts and our customers didn’t really understand a GANTT chart. They sorta knew what it looked like because it was what they gave to their coworkers and bosses every few weeks to report progress, but they didn’t really understand what they were really trying to capture.

I think that once they understood what they actually wanted and what a GANTT chart actually was that it didn’t make sense to use a GANTT chart after all. But that’s just my speculation of course.

Tools like Microsoft Project are evil, mostly

I don’t like tools like Microsoft Project or any tool that locks you into their process for how you should do things. Or maybe it’s that I don’t like people who use tools but don’t understand how to use the tool or at least what the outputted artifacts (diagrams, GANTT charts, etc).

Thank you to people who don’t effectively communicate

I try to communicate effectively, and I try to constantly improve that communication. People who don’t either of these things will make my portfolio bigger.

Refactoring ActiveRecord::Base

2007-03-15T00:00:00-04:00

ActiveRecord (AR) is one of my favorite programming libraries ever created. I am very thankful that “DHH”:http://www.loudthinking.com woke up one day and decided to author it.

Recently there has been talk in a few threads (How I Monkey Patched AR and ActiveRecord Refactoring) on the Rails-Core list which are trying to invite AR contributors, plugin authors and all around AR enthusiasts to think about refactoring AR.

The Good

AR is the best “ORM”:http://en.wikipedia.org/wiki/Object-relational_mapping that I know of and actively use. ActiveRecord::Base is the centralized theme of ActiveRecord. It’s what you subclass when you need to model an actual database table. It’s where you declare your associations (hasone, belongs_to, etc…)_. It connects your application code to your database storage.

The Bad

ActiveRecord::Base dishes off some of the SQL generation tasks to the underlying connection adapter. This means that if you’re using MySQL then the MysqlAdapter is going to be responsible for quoting valute (for instance the methods quote and quotevalue)_.

Unfortunately ActiveRecord::Base remains to keep some functionality it should most likely give up to the connection adapters. This functionality includes any partial SQL that you see in ActiveRecord::Base, in my opinion.

The Ugly

Since ActiveRecord::Base is holding onto some implementation it doesn’t deserve you can’t get a clean interface for extending aspects of SQL generation without overriding and reimplementing methods on ActiveRecord::Base.

The downside to this is that it’s not isolated to even just your adapter. Even more so, it’s not isolated to just your functionality. Why is this bad? It increases the risk that a bug in your code is going to bring down other parts of the system which may or may not be totally unrelated.

Examples of this include how queries are built. The attributeconditions_ method on ActiveRecord::Base is responsible for handling Array, Range and nil objects specifically. If your object isn’t one of those then you’re going to get stuck with an equals = comparison. An example of this is when you do a :find method call with conditions Hash. For example:

SomeModel.find :all, :conditions=>{  :id => [ 1, 2, 3 ], :age=>(20..25) }

The above code is great, but what happens when you want to use database specific features (or features which use different SQL dialect) like one regular expression searching, database functions, subqueries. Or even supporting additional query modifier statements like the WITH clause that MS SQL, Oracle, DB2 and PostgreSQL8.2 offer, or even the infamous ON DUPLICATE KEY UPDATE functionality that MySQL offers?

Plugins - An Existing Solution

One solution is to have everyone release plugins which extend, implement, override or re-implement functionality that AR currently offers. Some folks in the Rails community even like to suggest that people create plugins and then if the plugin becomes popular they’ll consider putting it into core.

While I see the benefit in this (if no one uses the functionality why does it belong into core?) I also see the need to start considering and refactoring AR to support what some would consider cleaner, more extendable code.

I have even gone as far as implementing “ActiveRecord::Extensions”:http://www.continuousthinking.com/tags/arext which is a plugin that is trying to solve a lot of these issues. And I believe it has in some regards.

Why Plugins and Method Overriding Isn’t The Final Answer

Plugins and method overriding (for all of those calls to alias, you know who you are) aren’t the solution for where AR probably should go as Rails starts on its sweep of moving to a 2.0 release.

The problem is that when several plugins have to forcefully override core methods on ActiveRecord::Base to extend the functionality it screams out to me that ActiveRecord could use a little refactoring love. This would allow alot less method overriding and aliasing while still allowing plugin developers to extend AR’s functionality.

“Fowler”:http://www.martinfowler.com talks about “code smells”:http://www.martinfowler.com/bliki/CodeSmell.html and the continuous overriding of core methods seems to indicate one or possibly more.

How Can AR Separate Subjective Desires From Objective Needs

A few simple guidelines to use:

Domain specific problems shouldn’t be put into ActiveRecord core.
Generic database solutions should be put into ActiveRecord core. ** A public interface should be put onto ActiveRecord::Base if it operates on a given table or model objects ** Implementation details should be hidden inside of an adapter somewhere. (ie: no SQL generation in ActiveRecord::Base)
Generic solutions which impose different SQL dialect should be put into adapters or another component which adapters know how to use.

A few simple questions to think when deciding to extend AR with a plugin or introduce new ideas to AR core:

Is the functionality provided by more then one database even if the how its done differs?
Can this functionality be isolated or encapsulated in a way that reduces the risk of breaking other AR functionality should a bug be found? (ie: are you overriding core ActiveRecord::Base methods and aliasing the original? If so this is a very easy bug to introduce here.)
Does this functionality make sense in only your problem domain, or does it makes sense in most or all problem domains?

Moving Forward

I am working on a patch to AR core which removes all SQL code in ActiveRecord::Base and extracts it out into the connections adapters. It will provide an API for creating additional or specific query based modifiers. This will provide things like prefix and suffix modifiers. It will also separate generic query generation (SQL dialect that all databases support) from non-generic query generation.

This functionality already exists in “ActiveRecord::Extensions”:http://www.continuousthinking.com/tags/arext and you can see its usage examples in Ruby Insiders “December Article”:http://www.rubyinside.com/advent2006/17-extendingar.html . The implementation will slightly differ since by patching AR core itself I’ll be able to introduce simpler code.

The ability to create and extend custom better finder support will be introduced in this patch which allow core developers and/or plugin developers to isolate their code changes and to include that support into the adapters of their choice, without overriding AR core methods.

Thoughts?

If you’ve read this whole post then you’re most likely interested in AR and it’s future. What do you think?

ActiveRecord::Extensions 0.5.2 Released!

2007-03-15T00:00:00-04:00

ActiveRecord::Extensions 0.5.2 is released! A rubygem has been born!

Installation is so easy now for ActiveRecord::Extensions:

gem install -r 'ar-extensions'

Enjoy!

0.5.1 was also released, but I quickly released 0.5.2 after it to fix a possible bug with method aliasing. This would only occur if you had another plugin or rubygem which used the same alias name for ActiveRecord::Base#quote

ActiveRecord::Extensions 0.5.0 Released!

2007-03-14T00:00:00-04:00

ActiveRecord::Extensions 0.5.0 is released! This release includes support for querying against Time objects against ActiveRecord columns which are considered :datetime by ActiveRecord’s standards (this typically include DATETIME and DATE database columns).

Code Example

To find all blog posts within the last week:

BlogPost.find( :all, :conditions=>{ :created_at_gt => Time.now-1.week } )

To find all posts within the last year:

BlogPost.find( :all, :conditions=>{ :created_at_gt => Time.now-1.year } )

To find all posts over a year old:

BlogPost.find( :all, :conditions=>{ :created_at_lt => Time.now-1.year} )

To find all users who logged in within the past 15 minutes:

User.find( :all, :conditions=>{ :logged_in_at_gt => Time.now-15.minutes} )

Supported Suffix Modifiers

This particular query addition supports the following column name suffix modifiers (ie: the “_lt” in the “created_at_lt”).

_lt => less than
_gt => greater than
_lte => less than or equal to
_gte => greater than or equal to
_ne => not equal to
_not => not equal to
_eq => equal to (this is implied without a suffix present)

MySQL TIMESTAMP Disclaimer

This does not work on TIMESTAMP columns for MySQL due to an issue with the inconsistency of TIMESTAMP columns in varying versions of MySQL and due to the nature of server configurations which can alter the behavior of TIMESTAMP columns.

PostgreSQL Support Note

I recently switched to a Mac, I am compiling PostgreSQL 8.1 and 8.2 as I type this. As soon as I can test this functionality against PostgreSQL I will release an update with that support.

Download It Now!

Rubyforge: “http://rubyforge.org/frs/?group_id=2113”:http://rubyforge.org/frs/?group_id=2113

Recapping UI Architectural Patterns

2007-03-04T00:00:00-05:00

Here are some recent summarizations and thoughts on classic classic Model View Controller , Model View Presenter and then finally end on the more recent Presenter First pattern.

Model View Controller

Model View Controller (MVC) is an architectural pattern used to separate domain objects which model our perception of the real world and the presentation objects used which are the GUI components that we see on the screen.

A few key points regarding domain objects: * domain objects should be completely self contained and they should work entirely without reference to the presentation.

domain objects should support multiple presentations, possibly simultaneously
domain objects send events when it’s state changes to allow views and controllers to observe those events

In MVC, the domain element is referred to as the model. Domain objects are to represent their real world counterpart. For example, a domain object for a person would be a Person object.

The presentation (UI) part of MVC is the view and the controller.

the controller’s job is to take user input and figure out what to do with it
the view’s job is to be the UI (The view should contain as little to no logic as possible.)

There is a model-view-controller for each element on the screen.

Some important notes about the design of MVC:

the model object does not contain a reference to the controller or the view
the controller and the view contain a reference to the model
the controller and the view do not contain references to one another
the controller and the view observe the model object for events/changes

The design of MVC shows that the controller does not directly update the view. Instead it notifies the model, and lets the observer mechanism take over. Since the view is observing the model object it should update itself accordingly.

Issues With MVC

Issue #1 - View Coupling

Since a model, view and controller exists for each UI element on the screen, MVC can fall short when an update in one view propagates a change in a different view. This is because you can end up with coupling between views:

having one view update another view couples the views
you can solve this by creating a new view which is composed of the previous two views

Issue #2 - View Logic

A second issue which is a variant of the first issue exists when an update in one view propagates a change to itself or another view which is based on criteria based on the change in the domain object.

The problem with the second issue is that you have logic that makes a decision about the presentation of your model. The logic to do this isn’t necessarily domain logic so it doesn’t belong in the model. You also don’t want to put unnecessary logic in the view.

You can solve this by: * creating a new model object that is oriented around the screen (presentation) which wraps the original model object. The view logic could go in this model object without affecting the original model object. (this would be equivalent to creating an intermediate Presentation Model object to handle the view logic)

According to Fowler, the Presentation Model also allows you solve the issue of presentation state, as well as presentation logic. By wrapping the domain model in a presentation model you can maintain view specific logic and state separate from our domain logic. All the while leaving the view very clean.

Issue #3 - View Testability

Testing views is extremely difficult. This is one of the reasons why MVC suggests to leave views as simple as possible, because they are hard to test.

You can reduce the risk of issues in the view by moving most, if not all of the logic outside of the views into domain objects or presentation model objects which can be self-contained and are easier to test.

Conclusion

MVC is the building blocks for breaking out domain logic from presentation logic.

Testing a strict MVC architecture seems to have its drawbacks especially if complex view logic is kept in the view. The overhead of creating a model/view/controller for each UI element also seems to be a daunting task to coordinate and test.

Rather then strictly following MVC it seems to be a better approach to utilize a MVP approach.

Model View Presenter

Model View Presenter (MVP) is a architectural pattern similar to MVC. Whereas in MVC there is a controller/view for each UI element, in MVP there is a typically a single presenter/view for each for screen or at the least for each set of complex screen elements.

MVP and MVC share the commonality that they both rely on the observer synchronization. In MVP the presenter handles user actions and updates the model. In MVC the controller handles user actions and updates the model. In both MVP and MVC the view will then be updated by observing events/changes on the model.

MVP implementations can vary in a great deal when it comes to how the view gets updated: * one variation maintains the same relationship between the model, view and presenter that is maintained through MVC’s relationship of the model, view and controller. * a second variation allows the presenter to have access to the view to update the view when complex view logic is required, otherwise view logic would go in the view. Fowler refers to this as the Supervising Controller (aka Supervising Presenter). * a third variation puts all of the view updates inside of the presenter. This implements what Fowler refers to as a Passive View. * a fourth variation of this is implemented in the Presenter First pattern. (this will be describe later)

Conclusion

MVP simplifies complex view updates by utilizing a Supervising Controller. By extracting out complex view logic is promotes greater testability for your application.

Allowing a presenter object to handle the user actions for a screen, form or set of UI elements seems to cut down on unnecessary complication and overuse of observers as you could get with MVC.

Presenter First

The Presenter First (PF) approach is a variant of MVP. In practice the authors emphasize using it in an agile development process which build features into an application given customer stories. It is considered to be a hybrid of process and pattern.

To outline some of the things PF does:

separation of business logic and view logic
separation of complex view logic from the view
decoupling of the view from the presenter/model
provide fully testable GUI applications

PF works by composing the model and the view into the presenter via dependency injection. The presenter is created, but is never reference throughout the application. It simply glues together the model and view.

The model nor the view contain a reference to the presenter. Instead they send events that the presenter observes, and the presenter then coordinates those events and updates the model or view accordingly.

View —-> Presenter <—- Model

PF states that the view is the most complex, tedious and time consuming component to test. PF’s goal is to leave the view as simple as possible. One way it promotes to do this is to only allow your view to manage simple data types. If complex data types are handled in your view, then your view must contain the ability to process and correctly display the complex data types. Since this promotes additional logic in your view, PF discourages this.

PF ties user stories directly to a specific MVP triplet. The term “triplet” is used to refer to an instance of a model, view and presenter. Triplet is commonly referred to as a “triad”.

PF takes into account that complex view logic that exists. Often times that logic is mixed in with the domain objects. The problem with this is that the domain objects now contains a mixture of domain logic and view logic. This makes the code harder to read and it complicates the interaction between the model, presenter and view because complex view updates are propagating from the model itself.

PF solves this by introducing an “adapter” object. The adapter object goes in between the view and the presenter. The presenter will now reference the adapter, and the adapter will reference the view. There now exists a place that isolates any logic that is needed for the view. View logic is now fully testable.

Also, the adapter object may lead to an adapter-model object in which only the adapter would reference. This could be used to maintain view/presentation state. Even if an adapter object is introduced, the term “triplet” is still used.

PF also suggests that the presenter objects have no public methods and that they are stateless. The presenter’s job is merely to coordinate events between the view and the model (or vise versa).

PF also suggests that starting with the presenter first is the best place to start the development of a user story. Over time PF suggests it is less expensive to start with the presenter, rather then the view or the model.

Conclusion

Presenter First promotes a consistent, predictable convention for class naming, and object responsibility. It allows for IDEs or development tools to be created to speed up the development, creation and testing of these objects.

The interaction between the components in PF is easy to understand and the way that it is approached by the authors seems to remove issues with more classic MVC patterns or other MVP variants.

So I Got A Mac

2007-02-20T00:00:00-05:00

So I got Mac. A second-tier Mac Book Pro actually. After the past few years of being a dedicated linux enthusiast, it appears to be the best bet out there for a dual business/development box.

(I’ll still run Kubuntu for my desktop box at home and Ubuntu server for my server, but as of right now I’m not having any second guesses about the Mac. )

The built-in webcam and the iChat video support immediately made it worth it. I got Emacs working in just a few minutes and firefox is downloaded and installed.

I spent a few hours today installing/compiling a bunch of packages from MacPorts, but so far it’s been well worth it.

I am digging the magnetic power adapter as well. Thanks to Brandon, John and Craig for letting me pick their brains about OSX throughout the day!

Moving On

2007-02-14T00:00:00-05:00

Well it’s over.

After nearly six years of working with my current employer developing custom software I have decided to pursue a new direction.

My passion for developing better software has gotten the best of me. I 100% agree with the “Agile Manifesto”:http://www.agilemanifesto.org and that’s why tonight I became a signatory and part of the reason why I felt it was time for me to pursue a new direction. To iterate the four main points of the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Individually as a developer and a team member I wake up and do the following every day I go to work:

As a software developer I take pride in the software that I create and that others may have to maintain.
As a tester I take pride in proving that my software works so it can be changed with confidence to satisfy evolving business needs, even if that change is not going to be made by me.
As project member I take pride in communicating and collaborating to those I work with to give the project it’s best possible chance of success and of also solving the right business problem.
As a person I take pride in respectfully and genuinely treating those I encounter through work and every day life.

I wish my previous employer the best of luck.

To those who read this post, I hope you will either be positively affected in someway by the software that I have or will help create or that you will positively affected by working with me directly for software that will solve your business needs.

ActiveRecord::Extensions 0.4.0 Released!

2007-02-12T00:00:00-05:00

ActiveRecord::Extensions 0.4.0 is released!

Updates

added to_csv functionality (works with belongs_to, has_one and has_many relationships)
added temporary table functionality
added foreign key functionality

to_csv functionality

Example 1, exporting all fields

 class Book < ActiveRecord::Base ; end

 book = Book.find( 1 )
 book.to_csv

Example 2, only exporting certain fields

 class Book < ActiveRecord::Base ; end

 book = Book.find( 1 )
 book.to_csv( :only=>%W( title isbn )

Example 3, exporting a model including a belongs_to association

 class Book < ActiveRecord::Base
   belongs_to :author
 end

 book = Book.find( 1 )
 book.to_csv( :include=>:author )

This also works for a has_one relationship. The :include option can also be an array of has_one/belongs_to associations. This by default includes all fields on the belongs_to association.

Example 4, exporting a model including a has_many association

class Book < ActiveRecord::Base
  has_many :tags
end

book = Book.find( 1 )
book.to_csv( :include=>:tags )

This by default includes all fields on the has_many assocaition. This can also be an array of multiple has_many relationships. The array can be mixed with has_one/belongs_to associations array as well. IE: :include=>[ :author, :sales ]

Example 5, nesting associations

 class Book < ActiveRecord::Base
   belongs_to :author
   has_many :tags
 end

 book = Book.find( 1 )
 book.to_csv( :include=>{
                 :author => { :only=>%W( name ) },
                 :tags => { :only=>%W( tagname ) } )

Example 6, using Arrays returned by find

 class Book < ActiveRecord::Base
   belongs_to :author
   has_many :tags
 end

 books = Book.find( :all )
 books.to_csv( :include=>{
                 :author => { :only=>%W( name ) },
                 :tags => { :only=>%W( tagname ) } )

Temporary Table Support

Example 1, using defaults

 class Project < ActiveRecord::Base ; end

 Project.create_temporary_table

This creates a temporary table named ‘temp_projects’ and creates a constant name TempProject. The table structure is copied from the projects table.

Example 2, using :table_name and :model options

Project.create_temporary_table :table_name=>'my_projects', :model=>'MyProject'

This creates a temporary table named ‘my_projects’ and creates a constant named MyProject. The table structure is copied from the projects table.

Example 3, using :like

ActiveRecord::Base.create_temporary_table :like=>Project

This is the same as calling Project.create_temporary_table.

Example 4, using block form

Project.create_temporary_table do |t|
  # ...
end

Using the block form will automatically drop the temporary table when the block exits. t which is passed into the block is the temporary table class. In the above example t equals TempProject. The block form can be used with all of the available options.

Foreign Key Support

Enables support for enabling and disabling foreign keys for the underlying database connection for ActiveRecord. This can be used with or without block form. This also uses the connection attached to the model.

Example 1, without block form

Project.foreign_keys.disable
Project.foreign_keys.enable

If you use this form you have to manually re-enable the foreign keys.

Example 2, with block form

Project.foreign_keys.disable do
  # ...
end

Project.foreign_keys.enable do
  # ...
end

If you use the block form the foreign keys are automatically enabled or disabled when the block exits. This currently does not restore the state of foreign keys to the state before the block was entered.

Download It Now!

“ActiveRecord::Extensions 0.4.0”:http://rubyforge.org/frs/?group_id=2113

Check it out from SVN into your Rails project

svn co svn://rubyforge.org/var/svn/arext/tags/ar-extensions-0.4.0 vendor/plugins/

Temporary Table Nicety

2007-01-31T00:00:00-05:00

A taste of temporary table support for ActiveRecord and MySQL.

Creating Temporary Tables

Temporary tables can be created by using two forms. Temporary tables will generate the following SQL:

CREATE TEMPORARY TABLE table_name LIKE base_table

The First Form

A block form which manages your temporary table (ie: it creates the table at the start of the block and ensures it is removed by the end of the block, similar to how IO objects work in ruby) .

The Second Form

The second form allows you to assign your temporary table to a variable. You are responsible for destroying it. Or you could just leave it around until your ruby process is done and your database will kill it when the connection closes.

Here’s an example using the block form:

# create our model
class Account < ActiveRecord::Base
end

# perform the update
Account.create_temporary_table do |t|
   t.new.is_a? ActiveRecord::Base # => true
   t.new.is_a? ActiveRecord::TemporaryTable # => true

    # You can treat 't' like any model class, and create new records, 
    # add validations, etc.
    record = t.new :name=>"New Account" 
    record.save
    record.create :name => "Another new account"

    # TempAccount is created to reference this model class as well
     TempAccount == t # => true

    # the "end" block here will drop our temporary table and remove
    # our TempAccount constant
end

Checking It Out

You can pull it down from trunk right now. It will be included in the next release (which will be 0.4.0):

svn checkout svn://rubyforge.org/var/svn/arext/trunk/ar-extensions

Like Tables

Like tables are similar to temporary tables. In fact they are created in the exact same way except that they are permanent. They are normal tables until you destroy them. A like table simply generates the following sql:

CREATE TABLE table_name LIKE base_table

You can create this the same way way you create temporary tables, just pass in the :permanent option as a parameter:

class Account < ActiveRecord::Base
end

# t is your model class, also aliased as TempAccount.
temp_account_model_class = Account.create_temporary_table :permanent=>true

TempAccount == temp_account_model_class # => true  

# drop your table
TempAccount.drop

ActiveRecord Foreign Key Nicety

2007-01-24T00:00:00-05:00

I’ve been busy lately and I haven’t finished the to_csv functionality for ActiveRecord::Extensions. It’s coming, but I haven’t had time to implement all of the tests.

A new feature that myself and Mark Van Holstyn worked up was because we wanted an elegant solution to this in a problem we had. And it was time to finally put in the foreign key support that I hacked together over a year ago. Now it’s not a hack, and I think it’s kind of elegant.

# Disable foreign keys altogether
ActiveRecord::Base.foreign_keys.disable

# Enable foreign keys 
ActiveRecord::Base.foreign_keys.enable

# Run some updates in a disable block and have AR automatically re-enable foreign keys
Topic.foreign_keys.disable do
   # ... code here....
end

# Run some updates in a enable block and have AR automatically re-disable foreign keys
Topic.foreign_keys.enable do
   # ... code here ....
end

This works on any instance of ActiveRecord::Base, and it works on the connection for that instance. So if you have models which are connected to different databases, no worries.

This is in trunk right now and works great for MySQL.

open4status for ruby

2007-01-19T00:00:00-05:00

open4status which is an adjustment to open3.rb thats found in the standard library returns stdin, stdout, stderr and a Process::Status object of the command that ran. This way you can determine the exit status code of the command that you passed into popen4status method.

require 'open4status'

stdin,stdout,stderr,status = Open4.popen4status( "some command here" )
puts status.exitstatus

The problem this solves is that when you use Open3.popen3 or Open4.popen4, the $? value isn’t set. Since the way that $? is set can’t be done without writing a C extension or patching ruby itself this handles the problem elegantly by returning the Process::Status object.

The Code

This is being distributed as a poor man’s way of code distribution.

I am waiting to hear back from Ryan Davis on a bug/feature request to Open3 to see if this is something he wants to include in his “codeforpeople”:http://www.rubyforge.org/projects/codeforpeople project at Rubyforge.

If not I’ll release a gem. Until then here’s the file:

“http://www.continuousthinking.com/assets/2007/1/19/open4status.rb”:http://www.continuousthinking.com/assets/2007/1/19/open4status.rb

.screenrc configuration

2007-01-07T00:00:00-05:00

I spend most of my time in screen when I’m coding or doing any system administration work. It gives me the ability to do multiple things in a single window, and never have to remove my hands from my keyboard to switch terminal sessions or split windows. It even provides the flexibility of detaching and reattaching to screen sessions while leaving your terminal sessions in existence.

I’ve been using the below .screenrc file recently to give me some more useful information.

The screenshot

Note the following things in the screenshot:

system hostname
system ip addresses for each interface configured (see below “whatsmyip” file information)
system load (updates every few seconds)
date
current time (this updates every second)

The .screenrc file

altscreen on
hardstatus on
hardstatus alwayslastline
backtick 1 60 60 /home/zdennis/bin/whatsmyip
hardstatus string "%-Lw %{= kG}Host: %{Y}%H%? %{c}(%1`) \
%{= kG} %-=Load: %{Y}%l%{kG}  %{= kG}Date: %{Y}%m/%d\
/%y%{= kG}  Time: %{Y}%C:%s%a%{= kG}%{W}"
caption always
caption string "%-Lw%{= bw}%50>%n %t%{-}%+Lw%<"

Note: The lines that end in \ note a continuation of the line.

The whatsmyip file

The whatsmyip file is a simple ruby script which parses out all interfaces configured with an ip address.

#!/usr/bin/ruby

interfaces = `ifconfig`.scan( /^(\w+)/ ).flatten.delete_if{ |interface| interface =~ /lo/ }
arr = interfaces.inject( \[\] ) do |arr,interface|
  md = `ifconfig #{interface}`.match( /((\d+\.){3}\d+)/ )
  arr << "#{interface}: #{md.captures.first}" if md
  arr
end
print arr.join( ' ' )

to_csv update (nearing Round #2)

2007-01-04T00:00:00-05:00

Round #2 of the to_csv functionality is nearing completion. The updates so far are:

supports associations via the :include option on a per model object basis
supports custom headers through the model class

It will work on an ActiveRecord model object itself or an array of ActiveRecord model objects that are returned from any “find” method call.

Basic :include option

The :include option will bring in an association that is created with belongs_to or has_many declarations.

Here is a basic example for a belongs_to association to be included in the CSV results with default options:

csv = People.find( :all ).to_csv( :include=> \[ :address \] )

If you haven’t been following to_csv functionality prior to this posting the to_csv method does support toggling on/off of the CSV headers:

:headers=>true
:headers=>false

Updated :headers Option

To detour from the :include options for a moment, the :headers option has been updated to accept:

an array of column names as Symbols or Strings
a Hash of column name to header name mappings as Symbols or Strings

Here are a few examples of the new headers option in use:

# using symbols
csv = People.find( :all ).to_csv( :headers => [ :first\_name, :last\_name ]  }

# using strings
csv = People.find( :all ).to_csv( :headers => [ 'first\_name', 'last\_name' ]  }

# using a Hash to supply custom headers
csv = People.find( :all ).to_csv( :headers => { :first\_name=>'FirstName', :last_name=>'LastName' }

Since Arrays are ordered the CSV columns will be in the order of the Array. Since Hashes aren’t ordered the order of the columns will be done alphabetically based on the field name.

Intermediate Usage Of :include

The :include option can take:

an Array of Strings or Symbols denoting the name of the association
a Hash of Hashes mapping the association name to an options Hash

The options Hash is what you’re already passing into the to_csv method. If you use the Hash form of :include you get the ability to embed different options per each association included.

Here are some more intermediate examples:

people = People.find( :all )

# Using a Hash to specify the column you want from the Address relationship
people.to_csv( :include=>{ :address=>{ :only=>[ :street, :city, :state, :zip ] } } )

# Using a top level options to include only certain fields from each person and
# then options to include certain fields from each person's address.
people.to_csv( :only=>\[ :first_name, :last_name \],
   :include=>{ :address=>{ :only=>\[ :street, :city, :state, :zip \] } } )

# Modification of the last example to use custom headers
people.to_csv( :headers=>{ :first_name=>"FName", :last_name=>"LName" } ,
   :include=>{ :address=>{ :headers=>{ :city=>"Hometown", :state=>"ST" } } } )

That’s a brief summary for where the state of affairs is at for now. If you want more information please read all of the nice tests by “checking out”:http://rubyforge.org/scm/?group_id=2113 the SVN repository.

There are some other usages that you will be able to do like (see below) but the tests and functionality has not been intentionally implemented although it may/may work off from existing functionality:

support multiple :include options for multiple associations
embed :include options inside of :include options for chaining associations

One thing I don’t like about all of this so far is all of the curly braces, brackets and potentially parenthesizes. The more :includes you want to have, the more curly braces you’re going to have most likely.

I’m trying to think of a block like declarative syntax to handle this, but I haven’t come up with any worthwhile yet. If you’ve got any ideas I’m all ears.

Upcoming 0.4.0 release

This will be launched in a 0.4.0 release which should be soon. I’ve got to be out of town part of this weekend, and the most of next week so I am going to see if I can crunch it in before the next Monday.

ActiveRecord::Extensions 0.3.0 Released!

2006-12-30T00:00:00-05:00

ActiveRecord::Extensions 0.3.0 is released! Download it “here”:http://rubyforge.org/frs/?group_id=2113.

There are no functionality changes in this release. There are two changes:

thanks to Michael Schuerig for pointing out a potential namespace issue which is fixed in this release
tests are now loaded in the a new ruby process rather then into the same ruby process as rake tasks when running rake test:ADAPTER

ActiveRecord::Extensions 0.2.0 Released!

2006-12-22T00:00:00-05:00

ActiveRecord::Extensions 0.2.0 is released! Download it “here”:http://rubyforge.org/frs/?group_id=2113 .

Updates include:

Changes to the tocsv_ method to support an API compatible with the “ToCSV plugin”:http://blog.integralimpressions.com/articles/2006/09/01/tocsv-plugin by Chris Abad
Added support for SQLite and SQLite3
Added “does_not_match” suffix for :conditions which want to negate a regex
Added “not_between” suffix for :conditions which want to negate a range
Converted test database schema to use migrations, and added tasks to load test database

to_csv updates

class Developer < ActiveRecord::Base ; end
developers = Developer.find( :all )

# Output default headers, this is implicit if headers is not provided
csv  = developers.to_csv( :headers => true )

# Output no headers
csv = developers.to_csv( :headers => false )

# Output only the following columns
csv = developers.to_csv( :only=>[ :id, :name ] )

# Output all columns except the following
csv = developers.to_csv( :except => [ :id, :name ] )

Updates to better finders

I was typing some code today and I was using Ranges and Regexps. It just felt write to say that somethingdoes_not_match_ when matching between a Regular Expression. And then I decided to add “not_between” for Ranges.

class Developer < ActiveRecord::Base ; end

# find all developers whose name does not match the regex
Developer.find :all, :conditions => { :name_does_not_match => '^Zach' }

# find all developers whose IQ is not between 80 and 120
Developer.find :all, :conditions => { :iq_not_between => ( 80 .. 120 ) }

Running ActiveRecord::Extensions Tests

ActiveRecord::Extensions provides a great testing suite. Just run “rake -T” to see all of the supported tasks. In 0.2.0 the ability to load a test database from migrations has been added.

 # Usage
 rake db:test:prepare_<db>

 # IE:
 rake db:test:prepare_mysql

 # Then run your tests:
 rake test:mysql

 # And don't forget to test against activerecord
 rake test:activerecord:mysql ~/rails_trunk/activerecord

The only prerequisite of the above is to make sure that your connection is specified correctly for the database you want to test. To do this go into the tests/connections/native_DB/connection.rb file and update the database configuration.

Enjoy 0.2.0!

For any questions or comments let me know. * zach DOT dennis AT gmail DOT com

ActiveRecord::Extensions SQLite Compatibility

2006-12-21T00:00:00-05:00

The upcoming 0.2.0 release is going to include SQLite compatibility, and it looks like that is going to be released before the weekend hits! Any one out there who uses SQLite and wants to leverage the usefulness of ActiveRecord::Extensions, wait no longer (then 1 to 2 more days)!

The upcoming 0.2.0 release will update the to_csv and to_csv_file method arguments.

# rather then
array_of_models.to_csv( :headers => [ :field1, :field2, :field3 ] )

# it'll be
array_of_models.to_csv( :headers => true|false, :only=> [ :field1, :field2, :field3 ] )

# or
array_of_models.to_csv( :headers => true|false, :except=> [ :id ] )

# and the same goes for the options that were passed into to_csv_file as well
array_of_models.to_csv_file( filename, :headers=>[ :name, :salary ] )

Thanks to Dan Kubb for bringing this up. The API is borrowed from Chris Abad’s “ToCSV plugin.”:http://blog.integralimpressions.com/articles/2006/09/01/tocsv-plugin

After that I’ll be on holiday vacation and I hope to kick out some cool stuff, like the :include option that Dan Kubb “mentioned.”:http://rubyforge.org/tracker/?atid=8256&group_id=2113&func=browse for the to_csv.

ActiveRecord::Extensions 0.1.0 Released!

2006-12-17T00:00:00-05:00

ActiveRecord::Extensions 0.1.0 is released and it’s getting some press! An article has been “published”:http://www.rubyinside.com/advent2006/17-extendingar.html on “Ruby Inside’s Advent Calendar”:http://www.rubyinside.com/advent2006/ . Thanks to Peter Cooper for publishing the article.

Release Notes

ActiveRecord::Extensions 0.1.0 features:

to_csv functionality for Arrays returned by ActiveRecord::Base.find methods
to_csv_file functionality for Arrays returned by ActiveRecord::Base.find methods
Custom query object support for ActiveRecord::Base.find
Official better finder support for MySQL and PostgreSQL
Generic better finder support for all other database adapter supported by ActiveRecord
Official import functionality support for MySQL and PostgreSQL
Generic import functionality support for all other database adapters supported by ActiveRecord

0 is actually the seventh release of ActiveRecord::Extensions, it’s version number is so low because as more adapters are officially supported, it will quickly rise towards a 1.0.0 release.

Official Support vs. Generic Support

Official support means that I have tests for the adapter in question, and it without a doubt works with ActiveRecord::Extensions.

Generic support means that I have implemented default ActiveRecord compatibility with all of the features. It should work with all supported adapters of ActiveRecord, but there are not tests in my library testing those adapters.

to_csv

tocsv_ has been added as a method to all Arrays returned by ActiveRecord::Base.find. You can now quickly and painlessly turn ActiveRecord objects into CSV format. This functionality does rely on faster_csv (1.0.0 or higher) being installed:

class Project < ActiveRecord::Base ; end
projects = Project.find( :all )
csv = projects.to_csv

You can also pass in an array of headers that you want as Strings or Symbols:

csv = projects.to_csv( :headers => [ :project_name, :started_on, :estimated_due_date ] )

to_csv_file

tocsv_file_ has been added as a method to all Arrays returned by ActiveRecord::Base.find. It gives you the ability to quickly csv files, much like it’s sibling function tocsv_. Instead of simply returning a CSV string it writes a file to disk:

projects = Project.find( :all )

# Writes projects.csv to disk using the 'w' file mode operation
projects.to_csv_file( 'projects.csv' )

# Writes projects.csv to disk using the 'a' (append) file mode operation. 
# Any IO mode is supported as the second parameter.
projects.to_csv_file( 'projects.csv', 'a' )

# Writes projects.csv to disk specifying what columns headers to use:
projects.to_csv_file(
     'projects.csv', 
     :headers=> [ :project_name, :started_on, :estimated_due_date ] 
)

Refactorings

This release also includes some refactorings of how ActiveRecord::Extensions internals work to support better extensibility down the road.

Download and Install

“Download it now from rubyforge!”:http://rubyforge.org/frs/?group_id=2113 .

Installation is simple. You can put it in your Rails application by placing the extracted directory in your RAILS_ROOT/vendor/plugins directory or you can put it in any application and require the init.rb file included in the ar-extensions-0.1.0./ directory.

Upcoming in the next release will be easier installation via “gem install” or installation as a Rails plugin from your rails application using “script/plugin”.

Contact the Developer

Any questions, comments or bugs please feel free to use the Project Tracking features on the “RubyForge project site”:http://rubyforge.org/tracker/?group_id=2113

Email: Zach Dennis - zach DOT dennis AT gmail DOT com

COBOL, A Short Visit

2006-12-06T00:00:00-05:00

I wrote some COBOL today. I can’t say it was fun, enjoyable or even breath taking. It was more of a “oh my gosh, I’m so glad we have languages better COBOL these days!”.

I was working with a vendor who runs a data extract program from a COBOL program. We needed to utilize a non-printable whitespace character as a field delimiter. They didn’t know how to do that since COBOL treats all whitespace equally, as spaces. I was hoping COBOL would treat \t literals as actual tabs, but it doesn’t.

So I ended up with my sample program:

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. hello.
000300 PROCEDURE DIVISION.
000400 DISPLAY X'09'.
000500 DISPLAY "Hello World!".
000600 STOP RUN.

That X’09’ gave me my binary character for a tab! I can’t say I’d want to program in COBOL, but for a very short visit it was fun to read up on it, and write some sample programs. The above six-liner just happened to be the one I needed.

Rails, Creating Tables With Different Primary Keys (PostgreSQL)

2006-12-03T00:00:00-05:00

Say you’re using PostgreSQL and Rails and you want to create a table with a primary key that is not the field ‘id’. How do you make that work?

At first thought you might try the below:

ActiveRecord::Schema.create_table :articles, :id=>false do |t| t.column :title, :string end

You pass in :id=>false because that tells ActiveRecord that you don’t want ActiveRecord::Schema to create or set a field for your primary key. So you plug into your application code that actually relies on your new table:

class Article < ActiveRecord::Base
end

Article.create :title=>"Test Article"

You get an ActiveRecord::StatementInvalid error stating that relation “articles_id_seq” doesn’t exist? What gives?

The first problem is that since you told ActiveRecord::Schema not to create or set a primary key field, you don’t have one. ActiveRecord (and thus Rails) relies on having a primary key.

To fix this you’d simply modify your original code to look like:

ActiveRecord::Schema.create_table :articles, :id=>false, :primary_key=>'aid' do |t|
  t.column :aid, :serial
  t.column :title, :string
end

class Article < ActiveRecord::Base
  set_primary_key 'aid'
end

And now everything works!

You may notice that we use the column type serial instead of integer. This is because PostgreSQL is capable of handling auto incrementing integers and ActiveRecord expects it to unless you give it another way of handling unique primary keys (which is a topic for another post).

PostgreSQL does this with sequences, by using the serial (or even bigserial) column types you hint to PostgreSQL to automatically handle the creation of those sequences.

Click “here”:http://www.postgresql.org/docs/8.1/static/sql-createsequence.html for information sequences in PostgreSQL 8.1
Click “here”:http://www.postgresql.org/docs/8.1/static/datatype.html for information on data types in PostgreSQL 8.1

Olivia Dennis, Thursday Morning Update

2006-12-01T00:00:00-05:00

Olivia had blood taken first thing this morning. They started her on a new medicine yesterday to help regulate sodium. The blood draw should from this morning should show if it’s working. She had another spinal tap this morning, too. The doctor said that it went well-they got it on the first try. We should have results from that later this afternoon. As long as there’s no infection in the spinal fluid, WE GET TO GO HOME TOMORROW!!!

Her stinkin’ IV popped out again just now. She only has 2 doses of antibiotic left…too bad it didn’t stay in… It was in her ankle this time, wonder where they’ll try to put it next :-(

Olivia has a long road ahead of her. She has three medicines to go home with and she’ll have to see the doctor a few times a week. I’m sure she’ll be so happy to be home though! I’ll send out an email as soon as we get results.

Again, please forward this to others who want updates…thank you.

Olivia Dennis, Friday Update

2006-12-01T00:00:00-05:00

The doctor stopped in just now and gave us good news! WE GET TO LEAVE tonight! His exact words were,

”I’m sure you guys know this, but you are very, very fortunate. She’s passed MRI’s that show no brain damage, she’s passed her hearing tests, and overall she’s acting like a happy 3-month-old. She had ONE MONSTER of an infection when you brought her in and we were very scared in the beginning. She beat one heck of an infection.”

He also said that, although it sounds selfish, he’s really enjoyed getting to watch her grow. :-)

We’re going home!! We have a pile of paperwork, a stack of prescriptions, bags and bags of cards and toys, a wagon full of a month’s worth of crap, and A HAPPY HAPPY HEALTHY BABY!! Tonight is going to be a great night….

Thanks go out from the bottom of my heart for all the prayers. What an emotional rollercoaster ride we’ve all been on! We made it…she’s making it! We have more tests and appointments over the next few weeks, but it’s going to be so nice to be home. Thanks again everyone, and I’ll keep you all posted as she gets better and better! OH- and I attached a picture of her BUSTIN’ OUT OF THIS PLACE!!

!/assets/2006/12/2/olivia_leaving_hospital_tiny.jpg!:/assets/2006/12/2/olivia_leaving_hospital.jpg

olivia dennis, Tuesday afternoon

2006-11-28T00:00:00-05:00

The doctor visited today and told us that they’re planning on sending us home THIS FRIDAY!!! :-) Olivia has blood-work today and tomorrow, a urine test tomorrow and another spinal tap Thursday. It’s going to be a busy week, but we see a very very bright light at the end of the tunnel!

The doctor, however, still does have a few concerns. First, her sodium and potassium levels are still a little off. He’s not sure why. The wrong levels of sodium in your body can cause seizures. Although he doesn’t think it will get this bad, he still thinks it’s something we need to watch. The other thing that worries him is her white blood cell count. To make things simple, he basically said that her white count is down TOO far now. If she were to come in contact with any more bacteria, she doesn’t have enough white blood cells to fight it off. If she starts running a fever, he doesn’t think she’d be able to break it. So, we need to keep an eye on her!

Overall, he thinks things are going well. He thinks the inconsistencies in her sodium, potassium, and white blood cells are mainly due to her heavy doses of antibiotics. He thinks her body will correct itself once she’s done with them. When we got home, we’ll have to take her for blood tests a few times a week to make sure…

Please pray that bad germs stay away from her during these last few, very important, days at the hospital!!

She’s waking up from a nap-I’ll post pics later tonight if I have time!

Olivia Dennis, Happy Thanksgiving!

2006-11-23T00:00:00-05:00

We’ve had a good day today… Olivia had quite a few visitors today… good thing she had her cute Thanksgiving outfit on!!

No new news today. Olivia got a new dressing on her PIC line this afternoon; she wasn’t too happy. Other than that, she was a smiley happy baby all day today. I think she was happy to be back in her blue jeans-they’re her favorite…just like her mom :-)

Happy Thanksgiving to everyone!

ActiveRecord Extensions, PostgreSQL Support

2006-11-23T00:00:00-05:00

PostgreSQL support for ActiveRecord::Extensions is moving along nicely for the better finder support. It includes everything that the better finder support already supported (including Ranges, Regular Expressions and custom made query objects) except for Full Index support.

To add regular expression support (only case-sensitive at this time, case-insensitivity will come later) the only code I had to write was the below:

module ActiveRecord::Extensions

  # The below supports finder sql for regular expression 
  # support the PostgreSQL adapter:
  # Example:
  #    Model.find :all, :conditions=>{ :title => /regex/ }
  #
  class RegexpPostgreSQL < AbstractExtension   
    NOT_EQUAL_RGX = /(.+)_(ne|not)/

    def self.process( key, val, caller )
      if val.is_a?( Regexp )
        match_data = key.to_s.match( NOT_EQUAL_RGX )
        key = match_data.captures\[0\] if match_data
        fieldname = caller.connection.quote_column_name( key )
        return Result.new( "#{caller.table_name}.#{fieldname} " +
             "#{match_data ? '!~ ':'~'} ?", val )
      end
      nil
    end

  end
  register RegexpPostgreSQL, :adapters=>[ :postgresql ]

end

I am really digging the pluggable extensions so far. What do you think of the above code set to add Regexp support for PostgreSQL?

olivia dennis, wednesday morning

2006-11-22T00:00:00-05:00

We received good news last night… Olivia’s VCUG came back looking great! They didn’t see anything wrong with her entire urinary tract!
GREAT GREAT NEWS!! They’ll still do some lab work on her today. The doctor stopped in this morning. He’s happy that there’s no visible problems in the urinary tract, but he’s still concerned with the low grade fever she has had the past 4 days. Because of the fever, her spitting up CONSTANTLY, and not wanted to eat as much, he’ll be looking for some type of belly infection in today’s lab work. Her white blood cell count is still a little elevated, but hopefully there won’t be any type of infection in there! We’ll find out Friday…

Olivia hung out on her boppy last night, playing with daddy. Then there is the pouty face she gives to her daddy when she wants something….”Daddy, I want a pony”, she said. :-)

We meet again with the case manager on Monday. If all is well, we’ll be going home next week!

Olivia Dennis, Monday afternoon

2006-11-20T00:00:00-05:00

After looking at last night’s blood work, the doctors determined that Olivia was having an allergic reaction to her antibiotic. Yesterday she continued spitting up, had red blotches all over her skin, and was still a little fussy. After switching her meds this morning, she seems to be doing a little better. She’s still spitting up today, and is pretty fussy, but there isn’t a skin irritation and she’s eating better.

Our doctor decided that rather than waiting for the Ann Arbor doc to do the VCUG, he’s going to have that ordered today, so hopefully we’ll be able to get that done within the next few days.

Along with last night’s blood work, they started a blood culture to make sure there isn’t any bacteria in the blood again. The cultures are checked at 24, 36, and 48 hours. We should have the first results later this evening.

I’ve posted a few pictures from this past weekend, when she was feeling well. She giggled and laughed at mom’s goofy faces while hanging out in her swing on Friday morning. There’s also a picture of her getting geared up for the BIG game on Saturday… she was HIGHLY disappointed in the outcome, just like her grandpa Dave.

olivia dennis, sunday evening

2006-11-19T00:00:00-05:00

I’ve been hesitant to post an update the past few days…. Olivia hasn’t been feeling well. Yesterday evening she was very unhappy and irritable for some reason. She had a little tiny bit of a fever and didn’t want to eat much. She had some tylenol and I gave her a warm bath to try to calm her down. Matt and I can’t put our finger on exactly what’s wrong, but we both agree that she just isn’t acting like herself; something is a little off. She didn’t sleep much last night, so she slept until 11 this morning!

Today she’s been spitting up most of the food she’s had and we’re still having a hard time getting her to eat. She’s had blood drawn twice today, and they’re thinking of MAYBE another MRI within the next couple of days to make sure nothing is on the brain that wasn’t there before.

I just got word that her white blood cells are slightly back up again, we’ll find out exactly what that means tomorrow morning when the doctor is back in. We had hopes of being home for Thanksgiving; we’ll have to see what the next few days brings. Please keep praying for our little sweet girl-she’s come so far, but we’re not there yet…

I’ll post some pictures from the weekend tomorrow when I have more time.

ruby, class variable or class instance variables

2006-11-17T00:00:00-05:00

This is in reference to the topic of class variables or class instance variables in ruby… it’s a posting based on the recent post of Stuart Halloway, click here to read it.

Why Not Class Variables?

Stuart Halloway hits the problem that class variables has perfectly, “They are shared across an inheritance hierarchy in a counterintuitive way.” Although he doesn’t specifically say ActiveSupport or “Rails” that is where this probably exists, and IMO it promotes bad design and a bad usage of class variables.

The problem is that since class variables are shared across the inheritance hierarchy, if any class in the hierarchy changes the value of the class variable, it changes throughout the whole hierarchy. This is not good.

It is better to use instance variables on the class, because they work intuitively across inheritance, and if you change the value of class-level instance variable it only changes for that class (it doesn’t affect the rest of the hierarchy).

Class variables that are used and relied on throughout a inheritance hierarchy is BAD design IMO. Even if you intend to use class variables for your class only you are forcing people who will extend your code to potentially give in to BAD design. It is better design to encapsulate class variables into class-level instance variables which are accessed via class-level instance methods. This allows any subclasses (or potential subclasses) to redefine implementation if they want to, and it won’t have negative effects on the the rest of the hierarchy.

Here’s a scenario of BAD use for class variables. This uses the example of keeping track of how many people you have:

class Person attr_accessor :name

 @@instances = \[\]
 
 def self.instances
   @@instances
 end
 
 def initialize( name )
   self.class.instances << self
   @name = name
 end

end

joe = Person.new( “Joe” ) zach = Person.new( “Zach” )

puts “You have #{Person.instances.size} people in existence!” # POINT A

class Paramedic < Person end

sally = Paramedic.new( “Sally” )

puts “You have #{Person.instances.size} people in existence!” # POINT B puts “You have #{Paramedic.instances.size} paramedics in existence!” # POINT C

At POINT A you have two people in existence, which is correct.
At POINT B you have three people in existence, which is correct.
At POINT C you have three paramedics in existence which is incorrect!

You only have one paramedic (Sally!), but since Person is using a class variable you are stuck with affecting the whole hierarchy.

Now this is easy to fix, by using class-level instance variables. Don’t be shocked by the “class « self”…

class Person
  attr_accessor :name

  class << self
    attr_accessor :instances

    def instances
      @instances ||= \[\]
      @instances
    end
  end

  def initialize( name )
    Person.instances << self
    @name = name
  end

end

joe = Person.new( "Joe" )
zach = Person.new( "Zach" )

puts "You have #{Person.instances.size} people in existance!" POINT C

class Paramedic < Person

  def initialize( name )
    super( name )
    Paramedic.instances << self
  end

end

sally = Paramedic.new( "Sally" )
puts "You have #{Person.instances.size} people in existance!" #POINT B
puts "You have #{Paramedic.instances.size} paramedics in existance!" POINT C

At POINT A you have two people in existence, which is correct.
At POINT B you have three people in existence, which is correct.
At POINT C you have one paramedic in existence, which is correct.

Now the “class « self” which looks mystikal really isn’t. It’s been called a classes singleton class, a metclass, an eigenclass, and the list goes on. _why gives a good description of it at http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html

The beauty of a metaclass is that one exists for every class created. This is nice because you can inherit functionality created in a parent class’s metaclass, and you can redefine implementation of that functionality if you want to. If you decide to do that your changes will only affect that class and then everything else on down the hierarchy.

These is much more POLS then class variables, and it promotes better design, testability and extendability of your code.

Rails uses class variables to implement methods like cattr_reader, cattr_writer, and cattr_accessor.

class Class # :nodoc:
  def cattr_reader(*syms)
    syms.flatten.each do |sym|
      class_eval(<<-EOS, __FILE__, __LINE__)
       unless defined? @@#{sym}
          @@#{sym} = nil
       end

        def self.#{sym}
          @@#{sym}
        end

        def #{sym}
          @@#{sym}
        end
      EOS
    end
  end
# ....

Along with the use of class variables it defines a class method and an instance method. This bothers me, because it will overwrite an instance method with the same name. cattr_ which I’ve always took for “class attribute” should NOT create instance methods. What does an instance method have to do with “class attributes|variables”? This scares me and seems like a nasty side effect for someone unsuspecting.

The Opposing View

Reading up on an opposing view, click here to read

Ola Bini writes:

“Class have instance variables of themselves, these are rarely useful; they usually contribute to hard-to-find-errors. And don’t confuse them with class variables which is a totally different kind of beast.”

I disagree with this. I think modifying class variables throughout an inheritance hierarchy which may be spread out through many files and even directories (if you’re extending someone else’s library) is much harder to track down. Essentially you have to do the equivalent of:

find ./ -type f -exec grep -Hn "@@varname" {} \;

And thats just to find where it could have changed.

Since class variables are many times accessed directly it’s easy to lose the benefits of encapsulation. One debugging benefit I find with encapsulation is the ability to alter the method where something is changed, and you can check the caller’s backtrace to see where the erroneous value is coming from in your application.

I don’t see a very good use-case for why @@classvariables are useful. I much prefer class instance variables for what I consider obvious reasons… what do you folks out there think?

Olivia Dennis, Thursday afternoon

2006-11-16T00:00:00-05:00

Nothing much going on today. After yesterday’s news we’re all so happy and we’re feeling a little more relaxed. We still have a few more tests to get through, but the good news yesterday lifted our spirits.

This morning Olivia had a nice warm bath-she loved it. She loved it so much that she decided to poop all over herself as soon as she got out so we had to wipe her down all over again!

She’s been so smiley and alert this morning. We practiced sitting up some more, and we practiced standing up tall. She’s getting so big in here!! After all that working out, she relaxed with dad and ended up falling asleep just like her daddy! It was cute.

We’ll spend the rest of the week relaxing, getting plenty of rest, and watching Olivia get better and better.

Thank God for such wonderful miracles!

Olivia Dennis, Wednesday afternoon

2006-11-15T00:00:00-05:00

Aunt Lexi came to visit last night! Olivia loves hanging out with her Aunts!

Olivia had her ultrasound done this morning. It went well; she was very smiley and cooperative. The doctor just came in to let me know that EVERYTHING LOOKS GREAT! The original problem (some kind of kink or pinch in the ureter) that caused the infection isn’t even showing up on the ultrasound anymore!! The kidney is back to it’s original size and there is no inflammation anymore. YAY!!

Although this is VERY VERY exciting, the ultrasound will still be sent to the doc in Ann Arbor to look at. Our next step is to do a VCUG (I forget what this stands for). This test will show the urine flow in her kidneys, bladder, and everywhere else it goes. They’re just doing this to make sure there aren’t any other problems that the ultrasound would miss.

I’m so happy that not only is the infection gone, but the original defect in her kidney seems to have corrected itself!! Our little miracle baby!!

Olivia was SO happy to get such good news!!

Olivia Dennis, Tuesday evening...

2006-11-14T00:00:00-05:00

Another slow day here. Olivia practiced sitting up for a while, and we read her book again but, most importantly, Olivia is getting all kinds of rest. The doc stopped in this morning to let us know that she’ll have another ultrasound of her kidney tomorrow morning. This ultrasound will be sent to the specialist in Ann Arbor. He’ll use this to determine if we can wait to see him until he comes back to Kalamazoo (Bronson Hospital) or if we need to be seen right away in Ann Arbor. He will be back in Kzoo the first week of December. Our doctor told us that we should have that situated by the end of the week.

Olivia is in the treatment room right now, getting a new dressing put on her PIC line again. All the hair she has makes it hard for the tape and glue to stick. It’s no fun for her, but I’m sure a new dressing feels so much better when it’s done.

We know for sure that we’ll be here at least through the week. Next Monday we will meet with our case manager to discuss taking Olivia home with the IV and having a nurse visit the condo.

Olivia Dennis, Monday afternoon update... posted by mom

2006-11-13T00:00:00-05:00

Things have been slow so far today… Olivia slept in late (until 9) just as a princess should. Her and dad read a book together last night-she was so interested in the pictures! She was smiling and laughing while she was awake earlier today.

For 10 days now, Olivia has been on 2 antibiotics. The doc explained them to me like this…

“One is the ‘killer’ and the other ‘intensifies’ the ‘killing’ of the bacteria. Unfortunately, the ‘intensifier’ has many bad side effects because it’s so strong. Now that we truly have the bacterial infection under control, we can get rid of this antibiotic.”

Yay… we REALLY are on our way!! It was good to hear. Today is day 10 of the 28 days she’ll need to have her IV, so we still have a while, but it’s so nice to see more progress!!

Thanks to everyone for the all the love and prayers… she’s such a fighter!

Olivia Dennis, Sunday Noon Update ...posted by mom

2006-11-12T00:00:00-05:00

Since Olivia’s sodium and potassium levels are a little off, the doc’s decided to limit how much she eats during the day. They cut her intake quite a bit; she’s allowed less than half of what she normally eats. As you can imagine, she’s not happy. She’s been screaming most of the time she’s awake-she kept Matt up really late last night.

The doctors decided to do some blood work to check on her potassium and sodium levels today, rather than tomorrow because she’s so unhappy.. we are waiting for the results on that. Hopefully, her levels have worked themselves out and we won’t have to restrict her eating again today.

Over the past three days, Olivia has been awake only a few hours. She’s been through so much and we think it’s all catching up with her. She’s so tired and she needs so much rest so she can keep getting better.

Toward the end of next week, Matt & I will decide with the doc’s where Olivia will get the rest of her treatment. Maybe the last two weeks or so of antibiotics will be done at home, by a nurse who visits the condo. This isn’t anything we have to decide right now, just another thing we’re talking about with doc’sâ€¦

Bath Time

Grandpa J

Olivia Dennis, Friday Night Update

2006-11-11T00:00:00-05:00

Today was a really busy day for little Olivia. She had two blood draws which showed that the sodium level has elevated. The doctor says that this is a reaction to the bacterial meningitis which causes her to retain fluid. We are waiting for the doctor to determine whether her food in-take and IV fluid would need to be reduced.

Olivia got a new dressing on her PIC line today which was extremely painful, time consuming and exhausting, but Olivia and Mom toughed it out together! _(see pictures below)_ Olivia is also waiting on an appointment with a doctor from the DeVos Children’s Hospital or the University of Michigan to determine the next steps for her kidney infection.

Besides the doctors and nurses Olivia spent most of today smiling and chatting with Mom today.

Changes To The Web Site

The black and gray colors weren’t really fitting to a cute little girl like Olivia, so in an effort for the web site to be more fitting to Olivia’s tastes we’re going to be changing the color themes and adding some more fitting imagery.

Olivia Dennis, Thursday Evening Update

2006-11-10T00:00:00-05:00

This posting is directly from an email I received from Adrienne todayâ€¦

”Final word on hearing test is in! Not only can she hear, she can hear great! I guess she was just ignoring us. More blood was taken this morning, they’re doing blood work daily. Doc is still trying to get in touch with U of M doctor. We brought Olivia’s swing and her boppy up here. She’s finally feeing well enough for us to put her down. She takes naps in her swing and watches TV on her boppy. We used to take her for walks around the floor to see the paintings on the wall, but she’s confined to the room nowâ€¦ bummer. She’s happy today and she just drank 8 oz at once!! She’s eating better! She also wanted me to tell everyone thanks for all her new toys, cards, and their prayers!! Talk later! xo”

</p>
</p>

More Pictures

Here is a link to Adrienne’s yahoo photo album for Olivia:
http://new.photos.yahoo.com/ayjay3636/album/576460762335295823

Olivia Dennis, Wednesday Noon Update

2006-11-08T00:00:00-05:00

Adrienne and Matt are still waiting to get the results from the Olivia’s last hearing test. The doctor stopped in today, and Olivia’s white blood cell count is down from yesterday, but the doctor still believes the infection to be active. They plan to monitor throughout the rest of the week and go from there.

Olivia Dennis, Tuesday Morning Update

2006-11-07T00:00:00-05:00

Olivia had another good night last night. She slept through the night (including the vitals at 4am)! Visitors must now wear masks in the room, so Olivia doesn’t quite know what to think of all the yellow faces yet. She’s noticed the TV, and loves watching ESPN.

The doctor said that there is no final conclusion on the hearing test yet, and he isn’t happy with the blood results from this morning. Potassium and sodium levels are up in blood which he said means that her brain is telling her body to retain water. Her white blood cell count is up again, and there shouldn’t be because of all the antibiotics in her system. He is going to contact the doctors at the DeVos Childrens Hospital and the University Of Michigan Pediatrics.

Olivia is still fighting hard, but she’s still a long ways away from recovery.

Mom would like to add, “Thanks with ALL of my heart go out to all who prayed for my precious little girl. ”

Olivia Dennis, Monday 2pm Update

2006-11-06T00:00:00-05:00

Olivia is having a super day today! The specialist who reviewed the MRI said that it looks good! Adrienne said she slept SO hard last night, and she is super happy and awake today.

The first doctor who did a hearing test today said everything was looking good. There will be a second doctor who will have results sometime Tuesday, but things are looking up.

Please continue to keep Olivia, mom and dad and the doctors in your thoughts and prayers.

Olivia Dennis, Week 1 Hospital Pictures

2006-11-05T00:00:00-05:00

Olivia is doing good today. She had some restless sleep last night, but she’s been awake and smiling so far today! Tomorrow should be a pretty busy day. We’ll have the following:

Olivia will get a hearing test
Olivia will find out about her MRI from the pediatric radiographer
Olivia will get some more blood work done

Here are some images from the hospital this last week.

Olivia Dennis, Saturday Midnight Update

2006-11-05T00:00:00-05:00

Olivia had a pretty good day today. Her temperature was below 100 degrees all day and she had lots and lots of visitors. From Grandma’s and Grandpa’s to Aunts/Uncles to friends and people she’s never met before.

Her MRI got pushed back a few hours, and it took up to three tries to get her sedated (she’s a tough little girl) but the doctors ended up getting it done. The results from the MRI won’t be in for a day or two though depending on when the special radiologist for Olivia is in next.

After the MRI, Olivia was still pretty sleepy from the sedation, but she woke up for Mom not to long after happy and smiling. She thought about going back to sleep, but decided she was hungry and ate alot!! 6.5 ounces!!!!!

A nurse tested her hearing today and although Olivia didn’t respond to the hearing test, when her Dad came in the room tonight and spoke, her head tilted right in his direction. Right before I left Olivia had taken two laps around the pediatrics floor with her Dad and she was in awe of the lights and the colors on the walls.

I’ll post pictures of Olivia from this week at the hospital tomorrow. As always, continue to keep Olivia, her mom and dad in your thoughts prayers, as well as the doctors treating her.

Olivia Dennis, Saturday Noon Update

2006-11-04T00:00:00-05:00

Olivia is doing good today. The second spinal tap from yesterday afternoon relieved some pressure in her little body, and she was able to get a good night’s rest. Today she’s going to be getting an MRI, and she’s not allowed to eat for quite a few hours leading up to it. You can imagine that she’s quite hungry, so she goes back and forth between crying and sleeping.

As you keep Olivia, her mom and dad in your thoughts and prayers, please do the same for the doctors treating little Olivia.

Olivia Dennis, Meningitis

2006-11-04T00:00:00-05:00

My niece Olivia Dennis is in the hospital right now. She’s eight weeks old and has been diagnosed with bacterial meningitis. The doctors are not 100% sure of the diagnosis, but they are leaning towards the worst form of it. She’s had two spinal taps, a ctscan, an ultrasound, and several draws of blood. She’ll be in the hospital for the next 14 to 42 days.

Please keep Olivia and her mom and dad in your thoughts and prayers.

Fixing Sound on eMachines M5405

2006-10-29T00:00:00-04:00

While working on my sister’s laptop (eMachines M5405) tonight I noticed that I couldn’t hear any sound coming out of it. The fix was simple. In KDE, load up KMix and select the Switches tab and disable the External Amplifier, and it should work fine.

Finder Extensions and MySQL Fulltext Indexes

2006-10-29T00:00:00-04:00

ActiveRecord::Extensions has been turned into a pluggable extension registry to support better finder methods across multiple database platforms more easily. Very little ActiveRecord::Base code actually gets touched now. ActiveRecord will now query an extension registry and if an extension can answer the request it will take the result otherwise it will default to ActiveRecord’s original behavior.

The API interface that developers use is still the same, it’s just the underlying architecture that changed.

Extension Example

Here’s an example which is pulled straight from the source. It adds Range support for ActiveRecord find methods.

# EX: Model.find :all, :conditions=>{ :number => (1..100) }

# EX: Model.find :all, :conditions=>{:created_on => ( Date.today â€“ 30 .. Date.today ) } 
class RangeExt < AbstractExtension NOT\_IN\_RGX = /(.+)\_(ne|not|not\_in)/ def self.process( key, val, caller ) if val.is\_a?( Range ) match\_data = key.to\_s.match( NOT\_IN\_RGX ) key = match\_data.captures

if match\_data fieldname = caller.connection.quote\_column\_name( key ) min = caller.connection.quote( val.first, caller.columns\_hash[ key ] ) max = caller.connection.quote( val.last, caller.columns\_hash[ key ] ) str = "#{caller.table\_name}.#{fieldname} #{match_data ? 'NOT ' : '' } BETWEEN #{min} AND #{max}" return Result.new( str, nil ) end nil end  
end 

register RangeExt, :adapters=>[ :mysql, :postgres ]

All an extension has to support is the process method which takes the key and val from the :conditions hash, and it gets the context of the caller passed in (the AR model).

Once you create an extension you can add it to the ActiveRecord::Extensions registry by calling the register function on ActiveRecordExtensions. This code is called in the context of ActiveRecord::Extensions so the register function is available. This takes an array of database of adapters which are supported or the symbol :all.

This should open up ActiveRecord to receiving better finder support without having to hack up ActiveRecord itself since it’s pluggable.

MySQL Fulltext Indexes

Fulltext index support has been added for MySQL.

Example

class Project < ActiveRecord::Base fulltext :title, :fields=>%( project\_name project\_description )
end 
Project.find :all, :conditions=>{ :match_title=>'query string' }

Boolean and Query Expansion based fulltext index searches will be supported _(they are not committed to trunk yet)_ . It is not concrete whether these will be supplied via the declaration, the :conditions hash or allow to be supported by both.

This Ain’t Released Yet

Right now these changes exist in trunk. You can download them by visiting the rubyforge project page

These should be out in a 0.0.6 release later this week.