It was a dark and stormy night, me and the server, Loca, left all alone in a chilly room.

To let a linux server connect with Forefront I wanted to set up and run cntlm, which is a local proxy that authenticates to a Forefront gateway to allow internet traffic.

Some months ago I posted (Italian only) about Check_mk as a monitoring tool which can be used also to taking care of Plone instances. This time I will post a small custom plugin I wrote for Nagios.

Check_mk scan_port plugin

It's always more important to develop applications that are accessible from any device so we wondered what it takes to adapt an application, perhaps already developed, to ensure this possibility. In this case, Twitter provides its layout via Twitter Bootstrap, so it was decided to integrate it.

Capita di dover sviluppare siti che sfruttano javascript per presentare dati e testi. Se il sito è multilingua, anche questi dati e questi testi dovranno essere tradotti coerentemente con la lingua in cui si sta visualizzando il sito.

 // Tramite jQuery si prende la lingua corrente dall'attributo del tag html 
 var lang = jq('html').attr('lang');

 // si dichiara il vocabolario con le traduzioni nelle varie lingue
 var messages = {'it': 'Benvenuti',
                 'en': 'Wellcome',
                 'es': 'Bienvenido',
                 'fr': 'Bienvenue'};

 // apriamo l'alert scegliendo la traduzione opportuna.
 alert(messages[lang]);

Se la pagina web che stiamo creando ha molte parti caricate via javascript, e quindi molti testi e parole da presentare tradotte, questo approccio è scomodo; innanzitutto perché si rischia di dover mantere molto codice solo per le traduzioni.
Se siamo in un caso come questo, il sito sviluppato probabilmente è già multilingua e i dati verranno presentati correttamente. Per quanto riguarda i testi da mostrare in javascript, è meglio sfruttare un motore di traduzioni, e in Plone, grazie alla community, un'utility di questo tipo esiste già: jarn.jsi18n. Grazie a questo prodotto, infatti, è possibile sfruttare appieno il message factory di plone e tutti i suoi file di traduzioni.

Negli ultimi mesi abbiamo dovuto migrare una serie di portali dal vecchio Plone 3.3.5 alla nuova release 4.2.
Questa operazione è anche stata l'occasione per fare un po' di rifattorizzazione dei prodotti (necessaria in alcuni casi, per farli funzionare anche su Plone 4) e di pulizia generale dei contenuti.

"Quei content-type sono vecchi... cambiamoli!"

Su alcuni portali avevamo una serie di content-type creati ad hoc per esigenze passate, poi diventati obsoleti o perché le funzionalità sono state implementate (meglio) in altri prodotti, o perché non abbiamo più bisogno di loro.
Per esempio, avevamo creato diversi content-type che aggiungevano funzionalità a quelli base di Plone (al tempo non conoscevamo ancora la potenza di archetypes.schemaextender) sovrascrivendoli, e ora dovevamo tornare indietro per poter ricominciare a utilizzare le versioni base.

Tornare a utilizzare le versioni standard è semplice, basta disinstallare il nostro prodotto.
Cosa fare però con i contenuti già creati? Come torniamo a una situazione "standard" senza rompere niente?
E' come avere tra le mani una serie di cubi avendo a disposizione solo buchi tondi: non funzioneranno più, ma non li possiamo perdere. Vanno sostituiti.

La soluzione è facile: li migriamo!