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.

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.


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.

My office i4

I’ve been working from home for more than 3 years now, and my setup has gone through several iterations – the current one is i4.


After joining Automattic, I was encouraged to think about my office setup. The company sponsors the kind of high-quality office perks that you’ll expect in companies at this level, and I took that opportunity to upgrade my own in ways I had been already thinking about. The fact that you are not in their offices, but in your home adds a different feeling to it. Although I appreciate the company efforts and perks, I’d like to stay frugal within comfortable limits, so I didn’t get anything I wouldn’t buy with my own money. I think of my office setup as a gift for the elder me – I wish he’ll be proud of what his younger self is doing for him.

For i4, these are the new additions to my office:

HAG Capisco 8016 chair, which promotes and supports several seating positions.

DIY kit from Autonomous, to build my own height adjustable desktop so I could change between seating and standing positions.

We, humans, are not designed for seating. A lot has been said about the optimal seating position, but an idea that has gained recognition in ergonomics is that changing positions frequently may be the best long-term strategy.

For the past two months, I’ve been experimenting with that idea to learn what works better for me. I’ve used three main positions -traditional seating, saddle seating, and standing- and a lot of other crazy ones. What I’ve found out is that I change positions through the day as my body asks for it, but I mainly use the saddle position (most of the time, but especially when I need to write) and standing (for consuming information). The traditional seating feels a bit unnatural to me now, although it may be a side effect of using the Capisco which is more tailored for other postures. I also have a more traditional chair at home, but I rarely use it.

This is i4. This setup fits me so well that I cannot imagine what i5 will look like yet.


Como parte de mi refuerzo de aprendizaje del inglés, en los últimos meses he estado escribiendo varios textos: formales, informales, críticas, emails, académicos, informes, etc. Mi herramienta favorita actual para esos momentos es Grammarly. Las sugerencias van más allá de la mera corrección ortográfica y son contextuales al estilo de la redacción, te recomienda sinónimos a palabras usadas en exceso, se integra en mi flujo diario de trabajo digital (email, Simplenote, etc) y me envía informes semanales de los errores más habituales que cometo, en el navegador funciona como tesauro al seleccionar una palabra, etc ¿qué más se puede pedir?

Al poco de experimentar la versión gratuita me hice premium; fue un flechazo a primera vista. Aunque no lo he usado todavía me gusta además que, de manera natural, te invite a contactar con un humano para revisar textos que son devueltos en menos de media hora, 3h o un día. Han visto muy bien que la gente con la sensibilidad para usar este tipo de herramientas son presciptores naturales de un servicio de traducción humano.

Como todo buen software, tiene sus peculiaridades que hace que les tengas cariño: por ejemplo, las comas de Oxford han sido un descubrimiento y todavía estoy decidiendo de qué bando estoy. Por el momento, lo único que verdaderamente me molesta es que sólo pueda usarla con los textos de inglés. Me gustaría ver algo así para el español, gallego o portugués. ¿Una especie del famoso dardo en la palabra actualizado al siglo XXI?

Programación de interfaces basada en componentes

En mi travesía por aprender cómo mejorar lo que hice en mi último proyecto, estoy empezando a apreciar el encaje que tienen ideas como el immediate mode, las funciones puras y la inmutabilidad. Conceptos que transcienden modas y que, al entender su utilidad y trade-offs, se introducen en el conjunto de herramientas que tenemos a nuestra disposición, sea cual sea el contexto en que programamos.

Hay otro concepto al que recientemente le estoy prestando atención: programación de interfaces basada en componentes.

¿En qué consiste?

En la creación de elementos reutilizables que sean autosuficientes. Es decir, estables por sí mismos y que no dependan de estado global.

components_before components_after
Lo que hacemos ahora Lo que necesitamos hacer

Es muy interesante comparar cómo diversas herramientas proponen la creación (o no) de componentes. La selección tecnológica es, en sí mismo, un tema con muchos matices y tonalidades y existen diversas aproximaciones para comparar toolkits de programación. Algunas aportan algo, otras no y otras depende.

Por ejemplo, a la hora de comparar dos toolkits líderes de sus respectivos sectores como Wicket y React podríamos hacerlo de la siguientes maneras:

Sin embargo, si los comparamos en términos de cómo componen la interfaz, vemos que su aproximación es similar: proponen crear componentes que encapsulen conjuntamente HTML, CSS y JavaScript. ¿Cómo lo hacen? Tanto Wicket como React crean los componentes mediante un lenguaje de programación (Java/JavaScript) y no mediante un lenguaje de marcado (HTML).

  • Componente en Wicket. En Wicket, la unidad mínima de reutilización es el Panel, que consiste en varios archivos:, panel.html y opcionalmente otros de localización como
  • Componente en React. En React, el componente es un archivo JavaScript que devuelve código HTML. JSX es únicamente azúcar sintáctico que ayuda a que el código JavaScript sea más expresivo.

Esta aproximación los diferencia de otros toolkits como Angular, Polymer, JSP o Mako, que serían ejemplos de lo contrario: la composición de la interfaz se hace mediante un lenguaje de marcado -HTML- o derivativos que compilan a él.

¿Esto supone una mejora?

La respuesta rápida: sí, porque en un lenguaje de programación tienes a tu disposición 50 años de investigación en computer science, destilados con más o menos suerte. Hombros de gigantes sobre los que mirar más lejos.

La respuesta más elaborada: las interfaces son sistemas complejos, necesitamos subcomponentes para simplificar su creación y mantenimiento. Hay dos áreas donde un lenguaje de programación supera al de marcado para crear subcomponentes: encapsulación y expresividad.


La encapsulación consiste en la creación de elementos que podamos (re)usar sin la obligación de entender sus propiedades internas, ni de empezar todo desde cero cada vez. En un lenguaje de programación tenemos herramientas para encapsular elementos y funcionalidades como paquetes, módulos, clases, funciones, herencia, mixins, patrones de diseño, etc. Por el contrario, en un lenguaje de marcado como HTML, las opciones son inexistentes.

Iniciativas como WebComponents se han creado 20 años después del propio HTML. Son bienvenidas, pero no podemos obviar el elefante en la habitación: sólo nos ofrece la creación de paquetes, no todo lo demás. En Wicket y React los componentes son elementos que están programados en Java/JavaScript y, por lo tanto, podemos hacer con ellos lo que normalmente haríamos con cualquier otro trozo de código: herencia, composición, aplicar patrones de diseño, etc.


La expresividad consiste en la capacidad de programar los distintos matices que deseamos. En un lenguaje de programación tenemos a nuestra disposición mecanismos como tipos de datos, control de flujo, inversión de flujo, bucles, paso de mensajes, etc. HTML no tiene nada de esto.

Los toolkits que pretenden componer mediante un lenguaje de marcado -JSP en Java, Mako en python, etc- no poseen esa expresividad. Para solventarlo, tratan de integrar parte de ella en un lenguaje propio que compila a HTML: un sistema de plantillas. Un ejemplo típico que casi todos los sistemas de plantillas poseen son algunas construcciones para controles de flujo y bucles. Por ejemplo, en JSP:

<c:when test="${isThisVariableTrue}">
 <h1><fmt:message key="Title" /></h1>
 <c:if test="${isThisOtherVariableTrue}">
 <fmt:message key="showMessage" />
 <c:out value="${value}" />
 <c:if test="${isThisOtherSecondVariableTrue}">
 <fmt:message key="aDifferentMessage" />
 <c:out value="${aDifferentValue}" />

También necesitan crear mecanismos para pasar información del código a la plantilla y suelen ofrecer nuevos tags HTML para realizar acciones que HTML no permite. Interacciones que cualquier lenguaje de programación incluye por defecto pero que un sistema de plantillas integra con esfuerzo, limitaciones y a costa de aprender una nueva sintaxis no reutilizable en otros contextos. Para controlar la complejidad necesitamos más expresividad que la que nos aportan bucles y condicionales. Si lo único que puedes utilizar es un martillo, todos los problemas te parecerán clavos.


Sería simplista decir que Wicket y React se han convertido en líderes de sus respectivos sectores únicamente por la propuesta de creación de interfaces mediante componentes. Es, sin embargo, un fundamento que comparten y plausible para explicar por qué React tiene éxito y Polymer no: como la productividad aumenta al usar esta aproximación, se acaba extendiendo por microdecisiones de agentes interrelacionados que buscan su propio beneficio.

Al pivotar la construcción de componentes sobre un lenguaje de programación y no sobre un lenguaje de marcado tenemos a nuestra disposición todas las herramientas de encapsulación y expresividad disponibles en el lenguaje, lo que facilita domar la complejidad inherente a la creación de interfaces. El aumento de productividad es de órdenes de magnitud.

Para entender en toda su complejidad los efectos del cambio, conviene releer parábola de los relojeros.

Vagrant con Debian Jessie

Estos días he estado creando un entorno de desarrollo con vagrant para un nuevo proyecto que corre sobre Debian Jessie con tecnologías un poco antiguas.

Una de las bases de datos de ese proyecto tiene más de 12Gb de volcado, pero la máquina de debian viene con 10Gb para todo el sistema, así que me puse manos a la obra para redimensionar el espacio asignado en disco en la máquina virtual.

Esto resultó un proceso menos trivial de lo que yo me esperaba, asi que publico aquí unas notas sobre la configuración completa de la máquina para mi yo futuro y como ayuda para cualquiera al que le pueda ser útil.

Instalar el entorno base

Lo primero fue descargarme el binario de vagrant. No usé el propio que viene en los repos de mi sistema porque ellos no lo recomiendan. Luego, me puse a buscar una máquina Debian Jessie de 64 bits y me encontré con la “oficial“. Así que tener un Debian listo para poder jugar fue tan sencillo como:

vagrant init debian/jessie64

Configurar la zona horaria

Instalando ciertas librerías de i18n y l10n para el proyecto, me encontré con problemas porque la VM no tenía la zona horaria correcta, así que me instalé un plugin que me permite configurar la zona horaria de la VMs.

vagrant plugin install vagrant-timezone

En mi caso, he seteado la zona horaria para todas las máquinas, aunque se puede configurar de manera individualizada para cada una. He puesto mi zona horaria como “CET”. Aunque en la docu del proyecto dicen que es posible usar la variable :host para que la tome automáticamente del equipo, a mí no me funcionó.

Así que en mi ~/.vagrant.d/Vagrantfile he incluido:

Vagrant.configure("2") do |config|
  if Vagrant.has_plugin?("vagrant-timezone")
    config.timezone.value = "CET"

Aumentar el espacio en disco

En este apartado necesitamos hacer 2 cosas: primero, asignar más espacio a la máquina virtual; luego, configurar internamente las particiones para que reconozca ese espacio. Para la primera parte estuve viendo este tutorial. Para la segunda, lo hice de otra manera inspirado por éste.

Lo primero que hay que saber es que vagrant puede usar diferentes providers, que son los sistemas de máquinas virtuales. El que tenía yo era VirtualBox, así que al crear la base vagrant, lo que ocurre es que se guarda un archivo VDMK en el lugar donde mi VirtualBox almacena las VM. En mi caso, esto fue en un directorio tal que “~/VirtualBox VMS/debian-jessie/”, donde encontré el fichero debian-jessie.vdmk que era el que tenía que ampliar. Al parecer, esta funcionalidad sólo está disponibles en discos con formato VDI nativos, no con el VDMK, así que lo primero que tuve que hacer fue convertir el disco a VDI y luego ampliarlo a unos 52GB:

VBoxManage clonehd --format VDI debian-jessie.vmdk debian-jessie.vdi
VBoxManage modifyhd debian-jessie.vdi --resize 50000

A partir de aquí, la operación es la misma que cuando uno hace particiones, aunque yo no lo tenía muy fresco porque hacía años que no me enfrentaba a ello. Lo primero a recordar es que para manejar particiones, los discos tienen que estar desmontados. La idea es arrancar con una ISO como la de GParted y realizar las operaciones desde ese entorno. ¿Cómo hacer esto con una VM de VirtualBox? Pues:

  • añadiendo la ISO como CD al sistema de almacenamiento de la VM


  • configurando el arranque indicando que lo intente como CD primero y luego como disco


  • Et voilà!


Como mi VM no tenía sistema de ventanas, arranqué desde consola luego de aceptar los diversos menús que aparecen e hice las operaciones de edición de tabla de particiones con parted. En mi caso, tenía una partición primaria y una extendida con la SWAP en el disco /dev/sda, así que mi plan fue:

  • borrar la partición extendida
  • reclamar para la partición primaria todo el espacio de disco menos el último giga
  • extender el sistema de ficheros al tamaño total de la partición
  • añadir de nuevo la partición extendida con la SWAP

Que viene a ser lo siguiente:

parted /dev/sda
rm 2
resizepart 1 -1GB
e2fsck -f /dev/sda1
resize2fs -p /dev/sda1

Tuve problemas para crear la SWAP con parted, así que hice este último paso posteriormente con cfdisk ya desde vagrant, que es mucho más sencillo y visual.

Para finalizar, hay que recordar desmarcar el arranque por CD y eliminar la ISO de Gparted  del sistema de almacenamiento de la VM en VirtualBox. Entonces ya podemos arrancar nuestro vagrant de nuevo con normalidad y comprobar  que todo ha ido bien.

vagrant up
vagrant ssh
df -h

Estos días me he dado cuenta de que en 2015 he escrito sin proponérmelo un ensayo sobre la vida en una PYME de desarrollo de software del que me siento muy orgulloso. Está en las 7.400 palabras. Para convertirlo en librito convendría incluirle un glosario como anexo, para suplir la falta de enlaces complementarios. También hacer algo de trabajo para homogeneizar la lectura y eliminar la necesidad de los videos. ¿Algún consejo sobre edición, longitud, maquetación, las gestiones para conseguir el ISBN, etc?

Arquitecturas para la participación

Este post cierra la serie que inicié hace unos meses sobre desarrollo de software en una PYME. En el primer post, escribría sobre cómo seleccionar tecnología; en el segundo, sobre un mecanismo para objetivar el diseño y reducir los costes de producción. En este último escribiré sobre cómo la organización del código que escribes habilita relaciones con otros.

Programar es una comunicación entre personas

«Programs must be written for people to read, and only incidentally for machines to execute»

Esta frase extraída del prólogo del mítico SICP es una de las perlas que, entre los hackers, define el buen hacer de la profesión y que pone sobre la mesa toda una declaración de intenciones por parte de Abelson y Sussman: la programación es un nuevo medio de comunicación y expresión de ideas entre personas. De este enfoque se deriva que lo fundamental a la hora escribir programas de software es hacerlo de tal manera que nuestros limitados cerebros puedan navegar rápidamente entre los múltiples detalles, con sus distintos niveles de complejidad.

Al escribir código, un primer nivel de comunicación se daría entre programadores (con otros o con nosotros mismos dentro de unos meses). La buena o mala comunicación de las ideas a través del código tendría un impacto económico que se observaría en los tiempos necesarios para la adaptación, mantenimiento y aprendizaje de un programa. Entender un programa es un acto intelectual donde entra en juego la experiencia previa, la capacidad de relación de ideas y la compresión lectora, pero también la buena maña del que lo haya escrito para hacerlo de un modo inteligible. Al igual que un ensayo, un programa requiere cohesión interna y ritmo para ser entendible.

Un segundo nivel de comunicación se daría entre programadores y analistas del dominio y/o clientes. Ese tipo de conversaciones modela cómo se comporta el sistema y se transmiten al código en forma de estructuras de datos y algoritmos.  Un programa no es más que la declaración de un proceso que tiene entradas y salidas.

El hecho de que el software refleje estas relaciones sociales es conocido desde hace décadas y cristaliza en una de las más populares leyes de la programación, la ley de Conway:

«Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.»

Es decir, las conversaciones, grupos y jerarquías existentes en el proyecto se trasladarán al código de manera inevitable. La arquitectura reflejará tu estructura de comunicación y poder, determinando el tipo de relaciones que puedes tener con tu entorno. Toda una profecía ciberpunk.

Pero … ¿cómo habilita o dificulta relaciones la arquitectura?

Una PYME pequeña funciona como una comunidad: aunque existen roles y división de responsabilidades (diseñador, programador, administrador de sistemas, analista), hay mucho de pluriespecialismo. Además, por el propio tamaño de empresa, en muchas ocasiones existen proyectos que se realizan con otros equipos. Existen arquitecturas o maneras de modularizar el código que te permiten que esa división del trabajo sea más efectiva. Veamos algunos ejemplos:

Diseño orientado al dominio

La programación es fundamentalmente la transcripción de las conversaciones entre programadores y analistas. Es necesario tener un un lenguaje común y existir entendimiento entre ambos para que la cosa salga bien. Una de las prácticas que más me ha ayudado a organizar el código es el diseño orientado al dominio, es decir: organizar el código en torno a la interacción de las entidades que se definen en la conversación analista-programador. Aunque parezca una obviedad, no lo es, tiene sus trampas y se hace menos de lo que parece. El impacto de esta práctica deriva de cómo facilita las conversaciones y el entendimiento del programa.

Separación de API e interfaz

Esta técnica, conocida ya por los pioneros, ha retomado fuerza en la era de la web ubicua y la arquitectura REST. Con este mecanismo de modularización, el API define el acceso a datos y acciones que permiten usar el sistema. El interfaz es un mero usuario del API. Además de beneficios técnicos, esta frontera tiene beneficios sociales: facilita una división del trabajo en aspectos muy distintos de la aplicación, que requieren conocimientos, técnicas y herramientas diferentes. Esto permite que la colaboración diseñador-programador sea más fluida.

Hay 2 ejemplos que ilustran muy bien mi experiencia. En ciertos proyectos donde creamos formularios para la introducción de datos con una aplicación de escritorio, aplicar este principio nos ha permitido que nuestros analistas (repito: analistas, no programadores ni diseñadores) hayan diseñado por sí mismos los formularios que luego los programadores integran en la aplicación. En otros proyectos, hemos contratado a empresas para que nos ayudasen a crear un API mientras nosotros nos centrábamos en el diseño de la interfaz (y viceversa). Ambas situaciones serían muy complejas de delegar (o casi imposibles) si no hubiésemos hecho un uso intensivo de este principio a la hora de desarrollar el producto.

Creación de plugins o módulos

Otra manera muy evidente de crear espacios para la colaboración es permitir añadir nuevas funcionalidades a tu software mediante la creación de plugins o módulos. Este tipo de arquitectura minimiza la barrera de entrada para que nuevos colaboradores puedan ser productivos muy pronto, ya que no necesitan conocer todo el proyecto antes de incluir una funcionalidad, sino que les basta con conocer sólo lo que necesitan.

En nuestra experiencia colaborando con un proyecto empezamos por el desarrollo de pequeñas extensiones o plugins con funcionalidades limitadas. Pasados unos meses, nos sentimos cómodos y con conocimiento suficientes de ciertas partes internas de la aplicación como para modificarlas y enviar mejoras. Los primeros plugins fueron exploratorios, nos permitieron familiarizarnos con el código y el producto; una vez confiamos, nos lanzamos a cosas mayores. Fue precisamente un aspecto técnico (la creación de plugins) el que nos habilitó para iniciar una relación comercial con el proyecto: de no existir esa posibilidad al principio, se nos hubiese hecho muy difícil como PYME invertir todo el tiempo necesario para entender un proyecto tan grande.

Estos son algunos ejemplos de cómo la arquitectura habilita o impide relaciones, pero existen otros miles de pequeños detalles. La modularización del código es fractal, influye en todas las capas de la aplicación.


El programador es, principalmente, un organizador de ideas y un ensayista. Necesita cierta capacidad lógica para analizar y diseñar un sistema, pero también para organizarlo de manera que habilite buenas conversaciones y una división del trabajo efectiva. Necesita entender a las personas con las que trabaja.

Por ello no me parece casual que Kent Beck, el gran recuperador de ideas de nuestra generación, apuntase que uno de los factores con más impacto a la hora de ser un buen programador es la empatía.




¿Particionar o no particionar?

Hoy he tenido una de esas epifanías sobre una cosa que uno supone como básica, y que por eso mismo hacía más de 10 años que no pensaba sobre ella: ¿particionar el disco duro o no particionar?

Por qué dividir mi disco duro en particiones

La sabiduría convencional nos dice que un disco duro debe tener al menos la partición del sistema operativo y la de datos separadas. En otras como swap y temporal es más fácil encontrarse opiniones diversas. La sabiduría nos dice que:

  • tenerlas separadas hace que tengas un entorno más resilente, ya que si el sistema se estropea en una actualización o por un virus, puedes reinstalar uno nuevo sin tocar la partición de datos.
  • permite hacer cosas como tener varios sistemas instalados en distintas particiones compartiendo la de datos.
  • es una manera de asegurarte que el sistema operativo reside en los primeros sectores físicos del disco duro, donde el acceso a lectura es más rápido y, por lo tanto, tendrás mejor rendimiento.

Cuando me he puesto manos a la obra para llevar esa sabiduría a la práctica me han entrado unas dudas existenciales que describo a continuación.

Por qué tengo 1 única partición

Mi sistema inicial es un Ubuntu 14.04 con LVM con una única partición y encriptado. Mi plan inicial era usar LVM para crear una nueva partición para los datos dejando la del sistema operativo en unos 25Gb.

La razón principal de haber decidido usar LVM es que me permite redimensionar las particiones dinámicamente. Uno de los problemas que tuve con mi anterior portátil es que la partición del sistema operativo -donde también residían las bases de datos- llegó a su tope de capacidad en el peor momento: cuando necesité actualizar una BD a pocas semanas de una entrega. La BD en cuestión ocupaba unos 10Gb y necesitaba otros 5Gb de espacio que no tenía en el sistema, pero sí en la de datos. Como no podía redimensionar las particiones y ponerse a instalar las BD en la partición de datos llevaría un montón de tiempo, me puse como un loco a borrar kernels no usados, limpiar cachés, eliminar locales y desinstalar programas. Al final conseguí hacer sitio y salí del paso.

La primera lección aprendida es que es increíble la cantidad de basura que uno acumula. La segunda, que no me gustan las particiones.

Por eso, con la compra de mi nuevo equipo, me he estado replanteando si particionar o no y cuál es la mejor estrategia ahora, en 2015. Me dió por pensar sobre esto principalmente porque mi equipo incluye un disco SSD de 512Gb. A nivel práctico esto significa que:

  • un disco SSD, a diferencia de los de aguja, la velocidad de acceso a los distintos sectores físicos del disco es la misma, no depende de la posición que tengan. Es decir, tener el sistema operativo en la primera partición ya no es un diferencial para el rendimiento.
  • el espacio que tengo es justito para todo lo que quiero almacenar en él durante los siguientes años. Decidir cómo particionarlo supone un problema porque tengo que pensar cómo. Es cierto que el uso de LVM mitiga los efectos de esta decisión ya que podría cambiarlo en el futuro si el sistema crece más de lo previsto o la de datos se me quedase corta. Pero la verdad es que me da pereza pensar en esto de las particiones y tener que juguetear con ellas. Tampoco sé cómo puede resultar o si voy a tener problemas, no estoy experimentado con LVM, así que tengo una aproximación conservadora.
  • no necesito tener partición de datos compartida entre varios sistemas porque tengo sólo 1. Si necesitase un Windows para hablar con la administración, puedo virtualizarlo; de todos modos, en los últimos 6 años no recuerdo haberlo necesitado. Tampoco tengo planeado ponerme a probar nuevos sistemas Linux en paralelo.
  • tengo un sistema de backup que funciona y que permite recuperar datos entre ordenadores de un modo sencillo, con lo que usar las particiones como medida anti-pérdida de datos si hay un problema con el sistema no me aporta nada.

Todo esto me ha hecho reflexionar. Sabiendo, además, que si estoy equivocado y sufro un desastre o mal rendimiento siempre estaré a tiempo de jugar con LVM para organizarlo de otra manera, me he propuesto probar una nueva estrategia que parece más adecuada hoy en día. He decidido quedarme con una única partición.

De qué hablo cuando hablo de programar

A grandes rasgos, como programador, me puedo identificar con el trabajo que llevan a cabo un carpintero, escritor, modista o diseñador industrial. Todos ellos crean una estructura donde no la hay y le dan una forma agradable que la gente quiere usar. Lo que es completamente diferente con respecto a ellos son mis herramientas, las tareas diarias que realizo y el conocimiento específico que necesito para llevar a cabo mi trabajo. Cada oficio tiene sus cosas, aunque existan lecciones compartidas de unos a otros.

Las actividades del día a día

En mi empresa, creamos productos para organizaciones. Diseñamos herramientas para la toma de decisiones y compartir información. En ese contexto, mi día a día pivota en torno a 3 actividades diferenciadas:

  • entender los procesos del cliente, para lo que es necesario conocer el dominio en el que trabajas: ¿qué datos se recogen? ¿qué tareas necesitan resolver con esos datos? ¿cuáles son los roles de la gente que participa? El objetivo es entender qué hace el cliente para proponer mejores maneras de hacerlo con ayuda de la tecnología. La mejor herramienta que he encontrado en esta actividad es la conversación con el cliente y compañeros. Suelo también dibujar gráficos en papel. En digital menos, porque me lleva más tiempo y el gráfico no tiene vocación de permanencia, es meramente una herramienta para pensar y comunicar.
  • diseñar el producto, crear la herramienta que se adapte al proceso: ¿debemos usar una metáfora de mapa o de ruta? ¿Cómo componer la interfaz? ¿Cuál es el siguiente paso que un usuario debe hacer? En esta actividad el objetivo es determinar cómo un usuario interactúa con el producto y cómo eso da forma al proceso. Uso mucho el papel para comunicar el flujo o composición de las interfaces del producto a mis compañeros y clientes, pero coge relevancia lo digital para mostrar capturas de ejemplo de otros productos, realizar bocetos, etc. Y, por supuesto, un editor de texto (enfocado a programación) para implementar esas ideas. Hay mucho de ajuste en esta actividad, de probar si lo que pensaste inicialmente tiene sentido, de tratar de entender el espacio de la solución y decidirse por lo que mejor encaja. También tiene mucho de pegamento entre el análisis y la programación.
  • dotar de estructura al producto: ¿cómo diseñamos la base de datos? ¿y la arquitectura de mensajes? ¿es necesario ajustar la estructura o conviene generar deuda técnica? El objetivo de esta actividad es construir la solución. Esto es lo que convencionalmente se entiende como programación: escribir en un editor de texto lo que has aprendido del diseño y análisis. Mi principal herramienta es el editor, claro, y las interfaces que me ofrezcan las tecnologías que uso (base de datos, consola, etc). Suelo también garabatear mucho en papel para pensar. Mientras no se nos ocurra algo mejor, el papel me parece la tecnología definitiva para explorar ideas: flexible, rápida y desechable.

Estas actividades no son secuenciales (análisis > diseño > estructura) ni estancas, se retroalimentan y hay ciclos también en ellas.

Capacidades y equipo en contexto

Es importante que el equipo tenga todas estas capacidades, aunque cada persona tendrá fortalezas en un área u otra: alguien puede conocer muy bien el dominio porque ha trabajado en él, otros pueden ser mejores diseñando el producto porque conocen lo que la tecnología puede dar y tienen la empatía suficiente para entender el proceso, etc.

Hay días en que no sé cómo llamarme a mi mismo: ¿analista, diseñador de interacción, programador? Medio en broma, medio en serio, con los íntimos digo que soy fisico-químico de sistemas de control interactivos. La historia del término tiene su gracia y, en verdad, refleja muy bien lo que hago: estudiar las fuerzas y estados por los que un sistema puede pasar y dotarlo de interactividad. No deja de ser una boutade. Tampoco es que me importe no tener un nombre sino muchos dependiendo del contexto. Además, en el sector nadie sabe en realidad cómo llamarse a sí mismo: UX, UA, IxD, diseñador gráfico, programador, programador backend, arquitecto de software, testeador, programador frontend, growth engineer, etc. ¿De verdad necesitamos tantos nombres? Creo que existen porque señalizan cuál es el silo en que te ubicas en una organización, el departamento y nivel de jerarquía. Yo suelo utilizar sólo 3: analista, diseñador de interacción y programador. Creo que comunican las actividades principales y son ampliamente conocidos en el sector, no necesitan ser explicados. Lo que me gusta de ellos es que transmiten una sensación de amplitud, de recoger todo lo que una actividad puede ofrecer; señalan a mi interlocutor que estoy capacitado para hablar con él (que es lo que me interesa de un nombre) evitando el efecto: ah, es que tú sólo haces UX, no te veo como un igual.

Por otro lado, en cuanto a la secuencialidad de las fases habría mucho que decir, pero tiende a ser cierto que por la propia naturaleza del trabajo los ciclos iniciales del proyecto contienen más análisis y los finales menos, por ejemplo. Además, al estudiar lo que hacen otros, me he dado cuenta de que el día a día de los programadores es muy distinto dependiendo cuál sea tu producto y sector: ¿creas productos para organizaciones? ¿juegos? ¿herramientas de publicación? ¿películas? ¿música? No me refiero únicamente a conocimiento especializado (cómo dibujar un mapa, cómo renderizar un personaje en un juego, etc), sino a cosas más amplias que impactan en cómo enfocas tus actividades diarias. Por ejemplo, una arquitectura específica puede tener mucho sentido en un sector pero no en otro simplemente por cosas como cuáles son los canales de distribución de tu producto.

Crear productos, de principio a fin

Cuando hablo de programar, hablo de todo esto. De la actividad que me permite crear productos de principio a fin.

Por desgracia, creo que todavía hoy la visión hegemónica de un programador baila entre la superespecialización de las factorías de software y el vaquero indomable de las startups que puede hacer cualquier cosa desde la soledad de una cafetería. La primera transmite que no eres nadie si no eres el jefe de todos esos compartimentos estancos; la segunda, que no necesitas compañeros y pares para ser mejor y llevar tu proyecto a cabo. Necesitamos otro relato. Necesitamos una visión equilibrada de la programación como trabajo en equipo y carrera a largo plazo.

No me frusto tampoco con esta visión descompensada pues no conviene olvidar que la nuestra es una industria muy joven. Empezamos, ahora, a tener a nuestros propios viejos programadores. Quizás entenderemos de verdad lo que significa programar cuando el tiempo pase y las historias que cuentan los mayores se transmitan entre generaciones. Por eso admiro a personas como Ward Cunningham y Kent Beck que, a pesar de formar parte de los pioneros de la industria, siguen en primera línea a sus 60 años, haciendo lo que se les da bien: crear productos de principio a fin.