Cloud

[Per Andrea B.]

Ma vaffan cloud!


:)

HttpClient - disable follow http redirect

I was playing with Apache DefaultHttpClient on Android. HttpClient follows http redirect by default. But I need to disable it.  I expected a simple set property on HttpClient or HttpGet. I was wrong.  :(
Found two solution after a long googling.

My code:
DefaultHttpClient httpClient = new DefaultHttpClient();
HttpGet httpget = new HttpGet("http://....");


Solution 1: set parameter

DefaultHttpClient httpClient = new DefaultHttpClient();
BasicHttpParams params = new BasicHttpParams();
HttpClientParams.setRedirecting(params, false);
httpClient.setParams(params);
HttpGet httpget = new HttpGet("http://....");

Solution 2 - define my own redirecthandler

DefaultHttpClient httpClient = new DefaultHttpClient();
httpClient.setRedirectHandler(new DefaultRedirectHandler() {
@Override
public boolean isRedirectRequested(HttpResponse response, HttpContext context) {
return false;
}
});
HttpGet httpget = new HttpGet("http://....");

My first Android test app

My first test on Android. A Memory game for my kids.  :)

But it has some bugs. First of all I need to fix the layout when rotated.  :(

GDocBackup 0.4.21.107 released

Updates:

• workarounds for some (still open) Google issues  :)
• many bug fixes
• updated google-gdata library
• beta release notification (optional)

http://gs.fhtino.it/gdocbackup

Torino GTUG ?

Questo Giovedì (9 settembre 2010) proviamo a vedere se riusciamo a formare un GTUG su Torino. (GTUG = Google Technology User Groups).  Se qualcuno è interessato, sarà il benvenuto.

http://torino.gtugs.org/

[Update - Dic. 2010]: community partita e attiva. :)

Invio automatico dei bollettini di Allerta MeteoIdrologica di ARPA Piemonte grazie a Google App Engine

ARPA Piemonte pubblica regolarmente vari bollettini meteo e affini. Tra questi trovo molto utile quello di Allerta MeteoIdrologica. Viene pubblicato tutti i giorni attorno alle ore 13. Il bollettino evidenzia i fenomeni meteo rilevanti nelle 36 ore successive ed i previsti effetti al suolo (smottamenti, problemi alla viabilità, ecc.).

Il territorio piemontese è diviso in 11 zone: i fenomeni sono evidenziati in dettaglio per ogni singola zona.  Per ogni zona è indicato anche un livello di criticità: ordinaria, moderata ed elevata.

Guardando il bollettino ho pensato: mi piacerebbe essere avvisato in caso di una previsione di eventi critici nella mia zona (forte nevicata, piogge intense, esondazioni). Consultando il sito non ho trovato nessun servizio per l'invio automatico, tanto meno un servizio per l'invio "per zone" e in solo in caso di allerta. Che fare? Soluzione: me lo faccio io il servizio!  :)

E' un po' di tempo che stavo provando Google App Engine (la piattaforma di Cloud Computing di Google). Mi è quindi sembrato ovvio fare 1+1.  Ed ecco il risultato:   http://fhtino.appspot.com/bollettino/

E' stata una buona occasione per fare molti esperimenti con i servizi offerti da Google App Engine e non solo.

Un po' di dettagli tecnici:

• gli utenti si registrano inserendo la loro email e scegliendo le zone per cui ricevere i bollettini. Inoltre posso scegliere se ricevere il bollettino tutti i giorni oppure solo in caso di Allerta vera e proprio.
• per evitare lo spam, ho integrato reCaptcha
• via Scheduled Tasks l'applicazione controlla se viene pubblicato un nuovo bollettino (in pdf)
• i dati testuali del bollettino sono estratti grazie ad una versione modificata di PdfBox che può girare su GAE (vedi http://fhtino.blogspot.com/2010/04/pdfbox-text-extration-gae.html). I dati sono quindi ri-organizzati in xml.
• quando l'applicazione trova un nuovo bollettino, invia le email agli utenti (via TaskQueues)
• le informazioni degli utenti e il bollettino attuale (in xml) sono memorizzati nello Storage di GAE

Attenzione: si tratta di un esperimento. I dati potrebbero essere estratti in modo errato e quindi l'applicazione potrebbe inviare avvisi errati. Come ho indicato sul sito, I DATI NON SONO VALIDI.   Comunque l'applicazione sta girando da alcuni mesi e si è sempre comprata bene. Spero che continui così.

Tombino anonimo

Stando ad un articolo su WIRED, questo è il punto di arrivo di uno dei principali cavi sottomarini che attraversano l'oceano Atlantico. L'anonimo tombino è nei pressi di Halifx, Canada.

Guard Clauses & Fail Fast

Recentemente mi è capitato di discutere con un amico di come organizzare il codice all'interno di un metodo. La questione è tutto sommato semplice: unico punto di uscita come indicano i sacri testi oppure un approccio più pragmatico? Io sostengo fortemente il secondo.
Spesso il codice che scriviamo ha tantissime condizioni da controllare. Molte di queste sono in realtà condizioni di esecuzione, cioè condizioni che devono essere soddisfatte per poter poi eseguire il lavoro vero e proprio. Ad esempio, controllare che la connessione a DB sia attiva, che un valore numerico sia compreso in un certo intervallo e così via. Questo tipo di condizioni sono quindi più dei "check" o per dirla con Martin Fowler dei "Guard Clause", clausole di salvaguardia. Riporto l'esempio di Fowler. Partiamo da questo pezzo di codice:

double getPayAmount() {
 double result;
 if (_isDead) result = deadAmount();
 else {
  if (_isSeparated) result = separatedAmount();
  else {
   if (_isRetired) result = retiredAmount();
   else result = normalPayAmount();
  };
 }
return result;
};

Ecco come possiamo riscriverlo in modo molto più chiaro con "guard clauses":

double getPayAmount() { 
  if (_isDead) return deadAmount();
  if (_isSeparated) return separatedAmount();
  if (_isRetired) return retiredAmount();
  return normalPayAmount();
};

Questo modo di scrivere codice ha secondo me anche altri vantaggi oltre alla chiarezza. In primo luogo concentra nella parte iniziale tutti i controlli di accesso rendendo più facile il test ed il debug e semplifica l'aggiunta/modifica dei check stessi. Altro vantaggio è che si trova la strada facilitata per implementare un approccio "Fail Fast" (vedere qui l'articolo di Jim Shore).
Fail Fast è un approccio che condivido moltissimo. Il ragionamento di base è molto semplice: meglio un'applicazione che si pianta inaspettatamente che una che va avanti in condizioni precarie nascondendo gli errori. Mi conforta che questo è anche l'approccio scelto per la gestione delle eccezioni di background in .NET 2.0, che cambia radicalmente l'approccio rispetto a NET 1.0 / 1.1 che invece ignorava e nascondeva.

Torniamo a "Clause Guard": metto in testa tutti i controlli; per ogni controllo posso decidere se gestire la condizione e uscire in modo controllato dal metodo oppure se considerare la condizione come anomala e quindi sollevare un Exception.
Certamente Fail Fast è un approccio più ampio che non si limita a sollevare eccezioni nei controlli del codice. Ma indubbiamente i due metodi si sposano molto bene.

PdfBox text extraction & GAE

How to do text extraction from pdf files using PdfBox on Google App Engine

(Warning: I used an old version of PdfBox: 0.7.3.)

PdfBox is a very popular Java library for creating and managing pdf files. It's also able to extract text from existing pdf files. Pdfbox is published as a jar file.
I'd like to use it on Google App Engine (java version) for text extraction from particular area of the page of pdf files. PdfBox allows that. The class to use is PDFTextStripperByArea. I tried it but GAE blocked me: PDFTextStripperByArea uses not allowed JRE classes. In particular jawa.awt.Rectangle and Rectangle2D. GAE applies a "white list" approach: only a subset of the standard JRE classes is allowed to run on GAE. 99% of Java.awt.* is blocked. http://code.google.com/appengine/docs/java/jrewhitelist.html
There is also another problem. During text extraction PdfBox uses a temp file. By default it's created on the file-system. GAE also blocks the access to the file-system.

My solution was:

• use my own Rectangle instead of java.awt.Rectangle
• use a "in memory" temp file

The first required modification and recompilation of PdfBox.

My own Rectangle

I created my own Rectangle and Rectangle2D classes. My rectangle implementation is not complete compared to the awt one. I only created fields and methods required.
Than I created a new PDFTextStripperByArea: PDFTextStripperByAreaGAE. I not modified the original PDFTextStripperByArea because I didn't want to break the PdfBox library compatibility.
The new class only use my Rectangle. No more references to java.awt. So now GAE allows it to run.
The new PDFTextStripperByAreaGAE is equal to the old PDFTextStripperByArea . The only difference is the use of my Rectangle instead of java.awt.Rectangle. I copied and pasted 99% of the original code.

Temp file in memory

PdfBox uses File System by default. But you can force it to use a "in memory" buffer. PdfBox ships with org.pdfbox.io.RandomAccessBuffer. I use it.


byte[] pdfBytes; // contains the bytes of the Pdf file
RandomAccessBuffer tempMemBuffer = new RandomAccessBuffer();
PDDocument doc = PDDocument.load(new ByteArrayInputStream(pdfBytes), tempMemBuffer);
PDFTextStripperByAreaGAE sa = new PDFTextStripperByAreaGAE();
sa.addRegion("Area1", new Rectangle(26, 86, 62, 10));
sa.addRegion("Area2", new Rectangle(99, 86, 94, 14));
...
PDPage p = (PDPage) doc.getDocumentCatalog().getAllPages().get(0); // page 1
sa.extractRegions(p);
String area1 = sa.getTextForRegion("Area1")
String area2 = sa.getTextForRegion("Area2")
...
doc.close();

Live demo

http://fhtino.appspot.com/PdfBoxGAE/demo.jsp

(please, use small pdf files)

Spunti interessanti dalle slide di Jeff Dean

Stavo guardando le slide che Jeff Dean (Google) ha presentato alla Cornell University:
http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf

Moltissimi spunti interessanti conditi con mie considerazioni:

• le cose (server, dischi, schede e apparati di rete, ecc.) si rompono: bisogna imparare a gestire la cosa. Non fare finta che non possa accadere.
• sviluppare servizi "interni", con poche dipendenze, chiare e documentate
• usare "protocolli"  (strutture dati) che possono evolvere in modo trasparente per i "sistemi intermedi" (ogni applicazione capisce i propri "tag")
• conoscere i  "numeri base" del performance di trasferimento dati in condizioni diverse (memoria, disco, lan, rete geografica, ecc.)
• fare fronte alle richieste degli utenti senza far esplodere il sistema in termini di complessità. Oltre un certo punto, per far fronte a tutte le richieste, il sistema diventa troppo complesso e costoso.
• sviluppare infrastrutture (e software) in base ad esigenze reali e non speculare su possibili esigenze future che, ad oggi, non esistono.  Considerare invece come le esigenze attuale potrebbero evolvere.
• la velocità di risposta delle applicazioni è molto importante. Attenzione alla latenza.

GDocBackup 0.4.13.87 released

Added support for pdf export and other minor fixes/enhancements.

http://gs.fhtino.it/gdocbackup

C'è sempre da imparare dagli altri, soprattutto se questi raccontano

Il 24 febbraio scorso è "caduto" GAE - Google App Engine. Per chi non lo conoscesse (chi?) è la piattaforma per lo sviluppo di applicazioni di Cloud Compunting di Google. Da non confondere con Google Apps, che è sempre Cloud, è sempre di Google ma è un più un servizio che una piattaforma di sviluppo. Detto in 2 parole: in Google App Engine scrivi applicazioni web in Java o Phyton. In Google Apps usi versioni parzialmente custom di GMail, Calendar, ecc.

Dicevo... il 24 febbrario Google App Engine è "morto": non funzionava più niente. Dopo un paio di ore di completo blackout sono ripartite le applicazioni, prima in read-only, poi in modo normale. Il disservizio è stato molto grave, ha praticamente coinvolto tutte le applicazioni e ha scatenato molte reazioni negative fra gli utenti visto che GAE è un servizio a pagamento (...ovviamente c'è anche una versione gratuita... a differenza di qualcun'altro...). 

Un po' di giorni dopo il fattaccio Google ha pubbicato un'analisi "post-mortem". Il post è molto dettagliato ed è possibile capire molte cose su come vengono gestiti ed erogati i servizi in Google. Ma l'aspetto che mi ha colpito di più è la trasparenza: non so quante aziende di fronte ad un problema serio sui propri servizi avrebbero fatto la stessa cosa. Un "mea culpa" pubblico e dettagliato. Certo, ci sono ragioni di politica commerciale, ma è la prima volta che vedo una cosa del genere.

Il post di Google è anche un'occasione per imparare qualcosa sulle problematiche dell'erogazione dei servizi da applicare poi anche in realtà più piccole.

• power failure: la causa è stato un problema dell'alimentazione dell'energia elettrica. Ci facciamo tanti problemi con SAN, RAID e Cluster e poi ci dimentichiamo dei gruppi di continuità.
• procedure per i casi di disastro: Google le aveva ma il team non aveva familiarità con esse. Noi facciamo delle simulazioni, proviamo ad applicarle?
• le procedure non erano aggiornate. E le nostre?
• le procedure non coprivano un caso così grave nell'alimentazione elettrica. Le nostre coprono tutti i casi?
• mantenere le procedure aggiornate, soprattutto se il sistema cambia. Aggiorniamo le procedure?
• definire delle politiche di gestione dei casi di emergenza. Fatto?

Ma la domanda principe è: noi abbiamo le procedure di emergenza oppure facciamo finta che certi disastri non succedano mai?

Memento:

• l'energia elettrica si può interrompere
• l'energia elettrica può avere sbalzi
• i dischi si rompono
• gli alimentari si rompono
• i controller RAID si rompono
• gli switch, i router e i firewall si rompono o si bloccano
• i nastri (del backup) non sono più leggibili
• il RAID o la SAN è configurato bene? Sì? Allora togli un disco a caldo su un server di produzione se hai il coraggio!

[UPDATE]

Nell'ottica dell'importanza della continuità del servizio  :)

http://xkcd.org/705/

UrlDiff Monitor

http://urldiff.appspot.com/

Un po' di esperimenti per imparare ad usare Google App Engine.

Someone smarter than you

Un bel articolo di Scott Guthrie (Corporate Vice President - Microsoft Developer Division).

Questa mi è proprio piaciuta:

There will always be someone somewhere in the world who is smarter than you - don’t always assume that they aren’t in the room with you.

:)

Google rimuoverà la censura su Google.cn

Questa è una notiziona: nella sostanza e nella forma.

Sostanza: Google toglierà i filtri/censura attualmente presenti su Google.cn.

Forma: un bel comunicato sul Blog ufficiale di Google Inc.

http://googleblog.blogspot.com/2010/01/new-approach-to-china.html

Un frammento:

These attacks and the surveillance they have uncovered--combined with the attempts over the past year to further limit free speech on the web--have led us to conclude that we should review the feasibility of our business operations in China. We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all. We recognize that this may well mean having to shut down Google.cn, and potentially our offices in China.

Assolutamente da leggere!