El papeleo de ser padre
Pasados esos primeros momentos de tensión y felicidad máximos, vuelves a casa para que la realidad trate de despertarte a golpe de pequeñas bofetadas. O eso es lo que me está pasando a mi.
Pasados esos primeros momentos de tensión y felicidad máximos, vuelves a casa para que la realidad trate de despertarte a golpe de pequeñas bofetadas. O eso es lo que me está pasando a mi.
Se me hace muy cómodo tener un atajo de teclado para la típica orden de "ir a la linea X", así que en vez de escribir todo el tochaco de comando que hace falta en Emacs para ello (M-x goto-line<RET>#linea<RET>) voy a hacer un binding.
Así de extraño suena el nombre del último proyecto que lleva dando vueltas entre las perdidas neuronas de mi extremidad superior. ¿De qué se trata?, de un cúmulo de cosas... Os habréis dado cuenta que hace un tiempo me entretiene bastante todo lo relacionado con Flask y Django, pero como buen newbie que soy, no me sentía cómodo sin un proyecto en el poder practicar el learn by doing.
Normalmente las especificaciones de un entorno de desarrollo y las de un entorno en producción suelen ser bastante diferentes. Quizás en el primero buscas la comodidad mientras que cuando se hace el deploy a producción priman otras cosas.
Hace algún tiempo empecé a utilizar Flask para un proyecto personal. Flask es un mini framework de desarrollo en python que me ha convencido desde el principio por su sencillez. Intentaré exponer un pequeño ejemplo para que os hagáis una idea de cómo funciona. Y como Álex ha escrito un completo tutorial sobre Pylons/Pyramid con un ejemplo de aplicación, no quería ser menos y explicar mis aventuras y desventuras con esta otra pequeña joya de Python así que allá vamos.
Cuando algo tan sencillo de instalar y de configurar se convierte en un servicio mejor que sus antecesores en prácticamente todas sus características podemos decir que hemos dado un salto de calidad importante.
¡Menuda combinación!. A decir verdad empecé jugando un poco con el maldito slowloris y al final acabé montando este batiburrillo de servidores, primero para paliar el efecto del dichoso gusano y segundo para preparar el servidor para la inminente nueva versión del blog - que me gustaría estrenar con el décimo aniversario de este humilde rinconcito -. En un esquema inicial analógico de esos que tantos nos gustan podemos ver la pirula (pido perdón de antemano por la calidad de la foto):
Llevo desde el fin de semana con la mosca detrás de la oreja. Uno de los servidores que administro ha visto incrementada de forma inexperada su carga media de CPU sin motivo aparente. Donde el load average normal de 1 minuto variaba entre 0.40 y 0.80 de repente suponía cargas tan elevadas como 60 o 100 unidades. En esos momentos puntuales que llegaban a dejar la máquina zombie el proceso que abarcaba un consumo de entre el 60% y el 90% de CPU era apache2. Intrigante que ni error.log ni slow-queries.log de MySQL (lo que normalmente suele ser cuello de botella) dieran ninguna pista.
Me ha pasado un par de veces y siempre he acabado en el mismo sitio así que he decidido documentarlo con un mini-post, porque seguro que no será la última vez que me pase.
No lo tenía claro, pero cuando entendí lo que suponía y cómo se trabajaba con virtualenv + pip me decidí a probarlo. Voy a intentar explicar como se utilizan estas herramientas de una forma genérica, para hacernos una idea de lo que significa y los casos en los que se pueden aplicar. A grandes rasgos: Django: Framework en python, creo que no necesita mucha más explicación. Virtualenv: Herramienta necesaria para crear un entorno virtual de python, con las versiones específicas de los paquetes y/o dependencias que hagan falta para el proyecto. Pip: Gestor/Instalador de esos paquetes (similar a easy_install). Con estas herramientas intentaremos instalar un entorno virtual independiente para gestionar todas las dependencias de nuestro proyecto.