Arquitectura.ppt (los8delj@googlegroups.com)

[David Màlaga (Google Drive)]

I've shared an item with you.

Hola apañeros.

Echadle un ojo a esto cuando podais.

Salut!

Arquitectura.ppt

Google Drive: create, share, and keep all your stuff in one place.

[Victor Santiago]

Mis conocimientos no dan para romper ni mejorar nada, pero si para ver un buen curro.

un abrazo!

2013/2/19 David Màlaga (Google Drive) <dmmez...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "los8delJ" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a los8delj+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Victor Santiago
Barcelona

[Roger Muntasell Castellví]

Hola a todos,

 

David no puedo ver la transpa número 6 que immagino es arquitectura struts. Como tampoco puedo modificar la pps, voy a largar lo que pienso:

Para mi la arquitectura ha usar es struts (en su versión 2), que además es facilmente vinculable a spring, soporta json a través de pluguins, la vista claro está htm5, css3 y si hay dinamismo se puede usar taglibs para jquery...etc

 

La base de datos sin duda me  quedo con MySql por renidmiento y pq tiene un workbench que permite realizar modelos ER de forma facil.... eso que no solemos hacer en Atm... y por último pq es la que conozco a nivel de desarrollo  jijiji.

 

En cuanto a Pools no tengo preferencias...

 

Good night;

 

Good Job

 

2013/2/19 Victor Santiago <victo...@gmail.com>

[Daniel Luque]

Como aporte, comentar que creo que las plataformas de servicios web accesibles desde dispositivos móviles y web parecen tender a RESTFul. Tengo pocas nociones sobre el tema pero por lo que vimos en una demo a la que asistimos la implementación es muy sencilla y ofrece múltiples formatos de comunicación (JSON, XML,...)...

sin saberlo seguro supongo que Ojective C y las diferentes plataformas moviles contemplan apis restful. La demo que nos hicieron fue con NetBeans y la creación de servicios resful usando annotations era casi inmediata (hay varios artículos al respecto http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/RESTfulWebServices/RESTfulWebservices.htm) y supongo que no será difícil encontrar plugins para otras plataformas.

pos eso,

Dani.

Dani Luque

[David Màlaga]

REST(ful) es una forma enfocar las aplicaciones a recursos en lugar de a operaciones, y presupone que los navegadores/clientes son capaces de ejecutar todos los verbos HTTP (GET, POST, PUT, DELETE...), que a la práctica es mentira y hay que simularlo todo con GET y POST.

A mi modo de ver es una "definición" un poco amplia.

Básicamente todo funciona con librerías que simulan las operaciones.

2013/2/20 Daniel Luque <daniel...@gmail.com>

--

Salut!

 "Si todo está bajo control, es que no vas suficientemente rápido". Mario Andretti.

[Daniel Marquez Medina]

IMHO y desde el (des)conocimiento que me invade :)

yo Hibernate no pondría, lo veo demasiado para lo que se necesita. Spring estaríamos en el mismo planteamiento, pero para mi aporta más que resta, de hecho ahora le han puesto Spring Data que soporta incluso NoSql, el desconocimiento tampoco sería un problema, somos chicos apañaos.

el debate si app o html, yo me decantaría por html, ya que habría que hacer solo un plataforma, siempre (entiendo) se puede hacer una app en cada plataforma y que esta llame al navegador o algo así (desconocimiento 100%)

y como no REST, full, a medias o como sea, orientados al servicio, que sea muy facil crecer en horizontal.

Ember como standar de facto!!! 

el resto todo OK.

Gran trabajo!!!

Daniel Márquez

http://twitter.com/enchequito

http://www.linkedin.com/pub/daniel-m%C3%A1rquez-medina/21/b13/999

[David Màlaga]

Puedo estar de acuerdo con lo que Dani dice de Hibernate (a pesar de que soy un fan declarado).

El motivo de incluirlo en el stack era por el siguiente razonamiento: como que no vamos a comprar máquinas ni IPs ni nada de todo esto, vamos que iremos a "la nube". Usar Hibernate nos independiza de la base de datos que utilicemos (estamos de acuerdo que preferimos MySQL, pero es posible que el proveedor nos ponga alguna restricción).

Luego podríamos entrar en otros aspectos a valorar, pero esto son temas más de gusto personal.

2013/2/20 Daniel Marquez Medina <enche...@gmail.com>