Proyecto T: definición de tecnología

Hace un tiempo empecé a trabajar con un conjunto de alumnos de UNQ en su trabajo final de carrera. El mismo consiste en la construcción de una aplicación para gestión de una sala de guardia de un hospital público.

Una de las decisiones que tenemos que tomar  al comienzo del proyecto es la tecnología a utilizar.

Intentando dejar de lado las preferencia personales, hay algunas consideraciones importantes para esta decisión:

  1. Dado que el contexto del proyecto es un institución pública donde el presupuesto es realmente acotado es necesario que la tecnología a utilizar no requiera el pago de licencias.
  2. Dado que se espera que el sistema tenga una vida “más larga” que el tiempo de desarrollo es muy posible que una vez completado el sistema, alguien más debe encargarse del mantenimiento. Sumado a que trabajeremos con alcance variable es posible que en un futuro el product owner deba conseguir más gente para agregar nuevas funcionalidades. Por esto es necesario que sea fácil conseguir programadores con conocimiento de dicha tecnología.
  3. La tecnología elegida debería estar lo suficientemente estable y contar con herramientas que faciliten la resolución de situaciones técnicamente comunes en un proyecto como el planteado y no de larga sesiones de investigación y resoluciones de problemas técnicos.
  4. Dado que seguimos estando en un contexto académico, la tecnología a utilizar debería permitirnos aplicar ciertas buenas prácticas que los alumnos aprenden a lo largo de la carrera.

Con estos puntos de partida ya podemos empezar a eliminar algunas candidatos.

  • En primer lugar podemos descartar tecnología Microsoft  por (1).
  • Al mismo tiempo y pesar de que me causa cierta pena, creo que (2) deja afuera Smalltalk.
  • Creo que (2) y (3) dejan afuera a cosas tales como Erlang

La lista de candidatos es aún bastante larga y al mismo tiempo con sólamente un lenguaje no llegamos a ningún lado. Es necesario considerar lenguaje + frameworks, lo cual nos podría llevar a la siguiente lista de candidatos:

  • Php, tal vez sea por sus orígenes “informales”, creo que las convenciones y herramientas aún no están claramente unificadas, hay varios alternativas (Symphony, Cake, etc) y a mi parecer ninguna se ha establecido. Sumado a que el lenguaje no me gusta.
  • Python + Django, lo usé y no me gustó, creo que Django tiene demasiada magia negra.
  • Java, ¡ja!  ¿cual de sus n variantes? No lo sé, creo que en un punto casi todas cumplen con las premisas iniciales. simplemente descartaría el uso de contenedores pesados (EJB).
  • Hermanitos de Java ya sea Scala o Groovy, que más allá de las particularidades que ofrecen como lenguajes, ambos proveen un conjunto de herramientas muy interesante y que simplifican varias cuestiones cuestiones cotidianas que tal vez en java requieren un esfuerzo de configuración/xml realmente pesado.
  • Ruby, Rails tiene demasiada magia negra, pero creo Padrino definitivamente es un opción válida.
  • JavaScript sin duda está en ascenso y si bien apenas he ido más allá de jquery es algo que me tienta mucho

Algo que me parece inevitable para este contexto de aplicación es el uso de Javascript del lado del cliente manejando toda la lógica de presentación y dejando en el server sólo servicios de negocio, entonces el punto sería con qué construir estos servicios.

Ahora bien, más allá de mis gustos, la realidad es que la aplicación la tienen que construir los alumnos y llegado a este punto son ellos quienes deben tomar la decisión considerando todo lo aquí expresado.

Mi recomendación para los alumnos fue: tomense un rato para googlear las cosas que aquí menciono si es que no las conocen. Si alguna de las alternativas les tienta más que otra y no la conocen, entonces bajense lo que sea necesario e intenten escribir una pruebas unitaria y hacer una página que sume 2 números. Eso debería darles cierta idea de dónde se están metiendo.

Issue with Internet Explorer 11 and Asp.Net Webforms

Some time ago Microsoft released Internet Explorer 11 and some of the users of a web applications I am working on, reported that they were not able to use the web application, they clicked some buttons and nothing happend.

After installing IE11 I was able to reproduce the issue and find root cause: asp.net was not generating the Javascript files required by the webforms controls. These strange behaviour was caused because asp.net did’t recognize the web browser that was sending the request (IE11).

This problem with a recommended solution is explained here by Mr. Hanselman.

In our case we just added a browser definition file to fix the problem. We know this is not the better solution, but we are about migrating to ASp.NET 4.5 that has a built-in fix for this  issue.

It is incredible that the same issue happened when IE10 was released.

Comienzo de nuevo proyecto, llamémosle T

En estos días estoy por comenzar un nuevo proyecto, llamémosle T. Se trata de un trabajo de inserción profesional que voy a co-dirigir con Fidel. El trabajo será desarrollado por dos alumnos de la carrera y el objetivo es construir un sistema de gestión para la sala de guardia de un hospital. El proyecto surgió a partir de una necesidad detectada por Luis, un médico, jefe de guardia de un hospital del conurbano.

Como suelo recomendar para todos los trabajo finales de carrera, la idea es gestionar el proyecto como de alcance variable, lo cual requiere una trabajo muy cercano con el product owner para asegurar una correcta priorización de funcionalidades y un rápido feedback a medida que estas se van completando.

Continuará…

 

 

Resultados del Taller de lntegración Continua

El jueves pasado hicimos en Kleer el taller de integración contínua. No tuvo tanta práctica como yo esperaba, pues hubo muchas consultas, pero creo que estuvo muy bien. Cubrimos todos los puntos del programa y atendimos a todas consultas de los asistentes.

Algunas variantes a considerar para futuras ediciones:

  • Enfocar el taller sólamente en Jenkins
  • Enfocar el taller en una única tecnología (Java , .Net, etc)
  • Hacer el taller de día completo o de dos medios días para poder hacer más práctica

Les dejo algunos frases de las encuestas de la evaluación completadas por los asistentes:

  • “Excelente las explicaciones y conocimientos expuestos”
  • “Muy bueno, si bien conocía algunas de las herramientas, vi un poco más en detalle todo el potencial de uso que tienen”
  • “Nada para agregar, el taller fue genial..”
  • “Excelente Didáctica y cobertura del tema”

Impresiones de la RubyConfAR 2013

La semana pasada participé por primera vez de la RubyConf. Los comentarios que recibí de algunos colegas sobre las ediciones anteriores me entusiasmaron mucho y por ello decidí anotarme.

Para quienes nunca han asistido comienzo describiendo el formato de la conferencia. La conferencia en sí son 2 días a los que se le suma un preludio denominado “Ruby Fun Day” en el que se dictan charlas/talleres introductorios a Ruby. Lamentablemente no pude asistir al fun day, pero de todas formas no creo que me hubiera aportado mucho, ya que tengo bastante experiencia trabajando con Ruby. Adicionalmente también suele haber alguna actividad social fuera del horario de la conferencia.

La conferencia en sí es un track único con sesiones de 30 minutos organizadas en bloques, donde cada bloque es: sesión 1 + sesión 2 + coffee break. Al mismo tiempo las sesiones suelen ser en forma de exposición, a diferencia de los eventos de agile, donde hay sesiones tipo workshop o tipo debate. Creo que justamente por estar acostumbrado a las conferencias agile, este formato me resultó  un poco pesado.

Respecto de las sesiones, me llamó la atención que más de una se enfocó en otros lenguajes (recuerdo una sesión sobre Go y otra sobre Erlang). Entre las sesiones que me resultaron más interesantes estuvieron:

  • La de @abecciu de Restorando sobre cómo resolvieron ciertas cuestiones de recolección de datos
  • La @runixo sobre IPython Notebook
  • La de @cristianrasch sobre Rack
  • La de @xymbol sobre Ruby & Unix
  • La de @kurko sobre orientación a objetos

Más allá de esto, hubo otras dos sesiones que más que interesantes yo las calificaría como muy entretenidas, en gran parte por el carisma de sus oradores. Esas sesiones fueron las de @ajlopez sobre su implementación de Ruby con C# y la de @janogonzalez sobre la bipolaridad de los programadores.