Nagy Viktor (V)

Kép a férfiakról

2009-09-27T10:27:25Z

Néhány haveromat beválogatták egy filmforgatásra, ahol egy férfivá-avatást jásztanak majd el. Ehhez mindannyiuk haját kopaszra borotválják. Erről már a válogatáson is tudtak. Íme egy jelenet a borotválásból: Ma történt meg a kopaszra borotválás. Miközben kopasztott Magdi néni, a következő párbeszédet sederintette le mögöttem. Jött egy másik srác, és mondta, hogy őneki kéne a haja a hétvégére. Tudni kell, hogy kb nullással volt körbenyírva, a fejtetőn meg 10 cm2-en 3mm hajkorona. Magdi néni megkérdezte, hogy:

Miért, most lesz a lagzija?

A gyerek csak mondta, hogy igen most. Aztán kapott még a pofájába, hogy akkor miért vállalta el stb, stb. De a legjobb:

A férfiak mindenből mekkora problémát csinálnak!

Itt már hangosan röhögtem, hogy ezt jól megkaptuk. A srác kezdte nem érteni a ránehezedő nyomást, és magába roskadóan utolsó próbálkozásként sértődötten odatette Magdi néninek, hogy:

Ezt majd én eldöntöm.

Magdi néni, borotvált tovább, és ugyanazzal a lendülettel, alig alázva a srácot:

Hát persze, hogy eldönti. …

Kicsit semmibe lett nézve a hisztijével együtt. Szóval jól állunk. Férfivá avatásos forgatás, és fel sem merül senkiben, hogy valami hibádzik. Mit jelenthetett férfinak lenni. Ma nincs ilyen szertartás, mindenki férfi? Mi történt az elmút 2-3 ezer évben, hogy fodrász Magdi néni csípőből kicsinál egy kis pöcst, aki annak idején valószínűleg egy harcos férfi lett volna.

A skac meg ült a padon, mint egy tök, a kis sérójával, aztán elkullogott. Azt hiszem van még tennivaló. Mennyi férfit kell még legyártani, mire ismét kialakul egy közfelfogás, hogy mit is jelent a férfi. Van munka.

Vim actually seems to be quite nice for Python/Django development

2009-09-15T02:05:40Z

In the past days there was a quite nice discussion on Editors of choice on the list, and this encouraged me to give Vim another try. This time, it seems to be rather fruitful! My vim setup is stored online at my Launchpad repo, feel free to check it out.

To get a quickstart I’ve read what plugins others have recommended on the above list discussion, and in the Django Wiki on using Vim.

Whatever plugins you use, you might find my djvim.py 1 script useful to start (g)vim ready for django development. Actually, it assumes omnicomplete as well, but I guess this is not a big requirement.

After, I have checked all the plugins and things that I could find on the two pages mentioned previously, finally decided to stay with the following:

A short description of my settings related to each of them follows.

Omnicomplete allows code completion in python, javascript, etc. It’s original key binding is <Ctrl-x><Ctrl-o>, instead of <Ctrl-Space> the one I’m familiar with. As a result, I’ve added
```
imap <C-Space> <C-x><C-o>
```
to my .vimrc file.
TagList also has some weird key bindings, and very long command names to type, so I’ve defined
```
map <F4> :TlistToggle<CR>
```
It’s worth noting that I did not manage to make TagList to automatically scan the files I open, so the djvim.py file takes care of this, and tells vim which directories to scan at startup. This is definitely not the nicest way to go, but good for a Vim novice.

Besides installing these plugins, as I am a big fan of Eclipse’s debugging with PyDev, I wrote my first Vim function to run the test suite. It is a rather simple script, and it’s extremely non-interactive, but at least it is a first step. It basically runs ./manage.py test with the given application and the settings file you set at startup, and reads the output into a new window.

After spending a short day around Vim I really enjoy it, and will try to stick with it for a while. But there are still some shortcomings in which you might be able to help me out.

how can I set up taglist to automatically tag the files that I open for editing?
have a shortcut to start the development server. As Vim is not able to handle an interactive shell, this basically means to open a terminal and run the server in there, or regularly read to output of ./manage.py runserver.
have shortcuts to other commands, like shell_plus
make my extremely powerful DJtest script able to jump to the code when there is an error/failure
have django.vim syntax set for every html file by default

If you have any favourite settings, tweaks that I could use, please share them with me below!

Getting donations from PayPal

2009-07-18T11:30:50Z

During my trip in Bulgaria starting in a couple of weeks we will take part in a fund-raising mountain hiking for the Karin Dom foundation. As besides our participation we would like to help them financially as well we decided to put together a small website where friends and colleagues might sponsor us, so we can transfer their donations to Karin Dom.

To accomplish this task, I wrote a small django application, django-donation. This application let’s you easily receive donations on your website, and tries to show some relevant information about your sponsors, like to total amount collected. Moreover, depending on the sponsors’ wishes you might show their name and donation as well.

During this work I have learned several things:

Circumventing PayPal’s security checks is a breeze (but still annoying to have to) For the donation I thought I will need a Business type account. Probably I was wrong as a Premium account would suffice, but when I realised this my account was already changed into a Business account, and PayPal was asking for all kind of weird papers. For some reason, they were not very eager to change back my account type, thus I went on and asked all kind of recommendations from Karin Dom, and explained to PayPal that actually I am not affiliated to them, we are just collecting funds for them. Finally they allowed my account, and now I can collect the donations. The twist in this story is that Karin Dom struggles getting the Business status, thus despite the PayPal button on their site, you can donate to them only via direct transfers.

Use the identifier if you can Unfortunately django-donation still has some flaws. The main problem is that I am not saving the unique identifiers of every transaction, and several of our donors were registered twice or even more times. I will fix this once I have some more time (might be tonight?), or feel free to do it, if you have some free time. :)

Finally, you can check out our Karin Dom sponsorship site here.

Export to CSV with Django

2009-06-02T09:36:41Z

The past week as a sub-project of django-conference, I’ve built a really simple and hopefully useful application to make csv exporting extremely easy.

It uses python’s csv library, and can be set up for example with the following code in your urlconf:

from export_csv.views import export_csv 

export_attendees = {
    'queryset': Attendee.objects.all(),
    'filter_by': 'conference__pk',
    'export_data': {'is_presenter': 'Presents',
        'user.get_full_name': 'Attendee',
        'conference': 'Conference',
        'user.get_profile.affiliation': 'Affiliation',
        },
    'require_permission': 'conference.delete_attendee',
}

urlpatterns = patterns('',
    url(r'^export/attendees/(?P<object_id>\d+)/$', export_csv, 
    export_attendees, name='export_attendees'),
)

This code was taken from an ongoing project to build a conference administering application for django (and for the Hungarian Economists Association).

Basically, the above setting will take a queryset by default that can be further filtered to get the data to be exported, and the export_data dictionary describes the columns to be exported. As the example shows, the columns can be either callable or simple properties, and will be evaluated from the instances of the exported queryset, like attendee_instance.is_presenter(). While column headers are given as the values for export_data.

The view code is really simple, the only tricky part was to construct the callable/non-callable object paths described in export_data, this is done by the following method

def get_attr(object, attrs=None):
    if attrs == None or attrs == []:
        return object
    current = attrs.pop(0)
    try:
        return get_attr(callable(getattr(object, current)) and 
                    getattr(object, current)() or 
                    getattr(object, current), attrs)
    except ObjectDoesNotExist:
        return not_available

If you would like to add some extra functionality, like date based exporting, or just would like to play with the code, go and grab it from launchpad:

django-export-csv
and its first implementation in django-conference

What to test in django?

2009-05-24T15:25:31Z

I’m continuously trying to get used to test driven development, as I agree with its many advantages cited around the web. Still, I often find it hard to come up with a necessary (and hopefully sufficient) list of tests. Moreover, as I often code for fun only, I don’t pay much attention to the question. This has changed now as I got a paying project. Here are my first insights, I hope it will help other django enthusiasts as well. :)

The bottom line is test every method you write, including output variables and inside logic. Moreover, write tests that pass as they mimick normal usage, and then start to think about tests that fail if someone tries abnormal usage (like setting a start date after an end date).

Testing models

The model contains your business logic and data. Something no user should be able to avoid or misuse. As django itself is thoroughly tested there is not much reason to test whether a NullBooleanField accepts None as a value, and in general I see no reason in testing a model’s attributes.

On the other hand every defined method should be tested! For example, if you have a model to represent Comments with approved and published attributes, in the save method you’ll likely avoid saving if approved==True and published==False. This is a logic to be tested. You should similarly check your get_absolute_url (and similar) methods whether they provide proper output.

class ComentModel(models.Model):
    author = models.ForeignKey(User)
    comment = models.CharField
    published = models.BooleanField
    approved = models.NullBooleanField

    def save(self, force_insert=False, force_update=False):
        if approved==True and published==False:
            return
        super(Submission, self).save(force_insert, force_update)

Testing forms

My feeling is that many people misunderstand the use of forms. Basically forms are to interact with non-trusted users (and sometimes to extend the admin functionality as well, but that’s a different story).

This being said, it might happen that you have the same functionality on the admin and on your main site, like adding a comment for something. The difference being that on the admin site the user can pretend to be any other user for example, or can immediately approve his comment. While on the main site the user can comment only under his own name, and every comment might need approval. Despite this difference, both comments will be stored in the same Model.

Moreover, every logic related to a bit complex data that will be stored in the database should be included in your form definition, instead of using your views. This for example allows you to easily reuse the same form processing in different views (e.g. APIs might need different views than simple HTML, but they will still process the same data).

As this is the point many posts miss, I’ll repeat it: when you would like to save data coming form users in a model rather keep your views simple, and make your forms complex, than having complex views and simple forms.

So, as we will have some hard-working form classes, what should we test? The same principle applies as before: test every method you define! If there is any reason to define your own __init__ method, then you should test the modified form properties as well.

For example, take a conference application. Every conference has many Topics, and if you want to present a paper you might need to select a Topic when you submit your idea. But the form should show only the topics for the conference you are interested in. This can be achieved by overwriting the __init__ method like this

class SubmissionForm(RegistrationForm):
    topic = forms.ModelChoiceField(label=_('Select a topic'), 
           queryset=models.Topic.objects.all(), empty_label=None,
           help_text=_('Topics help our reviewers to coordinate their work. \
            Please find a topic that best matches your paper'))

    def __init__(self, *args, **kwargs):
        super(SubmissionForm, self).__init__(*args, **kwargs)
        self.fields['topic'].queryset=\
            models.Conference.objects.get(pk=kwargs['initial']['conference']).topic_set.all()

In this case we should test that form.fields['topic'].queryset contains all the topics of the given conference, and only those.

Testing views

As you already know, you should check every method you define. Moreover, you should check that the methods you want to be restricted (e.g. by the @login_required decorator) are really restricted, but are available for authorised users. For more subtle restrictions, like showing only your own posts further testing is necessary, as this assumes that the user should be logged in, but still can’t see every post.

Moreover, if you are using forms like above that should be initialised, then you should check that they are indeed properly initialised. In the above case this would mean to check the template context variable for the form object, and see the value of response.context['myform'].initial.

Testing templates

As I am not a designer guy, I’ve found this is the easy part! Basically, I just test for the variables that the designers might need to put together the content of the page. Like this:

class TemplateTests(MyTestCase):

    def check_template_var(self, rsp, var):
        '''
        Check for template variable ``var`` in response rsp
        '''
        if isinstance(rsp.context, dict):
            contexts = [rsp.context,]
        else:
            contexts = rsp.context

        for c in contexts: 
            if c.has_key(var):
                return True
        return False        

    def test_conference_list_html(self):
        rsp = self.client.get(reverse('conference_list'))
        self.assertTrue(self.check_template_var(rsp, 'conference_list'),
                        "conference_list is not set for conference_list.html")

Other tests

It might happen that you write some custom template tags, filter, or some strange admin functionality. I haven’t thought much about testing these yet, but for template tags at least there are some posts on the web

Conclusion

The bottom line is to test every method you write, including output variables and inside logic.