viernes, 30 de marzo de 2012

Game of Thrones: el libro y la serie de TV

Acabo de terminar de ver la primera temporada de Game of Thrones, después de haber leído el libro.

Cuando empezaron a dar la serie Game of Thrones en HBO parecía interesante, y me dieron ganas de verla, pero la verdad cada vez me parece más complicado tener un horario fijo para poder ver algo en la tele[1]. Así que, después de ver el primer capítulo, no vi más...

Poco tiempo después me enteré que estaba basada en un libro, así que me puse a leer el libro antes de ver la serie.

El libro está bueno. La historia en sí es atrapante, pero después de leer las 700 páginas, la sensación que me quedó es que fue una especie de introducción, que quedaron muchos cabos sueltos. Claro, es el primero de 5 libros (hasta ahora...), y como tal, no es la historia completa.

Después de leer el libro, me puse a ver la serie gracias a Cuevana. Es una excelente adaptación, bastante fiel a la historia original, y creo que vale la pena verla aunque no se haya leído el libro. La gran ventaja que tiene el libro es que permite profundizar mucho más en los personajes, y por las cosas que pasan por la cabeza de cada uno de ellos.

Creo que haber leído el libro primero fue una buena decisión, y pienso repetirla para la segunda temporada que está por comenzar.

[1]Nota aparte: hay una gran oportunidad de negocio para el que resuelva bien el tema de distribuir contenido a demanda. No me refiero a la solución técnica, que ya existe (por ejemplo Netflix o Cuevana), sino a entregar contenido de calidad de forma simple para el usuario y con un costo razonable. Me llama la atención que las operadoras de cable no lo hayan visto todavía...

jueves, 22 de marzo de 2012

Detectar problemas de memoria con Instruments

En Objective-C, cuando se maneja la memoria "a mano" con retain/release/autorelease, es bastante común que aparezcan problemas de memoria.

Estos problemas no deberían aparecer si se usa ARC (Automatic Reference Counting) en el proyecto, ya que todo el manejo lo hace automáticamente el compilador.

Los problemas que pueden aparecer son de dos clases:
  • Leaks: un objeto se retiene más veces que las que se libera, por lo que queda memoria en uso, a la que no se puede acceder.
  • Zombies: un objeto que se libera más veces de las que se retiene, por lo que la aplicación da un error cuando se le intenta mandar un mensaje.
Los Zombies en general son más fáciles de detectar ejecutando la aplicación, porque la aplicación termina con un error. De todas formas, a partir del error, no siempre es fácil detectar donde se produce o por que.

Para ambos casos, Xcode viene con una aplicación llamada Instruments, que permite detectarlos.

Para poder ejecutar Instruments, se debe ejecutar la aplicación con "Profile" (en lugar de "Run"), lo que va a mostrar una pantalla como sigue:

En esta pantalla se elige que es lo que queremos buscar (Leaks o Zombies), y luego se abre la ventana de Instruments correspondiente y la aplicación en el Simulator.

Al ejecutar la aplicación, si aparece algún problema de memoria, se va a ver en esta ventana.

Por ejemplo, cuando tenemos "leaks":

En la parte superior de la pantalla, nos muestra en azul la memoria que va usando, y en rojo cuando aparece un "leak".

En la parte de abajo, muestra los objetos que no se liberaron. Ahí se puede ver la clase del objeto, quien fue la biblioteca responsable, y donde fue que se produjo el "leak". Si hacemos click en la flechita al lado de Address, entonces muestra toda la historia de ese objeto: cuando fue que se creo, cuando se retuvo y cuando se liberó. Eso permite tener una idea bastante clara de donde fue que se produjo el problema.

Si bien no nos da la ubicación exacta de donde está el problema (es decir, donde se debió haber liberado la memoria y no se hizo), da mucha información que permite encontrarlo de forma relativamente fácil.

Lo mismo ocurre con los "zombies", cuando la aplicación da un error de tipo "EX_BAD_ACCESS", es seguramente porque tenemos un objeto que se liberó de más.

Cuando corremos la aplicación con Instruments, si aparece un "zombie" muestra una cartel indicándolo, y si hacemos click en la flechita, muestra toda la historia del objeto, cuando se le hizo "retain" y "release", lo que permite encontrar de forma bastante rápida donde está el problema.


Con Instruments se pueden hacer muchas más cosas. Estas dos tal vez sean las más comunes, pero es una aplicación que tiene mucha potencia. Vale la pena dedicarle un rato, para ver las cosas que tiene. La parte de "Leaks" sobre todo es fundamental para encontrar problemas de memoria, que si no, son muy difíciles de detectar.

miércoles, 7 de marzo de 2012

Administrando el correo con GMail

Si hay algo que me gusta tener ordenado es el correo. No sigo la filosofía de inbox zero (ni soy experto en el tema), pero me gusta tener la bandeja de entrada limpia en todo momento.

La idea de esta nota es contar como me organizo, ya que creo haber encontrado una metodología que me convence, y capaz que le puede servir a alguien más. Obviamente si alguien piensa que se puede mejorar, escucho los comentarios.

Para el correo, tanto personal como laboral, uso Gmail. En algún momento probé algún otro cliente (Thunderbird y Sparrow), pero no lograron convencerme del todo. Gmail tiene el Priority Inbox, que facilita bastante la organización.

El Priority Inbox de Gmail permite definir hasta cuatro secciones, que en mi caso son:

  • Important and unread
  • Starred
  • etiqueta Follow up
  • Everything else
En Important and unread va eso, mensajes que Gmail etiqueta como importantes y que todavía no leí. Hay que entrenar un poco a Gmail para que sepa que cosas tienen que estar marcadas como importantes y cuales no, pero después de un tiempo el algoritmo es bastante bueno (aunque igual a veces se equivoca).

En esa sección no puede haber nada... Cuando chequeo la bandeja de entrada, si hay un mail ahí, entonces hay que prestarle atención. Las opciones son varias:

  • Si el mail no era importante, entonces lo primero es marcarlo como tal, para que Gmail vaya mejorando la heurística.
  • Si es un mail informativo, pero no requiere ninguna acción de mi parte, se lee y se archiva. En caso que tenga información que voy a necesitar más adelante, puede quedar en la sección de Everything else como leído.
  • Si el mail requiere una acción, pero no urgente, se le pone la etiqueta Follow up para verlo más adelante.
  • Si requiere atención urgente, y no estoy con nada urgente en el momento, se lo marca como Starred. Si ya estoy con otra cosa, entonces va también a Follow up.
Para los mails sin leer que aparecen en Everything else (los que Gmail no marca como importantes) se sigue el mismo procedimiento, pero pueden quedar sin leer si estoy con algo urgente en el momento.

La sección Starred es para las cosas que estoy viendo en el momento. Por ejemplo, cuando empiezo a trabajar en un issue, el mail correspondiente lo marco con una estrella, y cuando termino lo desmarco.

Obviamente en esta sección no puede haber mucha cosa. Es difícil que esté activamente en más de un tema a la vez, por lo tanto solo pueden estar los mails que corresponden a ese tema. También puede haber algún tema que tenga en espera de una respuesta si pienso que va a llegar rápido, pero si demora mucho, va para Follow up o se archiva (ya va a llegar otro mail con la respuesta...).

Cuando no hay nada en Important and unread ni en Starred, entonces le toca el turno a Follow up. De los mails que están ahí, se toma el que parezca más importante, se le saca la etiqueta de Follow up y se lo marca como Starred.

En este momento tengo:
  • 0 mails en Important and unread :)
  • 2 mails en Starred (uno de un tema que empecé a ver y todavía no terminé y otro esperando una respuesta)
  • 10 mails en Follow up
  • 11 mails en Everything else, todos leídos.