Desarrollo y publicación de aplicaciones con cero costo

La semana pasada estuve trabajando en una aplicación de ejemplo que voy a utilizar para ejercitar algunas cuestiones en mi materia en UNQ. Mi idea es trabajar con esta aplicación mostrando todos los aspectos de su desarrollo, desde la concepción hasta la puesta en producción, pasando por cuestiones técnicas como prácticas de refactoring pero también por cuestiones más bien de infraestructura como el setup de un dominio.

Esto me llevó por un lado a configurar un ambiente de desarrollo y un ambiente productivo. Comparto aquí algunas herramientas/servicios que utilicé.

Para la administración y versionado de la aplicación utilicé GitHub.

Para integración contínua utilicé Travis.

Tanto para el ambiente de staging como también para el de producción utilicé Heroku.

Para el setup del dominio del ambiente productivo utilicé el servicio de Free DNS.

Obviamente para una aplicación real puede que todo esto no resulte suficiente, pues hay cuestiones operacionales (como disponiblidad, backup, etc) que no están siendo contempladas. Pero más allá de este detalle, la cuestión es que todo esto me permite mostrar muchas cuestiones sin tener que pagar por servicio alguno.

Prácticas de desarrollo y delincuencia cotidiana

Este post surgió a partir de una charla con mi colega Gabriel Iglesias.

Estábamos hablando sobre prácticas de desarrollo en distintos contextos: la industría, la universidad, proyectos open source, etc.

Gabi comentó que en un momento le tocó trabajar en un contexto donde habia varias «malas» prácticas (comitear código en el repositorio sin el correspondiente mensaje de log, no respetar la convención de codificación, utilizar nombres de variables no descriptivos, etc). Esto no me extrañó en lo más mínimo, pues hay muchos contextos así, pero el hecho de que sea algo común no significa que sea correcto ni que uno deba aceptarlo. Es ahí donde surge la relación con la delincuencia. Hoy en día los actos delictivos son algo cotidiano en ciertas zonas de nuestro pais, pero ello no significa que sean correctos.

Ahora pensando a la distancia se me ocurre otra relación entre estas dos cuestiones:  un programador que no respecta las convenciones y/o no pone los mensajes de log en los commits ¿no es acaso un delincuente? Para pensarlo. Fin.

PD: Gracias Gabriel

Jenkins: Plugins infaltables

De cara a automatizar parte de la corrección de los trabajos de los alumnos de la materia que dicto en UNQ, ayer estuve configurando un Jenkins. La idea es que los alumnos entreguen sus trabajos via Github, o sea, cada alumno tendrá un repositorio en GitHub. Llegada la fecha de entrega de cada trabajo, el build server (Jenkins en este caso) descaga los repositorios y verifica que existan archivos correspondientes a la entrega.

Como parte de la configuración de este Jenkins, instalé los siguientes plugins que me parecen fundamentales:

  • Git: la función de este plugin es obvia, permite a Jenkins conectarse con repositorios Git
  • Green Balls: por defecto, Jenkins representa el estado «build exitoso» con el ícono de una pelotita azul. Este plugin cambia dicha pelotita azul por una pelotita verde.
  • Copy Artifact: permite copiar artefactos de un proyecto a otro
  • Email Ext: extiende la funcionalidad de notificaciones de email provista por nativamente por Jenkins

Anteriormente había comentado sobre un plugin para enviar notificaciones via Jabber (particularmente gtalk), en esta ocasión no lo instalé, pues creo que dicho plugin resulta útil para cuando uno trabajar en desarrollo y este no es el caso.

Sobre el Open Space de Educación

Me resultó muy interesante. Estimo que hubo alrededor de 30 personas de perfiles muy variados. La mayoría eramos de sistemas, pero también había gente de eduación de distintos ámbitos: sindicalismo, idiomas, educación social, etc, etc.

Hubo más propuestas de sesiones que los slots que teniamos disponibles, pero algunos de los que las habian propuesto fueron solidarios para juntar sus sesiones y que así todos los temas sean tratados.

Luego de la planifinición inicial, comenzamos con una sesion plenaria de Lightning Talks  de 3 minutos donde algunos de los asistentes compartimos técnicas/experiencias realizadas en nuestros respectivos contextos. En esta sesión Pablo Roca presento el proyecto Nahual.

Después de eso participé en las siguientes sesiones:

  • Evaluación: esta sesión fue propuesta Jorge Silva y Mariano Tugnareli. Compartimos distintas problemáticas y técnicas relacionadas a la evaluación: la evaluación como instancia de aprendizaje, la evaluación de pares, la evaluación en cursos masivos, etc.
  • Tutorias: esta sesión resultó de fusionar 3 sesiones relacionadas a las dificultades de enseñanza en los primeros años de la universidad. Yo compartí mi expericiencia como tutor en el programa PACENI y otros asistentes comentaron las dificultades que afrontaban en sus correspondientes ámbitos. Sinceramente no sacamos nada en límpio, fue más bien una sesión de catarsis.
  • Actividades: esta sesión fue propuesta por Juan Gabardini y la idea era compartir técnicas/dinámicas para enseñar en el aula. Comentamos más de 15 técnicas, muy interesante.

También hubo algunas otras sesiones sobre trabajo con niños, training from the back of the room y aprendizaje por descubrimiento.

Personalmente me resultó muy enriquecedor y me llevé algunas cosas para probar en mis materias.

Un nuevo rumbo

Finalmente voy a empezar a trabajar de forma independiente. Desde que me recibí estudié el tema en varias ocasiones, pero nunca me animé a dar el paso. Y en esta ocasión de no haber sido por una pequeña ayuda de ex-empleador creo que tampoco lo hubiera hecho. Resulta que la empresa donde trabajaba hizo una reestructuración y el puesto que yo ocupaba fue «recortado». Si bien podría haberme quedado en la empresa tomando otro puesto, decidí dar el gran paso y continuar trabajando en cuestiones de capacitación pero esta vez por mi propia cuenta.

En el pasado trabajé de forma independiente, pero fue algo corto, informal e inestable. Fue durante los primeros años de la universidad. Hacia trabajitos tipo soporte técnico a particulares y de vez en cuando algunos desarrollos de sitios web. Tengo esperanzas de que en esta ocasión sea algo más estable, duradero y entretenido. Al mismo tiempo, todos los años que llevo trabajando en la industría y en la universidad creo que me han dado una rica expericiencia.

En particular hay un tema en el que me gustaría mucho trabajar: implementación de prácticas «duras» de ingeniería. Este ha sido uno de los focos de mi trabajo en el último tiempo tanto en la empresa donde trabajaba como también en UNQ. Con prácticas «duras» de ingenieria me refiero a aquellas prácticas cercanas de código: automatización de pruebas, verificación de estándares de codificación, obtención de métricas de código, integración contínua, manejo de ambientes, automatización del pasaje entre ambientes, etc.

En estos dias me encuentro ordenando algunas cuestiones operativas mientras analizo como y por donde empezar.

Primer Balance TPI 2012

Al final de cada cuatrimestre en TPI, Fidel, el director de la carrera, organiza la denominada «reunión de balance». En dicha reunión Fidel comparte con los alumnos y profesores de la carrera los hechos y novedades relevantes acontecidas durante el cuatrimestre.

Tradicionalmente estas reuniones han tenido una forma de «pseudo-monólogos», lo cual es casi inevitable ya que es Fidel quien concentra casi toda la información de lo acontecido. A pesar de esto, este cuatrimestre Fidel decidió intentar un cambió y convocó a dos «maestros de ceremonias» para facilitar la reunión. Yo tuve el honor de ser uno de esos maestros de ceremonias, el otro fue Victoria Fabrice, una alumna de la carrera.

La reunión estuvo dividida en 3 partes:

  1. Dado que Fidel concretaba mucha de la información a compartir, la primera parte de la reunión, unos 40 minutos, Fidel hizo un resumen de los hechos más relevantes: estadísticas generales de la carrera, anuncios sobre las inscripciones, novedades en el equipo docente y en la infrastructura de la universidad, etc, etc.
  2. Una vez finalizada la exposición de Fidel, junto con Victoria falicitamos una dinámica para romper el hielo y que la gente se relaje. Al finalizar la dinámica cada participante escribió en post-its sus inquietudes/problemas/sugerencias/consultas y los pegó en el pizarrón.
  3. Una vez terminada la lluvia de post-its, pasamos a la parte de debate para lo cual utilizamos la técnica de Fishbolw. Victoria y yo fuimos agrupando los post-its por temática y los fuimos compartiendo en voz alta para ir tratándolos. La idea era que entre todos contestaramos las consultas y debatieramos posibles soluciones a los problemas.

Los principales temas de discusión estuvieron alrededor de la oferta horaria, la infraestructura de la universidad, la nueva Licenciatura en Desarrollo de Software, la publicación de notas, la organización/representación de los alumnos y comunidad TPI. Personalmente me resultó muy enriquecedor.

Al finalizar, utilizamos la técnica de las caritas para ver si los asistentes preferian está forma de reunión o la tradicional, los resultados fueron:

  • 🙂 , 25 personas prefieron está forma de reunión por sobre la anterior
  • 😐 , 3 personas opinionaron que esta forma de reunión o la anterior le dan lo mismo
  • 😦 , no hubo gente prefieriera la forma anterior

Hay un voto que me llamó la atención, ya que el dibujo no correspondia con la consigna, me queda la duda si es una carita asombrada o enojada.

Open Space de Educación

Desde la comunidad de métodos ágiles de Buenos Aires, estamos organizando un open space sobre esta temática. La idea es compartir técnicas/problemáticas/estrategias de enseñanza de cara me mejorar las clases, la llegada a los alumnos y el proceso de enseñanza/aprendizaje en general.

La cita es el próximo sábado 4 de agosto en las instalaciones de la UNTreF en el Centro Cultura Borges (Viamonte esq. San Martín 3 piso, Ciudad de Buenos Aires)

Como de costumbre el evento es totalmente gratuito pero con previa registración. Más info y registración aquí.

¡Nos vemos!

Cierre de cuatrimestre a puro TDD (algo3, 1c-2012)

Y se fué uno más, pero distinto y para bien. En líneas generales mantuvimos la misma modalidad que los cuatrimestres anteriores, pero creo que en esta ocasión hemos manejado mejor los tiempos y hemos resultado «más convincentes» en algunas cuestiones.

Entre los cambios del curso Jueves-tarde sumamos un nuevo colaborador docente: Diego Marcet, graduado de la casa, ex-alumno de la materia y ex-compañero mio de trabajo en Southworks.

Otro de los cambios implementados fue el uso del campus virtual (basado en Moodle) para la publicación del material de estudio. Yo personalmente fuí un poco más allá y lo utilicé para manejar la interacción con mis grupos vía los foros. La ventaja que le veo al uso de foros tiene que ver con que la resulta muy cómodo visualizar el hilo completo de la conversación.

A mi parecer la particularidad más destacada (al menos de nuestro curso) fue el fuerte incampié que hicimos en el uso de TDD, lo cual dió sus frutos en el trabajo final, donde varios alumnos desarrollaron gran parte de trabajo usando esta técnica.  Es más, la cantidad de pruebas unitarias de los TP finales fue record en el caso de los TPs que yo corregí: me entregaron TPs con más de 200 pruebas unitarias, llegando a niveles de cobertura llegando al 80%.

La última innovación a mencionar es la práctica de integración contínua. Si bien este tema lo vemos en la teoría desde hace varios cuatrimestres, este año fui más allá y levante un servidor de integración contínua para mis alumnos (lamentablemente no tenía una gran infraestructura, asi que solo lo pude hacer para los 3 grupos a mi cargo). El proceso de build incluyó: compilación, ejecución de pruebas y medición de cobertura.

Si bien no hicimos la dinámica de retrospectiva global, yo hice una más reducida con los alumnos de mis grupos y el feedback fué muy positivo: solo surgieron algunas cosas menores para mejorar que comentaré en un próximo post.

Retrospectiva de Ing. de Software, primer cuatrimestre 2012

Antes de entrar en detalle sobre los resultados de la retrospectiva, quiero destacar por qué hacemos restrospectivas. La respuesta es simple: para mejorar. La idea es revisar como se desarrolló la materia intentando identificar puntos positivos y negativos, y partir de su análisis definir: qué cosas mantener, qué cosas cambiar y que cosas probar. Ahora sí, vamos a la restrospectiva.

Para la retrospectiva, utilizamos la técnica del timeline, mi favorita para estos casos (cierre de cuatrimestre). Lamentablemente, solo participaron 5 de los 7 alumnos. De todos los items identificados, una cuarta parte estaba relacionada a cuestiones «de ambiente» ajenas a la materia y sobre las cuales prácticamente no tengo posibilidad de influencia (por ejemplo: fallas en la infrastructura informática de la universidad). Respecto del resto de los items, esto es lo relevante:

Items a mantener

  • Estructurada iterativa de la materia
  • Actividades de aplicación
  • Dictado de una clase en forma remota
  • Presentación de invitados de la industria
  • Dinámica de evaluación final
  • Restrospectiva al final de cada iteración y restrospectiva final

Cuestiones a mejorar

  • Dificultades varias con Sinatra
    • Recomendar un tutorial y darlo con anticipación suficiente
  • Evaluación online
    • Hacer revisar las preguntas por un tercero para asegurar que sean claras y evitar posibles ambigüedades
    • Hacer una al final de cada iteración
    • Resolver las dificultades técnicas de la herramienta para permitir ver el resultado y las respuestas correctas al finalizar la evaluación
  • Retos del profesor (si, yo, los sermoneo mucho cuando no cumplen con las tareas)
    • No calentarme tanto
    • Mejorar las formas
    • Automatizar la corrección y parte del feedback con alguna herramienta
  • Material utilizado en clase no disponible (en algunas clases utilicé ppts que luego no compartí)
    • Publicar el material utilizado o bien ser explícito de antemano que no será publicado
  • Poca visibilidad de las notas
    • Publicar las notas al final de cada iteración

Para probar

  • Lecturas voluntarias: compartir algunas lecturas/videos opcionales que les permitan sumar «puntos adicionales» al presentarlos al resto de la clase
  • Proveer una guia de lectura para todas las lecturas, asi leen más enfocados
  • Dedicar los primeros 10 minutos de la primer clase de la semana para repasar los puntos destados de la lectura realizada

Bueno, esto es todo, voy a intentar incorporar todas estas cuestiones el próximo cuatrimestre.