In questo momento sto realizzando la versione mobile di un sito web che potete vedere a questo indirizzo. Utilizzo jquery per qualche chiamata ajax e sopratutto perchè mi rende più agile lo sviluppo delle parti javascript. Una volta finita una parte del sito, ho tentanto di accedere con un iPhone. L’apertura risulta effettivamente lenta. La parte più pesante del sito, sono i 73 kb di jquery che, nonostiante sia nella versione minified, risulta essere troppo pesante per poter essere utilizzato con uno smartphone. Ho cercato in rete una versione light di jquery ma non ho trovato nulla.

speranza: una versione mobile per iPhone non sarebbe male =(

Sviluppando sul portatile e testando il sito da li e con Chrome, risulta tutto rapito. Con questo iPhone è tutto fuorchè performante. Spero che qualcuno capiti in questo post e sappia consigliarmi per ovviare a questo problema. 70 kb sono eccessivi! La prima cosa che ho pensato, è una versione mobile di jquery così ho trovato http://jquerymobile.com/. Di fatto quel sito è una pagina fine a se stessa e pare non esista nessun codice mobile.

proposta: date che vi sarà dato:

=( Se qualcuno sa/può aiutarmi lo ringrazio molto. In cambio, presto potrei preparare una guida in italiano alle Graph API di google. Ci sto giocando da un po. Mi sono creato uno script che “tira su” tutte le foto dei miei amici. Ho creato un png enorme con un migliaio di quadratini dove da qualche giorno tutti si stanno taggando =). Credo che adesso mi basti aprire una società, imparare ad usare flash, fare un giochino ambientato in una fantomatica fattoria, mettere delle vacche rosa in giro per i prati …. e quotare la mia società in borsa. Potrebbe essere interessante …

Your profile could not be opened correctly.

Some features may be unavailable.  Please check that the profile exists and you have permission to read and write its contents.

rm -R /home/demo/.config/chromium/Default

Esporta una tabella in formato array di php

<?php

/**
* Export to PHP Array plugin for PHPMyAdmin
* @author Geoffray Warnants
* @version 0.2b
*/

//
// Database “PROVA”
//

// PROVA.Classificazioni
$Classificazioni = array(
array(‘id’=>1,’Nome’=>’Una Stella’),
array(‘id’=>2,’Nome’=>’Due Stelle’),
array(‘id’=>3,’Nome’=>’Tre Stelle’),
array(‘id’=>4,’Nome’=>’Quattro Stelle’),
array(‘id’=>5,’Nome’=>’Cinque Stelle’)
);

Ah! Sono stato proprio distratto. Adesso però vorrei capire se qualcuno si è divertito con questa features e l’ha usata per i suoi scopi malvagi. Magari può suggerirmi qualche buon utilizzo.

http://www.radoslavdimov.com/jquery-plugins/jquery-plugin-timepicker/#Examples

Non troppi mesi fa, preparavo un talk sugli eventListener di javascript. In quel mio intervento facevo notare come la stessa Microsoft avesse partecipato allo sviluppo dello standard, ma evitando di usarlo al rilascio del suo browser. Nei prossimi anni, vedremo il web cambiare drasticamente e  Dean Hachamovitch che è responsabile del team che si sviluppa IE presso Microsoft ha detto la sua su HTML5. Lo cito per far notare che forse, stanno nuovamente appoggiando un nuovo standard, e tra qualche tempo faranno di testa loro. Andrà così? Vedremo:

“Il futuro del web è HTML5. Microsoft è profondamente impegnata nell’avanzamento del processo HTML5 con W3C. HTML5 sarà molto importante nell’innovazione di applicazioni web interattive e nella progettazione dei siti. Le specifiche HTML5 descrivono il supporto video senza specificare un particolare formato video. Pensiuamo che H.264 sia un formato eccellente. In IE9, nel supporto HTML5, sarà supportata solamente la riproduzione di H.264″.

Basta poi prendere ad esempio youtube per capire che internet al momento mostra i suoi video usando Flash di Adobe. Hachamovitch giustamente fa notare che un browser senza supporto a Flash un tantino complicato ma anche che lo stesso Flash non è proprio perfetto in fatto di sicurezza. Flash al momento è l’unico software, o quasi, che permette di visualizzare video in internet. La diversità del software è importante, al di la che sia chiuso o meno, deve esserci una diffusione diversificata per garantire sicurezza.

“Se i video possono essere disponibili in altri formati, la facilità di accedere ai video usando un browser su un determinato sito senza usare Flash è una sfida per gli utenti. Flash ha qualche problema, in particolare per quanto concerne l’affidabilità, la sicurezza e le prestazioni. Lavoriamo a stretto contatto con gli ingegneri di Adobe, condividendo le informazioni relative ai problemi che scopriamo nelle nostre discussioni tecniche. Nonostante questi problemi Flash resta un importante modo per fornire al consumatore una buona esperienza di fruizione del web al giorno d’oggi”.

Sicuramente avranno una loro visione delle cose. Infatti basta pensare che verrà utilizzato, per IE, il formato H.264. Ora, per chi non lo sapesse, non è l’unico standard disponibile. Theora per esempio è gratuito e non è coperto da brevetti. Ora, H.264 resterà royalty free fino al 2016. E dopo? Siamo sicuri che non ce lo faranno pagare tra 6 anni quando no sarà più royalty free ma impossibile da abbandonare in quanto diventato, per allora , standard de facto?

A salvare la situazione potrebbe essere Google con il suo formato VP8. Da qui arriva ad una prima risposta sul perchè può essere scartato Theora. Quest’ultimo si basa sul VP2 (decisamente vecchio no?). Però si sa che il software open source è decisamente migliore di quello chiuso. Prima tra le motivazioni, proprio il fatto che deve essere per tutti. Con il rischio di un 264 da pagare dal 2016, si potrebbe creare un divario tecnologico dentro ad internet. Magari anche con il rischio di vedere “visibile solo con …”. E fare questo proprio in un momento in cui si sta cercando di far conoscere agli utenti la realtà dei fatti, ovvero che esistono più browser. Dovrebbero essere implementati più codec in ogni caso. Se ci fosse un solo codec, un baco potrebbe generare una falla enorme in tutta la rete globale.

Adesso andiamo nel mondo della mela: su webmasterpoint si dice che apple non porterà mai il flash di Adobe su iPhone. iPhone è molto orientato verso l’HTML5. Quello che penso e che mi viene fatto pensare anche leggendo ipaditalia, è che HTML5 diverrà uno standard grazie alla Apple esattamente come la Apple a reso standard de facto lo standard USB. Io lo vidi per la prima volta nel mio iMac (i primi che ancora erano a tubo catodico …) e da li in poi si iniziarono a trovare ocunque. Che dire. Dire che anche Mac, purtroppo, sposerà h.264. Beh a questo punto speriamo che rimanga royalty free anche tra 6 anni. Che browser ci saranno tra 6 anni? Siamo sicuri che non ci saranno nuovi formati Open e per allora saremo veramente liberi?

Scaricate il file della lingua: http://l10n.drupalitalia.org/

Una volta scaricato il file della lingua, abilitare il modulo per la gestione delle lingue.

Per farlo, andate in Administer > Modules. Vi troverete in una pagina dove è possibile consultare la lista dei moduli presenti nel vostro drupal. Anche se non attivi, molti sono presenti di default nel core. Per primo, troverete l’elenco dei file opzionali. Per secondo, quello dei moduli richiesti. Il nostro modulo, ovviamente, sta nell’elenco di quelli opzionali e si chiama Locale con descrizione “Aggiunge funzionalità di gestione della lingua e abilita la traduzione dellla interfaccia utente in lingue diverse dall’inglese.“. Selezioniamolo e poi salviamo la configurazione.

Dopo aver attivato Locale, aggiungiamo una lingua: l’Italiano.

Questa volta andiamo in Administer > Site Configuration > Languages. Da questa pagina, selezioniamo il menu Add language” quindi la lingua italiana. A questo punto, nella lista delle lingue avremo English ed Italian.

Ora possiamo caricare il file della lingua.

Cliccando nuovamente su Administer > Site building > Translate interface, potremo cliccare sul link Import e dalla pagina che verrà caricata, potremo uploadare il file “.po” che vi ho indicato all’inizio del post. Ed a quel punto avremo finito =). Tutta, o quasi, la nostra amministrazione drupal parlerà la nostra lingua.

Sempre su Administer > Site building > Translate interface, possiamo vedere l’elenco delle lingue installate ed anche in che percentuale la nostra lingua è stata tradotta. In particolare, la colonna dove si può vedere questa informazione si chiama “Build-in interface”. Nel mio caso, il file .po che ho scaricato contiene 3103 stringhe tradotte su 3128, ovvero il 99.2% delle stringhe totali.

Ho ovviamente e subitamente segnalato la cosa all’utente Staff. Speriamo che risolvano entro oggi: ho una gran voglia di drupalare.

Per chi volesse andare al link originale: sondaggio.

Cesena è strana, ha i parcheggi ma i cesenati non li usano correttamente. Non c’è adeguata copertura delle corriere e dei bus (nonostante tutti i cesenati li chiamino tram eheheh). Qualche tentativo di miglioramente viene dalla fornitura di biciclette pressochè gratuite. Molto si è fatto, e probabilmente molto è ancora da fare. In ogni caso di questa ed altre faccende, si discuterà all’OpenSpace creato ad oc per discutere dell’ultimo km a Cesena. Amministrazione e cittadini si incontrano. SPERIAMO che l’incontro sia positivo per tutte le parti.

(ps … ho tentato di scrivere in inglese … spero che chi sa l’inglese

davvero capisca ugualmente eheheh )

Per fare un esperimento, ho provato a digitare:
$ at 13:40
at> touch ciao
ctrl-d

Ovvero… ho digitato “at 13:40″ poi invio. Successivamente ho inserito i comandi “touch ciao” e quindi nuovamente invio. Infine, ho premuto ctrl-d. Non so se premere ctrl-d sia la procedura corretta, fatto stà, alle 13:40 è stato creato un file di nome “ciao”. Mi trovavo nella directory della mia scrivania quando ho lanciato il comando quindi il file è stato creato sulla mia scrivania.

Potrebbe essere un modo interessante per mandarsi dei post it che compariranno magicamente sulla propria scrivania quando serve =).

Se posso dire la mia sul nome, avrei preferito Microsoft Murderer hihiih. Peccato si sia preferito parlare della mangusta.

Cosa significa la sigla TDD?

Significa Test Driven Development ovvero sviluppo guidato dal testing.

Più precisamente?

Significa che per sviluppare un software, si scrivono prima i test, e poi il codice vero e proprio. Per dirla in un modo più amichevole: sapendo che cosa deve fare una applicazione, noi dobbiamo prima scrivere del codice che si basa sulle specifiche di un progetto e che afferma che ciascun metodo deve risultare determinati valori.

Troppo complicato? Proviamo con un esempio semplice: scriviamo i test per implementare il metodo somma.

Immaginiamo di dover implementare una calcolatrice e di avere un metodo somma($addendoUno,$addendoDue); Va da se che somma(1,3) dovrà restituire 4. E’ un requisito del metodo. Bene, prima di implementare una qualsiasi riga di codice per la somma, scriviamo il test che controlla che dati due precisi valori, restituisca un terzo nel modo corretto. Scriviamo diversi test. Molto bene: i requisiti della nostra funzione somma, sono che la somma funzioni. (lol)

Abbiamo scritto i test, ed ora?

Ora lanciamo i test.

I test falliranno tutti, perchè non abbiamo ancora scritto nessun codice. Quindi procediamo e scriviamo il nostro metodo.

Testiamo il codice!

Adesso che abbiamo implementato il codice, lo possiamo testare e se il metodo somma funziona correttamente, farà andare a buon fine tutti i test. Bene! Il codice che abbiamo creato è stato testato e funziona.

Perchè ho scritto un test?

I testi si possono scrivere per varie ragioni ed ora elenco alcuni vantaggi che ho visto fino a questo momento:

• è facile intuire, che dicendo al codice come deve comportarsi quando è corretto (scrivere un test) ci porterà a ridurre i bug e, per esempio, a non avere errori di logica nella programmazione.
• possiamo fare refactoring e ritestare tutto il codice. Se i test vanno a buon fine, non dobbiamo chiederci se ci sono errori “in giro”. Il codice funziona bene come prima del nostro operato quindi siamo felici e tranquilli =). Abbiamo fatto un buon lavoro.
• vengono testate le singole funzionalità, o unità (unità di test appunto) ed si cicla in questo modo: si decide la funzionalità, si scrive il test, si scrive il codice e lo si modifica se e fino a quando il test non è soddisfatto. Da quel momento in poi, non dovremo più preoccuparci di nulla.
• ogni test è documentazione, in quanto spiega il funzionamento di ogni piccola unità di codice. Talvolta può persino sostituire la documentazione stessa.

Molto bene, non entro oltre nel dettaglio anche perchè se devo essere sincero, solo oggi ho realizzato una classe usando il TDD. In particolare ho pensato di scrivere del codice oop per realizzare una pagina html5 di base. Ho ragionato in questo modo: so come è fatto un documento scritto in HTML5, implemento dei test in modo che mi vengano restituite delle parti di codice nel modo esatto che desidero. Implemento il codice e via di seguito.

Ancora più semplicemente, vediamo gli steps:

1. scrivo un test
2. faccio fallire il test (per assicurarmi che la funzionalità non è stata implementata)
3. metto mano al codice in produzione fino a che il test non ha esito positivo
4. torno al passo 1

Ma scrivere un test dopo aver scritto il codice di produzione non è uguale?

Di primo acchitto potrebbe sembrare. Difatti, però, scriveremmo dei test influenzati dal codice, e di conseguenza non sarebbero test rivolti allo scopo dell’applicazione ma del codice appena scritto. Per ora il post lo concludo qui. Spero che sia utile a qualche lettore …