Code on oscarmlage

Moviendo entornos virtuales virtualenv

info@oscarmlage.com (oscarmlage) — Thu, 11 Feb 2016 21:05:00 +0000

Una de las ventajas de los entornos virtuales es que los podemos recrear en cualquier máquina con muy poco coste de tiempo, siempre que tengamos los requisitos más o menos documentados es tan sencillo como lanzar un comando para volver a construirlo ¿o no?. La teoría es fantástica pero en la práctica siempre surgen - como no - problemas murphianos.

PyConES 2015

info@oscarmlage.com (oscarmlage) — Sat, 28 Nov 2015 11:32:51 +0000

El pasado fin de semana (20 a 22 noviembre de 2015) se celebró en Valencia la PyConES 2015, la tercera edición de la conferencia nacional sobre Python más importante de España. Así que como no podía ser de otra forma, después de un noviembre atípico por un más que intenso e interesante Sprint (materia de otro post), allá nos fuimos Borja y yo a pasar el fin de semana entre amigos a la ciudad del Turia.

Darcs: Fixing a wrong amend

info@oscarmlage.com (oscarmlage) — Fri, 30 Oct 2015 10:58:24 +0000

I must admit I often get confused when recording a new patch based on a previous one. Sometimes I amend instead of creating a new record, and once it's done it's not easy to rollback. Well, really it is if you have a backup of the original patch. And this is how I treated to handle it...

Using mercurial a la darcs

info@oscarmlage.com (oscarmlage) — Thu, 09 Apr 2015 10:54:41 +0000

Nowadays using a version control system is as basic as using an editor. I have to admit I'm a mercurial fanboy because it's clear, simple and written in python.

In some other projects we're using darcs, similar to mercurial but with a different approach. As we've organized the darcs project, we must pull, create a patch with the new features, and send it to our QA department for review and bug hunting. If there are errors we must fix them and rewrite + resend the patch for a new review. Once the code is ok, the SYS department pushes the patch to staging (if there are more tests to be done) and finally to production enviroment.

ZODB, how to properly delete a BLOB file

info@oscarmlage.com (oscarmlage) — Tue, 25 Nov 2014 22:48:23 +0000

Due one of my Pyramid current projects, I was playing a bit with ZODB and blob image storing. After reading here and there, I had no idea how to properly delete a filesystem stored image, blob field related. I though best way was to use remove_committed() ZODB.blob method with something like:

Django deploy: problems with limited hosting

info@oscarmlage.com (oscarmlage) — Mon, 21 Jul 2014 21:51:18 +0000

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. Thanks to my Ailalelo's mates (they had lot of experience with this kind of situations) I found the proper configuration.

Django and memcache: clear cache keys

info@oscarmlage.com (oscarmlage) — Wed, 05 Feb 2014 13:35:54 +0000

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.

Pyramid: 6 - Forms (simpleform)

info@oscarmlage.com (oscarmlage) — Mon, 04 Nov 2013 19:00:00 +0000

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.

Pyramid: 5 - Views y Chameleon Templates

info@oscarmlage.com (oscarmlage) — Sun, 03 Nov 2013 19:00:00 +0000

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.

Pyramid: 4 - Models

info@oscarmlage.com (oscarmlage) — Sat, 02 Nov 2013 19:00:00 +0000

Si hacemos memoria, hasta el momento ya sabemos montar un proyecto y un entorno mínimo de trabajo, entendemos la estructura del mismo, incluso nos hemos arriesgado a modificarla ligeramente según nuestras necesidades; y sabemos a pies juntillas cómo funciona el despachador de urls de Traversal contra la ZODB.

Pyramid: 3 - URL Dispatching y ZODB Traversal

info@oscarmlage.com (oscarmlage) — Fri, 01 Nov 2013 19:00:00 +0000

En capítulos anteriores hemos visto cómo montar el entorno y cómo entenderlo y adaptarlo mínimamente a nuestras necesidades organizativas. Hoy trataremos de abordar el tema del despachador de URL's... ¡qué mal suena en castellano!.

Pyramid: 2 - Entendiendo la estructura del proyecto

info@oscarmlage.com (oscarmlage) — Thu, 31 Oct 2013 19:00:00 +0000

En la anterior entrada hemos visto lo más básico de cómo crear un entorno y un proyecto inicial con Pyramid + ZODB, en este post vamos a intentar entender el proyecto y adaptarlo un poco a nuestra forma de trabajar, para ello nada mejor que empezar echándole un vistazo a lo que pcreate ha hecho por nosotros:

Pyramid: 1 - Montando entorno y proyecto con ZODB

info@oscarmlage.com (oscarmlage) — Wed, 30 Oct 2013 19:00:00 +0000

Las series de artículos no son lo mío, creo que no he llegado a completar las que he empezado, pero hay que intentarlo. Entiendo que con esa premisa serán pocos los arriesgados lectores que lleguen al final, pero es una de las excusas que tengo para ponerme al lío con este nuevo reto, así que el que avisa...

Django: limpiando usuarios desde shell

info@oscarmlage.com (oscarmlage) — Thu, 12 Sep 2013 23:03:29 +0000

Es tal el interés por el foro de VamosaVidas (si, ese que rompí en su día y he vuelto a arreglar) que todos los días tenemos cientos de registros. Realmente se trata de robots que se dedican a hacer spam, pero eso es lo de menos :P.

Darcs: otra forma de trabajar

info@oscarmlage.com (oscarmlage) — Fri, 11 Jan 2013 17:18:13 +0000

Si tengo que ser sincero, desde un principio he sido bastante reacio a la moda esta de los sistemas de control de versiones. Estaba tan agusto y acomodado con mis copias de seguridad y mis carpetas fechadas que me daba una pereza enorme ponerme a aprender un nuevo sistema que, sin duda, me obligaría a cambiar la forma de trabajar.

Django: Cambiando de DB Engine

info@oscarmlage.com (oscarmlage) — Sat, 28 Apr 2012 18:42:31 +0000

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. Este suele ser el caso del motor de base de datos cuando trabajas con Django.

Django + virtualenv + pip

info@oscarmlage.com (oscarmlage) — Wed, 23 Feb 2011 21:37:56 +0000

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.

¿Codeigniter-Reactor + esteroides?

info@oscarmlage.com (oscarmlage) — Fri, 04 Feb 2011 20:09:38 +0000

Es algo que todavía no llego a entender ni asimilar. He pasado la mayor parte de la tarde para configurar la nueva versión 2.0 de CodeIgniter-Reactor con varias librerías que, para mi forma de desarrollar, son indispensables en cualquier framework de programación orientado a web:

HMVC: Gracias a la librería de Wiredesignz podemos ordenar nuestro código en módulos y simplificar la lógica de la aplicación.
ModulesModule: Ahora que todo será un módulo, no vendría mal un módulo encargado de ejecutar las tareas más comunes de los módulos (instalar, desinstalar, actualizar...). Un módulo de módulos.
SettingsModule: No me gusta cargar la configuración desde ficheros config/*, por comodidad y para que el usuario pueda cambiar cualquier parámetro ajustable de una aplicación, prefiero hacerlo en base de datos y cachearlo a disco si es necesario. Me quedo con la librería de PyroCMS.
ThemesModule: Otra característica imprescindible sería tener una aplicación themeable y que desde un interfaz de administración se pueda cambiar tranquilamente el aspecto de la misma. Para ello podemos hacer uso de este módulo capaz de instalar y desinstalar themes.
TemplateLibrary y TagsLibrary: Una vez hemos decidido hacer la aplicación modular y themeable siguiendo el patrón MVC, un buen lenguaje de template para que los diseñadores no se vuelvan locos con el lenguaje dinámico sería un punto más.
MigrationsLibrary: Una vez lo pruebas se convierte en musthave. Se trata de una librería para hacer migraciones de versiones en base de datos. Gestiona los cambios entre versiones de forma sencilla.