Retrospectiva del 2011

D'aquest any que ara s'acaba només puc comptabilitzar coses positives i la més important de totes ha estat entrar en contacte amb els amics de Agile Barcelona, que m'ha portat a participar en altres grups i m'ha omplert de motivació i energia.

A nivell de lectura he començat molts llibres que no he acabat, i tinc la tauleta de nit amb cinc a mitges, alguns molt avançats. Decididament és una cosa a millorar per a la propera iteració.

He llegit sobretot llibres tècnics i en anglès, i dels no tècnics he dedicat moltes hores a George R. R. Martin (potser massa i tot). És curiós, però quan he repassat les lectures, hi havia coses que tenia la sensació que havia llegit feia més temps.

Al blog tinc moltes coses com a Esborrany que no acabo d'escriure, sobretot temes relacionats amb bases de dades. Tinc anotat com a impediment que el codi dels posts no es visualitza prou bé, així que miraré de resoldre-ho el més aviat possible.

El 2012 es presenta molt interessant i la conferència ALE 2012 que es farà l'agost a Barcelona és un estímul extra.

Què tocarà per l'any vinent? millorar l'anglès sobre tot i recuperar les lectures pels temes frikis que sempre m'havien interessat: usabilitat, visualització de la informació, desenvolupament àgil i soft skills. M'haig de posar les piles en moltes coses, però ganes no en falten.

Gràcies per llegir-me.

ALE Bathtubs: conferències sense sortir de casa

La Agile Lean Europe (ALE) és una xarxa de persones que tenen ganes de difondre i fer créixer el pensament Lean i Àgil. És oberta, així que qui vulgui pot apuntar-se. Podeu seguir-los al Twitter per @alenetwork_eu.

Una iniciativa interessant de l'ALE són les Bathtubs Conferences  que són conferències a les que pots assistir sense moure't de casa, i si vols, des de la banyera (bathtub en anglès vol dir banyera). Fem servir el GoToMeeting de CITRIX, que és molt semblant al WebEx de Cisco, i que consisteix en visualitzar la pantalla del presentador i sentir la seva veu a través d'IP. Llàstima que la tecnologia de CITRIX no funciona amb Linux...

El passat 6 de desembre va ser la IV conferència. En aquest cas quatre ponents van presentar les seves idees durant 15 o 20 minuts, deixant després temps per a les preguntes. Va ser des de les 21 fins a les 22:30 (més o menys) i va valer molt la pena.

La primera xerrada la va fer Tonino Lucca, sobre com fer el seguiment dels elements no planificats en Sprints de Scrum.

La segona va ser de J.B.Rainsberger sobre la economia del disseny del software, on començant per recomanar el llibre The Mythical Man-Month (un dels meus favorits) i de parlar de Complicació (i no Complexitat) va definir que el cost d'implementar una funció es pot expressar com:

el cost de la seva complicació essencial + el cost de la seva complicació accidental

Va afirmar que la millor manera de reduir la complicació accidental consisteix en aplicar TDD, per evitar la complicació accidental, i Refactoritzar, per eliminar-la. Finalment, amb bon criteri, afirmà que Scrum necessita XP.

La tercera la va dur a terme Silvana Wasitova amb un títol tan suggestiu com PMI no és l'enemic (PMI és el Project Management Institute) on proposa com conviure amb els gestors de projectes "tradicionalistes" (m'encanta el terme), i argumentà que les dues postures no són tan diferents. Com a ajuda pera la integració proposava el llibre The Software Project Manager's Bridge to Agility.

La darrera presentació, en la meva opinió, va ser la més interessant. Marcin Floryan va parlar de d'on ve el codi dolent. Després de parlar de que el codi dolent pot venir de construir coses equivocades o construir-les malament va arribar a una conclusió força interessant: la majoria dels problemes venen de no haver mantingut una conversa difícil: de no haver-li dit a algú que alguna cosa no funcionava, que necessitàvem més temps o que les expectatives no són realistes. El problema està en NO parlar. I va recomanar dos llibres que segur són molt interessants Difficult conversations i Crucial confrontations.

Una experiència molt interessant i aniré preparant la banyera per la propera edició.

Global Day of Coderetreat a Barcelona

La idea d'un Code Retreat, tal i com explica Corey Haines, consisteix en dedicar un dia a millorar la nostra pràctica com a programadors. En el dia a dia, amb les pressions i les presses, de vegades no podem fer les coses com ens agradaria fer-les, així que destinem un dia a posar-nos a prova, aprendre coses noves i passar-ho bé (a lo friki). Si retreat en anglès és "retir espiritual", ho podríem traduir com "retir pel codi".

El passat dissabte 3 de desembre de 2011 es va fer el dia mundial del coderetreat, desenvolupant de manera simultània code retreats a diferents ciutats de tot el planeta, i a Barcelona ho va organitzar Agile Barcelona a les instal·lacions de  Runroom (gràcies Carlos).

Comptant amb en Jaume Jornet com a facilitador vam començar a les 9:00. Desenvolupant per parelles i fent TDD ens vam posar amb el problema del Joc de la Vida de Conway en iteracions de 45 minuts i 15 minuts de retrospectiva. Cada iteració canviem de parella. Cada iteració esborrem tot el codi. A ser possible, pots provar algun llenguatge amb el que no estiguis acostumat. L'objectiu no és acabar el problema sinó aprendre.

Vam fer sis iteracions, fins més enllà de les 5 de la tarda. A cada iteració s'anaven afegint restriccions que ho feien més interessant: no poder tocar el ratolí (cal conèixer l'IDE), fer codi expressiu, cap mètode de més de 4 línies, ping-pong programming, no es pot parlar amb el company, no es pot esborrar codi, etc. S'aprèn molt!

A banda del Java, vaig poder tastar el Objective C (gràcies Pedro) i C# (gràcies Jose), però em vaig quedar amb les ganes de veure Ruby i Clojure. La darrera iteració va ser en format Randori i fent servir cyber-dojo.com, però ja estàvem massa cansats.

Durant el dia vam contactar per videoconferència amb els companys de Macedònia, Polònia, Berlin, Bilbao i Madrid, i així vam tenir més el sentiment de Code Retreat global.

Més de 20 persones ens vam arreplegar per aprendre a Barcelona, però vam ser més de 2000 a tot el món. Gràcies a tots els que us vau passar per Runroom, perque vaig poder aprendre de tots, i gràcies a les families que ho van fer possible.

Actualització:
Hi ha un vídeo força interessant de la jornada de Barcelona a la Web de Runroom.

Actualització (11 dec 2011):
Un bon resum en diapositives del que és el coderetreat.

Estic llegint: Management 3.0

Leading Agile Developers, Developing Agile Leaders
De Jurgen Appelo. Desembre 2010. Publicat per Addison-Wesley. 464 pàgines

Jurgen Appelo fa un recull en un sol llibre d'una gran quantitat de coneixement al voltant de la motivació, la creativitat i la gestió del canvi, orbitant al voltant del desenvolupament àgil, però en molts casos transportable a altres contexts.

En la meva opinió el llibre segueix fidelment el Mètodel del Mojito (del mateix autor), que consisteix en copiar les idees d'altres i barrejar-les per aconseguir una cosa molt millor.

El capítol 2 és una excepcional repàs a la història del desenvolupament àgil, de les diferents tendències i dels obstacles que es troba.

Al capítol 3, a banda d'explicar que un equip de desenvolupament és un sistema adaptatiu complex i de presentar un seguit de teories, dóna una interessant distinció entre complex i complicat.

• Complicat = difícil de comprendre (oposat de senzill). Relacionat amb l'estructura. 
• Complex = difícil de predir (entre ordenat i caòtic). Relacionat amb el comportament.

Els capítols 5 i 6 són els que veig més directament aprofitables per a sectors no informàtics i són els relacionats amb la motivació i l'auto-organització.  La teoria de X i la teoria de Y, la motivació intrínseca i extrínseca, les tècniques de creativitat i la diferència entre els elements de motivació i els factors d'higiene, són algunes de les perles d'aquests capítols.

Al capítol 10 parla d'una debilitat del manifest àgil, i l'anomena el "punt cec": la competència dels individus. Les pràctiques àgils funcionen si l'equip és bo, i aquesta debilitat la intenta combatre el manifest per l'artesania del programari.
L'autor indica que la competència té dues dimensions, disciplina i habilitat, i que s'han de treballar les dues.

Al capítol 15 presenta el seu propi model de millora, que anomena SLIP (Simple Linear Improvement Process) i el compara amb altres models, com el Plan-Do-Check-Act (PDCA, el cicle de Deming/Shewhart) o el DMAIC de Six Sigma. 

Un bon llibre per aprendre del món de l'agilisme, de com manegar equips àgils, i ple d'apuntadors per aprofondir en tots aquests interessants temes.

A més vam tenir l'oportunitat de conèixer en persona a l'autor quan va venir a la Scrum Week de Barcelona i ens va explicar Com canviar el mon.

Entrevista a Bob Martin: Software Craftmanship i Polyglot Programmers

L'altre dia vaig escoltar una entrevista a Bob Martin a la Software Engineering Radio (podeu descarregar-la o escoltar-la on-line). Ja havia parlat en aquest espai sobre Uncle Bob i la seva artesania del programari (software craftmanship).

Uncle Bob diu que es dedica a programar perquè és el que li agrada, i que no comparteix la idea de molta gent de que la feina de programador és una etapa transitòria fins a convertir-te en manager.


En primer lloc aquest senyor afirma que per tal de ser programador no cal una titulació universitària. L'alternativa que proposa el Sr. Robert C. Martin és una cosa semblant als aprenents dels antics gremis. Comences amb algun mestre i vas aprenent ajudant-lo a fer feina real, no escoltant lliçons. Quan ja saps molt d'un mestre vas a un altre mestre fins que et converteixes en mestre.

A l'entrevista, el locutor li pregunta que quin llenguatge de programació recomanaria i Bob respon que no pots conformar-te amb només un llenguatge de programació. Després de parlar de molts llenguatges (Java, C#, Ruby, Python, Clojure, ..) l'entrevistador pregunta si cal ser un expert en tots i Uncle Bob respon que no cal ser un expert però sí que cal saber de què van, ser capaç d'escriure alguna cosa. D'aquesta manera potser no seràs un expert en Clojure, però coneixeràs els conceptes de Functional Programming i potser podràs aplicar idees quan facis servir el teu llenguatge habitual. Això porta a la idea del Polyglot Programmer que ja en parlarem un altre dia.

Però la part més interessant és quan l'entrevistador li diu, "molt bé, quan se suposa que hem d'aprendre tot això?" i Uncle Bob li diu: millorar les habilitats d'un mateix no es pot fer en temps de feina, això s'ha de fer durant el temps personal. I fins i tot dóna el seu càlcul: cal dedicar a estudiar unes 20 hores setmanals del teu temps. PAM!

Clar, des d'un punt de vista econòmic el que està dient xoca. Costa de vendre la professió a algú que estigui començant. I els que treballen (treballem) per un altre ho veuran com un sacrifici que cal que sigui recompensat. Però pensant com un treballador preocupat en tenir feina demà, és un consell valuós.

I això porta a un altre punt. Si ames el que fas, si realment t'agrada, no ho veuràs com un sacrifici. En aquest sentit he vist en més d'una ocasió una oferta de feina on busquen un programador "friki". L'empresari el que realment vol és algú apassionat pel que fa.

I això em porta a dos històries. Una, de record trist avui, és el discurs del Steve Jobs a Stanford on insisteix en que has d'estimar el que fas perquè és la única manera de estar realment satisfet. I l'altre és el discurs de'n Pep Guardiola al Parlament on parla del mateix: sentir passió pel que un fa.

Pels que convertim aquest sacrifici en un divertiment aquestes 20 hores de les que parla Uncle Bob se'ns queden curtes.

Estic llegint: A Dance With Dragons

De George R. R. Martin. Juliol de 2011. Publicat per Bantam. 1040 pàgines 


La cinquena part de la sèrie Cançó de Gel i Foc és la primera que s'ha publicat després d'emetre la sèrie de televisió del primer llibre (Game of Thrones), i ha estat molt més esperat que els anteriors. Evidentment no ha donat temps a que surti la traducció de Gigamesh i l'hem hagut de llegir en anglès.


 Serà difícil fer un comentari sense spoilers però és el meu costum.


És la primera novel·la que llegeixo amb l'iPad i ha estat fantàstic la lectura en anglès amb un diccionari a cop de clic. Puc dir que augmentat molt el meu vocabulari, to i que l'anglès d'edat mitjana no em serà molt útil (escuder, llança, catapulta, fossar, ...)


En aquesta novel·la l'autor descriu la historia que va relatar a Festín de cuervos, però des de la perspectiva d'uns altres personatges: vist des dels personatges del nord de Ponent (Westeros). Aquesta anomalia (descriure el mateix temps) la manté fins a la meitat del llibre on torna a còrrer el temps.


Presenta ciutats noves i personatges nous, tot i que manté als personatges supervivents. Hi ha un grapat a la ciutat de Meereen que tenen noms tan similars que em va costar de seguir.


Tot i haver-me agradat molt, aquesta és de les cinc la que trobo més fluixa. Alguns personatges no m'acaben d'agradar i altres que sí que ho feien s'han transformat i no em resulten tan atractius. Això, i la sensació de que avança el temps per portar-nos a alguna banda, però no passa res. Com si fos un llibre de transició.


Ara potser haurem d'esperar cinc anys més per veure The Winds of Winter i altre cinc per A Dream of Spring (segons la wikipedia), i confiant que George, de 63, es cuidi bé la salut.



També comentats en aquest blog: 
Juego de Tronos (acabat) 
Choque de Reyes (acabat) 
Tormenta de espadas /1 (i /2) 
Festín de cuervos

Coding Dojo: fent Katas

Un Coding Dojo és una trobada on un grup de desenvolupadors es posen a treballar en un problema per tal d'aprendre i compartir experiències. Es tracta d'un esdeveniment on tothom va a aprendre (i tothom accepta que estem tota la vida aprenent)  i es practiquen les tècniques de Test Driven Developent (si no hi han proves el codi no existeix) i de Pair Programming.

La idea és que per aprendre cal repetir, repetir i repetir... com els practicants d'arts marcials. I d'aquí que hagin manllevat tota la terminologia de les arts marcials japoneses.

Hi ha diferents modalitats de Dojo: Kata preparat i Randori. Al Kata preparat els assistents tracten de resoldre un problema conegut, treballant en parelles, mentre que al Randori només hi ha un parella que codifica, la resta segueix el que van fent en un projector i la parella va canviant per torns.

Havia llegit molt però fins divendres no vaig tenir una oportunitat de participar en un coding dojo organitzat per Agile Barcelona, amb l'hospitalitat de Runroom i el patrocini de Úbeda Gin&Tapas.

Es tractava d'un Kata preparat (no de Randori) i van omplir la sala 20 persones per tal de resoldre el problema de les Torres de Hanoi. Quan vam veure que la web on acostumaven a recollir la descripció de les kates (http://codingkata.org/katas/) estava caiguda, vam improvisar i vam agafar la kata proposada a 12 meses 12 katas que era KataArgs basada en el capítol 14 de Clean Code.

Quan ens vam presentar cadascú deia els llenguatges de programació en els que treballa per tal de veure amb qui podries posar-te a resoldre el problema: Java, PHP, .Net, JavaScript, ... No sé quins llenguatges realment es van fer servir, però les converses posteriors treien a la llum que el més conegut era el Java, tot i les seves febleses.

L'experiència va ser increïble, tot i que la Kata potser era una mica complexa. Els pomodoros, la organització de l'espai de treball, el Ballmer peak... caldrà repetir.

I això de tornar a estar fent Katas és un estímul extra.

Els clàssics jocs Sierra

A finals dels anys vuitanta i començaments dels noranta vaig jugar moltíssim als jocs de PC que feina una companyia americana que es deia Sierra On-Line.
Eren un pont entre els jocs conversacionals (pantalla en negre i tot lletres) i les aventures gràfiques de point-and-click de Maniac Mansion, Monkey Island o Indiana Jones and the Last Crusade.
Podies bellugar al teu personatge per la pantalla amb els cursors i si volies que fes alguna acció havies d'escriure-la en anglès: "open door".
Jugàvem amb el diccionari al costat, i va ser la millor manera d'ampliar vocabulari.

Vam començar amb el primer Larry, però desprès van venir les sagues del King's Quest, Police Quest, Space Quest (potser el meu preferit) i molts d'altres. Quins temps...

L'altre dia vaig trobar per total casualitat un article fantàstic que no només comentava els clàssics de Sierra sinó que explicava com descarregar-los i jugar-los.

Resulta que els jocs antics hi ha gent que els considera abandonware i que es poden copiar amb tranquil·litat (discutible, però hi ha gent que pensa així). Hi ha diferents plataformes per executar antics jocs de DOS i jo he provat una que es diu DOSBox i puc dir que funciona perfectament sobre Ubuntu. Quina il·lusió poder veure els mateixos jocs!!!

El que ja he trobat extraordinari ha estat la pàgina Sarien.net en la que un tal Martin Kool ha transformat alguns jocs de Sierra a JavaScript!!! Hi ha descripcions de com ha fet el codi i pots veure interioritats dels jocs. Pots jugar-los des del navegador sense haver-te d'instal·lar res i fins i tot els ha fet multijugador. Si hi ha un altre jugador en aquell moment en la mateixa habitació, podries parlar amb ell. De moment hi ha cinc jocs (primeres parts i algun aïllat) però és un veritable regal pels vells nostàlgics.
"Ken sent me"

Estic llegint: Festín de Cuervos

De George R. R. Martin. 2005 (2007 en castellà). Publicat per Gigamesh. 860 pàgines

Es tracta del quart volum de Canción de Hielo y Fuego. El boom que ha suposat la sèrie de televisió Game of Thrones ha fet que ara trobem expositors dedicats a les obres de Martin en la majoria de llibreries i ara que acaba de sortir el número cinc en anglès, A Dance With Dragons, l'exposen d'importació com van fer amb altres estrenes, com les del Harry Potter. Hi ha a Barcelona tanta gent que llegeix novel·la fantàstica en anglès?

Aquest quart volum, tot i que manté la línia dels anteriors, l'he trobat una mica més fluixet, potser per que no surten alguns dels meus personatges favorits. Sembla que l'autor volia explicar una part important de la història i que es reparteix en molts territoris i amb molts personatges. Podia haver explicat tota la història en dues meitats, però en comptes d'això es va estimar més explicar tot el que fan uns personatges i en el volum 5 tot el que fan els altres.

Resulta fascinant la manera que té de crear nous mons, ciutats, cultures i religions. Coneixem tres regions d'aquest mon fantàstic que havien sortit només esmentats i afegeix molts nous personatges que sembla que tindran molta importància.

Com ja ens té habituats, en qualsevol moment pot fer un gir radical a l'argument.

M'ha agradat molt la introducció que fa a l'edició espanyola el director Álex de la Iglesia. Molt abans que es plantegés fer una sèrie per la televisió comenta que l'èxit de George R. R. Martin es deu a que abans de dedicar-se a la novel·la feia guions per sèries de televisió, i aplica totes les tècniques que va aprendre.

Tal i com s'ha quedat la història al final d'aquest Festín de Cuervos, crec que faré l'esforç de llegir en anglès.

També comentats en aquest blog:
Juego de Tronos (acabat)
Choque de Reyes (acabat)
Tormenta de espadas /1 (i /2)

Eclipse: com envoltar un text entre cometes

Editant codi amb Eclipse moltes vegades m'agradaria poder fer que allò que tinc sel·leccionat estigués envoltat de cometes dobles (surround with double quotes). Avui ho havia de fer moltes vegades (un canvi de long a String) així que he buscat un Plugin de Eclipse per facilitar-me la vida i he vist que no cal.

En la entrada Eclipse surround with quotes and other blocks de Stack Overflow he trobat el següent (traducció literal):

Ves a Java > Editor > Templates i afegeix una nova template que anomenes quote, amb el següent contingut:

"${word_selection}"${cursor}

Aleshores a l'editor, escriu el text que vols envoltar entre cometes, el sel·lecciones i prems CTRL + espai, sel·lecciones quote i prems Enter. El text sel·leccionat ara està entre cometes.

Si no veus propostes de templates quan prems CTRL + espai, mira les tinguis marcades a Java > Editor > Content Assist > Advanced.

Com deia un company l'altre dia: "Programar amb Eclipse és control 1 i control espai".

ANTLR: construint llenguatges

Al projecte que estem desenvolupant actualment havien d'acceptar expressions de consulta com la següent:

nom:toni AND (data:ENTRE 17-FEB-2010 I 25-MAR-2010 OR ciutat:Barcelona)

(no exactament això, però com a exemple ens serveix)

Aquesta consulta expressada d'aquesta manera calia validar-la i convertir-la, entre altres coses, a una consulta SQL.

Per fer aquesta feina podíem haver fet un codi basat en substrings i molts if, però el resultat seria poc flexible (i poc fiable). El millor és sempre fer servir l'eina adequada per cada problema, i en aquest cas el més adient semblava ANTLR.

ANTLR (ANother Tool for Language Recognition) és una eina que permet construir aplicacions per reconèixer i interpretar llenguatges. S'assembla al lex i el yacc que vam veure a les assignatures de Compiladors, o al Flex i Bison que trobem a GNU/Linux, o al JavaCC.

Amb ANTLR pots construir un lexer i un parser, definint el llenguatge amb notació similar a BNF, igual que fèiem amb yacc, però amb moltes facilitats. Entre altres coses hi ha una eina visual per anar provant la gramàtica a mesura que la vas escrivint. I s'integra perfectament amb Eclipse.

Resulta molt fàcil crear DSL (Domain-Specific Languages) fent servir ANTLR, i això obre un món de possibilitats.

Tot i que no he estat jo el que al final a desenvolupat el parser al projecte, he pogut veure tot el potencial de ANTLR. A la seva plana Web els usuaris han anat pujant gramàtiques per molts llenguatges, entre d'altres el PL/SQL. Això m'ha fet recordar un munt de projectes personals abandonats, com el formatejador de PL/SQL o, molt més interessant, un analitzador estàtic de codi PL/SQL que doni informació com:

• variables no usades
• funcions i procediments no usats
• us adequat de convencions pels noms
• tipus de dades coherents

Pot ser un projecte molt pràctic per netejar codi existent. A veure si trobo temps finançament...

Estic llegint: Los Olvidados

De Tim Tzouliadis. 2010. Publicat per Debate. 520 pàgines.

Aquest assaig històric descriu una part de la història contemporània que no és gaire coneguda. A la Gran Depressió del anys 1930 la taxa d'atur als Estats Units era molt alta i van haver milers d'americans disposats a provar sort a la Unió Soviètica, un paradís dels treballadors i una terra d'oportunitats.

Molts americans van viatjar a la URSS de Stalin per buscar feina i un futur per les seves famílies. En aquella època fins i tot la Ford va obrir una fàbrica de cotxes a Rusia, on van anar a parar alguns enginyers americans. Al llibre podem veure fotos d'aquests pioners americans jugant a beisbol a parc Gorki.

Però les coses no eren gens maques amb Stalin. Va arribar "el Terror", on sistemàticament els serveis de seguretat soviètics feien escorcolls i detencions nocturnes de tots els sospitosos de ser "enemics del poble".

I l'ambaixada americana va passar d'aquests emigrants.

Deixant de banda la situació dels americans, les tortures, execucions i explotació com a esclaus als Gulags i les mines d'or de Sibèria van durar molts anys. Al llibre no s'atreveix a donar xifres, però parla d'uns 15 milions.

Quan es va aixecar Hitler i la Unió Soviètica es va convertir en aliada dels Estats Units Stalin va continuar exterminant el seu poble i costa de creure que s'estengués tant en el temps.

És trist, però aquestes atrocitats no ens van afectar com ho van fer els camps d'extermini nazi per la sola raó de que no tenim imatges.

Es tracta d'un relat molt dur però és una part de la història que no podem ignorar.

Malgrat que ha estat de vegades ha costat de llegir, haig d'agrair al meu cunyat per haver-me'l regalat.

Si voleu, podeu llegir un resum molt més detallat del llibre a la web de Hislibris.

Estic llegint: JUnit in Action

De Vicent Massol amb Ted Husted, 2003. Publicat per Manning. 384 pàgines

He tingut l'oportunitat de llegir aquest llibre pràctic sobre JUnit i, com li passa a la majoria de llibres molt tècnics, se li nota massa el pas dels anys.

JUnit ha canviat moltíssim a la versió 4, i també ho ha fet Java a partir de la versió 5, així que moltes de les coses explicades ja no tenen sentit. És difícil anar passant les pàgines del llibre destriant allò que realment és interessant i no està obsolet. Sí que pots aprendre coses amb el llibre, però es fa difícil de llegir.

Està bé veure:

• Com funciona internament JUnit
• En quin directori cal posar els tests
• Els diferents tipus de test
• La diferència entre proves unitàries i proves d'integració
• Una revisió del procés de desenvolupament
• La diferència entre mocks y stubs
• Eines per construir mock objects (encara que una mica obsoletes)
• Ús de Jetty per fer proves de servidor
• Proves amb Base de Dades (encara que coneixent les eines que dóna Spring Framework, el capítol era poc útil)
  

També hi ha molta cosa no aprofitable o que falta, com les maneres de provar EJB (ha canviat del tot l'especificació i les eines), la millor manera de fer servir les annotations i les test suites amb JUnit 4 o les llibreries addicionals que es poden fer servir amb JUnit.

La segona edició del llibre sembla que corregeix alguna de les obsolescències que he comentat. He pogut llegir dos capítols gratuïts que tenen publicats els de Manning i n'hi ha molta cosa interessant. Per exemple al capítol 19 explica llibreries que es poden fer servir, com Hamcrest, Unitils, Mycilla, DbUnit, FEST o JUnit-addons. També revisen EasyMock i Mockito per construir mock objects, però no als capítols gratuïts.

Un llibre difícilment recomanable avui en dia. La segona edició fa millor pinta, però aquest tipus de llibre queden obsolets amb molta facilitat.

Java, Oracle, NLS i tests

Aplicació Java amb Oracle 11g. En dos entorns diferent una consulta amb ORDER BY dóna resultats en ordre diferent. El problema està, evidentment, en la configuració del NLS.

El driver JDBC d'Oracle, la versió purament Java (la versió thin), no fa servir la variable d'entorn NLS_LANG des de la versió 10g. En comptes d'això dedueix els valors de NLS de l'idioma del sistema operatiu. La manera de canviar l'idioma consisteix en passar els següents paràmetres a la VM:
-Duser.language=en -Duser.country=EN

Arrencant amb aquest valors l'ordenació anava bé, per que agafava el NLS_LANGUAGE, NLS_TERRITORY, NLS_SORT i NLS_COMP als valors que esperàvem. Experimentant una mica, vaig veure que amb NLS_SORT si poses BINARY és el més eficient, però si vols que ignori majúscules i minúscules pots fer BINARY_CI i si vols que ignori accents pots fer BINARY_AI. Però això no és l'important.

El cas és que no volíem haver de llençar les nostres màquines virtuals amb paràmetres especials, així que vam mirar de configurar-ho directament a l'aplicació.

La teoria diu que -Dparam=valor és el mateix que des del Java System.setProperty("param", "valor"), però no és així pel que fa a la resolució del NLS. I vam trigar molt en descobrir-ho. En aquest cas el que realment l'interessa és el "default locale" i no aquestes variables d'entorn (que només es fan servir per definir el default locale. Així que tal i com apunten en aquest tutorial de java, el que cal és fer cridar a Locale.setDefault(). En el nostre cas Locale.setDefault(Locale.ENGLISH).

Com això ho volíem fer des de Spring hem pogut aprofitar el que comentava algú al fòrum de Spring.

Ara ja no depenem dels paràmetres d'inicialització.

Conclusions:

• Les proves automàtiques t'ajuden a trobar els errors ben aviat
• La configuració de NLS amb Java és un mal de cap

Una proposició de Google

D'ençà que vaig posar la LinedIn les meves dades en anglès vaig rebent ofertes de feina de l'estranger. Reps un missatge d'algú que vol que t'afegeixis a la seva xarxa de contactes professionals i al final és per una proposta laboral. I jo que no estic buscant feina.

Doncs l'altre dia vaig rebre un missatge d'una empleada de Google per afegir-me a la seva xarxa. Quins nervis: Google s'havia fixat en mi! Em va dir que hi havia una oferta de feina de “high profile” i que semblava que podia encaixar però necessitava veure un currículum meu. Vaig preparar un curri en anglès tan ràpid com vaig poder i li vaig enviar, pensant que em descartaria directament.

Però no. Em va enviar detalls de l'oferta, indicant les tasques a desenvolupar, i semblava molt interessant. L'oferta era per Munic, Dublín o Zúrich (a Londres no hi havia places). Hi havia una oferta per Sistemes i una altra per Software, les dues molt xules.

Aleshores em va demanar que em puntués del 0 al 10 en diferents coses (llenguatges, sistemes operatius, etc.), essent un 10 que hagués escrit un llibre sobre el tema. Amb les meves puntuacions em va convocar per una entrevista per telèfon i vam quedar.

Em va preguntar que si tenia un Blog técnic, i quan li vaig dir que era en català em va dir “then, it doesn't matter”. No era una entrevista, era un examen. M'anava a fer preguntes respecte aquells punts que jo m'hagués puntuat més alt i els que ella cregués. I jo sense connexió a Internet!

Vaig començar bé amb les preguntes de base de dades, i vaig continuar molt tranquil amb Java i amb Linux. Però em va plantejar un parell de problemes i una pregunta teòrica que em van descol·locar. No, no m'enrecordo del cost del Quicksort (potser que fos log(n)?

Després d'unes deu preguntes em va dir que es posarien en contacte amb mi en tres dies, i si passava aquesta entrevista tindria una altra amb un enginyer, i si la superava la següent seria a Dublin.

Als tres dies, molt amablement, em va dir que havia estat un plaer xerrar amb mi però que actualment no tenien una plaça que encaixés. Snif.

Ja veus quina tonteria. Em vaig sentir molt content i orgullós uns dies. Al poc temps vaig veure que Google anava a incorporar 26.000 nous empleats a la seva plantilla.

Per poder fer que una gran corporació es fixi en tu:

• Apunta't al LinkedIn i amplia la teva xarxa de contactes (si no em tens, ja saps)
• Posa el teu perfil de LinkedIn en anglès
• Si vas fluix d'anglès, posa-li remei
• Agafa bon coneixement teòric d'informàtica (una carrera ajuda)
• Agafa bon coneixement d'un llenguatge com Java o PHP
• Agafa bon coneixement de Linux
• Si fas un blog tècnic, fes-lo en anglès

Ha estat una experiència.

La sèrie Game of Thrones: una primera impressió

Aquest diumenge van emetre el segon capítol de la sèrie Game of Thrones pel canal de cable americà HBO (Home Box Office). No volia fer cap valoració fins no veure un segon capítol, perquè de vegades els capítols pilot enganyen.
Ara sí que puc dir que és impressionant i molt fidel al llibre. Alguns personatges no coincideixen amb la imatge mental que m'havia fet, però funcionen força bé en el seu paper, i tenint en compte que el propi George R. R. Martin ha participat en la producció, no li podrem pas discutir.
No tenia idea de què li semblaria la sèrie a algú que no ha llegit la novel·la, però avui m'han confirmat que l'efecte és similar.
Haurem de seguir ben atents a veure com resoldran algunes ambientacions, escenaris i demés.
Imprescindible.

Remote Pair Programming

Una de les tècniques que proposa extreme programming (XP) és el pair programming: dues persones treballant alhora sobre el mateix codi. Això que molts consideren una pèrdua de temps (perds un recurs) realment obeeix a una aritmètica molt diferent. A la pràctica, tenir sessions de desenvolupament en parelles resulta en un codi de més qualitat, una major comprensió de l'arquitectura per tot l'equip i una millora en la productivitat (evitant el temps perdut pels "multitaskings"). Això sí, el pair programming cansa molt.

El cas és que estem aplicant TDD al projecte, i per aprendre el millor és fer pair amb algú que en sàpiga. I això és el que hem fet: sessions amb tot l'equip... fins i tot amb el company que viu a Argentina.

Com hem fet pair programming a tanta distància? Em fet servir eines habituals de comunicació (Skype per parlar i WebEx per compartir escritori) però necessitàvem alguna cosa més adreçada a remote pair programming (tanbé anomenat distributed pair programming).

Saros és un plugin d'Eclipse que permet que dues (o més persones) editin alhora el mateix codi. És impressionant. Pots seguir al teu company com va movent-se pel codi, com edita i com sel·lecciona. I en qualsevol moment tots dos poden posar-se a escriure. És fantàstic una conversa de l'estil "li canvies el nom a la variable o li canvio jo?" o "molt bé, ves escrivint la declaració que començo aquí a sota a fer la implementació".

Hem provat fer party programming entre tres i també ha funcionat força bé. Quan estàs fent la definició d'algun mòdul nou és força interessant perquè pots fer un disseny per consens.

Saros també té una pissarra per compartir diagrames i sembla que també pot fer Veu per IP (VoIP) i compartir la pantalla, però això no ho he provat.

Definitivament crec en el pair programming i crec que és important que el navigator (el que no té el teclat, el que no està conduint, el que no és el driver) ha de tenir un altre ordinador a prop.

Ara vull provar estar un al costat de l'altre i disposar de Saros, per si en un moment puntual els dos s'han de posar a codificar.

Tot un descobriment aquest Saros.

Estic llegint: Scrum and XP from the trenches

De Henrik Kniberg. 2007. Publicat per InfoQ.com, 170 pàgines (enllaç)

Un bon llibre per aprendre Scrum i a més a més de franc.

Tal com diu el títol (Scrum i XP des de les trinxeres), es tracta de l'experiència en l'aplicació d'aquestes metodologies a una empresa. L'autor explica què és el que ha provat i com l'ha anat a ell, avisant que és possible que tu no et vagin bé les mateixes coses. Però ja tens un punt de vista de referència.

Explica els conceptes com Backlog, Burndown Chart o Planning Poker. I és molt fàcil de llegir i molt curtet.

He vist que també hi ha una versió en castellà. L'he fet un cop d'ull però quan veig alguns termes traduïts em xoca molt. Imagino que tot és acostumar-se. Com parlar de disparadors o pronunciar /uraklə/.

Ha estat la primera vegada que he fet servir el meu iPad per llegir un llibre i la veritat és que va molt bé. Em sembla que a partir d'ara el faré servir molt per a lectures tècniques.

Adéu iBatis. Hola MyBatis

L'altre dia comentava una API d'accés a bases de dades des de Java, el JPA. També comentava que un petit inconvenient de JPA és que el teu model de dades s'ha d'adaptar a l'eina i no pas a l'inrevés. La manera d'enfocar el problema objecte-relacional és des del punt de vista dels objectes.

Com la nostra realitat no ho permet un canvi en el model de dades, havíem de buscar alternatives, que permetessin fer accessos SQL. Com que el JDBC directe és insuportable (try-catch-finally fins la mort) calia una bona API. Els JdbcTemplate de Spring era una opció, però els RowMappers són un rotllo. Així que vaig anar a buscar a un vell conegut: iBatis.

En buscar referències vaig veure que el projecte ja no existia. L'autor, Clinton Begin, havia portat el projecte de Apache a Google Code i l'havia canviat el nom. Ara es diu MyBatis.

La virtut d'iBatis (i del nou MyBatis 3) és que tot el SQL és a fitxers XML, i que el mapeig a objectes pot ser molt sofisticat i és molt senzill de fer. A més a més proporciona mecanismes de caché i s'integra amb facilitat amb Spring i ehcache (entre d'altres).

MyBatis canvia algunes coses respecte a iBatis i simplifica molt la vida, reduint el codi de configuració. Aquesta versió (la 3), dóna l'opció de definir les consultes directament al codi Java, mitjançant annotations, però no em sembla una cosa que faré servir.

Portem uns dies fent proves amb consultes molt complexes (crides PL/SQL, ús d'ARRAYs, CLOBs, etc) i de moment estic molt content. I les consultes fàcils no tenen cap mena de complicació.

Ara només queda no cometre els errors de sempre i començar a pensar en objectes des del primer dia. Aplicant TDD i considerant les caché des del primer moment estic segur de que ens ensortirem.

Estic llegint: Tormenta de espadas /2

De George R. R. Martin. 2005. Publicat per Gigamesh. 604 pàgines

Realment no és una nova novel·la sinó que la traducció al castellà de Tormenta de Espadas va resultar massa voluminós i es va publicar en dos llibres de 600 planes. Aquesta és la segona part del que vaig comentar aquí fa poc.

Els arguments i els personatges van canviant i la història va evolucionant de manera que no puc predir. El ritme no decau i es manté l'ambient.

I és l'ambient, tot el que envolta aquest món de fantasia, el que està cuidat amb gran detall: descripcions de menjars, cançons, costums, vestits, ... Genial en tot moment.

Una cosa sí que haig de dir, però. George R. R. Martin ja ens havia deixat clar que pot passar qualsevol cosa. Que no hi ha personatges protagonistes ni immortals, i que tot pot canviar en qualsevol moment. Ho havia entès. Però crec que se li ha anat una mica la mà amb els "canvis" aquesta vegada. Opino.

Estic desitjant agafar la següent novel·la: Festín de Cuervos.

JPA: S'ha acabat el pensar en relacional

Quan tens una base de dades i coneixes SQL tots els problemes els penses en termes relacionals: taules, consultes, inserts, deletes, etc. Si necessites una dada, fas una query. Si la dada és a una altra taula, fas una JOIN.

A una aplicació Java tot ho has de pensar en termes d'objectes, defineixes les seves relacions i la seva jerarquia. Si has d'accedir a una base de dades relacional des de Java, ja tens el mal de cap.

D'entrada la API d'accés a dades, el JDBC, és molt ferragossa. I per altra banda tenim el clàssic problema del "impedance-missmatch", que no podem mapejar directament una jerarquia d'objectes a un model relacional. I a això l'has de sumar que si estàs fen consultes de, diguem Empleats, cada vegada que obtens un Empleat faràs un nou objecte que després quedarà a disposició de la màquina virtual per ser alliberat. Un malbaratament que et fa pensar en l'ús d'alguna caché.

Per totes aquestes coses han sortit moltes solucions de mapeig Objecte-Relacional, els coneguts ORM. Després d'haver provat TopLink i Hibernate, he topat amb JPA, Java Persistence API.

D'entrada JPA pertany a l'estàndard JEE (tot i que ha estat creat a la mida d'Hibernate) i permet fer servir tots els recursos dels Entity Beans sense fer servir Entity Beans.

Fent servir annotations (que són aquelles coses que porten una @ i es posen abans de la definició de la classe, de l'atribut o del que sigui) marques tota la configuració de la teva entitat. Un @Entity abans de la teva classe, i un fitxer de configuració persistence.xml i ja tens mapejada una taula a la teva classe. Tens mètodes per obtenir un registre per identificador (em.findById(...)) i cada vegada que modifiques l'objecte que has recuperat es converteix en un update.

Per sota JPA farà servir un Persistence Provider, una implementació concreta. He vist que hi ha una d'EclipseLink i una altra d'Hibernate, i cal anar en compte si fas servir alguna de les extensions pròpies. Només he provat la d'Hibernate.

El codi final queda super net i fàcil de llegir. Però tot no podia ser tan bonic.

Fer un mapeig d'una taula, és immediat. Mapejar una jerarquia, o un Empleats-Departaments (on cada Departament té una llista dels Empleats que treballen) ja posa les coses més difícils. I altres coses, senzillament no es poden fer.

Si es tracta de construir una aplicació sobre un model de dades existent la recomanació és adaptar-lo: construir les vistes o el que calgui per tal de facilitar-li la vida a JPA. Moltes vegades no hi ha prou amb vistes, per què necessites noves taules amb noves seqüències.

El disseny de la BD per una aplicació que ha de fer servir un ORM (sigui JPA o el que sigui) ha d'anar de la mà del disseny dels objectes. Em costa molt pensar d'aquesta manera, però certament quan dissenyes una BD has de tenir en compte la manera com es farà servir. De fet, les desnormalitzacions són necessàries quan coneixes quin ús tindrà la BD, no abans.

El problema que li veig és que el model de dades que li vindrà bé a JPA segurament no serà bo per alguna altra tecnologia més clàssica. I l'altre problema és que per que aquests muntatges siguin eficients cal muntar una caché d'objectes, i si tens aquestes cachés ja no pots accedir o modificar les dades des d'una altra tecnologia. Invalidem el concepte "altra tecnologia". Fins i tot potser que invalidis els triggers o les constraints.

JPA, i altres ORM, intenten apropar las bases de dades relacionals a les aplicacions Orientades a Objectes. No és una solució ideal, però de moment és el millor que m'he trobat.

Carta de Google

He rebut una carta de Google i venia acompanyada d'una targeta de promoció. D'entrada m'ha fet molta il·lusió però després de llegir de què tractava la sensació ha estat molt diferent.

Estan enviant cartes a alguns usuaris dels seus serveis per tal de promocionar AdWords, donant-te un val per que el gastis fent servir els seus productes de promoció.

És marketing del de tota la vida. Fer cartes als clients, com s'ha fet tota la vida. D'entrada m'havia fet molta gràcia. Però després ho he vist tan... analògic...

PostgreSQL a UOC

Aquesta setmana comença un nou curs a la UOC i aquest any tenim novetat a les assignatures de bases de dades (de les que tornaré a ser consultor). Per fi deixem de fer servir Informix com a servidor de base de dades per fer les pràctiques. A l'assignatura de SGBD (la tercera de la branca) les pràctiques es feien amb Oracle, i no sé si seguirà igual, però per Bases de Dades I i Bases de Dades II ara farem servir PostgreSQL.
No és que Informix fos una opció dolenta per l'assignatura, però no era possible fer servir la versió específica des de Linux i em tocava molt els nassos haver de tirar de màquina virtual només per l'Informix. I es veia una mica ranci...
Ara podem fer servir el mateix motor des de Linux o Mac, i estarem fent servir un programari de codi obert que està molt ben parit.

Porto un any llegint força documentació i fent alguns exercicis i la veritat és que és un motor molt complet. En alguns detalls de la implementació s'assembla molt a Oracle, cosa que ajuda força.
Com a mínim ara els procediments i triggers seran més entenidors, per que el codi d'Informix em resultava força estrany.
També treballarem amb apunts nous, i aquests canvis sempre s'agraeixen.

Els avantatges de les mudances

A la meva antiga feina, l'amo sempre deia que ell cada any canviava a tothom de lloc. Que era una cosa bona. D'entrada em va semblar un despróposit, un malbaratament d'energia innecessari, però el temps m'ha portat a donar-li la raó completament (en aquest aspecte).

La primera vegada que vaig viure aquest canvi de lloc “gratuït” d'entrada hi havia molt neguit. Tothom patia per qui li tocaria de company de taula, si tindria aire acondicionat a sobre o finestra a prop. Però un cop superats aquests neguits, la tornada a la feina va suposar moltes sorpreses agradables.

El canvi, t'obliga a estar més alerta. Més concentrat. Has d'abandonar rutines i agafar-ne de noves, i la renovació sempre és positiva. En definitiva, és una nova empenta a la teva productivitat.

Un altre benefici potser més important és la neteja. Quan has de deixar el teu lloc, agafes només el que et fa falta i tot allò que ja no necessites, ho llences. Si no fas el canvi, totes aquelles coses prescindibles es van amuntegant a una pila sobre la taula, o amagades inútilment a un armari.

Dilluns vinent canviem d'oficines. No a Omatech, sinó al client on ja porto un any. Aquests dies s'està fent neteja i preparant les coses que portem al nou edifici. La quantitat de coses que s'estan llençant! I la quantitat de coses que s'estan trobant! Dilluns segur que comencem amb energies renovades.

Els canvis són bons.

Estic llegint: Tormenta de espadas /1

De George R. R. Martin. 2000. Publicat per Gigamesh. 622 pàgines.

Després de l'anunci de l'estrena de la sèrie de televisió Joc de Trons (la primera novel·la de Cançó de gel i foc) no vaig poder evitar seguir amb la lectura d'aquesta serie. Cada llibre són més de 500 pàgines però no es fan llargs. Què bo que és!
Una de les dificultats de la lectura d'aquestes novel·les és que hi ha tants personatges, ciutats i relacions que cal fer un petit exercici de memòria, però la manera que té d'explicar les històries, destinant cada capítol a un personatge, fa que es faci curt.
Amb les 600 pàgines llegides, encara no han aparegut alguns personatges però les històries han evolucionat de manera molt interessant.
Tenia por que l'autor es deixés portar i afegís molta més fantasia, però la proporció segueix essent molt, molt adequada.
Com la traducció al castellà de l'anglès va fer augmentar molt el número de pàgines, els editors es van estimar més publicar la novel·la en dues parts. Així que ara em toca llegir la segona part abans que se m'oblidi res.

Refetes de Hollywood

L'altre dia vam intentar veure la pel·lícula El Equipo A i no la vam poder acabar (què dolenta!). I és que ara moltes, moltíssimes de les pel·lícules que fan ara són fluixes reconstruccions d'altres pel·lícules o sèries que han tingut èxit. Crisi d'idees? No sé. El gran Akira Kurosawa va fer una repassada íntegra a l'obra de Shakespeare i no per això eren pel·lícules dolentes. Cal que la història sigui bona i estigui ben contada, i és normal voler fer una relectura i voler explicar la història d'una altra manera, però ara no és un esforç d'un autor sinó el desig d'una productora per fer diners. S'acabat l'art.

Amb aquesta línia de pensament vaig donar-li voltes i vaig caure que, tard o d'hora, és fàcil que facin un remake de clàssics com Ben Hur, Metropolis o El Padrino. Per què no?

I veient la tendència actual de videoclip, protagonistes "buenorros" i "buenorras", i escenes d'acció trepidant, vaig pensar en la refeta de 2001, una odisea en el espacio. No crec que sigui intocable.

A la nova versió que he imaginat el tema del monolit i dels simis queda amagat. Per què destacar-lo si la gent no ho entendrà? Els hi estalviem.
Desprès posem un astronauta musculat i potser una astronauta, per afegir tensió sexual. A l'estació espacial hi ha una intel·ligència artificial controlant-ho tot. A la versió de Kubric (i a la novel·la de Clark) aquest "ordinador" es deia HAL. Aquest nom era el resultat de restar una lletra a la paraula IBM. A la meva pel·licula es dirà Iqqing, el resultat d'incrementar dues lletres a Google (brillant, no?).

Al final de la pel·licula una persecució, una batalla espacial, robots dirigits per Iqqing contra el forçut astronauta i un final previsible. A l'alçada del cinema actual.
Hollywood prepara't, que tinc moltes més idees!

El més curiós és que he cercat Iqqing per internet i he trobat uns 1000 resultats. Què difícil s'ha posat ser original...

Treballant amb dos monitors

Havia sentit les virtuts de treballar amb dos monitors i, fins i tot, molts dels companys de Omatech en fan servir dos per treballar, però jo mai havia fet servir un ordinador amb dos monitors connectats... fins fa uns dies. I m'ha canviat la vida.

Fa uns dies, treballant des de casa, havia de connectar-me per Terminal Server a una màquina i alhora fer servir recursos locals (Skype, fitxers locals, correu, ...). Vaig pensar en endollar el monitor de l'ordinador de casa al portàtil de feina (que era el que havia de fer servir). Vaig veure que a la configuració de l'Ubuntu podia indicar-li si volia tenir la mateixa imatge a les dues pantalles (la del portàtil i la de casa) o tenir de diferents. Vaig posar que fossin diferents.

A partir d'aquell moment quan el cursor del ratolí sortia d'un monitor per una banda apareixia a l'altra monitor. Podia desplaçar les finestres fins on millor m'anés i així vaig tenir Terminal Server en un monitor i recursos locals en l'altre.

Si amb Ubuntu ha estat fàcil amb el Windows imagino que serà més fàcil encara.

Ara ja l'he fet servir unes quantes vegades:

• Per corregir els exàmens de la UOC: en un monitor posava el examen a corregir i a l'altre la solució oficial.
  
• Per escriure una presentació i un document: en una banda poso el document de treball i a l'altra banda poso el navegador o els PDF d'on estic recopilant informació.
  
• Per desenvolupar: en una banda poso el codi i en l'altra banda poso el navegador on vaig provant o la documentació de referència.
  

No crec que sigui equivalent a tenir un monitor més gran. El fet de que siguin dos monitors et permet distingir més fàcilment el model mental que fas servir (consultar-escriure). Et permet aïllar-te.

No sempre és útil els dos monitors. Hi ha feines en les que el secundari el tindria totalment apagat (redacció de documents sense referència, generació de gràfics, etc.) però realment crec que suposa un avantatge considerable.

Potser algú podria fer una mètrica i resultaria que el cost del monitor queda ràpidament compensat per l'increment de la productivitat. No sé. El que tinc clar és que a mi em funciona i si ho proves, segurament, acabaràs demanant-li al teu "jefe" que et posi un altre monitor.

Gmail i els fitxers adjunts

La gent de Google no deixa mai de sorprendre'm. Avui estava escrivint un email i quan he pres el botó d'enviar m'ha sortit el missatge que podeu veure. Estava enviant les hores del mes i havia començat la redacció dient "us adjunto", però m'ho he repensat i he ficat el text directament. A més a més, el missatge en català.
Un aplaudiment.


Per si no veus la imatge diu:
Volieu adjuntar fitxers?
Heu escrit "Us adjunto" al missatge però no hi ha cap fitxer adjunt. Voleu enviar-lo igualment?

Sèrie de Games of Thrones de HBO

La sèrie de Joc de Trons (la col·lecció de llibres que ja hem comentat per aquí) s'estrenarà el proper 17 d'abril, segons veig a la web oficial de HBO (un canal de cable americà que ja ens ha donat sèries com Sexo en Nueva York, Band of Brothers, Los Soprano o Dos metros bajo tierra.

Ja podem veure tres de trailers per la web. El del corb, un en el que podem veure el Tron dels Targaryen (incòmode i fet d'armes dels vençuts) i un altre on veiem més escenes.
El que està molt bé és el Inside Games of Thrones (que també he trobat subtitulat), on els actors parlen dels seus personatges i de la història.

M'han agradat molt les recreacions dels personatges, Eddard ( Sean Bean, el Boromir del Senyor dels anells), Cersey, Daenerys o Tyrion. No m'ha agradat el que he vist de Robert ni de Jon, i Khal Drogo no s'asembla gens al que m'havia imaginat.
Tot i així em moro de ganas per veure-la.

Com m'havia deixat els llibres a mitjes "m'he vist obligat" a agafar el tercer llibre i compaginar-lo amb les altres lectures que portava.
Winter is coming

Estic llegint: Ciudadano Can

De Mark O'Hare. 2000. Publicat per Norma Editoral. 128 pàgines

De vegades es fa difícil llegir un llibre recopilatori de tires còmiques, però no ha estat el cas. No coneixia aquests personatges i no els he vist en cap diari, però la relació entre aquest gos i el seu amo (Fergus i Mel) és molt divertida.

Amb un humor blanc i enginyós, l'autor planteja una relació de parella totalment disfuncional. Recorda al repartiment d'intel·ligència d'una altra parella home-gos (Wallace i Gromit).

El gos atenent al telèfon, conversant amb les cites de l'amo, negociant pel menjar o buscant feina, sumat amb la persecució als carters o el menyspreu als gats, són situacions habituals a "Ciudadano can".

Els personatges secundaris recurrents també són importants en aquesta sèrie: el carter, el gos amic Arlo i, sobretot, el gat Zarpas. Les aparicions del gat són el de les parts més divertides, i com diu l'Albert, es mereixeria un spin-off.

Cal destacar la traducció. En molts casos l'humor es basa en jocs de paraules que es podrien haver perdut perfectament, però els responsables de la traducció han aconseguit que no perdem l'essència en cap moment. Tasca difícil.

Una obra que prometia algun somriure i m'ha fet riure de valent en alguns moments.

Shibboleth

Segons la Wikipèdia un shibboleth és qualsevol ús de la llengua que és indicatiu de la pertanyença a un grup.
Shibboleth és una paraula hebrea que vol dir "espiga". A la Bíblia (Jutges 12, 4-6) explica que quan els de la tribu de Galaad van guanyar una batalla als de la tribu d'Efraim, els galaaditas distingien als supervivents efraimites fent-lis passar una prova: pronunciar la paraula shibboleth. Com que els efraimites no tenien el so "sh", pronuniàven "sibboleth", i tal com ho feien eren massacrats.

Un origen tètric per una paraula força convenient. Ens trobem moltes vegades expressions o maneres de parlar que ens fan deduir l'origen d'una persona.
Per exemple, quan ens escrivim amb algú en anglès i fa servir l'expressió "Do the needful", podem afirmar que aquesta persona és de la Índia, Pakistan o Sri Lanka.

L'altre dia parlàvem amb un company d'OMA que és expert en Japó dels restaurants japonesos de Barcelona que estan regentats per xinesos, i ens va dir la manera de distingir entre xinesos i japonesos. De la mateixa manera que els xinesos no poden pronunciar la "R" i en el seu lloc diuen una "L", els japonesos no poden pronunciar la "L" i en el seu lloc diuen una "R". Quan ho va dir vaig pensar: "ei, això de distingir per la pronunciació té un nom!", però no em va sortir. Shibboleth.

Per altra banda Shibboleth és un sistema de Single-Sign On de codi obert basat en SAML. Però això no és tan interessant.

Estic llegint: Los combates cotidianos

De Manu Larcenet. 2010. Publicat per Norma Editorial. 244 pàgines

Meravellós. M'ha agradat moltíssim. Acompanyem a Marco, un jove francès, durant una part de la seva vida. Compartim els problemes amb la feina, les seves inquietuds, la fugida de la gran ciutat, la relació amb la parella i amb els pares, ... Vivim amb ell alguns conflictes interiors, les seves angoixes, el seu procés creatiu com a fotògraf, ... Tot plegat res fora del normal, però que construeix un àlbum magnífic.

M'ha agradat el dibuix, que d'entrada sembla molt simple però el combina amb uns fons plens de detalls i algunes pàgines en les que "dibuixa fotografies". De vegades fa servir el color per expressar algunes sensacions com l'angoixa, i m'ha agradat molt com queda.

Fa servir un ritme molt tranquil, un tempo molt europeu: ni l'acceleració i la densitat del còmic americà, ni la successió d'imatges per donar ambient dels japonesos.

M'ha encantat el guió: uns diàlegs bons, uns personatges secundaris no molt definits però ben trobats, una història interessant. Molt actual, amb continguts relacionats amb l'actual història de França i la pujada a la presidència de Sarkozy, i també amb la història menys recent. Un guió equilibrat, amb moments divertits i d'altres molt tristos.

Feia temps que no gaudia tant amb un còmic. I ara penso que em sembla que ja em van deixar un àlbum de "Los combates cotidianos", però això va ser abans de començar aquest blog i no me'n recordo bé. Un altre gran préstec de l'Albert.

Bona música: Andrea Motis

Per pura casualitat he descobert una meravella de cantant de Jazz: es diu Andrea Motis, té 15 anys i és de Sant Andreu. A més a més, toca el saxo la mar de bé. Si us agrada una mica el Jazz o la música tranquil·la, doneu-li una oportunitat. Podeu veure un article a La Vanguardia (amb un vídeo amb la Sant Andreu Jazz Band inclós).
Ha tret un disc amb Joan Chamorro, qui dirigeix la Sant Andreu Jazz Band, la banda de jazz més jove d'Europa. I és un disc magnífic. Podeu tastar-lo al Spotify, Joan Chamorro presenta Andrea Motis, i també podeu anar a compar-lo (i tant!).
Al YouTube hi ha alguns vídeos. M'ha agradat molt un que canta amb Ricard Gili (com Louis Amstrong), Basin Street Blues. No t'ho perdis!

Estic llegint: Agile Software Development with Scrum

De Ken Schwaber i Mike Beedle. 2002. Publicat per Prentice Hall. 154 pàgines

Després de veure la quantitat de llibres que hi ha al voltant de Scrum i després d'haver llegit molta de la documentació que hi ha disponible a Internet, va costar sel·leccionar algun llibre. Aquest era dels més valorats i era prou curt, així que vam decidir compar-lo al client on treballo.

És una bona introducció si no tens molta idea de què va el Scrum, però no parla de moltes de les que ara es consideren pràctiques acceptades com la manera de fer les estimacions.

Parla molt dels valors, de l'equip, de l'entorn, del procés i dóna moltes explicacions de per què funciona. Tot i així m'han quedat algunes preguntes per respondre.

Hi ha moltes "cerimònies" al voltant de Scrum, i s'ha convertit en un mecanisme fantàstic per vendre consultories i formació, i també tenen preparades moltes excuses per justificar quan no funciona. Més val conèixer-ho bé.
Un dia d'aquests faré un post explicant, més o menys, de què va i les coses bones que té, que són moltes.