[Perl blog] YAPC Day 2

Well aren't I psyched, because I've gotten the oomph to follow day 1 with day 2. Ha, we'll see about day 3 tomorrow.

Today I pretty much followed the databases track, with a detour at the beginning for 1.5 hours of perl 6 and Pugs. I'm quite impressed with how the perl 6 projects are coming along, though, as Eric/fishbot just told me, he was excited to see how the specs for Grammars have changed since he last looked at them. Now, I'll be excited to learn them when the design is finalized, and I'm excited for neat design development happening, but I'm not a language designer so I'll leave those discussions for those who are competent at such things.

In the database track, I saw a total of 4 Class::DBI talks of various sorts; I'm not convinced it's as useful as some claim, but I'm not actually warned away by the equally strong warnings I've heard from other smart people. Class::DBI seems just right for projects that can deal with a simple model. I suppose the first time I hit a wall with it, it'll be clear where the limitations are. But it seems it can handle many-to-many relationships, the thing I was most concerned about.

I need to look at Shawn Sorichetti's weblog, which will have interesting notes about IMA::DBI, and also I should track down the wiki for Class::DBI.

Casey West's talk about advanced Class::DBI included a number of modules to look at; which will shorten the amount of code you write, even further.

• Database-specific extensions: there are subclasses of Class::DBI for each of the major DBDs; each has a 'set_up_table' method which will semi-automatically create the tables you need, at compile time (for better and worse).


• Automatic Class creation: Class::DBI::Loader has a method 'find_class' to shorten class-creation code...


• Automatic Relationships: Class::DBI::Loader::Relationships will set up simple cases of relationships. Also, Loader has a 'relationships' flag to look into.



• Globally Unique Keys: ::Loader has parameter for 'additional_classes => [qw [Class::DBI::UUID]] whih uses/adds UUID field for able; it's DB independent and creates 16-character string UUIDs.


• Automatic XML Serialization: Class::DBI::AsXML (I think this was written by Casey): has 'to_xml_columns' method which will dump XML definitions for your data (non-recursively, I think; it might need more work)


• Automatic CGI Input: Class::DBI::FromCGI : the name is a misnomer; it can be used for many things besides CGI inputs. It will allow you to define columns/form-entries to untaint (as per type; you can specify integer, printable, etc... Pseudocode:

  use CGI::Untaint;
  # create handler
  my $h = CGI::Untaint->new(CGI->new->Vars):
  my $a = $camoose->create_from_cgi($h);

  
  
  Class::DBI::AsForm creates populated or empty form.

Advice: Don't: write a Class::DBI subclass; that namespace is already too populated. Don't reinvent classes already on CPAN.

Do: write a Class::DBI mixin; use exporting to provide your plugin; and use Class::DBI internals.

I need to read up in the docs, and possibly ask Casey what he meant for the last two Do's.

Dan Friedman's talk on Class::DBI::DataMigration describes a framework for basically building a better database programatically, but mostly just requiring a YAML config file that will do the translations. Which certainly sounds easy.

As for non-Class::DBI talks: I enjoyed the Yahoo tlak on high-volume databases and the high-availability talk which suggests corporate appropriateness for MySQL (hm...). Finally, I got a little bit of graph theory schoolin' with Walt Makowski's talk on Graph Theory and one instance when to use trees instead of sets to describe data so it can be combined more quickly.

Gotta go run and catch a boat-cruise. :)

[edit: back. Boy that was a long auction. Why did I think it would feel shorter if it were on a 4-hour boat-cruise? The conversations were excellent, though.]

[Perl blog] YAPC Day 1

A review of YAPC day 1.

Larry Wall's keynote was quite high-level and syncretic. He enthused about tensegrity, the engineering design principle that opposing forces properly balanced can provide tension and integrity at the same time. The talk was based on one he was invited to give in Russia, on how to build an open-source community.

Allison Randal's "state of the carrot" was a snapshot of where perl 5 and perl 6 design are right now. I didn't take notes, but there were some perl6 milestones released the day before, and everything seems to be progressing. PUGs has 80% of perl6 features, wow. [edit: This should be corrected to <30% or 10% (based on fraction of design that has test cases to cover it; see Autrijus's note below!)]

When we all split up, I started off in the "Enterprise Workflow" talk by Jim Brandt, which described how he and his group at the U of Buffalo used a few modules to save their University lots of time and money. The modules were: Class::DBI, Data::FormValidator, and CGI::Prototype. I've not actually done coding with Class::DBI, though I've read about it. Some people seem to dislike it intensely, for any sort of difficult projects, because it creates as much work as it saves. But for simple database lookups and manipulation, it seems like a timesaver.

Then, becasue we were running late and I was hungry, I ducked out and got lunch instead of going to the second talk...

For the afternoon, I took the easiest route and went for the session on Kwiki with Brian Ingerson.
I probably would've decided differently if all of the talks weren't being recorded, but as it is, the other talks looked more formal and his looked more freeform. Sure enough, he started off by saying he was going to one-up Autrijus who wrote the first half of a talk on the train to the client's site, then wrote the second half during the intermission.

Ingy's talk had the first half written last night at 4am, and the second half was going to be written by us.

Sure enough, the first half he presented slides on the architecture of his freeform wiki.

The thing is entirely plugins based, and has interesting abilities to make plugins interact and do the Right Thing with the least amount of code. He invented a number of techniques from scratch, he says because he's too lazy to research how other people have done things. TIMTOWTDI, right? Yeah. The plan is for the design to be a lego set for perl hackers.

Stuff he wrote that he thinks is cool: 'spiffy': a source-filter that adds 'use warnings' and 'strict' and a trailing '1' to each package file, and 'my $self=shift' to each method (this is turned on if you 'use Spiffy qw( -Base )'. -base won't include those. mixins: anonymous class between base-class and current class. like in Ruby. allows for a simple inheritence chain. Allows you to wedge stuff to replace or enhance methods which were either defined or inherited from a parent-class. And, he wrote a program registry, which is shared between plugins, and has some funky interactions which make sense but I didn't write down how it works, sorry.

He decided, when the plugin modules started exploding in number (there are well over 100 now by over 10 main authors), that CPAN wasn't the optimal way to release, since dependencies and versions make things slow to install. Instead, he recommends checking out his svn.kwiki.org.

Interesting feature: 'kwiki -view [blah]' will create a new kwiki named blah, with its own configuration files, but whose data and metadata are symbolicly linked from the parent directory. So it's easy to set up an admin view with extra features.

Brian's not terribly excited by wikis; they were just a means to playing with these new ideas. Spiffy has universal improvements. Spoon is generic techniques that seem interesting outside Kwiki. and Kwiki is built on Spoon.

Spiffy has a function named 'xxx' which will die at that point and do a stack-trace and some sort of variable dump.

I asked about documentation, which is... sparse... and how one is to start learning this when everything is tied together so intimately. He pointed me at doolittle.kwiki.org, which is a wiki which incorporates all of the POD stripped from the live version; (and I believe, checks the POD back into the SVN for the files) when he releases to CPAN, he does a once-over of doolittle and it gets released along with. So the docs are written by the community. In theory. I haven't taken a look at it yet...

The second half was organized around a pair-programming session with him and Chris Dent, where they built a plugin to do tags, like Delicious. It seemed pretty straight-forward, though, I would have loved to have asked more questions about the bugs they worked through. However, I did learn a bunch about debugging kwiki.

Afterward, I met up with other kw.pm mongers, and agreed we'd meet at Simon's house later for beer and chat, and possibly coding.

I was going to precede that with an RT (request-tracker) BOF, which would've been useful for work, but they left before I could get myself sorted out. I'll have to meet Jesse Vincent later on. So instead, I rode around on a segway for a little bit.

So that was my afternoon. Listening to other peoples' afternoons, I'm glad I went for less-structured. Maybe I'll do the perl6 track on Tuesday. Dunno.

In the evening, Simon, Eric and I set up our laptops and started hacking on Bots and Kwiki. Shuchit, Arguile and Greg came a bit later, and we had really good pizza.

We saw a few Futurama episodes (including the Popplers one, yay) and took the train back.