Cosecha de libros

Cosecha de libros

En Mayo pasado cuando asistí a la XPConf aproveché que había una stand de venta de libros y me di el gusto de comprar un par de libros que tenía en la mira desde hace tiempo.

En línea con la idea de que en un equipo todos sus miembros deben tener un perfil tipo T (saber en profundidad de un tema y al mismo tiempo tener una idea general del resto) hay un tema particular en el que me siento especialmente flojo: Usabilidad. Por esto decidí comprar dos libros:

  • The Design of everyday things, de Donal Normal, un libro clásico, no particularmente de software sino de diseño y usabilidad en general. Me lo había recomendado @dfontde hacía ya tiempo.
  • Don’t make me think, de Steve Krug, este si es un libro específico sobre usabilidad de software. Lo había visto hacía años en la biblioteca de una empresa amiga y desde entonces lo tenía en mi wish list.

Otro tema en que me siento flojo es en testing exploratorio y por ello también me compré un libro al respecto:

Finalmente había un conjunto que libros que ya había leído (al menos parcialmente) y que como me gustaron mucho quería tenerlos en formato físico:

«Agilistas» ¿fuera de foco?

Yo: me parece que deberíamos liberar las funcionalidades a medida que las vamos completando

El Scrum Master: o sea que querés usar Kanban en lugar de Scrum

Es la tercera vez en lo que va del año que tengo este diálogo, cada vez con un Scrum Master distinto (en distintos proyectos). No soy experto en Scrum pero ¿acaso Scrum dice que hay que esperar al final del Sprint para liberar una funcionalidad? Y si así fuera ¿que problema hay? Si vemos que en nuestro contexto puede resultar más beneficioso liberar a medida que completamos cada funcionalidad ¿porque no hacerlo? ¿Simplemente porque no es lo que dice Scrum?

Mi sensación es que hay:

  • Gente más preocupada por hacer Scrum que por entregar valor
  • Gente más preocupada por decir que es ágil que por serlo
  • Gente más preocupada por los ritos que por la mejora continua

 

El camino freelance, parte 6: libros recomendados

El camino freelance, parte 6: libros recomendados

Decidirse a comenzar el camino freelance no es fácil. A mi me llevó un buen rato, un par de años de hecho. La primera vez que lo consideré seriamente fue a fines de 2008 pero no di el paso hasta el 2012.

Allá por 2008 empecé a investigar hablando con algunos freelancers que conocía y leyendo algunos blogs, hasta que finalmente me compré un libro: The Principles of Successful Freelancing de Miles Burke. El libro valió la inversión, me ayudó a ver varias cuestiones que no estaban en mi radar en aquel momento.

Hoy, habiendo ya recorrido un par de años en el camino independiente vuelvo a recomendar el libro de Burke pero también he descubierto algunos otros que recomiendo con el mismo énfasis.

Soft Skills de John Sonmez y The Software Craftsman de Sandro Mancuso son dos libros excelentes y que recomiendo para todo programador profesional más allá de que trabaje de forma independiente o en relación de dependencia. Ser profesional es un valor que en el caso de trabajadores independientes es aún más valioso. El libro de Mancuso está enfocado en el desarrollo profesional. El libro de Sonmez también habla de desarrollo profesional pero es más profundo y llega a cubrir cuestiones concretas como técnicas de productividad, estrategias de trabajo remoto, marketing personal, la transición freelancer y cuestiones económico/financieras.

Los tres libros que mencioné  hasta el momento son libros para informáticos, el cuarto libro que quiero recomendar es mucho más genérico y posiblemente también más famoso: Los 7 hábitos de la gente altamente efectiva de Stephen Covey. Este libro nada dice sobre programadores ni trabajadores independientes, sino que básicamente habla de organización personal, algo fundamental para todo trabajador independiente.

 

Despedida de UNQ

El mes pasado cerré una etapa en mi carrera docente, presente mi renuncia en UNQ. No fue una decisión fácil, en UNQ estuve por primera vez a cargo de una materia lo cual fue un gran paso en mi carrera. Por otro lado tuve la oportunidad de aprender y compartir muchas experiencias tanto con colegas docentes como con alumnos. También tuve la oportunidad de participar de algunos de los debates de armado de la Licenciatura en Desarrollo de Software (que luego debió renombrarse por cuestiones administrativas). Por cinco años forme parte de un equipo docente de excelencia.

En estos cinco años, participé inicialmente del dictado de Objetos 1 y luego estuve a cargo de Ingeniería de Software. En los 9 cuatrimestres que dicté esta última materia tuve un total de 105 alumnos con un porcentaje de aprobación del 89%.

Pero como mencioné tiempo atrás, este año decidí dar un nuevo paso en mi carrera y tomé un cargo de mayor dedicación en UNTREF con el objetivo de trabajar en un proyecto de investigación.

A pesar de dejar mi cargo espero poder seguir en contacto con la comunidad UNQ y poder participar de futuras actividades.

Agradezco a toda la comunidad de UNQ  por las experiencias compartidas y muy especialmente a Fidel, quien me abrió las puertas de TPI y confió en mi para el dictado de Ingeniería de Software.

¡Gracias totales!

Nuevo proyecto: de regreso a .Net

Nuevo proyecto: de regreso a .Net

Hace un par de semanas comencé un nuevo proyecto, esta vez con tecnología .Net y con un contexto interesante:

  • El proyecto es de desarrollo y mantenimiento evolutivo de un sistema existente
  • El sistema está compuesto por un conjunto de aplicaciones de distinto tipo
  • El sistema lleva varios años en producción y no tiene ningún tipo de pruebas automatizadas
  • La documentación funcional y técnica es escasa (prácticamente nula)
  • Varias de las bases de datos no tienen claves foráneas
  • El sistema escala en forma vertical y no horizontal

En este contexto voy estar colaborando en cuestiones de arquitectura, operaciones y prácticas técnicas de desarrollo.

Continuará…

SoCraTes Chile 2016

SoCraTes Chile 2016

La conferencia estuvo excelente y más aún si tenemos presente que es la primera edición en Latam. Si bien es cierto que en el cono sur se vienen realizando conferencias en formato open space desde hace ya varios años, dudo mucho que alguna haya sido tan técnica como esta y al mismo tiempo con tan buen nivel.

Un punto importante para destacar es que la mayoría de las sesiones estaban preparadas con antelación, un tema que personalmente vengo insistiendo hace tiempo pues en la mayoría de los open spaces que he participado casi todas las sesiones ha sido improvisadas, lo cual generalmente ha jugado en contra de su calidad.

La conferencia se realizó en las instalaciones de la Escuela de Ingeniería de la Universidad de Chile. A diferencia de otros open spaces en los que participé, en este había un solo espacio, o sea, una única planta abierta en la cual se desarrollaron hasta 7 sesiones en paralelo. Para ser sincero debo admitir que inicialmente pensé que sería un caos, pero para mi sorpresa salió todo muy bien.

Los asistentes estaban convocados a las 9 de la mañana pero los organizadores arribaron bastante antes. Alrededor de las nueve 9.30 todos tomamos asiento y los organizadores hicieron la apertura y continuación de la misma se largo el marketplace de sesiones. De la apertura me llamaron positivamente la atención dos cuestiones: la mención explícita del código de conducta (algo que en muy pocas conferencias he visto) y ciertas instrucciones para el caso de emergencias (lo cual resulta muy lógico considerando que Santiago es una zona sísmica).

El marketplace fluyó con muy buen ritmo, algunas de las sesiones propuestas fueron (los nombres que comparto aquí no son exactos):

  • Continuous Delivery en Latam Airlines
  • Big Data en Chile
  • Versionado en un producto multi-cliente
  • Estrategias de Branching
  • Feature-Driven Architecture
  • How-to TDD en Php
  • Desarrollo de Microservicios con Scala y Akka
  • WebDrone, un framework para automatización de pruebas web
  • Test-Driven Problem Solving
  • Intro a Play Framework
  • Proyecto CarBack
  • Ser programador a las 50
  • Coding Dojo Proyecto Euler
  • Mutation Testing
  • Continuous Delivery a gran escala (propuesta por mi)

Entre las sesiones que participe destaco la presentación de @ferpobletea del caso de Continuous Delivery en Latam Airlines, el caso en si mismo resultó interesante y la presentación fue impecable.

Luego me pareció muy interesante la presentación de Aldrin Martoq sobre WebDrone, un DSL Ruby que provee una capa de abstracción sobre Selenium WebDriver. Me gustó mucho la dinámica, hizo una presentación breve y a continuación empezó a codear unos tests sobre FaceBook usando la herramienta en cuestión.

El coding Dojo de la tarde me pareció excelente, trabajamos sobre 2 ejercicios extraídos de Proyecto Euler. Ambos ejercicios los hice en Ruby con RSpec (haciendo TDD obviamente). El primero lo resolví sin mayores dificultades pero el segundo me resultó mucho más trabajoso. Inicialmente plateé una solución recursiva que si bien era conceptualmente correcta, tardaba una infinidad de tiempo en correr y consumía una cantidad descomunal de memoria.   Esto me llevo a cambiarla por una solución iterativa que utilizaba mucho menos memoria pero igual seguía tardando mucho. Finalmente Eduardo (el facilitador del dojo) compartió un secretillo que me permitió ajustar mi algoritmo y lograr una solución mucho más óptima en términos de tiempo de ejecución y consumo de recursos. Fue interesante que todos los cambios de implementación que fui realizando en este segundo ejercicio no modificaron el contrato de mi clase con lo cual los tests siguieron siendo siempre los mismos.

Algunas otras sesiones que tuvieron muy buena convocatoria y repercusión fueron: Feature-Driven Architecture presentada por Uzi Mamani, Microservicios con Scala/Akka y Test-Driven Problem Solving facilitada por @agustinvillena (una lástima que no pude asistir porque se superpuso con mi propia sesión).

En mi sesión tuve una buena cantidad de asistentes y me gustó como salió a pesar de ser la primera vez que la hacía. La sesión se llamo «Continuous Delivery a gran escala» y básicamente estaba centrada en una serie de técnicas/patrones para cuando tenemos que implementar procesos de integración y entrega continua en contextos «corporativos» con cientos de tareas en el servidor de integración continua.

La jornada terminó alrededor de las 6 de la tarde compartiendo unas pizzas en el mismo espacio de la conferencia.

Una vez finalizada la conferencia,  @agustinvillena y Marcel (su colega de cátedra) nos llevaron a mi y a Uzi a dar una pequeña vuelta turística por la ciudad para finalmente encontrarnos a compartir la cena con el equipo de organizadores.

Mis felicitaciones y agradecimientos a German, Felipe y el resto de los organizadores, el evento estuvo impecable y la pasé muy bien. ¡Ojalá se repita!

DSC05845

gente4DSC05837

 

DSC05854

DSC05856

Setting up a .net build server without Visual Studio

Usually setting up a build server is a very straight forward task but not always. In case you want to build .Net applications it could be a non-trivial task because of the tight coupling of the different build tools with Visual Studio. A simplified way of dealing with this complexity is to install Visual Studio in the build server. I took that approach in the past and I didn’t want to go that way again. I don’t want Visual Studio in the build server.

In a previous post I described the approach I took to simplified the setup of the different build tools I want to integration in my build process. But that approach does not work if you don’t have Visual Studio, FxCop will not work and at the same time you will get lot of warning messages because of missing dependencies. So here is what I have to do:

  1. Get a machine with Windows Server 2012 R2
  2. Install .Net SDK 4.5.2
  3. Install Microsoft Build Tools 2015
  4. Install Windows 7 SDK and .Net 4 SDK (not the whole package but only Reference Assemblies)
  5. Install .Net 3 assemblies (it can be installed by using the Add feature option in windows, so you don’t need any additional download)

With all this stuff installed in your server, then you can use the approach I described previously and just use your build server to trigger MSBuild to take care of running all your build tasks.

SoCraTes arrives South America

SoCraTes arrives South America

Next Friday, July 1st, the Software Craftsmanship and Testing Conference will arrive to South America. It will be hosted at Universidad de Chile.

I have just bought my ticket so in the next couple of days I will start preparing a session proposal (the agenda is full open space). I have 2 possible topics in mind:

  • Bringing technical excellent to legacy projects: since I started my freelancer activity the majority of the projects I have been involved were legacy projects. In that contexts my main concern was always remove technical impediments in order to enable the continuous delivery of business value. So the idea of this session is to share some patterns and practices to face this challenges.
  • Continuous Delivery at Scale: setup a Jenkins server and configure a couple jobs to automate integration and deployment is an «easy task», but the situation get complex when you have to manage hundred of projects and at the same time follow several organisational policies. This session is about patterns and recommendations to deal with this stuff.

I don’t have enough time to prepare both sessions, so I have to pick one. What would you prefer?

 

Integrating .Net Build tools: MSBuild, NuGet, FxCop, StyleCop and NUnit

These days it is very common to have a continuous build process that includes: compilation, code analysis and automated tests. The way of implementing this kind of process varies depending on the technology of the project.

I have worked with Ruby, Python, Java, JavaScript, Smalltalk and some other languages and in all cases you just need to install 3 tools:

  • the runtime/sdk (like ruby, jdk, cog)
  • a package manager (like bundle, maven, pip, metacello)
  • a build tool (like rake, maven, fabric)

Any other thing you may need (linter, testing framework, etc), you can get it using the package manager and make it run as part of your build script.

But in .Net the situation is more complex. First of all everything seems to be very tight to Visual Studio (the IDE). Because of this, many people just install the Visual Studio in the build server.

Additionally to this the .Net SDK does not provide a test framework. You can use NUnit (which you will have to install manually) or you can use MSTest but to use it you need to install Visual Studio.

FxCop (the linter) comes with Visual Studio but if you don’t want Visual Studio, then you have to install it manually.

So, in order to avoid several manual tasks when setting up a new dev box and also to minimize any possible difference between dev boxes and the build server box I did the following:

  • I downloaded all the tools I wanted to use in my build process and placed them into the same directory (c:\BuildTools).
  • I wrote a build script (using MSBuild and defining my own targets). This script «glues» the invocation to all of these tools: NuGet, FxCop, StyleCop and NUnit.
  • Finally I package all these stuff in a self-extracting .zip file so all the team members can easily replicate my setup.

In order to have the build process to run continuously I also installed this package in the Jenkins build server.

buildtools-v4buildtools-layout

Jenkins: Jobs as Code

Jenkins: Jobs as Code

Una de las funcionalidades destacadas en la nueva versión de Jenkins es la posibilidad de definir los pipelines utilizando un lenguaje de dominio específico. Esto resulta muy útil cuando uno tiene que manejar una cantidad importante de jobs y al mismo tiempo facilita el control de configuración ya que permite que la definición de los jobs sea tratada como código en lo referente al almacenamiento y versionado.

Esta posibilidad de manejar los jobs como código es algo que está ahora más presente en Jenkins 2, pero la realidad es que es una funcionalidad que ya estaba disponible para las versiones anteriores de Jenkins mediante el uso de plugins y algunas otras herramientas.

En particular yo venia utilizando el Jenkins Job Builder, una herramienta de la gente de Open Stack que permite definir jobs en un archivo .yml, definiendo también relaciones «de herencia» entre los jobs. El Job build es básicamente un script python que parsea los .yml y utiliza la api de Jenkins para crear los jobs correspondientes.

Otra herramienta que provee una experiencia similar es el Job DSL Plugin. Este plugin provee la posibilidad de definir Job utilizando un DSL Groovy para la definición de Jobs. La forma de uso es: poner los scripts de definición de jobs en un repo y luego crear un job en Jenkins (típicamente llamado Seed) que monitorea el repo de scripts y que cuando detecta cambios ejecuta los scripts los cuales generan los jobs que hayamos definido.

Otras herramientas similares pero que no he probado lo suficiente son: el Build Flow Plugin y el Workflow plugin.