Mark van Venrooij's blog

Tag: agile (Page 1 of 3)

Review: The clean coder

Cover of the clean coder

The clean coder

Last week I finished reading The clean coder written by @unclebobmartin. The book’s subtitle: “A Code of Conduct for Professional Programmers”, summarizes the book quite good.

Throughout the book @unclebobmartin tells about his own experiences during his career. Also he illustrates the points he wants to make with excellent example discussions between (project) managers and developers. These example stories are quite entertaining and make the book easy to read.

The first few chapters discuss how a professional developer behaves as a person. It’s all about managing expectations & making sure that you’re in the right state to do your job. After that some practices that improve the quality of your work are introduced. Examples practices are TDD, testing in general and estimation. The last chapters discuss how to behave in a team. A embarrassing paragraph in these chapters is called “Degrees of failure”. In that part @unclebobmartin basically explains how the education system fails to educate software developers.

It’s a nice book to read and has nice suggestions how software developers can improve their work and become craftsmen. However many of these tips are not new to me. They can be found in the enormous blob of blogs about agile / lean / etc. development. Only the estimation chapter gave me some real new information. Because the book is written in @unclebobmartin’s distinctive style I still recommend the book. The pragmatic programmer is a different league though.

How I learned about customer value

Confidence by h.koppdelaney, on Flickr

Confidence by h.koppdelaney, on Flickr

The article do users change their settings remembered me about a program I wrote as a student. I created a tool to categorize my expenses similar like Yunoo a.k.a. Afas Personal. This was however a local application. Why the heck should you share your finances on the internet? But let me go back to my memory. At the time I started building the application I did a little bit of research if there was this kind of software available. Sure there was, I just thought it didn’t look nice so I build it myself using Swing (I do know better now ;-)). I was just a little bit overconfident and suffered from the NIH syndrome.

Basically the application enabled me to download a file with all my transactions, load it to my program and categorize my expenses. I even created some rule engine like thing to categorize recurring transactions automatically. All these transaction are then shown in a JTable structure. The program also included budgeting, reports, some graphs, etc.

Back then I didn’t like how the information was shown in the transaction overview. There was too much information shown and it was shown in the same order as was used by the import file. So I made this table structure configurable. The configuration made it possible to hide columns and rearrange them. Also I created some ways to edit the configuration and store it into an XML file (it was the common fashion back then). This change resulted in al lot of work. I needed to create file handling & XML parsing code. But the main issue was that I used the UI as the (view) model.

Every transaction had an id which was shown in a column. It was quite easy to create the logic to find the transactions id as long as the id column was shown. If it wasn’t shown however it was not possible to match a row in the table to any transaction stored in the database. This was especially difficult because every other column may or may not be visible. So I created a view model that made is possible to find the transaction corresponding to the data shown in the UI. Because I wasn’t used to writing automated test (as everyone knows a real programmer doesn’t test), it took quite a while to create the model, hook it up to the interface and make it configurable. I think I spent at least some 40-60 hours on this feature. When I was done I was pretty proud as a developer that I was able to create this feature.

As the only customer of the product I wasn’t happy though. Yes the new feature improved my application a bit. But it didn’t help to support the main goal of the application: getting more insight in my expenses. The day I realized this I was pretty disappointed. If I look back now I learned a lot about customer value by making this (classic) mistake. This is also why I keep emphasizing customer value in the Agile/Scrum team I’m part of. By the way I learned a lot more by building this toy project. I still have all the sources of the program & I use it from time to time to experiment with new languages (I have some Scala classes that mimic the original functionality in Java), new practices and new IDE’s. As a software developer I think every other developer should have toy projects to experiment and improve his/her skills and become a craftsman.

Now I’m using an off-the-shelf product to categorize my expenses and make budgets. Sometimes I still have that nagging feeling that I could make a better program than the one I bought. I learned however that if I’m going to build this thing I need to spend a lot of time to have the same capabilities I like in that product and I think I can spend my precious time more effective.

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 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.

– Default functionality available

– 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 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. #geek #work

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

Bij 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.


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.

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.

« Older posts

© 2021 Mark van Venrooij

Theme by Anders NorenUp ↑