LiteIDE: mi IDE preferido para Go

Después de probar y estudiar Go (aka Golang) desde el día que nació sobre el 2009, he vuelto a retomarlo para el desarrollo de pequeños proyectos web/API. Me ha empujado a volver a usarlo la constante mención sobre Go en Hacker News. Raro es el día que no aparece una empresa o start-up que ha empezado a usarlo para bajar la factura de servidores y watios.

En su día analicé algún que otro IDE para Go que estaba interesante.

Lo cierto es que hoy en día Go ha evolucionado mucho y lo mismo ha ocurrido con los IDE asociados.

De entre todos lo que he probado (Goclipse, Go-IDE y LiteIDE) me quedo con LiteIDE.

Las razones son:

  • Cross-platform (GNU/Linux, Windows y Mac OS X)
  • LGPL
  • Modular
  • Sencillo
  • Ligero
  • Integra perfectamente el entorno (algo particular) de Go.

 

Ahora queda empezar a hacer Apps Go-fabulosas 🙂

 

[TIP] Formatea la salida JSON de CURL

Si estas acostumbrado a trabajar con JSON, backends y demás palobrotos seguro que habrás usado cURL para obtener paquetes JSON.

La salida que cURL da no viene formateada, simplemente la muestra tal y cómo el backend lo devuelve.

Si el paquete que esperas tiene un cierto tamaño, esto puede ser un poco lioso.

El módulo de Python json tiene una utilidad para formatear JSON, luego me he creado una función BASH que añado a mi .bashrc y que me ahorra fallos y dolores de cabeza.

function jcurl() { curl $@ | python -m json.tool; }

Para añadir esta función a tu .bashrc

 echo "function jcurl() { curl \$@ | python -m json.tool; }" >> ~/.bashrc

Quirks del kernel Linux

Lo primero, ¿sabes lo que es un “quirk“?  Según el traductor, tiene varias acepciones como capricho o peculiaridad. Es esta última acepción de la que vamos a hablar.

Linux tiene código “quirk” (peculiaridades) para ciertos dispositivos concretos.

Esto se debe a que hay muchos dispositivos que aunque tienen funcionalidades en común, incorporan “peculiaridades” que deben ser tratadas para explotar al máximo el dispositivo. Un ejemplo claro son los teclados con teclas multimedia o esos joysticks enormes que se emplean en los simuladores de vuelo.

Os voy a poner un ejemplo con un dispositivo de interfaz-humana (HID) al que vamos a intercambiar la funcionalidad de dos de sus teclas.

Como sabéis, cada dispositivo USB tiene asociado un par de códigos que representan un código unívoco de producto (identificador de fabricantes e identificador de producto). Cuando un dispositivo HID USB se conecta al sistema, el kernel busca si tiene asociado algún quirk, y si procede, aplica el “remapeo” de eventos.

Un fragmento de hid-belkin.c para un teclado Belkin.


static int belkin_input_mapping(struct hid_device ∗ hdev, struct hid_input ∗ hi, struct hid_field ∗ field, struct hid_usage ∗ usage,unsigned long ∗ ∗ bit, int  max)
{
unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);

    if ((usage >hid & HID_USAGE_PAGE) != HID_UP_CONSUMER || !(quirks & BELKIN_WKBD))
          return 0;
    switch (usage >hid & HID_USAGE) {
          case 0x03a: belkin_map_key_clear(KEY_SOUND);
          case 0x03b: belkin_map_key_clear(KEY_CAMERA);
          case 0x03c: belkin_map_key_clear(KEY_DOCUMENTS);
          default:
          return 0;
    }
    return 1;
}

¿es fácil de entender no? El código “mapea” tres eventos distintos a los códigos de kernel correspondientes a las teclas KEY_SOUND, KEY_CAMERA y KEY_DOCUMENTS.
Esta función de “mapeo” se ejecuta después de que la función “probe” del driver sea positiva y se haya obtenido la tabla de usos del dispositivo USB HID.
Dicha función de “mapeado” se aplica para cada uno de los códigos que reporte el dispositivo. Si os fijáis, cuando se produce un intercambio el código de retorno es 0.
Se devuelve 1 si no hay alteración (como puede ser el caso de la tecla ‘a’).

Si tenéis curiosidad veréis en que en todo el kernel hay numerosos “quirks” a todos los niveles.

 

Cómo instalar una aplicación Django en OpenShift

OpenShift es la plataforma PaaS de Red Hat. Aunque este post trata sobre consejos y experiencia de instalar una app de Django, hay que decir que OpenShift está actualmente montado sobre Amazon Web Services y que utiliza el concepto de recurso (gear o cartucho).  Un “cartucho” puede ser una aplicación web, una base de datos MySql, una instancia de memcached, etc. La cuenta gratuita permite tener 3 cartuchos. La idea es que si tu solución necesita escalar, fácilmente se puede añadir nuevos cartuchos bajo demanda.

Aquí os presento algunos tips o problemas con los que me he encontrado:

  • Lo primero es instalar el toolkit de OpenShift, rhc. Se trata de un script Ruby con el que se puede crear aplicaciones, ver logs, acceder via SSH etc. Se instala con “gem install rhc”. A mi me dio un error al instalar parte de la documentación pero funciona sin problemas.
  • La primera vez que se ejecuta rhc nos pedirá los credenciales de OpenShift (login/password) y permite crear y subir una clave pública de SSH para acceder sin tener que recordar clave alguna.
  • Para acceder vía SSH, ejecutamos “rhc ssh <app>“. Esto llama a SSH utilizando la clave pública. Como usuario, se utiliza un string-ID bastante largo. Al acceder nos situa en el “home” virtualizado: /var/lib/openshift/<UserID>. En ese directorio aparecen los componentes principales de tu aplicación. Para una aplicación Django son: app-root, git y python. La mayoria de los directorios son de sólo lectura. Solo en $HOME/app-root/data, $HOME/app-root/repo y algún que otro directorio podemos escribir.
  • Si necesitamos instalar algún componente Python, deberemos de ejecutar el script de Virtualenv. Esto se hace con “source $HOME//python/virtenv/bin/activate”. Luego ya llamaos a “pip install <paquete>“.
  • En caso de tener que copiar algo vía SCP, deberemos tener cuidado de que el directorio destino tenga permiso de escritura. Esta seria una sintaxis válida “scp <fichero> <userID>@<app>-<cuenta>.rhcloud.com:/var/lib/openshift/<userID>/app-root/data“.
  • El entorno de OpenShift establece un número grande de variables de entorno que será de gran utilidad para configurar tu aplicación. Todas comienzan por “OPENSHIFT_”. Por ejemplo OPENSHIFT_APP_DNS nos da el host,  OPENSHIFT_REPO_DIR el directorio donde se ubica el repositorio o OPENSHIFT_PYTHON_LOG_DIR donde se encuentran los logs de Apache.
  • El equivalente a “service httpd restart” es “ctl_app restart“. Lo utilizaremos cada vez que hagamos algún cambio en la aplicación.
  • La mejor forma de enlazar nuestra aplicación con wsgi es fijarnos en el ejemplo que viene. Apache ejecuta $HOME/app-root/repo/wsgi/application para cada request. Este script prepara el entorno de virtualenv e invoca al manejador wsgi de Django. Debemos ajustar los paths y nuestro “project.settings”.
  • Lo más normal es que durante la instalación de nuestra app nos encontremos con errores tipo 500. Con “rhc tail”, veremos los logs de Apache.
  • Los contenidos estáticos deben ir a $HOME/app-root/repo/wsgi/static, luego debemos configurar correctamente la variable STATIC_ROOT para que apunte al path correcto dentro de settings.py.
  • Si nuestra aplicación usa base de datos, se recomienda la ubicacion $HOME/app-root/data, ya que $HOME/app-root/repo se destina al repositorio de código.
  • Es posible tener una configuración especifica según el entorno de ejecución mirando las variables de entorno. En el ejemplo que viene por defecto, se crea una variable booleana ON_OPENSHIFT dentro settings.py que se usa para determinar la ubicación de la base de datos sqlite3.
  • Si queremos obtener la IP de aquellos que nos visitan, tenemos que usar el meta “HTTP_X_FORWARDED_FOR” en lugar “REMOTE_ADDR”.
  • Por último, si queremos asociar un CNAME a nuestra app, usamos “rhc alias <app> <cname>” para crear dicho alias (imagino que añadirá un ServerAlias a la configuración de Apache).

Sin duda OpenShift es de las plataformas más económicas (o gratis) de hospedar un proyecto Django. Muy recomendable para aplicaciones inicialmente pequeñas o prototipos.

 

Ubuntu Edge, la era PC-in-phone a 32 millones de dolares de distancia

 

Ubuntu se ha lanzado a esto del crowdfunding para traer a un nuevo concepto de gadget a la vida: el “pcphone“.

Imagina llegar a tu puesto de trabajo con tu “pcphone”, conectarle teclado y pantalla y ponerte a trabajar con Ubuntu. Se trata pues de un smartphone hipervitaminado que es capaz de correr un sistema operativo de escritorio como Ubuntu si nada que envidiar a los PC convencionales.

Para convertir este sueño de Mark Shuttleworth en realidad, ha optado por hacer en crowdfunding en Indiegogo por valor de 32 m$ (casi nada).

De conseguirlo, además de “reinventar el teléfono“, habrán batido un récord de recaudación.

La realidad es que a día de hoy llevan unos 7 m$ y faltan unos 24 días… complicado lo tienen.

Esta experiencia servirá para saber si este concepto de Ubuntu tiene cabida en el mundo actual y a qué precio (parece que los $825 de su precio objetivo esta lejos de lo que el consumidor quiere/puede pagar).

Espero la mayor de las suertes para este proyecto pero francamente creo que lo tienen complicado: producto poco definido, necesidad de mucha financiación, dudas sobre si Ubuntu podrá hacerlo, …

En 24 días sabremos si habemus “Ubuntu Edge” o no.

Red Hat Tour 13 Madrid

Red Hat Tour 2013 Madrid en el Santiago Bernabéu

Red Hat Tour 2013 Madrid en el Santiago Bernabéu

El pasado día 16 de Abril tuvo lugar el Red Hat Tour 13 en Madrid. En esta ocasión no se celebró en el típico hotel de turno, sino que se desarrolló en todo un monumento vivo de la Villa de Madrid, el estadio Santiago Bernabéu.

Este evento que se celebra cada año y medio aproximadamente tiene como título “Transform your IT“. En líneas generales viene a presentarnos lo último que los chicos de Red Hat  y sus patners (HP, Bull, Intel, Fujitsu, etc) están trabajando, sus apuestas de futuro inmediato y los casos de éxito.

El tema diagonal de todas las charlas fue el cloud computing. Siendo un poco más específico, los términos que más aparecieron en las distintas sesiones fueron “cloud abierta, cerrada e híbrida”.

Yo soy de los que piensan que esto del “cloud” no es más que un producto de marketing asociado a dos viejos conocidos: red y virtualización.

Según Wikipedia, una nube privada no es más que una nube destinada a ser explotada por una organización. De todos los casos de nube privada que presentaron, el que más me llamo la atención fue el renderizado de películas 3D de DreamWorks. Antes de la nube, ellos tenían montado un IT propio que era muy caro de mantener y encima no daban a basto cuando querían producir una película (según dijeron tardarían 7.000 años para hacer el  renderizado en un solo PC de alta gama). Lo peor de esto es que cuando no había película que renderizar, el sistema estaba ocioso. Así fue como acudieron a los servicios de consultaría de Red Hat y apostaron por la nube para reducir drásticamente el precio y conseguir sacar las películas según la planificación.

Para Red Hat las ventajas de una nube open source son claras: escalabilidad, velocidad y no lock-in. En entornos cada vez más competitivos con menor presupuesto y mayor exigencia, poder lanzar una solución rápidamente, hacer que escale según la demanda para no desperdiciar ningún recurso y que puedas seleccionar qué proveedor te va dar solución para según qué subsistema sin problemas de dependencia se convierte en un “must“.

De los pocos productos hardware que se vieron, me llamo la atención el HP Moonshot. Se trata de un nuevo concepto de rack que puede albergar hasta 45 unidades de lo que denominan “cartuchos”. Un cartucho puede ser una CPU, un disco SSD, un servidor NAS o incluso una FPGA. Para mi es el mejor “mapeo” de la nube en una nube física.

Respecto a las nuevas tecnologías open en las que Red Hat y sus patners están trabajando, destacaría OpenStack  (“el sistema operativo de la nube”). El objetivo es estandarizar la gestión de nubes públicas, privadas e híbridas. Esto viene muy bien para la interoperatividad entre proveedores de cloud.

Un nuevo servicio que me gustó especialmente fue OpenShift (el nombre no es muy acertado, esperemos que funcione bien). Este servicio es un PaaS de Red Hat que te permite  alojar una aplicación en el cloud abierto de Red Hat. Es insultantemente rápido hacer un deployment de un aplicación alli. Me registré y con dos click tenia andando un WordPress a estrenar. Lo mejor de todo es que hay un plan gratuito, luego se puede tener un WordPress totalmente modificable pero como si estuviera alojado en WordPress.com. Una pasada.
El principal problema que le veo a OpenShit es que hoy en día corre sobre Amazon Web Services (IaaS). Además de esto, todavía no admite SSL para tu dominio (tiene un SSL wildcard para *.rhcloud.com)

Para (casi) terminar, decir que he echado en falta la ausencia de ARM como alternativa a la arquitectura x86 para servidores y que no me cabe duda que le quitara cuota de mercado. Ya existen proyectos amateurs de cluster y supercomputadores que tienen el tamaño de una tarjeta de crédito que usan ARM como CPU. También brillo por su ausencia el término “mobile”, lo cual deja claro donde se posiciona Red Hat, dejando a distribuciones como Ubuntu que experimente en ese difícil terreno.

Por último, felicitar a Red Hat por el gran evento que ha organizado. El contenido de las charlas, el desempeño de los ponentes, el timing, la ubicación, etc estuvo muy a la altura.
¿dónde será el próximo Red Hat Tour 15? ¿Las Ventas? 🙂

Face Alt, a Face alternative SaaS to detect faces in pictures in Beta

On July 7th I received an email from Face.com  where they said that their API will be off in 30 days.

That sucks! 

The reason of my anger was that Face.com provides a great free SaaS to detect and recognize faces in pictures and I and thousands of developers around the world use their API to run our applications. “Face” was acquired by Facebook a month ago and it seems that Facebook now only have access to this API.

I saw then clear: I will create a new open source alternative service. We’ll call Face Alt (http://face-alt.org).

After a hard week of work during free time, the Face Alt Beta is now online!

The main features of Face Alt are:

  • It’s open source. The repository is in GitHub. It uses the great open source library OpenCV.
  • Initially only been implemented frontal face detection. We use the Haar Cascade classifier. We need to improve the detection ratio.
  • Face recognizer will be availble soon. Probably we will use cv::FaceRecognizer (included in OpenCV). This library implements the Fisherface algorithm. Developed by Philipp Wagner.
  • Detection of gender or face attributes will be added using Fisherface too (probably)
  • Detection of rotated faces is under study.
  • If you want collaborate with us, join us in our google group: face-alt.
  • API is restricted to 100 requests per day maximum
  • JavaScript API library available. Python, Ruby, Java,C#…coming soon!

If you want to enter in the beta program, sign-up here.

About the SaaS implementation, we use a AWS server instance configured with nginx connected via FastCGI with a native C++ face detector implementation.

Finally, say we are looking for collaborators, if you like this exciting field of computer vision, come with us!

See you 🙂