The Void

Lots of good things happened recently in Dancer’s development, here they are:

HTTP::Server::Simple::PSGI

After my last post about Dancer, Tatsuiko Miyagawa suggested to build Dancer’s standalone server upon a PSGI-aware layer, rather than on HTTP::Server::Simple::CGI.

A couple of days later, he released HTTP::Server::Simple::PSGI, which is actually based HTTP::Server::Simple (which itself doesn’t depend on any non-core modules).

A few patches later, the standalone server was refactored and running on this new guy. That means when writing a Dancer app, you can now always rely on PSGI environment goodness, whereas you’re using the standalone server, or the Plack architecture. That just rocks, again kudos to @miyagawa.

Dancer::Request

The Dancer::Request class got also heavily refactored and enhanced, it can now provide the user with an access to the raw body of the incoming request (thanks to RasterBurn for the report).

By the way, this class needs still so more features, and I’m actively working on it. I may release Dancer 1.2 when I’m happy with that one.

Oh and it also now provides a complete documentation. POD FTW.

Dancer::Route

I also gave a shot at Dancer::Route, which has been recently patched to support some new features (prefix and conditional matching, thanks to Frank Cuny)

No more CGI.pm, really!

I also found that CGI.pm was still used in one very place for rendering and HTML page. This was a shame as we wanted Dancer to be 100% CGI.pm-free. Hence the patch that actually allow us to say it now, for REAL ;)

All of this freash meat is available on my GitHub repo and will be soon released to CPAN, under version 1.140. Stay tuned!

A black stone hitting the wood.
A white stone is dead.
But shall the black group live for long?
Fear the Tesuji!

Ah, I’m glad I’ll face a goban this evening, it’s been too long!

I’ve read the book “The Productive Programmer” by Neal Ford, there are many great ideas in this book. This gave me the idea to write – just for fun – the 10 rules of Productive Programming.

1. Do not talk about Productive Programming

Well, you know where that first rule come from, don’t you?

2. Be DRY: Do not repeat yourself

This mantra comes from The Pragmatic Programmer, it says that you shall not repeat more than once a block of code. If you are about to, that means you need to refactor something. The less you repeat yourself, the better your code quality and maintainability.

3. Think YAGNI: You ain’t gonna need it

Donald Knuth is probably the first one who pointed out that sane rule, in The Art of Computer Programming: “Premature optimization is the root of all evil“.

When working on something, you may start thinking about future issues you may have, and here you start to optimize your code for problem you don’t have yet. This is very bad. The fact is that you’re going to spend energy and time on a virtual issue, that may never come true. Focus on your real issues, and let the time tell you where an optimization is needed.

4. Kill distractions

Distractions are the inner enemy: your email client notifications, your instant messaging system, your Facebook page, your Twitter account…

All this leads to disturb your attention. Every distrcation slows down a bit more your productivity. Choose when to check your emails, don’t connect your instant messaging system all day, choose when to connect with your twitters, and when not.

5. Be careful of angry monkeys

The “Angry Monkeys” metaphor symbolizes the fact that people tend to fear changes. When a team is used to do something in a particular way, that team will hardly think about changing its strategy, because of the mantra: “we always did it that way”.

Changes can be good for software. Don’t fear them.

6. Work your flow

The flow is the state of mind where you are when you’re focused on your code. This is a very fragile state, and can be broken very quickly (by distractions). The better your flow, the higher your code quality. Try to control external events that can break your flow, kill districations, and focus on one single task at a time, with a clear target in mind. Move step by step.

7. Write unit tests

Unit tests are the way to go in modern programming. Write tests and use a test coverage analyzer. Target 100% of test coverage. Try to write tests before you write code, use the Test-Driven Development technique as many times as possible.

8. Refactor comments into functions

If you’re writing some comments inside a functions, chances are that this function should be splitted into smaller ones. Those comments you write, they can basically be renamed as functions, you’ll see the resulting code will look much more readable and … testable!

9. If you find a bug, write a test

Whenever a bug is found, the first thing you have to do is to write a test that reproduce the bug. A bug you can reproduce is a bug near to be closed.

10. Apply these rules daily

Well, rules are nice, but they’re even better when applied ;)

…

All right, I broke rule #1, I know ;-)

Ça serait bien, mais il me faudrait un peu de temps libre et une idée pour parler de quelquechose d’intéressant.

Alors bon, ça sera pas pour cette fois.

C’est mon pote Güven qui m’a parlé de ce buzz en début de semaine : un peu partout dans la ville de Bruxelles fleurissent des affiches roses mystérieuses.

Si l’on en croit le pseudo-blog 20jours.be il s’agit d’un jeune romantique, tombé amoureux dans un train qui cherche artistiquement à retrouver sa belle.

Ça sent vraiment l’eau de rose, oui, et pour cause… Bref.

« Ca sent le buzz » me dit Güven. J’acquiesce, on commence plus ou moins à creuser au fil de la journée.

En cherchant sur Google : « 20jours.be », Güven trouve un article sur Lesoir.be qui donne quelques infos :

On vous dira aussi que l’anagramme de Kevin Polof peut révéler bien des senteurs et que les effluves de sa croisade rose embaumeront plus d’une belle après le 24.

Ok, donc un parfum ? Visiblement oui.

En cherchant le nom « Kevin Polof » sur Google, on trouve un Tweet en Néerlandais qui nous dévoile l’anagramme : « Love of Pink ».

Bien, cherchons « Love of Pink » dans Google…

And the winner is : Lacoste !

Buzz Buster Powa!

En me documentant sur la symbolique de l’Ouroboros je suis tombé sur cette phrase:

Le dragon circulaire est aussi présent dans la mythologie indienne, en encerclant la tortue qui supporte les quatre éléphants qui portent le monde.

Mais mais mais ! Et dire que l’idéee du Disque-Monde – plateau reposant sur quatre éléphants, eux-même sur le dos d’une tortue géante cosmique – n’est en fait qu’une pure transposition d’une véritable croyance indienne.

La grande A’Tuin, divinité Indienne de notre monde, qui l’eût cru ?

Sur #backup-manager, cet aprem :

13:06 -!- ramses [~pipapo@internetautobahn.de] has joined #backup-manager
13:06 < ramses> anyone there now? ;-)
13:07 -!- ramses [~pipapo@internetautobahn.de] has left #backup-manager [Verlassend]
17:23 < eger> heh
17:23 < eger> 2 minutes in irc world is like 2 microseconds

:-)

Le gouvernement Sarkozy nous propose une toute nouvelle façon d’organiser le temps de travail de salariés : Le Monde nous apprend que les salariés soumis au “forfait” jours, hors accord d’entreprise, vont travailler plus.

Cette proposition ferait passer le nombre de jours de travail maximum par an à 235.

Concrètement ça veux dire une chose simple : si l’entreprise n’a pas d’accord particulier sur le sujet avec ses représentants du personnel, les jours fériés payés disparaissent (outre le premier mai). Le salarié pourra donc s’abstenir de venir travailler un jour férié, mais, c’est ballot, il ne sera pas payé.

En effet, 235 jours c’est 365 – 104 (tous les samedi et dimanche) – 25 (les 5 semaines de congés payés) – 1 (le premier mai).

Alors j’entends déjà nos chers politiciens UMP nous avancer l’argumenteur suivant : mais c’est une mesure pour améliorer le pouvoir d’achat !

Haem, si je réfléchis cinq secondes, avant cette loi, un salarié était payé le 11 novembre, le 14 juillet ou encore le 15 août. S’il désire que cela persiste, il devra donc travailler ces jours là.

C’est donc travailler plus pour gagner pareil.

C’est beau la politique.

Le soleil parisien assome le golden boy – qui n’en perd pas son iPod pour autant.

On parle beaucoup, beaucoup de Jérôme Kirviel qui provoqué la perte de 5 milliards d’euros, mais savez-vous qu’il existe un homme qui a fait l’exact contraire : visionnaire, il a su prévoir la crise des subprimes, et a consacré son action dans ce sens.

Résultat, il a fait gagner 15 milliards de dollars à son fond d’investissement.

Kirviel-Paulson, le ying et le yang en quelque sorte.