Tech Ramblings and more...

I test therefore I code: Intro

2009-06-15T15:11:00.000-06:00

This is the first post of a series of articles, where I'm going to talk about developer testing, why I think it's important and its practical application in Java programming.

For this first article I was prepared to start quoting books about what developer testing is and start laying a foundation for next deliveries, but then I reconsidered and decided to take another approach. I'm going to tell you why I like developer testing and why I think it deeply impacts the quality of the software we write.

A few years back I didn't practice any automated or methodical developer testing. When I would develop new features or fix bugs I would go through the system manually exercising the features that I thought would be affected by the changes I had made to the code base. Unsurprisingly I would always miss something, maybe I would fail to see the relation between what I was doing and some feature in the system or maybe I would test something new, think it was completely functional then make (what I thought would be) a harmless change and then all Hell would break loose. I hated when that happened, because not only it meant more work for me, but it also meant that something I would deliver as working would then be tested by the QA team only to find more bugs related to my changes. Now you could argue that I'm a terrible developer who doesn't know how to properly do his job, and you might be right, but in any case I knew there had to be a better way of doing things.

A couple of years ago I was lucky enough to work in a project with a company that encourages automated developer testing and even worked with a group that embraced TDD as their development methodology. It was then when I realized the benefits of having a good, fast, automated suite of tests that would exercise your code as isolated units and as a whole system. To me the main benefits I got were:

When I created a test for a certain feature, I would use that time once, then I could move forward knowing that I just had to run that test to make sure the feature still worked.
I had a safety net when refactoring the code. The test suite would become a baseline for functionality, so I wasn't afraid to change code.
Immediate feedback. When I created a certain piece of code, I could test it, even if the UI or the backend were not finished.
Finishing criteria. When I wrote the test first, I knew exactly when the code I was working on was finished, when the test passes then you are done.
Better architecture. Testability would influence the architecture. When you are writing your tests you want to be able to set them up quickly without having to wire too many dependencies together, which makes your components loosely coupled, then you want to test very specific behavior making your components highly cohesive. That alone will make your code better and more flexible.

I think the previous points make developer testing absolutely worth it and when done right it can lead a software development team to attain much better quality standards and the business will save money in the long run, but most importantly it gives you peace of mind and that, to me, is something invaluable.

I'm my next post, we'll dive a bit more into the definitions of developer testing and then we'll get hands on to its application to Java development.

Part 1: Java syntactic sugar for Javascript

2008-11-07T18:16:00.010-06:00

In my spare time I have been playing around with javascript a lot. I'm trying to sharpen my javascript skills by writing a web application that looks like a desktop application using pure javascript and keep away from HTML as much as possible. I have done this using ExtJS.ExtJS is a javascript framework and GUI toolkit that encapsulates common widgets and functionality into classes and uses javascript object orientation capabilities extensively. A typical ExtJS class looks like this:

Ext.data.MemoryProxy = function(data){

  Ext.data.MemoryProxy.superclass.constructor.call(this);

  this.data = data;

};

Ext.extend(Ext.data.MemoryProxy, Ext.data.DataProxy, {            

  load : function(params, reader, callback, scope, arg){

    params = params || {};

    var result;

    try {

      result = reader.readRecords(this.data);

    } catch(e) {

      this.fireEvent("loadexception", this, arg, null, e);

      callback.call(scope, null, arg, false);

      return;

    }

    callback.call(scope, result, arg, true);

  },        

  update : function(params, records){

  }

});

This code snippet is creating a new MemoryProxy constructor, as a member of the Ext.data object, i.e., it's package. Then it uses Ext's Ext.extend to make some magic and create a protype inheritance from Ext.data.DataProxy. The thrid parameter to Ext.extend is an object literal expression that will become part of Ext.data.MemoryProxy's prototype, the functions present in this object will override the functions that were already present in Ext.data.DataProxy.So what's the problem with this code you may ask.... Absolutely nothing. This is pretty much standard OO Javascript. Many frameworks are already using this pattern and it has been working great.Now I do have a problem with code... it's not very intuitive to a Java developer. I know, I know... who cares about them, Java developers should be developing JAVA right? Well that's a valid point. But still, I consider myself a Java developer so I do care about us :D. So my idea is to create a small library that would add some syntactic sugar to javascript to make it a bit more like Java. Still with me? Like the idea?To be continued (on my next post...)

CSS display woes...

2008-11-06T16:51:00.004-06:00

So for a proof of concept I'm programming, I tried modifying an existing javascript tree widget implementation (from ExtJS). The effect I wanted to achieve was this:


 + Root Node
    Content for the Root Node 
  + Child Node
    Content for the Child node
  + Another Child Node
    Content for the Other Child node

Now, when doing this, the actual html that is rendered looks something like this:


  ___________________________
 |+| Root Node               | 
 | |Content for the Root Node|
 |_|_________________________|___
 | |+| Child Node                | 
 | | | Content for the Child node|
 |_|_|___________________________|_____ 
 | |+| Another Child Node              | 
 | | | Content for the Other Child node|
 |_|_|_________________________________|

The big problem I was having is that the node contents we not expanding to the fit the with of the page, i.e., fill what's left of the with. This was happening because the contents were rendered using a span tag and it because it's a inline element it just expands to the width of its contents. Using a div or changing the display of the span to block would not work either because block elements have a new line infront and after them. Using the "align:left" property would cause the div to align all the way to the left of the page.

The Solution? You may ask... Well, just hack it and use tables. I know it sucks, I hate it, I feel dirty by doing so, but to the extent of my knowledge there is not much else I can do. I wonder if it was so difficult creating an element in HTML that would allow you to display them inline and fill all the with to is to the left of them? Was it really that difficult????

First Post

2008-11-06T12:28:00.001-06:00

So, this is the first blog post of many (I hope) and I though I would give some information about myself and my background.

My name is Carlos Zúñiga, I currently live in San Jose, Costa Rica. I work for an e-tailer company from the USA that has a development center in Costa Rica.
At the time of this writing I'm 3 weeks away from getting married to my lovely girlfriend of 3 years, Maricel, as you might expect, we are swamped with stuff to do.

As for the geek in me, I'm a Java developer. I have about 6 years experience developing Java applications mostly for the web.
I'm very interested in Java and other JVM languages, and the whole ecosystem around the platform. I also enjoy programming in Javascript and I consider myself pretty savvy in this area.

I have had the opportunity of working in companies where Agile methodologies have been used and I gotta say that I really like them, specially Scrum and eXtreme Programming. I firmly believe that Pair Programming and TDD have a deep impact in the quality of software.

So I guess this is it for now, but hopefully I will write some more in the near future.