It’s official. Not only will I be going back to Railsconf this year, but I just signed up blerb to be part of Chad’s Community Project Code-Drive. I’m excited about the potential of this blog engine and it should be pretty polished by the end of May.

So, if you’re coming to Railsconf, come hang out with us on tutorial day and help us finish it up.

It’s been quiet around here, but there’s a storm brewing. I like mephisto, but it’s a bit heavy for what I need and not nearly as extensible as I would like. I’m either going to help with blerb (merb + datamapper based blog engine) or I’m going to strike off and write my own (probably also merb/datamapper based). As I have great epiphanies, I’ll try to record them here. As I have stupid comments you’ll have to endure those too.

Stay tuned for great upheaval

Being one to never pass up an opportunity to take pot-shots at Microsoft, I just had to share this article. It makes me giggle:

Windows XP Review

If you’re using Parallels and find yourself in need of the keypad. It’s not very well documented, but the clear key on the keypad toggles the numlock so you can use the numeric keys.

Thought you’d like to know (plus, if I write it here then I know where to look for it next time I need it) :)

Screen sharing via iChat in the Leopard is indeed awesome and amazing. However, there’s a better way. Here are my issues with the default screensharing via iChat:

1. It’s modal—you can’t click on any other application or interact with your own desktop in any way while sharing someone else’s desktop
2. It’s fullscreen, but it’s not—it takes over the whole screen, but there’s a black border around it if the screen you are sharing is a lower resolution than your screen so you still can’t get to your own desktop behind it.
3. You can’t select which desktop you want to see if they screen sharer has multiple desktops. You get all of them. If you are sharing with someone who has dual 30” displays and you are trying to view it on a macbook pro screen, that’s a real pain.
4. You can’t share with more than one person. If I were doing default VNC (which is the underlying protocol for Leopard screen sharing), I could allow as many clients as I want to view my screen. With Leopard, it’s one only.
5. I can’t have a view-only client. With VNC (typically we use the Vines server and Chicken of the VNC client) I can connect my client as view-only so I don’t have to worry about mouse contention with whoever is driving the server. You can’t do that in Leopard.

Don’t get me wrong, it’s still very useful, but these things do add up to be quite annoying. I still don’t have a solution for #4 or #5 (any help would be appreciated, please comment), but I’m here to relieve you if you’ve struggled with #1-#3. It turns out that iChat is using another installed app as the backbone of the screen sharing experience. Venture into finder and take a look at

/System/Library/CoreServices/Screen Sharing.app

This is the actual Leopard screen sharing client and you can run it outside of the iChat context. You give it the address of the server you are trying to share (the sharee has to initiate this to get the screen of the sharer). You then have the option of logging in using a known user/password on the sharing computer, or you can request permission which prompts the sharing computer. In order to set this up, the sharing computer needs to have screen sharing needs to be turned on in System Preferences (under the Sharing panel), and if behind a firewall/router you need to have the VNC ports forwarded to the right internal IP (I forward ports 5900-5902).

I know the stupid song says to blog about the video, and yes I am, but it’s just too funny not to, and besides it’s Billy Joel. If you haven’t seen this yet, check it out:

Richter Bubble Video

Having been burned rather badly by the first bubble bursting, I have had thoughts lately that it feels like 2000 all over again. On the other hand, I think VCs are a little smarter this time, especially since they have so many options. On the other hand, how can you explain an industry that is based on the whims of social networking as a legitimate enterprise? Facebook could disappear even faster than it appeared if you combine a strategic mistake or two along with something cooler coming along (who uses Myspace anymore anyway?). On the other hand (can you tell I just watched ‘Fiddler on the Roof’ lately?), the expectations are set higher than they were, and there is some expectation of cash from something other than an IPO.

Here’s hoping that if it happens, it’s at least more like the air going out of a balloon than a bubble bursting. At least that gives a much more exciting ride.

I’ve always liked the way RSpec succinctly clarifies the intentions of your tests in such a non-computer fashion so testing in fact turn into requirements gathering exercises. At Rubyconf last week David Chelimsky showed off some new syntax sugar that I absolutely loved. For all I know it could have been in RSpec from the start, but it was new to me and it’s now a regular part of my repertoire. It’s the pending block syntax.

The ability to mark tests as pending has always been a strength of RSpec over any other testing framework I’ve ever used. It’s easy enough to rename a test method so it doesn’t execute, but before RSpec I’ve never worked with one where you can mark it as pending and it then reminds you that you still have work to come back too. Too often renamed tests get forgotten. Here are the many ways to mark tests as pending.

1
2
3
4
5
6
7
8

describe "Test some object with pending tests" do
  it "should make sure 2 + 2 = 4" do
    4.should == (2 + 2)
  end

  it "should make sure the second derivative of something calcs fine"

end

That will run with one green test, and one yellow test marked ‘PENDING: Not Yet Implemented’.

(That’s the output you get from Textmate’s most excellent spec runner). Another way to do the same thing, but add some context is as follows:

1
2
3
4
5
6
7
8
9
10

describe "Test some object with pending tests" do
  it "should make sure 2 + 2 = 4" do
    4.should == (2 + 2)
  end

  it "should make sure the second derivative of something calcs fine" do
    pending "This test can't be implemented until derivatives make sense to me"
  end

end

It still marks the spec as pending, but instead of ‘Not Yet Implemented’, it gives the text you specified (in this case: ‘This test can’t be implemented until derivatives make sense to me’ - seemed like a good reason to me).

Both of these forms are very useful for marking entire specs as pending. I tend to use the first form when I’m first trying to capture all the specs I need to write to implement a piece of functionality. Then I come back and implement each spec, then get it passing, but I’ve already captured what I think would be the entire scope of functionality necessary in the pending specs. I’ve seen people use the second form (the pending keyword) a lot to skip a spec that is suddenly failing. There is a better way. Instead of marking the whole spec as pending, add a block to the pending keyword and use it to wrap the part of the spec that is misbehaving. You get a double benefit. Take the following test for instance:

1
2
3
4
5
6
7
8
9
10
11
12

describe "Test some object with pending tests" do
  it "should make sure 2 + 2 = 4" do
    4.should == (2 + 2)
  end

  it "should follow the rules of basic arithmetic" do
    4.should be < 5
    9.should_not == 76
    3.should == (1 + 1)
  end

end

It fails as follows:

Ignoring the trivial nature of the spec, if the failing test is part of a library or in some code which you are dependent on somebody else to fix it. Take the failing spec, wrap it in a pending block with an appropriate comment like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

describe "Test some object with pending tests" do
  it "should make sure 2 + 2 = 4" do
    4.should == (2 + 2)
  end

  it "should follow the rules of basic arithmetic" do
    4.should be < 5
    9.should_not == 76
    
    pending "need to alter the rules of the universe to make this happen" do
      3.should == (1 + 1)
    end
  end

end

This produces:

Now, not only does the spec pass, you get a huge benefit. While it appears that the entire test is skipped as pending, it’s not. The specs outside the pending block are still evaluated and the spec will fail if any of their assumptions are broken. Another unexpected benefit is that the code inside the pending block is actually run with each spec execution. As soon as it passes, you’ll get an error notification saying that though you expected this spec to fail but it didn’t (in this case I modified the code to work, but you get the idea).

Consider it a friendly reminder to come back and clean up your pending specs as soon as they no longer need to be pending. That way you can stay lean and mean and keep those specs green.

If this is the first time you’ve seen RSpec in action, you don’t know what you’re missing. If you like to read up on cool stuff, head on over to the RSpec Homepage. If you’d rather sit back and let some smart person explain it to you and show you how to get it all set up, I’d say this would be a better bet.

Enjoy!