Test notifications in gnome

I was quite impressed about rails/mac folks creating fancy test notifications by simply connecting zentest/autotest with growl. I wondered how can I get something similar in gnome. As it turns out - it's pretty straightforward - involves only 4 lines of python code and works using dbus. It uses one of the parts freedesktop.org - NotifyService. I created a tiny script for that. It looks rather nice and integrates well (the same service is used by gajim or rhythmbox).


Here's how you invoke it: konrad@machine:~$ python ./bin/test_notifier/test_notifier.py pass 'Test passed' "4 tests
9 assertions
0 failures
0 errors"

konrad@machine:~$ python ./bin/test_notifier/test_notifier.py fail 'Test failed' "4 tests
9 assertions
2 failures
0 errors"


And the code itself (btw: forget about 4 lines - here comes error handling:>)

import sys
import dbus
from os import path, getcwd

try:
    status, title, message = sys.argv[1:]
    icon_filename = {'pass': 'passed.png', 'fail': 'failed.png'}.get(status)
except Exception:
    print 'Usage:\n\t\ttest_notifier [fail|pass] title message'
    exit(0)

bus = dbus.SessionBus()
notifyService = bus.get_object("org.freedesktop.Notifications", 
                               '/org/freedesktop/Notifications')
interface = dbus.Interface(notifyService, 
                           'org.freedesktop.Notifications')

icon_filename = path.join(getcwd(), 
                          path.dirname(__file__), 
                          icon_filename)

interface.Notify('test_runner', 0, 
        icon_filename, 
        title, message,
        [], {}, -1)

XP reflections

While accumulating XP culture, I was a bit taken aback by the "don't think forward (more than one day)" rule. I couldn't quite understand why I shouldn't implement my functionality in more modular way (which would make future changes easier) even if I was _sure_ the future changes will be introduced. I stopped thinking about it at some moment, and really recently found the reason: finding the correct design of your system (i.e. one that makes changes easy) is impossible before you actually find yourself introducing them. In other words: since you always end up changing your design, don't mind for the future. YAGNI...

Resolver rocks!

John Udell took a first look at resolver, and he loves it! The entry is followed by a screencast showing what Resolver can do. I had an impression, that John was taken by the possibility of keeping python objects in the grid and interacting with them in non-ordinary way (which gives some more interesting ideas, like enabling drag-n-dropping objects attributes from within say, cell's context menu [ - hey? Clerkenwell? Anyone? :D]).

It looks like the screencast was taken through VNC, so the window decorations look mediocre (this screenshot from resolver hacks depicts what it should look like). Still, the fact, that resolver gains interest gives me some childish joy :D

PyCon UK - late review (part 3, last :>)

There were several interesting talks in the conference. Last two lectures I want to write about are Jonathan Hartley's TDD talk, and Simon Willison's OpenID keynote.

I had opportunity to work with Jonathan for the last two months, so I pretty much imagined what he was going to say. I couldn't quite imagine how. I mean: ok, it's fun, but how can you describe it? John somehow managed to present it in a really interesting manner, giving step-by-step examples to let you feel what you're doing, and providing clear graphs to let you grasp the whole idea. In fact, I liked the graphs so much that I think someone should write a script to generate such things for everyday coding.

I saved to the end Simon Willison's OpenID keynote. Simon is one of the creators of django (I mean: the _really_ first creators :>), a web developer, and (effectively) an OpenID evangelist. His mindblowing speaking skills along with enormous amount of concised information and the fact that everyone attended the lecture (keynote) made openID to stay in minds of all PyConners.

PyCon UK - late review (part 2)

On the first day, between 11:30am and 1:00pm, there were two other interesting talks: one ebout PyPy by Michael Hudson and the other about Stackless by Christian Tismer.

PyPy

PyPy is python compiler written in python. I heard of it before, but never got quite interested. However, the talk changed it a dramatically. We've been presented bunch of exciting features that PyPy enables, that being: dynamic sandboxing, objects becoming other objects, dynamic parser changes (evil but fun :>) and many others. I like the idea of running PyPy in any python implementation in order to compile python scripts to native format (which means: assembly, .net intermediate language, java bytecode or some crazy stuff like javascript, or python itself [sicko]). I _really_ like the idea of running PyPy in any python implementation in order to compile PyPy itself into assembly. Unfortunately, the JIT compiler is still being developped, so we'll have to wait a for that.

Stackless

Stackless python is python implementation that removes GIL and introduces lightweight threads. This gives you a couple of new possibilities, one of which is to mime Erlang :P (and that's actually pretty good, since erlang's syntax doesn't appeal to me). There are some projects that make heavy use of stackless, the most famous probably being Eve online (where each player has his of her very own thread, yeah!). And there's one interesting pearl: there is a version of stackless, that's implemented on PyPy framework.

PyCon UK - late review (part 1)

PyCon UK ended on Sunday. Unfortunately, I didn't have any machine on my during the conference. That's why my review is a bit late.

The first thing to say - it was awesome. Two days of extremely interesting talks and conversations with a bunch (200) of incredibly smart people. Some of the talks definitely need mentioning.

Resolver

I'll begin with lectures given by my colleagues. First one: The New Age of the Amateur by Giles Thomas was a presentation of Resolver - an advanced spreadsheet application we're working on. It is believed to solve many problems that excel power user have today. I have never had an opportunity to look at Resolver from potential user's point of view and, I must say, it was positively surprising experience.

Silverlight

Second event I attended was Michael's talk on Silverlight. Silverlight is Microsoft's "flash killer" product. What's interesting - very much in a manner C# was created, they managed to avoid mistakes made by their predecessors. I really like Silverlight's ability to be scripted in more than one language (including python, ruby and - I guess - any .net language). What's more, Silverlight apps should be able to run on Linux. Mono guys did an enormous feat implementing large part of Silverlight in Moonlight in a remarkable 21-day-long sprint. Moonlight is aiming to provide full implementation soon, but obviously it's not a matter of one month any more. The talk was very interesting. Michael did a great job playing with Silverlight before, and certainly knew what he was talking about. I'm very excited on his proof-of-concept Web IDE.

What is the *exact* distinction between Model and View in MVC?

Couple of days ago, we encountered simple problem: Whether spreadsheet selection should be stored in model or in view. It seems obvious that the right place for it is the view, since data doesn't change with selection. Fine, but how do we know what the data is. In particular: how do we know that the selection is not part of it. I mean: It's clear isn't it. If it's clear, there should be a simple answer to the original question.

Quite an easy take is "data is what gets saved". Unfortunately, excel saves the selection along with the rest of the file. Since the saving criterion is useless, how about other apps using your data? Nope. There's nothing that prevents other apps from reading your selection state if it was saved. Our definition seems to escape.

Let me repeat what I want to achieve. Considering spreadsheet application: you got the model, which describes the content of each cell in each sheet, and you got the view, which tells you which part of the sheet you are watching right now. Since the view has a state, it needs to have it very own MVC to keep a track of it. So, what prevents us from merging view state (view model) into the data model (*the* Model)? The feeling, that it's wrong? Fine, but why you get that feeling? Why? WHYYYY? (this is the shot from 30 meters above [and receding] of a man on his knees crying in void. Never mind.)

Let's use maths. View is a projection of the real object (the data/model). Being a projection, it loses parts of the information. Does that analogy help us with the selection problem? Not really.

I spent some time thinking on this, investigating few other ideas, but in the end I gave up. I couldn't find any definition that was not tautological or simply wrong. The final conclusion is somewhat sad: there's no such thing as clear distinction. It's just like the zero being a natural number problem: it's a matter of taste, a matter of deal.

And why I had the feeling for obvious distinction? Most probably from the paper spredsheet analogy. Spreadsheets are so easy to grasp mainly because you can imagine them as pieces of papers.

More important consequence from that is that you'll never know if your MVC splitting was the right one. There are only practical issues. You may follow the way your brain tells you or not. You will never know if you were right. You will only know eventually that you were wrong. Now this is sad...

P.S. What makes life endurable here is agile appreach(yeah!), but this is a topic for other post.