Com\’è dura la professione!

27 settembre 2006

Se può essere fatto, qualcuno lo farà.

Filed under: cosi' va il mondo,Microsoft — lbell @ 18:41

Un problema di sicurezza in Internet Explorer viene trascurato da mamma Microsoft, tanto che la correzione viene pianificata con un ritardo di tre settimane. Chi non la trascura invece sono i soliti malintenzionati che mettono Internet Explorer subito sotto attacco. A causa della pressione dell’utenza mamma Microsoft oggi rilascia la correzione, ma viene preceduto da un gruppo di sicurezza privato che ne rilascia una propria non ufficiale. Che la comunità stia iniziando piano piano a muoversi verso mamma MS?

Quello che si impara da questa storia è che ogni problema di sicurezza per quanto piccolo o complicato da utilizzare per realizzare un exploit, sarà comunque sfruttato da qualcuno.

 

Annunci

26 settembre 2006

Voto elettronico? No, grazie.

Filed under: cosi' va il mondo,Open Source,paranoia,Programmazione — lbell @ 20:26

Leggendo che in America sale la polemica sullo scrutinio elettronico, penso ad una sua futura introduzione in Italia. Le macchine utilizzate finora sembra abbiano dato cattiva prova di garanzia e sicurezza, tanto che perfino Martin Fowler (che è Martin Fowler) è sceso in campo con le parole che trovate in questo link. Come chiunque abbia programmato almeno un poco sa, la minaccia riguarda la trasparenza del voto. Utilizzando un sistema chiuso con software proprietario nessuno è in grado di garantire la correttezza delle operazioni, e non si parla solo di brogli voluti, ma anche di errori accidentali. Come sapere se le macchine si comportano bene? Chi può garantire che i votanti non saranno schedati se i programmi utilizzati nelle operazioni resteranno segreti? Un comitato di saggi che faranno un esame del codice? Realisticamente non si può. Oggi, almeno, lo scrutinio viene eseguito davanti a rappresentanti di tutti i partiti. Quando sarà tutto demandato alle macchine, chi potrà garantire qualcosa con sicurezza? Se nel mondo degli applicativi per ufficio la correttezza dei programmi è un problema tra l’utilizzatore ed il produttore, dato che la procedura operativa non è segreta, nel mondo della politica e del confronto fra cittadini occorre utilizzare altri criteri di giudizio.

 

Riporto un estratto dall’articolo di Fowler, grassetti compresi:

I cannot understand how a voting machine without a clear, auditable paper trail could be considered acceptable for voting. (…)

I don’t pay concentrated attention to this issue, but I do think it’s important for those of us in the software field to make our professional opinions on this topic clear.”

 

E da noi, qualcuno ha qualcosa da dire su di un argomento così importante? A nessuno interessa se l’avversario politico vince per un pugno di voti contestati? (Dove l’ho già sentita?)

Ok, basta paranoia per oggi.

14 settembre 2006

Estrarre testo da un file OpenDocument con PHP 5

Filed under: php,Programmazione — lbell @ 23:14

Il formato OpenDocument ci permette di manipolare i documenti possedendo solo qualche nozione di Xml. Stavo facendo delle prove di estrazione di testo con PHP 5 da un documento in modo dal poterlo indicizzare, cercando di scrivere meno codice possibile e ho prodotto una ventina di righe, utilizzando le librerie SimpleXML e unzip, una utility a linea di comando dato un documento con un certo nome di file fisso (diciamo b.odt) Attezione: se intendete provare questo programma sappiate che vi crea/sovrascrive un eventuale file content.xml nella directory di lavoro

<?php
function esegui($docname)
{
  shell_exec('/usr/bin/unzip'.' '.$docname .'  content.xml');
  $xml = simplexml_load_file('content.xml');
  $nodes = $xml->xpath('//text:p');
  foreach( $nodes as $item )
    echo $item." ";
  //unlink  commentato per evitare malintesi
}
esegui('b.odt');
?>

ed ottengo il testo. 12 righe di codice (commenti compresi) per ricavare il contenuto di un documento. Non male, ma si può fare di meglio: 1 riga sola

 

<?php shell_exec('/usr/bin/unzip b.odt content.xml');foreach( simplexml_load_file('content.xml')->xpath('//text:p') as $item ) echo $item." ";?>

e funziona. Dopo tante esperienze di programmazione non sono più abituato alla semplicità. Grazie a PHP ed a OpenDocument.

12 settembre 2006

From Java to Ruby

Filed under: Java,Programmazione,RubyOnRails — lbell @ 20:13

Finalmente il libro di Bruce Tate è arrivato. Dalla prefazione leggo ‘Sapevo che Java non era la soluzione a tutti i problemi’ e fin qui nulla di strano. Ma prosegue con ‘vedevo che i visionari di Java lo stavano abbandonando man mano che riconoscevano problemi di produttività e di complessità’ e qui la cosa si fa interessante. Poi si parla di proliferazione di framework, di complessità crescente del mondo Java, mentre l’esplosione di Ruby sta conquistando gli sviluppatori con la sua rapidità di implementazione. La parola d’ordine di Ruby e Rails è semplicità e produttività.
Il libro sembra interessante e orientato alla valutazione della gestione di progetti software con i due linguaggi e rispettivi framework, proprio il tipo di cosa che può far finire una carriera lavorativa. Una lettura interessante, ma potrà cambiare il mio lavoro? Spero solo che non sia la solita agiografia; a questo mondo c’è certamente posto sia per Ruby che per Java. A Ruby però ora come ora mancano diverse funzionalità di tipo ‘enterprise’ come ad esempio le transazioni distribuite. Che il libro sia la chiave per una integrazione felice?

7 settembre 2006

Qualche divagazione su Rails

Filed under: Programmazione,RubyOnRails — lbell @ 21:02

Orm (Object-relational mapping) è un insieme di tecniche per modellare i dati residenti su database relazionali sugli oggetti dei linguaggi di programmazione object oriented. Serve a spostare la gestione dei dati in territori familiari ai programmatori di applicativi, cambiando il paradigma di programmazione, mappando dati e relazioni gestiti dal database in tipi di dato e relazioni che i programmatori sono abituati a trattare.

Dobbiamo utilizzare queste tecniche continuando a basarci su database relazionali invece di passare a motori di archiviazione object oriented adatti alla memorizzazione degli oggetti ‘da programmatori’ sia perché il database relazionale è utilizzato da tutta una serie di programmi esistenti, sia perché un ripensamento totale del motore di archiviazione è un salto nel buio per quello che riguarda affidabilità e costi senza contare che il cliente finale spesso utilizza strumenti per la generazione di report ed elaborazioni che agiscono direttamente su database.

Per ora dobbiamo tenerci due domini diversi ed utilizzare uno strato di software per metterli in comunicazione. Un grosso inconveniente è che l’interfaccia fra questi due mondi, così come viene realizzata nelle tecniche più diffuse (Hibernate ad esempio), è statica e spesso si aggiorna un modello all’insaputa dell’altro.

Un altro grosso difetto è che vi sono modi diversi di identificare le entità tra i due mondi, per non parlare della corrispondenza fra i tipi di dato. Un oggetto in Java o C++ si identifica con un puntatore o una referenza, mentre un database sfrutta il valore dei suoi attributi, ma in certi casi si può avere una sovrapposizione. Nella programmazione distribuita l’identità di un oggetto non si può più verificare tramite un indirizzo di memoria, a meno di non usare un guid. Nei database d’altronde possiamo evitare di creare una chiave univoca sulle tabelle salvo non riuscire più ad indirizzare singolarmente più record con gli stessi attributi (in questo vi sono similitudini con la meccanica statistica sull’identificazione delle particelle).

L’approccio ad attributi sul database è insoddisfacente; se consideriamo la rappresentazione di una persona possiamo utilizzare come chiave il codice fiscale, ma cosa succede se un codice fiscale che ci arriva da una autorità esterna, si rivela errato o deve essere cambiato? Cosa succede ai dati delle tabelle collegate che lo utilizzano come chiave esterna? Non sarebbe meglio che ogni tabella avesse un campo identificativo interno non assegnabile da programma? Dopotutto una persona è una persona e se riesco a distinguerle nel mondo reale anche senza conoscerne il codice fiscale perché non posso farlo anche nell’astrazione che utilizzo per modellarlo nel mio database?

Ci sarebbe da discutere parecchio di forme normali, di variazioni nel tempo dei requisiti delle chiavi primarie e così via, e qui entra in campo Rails.

Rails sta spopolando nel realizzare una mappatura tra oggetti ‘da programmatori’ e ‘da database’ ed è di uso immediato quando le tabelle sono relazionate tramite campi identificatore. Lo scopo di Rails è di scrivere meno codice possibile sfruttando una serie di convenzioni. E’ possibile utilizzare Rails sfruttando gli insiemi di attributi come chiavi, ma occorre configurare ogni relazione e questo va contro lo scopo di Rails. Quando si usa uno strumento occorre assecondarlo, non combatterlo, oppure è meglio trovare uno strumento più adatto.

L’altro problema spinoso di ORM è il mapping dei tipi di dato che non coincidono perfettamente. Ad oggi la definizione è duplice, occorre definirli sia nel database che nei programmi applicativi utilizzando le categorie disponibili in ciascun campo, aprendo la porta ad una serie di problemi di allineamento e consistenza.

Usare Rails per applicazioni di una certa dimensione ci porta a dover risolvere il problema di come gestire i campi degli oggetti. Al contrario di Hibernate, Rails fa uso del pattern ActiveRecord, quindi non esistono campi predefiniti, ma i campi riflettono il reale contenuto del database. Hibernate al contrario pretende una mappatura esplicita tra i membri degli oggetti e campi; ovviamente i dati in questo modo sono definiti due volte ed occorre preoccuparsi della relativa sincronizzazione.

 

Ancora un ritardo della PlayStation 3

Filed under: Microsoft — lbell @ 20:05

Sembra che le cose si stiano mettendo piuttosto bene per Microsoft anche nel settore delle console, visti i continui ritardi della PS3, (un altro annunciato ieri per la versione europea). Mamma Microsoft ha le spalle talmente larghe che si può permettere anni di perdite (la prima XBox) ed approfittare del primo errore degli avversari. Un altro avversario in via di demolizione?

5 settembre 2006

Vecchi libri ritrovati

Filed under: letture,Mac — lbell @ 20:34

Certe idee non svaniscono, semplicemente cambiano nome.

NeXT e Mac

Blog su WordPress.com.