Data::Printer - a colored pretty printer for Perl

Wait, stop. Is this Yet Another Data::Dumper?

Well, yes and no. Data::Dumper (and friends) are meant to stringify data structures in a way that makes them still suitable for being eval'ed back in. That's really awesome, but poses a huge constraint over pretty-printers. Earlier this year, brian d foy talked about the amazing powers of Data::Dump, but it still suffers from those constraints. Same goes for the (also great) Data::Dump::Streamer.

Here's a quick visual comparison between the ever popular Data::Dumper and the new Data::Printer:



First thing you'll notice is the colored output, indexed arrays and a little extra regex information. But Data::Printer offers much more than that. How about debugging objects?



And what if your data is attached to others?



The idea behind Data::Printer is that most developers (at least to my experience) use such tools mostly just to see what's going on inside their variables and objects, not to serialize data in and out of Perl. So I decided to make a module that would focus on that: display Perl variables and objects on screen, properly formatted (to be inspected by a human). Data::Printer is somewhat similar to Ruby's "awesome_print", but I made sure to include more customization options and some neat features present in Perl's data dumpers.

For example, I called the printer function "p()" as it's nice and short and should steer clear of name collisions. But if you're so used to calling "Dumper()" in your code it just comes out naturally while you type, you can try this:

  use Data::Printer alias => 'Dumper';

  Dumper( %foo );  # there, problem solved!

Data::Printer comes with (I hope!) very sane defaults, so usually all you have to do is "use Data::Printer" (or even shorter: "use DDP") and start peeking at data structures with the exported "p()" function. But pretty is a matter of personal taste, and from colors to array indexes to the hash separator and their default values, you can customize just about anything!


Sounds neat, but I'm not gonna type all that every time!

And you shouldn't - which is why Data::Printer looks for a file called .dataprinter in your home directory and lets you keep all your preferred settings right there, so you only have to worry about it once :-)


Filters

There are times when you don't really wish to see an entire object's internals during your review, just that important piece of information that you're holding in it. Data::Printer also offers you the ability to easily add filters to override any kind of data display:

  use Data::Printer filters => {
     'DateTime'      => sub { $_[0]->ymd },
     'HTTP::Request' => sub { $_[0]->uri },
  };

If your filters are too complex you can create them as a separate module and load them by name. You can even upload them to CPAN so others can benefit from it! In fact, Data::Printer already ships with some (hopefully useful) filters for the whole DateTime family of modules (not just DateTime, but also Time::Piece and friends), and some Database ones as well (currently DBI and DBIx::Class):



You can also make your classes Data::Printer-aware simply by adding a _data_printer() function to them. You don't have to add Data::Printer as a dependency at all, and it will use that function to filter your class by default instead of doing a regular dump.


In Short...

If you want to serialize/store/restore Perl data structures, this module will NOT help you, and you should try other solutions such as the Dumper/Dump family, Storable, JSON, or whatever you can find on CPAN.

But if you only care about seeing what's going on inside your data structures and objects, give Data::Printer a try! Oh, and if you're into REPLs, you can add it as your default dumper for Devel::REPL too =)

Code is on github. Comments, feature requests, bug reports and patches are welcome!

The *REAL* Perl Ironmen =)

Last Saturday (May 7) there was a huge Perl event in Brazil - the São Paulo Perl Workshop! It was a full-day conference with several awesome talks, featuring brilliant international keynotes like brian d foy, Brad Fitzpatrick and Larry Wall himself! The workshop also contained some of our local talent like Eden Cardim, Thiago Rondon and Solli Honório, and even talks from W3C and brazilian companies relying on Perl for their core businesses. We had around 100 attendants, making this one of the largest Perl events in the world!

But here's where it really heats up: We were on the Rio Perl Mongers mailing list, calmly discussing how to get to São Paulo for the workshop - you know, renting a bus, getting on the same flight, that sort of thing - when Diogo suggested we use other, less convenient, means of transportation.

Bicycles.

Now, for those of you that are unfamiliar with Brazil, here's a little geography lesson. It's the 5th largest country in the world, and although in adjacent States, the distance from Rio to São Paulo is over 480km (298.3 miles), most of it UPHILL. It beats NYC to Washington DC by 150km (93 miles), Tokyo to Kyoto by 110km (68 miles), and London to Paris by over 140km (87 miles)! Of course, being a mailing list of mostly brazilian people, we all knew that already. So when Diogo tossed in the air such an absurd idea, bearing on the clinically insane, there was only one thing we could do.

We said "Hell, yeah!!"

There were 4 of us in total for the adventure: MDA on the "safety car", Marcio, Diogo and myself riding the bikes. Marcio is actually from São Paulo, and would come to Rio by plane with his bike only so he could ride with us!

Plan and Preparations

A friend of mine is actually a professional trainer for a big team here in Rio, and agreed to help us get into shape and plan for the ride - granted, her wording was more in the line of "I'll do my best to help you not die", after a few minutes of screaming about how crazy we were. We only had two weeks(!!) to prepare so we'd need all the help we could get. Thanks coach!

Once we started taking it really serious and got our feet back on the ground, we realized there were some problems with the journey. Thing is, even at an extremely generous 25km/h rate (did I mention most of the way is uphill?) we'd still take over 20 hours straight to reach São Paulo. That's at least two days, and unlikely to happen. Getting the friday off was not that big a deal, but there was little chance we'd all be excused for thursday too. So we decided to cycle from 7am until it got dark, at which point we'd get in the safety car and finish the travel. After all, we had a Workshop to attend ;-)


Surely, nothing can go wrong! Oh, wait...


Marcio missed his flight, and had to travel by bus to Rio overnight. MDA faced a lot of traffic jams and we could only reach Marcio at the bus station by 9am. Then Marcio found out his bike's fork broke during the travel, and we had to find a place to quickly fix or replace it. With all that trouble, it was only 2pm when we finally hit the road!

On the highway, we started pedaling on the side of the road, and found out the hard way there were a lot of places with no "side of the road" at all! Whenever we found such places we had to get back in the car and wait until it was safe again. It was a nuisance, but no one had a death wish.

It was really scary to ride next to giant trucks and speeding cars, and to see several pieces of tire torn off from trucks on the way.

At some point we even had to quickly move to the "side of the side of the road" - whatever that means - to avoid being hit by a car traveling against the traffic, on our lane!!


Conclusion

It was a 4 hour ride and, albeit exhausted, we had a lot of fun! It was a nice opportunity to exercise outdoors, see some great sights and even raise awareness of the local IT community to the Workshop and to Perl itself - there was a lot of joking around because "camel" in portuguese is also a slang for bicycles =)

As a reward, we got the chance to be in a great workshop with fellow Perl hackers. Now who knows, maybe this november for the YAPC in Rio we'll travel back from São Paulo ;-)

Oh, and if you're interested in more pics of the journey and the conference itself, here they are :)

Catalyst in the Cloud

A lot of buzz was generated recently in the Perl community after DotCloud, a big PaaS player, introduced its brand new Perl stack, letting developers deploy modern Perl web applications into the "Cloud" without having to worry about the underlying system at all.

DotCloud already provides a nice Dancer example, and sri was diligent enough to provide a Mojolicious example as soon as he got his hands on an account. So when I got my own invitation to the service, I wondered how Catalyst would stand to the challenge.

After going through the whole thing in just a couple of minutes, all I can say is that:

If you were ever scared or concerned of using Catalyst due to its dependencies and how hard it would be to deploy... you're out of excuses =)


So, without further ado, here's the Catalyst DotCloud deploy process!

Install the "dotcloud" app in your local machine:

$ sudo apt-get install python-setuptools
$ sudo easy_install dotcloud

Create a DotCloud namespace (I called it "catalyst")

$ dotcloud create catalyst

Deploy a Perl stack into that namespace:

$ dotcloud deploy -t perl catalyst.www

Create a sample Catalyst app (skip if you already have one) and enter its directory:

$ catalyst.pl CatalystCloud
$ cd CatalystCloud

DotCloud uses the "static" dir for static files, so let's create a symbolic link there for Catalyst's root/static, or wherever else you placed your static files. There are probably other ways to customize this with DotCloud's standard configuration and its nginx server, but I just joined and haven't fiddled with any docs yet :)

$ ln -s root/static static

Add PSGI support for your Catalyst app. We could try the built-in FastCGI run script, but the recommended way is PSGI. To do that, simply install Catalyst::Engine::PSGI and create the new helper for your app, naming it "app.psgi" in your app's base directory:

$ cpan Catalyst::Engine::PSGI (or cpanm, or whatever you like)
$ script/catalystcloud_create.pl PSGI
$ ln -s script/catalystcloud.psgi app.psgi

The "app.psgi" file needs to know how to find your app, so add a use lib 'lib'; statement to it, right after "use warnings". The final file should look something like this (replacing "CatalystCloud" with your app's name, of course):

#!/usr/bin/env perl
use strict;
use warnings;
use lib 'lib';
use CatalystCloud;
CatalystCloud->setup_engine('PSGI');
my $app = sub { CatalystCloud->run(@_) };

Remember to add the new dependency to your app's Makefile.PL, so DotCloud knows what's required when it deploys:

requires 'Catalyst::Engine::PSGI';

Your application is ready; let's push it to DotCloud:

$ dotcloud push catalyst.www .

Now sit back and watch as DotCloud smoothly walks through all of Catalyst's dependencies and deploys your app to the Web. Sweet!



Once you start working on your application, remember to keep your Makefile.PL up-to-date, adding any and all dependencies to it (like Catalyst::View::TT and Catalyst::Model::DBIC::Schema). But you already do that, don't you?

If you run into trouble, give "dotcloud logs catalyst.www" a try (again, replacing the catalyst.www namespace with your app's) and browse through you application's logs in real time. If you left the -Debug flag on, you can even see Catalyst's messages on the fly.

Many thanks are in order to the ever-awesome Miyagawa and the whole DotCloud team for making deploying Perl applications such a breeze =)

Have fun!!

The SDL Perl Game Contest!

Sure, you know what SDL is, right? Well, SDL has very nice Perl bindings that let you use the power and flexibility of Perl to write awesome games in no time!

There's even a manual to help you get started, including full game tutorials and a list of free/open-source resources for your games, like sprites, sound effects and music.

But by far the Coolest Game Ever™ is the one *you* write, from that silly idea you had the other day to a playable game you and your friends can enjoy.

And this march, the SDL Perl team is going to help you take that project out of your dusty drawer of "TODO"s and turn it into a reality, with the SDL Perl Game Contest!

The rules are simple, and much like the Perl Ironman contest:

"One game per week. Every week of march."

This means by the end of march you'll have not one, but FOUR games to show for. How cool is that?!

In fact, you can even make your weekly game the subject of your Ironman posts this month, and take out two birds with one stone (hmm... more game ideas)!

This monday (feb. 28), start writing your game! You have until the following monday to make it playable ("complete") and start all over again with a brand new game for the next week.

But what if I miss a deadline? What if I can't start this monday?

It doesn't really matter - just join the party and have some fun! Even if you only get to do one game, it's still a great opportunity to improve your skills and learn a bit about game design and development.

If you need any assistance writing your game, from ideas to code, WE WILL HELP! Just send an email to the SDL Perl mailing list with your questions (subscribe by sending an empty email to sdl-devel-subscribe@perl.org, then fire your questions to sdl-devel@perl.org) or, better yet, join us live in #sdl over at irc.perl.org and we'll be more than happy to assist you and try your game out. If you never used irc before, please keep in mind people might be busy or in different timezones than you, so you may get instant responses or have to wait a few of hours before you get a reply. Be patient!

It can be a game about anything. Just make sure it's doable in a week. Some games take years to be complete, but you might be surprised at how much you can accomplish in just a few hours with SDL Perl :)

Oh, there's one extra rule, actually, and that's mandatory - HAVE FUN!! :)

Teaching Perl to Undergraduates

Perl is an amazing programming language. And, with its growing worldwide re-popularization, it was an easy sell to the Computer Science Department of the Federal University of Rio de Janeiro, one of the best and most famous universities in Brazil, when I offered to give a free Perl summer class to the undergrads.

The idea was to give students the opportunity to learn a new language, presenting the concepts, structure, best practices and design patterns of modern Perl 5. It was also my response to seeing so many companies here complaining about the lack of Perl developers, forcing them to use other languages even when Perl would be the best alternative for them.

And what a huge success it was!

The course was given by Bruno Buss and myself, with me doing the talk and him preparing and giving exercises to the students and helping them with their code. At first we were hoping to get about 10 students interested, specially since we didn't have time to advertise the summer class at all. In fact, due to uncontrollable events, we could only confirm it and open registration two weeks before the class itself started. Even so, we decided to carry on with it. Later that night I got a message from Buss: "we're gonna need a bigger room".

Turns out that in less than 24 hours we already had over 25 undergrad students registered for the course! We kept registration open as a waiting list, since we couldn't find an available lab with more than 25 PCs in such a short timeframe. A day before the beginning of the class there were over 50 students applying for a spot, even though they already knew the class was full!

And this is Perl competing against student vacations, during summer, in Rio.

The course was one week long, from 1pm to 5pm (yes, we had to compensate $dayjob during nighttime, but it was well worth it). Slides for all 5 days are available. It's mostly Perl, with a little Portuguese here and there like variable names, values and complementary information whenever necessary. Here's what we covered:

• Day 1 (slides) - What's Perl all about; how to use perldoc; the modern and safe header (use 5.12.3; use warnings); basic I/O; scalar variables; manipulating numbers and strings; conditionals; loops; and file I/O, with autodie to capture exceptions. We also spoke about the Perl community, showed off a bit of Padre, the Perl IDE, and encouraged students to use chromatic's brilliant "Modern Perl" book as reference material.
  

• Day 2 (slides) - Running external programs; arrays (and how to manipulate them); hashes (and how to manipulate them); scalar x list x void context. That, and lots of exercises to fixate what they learned so far.
  

• Day 3 (slides) - References; building complex data structures; functions (subroutines); stack traces with Carp and Carp::Always; and retrieving command line arguments with Getopt::Long. While explaining anonymous subs we also mentioned/demonstrated closures and state variables, but didn't really get into it as it was a beginners class. The day ended with an explanation of Perl's sweetheart, the CPAN. We showed students not only how to install modules (with local::lib), but included an explanation of the full CPAN stack, including web search, CPAN Testers, Deps, Ratings and Bug/Request Tracking. We also discussed how to exploit those features (and other common tips) to pick a good module (and, of course, Task::Kensho).

• Day 4 (slides) - Regular expessions; how to create modules and export functions; and more CPAN goodies, including Capture::Tiny to properly retrieve the output of external programs (and pretty much everything else); Try::Tiny to capture exceptions; DateTime to handle, well, dates and times; Path::Class to manipulate files and dirs; Config::Any and Log::Log4perl.

• Day 5 (slides) - Plain old documentation; writing tests; Perl Critic; Perl Tidy; Object Orientation (Moose only, including meta - I only mentioned bless as a curiosity, while explaining what happens under the hood); databases (nothing fancy, just plain DBI with a strong encouragement towards ORMs like DBIx::Class, Rose::DB::ObjectFey::ORM); Web Crawling with WWW::Mechanize and Mojo::Client; and Web development with Mojolicious::Lite, while also heavily encouraging them to try out Catalyst in their own time.

Students were mostly from Computer Science, with around 6 of them being from Biology/Biophysics/Bioinformatics, and one or two from Electric Engineering and Applied Mathematics. In the end, there were 27 undergrads. Yes, 27. It was very rewarding to see 2 booted students showing up anyway, with their laptops, asking if they could sit on the back and participate. Of course they could :)