Moved to own domain

After a long time living in wordpress.com. I decided to move to my own hosted domain. You can read more in my brand new blog

Tenerife startup weekend

El pasado fin de semana, tuve la suerte de poder asistir a un evento de esos que cambian la forma de ver la vida. En esta entrada voy a tratar de resumir qué significó para mi, poder asistir, y esbozaré algunas de las cosas que aprendí.

Aquellos que me conocen personalmente saben que soy emprendedor por naturaleza, me gusta marcarme nuevos objetivos y soy propenso a aceptar grandes desafíos. Asistir a un evento de esta clase era algo que tenía que pasar tarde o temprano. Desde aquí quiero agradecer a todos los que lo han hecho posible, y no me refiero solo a los organizadores del evento, sino a mi encantador mujer que se hizo cargo de los niños un fin de semana sin mi. De todo corazón ¡GRACIAS!.

Ya metidos en el evento, se mezclan una suerte de condiciones que componen el coctel perfecto para lograr grandes cosas. Por un lado un montón de gente que comparte el espíritu emprendedor, con ganas de trabajar y de hacer algo grande. Por otro un puñado de gente con experiencia en el mundo de la emprendeduría con ganas de ayudar a aquellos que están empezando. En frente un fin de semana sin ninguna distracción en el que trabajar sin descanso.

Lo primero que aprendimos fue que las ideas no valen nada, lo único que tiene valor es el equipo y la ejecución. Esto lo aprendimos ni más ni menos que del señor Carlos Blanco, uno de los grandes de nuestro país.

El segundo día fue una mezcla de altibajos. Llegamos con las pilas cargadas, y una idea clara, y nos pusimos a trabajar raudos y veloces. Lo primero fue identificar los componentes del negocio mediante un lean canvas, tras lo cual comenzamos a trabajar sin más dilación. A mi me toco hacer las veces de director del equipo técnico. El equipo técnico estaba compuesto por cuatro personas y enseguida me di cuenta de que teníamos que subdividirnos. Este día lo pasamos creando un prototipo funcional de la demo, aunque finalmente tuvimos que tirar gran parte del trabajo a la basura, al darnos cuenta de que la herramienta de prototipado usada nos complicaría muchísimo poder aplicar la imagen que queríamos aplicar. A mitad del día, recibimos la visita de los mentores, que nos hicieron ver que necesitamos un growth hacker para conseguir que el proyecto tire para adelante. Además nos mostraron su preocupación por algunas partes del modelo de negocio sobre las que tuvimos que ir trabajando. Como la metodología es Lean quisimos validar las hipótesis de negocio y pasamos una encuesta de la que conseguimos más de 200 respuestas y efectivamente mostraban que el problema que estamos intentando solucionar existe.

El tercer día, gracias al gran Samuel Jorge García y su insomnio, volvimos a la senda adecuada, y pasamos casi todo el día terminando el prototipo del que luego sacaríamos los pantallazos. Fue un día tremendamente interesante, en el que plantemos una estructura de costes muy básica y montamos una presentación para el pitch final con la estructura “Emocional, racional, emocional”. Fue un trabajo intenso y complejo pero los resultados se vieron ya que en mi opinión nuestro pitch fue el mejor de los que se presentaron. No todo en la vida es pitching, y quedamos segundos, el resto de los equipos también habían estado trabajando y presentaron unos proyectos interesantísimos. Espero que todos tengan (tengamos mejor jejeje) mucho éxito.

Me llevo una experiencia irrepetible, un grupo increíble, unas ganas de trabajar inmensas y una pregunta abierta ¿qué hubiera pasado si en lugar de un fin de semana el evento durara una semana o un mes?

Factory Boy

I develop a Django application which has been rolling for three years now. I barely have a 40% of code coverage through tests, which is pretty low. When writing tests, the most annoying thing in my opinion is to get a dataset to work with. Using fixtures is the direct way, but it’s not that easy to write them by hand, also it’s difficult to get them in sync with migrations. But we have factory boy to save the day.

I first met factory boy in

As soon as I could, I gave it a try.

I created some Factories

class RolFactory(factory.django.DjangoModelFactory):
    FACTORY_FOR = Rol

    name = factory.Sequence(lambda n: u"rol%s" % n)
    description = u"A test rol"

class CacheFactory(factory.django.DjangoModelFactory):
    FACTORY_FOR = Cache

    id = factory.Sequence(lambda n: n)
    code = factory.Sequence(int)
    document_number = factory.Sequence(lambda n: u"%s" % n)
    name = u"John"
    surname = u"Doe"

You just need to include those attributes that need default values. In my case I included all the attributes not nullable or without a default value. So now I can start using the factories. One interesting thing is that you can use attributes not defined in factory class, but existing in model.

So lets use them a bit

    r = RolFactory.create(name="alumno")
    CacheFactory.create(rol=r)

It’s that simple. If my models are modified, then I may need to modify the factory class, but it would be just in one place.

As factories are classes, you can import and use them where needed, so I guess I may write them under every app directory, not sure if in tests.py file or in a separate file, but that would be another story.

Suds cache

I’m not a fan of cache where they are not needed, because it can turn a simple task into a no-so-simple task, specially when you don’t expect a cache to exists. This happens to suds, the probably best web service access package existing in python. It uses a cache with a default duration of one day stored in /tmp/suds. That cache only cache wsdl and xsd.

I see this feature could have huge advantages to projects using lots of wsdl and xsd under heavy load, because wsdl and xsd don’t change that often,  however its default values could lead to a headache, because you (at least not me) don’t expect to be a cache at all, and, after you realize there are a cache, you wouldn’t expect to be stored in disk.

To purge the cache, well in my case just the entry of the wsdl I need to be reloaded, it works to remove the file containing it.

Django signals and fixtures

Django signals are one of the more powerful tools we have. They let you focus in what you want to do, and the keep you dry. They can be also a real nightmare when there are lots of them, not well documented, and even one signal could perform tasks that sends signals to other handlers. Under this circumstances testing is your only ally, but creating fixtures is a tedious work, well, creating fixtures that works on medium complex projects is always a pain, but if you have lots of signals connected, then it turns into hell.

As the project is complex, you can’t simply dumpdata, so you must write your fixtures “by hand”. When you do this, and try to load them with loaddata, you realize that some of the database objects you manually created in your fixture, are magically generated when the fixture is loaded, and then, when it tries to load what you wrote, it fails because the data is already on db. The question is that, when your fixtures are loaded, they send signals, so you will need to note this. However the django developers provided us a way to skip those signals when a operation such as syncdb or loaddata is in progress. Whenever this happens, the signal handler will receive an extra keyword in **kwargs raw, so you can use it to avoid running a signal handler like this.

@receiver(post_save, sender=ModelA)
def signal_handler(sender, **kwargs):
    raw = kwargs.get('raw', False)
    if not raw:
        <do whatever>

Unfortunately you need to do this in all the signals you want to skip. I’m considering do it in all the signals handlers that perform database inserts or updates.