Construir software es duro y difícil, hacerlo con calidad es aun mas difícil. En nuestra joven industria han existido muchas ideas acerca de como podríamos desarrollar software con eficiencia, muchas metodologías han emergido, casi todas ellas han fallado. El movimiento ágil, fundamentado por el Manifiesto Ágil, propone principios simples, basados en humanos y sus interacciones y no en procesos o herramientas; es esencial el factor humano.
En esta charla abordaremos rápidamente los problemas comunes al desarrollar software y como podemos minimizarlos a través de sencillos principios basados en Agile Software Development. Ademas de los principios veremos como el uso de algunas practicas tomadas de Extreme Programming pueden mejorar significativamente el proceso de desarrollo de software.
El desarrollo y mantenimiento de aplicaciones empresariales, más que una profesión se ha convertido en todo un arte al darles soporte y mantenimiento, cobra mayor importancia y trascendencia cuando: diferentes desarrolladores modifican la funcionalidad, se utilizan versiones de API´s y frameworks diferentes sobre la misma aplicación sólo porque a "alguien" se le ocurrió, se duplica código por el desconocimiento de la aplicación y por si fuera poco....... existe código muerto en las diferentes capas de la aplicación (si es que se puede identificar alguna) una situación que nunca sucede en nuestro ámbito. Si el panorama no fuera ya de por si complejo, el realizar las pruebas (de todos los módulos de la aplicación) y promover la liberación de una nueva funcionalidad resulta en ocasiones más costoso en tiempo y recursos que la nueva funcionalidad por si misma. La presente sesión demuestra por medio de casos de éxito las ventajas que proporciona el someter aplicaciones existentes y nuevas sobre un proceso de integración contínua estandarizando: el versionado del código, el uso de herramientas de construcción, la automatización de pruebas, la evaluación de código y promoción de nuevas liberaciones de aplicaciones productivas. Todo esto sobre un ciclo iterativo, controlado y auditado para un objetivo final, producir aplicaciones con calidad de código.
El desarrollo y mantenimiento de aplicaciones empresariales, más que una profesión se ha convertido en todo un arte al darles soporte y mantenimiento, cobra mayor importancia y trascendencia cuando: diferentes desarrolladores modifican la funcionalidad, se utilizan versiones de API´s y frameworks diferentes sobre la misma aplicación sólo porque a "alguien" se le ocurrió, se duplica código por el desconocimiento de la aplicación y por si fuera poco....... existe código muerto en las diferentes capas de la aplicación (si es que se puede identificar alguna) una situación que nunca sucede en nuestro ámbito. Si el panorama no fuera ya de por si complejo, el realizar las pruebas (de todos los módulos de la aplicación) y promover la liberación de una nueva funcionalidad resulta en ocasiones más costoso en tiempo y recursos que la nueva funcionalidad por si misma. La presente sesión demuestra por medio de casos de éxito las ventajas que proporciona el someter aplicaciones existentes y nuevas sobre un proceso de integración contínua estandarizando: el versionado del código, el uso de herramientas de construcción, la automatización de pruebas, la evaluación de código y promoción de nuevas liberaciones de aplicaciones productivas. Todo esto sobre un ciclo iterativo, controlado y auditado para un objetivo final, producir aplicaciones con calidad de código.
Charla sobre Estrategia y desarrollos de aplicaciones moviles que Emilio Aviles Avila de SlashMobility impartió en la III trobada dels Serveis Informàtics de la Universidad de Girona
Charla sobre Estrategia y desarrollos de aplicaciones moviles que Emilio Aviles Avila de SlashMobility impartió en la III trobada dels Serveis Informàtics de la Universidad de Girona
Las organizaciones que desarrollan software que han adoptado métodos ágiles, se encuentran con un fuerte cambio de paradigma que afecta a las otras funciones de la organización. ¿Qué podemos hacer para enfrentarlo?
Exposición primer previo - Metodologías, técnicas y herramientas de desarroll...ANGIEGABRIELASUAREZG1
Las metodologías de desarrollo son métodos de trabajo diseñados para la
gestión de proyectos y programas, entre los beneficios de adoptar métodos
de desarrollo está: cumplir los objetivos y las intenciones originales sin
salirse del presupuesto establecido.
Las metodologías de desarrollo de software son aquellas que funcionan
entorno a la programación y permiten que el trabajo en equipo funcione de
manera organizada, ágil y eficaz. A pesar de que son populares en el
desarrollo de software, pueden ser utilizadas en otros ámbitos y lograr los
mismos beneficios.
Al momento de diseñar productos para un cliente o mercado se llega a un acuerdo sobre:
- costes
- equipo
- espacio de trabajo disponibles
- lenguajes utilizados
- metodología(s)
Existen dos tipos de metodologías para el desarrollo de software:
1. Metodologías agiles:
Conocidas por su adaptabilidad a los cambios; se ha demostrado que su uso otorga más beneficios en la empresa
2. Metodologías tradicionales:
Tiene una estructura sencilla y facil de seguir, sin embargo se basa en ciclos poco flexibles
Extreme Programming es una metodología ágil de desarrollo que propone un plan de desarrollo de software de corto plazo permitiendo una mayor interacción con el usuario.
aspectos de las aplicaciones y la configuración son necesarias a verificar para ejecutar cargas de trabajo en un entorno seguro.
Desde el ensamblaje de las imágenes de los contenedores a la seguridad de ETCD y acceso externo a elementos del cluster son importantes a considerar.
Kubernetes es una plataforma demasiado popular en este momento, todo mundo la usa o quiere usarla, pero es muy importante conocer las consideraciones y malos usos en los que algunos equipos caen al ejecutar aplicaciones Java.
Hableremos historia de los contenedores, por qué son necesarios, cómo docker llegó a cambiar el panoram, competencia de docker (rkt, etc.), la mejor ruta de aprendizaje y mejores prácticas.
Todo mundo habla de los beneficios de la arquitectura de microservicios, pero poco hay sobre los retos que esta arquitectuta introduce.
En esta presentación les compartimos un poco sobre algunos de los retos a los que nos hemos enfrentado en el campo.
DevFest Lima Corriendo cargas e trabajo seguras en GKE con IstioDomingo Suarez Torres
Istio es una nueva plataforma Open Source para conectar, administrar y asegurar microservicios, creado por IBM, Google y Lyft. En esta sesión se proporcionan detalles técnicos generales del proyecto Istio y una parte práctica de varias características de Istio, tales como trafico de ingreso, cumplimiento de políticas, telemetría y seguridad. Además se abordarán practicas que nos permitirán crear contenedores mucho más seguros.
In this talk, I will talk about what Cloud Native is and why it's important in the design of applications.
I will also address the challenges involved in writing Cloud Native applications in the JVM. The topics in details that will be discussed are:
Microservices arquitecture
Containers
Orchestration
Observability
CI, CD and Continuous Deployment
Security
El monitoreo no es suficiente, necesitamos más visibilidad de lo que ocurre en nuestra infraestructura, veremos como en sistemas distribuidos podemos tener trazabilidad y monitoreo para mantener saludables nuestros componentes.
Esta sesión comparte desde un punto de vista técnico las experiencias y aprendizajes obtenidos al orquestar contenedores usando la tecnología Kubernetes en SUNAT, la dependencia de gobierno federal en Perú encargada de la administración tributaria.
Presentación sobre Reactive Programming en la JVM para el meetup JVM_MX.
Se mostraron conceptos sobre Reactive Programming y Functional Reactive Programming con la biblioteca RxJava de Netflix.
En esta sesión analizaremos el caso de un proyecto que se realizó para una institución financiera para manejar el almacenamiento y búsqueda de grandes cantidades de datos. La implementación utiliza un cluster de 24 nodos distribuidos para manejar y buscar miles de millones de documentos que representan cientos de terabytes. Entre las tecnologías que se utilizaron están StorageGrid y ElasticSearch.
En esta plática compartiremos algunos de los principales retos técnicos del proyecto, y cómo se resolvieron.
ROMPECABEZAS DE ECUACIONES DE PRIMER GRADO OLIMPIADA DE PARÍS 2024. Por JAVIE...JAVIER SOLIS NOYOLA
El Mtro. JAVIER SOLIS NOYOLA crea y desarrolla el “ROMPECABEZAS DE ECUACIONES DE 1ER. GRADO OLIMPIADA DE PARÍS 2024”. Esta actividad de aprendizaje propone retos de cálculo algebraico mediante ecuaciones de 1er. grado, y viso-espacialidad, lo cual dará la oportunidad de formar un rompecabezas. La intención didáctica de esta actividad de aprendizaje es, promover los pensamientos lógicos (convergente) y creativo (divergente o lateral), mediante modelos mentales de: atención, memoria, imaginación, percepción (Geométrica y conceptual), perspicacia, inferencia, viso-espacialidad. Esta actividad de aprendizaje es de enfoques lúdico y transversal, ya que integra diversas áreas del conocimiento, entre ellas: matemático, artístico, lenguaje, historia, y las neurociencias.
Un libro sin recetas, para la maestra y el maestro Fase 3.pdfsandradianelly
Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestra y el maestro Fase 3Un libro sin recetas, para la maestr
2. Twitter
Si usan Twitter pueden encontrarme en
@domix
Comenten sobre mi charla con el hashtag
#testGulev2KX
#Gulev2KX
3. Sobre mí
Ingeniero de software desde 1999, experiencia en Java
He fundado algunos grupos de usuarios
JavaUp.org, SpringHispano.org, grails.org.mx
Colaboro en algunos proyectos OpenSource
Trabajo en @SynergyJ
Adopte los métodos ágiles desde 2005 de manera “parcial”
Tengo año y medio usando Scrum
Certified Scrum Master
4. Agenda
Problemas comunes en el proceso de desarrollo
Algunas propuestas
Agile/Lean Software Development
Extreme Programming
Testing
Conclusiones
5. Problemas comunes
Mal levantamiento de requerimientos
No son entendidos
El usuario no sabe lo que en realidad quiere
No se tiene la capacidad técnica
Se aceptan los proyectos sin pensar lo suficiente
Pésima administración de recursos
Mala negociación
Falta de COMUNICACION
17. Agilismo
Empezó por el manifiesto Agil en Febrero 2001
Surge por la necesidad de mejores métodos para
construir software
La construcción de software DEBE considerar diversos
tipos de pruebas
18. Principios
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
19. Los principios del manifiesto van
encaminados a mejorar la
comunicación, para mejorar el
proceso de desarrollo de software
mediante la adaptación.
21. 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
33. Extreme Programming (XP)
Conjunto de practicas sencillas
Es difícil su implementación si no hay compromiso
Su objetivo es mejorar la calidad del software y
responder a los cambios en los requerimientos
37. 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
para replicarlo. Un bug es una prueba que olvidamos
escribir
38. XP no es moneda de oro
Programación en pares
No hay diseño detallado
Se cree que la documentación es nula, pero las
pruebas automatizadas son la documentación de los
requerimientos
Control de cambios
39. 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
40. Pruebas de integración
Sirven para probar los componentes involucrados en
un flujo
Validan el trabajo de varios desarrolladores
Pruebas de caja negra
Pueden ser automatizados, simulan la interacción con
el usuario
41. Impacto de las pruebas
El tener una buena batería de pruebas, nos permite
entre otras cosas:
Validar nuevos requirimientos
Medir el impacto de los refactorings
Documenta el proyecto
Permite mejorar el diseño
42. 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
43. Automatización de pruebas
Usar alguna herramienta para el build del proyecto
Las pruebas deben ser
Repetibles
Autónomas
De ejecución rápida
44. Integración continua
Es el proceso de que cada cierto tiempo o cambio en
el código (commit en el repositorio), se construye el
proyecto automaticamente.
Este proceso realiza:
Compilación
Ejecución de pruebas
Generación de reportes
Notificación de errores
56. Agil
Adoptar ágil funciona
No funciona para todos
En mi experiencia ha sido muy satisfactorio
Cada equipo debe trabajar en como adoptar ágil en su
empresa
Siempre pueden volver a cascada :)