Thursday, November 27, 2008

The Evolving Web

In the beginning was dirt. Lots of it. Dirt was handy. You could stand on it. You could grow food in it. You could take a stick and scratch it.

Scratch the right things the right way, agree on the meaning, and you and your buddies could communicate. Leave a record of things. This was the first internet.

Didn't work that well.

The first breeze that came along messed it up bad.

Second, you all had to be there, looking at the scratches. Rather than sending the message around you sent the recipients. Awkward. But technologically promising.

Next came tablets. Wax. Clay. Stone. Time marched on. Tromp. Tromp.

Papyrus came and went. Then parchment. Quill pens had their day. Change was the one constant. Things had gotten beyond a few pokes with a stick. No longer could you do your tax return with a twig and a gob of clay.

Then the printing press. Mass communications. Industry. Engineering. Factories. Communication got easier in a way but it needed an infrastructure. Someone had to design type, melt metal, then set type and run presses, which had to be built first, but somehow this worked out. There was a division of labor. Specialization.

At one time only the richest, most privileged in society could read and write. Arithmetic was a university subject. Now they are all learned in grade school, and today it takes more than reading and writing to secure a fat career.

In the mainframe days you needed a Ph.D. to be a computer programmer. No, seriously. You had to plan carefully, and write down a bunch of ones and zeroes and feed them into a reader which programmed the computer, and then you got paid. A lot. Because no one else could do that.

Eventually programming languages were invented, and so on, and things got easier in a way, but not much. If you got inside the system you were set for life, just like in the old days.

Then, desktop computing came along. Revolution.

Back to the wild west. Anyone with time on their hands could do neat things. Not useful things but neat ones. Then they broke down barriers, overwhelmed the world, and made mainframes irrelevant.

Eventually those desktop toys got networked, and multi-tiered client-server systems came along, and remote procedure calls, and methodologies, and object orientation, and GUIs and IDEs and all that, and pretty soon you just about needed a masters degree to get a job again.

And then there was this web thing.

Put in a couple of weeks learning HTML, then start a new business. Couldn't do much, but it looked neat. Kind of a joke, really. The real computer people were not afraid.

First HTML, and then CSS were all you needed.

And then Photoshop: HTML, CSS, Photoshop. Period.

And graphic design.

Digital photography. Typography. Project management, iterative development. JavaScript. Ajax. Flash. Flex, C#, PHP, Ruby on Rails, HTTP, FTP, REST, CVS, SVN, Git, Python, Perl, XML, XHTML, Apache, IIS, Nginx, lighttpd.

And so on. A blizzard of technologies.

The web is mature. No longer a joke. Mainstream now. Desktop stuff folded into the enterprise black hole along with mainframes, and you can't make a living coding up web pages after work any more.

The web is now complicated and many faceted. It has complex interfaces. It is dynamic. It requires real programmers, user interface designers, usability engineers, test driven development, behavior driven development, design driven development, aspect oriented programming, scripting languages, frameworks, graphic artists, graphic designers, and a bunch more, depending on what the point is.

The early days are gone. We're well into the next wave. What it takes now, to get a solid web site built, and to keep it running, is professional help.

Luckily there is more professionalism in the industry these days. People with chops. People dedicated to producing and maintaining great sites. People who are sharp. People who have put in their time. People who will come through no matter what. Capable and committed.

So there's hope.


References:

Bertrand Meyer at ETH
Meyer's Introduction to Programming course and "Touch of Class" textbook
PDF of "Touch of Class" draft from 2004


Wednesday, November 19, 2008

A Message From Batman


While I think of something substantial, like a review of Obie Fernandez's "The Rails Way", here's something I found at "Made in England by Gentlemen", who found it at "Wavish Industries".

And, sad to say for all of us, this is all there is.

References:

Made in England by Gentlemen

Wavish Industries


Wednesday, November 05, 2008

Test Me On The Rails

I have a set of news sites I visit every day. I never know what I'll find, and usually I do.

On checking "RubyFlow" for November 04, 2008, I saw the following
We've stopped using RSpec... say Rails development team ENTP. They're now back to Test::Unit but improved with Jeremy McAnally's context. Others in the comments suggest shoulda. Is it curtains for RSpec?
Go there.

I sort of idly followed up on it, and found that there was a pretty good discussion of Rails testing options there.

I haven't followed up on all of them yet, except to get a list, which is what I'm posting here.

It's pretty sloppy but it might help someone else. I'm about to update a couple of my sites, maybe add a new one, and get back into the swing of testing with Ruby on Rails, so this is a good time for it all.

First, the most general things.


BDD
There is decent article on Behavior Driven Development at Wikipedia. Go there.
Behavior Driven Development (or BDD) is an Agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. It was originally conceived in 2003 by Dan North as a response to Test Driven Development, and has evolved over the last few years.

The focus of BDD is the language and interactions used in the process of software development. Behavior-driven developers use their native language in combination with the ubiquitous language of Domain Driven Design to describe the purpose and benefit of their code. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management etc.


Ruby on Rails.org

Ruby on Rails Howtos on Testing has a good list of topics (each item in this list has a URL attached to it):
  • A Guide to Testing the Rails (in depth)
  • A walkthrough of UnitTesting for beginners
  • How to Quickly Test Validation in Unit Tests
  • HowtoFunctionalTestACreateAction
  • HowtoRunOneTest
  • HowtoRakeOneTest
  • HowToUseFixturesWithHABTM
  • HowtoPutSerializedColumnsInYamlFixtures
  • DisableForeignKeyChecksUnderMySql
  • HowtoRunTestsWithCoverage
  • HowToDoTestDrivenDevelopmentInRails
  • HowToWriteYourOwnCustomAssertions
  • HowToUsePreloadedFixtures – save lots of time!
  • HowToTestRailsWithWatir – windows only
  • HowToTestActionMailersAndControllers
  • HowToUseZenTestWithRails?
  • HowToUseRSpecWithRails
  • HowToTestFlash.Now
  • HowToUseFixturesMoreEfficiently
  • HowToLoadFixturesForOneTableIntoDB
  • AgileIntroductionForTestingRails
Non-howto material:
  • Some thoughts on rails testing best practice
  • ZenTest — Automated test scaffolding for Ruby (No info at this site: just "coming soon")
  • Sample CustomAssertions
  • HowToProfileRails
Go there.

On Rails Forum, see "Test/Behavior Driven Development". Go there.

RSpec
RSpec is a Behaviour Driven Development framework for Ruby. It provides two frameworks for writing and executing examples of how your Ruby application should behave: a Scenario Framework for describing behaviour at the application level A Code Example Framework for describing behaviour at the object level.
Go there.
RSpec provides a Domain Specific Language with which you can express executable examples of the expected behaviour of a system." RSpec describes behavior of a system, before it is built, through examples of how it should work after it is built. The examples constitute a test suite.
RSpec tools include:
  • A domain specific language for expressing behavior.
  • A runner to verifying behavior, operating from the command line.
  • Integrated mock objects.
  • A report generator.
  • An intergrated coverage tool, RCov.
  • A coverage verifier to keep coverage up to a minimum level.
  • Integrated diffing.
See also David Chelimsky' blog "on software in process and practice" has "an introduction to RSpec - Part I" (I'm not sure if there is a part II -- at least I couldn't find it). Go there.


Cucumber
Cucumber is a tool that can execute feature documentation written in plain text. Cucumber targets non technical business analysts, interaction designers, domain experts, testers (for the plain text part) and programmers (for the steps, which are written in Ruby).

Cucumber itself is also written in Ruby, but it can be used to "test" code written in Ruby, Java (or web applications written in any language). When IronRuby matures it can be used to "test" .NET code too.

Cucumber only requires minimal use of Ruby programming, so don't be afraid to try it out even if the code you're developing is in a different language. Most programmers should pick up the required Ruby skills and be productive with Cucumber in a few of days.

While Cucumber can be thought of as a "testing" tool, the intent of the tool is to support BDD. This means that the "tests" (plain text feature descriptions with scenarios) are typically written before anything else, and the production code is then written outside-in, to make them pass.
Go there.

Mocha
The Mocha plugin allows mocking and stubbing within tests using a syntax like that of JMock and SchMock.

The big advantage it has over other mocking and stubbing libraries is its ability to mock or stub individual class or instance methods on concrete classes.

Provenance. Mocha has been created by amalgamating a number of techniques developed by James and my Reevoo colleagues Ben, Chris and Paul into a common syntax. It is currently in use on real-world Rails projects.
Go there.

More at "Agile Web Development". Go there.
For the API, see this.

Shoulda
The Shoulda Rails plugin is an eclectic set of additions to the Test::Unit framework that makes writing tests a breeze.

Shoulda: Making Tests Easy on the Fingers and Eyes

The Shoulda gem makes it easy to write elegant, understandable, and maintainable Ruby tests. Shoulda consists of test macros, assertions, and helpers added on to the Test::Unit framework. It's fully compatible with your existing tests, and requires no retooling to use.
  • Helpers – context and should give you rSpec like test blocks. In addition, you get nested contexts and a much more readable syntax.
  • Macros – Generate many ActionController and ActiveRecord tests with helpful error messages. They get you started quickly, and can help you ensure that your application is conforming to best practices.
  • Assertions – Many common Rails testing idioms have been distilled into a set of useful assertions.
See more at Thoughtbot, Inc. Go to their projects page.

Go to the Thoughtbot Shoulda page.

See a post at the Thoughtbot blog titled "Introducing the Shoulda Testing Plugin". Go there.

Kyle Banker has a "Shoulda Testing Cheat Sheet" Go there.

Get the cheat sheet PDF.


Test::Unit


Can't leave this one out. It's where everyone starts, and most stay.

There is "A Guide to Testing the Rails" and Ruby on Rails. Go there.
Intended Audience: This article is for fellow Rubyists looking for more information on test writing and how that fits into Ruby On Rails. If you're new to test writing or experienced with test writing, but not in Rails, hopefully you'll gain some practical tips and insight on successful testing.

Assumptions: Just so we're all on the same page here, I'm making a few assumptions about you.
  • You've got Ruby installed and know how to run a Ruby script.
  • You've got Rails installed
  • You've created a basic Rails application with 1 controller and 1 model.
If you haven't accomplished all of the above, you might be jumping ahead of yourself. Check out www.rubyonrails.org for some great beginner's tutorials. Go there.

Factory Girl

More from Thoughtbot: "factory_girl provides a framework and domain specific language for defining and using factories – less error-prone, more explicit, and all-around easier to work with than fixtures".

Go to their projects page.
Go to their factory_girl page.
Don't miss the factory_girl RDoc. Go there.
And there is more at GitHub. Go there.


RR

I couldn't find much about this, but it's out there somewhere.
"RR (Double Ruby) is a test double framework that features a rich selection of double techniques and a terse
syntax."

On GitHub. Go there.
And at Ruby Forge. Go there.


object_daddy
Drop Object Daddy into the vendor/plugins directory of your Rails app. Now every model has a .generate() method which will create a new instance object of that model. If the model in question has no constraints which would make Model.new.save fail then you're set. Those models which do have stronger constraints will want "generators" for those attributes which need special care.
See info on blogtastic. Go there.
And at Ogtastic. Go there.
GitHub has a bit. Go there.


Matchy

It's out there somewhere but it seems to be described only on one blog, which seems to be down right now. No doubt there's more, but I didn't have time to search for hours just for a description.


Context

"Context is a Rails plugin that provides an easy way to determine the context of an incoming remote request so that different responses can be sent. Useful for supporting multiple workflows on RESTful actions."

At RubyForge. Go there.

GitHub has some more info:
DESCRIPTION: If you’ve ever wanted contexts in your Test::Unit tests, then context is for you. Your tests will be easier to read and write without all the magic and extra code smell!

FEATURES/PROBLEMS:
  • Add contexts to Test::Unit tests
  • Small DSL for specifying tests that are pretty
  • Ability to chain context lifecycle methods (coming soon)
Go there.


References:
RubyFlow