Mark van Venrooij

Mark van Venrooij's blog

Tag: Craftsmanship (page 2 of 4)

Working with ATG

ATG by delete08, on Flickr

ATG by delete08, on Flickr

Now I’m working with ATG for a couple of months I want to share my thoughts on the platform so far. Let me first introduce ATG. ATG is an ecommerce platform. It promises to deliver out of the box functionality to create complex ecommerce websites. That’s all I want to say regarding the bullshit bingo. Today I’ll discus ATG as seen by a developer. There are many other perspectives to see if the software suits your needs.

In April this year I attended an ATG course containing three modules: “Foundations of ATG”, “Extending the ATG platform” and “ATG Personalization and scenario development”. As you can guess these are modules targeting a developer. There are lots of other courses for business users etc. Just as a reminder before working on ATG I used to be working on all kinds of JEE applications. Furthermore I developed some (test) projects in Ruby (on Rails) and used Google app engine to see the advantages of a cloud platform.

At first it was a shock to work with JSP files again. I was used to JSF / ZK and other component based GUI toolkits. JSP files seemed so old to me on certain moments. As a fact the whole platform feels a little bit out-dated. As an object-relational-mapper ATG basically uses a special kind of HashMap to represent the entities. If you are used to Hibernate/JPA or active record like technologies accessing entities properties with Strings feels not ideal. Maybe I just need to get used to it. The repositories are mapped to the actual database through XML.

ATG uses property files for dependency injection. Unlike Spring these are not in a XML format but just key-value pairs. This makes the property files much more compact. One disadvantage is that (just like Spring/hibernate etc.) it can result in a config hell. I’m not sure anymore if configuration over code is a good mantra. But I’ll save that discussion for my review of the pragprog book.

ATG uses Servlet beans (a.k.a. droplets) to couple the JSP files to the other Java Components. Servlet beans normal servlets but there is an ATG tag handler that lets you access them directly in your JSP.

Let me give an example of using a servlet bean:

A java class handling this droplet extends some base class containing a service method and may look like:

Furthermore we need a config file (named dropletName.properties) to map the servlet bean to a class. This config file is also used for dependency injection (someComponent).

ATG provides several out of the box servlet beans and components for commonly used operations.  For most (java) web developers this pattern is pretty familiar. One possible problem of these droplets is that some people may link up many of them. This results in pretty long JSP files with a lot of logic contained in them. But as Uncle Ben told us:

With great power comes great responsibility

So how do I feel about ATG? It is just another java development platform. It has its quirks and feels outdated sometimes, but any platform has its issues. ATG is just an implementation of ideas also used in JEE.

pro:
– Default functionality available

cons:
– Tends to lead to lots of logic in JSP files.
– Repositories are Hashmaps

Aanbevolen links

2008-02-10 Today's recommended

Today's recommended by henning, on Flickr

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:

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.

Growing object-oriented software guided by tests (A.K.A. Goos)

Growing Object-Oriented Software, Guided by Tests

Growing Object-Oriented Software, Guided by Tests

Dit is een review van het boek: Growing object-oriented software guided by tests geschreven door Nat pryce en Steve Freeman. Een aantal maanden geleden heb ik al een eerste blog geschreven over een klein detail van dit boek. Voordat ik het boek ging lezen had ik al enige kennis van TDD, maar deze kennis wilde ik graag uitbreiden.

Het boek

Het boek beschijft een manier om met behulp van TDD OO software te ontwikkelen. Binnen het boek wordt hevig gebruik gemaakt van Mock objecten om de ondeliggende code te testen. Ook wordt er gebruik gemaakt van geautomatiseerde acceptance tests. Deze variant van TDD die ook wel de “London school” wordt genoemd is (mede) bedacht door de schrijvers van het boek.

Het boek heeft 5 delen. Deel 1 is een introductie van TDD is en waarom het te gebruiken. Deel 2 beschrijft het TDD proces dat gebruikt wordt in detail. Deel 3 is een groot voorbeeld waar de theorie in de praktijk wordt gebracht. Deel 4 legt uit hoe je kunt zorgen dat je tests onderhoudbaar worden/blijven en tot slot behandelt deel 5 nog een aantal advanced topics.

Deel 1 en 2

Door het lezen van deel 1 en 2 krijg je een goed idee hoe het proces wordt aangepakt als je deze methodiek volgt. Belangrijke concepten:

Het laatste hoofdstuk van deel 2 is interessant omdat daar een aantal redenen wordt gegeven om nieuwe objecten en value types te introduceren. Waarschijnlijk zijn deze wel bekend, maar de opsomming zorgt voor extra houvast.

Redenen om value types te introduceren:

  • breaking out: te complex object vraagt om opsplitsing
  • budding off: een nieuw type om een Domain concept te vangen. Kan slechts 1 field zijn of zelfs geen enkel.
  • bundling up: als het vaak voorkomt dat we een aantal variabelen samen gebruiken kan het nuttig zijn om ze samen te voegen in een nieuw type.

Objecten ontstaan als:

  • breaking out: opsplitsen van te complex object.
  • budding off: nieuwe functionaliteit past niet in het huidige object en vraagt om een nieuwe class.
  • bundling up: als 2 objecten samen werken is het misschien nodig om de objecten in een nieuwe class te bundelen. The composite is simpler than the sum of his parts.

Deel 3

Na het lezen van deel 1 en 2 dacht ik dat ik de materie begreep. Dit bleek echter niet het geval. In deel 3 wordt een voorbeeld uitgewerkt. Dit is in dit geval een “Auction sniper”. Deze auction sniper kan op veilingen bieden tot dat een (ingegeven) maximum bedrag is bereikt. De GUI laat de status van de huidige veilingen zien.

In het voorbeeld wordt er stap voor stap gewerkt naar een volledige applicatie. De schrijvers leggen ook uit waarom ze voor welke stap kiezen. Gedurende Stap voor stap ontstaat een beter design van de applicatie door te luisteren naar de “test smells”. Door het voorbeeld werd mijn inzicht in OO-design in ieder geval vergroot. En ik denk dat TDD helpt bij het verkrijgen van een betere architectuur. (Zie ook mijn eerdere blog hierover.)

Deel 4 en Deel 5

Deel 4 beschrijft hoe slecht design van je applicatie zichtbaar wordt en hoe je jouw (unit)tests onderhoudbaar kan houden. Deel 5 legt uit hoe je persistence frameworks, threaded applicaties en asynchrone code kunt testen.

Conclusie

Als je nog niet ervaren bent in TDD/OO en je wilt meer inzicht verkrijgen is dit een zeer nuttig en praktisch boek om dit te leren. Het is helder en duidelijk geschreven en het voorbeeld geeft groot inzicht. Gedurende het lezen was ik wel af en toe de structuur kwijt van het voorbeeld. Terugbladeren en de schema’s bekijken in het vorige hoofdstuk hielp dan enorm. Graag had ik de schema’s wat vaker zien terugkomen. Het kan er echter ook aan liggen dat ik het boek gedurende een aantal maanden gelezen heb. Als dat binnen een kortere tijdsperiode gedaan wordt verwacht ik dat terugbladeren minder nodig is.

P.S.
Sommigen denken dat je moet kiezen tussen de London school en classic TDD. Jason Gorman heeft daar naar mijn idee een goed antwoord op gegeven. Hij stelt dat ze beide nodig zijn.

Logica Hack-a-thon 2011

IMG_6072

Na het succes van de hack-a-thon vorig jaar besloot Logica om er dit jaar een vervolg aan te geven. Natuurlijk was ondergetekende weer van de partij.

Afgelopen vrijdag en zaterdag hebben ongeveer 20 consultants op een zolderkamertje boven een koetshuis bij Bunnik een HTML 5 game gemaakt die als App (Android en Apple) verpakt kan worden. Ook is het mogelijk om de score te sturen naar een google app engine back-end.

De locatie was inspirerend midden in de natuur. Kudos aan @JasSchouten voor het vinden van deze locatie. Het was net als vorig jaar een fantastische bijeenkomst waar van elkaar leren en fun voorop stonden. Als fotografie nerd had ik natuurlijk weer mijn camera meegenomen. Zie hieronder de (beste) resultaten.

 

Meer foto’s. Bekijk ook de #logicahack.

Je (unit)testcode hoort niet in een ander package

Growing Object-Oriented Software, Guided by Tests

Growing Object-Oriented Software, Guided by Tests

Afgelopen weekend heb ik twee hoofdstukken van het boek Growing Object-Oriented Software, Guided by Tests gelezen. (Rechts is meer informatie te vinden over dit boek.) In een van deze hoofdstukken staat dat het een goede gewoonte is om je testcode in een ander package te zetten dan je productiecode. En daarvoor worden twee redenen gegeven:

  1. Navigeren in je IDE is makkelijker als je testcode gescheiden wordt van je productiecode.
  2. Je wilt eigenlijk alleen de public methoden / interface van je code testen. Door het in een ander package te zetten test je niet per ongeluk op package level.

Allereerst wil ik het over de eerste reden hebben. In principe ben ik het eens met de reden. Ik denk alleen dat er een andere manier is om dit te bereiken. Ik heb altijd de gewoonte om mijn test code in een andere “source folder” te zetten dan mijn productie code waardoor deze scheiding dus gemaakt wordt.

De tweede reden is wat mij betreft niet waar. Ja je wilt zeker de public interface testen. Maar ik vind het handig om ook de packages als “encapsulation” methode te gebruiken. Laat ik dit proberen uit te leggen met een voorbeeld. Het is gebaseerd op hetzelfde voorbeeld als mijn vorige post: het importeren van transacties in mijn administratie. In dit geval gaat het over het importeren van transacties van een specifieke bank.

Ik wil niet dat er in de rest van de code enige kennis heeft van de interne structuur van de code die verantwoordelijk is voor de import. Om deze abstractie apart te houden heb ik een interface gemaakt die de import voor een willekeurige bank kan aanbieden in termen van mijn domein. Met andere woorden gegeven deze bank en deze import file geef me alle transacties.

Wat dat betreft zou je zeggen maak een class en implementeer deze interface. Problem solved. Nu heb ik in mijn vorige post aangegeven dat ik meerdere classes gemaakt heb omdat dit het (import) probleemdomein beter omschrijft. Ik wil niet dat de rest van mijn code toegang heeft tot deze classes. Alleen de publieke interface moet gebruikt worden. Ik gebruik een package om deze classes te omsluiten.

Als ik dan de testcode in een apart package zou zetten kan ik de code alleen via de public interface testen. Dit zou inhouden dat ik testen kan schrijven die lijken op een integratietest. Mijn design zou dan veel minder beïnvloed zijn door de unittesten. Door de unittestcode echter in hetzelfde package (in de test source folder) te zetten was het mogelijk om de code voor de import te testen in veel kleinere stappen. Integratie en/of acceptatietesten kunnen dan de public interface testen om te zien of de eigenlijke public interface een goede “API” is. Dus unittestcode moet wat mij betreft niet in een ander package zitten dan de productiecode, wel in een andere “source folder”.

Older posts Newer posts

© 2018 Mark van Venrooij

Theme by Anders NorenUp ↑