HuetzinCL

El siguiente texto es una traducción del blog propiedad de: NERMIN HAJDARBEGOVIC del portal toptal ---------------------------------------------------------------------------------------------------------------------------- Sin muchas fanfarrias, Google introdujo una nueva versión de “Control platform”, hospedado en su gran nube. Si te suena familiar, quizá creas que se trata de “ Google Code”, que ya esta difunto. La gran diferencia es que la nueva “Cloud Source Repositories” de Google es una plataforma Git, lo que significa que es mucho mas flexible (y utilizabel) que Google Code. Google Code fue lanzado en 2006, un par de años antes GitHub y Bitbucket aparecieron en escena, superando rápidamente a Google Code en popularidad. Finalmente Google descarto el plug en Marzo de 2015, citando falta de interés. Mientras esto era el fin del camino para Google Code, el cual cayó de gracia años antes de ser declarado oficialmente muerto, Google no esta abandonando a la comunidad de desarrolladores. De hecho los repositorios ‘ Google Cloud Source’ parecen bastante prometedores, incluso en esta etapa inicial. Personalmente, no espero a mucha gente abandonando GitHub y cambiándose a Google próximamente, pero la compañía tiene una manera de atraer usuarios a sus servicios, incluso aquellos que no parecen tentadores en su lanzamiento. Google simplemente sigue empujando, puliendo, innovando y ofreciendo incentivos a los nuevos usuarios. Usualmente esto funciona, aunque estoy seguro que a muchos de ustedes se les viene a la mente ‘ Google Plus’ o un par más en este momento. Sin embargo también estoy seguro que Google es muy serio para este proyecto. Google está tomando GitHub y Bitbucket con repositorios ‘Cloud Source’. Google tiene la fuerza para hacer que esto pase Ya he mencionado 2 proyectos no tan satisfactorios de Google : Google Plus y Google Code, entonces podrías imaginar porque ninguno debería tener éxitos sobre el nuevo repositorio en la nube, el cual aún esta en versión beta. Bueno, para principiantes, Google tiene una buena experiencia mejorando betas dentro de la usabilidad, popular y servicios muy dependientes. Gracias a sus bastos recursos humanos y financieros, Google no debería tener problemas para convertir los repositorios Cloud Source en algo mas serio en un futuro, siempre y cuando haya interés suficiente. Otra ventaja es la infraestrutura en la nube de Google . Es insuperable; la compañía tiene una reputación en la estabilidad a prueba de balas, y gracias a las economías de escala, este puede usualmente ofrecer más o menos (comparado a pequeños competidores). Otra cosa para mantener en mente es que el nuevo servicio ‘Cloud Source Repositories’ no es exactamente un reemplazante para ‘ Google Code’. Si bien ambos servicios atienden a los desarrolladores, Google Code fue diseñada para projectos colaborativos open-source, y en el top de código también permitido el hosting de otros tipos de contenido, como documentación, wikis y mucho más. Sin embargo los repositorios ‘Cloud Source’ es mas o menos un servicio tradicional Git. No hay campanas ni silbatos, aunque hay unas cuantas características que deberían ayudar a una rápida adopción. Cloud Source Repositories vs. GitHub vs. Bitbucket La nueva plataforma de código en la nube de google no parece ser tomado en GitHub de frente. En su lugar, ‘Cloud Source Repositories’ (CSR) permitirán usuarios conectarse a repositorios hosteados en GitHub o Bitbucket. Sin embargo, todo esta automáticamente sincronizado al repositorio Google Cloud Source. Cada proyecto en la plataforma de la nube tiene un repositorio Cloud Source, el cual puede ser accesado y usado por multiples usuarios. Los permisos son heredados de el proyecto Cloud, por lo que todo el usuario tiene que hacer es agregar miembros del proyecto y establecer sus permisos. La buena noticia es que Google CSR puede ser conectada a otro repositorio Git hosteado en GitHub o Bitbucket. Todos los cambios serán sincronizados en ambas plataformas, tal como puedes establecer Google CSR a un espejo automática de GitHub y Bitbuccket. Recordar cuando dije que Google tenía un habito de hacer que la gente use estos servicios sin conocimiento previo? Bueno, la integración con la plataforma Google Cloud y respaldos automatizados, soporte para 2 de los grandes repositorios Git externos, sin duda suena como un servicio que muchos usuarios encontrarán atractivo. Recordar que aún esta en versión beta, por lo que Google podría hacerlo aún más tentador introduciendo una mayor integración con otros servicios de Google . Los Repositorios Cloud Cource ya miran y sienten como una extensión natural del ecosistema Google , pero con un poco mas de integración podría ser aún mejor. Entonces, ¿cómo se compara con GitHub y Bitbucket? Bueno, esto aun es difícil de decir; esto aun es una beta y no valorizado información ha sido revelada. Aun así, vale la pena señalar que GitHub y Bitbucket están estrechamente parejos en términos de características, además tienen algunas pocas diferencias. Por ejemplo, usuarios avanzados pueden preferir uno u otro debido a diferentes modelos de facturación. A menudo se argumenta que GitHub es un poco mejor por características extras y proyectos open-source, principalmente porque se hospeda un mayor numero de proyectos open-source. Sin embargo, BitBucket puede ser una mejor opción para proyectos pequeños y freelance porque ofrece mas características gratis (por ejemplo, repositorios privados ilimitados con multiples colaboradores). Al final del día, es una cuestión de preferencia personal; ambos servicios son muy buenos. Pero, ¿qué acerca de los repositorios Cloud Source? Personalmente, pienso que aún es muy temprano para decirlo. GitHub Y BitBucket han estado presentes por años, mientras que Google CSR solo hay un beta apenas hace unas pocas semanas. La liberación beta es completamente gratis y tienes 500MB de almacenamiento para sus valiosos archivos fuente. Sin embargo, obviamente esto no pinta la foto completa. Todavía tenemos que ver lo que Google planea hacer a largo plazo.

Framework Web MVC Introducción al Framework Spring Web MVC El framework Spring Web modelo-vista-controlador (MVC) está diseñado alrededor de un DispatcherServlet que asigna peticiones a los manejadores, con handler mappings(bean especial de spring que mapea peticiones a manejadores)configurables, resolución de vistas, manejo de idioma, zona horaria y resolución de temas así apoyo para la carga de archivos. El manejador por default está basado en las anotaciones @Controller y @RequestMapping, ofreciendo una amplia gama de flexibles métodos handler. Con la introducción de Spring 3.0, el mecanismo @Controller también permite crear sitios y aplicaciones Web RESTful (REST es una técnica de arquitectura software), por medio de la anotación @PathVariable y otras características. “Abierto para extensión…” Un principio clave de diseño en Spring Web MVC y en Spring en general es el principio: “Abierto para extensión, cerrado para modificación”. Algunos métodos en las clases core de Spring Web MVC son marcadas como final. Como desarrollador no podrás sobrescribir esos métodos para suministrar comportamiento personalizado. Esto no se ha hecho de manera arbitraria, sino específicamente con este principio en mente. Para una explicación de este principio, referirse a Expert Spring Web MVC and Web Flow de Seth Ladd y otros; específicamente ver la sección “Una mirada al diseño” en la página 11 de la primera edición. Alternativamente, ver •Bob Martin, The Open-Closed Principle (PDF) No puedes agregar asesoramiento a métodos final cuando usas Spring MVC. Por ejemplo, no puedes agregar comportamiento a el método AbstractController.setSynchronizeOnSession(). Referir a la sección “Entendiendo proxies AOP” para más información sobre proxis AOP y porque no puedes agregar comportamiento a métodos final. 17.3 Implementando Controladores Los controladores proporcionan acceso al comportamiento de la aplicación que típicamente se define a través de una interfaz de servicio. Los controladores interpretan las entradas de los usuarios y transforman en un modelo que se representa al usuario por la vista. Spring implementa un controlador en una forma muy abstracta, la cual te permite crear una variedad muy grande de controladores. Spring 2.5 introdujo un modelo de programación basado en anotaciones para controladores MVC que usan anotaciones tales como @RequestMapping, @RequestParam, @ModelAttribute, y muchas más. Este soporte de anotaciones está disponible para Servlet MVC y Portlet MVC. Los controladores implementados con este estilo no tienen que extender ninguna clase ni implementar alguna interfaz especifica. Además, usualmente estos controladores no tienen dependencias directas hacia los APIs Servlet o Portlet, aunque usted puede fácilmente configurar acceso a las bondades de Servlet o Portlet. Nota: En spring-projects Org on Github están disponibles varias aplicaciones web que aprovechan el soporte de anotaciones que se describe en esta sección incluyendo MvcShowcase, MvcAjax, MvcBasic, PetClinic, PetCare, además de otras. Como se puede ver, las anotaciones @Controller y @RequestMapping permiten nombres de métodos y firmas flexibles. En este ejemplo en particular el método recibe un Model y regresa un nombre de vista en un String, pero se pueden utilizar varios tipos de parámetros y retorno como se explicara en una sección posterior. Las anotaciones @Controller y @RequestMapping entre otras forman la base de la implementación Spring MVC. Esta sección documenta estas anotaciones y como ellas son las más comúnmente utilizadas en un ambiente Servlet. 17.3.1 Definiendo un controlador con @Controller La anotación @Controller indica que una clase particular tiene el rol de controlador. Spring no requiere que extiendas ninguna clase base controlador o referencia al API Servlet. Sin embargo, si las necesitas puedes referir a las características específicas del Servlet. La anotación @Controller actúa como un estereotipo de la clase anotada, indicando su función. El dispatcher lee estas clases anotadas buscando métodos mapeados y detecta anotaciones @RequestMapping (ver la sección siguiente). Se puede definir explícitamente beans Controller anotados, usando la definición estándar de Spring bean en el contexto del dispatcher. Sin embargo, el estereotipo @Controller también permite la detección automática, alineado con el soporte general de spring para detectar clases component en el classpath y registrar automáticamente definiciones de sus beans internos. Para habilitar la detección automática de dichos controladores anotados, puedes agregar el elemento component-scan a tu configuración. Usa el esquema spring-context como se muestra en el siguiente extracto de XML: 17.3.2 Mapear Request con @RequestMapping Utiliza la anotación @RequestMapping para mapear URLs, por ejemplo: /appointments, sobre toda la clase o sobre un método handler especifico. Típicamente las anotaciones a nivel de clase mapean un path de request especifico (o un patrón de path) sobre un form controller, con anotaciones adicionales a nivel de método se reduce el mapeo principal para un tipo de método HTTP especifico (“GET”,”POST”, etc.) o un parámetro condicional de un request HTTP. El siguiente ejemplo del proyecto “Petcare” muestra un controlador en una aplicación Spring MVC que usa esta anotación: En el ejemplo, @RequestMapping es utilizado en varios lugares. La primera vez se utiliza a nivel clase, esto indica que en este controlador todos los métodos son relativos a el path /appointments. El método get() va mas allá: solamente acepta request GET, significa que en un GET HTTP con el path /appointments se invocara a este método. El método add() tiene una especialización similar, y el getNewForm() combina la definición de un método HTTP y el path, de tal forma que request GET para appointments/new son procesadas por este método. El método getForDay() muestra otra utilización de @RequestMapping: URI templates. (ver la sección siguiente). Un @RequestMapping a nivel de clase no es obligatorio. Sin él, todos los paths son simplemente absolutos, no relativos. El siguiente ejemplo del proyecto “PetClinic” muestra un controlador multi-acción utilizando @RequestMapping: El ejemplo anterior no especifica GET vs. PUT, POST, y así sucesivamente, porque @RequestMapping mapea todos los métodos HTTP por default. Utilizar @RequestMapping(method=GET) para filtrar mas el procesamiento de los request.