With most of my government hackery now finished, I find myself with a free timeslice for the first time in a while.
I plan to use the time to rewrite my CPAN Top 100 website from statically generated to being dynamically generated.
The main reason for this is that I want to start generating priority and ranking lists for individual authors or, say, the entire dependency tree of Padre in the same way I currently do for the entire CPAN. The underlying theme of the Top100 is around prioritising maintenance, but the toolchain seems to drown out the rest of the modules, by virtue of being needed for everything.
Having written my geo2gov.com.au website in Catalyst (to force myself to finally learn it) I'd like to also take a look at some of the new lightweight toolkits.
This is mainly because the Top100 database (and the CPANDB database it is based on) is available as an ORLite model. And tying a light weight ORM to a light weight web framework seems like a natural fit.
The two that seem to stand out as having sufficiently good project managers who understand the need to build communities around their code are Dancer and Mojolicious.
Since neither of the two looks like it particularly outshines the other on face value, my plan is build the new Top100 website simultaneously in both of them.
At some point during the process (hopefully near the end) I will declare a winner. The code for the loser will be discarded, and the code for the winner will go on to power the final production top100.cpan.org site.
The main judging criteria will be based on simplicity, legibility, and how amenable they are to collective maintenance.
To help evaluate the last criteria accurately, and to spice up the competition rules a bit, I'm going to be building both versions of the site in an open commit environment.
I will be keeping the code for both implementations in my open repository at http://svn.ali.as/ and I will be giving commit access to the authors of both Dancer and Mojolicious (and anyone else they nominate).
I see many "competitions" (especially in benchmarking) where the person running the competition writes all the code as well (badly) and ends up falsely judging certain entries. And I don't want that in this case.
While I will try to create the initial functionality for each new page or section of the site, both teams are allowed to refactor or improve anything as they see fit so that the code represents what they see as best showcasing their toolkits.
HOWEVER, teams take certain risks in "improving" my newbie code.
Any collective maintenance policy requires that experienced developers try to keep their code understandable for newbies. This keeps the pool of talent both wide and deep, while preventing newbies from accidentally breaking code too complex for them to understand.
So if the team-contributed changes to show off their toolkits in their respective websites makes it harder for me as a newbie to maintain my code, then they will be judged down accordingly.
In a similar spirit of newbie and small site friendliness, I will be developing the application on Windows without access to a web server, and deploying it onto a remote Linux server running Apache.
If building the application requires dependencies or external changes add features that don't work in both of these scenarios, they will be penalised.
As in real life, I won't be laying out precise scoring methods in advance.
After each chunk of work, I will assess and comment on my experiences, and assign points for that stage of the work (while trying to remain fair about weighting each task appropriately).
If you have your own web micro-framework you would like to include in the competition as well, you are welcome to petition for inclusion in the comments below.
However, be warned that to qualify for inclusion you must demonstrate sufficiently robust project management and community involvement. If you have a low bus-sensitivity(1) score, or are not sufficiently mature yet to make me think you are a viable long-term choice for my site (5 years or more) you won't make the grade for entry.
So let the fight begin!
Next post, creating the initial application skeletons!
(1) Bus Sensitivity is the number of people that would need to be hit by a bus for your project to effectively collapse.
dance(); vs shagadelic();, but I know there has to be more to it