Personal tools

June

Jun 29, 2011

Europython 2011: aftermath

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.

cciaa.modulistica: da PloneGov Italia al mondo

Filed Under:

Vale la pena di rinnovare gli investimenti su un prodotto di pubblico dominio? Ecco perché noi di RedTurtle e i nostri Clienti pensiamo di si.

Il prodotto

 

Le classifiche possono piacere o meno, ma non si discute: esistono prodotti più utili di altri

Utilità: etimologicamente, attitudine ad essere usato. Come dimostra l'esempio di redturtle.smartlink (che si avvicina ai 7000 download), l'utilità di un oggetto è tanto maggiore, quanto più diffuso è il bisogno che esso soddisfa, ma non solo: perché l'oggetto sia davvero utile, quindi usato spesso e volentieri, deve essere innanzitutto facile da usare. Da tutti questi punti di vista, il prodotto cciaa.modulistica, di cui è stata appena rilasciata al pubblico la versione 2.0.0, è certamente tra le cose più utili che RedTurtle, assieme ai suoi Clienti, abbia sviluppato fino ad oggi. 

cciaa.modulistica base

Una lunga storia

La versione 1 di cciaa.modulistica, sviluppata originariamente per Plone 2.1, ha poi rincorso Plone nelle versioni 2.5 e poi 3.3. In questa sua lunga prima fase di vita il prodotto (cogestito anche dal Comune di Modena che ne aveva reso disponibile una prima versione italiana, nell'ambito di PloneGov Italia) non  era disponibile in versione scaricabile ed installabile. La versione 2, che si è giovata della fusione con il progetto cciaa.c3p.folder nato in ambito Plone 3, nasce per Plone 4.1 ed è la prima ad essere rilasciata al pubblico su Pypi e su Plone.org, previa traduzione completa in inglese.

A cosa serve

cciaa.modulistica dota le normali cartelle Plone di una serie di attributi aggiuntivi: una vista tabellare, in formato descrizione / collegamento al file scaricabile, sui contenuti di una cartella Plone, e un campo tramite il quale si può liberamente impostare l'intestazione delle colonne della tabella. La vista è automaticamente limitata agli oggetti di tipo file, ed ai collegamenti,  contenuti nel folder. Il campo che, per ogni file caricato in Plone, memorizza gli elementi ad esso correlati, viene utilizzato per rilevare l'esistenza di versioni dello stesso file in altri formati, il che provoca l'automatica comparsa di ulteriori colonne nella vista tabellare.

Numerosi esempi pratici sono disponibili nella sezione "Modulistica" del portale della Camera di Commercio di Ferrara.
La sezione "corpo" di eventuali contenuti di tipo "pagina" presenti nella cartella, è intercalata a tutta larghezza nella vista tabellare sopra descritta, consentendo di fornire preziose indicazioni sulla modulistica ed il suo utilizzo. L'ordine delle pagine nella cartella determina la loro collocazione all'interno della vista, consentendo di posizionare il relativo testo nel modo più idoneo.

cciaa.modulistica albi ruoli

Un curriculum esemplare

L'Ente che ha lanciato PloneGov in Italia non ha tradito il suo stile di innovatore e propugnatore della collaborazione, rivendicando orgogliosamente il suo posto nei "credits" del prodotto.

Questa storia non si è solo snodata in un lungo arco di tempo, ma ha coinvolto in modo decisivo almeno due dei nostri Clienti storici, il Comune di Modena ma soprattutto la Camera di Commercio di Ferrara, la cui fedeltà a Plone ed alla sua evoluzione nel tempo è stato il motivo fondamentale del suo costante aggiornamento ai successivi rilasci del CMS libero. L'unico motivo dell'attesa del rilascio pubblico è che si è preferito attendere lo sviluppo di una versione per Plone 4.

Tanto arrosto, poco fumo

Nulla di strano, insomma: niente fuochi d'artificio e una grande concretezza. Spesso, è proprio questo a servire: cciaa.modulistica è stato scaricato una quarantina di volte nei primi tre giorni dal lancio, e a questo ritmo in pochi mesi potrà diventare uno dei maggiori successi tra la cinquantina di prodotti rilasciati fino ad oggi da RedTurtle.

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:

PASTER TEMPLATE

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”):

...
config.include(myapp.fainit)
...

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. 

FANSTATIC

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:

CUSTOMISABLE ACTIONS

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)

 

I18N

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

[app:pyramid]
...
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:

config.formalchemy_model_view('admin',
                              model='pyramidapp.models.Foo',
                              context='pyramid_formalchemy.resources.ModelListing',
                              renderer='templates/foolisting.pt',
                              attr='listing',
                              request_method='GET',
                              permission='view')

and per Model:

config.formalchemy_model_view('admin',
                              model='pyramidapp.models.Foo',
                              context='pyramid_formalchemy.resources.Model',
                              name='',
                              renderer='templates/fooshow.pt',
                              attr='show',
                              request_method='GET',
                              permission='view')

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

Widgets

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
User.group.set(renderer=pyramid_autocomplete(filter_by='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 pyramid_formalchemy.events.subscriber 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

 

Summary

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.

CrudSprint2011

You can find more sprint photos here - http://www.flickr.com/photos/tags/crudsprint2011