Personal tools

You are reading the articles stored in Report e pubblicazioni

Jun 29, 2011

Europython 2011: aftermath

Filed Under:

Want to get rich? Create a methodology. Want to write better programs? Go to EuroPython!

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.

For me, Python was an easy choice, but... difficult to master.

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

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.

Jun 20, 2011

Pyramid CRUD sprint summary

Filed Under:

Pyramid CRUD sprint is over. It was an amazing event thanks to Gaël Pasgrimaud and Patrick Gerken. We have been sprinting in Redturtle's office to improve pyramid_formalchemy and fa.jquery. We have archived most of the sprint goals!

Patrick was working on the first two tasks:


It can be used to add a skeleton to an existing project or to create a new project. If you create a new project, you must first install pyramid_formalchemy in your python environment, either with pip:

$ pip install pyramid_formalchemy

or with easy_install:

$ easy_install pyramid_formalchemy

Only after that, the paster template becomes available. The template was made with the idea that it can be used to extend existing applications. It does not create an app for you. The provided template works well with pyramid_alchemy, pyramid_routesalchemy and akhet. To bootstrap an application, call paster like that:

$ paster create -t akhet -t pyramid_fa myapp

The application is created by akhet, akhet does not know about pyramid_formalchemy, and pyramid_formalchemy cannot modify the app configuration. So you have to do this by hand. First, you must add the install dependency like explained earlier. Second, you must add the following line in the main method that returns the wsgi app, directly after Configurator has been created (The example assumes that the Configurator instance is stored under the name “config”):


To add the minimum configuration to an existing application, you should be able to run:

$ paster create -t pyramid_fa myapp

All files that paster creates are prefixed with fa, and should not interfere with existing code. 


Patrick's second task was fanstatic integration. Fanstatic is a small but powerful framework for the automatic publication of resources on a web page. Think Javascript and CSS. It just serves static content, but it does it really well. Integrating it with fa.jquery was a time consuming task but we managed to get a working proof of concept. I will blog more details when we publish something stable.

Next tasks were handled by Gaël:


Action are basically links or input button. By default there is only one category buttons which are the forms buttons but you can add some categories like this:

>>> from pyramid_formalchemy.views import ModelView
>>> from pyramid_formalchemy import actions
>>> class MyView(ModelView):
...     actions_categories = ('buttons', 'custom_actions')
...     defaults_actions = actions.defaults_actions.copy()
...     defaults_actions.update(edit_custom_actions=Actions())


Where myactions is an Actions instance

You can also customize the actions per Model:

>>> from sqlalchemy import Column, Integer
>>> from sqlalchemy.ext.declarative import declarative_base
>>> Base = declarative_base()
>>> class MyArticle(Base):
...     __tablename__ = 'myarticles'
...     edit_buttons = Actions()
...     id = Column(Integer, primary_key=True)


The available actions are: listingnewedit

But you can add your own:

>>> from pyramid_formalchemy.views import ModelView
>>> from pyramid_formalchemy import actions
>>> class MyView(ModelView):
...     actions.action()
...     def extra(self):
...         # do your stuff
...         return self.render(**kw)



Yes, pyramid_formalchemy is now i18n! You need to add to your pipeline:

default_locale_name = en
available_languages = fr en

and that's it! Right now we have english and french translations but others are coming.

I was working on the first three tasks: 

View customization

This was one of the main sprint tasks - to have a possibility to customize CRUD views per model.  You can register them simply like that:


and per Model:


formalchemy_model_view is an extension for config.add_view so you can use all view specific kwargs.


We were able to finish simple implementation of autocomplete widget. It's not yet fully documented but it will be released in pyramid_formalchemy 0.4.  Here is how you use it:

from pyramid_formalchemy.renderers import pyramid_autocomplete'name'))

where User is your fieldset and group is your relation field; filter_by parameter is the SQLAlchemy column you want to filter (autocomplete) on. 

Events hooks

We have provided four events: 

  • IBeforeValidateEvent
  • IAfterSyncEvent
  • IBeforeDeleteEvent
  • IBeforeRenderEvent

There are also two more specific render evnts: 

  • IBeforeShowRenderEvent
  • IBeforeEditRenderEvent

You can use decorator to use them:

from pyramid_formalchemy import events
from pyramidapp.models import Foo

@events.subscriber([Foo, events.IBeforeValidateEvent])
def before_foo_validate(context, event):
   #do your stuff here



It was a very productive four days. Thanks again for all your help. We should release new versions of pyramid_formalchemy and fa.jquery in the following days. If you don't want to wait - grab the development versions on github.


You can find more sprint photos here -

May 06, 2011

Una giornata da "informavori"

Prima esperienza all'Italian Information Summit: tanti spunti di riflessione e una certezza... siamo affamati di informazione :)

IASummit - nel pubblicoPrendo in prestito il termine "informavori", citato ieri dal prof. Bussolon nel talk "Fondamenti cognitivi dell'architettura dell'informazione" al V° Summit Italiano di Architettura dell'Informazione, perchè mi sembra riassumere un po' le 8 ore di incontri e seminari a cui ho assistito. Siamo affamati di informazione.

IASummit - tavola rotondaLa tavola rotonda di apertura, invece, ha affrontato il tema del ruolo dell'utente nella progettazione di interfacce e applicazioni. Impossibile riassumere tutto in un post: basta dare un'occhiata ai tweet scambiati in tempo reale per rendersi conto della tempesta di idee che ha animato la giornata.
Mi piace perciò l'idea di riprendere solo alcuni spunti della discussione usando solo le parole/tag e i pensieri che ho annotato a ruota libera.

  • Creatività, sinergia, empatia... possono andare a braccetto?
  • Non ci sono utenti nè clienti, ma... persone!
  • Progettare siti web equivale a progettare habitat digitali, all'interno dei quali l'utente/persona si muove... anche in modo imprevisto!
  • Training on the job.
  • Knowledge transfer.
  • Qualità percepita dall'utente Vs. qualità reale del servizio.
  • Il portale viene erroneamente identificato con la piattaforma tecnologica: la tecnologia, invece, deve essere invisibile per dare spazio alla comunicazione (fatta attraverso il portale) e incentrare la progettazione sull'utente!
  • Uno dei maggiori paradossi dei giorni nostri: applicazioni sempre più complesse con interfacce sempre più semplici.

IASummit - tagPer finire chiuderei con un bellissimo assunto proposto dalla prof.ssa Fiorella de Cindio del Dipartimento di Informatica e Comunicazione

dell'Università degli Studi di Milano, a proposito dei nuovi strumenti messi a disposizione degli utenti per interfacciarsi con le informazioni:

"l'iPad va considerato come oggetto di culto che deve apparire o come strumento (che deve scomparire)?"
Per estensione anche un sito web deve comportarsi nello stesso modo: inizialmente deve apparire per attrarre gli utenti, poi deve farsi invisibile per favorire la ricerca delle informazioni e la fruizione dei contenuti.

E non posso certo omettere la considerazione finale che mi vede pienamente d'accordo: "l'oggetto di culto è molto maschile e richiede manuali d'uso voluminosi e compliccati, mentre lo strumento ha una connotazione tutta femminile, come una lavatrice, e puo' essere usato senza istruzioni perchè immediato e di facile comprensione" :D

Che dire se non... buon summit a chi avrà la possibilità di seguirlo anche nei prossimi giorni!

Mar 07, 2011

Plone e StackOverflow

Filed Under:

C'è qualcosa di ancora meglio della mitica plone-users?

In questi giorni c'è un discreto dibattito sulla proposta di sostituzione della mailing list [plone-users] con StackOverflow

L'idea è di sperimentare questo servizio per un 2-3 mesi e quindi di decidere il da farsi. Quello che su cui si vuol far leva sono diversi aspetti:

  • Semplificare: Per molti, le mailing list sono uno strumento un po' ostico e Nabble non è il massimo come integrazione. Stack Overflow non necessita di particolari setup per poter cominciare a "chiedere".
  • Valutare la reputazione: Una mailing list va frequentata per capire chi sa dare le risposte corrette e chi invece no. Stackoverflow ha un allegro sistema di valutazione dei partecipanti.
  • Non chiedere 100 volte la stessa cosa: nessuno legge gli archivi di una mailing list, davvero nessuno. StackOverflow è facilmente "cercabile".
  • Visibilità verso il mondo: Occorre che la comunità esca dal suo guscio dorato. Ebbene si, siamo maledetti snob che giocano con il miglior CMS sul mercato. Il confronto non può che far bene a noi stessi e anche agli altri: per Giove, non possono continuare ad utilizzare quegli antiquati CMS :)
  • Notifiche: Se c'è un'argomento che vuoi seguire, beh è bene che tu venga avvertito: una ML, tantomeno Nabble, è in grado di farlo.
  • Tonnellate di email vs RSS: questo potrebbe essere vantaggioso, ma è un punto alquanto controverso. Gli RSS di Stackoverflow mostrano le domande, non le risposte. E c'è chi preferisce il proprio client di posta a l'ennesimo portale da tenere sotto controllo.


Personalmente credo che sia un cambiamento interessante, in generale sono per i cambiamenti, ma questo lo è in modo particolare.

Non si tratta di avere uno strumento nuovo da utilizzare, si tratta di cambiare l'approccio con il resto del mondo.

Significa davvero uscire dalle nostre conferenze, dai nostri tool, dalle nostre mailing list e aprirci al confronto. Il confronto è bello! Si, si, subisci spesso delle critiche, ma ne esci sempre migliore di prima.

E voi che ne pensate?

Intanto troviamoci tutti su StackOverflow:



Mar 01, 2011

Software libero, azienda aperta. Cum grano salis...

Filed Under:

L'apertura delle politiche e del modo di pensare delle aziende del free software non deve indurre ad eccessive semplificazioni, meno che meno deve far passare in secondo piano la tutela della privacy e delle informazioni riservate, né deve farci scordare che siamo un attore di mercato. L'equilibrio tra apertura e chiusura, tra coopetition e competition deve essere chiaro a tutti i livelli dell'azienda.

Lo spunto

Essere il più aperti possibile, non significa rinunciare alle proprie responsabilità verso l'azienda e verso la privacy e i diritti d'autore del Cliente.

Un recente post di Marten Mickos, già CEO di MySQL, tratta in modo completo e coinvolgente il tema della "quotidiana vibrazione sui temi dell'apertura e della chiusura". Ne consiglio caldamente la lettura.

La riflessione

Per esperienza diretta, tutti sappiamo che c'è qualcosa di trascinante, di profondamente moderno, direi quasi di rasserenante nell'idea di dichiararsi aperti, e di agire di conseguenza. Ma abbandonarsi a corpo morto a questo atteggiamento ha il suo "lato B", da tenere in debita considerazione. Svilupperò questa riflessione su tre piani, interno all'azienda, mercato in generale, e il nostro mercato di riferimento, il Settore Pubblico.

Nell'azienda: il "troppo aperti" esiste!

Il post di Marten Mickos espone con un misto di entusiasmo e lucidità il peso di una scelta di massima apertura, che in azienda vuol dire anche dare voce a tutti, a prescindere dal ruolo, e - tendenzialmente - incoraggiare un'assoluta trasparenza. Basta il normale buon senso a individuare subito le aree di possibile conflitto:

  • le informazioni ricevute dai Clienti, che rappresentano una loro conoscenza e proprietà intellettuale, non possono essere divulgate senza consenso. Il personale dell'azienda deve essere formato a riconoscere e a gestire questa area grigia;
  • i dati personali, sensibili e in generale quanto attiene alla privacy non può essere esposto in modo indiscriminato;
  • processi decisionali totalmente governati dalla base (estrema conseguenza di un'apertura all'ascolto) possono comportare decisioni inaccettabilmente lente.

Questi aspetti debbono essere governati con metodi e direttive interne all'azienda: in ogni caso il personale deve essere sensibilizzato su questi aspetti. Il "capitale sociale" (l'insieme di relazioni interne patrimonio dell'azienda) va gestito metodicamente per essere valorizzato, non lasciato a sé stesso. Limitativamente, i binari potrebbero essere descritti come "la gabbia che vincola il percorso del treno", ma al tempo stesso sono il suo vantaggio, la precondizione per il suo successo. Così i metodi in azienda: non celle e recinti, ma canali privilegiati per l'efficienza.

Il mercato: cooperare, "coopetere", competere

Un rilascio pubblico affrettato o indiscriminato può anche mettere in ginocchio un'azienda

Ci sono motivi molto facili da capire per cui un'azienda possa legittimamente dilazionare o addirittura evitare il rilascio pubblico di componenti custom. Un oltranzismo della "openness" può sfociare in stupido autolesionismo per un'azienda che - alla fine - è un attore di mercato. Il "pubblico" contiene anche tutti i competitors e, fortunatamente per tutti, la proprietà privata esiste ancora, a dispetto dei vecchi slogan.

L'azienda è la famiglia, la community sono gli amici, il "pubblico" è la società intera. Esistono doveri su tutti e tre questi livelli, non solo sull'ultimo.

Nella nostra esperienza, con una tecnologia come Plone, in costante crescita ma non ancora mainstream, vediamo le altre aziende che la propongono come compagni di avventura. Con alcuni di essi cooperiamo strettamente (stringendo ATI, reti di imprese o condividendo iniziative di marketing, ad esempio nel ContènTOUR), con altri siamo in "coopetition" (condividiamo i valori di fondo,  la community Plone, le sue iniziative), con altri ancora siamo in competizione aperta, come ogni buon attore di mercato - e in questo non c'è nulla di male. 

Logo Plone

Probabilmente, di pari passo con l'affermarsi di Plone, questo scenario sfumato andrà a radicalizzarsi, con il grigio della "coopetition" che si ridurrà mano a mano che Plone saturerà il mercato (con meno possibili clienti a disposizione, la lotta e l'alleanza diverranno le sole alternative): nulla di apocalittico in questa situazione, che vivono tutte le aziende non-open. Se mai ci si arriverà, l'alternativa "con me o contro di me" non impatterà assolutamente sull'apertura intrinseca del software, che resterà libero come prima. Nessuno rischia niente, a cambiare saranno le strategie, non la filosofia di fondo.

"Il tuo software è di tutti." - "Un momento!"

Il sistematico rilascio al pubblico dominio del software sviluppato va equilibrato con le esigenze del Cliente, e ciò è particolarmente vero nel Settore Pubblico, nel quale esperienze come PloneGov Italia pongono ogni giorno i propri membri di fronte alla necessità di formalizzare a un qualche livello il riuso. 

Logo PloneGov Italia

Se anche realizziamo una soluzione, la competenza che c'è dietro (rappresentata da processi, logiche organizzative, politiche del back-office) e la relativa proprietà intellettuale sono dell'Ente che ha investito denaro pubblico nella realizzazione: i motivi che inducono i responsabili IT e le loro pubbliche amministrazioni a porsi il problema di governare il riuso, non sono certo dovuti a meschinità o ambizione personale, ma piuttosto all'esigenza di gestire responsabilmente un patrimonio dell'Ente.

Istituti quali le convenzioni tra Enti, i protocolli di intesa, la implementazione di clausole aggiuntive nei modelli di licenza di riferimento (EUPL, GPL e simili) non limitano il riuso: lo rendono possibile. 

Una certa competenza sul tema, e attenzioni quali la disponibilità di un testo di delibera di adesione a PloneGov Italia o di schemi di convenzione, vanno incontro a questo tipo di esigenza: è importante che i decisori politici si riconoscano nell'esperienza del riuso. Se da queste persone esigiamo un assunzione di responsabilità quando sbagliano, allora dobbiamo anche aiutarli ad assumersi la responsabilità del loro ben fare, capendo le loro esigenze e accontentandoci di un 98% di apertura anzichè di un 100%.


L'apertura è una scelta: se non è una scelta, perde valore. L'apertura non è un riflesso pavloviano, un atteggiamento compulsivo, uno slogan per fare bella figura. L'apertura è una strategia, e come tale va gestita e governata, senza faciloneria, senza moralismo, se no si rischia di cadere in contraddizioni in termini: "aperto per forza" è un po' come "sii spontaneo!" e molto vicino al "vietato vietare".