Maven

Già nelle scorse settimane mi era più volte capitato di leggere qualcosa su Maven... alcuni tutorial e progetti che ho analizzato lo richiedevano o facevano riferimento a questo tool, ma ho sempre evitato di "sapere cosa fosse".

Leggendo però il tutorial (anzi, vedendo la videolezione e relativi source) per l'integrazione tra GWT e Spring si è resa necessario lo studio, anche solo approssimativo, di cosa sia Maven.

Copio la definizione trovata in questa pagina:
http://www2.mokabyte.it/cms/article.run?articleId=S85-L5J-HP3-86O_7f000001_30480431_0844866c

Maven è un uno strumento "intelligente" e di alto livello per la gestione dei progetti in termini di compilazione, assemblaggio, test, deployment, e così via.

Sembrerebbe qualcosa di fin troppo evoluto per quello che sto facendo ora, anche se probabilmente diventerà interessante e utile per ciò che implementeremo. E dato che per comprendere ed utilizzare alcuni tutorial devo saperlo utilizzare, forse è il caso che me los tudi almeno superficialmente.

Attualmente sto leggendo questi articoli: Maven: best practices per il processo di build e di rilascio dei progetti in Java
Sembrano fatti bene, la prima pagina me la sono letta e più o meno capita tutta: è un introduzione a cosa sia Maven e una semplificata analisi di confronto Maven VS Ant (uno strumento di build di progetti Java)

GWT, JSTM e JSTM4GWT

In questa settimana sono riuscito nell'impresa di far dialogare GWT con JSTM4GWT (la versione per GWT di XSTM) e JSTM (la versione Java di XSTM.
Ho realizzato (e sto ampliando) un piccolo esempio per verificare se riesco ad ottenere da XSTM ciò che voglio.

L'idea di base è cercare di creare una form logica sul server, via Java, replicarla in GWT sul client, sia in via logica che come UI fisica sul browser e far comunicare il tutto in maniera semplice senza PRC.

Lo strato che fa la maggior parte del lavoro è proprio, ovviamente XSMT... si realizza la maschera (form) logica sul server via java... sul serve non serve una rappresentazione visiva (ma sarebbe immediato implementarla). Si condivide con il client questa maschera logica (attraverso appunto il dialogo JSTM e JSTM4GWT) e la si replica poi in GWT per realizzarla fisicamente sul browser, e viceversa

In questo modo ogni interazione sulla maschera fatta da un utente sul client viene replicata sulla maschera logica sul server, che può agire autonomamente in base ad ascoltatori che intercettano le variazioni della maschera logica, aggiorna la maschera logica che poi verrà replicata immediatamente sul client

Per ora, nell'esempio che ho fatto io, si replicano immediatamente sul client le modifiche fatte sulla maschera logica del server... ma non viceversa (bisogna sempre premere il tasto "commit"... questo anche per una scelta architetturale di JSTM), anche se il comportamento è non difficilmente modificabile (già parzialmente testato)

Il server riesce a capire se le modifiche sulla maschera logica sono avvenute internamente al server o dal client e quindi può agire diversamente di conseguenza.

A quanto pare sono riuscito ad ottenere ciò che volevamo... devo verificare alcuni dettagli ma forse siamo arrivati ad un livello di astrazione/interazione vicino a quello che vorremmo ottenere... anche perchè la realizzazione grafica del client può essere abbastanza facilmente svincolata da GWT e realizzata in uno dei qualsiasi 3 linguaggi supportati da XSTM: Java, .NET e appunto Java/GWT

Convenzioni sui nomi in Java

Dal sito di Java (http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html) presento qui le convenzioni per la rappresentazioni dei nomi in un progetto Java.

• Package: impotante utilizzare le convenzioni per evitare conflitti sui nomi, soprattutto nel caso di utilizzo di package importati da terze fonti.
  
  • I nomi dei package vanno scritti tutti in minuscolo.
    
  • Se si appartiene/lavora per una compagnia che ha un dominio internet, lo si usa all'inizio del nome del package, prima il "suffisso" del nome a dominio (il dominio di primo livello) poi il dominio effettivo della compagnia (il dominio di secondo livello). Nel casa dei package della Sun si ha "com.sun".
    
  • Se il nome a dominio contiene caratteri speciali non usabili nel nome del package, bisogna convertirli in underscore (per esempio se il nome a dominio è una keyword o se il nome inizia con un numero.
    
  • Se si vuole indicare un sottodominio, lo si può fare, sempre con la logica di scrivere il nome a dominio in maniera inversa, cioè primolivello.secondolivello.sottodominio
  • Si può specificare anche il nome dle progetto o della persona che ha sviluppato il package, sempre con la logica di inserirlo in fondo al nome del package.
    
  • Esempi validi sono, per esempio
    com.java
    com.apple.quicktime.v2
• Classi e interfacce: Anche in questo caso è buona norma rispettare le seguenti convenzioni
  
  • i nomi dovrebbero rappresentare sostantivi o frasi descrittive non eccessivamente lunghe
  • La prima lettera deve essere maiuscola, le altre minuscolo.
  • Se il nome è composto da più parole, vanno scritte attaccate, con la prima lettera di ognuna in maiuscolo
  • Il nome dovrebbe essere descrittivo della classe, avere un senso, una connessione al significato semantico della classe stessa
  • Sono da evitare i verbi, riservati ai metodi
  • Esempi di nomi corretti per classi ed interfacce sono:
    ClassLoader
    SecurityManager
    Thread
Dictionary
• Metodi: utile anche in questo caso rispettare le convenzioni
  
  • il nome di un metodo dovrebbe essere costituito da un vervo che spieghi l'azione del metodo stesso, scritto in minuscolo.
  • Se si vuole usare più di una parola, contenenti comunque in verbo, la prima parola deve essere minuscola e le altre avere la prima lettera maiuscola.
  • Metodi che leggono e settano una variabile, dovrebbero indicare come prima parola, rispettivamente, get e set, seguita dal nome di variabile interessata
  • Metodi che servono per ricavare la lunghezza di un oggetto dovrebbero chiamarsi lenght
  • Metodi che verificano una variabile booleana dovrebbero chiamarsi is seguita dal nome di variabile da verificare
  • Nomi corretti di metodi sono
    getV
    setV
    isV
    toV
    sommaCostanti
• Fields (non so bene cosa siano)
  
  • Names of fields that are not final should be in mixed case with a lowercase first letter and the first letters of subsequent words capitalized.
  • Note that well-designed classes have very few public or protected fields, except for fields that are constants (final static fields).
    
  • Fields should have names that are nouns, noun phrases, or abbreviations for nouns.
• Costanti:
  
  • Le costanti dovrebbero essere rappresentate da parole o frasi descrittive e/o abbreviazioni, scritte in maiuscolo, divise, se più parola, da un underscore.
  • Corretti nomi di costanti sono:
    MIN_VALUE
MAX_VALUE
    PS_RUNNING
    S_SUSPENDED
• Varibili locali e Parametri
  
  • Dovrebbero essere costituite da parole corte, o assemblamenti di lettere, sempre in minuscole, che non necessariamente formano una parola di senso compiuto
  • per esempio una variabile che contiene un riferimento all'oggetto ColoredPoint potrebbe chiamarsi cp
  • oppure buf potrebbe essere un buon nome per un puntatore ad un buffer
  • si dovrebbero evitare variabili di uan sola lettera, escludendo i cicli dove si possono usare (come la classica i) oppure se indicano un type, per esempio per convenzione si usa
    
    • b for a byte
    • c for a char
    • d for a double
    • e for an Exception
    • f for a float
    • i, j, and k for integers
    • l for a long
    • o for an Object
    • s for a String
    • v for an arbitrary value of some type

Lo switch in Java

Un'altra delle cose scoperte la settimana scorsa, che all'inizio mi ha lasciato nel panico, perchè non capivo cosa stesse succedendo, è che Java a uno switch... che funziona solo su integer...
Non conosco i moivi di questa scelta implementativa... che mi pare bizzarra... in un linguaggio dove puoi fare quasi tutto, questa è una limitazione non da poco

E a volte è proprio utile, soprattutto ai fini delal leggibilità del codice, eseguire uno switch su delle stringhe

Ok, ok, la soluzione potrebbe essere una serie di If elseif... ma ve lo immaginate un codice con una decina di elseif?
Uno schifo.

Certo, si potrebbe pure fare una mappatura "caratteri-integer", ma che barba... e poi risulterebbe meno leggibile il codice

Girovagando in rete ho trovato una soluzione abbastanza buona.
In pratica, prima di eseguire lo switch, si crea una costante Enum, elencando come contenuti enumerativi le stringhe che si vogliono usae... e poi switchare su queste

Esempio, ho una variabile stringa che può assumere questi valori "carne, pesce, dolce, contorno, frutta" e voglio creare uno switch su questa variabile sringa
Si prosegue così:

• Definire una costante enum con i valori congruenti alle stringhe che si vogliono prendere in considerazione
  
  enum portate {
  carne, pesce, dolce, contorno, frutta
  }
  
  
  
• Successivamente eseguire uno switch con un valueof(costanteenum). Il valueof fa una comparazione tra le stringhe e i valori di enum. Si può usare toLowerCase per un confronto non case sensitive
  
  switch (portate.valueOf(e.getActionCommand().toLowerCase())){
  case carne:
  bla bla
  break;
  
  [...]
  
  case frutta:
  bla bla
  break;
  }
  
  
• L'unico problema è che così si potrebbero sollevare delle eccezioni IllegalArgumentException or NullPointerException (penso che succeda se la stringa ha un valore che non ha corrispondenze nell'enum. Si possono gestire con un Try-catch
  

  
  enum portate {
  
  carne, pesce, dolce, contorno, frutta;
  
  public static portate cercaportata(String stringa)
    {
        try {
            return valueOf(strimga);
        }
        catch (Exception ex) {
            return NOVALUE;
        }
    }
  }
  
  switch (portate.valueOf(e.getActionCommand().toLowerCase())){
             case carne:
                 bla bla
                 break;
           
                      [...]
          
             case frutta:
                 bla bla
                 break;
  
            default:
                 bla bla per valori non presenti nell'enum
         }
  

  
  

Thread & company

Durante questa settimana non sono riuscito a fare molto.
Ieri ho dato il mio ultimo esame... laboratorio di sistemi operativi
Quindi un giorno di lavoro in meno, in più non sono stato nemmeno bene... insomma ho lavorato ben poco purtroppo

Comunque sono riuscito ad implementare, nella mia mini-stupida applicazione i thread

In pratica ho provato a vedere se si riuscivano ad usare in echo2 i thread e tutto ciò che riguarda la programmazione concorrente che Java mette a disposizione.

Mi sono dedicato ai thread perchè mi sono accorto, leggendo qua e la e provando con il codice, che la classe timer di swing non è disponibile in echo2.

Ma i Thread sì.

Funzionano, ne ho creati due, da far partire in momenti diversi, che aggiornato ogni secondo delle etichette di testo... un thread parte attivo con l'applicazione e s ferma all'atto dell'apertura di una nuova finestra, l'altro viceversa... viene attivato con l'apertura di una nuova finestra e si adormenta alla chiusura della stessa.

Attualmente ho utilizzato un busy waiting per gestire il controllo dello stato dell'applicazione, giusto per provare.
Lo so, non è una soluzione molto corretta, ma qui non mi serviva l'efficienza.
Ma comunque credo sarebbero comunque disponibili i monitor e gli altri sistemi di sincronizzazione di Java, senza alcun problema.

Però è emersa un'altra particolarità di Echo2... che in effetti avevo letto, ma non compreso sino in fondo...
In pratica non tutto cio che il lato server "aggiorna" viene effettivamente aggiornato lato client... la sincronizzazione avviene solo quando lato client succede qualcosa... questo per ridurre lo scambio di messaggi tra client e server per non appesantire la banda

Questo cosa comporta? che per esempio le etichette dei contatori, sebbene i contatori si tengono aggiornati lato server e sono coerenti anche lato client quando vengono visualizzati, romangono FISSI fino a quanto l'utente fa qualcosa lato client... apre una finestra, clicca un pulsante, fa uno scrolling eccetera

Infatti i miei contatori rimangono apparentemente fermi, ma alla prima interazione si aggiornano con i valori che piano piano si erano aggiornati via server...
Questo potrebbe creare dei problemi, ma esiste il sistema per rimediare, modificando la parte client del framework

Comunque, la disponibilità e il funzionamento dei thread, ha messo in risalto che gli eventuali problemi che potrebbero nascere dal bisogno di avere una parte del codice "bloccata" in attesa di qualche interazione, si potrebbero risolvere proprio con l'utilizzo dei thread... che di fatto si posson bloccare su delle risorse e/o condizioni varie con dei monitor o altre soluzioni simili