… come voleva far sembrare.

In questi giorni sono pieno di lavoro fin sopra la testa, quindi perdonatemi se posto poco, ma oggi sono venuto a conoscenza di una cosa che mi ha fatto perdere parecchia della stima che avevo in Google.

Sembra che Google stia distribuendo le nuove versioni dell’SDK per Android solo ai programmatori che hanno superato la prima fase del concorso per lo sviluppo di applicazioni, quello che aveva suscitato le ire degli italiani e anche un’interrogazione in parlamento, a causa delle nostre leggi sui concorsi.

Tutti gli altri sviluppatori stavano aspettando le patch da oltre 4 mesi, e avevano segnalato diversi bug, anche gravi, nell’SDK stesso, ed ora un dipendente di Google, per sbaglio, ha inviato alla mailing list degli sviluppatori, invece che a quella dei vincitori del concorso, un messaggio in cui li informa che la nuova versione dell’SDK è disponibile della loro area privata di download.

Si è scoperto poi che quegli sviluppatori hanno firmato un NDA (Non Disclosure Agreement) che vieta loro di rilasciare informazioni sull’SDK.

Ora molti sviluppatori sono delusi dal comportamento di Google, e io sono d’accordo con loro. Che senso ha rilasciare l’SDK solo ad alcuni e non a tutti? Potrebbe essere comprensibile dare un canale preferenziale per le informazioni o per il debug all’SDK a questa elite, ma lasciare indietro tutti gli altri significa semplicemente che non c’è alcun interesse nello sviluppo open source, ma solo nello sfruttamento della comunità per la scoperta di bug, senza dare loro nulla in cambio.

Cercando informazioni ho poi scoperto che Google non ha nemmeno mai rilasciato i sorgenti di Android, e che si riserva di farlo solo dopo che sarà uscito il telefono vero e proprio, e che David “Lefty” Schlesinger, che se ne è lamentato nella mailing list, è stato moderato per averlo chiesto.

Non mi meraviglia che molti stiano abbandonando Android per sviluppare per l’iPhone, anche se avrei preferito si fossero rivolti a OpenMoko, che ne ha più bisogno. Ma solo sicuro che qualcuno tra loro lo farà.

Pessima figura, Google.

Prima milestone per i miei due programmini.

Oggi, con un po’ di tempo a disposizione, mi sono messo a lavorare su Esse ed Essedue, e ho implementato alcune modifiche che mi hanno convinto a portare la versione alla fatidica 1.0:

• In fase di chiusura viene controllato che non ci siano file aperti e modificati ma non salvati, e viene chiesta conferma
• Si possono aprire file direttamente dalla linea di comando. Se non esistono o sono illeggibili viene aperto un requester di errore
• Ho aggiunto un file .desktop, in modo da farli apparire nei menu di Gnome, KDE e dei WM e DM che seguono le direttive freedesktop.org
• Entrambi sono stati debianizzati. I file per creare il pacchetto deb sono inclusi assieme ai sorgenti.

Ora anche chi non era interessato a Vala o alla programmazione in genere, potrà scaricarsi il pacchetto deb della versione che preferisce, presente nella pagina di progetto di Esse, ed utilizzarlo. Non ho testato, ma in teoria il pacchetto dovrebbe essere compatibile anche con Ubuntu 8.04.

Se non vi piace, aptitude remove è vostro amico.

Se trovate dei bug non esitate a segnalarmeli. (continua…)

Esse, ancora più scarno

Segnalo a chi fosse interessato, nella pagina dedicata ad Esse, il mio micro-editor scritto in Vala, la disponibilità di Essedue.

Si tratta dello stesso micro-editor, con le stesse caratteristiche minimali, a cui è stata completamente rimossa la dipendenza da Glade. Ora la GUI viene costruita interamente da codice, e per i menu e la toolbar ho utilizzato UIManager.

Il pacchetto è più piccolo, in quanto XML non è proprio un formato “risparmioso”, mentre l’eseguibile è cresciuto leggermente, da 36 a 40 KB. In compenso, in memoria, esse occupa 13.3 MB (di cui 8.1 condivisi, quindi 5.2) ed essedue 12.6 (di cui 7.6 condivisi, quindi 5.0). In pratica tutto il risparmio, come previsto, è dato dalla libglade (500 KB) e dal DOM XML per la stessa (circa 200 KB). Il risparmio non è enorme, soprattutto in un sistema che usa già glade per altri software, ma in un sistema embedded come un palmare anche solo quei 200 KB potrebbero essere utili per qualcos’altro.

Per fare un confronto molto spannometrico, geany occupa 19.2 MB (di cui 9.5 condivisi, quindi 9.8) e gedit  28.5 (di cui 15 condivisi, quindi 13.5).

Ora non mi resta che capire dove vadano a finire quei 5 MB, viste le dimensioni dell’eseguibile, ma presumo in strutture di sistema, aree allocate dalle librerie, bitmap dei widget, ecc. Mi piacerebbe capire se si possono ridurre.

La mia prima applicazione in Vala. Che emozione!

Come promesso, ho trovato il tempo di ripulire un po’ il codice del mio primo programmino in Vala, e per l’occasione ho creato una sezione apposita del sito dedicata a Vala, con una sottosezione dedicata a questo programmino, che ho chiamato Esse (spero non ci siano altri software con lo stesso nome…).

Il codice non è molto denso di commenti, anche perché, secondo me, è talmente chiaro e lineare che avrei finito col riscrivere in italiano quello che già si capisce leggendolo. L’unica cosa che forse confonde un po’ le acque sono i continui cast tra un oggetto e l’altro. Spero che nelle future versioni di Vala il tutto venga un po’ automatizzato e reso più trasparente.

Che altro aggiungere? Scaricatelo, guardate il sorgente, provatelo e fatemi sapere le vostre impressioni. La licenza è GPL2.

Vi ricordo che avrete bisogno del compilatore Vala (e del GCC) per compilarlo. In Debian Lenny (testing) è già presente da diversi mesi, quindi basta un

aptitude install valac

Happy hacking.

Una prima veloce analisi dei due nuovi linguaggi.

Come mi ero ripromesso, in questi 5 mesi ho dato un’occhiata a questi due nuovi linguaggi che sono apparsi sulla scena, e mi sono fatto un’idea sommaria delle loro capacità.

Vediamone velocemente le caratteristiche, i pro e i contro. (continua…)

Bisogna adeguarsi al mondo che cambia…

Qualche giorno fa Donald Knuth, uno dei mostri sacri della programmazione, autore di vari libri della serie Art of Computer Programming, ha rilasciato un’intervista a InformIT in cui, tra le altre cose, esprime un parere estremamente negativo sulla attuale tendenza dei produttori hardware verso le architetture multi-core.

Il suo pensiero si può riassumere più o meno con: i produttori hardware non sanno più come migliorare le prestazioni dei loro chip, quindi hanno riciclato l’idea del multiprocessing, mantenendo le prestazioni fisse (o inferiori) su un singolo core, e mettendo diversi core per poter dire che la CPU è più veloce. In questo modo fanno ricadere la “colpa” nel mancato rispetto della legge di Moore (il raddoppio della potenza di elaborazione ogni 18 mesi) sui programmatori, dicendo che non sono in grado di scrivere software adatto alle nuove architetture.

Io, come diceva un saggio, sono “completamente d’accordo a metà col mister”. (continua…)

Nuova versione del framework “ufficiale” per PHP, con numerose novità interessanti.

Assieme a un restyling del sito, che trovo molto meglio del precedente (almeno ora è fluido in verticale), anche se ha ancora qualche link rotto, è stata annunciata oggi la nuova versione di Zend Framework, la 1.5.

Le principali novità di questa versione sono Zend_Layout, che permette di avere un layout comune a tutte le pagine invece di doverlo ripetere per ogni View o di dover usare accrocchi per includere i pezzi in ogni View, e Zend_Form, che permette di creare dei form da passare alla View e di inglobare negli stessi le informazioni per la validazione dei campi oltre a permetterne la validazione al volo anche tramite AJAX (informando il browser tramite JSON sugli eventuali errori).

Ci sono moltissime altre novità, naturalmente, oltre a diversi bugfix.

Più veloce della luce Akrabat, che in contemporanea ha rilasciato la sua nuova versione (anche questa 1.5) del tutorial per Zend Framework, includendo già le informazioni su Zend_Layout e Zend_Form.

Trovo molto intelligente la sua scelta di categorizzare i vari form come Model, ma devo ancora vedere la documentazione ufficiale, se già lo prevedeva.

In realtà ad una prima occhiata avevo classificato Zend_Form come una feature utile al massimo per chi scrive CMS, perché rimuove dalla View le informazioni sul form, rendendo la vita difficile ai grafici/HTMListi quando si lavora in un ambiente misto, ma ora sto meditando se ricredermi. Forse lo proverò direttamente sul campo per vedere le reazioni.

Ho già installato il nuovo framework in parallelo al precedente 1.0 (che mantengo per non rischiare la compatibilità di alcune applicazioni già scritte) e nei prossimi giorni lo proverò sicuramente.

Qualcosa si (s)muove.

Durante una conferenza a Las Vegas, Miguel de Icaza, sul palco assieme a rappresentanti della Microsoft, incalzato da alcune domande di Mike Shcroepfer (di Mozilla) ha prima cercato di spiegare come l’accordo con Microsoft protegga solo chi scarica Moonlight dal sito Novell e non da altri siti, e infine ha ammesso che, se fosse stato per lui, l’accordo con Microsoft non si sarebbe dovuto fare, ma non era in posizione di decidere.

De Icaza, cofondatore del progetto GNOME e della (ormai estinta) Ximian, ora è vice presidente di Novell.

Moonlight, per chi ancora non lo sapesse, è l’implementazione “open source” (tra virgolette perché appesantita dai brevetti Microsoft) di Silverlight, la risposta di MS, appunto, a Flash/Flex/AIR di Adobe. Per come la vedo io, sono entrambe tecnologie chiuse, anche se apparentemente open, quindi da evitare finché possibile.

Di recente Nokia (probabilmente stressata da MS) ha annunciato che avrebbe reso disponibile Silverlight sui suoi cellulari intelligenti (le serie S40 e S60).

Novell aveva già ricevuto pesanti critiche dalla comunità per il suo accordo con “il nemico”, soprattutto dal sito BoycottNovell, che non ha mancato di criticare anche Moonlight. Forse De Icaza si sta accorgendo che nel mondo Linux perdere il supporto della comunità può essere molto rischioso.

Secondo me, semplicemente, Linux non ha bisogno di Mono. Nessuna applicazione (che io sappia) scritta per .Net funziona su Linux, nemmeno le più semplici. E tutte quelle scritte per Linux sfruttano Gtk o meccanismi di Linux, per cui non funzionano con Windows, quindi il motivo principale dell’esistenza di Mono viene a cadere. Ritengo che ci siano già molti strumenti per sviluppare rapidamente su Linux (dall’immensità di librerie disponibili per C e C++ a Python, passando per Gambas, Ruby, e anche Java. E perfino PHP, volendo, anche fuori dal web), e che sarebbe meglio spendere energie per sviluppare progetti più significativi, come Vala e GDC, che hanno una cronica mancanza di sviluppatori, ma nonostante ciò stanno crescendo.

Disponibili le nuove versioni del framework ufficiale Zend per PHP.

Sono state annunciate ieri le due nuove versioni dello Zend Framework.

La 1.0.4 è una maintenance release, che corregge un centinaio di bug. Sarò stato fortunato, o magari non uso ancora molte delle funzioni del framework, ma non mi è ancora mai capitato di incappare in un errore da quando ZF è alla versione 1.0.x. Ne ho trovati un paio mentre era in beta, corretti rapidamente.

La 1.5RC è la prima release candidate della nuova versione, che dovrebbe uscire in versione definitiva entro 1 mesetto. Qui le novità rispetto alla 1.0.x sono moltissime. La più importante, forse, è il nuovo modulo Zend_Layout che dovrebbe risolvere molti problemi dell’attuale modello di View in caso di siti con layout molto simile in molte pagine: la maggior parte, insomma. Altre innovazioni sono lo Zend_Form (che personalmente non mi piace molto perché sembra mischi la logica di Controller e View, ma dovrò approfondire) che supporta form potenziati da AJAX, nuovi helpers per Action e View per un migliore supporto AJAX, nuovi componenti per Advanced View, nuovi componenti per l’autenticazione tramite Information Card e OpenID, e miglioramenti importanti a Lucene (un “motore di ricerca” integrato nel framework, per indicizzare documenti di vari tipi), per la generazione di PDF (ora con supporto UTF-8) e ai web services (Technorati e Slide Share).

Entrambe richiedono almeno PHP 5.1.4 per funzionare, ma io consiglio di passare direttamente a PHP 5.2.

Spero solo di trovare un po’ di tempo per smanettare con la 1.5. Alcuni dei nuovi moduli sembrano molto interessanti.

Devo però muovere una critica agli sviluppatori: nella documentazione non si capisce da quale versione un certo modulo o una certa funzione sono state implementate, col risultato che ci si trova magari a cercare di usare con la 1.0.4 una funzione o una classe che esistono solo nella 1.5 e non si capisce dove sia l’errore finché non si va a vedere il sorgente del framework. Appena mi verrà attivato l’account nel bug tracker credo che aprirò una segnalazione a proposito.

Oggi stavo cercando di abilitare APC in locale (prima di metterlo sul server) per due motivi: migliorare le prestazioni di PHP e abilitare la possibilità di monitorare gli upload via AJAX.

Purtroppo ho scoperto sulla mia pelle che APC non serve a niente se si usa PHP via CGI, perché tiene tutte le pagine precompilate in shared memory, che naturalmente viene liberata alla fine di ogni processo CGI.

Quindi se state usando PHP come CGI, lasciate perdere APC. eAccelerator funziona, perché salva i precompilati su disco oltre che in RAM, ma non supporta (che io sappia) il monitoraggio degli upload.

Dovrò decidermi prima o poi a passare PHP4 in CGI e promuovere PHP5 a modulo di Apache, ma servirà un po’ di tempo per verificare che funzioni tutto senza problemi.