Schrade.Blog

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.

RSpec 1.0 was quietly released last weekend, after a flurry of activity from Aslak and David, who were hiding at a little table last Saturday during Railsconf finishing it up. Since it didn't get the blogosphere loving that I thought it should have, here are some of the important changes:

• The API is now considered stable, which is huge news for those of us that have been suffering through upgrades for a while now.

• You can now include examples that are not implemented by not providing a block to the example. These examples then show up in yellow in your spec report. For instance:

  it 'should tell us it is sharp'

  will produce:

  

  when run. Much handier than a TODO comment, right? It allows you to do a lot of thinking about how your object should act beforehand, and then implement it piece by piece.

• A spec:rcov task was added to the Rails rake tasks that will automatically produce a code coverage report from your specs.

• Numerous other bug fixes and small changes. See the changelog here.

If you haven't checked out RSpec yet, you don't have any more excuses not to. You can install it into your Rails app right now and start writing specs without changing anything else. You can even throw it away and go back to the normal Rails testing framework anytime that you want to, although I doubt that you will.

Said during an informal discussion with Avi Bryant after his keynote:

When I look at DHH's code, it makes me want to scream.

The guilty party (not Avi or myself, obviously) shall remain nameless.

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.

I'll be heading to RailsConf later this week. Here, via MyConfPlan, are the sessions that I'll supposedly be attending, although it's more likely that you'll find me chatting in the hall or over near the Aslak.

Looking forward to seeing everyone there.

Someone is finally writing a nice language level comparison of Ruby and Smalltalk, without any of the bias that we normally see in one of these things. I'm still convinced that you can't really see the power of programming in Smalltalk until you really try it (kind of like how Java programmers can't really see the power of Ruby until they try it) but hopefully this will encourage a few more people to give it a go.

Check out the article here.

There are a ton of social networks out there nowadays, but how many of them are really useful?

I mean really useful. Useful in the sense of helping us to get our job done or making our lives easier.

Clearly, the vast majority of the social networks that we use on a day-to-day basis are little more than time sinks. Myspace and Facebooks are prime examples of this.

Twitter? Even worse.

The question remains then, how can we use the power of social networking to make our lives easier? How can we harness it to help us better do our jobs and manage our free time?

The company that I am currently involved in, Collaborative Drug Discovery, is trying to answer those questions, at least for the domain of drug discovery.

We take data from academic chemistry labs all over the world, some of it sitting in dusty old lab notebooks, forgotten for years; and feed it into our system. This data can then be shared with all of the other researchers in the system.

Suddenly all of these researchers have access to exponentially more data then they had before, as well as the means to search and explore it.

Take just a minute and imagine the possibilities of that.

As an example, say a researcher in Poland finds a chemical that slows the growth of a certain type of cancer. They put it into the CDD system and then find 10 other similar chemicals that have already been studied by researchers from all over the world. If one of those chemicals has already been tested in humans and proven safe for other uses, the researcher might be able to head directly to human testing for effectiveness against the cancer that she found it worked against. This is a stage in the drug discovery process that usually takes many years and hundreds of millions of dollars to get to. We've just routed around it, all thanks to the power of social networking and data sharing.

Millions of dollars and years of people's lives were saves

And just possibly, and most importantly, hundreds of lives might have been saved in the process.

That's our vision, and I'm excited to be a part of it.

I've written several Rails apps that are in production use, and I love working in Ruby on Rails as my daily development platform, but let's face it, it has a bunch of problems. Just because the Rails team did a lot of things right doesn't mean that there aren't a bunch of things that can be improved right out of the box. Here are the first couple of things that I would do if I was starting a new Rails Project tomorrow:

1. Install HAML. I can't stress enough how much better your life will be if you use HAML instead of rhtml. Imagine DRY templates, less view code, and perfectly formatted XHTML every time. Imagine the sky opening up and angels coming down and lifting you up to templating heaven (it's next to dog heaven). That's what HAML gives you. We've solved the problem of looking at ugly HTML with embedded code a hundred times now, so why do we keep going back to it? Don't subject yourself to that sort of pain again! Install HAML and don't look back.

2. Dump the integrated testing framework and install RSpec. It's great that Rails has a testing framework integrated with it, but it has a number of problems. It confuses well known testing terms such as functional tests, there's no way to test views separately from controllers, etc. RSpec blows it away. Not only does it give you all of the advantages of doing Behavior Driven Development, it fixes the a bunch of the inherent problems with the Rails testing framework. No longer are controller tests called functional tests and model tests called unit tests. Now you just have model and controller specs. It also allows you to group your use of fixtures into different contexts for for different sets of tests, although you shouldn't really have to use fixtures much anymore because of RSpec's great built in mocking support. Overall it's a big step up from the built-in testing framework.

Just doing those two things will make your development faster by making your code easier to understand and by cleaning up a lot of the rough edges of the Rails framework. At this point I can't imagine going back to the standard Rails way of doing things.

When I was starting my first company and moving out to San Francisco a year and a half ago, I remember attending one of the first meetings of SFWIN. I took place in the backroom of a sushi place and had about 20 or 30 people at it. Everyone there was an entrepreneur first and foremost, but I remember the meeting having a distinctly geeky feel about it.

Fast forward to the present day, and the geeks are pretty much gone. I've been to a ton of networking events since that first one, and I've watched them fill up with more and more suits (and a bunch of geeks, me included, turn more and more into suits). This is good, as it means that there's lots of money floating around the Valley right now, and it has helped me learn a ton about business since those early days, but there isn't really anyplace anymore that has that geeky edge to it.

It looks like someone is finally taking steps to change all of that. I got an e-mail today from Christian Perry of SF Beta announcing geekSessions, a new networking event in the SF area that tries to inject a bit of the geek back into things. It's not quite in the back room of a sushi place anymore, but hey, we're all used to spending our time at throwing down drinks at 111 Minna now, so I guess the upgrade was inevitable.

Sounds like a great idea to me.

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.