PCE-Evolution: An infrastructure pattern

Beyond which environments I use on different project/organisation there is one recurrent strategy that I have applied several times in different context. I may say it is a pattern.

The problem

Like any pattern explanation it should start with a problem, so here it is: it is very common production environments to be large in term of hardware capacity and also in size of data. This makes difficult (and/or very expensive) to replicate the production environment to test your application. If you test in an environment different from the production environment you are taking a risk, and the bigger the difference is the higher the risk you are taking.

The solution

Your application pass through different environments from you local development machine to the final production environment.  These two environments are the extremes of your pipeline, so you should make use that each intermediate environment is “closer” to the production environment.

Example

Local development environment (your workstation): here you run the whole application in an isolated way, you have a local DB installed and external services dependencies may be mocked. Your hardware is not comparable to production’s hardware. Even your OS may be different: you may use Windows 10 or Mac or Ubuntu Desktop, while your production server may run Windows Server or Ubuntu Server. In terms of the previously mentioned dimensions, all of them are different from production.

Development environment: your hardware is still far from production, but at least you have the same OS asp production but the other dimensions are still different.

Test Environment: here your layout is the same as production, that is: if you have a cluster for the production DB, then you also have a cluster for test DB but possibly your test DB cluster has less servers that the production one.

This way the closer to production the more Production-like, Complex and Expensive.

infra_pattern

Convocatoria de autores para el libro del AOC 2017

Como ya mencioné hace un tiempo, este año quiero editar el tercer libro de la colección AOC para así completar la trilogía.

Dado que este año habrá 2 AOC (por cierto esta semana comenzó el proceso de inscripción/postulación para el AOC de Chile) mi idea es que el libro contenga capítulos de autores participantes de uno y otro AOC.

La dinámica de escritura será igual a los casos anteriores, en el sentido que serán capítulos independientes pero respetando una estructura mínima. En cuanto a la consigna, la idea es escribir ensayos/reflexiones/opiniones.

Dicho todo esto, abro la convocatoria de autores para este tercer libro. Los requisitos son simples: participar de al menos uno de los AOC 2017 y comprometerse a entregar el capitulo “release candidate” un semana antes del AOC en que se piense participar.

A los interesados en sumarse a esta iniciativa les pido que por favor:

Una visión formal/académica sobre DevOps

Ayer por la tarde “me interné” en un local de Barnes&Noble y recorriendo la sección de libros de tecnología me encontré con un libro cuya existencia desconocía: DevOps, a Software Architect’s Perspective de Len Bass y Cía.

Apenas leí el índice no dudé ni un instante en comprarlo ya que es el primer libro que veo sobre esta temática de una fuente “formal/académica” como es el SEI-CMU.

Anoche empecé a leerlo y por el momento pinta muy interesante.

devops_book_sei

Estadísticas personales 2016

Desde que comencé a trabajar en forma independiente registro con bastante detalle el tiempo que dedico a mi actividad profesional y dado que me gustan las estadísticas y el cierre de año parece un momento propicio para actualizarlas.

Durante 2016 hice un cambio relevante en la utilización de mi tiempo motivado principalmente por tomar un cargo de mayor dedicación en la Universidad. Analizando mi registro de horas los números indican que mi dedicación industria/academia fue 60/40.

2016_industria_vs_academia

Del análisis se desprende también que el promedio de horas trabajadas semanalmente (industria + academia) suma 32 horas semanales. Aquí hay algunos puntos a tener presentes:

  • El trabajo en la academia tiene “pozos y picos”, por ejemplo durante enero/febrero la actividad es muy baja debido a que no hay clases, mientras que durante diciembre y julio/agosto suele haber picos debido al cierre de cuatrimestre.
  • Las horas aquí contabilizadas del trabajo en la industria son solamente las horas facturables. Cuando uno trabaja en proyectos de desarrollo el total de las horas dedicadas son facturables, pero cuando los proyectos son de consultoría/capacitación hay algunas horas que no se facturan (típicamente las dedicadas a la pre-venta)
  • No están reflejados en el registro de horas las cuestiones de “formación, marketing y similares”, o sea: los cursos, conferencias y charlas a los que asistí, ni tampoco las lecturas ni las katas que realicé, ni mucho menos el tiempo dedicado a pre-venta, ni a escribir en este blog, ni tampoco los cursos que armé y dicte en empresas. Al mismo tiempo cabe destacar que muchas de estas actividades no son exclusivamente académicas ni industriales pero sin embargo aportan a ambas dimensiones ya que en mi caso particular ambas dimensiones están enfocadas en la misma área de conocimiento: ingeniería de software.

En base a lo puntos anteriores se desprende que en realidad dedico más de 32 horas promedio por semana a mi actividad profesional, la pregunta que surge entonces es: ¿cuantas horas trabajo por semana? La respuesta no es trivial, como indica un viejo dicho “búscate un trabajo que te apasione y no trabajarás nunca más“, puede sonar a chiste pero es mi realidad. De todas formas quiero intentar dar una respuesta a esta pregunta. En términos generales dedico a mi actividad profesional el horario típico de oficina o sea de lunes a viernes de 9 a 18, a excepción de los martes por la mañana y viernes por la tarde que intento dejarlos libre.  Pero al mismo tiempo dos veces por semana dicto clases en la universidad después de las 18. Finalmente los sábados por la mañana por la mañana también los dedico a cuestiones profesionales, generalmente lecturas relacionadas a mi proyecto de investigación. Con lo cual en términos generales dedico unas ~44 horas a cuestiones profesionales, lo cual implica unas ~12 horas típicamente no facturables directamente que suman tanto a mi actividad profesional como académica.

distribucion

Al analizar las tecnologías con las que he trabajado en este 2016 se destaca .Net, cosa que no ocurría desde 2013.

distribucion_tecnologias

 

Finalmente en lo que respecta conferencias/eventos/cursos:

  • Participé en 5 conferencias grandes, cuatro de ellas internacionales
  • Participé de  6 cursos (sin contar las sesiones de las conferencias)
  • Dicté/facilité 12 cursos/charlas

Finalmente en lo que respecta a este blog, escribí 101 artículos, prácticamente 1 cada 3 días.

Mirando en retrospectiva y comparando con años anteriores este 2016 fue un año muy intenso y el pronóstico para 2017 (al menos en los primeros meses) pinta muy parecido.

 

Agile Open Camp 2017

Agile Open Camp 2017

El año próximo habrá dos Agile Open Camps, “el tradicional” en los alrededores de Bariloche (marzo) y otro en las afueras de Santiago de Chile (mayo).

Ayer un colega me preguntaba sobre esta conferencia: “¿qué tiene de distinto?

En primer lugar lo referí a los artículos que escribí sobre el AOC en mi blog. Y luego le conté que lo más interesante a mi entender era la experiencia de participar más allá del contenido de la conferencia. A nivel contenido, creo que el evento es principalmente de índole “soft”, son muy pocas las sesiones de índole técnica y al mismo tiempo son muchas las sesiones que ni siquiera tienen que ver directamente con desarrollo de software. De todas formas como el evento es en formato Open Space, cada uno puede proponer las sesiones que guste. Algo que me resulta distintivo de este evento es la posibilidad de generar entregables concretos que trasciendan la conferencia. Esto se debe a que todos los asistentes estan alojados en el mismo lugar, compartiendo mucho tiempo y con la completa libertad que brinda un open space. En las dos ediciones anteriores yo mismo me encargué de la edición de dos libros que escribimos durante la conferencia. Para esta edición 2017 me gustaría trabajar en el tercer libro o bien en alguna pieza de software.

Esta semana comenzó el proceso de postulación para el AOC de Bariloche: http://argentina.agileopen.camp/, yo ya hice mi postulación ¿y vos?

 

 

Cierre de Ingeniería de Software en UNTreF

El cuatrimestre terminó y si bien no todo salió perfecto, estoy conforme con el resultado.

Una cuestión fundamental a mi entender para el buen fluir del cuatrimestre es que este mismo grupo de alumnos cursó conmigo el cuatrimestre anterior la materia Análisis y Diseño Orientado a Objetos. En dicha materia hicimos un gran foco en cuestiones técnicas de ingeniería de software lo cual permitió que en esta materia podamos poner más foco en las cuestiones no tan técnicas.

Comparto aquí algunos puntos destacados:

  • 10 inscriptos, 10 aprobados
  • La nota promedio de cierre de cursada fue 9
  • La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue 8,4
  • El tiempo promedio semanal dedicado por los alumnos fuera de clase fue 8 horas.
  • Tuvimos dos clases especiales a cargo de invitados: Sergio Villagra nos visitó para dar la clase de modelos de calidad y Emilio Gutter vino a contar la forma de trabajo  y organización de 10 Pines
  • La actividad de cierre de la materia (lecciones aprendidas) fue facilitada por también por Emilio Gutter.

inguntref2016

Cierre de algo3 (2016)

Terminamos un año de cambios:

  • Eliminamos la distinción clase teórica / clase práctica y pasamos a tener dos clases, ambas de índole teórico/prácticas
  • Cambiamos la dinámica de las clases a hacia un enfoque más “from the back”, algo que ya veníamos haciendo en forma más leve y este años aumentamos la apuesta
  • Como parte del punto anterior fomentamos el trabajo en clase con las computadoras, intentando programar durante la clase

Si bien conceptualmente estoy completamente convencido de que este enfoque es el más apropiado para esta materia, creo que la puesta en práctica no fue lo suficientemente buena, creo que tuvimos varias falencias de coordinación interna entre los docentes. La parte positiva es que esto nos deja un buen espacio mejorar 😉