La scorsa settimana si è tenuta a Los Angeles la Professional Developer Conference di Microsoft, conferenza dedicata interamente ai tool di sviluppo per Windows o di tecnologie ad esso riconducibili. Una delle novità è stata la presenza di Miguel de Icaza che ha tenuto una presentazione sullo “Stato della Nazione” di Mono e dei progetti ad esso affini.

La novità è di rilievo se si pensa che Mono è il presunto cavallo di troia all’interno dei nostri PC con GNU/Linux installato sopra, ma anche che Microsoft presenta al suo pubblico di sviluppatori un progetto Open Source che rende libero ed accessibile il codice relativo a .Net e potenzialmente li spinge pensare alle loro applicazioni anche su sistemi non-Windows come Linux e Mac OS X. Tenuto conto che Mono è ormai compatibile al 100% con le WinForms 2.0 e con LinQ e che presenta dei tool che .Net ancora non ha, il keynote di Miguel è stato un fatto che mi ha piacevolmente sorpreso.

Tra le novità presentate in questo keynote citiamo:

• Mono è l’ambiente di riferimento per chi voglia portare applicazioni .Net su piattaforme non Windows
• Mono supporta pienamente i maggiori standard legati a .Net
• Mono è calibrato per essere portato anche su dispotivi embedded (Console come Wii e iPhone ad esempio) e a tale scopo si può sfruttare l’ottimo Mono Linker che consente di estrarre da librerie esistenti solo il minimo indispensabile per quello che ci serve, senza portarci appresso codice inutile
• Mono ora supporta una procedura di SIMD (Single Instruction Multiple Data) che consente di velocizzare di molto i calcoli matriciali e, di fatto, rende Mono adatto anche per lo sviluppo di video games
• per la prima volta si introduce gsharp, una shell per C# che, al pari di quelle esistenti per Python e Ruby, consente di eseguire codice .Net al volo con tanto di output grafico. Ha inoltre la capacità di agganciarsi ad un processo Mono in esecuzione e di variarne il comportamento a Run-Time
• non ci ho capito molto ma mi è sembrato di capire che ora Mono presenta anche un compilatore AOT: non vorrei sbagliare ma, al pari dell’analogo per Java non presenta una migliore efficienza nell’esecuzione del codice
• viene introdotto il Mono Debugger, che fino ad ora mancava all’intera suite.

Le novità sono davvero tante e, per quanto gli “You Know” di Miguel non diventeranno mai famosi come le triplette di un certo Steve o come gli “huuuge” di un altro Steve, vale la pena guardare anche il video (wmv) del keynote per imparare a conoscere un personaggio che già fa, e in futuro lo farà ancora di più, parlare di se.

Al solito non vedo di buon occhio il fatto che Mig indichi Visual Studio come ambiente di sviluppo per Mono e ancor meno capisco la necessità di scrivere MonoDevelop quando si poteva scrivere un plugin per Eclipse/Netbeans. Ma fino a che le buone idee dietro la piattaforma .Net si diffonderanno come Open Source ben venga Miguel e tutto il suo entourage, ma state attenti che la Microsoft è sempre in agguato dietro le sue spalle ed il rischio di avere un Linux che gira alla velocità di Windows Vista è qualcosa da evitare come la peste.

Zac

Diamo il benvenuto ad un altro possibile protagonista della scena Open Source ed ovvero MonoDevelop, l’ambiente di sviluppo targato Novell sviluppato da una comunità di sviluppatori di cui ho spesso ammirato la creatività ed altre volte criticato la loro strana tendenza a difendere le posizioni di Microsoft. Com’è come non è adesso MonoDevelop ha raggiunto il suo primo stadio ed è anch’esso un prodotto open source da cui tutti potremo imparare qualcosa (anche quelli che non vogliono exe nella propria Linux Box).

Il progetto, capitanato da Miguel de Icaza, si è distinto negli anni per aver proposto in ambiente Linux (e in tempi recenti anche Windows e Mac OS X) metodologie e strumenti di sviluppo propri dell’ambiente Windows; quanto questo sia in grado di spostare i pigri sviluppatori .Net a Mono, se non addirittura a Linux, e qualcosa che spero di avere il piacere di osservare.

Inoltre auguro al progetto di diventare a breve uno strumento di sviluppo all’altezza di mostri sacri quali NetBeans, Eclipse o IntelliJ IDEA (scusate ma conosco solo questi). Per ora è un prodotto calibrato su C# con un supporto iniziale ad altri linguaggi come Visual Basic.Net, C++, Java e Boo.

Complimenti a tutta la comunità di Mono. Anche se non siete ben visti da molti pinguini “della curva” è ammirevole l’impegno (interessato?) che ci mettete nelle cose che fate.

In bocca al lupo

Sandro Zacchino

Fino a poco tempo fa pensavo che .Net (in quanto prodotto Microsoft) stava avanzando così tanto da buttare fuori di scena tutti gli altri modelli di sviluppo presenti sulla scena. In realtà per come la Microsoft sta giocando la sua partita .Net avrà senso solo finché Windows manterrà la sua quota di mercato. Ma forse bisogna guardare con più attenzione ai seguenti fatti:

• sui desktop, Windows è ancora la scelta obbligata dato che le aziende che producono software e periferiche offrono quasi sempre soluzioni per Windows
• il web, di contro, è permeato ancora di PHP, JSP di Apache e MySQL, per quanto, a livello enterprise ASP.NET, IIS e SQL Server, per via della loro stretta integrazione e user-friendliness (apparente), non sono certo una realtà minore
• rispetto a qualche anno fa, esistono molte più piattaforme non-windows con cui fare i conti: lato mobile gli attori protagonisti sono Nokia, BlackBerry e iPhone; Microsoft dice che loro hanno un quota di mercato rilevante ma il dato, secondo la mia opinione, riguarda solo gli utenti di tipo aziendale (e tra questi manager e rappresentanti); mi sembra che tra i normali consumatori la piattaforma di riferimento sia Nokia
• Java si è giocata la carta dell’open source e si contende, insieme a Mono, lo scettro di ambiente di sviluppo multipiattaforma per eccellenza: basta vedere la corsa ai nuovi ambienti di sviluppo per iPhone che, nonostante le limitazioni della licenza dell’SDK, è appena iniziata; guardate qui e qui
• Java, dopo un periodo di sonnolenza, sembra aver ripreso la voglia di essere un competitor serio anche per le applicazioni desktop: ultimamente librerie come SwingX, Timing Framework o Jgoodies e ambienti di sviluppo maturi come NetBeans ed Eclipse dimostrano che lo sviluppo con Java non ha nulla da invidiare a .Net o Flash; inoltre il JCP, ovvero la comunità Java che decide come orientare le novità del linguaggio, è attiva più che mai per renderlo un linguaggio al passo coi tempi: sulla scena i linguaggi “minori” come Python, Ruby, Groovy e Javascript dimostrano giorno per giorno le loro indubbie qualità (type inference, definizione dinamica di metodi ed attributi, estensioni delle classi, presenza dei closures) e la capacità di Java di integrarli per ora lo sta salvando dal confronto diretto con il più giovane e performante C#; i grandi nomi dietro a Java dicono che non è possibile mantenere Java un linguaggio così semplice: è vero che le cose che fa C# si possono ottenere lo stesso ma la complessità necessaria per farlo scoraggia i più; Microsoft ha dimostrato che ha conoscenza ed esperienza da vendere nell’ambito dei linguaggi di sviluppo: LINQ, Parallel FX, e altri progetti dell’area Research stanno lì a dimostrarlo; di certo Java non può rimanere a guardare (e per fortuna non lo fa)
• a proposito di Flash, va ribadito che ormai sono molti i progetti open source il cui output è un file Flash; la stessa Adobe inoltre ha da poco rilasciato la suite Air, che consente di portare le applicazioni flash sul desktop
• Internet Explorer, sebbene sia il browser più diffuso, se la deve vedere con Firefox, Safari e all’orizzonte appaiono progetti come questo, molto interessante per le opportunità che presenta
• non ultimo, il sistema operativo: Windows Vista ha avuto il grandissimo merito di dirottare molti utenti verso altri sistemi operativi ed ha convinto molti governi a scegliere alternative open source ai suoi prodotti; da questo punto di vista possiamo certamente dire che Microsoft è stata un grosso sponsor per il movimento del Software Libero; inoltre sulla scena, Apple si fa sempre più presente grazie alla riconosciuta qualità del suo sistema operativo e alla bellezza dei suoi prodotti: riuscendo inoltre ad attingere a piene mani da tutti i progressi del mondo Gnu/Linux e FreeBSD, Mac OS X sembra sempre più la piattaforma di sviluppo ideale per tutti i progetti non .Net (ricordo che da poco è stato rilasciato anche MonoDevelop per Mac OS X)

Insomma, sul palcoscenico ci sono molti attori e, forse, rispetto a qualche anno fa, la conoscenza diffusa delle alternative possibili rende i grossi nomi meno capaci di dirottare le scelte del mercato con semplici strategie di FUD (ossia instillare il dubbio che scegliere prodotti alternativi produca perdite, disastri e cataclismi di varia natura). Il modello di sviluppo open source risulta vincente a tal punto che grosse compagnie decidono di acquistarli in blocco piuttosto che derivarne lo sviluppo.

Vedremo cosa ci riserverà questo incerto futuro.

Qualche dettaglio: per chi non lo sapesse Lobo Browser è un browser web open source scritto interamente in Java. Nell’ultima release integra il rendering di applet JavaFX, ossia il nuovo concorrente di Flash nell’ambito Web.

Zac

Questo è il problema…se sia più nobile d’animo sopportare gli oltraggi, i sassi e i dardi della Microsoft oppure seguire il suo modello di business senza infischiarsene di ciò che si fa ma di quanto rende. In realtà questo mio post è un pò combattuto e nasce come riflessione ad un annuncio di Miguel De Icaza. In quest’annuncio Miguel fa riferimento a quella che è stata la politica di Mono fino a questo momento e cioè quella di dare pieno supporto solo a piattaforme Libere, come (GNU/)Linux e BSD. Non avevo mai riflettuto abbastanza sul fatto di utilizzare software libero su piattaforme proprietarie ma immagino che sia un compromesso accettabile nell’ottica di una transizione da un mondo pervaso da tecnologie e prodotti proprietari ad un mondo in cui la produzione di prodotti liberi (a questo punto perchè limitarsi al solo software) sia riconosciuto da tutti come IL modello di business da adottare.
Miguel invece fa questo distinguo…e mi sembra strano visto che le tecnologie sviluppate dal suo gruppo non fanno altro che favorire la diffusione di prodotti Microsoft all’interno di Sistemi Operativi differenti da Windows.
Inoltre dice che, al solo scopo di incrementare la base di utenti di Mono, prossimamente Mono darà pieno supporto ad OS X (in modo nativo e non sotto X11) e a Windows. Inoltre in questi ambienti sarà portato l’ambiente di sviluppo MonoDevelop.
Fino a qualche tempo fa mi sarei gasato per questa notizia, ora un pò meno. Il motivo è il modo in cui Miguel annuncia il porting di MonoDevelop:

“This should be useful for people that are building Gtk#-centric applications on Windows. For other uses Visual Studio and SharpDevelop will continue to be better IDEs to use.”

Traduzione:

[MonoDevelop per Windows/OS X] dovrebbe essere utile per le persone che creano applicazioni Gtk#-centric su Windows. Per altri usi Visual Studio e SharpDevelop continueranno ad essere IDE migliori da utilizzare.

Migliori? ma da quale punto di vista? Dal lato della produttività? Dal lato del business?…Miguel, usa la forza Miguel…non dare ascolto a colui che dice di essere tuo padre ed invece è un pelatone che “ama la sua compagnia”…

Zac

Forse sono la persona meno adatta a parlare di Mono e .Net visto che non ci ho programmato più di tanto (c’ho SOLO fatto la tesi dottorato ed un DSS). Ma, almeno per ora l’ho utilizzato più di Java quindi…

Bando alle ciance, il titolo del post non è un esclamazione di affermazione sulla potenza di Mono ma un nome furbescamente scelto dal suo autore per riferirsi ad un progetto nuovo di pacca. L’idea, forse ispirata dalle ruby gems, è quella di creare una libreria di extension methods per Mono. Gli extension methods sono la trovata della Microsoft per incasinare quello che era nato come un buon progetto, tutto sommato. Ossia, perchè ereditare un’intera classe per poi aggiungerci un metodo, quando posso scrivere un extension method? La domanda è legittima e la risposta sta nell’esempio seguente: supponete di avere una stringa che contiene un indirizzo di posta elettronica e volete un metodo per verificare se l’indirizzo è corretto (almeno sintatticamente). Ma siccome questo metodo è abbastanza generale vi viene in mente che potrebbe essere un metodo associato alla classe “string”! Bene in C# 3.0 possiamo scrivere una classe del genere:
public static class ZacExtensions { public static bool IsValidEmailAddress(this string s) { Regex regex = new Regex(@"^[\w-\.]+@([\w-]+\.)+[]µçrÕ׳"ÃGÒB"“°Ð¢&WGW&â&VvW‚ä—4ÖF6‚‡2“°Ð¢ÐЧÒÂö6öFS
Adesso è sufficiente includere il file con questa classe nel nostro progetto e magicamente “IsValidEmailAddress” diventerà un metodo della classe “string”. Bello! Magari un pò troppo “Agile” ma bello!
Tornando all’idea di prima le Rocks sono degli extension method, ne più ne meno, con qualche regola da rispettare per poterli mettere assieme in una libreria:

• The code must comply with the Mono coding conventions.
• The «this» parameter of the extension method must be named «self».
• To be included, a rock must come with its corresponding unit tests.

Un esempio di Rock è il seguente:
public static string Join<TSource> (this IEnumerable<TSource> self, string separator) { var coll = self as ICollection<TSource>; if (coll != null && coll.Count == 0) return string.Empty; int i = 0; var s = new StringBuilder (); foreach (var element in self) { if (i > 0 && separator != null) s.Append (separator); s.Append (element); i++; } return s.ToString (); }
E ovviamente a unit test:

using Mono.Rocks; // ... [Test] public void Join () { var data = new int [] { 0, 1, 2, 3, 4, 5 }; var result = "0, 1, 2, 3, 4, 5"; Assert.AreEqual (result, data.Join (", ")); }

Un progettino interessante che fa ben sperare sulla fortuna di Mono, per quanto Novell stia facendo di tutto per metterlo in cattiva luce.

Zac

…è che se ne arricchiscono tutti quanti. Leggevo oggi delle interessanti evoluzioni sullo sviluppo di LinQ, il language integrated query, vera innovazione della Microsoft nel suo nuovo .Net. Ora il LinQ approda anche sulla piattaforma Mono, il porting multipiattaforma di .Net, distribuito con licenza GPL/LGPL, vuoi perché la maggior parte dei suoi sviluppatori lavora in Novell, vuoi perché le librerie .Net si decompilano in modo semplicissimo (ma no, quelli di Mono queste cose non le fanno!). La Microsoft consente, attraverso le sue librerie, di utilizzare il LinQ su collezioni, file di testo, file XML e Database; in quest’ultimo caso il compilatore si preoccupa di tradurre le query LinQ in query SQL. Per quanto strano l’approccio funziona, ed anche bene, ma l’unico difetto è che l’unica piattaforma di database supportata è, ovviamente, SQL Server.

I Mono-Guys hanno iniziato la scrittura di una libreria, chiamata DBLinQ, che consentirà di sfruttare LinQ anche su altri database (e sopratutto su quelli open source). Questo è ovviamente una bella iniezione di fiducia nei confronti di un progetto che, dopo lo scellerato accordo Novell-Microsoft, ha gettato un’ombra pesante anche sul progetto Mono, che da Novell è sponsorizzato. Ma, come se non bastasse, l’articoletto mi ha fatto scoprire una estensione di LinQ che non immaginavo nemmeno: perché non sfruttare la potenza dell’accesso ai dati offerto da queste query integrate per eseguire codice parallelo su macchine Multi-Core? Già, perché? Ed infatti ci sono diversi gruppi di lavoro che hanno pensato di progettare delle estensioni per eseguire codice su dati distrbuiti su più core o addirittura per lavorare su framework per il grid computing: i due progetti si chiamano PLinQ e GridLinq (decisamente originali i nomi). Vi lascio ai vari LinQ per scoprire i dettagli di queste novità.

Zac

Seguendo il successo del fratello IronPython, arriva alle ultime fasi di sviluppo IronRuby, che porta il linguaggio più celebre del Web 2.0 nella ricca collezione dell’ambiente .Net. Nonostante sia stato sviluppato da Microsoft, IronRuby è distribuito con la Microsoft Permissive License (^_^”) che consente una fruizione completa dei sorgenti senza null’altro a pretendere da parte di Microsoft stessa (se non, forse, il fatto che nessuno brevetti questo lavoro). IronRuby si poggia sul DLR (Dynamic Language Runtime) che è quella porzione della virtual machine che consente l’esistenza, all’interno di .Net, di tutte quelle funzioni che consentono la generazione dinamica di variabili, gestione dinamica dei metodi e tutte le altre delizie a cui i linguaggi moderni ci stanno abituando. Grazie al DLR pare che le performance siano superiori a quelle di Ruby 1.8.6.

La mossa della Microsoft non va sottovalutata in quanto la gestione dei linguaggi in .Net ne sta decretando la sempre più capillare diffusione negli ambienti di sviluppo anche a discapito di Java. Inoltre i Mono-guys stanno tenendosi al passo con tutte le novità dell’ambiente .Net, offrendo anche una valida alternativa Open Source a tutto ciò. Sun dovrebbe darsi una svegliata ed iniziare qualche contromossa prima che sia troppo tardi: non basteranno certo OpenJava o JavaFX a destare preoccupazioni alla Microsoft: occorre che Java cominci a snellirsi sul lato virtual machine e ad accelerarsi sul lato delle performance.

La mia l’ho detta.

Zac

Vi segnalo rapidamente questo link per l’ennesima innovazione nell’ambito dello sviluppo .Net/Mono: il DLR (Dynamic Language Runtime). Ossia programmate come vi pare, in qualsiasi linguaggio vi pare…

Seguiranno maggiori delucidazioni…sappiate solo che questo progetto arriva insieme al nuovissimo Iron Ruby!!! Wow…

A presto.

E stata di recente inserira all’interno del progetto Mono la possibilità di creare applicazioni estensibili in un lampo. Il framework Mono.AddIns si propone di fornire un ottimo supporto sia ai progetti di piccole dimensioni che a quelli di livello Enteprise: ed ufficiallmente qui, adesso, in questo preciso momento storico che nasce il progetto, tutto salentino, di un ERP open souce che faccia concorrenza a SAP; il suo nome? Ovviamente FreeSap (ah ah, mmh).

Scherzi a parte vediamo subito un piccolo esempio di come sfruttare con profitto questa tecnologia. Non può esistere un addin senza un interfaccia: ce lo dicono i design pattern e, nonostante questa libreria l’interfaccia ce tocca:

[assembly:AddinRoot ("TextEditor", "1.0")]
	
[TypeExtensionPoint]
public interface ICommand
{
	string Run ();
}

Un derivato di questa classe implementa l’AddIn vero e proprio

[assembly:Addin]
[assembly:AddinDependency ("TextEditor", "1.0")]
	
[Extension]
class HelloWorldExtension: ICommand
{
	public string Run ()
	{
		Console.WriteLine ("Hello World");
	}
}

E la classe estensibile si estende in questa maniera:

public class Application
{
	public static void Main ()
	{
		AddinManager.Initialize ();
		foreach (ICommand cmd in AddinManager.GetExtensionObjects (typeof(ICommand)))
			cmd.Run ()
	}
}

Visto così è il classico esempio di AddOn con un pò di Reflection in mezzo che non guasta mai. A questo potete aggiungere tutta una serie di casi particolari che si possono gestire attraverso questa libreria.

Beh ora non avete più scuse per lasciare i vostri applicativi da soli! (ad una persona con gli occhialetti ed i capelli lisci gli staranno fischiando le orecchie?)

Visto che la maggior parte di voi parla sempre di Java, colgo l’occasione per parlare anche del suo fratellino minore C#. Mi piacerebbe anche sapere da qualcuno di voi se le feature in questione esistono in Java. Quando ho letto di questa caratteristica, appena introdotta nell’ultima fork di Mono, mi sono chiesto che fine avesse fatto l’ereditarietà per questi signori, ma soprattutto se ciò non avrebbe portato a codice difficilmente manutenibile.

Gli Extension Methods sono dei metodi, definiti in una classe A che estendono le funzionalità di una classe B. Per loro natura devono essere metodi statici e possono essere invocati a partire da qualsiasi istanza della classe B.

Un esempio aiuta a capire più di 1000 tesi di laurea:

static class MyExtension
{
  public static string Prefix (this string s, string prefix)
  {
    return prefix + s;
  }
}
	
class M
{
  public static void Main ()
  {
    string s = "abc".Prefix ("1");
  }
}

Un extension method ha come primo parametro un’istanza della classe da estendere preceduta da “this” (oh mein gott). Il senso del codice adesso appare chiaro. Possiamo estendere le classi a nostro piacimento, oltre che a nostro rischio e pericolo, senza doverne ereditare interfacce e scrivere classi ereditate. Il problema nasce nel momento in cui ci sono più extension per la stessa classe, con lo stesso nome. In questo caso si mette in moto un gestore dei nomi che utilizza l’albero dei namespace per trovare l’extension più vicina. Un pò ingarbugliato ma potrebbe rivelare scenari interessanti.

La cosa divertente è che gli sviluppatori consigliano di usarli solo se strettamente necessario…mi sa che quelli di Mono si stanno avvicinando un pò troppo alla mentalità di M$.

Zac