Finally a milestone as a CPAN tester!

Today I was excited to see that I finally got a second place at number the tests submissions from OpenBSD to CPAN:


It took a while for sure, but I was most of the time running a single smoker VM.

Of course, it would be more cool to get the first place - not much people are running smokers on OpenBSD, despite my efforts to make it easier - but for that I will need to get a working cluster because that's how BINGOS got that gigantic amount of submitted tests. Making plans to release some instances on AWS just to see what is what.

RabbitMQ on Docker with custom configuration

This is a quick tip.

I was thinking in a way of using RabbitMQ on a Docker container as part of an automatic integration tests for a application I was working with at my current job. That is easy, the Docker Hub has an official Docker image ready for use as rabbitmq:management-alpine.

My first thought was to automate the configuration of the RabbitMQ by using rabbitmqctl or rabbitmqadmin programs, but then I remembered that RabbitMQ can actually use a exported configuration backup in the form of a JSON file.

The problem was: how to load this configuration? I can't change the Dockerfile in order to do that because the broker must be running in order to load the configuration but then I would need to override the ENTRYPOINT, something that I was not willing to do.

Fortunately a good soul had already implemented a clever hack to the container configuration as you want, without doing many changes in the original Dockerfile.

So, at the end, the only thing I need to do is to write a Dockefile like the one below:

FROM rabbitmq:management-alpine
COPY rabbit_config.json /etc/rabbitmq/definitions.json

Dropping Archive::Tar::Wrapper support for Solaris

I recently adopt a Perl distribution: Archive::Tar::Wrapper.

Initially developed by Mike Schilli, this module is well know by the Perl community and it is being around since 2005. All started because I submitted a patch to Mike to make it work on OpenBSD.

From there, I tried to fix another known bugs (and introduced some!) and make it run on operational systems that were showing problems.

After fixing the distribution to run on MS Windows properly (with the help of Ingram Braun), the next step would be to fix it for Solaris. Carlos Guevara gave me some pointers and I decided to take a look.

First thing I thought was try to use a VM for it, of course. Vagrant VM's should be easier to use, and I was able to find one with, I think, a decent recent version.

That's is what I got after booting and logging in a shell:

Last login: Wed Jul 18 16:25:27 2018 from 10.0.2.2
Oracle Corporation      SunOS 5.11      11.3    September 2015
-bash-4.1$ perl -v

This is perl 5, version 12, subversion 5 (v5.12.5) built for i86pc-solaris-64int
(with 7 registered patches, see perl -V for more detail)

Copyright 1987-2012, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

Oh, come on! perl 5.12?!? Really?

That gave me some thoughts about how old Perl 5.12 is and how little Oracle cares about Perl.

And brought back memories about the time I spent over there, when I was able to see that Perl was used everywhere inside the company, from day-to-day automation to specifically helping their own products. I was even able to find that in the past (and I don't remember how long it lasted) there was a group of people specialized in using Perl to automate anything, or even develop web applications using Catalyst. I wasn't able to contact any member of the group about that time.

Not long after that, I got a blog entry from Perl Weekly about a new release of DBD::Oracle. To my surprise, even after many years Oracle still makes the life of Perl programmers unnecessary miserable when they just need to connect their code to a Oracle database and have to do all sorts of configurations to just install a Perl module due binary dependencies.

Long story short: I gave up trying to support Solaris. Just put

if ( $^O eq 'solaris' ) {
    die "OS unsupported\n";
}

in the Makefile.PL and life goes on.

I won't reject a patch to make Archive::Tar::Wrapper on Solaris, as long it passes on the unit tests and don't break on other OSes, but from my perspective, the Perl community doesn't really need anything from Oracle.

I have the utmost respect about Sun Microsystems and all the contributions it gave to the community but for Oracle? Not really. At all.

Quickly making a DEB from a Perl module

Recently I had to quickly create a DEB package for Ubuntu for a Perl module available on CPAN (not sure why REST::Client is not available anymore).

It has been a while since the last time I did, and honestly I couldn't remember what was required to.

After some frustating minutes trying to go over the documentation for dh-make-perl, I was able to reach those two simple lines in a shell:

$ export DEBFULLNAME='Alceu Rodrigues de Freitas Junior'
$ dh-make-perl --cpan REST::Client --arch all --depends libjson-xs-perl, liblwp-protocol-https-perl, liburi-perl libwww-perl --email glasswalk3r@yahoo.com.br --build

Documentation of dh-make-perl does have a lot of space of improvement... and for my dismay, it is not even easy to do make contributions for it: no available access to the repository as you would expect to do nowadays (git pull request), first you got to be accepted as a Debian contribuitor... which is not that easy too.

Perl on Windows... still not that good

Today I had to use Perl from Windows... it was a couple of years ago that I needed to do it so.

Frankly, it was never the best experience from a end user point of view. Strawberry Perl made it a lot easier, but to this day it is still an incomplete solution.

I don't want just to complain about it... if you don't like a opensource project, don't use it. Or try to improve it yourself.

Here are some notes for those willing to do the later:

1. Install Git for Windows. You will get some other nice programs as tar and gzip. You will need those and what the heck, everybody uses git nowadays.
2. Configure the cpan program. You can use the default configuration offered and set some items later.
3. Configure cpan to use the tar and gzip programs from step 1. In the case you don't remember, type o conf tar and o conf gzip and setup the complete path to those guys. If you were unwise and setup Git for Windows use the suggested path (C:\Program Files\Git), you will have to do some quoting and escaping the backslash (like "C:\\Program Files\\Git\\usr\\bin\\tar.exe").
4. Configure cpan to use the gmake.exe program (don't really know why it wasn't configured by default, considering that gmake.exe is part of Strawberry Perl): o conf make C:\\Strawberry\\c\\bin\\gmake.exe
5. Configure cmd.exe to use Unicode by default: fire up the command REG ADD HKCU\Console /v CodePage /t REG_DWORD /d 0xfde9 with administrator privileges in order to do that. It avoids you having warnings all over because of Unicode characters.
6. Configure cpan to use a SQLite database (which speeds up the process): o conf use_sqlite 1
7. Install YAML::XS, which is faster than YAML.
8. Be smart and add C:\Program Files\Git\usr\bin to your PATH variable.

cron versus Crom

Do you know cron? If you ever worked on a UNIX-like OS, it's very likely you do!

But what do you know about Crom?

What have they in common besides the (almost) identical names?

Let's see how the venerable cron compares to the imortal Crom!

	cron	Crom
What is it?	Software time-based job scheduler for UNIX-like OSes.	Fictional Cimmerian deity of Hyborian Ages.
Uses	Schedule tasks to be executed, per user, with granularity of one minute.	Basically nothing. Some believe that he bestow men and women at birth with the courage to survive, persevere, and vanquish adversity.
Creation	1979 (Version 7 UNIX).	1932. Crom is the most venerable indeed.
Versions	Several (proprietary, open source and free software) implementations.	There is only one Crom, you hound dog son of a thousand fathers!
How to use it	Executing crontab -e, or editing the several files that comprises it's configuration	Invoke his name during an oath or curse. That's the only know safe way to mention him.
Known problems	It will issue error messages if you messed up with the expected syntax	He has little patience for weakness, which means asking him for help will make him to ignore you (at best) or really f@#$%&! you (at worst).

Getting Ubuntu, Python 2.7, Jedi and Vim playing nice to each other

This took me some hours to figure out: how to finally set Jedi with Vim to have a good editor for Python 2.7 code.

Ubuntu 16.04 by default install Vim compiled against Python 3.5 interpreter, which is not immediate obvious but becomes a pain in the ass after you discover that even after installing Jedi and python-jedi, you're still getting the error message:

Please install Jedi if you want to use jedi-vim.

When opening a file with Python code.

To get things working for your Python 2.7 code, you might need to uninstall your current Vim related packages and install the following:

• vim-addon-manager
• vim-common
• vim-gnome-py2
• vim-gtk3-py2
• vim-gui-common
• vim-nox-py2
• vim-python-jedi
• vim-runtime

You can check your current configuration with:

$ dpkg-query -l 'vim*'