blogs.perl.org

The Perl Testing Workshop at YAPC::NA 2012, taught by Gabor, will be in Room 226 of the Pyle Center. We thought you might like a look at the room before the workshop. The workshop will be held for the 2 days before the conference (June 11 & 12).

So, I've been awfully quiet lately. There are a number of reasons for that, not the least of which is being the proud parent of a delightful little girl. Another reason has been simple: I'm writing a book.

A couple weeks ago I posted this introduction to DCI. I received a lot of feedback. Primarily I was told that I did not explain DCI concisely enough. In addition I received feedback that showed me I completely failed to convey the point of DCI. DCI does not replace OOP, it augments it and makes it easier to maintain.

After reviewing all feedback, and corresponding with many of those who provided it, I have written a new document. This document attempt to use simple language, to put DCI as simply as possible. Unfortunately the logical leap to grasping DCI is at least as large as the logical leap from Imperative to OOP, and cannot be consistently conveyed in a simple paragraph (at least not with my writing skills.)

In trying to learn 5.10 grammar-like regex features and wrote a program that, while matching simple Lisp-like constructs, builds up a data structure. This involves recursing into subpatterns, but I couldn't find a way to assemble the resulting tree from the bottom up. Therefore I used a stack.

Do you know of a better way of building the data structure with the given regex/grammar?

(I'm aware of Parse::RecDescent and Regexp::Grammars, but wanted to do this as simply as possible.)

I’d like to wish all of our sponsors a very Merry Christmas. Without you YAPC::NA 2012 wouldn’t be possible. And because of you, YAPC::NA 2012 is shaping up to be an absolutely amazing event. 

tl;dr version: The design of require makes it all but impossible to use in a secure and correct fashion. To fix this, Perl needs two new ops: one which will only load files, and one which will only load modules. Both would only load from @INC.

The more I look into the problem, the more I'm convinced that there is no good way to load a module from a variable in Perl. None of the existing techniques or modules fully solve the problem. They all have security holes or limitations. This is kind of embarrassing, it's an easy thing and it should be easy. My investigation into how many ways the simple act of loading a module can go wrong has lead me to believe that the solution is a new op which just loads modules.

For those of you wondering, near as I can tell this is how you correctly and securely load a module from a variable...

To build a package, use Module::Install, ya turkey!

Update: Per mstpan, one should not use Module::Install!

cpan Module::Install

Make a directory for your package to reside:

mkdir /home/you/My-Package

Put your module in the 'lib' directory. This is where all your code is going to live.

mkdir lib
mkdir My
touch My/Package.pm

Put your code in My/Package.pm, or copy the file you already wrote here.

Then, create a Makefile.PL in /home/you/My-Package:

Method::Signatures::Simple: Nice, very simple, and almost as fast as pure perl, is this module ready for use in modules you depend on?

This is a shot of the Epsilon Sigma Phi Conference Room, which will be available June 11th & 12th before (the 2 days before YAPC::NA 2012) for the Hackathon. 

Inspired by a recent blog post on patching cpanminus, I decided to spend a few minutes patching cpanm for a small itch I have: sometimes I want to download distribution tarballs only without building/installing. This patch adds a --download command to do just that.

To try it out for yourself:

$ git clone git://github.com/sharyanto/cpanminus.git
$ cd cpanminus
$ script/build.PL
$ perl Makefile.PL && make install
$ cpanm --download CGI Data::FormValidator

As some of you may have heard, Perl had been registered as a trademark by somebody other than TPF or any Perl related entity. Last year as soon as we realized that this had been done, we contacted some lawyers and TPF, and immediately filed a complaint.

We had been told that this whole process would take about a year, and finally I'm happy to announce that this decision has been reversed, and the above mentioned trademark has been revoked (I'm not a lawyer type, so excuse me if my words of choice there are not technically correct).

This was a joint effort by Japan Perl Association and Yet Another Society/The Perl Foundation, with a little bit of help by a hacker who shall remain anonymous, just in case. I'm happy that we were able to work this through.

That leaves the actual petition by TPF/YAS for the true trademark for Perl in Japan, but that's a whole different story. For now, I'm happy we're free to use Perl without worry.

The other day I was wondering about $? in Perl and the shell and how exit statuses work. I did some digging and now I'd like to talk a bit about exit statuses at the OS level and how Perl and the shell deal with it.

First off, there are two ways a unix process can terminate. One is by calling _exit, the other is getting killed by a signal. In both cases the resources of the process (such as memory or file descriptors) are cleaned up. All that remains is an entry in the process table (i.e. the PID is still taken) and some status information on how the process died. This "stale" process table entry is called a zombie process.

After a process has terminated, it's its parent's job to clean up after it by calling wait or simply exiting itself (a process whose parent has died is known as an orphan process; it will be adopted and cleaned up by init, the process with id 1).

We have a special treat for you today, a title unification match. In the corner to my right, haling from mysql.com, the undisputed world leader in users - MySQL! In the corner to my left, hailing from postgresql.org, the undisputed world leader in geek credibility - Postgres!

At YAPC::NA 2012 we will once and for all declare a winner in the RDBMS wars. Winner take all. Loser stripped of it’s title and goes home with it’s tail between it’s legs!

I've been messing around with Objective-C off and on for a while now. Whenever I take a break and come back to it, I find myself having to look up some of the same syntax over and over. Some examples would be:

$foo =~ s{bar}{baz}g;

foo = [foo stringByReplacingOccurrencesOfString:@"bar" withString:@"baz"];

$list{'foo'} = 'baz';

[list setObject:baz forKey:@"foo"];

For the past several years, I'd been set on YAML as the format for configuration file. It's human-readable, pretty, portable, and support arbitrary data structures. But for future projects, I'm planning to use INI format. Why?

First of all, YAML is "too complex" for users. There are subtle syntaxes, like the requirement for list separator character (,) or the mapping character (:) to be followed by space. And then there are object literals like Yes/No/true/false, ~, date/time, etc. And the various ways to do heredocs. It would take at the very least an hour to explain the syntax to first timers, and days to familiarize with it.

Second, and this is more important for me, there are no round-trip parsers/emitters for YAML. You can't modify data without reformatting the whole file and removing all comments.

Infinity Interactive is a New York based, multi-discipline consultancy that serves global organizations with local attention.  We build simple websites, infrastructure for multi-national corporations and everything in between.  Our strengths are our relationships with our partner companies and our focus on quality.

We are committed to open source software and are very active in the Perl community.  Therefore we are proud to sponsor YAPC::NA 2012!

Here's my definitive guide to creating a Perl package (non-OO) for retards.

I always wanted to write about Perl but never got the time to do. Recently came across to some of Neil Bowers published blogs which gave me the necessary push to write something useful. I feel honored to have worked with Neil Bowers in the past.

For the last 6 years or so I never got the opportunity to do any kind of web development. Although I kept in touch with all the web related stuff that is happening in the Perl e.g. Catalyst, Dancer, Moose. Also during my web development period, I never used any kind of MVC, ORM but these days everyone wants all these. So cut the long story short, I created the web app using the traditional perl-cgi-dbi logic, which as expected they didn't seem to approve it.

I've added a new article to my software-development / testing blog, called: Agile Scrum: Delivering Broken Software Since 1991 - looks at how Scrum can get subverted, and how to fix it. Enjoy!