Recently I’ve been reviving 2 years old Django application (myplaces) (from version 1.5.5 to latest version 1.9) and I was very unpleasantly surprised how tedious it was. As Django evolved some features got deprecated and removed and must have been replaced in the code. And it’s not only Django but also other contributed libraries are evolving as rapidly. In my application I was using django-rest-framework, which changed so significantly in version 3, that I cannot use it in my application without basically rebuilding the whole application.
Some of the changes might be necessary, but many where just cosmetic changes in names ( mimetype -> content_type, etc.), which I do not see as much of value add. Even core python still keeps bit of naming fuss in favour of backward compatibility ( for instance string.startswith, string.endswith made it till ver.3, even if they are not in line with PEP008 – python naming standards).
But it’s not only about changes of interface between versions (there is a fair process to deprecate features so when one follows development, it’s relatively easy to stay up to date), but it’s mainly all concept of the Django. Django was created more then 10 years ago, when web development was focused around servers and everything happened there. But situation changed radically ( as I have written some time ago). Now a lot of things is happening in the browser and you can have complete applications running there (recently I discovered this cool application, which is running almost completely in the browser, it’s just using a stream of events from the server). Accordingly servers now are used more to provide APIs to browser applications or to route real time communication to/from/between browsers. Continue reading Farewell Django
When you bring your web application live, you can expected various types of attacks – one could be a brute force scanning of possible logins. As a standard mean of prevention against such types of attacks login should be temporarily disabled after some number of unsuccessful attempts. For Django nice package called django-lockout exists.
Main advantage of this package is that it keeps history of unsuccessful login attempts in memory (using Django cache system), so checks are very quick. django-lockout is fairly easy to implement, however I’ve found one issue, when it is used together with django admin site.
Continue reading Protecting Django Application Against Brute Force Password Guessing
Django framework provides integrated tests runner, which can be started by
./manage/py test (see docs for more details, key advantage of this runner is that it’ll create new empty database for tests, so they do not interfere with each other or your development instance). This tests runner runs unit tests from
models.py modules in active projects. However in larger projects we would like to have other organization of tests code – have for instance special test package within project that contains many testing modules, each focused on particular aspect of the application. Continue reading Django tests auto-discover
Some types of web applications require to start long running tasks – like import of file, compilation etc., but user still needs to have real time updates about progress of the task, eventually some error messages, warnings from the task (cannot import particular line, compilation error). There are existing robust solutions like Celery, but it is aways fun to reinvent the wheel In this case we focus on simple solution, without need for request broker in middle, which enables immediate/ real time updates on running tasks to client browser.
For our solution we will use two cool technologies/libraries web sockets and zeromq library. Continue reading Long Running Taks in Web App/Django