I’ve found three extensions/libs that apparently could do the job for me (fullhistory, django-history and django-reversion) so I decided to test them, but because of the lack of structure/documentation of the other two I tried just the last one.

django-reversion

(http://code.google.com/p/django-reversion/)

It has a good documentation, integration with the admin and the most important for me a low level api, as I am not using the admin app for this project.

The installation went pretty well (svn co http://django-reversion.googlecode.com/svn/tags/1.1.2/src/reversion to your PYTHONPATH, add the reversion app to your INSTALLED_APPS in settings.py and the usual python manage.py syncdb).

To track the changes of a model you must register it with the reversion framework (importing reversion and calling reversion.register(YourModel)).

Reversion provides some ways for creating revisions of your model and the docs recommend that you choose one of them to use in your project. I chose the MiddleWare method because it seemed the better option for our project, but you should look the reversion documentation and decide which one is the best for you.

After registering the model and installing the MiddleWare no more changes are needed, whenever I save a model a new revision is created on the database. Another cool feature is the follow argument when registering a model. That way you can specify a ForeingKey/ManyToMany field to follow. This means that when you save the model a new revision is created with all “followed” fields in its current state. It’s very useful. See the docs for an example.

The only thing that’s not so clear for me is: what happens if I delete a field from a model that’s registered within reversion? Can you still restore its versions?

But enough of cheap talk, I’ll show you the code.

My first “useful” piece of code for Wave is a Tweet Gadget. It’s a simple Google Gadget that takes advantage of the Wave extensions for interacting with the Wave user. What the gadget does is very simple, it takes a tweet id and using the Twitter API it places the tweet inside the Wave. It’s a simple way to quote a tweet.

I must say that the original idea is not mine, it’s rbp‘s idea. We were chatting using Google Wave and he wanted to quote a tweet. That’s how we started looking ways of doing it.

Stateless gadget

I started writing a simple gadget that using the Google Gadgets API makes a request using the Twitter API and shows the tweet in the wave. The problem of this first version was that it does not keep the state, so if you reload/rejoin the wave, you won’t see the tweet, but instead you will see the text box for entering the tweet id.

In this first version you can see how to make a JSON Async Request using the Google Gadgets API. It’s very simple, all you need to do is to set the parameter gadgets.io.RequestParameters.CONTENT_TYPE to gadgets.io.ContentType.JSON and then call gadgets.io.makeRequest(url, callback, params) where callback is a function that receives the JSON object.A very simple example:


function myCallback(obj) {
jsondata = obj.data;
// access the attributes as jsondata['key']
// ...
}
function makesJSONRequest(url) {
params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.JSON;
gadgets.io.makeRequest(url, myCallback, params);
}


Adding state

Until now the gadget is a simple Google Gadget as it does not use any feature of Google Wave. Also it’s not so useful because it can’t keep the tweet id when you leave the Wave. And worse, people will never see the tweet you quoted. One of the main differences between simple Google Gadgets and Wave Gadgets is their ability to keep, set and change state. By state I mean information. You can keep user preferences, a game score or a tweet id (or even a tweet).

I decided that the easiest way was to store the tweet as it will appear in the wave (with HTML entities and everything). The new version will keep the tweet information when the user enters the tweet id, so everybody in the wave can see the quoted tweet.

You can see the Gadget code to understand how state works in Google Wave, but what’s most important:

• use a callback (with wave.setStateCallback()) to be aware of state changes
• wave.getState() returns an state dict-like object which you can set and get information from
• use wave.getState().get(‘key’) for getting an information
• and wave.getState().submitDelta({‘key1:’ value1, ‘key2′: value2} for setting information

And that’s it. It’s very simple, hope you enjoy it

This weekend (October 3rd and 4th) will happen the first “Transparência HackDay” (“Transparency HackDay” in english), a free and open hacking event with focus on bringing together hackers, activists, managers and people with ideas to make government information/public data more accessible for everyone using and writing web tools.

I’m attending and one of my ideas is to hack CET (Companhia de Engenharia de Tráfego / Traffic Engineering Company) data and make them available. The idea is to improve a crawler I wrote (in python ) that downloads and stores data about the traffic in São Paulo every 30 minutes from the “traffic now” CET website (as they don’t store it [or at least don't provide anything]).

More information about the HackDay (in portuguese):
http://www.slideshare.net/esferamobi/transparencia-hackday-proposta

This month we will meet to watch/present some lightning talks and to talk about our participation at the Fórum Internacional de Software Livre (FISL 10).

The meeting will be hold at the SP HackLab, May 23. More details (in pt-br): GruPy-SP wiki.

See you there

With CHDK (Canon Hack Development Kit) I can write my own scripts (in LUA or BASIC) to control the camera functions. It also enables new features and improve old ones. Really nice free software project

And for hackers, it’s well documented (including the source-code). I’ll try it better and post some results here (with pictures and some code I hope )

But… I’ve spent a lot of time to make it work with my Ubuntu. Why? Mainly because of the freakin’ VIA proprietary video driver. So I decided to write here some tips about how to get Ubuntu working on the 2133 (after trying to configure the xorg.conf for 3 hours because I hadn’t made a backup of the one that was working ).

The problem I have is that the desktop is bigger than the screen. Oh, you say, it’s just the Virtual xorg.conf Option.

IT’S NOT. Damn it!

Thanks to VIA there is a driver option called PanelID. This option is “well documented” in the README file.

The first thing you need to do is to tell the driver that your PanelID is 17. Why? I really don’t know. PanelID 17 means, accordingly to the README, that your display (or your Panel) resolution is 1024×600. The problem is that I want my resolution to be 1280×768 (which is supported by 2133). Anyway, using option “PanelID” 17 solves the problem partially, the desktop isn’t bigger than the screen anymore.

BUT… it thinks that your resolution is 1024×600 (because of the PanelID option, probably), so try to imagine what a 1280×768 desktop looks like in a 1024×600 display (or panel, whatever). The result is that you can see 3/4 of your Desktop, but your pointer “sees” the “panel” borders (i mean, it can’t go any longer than the screen limits).

To solve this problem you need to tell the X server that you have a Virtual display of 1024×600 (yes, you’re lying!!!) so it will arrange your 1280×768 desktop inside this virtual display of 1024×600. To do this you need to add the line

Virtual 1024 600

in the Display subsection of the Screen section.

Your xorg.conf will look like this (the relevant sections only):

Section “Device”
Identifier “via-P4M900 Device 0″
BoardName “Chrome9 HC IGP”
BusID “PCI:1:0:0″
Driver “via”
Option “Monitor-LCD” “HP-2133 LCD”
Option “PanelID” “17″
Option “NoDDCValue”
EndSection
…
Section “Screen”
…
Subsection “Display”
Depth 24
Modes “1280×768-60.0″
Virtual 1024 600
EndSubsection
…
EndSection

If you have any trouble with the video (or anything) trying to install Ubuntu on the HP 2133 Mini, leave a comment and I promise I’ll TRY to help

Some notes on day two:

• In São Paulo we had two lighting talks before the “official” conference. João (JS) talked about a little script he wrote that uses PyGame to display text from a .txt file in a presentation format. Rbp explained a bit about 2to3 (the Python 2.x [actually x equals 6] to Python 3 conversion tool) and showed some examples.
• First talk. Mark Ramm had some good points. Specially, IMO, about making Django more modular, which means that each part of it doesn’t depend on other parts of the framework. As an example, you can choose to use the Django ORM without using Django. But, please, don’t make it a lot of little packages that you need to grab together to start using the framework. One of the nice things about Django is that it’s simple to start using it (install one package and then django-admin.py startproject)
• Official lighting talks. As always, a great moment on any Python conference. Lots of curious and interesting stuff (and other stuff not so interesting… or not interesting at all [for me, obviously]). Funny moment: People, don’t use GMail over HTTP, there IS HTTPS support
• Schema evolution, three options: DMigration, South and Django Evolution. There are a lot of doubts about each one and I think I need to test all of them to choose one (and hope that they start collaborating to each other and make something really good). But it’s great to see that there is people working on that.
• Last talk was Django’s Future by, obviously, Jacob and Adrian. It was more like a chat between them. Some good ideas and discussions. Then they received questions/requests/suggestions from the public. Things like, dropping old python versions support, python 3 support, documentation, debugging tools, etc. I think that some suggestions/requests were really nice and I hope that Django developers (and the community) take them seriously. This was a great opportunity for developers to receive feedback from the community (users).

That’s it for 2008. Again, I’d like to thank Rodolpho and Google for making it possible to attend to DjangoCon from São Paulo. Congratulations to DjangoCon organizers and to the Django community!

And, of course, thanks GruPy-SP people

Pictures: Rbp’s DjangoCon set @ Flickr

It was 11p.m. Almost sleeping in this blue big puff

Some notes on the first day of event:

• I expected more news from GvR on his talk about GAE (nothing really new).
• David Cramer talk about High Performance was kinda heavy (but good things learned)
• The history behind Django is hilarious (State of Django by Jacob and Adrian)
• It seems Django is getting bigger (contributors) and better (features). Good!
• Really good talk by Malcolm Tredinnick about the Django ORM
• GeoDjango seems very interesting, but it’s not for me (at least now…)
• Cal Henderson made good “feature requests” and “bug reports” live, the unreadable SQL generated by Django scares me a bit… but not that much

In general it was great. I can’t wait for the lighting talks tomorrow (probably the best moment on any Python conference ).

Oh, the snacks @ Google (Sao Paulo) are awesome!

It’s really easy and obvious (it’s always easy and obvious with Python and Django).

First, you’ll need the admin.py file in your app directory.


from django.contrib import admin
from myproject.myapp.models import MyModel

admin.site.register(MyModel, MyModelAdmin)


The add_view method is called when you try to add an entry using the admin. There are other interesting methods you should look too, for customizing the admin behavior (change_view, delete_view, etc).

Another way to customize things is to write your own ModelForm, but it’s beyond the scope of this post

Thanks to Google (I think specially to Rodolpho) DjangoCon will be transmitted to Google’s Office in São Paulo while the conference is held in Mountain View.

Cool

I’m definitively going! So, Saturday and Sunday (September 6th and 7th) @ Google’s Office, see you there!