by Mary
Public service announcement: I’m on holidays and effectively unreachable until August 29, unless you’re in the select group of people who I’ve already given emergency personal/technical contact details to. (Yes! The cool kids!)
If there was something I was meant to do for you before I left… to be honest it’s probably already too late to remind me.
I have reason to believe that some people don’t like this new sponsorship era of sponsoring people to do anything before they’ve actually done it (as opposed to just pledging). If you people are out there waiting to give me money for Dry July, I will observe that is is now August.
Quick recap: Dry July, do not drink alcohol in the month of July. Fundraiser for the Prince of Wales hospital. Sponsor me here, it’s a sure thing now that July is actually over.
I sadly can’t regale you with tales of the new perspective on life that doing this gave me, except that opportunities to drink are offered to me more frequently than I realised prior to Dry July. I probably had about eight active offers of a drink during the month (including the Tuesday night drinks I go to every week). Andrew and I almost never drink at home: I don’t think we have had a drink without guests over since New Year, so I hadn’t thought it was so many. In a normal month I would probably have turned down only four or five of those opportunities rather than every one of them. It is an annoying feeling, I remember feeling much the same during linux.conf.au, when I couldn’t drink because of a medication interaction.
I drank more on the weekend than I usually would: one glass of wine Friday, and then 600 mL of beer (it was a Bavarian beer tasting thing, three 200 mL samples) followed by a cocktail on Saturday. My tolerance for alcohol does not appear especially affected by the month of abstinence, which makes sense considering my low exposure anyway.
I intend to change my drinking habits not at all long term as a result of Dry July. But hopefully the hospital is a tiny bit richer.
Filed under ideas I don’t want to forget because I may act on them in the next month or two
:
<mary> I have been seriously tempted to write an irssi plugin that goes something like: <mary> "you have tried to input a URL into a channel, press Ctrl+K to confirm" <mary> and "you have tried to input what looks like copy and pasted IRC into an IRC channel, Ctrl-K to confirm"
I tend to commit almost everything that doesn’t move to version control, but there’s one major exception: the source data for my website puzzling.org, which is mostly text files. So as to avoid various nuisances to do with calculating data I already have and storing it somewhere else and needing to keep that store up to date I keep track of the time that a file was modified by… asking the filesystem when this file was last modified.
So far so good, and tools like Blosxom do likewise, except that file timestamps tend not to be version controlled, which means if I store my files on more than one machine and rely purely on version control to maintain the date the dates don’t end up the same.
So instead I use Unison, which keeps the trees and dates in sync at the expensive of losing all my history (I also have incremental backups for a couple of months, but that’s a recent addition to my data management). As Martin Pool apparently did at some point, although that was some months before he started writing a version control tool.
Thus, plugin idea for version control system: optional version of additional filesystem metadata, especially times.
It’s a big shame because your very first experience of unittesting is unittest.main and your next experience is this brick wall of suck and you think… I’m just not going to use it.
Andrew and I have had Jonathan Lange to visit this week while he awaits home Internet, which means there’s been a lot of talk about unit testing.
Coincidently, today I am at the very beginning of a small-ish Python project, one just large enough that I’d like to make sure it’s fairly correct from the beginning, meaning I’d like to make sure it has automated tests, a sensible module layout and that kind of thing. It’s small enough that I bet I could get it working quickly enough without automated tests… and therein lies the trap. In order to do the right thing when starting a scratch project, doing the right thing needs to be either really really easy, or really easy to correct if it was skipped at the junkcode stage of the project.
Consider various aspects of the project. I haven’t worried too much about correct module naming, because at least with Bazaar renaming directories will be easy to do later. But I am trying to do unit testing from the very beginning because adding good testing to an existing codebase of much over 200 lines converges on impossible pretty quickly. And since I create new files in Python the way some other people create functions and some other other people create new lines, I separate my test modules early which results in this brick wall of suck:
import unittest tests = [ # list of strings containing test module names ] def my_import(name): # No love to http://docs.python.org/lib/built-in-funcs.html mod = __import__(name) components = name.split('.') for comp in components[1:]: mod = getattr(mod, comp) return mod def runAll(): runner = unittest.TextTestRunner() suite = unittest.TestSuite() for testmodulename in tests: testmodule = my_import(testmodulename) print testmodule loader = unittest.TestLoader() suite.addTests(loader.loadTestsFromModule(testmodule)) result = runner.run(suite)
That is, unittest does not do test discovery, you have to tell it where to find all the test modules, and you run slap-bang into Python’s tedious programmatic interface to its own import mechanisms.
So, unit testing in Python: hard to get right later, but not easy enough to get right at the beginning. (Consider: the code above is currently about three quarters of the codebase in question.) I will watch Jonathan’s pyunit3k with interest. (For my PhD I use Twisted’s trial test runner, but I am not willing to introduce a dependency on Twisted for this project purely for a better test runner.)
In general, it would be excellent if some firm and right person was to write a guide to best practices for Python projects, with regard to starting a project so that it is easy to test, easy to collaborate on, easy to install and (and I think this is somewhat missing too) easy for the distributions to package. And that all these steps be so trivial that they can be carried out at the beginning of almost every project.
For ages now the puzzling.org website has had a regular bug whereby instead of displaying correctly it would dump a bunch of HTTP headers and HTML in plain text to people’s web browsers. I’ve known about it for at least a year and people have been emailing me periodically.
This should now be fixed. The problem was Twisted Web/Nevow’s implementation of HTTP’s 304 code (not modified). At least in the Twisted versions in Ubuntu Hardy and possibly still in trunk twisted.web returns a body of data as well as that header, which is an HTTP MUST NOT. (twisted.web2 looks like it gets this right, we didn’t check for sure.)
If it continues to happen and you’re one of the few and far between people who wants to help me debug the rarely used HTTP implementation that runs my website, tcpdumps (all traffic, don’t limit the packet size) are the most useful debugging tool. At least I’ll know where to look in future.
Tim Connors and Andrew Pollock are bothered by microblogging syndicated on Planet Linux Australia. This promises to be an absolute pile-on in the bikeshedding manner, that is, very few people are competent to comment on blog entries about SQL database underpinnings or encryption design, but microblogging is exactly the sort of thing everyone has an opinion on and shortly we’ll hear them all. I hope I’m early in the crush…
Microblogging itself varies in appeal for me as much as any other kind of blogging. I guess the highs aren’t quite so high: I’ve never seen a Twitter I wanted to bookmark. But they’re 140 characters, plenty short enough to skim even if they aren’t changing the world. I am not a huge fan of microblogging that is clearly written for either the writer themselves (unadorned having dinner
working late
without any attempt to write about it in a such a way as other people might want to read) or as an alternative to SMSing a significant other your plans for the evening. But most of it is about the same quality and style as the random jabs at the world people occasionally insert into IRC (in fact Andrew Bennetts should have a twitter account, but never will), so, fine.
However I too do not generally find people syndicating their microblogging to their main blog very interesting. Firstly, if I want to read your twitter feed, I’m already subscribed to it through Twitter, so having it pop up in your main blog is just two copies of the same thing. If the other microblogging sites take off enough I’ll add people to my feed reader instead. The same is usually true of del.icio.us aggregations, Pia and Jeff Waugh being something of an exception because they provide commentary aimed at readers. I certainly won’t be syndicating my del.icio.us feed any time soon, it’s entirely aimed at me and if you want to subscribe that’s your lookout.
For Planets, I suggest the solution is to add a sidebar or two for microblogging and links provided by Planet authors. This enables feed discovery and mild entertainment for people who like the microblogging, but means that people aren’t stumbling on 30 character thoughts or unadorned collections of links when they expected substantive prose. In this model, people syndicating that stuff to their main blog are required to figure out how to exclude it from what the Planet aggregates.
Dear Google,
I am not sure how to quantify the exact amount of evil involved in unsolicited bulk email (I guess I could argue that it’s even commercial email, because you are a company promoting a product, even if it is a coding competition), but let me assure you, the amount of evil is exactly the same in 2008 as it was either time in 2005, and for that matter, in 2003.
So, knock it off already.
As the very model of a modern moderate drinker, you can think of me as your reasonably safe bet to back for Dry July, the Prince of Wales Hospital fundraiser in which participants gather sponsorship and do not consume alcohol for a month! (If people want wild and daring, you’re out of luck with me until Movember, sorry.)
As it happens, one of my sisters and I have both been patients of Prince of Wales Hospital during our lives (in my case, my recent compression chamber therapy for suspected decompression sickness was done there) and so this should be a matter dear to your heart as a way of ensuring the continuation of the Gardiner lines in the eons to come. And the Gardiner livers, under-abused things that they might be.
Sponsor me through my Dry July page.
Yesterday I posted that, per Unlocking IP, that iTunes U was only accepting content on the understanding that the university itself didn’t have the right to re-licence. Nicholas did what I didn’t though, and went to the source to find that the iTunes U licensing overview is quite a gentle friendly document instructing universities to check that their copyright is in order before distributing it and suggesting Creative Commons and GFDL as potentially appropriate licences for academic work. Nicholas also observes that universities are retaining their copyright, eg SMU.
So unless iTunes U USA and iTunes U AU are signicantly different beasts, it looks like all this is an object lesson (for me) in not citing without sighting (not trusting to a summary of anything without seeing the original documents). But good news overall, and my apologies for stupidly perpetrating confusion.