Machineloop...

I’ve continued to use System.js, and struggled with bootrapping unit tests in the module loader. One of the benefits of using such a module loader is that each module gets loaded into its own protective function. This keeps all the variables private and away from the global scope unless exposed purposefully. One challange with this approach is testibility with Jasmine. Jasmine, by default, looks for global objects available by loading in a spec file and the javascript you’d like to test.

A few pointers on what to focus on as a young developer. One of the best tips he gives is to develop self-discipline. These pointers are particularly hard to teach in a way that they are immediately applied. …

It can be helpful to refresh some of the basics, and so this is a brief explanation of a tree data structure in Javascript. I use the prototype style of inheritance to create an empty methods object, you could also just use the prototype object given with each object. Then I create and return a new object linked to that methods object which has the defined methods for the tree.

ES6 is coming! And I’ve been having a blast playing with some it’s new features. One that I’m most excited about is Proxies, but I’ll get into those in a later post. For today, I want to discuss the module loading features that are available using a library called SystemJS, which allows you to use ES6 modules, as well as Require/AMD and CommonJS syntax. It’s simple to set up, and I have an example repository that I’ll walk you through to get started.

Playing with JavaScript is often one of the best ways to learn. Just pop open that console in your browser and start playing! One problem that I really enjoyed solving was one where I needed to keep track of list of functions, invoke them all, and modify their results. I call this an asyncronous task mapping function. The tricky part is waiting until each of the functions has resolved before modifything the results. The asyncTaskMap will take an array of functions as the first arguement, each function will take a callback that we can generate, and invoke that callback with...…

Continuous integration testing is an extremely useful tool. It allows you to check to see if a build is breaking everytime a developer pushes code. It helps your team keep your code in a good shape. But this only works if you write tests for your code as you engineer your solution. I believe the right time to write a test for your code is immediately after you’ve finished a naive solutation and are asking yourself, does what I wrote work? You should use unit tests to help you answer that question. Automating the answer to that question in code...…