Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pshangov (3074)

pshangov
  (email not shown publicly)
http://mechanicalrevolution.com/

Journal of pshangov (3074)

Tuesday August 18, 2009
03:42 PM

Book Wishlist: Mastering CPAN

Cross-posted from http://mechanicalrevolution.com/.

I have been thinking recently that it would be so cool if there were a Mastering CPAN book, both for CPAN users and for CPAN authors. The best way to get the job done with CPAN is sometimes just so non-obvious. Such a book would be useful both for newcomers who still feel intimidated by CPAN as well as for more experienced users looking to learn some neat advanced techniques. A sample Table of Contents may look like this:

Part I: Using CPAN

  • Basics - what is CPAN, who hosts it, who contributes to it, etc.
  • Finding stuff on CPAN
  • Installing stuff from CPAN, CPAN.pm and CPANPLUS.pm, other shells, manual installation, PPM packages and repositories, .deb and .rpm packages, ActiveState Perl vs Strawberry Perl, compiling modules on Win32 with AS Perl and Visual Studio Express, understanding the overwhelming output of the cpan shell and figuring out which messages are important, failed tests and forced installs
  • Structure of a CPAN distribution, info you can find in META.yml, finding usage examples in the tests directory
  • Reporting bugs and finding support for a module
  • Creating your local minicpan, running a webserver for pod documentation
  • Advanced commands in the cpan shell, creating bundles for all of your installed modules, other local maintenance tasks
  • Other useful tools and websites: cpan testers, cpan dependencies, annocpan, cpanhq, diff and grep on search.cpan.org

Part II: Authoring CPAN Modules

  • The stuff from “Writing Perl Modules for CPAN” that is still relevant
  • EE::MM, Module::Build and Module::Install, including advanced options
  • Basic info on writing tests, testing modules on Win32 via the Microsoft Open Source Network CPAN Author Lab, cpantesters
  • Distribution management and upload tools
  • Basic techniques to write code that works with older versions of perl
Tuesday August 11, 2009
09:36 AM

Data::AsObject Released - Data Structures Made Easy

Cross-posted from http://mechanicalrevolution.com/.

Perl is notorious for its punctuation-ridden syntax, and if there is one place where this is manifested most obviously, it is when working with data structures. While I myself can see the beauty behind the line noise and have nothing against the syntax per se, it sometimes feels there are just too many characters to type. In particular, I have recently had to do a lot of work with XML data represented by perl hashes, via XML::TreePP and XML::Compile. Working with the data structures generated by these modules can quickly become pretty painful.

Enter Data::AsObject. It allows you to work with hash and array references as if they were objects. For example, I often have to process XLIFF files, which are used in the translation industry. Using XML::Compile, I can get my XLIFF files serialized into a hash and use it as follows (you don't need to know the details of the XLIFF format to see the point of the example):

$xliff holds the serialized xml
# get the source language of the first file
my $source_lang = $xliff->{'seq_any'}->[0]->{'file'}->{'source-language'};

# get all the translation units in the first file
my @trans_units = @{ $xliff->{'seq_any'}->[0]->{'file'}->{'body'}->{'cho_group'}->[0]->{'trans-unit'} };

# for each translation unit, add an alternative translation with a source and a target
foreach my $tu (@trans_units) {
    my @matches = get_matches($source->textContent);

    my $id = 0;
    foreach my $match (@matches) {
        $tu->{'cho_context-group'}->[$id]->{'alt-trans'}->{'source'}->{'_'} = $match->source;
        $tu->{'cho_context-group'}->[$id]->{'alt-trans'}->{'target'}->{'_'} = $match->target;
        $id++;
    }
}

The same example with Data::AsObject (for this to work, hooks need to be added to XML::Compile to automatically convert “source-language”, “trans-unit” and other elements with dashes to “source_language”, “trans_unit” etc.):

# Data::AsObject::dao converts a hashref or an arrayref to a
# Data::AsObject::Hash or a Data::AsObject::Array object
dao $xliff;

my $source_lang = $xliff->seq_any(0)->file->source_language;
my @trans_units = $xliff->seq_any(0)->file->body->cho_group(0)->trans_unit;

foreach my $tu (@trans_units) {
    my @matches = get_matches($source->textContent);

    my $id = 0;
    foreach my $match (@matches) {
        $tu->cho_context_group($id)->alt_trans->source->{'_'} = $match->source;
        $tu->cho_context_group($id)->alt_trans->target->{'_'} = $match->target;
        $id++;
    }
}

This an almost real life example and you can easily see what benefits in terms of readability Data::AsObject provides. Of course there are many caveats, the primary one being that you need to be able to control your input and guarantee that hash keys will only contain alphanumeric characters and underscores. Go check out the docs for more usage details.

Monday August 10, 2009
05:35 AM

Why I Stick with Perl

Cross-posted from http://mechanicalrevolution.com/.

This is the obligatory general-purpose evangelism piece that every perl hacker ends up writing sooner or later in his or her journalling career. Mine comes as only the second article in this blog, and is dedicated to what has recently become an increasingly controversial aspect of the perl culture – the dreaded There Is More Than One Way To Do It design philosophy. This article suffers from an abundance of generalizations, but too many details would have made it unbearably long to read. A more useful discussion may ensue in the comments.

Many argue that TIMTOWTDI is the curse of perl. It confuses beginners, increases the learning curve, makes it difficult for companies to enforce programming standards, makes it difficult to establish criteria for evaluating job candidates, etc. These arguments are by all means true. But for me, having programmed in a number of languages, TIMTOWTDI has emerged as probably the number one reason why I persist in preferring perl to anything else on the market.

A great example of TIMTOWTDI in action is Catalyst. I recently spent several months learning it and developing a relatively complex application. It was indeed very frustrating at the beginning. Catalyst supports a bazillion configuration formats and different parts of the documentation provide examples with different formats, and it is not always straightforward to translate from one format to the other. I had a tough time figuring out which form generation and validation library to start learning, since I had never used one before (Which one has the functions I need? Which one is best integrated with Catalyst? Which one has the best documentation?). Trying to understand the multiple ways in which access control can be implemented made my had spin. And so on, you get the idea.

But at the end of my learning experience I was happy. Having grasped the fundamentals of Catalyst I knew I could use any templating system I needed, plug in any storage model I needed, and generally deal with any circumstances whether planned by the Catalyst authors or not. I felt exhilarated and brimming with power. I felt like Popeye the sailor after eating his spinach. I felt I could rule the world.

I have done serious web programming in two other languages besides perl – C# and PHP. Late last year I joined a team working on a large web portal written in C# and .NET, and I had the chance to learn learn the .NET web programming patterns. In .NET there is generally one way and one way only to do things – which is sometimes good, and sometimes it sucks big time. I won't go into detail, but you don't feel powerful doing web applications in C#. You feel trapped.

With PHP, on the other hand, you have a proliferation of frameworks and tools, but the overwhelming majority of them have their own view of the universe and usually come with their own stack of tools developed by the framework creators and designed to be used with this particular framework exclusively. Diversity seems to come at the price of constant reinvention of the wheel. You end up feeling you could rule the world, but you'll have to use a different type of army for each individual country, and some countries will probably not surrender at all, and also things tend to get pretty messy with the larger countries, and in the end it is just too much work to bother so why don't you just give up your global domination plans altogether.

The bottom line is, perl powerful because it tends to provide a level of abstraction that you just do not get in other languages. Perl itself, as well as perl's frameworks and tools, have been designed from the very start to accommodate diversity and deal with the unexpected. The perl module author is trained to make very few assumptions about how you are going to use her code and leaves a lot of room for choices. And the knowledge that I can make choices gives me a warm fuzzy feeling and lets me sleep well at night. Choice creates competition and competition creates evolution. I may be a strange bird, but I love the fact that I can choose what object-oriented programming framework to use. I find it comforting to know that I can choose what regular expression engine I want to use – even though I would probably never do that. I am grateful to be able to work in an environment that inherently acknowledges that each solution is imperfect and the least imperfect solution tends to be different for each individual problem.

Friday August 07, 2009
02:50 AM

A New Perl Blog

Cross-posted from http://mechanicalrevolution.com/.

This is the first post in yet another new blog to join the Perl blogosphere. My name is Peter, I am from Bulgaria, and my technological inclinations seem to have been determined by a memorable childhood camel-riding experience (my family was relatively poor and precious stones are not something I am used to; also, I never really managed to get comfortable with snakes). Although I first started programming in Perl nearly 10 years ago, it was only in the past year that I evolved from an anonymous and passive consumer of Perl code and culture to a point where I released my first cpan modules, started sending bug reports and patches for other people's modules, and joined an exciting community project. Now the hacker in me is feeling a new urge – to speak and be heard!

While readers of this blog will be entertained with musings on tech stuff of any nature, the predominant theme is going to be Perl. Some of the topics that I want to talk about are Perl documentation and where it can be improved, my favourite but under-appreciated cpan modules, my personal Perl projects (stay tuned for some some cool stuff!), and, of course, my own takes on Perl evangelism. I will be joining The Iron Man Challenge, and the first five items on this blog will also be cross-posted on use.perl.org.

The name of this blog reflects my passionate belief that technology empowers the individual to influence the world and change it for the better. I think this is true more then ever at this specific point in time when technology has become so accessible and powerful that it has made it possible, like never before in history, for individuals and small groups to spread their ideas and influence to thousands and even millions of people, all over the world.

Enjoy!

Credits:

This blog is hosted on my brand new Hostgator account (I will post a review of Hostgator as a Perl hosting solution once I've had some experience with it). The theme – Byty the Free Child (which I fell in love with after seeing it on David Golden's blog), was designed by Cristian Antohe, initially for Wordpress. The content management system powering the blog is something I have been working on for a while and will soon be released to the public. The comment system is managed by Disqus.