Mejoras en Google Docs

Es bien conocida mi afición por las hojas de cálculo- esa herramienta de programación funcional frecuentemente mal empleada como base de datos que es fácilmente comprensible.

Así pues, celebro profundamente las mejoras introducidas por Google recientemente en la hoja de cálculo de Google Docs. Si aún no le habéis dado al botón de nueva versión (arriba, al lado de vuestro usuario)- la gran ventaja para mí es que ya no tenemos que editar y visualizar las fórmulas de las celdas en la misma celda (lo cual era harto incómodo, ya que el espacio era extremadamente reducido), sino que disponemos de un cuadro dedicado en la barra de herramientas como en el Excel.

Sobre el título de este blog

Según el Panhispánico de Dudas:

Por lo tanto, solo cuando en una oración exista riesgo de ambigüedad porque el demostrativo pueda interpretarse en una u otra de las funciones antes señaladas, el demostrativo llevará obligatoriamente tilde en su uso pronominal. Así, en una oración como la del ejemplo siguiente, únicamente la presencia o ausencia de la tilde en el demostrativo permite interpretar correctamente el enunciado: ¿Por qué compraron aquéllos libros usados? (aquéllos es el sujeto de la oración); ¿Por qué compraron aquellos libros usados? (el sujeto de esta oración no está expreso, y aquellos acompaña al sustantivo libros).

Así pues, cada vez que empleamos este, ese, aquel, etc., como pronombres, los amigos de la RAE esperan de nosotros que pensemos si hay ambigüedad posible; es incorrecto escribirlo con tilde si no la hay (o al menos eso interpreta un servidor).

Algo parecido pasa con solo/sólo- que cuando yo estudiaba, llevaba tilde siempre que podía ser sustituido por solamente, pero ahora sigue un criterio similar.

Decidí con solo/sólo rebelarme y escribir sólo con acento siempre que pueda sustituirse por solamente, y lo mismo voy a hacer con los demostrativos, y de ahí el título de este blog.

Sonidos galácticos

Una búsqueda sobre Saul Bass me ha llevado al ya conocido reinvento de los créditos de Star Wars a su estilo, y de ahí a este interesante vídeo sobre los mejores efectos de sonido de Star Wars. Si bien la elección es discutible (¿¡dónde está Chewbacca!?), celebro el reconocimiento al increíble trabajo de Ben Burtt, creador de algunos de los sonidos más icónicos y reconocibles de la historia.

Si desean saber más, recomiendo encarecidamente Galactic Phrase Book & Travel Guide: Beeps, Bleats, Boskas, and Other Common Intergalactic Verbiage, un libro en dos partes ilustrado por el enorme Sergio Aragonés que no sólo contiene una muy útil guía lingüística del universo Star Wars (la contraportada reza: “A must have when traveling without your protocol droid”), sino que viene seguida por un repaso a la creación de estos sonidos, donde podremos descubrir quién es Chewie, dónde está el sonido de encendido de un sable de luz y mil cosas más fascinantes.

JCR, Modeshape, programación web en general

Una cosa muy habitual requerida de un programador es realizar páginas web. La programación web, a un nivel muy alto, particularmente se preocupa de dos cosas:

  • Generar contenido- usualmente HTML– en respuesta a una petición HTTP para una URL. Es decir, cuando en nuestro navegador introducimos http://www.google.com, los servidores de Google nos responden con un HTML con la página de búsqueda de Google.
  • Procesar formularios. Tecleo la entrada de este blog en el interfaz de administración; cuando le doy a “Publicar”, los datos del formulario se envían al sistema de mi blog, que los procesa y los introduce en la base de datos del blog.

Hoy nos ocuparemos, en parte, de lo primero.

¿Cómo almacenamos el contenido de nuestra web?

Una primera aproximación sencilla es guardarlo en el sistema de archivos. Algo tan sencillo como guardar el HTML en carpetas del servidor funciona casi sin esfuerzo- simplemente le decimos a nuestro servidor web que para cada petición HTTP busque un fichero con la misma ruta y nombre que la petición y lo sirva al usuario.

Lógicamente, normalmente esto no es suficiente. Por ejemplo, no queremos repetirnos continuamente con la cabecera y pie de nuestra página web en cada HTML que creamos. Aquí, cosas tan sencillas como los server-side includes, el PHP o cualquier cosa con directiva “include” puede bastar.

Otro problema que plantea esta alternativa es su falta de versatilidad. Una evolución lógica (y popular) es guardar los contenidos en una base de datos, típicamente una que use SQL (básicamente, una base de datos relacional). Creamos un esquema de datos de la información que queremos mostrar en nuestra página (por ejemplo, entradas de blog, usuarios, categorías, etc.) y programamos una serie de páginas que, en función de la URL que nos piden, recupera la información de la base de datos y crea un HTML con esa información.

Esta mecánica es profundamente popular, y una parte muy significante de la web actual está implementada de esta manera.

Sin embargo, la opción más popular, las bases de datos SQL, no son apropiadas para todos los contenidos que queramos mostrar en una web. Las bases de datos suelen representar datos altamente estructurados, con esquemas rígidos (es decir, un usuario tiene un nombre, email; una entrada de blog tiene título, autor, fecha de modificación, cuerpo, etc.), y los sistemas de presentación web basados en bases de datos SQL suelen ser por consecuencia, rígidos. Esto en muchas ocasiones no es especialmente problemático, en otras es fastidioso pero soportable y en ocasiones, puede ser muy incómodo.

Lógicamente surgen alternativas a las bases de datos SQL; el movimiento NoSQL abandera a toda una serie de bases de datos no relacionales que se oponen a usar SQL. Normalmente, por motivos erróneos y en gran medida motivados por la existencia de MySQL, probablemente la menos relacional y SQLifica base de datos popular que existe.

Por mucho que uno opine que la mayoría de argumentos que esgrimen los defensores del NoSQL, uno sí piensa que pueden existir cosas mejores para almacenar contenidos para web. Una tecnología interesante en este sentido es Java Content Repository, un mecanismo de almacenaje de información muy adecuado para el contenido web. Unas cuantas características de los repositorios JCR son:

  • Jerárquico. Los contenidos (nodos) de JCR se organizan en una jerarquía, directamente identificable con la jerarquización típica de las URLs del contenido web
  • Versionado/con espacios de trabajo. Podemos almacenar todas las versiones que vayan habiendo del contenido, y disponer de varios espacios de trabajo paralelos (e.g. el espacio de trabajo público, un espacio de trabajo de borradores, etc.)
  • Con metadatos. Podemos almacenar metadatos sobre el contenido (autor, fecha de publicación, etc.) de una manera flexible

Así pues, en principio, JCR parece un sistema muy útil de cara a almacenar información web. Lo interesante de JCR es que es sólo una API, con varias implementaciones. Así, un repositorio JCR podría guardar su información en una base de datos SQL, en una NoSQL o en cualquier cosa que se le ocurre al implementador.

Y es aquí donde aparece Modeshape de JBoss. Modeshape es un JCR cuyo almacenaje es flexible. Más bien, JCR es una librería para implementar JCRs. Podemos implementar JCRs que cojan los datos de una base de datos, de otro JCR, de una fuente de datos NoSQL, de lo que sea. Y también nos permite unificar varios JCRs y acceder a ellos como si fueran uno.

Esto es harto interesante. Muchas aplicaciones web quieren recoger datos de diversas fuentes- algunas preexistentes y otras que se crean ad-hoc para la aplicación web en cuestión. Mediante Modeshape, podemos unificar el acceso a estas fuentes de dato, creando un adaptador a JCR que nos permita acceder a todos los datos que requerimos presentar vía web, mediante un mecanismo especialmente adecuado para su presentación web.

Para completar una aplicación web- o al menos su parte de presentación de contenidos, sólo necesitaríamos añadir algo que exponga el repositorio JCR que creamos a la web, lo cual sería algo interesante a comentar otro día.