Version 1.x of Code on the Go was really architecture-less. For 2.0 I wanted to have an architecture, and in the end, two primary types were used.

The first is the module design pattern. In the module pattern, you do not define things on the global. Instead, you use a library (Almond in my case) to give you two functions: define and require. You use the define method to define new modules. The function typically takes in the name of the module, an array of modules that the module depends on, and a function that has the dependencies passed in to as parameters. In the function, you create the object that you want the module to represent. It can be a simple object or a constructor function. It can even be as simple as a string, number, or Boolean value. The function is called the first time the module is request, either by the dependencies array or define a or by using the require function that passes the requested module. The library then stores the result of the function and passes it along as the result of all future calls to the module. The basic idea here is that a module only knows about modules it needs, cannot change those modules, and does not need global objects to cross-files.

The second is the Model-View-ViewModel (MVVM) pattern. The MVVM pattern is a spin on the classic Mode-View-Controller (MVC) pattern. The breakdown of MVVM is

  • Model: The data passed      around that you display to the end user. For example the file that you are      editing.
  • View: The code that contains User Interface (UI) objects like buttons. Important is that it does not know about the Model. For example the HTML in Code on the Go.
  • ViewModel: The glue between View and Model. It knows how to convert the Model into data and functions that the View can use. It contains properties that the UI links to and methods that the UI calls to change the Model.

The idea behind MVVM is that the Model and the View are completely independent of one another. This allows you to tweak your View without needing to worry about the model or to have more than one view of the data. A good example of different views would be in a stocks application. The Model consistently has the same information about the stocks but you can have many ways to look at it, graphs and tables for example.

Code on the Go consists of a small Model, “one” View and many ViewModels. The reason I say one in quotes is because technically there is only one HTML file so one view, BUT because of the way I have split it into multiple ViewModels it is like having more than one View. The ViewModels break code up into parts like one for controlling the Tabs, one for the Editor View, one for the Debug View, one for the Home View, etc. The ViewModels are intertwined, containing one another. There are some standalone, self-executing function style files too. One manages the CSS styles for instance; another is the entry point for the application.

That covers the overall architecture of Code on the Go. Next time I will talk about individual tricks I did to make things easier, like the CSS style manager class.

Last time we discussed version 1.0 of Code on the Go; both the libraries I used and why I decided to do a rewrite for 2.0. Now we’re going to talk about the libraries I used in 2.0. I’ll explain what they do and why I decided to use them.

WinJS 2.0
In the case of WinJS the question really become “Why HTML/JavaScript?” After all I could have used XAML/C# and been just as comfortable. The reason I chose HTML/JavaScript was the same in both: The editor library. In the XAML/C# world there are editors out there but none are free. Now I have zero issue paying for something but they are not cheap and I had no idea if this would make me any money. (Still have no idea for that matter.) In the HTML/JavaScript world I knew of one free code editor, CodeMirror, and would learn of another while developing 2.0.

Orion an open source HTML/JavaScript code editor. I found it when looking in to making my autocomplete better in CodeMirror. Knowing that the Esprima library (see below) would be my best bet I started poking around the site. To my shock there was an example of using Esprima to power autocomplete. I quickly investigated and found out that the example had imbedded a library called Orion. Now I had to chose: Use Code Mirror that I knew and had some features that would make life easier (like a document system to make having more than one file open at a time simple), yet Orion was less black box like for me as well as had autocomplete that put CodeMirror to shame. I decided that autocomplete would win the day. The version or Orion that I use has been heavily customize. I do plan to submit that work to the project at some point. Orion provides syntax highlighting, autocomplete, code folding, undo/redo, text formatting, brace matching, and more.

Almond is an Asynchronous Module Definition (AMD) library. AMD is a development pattern where you define “modules” and then import them as needed, removing the need for most global variables. Originally I had no plan to use the AMD pattern, planning to use a name spacing system. Orion though was build internally to use AMD via Almond, though it exposed a global variable so you could use either. As I tweaked Orion I got to like the AMD pattern with Almond and decided to use it. I like it so much that I’ve made it my default pattern now.

Knockout is a library I had been meaning to try for ages. It gives you data-binding in HTML. Data-binding is a way to allow you to not have to use ‘getElementByX’ methods or inline on-event handlers. This allows the two code sources to be extremely independent of one another. Knowing that I loved Dad-binding in the XAML world I figured I’d love to have for HTML too and I did.

Continuum is one of the most interesting I’ve seen. Continuum is a JavaScript Runtime Environment written in JavaScript. I’ve always loved the project but had no good use of it, till now. One of the features that I’m proud of developing is a “debug” mode for Code on the Go. It uses Continuum to run and test your code while being safe and sandboxed.

As explained in the last post Esprima is a library that analyzes JavaScript creating an AST. In fact there are THREE versions of Esprima in Code on the Go. Orion contains a modified version for JavaScript autocomplete. Continuum contains a version that it uses to help it run JavaScript. Finally there’s a version that I added and use to show users syntactical errors in their code. I have thought about trying to reduce down to just one version that they all could use. For now though I’m leaving it at three.

Once I had decided to use Orion for the editor I had expected to drop CodeMirror and I did. Then I wanted to add the “debug” mode. To do so I need a user interface. After trying different things I realized I could use the demo that comes with Continuum with some modifications. That demo used CodeMirror and I didn’t want to spend the time yanking it out yet. And so CodeMirror returned.

PortableRest is a library designed to make calls to REST services simple. While currently the only place I use it currently is to receive feedback from users eventually it will be used for more.

OfflineAjax is a library I built to solve a simple problem. If I user submits feedback while the machine is offline I would need to store it and send it at a later point. And that’s what OfflineAjax does. It provides an object with nearly the same API as XHR but only adds each request to a queue, only popping items out when there is internet. Currently there is a flaw in that if the app loses focus the queue is loss.

Metro ColorPicker is a user interface component that I made. It allows a user to select from preset colors or define their own. I use it to allow users to customize the colors in the editor.

That covers the Library’s I used. Next time I’ll talk about the code architecture I used.

In 2013, I was faced with the decision of how to build an application that was to be on both Windows Desktop and OSX. Being both a C# developer and a JavaScript developer I could have easily gone the web style direction like most others I know would, but instead I decided to go for a C#/Xamarin approach. (Why I decided against the web is a post onto itself.) That did leave me still with a learning curve for UIKit on OSX, since Xamarin is designed with the idea that you write the business logic once but write the UI for each platform. While this makes sense and I generally agree with it, this time I didn’t. Our app was designed to be more like an “app” in that we would want it to look nearly identical on both platforms. Just as importantly, I didn’t have the time to learn UIKit.

Then I heard of MonoGame. MonoGame was a cross-platform implementation of the XNA Libraries. (For those who don’t know, XNA is a game graphics library from Microsoft, kind of a managed way to use DirectX). I came up with the grand idea of writing the application using C#/Xamarin for the backend and using XNA/MonoGame for the UI. Issue was that XNA/MonoGame doesn’t come with “controls.” I’d have to create them from scratch.

Luckily I found an open source library that had already started down this very path. By the time I was done with it though, about the only things that were left of the original in my fork were basic concepts on how to do the hierarchy of drawing controls. I named my creation Avalon, after the code name for WPF. I had tried to get the company to release Avalon as an open source library, even going as far as registering a Twitter account. Sadly the closest I got was them thinking about doing a weird selling model.

Sadly near the end of 2013 I was laid off, killing the project. Being as no trademarks had been made on the name, I had very slowly started work on recreating the code, without the source code so I’d have no issues. Didn’t get very far to be honest.

Then a few weeks ago a new open source project call WPFLight came to my attention. It was almost the same idea: UI concepts on top of XNA/MonoGame. It was way better than mine and used XAML files, making it easily familiar to developers.

And so I have decided to abandon Avalon. It was a sort of vaporware to begin with and now I’ve finally admitted it to myself. Going forward I plan to contribute and support WPFLight, and maybe use even use it. :)

Goodbye Avalon, you served me well. Hello WPFLight!

Before I delve into version 2.0 I thought I would start with explaining the 1.x versions, what I did right and of course what I did wrong.

Version 1.0 was a very simple app, meaning it had nothing over the competition. Like some of my competitors I was using the CodeMirror library as the core to the app. CodeMirror is an HTML based code editor that offers Syntax Highlighting, Undo/Redo,  VERY basic Auto Complete, Code Folding, and more. I added tabs which most of the competitors did not do but the two competitors I was afraid of did. (And no I am not telling you who they are, I want to keep you using Code on the Go after all).

Besides CodeMirror the only other library I used was Esprima. Esprima is a library that analyzes JavaScript creating an AST (if you do not know what an AST is just think of it as a representation of your code as objects). At first Esprima was used to create a slightly better auto complete. In short it worked by keeping track of where in the code you were and where variables were declared. By comparing the two it would guess the variable and then if the variable had a primitive value (String, Number, or Boolean) it would show auto complete for that type. The second use for Esprima was to find code errors (things that just simply are invalid code and will not parse) and show them to the user.

Both Esprima and CodeMirror are still used in Code on the Go. Code Mirror is used as the “console” in the debug view. Esprima is used for the same things, Auto Complete and error finding, though how it is actually done is completely different.

The primary reason for not using CodeMirror in 2.0 as the main editor was that I could not easily hack it. Most of the things I wanted to hack have been added or fixed since then but it was too late.

Now 2.0 was a complete rewrite from 1.x. There is ZERO code that was kept from 1.x (unless you count code inside Esprima). The reason for this is that the code was simply bad. While it was pretty inventive, it was hacked together at first and it showed. User interface (UI) code was rewritten because if I was honest with myself the original UI was simply terrible. It was not even remotely touch friendly, it had way too much unused white space, and some things just didn’t look polished.

Now that we know where Code on the Go 2.0 came from we can start looking at it. Next post I will go through why I chose what libraries I did and how they fit together.

Starting next week I will begin to post about the upgrade of Code on the Go from 1.x to 2.0. It was a major rewrite of the whole code base and I think the coding tricks, frameworks, and what I learned will help other developers looking to develop using WinJS.

To start off the follow is the list of Libraries I used:

Over the next few weeks I’ll show how I used these libraries and what I learnt along the way


I did an experiment on the behavior of two online communities. I asked a question that I knew the answer to, would be common amongst new users, and would be straightforward to answer.
Stack Overflow and Quora reward users differently. Stack Overflow users are rewarded for janitorial tasks, whereas Quora users are not. Because these janitorial tasks are easier to obtain community status from than creating useful content, Stack Overflow users are more likely to vote against a question than assist an inquiring mind. When learning, asking the right question is often a difficult task. Stack Overflow’s reputation model could be improved to value imperfect questions and corrective guidance instead of moderation.
More discussion
Question on Quora
Question on Stack Overflow


I did an experiment on the behavior of two online communities. I asked a question that I knew the answer to, would be common amongst new users, and would be straightforward to answer.

Stack Overflow and Quora reward users differently. Stack Overflow users are rewarded for janitorial tasks, whereas Quora users are not. Because these janitorial tasks are easier to obtain community status from than creating useful content, Stack Overflow users are more likely to vote against a question than assist an inquiring mind. When learning, asking the right question is often a difficult task. Stack Overflow’s reputation model could be improved to value imperfect questions and corrective guidance instead of moderation.

More discussion

Question on Quora

Question on Stack Overflow

Yesterday I released MonoGame.Js. As it name suggest it is MonoGame but in JavaScript. It is not writing C# code and having it run in the browser like JSIL but instead a JavaScript library that provides an API that is very much like the MonoGame API.

Why did I do it? Besides my want to see MonoGame on as many platforms and in as wide use as possible, it’s also because I believe that the API model exposed by MonoGame is so good that even if you’re not using C# it would be helpful.

Right now MonoGame.Js implements 2D graphics, and Mouse/Keyboard input. Touch input is planed though when it will be added I do not know. I have no plans to add 3D support but would be doable and if someone wants to do it in a fork I’d be happy to take that pull request.

Well after being unemployed for a while I decided it’s time to expand my skill set. After looking around for what skills companies where looking for a big flaw in my skill set I saw was that while I can do client side web cross browser, I only know server side from the Microsoft stack (with a limited C++ and apache ability thrown in). So I decided it’s high time I learned the LAMP stack. For those who don’t know what LAMP is, it’s an acronym standing for common Linux (the “L”) web stacks. the exact meaning of the other letters is subject to change. For me the rest will be

A: Apache as the web server
M: MySQL for the database
P: Python for server side code.

The thing to note about that list is that I chose precise for all letters except “L”. In the case of Linux I decided not to pick just one but three: Debian, Fedora, and Slackware. Each is a “Core” distribution that other more commonly know distributions come from. For example Ubuntu, one of the most well know and most common consumer distributions is a fork a Debian. CentOS, a popular server distribution is a fork of Fedora. By learning these three I won’t know how to use every distribution out there but I should know the basics for each “family” and be able to quickly learn the differences.

For the “P” I thought about choosing PHP, despite my extreme dislike of the language. After all, like it or not it’s THE language to use it seems. I decided not to because learning Python would not only help me add the LAMP stack to my skill set but also all me to use it in other contexts. PHP is really only useable in LAMP (or web context that is). And admittedly it allows me to continue hating PHP.

As to MySQL and Apache, I’ve use both in the past. MySQL was part of a friends college course work and I helped her through it. Apache I used a previous job. Obviously I didn’t really explore MySQL that much in helping my friend and at the previous job I was using the C++ integration with Apache so the skill set doesn’t exactly transfer. On top of that most of the work I did wasn’t with Apache but with the custom system built on top of it.

So with the new year comes a new skill set and a new stack to work on. First up is learning the three Linux distributions in VMs.


When we put SSDs in the dev server

(via dbareactions)

I fully indorse SSD in dev severs :)


When we put SSDs in the dev server

(via dbareactions)

I fully indorse SSD in dev severs :)

Talk my brother today I made a prediction:

Windows 9 will be the one where the desktop goes away. Until then we’ll just get 8.x versions.

So I’m putting it out there. I’ve said it.