domingo agosto 31, 2003

... modelos dinámicos de objetos (2003-08-31 21:38:48.0) Permalink Comentarios [5]
Desde que a Akuma hizo su famoso curso de J2EE por aquí han caido distintos post sobre desarrollo web con Java, han sido varios los post sobre MVC, fron controller, etc. El último ha sido MVC(III): JavaServerFaces de Álvaro Zabala, y de rebote, en los comentarios, Akuma, que nunca deja de intentar aprender, pues ha acabado preguntando el por qué de usar OREO como motor de persistencia en Cáñamo. Bien, la solución es sencilla: modelos dinámicos de objetos.

¿Qué es eso?. Bien, el concepto viene descrito en un par de papers de Ralph E. Johnson, miembro de la GoF. La idea esta en separar los objetos de la definición de su composición, siguiendo un patrón llamado Type Object, es decir, tener una parte de metadatos (normalmente XML para que pueda cambiarse fácilmente, y que luego se cargará en forma de clases Java) que describe los objetos, y otra donde se almacenarán los datos de esos objetos. ¿Qué conseguimos con esto?: tener modelos de objetos dinámicos, que podremos manipular (añadir campos, eliminarlos, cambiar las relaciones entre los mismos, etc.) sin que tengamos que tocar el código de las clases que tienen que ver con persistencia (obviamente tendremos que tocar el código de presentación para permitir mostrar esos nuevos datos), ya que normalmente las clases de metadatos son cosntantes (clase, campo, relación, etc.), y la clase que almacenará los datos (simplificando un poco) es poco más que un Map para almacenar los valores, y por tanto podremos meter de todos.

No se si ha quedado claro. ¿Un ejemplo?. javaHispano, ¡como no!. GRacias a que usamos modelos dinámicos de objetos, podemos tener un mismo código (aplicación items) que gracias a su configuración podemos usar en varios sitios. Así, aunque no lo parezca, es el mismo código lo que esta ejecutando las secciones de noticias, IDEs, OpenSource, tutoriales, eventos, código útil y alguno más. Solo cambia las plantillas HTML que muestran los datos y la definición de los datos en un archivo XML. ¿Magia?, no, un modelo dinámico de objetos, concepto muy interesante en los sitios donde el modelo no este grabado a fuego.

¿Si es tan bueno por qué la gente usa más JDO o Hibernate (& Cia)?. Bien, realmente se podría decir que tienen otro enfoque, y no estamos hablando de un producto con la misma finalidad (vale, si, guardar cosas en una base de datos), aunque la razón de usar más uno que otro es suerte. Esas soluciones tienen o una emrpesa más grande detras, o más publicidad por venir de otra gente, o ... . No me importa, yo sigo diciendo que son cosas distintas. Tanto Hibernate (& Cia) como JDO se basan en el concepto una clase, una tabla, es decir, tu tienes un clase y dices donde guardarla, cuales son sus campos, etc. . Mientras que los modelos dinámicos se basan en un clase, n tablas, donde cada tabla puede tener una distintas estructura.

¿Problemas?. Por supuesto. El principal podría ser el de rendimiento, ten en cuenta que al estar metiendo otra capa de abstracción (la de los metadatos) en tu aplicación, estas perjudicando su rendimiento, no se pueden hacer optimizaciones que si se pueden hacer en otros casos. No os asusteis, no es que OREO sea 1000 veces más lento que Hibernate (por decir dos nombres), pero obviamente no es lo mismo, y en determinados entornos, con miles de transacciones simulatenas puede ser que esto sea algo a tener en cuenta. Para una aplicación normal, ningún problema.

En la actualidad, en la web, solo hay, que yo conozca, dos frameworks desarrolaldos en Java opensource que soporten modelos dinámicos, OREO y el Entity Engine de Open For Bussiness. ¿Por qué OREO?. Porque ya lo conocía, aunque mínimamente tuve algo que ver con su desarrollo, y ya sabía mucho de lo que podía ofrecer. Necesitaba algo y estaba ahí, aunque conozcía también sus limitaciones, hasta el punto de que lo que Cáñamo usa es una versión modificada de OREO (disponible en su CVS), donde se ha potenciado el SQL (la idea principal de OREO era trabajar de forma transparente con distintas fuentes de datos, como XML, LDAP y BD). OREO, por distintas razones lleva dos años parado (¡si, estas cosas ya existían hace tanto tiempo!), aunque por su calidad no se lo merece. En todo caso, Cáñamo esta basado en interfaces para poder cambiar las implementaciones de un montón de servicios, y ya he estudiado el EE de OfBiz para comprobar que puede hacer todo lo que Cáñamo podría necesitar, solo falta que algún día implemente el proxy que los una. ¿Voluntarios?.

Buff... cada vez que me pongo me sale un ladrillo. Mis disculpas.

viernes agosto 15, 2003

... pools y caches (2003-08-15 14:30:32.0) Permalink Comentarios [3]
aunque ya me ha pasado más veces, los comentarios de Álvaro a mi post sobre el front controller me ha recordado la aparente confusión que hay entre los conceptos de pool y cache en la informática.

Bien, pongamos un ejemplo en cristiano. Supongamos que mi empresa tiene una biblioteca interna en la primera planta, y que yo trabajo en la décima. Y supongamos que tienen dos volúmenes de cada libro. Esta biblioteca sería un pool de objetos, puesto que puedes coger los libros pero después tienes que devolverlos para que otro los utilice (el hecho de que haya varios libros no juega ningún rol en este caso). Cojo un libro, lo leo, lo devuelvo. Listo. Si el libro que quiero esta ya prestado, o me quedo esperando, o la librería compra una nueva edición (pool extensible), etc.
Como implemente aquí una cache?. Bien, si toda la gente que trabaja con Java esta en mi planta, porque no poner una habitación en la décima planta con los libros sobre java?. Así no tendremos que ir al primer piso y volveremos más rápido al trabajo. Pero que pasa si no me entran en esa habitacion todos los libros sobre java?, que tendre únicamente los que se usan más a menudo. Si alguién quiere uno que no se encuentra en esta habitación tendremos que devolver uno a la biblioteca principal para poder dejar allí el nuevo.

En informática... bien, se suele hacer una pool de objetos que se quieren reutilzar, normalmente porque nos ha costado mucho crearlos o por su simpleza en cuanto a complejidad de ejecución (como conexiones con sockets, EJB SLSB, etc.). Sin embargo queremos hacer una cache de datos que usamos mucho, o que preveemos que se van a volver a utilizar en breve (como los diez últimos post en un foro, Entity Beans) para evitar volver a cargarlos.

posiblemetne sean malos ejemplos, estoy seguro, pero esumiendo se podría decir: una pool hace que reciclemos, una cache hace que trabajemos menos.

jueves agosto 14, 2003

... Cáñamo (2003-08-14 09:34:26.0) Permalink Comentarios [5]
Casí todo el mundo que ha pasado por javaHispano me ha oido hablar alguna vez sobre Cáñamo (lo siento por la web de aspecto semi-abandonado, estamos remodelándola, pero el desarrollo sigue). Bien, ahora lo vuelvo a hacer. Sorry.

Para los que no lo sepais, decir que Cáñamo (licencia BSD), más que un framework para aplicaicones web, es algo así como un mini servidor de aplicaciones para aplicaciones web (aplicaciones que sigan unas normas, claro). Es decir, se parece más al núcleo de *Nuke (aunque mejorado) que a Struts (aunque ahora con los modulos de Struts se parezca más), aunque por supuesto, para que puedan ser ejecutadas por el motor tienen que seguir ciertas normas. Ahora mismo hay varias aplicaciones GPL para disponibles (catálogo de elementos para noticias y otros, artículos, foros, anillo de webs, etc.) de las que puede haber N instancias ejecutándose simultaneamente en una instancia (ejemplo: catálogo para noticias y también para listado de productos). Un ejemplo vivo de lo que se puede hacer con Cáñamo es javaHispano.

¿A que viene esto?. Simplemente a invitaros a participar en su desarrollo. Ahora es un buen momento, tres personas (y media) estan participando activamente en su desarrollo, una empresa (NHT-Norwick) esta usándolo y participando en el mantenimiento de su núcleo BSD, etc. Hay varias personas iniciándose con él, de modo que empezar varios a la vez puede resultar más sencillo.

Vale... ¿qué en la web no hay documentación?, cógela (de momento, ya he dicho que estamos de remodelación en la web) del CVS (módulo docs), encontrarás, como poco, la guía de instalación, la teoría de la guía del desarrollador y la práctica de la misma, creando el necesario hola mundo. Y por supuesto las listas de distribución.

Bien... ¿qué para que esto arranque necesitamos que más gente lo instale?, cierto, estas invitado a hacerlo. Obviamente tenemos que hacerlo accesible más fácilmente (trabajamos en ello!), pero el caso es que en de todos modos obtenerlo desde el CVS no debería ser un problema para nadie en estos días. Trabajamos también en hacer disponibles aplicaciones preconfiguradas (foros, portal, etc). Mucho que hacer.

Y todo esto.. ¿para qué?, ¿por qué dedicarle tu tiempo?.

• Primero, por hacer algo interesante, con gente interesante.
• Segundo por aprender, o por enseñar, o por mejorar, o discutir, lo que quieras.
• Opensource (aunque no es obligatorio). Lo que hagas podrán disfrutarlo todos, algo útil.
• Y por último, por javaHispano, si estas leyendo esto supongo que conoceras la web, y espero que quieras participar dentro de ella.

... sobre el front controller (2003-08-14 08:55:15.0) Permalink Comentarios [8]
Akuma ha hecho un curso sobre J2EE, y aunque no quedó del todo satisfecho, como resultado se ha puesto a jugar con el patrón front controller para aplicaciones web (El patrón front controller).
Le comenté el tema de no instanciar una acción para cada petición, y aunque reconoció no entenderlo del todo, lo implementó (Revisado: el patrón front controller). De aquí mi tirón de orejas por creerse las cosas a la ligera, aunque vengan de alguién tan convincente como yo ;-).

Ya que la explicación es un poco larga, pues le robo el post :-).

Antes de nada, supongo que habría claro por qué no queremos andar crendo instancias por cada petición. Bueno, pues no queremos porque andar creando esas instancias es una labor costosa (además por reflection), una labor que si bien ahora mismo podemos considerar requiere un tiempo despreciable es un tiempo que nos podemos ahorrar. Tened en cuenta que en una web más o menos grande (por ejemplo javaHispano, con entre 50 y 100 usuarios concurentes normalmente) podemos estar generando un montón de acciones.

Un entorno web es un entorno concurrente por definición, solucionado en Java en base a hilos, hasta aquí sin problemas. Entonces ¿por qué podemos permitirnos mantener una única instancia de una acción para servir todas las peticiones?. Bien, pues podemos, si y solo sí, solo accedemos a valores propios del hilo, en este caso, valores de la request, valores de la sesión y variables definidas en los métodos. Que la request y la sessión son propias de cada petición esta claro, sobre los métodos quizás no.

Las variables definidas en un método solo viven dentro de ese método, se crean con el método y se destruyen con el método. Es por eso que, mientras nuestras acciones solo utilizen para escritura (para lectura peuden usar variables de instancia) variables de ese tipo, no tendremos problema alguno de concurrencia, cada hilo tendrá las suyas propias.

¿Cual es el problema de esta aproximación?. Que puede invitar al programador (al menos si consigues hacer un framework de éxito) a olvidarse de posibles problemas de concurrencia y que acabe metiendo la pata. ¿Cuando puede ocurrir esto?: cuando te sales del método de ejecución para tratar algunas variables de instancia (datos cacheados y datos de configuración de la acción principalmente, aunque no únicamente), donde si que tendrás que usar la sincronización si piensas cambiar dichos valores.

En todo caso, aún no penseis que la implementación de Akuma es perfecta, más información la encontrareis como comentarios en su post.

miércoles agosto 06, 2003

... mi querida Alemania (2003-08-06 14:52:54.0) Permalink Comentarios [1]
Buah!, tengo un poco de morriña de mi exlugar de residencia. Aitor anda dando vueltas por las islas y por alguna razón tonta, para ir a Dublín paso por Frankfurt. Mi queria Alemania. Vale, quizás no Frankfurt, pero la idea es la misma ;-).

Como dice Aitor, hay muchos tópicos injustos sobre ese país, y uno de ellos puede ser su cordialidad, he vivido tres años allí, y la verdad, hay de todo, como en botica. El tiempo es malo, cierto, pero sin embargo cuando hace buen tiempo lo disfrutan mucho más que nosotros, y así se podrían atacar cada uno de los tópicos, aunque otros se cumplan. Y que quereis que os diga, ni el idioma suena siempre tan feo ni es tan difícil de aprender, los alemanes ponen muy buena voluntad en entenderte. Lqs prestaciones sociales son inmensas, etc, etc etc.
La verdad, a mi no me dolerían prendas por volver mañana.

Sinceramente, por lo que yo he visto allí, lo que más hace que estos tópicos sean reales e injustos son los españoles (e italianos, y el resto de habitantes de paises considerados más humanos ) que van allí una temporada, muchas veces estudiantes de Erasmus. Los que yo conocí no se mezclaban con los nativos (en realidad con cualquier no español o italiano), hablaban siempre castellano, no hacíanmás que quejarse, etc. El caso más sangrante es el de una chica que se quejaba porque de CUATRO exámenes tenía que hacer UNO en alemán (dos en inglés y uno en castellano). Joder!, a que ha venido?.

Generalizar es malo, lo sé, kein Flameware bitte!, y también hay alemanes malos, antipáticos y que vienen aquí sin ninguna intención de conocernos, pero que os puedo decir, desde mi experiencia nosotros tenemos más de que avergonzarnos.

Y ya para terminar, primero responderé a Aitor, no todos hablan cuatro idiomas perfectamente, pero es más común eso allí que aquí hablar aceptablemente dos (lo que aquí entendemos como inglés no cuenta ;-) ), mi novia es la tonta de su familia porque solo habla 4 y medio, aunque su familia tampoco se represnetativa, quizás.
Y por último, Aitor, que suerte tienes de haber tenido tiempo para hablar con una agradable azafata (que dirá Bego de los piropos que le has lanzado?), mi primera experiencia en Frankfuert, allá por Marzo de 1998, fué de pánico por no hablar alemán y tener 2 minutos para recorrerme ese inmenso aeropuerto!.

En fín, que tengo ganas de volver allí algún día.

viernes agosto 01, 2003

... de lo bonito que estaba hoy Bilbao (2003-08-01 17:35:32.0) Permalink Comentarios [6]
A pesar de ser fiesta (bueno, puente, la fiesta fué ayer) hoy me he pasado por las oficinas de mi empresa en Bilbao, para el que lo conozca, en pleno centro, Plaza Moyúa. Agosto, la ciudad tranquila, mucho calor, y después de la charla qzue tenía con mi jefe estuve de compras con mi novia. Gran Vía, Casco Viejo, vuelta a Gran Vía, parada para comer el menú del día del restaurante del Guggenheim (por si le interesa a alguno, en mi opinión ha subido el precio y bajado la calidad, solo los postres se salvan), paseo por Abandoibarra hasta el Palacio de Euskalduna y camino de San Mamés para coger el tren (vivo en Santurce, donde las sardinas).

bien, soy de Bilbao (vale, de cerca, de Santurce, ya lo he dicho), pero he estado tres años fuera, y solo puedo decir que Bilbao esta quedando precioso, al menos el centro. Todo el que conoció Bilbao antes del año 97, el de la apertura del Guggenheim si no recuerdo mal, puede olvidar la impresión que tenía, lo que se va a encontrar ahora no tiene nada que ver, por suerte, y les recomendaría que lo volviesen a ver, y si queiren pegarme un toque para tomar unos potes.

Solo hay que arreglar algunas de las partes de los alrededores de Bilbao, pero una vez listo con eso tendremos una bizkaia preciosa :-). Pero bueno, para los impacientes, simplemente que cierren los ojos al pasar por los suburbios y que se centre en todo el resto (centro de Bilbao, toda la costa, la sierra del Gorbea y Urkiola, etc.).

En fin, que se nota que soy de Bilbao, no?.