Acab de rebre tres llibres que vaig comanar fa poc menys de dues setmanes a ca'n Amazon. Pareix que la rapidesa en l'enviament no ha estat casualitat, sinó que comença a ser una constant.

Això de que el dolar estigui tan baix està acabant amb la meva economia, veus un llibre interessant, mires el preu a Amazon i al canvi surt molt bé, però clar, per un no s'ho paga fer una comanda, així que hi poses també aquell altra que veres l'altra dia i ja que hi som ....

Al 2007 em queden 5 dies de feina i això vol dir que tendré temps per anar-los llegint. La quantitat la dic per a que tots aquells que llegiu això sigueu conscients que n'és de dur ser un lector compulsiu: vosaltres estareu fent feina mentre jo m'hauré d'estar a casa, calentet, al sofà llegint els llibres que he rebut els darrers mesos. ;)

I els llibres són:

Scalable Internet Architectures Ed. Omnti (Sams Publishing) Theo Scholssnagle ISBN 0-672-32699-X

RESTful web services O'Reilly Leonard Richardson & Sam Ruby ISBN 0-596-52926-0

Javascript (The Definitive Guide 5th Edition) O'Reilly David Flanagan ISBN 0-596-10199-6

He fet una ullada ràpida als tres llibres i pareix que el que prometien a les ressenyes ho compleixen:

Scalable Internet Architectures fa un recull de millors pràctiques per fer aplicacions web escalables. Explica els principals conceptes i hi ha molts de gràfics que ajuden a assimilar-los. Alguna vegada he dit que el personal de sistemes ha de saber programar, m'estic aplicant la dita a la inversa: la gent que ens dedicam principalment al món de la programació d'aplicacions convé que estigui al dia del que se pot fer quan s'ajunten arquitectures de software, xarxa i hardware.

RESTful web services ens presenta una nova manera d'entendre els serveis web, de fet presenta una nova manera d'entendre la web sencera, en lloc de com a un conjunt d'aplicacions separades la tracta com a un conjunt de serveis. Darrerament se n'està parlant molt de serveis REST i aquest llibre potser la referència, el llibre de capçalera per tenir una visió global de tot el que es mou al voltant dels serveis web i quin paper juga l'arquitectura REST.

Javascript és tant un manual de javascript pels qui ja saben programar, com una referència del llenguatge. Havia tingut en les mans una edició anterior i em va fer molt bona impressió. Pareix que no li falta res, gairebé 1000 pàgines de lletra ben atapida donen per molt. No ho recoman com a tutorial de Javascript sinó com a llibre de referència i explicació dels conceptes i aplicacions més dures del Javascript.

Com sempre, això són les primeres impressions, així com les vagi llegint miraré de posar-ne ressenyes més extenses.

Tret del llibre Software requirements,

L'analista és la persona que ajuda als qui han demanat el projecte [1] a trobar la diferència entre el que ells diuen que volen i el que realment necessiten.

[1] stakeholders a l'original

M'ha feta gràcia la definició perquè és quelcom que sovint és perd al rol d'analista. L'analista ha de poder dir la seva en el projecte, proposar solucions, millores i expressar sense por el perquè troba que el que s'està demanant no funcionarà, o no és necessari.

Encara que se pugui dir que el client sempre té raó, si duim aquesta frase a les seves darreres conseqüències en el desenvolupament de programari, estarem pervertint la feina de l'analista.

És potser el mateix que quan un demana un disseny web i li diu al dissenyador des de com vol el format, les fotos, els colors i la tipografia. Llavors per a què vols un dissenyador web?

Pel que es veu aquest tipus de situacions no és sols pròpia d'analistes o dissenyadors web. Parlant amb un arquitecte em deia que té clients que ja li venen amb els plànols fets i que no atenen a raons, són els que solen acabar amb el bany aferrat a la cuina. També vaig viure una situació semblant amb un interiorista, el client li deia com ho volia tot, col·locació, llums, decoració, fins que l'home l'hi va tenir que dir que aquells temes eren precisament la seva feina.

Potser ens ho tendríem que plantejar de tant en tant allò de dir: "escolta, això és la meva feina, si la vols fer tu endavant però després també t'has de responsabilitzar dels resultats".

Suposem que tenim una base de dades de factures i algú ens demana a veure si li podem dir quina és la facturació total de cada any i la seva distribució en els diferents mesos. Això és el que s'anomena fer un crosstab report, és a dir, fer la transformació de dades que estan en files a columnes i normalment fer una operació damunt alguna quantitat numèrica d'interès.

Al blog d'Stephen Forte he vist un mètode que ens permet fer precisament això d'una manera elegant anomenat el mètode Rozenshtein. Stephen diu que n'està enamorat d'aquest mètode i és ben comprensible, el mètode és elegant i resol d'una manera senzilla el tema dels crosstabs reports a bases de dades sql. L'Stephen ho explica molt bé, però us resumiré la idea, es tracta de trobar una expressió numèrica que s'avalui com a zero o un que ens farà de discriminador de la columna, de manera que multiplicada per la quantitat que volem operar fa que aquesta es compti (quan l'expressió val un) o que no.

Per no repetir l'exemple de Stephen en posaré un de més senzill, suposem que tenim una taula on hem anat guardant els e-mails que hem rebut on tenim la data en que l'hem rebut. Volem saber quants e-mails hem rebut cada mes. A la taula mantenim un camp anomenat created_at que conté la data en que hem rebut l'e-mail. Podríem fer

select extract (year from created_at) as any,
count(id) as total,
sum(1 - abs(sign(extract(month from created_at)-1))) as "GEN",
sum(1 - abs(sign(extract(month from created_at)-2))) as "FEB",
sum(1 - abs(sign(extract(month from created_at)-3))) as "MAR",
sum(1 - abs(sign(extract(month from created_at)-4))) as "ABR",
sum(1 - abs(sign(extract(month from created_at)-5))) as "MAY",
sum(1 - abs(sign(extract(month from created_at)-6))) as "JUN",
sum(1 - abs(sign(extract(month from created_at)-7))) as "JUL",
sum(1 - abs(sign(extract(month from created_at)-8))) as "AGO",
sum(1 - abs(sign(extract(month from created_at)-9))) as "SEP",
sum(1 - abs(sign(extract(month from created_at)-10))) as "OCT",
sum(1 - abs(sign(extract(month from created_at)-11))) as "NOV",
sum(1 - abs(sign(extract(month from created_at)-12))) as "DIC"
from taula_emails group by 1

Això és un cas particular del mètode Rozenshtein, ja que com es pot veure el que feim realment és comptar registres. Sense fer les simplificacions cada més hauria quedat com

sum(1*(1 - abs(sign(extract(month from created_at)-MES)))) as "EL_MES"

El primer un correspon a la dada que volem operar de la fila, en el nostre cas és tan simple com dir que és 1 per a que la suma vagi comptant-les, però pot ser qualsevol operació que hi puguem fer. El mètode ho podem classificar d'idea feliç, però una vegada captat és prou senzill de fer anar. En aquest cas el que s'ha fet és extreure l'ordinal del mes i restar-li l'ordinal que correspon a la columna del mes que volem tractar. Aquesta operació ens donarà zero si la data de la fila que tractam és igual a la columna del mes o diferent de zero si no ho és. Per exemple,

extract(month from now()) = 11

ja que aquest post està escrit al novembre del 2007, si repassam l'sql veurem que els resultats qute tendríem per gener seria (11-1 = 10), per febrer (11-2 = 9), per octubre (11-10 = 1) per novembre (11-11 = 0 aja!) i per desembre 11-12 = -1.

Recordem que el que necessitam és un valor que sigui zero o un, i per això el que es fa és utilitzar la funció sign, que retorna -1 per valors negatius, 1 per valors positius i 0 pel zero.

Si després li aplicam el valor absolut (abs) resulta que hem aconseguit una funció que ens dona zero quan té el valor que nosaltres volem i un quan no el té, la restam d'un tenim just el contrari, és a dir, que valdrà un quan tengui el valor desitjat i zero quan no el tengui.

Aquesta funció és la que multiplicarem pel valor a operar, en el nostre cas 1 però podria ser perfectament el valor d'una altra columna. I ja ho tenim!

any   total    GEN    FEB   MAR  ABR   MAY   JUN   JUL   AGO  SEP  OCT   NOV    DEC
2007  100       10     10     19    20       5     15    8      5       2    5       1       0

L'article de Ricardo anomenat "Las matemáticas necesitan de sofware libre", m'ha recordat que tenia pendent fer un petit apunt damunt un programa que recentment ha alliberat SAGE.

SAGE a diferèncie d'altres opcions privatives permet veure l'algorisme que hi ha per davall dels càlculs i com les opcions privatives permet fer càlculs simbòlics i numèrics. A més compta amb opcions per enllaçar amb programes matemàtics privatius i lliures.

SAGE permet fer gràfiques, calcul simbòlic, calcul numèric i n-mil coses més, totes documentades al manual. I el millor de tot, el llenguatge de programació triat: Python.

A la web de SAGE també trobam una opció per poder provar el programa on-line, es poden fer proves, però va moooolt lent, tot i això es pot veure i provar la potència de la solució.

Trobar un error al teu codi és un emprenyo. Poder començar la depuració en 30 segons, trobar l'error 2 minuts, pujar-ho al subversion i actualitzar la versió de producció de manera que als 5 minuts d'haver detectat l'error estigui corregit no té preu.

Això és el gran avantatge dels llenguatges d'script, que el temps que passa des de que trobes un error a poder-ho corregir és molt curt (llevat d'excepcions amb errors difícils de trobar i depurar, clar). Curt perquè normalment posar en marxa l'entorn de desenvolupament no duu més que uns pocs segons i ja pots començar a depurar.

Si tot està ben organitzat el codi estarà a un repositori subvesion i l'entorn de producció no serà sinó un client de subversion, de manera que fer una actualització una vegada trobat un error que no afecti a la base de dades, és bàsicament

• svn ci
• ssh al servidor
• svn update

I en alguns casos recarregar l'Apache. Encara desenvolupament i sistemes siguin equips separats, davant un error crític el temps de resposta pot ser tan curt com 5 minuts.

L'experiència amb Java és que ja directament és necessiten els 5 minuts sols per posar en marxa l'entorn, 5 o 10 minuts més per depurar i si hi ha sort i sols era un error de jsp 2 mintus més actualizar i forçar la compilació del jsp per a que el proper usuari no vegi en enlentiment en la pàgina. Normalment més del doble per a corregir el mateix tipus d'error.

Si la correcció de l'error implica canviar codi que no sigui jsp o html les diferències són encara més grans i sovint pot implicar tenir que reiniciar el servidor, la qual cosa ens obligarà a tenir sempre dos servidors balancejats si no volem tenir als usuaris aturats durant 5 minuts. L'Apache es recarrega en segons, i tot i que sempre és bo tenir-ho tot duplicat i balancejat, la necessitat no es tan forta com en el cas anterior.

Personalment m'agrada molt Java i les llibreries que s'han desenvolupat en aquest llenguatge, però si el nostre negoci depèn del ràpid que puguem actualitzar la nostra aplicació web hi ha entorns i llenguatges amb més avantatges que Java o .Net.

El llenguatge x és millor!.Quantes vegades no haurem sentit aquesta frase defensant un o altre llenguatge de programació. Tots tenim les nostres preferències, condicionades per la nostra història, coneixements i manera de pensar. Podríem dir que hi ha un llenguatge de programació especial per a cada programador, aquell en que se sent més còmode tant perquè el coneix com perquè s'adapta a les seves estructures mentals.

De tant en tant, però convé tocar un poc de peus a terra i comparar llenguatges, potser el llenguatge que ens agrada més no és el més convenient per la tasca a realitzar, o no es tan ràpid com ens pensàvem.

Una manera de comparar llenguatges és la de crear tot una sèrie de programets típics i desenvolupar-los en els llenguatges que vulguem estudiar i veure quin té l'execució més ràpida o consumeix menys memòria, i això és precisament el que han fet la gent de The Computer Language Benchmarks Game, aquí trobareu un entorn on poder comparar distints llenguatges i fins i tot si trobau que falta alguna implentació o que podeu fer un programa dels que se proposen de manera més eficient poder enviar-ho.

Com que escor molt cap a la web m'he entretingut a comparar un grapat de llenguatges d'script entre ells i després comparar-los amb Java o C#.

• Python i Perl en general són molt semblats tant en velocitat d'execució com amb consum de memòria. Sols a l'execució de fasta per la generació de seqüències de DNA llueix més Python per mor d'un consum de memòria molt més petit. També és interessant comparar com en el tema de les expressions regulars Python no queda tan enfora de Perl com un podria suposar-se i que queda molt millor que el PHP per exemple.
• Python i PHP. En general Python és millor, però no hi ha una diferència prou gran com per marcar la diferència en la majoria d'aplicacions, llevat de que tinguem que fer molts de càlculs, però clar, llavors potser un llenguatge interpretat no és d'entrada el més ràpid.
• Python i Java. En velocitat de CPU Python queda molt malament llevat de casos molt particulars com el regex-dna, així que si sols coneixem Python i Java i hem de fer molts càlculs millor el segon, si hem de tractar cadenes millor Python. El mateix seria aplicable a PHP o Perl. Si el problema que tenim no és la velocitat sinó el consum de memòria, ja ens podem anar acostant més a Python i mens a Java.

La pàgina té un nom molt apropiat i t'hi pots passar hores fent comparacions, mirant com està codificat cada programa, com és d'elegant el codi i les línies que s'ha necessitat per realitzar cada algorisme.

Comparar és divertit, però no sols de velocitat i consum de cpu viu el programador. Saber en línies generals com se comporta el nostre llenguatge habitual comparat amb els altres és sempre profitós, però ens hem de situar sempre en perspectiva i situar el llenguatge en la casta de projectes que desenvolupam. Si l'aplicació no té un consum de memòria o cpu intensius aquestes característiques del llenguatge potser importaran menys que la velocitat en la que podem formar als desenvolupadors, en la mantenibilitat de codi, en el nombre de línies de codi que es necessiten per implementar un punt funció, ... i sobretot hi té molt a veure la capacitat de la gent que programa. No serveix de res tenir un llenguatge ràpid si el nostre codi és erroni o totalment ineficient.

Python te un sistema de tractament de cadenes molt potent i a la vegada molt entenidor. Una de les necessitats que tot programador té és el de muntar missatges més o manco estandaritzats en que sols varien uns pocs paràmetres.

Per exemple, suposem que tenim una llista de noms i edats, per seguir amb els exemples típic suposarem

agenda = [('Benjamí', 31), ('Pau', 22), ('Juan',34), ('Ricardo',38),('Guillem',28), ('Bernat',58)]

i volem construir amb cada un d'ells una frase del tipus: Benvolgut [nom] ara que ja tens [edat] anys ...

Una primera opció és la de fer servir l'operació de formateig de cadenes a Python amb la qual cosa podríem escriure un codi semblant a

for persona in agenda: ···print "Benvolgut %s ara que ja tens %i anys" % persona

que ens donaria com a resultat

Benvolgut Benjamí ara que ja tens 31 anys
Benvolgut Pau ara que ja tens 22 anys
Benvolgut Juan ara que ja tens 34 anys
Benvolgut Ricardo ara que ja tens 38 anys
Benvolgut Guillem ara que ja tens 28 anys
Benvolgut Bernat ara que ja tens 58 anys

Les opcions de formateig de cadenes esperen una llista i substituexien cada paràmetre que tenim a la cadena per l'element de la llista corresponent. Això és suficient per la majoria de casos en que ens trobarem, però la cosa és que no queda massa documentat què és cada paràmetre, i per això Python ens deixa posar nom als paràmetres de la cadena i passar enlloc d'una llista un diccionari, ara es substituirà cada paràmetre pel valor de la clau agafada del diccionari. L'exemple està agafat un tant pels pèls però seria:

for persona in agenda: ···print "Benvolgut %(nom)% ara que ja tens %(edat)i anys" % {'nom':persona[0],'edat':persona[1]} En la mateixa línia Python té a més una classe dins el paquet string anomenada Template que ens permet crear plantilles com a tals i fer-ne la substitució de paràmetres bé per nom o mitjançant un diccionari. En aquest cas l'esforç adicional de teclejar es veu compensat per un codi autodocumentat, per exemple

from string import Template plantilla = Template("Benvolgut ${nom} ara que ja tens ${edat} anys") for persona in agenda: ···print plantilla.substitute(nom=persona[0], edat = persona[1])

La potència de Template es veu quan hi ha molts de paràmetres, ja que es molt més senzill saber quan ens hem deixat un paràmetre, normalment per un nom mal posat i a més proporciona la funció safe_substitute, que genera la plantilla fins allà on pot i es molt útil a l'hora de depurar una plantilla amb una gran quantitat de paràmetres.

Si encara volem més, hi ha una gran quantitat de llenguatges de plantilles de tercers que podem utilitzar des de Python, en deix alguns enllaços:

• cheetah
• mygty
• cherry
• kid
• mako
• django
• simpleTAL
• genshi

L'elecció d'una alternativa u altre dependrà del que necessitem, i en el cas de les plantilles de tercers del si elegim un bastiment web o un altre, de si volem separar molt el codi de la capa de presentació o de si ens sentim més o menys còmodes amb la sintaxi d'XML per les plantilles.

Rhino és una aplicació open-source del projecte Mozilla que implementa un intèrpret de Javascript en una màquina virtual Java. Encara que la idea inicial del projecte és poder utilitzar el Javascript com a llenguatge d'script en aplicacions Java, Rhino és una eina valuosa en l'aprenentatge del Javascript i a l'hora de provar el codi Javascript realitzat sense tenir que anar al navegador. Rhino disposa d'una consola que ens permet introduir-hi el codi Javascript i veure'n l'execució o  executar un arxiur javascript que creem: aaloy@G5:~/workspace/apsl$ rhino Rhino 1.6 release 5 2006 11 18 js> Encara que amb utilitats com Firebug la programació de Javascript s'ha simplificat molt gràcies al seu excel·lent depurador, l'execució del codi de manera independent del navegador ens pot ajudar a provar coses i idees, això sí, amb el cost d'executar una aplicació Java.

Al curset que férem de formació d'equips (anyor el Tai-Chi) hi havia un exercici per determinar la nostra intuició a l'hora d'esbrinar esdeveniments, en aquest cas l'exercici consistia en estar amb els ulls tancats i intentar anticipar-se a un company que ens tocaria a una part del cos que ell volgués (eps! sense abusar). La cosa no va sortir malament, però he de dir que a la vida real, saber cap a on aniran els tir sols ser sovint més senzill, entre altres coses perquè no tenim ells ull tancats i podem raonar un poc. Suposem per exemple un cas hipotètic: un stakeholder  amb poder damunt el pressupost vol externalitzar una aplicació web i demana pressupost a tres empreses:

• L'empresa A és una empresa.
• L'empresa B és també una coneguda empresa local amb la qual ja s'hi ha fet feina.
• L'empresa C és una empresa consultora d'àmbit nacional i internacional amb la qual ja s'hi ha fet feina.

A les tres empreses se'ls fa arribar la mateixa definició o indefinició d'aplicació i es queda a l'espera del pressupost. A un moment donat se sap que l'stakeholder ha decidit quina empresa farà la feina. Quina empresa té més punts per resultar l'agraciada? Com es pot saber? Quina hauríeu triat vosaltres? Els qui no ho hagin endevinat la resposta és l'A. Perquè, perquè és la que canta. A no està al mateix nivell que les altres dues i quan passa això o bé s'ha fet per completar ofertes o perquè ja es té previst que sigui la guanyadora i les altres dues sols estan de convidats de pedra. Saber si és una opció o l'altra ja depén un poc més de l'entorn, però l'habitual és que l'empresa que menys encaixa sigui la guanyadora, després de tot, es podria haver demanat la proposta a una altra empresa del mateix nivell. Un altre cas potser el contrari, és a dir de les tres propostes tenim:

• Empresa A: desconeguda.
• Empresa B: amb referències i contínues visites dels comercials.
• Empresa C: empresa amb referències però coneguda per ser molt cara.

Com a pista direm que el projecte és gran, ja que si és petit, la cosa es distorsiona. I la resposta és? La B. La primera  no té referències i presenti la proposta que presenti és massa arriscada, a la tercera se li va demanar pressupost, però ja es sabia que seria molt cara, per tant sols ens queda la segona opció. Una vegada més ens trobam amb situacions en que encara que es demanin tres ofertes ja és pot saber amb molta antelació quina serà la proposta que sortirà elegida. Sempre hi pot haver sorpreses, però en el joc de l'anticipació qui comanda són les probabilitats.

En Marcos m'ha fet arribar un interessant article anomenat Technical Debt, d'Steve McConnell un dels meus autors preferits. En ell McConnell ens parla del concepte del deute tècnic, és a dir, l'equivalent a l'import en hores de feina que haurem de pagar en el futur quan en el desenvolupament d'una aplicació prenem determinades decisions.

Per exemple, quan no posam comentaris al codi estam adquirint un deute tècnic, ja que més endavant la persona que ho tengui que depurar o fer-ne modificacions ho tindrà molt més mal de fer i hi haurà de dedicar més hores de feina. També contreim aquest tipus de deute quan per exemple decidim fer la nostra aplicació depenent d'una determinada base de dades, donant per suposant que no necessitarem portar-la mai a una altra. En aquest cas el deute pot fer-se palès quan tenguem la necessitat de canviar de base de dades o bé pot no aflorar mai si l'aplicació acaba el seu cicle de vida sense necessitat de canviar de base de dades.

Es distingeixen dos tipus de deutes tècnics, aquell en el qual hem caigut de manera no intencionada i aquell totalment intencionat i que respon a una decisió estratègica. Els no intencionats s'han d'evitar sempre, ja que no hi tenim cap control, dels intencionats n'hem de ser conscients i avaluar-ne la relació entre el risc que assumim i el possible cost d'aquest risc vers els beneficis que en podem obtenir.

Tal i com passa amb els deutes financers, aquests tipus de càrregues poden ser fruits d'una planificació a llarg plaç o bé per necessitats puntuals del moment. Tal com passa amb el deute financer que en tenim a curt i llarg plaç (la visa i l'hipoteca) podem tenir un deute tècnic a llarg plaç, com per exemple fer una aplicació depenent d'una versió concreta d'un sistema operatiu si sabem que no el canviarem en diguem tres anys, o bé a curt plaç, com algunes decisions que s'han de prendre per tal de sortir al mercat abans que la competència i que s'hauran de resoldre una vegada el programa estigui en producció.

En els dos exemples, es veu que el deute existeix: als tres anys les dependències s'introduïren del sistema operatiu s'hauran de eliminar, els errors les característiques no documentades de la versió inicial del programa s'hauran d'arreglar.

A més de saber que existeix el concepte de deute tècnic ens permet atracar-nos més cap el llenguatge que parla la gent que comana normalment els programes. Ajuda a ser conscient del cost de determinades decisions tècniques i a poder fer un símil entre el cost financer i el cost tècnic, de manera que es pugui fer palès un possible cost ocult, que després haurà d'assumir-se o no, en funció dels beneficis que hi pugui haver.

A un post anterior parlava d'sqliteman, un gestor per sqlite, bo però que requereix de compilació. Dins el mateix nivell de sofisticació (és a dir, més aviat poca) tenim un altre programa que es presenta com a una extensió de Firefox, es tracta de sqlitemanager. L'extensió s'executa com si fos una aplicació més, fent servir l'envolcall que proporciona el navegador. Podem obrir una base de dades, veure'n l'estructura i els continguts, crear indexs, fer consultes sql, afegir registres i fer cerques. Com sqliteman la utilitat del programa resideix en poder veure totes les taules que conformen la base de dades i del tenir una interfície còmoda de feina. En aquest cas a més, l'aprofitar que s'instal·la com a una extensió del Firefox, fa que sigui totalment trivial posar-lo en funcionament. Està per la versió 0.2 i busques, i encara li queden molts aspectes a millorar, però per fer les tasques habituals és perfectament funcional. No deixa de ser sorprenent com sqlite s'està imposant com a base de dades d'escriptori davant opcions més complexes com la que podria representar Derby o  Hsqldb per exemple. Supòs que la simplicitat d'instal·lació (gens), la capacitat de poder-la fer anar amb pràcticament qualsevol llenguatge de programació i la seva velocitat han fent que sigui l'opció elegida pels qui volen una base de dades pensada per aplicacions d'escriptori o per desenvolupament. Fa temps vaig escriure un petit article a Bulma damunt sqlite, allà pel 2002 i la base de dades ja era impressionant en velocitat, portabilitat i llenguatges que la podien fer servir. En les darreres versions la cosa no ha fet sinó millorar.

AppFuseDjango és una aplicació d'aquestes que t'ajuden a començar, sense pretensions, sense fer res de profit més que mostrar d'una manera senzilla com fer les coses. En aquest cas, l'objectiu és tenir una mini-aplicació que mostri com començar a fer coses amb Django, amb el servidor de desenvolupament ja configurat per servir continguts estàtics (cosa que nos s'ha de fer després en producció), preparat per la traducció del lloc, paginació de llistats, etc.

La idea és anar afegint funcionalitats però sempre de manera que tot quedi el més entenedor possible, és adir, si s'han d'escriure tres línies de codi en lloc d'una per a que la cosa es pugui seguir es farà. De la mateixa manera si és necessari que l'aplicació tengui més d'un mòdul (ara sols té una agenda xorra) també es posarà.

L'he creat com un projecte de Google Code, i he de dir que estic gratament sorprés del bé que funciona el repositori subversion.

El wiki no m'agrada massa, m'estím més l'estil de Trac, però el subversion funciona molt bé i es pot configurar per a que t'envii un missatge cada cop que es fa una integració, així que en conjunt estic satisfet.

Esper que pugui servir a algú, si més no, a mi em serveix com a punt de partida dels meus propis projectes.