Ayer hice el webinar de técnicas de versionado con la ayuda de Carlos Peix. Pueden verlo YouTube. La deck utilizada está disponible para descarga aquí.
Autor: NicoPaez
Webinar: Técnicas de versionado para Entrega Contínua
El próximo miércoles (mañana), voy a estar dando un webinar sobre este tema. La idea es ver los conceptos básicos de la práctica Continuous Delivery y enfocarnos en cómo manejar nuestro repositorio de código para facilitar la entrega continua. Presentaremos algunos conceptos y estrategias, y veremos como llevarlos a la práctica utilizando la herramienta Git.
En página de registración encontrarás más detalles sobre este webinar.
Durante el webinar, recibiré consultas a través de Twitter (@kleer_la & #kleerScm).
Tools for Git
There is a simple but extremely useful tool to work with Git. It is not a graphic interface nor an IDE plugin. It is just an extension to the shell. It is called oh-my-zsh and, among other things, it provides a feature that shows the current git branch you are working on, when you are browsing a git directory.
To install this tool, you just have to follow these simple steps:
- The tool is an extension to zsh shell, so you have to start by installing zsh: apt-get install zsh
- Then you could want to set zsh as you default shell: chsh -s /bin/zsh <user_name>
- Install oh-my-zsh: curl -L https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh | sh
- Close the terminal and restart you OS session
That is all, you are done!.
Tutorial de aplicaciones Padrino: parte 1
En esta primera parte veremos la configuración inicial de nuestra aplicación y algunas de las herramientas que utilizaremos a lo largo del tutorial. La idea trabajar con un entorno como el descripto en el post inicial de esta serie, partiendo de esta solución y siguiendo los videos explicativos.
- Creación del repo git y primer commit, ver.
- Creación de la aplicación base con Padrino, ver.
- Configuración de Travis (build server), ver.
- Ajustes de configuración en la aplicación base que genera Padrino, ver.
- Generación de un objeto de negocio (model) con Padrino, ver.
Continuará…
Cierre de cuatrimestre en UNQ, cuarta promoción
Terminó el cuatrimestre y se fue la cuarta promoción de Elementos de Ingeniería de software desde que la materia está a mi cargo. Este cuatrimestre la materia tuvo un enfoque mucho más práctico. El primer mes de clase fue más o menos igual que siempre, pero luego nos fuimos enfocando mucho más en cuestiones cercanas al código. Para ello trabajamos con Ruby+Padrino, GitHub, Travis y Heroku. Lás últimas 5 semanas los alumnos trabajaron en grupo en el desarrollo de distintas aplicaciones. La aplicaciones en sí no fueron más que una excusa para poner en práctica los temas de ingeniería abordados durante la materia: estimación, planificación, comunicación, gestión de alcance y cambios, etc, etc.
Otro cambio que tuvimos este cuatrimestre fue que usamos un sitio basado en Jekill para llevar la bitácora de clase.
Para cerrar la materia cada grupo de alumnos grabó un screencast contando el trabajo realizado, les dejo los links a los videos:
Al igual que el cuatrimestre pasado, conté con la colaboración de Natalia, una ex-alumna de la materia (¡gracias Nati!)
Algunos números frios:
- Alumnos anotados: 10
- Alumnos aprobados: 8 (2 alumnos abandonaron la materia en el primer mes de clase)
- Nota final promedio: 8,25
- Fueron un total de 28 clases
- Tuvimos otra vez la visita de un profesional de la industria (¡gracias Emilio!)
Estoy muy contento con como salió la materia y según lo hablado en la restrospectiva, los alumnos también quedaron contentos. Una cosa en particular que me puso muy contento, es que logré mejorar la forma en que doy feedback, algo que había salido de la restrospectiva anterior.
Nota: el ícono representa un alumno que estuvo ausente el día de la retrospectiva.
Curso de Extreme Programming y tutorial de desarrollo de aplicaciones con Padrino
Desde hace un tiempo vengo trabajando con mi colegas de Kleer en la preparación de un curso de desarrollo de aplicaciones con prácticas ágiles. En cierto modo es un curso intermedio/avanzado de Extreme Programming. Durante el curso se verán temas como SCM, BDD, TDD, Mocking, Continuous Delivery, Pair programming, Design Patterns, SOLID, etc.
La idea del curso es ver estos conceptos y poner manos a la obra programando una aplicación empresarial utilizando Github, Travis, Ruby, Padrino y Heroku, entre otros. Dado que la idea es trabajar sobre los conceptos previamente mencionados, nosotros proveeremos una aplicación base sobre la cual se desarrollará el curso y sobre la que los alumnos deberán implementar nuevas funcionalidades poniendo en práctica los conceptos/prácticas en estudio.
Aprovechando el desarrollo de esta aplicación, he decido ir generando una serie de artículos y videos a modo de tutorial, para mostrar cómo encarar el desarrollo de una aplicación utilizando las mencionadas prácticas y herramientas.
Para facilitar las cuestiones de setup, estoy utilizando una máquina virtual con Linux Mint 14. Pueden descargarse la imagen base en forma totalmente gratuita desde virtualboxes.org. Esta imagen se puede ejecutar en diversas plataformas utilizando Virtual Box.
Una vez que tengan la imagen funcionando, es necesario instalar algunas cosillas, cuyo detalle pueden ver aquí.
En los próximos días comenzaré a publicar videos de 5 minutos mostrando como desarrollar la solución utilizando las mencionadas herramientas.
Curso de Startup Engineering: Semana 3
Al cabo de 3 semanas, el curso no me está dando nada nuevo. Luego de una primer semana interesante, las semanas 2 y 3, fueron totalmente técnicas enfocadas en el uso de Linux (bash, emacs, etc), github, heroku y un poquito de Node. Tengo que esperanzas que la semana 4 se ponga más interesante.
Continuará…
Anécdotas sobre cobertura de la prueba
«No quieres 100% de cobertura, porque es realmente muy caro lograrlo. En cambio deberías enfocarte en asegurarte la cobertura en los lugares donde más frecuentemente tienes bugs«.
Este es un extracto de una charla que tuve con Stef mientras transitábamos por la ruta que lleva de Lens a Lille, en Octubre de 2010. Si bien puse el texto entre comillas, la cita no es textual, pues Stef hablaba en inglés, pero la idea central es la que reflejo aquí.
Para cerrar este post, les comparto una situación que viví hace un tiempo: resulta que una de las personas que estuve capacitando hizo una demo de la aplicación que desarrolló como parte de la capacitación. La demo venia bien y en un momento le pedimos que mostrara una funcionalidad particular que no habia sido mostrada. Resulta que cuando la va a mostrar, la aplicación ¡pincha!, ja! a lo que le pregunto ¿y los tests? adivinen….no había tests para esa funcionalidad. El porcentaje de cobertura de la aplicación no superaba el 40%. ¡Que mejor forma de ilustrar la importancia de estas cuestiones! Espero que este colega haya aprendido la lección.
Por último quiero agradecer a David Frassoni quien la semana pasada me dio la idea de escribir este post.
Algunas ideas sobre cobertura de la prueba
Ayer recibí una consulta sobre este tema y estaba convencido que ya tenia algo escrito al respecto. Me puse a buscar me encontré con este post que había escrito hace ya más de un año, pero nunca había publicado no recuerdo por qué.
Continuando con este post que hice hace un tiempo, hoy quiero compartir algunos pensamientos. Personalmente creo que es importante tener un alto grado de cobertura, pero no hay que perder de vista que la cobertura sólo indica que el código ha sido ejercitado, pero nada dice de cuan bien (o cual mal) ejercitado. Precisamente hace unos dias Carlos me compartió este artículo donde se hace especial incapié en este punto.
Como lo indica este artículo que compartí anteriormente, existen distintos tipos de cobertura. Puntualmente la forma de cobertura que yo describí entra en lo que se describe como statement coverage y que es lo que mide la gran mayoria de las herramientas.
Pero esto sólo, es una herramienta insuficiente y si uno no analiza los resultados con criterio, podria llegar a engañarse facilmente.
Es cierto que de no tener pruebas, a tener pruebas que ejerciten el 80% del código, es una mejora muy importante, pero de ahí a «confiarnos» en la calidad de nuestro código, hay aún un trecho interesante por recorrer y posiblemente sea el trecho más complejo. Es más, dado el esfuerzo que puede implicar ese 20% restante, puede que resulte más conveniente, concentrarse simplemente en las partes del código que suelen tener acarreados más defectos.
Continuará…
Customize Jenkins header
I am talking about this:
- Create a logo image of size 130×60 px
- Upload the image to web accessible location
- Copy this style sheet
- Adjust line 6 to set the header background color
- Adjust line 14 to point to your logo image
- Upload the style sheet to a web accesible location
- Enter Jenkins and install the Simple Theme Plugin.
- Go to Manage Jenkins > Configure System, look for the Theme section
- Set the URL of theme CSS to point to you style sheet
- After saving the changes you should see your new style applied
Blog de NicoPaez 