La absoluta grandiosidad de Rompe Ralph

Es indiscutible que el cine de animación ha observado un gran resurgimiento en los últimos tiempos y muchos de sus pelotazos han sido universalmente aclamados como grandísimas películas para niños y adultos. Un servidor debe admitir que siempre se ha sentido un poco al margen de esto y que salvo honrosas excepciones (casi que me limitaría a WALL-E, el primer acto de Up y si me he de estirar cual Elasti-girl, los Increíbles) me deja en general bastante frío.

Obviamente en su momento vi los trailers y promociones de ¡Rompe Ralph! en su momento, y por supuesto secuencias como la reunión de villanos anónimos con un fantasma de Pacman, Zangief, Bowser y otros me atrajeron como un bicho a la luz, pero por un motivo u otro acabé no viéndola en el cine. Posteriormente, por casualidades del destino, Renfe se dignó a ofrecerme a Ralph en vez de una tercera proyección en dos semanas de Star Trek: en la oscuridad.

¡Y qué feliz coincidencia!

Pocas veces me he quedado tan enganchado a una butaca mirando una pantalla minúscula forzando el cuello. ¡Rompe Ralph! es una maravilla de principio a fin. Parte de la más que jugosa premisa de que los personajes de los juegos de un salón recreativo tienen vida propia y se ocupan de sus asuntos fuera de sus “horas de oficina”- en este caso el Ralph del título es el malo de “Repara Félix Junior”, cansado de su rol como villano que decide ser el bueno por una vez. Este argumento, que podría haber resultado plano y simplón se transforma en toda una epopeya gracias a un trabajadísimo guión que si bien tampoco es que sea un laberinto inacabable de giros y sorpresas, es más elaborado de lo que uno pensaría y consigue aprovechar todo el potencial del planteamiento y de las generosas licencias que permiten que aparezcan multitud de personajes de videojuegos reales.

La historia combina los personajes de tres juegos inventados- el “Repara Félix Junior” de Ralph, “Hero’s Duty”, un shooter de marcianitos y “Sugar Rush” un Mario Kart aún más almíbarado si cabe- hilvanandos las historias de sus personajes con habilidad, tirando de clichés y dejes videojueguiles y con alguna que otra hábil subversión. Además los personajes tienen unas personalidades más que tridimensionales que ayuda a darle una tremenda dimensión humana a la película- Ralph en toda su apariencia caricaturesca tiene toda una dimensión trágica y una humanidad que ya quisieran para sí muchos personajes de sesudos dramas- él y los demás dotan a la película de una emotividad sorprendente y poderosa.

En el aspecto técnico, la animación es absolutamente sobresaliente y destaca en su completa virtuosidad en el paso a las tres dimensiones de los juegos bidimensionales. Cada videojuego tiene una estética trabajadísima que se combinan con fluidez con el estilo visual de otros tantos videojuegos reales; los personajes de juegos más retro se maravillan de los gráficos de los juegos de última generación, pero encajan perfectamente conservando cada uno su propia personalidad sin mayor problema.

La banda sonora así mismo recorre con gracia todos los lugares habituales videojueguiles, e incluso las dos canciones-estrella-invitada, una de Rihanna y la de los créditos de Owl City en VO y Auryn en España no desentonan.

En definitiva, una película sobresaliente a la que es muy difícil no querer colocar en los olimpos cinematográficos. Hasta los no videojueguistas disfrutarán de lo lindo y los rompe-joysticks sobra decir que alcanzarán en el extásis (y hay un par de guiños ahí que sacarán ovaciones cerradas). Peliculón.

Jugando en 2013

Mis hábitos videojueguiles se han incrementado sustancialmente recientemente. Sin más, a qué he estado jugando últimamente:

Humble Bundles

Me enganché ahí por septiembre de 2012 con el Humble Indie Bundle 6 por Bit.Trip Runner, el Gratituous Space Battles, Shatter y SPAZ (aunque este último no me tiraba inicialmente en Linux). Sobre todo al que más le di fue al Bit.Trip, hasta que llegué al límite de mis reflejos.

En junio de 2013 le di al Humble Bundle with Android 6, atraído por el prometedor Frozen Synapse, que cumplió sus promesas como ya explique en una entrada anterior. Luego estas navidades han caído casi consecutivamente:

  • Humble Bundle: PC and Android 8, por el genial AaaaaAAaaaAAAaaAAAAaAAAAA!!! for the Awesome
  • Humble Jumbo Bundle, por el Serious Sam 3: BFE, al que aún no he jugado mucho
  • y la Humble Weekly Sale: Puppy Games, un pack de jueguecillos retro de Puppy Games la mar de gracioso, que incluye un Galaga, un Robotron y algo parecido al Paradroid, entre otros

Steam

En un arranque de nostalgia, y en parte por premiar el compromiso de Valve con Linux, me he pillado dos FPS clásicos.

El primero, por supuesto, mi querido Quake II, al que le dediqué muchas horas gloriosas en su momento y del que quiero recuperar el disfrute descerebrado de batallas al límite con legiones de bots. La verdad está siendo una odisea por ahora inacabada, ya que primero sólo está disponible en Windows, con lo que hay que instalarlo en Steam para Windows (en máquina virtual en mi caso) y traspasar los archivos de juego para usarlo con un cliente Linux (Yamagi, en mi caso). Con esto ya he podido jugar (por enésima vez) a los primeros niveles del modo de un solo jugador (aunque a 1920×1080 y unos gráficos que no disfruté en su época). Pero la clave está en hacer funcionar LMCTF, el mítico capturar la bandera con el “off-hand hook”, un gancho que puedes disparar al más puro estilo Spider-Man para columpiarte por el mapa mientras disparas, una mecánica de juego absolutamente gloriosa… y luego sumarle un bot (el Ultra, creo).

El otro es el Counter-Strike clásico. Ha sido genial comprobar como los servidores de un juego que salió en el 99 (¡el 99! ¡hace 14 años!) siguen llenos de jugadores matándose en el Dust. Yo no era muy de Counter en aquella época, pero estaba de oferta y es disfrutar de una pieza de museo.

PS3

Tenía la Playstation un poco olvidada- el GTA4 no era muy de mi agrado, el GT5 lo tenía ya muy visto y sólo le daba con cierta frecuencia al último Pro. Pero en esta última parte del año salió el GTA5, que me acabé y describí por aquí, y hace unos días le he echado mano al GT6. Cuando tenga un poco más de rodaje ya escribiré unas líneas, pero de momento sí, decir que es el 5 con sus mayores defectos corregidos- es decir, excelencia sobre ruedas.

En definitiva…

Sí, le doy más a los videojuegos que antes. Con los Humble Bundles y Steam, la barrera de preferir Linux se reduce bastante y puedo jugar cómodamente en el PC, con el complemento de la PS3. Vienen otras sorpresas, claro… y quizá tendría que hacer otras intentonas de MESS, UAE, Frodo y demás, pero el tiempo es limitado y uno no puede dedicar tanto tiempo como quisiera a los aspectos lúdicos. Pero da gusto gozar de las maravillas modernas y recuperar los clásicos que se demuestran imperecederos.

El cinco

Rockstar se mantiene fiel a su cita de revitalizar los inacabables debates sobre videojuegos; que si violencia, que si nueva forma de arte, que si el entretenimiento del siglo XXI… con su entrega periódica de la saga Grand Theft Auto. Hace unos días y tras treintaypocas horas de juego me acabé la historia principal del juego, con lo que me veo en el derecho de comentar mis impresiones aquí.

Pocos se preguntarán a estas alturas qué es el GTA. Pero por si acaso, lo repetiré aquí. El GTA es una saga de juegos surgida hace unos no despreciables 16 años en los que encarnamos a un criminal en un mundo abierto, con una historia que consiste en una serie de misiones a completar que nos permite ir avanzando el argumento. Yo me enganché en la primera entrega “3D”, el GTA III para PS2; me completé toda esa era, junto al Vice City y el San Andreas, pequeñas evoluciones que destacaron respectivamente por la ambientación y guión del Vice City (Miami, tomando como referencia El Precio del Poder de Brian de Palma) y un mundo gigantesco en el caso del San Andreas (el Liberty City/Nueva York del III y la Vice City/Miami del Vice City son ridículas comparadas con el condado de San Andreas/California del San Andreas, con su Los Santos/Los Ángeles, San Fiero/San Francisco y Las Venturas/Las Vegas, más una extensa campiña). Los 3D siguen al personaje principal en vista de tercera persona, mientras se mueve a pie o en diversos vehículos, peleando, disparando y saltando por, mayormente, las calles de una ciudad (algunos interiores hay, pero relativamente pocos).

El IV en PS3 volvería a Liberty City, pero por algún motivo, no me enganchó y casi no lo jugué. Pese al salto a la nueva generación de consolas, los gráficos me parecieron… grises y entre eso y un par de mecánicas de amigotes traídas del San Andreas, quizá un nivel de dificultad más alto y alguna cosa más, olvidé el bluray en un cajón.

Todo esto daría un vuelco con el V. Unos tráilers conseguidísimos, una historia que bebe de Heat sin vergüenza y la promesa de mejores controles me puso a tono para comprármelo el día del lanzamiento.

Y no me decepcionó. Quizá con un poco de trampa, rebajando el nivel de dificultad, el GTA V destaca por lo satisfactorias que son las escenas de acción. La conducción de vehículos, siempre un poco deficiente en anteriores entregas es mucho más… arcade y divertida. Y los tiroteos, oh los tiroteos. Los mecanismos de ponerse a cobertura, disparar, apuntar, cambiar de arma… son mucho más fluidos y sencillos de llevar a cabo. Apuntar con los controladores de consola es bastante frustrante respecto al uso de teclado y ratón de los shooters de PC, pero gracias a la acertada dificultad, participaremos en tiroteos grandiosos.

El juego asímismo introduce una novedad respecto a entregar anteriores. Los protagonistas anteriores (el silencioso del III, Tommy Vercetti del Vice City, CJ del San Andreas y Niko del IV) se ven reemplazados por el imaginativo trío protagonista. Comenzamos con Franklin, un pandillero muy similar a CJ que también se da cuenta que la ambientación de pandilleros es de lo más sosa, lo que nos lleva a Michael. Michael es un ex-atracador de bancos retirado que se verá arrastrado una vez más a una vida criminal, mayormente por eventos relacionados con Trevor, el último personaje en entrar, un demente que hacía equipo con Michael.

Trevor es el que más se ha enfatizado de todos- su locura, psicopatía y demás excentricidades dan mucho juego, hacen gracia y sirven de excusa (innecesaria) para la ultraviolencia propia de la serie. Pero mi favorito es sin duda, Michael- sin duda el personaje más multidimensional de la saga. Tras una exitosa carrera criminal, al lado de Trevor y otros variopintos personajes, se retira en sospechosas circunstancias con su mujer e hijos a una pequeña mansión en Beverly Hills. La dinámica de la riqueza le conduce a una familia inaguantable y a un vacío existencial que le lleva al psicólogo. Michael recorre los puntos entre el sarcasmo, la compasión, el instinto maternal y el crimen con elegancia y gracia, y sin duda alguna es el mejor interpretado del juego.

Pero es precisamente con Michael donde se exacerba el desequilibrio propio de la saga- Grand Theft Auto a veces es una peli muy seria de gángsters, a veces hace crítica social… y a veces se dedica a hacer chistes de caca-culo-pedo-pis. De hecho cuando los GTAs van en serio, lo hacen muy bien- las versiones GTA de Blackwater, el FBI… el comentario social, etc. pueden estar muy bien encontrados a veces, pero de repente da un volantazo hacia la caricatura y aunque a veces acierta, muchas veces descarrila completamente. El humor es además muy endógeno y poco accesible- chistes recurrentes que se remontan a las 14 entregas anteriores de la saga entre todas las diferentes versiones y un punto de vista bastante constante entre ellas, que puede gustar pero también aburrir.

El otro punto característico de los GTA es el famoso mundo abierto que popularizaron. En esta entrega se vuelven a superar una vez más- quizás el entorno sea menor en metros cuadrados que en el San Andreas, pero es desde luego más detallado y grandioso. Los gráficos son sencillamente espectaculares y es sorprendente comprobar hasta qué nivel se ha cuidado hasta el menor detalle. En esta ocasión hasta el entorno submarino está mapeado con horas y horas de trabajo añadiendo elementos que uno no podrá apreciar completamente aunque se dedicase siglos a ello. El monte Chiliad tiene teleféricos. Hay un campamento hippie. Una secta en las montañas. Infinidad de pueblecitos. Un sistema de autopistas en el que es fácil perderse.

Es, sencillamente inacabable y, como en entregas anteriores, la tentación de explorar se sobrepone muchas veces a que avancemos la historia.

Historia por otra parte que resulta interesante y que, aunque un poco predecible en ocasiones, hará que queramos llegar al final para ver cómo acaban.

Las misiones en sí acaban sufriendo de un poco de falta de variedad como en los anteriores, aunque se han esforzado más en dos aspectos en particular. Uno, los tiroteos, que son más complicados y elaborados que antes. Dos, los “heists”/golpes, misiones donde tenemos que planear asaltos, equiparnos, escoger entre dos alternativas, etc. que le aportan bastante novedad al limitado número de estereotipos de misión anteriores.

En fin, un juego imprescindible en todos los aspectos. La reducida dificultad lo hará accesible a todos- lo único que nos puede echar para atrás son las idiosincrasias de la serie, su humor infantil y otros puntos pueriles en lo que, por lo demás, es una obra de entretenimiento de primer orden.

Recopilatorios de grandes éxitos

Indudablemente, una de las asignaturas coco de cuando yo estudiaba informática era Compiladores- compis, para los amigos. No porque hubiese una tonelada de apuntes que memorizar, ni porque los profesores fuesen particularmente estrictos sino porque, simplemente, era tremendamente complicada.

Implementar un lenguaje de programación es seguramente una de las labores más complicadas que hay en el campo de la programación pura.  Tanto intérpretes como compiladores son fieras complejas que necesitan el uso de técnicas bastante sofisticadas para poder ser programadas efectivamente.

Tanto intérpretes como compiladores tienen que leer los programas escritos en su lenguaje- algo no trivial que en general se resuelve usando herramientas descendientes de los venerables lex y yacc; que en conjunto convierten una descripción de un lenguaje (un listado y definición de los átomos del lenguaje; palabras clave, separadores, sintaxis de literales, etc.; y una descripción de cómo se combinan para formar las estructuras del lenguaje) y que típicamente generan código en el que incrustamos nuestro compilador e intérprete.

Estas herramientas, básicas para el desarrollo, no son tampoco precisamente simples. Definir gramáticas de lenguajes es algo que se complica rápidamente- si no estamos hablando de lenguajes simples, no es sencillo encontrar una sintaxis y gramática no ambigua y, curiosamente, que no sea exponencialmente compleja de procesar. Lenguajes como C++ y Perl son notorios por sus particularmente enrevesadas gramáticas- en ambos casos son de tal complejidad que ellas mismas son, en cierta manera, lenguajes de programación.

Una vez podemos tenemos un mecanismo que nos permite pasar del código fuente de nuestro lenguaje a algo tratable por un programa (que es aún más complicado de lo que hemos descrito, ya que las herramientas comentadas, a parte de su complejidad teórica, nos plantean dificultades prácticas porque suelen ser, en general, bastante inaccesibles y poco amistosas), nos queda lo peor.

Los intérpretes deben, como su nombre indica, interpretar el código ya dispuesto en una estructura tratable (aunque probablemente compleja) y ejecutarlo. Para ello, debemos coger la representación del código e ir ejecutándolo paso a paso igual que haríamos si quisiesemos verificar la ejecución del código manualmente. Esto tampoco es sencillo, ya que características del lenguaje tales como los distintos alcances de los identificadores, los sistemas de objetos, la comprobación de tipos, etc. son en general problemas de por sí complejos.

Pero quizás el hueso más duro de roer es la compilación. En un problema algo relacionado con la traducción de lenguaje natural, un compilador debe coger el código una vez procesado y presentado de una manera estructurada y convertirlo en código de otro lenguaje. Esto, tal como es la traducción de lenguaje natural, es harto difícil.

En general, los compiladores suelen ser de lenguajes de mayor nivel a menor nivel; solía ser que los lenguajes se compilaban directamente al lenguaje ensamblador propio de las CPU- lenguaje ensamblador que es mucho más simple, poco expresivo y limitado que la mayoría de lenguajes de alto nivel, y por tanto esta traducción es compleja- en cierta manera debemos coger Dublineses y explicarlo de manera que un niño de cuatro años pueda entenderlo perfectamente.

En estos casos, la cosa se suele complicar mucho más porque una implementación naíf de un compilador a ensamblador suele redundar en programas que al ejecutarse son espectacularmente ineficientes. Conseguir ejecutables eficientes es un problema completo en sí mismo sobre el que se han escrito toneladas de libros.

Sin embargo, recientemente son más habituales los compiladores que compilan lenguajes a cosas que no son ensamblador- por diversos motivos entre los que destaca que un compilador a ensamblador sólo es útil para una familia de CPUs, y pese a que la familia x86 de Intel y los ARM copan la mayor parte del mercado, sigue habiendo muchos otros procesadores en uso hoy en día. Por otra parte, plataformas como la máquina virtual Java, LLVM o incluso Javascript también son populares como destinos de los compiladores- en el caso de Java o LLVM por ser más simples para la generación de código sin sacrificar eficiencia, y en el caso de Javascript, por ser un destino particularmente útil ya que nos permite ejecutar el código compilado en un navegador.

Tanto la JVM como la LLVM han sido diseñadas especialmente para este propósito, con lo que tienden a simplificarnos el proceso de compilación. En el caso de Javascript, pese a estar pensado con otros propósitos, proyectos como GWT o Emscripten han hecho grandes esfuerzos para hacer funcionar compiladores sobre Javascript. Mozilla incluso ha lanzado la iniciativa asm.js para definir un subconjunto de Javascript que sea práctico como plataforma a la que compilar de una manera eficiente.

El proceso no se queda aquí, ya que una vez tenemos un lenguaje funcional con intérprete o compilador, siempre hay un interés en acelerarlo- tanto el proceso de compilación como la ejecución de los programas. Una vez más, se trata de un área complicada y sutilezas- se han llegado a técnicas extremadamente sofisticadas que incluso “aprenden” de la ejecución del programa y modifican su funci0namiento para adaptarse y mejorar “en vivo”.

Como decíamos, una de las áreas de la informática pura más complejas y duras. Si bien en inteligencia artificial, bases de datos, proceso de imágen, etc. existen problemas duros, no suelen ser tan duros en cuanto a programación, sino a las matemáticas y otras áreas no estrictamente informáticas que tocan. También en programación empresarial existen sistemas extraordinariamente complejos, pero en este caso suelen serlo por el tamaño y la cantidad de entidades y conceptos interactuando entre sí del negocio. Pero son los compiladores probablemente una de las hazañas de programación más sofisticadas que hay y, así mismo, primordial para la programación en sí.

Ensaladilla de tiros: Frozen Synapse

Hace unas días me llegó el anuncio de un nuevo Humble Bundle, el célebre pack de juegos “paga lo que quieras” que sale ocasionalmente. Le eché un vistazo al listado y me llamó la atención uno, Frozen Synapse, una especie de simulador de tiroteos estratégico. Es de los que necesitas pagar más que la media para obtener, pero siendo la media ahora mismo menos de 4€, me lancé (puse $10, de hecho).

La premisa es sencilla, controlas una pequeña escuadra de agentes en escaramuzas contra otros grupos. El juego consta de turnos de 5 segundos, en los que puedes dar órdenes a tus hombres: moverse, apuntar, cubrirse, etc.; le das al play y se desarrolla el turno según las instrucciones.

Las órdenes son relativamente simples y dispones de un modo de previsualización que facilita bastante el diseño de las órdenes… no hay munición, energía, habilidades ni nada; incluso prometen que la simulación es determinista y exenta de azar. Se puede jugar en modo “luz” o “oscuro”, lo que determina si eres omnisciente y ver a tus oponentes siempre o sólo cuando tus agentes tengan contacto visual. Yo sólo he jugado con luz, entiendo que el oscuro lo complicará todo bastante y le añadirá emoción, pero de momento quiero cogerle el truco fácilmente.

Para el aspecto visual, podéis echarle un vistazo al trailer:

, los gráficos son sencillos y atractivos (y como bonus, ¡funciona aceptablemente hasta en mi netbook!).

Debo decir que sólo he echado unas cuantas escaramuzas, las primeras misiones del modo campaña y una partida rápida online, pero de momento me parece un juego fantástico.

Ni cuando tenía mucho tiempo para jugar me atraían los juegos complejos, y ahora que dispongo de pocos ratos para los videojuegos, más aún. Los juegos con mil tipos de unidades, opciones, recursos a gestionar, etc. me cansan y me hacen sentir como si estuviese trabajando de contable más que jugando. Frozen Synapse, en cambio, con muy pocas variables y mecanismos de juego en los que pensar, consigue mucha profundidad táctica. El sistema de turnos le da bastante emoción a la cosa, y de momento parece todo bastante equilibrado. Me recuerda mi parte favorita del UFO: Enemy Unknown, los tensos tiroteos, sin los (para mi) tediosos interludios de gestión de recursos.

Si buscáis un juego táctico sin complicaciones pero con dosis de emoción, creo que Frozen Synapse es una excelente opción… y es tan barato que casi no entraña riesgo.

Esquemas de datos explícitos e implícitos

Hablando de bases de datos relacionales, es común referirse al esquema de datos como la definición de las tablas, vistas, funciones, etc. que conforman la base de datos*. El esquema es sumamente importante, por supuesto, nos define qué datos admitimos y nos condiciona todo código que accede a la base de datos.

Este es un esquema explícito; está ahí, podemos enumerar los objetos de los que se compone y conocer milimétricamente su estructura; podemos saber qué tablas hay y qué columnas tienen, etc.

Ahora bien, supongamos que cogemos una aplicación que usa una base de datos y de repente, ocultamos el esquema. Asumamos por un momento que no podemos saber qué tablas hay, ni qué columnas, ni nada. Aún haciendo este gran cambio, nuestra aplicación seguirá funcionando**. Aún más, si desconectamos todas las restricciones de integridad y admitimos que se inserten valores en columnas que no existen (e incluso los almacenamos)… nuestra aplicación muy probablemente seguirá funcionando correctamente.

La primera observación interesante que podemos hacer es que aquello a lo que llamábamos el esquema de datos puede que no esté ahí, pero los datos que tenemos almacenados seguirán siguiendo el anterior esquema de datos. La programación seguirá condicionada por ese mismo esquema; seguiremos insertando en las tablas y columnas que definía el esquema.

El esquema de datos original que habíamos declarado explícitamente ya no existe, pero el esquema de datos implícito sigue ahí. Los datos continuan cumpliéndolo y el programa sigue regido por él. Existe, por tanto, un esquema implícito que podríamos deducir con bastante certeza observando los datos almacenados y el código que los manipula.

Siguiendo con este experimento, podríamos preguntarnos… ¿no hemos perdido nada, verdad?

Aparentemente, no. En cuanto a funcionamiento, quizá ocultemos y amplifiquemos algún defecto que ya existía (la base de datos aceptará datos inválidos cuando antes los rechazaba, y muy probablemente, no nos daremos cuenta), pero realmente no habremos perdido mucho.

Pero cuando nos llegue el momento de modificar o ampliar el código, sí tendremos un problema: al no poder consultar el esquema, se dificultará mucho nuestra labor. El esquema explícito era eso: explícito, claro, fácil. El esquema implícito sigue ahí, pero está oculto. Lo duro es que antes bastaba con ajustarnos al esquema explícito de los datos, que estaba delante de nuestros ojos, pero ahora seguimos teniéndo que seguir un esquema de datos implícito, mucho más críptico. Tendremos que mirar los datos almacenados o el código para saber cómo se llamaba cada tabla y cada columna, y esta información muy probablemente no esté centralizada.

Por supuesto, hay un caso en el que sí seguirá disponible. Si usamos un algo como un ORM, podremos contar con otro esquema explícito de datos; la definición del ORM -e incluso en algunos casos podremos reconstruir perfectamente el esquema a partir de la definición del ORM- claramente son conceptos si no equivalentes siempre, muy cercanos***. Si este esquema es suficientemente bueno, podría suplir perfectamente al esquema explícito de las bases de datos (e incluso mejorarlo: podría permitirnos expresar un esquema de datos más restringido).

Podríamos decir que el esquema de datos explícito de la base de datos no es estrictamente necesario, pero ciertamente, un esquema de datos explícito es una herramienta muy útil, quizás no tanto para el funcionamiento de las aplicaciones como para su codificación y mantenimiento.

Adicionalmente, es bien cierto que puedan existir datos que no se ajusten al modelo relacional -cuya estructura o restricciones sean sumamente especiales (normalmente por ser extremadamente laxos), pero aunque esto fuera cierto, seguirían teniendo un esquema implícito (o incluso explícito, si la herramienta que usáramos en sustitución de la base de datos lo permitiera o requiriera, o si nosotros  decidiéramos escribirlo) y, igual que en el caso relacional, no disponer de un esquema explícito nos entorpecería las labores de mantenimiento y extensión del código.

Así pues, aunque es posible que un esquema relacional no sea lo más adecuado para nuestros datos, es falaz concluir que la ausencia de un esquema explícito es una ventaja -el esquema implícito sigue existiendo y nos debemos ajustar a él- y es más fácil ajustarse a algo explícito y claro que a algo implícito y oculto.

* en algunos gestores de bases de datos, el término se confunde un poco porque se pueden separar los objetos de la base de datos en “esquemas” para gestionarlos mejor

** las bases de datos permiten a las aplicaciones consultar el esquema [explícito]; hay aplicaciones que utilizan esta funcionalidad (para permitir su personlización mediante la creación de nuevas tablas, etc.); en este poco frecuente caso, dejarían de funcionar, claro

*** lo que nos debería llevar a pensar que uno de los dos es redundante e innecesario

corregido por el de siempre

Amigo lector

Se han escrito ríos de tinta sobre la muerte de Google Reader. Una de las mayores víctimas silenciosas, son los usuarios de Blackberry. Hasta el momento, yo usaba la web de iPhone; un vestigio raro ya que hay “app”, pero que era la mar de usable en mi móvil.

De entre todos los reemplazos de Google Reader que se barajan, aún no he encontrado ninguno que me solucione el uso móvil en la Blackberry- no parece haber nadie que tenga una web móvil usable [la de Netvibes ya os digo yo que no se puede usar] y de momento no se huele ninguna aplicación (y por mucho que esto me estigmatice, preferiría no pagar si es necesario [aunque en el caso del lector de feeds, podría hacer una excepción]).

Explorando alternativas, me he puesto un poco en plan hágaselo usted mismo. Feedly dice que implementará Normandy, un clon del backend de Google Reader y de momento apostaré por esta reimplementación. De hecho, Google Reader no tiene API “oficial”, pero mucha gente la ha destripado y documentado, y de hecho goza de cierta popularidad. Así pues, me he puesto a buscar librerías que implementen la API.

Dado que uno trabaja mayoritariamente Python/Django y Java, esto me ha limitado un poco la búsqueda. Para Java, el mejor candidato parece greader-unofficial, pero parece estar un poco muerto con tan solo 47 commits en su repositorio, el último de octubre de 2011. En cambio, naturalmente parece que para Python existe libgreader, con commits de anteayer y con mucha mejor pinta.

Así pues me he puesto manos a la obra y he iniciado un proyecto Django publicado en Github, GROLM (Google Reader on Lightweight Mobile). Es un proyecto Django 1.5 estándar sobre una base de datos PostgreSQL.

libgreader proporciona cuatro alternativas a la hora de manejar la autenticación contra Google Reader:

  • proporcionarle el usuario/contraseña de la cuenta Google y que él mismo autentique
  • OAuth
  • OAuth2
  • una variante de OAuth para Google App Engine

; obviamente la menos usable y/o poco segura es la de la contraseña, y tampoco quiero desarrollar sobre App Engine, así que me he decantado por OAuth2 (al ser más moderna obviamente que OAuth). El mecanismo de autenticación de OAuth2 de libgreader parece completo, pero deseaba integrarlo con el sistema de autenticación de Django para ahorrarme faena.

Para ello, he localizado django-social-auth, que integra en el sistema de autenticación de Django diversos mecanismos de login social entre los que se incluye OAuth2. La configuración de django-social-auth con OAuth2 es relativamente sencilla, simplemente tenemos que añadir el siguiente fragmento a nuestro settings.py:

INSTALLED_APPS = (
  # ...
  'social_auth',
)
AUTHENTICATION_BACKENDS = (
  'social_auth.backends.google.GoogleOAuth2Backend',
)
GOOGLE_OAUTH_EXTRA_SCOPE = [
  'https://www.googleapis.com/auth/userinfo.email',
  'https://www.googleapis.com/auth/userinfo.profile',
  'https://www.google.com/reader/api/',
 ]
LOGIN_URL = '/login/google-oauth2'
LOGIN_REDIRECT_URL = '/logged-in/'
LOGIN_ERROR_URL = '/login-error/'
GOOGLE_OAUTH2_CLIENT_ID = 'xxxx'
GOOGLE_OAUTH2_CLIENT_SECRET = 'xxxx'

, donde los dos últimos parámetros los podemos obtener de la Google API Console (donde también deberemos añadir las URLs de nuestra aplicación para validar el proceso de login)

Con esto, con anotar una vista como @login_required, al visitarla se nos redirigirá a la página de autenticación de las cuentas Google donde haremos login y se nos redirigirá de nuevo a la vista ya autenticados (se creará un usuario de Django correspondiente al usuario de Google y se vinculará a la sesión del usuario).

Finalmente, para “propagar” esta autenticación a libgreader, el mecanismo que he encontrado es extraer el token de acceso que recoge django-social-auth y almacena en una base de datos y pasárselo a libgreader, algo que he encapsulado en un módulo, pero que en realidad es bastante sencillo:

usa = UserSocialAuth.objects.get(user=user)
 auth = OAuth2Method(settings.GOOGLE_OAUTH2_CLIENT_ID, settings.GOOGLE_OAUTH2_CLIENT_SECRET)
 auth.authFromAccessToken(usa.extra_data['access_token'])
reader = GoogleReader(auth)

, donde user es el usuario (que desde una vista podemos obtener por ejemplo haciendo request.user). Una vez tenemos esto, ya obtenemos el objeto GoogleReader que constituye el punto de acceso a la API.

El resto de código implementado por el momento tan sólo obtiene la reading-list (los elementos sin leer) y muestra sus 20 primeras entradas.

Google Apps es de pago

(llego muy tarde a esto, disculpas)

Hace mucho mucho tiempo, Google sacó Google Apps con su edición gratuita. Nos daba una posibilidad de usar las aplicaciones de Google (GMail, Docs [ahora Drive], etc.), bajo un dominio propio y con administración centralizada de usuarios. ¡Y gratis!

Y hubo gran regocijo y cantidad de gente con dominio propio se hizo la cuenta gratuita, migró su correo y demás a Apps (perdiendo datos o con gran trabajo- yo tengo pesadillas de cuando pasé mis estrellitas de Google Reader…) y contempló maravillada la nueva realidad.

Inicialmente, Apps era gratuito hasta 25 usuarios, y a parte de ese límite, las características de la versión de pago no eran tan atractivas (si no recuerdo mal, más espacio, herramientas para migrar correo e integración con directorios, básicamente). Naturalmente, no sólo particulares se hicieron esto sino que empresas (sospecho que muchas) se pasaron a Google Apps.

Puedo entender la frustración que sintieron en Google al comprobar cómo empresas con ingresos para las que tendría todo el sentido del mundo contratar la versión de pago por un coste ínfimo (40€/usuario/año es ridiculo comparado con, pongamos, lo que cuesta el empleado- imaginad como os sentiríais si os aumentasen en 40€ el sueldo bruto anual…), utilizaban la versión gratuita (que Google vendía como para pequeñas asociaciones, familias y otras entidades no precisamente con ánimo de lucro). Obviamente no se trata de nada ilegal, e incluso si pensamos que Google es una empresa enorme con unos beneficios inimaginables, podemos defender que no se trata de algo inmoral siquiera… pero insisto, puedo comprenderles.

Así pues, fueron recortando. La versión gratuita se iba ocultando más y más, luego se redujo el límite de 25 a 10 usuarios y finalmente, se eliminó completamente.

Dos apuntes:

Uno, es posible que las empresas que “abusaron” (insisto en las comillas), hayan hecho que los verdaderos destinatarios del invento lo hayan perdido.

Dos, para los friquis que lo echamos de menos… ¿realmente aporta tanto? Lo más visible es el dominio personalizado para los emails, pero con las opciones de accounts y forwarding, se puede simular bastante bien con el GMail tradicional. La gestión centralizada de usuarios… vaya, si la necesitas es porque tienes bastantes usuarios (probablemente, más de 25).

Unos apuntes rápidos sobre Vagrant

En las últimas semanas he estado jugando bastante con Vagrant. Se trata de una herramienta para automatizar el uso de VirtualBox (de momento).

Básicamente, uno define en un Vagrantfile un conjunto de máquinas virtuales, basándose en unas máquinas virtuales plantilla (boxes, en su terminología), especificando los parámetros de virtualización (configuración de red, principalmente) y un mecanismo de provisionado (soporta Puppet y Chef, pero también podemos usar scripts de shell de toda la vida, por ejemplo).

Hacer boxes nuevos es bastante sencillo (básicamente, hay que usar unos usuarios y contraseñas establecidos, instalar las Guest Additions de VirtualBox y poco más), si bien un poco laborioso, aunque existen repositorios como www.vagrantbox.es que tienen bastantes boxes listos para descargar.

Con los boxes y el Vagrantfile, podemos arrancar rápidamente templates de, pongamos, Centos 6.3 con la red configurada y una carpeta compartida con el host (por defecto, la carpeta donde está el Vagrantfile se ve como /vagrant en la máquina virtual), algo que realmente no ahorra muchísimo tiempo respecto a hacerlo con VirtualBox desde cero, pero que es más conveniente.

Mediante el provisionado o el uso de boxes “tuneados”, podemos resolver bastante bien el típico problema de montar entornos de desarrollo en proyectos complejos. Podemos empaquetar un entorno ya configurado como box o box + script de provisionado, junto con un Vagrantfile que se puede editar fácilmente para adaptarlo a la máquina de cada desarrollador en concreto, con el que levantar la máquina ya configurada será cuestión de minutos, cuando anteriormente podían ser horas o llevarnos a la tentación de tener entornos de desarrollo más sencillos y menos parecidos que el de producción.

Pero yo el uso que le veo más interesante es para la administración de sistemas, pues nos permite adoptar un modelo bastante parecido al de desarrollo de software con test unitario. Podemos “desarrollar” nuestros sistemas como Vagrantfiles + scripts de provisionado; idóneamente con esto deberíamos conseguir levantar el sistema desarrollado completamente automatizadamente. Si conseguimos esto, el Vagrantfile y el script de provisionado es una documentación “perfecta” de lo que es el servidor; recoge al detalle cómo se configura todo e incluso podemos ejecutar el provisionado en el sistema “de producción” y asegurarnos entonces que disponemos de una máquina virtual y un sistema de producción idénticos. Tras tener esto, podemos hacer todas las pruebas que queramos en el entorno virtual, como instalar actualizaciones, probar cambios de configuración, sustituir programas… y las podemos probar simplemente destruyendo el entorno y recreándolo a partir del Vagrantfile y el provisionado. Podemos hacer pruebas una y otra vez de scripts para actualizar la configuración en el entorno virtual y luego lanzarlas en producción con un gran nivel de seguridad.

Lo único que le faltaría sería soportar algún mecanismo de verificación automático, pero es un detalle pequeño.

Aún así, Vagrant no es perfecto. Al parecer, ahora mismo sólo soporta VirtualBox (en teoría están trabajando en abstraer el código que trata con el sistema de virtualización, pero no queda claro su status); sería fantástico que se integrase con sistemas de virtualización más “de servidor” como VSphere o KVM, para poder pasar los sistemas montados con Vagrant a producción más automatizadamente (y poderlos probar sobre el hipervisor “final”). También echaría de menos un mecanismo para automatizar la actualización de boxes (e.g. hacer un yum update periódicamente a los box y que se reempaquetase, de manera que estuviesen siempre al día).

También cabe argumentar que realmente Vagrant es una capa muy fina sobre VirtualBox, y que se podría conseguir algo similar mediante las herramientas de línea de comandos de VirtualBox, pero aún así considero que más allá del detalle técnico, los desarrolladores de Vagrant han conseguido una herramienta muy usable y que resulta atractiva… algo que muchas veces es un gran factor a la hora de adoptar una herramienta nueva que te permite hacer cosas de una manera nueva.

En definitiva, ánimo a que probéis Vagrant, tanto para desarrollo como para administración de sistemas. Seguramente para lo segundo no aporte demasiado en entornos “serios”, pero para el “aficionado” puede ser muy interesante.

Conecte el teclado al televisor

Mi madre disfruta contando la historia de cómo el día que mi padre trajo el primer ordenador a casa, un flamante Commodore C64, mi padre, mi hermano y yo no comimos y nos quedamos enganchados al aparato. Ese día se trastocó el mundo: a la televisión, el medio masivo de comunicación, le había salido un teclado que invertía su característica principal, la pasividad. El teclado y el mando de plástico manipulaban lo que salía por la tele. El primitivo muñeco que representaba a un futbolista respondía al mando y, lo que quizás resultaba más mágico, si pulsabas las letras dibujadas en el teclado, estas reaparecían en el televisor.

Poco más tarde (y si se me permite introducir otra anécdota materna), tecleamos un programa de una revista. Como resultado, si nuestra madre nos decía una fecha, el ordenador respondía en qué día de la semana había caído nuestro nacimiento, o lo que fuese. El teclado no sólo permitía interactuar con lo que salía en pantalla, sino que nos permitía enseñar al aparato a hacer cosas que para nosotros eran bastante laboriosas y complejas (no para mi madre que, por supuesto, recordaba exactamente en qué día habían caído las efemérides).

Un poco alejados del nido, y un poco más tarde, nuestro padre nos llevaba a su oficina a jugar con un ordenador con módem. Después de escuchar durante unos segundos unos sonidos un tanto extraños, en la pantalla aparecían cosas tecleadas por otros en otros lugares. La experiencia evolucionaría poco después en la universidad, donde los ordenadores estaban constantemente conectados a una red en la práctica infinita que era la biblioteca más alucinante del mundo (a mediados de los 90 esto era tan alucinante en el concepto como ahora, pero mucho, muchísimo más sorprendente). En la biblioteca podías encontrar un montón de libros molones, pero en Internet había material escrito que nunca podías encontrar en una biblioteca; discusiones y análisis sobre cualquier tema que te gustase, por poco “culto” que fuera. Ríos y ríos digitales sobre juegos de rol, literatura fantástica, música… pero también sobre la misma tecnología que impulsaba todo aquello.

Muy poco después, entre asignaturas y mis prácticas como becario, dispuse de mi propio espacio en Internet, y con un poco de HTML pude publicar mi propia página personal con los contenidos que yo quería, que cualquiera podía leer. El conocimiento resultaba mucho más accesible y era extremadamente sencillo publicar contenidos propios.

El ordenador, en un periodo relativo corto de tiempo, había derrotado a la televisión con su interactividad, había introducido la programación y luego, había sido el punto de acceso a la redes de la información.

Irónicamente, creo que los pasos siguientes están yendo en el paso contrario.

A algunos ordenadores se les está cayendo el teclado. Sin él, al igual que el televisor antes de conectarle un teclado, reducimos nuestra interacción y nuestra capacidad de crear. Sí, interactuamos con juegos (juegos que a menudo nos remiten a los simples juegos del Commodore C64), y en ocasiones tecleamos, pero la mayor parte del tiempo miramos y, si acaso, hacemos scroll, seguimos enlaces y otras cosas sencillas como expresar nuestra aprobación a un mensaje.

Además, atrás quedan también los tiempos en el que el ordenador estaba a dos pasos de un entorno de programación o incluso al encenderse directamente interpreta lo que escribimos como un programa. Más allá de eso, cada vez se ponen más barreras a que programemos y distribuyamos nuestras creaciones. Hasta nuestras creaciones más sencillas escapan a nuestro control y grandes empresas privadas se reservan el derecho de hacer con ellas lo que quieran: principalmente, venderlas al mejor postor.

Sí, los avances tecnológicos son notables y las posibilidades de hacer cosas son cada vez mayores, pero como con la televisión, cada vez adoptamos un papel más pasivo, y cada vez parece más complicado hacer lo que anteriormente casi podía ser más sencillo que consumir.

Si bien es difícil valorar si globalmente estamos evolucionando o viendo una regresión, creo que es obvio que en ciertas áreas estamos retrocediendo. Y lo que es peor, este retroceso puede frenar los avances que se hacen por otros frentes. ¿Habrá tanta gente ahora a la que le dé por crear y programar? ¿Podremos seguir con el ritmo de evolución si menos gente se quiere dedicar a avanzar y prefiere sentarse en el sofá a consumir lo que hagan otros? O por el contrario, el hecho de que se reduzca la proporción de gente que quiere crear y no consumir será irrelevante porque aún así serán más dado que la tecnología ahora está al alcance de muchos más.

No es fácil predecir el futuro. Pero es preocupante cómo volverle a quitar los teclados a las pantallas en nombre de la comodidad y poner vallas a la distribución de contenidos y software en nombre de la seguridad puede hacernos dar pasos atrás en una de las áreas más importantes de los últimos tiempos.