Conociendo Nuestro Fua interno

221 views
172 views

Published on

Levantamiento y consultoria interna de TI.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
221
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Conociendo Nuestro Fua interno

  1. 1. { El estado del Arte }“conociendo nuestro FUA interior”.José Bovet Derpich08/08/2011
  2. 2. Agenda Estado del arte De las buenas prácticas
  3. 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. 4. Nuestro día a día
  5. 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. 6. Y como… Ocupando herramientas adecuadas No reinventando la rueda Reutilizando Arquitecturas basadas encomponentes Implementando patrones de diseñoe integración. Testeando
  7. 7. Tecnologías que usamos. Lenguajes
  8. 8.  IDES
  9. 9.  Servidores de aplicaciones y ContenedoresWeb
  10. 10. S.O
  11. 11.  No reinventamos la rueda.CXFJAX-WSORMWebServicesJavaScriptVistaTestTareas y BuildersUtilitarios, loggers, etcSCMSearchEngine
  12. 12.  Nuestra piedra angular
  13. 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. 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. 15. El poder de POJO
  16. 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. 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. 18. Donde lo usamos…
  19. 19. En todos los escenarios…
  20. 20. Con otros frameworks
  21. 21. En remoting
  22. 22. Nuestras Aplicaciones Front Oficce Back Office
  23. 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. 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. 25. Malas Prácticas
  26. 26. “Todo en uno”No existen libreríasespecificasNo se tiene información delcomponente.¿Qué hace cada jar?
  27. 27. “La redundancia, a veces, no esbuena…”Duplicidad en los componentesSaludosjava.lang.NoClassDefFoundErrorCual es la que vale?JUnit en el deploy?
  28. 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. 29. “Abuso de las librerías.”Desconozco lo que ya estahecho.Un caos!
  30. 30. “No tenemos un estándar”“Extiendo y también usoanotaciones para mistest”
  31. 31. “No tenemos un estándar”“¿Se que clases necesito ocupar?”• Controller– AbstractController• MultiActionController• BaseCommandController– AbstractCommandController– AbstractFormController» SimpleFormController» AbstractWizardFormController– ThrowawayController– ParameterizableViewController
  32. 32. De las buenas prácticas“Producer good software is hard”
  33. 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. 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. 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. 36. Una mirada a CI
  37. 37. Herramientas
  38. 38. Control de versiones
  39. 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. 40. Herramientas ControlVersiones Centralizados Distribuidos
  41. 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. 42. Herramientas
  43. 43. Pero aún faltan Issue tracker Virtualización Testing Tools
  44. 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. 45. Sobre las metodologías
  46. 46. Enfoques Existen variados… Cascada Basas en prototipos Incremental o evolutivo Espiral OO Cascada con sub-proyectos Entrega por etapas
  47. 47. Metodologías De los 90 RAD OOP DSDM SCRUM RUP Desde hace 12 años XP EUP DDD TDD FDD BDD
  48. 48. Algo sobre metodologíaságiles.
  49. 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. 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. 51. Métodos Agiles Lean SCRUM Crystal Clear Extreme Programming
  52. 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. 53. Lean SoftwareDevelopment
  54. 54. Eliminar desperdicio Burocracia Comunicación Interna lenta Requerimientos no definidos o nebulosos Código innecesario
  55. 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. 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. 57. Practicas en XP-ProcesoContinuo Procesos continuo Integración continua Refactoring ¿Rewrite? Liberaciones pequeñas
  58. 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. 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. 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. 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. 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. 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. 64. Notificación visible
  65. 65. Visual management
  66. 66. Atlasianhttps://jira.springsource.org/secure/VersionBoard.jspahttps://jira.springsource.org/browse/SPRhttps://jira.springsource.org/secure/IssueNavigator.jspa?
  67. 67. I+D
  68. 68. El presente de Java Lenguaje != plataforma. Lenguaje=SDK Plataforma = JVM
  69. 69. JVM como plataforma Groovy Scala Jruby Jython Clojure
  70. 70. Mediante ByteCode
  71. 71.  Lenguaje interpretado Multiplataforma Orientado a Objetos Sintaxis clara Funciones y librerias Gran comunidad detrás
  72. 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. 73. Ejemplo JythonEjecución
  74. 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. 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. 76. Ejemplo JRuby
  77. 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. 78. Ejemplo Scala
  79. 79. Alrededor de Scala LIFT, framework web para hacer sistemas de altaconcurrencia. AKKA, plataforma para construir aplicacionesorientadas a eventos, escalables, y tolerantes afallos.
  80. 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. 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. 82. Herramientas sobre Groovy Testing Spock GMock Construcción Gradle Gant Framework Grails = Web Griffon = Swing Gaelyk = Web
  83. 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. 84. Grails: La plataforma
  85. 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. 86. DEMOcvs: Investigacion/JFinder
  87. 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. 88. Gracias!

×