Aquest és un apunt d'utilitat pública, és a dir, potser és una xorrada per la majoria, però per si algú s'ha trobat en la meva mateixa situació crec convenient explicar-ho.

La cosa és que amb KUbuntu el Firefox no es porta massa bé. Quan un selecciona un radio button o un checkbox l'estil de la selecció fa que no sàpigues si realment has fet clic o no fins que no has pitjat a un altre lloc de la plana. Bastant molest tot plegat...

No hi havia manera de saber si era un bug o què, ja que cercava per Firefox Styles o chekbox i clar sortien milers de planes de disseny i javascript. Afortunadament per mi vaig arribar a la plana de larns que es veu tenia el meu mateix problema.

La solució passa per anar al panell de control de kde (Arranjament del sistema) i anar a l'opció d'Aparença. Seleccionam GTK Styles and fonts i en l'opció GTK Styles seleccionar Use another style seleccionant-ne un que no sigui el Qt, en el meu cas Raleigh, o bé es pot instal·lar el QtCurve:

     sudo apt-get install kde-style-qtcurve  qtcurve
     

Amb això els problemes de visualització de Firefox 3 desapareixen.

Pens que tothom tenim un llenguatge de programació que ens és afí, com al Harry Potter amb les varetes, podríem dir que no és el programador qui elegeix el llenguatge de programació, sinó que hi ha un llenguatge que encaixa perfectament amb la manera de pensar del programador.

En la metodologia de gestió de projectes crec que passa un poc el mateix. Quan hom pensa que el més important en els projectes són les persones i s'ho creu, les metodologies clàssiques no encaixen, ja que tenen tendència a pensar que els programadors són intercanviables, com un peó de la cadena de producció.

Quan es posa èmfasi en que la programació la fa la gent i que el factor realment diferenciador en la productivitat i l'èxit d'un projecte no és tant l'eina de programació com la gent que hi ha implicada, arribarem prest a les metodologies àgils.

Dins aquestes n'hi ha una que a mi m'escau d'allò més bé, en que m'hi sent més identificat i aquest és l'Scrum.

L'Scrum és una metodologia senzilla, on l'equip ho és tot i el cap de projecte no diu el que s'ha de fer sinó que és un facilitador, és a dir, la persona encarregada d'eliminar els obstacles que puguin posar en perill [1] el projecte.

Scrum fuig de la idea de que s'ha de tenir tot totalment clar abans de començar i abraça la idea del canvi, del dinamisme en els projectes. M'agrada perquè va per feina, sols amb la mínima cerimònia i sempre amb l'objectiu de que el client acabi obtenint allò que necessita i que sovint no és allò que havia demanat inicialment.

[1] "Pero que parezca un accidente"

Llegit un apunt d'Okkum m'ha fet pensar en el joc que ens poden donar els CMS en el desenvolupament web i en els perills que també comporten.

De CMS n'hi ha en gairebé qualsevol llenguatge i bastiment que tengui una mínima orientació cap a la web, ja que al cap i a la fi es tracta de facilitar que l'usuari que ha de crear els continguts de la web ho tengui fàcil per fer-ho, i que les limitacions que imposa el CMS facin que tota la web tengui una estructura comú (afegiu-hi aquí la paraula corporativa).

Per PHP i Java n'hi ha per avorrir de CMS, per Python també n'hi ha un bon grapat, però si me'n tengués que quedar un per les possibilitats que té i la funcionalitat que aporta se'ns dubte em quedaria amb Plone.

De totes maneres, l'apunt no vol ser una comparativa de CMS, sinó reflexionar damunt les seves utilitats i els seus perills. Una web que és bàsicament contingut té en un CMS l'aplicació ideal. Si ho volem fer amb Django actualment hi ha dues possibilitats que destaquen:

• Django cms alliberat recentment i que és un complet sistema de publicació de continguts.

• Django page cms una aplicació per Django, és a dir pensada per a integrar-se amb un projecte web.

Cada un d'aquests projectes representa una manera d'entendre els CMS. El primer imposa que el CMS sigui l'aplicació principal i que en tot cas les funcionalitats que es vulguin afegir s'hi facin a partir del que el CMS ofereix, amb més o manco passibilitats d'integració. Pot anar molt bé si la única cosa que hem de fer és posar un formulari, però pot ser un maldecap si volem construir-hi la nostra aplicació web.

El Django page cms, per contra, suposa que serà una aplicació més a l'ecosistema del projecte, i per tant està pensant per integrar-se en qualsevol projecte. En contra té menys funcionalitat de CMS, menys cosa feta que l'anterior.

L'elecció d'un camí o un altra dependrà de l'aplicació i del client. Si hi ha o hi pot haver funcionalitat més enllà de la gestió de continguts és millor anar cap a una solució integrable que cap a una solució de CMS pura. Si els nostres usuaris no saben el que volen ni cap a on ha d'evolucionar la web doncs el sistema de component també és recomanable. Per webs de contingut que s'han de gestionar i mantenir ràpidament, el CMS pur és ideal.

I si el vostre negoci depèn del CMS, doncs no ho dubteu gaire: Plone, a anys llum de qualsevol CMS obert o tancat, i és també Python.