• entries
68
177
• views
82861

## Getting started with Node.JS part 1: Setup

I had been hearing about Node.JS for a while. "It's JavaScript on the server!" I mostly ignored it, as ASP.NET was forced on me at the time and I hadn't yet given employed life the finger and a flaming bag of poo on its doorstep[1]. What does "JavaScript on the server" even mean?

Well, it's a little more than just the bare meaning of a JS execution environment outside of a browser. Think of it like JS finally making something out of itself. All those years in college. Getting stuck in low paying design jobs. Now it commands respect! It can connect to databases!

Basically, start with V8--Google's JavaScript engine, not the salty-disgusting-juice that tricks you into eating vegetables when you were expecting a fruit smoothy instead. Just like the JavaScript that runs in their Chrome web browser. Then, throw away DOM--or rather--never add it because you didn't add WebKit into the sauce. Finally--and here comes the important part--throw on top a reliable package manager and a core set of libraries that make building a stand-alone Web server nothing more than a few lines of configuration code.

I should probably just shut up now and get to the point, because I'm the one late to the party and you, dear reader, probably know all this junk already.

## AAGHH!

I am so pissed off right now, and this is why:

MOTHER OF PEARL! LINE THE HELL UP!!!

This is a mapping application that we are customizing for a client. They have a format of data called RPF that ESRI MapObjects is particularly bad at cacheing. However, we found an open source project called OpenMap that handles RPF data very well. So it should be a whiz-bang process to create a custom MobObjects layer (the MapObjects API supports this) that uses the OpenMap code to spit out images. Making a small application that did nothing but spit out images given a path to RPF data and the extents of the image was nothing, simple task. Writing custom MapObjects layers is also not a big deal, we do it all the time.l

EXCEPT OPENMAP DOESN'T DEFINE MAP EXTENTS IN ANY SANE MANNER!!!!

Typically, a map extent is defined as the min/max latitude and longitude. OpenMap on the other hand expects a center latitude and longitude, along with a map scale. Fine, whatever, except it completely ignores any concept of aspect ratio! But let's ignore that, let's just calculate the damn scale... wait, you CAN'T because a monitor's pixel-per-inch ratio is not fixed!

So, after much trial and error, I've come up with something that is a reasonable scale factor... I think. Panning the map left-right is good, panning it up-down is okay, but if you pan it diagonally you get this freaking fracturing of the image.

GHAKGHAKALHGAH!!!!!!!

## TDD for the masses

If you hang out in #gamedev, then you've heard Washu and I talk a lot about WHY you should use TDD, with plenty of horror stories of when people DIDN'T use TDD. But we don't really talk about HOW to use TDD. I wrote this 1-printed-page (had to cheat on the margins) document for use at work, in an attempt to convince everyone else that they should be using TDD, just like they said they would. (don't ask) Anyway, it covers the main points (though not all of them), and has a couple of resource links for more information. The point of this doc is to be short. People won't pay attention to 2+ page docs.

Test First, Ask No Questions Later

Test driven development (TDD) can help developers create higher quality code on first iteration, as it helps developers avoid common errors of logic and design. The tests serve as a form of documentation, making clear the proper usage of the code. A large test suite facilitates subsystem integration, as it provides immediate feedback when new changes break old code. Test results are explicit and discrete, giving a better overview of the development progress. In short, tested code is confident code.

The TDD cycle:
1.) Take small implementation steps; large changes introduce large bugs,
2.) Design your implementation with testing in mind; determine what defines successful completion of the requirement and how to test for that completion
3.) Write one test; resist the urge to code in large runs,
4.) Write enough code so that your tests compile; do not write an implementation--just stubs,
5.) Run your tests, your new test should fail; if this is a tertiary pass through the TDD cycle, your changes may cause other, previously passing tests to fail,
6.) Write just enough code to pass all the tests; do not continue until all the tests pass, in this way you know that your changes do not break existing code,
7.) Refactor as necessary; minimize duplicate code, eliminate inefficiencies,
8.) Continue from step 2; consider if you need to expand your testing, remember to test boundary cases of input (bad input, good input that is close to being bad, typical input, etc.),
9.) Return to step 1; continue implementing small pieces of the requirement.

Tips on writing good tests:
1.) How to move a mountain: blast it into pebbles. Small tests (as defined by the number of Assertions made by the test) have a very high "Testing Resolution". A failed assertion immediately terminates the test, even if the test contains more assertions. Large tests with multiple assertions may hide assertion failures that occur after the first failed assertion. By splitting multi-assertion tests into single-assertion tests, all Assertions that can fail will fail, giving a higher resolution picture of the defect at hand. The test itself may be long on code to prepare for the Assertion, but it should only have one or two assertions.
2.) Test early, test often, test everything. Developers may feel like TDD requires more time than coding without testing. Initially, this is true. The developer not only takes the time to write the code, they also take the time to write the tests. The total amount of time spent on the code is far less, as higher quality code requires fewer bug fixes.
3.) The only good GUI is a thin GUI. How will you programmatically duplicate user interaction with reliability, precision, accuracy, and flexibility? Design GUI's as only being a front end to well-tested, GUI-independent logic classes. Ensure the GUI elements are receiving the expected bindings and trust that the GUI elements of the Operating System work as advertised. This also aids in code reuse.
4.) In with the good data, out with the bad. How will you programmatically ensure that a map does not render 500 feet off kilter? In general, data validation must be completed via Regression Testing (comparison to known good results) or typically "by eye".

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp02172004.asp (includes an example project)
http://www.nunit.org/getStarted.html (getting started with nUnit)