Giacomo Vacca

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...

... and you never dared asking. Enjoy .

The first time I needed to have some kind of complex select statement, I started to pray about the ability to use regular expressions with mysql. Easy as it may be: use REGEXP ! For example: SELECT * FROM db.ip_addresses WHERE ip_address REGEXP '^192\.168\.0\.(133|135)$'; See the official documentation and details here .

If you like me are annoyed by the "recording" feature on vim (or better, by the way you can accidentally start it), then you may find at least useful to learn how it can be actually used. This post explains it .