XeAlgo

So the classic Gauntlet (and N64 version) was one of my favorite games ever. Having at that point, spent the last several years almost exclusively coding in Javascript, I decided that it was time to refresh my C++ skills and what better way to do that then to write a multiplayer Gauntlet server?

Well, while I was testing the server, I realized that text only response data wasn’t really going to cut it, so I whipped up a hacky little client prototype in order to get things such as latency compensation and movement smoothing figured out. Great. So now I can move some characters around the screen on a few browser windows. Awesome. 

Collision detection. So I went pretty cheap with this. Really no objects will be ever moving all that rapidly, so one basic point-in-box check on both the client and server later, bam! Collision works and with the prior interpolation work I did, it actually worked way better than I expected.

A more complicated game world. Who wants to run around in a 2 tone box all day? No I. The next thing to do was creating a map system. Cool, now things are starting to come together. One implementation for the client, one for the server and the wizard and archer have an interesting place to explore.

Will I ever finish the project?? Ok so everything prior to this was setup for this one point. A game server is a pretty big undertaking, even for a game as simple as Gauntlet, but what good is a server without a client? Not much...but unless you are some known rock star in the open source world or you have published a few games with at least mild popularity, people probably don’t care about you or your projects....so guess what? You get to do everything yourself.

Having a side project is, well, vital for an software engineer. It’s your resume of resume’s. It’s your mark of passion as a developer. It’s your hobby, the thing you do when you aren’t grinding away at the office all day. However, often it almost becomes a second job. You find yourself thinking “I need to do x”, “I have to make time to solve y” instead of “I can’t wait to write x feature!”. 

Some may argue that a “true” programmer will never think of coding as work. Ok, well in their world, you know the same one where unicorns roam freely, maybe that’s the way things should be, but in real life, anyone who isn’t a complete neckbeard (and my beard does tend to creep down my neck) there are a lot of things to do and think about, and sometimes what starts off as a fun side project, can become another burden...something you feel guilty for not having time to work on, so you try and adjust your life to make more time for it...

Ok so maybe not everyone has ran into this or thinks this way. I for one hate starting a project and not finishing it..but really the underlying issue here is that I chose a project without fully thinking about how much effort would be needed to complete it and I feel that this is the same issue that burdens most of us, even those creating startup companies. Far too often we have an idea which seems reasonably simple at first, only to later realize “holy hell, this thing is a beast”. 

Note: This is a work in progress and has plenty of typos.

Ok so I’m going to keep this article short and to the point, without going into long tangents about existing frameworks, why / why nots, blah blah blah.

Let me say this ahead of time so that I can later assume we’re on the same page. I’m a fan of creating 100% pure JSON servers. You should be able to send GET / POST requests (and I give 2 shits about PUT / PATCH / DELETE) and have the server spit out a nice little packet of JSON for your app to consume. Yay!

With that said. In my current project, I decided to layout a few rules:

Discrete pages are implemented as components. A component being a part of a whole. Module could have also been used, but I used it for something else, stop whining. 

Modules are reusable blocks that can be added to components. For example, recent activity is often something you’ll place on more than just a single “page” of your app. It may look slightly different from section to section, but that should be easy enough to change entirely through LESS / SaSS or even through the view / markup. Maybe I pass an argument of true vs false telling the module to be less verbose.

Nothing should be protocol dependent. If I decide to make everything utilize a websocket vs http, I should be able to do so without any complications. 

There should be very little interdependencies. I think this can be a very philosophical topic and can be solved in a million ways...so let’s just be friends and simply say, no spaghetti code.

My Architecture

Before I begin, let me first say, ALWAYS use your tools wisely and don't try to force the cylinder to fit within the square hole.

Not MVC

It's been stated plenty of times over the last few years that MVC does not apply itself well to client side architecture. In almost every case, you're either dealing with data or dealing with the view. I'm not going to go into the reasons why in this article, just google it.

With that said, I use controllers in my architecture. Ok, well not in the sense that you're probably thinking. I'll explain. Traditionally in web development, you'd send a request based on some text link or button click, the server would process the request and send back a pre-rendered webpage. All done.

In modern single page webapps, you still need to break the flow up into manageable chunks, well granted you're webapp requires the sophistication. I implement these "chunks" in the form of components. As mentioned earlier, components can be thought of as pages. More specifically, I utilize a routing layer to manage hash change events. Each hash has it's own component. For example: navigating to #products will render a "page" full of products.

So controllers? Controllers in this case are components. Each component acting as a single controller with a single action (well not exactly one action but more on that shortly). A simple component may simply invoke a view to render a static help page. A complex component such as one for products, may render a featured product, a list of the top 5, a way to filter and search for products, etc.

That's the high level view of components...but how are they implemented??

Models

Models contain data that can be rendered or be used as a communication layer between multiple components / modules. Models should be thought of as network objects, but will typically be populated through network responses. In fact, the models should never directly be created within a network response callback, but instead through an abstraction layer... this can be as simple as implementing a method such as "populate" which simply takes whatever data it recieves from the server and translates it to the data the model expects.

Views

Views are handle via Mustache utilizing tags which can be dynamically loaded or hard coded within the index. These tags look like: `` markup goes here, says {{name}}. ``

These can be reused over and over, stored in the DOM, cached in local storage, etc. I typically will bind some sort of UID between the view and the model that populates it so that I can later manipulate JUST the relevent DOM elements.

Modules

Modules as I stated in the opening section, are small blocks that can be used to build a component. However, modules should only be implemented if something should be reused multiple times. Under the hood, modules are watered down components. They typically still create a model / models, and render a view.. only, they're intended only to be used for a single and relatively simple purpose.

Events

I stated at the start of this section to always use your tools wisely. This is primarily what I was referring to. If you think EVERYTHING should be event driven...just no. Believe it or not, but making everything event driven, can lead to your code being just as spaghetti if not worse than not using events at all.

I've seen people create a model and view, and then use an event system to populate the view, not to mention the fact that the model was subscribing to some UI event, which was subscribed to some action, which was subscribed to some network event.... Just no.

In my architecture, there are two primary places where events are subscribed to..

In the main application shell code.

By discrete subsystems.

For example: 1. The user logs in. This sends out a "login" event. The primary UI reacts by changing the wrapper slightly, changing "login / signup" to "logout / profile". The login component reacts by removing itself as a listener, before making a hash change event to load the #dashboard. The hash change event then reacts by creating a new dashboard component object and telling it to initialize and render itself.

To Be Continued...

In the past 7 years or so, Javascript has seen an overwhelming explosion in popularity, starting with client libraries such as Yahoo's YUI and jQuery and later moving to the server side of the scene once NodeJS took off. As web applications grew and became more and more complex, the need to separate JS files into separate modules became a must.

With this separation came the need to manage dependencies, making sure files were loaded in the correct order, objects, classes and functions could be accessed where and when needed, etc. Makes sense, right? Well because of the asynchronous nature of the browser, getting this right was often a real pain in the ars. 

For a while, the solution was mostly just to add all of the scripts you needed to the body element and waiting for the ready callback before executing any code. However, this method wasn't full proof, it cluttered up your markup and even worse, it made it so that your page had to requests every single file individually - even minifying them before hand still only cut back on file size, but didn't help the fact that you're still having to send a ton of requests to your server to load everything up.

The solution? AMD modules + minification. Using libraries such as RequireJS and it's build tool, programmers could now wrap all of their code into special functions which would only be executed once all declared dependencies had been loaded..and with various build tools, you could concatenate all of your code into a single pretty .min file and call it a day! The best part about this solution was, you didn't have to use any namespaces, you simply declared a variable in which would denote the module you required.

The problem however with AMD is that, you now had to load up a relatively large library, wrap all of your code inside of define/require blocks and manually make sure that every single dependent you need is explicitly declared - which sometimes could lead to having a huge array of files and dozens of parameters in your callback to hold the module references. While the anonymous functions can help protect your code a bit and somewhat eliminate the threat of naming conflicts, it also made is a giant pain in the ass when trying to debug or test stuff in the developer tools without having first exposed anything to the global object!

While AMD isn't the only kid on the block, other techniques such as those used with CommonJS, still have their share of issues when it comes to the client side of things. Now don't get me wrong. I think both are totally valid methods and in many cases work just fine and I was a huge fan of RequireJS for years, that is until one day I was asked to limit the libraries I used to Underscore and jQuery...

To make a long story short, I realized I had to come up with an alternative solution and once I began thinking about it...it clicked! Why the hell am I worried about dependency management when all of my code was already getting concatenated into a single file? The only dependencies I had to worry about were libraries such as jQuery, Underscore, Backbone, etc.

Writing a script loader is cake, especially using jQuery to do the actual loading for you. I now only had to add two script tags to my markup (jQuery and my minified app script). The other libraries could easily be loaded dynamically. 

Namespaces...evil you say?

I beg to differ. While it's true that climbing the prototype chain can slow your code down, creating static objects such as:

myapp.someCollection.someModule

in modern Javascript engines, has such a low impact on performance, unless you're writing a 3D game engine using ThreeJS, you're unlikely to ever notice any performance gains by eliminating namespaces. Even so, you can simple create "pointers" such as:

var someModule = myapp.someCollection.someModule;

which keeps the JS engine from having to climb the tree. Namespaces are a great way to keep your code organized and just because you think it makes your code slightly more verbose, doesn't make it a bad approach to modular Javascript. The only real downside other than a potentially small performance decrease is when you want to reuse your code later.

Plugins!

"So you place all of your code in a single .min file and everything is part of some namespace...ok..whatever.. I bet you didn't think about the fact that you're now loading code you won't ever use in various sections of your app!". Wrong. Let's say I have my web app split into several physical pages, all of which utilize common code..but page A doesn't need to know about my friends and page B doesn't care about blog posts, but displays a list of my friends..

In page B. I'd simply need to load up a "friends.min.js" script (either physically in the body tag or automatically when I'm bootstrapping the page and that's it!..well..with a slight bit of work. For example:

for(var p in myApp.pages[currentPage].plugins) { myApp.pages[currentPage].plugins[p].init(); } ... myApp.pages.b.plugins.friends = { init: function() { ... } }

what's happening here is essentially dependency injection. I don't need to know ahead of time (in my common code) that page B is going to use the friends plugin, I just have to include it and let the system take care of initializing it for me.

Ok, I think I get the picture...but what about dev?

I utilize NodeJS + Grunt and a few grunt packages including watch, concat and uglify to name a few. These are the core tools I use to build my projects and because they run so fast, I can use the .min files for development along with a map file to help debug. This, along with the use of unit and functional tests, my development environment is extremely simple and easy to setup at the cost of spending slightly more time initially building the grunt config and package files.

This idea is shit!

Eh. Maybe, but it works extremely well for me and since I began developing my client side js with this technique, I've never looked back or have had regrets about it. I don't have to write a bunch of defines and callbacks or require functions (or update 20 files if I decide to rename or move a single file), I don't need to have two different index files for development and production (or do any hackery to make it handle both), everything is there immediately, so the page loads faster and I can execute my JS almost immediately.. etc.

The down sides include:

making sure namespace names don't conflict.

occasionally needing to update the gruntfile.

having to wait a second or so before I can refresh the page (due to the concat/uglify process).

a bit more effort dealing with plugins / modules that aren't part of the core library.

could potentially conflict with someone else's code if the root namespace key is generic such as "app, webapp..".

Over the last several months I've had my first real experience with the startup world and what I can already say to anyone thinking it's all fun and games is, it's not. Be prepared to work your ass off. Be prepared to step outside of your comfort zone so often that you forget what exactly your comfort zone is. Be prepared to lose sleep and work late into the night. Be prepared to work at your full time job to pay the bills and work just as many hours or more, for free.

If you're a lazy person, don't even bother to go down the road of the startup, because you will fail. However, with all of this said, it hasn't been a bad experience at all. In fact, while it's been a crazy amount of work, the experience overall has been quite interesting, and once you begin to see your efforts shaping up and your company becoming an actual company, you start to welcome all of that extra work. 

OSX 10.5+ 

I hate having to constantly remove .DS_store files from my various projects at work and if you are as well open you're terminal and run this command: 

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

So I finally got around to create my first "Hello World" node module in cpp...here's the code:

https://gist.github.com/xealgo/86bab21567dcc6498211

and then the JS node script:

https://gist.github.com/xealgo/30b42b264004d942bcf3

So I set out tonight with a question: how do I get all three of these to play nicely with each other. Well HipHop+Nginx was a no-brainer as Facebook demonstrates directly on their github profile how to configure the two, however what about using Nginx+HipHop + a custom php socket server? 

My theory right now is that the best solution would be to run the socket server on a separate VM from your primary HTTP server due to the fact PHP (or even HipHop) might have severe request delays if the socket server is processing a large chunk of code....not to mention, if it used a standard while loop... I'm still a noob so this stuff but I'm learning it all now!

Anyway, I my thought is that running php as C++ via HipHop with Nginx as the front-end http server could really be an interesting combo. I'm sure it's been done before, but I'll post again once I've learned more.