Mettere in pratica una campagna di marketing su Internet non è roba semplice, in quanto sono coinvolte tutta una serie di altre discipline e passi che non basterebbe un solo libro per raccontarla. Ad ogni buon conto, si possono ridurre tutti i compiti di gestione a 4 semplici passi illustrati in figura.

I passi basilari di una campagna SEM

1. Pianificazione della campagna. Qual è il mercato contro cui intendiamo batterci? L’analisi di mercato può risultare un’operazione molto complessa e conviene affidarsi a esperti del settore. Occorre individuare chi sono i principali competitor e, di questi, studiarne i trucchi e i fattori chiave che hanno permesso loro di crescere e arrivare al successo;
2. Contenuti. Quando il piano sarà chiaro ecco che bisogna passare alla creazione dei contenuti della nostra campagna. Attenzione: un contenuto può andar bene per un dato veicolo informativo, ma potrebbe risultare poco efficace se cambiamo il mezzo tramite il quale arrivare all’utente finale. Veicolo, mezzo? Useremo un blog per promuovere la campagna di marketing o dovremo agire sui forum? Contenuti testuali o multimediali? Una semplice landing page o un intero sito? Non necessariamente bisogna operare un aut aut fra questi nuovi mezzi di comunicazione, piuttosto è bene scegliere il giusto mix fra blog, forum, testo, video, sito e landing page al fine di ottenere il miglior risultato possibile;
3. Attuazione della campagna. Stabilito il piano e creati i contenuti si passerà alla pratica vera e propria. Occorre non perdere di vista l’obiettivo e attuare le strategie messe a punto nei passi precedenti, con rigore e disciplina, con tenacia e perseveranza;
4. Monitoring dei risultati. Una campagna di marketing mira a ridurre i costi di gestione, aumentare il ROI (Return On Investment) e far crescere le conversioni. Nei costi di gestione rientra ogni tipologia di spesa affrontata in relazione, diretta o indiretta, alla campagna in questione. Il ROI è semplicemente il guadagno registrato al netto dell’investimento sostenuto: è il parametro principe per misurare l’efficienza, ancorché l’efficacia, di una campagna. Le conversioni sono invece una misura di un preciso evento inerente la campagna: per esempio una conversione potrebbe essere relativa al numero di prodotti acquistati in rapporto al totale dei visitatori, o il numero di registrazioni al sito in rapporto agli accessi unici, e via così. Un monitoring costante e preciso permette di poter intervenire in tempo reale sulla campagna così da ottimizzarne i risultati.

Questi sono, a mio avviso, i passi basilari da cui non si può sfuggire per attuare una campagna di marketing che sia completa e di successo.

TeX risultò essere molto potente fin dai primi rilasci, ma era pure uno strumento piuttosto complesso a fronte di risultati finali eccezionali. Fu apprezzato dagli accademici in generale perché facilitava (nonostante ciò possa sembrare in contraddizione con la dicitura “strumento complesso”) la scrittura di documenti scientifici di ogni tipo. Dato il suo livello di complessità Leslie Lamport decise di derivarne un ulteriore linguaggio di markup operante a più alto livello. Nel 1985 venne così lanciato LaTeX, distribuito sotto licenza free. LaTeX conobbe sin da subito un grandissimo successo ed è diventato praticamente quasi uno standard in moltissime università e centri accademici di tutto il mondo per la redazione di documentazione tecnica (fra scienziati, matematici, fisici, chimici, ingegneri e, indifferentemente, cultori delle materie letterarie).

E’ disponibile per tutte le piattaforme, quindi ampiamente utilizzabile su sistemi Microsft, Apple o Unix-like.

In questo articolo mostreremo il suo uso su piattaforma Microsoft Windows, accennando ai vari strumenti che possono essere di aiuto a quanti intendono utilizzarlo per produrre materiale scientifico o di qualsivoglia natura.

Vi anticipo che potete soddisfare ogni vostro dubbio visitando il sito ufficiale della distribuzione o il Gruppo di Utilizzatori Italiani di TeX.

Passo preliminare: installazione di GhostScript

Per prima cosa bisogna installare GhostScript, cioè una sorta di programmi capaci di interpretare il linguaggio PostScript (che serve a descrivere pagine, testi e immagini). Il miglior candidato è proprio GhostScript (scaricabile da questo indirizzo) per il quale esiste una comoda interfaccia grafica e cioè GhostView (il cui sito ufficiale è questo).

Il processo di installazione è semplicissimo e dovrete solamente rispondere a un paio di domande. Occhio soprattutto a quando vi viene segnalato quali formati di file saranno associati a GhostView: in particolare dovrete decidere se aprire i PDF col suddetto programma o continuare a usare il software che più vi piace (tipo Adobe Reader).

Scaricare e installare MiKTeX, questo sconosciuto

MiKTeX è una delle più importanti distribuzioni disponibile per Microsoft Windows capace di mettere a punto un completo ambiente TeX/LaTeX. Nell’ottobre del 2010 è stata rilasciata la versione numero 2.9 (supporta ora pure Windows 7).

Dal sito ufficiale potete scaricare il file di installazione. Ne esistono di due tipi:

1. il NetInstaller che consta di appena 6MB e che si occupa di scaricare tutto da Internet e procedere così a una installazione completa e completamente personalizzabile;
2. l’installer completo di 140MB.

Le schermate del wizard di installazione sono semplici da capire. Vi verrà chiesta l’impostazione predefinita sul formato di carta, linguaggi e pacchetti da includere durante l’installazione vera e propria che porterà via qualche minuto del vostro prezioso tempo.

Terminata la fase di installazione ecco che potete cominciare a lavorare sul serio producendo la vostra documentazione.

Cosa serve per lavorare con LaTeX?

Di norma le vostre necessità riguardano un buon editor di testi, un programma di grafica e un visualizzatore di file PostScript o PDF. Cominciamo da questi ultimi perché qui il lavoro è veramente già fatto. Se non avete già Adobe Reader potete comunque contare su GhostView che abbiamo installato al passo 1 di questo piccolo tutorial.

Passando agli editor di testo la scelta è veramente molto soggettiva. Si può propendere per un software completo o uno minimale. In generale serve un comunissimo editor ASCII dove editare i sorgenti LaTeX, quindi basterebbe il Notepad di MS Windows o il leggerissimo PSPad. Oppure potete affidarvi a un editor per programmatori e di seguito vi propongo una breve lista (sono rilasciati sotto licenza freeware o software libero):

• Geany;
• Notepad++;
• SciTE.

Si passa poi agli editor specifici per LaTeX (anche se quelli più completi e professionali sono disponibili per ambienti Unix-like):

• LyX (assimilabile come un Word Processor a tutti gli effetti);
• TeXnicCenter (il mio preferito);
• GNU TeXmacs (il più completo, a mio parere).

Altri software interessanti riguardano la gestione dei formati grafici. In particolare io prediligo DIA per la costruzione di grafici, grazie al buon numero di librerie messe a disposizione dell’utente, praticamente adatte a qualunque tipologia di disegno (schemi elettrici, grafici UML, diagrammi di tutti i tipi). Se dovete lavorare con i grafici matematici allora non potete non usare GNUplot, un must in questo settore. Potete pure usare un comodo tool online quale Draw Anywhere. Io comunque preferisco DIA per la facilità con cui si convertono le immagini nel formato eps.

Un altro software che vi propongo è BibDesk, ottimo per gestire un database bibliografico dal quale estrarre gli elementi da inserire nel vostro documento, in modo facile, pratico e veloce.

Infine ecco due riferimenti per ottenere da un sorgente LaTeX un formato ipertestuale, quale una pagina web: TeX4ht e Latex2HTML.

Tu che programmi usi?

In pratica, parimenti a Symfony e Django, CakePHP dà allo sviluppatore la possibilità di leggere il database e generare le classi relative a controller, modelli e quanto altro. Un comodo aiuto.

Ora, lavorando su MacBook e adorando MAMP, al primo comando impartito al mio terminale ho subito registrato una serie di errori. La console non riesce a lavorare sul database. Il motivo è semplice se si legge il primo errore stampato a schermo:

Warning: mysql_connect(): Can't connect to local MySQL server through socket '/var/mysql/mysql.sock' (2) in /Users/kiko/Sites/cakesecurity/cake/libs/model/datasources/dbo/dbo_mysql.php on line 552

In pratica non trova il socket di MySQL e ne ha tutte le ragioni. Usando MAMP infatti tutti gli strumenti di sviluppo web sono riferiti alla directory principale di MAMP. Come far funzionare la console di CakePHP allora?

Le soluzioni che mi sono venute in mente sono due. La documentazione relativa alla configurazione del database non suggerisce nulla, quindi o mettiamo mano al codice di CakePHP o aggiriamo il problema in modo meno elegante ma sufficientemente efficace. Ho scelto la seconda via.

Creiamo un collegamento banale al socket sfruttato da MAMP nella posizione dove il framework pensa di trovare il socket di MySQL e cioè:

sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock /var/mysql/mysql.sock

Ovviamente la directory /var/mysql va creata prima di lanciare il precedente comando. Fatto ciò tutto lavorerà a meraviglia.

1. Documentare il codice

Scrivere chiari e precisi commenti è impagabile. Permettono di leggere più facilmente il codice senza impazzire dietro ad algoritmi o funzioni o parametri conditi di mistero e di cui se ne disconosce la funzione, il significato e il motivo della loro esistenza. Gli stessi commenti devono essere scritti con coscienza, senza badare troppo alla forma magari, ma senza rinunciare a una certa formalità e un certo stile. Bisogna cercare di essere sempre chiari nelle spiegazioni e di non dare nulla per scontato. Prolissi e completi quando è rischiesto dal contesto, concisi quando è inutile divagare o spiegare cose ovvie e facilmente deducibili. Quando a distanza di tempo ci toccherà rimettere mano a un codice che abbiamo scritto di nostro pugno e di cui non ricordiamo molto, una veloce lettura dei commenti ci permette in pochi secondi di ritornare nella dimensione di quel progetto. Una buona documentazione del codice permette un alto livello di maintainability dello stesso. Nel caso, poi, ci fosse la necessità di collaborare con altri sviluppatori, il non dover chiedere costantemente chiarimenti su una funzione o un parametro permette di velocizzare il lavoro e migliorarlo sotto tutti i punti di vista, in quanto troveremo tutte le risposte dentro i commenti.

E’ possibile, in ultimo, estrarre dal codice sorgente i commenti formattati in un certo modo e produrre così un manuale per gli sviluppatori o una reference. Tutto in modo automatico ed evitando un doppio e tedioso lavoro. Uno strumento molto apprezzato, in tale contesto, è phpDoc (facile immagine per quale linguaggio).

Ultima raccomandazione, che a molti potrà suonare strana o esagerata. Se pensate che il vostro codice possa essere degno del panorama internazionale, cioè di un pubblico non solo italiano, allora è bene cominciare a prendere confidenza con l’inglese-scritto e commentare il codice in questa lingua.

2. Scrivere buon codice

E’ difficile in poche righe capire cosa significa “scrivere buon codice”, ma ci provo. Fra l’altro è una delle prime cose che uno studente si sente dire da un buon professore. Il pieno significato di un simile avvertimento dal sapore di consiglio lo si coglie solo quando si lavora seriamente a qualche progetto. O quando ci si confronterà con altri sviluppatori. Scrivere buon codice significa scrivere i nomi delle funzioni scegliendo i migliori termini, i più espressivi in assoluto. Conviene eliminare inutili abbreviazioni, solo per risparmiare qualche carattere e guadagnare qualche decimo di secondo in più sulla digitazione. Significa scrivere un codice la cui sola lettura è bastevole per capirne l’implementazione. Generalmente una funzione chilometrica è sintomo di scarsa progettazione del codice, il che non vuol dire che poi le cose non funzionano. La migliore palestra, in tal senso, è la lettura di codice dei migliori programmatori che potete trovare in rete e l’analisi di progetti dal codice aperto.

3. Framework e librerie

Spesso ci si trova a riscrivere del codice che in realtà esiste già e probabilmente risulta più completo del nostro, oltre che più efficace. Pertanto prima di buttarsi a capofitto nella scrittura di nuove classi occorre capire cosa offre Internet. Esistono diversi utilissimi siti dove poter trovare del buon codice (citiamo su tutti Sourceforge). Ed esiste Google per cercare eventuali librerie già pronte per essere usate nei nostri progetti. Se nulla ci soddisfa allora non resta che scrivere quanto abbiamo di bisogno. Se abbiamo intrapreso quest’ultima strada è buona cosa pensare non al progetto in sé, quanto piuttosto ai problemi generali che intendiamo risolvere. E’ questo infatti il caso migliore per pensare a una libreria riutilizzabile pure in altri progetti. Se poi siamo soliti lavorare su applicazioni che in qualche modo hanno molte somiglianze fra di loro, beh allora conviene pensare a qualche framework. Generalmente una grande società di software ne progetta uno e provvede a usarlo nei vari lavori. Uno sviluppatore indipendente può lanciare a se stesso la stuzzicante sfida di costruirne uno nuovo, o studiare per bene un framework esistente.

In tal senso un buon framework (Rails per i programmatori Ruby, Zend o Symfony per i programmatori PHP, Django per gli appassionati di Python) potrebbe essere una ottima base per sviluppare una grande applicazione. Ma occorre valutare per bene ogni fattore. Spesso un framework rischia di appesantire lo sviluppo e se non riusciamo ad ottimizzarne la configurazione rischiamo pure di ottenere un prodotto dalle scarse performance. E’ opportuno inoltre non focalizzarsi soltanto su un prodotto, ma studiarne più di uno per capire realmente benefici e svantaggi di ognuno di loro. A quel punto, e solo a quel punto, conviene sceglierne uno e provare a padroneggiarlo al meglio. In altre parole: non limitarsi a leggere qualche articolo su Internet (raramente ho scovato delle analisi pienamente oggettive sui software e sui framework), ma sperimentare le soluzioni. Quindi specializzarsi su un prodotto.

4. Standard e best practices

I design pattern vanno studiati, compresi e quindi usati. Spesso ci si accorge che bravi programmatori li disconoscono ed è un male. Pattern quali MVC offrono una potenza incredibile. E numerosi altri pattern offrono una soluzione ottimale a ricorrenti problemi per quanto riguarda la programmazione (che è poi la definizione di Design Pattern).

Quando parliamo di best practices ci riferiamo a delle esperienze che altri hanno già maturato in qualche settore professionale e nelle quali hanno raggiunto ottimi risultati. Potete pensare a delle regole generali, più o meno formalizzate, o a degli esempi opportunamente descritti e commentati. Per quanto mi riguarda mi sono stati utilissimi i libri di ingegneria del software che ho letto e sui quali ho trovato diversi riferimenti a ulteriori libri e articoli. Potete recuperare su internet diverse interviste a eminenti sviluppatori che raccontano le loro esperienze e le loro idee.

5. Pensare. Poi scrivere codice

Lontano da una schermo e una tastiera si riesce meglio a programmare. Sembra un paradosso, invece è la pura realtà. Provate a pensare alla vostra architettura fuori da una finestra di Mac o di Windows o di Linux. Fogli di carta, penna, matita e idee. Non è tempo sprecato, anzi tutto il contrario. Uno schermo con icone e testo, una tastiera e un mouse possono risultare degli elementi destabilizzanti e di distrazione. Si è tentati di scrivere subito del codice funzionante, salvo poi scoprire che una funzione poteva essere scritta meglio, o un insieme di classi poteva essere progettato in modo più intelligente. A quel punto tornare indietro è complicato. Rifattorizzare equivale a partire da zero (e a un livello iniziale non si parla certo di refactoring) e, si realizzerà con estremo rammarico, di aver buttato via preziose ore di lavoro.

Ponderare bene le scelte: tracciare diagrammi, appuntare note e idee, provare a scrivere un piano di sviluppo. Anche senza badare alla forma, una sorta di brainstorming solitario. Fate una lista dei problemi da risolvere, delle possibili soluzioni cui avete pensato e, dopo una pausa lontano da tutti e tutto, rileggete con attenzione quanto avete scritto e cercate di capire se è l’ora di mettersi a scrivere codice o conviene dedicare ancora qualche minuto a questa meditazione pre-sviluppo.

Non esiste un libro delle soluzioni in informatica. Esiste però una quantità smisurata di handle di soluzioni. Queste maniglie altro non sono che il codice e gli applicativi che altri programmatori hanno già realizzato e rilasciato. Dare uno sguardo all’interno del codice scritto da terzi (e dovete ovviamente scegliere i migliori terzi, perché conviene imparare soltanto dai migliori) si rivelerà presto preziosa lettura e fonte di soluzioni. Il che non vuol dire che dovete copiare, ma certamente ispirarvi. O, più umilmente, imparare.

Per certi compiti usare un plugin è una forzatura e rende il tutto leggermente più lento, in quanto il l’engine di WordPress deve provvedere a caricare ed eseguire tutti i plugin. Meglio eseguire codice scritto apposta. Il file functions.php potrebbe essere il posto ideale per piazzare lì alcune utili funzioni da utilizzare in lungo e in largo nel nostro tema.

Rispondiamo allora, in questo piccolo articolo, alla domanda del titolo: si può ottenere una lista di articoli related senza usare plugin? Certo. Nel mio blog uso il seguente codice.

L’idea è di partire dalle categorie in cui è inserito il post. Quindi estrarre da ogni categoria gli articoli collegati. La mia soluzione prevede il recupero a ritroso degli articoli più recenti, questo per evitare di doppiare gli articoli più letti che mostro in un apposito widget (test che ho effettuato!), a meno di casuale coincidenza. Ora gli approcci sono due:

1. inserire il codice all’interno del vostro file functions.php e richiamarlo nel punto esatto del vostro tema;
2. inserire il codice all’interno del file single.php.

L’opzione numero 2 mi è sembrata nel mio caso la più logica. Ecco il codice:

$_cats = get_the_category($post->ID);
if ($_cats) {
	$_catid = array();
	foreach($_cats as $_item) $_catid[] = $_item->term_id;
	$args=array(
		'showposts'=>5,
		'category__in' => $_catid,
		'post__not_in' => array($post->ID),
		'caller_get_posts'=>1
	);
	$_relposts_query = new wp_query($args);
	if( $_relposts_query->have_posts() ) {
		echo '<h3>Related Posts</h3><ul>';
		while ($_relposts_query->have_posts()) {
			$_relposts_query->the_post();
		?>
			<li><?php if(has_post_thumbnail()) echo get_the_post_thumbnail(get_the_id(), array(50,50)); ?><a href="<?php the_permalink() ?>" rel="bookmark" title="Link to <?php the_title_attribute(); ?>"><?php the_title(); ?></a></li>
		<?php
		}
		echo "</ul>";
	}
}

Come potete notare uso la nuova funzione di WordPress relativa ai thumbnails. Per modificare il numero di articoli da mostrare settate il parametro showposts secondo vostre necessità (riferimento wp_query). Per il resto è davvero tutto molto semplice e risulterà chiaro a chi ha un pò d’esperienza con i temi di WordPress.

P.S.

Simile risultato può essere ottenuto giocando con i tag. Anzicchè prendere a riferimento le categorie, come nel mio caso, è possibile recuperare i tag con cui è stato postato un articolo e da lì recuperare i related posts. In tal caso date un’occhiata all’idea di Jean Baptiste Jung.

XML Parsing Error: XML or text declaration not at start of entity

In effetti aprendo il flusso con un programma esterno danno noia a me al validatore le righe bianche, quindi vuote, all’inizio del notiziario. Cioè è proprio WordPress a creare casino e il motivo è che gli ingegneri della piattaforma hanno leggermente complicato la creazione dell’RSS. Qual è la soluzione, allora?

Apriamo con gentilezza il file feed-rss2.php che si trova nella directory wp-includes, partendo dalla root della nostra installazione di WordPress. Nelle primissime righe troviamo le due istruzioni seguenti:

header('Content-Type: text/xml; charset=' . get_option('blog_charset'), true);
$more = 1;

La loro funzione è importante ai fini della creazione dell’RSS. Immediatamente dopo questa coppia di istruzioni inseriamo il seguente trick che sistema tutte le cose:

$out = ob_get_contents();
$out = str_replace(array("\n", "\r", "\t", " "), "", $input);
ob_end_clean();

In particolare prende i caratteri bianchi (sostanzialmente i caratteri di tabulazione che vedete inseriti nell’array-parametro) iniziali e li pulisce, così come da formato XML. Salviamo tutto quanto e il nostro formato sarà ora valido.

La stessa identica operazione dovremmo farla sul file feed-rss2-comments.php che si trova sempre nella directory cui prima accennavo. E se utilizzate gli altri formati il consiglio è quello di ripetere la stessa operazione per i file feed-rdf.php, feed-rss.php, feed-atom.php, feed-atom-comments.php.

Fatto ciò FeedBurner non ci distuberà più e noi potremo iniziare a raccogliere statistiche utili per far crescere il nostro blog.

WordPress mette a disposizione dello sviluppatore il set di funzioni che hanno in comune il prefisso wp_count_. Il set che a noi interessa è allora il seguente:

• wp_count_posts('posts')
• wp_count_terms('category')
• wp_count_terms('post_tag')
• get_comment_count()

Trovare il numero totale degli articoli

Supponiamo allora di voler mostrare il numero totale degli articoli pubblicati. Per comodità vi consiglio di creare delle piccole funzioni che poi possiamo richiamare liberamente e comodamente in ogni punto dei nostri temi. Il posto migliore dove riunire queste funzioni è il file functions.php. Ricorriamo allora ad un codice simile:

	function get_total_posts() {
		$___posts = wp_count_posts('post');            
		return $___posts->publish;
	}

Commentiamo quel poco che c’è da commentare. Secondo una mia personalissima convenzione amo chiamare tutti gli oggetti che uso in modo indiscriminato anteponendo al loro nome tre caratteri di undescore. Facili da cercare, facili da riconoscere proprio visivamente. La funzione ci restituisce un oggetto dal quale preleviamo il numero di post effettivamente pubblicati, quindi scartando i draft. In realtà il parametro post potrebbe essere anche omesso, in quanto parametro di default, ma per leggibilità io preferisco sempre inserirlo.

Se vogliamo viceversa fare il conteggio degli articoli in bozza allora modifichiamo leggermente il codice:

	function get_total_drafts() {
		$___posts = wp_count_posts('post');            
		return $___posts->draft;
	}

In questo modo è possibile richiamare le due funzioni come segue:

        echo get_total_posts();
        echo get_total_drafts();

Trovare il numero di categorie e il numero di tag

In modo del tutto analogo presentiamo brevemente il codice per recuperare il numero delle categorie e il numero dei tag:

	function get_total_categories() {
		$___cats  = wp_count_terms('category');
		return $___cats;
	}
	function get_total_tags() {
		$___tags  = wp_count_terms('post_tag');
		return $___tags;
	}

La chiamata delle due funzioni avviene nel modo canonico. In più vi propongo una semplice funzione che ho scritto per conoscere il numero di articoli pubblicati in una determinata categoria:

	function get_posts_in_category($cat) {
		$___catid = get_cat_id($cat);
		$___catobj = get_category($___catid);
		return $___catobj->category_count;
	}

Da notare che il parametro che passate alla funzione è esattamente il nome della categoria di cui volete conoscere il conteggio degli articoli, senza perciò passare dal recupero dell’ID.

Trovare il numero di commenti

Ultima funzione. Recuperiamo il numero di commenti registrati nel nostro blog:

	function get_total_comments() {
		$___comm  = get_comment_count();                                             
		return $___comm['approved'];
	}

Dall’array possiamo estrarre i seguenti valori:

• awaiting_moderation per i commenti in attesa di moderazione;
• spam per il totale dei commenti spam;
• tot per recuperare il numero totale dei commenti (informazione sulla cui utilità ho qualche dubbio).

Per consultare la documentazione ufficiale vi rimando al seguente link. Suggerimenti per migliorare il codice o per velocizzarlo? Alternative alle funzioni proposte?