There ain't no commenting thing. Mail me at I like getting mail.


View current version link broken on

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). wiki/mail archive

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.

Friday 31 October 2003

I wrote code so you don't have to.

Tuesday 7 October 2003

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.

Thursday 25 September 2003 - Afternoon

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.

Thursday 25 September 2003 - Morning

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 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.

Wednesday 24 September 2003

Day off to visit friends.

Tuesday 23 September 2003 - Afternoon

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.

Tuesday 23 September 2003 - Morning

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.

Monday 22 September 2003 - Afternoon

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.

Monday 22 September 2003 - Morning

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.

Thursday 18 September 2003

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.

Sunday 13 September 2003

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 cth 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.

Wednesday 10 September 2003

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.

Older stuff...

Monday 8 September 2003
Sunday 7 September 2003
Wednesday 3 September 2003
Tuesday 2 September 2003
Saturday 30 August 2003 - Monday 1 September 2003
Friday 29 August 2003
Thursday 28 August 2003
Tuesday 26 August 2003
Tuesday 19 August 2003
Friday 15 August 2003
Thursday 14 August 2003
Monday 12 August 2003
Monday 11 August 2003
Thursday 7 August 2003
Wednesday 6 August 2003
Monday 4 August 2003
Friday 1 August 2003
Saturday 26 July 2003
Thursday 17 July 2003
Wednesday 16 July 2003
Thursday 10 July 2003
Tuesday 1 July 2003
Sunday 29 June 2003
Friday 27 June 2003
Thursday 26 June 2003
Wednesday 25 June 2003
Tuesday 24 June 2003
Monday 23 June 2003
Sunday 22 June 2003
Saturday 21 June 2003
Friday 20 June 2003
Thursday 19 June 2003
Tuesday 17 June 2003
Monday 16 June 2003
Sunday 15 June 2003
Friday 13 June 2003


HTML generated from pod with podblog