Entradas

SpringBoot + Docker

Imagen
En este post intentare explicar los pasos que tienes que seguir para construir una imagen Docker y subirla a Docker Hub para ejecutar una aplicación SpringBoot. Docker Según su propia web , Docker en resumen, es una plataforma para desarrollar, implementar y ejecutar aplicaciones con contenedores. Un contenedor ejecuta una imagen. ¿Y que es una imagen? Es un paquete ejecutable que incluye todo lo que se necesita para ejecutar una aplicación: el código, librerías, variables de entorno y archivos de configuración. A container is a runtime instace of an image   (Un contenedor es una instancia en tiempo de ejecución de una imagen) DockerHub Es un servicio cloud que tiene varias características: Repositorios de imágenes Builds automáticos Webhooks Organizaciones Integración con GitHub y Bitbucket En este post, lo que haremos será construir una imagen que subiremos al repositorio de imágenes de Docker Hub. Para poder subir imágenes, debemos crearn

¿Por qué Scrum?

Imagen
Desde que estoy inmerso en el mundo Agile, en especial en Scrum, siempre he escuchado frases del tipo “Esos post-it son una chorrada”, “tanta reunión es una perdedera de tiempo”, “¿Eso sirve para algo?”, “Yo hago mi trabajo y listo”. Haciendo un poquito de historia… Cuando estaba con  el proyecto de grado de fin de carrera, era necesario entregar un amplio documento técnico hecho al detalle, con infinidad de diagramas UML, dichos diagramas se hacían antes de poner la primera línea de código, como era lógico pregunte a mi profesor de la  U ¿Qué pasa si el código no es como se muestra en el diseño? Su respuesta fue –Cambias el diseño. Con la poca experiencia que tenía en ese momento, pensé que eso de cambiar el diseño seria el pan de cada día en el desarrollo de software. Con el tiempo he comprobado que no estaba equivocado, en el software es muy complicado conocer al 100% lo que se quiere como para crear un diseño perfecto. He visto quejarse al usuario a

Lo que me dejó la PAM 2015

Imagen
Cuando me enteré del evento en el blog de Javier Garzas [1] no dudé en asistir, el objetivo del PAM Peopleware Agile Management [2] era más que llamativo.  En él, sin conocer aún el programa sabía que se hablaría sobre equipos, personas, gestión, calidad. Temas que me dieron sobradas justificaciones para asistir. Para empezar, es muy grato ver como a pesar de ser un evento entre semana y que ocuparía todo el día, la asistencia fue muy buena (Supongo que más de un jefe de los asistentes al evento, pensaría que ir seria perder el tiempo. Pero bueno, de esa frase hablaré en un futuro post). Con el formato de charlas simultaneas de 30 minutos de duración, he de admitir, que en principio pensé que sería muy ajustado el tiempo y no se cumpliría la agenda, pero para mí grata sorpresa, ¡fue un éxito! Tomado del facebook de Javier Garzas https://www.facebook.com/javiergarzas.blog/ Javier Garzas dió apertura al evento, explicando el ¿Por qué necesitamos más People

Estimar no debe ser un compromiso

Imagen
Matriz Stacey Desde que estoy metido en el mundo del desarrollo de software me ha causado mucha intriga estimar, recuerdo que hace unos años tuve una conversación con un colega y amigo que era jefe de proyecto, le pregunté ¿cómo puedes estimar un proyecto completo, cerrar fechas, hasta firmar un contrato si aún el equipo no se ha puesto a desarrollar? No recuerdo exactamente su respuesta, pero fue algo del estilo: haces un análisis de todos los requerimientos, diseño y teniendo en cuenta los recursos calculas cuanto tiempo tardaras en entregar. Me quede con la sensación de que estimar nunca sería una ciencia exacta y que por más fina que fuera la toma de requerimientos y el diseño, siempre falta algo y por ende esa fecha que se dio en un principio nunca se cumpliría, ya sea porque los requerimientos no están claros, por que el cliente no sabe lo que quiere, porque no se conoce la tecnología a utilizar, etc. Se me ocurre una lista larga de porqués. Antes de

Equipo

Imagen
Al referirnos de Agile, en particular de Scrum; el elemento más importante es el equipo, como bien se reseña en el manifiesto [1] agile. Cuando hablamos de equipo, la imagen que se viene a la mente (sobre todo a los aficionados del deporte como yo) es un equipo de fútbol, baloncesto, rugby, etc. En todas esas disciplinas deportivas cuando el equipo logra triunfos, títulos o campeonatos, la gran mayoría de las veces por no decir siempre, se debe a que en el equipo existe una sinergia [2] que les permite luchar unidos por conseguir el objetivo, que es ganar. Esa sinergia se traduce en comprender que son una unidad. En el deporte como en Scrum, esa unidad llamada equipo destaca por ciertas características tales como: Objetivo común, compromiso conjunto, multidisciplinar, auto organización, libertad, responsabilidad. Ahora bien, muchos dirán, ¡Pero con que en el equipo tenga unos ‘cracks’ no me hace falta nada más!  Pues los hechos demuestran lo contrario.