Scratch Map Summer 2018

After some epic trips in the past years, this is what our scratch map looks like. It doesn’t give you a clue about the frequency or preferred places, but it does show our biases to date. Antarctica is in our todo list.

The kite runner

Lately, I felt the urge to read fiction again, after a long time focused on tech and non-fiction. I was also looking to widen my perspectives and stay away from sci-fi for a bit. I found an English book club ran by the neighborhood public library, and The kite runner was the first reading since I joined. Actually, a friend of mine had lent me the book many years ago, but I had forgotten most of it. It seems unfair that I did because the second read has left me very moved.

The book’s central character is Amir, born from a rich Pashtun merchant in the Kabul of the 60s. The first third of the book pivots on the relationships with his father and his Hazara servant during his teenage years. After the Saur revolution, the family flies to America and we are introduced to how was life like for Afghani immigrants, but also how our beloved character transitions to become an adult. The book’s third act goes back to Afghanistan, but to a different one, as it is set up after the Ismalic Jihad that ended up with the Taliban ruling the country.

Because I had already read the book I didn’t expect it to be able to generate so many emotions as I went through it. I was so wrong. In the beginning, I had some trouble to like it, and Hosseini’s way of expressing Amir feelings felt a bit pretending, but every time he focused on a particular plot, I felt engaged again. Certain scenes were a lot more disturbing than I remembered, to the point that I had to stop a couple of times, take fresh air, and make myself aware that I was living in a totally different reality than the books – that’s something I don’t experience in many books. Having to deal with my father’s death last year struck all kind of emotions and relived conversations as well – in a way, I think that helped the book to have more impact on me this second time, and reminds me that there are books that hold healing power if read at the proper time. Finally, I couldn’t help but think that the Amir and Hassan friendship is a metaphor for Afghanistan as a failed state during the many wars that beat the country in the 1974-2001 period. It seems to me as if Hosseini was trying to say that the country cannot be at peace until the Pashtuns and Hazaras are equals.

I’d say The kite runner is a book about guilt and redemption, a father-son relationship, and perhaps the main window to Afghanistan culture for most westerns. I think the book fares well in each of those.

On JavaScript modules

Next week I'm going to participate in a session about package managers for different languages – we'll present pip (python), composer (PHP), and npm (JavaScript). In sharing ideas with my colleagues I realized how many of the struggles of modern JavaScript tooling and workflow is based upon the fact that the language didn't have a built-in module system until recently, so I've decided to write down my thoughts as preparation for the talk.

A brief history of modularity

For a more in-depth explanation, please, check this evolution of modularity in JavaScript – it has many details hard to find in other places.

JavaScript was created in 1995 without modules, and every <script>  shared the same global scope. We learned how to work with functions and namespacing to gain a minimum ability to divide our code into pieces, but as the importance of JavaScript grew, the pressure to have better alternatives was more intense as well.

In the server, Node.js became the de facto standard and its module choice, CommonJS, the format used in the incipient node package manager,npm . That was 2010, 15 years after the JavaScript release. Browser-side nobody could afford or was interested in a unified module system, so alternatives bloomed and the market became more fragmented. With time, the use of npm skyrocketed and so the importance of CommonJS, even for browsers.

How to make CommonJS available in the browser

It may be worth to pause and remember that at that point we still didn't have a module system for browsers. We had something that was simple enough to work with and hack. The core of the CommonJS API is quite simple, and has two pieces:

  • require: a function to import some code that's somewhere else.
  • module.exports: a variable to hold the code to be exported.

Let's say that I have an input.js file in CommonJS format:

var constants = require( './constants' );
console.log( constants.HELLO + ' ' + constants.WORLD );

And the corresponding constants.js contains:

module.exports = {
    HELLO: 'HELLO',
    WORLD: 'WORLD',
};

I can't add those files to the browser through the <script>  tag and expect them to work. That's invalid JavaScript as browsers understand it.

How do we make it valid JavaScript? Well, something we can do is to copy the modules to the same file, wrap them in a function (so their internal variables don't collide) and expose the necessary keywords through the function arguments:

// Scope the first module
function( require, module ) {
    var constants = require( './constants' );
    console.log( constants.HELLO + ' ' + constants.WORLD );
}

// Scope the second module
function( require, module ) {
    module.exports = {
        HELLO: 'HELLO',
        WORLD: 'WORLD',
    };
}

This can be included in the browsers! It won't fail, but it will also do nothing.

OK, next step, let's implement require : it is a function that takes a module identifier and returns its module.exports object. We can do that:

// Implement require
var modules = {};
var require = function( moduleId ){
    var tmpModule = {};
    modules[ moduleId ]( require, tmpModule );
    return tmpModule.exports;
}

// Scope and register the first module
var input = function( require, module ) {
    var constants = require( './constants' );
    console.log( constants.HELLO + ' ' + constants.WORLD );
}
modules[ './input.js' ] = input;

// Scope and register the second module
var constants = function( require, module ) {
    module.exports = {
        HELLO: 'HELLO',
        WORLD: 'WORLD',
    };
}
modules[ './constants' ] = constants;

It looks a bit better, but still does nothing and we ended up adding a lot of variables to the global scope.

Let's fix this by scoping the code within an IIFE (so it doesn't pollute the global scope) and execute the main module, the entry point of our program (./input.js in our example):

(function() {
  // Implement require
  var modules = {};
  var require = function( moduleId ) {
    var tmpModule = {};
    modules[ moduleId ]( require, tmpModule );
    return tmpModule.exports;
  };

  // Scope and register the first module
  var input = function( require, module ) {
    var constants = require( './constants' );
    console.log( constants.HELLO + ' ' + constants.WORLD );
  };
  modules[ './input' ] = input;

  // Scope and register the second module
  var constants = function( require, module ) {
    module.exports = {
      HELLO: 'HELLO',
      WORLD: 'WORLD',
    };
  };
  modules[ './constants' ] = constants;

  // Execute the main module
  var module = {};
  modules[ './input' ]( require, module );
})();

This is it! We've transformed our initial CommonJS modules into something that is executable in today browsers.

This exercise would need quite a bit of work to be production-ready, but the fundamental steps are there and it's not difficult to see that's easily automated by tools. This is mostly what Webpack does when it transpiles CommonJS to IIFE. Rollup seems to be a bit more elegant but its strategy is similar. If you're curious, check the runnable code they generate.

The transition to ESModules

The success of npm and CommonJS  taught the browser ecosystem a valuable lesson: a better workflow was possible. Some attempts were made to replicate the registry plus format formula but, eventually, npmCommonJS won .

Flash forward to 2015 and the ES6 standard introduces modules in the JavaScript language. Three years after that, browser adoption and node support are still not universal or complete, but everybody agrees that it will. The whole ecosystem seems to be on board and execution environments, toolslibraries, and authors are preparing for what that means.

If we believe that, npm will continue to be the central registry to distribute JavaScript for the foreseeable future, but CommonJS will no longer be the default module format. In this moment of transition, not everything is clear or necessarily better. The ashes of the module wars are still warm, but they won't be forever.

The right to repair

These farmers can't repair the equipment they own because the manufacturer doesn't sell them the necessary tools to configure the software that controls the pieces. They're trapped into a monopoly. In response, they've become activists for their Right to Repair. But this is a wider issue than a John Deere monopoly in the agricultural business, it affects any industry whose products embed software – which is mostly everyone these days.

My first plant

My parents in law got me an evergreen bonsai for Christmas, a Ficus Retusa.

It's not until recently that I've got interested in the idea of growing a plant. I find fascinating that you can mold a living being to your liking, within certain constraints. Every branch contains a possibility, and you've got to decide which ones to develop. The fact that it's a slow process that takes years to fully see the results speaks of the patience and constant caring you need to put into it. I don't want to think too much about that because the thought of committing myself to something for so long is scary! At the same time, I've found a sense of calm and bonding in things like cleaning every individual leaf of the tree once a month – I can understand much better now to Paul Richardson, the exo-botanist of Mars.

Being the first plant I own, I'm still learning a lot about everything: its watering needs, what's a good pruning balance, how to identify and treat pests and diseases, etc. So far, it's been enjoyable.