Certificazione SCJP 5.0, la mia esperienza.

Ciao, volevo condividere con voi la mia esperienza su quello che è un passaggio cruciale della carriera di ogni sviluppatore Java, la certificazione Programmer.

Ho cominciato da Marzo 2007 a prepararmi per tale obiettivo; googlando e sotto suggerimento dei colleghi ho trovato le informazioni principali su argomenti e libri su JavaRanch il sito di riferimento per le certificazioni.

Consiglio spassionato è di registrarsi e di utilizzare il forum per qualsiasi domanda/dubbio : troverete persone disponibili adi aiutarvi e a consigliarvi.

Il libro che ho utilizzato per prepararmi è questo, libro di riferimento per la certificazione.

La mia esperienza di Java risale al “lontano” 2002, anno in cui all’università cominciavo a cimentarmi con i primi progetti. Utilizzo quindi accademico fino a Novembre 2004 quando ho intrapreso il lavoro e ho cominciato ad applicare sul campo quello che avevo imparato.

Il mio training è avvenuto all’interno di un gruppo di sviluppo della società per cui lavoro, e quindi ho colmato le lacune di programmazione/sviluppo con l’apprendimento sul campo.

Quando ho intrapreso lo studio per la certificazione (marzo 2007) quindi avevo circa 2 anni e mezzo di esperienza lavorativa su Java, di cui circa 6 mesi su JEE e il rimanente su JSE.

Il primo approccio è stato misurare la mia preparazione rispetto al requisito dell’esame con degli esami mock: e devo dire che mi sono sentito abbastanza impreparato rispetto a quanto richiesto. Se avessi dovuto dare quindi l’esame senza preparazione ma solo con la mia esperienza lavorativa sicuramente non l’avrei passato.

Ho quindi cercato di pianificare una roadmap per la preparazione: come consigliato dagli utenti di JavaRanch, studiando solo nei week-end, ho stimato il tempo necessario in 4/6 mesi e devo dire che la stima è stata accurata.

Più studiavo e più mi sentivo di aver costruito una preparazione lavorativa che teneva conto solo delle cose che mi servivano per raggiungere l’implementazione dei requisiti.

A forza di utilizzare framework vari, applicare design patterns e cercare di disegnare una architettura modulare che tenesse conto dei principi OO mi ero perso le basi.

E in effetti questa è stata l’occasione giusta per riscoprirli.

Gli innumerevoli vantaggi a livello tecnico sono rappresentati dalla maggiore padronanza di tutte le sottigliezze che stanno dietro a un linguaggio di programmazione e in particolare una conoscenza approfondita di argomenti essenziali quali:

  1. IO e Serialization
  2. Collection framework
  3. Generics
  4. Inner Classes
  5. Threads e concorrenza

Il mio approccio per lo studio è stato quello di studiare ogni capitolo facendo i test per argomento che si trovano sul libro di Kathy Sierra. Dopo di che negli ultimi 10 giorni oltre a un ripasso generale ho cominciato a fare prove di esame.

Mi sono appoggiato al kit della Whizlabs che ho trovato ottimo come soluzione: si compone di vari moduli tra cui:

  1. un esame diagnostico per la valutazione della preparazione pre esame
  2. 4 esami pratici di 72 domande sullo stile di quello della Sun
  3. 1 esame finale

Devo dire che costa leggermente, ma sicuramente è uno strumento essenziale per prepararsi adeguatamente.

Ora come passo “obbligato” spero l’anno prossimo di poter proseguire con una delle certificazioni successive; pensavo alla SCJD che tra tutte sembra la più versatile.

Se state leggendo fino a qua probabilmente è perchè cercate informazioni utili sulla preparazione e quindi non mi rimane altro che augurarvi buono studio e in bocca al lupo per la Programmer :)

Mazi

Visual Studio 2005 e unit test

Dopo circa un mesetto di utilizzo di tecnologia targata Microsoft volevo condividere qualche punto.

Visual Studio 2005 è un gran bell’ IDE, molto integrato, facile da usare, user-friendly e molto potente; C# d’altronde è molto simile a Java come linguazzo OO, con delle feauture molto interessanti.

La prima pecca che ho potuto notare è che non ha nessun framework integrato per fare unit test, e questo è male!!  O meglio ne esiste solo una versione che integra un ambiente per i test unitari (la Team Edition).

L’inizio dello sviluppo è stato molto pittorico: molti “just click next” e poco codice a manina,  e quindi non era una priorità testare unitariamente il codice prodotto dal framework .NET.

In questa ultima settimana fortunatamente avendo preso un pò il controllo degli strumenti e padroneggiando di più gli strati di codice prodotti dal magnifico “maghetto” targato M$, ho ripreso a essere io il protagonista dello sviluppo, e per ovvi motivi mi sono sentito in braghe di tela quando non potevo fare test unitari.

Quindi ho speso una giornata a cercare e valutare la configurazione migliore in Visual Studio 2005 per crearmi un ambiente adatto e confortevole per raggiungere questo obiettivo.

Sono partito da NUnit che è il porting di JUnit per .NET. Bisogna scaricarsi le librerie e poi creare una solution che faccia riferimento a nunit.framework.

Il core di NUnit è molto interessante e assomiglia a quello di JUnit 4 in cui i Test sono evidenziati tramite le assertion; qua invece che le assertion si usano altre strutture che consentono di decorare con dei metadati le classi di Test:

    [TestFixture]
public class BankAccountTest

[SetUp]
public void Init()
{
bankAccount = new BankAccount(“Mazi”);
}

[Test]
public void InitTest()
{
Assert.AreEqual(0.0, bankAccount.Balance);
}

Come si può vedere si usa la direttiva TextFixture per definire una classe di Test, e altri attributi specifici per Test, SetUp, TearDown ecc. ecc.

NUnit non è integrato in Visual Studio, e quindi una volta creata la solution di test (la dll o l’exe) bisogna usare la gui di NUnit standalone per eseguire i test: questo può risultare scomodo per chi è abituato a un ambiente orientato ai test unitare come Eclipse.

Purtroppo nel modo M$ ci sono, oltre a NUnit, altri vari framework di unit test:

  1. CSUnit
  2. Zanebug
  3. MBUnit

Ognuno ha i suoi vantaggi, e ognuno dice di essere il migliore :D

Per ora proverò l’accoppiata NUnit e TestDriven.Net, diciamo che il desiderata sarebbe avere test unitari e un plugin per Visual Studio integrato in modo da non dover usare un programma esterno per testare, ma fare tasto destro, run test :)

Mazi

ClassLoader.loadClass() e Java 6.

E quale giorno migliore del mio ultimo di lavoro su Java per imbattermi in un baco da 10 e lode? :D

Praticamente stavamo provando a far girare la TestSuite di Jade su Java 6 (glassFish) e ci siamo scontrati su questo problema, come mostrato nel piccolo esempio qui sotto:

ClassLoader classLoader = ClassloaderTest.class.getClassLoader();

Class<?> className = classLoader.loadClass(“[Ljava.lang.Object;”);

dove [Ljava.lang.Object; è la rappresentazione sotto forma di stringa di un array di Object, come restituito se si esegue questo codice:

new Object[0].getClass().getName();

La cosa bella è che il codice sovrastante funziona con Java 5 ma non con Java 6.

Googlando un pò ho scoperto che questo interessante articolo che spiega l’arcano.

Il nocciolo della questione è che il metodo ClassLoader.loadClass di Java 5 era più lasco di quello di Java 6 che invece implementa in maniera più restrittiva la Java Language Specification.

Infatti loadClass è definito per funzionare sui “binary names”, che la JLS definisce come classi e interfacce, ma non come array. Se si vuole far caricare al ClassLoader una classe s, e s potrebbe essere la rappresentazione sotto forma di stringa di un array, allora bisogna usare Class.forName(s, false, classLoader).

Mazi

Last day with Java (for a while)…

Ed ecco giunto il mio ultimo giorno presso il nostro grande gestore di TLC sul progetto che mi ha visto coinvolto negli ultimi due anni.

Il bilancio è molto positivo: ho  lavorato in un grande team formato da persone motivate che hanno condiviso gli stessi valori e obiettivi, in cui la parte umana è stata essenziale per creare coesione e affiatamento.

Da lunedì mi si prospetta una nuova ed entusiasmante avventura, sempre presso lo stesso cliente come descrivevo nell’ultimo post.

Un grazie particolare a tutti quelli che mi hanno dato una mano a crescere professionalmente, anche se hanno dovuto più volte sorbirsi la mia testardaggine e il mio orgoglio ^_^.

Stay tuned.

Mazi

Microsoft .NET vs Sun JEE

La mia esperienza presso il nostro grande cliente di TLC italiano sta per volgere al termine, o almeno la mia permanenza nel progetto su cui ho lavorato negli ultimi due anni.

Per l’estate infatti il sistema dovrebbe vedere l’estensione su territorio nazionale ed ovviamente il budget è stato spostato dallo sviluppo verso l’esercizio, con conseguente taglio sul task di development che passerà da 6 persone (1 interna + 5 consulenti) a 1 persona (1 interna) entro giugno.

Ora sembra che mi si presentino due scenari completamente diversi per ambito e tecnologie utilizzate:

Uno presso lo stesso cliente basato su tecnologia .NET con l’utilizzo di RFID e dispositivi mobili basati su Windows Mobile; l’altro presso un altro cliente basato su tecnologia JEE, Oracle ADF, JSP con una architettura tradizionale N-tier.

Le due prospettive sono abbastanza agli estremi e sicuramente la scelta finale coinvolgerà solo in parte la mia propensione per una o l’altra. Ciò non toglie che vorrei chiedere un consiglio a chi legge e a chi ha sicuramente più esperienza della mia.

Il primo progetto sicuramente mi permetterebbe di toccare con mano un mondo mai sperimentato prima per sviluppare (Microsoft e dispositivi mobili) e potrebbe essere un vantaggio in termini di crescita professionale (la vedo solo un pò dura fari girare Visual Studio su Kubuntu :D).

L’altro mi riporterebbe indietro di circa due anni alla mie prima esperienza lavorativa, quando cominciai col mitico dream team. Dovrei rimettere le mani in pasta con Jdeveloper, BC4J, JSP+JSTL e ambito Java Enterprise Edition, temi su cui mi sono decisamente arrugginito…

Su google fight indovinate chi vince tra le due piattaforme? :D

E buon 2007 a tutti….

… e già, vacanze di Natale finite anche per quest’anno.

Meno male ke sono riuscito a farmi 9 giorni di riposo dal 30 al 7, che poi tanto di riposo non sono stati…..

Per i curiosi ho trascorso come sempre questo inizio anno in montagna e, baciato dalla fortuna, ho pure goduto della nevicata dell’1 sul 2.  Infatti all’alba del 31 con 12 gradi a mezzogiorno e montagne brulle cominciavo leggermente a preoccuparmi, ma poi fortunatamente abbiamo ricevuto una manna dal cielo e così via, 3 bei giorni sulla neve il 2, il 3 e il 6 (riposo tra due surfate e l’altra.. ^_^).

Ovviamente si può vedere qualche foto su flickr.

Saluti a tutti e buon inizio 2007 :)

Mazi

RandomAccessFile.setLenght, Linux e VFAT.

Nel mio lento ma continuo passaggio a Linux come ambiente di sviluppo (oltre che sistema di tutti i giorni)  mi imbatto spesso in problemi vari di convivenza dei due sistemoni (Micro$ e Linux).

Praticamente usando una modalità dual boot per poter switchare in modo trasparente da uno all’altro mi sono configurato una partizione FAT32 di condivisione per poter modificare e aggiornare a piacimento ogni file.

Per poter utilizzare Eclipse sullo stesso workspace quindi ho spostato la mia area Develop (che contiene tutti i workspace di Eclipse)  sulla sopra citata partizione, in modo che anche se non committo sul repository degli sviluppi parziali, nel caso di switch sono completamente aggiornato con le mie ultime modifiche.

Peccato che tutto funzioni benissimo, tranne il fatto che nel task di ant del setup della piattaforma di test, ci sia un modulo che non posso toccare che fa riferimento a questo pezzo di codice:

RandomAccessFile randomAccessFile = new RandomAccessFile(file, “rw”);

randomAccessFile.setLength(…);

Bene peccato che questo “inutile” e ingenuo pezzo di codice manda in eccezione la VM di linux in determinate condizioni con questo bellissimo stacktrace:

java.io.IOException: Operation not permitted
at java.io.RandomAccessFile.setLength(Native Method)
at file.TestLenght.main(TestLenght.java:20)

Googlando un pò ho scoperto che l’arcano è che il filesystem vfat non supporta il settaggio della dimensione dei file, che non è una sorpresa secondo qualcuno visto che non supporta nemmeno i sparse files.

Ho trovato anche una bella discussione a riguardo sui gruppi di google.

Sembra che la libreriadi Java IO sotto Linux usi ftruncate per espandere un file, e questa modalità funziona su tutti i filesystems tranne VFAT.

Visto che Win32 supporta  lo stesso metodo sui filesystems FAT l’implementazione sotto Linux dovrebbe trovare qualche altro modo per espandere la dimensione di un file sotto VFAT.

Quindi visto che non posso mettere mano a quel codice di utilità non mi resta altro che migrare il mio workspace sotto ext3, e ovviare al problema eliminando la causa: non sviluppare più sotto Windows :D

Mazi

Follow

Get every new post delivered to your Inbox.