Master on Libre Software Planet

September 16, 2018

Andrés Maneiro

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.

by nosolosw at September 16, 2018 05:02 PM

August 09, 2018

Andrés Maneiro

July 22, 2018

Andrés Maneiro

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.

by nosolosw at July 22, 2018 11:41 AM

June 27, 2018

Andrés Maneiro

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.

by nosolosw at June 27, 2018 01:15 PM

June 25, 2018

Andrés Maneiro

Summer solstice

Depending on how you think about seasons, the summer’s solstice is the beginning of the summer or the middle of it – in either case, enjoy.

by nosolosw at June 25, 2018 01:28 PM

May 31, 2018

Andrés Maneiro

May 15, 2018

Andrés Maneiro

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.

by nosolosw at May 15, 2018 01:40 PM

April 11, 2018

Andrés Maneiro

February 25, 2018

Andrés Maneiro

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.

by nosolosw at February 25, 2018 10:22 AM

February 23, 2018

Andrés Maneiro

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.

by nosolosw at February 23, 2018 01:28 PM

February 11, 2018

Andrés Maneiro

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.

by nosolosw at February 11, 2018 07:15 PM

February 02, 2018

Andrés Maneiro

The luxury of a desktop app

These apps are just little icons on my desktop bar. I don’t even have Bluetooth enabled on my computer. The amount of memory they consume is a luxury – the luxury of desktop apps.

by nosolosw at February 02, 2018 01:42 PM

February 01, 2018

Andrés Maneiro

Seamless offline docs

This combination of Zeal and Atom (with the dash package) seems to just work, and help you set up a seamless offline docs experience.

by nosolosw at February 01, 2018 08:06 PM

January 27, 2018

Andrés Maneiro

Tempestades de sal, Sés

Sés is a Galician singersongwriter. Her stage presence and lyrics reminds me of what it means to grow in small villages by the periphery. I feel connected to that dignity and survival skills, because it embodies the attitude of the women I grew around. The Galician matriachy.

by nosolosw at January 27, 2018 04:43 PM

January 24, 2018

Andrés Maneiro

UKL passed away

I’ve just learned that Ursula K. Le Guin is no longer with us. She left multiple worlds for us to play with and learn from. Two of them –The Left Hand of Darkness, and The Dispossessed– are my goto guides when it comes to imagining societies that take into account the role of self-management, genre, language, and free commerce. We cannot bring her back, but we still have her words to read all that she wanted to tell us.

by nosolosw at January 24, 2018 01:15 PM

January 08, 2018

Andrés Maneiro

JavaScript in use 2011-2017

According to the HTTP Archive, the top 1.000 websites download 5 times more JavaScript today than seven years ago – HTML grew 2x and CSS 3x. Combining that with the fact that the mobile web is more present than ever, the result is that the main bottleneck for the websites we create and consume is the CPU.

by nosolosw at January 08, 2018 07:18 PM

January 02, 2018

Andrés Maneiro

Input lag: 1977-2017

Input lag: 1977-2017 is an essay about the time it takes several computers to display a character from a keypress. A lot of newer computers take 3 to 5 times more than 30 to 40 years old computers.

by nosolosw at January 02, 2018 02:51 PM

December 20, 2017

Andrés Maneiro

Google Maps’ Moat

Google Maps’ Moat, by Justin O’Beirne. On the competitive advantage that Google Maps has over Apple Maps – equally interesting for map nerds and business people.

by Andrés at December 20, 2017 01:49 PM

December 02, 2017

Andrés Maneiro

Afuega’l Pitu

Saturday occupation: eating spicy cheese made of cow milk and paprika.

by Andrés at December 02, 2017 02:34 PM

December 01, 2017

Andrés Maneiro

Shelter from the Storm

Mars soundtrack (the National Geographic tv-show) is fantastic. Nick Cave is just the perfect voice to convey that feeling of exploration and fear. Moon, Interstellar, The Martian, etc; it seems sci-fi movies got an appreciation for soundtracks that have a major role in the film – and I enjoy that.

As much as I like Cave’s main theme for Mars, after a few episodes, I was in the need of something like Dylan’s Shelter from the Storm. Exploration needs joy and celebration.

by Andrés at December 01, 2017 02:51 PM

November 25, 2017

Andrés Maneiro

Agile according to Basecamp

Running in Circles is Basecamp’s view of agile product management. They acknowledge the value of working in cycles, but add three pieces: having the time to focus, being able to modify the original plan, and tackle the core unknowns of the feature first.

The first two are enablers that are provided to the makers by management. The last part is how the maker make the most of those powers. Together, they form a process that is nicely captured with the uphill / downhill metaphor. Uphill you are discovering the unknowns and making decisions about what goes in, downhill everything is clear and you are implementing it at warp factor 10:

by Andrés at November 25, 2017 01:07 PM

November 23, 2017

Andrés Maneiro

Ten years of mobile

10 years of mobile by Luke Wroblewski packs a lot of knowledge in one hour and a half. If I could only watch one talk about mobile, I'd make it this.

by Andrés at November 23, 2017 08:12 PM

November 22, 2017

Andrés Maneiro

Module counts

I came across Module Counts, which tracks the number of published modules for major language package managers. At this point, npm has 600k packages published, which is 3 to 4 times what any other package manager has. I’m not aware of download statistic across different package managers, but npm has surpassed the 2 billions downloads a week mark.

by Andrés at November 22, 2017 02:41 PM

November 18, 2017

Andrés Maneiro

Are you serious

This puts me in the perfect mood before going for a walk in this sunny and cold Saturday.

by Andrés at November 18, 2017 03:25 PM

November 12, 2017

Andrés Maneiro

Software architecture failing

Software architecture failing: tech writing is biased towards what the big ones do, which usually doesn’t fit most other contexts – but, who got fired for choosing IBM, right? Although I feel connected to this rant at an emotional level, I do think it’s necessary to elaborate more and make a positive contribution: help to create and spread that alternate history of software development. How do you do it? Hat tip: Fran.

by Andrés at November 12, 2017 10:30 PM

The language of programming

The language of programming is about the struggles non-native English speakers face when learning to program. Hat tip: Manuel.

by Andrés at November 12, 2017 10:15 PM

November 01, 2017

Andrés Maneiro

Touch typing in Dvorak

On November 2016 I had a free month between jobs. Apart from some resting, reading, and general preparations for my new adventure, I still had quite a bit of free time to do new things or build good habits. It was while cleaning my office that I found a keyboard I had bought a couple of years back:

Its layout was a beautiful matrix -which is good for your fingers- and came with Dvorak by default. So it struck me: how about improving my typing during the coming weeks?

As a programmer, typing is an essential skill for me. I had been doing it for more than 15 years in a learn-by-doing way, and I plan to keep typing for years to come. I thought it would be fun to spend a couple of hours a day training in touch-typing and give Dvorak a second try. And so I did.

The experience

Before I switched, I recorded about 15 typing sessions at TypeRacer using the QWERTY layout, which logs typing speed (words per minute) and accuracy (% characters right over the total). I was at 67 wpm and about 95% accuracy at the time.

Progress was very humbling at the beginning; it felt like learning to walk again, and I swear that, sometimes, I could even hear my brain circuits being reconfigured! After a few weeks, though, I was under 40 wpm and, by the end of the month, I was under 50 wpm. I stopped quantifying myself by then: as I started working, I had a lot of typing to do anyway.

During the first months, the only moments I struggled and felt like perhaps the switch wasn’t a good idea after all was during real-time communication: chats, slack, etc. I don’t know what people thought of me, but my velocity at the time was typing-bounded – I was certainly a very slow touch-typist by my own standards.

But time passed and I improved.

Spáñish Dvorak and symbols

Throughout the process I changed my setup quite a bit: I started my journey using the Programmer Dvorak layout with a TypeMatrix keyboard. After a few months, I switched back to my good old ThinkPad keyboard because having to use a mouse again after years not using it was a pain. A few months later, I switched to the Dvorak international, because the Programmers Dvorak layout didn’t quite suit me. Then, I tweaked the common symbols I use for programming so they were better positioned. Besides, although the bulk of my typing is in English, I still need to write decent Spáñish, which basically means using tildes on vowels and ñ. TLDR: the Spanish Dvorak version made things more difficult, so I’ve just tweaked the Dvorak international to accommodate tildes and ñ as I see fit.

At this point, I believe I can patent my own layout:

All the changes I did to the symbol positions have affected my ability to build muscle memory for them – sometimes I still need to look at some specific symbol on the keyboard. However, the current version has been unchanged for months, so I only need a bit more time for them to stick.

The numbers

Given that I was a QWERTY user for 15 years, I thought I would give the new layout a year before comparing any statistics. The fair thing to do would be comparing after 15 years, but I’m a bit impatient for that. I went to TypeRacer again and noted down the results for about 20 races. These are the numbers of this totally unscientific experiment:

A few remarks:

  • In terms of speed, it seems that I’m mostly there. My median speed now is 65 wpm, 2 words per minute less than before. I had a higher peak (83 vs 79) in one of the current typing sessions, but I was under 60wpm in more sessions this time.
  • In terms of accuracy, I’ve improved a bit. My median accuracy has increased by 1,5 points, and I had only 2 sessions below 95% of accuracy this time.

Coda

Overall, I’m very happy with the switch to Dvorak. My accuracy has improved, meaning that I can maintain a longer typing rhythm. Not having to correct mistakes makes me a faster typist as well, and by learning to touch-type I also have grown more endurance.

This experiment was very humbling but fun. I believe it increased my brain plasticity by an order of magnitude, and I’m hoping to improve my numbers as years pass as well. However that turns out, though, I think of this as a gift to the elder me, a way to prevent typing pain in the future and promote a healthy use of the tools I heavily depend upon.

by Andrés at November 01, 2017 03:45 PM

October 25, 2017

Andrés Maneiro

I spent the weekend reorganizing things, including my blog. I’ve got a new WordPress theme (independent publisher) which looks a lot more lightweight. I’ve consolidated the essays section with stuff that grew out of individual posts (I keep thinking that someday I’ll have the time to publish them as independent e-books), polished the about, fixed some links in the glossary, and started to reorganize the archives.

I’m also going to try a different approach in the following months: instead of having separate blogs for music, lifestream, thoughts, etc I’m going to publish everything here – I do not publish that much anyway, and I like the idea of this having a more personal touch.

by Andrés at October 25, 2017 07:16 PM

October 22, 2017

Andrés Maneiro

Learning to learn

When we want to acquire a new skill, we are faced with two choices: trial-error, or instruction. One is experience-driven or practice-based, the other is concept-driven or theory-based.

The trade-offs

Trial-error is the built-in mechanism humans come with to acquire knowledge and skills – our thinking processes are optimized for that. However, it may be expensive and impractical in some situations. For instance, learning to pilot an aircraft by trial-error is risky should you want to keep the chances of learning in the future high. We have developed systems that lower the cost of trial-error, though, such as pilot simulators. It can also be time-consuming: we just don’t have the time to trial-error every piece of knowledge our society is based upon!

Learning by instruction appears to be more efficient: we are presented with models and recipes that work, saving us a lot of time that we can use to advance our knowledge further. Nevertheless, the instruction is not always possible; sometimes the map of knowledge of a certain domain isn’t built yet, so we need to rely on the trial-error approach. Even most important is the fact that internalizing abstract knowledge not based on direct experience seems to be more difficult for humans.

This poses a question: how shall we learn?

The Dreyfuss model

In February 1980, Dreyfuss brothers published a seminal paper on how to teach: «A five-stage model of the mental activities involved in directed skill acquisition». This work was supported by the US Air Force, which was interested in improving their training programs.

What they said is 1) we should recognize the role of the first-hand experience in acquiring knowledge and 2) to become an expert it is necessary to learn the rules, guidelines, and maxims of the particular skill we are interested in.

The rules are the principles that always apply, they don’t depend on anything so they are context-free or non-situational. Examples of rules are the valid movements of a piece in the go game, the set of instructions in programming, the techniques in the Aikido martial art.

The guidelines are the principles that only apply in specifics contexts, so they are context-bound or situational. Things like josekis in the go game (sequences of moves in a specific part of the board), the design patterns in programming, or the katas in Aikido.

The maxims are principles that guide us towards achieving our long-term goal, they help us by assigning a value to guidelines: is this joseki worth it if I’m playing for territory in go? Is the ability to grow new features necessary for this specific part of the application? What specific throw should I use if I want to face the next adversary?

For one to become an expert, rules, guidelines, and maxims should be second nature.

Dreyfuss defines a 5-step process someone goes through to gain knowledge: novice, competence, proficiency, expertise, mastery. Others outline different systems that include three stages. What’s important is to realize that the learning process is at its best when we take a practical approach and theory is presented to the learner as they are prepared to assimilate the next artifact – rules, guidelines, maxims.

Coda

Learning to learn is probably one of the more important skills when we no longer know what’s coming next. The real world TM tends to be more chaotic and intertwined than the sequential process outlined by Dreyfuss. Realizing where are you at a particular skill will help you in making decisions about what focus on. For instance, am I a novice at skill X? Well, at this point, I’m better off focusing on learning the rules and imitate what others have done. And so on.

Learning also takes a lot of time – someone has even published a number, about 10.000 hours to become an expert in anything. It’s a lot! It may be discouraging. Luckily, a practice-based approach makes things more rewarding, and time flies when we are enjoying the process.

by Andrés at October 22, 2017 11:13 AM

October 16, 2017

Andrés Maneiro

The thing that get us to the thing

Past Saturday, AMC aired Halt and Catch Fire season finale. I saw this tv-show grow over 4 seasons and I’m sad it’s over.

HACF resonated with me because it was about the pleasure of making things work and the cost of pursuing your dreams. We need a whole lot more stories about the woes and joys of creation to learn how to navigate that world and to inspire us. We need more builders and dreamers capable of not burning themselves out.

Bonus points for using the evolution of computers as the McGuffin. But, as much as I liked the history of computers being the central plot of a well done period  drama, HACF wasn’t about computers. The computers aren’t the thing. They are the thing that get us to the thing.

by Andrés at October 16, 2017 10:13 PM

October 06, 2017

Andrés Maneiro

The pleasure of finding things out

This was the first book listening experience that I’ve actually finished. Sean Runnette‘s voice was adequate for setting the tone and rhythm – actually, sometimes I felt I was listening to Feinmann himself!

Having read Surely You’re Joking, Mr. Feynman!What Do You Care What Other People Think? and some other papers/videos, most of the stories in the book I already knew, but it had some new material that made it interesting nonetheless. This is more mathematical/physical intense than the others, probably because it’s mostly focused on the scientific and less in the human Feynman – but also because many chapters are directly transcribed from conferences he gave. It’s also worth noting that, unlike the other two, this book was published without Feynmann intervention: it’s published 10 years after his death.

If I had to choose only a Feynman book I’d choose Surely You’re Joking, Mr. Feynmann! It’s better edited and has more variety. Then, if you are hungry for more, What do you care what other people think? contains new stories. I liked this one, but I doubt it’s a good introduction to Feynmann lifestyle, work, values, and character.

by Andrés at October 06, 2017 01:25 PM

September 28, 2017

Andrés Maneiro

Code simplicity

 

I’ve just finished the book Code Simplicity. It presents a framework for thinking about software development in the form of laws and rules. It’s short but comprehensive. From my experience, the laws and rules hold true. I think the book has value as an overall perspective of what’s important in software development, and there are some chapters that are really spot on: for example, the equation of software design – something that I’ve already included in my glossary and plan to expand.

Code Simplicity doesn’t intend to land the laws and rules to something actionable, though. I’m at a point in my career where I’m focused on consolidating and reflecting upon how to achieve simplicity in software design – that means that I crave for specifics so I can compare them with mine.

As a cross-recommendation, if you are interested in learning about the laws of software development in a manner that is actionable, I’d suggest reading the Beck’s trilogy: Extreme Programming Explained: Embrace Change, Test Driven Development: by example, and Implementation Patterns. Those three books make a great combination of macro-forces (at a project level) and micro-forces (at a coding level) in software design. They were fundamental in consolidating my experiences as a programmer, so I’m highly biased towards them.

Hat tip for the Code Simplicity recommendation: Nikolay.

by Andrés at September 28, 2017 09:56 PM

September 08, 2017

Andrés Maneiro

September 01, 2017

Andrés Maneiro

Turns out algorithms are racists

«Technology is neither good nor bad; nor is it neutral.»

Melvin Kranzberg’s six laws of technology

One of the things I was very into a decade ago was studying the intertwine between technology, culture, and society. From those years, I developed a sensitivity about my role as an engineer, or as an enabler of possible worlds.

This is one of the things I wanted to avoid:

A person isn’t able to clean his hands because the machine sensors are only prepared to detect white hands! That’s a horror story that could make a BlackMirror episode.

This made me think about the mainstream perception of Machine Learning and Artificial Intelligence technology. Lately, some friends of mine are sharing with me clickbait news like Facebook shuts down robots after they invent their own language. They ask me if robots could take over, soon. Well, I can tell you something: at this stage of technology, I am not worried about robots taking over. What I do worry about is how our inability to understand technology creates racists algorithms that reinforce our biases.

by Andrés at September 01, 2017 08:31 AM

August 28, 2017

Andrés Maneiro

August 27, 2017

Andrés Maneiro

(…) the number-one indicator of a successful team wasn’t tenure, seniority or salary levels, but psychological safety. Think of a team you work with closely. How strongly do you agree with these five statements?

  1. If I take a chance, and screw up, it will be held against me
  2. Our team has a strong sense of culture that can be hard for new people to join.
  3. My team is slow to offer help to people who are struggling.
  4. Using my unique skills and talents come second to the objectives of the team.
  5. It’s uncomfortable to have open honest conversations about our team’s sensitive issues.

Teams that score high on questions like these can be deemed to be “unsafe”. Unsafe to innovate, unsafe to resolve conflict, unsafe to admit they need help.

— Engineering a culture of psychological safety.

by Andrés at August 27, 2017 09:10 PM

August 08, 2017

Andrés Maneiro

Highly recommended article: Born for it, on how the image of software developers came about.

by Andrés at August 08, 2017 09:12 PM

July 31, 2017

Andrés Maneiro

Code and decision trees

A lot of what programs do is transforming inputs into outputs. Take, for example, a piece of JavaScript code like this:

itemsToMarkup( items, viewType, galleryType ) {

    let markup;

    switch ( viewType ) {
        case 'gallery':
            if ( 'individual' === galleryType ) ) {
                markup = getHTML( items );
            } else {
                markup = getShortcode( items );
            }
            break;

        case 'image':
        default:
            markup = getHTML( items );
    }

    return markup;
}

What’s the purpose of this code? It takes some input data structures and outputs a markup, either proper HTML or a code to be processed by later stages of the pipeline. At the core, what we are doing is taking a decision based on the input’s state so it can be modeled as a decision tree:

By restating the problem in a more simple language, the structure is made more evident. We are free of the biases that code as a language for thinking introduces (code size, good-looking indenting, a certain preference to use switch or if statements, etc). In this case, conflating the two checks into one reduces the tree depth and the number of leaves:

Which back to code could be something like:

itemsToMarkup( items, viewType, galleryType ) {

    let markup;
    const isGalleryButNotIndividual = ( view, gallery ) => view === 'gallery' && gallery !== 'individual';

    if( isGalleryButNotIndividual( viewType, galleryType ) ) {
        markup = getShortcode( items );
    } else {
        markup = getHTML( items );
    }

    return markup;

}

By having a simpler decision tree, the second piece of code makes the input/output mapping more explicit and concise.

by Andrés at July 31, 2017 05:23 PM

June 26, 2017

Andrés Maneiro

A new middle class?

In this paper, we make the case that the high-productivity digital firms are starting to generate a new middle class. It’s a virtuous circle. Consumers flock to those firms because they offer lower prices and better service. Workers migrate there from low-productivity firms because the high-productivity firms offer better wages for the same occupations—and, often, steadier hours and better benefits.

— The Creation of a New Middle Class?: A Historical and Analytic Perspective on Job and Wage Growth in the Digital Sector. [PDF]

by Andrés at June 26, 2017 01:41 PM

June 22, 2017

Andrés Maneiro

The Google repository

I’ve been reading how Google organizes its codebase: they maintain a hyper-large repository containing everything, since the beginning of the company. I guess you may find Gmail, Photos, or AdWords there. You won’t find Android or Chrome, though – these are open source projects.

The repository is 86Tb of data, 1 billion of files, and 35 billion of commits. To manage this complexity, they needed to build their own tools: a home-grown Version Control System that can work effectively with such a repository at this scale, editor integration, building and automated testing tools, etc.

They develop all the code against trunk/master, meaning that if you are updating a library, you’ll also need to fix all applications that depend on it. Every project will be up-to-date, even abandoned projects.

The advantages

The main reasons they claim this approach works for them are: it makes easier reusing blocks of knowledge company-wide and reduces the friction to contribute between projects/teams. UI primitives, building tools, etc, all are shared by any project that wants them, it’s just a matter of depending on the master version. It minimizes the costs of versioning/integration and the curse of being left behind when something is updated and you cannot keep up with the changes (the experts will do it for you!).

As a side effect, when working on libraries/frameworks it’s easier to understand the performance/impact/etc of a specific change (you can run tests on real projects) and to put together a task-force to fix issues affecting several applications.

The disadvantages

This approach comes with downsides as well: they mention the amount of maintenance this setup requires even with all the tooling they have already built. With a monolithic repo, it’s easy to run into unnecessary dependencies that bloat the binary size of a project (and they do), the costs inherent to updating basic blocks used through the whole company, etc.

Another point is that it makes difficult having external contributors. Although they have a space in the repository for public/open-sourced projects, the article is unclear on how they manage 3rd-party contributions there – external programmers don’t have access to the internal building tools that Google programmers have. High-profile products like Android or Chrome -where outside contributors are expected and encouraged- have walked away from this approach.

Coda

I highly recommend reading the paper, it’s a pretty unique approach, and the article does a good job on presenting a balanced perspective.

by Andrés at June 22, 2017 05:45 PM

May 01, 2017

Andrés Maneiro

How comparing things is faster and simpler with immutability

In the previous post of the series, I wrote about the nature of value and reference data types, and the differences between shallow and deep operations. In particular, the fact that we need to rely on deep operations to compare things is a major source of complexity in our codebases. But we can do better.

Comparing mutable structures

When working with mutable data structures, things like determining whether an object has been changed or not is not so simple:

var film = {
    'title': 'Piratees of the Caribean', 
    'released': 2003
};

// At some point, we receive an object and one of its properties
// might have changed. But how do we know?
newFilm = doSomething( film );

film === newFilm; // What does a shallow equality yield?

If we are allowed to mutate objects, although film and newFilm identifiers are equal, the payload might have been updated: a shallow equality check won’t suffice, we’ll need to perform a deep equality operation with the original object to know.

Comparing immutable structures

In JavaScript, primitives (numbers, strings, …) are immutable, and reference data types (object, arrays, …) are not. But if mutable structures are the reason why comparing things is difficult, what would happen if we worked with reference data types as if they were immutable?

Let’s see how this would work:

If something changes, instead of mutating the original object, we’ll create a new one with the adequate properties. As the new and the old object will have different identifiers, a shallow equality check will set them apart.

var film = {
    'title': 'Piratees of the Caribean', 
    'released': 2003
};

var doSomeThing = function( film ) { 
    // ... 
    return Object.assign( 
        {}, 
        film, 
        {'title': 'The curse of the Black Pearl'} 
    ); 
}

var newFilm = doSomething( film ); 

film === newFilm; // false

If nothing changes, we’ll return the same object. Because the identifier is the same, the shallow equality check will yield true.

var film = {
    'title': 'Piratees of the Caribean', 
    'released': 2003
};

var doSomeThing = function( film ) { 
    // ... 
    return film; 
} 

var newFilm = doSomething( film ); 

film === newFilm; // true

It is easier to tell what have changed when reference data types are immutable because we can leverage the shallow equality operations.

As a side-effect, it takes less effort to build a whole lot of systems that depend on calculating differences: undo/redo operations, memoization and cache invalidation, state machines, frameworks to build interfaces with the immediate mode paradigm, etc.

Coda

One of the reasons I started this series of posts was to explain how using immutable reference data types was one of the tricks at the core of Redux and React. Their success is teaching us a valuable lesson: immutability and pure functions are the core ideas of the current cycle of building applications – being the separation between API and interface the dominant idea of the previous cycle.

I have already mentioned this some time ago, but, at the time, I wasn’t fully aware of how quick these ideas will spread to other areas of the industry or how that will force us to gain a deeper understanding of language fundamentals.

I’m glad they did because I believe that investing in core concepts is what really matters to stay relevant and make smart decisions in the long term.

by Andrés at May 01, 2017 07:51 PM

April 30, 2017

Andrés Maneiro

How equality and copy operations work

In the introductory post of this series we talked about the differences between value and reference data types:

  • Value data types store their payload as the contents of the variable.
  • Reference data types store an identifier as the contents of the variable, and that identifier is a reference to the actual payload in an external structure.

Through this post will see how the equality and copy operations use the content of the variable, meaning that they’ll use the payload for data types and the identifier for reference types.

Working with value data types

Let’s say we have the following value variables:

In plain JavaScript, this would be:

var foo = 42;
var bar = 42;
foo === bar; // this yields true

If we were copying variables instead:

var foo = 42;
var bar = foo;
foo === bar; // true

foo = 23;
foo === bar; // false

As the content of the variables is the mere payload, the operations are straightforward.

Working with reference data types

Let’s say now that we are working with reference data type variables:

In JavaScript, this would translate as:

var x = {'42': 'is the answer to the ultimate question'};
var y = {'42': 'is the answer to the ultimate question'};
x === y; // This yields false.

When we create new reference data type variables, they are going to have a brand new identifier, no matter whether the payload is actually the same than other existing variable. Because the language interpreter is comparing identifiers, and they are different, the equality check yields false.

What if we were copying variables instead:

var x = {'42': 'is the answer to the ultimate question'};
var y = x; // Copies x identifier to y.
x === y; // This yields true.

It is important to realize why these are equal: because their identifiers are equal, meaning that both variables are indexing the same payload.

With that in mind, what would happen on modifying the payload?

x['42'] = 'the meaning of life'; // Changes the payload.

x === y; // Still true, the identifiers haven't changed.
console.log(y['42']); // Yields 'the meaning of life'.

But:

var x = {'42': 'is the answer to the ultimate question'};
var y = x; // Copies x identifier
x === y; // We already know this is true.

x = {'42': 'the meaning of life'}; // New identifier and payload.

x === y; // This would yield false.
console.log(x['42']); // 'the meaning of life'
console.log(y['42']); // 'is the answer to the ultimate question'

The reason is that x = {'42': 'the meaning of life'} assigns a new identifier to x, that references a different payload – so we’ll be back to the first scenario shown in this block.

(A short aside: in the introduction, I mentioned that references and pointers were different. The above case is a good example of how they’re different: if y was a pointer, it would index the contents of x, so both variables would remain equals after x contents change.)

In computer science, the operations that work with the contents of the variable (be it values or reference identifiers) are called shallow operations, meaning that they don’t go the extra step to find and work with the actual payload. On the other hand, deep operations do the extra lookup and work with the actual payload. Languages usually have shallow/deep equality checks and shallow/deep copy operations.

JavaScript, in particular, doesn’t provide built-in mechanisms for deep equality checks or deep copy operations, these are things that either we build ourselves or use an external library.

An example with nested reference data types

A JavaScript idiom to create new objects by reusing parts of existing ones is using the method Object.assign(target, …sources):

var x = {'42': 'meaning of life'};
var y = Object.assign({}, x);
x === y; // Yields false, identifiers are different.
x[42] === y[42]; // Yields true, we are comparing values.

Object.assign creates a shallow copy of every own property in the source objects into the target object. If the target has the same prop, it’ll be overwritten. In the example above, we’re assigning a new identifier to the variable y, whose own properties will be the ones present in the object x.

This works as expected for objects whose own properties are value data structures, such as string or number. If any property is a reference data structure, we need to remember that we’ll be working with the identifiers.

For example:

var book = {
    'title': 'The dispossesed',
    'genre': 'Science fiction',
    'author': {
        'name': 'Ursula K. Le Guin',
        'born': '1929-10-29'
    }
};

// We are creating a newBook object:
// * the identifier would be new
// * the payload would be created by shallow copying 
//   every book's own property
var newBook = Object.assign({}, book);

newBook === book; // false, identifiers are different

// Compare value data types properties:
newBook['title'] === book['title']; // true
newBook['genre'] === book['genre']; // true

// Compare reference data types properties:
newBook['author'] === book['author']; // true

Both newBook and book objects have the same identifier for the property author, that references the same payload. Effectively, we have two different objects with some shared parts:

If we change some properties, but not the author identifier, both book and newBook will still see the same author payload:

book['title'] = 'Decisive moments in History';
book['genre'] = 'Historical fiction';
book['author']['name'] = 'Stefan Zweig';
book['author']['born'] = '1881-11-28';

newBook === book; // Yields false, identifiers are still different.

// Value variables have diverged.
newBook['title'] === book['title']; // false
newBook['genre'] === book['genre']; // false

// The author identifier hasn't changed, its payload did.
newBook['author'] === book['author']; // true 
newBook['author']['name'] === book['author']['name']; // true 
newBook['author']['born'] === book['author']['born']; // true

For both objects to be completely separate entities, we need to dereference the author identifier in some of them. For example:

book['title'] = 'Red Star';
book['genre'] = 'Science fiction';
book['author'] = { // this assigns a new identifier and payload
    'name': 'Alexander Bogdanov',
    'born': '1873-08-22'
};

newBook === book; // Yields false, identifiers are still different.

// Reference identifier for author changed,
// book.author and newBook.author are different objects now.
newBook['author'] === book['author']; // false

Coda

Humans have superpowers when it comes to pattern matching, so we are biased towards using that superpower whenever we can. That may be the reason why the reference abstraction is sometimes confusing and why the behavior of shallow operations might seem inconvenient. At the end, we just want to manipulate some payload, why would do be interested in working with identifiers?

The thing to remember is that programming is a space-time bound activity: we want to work with potentially big data structures in a quick way, and without running out of memory. Achieving that goal require trade-offs, and one that most languages do is having fixed memory structures (for the value data types and reference identifiers) and dynamic memory structures (for the reference payload). This is an oversimplification, but I believe it helps us to understand the role of these abstractions. Having fast equality checks is a side-effect of comparing fixed memory structures, and we can write more memory efficient programs because the copy operation works with identifiers instead of the actual payload.

Working with abstractions is both a burden and a bless, and we need to understand them and learn how to use them to write code that is simple. In the next post, we shall talk about one of the tricks that we have: immutable data structures.

by Andrés at April 30, 2017 07:55 PM

Value and reference data types

There are a number of ways to classify data types in computer science. Of all of them, I find that the difference between value data types and reference data types is a useful classification for the daily life of application programmers – knowing the differences results in fewer bugs, less time to understand code, and more confidence to sleep well at night.

One way to think about them is by considering what is the content of the variable for each data type:

  • Value data types store their payload as the contents of the variable.
  • Reference data types store an identifier as the contents of the variable, and that identifier is a reference to the actual payload in an external structure.

Let’s say the FOO variable is a value data type and its payload is 42, while the BAR variable is a reference data type and has 42 as payload. A visual representation of this might look like:

We usually are interested in the payload of the variable (in green), not in their metadata (in red), yet fundamental operations of the languages we use every day have a different behavior depending on whether the variable content is a value or a reference.

For example, JavaScript has value and reference data types: the primitive data types are value data types – number, boolean, or string- and all the rest are reference data types – objects or arrays.

In terms of memory management, it is common for value data types and reference identifiers to be assigned a fixed amount of memory, and to live in a part of the memory called the stack. On the other hand, the reference payload usually doesn’t have a fixed amount of memory assigned so it can grow to any length, and tends to be stored in a different part of the memory sometimes called the heap. This is a generalization and an area that depends heavily on the language and its interpreters, but the reason this distinction exists in some manner is that we want fast and easy operations for an unlimited amount of data: operating with fixed memory variables is easier and faster, but dynamic memory allocation makes a better use of the limited space in memory – it’s a space/time tradeoff.

Boxing and unboxing

Languages with both value and reference data types, tend to provide ways to convert values into references, and vice-versa. This is called boxing and unboxing.

It is common that each value has a reference counterpart. For example, in JavaScript, there is the string primitive and the String object, the number primitive and the Number object, the boolean primitive and the Boolean object.

Also, languages tend to provide automatic boxing and unboxing in some situations. For example, JavaScript primitives don’t have methods or extra properties like the reference objects have; yet, they’ll be automatically boxed to the equivalent reference object when you’re trying to use one of its methods or properties.

This is a source of confusion, and the reason why:

var foo = 'meaning of life';
// Defines foo as a primitive string.
// To define it as the reference object String we'd do
// var foo = new String('meaning of life');

foo.toUpperCase();
// This yields 'MEANING OF LIFE'.
// Although foo is a primitive we can use the object methods
// thanks to the autoboxing.
// We could think of it as a type conversion in other languages: 
// ((String) foo).toUpperCase();

foo.constructor === String;
// This yields true.
// When we call a property or method belonging the object String,
// foo will automatically boxed, so it behaves like the object.

foo instanceof String; 
// This yields false.
// In this case foo is in its natural state (unboxed),
// so we are comparing the primitive to the reference.

typeof foo;
// This yields 'string'.
// In this case, foo is in its natural state (unboxed),
// so we are asking the system what kind of variable it is.

A note about references VS pointers

Some may argue that reference is how Object Oriented languages coined the old pointer data type. They are different things, though. The way I set them apart is by picturing what are the contents of the variables. References contain an identifier of the payload in an external structure; pointers index the content of another variable.

If, for example, a language would allow us to define a variable called Z as a pointer to X, visually it might look like this:

Although the difference between pointers and reference might be subtle, it has deep connotations when it comes to how operations work with them.

Coda

We, applications programmers, are mostly interested in the payload of the variables, but our programs consist of wrangling variables around with operations such as equality checks, copying, and passing arguments to other functions. These operations depend on the nature of the data they work with, so we are bound to deeply understand their inner workings. That will be the topic for the next post of the series.

by Andrés at April 30, 2017 09:48 AM

April 04, 2017

Andrés Maneiro

CSS Grid, from Galifornia

One of the bigger milestones in Q1 2017 was the landing of the new CSS Grid standard in all major browsers.

Personally, the cool thing about this is that support for webkit and blink (namely, safari and chrome browser) was led and developed by IGALIA with a team of people (Manuel, Javier, and Sergio) from Galicia. I love seeing how Baiona or A Coruña can be attractive places for high-tech talent. We are Galifornia!

by Andrés at April 04, 2017 04:25 PM

March 27, 2017

Andrés Maneiro

A FPJS week

Just this week, two of my colleagues at Automattic have written about Functional Programming concepts. Check Grzegorz’s A journey to Functional JavaScript and Miguel’s Functors and monads: an introduction.

by Andrés at March 27, 2017 09:23 PM

February 28, 2017

Andrés Maneiro

sum-csv

After the last blog categories reorganization, I realized that I talk less about what I do and more about what others do. That make sense, as this blog is part of my learning process and I’m always looking around to find ways to improve myself. Yet, I’d like to start writing more about the little things I do. Writing helps me to reflect upon the how, so eventually I’ll learn more about my thought processes. These are likely to be very small things.

sum-csv

sum-csv is a small utility I have built to help me to crunch some statistics I was working with. I had a complete dataset in a CSV file, but what I wanted was an ordered list of the number of times something happened.

Original CSV: What I wanted:

A data transformation

This is a small task – my old self whispered. Yet, instead of opening the editor and start coding right away, the first thing I did was drawing things. I am a visual person and drawing helps me to gain understanding. The algorithm I came up with was a succession of mathematical transformations: Which is to say:

  • transpose the original matrix
  • eliminate the rows I was not interested in
  • for each row, group all numerical values (from column 1 onwards) by adding them, to calculate the total
  • sort the rows by the total

Now, I was prepared to write some code. Amusingly, the gist of it is almost pure English:

d3-array.transpose( matrix ).filter( isWhitelisted ).map( format ).sort( byCount );

Reflection

Creating production-ready code took me four times the effort of devising an initial solution: finding good and tested libraries for some of the operations not built-in in the language such as reading a CSV into a matrix or transpose the matrix itself, creating the tests for being able to sleep well at night, distributing the code in a way which is findable (GitHub/npm) and usable by others/my future self, and, actually, writing the code.

I am not always able to write code as a series of mathematical transformations, but I find pleasure when I do: it is much easier to conceptually proof whether the code is correct. I also like how the code embodied some of the ideas I’m more interested in lately, such as how a better vocabulary helps you to make things simpler.

by Andrés at February 28, 2017 01:41 PM

February 19, 2017

Andrés Maneiro

A more expressive vocabulary for programming

map and friends are more precise, sophisticated ways to talk about consistent patterns in data manipulation. Using them over for is analogous to using the word “cake” instead of “the kind of food that you make by whipping egg whites and maybe adding sugar”.

Interestingly, you can eventually add new layers of category on top of established layers: just like saying that butter cakes constitute a specific family of cakes, one could say that pluck is a specialization of map.

Of vocabulary and contracts, Miguel Fonseca.

by Andrés at February 19, 2017 04:39 PM

February 10, 2017

Andrés Maneiro

Simple made easy

Precise words make communication more efficient. Arguably, software development is about managing conceptual complexity. Simple made easy, by Rich Hickey is a talk that tackles those two topics.

Two takeaways from this talk:

  • The differences between simple and easy.
    • Simplicity is an objective measure, and its units are the level of interleaving (of concepts). Simplicity should not be measured by the cardinality, the number of concepts/units.
    • Easiness is a subjective measure, and it is related to how familiar you are with some topic or your past experience.
  • We can make things simple with the tools we already have by favoring concepts that make things simpler to reason about, not quicker to write. He recommends:

See also:

by Andrés at February 10, 2017 06:00 AM

January 28, 2017

Andrés Maneiro

La La Land

Now, this is a musical that I like. Entertaining, moving, and complex.

I wouldn’t say musicals are my kind of films. My personal favorite is Sweeney Todd: The Demon Barber of Fleet Street, which is typical Burton. I didn’t like Les Misérables and haven’t watched Moulin Rouge. That’s my track record. Yet, this film is energizing, jazz everywhere, a colorful photography, with brilliant performances by Stone & Gosling.

At the core, I’d say this is a wonderful love story, with a positive and naïve message – just what we need right now. That’d be enough to recommend it. At the same time, it is not what would you expect from a Hollywood film: it is sad in many and fundamental ways, which makes the film a modern story about love, life, and personal growth. And has an epic soundtrack.

by Andrés at January 28, 2017 12:04 PM

January 26, 2017

Andrés Maneiro

To the hackers that grew older

The hacker ethic and the spirit of the information age, by Pekka Himanen, was one of these essays that had a big influence on my early yo. It resonated with how I felt about a lot of things: discovery & learning as a fundamental part of myself or work attached to meaning are two that I remember now. It was the first time I thought about how we divide life into chunks of time, more or less isolated.

One thing I didn’t realize at the time was who this essay was written for: a generation of individuals, with friends & family, but that see themselves as the unit of life in Earth. Given that the book defined the spirit that has driven one of the major social and cultural changes of the human race, this is no minor issue. As Jack Sparrow in the Pirates of the Caribbean, this generation had a mindset of fighting for their liberty against companies and governments. As individuals.

That attitude towards life, I believe, is one of the reasons why the products we create and consume are tailored for the individual and not for the communities: we have a personal music account, a personal pictures account, a personal mail account, etc. Solutions that take the group into account are rare and mostly exist for production-driven organizations (companies or volunteer based bodies), but less for leisure or consumption communities.

As we grew older and our communities became online, they asked us for help. So we create the “pay the service for user” feature as to pay for our relatives accounts, the family plans in our music and video stores, or the network setup for our publishing platform. These changes reflect a fundamental and more humane way to interact with others through technology. We are still in the early stages, but I expect this pattern to become stronger because one of the drivers for this to happen is that we have grown older in the same way that any other generation did in the past: realizing that we are weak as individuals, our natural state is to tribe within groups. Jack Sparrow struggled with this as well; he found out that the Black Pearl can be easily lost if you are on your own, and that you need a team if you want to navigate the ocean in freedom.

I, for one, look forward to a future more community-oriented. What specific shapes it will take is something that only we can invent; so let’s do it.

by Andrés at January 26, 2017 06:15 PM