Come da titolo, ufficialmente I give up on Symbian.
È una mezza sconfitta. Dico "mezza" perché è bene capire quando lottare e quando ritirarsi.
Nel mio caso la lotta (impari) era contro un sistema decisamente poco user-friendly e ricco di bug, dal costo elevato (sia in termini di prezzo dell'apparecchio, specie se rapportato alla qualità, e di tempo da perdere), e con una comunità poco disponibile.
Quando capisci che non puoi ottenere di più, diventa inutile e controproducente accanirsi.
Ok, ammetto di essermi posto in modo polemico, ma spendere dei soldi per qualcosa che dopo sei mesi è già vecchio, che viene letteralmente abbandonato dalla casa madre senza che l'utente possa riqualificarlo in alcun modo (cercherò di vedere se e come sostituire il firmware, ma dispero e non ci perderò molto tempo), vedere che bachi e mancanze anche gravi vengono sì corrette, ma nel telefono successivo ... - Neanche Microsoft fa così (e ho detto tutto) - tutto questo non porta certo ad un sentimento di gioia e appagamento.
Sarà stato per il tono polemico, ma la comunità Nokia-Symbian è decisamente poco propensa nell'aiutare chi, preda dello sconforto, evidenzia le carenze architetturali o i problemi incontrati (tipo il fatto che non sono mai riuscito a mettere in pista l'SDK di Symbian, o quell'idiozia della firma delle applicazioni anche per un uso "privato" solo sul proprio telefonino)
Così ho deciso che in 3 (o forse 4) anni ho ammortizzato il costo del mio E61 e sono passato a comperare un tablet più serio (che non monta né Symbian né Windows Cesso Edition) che posso finalmente utilizzare come palmare.
Android? No: Maemo. Un Nokia N900.
Non è tanto per Maemo, quanto per il fatto che ho potuto vedere l'apparecchio in questione e parlare dei diversi pregi e difetti della macchina con chi lo usa come palmare, e il fatto di poter accedere alla flash per fare sia i backup dell'intero firmware che sostituire l'intero firmware.
Poi Maemo ha dietro Debian, quindi il mondo.
Perché non Android?
Semplicemente perché non sopporto Java. Comunque l'N900 può ospitare anche Android.
E l'iPhone?
A me interessa programmare, non usare solamente i programmi di altri.
Se me lo regalassero non lo rifiuterei. Lo apprezzo anche, ma non è il mio target.
Da questo punto di vista l'N900 va bene: touch screen e tastiera qwerty estesa a scomparsa.
Ho fatto un buon acquisto? Boh. Vedremo. Un minimo di incertezza c'é sempre.
Ad ogni modo se come telefono dovesse avere problemi, posso sempre usarlo come semplice palmare, cosa che non posso comunque fare con l'E61.
Chiudo il post scusandomi con Symon_89 per non aver risposto al suo ultimo commento.
Io ci rinuncio a stare dietro ai capricci e ai problemi di un sistema così chiuso.
Ovviamente dispiace anche a me parecchio. Allora avrei potuto prendere un telefono normale e risparmiarmi diversi problemi (e diversi soldi, dato che avevo acquistato uno smartphone che ho usato praticamente solo come phone), ma alla fine la prendo in modo positivo come esperienza (da non ripetersi, nel limite del possibile).
2010-11-07
2010-08-15
PyS60: la calma è la virtù dei forti
... ed io l'ho persa da tempo. :-)
Battute a parte, ci voleva un pomeriggio di ferragosto per riuscire a mettersi dietro a questo progetto che mi permette (forse) di utilizzare il mio smartphone come tale e non solo come telefono. Almeno in attesa di decidermi se prendere l'N900.
In due parole, il progetto permette di mettere sul telefonino un interprete python e quindi di scrivere programmi e script in modo semplice. Dico semplice perché non sono mai riuscito a mettere in pista tutta la pappardella di sw, plugin, editor (perché si è praticamente obbligati anche a mettere un IDE basato su Eclipse, e io odio Eclipse), né sotto Linux né sotto Windows.
Con PyS60 ho dovuto installare la versione 1.9.6 invece della 2.0.0 perché semplicemente le versioni successive necessitano di un firmware più aggiornato di quello che ho e Nokia non aggiorna praticamente mai il firmware dei suoi apparecchi. È più comodo farne comperare di nuovi.
Con Python esiste il progetto Ensymble che permette(rebbe) di convertire un progetto python in un file sis e quindi installarlo sul telefono.
Piccolo problema: gira con Python 2.5. Sui pc trovi la 2.6. Vabbé. Esiste la versione 0.29 che gira sotto Python 2.6, ma ho dovuto correggere un paio di cose nei sorgenti (più un tarocco in installazione) per riuscire a farla girare.
Sia come sia, documentazione alla mano, tutorial a portata dell'altra mano, riesco finalmente a far funzionare uno script che si mette in ascolto sul bluetooth e a scambiarci informazioni.
Devo ancora mettere a punto qualche impostazione, ma sembra funzionare.
Lo scopo finale è quello di farmi un programma di monitoraggio del telefono che permetta di vedere informazioni semplici (come il gestore a cui sono collegato, batteria e livello segnale), un po' più complesse (ad esempio calendario, contatti, e magari sincronizzarli con Thunderbird), fino ad arrivare ad un'interfaccia di invio messaggi o altri giochini che mi possono venire in mente. In pratica comandare il cellulare in modo completo dal pc.
Dovrò penare per diverse cose poiché non saranno compatibili con la mia versione di PyS60, ma potrebbe essere divertente.
Vediamo che ne salta fuori.
Battute a parte, ci voleva un pomeriggio di ferragosto per riuscire a mettersi dietro a questo progetto che mi permette (forse) di utilizzare il mio smartphone come tale e non solo come telefono. Almeno in attesa di decidermi se prendere l'N900.
In due parole, il progetto permette di mettere sul telefonino un interprete python e quindi di scrivere programmi e script in modo semplice. Dico semplice perché non sono mai riuscito a mettere in pista tutta la pappardella di sw, plugin, editor (perché si è praticamente obbligati anche a mettere un IDE basato su Eclipse, e io odio Eclipse), né sotto Linux né sotto Windows.
Con PyS60 ho dovuto installare la versione 1.9.6 invece della 2.0.0 perché semplicemente le versioni successive necessitano di un firmware più aggiornato di quello che ho e Nokia non aggiorna praticamente mai il firmware dei suoi apparecchi. È più comodo farne comperare di nuovi.
Con Python esiste il progetto Ensymble che permette(rebbe) di convertire un progetto python in un file sis e quindi installarlo sul telefono.
Piccolo problema: gira con Python 2.5. Sui pc trovi la 2.6. Vabbé. Esiste la versione 0.29 che gira sotto Python 2.6, ma ho dovuto correggere un paio di cose nei sorgenti (più un tarocco in installazione) per riuscire a farla girare.
Sia come sia, documentazione alla mano, tutorial a portata dell'altra mano, riesco finalmente a far funzionare uno script che si mette in ascolto sul bluetooth e a scambiarci informazioni.
Devo ancora mettere a punto qualche impostazione, ma sembra funzionare.
Lo scopo finale è quello di farmi un programma di monitoraggio del telefono che permetta di vedere informazioni semplici (come il gestore a cui sono collegato, batteria e livello segnale), un po' più complesse (ad esempio calendario, contatti, e magari sincronizzarli con Thunderbird), fino ad arrivare ad un'interfaccia di invio messaggi o altri giochini che mi possono venire in mente. In pratica comandare il cellulare in modo completo dal pc.
Dovrò penare per diverse cose poiché non saranno compatibili con la mia versione di PyS60, ma potrebbe essere divertente.
Vediamo che ne salta fuori.
2010-04-05
Condivisione dati
Uno dei problemi di chi utilizza tanti computer (intendendo con "tanti" più di due computer) è la condivisione dei dati tra gli stessi.
Avere un serverino a casa aiuta, ma devi sempre ricordarti di copiarci sopra i dati e, ancora più importante, devi ricordarti di prelevare i dati che ci hai copiato su.
Detto questo, si pone un altro problema che affligge chiunque abbia a che fare professionalmente con i computer: l'organizzazione dei dati.
L'organizzazione gerarchica arborescente (l'albero delle directory) dei normali filesystem è a dir poco inefficente. Viene incontro il fatto di non avere le lettere di unità che complicano solo la vita agli utenti Windows. Tuttavia per ora non c'è molto che si possa fare.
Quando si parla di backup si introduce un ulteriore problema: la macchina di cui si fa il backup. Incrociare i dati per cercare di evitare i duplicati è un lavoro lungo e tedioso. Praticamente nessuno lo fa volentieri (leggi come: non lo fa nessuno, nemmeno io).
La cosa più comoda sarebbe avere uno spazio "condiviso" in locale, ossia uno spazio su ciascuna macchina che si sincronizzi più o meno in tempo reale (se connesso alla rete) con le altre macchine.
Un sistema simile esiste e si chiama Dropbox.
Come si dice: «morto un papa, se ne fa un altro», si può dire «risolto un problema, ne introduciamo due».
Infatti Dropbox è un servizio limitato nella sua forma gratuita (devono pure campare), e comunque parcheggi i tuoi dati su un server remoto che si trova negli USA.
A parte questo, sarebbe carino avere qualcosa di simile in un ambiente limitato quale la rete di casa, e con spazio illimitato (mi compero un HDD più capiente e posso moltiplicare la capacità del backup).
Un sistema di questo tipo è tecnicamente semplice. Delicato nella fase di progetto, ma semplice nella realizzazione. Un po' per necessità, un po' per diletto, sto provando a farmene uno io in casa.
Come scelte architetturali, ho optato per l'uso di Python.
Lato server (Debian) lavoro con Django e Sqlite3.
Lato client (Ubuntu) lavoro con Python e le sue (infinite) librerie.
Eventualmente metterò in pista anche un client per Windows sempre in Python.
Perché queste scelte?
Intanto per la ricchezza delle librerie già presenti. Non mi va di concentrarmi sul protocollo HTTP, o sull'implementazione delle hash.
Ho già tutte le librerie di cui ho bisogno e anche di più.
Come client il fatto di lavorare in Python mi permette di avere un unico client che giri quasi ovunque. Mi preoccuperò dei vari aspetti delle sfumature dei sistemi operativi se e quando ne avrò bisogno.
Django è un ambiente per lo sviluppo di applicazioni web molto buono e completo, pur essendo solo alla versione 1.1, e mi permette di lavorare concentrandomi sul codice.
Python può essere programmato con diversi paradigmi. Personalmente preferisco lavorare con linguaggi funzionali, ma per la maggior parte delle cose va più che bene.
Se e quando il progetto vedrà la luce in una versione 0.1 alfa, deciderò se pubblicarlo. Dopo una giornata sono al 20% del lavoro sul server.
Avere un serverino a casa aiuta, ma devi sempre ricordarti di copiarci sopra i dati e, ancora più importante, devi ricordarti di prelevare i dati che ci hai copiato su.
Detto questo, si pone un altro problema che affligge chiunque abbia a che fare professionalmente con i computer: l'organizzazione dei dati.
L'organizzazione gerarchica arborescente (l'albero delle directory) dei normali filesystem è a dir poco inefficente. Viene incontro il fatto di non avere le lettere di unità che complicano solo la vita agli utenti Windows. Tuttavia per ora non c'è molto che si possa fare.
Quando si parla di backup si introduce un ulteriore problema: la macchina di cui si fa il backup. Incrociare i dati per cercare di evitare i duplicati è un lavoro lungo e tedioso. Praticamente nessuno lo fa volentieri (leggi come: non lo fa nessuno, nemmeno io).
La cosa più comoda sarebbe avere uno spazio "condiviso" in locale, ossia uno spazio su ciascuna macchina che si sincronizzi più o meno in tempo reale (se connesso alla rete) con le altre macchine.
Un sistema simile esiste e si chiama Dropbox.
Come si dice: «morto un papa, se ne fa un altro», si può dire «risolto un problema, ne introduciamo due».
Infatti Dropbox è un servizio limitato nella sua forma gratuita (devono pure campare), e comunque parcheggi i tuoi dati su un server remoto che si trova negli USA.
A parte questo, sarebbe carino avere qualcosa di simile in un ambiente limitato quale la rete di casa, e con spazio illimitato (mi compero un HDD più capiente e posso moltiplicare la capacità del backup).
Un sistema di questo tipo è tecnicamente semplice. Delicato nella fase di progetto, ma semplice nella realizzazione. Un po' per necessità, un po' per diletto, sto provando a farmene uno io in casa.
Come scelte architetturali, ho optato per l'uso di Python.
Lato server (Debian) lavoro con Django e Sqlite3.
Lato client (Ubuntu) lavoro con Python e le sue (infinite) librerie.
Eventualmente metterò in pista anche un client per Windows sempre in Python.
Perché queste scelte?
Intanto per la ricchezza delle librerie già presenti. Non mi va di concentrarmi sul protocollo HTTP, o sull'implementazione delle hash.
Ho già tutte le librerie di cui ho bisogno e anche di più.
Come client il fatto di lavorare in Python mi permette di avere un unico client che giri quasi ovunque. Mi preoccuperò dei vari aspetti delle sfumature dei sistemi operativi se e quando ne avrò bisogno.
Django è un ambiente per lo sviluppo di applicazioni web molto buono e completo, pur essendo solo alla versione 1.1, e mi permette di lavorare concentrandomi sul codice.
Python può essere programmato con diversi paradigmi. Personalmente preferisco lavorare con linguaggi funzionali, ma per la maggior parte delle cose va più che bene.
Se e quando il progetto vedrà la luce in una versione 0.1 alfa, deciderò se pubblicarlo. Dopo una giornata sono al 20% del lavoro sul server.
Iscriviti a:
Post (Atom)