Category Archives: Work

I love NodeJS

So NodeJS has become all the rage in the development world recently, especially amongst those developers that use a lot of JavaScript and it certainly presents some interesting opportunities for those that know what they are doing with it.

Even more so if you couple it with other solid JavaScript libraries like SpineJS.

Essentially speaking for those of you that don’t know, JavaScript is usually a client side implementation in the browser to add extra functionality or small bits of programming logic. Think things like Jquery. In browser, adds functionality, is used as a solid library for manipulating elements and data on a page, and can be used to provide some very nice client-side validation.

NodeJS is on a whole other level.

NodeJS the Serverside JavaScript Framework

Node is server side JS and is used to write Java Applications and acts as a solid framework for building applications on. Think python.

And today I intend to give you a little demonstration of just what you can do. In 37 lines I am going to create a web server that will function and serve static files (no fancy logic in this one). You can think of it as a portable web server on the go.

var http = require("http"),
 url = require("url"),
 path = require("path"),
 fs = require("fs")
 port = process.argv[2] || 8888;

So first we initialise some variables. These are Node includes for the most part dictating which sub libraries of Node we want to include in our application. HTTP is used to handle HTTP requests. URL manipulates URL data, PATH allows us to manipulate local data paths (needed for finding files) and FS is included to read out files and serve them back out.

Now the beauty of Node is it’s designed to be non-blocking, and therefore can handle multiple asynchronous requests in one go. And it is with that in mind that the application makes a lot of use of callbacks, where the functions listen for an activity and wait to respond to it.

http.createServer(function(request, response) {}.listen(parseInt(port, 10));

BAM. That line has just made a http listener, that will listen for http requests coming in on the port we specified in the Variables above (8888). At the moment though it will literally do nothing except listen to a request.

We also want a line following that to actually provide a start to the application and give some feedback on the server. So we add:

console.log("Static file server running at\n => http://localhost:" + port + "/\nCTRL + C to shutdown");

That will write to the console, letting us know that the server has actually started, and give us some details like the port we have specified.

Node running our Server.js file

Ok time to get some application logic in there.

http.createServer(function(request, response) {
 var uri = url.parse(request.url).pathname
 , filename = path.join(process.cwd(),"public/", uri);
 }).listen(parseInt(port, 10));

What we have now is listener that will look for incoming HTTP requests on port 8888 on the server and will attempt to parse the URL that is provided removing the host information to get a path string to a file, which it will append to the node instances current working directory.

So if my Node app is running on d:/node and I send a request to local host that is http://localhost:8888/files/ it will amend the path above to be d:/node/files/.  Pretty nifty.

So now for a bit of validation. We amend the http.createServer function to the following.

http.createServer(function(request, response) {
 var uri = url.parse(request.url).pathname
 , filename = path.join(process.cwd(),"public/", uri);
 path.exists(filename, function(exists) {
 if(!exists) {
 response.writeHead(404, {"Content-Type": "text/plain"});
 response.write("404 Not Found\n");
 response.end();
 return;
 }
 });
 }).listen(parseInt(port, 10));

Excellent. Now we have some validation in there. path.exists checks the path variable we assign to filename to see if it exists. If it doesn’t it ends the request and responds with a 404 error. The response.writeHead function tells the page that made the request the type of content to expect. Then we write to the page our 404 message, finishing by ending the response.

A 404 generated by node when it can't find the file we requested

Next we want to start serving some files back to users.

Amend the createServer function as follows:

http.createServer(function(request, response) {
 var uri = url.parse(request.url).pathname
 , filename = path.join(process.cwd(),"public/", uri);
path.exists(filename, function(exists) {
 if(!exists) {
 response.writeHead(404, {"Content-Type": "text/plain"});
 response.write("404 Not Found\n");
 response.end();
 return;
 }
if (fs.statSync(filename).isDirectory()) filename += '/index.html';
 });
}).listen(parseInt(port, 10));

Ok. Standard HTML time. We need to check to see if we are looking at a directory or at a file in the URL request.

http://localhost:8888/files/ is looking at a directory, so we would want to find the index of that directory. The line we just added uses the file system (fs) library we loaded to check if it is a directory. In this case it is, so it appends the path with a file name. Index.html. The standard root for all folders. http://localhost:8888/files/fred.html would not be a directory so it would leave the string as is.

Now we have a file that we are looking for we need to serve it back to the user at the other end. Amend the server function to this:

http.createServer(function(request, response) {
var uri = url.parse(request.url).pathname
 , filename = path.join(process.cwd(),"public/", uri);
path.exists(filename, function(exists) {
 if(!exists) {
 response.writeHead(404, {"Content-Type": "text/plain"});
 response.write("404 Not Found\n");
 response.end();
 return;
 }
if (fs.statSync(filename).isDirectory()) filename += '/index.html';
    fs.readFile(filename, "binary", function(err, file) {
 if(err) {
 response.writeHead(500, {"Content-Type": "text/plain"});
 response.write(err + "\n");
 response.end();
 return;
 }
      response.writeHead(200);
 response.write(file, "binary");
 response.end();
 });
 });
 }).listen(parseInt(port, 10));

Ok that was a nice chunk. So what this section is now doing is reading the file given by our filename string using the type binary.

It checks to see if the file can be read (if(err)). If the statement produces an error it sends a 500 server error response back to the user on the other end. If it doesn’t produce an error it sends the file back as binary, resulting in one web page being displayed.

One successfully loaded webpage. You'll note that the HTTP requests for CSS files and images have also been successful and returned as well

BAM. In 37 lines of JavaScript we have just created a working web server.

You can further extend this by adding other libraries like SpineJS to make fully JS MVC applications that will return more dynamic content (using JSON and then parsing it with AJAX requests).

It’s amazing what you can do with some languages, and that is why I love the NodeJS framework.

Go get it and go play!

Dave the Keeper of Nodes.

Tagged , , , , , , ,

Asynchronous Web Applications are the Future

Given the prevalence of Jquery and Ajax request capabilities in modern web design, I’m still surprised by the amount of websites that still rely on the request -> retrieve format of web design.

We all know that speed matters on the web, and delays in getting information, or while waiting for a page to load can have a huge effect on the users experience and can sometimes drive traffic away from a website.

But with the technology available to us, it doesn’t have to be this way. It’s an exciting time to be a developer for the web, given what we can now do! So let’s start updating out sites to be “realtime” user experiences, where the page doesn’t visibly load.

A brilliant example of this would be GitHub and their project browser. Every time you click on a file or folder, it smoothly passes you to the next page, undetectably; the interface simply slides to show the next page. But the address bar updates, thus allowing you to bookmark specific places or files, but to the user it is clean and smooth. No pages loading.

For the most part our interfaces should be none blocking. We want the pages to update and refresh as we use them, showing the new information (though there are some key exceptions such as Credit Card Transactions where you want a confirmed response before processing any further).

After all users want to use web applications without interruptions or delays, and having blocking sections in there can negatively affect user experience and potentially drive clients away from your application. Users don’t generally need to see loading messages, or other feedback relating to the requests passing in the background, (though don’t misunderstand, not all feedback is bad, but it should be un-intrusive and non-blocking, like a small spinner for instance as a username is being checked and validated).

By using asynchronous requests, where the client side session updates immediately while the server updates in the background we can achieve cleaner and more user experience driven web applications. And we are starting to develop the tools to do so.

A fantastic example of this would be SpineJS that aims to let you completely decouple the server side mechanics from the user experience, which on the hole makes for neater web applications that are more pleasurable to use.

I’d love to see more of this type of development, and people should start making more use of it.

Dave, the asynchronous packet!

Tagged , , , , , , , ,

A requiem for the Desktop Application

Cloud apps are making a strong headway on the desktop application front. And it doesn’t surprise me in all fairness. The ability to get at your data or documents, anywhere at any time is a pretty attractive prospect in my book. Especially given the number of offices I work out of, not having to carry around large external hard drives or masses of thumb drives is a pretty useful. Everything is becoming so App-centric. Web apps, with the required mobile apps to go with, it’s no wonder that this is happening.

Even I have switched over to largely using web applications or cloud applications. Google’s Apps are now my default document editors and email as well as being a damn good all purpose calendar. My invoicing and book keeping is done through Ronin App (Check them out by the way, fucking brilliant for project management and invoicing.

But the reason why I am writing the post like this is the introduction of a new service to OnLive.

Just briefly, if you aren’t familiar with OnLive, they provide high end gaming through the media of cloud computing. As long as you have a damn good internet connection you can play the latest games at the highest graphics without having a dedicated console or a PC, all you need is decent internet and a subscription. In my opinion, a damn good deal.

But as they announced last week, they have brought Windows and Windows Desktop applications like Office to the iPad. Your entire Windows Desktop and applications in the cloud. Running on machines far better than yours will ever be. And all you need is a decent internet connection.

Now that is impressive. Seriously impressive. And the possibilities are endless. Imagine being able to simply use a tablet like an iPad on an Android Tablet and being able to call on the full power of a solid desktop anywhere in the world. And Heck, if you couple that with the fantastic Web App DropBox, you don’t even have to worry about your data on the go. It’s all there in the cloud.

Now the desktop won’t be dead for a long time, but I think we are finally starting to see the threshold tipping point where they are becoming less relevant. I can see a future where all processing is Cloud and Grid based. And I think I like that future.

But till I can get the Adobe Suite in the cloud, not for me yet.

Share your comments.

Dave the creator of cloud grids.

Tagged , , , , , , ,

What I do, is not What I do.

It’s an odd truism in the website world but it’s often the case. What I do, is not What I do.

How many of us introduce ourselves like this: “Hi, I’m Dave, and I design websites”? Seriously, I know I do, but that isn’t even half the story given the myriad of different skillsets that roll into those 2 words. “I design websites”. What the fuck does that even mean when you get down to it?

After all my skill sets boil to so much more than just those 2 words. But we all simplify for the client. After all saying “I’m a website designer” is easier than saying “I’m a website designer and developer with a specialization in PHP and using WordPress as a Content Management System as well as being versed in various aspects of SEO for businesses and building Social Media Presence”.

But we kind of have a tendency to shoot ourselves in the foot by saying Website Designer, as so many people (mostly the non tech-literate) start making assumptions about what you can do.

I recall one instance where I told someone I was a website designer and I was requested to build an all singing and dancing flash animation for their website. I had to decline, after all I’m not an Animator. But the thing that stuck with me was the parting words. “I thought you said you were a web designer”.

It’s a huge misconception among the average lay-person as to what web design actually is.

So to my “Web Designer” friends, have a read of this and if you have any funny stories to tell do so. But I would like to hear how you describe yourself to new clients.

Tagged , , , , , , , , ,