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.

2017/04/30

Tú debes poder programar

Porque los programas están construyendo tu vida


En la Edad Media, la gente recurría a escribientes para que les redactara sus escritos.

Cosas como Actas, Títulos, Leyes, Poemas, Cartas, Cosas Importantes.

Mientras la demanda estuvo limitada a religiosos y nobles, los escribientes fueron suficientes.

Cuando la gente aprendió a usar los escritos en su vida, la demanda aumentó, y los escribientes que había no eran suficientemente numerosos ni suficientemente rápidos para redactar lo que les requerían.

En el mundo actual, la gente recurre a los programadores para que les haga sus programas.

Mientras la demanda estuvo limitada al gobierno y las empresas, los programadores fueron suficientes.

Cuando el Internet acelera a que la gente use los programas en su vida, la demanda de programadores aumentó y ya estamos notando que no son lo suficientemente numerosos ni lo suficientemente rápidos para hacer los programas que queremos.

(Sí, quizás es mejor dar un paso atrás e imaginar que no eres un programador para tener una perspectiva más amplia de estas cosas).

¿Qué está pasando ahora?

Los escribientes están mejorando sus técnicas para crear escritos.

Como ha quedado patente, casi nunca el cliente sabe cuál es exactamente el mensaje que quiere que se escriba, eso se va descubriendo en el camino, iterativamente, de manera ágil.

En realidad, hay un conjunto de técnicas de redacción defensiva y buenas prácticas para facilitar cambiar las cosas si el cliente de pronto cambia de opinión sobre algo. (Quizás ya no quiera mandar el poema a Rosa sino a María. Quizás no quiere un tono tan formal, etc.)

Por supuesto está la cuestión de la calidad. Es bien sabido que es mejor recibido un mensaje bien presentado, así que elegimos el mejor pergamino y las mejores tintas. También cuidamos el estilo de la letra y el arte de las iluminaciones que van alrededor.

Cada cierto tiempo se prepara un pergamino con la caligrafía y las iluminaciones propias del final, para que el cliente vaya evaluando el resultado. Esto es gracias a que los avances tecnológicos han permitido abaratar enormemente el costo de los pergaminos y la tinta.

Los escribientes más vanguardistas han optado por indagar en el destinatario (Rosa o María) para estar seguros que el mensaje será el que les gustaría escuchar en primer lugar. El tipo de letra y papel o pergamino que les guste, los colores, etc. y así tener una mejor experiencia de usuario.

Pero la demanda sube y sube y los programadores escribientes no se dan a basto.

Muchos están tratando de automatizar algunas cosas, creando formatos con espacios en blanco donde pueda ir el mensaje customizado.

Hay quienes invierten en mecanismos de relojería capaces de tomar las plumas y la tinta y reproducir la caligrafía de los escribientes de manera asombrosa, pero aún es una solución demasiado sofisticada y cara.

También hay por ahí un tipo proponiendo el uso de unos moldes de letras y tipos movibles.


Bueno, como habrás notado, estamos en el siglo XXI con un patrón de problema del siglo XV.

Sabemos cómo sigue la historia.

Sí, la imprenta fue algo muy importante que ayudó a difundir más fácilmente los textos. Pero lo que realmente cambió al mundo fue que la gente estaba usando textos para cambiar su vida.

El conjunto papel y lápiz, pergamino y tinta fue potenciado por la imprenta.

Hoy hay sistemas equivalentes a pergaminos caligrafiados. Con escribientes defendiendo con su corazón por qué usar ese tipo de pergamino y tinta, y ese tipo de caligrafía. Casas de escribientes tratando de tener a los mejores o formarlos lo más pronto posible, porque el mercado no espera.

Curiosamente, nadie parece preocuparse por dar a la gente papel y lápiz que pueda usar sin necesidad de ser educado en las artes de escribiente.

Porque eso es lo que necesitamos ahora. Una herramienta que permita programar a cualquier persona, sin necesidad de ser educada en las artes, o la profesión, de la programación.

Sí, Internet es algo muy importante que ayuda a difundir más fácilmente el conocimiento y a comunicarnos. Pero lo que realmente está cambiando al mundo es que la gente está usando a los programas para cambiar su vida.

Necesitamos dejar de depender de escribientes que lo hagan por nosotros. Necesitamos nuestro propio papel y lápiz para programar nosotros mismos el mundo que imaginamos.

Escribir no es solo un arte o una profesión; es un derecho. Igual programar.



2017/04/04

Termux para programar en un android

Termux (https://termux.com) es una aplicacion que emula una consola Linux en el Android.

Una vez instalada, se puede instalar ssh:

$ apt update
$ apt install openssh
$ ssh myuser@myserver.com

Una vez conectado a un servidor, se puede usar los comandos Linux de ese servidor.

Yo probe entrar a un servidor en Digital Ocean, crear un proyecto React, usar el editor vim, ejecutar el proyecto y ver el resultado en una pagina web, abierta en Chrome en el mismo celular (Android reconocio alternar  entre aplicaciones con Alt+Tab).

Si ademas cuentas con un teclado conectado via bluetooth, la sensacion puede ser como la de tener una mini laptop con touchscreen ^^

Tip:
En Termux, para abrir mas de una consola, arrastrar el dedo desde afuera del borde izquierdo hacia adentro.

2017/02/22

Imprimir formas en consola

En un aviso de Workana encontré un pedido como este:

Escribir un programa que pregunte al usuario elegir una forma para dibujar en la pantalla.
La forma puede ser: Circle, X, Box y un Box con una X.
También el usuario indica cuántas filas se usarán para dibujar la forma.
La forma debe ser dibujada con asteriscos (*).

Me parece que se trata de un programa para correr en consola.

En mi caso, me pareció más práctico intentarlo con php.

shapes.php

<?php
do {
 print "1. Circle\n";
 print "2. X\n";
 print "3. Box\n";
 print "4. XBox\n";
 fscanf(STDIN, "%d\n", $option);
} while (!$option);

do {
 print "Number of rows: ";
 fscanf(STDIN, "%d\n", $rows);
} while (!$rows);

for ($i=0; $i<$rows; $i++) {
 for ($j=0; $j<$rows; $j++) {
  $print_dot = false;
  switch ($option) {
   case 1:
    $print_dot = is_circle($i, $j, $rows);
    break;
   case 2:
    $print_dot = is_x($i, $j, $rows);
    
    break;
   case 3:
    $print_dot = is_box($i, $j, $rows);
    break;
   case 4:
    $print_dot = is_xbox($i, $j, $rows);
    break;
  }
  if ($print_dot) {
   print "*";
  } else {
   print " ";
  }
 }
 print "\n";
}

function is_circle($i, $j, $rows) {
 $r = $rows - 1;
 $d = pow(($i - $r/2), 2) + pow(($j - $r/2), 2) - pow($r/2, 2);
 return abs($d) <= $rows/3;
}

function is_x($i, $j, $rows) {
 return ($i == $j) || ($j == ($rows-1) - $i);
}

function is_box($i, $j, $rows) {
 return ($i == 0) || ($j == 0) || ($i == $rows-1) || ($j == $rows-1);
}

function is_xbox($i, $j, $rows) {
 return is_x($i, $j, $rows) || is_box($i, $j, $rows);
}


El ejercicio me pareció interesante para ver una manera simple de tomar una entrada desde consola. Y cuando llegué a la parte de impresión de formas me pareció más interesante. En particular la del círculo, que dejé para el final.

Algunos conceptos de coordenadas y geometría analítica me ayudaron a completar el programa.

El problema del círculo es, en el fondo, cómo imprimir una imagen en un medio de baja resolución.

Esta es la forma en que se me ocurrió resolverlo, con una especie de detección de borde seteado a $rows/3, al tanteo (para que se vea bien el círculo en 4, 8 o 16 filas).

Seguramente hay muchas maneras de resolverlo. ¿Cómo lo harías tú?


2017/02/17

Invertir una cadena con javascript

¿Cómo harías una función que invirtiera una cadena dada?
Es decir que f("abcdef") sea "fedcba".


Yo pienso que no hay una "forma correcta" de resolverlo. Simplemente hay formas, y cualquiera que se te ocurra y haga el trabajo está bien.

De todas esas formas habrá algunas que logran hacerlo con menos variables o menos código, o usando técnicas esotéricas. Formas optimizadas.

Hay programadores que se familiarizan con esas técnicas optimizadas y las aplican luego directamente en los siguiente problemas que enfrentan. Puede ser impresionante, como cuando ves a un mago sacando del sombrero cosas que no creías posible. Igual que con los magos, se requiere de práctica y ensayo para lograr esas cosas. Pero, igual que con los magos, no significa que esa es la forma en que todo el mundo debería pretender hacer las cosas.

La optimización prematura es la raíz del mal, es la advertencia de Knuth, comprobada una y otra vez en la experiencia de los programadores. Está bien optimizar, por supuesto, pero tiene su momento, y definitivamente no es al inicio.

En la vida real, la solución de los problemas se produce por tanteo. Como en un cuarto oscuro, estiras los brazos y tientas. Tocas algo una y otra vez, formándote una idea de lo que hay. Así, descubres la puerta hacia la solución. Una vez que la descubriste, podrías volver al punto de partida y hacerlo más rápido, en menos tiempo o de manera más elegante. Recién ahí es que se realiza la optimización. Si intentaras salir a toda velocidad al inicio, sería muy probable que te lastimaras con algún obstáculo o fueras rápido en la dirección equivocada. También sería un poco raro hacer movimientos elegantes si ni siquiera sabes a dónde vas a ir.

Así que para este problema, quizás se te podría ocurrir algo como:

// recorrer la cadena en reversa
function f(s) {
 var result = "";
 for (var i=s.length; i>0; i--) {
  result = result + s[i-1];
 }
 return result;
}

Ok, es lo primero que se me ocurrió. Veamos si se puede hacer mejor. Quizás se pueda recorrer la cadena de otro modo:

// recorrer la cadena de frente pero acumular en reversa
function g(s) {
 var result = "";
 for (var i=0; i<s.length; i++) {
  result = s[i] + result;
 }
 return result;
}

¿Y si vemos como luce con reduce?:

// usando reduce y acumulando en reversa
function h(s) {
 return s.split("").reduce(function(result, c) {
  return c + result;
 });
}

¿Y usando la notación fat arrow?:

// usando reduce y fat arrow
function j(s) {
 return s.split("").reduce((result, c) => c + result);
}

Quizás con la práctica sea esta forma la que aparezca primero en tu cabeza en el futuro. Podría ser impresionante. Pero hay que recordar que las cosas empiezan tanteando. Y que está bien.

2017/01/28

Qué hacemos



Es diferente el sentimiento de desarrollar algo sin tener que hacerlo por cumplir sino porque realmente te interesa.

En lugar de simplemente cubrir las horas por las que te están pagando, o los tickets que se acordaron para el sprint, te encuentras jugando con la idea de cómo podría ser mejor. Y cuando sabes que esas ideas podrían aplicarse, sientes como la alegría de estar yendo por un bonito camino.

Me pregunto cómo en un trabajo pagado podría incentivar ese tipo de actitud.

Me parece que podría ser cuando hay claridad en lo que se quiere lograr, y el sentimiento de autonomía.


No es una buena idea recordar a alguien que se le está pagando por hacer cierto trabajo. Eso baja el nivel de la conversación hasta el primer peldaño de la pirámide de Maslow.

Es triste que  tu jefe o tu cliente crean que solo trabajas por el pago que recibes. Tú sabes que lo haces por un propósito mayor, o te gustaría que así fuera, pero esos comentarios motivan a cumplir solo lo mínimo necesario.

Más arriba en la pirámide de Maslow, cuando las necesidades básicas han sido cubiertas, trabajamos para ejercitar las habilidades que disfrutamos desarrollar. Si recibimos algo por ello, qué bien. Pero si no nos pagaran, igual lo haríamos.

Ese es el tipo de trabajo que es difícil de entender para quienes se han acostumbrado a trabajar para sobrevivir.

Hay personas que siguen pensando así aunque sean ricas y ya no tengan procupaciones económicas. Y lo transmiten a sus hijos, familiares, amigos o colegas o empleados.

Antes, quizás era necesario pensar así para poder sobrevivir. Dejar atrás lo sueños y sacrificarse por lograr un mérito material.

Pero hoy, pensar así conduce a la extinción.

Las soluciones de antes van quedando obsoletas. Hay que ir imaginando lo que construiremos mañana mientras van cayendo los edificios a nuestro alrededor.

Las nuevas soluciones están viniendo de la mano de gente apasionada por lo que hace. Logran ver cosas que nadie más. Logran hacer cosas que nadie más.

No puedes hacer que tu hijo se enamore de la mujer que te parece que más le conviene.

Tampoco puedes hacer que un empleado sienta pasión por lo que más conviene a la empresa.

Tienes que encontrar alguien que ya lo sienta, y cuidarlo.

También puedes orientar tu empresa para que aproveche lo que sus apasionados miembros son capaces de construir juntos.


Las empresas están descubriendo que, en lugar de vender lo que haces, hay más éxito vendiendo el por qué lo haces.

Pero no es lo mismo preguntárselo a alguien que trabaja por encargo que a alguien con pasión por ello.

2017/01/21

La importancia de solucionar algo

Amazing Grace

A Grace Hopper se le dio el encargo de elaborar el manual de instrucciones de una de las primeras computadoras creadas en los Estados Unidos.

A la Marina, le interesaba averiguar de qué modo podría aprovechar el potencial de la nueva máquina Mark I.

No era común que una mujer perteneciera a la armada, y tampoco tenía los estándares de peso y talla, pero sus habilidades matemáticas le ayudaron a ser admitida y abrirse camino.

Ella propuso organizar bajo nombres más asequibles las rutinas que había coleccionado con su equipo, y un esquema para reutilizarlas con más facilidad y automatizar la generación de las secuencias binarias que eran la forma normal de programar las computadoras en aquella época.

Normalmente, para programar la solución de un problema, había que enfrentarse con el hardware y los interruptores necesarios para implementar el programa. Era como tener que atravesar continuamente una bruma mental para distinguir lo que se quería conseguir.

En cambio, usar un compilador de código tenía la ventaja de permitr pensar con más claridad en el problema que se quería resolver.

Sin embargo, su propuesta fue desechada porque el código binario generado de ese modo era más largo y menos eficiente.

Grace persisitió en ello como un proyecto personal. Desarrollando lo que vendría a ser conocido como lenguaje ensamblador, o Assembler.

Uno de sus amigos, que había estado meses con un equipo tratando de programar la solución de un problema especialmente difícil, logró hacerlo en unas horas usando Assembler.

Poco a poco, el uso del Assembler se fue extendiendo.

Años después, creó COBOL, el primer lenguaje de programación, que permitía expresar un programa en algo parecido a sentencias en inglés.

Menos eficiente pero más eficaz

Hoy en día, prácticamente toda la programación se hace con ayuda de compiladores y los lenguajes de alto nivel que aparecieron luego del COBOL. De ese modo, los problemas no solo se resuelven con más rapidez, sino también con menos errores. Y si los hubiera, son mucho más fáciles de localizar.

La propuesta de Grace de usar lenguajes de más alto nivel para solucionar problemas encontró resistencia en otros programadores que desdeñaban el código binario repetitivo, largo e ineficiente que se producía de ese modo. Ellos podían hacerlo más simple, más elegante, del "modo correcto".

Los programadores que podían programar directamente en binario no eran muchos y quizás se sentían un poco como sumos sacerdotes. Los intermediarios exclusivos entre la gente y las máquinas todopoderosas.

Los lenguajes de alto nivel tuvieron la virtud de hacer la programación de computadoras accesible a más personas.

Sigue siendo cierta la observación de que el código binario producido por los compiladores es más repetitivo, largo y menos eficiente que el que se podría producir directamente. Sin embargo, con la mejora de la velocidad de procesamiento, la programación directa en binario ya es muy poco práctica.

Es más importante llegar primero a la solución de un problema. La eficiencia del resultado se podría ir mejorando luego de eso (finalmente reemplazando código por assembler y luego por binario si el rendimiento fuera algo vital).

Algo hecho es mejor que lo perfecto

¿Qué es mejor, una solución perfecta que tarda tanto que nunca llega, o una solución que funcione?

"Done is better than perfect" es una famosa frase acuñada por la gente de Facebook.

La comunidad hacker tiene además "Primero que funcione, luego optimizas".

Y Donald Knuth, la famosa "La optimización prematura es la raíz de todo lo malo".

No son opiniones. Expresan un hecho, comprobado una y otra vez en la experiencia de los programadores y los equipos de programadores y los proyectos de programación.

Aún así, de cuando en cuando encontrarás a otros programadores o desarrolladores de software insistiendo en buscar la perfección o hacer optimizaciones durante la solución.

Es la optimización mal entendida.

Optimizar algo está bien, pero su momento es después que haya una solución.

Solo puedes mejorar algo que tienes, si no, la optimización es una falacia (y las falacias son peligrosas porque suelen tener ese aire de verdad que hace que uno las acepte si no se anda con cuidado)

Código limpio

A la computadora le da igual si el código está limpio o no.

El código limpio es una optimización orientada a los programadores para facilitar el mantenimiento del programa.

Pero, igual que toda optimización, su momento es después que tengas una solución, no antes.

Hay que disfrutar garabateando con código, esbozando algoritmos, en el proceso de concretar una solución.

Pretender escribir código limpio durante el proceso de solución es tan contraproducente como pretender pintar la versión final de un retrato directamente sobre un lienzo en blanco.

Cómo odio a los haters :-)

Hay programadores que automáticamente tienen actitudes hostiles o de desdén hacia ciertos lenguajes de programación, ciertos frameworks o ciertas librerías.

"PHP es el peor lenguaje de programación jamás inventado"

"Javascript es un lenguaje de juguete que no se puede tomar en serio"

"Todos esos frameworks son basura que complica las cosas"

Pero minimizar lo que nos disgusta no hace que nuestras soluciones sean mejores. De hecho, impide ver las soluciones de otros.

PHP es un lenguaje que ha ayudado mucho a democratizar la programación en Internet. La valla es más baja y mucha más gente puede entrar y cometer errores que hacen sonreir con desdén a ciertos académicos y profesionales. Pero ha permitido que muchas ideas geniales vean la luz. Más de la mitad de los blogs en Internet están hechos en WordPress, que es un administrador de contenidos escrito en PHP. Wikipedia está escrita en PHP. La base de Facebook también estuvo escrita en PHP.

Javascript ha evolucionado. No es solo para hacer efectos especiales en una página web. Permite crear interfaces complejas. Y en el lado del servidor, facilita el desarrollo de soluciones ligeras, asíncronas y sin bloqueos. Paypal usa Javascript en el backend. Hay quienes consideran que actualmente Javascript tiene uno de los más completos ecosistemas de desarrollo web.

Los frameworks son herramientas para resolver problemas. Como un martillo, o una sierra. Puede tomar su tiempo conseguir maestría en su uso. Muchos dedos golpeados, cortes accidentales. Y puede que no sean para todo tipo de problemas. Quizás haya herramientas más sofisticadas, o más ligeras, pero posiblemente te enfrentarás a más problemas si intentas hacer carpintería con una piedra, un cuchillo, o una navaja suiza.

Creo que siempre es más constructivo tratar de ver las buenas partes, usar esas buenas partes y evitar las otras.

También aquí es cuestión de ver el vaso medio lleno.

Referencias

2017/01/13

La falacia de "hacerlo sin frameworks"

Hay una idea difundida entre muchos desarrolladores acerca de que es mejor no usar un framework en lo posible.

El Framework F tiene las deventajas a, b y c; por lo tanto, si no lo usan, evitarán esas desventajas, concluyen.

Veamos por qué esto es una falacia (un razonamiento errado que parece correcto). Las falacias son peligrosas porque parecen correctas.


Un framework es, en esencia, un conjunto de convenciones sobre cómo usar un conjunto de librerías.

Cuando usas un framework, vas notando cómo sus convenciones condicionan el modo en que abordas las tareas y resuelves los problemas. Poco a poco, empiezas a visualizar las soluciones en términos del framework.

Esa pauta que establece el framework puede ser de gran ayuda para mantener orden y estabilidad en un proyecto. Y también para darle continuidad.

Pero también puede ser que las convenciones sean demasiado reguladoras, restrictivas o limitantes. O que haya problemas que sean de solución muy dificil o imposible en términos del framework.

Entonces tenemos:

Framework F
Pros Contras
m a
n b
p c


Para analizar qué framework elegir, sería:

Framework F Framework G Framework H
Pros m
n
p
Contras a no no
b no no
c no no

Así que si esos frameworks tienen esas desventajas, no los usemos y así las evitaremos.


Suena lógico. Sin embargo, es un error.


Lo que realmente están proponiendo es esto:

Framework F Framework G Framework H Framework X
Pros m ?
n ?
p ?
Contras a no no ?
b no no ?
c no no ?

¿Qué es el Framework X?

Es el framework (propio aunque negado) que se irá definiendo (sobre la marcha).

Las preferencias de uso, las posibilidades y limitaciones, y el contexto de trabajo del equipo de desarrollo, determinarán un conjunto de librerías y cómo se deben usar.

Es decir, un framework.


Por eso, lo que realmente están proponiendo los desarrolladores que "evitan frameworks" es:

"No uses un framework conocido (con todas sus ventajas, horas de prueba, comunidad y documentación) y usa mi framework (que aún no existe pero va a ser mejor que todos ellos)"


Si aceptas esa propuesta, automáticamente estás asumiendo un proyecto extra que deberá correr en paralelo al que quieres realizar. Porque hacer un buen framework consumirá tiempo y recursos en codificación, documentación y capacitación.

No es que te estés ahorrando el costo de usar un framework; estás asumiendo el costo de hacer uno.

"No hemos usado ningún framework, así que no tienes que aprender nada nuevo para empezar".

No es verdad. Verás que tendrás que familiarizarte con el conjunto de funciones y librerías que están usando, la forma en que las llaman y la particular (o peculiar) manera como el proyecto se ha organizado (o ha resultado ser).

Si usas un framework conocido, puedes tener más apoyo de la comunidad, documentación, casos de ejemplo, etc. Habrán más personas que ya lo conocen y están disponibles para colaborar contigo.

Es cuestión también de saber ver el vaso medio lleno y valorar las virtudes del modelo open source.

El efecto Dunning-Kruger

Es un efecto psicológico que se observa en todas las personas, de pensar que son más competentes en aquellas cosas en que realmente tienen más limitaciones:

Why Do Incompetent People Think They're So Great?


¿Estamos siendo afectados por el efecto Dunning-Kruger?

Usando las buenas partes

Creo que es importante ser claro en lo que se hace, y tratar de mostrar claramente lo que sucede cuando nos damos cuenta que está sucediendo.

Porque solamente podemos construir castillos de verdad usando ladrillos de verdad.

Reinventar la rueda es muy util para desarrollar las habilidades de invención.

Poder hacer un propio framework que sea comparable con los frameworks conocidos es algo admirable.

Pero no es el mejor camino minimizar lo que esos frameworks conocidos son para que así la tarea de competir con ellos resulte más fácil o nuestro trabajo parezca más meritorio.


Siempre es posible encontrar algo desfavorable en un framework, algo que no puede hacer tan bien y que quizás nosotros podamos hacer mejor (en un contexto más simple, aisladamente).

Me parece más interesante juzgar los frameworks en función de las cosas favorables. De lo que nos permiten hacer. De los problemas que nos pueden ayudar a resolver.

Porque tampoco podemos construir castillos con ladrillos que no tenemos. Hay que usar lo que sí tenemos.


Hay una cita de Addy Osmani como recomendación acerca de los frameworks:

“First do it, then do it right, then do it better.”

Primero usa lo que hay, conócelo realmente. Si encuentras algo que mejorar, corrígelo. Luego intenta hacerlo mejor.

Buscar

Más artículos

Archivo