Monthly Archives: December 2008

xtra! xtra!

Posted by on December 16, 2008 4 comments

Yesterday I received my xtracycle, and today I finished the assembly.  Sort of.  I’m still lacking proper shift cable and housing so I’m rocking a single speed xtracycle right now, but I took it on its maiden voyage in the middle of our giant snow.  First off, the xtracycle handles beautifully in the snow.  The bike is so long you can actually get the thing sideways and control it quite nicely.  More importantly, though, this beast can haul anything.  In the photo above, I’m hauling punch ingredients for our work Christmas party.  I can’t wait to haul crap.  If you need a large object transported by bicycle, just let me know.

And now gratuitous roller shots:

hold on!

hold on!

dan is teh roller rockstar

dan is teh roller rockstar

it’s cold.

Posted by on December 15, 2008 No comments

I’d just like to point out that when I went to bed it was 51 degrees, and when I woke up, it was 5 degrees.  So, whoever is in charge of these things, please stop with the order of magnitude temperature changes in 8 hours.

That is all.

the affero public license

Posted by on December 10, 2008 1 comment

After Chris Grubbs and I finished up our work on phlombay.com for a class project about a year ago, we released what little code there was under the Affero Public License.  My reasons were strictly idealogical, and I assume Chris wasn’t going to be selling proprietary versions of the site, so he went along just fine.  However, since that time I’ve really wondered about the utility of license (as an aside, I’ve started work on phlombay again, but that’s another post entirely).

Unlike the GPL, the Affero stipulates that licensed software running on a network and providing a network or web service, must also provide the source.  So while Google is not required to release any modifications to (the GPL licensed) MySQL backing up their search, they would be required to do so were the software licensed under Affero (I think…but what if the DB server is merely accessible via a webapp…hmmm).

Regardless, I had wondered about the utility of this license.  However, that changed today after discovering some of the technorati services such as events and contacts.  These services parse a page looking for microformats and then generate the appropriate file for that microformat (i.e. a vCard or iCal file).  This is a perfect example of when code should be released under the Affero.  By providing the code backing up these services, Technorati would enable users to setup their own servers (to relieve load, enforce uptime requirements, etc) while also ensuring that any modifications would be available to the public.

Though many object to the viral nature of licenses like the GPL, this objection is somewhat neutered in terms of webservices.  Generally the service is available for  (as in beer) already.  Modifications to the code of this service probably serve no real monetary purposes; instead they improve the quality of the service.  Therefore, there is less of a reason to shy away from a viral license when releasing code that backs webservices.   Sure, in a perfect world we wouldn’t need viral licenses (or any licenses at all!), but that world is far off.  Until then, the GPL and the Affero GPL are handy intellecutal property hacks.

private methods are stupid

Posted by on December 8, 2008 1 comment

Today at work in a unit-testing-brown-bag-lunch-session, I spouted off about private methods, claiming that they are stupid.  I stand by my statement; private methods are definitely stupid.  However, my true feelings are a bit more nuanced.

If we assume we are associating a specific chunk of functionality with every method we write, then there is an overarching hubris associated with declaring a method to be private.  When we declare such a method to be private, we  predict the future, saying “only I, the privileged creator of this spectacular class will ever need this functionality.”

But, wait, aren’t there legitimate reasons to declare a private method?  What if a particular method leaves an object in an inconsistent state, debilitating all subsequent calls to “public” methods?  Should this dangerous method be marked private?  Perhaps.  Leaving aside arguments about the necessity to create such a method, there are other ways around the problem.  Convention, not language level constructs solve the issue nicely.  Python, for example, uses a leading underscore for “private” methods, and Smalltalk programmers sometimes place these methods in the “private” protocol.  And while I am not interested in metaphysical debates about what makes a system “object oriented” (I mean really, I think CLOS is perhaps the best OO system out there), with the examples of Smalltalk and Python, it is clear that private methods are not necessary for OO systems.

The argument that private methods are necessary to “protect” code is even sillier.  If we’re afraid of how other programmers might use our classes, then we shouldn’t bother programming.  Not only do these fears foster a sense of mistrust among programmers, but also, they are not easily eliminated.  In the most straightforward cases, users of our classes with access to the code may go through and mark useful methods public (note that loosening protection introduces no bugs in non-reflective code), or worse, copy and paste this functionality into another method entirely.   In more severe cases, the “nefarious” programmer will resort to introspection or disassemblers.

We programmers are tinkerers, and we should be willing to let ourselves tinker.  Sleep easy, and declare your methods to be public!