Pages
Categories
Archives
Links
Terracotta for Spring:
Ecco le slides dell’ultima presentazione fatta allo Spring Meeting 2008 il 14 giugno a Cagliari
Grazie a Massimiliano Dessì per l’invito in sardegna, stupendo posto di pace.
La presentazione ha avuto un enorme successo, si sono cominciati gia a vedere i primi iscritti al gruppo it_terracotta@yahoo.com
Posted by Simone Federici as Seminari at 9:34 AM CEST
Terracott DSO:
A torino, 20 ottobre 2007 per il Javaday ho presentato questo seminario su Terracotta.
Soluzione opensource per il clustering a livello di JVM.
Soddisfa i requisiti di scalabilità e affidabilità.
Clustering trasparente a livello applicativo.
Fa interagire le applicazioni distribuite come se fossero su una unica JVM.
In una JVM i threads interagiscono gli uni con gli altri attraverso il cambiamento degli oggetti residenti nell’HEAP e attraverso le primitive concorrenti. (‘synchronized’ keyword, wait(), notify() e notifyAll()).
Terracotta estende il loro significato per una sincronizzazione distribuita.
Ho scritto anche un articolo su terracotta “http://www.aldaran.org/press/java/terracotta-dso/”
Inoltre ho aperto un gruppo di discussione su yahoo
http://it.groups.yahoo.com/group/it_openterracotta/
Clicca qui per iscriverti a it_openterracotta
Posted by Simone Federici as Seminari at 4:23 PM CEST
Per la Eclipse conference ho tenuto un seminario su come integrare maven con eclipse, l’idea era quella di consigliare Maven come strumento di gestione del ciclo di vita dei progetti opensource.
Ecco le slides del seminario Maven2
Presto metterò il link alla presentazione su youtube.
Posted by Simone Federici as Seminari at 1:09 PM CEST
Nell’ultimo anno mi son
o inbattuto in un progetto opensource, Terracotta, molto interessante.
Dopo numerosi studi e applicazioni di esempio, ho deciso di seguire un corso organizzato da loro per approfondire l’argomento.
Ho postato i miei appunti in un articolo tecnico.
Posted by Simone Federici as Post at 12:15 AM CEST
L’ho finalmente ritrovata,
nel 1999 per l’esame di sistemi operativi, pubblicai sul sito dell’università il mio primo progetto Java multithread (jdk 1.1.8)
Scambio di messaggi a lunghezza variabile
Posted by Simone Federici as Post at 3:58 PM CEST
La rivista americana Forbes ha stilato una classifica sui mercati immobiliari più sopravvalutati del mondo e sorpresa, al secondo posto, prima di città come Londra e New York, c’è Roma.
Case, classifica di Forbes 26-08-2007
Posted by Simone Federici as jokes at 9:41 PM CEST
Il bejug, java user group del Belgio, ha annunciato il tema del javapolis 2007. Dopo 30 anni dal IV episodio, Star Wars incontra il Javapolis.
Chissa cosa stanno architettando per questo evento che sembra diventare sempre più ricco di spunti originali.
Posted by Simone Federici as Eventi at 9:48 PM CEST
Esistono 2 tipi di eccezioni, Checked e Unchecked.
Le Checked Ex. (ossia controllabili) sono prevedibili, ad esempio invalid input, database error, ecc…
le Unchecked Ex. rappresentano invece degli errori che avvengono a runtime (potremmo definirli dei difetti del programma). Spesso sono causate da errori o dimenticanze di programmazione, o errato modo di usare un proprio oggetto/metodo.
E’ importante programmare usando il minimo possibile le eccezioni, la loro gestione impiega una grande quantità di CPU, memoria e risorse macchina.
Ogni qualvolta è necessario gestirne una, stabilire a chi spetta la sua gestione è importantissimo.
La domanda da porsi è: “chi conosce il come e chi conosce solo il cosa…”
E’ chiaro che delegare la gestione (catch) di una eccezione ad un componente che non conosce l’implementazione implica la creazione di un accoppiamento di troppo.
Un esempio nella vita reale potrebbe essere: chiedo a un professionista di ripararmi la lavatrice, dopo qualche giorno torno e lui mi risponde che il suo bancomat è scaduto.
E’ chiaro che questa risposta non ha senso, ma proviamo a ricostruire cosa è successo: andando a comprare i pezzi necessari per la lavatrice, non è riuscito a pagare perché aveva il bancomat scaduto.
Se tentiamo di modellare questo evento, ci accorgeremmo che l’eccezione “Bancomat scaduto” non doveva arrivare a me, (come lo gestisco?), il professionista avrebbe dovuto filtrare l’eccezione e dirmi, “il pezzo non è ancora disponibile”. (Legge di Demetra)
Se non è Chiaro, la SQLException in una jsp non ci deve arrivare!
Nella modellazione, quindi, è fondamentale impiegare le Checked Ex. in modo molto attento. (valgono tutti i principi OOP)
L’uso delle Unchecked exception (le runtime) o meglio catturare una eccezione di runtime,
in un sistema perfetto non dovrebbe essere mai fatto. dico in un sistema perfetto perche poi per pigrizia spesso e volentieri se ne abusa.
essendo delle eccezioni non dichiarate nelle firme dei metodi, queste eccezioni sono in grado di attraversare tutti i tiers della applicazione fino ad arrivare all’utente. Giusto pensare un sistema per non far vedere l’errore all’utente finale (lo sviluppatore invece le deve vedere).
Quando si crea una firma di un metodo, senza implementarlo, la soluzione migliore è fargli rilanciare una Uncheked Exception tipo “throw new NotYetImplementatedException()”
Insomma, queste eccezioni esulano dalla progettazione di un software, sono molto potenti e anche molto pericolose se lasciate proliferare. Esse dovrebbero sparire nella messa in esercizio.
Citazione dell’anipattern “programming by exception”
Una volta in Sud Africa ho visto un MVC che faceva uso di Una ForwardException
dove il getMessage() restituiva la url della jsp dove forwardare….. esempio lampante di
antipattern 
NON FATELO…
Posted by Simone Federici as Post at 6:21 PM CEST
