Tag Archives: django

Farewell Django

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

Protecting Django Application Against Brute Force Password Guessing

lockWhen 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

Web Clients Are Getting Thick

Remembering days when client-server rules the world, then days when everybody praised light web clients where all user interface (UI) was prepared on web server and any user action was communicated back to server (this could lead to heavy network traffic – I’ve seen one mainstream ERP  program, where a change in one input, say line item quantity,  lead to several megabytes being sent over network).  I’m quite amused to see how we’re returning back to thick clients and passing  more and more UI tasks back to user devices.   This probably make sense, taking into account the computing power available in user devices now (my mobile has approximately same computing power (dual core 1.2 GHz ARM CPU)  as  a reasonable  server  ten years back(Sun V240 for instance)) and  improvement of web browsers and especially their Javascript engines.   Normally utilization on an average client machine would be very low, unless client is dealing with digital media, so using  available computing  power there  is an obvious step. Network bandwidth could be now  more precious resource then client  computing cycles. Continue reading Web Clients Are Getting Thick

Django tests auto-discover

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 tests.py or 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

Long Running Taks in Web App/Django

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