Vitruvian Tux

Come buona parte dei miei post anche questo nasce, oltre che con l’intento di fare un po’ di informazione, per ricordarmi di come ho già risolto un problema che mi si è presentato: in effetti la mia memoria di solito è fallace e googolare per cercar la stessa informazione più di una volta non mi piace granchè ^_^

Un attività che spesso capita di dover effettuare è quella di processare “on the fly” un file xls (magari disponibile a seguito dell’upload di un utente) e gestire i dati in esso contenuti (possibilmente strutturati come da noi previsto altrimenti la cosa è improponibile..) per, ad esempio, popolare tabelle di un database o più semplicemente visualizzarli sul nostro sito.

Bene, la soluzione a questo problema è più semplice di quanto si pensi.

Esiste infatti un progetto su Sourceforge che tramite la classe ExcelReader rende disponibile tutto ciò che ci occorre.

Dopo aver incluso i due file reader.php e oleread.inc nel nostro script e saremo quindi pronti per svolgere il lavoro “sporco”.

Per prima cosa inizializziamo la nostra classe  e in seguito passiamogli il file da aprire:

$data->read('nome_filel.xls');

la cosa successiva da fare, ovviamente, è effettuare un ciclo per ogni riga e colonna ricordando che:

$data->sheets[0]['numRows'];
$data->sheets[0]['numCols'];

rappresentano rispettivamente il numero di righe e colonne contenute nel file xls (in particolare nel primo foglio del documento).
A questo punto possiamo prelevare il valore contenuto in ogni cella accedendovi come faremo con una banalissima matrice:

$data->sheets[0]['cells'][$i][$j];

Un esempio di script per mostrare a video i dati di un file xls in forma tabellare è quindi il seguente:

<?
require_once 'Excel/reader.php';
$data = new Spreadsheet_Excel_Reader();
$data->setOutputEncoding('CP1251');
$data->read('nome_file.xls');
error_reporting(E_ALL ^ E_NOTICE);

echo "<table>";
for ($i = 1; $i <= $data->sheets[0]['numRows']; $i++) {
        echo "<tr>";
	for ($j = 1; $j <= $data->sheets[0]['numCols']; $j++) {
		echo "<td>".$data->sheets[0]['cells'][$i][$j]."</td>";
	}
	echo "</tr>";
}
echo "</table>";
?>

PS: Ovviamente è possibile ciclare anche sui fogli che compongono il file xls..

Popularity: 8% [?]

Tra i numerosi feed che di giorno in giorno intasano il mio Google Reader solo oggi, scavando scavando, ho trovato una news che in effetti credevo di aver perso tra i tanti post non letti.

Il feed in questione è quello relativo al “TIOBE Programming Community index” di Giugno 2009.

Per chi non lo conoscesse tale indice da una stima, ogni mese, della diffusione d’uso dei vari linguaggi di programmazione esistenti.  Il suo scopo badate bene non è quello di definire il “miglior” linguaggio di programmazione (evitiamo flame in merito.. ogni linguaggio ha un suo campo d’uso – anche se essendo tutti Turing equivalenti il blancio si sposta in effetti solo sulle performace..) bensì di valutare quale è il linguaggio in cui sono state scritte più righe di codice.

E’ una misura come tante altre per valutare la diffusione di un linguaggio. Inoltre tale indice può essere utile per farsi un idea su quali linguaggi al momento sono maggiormente richiesti sul mercato – fa sempre comodo acquisire competenze spendibili nella “real life” ^_^.

Quindi cosa dire.. commenterò giusto le prime 10 posizioni e molto in breve per il resto vi lascio ad una interessante lettura – grafici compresi – alla pagina di riferimento.

Ecco la top ten di Giugno:

1. Java
2. C
3. C++
4. PHP
5. Visual Basic
6. Python
7. C#
8. Javascript
9. Perl
10. Ruby

Commento a caldo:

Ovvie le prime 4 posizioni, immutate da tempo come la 5 del resto. La quinta piazza ammetto che mi da un senso di disgusto – signore proteggici dai batti_tasti VB che si credono programmatori – ma purtroppo tale è la realtà. Python e C# sono cresciuti negli ultimi mesi e devo dire che sono molto felice per il Python un linguaggio molto elegante e pulito che ho avuto modo di apprezzare nell’ultimo anno. Javascript non l’ho mai retto troppo ma è anch’esso in ascesa. Perl sembra in caduta libera in contro tendenza con tutti gli altri linguaggi presenti nella top ten. Ruby è stabile alla decima piazza.. credo che prima o poi dovrò trovare il tempo di dargli un occhio -più dell’infarinatura minima che mi ritrovo  (anche se al momento non mi vengono in mente troppi progetti di dimensioni ragionevoli sviluppati in Ruby.. probabilmente è solo una mia mancanza..).

Bhe questo è tutto.. diciamo che ci possiamo aggiornare con la prossima pubblicazione!!

Popularity: 4% [?]

A seguito del post di ieri (relativo alla scarsa privacy offerta da Facebook) ho iniziato, da bravo informatico, a interrogarmi su alcune implicazioni di quanto riportato.

Premetto che quelle che propongo qui di seguito sono solo supposizioni e non vogliono essere interpretate come realtà assoluta – invito anzi chi abbia voglia a discuterne nei commenti – e che ho deciso di scrivere questo post solo ed esclusivamente per mettere a fuoco qualche dettaglio che può essermi sfuggito.

Riepilogando:  ieri abbiamo visto che, tramite le API offerte da FB agli sviluppatori e un po’ di colpo d’occhio, è possibile ottenere pressappoco tutte(*) le informazioni personali che un qualsiasi utente – pur impostando il proprio profilo come privato – da in pasto al social network in questione.

Fino a qui diciamo che siamo nella “norma”. Il tutto non può essere definito un bug ne una “lack of security” poiché proprio nei termini d’uso delle API del servizio si esprime esplicitamente che i dati ricavati con tale approccio debbano essere cancellati entro le 24 ore. Questo implica che sostanzialmente il tutto era previsto e accettato al momento della pubblicazione delle API.

Ho detto nella “norma”: immagino che qui il concetto sia abbastanza vago e si presti ad interpretazioni, diciamo solo che – almeno dal mio punto di vista – l’accesso a tutte le informazioni di un utenza non hanno molto significato per uno sviluppatore di applicazioni per tale piattaforma.

In fin dei conti a quale applicazione è necessario sapere quali sono i nostri percorsi di studi\interessi musicali\orientamento politico\ etc. etc. ? Questi dati possono essere al più utili a chi ha intenzione di fare delle analisi statistiche e raccolta di dati a fine commerciale (analisi che non potrebbero in ogni caso essere fatte proprio per il limite di “vita” imposto da Fb per i dati ottenuti proprio come dicevo precedentemente).

Diciamo quindi che molto probabilmente è stata fatta una scelta sbagliata relativa alle informazioni da rendere disponibili sugli utenti per salvaguardarne la privacy. Errore non proprio da nulla a mio avviso.

Vediamo inoltre che, per assurdo indagando su una persona in questo modo si possono ottenere tutte le informazioni sui contatti a questa collegati – e via dicendo con un effetto a cascata.

Avevo espresso qualche dubbio a fine articolo relativamente alla possibilità offerta da breve da FB di impostare un nome al nostro account, impostando un url rewriting per rendere più leggibile l’indirizzo della pagina del nostro profilo, e alla possibile “risoluzione” trasversale di questo problema di privacy.

Inizialmente l’idea mi aeva quasi convinto: in fin dei conti se riesco a riscrivere le url di tutti i profili nascondendo le informazioni sull’id del contatto tutte le interrogazioni che posso fare tramite un applicazione scritta con le API prevedono che questi ne autorizzi l’uso. Mi spiego meglio, se io utente non proprietario del contatto non conosco l’id non posso manualmente creare una query ad-hoc. Mentre, al contrario, se sono il proprietario dell’account avrò salvato da qualche parte il mio id (in sessione, in un cookie…) quindi potrò fornirlo di mia volontà all’applicazione.

Che poi possano essere comunque scritte applicazioni “malevole e impiccione” è un altro paio di maniche – fatto stà che l’utente ha in ogni caso modo di non essere passivamente soggetto a indagini mirate. Magra consolazione.

L’idea di nascondere l’id in effetti non era male – unico neo convertire tutti gli account vecchi senza “nome” facendo pressione sugli utenti finali presentando tale possibilità come un semplice abbellimento (si è parlato spesso di “fancy url”).

In ogni caso, purtroppo, seppure la strada era percorribile e forse la più rapida – di certo non la più sicura, ma ovviamente quella che garantiva la migliore retrocompatibilità con le applicazioni già sviluppate  – questa è stata interrotta a metà.

Ebbene si la riscrittura delle url vale solo per la pagina del profilo e non per tutti i link che puntano ad essa. Ad esempio i commenti lasciati hanno ancora un link contente l’id e ciò accade anche per i link per l’invio di messaggi di posta e compagina bella.

Quindi a quanto pare o la “soluzione” è stata percorsa a metà o molto probabilmente l’interesse alla privacy degli utenti è merce più rara di quella che solitamente si ricerca nel comune pensare.

Cosa dire… le soluzioni ci sarebbero, e alcune anche molto ma molto banali – già la scomparsa degli id visibili sarebbe un notevole passo avanti.

(*) Ieri ho parlato solo delle foto perché in effetti mi sembrava poco opportuno dare direttamente la query per ottenere informazioni personali ma, usando la struttura delle tabelle presente nel wiki ufficiale per gli sviluppatori di applicazioni per facebook non ci vuole molto a scriverne di banali per effettuare tali tipologie di ricerche…

Popularity: 7% [?]