I’ve been lucky enough to have been using Spring for just over 4 years. If you don’t know what Spring is, it solves a lot of problems in complex Enterprise Java Systems. And it makes those systems more configurable; Spring makes your code like Lego blocks. Blocks that you can take apart and use again and again (no matter what the underlying technology is). And because you can take it apart, it makes your code easier to test. And testing is a good thing – the earlier you find bugs , the cheaper they are to fix.
Get the feeling that I’m a bit of a Spring fanatic? Wasn’t always that way. It took me two projects where other people had choosen Spring to convince me. And did I mention that it’s one of the most in demand skills in the Java world?
Rod Johnson (aka ‘Mr Spring’) is speaking in Dublin at the Westin hotel Dublin on the 11st March. It’s fairly central, and it’s a breakfast briefing, so you don’t even to have to arrange the day off work. More details on the event are on the Kainos Website.
Update: The registration form to sign up for the event is here.
In an ideal world, potential customers would read this blog then decide that they want to do business with me.
In the real world many of my customers haven’t heard of a blog, and are quite happy that way thank you very much.
Given that a lot of ‘selling’ to these customers is on a personal level, the fallback is to use the traditional common or garden CV. Which gives rise to the following problems :
- Too Long or Too Short? : How do you get 13 years experience into a document without it looking like a version of ‘war and peace’?
- The curse of the technical buzzword : You need to include the technical buzzwords (Oracle, Java, Agile etc) to show you can do the job (a lot of people just do a 1st scan for words like this). But, put too many in, and you just end up looking silly.
- People or Technical skills: Apparently you can have great technical skills , or great people skills , but not both. How do you stop yourself getting pigeonholed? What about non-traditional experience (e.g. blogging, writting, speaking, training?)
- Customer confidentiality: A lot of the stuff we do is internal to clients. But potential clients need to know what you’ve done to judge your work. Where’s the balance?
You can judge how successful I’ve been here: Paul Browne’s CV online [pdf].
Yes, I’m slightly more available than normal in the coming months. Yes, I’ll consider proposals slightly outside ‘normal’ contracts, if the projects and upside are interesting. And yes , I may just take some time off that I’ve been promising myself (but I’ve said that one before). Email me at PaulB@firstpartners.net.
Note to recruitment agencies: I’m very happy consulting through FirstPartners. No, I don’t want a permanent job. No, Cork is nowhere near Dublin , but I will consider Belfast. No, I don’t believe that you’re in for anything other than the money – that’s ok , you probably have a family to feed; but let’s not waste time pretending otherwise.
I’ve written and presented quite a bit about Agile Project management, but I’ve to recognize that these guys are experts. This PDF is a 90 Page guide to Scrum and XP Project Management, written in a way that both Business and Technical people can understand.
[Link to crisp OO and Java consultants]
It’s clear , it’s honest , and more importantly , it’s not trying to sell you anything (Rational consultants, you know who you are). Ok, they’re not trying to sell you anything , not unless you’re in the market for a bit of OO consultancy in Sweden.
The best thing about doing presentations is the questions you get asked at the end. Apart from the stomach churning moment of ‘will I be able to answer this one?’ they give you a new angle on things that you may have always assumed, but force you to think of in a different way.
Take one of the questions after yesterday’s Enterprise java presentation at DCU. One of the topics mentioned in the final ‘putting it all together’ was the Agile and RUP (or other upfront design) methodologies. The question , coming from an attendee that was keen on using Agile , was ‘How do you do Architecture in an Agile project?’
On the face of it this seems a contradiction. Agile in it’s most extreme form is ‘make up just enough design as you go along’, with automated tests to make sure changing things later is a relatively low cost and pain free process. In real life most projects are a balance between Agile and need some element of a more formal process (often trying to answer the question ‘how mucn is this going to cost?)’
So , how do you merge Agile with an upfront design process? It’s easier than you think.
Most systems built the ‘traditional way’ do not get all their design done in one go. They might start out with the best of intentions for phase 1 with a clean sheet but over the months / years people come and go, business requirements change and different phases try to deliver different things. Over time the original clean design twists and turns and you work hard to try and make it work out ok. Some of features you thought were key may end up getting thrown out as too complicated.
Now Agile architecture is a similar situation. Each weekly / monthly iteration is like phases on the larger project , with twists and turns that may be unexpected. The difference now is that you have a safety net comprised of your (J)Unit tests, to allow you to make radical changes if your blueprint ends up in a cul-de sac.
Yes, it is ok to have an idea the bigger picture and where you like to go with the design. Yes, a good architect will find reasons in the current release to build towards that design. And yes, a good architect may admit that some of the design features he / she thought were required weren’t actually needed. The difference between Agile and Upfront architecture is in when you find your ‘Don’t really need it’ point. With Agile , you find it just before you build it. With upfront design / architecture you find it when it’s already too late.
And the results of the Virtual Java Meetup are … here. Names have been changed to protect the innocent.
If you couldn’t be bothered reading the entire thing , the results of the Dublin Jury on ‘what technologies should I be learning in the next 12 months’ are:
- Web services are going to be big, but only if they can be simple.
- EJB 3 and Netbeans are both worth taking a look at again, they are now much better than the previous versions that gave them a bad name.
- Middleware (e.g. workflow and Rules Engines) are interesting in a corporate environment, but there is a high barrier to entry.
- Struts , and to a lesser extent JSF , will continue to be dominant Java Web frameworks, despite not being the best technical choice.
- A lot of companies are still using Java 1.4, but may make the leap to Java 6 (Mustang).
- Service Orientated Architecuture (SOA) is a nice idea, but not so many projects have been implemented using it.
- IDE’s (Netbeans / Eclipse / JDeveloper) can deliver a lot of value, but only if backed up by lower level tools (e.g. Ant and Maven).
- More for the next 24 months , keep an eye on Apache Service Mix.
It’s pretty ironic , given that I’ve already stood up and did a presentation on the topic to the INDA, but today we have a UCD exam in Agile Project Management.
In perhaps the worlds first use of a blog as an exam revision technique, here are the main features of Agile projects:
- Working Software over Comprehensive documentation
- Customer interaction over Contract negociation
- Responding to change over following a plan
- Individuals and interactions over processes and tools.
In the meantime , if you don’t have an exam this morning , check out the NoUnit Agile tool that we build and maintain.
If you’re very observant , you might notice that this post is about a week late. Still , here are my notes on the slides / nodes from the final day of the Agile course.
Previous Posts from the training course are:
Framework for writing automated unit tests (don’t need to use Junit
to write the tests , but it helps)
tests extend TestCase
test methods (pre Junit 4.0) : public void testSomething() method
assertEquals assertTrue assertFalse assertNull assertNotNull
assertSame and fail methods for testing.
tearDown() methods called before and after each test method.
(groups of TestCases) replaced by Ant and (Eclipse) IDE
Run tests via
built in Text / Swing test running , or more likely use IDE / Ant
same or paralell folders
Mock and Stubs
classes (Collaborating Objects) can be tightly bound to system
resources (e.g. File or Database) or to a hard to test API. Another
example is the observer pattern. How do we unit test these?
fake object , pass it to class under test , allows testing of the
class at a unit level.
Stub : fake
object that uses hard-coded data , often following an API. Many
ready made stubs available (e.g. For the JDBC libraries).
expensive to create objects
create all objects that production code interacts with.
middle and develop outwards
can ripple out / appear elsewhere.
Dummy: type of stub that deliberately fails in order to test
exception handling – simulate database crash or I/O full.
Self Shunt is
where the unit test itself implements the interface (doesn’t work
for classes) and gets callbacks from the class under test.
like stubs, except that they are intelligent enought to self-verify.
Secondary objects (normally ones that we build) instead of API (as
What if mock
implementation is incorrect?
Interaction vs. State: In
state-based testing you check the tests by examining the state after
the stimulus. In interaction based testing you check the right
interactions were triggered by the stimulus – Martijn
tend to test more the interaction between objects rather than a unit
test of the object itself.
than mock external API’s
Smells and refactoring.
are bad or suspect design decisions in code.
bad , but should be looked at (often will involve a trade off)
often hard to understand , hard to change code.
Small , controlled changes to codebase , so that it continues to
compile / tests run to improve the design. The behaviour remains
exactly the same.
refactoring and adding additional functionality.
automated tools and Unit tests to confirm that nothing has broken.
!= Rewrite. Codebase is evolved , not thrown away.
In some ways
, equivalent to Use Case from Predictive methods (but with subtle
chunk of functionality that makes sense to the customer.
represented as card / conversation / paper based documents (more
In Agile (as
opposed to predictive) , shift the focus from writing to talking
i.e. Get a true understanding of what the customer wants , even if
they haven’t expressed it very well.
importance of requirements
iterative development and participatory design.
Even a simple
requirement has many possible permutations (that lessen the odds of
getting it right.
Not just a
generic user – but more user roles – groups of users that do
different things with the system , depending on their experience ,
task at hand etc
should be Invest:
(FlashCard , as used by Xplanner)
Be careful of
too big and
cannot be used for estimated (break these down into smaller
stories). Easy for Compound , but for complex stories might need to
do some research and then break out.
Too small ,
and it is not worth the admin of estimating each. Bundle them up
into higher level task like UI improvements or bug fixes.
should give us the acceptance tests