March
Mar 29, 2011
Nuvole, nuvole, nuvole … di Tag
descrizione e storia di collective.vaporisation, un prodotto per tagcloud.
Cos'è una tag cloud?
Probabilmente la domanda è fin troppo facile ma per i pochi che ancora non lo sanno questa “nuvola di tag” (traduzione italiana) è un'area del sito in cui si rappresentano le parole chiave più usate all'interno del portale web.
La caratteristica principale è quella che la lista di parole chiave è pesata e quindi le parole più usate sono evidenziate per dimensione, font o colore.
Queste nuvole non sono però presenti solo per bellezza o per
fornire una statistica ma hanno anche la funzione di navigazione
permettendo all'utente di cercare e visitare i contenuti legati alle
varie parole chiave.
Per una più dettagliata descrizione vi rimando al sempre utilissimo wikipedia
E per Plone?
Quando ci è stato richiesto di inserire in uno dei nostri portali una tagcloud abbiamo scovato il pacchetto di Souheil Shelfouh chiamato “Vaporisation” (non chiedete come mai la scelta di questo nome perchè, pur sembrandoci strano, non abbiamo mai indagato a riguardo!)
Questo prodotto ci è subito piaciuto. Forniva una portlet tagcloud dotata di tutte le principali funzionalità base: creava la lista pesata delle parole chiave, forniva un controllo sulle dimensioni e sul numero di parole chiave da visualizzare, era presente un sistema di filtraggio manuale delle parole chiave. Oltre a questo era presente un sistema di navigazione per parole chiave collegate che durante la fase di ricerca/navigazione modificava la portlet mostrando solo le parole chiave presenti nei contenuti insieme a quella ricercata.
L'intervento RedTurtle
Fin qui vi starete chiedendo il perchè di questo articolo. Per parlare i prodotti di "altri"? La risposta è no :)
Le richieste che ci arrivavano dai clienti erano più articolate e il prodotto così com'era non ci permetteva di soddisfarle.
La richiesta principale era quella di porter utilizzare un qualsiasi campo di tipo KeywordIndex dato che gli archetype presentavano più campi di questo tipo.
Inizialmente abbiamo esteso il pacchetto originale ma dopo aver contattato Souheil Shelfouh, e aver scoperto che non intendeva più portare avanti il progetto, abbiamo deciso di prenderlo in mano noi andando a creare collective.vaporisation (nuovo, eggizzato, Plone4 compatibile).
Il prodotto collective.vaporisation
Ma andiamo ora a vedere quali sono le caratteristiche più importanti di questo nostro prodotto.
Filtraggio delle parole chiave
Possiamo eseguire vari tipi di filtri utilizzando un percorso in
cui si devono trovare i contenuti, il tipo di contenuto e i campi (di
tipo KeywordIndex) da utilizzare. Questa “ricerca” fornisce una
lista di parole chiave da mostrare che noi possiamo ulteriormente
filtrare andando ad agire su blacklist e whitelist
Visualizzazione
Tra i campi di creazione della portlet
ne compaiono alcuni che determinano come e cosa visualizzare
all'interno della portlet. C'è ovviamente il nome della portlet
stessa, il numero di parole chiave da visualizzare, il numero di
dimensioni diverse da attribuire alle parole chiave e l'ordinamento
alfabetico.
Aggiornamento del cloud
Lavorando su un CMS le parole chiave usate nei contenuti
potrebbero aggiungersi o togliersi spesso e soprattutto aumentare
come numero numero di utilizzi. Per questo motivo abbiamo inserito un
ulteriore campo che permette di impostare, in minuti, ogni quanto la
portlet si aggiorna. Ma non è questo l'unico parametro in base al
quale la lista dei tag viene aggiornata; l'aggiornamento avviene
anche ogni volta che vengono modificati i parametri della portlet
oppure ogni volta che si accede al sistema con un nuovo utente.
Normalmente gli anonimi non vedranno le stesse parole chiave degli
autenticati.
Joint navigation
Attivando
questa opzione nella configurazione della portlet otterremo il
risultato di una portlet dinamica durante la ricerca dei contenuti
con determinate parole chiave. Abbiamo già parlato della possibilità
di cliccare sulle singole parole chiave per eseguire una ricerca nel
portale che mostri tutti i contenuti in cui la parola chiave è
presente. Nel caso la portlet sia visibile anche nella pagina di
ricerca, per esempio perchè è presente in una colonna laterale,
questa mostrerà solo le parole chiave contenute nei documenti che
sono stati trovati dalla ricerca in modo da poter affinare la ricerca
in maniera sequenziale. Le parole chiave che si stanno cercando
compaiono nel footer della portlet e possono essere rimosse per
modificare la ricerca corrente o tornare ad una ricerca precedente.
Cosa aspettarsi dal
futuro?
Le funzionalità base sembrano solide e quindi oltre alcuni accorgimenti tecnici come per esempio il reload automatico delle parole chiave da filtrare (whitelist e blacklist) quando si modifica un filtro (path, tipo, indici usati) c'è forse la necessità di poter customizzare maggiormente la grafica per quanto riguarda colori e dimensione.
Document Actions
Mar 17, 2011
Munin timeout
I had recently problems with one of munin plugins - it disappear from munin graphs. In my munin-node.log I have a lot of:
[21134] Service 'temperature' timed out.
How to change munin timeout value? There is nothing about it in munin documentation. But if you look into source code you will find that it exists. Adding:
timeout 60
to munin-node.conf or your plugin specific configuration does the tick!
Document Actions
Mar 07, 2011
Plone e StackOverflow
C'è qualcosa di ancora meglio della mitica plone-users?
In questi giorni c'è un discreto dibattito sulla proposta di sostituzione della mailing list [plone-users] con StackOverflow.
L'idea è di sperimentare questo servizio per un 2-3 mesi e quindi di decidere il da farsi. Quello che su cui si vuol far leva sono diversi aspetti:
- Semplificare: Per molti, le mailing list sono uno strumento un po' ostico e Nabble non è il massimo come integrazione. Stack Overflow non necessita di particolari setup per poter cominciare a "chiedere".
- Valutare la reputazione: Una mailing list va frequentata per capire chi sa dare le risposte corrette e chi invece no. Stackoverflow ha un allegro sistema di valutazione dei partecipanti.
- Non chiedere 100 volte la stessa cosa: nessuno legge gli archivi di una mailing list, davvero nessuno. StackOverflow è facilmente "cercabile".
- Visibilità verso il mondo: Occorre che la comunità esca dal suo guscio dorato. Ebbene si, siamo maledetti snob che giocano con il miglior CMS sul mercato. Il confronto non può che far bene a noi stessi e anche agli altri: per Giove, non possono continuare ad utilizzare quegli antiquati CMS :)
- Notifiche: Se c'è un'argomento che vuoi seguire, beh è bene che tu venga avvertito: una ML, tantomeno Nabble, è in grado di farlo.
- Tonnellate di email vs RSS: questo potrebbe essere vantaggioso, ma è un punto alquanto controverso. Gli RSS di Stackoverflow mostrano le domande, non le risposte. E c'è chi preferisce il proprio client di posta a l'ennesimo portale da tenere sotto controllo.
Personalmente credo che sia un cambiamento interessante, in generale sono per i cambiamenti, ma questo lo è in modo particolare.
Non si tratta di avere uno strumento nuovo da utilizzare, si tratta di cambiare l'approccio con il resto del mondo.
Significa davvero uscire dalle nostre conferenze, dai nostri tool, dalle nostre mailing list e aprirci al confronto. Il confronto è bello! Si, si, subisci spesso delle critiche, ma ne esci sempre migliore di prima.
E voi che ne pensate?
Intanto troviamoci tutti su StackOverflow:
http://stackoverflow.com/questions/tagged/plone
Document Actions
Mar 01, 2011
Software libero, azienda aperta. Cum grano salis...
L'apertura delle politiche e del modo di pensare delle aziende del free software non deve indurre ad eccessive semplificazioni, meno che meno deve far passare in secondo piano la tutela della privacy e delle informazioni riservate, né deve farci scordare che siamo un attore di mercato. L'equilibrio tra apertura e chiusura, tra coopetition e competition deve essere chiaro a tutti i livelli dell'azienda.
Lo spunto
Un recente post di Marten Mickos, già CEO di MySQL, tratta in modo completo e coinvolgente il tema della "quotidiana vibrazione sui temi dell'apertura e della chiusura". Ne consiglio caldamente la lettura.
La riflessione
Per esperienza diretta, tutti sappiamo che c'è qualcosa di trascinante, di profondamente moderno, direi quasi di rasserenante nell'idea di dichiararsi aperti, e di agire di conseguenza. Ma abbandonarsi a corpo morto a questo atteggiamento ha il suo "lato B", da tenere in debita considerazione. Svilupperò questa riflessione su tre piani, interno all'azienda, mercato in generale, e il nostro mercato di riferimento, il Settore Pubblico.
Nell'azienda: il "troppo aperti" esiste!
Il post di Marten Mickos espone con un misto di entusiasmo e lucidità il peso di una scelta di massima apertura, che in azienda vuol dire anche dare voce a tutti, a prescindere dal ruolo, e - tendenzialmente - incoraggiare un'assoluta trasparenza. Basta il normale buon senso a individuare subito le aree di possibile conflitto:
- le informazioni ricevute dai Clienti, che rappresentano una loro conoscenza e proprietà intellettuale, non possono essere divulgate senza consenso. Il personale dell'azienda deve essere formato a riconoscere e a gestire questa area grigia;
- i dati personali, sensibili e in generale quanto attiene alla privacy non può essere esposto in modo indiscriminato;
- processi decisionali totalmente governati dalla base (estrema conseguenza di un'apertura all'ascolto) possono comportare decisioni inaccettabilmente lente.
Questi aspetti debbono essere governati con metodi e direttive interne all'azienda: in ogni caso il personale deve essere sensibilizzato su questi aspetti. Il "capitale sociale" (l'insieme di relazioni interne patrimonio dell'azienda) va gestito metodicamente per essere valorizzato, non lasciato a sé stesso. Limitativamente, i binari potrebbero essere descritti come "la gabbia che vincola il percorso del treno", ma al tempo stesso sono il suo vantaggio, la precondizione per il suo successo. Così i metodi in azienda: non celle e recinti, ma canali privilegiati per l'efficienza.
Il mercato: cooperare, "coopetere", competere
Ci sono motivi molto facili da capire per cui un'azienda possa legittimamente dilazionare o addirittura evitare il rilascio pubblico di componenti custom. Un oltranzismo della "openness" può sfociare in stupido autolesionismo per un'azienda che - alla fine - è un attore di mercato. Il "pubblico" contiene anche tutti i competitors e, fortunatamente per tutti, la proprietà privata esiste ancora, a dispetto dei vecchi slogan.
Nella nostra esperienza, con una tecnologia come Plone, in costante crescita ma non ancora mainstream, vediamo le altre aziende che la propongono come compagni di avventura. Con alcuni di essi cooperiamo strettamente (stringendo ATI, reti di imprese o condividendo iniziative di marketing, ad esempio nel ContènTOUR), con altri siamo in "coopetition" (condividiamo i valori di fondo, la community Plone, le sue iniziative), con altri ancora siamo in competizione aperta, come ogni buon attore di mercato - e in questo non c'è nulla di male.

Probabilmente, di pari passo con l'affermarsi di Plone, questo scenario sfumato andrà a radicalizzarsi, con il grigio della "coopetition" che si ridurrà mano a mano che Plone saturerà il mercato (con meno possibili clienti a disposizione, la lotta e l'alleanza diverranno le sole alternative): nulla di apocalittico in questa situazione, che vivono tutte le aziende non-open. Se mai ci si arriverà, l'alternativa "con me o contro di me" non impatterà assolutamente sull'apertura intrinseca del software, che resterà libero come prima. Nessuno rischia niente, a cambiare saranno le strategie, non la filosofia di fondo.
"Il tuo software è di tutti." - "Un momento!"
Il sistematico rilascio al pubblico dominio del software sviluppato va equilibrato con le esigenze del Cliente, e ciò è particolarmente vero nel Settore Pubblico, nel quale esperienze come PloneGov Italia pongono ogni giorno i propri membri di fronte alla necessità di formalizzare a un qualche livello il riuso.

Se anche realizziamo una soluzione, la competenza che c'è dietro (rappresentata da processi, logiche organizzative, politiche del back-office) e la relativa proprietà intellettuale sono dell'Ente che ha investito denaro pubblico nella realizzazione: i motivi che inducono i responsabili IT e le loro pubbliche amministrazioni a porsi il problema di governare il riuso, non sono certo dovuti a meschinità o ambizione personale, ma piuttosto all'esigenza di gestire responsabilmente un patrimonio dell'Ente.
Istituti quali le convenzioni tra Enti, i protocolli di intesa, la implementazione di clausole aggiuntive nei modelli di licenza di riferimento (EUPL, GPL e simili) non limitano il riuso: lo rendono possibile.
Una certa competenza sul tema, e attenzioni quali la disponibilità di un testo di delibera di adesione a PloneGov Italia o di schemi di convenzione, vanno incontro a questo tipo di esigenza: è importante che i decisori politici si riconoscano nell'esperienza del riuso. Se da queste persone esigiamo un assunzione di responsabilità quando sbagliano, allora dobbiamo anche aiutarli ad assumersi la responsabilità del loro ben fare, capendo le loro esigenze e accontentandoci di un 98% di apertura anzichè di un 100%.
Conclusione
L'apertura è una scelta: se non è una scelta, perde valore. L'apertura non è un riflesso pavloviano, un atteggiamento compulsivo, uno slogan per fare bella figura. L'apertura è una strategia, e come tale va gestita e governata, senza faciloneria, senza moralismo, se no si rischia di cadere in contraddizioni in termini: "aperto per forza" è un po' come "sii spontaneo!" e molto vicino al "vietato vietare".