Cómo se hizo el mapa de calor
En Bosco Curtu | publicado el Martes 31 de Marzo de 2009
En el anterior post explicaba lo que era el mapa de calor de dooplan. Robert construyó la solución (a partir de otro desarrollo) y aquí explica cómo funciona.
PyCamp 2009 de PyAr
En Total interferencia | publicado el Lunes 30 de Marzo de 2009
Este es el reporte del evento que, como ya comentara, se realizó en Los Cocos en Córdoba. Fuimos mas de 30 Pythoneros de Formosa, Sante Fé, Entre Ríos, Buenos Aires y Córdoba con algunas ausencias respecto al año anterior, pero también con mucha gente nueva. Otra vez llevé la portátil que me facilitan donde trabajo, [...]
Leo Soto & su presentación Jython & Django (PyCon 2009).
En Continuum | publicado el Lunes 23 de Marzo de 2009
Leo Soto nos visitó el pasado viernes respondiendo a una invitación nuestra. Debo confesar que somos afortunados, pues ensayó la charla ( en versión extendida ) de la presentación que hará en la PyCon 2009 ( en Chicago del 27 al 29 de Marzo ) sobre el trabajo que ha estado haciendo en soportar django sobre [...]
Instalando mod_wsgi, nginx y cmemcache en Ubuntu Intrepid para Django
En Frameworks Agiles | publicado el Sábado 21 de Marzo de 2009
Es un resumen breve para configurar nuestro servidor apache con mod_wsgi, memcache y nginx, el cual lo he recopilado de varios sitios, el cual espero pueda ser de ayuda y tambien pueda permitirnos a abrir debatos en lo que se refiere a las mejores practicas para configurar tus host para aplicaciones django. Por que mod_wsgi y no mod_apache, puedes encontrar en este resumen mas detalles en los siguientes links: * http://code.google.com/p/modwsgi/wiki/PerformanceEstimates * http://code.google.com/p/modwsgi/wiki/FrequentlyAskedQuestions * http://blog.webfaction.com/django-setup-improvements
Snippet de vista para i18n
En pyAutoservicio | publicado el Viernes 20 de Marzo de 2009
Una de las cosas que nos ofrece django es vistas genéricas y soporte para localización (aka i10n) e internacionalización (aka i18n). Entonces una vez tenemos nuestro sitio con i18n o i10n pues lo que sigue es que le demos a nuestros usuarios la manera de escoger su idioma, django tiene un algoritmo par esto, sin embargo en algún punto nuestros usuarios querrán poder escoger su idioma preferido, para esto este framework nos da la opcion de una vista generica, sobre la cual encontrarán información en http://docs.djangoproject.com/en/dev/topics/i18n/#the-set-language-redirect-view. Lo único es que esta vista espera que halla un formulario para que el usuario escoja su idioma y además que tengamos predefinida una página a la cual el usuario será redirigido después de seleccionar el idioma a lo cual le veo particularmente un inconveniente pues si el usuario ha llegado a un punto importante para él y es llevado a la página inicial pues no le agradará (en mi caso me molestaría), además si queremos tener la posibilidad de hacerlo desde una url y no una variable por post? Para resolver este conflicto se modifica un poco la vista que nos trae django y la dejamos así: def set_lang(request,lang): response = HttpResponseRedirect(request.META['HTTP_REFERER']) lang_code = u'%s' % lang if lang_code and check_for_language(lang_code): if hasattr(request, 'session'): request.session['django_language'] = lang_code else: response.set_cookie(settings.LANGUAGE_COOKIE_NAME, lang_code) return response Esta vista espera que se escoja el idioma por una url y además redireccionará al usuario a la página en la que se encontraba, podemos hacerlo incluso en el urls.py y finalmente escogemos la url: urlpatterns = patterns('', ... (r'^set_lang/(?P\w{2})/$',set_lang), ... ) de esta manera si se va a /set_lang/es/, django cargará todo nuestro sitio en español y volvera a la vista en la que lo hallamos hecho.
23 de Marzo: Sprint Django durante PyCamp 2009
En Total interferencia | publicado el Jueves 19 de Marzo de 2009
La comunidad de usuarios Python de Argentina se reúne este Sábado en la segunda edición del muy exitoso PyCamp: Cuatro días en un apacible y bello lugar de las sierras de la provincia de Córdoba, para programar, planificar y disfrutar del entorno y del contacto cara a cara. Entre las actividades tenemos planeado un Sprint para [...]
Planificando un deploy (django + nginx)
En Blog de Javier Santana | publicado el Viernes 13 de Marzo de 2009
Si algo he aprendido a lo largo de mi corta vida como perfil mixto entre desarrollador web y adminitrador de sistemas es que los deploys sí importan. Ahora mismo tengo una aplicación web en django y mis requisitos para el deploy son los siguientes (lo cierto es que servirían para cualquier aplicación web):- Hacer el setup del servidor en un solo paso- Poder tener la aplicación en el servidor funcionando con un solo comando- Poder volver a una versión anterior en cualquier momentoSimples de describir, pero complicados de llevar a cabo.Hay 3 cosas que tengo que tener en cuenta en la configuración:- el servidor web- la aplicación- la base de datosPor mi parte he elegido nginx como servidor web ya que soporta fastcgi y parece ligero, para la aplicación uso django y como base de datos mysql. La elección no se basa nada más que en mi experiencia, no quiero entrar en el juego de que es mejor o peor.Para el deploy estoy usando fabric, un sistema que permite en 3 puntos:- ejecutar comandos en local- ejecutar comandos en un server remoto- subir y bajar ficherosY todo con sintaxis python :), con lo cual puede además usar todo el api de python.El layout de carpetas es el siguiente: - /srv/agroguia/ - versions - 0 - timestamp - .... - last (enlace simbólico a la última versión subida de esta versión) - 1 - ... - current (enlace simbólico a la carpeta dentro de versions/X/timestamp)El servidor web está dividio en dos rutas: - la parte estática que apunta a current/assets. De momento el peso de los assets es muy bajo ( - la parte dinámica que usa fastcgi contra un socket unix que se crea al levantar django.Y por qué dividir la aplicación en versiones y dentro de cada una en timestamp (en realidad timestamp + hash de la revisión del sistema de control de versiones). Cada versión tiene un esquema de base de datos y una base de datos diferente dentro de mysql, de forma que todas las versiones de la aplicación dentro de esa carpeta pueden usar la misma base de datos sin problemas de integridades ni nada por el estilo. Similar a este sistema de versiones y timestamps lo usa el sistema de deploy de google app engine.Del mismo modo, cada vez que cambie el esquema de la base de datos, se creará una carpeta nueva, se llamará al comando de creación de base de datos de django (manage.py syncdb) y luego llamaré a la migración (manual, django aún no soporta migraciones al estilo rails, una pena) que usará los datos de la versión anterior.Si en cualquier momento quiero volver a una versión anterior puedo símplemente cambiar el enlace simbólico de current y levantar de nuevo el servidor. Incluso si quiero tener una versión en producción y una para desarrollar basta con que levante un servidor de desarrollo en otro puerto diferente al 80 (google en este caso lo hace con subdominios, pero yo no soy tan guay)Otro detalle importante es la posibilidad de hacer un setup del sistema desde 0. Me baso en un servidor ubuntu, así que tengo unos cuantos targets que instalan dependencias (mercurial, nginx...), módulos python con pip (el reemplazo de easy_install), carpetas, usuarios y permisos varios.
Agregacion en Django
En AxiaCore | publicado el Miércoles 11 de Marzo de 2009
Trabajando con modelos en Django para aplicaciones web de alto perfil, como las desarrolladas por AxiaCore, nos encontrábamos frecuentemente con tener que hacer cálculos aritméticos básicos manualmente sobre un conjunto de datos en particular. Por ejemplo si necesitábamos obtener el total de ventas de un mes determinado, se tenia que iterar cada elemento del conjunto de [...]
Presentación de Empathy
En Software Libre | publicado el Martes 10 de Marzo de 2009
Continuación de la presentación de Django-Sympy, por Fabián Seoane. Un entorno de cálculo simbólico en la web; está actualmente funcionando en http://empathy.sympy.org. La aplicación tiene un API tipo JSON-RPC, que se podría usar desde cualquier lenguaje. Actualmente está tratando de resolver problemas de seguridad y de carga. La presentación os la podéis descargar del sitio habitual Fuente: osl.ugr.es
Parches para mejorar Django
En DynamicWare | publicado el Domingo 8 de Marzo de 2009
Encontré algunos parches que estoy usando a diario para desarrollo y tests en Django, y me pareció interesante compartirlos. Además la idea es que sirvan de ejemplo de las cosas que se pueden encontrar en el sistema de "tickets" de Django, donde hay muchos parches para agregar funcionalidad, por ejemplo:- Make Django's server optionally multithreaded (específicamente: devserver_multithread_trunk_r9532.patch)Esto permite que el servidor de desarrollo funcione con multiple threads. Sirve, por ejemplo, si queremos realizar un request al mismo servidor (por ejemplo, usando urllib2) desde una vista.- Add live test server support to test framework (específicamente: django_live_server_r8458.diff)Permite iniciar un servidor http desde un testcase.