Mes: agosto 2016

team.split() & Project.new()

Hace tres meses me sume a un proyecto que recién estaba empezando. En aquel momento el equipo estaba aún en formación y éramos unas 9 personas. Hace dos semanas llegamos a ser 15 personas en el equipo. Obviamente ya no era factible alimentarnos con dos pizzas.

Por ello fue que la semana pasada partimos el equipo y ahora estoy trabajando en un equipo de 5 personas: 3 devs, 1 tester y 1 facilitador. Estamos trabajando en rehacer desde cero un componente existente en la plataforma. Esperamos poder liberarlo en aproximadamente 5 o 6 semanas.

Ayer empezamos la primer iteración. La planning estaba agendada para las 11 de la mañana, pero como todos estabámos en la oficina desde las 9, decidimos comenzar a trabajar en algunas tareas de setup todos juntos: creación del repositorio Git y de la estructura de la solución base y configuración del Jenkins para que haga integración continua (#ci). Luego hicimos la planning donde acordamos con nuestro PO los items a trabajar durante la iteración. Por el momento y dadas las particularidades de nuestro proyecto, no estamos estimando los items de nuestro backlog (#NoEstimates). Simplemente intentamos particionar los items de forma tal que sean pequeños y que requieran no más de 2 días de trabajo cada uno. De esta forma medimos cantidad de items completados por iteración.

A continuación de la planning debatimos algunas cuestiones de diseño de alto nivel. Ya por la tarde, con todo el equipo trabajando sobre una compu + proyector (#mob-programming like) comenzamos a escribir las pruebas de aceptación que nos guiarán en el desarrollo de las funcionalidades comprometidas (#tdd). Esto nos permitió detectar en forma temprana algunas dudas sobre el comportamiento esperado de la aplicación.

Estoy muy entusiasmado con este proyecto, ya que implica el trabajo con un equipo nuevo, teniendo la confianza del cliente para hacer las cosas de la forma que nosotros consideramos más apropiada.

Continuará…

Reclutando programadores: cortesía

Reclutando programadores: cortesía

Una empresa analiza el CV de una candidato, lo contacta y decide citarlo para una entrevista. El candidato acepta la invitación y la entrevista se concreta. La empresa finalmente por X motivo decide no contratar al candidato pero no se lo notifica explícitamente, simplemente no vuelve a contactarlo.

Fea la actitud.

Si el candidato se tomó el tiempo para asistir a la entrevista, la empresa debería mínimamente enviarle un mail para notificarle su decisión. No pretendo que la empresa de explicaciones, simplemente que tenga la cortesía mínima de enviar un mail para que el candidato no quede pendiente de una falsa ilusión. Y no importa que la entrevista haya terminado con la clásica frase «Gracias por venir, si decidimos avanzar con el proceso te llamamos», creo que de todas formas hay que notificar al candidato, es una cuestión de cortesía.

Adicionalmente si se le pidió al candidato resolver algún tipo de ejercicio considero que la empresa debería mínimamente dar algún tipo de feedback al respecto. Una vez más una simple cuestión de cortesía. El costo es mínimo y deja una buena imagen de la empresa.

Reclutando programadores

Desde hace ya un par de años que la demanda de profesionales informáticos en Argentina está por encima de la oferta disponible. Por esto es que algunas empresas han comenzado a prestar mayor atención a ciertas cuestiones como el proceso de reclutamiento y los planes de carrera.

El año pasado una empresa en que había trabajado como empleado tiempo atrás, me contactó para que los ayudara con un plan de entrenamiento para programadores y líderes técnicos. Nos reunimos a hablar del tema para entender mejor sus necesidades y finalmente terminé presentando una propuesta integral que incluía trabajar sobre el proceso de reclutamiento, el entrenamiento y los planes de carrera. Si bien el proyecto nunca se concretó, yo estuve pensando bastante en el tema y un libro que lei recientemente me ayudó a confirmar algunos puntos de mi visión.

Una charla que tuve con un colega la semana pasada me motivó para compartir mis ideas, así que decidí inaugurar una nueva serie de artículos en este blog y que voy a bautizar como: «Reclutando programadores».

Continuará…

recluting

.Net: infraestructura de desarrollo & test

Quiero compartir la infraestructura que estamos usando en el proyecto que estoy trabajando en este momento.

Como repositorio de código estamos usando Git, más específicamente GitLab (aunque a pedido del cliente en breve migraremos a BitBucket).  Dado que estamos usando una arquitectura «micro-servicios-like» tenemos un repositorio por cada micro-servicio, más un repositorio general para configuración, más un conjunto de repositorios adicionales para algunas librerías de uso común y finalmente un repositorio para los scripts de operaciones.

Estamos usando Nexus como repositorio de binarios NuGet y Maven, ya que tenemos componentes .Net y Java.

El servidor de integración continua y orquestador de deployments es Jenkins 2. El proceso de Build lo tenemos armado con MSBuild de manera que Jenkins simplemente obtiene el código de Git, dispara MSBuild y genera reportes y notificaciones basados en el resultado del proceso.

Los deployments los hacemos con MSDeploy y los disparamos desde Jenkins.

De esta forma, los componentes comunes compartidos entre distintos micro-servicios están publicados en nuestro NuGet/Nexus y quien necesita utilizarlos simplemente agrega una referencia a nivel binario usando NuGet. Esto nos permite evitar almacenar binarios en Git y al mismo tiempo que nos habilita a que cada parte de la arquitectura pueda ser versionada en forma independiente.

Para la gestión del backlog utilizamos Jira que a su vez lo tenemos integrado con Hiptest para el manejo de los casos de prueba. Personalmente nunca antes había trabajado con Hiptest y algo que me gusta mucho es que se integra con SpecFlow para la definición de los casos de prueba y el registro centralizado del resultado de la ejecución de las pruebas reportado por SpecFlow.

Para comunicarnos tenemos una lista de correo, un Slack y Skype/Hangout para las video conferencias.

pipeline_net

.Net Core: un primer vistazo

El último fin de semana estuve haciendo un par de Katas para familiarizarme con el nuevo stack de herramienta de .Net Core. Lo que aprendí me gustó mucho y para compartirlo hice este breve video introductorio. Espero resulte de utilidad.

Nota: en el video también hice uso de algunas herramientas «extra .net», más concretamente utilicé un generador de código, un Yeoman.

.Net: abuso de AppSettings

Toda aplicación .Net cuenta con un archivo xml de configuración. Dicho archivo tiene un conjunto de secciones predefinidas entre las que se encuentra la sección AppSettings que permite definir parámetros de configuración del tipo clave-valor.

Considero que este mecanismo resulta muy útil y apropiado para cuando uno tiene que manejar un set reducido de entradas en esta sección. Sin embargo me he cruzado con aplicaciones con más de 10 entradas en appsettings. Más aún, en alguna ocasión que me cruzado con aplicaciones con ¡más de 50 appSettings!. El problema que veo con esto es que cuando uno cuenta con tal cantidad de parámetros de configuración, es muy posible que dichos parámetros tengan cierta relación/estructura, la cual no es posible reflejar usando el mecanismo de AppSettings. Para estos casos resulta mucho más conveniente en mi opinión utilizar el mecanismo de extensión de configuración que ofrece .Net definiendo secciones personalizadas.

Este breve artículo de MSDN explica de forma muy concreta cómo hacer uso de este mecanismo. Personalmente no suelo usarlo porque en mis proyectos generalmente uso algún inyector de dependencias y hago uso de las funcionalidades del inyector para precisamente inyectar los parámetros de configuración.

.Net Core: el renacimiento

Hace un par de semanas decidí instalar .Net Core, la más reciente versión de .Net publicada por Microsoft. Me sorprendí muy positivamente. Si bien había leído algunos artículos sobre la idea de este .Net Core, muchas veces la idea y la implementación tienen un delta enorme.

En primer lugar hay que aclarar que .Net Core marca un hito en la evolución de la plataforma .Net por una serie de cuestiones:

  • Es de código abierto (licencia MIT)
  • Es multiplataforma por iniciativa propia de Microsoft en Windows, Linux y MacOS (otras versiones de .Net también corrían en Linux, pero era por el trabajo realizado por la gente de Mono)
  • .Net Core no es el sucesor de .Net 4.5, sino que es una redefinición de la plataforma .Net y por ello su número versión se ha reseteado: .Net Core 1.0

Uno de los cambios que trae .Net Core es una experiencia de usuario totalmente distinta para el programador. Tradicionalmente el programador .Net ha estado «esclavizado» al Visual Studio, un entorno de desarrollo extremadamente pesado y en mi opinión no tan potente (al menos que uno le instale la extensión ReSharper) .Net Core brinda una experiencia de usuario muy parecida a la que típicamente se tiene trabajando con lenguajes de tipado dinámico del tipo Ruby, Python. Esto es: trabajo desde una terminal y codificación con un IDE liviano tipo Sublime, Atom, etc. Sin embargo aquellos que prefieran seguir trabajando con el pesado Visual Studio, también puedo hacerlo.

Al mismo tiempo Microsoft también ha generado un nuevo IDE (muy parecido funcionalmente a Atom y Sublime) que se llama Visual Studio Code. Personalmente la elección del nombre me parece desafortunada pues genera confusión ya que esta herramienta no tiene nada que ver con el famoso Visual Studio. Por ello yo habría optado por un nombre nuevo totalmente desligado de Visual Studio.

Para aquellos que quieran una explicación bastante completa de cómo calza .Net Core en el mundo .Net existente y de la visión de Microsoft a futuro para .Net, les recomiendo leer este excelente artículo de Rick Strahl.

En las próximas semanas iré compartiendo mis experiencias con estas nuevas herramientas.

Noche polémica en Agiles@BsAs

Noche polémica en Agiles@BsAs

Como anuncié hace un tiempo, ayer tuvimos Meetup de Agiles@BsAs por partida doble.

La reunión comenzó con @jgabardini diciendo «F*** the manifesto«, una crítica provocativa al manifiesto escrito hace ya quince años. La charla estuvo muy creativamente planteada desde la teoría de Tribal Leadership.

A continuación yo hablé sobre Software Craftsmanship. Fue mi primera vez hablando de este tema ante una audiencia. Los slides que utilicé están disponibles aquí.

Si bien había unas 70 personas registradas, la cantidad de asistentes fue de alrededor de 25, una caída habitual en este tipo de encuentros. Ambas presentaciones tuvieron muy buena participación de la audiencia generando como estaba esperado cierto nivel de polémica.

Personalmente estoy muy conforme con como salió el encuentro, agradezco a los participantes y Kleer por haber facilitado las instalaciones.

Herramientas para desarrolladores Windows

Herramientas para desarrolladores Windows

Para quienes trabajamos habitualmente en mundo unix-like (Linux, MacOS, etc), trabajar en Windows puede resultar extremadamente molesto. Personalmente he encontrado dos herramientas que me han ayudado a mitigar mis tareas en Windows:

  • Chocolatey es un gestor de paquetes para Windows, es en cierto modo un equivalente al apt-get de los sistemas Debian.
  • Cmdler es un emulador de consola. Simplemente excelente pues más allá de los típicos comandos POSIX también provee un editor vi, un esquema de colores muy agradable y prompt muy cómodo.
  • Firefox, creo que no hay mucho que decir
  • Visual Studio Code es un «Power editor» al estilo Sublime. Su nombre me parece una triste elección pues causa confusión y poco tiene que ver con el famoso Visual Studio, pero es una muy buena herramienta de edición de código.