L'attività di stima è sempre un argomento complesso da trattare e non di rado capita che stime errate siano fonte di conflitto tra Project Manager e Developers. Ciò avviene, il più delle volte, perché il tempo necessario espresso con valori precisi è noto solo a lavoro finito. Accade quindi di frequente che quest'ultimo non coincida con quello stimato.

Recentemente ci è stato chiesto di stimare la migrazione di contenuti da Plone3 a Plone4, nel caso specifico in cui l'operazione sia ulteriormente condizionata dall'utilizzo di prodotti diversi per la gestione del FileSystemStorage (FSS) nelle due installazioni Plone.

Una valutazione iniziale spannometrica si sarebbe potuta ottenere velocemente consultando l'esperto del gruppo, ma questo approccio ha il grosso problema di affidarsi completamente all'esperienza e alla competenza del singolo, il quale senza test concreti, non ha la possibilità di essere preciso.
Interessante risulta essere quindi l'idea di fare uno studio. Questo offre la possibilità di produrre una stima più accurata, oltre ad avere il vantaggio di poter essere delegato a collaboratori meno esperti.

Ottimo! Allora avanti :-)

Lo studio

La procedura si basa sull’osservazione dell’andamento del grafico ottenuto analizzando i valori risultanti da processi di migrazione successivi di siti con dimensioni FSS diverse, e la conseguente estrapolazione e stima.

Come prima cosa è necessario dare qualche indicazione sull'applicazione utilizzata come caso di studio. Le caratteristiche sono brevemente riassunte come segue.

Oggi come oggi uno sviluppatore di siti web deve tenere conto del fatto che il risultato del proprio lavoro, nella stragrande maggioranza dei casi, verrà fruito usando dispositivi dalle caratteristiche più svariate.

Capita sempre più spesso che le richieste del cliente convergano nel richiedere un sito con un design responsivo, fruibile tanto sul touchscreen di un telefonino quanto sul ben più ampio schermo di una postazione desktop, veloce e performante sia su rete mobile che su rete fissa.

Sfruttare al massimo le potenzialità offerte da JavaScript è ormai diventato un imperativo categorico per soddisfare queste richieste, tanto è vero che oramai si parla di applicazioni JavaScript.

Per raggiungere l'obiettivo è necessario scrivere codice ottimizzato e a prova di browser. Chi lavora nell'ambiente non può non accorgersi dell'enorme progresso a cui si è assistito negli ultimi anni e del fermento tutt'ora in atto.

Ovviamente Plone, che da sempre è "sul pezzo", sta seguendo questa strada, aumentando sempre più le funzionalità che si appoggiano su questo linguaggio.

I liked the enthusiasm of Denys Mishunov. He gave us many suggestions, tips and tricks that we needed to improve our daily work. This is the most important thing to me.Thanks to Jarn guys, I discovered the importance of enjoying my work. These tools can really make us work more quickly and easily, and make it more fun.

I liked so much Yiorgis Gozadinos approach: he is always looking for the cleanest and simplest way to solve problems. For example, we talked about the importance to follow Design Patterns, reusable solutions that can be applied to commonly occurring problems. This patterns lead you to result, with a lower effort and no waste of time.

Passion and enthusiasm shown by my teachers made me once more realize that the best way to reach professional growth is loving what you do.

Among the many other topics we discussed during training, we spoke about tests, that allow you to increase your work quality.

Besides learning useful and interesting tools, we also made a comparison between our and their way of working. In some cases, we found most effective approaches.

Thank you, Jarn guys, not only for what you taught us on a technical level, but also for the emotional charge you gave me!

Here @RedTurtle we are heavily using funkload for acceptance and benchmarking tests. We have started using it in 2008 just after Bristol Performance Sprint. We have found even more useful with buildout recipe. The only missing part was the recorder. It's built-in Funkload itself, but it was not enabled in the recipe. Well - now it is ;-)

/ If you want to know how to include funkload in buildout project - check my previous blog /

Starting a recorder is quite easy:

$ ./bin/funkload record -p 8080 MyTest

for full usage call:

$ ./bin/funkload record --help

This will start proxy on 8080 port and save all your browser requests to MyTest funkload scenario. Now open your browser, change proxy configuration to localhost:8080 and click-through test case. When you finish - stop the proxy with Ctrl-C. Funkload will generate a test_MyTest.py file and notify you where you can find it. It should be now collective.funkload compatible - you can lunch:

$ ./bin/funkload test /path/to/test_MyTest.py

To test it.

Another small improvement is a PloneFLTestCase. It extends default funkload test case, implementing two additional methods helping with Plone content creation. Right now instead of using this approach:

folder_portal_factory = self._browse(server_url + "/coreloadtests/Members/" + self.user_id +"/createObject?type_name=Folder",
                                             method='get', 
                                             follow_redirect=False,
                                             description = 'Get folder portal factory')

folder_edit_url = folder_portal_factory.headers.get('Location')        
folder_id = folder_edit_url.split('/')[-2]

folder_created = self.post(folder_edit_url, params=[
    ['id', folder_id],
    ['title', 'folder'],
    ['description', ''],
    ['description_text_format', 'text/plain'],
    ['subject_existing_keywords:default:list', ''],
    ['last_referer', 'http://localhost:8080/coreloadtests/Members/' + self.user_id + '/view'],
    ['form_submit', 'Save']],
    description="Post /coreloadtests/Members/user...280843853/atct_edit")

new_folder_id = folder_created.url.split('/')[-2]

you can just do:

new_folder_id = self.addContent(
        server_url, 
        portal_type='Folder', 
        params=[['id', 'id'],
                ['title', 'testing title'],
                ['description', 'testing description'],
                ['description_text_format', 'text/plain'],
                ['form.submitted', '1'],
                ['last_referer', ''],
                ['form_submit', 'Save']], 
        description='Create folder')

It doesn't do much, but for sure it helps you keep you test case readable.

The new release of PloneboardNotify doesn't give us many new features but is not this the real focus of this article.

This add-on was already available and used in production environment, and one of the first effort was to keep Plone 2.5 compatibility.
The same is for the new 0.4 release (and maybe Plone 2.5 compatibility will continue until all of our customer will drop this version).

So? What is the problem?

Thanks for testing

Sometimes when you develop something that is useful for a single site, it became magically useful for other... but sometimes you are too stupid (and lazy) to understand it.
Let's go back to Ploneboard: after all the notification e-mail after a new forum discussion/response is a wanted feature (worst... an expected feature), not available in Ploneboard (that, even if it isn't perfect, is the only mature choice available right now on Plone to have a forum).

PloneboardNotify is a good example of a bad way to start a product... developed fast but with no eye on good OOP, without thinking about make it extensible... not tested at all. It was only a stupid event script that send e-mail (luckily this old version isn't available or any public SVN so the Story will not judge me).

First public released versions were only more "user friendly", making it usable in any context where you have Plone and Ploneboard. Maybe they are good release but was clean the need of refactoring: but refactoring is someway a dangerous task (the code is working... why I must spend my time making it better only to get the same features and be forced to test all feature and behaviour from scratch? I'm sure to remember what I need to test?)!

The problem there was (and is also now) the "core" (please... don't look at it!). Tests at every release were done by me (and my name is not Funkload) manually playing with the browser, repeating the same operation on Plone 2.5 and 3. Time after time the core grow as new feature is added... Tests are every time more expensive and boring...

What is changed now? Nothing! PloneboardNotify is still a mess... but now it's a tested mess!

Future

The primary effort of this release was adding a complete functional tests coverage of all features (for both Plone 2.5 and 3 versions). After that, thanks to the help of Nicolas Laurance, I also added the HTML e-mail feature.

Now I have no fear to make changes to the code core... also in this release I removed some stupid piece of code (after completing tests!) and introduce adapters. Having tests available now will speed up dramatically the develop process of new features.

Next steps will be to reach a better OOP and making the product more customizable by other developer in their sites (like customize the e-mail template in some simple way).

Lessons learned

• Don't be lazy. You can make this code more reusable. Always.
  
• Don't be lazy. Write tests! Better: you will became lazy if you don't write tests because testing manually is very boring and you'll begin skipping some action!
  
• Don't be stupid. You can't make deep refactoring and expect that all will work after you've finished, so...
  make tests!