Mostrando entradas con la etiqueta herramientas. Mostrar todas las entradas
Mostrando entradas con la etiqueta herramientas. Mostrar todas las entradas

Aparta, Javascript. Llega... ¡DART!

Dos añitos se ha tirado la plataforma Dart de Google para conseguir alcanzar la suficiente estabilidad tanto en el lenguaje como en las librerías y herramientas, como para llegar a su primera versión estable, la versión 1.0, cuya salida según el equipo de desarrollo es inminente.

¿Y qué demonios es Dart?. Pues la forma más rápida de definirlo es que es un reemplazo de JavaScript. Un reemplazo que pretende aprovechar las virtudes de JavaScript, y a la vez superar sus defectos. Esto lo hace especialmente interesante cuando lo que se pretende desarrollar es una aplicación web (o de forma más general, un "rich client"), es decir, una aplicación con interfaz web y con mucho código en la parte cliente. No obstante, si pensamos más allá nos podemos dar cuenta de que sus posibilidades son aún mayores.

Te estoy viendo. Tienes serias dudas. ¿Cuántas veces te han vendido la moto del enésimo lenguaje de moda que todos deben usar porque es el más bonito e indudablemente el mejor, para finalmente darte cuenta de que no tenía nada especial y era lo mismo de siempre o, incluso, mucho peor?.

Lo cierto es que Dart cubre un hueco, tiene un propósito. Hoy por hoy no hay otro igual o del mismo estilo.

¿No me crees?. Sigue leyendo, a ver qué piensas al final del artículo...

Pero... ¡yo amo Javascript!

El bueno
JavaScript tiene indudablemente algunas virtudes. Es un lenguaje con un buen manejo de prototipos y con la posibilidad de usar funciones como valores dentro de variables. Pero también es un lenguaje muy guarro, especialmente si pretendes hacer una aplicación más o menos grande, algo que cada vez es más habitual con la evolución que han sufrido las tecnologías web. Se nota que el lenguaje está pensado "en pequeño".

Las variables son globales, y si quieres crear un espacio propio de nombres o modularizaciones adecuadas en general, te metes en problemas. No existe encapsulación, no se pueden tener elementos privados a nivel de clase (si aceptásemos que existen clases, quiero decir, cosa que no es cierta). El uso de this es para darle de comer aparte (cada vez que te ves obligado a hacer un var self = this, muere un gatito), los operadores son exageradamente casquivanos... cosas muy básicas del diseño de aplicaciones, y especialmente del diseño orientado a objetos.

El feo
Por supuesto, puedes diseñar y programar aplicaciones JavaScript correctamente, incluso orientadas a objetos, siguiendo varias recomendaciones sobre cómo organizar correctamente tu código, y qué características del lenguaje evitar. Hay un montón de libros y artículos sobre el tema, y es verdad que uno de los grandes problemas de Javascript es que durante mucho tiempo se ha considerado un lenguaje "para hacer chapucillas en la web". Y la gente que programaba en Javascript a menudo no eran programadores, lo que ha hecho que se haya extendido mucho código basura.

El malo
Pero también es verdad que el lenguaje no ayuda a estructurar mejor el código, sino todo lo contrario, ni tampoco ayuda a la legibilidad. ¿Por qué tengo que leerme un libro para enterarme de qué cosas del lenguaje debo evitar a toda costa y qué patrones debo seguir no para que mi código sea mejor, sino para que sencillamente no sea pura caca de vaca?. ¿Por qué tengo que leérmelo incluso para entender muchas cosas arcanas que lleva el lenguaje dentro, y que muchos programadores gustan de utilizar para demostrar todo lo que saben?.

En cualquier caso, si ya has superado ese umbral, tienes conocimiento sobre cómo diseñar de una forma legible y mantenible una aplicación JavaScript y, qué demonios, te encuentras cómodo con ello, entonces Dart no será para ti.

Lenguaje limpio, con clases y orientado a objetos 

Hoy por hoy, si quieres hacer una aplicación cliente en la web, en web "pura", se tiene que ejecutar en Javascript, ya que es lo único que los navegadores saben ejecutar. Dadas sus limitaciones, han ido apareciendo otros lenguajes de reemplazo, que compilan a Javascript, como por ejemplo CoffeeScript y TypeScript.

Dart va un paso más allá que estos dos, porque al contrario que ellos, el lenguaje no está basado directamente en Javascript. Se parece en algunas cosas, sí, porque la mayor parte de su "target" es la gente que está trabajando con Javascript, por lo que es conveniente que haya cosas que les resulten familiares.

En contraposición a Javascript, la palabra que mejor define a Dart es que es limpio. Tiene funciones, que también se pueden asignar a variables, pero también tiene clases, lo que facilita que se haga un diseño orientado a objetos. Permite crear librerías, versionarlas e importarlas en otro proyecto con un espacio de nombres propio, para evitar colisiones. Tiene la posibilidad de crear propiedades y métodos privados dentro de una clase.

Además, de esto, el lenguaje tiene mucho "syntantic sugar", es decir, muchas formas sencillas de declarar las cosas en pocos términos. Para que un elemento sea privado, basta con hacer que su nombre empiece por "_". Los getter y setter son opcionales, y se les llama automáticamente al usar la propiedad, de forma que desde el punto de vista del que los llama no sabe si existen o no (sí, sí, encapsulación poco trabajosa). Se pueden declarar métodos sencillos que devuelvan un valor o una operación de forma rápida usando "=>". Se pueden concatenar llamadas consecutivas a un objeto con el operador "..". Se pueden declarar fácilmente funciones anónimas para pasarlas como parámetro. Se pueden declarar datos de colecciones de forma sencilla usando literales [] y {}...

El lenguaje Dart tiene tipado dinámico, aunque a ellos les gusta más llamarlo "tipado opcional". Puedes declarar el tipo de cualquier variable, o no hacerlo. Dart tiene un modo de ejecución llamado "checked mode", que es el que se recomienda para desarrollo, y que es más lento pero da error ante manipulaciones erróneas de variables sin tipo declarado según su valor actual. Por ejemplo este código no daría error en "modo producción", pero sí haría saltar una excepción en el modo checked, al tratar una cadena como si fuera un booleano (lo de los undefined, null, etc. como false dentro de las condiciones no se ha heredado de JS; en las condiciones sólo pueden ir booleanos):

var name = 'Bob';
if (name) {
print
('You have a name!'); // Prints in JavaScript, not in Dart.
}
No sé muy bien por qué, pero el editor de Dart no es tan listo como eso, aunque sí que es listillo. En el código anterior no daría ninguna advertencia, pero si pulsamos autocompletar en "name." sí que nos dará una lista con todos los atributos y métodos públicos de la clase String (lo que me hace pensar que lo anterior también es alcanzable). También es capaz de hacer cambios de nombre en clases, propiedades o métodos propagando el cambio a todos los que lo usen, así como hacer otros tipos de refactorizaciones. Por tanto, los que se encuentren más cómodos con lenguajes estáticos (entre los que me incluyo) podrán mitigar un poco esa incomodidad gracias a esta posibilidad de hacer refactorizaciones y renombrados. Por supuesto, en los sitios en los que las variables o los parámetros sí que los declaremos con su tipo, se detectará cualquier manipulación errónea.

En definitiva, sí, el lenguaje se parece a... muchos otros lenguajes que ya existen. Tiene bastantes puntos en común con Groovy, por ejemplo. Pero tiene una diferencia importante respecto a ellos: se puede ejecutar en el navegador.

"Mundo real": Rendimiento, compatibilidad, conectividad

Todo esto es muy bonito, pero la vida real no vive sólo de lenguajes. Consideremos otros aspectos fundamentales a la hora de tomar una decisión:

    de 11870.com
  • Rendimiento. Este ha sido el objetivo número uno del equipo de Dart una vez definido el lenguaje. Es obvio que el rendimiento es importantísimo, el compilador de Javascript debe generar código que sea suficientemente rápido y pequeño, o si no no merecerá la pena. En cuanto a la velocidad, Google afirma que su lenguaje actualmente puede llegar a ser incluso más rápido que si haces la aplicación directamente en Javascript. Los datos se pueden encontrar en este benchmark. Sea verdad o no (ya se sabe que los benchmarks son como las encuestas de los políticos), la verdad es que los ejemplos que he visto sí me han parecido suficientemente rápidos. En cuanto al tamaño, Dart optimiza la carga de librerías, de forma que sólo se compila a JS el código que realmente se utiliza dentro de la aplicación. Ahora mismo hay alguna librería que al utilizarse sí que aumenta mucho el tamaño, pero teniendo en cuenta que se trata aún de una versión 1.0 de la plataforma y que el rendimiento es el objetivo principal actualmente, es de esperar que se hagan optimizaciones. Habrá que ver hasta dónde se consigue llegar.

  • Compatibilidad. El código generado es compatible con todos los navegadores actuales... excepto con Internet Explorer 8 o inferiores. En Octubre del 2013 el uso de IE8 según StatsCounter es del 9,56%, todavía alto. Por otra parte, las herramientas de Dart no funcionan en Windows XP, sistema operativo que todavía según la misma web tiene un uso del 20,06%. Mi interpretación es que este es uno de los aspectos en los que se nota que Dart sabe que su momento no iba a llegar este año... pero puede que sí el que viene, ya que es de esperar que ambas estadísticas y especialmente la de IE8 desciendan durante los próximos meses.

  • Conectividad. Desde Dart se puede llamar a librerías Javascript sin ningún tipo de problema. El enfoque sugerido es hacer una librería Dart que encapsule las llamadas, y en general es así como se está haciendo. Por otra parte, a pesar de lo pronto que todavía es para Dart, existen ya librerías para acceso a bases de datos como MySQL, PostgreSQL o MongoDB. Por supuesto, el margen de mejora en cuanto a librerías es todavía grande.

Librerías de acceso al navegador

Para acceder al navegador tenemos la librería html, una librería bastante grande que encapsula el acceso al DOM del navegador, HttpRequest, WebSockets, y las múltiples nuevas APIs que están surgiendo en HTML5 (almacenamiento local, sonido, WebRTC, etc.). También tenemos la librería js que permite acceder a JavaScript.

Luego sobre ellas se construyen algunas librerías que facilitan la creación de la web según estándares modernos y modularizables, pensando especialmente en la creación basada en componentes. La librería que se considera "base" para esto es polymer, basada en el proyecto Javascript del mismo nombre, y que permite definir elementos y atributos propios dentro del DOM o extender otros ya existentes, enlazar automáticamente con datos de los objetos Dart, incluso con enlazado doble, si cambia el elemento HTML cambia el objeto Dart y viceversa, y crear estructuras condicionales y bucles.

La cosa no se queda ahí ya que también se está creando un port del cada vez más popular AngularJS, llamado AngularDart. Este proyecto va más allá que polymer, ya que es un framework MVC más completo.

Hay que tener en cuenta que toda la parte del cliente, incluyendo estas librerías, al final se acaba convirtiendo en JavaScript. Es decir, nada de SEO (o sea, fundamentalmente nada de aparecer en buscadores) ni de accesibilidad (me refiero a la accesibilidad tradicional WAI WCAG-AA, que se sigue exigiendo en muchos proyectos de la administración pública, no a la más moderna WAI-ARIA). Por eso dije al principio que Dart es ideal fundamentalmente para aplicaciones web, no para sitios web públicos que queramos que aparezcan al buscar en Google.

Se puede ejecutar en el servidor

La aparición de node.js supuso una pequeña revolución, ya que permitía ejecutar Javascript no sólo en el navegador, sino que también la parte de servidor se hiciera en el mismo lenguaje. Dart ha tomado también este modelo, y desde el principio se ha preparado para poder ejecutarse en un servidor web. La diferencia fundamental entre la parte de cliente y la de servidor es que esta última no se compila a Javascript, sino que se ejecuta directamente en la máquina virtual de Dart. Además no podrá utilizar, obviamente, las librerías de acceso al navegador, y a cambio tendrá las suyas específicas que no podrán usarse en el cliente (muchas otras serán comunes para los dos lados).

La librería principal del servidor es io, que permite acceso al sistema de ficheros, sockets, cliente y servidor web, etc.

Para esta primera versión 1.0 el equipo de desarrollo se ha planteado como prioridad el compilador de Javascript y su rendimiento, y la ejecución en la parte del cliente en general, dejando para más adelante las optimizaciones en el servidor. Esto quiere decir que el soporte de Dart en el servidor, aun siendo completo, sólo lo veo recomendable por el momento para aplicaciones que no tengan muchas complicaciones en el lado del servidor. Un API que acceda casi directamente a una base de datos, por ejemplo. Si no, para valientes.

Algunos ejemplos de incidencias o mejoras que se han pospuesto tienen que ver con la velocidad de la propia máquina virtual y de la concurrencia. Concurrencia que en Dart se ofrece en forma de isolates, elementos de ejecución que no comparten memoria y se comunican entre sí por medio de mensajes, para evitar la existencia de errores chungos al gestionar la sincronización. Aparte del modelo de concurrencia, Dart permite ejecución asíncrona mediante Futures, que no se ejecutan simultáneamente sino uno detrás de otro, pero que permiten establecer el orden de las ejecuciones de una forma un poco particular. Son similares a las promises de Javascript. Siendo interesantes a priori ambas propuestas (aunque no tengo una opinión demasiado firme sobre ninguna de los dos por el momento y ambas me chocan un poco), lo cierto es que les queda trabajillo para facilitar la programación en el servidor, tanto en los isolates como en los futures (los futures se usan también en el cliente habitualmente pero entiendo que ahí no tienen por qué complicarse demasiado y me da que basta con lo que hay). Incluso la mismísima serialización de objetos con JSON, que debería ser importantísima en Dart para la comunicación cliente-servidor, entre isolates o usando sockets, está aún poco trabajada (aunque hay soluciones para crear y leer JSON automáticamente, pero ya las contaré otro día).

Sin embargo, el que tanto el cliente como el servidor se puedan crear en el mismo lenguaje Dart tiene ventajas muy interesantes. Es obvio que podríamos compartir código entre ellos, incluyendo los propios objetos que se serialicen en la comunicación cliente-servidor, pero puede ser aún más interesante si creamos interfaces comunes para determinadas partes que son similares en el cliente y el servidor en cuanto a concepto aunque su implementación sea completamente distinta. Especialmente el cliente HTTP, aunque también posiblemente los sockets / websockets. Esto nos permitiría poder trasladar código de cliente a servidor y viceversa con mucha facilidad, haciendo que por ejemplo podamos trasladar cosas fácilmente de acuerdo al rendimiento, la seguridad o simplemente cambios de requisitos.

Incluso, se me ocurre que potencialmente podríamos hacer un framework en el servidor que reemplazara la librería de acceso al DOM y creara los elementos en memoria usando el mismo Polymer o cualquier otro sistema de plantillas que usemos en el cliente, y devolviera el HTML resultante al cliente para partes de la web que queramos que aparezcan en buscadores. Sí, quizá después de todo el SEO sí que sea posible.

Es de esperar que Google vaya con fuerza a por el servidor después de la versión 1.0, e incluso que le dé soporte en AppEngine, de forma que podamos tener con cierta facilidad un hosting básico gratuito.

Yendo un paso más allá

Al ser Dart un proyecto de Google, se pueden adivinar intenciones que tiene la empresa para el lenguaje. Se puede adivinar que pronto la versión oficial de Google Chrome va a ejecutar Dart de forma nativa (bueno, además es que lo han dicho ellos mismos). Al fin y al cabo, ya existe una máquina virtual que ejecuta Dart directamente, la DartVM, y ya existe una versión de Chromium que también ejecuta Dart de forma nativa, Dartium. No olvidemos que Chrome tiene un uso actualmente del 40,44% (nuevamente StatsCounter, Octubre 2013).

Al hacer esto Google va a conseguir una jugada a varias bandas: por un lado, esta vez seguro que sí, las aplicaciones Dart serán más rápidas que las aplicaciones Javascript. Por otro lado, las aplicaciones Dart serán más rápidas en Chrome que en el resto de navegadores. Y por otro lado, las aplicaciones Dart podrán tener un rendimiento comparable a las de escritorio, por lo que se aumentará la tendencia de aplicaciones hacia las tecnologías web. Triple win para Google.

Además de esto, no olvidemos que HTML5 + JS se está utilizando actualmente en otros ámbitos, no sólo aplicaciones web. Por ejemplo, para hacer aplicaciones móviles multiplataforma, o para videojuegos. Y vaya hombre, Google también está detrás de Android, por lo que es de esperar que finalmente también consigan que las aplicaciones hechas en Dart funcionen mucho mejor en Android que en IOS (y ya van cuatro wins). En este sentido, existen ya librerías específicas para hacer aplicaciones móviles en Dart, especialmente Rikulo.

Conclusiones

¿Y ahora?. ¿Estás ya convencido de que esto no es lo mismo de siempre?. ¿Ves no sólo lo que ya aporta, que es mucho (aunque algunas cosas estén aún un poco verdes), sino en lo que puede llegar a convertirse, en lo que se está convirtiendo?. Te invito a que dejes un comentario con tus impresiones. ¿Piensas como yo que supone un nuevo paso en la propia evolución de la web?.

Pues corre, vete a la página de Dart, ¡y dale duro!.

¡La web te necesita!

de panicposters.com

Móntate la mejor Smart TV + centro de descargas + servidor con la Raspberry Pi

¿Cómo te gusta ver las pelis y las series en casa?. ¿Eres de verlas en sitios online o de descargarlas?. Si eres de los segundos, y tienes unos mínimos conocimientos de cacharreo con terminales Linux, este es tu artículo.

Controlarás tus descargas al máximo, desde cualquier sitio y en cualquier momento, con un coste energético mínimo y sin ruido. Y sin tener que hacer nada, copiar nada ni tener que arrancar nada más, encenderás tu tele y tendrás tu catálogo completo navegable con información completa y la portada de cada peli, y podrás elegir la que quieras ver manejando todo con el propio mando de la tele.

¿Preparado?

NOTA: Por supuesto, estoy hablando siempre de descargas legales. Si usas este sistema para descargar algo que no sea gratuito o sobre lo que no tengas derechos, este blog y su autor no se responsabilizan en absoluto.

Introducción

Si no teníamos suficiente inteligencia en el mundo con los smartphones, ahora vienen las teles a hacerles la competencia, y cada vez se oye más el nuevo término molón: las Smart TV.

Lo que está claro es que la tele ya no es lo que era. Hace ya mucho tiempo que eso de que sean las emisoras las que deciden lo que puedes ver es cada vez más cosa del pasado... El caso es que la tele está en un importante momento de cambio. Contratos del pasado y miedos del presente hacen que servicios online como Netflix no existan en España, y que los que existen, como Filmin o Waki.tv no tengan, en mi opinión, un precio ni un catálogo comparable (y el precio y el catálogo, amigos, es lo principal de todo esto). Eso merma mucho las posibilidades online actuales en nuestro país, aunque poco a poco el panorama está mejorando mucho. También hay sitios online de pirateo, pero tienen sus limitaciones (de muchos tipos). Mientras los servicios online acaban de estabilizarse, tenemos la interesante opción de las descargas.

En este artículo os voy a contar cómo os podéis montar la mejor Smart TV al menor precio posible. Existen otras opciones, cada vez más, sobre todo basadas en Android, y ahí están Google TV y Apple TV con el revólver desenfundado. Nosotros usaremos un ordenador barato, la Raspberry pi, perfecta para este uso. Como software principal del centro multimedia le pondremos uno de los más populares actualmente, y que es la leche: XBMC. No contentos con ello, aprovecharemos que tenemos un peazo de Linux con todas sus posibilidades, y lo convertiremos también en un centro de descargas y a la vez en un servidor.

La Raspberry Pi


La Raspberry Pi es un mini-ordenadorcillo poco potente y barato, que viene con lo mínimo minimísimo para poder llamarlo ordenador. No trae ni un solo periférico, es decir, no lleva pantalla (tiene una conexión HDMI y otra de vídeo compuesto RCA), ni teclado, ratón, etc. (tiene dos conectores USB), ni discos duros (tiene una ranura para tarjetas SD, donde se puede instalar el sistema operativo), ni siquiera fuente de alimentación (se alimenta por micro-USB). Por no tener no tiene ni caja. O sea, lo que podéis ver en la foto.

Se ha puesto un poco de moda en el mundillo geek por eso de que es un juguetito "teóricamente" barato, aunque eso ha llevado a que mucha gente no sepa qué hacer con ella pasadas las semanas. Lo cierto es que, precio aparte, le veo al cacharrillo algunas ventajas importantes para ciertos usos, que son los que voy a explorar en este artículo.

Cuidadín, aviso que la instalación de la Raspberry y sus aplicaciones no es para todo el mundo. Conviene tener un mínimo de conocimientos de Linux para ponerla en marcha, sobre todo por la parte de instalación de aplicaciones como servidor. Casi todas las instrucciones van por consola y es fácil que en algunos momentos tengamos que salirnos de lo que te cuentan e instalar algún paquete adicional para que todo funcione, y aparte de eso tendremos que ir pegándonos con el router para abrir puertos, asignar direcciones IP estáticas, etc. Si no te ves capaz, siempre puedes simplemente instalar XBMC y ya está, que eso sí es fácil y sale prácticamente solo.

La lista de la compra

El truco de la Raspberry es que es barata... porque está pelada. La mayor parte de cosas que puedes necesitar es fácil que las tengas ya por casa, pero siempre hay algo que no. Según lo que tengas o dejes de tener, tu lista de la compra real se puede parecer a la siguiente (ojo, los precios que pongo, redondeados, son los que he conseguido yo; no son los más baratos ni de coña, he buscado siempre la comodidad y conseguir lo que fuera sin tener que esperar):
  • La Raspberry Pi modelo B con 512 MB de RAM. Tanto ella como varios de los complementos los compré directamente en una tienda física de Madrid, ya que me pillaba muy cerca y no tardaba nada en comprarla: Electrónica Embajadores. Por Internet y comprando en el extranjero se pueden conseguir precios mejores, aunque sin pasarse. 44 euros.
  • Una caja donde meterla, para que no se quede con la melena al aire, que da penica. Hay cientos de tipos y diseños de cajas distintos, algunos con bastante gracia, de hecho ni siquiera tienes por qué comprártela, te puedes hacer una con Lego. Yo no me compliqué la vida y me compré una caja transparente, que también tiene su aquel. 11 euros.
  • Un cargador de corriente USB y un cable de USB a micro-USB. Esta será la alimentación de la Raspberry. Puede valer el cargador de un móvil, aunque... ¿entonces cómo cargamos el móvil?. Si tenéis alguno de sobra, os valdrá. Lo más importante es mirar los amperios del alimentador. Como poco deberían ser 700 mA. Puede valer con menos, pero hay que tener en cuenta que lo que conectemos a los USB del cacharro también chupa potencia. Para poder poner dispositivos a troche y moche sin miedo, recomiendo que tenga más potencia aún. Yo me compré uno de 2100 mA, pa que no nos falte de ná (en la misma tienda). 13 euros.
  • Una tarjeta SD de clase 10. El tamaño no es tan importante, 8 GB por ejemplo está bien, pero la velocidad de la tarjeta sí tiene importancia. Tened en cuenta que en ella va a estar el sistema operativo, así que para algunas aplicaciones nos convendrá que vaya rapidito. Si tenemos una sobrante de clase 4 ó 6 podemos probar también con ellas, que puede que nos valga. Yo compré una microSD clase 10 de 8 GB (recomendable que sea microSD porque nos valdrá para otros cacharrillos) por 12 euros.
  • Puede que te hagan falta otros cables si por lo que sea no los tienes, básicamente necesitarás un cable Ethernet y otro HDMI (también puede valer un cable de vídeo compuesto)... bueno, ¡y una tele, claro!
  • Un disco duro externo USB. Para no cagarla al final, lo suyo es que no tenga ventilador ni soniquetes "raca-raca". Si tienes ya uno, fenomenal, en mi caso me compré uno de 1TB de esos pequeñines sin alimentación ni ventilador. Ojo, si no tiene alimentación propia seguramente tengas que conectarlo a un hub USB enchufado a la corriente (yo lo he hecho). A mi me el disco me costó 70 euros.
Como veis, al final este "ordenador de 30 dólares" puede llegar a convertirse en unos 150 euros, aunque depende mucho de lo que tengamos disponible por ahí. También es verdad que todos estos componentes los podemos acabar reutilizando en otras cosas, especialmente el componente más caro, el disco duro externo.

Otras cosas que podríamos comprar... o no:
  • Adaptador Wifi USB. Entre que nuestro cacharro vamos a ponerlo a descargar como loco y que queremos que consuma lo mínimo posible, lo suyo es conectarlo al router directamente mediante un cable de red. Pero puede que eso físicamente no sea posible, en cuyo caso nos haría falta uno de estos.
  • Teclado y ratón: en general, lo cierto es que no hacen demasiada falta. En cuanto puedas acceder a un terminal en remoto, podrás manejar todo desde un ordenador, digamos, "normal". Si no tienes ordenador normal, siempre puedes ponerle unos inalámbricos. Ojo, si conectas más de dos dispositivos necesitarás también un hub USB. Si es para hacer cosillas de forma ocasional, siempre podemos comprar un mini-tecladito-touchpad 
  • Mando remoto para manejar las "pelis". Otro que no hace demasiada falta, como veremos más adelante. Hay otras opciones muy buenas. En cualquier caso, si hace falta, existen

XBMC: espectacular centro multimedia

Instalar XBMC en la Raspberry es realmente fácil. Existen varias distribuciones que lo llevan ya de serie, pero yo recomiendo seguir estas instrucciones para instalar Raspbmc. Para poder usarlo luego de servidor, es importante ponerle una IP fija. Esto se puede hacer desde el propio instalador, si se instala desde Windows.

Ahora conecta la Raspberry, con la tele encendida. ¿Por qué con la tele encendida?. Porque si tienes una tele compatible con CEC (y la mayor parte de las teles actuales lo son), vas a poder controlar XBMC con el mando de la tele, sin tener que poner ningún receptor de infrarrojos en la Rasp (la señal se transmite de la tele al cacharro por el cable HDMI). Por lo menos en mi caso, para que esto funcione la tele tiene que estar encendida cuando conectas la Raspberry (simplemente encendida, da igual en qué canal esté).

Si no te funciona, o si reiniciaste la Raspberry con la tele apagada, tienes otra opción sencilla: usar el móvil como mando. En Android tienes aplicaciones como la oficial de XBMC ó Yatse que cumplen este papel a la perfección, además de permitirte otras cosas como por ejemplo explorar tu catálogo de películas, series y música. Pruébalas conectando por wifi. Y si no... siempre puedes conectarle un teclado o un ratón a la Raspberry. Otra ventaja de tener estas aplicaciones en el móvil es que te permiten consultar tu catálogo, así que si quieres por ejemplo puedes elegir qué película vas a ver mientras vas a casa en el metro.

XBMC es una gozada. Le dices el directorio donde tienes las películas y las series, y él solito se pone a pensar un rato y te hace un catálogo completo con todas ellas: portadas, ficha técnica, argumento, información sobre el tipo de fichero... en fin, lo mejor es mirar las capturas de pantalla. ¡Todo eso sale solo!. Y por muy baratera que sea la Raspberry, reproduce vídeos HD de 1080p sin ningún problema.


XBMC tiene muchas más posibilidades. Por ejemplo, tiene un administrador de ficheros que nos puede venir muy bien para colocar ficheros recién descargados, tiene distintos skins... y sobre todo, también existen add-ons para acceder a múltiples servicios online.

Mini servidor "full time"

Ya tenemos nuestro centro multimedia "estándar". Pero... ¿por qué conformarse con eso?. La Raspberry puede ser también un gran servidor, porque:
  • Tiene un consumo energético ridículamente bajo.
  • Es silenciosa. No tiene ventilador, ni disco duro haciendo raca-raca... no que haga poco ruido... absolutamente silenciosa
Y... ¡es completamente compatible tener el servidor con tener el XBMC!. No sólo compatible, sino que se complementan a la perfección.

Como desventaja, tiene poca potencia, así que olvidaros de instalarle un servidor de base de datos, una web Java potente o simplemente cualquier servidor con un gran número de accesos concurrentes. Aunque, bueno, tampoco digo yo que no pueda servir para todo esto, sencillamente no parece la solución ideal para esos casos.

¿Entonces qué tipo de servidores le podemos instalar?. Básicamente, podemos usarlo como:
  • Centro de descargas: torrents, descargas directas, eMule...
  • Servidor web HTTP + PHP
  • Servidor de almacenamiento en la nube, al estilo de Dropbox, Drive, Box, etc.

Preparando el terreno

Por lo pronto, de serie ya trae instalado un servidor SSH. Gracias a él, podemos conectarnos con cualquier otro ordenador e instalar lo que queramos (Raspbmc es una distribución basada en Debian). No sólo eso, también podemos acceder al sistema de ficheros cómodamente con cualquier cliente FTP (como por ejemplo Filezilla) a través de SFTP.

Al acceder por primera vez por SSH, se configuran algunos elementos más: es conveniente poner el locale es-ES_UTF8 (salvo que seas iberoamericano, en cuyo caso sería el dialecto correspondiente, pero es importante que sea UTF8). También es conveniente cambiar la password, ya que para aprovechar todo esto a tope lo suyo es que el acceso SSH (así como el resto de servicios que estemos instalando) sean accesibles desde fuera de la red local. Por tanto, ya tenemos listo nuestro acceso por consola para instalar lo que queramos.

Algo importante es el montaje de nuestro disco externo. Por defecto, Raspbmc automonta el disco con el usuario pi y con permisos de escritura sólo para él (ni siquiera para el grupo). Como los servidores que le instalemos tendrán en general sus propios usuarios, lo mejor es que montemos el disco con permisos de lectura y escritura para el grupo. Para mejorar el control, podemos crear un grupo propio "ntfs":

sudo groupadd ntfs
sudo usermod -a -G ntfs pi
sudo usermod -a -G ntfs root

Como no se pueden cambiar los permisos por defecto para el automontaje, tenemos que cambiar a mano la configuración del montaje de nuestro disco en concreto en el fichero /etc/fstab. Primero obtenemos el UUID de nuestro disco:

sudo blkid /dev/sda1
(probablemente sea /dev/sda1 pero para asegurarnos podemos ejecutar antes sudo fdisk -l | grep NTFS)

Raspbmc trae un editor "cómodo" para editar ficheros, nano, que podemos usar para modificar cualquier fichero de configuración (si eres un fanático del vi lo tienes también, claro).

sudo nano /etc/fstab

Añadimos una línea con el UUID del disco (aquí pondré XXXXX, reemplazar por el que tengáis) y el punto de montaje, que normalmente será un subdirectorio de media (aquí voy a poner externaldisk, pero puede ser lo que queráis):

UUID="XXXXXXXXX" /media/externaldisk ntfs-3g auto,gid=ntfs,umask=0002,uid=pi 0 0

Para asegurarnos, creamos el subdirectorio en media:

sudo mkdir externaldisk
sudo chown pi:ntfs externaldisk
sudo chmod 775 externaldisk

A partir de aquí, por cada servidor que instaléis que queráis que tenga acceso de escritura al disco, deberéis añadir el usuario con el que se ejecute el proceso (que se puede ver ejecutando sudo ps -ef | grep <parte de nombre de proceso>) al grupo "ntfs":

sudo usermod -a -G ntfs <usuario>

Normalmente después de hacer esto habrá que reiniciar (sudo reboot).

[EDITADO] Las instrucciones anteriores suponen que el disco lo tenemos formateado en NTFS, que fue lo que hice yo para poder llevarlo con más facilidad a otras máquinas o centros multimedia ajenos. Sin embargo, si tenéis una conexión a Internet rápida es muy recomendable para el rendimiento formatearlo en ext4 (gracias a Antonio Muños por la información).

Una última recomendación: en general vamos a instalar servidores que te proporcionan un acceso web. El propio XBMC también tiene uno. Para no liar mucho el tema, recomiendo modificar el usuario por defecto y poner en todos los servidores el mismo usuario y password. Ojo, que sea uno propio, no uséis uno estándar, porque cualquiera podría acceder a ellos y liaros una buena. Aparte de eso, para que cualquiera de estos servidores sea accesible por Internet, habrá que abrir los puertos en el router.

Instalando servidores


Para empezar a darle caña, podemos poner un cliente bittorrent con estas instrucciones para instalar Transmission, y poder descargar lo que queráis al disco duro externo. Como podéis ver, Transmission incluye un interfaz web, así que si abrimos el puerto (por defecto 9091) podremos gestionar nuestras descargas desde cualquier sitio. Ojo con la password en ese caso, claro.

Añadimos el usuario debian-transmission al grupo ntfs, cambiamos la configuración para que se descarguen las cosas al disco externo, y todo debería ir como la seda. Como los torrents tienen muchísimo peligro de colapsar la conexión, es importante limitar también la velocidad de subida. En esta dirección podéis calcular qué límite de velocidad es adecuado para vuestra conexión.

Para que cualquier sitio sea cualquier sitio, también podéis controlar vuestras descargas con una aplicación móvil. Para Android por ejemplo tenéis Remote Transmission. Y... también podéis acceder desde el propio XBMC, con lo cual si estáis pegados a la tele no necesitáis despegaros del mando. Basta conque instaléis desde el mismo XBMC el correspondiente add-on.

Pero no sólo de torrents vive el hombre... también tenemos las descargas directas de la web o a través de servidores de descargas. ¿JDownloader? No... mejor instalar pyLoad, un programa que es mucho más ligero, tiene interfaz web y funciona muy bien en nuestra Raspberry. Podéis seguir estas instrucciones, aunque ojo, yo he tenido que instalar muchos más paquetes que faltaban, así que el punto 1 de la instalación a mi me quedó así:

sudo wget -O pyload-cli.deb http://get.pyload.org/get/ubuntu-cli
sudo apt-get install python python-pycurl python-crypto unrar-free tesseract-ocr tesseract-ocr-eng python-imaging spidermonkey-bin libgif4 libwebp2 libgmp10 liblcms1 python-support libnspr4 libtesseract3 tesseract-ocr-osd tesseract-ocr-equ
sudo dpkg -i pyload-cli.deb

Una vez hecho esto, todo debería funcionar correctamente. Sin embargo, veremos que al reiniciar dejará de funcionar. Añadimos el usuario al grupo ntfs y todo debería funcionar correctamente.

Por si te lo estabas preguntando, sí, pyLoad también tiene una aplicación Android para gestionar tus descargas con el móvil.

EDITADO: Antonio Muñoz añade también que es importante para el rendimiento de pyLoad configurar su servidor threaded en lugar de builtin.

Aprovechando que tenemos un cacharrillo propio constantemente encendido, también podemos aprovechar para instalarle un servidor HTTP. Seguro que en algún momento le podemos dar uso. Por ejemplo, puedes instalar el servidor ligero lighttpd, con soporte de PHP. Ponle también soporte para SSL.

Aunque tenemos un servicio sFTP, nos va a venir bien tener también acceso al sistema de ficheros con un interfaz web. Así que podemos instalar Ajaxplorer simplemente descomprimiéndolo en el directorio /var/www y dando permisos de escritura en el subdirectorio data.

sudo apt-get install unzip
wget -O ajaxplorer.zip http://sourceforge.net/projects/ajaxplorer/files/latest/download?source=files
sudo unzip ajaxplorer.zip -d /var/www
sudo mv /var/www/ajaxplorer* /var/www/ajaxplorer
rm ajaxplorer.zip
sudo apt-get install php5-cli php5-gd php5-mcrypt
sudo chmod 776 /var/www/ajaxplorer/data

(al arrancarlo aparecerán avisos varios, cada uno tiene más o menos instrucciones de cómo resolverlo; en cualquier caso, debería funcionar ya)

Ajaxplorer tiene varias cosas que están bastante bien. Permite streaming, como poco de ficheros MP3 (no sé si también será capaz de hacer streaming de vídeo). También tiene herramientas para sincronizar automáticamente un directorio local con un directorio del servidor, al estilo de Dropbox, como esta y esta. Y también permite crear usuarios y roles, por lo que podemos crear carpetas públicas, o invitar a gente a subir ficheros a una carpeta. Y si no te acaba de convencer, siempre puedes probar Owncloud (no tengo muy claro cuál de las dos es mejor o más ligera, la verdad).

¿Más cosas?. Todas las que quieras. Puedes instalar un cliente para descargas de la red de eMule, poner un sistema de administración por web, un servidor Samba, configurar rsync para hacer backups, poner un proceso que reinicie la máquina cuando estén caída, o incluso probar a instalar un servidor J2EE ligero como TJWS... en fin, todo lo que vayas necesitando. ¡Por este artículo creo que es más que suficiente!

Configuración final XBMC

Ahora vamos a cambiar algunas cosillas de la configuración de XBMC para evitar problemas. Si tenemos la Raspberry conectada a la tele por HDMI, la configuración por defecto tiene un inconveniente para nuestro servidor: si al encender la Raspberry el televisor está apagado, no detectará el HDMI y automáticamente mandará la señal de vídeo por el RCA, con lo cual no veremos nada. Esto se puede deshabilitar siguiendo estas instrucciones. Aun así, al menos en mi caso es conveniente conectar o resetear la Raspberry con la tele encendida, porque como comenté antes, parece que si no el mando no funciona. Aunque por lo menos nos aseguramos de que podemos ver lo que estamos haciendo y usar el móvil como mando.

Además, XBMC trae instalado un firewall. Para que podamos usar nuestra maquinilla por Internet, lo podemos deshabilitar. Esto se puede hacer directamente desde la pantalla de configuración de Raspbmc, en Programas > Raspbmc settings > System configuration. Esto me ha estado funcionando durante un tiempo, pero en la última actualización creo que han introducido un bug que hace que no funcione. Si estás en el mismo caso, edita el fichero /etc/network/if-up.d/secure-rmc y al final pon:

sudo /sbin/iptables --flush

¡Listo!

¿Ya lo tienes todo funcionando?. Pues ahora... revisa la agenda, llama a todos tus amigos frikis, y... ¡¡¡presume de Smart TV!!!

En la nube y gratis, ¡barra libre! (¿Google is evil?)

La semana pasada saltó la noticia: Google había decidido cerrar uno de sus servicios gratuitos en la nube, Google Reader. Esto ha creado una importante polémica, ya que muchos de sus usuarios se han sentido engañados por Google, que no ha tenido en cuenta sus sentimientos y necesidades y en su lugar ha atendido al "vil dólar".

Esta reacción me ha dejado, la verdad, bastante sorprendido. Y leche, voy a opinar, ¡que pa eso tengo un blog!

Ha habido gente que siempre ha demostrado muchísimo criterio y educación, como Enrique Dans (gran blog el suyo aunque ahora no esté de acuerdo con él), que de repente, en mi opinión, pierden un poco los papeles con tweets como este:



Traducción (no literal pero creo que sí bastante equivalente): "Ey, @google, ¿recuerdas tu última limpieza de Primavera, cuando te cargaste el Reader? Pues ahora coge el Google Keep y metételo por el ****..."   (Keep es un nuevo servicio que ha sacado Google durante estos días)

También debo decir que Dans ha reconocido su grosería en ese mensaje y que por lo demás ha dado explicaciones sobre su opinión aquí y aquí, pero... ¿qué ha ocasionado que tanto él como muchos otros pillen semejante cabreo?. ¿¿¿Qué ha hecho Google tan diabólico como para llegar a eso???.

Creo que casi nadie duda, o debería dudar, de que Google, como empresa privada, está en su derecho de pensar en sus beneficios por encima de los de sus usuarios. David Bonilla, por ejemplo, razonaba bien esto en un artículo sobre el tema. Pero creo que ese no es el meollo principal del asunto. De lo que se acusa a Google es de maltratar a sus usuarios en el cierre, de no ser justo con ellos. De "jugar sucio".

Yo creo que esto hace que el tema no sea tanto de lógica como de sentimientos, de corazones rotos. Como Maven y yo, vaya. Examinemos pues la historia de amor-odio desde sus principios.

Año 1999. Para todo el mundo, Google es ese buscador que ha salido en los últimos años y que es la leche, y que encuentra más cosas que Altavista y Yahoo. Bueno, no es para tanto, aunque, ¿te has dado cuenta?. Me está mirando.

Año 2000. Google empieza a sacar otros servicios en Internet, como AdWords, con el que empieza a mostrar las cartas de su estrategia empresarial. También empieza a llevar a cabo una de las prácticas que se convertirá en marca de la casa: comprar productos que han hecho otros y hacerlos suyos. Así nace Google Groups. Ey, pues parece que tiene su gracia y hace cosas que no están mal, aunque tía, no me enrollaría con él ni borracha.

Año 2002. Google crea Google Labs, con el que envía otro mensaje: "Nosotros molamos. Estamos continuamente investigando y probando nuevos productos para que todo lo que hagamos sea la leche". Se empieza a conocer que los empleados de Google tienen permiso para dedicar el 20% de su tiempo a proyectos que decidan ellos, y que son los que alimentan el Labs. Pues oye, vale, no es guapo... pero tiene algo especial, no sé cómo explicarlo. Aunque no está tan bueno como Migolsón, claro.

Año 2003. Compra Blogger, y con esto empieza a petarlo, por varios motivos. Por un lado, es un servicio que gana muchísimos usuarios, y que además consigue unir el nombre de Google a una nueva moda que se empieza a imponer en Internet, la creación de blogs. Por otro lado, supone un nuevo mensaje de Google al mundo: "No necesitas Windows, se pueden hacer grandes aplicaciones directamente en la web". No olvidemos que en ese momento Microsoft, su Windows y su Office dominaban el mercado, sin que aparentemente le importara usar malas prácticas para conseguir el monopolio (y estos de verdad, aunque también en esto hay cierta polémica). El caso es que empieza a mostrar otra de sus líneas estratégicas: cargarse a Microsoft, no enfrentándose en su mismo terreno, los sistemas operativos de escritorio, sino yendo más allá, cambiando el paradigma: llevemos las aplicaciones a la web, retornemos desde el ordenador monolítico hacia el cliente-servidor, aprovechando la existencia de Internet. Microsoft tiene su corralito muy bien montado, pero no está preparado para esa pelea. Hasta este momento, no se hacían "aplicaciones" completas en la web, que no se consideraba suficientemente cómoda para ello. Se hacían en Windows. Jo, tía, ¡me está empezando a traer loca! Es tan interesante en lo que dice, es tan sensible, tan especial... Migolsón está muy bueno, pero no mola tanto, te acabas dando cuenta de que es un soso, no tiene fondo.

Año 2004. Lanza GMail, y ahora ya sí que la lía parda. Sigue una inteligente estrategia comercial: aprovecha que ya tiene ganado un gran prestigio, y saca el servicio en forma de "beta privada" con invitaciones. Si quieres ser uno de los "privilegiados" en probarlo y usarlo, necesitas que alguien te dé una invitación. Los que la prueban hablan maravillas del producto, y además presumen de que "yo la tengo y tú no". Además, es que es verdad que GMail está realmente bien. Acaba de un plumazo con algo que hasta ese momento se sufría mucho en el correo electrónico: tenías que estar vigilando siempre el espacio libre que quedaba, y borrar mensajes. Se da una gran capacidad de almacenamiento a cada cuenta y santas pascuas. Aparte de esto, crea un sistema de agrupación de mensajes por conversaciones realmente bien pensado. GMail está tan bien, que 9 años después nadie ha intentado ni siquiera enfrentarse a él. Tía, ¡creo que me mola!, ¿pero qué se ha creído?, le he dicho de salir y me ha dicho que iba a tener unas semanas muy ocupado, ¡que ya me llamaría!. Te lo digo yo, ¡este no se me escapa!

Año 2005. Google cada vez lanza más aplicaciones en la web. Una de ellas de gran importancia con el tiempo, Google Maps, con un completísimo callejero de todo el mundo. Y siguen saliendo más servicios: Google Docs, Picasa, Calendar... Google Reader. Todos gratis. Sin publicidad. Google mola mucho. Google no piensa en ganar dinero, ¡Google piensa en nosotros!. ¡¡¡Tía, qué feliz soy!!! ¡Es perfecto, maravilloso, no tiene ningún defecto! ¡No hay nadie como él! ¡Y sólo piensa en mi, no le importa nada más en el mundo!

Siguieron pasando los años, claro, en los que Google fue dejando cada vez más claras sus estrategias comerciales. Apostó por los móviles con Android. Fue a "matar" a Internet Explorer con Chrome. Sigue intentando cargarse también a Windows, por un lado con los Chromebooks, por otro con Google Apps. Dejó claro que todo eso que nos estaba dando gratis tenía un precio: estaba obteniendo información sobre nosotros, para dar un servicio de publicidad ajustado automáticamente a nuestros gustos, que es revolucionario y con el que se puede ganar (claro) muchísima pasta.

Y es aquí cuando llegamos al meollo. Google nunca ha dicho que piense más en el usuario que en ganar dinero. Google acuñó desde el principio una frase: "se puede ganar dinero sin ser malvado". Se refería a Microsoft, claro. Microsoft aprovechaba su estatus de dominio para hacer el mundo un poco peor. Se saltaba los estándares a la torera. No le interesaban. Lo que le interesaba es que sus productos fueran oscuros y cerrados, y que no fueran compatibles con nada, para cargarse su competencia. Nada de usar formatos estándar de documentos para Office. Nada de usar estándares para las páginas web, ¿para qué?. Si lo que queremos es que todo el mundo use Internet Explorer. Personalmente, culpo a Internet Explorer y por tanto a Microsoft, de que el desarrollo en la web haya crecido tan lentamente.

De lo que se acusa ahora a Google es precisamente de esto: de ser malvado. De dejar tirados a sus usuarios. Sin embargo, lo cierto es que Google en ningún momento ha usado su posición de dominio para ocultar la información y cargarse a la competencia. Google ha hecho todo lo contrario, ha dejado siempre más o menos claro cómo acceder a sus servicios, ha creado APIs, ha fomentado los estándares. Si nadie se ha opuesto a Google en su terreno es porque nadie ha pensado que podía hacerlo mejor.

Una de las cosas que se le achaca es que "Google se equivoca". Suponemos que lo usa "mucha" gente. Suponemos que si es así le tiene que interesar a Google, sin pensar en qué gana Google con todo esto, sin pensar en que el mantenimiento de los servidores y del almacenamiento son dinero que Google pierde. Suponemos que si le interesaba hace 8 años le tiene que seguir interesando. Suponemos que Google ha hecho mal las cuentas, que claro que le tiene que interesar. Suponemos que Google quiere perjudicarnos para colárnosla por otro lado... ¿Por qué?. ¿Por qué va a ser así?. ¿Porque lo usamos yo y mis amigos?

Aparte de esto, digo yo, ¿qué se supone que tiene que hacer una empresa que está dando un servicio gratuito cuando está perdiendo dinero por ese servicio o sencillamente no le interesa continuar con él por el motivo X?. ¿Qué tiene que hacer para cuidar a sus usuarios y darles la posibilidad de migrar a otro sistema? ¿Para tratarlos bien?. En mi opinión, si quieres ir de buenas y buscas el bien de tus usuarios tienes que hacer esto:


1. Avisar con tiempo suficiente de cualquier cambio que quiera hacer en este sentido (cesar el servicio o cambiar sus condiciones)

2. Permitir a los usuarios extraer de alguna forma sus datos, para poder migrarlos a otro sistema

(habría una tercera, que no es aplicable a Reader: el día que Google decida cerrar otros servicios como GMail y Blogger, espero que durante un tiempo permitan configurar una redirección desde tu página o dirección de correo a otra página / dirección)


Esto lo ha hecho Google, y lo ha hecho muy bien. El mismo día que Google anunció que iba a cerrar Reader, Feedly ya aseguraba que iban a permitir una migración transparente sin que el usuario tenga que hacer nada. Esto lo puede hacer Feedly porque Google lo permite, ni más ni menos.

¿Y qué es lo que le piden los que se quejan?. Que Google ofrezca un reemplazo. Vamos a ver, pongámonos en la piel de Google, supongamos que somos nosotros los que damos ese servicio. Si el servicio no me compensa, porque he hecho cuentas y sé que no me compensa, no voy a hacer otro producto que haga lo mismo. ¿Y ofrecer a mis usuarios que se muevan a un producto de otra compañía?. Soy Google, estoy dando una garantía de calidad demostrada con los años. Si te ofrezco un producto de otra compañía, no te puedo garantizar esa calidad. No puedo responder de la otra compañía. Pueden ser unos chapuceros. Sinceramente, si Google hubiera hecho esto sí que estaría perdiendo algo de mi confianza. Y si resulta que no existe ningún producto similar con un nivel parecido, Google no tiene culpa de nada, hay que dejar que sea el mercado el que decida la realidad que hay detrás de todo esto. Una de dos, o aparece un buen producto aprovechando la buena base de usuarios (es lo que ha pasado con Feedly, que se estará frotando las manos), o es que nadie quiere hacerlo porque se pierde dinero con dicho servicio. El caso es que cualquiera puede hacerlo, Google no pone trabas.

Entonces, ¿qué es lo que ha ocurrido?. Yo creo que esto pasa única y exclusivamente por ser Google. Creo que había gente obnuvilada. Que confundió no ser malvado con ser tonto. Que pensó que Google era una ONG. Que usaban cualquier producto de Google sólo porque era de Google, aunque existiera otro mejor. Porque, claro, tenemos sentimientos. Y es tan bonito enamorarse, pensar que el otro es perfecto. Hasta que cualquier día te das cuenta que ¡zas!, es humano igual que tú. Y tiene necesidades igual que tú. Y que, vale, te quiere, pero está mirando a esa otra. Y en ese momento nos sentimos decepcionados y engañados.

Pero tranquilos, que eso se pasa. Se llama realidad, y si la sabes entender, es maravillosa. En cuanto te des cuenta de que pasa el tiempo y otras empresas van cerrando también sus servicios, y que ninguna hace eso que le exigías a Google (pero que tampoco tienes muy claro lo que era), y que al contrario, muchas lo hacen mucho peor... entonces igual vuelves a mirarlo y piensas "Oye, pues no estaba tan mal. Y ey, me está mirando".

Cómo convertir tu netbook... ¡en un ZX Spectrum!

El netbook, ese mini-ordenadorcillo que te compraste hace unos años para navegar por Internet y pedaleos varios mientras estabas en el sofá. Y que ha quedado triste y anticuado desde que compraste tu flamante tablet, la herramienta ideal para el pedaleo y cuyo hábitat natural es el sofá, la cama y hasta el cuarto de baño (sí, yo también soy de esos).

¿Se le puede dar algún uso ahora?. Bueno, los cacharrillos pequeños siempre han tenido una ventaja, la obvia: no ocupan mucho espacio. Siempre se puede hacer alguna tontería con ellos. Si no que se lo digan a la Raspberry Pi, que se está poniendo de moda precisamente por eso, por todas las posibilidades que te da para hacer chorradillas con ella. Pero bueno, ya habrá tiempo de hablar de la Pi, que cualquier día de estos me la compro aunque sólo sea para ver si me decido a comprar la maravilla del frikeo que es el espectacular mini-arcade llamado Picade (lo descubrí hace unos días y todavía babeo).

Y es que últimamente me siento bastante retro. Ese sentimiento más bien absurdillo que imagino que surge sobre todo por la nostalgia. Llevo unas semanas leyendo el libro Ocho quilates, y reconozco que eso está levantando mi espíritu retro, aunque más que por el de los arcades, por el del ZX Spectrum. Al fin y al cabo ya habéis visto anteriormente que soy muy fan del Spectrum.

Mientras me decido por la Picade, que al fin y al cabo cuesta una pasta... ¿por qué no satisfacer mis necesidades más retro con algo que esté más al alcance?. ¿Por qué no darle un uso a ese netbook que está empezando a ser pasto de las telas de araña?. Reservando los arcade de recreativas para el Picade (yum!), ¿por qué no... convertir el netbook en un ZX Spectrum?. Al fin y al cabo, el Spectrum tenía un teclado, como el netbook. El tamaño de la pantalla es genial para el Spectrum. El tamaño del cacharrillo en sí es hasta parecido. Y qué leche, aunque ahora ya no deja de ser más que un caprichín tonto que jamás usaré, ¡en su día era un sueño tener un Spectrum de bolsillo con el que pudiera cargar los juegos sin tener que pegarme con el cassete!.

Manos a la obra. Mi netbook es un Asus eeePc 701. Me gustaría que tuviera un arranque dual, porque todavía me sigue viniendo bien para tomar notas en reuniones o presentaciones con el OpenOffice, para eso la verdad es que es genial, que se quiten todos los tablets. Y para que sea un Spectrum, necesito que arranque directamente como Spectrum y en pantalla completa. Así que necesito un nuevo sistema operativo, que sea ligero, que arranque lo más rápido posible y que tenga un emulador de Spectrum. Y que tenga drivers para el cacharrín. Una distribución Linux ligera, vaya.

Buscando por ahí encuentro que una de las distribuciones ligeras de las que más y mejor se habla es Puppy. Y mejor aún que eso: descubro que existe una distribución derivada llamada Puppy Arcade, que tiene incluidos emuladores para todos los cacharrillos imaginables, ¡incluyendo el Spectrum!. Y además se puede instalar directamente en un Pen Drive.

Primero me lío un poco descargándome otra distribución similar que hay que es Puppee Arcade, que en teoría está adaptada a los eeePC. Pero veo que está anticuada y tiene muchos enlaces rotos. No perdáis el tiempo con ella, no creo que merezca la pena.

Así que me bajo la ISO de Puppy Arcade y sigo las instrucciones para instalarlo en el pen drive. Primer problema: que arranque con el USB. Me meto en la BIOS del eeePC (F2 al arrancar), cambio el orden de boot de los discos. Ojo, está en Boot -> Hard disk drives, me llevó un rato de probatinas darme cuenta.

Segundo problema: al arrancar, la pantalla sale "fea". Y peor que eso, cualquier ventana que se intente abrir no aparece. Ir a Menu -> Shutdown -> Exit to prompt y te lleva a un terminal. Si lees el texto que te pone, te sugiere que si hay problemas con el vídeo ejecutes "xorgwizard". Lo ejecutas y ves que puedes elegir entre modo Xvesa, que es el que hay seleccionado, y modo Xorg. Selecciona este último, sigue las instrucciones y haz la prueba. Al acabar, ejecuta "startx". Et voilá!


Tercer problema: Copio algunos juegos de Spectrum y pruebo el emulador de Spectrum, y... ¿qué es esto?... ¿¿¿no tiene modo de pantalla completa???. La verdad es que no me gusta un pelo el emulador. Aparte de eso, la aplicación que tiene para navegar por los juegos de los distintos sistemas de forma cómoda, tampoco es compatible con el Spectrum. Tanto cogerse una distribución especializada para esto...

En este momento me temía lo peor. Al fin y al cabo, haciendo memoria recordé que no había visto jamás un emulador de Spectrum en Linux con pantalla completa. Y esta distribución no parece que admita ni ficheros deb ni rpm. Buscando un poco, encuentro que sí que existe un emulador con pantalla completa: FBZX. Lo pruebo en Ubuntu y parece que funciona realmente bien. Por supuesto, nada de distribuciones "pet", que es el formato que usa Puppy. Buscando un poco encuentro que sí que existe un .pet para FBZX, aquí, versión 2.1 aunque ya se va por la 2.10... pero es lo que hay.

Cuarto problema: Lo instalo y no funciona. Bueno, dice que instales primero el paquete que hay encima, iNES-3.6, porque si no le faltará la librería glibc2.7. Lo instalo. Nada, mismo error.

Mi piel empieza a cambiar de color un poco más. Una vez he pasado por suficientes tonalidades de violeta como para poder respirar, me decido a buscar la librería. Encuento la versión 2.10.1 aquí. La instalo y... ¡funciona!.


Quinto tema: en mi caso, prefiero instalarlo directamente en el disco duro. Voy a Apps -> Quick start y pulso "Install to HD". La verdad es que esperaba que arrancara más rápido, pero no se nota la diferencia, arranca igual de rápido desde el Pen Drive y desde disco, unos 30-40 segundos. Me decepcionó un poco, la verdad es que esperaba conseguir un arranque más rápido. Pero ya eran las ¡¡¡tantas!!! de la mañana y me había decidido a solucionarlo todo esa misma noche (y lo que ya no era noche).

Sexto tema: sólo queda un detalle más, hacer que nada más arrancar se vaya al emulador de Spectrum, y que arranque directamente en pantalla completa. Voy a Apps -> Browse Files, me meto en el directorio Startup, y creo un script "fbzx_exec", con este contenido:

#!/bin/sh
fbzx -fs


En fin, seguramente se podría haber hecho mejor. Seguramente haya algún Linux que arranque más rápido, y que sea capaz de tener una versión más nueva del FBZX. Pero por mi parte ahí se queda el tema.

Así que ya está, querido lector: ¡ya tienes tu ZX Spectrum de bolsillo!. ¡Ya puedes convertirte en el alma de las fiestas y ligarte a las nenas!. Bueno, o por lo menos ya puedes recordar los tiempos en los que mientras esperabas 10 minutos a que se cargara un juego, mientras lo conectabas a la tele y al cassete y lo llenabas todo de cables, fantaseabas... con tener un Spectrum autónomo de bolsillo como este. El Andrés de los años 80 ha cumplido un sueño.

Bueno, ¿y ahora qué puedo cargar?...



P.D. 1: ¿Os he dicho que al instalar todo esto se me jodió el sistema operativo principal, el Xandros, y ahora no consigo entrar con mi usuario?... bah, ¡tengo un Spectrum!, ¿a quién le importa tan nimio detalle?...


P.D. 2: Ya que estamos con lo retro y el Spectrum, me queda en el tintero hablar de un proyecto que estoy desarrollando últimamente... ¡en poco tiempo en este su blog!

Breezi: la herramienta con la que tu abuela podrá crear la web de su club de ganchillo


Puede parecer que esto de los creadores WYSIWYG (o sea, editores visuales) de HTML no es nada nuevo. El Dreamweaver es quizá el editor de webs que llegó a ser más popular, de hecho hace unos años era una de las herramientas más pirateadas por los desarrolladores. Lo cierto es que con el Dreamweaver podías más o menos hacer webs aunque no tuvieras ni idea, pero llegaba un momento en que no era tan fácil. Ese momento en el que sentías que la herramienta no te dejaba hacer lo que querías, todo se embarullaba y perdías por completo el control sobre tu creación. Las tablas dentro de tablas dentro de tablas dentro de tablas no había nadie que las manejara ya, de repente tenían vida propia. Ya no podías cambiar lo que habías hecho, ya no estabas pensando en cómo quedaba mejor la web. Ya no sabías por qué salía ese hueco ahí ni qué podías hacer para quitarlo. Eso se había convertido en una guerra contra la herramienta. Sólo puede quedar uno.

En cualquier caso, lo que acabó matando a Dreamweaver del todo (aunque la herramienta sigue existiendo, pero su popularidad ya no tiene comparación con la que tuvo) fue el declive del diseño de layouts con tablas y la popularización del diseño basado en CSS. Hacer un diseñador de layouts basados en CSS que resulte intuitivo es mucho más complejo, e incluso muchos podrían pensar que es imposible hacer uno que no requiera de ningún tipo de conocimiento de HTML y CSS.

En este contexto, aparece Breezi. Y Breezi es... la leche. Así de claro. Hace unos días la estuve probando, y hacía tiempo que no probaba algo que me haya entusiasmado tanto. Todo está tan bien pensado y queda tan natural que parece fácil. Pero no lo es, ni mucho menos.

Para mis pruebas quise hacer algo para lo que no tuviera que ir creando imágenes ni logotipos ni fotos, porque no soy diseñador y como tenga que ponerme yo a hacer dibujillos podía tirarme meses. Además quería basarme a ser posible en un caso real, un rediseño de una web sería genial. Así que mi planteamiento fue... ¿cómo haría yo un rediseño de la web de... mi escuela de baile? (sí, amigos, también bailo, o lo intento, ¿a que soy una caja de sorpresas?). Por cierto, si os gusta el baile, queréis aprender y vivís en Madrid, ya estáis tardando en ir a esta academia, porque es muy buena y no sólo aprendes mucho sino que además te lo pasas a lo grande: escuela de baile Sálsalon. Como podéis ver su web se está quedando un poco antigüilla, así que me pareció perfecta para las pruebas (sé que están trabajando en cambiarla, y digo yo que la harán diseñadores de verdad, no informaticuchos sin gusto estético como yo).

Por lo pronto, Breezi es una aplicación web, que además incluye el hosting. Esto quiere decir que cuando tengas hecha tu web no tienes por qué andar pegándote con servidores FTP ni otras zarandajas. Pulsas el botón de "Publicar" y automáticamente tu web está en Internet, en la dirección "midominio.breezi.com". Si no quieres pagar nada, puedes hacer una web pequeña que esté en esa dirección y que tenga un máximo de 3 páginas, insuficiente en el mayor parte de los casos pero potencialmente suficiente para algunas empresas pequeñas que sólo quieren tener un pequeño escaparate, sin demasiadas necesidades informativas. Si quieres hacer una web completa y que tenga su propia dirección, puedes hacerlo por 150 dólares al año. Teniendo en cuenta que esto incluye el hosting, no me parece ninguna barbaridad. Existe también una modalidad de pago a dólar por cada hora de uso del editor, que puede ser muy interesante si no queremos gastar mucho dinero y queremos apurar (esta modalidad puede dar mucho lugar a la picaresca, así creo que se puede considerar muy española). Pero dejemos a un lado el vil metal y vamos al lío.

En cuanto a los layouts, Breezi permite crearlos usando un diseño basado en cuatro elementos:

  • El primer elemento son los bloques principales, que son contenedores horizontales que vienen ya creados por defecto para facilitar las cosas: cabecera, introducción, cuerpo y pie.
  • Dentro de cada uno de ellos se pueden crear secciones, que vuelven a ser bloques horizontales que se añaden libremente
  • Dentro de cada sección se pueden crear varias columnas, que son bloques verticales. Se pueden ir creando, eliminando y redimensionando sobre la marcha
  • Dentro de cada columna se van apilando de forma vertical los componentes de contenido, que Breezi llama aplicaciones. El nombre me parece un poco engañoso, la verdad, quedaros conque son unidades prediseñadas de contenido. Quizá hubiera quedado más claro si las hubieran llamado widgets.

Todo esto está muy bien, pero evidentemente crear una página desde cero siempre es complicado, y Breezi lo sabe. Así que nada más crear una página, lo primero que te da para elegir son un montón de plantillas prediseñadas, para que puedas partir del layout que se parezca más a lo que tengas en la cabeza e ir modificándolo sobre la marcha. Se agradecen detalles como que estas plantillas vengan en blanco y negro y sin grandes suposiciones sobre el estilo gráfico (aunque también tienen otras que incluyen el diseño, para los más vagos). También se agradece que no sean layouts vacíos, sino que incluyan textos, noticias u otros elementos de contenido que se suelen utilizar en las páginas. Esta es una de las grandes maravillas de Breezi, te da siempre ya prediseñado lo que más se suele utilizar, y luego te permite cambiarlo.

En cuanto a la personalización del estilo cada elemento, uno de los problemas típicos que han tenido siempre los editores gráficos es cómo hacer que el usuario pueda elegir correctamente cuál personalizar. Es decir, si un bloque tiene dentro una sección que tiene dentro una columna que tiene dentro una aplicación, ¿cómo puedo hacer que cada una tenga un botón distinto para personalizarla?. La opción por la que opta me parece inteligente: separar cada botón de personalización de los contenedores adyacentes para que puedan pulsarse por separado: uno aparece en horizontal, otro en vertical, otro en diagonal, otro más separado... Para cada elemento podrás personalizar sus márgenes y espaciados y podrás ponerles bordes, sombreados...


Una vez tenemos nuestro layout más o menos definido (o fusilado directamente de la plantilla), comenzamos a meter contenido. Para eso tenemos las aplicaciones. Una aplicación puede ser desde un menú hasta combinaciones de texto e imágenes, pasando por botones, formularios de contacto, galerías, noticias, conjuntos de iconos sociales... Cada aplicación tiene un botón para configurarla en general, como por ejemplo editar los elementos del menú, o las imágenes que aparecerán en la galería. Además, cada aplicación estará compuesta por varios elementos que se pueden configurar por separado. En el caso de los textos, por supuesto tendremos el inevitable editor con sus fuentes (incluyendo las fuentes de Google, por cierto), negritas, colores, etc. A cada elemento de una aplicación se le puede dar estilo por separado, dependiendo los estilos disponibles del tipo de elemento en cada caso.


Otra de las cosas que más me ha gustado es que los contenidos se adaptan al tamaño de su contenedor. Esto es especialmente chulo en el caso de las imágenes. Cuando añades una imagen, esta calcula el tamaño que tiene disponible y te permite seleccionar qué parte de la imagen es la que quieres mostrar, redimensionándola si es necesario y sin deformarla salvo que le digas explícitamente que la quieres así. Sin apenas darte cuenta, has adaptado la imagen en unos segundos.


En fin, lo más importante que puedo decir es que en todo momento tenía la sensación de que el tiempo lo estaba empleando en jugar con el diseño, no en que el diseño jugara conmigo. Sobre todo, tenía la sensación de que no me estaba pegando con la herramienta, sino que en todo momento Breezi me estaba ayudando a sacar el diseño adelante. El resultado no es precisamente espectacular, porque ya he dicho que no soy diseñador, pero teniendo en cuenta mis grandes limitaciones sí que llegó a sorprenderme. En unas horas, ya tenía hecha una página de inicio casi completa, a pesar de que tuve que ir aprendiendo a usar la herramienta sobre la marcha. Podéis verlo en salsalon.breezi.com (no lo he puesto como enlace a propósito, para evitar que aparezca en los buscadores y engañe a algún incauto).


Cabe añadir también que puedes exportar la web resultante, para que se sincronice con Dropbox o con un FTP. Es decir, puedes publicar la web en otro servidor sin problema alguno, incluso con la opción gratuita. Y que la web resultante funcionará bien en todos los navegadores, y si accedes con un móvil te das cuenta de que sin querer acabas de crear un diseño responsive (que no sé cómo narices se traduce, si es que tiene traducción).

Por supuesto, no es oro todo lo que reluce. Al ejecutarse todo en el navegador y con un porrón de Javascript, se necesita un ordenador con cierta potencia para que vaya fluido. Y consume un montón de memoria. También es obvio que es más limitado que el HTML escrito a mano. Por último, el código que se genera es inevitablemente sucio, aunque no tanto como podría haber sido. Pero creo que todo estas limitaciones son inevitables en un editor WYSIWYG. También debo reconocer que no he probado otras herramientas del mismo tipo, como Weebly, Sidengo ó Wix (aunque si he probado esta es precisamente porque es la que me dio mejor pinta). Por último, esta herramienta apenas tiene unos meses, así que todavía puede mejorar aún más con el tiempo (o estropearse, que ejemplos hay miles).

En resumen, Breezi tiene dos cosas que son alucinantes: una, que es una gran herramienta para hacer un prototipo y ayudarte a pensar en el diseño de tu web, y dos... que gracias a ella hasta tu abuela es capaz de hacer una web chula, y dejar en pañales tu último intento de meterte a diseñador. Mejor no se la enseñes, que corres el riesgo de quedarte sin "cocretas" y lentejas para siempre.


Nota: No recibo comisión (ni jamones) ni de Breezi ni de Sálsalon, ¡de verdad!. Sé que prometí en la columna de la derecha que iba a gruñir mucho, y ahora voy y salgo con esta entrada pelota... imperdonable, lo sé. Prometo ser más capullo la próxima vez... 

Java y el UML maldito

En la entrada de hace unas semanas, En busca del UML perdido, contaba cómo apareció el diseño orientado a objetos, por qué es bueno, y por qué el UML abrió un camino importante para su popularización. Y dejaba en el aire que aunque la programación orientada a objetos sí había triunfado con los años, sin embargo el diseño orientado a objetos no lo había hecho... ¿por qué?.

Voy a centrarme en Java, porque al fin y al cabo en general ha sido el lenguaje dominante durante estos años (lo de que además haya sido el lenguaje que he estado usando yo durante este tiempo es una casualidad nimia y sin importancia, claro).

Los profesores de Ingeniería del Software nos decían (y supongo que nos seguirán diciendo) que el lenguaje final en el que se fuera a programar no importaba, que el diseño se tenía que abstraer de eso y ser genérico, y que luego ya se preocuparía otro de programar en el lenguaje de programación que fuera lo que se había diseñado.

Así, las primeras herramientas UML que aparecieron, entre las que destacaba el Rational Rose (que para eso se había gastado Rational el dinero en fomentar la creación de UML), eran herramientas orientadas fundamentalmente a la documentación. Es decir, el producto que se obtenía al usarlas era un documento, que era el resultado del proceso de diseño, y que se entregaría al programador para que lo siguiera como guía al programar.

¿Qué pasó?. Pues que eso de que el lenguaje final no importe es la primera gran mentira del diseño. Vale, es verdad que eso es posible, pero sencillamente no es práctico.

Para empezar, si tenemos ya un diseño de clases, nos conviene que la herramienta sea capaz de generarnos el código Java a partir del diseño, porque eso nos va a quitar un montón de trabajo absurdo y aburrido. Así surgió la generación de código. Tanto el Rational Rose como otros productos por el estilo que había entonces, como el Paradigm, empezaron a implantar la generación de código en C++... y por supuesto también en Java.


Pero no bastaba con eso. Hay otro problema importante, que se presenta porque como ya comenté el planteamiento del modelo en cascada no suele ser realista. Lo recordamos: el analista Calculín hace el diseño en UML sin pensar en cómo se va a programar, y luego el programador-fontanero Mario (Bros., of course) lo tiene que convertir en Java y preocuparse porque todo eso funcione. Al final Mario Bros. acaba modificando cosas sobre el diseño inicial, porque según se va profundizando en el desarrollo de la aplicación, se van aprendiendo más cosas sobre ella, cosas que pueden afectar mucho al diseño. ¿Qué pasa entonces con ese diseño?. ¿Se tiene que modificar también, según cambiamos cosas en el programa?. ¿Vamos a hacer trabajo doble?. Qué coñazo, ¿no?.

Las herramientas entonces empezaron a implantar otra funcionalidad interesante. Como somos capaces de generar Java a partir de UML, si luego algo cambia en Java... hagamos una función que modifique automáticamente el diseño UML a partir de las modificaciones hechas en Java. A eso le llamaron con el bonito nombre de ingeniería inversa ("reverse engineering").

Todo esto de diseñar en UML - generar Java - modificar Java - volver a UML - volver a Java, etc. al final era, la verdad, un auténtico cacao. Cacao incrementado además porque cada cosa se hacía en una herramienta distinta. A algún comercial de mente despierta se le ocurrió arreglar el problema, ¡cómo no!... poniéndole un nombre chulo al tema (una de las grandes soluciones en todo manual del buen comercial). Así surgio, ¡ta-chán!, la... ¡¡¡round-trip engineering!!! (nuestro traductor a español dimitió el mismo día en el que le dijeron que tenía que traducir algo así y lo único que se le ocurrió fue llamarlo "ingeniería de rosquilla"). Si alguna vez, querido lector, has intentado trabajar en la sincronización bidireccional de dos sistemas que se pueden actualizar por separado, sin duda sabrás que la palabra que mejor puede definir eso es que es un infierno. Se le puede añadir algún calificativo, como el típico "fucking" si hablamos en inglés, o cualquiera de los múltiples equivalentes que existen en el rico castellano, pero vamos, creo que se entiende el tema. Es realmente complicado saber qué lado se modificó antes, qué lado manda, asegurarte de que al generar hacia un lado no se pierde nada que ya teníamos hecho, etc. Es complicado de programar, pero también es complicado de mantener y complicado de entender.

En ese momento, a alguien se le enciende una bombilla en la cabeza... y si nos dejamos de complicar la vida, y más importante aún, dejamos de complicársela al pobre programador... ¿¿¿y si hacemos que haya un sólo modelo???. O sea, ¿y si hacemos que el modelo UML esté representado con el propio código Java?. Creas una clase en Java, la tienes en UML. Modificas algo en un lado, lo tienes en el otro sin tener que hacer nada. Creas una clase en UML, la tienes en Java. No tienes que ejecutar una ingeniería directa ni una ingeniería inversa. Más importante aún, no tienes que ejecutar una "rosquilla" de esas chungas. Sobre todo, eliminamos de un plumazo todas las dificultades que conlleva una sincronización bidireccional. Lo que vemos en UML es lo mismo que vemos en Java. Modificamos cada vez lo que nos sea más cómodo en ese momento. Así surgió una herramienta llamada Together.

Together era una gran herramienta de desarrollo. Podías editar Java a la vez que editabas UML. No se consideraba que el diseño era una cosa distinta a lo que se programaba, se consideraba que el diseño era una vista distinta del mismo modelo. Los ficheros Java contenían el modelo de clases UML completo. Cuando hacías un diagrama, el diagrama se guardaba en un fichero aparte, pero sólo se guardaba el diseño del diagrama, es decir, el modelo final era el modelo Java.


Si sabes un poco de UML y de Java te puedes dar cuenta de cuál es el problema principal. El modelo de clases de UML y el de Java son diferentes. Hay elementos que son idénticos en ambos casos, como puedan ser las clases, pero hay otros cuya correspondencia no es tan sencilla. Por ejemplo, asociaciones, composiciones, relaciones 1-N... Para esos casos, hay que definir un mapeo entre Java y UML. Pero ese mapeo es posible. Aún con eso, sigue habiendo información que nos puede resultar interesante en el diseño UML pero que en Java se pierda. Para eso Java tiene uno de esos elementos geniales que a alguien un día se le ocurrió crear aunque no dejen de ser un parche: las annotations (anotaciones). Vale, estamos hablando de finales de los 90, aún no existían las anotaciones, pero sí que existían en la forma de "comentarios Javadoc". Al fin y al cabo eran lo mismo. Pero en TogetherSoft, los creadores de la herramienta, también tenían sus comerciales molones, y rápidamente le pusieron un nombre a todo esto: le llamaron tecnología "LiveSource".

¿Por qué Together no llegó a triunfar si era una herramienta tan buena?. Lo primero de todo, como IDE no llegaba a ser tan bueno como un IDE de Java de los que existían entonces. En aquella época el IDE que triunfaba era sobre todo el Borland JBuilder, creado en el 95 y que estaba realmente bien. Eso era un peso importante, porque si tienes que elegir entre un "gran" IDE Java y un "buen" IDE Java que-además-tiene-UML, la decisión no es tan fácil. Además, en mi opinión había algunos problemas con el mapeo Java-UML, que al fin y al cabo es el problema fundamental. Algunas decisiones me parecían bastante discutibles.

Sin embargo, no creo que ninguno de ellos fuera el mayor problema. El mayor problema que se encontró Together fue puramente comercial. Por un lado, TogetherSoft no era una marca con peso suficiente como para hacer grandes campañas comerciales, no llegó a hacerse tan popular como llegó a ser el Rational Rose. Por otro, y más importante... Together nació en 1999 (o 1998, no estoy seguro)... y con el paso de los años hemos visto cómo surgió Netbeans primero (en 1999), y Eclipse después (la versión 1.0 es del 2001), y que al final fue el que se llevó el gato al agua y se convirtió en el IDE Java más usado. Ambas triunfaron no por ser mejores que JBuilder, sino porque mientras que esta era de pago, las otras dos eran -y siguen siendo- gratuitas. Ahora mismo, el modelo de sacar un producto gratuito para que domine el mercado y acabar teniendo ganancias por dar soporte a empresas y cursos se sabe que puede funcionar (siempre que el producto sea realmente bueno), pero por aquel entonces era difícil ver a compañías de desarrollo que apostaran por él. El caso es que Together era de pago. Es más, por lo que recuerdo era aparentemente cara, de esas que no dicen su precio en la web (sí, siempre usé una versión pirata...). ¿Por qué iba nadie a pagar por esa herramienta existiendo IDEs que son mejores para el desarrollo Java y que además son gratis?.

Rational Rose había llegado a tener cierta popularidad, es más, muchas empresas compraron licencias del producto, pero en el fondo no dejaba de ser un producto fallido desde el momento en el que se separaba el diseño del código. Era un gran producto académico, no tan bueno para el mundo real. Y costaba una pasta. Las nuevas versiones se centraban más en que hiciera cada vez más cosas, más que en que lo que hiciera lo hiciera bien y fuera práctico. La gente se cansó de él, y sólo las empresas que tenían que justificar la producción de un documento de diseño siguieron utilizándolo... y cada vez menos, pasándose en muchas ocasiones a herramientas con las que dibujar cajitas y diagramas, como Visio, Flowchart o sobre todo los mismísimos Word o Powerpoint. Together era un gran producto, pero nunca llegó a ser popular. Demasiado ambicioso en el momento equivocado. Como curiosidad, puedo añadir que Rational acabó siendo comprada por IBM (autores de Eclipse), y Together acabó siendo comprada por Borland (los del JBuilder, y la mejor empresa para desarrolladores hasta ese momento... a esa la mató el software libre, claro). Ambos productos siguen existiendo, pero... ¿conocéis a alguien que los use?.

Pasaron los años y el UML languideció. La cascada y un puñado de dólares lo sepultaron.

¿Qué hubiera pasado si el comercial de TogetherSoft en lugar de perder el tiempo pensando en nombres molones para su tecnología, hubiera ofrecido el producto gratis?. Estoy convencido de que la historia hubiera sido distinta, y ese tipo estaría ahora tumbado en una hamaca hecha de billetes de dólar (bueno, igual está así de todas formas, a saber). La herramienta seguramente habría seguido creciendo, pero en lugar de buscar motivos comerciales, habría buscado funcionar cada vez mejor. Como le pasó a Eclipse especialmente los primeros años. Y ahora UML estaría posiblemente en un trono. O no... (pero yo pienso que sí!).

Se puede decir que en los 2000, sin haber acabado nunca de despegar, UML se fue difuminando cada vez más. Se necesitaban nuevas herramientas. Comenzaron a aparecer "plugins" de UML para Netbeans y/o Eclipse, la mayor parte de ellos siguiendo el modelo de Rational, es decir: orientado a la documentación, y de pago. También surgió alguna herramienta de UML gratuita, como ArgoUML, pero por un lado en general seguían estando orientadas a la documentación, y por otro el acabado normalmente no era suficiente como para convencer a nadie para que las usara.

En el año 2002 (o quizá 2001), aparece un plugin para Eclipse llamado "EclipseUML" y creado por una empresa llamada Omondo. Las intenciones de Omondo eran muy buenas, el plugin es gratuito y siguen la filosofía "LiveSource" de Together, es decir, el modelo UML se guarda en las propias clases Java. Omondo rebautizó esta técnica como "live round-trip". Las primeras versiones no tenían tanta funcionalidad como tenía el Together, pero al estar integradas con Eclipse, el IDE de Java seguía siendo el mejor. Y lo cierto es que el editor de UML no estaba mal y cumplía muy bien con lo mínimo que se le podía pedir. ¿Esperanza?.

Pero todo se fue al traste en cuanto alguien se dio cuenta de que eso que estaban haciendo ellos, hasta ese momento se estaba cobrando. El dólar volvió a aparecer. Así, el producto empezó a ofrecer una versión gratuita y otra de pago. Una de las "pequeñas" diferencias entre ellas era... que la versión gratuita no se podía usar en proyectos que estuvieran bajo control de versiones, es decir, CVS, Subversion, etc... espera... ¿¿¿pero qué proyecto medianamente serio no está en control de versiones???. Si esto ya de por sí es casi casi volver a caer en los mismos errores del pasado (hay una ventaja importante, y es que seguimos dentro de Eclipse), de repente a los señores de Omondo se les ocurre que por si acaso eso no es suficiente para hundir del todo el producto, mejor darle un empujoncito. Así, en un momento dado por cada versión nueva del plugin que sacaban, cambiaban el formato de los ficheros de diagramas. Es decir, si cambiabas la versión del plugin, tenías que volver a dibujar todos los diagramas. Como además la versión del plugin estaba ligada a la versión de Eclipse, si querías actualizar Eclipse tenías que actualizar el plugin. Ni sé, ni quiero saber, qué habrá sido del plugin de Omondo. Sólo sé que cuando he visto alguna vez su página me ha parecido que volvían a haber cada vez más y más funcionalidades "avanzadas". ¿Repitiendo más errores del pasado?.



También ha habido alguna aproximación diferente, limitada pero interesante. Por ejemplo UMLGraph, que propone algo radicalmente distinto: en lugar de dibujar nosotros los diagramas, esta herramienta los generará automáticamente y los meterá dentro del JavaDoc. El modelo por tanto es también el modelo Java, usando también anotaciones para enriquecer la información UML. Esta aproximación me parece muy interesante como herramienta complementaria, pero no tanto como herramienta única.

Han aparecido también otros plugins gratuitos con la idea del LiveSource, como por ejemplo Green UML, pero el problema de este plugin es... el que dice el nombre, que está verde cual aceituna bañada en rayos gamma (aunque confiamos en que florezca y se convierta en una linda mariposilla). Otros plugins son gratuitos pero siguen con la idea del diseño como documento y la mandanga del roundtrip, como Papyrus ó el propio plugin oficial de Eclipse MDT / UML2.

Es frustrante, porque teniendo en cuenta la arquitectura modular de Eclipse y que tiene módulos para tanto para hacer fácilmente diagramas como para manejar el código fuente de Java a cualquier nivel, lo cierto es que hoy por hoy sería fácil hacer un editor de UML con LiveSource. Ahí tenemos el ejemplo del Green UML, ¡que surgió como un proyecto hecho por estudiantes en la Universidad! (no tengo claro si fue para un proyecto de fin de carrera o para una tesis, pero imagino que fue para algo así).

¿Está todo perdido?. ¿Caemos una y otra vez en los mismos errores?. ¿Qué es lo mínimo que debería tener una herramienta UML para que sea práctica al trabajar en proyectos Java?. ¿No existe ninguna ahora mismo que apunte a eso, todo son fracasos?. ¡Quiero usar una!. ¿Andrés, eres tan abuelo cebolleta que no eres capaz más que de hablar del pasado?. La respuesta a todas estas cuestiones, en la tercera parte de esta serie sobre UML, que como no podía ser de otra forma se llamará "UML y la última cruzada". En pocas semanas en este humilde blog.