Giacomo Vacca

When I’ve found Inside-Out Objects not only mentioned but suggested inside Perl Best Practices (see "Always Use Fully Encapsulated Objects" section) I thought: “Cool, here’s a solution to enforce encapsulation on Perl classes. This was badly needed”. But then, the list of advantages wasn’t too exciting, while the drawbacks were quite scary… See for example this analysis . To simplify the problem, note that all I want is: “a mechanism to prevent an object attribute to be read or changed from outside the object”. In Java, C++, PHP, you just declare that class attribute as private . Simple. (Python has a form of “privatization by obfuscation” that I don’t really like, but it may be better than what Perl does – which is nothing). Perl (5) is not a full OO programming language, just a procedural language that has got some additions to allow for OO dynamics, but still I'm surprised I can't "protect" object attributes... Getting back to Inside-Out Objects, t...

There are so many articles on how to generate test reports on Hudson for perl modules or applications, that I thought it was somehow complicated. It's not. The underlying problem is that Hudson has support for test results in JUnit format. To solve this you need to convert from TAP to JUnit the test results. Of course there are some pre-requirement: Your perl code must have tests (duh) You must have Hudson set up to run those tests You need to install TAP::Harness::JUnit on the building box You need to install ' prove ' on the building box Then all you have to do is add this command in the shell script you execute to run the tests: prove --harness=TAP::Harness::JUnit and configure the "Publish JUnit Test Result Reports" section of your project to point to the resulting XML file. No mumbo jumbo . Since TAP::Harness::JUnit is not available as a debian package, if you need to install it properly, just follow the usual procedure to generate debian packages from CPA...

If you are not interested in the full post, the concept of it is: “What are the 500 books that are worth reading before I die?” What do you recommend? Here’s the full post: I’m a keen reader since I was a child, and I’ve recently become an enthusiastic user of Kindle . Infinite (well, I know they are finite, but allow me this mathematically inconsistent emphasis) opportunities have suddenly become available: I can have thousands of books on my Kindle in seconds. Kindle books cost less their paper version, and often are even free (what’s slightly concerning is how easily you can buy a Kindle book: you just click on a button and your Amazon account is charged automatically - that’s why I set up a password to lock the device). Anyway the point of this post is about decisions: what to read. Let’s start with estimating how much I can read in my life, to give more sense on what follows. I need about one month to read a technical book of 400-500 pages, about two weeks to read an in...

Almost a year ago I attended " Literature and Freedom : Writers in Conversation ", a discussion hosted by Tate Modern which presented among the others Tahar Ben Jelloun . Now I wish I took more notes during that discussion, but this afternoon I found one - I'd rather write it here before losing even that piece of paper: Behind every work of fiction lies a tragedy. It's probably something you may easily believe reading "This blinding absence of light", which definitely impressed me this Spring, and I faced like a long work of poetry rather than a novel. Here's a review from The Guardian .

perlcritic is "a static source code analysis engine", a CPAN module which can also be used as a command . An example: $ perlcritic -severity 3 src/AModule.pm Subroutine does not end with "return" at line 24, column 1. See page 197 of PBP. (Severity: 4) Return value of eval not tested. at line 32, column 5. You can't depend upon the value of $@/$EVAL_ERROR to tell whether an eval failed.. (Severity: 3) As you can see you can get extremely useful information about the sanity of your code and how much it complies to good coding practices. There are 5 different severity levels (being 5 the "less critic"). Most Policy modules are based on Damian Conway's book Perl Best Practices ( PBP ), but it's not limited to it. I run perlcritic (using typically severity 3) automatically on all the source code files, every time I run the unit tests and/or build a package, in order to get as soon as possible a valuable feedback after code changes. Since the ...

Merging hashes with Perl is extremely easy: you can just "list" them. For example try this: use strict; use warnings; use Data::Dumper; my %hash1 = ('car' => 'FIAT', 'phone' => 'Nokia'); my %hash2 = ('laptop' => 'Dell', 'provider' => 'Orange'); my %mergedHash = (%hash1, %hash2); print "hash1: " . Dumper(\%hash1); print "hash2: " . Dumper(\%hash2); print "merged hash: " . Dumper(\%mergedHash); You'll see that %mergedHash contains the result of merging the two hashes. This is the simplest but not most efficient way to do it: here Perl Cookbook presents a different method , which uses less memory - interesting if you're merging big hashes (and have memory constraints). Now the tricky bit is that you can have this merge even when maybe you don't expect it... For example add this code to the previous lines: useHashes(%hash1, %hash2); sub useHashes { my(%hashInp...

It took me more than expected (and in fact someone found it for me) to explain why a file installed by a debian package and not listed inside debian/conffiles was handled as a standard configuration file. The file is installed in a subdirectory of /etc/, so intuitively you may assume it must be considered as a configuration file, although this wasn't clearly stated in a document until I read this from Debian New Maintainer's Guide , chapter 5: Since debhelper V3, dh_installdeb(1) will automatically flag any files under the /etc directory as conffiles, so if your program only has conffiles there you do not need to specify them in this file. For most package types, the only place there is (and should be conffiles) is under /etc and so this file doesn't need to exist. The conclusion is that if you install a file in a subfolder of /etc/, you don't need to list it inside debian/conffiles.

This is a concept that I've always found interesting. This evening I recalled it and found a blog article with other classifications of order of ignorance. This is the version I already knew: 0OI: I have Zeroth Order Ignorance (0OI) when I know something and can demonstrate my lack of ignorance in some tangible form, such as by building a system that satisfies the user. 1OI: Lack of Knowledge. I have First Order Ignorance (1OI) when I don’t know something and I can readily identify that fact. 2OI: Lack of Awareness. I have Second Order Ignorance (2OI) when I don’t know that I don’t know something. That is to say, not only am I ignorant of something (I have 1OI), I am unaware of that fact. 3OI: Lack of Process. I have Third Order Ignorance (3OI) when I don’t know of a suitably efficient way to find out that I don’t know that I don’t know something. So I am unable to resolve my 2OI. In my words: Level 0 : I know the problem and I can solve it because I've already done it before. ...

Many of us had courses, attended lectures and speeches on programming. Many of us read (even many) programming books, and regularly read articles and blogs about programming. Have you ever thought of what should have been the first thing to learn in programming? The usual "variables, operators, data structures, classes, templates, metaprogramming, ..." or something else? I've come to the conclusion that the most important thing, the first thing to learn, the one that if you're not familiar with you shouldn't even keep studying programming, is the answer to this question: "How can I verify my code works?" . If I was a teacher, right before writing my name on the blackboard (yes, this is how I like it to imagine it), I'd write this: "How can I verify my code works?". And I'll spend the entire lesson waiting for someone to come up with a reasonable solution. If nobody goes close to it, I'd assign it as an essay for the following lesson...

Time ago I wrote something about debianizing a perl module . If you're not applying it to a tar downloaded from CPAN or in general a third party module, but on your own module, then you may find it useful to build the module's dir structure using module-starter (installed with libmodule-starter-perl). The CPAN page for module-starter contains a simple description on how to use it and this post has interesting comments on even easier ways to achieve the same result (using dzil for example). In summary this is what you need to do: $ module-starter --module=My::AModule --author="Giacomo Vacca" --email="giacomo.vacca@email.email" --builder=Module::Install Inside the created dir (My-AModule): $ perl Makefile.PL $ make $ make test (I'm not running make install on purpose) Outside of My-AModule: $ dh-make-perl My-AModule/ (builds the debian dir using the current configuration) Inside My-AModule: $ debuild or $ debuild -us -uc if you don't want to sign ...

The good news is that building a debian package from the source of a CPAN module is easy, thanks to the dh-make-perl tool. The bad news is that the configuration of dh-make-perl can lead to the generation of a debian package containing unneeded files, and as a collateral effect preventing package installation as the files belong to more than one package. For example you can end up with something like: dpkg: error processing /var/cache/apt/archives/scnlibpoe-filter-stomp-perl_0.01_all.deb (--unpack): trying to overwrite `/usr/lib/perl/5.8/perllocal.pod', which is also in package scnlibpoe-component-client-stomp-perl Somebody suggests a change in the configuration file used by dh-make-perl . The same result can be achieved by applying this change to your debian/rules file: --- debian/rules (revision 32211) +++ debian/rules (working copy) @@ -51,8 +51,11 @@ - rmdir --ignore-fail-on-non-empty --parents $(TMP)/usr/lib/perl5 + rm -rfv $(TMP)/usr/lib

The goal is to make my life easier when the same package may go to different distributions. This is not useful per se, but it becomes so when you use custom distributions names to distinguish separate product branches. Let's assume you have an application app , which has different flavours, for example alpha and beta . You may want to have two separate debian repos for app , one called alpha and one called beta . Hosts within environment A may refer to the alpha repo, while hosts in another environment, let's say environment B, may want to refer to the beta repo. This keeps the small or big differences in app isolated. Now, assume app reaches a point when the only difference between A and B is the distribution name, so you can have the same version for the alpha and beta repo: how can you avoid building the package twice? Is there a way to make both repos happy? These are the questions that led me to the need of having a local debian repo , to experiment a little on this to...