Bruno Mendola

Ok, vi risparmio la battuta sugli insetti :)

Facebook mette a disposizione di tutti gli utenti/programmatori un comodo set di funzioni, che in gergo si chiamano API (Application Programming Interface), scritte in vari linguaggi web, per interagire con la piattaforma del popolare social network e sviluppare le proprie applicazioni, siano esse integrate in Facebook (la maggior parte sono così) oppure applicazioni “stand-alone”, cioè fruibili da un sito esterno ma collegate alla banca dati di Facebook.

Fb rende l’impatto tra il programmatore e le API molto semplice, ponendolo di fronte ad un’interfaccia per gli sviluppatori che guida passo passo nella creazione delle applicazioni, integrandosi con utili strumenti come il Wiki ed una Test Console, che permette di effettuare chiamate di prova alle varie funzioni, specificandone i parametri, e ricevendo in risposta il relativo output in formato leggibile.

Le API si compongono di una parte che gira lato server dell’utente, le librerie client, ed una parte in formato markup che viene processata dal server di Facebook, il quale produce normali tag HTML interpretando un linguaggio ideato da Facebook chiamato FBML.

Il programmatore potrà utilizzare le librerie client ufficiali in PHP oppure una di quelle non ufficiali, disponibili in tantissimi linguaggi tra cui Java, Ruby on Rails, Perl, Python, .Net.
Con queste librerie bisognerà produrre un codice sorgente, che avrà un output in HTML, XML oppure FBML e che, anche nel caso di applicazioni da integrare in Facebook, dovrà essere ospitato presso un server web esterno per poi essere collegato a Facebook tramite l’interfaccia di amministrazione dell’applicazione. Quindi bisognerà trovare un hosting web, anche gratuito, che fornisca lo spazio per l’applicazione.

Facebook non chiede nient’altro, perchè consente ai programmatori di salvare le informazioni utilizzate dalle applicazioni in un vero e proprio database, il DataStore, in cui è possibile memorizzare i dati necessari a ciascun utente, senza doversi procurare un database su un server esterno, che costituirebbe una spesa sicuramente più grossa dello spazio web.
Anche per quanto riguarda il database Facebook ha “inventato” qualcosa: si chiama FQL, ed è un derivato del SQL che ha lo scopo di interrogare il database di Facebook ponendo alcune restrizioni sui permessi di accesso alle tabelle, perchè ogni utente può accedere solo alle informazioni proprie e dei propri amici che le condividono, non di più.

Per iniziare, una applicazione di esempio potrebbe essere questa:

<?php

require_once ‘client/facebook.php’;

$appapikey = ‘YOUR_API_KEY’;

$appsecret = ‘YOUR_APP_SECRET’;

$facebook = new Facebook($appapikey, $appsecret);
$user_id = $facebook→require_login();

$friends = $facebook→api_client→friends_get();

?>
<p>Ciao, !</p>
<p>I tuoi amici: 

<ul>

<? foreach ($friends as $friend) { ?>

  <li><fb:name uid=“<?= $friend ?>” useyou=“false” /></li>

<? } ?>

</ul></p>

?>

YOUR_API_KEY e YOUR_APP_SECRET vanno sostituiti con i codici assegnati da Facebook, che identificano univocamente l’applicazione e le consentono di effettuare le chiamate alle API per le quali è stata autorizzata inizialmente.

L’oggetto $facebook diventa l’interfaccia verso la piattaforma, la quale viene interrogata tramite le varie funzioni in PHP5 (ad oggetti).

I tag che inziano con <fb: sono i tag FBML di cui parlavo prima: essi verranno interpretati da Facebook e diventeranno, in questo caso, dei collegamenti ai profili specificati nell’attributo uid. Il particolare il primo diventerà un link al profilo dell’utente dell’applicazione ($user_id) e l’altro sarà un link al profilo di uno degli amici ($friend).

Per iniziare può bastare quanto detto finora, ma l’appetito vien mangiando… le possibilità sono infinite!

Per esempio utilizzando la seguente chiamata

$facebook→api_client→call_method(“facebook.status.get”,

                            array(‘uid’=>$user_id, ‘limit’=>10));

Buon divertimento! :)

Era da un po’ che ci lavoravo, ma gli impegni lavorativi fino ad oggi avevano sempre prevalso: ho fatto il porting del sito alla nuova versione 2.3.2 di Rails!
(era fermo alla 1.2.6)

I miglioramenti sono tanti, ma (tanto per cambiare) per la maggior parte invisibili. Beh, rimane la soddisfazione di aver fatto una cosa per benino!

Il risultato più evidente si può osservare nel nuovo modulo Social Networks, che integra le ultime condivisioni dai siti “2.0” che utilizzo di più… ne sono molto soddisfatto!

La notizia veramente positiva è che adesso c’è tanta carne al fuoco, perchè non ho intenzione di lasciar morire dentro la mia memoria, al momento moooolto volatile, quelle quattro cose che ho imparato: ho utilizzato la API di Facebook, YouTube e Flickr; ho sperimentato il fragment caching di Rails; mi sono deliziato con le nuove API i18n di Rails, per l’internazionalizzazione e la localizzazione delle pagine.
Insomma, ne avrò ancora per qualche altro post! :)

Concludo lodando ancora l’eleganza estrema di Ruby on Rails, è una goduria programmarlo! Certo non è a livelli “enterprise”… ma è VERAMENTE DIVERTENTE!! XD

PS: è in programma un ritoccone alla grafica… ma il lavoro è lungo!

Hamlet Activity: primo premio al Worldwide UML Jokes Contest 2008

Erano almeno 3 anni che non cominciavo a studiare qualcosa di complicato :)

Al primo giorno non ci sto capendo niente con tutti sti grafici, diagrammi, attori, comparse e punti di vista! Che bella sensazione!!!
Maaa… quand’è che si inizia a programmare?? x_x     Ok, scherzo… serietà!

Però volevo condividere una piccola considerazione: prima di iniziare con libri filosofici e PDF prolissi, è il caso di dare uno sguardo alla relativa voce su Wikipedia (Unified Modeling Language ITALIANO e Unified Modeling Language INGLESE), molto ben scritta e soprattutto SEMPLICE!

Da lì, sono poi arrivato ad un semplicissimo tutorial su UML 2.0, in inglese ma con tante figure :P

Ecco… dooopo si può pure passare ai libri.

In ogni grande azienda, quando si tratta di adottare una nuova tecnologia, ci si trova sempre frenati da qualcuno che pone la domanda “e con tutto il software sviluppato finora che facciamo?”.
In effetti è vero che non si può pretendere di fare il porting di tutto il codice già scritto ogni volta che viene scoperto un nuovo framework di programmazione.

La soluzione sono i Web Services, “un sistema software progettato per supportare l’interoperabilità tra diversi elaboratori su di una medesima rete” (fonte: Wikipedia).

Il Web Services Description Language (WSDL) è uno standard internazionale, promosso dal World Wide Web Consortium (W3C), che permette la descrizione delle caratteristiche di un Web Service attraverso uno schema XML/SOAP, il quale viene utilizzato come “strumento di sincronizzazione” tra il framework fornitore del servizio e quello che sarà l’utilizzatore (che, grazie a questa forma di comunicazione standard, potranno anche essere basati su linguaggi di programmazione eterogenei).
Grazie al WSDL è possibile, per esempio, utilizzare un’infrastruttura software progettata e sviluppata su un server Java (es. Tomcat), richiamandone i metodi da un server basato su Ruby on Rails (es. Mongrel).
In particolare, per quanto riguarda Ruby, si dovrebbe utilizzare la gemma SOAP4R, che però nelle ultime versioni è inclusa direttamente nel pacchetto ufficiale.

Un piccolo esempio di tutto ciò si può realizzare in pochi semplici passi, non c’è neanche bisogno di scrivere un vero tutorial.

• Creare una Web Application con un Web Service in Java e deployarla su Tomcat:

@WebService()
public class MyWebService {
    @WebMethod(operationName = "sayHello")
    public String sayHello(@WebParam(name = "firstName")
    String firstName) {
        return "Hello, " + firstName + "!";
    }
}

• Creare un progetto in Rails e richiamare il Web Service remoto:

class MyController < ApplicationController
  require 'soap/wsdlDriver'
  
  def index
    XSD::Charset.encoding = 'UTF8'
    wsdl = "http://TOMCAT_SERVER:8080/MyWebApp/MyWebService?wsdl"
    service = SOAP::WSDLDriverFactory.new(wsdl).create_rpc_driver

    result = service.sayHello :firstName => 'Bruno'

    render :text => result.return
  end
end

Ovviamente i due componenti precedentemente descritti potranno anche stare sulla stessa macchina, comunicando tramite l’interfaccia di loopback.

C’è da ricordare che lo standard XML dei Web Services permette di ritornare come output soltanto i seguenti tipi di dato:

• Boolean
• Byte
• Double
• Datatype
• Decimal
• Enumeration
• Float
• Int
• Long
• Qname
• Short
• String
• TimeInstant
• UnsignedByte
• UnsignedInt
• UnsignedLong
• UnsignedShort
• Array dei suddetti tipi

quindi per passare tipi di dati complessi da un’applicazione all’altra sarà necessario implementare dei metodi di serializzazione/deserializzazione sugli oggetti.

PS: un motivo in più per utilizzare NetBeans, che dalla versione 6 supporta anche Ruby on Rails e PHP! :)

Solo qualche appunto che mi sembra utile condividere con chi, come me, per lavoro e/o per diletto, si appresta a lavorare con il nuovo sistema operativo opensource per cellulari Android ed i prossimi GPhone (si vocifera che saranno nelle nostre mani già a settembre, per merito di Samsung, e ad un prezzo da urlo (100 dollari!!)):

1) il Software Development Kit (SDK) di Android, scaricabile da qui, è segnalato come disponibile solo per architetture i386 (quindi a 32 bit), mentre funziona egregiamente anche sulle macchine a 64 bit.

2) c’è un plugin per NetBeans, chiamato Undroid, che permette l’integrazione dell’IDE con l’SDK di Android, esattamente come avviene per il WTK (Wireless ToolKit) di J2ME ed il relativo emulatore.
Sottolineo che questo è un prodotto di terze parti, anche se funziona più che bene, mentre il plugin per Eclipse è supportato ufficialmente da Google.

3) a causa di un momentaneo problema di compatibilità con l’ultima release dell’SDK (m5-rc15), bisogna apportare una piccola modifica ad ogni nuovo progetto per Android creato con NetBeans, altrimenti la compliazione non andrà a buon fine, ritornando l’errore

AndroidManifest.xml line 5: Tag missing required attribute name.

<activity class=“…” android:name=“…”>

  <intent-filter>

    <action android:name=“…”/>

    <category android:name=“…”/>

  </intent-filter>

</activity>

4) se ci si trova a sviluppare dietro un proxy aziendale, è possibile avviare l’emulatore impostandone l’indirizzo (in caso contrario, non si potrebbe utilizzare il browser e le applicazioni che utilizzano la connettività di rete).
Per fare ciò, bisogna aprire le Proprietà del progetto (click destro → Properties), andare nella scheda “Run” ed inserire nel campo “Emulator options” la stringa -http-proxy http://PROXY:PORTA (ovviamente sostituendo i relativi valori dell’URL).

Se le aspettative saranno rispettate (e le premesse ci sono tutte), l’_Apple iPhone_ avrà presto un valido concorrente… che comunque, evidentemente, è già l’handset preferito dai programmatori. La libertà è la cosa + importante, ma Apple non l’ha mai pensata così!

Buon divertimento a tutti i programmatori smanettoni! :)

Ooooook… è il momento di accontentare la mia blog-stylist preferita! (cit: “scrivi troppe poche minchiateee!”)
Beh, in realtà è un appellativo che sta un po’ stretto a questo capolavoro… per il semplice motivo che è tutto maledettamente vero (gli ultimi accadimenti a lavoro lo dimostrano… grrrrr…)!!

Ed è vero anche che… evidentemente non ce la faccio a discostarmi dall’argomento principale del mio blog! =) Sono un caso cronico e me ne vanto!
Ultimamente ho attacchi di “programmazione violenta” che hanno lasciato varie tracce nei recenti post… ma che ci posso fare se mi diverto troppo? :D E mi pagano pure… mi pare QUASI male… QUASI, appunto… MUAHHAHAH!

PS: in qualche modo me lo dovrò passare il tempo… maledetta febbre! :S

E’ una notizia talmente ovvia che non sembra neppure una notizia, ma qualcuno ha sviuppato un plugin per Ruby on Rails che permette di fare il rendering in HTML delle pagine scritte con la sintassi di MediaWiki… cioè lo stesso software utilizzato da Wikipedia. :)
Sarebbe successo… prima o poi. Gli automatismi di Rails non potevano permettersi una tale carenza!

margherite e rubini… un regalo di sicuro effetto! :)

MediaCloth è il nome del plugin: implementa tutti i tag più diffusi della sintassi di MediaWiki, lasciando però al programmatore il compito di gestire le caratteristiche che cambiano da un sito all’altro, come la gestione dei link e delle immagini.

Mi sono convinto che questo post potesse essere utile nel momento in cui ho cercato un po’ di documentazione riguardo quest’ultimo punto. Essendo il progetto in via di sviluppo (la versione corrente è la 0.0.3), probabilmente nessuno si è ancora preso la briga di scrivere due righe sull’argomento… quindi ho dovuto andarci per tentativi! :P

L’installazione è semplice:

# gem install mediacloth

… mentre nel controller o nel modulo che si occuperà del rendering, servirà qualcosa del genere:

require 'mediacloth'

parser = MediaWikiParser.new
parser.lexer = MediaWikiLexer.new
ast = parser.parse(input)
generator = MediaWikiHTMLGenerator.new
generator.parse(ast)
output = generator.html

Quello che nessuno vi dirà mai è che… è proprio qui che si deve intervenire per includere il nostro gestore di link!

Prima di tutto creiamo il file lib/mywikilinkhandler.rb :

require ‘mediacloth’

require ‘builder’

class MyWikiLinkHandler < MediaWikiLinkHandler

  def url_for(page)

    “/wiki/#{page}”        # … PER ESEMPIO

  end
def link_attributes_for(page)
{ :href => url_for(page) }
end
def link_for(page, text)
elem.a(link_attributes_for(page)) { |x| x << text }
end
def link_for_resource(prefix, resource, options=[])
case prefix
when ‘Image’ # ANALOGAMENTE E’ POSSIBILE AGGIUNGERE ALTRI TIPI DI RISORSA
“”/images/#{resource}\" alt=\“#{resource}\” />"
else
link_for “#{resource}”,
!(options.empty?) ? options.join(’, ’) : “#{resource}”
end
end

protected
def elem
Builder::XmlMarkup.new
end
end

… e poi modifichiamo il codice di prima, dicendogli di utilizzare il nuovo link handler:

require 'mediacloth'
require 'mywikilinkhandler'

parser = MediaWikiParser.new
parser.lexer = MediaWikiLexer.new
ast = parser.parse(input)
generator = MediaWikiHTMLGenerator.new
generator.link_handler = MyWikiLinkHandler.new
generator.parse(ast)
output = generator.html

Fatto! :)

Adesso il parser riconoscerà [[Link interno]], [http://www.brunomendola.net Link esterno] e [[Image:immagine.png]].

Per una panoramica sulla sintassi wiki, fate riferimento alla guida base di MediaWiki.

Opzionalmente, se proprio voleste realizzare un super-wiki_, c’è la possibilità di utilizzare un altro plugin per fare il rendering delle differenze tra le diverse versioni dei documenti: blank">diff-lcs un porting in linguaggio Ruby del famoso algoritmo Diff che viene utilizzato un po’ dappertutto.
Al contrario di MediaCloth, questo plugin è molto ben documentato… basta leggere e programmare! :)

Spero che questo post faccia risparmiare tempo a qualche programmatore in cerca di lumi :)

Buon divertimento!

Ricordare quando scoppiò la bufera sul DRM, sul TCPA, sul cosiddetto “”http://it.wikipedia.org/wiki/Palladium">Palladium", il chip Fritz e (soprattutto) l’adozione di queste tecnologie sui sistemi operativi proprietari?
Al giorno d’oggi Microsoft continua per la sua strada (fallimentare), Apple è tornata saggiamente sui suoi passi, ma… è tutto qui? Non direi!

Oggi ho assaporato con i miei stessi polpastrelli le limitazioni di un sistema di Trusted Computing, quello che abbiamo tutti installato sui nostri cellulari (o almeno tutti quelli con SO basati su Java). Lo sapevate?
E cosa comporta la presenza di questo “sistema di sicurezza”?
Vi racconto la mia esperienza.

Ho sviluppato un programmino in Java 2 Micro Edition (J2ME), da far girare sul mio Nokia 6280, che ha un sistema operativo Nokia Series 40 (S40).
Ho implementato molte feature, tra cui connessione TCP/IP e Bluetooth, RecordStore per registrare le impostazioni come su un normale database, parsing di feed RSS, parsing di dati GPS provenienti da un ricevitore collegato, cattura delle immagini dalla fotocamera, accesso al filesystem per importare immagini nel programma.

Cosa vengo a scoprire?? Che quando tento di utilizzare alcune funzioni, come l’accesso ai file o la connessione tramite socket, l’applicazione si blocca dicendo “You are not authorized to access the restricted API”!
L’ambiente MIDP2, sotto cui girano le MIDlet, è come un recinto da cui si riesce a vedere perfettamente ciò che sta all’esterno, ma qualcosa ti blocca quando tenti di raggiungerlo.

OK, ho pensato che se hanno deciso di vietare anche soltanto la lettura dei file, ci sarà un buon motivo che riguarda ALMENO la sicurezza dell’universo!
Ma che!!!! Ho letto sul forum degli sviluppatori Nokia che, per usare quelle ed altre funzioni, è necessario COMPRARE un certificato dalle authority internazionali e “firmare” la MIDlet con questo certificato!! (in pratica, basta pagare per allargare il recinto!)
E quanto costano questi certificati, presso le varie authority?? Verisign offre un certificato con validità di 1 anno al modico prezzo di 499 dollari, mentre Thawte ci fa il favore di proporre lo stesso articolo per 299 dollari.
Dopo questa banalissima operazione, la nostra applicazione avrà finalmente accesso alle preziose funzioni riservate che ci erano state negate.

Wow! Grazie! Ma io volevo soltanto realizzare un programmino cretino e avere il piacere di farlo girare sul mio cellulare!! E’ veramente frustrante! :’-(

A questo punto aspetto con ansia gli sviluppi di Android… free, open source e, SPERO, senza problemi con i certificati!

Chi ha intenzione di sviluppare MIDlet per cellulari utilizzando il WTK 2.5.2 della Sun su una macchina a 64 bit, si troverà nella situazione di non poter avviare l’emulatore, poichè esso si rifiuterà di partire sostenendo che:

java.lang.UnsatisfiedLinkError:
	/home/user/netbeans-6.0/mobility8/WTK2.5.2/bin/sublime.so:
	/home/user/netbeans-6.0/mobility8/WTK2.5.2/bin/sublime.so:
	wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

Insomma… problemi di compatibilità tra binari a 32 e a 64 bit!

Per risolvere il problema, cominciamo con lo scaricare una JDK a 32 bit;
poi andiamo nella directory dove abbiamo installato WTK (nel mio caso è quello compreso nell’installazione di NetBeans 6) e decomprimiamo il pacchetto:

$ cd ~/netbeans-6.0/mobility8/WTK2.5.2
$ sh /path/to/jdk-6u3-linux-i586.bin
$ ln -s jdk1.6.0_03 jdk32

In seguito, dovremo editare lo script di avvio dell’emulatore WTK:

$ cd ~/netbeans-6.0/mobility8/WTK2.5.2
$ vim bin/emulator

(ovviamente potete utilizzare il vostro editor preferito al posto di vim)

e modificare la prima riga del codice in questo modo:

javapathtowtk=/home/user/netbeans-6.0/mobility8/WTK2.5.2/jdk32/bin/

Adesso potrete finalmente testare le vostre applicazioni J2ME sull’emulatore! :)

Mi capita sempre + spesso di parlare di AJAX e descriverlo come “facile da programmare” a persone che ancora non si sono avvicinate alla programmazione web avanzata. E’ ovvio che in questo caso non riesco ad essere molto credibile! :)
Quindi ecco qui una ppppiiiiccola guida passo passo per comprendere cosa veramente ci permette di fare questa nuova tecnologia. Credo che per leggere tutto senza fatica serva un minimo di conoscenza della programmazione web… o una bella fantasia! :P
Ah, per realizzare il tutto è necessario avere installati sulla propria macchina, o anche su una macchina remota, un server HTTP (io uso Apache 2.2) funzionante con PHP ed un server MySQL. Tutto open source naturalmente… basta scaricare ed installare! ;)

AJAX (Asynchronous Javascript and XML)… tutto si basa sul concetto di “comunicazione asincrona” con il server: noi clicchiamo su un link o un pulsante per eseguire un’azione su dei dati remoti (che possono essere righe di database, file sul disco del server, ecc…) e ne vediamo subito le conseguenze, ancor prima che le azioni siano comunicate al server.
Quindi, mentre noi andiamo avanti a navigare e a fare altro, un javascript si occupa (con molta tranquillità) di comunicare al server l’azione che abbiamo eseguito “virtualmente”… sicchè il server capisce il da farsi ed esegue di fatto le azioni.
Il vantaggio? E’ stato eliminato il tempo di latenza della comunicazione client-server ed anche il reload della pagina! :)

Inoltre, sempre grazie ad AJAX, possiamo cambiare radicalmente il contenuto di una pagina web (tramite manipolazione DOM), richiedendo dati al server in formato XML o testo semplice, e sempre senza ricaricare la pagina… che per siti abbastanza complessi è una vera seccatura!

Andiamo al lato pratico della questione: il fondamento di AJAX è un oggetto javascript che si chiama XMLHttpRequest.
A causa delle differenti implementazioni sui diversi browser, questo oggetto viene creato tramite una funzione cross-browser che si scrive una volta e poi si può dimenticare tranquillamente. :)

function createXMLHttpRequest() {
	try { return new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) {}
	try { return new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) {}
	try { return new XMLHttpRequest(); } catch(e) {}
	alert("XMLHttpRequest not supported");
	return null;
}

Quindi abbiamo capito che questa funzione restituisce il giusto oggetto per le chiamate AJAX, a seconda del browser. Cominciamo mettendola dentro un file di testo e chiamiamolo ajax.js.

Adesso dobbiamo decidere cosa fargli fare. Uhm… facciamo finta di avere una tabella in HTML con tante righe prese dal database sul server… e vogliamo che alla pressione di un pulsantino accanto alla riga, questa venga cancellata dalla pagina e anche dal DB.
Ovviamente la cancellazione “visuale” avverrà subito tramite manipolazione DOM e la cancellazione “reale” avverrà con i suoi tempi tramite una chiamata AJAX.

La parte che ci interessa della pagina HTML, cioè la tabella, potrebbe essere generata da un semplice script PHP, che non riporto. Nell’esempio successivo infatti realizzeremo questo passo in AJAX.

Ma andiamo alla nostra tabella. Nella pagina HTML, in mezzo a tutto il resto, avremo qualcosa del genere:

<html>
<head>
	<title>Test AJAX 1</title>
	<script type="text/javascript" src="ajax.js"></script>
</head>
<body>
<table id="tabella">
	<tr id="riga_1">
		 <!-- QUESTO E' IL DATO PROVENIENTE DAL DB... -->
		<td>Testo 1</td>
		 <!-- ...E QUESTO E' IL PULSANTINO DI ELIMINAZIONE -->
		<td><input type="button" value="Elimina" onclick="elimina_riga(1)" /></td>
	</tr>
	<tr id="riga_2"> <!-- ALTRE RIGHE PER RENDERE LA COSA UN PO' VEROSIMILE -->
		<td>Testo 2</td>
		<td><input type="button" value="Elimina" onclick="elimina_riga(2)" /></td>
	</tr>
	<tr id="riga_3">
		<td>Testo 3</td>
		<td><input type="button" value="Elimina" onclick="elimina_riga(3)" /></td>
	</tr>
</table>
</body>
</html>

… e la funzione Javascript (dentro il file ajax.js) che svolgerà l’azione sarà più o meno così:

function elimina_riga(id) {
	
	// LA RIGA VIENE CANCELLATA DALLA PAGINA WEB
	riga = document.getElementById("riga_"+id);
	riga.parentNode.removeChild(riga); 
	
	// E ADESSO CANCELLIAMOLA _VERAMENTE_ DAL DB
	var xhReq = createXMLHttpRequest();
	xhReq.open("POST", "elimina_riga.php", true);
	xhReq.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
	xhReq.onreadystatechange = function() {
		if (xhReq.readyState == 4)  {
			if(xhReq.status == 200) {
				// PER SICUREZZA CONTROLLIAMO CHE L'AZIONE SIA ANDATA A BUON FINE
				if(xhReq.responseText!="1") {
					alert("Hey, qualcosa è andato storto!");
				}
			}
		}
	}
	xhReq.send("id="+id);
}

Sul server ci sarà uno script elimina_riga.php che esegue l’azione asincrona sul database. Per completezza:

<?php
if(is_numeric($_POST['id'])) { // EVITIAMO ATTACCHI DI SQL INJECTION

	mysql_connect('localhost', 'username', 'password'); // CONNESSIONE AL DB
	mysql_select_db('database');

	if(mysql_query("DELETE FROM tabella WHERE id=".$_POST['id']))
		echo "1"; // ET VOILA'... RIGA CANCELLATA!
	else
		echo "0";
}
?>

Ho omesso tutti i controlli su un’eventuale autenticazione (che si potrebbe fare molto facilmente con le variabili di sessione del PHP), perchè è un argomento che non riguarda questo tutorial.

Beh… a questo punto il primo passettino con AJAX è stato fatto! :)
Adesso possiamo vedere qualcosa di più complicato… la richiesta di dati in formato XML!

L’XML è utile per organizzare i dati in una struttura ad albero schematica e allo stesso tempo flessibile dal punto di vista del programmatore.

Supponiamo di voler creare la tabella HTML dell’esempio precedente, utilizzando i dati presi dal database: la tabella sarà creata al carimento della pagina tramite una XMLHttpRequest e la manipolazione DOM del documento.

La pagina HTML dovrà associare all’evento di caricamento della pagina la funzione javascript per la creazione della tabella:

<html>
<head>
	<title>Test AJAX 2</title>
	<script type="text/javascript" src="ajax.js"></script>
</head>
<body onload="popola_tabella()">

<table id="tabella">
</table>

</body>
</html>

leggi_tabella.php è uno script PHP lato server che produce il file XML che ci serve per popolare la nostra tabella:

<?php
header("Content-Type: text/xml");
echo "<?xml version="1.0" encoding="ISO-8859-15" standalone="yes"?>\n";

mysql_connect('localhost', 'username', 'password'); // CONNESSIONE AL DB
mysql_select_db('database');

?>
<tabella>

<?php
$query = mysql_query("SELECT id, testo FROM tabella");
while($riga = mysql_fetch_assoc($query)) {
?>
	<riga id="<?=$riga['id']?>"><?=$riga['testo']?></riga>
<?
}
?>

</tabella>

Il risultato che avremo sarà come questo:

<?xml version="1.0" encoding="ISO-8859-15" standalone="yes"?>
<tabella>
	<riga id="1">Testo 1</riga>
	<riga id="2">Testo 2</riga>
	<riga id="3">Testo 3</riga>
</tabella>

e servirà una funzione javascript per richiedere la pagina XML al server ed interpretarla per farla diventare codice HTML.

Dentro ajax.js avremo la funzione principale:

function popola_tabella() {
	var xhReq = createXMLHttpRequest();
	xhReq.open("POST", "leggi_tabella.php", true);
	xhReq.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
	xhReq.onreadystatechange = function() {
		if (xhReq.readyState == 4)  {
			if(xhReq.status == 200) {
				xml = xhReq.responseXML;
				if(xml!=null) {
					// INDIVIDUA L'ELEMENTO tabella NELLA PAGINA HTML
					tabella = document.getElementById("tabella"); 
					// ELEMENTO tabella NEL FILE XML
					var xmlTabella = xml.getElementsByTagName("tabella")[0];
					// TUTTE LE RIGHE DELLA TABELLA NEL FILE XML 
					var xmlRighe = xmlTabella.getElementsByTagName("riga");  

					for(i=0;i<xmlRighe.length;i++) { // PER OGNI RIGA....
						xmlRiga = xmlRighe<i>;

						// LEGGE L'ID DELLA RIGA
						id = xmlRiga.getAttribute("id");

						// LEGGE IL TESTO CONTENUTO
						testo = xmlRiga.childNodes[0].nodeValue;

						// CREA UNA NUOVA RIGA
						riga = document.createElement("tr");

						// IMPOSTA L'ID
						riga.setAttribute("id","riga_"+id);

						// CREA LA CELLA CON IL TESTO
						cella1 = document.createElement("td");      
						cella1.innerHTML = testo;

						// CREA LA CELLA CON IL PULSANTE ELIMINA
						cella2 = document.createElement("td");       

						// CREA IL PULSANTE ELIMINA
						elimina = document.createElement("input");  
						elimina.setAttribute("type","button");
						elimina.setAttribute("value","Elimina");
						elimina.onclick = function() { elimina_riga(id); };

						// AGGIUNGE IL PULSANTE ELIMINA ALLA CELLA
						cella2.appendChild(elimina);

						// AGGIUNGE LE CELLE ALLA RIGA
						riga.appendChild(cella1);
						riga.appendChild(cella2);

						// AGGIUNGE LA RIGA ALLA TABELLA
						tabella.appenChild(riga);
					}
						
				}
			}
		}
	}
	xhReq.send("");	
}

E’ da notare che il codice che viene scritto dopo xhReq.onreadystatechange = function() { è da trattare come una funzione separata, che viene invocata quando la virtual machine rileva un cambiamento dello stato della XMLHttpRequest. Ciò implica che non potremo accedere da questo codice alle variabili utilizzate all’interno della funzione chiamante.

… direi che abbiamo finito! :lol:

Bene! :) Adesso chi volesse approfondire potrebbe utilizzare questi piccoli esempi come base per costruire qualcosa di più complesso. Vi assicuro che quanto c’è di più difficile nella programmazione AJAX è stato trattato in questo tutorialino-ino-ino! ;)

Maggiori informazioni sulle funzioni per la manipolazione DOM le potete trovare facilmente su Google.

Sperando di essere stato utile a qualcuno… vi auguro buona programmazione! :D

I tizi che hanno inventato i computer sono sicuramente molto intelligenti, nessuno potrebbe dire il contrario. E lo saranno anche i programmatori dei sistemi operativi, no?
Bene, allora qualcuno mi spiega il motivo per cui questi simpaticissimi burloni hanno pensato di far smettere di girare il mondo esattamente il 19 aprile del 2038 (alle 3:14:07 UTC)? o.O
Il fatto è che le date vengono rappresentate, con il sistema POSIX, tramite un signed int a 32 bit, che indica il numero di secondi passati dal 1° gennaio 1970. La prima cosa che viene da pensare ad un programmatore è “uhm, quanti secondi ci stanno in 31 bit?”… e invece no! “Chissenefrega, ce ne stanno tantissimi!” Sì, talmente tanti che arrivati all’ora X il bit più significativo diventa 1, il numero diventa negativo, e la data si sposta automaticamente al 19 Gennaio 1901! O.O Immaginate il disastro!

Le spiegazioni sono 2:

1) avevano ragione i Maya (c’erano droghe potenti a quei tempi), quindi NON ci sarà un 2038, perchè secondo il loro calendario l’Età dell’Oro (cioè la nostra epoca) finirà il 21 dicembre del 2012 a causa di terribili catastrofi… ed evidentemente loro, i programmatori, sapevano tutto! (che sarebbe anche la trama dell’ultimissima puntata di X-Files, se qualcuno si ricorda :P)

oppure

2) aveva ragione John Titor, un enigmatico personaggio apparso su Internet nel 2000, dicendo di essere un soldato inviato indietro nel tempo dagli scienziati del 2036 per recuperare un vecchio IBM 5100, che sarebbe l’unica macchina capace di risolvere il bug che sconvolgerebbe il mondo (qui c’è tutta la storia).

Ehm.. tra le due mi sembra più simpatica la seconda! Vai John, io credo in te!!! ;)

Ehm.. tra le due mi sembra più simpatica la seconda! Vai John, io credo in te!!! ;)Tornando seri, mi sembra che ci sia qualcosa di DECISAMENTE mooolto strano. Voglio dire… stiamo parlando di gente abituata a risolvere problemi ben più cervellotici di una dichiarazione di variabile ed un prevedibilissimo overflow! Bohhh!

Ehm.. tra le due mi sembra più simpatica la seconda! Vai John, io credo in te!!! ;)Tornando seri, mi sembra che ci sia qualcosa di DECISAMENTE mooolto strano. Voglio dire… stiamo parlando di gente abituata a risolvere problemi ben più cervellotici di una dichiarazione di variabile ed un prevedibilissimo overflow! Bohhh!E adesso? Che si fa?
Qualcuno potrebbe dire “facile, cambiamo tutte le date e facciamole diventare a 64 bit!”. Tutte?!? Beh, non solo si dovrebbero cambiare tutti i sistemi operativi e tutti i programmi, ma anche tutti i file e tutti i filesystem del mondo! Ops, mi sa che è difficilotto! :P
“ok, allora recuperiamo 1 bit e dichiariamo le date come unsigned int, così siamo a posto fino al 2106 e poi se la sbrigano i nostri nipoti… prrr!”. Eh no! Si dovrebbe comunque riscrivere e ricompilare praticamente tutto, perchè non funzionerebbero più le differenze tra date!
E’ vero che adesso ci sono i sistemi a 64 bit, ma è anche vero che i chip a 32 bit vengono sfornati ancora in quantità enorme e non vogliono proprio saperne di sparire dalla circolazione, non solo in ambito personal computer… ad esempio ci sono i dispositivi embedded che ne fanno largo uso e oltretutto non sono aggiornabili!
Siamo sicuri che entro il 2038 ogni singolo chip presente sulla faccia della terra sarà sostituito? :S

Ehm.. tra le due mi sembra più simpatica la seconda! Vai John, io credo in te!!! ;)Tornando seri, mi sembra che ci sia qualcosa di DECISAMENTE mooolto strano. Voglio dire… stiamo parlando di gente abituata a risolvere problemi ben più cervellotici di una dichiarazione di variabile ed un prevedibilissimo overflow! Bohhh!E adesso? Che si fa?
Qualcuno potrebbe dire “facile, cambiamo tutte le date e facciamole diventare a 64 bit!”. Tutte?!? Beh, non solo si dovrebbero cambiare tutti i sistemi operativi e tutti i programmi, ma anche tutti i file e tutti i filesystem del mondo! Ops, mi sa che è difficilotto! :P
“ok, allora recuperiamo 1 bit e dichiariamo le date come unsigned int, così siamo a posto fino al 2106 e poi se la sbrigano i nostri nipoti… prrr!”. Eh no! Si dovrebbe comunque riscrivere e ricompilare praticamente tutto, perchè non funzionerebbero più le differenze tra date!
E’ vero che adesso ci sono i sistemi a 64 bit, ma è anche vero che i chip a 32 bit vengono sfornati ancora in quantità enorme e non vogliono proprio saperne di sparire dalla circolazione, non solo in ambito personal computer… ad esempio ci sono i dispositivi embedded che ne fanno largo uso e oltretutto non sono aggiornabili!
Siamo sicuri che entro il 2038 ogni singolo chip presente sulla faccia della terra sarà sostituito? :SIo direi di cominciare a fare una bella scorta di carta e penneeeeeeeee! :lol:

Ehm.. tra le due mi sembra più simpatica la seconda! Vai John, io credo in te!!! ;)Tornando seri, mi sembra che ci sia qualcosa di DECISAMENTE mooolto strano. Voglio dire… stiamo parlando di gente abituata a risolvere problemi ben più cervellotici di una dichiarazione di variabile ed un prevedibilissimo overflow! Bohhh!E adesso? Che si fa?
Qualcuno potrebbe dire “facile, cambiamo tutte le date e facciamole diventare a 64 bit!”. Tutte?!? Beh, non solo si dovrebbero cambiare tutti i sistemi operativi e tutti i programmi, ma anche tutti i file e tutti i filesystem del mondo! Ops, mi sa che è difficilotto! :P
“ok, allora recuperiamo 1 bit e dichiariamo le date come unsigned int, così siamo a posto fino al 2106 e poi se la sbrigano i nostri nipoti… prrr!”. Eh no! Si dovrebbe comunque riscrivere e ricompilare praticamente tutto, perchè non funzionerebbero più le differenze tra date!
E’ vero che adesso ci sono i sistemi a 64 bit, ma è anche vero che i chip a 32 bit vengono sfornati ancora in quantità enorme e non vogliono proprio saperne di sparire dalla circolazione, non solo in ambito personal computer… ad esempio ci sono i dispositivi embedded che ne fanno largo uso e oltretutto non sono aggiornabili!
Siamo sicuri che entro il 2038 ogni singolo chip presente sulla faccia della terra sarà sostituito? :SIo direi di cominciare a fare una bella scorta di carta e penneeeeeeeee! :lol:PS: ok, non volevo essere allarmistico… probabilmente non succederà niente… ma ste cose mi fanno viaggiare troppo con l’immaginazione! :P

A lavoro ho sviluppato un programma in Java che utilizza delle librerie particolari per la comunicazione con la porta seriale; le librerie però sono diverse tra Windows e Linux, con una procedura di installazione abbastanza noiosa.
Mi serviva quindi qualcosa che potesse automatizzare questo processo e che rendesse anche più semplice l’accesso al programma (i programmi Java si lanciano da riga di comando con java -jar “/percorso/del/file.jar”.. non è molto bello da vedere!).
Dopo un po’ di ricerche mi sono imbattuto in questo simpaticissimo programmino

anch’esso scritto in Java (quindi per girare necessita semplicemente di un qualsiasi sistema con Java Virtual Machine installata), open source, rilasciato sotto la Apache Software License version 2.0, e che ha il compito di produrre dei semplicissimi wizard di installazione per le nostre applicazioni.
Dopo un primo momento di smarrimento, ho capito il funzionamento (e ho capito anche che non è più il caso di non leggere mai il manuale) ed in pochi minuti sono stato in grado di produrre il mio installer multipiattaforma, con una gradevole interfaccia grafica multilingua. :)

Il pregio di IzPack è appunto la sua natura orientata alla realizzazione di programmi che possano girare su diversi sistemi operativi; per la configurazione si basa su file XML con una struttura molto user-friendly e che permette di personalizzare ogni singolo aspetto dell’installer finale: è possibile distribuire il programma con i sorgenti o meno, includere un eseguibile di disinstallazione, aggiungere i collegamenti nel menù e sul desktop, il tutto indifferentemente da quale sistema si stia utilizzando.
Sarebbe anche possibile sviluppare facilmente dei moduli aggiuntivi per l’installer (tutto spiegato nella documentazione), ma non ne ho avuto bisogno perchè è già veramente molto completo.
Una volta completata la configurazione, si lancia la compilazione dandogli in input il file XML con le specifiche… et voilà, è pronto il brodo + brodo che possa esistere, per un informatico che sta assaporando solo adesso le gioie di vedere la propria creatura girare ovunque! :P

Consigliatissimoooooooo!

Molti sono scoraggiati ad imparare a programmare in Java Enterprise Edition (J2EE) dalle difficoltà nell’impostazione dell’ambiente di lavoro nel proprio PC di casa.
La scelta dei componenti e la poca documentazione “user-friendly” reperibile in rete contribuiscono a lasciare J2EE relegato in ambito aziendale, dove di solito si trova un sistema di server già pronti all’uso e… bisogna solo programmarci dentro.

Anch’io ho rimandato l’approccio a questo ambiente più di quanto volessi, ma a questo punto posso confermare che è più facile di quello che sembra! :D

Prima di tutto c’è da fare una doverosa introduzione: avevo sempre sentito parlare male di Java, a causa della sua pesantezza e della conseguente lentezza. Ad un certo punto mi sono chiesto il motivo per cui è così diffuso nelle aziende… e vi assicuro che è INCREDIBILMENTE diffuso!

Mi sono dato una spiegazione dopo diversi colloqui di lavoro: è frequente che un’azienda abbia la necessità di sviluppare diverse forme di interazione con un unico ambiente centrale, un “core”, che dovrà dialogare con client sviluppati in vario modo (interfacce testuali, grafiche, per dispositivi mobili, interfacce web, eccetera)… ed in questa ottica Java mette a disposizione dei programmatori una stuttura orientata al riutilizzo del codice già scritto, alla scalabilità ed al lavoro di gruppo.
Ne risulta che l’azienda ci guadagna… ed anche tanto!

Andiamo all’aspetto pratico. Bisogna decidere quali programmi utilizzare come application server e come ambiente di sviluppo.
Come Wikipedia insegna, un application server è un software che fornisce l’infrastruttura e le funzionalità di supporto, sviluppo ed esecuzione di applicazioni e componenti server in un contesto distribuito. Si tratta di un complesso di servizi orientati alla realizzazione di applicazioni per il web, multilivello ed enterprise, con alto grado di complessità.
Sapendo per certo che in queste diatribe ne escono sempre vincitori i rappresentanti del software libero, sia come sicurezza che come reperibilità (ed anche per i costi!!!), non ho neanche guardato il software commerciale (WebSphere di IBM, Oracle AS, Weblogic, …).
La scelta, per quanto riguarda l’AS, è ricaduta sul progetto open-source più sviluppato e più supportato da una vasta comunità di sviluppatori: JBoss.

E’ possibile scaricarlo direttamente dalla sezione download del sito ufficiale (io ho optato per l’ultima release stabile, che al momento è la 4.0.5).

Un IDE di sviluppo che qualche mese fa mi è risultato ottimo nella programmazione Java (standard e mobile) è stato Eclipse (anch’esso open source), quindi mi sono informato se fosse possibile renderlo interoperabile con le strutture J2EE. Le soluzioni erano diverse, ma alla fine ho deciso scaricare JBoss Eclipse IDE, una versione di Eclipse modificata direttamente dagli sviluppatori di JBoss, con installati tutti i plugin necessari al funzionamento in accoppiata con l’application server.

Ah… ovviamente la macchina server è equipaggiata con una stupenda Slackware Linux 11.0! ;)
(tutte le indicazioni seguenti riguardano Slackware, ma sono facilmente riportabili ad altre distribuzioni)

L’installazione di JBoss è semplice, basta estrarre l’archivio:

$ cd /opt
$ unzip /path/to/downloaded/jboss-4.0.5.GA.zip
$ ln -s jboss-4.0.5.GA jboss

Non bisogna compilarlo perchè è anch’esso scritto in Java, quindi è multi-piattaforma e gira sotto la Java VM ;)

Prima di far partire il server è necessario installare JDK, qualora non fosse già presente nel sistema, per poi impostare qualche variabile d’ambiente:

$ ln -s /usr/lib/jdk1.5.0_09 /usr/lib/java
$ export JBOSS_HOME='/opt/jboss'
$ export JAVA_HOME='/usr/lib/java'
$ export CLASSPATH='/usr/lib/java/lib/tools.jar'

A questo punto si potrà lanciare JBoss eseguendo

/opt/jboss/bin/run.sh > /dev/null &

(uso la redirezione dell’output per evitare che la shell sia inondata dai messaggi di debug anche con il programma messo in background)

E’ consigliabile salvare uno script d’avvio in

/etc/rc.d/rc.jboss

case "$1" in
  start)
    echo "Starting JBoss:  /opt/jboss/bin/run.sh"
    export JBOSS_HOME='/opt/jboss'
    export JAVA_HOME='/usr/lib/java'
    export CLASSPATH='/usr/lib/java/lib/tools.jar'
    /opt/jboss/bin/run.sh > /dev/null &
  ;;
  stop)
    echo "Stopping JBoss..."
    /opt/jboss/bin/shutdown.sh -S > /dev/null &
  ;;
  restart)
    echo "Restarting JBoss..."
    /opt/jboss/bin/shutdown.sh -S > /dev/null &
    /opt/jboss/bin/run.sh > /dev/null &
  ;;
  *)
    echo "Usage: $0 {start|stop|restart}"
    exit 1
  ;;
esac

Adesso è il turno di JBoss IDE:

# cd /usr/local
# tar xfvz /path/to/downloaded/JBossIDE.tar.gz
# chmod +x /usr/local/eclipse/eclipse

Sarà necessario eseguire Eclipse come root, per fare in modo che il server possa essere gestito dall’interno dell’applicazione. Per fare ciò, utilizzeremo il programma sudo, modificando il file

/etc/sudoers

# User alias specification
#### inserisci qui gli utenti sviluppatori ####
User_Alias     JBOSS_DEVEL = bruno, pippo 
# Cmnd alias specification
Cmnd_Alias     JBOSS_IDE = /usr/local/eclipse/eclipse
# User privilege specification
JBOSS_DEVEL     ALL = NOPASSWD: JBOSS_IDE

Poi basterà lanciare JBoss IDE con il comando

$ sudo /usr/local/eclipse/eclipse

(ed eventualmente aggiungere un’icona sul desktop che lanci questo comando).

Prima di iniziare a programmare, sarà necessario impostare su Eclipse i parametri del server JBoss nella finestra Run > Debug…, cliccando a sinistra su JBoss 4.0.x e poi su New.
Ovviamente la home directory deve essere impostata su

/opt/jboss

A questo punto sarà possibile iniziare un nuovo progetto J2EE, aggiungere componenti come EJB e Servlet, impostare le XDoclet, effettuare il packaging ed eseguire debug e deploy sulle proprie web-app! :)

Adesso la cosa migliore da fare è seguire un buon TUTORIAL per imparare velocemente ad usare tutti questi simpaticissimi giocattoli :)

Tempo fa uscirono su alcuni numeri consecutivi di una rivista (non ricordo quale) degli inserti con le “Quick Reference Card” di vari linguaggi di programmazione… dei foglietti scritti fitti fitti con tutte le possibili nozioni che spesso si perdono nella memoria del programmatore. Utilissimi! Peccato che me li sono persi.

… fortunatamente in rete si trova di tutto :)

PHP Cheat Sheet

MySQL Database Quick Reference

CSS Cheat Sheet

JavaScript Cheat Sheet

Happy programming!

Google Web Toolkit – Build AJAX apps in the Java language

… così si presenta la nuova idea della “grande G”.

E’ un insieme di librerie che permettono lo sviluppo in via semplificata di applicazioni AJAX anche per chi è all’asciutto di programmazione. Partendo dal Java, si possono utilizzare le classi fornite da Google per poi generare il Javascript necessario a dinamicizzare l’interfaccia web di qualsiasi sito.
Per applicazioni AJAX si intende qualcosa di simile a GMail, Google Calendar, eccetera..

Scelta poco condivisibile, da parte mia, perchè sono sempre stato contro la fornitura di “pappa pronta”. Si corre il rischio di fornire uno strumento molto potente anche a chi non lo sa utilizzare, annullando così la professionalità di chi quelle cose le ha studiate per bene; stessa cosa che successe molto tempo fa con la nascita degli editor WYSIWYG per le pagine web.

Beh.. ecco il link:

Beh.. ecco il link:

E’ tanto che non scrivo. Sia perchè ci sono delle situazioni un po’ troppo delicate in gioco, quindi la mia testa è altrove, sia perchè ho avuto veramente pochissimo tempo.

Ho imparato il Java! :D

In 2 giorni mi sono letto un intero corso… molte cose già le sapevo, perchè sono i fondamenti della programmazione Object Oriented, ma devo dire che come si imparano con Java non si imparano con nessun altro linguaggio!
Quindi… ieri ho finito con il “corso base” e mi sono buttato subito sulla cosa + sfiziosa: la programmazione MIDP1 e MIDP2 per i cellulare J2ME-enabled!!! :D Il primo “Hello World!” spuntato sul display del mio Nokia 6280 è stato troppo emozionante!
Poi ho capito anche come programmare semplici giochini grafici, ma non è esattamente il mio obbiettivo.

Oggi mi sono detto “OK, fin quì tutto facile: perchè non andare a sbirciare un po’ nell’ambiente enterprise?”. Significava installare tutto l’occorrente per J2EE, ma la piattaforma di programmazione più utilizzata costa “una cifra”… quindi mi sono messo d’impegno, ho predisposto la mia Slackware per avviare il demone Tomcat e poi ho installato il plugin Lomboz su Eclipse. Tutto perfetto, soltanto qualche problemino iniziale con i permessi che ho risolto inizialmente in maniera molto… ehm… sbrigativa (777 :P).
Adesso andando con il browser sulla porta 8080 della mia macchina, si apre il mio nuovo mondo :)

Perchè tutto ciò? Beh… perchè il mercato richiede fortemente questo!
Ho detto tutto……..