Com\’è dura la professione!

30 agosto 2006

Fissata la data del Linux Day 2006

Filed under: Linux,Open Source — lbell @ 21:05

Come per magia, contemporaneamente all’apparizione dei prezzi di Vista su Amazon, e’ spuntata anche la data in cui si terrà il prossimo Linux Day: il 28 ottobre 2006. Il sito riguardante l’evento è http://linuxday.linux.it. Evidentemente ci si è resi conto che alla fine di novembre (data delle ultime edizioni) può anche nevicare, specialmente al nord. Nuovo anche il logo realizzato da Emanuele Miliani.

logo Linux Day

29 agosto 2006

One Laptop per Child, il computer da 100 (o poco più) dollari

Filed under: Linux,Open Source — lbell @ 20:05

Per il progetto “One PC per Child” siamo alla stretta finale, la produzione dovrebbe partire a Novembre. Si tratta di un portatile economico per i bambini del terzo mondo, ma se guardo le specifiche mi sembra una macchina innovativa. Basso costo, basso consumo (alta autonomia presumo), un display LCD (piccolo 8”) riprogettato da zero per essere leggibile anche in pieno sole, una flash al posto dell’hard disk, leggero, Linux come SO, perfetto per essere usato nei viaggi di lavoro in treno soprattutto se non si usano programmi particolarmente affamati di cpu e memoria o per leggersi libri e documentazione in PDF. Come BIOS ci sarà LinuxBIOS che promette, grazie ad un progetto Open Source, di far partire il computer in tempi paragonabili al videoregistratore di casa.

OLPC, così si chiama per ora il progetto, dimostra la bontà delle soluzioni Open Source e la loro applicabilità al mondo reale quando esiste la volontà di portare a termine un progetto serio. Di veramente innovativo la riprogettazione del BIOS e del display: un settimo del consumo ed un terzo del prezzo dei display tradizionali. Segnalo questa intervista di Mary Lou Jepsen sulle considerazioni sulle scelte effettuate nella progettazione del display.

Il progetto in sé, dalle finalità nobili ed umanitarie, e’ piuttosto controverso, un po’ perché le scelte fatte sono invise ad alcuni giganti dell’industria, un po’ per le perplessità dei beneficiari. Se da un lato Brasile, Argentina, Nigeria e Thailandia stanno trattando, altre nazioni come l’India hanno preferito non appoggiare il progetto. Se si tratterà di una soluzione veramente utile lo scopriremo fra qualche anno, ma intanto di notevole c’è la volontà di aiutare delle persone con questo progetto ed il fatto che le soluzioni Open Source siano state scelte non solo per l’etica, ma anche per l’efficienza.

23 agosto 2006

Deframmentare

Filed under: Linux — lbell @ 21:03

Mi sono sempre chiesto perché per Windows fioriscono i programmi di deframmentazione mentre in Linux sono praticamente assenti. Avevo trovato un bel post (questo) da cui mi sembrava di avere avuto indicazioni chiare, ma leggendo i commenti i dubbi mi sono ritornati. I filesystem NTFS e quelli classici Linux sono stati ovviamente studiati per per un utilizzo in multiutenza, ma sono impiegati in una varietà di ambienti, dal file server al web server, al database server al desktop monoutente. Posso immaginare che NTFS sia stato adeguatamente progettato, dimensionato e testato, e allora dove sta la differenza? Perché in Windows si nota un drastico incremento di prestazioni di un NTFS deframmentato, mentre sotto Linux non ci è data la possibilità di provare questa gioia? Forse dipende dal fatto che più che dai meandri del kernel la differenza dipende dall’utilizzo dei programmi. Un sistema desktop Windows lo si nota perché lo si ha sempre sotto gli occhi. Forse dipende dalla cache dei dispositivi di memorizzazione che viene alimentata dalla memoria lasciata libera dai programmi. I filesystem sono bestie complesse, gestiscono il journaling, possono cambiare strategia di allocazione a seconda della dimensione e del tipo dei file, gestiscono una cache logica per file ed una fisica, per settori. Fare dei test semplici non dà affatto l’idea di cosa succede in un server dopo un anno di lavoro ininterrotto, né di come un RDBMS che decide di allocare un grosso blocco di dati per poterlo gestire in proprio possa funzionare, senza tenere conto di tutte le soluzioni hardware possibili. Come fattori da tenere presente ci sono anche la cache sul controller dei dischi, l’uso di gestori di volumi logici che disperdono i dati su più dischi fisici, e l’uso di diversi filesystem su differenti partizioni.

8 agosto 2006

Ruby on Rails in MacOS X 10.5 Leopard

Filed under: Mac,Open Source,RubyOnRails — lbell @ 11:57

Tanto per non perdere l’abitudine a stare un passo avanti agli altri, Apple ha annunciato che la prossima versione di MacOSX (server e client) sarà equipaggiata con Rails. D’altronde, come si trova scritto anche nel blog degli sviluppatori di Rails, tutti i core developer utilizzano Mac e si aspettano che la piattaforma Apple diventi una delle principali piattaforme di sviluppo per gli applicativi Rails, per cui sembra proprio un amore corrisposto. Per inciso, per non scontentare nessuno, Mac OS 10.5 avrà in dotazione anche software per suppportare J2EE (Jboss e Tomcat).

7 agosto 2006

Un commento di troppo

Filed under: Programmazione — lbell @ 20:59

Java e C# riuniscono dichiarazioni ed implementazione per semplificare la gestione dei programmi. Si può semplificare anche la gestione della documentazione inserendola direttamente nel sorgente ed estraendola con appositi strumenti (Javadoc, Ndoc). I metodi degli oggetti possono essere preceduti da un commento codificato che ne descrive la funzione ed i parametri attraverso una particolare notazione. Scrivere i commenti così lontano dagli oggetti cui sono riferiti ci riporta però alla situazione che abbiamo voluto evitare per il codice, cioè occorre uno sforzo in più per tenere allineati documentazione e codice.

Quando le scadenze di consegna dei programmi incombono ed il codice si deve modificare velocemente, i commenti scritti in cima alle funzioni tendono a non essere più così visibili e fatalmente li si trascura. Un volta che il programma ( o la correzione ) è stato messo in produzione, i sorgenti non si modificano, nemmeno per completare i commenti.

Proviamo ora a compilare una classe di esempio in C# in cui abbiamo tralasciato qualche dichiarazione. Il compilatore si lamenta un po’, ma senza seccarci troppo.

 
         ///<summary>
         /// questo e' il sommario
         /// <c> codice</c>
         /// <param name="uno\">prova uno</param>
         /// <param name="due\">prova due</param>
         /// <RETURNS>spiegazione del valore di ritorno</RETURNS>
         ///</summary>         public int somma2( int quattro )
         {
                 return quattro+2;
         }

Non si potrebbe invece utilizzare una notazione che pretenda che il commento sia effettivamente legato al parametro stesso, come mostrato nel metodo scritto qui sotto (con una notazione di fantasia)?

 
        public int  somma	/*= esegue questo e quello */
        (         int uno	/*= serve a fare questo */,
                 int due	/*= serve a fare quello */ )
        {
                 return uno+due;
 	}

E’ ora più difficile che codice e commenti siamo disallineati.

Il corpo della documentazione inserito nei commenti può contenere link ad altre parti di programma, parti in grassetto e così via, il tutto utilizzando una sintassi HTML like. Non sarebbe male, tanto per praticità, che fosse l’IDE ad occuparsi di questi dettagli, formattando questa parte di codice come se fosse un piccolo word processor; certo l’IDE non sarebbe più un semplice editor di testi, ma è da tempo che in realtà non lo è più. Nulla impedisce che utilizzando invece un editor come vim, il codice in HTML like ricompaia.

3 agosto 2006

L’architetto e i pattern

Filed under: Programmazione — lbell @ 20:52

Leggo che Alexander, l’architetto (e tante altre cose) che ha lanciato i pattern, oggi tanto comuni nel mondo della programmazione, nel mondo dell’edilizia, sia stato poco stimato dagli architetti suoi contemporanei, per la scarsa originalità delle sue soluzioni. Nel modo della programmazione invece i pattern sono visti come una risorsa preziosissima, per la robustezza che forniscono alle soluzioni. Che sia più difficile produrre un programma funzionante che progettare un edificio?

J2EE, l’elefante

Filed under: Java,Programmazione — lbell @ 20:27

E’ da un po’ di tempo che J2EE viene citato come la pecora nera della programmazione web. Non stupisce che chi usa un framework come rails lo ritenga pesante, dalla configurazione farraginosa e complicata, che chi utilizza .net come piattaforma di riferimento ne veda soprattutto i difetti, che non vada giù a chi usa linguaggi di script come Perl, Php e Python, tanto che qualcuno lo chiama in causa scrivendo storielle. Il colmo è però arrivato con un post di de Icaza, il fondatore di Mono, sul suo blog, in cui si paragona il peggio di Avalon a J2EE.

2 agosto 2006

Rails o non rails?

Filed under: Programmazione,RubyOnRails — lbell @ 11:40

Dopo avere esaminato Rails, per fugare i dubbi se sia il solito fuoco di paglia che periodicamente brucia in rete o un reale strumento di lavoro, ho deciso di metterlo alla prova nel solito progetto inutile (GPL) di prammatica in questi casi, nella fattispecie un programma per gestire l’inventario di computer e servizi. Inutile dato che ogni ditta gestisce già un registro di tali beni, anche se magari poche lo hanno realizzato con Rails. Per ora sono alle prese con la sintassi del linguaggio (Smalltalk?) e delle magie convenzioni del framework.

Rails serve per progetti complessi? Lo si può imporre ad un gruppo di lavoro? Rails è basato su magie convenzioni. Portare una serie di sviluppatori ad essere esperti di magia non è banale, soprattutto quando non esiste nemmeno un libro in italiano su Ruby, mentre di Visual Basic, ASP.net e C# sono pieni gli scaffali delle librerie (lo so, sto mischiando il linguaggio con il framework, ma il confronto lo si fa a 360 gradi). Manca inoltre un designer visuale, e questo bene o male è dove tutti gli ambienti Open Source si scontrano con il mondo Microsoft.

Comunque i progetti inutili servono per chiarirsi le idee anche su questi argomenti.

Blog su WordPress.com.