Oggi giretto Bologna – Loiano – Monzuno (dintorni molto belli), ritorno verso Pieve di Pino con discesa a Gaibola e San Mamolo (strada stretta e malmessa). Poi dritto verso Calderara, e ritorno a casa.

Peccato per la pioggerellina e l’asfalto un po’ viscido.

View Larger Map

Spesso escono articoli su vari argomenti, tenuti da personaggi “importanti” che ne sparano un po’ di tutti i generi.
Ovviamente, ci si può esaltare o meno alla lettura delle prossime X features della versione Y.ZZ^2 ecc., ma di solito io non faccio parte del gruppo.

La cosa invece che mi è parsa carina di questa intervista a Damian Conway sul futuro del perl (si parla sempre della fantomatica versione 6 del linguaggio, in gestazione da 10 anni), è questo paragrafo:

Greg: What non-computing books would you recommend programmers to read?

DC: Programming is an intrinsically creative task, so it’s critically important to feed your creativity from outside the discipline. My own interest has always been in new models and metaphors for computation and better ideas for interfaces, so I try and read as widely as I can in the hard sciences (especially physics and mathematics) and in the literature of general design. But that’s me, and most people wouldn’t find inspiration in those same places.

So the general answer, I think is that you need to find books that stretch your brain in unexpected ways, that break you out of your habitual ways of thinking and of viewing the world, that challenge your assumptions and your certainties. Some great example of such books are “The Design of Everyday Things” by Donald Norman, “Freakonomics” by Stephen Dubner and Steven Levitt, “Guns, Germs, and Steel” by Jared Diamond, “The Prince” by Machiavelli, “Catch Me If You Can”, by Frank Abignale, “Lost in the Cosmos” by Walker Percy, or just about anything that Douglas Hofstader has written (sadly, most people seem to stop at “Godel, Escher, Bach”).

Now, I don’t say that I agree with every idea or theory in those particular books, or even with most of them, but I do think that every one of them issues a direct challenge to our entrenched expectations and beliefs. And I think that’s the critical thing.

So much of everyday programming is monotone. You need to transcend that sameness if you want to become a better programmer. And learning to think outside the box (and even just that there’s a box to think outside of!) is essential to that growth.

I think that’s also why so many programmers naturally gravitate to science fiction. Really good SF takes you outside your assumptions in exactly the same way.

Qualche tempo fa mi sono messo a guardare framework web vari e curiosi, trovando le cose più disparate: mi avevano colpito molto due engine scriptati in bash e rc (nanoblog e werc).
La shell è molto affacinante, ma l’overheading del codice legato ai vari “system” che la shell lancia per avviare figli di se stessa sono mostruosi.

Dunque, in un weekend lontano da casa ma col portatilino a mano, mi sono messo a guardare queste cose lato C – un po’ macchinosetto, non c’è dubbio.

Mi sono messo a scrivere una lib cgi, per esercizio, in modo che sapesse interpretare un form in GET ed in POST (non avevo mica capito come client e server si passavano i dati in POST) e la cosa funzionava pure (a parte un bug, suvvia).

Tornato a casa, un apt-cache search libcgi ha evidenziato i seguenti pacchetti, che indicavano chiaramente il mio lavoro come inutile:

La pagina introduttiva di libcgi-doc (su sourceforge) dice quel che segue:

Hello!
My name is Rafael Steil, I’m from Brazil.

I started programming LibCGI just for fun at september/2001. The reason I wrote this lib was, originally, to learn more about C programming. In that time, I had many problems with pointers manipulation, and I was being a bit bored about it.
I needed a reason, a good reason continue. Those days I’ve been coding in PHP, and I sill like PHP a lot, because it is powerful and fun to code with. But on the other hand, I don’t want to work with PHP for the rest of my life, I want to do something of exciting, like programming games .

Just as curiosity, currently I spend my time ( which means, I’m paid for ) coding in Java and C#.

When I wrote the first LibCGI’s line of code ( in this time LibCGI was just a test program ), I knew absolutely nothing about CGI programming, I didn’t know how to read form variables, nothing.
After some time searching in the Internet, I found some cool papers, and one of them described how to read data, and before reading it, I thought “sucks, It seems to be really complex”, but not, I was wrong! How fun!! After some hours I finished a more complex program, that reads from STDIN and parses it! So I thought “why not make a lib???”.

Great! I had one more reason to code in C. At that time, I was already codding much better, and I was safe that could do something very cool! Now, the result is LibCGI. I would like to thank to everyone that send me suggestions, bugs and bug-fixes, well, to everyone that uses LibCGI. Thanks a lot guys.!!

Esiste anche il pacchetto libcgic-dev (sviluppato da boutell.com), ma visto che si trascinava dietro mille cose in debian e non mi interessava, l’ho lasciato lì.

Sicuramente la lib di Boutell sarà meglio (oltre che più aggiornata), ma mi sento “romanticamente” vicino al brasiliano.

Da wikipedia:

The Yellow Shark is an album of orchestral music by Frank Zappa, released in 1993. It features live recordings from the Ensemble Modern’s 1992 performances of Zappa’s compositions. It was the last Zappa album released before his death.

Quando i web browser fanno una richiesta, questa viene portata al web server corrispondente che poi serve contenuti (X)HTML.
Il contenuto in questione può essere servito direttamente dal webserver in quanto statico, oppure costruito al volo in maniera dinamica grazie ai programmi installati sulla macchina-server.

Come scritto bene su wikipedia, l’interfaccia CGI (Common Gateway Interface) è lo standard (RFC3875) che definisce come un webserver può delegare la generazione di pagine web alle applicazioni sul server stesso: queste applicazioni sono gli script CGI.

Quando il webserver deve servire una pagina dinamica, passa attraverso l’interfaccia CGI per comunicare con l’applicativo la richiesta (ie: URL) tramite le variabili d’ambiente.

Il semplice script bash environment.sh chiamato con un browser

produce

HTTP_KEEP_ALIVE=300
HTTP_USER_AGENT=Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100501 Iceweasel/3.5.9 (like Firefox/3.5.9)
HTTP_HOST=kripton.lan
SERVER_PORT=80
HTTP_ACCEPT_CHARSET=ISO-8859-1,utf-8;q=0.7,*;q=0.7
DOCUMENT_ROOT=/var/www/
SCRIPT_FILENAME=/usr/lib/cgi-bin/environment.sh
REQUEST_URI=/cgi-bin/environment.sh
SCRIPT_NAME=/cgi-bin/environment.sh
HTTP_CONNECTION=keep-alive
REMOTE_PORT=44486
PWD=/usr/lib/cgi-bin
REDIRECT_STATUS=200
HTTP_ACCEPT_LANGUAGE=en,it;q=0.7,en-us;q=0.3
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
REMOTE_ADDR=::ffff:192.168.0.1
SHLVL=1
SERVER_NAME=kripton.lan
CONTENT_LENGTH=0
SERVER_SOFTWARE=lighttpd/1.4.19
SERVER_ADDR=::
GATEWAY_INTERFACE=CGI/1.1
SERVER_PROTOCOL=HTTP/1.1
HTTP_CACHE_CONTROL=max-age=0
HTTP_ACCEPT_ENCODING=gzip,deflate
REQUEST_METHOD=GET
_=/usr/bin/env

(Lo script CGI deve produrre anche il Content-type della pagina.)

Ogni singola richiesta al webserver passando attraverso CGI implica l’avvio di singoli script e quindi di singoli processi sulla macchina; questo ovviamente può causare l’esaurimento delle risorse in breve tempo, nel caso il traffico sia elevato.
La soluzione è stata inventarsi FastCGI che consiste in un singolo processo persistente che chiama i diversi applicativi e comunica attraverso socket UNIX o TCP con il webserver.

Riferimenti su wikipedia: web pages, dynamic web pages, CGI, FCGI, URL, header HTTP.

E’ un po’ di tempo che guardicchio la robba di suckless.org, e anche se non penso proprio che passerò a Plan9, me la spasso un casino a seguire i rant cosmici del gruppo.

La pagina harmful.cat-v.org/software/ è davvero un gioiello.

Inizia con un fantastico

“One of my most productive days was throwing away 1000 lines of code.“

per poi passare ad un elenco di software criticabili con rispettive alternative. (Peccato ci sia perl in mezzo agli harmful.)

Notevolissimi gli editor harmful: Vim, Emacs, nano, Eclipse, …, Less harmful alternatives: Acme, Sam, ed.

Ah… ed.

La pagina si conclude con un fantastico

HTML Email sucks.

Questo video spiega molte cose sullo stile di guida di una moto, se si vuole bene vedere.

Attenzione dai 2:12 ai 2:25, che fa il miracolo… O_O