Seeing so many JQuery fans out there, I’d like to share a little trick I use when I run JQuery alongside the MS AJAX Library.

There’s one very confusing aspect of JavaScript: the this keyword. What does this point to at any given time? The answer is it depends. It’s often difficult to figure it out. Just about the best and most detailed explanation of JavaScript closures, execution contexts, scope chains, the this keyword, etc, is here: JavaScript Closures.

When you write a new client-side component—a behavior or a client control—you declare a “constructor” and then augment the “class” prototype:

MyNamespace.MyControl = function (element) {
  MyNamespace.MyControl.initializeBase (this, [element]);
  // ...
  this._addPanel = null
}

MyNamespace.MyControl.prototype = {

  initialize: function () {
    MyNamespace.MyControl.callBaseMethod (this, 'initialize');    
    
    var self = this;
    var el = self.get_element();
        
    // ...
    var addLink = document.createElement ('a');
    $(addLink).click (function (evt) { 
       $(self._addPanel).show ();
       evt.preventDefault ();
    });
    // ...
  }
}

I simply save this because I know it’ll change hands inside various closures. It’s easy enough to forget you’re inside a closure when writing a mad “jquery” so this doesn’t point to your component anymore.

In the sample above I have a hyperlink whose click handler should display an arbitrary panel. I store this panel DOM element in a “private” field of my component. I can’t write $(this._addPanel).show() because this will point to the hyperlink when the click handler is invoked. Saving this in variable self allows me to get to the panel.

This simple technique has saved me a lot of debugging time. Hope it helps someone.

Ralph Johnson intrigued the hell out of me with his recent post about Erlang. A language geared specifically toward multi-processor/core environments; systems with reliability of nine 9’s; a number of little processes talking to each other via messages as opposed to dipping their hands into shared memory, etc—sounds too good to be true. Yet this is what Erlang promises.

On Ralph’s recommendation, I ordered a copy of the brand new book Programming Erlang by Joe Armstrong. Joe is a key figure behind Erlang. Apparently, they’ve been running an electronic switching system at Ericson for some time. Built in Erlang, the system delivers, allegedly, the wicked “nine 9’s” uptime.

I’m halfway through the book, and I’m getting a kick out of this language. It’s odd, but once you get the hang of it, it makes sense. For example, variables can be initialized only once, i.e. values are “burned” into variables upon initialization. Want to assign another value? Declare another variable.

Also, there’s no shared memory. Consequently, there are no locks or synchronization primitives. You write a set of processes and they communicate by way of messages. Those of you who ever wrote multithreaded code in C++ with semaphores, mutexes, etc, know what a nightmare it can become. Debugging that mess is, uummm, a little difficult.

Language maturity

I don’t think Erlang will become the next .NET or Java, but I do believe it’ll carve out a niche of devotees, just like Ruby and Rails did. Nothing wrong with that. I think the purity of language will be preserved better. Otherwise committees of “super stars” will inevitably spoil it.

The reason I’m saying it is this. I can’t help but notice how good manipulation of collections, lists and sets is in Ruby, Python, Erlang and similar languages. In .NET, collections are an embarrassment. A handful of primitive lists and dictionaries which only confuse people (see .NET Collection Madness part 1 and part 2). By golly, even STL kicks butt.

List<T> made life a little easier, but the “prescriptive guidance” advocates usage of the neutered Collection<T> class so you can override InsertItem, RemoveItem, etc, hoping that one developer out of a million will actually care! That always bothered me.

If we’re stealing stuff from functional languages into C# 3.x, why not clean up collections while we’re at it?

Conclusion

Anyway, keep an eye on Erlang. If it catches momentum, I think we’ll see some interesting developments.

Joe Wikert has kindly sent me a free copy of Beginning Ruby on Rails. Joe challenged me to give the born-again Wrox a try since I’ve been a relentless old-Wrox basher.

In terms of quality of content, Beginning Ruby on Rails is what a n00b book should be. It’s just plain fun. Steven Holzner knows a rooky needs a lot of handholding, so he crawls over every sample in the book explaining how it works.

Beginning Ruby on Rails is what it says it is: a book for total beginners to both Ruby and Rails. I saw one reviewer at Amazon say it was incomplete. Dude! Read the cover. It’s for beginners and it’s only 360 pages. Of course it’s incomplete. It should be.

On Rails

No question, Rails sparked a ton on interest to an obscure language that Ruby used to be, as well as to the design of Rails itself. Rails is often pitted against ASP.NET as a lighter, better alternative. Fair enough.

I do feel jealous there’s no server control life cycle to battle. I’m sick of it. I wish it were abstracted better. Nikhil will not write an updated book (too time-consuming and only one Nikhil), so we’re stuck with the monstrous architecture for the foreseeable future.

I do feel jealous about the proper division into the model, view and controller. In all fairness, MVP (Model–View–Presenter) is achievable with the Web Client Software Factory. I haven’t tried, but I rely on David Hayden’s word here.

There’s a whole bunch of other things I’m jealous we don’t have in ASP.NET. And Ruby is often so much more expressive than C#.

At the end of the day, we’re back at square one of all framework fights: each one sucks and excels in its own days. While reading the book I couldn’t help thinking, “How would I go about this and that in our product if it were built on Rails.” I had no idea because ASP.NET seemed to offer so much more horsepower. Again, this is a beginner book, and I need to read some more to have a more objective opinion.

Maybe my perspective will change as I learn Rails tricks. But for the time being, I’m not joining the crowd who proclaim endless love to Ruby and Rails and go, “OMG! I’ve been wasting my life away on ASP.NET. It suxxors. Rails is the way.” A tool is a tool. Learn to get the most out of it, employ it in a proper setting, and guilty conscience will not wake you up at night.

Conclusion

Back to the book. If you want to wander outside the ASP.NET camp, give this book a try. I liked it. Oh, and follow Joe’s blog if you’re a freakin’ bookworm like me. :)

+1 to the born-again Wrox.