Daniel Latorre ha sido tan amable de anunciar oficialmente (en castellano) en su blog el lanzamiento de la nueva web de jLibrary y su demo online. Durante los últimos meses Daniel y yo mismo hemos estado trabajando en llevar a jLibrary a la web, y creo que el objetivo se ha cumplido y que el resultado es bastante satisfactorio.
Desde que comencé el proyecto allá a finales del 2003, desde siempre la principal "feature" que había faltado era la posibilidad de navegar tus respositorios de documentos via web. La aplicación de escritorio es fenomenal, y siempre recibo mensajes o leo mensajes en el foro del proyecto hablando maravillas de la misma. Pero lo cierto es que una de las cosas de las que me arrepiento en este proyecto es el de no haber lanzado la web con mucha más antelación. Pero bueno, el proyecto siempre ha sido un playground en si mismo, y creo que tanto Daniel como yo mismo lo hemos aprovechado para aprender nuevas tecnologías estos últimos meses.
La demo está disponible en http://demo.jlibrary.org. Daniel explica en esta entrada como utilizarla. Ambas páginas, la demo y jLibrary, comparten el mismo servidor pero son distintos repositorios de documentos. La única diferencia es que la demo te permite subir documentos y jugar un poco con ellos. Se puede acceder a ambos repositorios usando el cliente de escritorio, aunque eso ya está explicado en la documentación.
Por aportar algo más deciros que el desplegar esta web online nos ha ayudado ha encontrar algunos leaks en el sistema que estaban ahí, ocultillos. Hemos desplegado un sistema de monitorización que nos ha sido bastante útil para ello, así que ahora estamos bastante contentos con el resultado. El servidor es bastante modesto y está ejecutándose sobre un VPS con 384Mb de RAM, aunque realmente no utiliza mucho. La verdad es que no tengo números muy exactos porque siempre reinicio el servidor para meter algún parchecillo, pero la última vez que miré llevaba una semana de ejecución y no había hecho ni una sola "major garbage collection", lo que está muy bien :)
Claro que una segunda lectura es que la actividad no es demasiada, jejeje. Solemos tener entre 5-10 sesiones abiertas, se suelen crear cada dia unos 3 o cuatro documentos, actualizarse lo mismo y la gente va creando también unos cuantos comentarios. El repositorio anda por los 100Mb, 200Mb de tamaño y normalmente la gente visitará unas 1000 o 2000 páginas por día, más o menos.
Update: Desde que lo han anunciado en javaHispano ahora ya sabemos que soporta bien las 60-70 sesiones concurrentes :-)
Como veis, números muy modestos, pero estamos bastante contentos con el resultado. Por cierto, muchas gracias Dani por echarme una mano con esto, ya que si no estuvieras tú por ahí, no creo que el proyecto hubiese visto la luz.
Mostrando entradas con la etiqueta jlibrary. Mostrar todas las entradas
Mostrando entradas con la etiqueta jlibrary. Mostrar todas las entradas
jueves, enero 24, 2008
martes, julio 31, 2007
¿Vale la pena buscar colaboradores en sf.net?
martes, julio 31, 2007 por Martín
Ahí queda esta pregunta abierta. Y es que tengo que reconcer que el servicio de recruitment de SourceForge.net me frustra. En fin, aunque hay que reconocer que SourceForge no tiene ninguna culpa; bastante hacen ofreciéndome ese servicio gratuito.
El caso es que lo que os voy a contar ya no es la primera, ni la segunda vez que me pasa. Pero iluso de mi, la semana pasada volví a picar, y se me ocurrió publicar un trabajo buscando gente interesada en hacer algo con jLibrary. La idea era (y es) probar jLibrary, crear alguna aplicación interesante sobre la web (incluso tipo scribd, que la gente la pueda usar para probar frameworks web; en fin que es un campo de pruebas interesante, y se me ocurrió publicar un anuncio para ver si había alguien interesado en el Open Source y sus oportunidades.
Durante las tres semanas que ha estado el anuncio abierto me han llegado mensajes de trece personas interesadas, cosa que me parece que está bastante bien, y se asimila a lo que ya he tenido en las otras ocasiones que he publicado un trabajo. Lo que me frustra es que la mayoría de las personas que se ponen en contacto conmigo:
Uno de los últimos me mató cuando me pedía que le enviase la documentación de sus tareas y diagramas de diseño que especificasen lo que tenía que hacer. No sé si lo hizo a propósito pero vaya bajón de moral.
En fin que tras mis experiencias buscando gente en sf.net me queda claro que los canales tradicionales: amigos, usuarios de tu aplicación, empresas interesadas, son mucho más productivos.
El caso es que lo que os voy a contar ya no es la primera, ni la segunda vez que me pasa. Pero iluso de mi, la semana pasada volví a picar, y se me ocurrió publicar un trabajo buscando gente interesada en hacer algo con jLibrary. La idea era (y es) probar jLibrary, crear alguna aplicación interesante sobre la web (incluso tipo scribd, que la gente la pueda usar para probar frameworks web; en fin que es un campo de pruebas interesante, y se me ocurrió publicar un anuncio para ver si había alguien interesado en el Open Source y sus oportunidades.
Durante las tres semanas que ha estado el anuncio abierto me han llegado mensajes de trece personas interesadas, cosa que me parece que está bastante bien, y se asimila a lo que ya he tenido en las otras ocasiones que he publicado un trabajo. Lo que me frustra es que la mayoría de las personas que se ponen en contacto conmigo:
- No tienen ni idea de que va el proyecto o,
- tienen idea pero ni siquiera se lo han descargado y/o probado o,
- no tienen los conocimientos suficientes de Java para bajarse Maven y construir el proyecto o,
- tienen los conocimientos pero en cuanto ven que les pides un poco de esfuerzo para al menos construir el proyecto, ejecutar los unit tests, etc., se les baja el subidón inicial y prefieren buscar otra cosa más sencilla o,
- (y esta es la buena) asumen que es un trabajo remunerado. Lo siento, pero en esta ocasión va a ser que no.
Uno de los últimos me mató cuando me pedía que le enviase la documentación de sus tareas y diagramas de diseño que especificasen lo que tenía que hacer. No sé si lo hizo a propósito pero vaya bajón de moral.
En fin que tras mis experiencias buscando gente en sf.net me queda claro que los canales tradicionales: amigos, usuarios de tu aplicación, empresas interesadas, son mucho más productivos.
domingo, julio 01, 2007
jLibrary 1.1 disponible
domingo, julio 01, 2007 por Martín
Pues nada, me toca anunciar esta actualización de mi proyecto jLibrary que la mayoría ya conocéis. No me voy a parar mucho en las novedades porque, tampoco son muchas y las podéis encontrar en la web.
Lo más notable es la migración del cliente a Eclipse 3.2, la sustitución del protocolo de servicios web por algo más ligero basado en tunnelling HTTP, la posibilidad de añadir propiedades personalizadas a los documentos, y finalmente que ahora hay una nueva versión para Mac OS X. Además las versiones de Linux son mucho más estables ahora, y el proceso de construcción está basdo en Maven 2 y ahora es mucho más sencillo, lo que debería hacer más fácil que alguien interesado en el proyecto sea capaz de ponerse a trabajar con el en minutos.
Dejando a parte las novedades, para mi esta ha sido más que nada una versión de compromiso. Ha sido una actualización moral. Con jLibrary 1.0 había una serie de cosas que no me gustaban nada, especialmente que no pudieras subir documentos grandes (+10Mb) sin incrementar el tamaño del heap de las máquinas virtuales del cliente y servidor, todo ello debido al consumo y a la forma en que Axis transmite los contenidos. Otro compromiso fue las continuas peticiones por parte de usuarios de poder crear propiedades personalizadas, aunque esto último también tiene que ver con la orientación que le quiero dar ahora al proyecto. Y por último estaba la necesidad moral de cambiar el método de construcción; sustituir todos los hacks de Ant por algo mucho más decente y sencillo basado en Maven.
Todos estos cambios han llevado mucho más tiempo del que me temía. Mi cambio de residencia y de forma de vida ha reducido drásticamente el tiempo que le he podido dedicar al proyecto; y si antes podía dedicarle dos horitas extras al día, pues ahora se han convertido en dos horitas extras a la semana. Todo ello me ha hecho replantearme el futuro de jLibrary.
Y es que para mi ahora mismo jLibrary ha llegado a lo que debe ser un punto de inflexión. Muy probablemente esta sea la última versión del cliente basado en Eclipse RCP, que yo haga. En su momento estaba interesado en la tecnología, pero creo que ya la he aprendido más que de sobra :-) Así que es algo que no me motiva demasiado ya.
Lo que sí que me interesa mucho más ahora es trabajar en la parte servidor de jLibrary. En mi opinión el proyecto puede ser un banco de pruebas muy bueno para muchas tecnologías. Es un servidor estable, que ofrece una abstracción documental sobre una tecnología estándar (JSR-170) y que se me antoja como un banco de pruebas muy interesante. La idea es que para mi es más fácil ahora utilizar jLibrary para probar un determinado framework que crear desde cero todo un modelo de datos, relaciones, persistencia, configuración, etc.
Es decir, que si quiero probar Wicket, Seam y similares, pues puedo utilizar jLibrary para ello; que si quiero jugar con Grails, pues más de lo mismo; qué si lo que quiero es crear una web de reviews, un sistema de blogs, un youtube de documentos, o una alternativa a diggs meneames y similares, pues ahí está un framework que me ofrece ya las abstracciones para documentos, directorios, recursos, categorías, tags, relaciones, bookmarks, que además soporta propiedades personalizadas, y que tiene una aplicación de escritorio para administrar todos los datos.
Si alguien está interesado en esta idea, tiene algo en mente, quiere probarlo, etc., pues sólo tiene que mandarme un correo (mpermar en gmail). Las posibilidades están ahí, y a ver si sale algo de todo esto. Quizás no salga nada, pero mientras se pueda juguetear y aprender, pues ya habrá beneficio.
Lo más notable es la migración del cliente a Eclipse 3.2, la sustitución del protocolo de servicios web por algo más ligero basado en tunnelling HTTP, la posibilidad de añadir propiedades personalizadas a los documentos, y finalmente que ahora hay una nueva versión para Mac OS X. Además las versiones de Linux son mucho más estables ahora, y el proceso de construcción está basdo en Maven 2 y ahora es mucho más sencillo, lo que debería hacer más fácil que alguien interesado en el proyecto sea capaz de ponerse a trabajar con el en minutos.
Dejando a parte las novedades, para mi esta ha sido más que nada una versión de compromiso. Ha sido una actualización moral. Con jLibrary 1.0 había una serie de cosas que no me gustaban nada, especialmente que no pudieras subir documentos grandes (+10Mb) sin incrementar el tamaño del heap de las máquinas virtuales del cliente y servidor, todo ello debido al consumo y a la forma en que Axis transmite los contenidos. Otro compromiso fue las continuas peticiones por parte de usuarios de poder crear propiedades personalizadas, aunque esto último también tiene que ver con la orientación que le quiero dar ahora al proyecto. Y por último estaba la necesidad moral de cambiar el método de construcción; sustituir todos los hacks de Ant por algo mucho más decente y sencillo basado en Maven.
Todos estos cambios han llevado mucho más tiempo del que me temía. Mi cambio de residencia y de forma de vida ha reducido drásticamente el tiempo que le he podido dedicar al proyecto; y si antes podía dedicarle dos horitas extras al día, pues ahora se han convertido en dos horitas extras a la semana. Todo ello me ha hecho replantearme el futuro de jLibrary.
Y es que para mi ahora mismo jLibrary ha llegado a lo que debe ser un punto de inflexión. Muy probablemente esta sea la última versión del cliente basado en Eclipse RCP, que yo haga. En su momento estaba interesado en la tecnología, pero creo que ya la he aprendido más que de sobra :-) Así que es algo que no me motiva demasiado ya.
Lo que sí que me interesa mucho más ahora es trabajar en la parte servidor de jLibrary. En mi opinión el proyecto puede ser un banco de pruebas muy bueno para muchas tecnologías. Es un servidor estable, que ofrece una abstracción documental sobre una tecnología estándar (JSR-170) y que se me antoja como un banco de pruebas muy interesante. La idea es que para mi es más fácil ahora utilizar jLibrary para probar un determinado framework que crear desde cero todo un modelo de datos, relaciones, persistencia, configuración, etc.
Es decir, que si quiero probar Wicket, Seam y similares, pues puedo utilizar jLibrary para ello; que si quiero jugar con Grails, pues más de lo mismo; qué si lo que quiero es crear una web de reviews, un sistema de blogs, un youtube de documentos, o una alternativa a diggs meneames y similares, pues ahí está un framework que me ofrece ya las abstracciones para documentos, directorios, recursos, categorías, tags, relaciones, bookmarks, que además soporta propiedades personalizadas, y que tiene una aplicación de escritorio para administrar todos los datos.
Si alguien está interesado en esta idea, tiene algo en mente, quiere probarlo, etc., pues sólo tiene que mandarme un correo (mpermar en gmail). Las posibilidades están ahí, y a ver si sale algo de todo esto. Quizás no salga nada, pero mientras se pueda juguetear y aprender, pues ya habrá beneficio.
jueves, abril 12, 2007
Evaluando la salud de proyectos Open Source con ohloh
jueves, abril 12, 2007 por Martín
En fin, que me he cortado porque iba a poner un título del estilo de "jLibrary vale 1 millón de dólares" mmmm. Creo que debería haberlo puesto porque igual alguien se animaba a invertir :)
El caso es que he estado jugando un poco con ohloh. Se trata de una aplicación web de análisis de proyectos Open Source. Básicamente lo que hace es analizar el código de proyectos que se encuentran en repositorios de Open Source como sourceforge.net y extraer una serie de hechos a partir de todos los datos. He estado probando el servicio con jLibrary y la verdad es que tengo que decir que los resultados son interesantes.
Por ejemplo, este es el análisis del coste del proyecto que hace ohloh:
Codebase 89,010 LOC
Effort (est.) 22 Person Years
Avg. Salary 55.000 $/year
Estimated cost: $1,193,250
En fin, mmmm, los sueldos son bastante altos para España, así que supongo que el coste realmente sería menor :D Tampoco sabía que tenía tan pocas líneas de código, la verdad. Lo cierto es que utilizaba tantos frameworks que alguno puede estar sorprendido que con tan pocas líneas se puedan hacer tantas cosas... la magina del Open Source :)
En cuanto al estado del proyecto, hay que decir que ohloh lo clava:
Mostly written in Java
Factoid: "Small development team"
Over the past twelve months, only 5 developers contributed new code to jLibrary, making this a relatively small project.
For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 8 developers have contributed.
Yo creo que el análisis es perfecto, ya que en el último año prácticamente yo he sido el único que ha trabajado (y poco) en el proyecto. Además, no me ha sacado ningún warning sobre las licencias, cosa que sí se lo saca a muchos proyectos a poco que os pongáis a investigar un poco. También se ve que está bien comentado, porque ohloh pone un warning a todos los proyectos que no tienen comentarios.
En fin, que tampoco te va a dar un análisis muy completo del repositorio y del proyecto, pero encuentro que ohloh es un servicio muy bueno para evaluar la salud de proyectos Open Source. Y vosotros, ¿qué tal van de salud vuestros proyectos libres?
El caso es que he estado jugando un poco con ohloh. Se trata de una aplicación web de análisis de proyectos Open Source. Básicamente lo que hace es analizar el código de proyectos que se encuentran en repositorios de Open Source como sourceforge.net y extraer una serie de hechos a partir de todos los datos. He estado probando el servicio con jLibrary y la verdad es que tengo que decir que los resultados son interesantes.
Por ejemplo, este es el análisis del coste del proyecto que hace ohloh:
Codebase 89,010 LOC
Effort (est.) 22 Person Years
Avg. Salary 55.000 $/year
Estimated cost: $1,193,250
En fin, mmmm, los sueldos son bastante altos para España, así que supongo que el coste realmente sería menor :D Tampoco sabía que tenía tan pocas líneas de código, la verdad. Lo cierto es que utilizaba tantos frameworks que alguno puede estar sorprendido que con tan pocas líneas se puedan hacer tantas cosas... la magina del Open Source :)
En cuanto al estado del proyecto, hay que decir que ohloh lo clava:
Mostly written in Java
Factoid: "Small development team"
Over the past twelve months, only 5 developers contributed new code to jLibrary, making this a relatively small project.
For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 8 developers have contributed.
Yo creo que el análisis es perfecto, ya que en el último año prácticamente yo he sido el único que ha trabajado (y poco) en el proyecto. Además, no me ha sacado ningún warning sobre las licencias, cosa que sí se lo saca a muchos proyectos a poco que os pongáis a investigar un poco. También se ve que está bien comentado, porque ohloh pone un warning a todos los proyectos que no tienen comentarios.
En fin, que tampoco te va a dar un análisis muy completo del repositorio y del proyecto, pero encuentro que ohloh es un servicio muy bueno para evaluar la salud de proyectos Open Source. Y vosotros, ¿qué tal van de salud vuestros proyectos libres?
domingo, enero 28, 2007
Sobre Eclipse RCP y la EclipseCon 2007
domingo, enero 28, 2007 por Martín
Estoy de suerte. Parece ser que este año me han vuelto a nominar para los Eclipse Awards Nominations dentro de la categoría de Best Open Source RCP Application. El año pasado por estas fechas estaba ya planeando el viaje. Mi ex-compañía y mis ex-jefes, se portaron fenomenal y pusieron su granito de arena, así que en primavera pude estar en California disfrutando de la EclipseCon.
Este año se celebra la EclipseCon 2007 aunque casi al 99.9% que no estaré allí, salvo sorpresa final. Las razones son varias, la más importante es que ya no estoy tan relacionado con la plataforma como estaba los pasados años. Una versión estable de jLibrary salió finalmente a la luz, así que el proyecto, en su parte cliente, se ha quedado más o menos estancado. Seguramente le dedicaré uno, o varios, post en el futuro, pero bueno, vamos, que por ahora sólo estoy trabajando ya en el servidor, para preparar una especie de entorno de pruebas para otras tecnologías interesantes como spring, ruby on rails, grails, etc.
Por otra parte, porque yo quería publicar este post para hablar de RCP. InfoQ ha publicado un estudio del uso de Eclipse RCP en la industria del mueble. El estudio es interesante porque muestra como integrar un CRM web existente basado en SugarCRM con Eclipse RCP, de modo que se aprovechan todas las ventajas de Eclipse RCP para ofrecer una aplicación de escritorio tradicional, mientras que se mantiene el servidor existente y todos sus servicios.
Si volvemos a echar un vistazo a las nominaciones de la EclipseCon 2007, veréis que realmente hay un mercado importante en cuanto a aplicaciones comerciales y despliegues en torno al concepto que plantea Eclipse RCP y a esta herramienta. De hecho el número de soluciones comerciales nominadas, supera y de largo al número de soluciones Open Source. Eso sí, me da la impresión de que faltan muchas empresas y productos en la lista. Pero aún así esto nos da una idea de que Eclipse RCP puede ser una opción muy interesante a a hora de crear un producto que pueda dar algo de dinerillo.
Pues ala, fin de la cuña publicitaria sobre Eclipse RCP :)
Este año se celebra la EclipseCon 2007 aunque casi al 99.9% que no estaré allí, salvo sorpresa final. Las razones son varias, la más importante es que ya no estoy tan relacionado con la plataforma como estaba los pasados años. Una versión estable de jLibrary salió finalmente a la luz, así que el proyecto, en su parte cliente, se ha quedado más o menos estancado. Seguramente le dedicaré uno, o varios, post en el futuro, pero bueno, vamos, que por ahora sólo estoy trabajando ya en el servidor, para preparar una especie de entorno de pruebas para otras tecnologías interesantes como spring, ruby on rails, grails, etc.
Por otra parte, porque yo quería publicar este post para hablar de RCP. InfoQ ha publicado un estudio del uso de Eclipse RCP en la industria del mueble. El estudio es interesante porque muestra como integrar un CRM web existente basado en SugarCRM con Eclipse RCP, de modo que se aprovechan todas las ventajas de Eclipse RCP para ofrecer una aplicación de escritorio tradicional, mientras que se mantiene el servidor existente y todos sus servicios.
Si volvemos a echar un vistazo a las nominaciones de la EclipseCon 2007, veréis que realmente hay un mercado importante en cuanto a aplicaciones comerciales y despliegues en torno al concepto que plantea Eclipse RCP y a esta herramienta. De hecho el número de soluciones comerciales nominadas, supera y de largo al número de soluciones Open Source. Eso sí, me da la impresión de que faltan muchas empresas y productos en la lista. Pero aún así esto nos da una idea de que Eclipse RCP puede ser una opción muy interesante a a hora de crear un producto que pueda dar algo de dinerillo.
Pues ala, fin de la cuña publicitaria sobre Eclipse RCP :)
Suscribirse a:
Entradas (Atom)
