Mark van Venrooij

Mark van Venrooij's blog

Category: featured (page 2 of 2)

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

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.

TDD is a design technique

Die zehnte Design // My Oh My by principia aesthetica, on Flickr

Die zehnte Design // My Oh My by principia aesthetica, on Flickr

When I read Mark Seemann’s blog post stating “TDD is not a design technique” I agreed. Now I don’t anymore. Let me tell you why.

During Christmas I was writing some code with TDD. (Yeah I know I should socialize with my friends and family, but they were just like most other people still asleep around 6 am.) The codebase basically tracks my finances. I can import my bank transactions and categorize them. I wrote the first version of this program some years ago until I found that paying for a working solution is a lot easier. Since then I use the program for experimenting with new techniques, tools and programming languages.

This time I was trying to find out how the new IntelliJ IDEA worked for me while using TDD. To get a real life example I decided to (re)write the import functionality for my finances application. The banks import format is basically a text-file containing fixed length records with my transaction information. The real difficult herein lies in the fact that a transaction is splitted in 2, 3 or 4 lines in the input file. This depends on the length of the description associated with it.

Two sample transactions in file:

The old code used a single class with a 200 line method, which extracts every variable needed to construct a list of transactions. This worked and there was a test available to validate the results. But I couldn’t understand the code anymore. Using some mysterious/magical constructions I managed to get it done. A particularly good example of this so called magic was that I actually fast forwarded a few lines within the loop that was iterating over all the lines.

I decided to rewrite the code using TDD. Since I wrote the first version of the parser some years ago, I did not have a clue about the import format. However I did have a sample file and the file specification. Hence it was relatively easy to write some tests. I started to write tests which determined whether the variables were parsed correctly. So the first tested whether I could retrieve the account number correctly. Then I created the code to make the test pass. The next test checked retrieving the amount and so on. All the information could be found in the first line of a single transaction in the file.

Finally I came to the difficult part of the file. In the best case the description can be found in the second line of a single transaction. In the worst case it is splitted across line 2,3 and 4. To make it more difficult the description is at different positions in the line depending on the type of the line. There were three line types: Line 1 is always of type 1, line two is of type 2, and line 3 and 4 are type 3. Writing some tests per type made it a lot easier for me to eventually retrieve the complete description of the transaction. Along the way I created three classes resembling the line type and encapsulating the problems per line. The new code design was much better than the old code design was.

TDD-ing through the code made it possible for me to do everything step by step.  With each step I understood more of the actual problem domain. Together with the ability to refactor the code quite easily without being afraid that the code correctness was going to be compromised, I was able to get a better design. This design resembled the problem domain much closer than my old code did. For me this is all related to TDD. So I’m sorry I have to disagree with Mark Seemann. TDD is a design technique, maybe not directly but it does enable you to create better designs.

P.S. This is my first blog post in English. This is because it was a reaction to an English blog. As I’m not a native English speaker it is possible that there are some grammar/spelling mistakes. Please leave a reaction with the correct spelling if you find a mistake.

Meten is weten, maar wat moeten we meten

Spreadsheet

Spreadsheet

Mij valt het op dat steeds meer mensen managen by Excel sheet. Dus puur naar de nummertjes kijken. Einstein zei daarover:

“Not everything that can be counted counts and not everything that counts can be counted.”

Ook ik merk het bij mezelf dat ik enorm gefascineerd wordt door getallen en de verandering erin. Ik heb mijn eigen kasboek en controleer waar ik mijn geld aan uitgeef. Ik meet mijn hartslag in de sportschool en probeer zo tot de ideale training te komen. Ook wil ik voortgang zien als ik aan de gewichten hang. Ik denk dat ik nog wel een aantal voorbeelden kan vinden m.b.t. het meten en analyseren van getallen.

Op dit moment worden bedrijven gemanaged op de financiële cijfers. Is er genoeg omzet is er genoeg winst en zijn onze kosten niet te hoog. Deze vragen zijn natuurlijk belangrijk voor bedrijven. Zeker op de korte termijn. Andere zaken die belangrijk zijn, zijn vaak vager en moeilijker te meten. Zo is er medewerkertevredenheid, aandacht voor milieu en samenleving. Ondertussen is het wel gemeengoed geworden om deze aspecten ook te noemen in de jaarverslagen, maar de vraag blijft of er echt gemanaged wordt op deze waarden.

Sinds jaar en dag wordt de status van landen in de wereld gemeten in de vorm van het bruto binnenlands product (Gross Domestic Product of GDP in het Engels). Ook is de groei van dit product heel belangrijk. Want de algemene opinie lijkt te zijn dat welvaart 1 op 1 gekoppeld is aan het BBP. Maar zoals Robert Kennedy al meer dan 40 jaar geleden zei:

“If we believe that we, as Americans, are bound together by a common concern for each other, then an urgent national priority is upon us. We must begin to end the disgrace of this other America. And this is one of the great tasks of leadership for us, as individuals and citizens this year. But even if we act to erase material poverty, there is another greater task; it is to confront the poverty of satisfaction – purpose and dignity – that afflicts us all. Too much and for too long, we seemed to have surrendered personal excellence and community values in the mere accumulation of material things. Our Gross National Product, now, is over $800 billion dollars a year, but that Gross National Product – if we judge the United States of America by that – that Gross National Product counts air pollution and cigarette advertising, and ambulances to clear our highways of carnage. It counts special locks for our doors and the jails for the people who break them. It counts the destruction of the redwood and the loss of our natural wonder in chaotic sprawl. It counts napalm and counts nuclear warheads and armored cars for the police to fight the riots in our cities. It counts Whitman’s rifle and Speck’s knife, and the television programs which glorify violence in order to sell toys to our children.

Yet the gross national product does not allow for the health of our children, the quality of their education or the joy of their play. It does not include the beauty of our poetry or the strength of our marriages, the intelligence of our public debate or the integrity of our public officials. It measures neither our wit nor our courage, neither our wisdom nor our learning, neither our compassion nor our devotion to our country, it measures everything in short, except that which makes life worthwhile. And it can tell us everything about America except why we are proud that we are Americans.”

Naar mijn mening zullen we nooit zonder een meetinstrument kunnen. Dan moeten we de meetinstrumenten maar aanpassen zodat ook de dingen gemeten worden die nu niet in het BBP zitten. De overheid van het bergstaatje Bhutan baseert zijn beslissingen op grond van het bruto nationaal geluk (Gross Domestic Happiness of GDH in Engels). Deze laatste maatstaf begint steeds meer weerklank te krijgen in de internationale politiek. Althans het begint ook een factor te worden die meeweegt in beslissingen. Sarkozy in Frankrijk gebruikt het en David Cameron in Groot-Brittannië vindt het BBP alleen niet voldoende.

Hetzelfde geldt natuurlijk voor bedrijven. Ook daar moet niet alleen naar de financiële cijfers gekeken worden. Op het moment dat de medewerkers meer tevreden zijn dan stijgen de prestaties van een bedrijf ook. Een voorbeeld hiervan is Jumbo. Bij Jumbo gaat medewerkertevredenheid, klanttevredenheid en financiële waarde hand in hand.

Ook in het persoonlijke leven moet er verder gekeken worden dan alleen je inkomen. Vaak wordt je succes beoordeeld op je het huis dat je hebt, de auto is een goede tweede. Maar het succes van je leven zit ook in andere en soms de kleine dingen. Het meest schaarse goed in deze wereld is de tijd die je hebt. Besteed deze tijd dus zo goed mogelijk. Managen met een Excel sheet haatte ik, tenminste dat heb ik een aantal weken geleden gezegd. Maar ik denk dat op zich het managen per spreadsheet niet het probleem is, maar wel de getallen die in die spreadsheet staan.

Newer posts

© 2018 Mark van Venrooij

Theme by Anders NorenUp ↑