in the first part of the talk, Mike introduces Dependency Injection and explains how to apply that pattern in practice with Castle Windsor. Then he talks about Castle component lifestyles and implementing common architectural and design patterns using Castle Windsor component model. In the second part of the talk, I present strategies how to manage component configuration effectively for production. After that, I explain how to use Castle facilities to extend the framework, integrate third-party services and manage components easier.

download the slides and the source code from the talk.

I would like to know if we could used a Fitnesse page as a template.

We all know that Fitnesse offers ColumnFixture which allows us to make a loop within a wiki page. I understand that with a ColumnFixture, we could not run anything other than methods defined in that ColumnFixture. So if i need to run a test scenario over a set of parameters, i need to create a ColumnFixture, build a method which do all the work of the mentioned
test scenario, then put the ColumnFixture on wiki page….

The biggest disadvantages is that we have to develop something (the development curve could be expensive if the test scenario is rather complex) for each test scenario. Any way, this advantage will be overcome if we have ability to use a wiki page as template. Here is detailed description of using wiki page as template:

1. Build a simple Column Fixture encapsulating all parameters used in a test scenario *and* the absolute path of the page representing a single test scenario

2. Put the ColumnFixture in a third Fitnesse test page, with tuples of parameters in rows  *and *the absolute path to test scenario page in question

3.Click on the ‘Test’ button, then the wiki engine will run over all the table rows. For each row, tuple of parameters would be inserted into the template page specified by the absolute path. Then the filled template page would be executed as a normal Test page

4. The final test result will be collection of all..

There are several ways you can do this with FitNesse, including Markup Variables and Parameterised includes, but the problem here is not how to do that, but why do you want to do it at all. Posing this questions seems to suggest that you are building scripts rather than a specification with Fitnesse. This is a very bad practice and it is going to cost you a lot on the long run.

Reusing fixture code or fixture tables is not something you should be concerned about if you are using FitNesse properly. FitNesse is not a general purpose test automation tool. It is not designed to be a test automation tool, it is designed to work with acceptance tests or executable specifications that are worked out together by the business, testers and developers. Such acceptance tests can and should be used for regression testing later, but FitNesse is not a general-purpose test tool. There are much better tools for that, and if you need UI automation testing, use one of such tools.

FitNesse is a very good tool for executable specifications. In order for executable specifications to be effective, they have to be easy to read and understand and they have to explain the system from the appropriate level of abstraction. Otherwise they are unusable as a target for development and they will be a pain to maintain, especially because code refactoring does not propagate to test pages. Having templates and complex scripts does not fall under the “easy to understand” category. Looking at things from the proper level of abstraction means grouping related rules and explaining them so that there is very little which really needs to be reused across different specifications.

You should encapsulate the script (your template) in fixture code, and then use the table with parameters and results in the fitnesse page connecting to that fixture to specify inputs and outputs. This difference between the script (how) and specification (what) is the key to successful application of acceptance testing. Details of scripts and their complexity should be put into fixtures (and don’t force yourself to use the ColumnFixture, take a look at the fixture gallery and see which fixture type is closest to what you want to achieve). FitNesse tables should just provide inputs and expected outputs for entire scenarios, not dealing with individual workflow steps. Tests like that will be much easier to understand and maintain. Changes in code will be propagated to fixture code, so you will not suffer from high maintenance costs. David Peterson gives a very good example of the difference between Scripting and Specification on Concordion Technique page. The ideas described there are applicable to FitNesse as well.

Some testers complain that this requires developers to help them with writing fixtures. If you do not work together with developers, then you are not doing agile acceptance testing properly and there is no chance that the whole thing will actually work. So not having developers on board is a much larger problem than the one of writing fixtures to automate your tests. Again, this may signal that you are not using FitNesse for agile acceptance testing but just for test automation, and there are much better tools for that. Use the right tool for the job, don’t treat FitNesse (or anything else) as the silver bullet that solves all problems.

The explanation for the idea is that everyone on the team knows who the worst programmer is, so senior developers are closely monitoring everything that he does and cleaning up problems. The work of the second worst programmer is not monitored with that attention so he has the chance to do some real damage.

Although the story was intended as a joke, it is not completely without merit. Of course, just watching that person as well is not going to solve the problem. The moral of the story is, I think, that code and design reviews need to be done periodically. Most teams I’ve worked with in the past don’t take code reviews seriously, but that is one of the key practices to prevent problems and should not be skipped. Pair programming helps a lot since at least two people are working on the same task, but it still does not protect against problematic code (especially if the worst and the second worst guy pair up).

Drawing a parallel between writing and coding, proof-readers and copy-editors play a crucial role in any magazine or publishing company. They look at the stuff that you have written, identify and sort out (or suggest sorting out) language and grammar issues and look out for stuff that is expressed overly complicated and should be made more clear. An impartial view on the stuff that an author has written often helps a lot to make his text easier to understand and read.

Code reviews matter. Do them often, read code that other people wrote and get them to read your code. Step back for a moment and switch to reading mode rather than writing and check if the stuff can be written simpler or better. Even with the best intentions, people sometimes get blind to unnecessary complexity that they wrote themselves and an objective opinion of another developer can help a lot to sort things like that out. And of course, they might spot things that you have missed while writing the code, intercept bugs and suggest additional unit tests to check potential problems.

Image credits: Jenny Rollo

The audience voted by raising coloured cards. A green card signaled that a particular issue was not really hurting the voter, a yellow card signaled that it hurts a bit and a red card meant that the issue was a serious problem.

Here are the things that Kniberg talked about:

1. Believing the hype (mostly yellow cards)
   • belief in magic — “all the problems will magically go away when we install XP 1.0”
   • not willing to change — “trying to chop the tree with a chainsaw”
   • throwing out stuff that works
   • focusing too much on process perfection
   • trying to get it all right from start
   • blaming the messenger — scrum flushes out problems in the open
   • tool focus —”let’s buy the biggest most expensive XP tool”
   • focusing on the wrong issues (should we use postits or index cards)
2. Definition of done (mostly yellow and red cards)
   • not having one
   • not obeyng it
   • it’s outside the teams control (in production, but team has no access to it)
3. Velocity issues (mixed – yellow, green and red)
   • it’s not known
   • it’s not used
   • is misused (connected to salary)
   • death marches
   • cheating
   • yo-yo velocity — bugs leaking into other iterations
4. Retrospective problems (mixed – yellow, green and red)
   • doesn’t happen
   • doesn’t result in concrete improvements
   • changes not executed and evaluated
   • unwanted people in the meeting – team not open
   • team members or product owner not participating
   • team is penalised for bad changes
5. Team commitment issues (more red than anything else, but mostly yellow)
   • team is pressured – deadlines, death marches, aggressive managers
   • team is not sitting together
   • team does not track and learn
   • always under-committing
   • always over-committing
   • velocity=0 —nothing actually delivered to the end
   • no slack
6. Technical debt (mostly red)
   • letting it pile up
   • ignoring it
   • fixing the product but not the process
   • big bang rewrites
7. Teamwork issues (yellow-red)
   • fixed roles — “I don’t touch your stuff ever”
   • personal backlogs
   • people not helping each other
   • personal incentive models
   • implementing all stories in parallel
   • management interference
8. Product backlog and product owner/customer issues (mostly red cards)
   • not having a backlog
   • having backlog but not visible
   • big or never-ending stories
   • product owner does not have power or domain knowledge
   • multiple, conflicting product owners
   • product backlog not being maintained
   • product owner surprised at sprint demo
   • product owner is a bottleneck
   • product owner not prioritising
9. Mergofobia — merging is a pain and therefore we do it as seldom as possible (mixed colours)
   • no “done” branch
   • no branch policies — purpose of each branch not clearly defined
   • not integrating early and often
   • not taking responsibility
   • hiding behind branches — “whenever we have a problem, we add a new branch”
10. Sprint backlog/taskboard (relatively mixed, mostly yellow)
    • does not exist
    • too far from the team
    • too complicated — “too many columns”
    • not used during daily scrum
    • not owned by he team — tool or way of maintenance imposed from above
    • no burndowns
    • not updated daily
    • warning signes ignored

From the votes, it looks like technical debt and product backlog and product owner/customer issues are the biggest problems for most teams

An interesting thing happened at the start of the talk, when Kniberg asked the audience to vote on “this conference is too big”, with most people raising red cards. From what I can work out, at any time there are at least 30 sessions running concurrently and it is often a challenge to select a single session to attend.

I use WordPress for my blog, and so far I am relatively satisfied with it. As a very popular online software package, it does get attacked a lot and security updates are released every once in a while. My site was hacked last year and the bastards dumped a bunch of hidden porn site links in about twenty articles, which took me a few days to clear up. So I learned the hard way that when the admin console suggests an upgrade, I should take its advice. I also added a cron task to check for a few keywords in the database and alert me if someone starts advertising limb enlargement devices for free, and since then I had no real problems. That is, until my site became a hot spot for south-east Asian smut aficionados overnight.

My first guess was that someone was simply spamming me with fake referrer headers, since there was absolutely no reason why my web site would actually appear in Google’s search results for adult movies, Korean or with a different geographic origin. Web sites use request referrer headers to identify where the visitors are coming from. A web browser will send the address of the site where you click on a link to the linked web site, if you have not turned that off. It is not a 100% reliable mechanism to identify visitor sources, as some people turn that feature off and some browsers have bugs and send rubbish, but in general it works OK. With the recent surge in the number of blogs, a new kind of spamming started to take place online. Spammers send fake requests to web sites, putting the address of the web site they are advertising into the referrer header. The rationale behind it is, I guess, to make the site owners to click on the referrer link to see who is sending people to their web site.

But there were quite a few of those requests, much more than with typical spam. The visitors were led to the search web page, and did not look at any other page after that, which could be explained by the fact that they were probably disappointed to find only clips of an ugly bald guy talking about agile acceptance testing instead of their favourite underground adult stars. However, with the web page they downloaded images, css and javascript files, which spammers typically don’t do. I did not know which article actually brought the unexpected guests since only the search page was affected. The database lookup did not help either — luckily this time it seemed that the site was not hacked.

I tried out the query on Google, just for fun, to be absolutely amazed that my site was the third on the list. Sure enough, my search page was there. I simply had to click on that to see what happens, and a few seconds later I was looking at a spam web site. My web logs showed a hit from Google again, but I was not looking at my site. Clicking on the “cached” link on Google led to the same outcome. I grabbed the page using wget, which definitely would not jump out directly, and there I found the words “korean underground adult movies”, but only after the “There are no results for…” phrase. More interesting, after that, there was a HTML image tag with “-1.com” as the source, and an onError event redirecting people to the spam web site. When the page loaded, the browser could not find -1.com to load the picture, and fired the onError event, sending the visitors from my web site to some place they could probably watch something more to their liking. Not a bad trick at all!

God knows how they got Google to index my web page with both their keywords and the redirection tag as a search phrase, but they did. And it’s not only my blog, there’s a few thousand other sites with the same problem. Search on google for “onerror freeimagew” to see them. The results containing </title> in the site name will probably redirect you automatically to the spam site.

The problem was that my blog just dumped out whatever people put into the search form when it could not find any relevant posts. The input string was properly sanitised before it was sent to the database, and WordPress generally cleans up all user submitted comments from hostile content, but it looks like they did not think of someone using the search form to hack the web site. In any case, I just changed the theme search.php file to print “Sorry, no posts matched your criteria” when there are no results, and that fixed the problem. A proper solution would be to strip out HTML tags from the search but I was too lazy to look for all the places where the phrase could be set.

In any case, this is one more example how important it is to filter and sanitise everything put in by web site users, regardless of how safe it may seem, and never ever printing it back on the web site without checking for potential problems.

Image credits: Sonja Gjenero