Nice Mercurial tutorial by Joel Spolsky

Joel Spolsky (of Joel on Software) wrote a very entertaining and thorough tutorial on Mercurial, a distributed version control system (DVCS). The tutorial has a Subversion re-education pre-tutorial for those of us with Subversion brain damage. Well worth a look. Sadly, Joel will no longer be blogging, citing the need to focus on his growing software company. His musings on software development will be missed.

Mockito's @InjectMocks annotation does reflection-based DI

I've been using @InjectMocks heavily lately since it came out in version 1.8.3 of mockito. The javadocs for this annotation state that it uses setter injection to inject its dependencies. Being a lazy developer, I was writing a unit test yesterday at work and forgot to write the setter methods for a couple of dependencies on the SUT that I was testing. Lo and behold, the test passed and all mock verifications were satisfied. Very confused, I went back to some other unit tests and their SUTs and removed the setter methods. In all of my cases, the tests continued to pass. A quick note to the mockito list confirms what I discovered--@InjectMocks actually is using a reflection-based DI scheme, not unlike what Spring does when you annotate collaborator fields in a Spring bean with @Autowired and @Resource. Very cool feature, as this further reduces code noise. Here is the discussion on Google Groups.

Cool features in Cucumber, part 1

My Cucumber adventure (via cuke4duke) continues. I have been busy writing features and building out step definitions in Groovy. Groovy absolutely rocks for this sort of thing. I'm doing some more elaborate Cucumber features (at least in my novice head) and came upon this blog posting. Very handy stuff. More related to the Ruby version of Cucumber, but most of the concepts transfer over to cuke4duke.

PeepCode screencast: Use the Cucumber

I've been interested in acceptance testing tools recently and Cucumber has been at the top of my list. PeepCode recently released a screencast on Cucumber. I've viewing it right now; the screencast is excellent and a nice introduction to Cucumber. I'm thinking of using it on a Grails web app. The screencast is based on a Rails 2 web application, which Cucumber seems to integration seamlessly with. Supposedly Cucumber is technology agnostic and works against any sort of web application.

CoverScout for retrieving iTunes album art

I recently purchased the MacHeist nanoBundle, a collection of Mac OS X applications and utilities. One of the utilities included in the bundle is CoverScout, a utility that will allow you to browse your iTunes library and retrieve hard to find album art. I have a fairly large collection of music and iTunes has been pretty average in its attempts to find album art. CoverScout will retrieve album art from many different sources and allow you to select which image to use. The images are also rated by quality. Very cool utility.

New annotations in mockito 1.8.3

Mockito 1.8.3 was recently released and I got a chance to use it today. There are a couple of new annotations available in this release: @Captor, @Spy, and @InjectMocks. I was able to use @Captor and @InjectMocks today. Even after just a few minutes with these two annotations, I'm sold. Very cool enhancement. I spent some quality time with EasyMock last week, and there's nothing easy with EasyMock. Ugh!! If you're hip to using mock objects in your Java unit testing efforts, you really should look at mockito these days. Details about @Captor and @InjectMocks follows.

@Captor

This annotation will automatically create typed argument captors (org.mockito.ArgumentCaptor<T>) in your unit tests. Argument captors are essential in verifying indirect outputs to your mocked collaborators.

public class Test{
    @Captor ArgumentCaptor<Foobar> foobarCaptor;

    @Before
    public void init(){
       MockitoAnnotations.init(this);
    }

    @Test 
    public void shouldDoSomethingUseful() {
       //...
       verify(mock.doStuff(foorbarCaptor.capture()));
       Foobar capturedFoobar = foobarCaptor.getValue();
       assertEquals("foobar", capturedFoobar.getName());
    }
 }

@InjectMocks

Automatically injects mocks by type using setter injection. Constructor injection is not currently available, but if you want to provide a patch, the mockito team will gladly consider your contribution. I'm actually more interested in reflection-based injection, similar to what Spring uses when annotating dependency fields using @Autowired. Having your unit tests inject dependencies via reflection would help me avoid the set* methods on the implementations. I may have to play with this a bit.

public class FooBarManagerTests  {

       @Mock private FooDependency mockFoo;
       @Mock private BarDependency mockBar;
       @InjectMocks private FooBarManager manager = new FooBarManagerImpl();

       @Before 
       public void initMocks() {
           // Initializes all mocks and then injects those mocks into the FooManager instance.
           MockitoAnnotations.initMocks(this);
       }

       @Test 
       public void shouldDoSomething() {
           manager.doSomething();
           verify(mockFoo).doSomethingToFoo(any(String.class));
           verify(mockBar).doSomethingToBar(any(Integer.class));
       }
   }

Gerard Meszaros "From Concept to Product Backlog" talk

I just finished up an InfoQ presentation by Gerard Meszaros discussing how to go from the conceptualization of a project to the manifestation of a product backlog. I really enjoyed the presentation and it hits on some gray areas of current agile implementations that I have worked on. Highly recommended.

Adopting Agility with XP, Scrum and Lean Thinking - Powered by RegOnline

David Hussman is leading an agile course next week. Still room for participants to register.


Adopting Agility with XP, Scrum and Lean Thinking

DevJam course offerings for February-March 2010

David Hussman recently posted the new DevJam course offerings for February and March 2010. I'll be leading the Introduction to Groovy, Introduction to Grails and Test Driven courses. The Test Driven course is open to Java and .NET developers (.NET examples in C#). Detailed information can be found at http://www.devjam.com/courses-and-training/index.php. Seating is limited to about 12 participants per course.

IntelliJ IDEA 9 as an Adobe Flex IDE

If you're on the fence about paying for a license for IntelliJ IDEA, here is one more reason to justify the cost of the license. Adobe Flex. I've spent just a little time with it and the Flex 4 Beta 2 SDK and I must admit, IntelliJ as a Flex IDE rocks. Much better than Flex Builder 3. You don't get a Design View with IntelliJ, but I never used it in Flex Builder and it seems of dubious value.

I can't comment on how it stacks up against Flash Builder 4, but Flex development in IntelliJ is a joy. I'll post more as a I get a chance to use it some more.

Are you cultivating your software development expert mind?

What are you doing to build your proficiency in software development? It's something I've been interested in lately. How do you develop an expert mind in software development? I spend my day consulting and I notice that most of the people that I develop software solutions with day-to-day do not spend any time outside of work cultivating their development skills. I'm somewhat dumbfounded by this phenomenon. Is this commonplace elsewhere?

I spend a fair amount of time reading books and then applying the reading to personal coding projects. Typically I have used these projects to learn a new technology. Recently I've started working through Dave Thomas's Code Katas. From Dave's Code Kata website:

Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer.

So, again, what are you doing to practice software development?

Not a fan of Apple's new Magic Mouse

I recently purchased the new Apple Magic Mouse and after about a week of on and off use, I'm not a fan of it. For me, the laser tracking is terrible. I thought it might be the desk so I bought a mouse pad (remember those) and though the mouse pad made tracking a bit better, the Magic Mouse laser tracking performance is irritatingly poor on both the desk and mouse pad surfaces. It's a beautiful device, but it's basic performance is just terrible from my experiences with it. I'm going to hang onto it for a while and see if the driver support gets better over time.

Anyone else seeing issues with the basic laser tracking performance?

Using argument matchers in EasyMock and mockito

I spent some quality time with EasyMock today while coaching some developers on building tests around an existing codebase. We were mocking a dependency of our SUT and the method call that we wanted to mock had two parameters. When we wrote the expectation, we used the anyObject() matcher for the first parameter and tried to perform an exact match on the second parameter, a Boolean. Here is an example of what we were trying to do in EasyMock (NOTE: we statically imported EasyMock so we could reduce the amount of code noise by not prefacing our expect, matcher, replay and verify invocations with EasyMock.):


expect(mockObject.retrieveSomething((String) anyObject(), false)).andReturn(someObject);


Unfortunately, EasyMock and mockito do not like this. They both want you to use matchers for all parameters if you use matchers for any parameters. However, the two libraries react quite differently when this situation occurs. EasyMock complains with a somewhat confusing message that at first blush makes it seem like we declared the expectation for multiple invocations. It really threw us off for a while (at least an hour) trying to figure out what was wrong with our expectations. Here is how we fixed it in EasyMock:


expect(mockObject.retrieveSomething((String) anyObject(), eq(false))).andReturn(someObject);


Mockito does a much better job of stating that when you use a parameter argument matcher in your expectation, you have to use parameter argument matchers for all of the parameters of the method call participating in the expectation. I find it interesting that mockito retains the behavior of EasyMock (mockito is a fork of EasyMock) with regards to argument matching, but mockito improves on the error messaging when something goes wrong with the mock object setup. Further reinforces my decision to forego EasyMock in favor of mockito.

Getting a handle on code quality with Sonar

I've been working with a client recently who uses Sonar, an open source code quality management platform hosted at Codehaus. I'm thoroughly impressed with this tool. If you want to see what the tool can do without investing the time in installing it, take a look at the various screencasts. They also have a live version of Sonar up so you can play with it without installation.

We've been working on getting unit tests built around a legacy code base and Sonar has been a big help in identifying classes that are the biggest code coverage offenders. We used the Clouds feature, a word cloud that weights the class names in the cloud based on code coverage and complexity. The less test coverage on the class and/or the more complex the class, the larger the weight of that class name word in the word cloud. It really helped us focus on where to direct our testing efforts.

I have yet to get this tool up and running in one of my own projects, but things are finally starting to simmer down now with consulting and training activities that I hope to focus on building out a CI environment using Hudson and hooking in Sonar to that environment. Stay tuned.

Promoting keystroke use in Eclipse

If you want to promote key mappings use in Eclipse, MouseFeed might be your ticket. This Eclipse plugin monitors your mouse usage, and when you click on a UI component (button, menu, etc.) that can be invoked by key stroke, the MouseFeed plugin will pop up a small notification window stating that the action has a key mapping. The notification window disappears after a few seconds, but it's power is obvious. Very similar to the Key Promoter plugin in IntelliJ IDEA. Very cool Eclipse plugin.

Here is a screencast of the MouseFeed plugin in action:

Completed another Test Driven and Refactoring course for DevJam

This time using C# and the .NET platform. The course went over really well, though we did have some small snafus with the training area in the DevJam office. Nothing that can't be tweaked. I had 15 participants in this class. All participants pair programmed when completing the hand-on exercises and again, I'm totally amazed at how well pair programming goes over when you get people away from their normal work environment. Everyone really grooved on the pair programming thing.

One area that we will need to work on is the mock objects content. We don't have any hands-on exercises for using mock objects and we heard about it in the reviews of the course. I did walk everyone through a demonstration of using mock objects in your unit tests, but I mis-gauged how much interest the participants had in mock objects and the desire to get their feet wet with mock objects. Some of the class participants stay after the course ended and we did another 40 minutes of live coding demos on the use and features of mock objects (using moq for the mocking framework in .NET).

All in all, an awesome two days for me and hopefully for the course participants.

Test Driven and Refactoring class in Chicago

Completed a two day Test Driven and Refactoring class in Chicago today. The class went really well and I think I really was able to get a few developers to come down off the TDD fence and really buy into it. That is always satisfying. The class was again offered by DevJam.

I did have a few participants that actually bowed out after the first day of training. One in particular was very abstinent about not writing tests and really does not believe unit testing and TDD in particular are useful in software development. This person was very much in favor of big design up front. This person's views really threw me for a loop. The group that I gave the training to has significant issues with quality, so the view of testing not worth the effort seemed very ironic in this situation. Needless to say, I was not able to get this person to realize how unit testing and TDD help you in the design process. Oh well, you can't win them all over.

I heard a lot of good feedback around the mock objects example that I demonstrated. In this example, I demonstrated not only behavior verification with the mock objects, but also was able to demonstrate capturing indirect outputs on the mock objects and then verifying the state of these indirect outputs. I used mockito 1.8 for the demo. All in all a great class.

Second Groovy and Grails training in the bag

Completed my second Groovy and Grails training for DevJam this past Saturday. This training session was much smoother than the first training. Still too much material and exercises to be taught in just one day. Received a lot of good feedback from the participants and hopefully this feedback helps solidify the training. I'm always amazed at how much stuff I could focus in on for the Groovy training. Really need to beef up the meata-object protocol stuff in the Groovy training.

Using the new Groovy-Eclipse V2 plugin

Started using the new Groovy-Eclipse V2 plugin. I'm continuing to fine tune some Groovy training that I've come up with in collaboration with DevJam. So far so good. Seems to work pretty well. I'm not expecting much at the moment, but the alpha seems pretty stable. We need an open source Groovy IDE for the training, and I would love to use Eclipse and this plugin to fulfill that role. I think I still prefer IntelliJ for Groovy stuff (it seems more mature), but it costs some money and most people are using Eclipse these days.

First Groovy and Grails training is in the bag

I made it through my first test run of Groovy and Grails training for DevJam this past Saturday. Had a couple of snafus occur. Nothing major and easily fixed. Did learn a couple of things though:

Don't put developers on an operating system that they don't know for training

The DevJam training has Mac minis which boot either Mac OS X Snow Leopard or Windows Vista (via Bootcamp). I had the systems booted to Mac OS X for the training. Unfortunately all of the developers that came to this training were unfamiliar with Mac OS X, but willing to try it. Bad move on my part. I ended up answering far too many questions on the operating system and which tools were were going to use. Oracle SQL Developer also gave me problems in the Mac OS X environment when trying to update the tool with the MySQL drivers through its software updating system.

If you think you have enough code examples, you don't!

I had about 10-12 Groovy code examples to demonstrate various features of the language. Far too few for the questions that cropped up. Luckily, it was Groovy and writing new code examples or changing existing code examples was pretty straightforward. Kudos to Groovy for being very easy to explore and play with. The participants thought very highly of the interactiveness of the coding during the session.

Don't try to do both Groovy and Grails in a single day.

I knew going in that doing both was going to be very difficult. I just didn't realize how difficult it would be. Again, due to operating system and tool snafus, I didn't finish up the Groovy stuff until well into the afternoon. Not much time for Grails. I was looking forward to the exercise in Grails and we didn't get very far with it.

Automate the packaging of the student materials in electronic format.

We decided to put all the training handouts, examples, and anything else helpful for the students on 4 GB flash drives and give the flash drives to the students to keep. That's good. What's not good is missing some things on the flash drive and updating flash drives during the course. Next time I'll use an Ant build script to build a distribution and clean out any Subversion metadata from the student materials.

The Groovy Eclipse plugin seems to be making headway.

One of the participants in the group, Nick Spilman, had his laptop along and was using Eclipse Galileo and the new Groovy Eclipse plugin during the Groovy portion of the training. He thought it worked well with Groovy. I used IntelliJ 9.0 EAP (Maia) and that also works well. Looks like SpringSource (or shall I say VMware now) is getting serious on the tooling for Groovy and Grails.

Need to spend more time on understanding Groovy's meta-programming facilities.

It's one thing to use Groovy and use its meta-programming faclities (aka MOP) successfully in your own work. It is a far different thing to try and teach others about Groovy's meta-programming facilities. Teaching a concept, especially a concept as complicated as meta-programming, is extremely difficult.

Performing test runs of presentations and trainings is essential.

I'm very pleased that I was afforded the opportunity to be able to offer a couple of test runs of this training to some developers before offering it to the public. Like anything else, it takes practice and feedback to get good at something. I have another test run of this training later this month and I'm sure it will be much better than it was the first time out.