Linked

Y no, no me refiero a la canción de Leño, un clásico. Los dos últimos sábados, he tenido dos reuniones similares pero muy diferentes. De empresas pequeñas que buscan una forma de hacerse un hueco, aunque el concepto de pequeño es muy distinto en ambos casos, como también lo es el de hueco. No es que sean opuestas, pero por un lado se busca dominar el mundo, por el otro vivir de otra forma. En un lado hay sueños, en el otro ambición.

¡Qué se le va a hacer, yo soy un soñador!.

No sé si estoy en lo cierto
lo cierto es que estoy aquí
otros por menos se han muerto
maneras de vivir.

Descuélgate del estante
y si te quieres venir
tengo una plaza vacante
maneras de vivir.

Share This

Tengo que mirar más en detalle JPA (Java Persistence Api), pero si los propios miembros de la especificación lo suponen un subconjunto de JDO (Java Data Object), es de suponer que sea parecido. De todos es conocido el problema de Hibernate (y cualquier ORM) con lazy loading, de hecho ya hemos hablado aquí sobre ello. Básicamente sucede cuando después de cerrar el la transacción en el controlador (una acción de struts por ejemplo, o una clase de servicio) queremos cargar objetos relacionados definidos como lazy en la vista. Ahí aparece el temido LazyInitializationException.

Hoy no voy a hablar de eso, ya hay soluciones como el OpenSessionInView (he olvidado el término patrón a propósito), o más inteligentes, como utilizar Spring, por mucho que a alguno le pese. Pero en lugar de eso, voy a hablar de un desconocido, y como lo resuelve él: JDO, por si alguien tiene que escoger un ORM y se niega al borreguismo (dicho esto sin acritud hacía Hibernate, sino simplemente quiere ver distintas opciones, que nunca es malo).

En JDO, al igual que la mayoría de los ORM, tenemos por una parte nuestros beans, por otra la base de datos, y en medio tenemos un fichero con metainformación que relaciona ambas cosas, normalmente un xml. Sin entrar en detalles de como se trabaja con JDO, casi todos podrán entender:

Esta es la definición de una clase Task, que tiene varias relaciones (los campos primitivos no hace falta definirlos si nos valen los valores por defecto). La parte interesante es la del final, la llamada fetch-group.

Y es que por defecto se cargan las relaciones de forma perezosa, como en casi todas partes (y por tanto tendríamos el mismo problema). En JDO podemos definir distintos fetch-groups, para distintos usos normales de la clase, definiendo que queremos que se cargue en esos casos. Por ejemplo, en este caso, cuando cargamos un grupo de Task para un listado, se cargará el grupo por defecto (primitivos + String + Date, pero no relaciones, salvo status porque así lo hemos definido), pero cuando queremos mostrar una página de detalle, nos interesa tener a mano información sobre el tipo de tarea que es (taskType), su estado (en este caso es un objeto, no un valor, status), o si tiene añadidos varios fallos (bugs). Dejamos sin cargar los partes de horas, historial de cambios, etc.

Simplemente a la hora de hacer la consulta haremos algo así como (escribo de memoria):

query.getFetchPlan().addFetchGroup("detailsPage");

Limpíto, ¿no?.

Share This

Beta, muy beta, o más. Pero puesto que ya lo estamos utilizando hace unas semanas, hemos puesto online una versión de pruebas del gestor de proyectos que hemos estado realizando en los ratos libres y que ya comentamos en parte en el pasado. La parte más interesante, la que enlaza el trabajo con la rentabilidad (lease, los dineros) aún no tiene interface gráfica, pero ya es usable para el seguimiento del trabajo.

La idea que sigue es sencilla. Un proyecto tiene grupos de tareas o áreas de trabajo. Cada una de ellas tiene tareas, y cada tarea puede tener bugs. ¿Por qué un bug tiene que ir siempre asociado a una tarea (eso melo han preguntado)?, básicamente porque no debería haber errores en algo que no se ha realizado, ¿no?. Si una tarea o un bug es “trabajable”, entonces se puede introducir partes de trabajo sobre ellas, sólo de las últimas dos semanas, un requisito para que nos vayamos acostumbrando a utilizarlo.

La parte económica, pues bueno, básicamente mide el coste del proyecto, lo compara con el coste de producción, y con el coste de oportunidad, así como ir aprendiendo de estas desviaciones, intentar ver porque se producen, para después detectarlas lo antes posible y dar recomendaciones. Como veís, se nota que tengo más problemas que la simple programación. De esto, como he dicho, nos falta mucho (casi de todo) de la interface de usuario, aunque ya tenemos implementada la lógica en gran parte.

Simplificar la interface de usuario, añadir comentarios varios, control de roles y nuevas opciones, son algunas de las cosas que nos faltan por hacer.

¿Licencia?. La verdad es que es una buena pregunta. No lo tenemos decidido :-D. Opciones:

- liberarlo.
- regalarlo pero no entregar el código, a todos o sólo a empresas pequeñas
- venderlo a todo el mundo.

Como no nos veo con fuerzas para realizar las labores comerciales, la tercera opción no creo que sea (no espero retirarme con este producto). La primera… pues bueno, tampoco quiero perder el control sobre el producto, aunque es un opción. Aunque seguramente sea la segunda opción. El software se podrá descargar gratuitamente, al menos para empresas de menos de 10 personas, y ofrezcamos modificaciones y adaptaciones pagadas porque no ofreceremos el código libremente (notese, no lo haremos libremente ;-) ).

Casi lo olvido…. la URL: http://demo.projectio.com, usuarios admin, pm o employee, todos con password projectio. El tomcat dónde está me esta haciendo algunas cosas raras, pero bueno, no lo tengáis en cuenta, en teoría funciona ;-).

Se aceptan todo tipo de sugerencias, por supuesto, en la parte inferior de la demo tenéis un link para enviar sugerencias.

Share This

Últimamente cada vez tengo más la sensación de que el borreguismo en internet va creciendo, para llegar a los límites del mundo real. Siempre he compartido la idea de que la competencia está a un click (incluso para el todopoderoso Google), pero cada vez me está pareciendo más que según se suma gente a la red, no es que las opciones se reduzcan, sino que simplemente se crea un círculo vicioso alrededor de lo existente.

Pero últimamente me está preocupando más las consecuencias de la endogamia que produce esto que se llama Web 2.0 internet, o al menos una de sus partes, los blogs. Y es que es curioso como pueden manipular la realidad (aunque obviamente la culpa es de quién se deje manipular, o simplemente no averigüe lo suficiente). Pongamos un tema X, me da igual. Vas a hablar sobre ese tema con la empresa E1, y resulta que consideran un exporto al individuo I1, porque su consultor C1 le dice que es el mejor del mundo y que tiene un blog que es la releche, etc. Vas a la empresa E2, y te habla de I2, porque se lo comenta su C2 correspondiente. Y así sucesivamente, incluso en un nicho de mercado hiperexclusivo y que no tiene sentido que I1, I2, IX no se conozcan. Y el problema no está en esas relaciones, supongo que es de las empresas EX, que simplemente aceptan lo que se les dice. A fin de cuentas tampoco tienen porque no fiarse.

Pero esto de la internet, y esto sucede desde mucho antes de la Web 2.0, crea unas relaciones de confianza que me sorprenden. Yo mismo la he vivido. En el pasado, por el hecho de haber fundado javahispano tenía más respeto profesional por parte de algunas personas del que seguramente me merecía. Alguno me dirá que las relaciones entre blog se llevan más allá, se conocen personalmente, se entienden y que si dejan de hacerlo simplemente también se nota. Me parece que se crean millones de islas, formados por grupos de gente, a los que no es que les una un interés común (aunque seguramente lo hace), sino que simplemente la casualidad ha hecho que hayan acabado en un circulo o en otro. Y si entras a uno, ya esta, inmediatamente eres aupado a un nivel superior de lo que sea. Sin haber hecho nada, sin haber demostrado nada.

No lo sé. Cada día me parece menos real, o mejor dicho, me parece que esas relaciones irreales se convierten en relaciones irreales en la vida real, en pequeños reinos de taifas ridículos y endogámicos que no benefician a nadie.

Sé que esto puede parecer una pataleta, nada más lejos de la realidad, que entrase yo a un sitio en sustitución de otro sería una operación conmutativa que seguramente no cambiaría nada. Además ahora mismo no se me ocurre un sitio dónde yo quisiera estar, el ejemplo que he comentado es real de mi entorno pero que no tiene nada que ver conmigo. Simplemente lo mismo que hay cosas que me maravillan de internet, también hay cosas preocupantes.

Share This

Estamos buscando… desarrollador Java J2EE y desarrollador para móviles J2ME.

Share This