moreUnit

wow... the moreUnit plugin for eclipse is just what I've been looking for, it's amazing. One of the more important things it does is associate Classes with Test Classes - So if you have Foo it knows that FooTest is related to it. From there it does a number of great things.

• Handles renaming correctly - if you rename Foo to Foo2 it will automatically rename FooTest to Foo2Test. For that functionality it's worth it just to use this plugin.
• ^J toggles between Foo and FooTest AND if FooTest doesn't exist yet, it prompts you to create it. Woo hoo! I constantly create a new class - then CRTL N to create the test, this cuts down one anoying step, pretty cool.
• It associates method names with test method names. And does a few awesome things with that association.
  • If you have:
    Foo.bar() and FooTest.testBar()
    you rename Foo.bar() to Foo.foo()
    it will rename your test method to FooTest.testFoo()
    it will even do multiple test methods if you had testBarA() - testBarB() - testBar*() - it will rename all of them.
  • Because it associates the methods with test methods - it can provide you with a view that shows you all the test methods your missing for a class (Emma's great, but it doesn't give you this kind of detail, you can always trick yourself into thinking you covered stuff when you haven't, this is pretty awesome, imagine failing the build if you don't have a testMethod for every method in a class, that I think would be much more valuable than failing on code coverage metrics). In this view you can also create the missing methods in you test class
  • I have a bone to pick though. In Junit4 your method names really shouldn't begin with the word test any longer, because you already have that information in the form of an annotation at the beginning of your test method - BUT for moreUnit to know that a method in a test class is associated to a method in your class under test, you need to prefix with "test"
• Some of the documentation doesn't match up to the most recent version, but 1.2 was just released before Christmas, so I assume it will be updated at some point. For example I don't seems to be able to setup project specific settings - and really the test directory setting, doesn't appear to have any effect (It specifies the directory where you create new tests).

So I've just been playing with it for an hour or so, but this thing is great, I can't wait to start using it day to day

Google Reader

I recently made the switch from Bloglines to Google reader. I'm definitely happy I did. Google reader does a few things much better than bloglines.

1. It has some nice keyboard shortcuts http://www.google.com/help/reader/faq.html#shortcuts , n/p (next previous), o (open close), s (star), m (mark as un /read). The short cuts are simple to use + remember.
2. I really like the Feed / Subscription pane. It shows unread blog post in bold, but then it has all the other blog posts there below it. it's really easy to scan though old posts and find one your looking for.
3. Speaking of finding stuff you're looking for, it also allows you to star a post. There are a few posts that I go back and re-read. My usual MO is to add a bookmark in firefox to the post. But being able to star an item and come back to it is really a great feature for me.
4. Top Recommendations - I really like this, three links that google thinks I'd like. For example I found out No Fluff Just Stuff has a feed - which is an aggregation of all the speakers blog posts it's a really nice feed.

I'm interested to see if bloglines will do a redesign anytime soon. But for me it doesn't compete with Google Readers features and usability

Updated - I just have to add, I've been exploring the rest of the keyboard shortcuts for google reader + they're awesome no more mouse. The commands to browse your subscriptions are great. shift n/p is next previous subscription shift o is open subscription. This is a really nice job of modifying other similar key bindings for a different context... it's very easy to use. Then there are the g? commands. Go somewhere gs goto starred items, gh go home, gu I don't know what the u stands for but it is goto subscription. It brings up an awesome quicksilver esq type completion window, it's pretty and nice to use.

Daily WTF Error'd submission - 16 Million TB

I'm thinking this is worthy of a WTF Error'd, but in case it doesn't make it here it is:

So... one day I'm writing some code, and my computer seems slow this is what the activity manager had to say:

Hard Contracts vs Soft Contracts

So I've been thinking about different kinds of contracts your software can have, hard contracts and soft contracts. If I look at the javadoc for List, it tells me what's expected of me if I implement a List.

add(int index, Object element)
          Inserts the specified element at the specified position in this list (optional operation).

Great, I implement a List, BsList - and pass it off to you. Technically I did everything Java cared about, there's no compile errors, I implement List and provided all the proper methods. But there's nothing that verifies if I followed the intent of the List interface. The only thing you could do if you wanted to know if I did a good job would be write some unit tests. This is a soft contract. I implemented some interface and you assumed because I did that, my code follows the expected behavior of List.

Now imagine another world. Where Sun not only released the List interface with some Javadoc, but also provided developers with a set of tests. How much more confident would you be in BsList if you could run a Sun approved unit test suite?

Most interfaces talk not only about a syntactic contract (you implemented the interface), but have an expectation about how the implementation should behave. The problem is, that's only captured in javadoc. I think interfaces need harder contracts bundled with them, they need unit tests. And seriously, you can't tell me you wouldn't love implementing an interface that had a set of tests with it. The List interface is big, 23 methods, how do you know you got it right? And why should those tests ever be coded up more than once?

Who knows, maybe it would be a bad idea for Sun to do something like that, but I know I'll be providing unit tests with my interfaces.

Testing Interface Implementations

I've been working on some library code recently, and working on a few implementations of an interface. I wrote and tested my first implementation, then started on the second one. I didn't think about it in advance but of course about 90% of the tests needed to be the same. I realized I needed to verify that every implementation adhered to the API spec I laid out.

I ended up moving all the shared "API" tests into an abstract base class, with one abstract method, create(). So far so good, it feels a little weird to have an abstract class doing testing, but it's also kind of cool. Instead of having Javadoc describing your API there is a clean set of tests that you can look at. Also if you want to implement the interface, now not only do you have access to the minimum set of behavioral requirements but, it's also easy to run the tests against your implementation.

I wish every API I had to implement had a hard contract of tests that I had to pass, that would make life so much easier.

Javadoc = soft contract
Tests = hard contract

Code Swarm

Have you ever run Code Swarm on your source code repository?

No? well the you should Download it and build it

From the site:

This visualization, called code_swarm, shows the history of commits in a software project. A commit happens when a developer makes changes to the code or documents and transfers them into the central project repository. Both developers and files are represented as moving elements. When a developer commits a file, it lights up and flies towards that developer. Files are colored according to their purpose, such as whether they are source code or a document. If files or developers have not been active for a while, they will fade away. A histogram at the bottom keeps a reminder of what has come before.

A developer did it on our repository and showed it at a team meeting, it was a lot of fun to watch, I definitely recommend it.

Coding Question / Annotations / Dynamic behavior / DSL

Let's say you have a domain object and there is a DSL that acts upon the domain object. There are some constraints:

1. The DSL is only allowed to access certain methods on the domain object
2. If the DSL tries to access a method it's not allowed to, you can throw an exception
3. You didn't write the DSL it's something like MVEL (or it is MVEL), so you can't modify it.
4. You can wrap, modify, do what ever you want to the domain object before exposing it to the DSL.
5. The DSL looks like "foo() > 1". Where the DSL will has an object and will call foo() on it.

How would you implement this?

One option which is pretty straight forward, use a facade and expose to the DSL only the specific methods in from your domain object. This is not too bad if there are 3-5 methods, but assume there are 20 methods, or even there are 10 objects each with 20 methods you want to expose to the DSL. A facade might not be a bad idea, but it does start to incur some maintenance cost. And developer annoyance.

Another option would be to use meta-data / annotations (I know, I know Metadata is for noobs but I'm a noob, so it's okay for me to use it). Instead of the facade you could annotate each method you expose to the DSL. Great it's easy to annotate methods, but how would you throw an exception if the DSL tried to do some bad stuff? This is where something like AOP / CGLib can come into play. You proxy your object with CGlib and intercept all method calls, if the method does not contain your annotation then you throw an exception. Take your proxied object and expose it to the DSL. Now the DSL has a proxied version of your domain object that won't let it call methods on it that it shouldn't. Problem solved.

The real question is which is better the facade or the metadata? I'm really not sure.

Any other tricky ideas?