I don't hate everything

So inspired by both this post by moritz and the awesome Regexp::Grammars module on CPAN, I created a Perl 5.10 version of the perl 6 code (also using GraphViz::Data::Grapher).  There are a few differences, such as naming the top rule, the '' element that Regexp::Grammars creates, and the output format which comes from GraphViz::Data::Grapher (I am outputting to png since GraphViz's as_svg [well dot's SVG output, technically] outputs the wrong size for the outer svg tag).

So I am subscribed to a number of Perl-related blogs and aggregators, but when a large Perl web application with an impressive list of users gets updated, I only find out from Freshmeat and Planet Mozilla.

Perhaps if it was developed with Moose or using Catalyst?

Ok, so I was looking to integrate some perl scripts into my IRC client, which happens to be EPIC, version 4, as EPIC5 seems to be trying to be the Perl6 of the text-mode IRC clients, and I'm not quite there yet (irssi, meanwhile is the Ruby of text-mode IRC clients).  So I was looking for the correct syntax for the perlcall(6) function, (as opposed to the perl(6) and perlxcall(6) functions), and I get this from /HELP 6 perlcall:

*** Help on perlcall

and that was it.  Looking at /usr/local/share/epic/6_Functions/ for perlcall I see it is 0 bytes long.  And so I look and there are 81 files like that.  Shurely Shome mishtake right?  Apparently not, asking in #epic I get informed that I should use the wiki, because 'it makes it a lot easier for us to give you correct/updated information'.  Pathetic, really.  Why can't the documentation be in source control and shipped with the source code?  The online help pages that they have (which aren't categorized, its just a flat dump) could be generated from the text files instead.  But oh no, we need a Wiki for documentation, and must have an internet connection just to read documentation, ugh.  EPIC devs use Unix, right, they aren't hacking the source on their iPhones or Palms. right?

Now, ironically, I will need the perl*call documentation to write a reader of the Wiki documentation so I can use it in EPIC (maybe).  Lovely.  More on that later.

PHP SDK for Windows Azure

So, of course, to show its commitment to open-source, Microsoft has released PHP APIs for Windows Azure.  I'm not sure I understand the love Microsoft has for PHP, but I could be snarky and say the PHP philosophy fits in neatly with Microsoft's languages philosophy. 

Anyway, as much as I wish Microsoft would introduce Perl APIs for Azure, I do not hold out much hope, and instead see this as an opportunity for enterprising Perl coders to outdo the official APIs and increase the number of problem domains where Perl is a possible solution.  The API seems to be mostly HTTP and XML with some extensions (it is Microsoft, after all).  If after completing the other 700 items in my todo list, this is still undone, I'll get right on it.

Also worth noting, re: Azure, is FastCGI support, a definite plus for Perl developers.

So, in summary, Web Apps, REST/XML and FastCGI.  A near perfect fit for Perl, so how did we get to where PHP is the default, first choice language for this? 

Ugh.

So as part of this 'Modern Perl' push, I was looking at KiokuDB for persistence. 

I went through the KiokuDB::Tutorial and kept wondering why the DBI backend did it the way it did: Objects encoded into JSPON blobs, stored in a single field in an 'entries' table, with "indexing" in a separate table. 

I could understand that that probably works well for the BerkeleyDB backend, but putting relational data into a single, essentially unindexable (doing a JOIN from another table with 'index' data doesn't count) blob field is something you really shouldn't be doing in an RDBMS.  Basically it moves data validation and management out of the database where it belongs and into the application (A very Rails-ish way of doing things, and that is a bad thing), and making reporting or other analysis of the data impossible without the additional overhead of a Javascript/JSON library.

So while reading I thought of several alternatives that I would have used instead, mostly PostgreSQL-specific (since that is where I live):

• Using PL/Perl and JSON::Any to create a set of functions for inspecting the JSPON data, which could then provide real indexing with PostgreSQL's functional indexes and make reporting possible without too much overhead on the client;
• Storing the data in XML in an XML field and using PostgreSQL's XML/XPath functions for indexing/reporting on the data;
• Creating a custom type for each persisted class and creating a separate table for each class containing an ID field and a field of that specific type;

Upon thinking of the last one on the list, I realised that since CREATE TABLE actually creates a custom type in PostgeSQL, skipping the whole custom type dance, and just creating a database table for each persisted class would work and be the ideal solution.  Have a mapping between Moose types and SQL types, create references with foreign keys, provide real indexes on single and multivalued types and enable easy integration with other tools for data reporting and analysis.

Sadly, I doubt that Kioku's DBI backend will change at this stage, so I will probably have to write it myself, and will probably remain PostgreSQL-specific for a while.  That is, if I find myself with the need for KiokuDB-level persistence (I usually go from database to code, not the other way round).

Welcome to my new 'blog.  Read the description for what it is about, Basically I was inspired to create this because of the Perl Iron Man 'competition', so this will mostly, but not exclusively, be about Perl.  Here are a couple of lists:

Perl stuff I like:

• Moose
• AnyEvent
• Coro
• DBI (and DBIx::Class)
  
• Catalyst
  
• mod_perl
  
• Gtk2
• PDL

Honourable mention has to go to Term::VT102 which makes me want to go and write Gtk2 + Goo::Canvas frontends for everything in /usr/games

Perl stuff I am ambivalent/generally positive about:

• Moose; Moose has apparently been production ready since 0.65 but perhaps they should have waited for 1.0 for the deprecations and new features and incompatibilities to be worked out (I am not a fan of release early, release often)
  
• MooseX; some of MooseX radically changes Perl syntax (MooseX::Declare, I'm looking at you), for little real benefit
  
• Perl6; it seems to have gone too far to not be Perl 5 ('twigils'? and the string concatenation operator is what?), though I do like Parrot
  

Perl stuff I actively dislike or hate:

• POE; oh POE, initially you appeared so beautiful and so full of promise, but it turns out you were rotten and twisted inside and I had to leave you
• wxPerl (and its parent, wxWidgets); I don't understand the attraction of this (Padre, I'm looking at you), Tk and Gtk2 can both run cross platform (even on Windows) and have better event loops that even support file handle events
• META.yml; YuckAML