javascript object helper

2 comments:

I've been working in Javascript quite a bit lately. This seems to be a recurring theme in my development career going back to 199x. As I always looked at javascript as a pseudo-language used to manipulate browser characteristics, I hadn't really taken a good look at it.

Recently, I found I was using a lot of the same code over and over again between pages. Good old copy/paste/molest style of coding. Ugh. And at first I though, "I should write procedures for this".

PROCEDURES?!? Isn't javascript object oriented? Some would argue that it is not. But it sure can act like it is. There are no classes, but there are objects with properties and methods. It supports encapsulation and aggregation. And it supports inheritance. There are a number of different ways of achieving inheritance. I am not going to go into all of them in this posting. What I know, I learned from the Master anyway.

I decided to create an object that would encapsulate my common object manipulations; create a new instance of an existing object, extend an objects properties, and create a new object through multiple inheritance. With these three simple tools, I can accomplish quite a bit.

The following is the code as of this writing:

var objectHelper = {
  clone: function (originalObject) {
      var returnObject;
      function interstitial() {};
      interstitial.prototype = originalObject;
      returnObject = new interstitial();
      returnObject.uber = originalObject;

      return returnObject;
  },

  extend: function (originalObject, newProperties) {
      var returnObject = this.clone( originalObject );
      for ( var prop in newProperties ) {
          returnObject[prop] = newProperties[prop];
      }

      return returnObject;
  },

  assemble: function(objectHash) {
      var returnObject = {};
      for ( var obj in objectHash ) {
          returnObject[obj] = this.clone(objectHash[obj]);
      };
      return returnObject;
  }
};

clone creates a new object based on the one you pass to it. This seems simple enough, but it encapsulates code I commonly use. The benefit here is that manipulation of the new objects base properties do not alter the original objects properties. This is a common hassle with javascript objects

extend creates a new object based on the one you pass it and a corresponding object literal (or named object). The resultant object has all of the properties of the original, plus all of the additional properties provided in the second parameter.

assemble accepts any given number of objects as parameters and assembles a single object comprised of all the objects passed in.


Extending the FitNesse ActionFixture

No comments:


I've been working with FitNesse lately. I find it to be relatively simple to use, although I have admittedly not gone beyond that basics as of yet. The install was simple and the ColumnFixture is  very straight-forward. I had a number of tests up and running in a matter of hours.

But I had some minor issues with the ActionFixture. I used the sample code that came with FitNesse to get me started:

public class CountFixture extends Fixture {
  private in counter = 0;

  public void count() {
    counter++;
  }

  public in counter() {
    return counter;
  }
}

The table is as follows:

|!- ActionFixture -!|
| start | !- Customer Action Fixture -! |
| check | counter | 0 |
| press | count |
| check | counter | 1 |
| enter | counter | 5 |
| press | count |
| check | counter | 6 |



Everything is fine except I get an error on the enter. Method not found. So what gives? This is the EXACT code provided by FitNesse.

I tried the obvious things like making the counter public as is done with ColumnFixtures, but to no avail. I did some digging around and some experimenting and I finally decided to try adding another method to the class. One that accepts a parameter and updates our private global counter variable. The final class is as follows:

public class CustomerActionFixture extends Fixture {
  private int counter = 0;

  public void count() {
    counter++;
  }

  public void counter(int i) {
    counter = i;
  }

  public int counter() {
    return counter;
  }
}

And now, all is well. Hopefully this will save some of you a little pain.

How do you deal with being the person who doesn't get it?

1 comment:
A few days ago, I posted a "Rant" about key personnel on projects who don't get it. This was an immediate response to an encounter with a specific customer.

I genuinely believe that our lives are not governed by the events that occur, but by our chosen responses to those events. It is through our choices and actions that we exercise some illusion of control and help to temper the chaos around us.

I am in the midst of a personal revelation that I am struggling with.

I am a poor customer service provider.
I always have been.
When I rely on teammates who are excellent at it, I flourish.
When I take on the role myself, I fail.

I dig computer programming. It just makes sense to me. I enjoy learning new languages and techniques. I love creating things. I am made for this vocation; this profession; this lifestyle. I am passionate about it. I want to stand in front of rooms of people and tell them all about it. I want to write books about it. I want to learn and learn and learn and learn. I want to hone my craft. I want to kick ass. I want to be surrounded by people who feel the same way. People who value the same things, share the same passion, and want to make a difference in the world. People who are more passionate about TDD than they are about their favorite sports team. People who think hanging out with geeks writing a program that nobody will ever use is way f'n cool. People who would rather walk away from the money and the customer than compromise code quality to meet a deadline and get a buck.

I don't suffer fools well. Right is right. Team comes first. Quality is sacrosanct, but perfection is perversion. Collaboration requires hard work whereas Cooperation simply works. You're either on the team, or you're not. Roll your damn sleeves up, make your contribution, take a stand, own it with the rest of us, or get the F out of the way. I can't stand people who want the glory, but can't get their hands dirty or be bothered with little things like details, rational thought, or reality. 

These attitudes; this righteousness; my outlook. It makes me a good developer. Put me on a team with like minded people and we'll crank it. But I am not a good candidate for managing the customer relationship.


I lead teams well. I deal with customers poorly. I don't expect to change much. I've had this sense of passion and justice all of my life. And, frankly, I like it.

So, yeah, the customer didn't get it. But neither did I. I think I get it now. Or at least I've learned a lot and perhaps grown a little. And I feel okay about me right now. That's something I've been struggling with for a few months.

Code Retreat #2

No comments:
So I wasn't a part of the first code retreat in Michigan, but I am really looking forward to the second code retreat in Ohio. This one is going to be hosted at LeanDog Software. You may not yet know who these dudes are, but you will.

This one is going to fill fast. The event is March 14, 2009 and is capped at 40 participants. Check out the site. And if this is your bag baby, register to participate (assuming you can make the date).


How do you deal with people who don't get it?

1 comment:
This is just a quick vent to help me get it off my chest.

We discovered a fairly significant bug in a production Web application earlier this week. At the time, the bug was being reported as isolated to one page in the application. I reported seeing email that implied the issue existed in other areas of the application, but was informed by a key participant that I was mistaken and confused.

In a team meeting to discuss our plan, we agreed we would take two steps; fix the known issue and assess the application for any other occurrences. I gave an estimate of one day to fix the existing issue and two more days to assess the entire application. As a result, we had no definitive estimate of remediation. We clearly needed to take the time necessary to simply assess the scope. One day to correct the known, two days to assess the rest, unknown requirement complete the corrections (if more were needed). Three days until we knew the impact.

A teammate and I stayed late into the evening looking into the reported issue and running various test scenarios to see if we could identify the root cause. We not only identified the root cause, but determined the fix required. By the way, the page that I referenced earlier and was told I was confused about is the page we discovered the error on and used for our resolution testing. But being called confused by key participants who have no real concept of what is going on is another rant.

The next day, the team met again and I provided a summary of our findings. I informed the team that the problem was not isolated to a single page and was, in fact, systemic. The entire application would need to be changed. I assured the team we would continue with the plan to fix the previously known page in one day and we felt we could remedy the entire thing in four days.

I was beaming - we went from three days to assess and reconvene to four days for complete resolution. This was clearly good news.


"But yesterday you said three days and now it is four?" was the response from the key participant.