Mes: diciembre 2013

Un proyectito en PHP

En los inicios de mi carrera hice algunas cosillas con Php motivado por un curso de Php que había tomando en el Club de Programadores y cuyo instructor había sido el maestro AJ Lopez.

Hace un tiempo volví a poner mis manos en Php y me encontré con varios cambios, algunos de los cuales había escuchado pero no había tenido la oportunidad de experimentarlos.

Mi percepción es que el lenguaje ha evolucionado bastante, incorporando diversas construcciones y soporte para programación orientada a objetos.

Por otro lado veo un gran ecosistema de herramientas y frameworks que le han permitido mantenerse como uno de los principales jugadores en el ámbito del desarrollo web a pesar del gran avance de Ruby y Python.

Al mismo tiempo noto que a diferencia de lo que ocurre en Ruby y Java, la comunidad no estan del todo «alineada», hay cuestiones que no parecen estar estandarizadas y otras que a pesar de parecer estandarizadas son ignoradas por gran parte de los practicantes.

En mi caso particular resulta que desde comienzo de año venía trabajando en una organización en una iniciativa de Continuous Delivery y llegado un punto necesitamos de una herramienta para secuenciar los pedidos de despliegue a cada ambiente. Por diversas cuestiones esta organización decidió construir esta herramienta con Php usando el framework Silex. Luego de una primera versión, fue necesario realizar algunas modificaciones y agregar nuevas funcionalidades y por cuestiones de disponibilidad de tiempo, fui yo el encargado de estas cuestiones. Esta organización ha manifestado la intención de liberar está herramienta con licencia open source, por ello es posible que en breve les traiga más noticias.

Continuará…

Firefox, mi navegador de desarrollo

Desde hace ya años uso un navegador para hacer desarrollo y otro para todo lo demás.  Esto se debe a que en mi navegador de desarrollo suelo estar probando plugins de forma relativamente frecuente lo cual podría llegar a «romper» el navegador o a impactar negativamente en el comportamiento de una alguna aplicación web.

Como navegador de desarrollo uso FireFox, pues tiene una importante cantidad de plugins que me resultan muy útiles para el desarrollo web entre las cuales se cuentan SeleniumIDE, FireBug, YSlow, HttpFox y ScreenShooter.

Por otro lado, uso Chrome para todo lo demás que no es desarrollo pues me resulta muy cómoda la forma en que se integra con los servicios de Google que uso de forma cotidiana.

Un detalle adicional que no es menor, es el que hecho de que FireFox se mantiene en cierto modo «más limpio/neutro» que Chrome, ya que este último incluye cada vez más extensión particulares para integración con los servicios de Google, algo que puede ser útil para el usuario final, pero que como desarrollador comienza a hacerme un poco de ruido.

Cierre de cuatrimestre en Algo3 (2013-2)

Comienzo compartiendo algunos hechos generales que personalmente me resultan de interés:

  • Consolidamos el uso de campus virtual
  • Consolidamos el uso del sistema de corrección de TPs
  • Gran parte de los grupos pudo trabajar exitosamente con servidor de integración continua
  • Curiosamente el  curso de los jueves por la tarde tuvo record de alumnos

Ya hablando en particular del curso de los jueves por la tarde, surgieron los siguientes temas en la retrospectiva:

  • (+) Los videos explicativos
  • (+) El uso de dos lenguajes
  • (+) El uso del sistema de corrección/gestión de TPs
  • (+) El TP final
  • (-) Poco tiempo para resolver los parciales => cuestión recurrente a pesar que Carlos a intentado mejoras ya lo hablaremos en equipo
  • (-) Poca explicación sobre cómo crear elementos visuales con Java => Vamos a proveer una guía/ejemplo/video para facilitar este tema
  • (-) Que el corrector automático no corra todo el tiempo => Este un tema de infraestructura que esperamos tener resulto para el cuatrimestre próximo.

Ya en el plano personal, la experiencia con mis grupos me resulto excelente. Tuve 3 grupos que trabajaron acorde a mis expectativas, haciendo test-driven development e integración continua y cumpliendo con las fechas estipuladas. Creo que por primera vez todos los grupos a mi cargo cumplieron con la fechas estipuladas.

algo3-2013-2

Crónicas de mi regreso a .net

Como mencioné hace un tiempo, he vuelto a desarrollar código con tecnología .net después de casi 2 años.

El proyecto en cuestión consiste principalmente en mantenimiento evolutivo de una aplicación desarrollada inicialmente en 2009 con Visual Studio 2008 y varios complementos como: AjaxControlToolkit, Web Service Enhancements 3.0, Crystal Reports y Enterprise Library 3 entre otros.  Un detalle no menor es que la aplicación ha estado congelada funcional y técnicamente desde 2010, por lo que los mencionados componentes siguen aún en uso.

La aplicación consiste en un producto ofrecido como servicio y que se encuentra actualmente en funcionamiento. La empresa que desarrolló este producto/servicio fue adquirida por otro empresa más grande y a partir de esto el nuevo dueño de producto ha decidido potenciar este producto/servicio, lo cual requiere el desarrollo algunas nuevas funcionalidades y la modificación de algunas otras ya existentes.

Como parte de mi backlog de trabajo estan como puntos más prioritarios:

  1. Armar la infraestructura de integración continua y despliegue automático, de cara poder liberar funcionalidad de forma frecuente.
  2. Implementar una nueva funcionalidad estratégica para el negocio.
  3. Actualizar la solución a net 4.5 y refactorizar algunos componentes.

Respecto a (1) he logrado interesantes avances que compartí hace un tiempo en un screencast.

Respecto a (2), la funcionalidad está aún en desarrollo y me resultó muy interesante pues tuve la chance de experimentar con algunas técnicas y herramientas para trabajo con código legacy (ah, si me olvidé de mencionarlo, la solución casi no tiene test automatizados).

Sin duda una de las cosas que más interesante me resultó fue el uso de Dapper para facilitar el acceso a la base de datos. Resulta que el acceso a la base de datos estaba hecho de manera cuasi ad-hoc utilizando Ado.net, datasets y store procedures, artefactos que no me resultan para nada felices. Sumado al hecho de que la última vez que escribí SQL a mano fue en 2005, desde entonces siempre he utilizado algún tipo de ORM para todas las operaciones tipo CRUD. Esta herramienta Dapper es muy simple, básicamente provee un conjunto de métodos de extensión sobre la clase DBConnection que facilitan el mapeo de objetos. No me animo a calificarlo como ORM, pues carece de ciertas funcionalidades como lazy loading y cache, pero más allá de eso creo que es una alternativa muy interesante cuando uno tiene que trabajar sobre una base de datos ya existente. Prometo dedicar otro artículo para contar más detalles sobre Dapper.

Por otro lado, si bien utilicé la técnica de inyección de dependencias, no utilicé ningún framework para ello, pues en el contexto de la funcionalidad que desarrollé introducir un nuevo framework era más complejo que  resolver la inyección de forma manual.

Cierre de cuatrimestre en UNQ, quinta promoción

La semana pasada terminó el cuatrimestre en UNQ y con ello mi quinto cuatrimestre dictando Elementos de Ingeniería de software.

Este cuatrimestre tuvo algunas particularidades entre las que destaco 2:

Respecto del cuatrimestre anterior la materia no tuvo cambios significativos, pues si bien se sumó Pablo, ya nos conocíamos desde hacía años y compartimos la misma filosofía en lo que respecta a los temas de la materia.

Un cambio que sí me pareció muy importante fue el contar con un espacio en el campus virtual de la universidad. Esto nos sirvió para compartir el contenido y también para realizar algunas actividades complementarias a las clases presenciales.

Otro cambio positivo fue el uso de videos para explicar algunas cuestiones técnicas que no son el foco de la materia. Así logramos utilizar mejor el tiempo de clase.

Entre los puntos que surgieron en la retrospectiva de la materia se destacaron:

  • Es muy distinto cuando damos feedback por mail a cuando lo damos en persona => reemplazar el feedback via mail por feedback en video
  • Algunas de las clases con formato «clase magistral» resultaron poco entretenidas => intentar cambiarlas por clases con dinámicas o al estilo «from the back»
  • En algunas clases comenzamos haciendo un ejercicio de relajación lo cual gustó mucho => hacerlo más seguido
  • Enviar tareas lo más temprano posible
  • Mantener los videos sobre temas técnicos
  • Mantener las clases con dinámicas
  • Mantener el uso de la máquina virtual para simplificar la configuración de ambiente y herramientas
  • Mantener las visitas de gente de la industria.

Para cerrar comparto algunos números frios:

  • Alumnos anotados: 9
  • Alumnos aprobados: 8 (el alumno que abandonó lo hizo la tercer semana de clase debido a que sufrió un accidente que impidió asistir a clase por un período prolongado)
  • Nota final promedio: 8,5
  • Total de clases: 31
  • Visita de profesionales de  la industria: 2, DiegoF y Fer Di Bartolo (¡gracias muchachos!)

eis-5-cohorte

Taller de Prueba Automatizada

El martes pasado participé del dictado de este taller junto con @jgabardini. Me gusto como salió, pero al igual que en otras ocasiones, creo que nos quedamos cortos en el tiempo de práctica.

Durante el taller trabajamos con las siguientes herramientas:

Adicionalmente también hablamos sobre:

La evaluación de los asistentes fue muy buena y adicionalmente me surgieron algunas ideas para probar en próxima ediciones.

Project Bootstrap, cómo inicio mis proyectos

Al comienzo de todo proyecto de desarrollo hay ciertas cosas que debemos tener en claro y algunas decisiones que debemos tomar respecto de las herramientas de soporte que utilizaremos. Estas cuestiones constituyen lo que suelo denominar como bootstrap del proyecto. Hace un tiempo grabé este screencast para mis alumnos de UNQ sobre este tema. Para quienes prefieran leer a escuchar, resumo brevemente lo que mencionado en el screencast.

Todo proyecto surge a partir de una visión. La visión es definida por el cliente y es básicamente el justificativo del proyecto. El cliente decide llevar adelante el proyecto para resolver un problema o para aprovechar una oportunidad. Es fundamental que todos los involucrados del proyecto conozcan la visión, por ello siempre suelo ponerla por escrito y compartirla con todos los involucrados.

Al desarrollar proyectos es común hablar de «el cliente», un término que me resulta inapropiado, pues lo considero ambiguo. Personalmente prefiero utilizar términos más específicos. Desde mi perspectiva todo proyecto tiene un sponsor, que es aquel que brinda el apoyo político para que el proyecto se lleve adelante. En forma simplificada podemos decir que el sponsor es quien está pagando por el proyecto. Por otro lado tenemos al experto de negocio, que es quien conoce en detalle la problemática a resolver. En ocasiones puede que el sponsor sea también el experto de negocio, pero no siempre es así.

Ya en el terreno de las herramientas, hay algunas cosas básicas como:

  • un repositorio de código: git, mercurial, subversion o el que más te guste
  • una herramientas de gestión: Jira, Redmine, Trello, una hoja de cálculo o simplemente un tablero de post-its
  • un servidor de integración continua: Jenkins, TeamCity, Travis o el que gustes

Adicionalmente me parece importante contar con:

  • Un ambiente de prueba/demo: este es un ambiente «neutro», fuera de la máquina del programador, donde se instala la aplicación en cuestión de forma frecuente. Este ambiente es usado para las revisiones de iteración. De cara a mitigar riesgos, debería ser lo más similar posible al ambiente productivo
  • Projectpedia: es básicamente una wiki que concentra información del proyecto. Con información del proyecto me refiero a cosas bastante variadas que van desde información de contacto de los involucrados, hasta la visión del proyecto y la información de acceso a los distintos ambientes, etc, etc

¿y tu? ¿usas algo más?

La explicación del porqué estoy codeando un Applet

¿Acaso pensabas que con HTML5 y el ascenso de Javascript podrías deshacerte de los applets y los ActiveX? Pues aún no es posible. Aunque cueste creerlo hay ciertas cuestiones que aún hoy se encuentran fuera del alcance de HTML5 y JavaScript. Les cuento el caso de un proyecto en el que estoy trabajando y para el cual tuve que desarrollar un applet.

Resulta que un sistema en el que estoy trabajando es una aplicación web en la que algunos usuarios deben cargar información sensible. Por esto se ha definido que cuando un usuario cargue esta información sensible, la mista deberá ser firmada. Para esto cada usuario cuenta con un token. Cuando digo token me refiero a un dispositivo físico que almacena certificados y que permite que los mismo sean utilizados para distintas cuestiones. Físicamente estos tokens son como llaves USB. Por razones de seguridad, no es posible acceder directamente a los certificados del token, sino que el acceso debe hacerse mediante un driver particular que provee el fabricante del token. Entonces nos encontramos con una página web cuya información debe ser firmada y para generar la firma resulta necesario interactuar con el driver del token. Hoy en día aún no es posible hacer esto (interactuar con un token) con HTML5/JavaScript desde un browser y la solución que nos resultó más razonable fue usar un applet. Puede que el applet parezca algo feo, pero sin duda es mucho mejor que usar componente ActiveX que sólo correría en Windows.

En próximos post compartiré algunas cuestiones que he ido aprendiendo durante la construcción de este applet.

Un pizca de mundo real en la academia

Continuando con lo planteado en el post «La universidad me mintió» quiero compartir algunos casos de materias en las que se pone al alumno en situación bastante similares a las del mundo real.

Comienzo con algunos casos que me involucran.

Elementos de Ingeniería de Software, Universidad Nacional de Quilmes

Las últimas 5 semanas de la materia, los alumnos trabajan en equipos de dos personas en la construcción de un producto, organizados en iteraciones semanales y utilizando prácticas de Scrum y XP. En la cuarta iteración los hacemos rotar de manera que trabajen en el producto de equipo.

Algoritmos y programación 3, Universidad de Buenos Aires

El trabajo final de la materia suele ser la construcción de un video juego utilizando POO y Java. De cara a simplificar las complejidades de la construcción de la interface de usuario y el manejo de threads, hemos construido un mini-framework que se encarga de estas cuestiones y permite que los alumnos se enfoquen mejor en la construcción del modelo de objetos de dominio. Este mini-framework está intencionalmente incompleto y carece de cietos puntos de extensibilidad (también intencionalmente) lo cual en cierto modo obliga a los alumnos a leer el código del micro framework y modificarlo.

Taller de Programación 2, Universidad de Buenos Aires

Según comentó Dario en el post inicial, en la materia Taller de Programación 2, de la carrera de Ingeniería Informática de la Universidad de Buenos Aires, los alumnos deben trabajar sobre código heredado. Festejo esto, pues cuando yo cursé esa materia no dinámica no era esa, sino que trabajamos directamente sobre «código nuevo».

Práctica de desarrollo software, Universidad Nacional de Quilmes

Por otro lado Javí comentó que en la materia Práctica del Desarrollo de software, de la Licenciatura en Desarrollo de Software de la Universidad Nacional de Quilmes tiene la idea de trabajar sobre un producto/servicio a lo largo de los varios cuatrimestres.

Algunos otros

Más allá de estos 4 casos, he oído de algunas iniciativas en esta dirección en la Universidad Nacional de Tres de Febrero y en la Universidad Nacional de La Matanza, pero no tengo detalles suficientes como para compartir.

How to backup Jenkins

There are a couple of plugins out there to backup Jenkins. Some of them focus on jobs configuration while others focus on Jenkins global configuration. All of them have in common that store a file (or set of files) in a certain location in the same box where Jenkins is running. In  my opinion this is not enough because in case of a hardware failure you could lose Jenkins and also the backups.

Maybe there is a plugin that solves this situation but I didn’t find it, so I decided to do the following:

  1. Create a code repository
  2. Create a PowerShell script to copy all jobs configuration files to the repository folder and commit them
  3. Create a Windows Scheduled Task to trigger the script once a day

To write the script mentioned in (2) you need to know some internal details about Jenkins. For each job you create, Jenkins creates a folder with the job name under the location $JENKINS_HOME/jobs. Inside the job folder you will find a lot of files but the only important for us is the config.xml which contains the job configuration.

If this explanation is not clear enough or if you simply don’t want to waste time writing the script, you can take a look at the script I wrote.

One more detail: I am wrapping my PS script with a cmd script in order to redirect the output to a file that I used as a log file.