BCN JUG } Workgroups - Social | 1era sesión

[Loïc Prieto]

Buenos días a todos!

El pasado martes 11 de marzo nos reunimos para la primera sesión del grupo de trabajo de Social. El objetivo de la reunión era establecer las pautas, tecnologías y arquitectura que seguiríamos para implementar el proyecto de publicación de eventos de BCN Jug en las distintas plataformas sociales.

El flujo de funcionamiento de la aplicación es:
Acceder a la página de publicación, elegir a qué plataformas propagamos el evento y lanzar. Con los datos proporcionados desde el cliente, se van activando los distintos módulos de publicación que tengamos en el backend.

Desde el punto de vista de arquitectura, tendremos un cliente sencillo, implementado como aplicación web en AngularJS. Este cliente accederá a los servicios de un Backend Java alojado en OpenShift. El backend expondrá sus servicios a través de una interfaz REST. La tecnología elegida para implementar el backend es Spring, con Spring MVC para REST (aunque todavía queda por debatir si usaremos Spring MVC o alguna otra tecnología de REST para Java) y Spring Social para las interacciones de nuestro cliente con las distintas redes sociales en las que vamos a publicar: Facebook, Google+, Twitter y Meetup a priori.

Desde el punto de vista de infraestructura, usaremos un alojamiento en OpenShift, a medio plazo integrado con Jenkins,que recogerá el código de una cuenta de grupo en Github. El sistema de construcción elegido es Gradle. Organizaremos las tareas siguiendo un modelo Kanban, con la herramienta Trello. Compartiremos documentos con las herramientas de Google Drive. La documentación pensamos hacerla con ASCII Doctor. Usaremos este foro para comunicarnos también, además de reuniones periodicas en las que pongamos a punto los temas que tengamos que tratar o para coordinarnos en persona (además de para tomar alguna cosa juntos, claro ;) )

Saldremos con un MVP que permitirá publicar los eventos y nada más. Persistencia, autenticación y funciones más avanzadas se dejarán para iteraciones posteriores.

Iremos creando tareas relativamente independientes para que los que quieren participar puedan coger unidades pequeñas de trabajo.

Por lo demás, creo que no me dejo nada. Si es el caso, no dudéis en preguntar.

Un saludo!

[Nacho Cougil Jares]

Well done Loïc!

¿Qué te parecería ponerle un poco de forma y publicarlo en nuestra página, LinkedIn y G+ por ejemplo? ;-) 

Btw, ya he creado el board (easy mode) para que podamos empezar a trabajar en ello. Read only for everybody (cuando me paséis los mails, os concedo acceso de edición).

https://trello.com/b/GWnRMBcK

Salu2 y thx por el resumen!!!

--
Has recibido este mensaje porque estás suscrito al grupo "Barcelona JUG" de Grupos de Google.
Para anular tu suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje a barcelona-ju...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Esteve Camps Chust]

Guai, joined to Trello

--
Esteve Camps Chust

[Alex Soto]

Hola solo una cosa si usáis AsciiDoc no es necesario poner la documentación dentro de google drive, la podés poner directamente en el proyecto, ya sea en src/main/documentation, en src/main/resources o bien en un modulo aparte. Lo digo porqué se puede mantener todo el proyecto junto en github sin tener que hacer ningún switch de contexto. También comentar que si lo hacéis así la gente podrá hacer un clone del proyecto, modificar la documentación y hacer un pull request donde sólo habrán cambios de documentación, de esta forma será más fácil tracearla y ver en cada momento que modificaciones han habido, que se ha añadido, que se ha quitado, ...

También os será más fácil generar la documentación ya que hay el plugin de Gradle para AsciiDoctor y durante el build podréis renderizar la documentación sin tener que depender de otro paso externo.

Sobre test os recomiendo Arquillian ya que tiene el proveedor para poder ejecutar los tests directamente en openshift (Arquillian se va a encargar de hacer el push del código a ejecutar el test automáticamente), de esta forma podréis ejecutar los tests tanto en local como en "producción" sólo cambiando una variable de entorno.

Y sobre el servidor yo siento un amor especial por Apache TomEE, no es necesario usar JBoss en openshift ya que también hay el cartridge de TomEE. 

Sólo una última cosa, yo he trabajado con Jenkis y Travis. La verdad que Travis me gusta mucho más que Jenkins por el hecho de poder definir todo el build en el propio proyecto, sin tener que depender de una configuración externa, pero evidentemente al final es como os sentis más a gusto.

Esto es todo (de momento) :P

Alex.

El dijous 13 de març de 2014 22:22:16 UTC+1, Loïc Prieto va escriure:

[Loïc Prieto]

Muchas gracias por los aportes, Alex! Se nota la experiencia ahí, eh?

Sobre TomcatEE lo estuve pensando yo también, ya que, en el fondo,  con ĺos componentes que vamos a usar, realmente no necesitamos ninguno de los servicios que ofrece un contenedor JEE "pesado", sólo el apartado web, que ya proporciona muy bien Tomcat. Por mí, podemos cambiar el contenedor. ¿Qué pensáis los demás al respecto?

Escogimos Jenkins porque había oído que se integraba bien con OpenShift y por medio conocerlo de usarlo (conocimiento nivel usuario, que diríamos, je je), pero si pensáis que Trevis también podría estar bien, podemos cambiarlo. Es cierto que el hecho de tener configurada la integración continua desde el propio proyecto es bastante tentador.

[Esteve Camps Chust]

En cuanto a cambiar a TomEE, me parece correcto; de momento, no necesitamos más. En cuanto a la CI, yo tiraria por lo fácil: la CI lleva a poner unit tests, cobertura, checkstyle y tantos otros plugins más que pueden hacer crecer el tema.

--
Esteve Camps Chust

[Alex Soto]

Bueno TomEE es mucho más que lo que se comenta, por ejemplo el WebProfile tiene EJB, CDI, JPA, JAAS, ... no es para nada un Tomcat. Y por ejemplo una Full Profile es super lijero y tiene todas las características de cualquier servidor de aplicaciones http://tomee.apache.org/comparison.html. No se trata tanto de si se necesita más o no, sinó la facilidad de uso, la velocidad, el espacio, ... por ejemplo para pasar toda la suite TCK en TomEE solo se necesitan 64MB de heap, preguntaros cuando necesitaríais para Websphere o Weblogic.

Sobre el tema del CI no entiendo mucho el problema, quiero decir que los plugins que se comentan para CI ya estan integrados dentro de Gradle, la gracia tiene que ser que un desarrollador pueda ejecutar en su ordenador lo mismo que en el servidor CI, así por ejemplo si todo el pipeline se define en Jenkins, con los plugins necesarios, ... estamos alejandonos del ideal. Creo que si se quiere usar Gradle (y estoy de acuerdo), si el sistema tiene que crecer debe de crecer entorno a Gradle y no entorno a un servicio de integración contínua.

Creo también interesante de porqué tenemos que hacer integración contínua, no sería mejor hacer continuous delivery? Mucho mejor y no tenemos todos los recursos para hacerlo.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "Barcelona JUG" de Grupos de Google.
Para anular tu suscripción a este tema, visita https://groups.google.com/d/topic/barcelona-jug/lv6WgQo7WQs/unsubscribe.
Para anular tu suscripción a este grupo y a todos sus temas, envía un mensaje a barcelona-ju...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
+----------------------------------------------------------+
  Alex Soto Bueno - Computer Engineer
  www.lordofthejars.com
+----------------------------------------------------------+

[Loïc Prieto]

La verdad es que el tema de CI me pilla muy verde. ¿Tal vez se podría aprovechar para hacer una sesión explicativa? Si te animas, para la próxima reunión tal vez nos podrías explicar tu experiencia con estas herramientas, cómo las has usado y cómo podemos aprovecharlas aquí. De la integración con herramientas como Gradle o con OpenShift, o lo que consideres que sea interesante. ¿Te animarías?

[Alex Soto]

Si claro ningún problema a ver si puedo ir, ya iré manteniendome informado, de hecho (y que conste que yo no lo haría) han liberado en licencia APL2, Go que es un CI server muy muy interesante.

[Adela Tort]

Hola!!

De poner TomEE no lo había pensado, podemos probarlo, no lo veo mala idea, incluso quizás el OpenShift vaya más ligero que con el JBoss, pero ni idea, tengo que reconocer que nunca he probado TomEE.

Referente al tema de CI, dijimos Jenkins pensando en poner el cartridge que hay en OpenShift. La idea sí que es configurarlo todo en Gradle, igual que en Maven. Ahora solo nos falta aprender Gradle, estoy en ello ;)

De Continuos Delivery no había pensado, pero muy buena idea, seria un buen momento para probarlo! Alguien para dar una mano y ayudar a montarlo? :-) Con una tarea mismo en el jenkins o es un poco a saco?

Saludos!

Adela

[Max Pimm]

Hola,

 

Y sobre el servidor yo siento un amor especial por Apache TomEE

I'd be interested to hear why you would prefer this to, say, Wildfly?

Max

[Alex Soto]

Yo os puedo ayudar en lo referente a Continuous Delivery (solo un apunte que siempre confunde a la gente Continuous Delivery != Continuous Deployment)

About why Apache TomEE instead of JBoss, well there are several reasons and some of them are personal :) For example I have cospoken with David (its leader) in one conference or I have collaborated with Tomitribe or I have talked with him about technology too, so there is a personal relationship with David that makes me think of TomEE. But of course this is a reason  but there are some non personal reasons. For example the webprofile is light it is only 28Mb and uses only 64Mb of heap, the rest of them is for your application which is amazing. Also it takes 1 second to startup (in this case very similar to Wildfly) and of course it is open source and based on Tomcat which means you don't need to learn nothing new (no modules, no different configuration, no new plugins), you only package the war (with the ejb, jsp, servlets, pojo, ...) you drop them on webapp and that's all. But more important the same plugins of Tomcat (maven, gradle, Eclipse, Intellij, ...) works perfectly with TomEE, so of course Wildfly is great (in fact I know a lot of people from Red Hat) I have nothing against it, I think that for example that  in clustering environments JBoss works really well and it is so easy to scale. But IMO almost 80% of projects where we work, an Apache TomEE is enough and this application it seems a case. 

--

Has recibido este mensaje porque estás suscrito a un tema del grupo "Barcelona JUG" de Grupos de Google.
Para anular tu suscripción a este tema, visita https://groups.google.com/d/topic/barcelona-jug/lv6WgQo7WQs/unsubscribe.
Para anular tu suscripción a este grupo y a todos sus temas, envía un mensaje a barcelona-ju...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Alex Soto]

BTW http://zeroturnaround.com/rebellabs/abandon-fish-migrating-from-glassfish-to-jboss-or-tomee/

[Alex Soto]

Si necesitas ayuda en Gradle me lo comentas, no soy un experto pero si que he tocado algunas cosas, y tengo algunos screencast muy interesantes.

Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/barcelona-jug/lv6WgQo7WQs/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un mensaje de correo a barcelona-ju...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Max Pimm]

Hi Alex,

On Tue, Mar 18, 2014 at 9:03 AM, Alex Soto <aso...@gmail.com> wrote:

About why Apache TomEE instead of JBoss, well there are several reasons and some of them are personal :) For example I have cospoken with David (its leader) in one conference or I have collaborated with Tomitribe or I have talked with him about technology too, so there is a personal relationship with David that makes me think of TomEE. But of course this is a reason  but there are some non personal reasons. For example the webprofile is light it is only 28Mb and uses only 64Mb of heap, the rest of them is for your application which is amazing. Also it takes 1 second to startup (in this case very similar to Wildfly) and of course it is open source and based on Tomcat which means you don't need to learn nothing new (no modules, no different configuration, no new plugins), you only package the war (with the ejb, jsp, servlets, pojo, ...) you drop them on webapp and that's all. But more important the same plugins of Tomcat (maven, gradle, Eclipse, Intellij, ...) works perfectly with TomEE, so of course Wildfly is great (in fact I know a lot of people from Red Hat) I have nothing against it, I think that for example that  in clustering environments JBoss works really well and it is so easy to scale. But IMO almost 80% of projects where we work, an Apache TomEE is enough and this application it seems a case. 

Thanks for the comprehensive answer :)