#vorlon.js

New Post has been published on http://drew5.net/code/website-debugging-with-vorlon-js/

Website Debugging with Vorlon.js

I have worked for digital agencies for most of my career. I was a developer and eventually became the Director of Technology at a few of them. I have worked with web technologies since 1996 and have gone through iterations of design and build trends. From the Adobe Flash splash-screen phase to home page takeovers. From content needing to be “above the fold” to iframes to ActiveX and more! When I was working at Byte Interactive from 2003 to 2007 we were a big .NET and Flash web agency. We did some PHP and Java but most of our clients were .NET. In the 06/07 time frame we started dabbling in the Mobile design space. It wasn’t until we were bought out by Story Worldwide in 2007 when we started to get more into the mobile space. We worked on iOS and some Android and mobile web as well. I then left Story in 2010 and became the Director of Mobile Technology at Affinion Group. This is where I started to get heavy involved with the Mobile Web. From build patterns to testing on all sorts of devices. The “band” was getting back together in late 2010 (ex Byte and ex Story) to form a new company called WELD Media. I jumped in as VP of Technology and we supported web and mobile web heavily before I joined Microsoft.

Marshall St Mayhem

During all of these companies we had many types of projects. Ranging from small promotional websites to full blown eCommerce applications. We had to support IE 7 for some time as well as all of the newer mobile devices. When it came to testing we used a bunch of methods that have stood the test of time. Different browsers. Browser add-on (Firebug, YSlow, Web Developer Toolbar) we used F12 and inspect element heavily. Heck, we even set up old PC’s and Macs as a test lab. We purchased iPod Touches, iPads, Android phone and tablets. But the common denominator with all of these is you had to be near the device or using the browser to help debug. It did not matter the “tool” you used. You had to open up the website and see for yourself or try and replicate the issue. And there were issues. As a developer, you are able to keep your dev machine up to date. But not so much your clients. Especially when the IT departments lock down versions.

QA Lab – Photo Credit: Library of Congress

I remember a few of our clients were still running IE6 when IE8 and Chrome were the standard. IE6! Ugh, that was the absolute worst. Even better, they might be using the latest version of a browser but the plugins are out of date (see Flash) or not installed. There is nothing you can do when you are trying to debug that type of issue other than heading down to the clients office and see for yourself (we did this a few times).

These issues are all present today and even worse. With the explosion of connected devices accessing the web makes it even harder to debug and troubleshoot an issue. How many flavors of Android are there now? Last count – 10! Even iOS has a lot. And lets not even touch on screen resolution.

So what happens when your client calls you up after the project has launched and says “I am looking at the site on my home computer and it does not work” or “The site is not working on my mobile phone”. Aside from saying the typical developer line “it works on my phone/computer”, what do you do?

Client on phone – Photo Credit: Library of Congress

Vorlon.js

In comes Vorlon.js. The remote debug web tool. It is ideal for situations like this. A simple line of code on your website and you can inspect til your heart is content the issue on your clients device. How does this work you say? Magically! Not really. Vorlon.js is built upon some great development library standards like Node.js, Socket.IO and Express. Vorlon.js runs on it’s own server (or Node.js server) to host the dashboard and the service. The service is using Socket.IO to get a connection to the dashboard as well as the various devices that we be connecting to the site that you are debugging. The site that you are debugging contains a reference to a JavaScript file that is served by the Vorlon server which contains all of the plugins and client code to interact with the client and the dashboard.

Get Started with Vorlon.js

Lets talk about how we use it and get started.

First you need to make sure Node.js is installed. Head on over to Nodejs.org and download and install for your platform of choice.

Once installed, create a project directory somewhere on your computer and you can utilize the Node Package Manager to install Vorlon.js.

npm i -g vorlon

That will install Vorlon.js. The -g option with NPM installs the package globally. So you will not see the files in your project directory. You will have to navigate to the directory that global packages are installed to if you want to modify or copy the installation. On Windows you can find it at C:\Users\username\AppData\Roaming\npm\node_modules\ on a Mac /usr/local/lib/node_modules.

Once installed, you can issue the vorlon command to get the server up and running

vorlon

Now you have a server running on your localhost on port 1337. To get access to the dashboard, just open your favorite browser and navigate to http://localhost:1337/dashboard/.

Start using Vorlon.js

In order to start debugging you will have to add a single reference to your client project.

<script src="http://localhost:1337/vorlon.js"></script>

Done! Now when you visit the client project website on any device, information will be sent to the dashboard.

Once we start having clients connect we can identify a client and inspect their DOM, look at their debug console, check out their JavaScript objects, perform validation upon their network monitor to ensure proper files were loaded, look at device information and more. All of the aforementioned are plugins that are available to use with Vorlon.js.

Wait, we are not done yet. We can use Vorlon.js in a desktop app or we can deploy to Azure using a one-click deploy. Both of which can be found on the Vorlon.js GitHub page.