Mes: septiembre 2016

NetConfUY 2016, día 1

NetConfUY 2016, día 1

El primer día de la conferencia estuvo dedicado por completo a workshops, dos tracks en paralelo, con sesiones de 2 horas para poner manos en la masa. Dado que las sesiones tenían un cupo de 40 asistentes la cantidad total de gente de este primer día estuvo acotada. Resumo brevemente las sesiones a las que yo asistí.

La primera sesión fue Prototipado de aplicaciones Moviles con Xamarin Forms y estuvo a cargo de Sorey García. Este es uno de los temas con los que me sentía en deuda y por ello decidí asistir. El contenido no fue muy profundo pero para mi que estaba totalmente en cero, me vino de muy bien. Con lo que vi creo que ya tengo una idea suficientemente para imaginar los casos específicos en los que Xamarin podría resultar la opción apropiada.

Mi segunda sesión del día fue IoT para principiantes: Mis primeros pasos con Arduino y fue facilitada por Leo Micheloni. Este es otro de los temas que tenía pendiente hace muchísimo tiempo. La sesión estuvo excelente, los asistentes nos repartimos en varias mesas (entre 4 y 6 por mesa) y Leo nos repartió un kit de Arduino y unos pendrives con el SDK para instalar. Inicialmente hizo una explicación general y luego pusimos manos a la obra armando distintas configuraciones sobre la plaqueta y programando distintas «lógicas» usando: leds, pulsadores, sensores de proximidad, etc, etc. El modelo de programación y «ensamble» de Arduino es realmente muy simple.

Las sesiones 3 y 4 fueron como «hermanas»: primero Asp.Net & ReactJS y luego Asp.Net Core & Angular 2. Estas sesiones estuvieron a cargo de Mariano Vazquez y Nico Bello respectivamente (dos miembros de la familia FIUBA, ¡que chico parece el mundo a veces!).  Desde el punto de vista del contenido y la dinámica, ambas sesiones estuvieron muy bien.

Ya cerrando el día participé de la sesión de MauroG y RodolfoF sobre Asp.Net Core en Linux. La sesión estuvo bien pues el ejemplo sobre el que se trabajó cubrió la un caso web típico de punta a punta: UI-Controllers-Models-DB.

Al finalizar la última sesión, ya eran más de las 21, ¡upa! vaya que fue un día intenso y aún quedan dos días más  😉

Semana de NetConfUY y otros en Uruguay

Esta semana estaré en Uruguay con motivo de la NetConfUY, el evento de tecnología .Net más importante de la región. La agenda pinta muy interesante, va desde: .Net Core, a IoT pasando por contenedores, la nube, big data y Xamarin. Me llevé una agradable sorpresa al ver entre los oradores a varios ex-compañeros de trabajo como Nico Bello, Mariano Vazquez y Edu Mangnarelli y algunos otros viejos conocidos del medio local como Leo Micheloni y Diego Gonzalez.

Aprovechando el viaje voy a realizar algunas otras actividades: por un lado voy a dictar mi Taller de Prácticas DevOps junto con mi amigo @PabloLis y voy estar hablando sobre Continuous Delivery a gran escala en el Meet up de AgilesUY.

meetup_uy

Oportunidad laboral para programadores .Net

El proyecto en el que estoy trabajando viene bien. Nuestro cliente está contento y tiene una gran proyección de negocio, por ello ha decido expandir el equipo. Es por ello que estamos buscando Desarrolladores con experiencia en .NET.

El contexto del proyecto es:

  • Dinámica de trabajo XP-like
    • iteraciones cortas
    • tdd
    • integración continua
    • deploy frecuente y automatizado
    • alto involucramiento del cliente
    • test automatizados
  • Stack .Net 4.5
    • WebApi
    • NHibernate
    • Fluent Migrator
    • Log4Net
    • Swagger
  • Herramientas de soporte
    • Git
    • Jenkins
    • NuGet
    • Nexus
    • MSBuild
    • Jira

Más detalles en privado. Interesados contactarme.

Configuring Jenkins Authentication with Auth0

The procedure described here is based on Jenkins 2.7.4 but I think it should also work with other (not so distant) versions.

First of all, log into your Auth0 account.

Then create a new client application («Clients» item in left-hand menu).

auth0_1

In  the «Create Client» dialog set the name of your client application (for example «MyJenkins«) and choose the application type «Regular Web Applications«, finally click «Create«.

auth0_2

Once the application is created, go to «Settings» and set the value of the «Allowed Callback URLs» to «http://YOUR_JENKINS_URL/securityRealm/finishLogin«. Click «Save Changes«.

auth0_4

Scroll down to the «Advanced Settings» section, click on «Endpoints«. Take the SAML Metadata URL and save the content in that URL into a file (remember this file because we will use it later when configuring Jenkins).

auth0_9

Go to the «Addons» tab and enable «SAML2» option.

auth0_5

In the Addon configuration dialog edit the settings to set the «audience» and «recipient» values to «http://%5BYOUR_JENKINS_URL%5D/securityRealm/finishLogin«.

auth0_6

Click «Save» and close de dialog. Now you should see the SAML2 option is enabled.

auth0_7

 

That’s all on Auth0 size, now let’s work on Jenkins.

To perform the following steps, you need to be logged in with a user with administrator profile. I assume the reader is already familiar with Jenkins so the instructions won’t be so detailed.

First of all we need to install the «SAML Plugin«.

auth0_8

Once the installation is ready go to «Manage Jenkins > Configure Global Security«. In the «Security Realm» pick «SAML 2.0» and in the «IdP Metadata» box paste the content of metadata file you saved on before.

Scroll down to the «Authorization» section and ensure the option «Logged-in users can do anything» is selected (authorization  is something we will work on later). Scroll down to the bottom of the page and click «Save«.

That’s all.  Close the browser [*] and the next time you try to log in you will be redirected to Auth0. Now every user enabled in your Auth0 account will be able to log into Jenkins.

In the next article I will explain how to configure authorization.

[*] at the moment of this writing there is bug in the SAML plugin that affect a logout feature https://issues.jenkins-ci.org/browse/JENKINS-37311.

projifm: fin de primera iteración

El lunes pasado completamos la primera iteración con un muy buen desempeño. A pesar de haber sufrido retraso por parte de un proveedor externo de una API logramos entregar toda la funcionalidad comprometida, solo nos quedó pendiente una tarea relacionada a una aplicación legacy con la que debemos integrarnos.

Me sentí muy cómodo con la estructura del equipo: 3 devs (yo entre ellos) + 1 tester + 1 facilitador + PO (+ 1 persona en tareas de infraestructura con dedicación parcial).  La forma en que trabajamos es bastante aproximada a lo propuesto por XP. Entre las prácticas que utilizamos están: daily stand ups, reunión de planificación, reunión de review, retrospectivas, #noEstimates, product backlog, spikes, pruebas automatizadas, deploy automatizado, mob-programming, collective ownership, control de configuración, TDD (poco pero en ascenso), versionamiento de base de datos, etc.

Entre los temas a mejorar surgidos en la retrospectiva estuvieron:

  • Mejorar el flujo de release: nos pasó que varios de los items del backlog se estiraron durante varios días y luego los cerramos «todos juntos» hacía el final de la iteración. Esto generó que el burn-down chart tenga una meseta importante.
  • Mejorar la interacción con nuestro «DevOp» pues tuvimos algunas fricciones consecuencia de la falta de claridad en algunos acuerdo de trabajo (lo pongo entre comillas pues considero que DevOps es más un mindset que un rol)

Aplicaciones legacy, monolitos y micro-servicios

Una plataforma desarrollada durante varios años sin prestar mayor atención a a algunas buenas prácticas de desarrollo (integración continua, test-automatizados, trazabilidad de artefactos, control de la configuración, separación de ambientes, etc). Desarrollada por una software factory externa a la organización.

En un momento la organización decide cambiar de software factory y es ahí donde entramos somos.

Nos encontramos con una plataforma legacy, con arquitectura monolítica, issues de performance, corriendo sobre máquinas físicas (nada de cloud, ni virtualización), sobre la que el cliente espera que agreguemos nuevas funcionalidades. La visión es ir hacia una arquitectura de micro-servicios corriendo en la nube. Este desafío nos plantea una seria de interrogantes:

  • Cómo organizar el equipo para poder dar soporte a la plataforma actual y al mismo tiempo desarrollar nuevas funcionalidades
  • Cómo mitigar los riesgos de introducir modificaciones sobre una plataforma legacy
  • Cómo vivir en una infraestructura mixta cloud  y on-premise
  • Cómo mantener la motivación al trabajar sobre código legacy/frágil escrito por terceros
  • Cómo introducir la nueva arquitectura basada en nuevas tecnologías de una forma no disruptiva para el negocio y los usuarios

Esta es la situación que estoy afrontando en mi proyecto actual y es también la temática de una charla/presentación que en la que empecé a trabajar esta mañana.

 

Reclutando programadores: juniority

Reclutando programadores: juniority

¿Cuantas veces te cruzaste con alguien supuestamente de cierto nivel de «seniority» que estuvo por encima de las expectativas para ese nivel? Yo creo que muy pocas veces. En general creo que la situación más común es la inversa: quien en los papeles es nivel X , en la práctica termina siendo nivel Z (siendo Z < X). Es por esto que cuando tengo que hablar de seniority prefiero utilizar el término juniority, ¡ja!.

Más allá del chiste, creo que los niveles de seniority/juniority son clasificaciones bastante inútiles en la mayoría de los casos. Las clasificaciones tienen utilidad cuando cada clase tiene un significado universal que permite establecer un lenguaje común. El nivel de seniority suele asociarse a la experiencia. El problema es que no hay un acuerdo universal respecto de cuanta experiencia se requiere para cada nivel de seniority. Para CESSI por ejemplo, senior implica más de 4 años de experiencia, pero conozco de organizaciones en las que se requiere más de 6 años para ese mismo nivel.

Pero aún pudiendo lograr un acuerdo universal sobre la cantidad de años de experiencia de cada nivel de seniority, hay algunas otras cuestiones a considerar:

  • el tiempo que se realiza una actividad de índole intelectual no resulta necesariamente proporcional al nivel de maestría de la persona en esa actividad.
  • en muchos casos resulta más relevante la cantidad de experiencias que la duración de la experiencia. No es lo mismo una persona que durante 6 años trabajó tan solo en 2 proyectos que una persona que en 3 años trabajó en más de 10 proyectos. Yo creo que en la mayoría de los casos preferiría a esta segunda persona.
  • finalmente hay otro conjunto de factores que suelen influir en la determinación del seniority, cuestiones tales como aptitudes, habilidades y conocimiento, temas que trataré en el siguiente artículo.

continuará…

Reclutando programadores: perfiles

Para algunos el término «programador» no resulta apropiado para describir a aquellos que desarrollan software de forma profesional, por el simple hecho que la actividad de programar es solo una parte de lo que hay que hacer. Un término mucho más aceptado es «desarrollador». Pero  incluso hay empresas que prefieren hablar en formal general de «Ingenieros», independientemente de que una persona tenga formalmente ese título académico.  A propósito de esta diversidad de terminología, hace un par de años la Cámara de Empresas de Software y Servicios Informáticos de Argentina (CESSI) llevó adelante una iniciativa para «estandarizar» los perfiles informáticos. Esta iniciativa derivó en La guía de perfiles ocupacionales de TI. Si bien desconozco cuán utilizada es esta guía en la actualidad por las empresas del sector, creo que resulta un buen punto de partida para hablar sobre perfiles informáticos.

Esta guía no menciona explícitamente un perfil de programador. Los roles más «cercanos» que menciona son: Desarrollador de Software y Arquitecto de Software. Personalmente me gusta la descripción de los perfiles, creo que es bastante completa aunque algunos detalles que me llamaron la atención:

  • En el caso del arquitecto se menciona explícitamente entre sus habilidades «Pasión por la tecnología». Esto me parece fantástico pero me llama la atención que tal característica no figure entre las del desarrollador. No digo que este bien ni mal, simplemente me llama la atención y me hace pensar, en este momento no tengo opinión formada al respecto.
  • Creo que nunca me convenció la idea de «EL arquitecto» (a pesar de haber tenido ese «título» en uno de mis trabajos). Pero creo que de aceptar la existencia de dicho perfil imagino que es naturalmente un perfil senior. Sin embargo la guía de CESSI propone dos niveles de arquitecto: semi-senior y senior.

Este último punto abre la puerta para hablar sobre «seniority», pero eso será parte de otro post ya que es un tema para hablar largo y tendido.

Continuará…