Schrade.Blog

(Or, How I Spent My Martin Luther King Day Weekend)

Here are the web app frameworks I've been reading about and playing with for the last few days. As usual, they've got a bunch of cool ideas that we'll be seeing in mainstream frameworks in 4 or 5 years.

Weblocks: Weblocks is a continuations-based web framework written in Common Lisp. Think Seaside, in Lisp.

Ramaze: An MVC framework written in Ruby. Like Rails without all of the garbage and magic.

Check them out. Pretty cool stuff going on.

My coworker Krishna, inspired by Giles Bowkett's post Rails Debugger: Use RCov With Selenium, Watir, Or Just In Real Life, whipped up a little rake task that automates the process of checking code coverage using your Selenium tests:

desc "Measure coverage of selenium specs"
task :coverage do
  FileUtils.rm_rf "selenium_coverage"
  mongrel_pid = fork { exec("rcov script/server -o selenium_coverage --rails -- -e test -p 4000") }
  sleep(6) # wait for mongrel to start

  begin # selenium will call "exit 1" if there are failures
    Rake::Task["selenium:spec"].invoke
  rescue SystemExit; end

  Process.kill("INT", mongrel_pid) # triggers generation of rcov report
  Process.wait
  system("open selenium_coverage/index.html") if PLATFORM['darwin']
end

While we don't agree that this task, in any way, shape, or form, constitutes a debugger, it has been useful in showing us areas of our code base that our Selenium test cases aren't hitting.

This should work for just about anyone that has a rake task to run their Selenium (or Watir, or other in-browser testing tool) tests. Just replace 'selenium:spec' in the block above with whatever task you use to run your in browser functional tests and have at it.

My friend Jay published a blog post today entitled Despised Software Luminaries and, for once, he got it all wrong. I know Martin and Obie , his examples in the post, from my time at Thoughtworks, and they're not software luminaries. They're software pundits.

Both of them spend a lot of time telling people how they think the software world should operate. Whenever you tell people how they should do something, it naturally leads to disagreement. It's that simple. People despise them because they disagree with them.

When I think software luminary, I think of people like Alan Kay, Fred Brooks, and Edsger Dijkstra. People that made fundamental changes to the way that we write software. People like Obie and Martin are smart, talkative guys, but they're not quite in the same league as those guys.

(See also: http://en.wikipedia.org/wiki/Turing_Award)

Ever since I started writing Ruby code I've used Textmate as my editor. Recently, however, I've found myself using Netbeans more and more, to the point where I usually have Netbeans and Textmate open next to one another. Netbeans' refactoring support, ability to jump to method definitions, and ability to autocomplete code is just too good to ignore.

However, a couple of features have kept me from switching to Netbeans full time, namely its lack of Haml support and the fact that it couldn't run a focused Rspec example.

Well lo and behold, I just checked the Netbeans Ruby Recent Changes page and found the following:

• October 12
  • Lots of bug fixes
  • RSpec module (not part of 6.0 but available in the continuous builds on deadlock)
    • TextMate RSpec snippets
    • "Run Focused Test" action which runs test under the caret. Locate the action in the Keybinding options (see the "Other" category) and bind to something convenient.
    • "Debug Focused Test", which starts the debugger on the test under the caret.
  • Preliminary support for HAML and SASS - see announcement

They solved both of my issues on the same day!

I did have to install the Haml plugin from here, but it looks like I no longer have a compelling reason not to switch to NetBeans fulltime.

And the obligatory screenshot:

Awesome!

In his post The Business Advantage of Rails, Giles Bowkett writes:

What makes programmers happy? Elegant systems which make them productive and take tiresome, tedious bullshit out of their daily lives.

People who get tiresome, tedious bullshit out of their way forever are great people to work with. Conversely, tolerating tiresome, tedious bullshit without ever fixing it is absolutely not a character trait you want your hiring process to be biased in favor of.

which sounds like a good idea, except that a lot of programming on a real application, no matter if you do it in Ruby, or Visual C, or COBOL, ends up being a lot of tiresome, tedious bullshit.

Which brings me to something that I've been thinking a lot about lately. At CDD we have a pretty complex Rails app, (as one of the consultants that we're working with said, "I've worked on a dozen Rails apps, and this is about 4 times bigger and more complex than any of them") and as our application gets bigger and bigger I'm starting to see more and more complexity and problems crop up. I feel like we're walking up the same old curve to all of the standard problems you run into when programming a webapp in any language (object model too big to be easily understood, code is getting less and less cohesive, etc). It may have taken a little longer to get there, but I'm pretty sure that we're going to end up in the same place.

Which leads me to another problem. The easiest solution to a lot of these problems, in my experience, has always been to refactor the code. That's what I always ended up doing with Java apps of this size back in the day. Unfortunantly, the state of Ruby refactoring tools, and I'm putting this as nicely as I possibly can, sucks. Even something as simple renaming a class tends to be far more painful than it needs to be.

So the big question now is, have we (and perhaps we're the first team to do this, as I haven't heard much about it from others) finally hit the point where the cost of maintaining our code in Ruby is higher than the savings by writing it in Ruby in the first place? I'm not willing to answer yes to that question yet, but I am starting to see more and more places that have me pining for for the good old days of IntelliJ, with all of the great things it does to make your life easier. It's easy to forget about the amount of tiresome, tedious bullshit that great tools can help us avoid, at least until you start running into that same old bullshit.

Seaside does not have a marketing problem!

Everyone I know in this business knows about Seaside and its super productive powers. We've all seen the demos and the screencasts and the awesomeness that is DabbleDB. For god's sake, Avi gave a keynote at RailsConf this year.

I think it's safe to say that people know about Seaside.

The problem at this point isn't a marketing one. It's the same problem that Squeak has always had. Namely that when you download Squeak and start it up, you're presented with this:

When most programmers I know see this, they have the same reaction, "What the fuck?"

This is usually followed quickly by the question of, "Can I edit this using Vi or Emacs?"

Let me answer this now. No and No.

If you're the type of person that can't imagine giving up writing code at the command line, then Squeak isn't for you. (Although there are Vi and Emacs keybindings.)

And that's usually the end of it. People play with Squeak for a few minutes and then go back to doing their real work in Ruby or Python or Java or C#. A lot of the power and magic of using Seaside is directly derived from the power and magic of using Smalltalk, which unfortunately (or fortunately, depending on your point of view) means that you're going to have to learn Smalltalk if you want to use it .

And Smalltalk is, at least in the case of Squeak, a whole different world. You have to unlearn a lot of what you know in order to use it. Editing is different, class creation is different, version control is different. Basically everything you know as a programmer gets thrown out the window.

But you know what? At some point, once you do that and really start to immerse yourself in Smalltalk, you'll suddenly realize that it's hard to go back to the old way of doing things.

You'll realize how much easier it is to just ask the system what method you should use to get something done instead of going to a PDF document somewhere to look it up. (Yes, in Squeak you can just type "'class'. 3. 'cla'" into the the method finder and tells you that "contractTo" and "truncateTo" are the two messages in the system that give you that result.)

You'll suddenly come to the realization that this is simply better.

That this is how things are supposed to work.

Unfortunately for most of us at this point, we'll have to go back to our real jobs, (I asked Avi after his keynote how many people in the world are actually making money using Seaside and he said that he figures about 20) but even if you get this far you'll learn enough to to have a whole new outlook on how coding should work.

It's not a marketing problem, it's the the same old problem that people are scared of things that are different then what they're used to. Hopefully someday we will be able to overcome this fear, and then Seaside and Smalltalk will finally take over the world. But for now this new outlook on development will have to be good enough.

If Ruby is a step up from Java in productivity and power, and Smalltalk is a step up from Ruby, then we should all feel a little ashamed when we read the following from The Early History of Smalltalk by Alan Kay:

In January 1976, I took the whole group to Pajaro Dunes for a three day offsite to bring up the issues and try to reset the compass. It was called "Let's Burn Our Disk Packs." There were no shouting matches, the group liked (I would go so far to say: loved) each other too much for that. But we were troubled. I used the old aphorism that "no biological organism can live in its own waste products" to please for a really fresh start: a hw-sw system very different from the ALTO and Smalltalk, One thing we all did agree on was that the current Smalltalk's power did not match our various levels of aspiration. I thought we needed something different, as I did not see how OOP by itself was going to solve our end-user problems. Others, particularly some of the grad students, really wanted a better Smalltalk that was faster and could be used for bigger problems. I think Dan felt that a better Smalltalk could be the vehicle for the different system I wanted, but could not describe clearly.

I know that they went on to implement Smalltalk-76 as the follow-up to this, and that what we use today is a closer ancestor to that then the Smalltalk-72 that he is discussing here, but it was really just anther evolution. How is it that we haven't had a revolutionary advance in programming languages in the 30 years since then?

I don't have a solution, but I think that all too often we forget that there's even a problem to be solved.

Recently at work we've been having a bit of an argument over the proper way to structure a spec while doing Behavior Driven Development.

I'm going to illustrate a couple of patterns that have emerged using the simple example of a sword that should tell you if it is sharp or not, depending on whether it is new or used.

One camp at my current job, likes to use what I'm calling the Inside-Out Pattern for writing specs. This group likes to start with the method name and then define behavior for it. An example of this is shown here (in RSpec syntax):

describe "sharp?" do 
  it "should tell you if it is sharp or not" do
    Sword.new(:status => 'new').sharp?.should == true
    Sword.new(:status => 'used').sharp?.should == false
  end
end  

Their argument for this pattern is that all of the code for that method stays in one place, so it's easy to see if you've covered everything in that method.

The argument against this is that your specs are harder to understand and you can't really do real TDD with this method of development.

The other camp likes to use what I'm calling the Outside-In Pattern. This pattern describes the possible states of the object first, and then describes what the object should do in each state:

describe "A new sword" do
  before(:each) do
    @sword = Sword.new(:status => 'new')
  end

  it "should tell us that it is sharp" do
    @sword.sharp?.should == true
  end
end

describe "A used sword" do
  before(:each) do
    @sword = Sword.new(:status => 'used')
  end

  it "should tell us that it is not sharp" do
    @sword.sharp?.should == false
  end
end

The argument for this pattern is that it is more descriptive of what the object should do and it helps with TDD.

The argument this is that you get too many descriptions in your spec, and they can get hard to read. Also, the behavior for a single method in a class is spread around the multiple descriptions, so it becomes harder to make sure that all of the behavior of your method is covered.

Most of the specs that we've written so far seem to skew towards one or the other of these options, but there's no consensus on which of them is better yet, so I figured I'd throw it out there and see if anyone has experience one way or the other and which one has worked better.

Please let me know in the comments.

(And yes, before anyone asks, I'm firmly in one of the camps, and yes, I purposely didn't reveal which one here. I'll be talking more about it in a later post.)

Update: My coworker Dustin points out another way of doing specs that rests firmly in the middle of these two views.

This afternoon I've been reading "Rubyisms in Rails" by Jacob Harris. It's a little PDF download from Addison Wesley about how various aspects of the Ruby language enabled Rails to come into being, and I've been enjoying it quite a bit. I had to stop and laugh when I saw the following quote though:

Because it is not compiled and has no static types, Ruby might seem to be more dangerous to develop in; but in some sense, it can actually be safer to program in: Because developers have no illusions that type checking is a serious defense against bugs, they will not confuse compilation with correctness.

I'm going to go out on a limb here and say that for the 90% of developers that do a bad job of testing all around, this is not going to be the case.

Also, he makes the statement:

Simple to use and well suited for their purpose, symbols are one of the unique features of Ruby.

I'll just assume that he meant to say, "Simple to use and well suited for their purpose, symbols are one of the great features of Ruby that was taken directly from Smalltalk" and his editor just took it out after he turned in his manuscript.

Overall though, it's a good quick read that does a great job of showing how Ruby makes a lot of the magic in Rails possible. Well worth the bargain price of $9.99.

I just downloaded and installed the Cruisecontrol.rb 1.0 release that was just put out by some of my old co-workers at Thoughtworks earlier today. It literally took about 2 minutes to get builds up and running with our project.

As far as I can tell, it seems to be exactly what you would want out of a CI tool, it's easy to install and it gets out of your way until a build fails. Good stuff.