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í que 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 era 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 exiten 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 ambiguedad.

Más allá de la necesidad del inglés para el acceso a los recursos, exite 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 pais 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 díalogos 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 que 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.

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

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

Utiliza software de base en inglés

Es común que cuando se produce un error en una aplicación, se muestre 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.

Coursera: Curso de Android, Semana #3

Ayer completé la tercer semana, durísimo. Tuve que ver 4 videos y hacer 5 ejercicios de programación, uno de los cuales me llevó varias horas debido a que la configuración provista en el código base del ejercicio no permitía ejecutar la aplicación en un emulador.

Hasta el momento el curso ha estado enfocado en cuestiones relacionadas a la arquitectura de las aplicaciones Android. Por lo poco que ví de la semana 4, parecer tratar sobre construcción de interfaces de usuario.

Continuará…

Un defecto en producción, ¿que harías tu?

A partir de ciertos problemas de calidad en sus aplicaciones, al área de sistemas de una organización decide invertir en la adopción de ciertas prácticas. Trabaja durante un año adoptando prácticas y principios tales como integración continua, control de configuración, mejora continua, planificación adaptativa, automatización de pruebas, etc. Todo esto a la par de un cambio en el proceso de desarrollo y despliegue de las aplicaciones.

Luego de un arduo trabajo de un año todos los equipos de desarrollo de la organización han adoptado (en mayor o menor medida) la nueva forma de trabajo y las prácticas asociadas.

Un día llega un defecto crítico a producción: ¿qué es lo que debería hacerse?

  • Opción A: arreglar el defecto y ya, no importa el proceso ni las prácticas
  • Opción B: seguir el procedimiento correspondiente para este tipo de situaciones.
  • Opción C:  intentar seguir el correspondiente procedimiento pero si este retrasa/dificulta la solución del problema, intentar una solución sin apartarse de los principios que se han venido trabajando y revisando/ajustando el procedimiento una vez resuelto el problema.

¿que opinas tu?

Proyecto T: tecnología definida

Luego de investigar y hacer algunas pruebas de concepto, los alumnos eligieron construir la aplicación con Grails y AngularJS, una combinación con la personalmente no tengo experiencia pero que me gusta.

Respecto a la infraestructura, el repositorio será Git (github).

Respecto del build server y el ambiente de tests, yo tenía la ilusión de usar el servicio de CloudBees, pero los alumnos prefirieron ir con Travis y Heroku.