Nueva edición del taller de Integración contínua

El próximo 28 de Marzo voy a dictar una vez más este taller. Para esta nueva edición he realizado algunos cambios basado en el feedback de la edición anterior. He decidido recortar algunos temas de cara a poder ver otros con mayor profundidad. Asimismo quiero que los asistentes hagan más práctica y que puedan llegarse del taller algunos scripts para su uso cotidiano.

Pueden encontrar más información aquí.

jenkinsCIA

Octopush by Olx

Como parte del proyecto de Continuous Delivery en Olx, generamos una herramienta para controlar el acceso al ambiente de staging. Esta herramienta se llama Octopush y está construida con Php y MySql. La semana pasada Olx liberó Octopush bajo licencia Apache.

Los interesados en colaborar/ver/usar Octopush pueden encontrar el código el código en GitHub (github.com/olx-inc/octopush).

Explicar lo que hace esta herramientas no es tan trivial por eso grabé este breve video.

MiriadaX: cursos online gratuitos en castellano

Reciente descubrí MiriadaX, una plataforma al estilo Coursera, pero que agrupa Universidad de España. Cuenta con una gran cantidad de cursos de diversos temas que varian desde Economia y Finanzas hasta Turismo y Salud pasando por Informática e Innovación.

Para hacer una prueba de esta plataforma y aprovechando que ya estoy por terminar el curso de Android decidí anotarme en un curso de agilidad llamado Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI El mismo tiene una duración de 1 mes y una carga estimada de trabajo de 5o horas.

En un mes les cuento que tal el curso y la plataforma.

Continuous Delivery en Olx

Hace aproximadamente un año comencé a trabajar en un proyecto de implementación de continuous delivery en Olx. Mi rol dentro de dicho proyecto era el de facilitador colaborando principalmente con Diego Garber, release manager de Olx y product owner del proyecto.

Cuando digo facilitador lo digo en un sentido muy amplio, ya que mis tareas incluian un poco de gestión, un poco de diseño, capacitación, configuración/troubleshooting de Jenkins y hasta programación en Php. Básicamente ayudaba a que cada involucrado cumpliera con sus tareas, lo cual podía incluso implicar que en ciertas ocasiones me encargara yo mismo de la ejecución de dichas tareas, ya fueran configurar un repositorio GitHub o escribir algo de código.

releases

En estos días estamos cerrando el proyecto y me complace el hecho de que no sólo hemos cumplido con la mayoría de los objetivos inicialmente planteados, sino que aún más importante, hemos agregado valor a la organización permitiendo que el área de tecnología pueda dar respuestas más rápidas a las necesidades del negocio, acortando el ciclo de feedback y potenciando el retorno de la inversión.

En las próximas semanas iré compartiendo algunos datos más de esto, por el momento termino este artículo con un gráfico que muestra la evolución de la cantidad de releases desde que arrancamos el proyecto. En el  mismo se puede apreciar que se pasó de 60 releases mensuales en marzo de 2013 a 180 en enero de 2014.

Algunos cambios en Algo3 para el 2014

Un nuevo cuatrimestre está por comenzar y junto con el vienen algunos cambios.

En primer lugar tenemos algunos cambios de horario: la teórica será dictada los lunes por la tarde y al mismo tiempo la práctica de los miércoles también se dictará por la tarde (en ambos casos el horario es de 16 a 19 hs). Las otras dos prácticas siguen iguales.

También tenemos cambios en los equipos docentes de las prácticas: Gabi Falcone pasa a la práctica de los jueves a la noche, mientras que DiegoM y yo estaremos en la práctica de los miércoles.

Finalmente tenemos algunos cambios en lo que respecta a la dinámica de las clases: vamos a experimentar más fuertemente con algunas técnicas de lo que se denomina el paradigma de educación centrada en el alumno.

Coursera: Curso de Android, Semanas #4 & #5

La cosa se puso más dura, muchos más videos y al mismo tiempo mucho más contenido, lo cual hace que sea más difícil afianzar los conocimientos. Estoy descubriendo que realmente no es una cuestión tan simple hacer aplicaciones para dispositivos móviles en la actualidad. Si bien sólo tengo una idea aproximada de lo que es desarrollar para Android, estimo que la complejidad de desarrollo en Windows Phone y iPhone ha de ser similar.

Estoy usando el emulador de  Genymotion, que supera con creces al emulador por defecto que viene con el SDK.

Estoy por comenzar con el contenido de la semana 6, que está centrado en gráficos y animaciones, temas que no me interesan demasiado pero que sin duda son relevantes sobre todo para el desarrollo de juegos.

Continuará…

Recomendaciones idiomáticas para programadores

Las recomendaciones que comparto en esta sección han surgido principalmente de mi experiencia personal como programador y como docente de programación. Decidí ponerlas por escrito cuando me dí cuenta que las repetía una y otra vez para los distintos alumnos que pasaban por mis clases.

Aprende inglés

Nos guste o no el inglés es la lenguaje universal es esta profesión, todos los lenguajes de programación de escala industrial parten de la lengua inglesa. (he sabido de lenguajes de programación basados en otros idiomas, pero todos ellos eran experimentales o bien para uso educativo).

Si bien parte de la bibliografía es traducida al castellano, las traducciones siempre tienen un tiempo de defasaje respecto de la publicación original que la mayoría de los casos es en inglés. Incluso cuando la publicación original no sea en inglés, es casi seguro que será antes traducida al inglés que al castellano.

Al mismo tiempo la evolución de las herramientas es cada vez más rápida, haciendo que los tiempos entre las distintas versiones sea cada vez más corto. Esto hace que una traducción tardía pierda sentido pues queda rápidamente desactualizada.

Es cierto que también existen publicaciones originales en castellano, pero sinceramente son sólo un pequeño porcentaje.

Adicionalmente existe un riesgo con las traducciones que es la potencial pérdida de cierto sentido del término original o peor aún, la ambigüedad.

Más allá de la necesidad del inglés para el acceso a los recursos, existe otra cuestión: los clientes. En este contexto cada vez más globalizado no es raro que termines trabajar con un cliente que no hable castellano. Aún cuando dicho cliente no sea un de país de habla inglesa ¿en qué lenguaje crees que pretenderá comunicarse contigo? Y podemos ir aún más allá, puede que incluso parte de tu equipo este distribuido y te tengas que trabajar con un compañero que no hable castellano.

Resumiendo: debes tener cierta soltura para comunicarte en inglés. ¿cuanta soltura? Mi heurística es: debes sentirte cómodo leyendo y escribiendo y debes ser capaz de entender los diálogos de la serie IT Crowd en idioma original sin necesidad de leer los subtitulos.

Elige un idioma

Un dilema común para muchos programadores de habla no inglesa es ¿en qué idioma programar? O sea, más allá del lenguaje de programación que elijas utilizar, en un punto tendrás que crear tu clases/funciones/variables y deberás decidir cómo nombrarlas.

Podrías nombrarlas en inglés para así mantener uniforme el código fuente ya que las construcciones nativas del lenguaje de programación están en inglés.

Pero si tu cliente es de habla castellana, entonces podrías decidir nombras tus clases/funciones en castellano, para así tener un mapeo más directo entre los conceptos del dominio y tu código.

A mi parecer ambos criterios son válidos y creo que la decisión más apropiada requiere de un análisis del contexto particular de cada caso.

Más allá del análisis y la decisión que uno tome, creo que lo importante es hacer el análisis, tomar decisión y respetarla. Obviamente esta no es un decisión individual, sino que es que debe decidirse a nivel de equipo.

actualización: hoy, 10 años después del escrito inicial, he cambiado de opinión, o sea: debemos construir un lenguaje universal con la gente de negocio. Si nuestro cliente/product owner habla castellano, nosotros hablamos castellano, nuestra comunidad de usuarios habla castellano, entonces el código va en castellano. Eso nos ayudará en las construcción de lenguaje universal (ddd), no evitará ambigüedades y nos ayudará a disminuir la carga cognitiva.

Utiliza el alfabeto inglés

Es común en la actualidad encontrarse con lenguajes de programación que permiten el uso de caracteres no pertenecientes al alfabeto inglés. Por ejemplo en Java es posible definir una variable “año”, una clase “Interés”. En mi experiencia esto, tarde o temprano, suele traer algún tipo de problema, sobre todo si los ambientes de desarrollo de cada miembro del equipo no estan totalmente estandarizados.

Utiliza software de base en inglés

Es común que cuando se produce un error en una aplicación, se muestre un mensaje de error al usuario y al mismo tiempo se genere una nueva entrada en el log de la aplicación. En algunos casos esos errores se muestran en el idioma actual de la aplicación y/o del sistema operativo.

Dado que hay mucha más información en internet en inglés que en castellano, siempre recomiendo utilizar software de base en inglés, o sea, al instalar tu sistema operativo, elige inglés como idioma por defecto. Lo mismo recomiendo para los IDEs y los SDKs. De esta forma en caso de encontrarte con un error, el mismo estará en inglés y al ponerlo en el buscador encontrarás muchos más resultados que si el error estuviera en castellano.

ASSE 2014: Simposio Argentino de Ingeniería de Software

Este tradicional simposio que forma parte de las Jornadas Argentinas de Informática organizadas por SADIO se llevará a cabo este año en las instalaciones de la Universidad de Palermo, los días 4 y 5 de Septiembre.

Los chairs de esta edición del simposio somos Luciana Roldán y quien escribe. Luciana es investigadora del CONICET  y docente de UTN Santa Fe y en lo que a mi respecta, fui invitado por ser miembro de la División Ágiles de SADIO.

Esta semana abrimos la convocatoria para la presentación de trabajos y estamos trabajando activamente en su difusión. Pueden encontrar información más detallada en la página del simposio.

JavaScript en OLX

Este semana estuve participando de un entrenamiento en JavaScript organizado por la gente de OLX con quien vengo trabajando desde hace casi un año.

El entrenamiento fue dictado por Kyle Simpson (@getify) y estaba titulado «Advanced JavaScript». Cómo dijo el propio Kyle durante la apertura, un nombre mejor podría haber sido «JavaScript Foundations», pues justamente el foco estuvo en cuestiones básicas, de «bajo nivel» en cierto punto, que en mi opinión la gran mayoría de la gente que escribe JavaScript desconoce.

El entrenamiento me pareció muy interesante, me enteré de cosas de las que no tenia ni idea. Ojo, también debo admitir que nunca le puse muchas pilas a aprender JavaScript. He escrito código y aprendido lo poco que sé a base de «prueba y error». A pesar de esto soy consciente que cada vez es más necesario para todo programador, manejar cierto nivel de JavaScript.js_at_olx

Una cosa que confirmé en el entrenamiento es que nunca voy a llegar a un nivel avanzado en el uso de JavaScript, pues resulta que el lenguaje tiene tantas particularidades/características que llegar a dominarlas me llevaría un tiempo tal que no estoy dispuesto a invertir.

Le agradezco a David Grandes y Santiago Villa del equipo Mobile de OLX por haberme invitado.

Sobre la terminologia ágil y sus traducciones

Muchos de los términos del ámbito de la informática tienen su origen en habla inglesa. A lo largo de los años diversos términos han sido traducidos al castellano y en mayor o menor medida las traducciones han sido adoptadas por la comunidad hispano-parlante.

En particular dentro del mundo ágil también nos encontramos con muchos término con origen en lengua inglesa, pero que tal vez por ser de más reciente aparición, aún no tienen traducciones consolidadas en castellano.

La traducción de estos términos fue uno de los desafíos que enfrentamos al escribir el libro sobre desarrollo ágil. Desde un principio decidimos intentar traducir todo lo que fuera posible y razonable. Finalmente la estrategia fue:

  • En el caso de términos con una traducción ampliamente aceptada por la comunidad y a nuestro entender apropiada, hemos utilizado dicha traducción.
  • En el caso de términos con diversas traducciones razonables, optamos por elegir aquellas que a nuestro criterio resultaban más apropiadas.
  • En el caso de términos sin traducciones razonables, optamos por no traducir.

Un caso interesante es el término User Story, muchas veces traducido como Historia de usuario. A nuestro entender dicha traducción no es del todo correcta. El término historia en castellano hace referencia justamente a la historia como sucesión de hechos pasados, lo que en inglés es history. El término inglés story, sería en castellano algo así como cuento. Es por esto que decidimos utilizar directamente el término inglés.

Entre los términos que no tradujimos están: spike, coach, slack y build.