Programmer blog

We always write something unusual while doing basic things. Our own bicycles and crutches to work out some unusual situation. Here is another recipe to do a thing like so. I have tried several libraries and readymade decisions. But it assumes you have them installed. And you often try things in console, don't you? Anyway the recipe is simple and quite straightforward. import datetime # Getting first timestamp t1 = datetime . datetime . now ( ) # Your function e.g.: data = [ g . name for g in request . user . groups . all ( ) ] # Second timestamp t2 = datetime . datetime . now ( ) print "Execution time: %s" % ( t1 - t2 ) It is rude and quite simple but may often suit you well to measure execution time in a simple and straightforward manner. Also nice idea to write down this function into logs. It may be handy on refactoring of your core app for e.g.; import datetime import logging log = logging . getLogger ( 'mylogger' ) # Getting ...

I like to invent bicycles in my code. They often come in handy and you basically do not rely on Django version... So upon updating your project's Django version in future times you will not have to refactor half of all the code. So... How do you test http redirects? I usually restrict my time in thinking and write code like if redirect target is hardcoded. And it really is in most of the times. But imagine if you decide to redirect your view response in several places. Or imagine if you're not the only one who owns you'r project's code and there are many collaborators that can change things without warning... And you need to have a test for that view that will test redirects and complex code behavior. I used to check redirects like so: response = self . cliet . get ( '/myview' ) self . assertEqual ( response . status_code , 302 ) # View redirected... All ok... But  if you have some view that can redirect to things that you need to check. How would y...

Django supports security models and methods out of the box. They are Group and Permission objects. Permission is m2m related to internal Django User. I helps you relay on request.user later in your code. You often come to situations where you may need a view to be accessed only by certain group of users.  For example you have the app that has two groups of users. One can search and another one can Index files. Simplest approach is to use Groups here.  In fact you may use permissions in case your app will have several unique users that might do some stuff. In general best approach is to use Group to specify type of users and Permission to specify the role of users in this group. So if you will have Group called 'search' and it will have permission with name, say 'search stuff'. So when you will call: def my_view (request): # ... my view actions ... user_permissions = request.user.user_permissions.all() for p in user...