El nucli

En un projecte gran, amb molta gent introduint codi a un ritme alt és difícil mantenir un mínim de qualitat. Les accions que es poden dur a terme, com revisions de codi, refactoritzacions, etc, suposen enderrarir aquest progrés. Al manco a curt termini.

Quan ens trobem amb aquesta problemàtica: vegem la qualitat com a necessària però som incapaços de arribar al nivell que desitgem, hem de optar per una solució de compromís. Crec, puc estar molt equivocat, que l'opció més adient és identificar quin és el nucli crític de l'aplicació i mantenir-lo el més aïllat possible de la resta de l'aplicació.

Fins i tot, el millor seria fer que només certes persones fossin responsables d'aquesta part, però això ja pot ser més complicat. Podríem introduir el coll de botella que intentem evitar. Per això una solució més realista probablement sigui mantenir al manco l'aïllament.

I quina és aquesta part crítica?. En general aquesta part de l'aplicació correspondrà a les classes de domini i mètodes de servei més importat. No de tota l'aplicació, sinó aquelles que representen la part funcional bàsica del sistema.

No crec que aquesta intenció sigui  estranya: ho feim amb altres parts de l'aplicació. Per exemple, si algú ha de crear un Servlet, el crea i ja està. Però si algú necessita una taula nova a la base de dades, normalment feim que necessiti l'aprovació d'algú amb coneixements específics o amb millor visió global de l'aplicació. Moltes vegades inclús es cerca un consens entre un ampli grup de desenvolupadors. No és que el Servlet no sigui important, però està clar que no està al mateix nivell que un canvi a l'esquema de la base de dades.

Aïllar aquesta zona de l'aplicació que reconeixem com a crítica permet que, encara que no puguem assolir al moment el nivell de qualitat dessitjada, més endavant sigui viable afrontar tasques de millora.

Per aconseguir aquest aïllament s'han d'evitar dues coses. Que el que ha d'estar allà dins surti, i que el que no ha d'estar allà dins hi entri. Així de fàcil. Així de difícil.

Per exemple, si feim un mètode de servei

public void modificaSolicitutVacancies (Solicitut nova);

Probablement aquesta funcionalitat inclou molts de casos diferents:

• La solicitut canvi l'estat a acceptada. És una acceptació d'una solicitut de vacances
• La solicitut canvi l'estat a rebutjada. És una denegació
• La solicitut activa un atribut de cancelada. L'usuari retira la solicitut. Si ja estava acceptada s'han de restaurar els dies de vacances restants
• ...

El mètode de servei se converteix amb un simple sql update... Tota la lògica que hi ha al darrera d'aquesta acció, lògica crítica en un sistema de control de vacances, queda en el Servlet, al javascript o, fins i tot, baixa la responsabilitat de l'usuari.

L'altre problema es pot produir pel fet que, mesclat amb aquesta part crítica, s'hi introdueixin altres components que no ho són tant.

Per exemple, el sistema anterior pot tenir un servei de notificació via email o sms de l'estat de les solicituts. Aquest clarament és un mòdul de suport a l'aplicació. Pot ser molt important per l'usuari. Fins i tot imprescindible, però no està al nucli del que implementem. Ha d'estar clarament diferenciat al codi.

El camí a seguir ha de ser tenir el màxim de funcionalitat possible treta de la gestió bàsica de l'aplicació. Quan més ens esforcem en aquesta tasca més parts de l'aplicació passaran a estar implementades amb eines externes en lloc de codi nostre. Coses com eines de reports, eines de cerca de documents o d'explotació de dades (uns companys ara fan virgueries amb el Pentaho), poden augmentar molt el profit que s'extreu de la nostra aplicació.

Però això només és possible si la base damunt la que se sustenta tota aquesta parafernàlia és sòlida. Si la creació i cerca de documents PDF generats està mesclat amb el nucli de l'aplicació, dificilment trobarem una eina que s'adapti al que necessitem. Si feim un mòdul separat amb el que té de comú tota la part de generació de documents, extreim aquesta part de la gestió bàsica (no mesclar el codi del mètode que determina que una solicitut s'ha d'acceptar amb el que genera el document d'acceptació) i ens adaptem a l'estructura habitual (general) de les eines de indexació i cerca de documents, tenim molts de números de poder delegar part important a una eina externa.

Creant bits

En primer bloc he de donar l'enhorabona a en Ricardo per la seva exposició i a en Toni per la iniciativa. Va ser un capvespre molt ben emprat i entretingut.

Després de tenir un día per digerir una mica el vist, vaig a escriure el que m'ha quedat del tema.

Impresió general.

Excelent. La capacitat del client a l'hora de configurar el sistema tant de producció com a altres entorns (proves d'acceptació, desenvolupament …)  és simplement impresionant. Crec que, un cop generalitzat aquest servei, la tornada enrera es veu molt improbable.

En Ricardo va fer molt bona feina explicant a un no iniciat que és el que se troba quan se enfronta a l'oferta d'Amazon. Quines parts poden desorientar més i que s'ha de tenir en compte. La part final, amb la demostració, fou tota una exhibició de l'eficiència del sistema.

El sistema.

A l'inici de l'exposició en Ricardo va mostrar la seva admiració per la interfícia presentada per el sistema d'Amazon. Deu ser un bon exemple de com s'ha de dissenyar un sistema. Demostració palpable de la importància de construir un model coherent i oferir un conjunt d'interfícies de qualitat.

En el cas del EC2, se presentaven interfícies RESTFul, SOAP, una utilitat per línia de comandes, una interfícia gràfica i, me va semblar entendre, una API per distints llenguatges.

Un altre factor que també crec que deu haver influit en l'èxit d'aquest producte és el fet es tracta del sistema que ells mateixos empren. Tot un exemple del principi "eat your own dog food".

La tasca d'en Ricardo i creant bits.

Me va agradar molt el comentari d'en Ricardo referint-se a que, quan veia la llista final del que necessitava, la veia tan evident que li sobtava haver tingut tants de problemes per arrivar a ella. Aquesta és precisament la tasca dels "pioners" en una tecnologia. Curiosament, quan aquesta tasca està ben feta, el resultat és un "ah, sí, això és molt fàcil", i quan no se fa tant bé, s'obté un "uau, que ets de bo!, això és molt complicat!". Així que enhorabona per la simplicitat a la llista ;-)

L'arquitectura per Meneame pot servir perfectament com a plantilla per moltes aplicacions Web. De fet, no estaria gens malament que s'oferissen una sèrie de "Architecture patterns" com a punts de partida per configurar els distints projectes.

Alternatives?

La que estava en ment de tothom és l'oferida per Google. En Ricardo explica que en les seves proves observaren que la latència en els accessos al BigTable eren molt elevats. Això és un problema important en una aplicació com meneame. No sé si aquest va ser l'argument definitiu, tanmateix Ricardo va valorar el sistema de Google com a molt bo.

Google i Amazon presenten solucions diferents a problemes semblants. Aquesta diferència és principalment en el nivell d'abstracció que presenten (Disclaimer: no en tenc ni idea del tema. Parlo a partir del que vaig entendre ahir). A Amazon configures el teu sistema i cada una dels seus elements. Has de coneixer molt bé què necessites i quina és la millor forma d'obtenir-ho. Google no et presenta aquest nivell de detall. Tú poses l'aplicació i demanes la capacitat dessitjada.

Diria que en general (amb excepcions notòries), sol triunfar el sistema que és mou a un nivell d'abstracció més alt. Fent una valoració freda, apostaria fins a 1.5 euros a que les coses li van un poc millor a Google, però no més.

Programació

Som programador. D'altres coses (de informàtica i de fora de la informàtica),  en sé molt poc.  Que en vaig treure de la presentació d'ahir que afecti directament al meu vici?. La primera conclusió va ser que, al manco amb el sistema d'Amazon, el model de programació varia poc. No dic gens. Hi ha coses que s'han de considerar. Per exemple, pot ser necessari modificar el que considerem a l'hora d'optimitzar l'aplicació per incloure factors que afecten al que ens cobra el que ens lloga la plataforma (per exemple, nombre de connexions establertes).

Un altre problema interessant presentat, l'obtenció de la IP remota quan l'accés arriva per https i ha passat per un balencejador de càrrega que no ha pogut modificar les capçaleres no és inherent al fet d'estar al núvol, sinó a l'arquitectura concreta.

Ara que tot això és amb el model d'Amazon. Amb Google sí que ens canvia el funcionament d'una pessa clau en tot el sistema: l'abandonament del model de dades relacional, però això ja per un altre dia.

llibre "Managing the testing process"

Fa unes setmanes vaig comanar un parell de llibres que parlaven de les proves en el software.

Un d'ells és "Managing the testing process" de Rex Black. Encara no l'he llegit tot (té 600+) pàgines però amb el que duc llegit, més o manco la meitat, ja m'ha servit per fer-me una mica a la idea de com se pot organitzar aquesta tasca.

En primer lloc he de dir que no era el tipus de llibre que cercava. Volia un llibre a on s'expliquesin tècniques concretes de proves, no la seva gestió. Cercant per amazon durant un parell de dies, me va pareixer que l'oferta de llibres d'aquest àmbit és molt reduida. Al final hem vaig decantar per aquest llibre i "Lessons learned in software testing".

Cap del dos tracta l'àmbit que cercava, però tot i així m'estan servint per omplir un buid molt important. Al cap i a la fi, ens dediquem professionalment a posar sistemes en producció.

Intentaré apuntar les idees més importants que m'ha aportat el llibre.

1. La motivació del procés és assegurar al màxim el valor del producte
2. Per això, s'han d'identificar els riscos (situacions que poden fer perdre aquest valor) i prioritzar-los. Per exemple (simplificat): prob. d'ocurrència x efecte produït
3. Dissenyar el conjunt de proves (test cases) cercant la màxima cobertura dels riscos anteriors. Molt de pragmatisme és necessari per aquí.
4. Les proves poden variar molt en la seva especifícitat:
1. Proves automàtiques ( de caixa blanca o de caixa negre )
   
2. Proves manuals, però seguint un guió
3. Proves exploratòries
   
5. Tots els tipus de proves anteriors tenen valor. En general, anant cap a d'alt són més ràpides d'executar, anant cap abaix, tenen més capacitat de detectar errors.
6. Les proves automàtiques són molt sexys per els programadors. Com s'ha dit abans tenen valor, però hem d'evitar identificar-les amb TOT el procés de proves. 
7. Una de les principals dificultats que trobarem serà com organitzar l'execució d'aquests tests cases. Les dificultats provenen de que:
   
1. No treballarem amb una release, sino en successives releases que anirà (anirem) produïnt l'equip de desenvolupament. No podrem passar tots els test cases en cada lliurament.
2. Entre releases s'introduiran errors de regressió. Que la versió 1.0.RC3 passi el test case X no vol dir que la versió 1.0.RC4 l'hagui de superar.
   

El llibre és molt específic en la gestió del procés. Proposa una metodologia pròpia per el projecte de test i la compara amb l'estàndard IEEE 829. Moltes d'aquestes coses ara mateix no les veig amb possibilitat incorporar-les a la meva feina, però no està de més coneixer les seves idees principals.

Un consell que m'ha agradat ajuda amb un problema que tots hem patit a les nostres feines: fa referència a la forma de comunicar un bug que hem trobat. Per desgràcia, l'ego dels programadors és molt sensible. Per encara més desgràcia, en alguns casos el manteniment d'aquest ego és més important que la feina que se duu entre mans. Per això, part important de la detecció del bug és justíficar per qué és un bug. L'hem d'aïllar el màxim possible i correlacionar amb una especificació o un dels valors de l'aplicació. És frustrant sovint el que costa convèncer a un programador que un error és un error.

Per acabar, una idea no del llibre sino del blog de testing de google, per superar la paràlisi a l'hora d'iniciar la definició dels jocs de proves. A la pregunta de "Per on començo a dissenyar les proves", la resposta que donaven era: imagina que d'aquí a dues hores te diuen que posaran el sistema en producció, que seria el primer que provaries?

Una conversa estranya

Avui he tingut una conversa un tant estranya amb el servei tècnic de vodafone

Jo: Hola. El móvil no me permite realizar llamadas ni acceder a internet
Ells: (després de 5 minuts d'espera i de demanar-me fins la talla dels calçatins). El problema es que ha superado su límite de consumo, 60 euros
Jo: No sabía que tenía límite de consumo.
Ells: Sí, (40 segons d'espera). Lleva gastados 140 euros
Jo: Ah. Lo del límite no funciona muy bien no?
Ells: ....
Jo: Necesito hacer más llamadas. Pueden anular el límite?
Ells: No. Pero lo podemos pasar a 70 euros
Jo: ??? Así podré llamar?
Ells: Debería funcionar

Al final li he dit que fes el que trobés per tal que jo pogués telefonar. He rebut un missatge fa poc indicant que s'ha anulat el límit. Ja puc telefonar però encara no tenc accés a internet.

Espero que el projecte en el que treballo no generi converses com aquesta entre la gent d'atenció als usuaris i les pobres víctimes

PS: Una conversa sentida a l'avió (també real):
 1- Que frio! En XXXX teniamos 22 grados durante la noche
 2- ¿En la sombra?

Idioma

En tots els projectes en que he participat, hem emprat el català en el codi. Això s'ha fet sense cap discussió, semblava que la opinió era unànime. Però, i si no haguera estat així? i si hi hagués hagut divisió d'opinions?

Suposo que tots els raonaments haurien estat fets a posteriori. Vull que es faci en català, quins arguments puc emprar? Desgraciadament sembla quasi impossible procedir d'altre forma en aquesta qüestió.

Pensant-ho fredament, quin idioma s'hauria d'emprar? o, millor: quins arguments hi pot haver per decantar-se per un idioma o un altre?

Una llengua, si intentem treure factors emocionals que l'enrevolten, és (en l'àmbit que ara ens interessa) una eina de comunicació, i com a tal l'hem d'analitzar en el nostre cas. Quin idioma complirà millor la tasca d'expressar el significat del nostre codi?

Descomposaria aquesta capacitat en dues propietats diferents: l'univers de persones que podrà llegir el nostre codi i la capacitat expressiva d'aquest idioma en l'àmbit que desenvolupam.

Anem al primer punt: qui podrà entendre el nostre codi. En aquest cas hi ha factors quantitatius evidents: el nombre de persones que podran treballar en el nostre codi serà molt major si ho fem en castellà, que si ho fem en català. Tots dos, per la seva banda, seran molt inferiors al que tendrem si emprem l'angles. En l'àmbit que treballem, aquestes diferències són pràcticament inexistents (gent de les illes), però se'ns poden ocórrer fàcilment motius per ampliar aquest àmbit. Per exemple, deixar l'aplicació a altres comunitats o fer-la codi lliure. Un altre exemple, accedir a serveis de consultoria externa. Si ho fem en angles podrem treballar més fàcilment amb els experts més qualificats en una determinada tecnologia.

I que hi ha de la capacitat expressiva que aconseguim amb l'idioma emprat? En principi un podria pensar que és gairebé equivalent en tots ells. O que només és pot veure afectat per el nivell que tenen els programadors (encara que no ho sembli, escric millor en català que en angles;-) ). Hi ha lògica en això. Però hi ha gent que pot objectar coses importants (bàsicament, els seguidors de l'anomenat Domain Driven Design). Aquesta gent diria que és un valor importantíssim desenvolupar un llenguatge comú entre desenvolupadors i clients que estigui present en tots els àmbits: comunicació directe, documentació, codi, taules, etc. Desenvolupar aquest llenguatge no es tant triar quina paraula emprarem per expressar cada concepte sinó esforçarnos per enraonar amb els mateixos conceptes. No dir habitació si els professionals del sector empren el terme "unitat d'allotjament". Però més que això, entendre per que el terme habitació no és exacte i s'empra l'altre.

Aquesta tasca serà molt més fàcil si emprem el mateix idioma en el que s'expresen els usuaris, la documentació oficial i les altres aplicacions que conviuran amb la nostra. En el nostre cas, aplicacions per la Conselleria d'Educació, el català és la llengua més adient. Si l'aplicació hagués de gestionar la docència a totes les comunitats, això canviaria.

Afegiria, però, que la solidesa d'aquest segon factor està condicionat a la importància que donem al model del domini. Si a l'hora de fer l'anàlisi, el criteri emprat és "basta per implementar els requeriments" poca importància té que hagem de traduir els termes emprats del català al castellà o l'angles.

tancat?

Sense portatil, crec que aquest bloc estara un temps aturat: -(

Robatori

Un mal dia.

M'han robat un parell de coses del cotxe quan estavem nedant a Alcanada. Una bossa on l'atlota tenia el passaport, la camara de fotos, targetes de banc i altres, i una altra bossa on duia dos portàtils, el que empro per treballar a casa i un antic on juga la nina.

Havia agafat el portàtil per acabar de preparar el curs de desenvolupament amb JBoss que comença dilluns.

Quasi tot ho tenia al subversion de la feina, però no havia pujat els projectes amb els exercicis, ni una darrera presentació.

Ara estic preparant a contrarellotge tot el que falta.  Espero poder arrivar amb alguna cosa presentable.

Que hi farem ...