Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: python

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.

Observer para compilar automáticamente cada vez que guardas

Los que hayan usado el ndk, me comprenderan. La cuestión es que cada vez que quieres hacer un cambio tienes que compilar la librería. A veces resulta muy pesado, ya que después de esto tienes que limpiar y construir tu proyecto Android que usa dicha librería. Un proceso la mar de ligero si tu proyecto es mínimamente grande.

Tras llevar un tiempo trabajando con esto pensé que sería interesante tener un observer que escuche y que compile el proyecto cada vez que guarde. Ya sólo me tendré que preocupar de hacer los pasos pertinentes en Eclipse para construir el apk con la librería recién compilada.

Para hacer esto elegí python, ya que es un lenguaje realmente potente y fácil de ejecutar desde la consola. Tras buscan un poco opté por usar WatchDog, que es una librería que observa cambios en un fichero. Solo hay que escuchar y cuando se realice la acción de grabar lanzar la compilación. Se ha programado para que escuche cambios en un directorio entero, puedes cambiar para limitar al fichero con el que estés trabajando.

Os dejo el código en github. Es muy sencillo de usar y muy potente.

La mejora más inmediata que se me ocurre es poder mostrar visualmente si la compilación ha ido bien o mal.

Comentarios? Sugerencias?

Primer Walqa Coding Dojo

Así es, el viernes pasado, día 21 de enero, se celebró el primer coding dojo realizado en el Parque Tecnológico Walqa, dirigido por Carlos Ble.

Un dojo (道場, literalmente “el lugar de la senda”) es un sitio donde poder practicar y entrenar una disciplina concreta. Simplemente son centros donde se pueden reunir personas con ganas de aprender. Como en todos sitios, es normal que haya gente con más conocimientos que otros, pero esto es precisamente lo que se busca: que el conocimiento puede transmitirse entre los asistentes.

En nuestro caso, las características de nuestro dojo eran las siguientes:

  • Se va a diseñar y programar un problema (o kata) llamado FluentAPI.
  • Debe realizarse por parejas (pair programming).
  • Debe utilizarse TDD.
  • Se realizará en periodos de tiempo determinados, tras lo cuales deberemos cambiar de pareja.
  • No se indicará cuánto tiempo dura cada periodo (así tampoco hay ansias por terminar)

Al evento asistieron más de 30 personas de distintos perfiles y distintas procedencias (Indra, Tafyesa, Universidad de San Jorge, Telefónica I+D,…)

El problema o kata elegido para la ocasión fue el siguiente:

Queremos conseguir una API para acceder a una lista de objetos que sea fácil de leer al ojo humano, al estilo de:

  1. select(“name”).from(users)
  2. select(“name”).from(users).where(“age”).greater_than(18)
  3. select(“name”).from(users).where(“surname”).contains(“rodriguez”)
  4. select(“name”).from(users).where(“age”).greater_than(18).and(“location”).is(“san francisco”)

Y a ello nos pusimos. En el primer periodo parecía que la cosa no terminaba de arrancar, ya que el problema era difícil de abordar en un principio. Por las mesas se veían lenguajes tan dispares como Java, Ruby, PHP, .Net o Python.

Al sonar la alarma y acabar el primer pomodoro, nos dirigimos a una sala habilitada por Walqa con aperitivos y bebidas, que de seguro nos sirvió para descansar y consultar algunas dudas (como el uso de import static en Java, que resultó fundamental para la resolución del problema)

Acabadas las sesiones de programación, nuestro sensei Carlos Ble se puso a los mandos del portátil y se dispuso a ejecutar una forma de resolver el problema en Python. Mientras, los asistentes observaban el proyector con lo que iba realizando, en medio de un silencio solemne.

Tras lo cual, Carlos dejó continuar la resolución a dos de los presentes: Dani y Rubén, que se enfrentaron a una modificación del problema ante todos los asistentes.

Y hasta aquí dio tiempo. Los participantes salimos muy contentos con la experiencia y alguien llegó a decir que había sido el coding dojo con más afluencia de los realizados en España. ¿Será verdad? 🙂

P.D: nuestra intención es que este sea el primero de una larga lista de eventos.

P.P.D: tenemos nuestro propio hashtag: #codingdojohuesca

Eficiencia en Google App Engine: Appstats

Nuestra elección a la hora de subir datos a la nube fue Google App Engine, el servicio que permite ejecutar aplicaciones web en la infraestructura de Google. El desarrollo  en esta plataforma presenta ciertas características que obligan a cambiar el chip desde un primer momento y que nos fuerzan implícitamente a tener en cuenta la eficiencia y, sobretodo, la escalabilidad. Dicho esto, siempre hay momentos a lo largo del camino en los que uno se plantea revisar la eficiencia global de la aplicación para mejorar su tiempo de respuesta, reducir los consumos de cpu y, de paso, reducir la factura cobrada por Google.

La primera vez que nos enfrentamos a esta situación decidimos usar cProfile y pstats para estudiar los tiempos de nuestro código Python centrándonos en aspectos clásicos como optimización de búsquedas, mejora de la eficiencia en la manera de concatenar cadenas, reducción del número de iteraciones en un bucle…la verdad es que de poco nos sirvió, ya que, veíamos que la mayor parte del tiempo de proceso se gastaba en algo que en el profile se indicaba con líneas como esta:

_apphosting_runtime___python__apiproxy.Wait

Es decir, que la mayor parte del tiempo nuestra aplicación estaba esperando a que se completase el proceso realizado por una llamada a alguna API de Google.

Estudiando en detalle el lugar del código en el que aparecen estas líneas, se puede averiguar a qué API se están refiriendo pero, por suerte, todo ese trabajo dejó de ser necesario gracias al descubrimiento de Appstats:

Appstats es una herramienta creada por  Guido van Rossum (creador de Python y actual empleado de Google) que forma parte del SDK y nos permite ver en detalle en qué emplea realmente el tiempo nuestra aplicación mediante el estudio de las RPC, es decir, las llamadas remotas que nuestra aplicación hace a las distintas API’s de Google. Su instalación es muy sencilla y podemos instalarla incluso en producción porque consume muy pocos recursos.

En  el siguiente video, el propio Guido, nos explica las bondades de esta herramienta indispensable:

En el video se muestra cómo instalar y usar la herramienta, una breve explicación de su funcionamiento y consumo, posibilidades de configuración y algunos ejemplos de uso como, por ejemplo, detección de ciertos patrones de ineficiencia comunes a muchas aplicaciones : Patterns of Doom!