Autor: fpuga

Si el disco duro no para al arrancar ubuntu vacía la papelera

Los discos duros (casi) infinitos actuales han hecho que en un año haya acumulado más de 4000 ficheros y casi 60GB en la papelera de Gnome. Nunca pensé que esto fuera un problema pero ultimamente el ordenador tardaba muchísimo en iniciarse y el disco duro incluso después de arrancar el escritorio estaba funcionando durante uno o dos minutos.

El comando iotop nos permite saber que procesos están consumiendo más acceso a disco, y al lanzarlo durante el arranque descubrí que el problema era el servicio gvfsd-trash, responsable de la gestión de la papelera. Hay un montón de bugs y comentarios en los foros quejándose de este problema [1], [2], [3].

A falta de una solución mejor simplemente vaciar la papelera funciona. Así que ya sabes, si la lucecita del disco duro no para durante el arranque vacia la papelera.

Cliente de correo para Linux

Llevo usando aplicaciones web para usar el correo desde que abrí mi primera cuenta de mail. Gmail tiene tiene una interfaz genial, funciona en cualquier dispositivo y es rápido. El único problema es que tus correos no son tuyos. Estos días he tenido que cerrar una vieja cuenta de correo en gmail y para descargar los mails a modo de copia de seguridad he estado revisando clientes de correo de escritorio:

  • Que se lleven bien con gmail/imap, respetando etiquetas, …
  • Que permitan agrupar conversaciones al modo en que lo hace gmail
  • Que tenga buenas funcionalidades de búsqueda
  • Que no use Qt

En las recomendaciones y quejas de clientes sobresalen un par de ellos:

  • Claws Mail. Que no parece tener el «modo conversación»
  • N1. Que tiene una pintaza, algo así como el Atom de los clientes de correo, el problema es que todo el correo pasa a través de sus servidores o tienes que instalar uno en local.
  • Evolution. Que parece pesado, poco documentado y con demasiada gente quejándose de bugs.
  • Thunderbird.
  • Geary.

Tanto Thunderbird (con plugins) como Geary (por diseño) cumplen todos los requisitos, pero la búsqueda de Thunderbird parece mejor, y la mayor base de usuarios y documentación hace que sea el que vaya a probar.

Siguiendo la documentación de thunderbird, la documentación sobre IMAP de Google es fácil de configurar. Si hay problemas de conexión se puede deshabilitar el acceso seguro en google o habilitar OAuth2 en thunderbird como método de autenticación.

Para configurarlo bien hay que revisar un poco la configuración pero en general funciona todo sin problemas.

Atom: Autocompletado de código en python

Al margen del «Code Completion» de PyCharm, y algún otro, el resto de editores/IDEs proveen autocompletado a través de librerías o «servicios externos». Para el caso de python hay fundamentalmente dos, rope y jedi. Rope está más enfocada a Refactoring y Jedi a Autocompletado, por tanto las dos son complementarias. En la actualidad varios editores que usaban rope están migrando a jedi, su autor ha hecho una comparación defendiendo su librería.

Además de estas librerías cada editor suele proporcionar un plugin base para autocompletado (autocomplete-plus en atom, auto-complete en emacs) y plugins adicionales para cada lenguaje concreto que actúan como wrapper de las librerías base (rope, jedi,…). Por ejemplo en atom tenemos autocomplete-python que es un wrapper para jedi.

Instalación

Primero hay que instalar jedi sea a nivel global como en el ejemplo, o dentro de un virtualenv.


sudo pip install jedi

Luego se instala el plugin de autocomplete-pyhon (que es el más actualizado de los varios que hay). Si usas virtualenv también debería funcionar sin problemas pero si usas algo como virtualenvwrapper donde tu módulo está en un directorio distinto al «entorno virtual de python» puedes haber más problemas.

Lanzado atom desde un virtualenv activado siempre funciona correctamente. Si lo lanzas de otra forma hay que configurar la opción de configuración Python executable path del plugin con algo como:


PATH_TO_VIRTUALENV_WRAPPERS_FOLDER/$PROJECT_NAME/bin/python

o

PATH_TO_VIRTUALENV_WRAPPERS_FOLDER/$PROJECT/bin/python

Donde PATH_TO_VIRTUALENV_WRAPPERS_FOLDER es la ruta absoluta al directorio donde se guardan todos los entornos virtuales de virtualenwrapper y $PROJECT_NAME y $PROJECT son cadenas que debes escribir tal cual. Son variables que entiende el plugin. De la documentación parece deducirse que lo que hay que usar es $PROJECT pero a mi me ha funcionado sólo con $PROJECT_NAME. Además el directorio padre que se añade a atom a través del «Add project folder» debería llamarse igual que el virtualenv para que $PROJECT_NAME tome el valor correcto y puedas usar la misma configuración para distintos proyectos.

Uso

Por la naturaleza dinámica de python muchas veces jedi no es capaz de detectar el tipo de datos de un objeto. Pero podemos ayudarlo documentado el método. Por ejemplo en un caso como el del ejemplo siguiente con una vista de pyramid, jedi no será capaz de determinar el tipo de datos del parámetro request.


@view_config(route_name='my_route')
def my_route(request):
pass

Pero si hacemos lo siguiente si que autocompletará correctamente los métodos de request:


def cultivos_get(request):
"""
:type request: pyramid.request.Request
"""
pass

No lo he probado con python 3 para ver si soporta el type hinting pero este issue me hace suponer que si.
Teclas principales

  • Sugerencias de autocompletado. Ctrl+space Cursores y tab/intro para escoger y aceptar sugerencia
  • Go to definition: Ctrl+Alt+G
  • Show usages: Ctrl+Shift+P show usages
  • Renombrado en varios ficheros a la vez: Con el cursor encima del símbolo. Ctrl+Shift+P rename

Conclusiones

Las funcionalidades que proporciona son de todas formas muy justas porqué a no ser que documentes los métodos, la mayoría de veces no es capaz de inferir el tipo de datos de una variable. Además las funciones de autocompletado normal de atom incluyen habitualmente opciones que no tienen porque corresponder con métodos o propiedades reales del objeto. Y si se desactiva el autocompletado normal para los ficheros python, tendremos muy pocas sugerencias.

Libro: JavaScript: The Good Parts de Douglas Crockford

A pesar de que Crockford tiene un estilo de comunicación bastante peculiar, demasiado agresivo, para mi gusto, tenía bastantes expectativas puestas en este libro, que al final no se cumplieron.

Para mi lo mejor del libro es que se puede leer muy rápido y los railroads syntax diagrams. No es desde luego un libro para aprender javascript sino más bien una guía de ciertas prácticas a evitar y una justificación de las reglas de jslint. La verdad es que al contrario que otros libros de javascript como el de Flanagan o centrados en los idioms de los lenguajes como Effective Java, no me veo volviendo a este de vez en cuando para repasar algún concepto.

El libro puede gustarte si eres de los que se leen la definición de reglas de eslint para definir tu propio subset.

Nota. Estas transparencias también son un buen resumen del libro e incluso tienen un «code playground» para practicar.

Eventos en backbonejs

Una de las formas más interesantes de desacoplar código, vistas fundamentalmente, usando un framework MV* tipo backbone es aprender a usar correctamente los eventos y patrones asociados. Observer (pub/sub), Event Aggregator, Mediator, …

La mejor lectura al respecto que he encontrado es este post de Derick Bailey (creador de MarionetteJS), donde de forma muy ilustrativa examina distintas opciones finalizando con como hacerlo con eventos. Es recomendable también leer los comentarios, donde Derick responde a varias dudas de los lectores.

La sección sobre Eventos de Developing Backbone Applications explica bien como usar los eventos en general en backbone y esta otra sección revisita el post de Derick exponiendo la diferencia entre Event Aggregator y Mediator.

Pero para trabajar con Eventos de forma correcta además de los patrones y las especifidades de backbone es necesario conocer algunas técnicas y características de javascript relacionadas con el contexto. La siguiente selección de artículos puede ahorrarte un par de horas de quebraderos de cabeza:

Libro: Developing Backbone.js Applications

He terminado de releer estos días Developing Backbone.js Applications, escrito fundamentalmente por Addy Osmani con la colaboración de más gente vía pull-requests en github. Los primeros capítulos del libro (Introduction, Fundamentals, Basics) se leen muy rápido y dan una buena idea, no sólo de como usar backbone si no de porqué usar un framework MVC.

La idea de mezclar el uso concreto de la herramienta con explicaciones de más alto nivel de patrones se produce a lo largo de más capítulos del libro, por lo que uses backbone o no lo que aprendas te seguirá sirviendo. Esto creo que es el principal aliciente del libro, ya seas un programador novato e inexperto en backbone, o no, puedes aprovechar las explicaciones sobre patrones MV*, Mediator vs Event Aggregator, Desarrollo Modular, …

Otra de las cosas que me gusta del libro y que es muchas veces ignorada es que dedica un capítulo entero a testing. Tal vez demasiado centrado en explicar distintas herramientas (Jasmine, QUnit, Sinon) pero aún así d utilidad.

Algunos otros capítulos me dan la impresión de ser demasiado específicos, como aquellos dedicados a desarrollo para móviles y a otros frameworks construidos sobre backbone como Marionotte y Thorax. El capítulo sobre herramientas por ejemplo también es muy específico y al ritmo al que evolucionan en estos momentos ya se ha quedado desactualizado.

Salvando eso, creo que sigue siendo un libro muy recomendable.

¿Es «decrecimiento» una buena palabra?

Aunque puedo coincidir con algunas de sus ideas la palabra «Decrecimiento» me pone nervioso. Por eso el artículo de Kate Raworth en el blog de Duncan Green explicando algunos de los motivos por los que Decrecimiento es una mala palabra creo es digno de ser leído. Este otro post, con el que no concuerdo, es una respuesta al artículo original.

No dejéis de leer los comentarios y fijaros en la encuesta, en este momento la opción «buena idea, buena palabra» tienen 117 votos, «buena idea, mala palabra» 76 votos y «no una buena idea» tiene 41 votos. Es decir que aún sumando las dos últimas opciones el resultado está empatado. En cambio, la mayoría de comentarios, son críticos con la palabra.

Siendo un pelín malvado parece que a los fans del decrecimiento les va más la adhesión a la idea que a presentar argumentos a su favor.

El sol, la tierra la luna y animaciones con css3

Hace algún tiempo vi un ejemplo brutal de como usar únicamente html5 y css3 para hacer una «representación» del sistema solar.

Viendo que estaba como uno de los proyectos de codeacademy hice una pequeña prueba que comparto. La diferencia fundamental con el de code academy es que en lugar de usar imágenes para representar a los planetas uso div con background-color y que he añadido la luna para poder jugar un poco con las animaciones «anidadas». Que fundamentalmente es un problema de posicionamiento css.


Aquí el resultado.

Hay otros experimentos muy chulos en esta línea como este que trata de reproducir el primer experimento usando un html más semántico. O este otro clon del primero donde también modifica la estructura del html usando div todos al mismo nivel de anidamiento. Este otro también sigue la idea del primero pero añade cosas chulas como usar funciones css para posicionar las estrellas de fondo en localizaciones aleatorias.

Y por último, uno que a pesar de incluir algo de javascript (para los controles) es capaz de reproducir el sistema solar en 3D.

Aitor Guevara hablando de la arquitectura de Ducksboard

Un vídeo algo antiguo (2013) en el que Aitor Guevara (CTO de Ducksboard) nos habla de cual era la arquitectura de Ducksboard en aquel momento. A pesar de que el vídeo dura más de una hora y media Aitor consigue hacer amena una charla técnica. No entra al mínimo detalle técnico pero si da una buena idea general. Responde sin rubor a preguntas como cual era el costo de la infraestructura que tenían en Linode (400$) o cuantos clientes de pago tienen.

Por el medio de la charla caen perlas del estilo de:

  • Usamos twisted para hacer aplicaciones asíncronas en python. ¿Conoceis nodejs? pues lo mismo pero tiene 10 años en lugar de 1.
  • Usamos backbone, porque tenemos un montón de javascript. Tenemos un montón no porque nos guste si no porque es lo que hay.

Otra de las cosas que más me gustan es la defensa que hace de PostgreSQL, que es el componente central de su infraestructura (especialmente hacia el minuto 50 pero en realidad lo hace en varios momentos). Hacia el minuto 44 explica como usan ellos backbone. La verdad es que aquí no me quedo muy claro desde donde servían el html, o si iba todo en los templates, porque el django del frontend en principio sólo actuaba como API Rest sirviendo JSON al navegador. Eso si, su django usa SQLAlchemy y no django-orm porque tenían cosas en el postgres que django-orm no soporta.

Los últimos minutos de la charla presenta un par de herramientas que «análisis del negocio» que también son de interés.

En este post además del vídeo están las transparencias.

Un sistema como otro cualquiera para recuperar tus contactos en un Android con la pantalla rota

Uno de esos días cualquiera en que te llega alguien (a quien no puedes mandar a freír puñetas buscar en google) que una semana después de comprarse su primer móvil con Android se le ha caído al suelo, se le ha roto la pantalla y quiere recuperar sus contactos.

La primera respuesta es fácil. No hay problema, estarán en la memoria de la tarjeta, o sincronizados en la cuenta de google. Pero no, ni uno ni otro. Están en la memoria del teléfono.

Las primeras búsquedas en google se refieren a sistemas que necesitan que el teléfono esté rooteado para por ejemplo copiar la base de datos (sqlite) con los contactos. Teniendo el sqlite es fácil sacar un csv o al menos un listado que copiar a mano. Pero por supuesto el teléfono no está rooteado.

Bueno, la pantalla no está del todo muerta, la parte de arriba responde. Así que igual da para hacer pulsar en los sitios clave. El teléfono en sí no puede desbloquearse, pero si se puede llegar al botón de «Ajustes«, porque no tiene activado la protección por figura. Jugando con la rotación automática para modificar los sitios a pulsar, podemos llegar de «Ajustes» a «Aplicaciones«, de ahí a la pestaña de «Todas» y desplazarnos hasta «Contactos«. Muchas de las apps, como la «Contactos» tienen un botón «Lanzar» equivalente a como si las abrieras desde el Launcher.

Estando en la app de Contactos sólo hay que poder lanzar la opción de «Exportar«, pero en este teléfono ese menú se lanza desde la tecla de «Menu» que no responde. Teóricamente con el conector adecuado, podríamos conectar un ratón al teléfono para controlarlo, pero a falta de conector resulta que es posible enviar eventos (como pulsaciones de teclas) al móvil a través de adb.

«Pulsamos» la tecla de menú:


$ ./adb shell input keyevent 82

Y un par de veces KEYCODE_DPAD_DOWN que actúa como el curso hacia abajo


$ ./adb shell input keyevent 20

Y enviamos el evento KEYCODE_DPAD_CENTER para hacer click / pulsar / tap sobre la opción seleccionada


$ ./adb shell input keyevent 23

Y ya tenemos lanzada la la aplicación de exportación. Siguiendo un proceso parecido de ver en que partes de la pantalla de puede pulsar y enviando eventos desde adb, seleccionamos como origen el smartphone, como destino la cuenta de gmail. Y listo. En un par de minutos tenemos los contactos en gmail, desde donde podemos exportarlos a csv, vcard o listos para ser usados desde otro teléfono android.

Espero que a alguien le sea de ayuda. Se admiten otros modos de hacerlo en los comentarios.