Coding Frontier

Code Coverage Goals

I haven't talked about it yet on this blog, but I am a big fan of unit testing. If you care about the quality of your system, all code should always be tested. I hear this excuse and that from my fellow developers about why certain code wasn't covered. Maybe they don't have time. Maybe they don't believe it is worth the hassle. Maybe it was "too hard". The bottom line is that, for whatever reason, unit testing just wasn't a priority.

Enter management. In their infinite wisdom, they decide to inspire developers to start writing unit tests by creating a performance metric based on code coverage. This will surely fix the problem, right? Now that the test coverage is tied to the year-end bonuses, the developers will definitely make writing them a priority!

Why Code Coverage Goals are Bad for Your System

You need to be very careful when you make performance metrics for code quality. If you make a goal around executing lines of code in unit tests, then that is exactly what you will get. Instead of writing tests based on the requirements or what the code is supposed to do, they will be based on the gaps in the coverage reports.

Developers will start executing code left and right but that doesn't mean that there were actually any tests or that any of this code is verified in any way. What it means is that it was executed. There is no guarantee that any asserts were included or meaningful. There is no guarantee that exceptions aren't caught and ignored. There is no guarantee whatsoever that any of that code was, in fact, tested in any way.

This is considerably worse than not having test coverage in the first place. At least when the code isn't covered, you know exactly what was tested and what wasn't. When everything is being executed, you no longer have any clue what is actually being verified. You are right back to square one when you had no testing whatsoever.

Why Code Coverage Goals are Bad for Your Staff

For starters, motivating people with money is easy, but not effective. If your employees work at your company for the money, then their loyalty is to the money and you will have a very tenuous relationship with them. Not only that, but when someone else offers them more money, they will jump ship in a heartbeat. Oh, and you don't have the best pay in town. You may think your package is "highly competitive", but there is always someone who will pay more than you do and you can rest assured that once your employees figure out who that is you will lose them.

I read a great post about this on the Venture Hacks blog called We don’t pay you to work here. It profiles a book called Hidden Value that goes into great depth about this. I would highly recommend you at least read their post on it. Ultimately it boils down to the fact that money only motivates people to quest for more money.

So What Should We Do?

The root of the problem is not that the system is not covered by unit tests, but that your developers don't believe in unit testing and hold it as priority #1. Installing monetary goals around coverage numbers will do little for your application and only serve to annoy your developers. If you need a measurable goal, a better one might be how many defects are found by your QA department and remind people that if the code is properly unit tested, the defect numbers will be considerably lower, if not zero. 

The only solution to the problem, however, is to get your developers to believe that it is essential. Changing people's beliefs is a hard thing to do. The first step is to make it clear that it is important to the company and not just by saying it, but by acting on it.

My recommendation: check the project plan. It needs to be considered the flagship part of the development life cycle. If unit testing isn't a major part at the start of development, then you are sending a clear message that it isn't really that important to the company after all.

Easy Rewards for Good Behavior

I worked on a project a few months ago that sucked the life out of everyone involved. I'm sure you know the kind. It was one of those with a severely condensed timeline because it was horrendously underestimated prior to any work beginning. There were lots of moving parts and separate teams working on things simultaneously, all of which needed to go in correctly otherwise everything was in vain. My team busted our asses for months and got the project knocked out, on time, and without any production issues. The other team dropped the ball and my team had to pick up the slack. In the end though, we all got it done and we got it done right.

That was wonderful! We were all very excited and all glad that we actually accomplished this seemingly insurmountable feat. Once all was said and done, however, we didn't hear a peep from management. Not even a, "Great job!" Nothing. But that's fine. I like to be busy and had a great time on the project, although you may not have known it if you spoke to me at the time. When I am under an abnormally gigantic amount of stress, like most people, I am not always chipper.

Anyway, our PMP thought we did such a fantastic job that she ran it up the flagpole and tried to get the team a reward for going above and beyond. It almost made it through, but was crushed by the CFO. Again though, that's fine. I really don't expect to get any extra rewards for doing my job. I mean, I am just doing job after all. For some reason though, this project came back to haunt me tonight. I was thinking about everything we went through and how passionate the PMP was about getting us a reward for the work we did. I got to thinking that there is a really simple and meaningful way to reward professionals for doing great work and it doesn't cost a thing.

All you have to do is go onto LinkedIn and write a recommendation. It only takes a few minutes and is actually a meaningful thing to have. It is something personal that another professional wrote about you and that you can carry with you for your entire career. It is something that shouldn't be copy-and-pasted from the letter provided with the Corporate Bullshit Award, or whatever nonsense your company gives out to people, but something specific about that person and what they accomplished. Maybe some people wouldn't care, but I think that knowing that someone took a few minutes out of their day and wrote an unsolicited open and public letter about you would mean a lot.

I don't blame that PMP or anyone else for not writing a recommendation in that instance. I mean, I just now thought of it and this all happened months ago. What I do take away from this is that the next time I see someone else going above and beyond the call of duty in a meaningful way, I need to write one for them without having been asked. It is nice to share a little love once and a while. Pass some along and maybe you'll get some back.

jQuery Extensions Aren't Just for Plugins

I don't typically think about extending jQuery for page specific code. Normally I reserve that for plugin authoring, but I was working on a screen the other night and I found myself calling a function in a few places and passing it a jQuery object.  This function would iterate over the elements and do blabady-blah whatever.  I realized that I could make this a whole lot cleaner by writing it instead as a method on the jQuery object. Originally it looked something like this: [js]var MyPage = {   actOnItems: function(items) {     $(items).each(function() {       ...     });   },   needsToActOnItems: function() {     MyPage.actOnItems($("div :input"));   } };[/js] That isn't a bad way to do it necessarily, but I think it makes the code a lot simpler and cleaner to read if I just extend jQuery with the method instead. [js](function($) {   $.fn.actOnItems: function() {     return this.each(function() {       ...     });   }; })(jQuery); var MyPage = {   needsToActOnItems: function() {     $("div :input").actOnItems();   } };[/js] The jQuery extension stays with the rest of the page specific JavaScript, but now we have abstracted it out so it can be used like any other jQuery method. This also allows us to chain it and reduce the risk of confusing the future maintainer of the code. Be careful not to go crazy with this though. As with anything, only do it when and where it makes sense.

Rounding to a Decimal Place with ruby-units

I am working on a project that involves a number of unit conversions and so I started using ruby-units to facilitate.  It is a really flexible library that is really easy to use...I would highly recommend it if you have any need for conversions.  I did run into a small issue with it though.  I needed to take some value, say 160 kg, and convert it to pounds.  That yields the beautiful value of 352.739619 pounds.  I need it to be in a %.1f format, and calling .to_s("%.1f") works great if it is a decimal like that.  I also needed whole numbers, like 160 kg to show up as "160 kg" and not "160.0 kg".  Normally not a big deal.  The good ol' brute force multiply-round-divide trick should work, right?  

Well, not really, unfortunately.  When you divide certain types of Units, it may keep it as a fraction if it doesn't divide evenly.  For example...

("160kg".unit.to('lbs') * 10).round / 10  #=> 3527/10 lbs

That isn't what I want, of course.  After trying to finagle this one way or another, it finally dawned on me that there is a simple, albeit inefficient, solution to this.

"160kg".unit.to('lbs').to_s("%.1f").unit  #=> 352.7 lbs

That's it.  Just to_s and then back to a unit.  It will round off the zero automatically if it was a ".0".

Apache CXF and Variable Paths

In most situations, a REST service would be set up with a concrete path and known number of path elements. On occasion, however, we may need to implement a service with a variable path. Maybe it is for a series of search parameters or, as is my case, an actual file path needs to be provided. There is great support for the known paths. You just type it in the Path annotation and tell it where the variables are. Easy. Well, for unknown paths things get a little hairier, although the solution is still simple and not as ugly as it could be. Let's look at an example for encoding a URL that looks like this:   http://codingfrontier.blogspot.com/subsystem/get/path/to/file/somewhere/in/the/system As always, we start with our Path annotation. We have already set up the path for "subsystem" at the class level, so on the method that we want to receive the multi-element parameter we need to set our Path annotation to accept the rest of the URL, whatever that may be, and do something a little dirty in our receiving method.   Path("get/.*")
  public void get(@Context UriInfo uriInfo) {     String pathParam = uriInfo.getPath().replaceAll(".*/get/","");     ...   } Calling uriInfo.getPath() will give us the entire path, so we are using a simple regex to strip the constant portion off the beginning of the string.  This will provide us with the entire rest of the string to do with as we please. Accessing the UriInfo this way is less than desirable, but in this case it gets the job done. If you need a cleaner way of accessing each parameter without having to parse them yourself, you can get to them directly as well.   public void get(@Context UriInfo uriInfo) {     String firstParam = uriInfo.getPathSegments().get(0).getPath();     ...   }
It isn't very elegant, but it gives you the flexibility to write some really fancy REST services with dynamic URLs.  I don't normally like to step out of the framework like that, but it is nice to have the flexibility to do so when the need arises.

jQuery Custom Event Handlers to the Rescue!

What do we do when we have a form that is highly customizable based on numerous inputs on the screen and needs to change on the fly as the user selects different options? First we curse at the business people who dreamed this up. Then we go get some coffee (or wine if we are working from home). Finally, we leverage jQuery to make what could be a tangled mess of tightly coupled JavaScript into distinct loosely coupled components that don't know or care about each other.

In this case, we will look at just one of the many fields on the hypothetical screen that is causing so much grief.  Let's say that the Driver field has a few dozen possible values and each of those values has a number of configurations associated with it that are stored all over creation in the back-end legacy system.  Our first thought might be to dump all the possible configurations into the page and write a large amount of complex javascript to find the right configurations on change and adjust the screen accordingly.  Then it hits us...we are professionals and actually know how to build robust solutions.

Our second thought leverages the awesome power of jQuery to make this daunting task fairly simple.  Our Driver select is populated on page load with all the possible values, so we don't need to worry about that.  All we need to do is make an Ajax call to our back-end system that will gather all the configurations and jam them into a JSON representation of the Driver object, then fire a custom event handler when the response comes back that has listeners that will run custom logic for each component on the screen.  It would all look something like this:

var Driver = {   init: function() {     $("select[name='Driver']").change(Driver.get);

  },
  get: function() {
    $.getJSON("/drivers", { id: this.value }, Driver.update);
  },
  update: function(driver) {
    if (driver && driver.value == $("select[name='Driver']").val()) {
      //Do whatever needs to be done here...
      //Invoke the custom event when the Ajax return is ready.
      $("select[name='Driver']").invoke("driver_callback", driver);
    }
  }
}; $(Driver.init);
var Passenger = {
  init: function() {
    $("select[name='Driver']").bind("driver_callback", Passenger.update);
  },
  update: function(event, driver) {
    if (driver && driver.passenger) {
      //fancy logic here
    }
  }
}
$(Passenger.init);
The first thing to note is that we have created two objects that are somewhat analogous to static classes in other languages.  These are meant to represent the functionality of the distinct fields. Each one has an "init" function that is called when the DOM is ready.  In both objects, the init method is used to attach event handlers wherever necessary.

In the Driver object, the important thing to note is the "update" function.  This performs two tasks.  One is to verify that the JSON object we got back actually matches the currently selected value on the screen.  This is merely a safeguard for when the user selects more than once in quick succession and the server cannot respond in time or responds out of order.  The other is the invocation of the "driver_callback" event handler.  This will cause anything that was bound to the Driver select with that handler name to be executed and passed the JSON object. This allows flexibility for some "js" files to be loaded and attach the event handlers prior to the existence of the Driver object in the JavaScript.

The Passenger object binds to the "driver_callback" event in the init method.  This is a good way to do it because it maintains the loose coupling with the Driver field.  Whether that field actually exists or the driver_callback ever gets fired doesn't really matter.  That allows us to include a lot of functionality in this "js" file for multiple screens and only the logic that is relevant to this screen will be invoked.  Also, we can have any number of methods bound to that event, so we can switch out functionality just by changing JavaScript include tags.

How Technology Choice Can Impact Your Design

Whenever we consider using a new framework, library, or technology, we always take a look to see what features it has, how fast it is, how it impacts our memory footprint, etc. We tend to focus on how the technology meets our current needs but sometimes forget to consider how the usage of this technology will impact the design of our system going forward. Whenever we incorporate something new, we also adjust how we do things to match what the technology is expecting. If you don’t, most often you will seriously regret it later when you have to jump through fiery hoops to get simple things to work. When dealing with the client layer, this becomes a highly visible change to your system...not by the user but by anyone looking under the hood. For example, when you start using Prototype, you will most likely also start using a lot of ids in your DOM. We do this because Prototype provides us with the handy $(“id”) function, which encourages us to reference individual elements. This also allows us to continue writing the rest of our JavaScript in a procedural manner. The entire library is designed around working on individual elements in the DOM and not groups. Sure they provide $$ for CSS selectors and the invoke function for dealing with arrays, but whenever I use Prototype I feel like this was an afterthought. Although being a more verbose way to write JavaScript, it allows us to write in much the same manner that we do on the back end. Whether your system is Java, .NET, or Ruby, the vast majority of your developers are probably not very functionally oriented. This style is also largely due to Prototype’s origins with Ruby on Rails. Prototype works in a very Ruby-esque manner in many ways, such as how it enhances existing DOM elements instead of just encapsulating them and providing new objects. When we work with jQuery on the other hand, we see a complete 180 on the approach. There is no distinction between a single element or many. Everything is accessed through a CSS selector, so you no longer feel the need to reference DOM elements individually. Also, DOM elements are not enhanced, they are encapsulated by the jQuery object. When we use the $ function, we always get a jQuery object back, so there is little need to check for results or loop through the elements. We simply invoke methods directly on the results and it works the same whether there were 0, 1, or a thousand objects returned. The entire framework is designed around the however-many concept, which encourages us to think differently about the DOM and our JavaScript. Because of the CSS-selector-only approach, I find myself using very few ids at all and the way my functions end up is completely different than it would be if I had used Prototype. I end up taking more time to analyze the DOM to keep it cleaner and more lightweight. I make very heavy use of CSS selectors and when I use the “colon” attributes, I end up eliminating the need to perform checks on the returned objects. All in all, my DOM and JavaScript end up being much more condensed when I write with that mindset. I am not saying that one approach is better than the other, just that it drives many other decisions and the way other aspects of the system will be implemented. The next time you find yourself evaluating a new technology, remember not just to look at how it meets your needs, but what impact it will have on the way you do things going forward.

CSS? The DOM? I'm a developer. I don't care about that.

This is the common mindset of most developers. Most of us think that the DOM and CSS are just output from the server that gets displayed in the browser. I know, I used to be in that camp. It used to be easy to ignore it and get it just good enough so that it would look right in IE. We have been going like that for years now and it has been working, right? Well, not really. As we see Web 2.0 applications becoming more and more common, that mindset is becoming very troublesome for both development and maintainability. JavaScript has become a large piece of most sites and if it isn't well designed and reusable, it can easily become an unwieldy beast. This is where CSS selectors enter the scene to help us write more compact JavaScript that is loosely coupled to any given page. The DOM and CSS now play an important role as metadata to drive the JavaScript. Using a library like jQuery or Prototype, you can reduce most, if not all, of the utility code that you would normally have to write yourself. You also get cross-browser compatibility as an added bonus. By far the most important aspect of these libraries, however, is the ease of using CSS selectors to gather DOM elements. We can now look at CSS classes as more than just aliases for style tags...they can be used to flag DOM elements for easy manipulation by your JavaScript. For example, let's say you are displaying some sort of data list on your screen that has some singular items and others that are expandable groups. In the old days, you would most likely put an onclick="..." attribute somewhere on the expandable items and embed some JavaScript on your page to show and hide the elements. By using a CSS selector instead, you can separate your JavaScript completely from the DOM and flag the expandable items with a CSS class. If the class name is "expandable", the code might look something like this: $(".expandable").click(function() { $(this).next().toggle(); }); Using jQuery in this instance, we have written some very simple and easily readable JavaScript that can be applied on any page whether there is an expandable class present in the DOM or not. We also avoided generating JavaScript from our back end code, which helps keep our codebase cleaner and makes it easy to unit test our JavaScript. This code can now be moved to an external file, minified, and gzipped to reduce the payload sent to the client. Also remember that when you embed onclick elements in your DOM, you are repeating code over and over and preventing it from being cached, increasing load times and bandwidth usage. The above example is just the tip of the iceberg with what can be accomplished with CSS selectors. Classes are just one of the many things you can key off of, so if we had some more complex logic that required us to run the "foo" function on page load for all text input tags, anchor tags with a rel attribute of "crazy", a div with an id of "meatball", and images with an alt attribute containing the text, "chocolate", we might do something like this: $(document).ready(function() { $(":text, a[rel='crazy'], div#meatball, img[alt*='chocolate']").each(foo); }); As you can see, this is a very versatile and powerful tool. We need to get out of the mindset of purely imperative coding in our JavaScript to take full advantage, but once we do a whole new world is opened up. Now that we see how CSS can be leveraged by our JavaScript, how does the structure of the DOM fit into all this? First, having a simple DOM means that you will have simpler selectors when you are dealing with more complex logic. Second, keeping your DOM lean will allow you traverse the elements very easily. In the first example, I am assuming that the DOM element that is "expandable" is immediately followed by the element that will be toggled on and off, allowing me to simply call "next()" on the result of the selector and move to the next element. Let's say we are doing something a little more complicated, such as a row that contains a clear button and five inputs that may be text, selects, or a combination of the two. Traditionally, we might hard code the names of the inputs and run a "input_name.value = '';" for each one in the onclick for the clear button. Using jQuery, we might do something like this instead: $("a.clear").click(function() { $(this).nextAll(":input").val(''); }); Once again, we have taken something that would have been a horrible hard-coded mess and turned it into something easily reusable on multiple pages. We cringe at the thought of hard coding, duplicating logic, and writing unreadable code on the back-end, so why do we so often write it that way on the front-end?