Adding TypeScript Support to Projects

Bits and Bytes: Adding TypeScript Support to an Existing Project

In the previous Bits and Bytes, we looked at Getting Started with TypeScriptnow we will see how we can add TypeScript support to existing projects.

Similar to getting up and running we are going to need to make sure Node.js and our TypeScript compiler is installed. Once that is complete we can add a tsconfig.json file to support our compiler options. For info on getting up and running check out Getting Started with TypeScript. Read more “Bits and Bytes: Adding TypeScript Support to an Existing Project”

Bits and Bytes: Getting Started with TypeScript

You might be wondering what is TypeScript. Is it yet another programming language I need to learn? Another set of API’s and documents to read through? Yes and no. It is a superset of the programming language JavaScript. What does that mean? Well, as a “superset” it means everything that you love (or hate) about JavaScript is still there but now you have the ability to create classes, modules and interfaces to help build your large scale applications and components. Don’t worry about compatibility since at the end of the day it compiles down to simple JavaScript. What is also cool is you can start using TypeScript immediately. Read more “Bits and Bytes: Getting Started with TypeScript”

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
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
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
Client on phone – Photo Credit: Library of Congress


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 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.

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

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.

Gifs N Giggles Released for the Windows Store


My newest app has jus made it to the Windows Store. It is called Gifs N Giggles. The app is powered by and utilizes its repository of animated gifs for you enjoyment.

My first release is just consuming the Giphy API to show the top trending and most recent gifs. There is a feature called “Make me Giggle”, which will get a random gif. Sharing is done via the Windows charms bar for now.

My next release will add some for features. I am thinking of adding a meme generator, like and dislike functions, rating/ranking and more.

I am using the MVP (minimum viable product) approach to get a product in the market, test and gather feedback and iterate on it.

gifs n gigglesgifs n giggles


Go download it now and let me know what you think.


jQuery Accordion with 8 Lines of Code

Ok.  Maybe more than 8 lines of code but very little.  I have been working with another agency (that will rename nameless) on a mobile web site for a client of ours.  The agency provided the HTML/CSS/Images and Script for our technology team to implement.  We hook up all the back end and call it a day.

The section that came into question was an ‘accordion’ style UI for a set of FAQ’s and other content.  When I first loaded up their pages, everything worked fine.  Upon further inspection of their code I noticed a lot of JavaScript libraries that were not needed.  They included jQuery AND Prototype along with some effects and accordion scripts.  (Prototype alone is almost 100kb in file size and the other scripts were 42kb.  That still does not include the 70kb for jQuery)  I thought to myself, this is a mobile site…why have extra scripts if not needed.  To make matters even more funny, we are supporting Mobile Safari (iOS), Mobile Chrome (Android) and the BlackBerry Browser (RIM), it does not work in BlackBerry at all.  Forget enabling or disabling JavaScript it just does not work.  Even the elements are hidden.

So it got me thinking about the old saying, “if you want something done right you have to do it yourself”.  So I did.

I removed all the libraries except for jQuery and made all of the elements visible by default.  Basically if a user does not have JavaScript enabled then they can see everything.

Here is my HTML

Styles and other HTML can be wrapped around it. You can change the paragraph tags to div’s if needed but that is the structure you need more or less.

Now for the JavaScript.

Make sure you embed jQuery (I did from Google)

Then hide all open content containers:

If the element does not have the ‘current’ class then we need to first remove the ‘old’ ‘current’, close the ‘old’ ‘current’ and open and set the new ‘current’.


Here is the final:

Depending on how you format the code and what you count as a ‘line’ it can be about 8 lines 🙂

Updated GitHub Repository

Demo here – View in Mobile Browser.  Desktop browser will work as well.  Works on iOS, Android, BlackBerry.