Category Archives: Javascript

Vsts: setting up tests and coverage to run on build for Javascript projects

I’m currently writing Javascript code, React and Redux to be more specific. After picking up the brilliant book “Human Redux” I’ve really started to enjoy this ecosystem.

But, remembering the brilliant Zombie TDD I also want to get back in the testing-game. This is quite easy when using create-react-app, as Jest is a great tool.

However, this is not the topic of this post. The topic here is how to get Microsoft VSTS (Visual Studio Team Services) to run your tests during the build phase, and report test results and coverage, and provide you with stuff like this:

2018-07-25 10_14_11-Window

coverage

You need to do stuff both to your project, and to your vsts build definition.

First off, your project:

You need the jest-junit package

npm install jest-junit -S

And, you need to edit your package.json file. First, add the top-level entry “jest”, with the following content

"jest": {
    "coverageReporters": [
      "cobertura",
      "html"
    ]
  },

and the top-level entry “jest-junit”, with the following content

"jest-junit": {
    "suiteName": "jest tests",
    "output": "test/junit.xml",
    "classNameTemplate": "{classname} - {title}",
    "titleTemplate": "{classname} - {title}",
    "ancestorSeparator": " > ",
    "usePathForSuiteName": "true"
},

Finally, you need to add the task “test:ci” to your script-block:

"test:ci": "react-scripts test --env=jsdom --testResultsProcessor=\"jest-junit\" --coverage",

So, what have we done here?

  1. We set the coverage reporters of Istanbul (which jest uses) write both the cobertura and html formats
  2. We set up jest-junit to produce junit-xml from our tests
  3. We create a test-task to be run on vsts that uses these two

You also want to add the resulting files to .gitignore

# testing
/coverage
/test

This should now work locally, test it by running

CI=true npm run test:ci
The coverage-folder should be created and the file test/junit.xml should be created.

So, everyting is good on the project side, time to move on to vsts.

Create a build, and add three tasks:

The first is an “npm” task, configure it like this
npm_test

Then, you need to publish the results of the test and the coverage, so add a

“Publish Test Results” and a “Publish Code Coverage Results” task

npm_publish_test

npm_publish_coverage

Make sure you select “Even if a previous task has failed, unless the build was canceled” on the option “Run this task” under the tab “Control Options” for both publish tasks, as we want tests reports and coverage even if we have failing tests.

In addition you want to set the environment variable CI to true, in order for Jest to run all tests:

ci_true

With these things in place your build should now include test results and coverage reports!

10 Open-Source Projects Every JavaScript Geo Dev Should Know About

That is not tied to a proprietary platform

An article flew by in my Twitter stream, with the title “10 Open-Source Projects Every #JavaScript Geo Dev Should Know About”. As I consider myself a Javascript Geo Dev i thought that there might be som OpenSource gems I’ve missed and clicked the link. The link brought me to esri.com and what I was presented with was this article, listing 10 open source javascripts projects that I’ve never heard of.

Why? Most of them (or all, no links, and I can’t bother to google them all) are ESRIs own libraries, and although OpenSource they are tied to the ESRI platform. In fact, from what I understand, 4 or 5 of them are directly tied to ArcGIS Online.

This made me feel a bit tricked. Not that there are anything wrong with ESRI releasing OpenSource code, but where there is an implicit requirement that you use their paid services, what is the use for others?

But, instead of complaining I’ll present a list of my own, that should be of a wider use to all Javascript Geo devs (although I’m rather certain that most of you’ve heard about most of them already!)

1. OpenLayers 3

We all know OpenLayers 2 (don’t we?) and most of you probably know that the brand new OpenLayers 3 is in the making (beta 4 now!). Lots of features, a complete rewrite and heavy use of the Closure compiler.

2. Leaflet

The web-friendly, lightweight, hipster no-frills mapping library that excels in beeing un-bloated and easy to use. Just try it, seriously!

3. Proj4js

A JavaScript port of proj.4, meaning that you can do all your coordinate re-projections right in the browser!

4. jsts

A JavaScript port of JTS Topology Suite, a library of spatial predicates and functions for processing geometry objects. It works, but is a rather straight Java-port, which leads me to the next entry:

5. Njord.js

Njord.js is a vanilla JS, client side lib for lightweight geoprocessing, envisioned to compete with jsts and heavily inspired by Shapely. It’s written by yours truly and is under development.

6. D3

A JavaScript visualization library for HTML and SVG. I personally know next to nothing about it and haven’t used it, but if you need to add some visualisations to your map app D3 seems to be the way to go.

7. Three.js

Three.js simplifies the task of working with WebGL from Javascript. We all know that 3d is the future, so why not start learning it. If you don’t think that mapping and 3d can be united, take a look at this lib.

8. KuGIS

KuGIS is a browser-driven GIS-application with support for a lot of spatial analysis. Driven by Leaflet and JSTS. Really shows what you can do in the browser these days.

9. Bootleaf

Although I haven’t used it myself I’ve heard some good things about this lib, actually just a “simple, responsive template for building web mapping applications with Bootstrap 3, Leaflet and typeahead.js”.

10. SpatialBB

Also written by yours truly, SpatialBB (or “spatially enabeled Backbone”) is an attempt to merge the MVC-capabilities of Backbone.js with the spatial capabilities of Leaflet. Also a work in (some state of) progress, but I kinda like the idea.

So, that was my list. What did I forget? Are there any gems that’s useful? Please point me in their direction!

Ninjatriks i JavaScript, del 2

Jeg var ikke sikker på om det kom til å skje, men når jeg øynet muligheten til å kombinere mine to favoritthobbyer, koding og øl, måtte jeg jo bare. Dermed blir det del 2 av ninjatriks i JavaScript, denne gang med fokus på funksjonell programmering og underscore.js.

Ifølge Douglas Crockford er JavaScript “Lisp in C’s Clothing”. Dvs, det er et funksjonelt språk utkledd som et prosedyrespråk. De fleste som har skrevet litt JavaScript har funnet ut at det går fint å skrive prosedyre (og kanskje også objekt)-orientert i JavaScript.

Men, hvis det nå er sånn at JavaScript er funksjonelt så burde det kanskje være noe å hente? Jeg snakker ikke helt nazi no-sideeffects, everything is a function, men noen gode ideer her og der?

Det har ihvertfall jeg funnet ut de senere år, etter at jeg tok i bruk Backbone.js og dermed Underscore.js. Underscore.js er et lite utility-bibliotek som beskriver seg som “It’s the tie to go along with jQuery’s tux, and Backbone.js’s suspenders.”. Ja, mange av de funksjonene underscore.js tilbyr finnes som “native”-javascript funksjoner i nyere implementasjoner. Dog, jeg har lært meg underscore og trives med det, dermed så vil jeg fokusere på det.

Men, hva er det å hente? Hva gir underscore og en funksjonell tankegang meg? Jeg tenkte å ta noen eksempler, så kan du se selv.

Eksempel 1 er ganske greit. Du har ei liste med objekter (la oss si øl-objekter). Du vil finne alle objekter (dvs øl) som er produsert av Haandbryggeriet. Gitt lista (som tilfeldigvis er fra en juleølsmaking jeg deltok på):

    var beers = [
       {"brewery": "Austmann", "name": "Jingle Beer", "score": 6.49, "abv": 7},
        {"brewery": "Binding-Brauerei", "name": "Santa Clausthaler", "score": 2.14, "abv": 0},
        {"brewery": "Brasserie St-Feuillien", "name": "Cuvée de Noël", "score": 6.43, "abv": 9},
        {"brewery": "Dahls", "name": "Julebrygg", "score": 5.19, "abv": 4.5},
        {"brewery": "Fanø Bryghus", "name": "Julebryg", "score": 5.74, "abv": 7.2},
        {"brewery": "Grans Bryggeri", "name": "Lade Gaards Brygghus Juleøl", "score": 5.92, "abv": 6.5},
        {"brewery": "Hansa", "name": "Ekstra Vellagret Julebrygg", "score": 6.39, "abv": 6.5},
        {"brewery": "Haandbryggeriet", "name": "Nissefar", "score": 6.07, "abv": 7},
        {"brewery": "Haandbryggeriet", "name": "Nissegodt", "score": 6.26, "abv": 4.5},
        {"brewery": "Inderøy", "name": "Nisseøl", "score": 6.06, "abv": 4.5},
        {"brewery": "Nøgne Ø", "name": "God Jul", "score": 5.89, "abv": 8.5},
        {"brewery": "Nøgne Ø", "name": "Julesnadder", "score": 7.19, "abv": 4.5},
        {"brewery": "Nøgne Ø", "name": "Special Holiday Ale", "score": 6.71, "abv": 9},
        {"brewery": "Ægir", "name": "Julebrygg", "score": 6.21, "abv": 4.7}
    ];

Hvis vi nå vil finne ut hvilke som var butikkøl (dvs abv <= 4.7) kan du gjøre dette med en for-løkke:

    var pol_limit = 4.7;
    var shop_beers = [];
    for (var i = 0; i< beers.length; i++) {
        var beer = beers[i];
        if (beer.abv <= pol_limit) {
            shop_beers.push(beer);
        }
    }
    console.log(shop_beers);

Ganske standard, men mye boilerplate og unødvendige temporær-variabler. Hva med Underscore.js? Vi kan bruke _.filter():

var isShopBeer = function (beer) {
    return (beer.abv <= 4.7);
};
console.log(_.filter(beers, isShopBeer));

Det som skjer her er at _.filter() looper gjennom lista beers og returnerer en ny liste over de ølene som returnerer true i funksjonen isShopBeer. Ganske fiffig, færre linjer og lettere utbyttbart.

En annen artig ting, er at siden vi nå har en funksjon for å bestemme om et øl er butikkøl, vet vi at alle øl som returnerer false i denne er poløl. Dermed kan vi finne antall poløl ved å bruke _.reject():

console.log(_.reject(beers, isShopBeer));

Så, dermed kan vi finne ut at vi hadde:

var shopBeers = _.filter(beers, isShopBeer);
var polBeers = _.reject(beers, isShopBeer);

console.log("Antall øl: " + beers.length);
console.log("Antall butikkøl: " + shopBeers.length);
console.log("Antall poløl: " + polBeers.length);

eller:

  • Antall øl: 14
  • Antall butikkøl: 6
  • Antall poløl: 8

Hva om vi vil finne ut hvilket øl som gjorde det best? Og dårligst? Med en for-løkke kunne vi gjort dette som

var max = beers[0];
for(var i = 1; i max.score) {
        max = beer;
    }
}
console.log(max.name) //Julesnadder

Med underscore kan vi bruke _.max():

var getBeerScore = function(beer) {
    return beer.score;
}

console.log(_.max(beers, getBeerScore)); //Julesnadder

og tilsvarende har vi såklart _.min():

console.log(_.min(beers, getBeerScore).name); //Santa Clausthaler

Altså:

var best = _.max(beers, getBeerScore);
var worst = _.min(beers, getBeerScore);

console.log("Best: ", best.brewery + " " + best.name + " (" + best.score + "/10)");
console.log("Værst: ", worst.brewery + " " + worst.name + " (" + worst.score + "/10)");

eller:

  • Best: Nøgne Ø Julesnadder (7.19/10)
  • Værst: Binding-Brauerei Santa Clausthaler (2.14/10)

Best av polølene da? Typisk ville vi gjort noe sånt som:

var pol_limit = 4.7;
    var max = 0.0;
    var best;
    for (var i = 0; i< beers.length; i++) {
        var beer = beers[i];
        if (beer.abv > pol_limit && beer.score > max) {
            console.log(beer.name)
            best = beer;
            max = beer.score;
        }
    }
    console.log(best.name); //Special Holiday Ale

Men, vi kan kombinere underscore-funksjoner:

console.log(_.max(_.reject(beers, isShopBeer), getBeerScore)); //Special Holiday Ale

Hvor mange øl var det med fra hvert bryggeri?

Vel, en måte å løse det på er følgende:

var result = {};
for (var i = 0; i< beers.length; i++) {
    var beer = beers[i];
    if (result.hasOwnProperty(beer.brewery)) {
        result[beer.brewery] += 1;
    } else {
            result[beer.brewery] = 1;
    }
} 
console.log(result);

Med underscore kan vi bruke _.groupBy():

var getBrewery = function (beer) {
    return beer.brewery;
}
console.log(_.groupBy(beers, getBrewery))

denne gir oss riktignok en liste med øl-objekter på hver key, ikke bare antallet. Det kan vi dog få til med en _.reduce():

console.log(_.reduce(_.groupBy(beers, getBrewery), function (memo, beers, brewery) {
    memo[brewery] = beers.length;
    return memo;
},{}));

Men, det spørs om det er det vi egentlig vil? Med resultatet av groupBy'en kan vi spytte ut endel statistikk:

_.each(_.groupBy(beers, getBrewery), function (beers, brewery) {
    var avg_score = _.reduce(beers, function(sum, beer){ return sum + beer.score; }, 0) / beers.length;
    console.log(brewery + ": " + beers.length + " øl, " + avg_score + " i gj.snitt");
});

Vel, det var det for denne gang. Håper du lærte noe nytt, hvis du har spørsmål eller kommentarer er det bare å mase (jeg har sikkert gjort noen feil, jeg er på ingen måte noen mester, men jeg lærer stadig!)

Ninjatriks i Javascript, del 1

Jeg drister meg frempå med en “del 1”, selv om jeg ikke vet om det blir noen del 2, 3 etc..

Uansett: Jeg skriver jo endel Javascript, og jeg ser endel javascript-kode rundt om kring. En ting som irriterer meg er hvordan folk roter til det globale namespacet, og dermed tenkte jeg å dele noen triks for å holde styr på namespaces etc i Javascript.

Detter er på ingen måte noen fasit, men det er noe som jeg synes fungerer godt selv. Har du inspill eller korreksjoner lærer jeg gjerne av deg!

Hold det globale namespacet ryddig!

Alle funksjoner og variabler du definerer i Javascript legger seg i det “globale namespacet”. Dvs, du kan få trøbbel med at du overskriver variabler eller funksjoner som finnes fra før (hvis disse ikke har vært ryddige). Men, frykt ikke, løsningen er rimelig enkel: namespacing! Hvordan? Vel, Javascript har ikke noe namespace-konsept, men det har objekter (eller, object literals, dvs {}). Disse kan vi bruke som namespace. Si at jeg vil ha et namespace Atlefren. Da kan jeg lage det som følger:


var Atlefren = {};

Da kan jeg, lage funksjonene mine som dette:


Atlefren.myFunc = function () {
    return "foo";
};

Problemet med denne løsningen er ser du hvis du i fil a.js skriver følgende:


var Atlefren = {};
Atlefren.myFunc = function () {
    return "foo";
};

og i fil b.js:


var Atlefren = {};
Atlefren.myOtherFunc = function () {
    return "bar";
};

Hvis du inkluderer a.js og så b.js vil myFunc være “undefined”, fordi “namespacet” Atlefren settes til et tomt objekt i toppen av b.js. Et triks for å omgå dette er følgende:


var Atlefren = window.Atlefren || {};

Her skjer følgende: “namespacet” Atlefren settes lik namespacet Atlefren fra “window” (som er det globale namespacet), og hvis ikke dette finnes lages det et nytt, tomt objekt.

Dermed vil både Atlefren.myFunc og Atlefren.myOtherFunc eksistere etter at a.js og b.js er lastet, og rekkefølgen du laster dem i har heller ikke noe å si.

Selveksekverende funksjoner
Men, vi er ikke helt i mål. Hva med diverse småfunksjoner du ikke vil eksponere ut? ta dette eksempelet:


var Atlefren = window.Atlefren || {};

function someHelpingFunction(string) {
    return string + "!";
}

Atlefren.myFunc = function () {
    return someHelpingFunction("foo");
};

Nå vil Atlefren.myFunc være pent og pyntelig inne i namespacet, mens someHelpingFunction vil ligge i det globale namespacet. Vi kunne såklart lagt someHelpingFunction i Atlefren-namespacet også, men det blir upent. For det første vil det da bli masse, unødvendige funksjoner i Atlefren-namespacet, for det andre må du bruke notasjonen


namespace.funksjonsnavn = function () {};

hver gang du skal lage en ny funksjon. Det er mye skriving. Heldigvis finnes det en løsning, og den inkluderer anonyme funksjoner. Såkalte selv-eksekverende funksjoner. Teorien er sm følger:

Du kan definere en anonym funksjon som følger:


function () {};

Vi vet også at denne kan assignes til en variabel og kjøres:


var func = function () {};
func();

Dette kan også gjøres i en go:


(function () {/*do someting*/}());

Her lager vi en funksjon, og kjører den umiddelbart (det siste () er kallet til funksjonen). Det er “god skikk” å legge et ekstra par parenteser rundt en slik funksjon, for å signalisere at dette er en “selveksekverende funksjon) Denne funksjonen blir kjørt en gang og så har du ikke tilgang til den mer. Det fine her er at funksjoner at et eget scope, variabler og funksjoner definert inne i en funkjsjon legges IKKE i det globale namespacet. Dermed kan vi gjøre følgende:


var Atlefren = window.Atlefren || {}; //definer namespacet
(function () {
    //denne funksjonen finnes kun i scopet til den selv-eksekverende funksjonen
    function someHelpingFunction(string) {
        return string + "!";
    }

    // denne legges på Atlefren-namespacet som før
    Atlefren.myFunc = function () {
        return someHelpingFunction("foo");
    };
}());

Ett lite problem gjenstår: jeg må fortsatt skrive hele namespacet mitt for hver funksjon jeg skal eksponere. Dette kan bli slitsomt hvis jeg har et langt, nøstet namespace (eks org.atlefren.demo.stuff, for Java-fanatikerene), eller om jeg skal endre navnet på namespacet mitt. Heldigvis er jo den selveksekverende funksjonen nettopp en funksjon, og kan dermed ta argumenter. Vi kan dermed sende inn namespacet som et argument og bruke dette (jeg har lagt meg på å kalle parameteret ns, så jeg alltid vet hva jeg jobber med:


var Atlefren = window.Atlefren || {}; //definer namespacet
(function (ns) {
    "use strict";

    //denne funksjonen finnes kun i scopet til den selv-eksekverende funksjonen
    function someHelpingFunction(string) {
        return string + "!";
    }

    // denne legges på Atlefren-namespacet som før
    ns.myFunc = function () {
        return someHelpingFunction("foo");
    };
}(Atlefren));

Sånn, nå har vi et ryddig public namespace, ikke så mye clutter og fint strukturert kode. Hvis du er eksta nøye kan du legge på en “use strict” øverst i den selv-eksekverende funksjonen, for å fortelle javascript-parseren at du skriver “skikkelig” javascript (som jeg har gjort).