Sergio and the sigil

Say hello to Scott Seely

Posted by Sergio on 2009-07-14

Hey, hey, hey dear Devlicio.us readers. Today we are adding another valuable member to our roster and we are very happy about it.

Join me and welcome Scott Seely to our group. I've known Scott for only about one year and he hasn't stopped surprising me with the breadth and depth of the things he writes about on his blog, his books, articles, and presentations.

As if that isn't enough, Scott is very participative in the developer community, organizing a user group and participating in many others. He was also one of the driving forces behind the recent Chicago Code Camp.

So, I hope I got you as excited as us to start reading Scott's material on our site. Check out his original blog for older posts for a little taste of things to come.

Welcome on board, Scott.

Upcoming Local UG Meetings

Posted by Sergio on 2009-07-06

Here are two user group events that are happening soon and that I'm directly involved.

July 8th, Chicago ALT.NET

0-60 With Fluent NHibernate
See the full description of the session over at the Chicago ALT.NET home page. We will have Hudson Akridge tell us all about Fluent NHibernate, a project that has been instrumental in getting people on NHibernate by simplifying a lot of that ORM's configuration chores.

The Chicago ALT.NET meetings start at 6PM in the Sears Tower. Check the website for complete location details.

July 14th, WI.NET

JavaScript - Beyond the Curly Braces
I'm taking my little JS presentation to the WI.NET UG in Milwaukee. The group's website hasn't been updated with the presentation details yet but it's basically the same presentation given at other local UGs.

The meeting starts at 7PM. Come ready to be surprised.

UPDATE: The video and slides from this presentation have been published.

A Craftsman sometimes has to create his own tool

Posted by Sergio on 2009-06-28

Today I was reading the latest one of the many excellent blog posts Patrick Smacchia has put out on the topic of code metrics and caring for your code's quality.

The passion this guy has for that topic is such that he has created the best tool for analyzing your code. But he doesn't stop there. He wants to make sure we understand what is going on behind the seemingly magic CQL queries that ship with NDepend. He wants you to understand your code's DNA; with the added bonus that you can actually improve that DNA.

That's Science with capital S.

  1. First you understand the problem that you are trying to fight (code complexity/unmaintainable software,)
  2. you research ways to quantify it (the metrics,)
  3. you create some tool or device to extract that information from your subject,
  4. you extract the metrics from a familiar subject,
  5. you apply your knowledge of how #2 relates to #1 and improve the subject under analysis,
  6. you use the tool to verify the metrics have improved,
  7. time shows you that the changes you made indeed reduced the problem at #1

I simply hate when someone criticizes Patrick's posts as being just marketing material for his product. Let me tell you this. If I had that much dedication for software quality, to the point that I had created a great product to empower everyone, I'd also be trying to explain the problem to you using the tool I wrote. Heck, I'm pretty sure if someone else had written NDepend Patrick would still be writing about these things and using the tool in the process.

I like code metrics and static analysis a lot as well, not nearly as much as Mr Smacchia though. I'm very excited that very soon I'll get to use it in our code base, in our CI server. I can't wait to learn more about this science and inflict positive changes in our code. Like everybody else, we know there's dirt and bad smells in our code and it's just awesome that there's a tool that can help us clearly identify, mitigate, and track it.

My hope is that I'll be able to come back here and share what I've learned about my code and how the process we went through to improve it.

Spotlight on JavaScript at the CNUG

Posted by Sergio on 2009-06-15

This Wednesday, June 17th, the Chicago .NET Users Group, CNUG, has invited me to bring my JavaScript presentation to their monthly meeting.

Despite of what the event description might lead you to believe, the talk is hardcore JavaScript, not much specific to Ajax at all, although I believe the material will greatly help you with the Ajax work as well.

You can read the complete talk description and register for the event. Hope to see you there.

JavaScript: Not your father's inheritance model - Part 1

Posted by Sergio on 2009-06-12
This post is part of a series called JavaScript Demystified.

This particular chapter is further divided in two parts. Read Part 2.

In a previous installment in this series we saw how we could create constructor functions in JavaScript. Back then I just mentioned that we don't have classes in JavaScript and that there's this weird prototype property in every object.

Let's dig into those concepts a little more and try to understand how inheritance is achieved in JavaScript.

Inheritance as we often know it

For myself and probably the majority of you reading this blog, inheritance in an Object Oriented programming language is directly associated with the concept of classes.

When we work with C#, VB, Java, Ruby, and many other popular programming languages, each of our objects is of some type, which is represented by a class. Our objects automatically inherit functionality from their associated class often called base or super class, and any other classes that the base class itself is associated with (i.e. derives from.)

That's nothing new to you, I'm sure. I'm just re-hashing that in the previous paragraph to make a comparison later. Let's call this model class-based inheritance.

That's not the end of the story

This may come as a surprise to some people, but class-based inheritance is not the only way to obtain Object Oriented inheritance (by saying Object Oriented I automatically excluded those of you that thought Copy/Paste Inheritance was one of them.)

It just so happens that the JavaScript language designers chose another inheritance model. And they are not alone in that choice. By opting for a prototype-based inheritance model , JavaScript joined the ranks of other programming languages such as Self , Lua , and Agora.

The prototype is the king

Objects in JavaScript don't inherit from classes; they inherit straight from other objects. The object they inherit from is called their Prototype (I'm using a capital P here to avoid confusion down the line.) The object's Prototype is assigned right at construction time.

You may be intrigued and say: But when I create my objects I don't remember specifying any Prototype stuff. What gives?

Let's see what happens then. When you create a plain Object using either of the following syntaxes

var obj1 = new Object();
obj1.name = 'box'
//or
var obj2 = { name: 'door' };

JavaScript will automatically assign a Prototype to each of these objects. This prototype will be Object.prototype.

Similarly, let's see what happens with a few of the other object types in JavaScript.

The Prototype objects is how every object in JavaScript is born with inherited functionality. For example, the substring() method that every String object has is a method defined in the object String.Prototype.

The prototype objects themselves also inherit from Object.prototype, that's how every object of any type has a toString() method.

When you try to access 1234.constructor, as an example, the runtime will look for a constructor property on our object (the number 1234). It doesn't have one so the next step taken is to check if that object's Prototype has it. The Prototype for 1234 is Number.prototype and it doesn't have that property either. The runtime then looks on the Prototype of Number.prototype, which is Object.prototype. That last object does have a constructor property, so that is returned. If it didn't, undefined would have been returned instead.

In Part 2 we will see how to create our own Prototypes.