Archivo de la categoría: Software

Buscando con DuckDuckGo

2 respuestas

[DuckDuckGo logo]Desde hace una semana estoy usando DuckDuckGo como reemplazo de Google para buscar.

No es un servicio nuevo, pero en su momento no le había dado mucha bola. Pero resulta que Google de a poco fue perdiendo la magia. Se nota cada vez más que lo único que quieren es enrostrarte un anuncio publicitario. Ojo, siempre ese fue su objetivo principal, pero había una época en que lo disimulaban, en que te la ponían sin que te dieras cuenta, casi.

Ahora es más evidente. Cada vez hay más resultados esponsoreados. Los resultados de búsqueda están cada vez más sucios de metadata de otros servicios, todo entreverado. Google cambió sus políticas de privacidad y si bien es cierto que son más simples, es como que ahora tienen piedra libre para usar todo lo que saben de vos para influenciar en como te muestran un resultado de búsqueda. Tal vez lo hicieron siempre, por atrás, pero ahora es explícito.

Google se caracterizaba por una página de resultados limpia, pristina, simple, minimalista. En los últimos tiempos han ido agregando iconitos y previews y colores, y +1′s y paneles y barras y… está empezando a suckear.

Así que decidí probar DuckDuckGo, un poco por capricho. El diseño recuerda mucho al de Google de los primeros tiempos. ¿Los resultados son buenos? Mirá, lo vengo usando hace solo una semana, y te diría que para el 99% de las búsquedas, sí. No se si es mejor o peor que Google, pero me sirve, me funciona.

En cuanto a privacidad tiene cosas muy piolas, les recomiendo leer al respecto, pero dos cosas que me parecieron fantásticas son la posibilidad de configurar DuckDuckGo para que no le informe al sitio de destino que lo visitás de parte de él, y la posibilidad de usar su sintaxis “bang” para especificar un proxy directamente en la búsqueda, haciendo que el tipo pase por ese proxy, anonimizando (en parte) lo que estás haciendo.

¿Y que es eso de la sintaxis “bang”? Algo que está más bueno que el dulce de leche, que es re-natural y re-útil. Es básicamente una forma de decirle a DuckDuckGo “buscá acá”, o “buscá este tipo de información”, etc. Ejemplos:

  • Buscame The Lord Of The Rings en IMDb:
!imdb the lord of the rings
  • Buscame un torrent con la imagen de ubuntu 11.10:
!torrent ubuntu 11.10
  • Buscame posts taggeados “Caminito” en Tumblr:
!tumblr caminito

… y así. Y esa sintaxis también funciona para cosas como !convert, !translate, y otros verbos. Hay cientos de términos “bang” para usar, en las categorías y temas que quieras, ciencia, lenguajes de programación, multimedia, noticias. ¿Y lo mejor? ¡Qué son obvios! O sea, no es que tenés que estudiar la lista. A mi me viene pasando que de pronto digo “¿si le mando !flickr buscará en Flickr?” Y resulta que sí, y tal vez con Flickr es obvio, pero encontré intuitivo, natural, pergarle a cosas más específicas.

Y eso no es todo, la sintaxis !bang es solo uno de los goodies que ofrecen; podés escribir queries con cálculos, con conversiones, con temas relacionados con geografía, fecha y hora, etc., etc.

Una semana es poco tiempo para evaluar algo tan importante como un servicio de búsqueda en internet, pero la verdad que por ahora se queda, y como primera opción. Ya agregué el Search Plugin de DuckDuckGo a Firefox para tenerlo en la barra de búsqueda, y lo puse como opción predeterminada.

Enviar un artículo a Read It Later desde Google Reader

Deja una respuesta

Mi servicio preferido para llevar un registro de “cosas que encontré en la web y que me quiero acordar de leer” es Read It Later. Antes usaba Instapaper, pero más que nada por un tema de soporte oficial en celulares con Android, hace unos meses me cambié a Read It Later.

Hace rato que tengo configurado en la barra de marcadores de Firefox un bookmarklet que me permite enviar a Read It Later la página que estoy leyendo, y en general es lo que uso. El tema es que cuando estoy leyendo un artículo en Google Reader, tengo que abrir el artículo en una solapa/ventana nueva (para ir a la fuente original), y de ahí hacer el envío.

Si bien Google hizo muchas cagadas con el rediseño de Reader de hace unas semanas, hasta que le encuentre un reemplazo, lo sigo usando. Y resulta que han hecho algunas cosas buenas. Por ejemplo: al pie de cada artículo hay una opción de “Send to” que permite enviar la nota a diferentes servicios. Desde la configuración de Google Reader se pueden habilitar y deshabilitar que servicios queremos ver. Están los clásicos: Twitter, Facebook, Tumblr, Digg… hasta está Instapaper, pero no está Read It Later.

Si miran en la configuración al pie de los servicios disponibles, verán que no todo está perdido. Google previó crear “sitios personalizados”, con lo cual es posible definir nuevos servicios. Y resulta que la gente de Read It Later ya documentó como hacer para agregar su servicio a la lista.

Hay que crear un enlace personalizado con la siguiente información:

Name: Read It Later
URL: https://readitlaterlist.com/save?url=${url}&title=${title}
Icon Url: http://readitlaterlist.com/favicon.ico

… y listo, con eso aparece Read It Later como “sitio destino” dentro de Google Reader, y se pueden enviar los artículos sin necesidad de abrir la fuente original primero.

Read It Later dentro de Google ReaderFuente: Add Read It Later to Google Reader’s Send To Dropdown

Sí, ya se: hay una extensión oficial para Firefox que integra Read It Later con el browser, pero, cuestión de gustos, personalmente prefiero el bookmarklet antes que una extensión…

Luchando con la memoria interna del HTC Desire

3 respuestas

Hay dos cosas que no me gustan de mi HTC Desire: una es la autonomía de la batería, la otra, el espacio de almacenamiento interno.

Bueno, hay tres cosas: La tercera es el GPS, pero no termino de decidir si lo lento que es el GPS para obtener un lock, y la frecuencia con la que se desengancha es un problema de software, de hardware, o que… y no es tan de vida o muerte. Lo puteo mucho cuando salgo a correr, pero para lo demás, zafa.

Volvamos a los dos temas originales:

El tema de la batería más o menos quedó aceptablemente resuelto cuando actualicé a Gingerbread. Estoy usando una ROM custom basada en el build oficial de Gingerbread liberada por HTC para el Desire, específicamente esta, que es del mismo desarrollador de la ROM que usaba de Froyo.

Digamos que con esa ROM obtengo unas 8hs de uso intensivo, o unas 24 a 36hs de uso normal (que en mi caso tiende a ser de moderado a bajo). Si bien está lejos de lo que me gustaría, sirve. Sí, en la práctica implica que lo tengo que cargar todos los días, pero bueno… ahora con Gingerbread puedo obtener esa autonomía estando conectado prácticamente todo el día (con Froyo para lograr eso usaba permanentemente Green Power para solo activar la conexión de datos durante 2′ cada 30′).

Y todavía podría mejorarlo más, si flasheara el “Powersaving Mod” de esta ROM y/o utilizara alguna aplicación que aprovecha el rooteo del teléfono para hacer under-clocking cuando la CPU o la pantalla están idle. Calculo que con eso mejoraría mucho, pero todavía no me puse a jugar con eso. Y siempre puedo recurrir a Green Power (con Gingerbread casi no lo estoy usando… pero la opción está). Como decía al principio, la autonomía que tengo ahora no me vuela la peluca, pero me alcanza. Es manejable.

Pero queda un tema… y es el espacio de almacenamiento interno. Con esta ROM que estoy usando, instalé también A2SD+, que básicamente usa una partición extendida en la SD card, y mueve ahí las aplicaciones y el caché Dalvik, pero no los datos de las apps. Eso mejora mucho la cuestión, pero no alcanza. Hay dos cosas que con el correr de los días se van descontrolando:

Cache

El caché de algunas aplicaciones crece mucho. Algunas apps tienen el cache en la memoria interna, otras en la externa, otras en ambas. Depende. Pero hay ciertas apps que tienen una tendencia a entrar a comer megas y megas de cache en la memoria interna: Google Reader, Internet, Facebook, Market, Google Maps.

Para resolver esto, instalé CacheCleaner NG (requiere root para ser realmente útil…) Lo que tiene de bueno esta app es que permite ver el caché usado aplicación por aplicación, interno y externo, y configurar individualmente cual quiero que borre y cual no, también aplicación por aplicación. Cada N días, le pego una mirada, y libero unos cuantos megas (con una semana típica de uso suelo estar con entre 10 y 15MB usados para cache, que obviamente sigue creciendo si lo dejo). CacheCleaner NG puede configurarse para iniciarse automáticamente y limpiar con cierta frecuencia, pero por ahora, lo estoy haciendo manualmente.

ANR_history.txt

Esto es un misterio. Intrigado por saber que otra cosa iba comiendo espacio sin parar, día a día, casi que hora a hora, sin prisa pero sin pausa, empecé a prestarle más atención a la info que da DiskUsage. Lo venía usando hace bastante, pero no me había percatado que, si soy root, puedo usarlo para analizar la carpeta /data/data, que es donde están los datos de las aplicaciones. Y ahí me encontré con este señor archivo:

/data/data/com.android.htcprofile/anr_history.txt

Google no me ayudó mucho, pero aparentemente es una especie de log de errores. De hecho, es un archivo de texto, que tiene stack traces de aplicaciones con problemas. Aparentemente, “anr” es “application not responding”. Tiene sentido… historial de aplicaciones que no responden. Lo estuve mirando un poco, y hay errores de java de todo tipo, de prácticamente todas las aplicaciones. No tengo idea que tiene que ver con HTC Profile; tampoco tengo muy claro que es HTC Profile. Lo que si tengo claro, es que si no lo blanqueo cada tanto, crece sin parar, mal. Y también estoy casi seguro que esto empezó a pasar con la ROM basada en Gingerbread. ¿Será un bug de la ROM que liberó HTC? ¿Hay forma de apagar ese log de errores? Como les decía, Google no me fue de ayuda. Sí encontré un par de foros en los que aclaran que no conviene borrarlo directamente, porque luego podría tener algún problema de permisos (¿tal vez alguna aplicación o librería de HTC luego no lo encuentra y falla?). No comprobé lo de los permisos, pero por las dudas, no lo borro, lo trunco. Me abro una consola local con ConnectBot, y hago esto:

$ su
# echo "" > /data/data/com.android.htcprofile/anr_history.txt

… y santo remedio. Por algunos días / semanas.

Odio tener semejante teléfono que me salió unos buenos mangos y tener que estar haciendo este tipo de chanchadas. Ya decidí que mi próximo teléfono (si tiene Android) va a tener que tener espacio de almacenamiento interno de verdad (y no los 140MB que tiene el HTC Desire, que son un chiste de mal gusto).

Masticando fotos

Deja una respuesta

Estoy en vías de actualizar mi cámara de fotos. Los por qué, y cual es la cámara que quiero serán materia de otro post (¡suspenso!), ya que la decisión no fue fácil, y tiene varias aristas. Y además es una excusa para hacer otro post y hacer de cuenta que tengo un blog y escribo regularmente (?)

Pero una de las primeras cuestiones con las que me topé, es que si pretendía ganar en “profesionalismo” de la cámara, iba a tener que sacrificar zoom. Mi cámara actual, una Canon PowerShot S5 IS, entra en la categoría bridge/prosumer, pero a su vez, super zoom. Tiene un zoom de 12X (sí, OK, hoy no es tanto para una super zoom, pero cuando la compré, era una barbaridad).

Y resulta que las cámaras compactas más pro, como las “PowerShot G” de Canon o las “Coolpix P” de Nikon, tienen bastante menos zoom. Y las cámaras reflex vienen con un lente estándar con mucho menos zoom, y si bien se le puede poner el lente zoom que uno quiera, hay que considerar dos cosas: el precio del lente, y que un lente de más de 300mm (o incluso menos) para una reflex es un Señor Lente (en tamaño y peso), no muy “trekking friendly”. Y lo mismo que aplica a las reflex aplica a las nuevas mirrorless / EVIL / micro four thirds / etc.

Así que de entrada quedó claro que si iba por una compacta pro (no super zoom) o por una reflex, iba a sacrificar longitud focal.

Inmediatamente me surgieron un montón de preguntas: ¿cuánto uso el zoom de mi cámara? ¿qué porcentaje de fotos saco con un zoom óptico mayor a 5X? ¿qué valor tienen para mi las fotos que saqué con un zoom grande, tipo 10X, 12X? ¿son fotos buenísimas que no querría haberme perdido por nada del mundo?

Algunas de esas preguntas eran complicadas de responder con certeza, pero básicamente decidí asumir el riesgo y seguir mi investigación sobre cámaras bajándole la prioridad al tema zoom. Tenía la impresión subjetiva de que no era un tema tan importante.

En algún momento, ya ni recuerdo como, porque en las últimas semanas he leído una cantidad escandalosa de reviews, opiniones, blog posts, etc., etc. sobre cámaras, caí en este interesante artículo: Photo Statistics: Aggregating EXIF data to see how I shoot photos. Y eso me abrió el camino a encontrar una respuesta certera a mis preguntas/dudas sobre como aprovecho la longitud focal del lente de mi cámara actual. Resulta que…

  • … las fotos más importantes / interesantes las tengo subidas a Flickr.
  • … Flickr expone los datos EXIF de las fotos (a menos que los ocultes, cosa que yo no hago).
  • … Flickr tiene una API que permite acceder por software a la información de las fotos, sin necesidad de tener que mirarlas una por una en la web
  • … Python es un lenguaje de programación hermoso y divertido, que últimamente tengo medio olvidado, y en el que es realmente muy fácil escribir un programita que acceda a mi cuenta de Flickr, y recupere la metadata EXIF de todas mis fotos, los mastique, me de las respuestas que busco, y encima me las grafique.
  • … hace rato que busco alguna excusa para volver a escribir algo simple en Python, para recordarme a mi mismo que programar puede ser muy divertido cuando no tenés que lidiar con problemas boludos de clientes idiotas y/o hardware lento y/o restricciones de Microsoft :)

Así que puse manos a la obra, y en un par de horas tenía 80 líneas de Python que resolvían el tema de bajar los datos de Flickr. Considerando que hacía rato que no escribía nada en Python desde cero, y que no conocía las bibliotecas que necesité usar (principalmente, FlickrAPI, aunque alguna vez, en otra vida, usé ese código como base para armar un Remember The Milk API), me di por satisfecho.

Dejé el script corriendo un largo rato (bajar la info de todas las fotos no es muy rápido, y encima el script no tiene absolutamente ninguna optimización, y tampoco estoy seguro de estar usando la API de Flickr eficientemente y no estar haciendo requests al pedo), y terminé con toda la data que necesitaba en formato JSON.

El resto fue fácil: levantar esa data, y empezar a obtener las respuestas que necesitaba (usando Python también, ¡obvio!). Y hoy estuve jugando un rato con matplotlib y haciendo algunos dibujitos con la data.

Pasen y vean que lindas tolderías:

(gráfico de Apertura vs Longitud Focal)

Apertura vs Longitud Focal

Conclusiones sobre fotografía

No uso mucho el zoom. De un total de 1800 fotos en Flickr tomadas con la S5 IS, solo un 17% están tomadas con un zoom mayor a 5X. Y si bien porcentualmente 17% es bastante, una rápida mirada por varias de esas fotos me confirma que no son obras maestras. Las únicas fotos en las que el zoom 12X garpó y mucho, fueron en un par de fotos de la luna. Así que a lo sumo tendré que sacrificar el fotografiar la luna.

Esto es consistente con el tipo de fotos que saco: paisajes, macros, algún que otro retrato. Todas situaciones en las que el zoom se usa poco y nada. Las longitudes focales largas están normalmente asociadas con “action shots”, deportes, y fotografía de “vida salvaje”, y es un tipo de fotografía que no practico, o porque no es mi tema, o porque si bien me alcanzaría el zoom, mi cámara está limitada en otros aspectos que también son clave en esas situaciones: una buena velocidad de disparo, una buena velocidad en obtener foco, buena calidad de imagen con ISOs altos, por ejemplo.

En resumen: creo que podría vivir con un zoom moderado.

Conclusiones sobre programación

Programar en Python es fácil y divertido. Esto ya lo sabía, pero se me estaba olvidando.

Programar para resolver algo que te interesa resolver a vos es mucho más interesante que programar para resolver algo que a otro le interesa que le resuelvas. Otra cuestión que debería tener más presente, aunque parezca una verdad de perogrullo.

Programar concentrándote en resolver tu problema, y no en convencer a un compilador de que estás resolviendo el problema de la manera correcta (i.e., programar con tipado dinámico vs programar con tipado estático) permite llegar al resultado mucho más rápido, y podés ocuparte de las refinaciones después. Otra perogrullada y van…

No voy a publicar el código porque los tres o cuatro scripts que hice son un asco y me da vergüenza. Tal vez invierta algo de tiempo en convertirlos en algo que califique de “programa”, y no de revoleo-de-sentencias-de-python, y los suba a algún lado. En algún momento. Pero no se si vale la pena. Anyway, si estás interesado en conocer más detalles sobre algo de todo esto, preguntá, y vemos…

GMail + OfflineIMAP + Evolution

2 respuestas

Finalmente, después de bastantes experimentos, creo que logré una configuración de manejo de correo electrónico en la laptop que me satisface. Y no te dejes engañar por el "Evolution" del título: En realidad, bastante de la experiencia aplica a cualquier MUA, o a cualquiera que quiera independizarse del MUA (ver "Bonus track" final), o simplemente a cualquiera que quiera tener un backup del correo de GMail local accesible incluso off-line.

Background

Mi cuenta de correo principal, la que más uso, está en GMail. La aplicación web está excelente, y ahora que me estoy acostumbrando a los "atajos de teclado" (¿por qué tardé literalmente *años* en tratar de aprenderlos e incorporarlos a mis dedos?), aún mejor. Pero así y todo, me gusta sentir que no dependo de una conexión a internet para acceder al correo histórico, y me gusta tener un backup, con lo cual necesito que el correo esté bajado en mi disco, para poder accederelo con algún MUA.

Hasta hace unas semanas, accedía a GMail con Evolution usando POP3. Desde que empecé a usar GMail que hacía esto. Y tenía múltiples filtros de correo entrante y saliente que redistribuían los mensajes en N carpetas de Evolution que, más o menos, equivalen a una etiqueta en GMail. Por otro lado, tenía (tengo) años de historia de correo electrónico que no es de GMail, principalmente, de mi vieja, querida y deprecada cuenta de Sion. Entonces por ejemplo en la carpeta "Amigos", tengo todo el correo de mis amigos, no solo el de los últimos 3 años en GMail, sino también el histórico.

El tema es que a medida que empecé a usar más y más GMail, y especialmente, desde que empecé a usarlo desde distintas computadoras, en distintos ámbitos, y con diferentes clientes, me choqué contra lo obvio: POP3… #noescala (chiste interno para los twitteros… je). Leer una cantidad de correos durante el día, etiquetarlos, acomodarlos, y a la noche prender la laptop y volver a bajarlos como correo "no leído", es una porquería. Muchas veces me pasaba que "leer" correo en la laptop en realidad era ir carpeta por carpeta en Evolution marcando los mensajes como leídos, sin siquiera abrirlos.

Boludo, ¡usá IMAP!

Hace bastante GMail habilitó IMAP. Cualquiera diría que es la solución. Pero… siempre hay un pero (en este caso, varios)

La implementación de IMAP de GMail suckea un poco. Lo de exponer los labels como folders tiene el inconveniente de que los correos que tienen N etiquetas, los bajás N veces (¿tantos recursos le sobran a Google que fue por este camino, en lugar de mapear las etiquetas a IMAP keywords, y dejar que las carpetas las manejes vos?). Por otro, la filosofía de "no borres el correo, archivalo", sumado a lo de las etiquetas, hace que cuando accedés a GMail con IMAP desde un cliente, algunas operaciones no sean obvias, o no hagan lo que vos pensás que deberían hacer. Aún hoy estoy tratando de incorporar algunas de estas cosas de manera definitiva en mi cerebro.

Así y todo, decidí sacrificar mi estructura histórica de carpetas, reemplazarla por la estructura "plana" que me da GMail (sí, ya se, si usara etiquetas con "/" en medio, automáticamente en la interfaz IMAP se traducen en una jerarquía de carpetas, pero no me gusta), y acceder vía IMAP.

Ahora, ¿qué hacía con las carpetas con el correo histórico? Vieron que los MUA en general cuando configuran una cuenta IMAP, como que crean una sub-estructura de carpetas nuevas, con su propia bandeja de entrada, papelera, correo enviado, borradores, más las carpetas de esa cuenta. Así que en cuanto hice el switch, el primer escollo es que en Evolution pasé a tener 2 grandes nodos: Correo viejo bajado por POP3, de GMail, de SION y otras cuentas, y el correo nuevo que iba entrando por IMAP. Y además, había una superposición: Todo el correo de GMail que había bajado durante años via POP3 estaba también accesible vía IMAP (repetido).

Para resolver eso, me tuve que embarrar las manos. Una solución hubiera sido escribir un script que leyera las carpetas en formato mbox de Evo y analizando los headers de los correos los copiara en las carpetas IMAP… pero no tengo experiencia manipulando correo a bajo nivel, y tampoco tengo TANTAS carpetas (ni tanto correo, apenas unos cientos de MBs), así que lo fui haciendo a mano: En cada carpeta de Evo, seteaba un filtro que básicamente era "mostrame el correo que entre los remitentes o destintatarios tenga a mi cuenta de sion o la cuenta de mi ex laburo y no tenga mi cuenta de GMail", y al correo resultante lo arrastraba a la carpeta (label) correspondiente en la cuenta de GMail.

Esto efectivamente "sube" (o importa) el correo en GMail, así que estuve un bueeeen rato haciendo esto. Y después me topé con este bug de GMail: El correo importado desde IMAP queda con la fecha incorrecta (con la fecha del día que lo importaste) en la interfaz web. Así que ahora tengo miles de correos en GMail que si los accedo desde la web, o si los busco, tienen la fecha en que los importé. Como internamente la fecha está bien (desde cualquier otro cliente se ve la fecha correcta, e incluso dentro de la interfaz web de GMail, en la vista de conversaciones se ven bien), supongo que algún día Google lo arreglará (aunque el tema es un known issue desde hace más de un año…)

Bueno, pero entonces, listo, pasaste a IMAP, y fuiste feliz, ¿no?

No

IMAP en Evolution *sucks*

Y por lo que leí, IMAP en Thunderbird también, y hasta IMAP en mutt suckea en algunos aspectos, así que malo por malo, me quedo con el malo que conozco, que encima es el MUA oficial de Gnome, y por lo menos tiene resuelta la integración con el desktop de manera decente.

Evo por default baja solo las cabeceras de los mensajes. Así que navegar por las carpetas se vuelve lentísimo, porque se tiene que conectar al server a bajar el mensaje. Obvio si el mensaje no está completo, no tengo un backup en disco. Y tampoco puedo hacer búsquedas locales, ni acceder al correo viejo si no tengo internet. Se le puede decir a Evo que baje todo el correo. Y lo hice. Lo dejé una noche haciéndolo. Pero resulta que el tipo así y todo ¡¡¡NO baja los attachments!!!. E igual, aunque tenga el correo cacheado en disco, cuando te parás encima del mensaje el tipo "dialoga" con el server IMAP para ver si el mensaje sigue existiendo, si le cambió algún flag, etc., o para bajar el attachment que no bajó. Es *lento*. Navegar por las carpetas de Evo se vuelve una tortura, y eso que no tengo cientos de miles de correos en cada carpeta, ni mucho menos. 

La única manera de leer correo sin que sea leeeeeeeento, es decirle a Evolution que labure "off line". Entonces el tipo se desconecta, no habla más con el server IMAP, y se deja de joder. Pero… no tengo los attachments. Y si entra nuevo correo, no me entero. Y si hago cambios localmente en el correo (los borro, los muevo, etc), no se impactan en el server hasta que no vuelvo a decirle a Evo que labure on line. Sucks. Sucks *big time*.

Después de considerar momentáneamente cambiar de MUA, decidí que ese no era el camino. En múltiples foros me encontré con que Thunderbird tiene issues también. Y no iba a volver a Thunderbird, cuya integración con Gnome es *pésima*, para sufrir más o menos lo mismo. Y no iba a pasarme a un MUA geek de terminal, como mutt o SUP, no gracias. No soy *tan* geek. Encima SUP está escrito en Ruby (yikes!).

Enter OfflineIMAP

Resulta que hay un programita, hecho en Python (¡Python rocks!), llamado OfflineIMAP, que básicamente sirve para sincronizar una cuenta IMAP con un repositorio local en formato Maildir. Puede hacer unas cuantas cosas más, como sincronizar múltiples cuentas, o sincronizar un IMAP con otro, y así, pero en esencia, el tipo es eso: un algo que lee un repositorio remoto (IMAP), y lo sincroniza contra uno local (Maildir u otro IMAP), y en el medio, podés poner reglas (esto sí, esto no, lo de esta carpeta pasalo a esta), y esas reglas muchas veces son expresiones de Python, o invocaciones a funciones de Python que realizan la conversión :)

Y todos sabemos que manejar tu correo con Python gives you a warm and fuzzy feeling :)

Así que hice eso: Configuré OfflineIMAP, y luego apunté a Evo a la carpeta raíz de la estructura Maildir, y voilá. *It flies*. Y encima, el formato Maildir es mucho más robusto que un mbox: tengo un archivo por correo, así que si por puta se corrompe un archivo, se pierde UN correo, no mil.

No voy a exponer acá un tutorial detallado de como configurar OfflineIMAP (hay *mil* recetas en la web), pero si voy a dar algunos tips que me resultaron interesantes, o que descubrí a fuerza de darme algún palo:

Muchos tutoriales te dicen que para configurar OfflineIMAP para GMail y luego accederlo con Evo tenés que mover ciertas carpetas a un nodo "root", porque si no Evo no entiende bien la estructura Maildir. Esto es parcialmente falso. La única carpeta problemática es el INBOX, que tiene que ser la raíz de la estructura Maildir, y GMail la expone como "/INBOX", no como "/". Esto se resuelve así en tu .offlineimaprc:

nametrans = lambda foldername: re.sub('^INBOX', '.', foldername)

Puede que NO quieras bajar la carpeta "Spam" de GMail, ni la carpeta "All Mail". La última es un tema… en mi caso, como soy bastante histérico con el etiquetado de correo en GMail, es raro que un mensaje quede sin etiquetar. Si está etiquetado, lo tengo en por lo menos una carpeta IMAP (y si tiene N etiquetas, en las N carpetas); si no está etiquetado, en general no es importante. Anyway, la forma de exluir una o más carpetas de la sincronización es la siguiente:

folderfilter = lambda foldername: foldername not in ['[Gmail]/Spam', '[Gmail]/All Mail',]

Dejarlas afuera tiene los siguientes caveats:

  • No hay forma de reportar un correo como SPAM desde tu estructura Maildir. La forma de decirle a GMail desde IMAP que un correo es Spam es moverlo a dicha carpeta, pero como no la estás sincronizando…
  • No hay forma de "desetiquetar" por completo un mensaje. La forma de hacerlo es mover el mensaje a la carpeta "All Mail", pero como no la estás sincronizando…

De nuevo, eso último es personal. A mi, me sirve así.

Ya que hablamos de carpetas, no dejen de leer estos tips de Google. Básicamente:

  • No mapeen la carpeta "Correo enviado" de su MUA a la carpeta Sent. Google copia automáticamente los mensajes que salen por su SMTP a la carpeta Sent.
  • No mapeen la "Papelera" de su MUA con la carpeta Trash de GMail, a menos que quieran efectivamente *borrar* el mensaje en lugar de archivarlo. Google recomienda lo último (archivar). La manera de borrar sería arrastrar el correo a la carpeta trash. Si atan la papelera de su cliente con el Trash de Gmail, no tienen forma de hacer el equivalente al "Archive" de GMail desde el cliente… a menos que también estén sincronizando la carpeta "All Mail", en cuyo caso, el Archive sería mover el correo a la carpeta All Mail.
  • Sí mapeen la carpeta "Borradores" de su MUA con la Draft de GMail, así los tienen sincronizados.

Por último, un detalle: No me gustaba mucho tener la clave de GMail volcada textualmente en un archivo de configuración. Pero resulta que OfflineIMAP puede invocar a una función de Python que le devuelva algunos settings, entre ellos, la password y el usuario de la cuenta IMAP (o de GMail). Así que pensé, ¿no podré tener la password en el keyring de Gnome, hacer un script de Python que lo recupere, y decirle a OfflineIMAP que use eso? Si, puedo. Y alguien ya lo había hecho :) Miren acá.

Bonus track

Lo bueno de tener a OfflineIMAP en el medio volcando tu correo en un Maildir estándar, es que ahora mi copia local del correo es independiente del MUA :)

Si mañana me canso de Evolution, solo tengo que poner el MUA que quiera apuntando a mi repo local, y ya está. Y si quiero probar un MUA nuevo, no necesito hacer NADA. Hasta puedo usar diferentes MUAs simultáneamente.

 

 

PyCon Argentina 2009

1 respuesta

Y pasó PyCon Argentina 2009. La primera conferencia de Python en el mundo en español. Y junto con esto, se cumplen 5 años de vida de PyAr. ¡Cuánta nostalgia! (y como pasa el tiempo…)

La conferencia estuvo EXCELENTE, empezando por el material de registración, siguiendo por la organización general, el lugar, la coordinación, las charlas, la versión impresa del tutorial en español, las keynotes de Jacob Kaplan-Moss y Collin Winter, y toda la cosa social que hubo alrededor.

Realmente, felicitaciones a todos los organizadores y colaboradores. Es la primera vez que PyAr se cargaba algo así al hombro, y salió muy bien. Parece que el año que viene habrá PyConAr otra vez, y será en Córdoba. Trataremos de estar :)

Para mi esta PyCon marcó un punto de inflexión. Este año medio me desconecté de PyAr, y por añadidura de la organización de PyCon. El viernes y el sábado la verdad me arrepentí. Ni yo no entiendo muy bien las razones por las cuales me alejé, hay muchas… y ninguna. Pero una de las tantas que puedo esbozar, es que sentí que no estaba pudiendo participar de ninguna manera más que asistiendo a las reuniones y hacer de "opinólogo". Como toda comunidad con participación voluntaria, se sigue esto de que "cada uno se rasca donde le pica", y a mi hacía rato que no me picaba nada concreto de Python, y tampoco me interesaba ayudar a rascar la picazón de nadie. Y me sentía cada vez más inútil. Y en algún momento sentí que era mejor dar un paso al costado, al menos por un tiempo. Hubo (hay) más razones, pero de nuevo, esa es una bastante concreta, y una que tuvo peso.

En retrospectiva, me doy cuenta que después de haber estado en PyAr desde los inicios, el haberme alejado JUSTO cuando se estaba organizando PyCon la verdad no fue una buena idea… porque ahí justamente había MUCHO para hacer, mucho en que ayudar y colaborar, mucho para organizar. Y me hubiera gustado sentirme un poco más parte de todo eso, en lugar de mirarlo de afuera. Y ojo: Mirarlo de afuera estuvo *buenísimo*, porque la conferencia estuvo buenísima. Pero si había una oportunidad de hacer algo concreto era la primera PyConAr, y me auto-excluí. Ufa. En fin… cosas que uno aprende.

Pero nada… lo pasado pisado. Disfruté de una muy buena conferencia, aprendí sobre varias cosas interesantes que están sucediendo en Python en este momento, y creo que lo más importante, es que aprendí (o recordé, o reafirmé) que lo más valioso que tiene PyAr es PyAr-la-gente, y que soy un boludo si por no reconciliarme con las cosas de PyAr que no me gustan, me pierdo todo el resto.

¡Feliz cumple PyAr! Por muchos PyConAr más…