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.