The Zen of Python

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

You can find it here.

About these ads

My first commit…

Today, after a day needed to make running my development infrastructure (Posgresql + TurboGears) I’ve finally done my first commit on fedora-elections project (fedora-infrastructure group).

fedora-elections is a simple and very useful web application based on TurboGears + SQLAlchemy which implement a voting system. It will be integrated with FAS2 and will be used to make decisions (new fedora name, etc. ).

Thanks to Nigel Jones to help and teach me :-)

PyCon 2 Live #2

Oggi la qualità dei talk è aumentata di molto. Devo ammettere che Google ha dimostrato un’ottima qualità e cura nella gestione dei talks: Brian Fitzpatrick ha tenuto un talk su come l’utente spesso non viene considerato durante lo sviluppo software, Alex Matelli ha parlato di Google Apps Engine. A differenza di Skype, che ha effettuato un investimento puramente monetario (senza curare molto la qualità dei talk), devo ammettere che da Google c’è veramente da imparare.

Il mio talk è filato via liscio, peccato che fosse in un orario un po’ sfigato (domenica pomeriggio dopo il coffee break) che ha contribuito in negativo ad una bassa affluenza. Per inciso, ho parlato di Func – Fedora Unified Network Controller (sul quale pubblicherò a breve un articolo), che è un sistema di API python, che permette il controllo agile di host su reti di larga scala.

Pycon 2 Live #1

Evito di commentare la giornata di ieri con RMS, che ha parlato di GNU/Linux, tanto prendete un video degli anni 90…ambientatelo a palazzo vecchio a firenze…e avete la conferenza di ieri ;-)

Stamattina c’è stato il workshop su django, inizialmente è partito bene, decadendo un po’ con la scrittura a mano della vista (cosa che con grails viene generata in modo automatico). La percezione cmq che da django, è che è molto difficile da mantenere…considerando che i vari branch nascono e muoino velocemente.

Ora sto seguendo il talk su Skype4Py, sinceramente una volta uscito di qui non correrò a provarloST, se devo essere sincero, considerando che lo speaker ci sta mettendo di tutto per farmi addormentare.

Ho finito le slide da circa 10 minuti…manca solo la grafica… :D

Next meetings :)

Liberamente (19 April)
I will partecipate as LOLUG member and Fedora Ambassador, and I will do a short talk on LTSP technology. LTSP is a killer technology to help schools and PA to migrate on opensouce when an upgrade of large scale system is required.

Pycon 2 Italy (9, 10 and 11 May)
My talk proposal about Func has been accepted and, see you there. Sunday at 17:45 ;-) I’m excited and, at the same time, scared. It’s my first official conference, and I’m not so able to speak in public, but on the other hand, never I start, never I learn. Let’s go. :)

Func and JBoss Module

Func (Fedora Unified Network Controller) is a revolutionary and sexy tool that allow you to administer hosts on large scale environments, using a secure communications through https. Func is written in python and is promoted and sponsorized by Red Hat.

Func is designed to implement a client-server model: there’s a single host master (certmaster) which register and exchange certificate with minions (clients). Certmaster can launch commands (ping, ps, netstat, and so on), get various information (hardware infos, nagios infos, xen virtual hosts infos, etc) on each or groups of clients. All commands are module and, thanks to module-driven design, is quite simple to write your own. You can find modules list here.

I wrote, with my byte-code colleagues, a simple module to monitor JBoss running instances, by retrieving information about active ones (port, name, bind address and pid), about problems (for example when two instances are started on the same bind address), and some little stuff (search).

You can execute command by using a single code line, for instance:

func "*" call jboss status
func "*example.com" call jboss status

and so on…more information here.

This module has multple purposes: the first one is to add useful and new stuff and the second is to start something that connect Java and Linux world. In fact, at this moment, they too many separate (although SUN made java opensource, with too delay, IMHO), and, at the same time, Red Hat world and JBoss world.

Unfortunatly I’m not a jboss man, and I don’t have idea on possible stuff to be added (ATM I’m think to add a deployer but func need improvement to copyFile Module ;-))