Osakidetza y cómo cagarla con un Bash-script (1/2)

Hola,

Son la una y media de la mañana y no puedo dormir así que os voy a contar una linda historia con moraleja en la que trataré de poneros en mi piel.

Resulta que hace varias semanitas, debido a unos temas, acaba llegando a tus manos una radiografía de la espalda de alguien. Esta radiografía fue pedida a Osakidetza, el servicio Vasco de Salud (comunidad autónoma en la que resides).

El sistema es sencillo. Te hacen una radiografía y, si la quieres, te permiten que rellenes un escrito para pedirla. Poco después te llega en un CD.

Tiene todo el sentido del mundo porque así tienes oportunidad de tener una segunda opinión de un conocido, acudir a otro médico o verla por ti mismo.

Ahora esperaréis que la historia se tuerza porque no se puede ver en Linux pero va a molar mucho más.

Resulta que el CD tiene un Autorun (que en Linux, evidentemente, no se dispara) que despierta una aplicación para poder ver las radiografías. Piensas que con una imagen sería suficiente, pero, como descubrirás después, el programa es mucho más potente y es capaz de tomar medidas, navegar y otras cosas que a los médicos les vienen bien.

Como la aplicación no se dispara, piensas que en Linux vas a estar jodido, pero te motivas y abres el contenido del CD a ver qué se cuece. Resulta que es un programa en Java. ¡Bien! ¡Eso es portable!

Tiene un par de carpetas de Windows y Mac así que esperas que haya para Linux. Efectivamente. Te encuentras con un script de Bash que esperas que levante la aplicación de Java.

Lo lanzas y falla, te dice que no tienes Java instalado. Lo compruebas y tienes el OpenJDK. Por un momento piensas en instalar el Java oficial pero acabas rechazando la idea y abriendo ese script para buscar por qué no te localiza lo que tienes. Te encuentras con esto:

#!/bin/bash
# This script attempts to find an existing installation of Java that meets a minimum version
# requirement on a Linux machine.  If it is successful, it will export a JAVA_HOME environment
# variable that can be used by another calling script.
#
# To specify the required version, set the REQUIRED_VERSION to the major version required, 
# e.g. 1.3, but not 1.3.1.
REQUIRED_TEXT_VERSION=1.6

# Transform the required version string into a number that can be used in comparisons
REQUIRED_VERSION=`echo $REQUIRED_TEXT_VERSION | sed -e 's;\.;0;g'`
# Check JAVA_HOME directory to see if Java version is adequate
if [ $JAVA_HOME ]
then
	JAVA_EXE=$JAVA_HOME/bin/java
	VERSION=`$JAVA_EXE -version 2>&1 | head -1`
	VERSION=`echo $VERSION | grep "java version" | awk '{ print substr($3, 2, length($3)-2); }'`
	VERSION=`echo $VERSION | awk '{ print substr($1, 1, 3); }' | sed -e 's;\.;0;g'`
	if [ $VERSION ]
	then
		if [ $VERSION -ge $REQUIRED_VERSION ]
		then
			JAVA_HOME=`echo $JAVA_EXE | awk '{ print substr($1, 1, length($1)-9); }'`
		else
			JAVA_HOME=
		fi
	else
		JAVA_HOME=
	fi
fi

# If the existing JAVA_HOME directory is adequate, then leave it alone
# otherwise, use 'locate' to search for other possible java candidates and
# check their versions.
if [ $JAVA_HOME ]
then
	:
else
	for JAVA_EXE in `locate bin/java | grep java$ | xargs echo`
	do
		if [ $JAVA_HOME ] 
		then
			:
		else
			VERSION=`$JAVA_EXE -version 2>&1 | head -1`
			VERSION=`echo $VERSION | grep "java version" | awk '{ print substr($3, 2, length($3)-2); }'`
			VERSION=`echo $VERSION | awk '{ print substr($1, 1, 3); }' | sed -e 's;\.;0;g'`
			if [ $VERSION ]
			then
				if [ $VERSION -ge $REQUIRED_VERSION ]
				then
					JAVA_HOME=`echo $JAVA_EXE | awk '{ print substr($1, 1, length($1)-9); }'`
				fi
			fi
		fi
	done
fi

# Get additional weasis arguments
userParameters=()
for var in "$@"
do
if  [[ $var == \$* ]]
then
    userParameters+=("$var")
fi
done
echo user arguments: ${userParameters[@]}

# If the correct Java version is detected, then export the JAVA_HOME environment variable
if [ $JAVA_HOME ]
then
	export JAVA_HOME
	echo Java Home: $JAVA_HOME/bin/java
	curPath=$(dirname "`readlink -f "$0"`")
	echo Weasis launcher directory: $curPath
	$JAVA_HOME/bin/java -Xms64m -Xmx512m -Dgosh.args="-sc telnetd -p 17179 start" -Dweasis.portable.dir="$curPath" -classpath "$curPath/weasis/weasis-launcher.jar:$curPath/weasis/felix.jar:$curPath/weasis/substance.jar" org.weasis.launcher.WeasisLauncher \$dicom:get --portable ${userParameters[@]}
else echo 'Weasis requires Java Runtime '$REQUIRED_TEXT_VERSION' or higher, please install it'
fi

Es gracioso porque en menos de 10 minutos lo haces funcionar convirtiéndolo en lo siguiente sin pensar mucho:

#!/bin/bash
# This script attempts to find an existing installation of Java that meets a minimum version
# requirement on a Linux machine.  If it is successful, it will export a JAVA_HOME environment
# variable that can be used by another calling script.
#
# To specify the required version, set the REQUIRED_VERSION to the major version required, 
# e.g. 1.3, but not 1.3.1.
REQUIRED_TEXT_VERSION=1.6



# Get additional weasis arguments
userParameters=()
for var in "$@"
do
if  [[ $var == \$* ]]
then
    userParameters+=("$var")
fi
done
echo user arguments: ${userParameters[@]}

# If the correct Java version is detected, then export the JAVA_HOME environment variable
if [ 0 -eq 0 ]
then
	export JAVA_HOME=/usr/
	echo Java Home: $JAVA_HOME/bin/java
	curPath=$(dirname "`readlink -f "$0"`")
	echo Weasis launcher directory: $curPath
	$JAVA_HOME/bin/java -Xms64m -Xmx512m -Dgosh.args="-sc telnetd -p 17179 start" -Dweasis.portable.dir="$curPath" -classpath "$curPath/weasis/weasis-launcher.jar:$curPath/weasis/felix.jar:$curPath/weasis/substance.jar" org.weasis.launcher.WeasisLauncher \$dicom:get --portable ${userParameters[@]}
else echo 'Weasis requires Java Runtime '$REQUIRED_TEXT_VERSION' or higher, please install it'
fi

Por el camino, te encuentras con unos detalles increíbles que, viendo lo graves que son, decides contar en tu blog.

La única diferencia con el script de arriba es que has borrado todo el bloque de comprobaciones y has hardcodeado JAVA_HOME. Una solución muy sucia que no funcionaría en todos los casos, pero te vale por el momento.

En la parte borrada hay unas joyas estelares. La próxima entrada explicará cuales, por qué y por qué este código a parte de no ser muy bueno es peligroso.

Seguimos otro día. Comentad con lo que encontréis y lo vamos discutiendo. Dentro de unos días pongo mi análisis del código.

¡Un abrazo!

Anuncios

droWMark, postea en WordPress desde Vim

Hola hijos,

Hoy vengo a contaros una cosa loca que he estado desarrollando para mí durante el último año en ratos libres.

Hace tiempo que salió su primera versión pero no lo publiqué porque no saqué tiempo y porque me daba un poco de vergüenza porque era muy cutre, pero ahora que tengo más tiempo (ya os contaré por qué) me he decidido a añadirle unas funcionalidades nuevas y estoy contento.

Vengo a presentaros droWMark, un plugin para Vim que sirve para postear a WordPress desde el editor, escribiendo en Markdown (con sabor a Pandoc). Por si os lo preguntabais, sí, llevo como un año posteando en este foro directamente desde Vim.

Hasta hace muy poquito el plugin no soportaba la subida de imágenes, pero tampoco lo necesitaba porque pocas veces añado imágenes a los posts. 🙂

Os cuento un poco cómo funciona por debajo y si queréis más información os leeis la documentación del plugin, que es bastante clara. Para leerla con entrar en la carpeta doc en el repo es suficiente pero mola más que os lo instaléis (usad Vundle o algo por favor) y hagáis :help drowmark.

El plugin se separa en dos partes, una en VimL (o VimScript) y otra en Python.

La parte en VimL se encarga de gestionar todo lo relacionado con Vim y llamar a la parte de Python. Hace las siguientes cosas:

  • Syntax highlighting de los ficheros especiales que utilizo. Son una mezcla de Markdown con un poco de INI1 en la cabecera (aunque no por mucho tiempo).
  • La documentación del plugin, para poder hacer :help drowmark y esas cosas.
  • Define el nuevo tipo de fichero WP. Para esto necesita detectar el tipo de fichero y marcarlo bien. De esto se encarga ftdetect.
  • Gestionar el post de plantilla para que se pueda hacer :NewWordPress y te prepare el archivo. Simplemente se guarda un fichero de referencia que se escribe en el búfer actual al llamar al comando. Fácil.
  • Llama al script de python de forma ordenada pidiéndole los credenciales al usuario. Mientras escribes la contraseña no muestra nada en la pantalla, pero no está muy fino y si te equivocas y borras no funciona. Si leéis el código entenderéis por qué.

La parte de python es todo lo relacionado con WordPress y la funcionalidad que se quería ofrecer. Así puede separarse y usarse sola o migrarse a otros editores. Tengo pendiente migrar a Emacs pero necesito la ayuda de mi divertida hermana Emacsera para eso. La parte de Python hace lo siguiente por el momento.

  • Captura las opciones puestas en la cabecera INI y construye un blogpost con ellas.
  • Convierte el MarkDown a HTML usando panflute. En las versiones anteriores lo hacía con pypandoc.
  • Durante la conversión (esto es la novedad de la versión 1.1) busca todas las imágenes en el texto y las sube si son ficheros locales cambiando la URL para que referencia al recién subido archivo. Lo mismo ocurre con el campo thumbnail de la cabecera.
  • Postea el documento convertido.

Y eso es todo.

Fijaos que esta entrada tiene un thumbnail (o imagen destacada) y una imagen aquí debajo. Están únicamente puestas para demostrar que puedo.

Imagen puesta para fardar

No os toméis este Plugin como la mejor manera de hacer las cosas, sólo quiero que veáis que cuando nos apetece cambiar nuestro workflow con un poco de esfuerzo podemos conseguirlo. No hace falta volverse muy loco.

Si leéis el código fuente veréis que es un script de Python muy corto y bastante cutre. A veces merece la pena programar agresivo si el programa cumple con lo que debe.

Ahora mismo estoy en ese proceso de ir convirtiéndolo en un programa razonable, pero, de momento, es un poco mierda porque funciona y para mí es suficiente. Si empezamos grande a veces nos aburrimos antes de terminar. Mejor empezar pequeño y cuando la cosa dé unos frutos recuperar la motivación para poder crecer.

¡Espero que os mole y lo probéis!

Comentarios y críticas, en la sección de abajo.

Un abrazo.


  1. INI son los ficheros como la configuración de Git, hice un parser de esto en C hace un tiempo

Reventando la Terminal

Buenas,

Llevo bastante tiempo investigando formas de disparar mi productividad y aprender sobre cómo funcionan por dentro las herramientas que utilizo (ya sabéis lo que hago con Vim) y hace unos días, cuando leí un post que me pasaron sobre cómo ser un master de la terminal, me di cuenta de que se me ha ido de las manos porque creo que incluso puedo aportarle cosas al artículo.

Lo voy a intentar.

Yo utilizo Bash y mi editor habitual es Vim. A veces, no mucho, uso tmux para multiplexar la terminal pero entre Vim y otros trucos no suelo necesitarlo. Todas mis configuraciones las podéis encontrar en mis dotfiles por lo que no voy a entrar en esas partes, me preguntáis lo que necesitéis saber.

Bien.

Para explotar tu terminal al máximo la tienes que conocer y para eso viene muy bien saber un poco de historia. Me la saltaré, pero la investigáis un poco vosotros (teletipos y esas cosas). Por herencia histórica, casi todos los terminales usan una librería de edición en línea llamada GNU-Readline. Bash no es una excepción, pero quizás otros sí lo sean así que investigáis vuestro caso (Fish y cosas modernas no sé si lo cumplirán).

Empiezo con Readline pero igual es lo más duro, os lo podéis saltar, más abajo os cuento las herramientas que más utilizo y cómo y en el medio hay un pequeño cheatsheet para navegar por ficheros de texto con less o las hojas del manual.

¿Tenéis ganas?


GNU-Readline

GNU-Readline define muchísimos shortcuts. Si os leeis la documentación (man readline) tenéis todos, pero yo os cuento los que más uso. Es posible que a medida que vaya aprendiendo más mis gustos vayan cambiando, os lo diré en el futuro.

Supondré que usáis GNU-Readline en modo Emacs. Sí, soy Vimer, pero el modo Vi no me gusta mucho en este caso porque no aprovecho la potencia de la edición por modos y el número de shortcuts y de maniobras que hay que hacer con los dedos es suficientemente reducido para que usar el modo Emacs no sea insufrible. Este es el truco número 1, probad el modo Vi también.

Voy a daros un poco de información con los hotkeys que uso habitualmente con un truco mnemotécnico entre paréntesis para ayudar (¡si lo tengo!).

Copiar-pegar, insertar, editar

Ctrl-i: autocompleta con las sugerencias posibles. Lo conoces porque lo usas en el Tabulador.
Ctrl-w: borra una palabra hacia la izquierda (word). El contrario es Alt-d pero no lo uso.
Ctrl-u: borra hacia la izquierda hasta llegar al inicio de la línea (se parece a la w, no tengo nada mejor). Muy útil cuando escribimos contraseñas para limpiar el campo entero. El contrario es Ctrl-k.
Ctrl-y: pega lo borrado anteriormente (yank). Alt-y para elegir cosas que has borrado anteriormente.
Ctrl-x Ctrl-u: Deshacer (prefix + undo). También se puede con Ctrl-_.
Ctrl-x Ctrl-e: Editar la línea con el editor por defecto (prefix + editor). Muy útil para cuando nos venimos arriba con la línea y se nos va de las manos o para pegar cosas.

Más abajo os enseño a pegar desde fuera de la terminal

Señales y procesos

Ctrl-c: envía la señal SIGINT al proceso actual, que sirve para pararlo.
Ctrl-z: envía la señal SIGSTP al proceso actual, que lo suspende. Luego jugaremos con él usando jobs, bg, fg y disown (zzz: onomatopeya de dormir).
Ctrl-d: envía EOF (End Of File) a la terminal, lo que te hace salir de ella como si hubieses escrito quit y otras cosas. Es muy útil y funciona en casi todas las terminales del mundo. Si hay texto en la línea borra el carácter.

Recordad también comandos como `kill`, `killall` y `pkill` y  el  `&` para lanzar en background. Más abajo profundizo un poco más.

Saltar por la línea

Pueden usarse las teclas inicio, fin y esas, pero hay otras también:

Ctrl-e: salta al final de la línea (end).
Ctrl-a: salta al inicio de la línea (“a” es la primera letra del diccionario).
Ctrl-x Ctrl-x: salta al lugar anterior (la “x” es como una marca de dónde estás y dónde estabas).
Alt-b y Alt-f: saltar una palabra hacia atrás (backward) y hacia delante (forward).

Manipular el historial

Ctrl-s y Ctrl-r: buscar hacia delante (search) y hacia atrás (reverse-search) en el historial. Para ejecutar el comando usar Ctrl-o o simplemente pulsar Enter para seleccionarlo.
Alt-.: inserta el último argumento utilizado.

Las flechas de arriba y abajo también sirven para manipular el historial, hay shortcuts también pero siempre uso las flechas.


Navegación simple por ficheros

Tanto Vim como less (y por tanto las páginas del manual) soportan lo que cuento aquí, uso muchísimas más, pero para navegar por las hojas de manual es suficiente:

/: abre una miniterminal para buscar. /palabra busca la palabra en el texto. Se puede saltar a la siguiente pulsando la letra n (next) e ir hacia atrás con N.

g: Ir al inicio del documento. En Vim hay que pulsarla dos veces porque es un prefijo para otras cosas como gf (go to file).

G: Ir al final del documento.

Ctrl-u y Ctrl-d: (Up y Down) moverse media página hacia arriba o hacia abajo.

Usad la ayuda para esto. En less `h`. En Vim `:h navigation`.

No lo he dicho de forma explícita pero las man-pages se muestran con less, por eso es lo mismo.

 


Herramientas locas y trucos

Aquí os cuento las herramientas o trucos que suelo hacer, estoy un poco loco así que no recomiendo seguir esto a pies juntillas. Seguro que algo sacáis, de todas maneras.

Copy-paste desde el universo

A todos nos gusta copypastear de Stack Overflow. Esto no es tan fácil desde la terminal. Yo uso xclip y muchas magias más para poder copiar y pegar desde la terminal a X y viceversa. Investigadlo un poco pero resumiendo mucho:

$ xclip -o          # muestra lo que haya en el portapapeles
$ xclip fichero     # manda el fichero al portapapeles
$ comando | xclip   # manda el output del comando al portapapeles

Hay más programas que hacen esto y podemos hacer algo parecido redireccionando las cosas a fichero y abriendo con otras herramientas, etc.

Recuperando el shortcut de arriba para lanzar comandos desde el editor C-xC-e, podéis abrir vuestro editor, pegar en él, analizar lo que habéis pegado y ejecutarlo con sólo salir. Buen truco.

¡No repitas comandos! Usa el historial

Lo primero, para que el comando no se registre en el historial introducid un espacio al principio. Tal que así:

$  ls

Para investigar lo ocurrido anteriormente podéis usar los shortcuts de antes para el reverse-search (C-r, remember remember) y otros, pero no olvidéis el comando history para mostrar todo, que podéis grepear su output y jugar con ello:

$ history | grep command

Tenéis también algunos comandos que actúan sobre el historial, no voy a entrar, lo investigáis. Os dejo uno de oro, que es el único que uso:

$ !!      # ejecuta el comando anterior
$ sudo !! # ejecuta el comando anterior con sudo

O si no, os podéis hacer un alias que se llame fuck como tengo yo en mis dotfiles.

Utilidades generales

Cualquier sysadmin o UNIX lover sabe suficiente de esto, y vosotros, seáis lo que seáis, pues también deberíais.

Como seguramente ya sabéis, podéis desviar la salida estándar (stdout, 1) y la de errores (stderr, 2) a un fichero para guardar el output en él ( >), tomar el input desde un fichero (<), hacer que se redireccione a otro comando en ejecución (el típico pipe, |), mandar curros a background (&) y otras. Si queréis un día os cuento más, pero quiero hacer esto más corto 😀

Estas desviaciones molan pero molan aún más si usamos los ficheros especiales como /dev/null y otros (zero, urandom…). Yo suelo usar mucho /dev/null para descartar output. Es muy común esto en scripts de arranque de demonios.

tee también es un comando que juega con esto y a veces es muy útil. Yo sólo lo uso para guardar un fichero como superusuario cuando lo he abierto sin sudo en Vim. 😀

Podemos suspender procesos con C-z, como decíamos antes y con ellos podemos jugar también.
Usando jobs, bg, fg y disown podemos mandarlos a background (bg) o foreground (fg) y desengancharlos de nuestra terminal (disown). Jobs es la herramienta para mostrarlos en orden, con su PID y todo, si queremos, para poder tirarles un kill.

Tenemos también la alternativa tmux/screen que a parte de servir para multiplexar la terminal, suelen permitir hacer un “detach” y dejar una sesión en background a la que podremos reengancharnos más tarde.

Comandos útiles

tree es una herramienta para hacer un ls en forma de árbol. Muy útil para ver bien. Normalmente hay que instalarlo porque no viene por defecto.

find: la navaja suiza del terminal gladiator. Lista todos los ficheros desde el directorio actual de forma recursiva, esa es su funcionalidad mínima. Puedes añadir filtrados por nombre o por tipo o por mil cosas más. Puedes ejecutar un comando por cada fichero etc. Ser un master en este comando te puede ahorrar mucho tiempo.

xargs: otra joya del terminal killer. Ejecuta comandos tomando un fichero como argumentos. ¿Sabéis cuando descomprimís un tar.gz y no está dentro de una carpeta y el contenido se os mezcla con la carpeta actual? Solución fácil: Creáis una carpeta y lo descomprimís limpiamente dentro, para limpiar el destrozo anterior hacéis lo siguiente:

$ ls carpeta | xargs rm -rf # borra todos los ficheros con el nombre de los que están en la carpeta de la carpeta actual

grep: Sirve para filtrar lineas por patrones que queramos, pero es mucho más poderoso que eso. El puto grep. Usadlo.


 

Creo que voy a dejar de escribir ya.

Me he dejado mil cosas y me gustaría profundizar mucho más pero esto se me está yendo de las manos. Comentad algo y provocad que escriba una segunda parte del post. 😉

¿Qué usáis vosotros? ¿Sois unos gladiadores de la terminal?

Espero vuestras opiniones.

Single-page apps: Razones y herramientas

Hola,

Para un proyecto he estado trabajando con el concepto de las single-page apps y he estado investigando alternativas para hacerlas. Hoy os comparto el análisis que hice, a mi manera como siempre, empezando por el contexto de estas cosas modernas y terminando por las opciones que yo tomé para ese caso concreto pero siempre enseñándoos de dónde viene la movida y basándonos en el lado teórico, que es lo que nos interesa.

Mi caso concreto era una aplicación relativamente sencilla, que me encantaría enseñaros pero no puedo (acuerdos de confidencialidad y esas cosas, cuando seáis mayores los tendréis). Como he dicho antes, mi situación me hizo tomar decisiones en una dirección pero la vuestra puede ser otra y puede que necesitéis elegir otras alternativas

Voy a hacerlo básico y no voy a profundizar en los detalles. Empezará muy tonto y subirá de level, no lo dejéis a medias porque os parezca simple que habrá movida para rato.


Contexto: Single page apps

Normalmente solemos tener un escenario con esta pinta cuando se trata de aplicaciones web: Un servidor con toda la lógica, lo que luego llamaremos backend, y una parte que se encarga de visualizar lo que sale del mismo y permitir cambios, lo que se llamará frontend.

El backend a veces expone métodos, a través de una API RESTful normalmente (que está de moda), consultables directamente desde fuera sin pasar por el frontend.

El frontend puede tener muchas formas aunque para el caso de hoy trataremos el caso de una página web. Otro ejemplo sería una aplicación móvil, por ejemplo.

Normalmente las páginas web de este tipo, tienen un lado de servidor y un lado de cliente (lo conté aquí). El lado de servidor entrega los ficheros estáticos y crea las diferentes páginas con su server side templating en su Flask, PHP (yuyu) o lo que sea accediendo a la parte backend, ya sea por métodos externos o porque son el mismo servidor y la línea entre frontend y backend es muy delgada.

En este documento se plantea la manera de eliminar completamente la parte de servidor de ese frontend para que haya un backend que exponga toda su funcionalidad de forma estándar y un frontend que le diga lo que tiene que hacer.

¿Pero qué ganamos con esto, tío loco? Ganamos que el servidor podría ser accedido por cualquier software donde se incluyen aplicaciones de escritorio, terminales, demonios, un chip que se ha inventado mi cuñao o una aplicación móvil. Además, quitamos la parte de visualización del servidor, entregando siempre datos parseables por cualquiera.

Con esto hemos, colateralmente, convertido nuestro frontend clásico en un programa que se le entrega al navegador y corre en él y ya no necesita de un trabajo especial para ser entregado. Ahora el frontend es una single-page app entregada de forma estática.

Implicaciones en el backend

Poca cosa. Entregar JSON (API REST) en lugar de HTML construido es incluso más sencillo.

Implicaciones en el frontend

  • Requiere de más carga en el browser para compensar lo que le hemos quitado de nuestro servidor. No es muy grave, ahora los dispositivos están acostumbrados.
  • Se convierte en un programa en sí mismo. Necesita:
    • Más librerías para hacer todas las labores nuevas.
    • Manejar dependencias para que no se desmadren las librerías.
    • Una arquitectura. Una forma ordenada para atacar la API.
    • Facilidades para gestionar un código más complejo.

Elecciones tomadas

En esta sección se mencionará qué se ha seleccionado en el caso del que os hablaba con el fin de resolver esas implicaciones que han aparecido pero más adelante se pretende introducir la teoría de cada una de las elecciones para que vosotros os planteéis otras y sepáis adaptaros a vuestro contexto con mejores armas. No os toméis esto ni siquiera como una recomendación. Sólo es un caso concreto.

  • Más librerías: Hay miles de maneras de gestionar las librerías: Descargarlas a mano, usar Bower, etc. Se ha optado por usar NPM (Node Package Manager) que a pesar de estar orientado para el server side nos valdrá porque haremos un truco encima.
  • Gestión de dependencias: Existen un par de maneras principales de gestionar dependencias en el lado de cliente. Se eligió Browserify porque unido a NPM funciona muy bien. Tiene sus desventajas, pero unido al resto de puntos (luego lo veréis) se convierten en facilidades.
  • Una arquitectura: Si no nos organizamos va a ser imposible pedir cosas al backend y ponerlas en la pantalla de forma sencilla. Para esto se ha seleccionado una de las arquitecturas más simples: MV (Model-View), porque diferencia la parte de los datos, el Model, de la visualización, la View, de forma sencilla sin elementos intermedios. Luego hablamos de la familia MV* y de otras cosas. Se ha usado una librería que facilita mucho este trabajo, se llama Backbone.js.
  • Facilidades de gestión: Este código empieza a tener entidad y programarlo todo en un único fichero de JavaScript kilométrico ya no es tan factible como antes. Necesitamos estructurar y separar. Gracias a Browserify y Backbone tenemos la perfecta oportunidad de usar CoffeeScript para programar. Este lenguaje de programación permite usar Programación Orientada a Objetos de forma sencilla, tiene una sintaxis muy simple y tiene un millón de trucos que nos vendrán bien y encajan perfectamente con el proyecto.

Teoría

Ahora cuento un poco de qué van todas las cosas que he mencionado arriba pero profundizando un poco en el sentido teórico de las mismas. No fear.

Dependencias y librerías: Bundles VS AMD

La mejor opción de las dos que se platean aquí como solución técnica es el AMD. AMD o, Asynchronous Module Definition, es una forma de definir módulos de código Javascript que se cargan en el cliente a medida que se van necesitando. De esta forma, no se descarga todo el código de golpe y si el hilo de ejecución no llega a utilizar un módulo pues no se descarga y punto. Ahorramos descargas y tenemos mejor rendimiento. Hay una librería muy famosa que implementa esto: Require.js. Aunque hay más. En su documentación podéis leer más al respecto e incluso una comparativa de por qué mola más que la otra alternativa.

La otra alternativa, la que en el título denomino Bundles, es CommonJS con magia extra aportada por Browserify. CommonJS es un proyecto para llevar JavaScript a otros entornos que no sean el Browser, por ejemplo, Node.js es una de sus implementaciones. CommonJS tiene una manera de gestionar dependencias basada en las sentencias require y module.exports. En el caso de Node.js, en cuanto el intérprete encuentra una sentencia require busca el fichero al que se hace referencia y lo importa. Esta búsqueda es lo que vamos a explotar.

Todos conocéis NPM (Node Package Manager), una herramienta para gestionar librerías y programas de Node.js y las dependencias de los mismos. Node.js, a la hora de buscar los ficheros requeridos busca la instalación hecha por NPM para encontrarlos (carpeta node_modules), con lo que, si tenemos todo instalado con NPM, es extremadamente sencillo gestionar las dependencias y cargar los módulos en nuestros programa, así como diseccionarlo en diferentes ficheros.

¿Pero no hemos dicho que esto es para entornos que no sean el Browser?

Sí, eso hemos dicho. Ahí es donde entra Browserify.

Browserify es una herramienta para convertir un bloque de código con pinta de Node.js en código ejecutable en el Browser. Browser-ify. Browser-izar.

Browserify resuelve todos nuestros require y module.exports de Node.js y browseriza nuestro código fuente creando un sólo fichero (el Bundle) con todo nuestro proyecto unido debidamente (con sus closures de protección y todo). Así sólo necesitamos añadir un tag script en nuestra web con el fichero generado y ya tendríamos todo bien ordenado como he dicho antes, usando NPM y todo su poder de gestión de dependencias por debajo.

En comparativa con los AMDs vemos varias cosas:

  • El Bundle es todo nuestro código fuente, así que la descarga inicial es mayor que el AMD, que lo descargaba todo por partes cuando lo necesitaba.
  • Gestionar las dependencias con NPM es más fácil que rascarse la oreja. Tenemos los package.json y todas esas cosas y, además, podemos crear un paquete con nuestra web como resultado y facilitar también los deploys.
  • El AMD mola más pero tiene una sintaxis loca. No he hablado de esto antes pero requiere que aprendamos otra sintaxis extra, que no es muy difícil pero hay que pensar que nuestros módulos se cargan de forma asíncrona y otros temas. No es copiar la sintaxis de Node.js que ya sabíamos por otras cosas.
  • Con Browserify podemos compartir las mismas dependencias en el Browser y en el Server si lo tuviéramos.
  • Y la más importante de todas: Browserify, como habéis entendido sin que lo haya puesto de forma explícita, requiere de un preprocesamiento del código antes de que sea funcional. Antes de ver nuestros cambios tenemos que ejecutar Browserify para que nos construya nuestro bundle. Esto genera problemas a la hora de debuggear porque la línea de tu fichero no es la misma que la del Bundle, por ejemplo. Pero hay workarounds y tampoco es tan grave en aplicaciones pequeñas o de tamaño medio, donde podemos tener un mapa mental completo de lo que hacen.

No lo hemos seleccionado para este proyecto pero el AMD mola mucho también. No lo ignoréis en vuestras aplicaciones futuras.

Arquitectura: familia MV* y Backbone.js

Hemos dicho antes que necesitábamos una manera ordenada de coger los datos, editarlos y pintarlos. Esto se resolvió hace mil de tiempo con la movida del MVC (Model View Controller), que es una arquitectura de tres elementos interconectados y parlanchines. El Model representa los datos de la aplicación, el View la representación visual de los mismos y el Controller una entidad capaz de editar los datos. Dicho de forma sencilla: el Usuario usa el Controller, que manipula el Modelo, que actualiza la View, que el Usuario ve.

Una arquitectura sencilla para crear UIs.

Pues partiendo de esto, es fácil pensar que podemos fusionar sin mucha dificultad el View con el Controller porque, al fin y al cabo, ambas se encargan de facilitar al usuario visión y acceso al Model. Pues con eso generamos un MV (Model View), como Backbone (luego vamos a eso).

También se nos podría ocurrir, ojo, introducir un elemento intermedio en el MV para tener una interfaz entre el Model y el View que se encargue de convertir datos de backend (el Model) en datos de frontend (la View). Esto se le llama MVVM (Model View ViewModel).

¿Y si…? Sí hijo, sí, tranquilo, puedes cambiar la arquitectura mil veces y, si te basas en MV para hacer los cambios, generarás una arquitectura de UI de la familia MV*.

Pues esa es la historia. Mil diferentes pero el mismo fondo.

Backbone.js

Backbone es una librería (no framework, si quieres un framework usa Marionette.js) de MV bastante sencilla. Dispone de varios tipos de elementos que facilitan esto y lo automatizan bastante. La parte positiva de Backbone es que no se las da de listo y supone muy pocas cosas, sólo considera que tienes una API RESTful detrás, nada más (y encima puede pisarse ese comportamiento con otro).

En Backbone existen los siguientes elementos: Model (¡sorpresa!), Collection, View ( 🙂 ), Router, History y Sync. Algunos sirven para el MV (adivinad cuales) y otros aportan funcionalidades que nos vendrán bien. Todos vienen en forma de clase para que los extendamos con nuestras funcionalidades concretas. Cuento un poco.

  • Model y Collection: Ambos representan el Model de la aplicación, pero la Collection es un conjunto de entidades únicas de tipo Model. La Collection se comporta como un array de modelos (con unas cuantas magias por encima). Los modelos y colecciones de Backbone son inteligentes saben pedir por una API REST sus contenidos y actualizarlos usando unos métodos sencillos, toda la lógica de la API está implementada ya. Que bien ¿no?
  • View: Representa la vista de un modelo o una colección. Se le dice cómo tiene que pintarse en la pantalla y cómo tiene que editar el modelo o colección subyacente y se encarga de ello. Con el sistema de eventos de Backbone se puede hacer fácilmente que cada vez que el modelo o colección subyacente cambie se actualice la vista al momento. Tiene varias cosas extra encima para facilitar el trabajo pero eso lo miráis.
  • Router y History: Dos componentes para gestionar las URLs y el Historial del navegador. Esto es importante porque como tenemos una single-page-app la página nunca cambia y, si no hacemos nada, siempre estamos en el índice. Esta parejita actualiza el historial y crea URLs para que podamos compartir enlaces y nos lleven a donde esperamos y podamos usar el botón de atrás del navegador sin problemas.
  • Sync: Esto es lo que los Models y Collections usan por debajo para comunicarse con su fuente. Como se ha dicho, se entiende que la fuente es una API REST pero no tiene por qué serlo. Podemos pisar éste objeto para que acceda a otra cosa, como el LocalStorage u otros, eso lo dejo a vuestras ingeniosas cabezas.

Resumiendo:

Creamos nuestros modelos y colecciones referenciando al modelo de datos del servidor de backend, los asociamos a vistas independientes y conectamos todo para que mágicamente funcione.

Y funciona.

¡Odio Javascript! CoffeeScript y la transpilación

¿Tú también?

Pensaba que estaba solo.

CoffeeScript es un lenguaje de programación que se compila contra JavaScript, es decir, el resultado de su compilación es un programa en JavaScript. Por qué hacer un lenguaje con esta pinta es una pregunta que tiene una respuesta muy simple: Porque JavaScript es una mierda.

Básicamente CoffeeScript añade Syntactic Sugar sobre JavaScript. Elimina las llaves, casi todos los paréntesis, y mucho código inútil, facilita el uso de clases (no prototype ni mierdas) y aporta array comprehensions, oneliners chulos y comprobaciones molonas (como la existencial y el == con cerebro).

El sistema de clases viene muy bien para Backbone, son dos proyectos que trabajan muy bien juntos (son del mismo autor), del que ya hablé in the past

No deja de ser un JavaScript con toques de Python y Ruby. Tenéis otros lenguajes de programación de este pelo, como TypeScript, LiveScript, ELM o ClojureScript, que tienen otro tipo de ideologías más perversas. Donald Trump.

Como habéis sobreentendido, nuestro código lo escribiríamos en CoffeeScript y tendríamos que convertirlo a JavaScript antes de probarlo y eso es un problemilla. En nuestro caso ya no lo es tanto porque, como tenemos Browserify y también requiere cierto procesamiento, ya no sentimos que perdemos nada. Además Browserify tiene la opción de instalar un módulo de CoffeeScript para hacer las dos conversiones a la vez así que no problemo. Se llama Coffeeify, por si queréis investigar.

Si nuestro código fuese para el lado del servidor también podríamos usar CoffeeScript y probarlo directamente con el interprete de CoffeeScript, pero para una aplicación final deberíamos convertirlo para evitar problemas de rendimiento.

Pues ya está, el código está bonito y es fácil de programar, no hay que aprender cosas nuevas para hacer CoffeeScript, sólo un poco de sintaxis sencilla.

EXTRA: CoffeeScript viene con un par de detalles muy locos. Tiene una cosa que se llama Literate CoffeeScript y un tipo de ficheros tipo Makefile llamados Cakefile que automatizan tareas. Ahí lo dejo.


Bueno, pues eso es todo. Iba a poner miles de links pero no lo he hecho. He puesto nombres y palabras clave y que cada uno busque.

Preguntas, comentarios y otras cosas, ya sabéis.

Un abrazo.

PD: Esta vez sí que me he pasado en la longitud pero ya que me he preparado el contenido pues lo cuento bien. 😀

Inocencia

Hace ya dos años hablé en un post sobre muchas cosas que me entristecían o afectaban en ese momento, cosas que debían ser cambiadas y la forma en la que intenté cambiarlas.

Todo lo enfoqué desde la idea de que la vida es un ir y venir de bromas y no sé si ahora mismo quiero enfocarlo igual porque, como aquel día, no tengo muchas ganas de reír mientras escribo estas líneas, a bolígrafo porque me siguen doliendo las manos.

En mi cabeza sólo hay una idea general de lo que quiero hablar pero seguro que la excitación del momento me lleva suficientemente lejos. Como hizo hace dos años. Como siempre hace.

Enlazando con lo que dejé a medias, tenía un trabajo, sí, que obtuve antes de terminar la carrera. Me despidieron de él. Sí. “La empresa de sofware libre más importante de Euskadi” (haha) me despidió. Esto puede suponer un shock importante para los lectores habituales de este sitio y seguramente para cualquier persona que me conozca, pero así fue. Sufrí una broma grandiosa y hoy, dos años más tarde era momento de contarla bien.

En realidad la broma no fue el despido sino todo el tiempo que pasé allí, cobrando menos de 800€ con un convenio destartalado y unas condiciones laborales cada vez más repugnantes. Feliz, porque aprendía cosas. Feliz, porque tuve unos compañeros excepcionales a los que echo mucho de menos a veces.

Ésta es la genial broma que tenemos hoy sobre la mesa, la que me permitirá arrastrar todo lo demás.

El despido de Irontec se debió a varias cosas, algunas de ellas fueron culpa de mis más elaboradas y sutiles bromas. Fueron todos esos momentos que le hicieron a mi jefe saber que yo no iba a conformarme con cualquier cosa, que a mí necesitaba alimentarme con retos, que yo no quería apalancarme sin más en un puesto de trabajo que no me aportase absolutamente nada. Me despidieron por la misma razón por la que me contrataron. Me despidieron porque Gorka es muy listo y sabía que me iría pronto.

“Me lo agradecerás cuando estés desarrollando microprocesadores o lo que sea que acabes haciendo” me dijo. Y se lo agradezco, pero fueron tiempos difíciles y me dolió mucho porque casi me había convencido a mí mismo de que ese lugar estaba bien y que no quería marcharme. Esa broma fue muy pesada, siempre es pesado que te despidan pero más cuando te dicen que no tienen ninguna queja de tu trabajo, que te largan para que no te largues tú, que no tienen sitio para ti.

Me echaron de aquella empresa, empresa supuestamente hacker, por ser como fui en mi PFC, el detonante de este blog.

Eso no fue suficiente para acabar con mi carácter bromista. Ese carácter que hoy más que nunca está presente en mi vida y más aprecio. El que me lleva a los lugares donde quiero estar.

Estuve cuatro meses en paro, desesperado en cierta manera, pero seguí haciendo cosas en mi tiempo libre, cosas técnicas, aprendiendo, mejorando porque, para mí esto no es sólo lo que hago para ganarme la vida. Esto lo hago porque me encanta.

Durante el tiempo en paro las bromas aumentan. Todo el mundo me anima a intentar trabajar en lugares que no son suficiente, que no sacian el hambre y les digo que no. ¡Qué risas recordando sus caras! Recuerdo cuando le dije a mi padre que no echaba currículum en ofertas que quisieran a más de una persona porque significaba que quería a gente estándar para cubrir un puesto y que yo no quería eso para mí. Ahora tiene mucha gracia, la verdad, aunque cuando eso no la tuvo. Es una broma a largo plazo.

Otra broma que no he sabido valorar lo suficiente hasta pasado un tiempo de aquello es el puñetazo de realidad que me di a mí mismo. Durante esos meses en paro me dedicaba a otras cosas por las mañanas mientras que, por las tardes, programaba, investigaba y buscaba trabajo. Con el tiempo, echando la vista atrás, me di cuenta que aprendía mucho más en mi casa que en mi trabajo de prácticas al que, supuestamente, iba para aprender.

No sólo me engañaron ellos, me había engañado todo el mundo y yo, tonto de mí, no había caído en la cuenta.

Durante ese tiempo además, este blog, que estuvo a punto de desaparecer hace dos años cuando escribí la entrada a la que hice referencia al principio, tuvo sus mejores momentos, cuando dedicaba días a investigar y preparar buenos contenidos en la línea que me interesa.

Cuando aquello mi situación personal empezó a irse a la mierda (si no lo estaba ya) pero decidí que a pesar de todo me mantendría bromista y feliz. Mi novia me dejó para que pudiese irme lejos, a un sitio en el que querían contratarme y fui. Hecho mierda, pero fui. Todo el mundo me deseaba de nuevo un precioso viaje a varios cientos de kilómetros de mi casa (recordáis alemania ¿no?). Sentí que todo el mundo quería que me largase, como si nunca hubiesen querido que estuviera aquí. Qué bromistas ellos también ¿verdad?

Una vez allí me di cuenta que el río se estaba saliendo de su cauce y que no estaba haciendo las cosas como tenía que hacer, así que dos días más tarde volví, a donde nadie me quería, a hacerlo a mi manera. Antes de ir compré dos cuadernos, éste en el que os escribo y otro en el que empecé a escribir un libro. Eso me hizo centrarme durante todo ese tiempo y me ayudó en los tiempos en los que ver tantas ofertas de trabajo basura me machacaba por dentro.

Poco después, me contrataron en un sitio. Lo que aprendí en este tiempo y la actitud que desarrollé me ayudó a conseguir un buen trabajo, que aún conservo tras algo más de un año. Ahora soy ingeniero de investigación y desarrollo en Fon Labs, el departamento de I+D de Fon, la empresa del Wifi que quizás conozcáis. Por fin estaba en un sitio que me aportaría cosas. A menos de 30Km de mi casa además. Y todo el mundo diciéndome que lo encontraría fuera ¡JA JA JA! ¡Imagina que me llego a quedar allí!

Joder, por fin estaba a gusto otra vez, a pesar de todo lo que quedó roto. Unas condiciones laborales infinitamente mejores (tranquilos que no soy rico todavía) y un trabajo técnico era lo que necesitaba.

Si hubiese perdido las ganas de hacer lo que me gusta, si hubiese cambiado, quizás ahora estaría en otra parte. Quizás, ahora, no estarías leyendo esto.

Como dije, la vida es una puta inocentada que cambia y gira en cada momento y lo que creías que estaba bien rápido se va a la mierda.

Mantente firme y sigue siendo tú, disfrutando de lo que haces y no renunciando a ello. Si no, puede que te quedes allá, que sigas toda la vida con esos 800€ o menos, o, lo que es peor, que creas que eso es todo a lo que puedes aspirar.

Continuará pronto.

 


Quiero dejar un pequeño espacio final, como hice la otra vez, para todas las personas que nunca perdieron un atisbo de fe en mí. Esos “Ekaitz, si alguien puede eres tú” peusto que ellos son la razón por la que la rueda sigue girando y no he colapsado todavía. Todos necesitamos un motor. Todos necesitamos que nos confirmen que vamos por el buen camino.

Además, también quiero agradecer a quien nunca quiso que me fuera, y que ahora está durmiendo a mi lado en el sofá, todo lo que me da sin pedirme absolutamente nada. Si no fuese porque estabas tú aquí quizás no me hubiese importado no volver nunca.

NeoVim True colors

Hola,

Ayer, después un año investigando (no muy bien por lo que he visto finalmente) he conseguido configurar NeoVim para que utilice true colors. La última vez que me puse con esto lo di por imposible pero he vuelto a ello porque he añadido un ColorColumn y necesitaba que tuviera un color más oscuro.

Resulta que no era para nada difícil pero no sé por qué me costó tanto en el pasado.

Antes de empezar NeoVim es una extensión de VIM para añadir alguna funcionalidad extra que seguramente nunca se verán en VIM. Os dejo la página del proyecto y vosotros investigáis.

Ahora al lío.

Para que soporte true colors hay que tener una variable de entorno activada: NEOVIM_TUI_ENABLE_TRUE_COLOR. Que se puede hacer en la propia terminal con un export o haciendo un let en la configuración de NeoVim.

En muchos sitios pone que esta configuración es suficente pero no es cierto. NeoVim necesita más cosas para que los true colors se vean. Si se añade :set termguicolors empezará a funcionar como debe. Esto es un bypass muy loco que hace que la terminal utilice los colores de la GUI.

En Vim hay dos modos de trabajo: el clásico de la terminal y el de la GUI. GUI implica que hay una aplicación de escritorio con sus ventanitas y eso que muestra Vim (gvim, por ejemplo). Los colores de una a la otra opción son diferentes porque se supone que la terminal no es capaz de manejar los mismos colores que una interfaz gráfica, pero eso ya no es del todo cierto. Muchos terminales modernos soportan true colors por lo que pueden usar los colores que, en principio, están hechos para mostrarse en la GUI.

NeoVim sabe esto así que diciéndole que use los colores de la GUI en la terminal lo hará y tendremos los true colors. Otro problema es que muchos esquemas de color comprueban si se está utilizando el modo GUI o el de terminal para decidir qué esquema utilizan (el complejo o uno simplificado especial para la terminal). Esa comprobación se hace con has('gui_running'), cuidado con eso. Hay algunos esquemas de color que son para true colors y algunos no lo comprueban y funcionarán bien (ejemplo).

Ya que estaba me decidí también por buscar otras opciones similares. Existe una muy chula que te cambia la forma del cursor dependiendo del modo en el que estés. Usa el cuadradito para modo normal, un subrayado del carácter en el modo reemplazar y una barrita vertical que se sitúa entre caracteres en el modo insertar. De esta manera tenemos un pequeño apoyo visual al trabajar. Esto se activa con NVIM_TUI_ENABLE_CURSOR_SHAPE que igual que la de antes de “enable true color” se puede setear como variable de entorno en la terminal o con un let dentro de la configuración de NeoVim.

Otro día os hablo más de NeoVim e incluso puede que haga una especie de manual a mi manera. Pero eso otro día.

Os dejo con el patch que he aplicado a mi configuración:


" Enable TRUE COLORS
+let $NVIM_TUI_ENABLE_TRUE_COLOR=1
+let $NVIM_TUI_ENABLE_CURSOR_SHAPE=1
+set termguicolors

" Highlight where the lines are more than 80 characters wide
set colorcolumn=80
-highlight ColorColumn ctermbg=DarkGrey
+highlight ColorColumn ctermbg=DarkGrey guibg=#262626

Como veis en el ColorColumn, ahora aplico el guibg=#262626 que es un gris bastante oscuro en su color RGB. Al estar aplicado el termguicolors utilizará ese color también en la terminal.

¡Conseguido!

Probad y me decís.


PD: Os dejo mis dotfiles para que veáis mi configuración entera: https://github.com/ekaitz-zarraga/dotfiles

Inspiración: Jeremy Ashkenas

Hola,

Hoy voy a hablar de cosas de las que no acostumbro: JavaScript y personas.

Quiero ponerme en el lado humano de la movida esta porque si no nos despistamos y pensamos que nuestras librerías, herramientas y mierdas no los hace un ser humano y, ya de paso, aprovechar para presentar a una persona admirable por su forma de pensar y enfocar sus soluciones.

Hablemos de Jeremy Ashkenas.

¿Por qué mola tanto este tío?

Mola porque es el autor de Backbone.js, Underscore.js, CoffeeScript, LiveScript (con otros coautores) y otras cosas locas. Hoy hablaré un poco de estos proyectos y os contaré por qué son tan interesantes.

Para empezar es extremadamente interesante la forma en la que publica los proyectos porque a parte de publicar lo que se suele hacer, con una documentación muy clara y limpia con un montón de ejemplos, publica una versión del código fuente con anotaciones que puedes leer a un lado mientras analizas el código del proyecto en el otro.

Por ejemplo, en CoffeeScript.

Creo que esto viene muy bien para que todos aprendamos de su modo de trabajar de forma sencilla y para que los novatos puedan leer pequeños bloques de código de producción con lo que hace al lado.

Documentation is like sex. When it is good, it is very, very good; and when it is bad, it is better than nothing. – Dick Brandon

Ese es el primer detalle, ahora vamos proyecto a proyecto.

UnderScore

Underscore es una librería de javascript que aporta mucha rapidez a la hora de desarrollar. Funciona sobre JQuery y aporta un montón de funciones para facilitar el trabajo del desarrollador: map, filter, invoke así como cosas más avanzadas como templating y otras cosas molonas.

En esta librería se empieza a notar cómo le gusta trabajar a este señor, empieza a asomar la programación funcional.

Link al proyecto

BackBone

Backbone es un framework muy cremas. Se basa en UnderScore y en JQuery para aportar una estructura para crear aplicaciones web que cojan sus contenidos desde una API REST.

Está basada en la estructura Model-View, no Model-View-Controller como se suele decir por ahí. Investigad qué es eso de Model-View.

Esta librería también hace uso de la programación funcional pero quizás no sea tan evidente. Lo que sí que hace es reducir de forma drástica la cantidad de código que hay que escribir y facilitar la comprensión de lo que se escribe separando en todo momento las diferentes etapas o capas del programa.

Link al proyecto

CoffeeScript

Este es un lenguaje de programación que transpila a JavaScript (ECMAScript5). Sirve para desarrollar más rápido y tener soporte para cosas que JavaScript no tiene de forma nativa pero pueden desarrollarse a mano. En realidad lo único que hace es aportar sintactic sugar a JavaScript pero lo hace con tanto estilo que casi lo convierte en un lenguaje distinto.

La transpilación esta lo que significa es que en lugar de compilar contra binario o bytecode o lo que fuera, este lenguaje de programación se transforma a JavaScript para que otras herramientas (Browsers o Node.js, por ejemplo) puedan ejecutarlo. Hay muchos más lenguajes que hacen este mismo truco: ClojureScript, ELM, TypeScript, LiveScript y muchos más. Cada uno de ellos aporta estilos diferentes sobre la idea principal de JavaScript.

CoffeeScript a mí me parece la joya de la corona. La idea principal de este lenguaje es sacar partido de JavaScript haciendo que se parezca lo máximo a Python o Ruby, que son lenguajes de programación con los que se prototipa muy rápido. De esta forma, escribimos menos y hacemos más.

Además tiene una cosa muy loca que es el Literate CoffeeScript que es una forma de usar una especie de templating en MarkDown, en el que solamente se ejecutan las partes marcadas como código fuente.

A mí me ha gustado mucho.

Con la aparición del nuevo estándar (ECMAScript6) ya no tiene tanto sentido porque casi todas las cosas que CoffeeScript aportaba han sido añadidas al lenguaje pero la forma de escribirlo sigue molando cantidad y las ideas detrás de este lenguaje siempre van a quedar para que aprendamos de ellas.

Os recomiendo que investiguéis acerca de los lenguajes transpilados a JavaScript, así como de ECMAScript y de qué diferencia tiene con JavaScript y por qué. No quiero entrar en eso ahora mismo.

Link al proyecto

LiveScript

Sin entrar mucho en detalle, LiveScript es como CoffeeScript pero basado en Haskell en lugar de Python o Ruby.

Y ya.

Tiene otra idea pero sigue siendo más de lo mismo: explotación de herramientas con un sabor concreto.

Link al proyecto

Conclusiones

Este señor es, evidentemente, un visionario de la movida. Muchas cosas que se han añadido a ES6 vienen de su trabajo con CoffeeScript y LiveScript, y sus librerías tienen bastante éxito.

En general todo lo que he contado aquí es sencillo, está bien explicado, tiene una documentación muy buena y es siempre legible y cómodo. Es un ejemplo de cómo hacer las cosas y una forma de trabajar muy interesante.

Se nota que ha trabajado en estas cosas y ha creado librerías para sí mismo y ha aprovechado para que los demás puedan aprender de ellas y utilizarlas.

Su buen gusto para la programación funcional y el prototipado rápido es lo que me ha llamado la atención de este señor. Tiene una colección de obras realmente bonita e impresionante.

La verdad es que llegué a muchos de sus proyectos de forma independiente y con el tiempo descubrí que eran de la misma persona. No me sorprendió lo más mínimo. Tienen un estilo inconfundible.

Esto no es un: copiad a este señor por favor. Es un: deberíamos aprender de él y aplicar lo que nos guste de sus soluciones en nuestros proyectos.

Espero que os haya gustado la recopilación y el formato de la entrada. He dejado muchas cosas abiertas a la investigación para fomentar que analicéis y aprendáis por vuestra cuenta también.

Cualquier duda, comentario o lo que sea: me decís.

Saludos.

PD: Y gracias a Jeremy por la colección de herramientas tan interesantes y por la genial documentación.