Niente a che vedere con la licantropia ma, piuttosto, con i sani effetti della concorrenza (da parte di Silverlight e del suo gemello Moonlight) che si fanno sentire anche in casa Adobe:
Contrariamente a quanto auspicato nel post dedicato al Pycon Uno, mi sa' che quest' anno saro' costretto a saltare l' appuntamento, previsto per questo fine settimana, con il Pycon Due.
Ho aspettato fino all' ultimo prima di prendere una decisione al riguardo, ma sono troppo indietro col lavoro da potermi permettere 3 giorni di "pausa":
sara' per il prossimo anno... e speriamo che anche questa volta siano resi disponibili i video degli interventi.
Adesso apprendiamo da TabletBlog che c'e' stata la conferma ufficiale da parte di Nokia:
Il dispositovo in questione e' l' N810 WiMAX Edition (WME)
Si tratta della seconda revisione del "Internet Tablet" della serie N800 (derivata a sua volta dalla N700) e basata sull' ottima piattaforma Maemo Linux (riguardo alla quale non mi dilungo piu' di tanto in quanto ho intenzione di scriverci uno o piu' post dedicati).
All' evento, ovvero la realizzazione del primo dispositivo WiMAX, Nokia ha dedicato un Podcast con Ari Virtaten che contiene alcuni interessanti dettagli e che riassumo schematicamente di seguito:
Nokia believe in a so called "Open Internet Model": people can connect to Internet using what device/connection/services they want to use and WiMAX seems enable this model extremely well;
Same device with same hardware/capability as N810 plus WiMAX capability added: working at freq. 2.5 GHz with an expected data rate of 2 to 4 MBit/s;
Benefits of WiMAX capabilities: people can use the device in more places (in a range of 2 to 3 miles from the antenna);
Software improvements: email application, WiMAX over the air activation (integrated in connection manager);
Initial Availability: in US Only (where WiMAX is available) in summer of 2008 should be NOT an exclusive of XHOM (Sprint Nextel);
Price: expected to be similar to the existing N810.
Stanchi dei soliti navigatori satellitari?
bhe', allora non vi preoccupate, perche' una nuova generazione di navigatori satellitari potrebbe presto venire alla ribalta..
e non sto parlando dell' ennesimo dispositivo GPS, che e' sempre meno distinguibile da palmare o da uno smartphone e che non aggiunge niente alle ormai consolidate funzionalita' standard dei sistemi di navigazione GPS:
sto parlando di un dispositivo pensato per soddisfare le necessita' di chi si trova ad affrontare un viaggio e che, oltre all' indicazione della rotta da dovere seguire, vuole anche essere informato su tutte le opportunita' che si possono venire a trovare durante il percorso.
Ma, soprattutto, sfrutta in maniera ottimale tutte le opportunita' offerte da una piattaforma hardware che integra il sistema GPS con la connetivita' offerta dal Wifi e dal modem GPRS; ed i risultati sono mostrati nei seguenti video:
Purtroppo, come spiegato nelle FAQ, il prodotto e' per il momento commercializzato solamente sul mercato statunitense:
anche se, essendo basato in larga parte su hardware per il quale e' gia' esistente sia del software funzionante che la opportuna documentazione, non si puo' esculdere una futura versione community based che ne estenda le funzionalita' rendendone possibile l'utilizzo anche nel resto del paesi.
un object database, che intendo utilizzare in alcuni progetti ai quali sto lavorando.
I requisiti che stanno alla base del design di EmbedDB sono:
compatibilita' con un utilizzo in ambienti embedded come smartphone, palmari e tabletPC;
interfaccia di I/O in XML;
facilita' di estensione e di personalizzazione;
supporto per diversi backend;
supporto multipiattaforma (almeno per WinCE/PocketPC e Linux).
Attualmente ne esiste una versione funzionante scritta in Python che utilizza SQLite come backend.
Questa versione di EmbedDB viene attualmente utilizzata da Enumera (un software per la catalogazione di beni mobili) ed e' abbastanza performante da potere essere tranquillamante utilizzata da un palmare.
Prevedo di realizzare delle altre versioni di EmbedDB da potere utilizzare anche in altri progetti ed, in particolare, nella nuova release di Axil, nella quale dovrebbe andare a svolgere il ruolo attualmente ricoperto da Axiom.
Nella attuale fase di sviluppo mi sto occupando del miglioramento del supporto di SQLite nella versione esistente di EmbedDB:
il punto sul quale sto concentrando gli sforzi e' l' eliminazione dell' utilizzo di pysqlite o APSW per l' interfacciamento tra Python ed SQLite.
E' infatti necessario utilizzare un interfaccia che consenta di aggirare le limitazioni, dovute all' utilizzo di tali librerie, nell' interazione con il database, in quanto non permettono di avere accesso a le funzionalita' piu' a basso livello del backend.
A tale scopo sto cercando di definire una interfaccia Python ad SQLite, basata sulle librerie (oramai incluse di default nella versione 2.5 del linguaggio) ctypes, che consenta di avere un accesso a tutte le funzionalita' messe a disposizione dal database senza rinunciare ad un layer software che permetta di astrarre da tutti quei dettagli che l'originale interfaccia C espone.
EmbedDB e' un progetto a lungo termine i cui sviluppi futuri di prevedono:
una riscrittura (totale o parziale) in C del codice Python;
l' aggiunta di un supporto ad altri backend come, ad esempio, QDBM o Tokyo Cabinet.
L' unica applicazione Java di cui faccio un' utilizzo regolare (escludendo, ovviamente, gli eventuali utilizzi lato server di cui non sono consapevole) e' Eclipse; e per un semplice motivo:
trovo che sia l' unico modo per avere un ambiente di sviluppo multi-piattaforma e multi-linguaggio che sia facile e funzionale.
Infatti credo che sia l' unico IDE che:
consente di avere lo stesso identico ambiente di lavoro tra diverse macchine e sistemi operativi;
fornisce una sterminata serie di plugin che consentono di estenderne notevolmente le funzionalita' e che , una volta che si impara ad usarli correttamente, risultano essere molto utili e ben fatti; tra questi ci sono sicuramente Pydev e Subclipse.
Bisogna, purtroppo, ammettere che Eclipse ha sempre avuto dei problemi di integrazione con Linux:
inizialmente per via della mancanza di una virtual machine abbastanza "performante";
poi perche' alcuni plugin non funzionano correttamente su alcune delle piattaforme hardware su cui si puo' trovare Linux (per es. Subclipse su Amd64 o PowerPC);
infine per via di alcuni bugs presenti in GCJ, ovvero il software, utilizzato di default su alcune distibuzioni Linux, per eseguire Eclipse.
Quest' ultimo e' il caso di che si presenta quando si cerca di usare Eclipse su Ubuntu 7.04 Festy: tutto sembra funzionare correttamente per i primi 5 - 10 minuti di utilizzo finche', improvvisamente, l'applicazione si pianta, cominciando ad utilizzare in maniera eccessiva il processore, per cui se ne rende necessaria la terminazione forzata.
Per risolvere questo problema bisogna cambiare l' ambiente nel quale viene, di default, eseguita di l' applicazione; per fare cio' e sufficiente realizzare i seguenti passi:
installare installare un JRE affidabile come, ad esempio, quello contenuto nel package sun-java6-jre;
selezionare tale JRE come quello di default, tramite il comando (da root/sudo):
update-java-alternatives java6-sun;
impostare nel file ~/.eclipse/eclipserc la variabile JAVA_HOME in modo da rispecchiare il cambiamento effettuato; nel esempio in questione, si dovra' aggiungere a tale file la righa :
Questo fine settimana sono stato al Pycon Uno, ovvero la prima conferenza italiana dedicata a Python, che si e' tenuta a Firenze:
e' stata sicuramente un' esperienza entusiasmante che non vedo l'ora di ripetere.
E' stato, infatti, molto stimolante condividere insieme ad una vasta platea (circa duecento partecipanti) di appassionati il susseguirsi degli interventi in programma tutti molto interessanti:
durante i due giorni in cui si e' articolata la conferenza, mi e' capitato abbastanza di frequente di trovarmi a dovere decidere quale, tra i due interventi che si tenevano in contemporanea, avrei dovuto seguire.
Ognuno dei talk ai quali ho assistito meriterebbe un post a parte; per cui, per il momento, mi limito a citarne brevemente alcuni:
il keynote di Alex Martelli sugli approcci che e' possibile utilizzare nell' affrontare le problematiche che si presentano durante la gestione dello sviluppo di grossi progetti software. I concetti esposti sono, grossomodo, quelli contenuti in questo post; il tutto condito con interessanti particolari che derivano dalla sua decennale esperienza ed in particolare da quella, piu' recente, di "Uber Technical Leader" in Google.
il talk sull' utilizzo di Python nella gestione dei test degli strumenti di misura di uno dei futuri rilevatori di sorgenti di Raggi-Gamma che verra' utilizzato in futuro dalla NASA;
il talk sul progetto PyPy, tanto interessante dal punto teorico, quanto pieno di potenziali ricadute pratiche immediate, che mira a sviluppare un ambiente che consente la facile realizzazione di interpreti ottimizzati per l' esecuzione di dialetti del linguaggio Python;
il keynote sull' utilizzo di Python come linguaggio di programmazione principale nella realizzazione del software del famigerato OLPC;
il talk sul Python 3000, che ha mostrato una panoramica su tutte le novita' che ci attendono nella nuova release del linguaggio;
e tutti quegli altri talk, come quello sulle estensioni alla DB-API 2, quello su SQLAlchemy o quello su Genropy, che sono stati interessanti per avermi fatto conoscere nuove modalita' di applicazione di Python nella risoluzione di vari problemi.
Per cui mi sento in dovere di ringraziare gli organizzatori della conferenza, ovvero l' associazione Python Italia, ai quali va riconosciuto il merito di avere saputo organizzare l' evento in maniera ottimale.
In questo periodo mi sto occupando di sviluppo di applicazioni sul palmari e, per l' esattezza, mi sto occupando di sviluppo su palmari in ambiente Linux/GPE (G Palmtop Environment).
Sfortunatamente sembrerebbe che io abbia scelto il periodo sbagliato per lavorare con GPE:
infatti per potere sviluppare in maniera ideale, ovvero serenamente e senza inutili complicazioni, con una data tecnologia si dovrebbe avere a disposizione una ambiente di riferimento il piu' possibile stabile ed aggiornato; e si dovrebbe, magari, poter contare anche sul supporto di una comunita' di sviluppatori affiatati e collaborativi.
Di solito tutte queste caratteristiche sono presenti in ogni progetto open-source di successo, ma, purtroppo, non si puo' certo dire che questa sia la situazione in cui si trova il progetto GPE in questo periodo.
Infatti, e' attualmente in corso una specie di faida (con risvolti che sfiorano il grottesco) tra due distinte comunita' GPE:
quella su LinuxToGo.org che e' invece il nuovo punto di riferimento della comunita' GPE.
Tutti gli sviluppatori GPE sono migrati sul sito LinuxToGo.org che supporta, sostanzialmente, anche la comunita' di sviluppatori legati alla distribuzione Angstrom e di OpenEmbedded (ovvero il toolchain per la cross-compilation su cui sono basate molte delle versioni embedded di Linux tra cui entrambe le distrubuzioni Familiar e Angstrom).
Handelds.org, cercando di opporsi a tale "migrazione", evidentemente non gradita, sta conducendo una battaglia tutta improntata alla difesa formale del "marchio GPE" senza, tuttavia, essere in grado di garantire un qualche tipo di futuro, in termini di capacita' di sviluppo e di supporto del software oggi esistente, al "progetto GPE".
La situazione, purtroppo, sembrerebbe essere oramai completamente degenerata:
ed e' sinceramente un tipo di spettacolo al quale non avrei mai pensato di dovere assistere all' interno di un' ambiente, solitamente molto piu' collaborativo, come quello delle comunita' di sviluppo open source.
Chi fosse interessato ad avere ulteriori dettagli sulla spiacevole faccenda puo' dare un' occhiata a questo articolo su Linux.com oppure ai post dei blog (sia quello del sito del progetto GPE, che quelli di alcuni degli sviluppatori) che trattano dell' argomento:
