Alepuzio

DEBUG SU QUERY IN JAVA

Come qualunque sviluppatore J2EE sa esistono due modi per eseguire una query SQL in JAVA:

1. Statement: l'oggetto di questa classe ha la query definita più o meno staticamente e la si esegue con il metodo execute() senza parametri aggiuntivi.


2. PreparedStatement: se la query deve essere ripetuta più volte, eventualmente modificando i parametri, l'oggetto di questa classe deve settare i vari parametri tramite i metodi setString(x,y), setDate(x,y), setBoolean(x,y) etc in base al tipo di parametro, al posto del parametro (primo->1, secondo->2, etc) ed alla variabile che contiene il valore da inserire (indicato con y). Lo stesso effetto si può ottenere con lo Statement tramite concatenazione di stringhe ma la query risulta più lenta da eseguire (e questo non è bello in ambito web).

(So che la mia spiegazione è penosa: per una migliore vedete la documentazione della SUN nei package java.sql.* e java.sqlx.* )

Sotto l'ambiente di sviluppo Eclipse, quando debuggando dovete sapere che query state eseguendo in quel momento ed avete un PreparedStatement dovete andare nella finestra delle variabili (o nella schermata INSPECT - CTRL+I da tastiera) ed aprire i nodi seguenti dell'albero della struttura:

Formiche informatiche



Caratteristica propria dell'informatico di ogni livello è la pigrizia. Pigrizia che spazia dallo "non scrivo il manuale d'uso che tanto poi l'utente fa un po' di prove e se la sbriga lui" allo "sto digitando troppi tasti nello scrivere il codice  che in buona parte fa sempre le stesse cose: fammi pensare se posso velocizzare qualcosina".

Nel primo caso l'utente bestemmia e non usa/compra il software realizzato dal pigro informatico, nel secondo l'informatico si sbriga a fare le cosette solite evitando noia ed errori derivanti e si dedicare ad attività più produttive (come pensare al nome da dare alla nuova macchinetta del caffè delle pause).

Ricordate questo post? Il programmatore non è un novello Mago Merlino che tramite invocazioni di entità infernali incatena spiriti maligni al computer costringendoli a compiere le azioni che l'utente comunica mediante mouse e tastiera, ma segue un percorso logico e lineare per costruire il software (anche se a mio parere è meno produttivo e più ricco di incognite di un bel Sabba in una notte di luna piena con un po' di hardware in un calderone bollente: purtroppo non ho ancora i benchmark di quello che esce fuori così ma l'istinto mi suggerisce qualcosa).

Tale percorso è:

1)scrittura del codice sorgente: il programmatore scrive il programma mediante regole semantiche e sintattiche di un certo linguaggio di programmazione(C, C++, Java, PERL, et cetera et cetera);

2)compilazione: usando programmi opportuni detti compilatori (gcc, g++, javac) il codice sorgente viene trasformato in codice che può essere compresoed eseguito dalla macchina. (Per la verità esistono linguaggi che permettono di non compilare necessariamente il codice ma sono un caso più particolare degli altri);

3)esecuzione:si invoca un programma specifico per far eseguire il programma compilato nella fase (2): nel mondo Windows in genere si clicca sull'opportuna icona si scrive il nome su "Esegui applicazione" o su command line.



Quando i programmi sono piccoli il procedimento non ha grossi intoppi (a parte l'errore manuale); quando cominciano ad esserci dimensioni maggiori e quindi complessità maggiore del programma, con varie dipendenze da file di sistema ed interdipendenze, allora la cosa comincia quantomeno a farsi lunghetta.



Per i programmi scritti in C/C++ (due linguaggi che hanno fatto grande la produzione del software) si ricorre ad un programmino chiamato make. Per eseguirlo basta scrivere in un file (makefile) i nomi dei vari file con alcuni riferimenti ad altri file e lanciarlo: lui si occupa di compilare tutto correttamente (ok, sto banalizzando ma solo per scopo divulgativo).

Questa utility però ha qualche svantaggio:

1)non è stato progettato per essere cross-platform: cioè la sua esecuzione funziona su GNU/Linux non è detto che funzioni su MacOS, nè se va qui è detto che vada su Windows.

2)Ergo ogni sistema ha il suo che differisce dagli altri per pochi dettagli cui nessuno pensa finchè non ci pensa dopo ore spese a capire "perchè sto coso non va su questo coso mentre va su quell'altro coso?" non esplicando però se per coso si intenda "sistema operativo", "computer" o "servitore di Azarot Principe dell'Inferno" (la terza è impossibile perchè per ipotesi di questo discorso abbiamo scartato l'idea di chiamare altri esseri viventi all'interno del processo produttivo: da un lato ci complichiamo la vita, dall'altro non abbiamo a che fare con manodopera esterna e quindi con sindacati vari)



Insomma, con make possono esserci complicazioni inutili e dispendiose. A ragione di ciò un programmatore Java, James Duncan Davidson, ha deciso di creare un nuovo sistema di compilazione chiamato ANT ("formica" in inglese).

Quali sono i vantaggi?

1) Il file su cui scrivere le istruzioni è un file XML valido (build.xml)anzichè di testo normale. Ci sono alcuni svantaggi in generale con XML ma tra i vantaggi è multipiattaforma per cui non ci si deve preoccupare di cambi di piattaforma;

2) ANT è scritto in JAVA, per cui se uno si vuole creare le sue estensioni poi può portarle in qualunque piattaforma senza doverle ricompilare.

3) E'meno complesso scrivere un build.xml che un makefile;

4) Deo gratia, molti ambienti di sviluppo software lo integrano nativamente: nel caso iellato ci sono i plugin che permettono comunque di usarlo.

Eclipse per esempio lo supporta nativamente, NetBeans non so.



A tempo molto perso ho creato una specie di cheatsheet, cioè una guida rapida per consultazione nella creazione di un build.xml. Spero possa essere utile: scaricatelo in pdf se non usate OpenOffice o se pensate che non lo modificherete.

Lo scarico è libero, gratis e la licenza è una Creative Commons BY-SA.

Il file è nel mio MediaBlog.



Alla prossima e happy building!! ;))

Accessibilità, perchè?







Salto nel mondo reale.



Qualcuno di voi che ha non ha handicap fisici si è mai recato in qualche posto in cui ci dovevano essere dei particolari punti riservati a chi non è altrettando fortunato (per esempio rampe tra strada e marciapiede o ascensori invece di sole scale) ed invece non c'era nulla o al massimo qualcosa fatto veramente male?



Avete dunque mai pensato che il mondo fisico è imperfetto mentre quello creato dai prodotti della mente  - che ci costruiamo noi con degli strumenti - è ottimo? 



Pensate che nel mondo astratto, esangue, libero dell'informatica e del pensiero non ci sono i problemi del mondo reale per il semplice motivo che il browser annulla le differenze del mondodi quaggiù?



No, mi dispiace deludervi. Anzi, spesso è pure peggio.



Mi spiego.



Voi che avete sicuramente più spirito di osservazione di me avete sicuramente notato nella barra dei link, alla sezione aggregatori, un banner rettangolare animato in cui c'è scritto che i CAPTHA ottici sono una barriera architettonica.



Esistono infatti degli utenti di Internet ciechi o comunque con forti problemi nel vedere (come Perla Scandinava); loro non usano i browser più diffusi (Internet Explorer, Mozilla e varianti, Epiphany, Links, w3m, Nautilus, Opera e chi più ne ha più ne metta) ma dei speciali programmi che permettono loro di navigare ed esaminare le pagine internet pur senza vederle (immagino si usa qualche tipo di interazione vocale, così di prima batttuta).



Quando funziona questo? Quando una pagina Internet è scritta col codice adatto, bene e chiaramente.



Quando funziona questo? Ora di più, prima mai o quasi.



Perchè? Legge dell'"Astrazione che fa Acqua" di Joel Spolsky, ovvero "Ma quando mai una ciambella esce col buco?!!".



Io sono uno sviluppatore, scrivo codice, mi piace usare strumenti poco amichevoli (come ViM o Emacs) per fare le mie cose informatiche, tra cui le pagine WEB.



Altri no, ma vogliono scrivere comunque pagine web. Va bene, si supplisce a questo desiderio usando degli appositi programmi come NVU, OpenOffice, MozillaComposer e FrontPage.



Accade che questi programmi, visto che sono di aiuto a gente che non sa nulla di come fare una pagina, devono gestire molti possibili creazioni e ricorrino spesso a trucchetti vari nella pubblicazione delle pagine per avere qualcosa di funzionante.



Inoltre alcuni browser (Internet Explorer, tanto per cambiare) per qualche ragione codificano a modo loro le pagine che non sono corrette nel codice HTML; questo comporta che esistono dunque pagine corrette e pagine scorrette ma che sono comunque visibili tranquillamente.



A prima vista può sembrare un vantaggio - "giusta o sbagliata la forma, è la sostanza che conta" - ma questo comporta anche che in pratica pagine scritte in cattivo HTML funzionino con IE ma siano sballate con altri browser.Purtroppo è difficile scoprire i problemi per chi non è addentro al settore perchè tante cose sono a lui invisibili tranne quando succedono i casini; in quel caso poi la reazione standard (e sbagliata) è "Non capisco nulla di compute, sono veramente difficili!".



I programmi speciali che ho citato prima hanno problemi perchè si basano sull'ipotesi che il codice delle pagine sia quantomeno corretto; e questo non succede questi programmi si trovano a dover leggere cose ondeggianti tra l'errato, il senza senso e l'incompleto.



Pertanto questi programmi - non potendo leggere correttamente la pagina - trasmetteranno informazione inconsistente all'utente. Se egli non può vedere, di grazia come riesce a superare l'ostacolo?



La Rete va navigata: se chi naviga si trova in una coltre di nebbia e senza bussola che può fare?



Un esempio: le tabelle.



A parte l'uso sconsiderato che ne fa certa gentaglia che è solita considerare una pagina come una tabella dove gli elementi sono le parti della pagina e che dunque ignora le disposizioni STANDARD ed INTERNAZIONALI sulla necessità di usre la tabella SOLO per presentare dati e NON per impaginare... a parte questo, molti si dimenticano di mettere tag specifici per facilitare lo scambio di informazioni.



Il tag caption serve per titolare una tabella: porca miseria, usate quello invece del solito h1 o simili: è fatto apposta!



Altro esempio: i link.



Quando scrivete un riferimento ipertestuale o un'immagine, nel codice inserite anche un tag apposito (alt mi pare che sia) che permette di inserire una descrizione in linguaggio umano di quello a cui punta il link o quello che descrive l'immagine.



I caos che nascono dai frame li racconterò un'altra volta perchè impongono problemi non indifferenti anche alle nuove tecnologie come Ajax, nate anche per una migliore usabilità dei siti.



C'è poi un ulteriore problema, legato però allo stile di una pagina: se non c'è contrasto sufficiente tra colore del testo e colore dello sfondo le persone affette da pratanopia (difficoltà a distinguere i colori o, nei casi peggiori, capacità di distinguere solo giallo, marrone e blu e grosse difficoltà con rosso e verde), da  non leggeranno nulla, per loro sarà un solo colore.



Soluzioni automatizzabili?



Per ora esistono dei filtri come Colorblind Web Page Filter che permettono di simulare l'effetto della combinazione sfondo-colore e dunque grosso modo il designer può immaginare i problemi delle sue creazioni; ma queste sono soluzioni perziali.



Il W3C consiglia di non affidarsi al solo colore: un link dovrebbe essere blu e sottolineato, un pulsante dovrebbe avere una scritta rossa e un bordo spesso, etc. (1)



In generale la situazione migliore è presentare il sito ad un gruppo di 3-4 persone e chiedere cosa vedono e in cosa hanno difficoltà.



Mettere i vari tag di descrizione in immagini e riferimenti ipertestuali.



Inoltre.



In alcuni blog per inserire i commenti spesso è necessario leggere i caratteri stampati in un'immagine (I succitati CAPTHA) e ricopiarli in un'area appossita per poter inviare i commenti. Perchè questa scelta? Perchè non esistono programmi che riescono a leggere il testo di un'immagine automaticamente per cui se lo spammer vuole rompere almeno ci mette la fatica e la perdita di tempo.



Problemi? Se non esiste il software per spammare con queste immagini, sicuramente non esiste neanche il software che permette a chi ha problemi di vista di leggere le immagini, dedurne il testo e duque commentare.



Sono necessarie le immagini? No, perchè basta mettere una condizione non computabile per una mcchina come può esserlo una lettura e copiatura di stringa.



Esempio?



"Quando fa 1+1-1?"



"Di che colore era il cavallo bianco di Napoleone?"



Con queste domande il software per spammer si blocca perchè non sa come rispondere a domande umane di questo tenore; mi sa che neanche con l'intelligenza artificiale sia una cosa gestibile tanto facilmente.



E tutti potranno navigare felici e contenti.



Perla Scandinava ha lanciato questa iniziativa cui mi sono aggiunto (con colpevole ritardo); Ventinove Settembre può integrare la mia esposizione qui esposta.



E' intelligente bloccare l'accesso alle informazioni in Rete solo per disattensioni tecniche?



Lo si fa solo per pigrizia o per semplice incapacità tecnica e progettuale?







Link vari

• bobby.watchfire.com




• www.csszengarden.com




• www.alistapart.com




• la versione italiana di csszen garden, "css sentiero"




• www.ericmeyer.com




• html.it, sezione grafica




• google.com con parole come "accessibilità web design"




• www.stopddesign.com

PS



Come avete intuito, il bue chiama cornuto l'asino: il mio blog è decisamente poco accessibile. Spero che questo post mi ricordi più spesso di migliorare il design.







(1)informazioni desunte dall'ottimo libro per web designer "lo Zen e il design CSS" di Dave Shea e Molly E.Holzshlag, Mondadori informatica - 40.00 euro ('tacci loro, ma perchè i libri di informatica costano sempre una cifra e gli informatici guadagnano poco?). Il libro tratta di tecniche di web design tramite esempi dal sito principe sui CSS, il CSS Zen Garden; comunque per me è un libro più adatto a chi è già dentro il mondo del design che al principiante.



Il design in cui si affronta il tema dell'accessibilità è Viridity di Laura MacArthur.

GPL questa sconosciuta


Questo è il primo post che dedico al mondo del free-software più in generale open-source.

Spero che il tempo non lo renda ultimo.

Cos'è il software libero? E' un qualunque software rilasciato con una licenza a prima vista molto strana, la GPL (General Public License).(1)

Prima di cominciare un chiarimento. Sapete come si crea il software, cioè quell'ammasso di bit (0 e 1) che fanno girare il vostro browser (Internet Explorer?? Firefox!!!! :)) ora, mentre state leggendo questo post?

Il Programmatore ha davanti a sè un problema di una certa complessità (oltre a portare a casa la pagnotta) e la sua soluzione va automatizzata in modo che una persona non ci perda troppo tempo appresso e si possa dedicare ad altro di più creativo, visto che costa più l'attività delle persone anzichè quella di componenti di silicio e quindi è meglio sfruttare al massimo le prime.

Il computer capisce solo 0 e 1 mentre il Programmatore, per quanto bravo tecnicamente e proporzionalmente meno empatico socialmente, ha sempre una gamma di parole un po' più vasta.

Cosa succede?

Il Programmatore, forte di un ottimo ambiente di sviluppo (Eclipse, Visual C++,  NetBeans) o al limite di un editor (ViM è il migliore per me, sennò EMACS o Notepad) scrive una serie di strane parole infischiandosene altamente di tutte le grammatiche umane sviluppate dal Paleolitico in poi.

L'ordine  di queste parole è determinato da una formalizzazione logica del problema, la cui soluzione è strutturata come il risultato di un insieme di istruzioni (alcune sempre eseguite, altre non sempre).

Questo insieme di istruzioni è detto algoritmo e rappresenta il cammino logico dal problema alla soluzione ("se c'è questo fai x, se no y...", "ripeti per 10 volte o fino a che non si ha questo messaggio...", "stai fermo fino a che l'utente non ti comunica la decisione...", etc).

Il modo con cui esprimere questi concetti e la quantità di parole connessa dipendono dal linguaggio di programmazione (C/C++, Java, Ruby, PERL, Modula-2, Python, Shakespeare Language...): in genere un programmatore usa 2 0 al massimo 3 linguaggi per coprire tutti i tipi di problemi.

Queste due cose (ordine (STRUTTURA LOGICA) delle istruzioni e come sono scritte (SINTASSI)) creano uno o più file di testo detti CODICE SORGENTE del software.

Poi cosa succede? Nel caso classico (2) il Programmatore usa un altro software - detto compilatore - che legge il codice sorgente, lo traduce con altri file di supporto (LIBRERIE) in file con all'interno dei caratteri riconoscibili non più dall'uomo ma dalla macchina.

Questo risultato finale è detto ESEGUIBILE ed è quello che voi avete sul vostro Desktop o sul vostro menu di Start; ci cliccate sopra e il programma parte, con gioia di tutti, specie del Programmatore che porta la sua pagnotta quotidian a casa (tranne ripensamenti del cliente ma di questo si occupa l'ufficio legale :)).

Chiusa la parentesi.

Cosa dice quindi la GPL? Dice che:

1)L'utente può usare il software sotto GPL per qualunque scopo, farne altre copie per uso personale, modificarlo e distribuirlo liberamente: deve solo inserire in ogni copia del titolare del copyrigth e da unacopia della GPL. Inolre non si assume responsabilità sul software.

2)L'utente deve usare la GPL nel rilascio del software (sia se lo ha modificato sia in caso contrario), cioè non può cambiare tipo di licenza; inoltre deve essere chiaro dal codice sorgente chi ha cambiato cosa;

3)L'utente nel rilascio deve allegare al software anche il codice sorgente;

Quindi questo tipo di software non nasconde - a priori - nulla all'utente: se l'utente non è soddisfatto se lo può aprire, vedere l'inghippo e aggiustarlo (che poi sia capace è un altro paio di maniche...). Al contrario il software closed-source non consente la libertà di studiare, modificare e ridistribuire il software.

A prima vista può sembrare un suicidio economico rilasciare codice con GPL, ma si consideri che:

3.1)Se un software non va, si può capire - assieme ad altri interessati - come risolvere il problema. Col codice closed-source te la devi vedere con l'azienda che te lo ha venduto (cioè non la costruttrice; se hai un Toshiba e Excel non va, contatti la Toshiba, non Microsoft)

3.2)Per molti è interessante capire come funziona un browser (per esempio); se non posso vedere i suoi sorgenti - ricordi? La strutturazione logica ed il linguaggio adottato - come posso capirlo?

Provare a commercializzare Abiword o WindowMaker può essere un suicidio economico, ma crearlo no.

3.3)Un software libero potenzialmente è molto più sicuro: se chiunque può vedere sotto, può anche testarlo per passione (fidati: c'è gente che lo fa come hobbydel week-end) senza dover rispettare scadenze di consegna. Questo rende il testing molto più accurato per via dell'approccio perfezionista applicabile in questo contesto rilassato. Spesso nel commerciale invece non puoi sacrificare troppa qualità per via delle scadenze.

4)Comunque il diritto d'autore è garantito: se uno prova a prendere il software GPL e poi rivenderlo chiuso rischia il processo. Finora infatti le aziende accusate diquesta violazione hanno sempre risolto la questione con accordi pur di non andare sotto processo perchè la GPL NON REGALA IL DIRITTO DI VITA E DI MORTE SU QUEL SOFTWARE.



Il seguito nelle prossime puntate :)



(1) Il link punta alla traduzione non ufficiale in italiano;

(2) Nel senso non classico non c'è la traduzione ma si esegue il codice sorgente mentre è letto (esempio: PERL, Pratical Expression Regular Language, Python, Ruby);

Digital divide: certe volte è veramente un problema?



Colpevole di aver espresso le proprie opinioni liberamente: questo è in pratica il verdetto del diritto egiziano contro Kareem, il blogger egiziano per cui era partita una campagna di sostegno - bipartisan, almeno così mi è sembrato - dai blogger e dalla Rete.

Mi viene un dubbio: molti si lamentano del digital divide, cioè la differenza di accesso alle informazioni della  Rete  WEB tra nazioni del Primo Mondo e le altre nazioni. Questi lamentano la gratuità di tale accesso in modo da rendere meno calcata questa differenza, magari accollando (o facendo accollare) le spese aggiuntive a chi accede ad Internet nelle nazioni più ricche.

Anche a me fa piacere estendere la Rete e ne apprezzo le potenzialità sia tecniche (meno) sia sociali e politiche (più). Anche io, se fossi in una zona non sviluppata come l'Italia,  vorrei conoscere ciò che c'è fuori.

Ma se per questo preferirei pure non usare Internet e scambiare le mie opioni col vicino di casa piuttosto che parlare in Rete e beccarmi 4 anni di carcere.

Il digital divide è una brutta malattia perchè l'informazione non riesce a circolare nel migliore dei modi possbili, ma se la sua cura crea un maggior controllo  GIURIDICO  e LEGISLATIVO sulla libertà di espressione delle persone, non si rischia di far fuori il paziente?