giovedì 30 agosto 2007

Promemoria: monitorare un log da remoto su Unix/Linux

Il seguente comando:

tail -f /path/del/log/blablabla.log

permette di visualizzare su console l'ultima porzione di un log, aggiornandola di continuo.

lunedì 20 agosto 2007

Alla ricerca del Santo Graal...

In questo periodo guardo con sempre più interesse a Grails. Tutto è cominciato quando ho deciso di approfondire le mie conoscenze sui web framework di tipo fronted per Java.
Da lì è partita sul serio la ricerca del Santo Graal. Quando cominci a cercare un framework per Java, sai quando cominci ma non sai quando finisci. E soprattutto con cosa finisci.

La mia esperienza attuale è limitata al lato backend dei framework. Ho usato con estrema soddisfazione Andromda e Spring, e Hibernate per l'accesso ai dati.
Anche queste scelte non sono state facili, ma in un certo senso è stato + immediato. Primo, perchè Spring e Hibernate sono standard de facto (e quasi quasi anche per diritto :-) ). Secondo, perchè dovevo cominciare a lavorare su un progetto e mi sono fidato subito del mio istinto.
Per Andromda è stato un caso, uno di quei casi che ti cambiano la vita :-)
Andromda è fenomenale, ha permesso la scrittura e gestione di un framework che supera le 150 entità, persistenti e non, con servizi di tipo J2EE, interfacciamento ai webservice.

Con i framework frontend la cosa è più difficile: ce ne sono una pletora, tutti validi e non c'è una reale direzione della comunità Java. Escludendo naturalmente Struts, che credo abbia fatto il suo tempo:
  • Click, Echo2, ThinWire: tutti ottimi prodotti, ma orientati ad applicazioni rich client piuttosto che generici siti/portali
  • GWT: uuhhmm le RPC mi danno garanzia di scalabilità?
  • OpenLaszlo: è un discorso a parte... ci giochiccherei volentieri, ma il tempo disponibile non me lo consente :P
  • Tapestry, Wicket(*): interessanti, l'idea di avere pagine HTML prive di elementi dinamici (il comportamento dinamico si ottiene con opportuni id nei tag HTML) dovrebbe ridurre le interferenze con i grafici.
    Di Tapestry però ho letto di complessità di configurazione e questo va contro la mia idea di buona progettazione. Un buon framework dovrebbe rendere semplici le cose semplici, e non troppo difficili le cose complesse. Per questo ho escluso Struts a priori.
    Il rischio è l'effetto "Inner-Platform": con lo scopo di rendere estremamente flessibile un componente di un sistema, lo si rende "un sistema dentro il sistema", complesso quanto il problema che si vuole risolvere.
    Il che a mio parere è blasfemo.
  • Stripes, ZK, Struts2, RIFE: andiamo già meglio (di RIFE non sono sicuro), c'è già una discreta applicazione dei principi di convention over configuration. Escluso Struts2 su cui non ho ben capito l'effettiva validità (e la home page che scimmiotta il Web 2.0 senza riuscirci), mi sono orientato su Stripes che mi pare abbia una comunità più ampia di RIFE e ZK. Una comunità più ampia significa bug risolti in fretta, disponibilità di articoli, faq, soluzioni a problemi complessi, tutti aspetti da tenere presente per applicazioni di produzione.
Stripes è quindi il prodotto che mi permetterebbe un approccio più moderno, ma abbastanza conservativo da non rischiare di cacciarmi nei pasticci.
Mi riferisco a portali web tipici, senza particolari richieste di interazione con l'utente. In applicazioni più tipicamente client, guardo con curiosità a ThinWire.
Ma tutto quello che è elencato (meno del 50% di tutto quello che in realtà si trova) non è affatto da scartare. L'ideale è che ogni esigenza venisse risolta con lo strumento più opportuno. In realtà si fa riferimento a quei 2-3 strumenti affermati ognuno per una certa tipologia di prodotto.

Attualmente io mi orienterei così:
  • Portale più o meno complesso, con poca logica applicativa e tipicamente web (per es. il classico sito di ecommerce): Stripes/Struts2/RIFE
  • Portale complesso, molto orientato ai dati (in realtà una trasposizione web delle applicazioni client, per es., la gestione di un magazzino): ThinWire/Click
  • Portale semplice, con logica tipicamente web anche abbastanza complessa (per es., gestione di un calendario online, o uno storage remoto con upload/download): Rails/Grails
Mi fermo qui. Ho vomitato tutto il mio giro mentale che mi ha portato a scoprire questi due progetti e ad intrappolarmi in un bivio: è vero quanto ho scritto alla fine? Rails/Grails sono veramente aggeggini con cui trastullarsi, o possono tranquillamente prendere il posto dei blasonati Stripes e Struts 2?

(*) Ricordavo male: di Wicket non mi aveva lasciato perplesso la complessità di configurazione (effettivamente Wicket è semplice), semmai la sua natura Java-centrica. Non so quanto mi convinca un portale che richieda, per ogni manutenzione, l'intervento su codice Java, con relativa compilazione, deploy ecc

sabato 11 agosto 2007

The Big Bang

Bene, anch'io nella blogosfera. Mi presento: sono un ingegnere informatico, dipendente di una società di IT nella sede di Palermo.

E' un pò strano scrivere il tuo primo post. Sembra di salire su un palco dove un pubblico che non ti conosce ascolta per un attimo ciò che stai per dire. Poichè sullo stesso palco ci sono migliaia di altre persone che già parlano, è probabile che nessuno di accorga di te, ma ti senti lo stesso tutti gli occhi addosso...

Questo blog servirà più a me che ad altri. Raccoglierò le mie idee, pubblicherò link e relativo breve commento, e spero anche di potere chiaccherare con chi condivide la mia passione informatica.

Sono attratto soprattutto dalle architetture software e dalla usabilità delle interfacce utente, non necessariamente in ambito informatico.

E per chiudere con qualcosa di spassoso e attinente, metto un link alla Interface Hall of Shame, una "irriverente" collezione (vecchiotta, per la verità) di ciofeche nelle UI. Scommettiamo che c'è tuttora qualche esempio nelle applicazioni più recenti?