The Worlds of Ursula K. Le Guin

To learn to make something well can take your whole life. And it’s worth it.

— Ursula K. Le Guin

The documentary that explores the life and work of Ursula K. Le Guin is now being screened in several festivals and events. Check out the dates and join one if you can. As a backer of the project, I had early access to the film. It’s only a few months since UKL has left us, so it came to me with a feeling of farewell and closure.

Function keys in Thinkpads

I usually work with an external ThinkPad keyboard, which matches the configuration of my laptop’s. Lately, though, I’ve been using my laptop’s keyboard more and more. At some point, Lenovo decided to design the 6th keyboard row in a slimmer way and switched the standard F1-F12 keys to function keys (volume, brightness, etc). This is very inconvenient if your work involves typing a lot, as editors tend to offer handy shortcuts with the F1-F12 keys.

This is how you change the default configuration: FN + ESC.

The girl on the train

This was the last assignment of the book club before the summer hiatus.

This is a thriller that builds slowly. Rachel is the main character, she’s a depressed, mentally unstable, and alcoholic woman that can’t cope with having lost her husband to another woman. Megan is also lost and has her own difficulties to find anything that fills her in life. Anna is a housewife and mother whose life goals are fulfilled.

Like in a jigsaw, we’re presented with partial and unreliable information about what’s happening to each one of them, which helps to build and keep the narrative tension. Through the story, they face different facets of emotional dependency, abuse, or personal struggles with life. There are some scenes that I particularly liked it because they embody so well one of the themes that give shape to the zeitgeist of our era: Rachel, in her daily train trips to work, invents any kind of stories about the people she sees through the window; their lives are always happier and out of struggles. We know that’s not true, but she doesn’t have that information. This made me reflect on our interactions through the so-called social networks and how they can be so much detached from the real ourselves in so many ways.

At times, I was so dragged to the story, that I even found myself reading while walking to board a plane.

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.