STOP SOPA

From Wikipedia on STOP SOPA DAY

Imagine a World
Without Free Knowledge

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.

BDD/TDD test cycle for beginners

I sent this message to a RailsMentor Protege of mine :

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.

Lego Mindstorms NXT-G moving from 1.0 to 2.0 – TriBot : Part 1

I discovered after installing Lego Mindstorms 2.0 NXT-G software that no one on the interwebs has captured this information before.

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

FUD all over again… This time with Testing!

Well, Jamie Cansdale has been getting heat over time from M$ over TestDriven.Net, formerly NUnitAddin.

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.

Happy Coding or Status Quo

… This presentation brought to you by Brains on Trains—The leading supplier of hosed-up thought processes.

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!