[Vienna-pm] Call for Votes: YAPC::Europe Hackathons

Thomas Klausner domm at cpan.org
Mon May 21 03:53:56 PDT 2007


Wie ihr vielleicht wisst, werden wir auf der YAPC::Europe 4 Hackathons 

Wir haben 6 Proposals von 5 Leuten bekommen und haben uns gedacht, es 
waere doch nett, wenn alle Vienna.pm-Mitglieder (bzw alle, die *jetzt* 
auf dieser Liste subskribiert sind) mit abstimmen wuerden, welche der 
Hackathons ausgesucht werden sollen. 

Also: Weiter unten folgt die Kurzzuebersicht und die Beschreibung 
(soweit vorhanden) der einzelnen Hackathons. JedeR kann 1, 2, 3 und 4 
Punkte vergeben. Die 4 Propsoals mit den meisten Punkten werden 
ausgewaehlt. Deadline fuer die Abstimmung ist DO, 24.5., 18:00 (CET)

Bitte die Votes in der Form: Titel -> Punkte an die Adresse 
    apw-orga at dmail.zsi.at
schicken, also 

i) Foo -> 4 Pkt
k) Baz -> 3 Pkt
m) Bar -> 2 Pkt
o) Fuu -> 1 Pkt

Und hier die "Kandidaten"!

Hackathon-Proposals fuer YAPC::Europe 2007


a) Perl6-in-Perl6 and Perl6-in-Perl5, Flavio S. Glock
b) DBI, DBD::Oracle, John Scoles
c) CPAN::Porters, Gabor Szabo
d) Adding Tests to CPAN Modules, Gabor Szabo
e) POE, Kidney Bingos
f) OpenGuides, Kake

a) Perl6-in-Perl6 and Perl6-in-Perl5
"Flavio S. Glock" <fglock at gmail.com>

I will be hosting the Perl6-in-Perl6 and Perl6-in-Perl5 hackathon in
YAPC::SA (SouthAmerica) in a few days.

It would nice for me if we could have a followup in Vienna.

b) DBI, DBD::Oracle
"John Scoles" <scoles at pythian.com>

I am interested the DBI, DBD::Oracle or perhaps CIG or even embedded C
with Perl.

I am currently the maintainer of DBD::Oracle and have worked closely with
Tim Bunce and other in the DBI community.

c) CPAN::Porters
Gabor Szabo" <szabgab at gmail.com>

This is a new project I have starter to work on. The objective is to 
increase the number of CPAN modules available as standard packages in 
the various Linux (BSD and other) distributions.  I have started to 
create some stats http://www.szabgab.com/distributions/ and started to 
write some documents. By the time of the hackathon there should be 
already several CPAN modules available in Debian that I am maintaining.  
During the hackathon I would like to get more people involved and not 
only on Debian but for the other major distros as well.  Maintaining 
such distros requires lots of manual administrative work but there is 
plenty of opportunities to create automations.  One of the sub-projects 
is to make use of the dependency table created by CPANTS and maybe add 
some more code to CPANTS to collect some more information we need. (even 
if that does not directly contribute to the kwalitee factor of the 

d) Adding Tests to CPAN Modules
Gabor Szabo" <szabgab at gmail.com>

Testing, that would be picking up several modules
(probably from Phalanx http://qa.perl.org./phalanx/ but I am not sure yet)
and starting to add tests to them. Tests initially might be released in
CPAN::Test::Others but once the module author agrees they should go
into the module itself.

e) POE
Kidney Bingos <chris at bingosnet.co.uk>


POE is a framework for cooperative, event driven multitasking in Perl.

It lends itself to a mulitude of different applications and purposes 
including, but not limited to:

- networking servers and clients;
- network monitoring;
- integration with existing event loops such as Glib, Event, Gtk, Tk, etc;

A hackathon would be an opportunity for POE developers to: gather, 
discuss and exchange tips, tricks and best practises; work on long 
delayed POE related modules; provide advice and support to newer and 
novice POE users.

I unfortunately can't say at this point what kind of hacking will be 
done. I intend to poll Rocco Caputo and the other POE developers 
regarding possible things to be done. Also participents on the day would 
probably have their own ideas.

Regarding the short introduction, I intend to produce enough material to 
cover hopefully a diverse audience, which can be tailored on the day 
given the attending persons.

About me:

I have been involved with POE development for a number of years now, 
including authoring and maintaining a large number of POE Components ( 
http://search.cpan.org/~bingos/ ) and using POE for work and public 
based projects. As well as that I have made a number of contributions to 
the POE code base.

f) OpenGuides

OpenGuides is a complete wiki-based application for running a website 
about some subject where geographical location is important. The most 
popular use at the moment is as a platform for a guide to a city - 
London, Oxford, Vienna, and Boston are among the major cities covered. 
The project has been running for over four years now, and has a small 
core team of programmers as well as a close-knit community of other 
interested parties including contributors to the various guides.

The content of an OpenGuides website is managed by the Wiki::Toolkit 
suite of modules, and stored in your choice of SQLite, MySQL, or 
Postgres.  OpenGuides itself provides structure and a UI layer on top of 
this.  OpenGuides and Wiki::Toolkit are both written in Perl, and are 
available on CPAN.

One of the major advantages of Openguides over other wiki software is 
its use of structured data, allowing complex queries such as "find me 
all the real ale pubs within 500m of King's Cross station which serve 
food at lunchtime" [0]. Most search results can be viewed either as a 
list or on a map, using the Google maps API [1].

[0] http://preview.tinyurl.com/22jlzu
[1] http://preview.tinyurl.com/2rxqt8

We have many, many tasks which could be addressed at a hackfest, 
depending on the skills and interests of the participants. These 

- authentication
  Currently we use the traditional "wiki way" of not requiring any 
  authentication at all; usernames are simply stored in a preference 
  cookie by the user's browser. We'd like to add authentication as an 
  option; OpenID is one possible way of going about this.

- making it easier to extend the core OpenGuides package
  Many guide admins have written add-ons to supplement the capabilities 
  of the OpenGuides distribution; some of these can be folded back into 
  the core, while others only make sense for particular 
  guides/cities/countries. Making it easier to write these extensions 
  not only makes it more likely that people will hack on things that can 
  eventually go into the core, it also makes it easier for people to 
  create local extensions without having to fork the codebase. This task 
  can be broken down into a number of possible subtasks, for example:
  - modularising our javascript snippets into libraries
  - creating an SQL query builder
  - refactoring the structured data handlers to allow customisation of the
    structured data fields
  - creating a template framework to allow a consistent look and feel
    between core OpenGuides and local extensions

- "good enough" internationalisation
  OpenGuides' HTML is output by means of the Template Toolkit; we 
  distribute the templates along with the Perl modules. Currently, these 
  templates are all in English, and people wanting to run guides in 
  different languages have to translate and maintain their own set of 
  templates. All I'm thinking of at this stage is a way to let us 
  distribute templates in multiple languages without significant 
  repetition of presentation logic.  

- improving the full-text search
  The text search is handled at the Wiki::Toolkit level; the content of 
  a page is tokenised and indexed when a page is saved. We need better 
  canonicalisation of these tokens to allow fuzzy matching (to catch 
  misspellings) and to make sure that punctuation is irrelevant in 
  searching (e.g. King's Cross vs.  Kings Cross).

- page deletion
  Page deletion is irreversible at the moment, which is not a good 
  thing.  What we need to do is add "deletion" in at the Wiki::Toolkit 
  level, by marking "deleted" pages/page versions as non-visible, and 
  then making sure they don't get returned by queries unless 
  specifically asked for.  

- JSON output / API
  We've always been very keen to allow data-sharing between OpenGuides 
  and other applications. We have RDF output, but this isn't hugely 
  programmer-friendly due to the amount of faff needed to actually get 
  out usable information. Other, more programer-friendly outputs would 
  be great; JSON might be a useful starting point.

- non-Perl tasks
  Obviously this is a Perl-based conference and a Perl-based hackathon, 
  but there are a number of other tasks which could be done by people 
  who're interested in OpenGuides but don't feel comfortable diving 
  straight into the code - or indeed non-Perl partners; I'll be 
  providing one of these :) Non-Perl tasks include: template 
  translation, user testing, writing documentation, coming up with new 
  example designs/stylesheets.

-------------------- END OF PROPOSALS ----------------------

#!/usr/bin/perl                              http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

More information about the Vienna-pm mailing list