How to convert a function definition as string to code in JavaScript


Just a snippet for converting a function as string to code:




<!doctype html>
    <meta charset=”utf-8″ />
    <meta http-equiv=”x-ua-compatible” content=”ie=edge”>
    <meta name=”description” content=”A page to quickly spike some code or styling.”>
    <meta name=”viewport” content=”width=device-width, initial-scale=1″>
    <link rel=”icon” href=”data:;base64,iVBORw0KGgo=”>   
        // Define a function as a string.
        // Don’t forget the “(” and the “)” arround the function.
        // See:
        var functionAsString = “(function(a, b){ return a + b; })”;

        // Convert a string containing a function definition to a real function.
        var fn = eval(functionAsString);

        // Execute the created function.
        var result = fn(1, 2);

        // Log result is: 3

Developer Anarchy, made possible by C-level buy-in and Micro Services.

A very great podcast on developer anarchy:

As Fred George explains, developer anarchy will work in environments, where you have C-Level Buy-In and can have rapid feedback.

So you better not try it on the mars lander project Smile.

It envies self-directed teams, fast deployment, rapid feedback, small components / services and business knowledge by the developers.

CSS modules


A great article on css modules:

This allows css to be imported and used in JavaScript.

A great fit for web components and can be easily used in frameworks like Aurelia, Angular, React etc.



Create a *.css file called submit-button.css  with content:
.normal { /* all styles for Normal */ }
.disabled { /* all styles for Disabled */ }
.error { /* all styles for Error */ }
.inProgress { /* all styles for In Progress */



Then use the css in your JavaScript like:

import styles from ‘./submit-button.css’;

buttonElem.outerHTML = `<button class=${styles.normal}>Submit</button>`


HTML (result)

<button class=”components_submit_button__normal__abc5436″> Processing… </button>


Under the covers it uses ICSS, more on ICSS:

Yes: Cycle.js is getting some TypeScript love


In his blog post: mentions:

I am a JavaScript programmer, and I make some libraries. Recently, however, I’ve been writing TypeScript for RxJS version 5 (used in Angular 2 which is also authored in TypeScript),

and I’m in the process of rewriting Cycle.js in TypeScript.

I find the cycle.js framework very interesting and I love to see it written in TypeScript, so kudo’s for André Staltz, when he accomplishes this.

Create a Visual Studio 2015 Project Template and upload it to the gallery

The most simple way to create a Visual Studio 2015 Project Template, is to start from an existing project template.

In short:



The installation folder for the custom templates will be:




Upload to gallery

When you have created the Visual Studio extension, there is just one step left: uploading to the gallery:

Go to and sign in.




Upload *.vsix



Enter some meta data





Don’t forget to publish!



After the publish you should find your project template in Visual Studio:

File > New > Project… > Online > search


Smooth list item scrolling with jQuery Animate, don’t forget to .stop()

If you want to scroll to items in a list, when clicking on a button, you can use jQuery.animate(), but don’t forget to do a .stop() before the .animate() to prevent jank.








module spike {
    “use strict”;
    var _activeListItem: IListItem = null;   
    var _items: Array<IListItem> = [
        { sortOrder: 1, title: “Item 1” },
        { sortOrder: 2, title: “Item 2” },
        { sortOrder: 3, title: “Item 3” },
        { sortOrder: 4, title: “Item 4” },
        { sortOrder: 5, title: “Item 5” },
        { sortOrder: 6, title: “Item 6” },
        { sortOrder: 7, title: “Item 7” },
        { sortOrder: 8, title: “Item 8” },
        { sortOrder: 9, title: “Item 9” },
        { sortOrder: 10, title: “Item 10” },
        { sortOrder: 11, title: “Item 11” }
    var _list: HTMLDivElement = <HTMLDivElement>document.getElementById(“list”);
    var _$list = $(_list);

    export function getId(sortOrder: number): string {
        return “target” + sortOrder.toString();

    export function onClickDown(evt: Event): void {

        if (_activeListItem.sortOrder === _items.length) {

        if (_activeListItem === null) {
            _activeListItem = _items[0];

        _activeListItem = _items[_activeListItem.sortOrder];

    export function onClickUp(evt: Event): void {
        if (_activeListItem === null || _activeListItem.sortOrder === 1) {
        _activeListItem = _items[_activeListItem.sortOrder – 2];

    export function removeActiveClass(): void {
        var listItem = document.getElementById(getId(_activeListItem.sortOrder));

    export function renderListItems(list: HTMLDivElement): void {
        var frag = document.createDocumentFragment(); => {
            var div = document.createElement(“div”);
   = “target” + item.sortOrder.toString();
            var content = document.createTextNode(item.title);


    export function scrollTo(id: string) {
        var listItem = document.getElementById(id);
        var offsetTop = listItem.offsetTop;

            scrollTop: offsetTop – 40
        }, 500);


    _activeListItem = _items[0];

    export interface IListItem {
        sortOrder: number;
        title: string;



body {
    color: rgb(68, 68, 68);
    font-family: “Open Sans”, sans-serif;

html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre,
abbr, address, cite, code,del, dfn, em, img, ins, kbd, q, samp,small, strong, sub, sup, var,
b, i, dl, dt, dd, ol, ul, li, fieldset, form, label, legend,table, caption, tbody, tfoot, thead,
tr, th, td, article, aside, canvas, details, figcaption, figure, footer, header, hgroup, menu,
nav, section, summary, time, mark, audio, video {
    border: 0;
    border-image-width: 0;
    -webkit-box-sizing: border-box;
    -moz-box-sizing: border-box;
    box-sizing: border-box;
    margin: 0;
    outline: 0;
    padding: 0;

button {
    border: 1px solid rgb(126, 33, 109);
    background: none;
    color: rgb(126, 33, 109);
    cursor: pointer;
    outline: none;
    padding: 4px 4px 4px 4px;
    position: relative;
    -moz-user-select: none;
    -ms-user-select: none;
    -webkit-user-select: none;
    user-select: none;

button:hover {
    background-color: #dbe0e0;

.list {
    bottom: 40px;
    left: 0;
    margin: 1px;
    overflow-y: auto;
    position: absolute;
    right: 0;
    top: 0;

.list-item {
    height: 80px;
    margin: 10px;
    padding: 10px;

.title {
    margin-left: 20px;
    margin-top: 10px;

.footer {
    border-top: 1px solid rgb(126, 33, 109);
    bottom: 0;
    height: 40px;
    left: 0;
    padding-top: 6px;
    padding-left: 6px;
    position: absolute;
    right: 0;

.left {
    border: 1px solid rgb(126, 33, 109);
    bottom: 0;
    left: 0;
    position: absolute;
    right: 50.5%;
    top: 0;

.right {
    border: 1px solid rgb(126, 33, 109);
    bottom: 0;
    left: 50.5%;
    position: absolute;
    right: 0;
    top: 0;

.wrapper {
    bottom: 20px;
    left: 20px;
    min-height: 300px;
    overflow: hidden;
    position: absolute;
    right: 20px;
    top: 40px;

.active {
    background-color: rgb(239, 222, 236);

Micro services in the real world, by Pieter Joost van de Sande, what a great talk!!

Sometimes, when you listen to a talk a light will go off, in this case it was more like a lighthouse.

Pieter Joost van de Sande gave a talk yesterday, about micro services.


What a great talk!


Some short notes I took during his talk (not necessarily the things Joost said and all references to businesses and persons are fictional).


What is the size of a micro service?

About a max size of 1000 rows of GO code.

So you should make a micro service based on the smallest consistent boundary.

Albert Einstein once said: make it as simple as possible but no simpler.

Joost said: make it as small as possible but not smaller.


What should NOT be a micro service?

Business entity are NOT a great base for micro service, because they are needed by multiple micro services. Instead use technical concepts as a micro service base.


Good candidates are:

  • Registration
  • Profile
  • Online
  • Matching


Do NOT use:

  • Company
  • Contact
  • Document
  • User


There will be only one micro service responsible for the quality of a specific part of the data

Data will be replicated in many services, but there will only be one service responsible for the quality of a specific part of the data.

E.g. if the registration service fires an event, that an user is registered with nickname: bigelefant, then all other services that depend on this data will be receive this specific event and they can’t argue that the event happened or that the data in the event is not correct.

It happened, so it is true!


How do you scale 1 micro services?



By using sharding. So all users with a nickname starting with an “A” go to registration service instance A and all users with a nickname starting with a “B” go to registration service B.

One note on sharding, you can’t do sharding on 2 different keys. If you want to shard the data on nickname and email (to guarantee unique nicknames and unique email addresses), then you should create 3 micro services, the first shards on nickname the second on email and de third service will gather both events and will be responsible for acknowledgements of the uniqueness of both keys.


Which tool did you use for requirements gathering?

Event storming by Alberto Brendolini (


Do NOT use queues, use persistent streams

Queues destroy data, by using persistent streams you can always continue where you left of.


Micro services do not have dependencies

Well this is not entirely true, when a micro service goes down and comes up again, it will ask the event stream system to play back all events it missed during it’s down time, so each micro service has a dependency on the event stream system, but there are 2 reasons, why this dependency is not a problem.

  • First, the event stream system is constructed of many independent event streams and an event stream is just an immutable (append only) file on disk.
  • Second, the event streams are stored on a google file system, that is guaranteed to have a 100% up time.


There are 2 things hard in software engineering: naming things and caching invalidation

Well the last part is solved in this micro services architecture by using immutable append only files. When something is immutable you can cache it indefinitely.


What is the data size increase factor by using denormalized replicated data?

Well in our case the total factor was about 200x!

But disk space is really really really cheap and the reducement in complexity is immense.

You gain a lot of flexibility and are much better prepared to scale your system.


How do you deal with configuration changes?

We use a micro service for that :-)

The configuration service fires an event, when configuration changes. These events are received by all micro services that use that specific part of the configuration.



What is the greatest challenge, when working with a micro services architecture?

Eventual consistency!


When using a micro services architecture, specific data will not be immediately updated on all micro services.

You can’t change specific data at a specific moment in time for the whole system.

Data will updated like a wave, but eventually all micro services will get the new data.


What besides using a micro services architecture, do you use to increase system availability?

Service degradation!

  E.g. we first ask the platinum online service to give a list of interesting people that are oneline, this service will take in to account geolocation and all kind of other metrics, when the service does not respond in 50ms we ask a the normal online service to give a list of people, this service will only take in to account gender en age, when this service does not respond in 100ms, Google adds will be displayed, so we earn by having our services offline :-).


How do you deal with different versions of different micro services?

We don’t have different versions!

We deploy the system as one big monolith.

All code lives in one big GIT repository and we have 3 branches:

  • Main
  • A
  • B

The branches A and B are for A-B testing.

We don’t use semantic versioning any more.

The system has a version, but this is just a counter.

When we deploy, the whole system is deployed to 5% off all users and steadily increased, when errors are found in the log the system will automatically rollback the deployment.

All deployments are stored.



How do you deal with different versions of events?

We make the schema of our events backwards compatible, but sometimes this does not work.

In 2 cases we even asked the user to supply data, because we wanted to add a new property and we didn’t know what the default value should be for the existing property in that case, we had to ask the user, when the user signed in, he or she was asked a question, the answer was the default value for the new property.


Some people say you must not put data in an event only “keys”?

We put as much data as possible in an event, because these events are shared by the micro services, when a micro service needs a specific part of the data and only has the key of this data it must ask another service for this data, hence you get the SOA dependency hell.

Data that is not of interest for the micro service that produces the event, can be of vital importance for another micro service, so we put as much as possible all data in an event.


How do you deal with planning?

We don’t plan.


You as a software engineer deliver value by increasing quality of the code or by adding new features, that’s the only thing that counts.

If your manager ask, when will this new and great part of the system be ready, you see, I can’t tell you.

You do requirements gathering and start to build, then by delivering working software you can steadily get a notion, when parts will be ready.

It’s ready, when it is ready.


How do you take on testing and documentation?

We don’t test

Well this is not entirely true, for each micro service we describe (in GO code) which events go in and which events go out. This delivers executable code, that can check if the micro service behaves like it should and delivers documentation about, how the system works.


Bugs are our highest priority!

When an bug that impacts the user is encountered all is dropped en the bug is tackled immediately.

When you have a bug list, you are doing something drastically wrong.