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.

Brown Shoes Introduction

I will be writing about lessons-learned as I move through
the implementation of Shoes on Jruby.. known as Brown Shoes.

Repo – What’s what where

The Brown Shoes Repo is at : https://github.com/shoes/shoes/tree/brown_shoes – a branch on Shoooes Github project.

Right now there are two parallel implementations within
the brown_shoes branch.

At ./lib/shoes is the Eclipse SWT Library implementation.
This is using the expected event-loop main-display and
native SWT widgets.

At ./lib/brown_shoes is the Java/Swing implementation.
JFrame, JPanel, and a bit of AWT as necessary.

There are some issues found on the Pivotal Tracker for
Brown Shoes https://www.pivotaltracker.com/projects/444909

We need your help!

There are details about running SWT or Swing apps that
completely befuddle the newbie in this Jruby/Shoes
business. (namely.. ME!)

If you are a seasoned Jruby, Java/SWT, Java/Swing… or
maybe just JAVA developer, and have interest and a few
hours to spare, your expertise would be GREATLY
appreciated.

Who’s up for a fun challenge that will help Kids learn
Ruby – Hackety Hack runs on … Shoooes!