Stefano Apostolico's Blog

Using multiple serializers with DjangoRestFramework

2017-10-10T00:00:00+02:00

How to use different serializers with DjangoRestFramework

Imagine to have a viewset and you want to parametrize the output, using different serializers.

class Person(models.Model):
    title = models.CharField(...)
    last_name = models.CharField(...)
    first_name = models.CharField(...)
    mail = models.EmailField(...)
    address = models.CharField(...)
    birthday = models.DateField()

class PersonSerializer(HouseSerializer):    
    full_name = serializers.SerializerMethodField()

    class Meta:
        model = House
        fields = ('title', 'last_name', 'first_name', 'mail', 'full_name')

    def get_full_name(self, obj):
        return "{0.last_name}, {1.first_name}".format(obj)

class PersonView(DynamicSerializerMixin, generics.ListAPIView):
    queryset = House.objects.all()
    serializer_class = HouseSerializer

it is easy to build a "serializer factory" to build on the fly

cache = {}

def serializer_factory(model, base=ModelSerializer, fields=None, exclude=None):
    attrs = {'model': model}
    if fields is not None:
        attrs['fields'] = fields
    if exclude is not None:
        attrs['exclude'] = exclude

    parent = (object,)
    if hasattr(base, 'Meta'):
        parent = (base.Meta, object)
    Meta = type(str('Meta'), parent, attrs)
    if model:
        class_name = model.__name__ + 'Serializer'
    else:
        class_name = 'Serializer'
    return type(base)(class_name, (base,), {'Meta': Meta, })


class DynamicSerializerMixin(object):
    serializers_fieldsets = {'std': None}
    serializer_class = ModelSerializer

    def get_serializer_class(self):
        ser = self.request.QUERY_PARAMS.get('serializer', 'std')
        if ser not in cache:                
            fields = self.serializers_fieldsets.get(ser, 'std')
            cache[ser] =  serializer_factory(self.model,
                                  self.serializer_class,
                                  fields=fields)

        return cache[ser]

adopt it:

class PersonView(DynamicSerializerMixin, generics.ListAPIView):
    queryset = Person.objects.all()
    serializer_class = PersonSerializer
    serializers_fieldsets = {'std': PersonSerializer,
                             'simple': ('first_name', 'last_name')
                             }

invoke it:

?serializer=std
?serializer=simpleA

py.test and Django

2016-11-10T00:00:00+01:00

Test django application with py.test and WebTest

I quit using default Django test suite some years ago, sometimes I go back to it to see if something new can change my mind, but up to now I continue to prefer my choice:

py.test
WebTest with django-webtest.

Why?

Several reasons - here's a few:

It can run unittest, doctest, and nose, style tests suites, making it ideal for new and legacy projects.
It includes an intuitively named raises context manager for testing exceptions.
You can define fixture arguments to generate baseline data. This is very, very different from Django-style fixtures.
Via pytest.ini/setup.cfg you can change the behavior of pytest.
Integrates nicely with setup.py.
WebTest allows you to model a user's experience much more closely as it is smart about mark-up. Instead of hand-crafting GET and POST requests, you can use the WebTest API to follow links and submit forms - this is what users actually do. As a result, your tests accurately capture user stories.
Writing functional tests with WebTest is both easier and quicker than using Django's test client. It's much simpler to fill in forms that construct complicated arrays of POST data - this is particularly noticable with formsets.
The WebTest response object supports several ways of parsing the response HTML, making it easy to make complicated assertions about the response.
response.showbrowser() is simply amazing

False Myths: Customers does not care about technology they care about money

2016-10-26T00:00:00+02:00

Yesterday a sentence like this was posted in a collaboration platform:

"At the end of the day your customers don’t care whether you’re agile, lean or practice design thinking."

I fully agree with the essence of this idea, but it does sounds misleading in one aspect of presentation: This sentence, when interpreted as "customers only care about money", could be a huge mistake.

Just because our customers do not care how we work, it does not mean that we should not care about methodologies and process. I don't care what products and tools my dentist uses; it's upto him, but I expect he cares about them a lot! Tools, processes and metodologies are in our domain and scope - though they do not need to be endorsed by or exposed to our customers, without an internal professional approach, we cannot deliver great products and services that solve meaningful problems for them in effective ways.

When the Business/Customer allocates a budget, there's an expectation of return value: a working, reliable product delivered in time and within budget. If something goes wrong, the Business/Customer complains about money because it is the only "unit of measure" that he/she knows that is understandable in our domain, and is the only common language he/she can speak with us.

As an analogy, When a new-bought car breaks down after a week, we go back to the vendor and complain

"Hey, I paid $$$ for this car but it does not work anymore!",

only because we do not know how to say

"Hey, this car has a design error , you should not have sold it!".

Ultimately, businesses care about "good products", but the way to deliver them cannot pass through a wrong approach or ignoring any methodology only because businesses don't care about them "explicitly".

Again, as an analogy from our experience on flights, I don't think we would expect our planes to be driven overlooking the current best practices, procedures and commonsense, or, even worst, piloted by the first available person.

Skills, knowledge and mastering the domain is the only way to give to the Business what it expects, any another approach is only a workaroud that undermines our reputation and credibility day after day.

django and pdbpp

2015-10-26T00:00:00+01:00

Quick tips how to enable pdb with django

pdbpp is my favourite debugger, I use integrated IDE for my development, but I still prefer use the command line for most of my daily work. I find Django sometimes cryptic when some error occurs, (ie. data migrations) this simple hack, enables pdb when I need, without install third party packages.

It is possible run python -m pdb manage.py <command> but this has, sometimes, some strange side effects, like continue prompting for restarting, and I loose autocompletion feature (I know, I'm lazy).

In the end I rolled out this custom manage.py.

#!/usr/bin/env python
import os
import sys

if __name__ == '__main__':
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'wfp_commonapi.settings._%s' % os.environ['USER'])
    from django.core.management import execute_from_command_line

    debug_on_error = '--pdb' in sys.argv
    args = [a for a in sys.argv if a != '--pdb']
    try:
        execute_from_command_line(args)
    except:
        if debug_on_error:
            import pdb, traceback
            type, value, tb = sys.exc_info()
            traceback.print_exc()
            pdb.post_mortem(tb)
        else:
            raise

now I can

./manage.py migrate app1 --pdb

and we'll enter in the pdb screen if an error occurs

cx-Oracle 5.2 on OSX (El Capitan)

2015-10-14T00:00:00+02:00

Install cx-Oracle 5.2 on OSX (El Capitan), mostly for my reference

What we install

Oracle Instant Client 64bit 11.2.0.4.0
cx-Oracle 5.2

export $ORACLE_HOME=/data/oracle/instantclient_11_2
mkdir -p $ORACLE_HONE

export DYLD_LIBRARY_PATH=$ORACLE_HOME
export LD_LIBRARY_PATH=$ORACLE_HOME

unzip 'instantclient*.zip' -d $ORACLE_HOME/..

ln -s $ORACLE_HOME/libclntsh.dylib.11.1 $ORACLE_HOME/libclntsh.dylib
pip install cx-Oracle