Welcome, hordes of visitors!

isnomore.net is being heavily refurbished. I'm tackling css, updating sections and refactoring code for public exposure (starting with zzbot).

I'll post here as I go. I'm aiming the site at programming, let's see how long I can keep up.

My interest in the OLPC project was recently boosted by an opportunity that came up for writing applications (or "activities", in XO-lingo) for it. That ended up going nowhere, but my interest remained.

I'll refrain from commenting on how ground-breaking it is and all that. There's enough of it going on. I won't even tag this post  "python" ;).

However, it seems from the latest news that not only the laptop's price has gone up, but that it needs (somewhat quickly) more orders to be viable.

Dr. Negroponte has repeatedly stated that there are currently no plans to put the laptop on the market. From an Ars Technica article:

Michalis Bletsas, chief connectivity officer for the project, told the BBC that the industry should be thinking less about pushing technology designed for the Western world on the rest of the planet, and more about developing technologies specifically for the developing world. "The way to do it is not to try and deploy tried and trusted technology but to try and develop technology specifically targeted to the developing world," he said.

Fair enough. You don't want to sell an unfinished product to regular consumers, and you don't want to finish the product aiming at regular consumers. But what about making it available for hackers? Individuals, universities, NGOs and others might be willing not only to pay more for XO, but also to contribute, test and develop for the project. They (we!) would probably even put up with paying up front and waiting some time until it arrives. What could top getting free expert workforce, other than getting paying expert workforce?

The Developer's Program seems like a nice option, but its resources are limited and apparently only hardware geeks are getting any actual hardware these days.

Let us help you, dr. Negroponte! We'll pay for our own hardware, and for that of others. Emulation is just not the same thing. Give us a gadget to play on and we might just make it viable for you.

Pretty please?

Just added Google AdSense to the site. Please let me know if it's too intrusive.

BTW, I couldn't figure out (in the two minutes I spent on it, anyway) why it doesn't seem to show at the bottom of the zzbot page. I might try to google a solution later...

More than one year ago, Danilo Sato and I started a pet project to practice TDD. We ended up not making all that much progress so far, codewise (over one year! So much for "agile"...), but it's been a great learning exercise. It's a Python test-driven implementation of the Stratego game, and Danilo has documented our early programming sessions on his blog (in Portuguese, I'm waiting for him to catch up to start bitching for an English translation, but I'll post stuff about it here as well). We've recently resumed work on it and it should show up both here and at Danilo's.

Anyway, I have since developed a taste for testing (a "teste", you could say) and, when I started cleaning up nnebs, I found myself writing tests for everything as I went through the code (no, it had no tests before; yes, it was my graduation project; anyone can have a Comp. Sci. B.Sc. these days...). Doctests, even, but more on that later.

One thing that struck me as interesting, in this process, came up while I was writing tests for some state-related classes. Nnebs is basically a spam filter, and I had decided its classifiers (as well as a few other classes) should be stateful, that is, they should be able to easily represent a particular configuration and switch back to it when requested. Since a few different classes would be stateful, I created a Stateful class from which classes wishing to be stateful should inherit. So far, so good. All these classes needed to do was inherit from Stateful and define which attributes would make up their states.

To describe a state itself, I created another class (aptly named "State") to hold attributes and their default values. It defined methods to add, delete, set and query attributes. It also defined that two state objects would be equal if their attributes and values were the same.

The State class was about 30 lines of code and worked quite well. However, while writing its tests I noticed they seemed a bit too trivial, which struck me as odd. I was having to write tests like

>>> State(attr1=val1, attr2=val2) == State(attr1=val1, attr2=val2)
True
>>> State(attr1=val1).get('attr1')
val1

That just doesn't seem right :)

I figured I could delegate some of State's behaviour by making it a subclass of "dict". Great, there goes my "get" implementation. And my equality implementation. And my __del__ implementation. And my initialization implementation. And, well, I assume you can take it from here.

So State is now simply a dict. Running the tests confirmed that everything worked as before. My code is 30 lines of bug-food (a.k.a. "code") shorter. And I'm a lot happier with nnebs and more confident in its code.

I started refactoring and doctesting nnebs, today. Last time I coded for it I was in such a hurry, in order to meet my graduation project's deadline, that, well, let's just say I'm not too proud of how it was delivered :P

Anyway, it's nice to play with nnebs once again, and I should put it online again soon.

Ok, third spam comment in a row. Time to integrate coreblog2 with akismet (and maybe later with nnebs). Should be up soon.

Yipes, I changed the workflow for COREBlog2 and failed to notice that most of my previous posts went into a private state. Publishing them resulted in a weird ordering of posts. I still need to fine-tune coreblog's workflow, so Zarquon knows what'll happen then.

Anyway, not to waste a perfectly fine post ranting randomly about COREBlog, allow me to rant structuredly. This is a list of what I'd like to see in coreblog (typing caps gets old fast)  in the near future (i.e., I consider them to be bugs of some sort). I'll try to add these myself and submit them to the coreblog people.

• Proper workflows. Other people have come up with solutions to this problem, I'll study that a bit and try to find a flexible way to accomodate both single and multiple poster blogs. This should include optional moderation of comments and trackbacks.
  
• Hooks for spam handling (such as akismet, but allowing for arbitrary tools - hint, hint) in comments and trackbacks.
  
• Fix coreblog's annoying habit of sending trackbacks before the post is published, and every time the post is saved. BTW, does anyone know what the policy is for sending trackbacks (in the Real World)? Once, when the post is published? Everytime something changes in a published post? I'd favour the former.
• Adding categories while editing the post. Sometimes I tackle a new subject and only after writing the post do I realize I need a new category or two. I should be able to add these categories from the post itself, it's annoying having to save the post, then create each category individually, then go back to the post to add them. A simple textarea, one category id per line, should do the job nicely.

This is what comes to mind, at the moment. I'm sure more'll surface.

What would you like to fix in coreblog? I might just be in the mood to throw it in as well :)

Update: I just realized I'm not using the latest version of coreblog (I'm using 0.9b and there's a 0.982b since April 13). I'll upgrade and see if something on this list was addressed.

I've been refactoring nnebs for a few days, now. Bugs found, some code rewritten, some mercilessly thrown away. But, more importantly, I've been adding doctests as I go.

This is my first real-world go at doctests. One thing I thought I'd miss were fixtures, but I found out I don't (not much, anyway). "Setting up" usually means creating an object, sometimes a few auxiliary variables, rarely anything more complex than that. "Tearing down" nearly always means, well, closing the docstring :). I'd use fixtures if I had them, but its absence doesn't bother me at this point.

I am a bit overwhelmed by the doctests-to-code ratio, though. Two-line methods often get a 10-line doctest. I am being very thorough and I know some of my tests could be more compact, but simulating all usage possibilities helps me rethink the code (specially after not touching it for almost a year). I get a clear view of how the code should work, both in words and in execution. On the other hand, when reading back the now-tested code I feel all those docstrings tend to clutter up a bit.

A silly, over-simplified, quasi-fictional example, but similiar to situations I've been facing these days. Say I have an object representing a word from an email message (remember, nnebs is a spam filter). This object stores the word itself and the number of times this word showed up in spam and nonspam messages. Now I want to define the addition of two such objects as a third object representing the same word, with added occurrence counts.

def __add__(self, other):
    """Returns self + other.
    This sum is a Word object representing the same value
    as self and other, but containing the sum of the 
    occurrences of both.

    >>> w1 = Word('semprini', spam=2, nonspam=5)
    >>> w2 = Word('semprini', spam=1, nonspam=10)
    >>> w1 + w2 == Word('semprini', spam=3, nonspam=15)
    True

    Words with different values cannot be added:

    >>> Word('semprini') + Word('dinsdale')
    Traceback (most recent call last):
    ...
    ValueError: Cannot sum distinct Words

    """
    if self.value != other.value:
        raise ValueError('Cannot sum distinct Words')
    return Word(self.value,
                spam=self.spam+other.spam,
                nonspam=self.nonspam+other.nonspam)

I like this docstring, it's very explicit about what the operation should (and should not) do. But it's also three times bigger than the code itself (more, if you notice I wrapped the last line to better fit this blog's layout), and after half a dozen of these there's basically only docstrings on my screen.

So they will almost surely be moved to a separate file. The doctest module integrates nicely with the unittest one, so a next step might be to follow Leo Rochael's suggestion and mix both. I considered starting the doctests file right away, but I find it helpful to write the examples while looking at the code (remember, this is not test-driven, I already had the code and didn't quite remember what all of it did). Of course, I must commit to being honest with myself and not adjusting the tests to the code, but I started this with refactoring in mind anyway, so more often than not I use the code to figure out what I originally expected it to do, write tests and then fix what's broken or unnecessary. It's always trivial to cut and paste all docstrings into a new file later.

But probably the best of both worlds would be to view the doctests as either part of the code or as one single extended interpreter session. That is, docstring folding ("go away, I want to look at the code!") and a docstring-only view ("go away, code!"). I wonder if (how) xemacs can do that...

I've re-ordered my pet-project priorities to 1) fix coreblog; 2) refactor and test zzbot; and 3) continue refactoring, testing and turning nnebs into an actual spam filter (and not a spam filtering testbed). I've also decided to get involved in python (the interpreter) development and have started reviewing patches, let's see how I'll fit this into the aforementioned priorities.

I put coreblog at the top because I've found myself reluctant to post before fixing some of the issues I encountered. I'm upgrading Plone today as a first step to start digging into coreblog, so expect something on that front soon.

On the other hand, I just realized a nice side-effect of being unable to receive trackbacks: no trackback spam!

I still get the email warning, though, so that won't keep me comfortable for too long :)

About two weeks ago, the server that held isnomore.net crashed. Literally. On the floor. I've used the "crashed, literally" joke a lot, these past days, but it's true. The shelf where we put the server fell from the wall and there went isnomore.net (and a few other domains). Obviously, our backup server was on the same shelf, and was found on the floor as well, but, fortunately, its hard drive still worked (unlike our main server's).

We (the {isnomore,cybershark}.net team) had been planning to move to a dedicated hosting anyway, so we took it as a sign from %(deity) and got to it right away. Since there was going to be a few days of downtime anyway, I went ahead and asked my previous ISP to transfer the domain to a registrar where I could control it directly. That, of course, started my very own little comedy of errors which guaranteed that isnomore.net remained unavailable long after the server had been migrated and all other services on it had resumed working properly.

The domain is not transfered yet, but at least I'm back online. I'll resume posting here soon (not counting this post) and I'll return to my priority list as well. Hopefully.