Django, DRY y el client-side

Por sí alguien no lo sabe, Django es un potente framework para el desarrollo de aplicaciones web en Python.
Sigue al pie de la letra la filosofía DRY (Don’t Repeat Yourself).

La verdad es que hace honor al lema, pero como backend que es, entra muy poco en lo relativo al client-side.
Aunque Django se usa como backend de aplicaciones móviles (recomiendo Django REST framework) o incluso como backend para aplicaciones nativas (alguna he hecho con C++/Qt4), la realidad es que el grueso de aplicaciones cliente/servidor hechas con Django son web.

Me he dado cuenta que donde más tiempo invierto a la hora de hacer una webapp es en escribir la lógica JavaScript. A pesar de usar mis propias librerías JS, jQuery, Handlebars y demás herramientas de última tecnología, aun tengo que crear mucho código JS para comunicar vía Ajax. Sin duda no cumple con el principio DRY. Harto de esta situación de ineficiencia me puse a buscar paquetes Django que me ayudarán en esta guerra.

No he encontrado una gran variedad, pero he descubierto un paquete en Github que aunque lleva un año sin recibir actualizaciones cumple con gran parte de lo que quiero.

El paquete se llama Django-puzzledev-jom y es fruto de un estudio universitario de lo que llaman SSMVC (Symmetric Synchronized Model View Controller).

Este paquete crea una serie de ficheros JavaScript para cada uno de los modelos que quieras que sean exportables. Importando estas clases en tu client-side, se hace trivial cualquier tarea CRUD.

Esta es la teoría. En la práctica me he dado cuenta de que aun le falta mucho por pulir. Aún esta lejos de alternativas en otras plataformas como ASP.Net o GWT.

Entre otras cosas. aún esta verde la generación de código JavaScript. Una de sus principales carencias es la inclusión de validadores. Esta tarea es más o menos trivial, ya que conociendo los tipos de datos, añadir una expresión regular para comprobar lo que debe ser un email, un télefono o un dato requerido, no debe ser muy complicado.

Es muy probable que acabe haciendo un fork de esta libreria y mejorarla a mi antojo.
Creo que puede ser una buena inversión de tiempo para agilizar los futuros desarrollos.

 

Anuncios

El primer Hackathon DEV&BIZ, Betabeers & IE Business School

Betabeers Hackathon Dev&Biz

Betabeers Hackathon Dev&Biz

TL;DR: 1º Hackathon que une desarrolladores de software y de negocio. El tema fue “nuevas formas de vender videojuegos”. No hubo ninguna idea “killer“. Experiencia muy  enriquecedora, mucho networking y sobre todo buen rollo y diversión.

El pasado 15 de Diciembre se celebró en el Área 31 de IE Business School, el primer hackathon que reunia Business y Software Developers.

Con algo de demora, el hackathon empezó sobre las 10 am.

El grupo canónico estaba formado por 3 desarrolladores y 3 business developers que tenian que desarrollar un proof-of-concept sobre el tema: “Nuevas formas de vender videojuegos

Se presentaron muchas ideas y propuestas sobre la mesa, al final se desarrollaron unas 6 propuestas que describo a continuación:

  • UGame
    • La hipótesis de los chicos de UGame es que a todo el mundo le gustaría hacer su propio videojuego. Su propuesta consiste en que alguien crea un nivel y luego se lo manda a un amigo para que juegue y continue su desarrollo.
    • Modelo de negocio: Cuando se recibe un mini-juego, se presenta un breve anuncio antes de dar paso al juego.
  • 6-Games
    • Se presentan 6 juegos en modo “slide-run” donde tienes 30 segundos para jugar. Pasados esos 30 segundos, no te deja jugar más y puedes poner un rating al juego antes de pasar al siguiente. El objetivo es que puedas probar los juegos y decidir cúal comprar.
    • Modelo de negocio: Hay varias formas de explotarlo. Desde el punto de vista de cliente final, puede evaluar que juego le gusta más y comprarlo directamente, llevándose una comisión. Desde la posición de desarrollador, puede ver el feedback/valoración que recibe su juego y así tomar medidas. En principio no pagan por publicar juegos.
  • GamesLover
    • “¿Quieres un juego a buen precio? Pues ayuda en su promoción mediante su difusión en redes sociales”. Esta es la idea. Cuanto más promoción hagas por un juego, mayor descuento obtendrás.
    • Modelo de negocio: Programa de afiliación, los juegos incluidos en este catálogo tiene mayores oportunidades de vender.
  • FinderGames
    • Facilita a los padres la búsqueda del juego correcto para su hijo. Mediante preguntas sencillas, pretende acertar con el juego correcto para los retoños.
    • Modelo de negocio: Afiliación y/o comisión por ventas de juegos.
  • Otogami App
    • Otogami.com es un web española creada por David Bonilla que permite encontrar juegos al mejor precio de mercado. Otogami App es la versión app de la web que  mejora la UX y añade nuevo canal para llegar al cliente con la facilidad de uso que posibilita los terminales móviles.
    • Modelo de negocio: Publicidad, programa de afilición o incluso venta de la app.
  • Gametify
    • Spotify de videojuegos. Se autodescribe solo. Pagas una cuota mensual y puedes acceder a un catálogo de videojuegos.
    • Modelo de negocio: Pago por subscripción.

Los ganadores del Hackathon fueron 6-Games. Su idea, demo y puesta en escena fue muy buena (…y no falló nada :). Ganaron un fantástico tablet de BQ Reader cada uno. ¡Enhorabuena!

Nosotros, @sdelamo y un servidor como Devs, y @hugocamper, Francisco Díaz y Víctor Fabre , desarrollamos el PoC de Otogami App. La verdad es que para ser una iOS App de 1-day quedó bastante bien. A nivel técnico nos permitio experimentar nuevas tecnologías como Django REST Framework o las nuevas funcionalidades de iOS6.  ¡Gracias chicos!

Conclusiones

Quiero expresar mis impresiones y conclusiones sobre el 1º Hackathon DEV+BIZ

  • Sobre el tema, creo que hubiera sido más interesante propuesta que ayudaran a la venta de videojuegos de gran tamaño que se venden en tiendas físicas. Creo que la venta de juegos casuales o móviles, no tienen tanta necesidad de reinvención como los modelos tradicionales de venta de empresas como GAME, FNAC, etc.
  • Los tiempos de exposición fueron muy largos e irregulares provocando que la audiencia desconectara pronto. ¡Hay que sumar el día entero de trabajo a la capacidad de atención!
  • Para la presentación de modelos negocio usaria el Business Canvas Model. Sólo eso. Seria una forma unificada que todo el mundo usaria y entenderia. Algo así se podría hacer para explicar la parte Dev.
  • Creo que se hecho en falta gente de la industria IP como SCEE, Microsoft, GAME o Nintendo.
  • También eché en falta game philosophers como mis amigos de ArsGames.
  • Curiosamente no escuche la palabrota “gamification” en toda la jornada.
  • La jodida WiFi volvió a dar problemas en las DEMOS. ¿Lo solucionaremos algún día? Es como dejar a un cirujano sin bisturí teniendo el corazón del paciente abierto.
  • Todas las ideas me gustaron, pero no vi ninguna idea killer que ayude a vender más juegos.
  • Como siempre, el buen rollo reinó y “me lo pase como un enano” 🙂

Quiero agradecer a los organizadores,  @miquelcamps, @akey (Dani Rojo), @MarkVillaCampa y cia. por el gran trabajo que hicieron.

A título personal, muchas gracias a esos patrocinadores, Fon, bq readers, EDIS, MailJet, Generacion X y Red Bull, que ayudan a que estos geniales eventos sean posibles aún teniendo los presupuestos de marketing tan ajustados.

Los datos sobre los proyectos presentados los he sacado de mi mala memoria. Si hay algo raro o incorrecto, pls, comentadlo y lo corrijo o añado.

Ahora toca recuperar fuerzas para el 4º Hackathon (esperemos que no caiga en tan mala fecha ni coincida con otro hackathon como el de BlackBerry).

Bye!

Recursos

Isobar Create London: nuestra primera app NFC, Pick&Drop

iPubs Team en Isobar Create London NFC

iPubs Team en Isobar Create London NFC

El penúltimo fin de semana de Marzo (24 y 25) tuvo lugar en Londres el 1º hackathon para el desarrollo de aplicaciones móviles que hacen uso de tecnología NFC en el viejo continente.

Anteriormente a Europa, se celebraron dos eventos en Estados Unidos (el primero en San Francisco y el segundo en Boston).

El evento fue organizado por Isobar (una agencia de comunicación moderna) en colaboración con una buena cartera de patners, destacando principalmente O2 (Telefónica UK). BlueVia, Google, Samsung, Kelloggs, Adidas, Kovio, etc.

La idea es sencilla, durante dos días y una noche te proporcionan la tecnología NFC, ayuda de expertos en la materia y un excelente catering para que equipos de hasta 5 profesionales (desarrolladores y/o diseñadores) creen una aplicación NFC que asombre al mundo.

El objetivo es claro, la tecnología NFC está ahí pero no se ha encontrado todavía un caso de uso que haga que las masas quieran ya un móvil con NFC. Los principales casos se que se conocen son: pagos, configurar el móvil según el contexto, cupones de descuento, intercambio de información entre terminales, etc. ¿Habrá que esperar a que Apple tome cartas en el asunto?

En las primeras horas del evento, recibimos charlas inspiradoras por parte de grandes profesionales de los respectivos patners. Así por ejemplo, habló el ingeniero jefe en NFC de Google, ingenieros de innovación de Proxama, el código ético de Diageo, etc.

Con las pilas de “innovación” cargadas nos pusimos manos a la obra. Ya teníamos la idea medio preparada y algunos diseños gráficos hechos.

Los criterios de evaluación iban buscando premiar aplicaciones que rompieran con lo visto hasta ahora, que establecieran relaciones marca-cliente, que ayudaran a retener la marca a los potenciales clientes y que tuvieran una clara explotación comercial.

Con estos requisitos la aplicación salió sola: “Pick&Drop“. Nuestra idea era crear un ecosistema de promociones representada por “chapitas” (badges). Es muy sencillo. Al tocar con tu móvil una tarjeta NFC “pick” obtienes la promoción. Cuando encuentras un punto “drop” puedes canjear dicha promoción.

Un ejemplo gráfico, en un revista ves un badge “pick” por una cerveza gratis. Pasas el móvil y lo capturas. Luego te acercas a tu bar o pub preferido, pasas el móvil otra vez y te ponen tu cerveza, ¿fácil no?

Esto se puede complicar para obtener premios mayores ya que hay promociones que requieren de más códigos. Ejemplo, si obtienes la chapita de la tónica y la chapita de la ginebra, puedes tomarte el gintonic perfecto. Con este mismo esquema se puede hacer un programa de fidelización del cliente, por cada 5 desayunos, 1 gratis.

Otro tipo de promoción que ideamos fueron las promociones para grupos. En este caso, el objetivo de la promoción es atraer a un grupo de amigos hacia una determinada marca, local, etc. Al pasar el móvil por una chapita de este tipo, verás qué amigos tuyos también lo tienen y podrás quedar con ellos para poder disfrutar de la promoción conjunta. Ejemplo, si vienes con dos amigos más a la pizzeria, os damos un pizza familiar gratis. Estas promociones se puede compartir a través de Facebook.

Volviendo al evento, el domingo a las 4pm se terminaba el hackathon y era el momento de presentar el “proof-of-concept” de la idea. Fuimos los primeros en exponer ya que teníamos que volver a casa pronto.

A pesar de que teníamos claro desde el principio que la presentación era clave, fue sin duda la peor presentación que he hecho en mi vida. Creo que nadie se entero de qué fue lo que hicimos. Hay que aprender de los errores para la próxima.

Los premios se dividían en 4 categorías:  retail (venta al por menor), entretenimiento y ocio, eventos deportivos y financiero.

Los ganadores de estas categorias fueron:

  • Retail: We’re Appy con “PillIt“, aplicación que permite llevar control sobre la medicación incluyendo un poco de gamification.
  • Entretenimiento y ocio: Blue Butterfly con “Tap-the-Wifi“, aplicación que permite configurar automaticante tu móvil para conectarte a lared wifi de bares, pubs, hoteles, etc. Ya existía una aplicación en Google Play que permite hacer esto y más cosas: NFC Task launcher
  • Eventos deportivos: Ying Yang con “Total Event“, aplicación para compartir información sobre jugadores durante un partido.
  • Financiero: New found comms con “Street Screen“, aplicación que permite hacer compras desde anuncios publicitarios.

Además de estos premios, habian otros 3 muy jugosos:

  • 10k £ para el desarrollo de la aplicación por parte de Proxama. El ganador volvió a ser “Tap-the-Wifi“. El jurado destacó su utilidad y sencillez.
  • Apoyo para el desarrollo de la aplicación por parte de BlueVía. El ganador fue Team Rollercoaster con una aplicación para reservar sitio en las colas de las atracciones de feria. Cuando tu turno se aproxima, te avisan.
  • Viaje con todos los gastos pagados a Blackberry World Conference en Orlando. El ganador fue London BBDG con “Tesco App“, aplicación que permite mejorar la experiencia de usuario de los compradores.

En líneas generales, parece que el jurado premió la sencillez. Felicidades a todos los ganadores.

Quiero agradecer a Isobar y a todos los patrocinadores por este gran evento que esperamos se replique por el resto de Europa. También añadir una crítica constructiva. La próxima vez que se convoque un evento, por favor, indicar la hora de finalización exacta. Nosotros tuvimos que cambiar la logística del viaje porque en un principio el evento terminaba antes de lo que al final fue. Una buena infraestructura Wi-Fi es muy recomendable (varias redes, baja potencia de emisión, canales ortogonales para que no existan interferencias,etc).

Agradecer también el apoyo que nos dió Andrés de BlueVia para integrar nuestra aplicación con su API.

El material NFC (tarjetas y lectores) que Taggito nos proporcionó fué también muy importante para prepararnos de cara al evento. Muchas gracias.

Ya estamos deseando acudir al próximo evento 🙂

Referencias:

Pantalla de inicio


Pick&Drop: splash screen

Captura de pantalla


Pick&Drop: Screen Capture

Django snippets: Executing standalone scripts

Sometimes it’s necessary run some background or cron tasks in a Django app. For example, you can recollect and email you some stats, purge temporal files, process images, etc.

In these cases, you need access to Django framework but you don’t use neither mod_python, wsgi or manage.py to run it.

I have the following simple snippet for it that works fine in my apps.


#!/usr/bin/env python

import os
import sys

if __name__ == '__main__':

# Setup environ
 os.environ['DJANGO_SETTINGS_MODULE'] = "project_name.settings"
 sys.path.append(<path_to_project_base_dir>)
# Bellow this line, welcome to Django World
# Now you can do things like "from project_name.app_name  import models"

If you want to depth in this topic, you must visit Standalone Django scripts

See you!

Medir el tiempo de respuesta de Django

Midiendo tiempos de respuesta en Django

Midiendo tiempos de respuesta en Django

El tiempo de respuesta de un servicio web es el tiempo que transcurre desde que se realiza una petición hasta que se envía el último byte de respuesta al cliente.

Es vital para las aplicaciones web medir este tiempo con el objeto de optimizar la capacidad de respuesta. Nos interesa por tanto minimizar el tiempo de respuesta.

Para aplicaciones web desarrolladas con el framework Django he desarrollado un middleware sencillo que mide el tiempo de respuesta de proceso desde que Django es “consciente” (Python).

Sin duda el middleware, es una de las características que más me gusta de Django. Permite, entre otras tantas cosas, añadir objetos al request.

Una clase middleware debe tener al menos un método: process_request.

En nuestro caso, tenemos 3 métodos: process_request, process_response y __init__.

La idea es simple. Cuando llega un request, añadimos una marca de tiempo al request (process_request).

Cuando ese request es procesado, obtenemos la diferencia de tiempo y la “logueamos” (process_response).

En __init__ simplemente inicializamos el contexto de logging.

Os dejo el código.

¡Que aproveche! 🙂

import logging
from datetime import datetime
from django.conf import settings
class LogTime(object):

        def __init__(self):

                self.log = logging.getLogger("tm")
                self.log.setLevel(logging.INFO)
                formatter = logging.Formatter('[%(asctime)s] "%(message)s"','%Y-%m-%d %a %H:%M:%S')
                if len(self.log.handlers) == 0:
                        hdlr = logging.FileHandler(settings.LOG_TIME_FILE)
                        hdlr.setFormatter(formatter)
                        self.log.addHandler(hdlr)

        def process_request(self,request):

                request.dtLogTimeStart = datetime.now()

        def process_response(self,request,response):
                if 'dtLogTimeStart' in dir(request):
                        delta = datetime.now()-request.dtLogTimeStart
                        self.log.info("req: %s - time: %i.%06i" % (request.path,delta.seconds,delta.microseconds))
                return response