- kune-devel - lists.ourproject.org

Vídeo demostración de kune (a día de hoy)
by Vicente J. Ruiz Jurado 26 Jan '08

26 Jan '08

Hola queridos: Coincidiendo con el Día de Acción Global de Forum Social Mundial, acabamos de terminar un vídeo en el que mostramos un poco como está el desarrollo actual de kune: http://kune.ourproject.org/spip.php?article12 Lo que queríamos hacer en principio para este día era instalar una máquina con una demo, pero al final se nos ha echado el tiempo encima y no la hemos podido instalar por problemas logísticos. En poco tiempo espero que esté. La idea es mostrar entre nosotros (y enseñar a quien nos parezca oportuno) cual es el estado actual de desarrollo, dejar atrás los primeros bocetos, e ir hablando sobre los siguientes pasos a seguir. También queremos usar el vídeo para hacer una llamada a la colaboración del mundillo "hacker" ahora que podemos enseñar el código (antes era puro vaporware). No se si con tanto recorte (el vídeo original era tres veces más grande) se muestra lo suficientemente claro el funcionamiento, pero haceros a la idea que durante todo el video, solo se ha cargado una página web al principio (y luego se va modificando dinámicamente según lo que se realiza). El desarrollo web, ya no es lo que era. Añadir, que desde hace un mes y pico, tomadas las últimas decisiones técnicas, el desarrollo está siendo mucho más rápido. Así que kune cambia mucho cada día de trabajo lo cual se agradece. Gracias en especial a Dani Gómez por estar ahí estos días. Para feedback, mejoras, opiniones, creo que es mejor escribir a: kune-devel(a)lists.ourproject.org Un abrazo, Vicente PD: Es el primer vídeo que edito, así que perdonar por la calidad.

2 1

"Comiteando"
by Vicente J. Ruiz Jurado 20 Dec '07

20 Dec '07

Muy buenas: Bueno, esta semana se ha jodido un disco de los antiguos de ourproject y no he sacado mucho tiempo, vaya mierda... pero bueno, está todavía en garantía así que por ese lado bien (cinco añitos de garantía son cinco añitos). Pero bueno, acabo de subir varias cositas. El tema de la traducción está cada vez más maduro. Ahora he metido que reconozca el lenguaje del navegador o el del usuario si está autenticado y te saque ya el interfaz en ese idioma. También he dejado a Lutther Blisset tranquilo por el momento y ya los contenidos tienen una lista de autores, su lenguaje, etc. Todo un poquito verde (le falta en el UI sobre todo) pero para tirar. El liquibase va cañón... lo estoy usando en plan "rake migrate" de rails. Nos va a venir bien. Ver: src/main/resources/db/liquibase_changelog.xml para más datos. ChangeLog: 2007-12-20 Vicente J. Ruiz Jurado <vjrj(a)ourproject.org> * Added lang, authors, publishedDate to Container * More i18n small fixes * src/main/resources/db/liquibase_changelog.xml: Added liquibase custom rollbacks to i18n inserts * Added lang to content and container * Added browser lang recognition and UI init language takes account of this and also the user lang if is logged (...) Abrazos, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "Obrar es fácil, pensar es difícil; pero obrar según se piensa, es aún más difícil." [Johann Wolfgang von Goethe]

1 0

Liquibase ...
by Vicente J. Ruiz Jurado 14 Dec '07

14 Dec '07

2007-12-13 Vicente J. Ruiz Jurado <vjrj(a)ourproject.org> * cleanup of files in repo * first liquibase integration via maven (see INSTALL) * i18n fixes * i18n initialization of data (languages, translations and countries) via liquibase 2007-12-12 Daniel Gómez Blasco <danigb(a)gmail.com> * utf8 problems with JSON fixed del INSTALL (....) - Run jetty: mvn jetty:run -Ddatabase.migrator.should.run=false # without liquibase db migraton once started (and initialized the db), you can stop a run jetty with de db migrator to insert initial data: mvn jetty:run (...) No se que te parece Dani. Se podría hacer todo (creación de la db) por liquibase... de todas formas, es un comienzo, lo iremos ajustando. Abrazos, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org “Tres clases hay de ignorancia: no saber lo que se debiera saberse, saber mal lo que se sabe, y saber lo que no debiera saberse” [Duque de la Rochefoucauld]

1 0

Sobre el Login
by Vicente J. Ruiz Jurado 13 Dec '07

13 Dec '07

Dani: (el resto se puede aburrir con lo que sigue) Hay un tema que no se como solucionar tal y como tenemos montado el tema en el servidor. Cuando el usuario hace login tenemos que generar otro sessionid. En teoría, siguiendo el SecurityFaq de GWT y otras lecturas [1][2], habría que hacer más o menos esto: request.getSession().invalidate(); request.getSession(true); El problema es que ahora solo se accede a UserSession y a HttpServletRequest en KuneApplicationListener, que se ejecuta solo cuando el cliente accede por primera vez. Vamos que no veo como acceder al request desde UserRPC o UserManager en el login para generar un nuevo sessionId. antes sí se podía acceder a las peticiones desde un servlet, tipo: this.getThreadLocalRequest().getSession().getId() Dani ¿me hechas un cable si tienes un hueco? No se, sigo pensando que esto va a ser un tema para ir pasando el rato mientras se crea un proyecto serio que haga una librería de seguridad para gwt (algo que mucha gente que usa gwt va a necesitar, usar y mantener). En fin, este es el coste de ir de modernitos ;) Abrazotes, Vicente [1] http://en.wikipedia.org/wiki/Session_fixation [2] http://www.owasp.org/index.php/Session_Fixation_in_Java

2 2

Más cositas
by Vicente J. Ruiz Jurado 12 Dec '07

12 Dec '07

Muy buenas: He subido más cositas de estos días: Changelog (...) 2007-12-11 Vicente J. Ruiz Jurado <vjrj(a)ourproject.org> * i18n languages sincronization with default * i18n fixes and refactoring * Unjoin SN fix * Add member confirmation * Search panel connected to json * Partial solving of login issues following GWT recomendations * new LanguageSelectorComponent Ya se salen las búsquedas y el interfaz de traducción ya se puede usar (ambos usando el JSON). Os paso una captura. Todo mejorable, pero bueno, tiene buena pinta. El ext-gwt se está portando bastante bien (nada que ver con el comienzo que era muy buggy). El tema del login todavía está un pelín verde, estoy siguiendo: http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ pero ahora mismo el login no está pasando bien el userhash (antes se pasaba siempre, estuvieras o no autenticado) pero bueno espero enderezarlo... Así que estoy probando recargando de vez en cuando la página... ahora me pongo con ello. El Json tiene problemillas con el UTF8 (bien localizados), y el traductor todavía no se puede usar más que para pruebas. Pero bueno... Todo en el svn. Besotes, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "For the more there are who say 'Ours,'-not 'Mine'- by that much is each richer ." [Dante on the joys of sharing (Purgatorio, XV)]

2 3

[OT] Aplicaciones portables...
by Vicente J. Ruiz Jurado 09 Dec '07

09 Dec '07

Muy buenas: Hace unos meses estuve mirando si había alguna distro live orientada a eclipse (no la encontré). Ahora he encontrado otra cosa: http://portableapps.com/ http://portableapps.com/node/929 Para quien no lo conozca, son instalaciones de aplicaciones de SL populares que corren en tu llave USB. Así, si te mueves mucho de ordenador a ordenador (por ejemplo si no tienes ordenador en casa o estás de viaje, o en casa de tu papis, de tu pareja je je), no necesitas instalar nada. Yo ahora mismo no tengo necesidad (no voy a sitios con Windows en los que necesite currar), pero mola... irse a un Ciber y arrancar tu eclipse (o tu Thunderbird, Firefox, gaim, etc)... Todo un regalito... Abrazotes, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "A la naturaleza se la domina obedeciéndola" [Francis Bacon]

1 0

Json y i18n
by Vicente J. Ruiz Jurado 07 Dec '07

07 Dec '07

Buenas... He modificado mínimamente lo de Json de Dani (he añadido la clase SearchResult y SearchResultDTO), he retocado las búsquedas del lucene y ya saca totales y no duplica resultados, a la primera: http://localhost:8080/kune/json/GroupJSONService/search?query=site saca: {"size":2,"list":[{"shortName":"site","longName":"Site Administration","link":"","iconUrl":""},{"shortName":"admin","longName":"Site Administrator","link":"","iconUrl":""}]} Dani, de puta madre... Ahora voy a mostrarlo bonito (que se puedan seleccionar usuarios/grupos fácilmente, resultados de búsquedas, etc). Lo acabo de subir todo junto con la primera entrega del i18n. Besotes, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "No camines detrás de mí, puedo no guiarte. No andes delante de mi, puedo no seguirte. Simplemente camina a mi lado y sé mi amigo." [Albert Camus]

1 0

Como vamos, i18n, parte pública y continuando...
by Vicente J. Ruiz Jurado 07 Dec '07

07 Dec '07

Muy buenas: Estoy a punto de terminar con el tema de i18n (por lo menos la parte inicial). Al final he usado una solución totalmente mixta (en el cliente). Se puede usar lo de GWT (?locale=pt_BR) pero en realidad nosotros usamos un HashMap generado en el servidor. Vamos, que si en el futuro integramos una parte de GWT que usar la parte de internacionalización de GWT, se integraría bien. No uso el diccionario en js, porque es una solución mucho más limitada, aunque el resultado es el mismo, un HashMap de textoAtraducir/traducción. Es una primera adaptación del Globalize de Rails para nuestro entorno. Cuando esté 100% en funcionamiento con el interfaz de traducción, se entenderá mejor que ahora. También he estado intentando ajustarme en lo posible a las recomendaciones de i18n de java generales. Pero bueno, es solo el comienzo (no he tenido en cuenta temas que todavía no veo necesarios como monedas, cifras, etc). Ahora me meteré con todo el tema de JSON que Dani ha comenzado. Por lo que he hablado con él, va a ser coser y cantar usarlo. Y así poner ya en funcionamiento las búsquedas. Espero. Por otro lado, una vez que se complete esto, y haga un poco de orden y limpieza (reorganización de nuestro UI de GWT), creo que lo siguiente va a ser la parte pública (la no -tan- dinámica). Tenemos varias opciones: - Usar técnicas web java clásicas para generar el contenido público y también para dar el aspecto personalizado a los grupos/proyectos (jsp + sitemesh por ejemplo). - Usar otras tecnologías más modernillas tipo rails usando nuestros contenidos de la bd para visualizarlos (porqué no). - Usar java clásico en el servidor pero dar estilo con gwt (y que es lo que más me atrae a priori): http://kune.ourproject.org/spip.php?article10 Esta pequeña última parte de gwt podría estar bien para Alberto ya que es algo suave para introducirse en el tema. Es solo una idea. Creo que una vez que tengamos la parte pública (o una primera aproximación), y limados otros temas (como el chat), podríamos pensar en dar por finalizada la primera etapa, poner online lo que tenemos y hacer una llamada a la colaboración, a recibir feedback, etc. Salir del huevo. ¿Opiniones? Abrazotes, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "Fuimos a una guerra por unas armas que no existían. Fue todo una mentira, y 85 soldados británicos yacen bajo tierra por su culpa. Voy a por usted, señor Blair, aunque de forma civilizada" [Reg Keys, padre de un policía militar inglés muerto en Irak]

1 0

Sobre json...
by Vicente J. Ruiz Jurado 04 Dec '07

04 Dec '07

Muy buenas: Resumen para todos los públicos (para que vaya sonando): gwt-ext, la librería de Widgets que estamos usando junto con gwt, funciona con json y con rpc (pero esto último lo han hecho últimamente de pago... que putada mientras el resto es SL), así que Dani se ha currado una forma de acceder a backend con JSON para extraer los datos y usarlos para multitud de cosas (desplegables, live searchs, resultados de las búsquedas con paginado), lo cual va a darle más vidilla al UI (se podrá terminar la red social añadiendo grupos a mano, las búsquedas que ahora solo están a nivel de servidor, etc). Ejemplo del live-search de gwt-ext: http://gwt-ext.googlecode.com/svn/trunk/site/samples/Showcase/www/com.gwtex… Comentarios para danigb: He estado haciendo el update (solo entraba en conflicto el pom.xml y es lo único que he subido por ahora actualízate) y viendo un poco lo que has hecho. He empezado a meter un "live search" de grupos y he actualizado el ext a la última (0.9.3). Algunos comentarios: El arranque del jetty muy muy organizadito ;) Creo que lo de que salgan más resultados de la cuenta y repetidos puede ser cuestión del indexado del lucene (que no se hace bien) así que ya lo miraré, no te preocupes. Por el momento le he calzado un reindex de usuarios/grupos con la creación de la bd (que antes no se hacía) que me parece necesario (mirando así a pelo los índices veo datos antiguos). Pero bueno, flipo con la cantidad de clases que has metido y el nivel de abstracción que tienes... ;) Al grano. Viendo el ejemplo de json de gwtext, veo que envía el total, y algún campo más (un id): http://extjs.com/forum/topics-remote.php ¿sería sencillo meterlo? Así, a primera vista, parece que le pasas los resultados de la búsqueda y los mapeas. Si los resultados son un total, y una lista, ¿los mapeará igual? ¿o tengo que definir el mapeo en algún sitio? Ya he visto que el paginado funciona: http://localhost:8080/kune/json/GroupJSONService/search?query=site&fisrt=2&… ;) y bueno, de alguna forma tengo que sacar del lucene el total de resultados cuando se pagina (así mirando no lo veo como sacarlo sin hacer dos puñeteras búsquedas). ah tontería: donde dice "fisrt" debe decir "first" ... En fin, creo que por hoy va a ser suficiente. Besotes, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org “No albergaba ninguna duda de que, con tiempo, los humanos podríamos crear una sociedad moral. El problema era, y yo lo sabía demasiado bien, que el tiempo se estaba acabando.” [Jane Goodall]

2 1

Posibles soluciones para el tema de la internacionalización de kune
by Vicente J. Ruiz Jurado 10 Nov '07

10 Nov '07

Muy buenas: Escribo a la lista para darle un poco de vidilla y porque con las conversaciones 1-1, al final, no es tan enriquecedor. Un resumen de lo que he estado mirando. Se me ocurren tres opciones (aunque también se puede elegir una combinación de estas): 1) User constantes y mensajes (opción estándar de GWT) http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.Develope… - Genera por cada locale código html en tiempo de compilación - Si se cambia el locale desde el GUI, hay que hacer toda un "refresh" completo en el cliente (carga diferentes .html/.xml) - En principio, si se cambia un .properties de un locale (solo), la compilación no se entera y no actualiza (por lo menos con gwt 1.4.60), pero estaría bien que solo compilara los ficheros que precisa. En definitiva requiere una compilación completa para cualquier modificación en las traducciones. - Usas métodos tipo miClase.AreYouSure(); Ventajas: se optimiza en tiempo de compilación para descartar cadenas no usadas en el código, detectar errores, etc. 2) Diccionario (segunda propuesta de GWT) http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.Develope… - Generar un .js por cada locale (también se podría generar un solo js, con todos los diccionarios, pero cargarías todos los idiomas para cada cliente lo cual no tiene mucho sentido). - Todo en tiempo de ejecución - Propenso a fallos si falta alguna clave - Se manda todo incluso si no se usa - Adecuado para aplicaciones ya internacionalizadas - Al final, es similar a tener un hashMap, aunque más limitado. De hecho cuando cargas un diccionario, obtienes una especie de hashMap. 3) Generar servicio RPC para i18n propio (opción propia "casera", aunque ya hay gente opta por esta opción según leí en algún hilo). Si no nos gusta la opción 1) por los rollos de compilación y ya que la opción 2) en la práctica es bastante floja, creo que es más interesante generar una funcionalidad propia que básicamente recuperar del servidor un hashMap con todas las cadenas necesarias para un locale determinado. Tendríamos una llamada RPC inicial tipo: map = servicioI18n.getLocale("es"); y luego podríamos tener llamadas del tipo (a lo Globalize): t("Are you sure?") que buscaría esa cadena en el HashMap. También podríamos generar métodos tipo: public String AreYouSure() { return map.get("Are you sure?"); } si nos parece más elegante, pero no se si vale la pena. Siempre me ha gustado lo fácil que se internacionaliza con Globalize en rails. El hashMap lo podemos generar a partir de los datos de una tabla de bd. Si en un idioma determinado, no está traducido, se envía el del idioma por defecto. También se podría recuperar diferentes hashMaps por, por ejemplo, módulo, para no tenerlo todo en el servidor junto: chatMap = servicioI18n.getLocale("es", "ChatModule"); Inconvenientes de la opción 3): menos óptimo que la opción 1), un poco más de curro que la 1) ya que hay que generar ciertas clases y cierto modelo (aunque se puede fusilar de Globalize). Ventajas: más dinámico que la opción 1) ya que no requiere de compilaciones (con actualizar la fuente de datos basta), funcionalidad y prestaciones similares al diccionario 2), pero con la ventaja que podemos extender la clase para dar más funcionalidad sin estar atados al parseo de un simple fichero javascript. La misma funcionalidad se puede usar a nivel de servidor para los mensajes que se tendrán que generar para el cliente más allá de gwt (notificaciones por correo, parte pública estática, etc). Internacionalizar nuestro código actual sería sencillo (añadir el método Trans.t("Cadena") a las "Cadena" ya existentes). Más cómodo a la hora de programar (los .properties, es un coñazo). Entonces yo me decantaría por seguir con 1) en el cliente (aunque en el servidor se necesitaría algo adicional) o pasar directamente a usar la 2) que es la que me parece da más juego tanto en el cliente como en el servidor. ¿Se me escapa algo? Dani, ¿qué te parece? Seguro que sacas a relucir cosas que yo no veo. Abrazotes, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "Lo que ha sido creído por todos siempre y en todas partes tiene todas las probabilidades de ser falso." [Paul Valéry]

1 0