And it doesn't enter sleep mode. It just goes puf, and powers off.

Searching around for similar reports, it seems that my battery is kaput. Either a cell is damaged, or the battery is starting to swell. I'm guessing its the first one, since I don't notice any swelling.

This is the third battery I've burned through with this laptop. The first one lasted from May 2006 up-to sometime early 2008. The second one lasted a couple of months, then started to swell. And now this one, since Mon Oct 27 23:20:47 2008 until today.

Now you might wonder how can I know the exact date and time that I got the new battery. The answer is simple. Before I switched to the new battery, I wrote this script, x-apple-log-battery-status, a quick and very dirty way of keeping track of all the stats about my battery.

I run it every 300 seconds. Given that the script logs the data to disk, it has to spin-up the disk and therefore influence the data collected, but I use my laptop intensely anyway. It rarely sleeps.

So I've recorded 53605 samples of my battery life. The first record is this:

t:1225149647 # Mon Oct 27 23:20:47 2008
fully_charged: No
is_charging: Yes
external_connected: Yes
cycle_count: 1
time_remaining: 38
max_capacity: 6869
voltage: 12485
current_capacity: 6516
design_capacity: 6300
temperature: 3082

The last one so far:

t:1266581334 # Fri Feb 19 12:08:54 2010
fully_charged: Yes
is_charging: No
external_connected: Yes
cycle_count: 561
time_remaining: 25013
max_capacity: 3367
voltage: 12459
current_capacity: 3335
design_capacity: 6300
temperature: 2944

As you can see, I've still have about 50% of the original capacity, but with 561 cycles.

The entire file is here: battery_log.txt.gz, 736Kb of gzipped data. You can do whatever you want with it, I only ask that if you do something interesting, send me a link.

Someday I'll dump this into a spreadsheet and do some pretty graphics.

Gone are the days that you could actually believe the "Don't be evil" corporate motto. The reality came crushing down, and Buzz is only one of the last proofs that "Don't be evil" is much different proposition than "Do good".

I'm fortunate enough not to use a lot of Google services, but still the amount of information they have on me is scary. I knew some of it, and I was aware of the social graph efforts going on inside Google, in particular Brad Fitzpatrick work when he first joined The New Borg.

But the path they choose with Buzz, assuming that my address book or even my chat roster, has anything to do with my social network, is wrong on so many levels.

For the geeks at Google, it appears that one step in their quest to harness all of the human knowledge is to treat humans as a flat concept, without any levels in their social relations. I no longer have best friends, whom I trust almost everything about me but that rarely exchange electronic messages, but I keep in my address book, with some guy that asked me a couple of questions some months ago. All of them get put in the same basket. So the same level of trust and sharing privileges is attached to all of them by default.

What bothers me the most is that now, until I can find replacements for the services that I find useful at Google (address book and mail), I will have to create new empty random Google account, and use each one for parts of the data I have in there.

The Future

During my college days, I was specially interested on distributed systems. I intuitively believed that they were the only solution for resilient scalable network-oriented services. What I couldn't imagine was that just how much important they are for the little level of privacy that I expect from online services.

So one of my goals for 2010 is to split my online information across several online services. Also, study options to move them back to my control.

As for Google, I guess it is time to start working on active Google blocking tools. There is definitively a war coming.

Congrats to all the Saints fans, excellent second half, with a awesome starting play.

Drew Brees MVP. Pity about not breaking the pass record. Tied with Brady at 32.

But for those that share my mother tongue, here it is.

(para quem leu a versão na mailing-list, tem apenas pequenas alterações de estilo, e um "Resumindo:" lá pelo meio)

A discussão que está a acontecer sobre o iPad, o efeito do modelo fechado e controlado pela Apple, e o que ele trás à criatividade e ao espirito hacker (no sentido cosquinhas, curioso, e não no sentido cracker) está mesmo muito interessante.

Acho que a questão da criatividade, que pelo que percebi começa com o post do Tim Bray que termina com a frase "For creative people, this device is nothing" é uma falsa questão.

Sinceramente, o bias natural do Tim Bray para a plataforma Android baralhou-lhe as ideias temporariamente. Basta apontar o trabalho do nosso Jorge Colombo com as capas da New Yorker como contra exemplo do seu argumento.

Mas mesmo que ele estivesse a dizer criativo como programador/developer, seria falso. Ninguém programa para o Android no próprio device. Estes devices não são computadores que possam existir no vácuo, são apêndices aos computadores que vamos ter em casa, ou no emprego.

O único contexto em que se pode ver o iPhone/iPad como limitadores de criatividade é nas politicas de aprovação da AppStore. Tudo o resto está disponível.

A parte de discussão sobre hackers é muito mais perto do meu coração. Tanto quanto pude ver começa com esta frase do Alex Payne:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today.

Apenas é possível concordar com isso se se pensar que o iPad será o nosso único computador, e claramente que não foi desenhado para isso. Mark Pilgrim parece concordar com esta visão negra do futuro dos hackers:

Once upon a time, Apple made the machines that made me who I am. I became who I am by tinkering. Now it seems they’re doing everything in their power to stop my kids from finding that sense of wonder. Apple has declared war on the tinkerers of the world.

O meu percurso (assim como de outros nesta lista, estou seguro) é semelhante ao do Mark: primeiro computador aos 11, começar a programar aos 12, 13 em BASIC e depois Assembler; começar a montar os seus próprios PCs; usar Pascal, C; usar minix, linux porque nos dava o controlo da nossa máquina; o querer saber como funciona, desmanchar, abrir, mudar. No meu caso sempre fugi um pouco da parte electrónica da coisa, não me dou com electrónica, e mais focado na parte de software low-level.

Mas respondendo à pergunta: será que o iPad vai limitar a próxima geração de hackers? Eu podia dizer que não e explicar as minhas razões, mas acho que a Gina Trapani tem uma resposta bem melhor que qq coisa que eu poderia escrever:

Because while we're all ranting about how closed the iPad will be, the jailbreak community is planning competitions to see who can crack it first. The sun isn't setting on tinkerers; their desire to crack things open intensifies when faced with something that's closed by design. The challenge is part of the appeal.

...

I'm of the mind that if someone wants to tinker, they will tinker, period. Because it's in their DNA, not because it's easy, and because by nature, tinkerers don't play by the rules.

A parte que eu posso acrescentar à discussão é esta: em 1991, na Universidade do Minho, a vasta maioria dos alunos não tinha acesso à internet. Não tinham mail, ainda não havia Web nem browsers, começava a aparecer usenet. Nesse tempo, quem andava pelos centros de informática, ou estava lá o menor tempo possível para fazer os seus trabalhos e ir embora, ou então pertencia ao grupo de pessoas que queria perceber tudo, como é que aquilo funcionava, como usar (e abusar) do sistema. Era uma "guerra" contra os administradores de sistema, porque era divertido. O que se fazia era programar, aprender e trocar conhecimento. Não havia outro sitio onde o fazer.

Durante os anos em que o acesso começou a aparecer, 92 e 93, apenas esse grupo lhe prestou atenção. Era uma fonte de conhecimento inesgotável e finalmente disponível. Despertava o nosso sentido de saber mais. Se tivesse de dar um nome a este período, seria a nossa explosão cambriana.

Esse aceso não nos transformou em colectores passivos de informação. Apenas nos deu mais energia para as próximas experiências.

Mas a partir de 94, altura em que os browsers Web começaram a ficar acessíveis às massas, começaram a aparecer uma nova tribo. Passavam horas e horas nos centro de informática a consumir informação, mas sem produzir informação. Lembro-me de discutir isto com a minha tribo e alguém (sinceramente não me lembro do nome dele) dizer "mas isto é o que se espera de pessoas normais". Sem dúvida que o nosso "hubris" tecnológico já estava presente e separava-nos das "pessoas normais" :).

Resumindo: não é possível julgar um device ou um comportamento que esse device facilita da mesma forma pela tribo dos hackers e pelo resto das pessoas normais.

A verdade é que para muitas pessoas, o que é importante não é se o sistema é aberto, às cores, hack-able, ou não. O que interessa é que com ele consigam fazer as tarefas simples do dia-a-dia sem as preocupações que apenas devem (ou deviam) existir na cabeça dos profissionais de IT.

Relembrando o artigo da Gina: ...someone wants to tinker, they will tinker, period. Because it's in their DNA, not because it's easy...

Penso em pessoas como a minha mãe, ou a minha tia, que por mais brilhantes e cultas que sejam (e claramente o são mais do que eu) não se sentem à vontade em usar um desktop clássico (Windows XP, Vista, 7, e Mac OS X) sem se baralharem.

Uma parte do artigo do Fraser Spiers:

Secretly, I suspect, we technologists quite liked the idea that Normals would be dependent on us for our technological shamanism. Those incantations that only we can perform to heal their computers, those oracular proclamations that we make over the future and the blessings we bestow on purchasing choices.

...

Those of us who patiently, day after day, explain to a child or colleague that the reason there's no Print item in the File menu is because, although the Pages document is filling the screen, Finder is actually the frontmost application and it doesn't have any windows open, understand what's happening here.

Ao olhar para os defeitos que a minha tribo atribui a esta nova plataforma, e seguindo um pouco a classificação dos mesmos que o artigo do Luke Wroblewski usa, podemos tentar vê-los do ponto de vista de uma "pessoa normal".

Quando se fala de multitasking, temos de clarificar exactamente o que queremos dizer com isso: correr várias aplicações ou partes delas ao mesmo tempo. De base, tanto o iPhone como o iPad, são um sistema multi-task, e apenas a limitação artificial da Apple em correr apenas uma aplicação ao mesmo tempo nos impede de o fazer.

Acho que é fácil de provar que a maioria das pessoas se baralha com multi-task. Basta pensar em todas as pessoas que já vimos a usar o Windows com todas as apps maximizadas, uma de cada vez. Ou de ver os problemas com o menu File > Print que o Fraser nos fala acima.

É claro que mudar rapidamente entre aplicações é importante, e essas mesmas pessoas o fazem, mas para tal não é necessário que a aplicação destino esteja a correr, desde que a ilusão criada pelo sistema operativo esteja bem feita.

Sem dúvida que várias features que a nossa tribo pensa em colocar nas suas aplicações passam por ter um processo em background a fazer qualquer coisa. Mas até as limitações actuais nas baterias estarem resolvidas, é possível argumentar que esses serviços devem ser feitos no nosso Mac/PC principal, e deixar a esse a tarefa de notificar o device que temos informação importante para ele, com a opção de enviar um link para a mesma informação que o device, transparentemente e sem a intervenção da app, obtem da rede para passar à app na próxima oportunidade.

Existem certas coisas que não são possíveis neste cenario, que normalmente envolvem informação que só o device pode ter (como o Bordalo nos diz, o Android dele adapta-se ao sitio onde está), mas até essas podem aparecer no futuro como um serviço do OS, disponível a todas as aplicações.

Quanto a não ter o plugin de Flash no Mobile Safari, já escrevi hoje sobre isso; resumindo a minha visão da coisa, era importante ter a opção de correr Flash no iPad, mas dispenso claramente de o ter dentro do browser, até porque as utilizações mais práticas que tenho para ele, estão (ou estarão) disponíveis via HTML5.

Todo o processo de aprovação da AppStore, e as barreiras à distribuição de aplicações são aspectos claramente negativos, apesar de dar origem a alguns episódios cómicos dignos de Kafka. Neste aspecto, acho que um compromisso pode surgir em que todas as apps tem de ser assinadas pela Apple (existem vantagens claras nisso), mas a distribuição pode ser via Web.

Uma coisa pouco discutida, é o facto de os i{Pad,Phone}'s não mostrarem o filesystem aos utilizadores. Segundo parece, no iPad, os ficheiros da aplicação ficam guardados numa pasta dentro da aplicação (que pode ser exportada para o Mac/PC via file sharing), de forma a que quando se remove uma App, tudo o que está associado a essa App desapareça (é giro cruzar esta funcionalidade com a alteração do Mac OS X relativamente a deixar cair o suporte a creator codes).

Cada app fica com a responsabilidade de mostrar os seus documentos, e se acham que isso é anormal, é porque não tem prestado atenção ao que o iTunes e iPhoto andam a fazer à anos: a esconder o file system com uma visão do mesmo ajustada à tarefa, ou tipo de documentos, que estão a ser manipulados.

Será que isso escala para muitos documentos? Olhando para o iTunes e iPhoto parece que sim, mas é possível argumentar que só funciona nesses casos porque apenas consumimos os documentos, não os alteramos profundamente, como numa aplicação do iWork.

É sem dúvida uma questão de volume de documentos, e faz mais uma vez lembrar que o iPad não pode ser um computador autónomo, sem o Mac/Pc para o acompanhar.

Mas olhando para as limitações como decisões conscientes de design, é importante ter uma coisa em conta: a nível de hardware, o iPad não nos limita em termos de user-inteface porque todo o seu UI é gerado por software (excepção única à ausência de camara que para mim é ainda hoje um grande mistério). Logo tudo o que nós hoje vemos como limitação, pode ser alterado, ou removido no futuro. Veja-se o que aconteceu com copy-paste nos iPhone's.

Como conclusão: para todos os efeitos, eu coloco-me claramente na tribo dos hackers. Ainda hoje continuo a abrir e fechar computadores como forma de hardware porn, principalmente máquinas antigas; ainda hoje continuo a continuar a ler e comprar livros para perceber como funcionam estes devices que nos intrigam; ainda hoje perco^Winvisto uma data de tempo todos os dias a estudar e a aprender com outros.

Por isso a minha posição sobre a politica da Apple não podia ser diferente daquela que a Gina Trapani tem:

First, know that I fundamentally agree with Alex and Mark: the closed nature of the iPad turns me off, and I wouldn't give one to my kid if I were encouraging her to learn about how computers work.

...

Even though I am critical of the iPad's closed nature and agree with Mark and Alex, I won't go as far as Alex did and say that it represents a dystopian future. I have more faith in our future tinkerers than that.

Mas a verdade é que eu não quero ser apenas hacker, e existem ocasiões em que é muito agradável desligar essa parte da minha vida para me concentrar no que está à minha volta, e nessas alturas, ter um device que me trate abaixo das minhas capacidades para o dominar, é uma trégua simpática.

Acho que a tribo está ao rubro porque este gadjet não é para eles, e isso é algo a que não estamos habituados.

As expected , the iPad will not support Flash, and this brought back all the discussion that went on when the iPhone appeared. I find it interesting that Gina Trapattani is seeing a reduction on Flash-enabled browsers (and thats not counting iPhones, just regular browsers) on her sites. Also Gruber (but he is counting iPhone's) and Alex Bayo.

As a end-user I would not mind see Flash burn in hell. On a regular day, I used to have regular Safari crashes. Since I installed ClickToFlash, I don't see them anymore. Maybe it is related, maybe not, but my suspicion is that the culprit is the Flash plugin.

But there are at least two features that I use several times per day that right now require Flash: multiple file upload, and clipboard access.

The first, multiple file upload, is solved by HTML5. Its in the spec, and implemented in Safari4 and Firefox 3.6+. I think that Chrome 2 already supports this too.

Regarding copy-to-clipboard, the situation is less clear. There is a section in the HTML5 spec about copy-and-paste, but it is inside the drag and drop chapter, and I don't know how it can be used today, if at all.

So the two last remaining useful (as in work-related useful) uses of Flash will soon have HTML5-based replacements, and that means that I will not miss Flash at all.

But that is not to say that Apple is right about this. As the person who bought (or will buy) one of this Apple devices that lack Flash support, it should be my decision to enable or not a technology that for better or for worst is still widely used. I do not want a Flash plugin, but I would not mind a Flash runner app. A dedicated browser, totally written and supported by Adobe, and available for free on the App store. With that, I would have a choice to click the blue legos and see the the Web as Adobe think it should be. (shudders)

First, you can look at the code of AnyEvent::Mojo::Server::Connection: no private Mojo APIs are being used.

They might have been with early releases, but as Sebastian says, I did work with him to improve Mojo so that I didn't have to depend on private APIs. That would be wrong.

In fact, given that I was able to write a AnyEvent-based Mojo server proves that the code was properly structured.

Second, I have no problems with changing state machines. I like state machines and expect them to change. I was eager to see Sebastian add a "pause" state, that would greatly simplify my own work regarding long-pooling. And the first break included changes in the state machine that I fixed on my side.

But the second break was caused not by the introduction of new states, but the abstraction of some code into the new Mojo::IOLoop. After the notification of no changes until 1.0.

Now, I totally accept that Sebastian needs to evolve his code base to support the new stuff he wants to support, like WebSockets. But it was nonetheless new code, and a re-factoring of all the Server interface.

I was pissed at having my code broken in that way after the "no changes" declaration, but only for a couple of days, but, and significantly more importantly, that has nothing to do with my deprecation of AnyEvent::Mojo.

I'm deprecating my module because there is a better way to do it now. I no longer need to keep this module up-to-date, I just have to work with the larger community of the PSGI/Plack, the Perl Web Server. It just makes sense to drop one-off module and switch to a system that is being reused by so many projects.

In a nutshell, I'm deprecating AnyEvent::Mojo because you have better solutions now. Solutions that I will move to and recommend to others. Solutions based on the PSGI/Plack stack, the Perl Web Server.

I am glad to see a clarification about the deprecation policy in the Changes and the http://github.com/kraih/mojo/commit/89fc6baf390d0065ad319abc540dc6a47e0bc812 for the Mojo project, I think it is a big step in the right direction; it can only give assurance to potential users of Mojolicious, and help the project.

I did learn a lot about HTTP that I hadn't pay attention before, the tiny details in the protocol. I do like Mojolicious MVC stuff, I just think that the Plack HTTP stack is better than the Mojo HTTP stack.

And I might get the cake and eat it too. I'll wait for Mojo 1.0 but it should be possible to use Mojolicious, the best part of the project, with Plack.

A long, long time ago...

When I wrote AE::M, I was looking for a way to do long-polling in Perl, with decent performance and cool stuff like epoll/kqueue support. At the time, the only solution might have been POE, but I have other problems with that module, so I decided I wanted a AnyEvent-based solution.

I went looking for a HTTP-stack that I could extend and found Mojo. The code was working and ready in a afternoon, and I was happy.

But then we had the famous 0.991250 release. A lot of backwards incompatible changes, and AE::M broke. I was caught at a bad time and could not update my own module for some weeks. In the Changes file, Sebastian explained why he broke backwards compatibility and that it would be the last time before 1.0; so I finally found the time and updated my code.

CPAN Testers was giving me green lights once more, and I was happy.

Until 2 months later that is, when we got the new Mojo::IOLoop code. AE::M broke again, and its broken since then. The place where I was using AE::M needed some fixes, and the work to adjust my code to the new Mojo is not as simple as it was the first time around.

So I took the dirty way out: included the last pre-Mojo::IOLoop code with my project, implemented the new features, and shipped. Not pretty. At all.

Meanwhile, in a distant planet, miyagawa was busy changing the Perl landscape with regards to HTTP integration. He wrote the PSGI spec, and the Plack toolkit. It is a wonderful piece of work, and the Perl Web Server of choice.

And after some API work, with the help of nothingmuch, it included a very decent support for asynchronous HTTP servers, including all the bits to make long-pooling work right.

Then in December, we got Mojo::Server::PSGI, native support for PSGI inside Mojo.

Next steps

Right now, I'm waiting for the next release of Mojo, and then I'll immediately release a new version of AnyEvent::Mojo, deprecating it.

With the native support for PSGI, there is no reason to maintain the AE::M interface, just use the Plack::Server::AnyEvent (or AnyEvent::HTTPD::PSGI when miyagawa finishes the cleanup he talked about).

But I will update the AE::M one last time to make it compatible with Mojo::IOLoop, as soon as I have the time. I don't want to leave it broken.

In the meantime, if you are using AE::M, I suggest that you bundle an earlier version of Mojo. I'll run a git-bisect to figure out which version is best and update this post.

Lessons learned

Not sure. On one hand, it is a version below 1.0 so we can expect some breakage.

On the other hand, the Changes file mentions that no more backwards incompatible changes would be made to Mojo before 1.0.

I still like the Mojolicious MVC framework and the dispatcher behind it, but I fear the Mojo stack and deprecation policy of the project now.

For now, all my async work is moving to Plack. I still need a asynchronous MVC framework, but I can wait a bit, or even write a very simple one if need be. Maybe steal code that I like from the others.

But I'm back to Catalyst (and I plan to talk about my feelings about the attribute-based dispatcher soon) because I feel safer. A lot safer. I know that there are other people out there that depend on Catalyst every day and in with big sites, much bigger than mine. And I trust the Cat developers not to break my code.

I do hope to see Mojo 1.0 soon, and I hope it goes well for all the gang at #mojo, but I will also look for some form of backwards compatibility policy before I even mention Mojo ever again in my presentations about Perl.

My analysis: I like the price, the battery life and the screen size. I would like to have a webcam for Skype, but that wasn't meant to be. Maybe next time.

I'll buy one, probably the 32G WiFi-only. It will replace my 17" Macbook for the non-work-related tasks that it does now.

I keep my iTunes, iPhoto, and other media stuff on my desktop Mac at work, and I travel around with the Macbook. Its a pain to keep these media libraries synchronized with the laptop, but its painless to do it with the iPad.

For most of my travel, I should be able to just leave the Macbook at home now.

For work related tasks, if I can get a Remote Desktop client on it, I should be able to connect back to the desktop at the office, via my IPSec VPN, and solve small problems.

I find the concept interesting only from a technical point-of-view. All the details about a good real-time web is what passes for tech-porn around here.

But from a human point-of-view, the concept is flawed. Or at least, my own brain finds the concept flawed.

I can't keep up with a constant barage of updates. For quite sometime, I don't have a Twitter client (I only get status updates that contain a link via RSS), I stopped using FriendFeed, and I've disabled or pushed to 8+ hours all of my checks for new mail or new articles on my feed reader. The only exception to the no-real-time updates I have is my instant messenger, and a lonely IRC client on the last virtual desktop of my system.

Not that it isn't helpful sometimes, its just not a good way to consume knowledge and information.

There are two very different concepts here: up-to-date information and real-time awareness.

I want the real-time web to succeed because it creates the necessary infrastructure to have up-to-date information in real-time, but I don't want to have the awareness of those updates shoved at me.

In an ideal future, you would have an application that sits on your mobile device, your smartphone or your tablet, that helps me manage the real-time stream. Some of my friends, Nuno and Pedro, call this application Exocortex.

Your Exocortex would subscribe to all your news feeds, your email, your Twitter/Facebook/Whatever stream. With the real-time web infrastructure in place, it would be constantly being updated with the latest information. He does not interrupt your concentration, he doesn't require your awarness; he just collects, organizes (preferably by learning what you like, and what is important to you), and indexes all. It fetches pages mentioned in the articles that you get and caches them (I find that I often click on the links but rarely follow to the second level).

Most of this happens locally on the device. It is a ecological crime not to use your local CPU. The cloud should not be CPU and storage outsourcer, but a meeting point and backup destination. Not the main point of consumption, but the backup destination. And yes, some business models would stop working.

Then, when you take your device, you get an interface into the latest trends, articles, web pages mentioned, all from the inside of your little information world, powered by your personal social network.

You can be offline and still see the latest information up to the moment you disconnected. Everything is cached locally, and if something is missing, you can pin it for later retrieval. I like to call this "close the laptop and go"-scenario. No need to sync the latest version.

So I welcome the real-time web, not because I want to be bothered every time someone farts on Twitter, but because I just want to take my iPad and go.

Giving thanks, like Christmas, doesn't need a special day, and for us perl hackers our favorite team, the perl-porters, giving thanks couldn't be easier.

So lets all, no matter where you are, run the perlthanks command line today, and celebrate our new schedule for Perl5 releases and happy days and long lives to our pumpkins.

On a more individual note, I can't forget three little big persons: cog, ambs and Magda. YAPC::EU raised the bar on so many levels.

But we don't live without CPAN, and so we acknowledge the PAUSE and CPAN teams, and all individuals that keep the mirror network up and running.

Finally, to those teams that make my day-to-day simpler and fun: the Moose cabal and the Plack gang (with a note of envy for miyagawa productivity...).

To all, a very big Muito Obrigado.

The small work I did was to start a script that converts a directory of files into a RSS or Atom feed.

For now it sits at the app-files2feed repository. I need to fix the last bugs with enclosure support and add documentation before releasing it to CPAN.

Non-perl work sucks.

I've added more commands to test (courtesy of code "borrowed" from SD, and the Launchy gem), and made the test suite more robust in case we don't find a suitable command.

<rant>
I'm amazed that something as simple as opening a URL is such a complicated task on most UNIX-based systems.

I have a single command to use on Mac OS X and on Windows based systems, but there seems to be no standard way of doing this simplest of things on UNIX systems.
</rant>

I need to tweak my server setup to be a little bit faster loading all this javascript, so you might notice a delay before the highlighter does its job.

Before each commit you should run the full test-suite of your code. If your test-suite has grown so much that it takes a long time to run, it makes more sense to run a smaller part of it, and let the continuous integration system (you do have one, right?) report back any problems with your tree later.

At the very least you should make sure that all your modules compile correctly. And that means checking the 00-compile.t test file.

To make the whole process automatic, I use the following pre-commit-hook:

#!/bin/sh

## Set any ENV vars that your test suite requires here

exec prove -l -Q t/00*

I usually write a script called my-git-pre-commit-hook and exec that one from the .git/hook/pre-commit file, this way I can run it by hand if I need to.

I also assume that all tests named 00-* are important enough to run before each commit, which lets me add more specific tests at any point.

This solves half of the problem. I also don't want to keep editing the 00-compile.t file each time I add another module to my project. So I wrote it like this:

#!perl

use strict;
use warnings;
use Test::More;
use Path::Class;
use File::Find;

my $lib = dir('lib')->absolute->resolve;
find({
  bydepth => 1,
  no_chdir => 1,
  wanted => sub {
    my $m = $_;
    return unless $m =~ s/[.]pm$//;

    $m =~ s{^.*/lib/}{};
    $m =~ s{/}{::}g;
    use_ok($m) || BAIL_OUT("***** PROBLEMS LOADING FILE '$m'");
  },
}, $lib);

done_testing();

This code uses File::Find to list all the .pm files in your lib/ directory, and then tries to use them. It also use submodules before using the main module, courtesy of the bydepth switch.

If a problem is found, it immediately bail out of the entire test suite, mentioning the file that has problems. On previous versions it would test all modules and only bail out at the end if any had problems. I found that version less productive because the same problem would be reported multiple times.

This works out fine for my projects. It adds at most a couple of seconds to each commit (in the current project it adds less than 4 seconds) but I find that acceptable.

It would be interesting to write a 00-test-commited-files.pl file that would look at the files being updated by the commit and run the tests that cover them. This could be done with the help from Devel::CoverX::Covered but I haven't done it yet.

I tried several times to enable CPAN::Reporter but I always found that it delayed just enough of my workflow that I found it a nuisance. After each test phase, it would start a SMTP connection and send the report. Those 3 or 4 seconds where a bit too much for me.

After a bit of reading I found a good compromise to report my test runs without affecting the performance. The setup is simple: make CPAN::Reporter write the test results to a directory and create a command to send them later.

To set this up, first you install CPAN::Reporter as usual and then you tweak the configuration to store the reports in a directory. My ~/.cpanreporter/config.ini looks like this:

email_from = "Pedro Melo" 
edit_report = no
send_report=unknown:yes fail:yes pass:yes na:no

transport=File /Users/melo/.cpan/reports

The trick is to use the File transport. You configure it with the directory where the test reports will be stored. In my case I choose /Users/melo/.cpan/reports. You need to make sure that directory exists.

From now on, every time you use the cpan shell to install a module, the test reports will be stored in you test report directory.

The final step is sending them. I wrote a simple script to take care of that, that you can find on my scripts repository: x-perl-send-test-reports (download).

How and when you run it is up to you. You can run it manually from time to time, or from a cron, or use something like folder actions to monitor the directory and start the script whenever a new file is placed there. I run it manually for now.

My command line to use the script is this:

x-perl-send-test-reports         \
    --from melo@simplicidade.org \
    --server smtp.gmail.com      \
    --transport 'Net::SMTP::TLS
         User melo@simplicidade.org
         Password my_password
         Port 587'               \
    ~/.cpan/reports

So one less excuse not to report your test results. If you are not using CPAN::Reporter, start now.

Almost 6 months later I can report that it works great, you don't notice it at all. Strongly recommended, if you need this sort of thing.

But there are no completely secure software-only solutions, and its good to know the limitations, like the "Evil Maid" Attacks on Encrypted Hard Drives.

The comments on the article are also worth a read. There are some proposals in there that might work and defend against this kind of attacks.

A former colleague of mine at PT had a small reporting problem, and he ended up comparing several languages for the job: C, Perl, PHP, and Python.

I was curious about the results, so I took the latest version of the Perl script that he was using and set off to work.

The first thing that you should be aware is where your bottleneck is. Take a look at this small script:

#!/usr/bin/env perl

use strict;
use warnings;

my $lines;
while () {
#  my @fields = split / /;
  $lines++;
}
print "$lines\n";

A basic line counter. Compare it to the system wc:

$ gzcat nfsd.gz | time wc -l
 12236390
       16.86 real        16.24 user         0.43 sys
$ gzcat nfsd.gz | time ./wc_simple.pl 
12236390
       10.13 real         8.51 user         0.84 sys

So, a bit faster than the C version, doing 1.2M lines per second on my laptop.

But if you remove the comment on the split(), we have:

$ gzcat nfsd.gz | time ./wc_simple_with_split.pl
12236390
       228.78 real       224.39 user         2.34 sys

A lot less: 53k lines per second.

So the first bottleneck is the split(). Lets improve on that. After some attempts I came up with this:

my $lines;
while () {
  my ($ts)    = /^(\d+)/gc;
  my ($type)  = /(\w)\sV/gc;
  my ($op)    = /\s(\d\d?)\s\w/gc;
  my ($bytes) = /\w\s(\d+)\s/gc;
  $lines++;
}

I make use of the gc flags to start the next match where the previous one ended. I also take advantage of patterns in the lines that I need to match, like the V in the NFS version.

With this version we get:

$ gzcat nfsd.gz | time ./wc_simple_with_regexps.pl
12236390
      109.62 real       107.42 user         1.55 sys

A bit better: 111k lines per second, a bit over 2x the previous result.

If we apply this gain to the reported times for the Perl script (419m11.267s), we get 200m49.97 which places Perl 1st, even above the C version by a minute or so.

My adjusted version of the stats_basic_optimized.pl script is melo_stats_basic.pl.

This was good enough I think, but I wanted to study the I/O gains that could be made. Stop reading here if you are already bored, it will only get worse. We did manage to get a few more minutes back, though... ;)

So I went after the I/O performance. Fist I wanted to rule out the pipe as the bottleneck.

$ cat /dev/zero | pv | cat > /dev/null
4.61GB 0:00:10 [ 498MB/s]

$ gzcat nfsd.gz | pv | cat > /dev/null 
1GB 0:00:04 [ 242MB/s]

So the pipe is not the bottleneck but we will never reach the full speed, gzcat will be our limitation.

I did try to read the gzip file directly into the Perl script and uncompressing it there, but it was very slow.

So assuming a limit of 242MB/s on the input side, how fast are we chopping lines? The size of the input is 1073743224 bytes, and our simple wc_simple.pl (no split, no regexp) took 10.13 seconds above, so we are chopping the input at a rate of 101MB/s.

So there is room to grow there (101MB/s to 242MB/s). I did some experiments:

$ gunzip nfsd.gz
$ time wc_simple.pl < nfsd
12236390

real    1m23.212s
user    0m7.434s
sys 0m2.166s

Yeah, the file doesn't fit in the cache like the gziped version, so there is real I/O, and the times go through the roof.

There is no point doing experiments with the big nfsd file. All of them will result in real I/O, and that is always slower than memory.

Lets try to do bigger reads and parse the results:

use strict;
use warnings;

my $size = shift || 2 ** 20; ## 1Mb default
my $offset = 0;
my $buf = '';
my $lines = 0;

while () {
  my $n = sysread(\*STDIN, $buf, $size, length($buf));

  while ($buf =~ /.+\n/gc) {
    $lines++;
  }
  last unless $n > 0;

  print "$lines $n\n" unless $lines & 0x1ffff;
  $buf = substr($buf, pos($buf));
}
print "$lines\n";

I tried several block sizes but with my OS the most I could read in one call was 64k. So asking 1MB and getting 64k reads we get:

$ gzcat nfsd.gz | time  ./wc_batch.pl
12236390
    8.37 real         7.52 user         0.58 sys

We get 1.46M lines per second, a 17% improvement. Lets adjust to retrieve our fields. The inner loop becomes:

while ($buf =~ /(.+)\n/gc) {
  $_ = $1;
  my ($ts)    = /^(\d+)/gco;
  my ($type)  = /(\w)\sV/gco;
  my ($op)    = /\s(\d\d?)\s\w/gco;
  my ($bytes) = /\w\s(\d+)\s/gco;

  $lines++;
}

and the runtime:

$ gzcat nfsd.gz | time  ./wc_batch_with_regexps.pl
12236390
   95.58 real        93.21 user         1.14 sys

So from 109.62s to 95.58s, 12% better (or comparing with our baseline wc_simple_with_split.pl at 228.78s, 58% better). Adjusting this to the reported results we would go from 419m11.267s down to 175m5.6842s.

I don't think I can improve on this unless we can have a bigger pipe reads. For example, forcing the reads to 8k:

$ gzcat nfsd.gz | time  ./wc_batch.pl 8192
12236390
       12.08 real        10.93 user         0.70 sys

A lot worse compared with the 8.37s we got with 64k reads. So the size of the pipe is the next factor we could explore, if that is even an option with your kernel.

But I'm happy now.

The next day

Or so I though. First there was doubts that the split() was faster than regexps. I wrote bench_splitters.pl (output on my laptop, download link) to compare split with my regexps. The regexps are a bit over twice as fast, but I found big differences between the Mac OS system perl (5.8.8 on my Leopard OS) and the 5.10.1 that I compiled: system perl was between 20 and 30% faster.

The same bench_splitters.pl gives you the max rate of extraction that you can expect from the global script. I also included timing of the bookkeeping parts of the original script. The only noteworthy detail is the fact than when you hit the second level condition, you pay the price of the modulus operator big time. I also think that something is wrong with the input. Those time stamps don't look like normal second-precision time stamps. They are too big. So I don't know if $ts % 3600 is the proper way to group performance by hour.

Second I wrote a max_line_rate.pl (output on my laptop, download link) that gives you the upper bound on the max rate that you can expect while parsing the required fields. You can run this script, and stop it at any point in time with ctrl-c, and it will print a performance report up to that point. Every 128k lines, a single line performance report is also printed.

You can use this max_line_rate.pl to compare your system perl with the 5.10.1 you compiled. I had much better performance with 5.8.8 in this particular application.

Finally I rewrote the statistics script. I did that to deal with the report that my previous version was consuming 7.5Gb of RAM. The reason is simple enough: I don't have access to the original input, only to a six-line excerpt that was posted. Therefore the regexps I use to extract the required fields might fail.

The new script, fast_stats.pl (output on my laptop, download link), is more robust, and should deal with lines that cannot be parsed: it will print the line that couldn't be matched and ignore it. Also: I've included the output of the ps command at the start and end of both fast_stats.pl and max_line_rate.pl to show that the RSS doesn't change that much.

To compare the original stats_basic_optimized.pl with my fast_stats.pl I wrote a small shell script bench.sh (output on my laptop). The nfsd.gz input file was generated with the build_source_file.pl script with the command:

build_source_file.pl 1073741824 | gzip --best > nfsd.gz

The new fast_stats.pl is almost twice as fast as the old one on my laptop.

On a final note (I wasted too much time already on this...), I'm not out to compare Perl with Python or Ruby or even PHPO. But I would like to know how we measure up against C though. The reason is simple: when Perl programmers feel that something is slow, they turn to C, not another scripting language.

This experiment is mostly to show that writing fast perl will sometimes take you to unexpected paths (like regexps beating a split), and that you should benchmark carefully if performance is critical to you.

It takes a single argument (can be a module, distribution, bundle or author name), checks the CPAN indexes to see which type it is, creates the proper URL for it at search.cpan.org and opens your browser with it.

The last bit, opening a browser with it, is very very immature. Right now it only works on Mac OS X. I'm hopping to get the experience to do it right from the Browser::Open distribution.

If no object is found, sends the user to the generic search interface.

The current hackish implementation can be found on my s_command topic branch (its a topic branch, I will rebase it on occasion onto master).

It does one simple thing: given a $url, it opens the default browser with it.

The difficult part is deciding how to open the "default browser". On Mac OS X, this is easy: just execute the open command.

On Windows, there is a start command that should do the trick, but I'm not a Windows user so I cannot test this. Any Windows users out there that can point me to the relevant information on how to open a URL with a simple command, I would appreciate it.

For Linux, you have too many choices it seems: you could use gnome-open but your user might be using KDE. There is a xdg-open command described at the FreeDesktop site that seems to do what I want. We can always fallback to firefox though. Fragmentation++!

Anyway, you can download the Java 1.6 update for Mac OS X Leopard from the Apple Software site, but its only 64-bit.

I do have a desktop that is 64-biT, unfortunately my Macbook Pro laptop is only a 32-bit Core Duo. Hence, I cannot run the new version of Java.

If you do have a 64-bit CPU, and after you install the update, you might want to switch the default version of Java to 1.6. To do that, the proper way to do that is to run the /Applications/Utilities/Java\ Preferences.app and drag the 1.6 version to the top of the list.

I just wanted to try out Jake... Guess I wont be able to, at least not until I can get my hands on the wife's laptop... hmms... she's sleeping already...

Let me just clarify some behaviors for non-background jobs:

• the worker will execute the job until it finishes even if the client that submitted it dies;
• if the client dies before the job is passed on to a worker, it will be removed and will never execute.

For background jobs, the behavior is different: a client submits a background job, the gearmand daemon queues this (on stable storage if you use the persistent queues of the latest versions of the C implementation), and sends it to a worker as soon as one is available.

This is basic stuff, I'm just making sure we are all on the same page regarding Gearman behavior.

Back to the the unique parameter. You can define a unique key for your jobs. Those keys should be unique per function, so you can have the same key on different functions and they will be two different jobs.

The fun part with unique is that you can have multiple clients listening to status and completion events of the same job if you share the key between them. Say that you start a job with a key alpha. If other clients submit a job with the same key, and (and this is an important) the job is still running, this second client will attach itself to the same job.

To test this I wrote a small shell script worker (save it as slow.sh and make it executable with chmod 755 slow.sh):

#!/bin/sh

echo "Starting a slow worker..." >>/dev/fd/2
for i in 5 4 3 2 1 ; do
  echo $i >>/dev/fd/2
  sleep 1
done
echo done $PID

This worker does nothing expect print to STDERR a count, and then sends to the client a done string with the worker process ID. But it takes 5 seconds to run so it allows us some time to switch between windows.

After you start your gearmand server (I used gearmand -vv just to have some debug) you can start a worker process like this:

gearman -w -f slow ./slow.sh

This worker registers the slow function and will execute the slow.sh per job.

Now open two new terminal windows and type on each one:

gearman -f slow -u alpha -s

This will submit a non-background job for the slow function, with the unique key alpha. The -s means that we won't be sending any data.

You'll see one execution of the worker, and then both clients will output something like this:

done 57998

You can experiment, and attach the second client only half-way through the worker run. Or you can stop the worker, start both clients, and then start the worker. The result will be the same: both clients receive the output for the same job.

This is a very very cool feature, and can be used easily for slow processing inside a web request.

First, if a web request requires a slow processing phase, we store all the relevant data and submit a background job to do the processing with some random key. The user receives a "Processing page" on his browser, that includes this key.

A small javascript program using AJAX, connects to our long-pooling server and submits a non-background job to the same function and using the key. This second client request will now wait until the processing is done, and can even receive status updates from the worker and send them back to the browser.

This attach-to-job-using-key is very reliable. I've tested several combinations with and without workers running, strange order of job submission, adding multiple clients to the same job, and all of them work as expected.

The only real problem with this is that the clients need to use the same API that is used to submit a job. Instead of a new API, like ATTACH_JOB for example, you use the same SUBMIT_JOB API that you use for new jobs. This works fine, until your second client attaches with a key for a job that has already ended. The gearmand server will fail to find it, and will dutifully create a new job.

My current workaround for this is to send a specific payload on the attach requests, to signal the worker that this is a attach request and not a new job. The worker, if he detects this signal, just ends the processing. For example, if your jobs require payload data, you can use an empty data field as the flag.

This is not optimal of course, you would be waking up workers just to return immediately, but it would work.

If you have multiple gearmand servers, you need to make sure that the clients that will be attaching to a job use the same server. A solution would be to pass the server identification (IP or even better hash-of-IP) along with the key.

The traditional way of doing this is have the workers store the completed result in a database somewhere. The solution presented here does not invalidate that, it only provides a very light notification of completion to background jobs. It beats pooling the database to see if the background job is completed.

What he wants is a way to tell CPAN this: "install the latest versions of my dependencies".

His solution wont work unfortunately. The code that he gives us will prevent the Task:: module from being installed but it will not guarantee that the latest version of the prereqs will be installed in the following runs.

the reason is simple: if you don't ask for a specific version of your prereqs, CPAN will accept any version, so it will only install each prereq once, the first time.

The perfect solution would be to create a marker on each prereq that would tell the CPAN tool chain that you want the latest version. This does not exist yet. You could probably standardize on version -1 meaning the last one (on a twisted parallel with the last index of Perl lists), but its all speculation. Its just not supported yet.

The next best thing would be to include the version required on each of your prereqs, and keep those values up-to-date to the latest available on CPAN whenever you rebuild your package.

This is a half-way solution. It wont guarantee the latest version at the time your package is installed but it would make sure you get the latest version at the time your package was built on your system before uploading to PAUSE.

This is actually a good compromise given that you are probably listing the versions of the prereqs that you tested your package with on your system.

And, better yet, this half-solution can be automatized. I wrote a Dist::Zilla plugin to do just that. The code is very simple and you can just adapt this into a Module::Install plugin or whatever you use to build your packages.

You can find the code for Dist::Zilla::Plugin::LatestPrereqs at my Github repository for Dist::Zilla tools. Its not on CPAN yet, and for now there are no plans to publish it. The reason is simple: it requires a small patch to the core Dist::Zilla. The patch is a single commit that you can find on Dist::Zilla fork. I've asked Ricardo Signes to accept the patch. If he likes the code, I'll release my plugin after the next Dist::Zilla release.

If you look at the LatestPrereqs code, you'll notice that it is very simple, but it does load the CPAN package and that is a big one. You could write this code directly on your Makefile.PL and have the very latest versions of your prereqs at install time, but this would assume that the system as a properly configured CPAN.

That was a risk that I'm not willing to take on my distributions. If you do it that way, ping me. I would like to follow your module CPAN Testers feed for a while.

Back to Marcel post, if you do need to prevent the install phase for your distribution, then I've also uploaded a Dist::Zilla plugin to do just that: Dist::Zilla::Plugin::MakeMaker::SkipInstall. It might be handy sometimes.

This was a long time coming unfortunately, and I accumulated FAIL test reports on CPANTS, but its here now.

Given that it uses the latest Mojo release, it supports HTTP keep-alive and pipelining, chunked-encoding and 100-Continue requests.

Although the test suite passes, I'm not fully confident on the pipelining code. My next step is to write a client with a slow network reader to exercise some corner cases of that part of the code. In particular, I'm concerned about the interaction of Mojo pipeline code with my request pause functionality that I use to implement long-polling servers.

It could be argued that long-polling and pipeline don't mix, but I think that the pause functionality could also be used on regular requests. For example, if one request needs an answer from a memcached server, the handler can start the memcached GET, pause the Mojo transaction, and resume it when the memcached response arrives. While that is going on, the server should be able to keep writing out previous requests, and reading the next ones.

Maybe thats a bit extreme, but I do hope to have this working, for complex pipelining situations.

But I'm a lazy bastard, and the lack of a bash completion script was getting on my nerves.

So here: you can get the new gh-completion.bash script from my repository. I've sent a pull request to Chris Wanstrath (defunkt)

Please note that this is still work-in-progress.

Right now, most of the command and options have completion, but I'm still trying to understand certain operations (like pull-request and track) that I never use. I don't really understand what they do, so I have no way to create a decent completion rule for them.

But using this bash completion is totally safe... Until you hit the ENTER key, that is.

On a regular basis, it indexes all our users, courses, teachers and other important tables. It works great, low install barrier, low maintenance, and it is very very fast. Perfect.

One of the problems that we found, that limited the usefulness of the full-text search engine, is that a lot of our text has accents, and it would be better to ignore those. Also we don't need case-sensitive-ness.

So I needed to generate a charset_table map, what Sphinx uses to normalize the text that you give him to index.

And being a (very) lazy person, I prefer to write a Perl script to do it. The result is the x-sphinx-charset-generator, now part of my script stash.

It takes an optional parameter, the charset that you are using on your text defaulting to 'utf8', the loose version of UTF-8, and generates a charset_table for the most common accented characters, mapping them to the lower-case version of the same letter without the accent.

I've only include the common Portuguese characters. Patches accepted for others characters that you might need.

The only part that I don't really like is that I need to apply the same logic to cleanup the strings that users use to search. I would prefer to have a module that would take the characters that I want to allow as valid, and have that module provide the charset_table and a function to clean search inputs. Interesting, but for now this will solve the important 80% of the problem.

The usual command you would use is something like this:

gunzip -c db-backup.sql.gz | mysql -udevuser -ppass db_dev

If your dump is big this can take a while and you wont have a clue about what is happening.

Instead, install pipe viewer and do:

gunzip -c db-backup.sql.gz | pv | mysql -udevuser -ppass db_dev

and you get a nice speed meter. For even better results:

dump=db-backup.sql.gz
size=`gunzip --list $dump | perl -ne 'print "$1\n" if /\d+\s+(\d+)\s+\d/'`
gunzip -c $dump | pv -s $size | mysql -udevuser -ppass db_env

and you'll get a speed meter and an ETA. The second command will get the uncompressed size of the dump and use that to teach pv how much data to expect.

Pipe viewer rockz.

At the time, we used HTML::Mason 1.05, and only after 1.30-ish (when the internal buffering changes introduced in the 1.10 release where reverted) did we upgraded to something more recent. To get an idea of the size of this Mason project, the current sites have a little over 450 different components across 7 sites (different layouts but same content) and 1 management site. A lot of those components are no longer in use, and where left there due to bad VCS practices. I would estimate about 200 actual useful components. And it makes heavy use of autohandlers, dhandlers, and multiple component roots, to implement site inheritance.

The E5 template discussion is also still on my mind, without a clear winner yet.

And finally, last week I read Jonathan Swartz article about what Mason 2.0 would look like.

So I took the time last night to re-evaluate Mason. As most powerful tools (and be sure that it is a very powerful tool), the problem with Mason is that you can easlly make a big mess of things. More than with other solutions like Catalyst and Mojo, that provide you with a clear separation of Controller, Model and View, Mason make is very easy to mix the three. You could end up with a lot of logic that should be in your models inside your templates.

But it has several advantages:

• its easy to start and add a new page. Just create the file and start typing: no need to jump between controller and template, and a restart (this alone makes for speedy development);
• it has decent wrapper functionality for skinning: autohandlers are great;
• the multiple component roots logic is very powerful, and its used both during the dispatch phase and component calls;
• the view logic is Perl: no need to learn a new language and be exasperated with their limitations like TT.

There are several downsides of course: for one, the split of Controller/View of modern frameworks allows you to reuse controller logic with multiple views. For example, you could output HTML, JSON and XML with the same controller code.

But the biggest downside is this: deployment is a bitch.

For production environments, deployment usually means mod_perl but I find FastCGI easier to deploy now-a-days. Yet, this option is only briefly mentioned on the MasonHQ site.

So I created a small experimental project (you can find all the files at the exp-mason-fcgi project on GitHub). It has a FastCGI startup script to power two virtual hosts. Each one shares a master component root, and has a local per-site component root to override the master site behavior when needed.

The setup works just fine under nginx+FastCGI (partial nginx.conf included), but I did get into some trouble. Mason usually delegates some stuff to Apache and without his big daddy around, he can get lost.

The first problem is directory index files. When you request a directory, Apache will help Mason out and point it to the proper index.html file. Without Apache, request to http://your-fastcgi-mason-site/ will just fail, because Mason cannot find the component for /. It has no logic to map / into /index.html for example.

You could implement this with a global dhandler, and it is probably the best solution, because it can also deal with 404 situations (another one that Apache could cleanup after).

I have a proof of concept hack in the repo that mimics the Apache DirectoryIndex directive. It is a hack, it should be in the Interp.pm and not in the Request. I'll clean it up later. But it does work, and it might be useful in some scenarios.

This patch makes a / request work just fine.

The second problem I have with Mason is the order of evaluation of templates. The current order for a request to /index.html is /autohandler which calls $m->call_next and that calls the /index.html component.

This makes it hard to influence the wrapper with content generated by the /index.html component.

The solution was to create a new HTML::Mason::Request method called scall_next(). It merges the $m->call_next() and the $m->scomp() calls into one, and allows me to use it in a autohandler like this. The $m->scall_next() will call the next component, get the generated HTML, and only then generate the HTML wrapper.

The last piece of the puzzle is a way for the /index.html and the parent autohandler to communicate, for example, to pass along the title for the page.

The Mason-recommended way is to use $m->notes() API, similar to the Catalyst stash concept. It works very well, but I prefer to take advantage of the fact that all components live inside the HTML::Mason::Commands namespace and just declare a shared %stash there and clean it up per request. With this, its easy to implement dynamic page titles.

All in all, I keep coming back to Mason. I do like most of what it provides, and for quick sites, it beats all the other alternatives in Perl-land.

A couple of months ago there was some discussion about a option to give web developers that was FTP friendly, in that you could upload your pages to a server and it would just work. Mason is the closest that Perl has to that goal.

But the deployment must be made simpler, and that I one of the things that Mason 2.0 should focus on: make it simpler to deploy.

So my laundry list for Mason 2.0 (and most of them can be implemented on 1.x):

• FastCGI support out-of-the-box;
• support for directory index files (without using dhandlers);
• $m->scall_next;
• better hooks for debugging and 404 errors.

I don't know. I'm strongly considering go Mason all the way for E5, and if that goes forward, I guess I'll have to write these four pieces myself.

I used the following test case to figure it out:

use Test::More tests => 1;
use Encode qw( encode decode );

sub u8l1 {
  return encode('iso-8859-1', @_);
}

my $ola_u8 = decode('utf8', 'Olá');
my $ola_l1 = encode('iso-8859-1', $ola_u8);
is(u8l1($ola_u8), $ola_l1);

The output of prove x.t is this:

t/x.t .. 1/1 
#   Failed test at t/x.t line 12.
#          got: '1'
#     expected: 'Ol?'
# Looks like you failed 1 test of 1.
t/x.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

The got: '1' had me for quite some time. Until I changed the u8l1() helper to this:

sub u8l1 {
  return encode('iso-8859-1', $_[0]);
}

And it just works.

The problem is the definition of the Encode::encode() function. It has a prototype like this:

sub encode($$;$)

So our @_ is interpreted in scalar context, and so evaluates to the number of parameters, 1.

I don't like it at all because it changes the standard Perl behavior of expanding lists. Its action at the distance. The fact that you cannot pass a single element list is also not mentioned in the documentation.

The only really useful use of Perl prototypes is using a & as the initial char, that allows you to write a function that looks like some built-ins like sort or map, that take a anonymous sub as the first parameter.

I have only one question: who was the monster stupid that cancelled this show? What was he thinking?

One thing that we inherited from log4j was the notion that a message can match multiple loggers in your logging hierarchy.

The logic is simple and explained in detail on a Log::Log4perl FAQ entry. If you write something like this in your logger configuration file:

log4perl.logger.Cat        = ERROR, Screen
log4perl.logger.Cat.Subcat = WARN, Screen

which define two loggers. Cat and Cat.Subcat, the second a subcategory of the first, and then use:

my $logger = get_logger("Cat.Subcat");
$logger->warn("Warning!");

you'll get a duplicate message in your log file because it matches both loggers.

I knew that and I always added a line saying:

log4perl.additivity.Cat.Subcat = 0

that prevented this behavior, but this required a line like that per logger. Pain. Not lazy, at all.

But for some reason (stupidity comes to mind) I didn't read the FAQ completely, because at the end, there is a solution. Just put this in your logger configuration file:

log4perl.oneMessagePerAppender = 1

Bliss, pure bliss.

Mind you that oneMessagePerAppender is not compatible with log4j, something that Log::Log4perl tries very hard to be, and therefore this feature is not documented at all except on this FAQ entry.

But with my hands going about their bussiness, the corner of the paper starts to bend upwards.

The solution is not rocket science. A simple paper clip.

Problem solved.

It might not have a comparison between riding a manta ray or riding a air-powered submersible thingie, but it shouldn't be too bad, given the two names associated with it.

This takes a lot of time, but I had most of the process already in auto-pilot.

But still it was a hack, so I decided to take the opportunity of the 5.10.1 release and make something more pretty and reliable.

The result is my Perl bootstrap repo.

There are two scripts. The first, bootstrap.sh, will install the local::lib module and prepare the environment. Its still not finished, it doesn't alter the .bashrc file, but it will get there.

The second, install_deps.sh will use the cpan shell to install a local Task::Bootstrap module. This Task has all the modules that I want installed.

There are still some problems. I still lack some distro prefs for a couple of them that pause the process and ask for user input. And some of the modules won't install without force (Mac::Carbon is the one that fails the most).

Other modules just don't install correctly on Mac OS X. Danga::Socket for example, requires Sys::Syscall, but this one fails the tests because Mac OS X lies about sendfile support: the sys/syscalls.ph includes the SYS_sendfile constant, but when you actually call it, we get a Function not implemented. I'm sure I could work around it, and probably fix it, but I no longer use Danga::Socket so I'll probably just remove that dependency.

The other was Mac::AppleEvents::Simple. Finder.app has a different naming scheme for its windows, and t/simple.t was failing. I've send a patch to the module RT Queue.

I still have small failures, but right now, I can mostly use this two scripts to setup a Perl environment from bare metal.

Update: I removed my ~/.perl5/5.10.1/ directory and ran time ./bootstrap.sh. The results:

real 56m4.598s
user 37m17.724s
sys  7m51.923s

So about an hour on a MacBook Pro 2.16Ghz Core Duo, running Leo.

Today the company has over 200 persons working there, keeps sharing their technology with us all, gives us access to a bunch of very cool APIs, and invites us to have fun from time to time.

I was lucky enough to work there for a couple of years, and do hope to do it again sometime in the future, it was a lot of fun.

For now, a really big happy birthday to SAPO.

You upgrade when:

• you have half-day of free time to do a clean install;
• all your must-have apps support the new version;
• any of your must-have apps requires the new version.

I usually wait until the last item is true before doing the upgrade.

When I started using them at work (circa 1998 or 99) the goal was simple: separate programmers logic from the layout so that designers can tweak the templates without breaking the code.

It was a simple and very worthwhile goal. And for the most part, it worked. You still need to coordinate which templates will be created, and how will the page be broken up into pieces to enable reuse of common parts, but it mostly worked.

The template systems where designed to be used by web designers, and given that those where accustomed to HTML tags, the more powerful template system that needed loops and decision constructs opted to create those with a simple syntax. The template systems became domain specific languages (DSL).

But, with the improvement of the HTML, CSS and JS capabilities, I don't know if the designers are still the target audience of template systems. As I split a set of HTML pages into a set of reusable templates, I try to create blocks that make sense in terms of caching, data-store life cycles, and other subtle factors that a web designer just doesn't care about. The page breakout is becoming a engineering exercise.

As programmers/engineers, we don't need the comfy world of a DSL. We want to work in the same language that we use to code. Templates are, at most, a small macro language that gets compiled into source code, in the same language that we have the rest of the system.

So I'm starting to move away from Template Toolkit, my preferred template system, into something that uses native Perl as the DSL. I don't know where I'll end up yet. I'm looking at Tenjin, Text::MicroMason, and Mojo::Template. There aren't many template systems that use Perl as the control language, actually.

The first two should be the most stable ones, older ones. Tenjin is also the fastest template system I've tested, although speed wouldn't be a deal breaker.

Controller-centric or View-centric render process

But we can't judge template systems without considering where and how they will be used. In my case they will the last step of a web request, handled by a web framework.

I'll use a BBC site page to illustrate my current dilemma, an article about Wikipedia page controls. Things of interest to me:

• the central part of the page is the main content, and directly related the the URL. This is the content that you came here to get. It has a lot of HTML before and after that are present to add value to the site (we hope), and provide exit destinations (the navigation and related stories);
• the title of the page, early in the HTML, is also directly related to the URL and the story: this is important because the template system must support inside-out rendering (first the central part, and then the wrappers), or have all the information in memory before starting the render process;
• some parts (the header, footer, and left-hand sidebar) are mostly static, and with low or no relation to the main content: in this case only the category of the article influences the navigation. It might also influence the related BBC sites;
• the right-hand side shows related stories. The "related" part might be highly dynamic, or static per category or a mix in between. The related external links are probably part of the story.

The path for a typical request (like /2/hi/technology/8220220.stm) looks like this:

1. collect all the important data from the URL: in this case the it seems to react to the hi/low part to pick the version of the master template, the category (controls the right-hand side column) and the article ID;
2. fetch the correct article and related informations (author, publish date, picture URL, caption...);
3. fetch the related articles for the right-hand sidebar;
4. call the view renderer with all of this.

Pretty basic and straight forward. Steps 1, 2 and 4 don't pose to many questions, they are required on any pipeline I can think of.

But the proper way to do 3 is a matter of discussion. On one hand you can put enough information on the URL to decide what the right-hand sidebar needs and fetch it in with some calls inside the Controller (I'm assuming here a MVC-style framework). In this model the controller prepares everything that we need to display the page.

But this makes the view a bit inflexible because if we need to had another box the top or bottom of the page, we would need to tweak the controller code.

On the other hand if our template system is powerful enough, we can have a small API that we can call back into Perl land, and have these little reusable boxes generated for us. The view controls the entire process of display.

The advantage of having a decent view system, even a object oriented view framework, is the extensibility that you get. Imagine a Moose-based template system: view are classes that you can extend, override, add before and after processing. Rendering is just creating an instance and calling a small method, as_string() or even stream_to_socket().

A system that brings the full power of Perl to the template world is Template::Declare. It treats templates as classes that you can subclass and extend. It seems very similar to what I like but I have zero experience with it so far.

No decisions have been made yet. I need to evaluate Template::Declare and see if it really fits my brain.

A beginning is the time for taking the most delicate care that the balances are correct.

from Manual of Muad'Dib by the Princess Irulan

extracted from Dune, by Frank Herbert

In the next weeks I'll be publishing a series of articles about a new project that I'm starting. Actually, I started this project once already, but I didn't like the path it was taking, so I'm restarting it.

The new system will replace the current EVOLUI.COM code base. Why rewrite a system that is in production for 8/9 years and that works reasonably well? There are several reasons actually.

The first reason is code rot: the current system is spread across 3 code bases (called internally E1 through E3). E1 was the first stab (who would guess, right?), and grew organically inside the company, without much planning, and coded by several programmers. E2 added a better management interface, and E3 added a new LMS and forum system.

A lot has changed in the last 8 years. And my inexperience in certain topics shows by the lack of proper tests and documentation. Also, it has grown to 850 Perl packages. Yes, eight hundred and fifty packages. I expect that more than half of those are no longer in active use.

The second, and more important reason, is that the new business requirements require a deep restructuring of the code, but given that we don't have a decent test suite, it would be madness to change stuff in one of those 850 packages.

The way I see it, I can write the new system properly, using a test-driven methodology, making sure that all the business logic is properly tested.

I'm not starting from scratch, I plan to reuse certain small but critical parts of the old system, but going over them to add tests and documentation.

The failed attempt was called E4, so this new version will be called E5.

I plan to cover the following topics (not sure of the order yet):

• source control, and ticketing systems;
• project directory layout;
• documentation techniques;
• business layer techniques;
• databases used and ORM layers;
• web frameworks;
• template systems;
• logging;
• smoke testing;
• deployment.

Hope you enjoy the ride.

But at the place where I usually do my mid-day walk, near the see, there was a strong wind, blowing from north-west.

Just perfect to stretch the legs, listening to some music. Must find some time to go back there today.

Thats what just happened around here, and I'm slowly returning to work.

Parrot’s record for a language implementation was a conference session where the speaker implemented the basics of the LOLCODE language from scratch as a live demonstration. It was a 5-minute lighting talk.

I have to get the time to implement a DSL for something on top of Parrot, to see how it works. Right now I only compile Parrot to run Rakudo.

Today, a new article describes the answer he got. In the end he decided to put the validation inside the model. I can only say: good for you.

But one of the reasons against the validation-inside-the-model that he received baffled me: Models don’t know about the current user (or other higher level information).

If your models don't know who is the person authenticated (and please read Yuval article about modelling identity to understand how complex it can become), then you are doing it wrong.

Models must know who is the authenticated user. They must know it because that is the only sane way to implement authorization inside your methods, and to generate a audit log of operations.

What I usually do is to create a Session class. For each request (be it Catalyst request, incoming email message, or XMPP request), I create a new Session instance initialized with the current user information plus some tidbits like channel (Web, email, XMPP) and IP address (if available).

Then all accesses to my API are either via the session object (create methods to access most important parts of your API), or by passing this session object to the API you are calling.

You should also use your Session as the access point to your logging and auditing capabilities.

The article mentions other issues like error messages. I haven't add the necessity of developing an application with multiple language support yet, but I think that the current throw-exception-objects strategy, with all the information (including the authorized user to figure our preferred language) will be able to deal with the problems that I can think of now.

In the end, I'm actually really curious about why would people think that putting your validation code in the controllers is a good idea.

Update: a lot of stuff in the comments if you care about this topic.

I spent an hour upgrading our office server this morning. In a world of Ghz speeds, be prepared to slow down a little.

The server was a dual-pIII (yes, Pentium III, Katmai generation) at 450Mhz (yes, mega) with 512Mb RAM (at 100Mhz, in 4 DIMMs). The upgrade replaced the CPUs with a pair of pIII 500Mhz (a 11% increase, not bad), and the memory to 1Gb at 100Mhz. Basically thats the best you can hope for with this Intel N440BX (aka Intel Nightshade) board.

I don't have the full specs for either of them but I would guess that the CPU inside the new iPhone 3GS is a little faster than the pair of pIII I'm using.

The obligatory Flickr set for enthusiasts of old hardware porn.

I also uploaded a small video showing the hardware boot up, but had to use Vimeo because Flickr limits video uploads to 90 seconds, and this server takes a bit more than that just counting the RAM...

I bought this server in 1999, to power the NFS server for the first launch of the mail.pt service. It was handed down through the times, from company to company, until it belonged to me after the demise of Prodigio. At the time it used two Mylex SCSI RAID controllers (I still have them, one of them in production) with 4 x 9Gb SCSI hard drives on each.

I have a quote for a €390 upgrade to a Core 2 Quad 2.8 Ghz with 8Gb RAM. I plan to do this sometime next month. But this old office server will not die. It will power a smoke server to test Perl modules with several releases of FreeBSD.

Some of their previous puzzles are very interesting like the JumblePrism or my two favorites, the RotaCubes and the Bramboules.

Oscar van Deventer creates stranger things: the WimTvane or the Topsy Turvy are just two examples

He also has a beautiful adding machine for kids.

I like puzzles. Puzzles good.

I encrypted the external FW800 500Gb hard disk that I use exclusively for Time Machine last night. It took about 8 hours. So far so good.

When I connect it to my mac, a PGP WDE dialog pop-up shows up, asking me for the correct pass-phrase. After I enter it, it shows up as a Time Machine external disk, and the backup starts.

Be aware that, in case of hard disk disasters, encrypting your TM disk can be more awkward than encrypting your internal hard drive.

With a normal non-encripted TM drive, you can boot your Mac from a Leopard DVD, and ask the Installer to restore a TM backup directly.

If you encrypt you TM disk, thats no longer an option. You have to install a bare bones system, install PGP WDE, and then restore the TM backup.

A possible solution (untested for now) is to have a clone of your internal hard drive (even an encrypted clone should work) that you update from time to time. Then you should be able to boot from the clone and restore a TM backup to the internal disk.

As I said, I haven't tried this yet. It should work, I don't see any reason not to.

I do have a clone of my internal hard drive, thats the next one to encrypt. I'll check to see if he is still bootable afterwards, and I'll try to find an extra disk somewhere to restore a TM backup.

I'm really happy with PGP WDE, works great, no surprises so far.

Until we do know more about it, we can look through the Wave protocol draft spec, and notice that its built on top of XMPP.

At the same event, the new XMPP-powered mini applications where also announced. Each one is a XML file with all the HTML, CSS, and JS files packed together. Time to see how long it will take a XMPP desktop client with access to a WebKit view to implement this extension. It reminds me all the discussions about embedded applications we had in the API mailing list last year.

It seems very good (I'm not a Hg user, so I don't really know). Lossless bi-directional synchronization.

Nice.

Casual observers initially criticised git for having a model so simple it was actually naive. It turns out they were confusing the model with its on disk representation. Git makes this distinction very well, and the result is that it implements powerful features (for instance idempotent patch application) which are apparently too complicated in other systems. Git itself isn't simple at all, the problem of version control is a complicated one so any system dealing with it is inherently complex. Git's advantage is that it's built on a very simple and future proof core, allowing the complex parts to evolve more easily.

A very nice way to put it, Yuval.

I've linked this excerpt differently. The linked Git documentation file is well worth a read, if you care about why git turned out as it did. Not that much interesting for day-to-day usage though.

I'll keep it running in case you need a guinea pig for tests.

Very good news.

Bootstrapping local::lib was reasonably simple but it got a lot simpler with the latest 1.004001 version. Basically you can just pipe the output of a URL into perl to bootstrap it.

The URL is some long beast in the cpansearch.perl.org site, impossible for me to memorize, so I created a shorter version, http:://bit.ly/local-lib. To bootstrap local::lib you now can:

wget -O- http://bit.ly/local-lib | TARGET=target_dir perl

or if you are a curl user:

curl -L http://bit.ly/local-lib | TARGET=target_dir perl

I wish I didn't have to specify the TARGET environment. It should assume, like the previous bootstrap process, ~/perl5. I'll whip up a patch tomorrow.

There is no permalink to the latest version of the bootstrap script, so until I can find a way to alter the destination URL, we are stuck with the current version of it. I do hope a more definitive URL shows up, like the suggested http://install.local-lib.pl/.

The process worked fine for me in a couple of servers around here, but it is not a complete bootstrap. This process installs the local::lib module but doesn't adjust your shell configuration to make the settings stick.

So after you need to run this:

TARGET=perl6 echo "eval  \$(perl -I$TARGET/lib/perl5 \
    -Mlocal::lib)" >>~/.bashrc

(see the local::lib bootstraping section for csh instructions)

Its an excellent service, and it can only get better.

The presentation is very good, but starting around 10m25s there is a sequence about pig farming in the Netherlands that make me laugh out loud.

Weird stuff.

Update: well, chickens are even worse (PDF)...

I check my email and RSS feeds early in the morning and late at night, just before bed, and keep my IM and IRC clients closed.

I needed to take a break, really. I found myself in the worst productivity slump ever, and something had to change.

I have lot of work piled up that I really want to get done:

• update the AnyEvent::Mojo module to support the latest Mojo developments, most notably support for pipelining commands;
• try out the Protocol::OpenID module that vti is writing: I promised him a AnyEvent::Mojo-based implementation;
• finish the XMPP Radar application;
• read through the new AnyEvent::XMPP branch that Robin has been working on: it looks significantly better and more developer-friendly than the current one;
• play around with real-time peer-to-peer synchronization of JSON-based documents: mostly a prototype to wrap my head around the problems of adding real-time replication to Prophet.

Thats the top 4, and I'm not even including $work stuff. On that side of things, I'm considering switching parts of DBIx::Class-based that I have (and don't particularly like, and in need of some feature-upgrades) to KiokuDB. That's probably the top item.

So far, working offline is paying off. I'm clearly more productive and I'm slowly getting myself out of the hole. I wonder how long I'll keep myself sane this way...

So a couple months ago I started looking around for options to secure my two macs (desktop and laptop) and their Time Machine backup drives against physical theft.

I bought a copy of PGP Whole Disk Encryption and I'm using it on my laptop. On day-to-day usage, you just don't notice the overhead. I suppose that if I had to do I/O intensive stuff I might, but so far it doesn't register at all.

The setup process is slow but painless. It took about 3 hours to encrypt my hard drive, and the laptop remains usable during the whole process. You can even stop and restart if you need to.

You can have several users each one with a different pass-phrase that can unlock the hard drive at boot time. I created two users, one for me, and another for disaster recovery. I generated a long random pass-phrase for the second user, printed two copies, and stored each copy on two different safe deposit boxes that I and my business parter have access to. This way, if I get hit by a bus, my partner can access the content of the drive.

My next step will be to encrypt the entire Time Machine external disk drive that I use. After that, I'll update the desktop machine and its Time Machine backup disk.

This should solve the physical theft problem. There are some precautions that you need to take though. For example, to be protected you must shutdown your laptop. When the laptop enters sleep mode, the hard drive remains "open". It would be nice to "lock" the hard drive when entering sleep mode, but I guess that it would require more support from Apple to do that. This is a problem for the laptop. I usually shutdown my desktop everyday when I leave the office. I do hope to see a lock-on-sleep feature in a future release.

But so far I'm very happy with this solution. Recommended.

Of course, I still have to worry about non-physical theft. People could still hack into my servers, or even hack into my desktop/laptop while they are running. But its a step.

The servers run with minimal services, and with a firewall active. I still haven't made the jump to a full SELinux enabled system, though. I do have a minimal port-knocking system for ssh connections, but its still experimental and only covers two of the ten servers I manage.

Also, some less secure services still share hosts with other higher security services. This is legacy from a time when I had less servers, and splitting them was not an option. My experiments with OpenVZ should provide an even better solution for this problem.

Small company, so small steps.

The anti-pishing features are great, specially the personal icon feature. It basically sets a cookie on your browser, with a picture URL, and shows you that picture on the login page. If you don't see the picture, then the site didn't get the cookie, and the URL is probably fake. Simple and effective.

I've also gained OpenID 2.0 and XRDS support, which is nice.

And given that I was already using simplicidade.org as my identifier, I only had to update the <link>'s on that page to point to my new provider.

OpenID delegation FTW...

The 280 North gang released version 0.7 this week, and inside there is a new tool that made my jaw drop. The nib2cib tool allows you to design your application with the gorgeous Apple Interface Builder, and then translate the resulting nib/xib into a cib that your JavaScript app can use directly.

It even supports Target/Actions and Outlets...

I'm not a JavaScript applications developer, but I find this truly impressive.

Following Tim's leads, I checked that the pod2man was producing proper nroff, with a \- for each -. It was. I tried to understand the groff tmac files, but I think we have here the first real proof that there are aliens out there, and they speak wonderful languages...

Anyway, we turned to Google and after a bit of digging we ended up at the groff CVS and a recent change (rev 1.39), just 4 months old so recent enough not to be included with Mac OS X. The description was promising:

tmac/an-old.tmac, tmac/doc.tmac: For -Tutf8, map -, -, ', and ` conservatively to ASCII for the sake of easy cut and paste.

The doc.tmac is important. When pod2man calls nroff, it asks for the an package. The an.tmac basically includes the andoc.tman and that one includes the doc.tman package.

At first I took the diff and tried to blindly apply it to the local doc.tman file. I don't speak alien, so although nroff didn't complain after my changes, it also keep on using the unicode hyphen symbol.

So I've downloaded the latest groff package (1.20.1) and did:

tar zxf groff-1.20.1.tar.gz
cd groff-1.20.1
./configure --prefix=$HOME/bin/groff-1.20.1 \
   --with-appresdir=/tmp/gxditview
make -j 4
make install

You now have your own local groff install, including a brand new nroff.

To test it, I run:

perldoc -n ~/bin/groff-1.20.1/bin/nroff local::lib

Copy and paste something in there with hyphens, like my nemesis --bootstrap, and you should see that your hyphens stay in glorious ASCII, no more of that unicode mumbo-jumbo.

So stick this into your .bashrc:

alias perldoc='/usr/bin/perldoc -n ~/bin/groff-1.20.1/bin/nroff'

And live long and prosper.

Maybe it is possible to take the changes and port them successfully to groff 1.19.2, but I couldn't do it. If you do speak alien and you do port them to the groff shipped with Mac OS X 10.5, leave me a comment. Sticking a new doc.tmac in the `site_tmac/´ directory is a lot simpler than installing groff.

Update: the PROBLEMS file (kudos to this thread where you can follow the whole argument with the same problem in Linux man pages) that is included with groff mentions this problem:

• The UTF-8 output of grotty has strange characters for the minus, the hyphen, and the right quote. Why?

The used Unicode characters (U+2212 for the minus sign and U+2010 for the hyphen) are the correct ones, but many programs can't search them properly. The same is true for the right quote (U+201D). To map those characters back to the ASCII characters, insert the following code snippet into the `troffrc' configuration file:

.if '\*[.T]'utf8' \{\
.  char \- \N'45'
.  char  - \N'45'
.  char  ' \N'39'
.\}

If you stick the above code into /usr/lib/groff/site-tmac/troffrc the output will be ASCII, even with the default Mac OS X groff, but the perldoc output starts with a couple of blank pages and a warning:

<standard input>:138: warning: can't find font `CW'

So compiling groff is still the best solution.

On one side, you have access to most of the software out there already compiled (presumably by someone who knows and uses the software and therefore is able to choose the proper, most useful, configuration options) and with all the administrative bits (startup scripts, example configuration files) in the "right" place (usually dictated by some standard like the LSB).

On the other all the package managers that I know of (and this is really a cry for help, please tell me of exceptions to this rule) have a Highlander-fetish with regards with package versions: there can be only one.

At any point in time, you can have one and only one version of a package installed it seems. If I have two applications running on some server, and you tested one of them with version X of the package P, and the other with version Y, you cannot have both versions installed at the same time. You have to pick the latest one and hope that backwards compatibility was not lost.

Most people with setups larger than mine that I talk to about this just tell me that "oh, you should split your applications on different servers, easier to manage, profile and tune". That's true, but most small mom-and-pop business don't have or don't want to spend capital to work around limitations on package managers.

There is also a good argument to be made for security. Keeping old versions around and in use is a security risk if the newest version was released to fix a security problems. I acknowledge this whole heartedly, but still, sometimes you know that you are using and old buddy version, but you still need to keep it running for some time, either because you evaluated the security problems and they don't apply to your configuration or because you need more time to test with the new version. We should be aware of the dangers you put yourselves in when you ignore upgrades like that, but you shouldn't be ruled by fear also. Analyze, weight your options, decide. Be rational.

One clean solution is a containers package like OpenVZ or FreeBSD jails or Solaris Zones: one kernel per server, several virtual servers. I admit that I strongly prefer this type of container-based virtualization solutions to the big ones that require processor support for decent speed, like VMWare, Xen or Parallels. I have a strong distaste for waste, and having multiple kernels running on the same metal, although extremely useful in some scenarios, is very wasteful of resources in the general case.

So although I just got a server at the office to have a second round of OpenVZ tests (and I'll probably use it in production for all my servers if I'm happy with them), I still believe that all of this is a big blanket over bad package managers.

My ideal package manager would create a base directory somewhere, lets say /p, and would create a set of directories, taking in account architecture, package name, and package version. For example, you could have perl 5.8.9 and perl 5.10 like this:

• /p/i386/perl/5.8.8/{bin,lib,...}
• /p/i386/perl/5.10/{bin,lib,...}
• /p/x86_64/perl/5.10/{bin,lib,...}

Also, you could keep the notion of latest using: /p/i386/perl/latest as a symbolic link to /p/i386/perl/5.10. This way other packages can require any version of perl or a specific version of perl.

The PATH environment would be tailored to the specific versions of each package you want. Just include the proper bin/ of the specific version you want. A global /p/${arch}/bin/ could be setup with symbolic links to the package/latest/bin/ files.

Clearly the solution of using OpenVZ is easier to manage today, no need to find or build a package manager like this, but still, I would really like to see it sometime.

The AnyEvent::DNS module allows you to resolve DNS queries fast and in parallel.

To test this, I wrote a simple command line tool to check XMPP SRV records of a list of domains. Both server-to-server and client-to-server records will be checked and results printed out. All queries will be made in parallel.

The code is at my Ironman repository. Click the "Raw" link to download (sorry, no direct link, GitHub lacks permalinks to the latest raw version of a file).

My new relation with Twitter can be summed up like this:

1. I'll post links that I find interesting;
2. I've subscribed the feed of mentions of @pedromelo: this allows me to read responses or comments about such links in my RSS reader, when I feel like it;
3. I've created a feed with all the twits from my friends that contain a link: allows me to catch any links they find relevant.

There. Twitter off.