Com\’è dura la professione!

12 settembre 2006

From Java to Ruby

Filed under: Java,Programmazione,RubyOnRails — lbell @ 20:13

Finalmente il libro di Bruce Tate è arrivato. Dalla prefazione leggo ‘Sapevo che Java non era la soluzione a tutti i problemi’ e fin qui nulla di strano. Ma prosegue con ‘vedevo che i visionari di Java lo stavano abbandonando man mano che riconoscevano problemi di produttività e di complessità’ e qui la cosa si fa interessante. Poi si parla di proliferazione di framework, di complessità crescente del mondo Java, mentre l’esplosione di Ruby sta conquistando gli sviluppatori con la sua rapidità di implementazione. La parola d’ordine di Ruby e Rails è semplicità e produttività.
Il libro sembra interessante e orientato alla valutazione della gestione di progetti software con i due linguaggi e rispettivi framework, proprio il tipo di cosa che può far finire una carriera lavorativa. Una lettura interessante, ma potrà cambiare il mio lavoro? Spero solo che non sia la solita agiografia; a questo mondo c’è certamente posto sia per Ruby che per Java. A Ruby però ora come ora mancano diverse funzionalità di tipo ‘enterprise’ come ad esempio le transazioni distribuite. Che il libro sia la chiave per una integrazione felice?

7 settembre 2006

Qualche divagazione su Rails

Filed under: Programmazione,RubyOnRails — lbell @ 21:02

Orm (Object-relational mapping) è un insieme di tecniche per modellare i dati residenti su database relazionali sugli oggetti dei linguaggi di programmazione object oriented. Serve a spostare la gestione dei dati in territori familiari ai programmatori di applicativi, cambiando il paradigma di programmazione, mappando dati e relazioni gestiti dal database in tipi di dato e relazioni che i programmatori sono abituati a trattare.

Dobbiamo utilizzare queste tecniche continuando a basarci su database relazionali invece di passare a motori di archiviazione object oriented adatti alla memorizzazione degli oggetti ‘da programmatori’ sia perché il database relazionale è utilizzato da tutta una serie di programmi esistenti, sia perché un ripensamento totale del motore di archiviazione è un salto nel buio per quello che riguarda affidabilità e costi senza contare che il cliente finale spesso utilizza strumenti per la generazione di report ed elaborazioni che agiscono direttamente su database.

Per ora dobbiamo tenerci due domini diversi ed utilizzare uno strato di software per metterli in comunicazione. Un grosso inconveniente è che l’interfaccia fra questi due mondi, così come viene realizzata nelle tecniche più diffuse (Hibernate ad esempio), è statica e spesso si aggiorna un modello all’insaputa dell’altro.

Un altro grosso difetto è che vi sono modi diversi di identificare le entità tra i due mondi, per non parlare della corrispondenza fra i tipi di dato. Un oggetto in Java o C++ si identifica con un puntatore o una referenza, mentre un database sfrutta il valore dei suoi attributi, ma in certi casi si può avere una sovrapposizione. Nella programmazione distribuita l’identità di un oggetto non si può più verificare tramite un indirizzo di memoria, a meno di non usare un guid. Nei database d’altronde possiamo evitare di creare una chiave univoca sulle tabelle salvo non riuscire più ad indirizzare singolarmente più record con gli stessi attributi (in questo vi sono similitudini con la meccanica statistica sull’identificazione delle particelle).

L’approccio ad attributi sul database è insoddisfacente; se consideriamo la rappresentazione di una persona possiamo utilizzare come chiave il codice fiscale, ma cosa succede se un codice fiscale che ci arriva da una autorità esterna, si rivela errato o deve essere cambiato? Cosa succede ai dati delle tabelle collegate che lo utilizzano come chiave esterna? Non sarebbe meglio che ogni tabella avesse un campo identificativo interno non assegnabile da programma? Dopotutto una persona è una persona e se riesco a distinguerle nel mondo reale anche senza conoscerne il codice fiscale perché non posso farlo anche nell’astrazione che utilizzo per modellarlo nel mio database?

Ci sarebbe da discutere parecchio di forme normali, di variazioni nel tempo dei requisiti delle chiavi primarie e così via, e qui entra in campo Rails.

Rails sta spopolando nel realizzare una mappatura tra oggetti ‘da programmatori’ e ‘da database’ ed è di uso immediato quando le tabelle sono relazionate tramite campi identificatore. Lo scopo di Rails è di scrivere meno codice possibile sfruttando una serie di convenzioni. E’ possibile utilizzare Rails sfruttando gli insiemi di attributi come chiavi, ma occorre configurare ogni relazione e questo va contro lo scopo di Rails. Quando si usa uno strumento occorre assecondarlo, non combatterlo, oppure è meglio trovare uno strumento più adatto.

L’altro problema spinoso di ORM è il mapping dei tipi di dato che non coincidono perfettamente. Ad oggi la definizione è duplice, occorre definirli sia nel database che nei programmi applicativi utilizzando le categorie disponibili in ciascun campo, aprendo la porta ad una serie di problemi di allineamento e consistenza.

Usare Rails per applicazioni di una certa dimensione ci porta a dover risolvere il problema di come gestire i campi degli oggetti. Al contrario di Hibernate, Rails fa uso del pattern ActiveRecord, quindi non esistono campi predefiniti, ma i campi riflettono il reale contenuto del database. Hibernate al contrario pretende una mappatura esplicita tra i membri degli oggetti e campi; ovviamente i dati in questo modo sono definiti due volte ed occorre preoccuparsi della relativa sincronizzazione.

 

8 agosto 2006

Ruby on Rails in MacOS X 10.5 Leopard

Filed under: Mac,Open Source,RubyOnRails — lbell @ 11:57

Tanto per non perdere l’abitudine a stare un passo avanti agli altri, Apple ha annunciato che la prossima versione di MacOSX (server e client) sarà equipaggiata con Rails. D’altronde, come si trova scritto anche nel blog degli sviluppatori di Rails, tutti i core developer utilizzano Mac e si aspettano che la piattaforma Apple diventi una delle principali piattaforme di sviluppo per gli applicativi Rails, per cui sembra proprio un amore corrisposto. Per inciso, per non scontentare nessuno, Mac OS 10.5 avrà in dotazione anche software per suppportare J2EE (Jboss e Tomcat).

2 agosto 2006

Rails o non rails?

Filed under: Programmazione,RubyOnRails — lbell @ 11:40

Dopo avere esaminato Rails, per fugare i dubbi se sia il solito fuoco di paglia che periodicamente brucia in rete o un reale strumento di lavoro, ho deciso di metterlo alla prova nel solito progetto inutile (GPL) di prammatica in questi casi, nella fattispecie un programma per gestire l’inventario di computer e servizi. Inutile dato che ogni ditta gestisce già un registro di tali beni, anche se magari poche lo hanno realizzato con Rails. Per ora sono alle prese con la sintassi del linguaggio (Smalltalk?) e delle magie convenzioni del framework.

Rails serve per progetti complessi? Lo si può imporre ad un gruppo di lavoro? Rails è basato su magie convenzioni. Portare una serie di sviluppatori ad essere esperti di magia non è banale, soprattutto quando non esiste nemmeno un libro in italiano su Ruby, mentre di Visual Basic, ASP.net e C# sono pieni gli scaffali delle librerie (lo so, sto mischiando il linguaggio con il framework, ma il confronto lo si fa a 360 gradi). Manca inoltre un designer visuale, e questo bene o male è dove tutti gli ambienti Open Source si scontrano con il mondo Microsoft.

Comunque i progetti inutili servono per chiarirsi le idee anche su questi argomenti.

5 luglio 2006

radrails, IDE per Rails

Filed under: Mac,RubyOnRails — lbell @ 20:06

Ho scoperto (!) un IDE per Ruby on Rails basato su Eclipse: radrails (www.radrails.org). Multipiattaforma, open source (cpl) e soprattutto comodo. Per esempio con ctrl+shift+V si passa automaticamente dal metodo del controller alla relativa vista. I difetti? E’ basato su Eclipse 🙂 , il che significa lentezza, e memoria consumata, ma questo naturalmente dipende molto dal computer dell’utilizzatore. Funziona perfino con kaffe .

Sempre in tema di scoperte: lanciare gem_server (da linea di comando) fa partire un server web che espone di default all’indirizzo localhost:8808 (la porta e’ configurabile) la documentazione delle ‘gemme’ installate per un comodo browsing offline.

11 maggio 2006

Java vs Ruby (J2EE vs RubyOnRails)

Filed under: Java,RubyOnRails — lbell @ 21:32

La filosofia di Ruby e Java e' opposta ed i loro framework più famosi (Rails e J2EE se e' corretto confrontarli dal punto di vista operativo) lo testimoniano. In Java ogni energia e' dedicata a gestire la vita degli oggetti di base di cui si occupa a partire dall'infrastruttura, alla sicurezza, all'autenticazione, al deployment. Java costruisce una architettura di tipo enterprise in cui si può pensare, rispettando una serie interminabile di specifiche, di rendere indipendenti e sostituibili gli ambienti di produzione di un componente da quello di installazione e di funzionamento tanto da lasciar utilizzare diversi compilatori e application server anche se la pratica dice che le cose non sono mai così semplici. Il prezzo di questo meccanismo e' la presenza di una quantità di files di configurazione che diventano un incubo da controllare e manutenere e l'uso obbligatorio di IDE o strumenti di automazione dei dettagli delle fasi di configurazione dei componenti. Con J2EE assume importanza la figura dell'integratore di sistemi il cui scopo e' di configurare e legare fra loro i vari componenti.

La configurazione e' quanto più possibile separata dagli oggetti su cui deve operare e cio' ha una sua importanza in termini di complessità. RoR al contrario sembra fatto apposta per costruire programmi in modo veloce. E' pieno di convenzioni di tutti i tipi e la configurazione viene posta quanto più vicino possibile agli oggetti.

Le relazioni fra i models vengono vengono inserite non in un file di configurazione in balia dell'integratore, ma nei models stessi. Ogni aspetto del framework e' pienamente configurabile ma e' tutto studiato per intervenire il meno possibile, utilizzando generatori di codice e convenzioni basate su corrispondenze tra nomi delle classi e degli oggetti su database e files.

Le due filosofie di base sono cosi' diverse da far ritenere i due ambienti come complementari. A Ruby probabilmente manca un ambiente di tipo enterprise, con tutto quello che comporta (transazioni distribuite ecc. ) con varie funzionalità che Java e .Net hanno acquisito con il tempo e con uno sforzo di design non indifferente. Un ambiente di questo tipo tuttavia spesso non e' indispensabile nel caso di siti di dimensioni medio-piccoli in cui quello che conta e' minimizzare il tempo di sviluppo e di consegna. Un punto a favore di Ruby e' che la sua concisione aiuta il programmatore a fare meno sforzi mnemonici nel ricordare i dettagli degli oggetti su cui lavora, di contro le trappole tese dalle numerose convenzioni utilizzate, sono insidiose.

Blog su WordPress.com.