Nonostante le migliori intenzioni, dopo un periodo iniziale non sono riuscito a portare a termine la nuova versione di MoioSMS ed ho dovuto abbandonare il progetto per carenza di tempo a disposizione.
Lascio l’articolo qui per chi lo volesse leggere, ma le informazioni riportate sono essenzialmente obsolete.
Come anticipato a qualcuno sul forum, è mia intenzione rinnovare radicalmente MoioSMS. La prossima versione di MoioSMS, la numero 3, si baserà su una piattaforma del tutto diversa e, nelle speranze di chi scrive, occorrerà meno tempo per mantenerla aggiornata – una condizione essenziale perchè un progetto come questo, che è fatto nel tempo libero, possa sopravvivere. Cercherò anche, come sempre, di rendere il programma più semplice e funzionale per l’utente.
Questo articolo spiega le ragioni della mia decisione ed ha un taglio decisamente tecnico – spero che gli altri sviluppatori dicano la loro nei commenti.
Motivazioni del cambiamento
La ragione di una così drastica decisione è dovuta a più fattori, il principale è che ritengo Python una piattaforma non più soddisfacente per le esigenze di questo progetto. Nonostante sia perfetto per l’uso in Linux, ambiente dove il progetto è nato, non è così semplice mantenere una buona compatibilità anche con gli altri Sistemi Operativi (ad esempio, lo stato di manutenzione ed aggiornamento di py2exe e py2app lascia parecchio a desiderare).
Un punto dolente sono le librerie grafiche che anni fa scelsi per l’interfaccia utente, le famose WxWidgets, che nel tempo hanno mostrato una lunga serie di limiti, errori non risolti, carenze di documentazione e poca uniformità tra Windows, Mac e Linux.
Altro punto debole è il sistema di decodifica delle immagini CAPTCHA, più che macchinoso, inefficiente e dipendente da una serie di altri programmi. D’altra parte, Python non dispone a mio parere di un’implementazione sufficientemente buona delle reti neurali, gli oggetti matematici che si usano a questo scopo, quindi non è facile passare ad algoritmi migliori. Il fatto di usare programmi esterni, inoltre, ha dato origine a una serie di grattacapi su come rendere il programma autocontenuto, il che ha sollevato nuovi problemi con firewall ed antivirus in Windows.
I problemi di Python non si fermano qui: un’esigenza da troppo tempo trascurata è quella di ristrutturare l’applicazione in modo da funzionare su più thread di esecuzione, per evitare di bloccare l’interfaccia durante l’invio dei messaggi. Anche qui, il supporto di Python alla programmazione concorrente è rudimentale, soprattutto in ottica di indipendenza dalla piattaforma (questo è cambiato recentemente con librerie come Twisted, che però usa processi anzichè thread, una soluzione a mio parere sub-ottimale).
Nuove idee
Ho passato parecchio tempo prima di trovare, capire e scegliere la tecnologia giusta per superare questi problemi. La scelta è infine ricaduta sul linguaggio Scala, che fa uso della piattaforma Java. I vantaggi che mette a disposizione sono notevoli:
- permette di scrivere codice compatto, similmente a Python e a differenza di Java, pur restando un linguaggio tipato staticamente, il che aiuta lo sviluppatore a trovare difetti nel codice prima della sua pubblicazione;
- ha integrata una libreria per il multitheading basata sul modello ad attori, che ritengo essere decisamente buono (l’ho usato, tra le altre cose, nella mia tesi di secondo livello in quanto fornito direttamente in Qt come estensione del meccanismo signals&slots);
- essendo basato sulla piattaforma Java:
- è meglio predisposto, rispetto a Python, per lo sviluppo su più piattaforme (vedi il concetto WORA: anche se non è vero in termini assoluti lo è in buona parte). Non ho dubbi, ad esempio, sul fatto che si possano realizzare interfacce più portabili in Swing piuttosto che WxWidgets per esperienze passate;
- permette di accedere a un numero esorbitante di librerie, anche di alta qualità, già esistenti per Java, in particolare l’ottima libreria Encog per le reti neurali;
- permette di ottenere eseguibili (Jar) più compatti rispetto agli exe/app attuali ed effettivamente eseguibili con un doppio click su tutte le piattaforme – al patto al più di installare un JRE su Windows qualora non sia già presente, cosa comunque facilmente aggirabile. Inoltre con poca fatica si possono ottenere Jar completamente autocontenuti, integrando la libreria per l’accesso http, la libreria per le reti neurali, i dati statici necessari e così via.
Cosa resta da fare
Le motivazioni che ho esposto non piovono dal cielo, in quanto prima di sbilanciarmi ho già preparato una versione (molto) preliminare di MoioSMS che riesce a mandare messaggi da Vodafone con un algoritmo apposito di decodifica dei CAPTCHA che arriva a un quasi-incredibile 92% di accuratezza. Nel prossimo periodo scriverò qui sul sito alcuni articoli che spiegheranno come il sistema funziona.
Nel frattempo punto a rilasciare una prima versione utilizzabile di MoioSMS 3. Per evitare di aspettare altri anni dapprincipio non ci saranno molti dei siti inizialmente supportati e molte funzionalità dovranno essere aggiunte in seguito, ma fin da subito dovrebbero vedersi i frutti della nuova architettura:
- un eseguibile autocontenuto, compatto e comune a tutte le piattaforme, con molti meno problemi di dipendenze;
- la spedizione degli SMS in un thread separato;
- decodifica dei CAPTCHA (inizialmente, di Vodafone) estremamente più veloce ma soprattutto
- un tempo di risposta ai problemi degli utenti inferiore.
Agli altri sviluppatori
Innanzitutto, grazie per tutto quello che avete fatto in questi mesi. Temo che qualcuno di voi non sarà contento di leggere queste righe – l’abbandono di Python sarà un divorzio doloroso, e forse non strettamente necessario, ma spero che condividiate le mie ragioni e che continuiate ad operare nella comunità di MoioSMS. E’ mia intenzione coinvolgervi maggiormente rispetto al passato, ovviamente se siete disponibili, iniziando da una discussione sulle idee in questo articolo.
A presto!
23 Commenti
Wow!
Personalmente credo che si tratti di una buona notizia: pur essendo, da sviluppatore web, un grande fan di Python, è inutile negare che scrivere applicazioni desktop multipiattaforma con questo tipo di linguaggi sia davvero un PITA [1].
Scala mi è piaciuto fin dall’inizio: credo sia un valido e soprattutto *moderno* erede di Java.
Credo che la JVM sia l’unica piattaforma che consenta davvero di girare su tutti i SO senza troppi problemi.
Non posso non citare l’alternativa Jython [2], che se da un lato ci consentirebbe di riciclare un po’ di codice, dall’altro si porta dietro un po’ dei problemi di Python. In particolare il modello di concorrenza, pur basandosi sui thread della JVM, non sarebbe all’altezza.
Ultima osservazione: direi di approfittare di questa “rivoluzione” per dotare MoioSMS di strumenti che facilitino il coinvolgimento della comunità: sistema di controllo di versione, bug tracker, ecc. Sourceforge o Github ad esempio andrebbero benissimo.
My 2 cents,
—
Giuseppe
[1] http://www.urbandictionary.com/define.php?term=PITA
[2] http://www.jython.org
Che bello. 🙂 Non conoscevo neppure Scala, ma devo dire che la cosa è quantomeno stimolante. 😛
Analisi molto interessante, non vedo l’ora della nuova versione in Scala (scelta intrigante 🙂
Un altra vittima del GIL python! 😀
Scala, Erlang e simili stanno prendendo sempre più piede. Magari appena rilasci i sorgenti gli do un’occhiata. Per l’interfaccia grafica potresti utilizzare Qt Jambi, con il vantaggio di avere un look & feel nativo su tutte le piattaforme possibili!
P.S.
Complimenti per il progetto della tesi di laurea… mi sono visto il video e l’ho trovato estremamente interessante
Riguardo a Jambi: al di là del fatto che da quando Qt è passata in mano a Nokia non so bene cosa aspettarmi sul futuro lato desktop, visto che i nuovi padroni finlandesi hanno più che altro mire per lo sviluppo sui loro cellulari, mi chiedo se ne valga la pena di assorbire una dipendenza così grossa. Si tratta infatti di svariate decine di MB dipendenti dalla piattaforma (librerie binarie chiamate in JNI). Lo stesso si può dire di SWT/JFace.
Swing non sarà perfettissima ma è molto uniforme tra le piattaforme ed è già installata di default con Java. Per come sono abituato, pensavo di creare la GUI visualmente in Java con NetBeans, per poi agganciarla al nocciolo Scala a mano. Cosa ne pensate?
Riciclo di codice con Jython: non sono proprio convintissimo. Buona parte del codice è dipendente dalle Wx o dalle Curl, in particolare quelli che attualmente si chiamano Sender non sarebbero così facili da riusare. Quel che resterebbe è la configurazione, che comunque ha bisogno di una rimodernata, e l’ossatura centrale del programma, che è replicabile piuttosto facilmente. Se a questo aggiungi i macati vantaggi che Scala offre credo che Jython non sia un’opzione pensabile…
Sulla piattaforma collaborativa partirei da git, visto che anche se in forma grezza il forum può andar bene, inizialmente, per tener traccia dei difetti. Giuseppe: hai un attimo libero per creare un account e spiegarmi come fare? Tutti: qualcuno sa se esiste un client Eclipse?
Riscrivere tutto in c++ con qt4 non è meglio?
Java sarà anche multi-piattaforma ma è un mattone…qualsiasi programma scritto in Java, grazie anche al jit, consuma non poca ram…
PS: Non è vero che nokia preferisca finanziare qt4 solo per i suoi dispositivi…in quanto una parte della comunità kde viene finanziata proprio da nokia…
nel peggiore delle ipotesi, nel caso nokia smettesse di supportare l’integrazione lato desktop, essendo qt4 open source verrebbe portato avanti sicuramente da qualcuno
Egit? http://www.eclipse.org/egit/
Luca: secondo me C++ non rappresenta una buona strada come linguaggio, per lo meno per questo progetto, in quanto i cicli-cervello costano più dei cicli-macchina! Scala permette una codifica più agevole, in quanto si può lavorare a livello di astrazione più elevato senza curarsi di tanti dettagli che in C++, invece, vanno gestiti (allocazione della memoria in primis, ma non solo quella), quindi credo che ne valga la pena di sacrificare qualcosina in prestazioni in cambio di un programma pronto qualche settimana prima.
Quanto al consumo di RAM non credo ci siano problemi rilevantissimi: se guardi il video della mia tesi di primo livello ti stupirai che tutto quel che si vede (compresi video, musica, applicazioni zoomabili) si fa stando sotto ai 64 MB di memoria occupata. In una prova che avevo fatto riuscivo a zoomare su 4.2 GB di fotografie, ossia svariate migliaia, senza sforare quel tetto… Credo che sia più che altro un problema di usare bene lo strumento. Tra l’altro, essendo Python un linguaggio interpretato, credo che si possa fare meglio rispetto a MoioSMS 2, il che per me sarebbe già ottimo.
Michele: grazie!
Non ho notizie sulla stabilità/affidabilità di Egit, comunque direi che vale la pena provarlo.
Per aprire il progetto su Github va creato un account, perché ciascun progetto appartiene ad un utente, quindi credo sia meglio che lo faccia direttamente tu, no?
OK, adesso provo.
Certamente è il tipo di cambiamento (da utente, benché l’informatica sia il mio campo) che meno mi aspettavo. Spero che i numerosi vantaggi esposti riusciranno a farmi superare i miei pregiudizi nei confronti di java. Certamente il passaggio python->java (scala) mi ha un po’ spiazzato. Probabilmente la piattaforma linux mi impediva di notare le difficoltà (da utente) legate a python. In ogni caso complimenti per il lavoro finora svolto e spero che la nuova avventura rispecchi le vostre aspettative… Io, beh… se non mi saprò adeguare all’ennesima jvm in esecuzione… saprò che le versioni 2.x funzionano già benissimo.
Personalmente comprendo fino a un certo punto l’accanimento contro le piattaforme in stile Java “di per sè”. Dopo tutto l’interprete Python (o Ruby, o Perl) è certamente molto meno performante (vedi la homepage di JRuby). Probabilmente il problema sorge dal fatto che la maggior parte dei programmi Java in giro non sono fatti come dovrebbero, quindi si diffonde l’idea che sia la VM ad essere lenta. Quanto al consumo di memoria ripeto, staremo sicuramente sotto i 64MB, e probabilmente andremo molto al di sotto.
Sono d’accordo con Silvio riguardo i limiti del python per questioni di portabilità tra i vari OS.
Non sono pienamente d’accordo con il linguaggio usato… avrei preferito qualcosa di più standard, del tipo:
* C++ con Qt4 -> l’accoppiata vincente 🙂
* Java standard -> ed interfaccia Swing
Ad ogni modo, cercate di rendere l’applicazione il più indipendente possibile… senza appoggiarsi a tool esterni, come ad esempio “curl”, e così via…
Vi auguro comunque un buon lavoro 🙂
Segnalo anche http://www.scala-ide.org/
Scala è un po’ un rischio, lo so 🙂
Speriamo che il fiuto funzioni meglio rispetto all’ultima volta con Python. Uno degli aspetti positivi è proprio la compatibilità con Java, quindi possiamo fare a meno di tutti i tool esterni (Apache Commons HTTP Client al posto di curl, javax.image al posto di imagemagick, Encog al posto degli OCR).
Proverò Scala IDE al più presto!
Ottimo allora 🙂
Ottimo programma ma… una versione per iphone? penso sarebbe un successone e se vuoi ti posso pure dare una mano 🙂
scusate mace una data o qualche indicazione per luscita di moiosms3?
io attendo, soprattutto per rossoalice che non esiste piu
sostituito da yalp. gli account di yalp nn funzionano con moiosms
se uso rossoalice. spero che cia sia yalp nella lista.
ciao
Purtroppo non sono in grado di dare indicazioni sui tempi, ricorda che è un progetto fatto nel tempo libero!
Se vuoi che il sito sia supportato, inizia col segnalarlo nell’apposita discussione (“Nuovi siti”) del forum, grazie.
Dai un’occhiata al forum, questo aspetto è già stato discusso più volte!