Your SlideShare is downloading. ×
  • Like
  • Save
Conociendo Nuestro Fua interno
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Conociendo Nuestro Fua interno

  • 54 views
Published

Levantamiento y consultoria interna de TI.

Levantamiento y consultoria interna de TI.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
54
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. { El estado del Arte }“conociendo nuestro FUA interior”.José Bovet Derpich08/08/2011
  • 2. Agenda Estado del arte De las buenas prácticas
  • 3. El estado del arte Que hay en el día a día. ¿qué, y con que lo hacemos? Tecnologías que usamos. IDES Servidores y contenedores webs No reinventamos la rueda Nuestra piedra angular Spring e IOC Nuestras Aplicaciones Componentes en FO - BO
  • 4. Nuestro día a día
  • 5. ¿qué hacemos? Programamos Pruebas Análisis de requerimientos Modelado Diseño Administración de Proyectos Gestión del cambio Comprar compulsivamente cupones, hacer free shipping endealxtream.com, entre otras.
  • 6. Y como… Ocupando herramientas adecuadas No reinventando la rueda Reutilizando Arquitecturas basadas encomponentes Implementando patrones de diseñoe integración. Testeando
  • 7. Tecnologías que usamos. Lenguajes
  • 8.  IDES
  • 9.  Servidores de aplicaciones y ContenedoresWeb
  • 10. S.O
  • 11.  No reinventamos la rueda.CXFJAX-WSORMWebServicesJavaScriptVistaTestTareas y BuildersUtilitarios, loggers, etcSCMSearchEngine
  • 12.  Nuestra piedra angular
  • 13. pero… ¿que es Spring? “Spring es una tecnología dedicada para permitirconstruir aplicaciones usando POJO’s…” RodJohnson Spring es un framework que resuelve muchoproblemas comunes en el desarrollo deaplicaciones en Java(SDK,EE)
  • 14. pero…¿porqué Spring? Porque reduce la complejidad de desarrollo JEE Simplificar sin sacrificar poder. Facilitar mejores practicas, que de otra manera sondifíciles seguir. No esta enfocado a una parte especifica de unaaplicación. Desarrollar aplicaciones usando POJO’s Impacto mínimo. Principio de la filosofía de Spring. Porque nace de la experiencia práctica de muchosdesarrolladores en todo el mundo
  • 15. El poder de POJO
  • 16.  Spring Framework y sus sabores Spring Security (exACEGI) Spring AOP Spring MVC Spring Web Flow Spring JDBC Spring Transaction Spring Scheduling Spring WebServices Spring Test
  • 17. Integramos Spring con… ORM: Hibernate, JPA, TopLink, JDO, OJB,Ibatis. DAO: Manejo de transacciones a través de AOP + IBATIS JEE: JMX, JMS, JCA, Remoting, EJBs, Email WEB: Spring WebMVC, Struts,Tapestry, JSF, JSP, RIA, Velocity, FreeMaker, ExtJs, Jasper Report, Portlet MVC AOP: AspectJ
  • 18. Donde lo usamos…
  • 19. En todos los escenarios…
  • 20. Con otros frameworks
  • 21. En remoting
  • 22. Nuestras Aplicaciones Front Oficce Back Office
  • 23. Tecnologías usadasNombre Versión usada Última versiónJava 1.5 – 1.6 7(Aún inestable)Tomcat 5.5 – 6.0 7.0.20Spring/MVC/WebFlow/Test2.0 – 2.5 3.0.5Spring Tool Suite 2.3 -2.5 2.7.1Spring Security 2.0.3 3.0.5IBATIS 2.3.4.7 Ya noexiste3.0.6MybatisAxis 1.4 1.5.5Velocity 1.6.4 - 1.5 1.7JUnit 4.4 4.9JQuery 1.4 – 1.5 1.6.2ExtJs 3.2.0 3.4 / 4.0 Alpha
  • 24. Alternativas Spring: Ibatis: Axis: Junit: TestNG Jtiger EasyMock Mockito STS: JQuery-Extjs: GWT - Prototype – Dojo -Script.aculo.usJDO JPA TopLink QuickDB DataNucleusCXFJAX-WS springwsREST
  • 25. Malas Prácticas
  • 26. “Todo en uno”No existen libreríasespecificasNo se tiene información delcomponente.¿Qué hace cada jar?
  • 27. “La redundancia, a veces, no esbuena…”Duplicidad en los componentesSaludosjava.lang.NoClassDefFoundErrorCual es la que vale?JUnit en el deploy?
  • 28. “El orden de midesorden…”Archivos de configuración portodos ladosNo existe agrupación porcomponente o funcionalidadMezclar peras con manzanas.!Solo necesito modificar unBean!
  • 29. “Abuso de las librerías.”Desconozco lo que ya estahecho.Un caos!
  • 30. “No tenemos un estándar”“Extiendo y también usoanotaciones para mistest”
  • 31. “No tenemos un estándar”“¿Se que clases necesito ocupar?”• Controller– AbstractController• MultiActionController• BaseCommandController– AbstractCommandController– AbstractFormController» SimpleFormController» AbstractWizardFormController– ThrowawayController– ParameterizableViewController
  • 32. De las buenas prácticas“Producer good software is hard”
  • 33. Automatizar pruebas Probar funcionalidades del software durante eldesarrollo. Detección de errores en etapas tempranas y no alfinal del desarrollo. Obtener métricas, informes y estadísticas. Imponen restricciones de diseño del software paraque sea comprobable. Evita el acoplamiento de diferentes componentes. Mediantes herramientas y técnicas como CI.
  • 34. Integración Continua“Practica de desarrollo software donde los miembros de unequipo integran su trabajo frecuentemente, por lo menosdiariamente y llegando a múltiples integraciones al día.Cada integración se comprueba por una construcciónautomatizada para detectar errores de integración lo antesposible. Muchos equipos encuentran esta aproximación comouna forma de reducir significativamente problemas deintegración y que permite desarrollar cohesivamente software deforma más rápida.”Martin Fowler”
  • 35. Enfoque de la CI Automatizar tareas de building Generar informes y métricas de tests Proveer información útil para realimentar el proceso dedesarrollo (feedback) Identificar problemas o errores en la integración del código Hacer el proceso de integración transparente al equipo dedesarrollo Establecer uniformidad en la programación del equipo Mantener actualizado y centralizado el código dedesarrollo
  • 36. Una mirada a CI
  • 37. Herramientas
  • 38. Control de versiones
  • 39. ventajas del control deversiones Proveer entornos distribuidos y/o centralizados a losdesarrolladores. Tener un control exacto sobre cual es la última versión delcódigo, y quién y cuando la ha cargado. Poder comparar versiones, viendo cuales han sido loscambios realizados. Regresar atrás (a una versión anterior) cuando lo quehemos desarrollado no nos ha dado los resultadosesperados. Crear distintas ramas del proyecto. Si llegado a un puntose hace necesario hacer dos aplicaciones con distintasfuncionalidades, pero con cosas en común, se puedenseparar en dos ramas.
  • 40. Herramientas ControlVersiones Centralizados Distribuidos
  • 41. Administración del Proyecto definir un ciclo de vida básico del proyecto sobreel que se pueden ir ejecutando ciertas tareasasociadas. Facilitar la gestión de las dependencias a partirde repositorios remotos de librerías, incluyendolas dependencias transitivas. Permite la generación de todo un site dedocumentación del proyecto (javadoc, informesde calidad, etc.) Realiza la generación y publicación de releases.
  • 42. Herramientas
  • 43. Pero aún faltan Issue tracker Virtualización Testing Tools
  • 44. Algunas mas… Reutilizar Automatizar la compilación eintegración Mantener un repositorio decódigo Hacer tus propios tests Commits diarios Compilar rápida y ágilmente Testar en clon deproducción, desarrollo, QA, etc. Resultados accesibles porparte de todos Versionar los componentes.
  • 45. Sobre las metodologías
  • 46. Enfoques Existen variados… Cascada Basas en prototipos Incremental o evolutivo Espiral OO Cascada con sub-proyectos Entrega por etapas
  • 47. Metodologías De los 90 RAD OOP DSDM SCRUM RUP Desde hace 12 años XP EUP DDD TDD FDD BDD
  • 48. Algo sobre metodologíaságiles.
  • 49. Agilismo Empezó por el manifiesto Agil en Febrero 2001 Surge por la necesidad de mejores métodospara construir software La construcción de software DEBE considerardiversos tipos de pruebas
  • 50. Principios Individuals and interactions over processes andtools Working software over comprehensivedocumentation Customer collaboration over contract negotiation Responding to change over following a plan
  • 51. Métodos Agiles Lean SCRUM Crystal Clear Extreme Programming
  • 52. Enfoque ágil... Software que funciona-Satisfacción del cliente Adaptar el proceso continuamente Comunicación cara a cara A veces dificil Excelencia técnica Simplicidad Auto organización
  • 53. Lean SoftwareDevelopment
  • 54. Eliminar desperdicio Burocracia Comunicación Interna lenta Requerimientos no definidos o nebulosos Código innecesario
  • 55. Extreme Programming(XP) Conjunto de practicas sencillas Es difícil su implementación si no haycompromiso Su objetivo es mejorar la calidad del software yresponder a los cambios en los requerimientos
  • 56. Practicas en XP-FeedBack Retroalimentación Programación en pares Juego de planeación Test Driven Development Esto es diseño mas que pruebas
  • 57. Practicas en XP-ProcesoContinuo Procesos continuo Integración continua Refactoring ¿Rewrite? Liberaciones pequeñas
  • 58. Practicas en XP-Codificación Codificación Pruebas de unidad Optimizar el código al final No horas extra (40 horas a la semana debe sersuficiente)
  • 59. Practicas en XP-Pruebas Pruebas Pruebas de unidad para todo Pruebas de integración Deben funcionar todas las pruebas antes de liberar Si surge un error (bug), deben escribirse las pruebas parareplicarlo. Un bug es una prueba que olvidamos escribir
  • 60. Pruebas de unidad Se prueban los componentes aislados Generalmente se usan Mocks o Stubs Se usan verificaciones “asserts” para probar Son confundidas con Pruebas de integración Pruebas de caja blanca
  • 61. Pruebas de integración Sirven para probar los componentesinvolucrados en un flujo Validan el trabajo de varios desarrolladores Pruebas de caja negra Pueden ser automatizados, simulan lainteracción con el usuario
  • 62. Impacto de las pruebas El tener una buena batería de pruebas, nospermite entre otras cosas: Validar nuevos requirimientos Medir el impacto de los refactorings Documenta el proyecto Permite mejorar el diseño
  • 63. Faltan mas pruebas¡¡ Pruebas de Stress Pruebas de Performance Pruebas de Integración de Sistema Pruebas de Aceptacion Pruebas de Sistema Pruebas no funcionales Pruebas Funcionales
  • 64. Notificación visible
  • 65. Visual management
  • 66. Atlasianhttps://jira.springsource.org/secure/VersionBoard.jspahttps://jira.springsource.org/browse/SPRhttps://jira.springsource.org/secure/IssueNavigator.jspa?
  • 67. I+D
  • 68. El presente de Java Lenguaje != plataforma. Lenguaje=SDK Plataforma = JVM
  • 69. JVM como plataforma Groovy Scala Jruby Jython Clojure
  • 70. Mediante ByteCode
  • 71.  Lenguaje interpretado Multiplataforma Orientado a Objetos Sintaxis clara Funciones y librerias Gran comunidad detrás
  • 72.  Nace a finales de 1997 Python en Java Identyico a python 2.2 Al igual que Python, Jython es dinámico Mas o menos maduro para el funcionamiento enJVM
  • 73. Ejemplo JythonEjecución
  • 74.  Lenguaje de proposito general, dinámico, orientado aobjetos Es funcional, imperativo y reflectivo Tipado dinámico Multiplataforma Introspección, metaprogramación Soporta alteración de objetos en tiempo deejecución Venia por Java
  • 75.  10 años de desarrollo Compatible con ruby 1.8.7 Puede correr de manera interpretada. Implementación 100% Java Al igual que jython, se han tenido que hacerarreglos para que corra en la JVM
  • 76. Ejemplo JRuby
  • 77.  Empieza su desarrollo 2001 Es orientado a objetos y funcional Significa “Scalable Language” El compilador genera byte code Diseñado para vivir en la JVM y otros entornoscomo .NET Pensado para concurrencia.
  • 78. Ejemplo Scala
  • 79. Alrededor de Scala LIFT, framework web para hacer sistemas de altaconcurrencia. AKKA, plataforma para construir aplicacionesorientadas a eventos, escalables, y tolerantes afallos.
  • 80.  Aparece en 2003. Groovy es un lenguaje dinámico, orientado a objetos, muyíntimamente ligado a Java. Diseñado para “robarse” cosas buenas de Python y Ruby EL 99% del código Java existente puede ser compilado mediantegroovy. El 100% del código Groovy es convertido en bytecode Java. Gran comunidad detrás Varios proyectos alrededor Soporte de herrmientas Eclipse, NetBeans, IntelliJ
  • 81. ¡Azúcar sintáctica! Listasdef list = [77,ABC,new Date(), x=15, abcdefg[ 1, 3, 5, 6 ] ][77, ABC, Thu Aug 11 12:47:09 CLT 2011, 15, bdfg] Mapasdef map= [id:FX-11, name:’Pepe, no:1234, 99:Y] Rangosdef toUp = 5..99def toDown = 100..0 Assignation multiple:def (x,y) = [45,-35] Return Opcional
  • 82. Herramientas sobre Groovy Testing Spock GMock Construcción Gradle Gant Framework Grails = Web Griffon = Swing Gaelyk = Web
  • 83.  ¿Qué es Grails? Plataforma para desarrollo agil en web Framework mvc full-stack Convención sobre configuración. Corre y se integra con la JVM Desarrollo de aplicaciones con groovy y java Orientado a objeto Dinámico Sintaxis Familiar Opensource
  • 84. Grails: La plataforma
  • 85.  Ventajas y Caracteristicas “The real” ORM, con cero configuración Dependency Injection Manejador de transacciones Internacionalización Web Flow Tag libraries Caching Layouts Ajax Servidor no necesita reiniciar(most cases) Desarrollo de pruebas en caliente Unit Testing Integration Testing Functional Testing
  • 86. DEMOcvs: Investigacion/JFinder
  • 87. Resumen Lo que nos ha funcionado… Lo que nos gusta usar para desarrollar … Lo que nos ha hecho mas productivos… Lo que nos puede dar control sobre el proceso dedesarrollo… Lo que nos puede permitir visualizar el desarrollo… Lo que nos gustaría implementar… Lo que necesitamos para mejorar….
  • 88. Gracias!