sábado, 25 de junio de 2011

Música para correr

Hace un tiempo encontré el sitio jog.fm, que permite buscar música para correr, con la particularidad que busca la música más adecuada para el ritmo que uno elige.

Por ejemplo, se puede buscar música para correr a 6 minutos por km, y encuentra canciones que sirven para correr a ese ritmo.

También sirve para buscar música para otras actividades, como caminar o andar en bicicleta.

En el sitio se pueden escuchar las canciones, comprarlas en Amazon o iTunes, armar listas de reproducción (que no se como la escucho mientras voy corriendo...), escuchar listas de otros usuarios, etc.

Además tienen una aplicación para el iPhone, pero no me convenció demasiado. La aplicación procesa toda la biblioteca, y cuando uno va a hacer ejercicio puede decirle a que ritmo quiere correr o que detecte el ritmo automáticamente. Supuestamente se van a reproducir las canciones adecuadas.

Digo supuestamente porque hice una prueba y me parece que no me funcionó muy bien. Algunas mejoras que le haría:

  1. poder elegir música de una lista, yo ya tengo una que se llama "música para correr"...
  2. tener alguna forma más fácil de decirle que canciones no quiero que use, por ejemplo un botón en el reproductor.
Con esos dos cambios sí sería más usable.

Sobre la corrida

En mi punto más alto (diciembre 2010 - enero 2011), llegué a correr 7km hasta tres o cuatro veces por semana, y corrí una carrera de 10km, de esas que hay un montón en primavera.

Desde ahí, vengo bajando. Primero en frecuencia y después en distancia. Es impresionante como se va perdiendo el estado físico por la falta de ejercicio. Ahora estoy corriendo una vez por semana (sábado o domingo, porque entre semana es imposible), y corro 5.7km. Pero cada vez cuesta más...

Lo bueno es que aumentar la distancia y mejorar el tiempo es algo relativamente fácil, si uno tiene la constancia necesaria. Cuando empecé, en agosto de 2010, hacía un recorrido de 2.5km, y a veces no me daba para hacerlo todo corriendo. De a poco fui subiendo, primero 3.5km, 4.5km, 6km, hasta llegar a los 7km y la carrera.

Así que cuando vuelvan los días más largos, trataré de salir a correr más seguido para estar mejor que en mi mejor época :)

Una mención especial

Hay dos canciones que se ajustan particularmente bien a mi ritmo de corrida. No las encontré en jog.fm, ya las tenía en mi biblioteca. Se las dejo para que las escuchen (en un dispositivo que soporte Flash...):

 The Ramones - I Wanna Be Sedated

 Astroboy - Did I Tell You?

jueves, 16 de junio de 2011

Subversion vs. Git

Cuando se habla de control de versiones, hay dos grandes formas de encarar el tema: centralizado o distribuido.

Durante un año estuve usando Git (un sistema de control de versiones distribuido), y ahora hace un mes y medio que estoy usando Subversion (que es centralizado).

Lo que sigue es un intento de comparar ambas herramientas, desde mi punto de vista personal, sin intención de hacer una comparación exhaustiva ni del todo objetiva.

Lo primero que hay que aclarar es que ni Git es del todo "distribuido" (ya que se suele mantener un repositorio centralizado), ni Subversion es totalmente centralizado (porque se trabaja sobre una copia local). La diferencia en realidad es donde ocurren las operaciones (branch, commit, etc.). En el caso de Git (y los demás que son distribuidos como Mercurial), las operaciones son locales, mientras que en Subversion ocurren en el servidor.

Esto quiere decir que en Git puedo hacer N commits antes de mandar los cambios al servidor, mientras que en Subversion cada commit se hace en el servidor.

Algunas consecuencias de esto son que:
  1. En Subversion los números de cada revisión son consecutivos, mientras que en Git cada commit se identifica con un UUID
  2. En Git puedo hacer commits intermedios, sin necesidad de tener una versión "estable", porque puedo hacer el push al final. En Subversion, cuando hago un commit tengo que tener una versión consistente antes de hacer el commit para no romper nada que pueda necesitar alguien más. Ese commit puede ser eventualmente bastante grande.
Otra diferencia es que en el caso de Git, no es posible hacer un "checkout" parcial, lo que es bastante natural en Subversion. Por lo tanto, si el repositorio es grande, obtener la versión inicial puede ser bastante más costoso con Git.

Una de las cosas que no me convencen del todo de Subversion, es que no puedo dejar un cambio por la mitad, para hacer por ejemplo un arreglo en la última versión estable. En Git, aunque tenga cambios pendientes, puedo moverlos a un nuevo branch, arreglar lo que sea que estuviera roto, y volver a poner arriba de eso los cambios que moví temporalmente. En Subversion, la mejor alternativa que encontré a esto, sería hacer un checkout en otro directorio para hacer el arreglo ahí.

Eso nos lleva a otra diferencia: en Git hacer un branch es totalmente natural. De hecho, cada copia local puede verse como un branch. Llevado al extremo, hay quienes hacen un branch para cada nueva feature que van a estar trabajando. En Subversion, un branch se usa solamente para congelar una versión, y no es posible hacerlo de forma local.

Por último, hace unos días apareció esta noticia, que dice que GitHub es el repositorio más popular (para proyectos open source al menos). Puede ser un punto a considerar al momento de elegir.

En conclusión, si me dan a elegir, me quedo con Git. Pero lo verdaderamente importante, sea cual sea la herramienta que se use, es tener algún tipo de manejo de versiones.

Si alguien se quedó con ganas de saber más, acá les dejo una comparación más seria de los dos.

miércoles, 8 de junio de 2011

User Controls para iOS, parte 2

Hace unos días les contaba que estuve trabajando en un User Control para el generador iOS (una galería de imágenes), y que se estaba trabajando en un mecanismo para poder definir controles desarrollados por terceros.

Hoy ese mecanismo ya está funcionando (build superior a 44260), y de hecho en este momento tenemos 4 user controls externos, tres para listas (image gallery, maps y chart)[1] y uno para atributos (star rating).

El código de los user controls está disponible y se distribuye con GeneXus, los pueden ver en la carpeta iOS/UserControls/src (build superior a 44297)

Como decía más arriba, hay dos tipos de user controls: los que aplican a una lista y los que aplican a un item (un atributo por ejemplo). La forma de implementarlos es distinta, y de hecho heredan de clases diferentes.

Así que si alguien tiene alguna idea de un user control que quiera desarrollar, me avisa que le paso la versión alfa de la documentación. Eventualmente quedará disponible en el Wiki, pero por ahora no está...

Les dejo una foto del Star Rating, que fue el otro control en el que estuve trabajando.


[1] Cabe aclarar que los controles map y chart no los hice yo... yo solo los moví a otro proyecto.

Actualización, 9/6/2011 9:50: @a_cardoso actualizó la documentación en el wiki. Pueden ver acá y acá.