Programmiamo

JSPCart utilizza per la configurazione del negozio online 3 file XML. La prima volta che ho visto il codice sono rimasto esterrefatto da come veniva letta la configurazione. Inizialmente pensavo che ci fosse un parser SAX o DOM, invece nemmeno quello, il codice effettuava (e lo fa tuttora) il parsing del file a mano.

So già cosa state pensando: roba da matti!!!

Oggi quando mi trovo ad affrontare la problematica di mappare file XML in Java Bean e viceversa evito, se possibile, i parser SAX e DOM e cerco di utilizzare tool di mapping come SDO, JAXB o Castor.

Ad oggi Bazaar preserva la codifica manuale ma, appena possible, modificherò il codice in modo da utilizzare Castor.

Dalle premesse penso che è chiaro che Castor è un tool per il binding XML -> Java Bean e viceversa.
Lavorare con Castor è sicuramente più semplice che lavorare con DOM o SAX (in alcuni casi).

Castor utilizza un file di mapping per mappare gli element XML nelle property Java Bean. Esiste, tuttavia, una modalità più rapida che consente la generazione automatica del codice a partire dallo schema.

I seguenti tutorials illustrano entrambe le modalità.

Tutorial 1

Tutorial 2

 

Ciao a tutti i lettori,

 

in quest'ultime settimane sono stato un pò impegnato con il lavoro. Questo mi ha impedito di scrivere post su questo blog e me ne dispiace. In questo periodo mi sto impegnando molto nella progettazione UML per un prodotto nel laboratorio dove lavoro. Farò tesoro di quest'esperienza che spero di condividere presto con voi.

Appena passati questi giorni di festa mi piacerebbe parlare di alcuni tool come Castor (sto già iniziando a scrivere qualcosa nel wiki), di continuare i post relativi a Gollumix e Trouts War, iniziare a parlare di compilatori, video editing, progettazione UML (use case model, analysis model, design e implementation model) e molto altro ancora.

In attesa di tutto ciò vi auguro Buone Feste.
Salvatore 

Oggi volevo segnalarvi un articolo su Java Developer Journal inerente ad un programma Optical Character Recognition (OCR) molto semplice scritto in Java.

Un programma OCR è, in pratica, un software capace di riconoscere il testo scritto a mano.

Il programma, in realtà, riconosce solo singoli caratteri, quindi va considerato solo come un esempio.

Il programma si basa su un particolare tipo di rete neurale detta di Kohonen (dal nome del professore che l'ha ideata).

Qui potete scaricare il codice relativo all'articolo.

1. Scaricate il file .zip;
2. scompattatelo in una cartella;
3. posizionatevi nella cartella;
4. compilate il codice con il comando: javac *.java, eventuali errori di compilazione sono dovute a new line dentro le stringhe, per risolvere il problema andate sulla riga segnalata dal compilatore e mettere la stringa su un'unica riga;
5. rimuovete il file OCR.jar perchè corrotto (il file conteneva già il codice compilato);
6. eseguite il codice con il comando: java MainEntry.

Dovrebbe comparire una dialog box dove voi scrivete il carattere e il tool lo riconosce. Vi consiglio di addestrare la rete con alcuni esempi, perchè gli esempi di default non sempre si adattono alla vostra scrittura.

In quest'altro articolo potete approfondire il tema OCR analizzando tutti gli steps che un programma di questo tipo dovrebbe eseguire.

Sono felice di annunciarvi il rilascio di Bazaar 1.0 pre5.

Il war file (che contiene anche il codice) è possibile scaricarlo da qui.

Qui trovate le novità offerte da questa nuova release.

Qui potete vedere la demo del prodotto.

Aggiornamento 1 29/3/2006
Mi scuso per i links non funzionanti. Ho avuto problemi con il dyndns, sistemerò tutto nel pomeriggo.
Scusate per il disagio.

Aggiornamento 2 29/3/2006
Ora i links dovrebbero funzionare. Mi scuso ancora per il disagio. 

 

 

Oggi volevo segnalarvi quest'articolo sui meccanismi di pluggability di eclipse che considero molto interessante.

Il discorso è semplice. C'è un core con un set di extension points che espongono determinate interfacce. Chi vuole estendere eclipse descrive il suo plugin attraverso un file XML e implementa gli extension points.

Pubblico quest'articolo perchè in futuro vi illustrerò un'idea su come implementare un'architettura di pluggability per Bazaar.

Bazaar ha ereditato molto codice da JSPCart e implementa per intero un servizio di shopping online, tuttavia sappiamo che le esigenze dei negozianti potrebbero essere le più diverse.

Io oggi mi immagino un futuro Bazaar così organizzato.

CORE 
Il core avrà solo i menù, il layout, la gestione dei temi e la gestione della pluggability.

PLUGIN CATALOGO 
La gestione del catalogo dei prodotti potrebbe essere un plugin che consente all'amministratore di caricare prodotti e ai clienti di visualizzarli.

PLUGIN CARRELLO (dipende da CATALOGO)
Ci potrebbe essere poi dei negozianti che oltre al catalogo vogliono anche la gestione del carrello, che diventerà un nuovo plugin. Questo servirà ai clienti per eseguire ordini.

PLUGIN CASSA (dipendente da CARRELLO)
Ci potrebbero essere dei negozianti che desiderano dare la possibilità ai propri clienti di pagare direttamente online. I vari metodi di pagamento potrebbero essere dei plugin a loro volta.

PLUGIN PRODOTTI PIU' VENDUTI (dipendente da CARRELLO)
Un negoziante potrebbe chiedere di visualizzare i 10 prodotti più venduti dal negozio. Anche questo potrebbe essere un plugin. 

NEWS, RSS e BLOG
Un negoziante potrebbe decidere di pubblicare news, rss o un proprio blog. Anche questo diventa un plugin.

WIZARD ASSEMBLA COMPUTER (dipende da CATALOGO)
Un negoziante di computer potrebbe decidere di fornire un wizard che consenta al cliente di assemblarsi un computer velocemente. Ovviamente ci sarà un plugin apposta usato solo da questa categoria di negozianti. 

Potrei continuare all'infinito. Penso che il concetto di pluggability (che vale per qualsiasi tipo di applicazione) possa essere un valido tema di discussione per questo blog in futuro.

Oggi volevo mostrarvi una mia implementazione del DAO pattern.

Nei post precedenti vi ho fornito alcuni link con la descrizione dei J2EE patterns.

Per aiutarvi a comprendere meglio il pattern DAO, ho pensato che sarebbe stato utile illustrarvi come io l'implemento. Ovviamente non voglio esaurire con questo post tutte le problematiche di persistenza utilizzando l'approccio DAO con classi POJO, ma è una buona base di partenza. In futuro discuteremo estensioni e, magari, anche approcci alternativi.

Come al solito trovate l'articolo nel nostro wiki.

Aggiornamento
Volevo segnalarvi questo tool a pagamento chiamato Firestorm. E' un DAO generator che può generare DAO partendo da un database esistente (o definito tramite file xml). Può generare codice per diversi back end: JDBC (molti database), Hibernate, Entity Bean, etc.

Vi consiglio di scaricare la Standard Edition (se vi interessa JDBC), e provare a fare il reverse engineering di tabelle (max 3 se si usa l'evaluation license) di un database e studiarvi il codice che, secondo me, va sempre adattato alle proprie esigenze.

In questi ultimi tempi ho ricevuto alcune richeste di hosting di Bazaar sul mio server che volentieri effettuo gratuitamente, finchè non si satura la banda. Se anche voi avete amici o parenti che vogliono aprire un negozio online scrivetemi una mail a questo indirizzo.

Ogni volta che ricevo una richiesta devo svolgere alcune attività per ora non automatizzate. Il mio obiettivo è quello di deployare l'applicazione e lasciare all'amministratore l'onere di personalizzarlo.

Bazaar è personalizzabile al 95%, l'altro 5% richiede il mio intervento nelle seguenti attività:

- inserire le condizioni di vendita;

- inserire i contatti;

- inserire le informazioni del negozio;

- personalizzazione homepage (con Bazaar-pre5 lo farà l'amministratore);

Ora nella prox release metterò nella fase di amministrazione un pannello di controllo per configurare quelli che sono i parametri del negozio. Tra questi parametri ci sono queste 3 descrizioni.

Ora il testo di queste descrizioni dovrebbe essere formattato (cioè usare grassetto, links, ecc.).

Usando semplici Text Area l'amministratore dovrebbe usare codice HTML per formattare il testo, il che è una pazzia. Perchè un amministratore Bazaar dovrebbe conoscere l'HTML?

Ho pensato, quindi, che nella prox release queste text areas dovevano essere editate attraverso un editor WYSWYG. Mi sono messo alla ricerca e ho trovato questo tool gratuito: TinyMCE.

TinyMCE è rilasciato con licenza LGPL, usa javascript ed è altamente configurabile. Io non avrò bisogno di molte funzionalità, mi servirà solo: grassetto, corsivo, sottolineato, font e gestione links.

Non ho ancora provato questo tool, ma promette bene. Appena rilascierò Bazaar-pre5 (a giorni) e mi dedicherò alla nuova versione, ci giocherò un pò e vi farò sapere come è andata.

PS
Se conoscete prodotti alternativi non esitatea segnalarmeli.

Continua la nostra avventura nel fantastico mondo dei videogiochi arcade con lo step 1 di Trouts of War. Definiremo la classe principale del nostro videogioco con alcune funzionalità che di volta in volta andremo ad arricchire. Come al solito trovate l'articolo nel nostro wiki.

Nel prossimo post inizieremo a disegnare la nostra astronave.

In questo post vorrei parlarvi di uno dei problemi classici nelle applicazioni di shopping online: ricerca di prodotti in stile google.

Generalmente, per affrontare questa categoria di problemi si utilizzano search text engine scritti ad hoc o da terze parti. Uno dei search text engine più famosi per J2EE è Apache Lucene. Anche quando l'applicazione si appoggia già ad un database, è sempre sconsigliabile utilizzare questi per tematiche di search text.

Per rendere più chiaro l'uso di Apache Lucene ho scritto il seguente articolo che descrive l'uso di questo tool nel nostro prodotto Bazaar. Il codice di Bazaar con questa nuova feature non è stato ancora rilasciato, quindi consideratelo un'anteprima.

Oggi voglio presentarvi una diversa categoria di Patterns pubblicati nel famoso libro Pattern-Oriented Software Architecture: Patterns for Concurrent and Network Objects di Douglas C. Shmidt.

In quel libro vengono discussi classici problemi in ambienti distribuiti e la loro soluzione attraverso specifici patterns.

Questi patterns vengono divise in 4 categorie: cuncurrency, event, initialization, e synchronization patterns.

Vediamo ora in dettaglio ciascun pattern. In futuro avremo modo di analizzare questi patterns in maggior dettaglio cercando di capire anche eventuali utilizzi in applicazioni pratiche.

Concurrency Patterns

Thread per Session
Thread Pool
Thread Specific Storage
Leader/Followers
Half Sync/Half Async
Active Object
Monitor Object

Event Patterns

Reactor
Proactor
AsynchronousCompletion Token

Initialization Patterns

Acceptor/Connector
Service Configurator
Object Lifetime Manager

Synchronization Patterns

Double Checked Locking
Thread Safe Interface
Scoped Locking
Strategized Locking

Miscellaneous

External Polymorphism
Wrapper Facade