8 nov 2011

Google, catch 22

Cosa c'è di meglio che aprire Google per trovare una risposta, sentirsi fortunati perché Google ci porta precisamente sulla domanda di un tizio con il nostro stesso problema, e però l'unica risposta è un tizio incazzato nero che dice: ma è mai possibile? ancora questa domanda? Perché invece di continuare a farci perdere del tempo, prima di scrivere una domanda non cerchi un po' su Google?

1 set 2011

Google Italy Blog: Musica a tutto Chrome, anche in estate la tua musi...

Google Italy Blog: Musica a tutto Chrome, anche in estate la tua musi...: Stanchi della radiolina portatile, delle canzoni trasmesse in spiaggia, del numero limitato di brani sulla vostra playlist? L’estate è tempo...

29 lug 2011

Programmatori pazzi

Bene o male, ma soprattutto male, qualunque sviluppatore impara a scrivere qualche piccola applicazione per il Web.

Magari abbiamo scritto la nostra applicazione per tenere traccia delle attività da svolgere, come pagare la bolletta del metano, ricordarsi di revisionare la macchina, portare Tobia alla toelettatura per cani, consegnare un nuovo prototipo al cliente, o pagare gli alimenti per la prole alla ex fidanzata. L'accesso all'applicativo sarà previa autenticazione, e gli utenti potranno inserire i propri dati, leggerli in tabella, ricercarli, filtrarli.

Poi che cosa manca? Gli utenti, oltre ad interagire con l'applicativo Web, vorranno scaricare i dati e portarli sul telefonino, farsene una copia su chiavetta, o importarli in Excel e farci qualche piccola elaborazione.

Da qualche parte nella pagina si dovrà predisporre un link o una paginetta di download, e gli utenti, dopo aver aggiustato qualche filtro, potranno scaricare il file sul proprio client e gestirlo come preferiscono.

E quindi, il programmatore medio che cosa si inventa? Generalmente la tecnica scelta si attesta intorno a queste soluzioni:

  1. si crea una bella crontab sul server, con una riga che viene eseguita ogni tot giorni, che crea una estrazione per ogni utente in \var\www\home\downloads\attivita-nomeutente.dat;
  2. la pagina di download, quando viene richiamata, inizia a scrivere un file in \var\www\home\downloads\attivita-nomeutente.dat. Una volta competato il file, viene mandato in output un bel link all'estrazione appena creata;
  3. la pagina di download richiama un processo sul server che inizia a scrivere un file in \var\www\home\downloads\attivita-nomeutente.dat. Poichè il processo è asincrono, si mette uno sleep di 5 secondi in modo da dare il tempo al processo asincrono di completare il file. Poi ci mettiamo un bel link al file appena generato.
Notate qualche cosa di strano?

La prima tecnica è molto limitata: come possiamo applicare dei filtri? Ma uno sviluppatore creativo è in grado di risolvere anche questo: in fondo, quanto ci vuole a creare in anticipo tutti i file con tutti i filtri possibili ed immaginabili, tutti già preimpostati?
Per la seconda tecnica, uno script con privilegi di scrittura su di una cartella che poi verrà servita tramite server HTTP è il sogno di ogni criminale informatico. Ma se proprio non ci sono altre possibilità, conviene almeno sapere che oltre al chmod 777 o all'Everyone Full Control esistono anche svariate vie di mezzo.
Per la terza ogni commento è superfluo. Posso solo giurare di aver visto anche questo!

Se però non avete notato altro, forse la sicurezza informatica non è il vostro mestiere, e probabilmente non lo sarà mai.

Il vero problema, grosso come un pilone portante del Burj Khalifa di Dubai, è che se mettiamo un file in \var\www\home\downloads\ l'utente vi potrà accedere felicemente andando al link http://www.example.com/downloads/attivita-nomeutente.dat ma oltre al nostro amico autorizzato vi potrà entrare anche tutto il resto del mondo. Certo, disabilitare il browsing delle directory è senz'altro un'idea brillante, ma non basta.

Il concetto è che al nostro Web Server non importa assolutamente nulla dell'autenticazione che abbiamo sviluppato nel nostro programma: abbiamo implementato un sistema di autenticazione per le nostre paginette Web? Bene. Abbiamo utilizzato un framework che implementa la parte di sicurezza? Meglio ancora. Ma questo sistema lo dobbiamo implementare anche per i nostri file. Solo allora possiamo servire le nostre pagine, dinamicamente, e protette dalle nostre credenziali.

(Ci sono casi in cui generare precedentemente i file da far scaricare agli utenti è cosa buona e giusta; tra l'altro il Web Server è sicuramente molto più veloce del nostro script nel servire le pagine; in questi casi però cerchiamo almeno di dare ai file un indirizzo URL casuale).

21 lug 2011

Sviluppare per il Web 2.0?

Ho iniziato a sviluppare applicativi Web aziendali, pubblicati sulla Intranet, fin dal 1998.
Al tempo l'azienda non era nemmeno collegata ad Internet, per cui non avevo ancora a disposizione una casella di posta elettronica aziendale, e le linee di collegamento tra le varie sedi distaccate erano decisamente molto lente.

La piattaforma per cui sviluppavo era Windows NT, con Internet Information Server, e gli applicativi erano realizzati con tecnologia ASP in linguaggio VBScript. Il database era spesso un Microsoft Access (dite quello che volete, ma si tratta di un prodotto miracoloso!) o, quando eravamo fortunati, un SQL Server.

Dopo pochi anni sono passato allo sviluppo per Apache su Linux, ma ho accuratamente scelto di evitare il PHP. So che il PHP è molto amato dalle comunità di sviluppo, ma quando si impara a conoscere un prodotto come ASP, passare al PHP sembra fare salto indietro di secoli. In ASP c'era un solo RecordSet, lo stesso RecordSet di Access, lo stesso di SQL Server, lo stesso di qualsiasi altro database di sistema. Non un RecordSet simile con le stesse funzioni: era proprio la stessa libreria di sistema: di per se, ASP era un sistema molto scarno, ma che si appoggiava largamente alle librerie di Windows.

Nel mondo PHP invece ogni diverso database aveva del codice diverso per essere gestito. La connessione ad un MySql era diversa dalla connessione ad un PostgreSQL, diversa dalla connessione ad un ODBC, diversa la connessione da una qualsiasi altra fonte dati. Diversa da qualsiasi connessione a qualsiasi database sviluppato per la console di Linux o per qualche applicativo client server.

(A vete intuito per quale ragione nel mondo Windows si parla di DLL Hell, mentre nel mondo Linux no? Ho il sospetto che nel mondo Linux vada di moda la riscrittura del codice piuttosto che la condivisione delle librerie... nonostante questo, avrei comunque qualche bella storia di .so Hell da raccontare!)

Per cui ho deciso che lo strumento per cui avrei sviluppato sarebbe stato il linguaggio Perl.
Non si tratta di un linguaggio per puristi, ma in fondo chi se ne importa? Ho programmato in qualsiasi cosa mi sia capitata per le mani, e l'ho trovato fin da subito un prodotto molto efficiente. E pazienza che la sintassi fosse orrenda e poco coerente: una volta abituati al VBScript, non si può che migliorare!

La cosa che mi ha convito fin subito del Perl era la sua immensa collezione di librerie, per connettersi o per gestire qualsiasi cosa (database, periferiche, API di sistema, c'era addirittura del codice per gestire il proprio account MySpace, il tutto via codice...!). Generalmente le librerie del Perl erano di buona qualità e progettate con buon gusto. Inoltre, da non trascurare il fatto che la stessa libreria che si utilizzava per sviluppare applicativi di sistema era la stessa libreria da utilizzare per lo sviluppo Web: avevo finalmente trovato la coerenza anche nel mondo Linux!

Ma soprattutto avevo trovato il miglior framework per il Web esistente sulla terra: HTML::Mason!
Il suo concetto di ereditarietà era favoloso: potevi concentrarti nello scrivere una paginetta che mostrava il contenuto della pagina, e tutto il resto, dal vestito grafico, alle connessioni al database, alle autorizzazioni necessarie, venivano ereditate secondo uno schema deciso in fase di progettazione.

Purtroppo si trattava di un sistema molto difficile da installare e da configurare (non vi sto a raccontare di tutti i conflitti di librerie di sistema per riuscire a farlo funzionare... quando inizi ad utilizzare componenti che non sono presenti in una distribuzione e sono scarsamente utilizzati, anche il mondo dei pacchetti e delle dipendenze mostra i suoi limiti) ma una volta predisposto il tutto diventava uno strumento davvero veloce per sviluppare applicazioni Web complesse.

L'ultimo applicativo che ho sviluppato era una specie di Cartella Clinica, con dati dei pazienti, variazioni anagrafiche, esami di laboratorio, esami radiologici, prescrizioni farmaceutiche, il tutto visualizzabile via Web oppure scaricabile in formato leggibile dal software del medico, previo accesso tramite utente e password.

Le fonti di dati erano MySql, Oracle, SQL Server (eh sì, vi si poteva accedere anche da Linux!), o file di testo importati tramite crontab.
Le pagine erano realizzate in XHTML, con CSS, con qualche bello spunto preso da CSS Zen Garden. JavaScript, come era giusto fare al tempo, era ridotto al minimo e si limitava a pre-convalidare i Form.

Poi si sa come vanno le cose nella pubblica amministrazione. Lo sviluppo interno viene abbandonato, e viene appaltato all'esterno. Così il mio lavoro non consiste più nel progettare e realizzare programmi, ma consiste nel riuscire a far funzionare programmi scritti da terzi, con tecniche di programmazione arcaiche e/o discutibili, e che probabilmente sicuramente avrei potuto scrivere meglio!

Negli ultimi cinque anni il mondo del Web è cambiato, il nuovo Web si chiama Web 2.0.
Cosa bisogna imparare per restare al passo?
Ho scelto di utilizzare il Google App Engine, questo richiede di imparare a programmare in Python ma (database a parte) tutto ciò che si utilizzava sotto Apache è ancora molto attuale. E all'autenticazione, il lato debole di ogni applicativo Web, non ci pensa più il programmatore ma se ne occupa Google!
La lista seguente serve soprattutto a me, per capire che cosa è cambiato dal punto in cui ero rimasto. Non è definitiva e la aggiornerò quando serve:

  • XHTML è stato abbandonato. Il successore di HTML4.01 è HTML5
  • Un applicativo, per essere funzionale ed apparire moderno, deve utilizzare AJAX
  • Utilizzare JavaScript non è più un tabù!
  • Creare a mano il proprio JavaScript è tabù: dove possibile, utilizzare JQuery o altre librerie standard!
  • Il framework standard di Google App Engine è Django. Non so se sarà il mio preferito, forse dovrei approfondire Pylons (che deriva in qualche modo da HTML::Mason)
  • Non bisogna dimenticarsi di integrare il proprio applicativo con Facebook e altri social networks, come ad esempio Google+.
Happy coding!

18 apr 2011

S-ciopa, el dissionario rùstego

Sulla falsa riga di urbandictionary, ed aiutato dall'estrema pazzia della mia amica Marina, è con estrema fierezza che presento S-ciopa, el dissionario rùstego!

Il progetto è realizzato in Python, e sfrutta il Google App Engine. Lato programmazione potrei fare di meglio, lo so, ma una volta tanto ho pensato di puntare di più sui contenuti, e lasciare lo sviluppo nei ritagli di tempo. Poi si vedrà, non è ancora finita :-)

Naturalmente di dizionari Veneti autorevoli se ne trovano quanti se ne vuole, sul web o in libreria. Con questo progetto volevamo soltanto dimostrare al mondo (se mai ce ne fosse ancora bisogno...) che forse forse un po' di svitol nelle rotelle della testa ci manca anche a noi...

5 mar 2011

Free e-books e audio-books

Project Gutemberg: raccolta di libri di pubblico dominio in formato elettronico.

LibriVox: raccolta di audio books di pubblico dominio, letti da volontari :-)

4 mar 2011

Scorrere un file in perl

Per scorrere un file in Perl con record a larghezza fissa, si può partire da questo codice:
#!/usr/bin/perl -w

open(my $fh, "<", $nomefile) or die $!;

while(read($fh, $buf, larghezza)) {
  # fai qualcosa con $buf, es. richiama la funzione unpack
}
se invece si vuole leggere un file di testo, con gli a capo al punto giusto, si può usare questo codice che legge tutto il file e lo carica in un array:
#!/usr/bin/perl -w

open(SRC, $nomefile) || die("Impossibile aprire il file di origine!");
@righe=;
close(SRC);
oppure si può leggere lo stesso file, ma una riga per volta:
#!/usr/bin/perl -w

open(SRC, $nomefile) || die("Impossibile aprire il file di origine!");
while () {
  # fai qualcosa con la riga corrente $_
}
sono banalità, ma siccome non programmo mai con un unico linguaggio di programmazione ma con quello che capita... non mi ricordo mai le sintassi, e allora le scrivo qui così le ritrovo subito! Naturalmente in Perl ci sono altri mille modi diversi per leggere un file!

Come leggere l'elenco di file in una directory in perl?

Utilizzando il perl, come si può ottenere l'elenco di file presenti nella directory corrente? È semplice, ma siccome non mi ricordo mai lo posto qui!
#!/usr/bin/perl -w

@files = <*.txt>;
foreach $file (@files) {
  print $file . "\n";
}
in questo caso vengono listati tutti i files con estensione .txt.

18 gen 2011

CSS-101: The easy way to learn CSS

Ho letto la segnalazione nella Smashing Newsletter numero 25, e la rilancio qui per ricordarmi di controllare quando avrò un po' di tempo! :-)

Libri e video sono ottimi strumenti per lo studio, ma quando si tratta di CSS i tutorial on line si rivelano spesso migliori, perché permettono di giocare con il codice, e vedere i risultati al volo.

In questo sito sono raccolti molti trucchi, e molte spiegazioni sul perché un certo comando produce un determinato risultato:

CSS 101

Non ho ancora provato, ma non voglio lasciarmi sfuggire questo link!

12 gen 2011

New song: Tie me up!

Dopo un lungo periodo di silenzio, finalmente riesco a pubblicare un nuovo pezzo strumentale intitolato Tie me up! :-)

ho ancora molti progetti vaganti nell'hard disk... spero di completarli e pubblicarli presto!

Free MP3s on Last.fm