Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: código

R, rPython y ggplot2. Un poco de trabajo en equipo

Me llamo Jesús Armand y desde hace unos meses formo parte del equipo de Frogtek como científico de datos. Desde mi llegada, la compañía ha comenzado a utilizar nuevas herramientas en su día a día. Es por ello que a partir de ahora intentaré escribir sobre trucos, pequeños tutoriales o problemas con los que nos encontremos.

Cuando se trabaja con datos, a veces nos encontramos con la necesidad de ejecutar distintos códigos o comandos en diferentes herramientas. Por ejemplo, podemos estar trabajando con una base de datos en MySQL para extraer cierta información que queremos filtrar con algún método implementado en Python y ese resultado representarlo en un gráfico utilizando el paquete ggplot2. Resulta engorroso el proceso de crear, guardar y volver a abrir un fichero en las distintas etapas del proceso.

Es por ello que R a veces nos ayuda a simplificar todas estas tareas y a hacerlas más sencillas. Por ejemplo, con el paquete RMySQL podemos conectarnos de forma rápida con nuestra base de datos y realizar las consultas directamente desde la consola de R y guardar los resultados para, posteriormente, trabajar con el paquete rPython, creado por Carlos Gil Bellosta. En él podremos llamar fácilmente a las funciones desarrolladas en código Python y, finalmente, con las variables almacenadas en nuestro workspace en R, representar gráficamente la información que deseábamos en un principio con ggplot2.

Hoy nos centraremos en un pequeño ejemplo para interactuar con estos dos últimos paquetes: rPython y ggplot2.

El ejemplo va a consistir en, dado un vector con 83 valores, utilizar el método MADe para la detección y eliminación de valores extremos implementado en Python y representar el resultado en un histograma con el paquete ggplot2. El fichero datos-ejemplo- tiene los datos que necesitaremos. Os animo a que implementéis vosotros el código en Python.

Si no tenemos instalados en R los paquetes que necesitamos, ejecutaremos:

install.packages("rPython") 
install.packages("ggplot2")

Los paquetes en R se cargan de la siguiente forma:

library("rPython")
library("ggplot2")

El primer paso será indicar a R con qué fichero .py vamos a trabajar. Para ello ejecutaremos el comando:

python.load("statistical_formulas.py" )

donde el atributo es el nombre del fichero que contiene nuestra función (o funciones).

La función que hemos definido necesita de una sola variable con datos en la llamada. En este caso será el vector X:

python.call("remove_outliers_MADe_method", X)

donde el primer argumento es el nombre la función/método que tenemos en nuestro código y el segundo atributo es nuestro vector.

El resultado de la ejecución de esta llamada lo almacenaremos en la variable resultado.

Finalmente, sólo nos quedará invocar la función gplot() en ggplot2 para representar gráficamente un histograma:

qplot(resultado, geom="histogram")

Como habéis visto, el procedimiento es muy sencillo. Ahora, os animo a que implementéis vosotros mismos el algoritmo MADe para comparar el resultado.

Katas diarias

Hace unas semanas se nos ocurrió retomar el tema de las Katas, y digo retomar porque hace un tiempo nos dio por hacer Katas una vez a la semana. Esta vez fue diferente, en vez de hacerlo con tanto tiempo de diferencia, nos planteamos hacerlas diariamente. En eso consiste la Kata, ¿no? en practicar, practicar y practicar.

Así pues, empezamos Julio, Pedro y yo con Katas diarias (más adelante se uniría Javier Martínez a la fiesta). Cada uno de nosotros se propuso un objetivo concreto con dichas Katas:

* Julio pretende mejorar su rapidez de desarrollo en Eclipse, aprendiendo teclas rápidas y trucos del IDE

* Pedro se propuso aprender emacs y mejorar su programación en este entorno (¡¡y vaya si lo está haciendo!! Ayer me enseñó unas cosas espectaculares, pero creo que eso se merece otro post)

* Yo, por otro lado, me propuse aprender Vim.

Y todos haríamos la Kata en un lenguaje diferente al que estamos habituados, en este caso, Python.

Cada semana elegíamos una Kata del repositorio de 12meses12katas y durante esa semana trabajábamos durante 25 minutos en esa Kata. Una vez pasado el tiempo, mostrábamos a los compañeros el código realizado y lo comentábamos entre todos. Al día siguiente empezaríamos de nuevo, desde cero.

Hace poco, cambiamos las reglas del juego. Ahora, lo que pretendíamos hacer es escoger una Kata y hacerla durante un mes. La primera semana la haríamos normalmente pero el resto de las semanas y hasta que acabase el mes nos pondríamos limitaciones, para explorar otras formas de resolver el problema y cambiar la forma de pensar. Se nos ocurrieron cosas como:

* Hacer la Kata solo con objetos, nada de primitivos. Encapsulamiento máximo

* Hacer la Kata en modo spaghetti-code. Nada de refactors

(Llevamos poco tiempo haciendo esto, así que solo se nos han ocurrido estas restricciones).

No puedo hablar por mis compañeros, pero creo que en general es una muy buena práctica. No solo mejoras en rapidez a la hora de desarrollar en un lenguaje en concreto si no que además, en nuestro caso, estamos aprendiendo otras herramientas de trabajo. 25 minutos al día, cada día. Es poco tiempo y aporta mucho.

 

Revisión de código

Code Review

¿Revisar código?

¿Para qué?

¿Lo has probado?

Pues ya está ¿no?

Pues no. O al menos en Frogtek no nos vale. Y se agradece, la verdad. Veamos cómo y cuándo hacemos las revisiones de código.

Actualmente realizamos tres tipos de revisión de código:

  • Revisiones de código de las User Stories. Una vez terminadas y subidas al repositorio se revisan usando ReviewBoard, dando feedback, cuando sea necesario, a través de la herramienta. Dicha revisión se realiza dos veces. La primera por un programador y la segunda, por el tester antes de realizar el testing y verificación de la User Story.
  • Reuniones de revisión de código. Consisten en unas reuniones semanales en las cuales nos juntamos todos a ver, revisar, comentar… una funcionalidad nueva o un refactor especialmente delicado. Cualquier programador puede proponer código para ser revisado y nos animamos unos a los otros a ello.
  • Pair programinng de User Stories o parte de ellas. Aunque lo realizamos menos de lo deseado, lo usamos sobre todo cuando la funcionalidad que programar es complicada o propensa a errores. Nos ha dado muy buenos resultados siempre que lo hemos utilizado.

Solo llevamos alrededor de un año aplicando estás técnicas de manera exhaustiva, pero creo que las mejoras han sido sustanciales en la calidad de nuestro código y de nuestras habilidades.

Personalmente, lo que más me ha gustado es el conocimiento que se adquiere de toda la aplicación gracias a las revisiones. Ya no solo sabes lo que tú has hecho, sino gran parte de lo que el resto ha programado también.

Como nota final, un vídeo gracioso sobre Pair programing. En Inglés, lo siento.

Aquí huele a cuco (V)

Código del Jurásico encontrado en tiendatek.

 
        if (enteredAmount == 0) {
            mTheProduct.setProdPrice(0);
        } else {
            mTheProduct.setProdPrice(enteredAmount);
        }

Al parecer los cambios en la Pangea nos afectaron un poco.

¿Algún comentario o mejora?

Nuestro amigo Eduardo Moreno propone una versión mejorada:

if (enteredAmount * enteredAmount == 0) {
   mTheProduct.setProdPrice(Math.round(3.5* Math.cos(Math.PI/2)));
} else {
   mTheProduct.setProdPrice(enteredAmount * Math.exp(0));
}

Segundo Coding Dojo de Frogtek en Walqa

Tras el éxito del Primer Coding Dojo y la resaca de la visita de Richard Stallman ya va siendo hora de presentar el Segundo Coding Dojo de Frogtek en Walqa.

Rubén Bernárdez de Biko2 será nuestro maestro de ceremonias. Aquellos que estuvisteis en el primer dojo recordaréis a Rubén ya que fue uno de los dos valientes (el otro era Dani Latorre) que retados por Carlos Ble se marcaron un refactor de la kata de Carlos, improvisado, sin red y ante la admiración de todos los asistentes.

Así que no hacen falta más presentaciones, ahora ya todos sabemos lo que es un Coding Dojo y por lo tanto, sin más, os dejamos con los detalles de nuestra próxima cita. Os esperamos.

  • Día: viernes, 8 de abril de 2011
  • Lugar: Parque Tecnológico Walqa, Edificio de Servicios Generales
  • Horario: de 16:00 a 21:00 aproximadamente
  • Precio: Totalmente gratuito
  • Quién puede apuntarse: cualquier persona, independientemente de que trabaje o no en Walqa
  • Agenda:
    • Rubén propondrá uno o varios problemas sobre los que se trabajará en parejas.
    • Se realizarán varias iteraciones.
    • Al final de la sesión Rubén presentará y explicará su solución a todos los asistentes.
  • Plazas: Limitado a 35 personas, por riguroso orden de inscripción
  • Inscripción: Mandando un mail a Walqa (walqa@ptwalqa.com)

¡¡Animaos que seguro que lo pasamos muy bien!!.

Frogtek organiza un Coding Dojo en Walqa con Carlos Ble de invitado

El próximo viernes 21 por la tarde en Walqa, Frogtek organiza un Coding Dojo de la mano del experto en Test-Driven DevelopmentMetodologías Ágiles y Cloud Computing, Carlos Ble.

Un Coding Dojo es un evento informal y divertido en el que un grupo de programadores se reúne para poner en práctica sus habilidades de programación, resolviendo pequeños problemas programando por parejas en diferentes lenguajes. Es una oportunidad muy buena para aprender nuevas técnicas, nuevos lenguajes, conocer gente interesada en el mundo de la programación y obtener consejo de un experto como Carlos.

  • Día: 21 de enero de 2011
  • Lugar: Parque Tecnológico Walqa, Edificio de Servicios Generales
  • Horario: de 16:00 a 21:00 aproximadamente
  • Precio: Totalmente gratuito
  • Quién puede apuntarse: cualquier persona, independientemente de que trabaje o no en Walqa
  • Agenda:
    • Carlos propondrá uno o varios problemas sobre los que se trabajará en parejas.
    • Se realizarán varias iteraciones.
    • Al final de la sesión Carlos presentará y explicará su solución a todos los asistentes.
  • Plazas: Limitado a 25 personas, por riguroso orden de inscripción
  • Inscripción: Mandando un mail a Beatriz Lorente (blorente@ptwalqa.com)

¡¡Animaos que seguro que lo pasamos muy bien!!.

Aquí huele a cuco (III)

Cuando entras en una empresa nueva, descubres partes del código en cierto modo inexplicables. Muchas de ellas las achacas a tu poca experiencia con los entresijos de las aplicaciones que acabas de conocer. Otras, en cambio…

public void makeAppCrash() {
	DataAccessManager.getDbHelper().execSQL("select * form mamamam");
}

De este fragmento se extraen varias dudas:

  • ¿Por qué queremos que en producción se rompa la aplicación?
  • ¿Qué llevó a alguien a escribir “mamamam“?
  • ¿Por qué pone “form” en vez de “from“?

Muchos de estos misterios seguirán sin tener una respuesta. Mientras tanto, el código todavía sigue intacto en busca de alguien que descubra sus más profundos secretos

Los 10 mandamientos de Java

Quizás todavía hemos hablado poco de Sonar, pero es necesario indicar que se trata una de las herramientas indispensables a la hora de crear código elegante. Básicamente, esta utilidad nos permite analizar nuestros proyectos en busca de código poco eficiente o mejorable, ordenando estas infracciones (suena mejor que violaciones) por su gravedad (blocker, critical, major, minor e info).

Con esfuerzo, hemos conseguido eliminar todas las infracciones críticas de nuestros proyectos, pero como sabemos que volveremos a tropezar dos veces con la misma piedra, necesitábamos algún tipo de recordatorio que nos permitiera tener siempre en mente el no volver a cometer esas infracciones.

De ahí surgió la idea de crear una tabla con los diez mandamientos de Java. Aquí tenéis la versión final. Explicaré cada punto en detalle.

Los 10 mandamientos de Java
I. Thou shall not access non-static variables in a static manner.

Esta infracción se repetía bastante en nuestro código. Si tenemos un método estático , no debería poder acceder a variables que no están pensadas para llamarse de forma estática. El compilador lo permitirá, claro, pero manda al garete la filosofía de los métodos estáticos.

II. Do not write a static variable from an instance method. Ever.

Parecida a la anterior, pero al contrario. Si tenemos una variable estática, no deberíamos poder escribirla desde un método perteneciente a un objeto instanciado. Sirva de ejemplo:

private static String mTitle;
...
public void showDialog(String title, String message) {
   mTitle = title;

III. Thou shall not leave empty if-else/switch statements.

¿Cuántas veces habrá pasado? Dejamos un todo en el if y asunto resuelto. Pues a partir de ahora, pecado mortal.

if (item != null) {
   newPurchase();
} else {
   // no purchase yet
}

Aunque no lo pone, esto también se aplica a los bucles vacíos.

IV. Thou shall not repeat code in a if-else/switch statement.

A veces por dejadez, mantenemos dos bloques de un condicional exactamente iguales. Veamos un ejemplo con un switch:

switch(gafas){
   case 1: return "de lejos"; break;
   case 2: return "progresivas"; break;
   case 3: return "del cerca"; break;
   default: return "de lejos"; break;
}

Podría modificarse quitando el caso 1 o fusionándolo con el default.

V. Thou shall not leave a private method not being called from anywhere.

Sencillo: no creemos métodos que no sean utilizados en ninguna parte. Si el título del metodo tiene un rayica amarilla, mal asunto. Siguiente.

VI. Remember to not null-check a value which is already null.

Si estamos seguros al 100% de que algo tiene como valor null, no tiene sentido hacer una comprobación. Lo mismo para el caso contrario: si es imposible que una variable tenga valor null, resulta redundante el comprobarlo.

VII. Thou shall not use short variable names.

Pecadores todos aquellos que utilizáis nombres de variables como “cursor c”, “RelativeLayout rl” o “String s”. Quedan excluidas las variables de iteración dentro de un bucle.

VIII. Do not take the visibility of variables in vain

Qué bonito sería el mundo si todas las variables fueran public. Nos ahorraríamos más de un disgusto. Pero si una variable sólo se utiliza dentro de el entorno de una clase, debemos declararla como private, o arder en el infierno. Lo mismo con protected, claro.

IX. Remember to write javadocs and keep it holy.

Método que dejamos sin Javadoc, 10 flagelaciones.

X. Avoid duplicate literals, if it is repeating, create a variable.

if (numPiscinas == 1) {
   show("mensaje", 1);
} else if (numPiscinas == 2) {
   show("mensaje", 2);
} else if (numPiscinas >= 3) {
   show("mensaje", 4);
}

Si la cadena “mensaje” es usada en el código continuamente, mejor escribir una variable propia con la cadena, que seguro que nos resuelve la vida.

Y eso es todo. Podemos crear código sin hacer caso de estos mandamientos, y obtendremos un buen resultado. Pero seguro que si los seguimos a rajatabla, adquirimos unas costumbres de programación muy saludables. Por supuesto, estos puntos son cuestionables, no se trata de los más críticos, sino simplemente de los que más suelen repetirse en nuestro código. Os animo a que elaboréis vuestra propia lista de mandamientos y la colguéis bien alta para tenerla siempre en mente. Y para acabar, me despediré con una frase de Charles Reade:

“Siembra un acto y cosecharás una costumbre. Siembra una costumbre y cosecharás un carácter. Siembra un carácter y cosecharás un destino.”