For over a decade, we have spent millions of hours building the largest encyclopedia in human history. Right now, the U.S. Congress is considering legislation that could fatally damage the free and open Internet. For 24 hours, to raise awareness, we are blacking out Wikipedia. Learn more.

A couple notes on BDD testing :

1. Never test “the glue”. “Glue” means anything that Ruby or Rails should be doing “automatically”. That means, database querying, sending values from controller to view, etc. So, in a view test, you should be able to adequately test your views using the isolated view tests. This is where you could test that your table-building code is working right as you expect. Your controller tests should be able to be tested without database requests (mocking model instances), see #2.

2. Skinny Controllers, Skinny Views. Make your controller code, and your view usage as absolutely minimal as possible.
The ideal controller method looks like :
def show
respond_with @some_record
end

Yes, THAT SMALL. Rails framework provides a HEAP of assistive methods to accomplish that. #before_filter, #after_filter, #respond_to

Views should contain very little Ruby code. #render :partial and generous use of Helpers allows your view code to be very small (and subsequently, very testable). Repeatable elements like table-rows should be in partials, where they are easily testable.

3. Cucumber-level testing : Are you using Cucumber (http://cukes.info)? Cucumber scripts should really be reserved for “business owner specification”. A business owner would not usually be concerned with error handling or the exact placement (or even widget-type) of elements on the forms. The Business owner instead is interested in knowing that Page A => Page B => Page C works… or for instance, “If I buy product “Widget Sharpener”, then my shopping cart counter increases to 1 “

There is a general BDD/TDD work cycle :

Create cucumber feature
Code supporting Cucumber step
Cucumber-RED : Cucumber execution fails because step causes failure in model/view/controller
Match expected functionality in model/controller/view RSpec
RSpec-RED : Rspec execution fails because functionality is not implemented
Modify model/view/controller with added functionality
RSpec-GREEN : Rspec now succeeds
Cucumber-GREEN : Cucumber now succeeds

You will often find steps 5-7 (Rspec Red/Green cycle) will repeat several times between Cucumber Red/Green cycles. This is our minute-to-minute Ruby-programmer’s work experience.

I’m looking forward to hearing more from you of your experience learning Ruby and Rails.

How the bot will wait to return with its bounty until I clap!

Part 3 of my series on migrating from NXT-G 1.0 to 2.0. TriBot – Grabber.

With these steps, the model is complete ready for the next step!

Continuing with the NXT-G 1.0 TriBot Series, here is Part 2 – Bumper

The Lego Mindstorms NXT 1.0 building instructions are found at Mindstorms Support 8527 -TriBot

So, without further ado, here is the Programming Guide for the Lego Mindstorms 1.0 TriBot : Part 1 – Driving Base

M$ turned up the heat over the last week, and seemingly put it to HIGH yesterday.

Ian Ringrose simplified the discussion :

“Is it safe for me as a developer without a large legal department to work with Microsoft technology? “

FransBouma says : “Nail on the head.”

Yes… Nail on the head.

His father recalls seeing a small girl of 5 or so and realizing that she will likely die from radiation, hunger, or injuries.

“That’s War”, he said, ” and that’s why I hate it.”

 Agreed 100%.

Ok. Spent too big of a portion of last year FIGHTING with Micro$oft VS .NET 2003/2005 and trying desperately to show that my dying VB6 apps can be converted to them. Well, conversion doesn’t work, at least on my KLOC applications with major hacks embedded for unit testing and robust error handling.

Found the Rails in Feb 05 and basically “didn’t look back”. It took ‘till Nov 05 to get approval for the first app, and we were desperate. Success rate on that was HIGH as my off-the-cuff estimate “It’ll take 1 to 2 months” was right on target. Deployed critical-features version of app for public consumption at end of Nov. and then deployed final feature-rich (to the level that this rewrite needed) at end of Dec. Managers happy. Uesrs happy. Application admins (tech-support staff) happy. CODER HAPPY

I can’t say I”ve ever felt “Happy” coding in M$ anything. Always a catch, always a missing feature. Always a black box to deal with. Always some reason to spend 2 days googling and searching M$ forums for obscure answers.
Also, no support, unfriendly forum users, unhelpful forum “experts”.

I continue to hash around the balance between the pros and cons of this argument. It seems really clear on paper which is the better choice for continuing development… UNTIL the emotional ties to employer-loyalty, cost conciousness, time conciousness (both calendar time and timecard time) all get in the way. I have also voiced the concern to coworkers that with all the money M$ uses for VS development… how can it NOT be better??!!

In the final analysis, M$ CAN “not be better”. The 800lb Gorilla has lots of hair to shed and leaves a VERY large footprint.

With Ruby and Rails, my experience in learning curve was that the curve was low and short. Peaking the hill of learning these technologies was manageable, doable. Even without learning how to flex the technologies (I still don’t grok the metaclass), I have been able to overcome some serious design hurdles with the convenient flexibility of Ruby and the Rails framework.

Looking up, I notice ONE bolded phrase

CODER HAPPY

The reference… Ruby and Rails.

Hm..

I have an approved rails app to work on.

coder team alpha Out!