Pistolando con LWP e qualche chiamata HTTP, avevo bisogno di rendermi conto che cosa mi stesse passando il server.
Ho trovato estremamente utile a scopo di debugging il metodo headers_as_string proprio della risposta (HTTP::Response) che lo eredita da HTTP::Message.
Direi che è l’equivalente del flag -e di lwp-request.
GET http://www.google.it/
User-Agent: lwp-request/5.827 libwww-perl/6.02
200 OK
Cache-Control: private, max-age=0
Connection: close
Date: Sun, 18 Sep 2011 13:39:47 GMT
Server: gws
Content-Type: text/html; charset=ISO-8859-1
Expires: -1
Client-Date: Sun, 18 Sep 2011 13:39:47 GMT
Client-Peer: 209.85.148.105:80
Client-Response-Num: 1
Set-Cookie: we_have_cookies; expires=Tue, 17-Sep-2013 13:39:47 GMT; path=/; domain=.google.it
Set-Cookie: we_have_a_lot_of_cookies!; expires=Mon, 19-Mar-2012 13:39:47 GMT; path=/; domain=.google.it; HttpOnly
Title: Google
X-XSS-Protection: 1; mode=block
Cool.
Tempo addietro ci ho dato dentro per cercare di capirmi con Catalyst.
Catalyst è ficco per diversi motiivi (un dispatcher super raffinato e duttile, molti plugin utili, un’organizzazione del codice impeccabile), e lo apprezzo sinceramente. L’ho apprezzato anche di più quando ho capito come non affidarmi alle sue abitudini sovra ingenerizzate.
Attualmente mi sto guardando come funzica Mojolicious, e come accade spesso, Perl è pieno di progetti del genere.
Alla fine il punto è sempre ricercare lo strumento giusto per il lavoro giusto – altrimenti detto conoscere l’HTTP e un HTML…
Il resto sono features.
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:
libcgi-dev – library for CGI programs in C
libcgi-doc – documentation for libcgi in html
libcgi0 – library for CGI programs in C
libcgic-dev – C library for developing CGI applications
libcgic2 – C library for developing CGI applications[…]
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.
Un indice di un resoconto di articoli sui css, da smashingmagazine.com.
Mastering CSS, Part 1: Styling Design Elements
- Layout and User Interface Techniques
- Navigation and Menu Techniques
- Image Styles and Galleries
- Typography Techniques
- Icons, Buttons and Links
Mastering CSS, Part 2: Advanced Techniques and Tools
- Calendars, Lists, Tables, and Timelines
- iPhone CSS Techniques
- Form and Search Techniques
- Visualization Techniques
- Other Handy Techniques and Tips
- CSS3 Techniques
- CSS Tools
- More Articles and Resources
Per ora ho usato i form, e letti gli articoli riguardanti le date (O_O), il testo sulle immagini, e gli angoli da sfogliare (bellissimo, provate il demo!). Molto carini anche gli articoli sulle liste visualizzabili in maniera diversa e riguardanti la validazione dei form.
Ho installato su kripton (debian) apache Tomcat, e ci ho messo sopra Cocoon (dopo 1 giorno e mezzo di bestemmie).
In linea generale, l’accrocchio mi sembra notevolmente schifoso: lento e inutile.
Ovviamente, non ho ancora capito niente. Perchè complicarsi così tanto la vita?
Non capisco ancora (ma c’è, sicuro che c’è) la fichezza di questi oggetti.
Apache + php è bello rapido e mi è chiaro. Qualcuno chiede una pagina, apache interpeta il suo bel codicillo php, che nel migliore dei casi è un html e basta, nel peggiore un html embeddato di php che elabora e passa. Lineare. Se ci sono javascript e css se li carica e se li legge.
Sul funzionamento di Tomcat non mi ci metto, ma già i file di configurazione mi lasciano sbalordito (l’xml mi pare attualmente una caterva di tasti sbattuti li per l’anima del …).
Comunque, quando arriva una richiesta quella viene passata a Cocoon, che fa dei giri strabilianti: si deve leggere una sitemap (xmap), un xslt e un xml da interpretare, ovviamente con tutte le risorse accessorie (CSS, javascript e altro) sempre dietro.
Sicuramente per qualcuno sarà banale… Io lo trovo a dir poco contorto. :-/
Non riesco a starci dietro a sto ambaradan.
Boh, a me per ora sta divisione dei contenuti non mi fa impazzire. (Rails mi è parso comunque molto più chiaro.)
Per far girare questa cosa fantastica ho preso tomcat5.5 dai repo debian, NON ho caricato -admin e -webapps che sicuramente a qualcuno piacciono, ma a me ‘ste interfacce d’aiuto punta e clicca mi fan venire il vomitino e mi incasino di più. Poi ho scaricato dal sito di cocoon la versione 2.1.11, ho buildato il war e l’ho messo sotto le webapps di tomcat. Al riavvio, ha scompattato ed è partito.
Per ora non ho molto da dire, se non che mi pare cacca sciolta. Sic. :-/
Preso dalla foga di provare qualcosa di nuovo (non so quando mai troverò il tempo di approfondire, ma intanto…) e soprattutto non riuscendo a dormire, mi sono installato Ruby e Rails su Idrogeno.
Non sono manco sicuro di aver capito tutto bene, fatto sta che attualmente il tutto sembra funzionare.
Per la cronaca, ho installato i seguenti pacchetti con un paio di apt-get (install ruby libzlib-ruby rdoc irb rubygems rubygems-doc libfcgi-ruby1.8 libapache2-mod-fastcgi rails libapache2-mod-ruby libapache2-mod-fcgid):
2009-04-23 01:03:16 install libruby1.8 1.8.7.22-3 1.8.7.72-3.1 2009-04-23 01:03:17 install ruby1.8 <none> 1.8.7.72-3.1 2009-04-23 01:03:17 install libreadline-ruby1.8 <none> 1.8.7.72-3.1 2009-04-23 01:03:17 install irb1.8 1.8.7.22-3 1.8.7.72-3.1 2009-04-23 01:03:17 install irb <none> 4.2 2009-04-23 01:03:17 install libruby <none> 4.2 2009-04-23 01:03:17 install libzlib-ruby <none> 4.2 2009-04-23 01:03:17 install rdoc1.8 <none> 1.8.7.72-3.1 2009-04-23 01:03:18 install rdoc <none> 4.2 2009-04-23 01:03:18 install ruby <none> 4.2 2009-04-23 01:05:44 install rubygems1.8 <none> 1.2.0-3 2009-04-23 01:05:45 install rubygems <none> 1.2.0-3 2009-04-23 01:05:45 install rubygems-doc <none> 1.2.0-3 2009-04-23 01:12:47 install libapache2-mod-fastcgi <none> 2.4.6-1 2009-04-23 01:12:47 install libfcgi0ldbl 2.4.0-7 2.4.0-7 2009-04-23 01:12:47 install libfcgi-ruby1.8 <none> 0.8.7-4.1 2009-04-23 01:17:59 install wwwconfig-common <none> 0.2.1 2009-04-23 01:18:00 install javascript-common <none> 5 2009-04-23 01:18:00 install libapache-ruby1.8 <none> 1.2.6-2 2009-04-23 01:18:00 install libapache2-mod-fcgid <none> 1:2.2-1 2009-04-23 01:18:00 install libapache2-mod-ruby <none> 1.2.6-2 2009-04-23 01:18:00 install libbreakpoint-ruby1.8 <none> 0.5.1-2 2009-04-23 01:18:00 install libbuilder-ruby1.8 <none> 2.1.2-1 2009-04-23 01:18:00 install libbuilder-ruby <none> 2.1.2-1 2009-04-23 01:18:01 install libcmdparse2-ruby1.8 <none> 2.0.2-2 2009-04-23 01:18:01 install libdaemons-ruby1.8 <none> 1.0.10-2 2009-04-23 01:18:01 install libjs-prototype <none> 1.6.0.3-1 2009-04-23 01:18:01 install liblog4r-ruby1.8 <none> 1.0.5-7 2009-04-23 01:18:01 install libmmap-ruby1.8 <none> 0.2.6-3 2009-04-23 01:18:01 install libmocha-ruby1.8 <none> 0.9.5-1 2009-04-23 01:18:01 install libmocha-ruby <none> 0.9.5-1 2009-04-23 01:18:01 install libncurses-ruby1.8 <none> 1.1-3 2009-04-23 01:18:02 install libopenssl-ruby1.8 <none> 1.8.7.72-3.1 2009-04-23 01:18:02 install libredcloth-ruby1.8 <none> 4.1.9-2 2009-04-23 01:18:02 install libredcloth-ruby <none> 4.1.9-2 2009-04-23 01:18:02 install libruby1.8-extras <none> 0.5 2009-04-23 01:18:02 install libsqlite3-ruby1.8 <none> 1.2.4-2 2009-04-23 01:18:02 install libsqlite3-ruby <none> 1.2.4-2 2009-04-23 01:18:02 install libxml-simple-ruby <none> 1.0.11-2 2009-04-23 01:18:02 install rake <none> 0.8.4-1 2009-04-23 01:18:03 install rails <none> 2.2.2-1
Seguendo questa guida (a grandi linee) ho poi creato la dir /var/rails/ e ci ho buttato dentro un’applicativo di default con # rails trone.
Of course, ho dovuto creare un virtualhost su apache e modificare bind9.
Se usate Icedove come client di posta, e ricevete una mail con un link web, c’è un’ampia possibilità che il suddetto client vi voglia far navigare con epiphany.
Questo è dovuto ad un link simbolico in /etc/alternatives della vostra Debian che risulta essere:
lobaloba:/etc/alternatives# ll x-www-browser*
lrwxrwxrwx 1 root root 17 2009-01-22 10:19 x-www-browser ->
/usr/bin/epiphany
lrwxrwxrwx 1 root root 33 2009-01-22 10:19 x-www-browser.1.gz ->
/usr/share/man/man1/epiphany.1.gz
Supponendo che vogliate aprire gli hyperlink con iceweasel, vi informo che con un sanissimo whereis si possono scoprire alcune info fondamentali.
lobaloba:/etc/alternatives# whereis iceweasel iceweasel: /usr/bin/iceweasel [...] /usr/share/man/man1/iceweasel.1.gz
A questo punto basta ricreare i symlink, ed il gioco e’ fatto.
lobaloba:/etc/alternatives# ln -s /usr/bin/iceweasel
x-www-browser
lobaloba:/etc/alternatives# ln -s /usr/share/man/man1/iceweasel.1.gz
x-www-browser.1.gz
La soluzione più elegante comunque, passa attraverso $ update-alternatives –config x-www-browser.
