Fesserie televisive

Sto guardando in TV Jericho. Non m'aspetto molto da una serie del genere. Però non posso non notare che vengano spacciate dette certe fesserie: "La bomba atomica è stata sganciata solo due volte. E quella di Denver era una bomba H".

Lasciamo perdere il successivo commento sulla differenza tra bombe atomiche e bombe H, ma quello che sorprende è la totale dimenticanza delle centinaia di test atomici di superficie eseguiti tra la fine degli anni quaranta e l'inizio degli anni sessanta facendo esplodere numerose bombe atomiche e bombe H, alcune di potenza notevole.

In questi casi mi pare proprio che la televisione non faccia nulla per non creare una visione distorta della storia. Tutti si ricordano di Hiroshima e Nagasaki. Pochi sanno che la prima bomba atomica mai esplosa non è stata quella di Hiroshima ma quella del test Trinity, eseguito nel deserto del New Mexico il 16 luglio 1945. Non molti ricordano dei test di Bikini. Più facile ricordare i recenti test sotteranei eseguiti dalla Francia a Mururoa. Ma di Ivy mike, la prima bomba H mai esplosa chi si ricorda? E dei test eseguiti col cannone atomico? E della Tzar Bomba, la più potente bomba H mai esistita (50 Megatoni) fatta esplodere dall'Unione Sovietica il 30 ottobre 1961 in Novaya Zemlya?

Per rifrescare la memoria, suggerisco una visitina al Nuclear Weapon Archive.

Classi Java, singleton ed Objective C

Le classi java non sono un oggetto. Si, esistono le istanze di Class, ma queste sono una supporto per l'accesso alle proprietà delle classi sottostanti (relazioni con altre classi, membri privati, metodi, annotation...). L'interfaccia esposta da Class facilita l'ispezione della classe ma non facilita l'uso di questa classe come componente applicativo. Per spiegare meglio questo concetto farò un esempio che prende spunto dal seguente problema: è meglio usare un singleton o una classe con i suoi metodi statici? Vediamo un attimo le due situazioni:

// definizione classe con metodi statici

class MiaClasse {
 public static void metodo1() { ... }
 public static Object metodo2(int valore) { ... }
}

// utilizzo classe con metodi statici

MiaClasse.metodo1();
...
Object r = MiaClasse.metodo2(10);

// classe singleton

class MiaClasse {
 private MiaClasse() { ... }
 private static MiaClasse instance = null;
 public static getInstance() {
 if (instance == null) instance = new MiaClasse();
  return instance;
 }
 public void metodo1() { ... }
 public Object metodo2(int valore) { ... }
}

// utilizzo classe singleton

MiaClasse.getInstance().metodo1();
...
Object r = MiaClasse.getInstance().metodo2(10);

Il singleton è indubbiamente una soluzione che aggiunge complessità, almeno in un primo momento. Però ha un vantaggio: permette di trattare il componente funzionale come un oggetto, con tutto quello che ne consegue. Ad esempio, se il singleton implementa una certa interfaccia M, è possibile passare il singleton ad un metodo che accetta un parametro di tipo M.

class MiaClasse implements M {
 ...
}

class AltraClasse {
public void metodoM(M param) { ... }
 ...
}

AltraClasse a = ...;

a.metodoM(MiaClasse.getInstance());

E' possibile fare la stessa cosa utilizzando l'oggetto Class?

La risposta è... forse... penso di si, ma in modo più complicato, così complicato che il singleton alla fine sarebbe la soluzione migliore.

Queste considerazioni mi fanno venire in mente un fatto: in Objective C le classi sono oggetti al pari di altri e potete permettervi di passarle come parametri ad un metodo ed usarle per richiamare i metodi della classe come si fa con i metodi delle istanze. Ad esempio:

@interface ClasseA
{
 ...
}
+ (int) metodo1: (int) valore;

...

@interface ClasseB
{
 ...
}
- (void) metodo2: (id) oggetto;

...

@interface ClasseC
{
 ...
}
- (int) metodo1: (int) valore;

...

@implementation ClasseB
- (void) metodo2: (id) oggetto
{
 int y = ... ;
 ....
 int x = [oggetto metodo1: y]
 ...
}

...

// utilizzo ClasseA come parametro metodo2
ClasseB* b = ... ;
[b metodo2: ClasseA];

// utilizzo istanza di ClasseC come parametro di metodo2.

ClasseC* c = ...;
[b metodo2: c];

Insomma, se Java fosse come l'Objective C, probabilmente si potrebbe evitare il ricorso ai singleton tutte quelle volte che vorrebbe trattare la classe come un oggetto. Il problema è capire quando questo è, più che necessario, possibile. Cioè, che probabilità ci sia che questo prima o poi diventi una necessità.

A proposito di numeri...

Su internet si trova di tutto, come ad esempio The On-Line Encyclopedia of Integer Sequences (Enciclopedia Online delle Sequenze di Numeri Interi), un sito sponsorizzato dagli AT&T Labs.

Vietato pubblicare questi numeri

09 f9 11 02 9d 74 e3 5b d8 41-56 c5 63 56 88 c0

Questione di millimetri

Supponiamo che il vostro compito sia quello di realizzare un documento in html di cui sia prevista la stampa in un foglio A4. Nel foglio di stile è possibile specificate le misure in millimetri così che quando ad esempio dobbiate specificare le dimensioni dell'area contenente il documento, possiate prendere in considerazione le misure standard del foglio A4, cioè 210x297 millimetri, e quindi ad esse togliere un margine previsto di circa 10 millimetri per ogni lato. Potete realizzare il vostro layout della pagina in html usando sia una tabella contenente una cella a cui sia stato applicato un padding di 10mm oppure usare un div a cui è applicato lo stile:

.test_cover {
position: relative; top: 10mm; left: 10mm;
width: 190mm; height: 277mm; background-color: #F0F0F0;
}

Ora supponiamo che nel documento ci sia un svg contenete del testo (avete deciso di mettere nel documento un testo in verticale e l'unico modo che avete per farlo è quello di metterlo dentro un text svg ruotato di 90 gradi). Mettete il codice svg nel codice html e grazie al fatto che avete realizzato una pagina xhtml riconosciuta come tale dal browser vi aspettate che il documento sia presentato correttamente con l'immagine svg renderizzata correttamente col testo in verticale.

Sicuri?

Si, se nell'immagine contiene solo cerchi, quadrati, figure geometriche più o meno complesse l'immagine viene presentata correttamente. Però se provate a mostrare del testo in una immagine svg collocata dentro un documento realizzato come sopra, cioè in cui la view che contiene l'immagine sia stata traslata di una misura espressa in millimetri, il testo magicamente scompare.

Strano, no?

Soluzioni? Si, ci sono: non usare alcuna traslazione o esprimerla in pixel.

Quindi, in attesa che esca FF3.0 e che (forse) il problema scompaia... chi mi dice a quanti pixel corrispondono 10mm?

p.s.: ho provat con Gran Paradiso Alpha 4 e il bug non si ripresenta. In compenso non mi funzionano più altre cose.

Page Zoom con Firefox 3

Non molti hanno chiara la misura dell'innovatività della prossima release di Firefox. Alcuni dettagli tecnici possono essere d'aiuto. Ad esempio, è noto che Firefox 3 sarà basato su Cairo, libreria grafica vettoriale open source. Non conoscendo così a fondo come è fatto Firefox non posso valutare fino a fondo le conseguenze di questa novità. Però, dovendo affrontare un problema per un lavoro, ho scoperto alcuni dettagli interessanti a proposito del supporto SVG in Firefox 3. Lo standard SVG prevede l'incorporazione di frammenti XHTML nel codice xml del formato grafico. Ho preso in considerazione questa possibilità per realizzare delle pagine contenenti miniature di documenti XHTML. Ovvero, potendo mettere dentro pagine XHTML oggetti SVG, mi è sembrato ovvio che un frame contenente un frammento HTML, presentato con una trasformazione per ridimensionarne il contenuto potesse presentare l'eventuale contenuto HTML ridimensionato graficamente, per esempio del 50% o del 70%. Una cosa diversa dal ridimensionare ogni singolo attributo del frammento HTML, soluzione tradizionalmente adottata in questi casi e che ha diverse controindicazioni (prima: la complessità). Però al momento non è possibile utilizzare questa soluzione perché non c'è un browser, Firefox 2 incluso, in grado di renderizzare HTML dentro SVG. Al contrario, Firefox 3 prevede questa possibilità. Ho provato con l'ultima release alpha di FF3 e sembra che la soluzione funzioni, fatta eccezione per un bug presente sulla versione mac che fa si che sui font non venga applicata correttamente la trasformazione.

Magari prossimamente pubblico un esempio con tanto di codice.

Station area Utrecht

Il municipio di Utrecht, Olanda, ha previsto un piano che nei prossimi dieci anni porterà ad una ristrutturazione del centro storico della città. Per mostrare in anticipo il risultato delle opere messe in atto, gli amministratori hanno pensato di far sviluppare un gioco, che è possibile scaricare da una pagina del sito del municipio di Utrecht. Il gioco è stato sviluppato con Ogre.