My Other Sites

Friends

Dynamic Views Waste Time August 4th, 2009

At my current job, we use ClearCase. I must say, for a distributed version control system, it is a pain to use. Mecurial and Git seem far easier to use and are far, far cheaper (free). Not only is the company I’m at spending way too much money for their version control system, they are also using it inefficiently. There have been days wasted where all that was done was mess with the merging and integrating of other people’s check-ins just so that I could get my build to run. And it’s not entirely ClearCase’s fault! Well, I’ll go as far as to say that ClearCase is an enabler. The reason there is always a mess is because of our use of dynamic views.

So let’s say you have two people working on a project. Your partner checks in to a particular branch, and all of a sudden your view on that branch gets instantly updated. Sounds good, you don’t have to constantly update or make sure you’re working with the correct code base as it is automatically updated. Now put yourself in a team of 7-9 people. Say one person checks in but forgets to check in a file or two. 6-8 people now have broken builds and cannot run the program. After some investigation, we find out that someone forgot to check in a few files, and that broke the build. Not too significant of a time-waster.

Now let’s imagine two people check in simultaneously, and the build breaks. Now let’s say that both checked in all of the appropriate files. You now have a situation where no one can run the build, and on top of that, you have to wait for both people who checked in their code to reconcile it and figure out what went wrong. This is particularly bad if say, one of them is ever sick on the next day after checking in code later in the evening. This is not something that has happened to me, although something similar did occur, and it took days for my build to get back up to speed.

If you have your own private branch with ClearCase, steer clear of dynamic views. Honestly, they are far more often a time-waster than anything else. Besides, why would you want to continuously integrate your private development branch? That makes no sense to me. Rather, create another view on the public development branch (or the main branch, whichever you prefer), and then use that to see what changes have been made to the code base. The worst case scenario is that you’ll have to update your private branch, which is OK. At the very least you get to control whether or not you want your build to break.

There was a Community Wiki on Stack Overflow that talks about the strengths and weaknesses of ClearCase. If you want a more in-depth look at what ClearCase does and does not do well, I’d certainly take a look.

Javascript Vs JQuery: Cross Browser Compatibility, Event Handlers, and Selectors August 2nd, 2009

A few days ago I had the pleasure of attending my first Boston Javascript Meetup. It was a pretty good experience, the speaker was decent, but best of all F1lt3r, who I follow on Twitter, was in attendance. He’s been doing work with the new HTML5 and neural networks, and it was pretty exciting stuff. It got me excited about actually learning Javascript. So now, that’s what I’ve started to do. I could always program makeshift Javascript, but I wanted to really learn it this time.

I wanted to do something simple, and I always default to games when I start to learn a new language. They are fairly intuitive and I can come up with simple examples far more easily. Games are also much more fun to create (at this scale, mind you). The game I chose to make was Tic Tac Toe. It is a very simplistic game and took no more than a few hours to make due to my looking up of a lot of stuff. The game is also complex enough to at least touch on a few of the basics of Javascript, from cross browser compatibility issues to event handling to selecting and manipulating elements. Now, I did not use a library right away; I wanted to dig straight into Javascript without knowing what a library could do for me first. I then proceeded to redo the code in jQuery, as I know that I do not want to be dabbling with pure Javascript for too long. I will be breaking the next sections down into how the code looks in Javascript as well as how the code looks in jQuery.

Javascript:

The first thing I needed to learn to forget about for the time being is embedding onclick into my elements in the HTML page. It’s hard to break old habits, but I really wanted to use an even handler in the .js file. The trick of course with event handling is that not all browsers support it the same way. By this I mean, Internet Explorer does things differently from most everyone else.


    // Cross-browser implementation of element.addEventListener()
    function addListener(element, type, func) {
        if(window.addEventListener) { // Standard
            element.addEventListener(type, func, false);
            return true;
        }
        else if(window.attachEvent) { // IE
            element.attachEvent('on' + type, func);
            return true;
        }
        else {
            return false;
        }
    }

addListener(window, "load", init);

This code essentially makes sure the event handler is properly attached to whatever element is passed to it. In this case, as you can see at the bottom of the code, I’m attaching the init function to the load event of the window (the top element of the HTML page). This is because I want to initialize any internal variables I have when the page loads and not before. People make the mistake of thinking their variables can be manipulated when the page first starts loading, and that’s wrong. You need to wait until the page is loaded.


    function init() {
        squares = new Array(3);
        for (var i = 0; i < 3; i++) {
            squares[i] = new Array(3);
        }
        turn = "X";
        $id("message").innerHTML = turn + "'s  turn";
        addListener($tag("table")[0], "click", placePiece);
    }

Init will initialize my internal two dimensional array so that I can keep track of the pieces placed. This makes finding a winner much more convenient later. You will notice that I add a listener to the table. Specifically, I’m listening to clicks in the table that I’m using as my tic tac toe board in the HTML, and I’m calling placePiece() when that click occurs. If you’ve never seen $tag before, that is because I defined a new function called $tag which is just returns document.getElementsByTagName. This is to avoid the hassle of writing that over and over again.


    var $ = {};
    function $tag(tagName) {
        return document.getElementsByTagName(tagName);
    }

The last place where the Javascript gets funky in order to support multiple browsers is in my placePiece function.

    function placePiece(evt) {
        var event = evt || window.event;
        var td = event.target || event.srcElement;
        if (td.innerHTML.indexOf("X") !== -1 || td.innerHTML.indexOf("O") !== -1) {
            $tag("div")[0].innerHTML = "You must place your piece in an empty space!";
            return;
        }
        var tds = $tag("table")[0].getElementsByTagName("td");
        for (var i = 0; i &lt; tds.length; i++) {
            if (tds[i] === td) {
                td.innerHTML = turn;
                squares[Math.floor(i/3)][i%3] = turn;
                findWinner(turn);
                break;
            }
        }
    }

You’ll notice at the top of the function that I have a few ors to properly determine what my event and td variables should be. This is, again, in order to support IE and Firefox and whatever browsers happen to fall in line. The rest is fairly self-explanatory.

jQuery:

The jQuery library takes all of the cross-browser mess and makes it neat and intuitive. Essentially, you no longer have to worry about support unless you stray away from the library. It also simplifies your code SO much. Here is my event handler and init function all rolled up into one function.


    $(function(){
        $("td").live("click", placePiece);
        squares = new Array(3);
        for (var i = 0; i < 3; i++) {
            squares[i] = new Array(3);
        }
        turn = "X";
        $("#message").text(turn + "'s  turn");
    });

This is just like doing $(document).ready(); this is just a shortcut. I don’t want to get into the details of jQuery (if you wanna learn it, simply go to their site!), but you’ll see that I registered the click event on the td’s in the document, and the rest should look fairly similar to the init function I had before. No longer do I have my function to hide the getElementById, jQuery already does that with $(“#id”).

The last noticeable difference is in the placePiece function. Take a look at the top of the function.


    function placePiece(evt) {
        var td = $(evt.target);
        if (td.text().indexOf("X") !== -1 || td.text().indexOf("O") !== -1) {
            $("div:first").text("You must place your piece in an empty space!");
            return;
        }
        var tds = $("td", $("table").get(0));
        for (var i = 0; i &lt; tds.length; i++) {
            if (tds[i] === td.get(0)) {
                td.text(turn);
                squares[Math.floor(i/3)][i%3] = turn;
                findWinner(turn);
                break;
            }
        }
    }

var td = $(evt.target) does everything I had to support multiple browsers, in one line.

So, obviously there is a TON I still need to learn, but I feel this is a good first step. I will continue to compare jQuery and Javascript in order to convince anyone who doesn’t feel like learning a library that they really should.

Let me know in the comments if you’d like a copy of the code.

Edit: Credit goes to Paul Fisher for telling me I didn’t use PRE and to George Adams for telling me jQuery shortcuts and making me not suck too hard on my first real Javascript attempt.

Eclipse Plugins Are Bizarre August 1st, 2009

It’s been a while since I’ve posted anything. However, you can be rest assured that I’m not dead.

My job has been an interesting experience so far. There are company-wide changes being rolled in and I get to watch the company mature, so to speak. I finished the first assignment I was given (it took a month!), and although I went way over schedule, I blame 3rd parties for the hassle it took to get the feature underway. In any case, no one predicted that what I needed to implement wasn’t directly supported. Oh well.

The bad part is that working on that feature didn’t make me any more familiar with the Eclipse RCP. Staring at Eclipse’s plugin architecture for the first time is daunting at best. The API is rather shaky, and information about how to manipulate it is hard to come by. My task requires me to delve deep into the way the plug-ins are loaded, how the UI commands and actions are integrated, and how the views are added to the Workbench. It is not the most intuitive architecture, and Eclipse does try to hide a lot of its underlying classes, which adds to the frustration.

Fortunately I’ve made a lot of headway and have finally wrapped my head around a lot of what Eclipse has to offer. In a way, it is quite the powerful platform, once you’ve discovered what you can and cannot do and how to do it. I will be making sure to post about anything cool I’ve discovered for manipulating Eclipse and how to use the RCP as time allows. Stay tuned.