Configura

Il sistema è molto semplice e molto
come-te-lo-aspetti:

1. vai su ploud.com
2. iscriviti: email, dominio, lingua
3. controlla la tua posta: c'è una mail di validazione con un link (devo davvero dirti che fare? :-)
4. ti chiederà la password che vorrai utilizzare
5. fatto.

Ci sono 2 tipi di servizi: gratuito e a canone mensile. Fondamentalmente si tratta della stessa soluzione, ma a pagamento ottieni:

• la possibilità di avere un tuo dominio
• più banda
• più spazio
• indicizzazione di google

Scegli il tema

Ora puoi impostarti il tuo tema tra quelli disponibili.

Tra gli 11 disponibili, io ho scelto "Earthling two" che avevamo adattato e rilasciato mesi fa su pypi.
E' bello vedere come ancora una volta la comunità funziona.

Tra l'altro l'uso di Diazo facilita molto l'implementazione di questo tipo di servizi: oggi ci sono "solo" 11 temi, ma è possibile aggiungerne altri.

Aggiungi funzionalità 

Ora puoi aggiungere gli add-on, tra cui:

• Carousel
• Dropdown menu
• Autenticazione con OpenID
• PloneFormGen per creare moduli online
• Simple Social: vuoi farti mancare Facebook & co?
• Workflow personalizzati per cartella
• Copia di lavoro
• plone.app.caching: cache per siti più veloci

e i due nuovi cavalli di razza di Plone:

• Dexterity
• Diazo theme support

Quindi?

Beh, è Plone! Hai tutto quello che puoi fare con Plone, niente di meno. Ci sono alcuni add-on interessanti anche se c'è tutta una serie di ulteriori add-on che vorrei già poter usare.

L'attuale target di mercato è sicuramente molto basico e i temi sono veramente pochi (anche se con Diazo e un po' di olio di gomito puoi fare faville).

Seconde me ha le potenzialità necessarie per crescere. Stay tuned.

Per lo sviluppo di un'applicazione mi sono trovata a dover generare un pdf il cui contenuto consiste in un modulo, ad esempio il modulo del censimento, compilato con i dati degli utenti dell'applicazione presi run-time dal sistema.

Avrei impiegato troppo tempo a disegnare il modulo insieme ai dati dell'utente, in più, per certi moduli (come il modulo censimento) sono già forniti i pdf.

Pensare di caricare il modulo come immagine di sfondo non è fattibile. Prima di tutto per la qualità scarsa del pdf finale e poi perché le dimensioni del file di output aumentano molto a causa dell'immagine usata come sfondo.

Il file da ottenere è un modulo già fornito in versione pdf, ma a cui ho bisogno di aggiungere testo.

La soluzione, a mio avviso migliore, è stata quella di usare ReportLab per disegnare un pdf fatto unicamente dei dati dell'utente per poi fare un merge del primo con il pdf contente il modulo, usando PyPDF.

L'unica difficoltà in questo approccio è creare il pdf contenente i dati di riempimento. Infatti questi dati devono essere nella posizione giusta, prioprio come se stessimo compilando il modulo.

Per superare questo ostacolo agilmente ho usato uno screen ruler. Io ho preferito "Free Ruler" per Mac OS X tra i vari righelli che ho trovato in rete, soprattutto per il suo tick mark interattivo che permette di fare una misura abbastanza accurata.

Ho aperto il pdf con il modulo da compilare, e poi ho misurato con il righello i punti in cui inserire i dati. Per creare il pdf con i dati di riempimento ho usato ReportLab che consente di scrivere stringhe di testo in un punto esatto, utilizzando le coordinate x e y.

Ecco la MIA ricetta

Passo 1

Aprire il pdf che rappresenta la base del nostro impasto, ovvero  il modulo da compilare, usando la classe PdfFileReader di pyPdf.

import codecs
from pyPdf import PdfFileWriter, PdfFileReader

input1 = PdfFileReader(codecs.open(path_modello_censimento, "rb"))

Passo 2

Preparare il pdf con i nostri canditi: i dati di riempimento. Qui entra in gioco ReportLab.

import StringIO
from reportlab.pdfgen import canvas
from reportlab.lib.units import cm

packet = StringIO.StringIO()
can = canvas.Canvas(packet)
...
textobject = can.beginText()
textobject.setTextOrigin( 11.94*cm, 20.12*cm)
textobject.textLine('hello world')
...
can.drawText(textobject)
can.showPage()
can.save()
packet.seek(0)

Come unità ho usato i centrimenti, sia nel fissare l'origine di ogni striga di testo inserita, sia quando ho misurato con il righello. 11.94 e 20.12 sono due esempi di coordinate.

Tenere presente che l'orgine si trova in basso a sinistra. Ma con l'istruzione seguente possiamo spostare l'orgine in alto.

can.translate(cm, cm)

Passo 3

Aprire il pdf creato sopra con PdfFileReader.

input2 = PdfFileReader(packet)

Passo 4

Aprire il pdf finale, che conterrà il merge dei due pdf precedenti con la classe PdfFileWriter di pyPdf.

output = PdfFileWriter()

Passo 5

Adesso la parte più divertente: "Impastare".

page0 = input1.getPage(0)
page0.mergePage(input2.getPage(0))
output.addPage(page0)

Dopo aver unito i due pdf pagina per pagina si arriva finalment al punto 6..

Passo 6

Adesso abbiamo il nostra risultato finale "output" che può essere memorizzato ovunque si voglia, io lo scrivo in un file temporaneo per completare l'esempio:

import tempfile
temp_file_name = tempfile.mktemp()
outputStream = codecs.open(temp_file_name, mode="wb")
output.write(outputStream)
outputStream.close()
os.unlink(temp_file_name)

L'elaborazione richiede un po' di tempo, ma il risultato finale è buono. Buon appetito!

Le 3D, ma molto altro 

Il leitmotif di quest'anno è stato senz'altro il tris di Diazo, Deco e Dexterity. E' già un po' di tempo che se ne parla e non vi nascondo un po' di delusione nel vedere che sono ancora temi importanti.

Il punto cruciale sta nel fatto che negli anni passati è stata tentata una rivoluzione, che avrebbe però avuto un impatto troppo importante su tutto l'ecosistema Plone. Questo ha portato a una serie di complicazioni e di refactoring.

Ora si sta ragionando in termini di add-on per Plone che ne migliorino l'esperienza, senza introdurre stravolgimenti.

Diazo & CMSUI

E' ormai un sistema maturo utilizzato in produzione da molto tempo. 

L'idea è di:

1. semplificare la fase di skinning di Plone limitandola al frontend, più facilmente gestibile da Diazo, 
2. demandare a CMSUI tutta la fase di gestione del backend mantenendo il tutto contestuale, ma indipendente dal layout.

Direi che questi due video da soli sono sufficientemente esplicativi.

Deco

Sta raggiungendo anche lui la maturazione e si sta lavorando sulla user experience. L'idea in questo caso è quella di sostituire prodotti come PortletPage o Collage. Questa una preview realizzata dai colleghi di FourDigits.

Dexterity

Sugli scudi infine anche Dexterity, di cui parlammo ancora due anni fa come promessa e che ora sta raggiungendo il suo compimento. Sull'interfaccia c'è ancora da lavorare e non è uno strumento per tutte le stagioni, ma è sicuramente estremamente interessante.

Gli altri temi caldi

I miei talk preferiti sono stati:

• Clone to Plone

• Multiplayer Plone

• Make plone search work like Google

Il primo racconta l'utilizzo di FunnelWeb per migrare portali da un altro sistema a Plone. 

Nota mentale: ogni migrazione è un'isola, ogni migrazione è "painful"

Il secondo è stato tenuto da Geir Baekholt su istigazione di Yiorgis Gozadinos e permette di utilizzare Plone un po' alla GoogleDocs con tanto di chat e status: 

Infine l'uso di Solr al fine di ottimizzare gli indici permette anche di aumentare le funzionalità "googlesche" di Plone:

Pyramid

La track "Related Tech" è stata fortemente monopolizzata da Pyramid. E' la tecnologia "sorella" di Plone che abbiamo sposato da tempo. Ne abbiamo parlato qui, qui e anche qui. Senza contare il talk di Andrew che ormai è un bestseller alle varie conferenze.

Il Keynote

Quest'anno l'usuale keynote è stato tenuto da P.J. Onori. Personalmente l'ho trovato di particolare ispirazione: è un inno alla crescita professionale, al capire l'usabilità delle cose, alla condivisione di esperienze tra developer e designer. 

Più volte mi sono ritrovato a dire "si! si! si!".

I nostri talk

Il caso d'uso

Lo sviluppo di una applicazione mobile che deve mostrare una lista di eventi ha fatto sorgere la necessità di avere un formato di immagine piccolo (facile con Plone), quadrato (mmhm...) e senza distorsioni dell'immagine (ok, non ci siamo): qualora l'immagine non fosse quadrata, la si dovrà "croppare".

Il comportamento standard IN plone

Plone base non fornisce la possibilità di prendere una immagine qualsiasi e restituirla in un formato miniaturizzato e sicuramente quadrato.

Prendiamo, ad esempio, questa immagine:

Immagine originale di dimensione 200x150

Agendo sulle funzionalità standard di plone, andiamo in ZMI nelle 'portal_properties/image_properties' del nostro sito, e aggiungiamo fra le 'allowed_size' una 'custom_size 100:100'; poi possiamo verificare caricando l'immagine (ha dimensione 200x150) che se chiamiamo sull'oggetto 'image_custom_size', ci viene tornata un'immagine 100x75:

Immagine ridimensionata con il comportamento standard di Plone

L'immagine è stata scalata in proporzione, non è questo che vogliamo! E quindi?

Studiamo la situazione

La prima domanda che è lecito e doveroso farsi è: 

Cosa succede quando facciamo traversing su un oggetto usando come attributo da "attraversare" uno degli scaling disponibili per le immagini?

Stiamo lavorando su Plone 4 e indagando un poco si scopre che è stato registrato un adattatore per gestire il traversing in caso di immagini dentro a plone.app.imaging:

class ImageTraverser(DefaultPublishTraverse):
    """ traversal adapter for scaled down versions of image content """
    adapts(IBaseObject, IRequest)

    def fallback(self, request, name):
        return super(ImageTraverser, self).publishTraverse(request, name)

    def publishTraverse(self, request, name):
        schema = self.context.Schema()
        if '_' in name:
            fieldname, scale = name.split('_', 1)
        else:
            fieldname, scale = name, None
        field = schema.get(fieldname)
        handler = IImageScaleHandler(field, None)
        if handler is not None:
            image = handler.getScale(self.context, scale)
            if image is not None:
                return image
        return self.fallback(request, name)
   

All'interno di questo adapter abbiamo il metodo publishTraverse da cui partire e un metodo che si occupa del fallback al traverser di default nel caso non si stia lavorando allo scaling delle immagini.

Inoltre, se si lavora allo scaling delle immagini, si chiama un altro adapter (IImageScaleHandler) che fornirà i metodi per creare l'oggetto con l'immagine ridimensionata:

handler = IImageScaleHandler(field, None)
if handler is not None:
   image = handler.getScale(self.context, scale)
   if image is not None:
      return image

La soluzione

Ok, è sufficiente. Abbiamo tutto quello che ci serve sapere! Come nella maggior parte dello sviluppo che si fa per Plone/Zope, la Zope Component Architecture permetterà di fare tutto in modo relativamente veloce.

Io sto lavorando con delle immagini in un archetype customizzato, per cui la cosa più semplice da fare per me sarà registrare un adapter più specifico per l'interfaccia del mio tipo, ma possiamo banalmente proseguire l'esempio registrandone uno per IATImage:

class MyImageTraverser(DefaultPublishTraverse):
    """ traversal adapter for scaled down versions of image content """
    adapts(IATImage, IRequest)
    
    def fallback(self, request, name):
        ...
    def publishTraverse(self, request, name):
        ...

Ora abbiamo il traverser per gli oggetti che implementano IATImage, e siamo già a metà del lavoro. Il successivo e ultimo passo sarà applicare la trasformazione vera e propria. 

Come abbiamo già avuto modo di vedere, si richiama un handler nel traverser che si occupa di ottenere l'immagine scalata. Quello che possiamo fare è registrare un nostro handler personalizzato per il field che contiene l'immagine; magari chiamare un handler personalizzato in modo condizionato, per gestire soltanto i casi che ci interessano; qualcosa come:

if scale in crop_and_scale:
    handler = ICustomImageScaleHandler(field, None)
else:
    handler = IImageScaleHandler(field, None)

L'handler originale si trova in plone.app.image, nello stesso modulo del traverser; analizzando il codice ci si rende conto che se nel sistema è presente plone.app.blob, di default, si userà il BlobImageScaleHandler presente in quest'ultimo pacchetto. 

Noi potremo creare un handler personalizzato come adapter sul field che si usa per contenere l'immagine, e essendo presente plone.app.blob, lo creeremo ereditando dalla classe BlobImageScaleHandler.

All'interno dell'handler, ci sono tutti i metodi per ottenere l'immagine scalata.

Per raggiungre il nostro obiettivo, ereditando dal BlobImageScaleHandler, possiamo scrivere un handler personalizzato che conterrà un unico metodo, createScale: l'unico che ci serve personalizzare. Qui potremo applicare le trasformazioni necessarie. Il metodo originale esegue i seguenti passi:

def createScale(self, instance, scale, width, height, data=None):
    """ create & return a scaled version of the image as retrieved
        from the field or optionally given data """
    field = self.context
    if HAS_PIL and width and height:
        if data is None:
            image = field.getRaw(instance)
            if not image:
                return None
            data = str(image.data)
        if data:
            id = field.getName() + '_' + scale
            try:
                imgdata, format = field.scale(data, width, height)
            except (ConflictError, KeyboardInterrupt):
                raise
            except Exception:
                if not field.swallowResizeExceptions:
                    raise
                else:
                    exception('could not scale ImageField "%s" of %s',
                        field.getName(), instance.absolute_url())
                    return None
            content_type = 'image/%s' % format.lower()
            filename = field.getFilename(instance)
            return dict(id=id, data=imgdata.getvalue(),
                content_type=content_type, filename=filename)
    return None

Per fare la modifica, nell'handler personalizzato potremo cambiare questa riga

imgdata, format = field.scale(data, width, height)

con quello che fa più comodo, e usando il crop delle PIL potremo trasformare l'immagine come necessario, arrivando a un risultato come questo.

Immagine ridimensionata e croppata fino alla dimensione 100x100

Un progetto alla ricerca di un modello

Il panel di studiosi e stakeholders di diversi paesi Europei che stanno portando avanti il progetto OSEPA ha obiettivi di analisi, diagnosi e proposta relativi al software libero nel settore pubblico. Nel precedente post su questo tema, esprimevamo una soddisfazione che oggi, potremmo dire, è decuplicata.

Difatti, abbiamo avuto la prova concreta che PloneGov, al di là del valore intrinseco per la tecnologia su cui si basa e per la comunità che coinvolge, è prima di tutto un modello, e la descrizione che ne abbiamo sempre dato, "modello di business sostenibile", è assolutamente esatta. Chi ha promosso l'iniziativa e chi vi ha aderito nutriva già questa certezza: è importante che ora ad affermarlo sia una "terza parte" come il team OSEPA.

Cosa si sta cercando?

Sostanzialmente, si sta cercando un modo di procedere che garantisca la qualità del software, la sicurezza e la stabilità del rapporto con i fornitori o comunque un'autonomia degli Enti che garantisca un futuro alla tecnologia e un supporto durevole, un modello che in qualche modo si autosostenga e si autogarantisca sia sul piano economico, sia su quello operativo.

Cosa si è trovato

Le conclusioni dei tre pannelli indipendenti creati nel corso dei lavori, due dei quali comprendevano una persona RedTurtle, sono convergenti:

• occorrono aziende che siano realmente parte della comunità e che vedano il contributo alla crescita della tecnologia FLOSS come un'opportunità;
  
• occorrono rapporti chiari e collaborativi tra aziende a Enti Pubblici, che devono individuare e difendere un interesse comune: l'economicità e la sostenibilità del modello, la qualità del software e lo scambio di conoscenze;
• occorre una crescita culturale degli Enti che ne faccia parte viva e attiva del modello di business;
  
• occorre coinvolgere il livello dei decisori nella scelta e nella visione che ne risulta.

Occorre, insomma "il triangolo di PloneGov", schema che effettivamente, nella sua semplicità, ha "folgorato" tutti i presenti.

La giornata di lavori

Il MAMBO, museo di arte moderna del capoluogo emiliano, si è ben prestato al meeting, che ieri 29 settembre viveva la sua seconda e ultima giornata. L'ampio salone oggetto del convegno, sede di un'installazione che ne seguiva il perimetro, era accogliente e provvisto di ogni tecnologia necessaria.

In fase iniziale, si è svolta la presentazione di una serie di casi di studio tra cui quello del Politecnico di Milano (che evidenzia luci e ombre, non esclusi gli opportunismi, del mercato FLOSS) e quello della regione spagnola dell'Extremadura, e ovviamente quello di PloneGov Italia curato da Stefano Marchetti, e in seconda battuta da chi scrive; ognuno degli interventi è stato seguito da domande e risposte. Ha seguito una sessione interattiva, nel corso della quale i partecipanti si sono divisi in tre gruppi, per rispondere indipendentemente alla domanda che più o meno suonava così "Quali modelli possono garantire agli Enti Pubblici Europei la qualità del software libero, un corretto rapporto con le aziende e la maggiore efficacia a parità di costo? Di quali fattori è necessario tenere conto?".

Come già detto, le conclusioni dei gruppi sono andate a convergere su un modello stile PloneGov Italia.

Dopo il pranzo, l'organizzazione ha offerto un piacevole tour in bus scoperto, propiziato da un tempo ideale (anche il sole sembra arridere a PloneGov!). A margine, il Politecnico di Milano ci ha "arruolato" come case study di compagnia "immersa" nelle comunità open source - un caso che evidentemente è meno comune di quanto credessimo, visto che non è stato considerato nel campione di studio su cui PoliMI ha basato la sua relazione.

Ogniqualvolta le aziende organizzatrici (RedTurtle, Abstract e BioDec) sono ricorse alla collaborazione dei propri Clienti (fanno fede precedenti come i due Plone for Research and University Day e l'evento ospitato del Comune di Padova), il loro coinvolgimento è stato totale.

Anche ENEA Roma, che ci ha ospitati nella tappa del 28 Settembre,  ha fornito sala, infrastruttura per il webcast dell'intera giornata di lavori, regia e personale tecnico, nonchè una sala più che adeguata alle esigenze del convegno e del catering. Ancor meglio, a conferma della scelta di Plone per il portale dell'Ente, ha fornito una consistente parte del numeroso pubblico, segno questo di forte impegno verso il software libero a più riprese ribadito dai relatori istituzionali, Diana Savelli, Andrea Quintiliani e l'Ing.Silvio Migliori, responsabile di diversi progetti di High Performance Computing.

Mattina: relazioni

Il dispiacere per l'assenza del relatore di ISFOL, impossibilitato a presenziare per motivi personali, è stato compensato dagli interessanti talk sull'esperienza di ENEA nell'allestmento di siti, e in particolare dall'attesissimo intervento di Flavia Marzano, che nell'occasione ha tracciato con il consueto equilibrio gli orizzonti di impiego del cloud nel settore pubblico. A questo che è un po' stato il "keynote speech" della mattina sono seguite, dopo il coffee break, le interessanti presentazioni delle Università di Macerata e di Bari, che hanno toccato anche aspetti di tipo organizzativo e architetturale.

E' quindi venuto il mio turno: nel presentare un'applicazione "fuori tema" come l'ERP Web sviluppato da RedTurtle Technology, ho chiarito che, al di là del caso di specie, certamente distante dall'esperienza del pubblico, mi interessava dare una misura della solidità "industry standard" e della plasticità di soluzioni in cui Plone è il front-end di un sistema basato su Pyramid, farmework applicativo utilissimo per applicazioni web che vadano al di là della gestione contenuti. Le integrazioni con dispositivi mobili sono un altro tema di interesse trasversale, in particolare per Enti di ricerca come ENEA

Maurizio Delmonte ha quindi illustrato con la sua tipica chiarezza e completezza il caso di studio del SIT del consorzio COSIB, applicazione fortemente integrata con un database geografico e tecnico, dall'interfaccia utente particolarmente riuscita.

Pomeriggio: dibattito

Dopo un catering molto apprezzato, è iniziato un dibattito che per circa due ore ha visti impegnati l'Ing. Migliori di ENEA in qualità di chairman e noi delle aziende (Maurizio in particolare) come animatori. Ne è emerso un quadro interessante, di grande consapevolezza da parte degli Enti presenti, ma anche la certezza che le difficoltà non vanno sottovalutate. Il pomeriggio ha anche fornito l'opportunità per ritornare su temi che al mattino erano semplicemente stati accennati, come qualche informazione in più sul tema delle licenze del software libero o le dinamiche di riuso presenti in PloneGov.

Sintesi

E' evidente che ENEA, nel suo ruolo di Ente ospitante, ha voluto dare un forte segno di "commitment" sul software libero, prima di tutto al suo stesso interno. Ciò non ha impedito che i presenti, a prescindere dall'Ente di appartenenza, siano usciti arricchiti dall'esperienza di un incontro che, come nella nostra migliore tradizione, ha effettivamente compiuto la missione di discutere, senza prevenzione e posizioni massimaliste, sull'esperienza di introduzione del software libero negli Enti, con un'equilibrata rappresentazione di luci e ombre. Proprio ciò che serve per rimanere nel mondo reale e fare crescere, al di là di proclami di principio, il free software nel Settore Pubblico italiano.

Dopo la rifondazione che abbiamo attuato nei mesi scorsi, abbiamo deciso di tenere una serie di incontri trimestrali. Vogliamo approfondire al massimo la conoscenza reciproca, raccontarci le nostre esperienze e dare/ricevere dai colleghi spunti e opportunità. Una specie di micro-conferenza con cadenza molto ravvicinata.

Erano presenti 8 partner oltre a noi:

• Four Digits (NL)
• Abstract (IT)
• Jarn (NO)
• Gocept (DE)
• Infrae (NL)
• Greenfinity (HU)
• Startifact (NL)
• Netsight (UK)
• RedTurtle (IT)

I talk

La giornata era organizzata in modo da avere talk ma anche spazio per discussioni aperte e lighting talk.

Evito di entrare nei dettagli: c'è un ottimo post di Matt Hamilton (Netsight) che vi invito a leggere.

Primo meeting: un sacco di cose da decidere!

Allo scorso Sorrento sprint è stato eletto un board (Kit Blake, Geir Baekholt e il sottoscritto) e in questo senso eravamo ora chiamati a proporre una strategia da seguire per i prossimi anni.

Questo è un cambiamento importante rispetto alla passata gestione. Abbiamo una strategia, condivisa tra il board e i membri che possono approvarla, emendarla, aggiungere nuove proposte. 

Il presidente, e il suo vice che lo affiancherà fino a sostituirlo dopo 6 mesi, hanno l'incarico di metterla in pratica. Il board supervisiona in modo light i vari presidenti nell'arco di 5 anni. Giusto per garantire un minimo di continuità nelle iniziative.

La nostra proposta è fondamentalmente basata su due capisaldi.

• ZEA sarà molto più leggera: poca burocrazia, quote di partecipazione contenute (400€ per le aziende oltre i 3 componenti, 100€ per gli altri e try-before-buy fino a tutto dicembre), nessun vincolo di azione o partecipazione da parte dei membri. ZEA agevola le opportunità: non le crea e non le impone.
• ZEA sarà molto più comunitaria e coesa: una meta-company di 100+ persone, con gli skill derivati dalle competenze di 20+ aziende. Agiremo ognuno come sede locale di ognuno degli altri. Ancora una volta saremo a diffondere il verbo di Plone, come sempre secondo la nostra mission, e lo faremo in modo coordinato e condiviso. 

Le azioni pratiche che contiamo di intraprendere nel breve e nel medio periodo sono:

• partecipare a eventi transnazionali a livello europeo per far conoscere Plone e il nostro brand;
• spingere sull'organizzazione e sulla partecipazione a sprint e tune up per continuare a evolvere (evolution not revolution) il nostro CMS preferito;
• organizzare un Transnational Exchange Programme durante il quale sviluppatori di un'azienda andranno a lavorare in altre aziende del gruppo per qualche tempo;
• ehm... sì, avremo anche un nuovo website

E non sarà solo Plone. Pyramid e Django già da un po' lo stanno affiancando. E non sarà solo tecnologia, in diversi abbiamo evidenziato competenze consulenziali che finora erano rimaste colpevolmente taciute.

Questa proposte, che come board abbiamo avanzato, sono state apprezzate dai membri e nei prossimi mesi proveremo, appunto, a metterle in pratica.

La community

Lo so. Mi ritrovo spesso a ripetere come un mantra la parola "community": nei post, nei talk, nelle serate con i colleghi, nelle presentazioni ai clienti.

Ancora una volta son qui a sottolineare questo aspetto: essere parte di una comunità. 

Questa volta però non è una comunità di persone, ma una comunità di aziende. L'idea di base non cambia: in fondo le persone che guidano queste aziende sono le stesse che negli anni hanno sviluppato e evangelizzato il mondo su plone. Abbiamo ancora la stessa idea fissa (potevo dire meravigliosa). 

Quello che cambia è il punto di vista. Un'azienda deve produrre reddito per sé e per tutte le persone che vi lavorano. E deve farlo in modo continuativo, organizzato, pensato.

Questo è un bene per Plone. E un bene per i nostri clienti (l'esperto della funzionalità che serve al mio cliente è sempre stato a un colpo di telefono, ma lo conosco molto meglio)

Personalmente, l'essere parte di una comunità di imprenditori mi aiuta a semplificare questa fase: tutti tendiamo a rendere le nostre aziende floride e stabili nel tempo, non dovrò più inventarmi in solitudine il modo migliore per farlo, potrò anche mettere a frutto suggerimenti e mediare iniziative già intraprese con successo da altri.

E' stata una 2 giorni impegnativa, carica di aspettative e con molte speranze per il futuro. Come lo stesso Matt nel suo post, anch'io "look forward to the next meeting in January…" ovunque sarà.  :-)

Un percorso che prosegue

Abstract, BioDec e RedTurtle continuano a collaborare sul fronte della divulgazione e promozione del software libero: anche quest'anno il trio di aziende ha ottenuto la collaborazione di un Cliente storico per ospitare, il 28 settembre, una tappa del ContènTOUR.

Grazie al particolare impegno di Abstract, si è ottenuta l'ospitalità di ENEA, un Cliente con il quale due delle aziende organizzatrici (appunto Abstract e noi) collaborano da tempo, su commesse separate, ma nel comune segno di un'attenzione al software libero nel mondo della ricerca e dell'accademia, già emersa prepotentemente nelle iniziative, anch'esse cogestite dal nostro trio di aziende, e denominate Plone for Research and University, ospitate una al CNR di Bologna, e una al TIGEM di Napoli.

Il programma della giornata

• la convinzione con cui l'Ente ospitante, ENEA, esporrà le ragioni della propria "love story" con Plone, oggi in uso sia la centro, sia nelle sedi geografiche, con un'estensiva formazione del personale ENEA per l'utilizzo del software libero;
• la presenza di un altro caso di studio legato alla PAC, in questo caso un Ente sul quale Abstract e RedTurtle operano congiuntamente in ATI: ISFOL, l'Istituto Superiore per la Formazione dei lavoratori, che ha scelto Plone per il proprio portale istituzionale;
• gli interventi delle Università di Bari e Macerata, a confermare che il mondo dell'Accademia è un terreno fertile per Plone (tra le università membri di PloneGov italia, ricordiamo anche Roma Sapienza e Ferrara);
  
• last but not least, un intervento di Flavia Marzano, una delle voci più autorevoli sull'apertura nella PA italiana.

Come iscriversi?

Come si vede, vale la pena di esserci: in particolare considerando che la partecipazione all'evento è gratuita, il link per l'iscrizione si puà trovare in fondo alla pagina riassuntiva sul sito dell'evento.

Una istituzione aperta al confronto

La doppia natura di forza di polizia e corpo militare da sempre conferisce alla Guardia di Finanza, assieme a uno spettro di competenze davvero ampio, anche una particolare attenzione agli aspetti tecnologici e di comunicazione.

Alla loro convergenza, i siti Web istituzionali: sfida ed opportunità affrontata, in questo caso, con intraprendenza da uno staff brillante che non solo ha saputo scegliere bene (parliamo di Plone), ma soprattutto ha saputo convincere - con la forza dei fatti - la catena gerarchica dell'opportunità di questa scelta.

Da osservatori a membri di PloneGov Italia

Ci fa particolarmente piacere che - in modo indiretto - PloneGov abbia accompagnato fin dal primo istante questa esperienza. Era l'Ottobre 2010 quando l'Ufficio Centrale Relazioni con il Pubblico della GdF contattava il Comune di Modena, identificato come uno dei membri PloneGov più attivi, alla ricerca di una collaborazione che consentisse di migliorare le competenze autonomamente sviluppate. Da subito, nasceva la proposta di formalizzare l'adesione a PloneGov Italia.

Esplorando i siti Modenesi, lo staff GdF individuava rt.video, la soluzione sviluppata da RedTurtle a Modena per il portale multimedia.mo e si rivolgeva a noi, chiedendo chiarimenti tecnici per procedere al riuso della stessa, assieme a una proposta formativa simile a quella a suo tempo erogata a Modena. Inoltre, analizzando il software offerto in riuso membri Plonegov Italia, si imbatteva nel selettore dei nomi di Enti territoriali proposto dalla regione Emilia Romagna, entrando in contatto anche con questo Ente. Altra fonte di ispirazione, alcuni dei prodotti Redturtle rilasciati al pubblico dominio, come redturtle.portletpage.views.

Una celebrazione speciale

Nel frattempo la burocrazia faceva il suo corso, veniva perfezionato un contratto con Redturtle per la fornitura di servizi e formazione, e il 23 giugno 2011 il 237° anniversario della fondazione della Guardia di Finanza veniva celebrato anche con uno streaming dell'intera cerimonia sul nuovo portale multimediale Plone.

Insomma, la GdF ha saputo destreggiarsi nel modo migliore, prima scegliendo una tecnologia flessibile ed aperta, poi individuando chi poteva aiutare l'Ente a migliorare la propria competenza, e soprattutto facendo in modo di minimizzare i costi rispetto al risultato. Tutto ciò, crescendo di competenza e migliorando la qualità del servizio. Una strada aperta a tutti, e tanto più agevole, quanti più Enti la percorrono: il prestigio e la dimensione della Guardia di Finanza, che certamente presto inizierà a sviluppare e rilasciare componenti Plone, sono una garanzia per il futuro di questa autostrada del riuso.

It has been a tiring but exciting week in Florence.

After four years of national PyCon Italy, the team has been excellent and set up an event that clearly shows the level of maturity of the community.

Over the years since the first EuroPython conference, the big change is that we don't have to justify our language choice anymore.

Actually, I would not even be a programmer it where was no Python. I was a system administrator, more like a plumber than an internal decorator.
Python has taken me by hand, teaching and letting me write things I would not have attempted in other languages available at the time.

As programmers, we make trade-offs and take compromises several times per day, while we design and write applications.
Very often we take a different road than we did the day before, because we've seen what lays ahead and want to avoid it, or the customer has changed his mind, or we have a better understanding of the whole.

As a matter of fact the right answer to a programming question is often "it depends", because the architectures, markets and business models are getting more and more complex, and we as software craftsmen have none of the certainties than mathematicians or computer science people take for granted.

Fortunately for us and our customers, software can be easily changed, and nothing prevents experimenting with different approaches if time allows.
But once in a while - typically at the start of a development cycle - we have bigger choices, the decisions that make room for the following ones: the basic architecture.

• What language(s) are we going to use? (that's easy, Python. but it depends)
• Light framework or a heavy, full featured one?

• Relational or non-relational database? And if non-relational, which of the many?
• Is our application process or data driven, or both? (this is vague. it's usually both)
• Browser or server side processing?
• How will it scale to many concurrent users?

and so on, and on.

At this point, if we pick the wrong road, the application could still be delivered, hopefully in time and the customer will be happy (at first), but the program itself might be a lot more complicated than it needs to be, and hard to change. The price will be paid over time, as new needs come and maintenance is required.

Unfortunately for us, some of these are hard questions, also subject of fashions and marker pressure, and it is very hard to have a comprehensive picture just by following technical blogs.

That's why I long for conferences like EuroPython, where the scope of the talks is as wide as can be, while still remaining highly technical.
Where the authors are ready to discuss about it over the lunch, and everybody is smart for having chosen Python :-)

Best talks.. ever :-)

A few of the talks tackling old problems in light of new tools and experiences:

Relate or !Relate (Mark Ramm-Christensen)

Mark explains the difference between the forest of NoSQL databases, and shows that a good SQL DBMS can scale surprisingly well.
This is a dear topic to me, because direct approaches in one side require complex contraptions on the other one, and vice-versa.
As a side note, lately the MySQL - Postgres debate seems to be over. The latter one has sharply won, if not the market, the minds of the programmers.

How to build complex web applications having fun? (Andrew Mleczko)

If the user wants both, give them both. Instead of fitting every requirement in a single architecture, try deploying a full-featured
CMS along with a light, flexible framework and divide the tasks -- a little like loading a bike on your camper.
You can go anywhere and they integrate well.
This is easier today (in the post-WSGI world) thanks to Pyramid, a highly refined foundation for web applications that lets a lot
of freedom: should the architecture be modeled after Zope, Plone, Pylons, Turbogears, Rails or Django? With Pyramid, "it depends" is the main concept :)

Other worth mentioning

• Challenges in developing a large Django site (Simon Willison)
• An iPhone-Python love affair: Building APIs for mobile (Anna Callahan - Nate Aune)

I also had fun with Raymond Hettinger, the only developer I've known that adds a +1 charisma bonus within a 10mt radius.

In his training track, he tore apart core concepts of Python (classes, decorators, properties, descriptors, dictionaries) and as he spoke rebuilt them using lists only. MacGyver couldn't do better!

But really, I could list half of the talks in the schedule, they are that good, and they kept a good balance of more and less advanced matters.

and the plone-ish stuff?

Sure, I would have liked a few more talks about Zope, Plone, BlueBream or Grok, especially highlighting how they have changed in the latest years, becoming more powerful, easier to extend and deploy, and there should be some effort communicating that to new developers.

They are coming to the conference to look for directions, and might go after some fashionable, but less capable tools.