Italian:
Da oggi è disponibile su sourceforge all’indirizzo https://sourceforge.net/projects/ftpsitedeployer/ il nuovo plugin FTP per NetBeans “FtpSiteDeployer”.
Permette agli sviluppatori che si occupano di applicazioni web scritte in Java di inviare agevolmente le modifiche direttamente da NetBeans usando un semplice menu contestuale,
direttamente sul file interessato. La versione corrente è in beta, distribuita con licenza GNU GPL, quindi completamente free, i contributi sono ben accetti.
Aggiornamento
- Nuova core library per il client FTP
- Nuovi mesasggi durante l’upload dei files.
English:
FtpSiteDeployer is a Netbeans plugin. Allows you to upload a single file to an ftp server. Was designed and is particularly usefull for upload changes to a web site developed in Java. The connection data are stored in the root of the project. This plugin allows to transfer a single file or a folder from the project view inside the Netbeans IDE. The plugin add a voice to the contextual menu called “upload file”.
Update
- New core library for FTP Client
- New messages during upload
Il plugin è ancora in fase di sviluppo, le funzionalità di base sono già disponibili.
Ormai l’HTML 5 è una realtà di fatto. Si aprono dunque nuove possibilità di sviluppo, l’HTML5 supporta una serie di nuove funzionalità che l’ormai collaudato e conosciutissimo HTML 4.x non può avere.
HTML 5 è di fatto un linguaggio nuovo e a questo punto la mia domanda diventa: è possibile sviluppare applicazioni e siti web compatibili nel layout per smartphone e tablet con l’HTML5?
Io credo di sì!
In effetti se facciamo un breve quadro generale, vediamo che nel mondo degli Smartphone e Tablet il predominio si divide in soli due sistemi operativi (iOS per iPhone e iPad) ed Android. Come ben sappiamo sviluppare una App per iPhone/iPad richiede la conoscenza dell’Objective C++, un Mac ecc, mentre per Android serve essere a conoscenza di Java. Seppure Java e l’Objective C++ sia parenti, i metodi di programmazione sono sostanzialmente diversi. Dunque se è necessario sviluppare una applicazione per entrami si Sistemi Operativi perchè voglio coprire il 90% del mercato dovrei programmare due apps: questo vuol dire doppio tempo di sviluppo, doppia manutenzione ed altre problematiche che non è il caso di affrontare adesso.
A questo punto direi che l’HTML5 ci viene prontamente in aiuto: perchè sviluppare due interfacce grafiche quando posso realizzarne una in HTML5 e javascript e ridurre il core (o la Business Logic) della applicazione a poche “righe di codice”? Se infatti una app per smartphone, non fa nient’altro che interrogare una base di dati (magari su XML) e visualizzare i vari risultati delle interrogazioni l’HTML5 e Javascript sono più che sufficienti.
Lo sviluppo per HTML5+Javscript per dispositivi mobile è già una realtà a tale proposito vi vorrei indicare due interessanti framework adatti anche allo sviluppo per mobile:
Se provate le demo di questi due framework javascript, ricordatevi di utilizzare un dispositivo Touch, altrimenti non funzionerà quasi nulla! Come potete vedere dalle demo dei due framework le interfaccie realizzate non hanno nulla da invidiare a quelle delle app programmate con Objective C++ e Java. Ovviamente sto parlando di apps non di games.
Nel caso in cui dobbiate installare un webserver sul vostro Android, vi consiglio di provare il seguente prodotto:
In questo modo potrete fare girare la vostra app in HTML 5 + Javascript senza essere collegati ad Internet.
Oggi ho voluto fare un test di performance molto semplice con java per cercare di migliore al massimo le performance nella esecuzione di contenuti dinamici di un sito web, senza tralasciare il discorso garbage collector. Per fare ciò ho realizzato una semplicissima classe che “spreca” un po’ di tempo nel fare operazioni inutili e l’ho fatta girare con vari settaggi. Riporto il codice sorgente della pagina di seguito è una classe semplicissima.
/*
* Testperformace.java
*
* @author l.ciocci
* Created on 5 febbraio 2010, 10.09
*
* Questa è una classe di esempio per verificare le performance della JVM.
* L'idea è quella di verificare le differenze tra la jvm in configurazione
* server e quella in versione standar
*
* Provare ad eseguire con
* java -server Testperformace
*
* oppure
*
* java -client Testperformance
*/
import java.util.LinkedList;
import java.lang.StringBuffer;
public class Testperformace {
public static void main(String[] args) {
long start=System.currentTimeMillis();
LinkedList list=new LinkedList();
StringBuffer sb=new StringBuffer();
System.out.println("Inizio l'esecuzione di Testperformance\n");
//Perdo un po' di tempo
for (int i=0;i<10000;i++) {
//Genero un numero casuale e lo memorizzo nella linked list
String str=new String();
sb.append(i);
str=sb.toString();
list.add(str);
//if (i%1000==0) System.out.print(".." + i);
}
long stop=System.currentTimeMillis();
long time=stop-start;
System.out.println("\nL'esecuzione ha impiegato: " + time + " millisecondi");
}
}
La classe usa un banale conteggio dei millisecondi passati dall’inizializzazione fino al termine dell’esecuzione.
La versione di java che utilizzo è la OpenJDK Runtime Environment (build 1.6.0_0-b11).
Ho fatto varie prove di esecuzione lanciando la classe con il comando:
java -server Testperformace
L’esecuzione ha impiegato: 895 millisecondi (Ovviamente le performance dipendono dalla configurazione hardware e software della vostra Workstation). Le successive esecuzioni hanno dato tempi comparabili.
Utilizzado lo switch:
java -client Testperformace
L’esecuzione ha impiegato: 760 millisecondi. E gli altri test hanno dato tempi comparabili.
Ma la cosa che mi ha sorpreso più di tutte è questo swith passato alla JVM, un po’ “segreto”:
java -XX:+AggressiveHeap Testperformace
In questo caso il tempo medio per eseguire l’applicazione è stato di soli: 391 millisecondi!!!
Ho poi fatto qualche altro test su pagine JSP ottendo ottimi benefici in termini di velocità. Lo switch in questione però impedisce di fare un corretto profiling della memoria con Netbeans (almeno nella mia Linux Box) e di non sembra funzionare bene in debug. Lo switch -XX:+AggressiveHeap sembra destinato all’uso di applicazioni che devono girare per lunghi periodi senza dovere essere riavviate. Molto Interessante!!!
Chi ha visitato di recente la pagina webmaster tools di Google avrà notato che è da un po’ di tempo che WT propone la sezione “velocità del sito” ed in questa sezione si fa riferimento ad un plugin per Firefox (e che si appoggia a Firebug) dal nome Pagespeed. Nota: è da ieri che è uscita la versione 1.6 beta per Firefox 3.6.
Quando Google consiglia una cosa in genere è perchè la ritiene molto utile e quindi vale la pena studiarla. Pagespeed non è difficile da installare ma per il corretto funzionamento richiede come già detto l’installazione di un altro comodissimo plugin Firebug davvero utile agli sviluppatori.
Per attivare Pagespeed è sufficiente fare clic sulla icona di Firebug (in genere posta in basso a destra) nella status bar del browser Firefox, selezionare l’opportuna scheda e premere il pulsante Analize Perfomance.Lo scopo principale di Pagespeed oltre ad aiutarvi a rilevare qualche errore è quello di ottimizzare in termini di velocità il vostro sito web.
Prendiamo come esempio il sito web http://www.clicfoto.it. Porto questo sito come esempio in quanto ha una struttura un po’ complessa e questo porta sicuramente ad una maggiore necessità di ottimizzazione. Inoltre è realizzato con un uso di CSS e table e non solamente con l’uso di tag div.
Effettuando l’analisi con pagespeed ottengo i seguenti risultati:
L’indice di velocità complessivo è di 77/100 ed il messaggio è “Significant performance improvement are possible”
In primo luogo possiamo vedere qualche segnalazione “grave” mostrata in rosso e altre segnalazioni di media entità segnalate in giallo.
Ad esempio segnalate come “grave”:
- Leverage browser caching
- Combine external JavaScript
- Specify image dimensions
- Parallelize downloads across hostnames
Segnalate come “warning”:
- Combine external CSS
- Leverage proxy caching
- Serve static content from a cookieless domain
- Use efficient CSS selectors
In linea teorica possiamo intervenire su tutte le segnalazioni, ma nella pratica dei fatti può essere molto impegnativo risolvere tutti i problemi.
I problemi evidenziati possono (o devono) essere risolti su due livelli:
- Livello di configurazione del server
- Livello di ottimizzazione delle pagine web.
Correzione dell’errore Leverage browser caching
L’errore Leverage browser caching può essere risolto a livello di configurazione di Apache attraverso l’uso del modulo mod_expires.
Verificate di avere nel vostro httpd.conf la linea:
LoadModule expires_module modules/mod_expires.so
Che consente ad apache di utilizzare alcuni meccanismi di caching. Dopodichè nella configurazione del vostro VirtualHost dovete andare ad aggiungere qualche informazione del tipo:
<Directory /home/percorsodelmiosito/images >
ExpiresActive On
ExpiresDefault "access plus 1 month"
</Directory>
<Directory /home/percorsodelmiosito/css >
ExpiresActive On
ExpiresDefault "access plus 1 month"
</Directory>
In questo modo specificate al browser che i file contenuti nelle directory “css” ed “images” non sono soggetti a cambiamenti e Firefox eviterà di ricaricarli.
Ovviamente questo tipo di ottimizzazione è possibile farla solamente se disponete di un hosting che vi consente di lavorare a livello professionale. In genere queste configurazioni non sono disponibile per gli hosting di tipo “economico”
Correzione dell’errore Parallelize downloads across hostnames
Anche questa correzione è possibile effettuarla solamente a livello di server. In pratica sono necessari almeno due “hosting” uno che fornisce il contenuto statico e l’altro quello dinamico. Tutte le immagini statiche dovrebbero essere spostate su un hosting statico del tipo static.clicfoto.it e tutti i percorsi alle immagini saranno del tipo src=”http://static.clicfoto.it/images/mia-immagine” (il link indicato non funziona è solo un esempio).
Correzione Serve static content from a cookieless domain
Questo errore si collega al precedente e può essere risolto nello stesso modo. Nel caso di un sito dinamico come ad esempio http://www.clicfoto.it viene settato un cookie per gestire la sessione. Il consiglio riportato è di fornire tutti i contenuti statici da un hosting parallelo che non setta cookie.
Correzione dell’errore Combine external JavaScript
La correzione di questo errore avviene a livello di programmazione della pagina web. E’ buona norma unire tutti i file javascript in un’unico file: in tal modo il parsing degli script è molto più veloce. Sebbene questa pratica non sia difficile da implementare risulta molto scomoda per i programmatori in quanto dividere gli script in varie parti facilita in genere il debug e l’aggiornamento a nuove versione.
Correzione dell’errore Combine external CSS
Analogamente a quanto specificato per i javascript la stessa operazione può essere fatta sui fogli di stile.
Correzione dell’errore Specify image dimensions
Questo è facilissimo da risolvere in tutti i tags img bisognerebbe sempre specificare l’altezza e la larghezza. In questo modo il broser limita i calcoli da fare per il ridimensionamento dell’immagine in quanto si trova già le dimensioni in termini di altezza e larghezza da raggiungere.
Correzione dell’errore Use efficient CSS selectors
Il consiglio in questo caso è di evitare di utilizzare selettori css troppo innestati ad esempio evitare #primostile #secondostile #terzostile. Lo strumento Pagespeed fornisce informazioni su quali selettori sono inefficienti nella pagina.
Personalmente cerco di limitare a due selettori la maggiorparte dei DIV anche se questo non è sempre possibile.
Analisi post ottimizzazione
Dopo aver fatto qualche ottimizzazione al sito http://www.clicfoto.it il risultato è questo:
Il punteggio in termini di velocità è: 82/100 è il messaggio di Pagespeed è: “Moderate performance improvements are possibile”. Questo risultato è stato ottenuto utilizzando solamente le correzioni di “Leverage browser caching” e di “Leverage proxy caching” ovviamente è possibile migliorare ancora, ma il risultato è già abbastanza soddisfacente!
Ecco una cosa di cui si parla molto, ma di cui si sa “relativamente” poco. I linguaggi object oriented ci hanno abituato molto bene, ci consentono di creare e distruggere oggetti in modo molto semplice senza doverci occupare della gestione della memoria: chi ha utilizzato il C si ricorderà della funzione malloc per allocare la giusta quantità di memoria ad esempio per un’array, chi utilizza solamente Java penserà che cosa inutile basta dichiarare:
ArrayList array=new ArrayList();
senza occuparmi di quanta memoria utilizza l’array!
In una applicazione web (o desktop) dichiariamo gli oggetti che ci servono li usiamo e alla fine ce ne dimentichiamo, tanto implicitamente è naturale pensare “ci pensa il garbage collector”. Ma è sempre vero? La risposta è semplicemente “No”. Il garbage collector funziona bene, ma non è perfetto e può essere aiutato da qualche semplice accorgimento.
Questo è poi particolarmente vero per le applicazioni web che magari devono funzionare per diversi giorni (o mesi) senza essere mai riavviate. Nelle applicazioni desktop infatti nella peggiore delle ipotesi si “blocca” la singola applicazione. Chiudendo il programma o facendolo ripartire in linea teorica torna tutto come prima.
Nel caso di un sito web dinamico o di una applicazione web invece si blocca l’intero sito precludendo di fatto l’utilizzo dei servizi o la consultazione da parte degli utenti collegati. In questa serie di articoli farò riferimento alle applicazioni web in particolare modo ed al loro sviluppo con Java.
In primo luogo un buon design del codice permette di evitare sprechi inutili di memoria. In secondo luogo non dobbiamo mai dimenticare che una pagina web può essere visitata da più di un utente contemporaneamente, e quindi sicuramente spreca molte risolte, anche in questo caso un design pulito aiuta a risparmiare memoria ed incrementare prestazioni.
In ogni caso anche un sito web concepito in modo assolutamente perfetto necessita di una determinata quantità di memoria per funzionare. E java permette di specificare quanta memoria assegnare alla Java Virtual Machine (JVM) tramite l’utilizzo della variabile JAVA_OPTS.
JAVA_OPTS=" -Xmx764m -Xms256m -server"
In questa riga ci sono 4 parametri interessanti che saranno passati alla JVM
-Xmx764m indica di utilizzare fino a 764 megabyte di memoria per l’heap
-Xms256m indica di utilizzare un minimo di 256 megabyte di memoria per l’heap
-server indica alla JVM di funzionare in modalità server, in questa modalità la JVM ha una migliore gestione del garbage collector (inoltre c’è chi dice che ha performance superiori, ma non ho ancora verificato).
…continua a presto!!!
Quante volte vi è capitato di volere rinominare più di un files contemporaneamente? Questo semplicissimo script in shell è facilissimo da usare e consente di fare questa operazione.
#!/bin/bash
# renames.sh
#Questo script sostituisce in una lista di file il carattere punto interrogativo con un underscore
for i in $( ls *htm* );
do
src=$i
tgt=$(echo $i | tr ? _ )
mv $src $tgt
done
Effettuate un chmod 755 rename.sh per potere utilizzare lo script. Lo script è davvero molto semplice e la parte centrale del programma consiste nel comando “tr” che è molto pratica e semplice da usare. Potete digitare tr –help per vedere le innumerevoli opzioni di questo comando. In questo caso viene utilizzato per sostituire il punto interrogativo con l’underscore.
Quindi nel codice riportato sopra tutti i files presenti nella directory di esecuzione dell script nel cui nome è presente la stringa “htm” subiranno la sostituzione del “?” con un “_”.
Ad esempio il file:
search.htm?marca=ferrari
diventa
search.htm_marca=ferrari
Questo script (o una versione migliorata e più avanzata) può essere utile ad esempio in abbinamento al comando wget che serve per effettuare il download di un sito web o di una parte di esso. Nel caso esposto sopra ad esempio viene “scaricato” una pagina che richiede un parametro marca=ferrari passato nella query string. Tuttavia nella maggior parte dei filesystem il carattere “?” è un carattere speciale e non può essere utilizzato, e quindi potrebbe essere necessario sostituirlo con una carattere differente.
Più di una volta in abito informatico è utile implementare una coda del tipo FiFo (First In First Out). Nel nostro caso vogliamo realizzare una coda di questo tipo per gestire i backup. Questo tipo di coda ha un funzionamento molto semplice: il file più vecchio viene cancellato, lasciando spazio al file nuovo.
Supponiamo di volere fare il backup in una cartella del tipo /mnt/backup
e di volere backuppare tutta la etc (la cartella dove sono memorizzati molti file di configurazione di linux).
Le operazioni da eseguire sono semplicemente tre:
1)Cancellazione del file di backup più vecchio
2)Creazione del nuovo file di backup.
3)Schedulare l’operazione con il cron daemon (opzionale)
Come comando per il backup utilizzerò il tar (semplice potente e veloce), ovviamente con le dovute modifiche potete utilizzare qualsiasi altro comando.
#Eliminazione del primo file ( il piu vecchio nella lista)
delFileNameEtc=$(ls /mnt/backup/bkpetc* | head -n1)
rm $delFileNameEtc
#Creazione di un nuovo backup per etc
fileName=$(date +%y%m%d)
tar cfvz /mnt/backup/bkpetc$fileName.tar.gz /etc
Il succo di questo script è racchiuso in due istruzioni:
1) Selezione del primo file: ls /mnt/backup/bkpetc* | head -n1
2) Creazione di un identificativo progressivo (in questo caso giornaliero) utilizzando il comando $(date +%y%m%d)
L’ultima operazione fondamentale è decidere la dimensione della coda FiFO per fare ciò è sufficiente creare nella cartella di backup un determinato numero di file vuoti.
Il numero dei file sarà la dimensione della coda:
cd /mnt/backup/
echo "" > bkpetc20091201.tar.gz
echo "" > bkpetc20091202.tar.gz
...
echo "" > bkpetc20091207.tar.gz
In genere io utilizzo uno script simile a questo in abbinamento con il CRON daemon di Linux, al fine di pianificare alcuni backup giornalmente, mantendo uno storico (nell’esempio in questione di 7 giorni). Ovviamente esistono software molto più sofisticati che offrono molte altre possibilità, ma se non volete spendere una fortuna Uno script simile potrebbe essere una buona base di partenza.
Per generare in modo semplice dati di test può essere utile utilizzare la funzione rand() di mysql. La funzione rand() genera un valore in virgola mobile compreso tra 0
Data se volessi fare il fill di dati interi (ad es da 1 a 10) di una tabella di test potrei eseguire un determinato numero di volte lo statement:
insert into MIATABELLA(MIACOLONNA) values (FLOOR(1+RAND()*(10-1)));
Quindi eseguendo N volte l'istruzione di sopra ottengo N record;
Se dovessi fare il fill della tabella con dei caratteri dovrei utilizzare la funzione CHAR().
Ricordando che CHAR(65) corrisponde al carattere A e che CHAR(90) corrisponde al carattere Z posso campiare l'istruzione di insert nel seguente modo:
insert into MIATABELLA(MIACOLONNA) values (CHAR(FLOOR(65+RAND()*(90-65))));
Sapendo che la funzione CHAR() supporta più argomenti interi cioè con CHAR(65,65,65) si ottiene la string AAA potrei randomizzare delle string di 3 caratteri ad esempio nel seguente modo:
Alcune volte per monitorare correttamente il carico di un server mysql può essere utile interogare il motore del database per sapere quali processi sono attivi.
Il comando per effettuare questo controllo è:
mysqladmin processlist
Quindi eseguendo il comando per localhost ed utilizzando lo switch -u root per specificare l’utente si ottiene:
Il comando mysqladmin prevede come switch:
-u per specificare lo username
-p per specificare la password
non è invece necessario passare il nome del database in quanto tale comando lavora a livello di server di database, mostrando normalmente tutti i processi per tutti i db che sono sul server.
Il comando mysqladmin può essere particolarmente utile per verificare qual’è il carico sul server e quelle che sono le connessioni ad un database.
Supponiamo ad esempio di avere una classe Java o una procedura realizzata con un qualsiasi linguaggio di programmazione e che per a causa di un bug tale funzione non chiuda la connessione correttamente. Dopo un determinato numero di chiamate a tale funzione tramite il comando mysqladmin processlist si potrà monitorare l’esistenza di un numero elevato di connessioni al database che non sono mai state chiuse!!! Questo problema potrà nel giro di poco tempo portare alla saturazione delle connessioni disponibili causando senza dubbio un problema nell’applicativo.