Author: Michele Bologna

  • Sondaggio per i miei lettori: how about writing in English?

    Un piccolo sondaggio che vorrei proporre ai miei lettori, nato da un’idea che mi è venuta ma che vorrei approfondire.

    Innanzitutto, la situazione corrente: questo sito è scritto in italiano per lettori italiani, e tradotto automaticamente in inglese.

    Ora, invece, mi stavo chiedendo se fosse il caso di cambiare, ovvero di scrivere i miei post in inglese, e tradurli automaticamente in italiano. La lingua principale di questo sito, praticamente, sarebbe l’inglese.

    Il cambiamento non è indolore: sia per i lettori che non masticano l’inglese, sia per il posizionamento del sito (è più facile posizionarsi nelle SERP italiane che in quelle inglesi), sia per me: non sono madrelingua inglese! Tuttavia, il cambiamento porterebbe anche alcuni vantaggi: più visibilità per il sito e quindi (sperabilmente) più visite, le possibilità di far conoscere e di interagire in modo più veloce con attori non-Italian speaking e perché no, anche un modo per migliorare il mio inglese.

    Ma prima di intraprendere questo percorso, volevo chiedere ai miei lettori: cosa ne pensate?

  • Ubuntu: esportare/importare la lista dei pacchetti installati

    Il punto di forza di Ubuntu, è, tra gli altri, l’utilizzo del package manager di Debian: apt-get (e più in basso nello stack applicativo, di dpkg); alcune volte realizzo un setup (in termini di pacchetti) su una particolare box Ubuntu che vorrei poter esportare su un’altra box. In altre parole, vorrei generare una lista di tutti i pacchetti installati e installarli, automaticamente, su un’altra macchina.

    dpkg offre questa possibilità. Cominciamo con la creazione dell’elenco dei pacchetti installati:

    dpkg --get-selections | grep -v deinstall > installed.txt

    Sulla macchina target, impostiamo la selezione dei pacchetti da installare e installiamo i pacchetti mancanti:

    dpkg --set-selections < installed.txt
    sudo dselect

    Finito!

  • Google Correlate (Draw) e l’importanza dei QR Code

    Oggi ho provato uno strumento messo a disposizione da Google: Google Correlate Draw. Come funziona? Si disegna una curva (di funzione) su un piano dove l’asse delle ascisse è il tempo, e sulle ordinate il numero di ricerche effettuate dagli utenti su Google. Il risultato è chiaro: mostrami tutti le ricerche (negli stati uniti) che hanno seguito l’andamento che ho disegnato sul piano.

    Ci ho “giocato” per alcuni minuti, e poi ho disegnato un’iperbole equilatera (si, è un’iperbole equilatera ruotata di 90° e traslata) con il massimo nel 2011, e ho osservato i risultati.

    google_correlate_draw

    Tra i risultati ritornati con un alto coefficiente di correlazione r, troviamo che le ricerche per il termine “QR Code” hanno l’andamento desiderato: segno del fatto che i QR Code stanno sempre più prendendo piede, e molte più persone si documentano a riguardo. Il tutto con un’andamento che è quello di iperbole equilatera. Sorprendente!

    UPDATE: Google Correlate Draw è stato dismesso da Google nel dicembre 2019.

  • Applicazioni desktop vs. Applicazioni cloud

    Ultimamente si parla molto di cloud computing e in particolare di SaaS: il paradigma cloud sta guadagnando sempre più interessa da parte delle aziende perché permette di abbassare i costi, una più facile manutenzione e un utilizzo semplice per gli utenti. Ma d’altra parte ci sono tante motivazioni per mantere un applicativo nella sua versione desktop, primo fra tutti l’utilizzo della banda.

    Un semplice esempio per capire meglio di cosa parliamo. Un’applicazione desktop è un’applicazione che viene eseguita fisicamente sul vostro computer: è stata precedentemente installata e viene distribuita sotto forma di applicazione che può essere installata dall’utente. Un esempio: Skype.

    Un’applicazione, cloud, invece risiede su una nuvola (da qui ‘cloud’): viene resa fruibile attraverso la connessione ad un altro sistema (tramite Internet ad esempio). Non richiede un’installazione (l’utente di solito accede all’applicazione da un browser) ma richiede una connessione ad Internet per essere utilizzata. Un esempio: Gmail.

    Dopo aver riflettuto sui vantaggi dell’una e dell’altra soluzione, ho deciso di condividere il mio parere riguardante le due soluzioni.

    Applicazioni desktopApplicazioni cloud
    Installazione del softwareL’applicazione deve essere installata prima di essere utilizzata.Nessuna installazione è richiesta (a parte il browser se l’applicazione verrà fruita tramite browser).
    Utilizzo delle risorseL’applicazione utilizza le risorse della macchina su cui è installata. Per applicazioni che hanno un carico computazionale cospicuo sono presenti requisiti hardware ben definiti.Il carico computazionale è quasi interamente gestito dal service provider che offre il servizio, riducendo i requisiti hardware della macchina che utilizza il servizio.
    AggiornamentiL’applicazione deve essere aggiornata manualmente dall’utente o da un amministratore di sistemaL’utente accede sempre all’ultima versione del software disponibile senza dover installare nulla: l’applicativo caricato dal browser è sempre aggiornato dal service provider, nulla è a carico dell’utente.
    Indipendenza dalla piattaformaAlcune applicazioni sono disponibili solo per determinate piattaforme (es. MacOSX, Windows), lasciando scoperte altre piattaforme comunque utilizzate da alcuni utenti (Linux, FreeBSD).Dato che molte applicazioni sono fruibili tramite un browser, molte delle applicazioni cloud sono indipendenti dalla piattaforma dell’utente
    Indipendenza/Utilizzo della reteUn applicativo desktop è indipendente dalla presenza della rete (se la funzione principale non è quella di utilizzare la rete).Senza connessione di rete, un’applicazione cloud non può funzionare (a meno di meccanismi di caching previsti dal browser [es. Google Gears/HTML5 Web Storage] e/o dallo sviluppatore dell’applicazione).Inoltre, il footprint di un’applicazione cloud sulla rete è tipicamente molto forte rispetto all’equivalente di un’applicazione desktop, proprio per la maggiore quantità di dati scambiati con la controparte remota.
    Autenticazione e autorizzazioneL’autenticazione e l’autorizzazione sono demandate al sistema operativo. Dato che questa pratica è tipicamente consolidata e ben documentata, un’applicazione desktop è solitamente più sicura della controparte cloud (sia del punto di vista della security fisica che di quella logica).L’autenticazione e l’autorizzazione sono realizzate su una rete che non sicura quale Internet, che può essere manomessa e/o monitorata. L’utilizzo di soluzioni di cifratura è una soluzione d’obbligo per proteggere i dati che transitano dal service provider all’utente finale.
    BackupI dati sono solitamente memorizzati sul pc dell’utente, che deve provvedere ad effettuare un backup cadenzato dei dati (se non previsto dall’amministratore di sistema).I dati sono quasi interamente gestiti dal service provider, che, in base al SLA garantito all’utente, deve provvedere al corretto backup dei dati e al ripristino in caso di failure.Inoltre, come già detto, questo comporta un utilizzo massimo della banda per trasferire i dati dal service provider al pc dell’utente finale.

    Quindi, qual è la soluzione migliore? Il desktop o il cloud?

    Ultimamente, la tendenza è quello di portare molte applicazioni sul cloud, e di associare al cloud tutte le applicazioni che possono essere richiamate tramite un browser. Ricordo che un’applicazione cloud deve rispettare diversi aspetti per essere chiamata cloud:

    • deve essere indipendente da piattaforma e hardware utilizzati dall’utente
    • deve supportare l’accesso tramite API
    • deve essere accessibile tramite qualsiasi sistema connesso a Internet
    • deve essere trasparente per l’utente da utilizzare indipendentemente da dove l’applicazione venga installata.

    Qual è la soluzione migliore? La risposta giusta, come al solito, è dipende. Dipende da molti fattori, come possiamo vedere, e ognuna delle due soluzioni ha i suoi punti di forza e di debolezza.

  • PHP5 e MySQL, la guida: la mia recensione

    php_mysql_guida

    Per ripassare le mie nozioni di PHP5, ho deciso di leggere il libro di McGraw-Hill, “PHP5 e MySQL, la guida“, composto da circa 1100 (!) pagine. Perché proprio PHP? Peché, PHP è un linguaggio di successo, sebbene non venga presentato nei migliori dei modi (“è un linguaggio per principianti”). Ecco almeno 4 ragioni per cui conoscere PHP è un plus:

    1. è attualmente il quarto linguaggio più diffuso in termini di codebase OSS;
    2. il più utilizzato e diffuso social network lo utilizza (anzi, lo migliora!);
    3. i CMS più famosi (WordPress e Drupal) sono sviluppati in PHP;
    4. sapevate che anche Wikipedia lo utilizza?
    Passiamo al libro: la lettura non è molto agevole (ci sono errori di battitura, traduzioni forzate dall’inglese, snippet di codice senza alcun syntax highlighting [non parlo del colore, ma almeno del bold!]) ma tutto sommato riesce a spiegare esaurientemente bene tutte le peculiarità di un linguaggio di successo quale PHP.
    Il libro passa in rassegna ogni aspetto del linguaggio, quali:
    • le basi del linguaggio
    • i tipi e la OOP con PHP5
    • la connessione ai database MySQL/PostgreSQL/Oracle
    • il package manager PEAR
    • l’utilizzo di sessioni e cookie
    • l’implementazione di servizi REST e SOAP

    Il libro termina con una serie di esempi svolti e analizzati. In definitiva il libro è un ottimo manuale per imparare (da zero) il PHP. In alcuni punti è spesso prolisso e ripetitivo; rappresenta tuttavia una buona miniera di informazioni e di reference per quando si deve sviluppare in PHP. La parte relativa all’approfondimento relativo all’integrazione con i database è lasciata a 3 capitoli (sebbene molti esempi siano presenti in tutto il libro); soluzione che ritengo comprensibile, visto il proliferare di ORM (come Doctrine) che “nascondono” i tweaking un tempo necessari per la connessione al db).

    In definitiva, un libro buono, ma non indispensabile: esistono libri più economici (e soprattutto più compatti!) che permettono di ottenere la stessa infarinatura di PHP.

  • Quali sono le applicazioni compatibili con Mac OS X Lion?

    Dopo la recente uscita di MacOSX Lion, ho scelto di fare un clean install di Mac OSX senza fare l’aggiornamento da Snow Leopard (anche se non esiste il DVD di Lion è possibile crearlo). Di conseguenza, ho colto l’occasione per fare una reinstallazione completa delle applicazioni che utilizzo maggiormente, tralasciando di installare quelle poco utilizzate.

    «The more I look at you, the more I'm hungry!»

    Alcune applicazioni, come Dropbox, non funzionano (ancora) con Lion. In attesa che i programmatori sistemino il problema, come possiamo sapere se una particolare applicazione è compatibile con Lion (oltre che controllare sul sito ufficiale o sui forum)?

    RoaringApps è un ricco database aggiornato con lo stato di compatibilità (per Lion) di ogni applicazione. Utilissimo prima di installare qualsiasi applicazione ma anche e soprattutto per scoprirne altre. Da controllare prima di installare qualsiasi applicazione su Lion!

  • Google Chrome: le estensioni consigliate che utilizzo (e i flags che ho impostato)

    Da un po’ di versioni anche Chrome permette di installare le famose estensioni (come in Firefox).

    Ecco quelle che utilizzo (la descrizione è self-explanatory!):

    • Adblock Plus for Google Chrome™ (Beta) – Version: 1.1.3Ads were yesterday! The successful extension Adblock Plus is now available for Google Chrome™.
    • Awesome Screenshot: Capture & Annotate – Version: 3.0.4Capture the whole page or any portion, annotate it with rectangles, circles, arrows, lines and text, blur sensitive info, one-click upload to share. Support PNG and shortcuts.
    • Bookmark Sentry– Version: 1.6.5A bookmark scanner that checks for duplicate and bad links.
    • Chrome Sniffer– Version: 0.2.8Detect web applications and javascript libraries run on browsing website.
    • Facebook Purity– Version: 1.0Removes application spam and other clutter from your facebook homepage
    • goo.gl URL Shortener– Version: 0.6.2Shorten url with goo.gl, the Google URL shortener, and share with many different service!
    • iReader– Version: 1.3.0.2View news stories and other articles in a very easy to read, clutter-free, scrollable display.
    • LastPass– Version: 1.73.3LastPass is a free password manager and form filler. LastPass is also available for Firefox, Internet Explorer and Safari.
    • Page Speed– Version: 1.11.2Analyze the performance of your webpages and get specific suggestions on how to optimize them.
    • Postponer Adder– Version: 0.4Add items to your Read It Later reading list
    • RSS Subscription Extension(by Google) – Version: 2.1.3Adds one-click subscription to your toolbar.
    • WiseStamp– Email Signatures for GMail, Google Apps and more – Version: 2.0.10.0Empower GMail, Google Mail & Google Apps emails with dynamic email signatures. Add Twitter, Facebook, Digg and more. Multiple HTML signatures support.
    • WordReference Extension– Version: 3.7.1WordReference Extension – Get the translations you want, in a fast and easy way !
    • Xmarks Bookmark Sync– Version: 1.0.14Backup and sync your bookmarks, passwords and open tabs across computers and browsers. Xmarks is also available for Firefox, Safari and IE.

    Inoltre, Chrome ha messo a disposizione una funzionalità interessante, ovvero i flags, cioé un modo di abilitare/disabilitare alcune funzionalità avanzate tramite un url specifico (visitate about:flags dal vostro Chrome). In particolare, a questo proposito segnalo l’utilissimo di abilitare “Click to play” che permette di abilitare il contenuto Flash di un sito solo su vostra richiesta e definendo una white-list di siti che possono utilizzare Flash.

  • Java: come scrivere un build.xml di ant per compilare e pacchettizzare (WAR/EAR)

    Come sapete, tutti i Java application server (come ad es. Tomcat) richiedono il deploy di un applicativo sottoforma di un pacchetto EAR. Ma come è composto un pacchetto EAR?

    Un pacchetto EAR non è altro che un file jar (che a sua volta è un file zip) che contiene al suo interno:

    • un descrittore di deploy, sotto la directory META-INF (application.xml) che contiene informazioni di gestione riguardo all’applicazione in corso di deploy, come il nome, il contextpath, etc.
    • generalmente, contiene un file WAR che contiene, al suo interno, il modulo web J2EE dell’applicazioni.

    A sua volta, un file WAR è un file JAR composto da:

    • il file web.xml sotto la directory WEB-INF che definisce la struttura dell’applicazione web.
    • i file compilati (.class) dell’applicazione posti sotto WEB-INF/classes

    Risalendo a ritroso, per creare un EAR è necessario:

    1. Compilare i files dell’applicazione;
    2. Spostarli sotto WEB-INF/classes insieme ai files della webapp (jsp, files statici, etc.)
    3. Creare un WAR (jar)
    4. Creare un EAR inglobando anche il meta-descrittore del deploy

    Per fare tutto questo è sufficiente usare ant (o meglio maven, ma questo ve lo spiegherò in un altro post!) con diversi target. Vediamo un esempio che ho realizzato:

    <?xml version="1.0" encoding="UTF-8"?>
    <project name="prjTest" default="main" basedir="./">
    
    <property name="component-name" value="prjTest" />
    <dirname property="workspace.path" file="${ant.file.prjTest}/.." />
    <dirname property="ear.dir" file="${ant.file.prjTest}" />
    <property name="target.dir" value="${ear.dir}/target" />
    <property name="deploy.dir" value="${ear.dir}/deploy" />
    <property name="deploy.file" value="prjTest.ear" />
    
    <target name="init">
    <mkdir dir="${target.dir}/classes" />
    <mkdir dir="${deploy.dir}" />
    </target>
    <target name="clean">
    <delete dir="${target.dir}" />
    <delete dir="${deploy.dir}" />
    <delete dir="${workspace.path}/prjTest/WebContent/WEB-INF/classes" />
    </target>
    
    <path id="myclasspath">
    <fileset dir="${workspace.path}/prjTest/WebContent/WEB-INF/lib">
    <include name="**/*.jar" />
    </fileset>
    </path>
    
    <target name="main" depends="clean,init">
    <javac srcdir="${workspace.path}/prjTest/JavaSource" destdir="${target.dir}/classes" includes="**/*.java"
    source="${source}" target="${target}"
    classpathref="myclasspath">
    </javac>
    
    <copy todir="${workspace.path}/prjTest/WebContent/WEB-INF">
    <fileset dir="${target.dir}">
    <include name="**/*" />
    <exclude name="**/.metadata/*" />
    </fileset>
    </copy>
    <copy todir="${workspace.path}/prjTest/WebContent/WEB-INF/classes">
    <fileset dir="${workspace.path}/prjTest/JavaSource">
    <include name="**/*.properties" />
    </fileset>
    </copy>
    
    <war destfile="${target.dir}/prjTest.war" webxml="${workspace.path}/prjTest/WebContent/WEB-INF/web.xml">
    <fileset dir="${workspace.path}/prjTest/WebContent" />
    </war>
    
    <ear destfile="${deploy.dir}/prjTest.ear" appxml="${workspace.path}/prjTest/META-INF/application.xml">
    <fileset dir="${target.dir}" includes="*.jar,*.war" excludes="**/.metadata/*" />
    </ear>
    </target>
    </project>
    

    Come potete vedere il target chiamato “main” si occupa di:

    • compilare tutte le classi del progetto (javac) usando il classpath di riferimento
    • copiare i files di configurazione (come il già menzionato web.xml) sotto /WEB-INF (copy)
    • copiare i compilati delle classi sotto /WEB-INF/classes (copy)
    • creare un archivio WAR (war) usando i files specificati in fileset e usando il web.xml specificato sotto webxml
    • creare un archivio EAR (ear) usando i files specificati in fileset usando il meta-application specificato in appxml e copiando i files da fileset.

    Questo è lo scheletro di build.xml che uso per pacchettizzare velocemente un’applicazione J2EE (infatti basta lanciare ant build.xml main) da linea di comando per compilare, copiare tutti i files necessari e creare WAR ed EAR!).

  • Pressman – “Principi di Ingegneria del Software” – quarta edizione: la mia recensione

    Ad un paio di anni di distanza dal corso di “Ingegneria del Software” frequentato all’università, ho deciso di rileggere il libro di Roger Pressman, “Principi di Ingegneria del Software”, che nel frattempo era avanzato fino alla quarta edizione.

    Il libro è voluminoso (circa 700 pagine) e piuttosto costoso (49 euro), ma rappresenta una pietra miliare nel campo del software engineering. Mettiamo subito in chiaro che su questo libro non si impara a programmare. È un libro che illustra le metodologie, gli strumenti e la teoria dell’ingegneria del software.

    Il libro è diviso in tre parti:

    1. nella prima parte vengono illustrati i modelli di sviluppo del software (il vetusto modello a cascata, il modello iterativo, e gli sviluppi agili);
    2. nella seconda parte vengono presentati gli approcci pratici a tutto il ciclo di vita del software, come la modellazione dei requisiti, gli strumenti per la progettazione del software (come UML) fino alla tecniche di testing (es. black-box e white-box);
    3. nell’ultima parte, infine, vengono presentate le metriche per la stima e per la valutazione della qualità del software

    Il libro non è di facile comprensione, ed è corredato da un esempio di progetto che viene sviluppato dall’inizio alla fine. Pressman presenta in modo completo ed accurato tutti i temi relativi all’ingegneria del software; a mio avviso, considero il libro come una sorta di manuale a cui fare riferimento in ogni momento e ad una lettura basata sullo specifico concetto, più che un libro da una lettura streamlined dall’inizio alla fine (in questo senso l’unico progetto di esempio sviluppato dall’inizio alla fine non aiuta).

    In definitiva: un libro che è una pietra miliare da avere nella propria collezione di libri tecnici. È vero, non è di facile comprensione (soprattutto a chi non ha molta dimestichezza con diversi temi dell’ingegneria del software), ma di sicuro un libro a cui si deve poter fare riferimento in ogni momento.

  • DriveCast: un (audio) registratore per i programmi radiofonici

    DriveCast è un servizio gratuito davvero utile che si comporta da audio-registratore di programmi radiofonici: ad esempio, se il vostro programma radiofonico preferito non offre i podcast delle puntate, ma voi volete registrare la puntata intera, potete usare DriveCast affinché vi registri ogni puntata del programma sotto forma di MP3, e poi fare il download in un secondo momento. Per evitare di saturare lo spazio disponibile, il servizio vi mette a disposizione di alcuni slot in cui memorizzare le puntate registrate; una volta raggiunto il limite, il servizio sovrascrive automaticamente le vecchie puntate. Il mio consiglio è quindi di fare un download periodico delle puntate da ascoltare.

    Il servizio è gratuito e funziona davvero molto bene, e soprattutto è gratuito. Da provare!