There ain't no commenting thing. Mail me at kake@earth.li
. I like
getting mail.
There ain't no commenting thing. Mail me at kake@earth.li
. I like
getting mail.
View current version link broken on http://openguides.org/london/index.cgi?id=Gaucho_Grill&version=1
Look at Pod::Simple::Wiki
CGI::Wiki::Plugin::Locator::UK - make sure it doesn't die if there are non-numeric co-ords in the database, if I can - or don't let non-numeric co-ords be stored, or something.
OpenGuides - preview doesn't work when you only have metadata and no content?
Check out why CGI::Wiki::Formatter::UseMod can do second-level nested lists but not third-level.
Look at Richard's makereadme thing (parsing yaml file to auto-generate list of prereqs).
Get the OpenGuides running under -T - suspect I'll need to patch Search::InvertedIndex.
Page renaming for CGI::Wiki. Also document somewhere why I gave up on changing it to use private page IDs.
I stopped updating this, bad me. I'm no good at timesheets either.
Mostly been working on stuff for the London.crafts wiki - a few enhancements to CGI::Wiki::Kwiki (which really needs a more appropriate name), but mostly planning out what I want to do with the yarn/pattern database. I want people to be able to use it to catalogue their stashes, to find suitable substitutions for patterns that use yarns they can't get hold of, to find suitable patterns for yarns that they have and want to use. The classes are mostly written, thanks to Class::DBI, but I'm putting off writing the glue.
I'm finding this pretty satisfying to work on, since it's something I have a real need for, its components are useful already even though the big picture is nowhere near completion, and I don't think anyone's likely to pop up and reinvent it.
Cut the OpenGuides stuff short because I'd promised crazyinsomniac
that I'd get back to them about the weird CGI::Wiki test failures
they've been getting. The problem seems to be that ->retrieve_node
sometimes works and sometimes doesn't. I've not seen these failures
from anyone else, and the complication is that crazyinsomniac is
running Windows - a platform I don't have available to me.
Still working on this. Very little progress. Bah.
Released CGI::Wiki::Kwiki 0.41 - just a few tweaks to the tests to avoid test failures on systems without CGI::Wiki::Formatter::Multiple installed.
Started making notes for perl.com article on OpenGuides. While I was writing the section on authentication I realised that we really should be storing IP addresses like all other wikis in the whole world ever. So made a start on that.
Day off to visit friends.
Released CGI::Wiki::Kwiki 0.4 - now with multiple formatter support.
Released CGI::Wiki 0.49 - now you can make your metadata search be case-insensitive. It really does make much more sense like this.
Released OpenGuides 0.25 - the simple search box will now look for your terms in the categories and locales of the nodes as well as in the titles and bodies - so for example a search on "holborn & pubs" will Do The Right Thing. Finally this search box is mostly working as I expect it to - Principle of Least Surprise.
I need a beer now.
Multiple formatter support for CGI::Wiki::Kwiki is mostly done now. This afternoon I need to:
* Check that my tests properly cover the case where only one formatter is specified
* Test that case in real life - ie get the London.crafts wiki running on this version
* Add facility to decide which formatter will be the default in the edit dropdown
* Make it clear in the docs that the method of specifying a formatter has changed
* Commit it and release it
That should be done by mid-afternoon with any luck, and then I'll do some work on OpenGuides.
Released CGI::Wiki::Formatter::UseMod 0.09 - a fix for its habit of sprinkling <br /> all over the place and thus surrounding tables with huge amounts of whitespace.
Got CGI::Wiki::Kwiki into a new CVS repository set up by Tom on his new box.
Released a minor fix to CGI::Wiki::Kwiki - the removal of a bogus
use CGI qw( :standard );
from CGI::Wiki 0.48 had revealed a
small bug.
Released CGI::Wiki::Formatter::Multiple 0.01 - it only supports ->format
so far but it's a nice start.
Hacked about on CGI::Wiki::Kwiki for a couple of hours - nothing committed or released yet, but I'm well on the way to having easy-to-use multiple formatter support. This has been the end goal of most of today's programming, since I want to set up a wiki for the CGI::Wiki rewrite, and I'd like to be able to treat documentation, test, code and discussion nodes differently.
Warning: this blog may be tedious for the next few weeks. I want to document all the programming tasks that I've been doing, so I can prove to myself that I'm not just being an unemployed slacker, but am working just as hard as when I was being paid, except on my own stuff.
I'm not going to work every day though, since that would involve staying in the house far too much for sanity.
(Yes I have finally given up and admitted that people other than me read this, hence the warning.)
Released CGI::Wiki::Kwiki 0.31 - tidied up the tests as per previous blog entry because the difficulty of testing the previous version was holding me back on further development.
Released CGI::Wiki 0.48, just a few small changes to allow the formatters access to the node metadata - I need this to allow multiple formatters per wiki.
Cast on for CGI::Wiki::Formatter::Multiple - ie, wrote the
documentation, Build.PL and a simple use_ok
test. I could write
a big screed here about similarities I've noticed between knitting and
programming, but I won't.
I left my job yesterday, before the end of the trial period but it was already clear that it wasn't working out.
In roughly the 24 hours since then, I've designed and implemented an alpha release of an application that lets the members of my craft group add details of yarns they've used and what gauge they got with them, and search for appropriate yarns for a given gauge (many patterns will specify not only the brand of yarn they recommend, which often we can't get locally or in the right colour, but also a gauge measurement to let you find a suitable yarn to substitute). It has a nice big test suite that I wrote as I went along. Oh, and I really enjoyed writing it, too.
Spent a few hours over the weekend playing about with Games::Set in an attempt to make it generate puzzles like the Set Daily Puzzle. I wrote some extra methods but haven't sent Richard patches since I've failed to make practical use of them yet due to having forgotten far too much maths. I did think at one point that I could attack it with group theory, but eventually realised that a group is not a group without an identity. Duh.
Now I know that Set's been around for long enough that other people are already going to have thrown maths at it, but I want to have a play on my own and see how far I can get.
Let the number of:
characteristics per card be c cards per set be n different values each characteristic can take be v
So for a standard Set deck we have c = 4, n = 3, v = 3
The size of the deck will then be v**c
(v
to the power of c
), since
the value of each characteristic is independent of the values of the others
- we have v
choices for the first characteristic, v
choices for
the second characteristic, etc, all the way to v
choices for the
c
th characteristic.
Here are some definitions I felt the need to invent and/or formalise. The terminology is complicated by the fact that the word "set" has been taken to describe something specific. So I'm going to use "collection" instead. A collection has no internal structure; the structured entities are going to be called decks and subdecks.
A card is a set of c
characteristics, each of which can take one
of v
values.
A collection of cards is one or more cards.
A subcollection F
of a collection E
is a collection of cards such
that every member of F
is also a member of E
.
The deck D
is a collection of cards such that every possible value
of every possible characteristic is held by at least one card in D
.
A Set is a collection of cards such that for each characteristic, either each card has the same value, or each card has a different value.
A completion of a collection E
of size c - 1
is any card
which when added to E
forms a Set.
A collection E
is complete if for each subcollection F
of
E
of size c - 1
, every completion of F
is also a member of
E
.
A subdeck is a complete subset of a deck.
A subdeck is proper if its size is smaller than the size of the deck.
So far I've just been playing with definitions and proving simple propositions, for example:
Sets cannot exist unless v >= n
.
For the case n = 2
, every collection of size n
is a Set, so
completions are not unique, and there are no proper subdecks.
This is fun.
I made a CGI::Wiki dev list.
I'd like to be able to make wikis where the author of a node can choose what wiki (or other) syntax to write in - using, for example, a drop-down box on the edit screen.
This will allow you to do things like have documentation pages written in POD, test suite pages written in plain text and rendered using a simple formatter class that just puts <pre> around everything, and discussion pages written in your favourite Wiki syntax.
Now this could be done in the calling code - just call $relevant_formatter->format( ... )
rather than $wiki->format(
... )
. But I'm wondering whether it should be explicitly supported
by CGI::Wiki, and if so, should this be done by changing the CGI::Wiki
API or by creating CGI::Wiki::Formatter::Multiple to handle it all.
The main tasks that a solution needs to accomplish are:
- when saving a node, store some metadata to indicate the required formatter
- when displaying a node, retrieve that metadata and use it to choose the appropriate formatter
Changing the CGI::Wiki API would mean that CGI::Wiki was mandating the behaviour of a particular metadata field, something it hasn't done up to now and I'm not sure it should do.
Handling it via CGI::Wiki::Formatter::Multiple would mean that the application code would be responsible for storing and retrieving the formatter-type metadata. The wins in this case over just handling all the multipleness in code would be:
- can just call $wiki->format
instead of selecting the right
formatter class, instantiating and calling that
- things like allowed_tags
only need to be supplied once, to CGI::Wiki::Formatter::Multiple->new
, rather than to each individual
formatter. (On the other hand, you might want to allow different
tags for the different types of pages.)
I'm also considering a grand renaming of CGI::Wiki, maybe to Wiki::Toolkit. We're discussing a major API change and a name change would help avoid the backwards compatibility demon.
OpenGuides 0.24 has escaped.
I've been exchanging some interesting emails about CGI::Wiki with
Jonathan Swartz. He pointed out that the API could really do with an
overhaul - in particular the way that ->retrieve_node
returns a
hash when it's absolutely begging to be an object. He is of course
completely right. The only reason the thing isn't an object is that I
was worried about backwards compatibility - this was in some stupidly
early version like 0.05 or something like that. Lesson learned - bite
the bullet and make incompatible changes when you need to, since it'll
be much much more painful six months later.
Anyway, a partial rewrite of CGI::Wiki is most appealing. I'd love to get it tidied up a bit. Jonathan has even offered to help! What a wonderful guy!
The sticking point is the tests. There's loads of them and I think
fairly decent coverage, but the test suite itself is an absolute rats'
nest. Some of the later test files depend on data having been added
in earlier-running ones, most of the test files have a big ugly loop
around them to run the tests on all available backends, and there's
the whole mess with the interactive Makefile.PL
and the persistence of
test database information (in CGI::Wiki::TestConfig) and the
data-eating possibilities resulting from that.
I'm sure that redoing the tests and the code at the same time would be a very bad idea, so I guess I need to rewrite the tests first. Not an appealing prospect, and not one that I'm sure I can hand off to anyone else, since it is such a mess.
I'm very interested in Module::TestConfig for cleaning up the
Makefile.PL
; it looks as though it'll let me delete a lot of code.
Plus I can get the separately-released plugins to use it for their
configuration and testing too, so you're not stuck with the
configuration you had last time you installed the main distro. I'm
concerned that this is going to mean another dependency though, and I
already get complaints about dependencies.
(I want a script that I can give the name of a module and optionaly a Perl version, and get a recursive list of its dependencies and their dependencies, with highlighting to show which modules are core in that Perl version.)
Bugfix for CGI::Wiki::Plugin::Locator::UK -
->find_within_distance
wasn't returning nodes with identical
co-ordinates to the one that we were finding things near to.
Look, it's gone all self-referential. Upgraded the RSS template for this site so now you only get the latest 10 entries, and you don't get my TODO list.
Fixed OpenGuides::Template so that OS co-ordinates entered into an edit form have whitespace trimmed before they're stored in the database, since postgres was choking on integerification of co-rds with trailing whitespace.
(No, I'm not sure why that code is in that particular package.)
Finished modularising OpenGuides::SuperSearch - well, as much of it as I can do without feedback from Ivor. The code could still do with a bit more refactoring, since it's all over the place, but my goal was to make it testable, and I've done that.
This is how you use it (yes, this is the entire CGI script):
use CGI; use Config::Tiny; use OpenGuides::SuperSearch; my $config = Config::Tiny->read( "wiki.conf" ); my $search = OpenGuides::SuperSearch->new( config => $config ); my %vars = CGI::Vars(); $search->run( vars => \%vars );
This is how you test the data retrieval:
my %tt_vars = $search->run( return_tt_vars => 1, vars => { search => "banana" }, ); is( $tt_vars{first_num}, 0, "first_num set to 0 when no hits" ); is( scalar @{ $tt_vars{results} }, 0, "...and results array empty" );
This is how you test the output produced by the module and the associated template:
my $output = $search->run( return_output => 1, vars => { search => "banana" }, ); like( $output, qr/no items matched/i, "outputs 'no items matched' if term not found"
I like this method; it feels clean. Better than what I did with CGI::Wiki::Kwiki, which was to capture the output by tying STDOUT to an IO::Scalar.
Released CGI::Wiki 0.47, which makes the ->list_recent_changes
method more powerful. Previously it could only filter on the metadata of
the current node versions, now it has metadata_was
and metadata_wasnt
,
which take into account metadata of previous versions. The most obvious
use for this is that now you can, for example, pick out all edits where
the edit_type
was "major", even when a node has had a more recent
minor edit, or all the nodes edited by me in the last week, even when bob
has come along and added some typos :)
This change was an absolute bitch, since I'm a fool and let the data manipulated by my test files get all intertwingled - and the solution is not so simple to just clear out the database at the start of each test file, since SQLite doesn't really like opening databases more than once.
While I was doing all this I found a bug or something in Search::InvertedIndex::DB::Pg, but I was already fed up so I quietly uninstalled it while I wasn't looking and am pretending I didn't see nuffing.
Have started tearing the search script of OpenGuides apart - I want to stick it in a module, make it have tests, make it more clearly coded. The impetus for this is that Ivor wrote it to use CGI to generate all the form stuff, and with the latest CGI release it's all gone screwy. He said he'd sort it out but that was over two weeks ago and I think it kinda needs doing so I made a start.
So the way to install into non-standard places has changed in Module::Build between 0.18 and 0.20, which led to some fun this morning.
First thing I didn't realise was that because it uses itself to install itself, I should have been looking in the documentation of the 0.20 that I was wanting to install, not the 0.18 that I already had installed.
The way to get it to install in /my/own/directory is to do
perl Build.PL install_path=lib=/my/own/directory
and then
./Build install
will do the right thing. I am writing this down now as I will never remember it. The exact invocation I use is
perl Build.PL install_path=lib=/home/kake/local/share/perl/5.6.1 install_path=arch=/home/kake/local/share/perl/5.6.1/auto/ install_path=libdoc=/home/kake/local/src/man install_path=bindoc=/home/kake/local/src/man install_path=script=/home/kake/local/bin/
Fixed up some stuff on CGI::Wiki::Kwiki - Tom has very generously made me co-maintainer so I uploaded 0.3. It's still not as featureful as I want it to be, but it's plenty good enough to use. The main thing missing now is diffs, and for that I need to rip out the diff stuff from OpenGuides and release it as CGI::Wiki::Plugin::Diffs.
Fixed some issues with SVG::Plot that Ronan Oger, the SVG
author, raised - the most interesting one is that now you can pass
options through to SVG by using the svg_options
parameter in the
SVG::Plot constructor. Richard suggested that this should have
been in the plot
method rather than the constructor, but given that
the existing design has everything in the constructor I thought it was
neater to add the new options there. If it is indeed bad design then
it needs fixing all at once, not confusingly bit by bit.
The find within distance function on OpenGuides London stopped working today. Eek! It was returning the error message:
DBD::Pg::st execute failed: ERROR: pg_atoi: error in "174448 ": can't parse " " at lib/CGI/Wiki/Plugin/Locator/UK.pm line 203.
Turns out that version 5 of the Heathrow Airport node had a trailing space in its OS Y co-ordinate, and postgres was choking on this when it tried to turn that entry into an integer for comparison with the supplied co-ordinates. (The metadata is all stored as varchar, since it's defined by the user of the module, and hence can be anything.)
Guess I need to add some post-processing on that field.
I actually did some user support at work today - one of our clients was having trouble uploading photos to our content management system and since there weren't any managers in and I was on phone duty, I got to sort it out. We got it working in the end, but not without a small amount of communication failure due to using different terminology for things. It wasn't an unpleasant experience at all, since the client was really nice and patient and seemed pretty smart too. But I've been thinking about it since, in particular small changes to the wording on the CMS interface that would make it easier to find out exactly what the user did to produce the results they're seeing - things as simple as writing "STEP 1: Do foo", "STEP 2: Do bar".
Normal (non-geek) people don't generally read out exactly what it says on the screen when you ask them what they did, or what happened. They paraphrase. If they clicked on a link that said "Confirm registration numbers", they might say "I checked the registration numbers". "STEP 1" and "STEP 2" aren't the kind of thing you paraphrase though. I think. Note that none of this speculation is properly tested.
Next time I design a user interface, I'm going to visualise how I'd talk a non-technical user through using it, over the phone.
That's not the kind of thing I usually write here, is it. I wonder if this is going to turn into a real blog.
Another release prompted by Shevek - CGI::Wiki 0.46.
Added node_suffix
and edit_suffix
options to
CGI::Wiki::Formatter::UseMod as requested by Shevek. So in 0.08
you can pretend your wiki is a regular website, with links like
http://example.com/wiki/MyNode.html
or
http://example.com/wiki/edit/NewNode.html
I keep completing things that I've been meaning to do for ages and then realising they weren't on my to-do list. That's my excuse for why my to-do list never gets any shorter, anyhow.
I got another mail from Jonathan Swartz asking about the use of
Class::Delegation with CGI::Wiki - apparently
Class::Delegation doesn't play too nicely with mod_perl
. I'd
been meaning for ages to get rid of this dependency, and Jon's mail
reminded me to get around to it.
I was very pleased when Richard first pointed me at Class::Delegation, because it seemed a very nice way to avoid having to write
sub method1 { my $self = shift; $self->attribute1->method1( @_ ); } sub method2 { my $self = shift; $self->attribute2->method2( @_ ); }
etc etc. (I'm not allowed to do that sort of thing in AUTOLOAD
because it makes Richard turn funny colours.)
It started getting on my nerves reasonably quickly though, because it
eats your attributes' methods' error messages and replaces them with
"Could not delegate <method>
". This is not very useful. No, I
never found time to look into it and find out if I could stop it doing
that. Bad programmer.
While I was taking it out, I found some slightly dodgy assumptions in some parts of the code that had previously been obscured by Class::Delegation papering over cracks. Lessons here:
1) Tests are wonderful. Tests are really wonderful. The CGI::Wiki tests are well worth the (maybe slightly excessive) length of time they take to run.
2) Sometimes nice syntactic sugar can make what's really going on less clear.
We'd lost the OpenGuides London mailing list archives when my drive died a while back. Yes, I still had the data. I just ran mariachi on an mbox and now the archives are back and shinier than before.
And here is the regular "cool things Richard told me about" spot. Today it's tramp, a thing that lets you edit remote files with emacs. It's like magic. All I had to do was
apt-get install tramp
start up xemacs, ask for the file
/[tazio]~/foo
type in my password, and right there I am editing a file on tazio from my desktop! It does tab-completion of filenames and everything. Wow.
Jonathan Swartz emailed me and offered to do some work on CGI::Wiki, to add the ability to put a prefix on the names of the database tables used. This will be pretty useful for people who can't go around creating databases left right and centre, and also quite handy for integrating wikiness into other applications. I like it when people offer to write my code for me!
Had a bit more of a think about what I want to do wiki-wise for london.food and wrote down a few thoughts - after having spent quite a few months turning this over in my mind I think it's coming together.
Tracked down a bug in Text::WikiFormat with the help of Sam Vilain (mugwump). The problem was triggered because an empty regex was being used to match paragraphs, and it turns out that perlop tells us:
If the PATTERN evaluates to the empty string, the last successfully matched regular expression is used instead.
So whenever the formatter was called in a situation where a match had previously succeeded, all paragraphs were getting silently eaten. Bug report and failing test sent to chromatic, and CGI::Wiki::Formatter::UseMod 0.07 released with an interim fix.
Released OpenGuides 0.22 with a number of minor tweaks and fixes that people had asked for - nothing hugely exciting. Very shortly after that happened, Ivor reported a bug with textareas that had been introduced in 0.21, so I wrote a test, fixed it, and uploaded 0.23.
Released CGI::Wiki::Formatter::UseMod 0.06, which uses the new features in Text::WikiFormat 0.7 to do nested lists.
Patched CGI::Wiki::Kwiki to have input fields for username, comment and edit type and to display these on Recent Changes. That was actually all it needed for me to be able to use it, so I set up a Wiki for the sewing/knitting circle some of us are organising.
Playing with CGI::Wiki::Kwiki today and noticed it doesn't work properly out of the box with CGI::Wiki::Formatter::UseMod, since the latter does sneaky URL munging for full UseMod compatibility - so you get URLs like
http://example.com/wiki.cgi?Mailing_List_Managers
rather than
http://example.com/wiki.cgi?Mailing%20List%20Managers
This is good for users, who get to see nice friendly URLs, but not so
good for programmers, because they need to be aware of the issue and
call the node_name_to_node_param
method where necessary.
I decided it was simpler to make the URL munging an optional extra in CGI::Wiki::Formatter::UseMod - this breaks backwards compatibility but I've been warning from the start that this module is really pretty alpha (it doesn't even do nested lists yet), so I decided it was OK.
Had to make a new release of OpenGuides because of this API change, but I'd wanted to anyway because of a couple of small changes that Earle and Ivor made.
Yet another cool thing that Richard showed me. When you make a
release, do cvs tag 'rel0_20'
(or whatever version it is), then
later on you can see all the changes since that release by using cvs
diff -r 'rel0_20'
. You can't use a .
in the tag, hence the
underscore. Oh, and put diff -u
in your ~/.cvsrc
for much more
useful cvs diff
output.
Finally got round to emailing Jerry about Search::InvertedIndex.
Start new job on Friday and haven't done half the things I intended to.
Tom's released CGI::Wiki::Kwiki - a wiki running on a CGI::Wiki backend. It looks pretty cool, though I'm sure the name is going to confuse people.
My article on how to avoid writing code is up on perl.com - I guess there must have been an emergency.
Added text formatting rules link to OpenGuides nav bar (turnable off with a preferences option) following a request from Mike Stevens. Also added config option for including navbar on front page. That's been bugging me for ages. Fixed some other niggly things that people have asked to get sorted.
Adding "edit_type" dropdown box to OpenGuides, found I needed to
have a metadata_isnt
to go with my metadata_is
constraint in
CGI::Wiki's ->list_recent_changes
method, so there goes 0.43
and then 0.44 cos 0.43 didn't actually work, along with OpenGuides
0.19. Then I had to go and upload OpenGuides 0.20 because I'd
forgotten to change the address of the dev mailing list. See how
quickly you get out of the swing of things. Hadn't actually intended
to spend the entire evening hacking. Oh well.
The July Perl Journal, which includes Building Collaborative Web Applications With CGI::Wiki, is now available. They changed my comedy section headings to sensible ones though.
And people wonder why I wanted a database backend for CGI::Wiki. Earle was wondering about finding orphaned OpenGuides pages - pages that aren't linked to, aren't in any categories or locales, and aren't redirects. So I thought for a minute or two and wrote some (admittedly ugly and can probably be improved) SQL:
select distinct node.name from node left join internal_links on node.name=internal_links.link_to where internal_links.link_from is null and node.name not in (select distinct node from metadata where node in (select distinct node.name from node left join internal_links on node.name=internal_links.link_to where internal_links.link_from is null ) and metadata_type in ('category', 'locale') ) and node.text not like '%REDIRECT%';
and that does the job.
Jody just announced on IRC that he's set up The Open Guide to Birmingham - no content yet but he'll be working on it. Hurrah!
Firefighting at work all day so somewhat disinclined to hack in the evening. The plan for the next week is roughly: rest brain over weekend, work like mad on final two work days (Monday and Tuesday), have well-earned break, dive back into open-source hacking from the following Monday. There's a hell of a lot to do, so much that I'm not even going to start adding it to my TODO list until then.
The Open Guide to London is online and running on OpenGuides. Wow.
There was a pub meet last night. Plans were hatched. One of them was that Mike Stevens is going to mentor me to learn Java. The other one was worse, but wasn't about programming.
I do wish I could remember what triggers _ListTables is
deprecated, use $dbh->tables() at /usr/lib/perl5/DBD/mysql.pm line
272.
I'm sure I've had this problem and solved it at least twice
before, but I didn't write it down, and Google is unhelpful.
It's probably got something to do with Class::DBI and/or
incompatible module versions.
Moved the Vegan Guide to Oxford fully over to OpenGuides. That's the second live OpenGuides install! (The other being the main Oxford one.)
Released CGI::Wiki::Plugin::Categoriser 0.02, now with somewhat shonky subcategory support.
Thanks to chromatic's swift and helpful reply, I got my head around part of the new Text::WikiFormat API and sent the lucky guy a proper failing test. Along with another item of confusion a little later.
So perl Build.PL config='sitelib=/home/kake/tmp'
doesn't work in
Module::Build 0.18_02 - which is admittedly a development version.
Shame I need to have that version installed in order to use the
create_makefile_pl
feature for OpenGuides.
I can't even work out how many levels deep I am in yak-shaving at the moment.
Laptop power supply busted again. Only one week of paid employment remains.
Note to self: when Class::DBI says something like add_to_artworks
needs data
then what it actually means is "give me a hashref, not a
hash".
I've been meaning for some time to compile a Class::DBI error message to English dictionary. That's the first entry.
Got something resembling a 0.02 release of CGI::Wiki::Plugin::Categoriser together. I still hate this module but I need it. I'll probably release it tomorrow.
Finally found time to look at chromatic's Text::WikiFormat changes. These changes should mean that nested lists work, which would be fabulous. I hit a snag in my understanding of the new interface though, so have mailed him a failing test to fix. :)
Richard was watching my tests fail with many lines of thing not matching a regex, and pointed me at Test::Differences, which looks very shiny indeed - and also his neat trick of using it optionally as seen here in one of the Mail::Thread tests.
Made a start at adding subcategories to CGI::Wiki::Plugin::Categoriser - but oh dear, it's all so horribly kludgey. I'm trying to stick with the wiki conventions of doing categories, yet trying to "do them properly" at the same time, and it just feels like a mess. I need them, though, to make the specialised food search for OpenGuides. Guess I'll just plug on with it; it's kind of an ugly module to start with anyhow.
Finished the article by dint of getting into the right mood and then spending half an hour on it. If only I could get into that mood on demand.
Minor faffing with OpenGuides and its install at http://openguides.org/london/index.cgi. The stylesheet is still busted though, and since Earle forgot to chown the directory I can't fix it in a non-kludgy way.
Got most of the article finished. Had a minor panic when I decided it wasn't interesting, went to the pub, talked to Robert Shiels, became re-enthused when he said he'd really like to read it. Hurrah. Will finish tomorrow then.
Accidentally promised to write Simon an emergency article about the potent combination of Class::DBI and Template. By Friday. Or possibly Thursday. Got a bit blocked at work and unexpectedly wrote about a quarter of it, though.
Learnt how to use a fax machine, in the process of sending signed contract and confusing "I'm not American" form to TPJ for the CGI::Wiki article I wrote them.
Sushi this evening, so perhaps not playing out tomorrow night.
A relatively unproductive day today because of hayfever, unreasonably hot weather, and busted laptop power supply (now fixed). The two things I released today were actually written yesterday.
Search::InvertedIndex::DB::Pg released.
Released a new version of CGI::Wiki - just a couple of small changes, one to remove the use of Test::Warn and one to make the test suite check if Search::InvertedIndex::DB::Pg is installed and run tests for it if it is.
I took Test::Warn out because I was hardly using it, and because I get moaned at for having lots of dependencies. Test::Warn was responsible for a fair number of my cascading dependencies. Now I know that the right answer to people finding it tedious to install modules is for them to use a tool that makes it not tedious, but if I get whined at enough then I tend to just give in.
Got OpenGuides working on the openguides.org server and copied the grubstreet data over to its new home. Hurrah! We'll run the two sites in parallel for a couple of weeks and then switch entirely to the new software.
Wrote a mostly-working PostgreSQL backend to Search::InvertedIndex. Just a small amount of DBD::Pg, BYTEA and null confusion to overcome, then mail Jerry and it should be all systems go.
Update: Confusion overcome thanks to a very helpful David Wheeler on IRC. Toby posted another solution to the london.pm mailing list later, but I haven't tested it yet.
Installed the dev version of Module::Build and used it to add a Makefile.PL to OpenGuides to keep mstevens (and CPAN.pm) happy.
I can backdate entries if I want to. Discovered Text::DoubleMetaphone, which works a hell of a lot better on my (real, discovered in the wild) misspelled artist names than either Text::Soundex or Text::Metaphone; though a simple remove vowels and collapse repeated letters picked up around half of them. The big win for Text::DoubleMetaphone over that simple approach is that it can figure out that, for example, "Nicolas" might be a misspelling of "Nicholas".
foo
HTML generated from pod with podblog