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.

Python Web Development with Django: Review July 3rd, 2009

My roommate bought Python Web Development with Django Developer’s Library by Jeff Forcier, Paul Bissex, and Wesley Chun, and I decided to use that as my guide for learning Django. When I looked at the reviews for the book at Amazon, it seemed promising. I didn’t delve deep into them, only looking at the first few comments. So, immediately I began. Of course, I already had Django installed, and if you had been following my blog you’d know of the crap I’ve had to deal with getting FastCGI to work in Windows 7 (I’ve given up for now, but I’ll get back to it one day). In any case, I open the book, and begin working on the first example in the book, the Blog. It seemed simple enough at first, they would give me code, and I would write it up. When they said to run it, I promptly did so. It was a shame that when I followed the example to the letter that it did not work.

So I attempted to fix any problems I was having with the thing. Turned out I had to delete my database and reinstall it as the authors did not mention that syncdb did not fix your database if you make structural changes to your model (which I did, since I had made a mistake). In any case, after that little hiccup, I managed to get the blog application working. Yay for me! It was fairly painless but it didn’t teach me anything about how to actually use Django. That was what the next three chapters were for.

I quickly began to realize that those three chapters simply cover way to much and assume that you know exact what is going on at all times. Now, I’m not an expert Python developer, nor do I claim to be one, and the book doesn’t assume otherwise, but their examples out of context are fairly hard to follow. They do not even teach you how each of the different methods work, only that it is how the framework works. In any case, I decided to skim that part of the book, as I had a feeling that the next four chapters (more examples) would probably be a great deal more help.

They weren’t. I mean, okay, I did each and every one. They all didn’t work right out of the box. Seriously, I had trouble completing each and every single one of them. I don’t even remember the problems I had with each, but needless to say at least one of the problems was various typos. During one of the later examples I actually downloaded the supplemental source code because I had pretty much given up. The source code also did not work, and I had to fix that too. Honestly, I think the authors were in a bit of a rush to release this book, because how can you publish source code that does not work? You can’t prove a book is grammatically correct and that it is spelling error free, but certainly you can make sure code actually compiles and works as expected, especially with the scope of the examples presented.

To be fair, it is a bit of a pain when the authors assume you’re in a Unix environment. For all you Windows people (esp. Windows 7), you’ll just have to learn to adapt and be resilient. For example, the authors did mention symlinks at some point. I didn’t realize I could do symlinks in Windows, so I created an Alias in my configuration file in Apache instead. Not a big deal, but something to keep in mind. Overall I found the book to be alright as far as decent examples to practice with… AFTER you’ve exhausted your online resources. Honestly, I got much more out of this video than any of the examples in the book, simply because it’s a full 20 minutes of following someone create a simple application in Django. If you can get past the Indian voice and the fact that he’s using GRAPHICAL VIM, then you’ll be alright.

Oh, and I also highly recommend the online Django documentation, it is actually quite nice if you know how to use Google.

Furniture and PyQ Docs June 20th, 2009

Furniture! You have no idea how nice it is to finally be at a desk after almost three weeks of slugging it out on a rather uncomfortable floor. I feel like I can finally get something accomplished. The wheels on my desk chair don’t quite roll yet and that’s a bit annoying, although I’m sure with use the chair will stop sliding and the wheels will actually feel like turning. As it is now, the wheels are too stiff to rotate much. So that’s that.

In other news, PyQ development has not quite begun yet, but preliminary requirements documents have been written and are uploaded to the repository. The documents we’ve decided will all be written in LaTeX, and that’s exactly what we’ve done. I’m getting quite used to the LaTeX macros, as it makes formatting your documents soooo much easier once you get used to it. Currently the Vision and Scope document and the Software Requirements Specification (SRS) are up, although both are a little incomplete (the SRS is a lot incomplete, the features of the system haven’t been written out yet.

Oh, I’ve given up on trying to get Apache with FastCGI working with Django on Windows 7 for now. It’s been way too much of a hassle, although I still feel it should be doable. I’ll try it again later, since everything is still installed and well, it doesn’t really interfere with Python’s built-in development server.

« Older Entries