Il problema, che al solito si verificava solo su Internet Explorer (dalla versione 6 in avanti, almeno fino alla 8, non ho verificato la 9), impediva agli sfortunati utilizzatori di questo browser, di scaricare file pdf generati dall’applicazione web.

Internet Explorer, oltre a non rispettare correttamente tutti gli header http che l’applicazione web genera, ha infatti un bug che impedisce di scaricare file pdf se la connessione è protetta da SSL, come riportato dalla stessa microsoft

When you try to open a Microsoft Office document or a PDF file by typing an HTTPS URL for the document in the Address bar of Internet Explorer 6 Service Pack 1 (SP1), you may receive the following error message:
Unable to download.
Internet Explorer was unable to open this site. The requested site is either unavailable or cannot be found. Please try again later.

header("Pragma: ");
header("Cache-Control: ");

Nel mio caso, essendo l’applicazione web sviluppata con Symfony 1.4, ho modificato il tutto nel seguente modo:

$response->clearHttpHeaders();
$response->setContentType('application/force-download');
/**
* Empty pragma and cache-control to allow IEx to download file through ssl
* http://support.microsoft.com/kb/323308/en-us
**/
$response->setHttpHeader('Pragma','',true);
$response->setHttpHeader('Cache-Control','',true);
/*************************************************/
$response->setHttpHeader('Content-Disposition', 'attachement; filename='.$this->filename, true);
$response->setContent(file_get_contents($filename));
return sfView::NONE;

Ossia per precauzione cancello tutti gli header http eventualmente settati nella risposta, quindi setto il content-type ad application/force-download per evitare un altro comportamento non desiderato di ie, procedo settando gli header pragma e cache-control vuoti, metto nel content della risposta il contenuto del file che voglio far scaricare e quindi disabilito la vista.

Ovviamente con tutti gli altri browser testati (Firefox 3 e superiori, Chrome 9+, Opera 10+) funzionava senza alcun problema anche in precedenza.

La morale è: per favore non utilizzate Internet Explorer, usate un browser rispettoso degli standard web, possibilmente aggiornato e per il quale non sia necessario per funzionare ricorrere sempre ad hack e workaround vari.
Consiglio sempre, sia quando mi trovo nei peggiori bar di Caracas sia nelle applicazioni web che sviluppo e/o mantengo, il sito abetterbrowser in cui vengono consigliati alcuni browser alternativi e migliori.

Per fare ciò è necessario preparare il nostro ambiente di sviluppo, installando e configurando i componenti necessari.

Analogamente a ciò che uso in ambito lavorativo, sia il sistema operativo che l’IDE sono rimasti gli stessi, ossia Ubuntu 10.10 e Eclipse 3.6.

Oltre a questi sono però necessari dei componenti aggiuntivi, specifici per lo sviluppo di applicazioni per Android.

In questo primo articolo vedremo quali sono e come configurarli:

• java 5+
• Android sdk
• Android Development Toolkit (ADT) per Eclipse

java 5+

Su Ubuntu aprite Synaptic (Sistema > Amministrazione > Gestione Pacchetti), cercate openjdk, ed installate, i pacchetti openjdk-6-jre e openjdk-6-jdk.

Per verificare la versione aprite il terminale (Applicazioni > Accessori > Terminale) e digitate java -version

java version "1.6.0_20"

OpenJDK Server VM (build 19.0-b09, mixed mode)

e javac -version

javac 1.6.0_20

Android sdk (starter package)

La pagina di riferimento è sul sito developer.android.com. Io nella fattispecie ho scaricato l’sdk starter package per Linux(1): android-sdk_r16-linux_x86.tgz.

Una volta scaricato estraetelo e spostate la cartella android-sdk-linux_x86 dove preferite; io l’ho spostata in /opt.

Portatevi quindi all’interno di tale cartella (/opt/android-sdk-linux_x86), entrate nella sottocartella tools e fate doppio click sul file android e confermate l’esecuzione.

Avete appena avviato il setup dell’sdk di Android, mediante il quale andremo prima ad installare ed aggiornare tutti i componenti necessari, e quindi ad aggiungere almeno un virtual device.

Per aggiornare tutti i componenti è sufficiente portarsi nel tab “Installed packages”, cliccare “Update All…” e confermare. Dopo qualche minuto, in base alla vostra connessione, avrete tutti i componenti dell’sdk installati.(2)

Adesso creiamo anche un virtual device, ossia un device Android virtuale (AVD) che useremo per provare le applicazioni che svilupperemo.

Per fare ciò riportatevi nel tab “Virtual devices”, click su New e createne uno con le specifiche che più fanno al caso vostro (io ho scelto come target API, la versione 2.2 di android).

Android Development Toolkit (ADT)

Google ha creato uno splendido plugin per Eclipse(3) che velocizza e semplifica molto lo sviluppo di applicazioni per Android.

Per installare il plugin ADT (4) all’interno del vostro Eclipse, dovete aprire Help > Install new software, ed aggiungere una nuova sorgente con il seguente url:

https://dl-ssl.google.com/android/eclipse/

Quindi selezionate Developer Tools e procedete con l’installazione.

Riavviate Eclipse, aggiungete le perspective Java e DDMS, infine collegate l’sdk di Android precedentemente installato, andando in Window > Preferences > Android, e scegliendo la directory dove avete installato l’sdk (nel mio caso /opt/android-sdk-linux_x86).

Avete finito. Ora siete pronti per creare la vostra prima applicazione Android.

In un prossimo articolo vedremo quanto sia veloce creare l’Hello World per Android e iniziare lo sviluppo di applicazioni più complesse, attingendo e studiando dai molti tutorial disponibili online e dai sorgenti delle numerose applicazioni Open Source disponibili.

Aggiornamento del 3 dicembre 2011

Con le ultime versioni dell’sdk di android (> r15) l’interfaccia è cambiata un po’ ma i concetti rimangono gli stessi.

Una volta lanciato scaricato ed estratto l’sdk e lanciato android, è sufficiente selezionare i pacchetti che ci interessano, io ad esempio avendo un HTC desire con Android 2.2 ho scaricato le API v8, comprese quelle di Google Maps.

Anche il plugin di Eclipse è stato migliorato, ora una volta installato vi presenterà al primo avvio una finestra in cui collegare l’sdk di android che avete precedentemente installato (o nel caso non lo abbiate gia fatto potrete scaricarlo e installarlo direttamente da qui).

Note:

1) L’sdk di Android è multipiattaforma e funziona oltre che in Linux, sia sotto Windows che Mac OS X. Questo è uno dei tanti punti di forza di Android.

2) Se volete sviluppare applicazioni che usano le google maps, allora è necessario che installiate anche tali api. Queste API si trovano in Available packages > Third party Add-ons > Google Inc. Io ho installato la versione Android API 8, revision 2, dato che sto sperimentando con l’applicazione Open Source GPS Share.

3) Se non avete già installato Eclipse, vi basta scaricarne una versione dal sito ufficiale, io vi consiglio Eclipse IDE for Java Developers, o in alternativa installare l’ultima versione pacchettizzata da Ubuntu (al momento Eclipse 3.5.2), sempre con il solito Synaptic.

4) Nel caso in cui non riusciate ad installare il plugin ADT per Eclipse e l’errore sia questo ‘missing “org.eclipse.wst.sse.core 0.0.0″‘, vi basta aggiungere ai repository software di Eclipse quello per la vostra versione, ossia http://download.eclipse.org/releases/indigo nel caso abbiate installato la versione Indigo di Eclipse (sostituite Indigo con Helios, Galileo etc. a seconda della vostra versione). Così facendo e ripetendo l’installazione di ADT le dipendenze mancanti verranno recuperate dal repository appena aggiunto.

Guide di Riferimento:

http://www.techhamlet.com/2010/09/test-android-applications/

http://www.techhamlet.com/2010/10/android-application-development-with-eclipse-ide/

La novità però, almeno per me, è stata “La tecnica del pomodoro“.
L’idea alla base è quella di suddividere il tempo in pomodori, ognuno della durata di 25 minuti + 2/3 di pausa.
Come prima cosa si scrivono su un foglio le varie attività da svolgere; in seconda battuta (e qui sta una delle principali difficoltà) ne si stima la durata in pomodori, disegnando n figure geometriche uguali a fianco di ognuna (es. refactoring: 0 0 0; ossia 3 pomodori). A questo punto si scelgono quelle da fare giorno per giorno (attività di pianificazione).

Si inizia quindi con la prima. Ogni pomodoro (25 minuti) ci si ferma, ci si distrae per 2/3 minuti, lo si segna come svolto (barrandolo con una x), si ripunta il timer e via. Ogni 4 pomodori ci si ferma per un poco di più, 10/15 minuti circa, in modo da ricaricarsi.
Se la stima è corretta dopo i pomodori previsti il lavoro è terminato; altrimenti o si è finito prima (e quindi si passa ad un’altra attività) oppure i pomodori non sono stati sufficienti ed allora, in base al lavoro svolto e a quello mancante si effettua una nuova stima, da segnare con una figura geometrica diversa dalla prima.
Bisogna ridurre al minimo le interruzioni durante i pomodori. Se l’interruzione viene gestita velocemente il pomodoro è ancora buono, altrimenti il pomodoro è perso e non deve venire barrato.
Per i dettagli vi rimando all’ottimo paper (che sto leggendo) di Francesco Cirillo.
Obiettivo è quello di organizzare meglio il lavoro, evitando di disperdere energie e di farsi prendere dall’ansia soprattutto con l’avvicinarsi delle scadenze.

La Tecnica del Pomodoro nasce con l’obiettivo di utilizzare il tempo come un utile alleato per realizzare le proprie attività nel modo desiderato e consentire un continuo miglioramento nel proprio processo di lavoro o studio. [...]
Tentando di confrontarsi con il tempo che passa, ci si sente inadeguati, oppressi, schiavi, vinti, ogni secondo di più. Si perde lo slancio vitale (3) che ci consente di realizzare attività: “sono passate due ore e non ho ancora finito; sono passati due giorni e ancora non ho finito”. Nei momenti di debolezza, lo scopo di realizzare attività tende a non essere più chiaro. [...]

Su flickr ci sono alcune foto dell’agile day 2006.

Ciao pestiferi!
Non voglio infierire ulteriormente, ma secondo me vi siete persi un’ottima occasione per capire come le metodologie agili si concretizzano e quali benefici apportano allo sviluppo del software, nonché alla gestione e razionalizzazione dei processi produttivi e gestionali.

Per quanto mi riguarda fino a poco temo fa avevo un’idea piuttosto teorica delle metodologie agili, avevo leggiucchiato qua e la articoli presi sul web (refactoring, TDD, ecc…), poi ho iniziato con il libro di Kent Beck (Padre dell XP) Extreme Programming Explained che non sono ancora riuscito a finire: non so voi, ma non riesco proprio a stare senza scrivere codice quando sento certe cose…

Beh, veniamo all’incontro.
Dunque, si è tenuto all’interno di un teatro, i presenti erano circa ottanta il che dava idea di come questo tipo di approccio sia sentito a livello italiano…
I primi ad intervenire sono stati i responsabili (team manager e coach) del team di sviluppo di Ferrari Sport, per intenderci quelli che la domenica trasportano la loro server farm ai box dei circuiti di GP.
Due tipi brillantissimi!
Loro hanno esposto la loro esperienza di utilizzo delle metodologie agili ed il loro approccio all’XP.
Tengo a sottolineare LORO in quanto non esiste un metodo valido per tutte le realtà; ognuno utilizza l’XP nel modo in cui essa riuscirà ad apportare i maggiori benefici al suo processo di lavoro.
Sarebbe sbagliatissimo, nonché controproducente, pensare al raggiungimento dei principi di XP come una cosa fine a se stessa!
Il loro team di programmatori è composto da 30 elementi; loro sviluppano tutto il software che va dal gestionale al supercalcolo e telemetrie; rilasciano una media di 50 versioni al mese! Lavorano su piattaforma Microsoft.

In ogni modo domani sera racconterò tutto per filo e per segno di persona al Pestifero: certe cose non si possono tenere solo per se!
Mi permetto però di darvi in primis due dritte e poi concludo con degli estratti del discorso di Francesco Cirillo: massimo esponente nonché importatore dell’XP in Italia; è stato allivo di Kent Beck …
Le dritte riguardano Ruby e Ruby On Rails, vi consiglio vivamente di darci un’occhiata se vi capita: http://www.rubyonrails.org/ da lì andate sul wiki e poi via!

Concludo anticipandovi che l’XP è descritta attraverso dei principi individuati da K. Beck, uno dei quali mi è rimasto impresso maggiormente, forse perché senza saperlo lo praticavo già: consiste nel trasformare ogni problema in un’opportunità; quindi avere dei problemi è fondamentale per riuscire poi a migliorarsi… Anche qui ce ne sarebbe da dire.
Ho buttato giù tutto di pugno, quindi scusate la (magari) non coerenza e l’italiano, c’ho da lavorare adesso.
Auguro a tutti un Buon Natale e Ste ci vediamo domani!

milo

Come sviluppare del (buon) software?
E’ una domanda alla quale l’ingegneria del software cerca di dare risposta da molto tempo, proponendo diversi cicli di vita del software.
Riflettiamo sulle metafore di cattedrale, bazaar e kibbutz.

Eric Raymond nell’oramai famoso saggio “La cattedrale e il bazaar” ha descritto il modello di sviluppo del software open source, nel quale il codice sorgente è disponibile e modificabile da tutti.

Perché bazaar?

http://www.apogeonline.com/openpress/doc/cathedral.html">

Rimasi non poco sorpreso dallo stile di sviluppo proprio di Linus Torvalds – diffondere le release presto e spesso, delegare ad altri tutto il possibile, essere aperti fino alla promiscuità. Nessuna cattedrale da costruire in silenzio e reverenza.
Piuttosto, la comunità Linux assomigliava a un grande e confusionario bazaar, pullulante di progetti e approcci tra loro diversi.

Le differenze principali di questo approccio, rispetto a quello “a cattedrale” utilizzato nel software proprietario sviluppato dalle aziende, sono proprio queste. Sebbene le risorse non siano ben definite, il planning venga fatto man mano e i co-sviluppatori non percepiscano uno stipendio, i vantaggi di questo approccio sono numerosi e sul lungo periodo destinato ad avere il sopravvento (in determinati contesti); la cosiddetta FOSS era.
Quali sono i vantaggi?

• Trattare gli utenti come co-sviluppatori è la strada migliore per ottenere rapidi miglioramenti del codice e debugging efficace.
• Distribuisci presto. Distribuisci spesso. E presta ascolto agli utenti.
• Se tratti i tuoi beta-tester come se fossero la tua risorsa più importante, essi risponderanno diventando la tua risorsa più importante; se ci sono abbastanza occhi, che cercano errori, gli errori diventano di poco conto
• La cosa migliore, dopo l’avere buone idee, è riconoscere quelle che arrivano dagli utenti. Qualche volta sono le migliori.
• molte teste funzionano inevitabilmente meglio di una sola.

Il resto lo trovate appunto nel saggio “La cattedrale e il Bazaar“.

Purtroppo però (e per fortuna, per altri motivi e in altri contesti che non approfondirò ora) questo approccio non sempre è adatto.
Il caso di Wikipedia ne è l’esempio.

http://www.macitynet.it/macity/aA23243/index.shtml">

i contenuti anonimi o pseudo-anonimi messi online sono alle volte un po’ problematici. Prendono posizioni, censurano punti di vista, scrivono cose non veritiere

In questo contesto l’anonimato diventa un problema importante, al quale bisogna far fronte. O con degli accorgimenti o con un cambio alla base, un nuovo approccio, il kibbutz.

Ma in realtà, rispetto anche ad altri modelli di sviluppo collaborativo come nel caso di Linux per quanto attiene alla tecnologia software, pare che invece manchi un modello di sviluppo basato su una autorità carismatica. Nel caso specifico, Linus Torvalds, ma non solo. E’ probabilmente comune a molte comunità non solo la coesione ma anche il riconoscimento di una autorità morale.

Mattia Monga, un ricercatore del dico dell’università statale di Milano, propone appunto la metafora del kibbutz, in relazione allo sviluppo del progetto Debian (pdf, 54kb – eng).

Riferimenti:
La cattedrale e il bazaar
Piccoli grandi problemi per l’enciclopedia libera
Froom Bazaar to Kibbutz (pdf, 54kb – eng)
Wikipedia – La cattedrale e il bazaar