El blog de pico.dev

Mantenimiento CRUD en Apache Tapestry

2013-06-14T18:10:00.000+02:00

El scaffolding es una ayuda que permite a partir de una descripción disponer de una funcionalidad sin escribir una línea de código o muy pocas exceptuando las necesarias para la descripción. En funcionalidades que se repiten mucho en una aplicación, no aportan mucho valor y son aburridas de programar puede llegar ahorrar una cantidad considerable de tiempo y disponer de un prototipo funcional muy rápidamente. Es utilizada por varios frameworks web en diferentes lenguajes para hacer los mantenimientos CRUD (Create, Read, Update, Delete) de las tablas de una base de datos relacional:

Ruby on Rails
Symfony
Grails
Y quizá algunos otros menos conocidos

El problema de los scaffoldings viene cuando la funcionalidad que proporcionan no es suficiente, no se adapta a lo que necesitamos o no nos gusta lo que se genera y nos vemos en la obligación de personalizarlo, los scaffolding son tan básicos que si tenemos una aplicación un poco compleja probablemente deberemos adaptarlos. En ese caso no nos quedará más remedio que programar lo que necesitemos. Algunos frameworks permiten generar un código inicial a partir del que comenzar la programación. Esto es el caso de Grails y el código generado deja bastante que desear (en mi humilde opinión), el CRUD de una tabla tiene cinco gsp, entre ellas una para el alta y otra para la modificación que son prácticamente iguales con lo que contiene bastante código repetido también en el controlador para las acciones save y update que para luego mantenerlo supone problemas. Una vez que el código está generado y lo hemos personalizado con alguna modificación al salir una nueva versión del framework (y tarde o temprano saldrá) tendremos la duda de si el código que se nos generó con una versión anterior se ha quedado obsoleto en la nueva versión, dudaremos si partir del código inicial que genera la nueva versión e incorporar las cambios que hicimos o si adaptamos el código que tenemos con los nuevos cambios.

Como resultado al final disponer de un framework que tenga scaffolding con el tiempo puede no suponer tanto ahorro de tiempo como puede parecer en un principio. Tapestry no proporciona un scaffolding para hacer estos CRUD aunque si proporciona varios componentes avanzados que ayudan mucho a realizarlos (Grid, BeanEditor). A continuación pondré un ejemplo de una funcionalidad similar a un CRUD realizada con el framework Apache Tapestry. En el ejemplo se podrá mantener una tabla de una base de datos pudiendo dar de alta una nuevos registros, eliminarlos, modificarlos y ver sus datos en una tabla con paginación Ajax. En el se verá que todo esto no supone más de 200 líneas de código Java y 80 líneas de código de presentación en tml. Necesitará solo dos archivos, uno para código Java, otro para el de presentación tml e increiblemente ninguno para código Javascript a pesar de hacer la paginación via Ajax. En estos números no estoy incluyendo varias clases de apoyo como la entidad a persistir o su DAO (Data Access Object) ya que no son propios de un único scaffolding sino que se podría utilizar para todos los que tengamos en la aplicación.

En la entrada sobre persistencia JPA usando Tapestry ya expliqué como construir el servicio y la transaccionalidad. En el siguiente código utilizaré ese servicio DAO para el acceso a la base de datos, no cambia nada. Me centraré en poner el código necesario para la página que necesita proporcionar la funcionalidad del scaffolding.

A continuación el código Java en la que principalmente Tapestry se encarga de llamar al método que actúa de escuchador para cada evento que se produzca en la página, en función del evento se llamará a la operación DAO adecuada y actualizar el estado del controlador.

Ahora el archivo tml que se encarga de generar el html que se enviará al navegador. En el mismo archivo está el código para mostrar el listado y para realizar la edición tanto en el alta como en la modificación. En función del estado de la página se mostrará uno u otro haciendo uso del componente Delegate. Para ver la paginación en funcionamiento sin necesidad de crear muchos objetos solo será necesario crear dos, esto es, las páginas solo contendrán dos elementos.

Eso es todo lo propio que necesita el scaffolding y sería lo único necesario para realizar otros similares. Sin embargo, este hace uso de unas cuantas clases de utilidad. Entre ellas la clase que proporciona la funcionalidad de paginación al acceder a la lista de entidades. A partir de los datos de paginación que el data source indica (elemento de inicio, de fin y orden) se construye el objeto que contendrá esta información y se le enviará al DAO para que haga la consulta adecuada.

Finalmente, como comenté un una entrada anterior sobre seguridad sobre XSS (Cross Site Scripting) el mantenimiento está protegido ante este tipo de ataques (puedes probar crear un producto con <script>alert(1);</script>), para ello no hemos hecho nada especial.

Y otro par de clases muy sencillitas que continenen los datos para que el DAO sepa como se quiere la ordenación y que elementos paginados se quieren.

El resultado de la lista, la modificación de un producto y el alta habiendo errores de validación es este:

Como en el resto de entradas el código fuente completo lo puedes encontrar en mi repositorio de GitHub. Si quieres probarlo en tu equipo lo puedes hacer de forma muy sencilla con los siguientes comandos y sin instalar nada previamente (salvo java y git). Si no dispones de git para clonar mi repositorio de GitHub puedes obtener el código fuente del repositorio en un archivo zip con el anterior enlace.

Referencia:
Documentación sobre Apache Tapestry

Persistencia con JPA y Apache Tapestry

2013-06-07T20:24:00.000+02:00

En Java disponemos de varias opciones para persistir la información a una base de datos relacional, algunas de ellas son:

JDBC: es la API que viene integrada en la propia plataforma Java sin necesidad de ninguna librería adicional exceptuando el driver JDBC para acceder a la base de datos. Mediante esta opción se tiene total flexibilidad y evita la abstracción y sobrecarga de los sistemas como Hibernate y JPA. Se trabaja con el lenguaje SQL de forma directa y este lenguaje puede varia en algunos aspectos de una base de datos a otra con lo que para migrar a otra base de datos puede implicar reescribir las SQL de la aplicación. Su utilización de forma directa no es tan habitual aunque en casos que se necesite acceder de forma masiva a los datos puede se útil para evitar la sobrecarga o complejidad que añaden sistemas como Hibernate o JPA.
Hibernate: el modelo relacional de las bases de datos es distinto del modelo de objetos del los lenguajes orientados a objetos. Los sistemas ORM como Hibernate tratan de hacer converger el sistema relacional hacia un modelo más similar al modelo de objetos de lenguajes como Java, de forma que trabajar con ellos sea como trabajar con objetos. En ORM como Hibernate normalmente no se trabaja a nivel de SQL como con JDBC sino que se trabaja con objetos (POJO), las consultas devuelven objetos, las relaciones se acceden a través de propiedades y los borrados, actualizaciones y inserciones se realizan usando objetos y métodos. Los objetos POJO incluyen anotaciones que le indican a Hibernate cual es la información a persistir y las relaciones con otros POJO. Como hibernate dispone de esta información en base a ella puede recrear o actualizar las tablas y los campos necesarios según la definición de esas anotaciones. El ORM es encarga de traducir las acciones a las SQL entendidas por el sistema relacional, esto proporciona la ventaja adicional de que el ORM puede generar las sentencias SQL adaptadas a la base de datos utilizada. De esta forma se podría cambiar de una base de datos a otra sin realizar ningún cambio en la aplicación o con pocos cambios comparado con los necesarios usando JDBC. Con Hibernate se puede emplear un lenguaje de consulta similar a SQL pero adaptado al modelo orientado a objetos, el lenguaje es HQL.
JPA: es una especificación de Java que define una API común para los sistemas ORM. Con JPA podríamos cambiar de proveedor ORM sin realizar ningún cambio en la aplicación. JPA se ha basado en gran parte en Hibernate y su forma de trabajar es similar, el lenguaje HQL también es similar pero denominado JPQL.

A continuación explicaré como acceder a una base de datos relacional a través de JPA en una aplicación web usando el framework Apache Tapestry. Lo primero que deberemos hacer es crear el archivo persistence.xml donde indicaremos el driver JDBC según la base de datos que utilicemos y la URL de conexión a la base de datos entre otras opciones como el usuario y password de conexión. En el ejemplo he usado H2 como base de datos ya que puede embeberse en una aplicación sin necesidad de tener un sistema externo como ocurren en el caso de MySQL y PostgreSQL. De esta forma este ejemplo puede probarse sin necesidad de instalar previamente ninguna base de datos relacional.

En la aplicación es necesario incluir unas pocas dependencias para acceder a la API JPA.

Una vez incluidas las dependencias debemos configurar Tapestry para que nos proporcione el soporte de acceso a una base de datos empleando JPA, definimos en el módulo de la aplicación y contenedor de dependencias, el servicio DAO y al mismo tiempo configuraremos la transaccionalidad mediante anotaciones para el DAO.

Las clases con capacidad de persistencia han de ubicarse en un subpaquete del paquete de Tapestry. El paquete de Tapestry es aquel que está indicado en el parámetro de contexto tapestry.app-package en el archivo web.xml de la aplicación web. Si tapestry.app-package fuese es.com.blogspot.elblogdepicodev.tapestry.jpa el paquete de las entidades debería ser es.com.blogspot.elblogdepicodev.tapestry.jpa.entities. Esta es la convención y la forma preferida de hacerlo, si se quiere cambiar es posible hacerlo mediante configuración. La entidad de persistencia que usaré para el ejemplo es la siguiente, en la que se incluyen las anotaciones de JPA:

El código de acceso a base de datos suele ponerse en una clase denominada servicio y DAO (Data Access Object) que contiene todo ese código. Ya que las operaciones de acceso a base de datos son candidatas a ser reutilizadas desde varias páginas o componentes es recomendable hacerlo así, además de hacer que las páginas de Tapestry sean más pequeñas (ya tienen suficiente responsabilidad con hacer de controlador en el modelo MVC) permite que si un día cambiásemos de framework web solo tendríamos que modificar la capa de presentación. Todo el código de los servicios nos serviría perfectamente sin hacer ninguna modificación.

El contenedor de dependencias se encargará en el momento que necesite construir una instancia del servicio DAO inyectarle en el constructor los parámetros necesarios. En este caso una de las clases principales de la API JPA que es EntityManager. Una vez con la referencia a entityManager trabajaríamos usando sus métodos para realizar las consultas y operaciones que necesite proporcionar el DAO.

Hay métodos del DAO que finalmente lanzan sentencias de inserción, modificación y borrado, este DAO es muy sencillo pero si realizase varias operaciones contra la base de datos estas deberían cumplir las reglas ACID. Para cumplir las reglas ACID hay que utilizar transacciones, se puede conseguir de forma declarativa utilizando la anotación @CommitAfter. Esta anotación inicia una transacción al iniciarse el método y lanza un commit al finalizar el método. En caso de que se produzca una excepción se seguirá haciendo commit para las excepciones checked (de obligado tratamiento o lanzado) y únicamente un rollback para las excepciones unckecked (que extienden de RuntimeException y no es necesario capturarlas o lanzarlas).

Si quisiésemos hacer rollback en una excepción checked deberíamos hacerlo manualmente capturando la excepción y lanzando una unchecked aunque si es la opción que queremos por defecto podríamos implementar una anotación para tratar la transaccionalidad de esta manera y de forma declarativa en todos los casos.

Una vez que tenemos el servicio DAO basta con inyectarlo en la clase de una página o componente y hacer uso de él. En la siguiente página se muestra un listado de productos donde con un botón se pueden eliminar y con otro se pueden crear nuevos. En la clase de la página se hace uso del DAO para buscar las entidades, crear una nueva con un nombre y descripción aleatoria y eliminar un producto.

Esta es una captura de pantalla del ejemplo en ejecución:

Para casos más complejos de transacciones como transacciones anidadas, requeridas, soportables, ninguna u obligatoria podemos basarnos en lo comentado en esta entrada donde queda perfectamente explicado.

Como en el resto de entradas el código fuente completo lo puedes encontrar en mi repositorio de GitHub. Si quieres probarlo en tu equipo lo puedes hacer de forma muy sencilla con los siguientes comandos y sin instalar nada previamente (salvo java y git). Si no dispones de git para clonar mi repositorio de GitHub puedes obtener el código fuente del repositorio en un archivo zip con el anterior enlace.

Referencia:
Documentación sobre Apache Tapestry
http://es.wikipedia.org/wiki/Java_Database_Connectivity
https://en.wikipedia.org/wiki/Relational_database
http://en.wikipedia.org/wiki/Cardinality_(data_modeling) http://en.wikipedia.org/wiki/ACIDhttp://en.wikipedia.org/wiki/SQL http://en.wikipedia.org/wiki/NoSQLhttp://en.wikipedia.org/wiki/Hibernate_(Java)

Seguridad en aplicación web con Apache Tapestry (II)

2013-05-31T18:15:00.000+02:00

Si en la anterior entrada hablaba de la seguridad sobre los aspectos de la autenticación y autorización de las acciones que puede realizar los usuarios en una aplicación web en esta hablaré como protegerse de otro tipo de fallos de seguridad, XSS e inyección de Sql.

Otros dos aspectos muy a tener en cuenta desde el inicio y durante el desarrollo de una aplicación web son los siguientes:

XSS (Cross site scripting): es una vulnerabilidad que pueden sufrir las aplicaciones por básicamente no controlar los datos que un usuario envía a través de formularios o como parámetros en las URL. Por ejemplo, supongamos una aplicación recibe un formulario con un nombre que se escupe tal cual se envió en otra página de la aplicación y que otros usuarios pueden visualizar en sus navegadores posteriormente cuando accedan a las páginas que los muestran. Una posible situación puede darse cuando los datos enviados se guardan en una base de datos, un usuario los envía se guardan en la base de datos y otro usuario los ve. Ese dato puede ser una cadena inofensiva como el nombre que se pide pero un usuario malicioso puede enviar código javascript o una imagen con una URL que puede recolectar con cualquier propósito la información de los usuario que la ven en su navegador. Un usuario enviando los datos adecuados puede explotar esta vulnerabilidad y conseguir desde obtener la sesión de otro usuario y hacer cualquier tipo de acción como si fuera ese otro usuario, hasta obtener datos y distribuir virus a los usuarios a través de nuestra propia página web.
Inyección Sql: esta vulnerabilidad puede ser explotada también por confiar en los valores que envía el usuario pero en vez afectar al html que genera la aplicación web afecta a las base de datos que utilice la aplicación. Si usamos los parámetros enviados por una fuente no confiable para construir las sql de forma dinámica concatenando trozos de sentencia con los parámetros, un parámetro con el valor adecuado puede modificar completamente la sentencia. Concatenando elementos se puede terminar una Sql y hacer cualquier otra a continuación. Las posibilidades de esto es que se podría extraer cualquier dato o borrar completamente la base de datos con sentencias delete o drop. Por ejemplo, hacer esto tiene el problema de la inyección de Sql: "select * from producto where id = " + id. Si el parámetro id tuviese el valor "1; delete from producto;" podríamos borrar todos los datos de la tabla.

Por tanto, tanto para evitar fallos de seguridad por XSS y de inyección Sql no se debe confiar en ningún dato enviado por el usuario o de un sistema externo. En realidad en ambos problemas de seguridad la situación es el misma pero que afecta a distintas partes de la aplicación, en un caso a la base de datos (inyección Sql) y en otro a la capa de presentación de la aplicación (XSS).

¿Que hay que hacer para evitar estos problemas? Depende del caso. Para evitar XSS todo lo que se emita en el html de la página y se envíe al navegador del usuario ha de ser codificado como html haciendo que si hay un dato malicioso sea inofensivo ya que el navegador no lo interpretará como parte del lenguaje de marcas html sino como texto. Para evitar la inyección de Sql si construimos alguna dinñamicamente los parámetros no se han de añadir concatenándolos. En Java con PreparedStatement, y seguro que en cualesquiera otros lenguajes, por un lado va la sql y por otro los parámetros, la clase o API que utilicemos se encargará de ejecutar la sentencia con los parámetros adecuados sin el problema de la inyección Sql (además tiene la ventaja de que el código será más legible al no estar mezclada con los parámetros concatenados).

A continuación explicaré que funcionalidades proporciona Tapestry para que las aplicaciones desarrolladas con él sean más seguras en cuanto a XSS.

Para evitar XSS todo lo que se genere como html a partir de datos recuperados de la base de datos y enviados por un usuario hay que escaparlo. Y Tapestry hace eso por defecto por lo que salvo que de forma expresa no hagamos el escapado no tendremos problemas de XSS. La generación de html se puede hacer de dos formas: en los archivos de plantilla tml o en código Java si se trata de un componente que no tiene plantilla tml asociada.

Con una plantilla tml haremos lo siguiente y el nombre se mostrará escapado en el html:

Para evitar escapado hay que usar la opción:

En el componente Java usaremos la clase MarkupWriter y su método write para escapar los valores y el método writeRaw para evitar el escapado si estamos seguros de que no implica un problema de seguridad:

Para evitar inyección de Sql usando Hibernate, JPA o la clase PreparedStatement y separando los parámetros de la sql o hql estaremos protegidos. Las buenas prácticas y un ejemplo de mala práctica usando la API de Hibernate, hql y sql para hacer las búsquedas son las siguientes:

En la siguiente imagen puede verse como se puede inyectar javascript enviando un formulario con dato que no es escapado correctamente al mostrar su valor de nuevo.

Seguridad en aplicación web con Apache Tapestry

2013-05-24T19:09:00.000+02:00

Además de la persistencia en una base de datos, otra de las funcionalidades comunes que suele necesitar una aplicación es la seguridad. En la seguridad hay varios aspectos a tratar que son:

Autenticación: que consiste en identificar al usuario en el sistema y comprobar que el usuario es quien dice ser. Normalmente la autenticación se suele realizar pidiéndole al usuario su identificativo, nombre de usuario o correo electrónico y una contraseña que solo él conoce. Aunque hay otras formas de realizarlo entre ellas los certificados.
Autorización: que consiste en determinar si el usuario autenticado tienen permisos para realizar una determinada operación. La autorización puede realizarse mediante roles, permisos o una combinación de ambos dependiendo de lo adecuado para la operación. Pero en ocasiones no solo hay que validar si un usuario tiene permisos para para realizar una acción, también puede ser necesario restringir la operación sobre ciertos datos, los que se determinen que él está autorizado a modificar, si no se hiciese esto un usuario podría alterar los datos de otro y el sistema tener una brecha de seguridad.

La autenticación y la autorización son solo dos aspectos a considerar pero no son suficientes para considerar una aplicación segura. Otros aspectos a tener en cuenta son XSS (Cross Site Scripting), la inyección de Sql o las conexiones cifradas SSL/TLS pero estos serán tema para otras entradas.

La información de autenticación y autorización puede guardarse en diferentes formas en lo que se conocen como Realms comunmente en Java. Algunos Realms puede ser simples archivos de texto plano aunque por su dificultad de mantenimiento al añadir nuevos usuarios, permisos o roles y que puede requerir un reinicio de la aplicación se suele optar por opciones como una base de datos relacional, un sistema LDAP o una base de datos nosql.

Para tener un sistema seguro no basta con ocultar las opciones que un usuario no puede realizar. Ocultar las opciones está bien pero también hay que realizar las comprobaciones de autorización en el caso de una aplicación web en el servidor, al igual que no basta con realizar las comprobaciones de validación de datos en el cliente con javascript, en ambos casos las comprobaciones hay que hacerlas en el lado del servidor también, de lo contrario nada impediría a un usuario conociendo la URL y datos adecuados a enviar realizar algo que no debería (advertido estás si no quieres que te llamen un sábado de madrugada).

La seguridad puede aplicarse de dos formas o una combinación de ambas:

De forma declarativa: ya sea mediante anotaciones o en un archivo independiente del código. Esta es la opción preferida ya que de esta manera el código de la aplicación no está mezclado con el aspecto de la seguridad.
De forma programática: si la opción declarativa no no es suficiente para algún caso podemos optar por hacerlo de forma programática, mediante código, con la que tendremos total flexibilidad para hacer cosas más específicas si necesitamos aunque mezclaremos el código de la aplicación con el código de seguridad.

Para aplicar seguridad en una aplicación Java disponemos de varias librerías, entre las más conocidas están:

Las dos librerías son similares aunque se comenta que Apache Shiro es más fácil de aprender. Además de integraciones con estas librerías Apache Tapestry dispone de módulos para realizar autenticación con servicios de terceros como Facebook, Twitter o sistemas OpenID.

Pero veamos como aplicar seguridad a una aplicación web que use el framework Apache Tapestry. En el ejemplo usaré el módulo tapestry-security que a su vez usa Apache Shiro. El ejemplo consiste un una página a la que solo los usuarios autenticados pueden acceder, en ella los usuarios podrán realizar varias operaciones: sumar a una cuenta uno, dos, tres, restar uno o poner la cuenta a cero en función de los permisos y roles que tengan. Para autenticase se usa un formulario aunque perfectamente podría usarse una autenticación BASIC.

Por simplicidad en el ejemplo los usuarios, passwords, roles y permisos los definiré en un archivo de texto, aunque en un proyecto real probablemente usaríamos una base de datos accediendo con hibernate para lo cual deberíamos implementar unos pocos métodos de la interfaz Realm o si necesitamos autorización la interfaz AuthorizingRealm de Shiro. El archivo shiro-users.properties sería el siguiente:

Por una parte se definen los usuarios con su password y roles que posee y por otro se definen los roles y los permisos que tiene cada uno.

La única configuración que deberemos indicarle a Tapestry es la URL de la página que autenticará a los usuarios y la página a mostrar en caso de que el usuario no esté autorizado para realizar alguna operación y el Realm a usar, lo hacemos añadiendo el siguiente código al módulo de la aplicación:

La página que realiza la autenticación es muy simple, poco más se encarga de recoger el usuario y password introducidos en el formulario de autenticación y a través del Subject realiza el inicio de sesión.

Una vez configurado el módulo y hecha la página que realiza la autenticación solo debemos usar de forma declarativa las anotaciones que proporciona Shiro, en el caso de la página Index @RequiresUser para permitir solo a los usuarios autenticados entrar a esa página y sobre las operaciones @RequiresPermissions para requerir ciertos permisos para ejecutar las acciones o @RequiresRoles para requerir ciertos roles. Estas anotaciones podemos usarlas no solo en las páginas y componentes de Tapestry que forman parte de la capa de presentación sino también en los servicios que desarrollemos y que forman la capa de lógica de negocio.

Si las anotaciones no son suficientes podemos hacerlo de forma programática, este es el probable caso de que un usuario solo debería modificar los datos relativos a él sin poder modificar los de otros usuarios. El código variará en función de la forma de determinar si el usuario tiene permisos para un dato. Para comprobar si un usuario tiene ciertos permisos de forma programática debemos usar el objeto Subject que tiene muchos métodos para realizar comprobaciones, como para reinicializar la cuenta se ha de tener el permiso «cuenta:reset» se debe hacer lo codificado en el método onActionFromReset:

En la plantilla de presentación que genera el html también deberemos hacer algunas comprobaciones de seguridad, básicamente para mostrar los enlaces a los que un usuario tenga permisos.

A continuación unas capturas de pantalla de la aplicación de la página de inicio autenticación, de la página con el índice de acciones y de la página de acción no autorizada:

Para hacer uso de tapestry-security deberemos incluir la librería como dependencia en el archivo build.gradle del proyecto:

Como en el resto de entradas el código fuente completo lo puedes encontrar en mi repositorio de GitHub. Si quieres probarlo en tu equipo lo puedes hacer de forma muy sencilla con los siguientes comandos y sin instalar nada previamente (salvo java y git). Si no dispones de git para clonar mi repositorio de GitHub puedes obtener el código fuente del repositorio en un archivo zip con el anterior enlace.

Para finalizar, a pesar de lo simple del ejemplo pero suficientemente representativo de lo que podría requerir una aplicación real comentar lo sencillo y limpio que ha sido aplicar la seguridad, por una parte gracias al uso de anotaciones y por otra gracias a Tapestry de por si.

Referencia:
Documentación sobre Apache Tapestry
http://tapestry.apache.org/security.html
http://tapestry.apache.org/
http://shiro.apache.org/
http://static.springsource.org/spring-security/site/index.html

Copia de seguridad con rsync

2013-05-17T17:50:00.001+02:00

Las copias de seguridad son imprescindibles, si alguien piensa que no es que nunca se le ha estropeado el ordenador ya sea porque ha fallado el hardware o por una actualización que ha corrompido el sistema de arranque o peor por que el disco duro se ha estropeado, eso o no tiene datos importantes que tener a buen recaudo. Si aún no te ha pasado que se haya estropeado el ordenador y te has quedado sin esa información que no quieres perder quizá hayas tenido suerte pero has de saber que tarde o temprano te pasará y para no perder esa información los «backups» son imprescindibles.

Una vez que tener copias de seguridad nos parece importante y tenemos respondida la pregunta de por qué, se nos plantean algunas otras preguntas:

¿De que hacer copias de seguridad?
¿Cada cuanto hacer copias de seguridad?
¿Que características han de tener las copias de seguridad?
¿En que medio guardar las copias?
¿Como hacer las copias de seguridad?
Y tan importantes como las anteriores, ¿como recuperar los datos?

Cada pregunta tiene diferentes respuestas según el usuario, entorno o la información de la que hacer las copias de seguridad. A la pregunta de que hacer copias de seguridad cada uno deberá conocer que información no quiere perder en caso de desastre, cuanto cambian los datos y que se perdería en un periodo de tiempo (día, semana, mes, ...), si las copias deben estar comprimidas para ahorrar espacio o cifradas y finalmente dependiendo de algunas respuestas anteriores que herramienta o herramientas usar.

Yo hasta ahora no usaba ninguna herramienta usaba el simple y manual método de copiar y pegar archivos del disco duro del ordenador a un disco duro externo. Cuando no tenía disco duro externo las copias de seguridad las hacía en CD y DVD pero hacerlas en un medio óptico como los anteriores no los recomiendo porque son lentos de realizar, en estos días no tienen capacidad suficiente para guardar todo y por tanto deberemos tener varios volúmenes y finalmente lo más importante porque son unos medios poco fiables. Dado el precio y capacidad que tienen hoy en día los discos duros USB externos además de su velocidad de transferencia es más recomendable esta opción y es la que a día de hoy uso. Pero aún con un disco duro externo el método de copiar y pegar tarda un buen tiempo y sigue siendo lento, con 70 GiB de archivos personales que no quiero perder, pero también el hecho de hacerlo manualmente es propenso a que algún día se me olvide hacer la copia de seguridad de todo y por la ley de Murphy ese día fallará el ordenador. Con lo que con esta situación he empezado a buscar alternativas a mi método manual de copiar y pegar.

Empece probando Déjà Dup pero no me ha convencido porque las copias de seguridad las guarda en un formato comprimido (y cifrado si se quiere) de modo que para recuperar los archivos se ha de utilizar la misma herramienta. Para mi una de las características de la copia de seguridad es que siga pudiendo tener accesibles los archivos independientemente de la herramienta. Viendo las posibilidades de los programas de copia de seguridad disponibles en Linux por la que me he decantado ha sido rsync. Es un método simple que mantiene sincronizados el contenido de dos carpetas, copiando los nuevos archivos, borrando los eliminados y solo actualizando los necesarios además de poder hacerse las copias entre dos máquinas diferentes a través de la red. Mediante rsync para hacer una copia de seguridad ahora tardo mucho menos ya que solo se copian los archivos que hayan cambiado además de estar automatizado con un script con lo que resulta más fácil y por ello se pueden hacer más a menudo.

Con el siguiente comando de rsync se puede hacer una copia de seguridad de una carpeta a otra:

La opción -a es una meta opción de utilidad que engloba otras con las más comunes para hacer copias de seguridad, -P hace que se muestre el progreso, --delete borra los archivos en la carpeta de destino que se hayan borrado en la carpeta origen.

Otro ejemplo para copiar varias carpetas de la carpeta home de un usuario es, con la opción --files-from, hay que indicar también la opción -r para que las carpetas se copien de forma recursiva:

Este simple comando ahorra mucho tiempo ya que con él no hay que copiar los XXX GiB cada vez que hay que hacer un copia de seguridad, solo se copiará lo que haya cambiado entre la copia de seguridad y el origen, que muy probablemente es una cantidad mucho menor que esos XXX GiB. Con lo simple que es se me hace extraño que haya pasado tanto tiempo haciendo las copias de seguridad manualmente.

Si quieres algunas otros ejemplos de uso de rsync como por ejemplo el como programar las copias de seguridad con cron o quieres conocer otras herramientas en la wiki de Arch Linux tienes unas cuantas más, algunas con interfaz gráfica.

Referencia:
https://wiki.archlinux.org/index.php/Backup_Programs
https://wiki.archlinux.org/index.php/Rsync

Modificar la base de datos con Liquibase

2013-05-10T18:19:00.000+02:00

A lo largo del ciclo de desarrollo de todo proyecto se producen cambios algunos de los cuales casi con toda seguridad afectarán al esquema o modelo de la base de datos. Por una parte se pueden producir modificaciones de definición de datos (DDL, Data Definition Language) para añadir y borrar tablas y añadir, modificar y eliminar campos, crear índices y restricciones de integridad. Por otra parte se pueden producir manipulaciones de datos (DML, Data Manipulation Language) para añadir nuevos datos, modificar o eliminar algunos de los existentes. Estos cambios de la base de datos también puede ser útil que estén bajo el sistema de control de versiones que empleemos al igual que hacemos con los cambios del código fuente del programa para poder volver a un estado anterior. Una herramienta que nos permita hacer «refactor» de forma automatizada de la base de datos nos facilitará la tarea.

Para llevar a cabo estas modificaciones tenemos varias opciones la primera que se nos puede ocurrir es crear un archivo con las sentencias SQL de los cambios y lanzarlo contra la base de datos. Sin embargo, esta opción aunque sencilla y rápida puede que no sea la mejor opción. La primera desventaja es que las sentencias puede que solo funcionen en uno o unos pocos sistemas de base de datos con lo que tal vez tengamos que desarrollar varios scripts para cada uno de los sistemas de base de datos a los que debamos dar soporte. La segunda desventaja es que si queremos revertir los cambios de un «refactor» deberemos crear las sentencias de «rollback» que puede dar bastante trabajo nuevamente si tenemos diferentes DBMS. Además de estas desventajas podríamos necesitar volver a cierto estado de la base de datos deberemos gestionarlo de alguna manera nosotros mismos probablemente de forma manual.

Una de las herramientas que nos puede hacer más sencillo estas modificaciones que se producen a la base de datos es Liquibase. Los scritps que actualizan la base de datos se definen en un XML (o json entre otros) de cambios que es independiente del sistema de base de datos que usemos aunque se pueden incluir sentencias SQL específicas para uno de ellos, también se pueden definir las sentencias rollback que permiten volver a un estado anterior. Soporta las principales bases de datos entre ellas:

MySQL
PostgreSQL
Oracle
MS-SQL
SQLite
Y otras entre ellas Sybase Enterprise, Sybase, DB2, Apache Derby, HSQL, H2, Informix, InterSystems, Firebird, SAPDB.

Una de las primeras cosas que podríamos necesitar si empezamos a usar esta herramienta sobre una base de datos existente es obtener el primer xml changelog.xml con el estado actual de la base de datos.

Si queremos lanzar una actualización de la base de datos a partir de un archivo changelog.xml con algunas modificaciones ejecutaremos lo siguiente:

Para obtener las SQLs que son lanzadas en la consola sin que sean ejecutadas contra la base de datos usaremos «updateSQL» en vez de «update» de esta manera podremos revisar las sentencias que ejecutará Liquibase. También puede sernos de utilidad obtener las diferencias entre dos versiones de la bases de datos o hacer rollback de los cambios, cosa que podemos hacer de diferentes formas.
Un archivo changelog.xml tiene el siguiente aspecto, en él vemos como se definen las tablas, campos y restricciones de integridad:

Por supuesto, estas tareas se pueden automatizar con la herramienta de construcción que prefiramos ya sea Ant, Maven, Gradle o mediante linea de comandos.

Referencia:
Liquibase

Ejemplo de pruebas unitarias en javascript con Jasmine y Sinon

2013-05-03T21:27:00.003+02:00

Tener un conjunto de pruebas unitarias sobre el código de la aplicación que desarrollamos es importante para tener más seguridad de que lo que hacemos funciona como se espera y no introducimos errores en funcionalidades que ya existían al hacer modificaciones, además de que en el caso de que haya errores estos serán más fácilmente descubiertos y resueltos en menos tiempo lo que hará que seamos más productivos. Si en una aplicación web es posible que ya hagamos pruebas unitarias sobre el código del lado del servidor, ¿por que no hacerlo también en el lado del cliente? Si la aplicación tiene un peso importante de javascript en el lado del cliente, y esa es la tendencia, es recomendable tener también teses unitarios de esta parte del código.

Aprovechando el ejemplo que hice de una aplicación bastante completa de una lista de tareas que utilizaba Backbone, RequireJS, Mustache en el lado cliente y Tapestry y RESTEasy en el lado del servidor ahora le añadiré al código javascript el conjunto de pruebas unitarias con Jasmine y Sinon.

Jasmine es una herramienta para realizar pruebas basadas en BDD (behavior-driven development). BDD es parte de las metododologías TDD (test-driven development) haciendo énfasis en que la gente del dominio pueda trabajar con la gente técnica. Jasmine nos servirá para hacer las pruebas unitarias, Sinon nos permitirá usar spies, stubs y mocks en esas pruebas:

Spy: Un spy es una función que se envía como parámetro al sujeto bajo prueba para que recolecte datos sobre lo que sucede dentro de esa función y objeto, se llama espía porque se envía tras la lineas enemigas para que recolecte información. La información que puede recolectar es el número de veces que se llama una función, con que parámetros y cuales, los valores de retorno o si lanzó excepciones.
Stub: ofrecen un comportamiento parcial preprogramado del objeto real, se puede utilizar para que proporcione los datos que queramos al sujeto bajo prueba. Los stubs también pueden ejercer de espías.
Mock: que también son espías (funciones falsas) y stubs (ofrecen comportmiento preprogramado) conocen las expectativas de como han de ser usados, requiriendo que se llamen con ciertos parámetros, un número de veces, en cierto orden, .... Conocen cual es el comportamiento esperado del sujeto bajo prueba y una vez hecha la prueba se puede comprobar.

A continuación veremos el código de las pruebas para la aplicación, las pruebas se centrarán en el código en el código de la lista de tareas y de probar las diferentes partes por separado, el modelo, vista y controlador. Veamos primeramente las pruebas para los modelos Tarea y Tareas, las pruebas se centrarán en las funciones adicionales que hemos asociado a los modelos, es decir, probaran lo que hemos hecho no Backbone.

En la parte del controlador de la vista nos centraremos en probar los métodos y eventos como onChangeCompletada en TareaView y addTarea, resetTareas, onClickLimpiar y onKeypressNuevaTarea en TareasView. Dado que la lista de tareas hace uso de un servicio REST utilizaremos Sinon para atrapar esas peticiones AJAX que se harían en la realidad.

En la vista probaremos que dado un modelo el resultado del html contiene los elementos que esperamos:

Las pruebas se lanzan abriendo la página html SpecRunner.html en el navegador. Esa página html tiene la dependencia sobre RequireJS y este carga en el navegador el resto de dependencias que necesiten los diferentes módulos incluido el módulo bajo prueba de la lista de tareas. Las pruebas de Jasmine se definen en otro módulo de RequireJS que tiene como dependencia la librería de Jasmine, Sinon y por supuesto el módulo tareas que probará. El resultado es el siguiente:

Backbone se presta muy bien a las pruebas unitarias. Una gran característica es que para realizarlas no es necesario que las vistas se asocien a un DOM real, funcionan en memoria, de modo que no hace falta insertar ni quitar contenido de la página mientras se van ejecutando los teses, no hay necesidad de limpiar el DOM para los siguiente teses y así funciona más rápido. Como usa el patrón MVC cada una de las partes del modelo, vista y controlador pueden probarse por separado. Este ejemplo no muestra todas la posibilidades de Jasmine y Sinon pero da una idea de como son las pruebas con ellas.

En mi repositorio de GitHub puedes encontrar el código fuente completo del ejemplo de pruebas unitarias en javascript con Jasmine y Sinon.

Y con esta es por el momento la última entrada sobre javascript que escriba de esta serie, no descarto escribir alguna más sobre javascript en el futuro porque alrededor de este lenguaje de programación están surgiendo muchas utilidades y librerías.

Referencia:
Introducción y ejemplo de RequireJS
Introducción y ejemplo de Mustache
Logging en Javascript con log4javascript
Capturar errores de Javascript
Optimizar módulos de RequireJS y archivos Javascript
Patrón de diseño MVC del lado cliente con Backbone.js
Introducción y ejemplo de Backbone.js

Ejemplo lista de tareas con Backbone, RESTEasy y Tapestry

http://tinnedfruit.com/2011/03/03/testing-backbone-apps-with-jasmine-sinon.html
http://blog.involver.com/2012/01/26/testing-backbone-js-best-practices-2/
http://kilon.org/blog/2012/08/testing-backbone-requirejs-applications-with-jasmine/
Backbone.js
RequireJS
Mustache
Jasmine
Sinon
RESTEasy
Apache Tapestry

Ejemplo lista de tareas con Backbone, RESTEasy y Tapestry

2013-04-26T21:38:00.000+02:00

Normalmente escribo artículos con ejemplos que tratan sobre una única tecnología, al tratar cada tecnología por separado entender que puede ofrecer es más sencillo pero en una aplicación real normalmente se usan varias tecnologías combinadas y al mismo tiempo. Esta entrada aunque sigue siendo un ejemplo es mucho más parecido a lo que podría ser una aplicación real que lo que he explicado durante las últimas entradas. En esta serie sobre javascript he explicado un montón de cosas por separado entre ellas RequireJS, Mustache, Backbone, servicios rest con Tapestry y RESTEasy. En esta entrada haré un ejemplo haciendo uso de todas las anteriores y alguna cosa más adicional como twitter bootstrap.

El ejemplo consiste en una lista de tareas, pudiéndose introducir nuevas tareas y marcarlas como realizadas. También se podrá eliminar de la lista las tareas completadas y ver un resumen con el número de tareas completadas y de tareas totales.

En la parte cliente de la aplicación se hace uso de RequireJS para manejar la carga de los archivos javascript necesarios, de backbone para gestionar la lista de tareas y realizar la comunicación con el servicio REST del servidor y de Mustache como motor de plantillas para generar la vista (el html). En la parte del servidor usa Tapestry como framework web y RESTEasy como librería para implementar un servicio REST que proporcionará la persistencia en memoria de la lista de tareas.

Backbone permite organizar el código aplicando el patrón de diseño MVC (modelo-vista-controlador) ampliamente extendido en los frameworks web. Este patrón de diseño tiene la ventaja que separa la aplicación en tres partes diferenciadas:

El modelo: que contiene los datos del dominio que maneja la aplicación que cuando es modificado lanza eventos para que el controlador y la vista actúen en consecuencia.
El controlador: que reacciona ante los eventos que se produzcan en el modelo o por el usuario y modifica adecuadamente el modelo o la vista según el evento.
La vista: que a partir del modelo produce la interfaz que se ofrece al usuario para que pueda manipularlos, los eventos producidos en la vista son manejados por el controlador.

Como se ve las tres partes se relacionan entre si pero están separadas de forma que cada una se encargue de una tarea. El código queda bien organizado y se evita el código espagueti que podríamos obtener de otra forma.

En una aplicación con la combinación de Backbone, Mustache y un servicio REST el servidor devuelve el html de la página inicial, las plantillas y los datos del servidor y se delega en el navegador del usuario la tarea de renderizar el html final. Esto tiene la ventaja de que entre el navegador y el servidor viajan menos datos (los datos y las plantillas tendrán menos tamaño que los datos formateados a html) y la parte del servidor se simplifica (no es necesaria la lógica para formatear a html los datos que dependiendo del framework hacen los jsp, tml de tapestry o gsp de grails). Aunque el código de la parte cliente crecerá, el código de la parte del servidor se hará más simple. Una vez cargada la página inicial entre el servidor y el cliente solo viajan los datos en formato json.

Veamos el ejemplo a continuación empezando por el modelo. El modelo con Backbone se define con Backbone.Model.extend, donde podremos indicar las propiedades de los objetos, también podemos definir funciones de utilidad. En este caso el modelo estará formado por los objetos Tarea que tendrán las siguientes propiedades:

Un id que identificará la tarea.
La descripción de la misma.
Y un indicador de si está completada.

Pero en la lista de tareas no solo tendremos un objeto Tarea, tendremos una colección de ellas. Esta colección también forma parte del modelo y se define con Backbone.Collection.extend, los elementos de esta colección serán objetos del modelo Tarea y lo indicamos en la propiedad model, también podemos definir funciones de utilidad como una función para obtener un array con las tareas completadas y otra para eliminar las tareas completadas que nos interesarán para ofrecer la funcionalidad de la lista de tareas. Las propiedades urlRoot y url son importantes para que backbone sepa localizar el servicio REST que proporcionará la persistencia.

La interfaz del servicio web REST es:

En Backbone la vista y el controlador de define en una misma entidad con Backbone.View extend. Aunque se definen ambas cosas a la vez la vista principalmente está formada por el método render, el resto será parte del controlador. Otra sección importante de la vista es la propiedad events donde indicaremos que eventos manejará el controlador y sobre que elementos de la vista, básicamente se define como clave el evento (click, change, ...) y un selector similar a los usados en jquery y como valor el nombre de la función que manejará el evento. En la vista también podremos definir métodos de utilidad. Tendremos dos vistas: una para para una tarea y otra para la aplicación de la lista de tareas.

En el método render se hace uso de Mustache para generar la vista a partir de una plantilla que contiene el código html, la plantilla combinado con los datos del modelo genera un resultado que será incluido en el html de la página. En las funciones initialize se inicializa la vista principalmente para definir que eventos que produzca el modelo serán tratados por el controlador, estos son las funciones on sobre el modelo, por ejemplo, nos interesará saber que se añade, modifica o elimina una tarea de la colección de tareas para actualizar la vista adecuadamente.

En el caso de TareasApp en el método initialize además se inserta en el elemento «el» que se le pasa en el constructor la vista inicial de la aplicación. De esta forma podríamos crear varias instancias de TareasApp.

Las plantillas de Mustache las he definido entre elementos <![CDATA[ ... ]]> ya que las plantillas de Tapestry han de ser xhtml válido, algunas expansiones de Mustache como {{attrs.checked}} de la plantilla tarea-template Tapestry no las entiende como válidas ya que realmente la plantilla Mustache en este caso no es html válido.

Una vez desarrollada la parte del servicio REST en el servidor con RESTEasy integrarlo con Backbone es muy sencillo, únicamente deberemos llamar en los puntos adecuados a las funciones save y destroy de los modelos. Al método save se le llama cuando se añade una nueva tarea en TareasApp.addTarea y cuando se modifica en TareaView.onChangeCompletada. Cuando se hace clic en el botón para limpiar las tareas completadas se llama a la función destroy de cada uno de los modelos. Estos métodos lanzarán las peticiones AJAX al servicio REST de forma automática variando su método y con su correspondiente url según hemos definido con las anotaciones del servicio REST: POST (crear), PUT (actualizar) y DELETE (eliminar).

Petición al crear una nueva tarea

Petición al marcar como completada una tarea

Petición al limpiar tareas completadas

La carga de inicial de la lista de tareas puede hacerse de dos formas: devolviendo los datos de las tareas cuando se pide la página o una vez cargada la página mediante una petición AJAX adicional. En Backbone recomiendan la primera ya que así se evitan peticiones al servidor innecesarias. Además aunque hagamos que las peticiones AJAX sean rápidas probablemente sean lo suficientemente lentas para que el usuario vea como se va rellenando el contenido de la página y dependiendo del html verá como los elementos van cambiando de posición lo cual puede ser molesto. Aunque hay que decir que incluir los datos en la propia página impediría cachear la página. Al final de la página Index.tml, está la sección para cargar la lista inicial de tareas que se pasará a TareasApp después de su constructor en el método resetTareas.

Esta es una captura del ejemplo:

Después de haber usado Backbone en este ejemplo simplemente tengo que decir que es una gran herramienta y que facilita y ayuda a organizar el código javascript en gran medida. Permite separar los datos de la aplicación que forman el modelo del controlador y la vista que reaccionan mediante los eventos producidos en el modelo. También permite desarrollar aplicaciones con un gran peso de javascript en la parte cliente sin que el código se convierta posteriormente en un infierno de mantenimiento aún con la ayuda de jQuery. Es una ayuda tan grande para hacer algunas cosas de la interfaz del cliente como lo es jQuery para manipular los elementos html.

Algunas partes no las he explicado como las plantillas de Mustache, el uso de RequireJS o la parte del servidor del servicio RESTEasy ya que ya lo que he hecho en entradas anteriores que puedes visitarlas mediante sus enlaces.

Como en el resto de entradas el código fuente completo lo puedes encontrar en mi repositorio de GitHub. Si quieres probarlo en tu equipo lo puedes hacer de forma muy sencilla con los siguientes comandos y sin instalar nada. Si no dispones de git para clonar mi repositorio de GitHub puedes obtener el código fuente del repositorio en un archivo zip con el anterior enlace.

Referencia:
Introducción y ejemplo de RequireJS
Introducción y ejemplo de Mustache
Logging en Javascript con log4javascript
Capturar errores de Javascript
Optimizar módulos de RequireJS y archivos Javascript
Patrón de diseño MVC del lado cliente con Backbone.js

Introducción y ejemplo de Backbone.js
Ejemplo de pruebas unitarias en javascript con Jasmine y Sinon

Introducción y ejemplo de Backbone.js

2013-04-19T20:22:00.001+02:00

Las aplicaciones y páginas web están haciendo uso de código javascript cada vez en mayor cantidad para proporcionar aplicaciones con funcionalidades más complejas. En estos momentos las librerías para utilizarse en javascript son muchas y una aplicación puede hacer uso de varias de ellas.

A pesar de las facilidades que proporcionan librerías como jQuery para manipular los elementos de una página web de forma dinámica, mucho código mal estructurado puede llegar a convertirse en un perfecto código espagueti, aunque jQuery facilita y simplifica muchas tareas en el manejo de los elementos de una página no es suficiente, a pesar de jQuery se puede llegar a tener un código con un mar de selectores, mantener sincronizados con la interfaz con el estado de la aplicación y la base de datos puede convertirse en una tarea complicada dar como resultado código con el que apetece poco trabajar.

Backbone.js trata de de resolver algunos de estos problemas proporcionando un marco sobre que el que organizar el código. Backbone.js en esencia en una librería modelo-vista-controlador (MVC) para javascript. Basándose en este patrón de diseño cada parte es independiente del resto. El modelo conserva el estado de la aplicación y produce eventos al ser modificado de forma que la vista se pueda actualizar de una forma independiente para ambos, la vista proporciona la interfaz del controlador a través del que se modifica el modelo de forma adecuada, todos los elementos están relacionados pero cada uno se encarga de una parte.

Backbone además proporciona una forma para trabajar con servicios REST tanto para recuperar los datos de los modelos como para actualizarlos, guardarlos y eliminarlos en el servidor. A continuación pondré un pequeño ejemplo usando backbone.js que calcula el área de un rectángulo dado su alto y ancho y que lo muestra en pantalla. Como backbone.js sigue el patrón de diseño MVC por un lado tendremos el modelo, en nuestro caso el rectángulo con las propiedades alto y ancho que nos servirán para calcular el área, por el otro la vista que se actualizará según los datos del modelo introducidos en dos campos de texto, finalmente el controlador que captura los eventos como los cambios en los campos de texto, modifica el modelo y el modelo notifica a la vista para que se actualice.

Vemos un ejemplo simple y que muestra parte del potencial de backbone.js. El modelo se define con el siguiente código, además de las propiedades se puede definir funciones que nos puede ser de utilidad, como calcular el área o obtener un objeto para ser utilizado con Mustache:

La otra parte es la vista y el controlador, ambas cosas se definen con Backbone.View.extend:

La inicialización del ejemplo:

Las partes de esta vista-controlador son:

el: el elemento html sobre el que actuará la vista.
events: los eventos que manejará el controlador, es un mapa donde la clave es un selector muy parecido a jquery y el nombre de la función a llamar cuando se produzca.
initialize: con la función de underscore _.bindAll haremos que la referencia a this sea la vista en las funciones indicadas (render, onChangeAlto, onChangeAncho). A continuación se crea el modelo y cuando se produzca algún cambio en él (evento change) se actualice la vista. Finalmente, cuando se inicia la aplicación se dibuja por primera vez la vista.
onChangeAlto y onChangeAncho: obtienen el alto o ancho de los campos de texto y modifican el modelo.
render: se encarga de actualizar la vista cuando haya algún cambio en el modelo tal y como hemos echo en la función initialize con la función on sobre el modelo. Actualiza los inputs de alto y ancho con los valores del modelo y mediante una plantilla de Mustache forma el mensaje que se visualiza en el elemento con id resultado.

Finalmente, queda el pequeño código html de la aplicación que contiene los campos de texto para introducir el alto y ancho y el elemento div donde se mostrará el área calculado del rectángulo:

Backbone.js no es la única librería que implementa el patrón MVC en javascript otras alternativas son knockout y AngularJS aunque esta últimas tienen la notable diferencia de que se basan en añadir atributos especiales a las etiquetas html para definir el modelo y asociar los eventos. Backbone.js no necesita añadir esos atributos especiales a la etiquetas html o «instrumentalizarlo», esto se hace a través de javascript lo que da una mayor separación entre el código html y el código javascript. Por ahí se dice que usando backbone.js para realizar lo mismo se necesitan más lineas de javascript pero hay que tener en cuenta que a cambio el html necesario es mucho más simple que en knockout o AngularJS lo que facilita que el trabajo con motores de plantillas como Mustache o Handlebars también sea más simple.

Como en el resto de entradas sobre esta serie de javascript el código fuente del ejemplo completo lo puedes encontrar en mi repositorio de GitHub. Este ejemplo se basa en RequireJS y Mustache visto en anteriores entradas que puedes consultar en el apartado de referencia al final de la entrada.

En la siguiente entrada mostraré un ejemplo completo y usando muchas cosas al mismo tiempo de las que he estado hablando individualmente en las últimas entradas, será un ejemplo de una aplicación de lista de tareas por hacer que permite crearlas y completarlas, usará RequireJS, Mustache y Backbone (usándolo de forma más avanzada y completa de lo visto en esta entrada) en la parte cliente y Tapestry y RESTEasy en la parte servidor.

Referencia:
Introducción y ejemplo de RequireJS
Introducción y ejemplo de Mustache
Logging en Javascript con log4javascript
Capturar errores de Javascript

Optimizar módulos de RequireJS y archivos Javascript
Patrón de diseño MVC del lado cliente con Backbone.js
Ejemplo lista de tareas con Backbone, RESTEasy y Tapestry
Ejemplo de pruebas unitarias en javascript con Jasmine y Sinon

Optimizar módulos de RequireJS y archivos Javascript

2013-04-12T17:35:00.000+02:00

Una vez que tenemos desarrollada una aplicación que hace uso de RequireJS como herramienta para gestionar las dependencias y archivos de javascript podemos realizar una optimización para conseguir que haya menos archivos y tengan menor tamaño. Esta optimización hará que la aplicación web realice menos peticiones al servidor y necesite transferir menos bytes dando como resultado una aplicación más rápida.

Para conseguir esta optimización necesitamos tener instalado la herramienta node.js y descargar el javascript que realizará la optimización, r.js. En Arch Linux instalar node.js consiste en instalar su paquete con:

Teniendo instalado node.js y habiendo descargado r.js el proceso consiste en ejecutar un comando desde la terminal. Este es:

El contenido del archivo build.js contendrá alguna información como el archivo de salida y la localización del módulo principal de la aplicación, básicamente la configuración es:

Este sería el resultado de optimizar el ejemplo de introducción sobre RequireJS. En el resultado se han eliminado los espacios y tabuladores, los diferentes archivos se han fusionado en uno solo (en este caso únicamente figuras.js y main.js) y los nombres de las variables se han acortado, esto reduce el tamaño del Javascript final. Esta optimización sirve también en cierta forma como ofuscación del código si queremos dificultar a alguien (como a la competencia de un producto) se aproveche del código que hemos desarrollado:

Al optimizar los archivos es recomendable ver las notas que indican en la documentación de RequireJS.

Si se quiere optimizar archivos individuales de javascript o no usamos RequireJS se puede utilizar la herramienta Closure Compiler, es muy sencilla, no hace falta instalar nada en nuestro equipo sino simplemente usar el servicio y da un resumen de la optimización que realiza.

Referencia:

Introducción y ejemplo de RequireJS
Introducción y ejemplo de Mustache
Logging en Javascript con log4javascript
Capturar errores de Javascript

Introducción y ejemplo de Backbone.js
Ejemplo lista de tareas con Backbone, RESTEasy y Tapestry
Ejemplo de pruebas unitarias en javascript con Jasmine y Sinon

Capturar errores de Javascript

2013-04-05T17:44:00.001+02:00

Tener un sistema de logging para el código Javascript de una página está muy bien para depurar el código cuando las cosas van mal en el sentido de que no hacen o no se comportan como se espera. Pero a veces las cosas pueden ir peor que mal, esto es, si hay algún error de «compilación» en en código de javascript el navegador detiene la ejecución y por tanto dejan de emitirse las trazas. Si el error nos sucede en el entorno de desarrollo o pruebas en nuestro propio navegador nos daremos cuenta del error pero en un entorno de producción no ya que el código se ejecuta en el navegador del usuario.

Sin embargo, no todo está perdido, los navegadores proporcionan como último recurso la función «window.onerror» que será llamada cuando se detecte un error de compilación o ejecución que impida continuar ejecutando el código javascript. Lo que podremos hacer para tratar el error será limitado pero al menos con log4javascript podremos enviar al servidor ese mensaje para que podamos primeramente conocer que se está produciendo y luego resolverlo, de otra manera nos sería desconocido ya que el código javascript se ejecuta en un entorno al que no tenemos acceso, en el navegador del usuario.

En el siguiente ejemplo mostraré como enviar al servidor esos errores de javascript que se produzcan. Para conseguirlo usaremos una combinación de la librería log4javascript comantada en la entrada anterior y la función window.onerror. A continuación el contenido de una página con el contenido completo usando RequireJS:

En la siguiente imagen se puede ver la petición que hace log4javascript para enviar el error al servidor.

Aparte de la propia traza del error que envía log4javascript (aunque en la imagen anterior no es muy descriptiva) podemos obtener otra información relacionada con la petición http que se realiza como el navegador en el que se ha producido, sistema operativo y versiones de ambos aparte de cookies si las hubiese o la dirección IP. En esa URL deberemos tener algo que atienda la petición y saque a los logs del servidor el mensaje enviado. En caso de usar Java probablemente hagamos uso de un servlet, u otra cosa en función del framework web que usemos, y utilizaremos slf4j, log4j o logback para sacarlo al registro de trazas del servidor. El código completo de este ejemplo está alojado en mi repositorio de GitHub.

Referencia:

Introducción y ejemplo de RequireJS
Introducción y ejemplo de Mustache
Logging en Javascript con log4javascript
Optimizar módulos de RequireJS y archivos Javascript

Introducción y ejemplo de Backbone.js
Ejemplo lista de tareas con Backbone, RESTEasy y Tapestry
Ejemplo de pruebas unitarias en javascript con Jasmine y Sinon

Logging en Javascript con log4javascript

2013-03-28T12:38:00.003+01:00

En esta serie de artículos que estoy escribiendo sobre varias librerías y herramientas relacionadas con el lenguaje de programación Javascript como RequireJS, Mustache y Backbone en esta ocasión voy a hablar de una librería de logging para javascript que también puede hacernos la vida más sencilla como programadores.

Sistemas de trazas hay muchos para Java y otros muchos lenguajes pero en el entorno de las aplicaciones web estos suelen usarse en la parte del servidor de las aplicaciones. Sin embargo, en el cliente también puede producirse errores y nos puede interesar tener información para averiguar la causa de forma que podamos solucionarlos más rápidamente o simplemente para tener un registro de lo que se ha ido haciendo en este caso en el cliente. Una librería de logging en el cliente también nos puede servir para tener información de errores en el navegador que de otra forma nos pasarían desapercibidos si solo tenemos trazas en el servidor, con la librería de trazas que explicaré en esta entrada podemos enviar las trazas de error al servidor de forma muy sencilla. Además, nos puede servir de utilidad en el momento de desarrollo del código javascript.

Por los motivos anteriores aunque no lo consideremos imprescindible nos puede resultar muy interesante la librería log4javascript. Los conceptos que emplea son muy parecidos a log4j con lo que si programamos en java aprenderemos fácil y rápidamente a usarla, en cualquier otro caso no nos llevará mucho tiempo aprender.

Lo primero que deberemos hacer es descargarla y una vez descomprimido el paquete incluirla en el código html de nuestra página con, haciendo uso de RequireJS:

Posteriormente deberemos usarla definiendo los appenders que determinarán a donde se envían las trazas, a los appenders les asociaremos un layout que determinará el formato de la traza y el nivel mínimo que ha de tener la traza («threshold») para ser emitido. log4javascript proporciona varios appenders según nuestras preferencias o necesidades:

AlertAppender: muestra las trazas usando la función alert del navegador.
AjaxAppender: realiza una petición ajax al servidor enviando la traza generada en el navegador, con este appender podremos tener el registro de lo que sucede en los clientes. Se ha de indicar el path de la URL que procesará las trazas en el servidor.
PopUpAppender: muestra las trazas en una ventana emergente en la que se pueden filtrar las trazas y en la que cada nivel aparece con un color distinto para reconocerlas más fácilmente.
InPageAppender: muestra la misma consola del PopUpAppender pero de forma incrustada en el pie de la página.
BrowserConsoleAppender: muestra los mensajes en la consola de depuración con los mensajes de javascript que incorporan los navegadores.

Con el siguiente bloque de código inicializamos el sistema de trazas, la variable log4j será la que utilicemos para emitir las trazas. En el ejemplo utilizamos el appender PopUpAppender con un layout que nos mostrará la hora, el nivel de la traza y el mensaje, el threshold del PopUpAppender es INFO con lo que todo mensaje con nivel menor prioridad como TRACE o DEBUG no aparecerán en el appender, para el caso de AjaxAppender el threshold será ERROR de modo que tampoco aparecerán en el las trazas INFO y WARN. Al emitir las trazas indicamos el mensaje más adecuado que consideremos más nos pueda ayudar y con el nivel de trazas según la importancia que tenga el mensaje, este nivel de trazas nos permitirá filtrarlos según su nivel en el popup:

El resultado que obtenemos en la consola emergente es el siguiente, los mensajes de nivel de trace y debug no aparecen por el threshold del appender PopupAppender.

Como los ejemplos de RequireJS y Mustache el código fuente completo lo puedes encontrar en mi repositorio de GitHib.

Referencia:

Introducción y ejemplo de RequireJS
Introducción y ejemplo de Mustache
Capturar errores de Javascript

Optimizar módulos de RequireJS y archivos Javascript
Introducción y ejemplo de Backbone.js
Ejemplo lista de tareas con Backbone, RESTEasy y Tapestry
Ejemplo de pruebas unitarias en javascript con Jasmine y Sinon

Introducción y ejemplo de Mustache

2013-03-22T18:04:00.002+01:00

Como comentaba en la Introducción y ejemplo sobre RequireJS el lado cliente están tomando cada vez más responsabilidad y peso en las aplicaciones. El lado cliente con los navegadores ya no se limitan a mostrar el html que se genera en el servidor de forma dinámica sino que son ellos mismos que obteniendo los datos en formato JSON probablemente mediante un servicio REST se encarga de transformar esos datos en el html que finalmente se ha de mostrar en la página. Generar el html en el cliente en vez de en el servidor tiene las siguientes ventajas:

Se reduce la carga del servidor.
La cantidad de datos devueltos es menor ya que el tamaño de la plantilla y los datos podrán ser menor que el html final generado por la combinación de ambos si una plantilla puede aplicarse varias veces sobre alguna lista de los datos.

Para transformar esos datos al html mediante una plantilla hay diferentes librerías que proporcionan esa funcionalidad entre ellas Mustache y Handlebars. Mustache es más simple que Hadlebars y Handlebars es un superconjunto de Mustache por lo que si tenemos una plantilla en Mustache podremos utilizarla en Handlebars. En esta entrada comentaré un ejemplo simple y sencillo con las posibilidades de Mustache.

Mustache se caracteriza por su simplicidad evitando incluir lógica en las plantillas, es decir, sin sentencias if y bucles aunque algunas etiquetas proporcionan la misma funcionalidad. El hecho de no incluir lógica en las plantillas hace que estas sean sencillas, fáciles de desarrollar y de mantener además de obligar a no mezclar conceptos lo que hace que el código sea «limpio».

La esencia de Mustache al igual que otros sistemas de plantillas es que por un lado tenemos los datos que forman parte del modelo y por otro lado la plantilla que forma parte de la vista, juntando ambos obtenemos un resultado.

Veamos como se traduce todo esto en código javascript. Lo primero y más sencillo son las variables que en la plantilla se indican entre {{ }}, estos corchetes con forma de mostacho le dan nombre a la librería, la variable es sustituida por el valor proporcionado en el modelo:

Secciones

Otra posibilidad de Mustache con las secciones que se indican con un # delante de la variable. Si la variable de una sección es false, tiene valor null o es un array vacio, esa sección se omite en el resultado. De esta forma una sección puede hacer de lo que en un lenguaje de programación sería una condición.

Secciones lista

En el caso de hacer una sección en el que la variable sea una array o lista, la sección recorrerá cada uno de los elementos de la lista y generará un contenido por cada elemento. Esto nos proporciona la funcionalidad de un bucle.

Parciales

Si no queremos tener una plantilla muy grande o queremos rehusar cierta parte en varias plantillas la podemos dividir usando parciales. Los parciales se indican con el caracter > y son una forma de llamar a un trozo de una plantilla. En la plantilla los parciales son sustituidos por su correspondiente código del mapa de parciales y la plantilla se procesa como si fuese una completa. Este es el mismo ejemplo de la sección lista pero usando parciales:

Compilación

Para una mayor eficiencia sobre todo en dispositivos móviles las plantillas pueden compilarse con:

Esto es lo básico de Mustache, tiene alguna posibilidad más como las funciones donde se puede añadir algo de lógica, también están las secciones invertidas que se indican con ^ y generan resultado si la variable de la sección es null, false o vacía, es decir, lo contrario de una sección normal. Por defecto los caracteres html de una variable son escapados pero puede evitarse con tres llaves {{{ }}} o un & antes del nombre de la variable. También puede cambiarse el delimitador de Muchache, los {{ }}, por otra cadena pero será poco habitual que lo necesitemos.

La otra alternativa que comentaba es Handlebars con la que si tenemos una plantilla de Mustache podemos utilizarla en Handlebars sin ningún cambio ya que Handlebars soporta todas las características de Mustache y añade algunas otras. Las principales diferencias entre Mustache y Handlebars es que Mustache puede ser usada desde diferentes lenguajes como Java, Python, Ruby, D, .NET, PHP, y alguno más que puede verse en la página del proyecto, Handlebars solo se puede utilizar usando javascript. Dado que Mustache puede ser utilizado con Java puede ser una alternativa a librerías como FreeMarker de esta manera podemos hacer uso de la misma librería de plantillas tanto en el servidor como en el cliente de forma que evitemos tener que aprender y conocer varias tecnologías que hacen lo mismo y aprovechemos mejor lo que conocemos. Otra diferencia es que Handlebars añade el concepto de funciones de ayuda («helpers») mediante los cuales se puede añadir lógica si nos es necesario y aunque puede facilitarnos ciertas tareas no conviene abusar de ello ya que puede hacer que las plantillas dejen de ser tan simples y empiecen a no ser fáciles de mantener.

El código fuente completo de este ejemplo los puedes encontrar en mi repositorio de GitHub.

Referencia:

Introducción y ejemplo de RequireJS
Logging en Javascript con log4javascript
Capturar errores de Javascript

Introducción y ejemplo de RequireJS

2013-03-15T22:18:00.003+01:00

Las páginas web ha evolucionado mucho desde sus inicios en los que eran simples páginas estáticas hechas con el lenguaje de marcas html, podían contener enlaces e imágenes. Posteriormente adquirieron capacidad de cambiar a través un lenguaje de programación que en el servidor genera el código html de forma dinámica basándose en la información que el usuario podía enviar en un formulario, también se incorpora cierta programación en el cliente con javascript. Con las nuevas versiones del estándar html, los avances de los navegadores y una explosión de dispositivos móviles de gran capacidad las aplicaciones están evolucionando hacia el cliente, haciéndose cada vez más complejas en el lado del navegador del usuario y adquiriendo resposabilidades que antes tenía la aplicación en el lado del servidor. Cada vez hay más librerías y frameworks javascript que tratan de resolver problemas específicos de las aplicaciones de internet. Entre estas librerías algunas de las más conocidas son, muy resumidamente:

jQuery: para manejar los elementos de la página.
mustache: a partir de una plantilla y unos datos genera un resultado.
underscore: proporciona ciertas utilidades bastante comunes que el lenguaje javascript no proporciona.
Backbone: da un modelo MVC para el desarollo de las aplicaciones.

Por supuesto, para cada área hay varias opciones entre las que se puede elegir, estas no son las únicas librerías hay muchas más alternativas (hadlebars, prototype, agularjs, mootools, ...) que en esencia proporcionan la misma funcionalidad que las anteriores. A medida que vamos haciendo uso de más librerías, archivos javascript y que estas pueden tener dependencias unas sobre otras se hace necesario algo que permita gestionar esas relaciones entre las librerías para que el código javascript se cargue en el orden adecuado y funcione correctamente. Aquí surge RequireJS, que además de gestionar esas dependencias también nos proporciona otras ventajas:

La carga de los archivos javascript se hace de forma asíncrona evitando el resto del contenido de la página se bloque hasta que los js de la página se carguen.
Permitirnos optimizar los archivos javascript juntándolos en uno solo de forma que sean necesarias menos peticiones al servidor y a la vez minificándolos para hacer que ocupen menos y la transferencia sea más rápida.
Se evita contaminar el ámbito global de javascript evitando posibles conflictos entre archivos javascript.

Algunas de estas ventajas hacen que la página cargue más rápido que es algo que el buscador de Google tiene muy en cuenta para el posicionamiento en los resultados de búsqueda.

Con RequireJS los archivos javascript se organizan en módulos y estos pueden tener dependencias sobre otros, todos los archivos javascript necesarios son cargados por RequireJS de forma asíncrona. Haciendo uso de RequireJS en la página web solo será necesario incluir un único javascript, que será el de RequireJS, en la propia etiqueta script y con el atributo data-main le indicaremos el módulo del que va a hacer uso la página. El resto de módulos se cargarán como dependencias del módulo que especifiquemos en el atributo data-main.

En el módulo inicial que carga la página, main.js, hacemos uso de la función require cuyos parámetros son un array con la lista de dependencias sobre otros módulos y una función que será llamada cuando RequireJS haya cargado todos los módulos indicados en la lista, en este caso solo uno. Por cada dependencia la función que se llama cuando todos los módulos se han cargado recibe un objeto como parámetro, de esta manera RequireJS es como evita contaminar el ámbito global ya que no son necesarias definiciones en el ámbito global.

En el ejemplo del módulo main.js en la función require se indica una dependencia sobre el módulo figuras. El módulo de las figuras contiene la lógica de esta simple aplicación que es calcular el área de un cuadrado y un triángulo y mostrar el resultado en un diálogo emergente. Una vez que todas las dependencias del módulo de la aplicación, en este caso solo una, han sido cargadas por RequireJS se llama a la función callback del módulo de la aplicación con la referencia del módulo de figuras.

El módulo figuras no tiene ninguna dependencia con lo que el array de dependencias no es necesario y solo se indica la función de inicialización del módulo en la función define. Este módulo define los prototipos de dos objetos, un cuadrado y un triángulo, con un método cada una de ellas que permiten calcular su respectiva área. El retorno de la función de inicialización del módulo es importante ya que lo devuelto por esta función es lo que recibirán como referencia los módulos que dependan sobre el módulo de figuras.

El resultado es este:

Las funciones require y define son similares pero si un módulo va a ser usado por otros se ha de usar la función define, sino va a ser usado por otros se puede usar la función require.

En posteriores entradas hablaré y pondré un ejemplo de otros temas relacionados con javascript como mustache, backbone, REST, logging, optimización, ... que nos pueden ayudar mucho a hacer mejores aplicaciones, más complejas, de forma más sencilla, con menos errores y más rápidamente. Este artículo sobre RequireJS solo es el primero en el que se basarán el resto que escribiré sobre javascript.

El código fuente completo de este ejemplo de RequireJS lo puedes encontrar en mi repositorio de GitHub.

Referencia:

Introducción y ejemplo de Mustache
Logging en Javascript con log4javascript
Capturar errores de Javascript

Skinning de web usando Apache Tapestry

2013-03-09T12:30:00.000+01:00

Algunas páginas o aplicaciones web tienen la necesidad de variar su aspecto en función de determinadas variables. La aplicación puede ser la misma pero necesitar cambiar el aspecto o la imagen de marca en función de esas variables. Si los cambios a realizar solo implican cosas visuales como colores, tipos de fuentes y tamaños, imágenes, etc... con cambiar las hojas de estilo de la web puede ser suficiente, pero si es necesario modificar el html que genera la aplicación porque los elementos sean diferentes o estén en diferente posición dentro del html generado necesitaremos incluir lógica en forma de condiciones en las plantillas que forman parte de la vista del framework que usemos. Si únicamente tenemos una variable incluir lógica en las plantillas puede ser manejable pero si son varias tarde tarde o temprano su mantenimiento será un problema y podremos tener como resultado código spaghetti en el html. Otra alternativa a usar una única plantilla con lógica es tener una plantilla distinta por variable o conjunto de variables si las plantillas generan código html suficientemente diferente de forma que manejar las diferentes plantillas por separado sea más sencillo, a pesar de que probablemente estaremos duplicando código en las diferentes plantillas. Pero para tener diferentes plantillas tendremos que inventar un mecanismo que nos permita seleccionar la plantilla adecuada en función de las variables y las cosas pueden complicarse si se puede dar combinaciones de ellas.

¿Cuales podrían ser las variables por las que una aplicación quisiese cambiar el html generado? Algunas de ellas podrían ser:

El nombre del dominio. Si aplicación necesita de diferente imagen de marca en función del nombre de dominio por el que se accede al servidor donde está alojada la aplicación.
El tipo de usuario. Aquí podría entrar cualquier información que el usuario nos envía en las peticiones http, desde el lenguaje al país de la dirección IP pero una candidata podría ser el dispositivo utilizado para acceder a la aplicación, si se tratase de un dispositivo móvil podríamos eliminar las cosas suplerfuas para aligerar en peso la página y que se cargase más rápido o para que esté más adaptada a un ambiente táctil de un table o smartphone.
Otra podría ser la hora o fecha en la que se accede a la aplicación por ejemplo para adaptar la aplicación a épocas navideñas o ciertos periodos relevantes para la aplicación.

Si tenemos una aplicación con esta problemática deberemos buscar la mejor forma que el framework que usemos nos posibilite. A continuación voy a explicar como conseguirlo usando el framework Apache Tapestry. Usando este framework veremos que añadiendo una pocas cosas podemos resolver el problema de forma simple, sencilla y limpia evitando tener la misma lógica desperdiga por toda la aplicación. Una vez realizada la selección de la plantilla adecuada su uso nos será transparente y nos podremos olvidar de esta funcionalidad y centrarnos únicamente en crear las plantillas.

En Tapestry a las variables se les denomina «axis» o ejes, una de ellas disponible por defecto y especial es el «locale» o idioma del usuario, de esta forma en función del idioma podemos tener una plantilla distinta y completamente diferente del resto, si no existe la más específica se usará la mejor opción al igual que ocurre con los ResourceBundle de Java. Por ejemplo, si el idioma es es_ES puede ocurrir los siguientes casos:

Que la plantilla de una página o componente con eje del idioma es_ES exista, si la página es Index, su plantilla es Index_es_ES.tml si existe se selecciona esta.
Si la plantilla Index_es_ES.tml no existe se elige la siguiente mejor opción que es Index_es.tml.
Si Index_es.tml tampoco existe se selecciona Index.tml que será la más general y opción de último recurso.

En Tapestry el eje del idioma se aplica también a los recursos estáticos como puede ser las imágenes, css, javascripts, etc... en el caso de las imágenes nos puede ser muy útil si estas llevan texto. Los ejes personalizados fueron introducidos en la versión de Tapestry 5.3, aunque ya era posible conseguirlos en versiones anteriores se necesitaba más esfuerzo. Podemos tener tantos ejes como deseemos pero si son muchos las combinaciones y plantillas necesarias pueden crecer en gran medida aunque al igual con el eje del «locale» si la plantilla no existe se seleccionará la de por defecto, por suerte no será necesario que definamos todas las plantillas para todos los posibles casos de combinaciones de ejes solo deberemos crear las plantillas personalizadas que nos interesen. Las combinaciones de los ejes y las plantillas puede observarse en la siguientes figuras.

Quizá todo parezca más complicado de lo que realmente es, la implementación en código de los ejes se traduce básicamente en dos partes:

La lógica que determina los ejes a aplicar a una petición.
La lógica que en función de los ejes de la petición selecciona la plantilla adecuada.

Una de las grandes características de Tapestry es que las cosas pueden ser redefinidas, extendidas y adaptadas, todo lo que esté definido como un servicio en el contenedor de dependencias puede serlo y esto es mucha de la funcionalidad interna del framework ya que muchas cosas se definen como servicios, solo deberemos implementar la interfaz adecuada en una clase y hacer la contribución en el contenedor de dependencias para que se use.

Veamos la clase que contiene la lógica que determina el eje a aplicar en función del dominio suponiendo que la plantilla a usar sea diferente si se entra a la aplicación por el dominio .com.es o por .net, la interfaz a implementar es ComponentRequestSelectorAnalyzer:

La clase CustomComponentRequestSelectorAnalyzer para determinar si la aplicación cumple un eje necesitará información, en el caso del eje del dominio bastará con la clase HttpServletRequest que podrá ser inyectada por el contenedor IoC de Tapestry en la implementación de la clase, si necesitásemos más información será suficiente con indicar el servicio que la proporciona en el constructor. DominioAxis es un enumerado de utilidad para identificar el dominio. Si el nombre del dominio acaba en com.es o .net devuelve el enum correspondiente:

La segunda parte de los ejes es proporcionada por una clase que implementa la interfaz ComponentResourceLocator y seleccionará la plantilla adecuada en función de los ejes detectados en la petición por la clase CustomComponentRequestSelectorAnalyzer anterior. La parte importante está en el método locateTemplate:

Se obtienen los ejes por los que pueden seleccionar las plantillas, en este caso solo uno pero podrían ser múltiples y combinados de cualquier forma aunque en ese caso la lógica para selecciona la plantilla sería más complicada. Independientemente del número de ejes el resultado final ha de ser el nombre de la plantilla y si existe se usa sino se usa la plantilla que no tiene ningún eje (salvo el locale que se puede aplicar siempre incluso usando ejes personalizados). En el caso concreto del ejemplo la plantilla sigue el formato «[nombre plantilla]_[eje dominio].tml» que en el caso de la página Index podría ser Index_com_es.tml o Index_net.tml. Si la petición no tuviese ningún eje la decisión de seleccionar la plantilla se delegaría en el servicio por defecto de Tapestry.

Una vez codificadas estas clases para que se usen se han de hacer unas pocas contribuciones en el módulo de la aplicación, en concreto lo que necesitamos definir son dos métodos, contributeServiceOverride y decorateComponentResourceLocator. Si los nombres de estos métodos no son suficientemente explicativos diré que contributeServiceOverride hace que se use un servicio en vez de otro, como queremos que se use nuestro CustomComponentRequestSelectorAnalyzer en vez del de por defecto que usa Tapestry lo sobreescribimos, nuestro servicio lo definimos en el método bind. El método decorateComponentResourceLocator aplica el patrón de diseño Decorator sobre otro servicio, si la clase CustomComponentResourceLocator detecta un eje y encuentra la plantilla la selecciona sino siguiendo el patrón decorate delega en la clase que decora.

Y este sería el resultado de acceder por los diferentes dominios:

Estas son las plantillas que se usan en cada uno de los casos:

En el caso del dominio que acaba en .local se usan las plantillas de la página Index.tml y HolaMundo.tml del componente HolaMundo ya que CustomComponentRequestSelectorAnalyzer no establece el eje del dominio.
En el dominio .com.es si se establece el eje de dominio y se buscan las plantillas de este eje, en el caso de la plantilla de la página se Index.tml ya que no existe Index_com_es.html pero en el caso del componente se usa HolaMundo_com_es.tml ya que si existe.
En el dominio .net se usa Index_net.tml y HolaMundo_net.tml ya que en ambos casos existen.

El código fuente completo lo puedes encontrar en mi repositorio de GitHub. ¿Quieres saber más sobre Apache Tapestry? Visita Documentación sobre Apache Tapestry.

Referencia:
http://blog.tapestry5.de/index.php/2011/06/24/template-skinning/
Código fuente completo del ejemplo Skinning de plantillas con Apache Tapestry

Integración de Apache Tapestry con RESTEasy

2013-03-01T20:23:00.001+01:00

Ahora que hemos visto en artículos anteriores como son los servicios web REST, como realizar uno empleando la librería RESTeasy, como crear un cliente para consumirlo desde el lenguaje de programación java o mediante javascript desde un navegador web y como devolver datos en formato json, xml u otro se nos plantean algunas ideas de como definir la arquitectura de una aplicación.

Las aplicaciones web normalmente se organizan en tres capas, la del cliente, la que contiene la lógica de negocio y la capa de base de datos. La capa del cliente está formada por el navegador, la de negocio donde se emplea algún framework y variará según lenguaje de programación que empleemos e incluye a menudo la responsabilidad de presentación transformando los datos de la capa de base de datos en html para el cliente. La capa de base de datos contiene los datos que trata la aplicación ya sea en forma relacional o no relacionan (no-sql).

En algunas aplicaciones es requisito ofrecer una interfaz de la aplicación para que otras aplicaciones se integren con ella, aqui es donde surgen los servicios web y se nos platea la posibilidad de extraer de la capa donde esta la lógica de negocio a una entidad independiente o integrar los servicios web como una parte más de la aplicación web.

En los ejemplos que hemos visto hasta ahora estos los he puesto como una entidad independiente, es decir, que solo ofrece los servicios web. Esta forma tiene la ventaja de que las partes de la aplicación son independientes pero tiene la desventaja de que la complejidad de la aplicación aumenta ya que los servicios web necesitarán de funcionalidades como acceder a la base de datos, inyección de dependencias o de la recarga automática de clases para ver las modificaciones en caliente mientras estamos desarrollando. Todas estas funcionalidades es probable que tengamos ya en la capa de lógica de negocio, con lo que podríamos ponerlo todo junto y aprovecharnos de las funcionadades que ya tenemos en vez de proporcionalas de nuevo en otra entidad independiente. Sin embargo, para tenerlo todo junto deberemos integrar el framework que usermos con la librería o framework que usemos para la aplicación web. En el siguiente ejemplo veremos como hacerlo para el caso de RESTEasy como librería que proporciona la funcionalidad de servicios web y Apache Tapestry como framework para la aplicación web desarrollada en Java.

En Tapestry ya hay una librería desarollada que permite integrarse con RESTEasy, sin embargo, por lo que he visto en su código fuente no permite obtener el cliente javascript como explique en el segundo ejemplo de esta serie de entradas sobre RESTEasy. Con lo que partiendo de su código fuente lo he modificado para que si se permita obtenerlo.

La parte importante de esta integración está en las clases que definene el módulo de la aplicación (AppModule.java) y el filtro de RESTEasy (ResteasyRequestFilter.java) que será el que atrape las peticiones REST. El código está comentado con notas explicativas.

Con el código de AppModule.java y ResteasyRequestFilter.java conseguimos la integración de Tapestry con RESTEasy y con ella conseguimos varias características que proporciona el contenedor IoC (Inversion of Control), el mero hecho de definir los servicios REST como servicios de Tapestry obtenemos inyección de dependencias y recarga de clases en vivo («live class reloading») que evitará que durante el desarrollo tengamos que estar constantemente parando y arrancando el servidor de aplicaciones para ver los cambios que hagamos con nuestro editor a la clase del servicio, ambas cosas sin que tengamos que hacer nada más. En cuanto a la inyección de dependencias si nos fijamos en el código de servicio REST HelloWorldResourceImpl vemos que tiene un constructor con una referencia a un objeto de la interfaz ContadorService, sin esta referencia el objeto no puede ser construido. El contenedor de dependencias de Tapestry es capaz de inyectar las dependencias necesarias en el constructor para satisfacer sus necesidades sin que tengamos que darle ninguna indicación, él se encargará de buscar en el registro un servicio que implemente esa interfaz, de construirlo (y de construir las dependencias de este servicio si a su vez las tuviese) y de pasarlo como referencia al constructor, encontrará que la clase ContadorServiceImpl lo implementa ya que así lo hemos indicado en el método AppModule.bind. De esta misma forma en los servicios REST podemos hacer uso de cualquier otro servicio, como pudiera ser el servicio persistencia proporcionado por Hibernate o JPA.

La página que genera el html (Index.tml) para el navegador con varias llamadas al servicio REST (Index.tml) es prácticamente html normal excepto por un ejemplo de como se usa un componente en Tapestry (). La etiqueta script solicita el javascript con el cliente del servicio web.

Y las peticiones que veríamos en el navegador serían:

Puedes ver, descargar y probar el código fuente del ejemplo desde mi repositorio de GitHub.

Referencia:
http://es.wikipedia.org/wiki/Representational_State_Transfer
Código fuente ejemplo Integración de Apache Tapestry con RESTEasy
Documentación sobre Apache Tapestry

Devolver xml, json o html con RESTEasy

2013-02-22T18:36:00.000+01:00

En esta serie de artículos sobre los servicios web REST hemos visto hasta el momento como hacer un programa sencillo Hola Mundo con RESTEasy y como crear un cliente Java y Javascript de ese servicio web para consumirlo desde javascript en una aplicación web y desde un programa java usando la librería RESTEasy. En un servicio web REST podemos devolver datos en varios formatos, ya sea texto plano, html, json o xml, en esta entrada veremos como devolver datos en los dos últimos y que anotaciones usar para que las cabeceras devueltas en la petición sean las correctas, que ventajas nos puede aporta y que problemas nos puede resolver.

Antes unos pequeños apuntes de porque nos puede interesar devolver json o xml. Unos de los motivos es que a medida que las aplicaciones web están ganando en complejidad estas están tendiendo a delegar en el cliente la parte de visualización en vez de ser el servidor el que devuelva html formateado directamente. Además de evitar cierta carga de proceso en el servidor y delegarla en los clientes ofreciendo una interfaz REST de la apliccación permitimos que terceros desarrollen sus propias aplicaciones y se integren consumiendo los servicios que ofrecemos.

Una vez explicadas algunas ventajas, veamos el ejemplo de como devolver json o xml en el servicio REST, en el siguiente código el servicio HelloWorldResource devolverá los datos de un objeto a través de los métodos getMensajeJSON y getMensajeXML. Los métodos del servicio puede anotarse con @Produces indicando el formato de los datos que se devuelve, en la clase MediaType hay constantes para muchos formatos. Si el formato en el que devolvemos los datos no está definido en la clase MediaType podemos definir uno específico con @Produces("text/html"):

La anotación @Produces es muy importante en el servicio REST ya que los métodos getMensajeJSON y getMensajeXML tienen especificada la misma ruta de petición en la etiqueta @Path, ¿como sabe entonces el servicio REST en que formato se han devolver los datos si la URL solicitada es la misma para ambos casos? La respuesta es empleando la información enviada en las cabeceras del protocolo http, más concretamente empleando la cabecera Accept que en este protocolo indica en que formato quiere el cliente los datos. En muchas aplicaciones es habitual encontrarse en que se realizan peticiones al servidor especificando como Accept text/html y resulta que el servidor devuelve los datos en formato json, xml u otro, la aplicación funcionará bien pero lo hace empleando el protocolo http de forma incorrecta, esto no ocurre con los servicios REST que en función de lo que se solicita en la petición así es el formato de los datos devueltos. En la siguiente imagen pude verse la cabecera Accept de la petición enviada por el cliente javascript.

En el ejemplo se devuelve una clase POJO con varios atributos que usa las anotaciones @XmlRootElement, @XmlElement, @XmlAttribute para indicar los datos y la forma de los datos a generar como resultado:

Para el cliente java desde el punto de vista del que lo usa la comunicación con el servidor y el formato en el que se transmiten los mensajes es transparente.

En el cliente javascript si usamos el formato json nos será más cómodo tratarlo en el navegador: En las siguientes imágenes las peticiones que se realizan desde el navegador con el cliente javascript, en la columna type se puede ver el tipo de datos devuelto en las peticiones:

Para que el ejemplo funcione deberemos incluir las dependencias org.jboss.resteasy:resteasy-jaxb-provider:2.3.5.Final y org.jboss.resteasy:resteasy-jettison-provider:2.3.5.Final.

Para finalizar, comentar que la combinación de ofrecer en la aplicación una API REST junto con librerías como Backbone.js que proporcionan un Modelo-Vista-Controlador (MVC) en el navegador accediendo al servidor para consumir el servicio puede dar lugar a aplicaciones más flexibles y fáciles de desarrollar entre otras cosas. Y esa es la tendencia hacia la que están evolucionado las aplicaciones web a medida que el propio lenguaje javascript y los navegadores aumentan sus capacidades.

En el siguiente enlace puedes encontrar el código fuente completo de este ejemplo y probarlo tu mismo en un servidor de aplicaciones como Tomcat. La siguiente entrada será como integrar RESTEasy con un framework de desarrollo web como Apache Tapestry.

Referencia:
http://www.jboss.org/resteasy
http://backbonejs.org
Código fuente completo del ejemplo Hola Mundo con RESTEasy

Cliente javascript y java de servicio web REST con RESTEasy

2013-02-16T02:57:00.000+01:00

Una vez que hemos desarrollado un servicio web REST tendremos que obtener un cliente para consumirlo ya sea con javascript, Java u otro lenguaje. En cualquier caso los clientes son mucho más sencillos de obtener en RESTeasy que en los servicios web basados en mensajes SOAP y XML haciendo uso de otras librerías a partir de la definición contenida en el WSDL como vamos a ver. Además, de poder ser consumidos desde un navegador a través de javascript.

Para el cliente Java deberemos tener la interfaz de ese web service con los métodos ofrecidos en el servicio, con las anotaciones adecuadas y que deberemos implementar en una clase. La interfaz del ejemplo Ejemplo sencillo de web service con RESTEasy sería:

Y la implementación:

Una vez tengamos la interfaz del web service REST y su implementación podemos hacer un programa java que lo use como cliente:

Apartir de esa interfaz podemos obtener el cliente y un programa que lo invoca con el siguiente código. La parte importante está en el uso de las clases RegisterBuiltin y ProxyFactory:

Y eso es lo mínimo necesario para consumir los web services desde java ¿te pareció sencillo?, pues para consumirlos desde un navegador con javascript es aún más sencillo, veamos como. RESTEasy proporciona un servlet que genera un archivo js con los clientes javascript de nuestros servicios web REST, lo único que deberemos hacer es incluir ese servlet en el web.xml de nuestra aplicación web y usarlo en la página html en la que queramos hacer uso de él.

El servlet que generará el javscript, resteasy-jsapi, debe ser cargado después del servlet de RESTeasy por eso los valores de los load-on-startup en las etiquetas servlet, si no lo hiciéramos así obtendríamos la siguiente excepción de error:

En el archivo helloworld-resteasy.jsp está como es la llamada al web service desde el navegador, básicamente consiste en generar un html que incluya la etiqueta script haciendo referencia al javascript a obtener en el navegador, contendrá los clientes javascript de todos nuestros web services REST. Aunque en el uso de los clientes las peticiones que se producen a través de la red estas operaciones son totalmente transparentes para nosotros, en cada correspondiente cliente javascript tendremos disponibles unos métodos que se encargarán de realizar y de la forma adecuada las peticiones teniendo entre otras cosas en cuenta como enviar los parámetros de los métodos. Una cosa a tener en cuenta es que en la interfaz del web service REST no debemos usar sobrecarga, mismo nombre de método con diferentes parámetros, ya que de otra manera el cliente javascript no sabe distinguir a que método del Servicio web llamar.

Recursos que pide el cliente Javascript

El último paso que tendremos que aprender es como devolver otros tipos de datos más complejos como json, xml, html u otros.

Referencia:
REST
Ejemplo sencillo de servicio web con RESTEasy
Código fuente completo del ejemplo Hola Mundo con RESTEasy

Ejemplo sencillo de servicio web con RESTEasy

2013-02-09T00:54:00.005+01:00

Las arquitecturas orientadas a servicios (SOA) no son nuevas y existen desde hace ya bastante tiempo. Surgen por la necesidad de las aplicaciones de comunicarse entre ellas para intercambiar información y colaborar. Dada la heterogeneidad de las mismas aplicaciones en el lenguaje de programación o de representación de datos requieren un lenguaje común con el que intercambiar información, para ello se puede emplear un lenguaje de marcas como XML y para el intercambio de mensajes SOAP (Simple Object Access Protocol) sobre el protocolo HTTP. Otras opciones como CORBA los mensajes se transmitían de forma binaria. Pero los servicios web basados en XML y SOAP no están exentos de problemas, los mensajes SOAP son bastante complejos y para algunas necesidades no son fáciles de construir o cómodas de usar, por ejemplo desde un navegador o un dispositivo móvil empleando javascript.

Dado el auge u omnipresencia que están tomando los servicios basados en internet, la web, los navegadores y javasctipt muchos de los sitios más importantes están evolucionando hacia servicios REST por su simplicidad de ser consumidos y fácil acceso, muchos sitios ofrecen una API basada en REST para que terceros puedan integrase con ellos, este es el principio para poder construir mashups. Algunas de sus características son que emplean el protocolo HTTP y sus diferentes métodos (GET, POST, DELETE y PUT, etc.) asignando a cada uno de ellos una operación de las denominadas CRUD (create -> PUT/POST, retrieve -> GET, update -> PUT/POST, delete -> DELETE). Pueden devolver datos en cualquier formato pero normalmente se emplea JSON o XML. En el siguiente enlace, muy recomendable, sobre algunos conceptos sobre las APIs REST está muy bien explicado las ideas sobre las que se basan estos servicios.

Para hacer sevicios web basados en REST con Java disponemos de varios frameworks entre ellos Restlet o Jersey, sin embargo, me ha convencido el ofrecido por la comunidad de JBoss, RESTEasy, tiene una muy buena documentación que está bien explicada y con la que es muy fácil iniciarse. Por lo tanto a continuación voy a poner lo necesario para implementar el ejemplo Hola Mundo con RESTEasy en una aplicación web java que puede ser hospedada en cualquier servidor de aplicaciones como Tomcat o JBoss.

Con RESTEasy los servicios web son POJO (Plain Old Java Object) a los que se les añade la fucionalidad mendiante anotaciones. Veamos como de simple podría ser el típico ejemplo sencillo de web service Hola mundo como demostración.

Aquí vemos varias anotaciones @Path, @GET y @PathParam. Con la primera estamos indicando parte de la URL en la que el web service responderá, con la segunda indicamos que el método HTTP que llame a esa URL deberá ser get y con la tercera recogemos un parámetro indicado en la URL. La implementación sería:

Una vez que disponemos del web service deberemos añadir al archivo web.xml las cosas necesarias para que RESTEasy recoja las llamadas a las URLs de los servicios web y los invoque, entre ellas el servlet de nombre resteasy de la clase HttpServletDispatcher. El web.xml sería el siguiente:

Lo básico a añadir es el servlet de RESTEasy y el correspondiente servlet-mapping, también deberemos indicar el parámetro de contexto «resteasy.servlet.mapping.prefix» con el prefijo de la ruta del servlet-mapping del servlet de RESTEasy. Con esta configuración todas las URLs que lleguen a la aplicación web y con la ruta «/rest/» corresponderán a un web service REST, una cosa a destacar es que los servicios web pueden convivir con con el resto de la aplicación independientemente del framework que uticemos para desarrollarla, lo único que deberemos hacer es indicar un prefijo para el servlet de RESTEasy tal y como hemos hecho en el ejemplo.

Pero... ¿Como sabe RESTEasy cuales son los servicios web de la aplicación? La forma de indicarle a RESTEasy los servicios web es mediante una clase que extiende de javax.ws.rs.core.Application y utilizando el parámetro de inicialización javax.ws.rs.Application para el servlet de RESTEasy que se puede ver en el web.xml. La implementación no tiene más que un Set con las implementaciones de los servicios web, en el caso del ejemplo:

Para finalizar, comentar que RESTEasy se puede configurar también como un filtro, lo que tiene algunas ventajas como descubrir de forma dinámica los servicios web sin necesidad de la clase Application. El resultado del servicio web invocado desde un navegador web es:

Este es el primer artículo de unos que escribiré sobre RESTEasy, en el siguiente explicaré como crear un cliente javascript o java para consumir este servicio web y en el último hablaré de como devolver datos en formato JSON o XML desde el web service.

Referencia:
Código fuente Hola Mundo con RESTEasy
Conceptos sobre APIs REST
http://www.jboss.org/resteasy
http://stackoverflow.com/questions/4131968/resteasy-path-requiring-a-full-path

Reproductor de radios Jamendo con Python

2013-02-01T19:28:00.000+01:00

Si sigues este blog desde hace un tiempo sabrás que de vez en cuando comento alguna cosa relacionada aunque sea de forma indirecta con la Raspberry Pi ya que es el computador que uso para realizar las descargas via torrent y para reproducir música principalmente con cmus. Dado que la uso sin ningún entorno de interfaz gráfica sino simplemente conectándome via SSH desde mi portátil y trabajando a través de comandos desde la terminal casi todo lo que quiera hacer con ella lo tengo que hacer a través de la terminal.

Para escuchar música suelo hacerlo de varias maneras: escuchar mi propia música en mp3 con cmus, escuchar radios que emitan por internet vía streaming o también las radios de Jamendo a través del reproductor de su página web. Jamendo ofrece una API a través de la cual se pueden escuchar las radios. Esto es lo necesario para poder escuchar las radios de Jamendo desde la RPi utilizando la terminal. Como quería aprender algo de Pyhton y es uno de los objetivos RPi me puse manos a la obra a hacer un pequeño programa, aún no sabiendo nada de este lenguaje de programación, que me permitiese escuhar cualquiera de las radios de Jamendo via streaming.

El resultado lo podéis encontrar en mi repositorio de GitHub en un archivo que no llega a las 100 líneas de código Python. Básicamente utiliza la API Rest que ofrece Jamendo para los desarrolladores que devuelve la información en formato JSON. Permite listar las radios disponibles en Jamendo según el estilo de música y los identificativos que utilizaremos luego para indicar al programa la radio que queremos escuchar.

Para usar el programa necesitaremos tener Python instalado y dado el que reproduce la música realmente es el programa mpg123 necesitaremos instalar también su paquete.

Después de habernos descargado el programa y habiéndole dado permisos de ejecución con:

Podemos obtener un listado de las radios con su nombre e identificativo usando:

Una vez que sepamos la radio que queremos escuhar lo haríamos con, en caso de que fuese la radio Classical:

Este programa se puede usar en cualquier sitio que tenga esas dependencias aunque en un ordenador de escritorio o portátil no nos sea imprescindible como en el caso de la Raspberry Pi ya que en los primeros podremos usar el reproductor web de Jamendo. Aún así aquí está para quien le pueda resultar útil como a mi. El programa no capturará todas las condiciones de error que se puedan producir, tener en cuenta que está realizado por alguien que sabe programar, conoce el lenguaje y API de Java pero no de Python. En cualquier caso si alguien cree que puede ser mejorado solo tiene que comentarmelo, enviarme un parche, ... ;)

Referencia:
Guías de instalación Raspberry Pi y desempaquetado
4 formas de escuchar música a través de internet

4 formas de escuchar música a través de internet

2013-01-25T18:19:00.000+01:00

Si nos gusta la música probablemente tendremos una colección amplia de canciones de diferentes artistas y géneros, sin embargo, por muy amplia que sea tal vez en algún momento nos apetezca escuchar algo diferente a la música que tenemos o nos apetezca escuchar la música del momento a través de alguna radio que emita por internet via streaming.

Muchas radios ya emiten a través de internet y por tanto las podemos escuchar desde el ordenador siempre y cuando tengamos una conexión a internet. Si no queremos usar el applet flash que normalmente proporciona cada radio en su propia página web podemos usar VLC, Banshee o incluso desde la terminal o consola. Para esto último ello basta con que tengamos instalado el programa mpg123 y conozcamos la URL en la que emite la radio lo cual a veces no es sencillo ni viendo el código fuente de la página del reproductor del applet flash pero escuchar música o radios por internet disponemos de varias opciones más, estas son algunas de ellas:

VLC

El reproductor multimedia VLC además de reproducir vídeos, música en prácticamente todo formato conocido de medio puede reproducir música por internet de forma bastante sencilla para el usuario. Solo hay que ir a la opción Ver > Lista de reproducción en la opción Internet de la lista de reproducción disponemos de varias opciones en cuanto a música y radios:

Free Music Charts: aunque parece que esta opción ha dejado de actualizarse desde hace bastante tiempo.
Icecast Radio Directory: esta es una lista de radios que emiten por internet, hay un montón de radios que podemos escuchar solo deberemos encontrar una que nos guste. Algunas de las radios emiten la música que está pegando fuerte en el momento.
Jamendo Selections: Jamendo es una colección de música en la que la mayor parte de la misma esta con licencia creative-commons que nos permite además de escucharla también con el propio reproductor de Jamendo en su propia página web poder descarganos las canciones a nuestro ordenador en formato mp3. Con VLC podemos escuchar la música emitida en las radios de Jamendo, hay radios para varios estilos de música: Rock, Pop, Jazz, Dance, Hiphop+Rap, World+Reggae, Lounge+Ambient. También tenemos una lista de las 100 pistas más populares, además de cada estilo junto con las 100 y 20 pistas más populares de la semana.

Con VLC también podemos Escuchar radios a través de internet como la Radio Nacional de España.

Linea de comandos con mpg123

El programa mpg123 nos permite escuchar música desde la linea de comandos con un consumo ridículo de recursos y sin necesidad de un programa con una interfaz gráfica, lo que nos puede ser útil para la Raspberry Pi. Tan sólo deberemos conocer la URL en la que emite la radio. La mayoría de las radios del Icecast Radio Directory proporcionan un enlace M3U con la dirección de la radio y algunas radios de cada país como el caso de la radio nacional de España (RNE):

RNE 1
Radio Clásica
Radio 3
Radio 4
Radio 5 Todo Noticias
Radio Exterior
Lista de radios nacionales

Teniendo la dirección URL de la radio la reproducimos con:

cmus

cmus es un reproductor de música basado en la consola que además de permitirnos escuchar nuestra música local nos permite también escuchar las radios que emitan via streaming. Al igual que con mpg123 solo necesitaremos la URL en la que emite la radio. Una vez que tenemos la URL y cmus iniciado deberemos teclear lo siguiente para añadir la radio a nuestra colección de música en cmus:

La ventaja de cmus sobre mpg123 es que no hará falta que recordemos o obtengamos la URL cada vez que queremos reproducir una emisora ya que con los comandos anteriores, dentro de cmus quedarán añadidos a nuestra librería en el artista «Stream».

Jamendo

Jamendo es una colección de música realizada por artistas no tan comerciales como la que solemos escuchar normalmente en las radios y que muchos artistas publican sus creaciones con una licencia creative-commons que nos permite incluso descargarla para un uso privado por lo que si estamos cansados de escuchar siempre lo mismo puede ser un viento de aire fresco para nuestros oídos además de poder descubrir nuevos grupos. La música la podemos escuchar desde la propia página de Jamendo con el reproductor integrado en su web con el navegador. Podemos escuchar cualquiera de las radios con diferentes estilos de música o utilizar el buscador para seleccionar algún estilo de música más específico.

Si quieres escuchar las radios de Jamendo desde la terminal o desde la Raspberry Pi puedes hacerlo utilizando este reproductor programado en Python.

En definitiva 4 formas diferentes de poder variar lo que solemos escuchar.

Referencia:
Escuchar radios a través de internet con VLC

Autenticación SSH con clave privada y pública

2013-01-11T13:44:00.001+01:00

Siguiendo el artículo de la semana pasada sobre como hacer que los programas no se terminasen al finalizar o perderse la conexión SSH en esta entrada explicaré como conectarnos a un una máquina de forma remota mediante SSH con una clave pública y privada en vez de con la contraseña del usuario.

Normalmente mediante contraseña nos conectamos a la máquina remota mediante el siguiente comando:

Esto nos pedirá la contraseña del usuario con el que trabajaremos en la máquina remota, en este caso la contraseña del usuario raspberrypi, y la deberemos introducir cada vez que realicemos la conexión. Si nos conectamos varias veces, realizamos conexiones a diferentes máquinas o nos conectamos con diferentes usuarios más pronto que tarde nos cansaremos de introducir la contraseña constantemente además de tener que estar recordando cada una de ellas si trabajamos con diferentes usuarios y asignamos a cada uno de ellos una diferente.

Todo esto se puede solucionar usando una clave privada y otra pública SSH con las que no necesitaremos proporcionar ninguna contraseña ya que será la clave privada la que nos autenticará. No necesitaremos proporcionar ninguna contraseña siempre y cuando no protejamos la clave privada mendiante una contraseña para poder usarla.

El par de claves SSH se generan con, se pueden utilizar otros algoritmos como RSA y DSA aunque ECDSA es el recomendado por OpenSSH por ofrecer la misma seguridad con un menor tamaño en bits para las claves. Sin embargo, en el ejemplo usaré RSA por el siguiente bug de GNOME:

Al final del proceso veremos la huella digital de la clave, si en algún otro momento deseasemos ver la huella alfanumérica o visual podríamos hacerlo con:

Una vez que disponemos del par de claves deberemos subir la clave pública a la máquina que posteriormente nos conectaremos identificandonos con la clave privada. Lo hacemos con:

Esta clave pública quedará como autorizada para la máquina y usuario indicados y será añadida al archivo ~/.ssh/autorihed_keys en la máquina destino. Si posteriormente quisieramos desautorizar alguna clave solo deberemos borrar la linea de la clave de ese archivo. Posteriormente deberemos indicar en la máquina origen las identidades que queremos que proporcione el comando SSH cuando nos conectemos a alguna máquina con:

Si no hemos protegido la clave privada con ninguna clave la identidad quedará añadida con el comando SSH posterior, si hemos protegido la clave privada deberemos introducir la contraseña para poder añadir la identidad.

Finalmente, nos conectaremos a la máquina con el comando SSH y accederemos a la máquina destino sin tener que proporcionar ninguna clave:

Referencia:
https://wiki.archlinux.org/index.php/Secure_Shell#Client
https://wiki.archlinux.org/index.php/SSH_Keys
Guía instalación Raspberry Pi con Arch Linux ARM (Parte I, instalación base)
Guía instalación Raspberry Pi con Arch Linux ARM (Parte II, programas)

Dejar procesos vivos de conexión SSH con screen

2013-01-04T20:22:00.000+01:00

El software libre y Linux es sorprendente, a veces nos surge una necesidad que no sabemos como resolver pero en el mundo del software es muy probable que el mismo problema se lo haya encontrado otra persona antes así que lo primero es buscar en internet, foros y ver cuales son las respuestas que obtiene esa persona que pregunta con el mismo o un problema parecido al nuestro para ver si alguien ha dado con la solución. Dependiendo del problema quizá descubramos un programa específico para resolver el problema.

Este es el caso que me ha surgido recientemente con la Raspberry Pi. Lo explico, a la RPi me conecto por SSH y dado que si se cierra esa conexión SSH se terminan todos los procesos lanzados en esa conexión SSH tengo que tener encendido el ordenador y la conexión SSH abierta hasta que termine de hacer lo que estaba haciendo. En la mayoría de los casos esto no es un problema pero para dejar la RPi reproduciendo música con cmus sí lo es ya que si se cierra la conexión SSH se termina el reproductor y se deja de escuchar la música, con lo que no puedo apagar el ordenador y dejar únicamente la RPi encendida que para reproducir música es mucho mejor que un ordenador porque no hay ruido de ventiladores y discos girando y la música se escucha más limpia sin ruidos adicionales por muy bajos que sean.

Screen, es una herramienta que nos resolverá ese problema además de proporcionarnos alguna funcionalidad adicional interesante. Con esta herramienta podemos dejar una terminal viva y sus procesos ejecutándose aunque se cierre la conexión SSH. Su uso es conectarnos mediante SSH de forma normal, ejecutar:

...que lanzará una segunda terminal en la sesión SSH y cuando queramos dejar la terminal de screen viva ejecutar CTRL+A y a continuación CTRL+D y ya podremos cerrar la terminal SSH original con exit, la terminal de screen y los procesos se seguirán ejecutando. Otra característica de screen es que podemos reconectarnos más tarde a la terminal de screen que dajamos viva, para ello nos volvemos a conectar mediante SSH y ejecutamos:

por si este fuera poco el volvernos a reconectar a la terminal de screen más tarde lo podemos hacer desde cualquier ordenador, no tiene por que ser el mismo ordenador desde el que iniciamos la terminal de screen, con lo que podemos iniciar los procesos en un ordenador, desplazarnos de sitio y continuar en otro. Lo que en algunos otros casos puede ser muy útil.

El paquete para instalarlo en Arch Linux es screen y lo hacemos con:

Referencia:
http://raspi.tv/tag/how-to-detach-a-process-on-ssh-without-killing-it
https://wiki.archlinux.org/index.php/GNU_Screen
Autenticación SSH con clave privada y pública
Guía instalación Raspberry Pi con Arch Linux ARM (Parte I, instalación base)
Guía instalación Raspberry Pi con Arch Linux ARM (Parte II, programas)

Calendario Arch Linux 2013

2013-01-01T00:10:00.000+01:00

El año pasado realice el calendario tematizado de Arch Linux y este en un poco de tiempo lo he modificado y adaptado al año 2013. Se trata de un modelo que después de varias dobleces y partes que hay que pegar se convierte en un dodecaedro que podemos tener encima de la mesa además para consultarlo alguna vez para decorar. Si eres usuario de otra distribución que no sea Arch Linux puedes descargarte el archivo svg contenido en el archivo zip del enlace anterior y modificarlo para adaptar los colores y el logotipo ya uses Fedora, OpenSUSE, Ubuntu, Mint, Debian, ...

Calendario Arch Linux 2013

El 2012 al final se me pasó y no lo construí ya que no dispongo de impresora, este 2013 espero poder imprimirlo en alguna fotocopistería y colocarlo junto a Tux y el cheat cube de Arch Linux. A continuación está proceso de ensamblado del calendario calendario y el resultado final.

Además de este calendario también hace un poco de tiempo también adapté un cheat cube de Ubuntu a la distribución Arch Linux por si alguien le coge gusto a esto del papel, probablemente para un usuario avanzado no sea especialmente útil más bien tiene una funcionalidad decorativa.

El cheat cube, el calendario y tux

¡Que empecéis bien el 2013!

Referencia:
Calendario Arch Linux 2013

El blog de pico.dev te desea un 2013...

2012-12-24T12:32:00.000+01:00

Otro año más que pasa para El blog de pico.dev y ya son casi tres años desde que empecé a escribir en él. Este año han sido 50 entradas las que he escrito un poco menos de una por semana, meta que me fijé como la adecuada para mi, que he ido haciendo con constancia y regularidad. Me gustaría poder dedicarle más tiempo al blog ya que ideas para entradas no me faltan a medida que voy curioseando sobre como se hacen o funcionan algunas cosas, ya tengo una buena cantidad de ellas acumuladas que durante el 2013 iré desarrollando. Aunque pueda parecer que no cada entrada requiere bastante tiempo de dedicación para aprender, investigar, programar algún ejemplo y luego escribir la entrada aunque luego se ve recompensado por los visitantes que las leéis, la satisfacción de escribir sobre lo que en cada momento más me interesa con total libertad y aunque pocos pero también con los comentarios de la gente que veo algunas cosas les han resultado útiles.

Pasado otro año más toca hacer balance de los números de este blog. Si durante el 2011 fueron 34.271 visitas, 25.251 visitantes y 55.280 páginas vistas que ya me parecían muchas este 2012 a falta de unos días han sido 64.364 visitas de 52.075 visitantes con 86.432 páginas vistas, unos números que no son duplicar los del año anterior pero casi. Si a principios de año empezaba con entre 100 y 150 páginas vistas al día el año ha acabado con entre 250 y 400 páginas vistas diarias. También se nota en la publicidad AdSense que suele ser habitual ya tener unos ingresos de 3€ mensuales, a este ritmo el 2013 superaré los 70€ necesarios para que Google me recompense por la publicidad que ya veré de que manera se los devuelvo en parte a la comunidad ya sea pidiendo unas pegatinas con el logo de Arch Linux para el portátil si es así algunas puede que reparta por correo, una taza, o ...

Estas son las entradas que he escrito durante la segunda mitad de este 2012 (en la etiqueta hemeroteca puedes ver las de otros semestres):

Hemeroteca #2

Apache Tapestry
Validaciones de datos de formularios con Apache Tapestry
Extender las validaciones de Apache Tapestry
Como devolver un archivo con Apache Tapestry
Como enviar un archivo con Apache Tapestry

Programación
Pruebas unitarias con Spock y Mockito
Obtener información del entorno de una aplicación web en Java
JodaTime y como integrarlo con Hibernate
Análisis estático de código con PMD
Páginas PageCatalog, ServiceStatus e HibernateStatistics de Tapestry
Deshabilitar el parámetro jsessionid
Crear un archivo comprimido Zip con Java
Como crear y usar sprites en páginas HTML
Texto de la terminal en color con Jansi

Una serie de artículos sobre BPM, Activiti y Drools
Conceptos sobre procesos de negocio (BP, BPM, BPMS, ...)
Procesos de negocio con Activiti
Usar variables en un proceso de negocio con Activiti
Tratamiento de errores en procesos de negocio con Activiti
Reglas de negocio con Drools y Activiti

Linux
systemd, reemplazo de sysvinit
Guía para aprender a usar Vim
Convertir imágenes entre formatos y cambiar tamaño con ImageMagick

Las entradas sobre Linux han sido muy pocoas y es que Arch Linux me da tan pocos problemas y no tengo que reinstalar cada pocos meses que la verdad no encuentro mucho en lo que escribir, aún así espero poder actualizar las guías de instalación de Arch Linux que ya se han quedado en parte obsoletas.

Análisis de productos
Desempaquetado («unboxing») de Amazon Kindle Touch
Mi guía para elección de portátil nuevo
Desempaquetado Sony Vaio E 14P (SVE14)
Análisis software y BIOS de Sony Vaio E 14P

Si no quieres perderte nada de lo que está por venir en este blog durante el año que viene no pierdas la oportunidad de suscribirte al feed con tu lector favorito.

Ya no me queda más que ¡desearos un mejor y buen 2013!