FoxyBlog

Avevo già parlato in passato delle soddisfazioni dello sviluppo OpenSource.

Ultimamente sto scoprendo anche quanta soddisfazione dia partecipare ad una community: e con questo mi riferisco sia allla communtiy UGI che alla community "allargata" di sviluppatori .NET mondiali (beh, principalmente US).

Scambiare opinioni con gente del calibro di Scott Hansleman , Phil Haack, David Silverlight o vedere i propri post (o il proprio lavoro) citati nei loro post o in importanti blog del settore mi da una soddisfazione immensa.

Il top è stato raggiunto 2 o 3 giorni fa quando Scott ha lasciato un commento (in italiano babelfishese ) sul post che commentava il suo libro ASP.NET 2.0 MVP Hacks and Tips.-)

Ho anche notato che la qualità del codice, ed specialmente delle "architetture" software, è notevolmente migliorato con i continui confronti con i vari membri sia di UGI che delle altre community che, soprattutto, con i membri del team di sviluppo di SubText.
Non che le discussioni con i miei colleghi siano poco interessanti, ma in ufficio con me lavorano 2 sviluppatori (3 me compreso), quindi non c'è molto spazio a discussioni

powered by IMHO 1.3

E' triste quando un progetto opensource muore, ma lo è ancora di più quando il progetto è nato dalla propria mente, e l'unico motivo per il quale non è mai stato completato è la mancanza di tempo.

JClubHouse è un progetto che io e Daniela abbiamo iniziato tre anni fa, era un CMS (tanto per cambiare ) sviluppato in Java, utilizzando Struts e Tiles, specializzato sulle associazioni (sportive o hobbistiche).

Ma ora devo decretarne la morte per i seguenti motivi (in ordine di importanza):

• poco tempo per lavorarci
• ci sono altri progetti sui quali ci stiamo concentrando (SubText, DotNetNuke, Kea-Winemaker)
• ora c'è .NET, mentre 3 anni fa al lavoro si sviluppava ancora in ASP Classic, e quindi avevi bisogno di una "valvola di sfogo OO"
• quasi nessun shared-hosting "economico" supporta Java, e poichè il target sarebbe stato quello degli hobbisti che si fanno il sito personale o della propria associazione, nessuno lo avrebbe usato
• DotNetNuke ha le stesse funzionalità di JClubHouse
• non ho più un server pubblico sul quale far girare un container java

Spero che Kea-Winemaker non faccia la stessa fine.

Shaun Walker, fondatore di DotNetNuke, ha pubblicato sul suo blog una tabella comparativa tra DotNetNuke, ASP.NET 2.0, SharePoint Server 2003 e Microsoft Office Sharepoint Services 2007.

Ovviamente vince a mani basse sul ASP.NET 2.0, essendo questa un framework applicativo più che un prodotto, mentre era più difficile posizionarsi in maniera competitiva rispetto alle due versione di SharePoint (03 e 07).

Che DNN fosse la scelta ottimale per gli ambienti di tipo shared-hosting e per i siti non entreprise già si sapeva: con 40k€ di licenza SharePoint non punta sicuramente ad un mercato del genere.

Ma questa matrice, apparre che DNN possa essere una soluzione competitiva anche in ambito Enterprise.

Leggete per giudicare coi vostri occhi: Feature Matrix Showdown

powered by IMHO 1.3

Migrare un progetto ASP.NET dalla 1.1 alla 2.0 è un processo abbastanza semplice e quasi completamente automatico.

Lanci il wizard (meglio se si usa il Web Application Project), lo lasci girarare per una 10ina di minuti e ti trovi il nuovo progetto pronto per essere lanciato sul framework 2.0.

Poi se si è pignoli, o si è detto al compilatore di mostrare i Warning come se fossero Errori, vi trovarete a rimpiazzare 345 volte ConfigurationSettings con ConfigurationManager, oppure a cambiare parameters.Add in parameters.AddWithValue, oppure uno delle varie API rese obsolete nel framework 2.0

Ora la parte automatica (semi-automatica) è finita (in 4 ore mi sono smazzato 2 classi library e 2 web project per un totale di circa 200 file di codice).

Ma ora inizia il bello, cioè introdurre le funzionalità portate dal FW 2.0.
Io ho iniziato con le MasterPages per rendere più snella la gestione del layout generale del sito di backend: e cos'ho ottenuto?
Sto facendo copia e incolla da quasi 2 giorni: MasterPageFile="~/Admin.Master" nella direttiva di Page e

<asp:Content ContentPlaceHolderID="main" runat="server">
    <!-- Contenuto -->
</asp:Content>

2 o 3 volte per ognuna delle 120 pagine del backend, ovviamente anche togliendo i pezzi di HTML che sono stati spostati nella master page.
Penso di non aver fatto mai un'attività così pallosa per così tanto tempo!!

powered by IMHO 1.3

Il numero di ieri di Community Server Daily News, il blog ufficiale che raccoglie articoli, post e thread interessanti sullo sviluppo e l'utilizzo di Community Server, ha riportato la "notizia" dell'inizio della mia serie di articoli sulla customizzazione di Communtiy Server:

A new CS Developer's Guide has been launched by Simone Chiaretta with the first item's title being "To personalize CommunityServer: write CSModules."   Now all we need is a CSApplication PreItalianDisplay Global event to hook into from another CSModule to do the translation.  In this article, Simone provides a thorough introduction to CS Modules.

Spero di riuscire a mantenere una frequenza di pubblicazione costante, e di continuare ad approfondire sempre più questo stupendo software di community.

Ho notato dalle statistiche, che il mio articolo [CSDev#1] - Personalizzare CommunityServer: scrivere CSModules non ha riscosso molto interesse (solo una 40ina di visite in una settimana): lo trovo strano perchè ho visto molti siti community (in primis quello delle due spin-off di UGIdotNET nuove community italiane su .NET) che lo usano. Ma forse senza pensare ad estenderlo troppo

Che Cassini sia diverso da IIS si sa, e anche Microsoft consiglia di testare sempre le proprie applicazioni anche su IIS standard (soprattutto se usate funzionalità che accedono al file system, ha problematiche di permessi, e similare).

Una delle differenze principali è che tutte le estensioni sono mappate all'engine di ASP.NET: quindi anche i file css, i js, le immagini jpg, gif e png passano tutte dalla pipeline degli eventi di ASP.NET.

Questo che problematiche porta?
Innanzitutto un degrado di performance, perchè il motore di ASP.NET deve analizzare anche le immagini o i video per capire se deve far partire la pipeline completa. Questo potrebbe non essere un problema, visto che siamo in ambiente di sviluppo.

Se questo fosse un problema si può aggiungere nel web.config i seguenti HttpHandlers

L'altro problema, più critico perchè bloccante, è che l'autorizzazione <deny users="?"/> viene applicata anche ai file statici: quindi l'eventuale pagina di login o altre pagine configurate per essere visibili anche gli utenti anonimi non mostrano immagini e stili perchè sono state bloccate dalla configurazione di autorizzazione.

Una soluzione è aggiungere al file di configurazione una sezione location che abiliti la visualizzazione dei singoli file statici anche agli utenti anonimi:

Ma se avete tanti file statici, invece che aggiungere una sezione location per ciascuno, potete raggrupparli tutti in sottocartelle apposite e aggiungere un file web.config che permatta la visualizzazione di tutti i file della cartella anche agli utenti anonimi.

Questi sono alcuni delle problematiche che devono essere affrontate se vogliamo usare il web server integrato di VS 2005: a mio avviso poco rispetto a tutti i grattacapi che da lo sviluppo di web application usando l'IIS locale della macchina di sviluppo.