Backbone: A view and ownership of it’s element

When writing modern applications using Backbone I often find myself relying on past experience with object oriented architectures to help me structure an application. This is rather natural as the first programs I ever wrote were in an object oriented language (MOO for the curious). While often hailed as one of the primary contributions of the object oriented paradigm to modern software development, encapsulation actually has a much more varied history, and it is encapsulation I want to talk about here.

When writing an application in Backbone one of the primary abstractions is that of the view – I happen to also use AMD in my applications so I’ll leverage that syntax here. Here’s an example of a simple view:

define( ["jquery", "underscore", "backbone"], 
   function( $, _, Backbone ) {
         var myView = Backbone.View.Extend({
            render: function() {
               $( '#content' ).html( "HELLO WORLD!" );
            }
      });
 
      return new myView;
   }
);

I’ve seen dozens of examples and tutorials that take this approach to views. On the outside there is nothing immediately wrong with it – clearly there is encapsulation, we define a function which acts as a closure denoting the ‘module’, and we give it some dependencies. We further have a view object – and in fact we have a single view object, as returning a new instance of myView gives us something very much akin to a typical singleton pattern.

However, when I look at examples like this what I see is a sham of encapsulation – we have split our code, but we have not placed proper boundaries on the actual impact of that code. Namely, this line:

$( '#content' ).html( "HELLO WORLD!" );

breaks what I see as a good structural principle. By making use of jQuery to select an element on the page, the view now has to ‘know’ things about its outside world that it otherwise would not need to be privy to. Additionally, it puts constraints on any application that would use this model – and encourages an almost spaghetti effect of interdependencies (how do I know somebody else isn’t modifying the html of the content element?).

I think views should maintain two major properties to be effective units of encapsulation:

  1. The view should not interact with DOM elements outside of itself
  2. The view should own its element

Taken together, we come up with a paradigm that looks more like this:

define( ["jquery", "underscore", "backbone"], 
   function( $, _, Backbone ) {
      var myView = Backbone.View.Extend({
 
         tagName: 'div',
 
          id: 'MyViewDiv',
 
          className: '',
 
          render: function() {
             $( this.el ).html( "HELLO WORLD!" );
             return this;
          }
      });
 
      return new myView;
   }
);

Some higher level object that owns content might then do something like this:

require( [ "views/myView" ],
   function( myView ) {
      $( "#content" ).html( homeView.render().el );
   }
 );

In such a structure all element lookups could also denote the this.el as a parent element, ensuring that you don’t run into code that modifies similarly named tags written out by some other poor unsuspecting view.

In either case, however you decide to approach it and how you want to express views in a backbone application, it is important that consistency be attained – nothing would be more confusing that to have a mix of views that live independently and views that act as all-knowing modifiers of the page around them.

Posted in backbone.js, encapsulation, Javascript | Leave a comment

Issue Retrieving Collections from Jersey REST Services

Ran into a painful issue today when attempting to work with a sample application I was putting together. In my application I use JPA to retrieve data from an Oracle database, which I then expose via a Jersey service (running on WebLogic 12c). My front end is using Backbone.js and I was attempting to populate a backbone collection with the results of the jersey rest call.

So the REST service was written quite simply:

@Path("/productcategories")
public class ProductCategoryResource {
 
	@Context ServletContext context;
 
	/*
	 * Retrieves a list of the top level product categories and their immediate children
	 * Implements the GET on this resource, can return values in JSON or XML
	 */
	@GET
	@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
	public List getProductCategories() {
 
		ProductCategoryBll bll = new ProductCategoryBll();
		return bll.listParentProductCategories( context );
 
	}
 
}

Using cUrl I was able to see that what I retrieved looked like this:

{"productCategory":[{"categoryDescription":"Office Supplies","categoryId":"2","categoryLockedFlag":"N","categoryName":"Office"},{"categoryDescription":"Consumer Electronics","categoryId":"3","categoryLockedFlag":"N","categoryName":"Electronics"},{"categoryDescription":"Books, Music, and Movies","categoryId":"1","categoryLockedFlag":"N","categoryName":"Media"}]}

This is perfectly valid shorthand JSON – it has three objects, and all are denoted to be of type productCategory. Backbone however (or maybe it is jQuery under the covers?) really did not like this – it instead was creating a collection with one thing in it – a productCategory, and then trying to parse this as my ProductCategory model object which obviously failed.
Here is my collection that was failing to parse correctly:

window.CategoryCollection = Backbone.Collection.extend({
	model: ProductCategory,
	url: "webresources/productcategories",
});

The fix was pretty simple once I realized what it was doing – I needed to override the collection’s parse to handle the funk it didn’t like from the Java server (alternatively I could have altered the Java end, but I really didn’t want to mess with it at the time, and it is perfectly valid JSON syntax). Here’s the altered collection:

window.CategoryCollection = Backbone.Collection.extend({
	model: ProductCategory,
	url: "webresources/productcategories",
 
	// Override parse as the default JSON Jersey returns with a collection does not work with Backbone
	parse: function( resp, xhr ) {
		return resp.productCategory;
	}
});

’til next time…

Posted in backbone.js, Javascript, jersey | Tagged , , , , | 1 Comment

More on Node VM

So I wanted to understand a bit more about what is going on under the covers with Node VM. To do that, I pulled open the node code itself. To start with, when we do a require(‘vm’) we are referencing the builtin vm module, which is contained in Node’s libs folder under the name ‘vm.js’. The code for it is quite simple, so I’ll past it here:

var binding = process.binding('evals');
 
exports.Script = binding.Script;
exports.createScript = function(code, ctx, name) {
  return new exports.Script(code, ctx, name);
};
 
exports.createContext = binding.Script.createContext;
exports.runInContext = binding.Script.runInContext;
exports.runInThisContext = binding.Script.runInThisContext;
exports.runInNewContext = binding.Script.runInNewContext;

This is from the version I am currently running which is Node 0.4.9.

What we see here is a call to process.binding to access ‘evals’ in the node C++ code. The rest is mostly just mapping logic, giving us the various methods we have already been using by mapping them to the methods in the C++ code. Pretty simple. To understand what is actually happening here though, we have to jump down into the land of C++.

In the src directory for node, in the file node_script.cc, we find the method that does the real work – WrappedScript::EvalMachine. Taking a look at this, we can get a sense of what differs between passing in a context via runInContext vs runInNewContext and runInThisContext.

The first significant time we see a differentiation is here:

  if (context_flag == newContext) {
    // Create the new context
    context = Context::New();
 
  } else if (context_flag == userContext) {
    // Use the passed in context
    Local<Object> contextArg = args[sandbox_index]->ToObject();
    WrappedContext *nContext = ObjectWrap::Unwrap<WrappedContext>(sandbox);
    context = nContext->GetV8Context();
  }

We can see that if we do a runInNewContext, we must create a new context object. On the other hand, if we pass in a context object previously created we instead perform a variety of gyrations to ‘unwrap’ the context and get the V8 context of it.

Later, we also find that disposal is quite different:

  if (context_flag == newContext) {
    // Clean up, clean up, everybody everywhere!
    context->DetachGlobal();
    context->Exit();
    context.Dispose();
  } else if (context_flag == userContext) {
    // Exit the passed in context.
    context->Exit();
  }

It is clear from our performance results that the object generation and subsequent detach/dispose is expensive enough to make a noticeable difference in our run time.

We also find this code which occurs whether or not a user is doing a new context or passing an existing one:

  // New and user context share code. DRY it up.
  if (context_flag == userContext || context_flag == newContext) {
    // Enter the context
    context->Enter();
 
    // Copy everything from the passed in sandbox (either the persistent
    // context for runInContext(), or the sandbox arg to runInNewContext()).
    keys = sandbox->GetPropertyNames();
 
    for (i = 0; i < keys->Length(); i++) {
      Handle<String> key = keys->Get(Integer::New(i))->ToString();
      Handle<Value> value = sandbox->Get(key);
      if (value == sandbox) { value = context->Global(); }
      context->Global()->Set(key, value);
    }
  }

Additionally, there is this set of code which occurs to copy the values back out to the object used from javascript:

  if (context_flag == userContext || context_flag == newContext) {
    // success! copy changes back onto the sandbox object.
    keys = context->Global()->GetPropertyNames();
    for (i = 0; i < keys->Length(); i++) {
      Handle<String> key = keys->Get(Integer::New(i))->ToString();
      Handle<Value> value = context->Global()->Get(key);
      if (value == context->Global()) { value = sandbox; }
      sandbox->Set(key, value);
    }
  }

Looking at all these however, it is important to note that these are if and else if statements – so all of this code (along with a few other tidbits) are ONLY executed if the context is to be new or user provided. There is a third option in the code – which is to say, runInThisContext. None of this code executes in a such a case, which seems consistent with the significant performance difference we see between runInThisContext and the other options.

It is also important to note that when supplying a context, the way values are communicated back and forth is actually via a copy operation – the scripts is not directly editing the object.

Posted in Javascript, Node.js | Tagged , , , , | 3 Comments

Node VM Continued

One thing I noticed today is that this works:

var util = require('util');
var vm = require('vm');
 
var contextObject = {
}
contextObject.contextMethod = function(text) {
console.log(text);
}
var myContext = vm.createContext(contextObject);
myContext.contextMethod2 = function(text) {
console.log(text);
}
var scriptText = 'contextMethod("Hello World!"); contextMethod2("Hello Universe!");';
var script = vm.createScript(scriptText);
script.runInContext(myContext);

Which in general makes sense, but it is nice to see that you can modify the context.

Posted in Javascript, Node.js | Tagged , , , , , , | Leave a comment

Node.js Virtual Machine (vm) Usage

For my project I want to have have run time mutable code. There may be some better ways to do this in node that I do not know, but the easiest I could find in base was the vm module. I did some experimenting and here’s what I found.

To use the vm module you need to ‘require’ it:

var util = require('util');
var vm = require('vm');

Grabbing util as well in this case just because I prefer the logging methods on it to the standard console.log, as the time stamps help me keep straight what I was running when.

For my quick test, I’ll just do some hello world.

var util = require('util');
var vm = require('vm');
 
vm.runInThisContext('var hello = "world";');

So this takes the code inside the string, compiles it via JavaScript V8, and executes it. Really cool, but unfortunately there is no external representation of what happened. Lets make it print something out.

We might think to try something like this:

vm.runInThisContext('var hello = "world"; util.log("Hello " + hello);');

However, we would find that this causes a syntax error and throws up on us complaining that ‘util’ is not defined. There is a rather subtle reason for this. the runInThisContext method of vm does use the current context, however it does not have access to local scope, and we defined util in local scope by using the ‘var’ keyword.

If you change the first line to remove the ‘var’ keyword, then running it will give a result like so:

17 Aug 23:41:32 - Hello world

Anything defined as a global variable is accessible to us with runInThisContext. A good thing if you want to have access to those global variables, a bad thing if you would prefer to limit what the script has access to. For instance, with runInThisContext you can do things like this:

vm.runInThisContext('var hello = "world"; console.log("Hello " + hello);');

Assuming this is trusted code, that can be fine – but if it isn’t trusted code, or if (in my case) it is trusted but you want to explicitly encourage it to conform to a set API for interacting with things outside of it, you may wish to exclude the dynamic script you are running from having access to the global context. Fortunately, vm has a method which does this called runInNewContext. For example, this next line will not work because runInNewContext creates a new, ‘empty’ context for the script to run in rather than using the existing one – the script then has access to nothing outside of what JavaScript V8 itself provides – it cannot access global node functions.

Fails:

vm.runInNewContext('var hello = "world"; console.log("Hello " + hello);');

It will say that ‘console’ is undefined as it no longer has access to the global scope where console is contained.

So that is good – we have a way to limit the access the script has, but we need to be able to provide it with something in order to have it effect anything outside of itself and be useful. We do that by providing the context, or ‘sandbox’, for it to use via the optional second argument. Here’s an example:

var util = require('util');
var vm = require('vm');
 
var myContext = {
   hello: "nobody"
}
 
vm.runInNewContext('hello = "world";', myContext);
 
util.log('Hello ' + myContext.hello);

The second argument takes an object, the variables of which are injected into the global context of the script. It is my understand that this passing is actually done via some fairly sexy copy operations, so perhaps a relevant performance note to make is that the size of this context is probably a significant factor (will need to do some testing myself to see). Similarly, you can of course pass in functions with the context – those functions may utilize calls outside the sandbox object itself, such as this:

var myContext = {
}
myContext.doLog = function(text) {
	util.log(text);
}
 
vm.runInNewContext('doLog("Hello World");', myContext);

And of course we can define whole object structures as such:

var myContext = {
   utilFacade: {
   }
}
myContext.utilFacade.doLog = function(text) {
	util.log(text);
}
 
vm.runInNewContext('utilFacade.doLog("Hello World");', myContext);

Though I have found at this point we begin to get my JavaScript editor of choice confused about what is legal and what is not.

Stepping back for one second, I wanted to note that it is important to think about what is going on here. We are feeding text in, which is compiled at the time runInNewContext. Depending on application, it may not be desired to compile it at the time you run – we might instead want to do this step before hand. This is accomplished via the Script object, like so:

var myScript = vm.createScript('var hello = "world";');
myScript.runInNewContext(myContext);

And we can still include calls to our context, so this works fine:

var myContext = {
  utilFacade: {
  }
}
myContext.utilFacade.doLog = function(text) {
	util.log(text);
}
 
var myScript = vm.createScript('utilFacade.doLog("Hello World");');
myScript.runInNewContext(myContext);

That said, it is important to understand that this is not very safe, as by the very fact that you are ‘updating’ the context you know there can be leakage – for example:

var myScript = vm.createScript('someVariable = "test"; utilFacade.doLog("Hello World");');
myScript.runInNewContext(myContext);
 
var anotherScript = vm.createScript('utilFacade.doLog(someVariable);');
anotherScript.runInNewContext(myContext);

This will print out ‘test’ to the log. We could have just as easily replaced anything in the context, causing crazy unexpected behavior between executions. Additionally there are some other fundamental unsafe things about this – for instance, our script could consist of a never-ending loop, or a syntax error or similar issue that halts or causes the entire node instance to go into an infinite loop. In general, this simply is not a safe avenue for dealing with untrusted code. I’ve thought about the problem a bit and read some blogs on it, perhaps I’ll post something about what to do in such situation later.

For now, I would be remiss if I did not mention this “undocumented” method – not the new method used to create the context, and the associated call differences (passing in the context object instead).

var myContext = vm.createContext(myContext);
 
var myScript = vm.createScript('someVariable = "test"; utilFacade.doLog("Hello World");');
myScript.runInContext(myContext);
 
var anotherScript = vm.createScript('utilFacade.doLog(someVariable);');
anotherScript.runInContext(myContext);

If you are like me, you may be wondering ‘what is the point? it seems to work similar’ and as far as I can tell currently it pretty much operates the same in terms of functionality – I may be wrong on this point though in some specific use case, if so please feel free to drop a comment on it and I’ll update accordingly.

While functionally it seems the same, in reality something very different is occurring under the covers. To get an idea of what, precisely, I think it is worthwhile to consider this git commit somebody made which I think provides some useful reference:

https://gist.github.com/813257

For the lazy, here’s the code:

var vm = require('vm'),
   code = 'var square = n * n;',
   fn = new Function('n', code),
   script = vm.createScript(code),
   sandbox;
 n = 5;
 sandbox = { n: n };
 benchmark = function(title, funk) {
   var end, i, start;
   start = new Date;
   for (i = 0; i < 5000; i++) {
     funk();
   }
   end = new Date;
   console.log(title + ': ' + (end - start) + 'ms');
 }
 var ctx = vm.createContext(sandbox);
 benchmark('vm.runInThisContext', function() { vm.runInThisContext(code); });
 benchmark('vm.runInNewContext', function() { vm.runInNewContext(code, sandbox); });
 benchmark('script.runInThisContext', function() { script.runInThisContext(); });
 benchmark('script.runInNewContext', function() { script.runInNewContext(sandbox); });
 benchmark('script.runInContext', function() { script.runInContext(ctx); });
 benchmark('fn', function() { fn(n); });

This is a pretty simple benchmark script – there are some fundamental issues with it but it gives enough of a view that we can gauge a general sense of relative performance of various methods of executing the script. The script.* functions will use the pre-compiled script whereas the first two will compile at time of execution. The last item is a reference point. Executed on my machine, this gives me the following result:

vm.runInThisContext: 127ms
vm.runInNewContext: 1288ms
script.runInThisContext: 3ms
script.runInNewContext: 1110ms
script.runInContext: 23ms
fn: 0ms

So you can see that there are significant performance implications. The pre-compiled examples run faster than those that compile on the fly – no real surprise there – and if we were to increase the number of executions we would find this difference exacerbated. Additionally, we see something significant is happening different with the ‘runInContext’ and ‘runInThisContext’ vs ‘runInNewContext’. The difference being that runInNewContext does exactly what it says – it creates a new context based on the object being passed in. The other two methods use the already created context object, and we can see that there is quite a benefit inherent in this – creating a context is an expensive task.

Posted in Javascript, Node.js | Tagged , , , , , | Leave a comment

Simple Telnet Server in Node.js

I was playing with Node.js and started putting together a simple telnet server to learn a bit about it. I am going to walk through it in phases from “super simple” to more complex. But first, let’s ask ourselves – what the heck is a ‘telnet server’?

Telnet is a client server protocol based on a reliable connection-oriented transport, it is generally text based. Typically telnet is used today when connecting to unix based systems to do administration (though ssh has become more in favor of late, as it provides encryption), for administration of network elements, MUD style games played over the internet, etc. Typically a telnet connection is made over TCP, however telnet actually pre-dates TCP (it originally ran over NCP). For most purposes telnet has largely been replaced by SSH, which is more secure. That said, there is still a thriving community that uses it for text based interaction on the internet, and as one of the most basic protocols I felt it was a good place to learn how to use Node.js.

Some folks tend to confuse telnet with just raw TCP communication – and in fact, many telnet clients are used for testing commands against a TCP server (such as a web server utilizing HTTP). There are true raw TCP clients available today – such as netcat, socat, or PuTTY supports it on Windows. A few things differentiate telnet from raw TCP, namely certain rules around how to handle carriage returns and so forth. Also, telnet is not initially able to transmit ‘binary data’ as it is not ’8-bit clean’ by default. You can negotiate 8-bit clean, which is precisely how FTP works.

In any case, enough theory, let’s get to some code. For my simple starting point I am going to begin with a simple TCP connection. Here’s some Javascript code for Node.js to do it:

var net = require('net');
 
var server = net.createServer(function (socket) {
	socket.write('Welcome to the Telnet server!');
}).listen(8888);

So the first line causes us to load the net module from node which we then use in the next statement. We call net.createServer() and pass an anonymous function to it. The function accepts a socket, and writes out a string to the socket. We then cause this server to begin listening.

Now this code looks pretty awful honestly – but it is how much of the Node.js tutorial code is written up. Let’s pretty it up though into something more manageable/understandable by a normal human being.

var net = require('net');
 
/*
 * Callback method executed when a new TCP socket is opened.
 */
function newSocket(socket) {
	socket.write('Welcome to the Telnet server!');
}
 
// Create a new server and provide a callback for when a connection occurs
var server = net.createServer(newSocket);
 
// Listen on port 8888
server.listen(8888);

So doing the same thing, but with comments and a named function defined separately and such. Put this in Node.js and run it, it will cause node to listen on port 8888. Should you then open a terminal window (or command line on Windows) and type telnet localhost 8888 you will see the message come from the server, and nothing else. Voila, you have now connected via telnet, very impressive.

We’ll find that the server does absolutely nothing when we send commands at it. In fact, there is no way to close the connection without killing telnet itself or issuing the escape character (probably ctrl-] in most clients). I would like to do something with the data, so let’s make a quick chat server as it were. I would like multiple people to be able to connect to my server (already handled for us by node) and anytime a person types something, I would like their text to be sent to other people – thankfully on the Node.js home page there is a short video where they do exactly this, so it isn’t exactly a great leap. We’ll need to listen for a ‘data’ event, and when we get data, we’ll want to send it out to everybody.

var net = require('net');
 
var sockets = [];
 
/*
 * Callback method executed when data is received from a socket
 */
function receiveData(data) {
	for(var i = 0; i<sockets.length; i++) {
		sockets[i].write(data);
	}
}
 
/*
 * Callback method executed when a new TCP socket is opened.
 */
function newSocket(socket) {
	sockets.push(socket);
	socket.write('Welcome to the Telnet server!\n');
	socket.on('data', function(data) {
		receiveData(data);
	})
}
 
// Create a new server and provide a callback for when a connection occurs
var server = net.createServer(newSocket);
 
// Listen on port 1337
server.listen(1337);

So a couple things. We created an array called sockets – this is to hold all the sockets that connect to our server. We then define a receiveData function – this is a call back which will be called any time data comes in from the socket. Our trusty newSocket method from before now registers the receiveData function as a callback for any time data is received. Using that array of sockets, we then send any data we receive out to all the sockets.

This is neat but there are several initial issues with it. First and most obvious, what happens when a socket disconnects? The answer is Bad Things(tm). We need to do something to remove the socket from the sockets array so that we do not try to send messages to a dead socket. So we add the following function:

/*
 * Method executed when a socket ends
 */
function closeSocket(socket) {
	var i = sockets.indexOf(socket);
	if (i != -1) {
		sockets.splice(i, 1);
	}
}

And we can then do this inside our newSocket method:

socket.on('end', function() {
	closeSocket(socket);
})

You can see here I used an anonymous function to call the function I wrote because I wanted to pass in the socket object explicitly. You may have noticed that I also did this for the data event, and the reason I did that is because I know that I also want to provide the socket to the receiveData method. Why? Because the second issue we face here is that data input is echoed back to the person who entered it in the first place. This is not optimal given the telnet interface we are using, and so we can correct this issue by sending to every socket except the one that sent us the data. We can modify receiveData as such:

function receiveData(socket, data) {
	for(var i = 0; i<sockets.length; i++) {
		if (sockets[i] !== socket) {
			sockets[i].write(data);
		}
	}
}

We also need to modify the newSocket function to have the socket as well as the data passed to the receiveData method. Here’s the full code as it stands after these modifications:

var net = require('net');
 
var sockets = [];
 
/*
 * Method executed when data is received from a socket
 */
function receiveData(socket, data) {
	for(var i = 0; i<sockets.length; i++) {
		if (sockets[i] !== socket) {
			sockets[i].write(data);
		}
	}
}
 
/*
 * Method executed when a socket ends
 */
function closeSocket(socket) {
	var i = sockets.indexOf(socket);
	if (i != -1) {
		sockets.splice(i, 1);
	}
}
 
/*
 * Callback method executed when a new TCP socket is opened.
 */
function newSocket(socket) {
	sockets.push(socket);
	socket.write('Welcome to the Telnet server!\n');
	socket.on('data', function(data) {
		receiveData(socket, data);
	})
	socket.on('end', function() {
		closeSocket(socket);
	})
}
 
// Create a new server and provide a callback for when a connection occurs
var server = net.createServer(newSocket);
 
// Listen on port 8888
server.listen(8888);

So that’s cool, but what if the person wants to quit communicating? They could kill their telnet client, or issue the escape character – but this seems less than optimal. Instead, lets give them a command they can type which will close the connection for them. We’ll need to look for a particular text entry that is typed to match against our command, and disconnect the socket if it is received. Here’s some naive code to do that:

if(data == "@quit") {
   socket.end('Goodbye!\n');
}

However, this actually won’t work, because what is actually sent to us is not just the text, but also the carriage return and newline that follows it. We need to strip these out – we’ll make a simple function that does this simplistically using regular expressions:

/*
 * Cleans the input of carriage return, newline
 */
function cleanInput(data) {
	return data.toString().replace(/(\r\n|\n|\r)/gm,"");
}

Now we simply need to call this function on our data and use the return for comparison against our command rather than the raw input. Here’s the complete code with this modification:

var net = require('net');
 
var sockets = [];
 
/*
 * Cleans the input of carriage return, newline
 */
function cleanInput(data) {
	return data.toString().replace(/(\r\n|\n|\r)/gm,"");
}
 
/*
 * Method executed when data is received from a socket
 */
function receiveData(socket, data) {
	var cleanData = cleanInput(data);
	if(cleanData === "@quit") {
		socket.end('Goodbye!\n');
	}
	else {
		for(var i = 0; i<sockets.length; i++) {
			if (sockets[i] !== socket) {
				sockets[i].write(data);
			}
		}
	}
}
 
/*
 * Method executed when a socket ends
 */
function closeSocket(socket) {
	var i = sockets.indexOf(socket);
	if (i != -1) {
		sockets.splice(i, 1);
	}
}
 
/*
 * Callback method executed when a new TCP socket is opened.
 */
function newSocket(socket) {
	sockets.push(socket);
	socket.write('Welcome to the Telnet server!\n');
	socket.on('data', function(data) {
		receiveData(socket, data);
	})
	socket.on('end', function() {
		closeSocket(socket);
	})
}
 
// Create a new server and provide a callback for when a connection occurs
var server = net.createServer(newSocket);
 
// Listen on port 8888
server.listen(8888);

So simple enough – a little telnet chat server. In actuality, it is more of a TCP chat server, as there is a lot more to do, and obviously it is very naive and brittle to error – but that is for another day.

Posted in Javascript, Node.js | Tagged , , , , , | 11 Comments

Installing Node.js

An acquaintance of mine noticed that I put together the previous post regarding Javascript inheritance in Node.js, and asked what that was. When I explained, the next question of course was how to install it. I don’t want to reinvent the wheel here, so here are some links on Node.js.

Node.js Home Page

Node.js Install Instructions

 

Posted in Javascript, Node.js | Tagged , , , , , | Leave a comment

Javascript Objects and Inheritance with Node.js

It has been years since I was particularly interested in the Javascript language. At the time it was slow, and I really felt that the virtual machine environment of Java provided everything I could possibly need in developing software – needless to say I didn’t spend much of that time doing front end web page development.. Recently however I have come across the Node.js system (here) and I’ve been enticed to dive more deeply into a language I had previously dismissed. I will write more about Node itself later, but for now I wanted to explore a bit about objects in Javascript.

Jumble of Objects

The fun thing about objects in Javascript is that they are completely mutable – which is to say, the ‘class’ is not static, it can change during execution. Additionally, objects themselves can define new properties and methods that are specific to them.

In the traditional class model that I have been most familiar with, constructs called classes are defined which provide the definition of the properties and methods. An object then is a new instance of the class – it contains the data specific to that instance, but it does not define additional data elements (properties if you will) or methods which may be called on the object – it can only do what it is defined to do by its class. Inheritance is handled at the class level, and the object remains an instance of a particular class.

In Javascript however we have the opportunity to do prototypal inheritance. In this scenario, object structure, not just data, is mutable. So if I happen to define a car object, I can make a bunch of car objects which will have the same properties. I may then directly add additional properties or methods to these ‘children’ without the need to rely on a class structure. Here’s an example of creating a new child object:

// This defines an object
function objectDefinition() {
	// Do nothing
}
// Now we make an instance of it
var myObject = new objectDefinition();
myObject.universalAnswer = 42;
 
util.log(myObject.universalAnswer);

This code when executed in node will log the number 42 to the console (if using a browser you could easily utilize alert instead). Now myObject, which is an instance of parentObject, has this special property (universalAnswer). However, other instances will not have this special property – for instance, this will fail:

// This defines an object
function objectDefinition() {
	// Do nothing
}
// Now we make an instance of it
var myObject = new objectDefinition();
myObject.universalAnswer = 42;
 
var anotherObject = new objectDefinition();
 
util.log(anotherObject.universalAnswer);

Now I could put this property up inside objectDefinition – to do this, I must define it inside the constructor function itself. Like so:

// This defines an object
function objectDefinition() {
	this.universalAnswer = 42;
}
// Now we make an instance of it
var myObject = new objectDefinition();
 
var anotherObject = new objectDefinition();
 
util.log(anotherObject.universalAnswer);
 
util.log(myObject.universalAnswer);

This code will log the number 42 twice, once for anotherObject and then for myObject, as they both have now inherited the property from objectDefinition. However, we just got done talking about how mutable all the classes are – what if I wanted to add this property later, after objectDefinition was already defined, and have all of the instances inherit it?

I could try something like this, but it would fail to achieve the desired result:

objectDefinition.universalAnswer = 42;

To actually achieve my intent I have to leverage something called ‘prototype’. The prototype property enables us to add methods and properties to objectDefinition which will be inherited by the instances. This adjusted example works and logs 42 twice:

// This defines an object
function objectDefinition() {
 
}
// Now we make an instance of it
var myObject = new objectDefinition();
 
var anotherObject = new objectDefinition();
 
objectDefinition.prototype.universalAnswer = 42;
 
util.log(anotherObject.universalAnswer);
 
util.log(myObject.universalAnswer);

Unfortunately, with our code as-is, I cannot further extend from myObject or anotherObject – that is to say, I cannot have another object inherit from myObject. This is because myObject has no constructor function. I might think ‘hey, I can just add a constructor function!’ but I have not found a clean way to do this. As such, we do need to define a sort of hierarchy a bit more intelligently if we want to have a construct with superclasses and subclasses. Let’s build such a thing here:

// This defines a "class"
function objectDefinition() {
	this.universalAnswer = 42;
}
 
// This defines the "sub-class"
function subObjectDefinition() {
	this.super = objectDefinition;
	this.super();
}
 
var myObject = new subObjectDefinition();
 
util.log(myObject.universalAnswer);

So we can see here that we are able to create an instance of subObjectDefinition because we have a constructor which can then be called by new. As such, our ‘classes’ which we wish to have object instances of and mutate via prototype must be created with constructor functions.

You’ll see here that we do something a little bit strange in subObjectDefinition(). We create a new property subObjectDefinition.super and store the objectDefinition constructor function in it. We then call this constructor function. By doing this, subObjectDefinition now has the properties defined in the objectDefinition constructor, such as universalAnswer. Alternatively in node we can do this – note that we move the property definitions to prototype, this is important as it is the prototype values which are inherited.

// This defines a "class"
function objectDefinition() {
}
objectDefinition.prototype.universalAnswer = 42;
 
// This defines the "sub-class"
function subObjectDefinition() {
}
 
util.inherits(subObjectDefinition, objectDefinition );
 
var myObject = new subObjectDefinition();
 
util.log(myObject.universalAnswer);

Some digging through the lib folder of node finds us the implementation of util.inherits, which is thus:

exports.inherits = function(ctor, superCtor) {
  ctor.super_ = superCtor;
  ctor.prototype = Object.create(superCtor.prototype, {
    constructor: {
      value: ctor,
      enumerable: false,
      writable: true,
      configurable: true
    }
  });
};

Here the author is actually creating an anonymous object in between which is an instance of the super’s prototype. This chain enables us to set the child.prototype.* without altering the parent’s prototype (which would be the case if we directly assigned the prototypes to be equal).

In this way, we can define each of our classes (basically empty constructor functions), define an inheritance hierarchy, add properties and values to each of these class’s prototypes, and create instances that appropriately respect the inheritance chain for locating properties or methods to execute. With the super value, we can call (and call() or apply()) our parent methods.

That is all well and good, however one might say ‘well that does not seem very…well…prototypal’ though I suppose one would have to define what THAT means. However, I am reminded of the first programming language I ever encountered – MOO. This was a domain specific language for online multi-user virtual environments, and it utilized what I would call true object-oriented, prototypal relationships. This is as opposed to the more typical models we have above, i.e. in Java C++ etc, where CLASSES INHERIT FROM CLASSES and OBJECTS ARE INSTANCES OF A CLASS. This is to say, OBJECTS INHERIT FROM OBJECTS in what I would consider a pure object-oriented prototypal inheritance, and each customization carries down through the tree of object inheritance.

When I first learned C++, understanding that objects did not inherit from other objects in this way was probably the greatest barrier I faced – such a non-object-oriented but rather class-oriented approach took a lot of getting used to. I’ve long looked back on the simplicity of true object inheritance and hoped I might see it again elsewhere…thankfully, a fellow by the name of Douglas Crockford came up with a way to do this in JavaScript. Here is his article: Prototypal Inheritance in Javascript

I’ll let the article speak for itself, with the exception that I will provide a simple example here that shows the simplicity and power of the approach:

// Setup our object creation function, this becomes boilerplate
if (typeof Object.create !== 'function') {
    Object.create = function (o) {
        function F() {}
        F.prototype = o;
        return new F();
    };
}
 
// Define some objects, some values, inherit away
function oldObject() {}
 
var newObject = Object.create(oldObject);
newObject.universalAnswer = 42;
 
var anotherObject = Object.create(newObject);
util.log(anotherObject.universalAnswer);

Note no super here, which can be a concern – I’ll leave it an exercise for those interested to bridge that gap.

I believe both the purist ‘objects inherit from objects’ approach shown here as well as the more classical separation of class and object as seen in Node’s implementation of util.inherits have their place. In my case I have a project for which I am most interested in this last method of inheritance, as the simplicity it brings provides some unique characteristics.

I have found inheritance in Javascript to be a construct that appears deceptively simple on the outside but which contains a tremendous amount of flexibility. I wrote this article while learning the topic myself and so look forward to comments or suggestions.

Posted in Javascript, Node.js | Tagged , , , , , , , , , | 1 Comment

Syntax Highlighting in WordPress

When I started to setup this blog, I knew I would need to post a lot of code in order to describe what I wanted to. After some googling around I found WP-Syntax which among the various syntax highlighters appears to be the most supported (it and various other add-ons seem to be available in the WP Plugins for automatic install). I recommend WP-Syntax itself plus the plugin called WP-Syntax Button, which provides a simple button to click in the visual post editor. Here’s an example of some Javascript highlighting:

// Trying out some prototypal inheritance
if (typeof Object.create !== 'function') {
    Object.create = function (o) {
        function F() {}
        F.prototype = o;
        return new F();
    };
}

However it isn’t all roses…at least for me, using the Twenty-Eleven theme from WordPress, I ran into trouble. The code was too large and bulky looking on the screen, the styling was all wrong. Apparently the styling of the theme was overriding the styling for the syntax highlighter, as the theme uses #content context which the page sees as more specific than the styles defined for WP-Syntax.

In order to resolve should you see similar issues, you can go into plugins, edit the wp-syntax.css file for WP-Syntax, and prefix each element with #content. Like this:

#content .wp_syntax {
  color: #100;
  background-color: #f9f9f9;
  border: 1px solid silver;
  margin: 0 0 1.5em 0;
  overflow: auto;
}
 
/* IE FIX */
#content .wp_syntax {
  overflow-x: auto;
  overflow-y: hidden;
  padding-bottom: expression(this.scrollWidth > this.offsetWidth ? 15 : 0);
  width: 100%;
}
 
#content .wp_syntax table {
  border-collapse: collapse;
}
 
#content .wp_syntax div, .wp_syntax td {
  vertical-align: top;
  padding: 2px 4px;
}
 
#content .wp_syntax .line_numbers {
  text-align: right;
  background-color: #def;
  color: gray;
  overflow: visible;
}
 
/* potential overrides for other styles */
#content .wp_syntax pre {
  margin: 0;
  width: auto;
  float: none;
  clear: none;
  overflow: visible;
  font-size: 12px;
  line-height: 1.333;
  white-space: pre;
}

Note the #content tags at the beginning. This still left me with some issues with line numbering, which I haven’t yet gotten around to figuring out.

Update: After posting this, I found this blog which has a much better description of the process and correctly utilises a child theme: http://markmthomson.net/?p=1849

Posted in Wordpress | Tagged , , , , , | 1 Comment