Friday, October 30, 2009

Behaving as a wave, not a particle

UPDATE: Got one!  Thanks, the webs. :-)
Dear Generousweb,

I'd like an invitation to Google Wave so I can start porting my awesome open source dicebot, Vellumbot, to the new platform.  (I've been talking about doing this since before it was cool--indeed, since before I knew Wave came with its own, apparently non-awesome dicebot.)

Anyone out there interested in helping a brother out?



Saturday, September 19, 2009

Hypy 0.8.4 released

The main focus of this release is a couple of minor bugfixes.

Release Version 0.8.4 (2009.09.19)

Bugfix release.

  • It is now possible to construct an attribute-only search with None for search phrase.

Friday, February 27, 2009

Launched a new Google Group: hypy-discuss

More people are showing interest in the library, so we need a place to go to discuss things archivably: this Google Group for Hypy is it.

Saturday, February 21, 2009

Penny Arcade D&D Podcast - this one has Wil Wheaton

Gabe's artwork for series 2 #1
The newest series of PA D&D Podcasts has started out at the maximum level for funny.  I was literally - not figuratively, not "LOL" but literally by which I mean with my literal lungs - walking around laughing out loud at this in a supermarket.

(First series starts here, but get a podcatcher and subscribe to the feed you technophobe.)

dpkg-origins: 0.9.1

Fixed a minor bug in dpkg-origins. It would crash when a partially-configured but obsoleted package was found in the index. (You might see this in dpkg -l as 'uc' or 'ic'.)  You would probably see this after a dist-upgrade, like I did.  Fixed this bug.

(See this post about dpkg-origins.)

Go get the dpkg-origins script.

Tuesday, January 20, 2009

Hypy 0.8.2 released

A minor version release of Hypy.  No material bugs reported so far.  That's good for my users, but bad for me because I can't do more releases until bugs get reported for me to fix. :-)

Some people would not have been able to easy_install release 0.8.1, so this release fixes that.

Hypy is a fulltext search interface for Python applications.

Homepage, downloads, everything:

Release Version 0.8.2 (2009-01-20)
  • I was unconditionally importing ez_setup in my and that makes it hard to easy_install.  Don't do that.
  • No library functionality change, but now more users can install it.

Tuesday, January 06, 2009

On demonstrating the value of unit tests to beginners

A little anecdote.  I'm slowly trying to get my team to wrap their heads around the idea that any new feature must be accompanied by unit tests as we near the point where they are absolutely required to write unit tests before they write code and the tests become part of the deliverable.  One thing I know is that if you haven't written a lot of unit tests yet, you don't really understand the value of them except very much in the abstract, so I am also trying to point out the value to him as we go.

One of my developers is writing a function that uses the compiler module to inspect some Python code, it's not really important why.  He had just learned how to write some unit tests in Javascript and I was teaching him how to use the stdlib unittest module for his unit tests written in Python.   His implementation isn't written yet, he is just starting to figure out what the interfaces look like, which is a great time to start writing failing tests.

I told him, start with this:

import unittest

class MyTestCase(unittest.TestCase):
  def test_myParseFunction(self):
    assert 0

.. and run that test, which he did, and it failed, and I said "good".  I started pointing out to him ways he could make very minor modifications to his code to make it easier to test (not nearly enough has been written on the subject of making code easier to test, BTW--bloggers, get on it!).

One of the improvements I asked him to make was to move some functions into another, more relevant module than the one he was working in.  He did that, then wrote version two of the unit test:

import unittest
import mynewmodule

class MyTestCase(unittest.TestCase):
  def test_myParseFunction(self):
    self.assertEqual(mynewmodule.myParseFunction("(python.code)"), [expected, output, structure])

Now, remember that he hasn't implemented myParseFunction yet.  So I asked him to run his failing test one more time.  And, a surprise to both of us, we got this:

[ERROR]: test_mymodule.MyTestCase.test_myParseFunction

Traceback (most recent call last):
  File "/usr/lib/python2.5/", line 260, in run
  File ".../", line 7, in test_myParseFunction
    self.assertEqual(mynewmodule.myParseFunction("(python.code)"), [expected, output, structure])
  File ".../", line 19, in myParseFunction
    return compiler.parse(s)
exceptions.NameError: global name 'compiler' is not defined

What the.. oh right!  He imported compiler in the original module, but forgot to move it to the new module.  The unit test - so far, one line long and expected to fail in a relatively uninteresting way, had already found a bug.  My favorite part was that it happened this way to someone learning why we put so much value on unit tests.