Marco Bellinaso

GetConnected è l'azienda bolognese con la quale sto lavorando da oltre un anno, in maniera sempre più stretta. Assieme a loro ho pubblicato Locomotimes (tra che l'altro già da qualche giorno ha superato i 20.000 download!) e stiamo lavorando assieme anche su nuovi prodotti. Il lavoro non manca e anzi sembra che le persone non siano mai abbastanza per tutti i progetti che escono, sia come commesse da clienti...che come prodotti commerciali. GetConnected sta quindi cercando nuovi programmatori da assumere...possibilmente giovani entusiasti, con una vera passione per l'informatica, che abbiano già una discreta esperienza ma che abbiano anche voglia di imparare ancora, lavorando su idee e tecnologie interessanti e moderne.

Come? Avete già sentito queste cose milioni di volte, per poi trovarvi di fronte al solito manager tecnicamente incompetente al momento del colloquio, che non valuta con il dovuto interesse (e rispetto) tutti i progetti, i software e i siti fighissimi che avete creato, magari da soli, con amici, nel tempo libero, per passione oltre che per professione?

Per dimostrare con i fatti che sono diversi, i ragazzi di GetConnected hanno dato il via ad una specie di concorso: inviate le vostre realizzazioni migliori in ambito web (basta anche solo il link al sito online, se non potete/volete spedire il sorgente) e avrete la possibilità di vincere il premio in denaro di 300€. Non male, per una cosa che avete già realizzato e che qualcuno vi chiede di mostrargli, no?

I progetti dovrebbero essere siti/servizi web e se volete vincere è meglio che siano in qualche modo innovativi, come idea e/o come tecnologie usate. Qualche paginetta fatta in Classic ASP per gestire un guestbook o delle news? mmm...no grazie! Un servizio sviluppato con ASP.NET / PHP / RoR con AJAX a gogò, mappe, mash-up e utilizzo di toolkit e framework vari? Fatevi sentire subito!

Il premio in denaro sarà solo per uno, ma tutti i partecipanti saranno presi in considerazione per una assunzione e/o collaborazione. Solo se lo si desidera ovviamente. Si può anche partecipare, vincere il premio e scappare...ma poi non dite che gli informatici in gamba non riescono a trovare (o cambiare facilmente) lavoro eh?!

Leggere libri di programmazione senza poi programmare e provare con mano quanto studiato vuol dire non aver imparato nulla. Mettersi li a realizzare i soliti esempi semplici e banali è ben poco divertente e anche poco utile. Ecco perchè per fare pratica ho voluto realizzare (assieme ai ragazzi di GetConnected) una applicazione reale, che non fosse troppo complessa ma che non fosse neanche un giocattolo.

Il risultato è Locomotimes, un'applicazione che permette di consultare in modo semplice e veloce gli orari dei treni per qualsiasi tratta nazionale e verso molte città europee. Le funzionalità sono parecchie; non mi soffermo qui sui dettagli perchè trovate tutto sulla pagina di iTunes o di GetConnected (qui c'è anche un video che mostra tutte le funzionalità), ma in breve:

- elenco indicizzato e filtrabile di tutte le stazioni supportate
- possibilità di includere solo le soluzioni di viaggio con determinati tipi di treno
- un sacco di informazioni nei risultati (partenza e arrivo non solo per il viaggio totale ma anche per tutti i cambi, alert se i cambi sono troppo ravvicinati, tipi di treno, durata del viaggio, tariffe di prima e seconda classe, link per l'aquisto online...)
- cronologia delle ricerche passate (così che fatta una volta sia possibile consultare i risultati in futuro senza dover fare un'altra connessione)

Per chi come me prende spesso il treno credo che l'applicazione possa essere molto utile. Si, lo so che il sito di Trenitalia può essere consultato tramite Safari...ma occorre 10 volte lo stesso tempo, pazienza e traffico dati. L'applicazione sarà gratuita per un po', quindi...se avete un iPhone andate a scaricarla subito! ;)

NOTA: in realtà lo sviluppo di questa applicazione è terminato da almeno un mese...nel prossimo post racconterò perchè ci abbiamo messo così tanto per essere pubblicati online e darò qualche consiglio per evitare un'attesa logorante :)

Su questo blog ho già parlato varie volte dell'iPhone. Ho avuto prima la versione 2G e poi la 3G...e nonostante attualmente usi regolarmente un BlackBerry Bold continuo a pensare che l'iPhone sia un dispositivo assolutamente innovativo e con alcune qualità (e soprattutto con delle potenzialità) ancora molto superiori alla concorrenza. Alcuni aspetti in particolare poi dovrebbero interessare molto gli sviluppatori. Per questi motivi (e per soddisfare un po' la mia curiosità e passione per la tecnologia) ho ordinato il libro Beginning iPhone Development (APress) appena fu annunciato e prima che fosse effettivamente disponibile (causa il fatto che fino a pochi mesi fa l'SDK era ancora sotto NDA e non se ne poteva scrivere pubblicamente...). Solo recentemente però ho iniziato un progetto e mi sono messo a studiarlo realmente.

Sviluppare per iPhone significa dover usare Mac OSX, imparare l'IDE di sviluppo XCode (fornito gratis con il sistema operativo o scaricabile gratuitamente assieme all'iPhone SDK), imparare il linguaggio Objective-C e il framework Cocoa Touch (che è parte di Cocoa + estensioni specifiche per iPhone, allo stesso modo di quello che fa il .NET Compact Framework e l'SDK di Windows Mobile rispetto al .NET Framework full). Oltre a questo bisogna abituarsi a programmare secondo il modello Model-View-Controller (che molti conosceranno anche in ambiente .NET o Java...ma sicuramente non tutti) e a tutta una serie di piccole e grandi differenze rispetto al modo di lavorare con altri ambienti e linguaggi. Di sicuro ci vuole un po' di tempo per prenderci la mano ed essere produttivi, e non è che essendo esperti con qualche altra tecnologia il lavoro con l'iPhone sia subito un gioco da ragazzi.

Proprio per questo motivo è utile avere una guida come quella in questione, che che insegni come muoversi partendo dai concetti base e mostrando passo per passo come: disegnare una vista, associarci un controller, collegare gli elementi della UI alle proprietà del controller, gestire gli eventi (tramite delegate)...e poi via via fare cose più complesse come riempire una lista associata ad una sorgente dati, personalizzare l'aspetto delle tabelle, costruire dei percorsi di navigazione tra viste distinte, gestire l'accesso al file system, realizzare qualche piccola animazione ed effetto grafico, gestire touch e gesture, localizzare un'applicazione, gestire la fotocamera e fare 2 cose sul multimedia.

Il libro è strutturato proprio come un corso, e quindi va letto in ordine. Alla fine si avrà una buona idea di come si lavora su questa piattaforma e il tanto codice di esempio fornito potrà anche servire come base di partenza (e miniera per copia-incollare piccole parti) per i primi progettini. Alla fine non si potrà dire di essere esperti, ma non si sarà più neppure degli sprovveduti. Il libro ad esempio spende ben 120 pagine per parlare di liste e navigazione tra viste, dato che sono concetti fondamentali e importanti per praticamente tutti gli applicativi (ad eccezione probabilmente di videogame e applicazione esclusivamente "grafiche", che sono programmate in modo diverso), ma non parla di accesso a web service o risorse via HTTP, programmazione multi-threading (importante ad esempio per recuperare o elaborare dei dati mentre l'utente usa qualche altra funzione dell'applicazione), utilizzo avanzato di alcuni controlli, interazione con altre applicazioni (il browser o il programma Mail ad esempio), accesso ai contatti del telefono, debugging, deployment dell'applicazione su un iPhone reale di test, o del processo (pieno di insidie) di firma e pubblicazione dell'applicazione in AppStore. Altri argomenti come l'accesso ai database Sqlite, la gestione delle gesture, dell'accelerometro e del GPS sono appena accennati in poche pagine, in modo insufficiente per un utilizzo immediato proficuo.

Le mancanze elencate sopra non si possono però considerare dei veri difetti del libro; sono mancanze "by-design", volute, dato che il titolo inzia con "Beginning..." e non con "Professional...". Quello che però ci sarebbe stato proprio bene in un libro del genere è un capitolo sul linguaggio (sintassi, costrutti, programmazione ad oggetti, categorie, reflection, gestione delle memoria) e le classi base tipo NSString, NSDate, NSArray, NSDictionary ecc. Non vorrei ovviamente una trattazione dettagliata di questi argomenti, (ci vorrebbe ovviamente un libro dedicato solo a quello) ma solo "un riassunto", un "quick-start" per chi viene magari da altri linguaggi e si trova un po' spiazzato dalla sintassi e da alcuni concetti di Objective-C. Ad ogni modo, se si è già letta la documentazione ufficiale di Apple sul linguaggio, anche questo non costituirà un problema.

L'importante è che una volta imparati i concetti di base sarà molto più semplice cercare (e capire) specifiche informazioni online, nella documentazione ufficiale...o in un secondo libro più avanzato. Non si tratta quini della classica bibbia omnicomprensiva, ma è uno strumento efficace e quasi indispensabile per partire con il piede giusto. In conclusione, è una perfetta prima guida, altamente consigliata.

In questo periodo – lavoro "normale" permettendo – sto sviluppando una applicazione iPhone che recupera dei dati da un web service .NET. Lavoro su un MacBook Pro con OSX come sistema operativo principale e Windows XP su VMWare Fusion. Chiaramente su OSX uso XCode per lo sviluppo del codice iPhone, e sulla VM con XP uso Visual Studio 2008 per lo sviluppo del web service.

Tutto bene con lo sviluppo, fino al momento di dover interrogare il web service che gira nella VM dal simulatore iPhone. Il problema è che in XP non ho neanche installato IIS, perchè la versione 5 ha troppi limiti ed è fin troppo diversa da IIS6. Quindi ho pensato che tanto valeva sviluppare usando il Web Development Server integrato in VS2008 e poi fare i test finali sul server Win2003 con IIS6. Il Web Development Server però non accetta richieste remote, ovvero processa solo richieste provenienti dalla macchina di sviluppo dove gira. Come fare quindi per testare l'integrazione iPhone/WS, senza dover necessariamente installare IIS o senza pubblicare ogni volta il WS sul server Win2003?

La soluzione è stata davvero semplicissima: basta scaricare Port Forwarding for Windows (programmino freeware, fornito anche di sorgenti, e che non richiede neanche installazione) e configurarlo per redirezionare le richieste che arrivano sulla porta 80 verso la porta gestita da Web Development Server. Un minuto ed il gioco è fatto.

Note
1) Io ho scelto la porta 80 per semplicità, ma potete scegliere la porta che volete...basta che vi ricordiate di aprirla nelle regole del firewall.
2) Di default la porta usata dal Web Development Server è dinamica, e questo è un problema perchè dovreste cambiare ogni volta la regola di forward. Per ovviare basta impostarla staticamente dalle proprietà del progetto ASP.NET.

Vi è mai capitato di rispondere in questo modo (o almeno desiderare di poterlo fare...) a qualcuno che vi fa una domanda banale e che ovviamente non ha speso neppure 10 secondi provando a fare una ricerca veloce su Google? Invece di rispondere come vorreste, fate voi la ricerca per conto suo...non direttamente su Google però, ma su LetMeGoogleThatForYou. Copiate l'Url generata dal sito e inviatela al vostro interlocutore. Per vedere l'effetto ottenuto al click provate voi stessi con l'immagine in questo post (e fate attenzione alle spiegazioni :)

Esattamente un mese fa ho ricevuto in "prestito a scadenza indeterminata" (grazie ad Alessandro, Federico, James e Davide!) uno dei recenti BlackBerry Bold. Da allora il mio iPhone 3G è rimasto spento e chiuso in un cassetto. Il motivo è presto detto: sebbene iPhone abbia un'interfaccia utente e un tipo di interazione che non ha pari in nessun'altro telefono, la sua effettiva utilità "sul campo" risulta limita da almeno due fattori:

1) Le limitazione che Apple impone agli sviluppatori di terze parti: non poter scrivere applicazioni che girano in background significa ad esempio non poter avere client Messenger, Gtalk o Skype sempre attivi e pronti a ricevere messaggi. Oppure significa non poter ricevere eventi di sistema in qualsiasi momento (nuovo SMS o mail in ingresso) per scatenare qualche operazione particolare. Non poter accedere a varie funzioni telefoniche (invio SMS, gestione completa della fotocamera ecc.) riduce ulteriormente il numero di applicazioni utili che si possono creare. Resta pur sempre una gran quantità di cose che si possono fare, ma meno di quelle che desidererei. Ora che un abbonamento da 3€ a settimana mi consentirebbe di avere 2GB di traffico a settimana, vorrei tenere Messenger e Gtalk sempre attivi...non poterlo fare è un "deal breaker".

2) La tastiera su touchscreen funziona discretamente bene, sicuramente infinitamente meglio dei vari tentativi he ho provato su molti altri telefoni, ma non è al livello di una tastiera fisica. Va bene per scrivere un Url nel browser, o un SMS...ma scordatevi di scrivere un mini-documento Word o una mail di più di 2 righe...specie se non avete un'infinita pazienza, tempo...e se non siete perfettamente fermi! Si perchè se provate a scrivere mentre camminate o mentre siete in macchina (non alla guida...) con qualche vibrazione e scoprirete che centrare il tasto voluto si complica significativamente.

Per quella che è la mia esperienza, il BlackBerry Bold risolve in modo quasi brillante entrambe le problematiche. Partiamo dalla seconda: la sua tastiera fisica è ottima, probabilmente la migliore che abbia mai provato. E' sufficientemente ampia per essere usata comodamente, i tasti hanno un buon feedback e non mancano un colpo; inoltre si auto-retroillumina in condizioni di oscurità. Riguardo al primo punto, anche se è vero che neppure col BlackBerry un programmatore può fare tutto-tutto (non si possono ad esempio cancellare SMS in ingresso o spostarli, non si possono chiudere applicazioni o interagirci in qualche altro modo, la customizzazione di applicazioni di sistema è un po' limitata ecc.), la libertà che si ha è di un'ordine di grandezza superiore a quella dell'iPhone. E' un dato di fatto, non un'opinione!

A parte questo, anche le applicazioni di sistema del BlackBerry sono molto più complete: c'è un Address Book "serio" (con i gruppi), il copia e incolla (che non pensavo mi sarebbe stato così utile finchè non ho dovuto iniziare a rispondere a molti clienti con una risposta fissa contenente Url e altre informazioni), un registratore video, un gestore di password, un editor per Word, Excel e PowerPoint, e altre cosette ancora.

Tutto il sistema è velocissimo e passare da un'applicazione all'altra (o chiuderla) è cosa di un istante - anche l'iPhone è sufficientemente veloce, ma non a questi livelli...colpa non tanto forse della potenza reale, ma delle onnipresenti animazioni...belle, ma che ovviamente rubano un po' di tempo.

La batteria dura circa 2 giorni con un normale utilizzo (mezz'ora di telefonate al giorno, qualche SMS, connessione 3G sempre attiva, programmi in background come Messenger e Gtalk sempre attivi, e un po' di navigazione). Niente male, diciamo al pari dell'iPhone.

Il browser integrato mi ha lasciato così soddisfatto che non ho neanche provato ad installare alternative come Opea Mini. Certo, il browser dell'iPhone non ha paragoni, ma quello del Bold comunque ha sempre renderizzato correttamente tutti i siti che visito e i suoi 3 livelli di zoom consentono di navigare le pagine molto comodamente.

Un'altra cosa simpatica del BlackBerry (e della sua tastiera) è che offre un milione di scorciatoie alle operazioni più comuni. Ad esempio per rispondere ad un SMS o mail (anche nei programmi non di sistema ma che comunque aderiscono alle linee guida di RIM, come ad esempio il client GMail fatto su misura da Google) basta premere "R", per scrollare verticalmente una pagina (utile proprio nel browser) si preme la "space bar", per cancellare un elemento da una lista si preme "backspace" ecc. ecc.

Volendo trovarci dei difetti, devo dire che la qualità costruttiva generale è inferiore a quella del dispositivo di Apple, pur essendo comunque più che discreta. Ad esempio la cornice esterna non è di metallo ma di plastica, il coperchietto posteriore è di "plasticaccia" leggera, e a premere sullo schermo questo si abbassa di mezzo millimetro. Nell'iPhone il case esterno è assolutamente perfetto e super rigido. Un altro difetto, non del telefono in questione quando piuttosto della piattaforma BlackBerry, è che il software di terze parti costa molto di più (costo medio sui 10$) dei rispettivi per iPhone (costo medio sui 1-2$). Inoltre spesso il software è meno curato nell'aspetto, anche se magari può fare più cose.

In molti potrebbero preferire l'ampio display dell'iPhone a quello del Bold: è una critica ragionevole, ma ovviamente dipende dall'utilizzo che farete del telefono. Se volete qualcosa per telefonare e scrivere, e da usare solo di tanto in tanto come player video, il display del Bold è più che sufficiente - nonostante la dimensione più ridotta infatti la qualità è eccelsa: colori brillanti e risoluzioni uguale a quella dell'iPhone (480x320). Se cercate un device per vedere contenuti multimediali, e che quando serve vi contenta anche di telefonare, allora l'iPhone è quello che fa per voi.

In conclusione, per ora con il BlackBerry Bold + flat dati da 3€/settimana (senza il quale si perdono molti dei vantaggi e del gusto di avere un device di questo tipo!) sono soddisfattissimo: la tastiera mi consente di scrivere in scioltezza anche mail piuttosto lunghe, o di chattare con Messenger e Gtalk; la parte telefonica funziona semplicemente come ci si aspetterebbe, il browser fa bene il suo lavoro, e il display mi permette di vedere qualche episodio di una sitcom quando spendo una mezz'ora in treno.

Da notare infine che il nuovo BlackBerry Storm sembra essere un'ulteriore ottima alternativa all'iPhone): ampio display per contenuti video e navigazione su web, solo touch-screen, e applicazioni di terze parti che potenzialmente possono fare quasi tutto. La mancanza della tastiera è quasi una scelta di vita però.

Anche senza consultare molte ricerche di mercato (che pure esistono in gran quantità) è sotto gli occhi di tutti come il mercato di smartphone e PDA si stia evolvendo tantissimo e velocemente. Ormai non è difficile passeggiare per strada incrociando non solo manager e "gente del settore" (leggi geek) ma anche ragazzini che parlano non con un normale telefono, ma con un dispositivo fornito di ampio schermo touchscreen e con migliaia di colori brillanti, connettività bluetooth, wi-fi e UMTS/HSDPA (più veloce di quello che fino a pochi anni fa si aveva nel PC di casa!), GPS, fotocamera da 2-5 MPx, vari GB di spazio disponibile, CPU potenti, tastiera estesa per una comoda digitazione, sensori di movimento...e magari qualcos'altro ancora. E' altresì chiaro che con una configurazione hardware di questo livello le possibilità per gli sviluppatori non mancano, ed infatti ecco fiorire giochi a volte paragonabili a quelli delle console portatili, e programmi / utility di tutti i tipi. Ci sono ormai moltissime aziende che hanno fatto del mobile il loro unico business, sviluppando applicazioni per tutte le maggiori piattaforme esistenti, e raggiungendo a volte anche un gran successo.

Con il fatto che (1) il mercato del software per mobile è in grande espansione, (2) molte idee possono essere sviluppate senza grandi investimenti di tempo e denaro ma con prospettive di guadagni potenzialmente interessanti, (3) è comunque la possibilità di imparare qualche nuova tecnologia e/o linguaggio divertendosi molto di più che facendo l'ennesima applicazione gestionale desktop-based, è normale che molti siano guardando a questo settore con l'intenzione di buttarsi dentro, o perlomeno di iniziare a "bagnarsi il piede" (espressione americana...chissà se in italiano fa lo stesso effetto :)

Vorrei allora proporre una analisi molto semplice e veloce delle principali piattaforme e delle tecnologie di sviluppo ad esse collegate, con l'intenzione di chiarire almeno parzialmente le idee a chi non si sa decidere.

Apple iPhone

E' chiaramente il device del momento, quello più di moda e che molti vorrebbero. Recentemente il suo AppStore, il negozio di applicazioni consultabile tramite iTunes (e solo tramite quello...) ha raggiunto le 10.000 applicazioni (la maggior parte delle quali è gratis o costa 0,79€ o poco più).

Cosa serve per sviluppare:
* Un qualsiasi Mac Intel-based
* L'ambiente di sviluppo gratuito XCode (presente direttamente nel DVD di OSX)
* L'iPhone / iPod Touch SDK, scaricabile gratuitamente
* Le chiavi per firmare digitalmente per proprie applicazioni: 99$/anno

Conoscenze richieste:
Objective-C & Cocoa Touch. Objective-C è un C con così tante cose in più, e con così tante differenze, che alla fine resta "C" solo nella sintassi degli statement di base (if, for, while, switch ecc.). Definizione di interfacce, classi, UI ecc. si fa tutto con una sintassi e degli strumenti di sviluppo che sicuramente risulteranno nuovi e anche piuttosto strani a tutti coloro non ancora abituati alla programmazione per Mac. Viceversa, chi già è in grado di programmare applicazioni desktop per OSX si sentirà piuttosto a suo agio: stesso strumento per creare le interfacce utente (Interface Builder), stesso linguaggio (anche se mancante di alcune novità dell'ultima versione, come la gestione automatica della memoria), e framework simile (Cocoa Touch, un sottoinsieme di Cocoa).

Ovviamente per chi viene da altri mondi (C#/VB.NET su Windows, o magari Java) l'impresa non è certo impossibile, ma solo un po' più ardua rispetto ad altre piattaforme. Recentemente sono usciti dei libri, tra i quali consiglio Beginning iPhone Development che possono davvero fare la differenza. Se partite da zero in questo ambiente, investite sicuramente nel libro se non volete perdere giorni cercando di capire come funziona questo mondo. Una volta iniziato poi sarà invece sicuramente più facile approfondire i dettagli dalla documentazione online.

Pro:
* Lo stesso programma può funzionare su iPhone e iPod Touch (a patto ovviamente che non usi la fotocamera o le funzioni telefoniche, non presenti nell'iPod), garantendo un grandissimo mercato.

* AppStore è l'unico store ufficiale dove pubblicare le proprie applicazioni, ed è perfettamente integrato sia con l'iPhone sia con iTunes => buona visibilità e ottime probabilità di essere trovati se l'utente cerca le keyword giuste

* Buon framework per creare con semplicità animazioni ed effetti grafici particolari.

* Presenza del DB engine Sqlite, e di una versione ridotta di OpenGL, oltre a tutta una serie di componenti e classi per creare belle interfacce utente, gestire l'interazione con l'utente, manipolare dati ecc. (le solite cose che ci si aspetta insomma, ma con parecchie cose in più sul lato della UI)

* Uniformità dei dispositivi: si sviluppa una volta sola, sapendo che tutti i propri utenti avranno dei device praticamente identici (stessa risoluzione, stessa potenza, stessa risoluzione della fotocamera ecc.). In realtà si può differenziare tra iPhone 2G e 3G (nel 2G manca il GPS) o tra iPhone e iPod Touch, ma comunque questo è nulla rispetto a quello a cui sono abituati gli sviluppatori in altre piattaforme!

Contro:
* Gli strumenti di sviluppo sono gratis, ma bisogna per forza avere un Mac per sviluppare.

* 99$/anno per avere la possibilità di stare nello store di Apple - non pochissimo per chi inizia, e soprattutto non poco per chi intende sviluppare applicazioni free!

* E' necessario pagare la licenza (leggi: le chiavi) anche per applicazioni custom per uno specifico cliente. Anzi in quel caso bisogna spendere 299$ per la licenza Enterprise.

* La documentazione e il supporto (sotto forma di forum, chat ecc.) sono ancora limitati rispetto ad altre piattaforme di sviluppo.

* Apple trattiene il 30% dalle vendite come commissione. E' una percentuale che "ci sta" in generale, ma la cosa negativa è che non c'è alternativa, ovvero oltre a pubblicare la mia applicazione sullo store non posso *anche* pubblicarla per conto mio e farmi pagare su PayPal, così da risparmiare sulle commissioni. (sto ovviamente trascurando la possibilità di scrivere applicazioni per device craccati - in quel caso c'è un mercato del tutto diverso, e una serie di riflessioni che non affronterò in questo post)

* Il costo medio delle applicazioni è attorno ad 1$...di conseguenza bisogna vendere veramente molto per guadagnarci qualcosa.

* Sebbene il sistema operativo di iPhone contenta di fare un sacco di cose, di fatto poi le API pubbliche consentono di fare molto ma molto meno: scordatevi di fare applicazioni che girano in background, applicazioni che intercettano eventi di sistema (chiamata / sms in arrivo), inviano SMS o mail, interagiscono con applicazioni di sistema quali il calendario, e che in generale accedono al device a basso livello. Le API per tutto ciò ovviamente esistono e Apple le usa per i propri applicativi, ma sono classificate come "private", non sono documentate, e se le usate Apple non vi consentirà di pubblicare il vostro programma nel suo store, relegandovi di fatto al mondo dei dispositivi craccati.

* Oltre ai limiti appena citati, c'è anche il fatto molto antipatico che Apple potrebbe rifiutare per una serie di motivi la vostra applicazione: non seguite qualche standard sull'interfaccia utente, avete fatto un'applicazione che fa qualcosa di simile ad un'applicazione di sistema (anche se magari lo fa molto meglio) esistente (o futura...), la vostra applicazione non rispetta certi standard prestazionali ecc. ecc. E' veramente troppo facile vedere la propria applicazione respinta...magari anche per più volte, e per motivi che spesso fanno imbestialire gli sviluppatori (che dopo aver speso settimane di lavoro vorrebbero vedere la propria creazione online il più presto possibile). Insomma la situazione è questa: iPhone è un sistema piuttosto chiuso, molto limitato riguardo a quello che vi permette di fare, e i programmatori sono in balia dei gusti di Apple.

In conclusione, le possibilità sono molto interessanti, ma potrebbero esserlo anche infinitamente di più se solo Apple cambiasse un po' politica e si aprisse di più. Attualmente ritengo che a meno che non abbiate veramente l'idea semplice ma geniale che vi faccia vendere centinaia di migliaia di copie, il motivo per buttarsi su iPhone sia piuttosto quello di farsi della buona esperienza su questa piattaforma e poi vendersi come consulenti: di lavoro sembra essercene parecchio, mi dicono amici da quel fronte ;)

Symbian devices (Nokia e altri)

I device con Symbian sono senz'altro meno "emozionanti" di iPhone (che per molti versi è stato una piccola rivoluzione), ma sono solidi, ben collaudati e diffusissimi. Sembrerebbero quindi un buon mercato dove indirizzarsi ma...a quanto pare se n'è già accorto da tempo un sacco di gente e attualmente ci sono quantità industriali di software per qualsiasi categoria. Trovare un'idea non ancora realizzata sembra una vera impresa. Se comunque questo non vi spaventa, continuate a leggere.

Cosa serve per sviluppare:
* Va bene praticamente qualsiasi PC con Windows, Linux o un Mac con OSX.
* Un IDE/compilatore Java (tipicamente Eclipse se volete restare nel free) o C++ (il vecchio Visual C++, il nuovo Visual Studio con C++, o il quotato CodeWarrior C++) (www.metrowerks.com)

Conoscenze richieste:
C++ per "applicazioni native", oppure J2ME (mobile edition) per applicazioni che girano dentro il runtime Java-based. Le applicazioni Java sono tipicamente più lente (niente giochi 3D spettacolari) e limitate (niente accesso a basso livello, niente funzioni avanzate quali intercettazioni di eventi di sistema ecc.), ma comunque è la scelta più produttiva e semplice per un gran numero di applicazioni che non richiedono cose molto particolari. C++ per contro permette di fare di tutto (ma proprio di tutto) sul Symbian, personalizzando qualsiasi aspetto...ma svilupparci sembra essere parecchio impegnativo, anche per chi già conosce il C++.

Sviluppare in Java ha anche il vantaggio che l'applicazione potrà poi essere portata anche su altre piattaforme con sforzi spesso molto ridotti, a volte addirittura assenti. Per un confronto tra le due opzioni fate riferimento a questo whitepaper. Per chi viene dal mondo .NET, imparare J2ME è una questione di pochi giorni. Chi invece già conosce Java deve sono vedersi le poche classi per creare l'interfaccia utente. In generale è un compito tranquillamente alla portata di chiunque abbia già delle buone basi di programmazione object oriented moderna.

Pro:
* Enorme diffusione della piattaforma.

* Facilità di sviluppo con Java.

* Portabilità della applicazioni sviluppate con Java.

* Costi di sviluppo molto ridotti o assenti.

* Libertà di scelta di vari canali di distribuzione (sul proprio sito, su store di terze parti ecc.).

* Il supporto per il mondo Java (sotto forma di forum, libri, corsi) di sicuro non manca.

Contro:
* Mercato già affollatissimo.

* Non c'è uno store centralizzato, bisogna registrarsi su vari store, ognuno con le proprie regole, le proprie commissioni, le proprie dati per l'invio dei compensi ecc.

* Esistono centinaia di diverse configurazioni hardware di cui tenere conto, e questo può facilmente diventare un inferno per lo sviluppatore che deve testare il software in infiniti simulatori, differenziare parti di codice, scrivere istruzioni dettagliate per modelli diversi, compilare una lista di compatibilità ecc.

In generale Symbian è una scelta con la quale difficilmente l'investimento di tempo andrà sprecato, non fosse altro che comunque Java è praticamente onnipresente. E' però un po' difficile creare applicazioni innovative data la ricchezza di software esistente.

BlackBerry

I BlackBerry prodotti da RIM (Research In Motion) sono dispositivi relativamente nuovi nel mercato italiano, ma già da molti anni popolarissimi negli USA, dove tra alti e bassi RIM è tra le prime 3 aziende del settore. Storicamente associati esclusivamente al mercato business (manager e impiegati che hanno bisogno di essere sempre collegati alla mail aziendale), gli ultimi modelli (Bold e Storm) sono di sicuro interesse anche per la massa degli utenti consumer, attenti alle funzioni multimediali, all'estetica, alla ricchezza di applicazioni.

Cosa serve per sviluppare:
* Va bene praticamente qualsiasi PC con Windows, Linux o un Mac con OSX.
* Eclipse + un plug-in di RIM; oppure il JDE, un ambiente derivato da Eclipse fatto su misura per lo sviluppo con BlackBerry. Se si inizia da zero con Java consiglio la seconda opzione, dato che richiede una più semplice installazione e configurazione.
* Un set di chiavi per firmare digitalmente le proprie applicazioni. Si comprano tramite il sito di RIM, e costano solo 20$, una-tantum.

Conoscenze richieste:
J2ME, come per Symbian. Ovviamente oltre alle classi generiche di J2ME RIM ha aggiunto tutta una serie di classi specilizzate per accedere alle funzionalità e caratteristiche peculiari del proprio sistema operativo e dei propri dispositivi, ma tipicamente si tratta solo di classe che ereditano da una classe J2ME base e la estendono con nuove proprietà (ad esempio BlackBerryContact the deriva da Contact). Come detto sopra per Symbian, provedendo dal mondo .NET la strada sarà perlomeno in pianura: pochi giorni dovrebbero bastare per leggersi le parti fondamentali della documentazione (disponibile a partire da qui), a guardarsi la vasta schiera di esempi installati assieme al JDE, e per cominciare a fare le prime prove concrete.

Pro:
* Semplicità di sviluppo.

* Non ci sono libri dedicati ma la documentazione ufficiale è piuttosto completa, gli esempi ufficiali coprano praticamente tutto, e il forum di supporto per sviluppatori è molto frequentato e vivo (una risposta arriva di solito in qualche ora).

* Il mercato potenziale è enorme, ma rispetto ad altre piattaforme esistono ancora pochi software => c'è più spazio per le proprie idee.

* Il prezzo medio delle applicazioni commerciali è piuttosto elevato (sui 15$), quindi con un'idea discreta ci si ripaga il tempo speso e ci si guadagna qualcosa in breve tempo.

* Esistono decine di device con caratteristiche diverse...ma almeno sono tutti di RIM, quindi è più facile tenerli sotto controllo e gestire una lista di compatibilità.

* RIM fornisce i simulatori di tutti i device, in modo da semplificare di molto il test delle proprie applicazioni.

* Tra le classi di J2ME e le estensioni di RIM è possibile interagire con il sistema operativo e le applicazioni di sistema in modo piuttosto completo: si possono intercettare molti eventi di sistema, scrivere delle applicazioni che girano in background e partono all'avvio, mandare SMS e mail, accedere al GPS, utilizzare connessioni verso indirizzi remoti, accedere ai dati del calendario e della rubrica, disegnare interfacce personalizzate, gestire suoni e video ecc.

* RIM ha annunciato che nel 2009 pubblicherà un suo store ufficiale, il che dovrebbe aiutare ancora di più le vendite di applicazioni di terze parti.

Contro:
* SDK parzialmente limitato per alcuni aspetti: non è ad esempio possibile cancellare SMS, intercettare degli eventi particolari, cambiare alcune impostazioni di sistema (profilo attivo, audio, immagine di sfondo della schermata principale) o cambiare il comportamento di alcune applicazioni di sistema.

* I file prodotti dalla compilazione (.JAR e .COD) non possono superare una certa dimensione massima. Ad esempio un file di 8MB (dimensione raggiunta includendo al suo interno molti file di testo, immagini ecc.) non verrà installato nel telefono.

* Non è presente un DB Engine installato di default. SQL Anywhere 11 di Sybase include UltraLite J per BlackBerry, un motore di database relazione che può andar bene in molte situazioni, ma è comunque un software da installare separatamente, e ha le sue limitazioni (soprattutto sul numero di oggetti gestibili)

In generale, vista l'ottima diffusione attuale del BlackBerry negli USA e la potenziale ottima diffusione futura globale, questa è una piattaforma sulla quale può aver molto senso investire. Tra l'altro, se si cambiasse idea e si volesse passare al mondo Symbian, buona parte delle conoscenze acquisite continuerebbero ad essere utilizzate.

Windows Mobile devices (HTC, Samsung, HP, Palm e altri)

Molti dei discorsi fatti per Symbian valgono anche per WM. Ci sono in commercio tantissimi dispositivi diversi, di produttori diversi, per qualsiasi tasca ed esigenza. WM è un sistema operativo piuttosto stabile e dalle mille possibilità, anche se purtroppo seriamente (e forse irrimediabilmente) compromesso da un'interfaccia grafica antiquata, scomoda...e brutta.

Cosa serve per sviluppare:
* Un PC con Visual Studio 2005/2008 Standard o Professional. Le versioni Express (gratuite) purtroppo non includono il supporto per lo sviluppo mobile.

Conoscenze richieste:
C#/VB.NET (anche C++ in realtà, ma ormai con C#/VB.NET si fa praticamente tutto...ad eccezione forse di videogame complessi) e il .NET Compact Framework. Se sviluppate già per Windows con Visual Studio, in pratica sapete già tutto e oltre quello che serve (si fa per dire, in realtà bisogna ovviamente studiarsi gli approcci, pattern e guideline specifiche delle applicazioni per mobile). Anche venendo dal mondo Java l'esperienza non dovrebbe essere traumatica. A semplificare di molto le cose c'è il fatto che Visual Studio è il più avanzato IDE al mondo, con potenti strumenti di design visuale delle interfacce grafiche, un editor di codice e un debugger eccellenti, e tutta una serie di strumenti di contorno che semplificano di molto la vita. Purtroppo a pagamento però.

Pro:
* Semplicità di sviluppo.

* Visual Studio è il miglior IDE che si possa desiderare, e la facilità di sviluppo ne beneficia ulteriormente.

* Ricca disponibilità di libri, tutorial, screencast, esempi e documentazione di vario tipo. Come per lo sviluppo in altri ambiti, Microsoft si distingue positivamente in questa categoria.

* Disponibilità di SQL Server Mobile Edition per la gestione di complessi database relazionali direttamente sul device (con la possibilità di sincronizzarsi con SQL Server)

* Libertà di scelta di vari canali di distribuzione (sul proprio sito, su store di terze parti ecc.)

* Ampia libertà di sviluppo: l'SDK permette di fare praticamente di tutto. Dove non sia possibile fare qualcosa con il .NET Compact Framework, è di solito possibile farlo con C++ a più basso livello.

* Nessuna approvazione e/o firma da organizzazione esterne è necessaria per il deployment dei propri applicativi custom.

* Grande disponibilità di componenti commerciali (es: griglie avanzate o controlli per realizzare grafici) già pronti all'uso.

Contro:
* Mercato già piuttosto saturo, è difficile creare applicazioni particolarmente originali.

* Non esiste uno store centralizzato per la vendita => Meno visibilità, meno facile essere trovati.

* Creare un'interfaccia utente accettabile per i propri programmi significa sostanzialmente crearsela da zero. Del resto così facendo si perde l'uniformità con il resto delle applicazioni - per quanto brutta la UI, di solito una qualche uniformità è utile.

In conclusione WM può essere una buona piattaforma per sviluppare in libertà applicazioni di vario tipo, anche se creare qualcosa di "fuori dal coro" richiede uno sforzo ulteriore rispetto a quello che si potrebbe pensare.

Conclusioni generali

iPhone ha un hardware molto interessante, è di moda e con un buon mercato; ma è molto limitato per le applicazioni di terze parti, e la politica di Apple è difficilmente apprezzabile dagli sviluppatori.

Symbian è diffusissimo, molto flessibile e potente. Il test e il deployment può però diventare molto problematico dato l'elevato numero di dispositivi in commercio da vari produttori. Il mercato è già molto affollato.

Il BlackBerry è in espansione, svilupparci sopra costa praticamente zero ed è semplice. C'è meno competizione rispetto alle altre piattaforme. L'SDK e l'OS stesso però a volte risulta limitato, e non ci sono molte sorgenti di informazioni e supporto oltre a quelle ufficiali (comunque molto buone)

Windows Mobile e Symbian hanno più o meno gli stessi pro e contro - l'uno o l'altro è quasi una scelta di vita!

Nella propria scelta c'è un fattore al quale io personalmente ho dato una grandissima importanza: cosa conosco già? Io ho deciso che se dovevo sviluppare delle utility nel mio tempo libero (almeno per ora), doveva essere abbastanza stimolante e divertente. Lavorare con gli stessi linguaggi, framework e IDE con i quali lavoro tutto il giorno non mi avrebbe dato questi stimoli. Ho deciso che imparare un minimo di Java e di Objective-C mi avrebbe fatto solo bene. Viceversa qualcuno potrebbe voler fare lo sforzo minimo e usare quello che già conosce: anche questa è ovviamente una scelta rispettabilissima...alla fine l'importante è iniziare con qualcosa...se poi piace e si vuole guardare verso altri orizzonti...

Ultimamente, lavorando spesso a casa su progetti sia personali che per clienti, mi è cominciata a venire "l'ansia da backup". In realtà è una sensazione già provata parecchie volte, dopo che l'altr'anno mi era saltato un disco pieno di roba. Fortunatamente già da vari anni uso una qualche forma di software di backup che regolarmente copia tutti i dati importanti su un disco esterno quasi esclusivamente dedicato a quello scopo; quindi praticamente nessuna perdita seria in quell'occasione.

La preoccupazione è in realtà generata dal pensiero che se parto per le vacanze e qualcuno mi entra in casa rubando PC e disco esterno, ho perso anche il backup. Idem se scoppia un piccolo incendio o se un vaso di fiori pieno d'acqua mi si rovescia sulla scrivania inondando tutto. Certo, basterebbe anche fare il backup su un NAS opportunamente nascosto e collocato separatamente rispetto al PC. E se però il backup mi servisse mentre sono in viaggio di lavoro, magari per una o due settimane? Non mi posso certo portare dietro il disco esterno, avrei sempre il problema furto/smarrimento, oltre all'ovvio problema di ingombro / peso / scomodità. Beh ma mi potrei portare dietro una copia su DVD, no? No perchè non ho voglia di sprecare n DVD, e soprattutto non ho voglia di star li a far scrivere i DVD ogni volta. Configurare il NAS in modo che sia visibile dall'esterno? Mmm, già è una configurazione di troppo per i miei gusti (devo avere un IP statico, e se non ho un IP statico devo usare qualcosa come DynDns.org), e comunque richiede di tenere in casa una connessione costantemente attiva.

E allora? Allora ho cominciato a pensare all'opportunità di fare dei backup online, tramite dei servizi dedicati. Dopo un po' di ricerche tramite il fido Google e dopo aver letto decine di recensioni entusiastiche, anche per me la scelta è caduta su Mozy. Il piano base da 4.95$ al mese (3.75€ al cambio attuale) consente di archiviare dati illimitati! Niente male, considerando che non è affatto difficile spendere più di 45€ all'anno comprando software di archiviazione, DVD vergini e HD esterni...

Ma le cose sono anche migliori, perchè se dovete archiviare meno di 2GB di dati, Mozy è totalmente free. Certo non salverete la vostra collezione di musica e film, ma probabilmente in 2GB i documenti e i progetti di lavoro (parecchio codice, nel mio caso) ci potrebbero tranquillamente stare. Questa è pertanto l'opzione che sto usando al momento - nel caso dovessi aver bisogno di ulteriore spazio, l'upgrade è comunque immediato da effettuare.

A parte la versione Home da 4.95$ per spazio illimitato, ci sono anche le versioni Pro ed Enterprise che permettono di fare il backup di file server, SQL ed Exchange, oltre a poter girare sulle versioni server di Windows e OSX. Si veda questa pagina per un confronto. Per "l'utente normale" (e qui includo anche il professionista che lavora senza un'infrastruttura fantascientifica) la versione Home è comunque sufficiente nel 99% dei casi.

Una volta iscritti e scaricato il software Mozy Client, lo si configura scegliendo le cartelle da backuppare, e impostando la schedulazione preferita (quando il computer non sta facendo nulla, ad una certa ora del giorno, in una certa data, ecc.). In pratica si trova gran parte di quello che c'è in un software di backup "classico". Il backup effettuato è incrementale, funziona anche con i file correntemente aperti, e supporta il versioning, il che risulta perfetto per chi modifica spesso i propri documenti (es: i sorgenti di un programma in fase di sviluppo) e vuole tornare alla versione di una data specifica. Certo non sostituisce software di versioning come SVN o TFS, ma è già qualcosa di molto utile.
Oltre che tramite l'applicazione dedicata di configurazione, è possibile aggiungere un folder al backup tramite una nuova voce aggiunta al menu contestuale di Windows Explorer (Gestione Risorse) in fase di installazione. Davvero comodissimo.

Per quanto riguarda la sicurezza, tutte le comunicazioni client-server sono cifrate tramite SSL. I dati sul server di Mozy sono poi cifrati tramite una chiave a 448bit! La chiave può essere quella di default di Mozy, oppure una scelta dall'utente. La prima opzione è consigliata per utenti senza troppi segreti da proteggere, e che non vogliono o non sanno crearsi una propria chiave; la seconda opzione dovrebbe comunque permettere anche ai più ansiosi di dormire sonni tranquilli.

Infine, per il restore dei dati ci sono almeno tre scelte:
1) Si fa tutto tramite l'applicazione desktop
2) Da Windows Explorer si può accedere al proprio spazio remoto sul server di Mozy tramite un hard disk virtuale chiamato MozyHome Remote Backup, che si comporta come un disco locale!
3) Si va sul sito di Mozy e dalle pagine private del proprio account sfogliare il materiale salvato online e scegliere cosa si vuole scaricarsi. Dopo aver confermato la selezione Mozy si mette al lavoro zippando il materiale scelto, e informa l'utente via mail quando questo è pronto. All'arrivo della mail l'utente può quindi scaricarsi lo ZIP auto-estraente in locale; questa soluzione può rivelarsi davvero eccellente nel caso si voglia scaricarsi qualcosa (magari non tutto il backup, ma solo qualche documento specifico) mentre si è da un cliente, in vacanza o comunque in qualche luogo senza il proprio PC e soprattutto senza una copia locale dei dati con i quali si lavora da casa.

Ancora non vi basta per convincervi a provarlo?

Qualche giorno fa Google ha regalato ai propri utenti di Gmail una nuova piccola feature: la possibilità di cambiare lo stile di default scegliendo un tema alternativo. Per andare nella galleria dei temi basta cliccare Settings / Themes e poi scegliere una delle attuali 31 possibilità.

Una moltitudine di blog hanno già parlato di questa novità (manco fosse una cosa così eccezionale), omettendo di citare che in realtà esiste già da tempo una soluzione (di successo direi, dato che è usata da quasi 2,5 milioni di persone) per fare la stessa cosa...ma per qualsiasi sito! Parlo dell'estensione Stylish di FireFox, e del relativo sito di supporto UserStyles.org.

Quello che fa questa estensione è sostanzialmente molto semplice: permette di applicare a qualsiasi sito o pagina uno stile CSS custom. Cambiando lo stile CSS è possibile cambiare colori, immagini e loghi, e addirittura rendere visibili o invisibili alcune sezioni della pagina (ad. esempio una colonna laterale contenente solo pubblicità). Il sito UserStyles.org è un enorme repository di stili creati e condivisi da altri utenti: basta cercare il nome di un sito e verranno elencati i relativi stili custom da scaricare e applicare tramite Stylish.

Ecco un esempio di come si può trasformare FaceBook:

...oppure Google:

Oltre a rendere un sito più gradevole alla vista (perlomeno secondo i propri gusti...) quest'estensione può essere molto comoda per i possessori dei mini notebook da 9" o 10" che vanno così di moda ultimamente: applicando infatti uno stile che elimini (nascondendole) colonne o sezioni di pagina "inutili", la ridotta risoluzione dello schermo potrà essere usata al meglio per visualizzare i contenuti "interessanti".

Dopo 10 anni di consulenze on-site per una moltitudine di clienti diversi, c'è una cosa che non smette di colpirmi e sorprendermi, anzi lo fa sempre di più con il passare del tempo. Sto parlando dell'apparente incapacità di moltissimi programmatori di cercare informazioni online. Non è affatto raro trovare qualcuno che ha un problema e che sta li ore ed ore a sbattere la testa con il proprio codice non funzionante, a grattarsi la testa davanti ad un criptico messaggio di errore che non se ne vuole andare, e al massimo ridursi a cercare lumi nella documentazione locale installata assieme al software/framework/IDE/linguaggio del caso.

Ma come si fa...non è infinitamente più semplice, immediato e produttivo cercare la soluzione online, e più specificatamente tramite Google? Con un messaggio di errore spesso è semplicissimo, basta copiare e incollare il messaggio as-is, e metterlo tra virgolette in modo da cercare la frase esatta. Pochi risultati? Togliete le virgolette. Troppi risultati? Aggiungete, fuori dalle virgolette, qualche parola chiave relativa al vostro contesto. Con un problema tipo "come eseguire del codice javascript al termine di un aggiornamento parziale tramite UpdatePanel di ASP.NET?" le cose si complicano, ma solo un po'.

In realtà oltre ai programmatori che per qualche misterioso motivo proprio non pensano di usare un motore di ricerca per trovare una soluzione, ci sono quelli che ci pensano, anche subito magari, ma mollano dopo qualche query infruttuosa. Essere in grado di cercare con profitto su Google è un'abilità che va affinata con la pratica, come qualsiasi altra cosa, quindi è normale che cercare a caso senza criterio spesso porti a cattivi risultati. Ma il problema è anche che la stragrande maggioranza dei programmatori italiani usa tool di sviluppo localizzati in italiano, legge documentazione in italiano, e parla solo con colleghi italiani. Usare un IDE/framework in italiano significa che i messaggi di errore saranno in italiano, e cercare in Google quel messaggio di errore in italiano ovviamente produrrà una quantità di risposte infinitesimale rispetto alla ricerca dello stesso messaggio di errore in lingua originale, ovvero in inglese. Tradurre "a occhio" il messaggio di errore non funziona bene, anzi mettendo il messaggio tra virgolette quasi sicuramente non funzionerà affatto. (questo è anche causato dal fatto che l'iniziale traduzione da inglese a italiano spesso viene fatta in modo un po' fantasioso, e solo quel primo traduttore potrebbe forse essere in grado di compiere il procedimento inverso ottenendo perfettamente la frase di partenza :-)

A parte i messaggi di errore da copiare e incollare, e indipendentemente dalla lingua dei propri strumenti, una larga percentuale di programmatori si ostina a cercare soluzioni e pezzi di codice scrivendo in italiano. Questo non è patriottismo o nazionalismo...è poca furbizia, o poco interesse. Certo, in italiano abbiamo delle fantastiche risorse come i forum di ASPItalia , i forum di Visual-Basic.it, oppure vari newsgroup. Una ricerca lì vale la pena farla, magari anche lasciare la propria domanda se non si trova già qualcosa di pronto...ma nel caso i primi 10 minuti di ricerca in italiano non risolvessero la questione vogliamo passare all'inglese?

In Italia abbiamo programmatori bravissimi, come in ogni altra parte del mondo...ma siamo pochi, pochissimi se paragonati alle decine di milioni di programmatori che usano l'inglese come lingua principale o che comunque lo conoscono sufficientemente da scrivere in linguaggio *tecnico*. E' una questione di numeri, tutto qua. Qualcuno alza la mano dicendo che non conosce l'inglese? Beh, è ora di impararlo! Non averlo studiato a scuola non è una ragione valida. L'inglese è facile da imparare, ed esistono infinità di corsi su CD, DVD, film
sottotitolati, libretti semplici per cominciare a farci la mano. L'inglese tecnico poi, quello che serve ad un programmatore per capire e farsi capire, è formato da una sintassi di base, un piccolissimo sottoinsieme di termini generici, e una grande quantità di termini specifici di settore (da conoscere in ogni caso). Anche con una conoscenza di base, e leggendo documentazione in inglese, si sta prestissimo a farci la mano. Scrivere funziona alla stessa maniera, bisogna cominciare a farlo. E sempre di più in futuro.

La prossima volta che farete un colloquio di lavoro a qualcuno chiedetegli come si comporta davanti ad un messaggio di errore incomprensibile o davanti ad un problema che non sa come risolvere. Se non vi dirà che cerca su Google (o perlomeno su forum e newsgroup di settore) e se ammetterà di non poter leggere e scrivere in inglese tecnico, pensateci bene...

Una corretta attitude verso la ricerca può servire più di una conoscenza di partenza della tecnologia di turno; e l'inglese non serve solo per gestire eventuali clienti o partner stranieri, serve per il lavoro di ogni giorno.