Rhetorically answering this with a resounding NO... the code also needs to be correct. And how do we as software engineers make sure code is correct?

func  
test  

That's right, unit tests. Which got me thinking a bit... Given I am already in a javascript runtime, can't I just inline my unit tests right into the blog it self? This post is a biproduct of the a couple of nights of tinkering with jasmine, iframes and events between different doms.

The two tests hopefully passing tests above are testing out the function in the code block bellow. The code, a simple add one function, is evaluated with in a iframe runtime.

function add1(num) {  
    return num + 1;
}

Just like the function above, the unit test logic bellow is also identified and evulated with in the iframe runtime.

describe("Running a sample code UnitTest", function() {  
  it("adds 1 to a number", function() { 
      expect(add1(1)).toBe(2);
  });

  it("adds 1 to another number", function() {
      expect(add1(0)).toBe(1);
  });
});

The codebase is effectivly creating new script tags inside the iframe and loading the text of the scripts into them. With the help of some promises, we can extend the logic to also sideload serverside files into the runtime. In the example bellow I am loading some scripts from my github repository and displaying the results of the run.

https://raw.githubusercontent.com/SergeiGolos/CodeOfSerge/master/unit_test_blogs/src/Player.js  
https://raw.githubusercontent.com/SergeiGolos/CodeOfSerge/master/unit_test_blogs/src/Song.js  
https://raw.githubusercontent.com/SergeiGolos/CodeOfSerge/master/unit_test_blogs/spec/PlayerSpec.js  
https://raw.githubusercontent.com/SergeiGolos/CodeOfSerge/master/unit_test_blogs/spec/SpecHelper.js  

Source

https://github.com/SergeiGolos/CodeOfSerge/tree/master/unittestblogs

Be warned, this code is alpha and in some places might require some tweeks to get it to work. The path to your dependencies for example. Also, becuse i am creating the html for the iframe on the fly, you might find some strange cross domain exeptions if URLs are not formated correctly.

Well... Since my last post was well over three month six months ago, it is clear that this strategy went over about as well as a two front war for Germany. Quoting the project at about 80 hours, with the learning curve I was expecting to spend about 120 hours, My baptism by fire wasn't to be the concern of my patron.

150+ hours in, and at a second dead end after a full re-write from scratch. I was beaten, bruised and defeated, and I crawled back to the tried and true Bootstrap.

Was it all bad? Not really, but the technology is too green even now that it has gone production with 1.0.

Layout based on flex-box: amazing

In Chrome only. Mostly

Front end developers like to pretend that HTML/CSS/JavaScript stack creates clean separations of concerns, but where does the layout fit in this scheme?
- Is it the task of the html mark up? Not really, but the markup around the data plays a part.
- Is it the CSS? Largely, but even in combination of CSS and HTML some layouts hunger for more complexity and require JavaScript; resize events for example. - JavaScript? Kind of, but the JavaScript really just manipulates the other two.

Flex-box, in principle aggregates the functionality of all 3 and moves them into a declarative markup in the HTML. Which is a dream, HTML really should be the layout layer. But even in chrome, some alignments produced unexpected artifacts in line heights and growing containers. And while some of these issues are resolved in 1.0, you can still see the browser struggling to deal with this new technology. And phone scrolling seems to trigger some strange elements shifts.

Then, for the LOLz, there is IE.

But blinded by the shiny new toy, I trudge on.

"Well, that's ok. The project had plans to be consumed on a chromebox, so IE support isn't necessary."

Paper looks amazing on the phone. Bulky on desktop.

Personal BIAS alert. I like paper and with a team of designers, paper can look very professional. But even google projects start to degrade on larger screens; example is Inbox, the new face-lift for Gmail. It is an amazing tool for the phone which has replaced my e-mail client on my android. But when I jump on my desktop with a large screen, the interface feels wasted; whole areas of my screen have no utilization and the larger bubblier look and feel requires more scrolling to cover less information.

Naturally, this is another area where I ran into problems; even with the background of some 8 years of art classes as a child, I am a coder first and a graphics designer never. So while application looked pretty good on my android phone, it didn't scale well to the large display; something was greatly problematic with a TV dashboard feature of the product.

Web components

No review of polymer can be complete without some thoughts on meat and potatoes of Polymer, web components; the new technology fore-casted to drive the future of Internet application.

At its heart, Polymer, is an implementation of web components, with a full abstraction layer for much easier web components creation. Web components, allow the grouping of HTML, CSS and JavaScript as one deliverable package. A package which when imported into the browser runs as any native HTML control. This brings great performance, but again the browser support currently is lacking and polyfils cancel this benefit.

But the theory behind web components, that developers can pick and choose 3rd party components to quickly develop applications makes me question if the Internet has learned anything from Microsoft's ASP.NET WebForms. It isn't completely fair to compare web components to ASP.NET WebForms, as many of the design flaws of WebForms don't effect the domain of front end development. But WebForms created a generation of developers who worked in a medium they didn't understand. The web was not a desktop application, and the abstraction shielded developers from having to understand the web applications workflow. More over, the overcomplicated abstraction made developers fear of what is under the hood. To this day I see this in Enterprise development. So will it be good for developers to drag and drop some web components onto an HTML page? Yes, they will be able to hit the ground running and create solutions but also, no, because it will shield green developers from having to understand the underlaying mechanisms of the medium they are developing on.

Conclusion

There is a lot of promise and room for growth for these combined technologies. But with out better browser support, the usefulness is diminished.

It takes 300ms of waiting before the user starts to get frustrated. Achieving quick load times is a task that is hard enough to do without the bloat-ware of multiple poly-fills. But even after bootstrapping the full poly-fill runtime, the response of loaded elements feel sluggish.

And what about mobile? My dev box is an I7 with 4 hyper-threaded cores with a 750W power supply and more memory then Bill Gates ever expected, but my phone has only a 3200mAh battery and a flimsy ARM processor. So what is the trade-off between visual feedback and battery life? If my computer stutters, my phone must in some real pain.

While for now, I am sticking with bootstrap for any contracted project, but I will continue to play with Polymor and other web component implementations until they mature enough for production.

"That galaxy is signaling in binary. I should signal back, but I only know enough binary to ask where the bathroom is." - Bender ( Futurama - S4E8 - Godfellas )

My excuse for my limited Spanish acquisition is that perhaps I'd been diverting my learning toward computer programing languages instead.

"I dedicate this performance to the lovin' memory of Microsoft QBasic. Keepin' it real." - Futuristic Sex Robotz

But the excuse is only an afterthought. I only started thinking about the correlation between spoken languages and programing languages after stumbling onto the topic of literate programming.

Literate programming is an approach to programming, introduced by Donald Knuth, in which a program is given as an explanation of the program logic in a natural language, such as English, interspersed with snippets of macros and traditional source code, from which a compilable source code can be generated.

...

According to Knuth, literate programming provides higher-quality programs, since it forces programmers to explicitly state the thoughts behind the program, making poorly thought-out design decisions more obvious.

Google dictionary defines literacy as "the ability to read and write." Well, ideally all developers can read and write code in their chosen language(s). Wouldn't all programing be literate? Depends on where you set the bar. A first grader is technically literate because he can cobble together some words by sounding out the syllables. But this isn't a rant about MS Bob, this is a rant about learning languages. So a bit about my experience as an ESL.

In 1993 my family and I moved to America, and it was pretty obvious to those around me that I was an immigrant. Thinking back, here is the basic list of the tells:

Sentence Structure

• Description: Coming from Russian, a language with no forced sentence order, one hurdle to learning English was sentence structure. As a result, my sentences would sometimes become overly complicated and difficult to understand.
• Solution: Translation at first, seeing the languages side by side and trying to understand the differences and similarities. Oh, and reading the language.
• Years Later: I learned to organize my thoughts in the paradigms of the English language.

Lack of Vocabulary

• Description: Without an extensive vocabulary it is almost impossible to communicate complicated ideas. The "big floating hotel boat" or "cruse ship" convey the same idea, but the correct terminology makes the communication efficient.
• Solution: Watching television. No, really! What a great way to learn a language. The pictures and words sync up for a better inferred meaning. Thank you, "Family Matters" and "Married with Children." Also, reading helped alot. A pattern emerges.
• Years Later: My vocabulary expanded, allowing me to more precisely craft my thoughts with elegant variation.

Getting Lost in the Process of Translating

• Description: I would often know what I wanted to express, but would get bogged down in the details of "how" to phrase my idea.
• Solution: Can't really stress enough the importance of reading.
• Years Later: Most appropriately the point of fluency in a language.

Accent

• Description: The Hunt for Red October's Sean Connery.
• Solution: Just practicing speaking the language
• Years Later: Can't even fake a bad Russian accent now.

Well as a PSL (programing as a second language), we each have to take a very similar path when learning new programing languages. Lets take a look at the same tells in the field of programing:

Sentence Structure

• Description: When a language learner translates a sentence into a new language, the complexity of both languages cloud the meaning of the sentence. The new programmer often brings much of the complexity of spoken language into the code they are writing.
• Solution: Read Code! Read books about code and code structure. Oh, the same pattern works here! Read code in open source projects. Programing languages are best learned by watching variations of language expression.
• Years Later: You learn to think in the constructs of the language and general computer logic.

Lack of Vocabulary

• Description: This is a real damper on the effectiveness of a green developer. This often leads to duplication of effort, the proverbial reinventing of the wheel. It also frequently diminishes the view of possible solutions, leading developers to work harder and not smarter.
• Solution: Read quality code. I feel like a broken record. But it was reading and listening to spoken English that helped me learn English, and it is reading quality code that helped me "learn" programing languages.
• Years Later: Obviously, I re-invent fewer wheels. But the benefits don't stop there. DSLs (domain specific languages), for example, open a whole new can of worms with syntax (vocabulary)

Getting Lost in the Process of Translating

• Description: Instead of thinking about the business logic surrounding some iteration of a list, a green developer thinks about the for loop and the variables involved to handle it.
• Solution: Read Code. Definitely a broken record. But read more code!
• Years Later: The logical abstractions come quicker, as many of the same abstractions are noticeable in many open source projects.

Here are a couple of books that have helped get me here over the years:

• Clean Code
• Programit Programmer
• Code Complete 2

So the moral of that story is to read code. And by "reading code" I am talking about the "Common Core" style reading for comprehension. Introspect on the code and really try to understand the meaning and intent.

So, crazy special IDE's/tools aside, litarate programing simply asks you to translate your code into English. It is almost like double checking your long devision with multiplication. I am not really suggesting that you write a novel alongside your application code, or go full Knuth with a special IDE's; it's a cool idea, but just try getting everyone on your team on that same page. :)

What I am suggesting is that thinking about the intent of our code should be a habit in the same way that unit testing should be a habit. The unit tests verify the integrity of you code, while the comments verify the sanity of those same lines. This is going to be a big goal in my personal improvement plan. Better fluency and code "sentence" structure will be the rewards, along with an assurance that the code solves the right problem.

resolve - {Object.< string, function >=} - An optional map of dependencies which should be injected into the controller. If any of these dependencies are promises, the router will wait for them all to be resolved or one to be rejected before the controller is instantiated. If all the promises are resolved successfully, the values of the resolved promises are injected and $routeChangeSuccess event is fired. If any of the promises are rejected the $routeChangeError event is fired. The map object is: - key – {string}: a name of a dependency to be injected into the controller. - factory - {string|function}: If string then it is an alias for a service. Otherwise if function, then it is injected and the return value is treated as the dependency. If the result is a promise, it is resolved before its value is injected into the controller. Be aware that ngRoute.$routeParams will still refer to the previous route within these resolve functions. Use $route.current.params to access the new route parameters, instead.

Ok, great: we have a factory function for getting some stuff from the server. On a route call to /Home, the resolver function returns some data. (This data can be a promise, in which case the promise will first be resolved before the controller is instantiated.)

(function(angular) {
    'use strict';

    var app = angular.module('app', ['ngRoute']).config([
        '$routeProvider',
        function($routeProvider) {
            $routeProvider.when('/Home/:message?', {
                templateUrl: 'Home.html',
                controller: 'home',
                resolve: {
                    data: ['$route', function ($route) {
                        return "Test String Data" + $route.current.params.message;
                    }]
                }
            }).otherwise({redirectTo: '/Home'});
        }
    ]);

    app.controller('home', [
        "$scope",
        "data",
        function($scope, data) {
            $scope.message = data;
        }
    ]);
})(window.angular);

But now I have business logic in my configurations. Routing files, in my mind, are a configuration item and should not actually contain code. Keep in mind that your resolver factory function is also injectable, as the example injects $route. As a result, it can actually contain some pretty complicated business logic for looking up records. Let's take a look at an example that pulls from the server, and join the server information with some request message.

resolve : {  
  data : ['$route', '$http', '$q', function($route, $http, $q) {
      var deffer = $q.defer();
      $http.get('/Data').then(function(result){
          deffer.resolve([result.data.Value, $route.current.params.message].join(' '));
      });

      return deffer.promise;
  }]
}

It is easy to see that, even with such a small function, we now might want to look into doing some type of unit testing. But right now, the resolver is just an anonymous function--unless you bootstrap the whole angular stack and your http, which is doable, but does make the first "it" more difficult. So can we handle this in a slightly simpler manner? Just move the resolver factory function to where it can be unit tested.

app.provider('data', function () {  
        return {
            $get: function () {
                return {
                    home: [
                        '$route',
                        '$http',
                        '$q',
                        function ($route, $http, $q) {
                            var deffer = $q.defer();
                            $http.get('/Data').then(function (result) {
                                deffer.resolve([result.data.value, $route.current.params.message].join(' '));
                            });

                            return deffer.promise;
                        }
                    ]
                }
            }
        }
    });

And now that the resolver function exists as an artifact of a provider, we can expose it inside the config function.

var app = angular.module('app', ['ngRoute']).config([  
    '$routeProvider',
    'dataProvider',
    function ($routeProvider, dataProvider) {
        var data = dataProvider.$get();
        $routeProvider.when('/Home/:message?', {
            templateUrl: 'Home.html',
            controller: 'home',
            resolve: {
                data: data.home
            }
        }).otherwise({ redirectTo: '/Home' });
    }
]);

To The Unit Test

So far, we have made the resolver factory named instead of anonymous. But the holy grail here is really the unit test of the resolver function. The full source code can be found here but the meat and potatoes is outlined in the test here. Variables prefixed with _ are, in this case, different mocks.

it('The the promise resolves to a combination of the get results and route messages', function() {  
    var result = fn(_route, _http, _q);
    expect(angular.isFunction(result.then)).toBe(true);
    result.then(function(data) {
        expect(data).toBe('test test');
    });

    _timeout.flush();
});

The result of "test test" matches the mock data being returned form the _http and _route mock objects. Naturally, this example is simplified. However, I have also done some work in which complicated async logic was executed in these functions.

Conclution

It isn't a big change to wrap the resolver function inside a provider, and the benefit of being able to test a pretty vital part of the applications is significant. We also gain the ability to re-use this resolver code since multiple resolvers can be used for a single route.

What do you think is going to be the role of medical technology in 2030?

It started as "Folding At Home," a crowd-sourced project to map protein folding. For just a few watt hours a month, a home computer would think about the problem of protein folding while idle--a very ambitious project at a time in which the rate of technological change was still expected to follow Moore's law.

"Moore's law" is the observation that, over the history of computing hardware, the number of transistors in a dense integrated circuit doubles approximately every two years. The observation is named after Gordon E. Moore, co-founder of the Intel Corporation, who described the trend in his 1965 paper.

Hindsight, they say, is 20/20, but it took less then forty years for Moore's law to crumble under the weight of its shortsightedness; nothing humans do is linear.

By the early 20th century, the two year estimate had shrunk to a year and a half; and by 2020, real competition for Intel finally emerged to drive innovation at breakneck speeds. Looking back on it, I am sure that Intel, AMD and Apple could never have imagined the world-changing computations that their ever-faster x86 chips were to unlock. But--as with any big conspiracy that starts in a small, smoky room--someone at AMD brainstormed a cheap benchmarking solution with a human-friendly spin. Not only do you trample the competition, but you do it while solving the problems of humanity. This all came at the tail end of a professor from Carnegie Mellon's eradication of AIDS through a retro-virus designed on crowd-sourced protein data--a great payoff on the Watt hour investment the early adopters contributed to the world.

Business only jumps on the wagon after viable profitability is displayed, but once it jumps, it sure adds some major momentum. Even accounting for the multi-exponential revision to Moore's law, the years following the adaptation of benchmark saw a boom in technological leaps that made people's heads spin. The Intel "8086" event, iconic of the time, witnessed the release of a CPU with more cores then the 8086 had transistors. The news and consumers gave it little notice; it was reviewed as a "meta" on the 17th page of The Guardian. The news did, however, take notice when, in 2025, the last unique human protein fold was analyzed. "While groundbreaking in the field of biology, we are now faced with finding a new benchmarking problem," an Intel employee was quoted saying. "For now, we will focus on the rest of the mammalian branch of life."

The real importance of news recognition came in the political and social support of human protein programing outside life threatening ailments. Much like the increasing speeds of computers, our understanding of natural processes of amino acids ballooned into new fields of research, bio-programing. The last year of "chemical-pills" was this year, 2027; nothing humans do is linear.

5:14 - what he forgot to tell me was that the knowing the names are things is useful if you want to talk to somebody else.

So it isn't surprising that a lot of people, including yours truly, do the following google search before going on job interviews. Ideally, this is simply a lexical refresher for the abstractions and concepts you already use in your everyday work. On the other hand, this could be real cramming.

In education, cramming ("mugging or swotting, from swot, akin to 'sweat', meaning 'to study with determination'") is the practice of working intensively to absorb large volumes of informational material in short amounts of time.

In which case the person doing the search is trying to pull the wool over your eyes and make themselves appear more equitable then they are. The reason for the interview. This is why you should never ask those "interview questions" at your interviews. (But this isn't an interview / interviewee / interviewer bashing post.)

While the post is inspired by a real work interaction, the code in the examples are all faked, and no names will be used. The villain of our clean code story will be Microsoft Bob a diligent employee but sometimes misunderstood.

Interview

Since 'C++' we have all gone OO happy with our general language choices. As a result polymorphism comes up in pretty much any interview for software engineering. And it better. This is something you really need to know as a software developer. One of those, makes your life easier bits of knowledge.

But at an interview, generally the person is asked what it is? MS Bob is ready with a good replay.

In object-oriented programming, polymorphism refers to a programming language's ability to process objects differently depending on their data type or class. More specifically, it is the ability to redefine methods for derived classes. - Google Define.

MS Bob even went into detailed examples of how it has been used in the past on project he has worked on.

Creating custom data access layer to work with different DBMS.

And so MS Bob gets hired. But do we really know if MS Bob understands polymorphism. For example, here Bob only worked on the project, another engineer may have created the structure which Bob was diligent enough to follow.

Work

Well the day to shine comes eventually to every developer where they create their own project from scratch. To the developer this is the moment of truth. MS Bob's moment came in the form of a calculator application. And our imaginary MS Bob wrote: full LinqPad example

void Main()  
{
  var m = new Math();
  m.process("add", 1, 2).Dump();
}

public class Math {

  public int process(string type, int n1, int n2) {
    int result;
    switch (type) {
      case "add":
      result = n1 + n2;
      break;

      ...

      case "div" :
      result = n1 / n2;
      break;

      default :
      result = 0;
      break;
    }
    return result;
  }
}

Needless to say, this solution lacks a level of elegance OO allows us. As result this solution
- hard to expand on. Adding a new operation for example will require a full round of testing for all the other features.
- doesn't embody the concept of separation of concerns - hard to unit test because each test ends up testing multiple concerns. - not to mention the needless increase in cyclomatic complexity.

MS Bob's switch case had to go.

Polymorphic Solution

The process function in the math class is doing multiple things. It is figuring out what the operation is, and then it is preforming it. full LinqPad example

void Main()  
{
  (new Add()).process(1, 2).Dump();
  (new Sub()).process(1, 2).Dump();
}

public interface Math  
{
  int process(int n1, int n2);
}

public class Add : Math  
{
  public int process(int n1, int n2)
  {
    return n1 + n2;
  }
}

...

public class Div : Math  
{
  public int process(int n1, int n2)
  {
    return n1 / n2;
  }
}

Ok, so lets see how this code holds up to the scrutiny we placed on Bobs code.

• hard to expand on Not at all, i can create a new project import this assembly and create any number of math operations that take two integers and result in an integer. Endless possibilities for growth.
• doesn't embody the concept of separation of concerns Each operation is implemented in it's own class. Addition knows nothing about subtraction and vice versa. Also there is no conditional logic required.
• hard to unit test Not at all. Since each class is only responsible for one thing, each class only really needs to be tested against it's primary function. The are no conditional branches so failed tests are easy to trouble shoot.
• needless increase in cyclomatic complexity As pointed out above, there are no branching conditionals in this code.

Conclusion

So MS Bob is made up, but switch statements are littered through out much of the code I end up reading. It is a lazy solution in a scenario where clean code polymorphic solution is just as easy to create. But this is the difference between knowing the name of something and knowing something as Richard Feynman so cleverly explained in the video.

While I am not saying that you should never use a switch, the polymorphic solution fits much better into the modern day tool kit. Dependency injection containers for example are a great tool for application composition. And this type of polymorphic programing fits like a glove with convention/interface based dependency resolution.

Also, MS Bob will make future appearances, and while todays instance of MS Bob relates to a specific interaction I had at work, I too was once MS Bob on this subject. The concepts aren't hard to get, but even with out practice knowing the name isn't enough.

A previous post talked about a general idea behind data annotation and the ability to mark up classes. But the example was far from being real world or useful. Today we are going to explore the way that data annotation can be used to decouple business logic with angular bindings. We are in search of a simpler solution to ES6 modules or RequireJS and Angular modules.

Module Pattern and Angular

ES6 brings us modules and the "import" keyword for better composition management, which basically means that this code:

import {ngBase} from './ngBase';  

transforms into RequireJS code that creates a dependency and on './ngBase

define(['./ngBase'], function($__0) {  
  "use strict";
  if (!$__0 || !$__0.__esModule)
  $__0 = {default: $__0};
  var ngBase = $__0.ngBase;
});

Nicely enough, ngBase becomes the variable into which the import is piped, scoped to the wrapper function. So how does this play with something like Angular which has its module system. A quick look online brings about a general consensus that the module pattern is good for business logic, but the angular bootstrapping should take place once the require js modules are loaded.

• http://www.sitepoint.com/using-requirejs-angularjs-applications/
• http://solutionoptimist.com/2013/09/30/requirejs-angularjs-dependency-injection/
• http://marcoslin.github.io/angularAMD/#/home
• http://stackoverflow.com/questions/12529083/does-it-make-sense-to-use-require-js-with-angular-js

Each of these post talks about creating non-angular aware modules that are later bootstrapped in another bootstrapping file. In my mind, this is a bit messy. When anything changes, you must change the bootstrapping file and the implementation file logic. But data annotation solves this problem. We can defer bootstrapping by marking our classes with all required data annotations to complete the late bootstrapping.

Annotate it All

So data annotation lets us create classes that understand their own purpose. Ideally, anything in Angular can be broken down into a class constructor function with annotation that defines the class function.

We annotate the controller/factory/directive name and dependency list into the ngController/ngFactory/ngDirective and ngInject annotation.

Annotation Classes

The magic behind this type of annotation is a collection of annotation classes that can register the class it annotates against an angular module.

ngBase class is an abstract that all Angular-based annotations derive from. We do have a useful wrap function, which allows us to wrap the Angular array notation for dependency injection. The ngBase class is common ground for all Angular annotations from Angular registering functions (ngController/ngFactory/ngDirective).

ngController class is an actual annotation class. It describes controllers to angular modules. The register function, which is aware of annotation on the class, can work in combination with other annotations like route and inject. The controller annotation simply takes the name.

@ngController('main')
@ngInject(['$scope', 'data'])
@ngRoute('/Home', { templateUrl : 'home.html' });

export class main {  
  constructor($scope, data) {
    $scope.data = data();
  }
}

ngFactory annotation class for creating factories, the Angular version of a singleton. Like ngController, it also works in combination with

@ngFactory('data')

export class data {  
  constructor() {
    return () => "test";
  }
}

ngDirective annotation class for creating directives has some additional logic. Like the other ngBase classes the name of the directive is the first argument of the annotation constructor and the directive property object as the second argument. The constructor of the annotated class automatically becomes the link function on the directive object.

@ngDirective('hello', {
  scope : true,
  template : '<div> hello {{data}}</div>',
  restrict : 'AE'
})
@ngInject(['data'])
export class hello {  
  constructor(data) {
    return (scope, element, attr) => {
      scope.data = data();
    }
  }
}

The Bootstrapper

Annotations can bind behavior to a class, and we can process the behavior by looking at injectable dependencies. The ngBootstrap class processes a list of imports. In our bootstrapping process, this is denoted by arguments based on how Tracuer transpiles this code.

import {ngBootstrap} from './lib/ngBootstrap';  
import {data} from './data';  
import {main} from './main';  
import {hello} from './hello';

var app = ngBootstrap(document, angular.module('test', []), arguments);  

Transpiled, we get this code, which explains the argument's object.

define(['./lib/ngBootstrap', './data', './main', './main2', './hello'], function($__0,$__2,$__4,$__6,$__8) {  
  "use strict";
  if (!$__0 || !$__0.__esModule)
  $__0 = {default: $__0};
  if (!$__2 || !$__2.__esModule)
  $__2 = {default: $__2};
  if (!$__4 || !$__4.__esModule)
  $__4 = {default: $__4};
  if (!$__6 || !$__6.__esModule)
  $__6 = {default: $__6};
  if (!$__8 || !$__8.__esModule)
  $__8 = {default: $__8};
  var ngBootstrap = $__0.ngBootstrap;
  var data = $__2.data;
  var main = $__4.main;
  var main2 = $__6.main2;
  var hello = $__8.hello;
  var app = angular.module('test', ['ngRoute']);
  ngBootstrap(document, app, arguments);
  return {};
});

Conclusion

You can find running code examples here

This post gave a real world example of the usefulness of data annotation. But there is a lot more. There are benefits to decoupling the application from Angular. The annotation can be quickly re-writen to bind a different framework to your current classes. There are benefits to unit testing a directive without needing to bind to angular.

Overall, data annotation is a tool for the tool box, and more posts will come on how this tool is useful.

Thinking About the Problem

The first place you go: wiki. If you are anything like me, lambda calculus hurts your head and only paints a fuzzy picture. Heavy math aside, what problem does it solve? It lets us have recursion of anonymous functions.

Factorial function to the rescue

function factorial(num) {  
  return num === 0 ? 1 : num * factorial(num -1);  
}  

To define recursion you must first define recursion.

But seriously, in order to be able to make this function anonymous, we need to get rid of our dependency on "factorial" I agree, crazy. But lets give it a try. Some closure? Maybe we can wrap it in a function? We no longer call the function by its name, does that help? Maybe if we can somehow call the wrapper function with the result of itself.

function(factorial) {  
  return function(num) {   
    return num === 0 ? 1 : num * factorial(num -1);  
  };
}

And queue the entrance of the Y Combinator!

function Y(bindFn) {  
  return function () {  
    return bindFn(Y(bindFn)).apply(null, arguments);  
  };  
}  

Untwisting the Pretzel

Right, that's what I thought, that a bit crazy. The factorial wrapper gets passed into it self, is that even possible? Seems so, here is a trace: (jsbin)

There is a beauty to this almost mechanical algorithm, reminiscent of the sewing machine or the RNA copy mechanism.

• Wrap the anonymous function.
• Send in the wrapped anonymous function into the Y combinator function.
• Unpack the anonymous function and execute it, by passing the Y combinator result of the wrapped function into the wrapped function.

The Angular team published a playground for @script: https://github.com/angular/atscript-playground

So why is annotation-oriented programing so much win?

The quick answer is meta programing. Buzz word alert: The basic idea is that you can mark up some object in your code with additional meta-information. And the cool part: parse that mark up at runtime to give your application additional intelligence.

But lets take a quick look:

// An annotation class that defines an animal
class animal {  
  constructor(sound) {
    this.sound = sound;
  }
  speak() {
    console.log(this.sound);
  }
}

An annotation is really just the instantiation of some class that can be bound to an 'annotations' property on the target class. The above code created an annotation class called "animal." When instantiating a class, we can create animal with a custom sound. As the example bellow shows, the @script annotation syntax allows us to attach the annotation class of "animal" to any classes we create like "cow" or "dog" targets.

// Create a cow class an annotate it with a cow sound.
@animal('Mooo')
class cow {  
}

// Create a dog class and annotate it with a dog sound.
@animal('Woof')
class dog {  
}

This is @script transpilation; the @animal('Woof') actually translates to the following JavaScript.

var dog = function dog() {};  
($traceurRuntime.createClass)(dog, {}, {});
Object.defineProperty(dog, "annotations", {get: function() {  
  return [new animal('Woof')];
}});

After the classes are marked up with annotation, a new property, 'annotations,' becomes available on the class object. It is an array, allowing for multiple annotations to be applied to a class.

cow.annotations[0].speak() //=> Mooo  
dog.annotations[0].speak() //=> Woof  

This is nothing revolutionary, but it does create a great convention, allowing us to write code that describes itself to itself. Lets take a look at a way that this can be consumed. In the code example, lo-dash, it is used for writing functional code, I am a lambda whore.

_.each([cat, dog, table], c => {  
  var noop =  { speak : () => {}};
  (c.annotations || [ noop ])[0].speak();
  });

Each loop can process the individual classes for the annotation property. In more complicated workflows, this can take into account the different annotation classes.

Conclusion

You can find running code examples here.

The code example above is not very useful, since any number of polymorphic practices can resolve this problem in much cleaner ways. But it does show how annotations can create behaviors on classes that you may not have the rights to change. Annotation also get out of the way of the implementation, allowing you to attack cross cutting concerns without affecting the annotated class.

• I get paid for it.
• I like the creativity it unleashes.
• I seek to communicate (with computers).
• I played with legos as a kid, and programing is damn close.

Originally I started coding because I wanted to be like my dad. This is shortly after I wanted to be a fireman and cosmonaut. One day, Dad showed up with a computer from work, and that night we "pair programmed" a times table program. A life long love was born.

My hope is that, as a reader, you are here because you too share a fanatical dedication to your craft.

Conventions

• MS Bob When dealing with programing concepts, every now and again the bad ideas need to be highlighted. What better scapegoat then MS Bob.