Se c’è una cosa grandiosa delle chiavette USB, è che possono tenere un sacco di cose importanti, ed essere estremamente portatili.
Credo che una delle cose più ganze, sia poter girare con il proprio OS a portata di mano.
Per gli utenti che non vogliono chiedere mai e che hanno una chiavetta USB a disposizione:

• scaricate l’immagine della distro debian (5.0) con il DE che preferite da qui (io sono andato sulla i386, usb-hdd, xfce).
• copiate su una chiavetta con $ dd if=immagine_debian_live.img of=/dev /chiavetta /usb
  Attenzione: copiate sul device della chiavetta, non su quella della partizione (ie: /dev/sdc, non /dev/sdc1)
• Inserite la chiavetta in una porta usb e riavviate il pc, facendo il boot dalla chiavetta (ie: F8 per avere il menu di boot).

Facile e utile.

Lavorando su un postgres vecchiotto avevo scritto una riga di codice php che con le nuove versioni non è accettata per questioni di casting.
Visto che in effetti il risparmio è notevole, oltre che più corretto, segnalo la funzione TO_CHAR (che ha nelle opzioni quello che spesso serve per fare manipolazioni di date).

Quello che prima era trovato concatenando due stringhe ricavate da DATE_PART (per prendere una parte di un timestamp without date zone) e facendolo passare per LPAD in due cifre riempito con caratteri 0:

( LPAD( DATE_PART('day',file_upped), 2,'0') ||
    LPAD( DATE_PART('month',file_upped), 2,'0') )

ora è trovato con questa semplice funzione che ha fra le opzioni già la possibilità di avere giorno e mese in campo di 2 cifre:

TO_CHAR(file_upped,'DDMM')

Per la serie, sperimentiamo framework a caso.
Nella mia spasmodica voglia di carpire qualcosa di utile in questi minchia di framework che popolano l’universo (non ci credete? O_o), ho installato rapidamente come test su rodio Catalyst.

Su freeBSD, cercare il port www/p5-Task-Catalyst/ e dare un bel # make build install clean.
Post installazione, andare in una dir a casaccio (magari servita dal webserver per ulteriori sviluppi) e, dopo aver letto rapidamente il man di catalyst, comandare:

# catalyst.pl nome_webapp

A questo punto si crea lo “scheletro” del framework – leggere il readme e cominciare a scrivere componenti.
(Con script/webapp_server.pl faremo girare l’applicazione sulla porta 3000. Per un neofita come me, pare ricalcare lo schema di rails.)

Dovendo scrivere un po’ di codice xml, mi sono chiesto se ViM avrebbe potuto venirmi in aiuto.
Il plugin xml.vim ha rappresentato la risposta.
Per “installarlo” è bastato mettere il file in ~/.vim/plugin/ e far leggere a ViM un file xml.

Mea culpa. Negli ultimi mesi ho dovuto dare un occhio in più alle query SQL e così sto ripassando e imparando un sacco di cose che prima mi erano sconosciute.

Una robba estremamente utile che prima facevo (male) “tagliando” in perl i dati fetch’ati dal database è prendere raggruppamenti di dati gruppati secondo una clausola.

La sostanza è che ultimamente mi ero ritrovato molto a mio agio nel raggruppare dati grazie all’opzione GROUP BY conteggiando le voci con COUNT. Il problema era che non sapevo come fare un taglio sul conteggio, e così scremavo i dati in perl dopo averli raccolti tutti dal database.
Questa cosa palesemente non risultava buona.
Quindi dopo prezioso suggerimento ho letto questa paginetta e ho trovato HAVING. Niente di trascendentale, ma per me salvifico.

 => SELECT nome, COUNT(*) FROM lista
       GROUP BY nome HAVING COUNT(*) > 600 ORDER BY count DESC;

Dopo aver filtrato (eventualmente) i dati con WHERE, l’input derivato dalla tabella può essere soggetto al GROUP BY per raggruppare dati, e i raggruppamenti possono essere scremati dalla clausola HAVING.
GROUP BY viene utilizzato per raggruppare insieme quelle righe della tabella che condividono gli stessi valori in tutte le colonne selezionate.
I raggruppamenti vanno d’accordo con funzioni che aggregano espressioni – come SUM() o COUNT().

Piccole scoperte per grandi pivelli.

Oramai convinto di dover provare ad usare cocoon, ho ben deciso di metterlo su rodio – che non per niente mi dovrebbe fare da webserver casalingo.

Installarlo su freebsd è stato molto semplice (c’è il port in /usr/ports/www/cocoon , attualmente versione 2.1.11_1). Meno semplice è stato leggere tutte le vaccate di java, ma amen.

L’installazione si conclude con un ottimo spam, che spiega per filo e per segno il da farsi.

Cocoon is now installed in /usr/local/cocoon.                                   

In order to be able to run Cocoon, please add the following line to
/etc/rc.conf:                                                      

  cocoon_enable="YES"

If you wish to start cocoon right now, invoke the startup script with
`/usr/local/etc/rc.d/cocoon.sh start' and point your web browser to the default
home page at http://localhost:8888/ where you may read the documentation and
test the samples.                                                              

For this control script to run seamlessly, it is recommended to increase the
maximum length of commands displayed by ps(1).  Please append the following
setting to /etc/sysctl.conf:                                                

  # Do not truncate command line arguments in ps(1) listing
  kern.ps_arg_cache_limit=10000                            

This setting will take effect at next reboot, however it is possible to have
immediate effect with the following command as root:                        

  # sysctl kern.ps_arg_cache_limit=10000

If you wish to skip this setting, please note that the `stop', `restart' and
`status' will not function properly with cocoon.sh.                         

Enjoy!

Altre opzioni (“avanzate”):

If you need to pass special options to Java, please set the
cocoon_flags option in /etc/rc.conf, see examples below:

  # Prevent Java from opening an X11 display

  cocoon_flags="-Djava.awt.headless=true"

  # Increase memory limit of the Java virtual machine

  cocoon_flags="-Xms32m -Xmx256m"

  # Run Java with remote debugging turned on on port 8000

  cocoon_flags="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000"

To specify the java version to use, please use cocoon_java_version:

  cocoon_java_version="1.4"

Boh. Per ora ho poco da dire: puntato un web browser sulla 8888 ho visto quel che volevo vedere. In /usr/local/cocoon c’è un po’ tutto.

Ora mi toccherà studiarlo. Ma almeno funge – anche se direi sul server fuffa; in /usr/ports/www/jetty
c’è un server un po’ più serio.

Avevo necessità di ricopiare una tabella già fatta da un database postgres (8.3) ad un altro.
Come fare per avere la stessa linea “CREATE” se l’history non riesce a recuperare così tanto indietro nel tempo?
Semplice: usare pg_dump.

pg_dump è l’utility per fare il backup dei database Postgres. Con un paio di opzioni, ha fatto perfettamente al caso mio:

# pg_dump nome_database --schema-only -t nome_tabella

L’opzione -t o –table serve a specificare la tabella che abbiamo scelto, e –schema-only dumpa solo la definizione dei data (non i dati stessi).

Senza specificare un output, pg_dump spamma su STDOUT, quindi con un taglia e incolla il gioco è fatto.