Lavorare con le date

Visualizzazione dei periodi di tempo in stile social!

distance_of_time_in_words è una funzione che restituisce la distanza di tempo fra due interi o due oggetti datetime in formato human readable. I parametri accettati sono from_time, to_time, granularity e round i quali permettono di ottenere velocemente stringhe come quelle nel seguente esempio:

>>> from webhelpers.date import *
>>> from datetime import datetime
>>>
>>> distance_of_time_in_words(1)    
'1 second'
>>>
>>> distance_of_time_in_words(0,90)
'1 minute and 30 seconds
>>>  
>>> distance_of_time_in_words(0, 90, granularity='minute', round=True)
'1 minute'
>>>
>>> distance_of_time_in_words(0, 91, granularity='minute', round=True)
'2 minutes'
>>>
>>> distance_of_time_in_words(0,100000000000, granularity='second')
'31 centuries, 6 decades, 8 years, 10 months, 15 days, 8 hours, 
    46 minutes and 40 seconds'
>>> d1 = datetime(2013,11,04)
>>> d2 = datetime(2013,2,15)
>>> distance_of_time_in_words(d1, d2, granularity='second', round=False)
'8 months and 17 days'

Per comodità è stata introdotta anche la funzione time_ago_in_words che si comporta esattamente come la precedente, ma il cui end-point è fisso a datetime.now().

Conversione del testo

Conversione da linguaggi di Markup semplici ad HTML

WebHelpers contiene degli helper per la conversione di testo. Una funzione messa a disposizione è markdown, che permette di trasformare in HTML un testo scritto nell'omonimo Formato. Questa ci permetterà di fare cose come la seguente:

>>> from webhelpers.html.converters import markdown
>>> text = """
... A first level header
... ====================
... 
... A second level header
... ---------------------
... 
... ###A third level header
... """
>>> print markdown(text)
<h1>A first level header</h1>

<h2>A second level header</h2>

<h3>A third level header</h3>

Dal momento che esistono diverse implementazioni di questo linguaggio di markup, la funzione accetta, oltre al testo da convertire, un parametro tramite cui si può passare il modulo con l'implementazione che si intende utilizzare; alternativamente verrà utilizzata un'implementazione fornita con webhelpers stesso.

Altre funzioni messe a disposizione dal modulo delle conversioni sono textilize, per la conversione in HTML di testo textile, format_paragraphs per la conversione in paragrafi HTML del testo passato e nl2br per inserire dei <br/> in corrispondenza dei "new line" nel testo.

Creare tag

Creazione di tag HTML in modo programmatico

Il modulo tags contiene un insieme di funzioni utili alla creazione di tag HTML in modo programmatico; queste funzioni, oltre ai parametri specifici, accettano un ulteriore parametro, attrs, utile per specificare altri attributi HTML. Vediamone alcuni esempi (la lista completa la si può vedere nella documentazione):

>>> from webhelpers.html.tags import checkbox
>>> checkbox('programming_lang', value='python', checked=True, label='Python')
literal(u'<label><input checked="checked" id="programming_lang" 
       name="programming_lang" type="checkbox" value="python" />Python</label>')

oppure:

>>> from webhelpers.html.tags import link_to
>>> link_to('Google', 'http://www.google.it', title="Google")
literal(u'<a href="http://www.google.it" title="Google">Google</a>')

>>> link_to('RedTurtle', 'mailto:info@redturtle.it', title="Mail to RedTurtle")
literal(u'<a href="mailto:info@redturtle.it" title="Mail to RedTurtle">
         RedTurtle</a>')
>>>
 

Oltre a tutte le funzioni utilizzate per generare tag, ce ne sono alcune più complesse che servono a elaborare i testi per inserire tag al loro interno. Avremo ad esempio auto_link che, dato un testo, converte le occorrenze riconosciute come link nel tag corrispondente:

>>> from webhelpers.html.tool import auto_link
>>> auto_link("Visita il nostro sito: http://www.redturtle.it, 
               il nostro blog: http://blog.redturtle.it, oppure 
               scrivici all'indirizzo info@redturtle.it")
 
literal(u'Visita il nostro sito: <a href="http://www.redturtle.it">
          http://www.redturtle.it</a>, il nostro blog:
         <a href="http://blog.redturtle.it">http://blog.redturtle.it</a>,
         oppure scrivici all&#39;indirizzo 
         <a href="mailto:info@redturtle.it">info@redturtle.it</a>')

Email facilities

Creare facilmente link per l'invio di mail precompilate

Interessante è anche la possibilità di creare link predisposti per facilitare l'invio di mail, fornendo una precompilazione dei campi del client di invio:

>>> from webhelpers.html.tools import mail_to
>>> mail_to('luca.bellenghi@redturtle.it',
...         'Scrivi a RedTurtle',
...         cc="info@redturtle.it",
...         subject="Mail di esempio",
...         body=u"non stampare questa mail")
literal(u'<a href="mailto:info@redturtle.it?cc=info%40redturtle.it&amp;subject=Mail%20di%20esempio&amp;body=non%20stampare%20questa%20mail">Scrivi a RedTurtle</a>')

Fra l'altro, è possibile anche offuscare gli indirizzi email per rendere la vita più complicata agli spider dei motori di ricerca:

>>> mail_to('info@redturtle.it',
...         'Scrivi a RedTurtle',
...         cc="info@redturtle.it",
...         subject="Mail di esempio",
...         body=u"non stampare questa mail",
...         encode="hex")
literal(u'<a href="&#109;&#97;&#105;&#108;&#116;&#111;&#58;%69%6e%66%6f@%72%65%64%74%75%72%74%6c%65.%69%74?cc=info%40redturtle.it&amp;subject=Mail%20di%20esempio&amp;body=non%20stampare%20questa%20mail">Scrivi a RedTurtle</a>')
>>>

Elaborazione numerica

Formattazione ed elaborazione statistica dei numeri

Fra le varie funzioni di elaborazione numerica, la più comoda che questo modulo mette a disposizione è quella per la formattazione, tramite la quale possiamo decidere come visualizzare un numero:

>>> from webhelpers.number import format_number
>>> format_number(1936.27, '.', ',')
'1.936,27'

E' un'ottima alternativa (basata sulle regex) ad un altro metodo che ho trovato nella documentazione ufficiale di python e avevo usato diverse volte per formattare stringhe che dovevano rappresentare una valuta.

Altre funzioni che questo modulo mette a disposizione sono ben più analitiche: abbiamo funzioni per il calcolo della media, della mediana, deviazione standard, percentuale, e tutta una serie di statistiche su una lista di numeri.

Controllo dei predicati

Verifica della veridicità dei predicati

Sono state sviluppate nel pacchetto una serie di funzioni di controllo dei predicati: data una lista di elementi si può effettuare delle verifiche di verità rispetto ad un predicato passato come parametro:

>>> from webhelpers.misc import all, any
>>> seq = [2,3,4,5]
>>> all(seq, lambda x: x > 1)
True
>>> all(seq, lambda x: x > 2)
False
>>> any(seq, lambda x: x > 6)
False
>>> any(seq, lambda x: x > 4)
True

Oltre ad all ed any che controllano se il predicato è vero per ogni o almeno un elemento nella lista, esistono anche no - che controlla se tutti gli elementi sono falsi rispetto al predicato - e count_true - che verifica quanti elementi della sequenza sono veri rispetto al predicato in oggetto.

In definitiva

Queste, oltre ad altre funzioni che per brevità non ho elencato, hanno permesso a questo pacchetto di entrare in una mia personale libreria di utilities da tenere sempre a portata di mano. Occorre sempre utilizzare piccoli accorgimenti per far rendere al meglio il risultato del proprio lavoro, ed è importante poterlo fare velocemente. Questa per me è una buona raccolta di funzionalità da tenere a mente. L'unico neo che ho potuto trovare al momento è la mancanza di traduzioni i18n.

L'immagine di testata è di ®DS

L'immagine per facebook è di AJC1

Stiamo parlando infatti di tool molto potenti e raffinati, veri e propri "attrezzi del mestiere" di web developer e designer. 
Firebug, Chrome Developer Tools, Opera Dragonfly sono sicuramente tra i più diffusi e conosciuti, e offrono sofisticate funzionalità tra cui:

• debugger
• console JavaScript
• ispezione degli elementi DOM
• analisi dei log.

Problema

In ambiente mobile, nello sviluppo di applicazioni HTML5 (web app) le cose non sono diverse, nel senso che le esigenze sono le stesse dello sviluppo web tradizionale; a cambiare, però, sono gli strumenti disposizione.

I browser per mobile non hanno infatti le caratteristiche dei fratelli maggiori, lasciando così sviluppatori e designer sprovvisti di un vero e proprio "banco di lavoro" per le loro applicazioni.

Soluzione

Fortunatamente a venirci in soccorso sono proprio gli stessi ambienti di sviluppo desktop.mobile.
Negli ultimi anni infatti, alcuni di questi si sono evoluti aggiungendo funzionalità di remote debugging, come ha fatto per esempio Google per Chrome Developer Tools.

Il debug remoto permette di connettersi con il browser in utilizzo sul computer direttamente alla sessione attiva sul browser del dispositivo mobile e rende possibile interagire con essa in tempo reale.

Niente male, direi! Vediamo come si configura.

Installazione

Nativamente disponibile nella versione desktop di Chrome (F12 da tastiera), Chrome Developer Tools necessita di qualche componente aggiuntivo per l'utilizzo remoto.

Requisiti

• un dispositivo mobile Android
• l'ambiente di sviluppo Android (SDK)
• Chrome for mobile installato sul dispositivo
• un cavo USB

L'installazione dell'Android SDK non presenta grosse difficoltà in quanto Goolge fornisce direttamente l'installer per iOS, Linux e Windows. Una volta scaricato, vi basta seguire le indicazioni di configurazione fornite a schermo. Per maggiori informazioni trovate tutto qui.

Android SDK viene tipicamente usato per lo sviluppo di applicazioni native, ma è necessario anche nello sviluppo di applicazioni web mobile: infatti mette a disposizione adb (Android Debug Bridge) che permette la comunicazione tra il browser mobile attivo sul dispositivo e Chrome Developer Tools su desktop.

Chrome for mobile

Chrome for mobile è il browser di Google per mobile scaricabile free direttamente da Google Play. Attenzione ai requisiti minimi di installazione su Android: richiede infatti una versione 4 o superiore.

Configurazione

Finita la fase di installazione si può procedere con la configurazione, che in linea di massima dovrebbe essere molto veloce; bastano due flag selezionati nei punti giusti.

Ecco cosa fare: connettere il telefono al computer attraverso il cavo USB e, nell'ordine, abilitare il debugger usb in Android e il debugger web mobile in Chrome for mobile come mostrato di seguito:

Lanciare ora il comando adb direttamente da console per attivare la sincronizzazione tra desktop e dispositivo mobile:

adb forward tcp:9222 localabstract:chrome_devtools_remote

Fatto!

Utilizzo

Arrivati a questo punto abbiamo tutto il necessario per iniziare una nuova sessione di sviluppo. Digitare quindi nella barra degli indirizzi di Chrome l'indirizzo localhost:9222

Se tutto è andato a buon fine, quando si inizia la navigazione da cellulare dovrebbero comparire le pagine navigate in Google Chrome, come mostrato nell'esempio sopra, dove si vedono tre pagine da me aperte in quel momento. Ora potete scegliete quale ispezionare semplicemente cliccandoci sopra. Il sorgente sarà immediatamente disponibile in Chrome Developer Tools sul vostro computer, esattamente come fareste con le applicazioni per desktop:

Conclusioni

Nel difficile compito di ricerca delle performance, disporre di strumenti adeguati è molto importante specialmente per il mobile dove le risorse a disposizione sono (ancora) ridotte.
Chrome Deveveloper tools è uno di questi; di certo non può garantire che le vostre applicazioni siano di successo, ma è di grande aiuto affinché possano diventarlo.

Alzi la mano chi ha sul muro dell'ufficio i segni inequivocabili di tazze, portapenne, robottini e cancelleria varia scagliati contro la personificazione di quel public.css di Sunburst che porta scolpito il blu #205C90 nei più reconditi recessi delle proprie righe.

Proprio così: il formato DTML è stato ufficialmente abbandonato e relegato alle versioni di Plone <= 3.x.

Attenzione: abbandonato non vuol dire "non supportato". Nei nostri temi basati su Sunburst possiamo tranquillamente introdurre file .dtml.
Allora non ci resta che prendere esempio dagli sceneggiatori di Beautiful e riportarli alla vita con un bel "coup de theatre".

Lo scopo di questo post non è di spiegarne l'uso, la sintassi o elencarne pregi o difetti. E' una scelta individuale e organizzativa che può essere o meno condivisibile. Ma per tutti i "plone-skinner" che la pensano come me, metto a disposizione la mia personale panacea:

• il buon vecchio base_properties.props, ampliato con ulteriori personalizzazioni (stili per la descrizione, bordo inferiore sui link, colore di hover sui link...)
• un file sunburst_public.css.dtml (da aggiungere al proprio tema) che fa uso del base_properties.props per ridefinire tutti gli stili (e solo quelli) del public.css di Sunburst in cui sia possibile sostituire un valore statico con una variabile dtml.

Entrambi i files vanno inseriti nella cartella "skins/miotema_styles" del proprio pacchetto. Il file sunburst_public.css.dtml dovrà essere registrato in profiles/default/cssregistry.xml con la classica direttiva:

<stylesheet id="sunburst_public.css" 
            media="screen" rel="stylesheet" 
            rendering="link"
            cacheable="True"
            compression="safe"
            cookable="True"
            enabled="1"
            expression=""/>

Consiglio di registrarlo prima del file css specifico del tema (esempio miotema.css).

Vantaggi?

Molteplici:

• cambiare faccia a Sunburst in 5 minuti
• evitare di sovrascrivere l'intero public.css
• ridurre gli episodi di ipertensione e nervosismo
• preservare il candore del muro del proprio ufficio.

Svantaggi?

Onestamente non ne vedo nessuno, salvo il fatto che il giorno in cui i dtml verranno definitivamente deprecati si dovrà necessariamente rivedere il proprio codice... ma in una simile circostanza si starà senz'altro procedendo con una migrazione di versione "major" e potreste sfruttare l'occasione per proporre un bel restyling del sito ;-)

Avvertenze e modalità d'uso: l'uso del prodotto può creare dipendenza e assuefazione. Assumere a piccole dosi e intervallare con la somministrazione di un tema Diazo per equilibrare i valori di "cssemia".

E' per questo che spesso mi piace perdermi alla ricerca di qualcosa di nuovo da proporre. Qui sotto ho elencato una serie di slider e gallery costituiti principalmente da JQuery plugin e CSS3.

supersized! JQuery plugin

Supersized è un fullscreen background slideshow costruito utilizzando la libreria jQuery.

DEMO >>

SIDEWAYS

Una galleria fullscreen di immagini creata con la libreria jQuery e CSS. La galleria presenta le immagini a schermo intero in diverse modalità e con barre di scorrimento personalizzate.

DEMO >>

Flyout Image Slider Using jQuery & CSS3

Uno slider costituito da una pila di immagini, che funziona facendo “volare” l'immagine selezionata davanti alla pila. Usa le transizioni CSS3, animazione e jQuery.

DEMO >>

Rslider

Uno slider jQuery di immagini e contenuti, fullscreen e responsive.

DEMO >>

Portfolio Flipping Slider Using jQuery & CSS3

Uno slider per visualizzare il proprio portfolio con un effetto "flipping" per l'impaginazione. Usa jQuery e trasformazioni CSS3.

DEMO >>

Sequence

Uno slider responsive che usa transizioni CSS3 avanzate.

Sliding Horizontal Parallax Theme

DEMO >>

Apple iPhone4 Style Theme

DEMO >>

Minimalist Horizontal Sliding Theme

DEMO >>

Animated Responsive Image Grid

Un plugin jQuery per la creazione di una griglia di immagini responsive che cambia automaticamente le immagini con animazioni e tempi diversi.

DEMO >>

Showing Image With Bounce Effect

Un effetto di rimbalzo quando viene mostrata un'immagine, creato utilizzando trasformazioni CSS3 e animazione.

DEMO >>

Triple Panel Image Slider

Uno slider jQuery di immagini a pannello triplo con un look 3D.

DEMO >>

Minimit

Minimit Gallery è un plugin slider che supporta transizioni e trasformazioni CSS3, trascinamento, scroller, e interazioni touch.

DEMO >>

CSS3 Parallax scrolling slider

Uno slider verticale che usa solamente proprietà CSS3.

DEMO >>

Image Accordion with CSS3

Un accordion di immagini che espande un elemento al click.

DEMO >>

Vegas, Background jQuery Plugin

Uno slider di diversi background.

DEMO >>

Elastislide

Carousel responsive di immagini che si adatterà in modo fluido a un layout. Si tratta di un plugin per jQuery che può essere disposto in orizzontale o in verticale.

DEMO >>

Orbit, A Slick jQuery Image Slider Plugin

Un plugin jQuery per un slider di immagini.

DEMO >>

CSS-Only Responsive Layout with Smooth Transitions

Un layout con effetto a “scorrimento fluido” creato solamente attraverso CSS.

DEMO >>

Glisse.js

Un photo viewer jQuery, responsive e completamente personalizzabile.

DEMO >>

iosSlider, Touch Enabled jQuery Horizontal Slider Plugin

Un plugin jQuery progettato per essere usato come un dispositivo di scorrimento del contenuto, un carousel, un banner di scorrimento o una galleria di immagini.

DEMO >>

Elastic Image Slideshow with Thumbnail Preview

Uno slideshow "elastico" che usa miniature per le anteprime. La presentazione si regolerà automaticamente al suo contenitore.

DEMO >>

WOW Slider

Uno slider jQuery di immagini, responsive e con vari effetti di visualizzazione.

DEMO >>

Come vedete, le possibilità per mostrare le vostre immagini sono davvero molte; e queste sono solo alcune delle tante proposte!

Ci si potrebbe chiedere: "quale scegliere"? Ma a questa domanda non è possibile dare un risposta che vada bene per tutti. Alcuni di questi plugin richiedono funzionalità estremamente avanzate, non ancora disponibili per tutti i browser, e questo non è un aspetto che si possa trascurare. In altri casi potreste avere bisogno di una soluzione accessibile, e allora sarà vostro compito testare l'utilizzo della tastiera.

Una sola cosa credo sia chiara: le funzionalità che ad oggi CSS3 e HTML5 ci offrono, hanno reso più semplice la creazione di questi strumenti, e questo ci fa ben sperare per il futuro.

Spero che abbiate trovato in uno di questi slider una soluzione alla vostra specifica esigenza!

La foto in testata è di Widerbergs.

Nella vita di ogni sviluppatore arriva il giorno in cui si incrocia la propria tastiera con codice incomprensibile, dai risultati inspiegabili e che, ovviamente, bisogna correggere. Avere gli strumenti adatti per il debugging è fondamentale.

Come programmatore python ho avuto modo di utilizzare diversi tipi di debugger, dal semplice pdb a una versione più completa: pdb++. Esistono debugger integrati nei vari IDE di sviluppo, di cui però non ho mai approfondito troppo l'uso dal momento che li ho sempre trovato ambienti un po' pesanti. Da amante della shell, divido il mio tempo di sviluppo fra vim e un editor di testo molto semplice come sublime.

PuDB è un debugger visuale basato su Urwid. Quando ho visto la sua prima immagine ho pensato che fosse qualcosa per nostalgici: sono riaffiorati parecchi ricordi delle schermate che mi hanno accompagnato quando muovevo i primi passi con TurboPascal.

Ma questo effetto retrò è passato rapidamente in secondo piano: mi sono reso conto di avere sotto mano tutto quello che mi serviva per debuggare il problema su cui stavo lavorando.

Installazione e uso

L'installazione è semplice: è necessario utilizzare un interprete che vada almeno dalla versione 2.4 in poi, dopodiché, che si usi buildout, easy_install o pip per l'installazione è indifferente e in un attimo si è pronti all'uso del pacchetto; nel codice che si vuole debuggare basta inserire:

import pudb;pudb.set_trace()

e al momento dell'esecuzione, in shell ci si trova nel debugger:

Una sola immagine è già in grado di mostrare che si ha molto per le mani: un'intera pagina di codice sulla sinistra e 3 box sulla destra - il primo con le variabili dello scope, il secondo in cui viene mostrato lo stack e il terzo in cui si trova la lista dei breakpoint.

Caratteristiche principali

Il funzionamento base è come quello del pdb: 'n' per proseguire nel debug, 's' per entrare in un metodo e così via. Ma vediamo quali sono le caratteristiche principali di questo debugger e perché, secondo me, rende più veloce il debug.

Navigazione da tastiera tramite le frecce o Shift+[V/S/B] per passare ai box di variabili, stack e breakpoint

Prima di tutto, abbiamo un'ottima navigazione da tastiera: per chi è abituato a vim, si tratta di ricordare qualche combinazione o tasto in più, ma una volta memorizzati i comandi principali si va veramente veloci. Per una lista di tutti i comandi, si può fare riferimento alla guida inserita nel debugger stesso, attivabile premendo 'SHIFT+?'.

In secondo luogo, si vede una porzione molto ampia di codice; non è una regola, ma cerco di scrivere metodi non troppo lunghi (dove possibile) e con puDB diventa facile visualizzare l'intero metodo di cui si sta facendo debug.

Visualizzazione differenziata per le variabili (tipo, repr, str) ed espandibile nel caso di variabili complesse

Altra caratteristica che reputo importantissima (assieme alla visione completa del codice) è la presenza nei box di destra di tutte le variabili che vengono definite nello scope e aggiornate durante l'esecuzione. Quello che preferisco è il fatto che si possa agire in diversi modi sulle variabili: in caso di variabili complesse, queste si possano espandere come vediamo nell'immagine sotto (premendo '\'):

Inoltre si può scegliere il tipo di visualizzazione per ogni singola variabile, mostrandola per tipo ('t'), mostrandone la __repr__ ('r'), la __str__ ('s') oppure utilizzando una rappresentazione personalizzata ('c').

Stack delle chiamate navigabile

Per quello che riguarda lo stack, la possibilità di scorrerlo e di navigare nei metodi elencati al suo interno è molto utile, dal momento che si è in grado (senza dover aprire altre finestre o senza riavviare la sessione di debug) di visualizzare il codice chiamante dei metodi che stiamo analizzando. Una volta entrati in un altro metodo dello stack, cambierà lo scope e anche le variabili visualizzate saranno aggiornate; l'esecuzione del debug riprenderà da quel nuovo punto.

Ovviamente, nel caso fosse necessario utilizzare la linea di comando, la possibilità c'è: è sufficiente premere '!' per fare switch su una shell python contestualizzata nello scope corrente ('Ctrl-d' per uscirne).

Non c'è molto altro da aggiungere; la cosa migliore da fare è mettersi alla tastiera e iniziare a utilizzare questo debugger!

Immagine nel body: http://www.flickr.com/photos/smitty/2245445147/

Immagine in testata: http://www.flickr.com/photos/28208534@N07/4047355843

The application, after a migration to a new hardware, has shown to be a bit lazy compared to the expectations.

Because of the weird behaviour and confident on our Plone installation, we assumed a hardware misconfiguration.
But without evidence (numbers in this case), a claim is merely an opinion.

So, to get ride of the problem, we decided to perform multiple load test on different servers, and then compare the results.

Funkload

http://ziade.org/2011/07/27/how-to-stress-test-your-app-using-funkload-part-1

So, let's see how to set a Funkload test within a buildout.

git clone https://github.com/nicolasenno/funkload.buildout
cd funkload.buildout
virtualenv --no-site-packages .
. bin/activate

Then the buildout.cfg (download from github):

[buildout]
parts = 
    bench-tools
    gnuplot
    versions = versions

[bench-tools]
recipe = zc.recipe.egg:scripts
eggs =
    docutils
    funkload 
    tcpwatch
initialization =
import os
os.environ['TCPWATCH'] = "${buildout:bin-directory}/tcpwatch"

[gnuplot]
recipe = zc.recipe.cmmi
url = http://sourceforge.net/projects/gnuplot/files/gnuplot/4.6.2/gnuplot-4.6.2.tar.gz/download
configure-options = --bindir=${buildout:directory}/bin

[versions]
funkload = 1.16.1
 

Gnuplot can be installed directly from buildout, as suggested by Alessandro Pisa on his blog post.

import unittest
from random import random
from funkload.FunkLoadTestCase import FunkLoadTestCase

PAGES = (('Homepage', ''),
         ('path1', 'contacts'),
         ('path2', 'media'),
         )

class Site(FunkLoadTestCase):
    """This test use a configuration file Site.conf."""

    def setUp(self):
        """Setting up test."""
        self.server_url = self.conf_get('main', 'url')

    def test_app(self):
        ''' site path
        '''
        server_url = self.server_url

        for title, page in PAGES:
            url = "/".join((server_url, page))
            self.get(url, description='Get %s' % title)

Then we can use a Makefile to automate the launch process:

LOG_HOME := var/funkload/log
REPORT_HOME := var/funkload/data

ifdef URL
    FLOPS = -u $(URL) $(EXT)
else
    FLOPS = $(EXT)
endif

ifdef REPORT_HOME
    REPORT = $(REPORT_HOME)
else
    REPORT = report
endif

all: test

test: start test-app

bench: start bench-app

start:
    mkdir -p $(REPORT)  $(LOG_HOME)

test-app:
    fl-run-test -d --debug-level=3 --simple-fetch site_test.py Site.test_app $(FLOPS)

bench-app:
    fl-run-bench --simple-fetch site_test.py Site.test_app -c 1:5:10:15:20:30:40:50 -D 45 -m 0.1 -M .5 -s 1 $(FLOPS)
    fl-build-report $(LOG_HOME)/site-bench.xml --html -o $(REPORT)

clean:

If you prefer, as an improvement, you can generate this file within the buildout itself.
Take a look to collective.recipe.template for more information.

Here we are!
A couple of shell commands and you will be ready to run the test.

From your buildout directory, type:

make test
make test URL=http://override-url/
make bench

At this point a full report will be ready in "{buildout dir}/var/funkload/data" (path depends on your configuration).

Conclusion

As you can see install and run a Funkload load test it's just matter of few steps.
Thanks to it, we have been able to prove our thesis with numbers.

I think it's not a bad idea add it into my checklist of things to do for every site deployment. It could become useful in many other cases.

Recommended reading

http://blog.redturtle.it/how-to-write-funkload-test-in-few-minutes

http://www.martinaspeli.net/articles/tools-for-a-successful-plone-project

Quando sto per scrivere un nuovo post per il blog, il problema è sempre il solito: trovare un argomento interessante da proporre.

Sfortunatamente per voi, la risposta è sempre la stessa: migrazioni!

Come già detto in un precedente articolo, spesso le migrazioni sono anche il momento ideale in cui fare un'analisi del portale e individuare eventuali archetypes creati ad hoc che, col tempo, sono diventati inutili o addirittura da eliminare, perché mai utilizzati correttamente.

Se quei contenuti li vogliamo proprio eliminare, li cancelliamo direttamente dal portale e non ci si pensa più.
Discorso diverso, invece, se questi vanno mantenuti e magari "convertiti" in qualcosa di più standard, come ad esempio i contenuti base di Plone.

Ultimamente ho dovuto pensare proprio a come migrare 4-5 vecchi Archetypes ormai inutilizzati e farli diventare dei tipi base di Plone (Cartelle, Pagine ed Eventi).

La prima idea è stata quella di creare una serie di procedure come descritto nell'articolo di cui parlavo prima, ma poi mi sono chiesto se non esistesse un modo per rendere parametrizzabile questa operazione senza dover scrivere ogni volta 200 metodi uguali.

Visto che la migrazione che mi interessava era molto base e non avevo bisogno di eseguire nessuna operazione intermedia, ho deciso di creare un piccolo prodottino che mi aiutasse: rt.atmigrator.

Si tratta di un pacchetto che va inserito nel buildout e non ha bisogno di essere installato.

Fornisce una semplice vista (http://url-del-sito/@@migrate-types) che non fa altro che chiedere all'utente 2 cose:

• Il tipo di partenza (selezionabile tra i tipi aggiungibili nel portale)
• Il tipo di destinazione (selezionabile tra i tipi aggiungibili nel portale).

Una volta confermato, viene lanciato un metodo come quelli già descritti, che esegue la migrazione con Products.contentmigration utilizzando come parametri i 2 tipi impostati nel form.

Completata la migrazione, nel log c'è una descrizione completa delle operazioni svolte (ed eventualmente il traceback degli errori) e l'utente viene informato di quanti elementi sono stati aggiornati.

Il prodotto di per sé è molto semplice, dato che esegue una migrazione base da un tipo ad un altro.
Nulla vieta però di prevedere, in futuro, anche delle evoluzioni e supportare, ad esempio, una gestione di filtri per determinare i contenuti da migrare (oltre al solo tipo, magari anche un percorso o lo stato di pubblicazione), oppure delle operazioni pre e post migrazione per determinati tipi.

Il sorgente è disponibile su github, quindi si può consultare ed eventualmente modificare in un attimo.

L'API principale a cui si fa riferimento per aggiornare lo stato di un contenuto nel catalogo Plone è la chiamata a reindexObject:

>>> context.setTitle('Nuovo titolo')
>>> context.reindexObject()
>>> context.title()
'Nuovo titolo'

Fin qui, nulla di nuovo.

In alcuni casi è possibile limitare gli indici aggiornati a un sottoinsieme di quelli esistenti.

>>> context.setTitle('Nuovo titolo')
>>> context.reindexObject(idxs['Title', 'sortable_title', 'SearchableText'])
>>> context.title()
'Nuovo titolo'

In base all'attributo modificato, vale la pena aggiornare tutti gli indici che lo riguardano.

Quando la sicurezza incontra la ricerca

Un fatto meno noto: il catalogo di Plone è usato anche nella gestione della sicurezza.
In particolare esiste un indice dal nome allowedRolesAndUsers esplicitamente usato per una verifica di sicurezza: capire se un utente ha accesso a un contenuto (in pratica viene memorizzato nel catalogo se gli utenti hanno il permesso di "View" sul contenuto).

Perché tutto questo? L'alternativa sarebbe disastrosa in termini di prestazioni: caricare tutti i documenti risultanti dalla ricerca e verificare il controllo di sicurezza direttamente su questi.
Tale operazione può diventare molto lenta e dispendiosa, se pensiamo che una semplice ricerca testuale può portare a migliaia di risultati in un sito mediamente popolato.

E' quindi importante che questo indice sia sempre aggiornato. Per questo motivo, ogni volta che viene effettuata un'operazione che comporta un cambio di sicurezza di un contenuto (principalmente modifiche nella pagina di condivisione), l'indice viene aggiornato automaticamente.

Dato che una semplice chiamata al metodo reindexObject può essere relativamente dispendiosa (tenete sempre presente che Plone potrebbe indicizzare anche i file allegati e che l'operazione di re-indicizzazione di un file può essere piuttosto lenta), esiste un altro metodo che viene utilizzata al suo posto: reindexObjectSecurity.
Nel funzionamento base di Plone, questa chiamata si occupa di aggiornare solo l'indice allowedRolesAndUsers introdotto sopra.

Sicurezze alternative

Ma è vero che l'unico indice legato alla sicurezza sia allowedRolesAndUsers?
Nell'uso quotidiano di Plone sì, ma esistono alternative.

Vi porto due esempi.

collective.portlet.truereview

Sto parlando di un prodotto poco noto e di qualche anno fa: collective.portlet.truereview.

Questo prodotto applica lo stesso principio utilizzato col permesso "View" dall'indice allowedRolesAndUsers per un nuovo permesso legato all'attività di revisione dei contenuti: "Review portal content".
Per fare questo viene creato un nuovo indice: reviewerRolesAndUsers.

Lo scopo del prodotto è fornire una portlet di revisione alternativa per Plone che, a differenza di quella ufficiale, non richieda il caricamento del contenuto.
NB: il prodotto è fermo dal 2009, non sono certo che funzioni ancora ma lo trovo piuttosto didattico.

collective.localrolesdatatables

Il secondo esempio è legato al più recente collective.localrolesdatatables.

Questo prodotto vuole fornire una vista che permetta di ispezionare lo stato della sicurezza e delle condivisioni in un sito Plone.
Per fare questo è necessario capire su quali contenuti ci siano effettivamente delle personalizzazioni locali della sicurezza, ovviamente senza caricare i contenuti per non ricadere nel solito problema di prestazioni (ormai ci siamo capiti, vero?!).
L'approccio usato è quello di creare un nuovo indice "hasLocalRoles", un valore booleano che indica se un contenuto ha ruoli locali impostati o meno.

Espandere il funzionamento di reindexObjectSecurity

E' stato proprio utilizzando di recente collective.localrolesdatatables che mi sono imbattuto in un bug (di cui sono certo soffra anche collective.portlet.truereview):
il prodotto funziona a dovere, ma se la sicurezza di un contenuto viene aggiornata, l'indice "hasLocalRoles" non viene modificato a sua volta, almeno non fin quando l'intero documento verrà modificato (e quindi completamente reindicizzato).

Qual è il problema? Il metodo reindexObjectSecurity "non sa" che anche questo indice fa parte della sicurezza del sito.

Come risolvere?

Se andiamo ad analizzare l'implementazione di reindexObjectSecurity, troviamo questa riga di codice:

catalog.reindexObject(ob, idxs=self._cmf_security_indexes,
                      update_metadata=0, uid=brain_path)

Viene quindi chiesto di reindicizzare nel catalogo il documento (ob) e di limitarsi agli indici definiti nella tupla self._cmf_security_indexes (quindi non tutti gli indici).

_cmf_security_indexes è un attributo di classe definito per CatalogAware, nel pacchetto Products.CMFCore. La sua definizione è la seguente:

_cmf_security_indexes = ('allowedRolesAndUsers',)

La soluzione è molto semplice: estendere la lista di indici registrati in questo attributo (qui come ho modificato collective.localrolesdatatables):

from Products.CMFCore.CMFCatalogAware import CatalogAware

CatalogAware._cmf_security_indexes += ('mioNuovoSecurityIndex',)

Problemi?

Questo tipo di intervento ha un effetto collaterale: modifica l'attributo a livello di classe e si rispecchia quindi su tutti i siti Plone presenti nell'installazione. Potreste anche trovarvi nella situazione in cui il prodotto che necessita di questa modifica sia installato su un solo sito Plone, quindi il nuovo indice non sia presente in altri, eppure la modifica sia comunque applicata.

E' un problema? Per fortuna no!
Il catalogo Plone è molto tollerante: se viene chiesta la reindicizzazione di un indice non esistente, questo fallisce l'operazione senza sollevare eccezioni.

L'immagine di testata è di Alexandre Dulaunoy.

Il Buildout 2.0 fa un taglio netto con il passato che, con le versioni 1.6 e 1.7, aveva come obiettivo principale quello di isolare il più possibile il buildout dalla componente Python. Ma il compito si è rivelato troppo difficile da implementare, e quindi si è scelto di abbandonare questa strada e lasciare all’utilizzatore di decidere tramite l'utilizzo di virtualenv.

Non è però in questo articolo che voglio analizzare le modifiche apportate a questo componente (che potete comunque trovare qui). Oggi vediamo cosa fare per far funzionare i nostri bulidout.

Rimanere ancorati al passato.

Tutto dipende dal bootstrap.py presente nel vostro buildout.

Se vi interessa rimanere sulle versioni 1.x, allora potete usare questo bootstrap.py: contiene una restrizione sulla versione di zc.buildout che deve essere minore di 2.0 - http://downloads.buildout.org/1/bootstrap.py.

Ma se non vi sentite troppo sicuri nel sostituire il bootstrap.py del vostro buildout, c’è una seconda soluzione, suggerita in risposta a questo bug report su stack overflow.
Dovrete semplicemente rilanciare il bootstrap del vostro buildout forzando la versione di zc.buildout in questo modo:

     python bootstrap.py -v 1.7.1
 

Tuttavia, con versioni molto vecchie del bootstrap.py, potreste ritrovarvi nel caso in cui non sia possibile forzare la versione; allora dovrete per forza aggiornare il file con la versione di cui sopra, per poi eseguire il comando forzando zc.buildout all’ultima versione precedente alla 2.0; al momento, questa: https://pypi.python.org/pypi/zc.buildout/1.7.1.

Il nuovo che avanza.

Per usare la versione 2.0 di zc.buildout vi consiglio di utilizzare questa versione del bootstrap: http://downloads.buildout.org/2/bootstrap.py.

In questo caso, però, vi potreste trovare nella situazione inversa, ovvero: dopo aver lanciato il solito comando "./bin/buildout -N", non trovate la nuova versione di zc.buildout.

La causa è da attribuire alla presenza di buildout.dumppickedversions che ha fatto il pin di alcune versioni e, quindi, lanciando il buildout con il “-N” (pratica più che corretta!), la nuova versione per zc.buildout non è stata presa in considerazione.
Magari avete specificato il dumppickedversions nelle extensions nel vostro buildout.cfg e state pensando di rimuoverlo; ma nelle ultime versioni del buildout è automaticamente incluso.
La soluzione, consigliata da Reinout van Rees nel suo post, è molto semplice: fate il pin di questi due prodotti nel [versions] del vostro file di configurazione e avrete il vostro pacchetto aggiornato :)

    [versions]
    zc.buildout = 2.0.1
    zc.recipe.egg = 2.0.0a3
 

Il caso

Come fa Plone a gestire
i gruppi virtuali??

Partiamo da un caso concreto, al quale sto lavorando in questi giorni. Ci sono degli user che, tramite un sistema di autenticazione federato, si collegano al sito. Quando questi si collegano per la prima volta, viene creato un utente vero e proprio nel sito Plone a cui viene impostata una proprietà (supponiamo sia "caratteristica_x=True"). Devo fare in modo di raggrupparli automaticamente.

In Plone tutto questo si fa con PAS e i suoi plugin in PlonePAS (si può vedere della documentazione qui). E proprio in quest'ultimo troviamo il codice che ci mostra come creare e gestire il gruppo degli "Authenticated User"; codice che si trova nei seguenti file:

• plugins/autogroup.py
• __init__.py
• Extensions/Install.py

Negli ultimi due moduli c'è il codice per registrare il plugin e installarlo. Si tratta di operazioni banali, e ci tornerò sopra più avanti quando mostrerò come creare un nuovo plugin. Nel primo modulo, invece, c'è tutta la logica che riguarda il funzionamento del plugin, ed è questo che mi interessa analizzare.

Analisi del plugin

Il plugin è generato tramite la classe AutoGroup. I meccanismi di PAS si basano sull'implementazione di interfacce tramite cui la classe si impegna a fornire un set di metodi; nella classe in analisi troviamo:

Tramite l'implementazione di interfacce, un plugin fornisce dei metodi e "promette" dei comportamenti

• IGroupEnumerationPlugin: fornisce metodi per l'enumerazione e la ricerca di gruppi
• IGroupsPlugin: fornisce un metodo tramite il quale, dato un principal (utente o gruppo) si ritornano tutti i gruppi a cui questo principal appartiene
• IGroupIntrospection: fornisce metodi per ottenere da un plugin gruppi e utenti dei gruppi
• IPropertiesPlugin: fornisce un metodo per ottenere le proprietà (titolo e descrizione) di un gruppo.

Per il nostro use case, è tutto corretto e l'unico comportamento che ci interessa modificare è quella fornito da IGroupsPlugin, tramite cui decidiamo se uno user è nel gruppo oppure no.

Creiamo un nuovo plugin

Per farlo, percorriamo i passi già citati sopra:

• si crea un plugin
• si registra
• lo si installa nel sistema.

Come detto, modifichiamo una sola funzionalita, data dal metodo getGroupsForPrincipal:

from App.class_init import InitializeClass
from Products.PlonePAS.plugins.autogroup import AutoGroup
from Products.PageTemplates.PageTemplateFile import PageTemplateFile

manage_addCustomGroupForm = PageTemplateFile("./zmi/CustomUsersGroupForm",
                                           globals())


def manage_addCustomGroup(self,
                          id,
                          title='',
                          group='',
                          description='',
                          RESPONSE=None):
    """Add an Auto Group plugin."""

    plugin = CustomUsersGroup(id, title, group, description)
    self._setObject(id, plugin)

    red_to = "%s/manage_workspace?manage_tabs_message=Custom+Users+Group+plugin+added"
    if RESPONSE is not None:
        return RESPONSE.redirect(red_to % self.absolute_url())


class CustomUsersGroup(AutoGroup):
    meta_type = "Custom users group"

    # IGroupsPlugin implementation.
    def getGroupsForPrincipal(self, principal, request=None):
        if principal.getProperty('caratteristica_x'):
            return (self.group,)
        return ()

InitializeClass(CustomUsersGroup)
 

Gli altri metodi nel codice sopra, manage_addCustomGroup e manage_addCustomGroupForm, sono utilizzati per l'aggiunta e la gestione del plugin in ZMI dentro la acl_users del sito: dobbiamo infatti creare un'istanza del plugin per avere il nuovo gruppo a disposizione.

Una volta scritto il codice del plugin lo dobbiamo registrare nell'inizializzazione del pacchetto:

from Products.PluggableAuthService import registerMultiPlugin

try:
    registerMultiPlugin(CustomUsersGroup.meta_type)
except RuntimeError:
    # Don't explode upon re-registering the plugin:
    pass

def initialize(context):
    context.registerClass(CustomUsersGroup,
                           permission=add_user_folders,
                           constructors=(manage_addCustomGroupForm,
                                         manage_addCustomGroup),
                           visibility=None
                           )

Fatto questo, possiamo considerare l'attività di sviluppo terminata. Se vogliamo istanziare il plugin con l'installazione del pacchetto, dobbiamo creare un import step dentro il quale fare qualcosa di questo tipo:

 
    ....
    portal = context.getSite()
    acl_users = getToolByName(portal, 'acl_users')
    plugins = acl_users.plugins
    if not 'custom_users_group' in acl_users.objectIds():
        manage_addCustomGroup(acl_users,
                            "custom_users_group",
                            "Custom users (Virtual Group)",
                            "CustomUsersGroup",
                            "Automatic Custom Group Provider")
        for interface in [IGroupsPlugin,
                          IPropertiesPlugin,
                          IGroupEnumerationPlugin,
                          IGroupIntrospection]:
            plugins.activatePlugin(interface, "custom_users_group"
    ....

In questo modo si aggiunge il plugin alla acl_users del sito e si attivano le interfacce per le funzionalità che il plugin dovrà gestire.

Conclusioni

Finito! Come possiamo vedere a questo punto nella gestione gruppi del sito, abbiamo un gruppo in più, che si comporta esattamente come il gruppo "Authenticated Users", tranne che per la condizione di appartenenza al gruppo; tale gruppo è disponibile anche nello sharing.

Per testarne il funzionamento, possiamo accedere al sito con un utente e verificare che non abbia permessi di nessun tipo. Dalla gestione gruppi possiamo assegnare il ruolo di Manager al gruppo appena creato e tornare a verificare con l'utente di cui sopra, che ora ha permessi da Manager nel portale.

L'immagine in testata è di evildan2

Nel caso in cui l'obbiettivo sia quello di far arrivare l'email da voi inviata 
dritta nello spam di Gmail, basta seguire due semplici regole:

• sottovalutare l'attività di invio email
• ignorare le linee guida fornite dal provider.

Facile, no?

Vorrei evitare di dire che lo spam è un grosso problema per la maggior parte degli utilizzatori di internet, ma ormai l'ho detto e allora, già che ci sono, aggiungo anche che Gmail in tal senso ha la guardia ben alzata.

Quindi, invertendo il loro significato, si ottiene che la prima regola è rassegnarsi al fatto che l'attività di invio messaggi di posta (parlo ovviamente di invio massivo), va gestita con un certo criterio e va seguita con altrettanta attenzione.

Non basta, per esempio, prendere una delle tante librerie disponibili per il vostro framework preferito e iniziare a spedire messaggi a tutto il mondo, perché le email verranno probabilmente inviate ma in molti casi non raggiungeranno mai la casella inbox.

La seconda regola impone di seguire le linee guida fornite dai provider, nel nostro caso quelle fornite da Google.

E' chiaro, a questo punto, che bisogna prendersi un po' di tempo e studiare il problema.

Concetti base

Da marzo 2012, Google aggiunge in cima a ogni email marcata come spam, un messaggio che indica il motivo per cui è stata classificata come tale, come nell'esempio qui sotto:

Ci sono due principali motivi per cui un messaggio viene marcato come spam.

Primo

Google considera la vostra email un potenziale falso o un tentativo di "phishing", marca il messaggio come spam e aggiunge una delle seguenti diciture:

• Our systems couldn't verify that this message was really sent by yyy.com
• This message may not have been sent by xxx@yyy.com
• Similar messages were used to steal people's personal information.
  Unless you trust the sender, don't click links or reply with personal information.

Secondo

Google considera il messaggio semplicemente spam, lo marca come tale e aggiunge qualcosa del tipo:

• It contains content that's typically used in spam messages
• It's similar to messages that were detected by our spam filters
• You previously marked messages from xxx@yyy.com as spam.

E' importante capire la differenza tra questi due diversi motivi, perché nel primo caso si risolve in modo relativamente facile - probabilmente si tratta solo di un problema di configurazione.
Nel secondo caso, invece, la questione è più complessa, perché Google decide cosa è spam secondo parametri e criteri non del tutto trasparenti.

Per quanto riguarda i contenuti, inizialmente Google come altri provider, cercava di separare il legittimo dall'illegittimo basandosi sull'analisi del testo alla ricerca di parole chiave sospette; ma questa strategia è stata abbandonata a favore di un'altra.

Negli ultimi anni la tendenza è di filtrare i messaggi in base al comportamento osservato nei destinatari stessi. Mi spiego meglio: se le email inviate per esempio da un indirizzo specifico vengono marcate come posta non desiderata o scartate dalla maggior parte degli utenti, Google assume che quell'indirizzo invia messaggi non graditi, e quindi diventa spam.

Il meccanismo è complesso, ma a grandi linee funziona come un sistema di rating alimentato dai destinatari, che in questo modo determinano quello che non vogliono ricevere.

Un primo spunto per risolvere il problema può venire dalla guida ufficiale Bulk Senders Guidelines di Google, della quale riporto alcune sezioni tradotte e interpretate.

Le linee guida

Con autenticazione e identificazione si descrive la capacità da parte di chi fornisce il servizio di posta (provider) di riconoscere il mittente del messaggio per cercare di prevenire il fenomeno conosciuto come email spoofing.

Sottoscrizione

Cancellazione

Inoltre è suggerito di:

Formato

Consegna

Sulla consegna Google ci tiene a sottolineare che non è in grado di garantire che la posta inviata raggiunga correttamente il destinatario.
Riporta in ogni caso due fattori determinanti:

• l'utente destinatario dovrebbe avere l'indirizzo contenuto nel campo "form" tra i propri contatti
• il destinatario, quando riceve il messaggio, deve indicare a Gmail (attraverso l'apposito tasto) che chi ha inviato il messaggio da quell'indirizzo non è da considerare come spam (aumenta il rating associato all'indirizzo).

Questo è uno dei punti critici del sistema, perché sono i destinatari dei nostri messaggi a decidere la sorte delle email che inviamo. Google consiglia per questo motivo di utilizzare due indirizzi diversi a seconda dello scopo, per esempio: supporto e promozione.

E' molto probabile infatti che i messaggi di tipo promozionale finiscano nel cestino o marcati come spam dall'utente, con la conseguenza di abbassare il rating generale dell'indirizzo di invio; mentre i messaggi di supporto probabilmente non verranno marcati come spam.

Conclusioni

In conclusione si può dire che l'ultima parola spetta ovviamente ai provider (Google in questo caso), i quali hanno pieno potere sulla gestione delle email. Seguire le linee giuda aiuta notevolmente, tuttavia il risultato non è garantito. E' chiaro che l'argomento "posta" non va preso sottogamba: spedire è semplice, ma fare in modo che arrivi al destinatario non è un risultato scontato.

E' uscito da poco un articolo molto curato sull'argomento che ha attratto la mia attenzione:

Front-end performance for web designers and front-end developers di Harry Roberts.

Nell'articolo vengono illustrati e sintetizzati molti degli argomenti relativi all'ottimizzazione dello sviluppo front-end.

Si parte dalle regole basilari: gli stili css devono essere chiamati all'inizio della pagina mentre i file javascript in fondo ad essa. Questo è un punto essenziale, dato che i browser eseguono il render della pagina progressivamente e prima hanno a disposizione il css, prima ne possono iniziare il render sulla pagina, evitando di bloccarla graficamente.

Al contrario le chiamate javascript, bloccando i browser nel processo di download parallelo delle varie risorse, devono essere posizionate in fondo alla pagina. La loro natura bloccante deriva anche dal fatto che ogni singola risorsa js deve essere caricata nell'esatta sequenza.

In generale è bene fare il minor numero di chiamate possibili a risorse, cioè scaricare il minor numero di elementi effettuando così poche HTTP Request. Ogni chiamata tecnicamente può incorrere in un "DNS lookup", in un redirect o in un errore 404 di risorsa non trovata; per questo ridurle contribuisce sensibilmente ad ottimizzare l'esecuzione.

Idealmente si dovrebbe massimizzare il parallelismo nell'ottenere risorse da domini diversi. Dato che un browser può al massimo trattare due risorse alla volta da uno stesso dominio, possiamo moltiplicare questo numero per il numero di domini dal quale possiamo servire le risorse.

Molti siti conosciuti fanno uso di domini "statici" solo per questo motivo, ottenere le risorse da più domini. In abbinamento alla tecnologia CDN (Content Delivery Network), ciò consente di diminuire ulteriormente la latenza di tempo ottenendo così le risorse anche da più luoghi dislocati fisicamente nel mondo.

Le richieste HTTP e il tempo per la risoluzione dei nomi DNS possono quindi rappresentare uno dei principali colli di bottiglia nelle prestazioni di front-end dato il limite nello scaricamento di risorse in parallelo imposto dai browsers. D'altro canto, la tecnica dell'utilizzo di sottodomini per aumentare le possibilità parallele introduce ad ogni nuovo dominio il tempo di latenza della risoluzione del nuovo nome DNS, quindi va valutato accuratamente caso per caso se sia possibile farsi carico di questo ulteriore tempo nel progetto web di cui ci si sta occupando.

Nel caso in cui servano nuovi nomi di dominio, è utile utilizzare la tecnica del DNS prefetching attraverso la quale semplicemente si comunica in anticipo al browser il nuovo dns dal quale, poco dopo, sarà necessaria una risorsa; facendo così si riescono a evitare i tempi di attesa per la risoluzione del nuovo dominio.

<head>
<link rel="dns-prefetch" href="//widget.foo.com" />
</head>

In realtà questo introduce il concetto di prefetching generale delle risorse; oltre ai DNS, anche le altre risorse come i web fonts o le immagini chiamate dai fogli di stile possono essere chiamate in anticipo in modo da iniziarne il download leggermente prima del loro effettivo utilizzo.

Per fare questo esistono due vie: 
- una sporca e sicura, che prevede di celare in un <div> nascosto le immagini per averle a disposizione nell'html della pagina molto in anticipo
- una più pulita ai puristi del codice, che è sostanzialmente sempre il link prefetching già visto per i DNS.

<link rel="prefetch" href="sprite.png" />
<link rel="prefetch" href="webfont.woff" />

Invece, per quanto riguarda l'ottimizzazione delle chiamate css è fondamentale sapere che non devono mai essere fatte da un un altro dns, data la loro natura bloccante sulla resa grafica della pagina; così facendo infatti si incorrerebbe nel DNS lookup, ovvero nel tempo ulteriore necessario alla risoluzione del nuovo dominio.

Oltre a servire il css il prima possibile nella pagina, bisogna concatenarli, ridurli al minimo rimuovendo commenti e spazi e comprimerli per diminuire il lavoro da parte del browser e dei vari sistemi di caching. I software di editing css contemporanei hanno tutti funzioni per controllare anche questi aspetti; in aggiunta, se si usano linguaggi di preprocessing dei css come sass si hanno a disposizione potenti strumenti per curare nei dettagli tali operazioni.

Senza entrare troppo nel dettaglio della compressione possibile usando gzip su server attraverso Apache, passiamo all'ottimizzazione delle immagini.

Si parte dalla ben nota tecnica di spriting delle immagini, ovvero del raggruppare in un'unica immagine tutte quelle che possono servire nel file css, in modo da ridurre al minimo il numero di http Request a questo tipo di risorsa. Anche se non tutte le immagini possono essere messe in uno sprite - ad esempio quelle da usare come sfondo, che vanno ripetute e che spesso vengono messe negli sprite con molti pixel vuoti attorno in modo da poter ottenere la ripetizione necessaria. Ma i pixel vuoti, non necessari, sono un problema nella velocità di esecuzione. L'articolo suggerisce di usare il classico "elemento di spriting", solitamente <i>, che ha il solo scopo di rimanere vuoto e portare l'immagine di sprite come sfondo. Ecco l'esempio di utilizzo più comune:

<li>
   <a href="/profile/">
      <i class="icon icon--person"></i> Profile
   </a>

</li>
 

L'articolo di Harry Roberts tocca anche il caso delle immagini Retina solitamente usate per i dispositivi mobile, in modo da garantire ad essi che hanno capacità di memoria inferiori, esperienze estetiche superiori, ma in generale l'autore ritiene che vadano scelte oculatamente. Tutto sommato esistono anche valide alternative alle immagini bitmap, come svg o font di icone.

Infine, l'ultimo argomento dell'articolo: le immagini JPG progressive.

Riguarda più che altro la velocità percepita nell'esecuzione, infatti a differenza dei JPG che si caricano per blocchi successivi, i jpg progressivi sono caricati interamente fin dall'inizio ma pixelati e solo progressivamente aumentano di dettaglio, un po' come accadeva per le vecchie gif. Ciò contribuisce molto alla percezione di rapidità visiva che avrà l'utente.

L'articolo portato alla vostra attenzione è ricco di approfondimenti come questo sui jpg progressivi: il mio invito è di tornare a ricercare ogni singolo approfondimento direttamente alla fonte.

Image by courtesy of: Silvia Cesari

Negli ultimi mesi, il mio lavoro è stato principalmente quello di “aggiornare” dei vecchi siti e migrarli da Plone 3 a Plone 4 (lo so, in ritardo di un paio d'anni).

Esistono sostanzialmente due modalità per migrare un sito Plone:

• esportazione dei soli contenuti dal vecchio sito (per esempio con strumenti come transmogrifier) e importazione di questi in un nuovo ambiente immacolato.
• migrazione del portale così com'è mediante il tool interno fornito da Plone stesso.

La migrazione con transmogrifier, di cui abbiamo già parlato precedentemente, in linea di massima è consigliata in quei casi in cui il vecchio portale potrebbe avere diverso “sporco” al suo interno, dovuto a svariati motivi (errori di gioventù dei programmatori, prodotti installati e mai utilizzati o mal rimossi, ecc.), oppure se si decide che parte dei contenuti attuali non servono più e si vuole portare dietro solo alcune sezioni.

Nel nostro caso avevamo degli ambienti abbastanza controllati, dove conoscevamo bene i prodotti installati (in parte sviluppati da noi e in parte trovati su pypi ma utilizzati da tempo) e il livello di sporcizia era minimo, ma soprattutto i portali dovevano essere migrati per intero.

Per questo motivo abbiamo deciso di utilizzare il tool di migrazione nativo di Plone.
L’utilizzo del tool è molto semplice, basta un click e fa tutto da solo, però il difficile è stato “preparare” i vari portali alla migrazione.
Il nostro problema era che dovevamo migrare una ventina di portali in sequenza e il rischio era di rimanere impantanati nelle varie procedure.
Dopo diverse prove e migrazioni fallite, abbiamo trovato una serie di linee guida che ci hanno aiutato a sopravvivere e che sono tornate utili anche in successive migrazioni.

Analisi della situazione

Come prima cosa, bisogna fare un’analisi approfondita dell’utilizzo del portale, dei prodotti installati e dei contenuti creati.
In questo modo si può avere una panoramica su quanti e quali contenuti sono stati effettivamente creati, quali prodotti sono veramente utilizzati e bisogna portarsi dietro, e quali sono inutilizzati e si possono rimuovere per ottimizzare ulteriormente il portale.

Compatibilità dei prodotti su Plone 4

Dopo l’analisi preliminare, è utile testare il corretto funzionamento dei prodotti da mantenere, su un buildout Plone 4.
Per quelli di terze parti scaricati da pypi, di solito non c’è bisogno di fare molto: basta una veloce ricerca su pypi o su plone.org e il gioco è fatto. Se poi non sono compatibili, vuol dire che o sono stati superati da altri prodotti più evoluti (e forse è meglio informarsi meglio sull'eventualità di sostituirli), oppure possiamo sempre aggiornarli noi, in modo da dare un utile contributo alla comunità.
I prodotti sviluppati appositamente per i clienti, invece, vanno per forza sistemati. In generale, se non si deve fare un refactoring pesante ma solo un aggiornamento, un buon inizio è quello di controllare se presi e messi su un Plone 4 girano correttamente, ed eventualmente correggere a mano a mano gli errori che si riscontrano.
Molto probabilmente diversi template o importazioni si romperanno, perché alcune cose in Plone 4 sono cambiate; nessun problema, visto che sul sito di plone.org c'è una guida dedicata: http://plone.org/documentation/manual/upgrade-guide - in alternativa, Google o le varie mailing-list tornano sempre utili.

Rimozione dei prodotti inutilizzati

Il passo successivo consiste nella rimozione dei prodotti vecchi e/o inutilizzati.
E’ un passo importante, poiché non è consigliato portarsi dietro dei prodotti che non vengono utilizzati, o che già sappiamo non essere compatibili su Plone 4. Per questo vanno rimossi prima di effettuare una migrazione.

Promemoria: fare sempre i profili di disinstallazione!

Se un prodotto non è dotato di un profilo di disinstallazione fatto correttamente (e per esperienza posso dire che purtroppo molti sono così), potrebbe lasciare dei “residui” indesiderati nel nostro Data.fs.
Questi possono generare dei semplici warning  nel nuovo sito, come per esempio dei CSS o Javascript registrati e non più disponibili, ma nella maggior parte dei casi il problema riguarda adapter o persistent utilities che non vengono rimossi correttamente e rischiano di vanificare la migrazione.
Come per l’aggiornamento dei prodotti, se questi sono stati scaricati da pypi, una buona prassi è quella di sistemare i profili di disinstallazione dando un contributo alla comunità.
Di solito le risorse che sono registrate e non vengono disinstallate correttamente sono quelle gestite con i profili di GenericSetup, come per esempio dei CSS o javascript, ma anche controlpanel e skin layers. Per avere degli esempi di come eseguire una corretta disinstallazione, basta cercare diversi prodotti nella collective (ad esempio redturtle.smartlink).
Se malauguratamente il prodotto non mette a disposizione il repository con i sorgenti (e può capitare), o sistemare il profilo di disinstallazione risulta troppo complicato, si riescono a rimuovere parecchie risorse anche manualmente.
Tutte quelle relative a GenericSetup si possono rimuovere da ZMI nei vari tool, ma i nostri nemici più agguerriti sono state le persistent-utilities, che sono persistenti ma non si riescono a visualizzare da ZMI.
Nessun problema, ci sono venute in aiuto due preziose risorse:

• wildacard.fixpersistentutilities, un prodotto che aiuta a riconoscere e rimuovere da interfaccia utente eventuali persistent-utilities presenti nel sito
• un'utilissima guida di Nathan Van Gheem che spiega come rimuovere manualmente adapters, utility e subscribers.

Blob Blob Blob

Su Plone 4 è diventato di default il supporto ai blob, per ovvi motivi di miglioramento delle prestazioni e di separazione di file e immagini dal Data.fs vero e proprio.
Per questo motivo, la migrazione di Plone 4 include uno step apposito che provvede in autonomia a migrare i contenuti di tipo file e immagine presenti nel sito ai blob.
Se i vostri prodotti prevedono contenuti che contengono immagini o file, è buona norma dotarli del supporto ai blob (procedura spiegata in un paragrafo della guida alla migrazione precedente) e di una procedura che permetta di migrare a blob i contenuti già presenti nel sito (ovviamente post-migrazione a Plone 4). Un buon esempio è fornito da redturtle.smartlink.

E per finire... la migrazione

Arrivati a questo punto, dopo aver verificato che tutti i prodotti siano compatibili con Plone 4 e aver ripulito il nostro Data.fs, possiamo procedere alla migrazione vera e propria.
Non serve altro che copiare i nostri dati nel nuovo buildout, farlo partire e andare nella ZMI del sito da migrare: un testo avvertirà che il sito è obsoleto e va aggiornato. Seguendo il link si avrà la possibilità di eseguire la migrazione in due modi:

• dry-run, cioè eseguendo tutti i passi della migrazione, ma non committando le modifiche alla fine: serve se si vogliono prima fare delle prove
• migrazione vera e propria: esegue tutti i passi e, una volta terminati, committa le modifiche e le scrive nel db.

Ovviamente il tempo impiegato dipende da molti fattori, come per esempio la potenza della macchina, la dimensione del Data.fs e il fatto di avere già i file sui blob.
Non sempre la migrazione andrà a buon fine al primo colpo. Fortunatamente quasi sempre il traceback dei fallimenti ci dà buone informazioni su cosa è andato storto, in modo da poterlo sistemare e ritentare. Nella mia esperienza, spesso i problemi erano proprio con utility mal rimosse o classi non più trovate.

Alla fine di tutto il procedimento, quando avremo un sito aggiornato e funzionante, prima di effettuare i vari test è buona norma fare un giro nel pannello di gestione dei prodotti aggiuntivi, in modo da vedere se ci sono degli upgrade-step da lanciare per sistemare alcuni prodotti. Altra operazione importante da fare è il pack del db, perché consente di guadagnare diverso spazio, visto lo spostamento all’esterno di file e immagini.

Conclusioni

In conclusione, se si prepara per bene il db da migrare, rimuovendo correttamente tutti i componenti inutilizzati, il tool di migrazione funziona discretamente bene.

Abbiamo solo avuto alcuni problemi durante la migrazione dei blob di un sito, come riportato anche da Ross Patterson in un suo post. Dopo una lunga analisi, abbiamo notato che il poskey Error veniva lanciato durante il commit finale, ma non siamo riusciti (come l'autore) a risalire all'origine del problema. La soluzione è stata quella di effettuare dei commit intermedi alla fine della migrazione dei file e alla fine delle immagini, anziché alla fine di tutta la procedura.

Seguendo questa sorta di check-list, siamo riusciti a migrare abbastanza agilmente una ventina di siti, e l'abbiamo riutilizzata anche per successivi lavori.

Sarà perché nella mia esperienza ho affrontato vari corsi di formazione per sviluppatori Plone, sarà perché non tutto il codice è sempre pronto per essere rilasciato, una cosa è certa: il rapporto tra il neofita e il codice da lui sviluppato è piuttosto combattuto.

Partiamo con una carrellata di quello che potete fare (ma in gran parte non dovete) fino ad arrivare alla soluzione dei casi più delicati.

Sviluppo old-style

Nell'uso quotidiano di Plone, il nostro amico buildout ci ha abituati per anni all'uso della directory di develop (di solito, la directory src):

[buildout]
...
develop =
    src/my.package
    ...

Sebbene questo metodo oggi sia largamente superato (vedi mr.developer), la comunità Plone lo ha utilizzato per anni e c'è ancora tanta documentazione in giro che ne parla.

Per molti utenti che non hanno dimestichezza con l'installazione di mr.developer (prima che questo diventasse parte dei template di buildout Plone rilasciati) questo modo è quello "più semplice".

Semplicemente: funziona!

Versiona-che?

Ammettiamo che vi troviate nella situazione di cui sopra: qual è la cosa peggiore che potreste trovare in un buildout?
Semplice! L'assenza del versionamento del codice.

Mi è capitato diverse volte di trovarmi in questa situazione: il Cliente X chiama per mettere mano a un buildout in cui erano presenti prodotti legacy proprio all'interno della cartella src.
Nei casi peggiori, si tratta di codice non versionato. Eppure ci viene chiesto di mettergli mano e di apportare un qualche tipo di modifica!

A volte può capitare di accorgersi che nemmeno la configurazione del buildout sia sotto controllo di versione...

Spesso il cliente si sente sufficientemente al sicuro sapendo che ha "una copia da qualche parte" (quando va bene), eppure è difficile fargli capire che la soluzione "backup" non è tutto.

Probabilmente siamo passati tutti per questa fase (detta anche fase del "ero giovane, avevo bisogno di lavorare"), ma spero per voi l'abbiate abbandonata abbastanza in fretta.

Externals SVN

Prima dell'esplosione di popolarità di Git/Github, il software di versionamento del codice più in voga tra gli sviluppatori Plone è stato SVN.
Ne è riprova il fatto che, ancora oggi, la collective SVN è un repository piuttosto utilizzato, anche se la nuova collective, ospitata su GitHub, sta rapidamente prendendo piede.

Una delle caratteristiche di SVN era la possibilità di definire il contenuto di una directory sotto controllo di versione tramite la definizione di externals (svn:externals), ossia permettere di caricare nella directory una serie di altri sorgenti provenienti (volendo) anche da altri repository.

Una volta compresa l'importanza del versionamento, il Cliente X potrebbe davvero apprezzare il fatto di sapere che il suo buildout è stato versionato, e che il contenuto della directory src contenente il suo codice è controllato da svn:externals, così che il sorgente di ogni prodotto venga scaricato dal repository stesso del prodotto.

Un esempio del formato che questa proprietà dovrebbe avere per due ipotetici prodotti Plone:

my.package https://my.repository/svn/my.package/trunk
your.package https://your.repository/svn/your.package/trunk

Il tutto ora è piuttosto robusto. L'unico problema riguarda l'utilizzo del trunk dei prodotti.
Questo tipo di configurazione può andare bene per un ambiente di sviluppo, ma come possiamo configurare l'ambiente di produzione?

Il trunk è per definizione una versione instabile o comunque sempre aggiornata di un prodotto; la possibilità che, aggiornando l'installazione o effettuandone una replica su un nuovo server (magari in seguito ad un disaster-recovery del sistema), il codice possa cambiare o aggiornarsi in qualche modo, è piuttosto pericolosa.

Per mantenere le cose stabili, si dovrebbe quindi riferirsi ai tag dei vari prodotti:

my.package https://my.repository/svn/my.package/tags/1.2
your.package https://your.repository/svn/your.package/tags/1.4.1

Il problema ora diventa degli sviluppatori, che sarebbero obbligati a gestire manualmente il cambio di repository da tag a trunk.

Come soluzione, per un certo periodo, abbiamo sperimentato l'uso di un doppia directory dei sorgenti, una per i tag di produzione e una per lo sviluppo.

Diciamo quindi di avere un buildout con un production.cfg in questa forma:

[buildout]
...
develop =
    prod-src/my.package
    prod-src/your.package
    ...

...e un development.cfg così:

[buildout]

extends = production.cfg
...
develop +=
    src/my.package
    src/your.package
    ...

Le due directory prod-src e src venivano quindi configurate con due svn:externals differenti: uno che puntava ai tag (versioni stabili e di produzione) e l'altro alle versioni di sviluppo.

La situazione è solida, ma in presenza di molti prodotti personalizzati (10, 20, ...) questo sistema risente di lentezza in fase di aggiornamento.

Ci sono modi migliori: andiamo avanti.

infrae.subversion

L'approccio dell'uso di svn:externals aveva anche un altro aspetto negativo: i puristi (diciamo pure: i maniaci) di buildout amano controllare tutto nei propri file .cfg; nell'esempio al caso precedente viene lasciata un'importante parte della configurazione (quali sorgenti scaricare) a SVN.
In pratica, aprendo il file di configurazione buildout.cfg non siamo in grado di vedere dove e quali versioni dei prodotti stiamo utilizzando.

La recipe infrae.subversion faceva esattamente questo e per un breve periodo ha risentito di una certa popolarità: che cosa scaricare usando SVN veniva configurato in un file .cfg!

[svneggs]
recipe = infrae.subversion
location = src
urls =
    https://my.repository/svn/my.package/tags/1.2 my.repository
    ...

La cosa non è andata avanti per molto, per vari aspetti negativi dell'approccio tra cui la lentezza (maggiore che usando svn:externals) e la fragilità (spesso gli aggiornamenti non andavano a buon fine).

Dimentichiamoci quindi anche di questo approccio.

Habemus egg

Torniamo al principio:
L'uso della sezione develop del nostro buildout è stata prevista per lo sviluppo.

Rendiamoci conto che tutti questi problemi si hanno solo in presenza di codice non pubblicamente rilasciato e rilasciabile: un qualunque prodotto pubblico viene scaricato automaticamente dal Python Package Index e ci dobbiamo preoccupare del suo sorgente solo se intendiamo mettergli mano per svilupparlo.

La soluzione migliore, da tempo documentata, è:

• poter utilizzare un server pypi privato (aziendale o del cliente)
• rilasciare i prodotti nel formato standard python (gli egg per l'appunto).

Il primo caso è in realtà piuttosto semplice: un pypi server non è altro che una directory di file accessibile via Web/HTTP.

Ammettendo di avere una directory su un server privato e che questa directory contenga tutti i nostri egg, questo semplice comando Python lanciato sul server permetterebbe di avere un repository di egg compatibile con buildout:

$ cd pypi-archive
$ python -m SimpleHTTPServer 9000

A questo punto va indicato al buildout che esiste questa possibilità:

[buildout]
...
find-links =
    http://dist.plone.org/release/4.2.4
    http://dist.plone.org/thirdparty
    http://the.server:9000/

Ovviamente un modo più robusto sarebbe quello di configurare un vero web server, come Apache.

Il problema in questo caso è che l'egg, una volta generato, andrebbe copiato manualmente in questa directory, mentre l'uso del Python Package Index ci ha abituati a un automatismo a cui è difficile rinunciare.
Presto detto: se volete ottenere un server in stile pypi perfettamente funzionante, potete usare Plone stesso e il prodotto PloneSoftwareCenter (che supporta le Python Package Index API).

Ora il secondo problema: com'è fatto un egg? Come posso generarlo e rilasciarlo?

Se per anni il rilascio di egg (pubblico o privato che fosse) necessitava di conoscere almeno i rudimenti di distutils, oggi ci sono fantastiche utility che nascondono tutta la complessità. In questo stesso blog potete leggere una dettagliata descrizione del migliore di questi: zest.releaser.

Come potete leggere dall'articolo, zest.releaser si occupa di tutte quelle operazioni di versionamento del codice necessarie al momento di una nuova release (aggiornamento, tag della versione, ...) e lo fa per varie tecnologie di versionamento (SVN, Git, Mercurial, ...).

Sembrerebbe quindi che abbiamo trovato la soluzione migliore per i nostri prodotti proprietari:

• codice versionato
• buildout che usa mr.developer
• server pypi riservato
• uso di zest.releaser.

Ambienti poco amichevoli

Non abbiamo però definito che cosa si intende per "server pypi riservato". Questo può essere:

• un servizio pubblicamente accessibile ma protetto da autenticazione
• un servizio senza autenticazione, ma posto su rete interna del cliente o dell'azienda.

Nel primo caso, l'autenticazione può essere un problema: configurare buildout/Python perché richieda autenticazione non è esattamente triviale e può dare vari grattacapi.

Nel secondo caso tutto torna ad essere molto semplice, ma cosa succede se il servizio è nella rete interna del cliente e siete voi il fornitore che deve mettere mano al codice per poi rilasciare nuove versioni?
A meno di non possedere una VPN, la cosa non sta in piedi.

In più: ci sono situazioni in cui l'accesso alla rete dall'esterno (e a volte anche verso l'esterno) è fortemente limitato da policy di sicurezza e regole di firewall che farebbero impallidire lo scudo sulla luna boscosa di Endor.

La difficoltà di poter avere un repository di egg condiviso tra voi e il cliente può non essere banale.

Ci sono però alcuni prerequisiti su cui non si transige: i sistemisti avranno dovuto accettare per forza di cose che "Plone non viene distribuito con un CD ma viene installato accedendo alla Rete" e che "Il buildout usa un sistema di versionamento a cui gli sviluppatori devono poter accedere".

In questi casi limite, noi in RedTurtle abbiamo iniziato a usare un metodo forse non troppo pulito, ma semplice e senza controindicazioni.

Pypi-local!

L'idea è semplice:

• generare gli egg senza rilasciarli (ci piace rilasciare codice, ma non sempre si può)
• inserire gli egg nel buildout, in una directory
• versionare anche i sorgenti dell'egg.

"pypi-local" è stato il primo nome dato alla directory atta ad ospitare gli "egg locali", e da allora non è più cambiato (se in RedTurtle qualcuno dice "...è nella pypi-local" tutti capiscono!).

Tenendo fede a questo nome, ecco come configurare il buildout:

[buildout]
...
find-links =
    ./pypi-local
    http://dist.plone.org/release/4.2.4
    http://dist.plone.org/thirdparty

In pratica, nella radice del buildout deve esistere questa directory.

Prima di impallidire per la poca eleganza di questo approccio, sappiate che questo ci ha aiutato in molte situazioni, non ultimo il caso seguente: dare un prodotto (sempre non rilasciato pubblicamente, a volte per mere questioni di "non saprei se va bene per pypi") a un cliente con un livello tecnico minimo, limitato solo al "so lanciare un buildout".
Come? Si manda l'egg per e-mail, con due righe di istruzioni e il gioco è fatto.

rt.zestreleaser.pypilocal

Fermo restando che nessuno vuole abbandonare l'uso di zest.releaser, l'uso della directory locale richiede la perdita di un automatismo e una copia manuale dell'egg generato nella directory:

...
Register and upload to pypi (y/N)? 
Register and upload to plone.org (Y/n)? n
Register and upload to redturtle (Y/n)? n
...
INFO: Finished full release.
INFO: Reminder: tag checkout is in /private/var/folders/Ka/Ka7qqP8VFb8dZJO8sohbrE+++TI/-Tmp-/...

zest.releaser esegue una serie di operazioni automatiche per rilasciare gli egg su tutti i server configurati, ma alla fine ci dice dove possiamo trovare la copia temporanea usata per queste operazioni ("Reminder: tag checkout is in...").

Ci basta andare cercare il nostro egg dentro a quella directory (nella sottodirectory dist).

Semplice? Sì, ma rimangono due considerazioni:

• la programmazione fa l'uomo pigro
• zest.releaser è maledettamente ben fatto, ed è pluggabile.

Per questo motivo (sì, esatto, solo per non dover copiare manualmente l'egg) abbiamo reso disponibile un plugin per zest.releaser che permette di copiare automaticamente l'egg nella directory "pypi-local" (o in qualunque directory vogliate): rt.zestreleaser.pypilocal.

La sua configurazione è molto semplice: vi basta modificare il vostro file .pypirc nel seguente modo:

[distutils]
index-servers =
 pypi
 plone.org
 ...

[rt.zestreleaser.pypilocal]
pypi-local = ../../pypi-local
global = /opt/global-pypi

Nella sezione "rt.zestreleaser.pypilocal" dovete andare a specificare la directory (volendo anche più di una) che zest.releaser cercherà prima di chiedervi se intendete copiare lì i file.

L'esempio "../../pypi-local" non è casuale: se state usando un struttura di directory standard nel vostro buildout, quando lancerete i comandi di zest.releaser vi troverete dentro alla directory del vostro prodotto (solitamente qualcosa nella forma buildout-root/src/my.package). Il percorso relativo fornito rispecchia esattamente l'idea che la directory pypi-local sia nella radice del buildout.

L'output di zest.releaser cambierà in questo modo:

...
Register and upload to pypi (y/N)? 
Register and upload to plone.org (Y/n)? n
Register and upload to redturtle (Y/n)? n
Copy egg to folder ../../pypi-local (Y/n)? 
Copy egg to folder /opt/global-pypi (Y/n)? n
...
INFO: Finished full release.
INFO: Reminder: tag checkout is in /private/var/folders/Ka/Ka7qqP8VFb8dZJO8sohbrE+++TI/-Tmp-/...

Conclusione

Tra tutti i metodi descritti, spero ne abbiate trovato almeno uno che si adatti alle vostre esigenze.

Gli strumenti per fare le cose nel modo giusto e per evitare il caos nella gestione dei vostri add-on Plone ci sono tutti, e sono semplici da usare!

L'immagine in testata è di fifthconspiracy.

Il perché è ovvio: ogni persona ha come minimo 50 registrazioni a siti vari e, soprattutto, ogni internauta di oggi ha un profilo su più social network.
Da qui la brillante idea di permettere di accedere ai siti direttamente con un altro account che fornisca l'identità.

Plone non poteva certo rimanere indietro su questo fronte e quindi ecco plonesocial.auth.rpx: un pacchetto che utilizza i servizi di autenticazione RPX offerti Janrain.

Una nostra personalizzazione

Il plugin di COM.lounge non rispondeva però appieno alle necessità di un nostro cliente, il quale non voleva l'autenticazione automatica indiscriminata da parte di tutti ma un secondo step di registrazione in cui richiedere alcuni dati aggiuntivi.
Abbiamo quindi deciso di estendere il prodotto originale sviluppandone una nostra versione in cui:

• abbiamo aggiunto un campo "telefono" al profilo utente
• abbiamo aggiunto un form obbligatorio per effettuare la registrazione al portale
• abbiamo modificato il plugin di autenticazione in modo da lasciare anonimi tutti gli utenti che non hanno completato il form.

Configuriamo il sistema

La prima cosa da configurare è Janrain stesso che, in linea con la politica di questo sistema, non fornisce la possibilità di una registrazione diretta al sistema ma solo tramite un account preesistente.

 

 

 

 

 

 

Dopo aver confermato le informazioni del proprio account, bisogna scegliere un nome per la propria applicazione.

 

 

 

 

 

 

 

 

Il dominio RPX, basato sul nome che avete scelto per la vostra applicazione, insieme ad alcune altre chiavi vanno a comporre le informazioni di configurazione. Queste sono necessarie a configurare il nostro pacchetto Plone.

 

 

 

 

 

 

A questo punto la configurazione “Plone to RPX” è completa, ma ora bisogna configurare RPX perché si colleghi ai vari provider di Online ID per i quali si vuole garantire l’accesso sul nostro portale Plone.

La home dell’applicazione presenta alcune informazioni sugli accessi, limitate se si sta utilizzando la versione gratuita, molto più complete se avete acquistato una versione plus, pro o enterprise.
Dei vari menù e quick links disponibili quello che ci interessa è il menu “Development -> Provider Configuration”.

Nell’immagine qui sopra si può vedere che, al momento, la mia applicazione è configurata per gestire l’accesso tramite Facebook e Google; l’altro dettaglio visibile è che molte delle opzioni sono disponibili solo per le versioni a pagamento.

 

Ora vediamo come configurare RPX per connettersi ad uno degli Online ID disponibili e prendiamo come esempio la configurazione per Twitter.

Cliccando sul pulsante “Configure” parte un wizard che fa compiere tutti i passi necessari.

Per collegare Twitter, ma anche Facebook tra quelli che ho avuto modo di provare, occorre attivare il proprio account come “Developers”. Nulla di particolarmente difficile, sul web si trovano tutte le informazioni necessarie, ma è un’ulteriore passaggio da fare.

Una volta effettuato l’accesso, bisogna creare la propria applicazione tramite la compilazione di un semplice form dove è necessario inserire i parametri indicati nella seconda schermata del wizard.

La terza schermata dice di impostare il permesso di “lettura e scrittura” da parte della vostra applicazione su Twitter, mentre l’ultimo passaggio da fare è impostare in RPX i parametri di “customer Key” e “Customer Secret” per effettuare il collegamento tra i due sistemi.

I wizard di configurazione non sono tutti uguali, perché ogni provider necessita di configurazioni particolari, ma si concludono tutti con la richiesta dei parametri per il collegamento tra i sistemi.

Per concludere la configurazione di RPX, bisogna andare a impostare il widget di Sign-in che verrà mostrato nel proprio sito scegliendo i tipi di account che sono stati precedentemente configurati.

 

A questo punto tutto è pronto per effettuare l’accesso con Online ID in Plone; buon login!