Een week of wat geleden heb ik het idee opgevat om op deze blog aanbevolen links aan de kolom rechts toe te voegen. De blogroll die er nu staat is nogal statisch en ik wil dit veranderen met een klein aantal links die regelmatig veranderen. Probleem is dan wel dat het nogal wat onderhoud vergt om deze interessante links regelmatig te vernieuwen. Zelf verwacht ik daar niet zo goed in te zijn. Het idee zit nu al een tijdje in mijn hoofd. Afgelopen weekend kreeg ik een gaaf idee dat ik wel wil proberen. Eigenlijk ben ik helemaal niet zo slecht in interessante links bijhouden. Via Twitter (re)tweet ik regelmatig links die (naar mijn mening) ook interessant kunnen zijn voor anderen. Als ik die nu op mijn blog kan weergeven ben ik klaar.

De opdracht is dus: verzamel uit je tweets de links die je ge(re)tweet hebt en zet ze op je website. Twitter heeft een mooie API die dit mogelijk maakt. En via @MMz_ begreep ik dat er een java implementatie van de API is: Twitter4j. Na bestudering van de Twitter API blijkt dat ik deze call nodig heb. In Twitter4j is dit geïmplementeerd via deze methode.

Natuurlijk wil ik de software ontwikkelen m.b.v. TDD zoals ik beschreven in dit boek. Hier ontstaan wat probleempjes. Je start altijd met een acceptance test. Het verzinnen van die test was niet zo moeilijk. Haal de laatste x links op uit je Twitter timeline en print ze naar je scherm via aan servlet. Probleempje hier is dat de API altijd andere data laat zien. (Tenminste als je Tweets verstuurt.) Ook wordt je op deze manier je afhankelijk van een webservice van Twitter die een aantal limieten heeft en soms gewoon niet werkt (tijdens het tikken van deze blog heb ik meerdere malen de @failwhale gezien). Verder wil je graag reproduceerbare resultaten hebben in je tests.

Een oplossing voor dit probleem is de Twitter API stubben. Vol enthousiasme begin ik te zoeken hoe ik de Twitter output kon stubben in Twitter4j. Na twee uur ploeteren, javadoc lezen etc. was het me nog niet gelukt. Het probleem zit in de manier in de beschikbaarheid van enkele klassen in de Twitter4j API. Veel van deze klassen zijn final en hebben package access. Ook is de netwerkfunctionaliteit overal tightly coupled aan de rest van de Twitter4j code. Hierdoor wordt het moeilijker om de call te stubben. Door slimme trucjes te gebruiken is het vast wel mogelijk om het voor elkaar te krijgen.

Op de een of andere manier voelde het heel vreemd aan wat ik allemaal het doen was. Eigenlijk wilde ik iets heel simpels, doe deze REST call en filter hier de links uit. Waarom moet ik dan door allerlei hoepels springen om het testbaar te maken. Zelf mijn parser maken voor deze ene API call is makkelijker dan Twitter4j proberen te stubben. Ook de testbaarheid wordt beter bij een (redelijk) slim design. Een eerste inventarisatie levert dit lijstje op: API call doen, result JSON parsen en vervolgens deze outputten om mijn scherm. JSON parsen dat kan niet zo moeilijk zijn. Ik had dit al eerder gedaan met JSON.org maar een tweet van @basvanstratum suggereerde dat er een makkelijker manier was:

Converting my Java objects to Gson using Google’s gson library. Very nice (read: simple) to use. http://j.mp/4fgz1N #geek #work

Ok dan gaan we een uur proberen om GSON te gebruiken. Mocht het niet lukken kan ik nog altijd het alternatief van JSON.org gebruiken. Nu moet ik @basvanstratum volledig gelijk geven in het gemak van GSON. De library heeft een aantal voordelen t.o.v. json.org. Een DTO omzetten naar JSON en omgekeerd is ontzettend makkelijk, de basis is:

MyDTO obj = new MyDTO()
Gson gson = new Gson();
String json = gson.toJson(obj);  
MyDTO obj2 = gson.fromJson(json);

Bij JSON.org moet je meer handmatig door je JSON structuur lopen. Het enige dat ik in mijn geval moest doen was de DTO schrijven die een Twitter status voorstelt. Nu was ik eigenlijk alleen geïnteresseerd in de “entities” property en daarbinnen de “urls” property. Het verbaast mij dat GSON er niet over valt als ik alle andere properties niet definieer. De library vult de properties die beschikbaar zijn en negeert de overige data gewoon. Fantastisch! Ongeveer tegelijk met het ontwikkelen kom ik de volgende blog tegen: TollerantReader van @martinfowler . Hierin beschrijft hij een manier om webservices te consumen waar je alleen de properties leest die je nodig hebt. Hierdoor ben je alleen gevoelig voor wijzigingen in de XML die je echt nodig hebt. GSON maakte dit voor mij ontzettend makkelijk.

Hetgeen waarmee het allemaal begon is erg makkelijk nu. Ik heb de output van de echte Twitter API “opgenomen” en deze data gebruik ik nu voor mijn acceptance test. Nu zullen jullie je wel afvragen heb je die links nu al zichtbaar op je blog. Nee helaas nog niet. Ik kan nu wel de links weergeven op mijn scherm, maar voordat ze op mijn blog komen, moet ik er nog dit nog wat netter worden. Dus binnekort op deze blog aanbevolen links.