More Time Saved By Unit Tests

So I’ve been meaning to make a fix in one of my projects for a while, and I haven’t touched the code in over a year, so of course I have to go back and really get back up to speed with the code. The change was for the Datavalve project and it was to include support for passing in collections and using in SQL Statements, so now you can use something like :

provider.addRestriction("item.statusCode in (:param)", stateCodeList);

This will cause the list of codes to be expanded into an in SQL statement including checking to exclude null items, and as usual, the restriction is not included if the code list is null or contains only null items.

So I have two problems, the first is getting back up to speed on my code, figuring out where the make the change, and making it. The second is making sure my code changes don’t break anything thats currently working.

For the first problem, I decide to create the unit tests first so I can verify that the change does as expected. Obviously, the tests fail initially, but by looking at the code executed by the tests, I can start to pick out places where I need to start looking to add the new code. After all, tests measure the correctness of the state after the code has been executed. What better place to start looking than seeing what code the test executes. After finding the method that I need to change, I make my code changes and run my tests. All my original tests pass with flying colors, but my new test fails. I take a peek and sure enough I left off the last line of code to add the built object to a list. I put it in, and I have all my tests up and running.

All in all, I’ve made a large change to some sizable (12K+ LOC) code that I haven’t seen in over a year, verified that the change works and that it hasn’t impacted any other code. Not bad for an hour.

I’m Back

So I’ve been on a bit of break from blogging, I’ve had lots of things going on, I’ve moved house twice, and changed jobs a couple of times. I’ve not even really been checking my email that much (as evidenced by the fact that I didn’t see my hosting invoices and the subsequent temporary suspension of my blogging web site). I’ve been spending time with the family over summer and taking a bit of a break from the extra-curricular IT work. I’ve also been doing some thinking on which direction I want to go in my career. Because of all this, If you’ve emailed, or sent a LinkedIn request that I’ve done nothing with, that’s why. However, things have been hotting up in my absence so there’s certainly a lot of topics to delve into.

Update

I haven’t been writing for a while since I’ve been busy working on several things right now.

First off, after a few months of job hunting, I’ve changed jobs, I’m now doing some Java contract work down in Pittsburgh. After 11 years at my old job, it was time to move on. The great thing about contract work is the opportunity to work on a lot of different projects in a lot of different places. After being stuck in Cleveland for 11 years, we are ready for some changes.

I also want to try and get into doing some more Java EE 6 and CDI training. A lot of people are unsure of how it is all meant to work together and are missing out on the real beauty and simplicity of working with these frameworks.

Rick, Rob and I have been doing some more work with CDISource and anticipate a release of our source in the next few weeks. Once thats out, I want to start playing with some of the Seam 3 stuff especially with regards to CDI. We announced CDISource and then all of a sudden we all got busy with different things, and we have some code we want to release for which we have a number of articles to write.

Between moving, unpacking, starting a new gig, which always fries the brain for a few weeks, and having my Mum over from Manchester,England, I haven’t really been having time to write or work on projects.

I have a new release of the Knappsack almost ready to go which includes Spring based archetypes and also a Java EE 6 EAR archetype as well as a couple of new posts.

Get yourself a reputation at work

For most of us, as programmers, we are a pretty lucky bunch. We get paid handsomely (or at least nicely) for doing something which we enjoy, will never go out of fashion and provides a great deal of benefit to the companies we do it for, if not the world at large. While we may not be working in the IT fields we want to be working in or for the companies we want to be working for, we still get to enjoy the process of writing code on a daily basis for a living.
Read More »

Announcing CDISource

In the last few weeks I have been rather busy working on a new project with Rick Hightower, who is fairly well known for his training and writings on Spring and JSF, and Rob WIlliams who is a blogger known as much for meddling in new technologies (and getting mad at them) as he is for intertwining various historical and literary references in his posts. The result of this is the CDISource project which aims to advocate and facilitate the use of the JSR 299 – Java Contexts and Dependency Injection framework across the Java landscape.

If you’ve seen my posts or my site before, you’ll no doubt be aware that I have written at great length about Java EE 6, JSF, CDI , EJB and so on. What I haven’t written about is the many frustrations I’ve come up against in dealing with these frameworks on their own and especially when combined, or how their usefulness is often constrained to the application server container.

Java EE in some ways is an archipelago of frameworks that lacks the cohesiveness and all in one wide screen vision that software developers need. Java EE is about the enterprise, in reality its about the web, or even more specifically about Java EE containers. There’s a whole slew of uses for a good type safe and flexible dependency injection and AOP framework and such as CDI outside of Java EE containers but there is very little information and code to make it actually work.

Our goal is to make CDI useful and usable on its own without Java EE 6, and to give developers the tools and information to do so. To let them write vendor neutral and portable code, and apply agile and best practices. Developers know how to write good software and don’t want to sacrifice that for the sake of using a framework to make things easier. To that end we aim to provide code and information that will help facilitate those practices.

There will be some learning for ourselves along the way and we will have to change some of our previously held concepts. I know over the last few weeks having been getting CDI working and useful outside of the web container it has really altered my perspective on how I think about the dependencies and structure in CDI applications. My perspective has changed even more than when I wrote A Little Less Conversation.

As much as I hate to say it, we did come up with a mission statement, although we found it fairly easy and enjoyable to clearly defined the goals and attitudes of the project.

Our mission is to :

  • Promote and facilitate the use of the Java Context and Dependency Injection (CDI) framework in relation to as many aspects of application development as possible.
  • Enable developers to take advantage of CDI independently of Java EE.
  • Provide lightweight, lean and agile access to the underlying CDI container as a core principle in our efforts.
  • Make testing easy without requiring a complex set of tools or complex deployment scenarios.
  • Enhance both Java EE development as well as the use of CDI in non Java EE application where possible.
  • Promote and enable the use of CDI in a vendor neutral environment and maximize the portability of application code across CDI implementations.
  • Not reject the ideas of Java EE but expand the usability of CDI outside the borders of Java EE application servers with frameworks that are not a part of the specification.
  • Not reject other CDI efforts but to provide another venue to promote those efforts. This is an addition. This is another voice in support of CDI.

We are pretty excited that so far we have been able to live up to the intent of our mission statement with everything we’ve done so far. Over the next few days and weeks you will see articles and tutorials come out of Rick, Rob and I as we write about the CDISource project and we start to showcase some of the code we have written and start giving you an idea of where we are heading.

Right now we have vendor neutral support for starting up CDI outside of the web container and also for testing CDI beans with minimal configuration and intrusion on your test cases. We also have a few other pieces that are nearly ready, as well as dozens of ideas to get started on.

You can start by looking at Ricks brand new introduction of CDI over on JavaLobby.