Planet PDX.rb

I have been getting absolutely slammed with stupid drug spam. Mephisto’s spam moderation stuff is pretty good, but the sheer volume required me to go down to the console to take care of the problem:

1
2
3
4
5

regex = /viagra|cialis|xanax|levitra|tramidol|valium|\
carisoprodol|tramadol|nexium|ultracet|allegra|\
zoloft|hoodia|snitz|ultram|levaquin|augmentin|\
prednisone|phentermine|fioricet|diethyproprion/i
Comment.find_all.select {|c| c.body =~ regex}.map(&:destroy).size

I was building the regex as I went along so I don’t have an exact count, but that probably deleted 500 comments. Much easier to moderate the other crap now.

Working into the evening on a client project (been sick and trying to play catchup) and was chatting with Allison about working in views and dummy text. I said, “Just make that a shortcut in TextMate.”

Then I thought, “I can’t be the first person to think of that.”

...as I type, lorem [tab]

Figures. Lorem ipsum generator… in TextMate. Why didn’t I know about this before?

So, I ask all of you… what’s your favorite TextMate trick?

Lately… I’ve been enjoying running single spec files with [apple]-r.

Dear readers,

Yes, I’m still alive. I’ve been insanely busy at my new(ish) job with LAIKA Inc, where I’ve been slinging Ruby since December. More about that later. I’m working on preparing a library I wrote at LAIKA for release, but until that’s finalized, I should probably keep it under my hat.

Also, I’ve set up rewrite rules to redirect my feeds to FeedBurner, inspired by Geoff’s recent post on the topic. If you notice anything funky about the feeds, please let me know!

I love to look at other peoples code. Initially, that’s what got me excited about Open Source software. Otherwise, I was looking at small snippets on various developer sites and really not getting the complete picture for how everything tied together.

Last night, I finally had a chance to checkout the sample caboose application, which was created as a way for people to get an idea for how some of developers in caboo.se are putting together their applications.

Some things that you might want to check out it’s using…

• RSpec
• RESTful Authentication
• TzTime
• SpiderTest

It’s definitely worth taking 15 or so minutes to check it out and get some fresh ideas.

There are a few things that I’m not quite sure that didn’t quite make sense, so… perhaps I’ll submit a patch. :-)

svn co svn://caboo.se/plugins/court3nay/empty_apps/tags/v_003

Have fun!

Well, I made it about eight months since I got my new hard drive... and today… I had to run…

sudo port -v install mysql5 +server

Why? I have to migrate some data from MySQL to PostgreSQL.

I still believe that Behavior-Driven Development is kinkier than Test-Driven Development...

I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.

“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”

I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.

Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.

Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?

“I thought that we paid you to fully test the code?”

Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.

What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.

Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!

IT’S OKAY TO FAIL! (some of the time…)

“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”

As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.

I’ll end this with a few questions, which I hope that you’ll share your experiences about…

• In what ways is your team embracing the failures of your development projects?
• How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?

We have so much to learn…

After re-reading Nat Pryce’s Scrapheap Challege writeup, I tried to see how easily I could answer a simple question with only lynx, grep and friends. It turns out to be even simpler than I suspected. For example, the following tells me that my average blog post receives 2.2 comments.

# iterate through 17 pages
page=1; until [ $page -eq 17 ] ; do
  lynx -dump "http://www.jvoorhis.com/articles/page/$page" | \
    egrep "([[:digit:]]+|no) comments?" | \
    sed -e "s/\[.*\]//g" -e "s/no/0/g" | \
    awk '{print $1}' >> comments.txt
  page=$(( page + 1 ))
done
avg comments.txt 

Two days ago, I discovered Module#method_added lurking about in the DRP library. Today, let’s take a look at what it does, along with an example implementation of multiple dispatch for Ruby objects.

Module#method_added accepts one parameter – a symbol allowing us to reference the method that was just defined in a class or module definition. We may do a number of things with only that method name – inspect the method, rename it, change its scope, or – in our case – register it with our multiple dispatch system.

The following code is both crude and simple: it allows us to define multimethods based on their arity, and does not support optional arguments or variable-length argument lists. It also only takes hold within the multi do ... end block. With a little extra work, the multi block could be eliminated, and missing features could be added. What is noteworthy is how reflective callbacks such as Module#method_added and Class#inherited make it possible to use the Ruby language to extend the Ruby language.

module Multi
  module Arity
    def method_added(name)
      if @__multi_def__
        @__multi_def__ = false # Disable method_added behavior while aliasing
        arity = instance_method(name).arity
        @__multi_methods__ |= [name]
        class_eval "private :#{name}; alias __multi__#{name}__#{arity} #{name}" 
        @__multi_def__ = true
      end
    end

    def multi
      @__multi_methods__ = []
      @__multi_def__ = true
      yield
      @__multi_def__ = false

      @__multi_methods__.each do |name|
        define_method(name) { |*args| send("__multi__#{name}__#{args.size}", *args) }
      end
    end
  end
end

if __FILE__ == $0
  require 'test/unit'

  class Example
    extend Multi::Arity
    multi do
      def hello
        "Hello, somebody" 
      end

      def hello(name)
        "Hello, #{name}" 
      end
    end
  end

  class MultiTest < Test::Unit::TestCase
    def test_dispatch
      ex = Example.new
      assert_equal "Hello, somebody", ex.hello()
      assert_equal "Hello, multimethods", ex.hello("multimethods")
    end
  end
end

Inspired by the eigenclass language generator, I’ve thrown together an example of how it would be implemented with the Directed Ruby Programming library. Directed programming is an interesting hybrid of genetic programming and the recently discovered grammatical evolution technique which generates a program tree according to a grammar.

This example may not be very interesting for those familiar with evolutionary programming techniques, but it created a fun diversion, highlights how the DRP library is to be used, and shows a different solution for a language generator.

class DrpGenerator
  extend DRP::RuleEngine
  begin_rules
    def main() "#{hello}\n#{ex1}\n#{ex2}" end

    def hello() "Hello, #{somebody}!" end

    def somebody() "matz" end
    def somebody() "world" end

    def ex1() "This is a more #{adj1} #{example}." end

    def adj1() "complex" end
    def adj1() "elaborate" end

    def example() "example" end
    def example() "test" end

    def ex2() "Some simple sentence." end
    def ex2() "Another, involving harder stuff." end
    def ex2() "Another, involving a more complex #{exp}." end
    def ex2() "Yet another possibility; each one is chosen with an evolutionary algorithm." end

    def exp() "expression" end
    def exp() "disjunction" end
    def exp() example end
  end_rules
end

g = DrpGenerator.new
3.times { puts g.main }

Hello, matz!
This is a more elaborate example.
Another, involving a more complex disjunction.

Hello, world!
This is a more elaborate test.
Another, involving harder stuff.

Hello, world!
This is a more complex example.
Yet another possibility; each one is chosen with an evolutionary algorithm.

My DrpGenerator isn’t as readable or attractive as the eigenclass DSL, and multiple definitions of the same method will likely confuse most Rubyists at first glance, but makes it easy to see the underlying grammar.

We've been working on automaically picking colors from a logo image, and I wrote it up here on the Dabble blog.

This morning was delightful. I woke up to find that 37signals had referenced our website on Signal vs Noise this morning. In particular, they referenced the Rails hosting order form on the PLANET ARGON site. What’s interesting is that Allison created this design over a year and a half ago.. and we’re actually in the process of a complete site redesign, which Chris and Allison are planning to blog about in depth. :-)

There are some discussions within the comments on the blog post about the design decisions that were made, some of which we’ve already begun to address in our redesign process brainstorming (based on google analytic conversion data).

On top of that, today is our Experience Director, Allison Beckwith’s, birthday.

Thanks for the linkage, 37signals!

...and… Happy Birthday Allison!

I’ve been working on a project with Graeme, and we’re spending some time cleaning up some RHTML views.

He posted an article earlier, titled, Dirty Views? Clean them up!, where he asks the following.

“I am also looking for more information on best practices with views in Rails. There doesn’t seem to be much information on the subject.”

We’re starting to re-evaluate how we approach our views and are curious what other teams are doing… especially if you have a team thats approx 1/2 designers… 1/2 developers per project. We’ll be reviewing some of the other options for the View layer over the coming week(s) and welcome any suggestions/insight to this area of Rails… head over to Graeme’s blog and share your thoughts. :-)

So, the Microsoft Technology Summit started today, which I was invited to. I had to cancel my trip late last week so that I could help out the design and development team out on a project that we’re wrapping up. Our office has had some colds going around, so I’m putting in some extra time to help out.

If you were hoping to meet up with me on one of these evenings, I apologize. I may be heading up to Seattle in the coming weeks anyways and if you sent me an email, I’ll let you know when I am planning to.

To those at the MTS… have fun and keep us posted on what happens!

It’s been five days since I posted my initial review of Highrise, that shiny new application by our friends at 37signals. I’ve been getting adjusted to my new process of managing contacts and have had to remind myself a few times that there is a brand new tool that aims to make my life a little easier.

Contact Form Integration

I haven’t heard about a Highrise API available yet, but I will definitely be looking into tighter integration once that is available.

Direct Submissions (not yet)

It seems that Highrise isn’t going to allow direct emails to be sent to it, they need to come from an existing contact in your account. For example, our contact form sends an email to our customer service mailing list. At one point, we had it connected to the Basecamp API to submit each new contact request as a new message in a designated project, but it didn’t really give me what I was looking for. Since each user in Highrise has a custom dropbox email address, I thought that I would try to link up the contact form to submit directly to Highrise.

I got the following response back from Highrise. ;-)

Hi Robby- An email was sent to your Highrise dropbox from john@cusackforpresident.com. This address does not correspond to any address that you have recorded for yourself in your Highrise account, and so the email was discarded.

So, in the meantime, I’m following this process with new contact requests as well as the other people at PA who are responsible for responding to Contact Requests.

Contact Request Submission

So… let’s say that John Cusack (one of my favorite actors while growing up) is having a weird dream and wants to get a website built for the record store that he ran in High Fidelity.

He fills out the form and submits it, which our application than stores and also sends over his contact information to our customer service email address.

A few minutes later…

Manually Review in Mail.app (and apply 2-minute rule)

Here I am in Mail.app and doing a double-take… “is that the real John Cusack?” (no, it’s just test data).

I then ask myself the following questions…

• Can I answer this in less than 2 minutes?
  • If yes, respond immediately (forward to Highrise, if contact info will be needed again)
  • If no, forward to Highrise

Okay, so I’ve decided to forward this contact to Highrise as I decided to go ahead and speak with John over the phone, since he was kind enough to leave his phone number.

As I mentioned in my last post, I’m using Act-On for forwarding emails to Highrise.

(back-tic h)

...and off the email goes.

View/Edit message/contact in Highrise

I’m now logged into Highrise and looking at my dashboard. As you can see, John Cusack is now at the top of my dashboad and waiting for me to decide if I want to do something with it.

Schedule Follow Up tasks

As I mentioned, I spoke with John over the phone and promised him that I’d send him a follow up email with a proposed date/time for a meeting next week.

...and that’s one way that I’m now using Highrise to getting all my contacts organized.

Five Day Review

Well, after five days of using Highrise, I’m still impressed with it. Our Administrative Assistant began using it last Friday and is using it to schedule follow up tasks for me. This definitely beats the old process of leaving post-it notes on my desk with names and phone numbers. :-)

We also upgraded to a paying account and paid for invoice #4.... and I plan to hit contact #200 later today within our account.

A few bugs:

• Forwarding email from Thunderbird doesn’t currently work (as of last Friday)
• A few forwarded emails from Mail.app didn’t work right (garbled… html emails perhaps?)

Also… it appears that 37signals has opened the doors to the public earlier today.

Have fun!

So, today I got what I’ll call a platinum ticket from one of our pals at 37signals for their upcoming new application, Highrise, which is what they’d call a “shared contact manager.” The rest of you can keep hoping that you’ll win a golden ticket this weekend. ;-)

For the past year and a half, I’ve been wanting to build some sort of contact and task management tool for organizing all of the contact requests that PLANET ARGON receives about our Design and Development and Rails Hosting services. If I go away for a week, I come back to a huge backlog of people who may be waiting a response from me. Having a tool to allow others at PA to see what is in my queue and in some cases, respond on my behalf… has been needed. When I first heard about Highrise long ago, I got excited and have tried several different tools and each of those tools has left me feeling uneasy. Perhaps I’ll post some reviews of the other tools one day.

First Impressions

The signup process looks familiar… :-)

Look and Feel

Well, it definitely looks and feels like a 37signals application. There might have been a time when I thought that would be silly… but really, when you look at other product suites, consistency is extremely important to the user experience. While they are definitely going to attract people to Highrise who have never used any of their other products, I’d also expect a huge majority of their initial customers will be users of their other products. It’s obvious that Highrise was in response to a void in the market that people (likely customers) were asking for in other products like Basecamp.

Highrise has all the Ajaxy goodness that you’d expect in a brand new modern web application. Most of it seems very intuitive, but I found myself getting caught up on the extra tabs across the top of the screen. When new tabs appear, my natural response was to try to close them when I was finished looking at the page. Perhaps this is just a design decision that I’ll learn to really like. At the moment, I’m still not quite sure because I expect the tabs to change quite frequently.

(few minutes later)

Actually… I wonder if the interface designers at 37signals did this to help their users avoid having several tabs open in their web browser. I use Safari for Basecamp and generally have 5-8 tabs open throughout the day for different projects that our team is working on because the Dashboard view doesn’t really give me a good feel for what is happening throughout the day on our various internal and client projects. I’ll try to pay attention to my usage habits to see if I’m opening less browser tabs in Highrise.

So far, this is the one thing that I’m not quite sure about (yet).

Highrise meets Act-On

Once I saw that you could forward emails to Highrise and it’d auto-magically create a contact and store it, I jumped for joy (not literally… but I got an evil grin). I have been using (more like heavily relying on) Mail Act-On for what seems a really long time. I’m constantly forwarding emails off to my colleagues to keep things from sitting stagnant for too long. So, guess what I did?

This is working beautifully and allowed me to move about 20 contact requests to Highrise in just a few minutes.

With this new ability, I can remove that one project in Basecamp that I was using to collect contact request information. That information now has a proper home!

Manage your Peeps

I’m taking more screenshots and going to continue putting more of our contacts into Highrise… so… consider this part one of a short series of posts.

To be continued…

InformationWeek has a short story titled, Poor Communications, Unrealistic Scheduling Lead To IT Project Failure.

“Communications failures top the list of reasons IT projects fail, according to poll results from the Computing Technology Industry Association.

About 28% of 1,000 respondents identified poor communications as the main cause of project failure, according to CompTIA, which offers project management training.”

So, while we’re all spending so much of our time focused on improving our technical skills, are we also investing our time into becoming communication superstars?

If you look back at the following posts, you’ll see some links to some excellent books on this topic.

• Project Enlightenment with d3
• The Technology of Dialogue
• Those that Tend the Store need Dialogue

After kicking myself all weekend for not heading to SXSW... was getting ready to head to sleep last night and saw a post by Michael Buffington announcing that Stikkit won an award for Best Technical Achievement.

Congrats to Rael, Michael, and the rest of the Stikkit team!

As mentioned a few weeks ago, I’ll be up in the Seattle area in a few weeks. I took the invitation to head to the 2007 Microsoft Technology Summit in Redmond, WA. When I received the invitation… my immediate response was, “Why me?”

Their response?

“The event is specifically for people other than Microsoft fanboys… they want to have a dialogue with influential members of the developer community outside of their comfort zone to see what we can learn from each other..”

Fair enough. Perhaps they’ll convince me to switch our entire team to Microsoft products… but I highly doubt my team would be cool with that. ;-)

It looks like Michael Koziarski (of Rails Core fame) will also be at the event. Supposedly, there will only be 50-60 people… so if you’re also going to be there, let me know.

I’m not sure what to expect yet from the event and they don’t have a web page dedicated to it. The most that I could find was a few blog posts from attendees of previous years. I plan to do some blogging during the event to share my experiences (good and bad).

p.s. thanks to those who invited me to have drinks/dinner while I’m staying in Bellevue. I’ll be responding to your emails in the next week. if you’re interested in meeting up, drop me a line.

It appears that Seth Godin is catching on to the concept of Dialogue.

Seth writes, “Some organizations are good at listening. Some are good at talking. A few are even good at both.”

I’ve been spending a lot of time thinking about how I listen to clients, employees, friends, and family. All of our relationships are a series of conversations. Sometimes we can have healthy dialogue, sometimes we just fall victim to debate. (see Dialogue vs Debate)

If you’re really interested in Dialogue, I’d encourage you to review the technology of Dialogue... and check out the Dialogue-Driven Development project and introduce yourself.

Not that I expect this to impact a lot of people or anything, but I wanted to let the intertubes know that I’m in the process of migrating services to a new machine. This may mean some downtime for bleything.net webservices (including this blog, the george demo, etc) as well as subversion and trac.

Also, I cut over my email services Friday morning, but hosed the config on the new box. If you emailed me and it bounced between about 7 and 10 PST Friday, it’s because I’m a biig idiot. Plz to re-send.

While reviewing some articles related to small business management, I came across the following post… titled, Note From Boss to Employees, by Michael Wade. As a young business owner, who only 16 months ago was working in his attic… to now trying to figure out how to run a company with over ten employees (and growing), posts like this remind me that we all have so much to learn. :-)

Here are a few that I appreciated…

“I may not have been given a huge amount of training before being named to a supervisory position. As a result, I’ve had to learn through trial and error. That’s not always bad. Many of my responsibilities can only be learned through practice.”

Yep… that’s me! The only difference is that I promoted myself instead of being promoted by someone else. I’m still not sure what I got myself into sometimes. ;-)

“I will make mistakes. Please give me the same understanding that you’d like me to give you when you blunder.”

This reminded me of a blog post from last year, titled, Avoiding the most common software development goofs, which points out that things like ignorance and stress are often to blame for mistakes in development. I feel like these are reasons for goofs in just about any environment, especially business. Let’s face it. We’re not perfect and we’re going to make a lot of mistakes. Once we’ve agreed on this, let’s take the next step and see what happens.

“If I do something dumb or am on the verge of doing so, please tell me. Don’t hint. Tell me.”

Perhaps this is a common problem for most small business owners. Are employees afraid to tell me that I’m doing something dumb?

“If either of us has a problem with the other’s performance, let’s talk about it.”

As they say, real friends will be honest with you about your faults. Not because they want to make you look bad, but because they care.

Each of the points that I have listed here are pointing to is… healthier Dialogue, which is always a challenge to accomplish… in any relationship… whether with clients, coworkers, bosses, or employees.

I’d like to add a few to this list.

• It’s easier to ask for forgiveness, than to ask for permission.
• I’m still trying to get the hang of this GTD stuff, so.. you might remind me if I forgot something.
• Ask yourself on a regular basis, “Am I having fun?” If not, make time for some.
• Please make fun of the boss! :-)

“Showing up on time …with a smile on your face is almost always more important than what you actually say or do.”—Seth Godin

overhead here...

...overheard on an internal forum…

“My my passion for nifty server tricks will blow peoples minds”—Daniel Johnson

Okay, this is a little overdue… but better late than never! ;-)

We’ve had several new people start with PLANET ARGON over the past few months. Some of them are blogging about their experience of working with Ruby on Rails and being a part of our team. I wanted to quickly introduce you to a few of them and their blogs, which I hope that you consider subscribing to.

Chris

For quite some time, we’ve been needing more design assistance, so late last year… we hired Chris Griffin, who moved here last year from Florida. He’s our new User Interface Designer and gets to work within the Rails environment everyday with the rest of us. It seems that Brian and Chris worked over the weekend to get his new blog up. Chris is self-proclaimed genius. I suggest that you keep an eye on his blog… because I’m sure it’s going to be a pretty active one. Chris joining our team marks a pivotal point in our teams evolution as we continue to place more emphasis in our Design and Development process on the User Experience.

• http://chriszgriffin.com/

Graeme

Our newest hire is Graeme Nelson, who recently moved to Portland from Seattle. He just joined our Design and Development team and if you’ve been reading the Rails-related blogs, you might have seen his blog already. He’s been blogging a lot about using RSpec with Rails and other fun things. He’s been contracting with us since the start of the year and I’m really excited that he’s accepted a job offer and joined the team!

• http://blog.imperialdune.com/

Gary

Last… but not least is Gary Blessington. I believe that I first offered Gary a job with PLANET ARGON about 2 1/2 years ago when we were still focused on PHP/PostgreSQL…. but PHP apparently wasn’t enough of a catalyst. Gary and I previously worked together at Imark Communications several years ago, when I first started doing web development. He was the senior developer on the team and was an important mentor during my early days of developing in a professional environment. Late last year, he hung up his .NET tool belt to become our Design and Development Director. He started blogging earlier this year and is sharing his experience of switching from .NET to Ruby on Rails.

• http://garyblessington.us/.

I’ll introduce the others as they start blogging and such. :-)

I’m going to be hanging out in Redmond, WA. late next month… why? That… I’ll explain at a later date. ;-)

What I can say is that I’ll be available on a few evenings if anybody is interested in meeting up to talk shop, which can include anything from d3, ruby on rails, bdd, agile interaction design... to BBC comedy shows. :-)

I’ll be flying up from Portland to Seattle on Saturday, March 24th. I’m going to try and stay downtown for that night… and then will be staying at Sheraton Bellevue until Tuesday night. So… Saturday-Monday nights are currently open.

I’m also planning to head to the monthly Seattle.rb meeting on Tuesday, March 27th.

If you’re interested in meeting up, drop me a line.

UPDATE If you’re taking the kinky aspect of BDD too serious... please don’t email me. ;-)

Recently, Seth Godin posted a short blog post, titled, Apologies, ranked, which points out several ways of apologizing. When you work in a service industry, it becomes very important to develop good apology skills. Let’s be honest for a moment. Not everything works out for the best in every customer experience. Sometimes it’s their fault and many times… it’s our fault.

In response to Seth’s post, Marc Chung has written up a similar post that adapts this to software bugs, titled, Seth on Fixing Bugs.

It’s worth a read and definitely relates to the communication issues that we keep talking about within the Dialogue-Driven Development community and how that can translate to a healthy testing process with BDD.

Thoughts?