.Net Core: lo que MS no te contó

Si uno se pone a investigar sobre .Net Core encontrará que en la mayoría de las fuentes se destacan las siguientes cuestiones:

  • La posibilidad de correr de fuera de Windows, más concretamente en Linux y Mac.
  • La nueva .Net Standard Library y su objetivo de “unificar” el mundo del desarrollo .Net proveyendo verdadera portabilidad entre las distintas plataformas .Net.
  • La intención de tener un sistema mucho más modular, basado en la idea de un Core realmente pequeño y la capacidad de cargar módulos adicionales según se requiera, usando el gestor de paquetes NuGet.
  • Una nueva experiencia de usuario para el desarrollador basada en un nuevo set de herramientas en el que se destaca Visual Studio Code.

Si bien considero que todos estos puntos son muy relevantes, creo que el primero tiene un impacto grandísimo pero que curiosamente no parecer estar proporcionalmente publicitado. Por lo que vengo leyendo la capacidad de correr fuera de Windows “es vendida” desde el punto de vista de desarrollo: “ahora podes codear .Net en Linux”. Pero a mi me parecer el mayor impacto de esta nueva capacidad no es tanto en desarrollo como en operación/producción, o sea: es posible hacer aplicaciones .Net y ponerlas a correr en un ambiente productivo Linux.

Tal vez esto no sea precisamente lo que más le interesa a Microsoft del nuevo .Net, pero definitivamente es lo más me interesa a mi😉

Algunos pensamientos sobre deportes, deportistas y habilidades

Cada deporte tiene un conjunto de reglas y un conjunto de técnicas/fundamentos para su práctica. Tomemos el ejemplo del tenis: una regla dice que hay dos oportunidades para ejecutar el saque. Al mismo tiempo existen diversas técnicas concretas para ejecutar el saque y que están determinadas en base un conjunto de cuestiones como ser: a la forma de lanzar la pelota, la posición de los pies, la flexión de las rodillas y el movimiento del brazo, muñeca y raqueta. En base al dominio de las reglas y las técnicas es posible distinguir distintos niveles de “habilidad” de los jugadores:

  • Autodidacta: en general conoce las reglas, pero su dominio de la técnica es limitado, en general porque no tuvo un entrenamiento formal o bien porque con el entrenamiento que tuvo no logró el completo dominio de la técnica.
  • Federado: el término obedece al hecho que ha participado (y/o participa) representando a alguna institución (club o escuela) en una competencia perteneciente a una federación/asociación. Ha recibido ha cierta instrucción sobre las técnicas y las reglas, conoce y domina hasta cierto punto (o está aprendiendo a dominar) la técnica. La principal diferencia con el autodidacta es la formación.
  • Profesional: es un federado pero con una habilidad mayor en el sentido que domina mejor la técnica y al mismo tiempo conoce más técnicas. Tiene una gran preparación física y en general la práctica del deporte es su medio de vida.

Al pensar en esta clasificación veo cierta similitud con el concepto Shuhari proveniente de las artes marciales y que Alistair Cockburn extrapoló al mundo del Software. Sin embargo creo que el mapeo no es directo. El nivel shu incluiría a los autodidactas y también a los federados principiantes, mientras que el nivel ha incluiría a los federados avanzados y finalmente el ri podría incluir a los profesionales.

Durante mi adolescencia practiqué varios deportes con distinto nivel de intensidad y “habilidad”: fútbol, voley, handball, tenis, paddle y basket. Si bien recibí cierta instrucción en todos ellos, solo en el caso de basket llegué al nivel federado. Hoy en día sigo practicando basket y si bien mi estado físico es bastante más pobre que en mi adoslescencia creo que mi manejo de los fundamentos persiste igual. Como suele decirse en me barrio “uno nunca se olvida como andar en bicicleta“.

Un año de investigación UNTreF

Esta semana está terminando el cuatrimestre en UNTreF (ayer fue la última clase de Ingeniería de Software) y me parece un momento apropiado para repasar lo que ha sido para mi este primer año de trabajo en investigación.

Si bien las primeras charlas del proyecto fueron a fines del año pasado, no fue hasta Enero que comenzamos a trabajar formalmente. Prácticamente todo trabajo de todo este año estuvo centrado en actividades de formación y en la realización de un primer estudio de índole exploratoria sobre el uso de prácticas en la comunidad ágil.

Este estudio tomo la forma de una encuesta la cual realizamos en el contexto del Agile Open Camp 2016. Luego de realizada la encuesta pasamos un buen tiempo analizando los datos recogidos y finalmente escribimos paper compartiendo nuestros hallazgos.

Respecto de la actividades de formación yo personalmente participé de las siguientes:

  • Seminario de Introducción a los métodos experimentales de investigación en Ingeniería de Software, dictado por Alejandro Oliveros de la Universidad Nacional de Tres de Febrero (quien es al mismo tiempo el director de nuestro proyecto de investigación)
  • Taller de redacción de tesis, dictado por Zulma Cataldi (Universidad Nacional de La Plata)
  • Curso Empirical-Based Software Engineering, dictado por Marcela Género (Universidad de Castilla La Mancha)
  • Seminario Estructura de los Artículos Científicos, lineamientos generales para la escritura de un paper, dictado por Carlos Neil (Universidad Abierta Interamericana)

Por otro lado participé de los congresos:

  • International Conference on Agile Software Development, XP 2016.
  • Congreso Nacional de Ingeniería Informática / Sistemas de Información, CONAIISI 2016.

En el primero estuvimos dando un Taller sobre Modern XP mientras que en el segundo fue donde presentamos el paper resultante de nuestra investigación. La semana próxima se publicarán las memorias del congreso en las cuales estará disponible nuestro trabajo.

Personalmente estoy muy conforme con este primer año de trabajo, ha sido una experiencia muy interesante y espero que el año se ponga aún mejor.

 

Notas del CONAIISI 2016

Notas del CONAIISI 2016

Jueves y viernes pasado estuve participando de este congreso que se llevó a cabo en la ciudad de Salta. Llegué a la ciudad el día anterior y estuve dando una charla abierta en la Universidad Nacional de Salta. Hubo unos 25 participantes entre los cuales se contaban alumnos avanzados, graduados, docentes y particulares. Aquí están las diapositivas que utilicé. Le agradezco a Loraine Gimson que fue quien se encargo de la organización de la actividad.

Ese mismo día por la noche compartí la cena con el Ing. Guillermo Pantaleo, un colega de FUIBA que fue docente mío y con quien tuve el gusto de trabajar un cuatrimestre. Él también estaba en Salta para participar del congreso.

El Jueves comenzó el congreso. Quedé impresionado por la gran cantidad y diversidad de asistentes. Más allá de los locales del norte del país había varios grupos grandes de Buenos Aires, Santa Fe y Córdoba y también gente de Cuyo, la Mesopotamia y la Patagonia, muy federal sinceramente.

El congreso se realizó en el campus de Universidad Católica de Salta que está ubicado en las afueras de la cuidad, hermoso, pastito muy cuidado, árboles, cerros alrededor, todo muy limpito y ordenado.

El jueves por la noche fue la cena de camaradería en un lugar llamado “La Peña de los Gauchos Güemes” que según, cuentan su construcción es un réplica de la histórica Posta de Yatasto. En la cena compartí la mesa con: una estudiante de la Nacional de Rosario, un estudiante de UTN.LaPlata, dos profesoras de UCASAL y un profesor/investigador de la Nacional de Avellaneda, cuyo trabajo de tesis yo había leido cuando trabajaba en mi tesis de grado sobre programación orientada a aspectos, ja!.

Entre las sesiones que más me gustaron estuvieron:
  • Un taller que dictó Carlos Neil (de la UAI) sobre escritura de papers. Realmente muy bueno, tanto a nivel contenido y también a nivel orador, el tipo muy didáctico y compartió mucho tips concretos.
  • Un trabajo de gente de UTN.BA sobre desafíos de arquitectura de IoT.
  • El keynote sobre documentos electrónicos y firma digital
  • Un trabajo basado en un experimento sobre cómo TDD llega a generar menos bugs
  • Una sesión tipo Foro donde estudiantes/graduados recientes contaban sobre sus emprendimientos
  • Un trabajo del ISISTAN sobre Refactoring que presentó Claudia Marcos

Mi presentación fue el día viernes y contó con una gran asistencia (el aula estaba repleta) y por las caras y participación de los asistentes me parece que tuvo una buena llegada. Aquí están las diapositivas que utilicé durante la presentación.

Actividades en Salta

Actividades en Salta

Esta semana estaré de visita en Salta para participar del cuarto Congreso Nacional de Ingeniería Informática / Sistemas de Información  (CONAIISI) donde estaré presentado el trabajo realizado sobre prácticas ágiles en el contexto de nuestro proyecto de investigación en UNTreF.

Adicionalmente este miércoles 16 de estaré dando una charla abierta en la Universidad Nacional de Salta en la que hablaré sobre prácticas de ingeniería actuales en el desarrollo de software (automatización de tests, tdd, integración y despliegue continuos, devops, modern XP, etc). Los interesados en asistir pueden ver más información y anotarse aquí, ya que si bien el acceso es gratuito se require registración previa.

Luego de la charla mi agenda está libre así que encantado de compartir unos tragos con quienes gusten sumarse🙂.

 

Una alternativa al Double Dispatch

Double Dispatch es un patrón de diseño para resolver situaciones en las que el comportamiento resultante no depende solamente del objeto que recibe el mensaje sino también de parámetro enviado en ese mensaje. Veamos un caso concreto para entender mejor esta situación.

Supongamos que debemos modelar un juego de naves espaciales tipo Galaga donde tenemos distintos tipos de objetos espaciales como ser Naves, Estaciones y Asteroides. Estos objetos pueden colisionar entre si y el resultado de dicha colisión depende particularmente de quienes son los objetos involucrados y del estado de los mismos. Veamos un ejemplo:

  • Si una nave colisiona con un asteroide la nave es destruida (vida = 0) y el asteroide disminuye su velocidad en 3 unidades
  • Si una nave colisiona con una estación a baja velocidad (velocidad < 10), entonces la nave se detiene (velocidad = 0) y la estación no sufre ningún cambio de estado
  • Si una nave colisiona con una estación a alta velocidad (velocidad >= 10), entonces la nave es destruida (vida = 0) y la estación disminuye su vida en 4 unidades.

Una solución trivial podría ser que cada objeto tenga un método “collideWith” en el que se verifique contra quien está chocando y se actúe en base a ello:

// SpaceShip
public void collideWith(SpaceObject otherObject) {

    if (otherObject.getClass() == Asteroid.class) {
        this.life = 0;
    }

    if (otherObject.getClass() == Station.class) {
        if (this.speed < 10){
            this.speed = 0;
        }
        else{
            this.life = 0;
        }
    }
}

Código completo Java de esta solución disponible aquí.

spacewar_trivial

Las clases Asteroide y Estación tendrían métodos análogos.
Si bien esta solución funciona, resulta un poco “rústica” en términos de Orientación a Objetos porque viola algunos principios de diseño, entre ellos viola el principio abierto-cerrado, ya que en caso que aparecer un nuevo tipo de objeto (como por ejemplo Cometa) habría que modificar cada uno de los métodos CollideWith para contemplar los nuevos casos.

Es aquí donde el Double Dispatch nos propone una alternativa un poco más elegante. La idea es que cuando un objeto recibe una colisión, delega la resolución al otro objeto invocando a un método más concreto como se muestra en el siguiente fragmento de código:

// SpaceShip
// Dado que aquí "this" es SpaceShip, se terminará ejecutando
// el método collideWith(SpaceShip) del otherObject
public void collideWith(SpaceObject otherObject) {
 otherObject.collideWith(this); 
}

protected void collideWith(Asteroid asteroid) {
 this.life = 0;
}

protected void collideWith(Station station) {
 // do something
}

protected void collideWith(SpaceShip ship) {
 // do other something
}

Código completo Java de esta solución disponible aquí.

spacewar_doubledispatch

Esta solución implica que cada clase tendrá un método collideWith por cada clase con la que pueda llegar a colisionar. En este caso particular donde tenemos 3 clases, tendremos 9 métodos (dependiendo del comportamiento particular que definamos para resolver la colisión podríamos tener tal vez algunos métodos menos).  En cierto modo esta solución también viola el principio abierto-cerrado, porque en caso de aparecer un nuevo tipo de objeto es necesario modificar todas las clases para agregar un nuevo método que resuelva la colisión aunque a diferencia de la solución anterior, aquí no modificamos un método existente sino que agregamos un nuevo método, lo cual es menos rústico.

Finalmente la solución a que mi gusta para esta situación entra en la categoría que Steve McConnell denomina Table-Driven methods (capítulo 18 de libro Code Complete). La idea es emular una tabla de métodos virtuales que es lo que usan algunos lenguajes a bajo nivel para resolver el late binding. Más concretamente lo que se hace es que cada objeto tenga una tabla o mejor dicho un diccionario (collisionMap) donde la clave es la clase contra la cual colisiona y el valor es un closure/lamba con la lógica a ejecutarse al colisionar contra ese tipo de objeto. Implementar esto en Smalltalk y/o Ruby es trivial, pero en Java tiene una vuelta de rosca extra, simplemente por la forma en que se implementan los lambdas en Java.

// Cuando se crea el objeto debe inicializarse el collitionMap
protected void initCollisionMap() {
    collisionMap = new HashMap<>();
    collisionMap.put(Asteroid.class, (x) -> collideWithAsteriod(x));
    collisionMap.put(Station.class, (x) -> collideWithStation(x));
}

// Este el punto de entrada en la colision
// Notar que la busqueda en la tabla es polimorfica
public void collideWith(SpaceObject otherObject) {
 CollitionHandler handler = this.collisionMap.get(otherObject.getClass());
 handler.collideWith(otherObject);
}

private void collideWithAsteriod(SpaceObject other) {
 this.life = 0;
}

private void collideWithStation(SpaceObject x) {
   // do something
}

Código completo Java de esta solución disponible aquí.

spacewar_table

A la hora de agregar un nuevo tipo de objeto, esta solución requiere agregar una nueva entrada al collisionMap y un nuevo método si es que la interacción con este nuevo tipo de objeto es distinta a las ya existentes. Otro punto interesante de esta solución es la posibilidad de variar el comportamiento de cada instancia de la misma clase, ya que el collisionMap puede alterarse en tiempo de ejecución.

Continuará…

Developing .Net on Mac

Developing .Net on Mac

I am not talking about .Net Core that runs on MacOS out-of-the-box. I am talking about .Net Framework 4.5 that only runs on Windows. This means that you need a Windows installation.

One option is to install Windows directly on Mac hardware, but this was never an option for me.

So the other option is to virtualize Windows. But this option implies 2 more concerns: which virtualization technology to use and which Windows version to virtualize.

Regarding virtualization I am using Oracle Virtual Box, it is free, works fine and I have been using it for years, so I didn’t even try other tool.

Regarding Windows, I tried different options and finally I decided to use what  worked best for me: Windows 7 (64 bits) but with an “special setup”: no antivirus and updates turned off.

And finally, beyond Visual Studio and the usual stuff for .Net development I added the following software:

  • Cmder, a great console emulator
  • Notepad++, a lightweight file editor
  • FireFox, the browser