Stasera, mentre mi spazzolavo i referrer al mio weblog mi sono imbattuto in un link davvero curioso. La provenienza è la versione tedesca di ZDNet. Il link che ho trovato si riferisce a IMHO 1.3. Visitando il referrer ho scoperto una pagina in cui ne viene pubblicizzato il download risalente allo scorso 26 giugno 2006. Inutile dire che non me lo aspettavo...

Link:

tags: - categories:

Ok, lo ammetto, sono stato preso in contropiede dall'uscita del nuovo e sfavillante Live Writer che - non ci vuole molto ad ammetterlo - surclassa e "seppellisce" definitivamente il mio IMHO 1.3. La domanda mi gira in testa da un po' di giorni ormai ma finalmente ho trovato il tempo di esprimerla su queste righe.

Continuo IMHO?

Ne ho parlato con parecchie persone in questi giorni, e i pareri sono molto discordi. Da chi mi dice chiaramente, "lascia perdere, non ha futuro" a chi invece invece mi incoraggia ad andare avanti e provarci lo stesso, probabilmente per affetto o magari perchè realmente crede che io ce la possa fare.

E' evidente che non abbiamo alcuna speranza di fare concorrenza a live writer, non fosse altro perchè non abbiamo un team di 20 programmatori. Le uniche speranze sono quelle di trovare una nicchia, in cui collocare Imho 2.0 oppure, quella che mi alletta di più di dare delle feature talmente innovative da superare le leccornie di live writer...

Il problema è che live writer è un prodotto nuovo che ha alle sue spalle la potenza di sviluppo e marketing di una azienda colossale, che in questo momento lo vede come uno strumento eccezionale per contrastare il suo diretto concorrente (Google). Per questo motivo, anche dovessi davvero inventare il ghiaccio bollente non ci vorrà molto per essere nuovamente superato.

Al momento sono molto dubbioso, nonostante stiamo lavorando alacremente sulla versione 2.0 che ha superato già le prime fasi del porting a nhibernate e che si avvia verso una prima release alpha a passi svelti. Avrei molte altre idee su cui investire, altri progetti che mi girano in testa, ma vi confesso che l'affetto che ho per questo progetto mi impedisce di chiuderlo definitivamente e repentinamente. Al momento perciò IMHO rimane vivo, nella speranza che altri vogliano aggregarsi al nostro team per dare il proprio contributo e che, il supporto che ho avuto in questi anni, non sia del tutto svanito.

Voi che ne pensate?

powered by IMHO 1.3


E nei primi freddi di Agosto (?) e' giunto il momento che metta al corrente tutti delle novità che riguardano il mio progetto IMHO, che oramai molti potrebbero considerare quasi-defunto dato che da tempo non se ne sa più nulla. IMHO invece è ancora vivo, perlomeno respira, ma dopo un periodo di congelamento dovuto allo scarso tempo a disposizione sta per riprendere il via. Questo grazie soprattutto al fatto che da alcune settimane si è unito a me nello sviluppo Mauro Servienti, che ha risposto all'appello che qualche tempo fa ho lanciato sul mio blog. IMHO perciò non sarà più solo il mio progetto.

Attualmente ci stiamo allineando su quello che già esiste, e abbiamo abbozzato una divisione dei compiti che dovrebbe vedere Mauro occuparsi della parte client e io della parte server. Non siamo ancora in grado di prevedere una data di rilascio dato che non abbiamo nemmeno provato a quantificare il lavoro, ma sono fiducioso che ora la spinta di due persone possa portarlo avanti molto rapidamente, almeno nella versione che abbiamo definito "Personal". IMHO, soffre attualmente di alcuni problemi che dovremmo affrontare per primi in modo da rimetterlo in carreggiata. Primo fra essi l'adozione di NHibernate come motore di Mapping, in sostituzione di iBatis che è un po' troppo "macchinoso". L'adozione di NHibernate sarà resa possibile dal cambio della base dati che passerà da Access, probabilmente a SQL Everywhere, per la versione base. Infine, ma questo sarà un problema che dovrà affrontare soprattutto Mauro, ci dovremmo scontrare con la prossima "sparizione" del controllo DHTML Edit, che era il cuore del precedente software. Infatti pare che da Internet Explorer 7.0, per motivi legati alla sicurezza questo controllo non sarà più disponibile e saremo costretti a trovarne un valido sostituto.

Ma a proposito di IMHO c'è un'altra importante notizia. Pochi sanno che IMHO 2.0 aveva trovato posto sul sito gotdotnet, anche perchè non mi ero mai preoccupato di divulgare la notizia. Mi faceva comodo lavorare con un backup dei sorgenti in remoto e non avevo mai nemmeno usato le altre feature di GDN. Oggi però vale la pena che informi tutti che IMHO 2.0 è da poco ospitato da Codeplex, dato che Korby Parnell e la sua collaboratrice Julie Sander hanno deciso che ha le carte in regola per farne parte. Codeplex, a prima vista pare proprio ben fatto, sarà forse per il fatto che ormai mi sto abituando a Team Foundation Server che uso anche sul lavoro, ma dove dire che la versione web è proprio venuta bene. Spero che ci auguriate un buon lavoro, e se per caso avete voglia di darci una mano... qualcosa da fare lo troviamo di certo.

powered by IMHO 1.3


Mi sono finalmente deciso a trovare una soluzione per la mia prolungata inattività sul mio progetto opensource. Da quando ho cambiato lavoro lo scorso dicembre, e a causa di una grossa mole di attività correlate allo user-group xe.net non sono più riuscito a trovare la giusta continuità per scrivere un po' di codice per il software. Consigliato da più parti, ho deciso infine di avviare una fase di ricerca collaboratori, allo scopo di portare alla conclusione questo progetto che mi sembra nonostante il lungo tempo trascorso dal suo ultimo aggiornamento ancora molto apprezzato.

Con questo non voglio dire che rinuncio a scrivere codice, anzi, ma la mia speranza è di poter delegare alcuni moduli vitali ad altre persone interessate, meglio se italiane così almeno parliamo la stessa lingua, per arrivare entro il prossimo settembre ad un rilascio della versione beta.

Chi fosse interessato non ha che da contattarmi mediante l'indirizzo che appare sul weblog. Tenete presente che non si tratta di una attività "riposante" chi si vorrà assume l'onere deve garantirmi che il modulo a lui affidato non rimarra solo un buon proposito, ma si concretizzerà in un bel po' di codice...

Grazie in anticipo.

powered by IMHO 1.3


Sul prossimo numero di Aprile di Computer Programming, già citato da Simone, uscirà un articolo dedicato ad IMHO 1.3. Si tratta di un paio di pagine nelle quali oltre ad illustrare alcune delle caratteristiche salienti del software mi dilungo anche sulla mia concezione del weblogging e sulla storia di questo software.

Ho deciso di dedicare questo articolo a XE.NET. In calce all'articolo infatti apparirà il logo della nuova community, nella speranza di stimolare l'interesse dei miei corregionali, e magari anche dei limitrofi.

Buona lettura a tutti.

powered by IMHO 1.3


Ho provveduto ad aggiornare la roadmap di IMHO 2.0 per rispecchiare l'andamento del progetto. Le modifiche più significative sono il termine della lavorazione del Preview Panel, l'anticipazione di alcuni dei servizi della Media Library alla prima versione, e l'inizio dello sviluppo dell'editor.

powered by IMHO 1.3


Finalmente eccomi a presentare la prima preview di IMHO 2.0. Al seguente indirizzo i miei assidui lettori potranno trovare alcuni screenshots della nuova interfaccia di IMHO e così cominciare pregustare le nuove feature. Il lavoro è ancora lungo e irto di difficoltà, ma sono lieto di condividere con voi la gioia che i primi vagiti dell'applicazione mi hanno regalato.

Ma veniamo a qualche più dettagliata spiegazione, partendo dall'immagine che affianca questo post. La finestra principale di IMHO, che probabilmente assumerà il nome di Management Central avrà sul lato sinistro una barra di tipo stacked, creata grazie agli splendidi controlli della Syncfusion. Tale barra è una sorta di finestra sul mondo, infatti grazie alla particolare architettura modulare essa è in grado di ospitare una serie di controlli che rappresentano le diverse funzionalità espletate da ogni modulo. A lato è già possibile vedere il Site Manager, e il MemberShip Manager (ancora incompleto). Il Site Manager come è evidente raccoglie al suo interno non solo i siti gestiti da IMHO 2.0, ma anche la struttura delle categorie sempre che l'engine cui il nodo si riferisce le supporti. La struttura delle categorie è gerarchica e ha un livello di profondità che è determinato dall'engine adapter e quindi in ultima analisi dal tipo di server su cui si pubblica. Ogni nodo è gestibile per mezzo di una apposita finestra di proprietà delle quali quella relativa la gestione del sito è visibile negli screenshots.

Tra gli screenshot è presente anche la finestra principale che oltre alla barra laterale di cui ho parlato finora, acquista anche un Preview Panel, che consentirà di rivedere il contenuto dei post precedentemente realizzati senza doverli aprire nell'editor. Proprio questo pannello probabilmente sarà la parte più complessa da realizzare perchè dato che l'architettura di IMHO 2.0 utilizza remoting, vorrei evitare di trasferire ogni volta i file che costituiscono il post attraverso remoting e e salvarli in una cache locale e per questo motivo sto valutando l'opportunità di realizzare un mini webserver integrato che mi permetta semplicemente di impostare l'url nel controllo webbrowser e dimenticarmi di quello che succede in seguito.

Per ora è tutto. Come dicevo questi screenshot sono solo un modo per condividere il lavoro che si presenta tutt'ora lungo. Per questo motivo saranno soggetti anche a modifiche, revisioni e spero pochi tagli prima che la prima beta (o alpha) possa essere pubblicata. Attendo i vostri commenti e i vostri suggerimenti.

E come usano dire gli anglomani... stay tuned!

powered by IMHO 1.3


Uno scambio con Mauro Sagratella mi ha ricordato una piccola questione riguardante IMHO che da tempo avevo dimenticato. Chi avesse un palmare e provasse ad usare ActiveSync mentre IMHO è in esecuzione avrà la spiacevole sorpresa che l'ActiveSync non funzionerà. Oppure tentando di aprire IMHO mentre è in corso una sincronizzazione sarà IMHO a non riuscire a partire. Il problema è di semplice spiegazione e per fortuna anche di semplice soluzione. IMHO fa uso di una porta, la 3010, sulla quale si mette in ascolto di chiamate di remoting da parte dell'handler che gestisce il quoting da Internet Explorer o Firefox. A quanto pare tale porta è utilizzata anche da ActiveSync per cui dato che non è possibile che due socket condividano la stessa porta il secondo che arriva non riuscirà a partire. Come dicevo, la soluzione è semplice: è sufficiente andare nei file imho.exe.config e imhoie.exe.config e cambiare il numero della porta che deve coincidere nei due file. Ad esempio Mauro mi segnala che la 2710 funziona egregiamente.

Detto questo c'è una curiosità relativa le porte prescelte che vi giro come un indovinello. Riuscite ad indovinare per quale motivo ho scelto di usare la porta 3010? Chi mi segue non dovrebbe aver difficoltà a rispondere alla domanda.

Mauro che lo sa è invitato ad astenersi...

powered by IMHO 1.3

tags: - categories:

Ho pubblicato un primo draft che descrive l'architettura di IMHO 2.0. Nel documento è presente uno schema a blocchi e vengono descritti abbastanza in dettaglio i vari componenti che partecipano al funzionamento dell'applicazione. Mi riservo di apportare ulteriori modifiche all'architettura qualora ne rilevi la necessità, anche in risposta a feedback che partano dai lettori.

Link: IMHO 2.0: Application Architecture

tags: - categories:

DOCUMENT VERSION

Status: draft

Author: Andrea Boschin
Last Update: 14/10/2005
Current Version: 1.0.0

ABSTRACT

Nel presente documento viene illustrata l'architettura dell'applicazione denominata IMHO codename "Pellestrina", allo scopo di definire l'ambiente in cui verranno collocati i moduli applicativi e l'interazione esistente tra essi. Nello stesso documento verranno anche definiti i punti di estensibilità presso i quali potranno agganciarsi eventuali moduli esterni sviluppati in seguito anche da terze parti.

OBBIETTIVI E SCELTE ARCHITETTURALI

La progettazione dell'architettura di IMHO codename "pellestrina" ha avuto essenzialmente due obbiettivi. Il primo di essi è stato la necessità di realizzare una piattaforma collaborativa che consentisse a postazioni distribuite di concorrere nella gestione di uno o più siti web (blog). Per risolvere questa esigenza si è scelto di suddividere l'applicazione in una parte server ed una client. La parte server avrà la responsabilità di consentire a diversi utenti l'accesso ai contenuti per la creazione di post, la loro categorizzazione, la schedulazione delle attività e la sincronizzazione con i siti veri e propri. Il client sarà la vera e propria interfaccia utente che permette la fruizione delle funzionalità in base ai permessi dell'utente e ai siti ad esso assegnati. La prima scelta architetturale quindi è stata quella di utilizzare .NET Remoting per consentire la comunicazione tra Client e Server.

La tecnologia .NET Remoting è parsa la più efficace e al tempo stesso anche quella più flessibile e adattabile alle esigenze applicative. In seguito a questa scelta e alla necessità di compiere attività sincrone e asincrone anche schedulate si è deciso di realizzare la parte server come un Windows Service che esponga da un lato una serie di "Remote Providers", ognuno dei quali deputato ad un certo ambito dell'applicazione, e dall'altro si occupi di effettuare le operazioni asincrone verso i siti web e di gestire le schedulazioni. In particolare la scelta di avere un certo numero di provider anzichè uno solo è data dalla necessità di ridurre al minimo il numero dei metodi esposti da un singolo oggetto per migliorare le performances del server.

Ulteriori considerazioni hanno consigliato l'adozione di una struttura a Provider anche per la parte di accesso ai dati che è rsidente completamente nella parte server. Tale struttura consente di migrare facilmente e rapidamente l'applicazione su diversi tipi di database. Infatti nonostante inizialmente l'applicazione sia basata su un database Microsoft Access, sarà opportuno in seguito consentire l'adozione di database più potenti quali Sql Server o Oracle. La scelta attuale di utilizzare un database Access è dovuta alla volontà di semplificare al massimo l'installazione del software e di esplorare innanzitutto il gradimento del prodotto prima di orientarsi a prodotti più complessi e costosi.

Il secondo obbiettivo cui l'architettura doveva rispondere era la necessaria espandibilità dell'applicazione, innanzitutto per consentire in futuro lo sviluppo di moduli aggiuntivi, realizzati per soddisfare esigenze specifiche, ma anche per consentire una più facile customizzazione e per spronare la realizzazione di estensioni di terze parti. Per raggiungere questo obbiettivo si è scelto di suddividere l'applicazione in moduli, ognuno dei quali viene caricato nella parte client al momento dell'avvio dell'applicazione. Ad ognuno dei moduli in fase di inizializzazione viene fornito un handle di una finestra host cui essi può agganciarsi con uno o più componenti dei quali in seguito intercetterà gli eventi. Al verificarsi di questi eventi i moduli applicativi, in completa autonomia si collegano al server ed espletano le proprie funzionalità usando i provider remoti definiti specificamente per il loro funzionamento oppure quelli di altri moduli da cui essi dipendono.

COMPONENTI ARCHITETTURALI

Nello schema qui sotto riportato sono definiti in dettaglio i componenti che danno vita all'architettura dell'applicazione e il rapporto che li lega. Lo schema è suddiviso innanzitutto nelle due parti che compongono l'applicazione, Il Client e il Server. Ecco a partire dall'alto quali sono i vari componenti e le funzionalità che essi espletano:

PLUGGABLE USER INTERFACE

L'interfaccia utente, è il fulcro attorno al quale ruota l'estensibilità dell'applicazione. Essa ha la caratteristica di poter acquisire nuove componenti, all'interno di una struttura ben definita, consentendo a tali componenti di vivere autonomamente e di comunicare con gli strati inferiori dell'applicazione. Questa struttura che sarà oggetto di un successivo articolo, espone delle aree entro le quali uno dei moduli applicativi possono agganciare componenti dai quali poi riceveranno notifica degli eventi cui si sono iscritti. L'interfaccia è composta da una form denominata host, che espone le seguenti aree:

  1. Group Bar
  2. Toolbar
  3. Status Bar
  4. Content Area

All'interno di queste aree un modulo può agganciare dei controlli che derivano da opportune classi, che forniscono un subset minimo di funzioni per l'accesso all'interfaccia. La registrazione di queste componenti avviene nel momento dell'istanziazione del modulo sottostante che sfrutta i metodi dell'interfaccia IHost che riceve come unico parametro nel costruttore.

MODULES

Il "Modulo" è l'unità minima che concorre al funzionamento dell'applicazione. Esso viene istanziato dinamicamente sulla base di alcune informazioni che vengono reperite nell'elenco dei moduli installati presente nel file di configurazione. In questo modo chiunque è in grado di registrare un nuovo modulo semplicemente realizzando una classe che estende la classe astratta ImhoModule. In un'architettura 3-tier il modulo è lo strato intermedio che si interpone tra interfaccia e datalayer. L'applicazione definisce al suo interno un certo numero di moduli qui elencati:

  1. Membership Management
  2. Site Management
  3. Post Management
  4. ...

(l'elenco dei moduli deve essere completato)

All'atto della propria creazione un modulo registra presso l'applicazione host i propri controlli e contestualmente si iscrive agli eventi che questi espongono. Per alcuni casi specifici l'host esporra alcuni metodi che consentono la condivisione di componenti di interfaccia anche tra moduli diversi (da valutare). Il modulo accede agli strati inferiori dell'applicazione per mezzo del Controller, sia esso quello standard o uno custom. I moduli inoltre utilizzano il meccanismo dei Principal per determinare quali sono le azioni che possono essere compiute da ogni utente.

CONTROLLER

Scopo primario del controller è quello di mascherare alle parti superiori dell'applicazione le presenza dei provider remoti. Esso a tutti gli effetti si comporta come una façade istanziando i provider remoti e di chiamandone i metodi per ottenerne i risultati in modo del tutto trasparente per gli strati superiori. Inoltre esso è un Singleton, e quindi è accessibile da parte di qualunque modulo senza che la sua referenza debba essere passata da un module ad un altro.

COMMUNICATION SINKS

La comunicazione tra il client e il server avviene per mezzo dei comuni protocolli di rete attraverso messaggi http o tcp in formato binario o SOAP. Questo tipo di comunicazione, unita alla scelta di usare la modalità "Single Call" per i provider remoti fa si che da un lato sia necessario proteggere il canale di comunicazione che altrimenti potrebbe essere facilmente intercettato e dall'altro che sia obbligatorio stabilire un modo per evitare di ripetere l'autenticazione ad ogni chiamata. I channel sinks assolvono proprio a queste esigenze. Primo fra essi, il SessionSink-Client, di occupa di affiancare ad ogni messaggio tra client e server un GUID che rappresenta la sessione corrente. La controparte server del Server del SessionSink rilevata la presenza del GUID verifica la corrispondenza con una sessione nella cache oppure la ricostruisce interrogando la base dati. La cache delle sessioni ha lo scopo di minimizzare l'accesso alla base dati nei momento di intenso utilizzo da parte del client. Assieme alla sessione sul server viene ricostruito anche il Principal all'interno del thread che sta eseguendo la chiamata, per propagare la gestione dei parmessi anche al server. Il secondo sink, denominato Encryption Sink usa una chiave condivisa tra client e server per crittare e decrittare i messaggi in transito tra le due controparti. Al momento la chiave è memorizzata all'interno del file di configurazione sia sul client che sul server, ma è auspicabile che essa possa essere specificata dall'utente al momento della prima registrazione del server sul client.

REMOTE PROVIDERS

Il provider remoto è una classe che estende MarshalByRefObject, il cui compito è di eseguire sul server i metodi chiamati dal client. Nella maggior parte dei casi il provider remoto dovrà accedere alla base dati e lo farà per mezzo del provider dati discusso nel prossimo paragrafo. Tuttavià il provider remoto può anche compiere operazioni differenti dall'accesso ai dati come a titolo esemplificativo: Impartire comandi di controllo al server, interfacciarsi ad altre componenti dell'architettura, etc...  In sostanza il provider è il mezzo con cui il client potrà operare sui dati e sull'engine centrale dell'applicazione. E' possibile registrare ulteriori provider "custom", inserendo le loro caratteristiche all'interno del file di configurazione. In questo modo chiunque potrà sviluppare providers a supporto delle componenti custom registrate negli strati superiori dell'applicazione.

DATA PROVIDER

Il data provider ha lo scopo di astrarre la base dati utilizzata e di contenere al suo interno le chiamate al database esponendole per mezzo di metodi. L'architettura di imho prevede che per l'accesso ai dati e il mapping su oggetti si faccia uso della libreria ORM iBatis. Tale libreria utilizza uno o più file xml che determinano le query da compiere per ottenere i dati. Questo file è parte integrante del dataprovider e deve essere contenuto in esso come embedded resource.

RELEASE HISTORY

Date Description Author
16/10/2005 Rilascio al pubblico Andrea Boschin

tags: - categories:

Grazie al prezioso aiuto di Mauro Sagratella, ora vi posso comunicare che l'ultima versione di IMHO risolve anche i problemi di ISA Server. Mauro mi ha supportato testando IMHO su ISA Server di cui io non dispongo e ha fatto anche qualche prova di codice che mi ha aiutato ad arrivare ad una felice conclusione. In questo post quindi vale la pena di discutere i due aspetti della questione:

1) Come configurare IMHO per uscire su ISA Server

E' molto semplice, se il vostro browser Internet Explorer naviga correttamente non avete che da impostare l'opzione "Use proxy from Internet Explorer" e tutto funzionerà correttamente.

2) Come faccio ad uscire su ISA Server con un mio programma

Anche qui la questione si risolve semplicemente. Ecco le due righe di codice che sono la chiave di tutto:

...

WebProxy defaultProxy = 
    WebProxy.GetDefaultProxy();

defaultProxy.Credentials = 
    CredentialCache.DefaultCredentials;

...

In sostanza occorre dare le credenziali dell'utente correntemente loggato al sistema al proxy che poi verrà usato per uscire su internet.

[now playing: Woodstock 99 Full Set (01:52:48) - Metallica]

powered by IMHO 1.3