2017/05/30

Simplificando el desarrollo

Webpack, Babel, TypeScript, Gulp, Sass, Stylus, Pug, son algunas de las cosas que se ven en el desarrollo frontend hoy en día.

Pug (Jade) permite escribir una especie de html sin brackets, que se ve más limpio y legible, y luego es traducido a html.

Sass y Stylus hacen algo parecido con el css.

CoffeeScript lo hacía con el javascript. Pero parece que va cayendo en deshuso, frente a TypeScript y ES6.

Pug te permite escribir html de manera más clara y sencilla y está bien.

Styles te permite escribir css de manera más clara y sencilla y está bien.

CofeeScript te permite escribir javascript de manera más clara y sencilla y también está bien.

Está bien que produzcas html, css o javascript de la manera que te resulte más cómoda y fácil de mantener.

Sospecho que muchos programadores provenientes de otras canteras, resintieron tanto las incomodidades de los brackets, y puntos y comas, que usaron sus potentes habilidades para construir herramientas que les recordaran sus lenguajes preferidos.

Además, herramientas como Gulp, Babel y Webpack pueden automatizar el proceso de traducción.

Pero entonces comenzó a complicarse la cosa.

Si miramos las cosas desde una perspectiva más amplia, lo que ha sucedido es que se ha creado una capa adicional entre el programador y el código. Una capa de pre procesado.

¿Qué pasa cualdo alguien más quiere participar en el desarrollo de un proyecto como este? Esta persona conoce todo lo necesario para actuar en la capa del código html/css/javascript.

-- Pero no, un momento, no puedes hacer eso.

-- ¿Por qué no?

-- Porque yo escribo en mi hermoso pug/stylus/coffeescript para producir ese horrible html/css/javascript y no se me ocurre cómo hacerlo en sentido inverso para que tus cambios actualicen los míos.

-- Bueno, me voy a ayudar a otro proyecto.

¿Y para qué publicas un proyecto en GitHub, como open source, y en inglés, si no es para facilitar que otras personas puedan colaborar contigo para evolucionar una idea que te apasiona?

Entonces, no tiene mucho sentido restringir esa facilidad con herramientas que no todo el mundo quiere usar, aunque tú las adores.

Lo que debería haber en tu proyecto compartido es cosas que sean fáciles de compartir: html, css y javascript. Producidos con las herramientas que gustes; pug, sublime, atom, notepad o dreamweaver. Pero, así como no puedes exigir que alguien use dreamweaver, sublime o atom para poder participar en tu proyecto open source, tampoco deberías exigir que usen tal o cual pre procesador.

El efecto de encarecer las cosas

Imagina que tienes una cita con una chica que te gusta. Por alguna razón, lo comentas en casa, a tu abuela. Ella se opone, por varias razones importantes:

-- No sabe cocinar; ¿cómo te va a atender después?

-- Pero, abue...

-- Además es demasiado flaca; con esas caderas sufrirá mucho para tener hijos

-- ¡Es sólo una cita, abuela!

Si sales con alguien pensando en si se casarán, ves todo con otros ojos. Hasta los defectos más pequeños se convierten en gigantes cuando los proyectas sobre la pantalla de un futuro de deberás soportar todos los días.

La abuela piensa así porque en su época, donde vivía, una cita era algo muy importante y costosa, pagada con el dinero que la familia ahorraba con esfuerzo, así que no podías estar en plan de "salir para ir conociéndonos".


Algo así aparece en el proceso de desarrollo cuando un proceso es caro de hacer.

Antes, con un simple editor de texto y el navegador, podías moverte rápidamente entre el html y los resultados, probando diversas librerías, plugins, etc, con mucha agilidad. Como ir en bicicleta.

Ahora, es un camión. Si quieres probar y jugar con una librería, un plugin, etc. ya no puedes hacerlo directamente, como antes. Debes traducir mentalmente el html de la documentación del plugin, y calcular tu código para que produzca el html que se requiere. Son dos lenguajes en la cabeza y un paso extra para depurar. Es como caminar con ayuda de un espejo.

Así que ya no tienes citas por diversión. Todo se vuelve más serio.

Cómo el builder establece de antemano dónde irá cada cosa hasta el fin de los tiempos, con ese mal ejemplo la gente empieza a sentirse presionada a hacer el código limpio directamente. De pronto, la elaboración progresiva de soluciones, la refactorización y la restructuración de directorios quedan al margen de la ley, porque son más caros.

Además, la gente empieza a usar Gulp y Webpack como herramientas con las que pueden instaurar un régimen de código opinionado ("así es cómo se deben hacer las cosas, tontos").

Y todo empezó con el afán de trabajar más cómodos. De buenas intenciones está hecho el camino al infierno... como reza el dicho.


Creo que es importante mantener un punto de vista amplio acerca de las cosas que hacemos en desarrollo. Del mismo modo que un máximo en cada división de una empresa no garantiza un máximo de la empresa en conjunto, una mejora en un aspecto individual no garantiza que todo el proceso de desarrollo será mejor. Los máximos locales no garantizan máximos globales. Producir html rápidamente no garantiza que mantenerlo será igual de rápido. Es mejor un enfoque holístico.

Creo que una buena referencia para tomar decisiones es considerar el número de pasos, capas y herramientas que significa corregir un bug, o introducir un cambio. Un problema se puede resolver de muchas maneras. Es posible usar un cañón para matar moscas. Pero es una buena idea empezar con las soluciones más simples primero.

Y, construir las cosas de modo que no obstruya los siguientes pasos. Evitar los compromisos innecesarios y mantener el camino libre y fresco para avanzar progresivamente. Ya que el viaje es el camino.

2017/05/24

Emponderar a los usuarios

Cuando estaba en la universidad, retomé el contacto con las computadoras después de un largo tiempo y conocí el DOS de Microsoft.

Estaba frente a una pantalla negra con el prompt C:\> esperando a que ingresara algo. Cuando lo hacía, me respondía.

Me sentía fascinado.

Aprendí a usar casi todos los comandos de la consola, y a programar nuevos comandos.

  • En la consola command, se pueden ejecutar comandos cuyas salidas pueden ser entradas de otros comandos.
  • Se pueden crear fácilmente nuevos comandos batch ejecutables desde la consola. Ya que los batch son archivos de texto simple y la consola tiene algunos comandos para generarlos.
  • Un comando podría generar nuevos comandos dinámicamente. Es decir, un batch se podría generar dentro de la rutina de un comando y ser ejecutado luego dentro del mismo comando.
  • Los programas de pantalla completa, aunque impresionantes, rompen el esquema de reutilización de comandos al apropiarse de toda la interfaz.
Más tardee, conocí Linux y la consola de comandos bash, donde se pueden observar puntos similares.


En la interfaz gráfica de Windows, en cambio:
  • En el escritorio, se pueden ejecutar aplicaciones, pero estas ejecuciones son aisladas y no se puede realizar ejecuciones compuestas donde la salida de una aplicación sea la entrada de otra, dinámicamente.
  • No hay herramientas para construir fácilmente nuevos programas desde el escritorio. Las aplicaciones no son interpretadas, sino ejecutadas desde un binario, y construir ese binario requiere conocimientos y herramientas especializadas.
  • No hay una forma sencilla de construir aplicaciones que puedan generar otras aplicaciones dinámicamente, dentro de su ejecución. No es sencillo construir compiladores.
  • La reutilización de las características de una aplicación es difícil. Cada característica está pegada a la aplicación. Cada mejora de características requiere una nueva versión realizada principalmente por quienes la programaron.
Algo parecido se puede decir de las interfaces gráficas de Linux (Gnome) y de la Mac (OSX), que vine a conocer luego.


En la interfaz gráfica de la Web, en el browser, se muestra una aplicación:
  • Cómo hacer que la aplicación sea un entorno donde se puedan ejecutar componentes que puedan componerse para formar nuevos componentes?
  • Cómo hacer que sea fácil crear componentes con los componentes presentes en el entorno?
  • Cómo hacer que un componente pueda generar dinámicamente otros componentes dentro de su ejecución?
  • Cómo prevenir que un componente pueda apropiarse de la interfaz?

Me parece distinguir que ese conjunto de características facilita que un sistema pueda ser extendido con la participación de sus usuarios.

El conjunto de comandos DOS y bash, puede ser fácilmente extendido por sus usuarios. Habrá programadores capaces de hacer nuevos binarios, pero la capacidad de hacer scripts, batch o bash, está disponibles de inmediato.

El conjunto de aplicaciones en Windows (o Gnome, o OSX) no puede ser fácilmente extendido por sus usuarios. Sólo puede serlo a través de programadores capaces de hacer nuevos binarios.

Uno se puede preguntar si esta limitación es puesta a propósito.

Al limitar que los usuarios puedan extender el sistema que usan, las empresas proveedoras de software se aseguran el papel de intermediarios, entre los usuarios y las soluciones que los usuarios requieren.

Y es conocido en el comercio que el intermediario siempre gana.

Así que me parece que la cuestión de limitar la extensibilidad del sistema por parte de los usuarios puede ser algo diseñado.

Sin embargo, ¿por qué ocurre también en la interfaz gráfica de Linux?. Siendo la comunidad Linux un fuerte representante del movimiento de software libre (promotor de dar a la gente la libertad de usar el software como quiera), esperaría que hubieran escritorios que permitieran componer aplicaciones visualmente, siguiendo la filosofía de composición de comandos que está presente en la consola.

Quizás sea que están distraidos por las complejidades de otros problemas.


Pero me parece que resolver esta situación sería muy interesante. Un escritorio así, emponderaría a los usuarios para crear cosas, sus propias cosas, y compartirlas en comunidad.

A mediados de los 80, Hypercard, de Bill Atkinson, fue una aplicación gráfica que facilitaba a los usuarios la creación de sus propias soluciones y a compartirlas. Atkinson insistió en que se distribuyera de modo gratuito Apple insistió en encontrarle alguna manera de obtener ganancias. Finalmente, el desarrollo de Hypercard se estancó y Steve Jobs canceló su desarrollo, cuando volvió a mediados de los 90.

Aunque hoy hay fans que recuerdan el legado de Hypercard, me parece que se enfocan más en las cualidades técnicas (como la interfaz gráfica, que sirvió de inspiración a VisualBasic y otras herramientas), que en la cualidad social de emponderar a los usuarios para hacer sus propias soluciones.


Quizás sea posible implementar la idea en la web, usando componentes que puedan componerse para formar nuevos componentes, tanto a mano como dinámicamente.

Quizás React pueda ser una buena opción para eso. (Sin embargo, la forma en que se suele usar React, con Webpack para generar compilados, parece una especie de barrera. A veces parece como si las compilaciones fueran una forma de dejar fuera a los demás y ponerse uno como intermediario.)

2017/05/18

Programando tu propia comida

En un inicio, si alguien tenía una computadora era para programar algo que solucionara su problema en particular.

Habían recetas de soluciones que se compartían entre la gente que programaba.

Cuando mucha gente trabajaba sobre cierto programa, se iban estableciendo costumbres y estándares para facilitar la comunicación entre las personas.

Nuevas formas de programar fueron emergiendo para facilitar que más gente pudiera programar soluciones más complejas con más facilidad.

Poco a poco, ya no fue necesario conocer de electrónica, ni de cuestiones específicas del hardware de la computadora. Luego, no fue necesario usar siglas mnemotécnicas sino expresiones muy parecidas al inglés.

Entonces, en algún momento, alguien notó que una computadora podía tener usuarios que no programaran, sino que usaran interfaces simples para realizar acciones sin componer nuevos programas.

Más tarde, alguien más notó que esos programas con interfaces simples podrían ser vendidos. Y luego, que para asegurar la dependencia podían limitar la posibilidad de hacer nuevos programas.

El software comercial permite resolver muchos problemas. Pero cada nueva característica, cada mejora, depende de que el proveedor del programa lo incorpore en la siguiente versión, por la que tendremos que pagar.

El software libre aparece como una respuesta a esta situación. Al obligar a que el código fuente de cada programa este disponible y cada usuario tenga la libertad de modificarlo y redustribuirlo, ayudó a que quienes tuvieran el conocimiento técnico suficiente pudieran ayudar con la evolución del software.

Sin embargo, la barrera es muy alta. El software actual, comercial o libre, sigue el esquema de aplicaciones paquete de muy difícil manufactura. Se necesita avanzados conocimientos de programación para lograr algo así. Además, son productos de uso final que difícilmente se comunican entre sí y que prácticamente no se pueden desagregar ni componer para formar nuevas soluciones.

A fines de los '80, Apple, una empresa con el estilo de proveer productos de cómputo que los usuarios no pueden alterar ni extender, tuvo un producto llamado Hypercard, creado por Bill Atkinson, que permitía a los usuarios componer visualmente secuencias de acciones y expresar los detalles en el lenguaje Hypertalk, muy simple y fácil de leer y escribir. Es decir, creó un entorno que permitía que los usuarios finales pudieran hacer programas para solucionar sus problemas particulares. Como antes, apareció una comunidad que compartía sus recetas.

Por alguna razón, está iniciativa no recibió el apoyo adecuado. Las siguientes versiones del producto limitaban las capacidades de creación y buscaba colocar a Apple como intermediario, otra vez, de las soluciones que la comunidad de usuarios era capaz de realizar por si misma.

Cuando Steve Jobs (precisamente, uno de los primeros en notar cómo hacer negocios con el software) regresó a la dirección, uno de los proyectos que canceló fue el de Hypercard.

Cosas como Hypercard necesitan una comunidad de usuarios emponderados, capaces de crear soluciones cuya explotación no puedes controlar.

Hay proyectos que tomaron la posta de ciertas ideas de Hypercard. Como VisualBasic, con su interfaz visual. Pero parece que siempre orientados a programadores, no a un público laico.

Parece más probable que una iniciativa que herede el espíritu de Hypercard provenga del software libre que del software comercial.


Hoy, el software comercial ha logrado que prácticamente cada persona cuente con una computadora en la mano. Gracias a ella puede consumir los productos que les preparan. La barrera técnica para preparar esos productos es tan alta y los consumidores tan ávidos de soluciones que se ha vuelto notoria la falta de capacidad para cubrir esa demanda.

Es como si hubiera pocos restaurantes para muchos comensales.

La comunidad de programadores, que son como los cocineros, ha optado por buscar modos de mejorar su respuesta, optimizando la forma en que programan, automatizando procesos, etc.

Los gobiernos están promoviendo la enseñanza de programación para aumentar el número de programadores. Es como aumentar el número de chefs y restaurantes.

Y sigue el aumento de gente con nuevas ideas de aplicaciones. Son como comensales con nuevas ideas de platillos, buscando chefs que los entiendan, o incluso financiandose un pequeño restaurante para poder ofrecer al mundo ese platillo que imaginan.

Ellos necesitan programadores porque, a diferencia del mundo de los comensales que también pueden cocinar, en el mundo de las aplicaciones es tan alta la valla de entrada que es como si sólo existieran cocinas industriales y ollas gigantes y sólo ingredientes al por mayor. La poca gente que puede preparar sus alimentos son los que saben hacer sus propias hogueras y utensilios para cocinar. O las que comen sushi.

¿Qué podemos hacer en este escenario?

Además de los cocineros tratando de cocinar más rápido y de los gobiernos tratando de hacer más cocineros, hay otras iniciativas en curso.

Hay el equivalente a cocinas comunitarias, donde cocineros pueden alquilar un espacio.

Hay el equivalente a máquinas expendedoras, donde se pueden conseguir golosinas, cafe o sandwich. Administradores de contenido que te permiten combinar algunas opciones para armar un refrigerio.

Los avances en inteligencia artificial están permitiendo máquinas expendedoras capaces de preparar algunas comidas básicas. Es decir, acciones simples como encender las luces, monitorear el refrigerador, sintonizar la tv o hacer consultas en Google, obedeciendo comandos en el lenguaje del usuario.


Quizás a estas alturas ya hayas notado qué ha pasado y qué se podría hacer.

Es como si se hubiera convencido a todo el mundo que la única forma de comer decentemente es en un restaurante o comprando algo hecho por un cocinero profesional.

¿Qué vendría a ser Hypercard? Quizás algo así como una máquina expendedora pero no de comida, sino de pequeños utensilios para cocinar, o de partes modulares para armar esos utensilios, y de ingredientes al por menor.

El símil deja ver que así como todo el mundo puede cocinar aprendiendo unas pautas básicas, la programación podría ser algo más asequible también.

El poder de la inteligencia artificial también podría ayudar, si se le permitiera disgregar soluciones existentes y componerlas en nuevas soluciones y a la comunidad de usuarios compartirlas libremente.

La clave es una libertad efectiva para componer nuevos programas a partir de otros, y de poder compartirlos libremente.

Si no puedes cocinar, dependes de alguien más para algo que debería ser una libertad básica.

No digo que no haya restaurantes. Tampoco que atendamos restaurantes usando expendedoras. Digo que no debe ser prohibitivo cocinar uno mismo.

Cada persona debe tener la libertad, y el poder, de resolver sus propios problemas, sin intermediarios.

Programar debe ser una actividad al alcance de cualquier persona.

Porque cada cambio en el mundo nace de una persona, no de un rebaño.

Y el mundo está necesitando cambios significativos más rápido de lo que se le puede proveer.

Necesitamos herramientas de programación más asequibles. El equivalente a una cocina de hogar o una hornilla. Ollas pequeñas y personales. Ingredientes al por menor. Recetas familiares.

Necesitamos liberar la creatividad de las personas para descubrir nuevas experiencias y soluciones... nuevos sabores.

2017/05/10

Solución al problema del high DPI con Freeplane en Windows 10

En una computadora corriendo Windows 10 con pantalla con high DPI (de muy alta resolución, por ejemplo, 4K), algunos programas (como Photoshop CS6, GimpShop, Inkscape y Freeplane), muestran los menús o botones de un tamaño diminuto, casi ilegible.

Freeplane es una de las aplicaciones que muestra botones diminutos
en panallas con high HDPI


Para Inkscape funcionó bien el truco de declarar un .manifest: http://www.danantonielli.com/adobe-app-scaling-on-high-dpi-displays-fix/

Quizás porque Freeplane es un programa que corre bajo Java, el truco del manifest no funcionaba. Finalmente, pude solucionarlo entrando a las propiedades del ejecutable freeplane.exe: Compatibility, Override high DPI scalaing behavior. Scaling performing by: System


Propiedades de freeplane.exe
Luego del cambio, los botones aparecen con un tamaño adecuado:

Luego de indicar que el escalamiento high DPI será
manejado por el sistema

Sabiendo esto, comprobé con Inkscape (sin ningun .manifest) que también funcionaba. Así, este método es una alternativa más simple al de ener que crear el .manifest.