Igor Minar ha publicado en su blog que han reescrito por completo mediacast, una aplicación web para que los empleados de Sun puedan publicar archivos.
Al parecer, la versión anterior estaba desarrollada con Servlets+JSP+Filtros y resultaba dura de mantener, por lo que decidieron reescribirla desde cero. Él sugirió que en el nuevo desarrollo se utilizara Rails con JRuby para desplegarlo en un servidor java. El equipo lo formaban él, que ya tenía alguna experiencia con Ruby on Rails, y otros dos compañeros más, éstos sin experiencia con Ruby o JRuby.
Algunas de sus razones para usar JRoR:
- Al comenzar desde cero, no tenían código heredado
- Utilizar el proyecto como prueba de concepto para otros usos
- Comprobar que se cumple la promesa Rails para el desarrollo rápido
- Algo nuevo y divertido para el equipo, para equilibrar las cosas no tan divertidas (La que más me ha convencido:P)
Por lo que comenta, la arquitectura de la aplicación no es demasiado compleja, aunque para mejorar el rendimiento utilizaron cacheos.
En el entorno de producción cuentan con un par de servidores balanceados T2000 con una unidad NAS compartida para el almacenamiento de ficheros, con Solaris 10, el JDK6, Sun Application Server 9.1 como servidor de aplicaciones y un servidor MySQL. Lo único que se echa de menos es que no de números de la carga que suele soportar el entorno de producción.
En cuanto al desarrollo, el core de la aplicación lo tuvieron listo en poco tiempo y parece que gracias a la poca cantidad de código necesario, el código lo revisaban rápidamente y los bugs los solían solucionar con pocas líneas de código. Encontraron problemas por no poder utilizar la mayoría de las gemas basadas en C y con las peticiones largas, que les supusieron la mayoría del tiempo de trabajo, ambos problemas los acabaron solucionando usando Java.
Que yo conozca, es la segunda aplicación que desarrolla una gran empresa con JRuby on Rails, tras Oracle Mix. Habrá que estar pendiente de los lenguajes dinámicos como JRuby y Groovy, pudiendo reaprovechar el conocimiento ya existente en Java y si va mejorando el rendimiento de estos lenguajes, quizás se empiecen a tener en cuenta como otra opción más dentro de la plataforma.
Después de varios meses colaborando con Martín Pérez, ya está online el cliente web de jLibrary, aunque todavía en beta por faltarle algunos ajustes. Es la primera aplicación web basada en jLibrary, además, se puede ver que la web del proyecto está publicada con la misma aplicación, con un repositorio específico para ello.
Esta aplicación, que aunque no llega tener toda la funcionalidad del cliente de escritorio, se echaba de menos por tener un cliente ligero para acceder desde un navegador. Además puede dar una idea de cómo utilizar jLibrary como core para otros desarrollos en entornos web.
En cuanto a funcionalidades:
- Se pueden navegar por los directorios y categorías de un repositorio, podemos ver el contenido de los documentos html y descargarnos cualquier tipo de documento.
- Realizar búsquedas sobre el contenido de los documentos de un repositorio
- Una vez autentificados con los usuarios creados para ello(por ejemplo kevin/kevin) en el repositorio demo, dentro del directorio PlayGround, se pueden crear directorios, crear documentos html, hacer uploads de documentos, asignar categorías y relacionar documentos.
- Suscribirse por RSS a un directorio
- Además se puede conectar desde el cliente de escritorio.
Para quien tenga curiosidad, están publicadas las características técnicas, tanto del servidor dónde se hospeda la aplicación como de algunas generales de la aplicación.
El cliente web, se distibuirá con la próxima versión de jLibrary, por lo que se agradece que contactéis con nosotros en caso de encotrar algún bug o simplemente para darnos feedback. Para contactar con nosotros lo podéis hacer en demo(arroba)jlibrary(punto)org o en la web del proyecto en sourceforge.
Ha sido mi primera aportación al mundo open source, del que tanto me he aprovechado:), y realmente es una experiencia que recomiendo:
- Me ha servido para aprender un poco de freemarker, maven, spring, al principio de mi colaboración a usar JSF... y aplicar algunas otras que ya conocía.
- El ver como gente de cualquier parte del mundo se interesa por el proyecto en el que colaboras, que al final de todo es lo que nos debería satisfacer como desarrollardores, que algo en lo que participas resulte útil, y espero que cuando salga la próxima versión de jLibrary sea el caso.
- Trabajar con Martín "mano a mano", que es un fuera de serie.
Este dolor de cabeza en forma de bug hacía bastantes días que lo tenía, utilizando la librería LiveValidation para validaciones con javascript con IE 6.
Pues resulta que cuando intentaba crear una nueva validación a un textarea concreto en un formulario, me daba un error:
LiveValidation::getElementType - Element must be an input, select, or textarea!.
A base de "debuggar" el código de la librería vi que al final la causa era porque ese textarea tenía un id=description, y al hacer la comprobación de si el elemento con ese id es un input, un textarea o un select devolvía un meta por el meta name=description... del header.
La solución tan sencilla como cambiar el dichoso id y seguidamente informar a los autores de la librería sobre el bug.
