/var/log/giacomo.log

It's not that hard to manage expectations (with Perl)

2011-03-05T19:25:00.004Z

Developers with a background in Ruby on Rails and PHP are familiar with the concepts of mocking objects and setting expectations on them.

The good news is that these powerful techniques for unit testing are available for Perl as well. Should I add you can find them on CPAN?

Before an example though, just a simple explanation about the topic.

Unit testing “is a method by which individual units of source code are tested to determine if they are fit for use” (Wikipedia). It’s a common practice to perform unit testing in isolation; in other words you focus testing on the source code, limiting as much as possible the interaction across modules or systems.

It’s almost always practically impossible to test a class without instantiating other classes on which it depends or interacts. What can be done is mocking objects: creating “empty objects” that emulate the external behaviour of real objects. They must be able to “fool” the class under test and allow the creation of an exhaustive set of tests around it.

Since the class under tests “expects” the other classes to do something, here comes the term expectation: the unit test expects that the class under test uses the mock object by calling a specific method, optionally in a specific order and optionally with specific arguments and return values.

An example with PHPUnit, where the class under test Person depends on a class Company, which is mocked:

$company = $this->getMock(‘Company’);
$person = new Person();
$person->setCompany($company);
$company->expects( $this->atLeastOnce() )->method(‘giveLaptop’);
$this->assertTrue($person->startFirstDay());

In this silly example, we are testing Person, and we want to verify that on the first day of work with a company, that person has a laptop assigned.
Person is actually instantiated, but Company, possibly a bigger and more complicated class, with other dependencies, is just mocked.
What we check is that inside Person::startFirstDay(), there’s at least one call to Company::giveLaptop().

As mentioned at the beginning of this article, expectations are available on Perl too, with the module Test::Expectation. The equivalent of the example before could be:

my $person = new Person();
my $company = Test::MockObject->new();

$person->setCompany($company);

it_is_a('Company');

it_should "give a laptop", sub {
Company->expects('giveLaptop');
is(1, $person->startFirstDay());
};

(Note that Test::Expectation uses internally Test::More with a plan, so if you’re using Test::Expectation AND Test::More you can’t set a plan with the latter, as perl will complain that there’s already a plan set by the former)

Unfortunately Test::Expectation is not available as a standard debian package, so if needed you may debianize it (just download, untar, dh-make-file and debuild. I wrote this article with some basic instructions).

Disclaimer:
- The code in this article can't work as is, i.e. it needs modules to be installed and configured, and more lines to include those modules.
- The code in this article has not been tested, and it doesn't come with any warranty
- I'm not implying that a company should provide each employee with a laptop during their first day

A gentle introduction to G.729

2011-03-05T12:33:00.005Z

G.729 is an 8 Kpbs audio codec, standardized by ITU, and called also CS-ACELP: Coding of Speech using Coniugate-Structure Algebraic-Code-Excited Linear Prediction, as that’s the algorithm used for audio compression.

It has two extended versions: G.729A (optimized algorithm, slightly lower quality) and G.729B (extended features, higher quality), and it's popular in the VoIP world because combines very low bitrate with good quality (but alas is not royalty-free).

G.729A takes as input frames of voice of 10 msec of duration, sampled at 8KHz and with each sample having 16 bit:

This gives a frame size of 80 samples:
8000 sample/sec * 10 * 10e-3 sec/frame = 80 samples/frame

The output is 8 Kbps, so each encoded frame is represented by 10 Bytes:
8000 bit/sec * 10 * 10e-3 sec/frame = 80 bit/frame = 10 Bytes/frame

Quality
Considering its bit rate, G.729 has an excellent perceived quality (MOS).
Under normal network conditions G.729A has MOS 4.04 (while G.711 u-law, 64 kbps, has 4.45)
Under stressed network conditions G.729A has MOS 3.51 (while G.711 u-law, 64 kbps, has 4.13)
Perfect quality has MOS 5.

G.729 doesn’t support (reliably) DTMF (RFC 2833)

Algorithm delay and complexity
The delay between input and encoded output is 15 msec: 1 frame (10 msec) + 5 msec required by the look-ahead prediction algorithm.

Not surprising, such a low bitrate associated with high quality, G.729 has relatively high complexity, 15 (while G.711 has 1, and on the other extreme side, G.723.1 has 25).

VAD and CNG
G.729B has been extended with VAD (Voice Activity Detection, which causes silence suppression), and generates CNG (Comfort Noise Generation) packets. This helps the receiving end in two key elements:
1. Recover synchronization in condition of high latency network
2. Generate Comfort Noise (which in case of silence from the transmitting end, tells the receiver that the call is still up)

Next to come, a gentle description of ACELP and G.723.

Test::Harness, or a lesson about wheels not to be reinvented

2011-03-01T18:48:00.008Z

Let’s say you have your unit tests in place, using something not particularly esoteric as Test::More. Good.

Now you want something to give some color to your output, so green is Good, red is Bad and you have a quicker feedback.

Time ago I wrote a quick shell script to run all the unit tests, interpret the output (in TAP format), print on screen some color output and stop the tests if something fails.

The core was:

function check_test_result() {
red='\e[0;31m'
green='\e[0;32m'
end='\033[0m'

result=`perl $1`;

echo "$result"

perl -e '{ my $input = join(" ", @ARGV); if ($input =~ /not ok/m) { exit 0; } exit 1; }' $result

if [ $? -eq 0 ]
then
echo -e "$red Not all tests passed. FAILURE$end"
exit -1
else
echo -e "$green All tests passed. SUCCESS$end"
fi
}

This works as soon as the unit tests fail (printing ‘not ok…’), but doesn’t quite work if something else is wrong (and you see the typical “your test died just after…” at the end).

Rather than improving this script, I was looking for a low hanging fruit, and eventually the easiest way I've found is to use Test::Harness prove, which BTW has color output by default.

So instead of the above (which needs also a few more lines to get the list of .t files), I can just use:

$ prove -v t/*.t

I mentioned Test::Harness prove in this post too, where I was using the JUnit module to convert from TAP to JUnit format, and get some nice code coverage report on Hudson.

Build-Depends-Indep is useless

2011-02-28T18:18:00.002Z

The words in the title are not mine, but only a quote from Debian Wiki.

However, if you're reading a debian/control file and wondering what Build-Depends-Indep means, starting from the assumption that it is useless may help.

Otherwise you can follow the rule to put in Build-Depends all those packages that are absolutely necessary to build architecture-dependent files, while the rest goes into Build-Depends-Indep.

Use the Warnings, Luke

2011-02-26T11:35:00.003Z

Browsing StackOverflow on perl-related topics, I have two main considerations:
1. Answers are typically very good, concise and useful
2. Questions are submitted with code that doesn't have 'warnings' enabled

I'd say that a considerable portion of the questions submitted would not be posted, or would be less generic, if authors used 'use warnings;' in their code.

Then add a pinch of the great perl critic, and possibly only half of the questions would really be submitted.

If you're using perl, or plan to use it, I strongly recommend to:
1. Always set 'use warnings;'
2. Always submit your code to perl critic (and keep a copy of Perl Best Practices handy).
3. First create the tests, then write the code. That's the only reasonable way (unless you're working on a one-liner for a quick admin task). TDD is your friend.

See more on Perl Critic here.

debian - cleaning up stale configuration files

2011-02-01T12:49:00.003Z

As suggested in Debian Cleanup Tip #1: Get rid of useless configuration files, it's worth using grep-status to retrieve information about configuration files left behind a package removal or upgrade.

For example, on my Squeeze VM:

$ grep-status -n -sPackage -FStatus config-files
libjack-jackd2-0

You can confirm with 'dpkg -l' that's a package in 'rc' status:

$ dpkg -l | grep libjack-jackd2-0
rc libjack-jackd2-0 1.9.6~dfsg.1-2 JACK Audio Connection Kit (libraries)

You may probably want to remove definitely those configuration files; just purge the package. For example:

$ dpkg -P libjack-jackd2-0

See also about debian configuration files, an important assumption Debian takes.

Recommended tool: Putty Session Manager

2011-01-12T13:43:00.002Z

If you have more than a few entries on putty, you may consider using Putty Session Manager.

You can organize your sessions in folders (and start all the sessions inside a folder with a click).

Please leave a comment if you know something better!

debian, tab completion failing

2011-01-10T17:29:00.002Z

Not a big deal, but since the solution to this problem wasn't immediate to find, it's probably worth writing it down.

Symptom: when you try to tab complete a command, you see a message like this:

vi /et-sh: <( compgen -d -- '/et' ): No such file or directory

Cause: You're using sh, not bash, so even if tab completion is enabled on ~/.bashrc, it won't be available to you.

Solution: change the default shell for the current user from sh to bash with

chsh -s /bin/bash

That's it.

Inside-Out Objects for Perl – I’m not convinced

2010-11-12T11:36:00.003Z

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, the best analysis I’ve found is from perlmonks in 2005.

I agree with the points raised by jhedden (however I find points 1, 2, 3 and 9 “less strong” than the others):

Hash-based objects are the standard. Using a different object API may lead to maintainability issues.
Inside-out object classes aren't compatible with hash-based object classes.
Inside-out objects are just another kludge on top of Perl's already kludgy OO mechanisms.
I haven't had any problems using hash-based objects. The encapsulation and compile-time checking advantages of inside-out objects aren't important enough to induce me to use them.
The encapsulation provided by inside-out objects is unenforcable because the source code is available.
Inside-out objects require a DESTROY method, and I don't what to have to remember to write one each time I create an inside-out class.
There are too many alternative inside-out object support modules that aren't compatible with each other.
I'm leery of the 'magic' the inside-out object support modules do 'under the covers'. There may be bugs or they may lead to unexpected problems when interacting with other modules.
I tried module Foo::Bar, and had problems with it so I gave up on trying to use inside-out objects.
You can't serialize inside-out objects either in general, or using Data::Dumper or Storable.
Inside-out objects are not thread-safe because they usually use refaddr as the key for storing object data.

I was hoping perl 6 will eventually solve the problem of private attributes (which is all I want here) and it seems I’m lucky:

Attributes are defined with the has keyword, and are specified with a special syntax:

class MyClass {

has $!x;

has $!y;

}

The ! twigil specifies that this variable is an attribute on an object and not a regular variable.

Attributes are private, but you can easily add an accessor for it, that is a method of the same name that can be called from the outside of the class and returns the value of the attribute. These accessors are automatically generated for you if you declare the attribute with the . twigil instead:

class MyClass

has $.x;

has $.y;

}

When you assign to an attribute from within the class, you still have to use the ! form.

Do I like that syntax? I do not. Do that mechanism satisfy my need? Yes, thank you.

Another reason to look forward to Perl 6.

Test reports on Hudson in 30 seconds (well, let's say quickly)

2010-10-29T13:21:00.003+01:00

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 CPAN modules:

wget http://search.cpan.org/CPAN/authors/id/L/LK/LKUNDRAK/TAP-Harness-JUnit-0.32.tar.gz
tar -pzxvf TAP-Harness-JUnit-0.32.tar.gz
dh-make-perl TAP-Harness-JUnit-0.32/
cd TAP-Harness-JUnit-0.32
debuild

There you go.

A rather serious matter – deciding what to read

2010-10-23T22:37:00.004+01:00

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 interesting novel of 200-300 pages.

I’m not sure I should consider technical books as a separate topic, because I typically like them, and so they are relevant not only for my job but in general for me (or I just can’t manage to read them, so the time spent is 0).

For sure, they require considerably more time than novels (mainly because it’s more “studying” than “reading”).

I’ll leave them out to focus more on “what I should read as a human being, rather than as engineer”, and to simplify my point.

So in a month I could read 2-3 interesting books. Holidays will probably tend to increase the average, but first I don’t have so many holidays, and second there are working months in which I don’t find the time to read as much as I’d like.

Let’s say 2 books/month. It’s 24 per year; 20 with a more conservative estimate.

20 books per year means that from today until I die – depending on how things go – I could read from 0 (damn double decker on a Sunday morning) to about 800 books.

If you just refer to some “1000 books to read before you die” articles, you see that I already can’t read 200 of them (I think I can safely remove the “Love” section for now though), and still there are thousands of options out there. Furthermore, each year new books worth reading are published – let’s say between 5 and 10? This means that even if I want to keep reading books that are really worth the time, I have to pick up now only about 600 existing books. 500 makes it a nicer number.

So the question is: “What are the 500 books that are worth reading before I die?”

What do you suggest?

(hint: consider that 40 good books will keep me quiet for a couple of years, so no need to completely drain your energies on the other 460 for the moment).

I know what books I liked so far though: I’ll write a separate post on it.

A forgotten note

2010-10-16T18:44:00.003+01:00

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.

Need some constructive criticism on your code? Ask perlcritic.

2010-10-16T17:27:00.005+01:00

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 same build scripts are used by a CI tool, I'm tempted to make the build fail if policies at level 4 or 5 are violated (as I do whenever even a single unit test fails), but I'm still not sure.

Anyway I strongly recommend this tool to anyone writing perl code, even if they are just scripts with a few lines (which are very likely to grow in the future, as a law on the increase of code complexity in the time - which I can't recall now - says ;-) ).

Personally, even if I don't agree 100% on what PBP recommends, I'd rather follow it and have a documented approach than do what I prefer (maybe just because I'm used to it) without a specific, well-documented reason.

If you just want to have a quick look, upload some perl code here, and see what feedback you get.

A note on the term constructive criticism: I chose it in the title as a mere translation from something I could have written in Italian, but then reading its definition on Wikipedia I think I've learned something more. Here's a quote:

Constructive criticism, or constructive analysis, is a compassionate attitude towards the person qualified for criticism. [...] the word constructive is used so that something is created or visible outcome generated rather than the opposite.

Merging hashes with Perl - easy but (maybe) tricky

2010-10-06T21:26:00.004+01:00

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(%hashInput1, %hashInput2) = @_;

print "hashInput1: " . Dumper(\%hashInput1);
print "hashInput2: " . Dumper(\%hashInput2);
}

What would you expect? Try it out.

What actually happens is that the two hashes are merged inside the call to useHashes(), and all works as if useHashes() received a single argument (the merged hash), instead of two separate arguments (the two original hashes).

Configuration files: an important assumption debian takes

2010-09-27T11:50:00.003+01:00

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.

Order of Ignorance

2010-09-25T20:56:00.004+01:00

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.

Level 1: I know the problem but I don't know how to solve it.

Level 2: I don't know I have a problem.

Level 3: I don't know how to identify if I have a problem.

The new (for me) concept I was reading about, applies a similar concept to uncertainty :

Variation is where assigned cause has been eliminated and only chance cause exists within a known and understood system.

Foreseen Uncertainty is where there are identifiable risks and understood issues which affect the delivery of the project but the basic market for the deliverable is understood and the business model or go-to-market strategy is understood. However, there is sufficient uncertainty that assignable cause variation will be observed and must be dealt with through aggressive issue log management.

Unforeseen Uncertainty will feel out of control most of the time and what gets delivered won't be exactly what the customer wanted or when they wanted it. This could be because the software development is happening with a new paradigm of tools or method - when teams start using MDA or DSLs for example - but it may also occur in new markets where the business model is not understood and the degree of variation cannot be predicted. The answer is to iterate frequently and plan adaptively. It is primarily this class of project which Doug DeCarlo addresses with his Extreme Project Management method.

Finally, there is Chaos, the land where we don't know what we don't know and we are trying to find out - neither the market, the business model, the customer base, the product features, or the technology are understood. It's the land of research projects.

In my words:

Variation: No uncertainty. You know the market and what to push on it.

Foreseen uncertainty: You know what problems can arise and you're ready to face them.

Unforseen uncertainty: What you deliver is different than what you've planned because uncertainties moved your scope.

Chaos: You don't know what to do and how to do it.

If I could decide, I'd choose to work in a scenario where I have Order of Ignorance 1 (I know the problem but I need to learn how to solve it) and Forseen Uncertainty, as I find it the most interesting to be in.

I know what your question might be at this point: "It's Staurday night and the most exciting thing you can do is... write this post?".

Well, you can classify your plans for a Saturday night in 4 different categories...

Programming: the first thing to learn

2010-08-10T11:58:00.003+01:00

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.

The concept I want to stress here is simple: The Code You Write Must Be Automatically Testable.

Emphasis on: Testable.

Emphasis on: Automatic.

1. At any given moment, you must be able to launch a script and verify that your code works as expected, while the result of the verification is automatically checked (refer to Unit Testing). Better if the script is fast.

2. Before changing your code, you must first write the tests to verify your changes will do what you expect (this is called TDD, Test Driven Development - there are many interesting and well written articles on this topic). Those tests will fail: your job will be making them pass.

3. You must not commit changes when some of the tests fail.

4. You must not build a package when some of the tests fail.

5. You must not be happy until all your tests pass.

(As a collateral note, you should beware of programming languages that don't provide mature and well maintained tools for unit testing.)

What happens if you don't follow this approach? Well, you will be able to write your code, have fun with it, pass your exams or even get paid for it, but sooner or later you'll end up with one or more of these questions:

"When did I break this?"

"How happened I didn't realize this wasn't working?"

"Now what else am I going to break if I add this new feature?"

"How can I test those 10K lines of code, without touching them?"

"How comes the testing guys never invite me for a beer?"

Inside the brilliant Head First - Software Development, you find the description of this simple process:

1. Write the tests

2. Make the code work

3. Refactor

4. Back to 1

On the Perl side, "Extreme Perl" gives a pragmatic view of testing.

Things start to get more complicated when the application you're writing has to interact with other "external" entities, which may be even remote. I'll write on this in the future.

Perl modules: from a new idea to a debian package in one minute

2010-08-06T10:20:00.002+01:00

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

$ debuild -us -uc

if you don't want to sign the deb.

Then I just suggest to have dput configured and upload the package to your repo.

Building a debian package for a CPAN module, and a known issue

2010-04-16T11:59:00.003+01:00

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

Creating (easily) a local debian repo

2010-04-13T18:00:00.004+01:00

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 topic (I know I should read all the Debian Policy docs and come up with one, single, incontrovertible answer. But I prefer the empirical way, sometimes).

So far I've just created a local repo using reprepro, and following this easy tutorial. I'll update this post with a simple procedure to build your own repo and some results on how to manage the distributions (although I must admit that in this particular moment I expect a simple solution to be:

1. Just stick both distributions inside debian/changelog

2. Add a Provides directive to debian/control

)

All you want to know about development on Debian

2009-11-27T16:39:00.001Z

... and you never dared asking. Enjoy.

mysql and regular expressions

2009-11-13T12:29:00.002Z

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.

Now save and quit... doh!

2009-11-06T14:12:00.002Z

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.

Most used Perl editors

2009-10-26T14:11:00.003Z

I've seen this poll too late, although it's interesting that the most used Perl editor is the vi family (where I'd belong) with 34%, followed not very closely by Emacs (13%).

Eclipse + EPIC got only 6%...

The full poll results here.

Debianize a Perl module

2009-10-20T17:18:00.003+01:00

What a good day.

Not only I've got a new laptop from the company, but I've found also an extremely useful tool to build a debian package from a perl module: dh-make-perl.

You just need to do 2 things:

- Run dh-make-perl on the untarred module directory (this creates the necessary debian dir and files).
- Inside the module directory, run debuild.

Very nice. Now I wonder why most of the CPAN and POE components don't come with a debian package...

When was that package installed?

2009-10-08T18:03:00.002+01:00

You can check the date from the output of:

ls /var/lib/dpkg/info/*.list -lh

Just | grep the name of the package you're interested to.

See this for important details.

My favourite photographer

2009-07-17T18:42:00.001+01:00

http://www.egglestontrust.com/

debian policy for init scripts

2009-07-17T18:37:00.003+01:00

It could be useful to add your /etc/init.d/ script to debian/conffiles to avoid overwriting local changes.
Sometimes sysadmins change the init scripts and with this little tip you can help them in case of package upgrades.

From the Debian Policy Manual:

"The /etc/init.d scripts must be treated as configuration files, either (if they are present in the package, that is, in the .deb file) by marking them as conffiles, or, (if they do not exist in the .deb) by managing them correctly in the maintainer scripts (see Configuration files, Section 10.7). This is important since we want to give the local system administrator the chance to adapt the scripts to the local system, e.g., to disable a service without de-installing the package, or to specify some special command line options when starting a service, while making sure their changes aren't lost during the next package upgrade. "

Using externals with SVN

2009-07-17T18:26:00.003+01:00

UPDATE: You need to specify the directory you want to create when setting the external property. No need to create the dir before propset: it'll be done automatically when you 'svn up'.

- Create somewhere in the SVN repo the directory you want to use as external (let's call it SVNEXTURL)
- Go in the working copy where you want to have an external reference and:

svn propset svn:externals 'newlocaldir SVNEXTYURL' .

where newlocaldir is the name of the directory being created by SVN during this operation.
Quotes are needed.
Note the '.'

- and then
svn up

Enjoy!

Problem: if you're using a version of svn-buildpackage older than 0.6.24 (debian), it won't work with external references. You can upgrade to >= 0.6.24 or apply locally the patch described here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363003

Lessons learnt #1

2009-05-18T18:36:00.002+01:00

Not a real surprise, but useful to write it down...

- If you have data that varies depending on the platform or environment you're using, be sure to have it in a separate file, marked as config file (for example using debian/conffiles if you build debian packages)

- Be sure to have a clear way to handle dependencies - Write them down and whenever possible use automated tools, as debian/control if applicable)

I'm cellphone only

2009-05-14T23:25:00.003+01:00

Now that I think about it, it's since 2000 that I don't have a fixed telephone line in the house where I live. Cell phone and ADSL or 3G data connection meant to replace it (with some limitations in terms of service availability and emergency calling).

It's probably a known trend: in the US 20% of people have made the same choice.

And look how many families are adopting wireless phone services only! I'll write on this topic and on interesting solutions.

VOIPBLOG.IT reported it in Italian.

2700 blogs available on the Kindle Store (and a digression)

2009-05-14T22:50:00.003+01:00

Quite amazing to see how many blogs you can subscribe to from the Kindle Store.
Prices go from 0 to $1.99.

By the way, digging a little bit in the past (March 2008), I've found an interesting rumor from Apple about a tablet from Mac:

A little birdy tells me that Apple will announce a 12 or 13-inch tablet in the fall of this year. Most likely in the September or October time frame.

That was rumored one year earlier as well (January 2007).

I could go even further in the past, but the good news seems to be that this time, eventually, we'll get the mega tablet from Mac on the next Fall... maybe.

curl for HTTPS (and Twitter)

2009-05-13T18:09:00.003+01:00

curl is a powerful library available on different platforms - I use it on Linux debian.

You can use it just to get http pages, or to post data and get a response from a server.
HTTPS is available too.

An example:

curl -k --data @request.xml https://127.0.0.1/service

posts the XML data contained by request.xml using a HTTPS connection (and ignoring invalid certificates, option '-k' - just for testing purposes).

This is a more interesting usage: it's nice to get info from Twitter or even send messages ("update your status") with just a command line:

Get status:
curl http://twitter.com/users/show.xml?screen_name=giavac

Send a message:
curl -u user:password -d "status=describing how to use the Twitter API" http://twitter.com/statuses/update.xml

To install curl on debian:

apt-get install libcurl3

(install dependencies too, and I suggest to include libcurl3-gnutls-dev)

How many different tea times do you have?

2009-05-12T19:35:00.003+01:00

Just realized that in UK you can refer to the "last or almost last meal of the day" as "Tea".

This just makes sense, considering that while driving you have to keep the left, but on the escalator you have to keep the right if you're standing, and the left if you're walking.

Not mentioning that your weight can be measured in stones, but in the gym weights are in pounds OR kilos, while when you buy food they use ounces.

I'll have a twentieth of gallon of tea before going home for the tea...

41.5% of Italians don't use Internet

2009-05-12T19:34:00.003+01:00

...even if Facebook looks very crowded!

Source IlSole24Ore.

Touching art with an iPod

2009-05-10T21:13:00.004+01:00

Positively surprised to experience that the so-called audio guides have been replaced by iPod Touch at Tate Modern.

Advantages are:
- You can see movies and pictures together with the audio presentations
- Easier to use - no need to enter a number to select an argument
- Lighter

Disavantages:
- Even if you're a Tate member, and you're paying for the guide, you have to leave an ID...

e-readers and advertising on newspapers

2009-05-09T23:52:00.004+01:00

Yesterday I wrote a quick note on Kindle DX, the new e-reader from Amazon, and today on The Independent I've found an article titled "Hold the front page: newspapers have a future" (see picture, taken this afternoon from Tate Modern).

Statistics say clearly that advertising in newspapers is going down rapidly (starting well before the 2008 internation crisis), so in this area, like on the web, there's more and more focus on context advertising. Less costs, higher conversion rates.

e-readers can be, more than just an interesting gadget, a tool to access "custom" advertising and ad-hoc contents. It would be nice to read your favorite magazine, select some additional content, find deals on what you're interested in and... buy it straigth away!

But I was also thinking: is an e-reader really needed? Or maybe manufacturer of mobile devices, already accessing Internet via WiFi and 3G, should just provide a big, plug&play screen, optimized for reading? Rather than spending 350P for the Kindle DX, I'd spend half of it for a portable screen to attach to an iPhone...

Kindle DX - Cool but expensive, and won't replace books (I hope)

2009-05-08T16:51:00.004+01:00

The title says almost everything I wanted to write about the new Amazon e-reader.

A detailed article from BBC News.

When the prices will start dropping, I'll take it into serious account.

VoIP banned from MS MarketPlace (MS style)

2009-05-08T11:13:00.003+01:00

That's the way MS wants to compete on the Mobile applications against the AppStore: banning VoIP from the allowed applications.

It's the 4th point in their Prohibited Application Types document.

Topic followed through VOIPBLOG.it and thestandard.com.

Where cloud computing is going

2009-05-07T14:51:00.003+01:00

Just finished reading an interesting article by Paul Bennet on Cloud Computing.
It really looks like we're going in that direction, with security and data privacy as key points.
Furthermore, in UK as well you can get notebooks for free with a monthly data contract!
The OS is not a problem, however the availability of VPN clients will be extremely important.

MySQL - Last INSERT id

2009-05-06T12:28:00.002+01:00

If you want to know which is the ID of the last INSERT been made from the current connection, when auto_increment is active, use this:

SELECT LAST_INSERT_ID();

A few lines in non-optimized perl:

my $sel_last = "SELECT LAST_INSERT_ID();";
my $sth = $dbh->prepare($sel_last)
or die "Couldn't prepare statement: " . $dbh->errstr;

$sth->execute()
or die "Couldn't execute statement: " . $sth->errstr;

my @data;
while (@data = $sth->fetchrow_array())
{
print "Last ID was.... $data[0]";
}

More details here for the MySQL statement and here for the perl DBI.

MS and Verizon to fight the iPhone

2009-04-30T23:53:00.003+01:00

'Pink' is the code name for a new mobile device aiming to compete with the iPhone.

Key points are:
- Touchscreen (surprise)
- More powerful OS (extending Windows Mobile)
- More applications (maybe with the same iPhone Apps approach?)
- An online store (Windows Marketplace for Mobile)
- WiFi (in collaboration with Verizon Wireless)

News from the Online Wall Street Journal, reported in Italian for IlSole24Ore.

base64 encoding/decoding

2009-04-30T16:13:00.004+01:00

One of the biggest problems nowadays is to being able to encode or decode to/from base64.

Jokes apart, if you need to quickly check a base64 string, try this encoder or this decoder (mind the note before using them).

Facebook Lexicon

2009-04-29T17:37:00.003+01:00

Pretty nice application for Facebook - It enables you to see statistics on keywords on the public walls.

Give a look to it here: http://www.facebook.com/lexicon/ and try for example: "brawn, ferrari" or "iphone, ipod".

Let's start again

2009-04-28T13:57:00.001+01:00

It's been a while since my last blog post - I haven't published anything for more than a year, so recently I've decide to close my old blog and open a new one (this one).

Feel free to subscribe to this blog, contact me, leave your comments.