Some months ago I had to deal with a Symfony2 project in a shared hosting (Spanish article) and now the big next deal is a similar task with Django. The project is almost done and I have the hosting credentials, once I'm in I noticed that there is no chance to configure anything (Apache, WSGI or whatever) so I was a bit lost.
When you are creating a new GPG key you have to decide how long the key will be valid before to renew. In my case when I got my own key, I was not really thinking on use it daily, it was years ago, just for test and have fun.
Last days ago I had lot of problems with MTA servers, hacked accounts, bad redirects policies and some other minor issues that kept me with the hands dirty in sysadmin keyboard. Needless to say how I love to put my sysadm hat and start to fix and/or optimize stuff, so from that bunch of problems was born this little script that makes my days easier than before.
This is a tipical friday story on sysadmin world, starting with a common Munin alert email and ending fighting against a cracked email account due a weak password. The alert referred to a weird problem with inodes outside range in / partition:
Una de las fantáticas features de tmux es la sencillez con la que puedes conectar múltiples clientes a la misma sesión de forma simultánea. Si lo has hecho alguna vez, con terminales de diferentes tamaños, habrás visto algo tal que así:
Let's play Django with Memcached. As the great framework Django is, it's so easy to activate any kind of cache in your project. Memcached is one of the options, but you can also work with DatabaseCache, FileBasedCache, LocMemCache, MemcachedCache, DummyCache (a kind of non-cache very useful for devel/test enviroments) or - of course - your own CustomCache if you want.
Sometimes when you are using Mercurial you want to paginate the output results. With paginate I mean use someting like bash more or less commands. Trying to focus yourself in a long list display is nearly imposible without a pager, so you can do it old-school-style:
El título suena muy a "la he liado parda por favor échame una mano". En efecto. Básicamente (y creo que lo repetiré varias veces a lo largo del artículo para que queda claro), la mejor solución para no llegar nunca a este punto es hacer dumps de vuestras bases de datos.
Aunque hasta ahora es cierto que hemos creado un model (bueno, dos), una view y una template, hemos configurado el root context de la aplicación y sabemos más o menos cómo funciona y cómo movernos por ella, de momento no hemos interactuado demasiado con el ZODB, nos falta agregar datos a ese modelo Twitts que creamos en su día y, obviamente, mostrarlos.
Siguiendo con esta serie de artículos sobre Pyramid y ZODB ya hemos escrito nuestros primeros modelos, así que ya podemos interactuar con ellos de alguna forma: a través de las views.