Entries Tagged 'Agile' ↓

Seaside, my other favorite framework, released version 2.8 today. This release has been optimized and optimized some more, as it doubles the average page rendering speed, and now uses up to 4 times less memory. Plus it supports Gemstone, which is the feature that I’m most excited about playing with.

The official release page is here, and if you still haven’t tried Squeak, a great new tutorial can be found here.

Congrats to the entire Squeak team on this one.

(Seriously though, who does a release on a Sunday? You guys are nuts.)

Yesterday’s blog post certainly generated a boat load of feedback, which I’m going to group into a few different tongue-in-cheek categories:

• Refactoring isn’t a problem, just refactor everything yourself by hand, or write a refactoring tool yourself.

If I had the time, I would. Refactoring by hand is what I’m doing now on a daily basis, because I don’t really have any other choice. Thus the request for better tools.

Which brings up a tangentially related point. Why is it that whenever someone asks for better tools it’s because they’re lazy? I think that we can all agree that it sucks to use an axe to chop down trees when you’ve used a chainsaw before. From now on, comments of the form “just use grep to do it” will only be accepted from those of you who program on mainframes and walk everywhere, simply because you remember the good old days before we had these fancy cars and trains to move us around.

• You must be coding Ruby incorrectly.

When making this comment, please point out the web page that shows how to write Ruby correctly. I have multiple Ruby webapps in production, I worked at Thoughtworks and I’m currently working with Pivotal Labs, two of the foremost Ruby consultancies, and no one has told me or my team that we’re writing things incorrectly. However, I have an open mind and I’m willing to learn more about this topic.

• You can’t just throw together Ruby code without tests, that’s why you’re running into problems.

Aren’t you going to have this problem with any language? Where did I imply that this was something that we were doing? Anyway, ‘rake stats’ says:

Code to Test Ratio: 1:2.8

So I don’t think that’s the problem.

Seriously though, It’s all a bit academic. If you asked me what framework I would use if I was going to start building a new webapp tomorrow (and told me that I couldn’t use Seaside) I would still choose Rails. It’s still the best tool for lots of jobs out there. Pointing out some of it’s deficiencies doesn’t make that any less true, despite what some people seem to think.

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.

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.

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.

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.

Down on the Collaborative Drug Discovery ranch we’re taking some initial steps towards moving from TestUnit to rSpec.

Blah

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.

I’ve been really feeling the pain of trying to hire a good developer lately.

We’ve been posting Craigslist ads, and we feel that we have all of the right keywords in place (Rails, Agile, Cheminformatics, Data Mining, Java, etc), and a bunch of cool challenging problems to work on, but we’re not getting back much as far as quality responses go.

Maybe the job market really is that hot right now. Everyone I know seems to have multiple offers on their plate. Still, we’re refusing to lower our standards, but we are starting to feel the drag of just not having enough people to get everything done. Anyone out there with any suggestions (or better yet, resumes of good people)? Email or comment if you’ve got them.