Mark van Venrooij

Mark van Venrooij's blog

Tag: Craftsmanship (page 2 of 4)

Developer certificates are similar to triple A ratings

 

Coin Operated by xcode, on Flickr

Maybe it is a far-fetched comparison but to me developer certificates (e.g. the Sun Java Certified Programmer) are quite similar to the triple A ratings issued by companies like S&P. Let me try to explain why I think they are similar.

Basically a rating or certification agency does some quality checks for you. Banks are outsourcing the risk assessment of certain financial products to the rating agencies. I think banks should always check the risks of the product they are buying themselves. Software companies use the developer certificates to outsource the quality checking of a (potential) new employee. And if I was the person who was hiring people I wouldn’t even think about outsourcing this pre-employment check.

By outsourcing these checks we explicitly trust trust the companies providing the service. Initially this makes sense, especially when you are an HR person who doesn’t know the details about the job a potential employee has to do. The problem however is that the certification agency benefits most if they check as many people as possible with the least possible effort. Also a developer pays for his certification resulting in the situation that the developer is the main customer of the certificate authority. I don’t think we should trust the agencies blindly. This is of course similar to the situation of the rating agencies (like discussed after the USA downgrade by S&P).

So are certificates useful? I agree with Martin Fowler’s article: CertificationCompetenceCorrelation. Bottom line: He hasn’t found a correlation between certification and competence, but it may have a economic value for the developer.

 

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.

Older posts Newer posts

© 2018 Mark van Venrooij

Theme by Anders NorenUp ↑