Key Lessons from the Specification by Example Course, Day 1

I’m taking part in a course of Specification by Example, lead by Gojko Adzic. Here I want to summarize the key things I’ve learned in the first day of this entertaining and fruitful course thanks to both Gojko and my co-participants.

If you haven’t heard about Specification by Example (SbE) before (really?!), then you need know that its main concern is ensuring that you build the right thing (complimentary to building the thing right), which is achieved by specifying functionality collaboratively with business users, testers, and developers, clarifying and nailing them with key examples, and finally, where it is worth the effort, automating checks of those examples to get not only automated acceptance tests but, more importantly, a “living documentation” of what the system does that never gets out of date. Best to read the key ideas described by Gojko himself or the SbE Wikipedia page.

What Changes When You Deploy More Frequently and Why You Should Do It

This post is inspired by Kent Beck’s excellent talk at JavaZone 2011 titled Software G Forces: The Effects of Acceleration where he describes how the development process, practices and partly the whole organization change and/or have to change as you go from annual to monthly to weekly, daily, hourly deployments. I’d like to summarize some of the points he made and use that as a ground for arguing that more frequent deployments are (in general) better.

I’d highly recommend you to watch his presentation as I will only reproduce parts of it (and as they are out of their original context, they might well not represent exactly what Kent wanted to communicate).

Kent argues that as you deploy more and more frequently, many things have to change including the business side of the software. What is a best practice for one of these speeds becomes an impediment for another one. With more frequent deployments teams have to progress towards the following practices, while leaving some other practices behind:

Most interesting links of May

Recommanded Readings

Acceptance testing / Specification by example:

• Gojko Adzic: Anatomy of a good acceptance test - an example of refactoring a bad acceptance test into a good one – good for learning about pitfalls and how a good one should look like
• Gojko: Top 10 reasons why teams fail with Acceptance Testing – acceptance testing is great and brings lot of value but must not be underestimated; some of the problems are bad collaboration, focusing on “how” instead of “what,” confusing AT with full regression tests. Brief, worth reading.
• Specification by Example: a love story (go directly to the PDF with the story): A nice, made-up story of going from low-level, workflow-based Selenium tests through similar Cucumber ones to true BDD tests describidng clearly what, not how – very well shows the point of specification by example and how it should (and should not) look like

(Enterprise) Java best practices:

•  Clean code, clean logs: 10 brief posts on logging best-practices – nothing really new here for me but in total it is a very good overview that every developer should know
• Make Large Scale Changes Incrementally with Branch By Abstraction – Continuous integration doesn’t work well with branches but as this article shows, you can manage even large-scale refactorings without branches using “branch by abstraction,” an approach reminding me of Fowler’s “strangler application” (an incremental replacement of a legacy system). The idea is: 1. Create an abstraction over the part of code to be changed;  2. Refactor the code to use it; 3. Implement new functionality using the new way / step by step move old functionality too, the abstraction layer delegating either to the new or old implementation … . It may be more work but: 1) your software is always working and deliverable; 2) (side-effect) in the end it will be more decoupled

Git:

• John Wiegley’s Git from the bottom upp (31p, Git 1.5.4.5, PDF) – a useful explanation of the fundamentals of Git, i.e. how it is constructed and how it works, which makes it much easier to understand how to  use it properly (recommended by Pål R.). Reading the The Git Parable first may be a good idea for an easy introduction into the fundamentals, though absolutely not necessary. This document introduces very well the important Git concepts (blob, index, commit, commit names such as branches, reflog) and how they cooperate to provide the rich set of functionality it has. It also explains well the value and usage of rebase. Among others I’ve appreciated the tip to use checkout, branch -m <new-branch> master, branch -D instead of the much more dangerous reset –hard and the tip to use stash / stash apply to create daily backups of your working tree in the reflog (with clearing it with ‘git reflog expire –expire=30.days refs/stash‘ instead of stash clear). Also git diff/log master..[HEAD] for reviewing work done in the current branch and and git diff/log ..master for checking the changes since the last merge/rebase after a fetch are interesting.

Tools:

• The secret power of bookmarklets - bookmarklets are an indispensable tool for every developer who works with web applications (to fill in test data, speed up log in, …), yet I’m sometimes surprised by meeting people who don’t know or use them; this blog explains them nicely, links to some useful ones and some useful tools for building them

Recommended Books

• (*****) Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck, Tom Poppendieck – A great introduction into lean thinking (the values and principles it is build upon), clearly communicated with the help of “war stories”. I absolutely recommend it to anybody interested in lean/agile.
• (**** ) Agile Project Management with Scrum (Microsoft Professional) by Ken Schwaber – Even though you can’t understand Scrum without experiencing it, this book full of war stories will help you to avoid many Scrum implementation pitfalls and to understand its mantra of “the art of the possible” and will show you how to adapt Scrum to various situations. It’s very easy to read thanks to its format of brief case studies organized by topics (team, product owner, …).

Favourite Quotes of the Month

@unclebobmartin: Cleaning code does NOT take time. NOT cleaning code does take time.

Clean Code: Four Simple Design Rules – Obligatory Read

I consider the Clean Code book to be obligatory for every programmer. And if you currently haven’t the time to read it all at once then you should read – and take deep into your heart at least the 12th chapter Emergence by Jeff Langr, which introduces Kent Beck’s Four Simple Design Rules and explains thoroughly what they mean and why they’re so important. The rules, in the order of importance, are:

1. Runs all the tests
2. Contains no duplications
3. Expresses the intent of the programmers
4. Minimizes the number of classes and methods (this isn’t as controversial as it may sound, see below)

Stated like this in simple sentences it’s difficult to see the depth hidden behind them and thus their essential importance for clean, high-quality code with high-quality design and I’ll therefore try to explain what they really mean in the full extent based on Clean Codes. I’ll cite some parts of the book – for I can’t find better words than the author – hoping for the author(s) and publisher graciously permitting it.

Knowing I’m Bad Programmer Makes Me Good Programmer

I know that I’m not a good programmer and this knowledge makes me actually a very good one. As Kent Beck says: “I’m not an excellent programmer, I’m just a good one with excellent habits.” [1] I know I’m a bad (read “a little above average”, if you plan to hire me ) programmer and therefore my code will contain bugs. So I like to write unit tests even before the code itself, and I prefer having the test fail first for thus I’m sure that it works (well, at least in a basic way). Being a bad programmer I also know that my design isn’t perfect and no matter how hard I try it’s very likely that it will need to be changed in the future. I therefore don’t try to account for all possible future changes and to make it so flexible that it could deal with all of them because I know I’d be wrong in this. Instead, I prefer simple designs and well isolated parts of code so that it will be easy to reorganize and refactor them as needed. Last but not least, knowing my weaknesses I appreciate very much when somebody else reviews my design and code and I’m very receptive of different points of view and ideas. For the same reason I do not hesitate to ask my collegues for an opinion or an advice when I’m unsure. (Kent Beck yeasterday twittered: “amazing how fast you can finish if you care more about feedback than avoiding criticism”.)

The net result is that I create a simple, well-tested code open to changes (i.e. easy to change in a safe manner), which is easy to read an understand (for I know that somebody will need to modify it many times, often the somebody being an older myself). And because I’m not afraid to ask, I’ve better and more suitable designs than I could create just by myself. Thus I produce a good, clean code as a good programmer would write.

[1] M. Fowler – Refactoring, page 73 in the Czech translation
[2] R.C. Martin (ed.) – Clean Code: A Handbook of Agile Software Craftsmanship

Jetty-maven-plugin: Running a webapp with a DataSource and security

This post describes how to configure the jetty-maven-plugin and the Jetty servlet container to run a web application that uses a data source and requires users to log in, which are the basic requirements of most web applications. I use Jetty in development because it’s fast and easy to work with.

RAD, WAS 6 Test Env and J2EE security: getting rid of “No received or invocation credential exist on the thread”

Recently I started a new J2EE project that required j2ee security. Unfortunately Rational app. Developer 6 seemed to have some problems running a WAS Test Environment in this way, at least with the default setup. I encountered 2 problems:

1. RAD wasn’t able to connect to the server at all, throwing some security exceptions.
   The solution (or rather work-around) was to switch the “Server connection type..” in the server’s configuration in RAD from RMI to SOAP. It seems that RMI doesn§t support authetification.
2. After that, everything seemed to be ok, but an error was logged every few seconds with the cause “No received or invocation credential exist on the thread“. The stack trace pointed to a MBean (a part of JMX) being contacted via RMI.
   Work-around: Disable an RMIConnector for JMX in WAS Console: log in, go to
   Application servers > server1 > Administration  > Administration Services > JMX connectors
   And delete the RMIConnector – make first sure that you don’t need it.

BTW, to enable the security, I enabled it first on the server via WAS admin console and then I created a new server configuration in RAD and set it to use security.

Stack trace for issue 2:
com.ibm.ws.security.role.RoleBasedAuthorizerImpl.checkAccess(RoleBasedAuthorizerImpl.java(Compiled Code)) at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1696) at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1603) at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1533) at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1506) at com.ibm.ws.management.AdminServiceImpl.getAttribute(AdminServiceImpl.java:501) at com.ibm.ws.management.connector.AdminServiceDelegator.getAttribute(AdminServiceDelegator.java:99) at com.ibm.ws.management.connector.rmi.RMIConnectorService.getAttribute(RMIConnectorService.java:123) at com.ibm.ws.management.connector.rmi._RMIConnectorService_Tie.getAttribute(_RMIConnectorService_Tie.java:193) at com.ibm.ws.management.connector.rmi._RMIConnectorService_Tie._invoke(_RMIConnectorService_Tie.java:87) at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:608) at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:461) at com.ibm.rmi.iiop.ORB.process(ORB.java:432) at com.ibm.CORBA.iiop.ORB.process(ORB.java:1728) at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2229) at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:65) at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:95) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java(Compiled Code)) .