.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.

 

Se viene Meetup polémico en Agiles@BuenosAires

El miércoles próximo en el Meetup de Ágiles@BuenosAires tendremos un jornada que en cierto modo podría considerarse polémica. Al mismo tiempo será una jornada doble: por un lado @JGabardini reeditará su sesión F*** the manifest que diera el año pasado en #Agile2015 por otro lado yo estaré hablando del movimiento de Software Craftsmanship. Ambas temáticas invitan a repensar los valores y principios de mundo Agile y la forma en que los consideramos en nuestro día a día.

La cita es el miércoles 3 de agosto a las 18.30 en las oficinas de Kleer.

Como siempre la entrada es libre y gratuita pero require registración (vía Meetup).

¡Nos vemos!

Meetup de arquitectura: academia meets community

El pasado jueves participé de una reunión del Meet up de Arquitectura de Software de Buenos Aires. La temática de la reunión fue: ¿Cómo tiene que ser una IDE para arquitectos?

El orador principal fue Victor Braverman, un reconocido investigador de la UBA.  La sesión comenzó con una exposición de Victor en la que presentó un trabajo desarrollado en conjunto con la gente de Epidata, una consultora Argentina especializada en Arquitectura de Software.  En forma resumida:

  • Victor y su equipo desarrollaron una herramienta para generar una representación visual de la arquitectura de una aplicación a partir del análisis automatizado del código fuente de la misma y de ciertas propiedades de runtime.
  • Luego utilizaron dicha herramienta en dos proyectos de Epidata y realizaron un serie de sesiones de trabajo con arquitectos de dichas aplicaciones para analizar lo generado por la herramienta
  • A lo largo de esas sesiones de trabajaro detectaron ciertas cuestiones en las que la herramienta agregaba valor

 

Luego de la exposición inicial se abrió la charla con la idea de que la audiencia diera su opinión sobre el tipo de funcionalidades / información que podría resultar útil que la aplicación ofreciera.

Lo presentado por Victor me pareció interesante al igual que lo surgido de la audiencia pero lo que más destaco es la iniciativa de este grupo de académicos de acercarse a la comunidad de práctica. No es raro ver a los académicos trabajando en conjunto con la industria, pero general esas interacciones con la industria son empresas, rara vez con las comunidades de práctica. Mis felicitaciones para Victor, su equipo y también para la gente de Epidata por esta iniciativa conjunta.

Para los interesados les dejo la grabación de la sesión que compartió  Pablo González (uno de los organizadores del Meetup)

Cierre de AyDOO 2016 en UNTreF

El cuatrimestre terminó y en mi opinión su desarrollo estuvo bastante en línea con lo planeado inicialmente.

Comenzando por los números duros:

  • Hubo 16 inscriptos, 2 de ellos nunca vieron a clase, 1 vino solo una clase y los restantes 13 completaron la cursada.
  • La nota promedio de cierre de cursada fue 7,9/10.
  • La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue de 7,5/10.

Personalmente quedé muy conforme con el desarrollo de la materia, obviamente siempre hay cuestiones que mejorar, pero en términos generales creo que la dinámica fue apropiada. Creo que el uso del campus virtual ayudó mucho a la dinámica y personalmente estoy muy conforme con la herramienta utilizada (Eliademy).

Entre los puntos positivos destacados por los alumnos estuvieron:

  • El uso de un lenguaje nuevo para ellos (Ruby), ya que hasta el momento la mayoría había trabajado casi exclusivamente con Java. Cabe aclarar que no trabajamos solo con Ruby, sino que comenzamos trabajando con Java y luego pasamos a Ruby. En este sentido varios alumnos sugirieron comenzar con Ruby mucho antes.
  • Los videos. Para varias cuestiones (principalmente de carácter técnico) compartí videos grabados por mi, que los alumnos encontraron muy útiles.
  • Los casos reales. En casi todos los temas que fuimos viendo, fui compartiendo casos reales que me he encontrado en mi carrera profesional como ingeniero.

Entre los puntos negativos a mejorar destacaron:

  • La estimación de la carga de trabajo. Inicialmente yo había estimado (y explicitado) unas 4 horas semanales de trabajo extra clase, pero según reportaron los alumnos, en promedio debieron dedicar unas 10 horas semanales.
    => Definitivamente este es un punto a mejorar y lo que pienso hacer al respecto no es modificar las tareas semanales sino simplemente comunicar que se requerirán unas 10 horas de trabajo semanal extra clase.
  • La falta explícita de recreo. Dado que la dinámica de las clases incluye actividades de trabajo, no suelo dar recreos explícitos, sino que para mi el momento de recreo es  cuando hacen las actividades. Típicamente doy X minutos para hacer las actividades y en ese tiempo son libres de tomar una porción para hacer su recreo. Fui explícito respecto a esto pero evidente a los alumnos no les gusta y quieren que de un recreo explícito.
    => Sinceramente no estoy convencido de cambiar esto, pero es algo que evaluaremos en la próxima edición. Una opción que estoy barajando es dar un recreo de 10 minutos pero que sean los propios alumnos quienes lo pidan explícitamente en cada clase y si nadie lo pide, entonces posiblemente no se haga.

Finalmente hubo algunas opiniones contradictorias de los alumnos respecto del nivel de exigencia. Si bien hubo coincidencia en que el nivel de exigencia fue alto, algunos lo consideraron muy positivo mientras que otros lo consideraron negativo.

aydoo2016

Actividad extra-curricular @UNTreF: Desarrollo con Vagrant

Este Jueves 28 de Julio voy realizar una actividad extra-curricular en @UNTreF. Se trata de una sesión acerca de Vagrant, una poderosa herramienta para manejo de ambientes virtualizados.

Creo que Vagrant puede resultar una herramienta muy útil para los alumnos que deban cursar materias de programación avanzada. La cuestión es: en las materias de programación básica, típicamente basta con instalar un IDE (tipo Eclipse) y listo, no se requieren herramientas adicionales. Pero en las materias más avanzadas típicamente hay que utilizar algunas herramientas más, como kits de desarrollo (SDKs), bases de datos, web servers, etc, etc. Es ahí donde el uso de Vagrant puede simplificar mucho la preparación del ambiente.

La idea de esta sesión es hacerla online vía Google Hangouts y con participación activa de la audiencia, o sea: la sesión mezclará explicaciones con consignas que los alumnos realizarán en sus propias máquinas. Para esto los alumnos participantes deberán tener instalado en sus máquinas Git, Virtual Box y Vagrant.

Si este primer experimento funciona relativamente bien puede que sea el punto de partida para un conjunto de actividades de capacitación online. Veremos

Preparando Ingeniería de Software 2016 @ UNTreF

En segundo cuatrimestre de 2016 dictaré la materia Ingeniería de Software junto a mi colega el ingeniero Pablo Tortorella (@pablitux). De cara a facilitar a los potenciales alumnos la organización de su cuatrimestre queremos compartir algunas cuestiones referentes a la dinámica de la materia para esta edición 2016.

  • La materia se dictará los jueves de 18 a 22 (si, jueves) en la sede Lynch.
  • Más allá de la asistencia formal requerida por reglamento, recomendamos fuertemente la asistencia a clase.
  • La dinámica de evaluación será continua: tareas semanales + trabajo práctico final (últimas 5 semanas del curso).
  • Utilizaremos una herramienta virtual de soporte para centralizar la publicación, entrega y evaluación de tareas. Las tareas serán principalmente lecturas + cuestionarios + ejercicios de programación.
  • Trabajaremos con GNU+Linux (obligatorio) y Ruby.
  • Estimamos que la carga de trabajo extra clase será aproximadamente de 6 horas semanales (aunque puede que sea un poco mayor durante el desarrollo del trabajo final).

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: