non-random ramble

RubyMate the ruby plugin for TextMate has a nice feature where it will run your tests for you when you press option-R.

If you want it to add your library and test directories in for you , simply edit the command in the bundle editor. There is an option for RUBYLIB there where you just add say “../lib” and “../test” as appropriate.

I have been using the google syntax highlighter plugin for a while now, but its been bugging me a little that I have to type

<pre name="code" class="html:nogutter:nocontrols">
Some code goes here
</pre>

In order to put in some java code. Infact, I can hardly ever remember the invocation.

I discovered Shortcodes for wordpress which is a simple way to write little plugins. So I wrote my own. Just pop it in your plugins directory and go activate from WordPress.

Now i can type:

[java]
public class MyClass {
}
[/java]

Unfortunately it only works in later versions of WordPress (at least 2.5), this blog is 2.04 and so I may have to upgrade, which I am scared of because of all the customisations I’ve made.

Update:

Now ive upgraded, so here’s some Java!

public class SomeSillyClass {
    public static void main (String[] args) {
        System.out.println(“WordPress Rocks!”);
    }
}

Some hard won knowledge was that not only do the stylesheets control the look and feel, but also the javascript “brushes” which are found in the script folder for the google syntax plugin (e.g. shBrushRuby.js)

This is just joy.

Re-Imaginining book covers by global nerdy.

Following my Previous post on this topic, I have been in contact with Jeff via email, and he mentioned that the version of the chapter which is on his website is a preview version and so the published one should be taken as the final version.

Something I mentioned there is a rule which wasn’t included in the final version (it is called “3. No static methods other than factory methods”). Jeff had some interesting comments and it sparked some good discussion between my pair (Steph) and I and so I think its worth adding the result here.

As I indicated, I had been thinking a bit about statics recently and been trying to pin down what I think about them. I was thinking along the lines of “Don’t use statics when you really want an instance” (see below). Jeff made the observation that actually they use statics quite a bit under certain circumstances.

With Jeffs kind permission, I will try to summarise our discussion.

Methods with no side effects

we use static methods extensively. whenever we can have a method that doesn’t have any side effects, we mark it as static so that the ide can alert us to the fact that it is so.

I realised that this is something I also like, if we’ve just written a method and it has no interaction with the state of the object, making it static is a clear indicator at the compiler level that the method has no side effects. I would tend to just do this without even thinking about it, so it was interesting to call it out.

Guard conditions / Encapsulation

bombUnless(isTrue, "the thing was supposed to be false!");

Here, there is a piece of logic which belongs to this class, but doesn’t involve the state of the instance. Steph and I discussed this also.

String params = url.params();
if (params == null || params.trim().equals("")) children.add(sentinal);

Becomes :

if (isEmpty(params)) children.add(sentinal);

I had hinted at this in the previous post, in terms of it being a common pattern. One place it is frequent is in the area of testing and mocking, for example Mockito or JUnit both make extensive use of statics which makes the code easier to read.

Jeff had this to say:

These kinds of minor improvements to code, getting rid of micro-duplication, have given me some of the best gains in my practice. Without static methods and static imports to help reduce the client’s overhead for the method call, it’s hard to make certain kind of improvements worthwhile.

Don’t use statics where you can have an instance

This was my original understanding of the rule “only use statics for factories”. I had been thinking that the intent of the rule was this, so for example:

public void talkToTheService() {
    Result result = SomeService.doSomethingForMe(myArgs);
}

instead of :

private SomeService someServiceInstance = new SomeService();

public void talkToTheService() {
    Result result = someServiceInstance.doSomethingForMe(myArgs);
}

Summary

I’m sure there is more to say on the subject, but I think some of these points are useful. As a general point, Jeff concluded our discussion with:

Static methods should be reserved for things that either touch multiple objects and have no identity beyond the functional cohesion (make it a static method to give the related steps a name) or things that represent generic operations on fundamental types (such as the isEmpty example).

Thanks Jeff!

I happened to notice the book “The ThoughtWorks Anthology” lying around the office. It contains quite a few interesting articles. One in particular resonated with me.

In Chapter 6, Jeff Bay talks about a set of simple rules for writing OO code, which he suggests you try applying rigorously on a small project (say 1000 lines of code). The article can be downloaded here.

This is a hard exercise, especially because many of these rules are not universally applicable. The fact is, sometimes classes are a little more than 50 lines. But there’s great value in thinking about what would have to happen to move those responsibilities into real, first-class-objects of their own. It’s developing this type of thinking that’s the real value of the exercise. So stretch the limits of what you imagine is possible, and see whether you start thinking about your code in a new way.

What I liked about this article is that it cut to the core of something which I have been working at explaining over the last few months. I sometimes feel like a “purist” when discussing OO design. It is a common situation to find myself defending writing a small class, or encapsulating a String to make a small value object which only has a single attribute. Jeff explains in a great way a few principles and challenges the reader to try them out in a rigorous way, just to see how it works out. This is a great way to present it, its not saying “I know the right way and you must follow the rules”, its suggesting that you should give it a chance and you might begin to see some rewards, or “Try it, you might like it”.

I also liked the fact that eight out of the ten rules were all about encapsulation something I have also been thinking a good deal about recently, prompted by this experience, even to the extent of getting it printed on a t-shirt (but that’s another story).

NOTE:
Since writing this post, I have had a discussion with Jeff via email, the results of which can be found here, this paragraph is superseded.

Another one which isnt actually in the book, but that I have been getting into recently is “No static methods except as factories”, This one is particularly hard to follow when so many libraries use them and its just so convenient:)

He’s not suggesting that these rules are always applicable but I think its interesting to make the effort of taking it to an extreme and see where it leads you, it may open new possibilities when going back to everyday coding.