Viricmind Labs

Este año el Concurso Universitario de Software Libre vuelve a la carga (esta es ya su sexta edición). Yo me presento por enésima vez, a ver si por fin consigo acabar lo que empiezo (sí, quiero acabar, no ganar).

El proyecto que presentaré se llama Litipk, y a mi entender será mucho más modesto y humilde que las barbaridades que "intenté" en las otras ediciones del concurso. Evidentemente eso hace que tenga menos posibilidades de ganar debido a la falta de innovación, pero mi gran propósito es ofrecer algo a la comunidad que pueda empezar a resultar útil a corto plazo.

¿Qué "será" Litipk?

Litipk "será" una aplicación web dirigida a facilitar la búsqueda, catalogación y compartición de material didáctico online, haciendo especial incapié en el aspecto social y comunitario. Mi deseo es conseguir que la gente se ayude mutuamente a la hora de intentar aprender .

¿Por qué Litipk?

Desde hace tiempo la red se está llenando de cursos, tutoriales, vídeos, libros y muchos otros recursos didácticos o formativos. Quien quiere aprender puede hacerlo sin demasiados problemas, pero eso sí, probablemente perderá un tiempo precioso buscando material, tiempo que podría ahorrarse si facilitamos un poco las cosas .

Por otro lado, hay un factor importantísimo que me ha motivado a decidirme por este proyecto: la crisis económica. Cada día vemos más recortes en el sector de la educación, ya sea en educación primaria, secundaria obligatoria, bachillerato, formación profesional o las mismas universidades.

Hay muchos potenciales estudiantes que no han podido encontrar plaza allí donde creían oportuno formarse, y otros simplemente no tienen la posibilidad económica de costearse los estudios. Y aunque eso ya debería ser suficiente, pues la educación y la formación tienen valor por sí mismas, es importante destacar también que la economía depende fuertemente de la formación de la ciudadanía. Es por eso que pensé en aportar mi pequeño granito de arena.

Algunos apuntes más

Litipk será desarrollado en CoffeeScript , haciendo uso de NodeJS y una buena lista de librerías y microframeworks libres. Tengo que admitir que a nivel técnico no es una decisión demasiado acertada, es cierto que puedo conseguir resultados espectaculares en cuanto a rendimiento, pero también lo es que trabajaré el doble para conseguir lo que podría hacer con Symfony2 o CakePHP. Sea como sea mi decisión está tomada, y lo que me ha motivado a tomar este rumbo es mi tendencia a probar cosas nuevas .

Respecto al blog, esta vez he decidido no crear un blog aparte para el proyecto. Todas las entradas estarán en mi blog personal, Viricmind Labs, pero bajo la etiqueta Litipk. Lo hago así para evitar dispersar demasiado mi atención y poder controlar mejor el histórico de mi trabajo.

Para finalizar, quiero decir también que Litipk ya tiene algo parecido a un logotipo , se trata del robot que podéis ver en este mismo artículo. El dibujo es obra de Cristina Pérez (aunque yo la llamo Pistacho), y está licenciada bajo Creative Commons 3.0 By-Sa .

Como dije en el anterior artículo sobre Nodejs, en este haré una introducción al lenguaje CoffeeScript.

CoffeeScript está diseñado para ser compilado a JavaScript, y parece estar basado en lenguajes como Python o Ruby. Mi empeño en explicar CoffeeScript antes de continuar con la guía de Nodejs radica en que probablemente voy a usarlo con asiduidad. Me gusta Nodejs... pero no me gusta Javascript.

Reconozco que JS es un lenguaje que obliga a pensar de manera diferente, y que en cierta manera le obliga a uno a lucir su ingenio cuando quiere crear código mínimamente interesante, pero a la vez me parece agobiante su falta de "limpieza" y la gran cantidad de construcciones "adhoc" que existen para poder trabajar siguiendo el paradigma OOP.

Empecemos con un ejemplo sencillo, transformaremos el "Hello world" que realizamos anteriormente en Javascript para Nodejs a código CoffeeScript. En primer lugar presentaremos el código que ya escribimos para usarlo de base:

1
2
3
4
5
6
7
8

var http = require('http');
 
http.createServer(function (req, res) {
	res.writeHead(200, {'Content-Type': 'text/plain'});
 	res.end('Hello Worldn');
}).listen(1337, "127.0.0.1");
 
console.log('Server running at http://127.0.0.1:1337/');

En segundo lugar, veamos como debería ser su equivalente en CoffeeScript:

1
2
3
4
5
6
7
8

http = require "http"
 
http.createServer((req, res) ->
  res.writeHead 200, {"Content-Type": "text/plain"}
  res.end "Hello Coffee!!\n"
).listen 1337, "127.0.0.1"
 
console.log "Server running at http://127.0.0.1:1337/"

Intentemos analizar las particularidades de este código. Podemos observar en la primera línea que no es necesario declarar las variables con la palabra reservada var, y que además las funciones son llamadas escribiendo sus parámetros después de sus nombres sin tener que rodearlos con paréntesis, un espacio basta. En la línea 4 podemos ver que cuando hay más de un parámetro estos deben separarse con comas.

Otro punto interesante es la no necesidad de punto y coma final, lo que puede ayudarnos a evitar algún que otro error tonto. Sigamos, pues hay una particularidad que podría darnos algunos dolores de cabeza si no caemos en la cuenta: en la línea 3 podemos ver como se llama a una función usando paréntesis, contrariamente a lo que había indicado antes. Esto solo se puede hacer si los paréntesis están pegados al nombre de la función.

Si hubiera un espacio entre createServer y el paréntesis, entonces se consideraría como parámetro no lo que hay dentro del paréntesis, sino el resultado de la llamada al  método listen (CoffeeScript creería que ese método pertenece al objeto retornado por el interior de los paréntesis).

Respecto a las funciones anónimas en CoffeeScript, estas se declaran de una forma que puede extrañar un poco, pero que para nada es complicada. Las funciones en CoffeeScript tienen estructuras como las que siguen:

1
2
3
4
5

funcionA = (param_1, param2) -> param_1*param_2
 
funcionB = (param_1, param_2) ->
    alert param_1
    param_1*param_2

Es decir, se indican los parámetros que aceptará dentro de un paréntesis, y el cuerpo de la función se escribe después de la flecha formada por el guión y el "mayor que". El último valor calculado se tomará como valor de retorno, y tal como pasa en Python, la identación es importantísima para definir el ámbito de las instrucciones. CoffeeScript tiene muchas otras características (bastante más) interesantes pero creo que será mejor que quien esté interesado las aprenda directamente de su sitio oficial .

Para acabar, veamos como se transforma este código nuevamente a Javascript para poder ser ejecutado por Nodejs o aplicado directamente en la parte del cliente de alguna aplicación web que estemos desarrollando. Antes será preciso instalar el compilador de CoffeeScript, y para ello usaremos NPM, como indiqué en el anterior artículo. Realizar la instalación es tan sencillo como teclear en la línea de comandos:

1

sudo npm -g install coffee-script

La opción -g sirve para indicarle a npm que queremos una instalación "global", que el compilador coffee sea accesible desde todo el sistema. Ahora, suponiendo que hayamos llamado ejemplo.coffee a nuestro código, para compilarlo a Javascript solo tenemos que escribir en la línea de comandos:

1

coffee -c ejemplo.coffee

Y obtendremos un fichero llamado ejemplo.js apto para ser ejecutado en Nodejs . Podéis comprobar como el código obtenido será ligeramente diferente a nuestra primera versión escrita en Javascript, ya que estará contenido dentro de una función autoejecutable. Si queréis, también podéis hacer el experimento de poner un espacio entre createServer y el paréntesis para comprobar lo que os he dicho anteriormente. Bien, esto es todo por hoy ^_^ , otro día más.

No se puede decir que sea fan de Ubuntu (ni de ninguna otra distribución Linux), pero la verdad es que por lo general lo he estado prefiriendo durante los últimos años. Lo que ha hecho que prefiera Ubuntu por encima de otras distribuciones ha sido básicamente que está basada en Debian, usaban Gnome por defecto y han apostado decididamente por la simplicidad.

Pero... últimamente me estoy mosqueando. En primer lugar, Unity llegó 6 meses antes de lo que debería. Tengo que decir que adoro la característica del "global menu" que me permite aprovechar al máximo el tamaño de la pantalla, pero la lentitud general del entorno y la poca configurabilidad es desesperante, eso sin mencionar el caótico panel, que dificulta enormemente encontrar aplicaciones de forma rápida.

No he dicho nada nuevo hasta ahora, si fueran estas mis únicas quejas ni me habría planteado escribirlas. Pero hay más, y "nuevo". Aunque el primer defecto que mencionaré es de la versión 11.04 y no de la 11.10 creo que debe ser explicado.

1. En Ubuntu 11.04 solía pasar que, de haber varios usuarios, multitud de veces GDM (la pantalla de login) sólo mostraba uno de ellos, el primero que se creó. No han llegado a solucionarlo nunca... en parte lo entiendo (iban a abandonar GDM en la próxima versión en pos de LDM, y el equipo de Gnome estaba trabajando en otra versión de GDM más nueva, dedicar esfuerzos a eso no resultaba rentable), pero no deja de ser frustrante.
2. En Ubuntu 11.10 hay problemas parecidos, pero peores. No sé si solo me pasa a mi pero... si salgo de mi sesión sin cerrarla y vuelvo a entrar en ella (sin haber entrado en ninguna otra antes) entonces el equipo queda "colgado". Lo único que obtengo es una pantalla negra, no puedo ir ninguno de los terminales y lo único que se puede hacer es reiniciar. Podría ser que tuviera que ver con mi tarjeta gráfica (es una ATI), aunque la verdad es que me importa poco. Eso nunca había pasado, y es un fallo prácticamente imperdonable.
3. Otro error que me ha dado muchos problemas (tanto en la versión 11.04 como en la 11.10) es el de las firmas de los repositorios. Por alguna extraña razón pasa que cada dos por tres tanto apt como aptitude me indican que las firmas de los paquetes son incorrectas (suele pasar en días que ciertos servidores de Ubuntu parecen colapsados). En general este error no debería causar problemas excesivos, le indicamos al sistema que instale el nuevo software aunque los paquetes no estén bien firmados... y listos. Ahora bien, eso se puede hacer desde la línea de comandos, pero no desde el entorno gráfico, lo que implica que los más perjudicados son los novatos (precisamente a los que Ubuntu se dirige en teoría).

Dicho esto, espero que para la versión 12.04 le den un repaso a todos estos incordios y los hagan desaparecer. Lo cierto es que probablemente me quede con ella durante unos años, tengo necesidad de estabilidad... al menos por un tiempo. Y lo vuelvo a decir, me he enamorado de la característica del "global menu", y estoy dispuesto a tragar Unity solo por eso (tampoco lo sufro mucho porque uso Synapse como lanzador).

Estos días estaré experimentando con Nodejs y aprocecharé para escribir un poco sobre mi aprendizaje en el blog. Nodejs es primo-hermano de herramientas como Twisted o Tornado, pero escrito mayoritariamente en Javascript y no en Python, y que aprovecha toda la potencia de la máquina virtual V8 que adquirió Google para su navegador Chrome, que no es moco de pavo . Empecemos pues!

Instalación de Nodejs

En todo momento presupongo que estamos trabajando sobre Linux y que tenemos instaladas ciertas herramientas básicas de desarrollo: compiladores, make, python, y la biblioteca libssl-dev. En caso de que nos falte algo no creo que suponga ningún impedimento, normalmente el sistema nos indicará qué nos falta y la instalación por lo general se podrá hacer a través de los gestores de paquetes más usados: apt-get, aptitude, yum y alguno que otro más.

En primer lugar descargaremos el paquete de código fuente estable (a día de hoy es la versión 0.4.12, del día 15 de Septiembre de 2011), lo descomprimimos y entramos desde la línea de comandos en el nuevo directorio creado tras la descompresión. Allí debemos ejecutar los siguientes comandos:

1
2
3

./configure
make
sudo make install

¿Ya está? No, casi... Nos falta NPM, el gestor de paquetes de Nodejs que nos facilitará la vida (aunque no es imprescindible por el momento).

Instalación de NPM

Para instalar NPM nos "arriesgaremos" a usar la versión disponible en su repositorio Git oficial... y es que no hay ninguna versión "estable" por el momento. Así que, evidentemente, tendremos que tener instalado git en nuestro sistema.

Lo primero que tenemos que hacer es teclear lo siguiente en la línea de comandos:

1

git clone git://github.com/isaacs/npm.git

Seguidamente debemos entrar en el nuevo directorio creado y ejecutar la siguiente orden:

1

sudo make install

Como podemos ver el proceso no tiene nada de complicado , puede que fuera preferible usar los acostumbrados gestores de paquetes... pero la comodidad que nos aportan tendría que pagarse con una falta importante de actualización, y más teniendo en cuenta el temprano estado de desarrollo de estas piezas de software y la cantidad de cambios que se suceden constantemente en ellas.

Bien, pasemos a la acción, vayamos a crear nuestra primera aplicación basada en Nodejs! El código es bastante simple y se entiende perfectamente, aunque en cierto modo puede asustar un poco porque un simple "Hello World!" es algo más complicadillo que si lo hiciéramos directamente en PHP. Podemos llamar al fichero ejemplo.js .

1
2
3
4
5
6
7
8

var http = require('http');
 
http.createServer(function (req, res) {
	res.writeHead(200, {'Content-Type': 'text/plain'});
 	res.end('Hello World\n');
}).listen(1337, "127.0.0.1");
 
console.log('Server running at http://127.0.0.1:1337/');

Como podemos observar el código debe tener en cuenta incluso las cabeceras HTTP, pero no hay que preocuparse, en artículos posteriores veremos como gracias a un gran conjunto de librerías y microframeworks el trabajo con Nodejs puede llegar a ser incluso divertido (y nos serviremos de NPM para cargar esas librerías de forma sencilla). Por cierto, para ver el resultado en el navegador deberéis visitar la dirección http://127.0.0.1:1337/ tal y como indica el propio ejemplo a través de la línea de comandos.

Como segundo avance de lo que veremos en los próximos artículos, entre otras cosas revisitaremos el primer ejemplo mencionado, pero esta vez escrito en Coffeescript, un lenguaje similar a Python (y por lo tanto mucho más agradable que Javascript) que generalmente se compila a Javascript.

Tiempo atrás había un detalle que no soportaba de Wine, que los iconos de las aplicaciones para Windows que se ejecutaban con Wine no aparecieran en la barra de tareas cuando éstas eran lanzadas.

Parece que con Unity y las nuevas versiones de Wine (estoy usando la rama 1.3, que actualmente está en fase Beta) la cosa ha mejorado un poco y con un poco de maña podremos eludir el problema que acabo de mencionar .

Por ahora, cuando ejecutamos directamente las aplicaciones de Windows bajo Wine sigue apareciendo el ya conocido icono del emulador, una copa de vino rosado. No digo que sea feo, pero si de verdad queremos saber qué se está ejecutando puede llegar a ser molesto que solo podamos ver esa imagen genérica. Ahora bien, como dije, hay un rodeo!

Empecemos, supongamos que estamos instalando el programa windowsero del que queremos conservar su icono. Lo primero que debemos hacer es, cuando el instalador nos pregunte sobre ello, indicarle que sí queremos accesos directos en el escritorio. Una vez acabada la instalación podremos ver que en el directorio de nuestro escritorio han aparecido 2 nuevos archivos, uno con extensión .lnk y otro con extensión .desktop.

El archivo con extensión .desktop probablemente se verá en el escritorio o en nuestro gestor de ficheros con el icono del programa que hemos instalado. Podemos vernos tentados a arrastrarlo hacia la barra de Unity, y funcionará, queda bien fijado. De hecho, es incluso mejor, si hacemos click sobre él una vez está en la barra de Unity veremos como se ejecuta el programa recién instalado.

Ahora bien, hay un pequeño problema. Si eliminamos los ficheros del escritorio porque molestan (en particular el que tiene extensión .desktop, el de la extensión .lnk no importa) automáticamente desaparecerá también el lanzador de la barra de Unity . La solución es sencilla, copiamos el fichero .desktop en el directorio donde fue instalado el programa para Windows (/home/usuario/.wine/drive_c/Archivos de Programa/NombrePrograma/), y una vez hecho esto, arrastramos el fichero a la barra de Unity como se hizo en el caso anterior.

Es importante que cuando arrastramos el lanzador a la susodicha barra lateral lo hagamos ya desde el directorio donde lo dejaremos, si lo hacemos desde el escritorio y luego movemos el archivo... el lanzador desaparecerá otra vez.

Para casos complicados: Cuando no tengamos a mano ningún fichero con extensión .desktop podemos recurrir a procedimientos algo más sofisticados, os dejo un enlace por si os hiciera falta:

• http://www.ubunturoot.com/2011/05/how-to-add-windows-wine-apps-to-unity.html