Futuro presente

Hola,

Ya estamos por aquí otra vez.

Hoy me pondré más serio de lo que acostumbro porque me toca hablar del futuro más que del pasado, como me suele gustar hacer.

Ya sabéis que dejé mi trabajo y otras movidas así que ahora estoy en mi sofá a las 9:45 de la mañana escribiendo esto, sin cobrar un duro.

Que no cobre ahora no significa que no tenga intención de hacerlo y tampoco significa que quiera un trabajo. Tal y como ya dije, creo que no encajo bien en el modo de trabajo de una empresa estándar y tampoco quiero forzarme a hacerlo porque para mí no tiene ningún sentido.

Como todavía tengo energía y he tenido la suerte de haber podido ahorrar un poco, estoy dedicando este tiempo a aprender y a preparar mi futuro trabajo. Sí, voy a generar un puesto de trabajo en el que encajo perfectamente, diseñado explícitamente para mí. Si hay suerte, puede que en el futuro pueda generar otros puestos de trabajo especiales, quizás uno sea para ti.

Esto sólo es una forma retorcida de decir que estoy creando mi propia empresa.

Ahora tendréis miles de preguntas pero tampoco voy a poder responder a todas porque, como he dicho, la estoy creando. La idea lleva mucho tiempo viva pero es posible que la realidad la haga cambiar y mutar hasta que yo pueda comer de esto o hasta que demuestre definitivamente que no puedo.

Os cuento un poco de qué va, aunque algunos ya lo habéis leído por otras fuentes.

 

 

ElenQ Technology es el nombre de la empresa que estoy creando.

Se dedicará a hacer, principalmente, Investigación y Desarrollo en las áreas en las que me muevo. Estas áreas incluyen todo lo que hablo en este blog y algunas cosas más que me guardo para mí como la electrónica, las redes, y otras, casi todas relacionadas con lo que conocemos como la Ingeniería de Telecomunicaciones con el pequeño añadido de que soy una persona muy curiosa que ha indagado en otros mundos.

Sé que a los que me leéis os van a gustar lo que diré a continuación:

ElenQ Technology tiene un fondo social obligatorio, heredado de mis desencantos con la empresa y de mis principios, que he dejado demasiado de lado durante un tiempo y ya va siendo hora de recuperar. Así de fácil. Los puntos críticos son los siguientes:

  • Los proyectos que se hagan deben hacer del mundo un lugar mejor. Respetaran los derechos humanos y el diseño ético. Serán Free Software/Hardware siempre. Los clientes tendrán acceso a todo lo que hago y participaran de forma activa en el desarrollo.
  • En los casos que sea aplicable, el conocimiento obtenido con el proyecto será liberado, con una buena documentación, para todo el mundo, para que cualquiera tenga más la información ya mascada sirviendo la realización del proyecto como una excusa para concentrar el conocimiento en una documentación fácil de leer.
  • Se apoyarán los proyectos que se utilicen durante la actividad de la empresa, en la medida de lo posible, con tiempo de desarrollo, dinero o lo que se pueda.

Sobre este sustento, la empresa investigará y desarrollará cosas para terceros, que siempre serán pequeñas y medianas empresas porque son esas empresas que aún conservan cierta ética (en algunos casos) y no pueden permitirse tener un departamento de I+D continuo. Con esto se fomenta que las empresas pequeñas crezcan porque tendrán la oportunidad de investigar y mejorar sus procesos e ideas para así competir un poco mejor con los grandes. Como los proyecto serán éticos, fomentará que las empresas crezcan en una dirección ética, provocando, en cierta manera, que el mundo sea un lugar mejor dentro de un tiempo, aunque sólo sea un poquito.

También ayudaré a que particulares consigan avanzar en esa idea de proyecto que tienen y que no tienen a nadie que les ayude a crear. Esa idea que siempre te quita el sueño pero como tienes un curro no tienes fuerza suficiente para sentarte a investigar y terminarla.

Y, por último, también se desarrollarán ideas propias y se mantendrán proyectos propios. Algunos serán herramientas que utilice para mí (ejemplo), como hago siempre, y otros serán ideas que querré desarrollar.

Como un pequeño extra importante, aunque no quiero que sea la primera actividad de la empresa, se darán formaciones sobre tecnología y sus usos que servirán para aprovechar lo que aprendo en los proyectos y el extraño y profundo conocimiento que llevo años atesorando en lugar de hacer otras cosas. Intentaré tener un hueco para hablar de las razones de abandonar mi curro anterior y animar a otros a plantearse qué está ocurriendo con los datos, la privacidad, la ética y otras cosas también. Siempre desde la humildad de un tío de 26 años que no se ve con un traje ni hablando de usted, pero siempre tiene una carcajada y un apretón de manos para cualquiera.

Durante el texto le he llamado empresa a lo que estoy montando aunque podría ser perfectamente una organización sin ánimo de lucro. Sólo quiero poder comer, y vivir sin preocuparme demasiado, no necesito crecer y crecer como el concepto (capitalista) de empresa propone. La idea es hacerle la vida más fácil a los demás a costa de que hagan mi vida un poco más fácil.

Eso es a lo que me voy a dedicar. Innovación Ética.

Crecimiento en la dirección adecuada.

Seguiré informando. Para bien o para mal.

 

PD: Ya tengo un nombre de dominio y movidas pero no me quiero poner con eso aún a poner links y cosas. Prefiero dejaros aquí la filosofía y ya contaros cosas en el futuro o que me preguntéis. No me gusta el spam. No me gusta una mierda.

 


Como siempre un par de agradecimientos:

A los que estáis ahí y escucháis mis mierdas, a ti, sí, y a ti, el del fondo, también.

A los que respetan lo que hago. A los que me confirman que un mundo mejor es posible. A los que no pierden la confianza en mí. A los que me piden colaborar conmigo a 700km de aquí. A los que me preguntan cosas. A los que tienen ideas para mí. A los que tienen cerveza y me sacan de casa cuando las cosas van lento.

A mi hermana por ayudarme con el LaTeX.

A mi amada por ayudarme en general.

Llegó el momento de saltar.

Si hay agua abajo, os aseguro que voy a caer tan fuerte que os voy a salpicar a todos.

Vergüenza inocente

Me cansé de “ser rico” y ahora me toca “ser pobre”. Entrecomillo porque ambas son inciertas hasta cierto punto, y ciertas hasta otro. La magia de la contradicción.

Hoy toca hablar de vergüenza, más que de inocencia, y de por qué una persona “brillante” “con muy buenas ideas” se convierte en un “fracasado” por iniciativa propia. Esta vez entrecomillo porque son citas textuales, algunas mías y algunas no. Seguro que puedes adivinar cuales digo yo, y seguro que los que no me siguen a menudo se equivocan, posiblemente a propósito.

En una entrada anterior te cuento cómo lo pasas mal cuando no tienes curro, hoy te cuento cómo lo pasas mal cuando tienes uno que casi todo el mundo querría y no lo quieres.

Sí, tú. Dejé ese curro hace un mes. Ese del que te hablo, el del I+D.

Era un curro de puta madre, no te líes, pero no quiero trabajar allí y posiblemente en el que me propongas tampoco. No valgo para eso. Soy una mierda de persona. Lo sé. Puedes dejar de leer aquí si te da la gana, o puedes leer más y llorar de la risa por lo tonto que soy. Quizás sólo llores. Sólo lo sabrás si sigues leyendo.

Hace mucho tiempo lo conté en la entrada a la que enlazo en la entrada enlazada aquí: me duele. Me duele mucho. A veces me duele tanto que quiero arrancarme los brazos, o esa puta rodilla que empezó a darme problemas. La espalda y con ella el cuello, la mandíbula y la cabeza. Hasta detrás de los ojos.

Es difícil vivir así.

Es difícil no poder levantarte de la cama y al mismo tiempo pasarte días sin dormir. Muy difícil. Casi tan difícil como contarlo sin hacerte la víctima o quedar como un mierda que se queja por todo.

Los que me leéis aquí sabéis lo que me gusta lo que hago, o lo podéis intuir al menos y sabéis que sólo lo que os acabo de contar no iba a ser una razón suficiente para dejar un curro que me guste. Soy un poco más duro que todo eso, al menos todavía. Así que empiezo por la razón menos importante para deciros además que ya me encuentro mejor, aunque sea un poco mejor y me esté costando, que todo lo que estoy haciendo está sirviendo para algo por ahora.

Ahora añadidle a ese dolor el trabajo en el que estaba. Un curro de puta madre para muchos, repito, en el que creo que siguen buscando gente.

Currar de 8:30 a 14:00, parar una hora obligatoriamente para comer y volver al tajo de 15:00 a 17:45. Ocho horas y cuarto para poder salir a las 17:00 el viernes porque había que entrar obligatoriamente a las 9:00 (el resto de días se podía entrar hasta las 10:00 si se compensaba por la tarde). Muchos trabajáis con horarios peores, lo sé, pero yo no puedo con eso. Os cuento por qué.

Primero porque el dolor me está arruinando la vida y la única forma de hacerle frente es hacer deporte, bastante deporte. Con estar finito (como estoy) y cuidarse no es suficiente. No es un tema de salud, es que mis musculitos se vuelven locos con el estrés y están todo el rato haciendo fuerza sin control así que me duele mucho porque tampoco estoy como Hulk y mi cuerpecillo no lo soporta. Eso significa, parar más, estirar a menudo y hacer deporte. Para, estira, haz puto deporte y controla ese estrés. No quieres que te pase esto. Créeme.

Segundo porque ese mierda de curro no era suficiente (acabo de decir que era guay ¿no?). Bromas de nuevo. No, no era suficiente. Era un curro técnico, que tenía sus cosas pero no estaba cambiando el mundo, al menos no para bien. Los retos técnicos eran escasos porque todo estaba relativamente masticado ya y siempre se hacía lo mismo. Dejé de aprender, de aprender mucho, y pasé a aprender poco a escondidas aprovechando la pequeña libertad de implementación que tenía para hacer siempre cosas que nunca había hecho porque me estaba aburriendo ya y no podía soportarlo.

Esto no era suficiente, cuando iba a casa mis ansias de aprendizaje me hacían seguir investigando en otros ámbitos (me obligaba a que no fuera laboral). Seguía aprendiendo cosas, moviéndome, recordándome todo el rato lo poco que sé. Esto lo hacía, claro, en lugar de hacer deporte. Uno, porque estaba agotado y el dolor no ayuda y, dos, porque el tiempo es limitado y todo no se puede hacer.

Tampoco era todo aprender, a veces también programaba cosas para aprender y diseñaba cosas sin las trabas que los altos cargos narcisistas, que creen que su análisis de dos minutos vale más que seis meses de implementación de cuatro ingenieros a tiempo completo, imponen. Me he currado la frase, vuélvetela a leer si hace falta.

Sin trabas, como cuando estuve en paro, aprendía rápido. Joder. ¡Hasta empecé a robar tiempo a la empresa haciéndolo allí! No es un secreto esto, empecé a procrastinar para investigar y aprender por culpa de la desmotivación.

La gente dice que la motivación tiene que salir de uno pero no es suficiente. Intenté mantenerme motivado de las siguientes maneras. Orden cronológico aunque algunas se mantienen vivas siempre o aparecen antes en menor medida.

  1. Aprender del entorno. Esto es cuando eres novato y tienes que ponerte al día. La oficina, el ritmo, etc.
  2. Aprender de proyectos. Cuando te empiezan a asignar cosas y tienes que acostumbrarte a las herramientas nuevas.
  3. Aprender de compañeros. Siempre tienen cosas para ti. Esto es cuando ya controlas tu mundo y aprendes del de los demás pidiéndoles ayuda o preguntándoles cosas que ellos saben y tú no.
  4. Aprender de retos. Esto es cuando ahora no buscas sólo hacer, si no que buscas hacer bonito lo que haces y entender cómo funcionan tus herramientas por dentro para poder explotarlas de forma elegante.
  5. Aprender de la incomodidad. Aquí es donde sales de tu zona de confort apropósito porque no vas a aprender dentro de lo de siempre y cambias detalles (como el lenguaje en el que programas) para tener una excusa para seguir aprendiendo.
  6. Aprender del intrusismo y la transferencia. Aquí tratas de ayudar a tus compañeros a realizar su labor mejor, aportándoles información sobre aquella cosa que investigaste en tu tiempo libre que puede que les venga bien. Intentas prestar atención a cuando tienen un problema o explican sus cosas para sacar información y poder preguntarles o participar en sus retos porque los tuyos te aburren y te has quedado sin ideas para hacerlos divertidos.
  7. Aprender del suicidio. Aquí ya se te acaban todas las ideas y procrastinas porque sabes cuánto tardas en hacer las cosas. Trabajas más rápido porque tienes más experiencia así que te permites decir que tardas lo mismo que antes para poder robar ese tiempo en cosas tuyas en las que sí te quedan ideas o para leerte esa librería que usas que te ha parecido interesante. Aprendes lo que sea porque eres un yonki y haces cualquier cosa con no trabajar porque te aburre demasiado y te deprime. Esto intentas hacerlo poco pero cuando estás mal simplemente te supera y te come.

Esas son las etapas.

Traté de hacer un poco de transferencia de conocimiento interna, mandé emails técnicos de cosas que había estado investigando (la entrada de las single page apps que hice es uno de esos emails reciclado) y obtuve muy poca respuesta así que me desanimé bastante.

Otras cosas que no me gustaban dentro de este apartado de la satisfacción personal son el product-driven-engineering o hacer las cosas para productizar o vender. Tío, es un departamento de I+D. Hay que innovar. Primero innova, el producto vendrá después.

Lo que acabó ocurriendo es que muchas cosas las hacíamos buscando aumentar la tasa de aceptación de los proyectos. Es decir, se buscaba justificar la existencia del departamento haciendo que la empresa viese que los proyectos que se hacían en nuestra unidad llegaban a producirse, a implantarse en producción. Casi ningún jefe está de acuerdo conmigo en que eso era un error. Puede que me equivoque, pero, independientemente de si me equivoco o no, a mí y a algún otro compañero eso nos parecía un error y una incomodidad suficiente como para dejar la empresa. Supongo que eso quiere decir algo.

Todas esas cosas me estaban creando un perfil de cómo me gustaría trabajar.

Tercero un tema laboral, que muy de puta madre pero no. Ya os dije que mi salario casi se duplicó desde el trabajo anterior, pero eso no quiere decir que estuviese bien pagado. Estaba pagado ligeramente por debajo de convenio, cosas que sólo se puede conseguir falseando tu puesto de trabajo, no quiero entrar en muchos más detalles porque es una historia que los que seguiréis este blog desde España seguro que ya conocéis porque habréis estado en una situación similar.

Sin salir de ese tema laboral, chorradas que te cambian la forma de entender la empresa: Le dices a tu jefe que necesitas otro tipo de teclado en lugar de esa puta mierda de logitech de teclas de feedback nulo o algún tipo de ayuda ergonómica y te dice que desde recursos humanos dicen que no pueden ni un euro cuando después de un tiempo se compran teclados de Mac a 50€ la pieza a cualquiera que tenga un Mac en la empresa, ya sean desarrolladores de iOS o jefes que sólo usan el ordenador para hacer putas presentaciones y responder emails mientras que tú lo pasas puto para navegar porque tienes un i3 del año de maricastaña (y no te digo compilando). For example.

Repito, son chorradas, pero chorradas que te abren los ojos. Tienes que estar agradecido de lo que tienes, pero no hay nada para ti más que lo que te pagan a fin de mes que además es menos de lo que te mereces. Es gracioso.

Luego te dicen que valores también que hay café, cocacola y galletas en la oficina. Y eso también es gracioso porque no hay fruta fresca y fisioterapia. Hay azúcar y cafeína. La gasolina del programador. La gasolina del infarto.

Otro tema es el horario que tampoco llevo muy bien. El trabajo era bastante creativo y me cuesta encajar mi creatividad dentro de lo que el horario me permite. Si estoy con el flow a las seis de la tarde me tengo que ir y si no me sale nada a las tres de la tarde me tengo que quedar tres horas a cagarla y tener que arreglarlo mañana. Eso es calentar la silla, presentismo laboral y es muy triste.

Fuera de todo lo malo a nivel laboral hay que decir que se cobraba al día (es muy cutre que haya que celebrar esto ¡Hola Irontec!) y que visto a grandes rasgos había bastante flexibilidad en horas de entrada (pero no en horas trabajadas al día), que estaba cerca de donde vivo y el ambiente laboral era muy bueno (luego vuelvo a este punto).

Cuarto punto. La ética. Este es el punto en el que más hincapié quiero hacer. Me fui porque lo que hacía no me parecía ético y porque me daba vergüenza. No puedo contar mucho porque firme unos papeles que blablablá. Cruzamos la línea roja, mi línea roja (la única que vale) y para evitar una situación desagradable en la que me piden algo y digo que no lo voy a hacer me fui. Ni siquiera iba a soportar que me lo pidieran. Ya me cuesta bastante dormir por las noches (dijo a las 2:04 de la mañana).

Es el punto más corto porque no puedo contar nada, pero no podía contribuir a eso.

No lo voy a marcar como un quinto punto pero la mierda de actitud de winner de la empresa, sus valores copiados de los de Amazon (todo un ejemplo a seguir), sus reuniones motivacionales con el superjefe niño rico sociópata que se las da de guay y sus putas cenas de empresa tipo cocktail me tocaban mucho los cojones y no las echo nada en falta. Nada de nada.

Prefiero ser pobre y eso es lo que he decidido hacer. Ahora mismo tengo 0 ingresos. Cero. Cobro cero patatero y mi dinero tampoco va a durar mucho tiempo.

Llevo un mes sin trabajar en la empresa y aunque estoy todavía en fase de negación, como si estuviese de vacaciones, me siento bien. Estoy tranquilo. Me sigue costando dormir por otras movidas pero ahora me puedo dedicar a mis cosas, cocino, descanso más, hago deporte, etc. Mi cuerpo está recuperándose.

Sí que os voy a decir que tengo ideas y cosas en marcha y os iré contando, que no me fui a ciegas, que no soy taaan tonto y que estamos en ello. Perdonadme si por el camino pongo algún link de donación pero necesito comer y toda ayuda es buena.

Os diré que todo lo que voy a hacer a partir de ahora es cambiar el mundo. Intentaré usar lo poco que sé para hacer de este mundo un lugar un poco mejor. Espero que esta aventura dure para siempre y contaminar a todos los que pueda con este germen que me ha convertido en un fracasado pero me ha llevado al lugar al que creo que tengo que estar.

Lo siento, lo siento mucho, pero no sirvo para lo que todo el mundo quería de mi. Ojalá no fuera así.

Ojalá no me diera vergüenza.


Como siempre, mi espacio para las cosas buenas.

Soy una persona emocional, no soy un robot como muchos creen, por eso escribo siempre este tipo de entradas.

He conocido a personas rematadamente imbéciles en esta etapa de mi vida, sí. Pero muy pocas y eran fácilmente eclipsadas por el resto de personas maravillosas.

Nunca os haréis una idea de lo que me duele no haber podido seguir allí con vosotros. No es un discurso de mierda de “todo lo que he aprendido”. Realmente es imposible explicar lo cómodo que llegué a sentirme y lo fáciles que hicisteis las cosas. Si fue más de un año y medio, creed lo que os digo, fue en su mayoría por vosotros. Sin vosotros no hubiese durado ni la mitad.

Me duele mucho pensar que mi egoísmo me ha hecho alejarme de teneros tan cerca.

Es lo único que echo de menos de trabajar ahí. Lo que estoy haciendo no es tan bonito si no tengo a nadie a con quien compartirlo. Me gustaría que estuvieseis aquí conmigo. Ojalá lo estemos de nuevo algún día. De verdad lo espero.

Menos mal que me quedas tú, reina. Escuchas mis mierdas y me animas en todo lo que se me pasa por la cabeza. Siempre incansable. El amor de mi vida. Ojalá el mundo fuera más como tú y menos como lo que es.

Me ha dolido esta entrada. Me ha dolido mucho. Os quiero a todos. Espero no defraudar en esto, o en lo otro. Pero sólo tenía vergüenza encima y no podía seguir viviendo así.

Ojalá esto despierte a otros.

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

Bueno pues.

Después de toda la espera toca ponerse a destripar el script del infierno que ya presenté aquí.

Aviso de que se me va a ir de longitud este post. Nada raro en mí.

Antes de nada deciros muy seriamente un par de cosas:

No está bien meterse con el trabajo de los demás. Este script lo ha hecho una persona. Por lo que veremos, seguramente no tendrá mucho conocimiento de GNU/Linux pero programa bastante limpio así que seguramente sea programador, posiblemente de Java (el programa está hecho en Java), cosa que hará bastante mejor que yo.

El objetivo de esto no es la burla, es el aprendizaje. Tanto el mío como el vuestro. No voy a clavar perfecto todo lo que comente aquí, igual que ocurre con todo lo que escribo en el blog, pero este es un lugar para la reflexión y el análisis positivo.

Escribo en clave de humor y vacilo a Osakidetza y a otros medios gubernamentales porque su labor es hacer las cosas bien (como la de todos) pero tiran de subcontrataciones chapuceras y no tienen un control real de lo que reciben a cambio.

Ni media broma al currela que se parte el lomo por una miseria en una consultora carnicera para hacer un script en un lenguaje que no forma parte de su curro.

Todo mi desprecio a las consultoras carniceras que sólo quieren que parezca que han hecho algo y ponen a cualquiera a hacer el trabajo y le presionan para que funcione y a todos los que contratan a este tipo de esclavistas y estafadores modernos.

Dicho esto, vamos a analizar el código. No sólo lo que esté mal (según mi criterio, ojo) si no que vamos a intentar fijarnos en el estilo y otras cosas. Veremos si lo consigo.

Aquí os dejo el script, pulsad para expandirlo. Lo dejo recogidito porque iré sacando pedazos más abajo, sólo está como referencia.

#!/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

Empezamos resumiendo un poco la labor del script. Básicamente, se encarga de arrancar un programa en Java con un conjunto de argumentos de entrada, toda la lógica sirve para buscar lo que veréis que se llama JAVA_HOME y comprobar la versión del Java que el usuario tenga instalado (VERSION dentro del script).

Los dos if principales (lineas 13 y 35) son los que aseguran esto. Ahora entramos en detalle pero antes una cuestión de estilo.

Podéis ver que el código está bien indentado (con tabs, pero bien indentado) y comentado. Con comentarios no muy anchos para que sean fáciles de leer. Por eso comentaba antes que me da la sensación de que el que lo ha escrito es programador, pero, por las cosas que veremos luego, no controla demasiado de la herramienta que está usando (que, por otro lado, es bastante cabrona y difícil).

Vamos a por esos if:

El primero, que comienza en la línea 13 es el if con lógica. Parte de la variable de entorno JAVA_HOME que suele indicar dónde está nuestra instalación de Java para ejecutar java -version (línea 16) y comprobar si la versión es más grande que la indicada en la línea 8.

# 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

Hasta aquí todo bastante bien. En detalle vemos como necesita diseccionar el resultado de java -version (lineas 16-18) pero tampoco sabría hacerlo mucho más bonito si fuera necesario.

En el if anidado vemos que para recuperar el JAVA_HOME nuevo corta el JAVA_EXE que él mismo ha creado antes (linea 23). No tiene mucho sentido, creo yo, recuperando el JAVA_HOME de más arriba era suficiente. Además lo recorta eliminándole los últimos 9 caracteres, que es exactamente lo que mide /bin/java, que es la parte que le ha añadido a JAVA_HOME antes para crear JAVA_EXE.

Yo ese if lo dejaría directamente así (líneas 19-30):

        if [ $VERSION -lt $REQUIRED_VERSION ] # -lt es less than
            JAVA_HOME=
        fi

Muchos ya os habéis dado cuenta de un par de detalles pero lo iré aclarando al final, no desesperéis. Si luego me olvido pues lo comentáis y listo.

Ese if no tiene mucha más chicha que eso, vamos al siguiente que es donde está la movida guapa.

# 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

El comentario ya lo dice todo.

Para empezar, usa locate, una herramienta que no viene por defecto normalmente. Cagada. Mejor usar find aunque sea más lento.

O mejor no usar, porque lo que hace es aún más cremas. Mirad la línea 39:

    for JAVA_EXE in `locate bin/java | grep java$ | xargs echo`

Ese for itera por todos ficheros del sistema que cumplen lo siguiente:

  • Contienen bin/java en su nombre
  • Terminan en java

El developer esperaba encontrar /usr/local/bin/java por ejemplo, pero con esa búsqueda también puede encontrar /home/user/projects/example_virus/bin/java_binaries/destroy_all_java, por ejemplo.

Lo divertido es que poco más abajo lo ejecuta, así porque él lo vale. Linea 45:

            VERSION=`$JAVA_EXE -version 2>&1 | head -1`

Repito más claro:

Este programa busca cosas casi aleatorias en tu sistema y las ejecuta para ver si su versión es correcta. Luego, si cumple, lo vuelve a ejecutar con un churro gigante de parámetros de entrada.

Si te encuentra algo que no es, lo va a disparar, sea malicioso o no.

Eso es lo más divertido de ese if, el resto es como el de arriba.

El bloque final es mucho más aburrido. Añade los parámetros de entrada que le metamos en la ejecución a unos que permite que le metas por defecto hardcoded (lineas 59-68) y ejecuta el programa haciendo mil jueguecitos que tiene pinta que sean muy necesarios.

Un par de cosas generales:

No entiendo para qué se necesita volverse loco con la puta variable JAVA_HOME. Si el usuario no es idiota y tiene todo bien instalado con llamar directamente a java es suficiente porque estára en el PATH y listo. Si realmente se necesitase setear la variable para algo interno del programa, con buscar dónde está ese binario sería suficiente, de nuevo, tirando del sistema se puede hacer con un whereis.

Es absurdo porque tras nosecuantísimo procesamiento para buscar la versión y la localización de Java en mi sistema, fue incapaz de localizar el OpenJDK, que sí que es capaz de lanzar el programa con éxito. Esto ocurrió porque en el parseo de las versiones utiliza un formato que es específicamente el que da Java, OpenJDK pone otra cosa diferente aunque parecida:

openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.04.2-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

A parte de todo esto, cuando decía que el programador no controla mucho de Bash es porque le veo muchos detalles en los que se nota que no tiene mucha experiencia con la herramienta. Por ejemplo, tiene ifs vacíos porque necesita el else cuando con negar la condición sería suficiente. El uso del locate en lugar de otras herramientas también puede dar una pista.

En general, el programa parece que está copy-pasteado de Stack Overflow. Cosa que todos hacemos, pero a algunos se les nota más que a otros.

🙂

Conclusiones:

  • No ejecutéis todos los ficheros del sistema. Si el usuario no tiene las cosas bien configuradas que le den por el culo. Es mejor eso que ponerse a ejecutar cosas aleatorias que a saber lo que hacen.

  • No seáis tan locos con las versiones porque eso os puede llevar al caso anterior.

  • Si sólo tenéis código para meter en el else quizás negar el if sea la solución más elegante. man [ para que os cuenten un poco de qué va el rollo.

  • Intentad evitar usar programas que no estén por defecto en el sistema. locate vs find. Y, a poder ser, no busquéis porque puede que caigáis en el caso 1.

  • Todos hemos trabajado en una herramienta en la que estamos un poco cojos, está bien buscar en internet, pero no está de más investigar un poco más si las fechas de entrega te lo permiten.

  • Bash es más feo que una nevera por detrás, pero es útil a veces.

  • No trabajes en una consultora cárnica si lo puedes evitar. Intenta cambiar el mundo en otro tipo de trabajos más sociales o éticos. Esos cabrones no te merecen. Es difícil pero lo puedes conseguir.

En fin.

Ya comenté en la primera parte la solución rápida que le metí al script, dejo en vuestras manos una más elaborada.

Un abrazo. Como siempre.

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!

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. 😀