I was in my car talking over a really bad connection. At the far end was Steve Denning, a renowned author of several books on management. He wanted to know how we work at Jayway. During a long interview, interrupted by countless GSM holes, we kept talking. Among other things I told him the story of our old house – a school from 1928. It is a good example of a renovation that had gone wild and how we managed to get on track again. It ended up in Steve's new book which came out last fall, "The Leader's Guide to Radical Management" (http://amzn.to/radicalmanagement). It is a great book and a funny thing happened while I was reading it: I took notes in the margin. That has not happened in the last twenty years, basically back in university. Denning's book really made me think. I just had to scribble and make comments.

Shortly after the interview I got the transcript – boy was that a sorry sight. Not only did the bad connection play tricks, my half-finished sentences and fuzzy thoughts made the text almost incomprehensible. Therefore, I was thoroughly impressed when I got the following text from Steve Denning's latest book. It was spot on.

"The Leader's Guide to Radical Management"
CHAPTER 7— PRINCIPLE #4: DELIVERING VALUE TO CLIENTS IN EACH ITERATION
…
Björn Granvik lives in Malmö, a small town in the southern tip of Sweden. At work, he is the chief technology officer of a software firm called Jayway. In the evenings and weekends, he works on renovating the house that he occupies with his wife and three children. The house used to be a school and so it is rather large, but doesn't have many rooms. Transforming it into a livable house requires a massive effort.

When he started the renovations, his wife would stand in the corner in one of the rooms, and she would say, "Björn, here's something over here that doesn't work."

And Granvik would run over and start trying to fix it.

But then he would hear her from somewhere else in the house and she would shout, "Here's something even worse." And he would leave whatever he was doing and go over and try to fix that. So he kept running between projects in the house. There was so much to do that he was constantly jumping from one project to the other, hardly ever finishing anything. So one day he said to his wife, "This doesn't work. We can't go on like this."

Granvik had encountered a phantom work jam! Too many inputs had jammed the system.

Given Granvik's experience with the practices of radical management and the simplicity of the situation, the solution was fairly obvious.

"I know that there are a bunch of things to do," he told his wife. "But we need to do them in some kind of order."

So he cleared a space on the door of the fridge, and he said that they would have three available slots. There would be one slot for all the big things that needed to be done—things that take a lot of time like fixing the leak in the roof—and two slots for small items, something that would take less than an hour to do, for which he could squeeze in an hour here or there. That might be like: "Hang ten photographs on the wall."

"Anything we put on these slots," he said, "we can talk about. And we can get them going. I will concentrate on these three things. If something else comes up, we can put it on the side of the fridge, but I will not look at it. There's no point in talking to me about this, because although I will listen, I won't do anything about it. I will only work on the top priority items in the three slots on the fridge."

So he and his wife began working this way. And it went really well. He was happy because his wife stopped bugging him about things that weren't on the priority list. And she was happy because things that she really wanted done were actually getting done.

The interesting thing was: it turned out that his client—his wife—was equally happy if he hung ten photos, or if he fixed the leak in the roof. Fixing the leak in the roof is a big expensive project that takes considerable time and effort. But the amount of joy that comes from it was no bigger than a tiny task like hanging the ten photos.

By focusing on what his client really wanted at that particular moment, he found that increasing client delight didn't necessarily cost more. A small thing delivered sooner could delight more than a big thing delivered later.

In order to become more productive, and generate more delight for his wife, Granvik had to restrict the flow of work. To go faster, he had to go slower.

Steve Denning goes on to talk about "phantom jam work" and the havoc it plays on our efforts. Doing too much at the same time invariably leads to less being accomplished. It certainly does not feel like it. Putting in the hours makes us count the effort and not the actual value we create. Just like tunnel vision, we are blinded by speed and forget that we are not reaching any goals.

Whenever you are stuck in effort blindness, stop and think.
- Am I really doing the right thing, the right way – is this value? Is it fun?
In my case I needed something that would focus our effort. Something to slow us down and get stuff done, really done. "The big and small list" was my solution of getting a good flow through my org… err, family.

Works for big people
So how did we do it?

Figure 1: Our fridge and the simple task board with a "small" (lilla) and "big" (STORA) list. Big stuff is "lift roof and fix it", small might be "hang photo on wall". Second from the left at top is the "build room" note (Bygga rum).

The first important step was to reduce the number of things going on at the same time. The lists are each limited to "3 notes". This meant nothing could be introduced or worked on before there was a vacant slot in one of the lists. In order for this to work we have to prioritize the work. It is of no use if I go off on a fixing spree if it is not what both my wife and me needs or wishes.

Separating the small stuff into their own lists, or "swim lanes", was the next step. As a parent I usually can squeeze in the 1 hour tasks somewhere into my calendar. Getting those smaller tasks done is an easy way to turn around a bad situation. It was baby-sized steps, as compared to the big list stuff, but at least it was a step forward. And remember, sometimes even small values are big wins.

Works for tweens
As Steve Denning writes in his book, we actually started to land projects, small and big. My wife was happy again, but my oldest son Max started to talk about the rooms I had promised him and his younger brother Felix. Since we live in an old school we have rather large rooms and no wardrobes. By Swedish standards we are apparently defined as "cramped living" (Swedish "trångbodd"). The statistics have us as living in a "small" house since our three sons shared a single bedroom. This is no small feat in the 360 m2 (3 800 square feet) that make up our ex-school.

My oldest son, Max, kept asking me (in a nice way) about his room. Being 12 years old, I could understand him. He wanted a room of his own. I recognized the earlier situation with my wife and yet again our fridge came to our rescue. This time around I made some more slots available - I needed to size up to include my sons. I explained why the "leak in roof" note came before "Build Max & Felix Room". This worked really fine because it was now understandable and transparent to Max why he would have to wait. Moreover, our kids needed to be better included in the decision process. Roughly once per week we visit the fridge and check the progress. If there are any vacant slots open we discuss what needs to be done - both fun and important stuff get their chance. And of course, we constantly check to see if we have the right prio - something might have come up that needs to "push through" the other tasks.

In the spur of the moment I took a pen and asked Max for commitment.
- You could help, I explained. What do you want to do?
He took the pen and to my surprise he signed off on one of the jobs before his own room note. Despite being young he understood that helping me with some other task would make us as a team work faster on accomplishing his goal. Sure enough, when I came home one afternoon I found a big hole in the garden for one of our roses that my wife wanted to plant. It might not sound all that much, but digging through those layers of ice age clay leaves even a grown man panting.

Works for small people
My second son, Felix (8) saw and understood the fridge. One morning I came down and saw that one empty slot now had a new note scribbled with a child's hand: "go bovling". A couple of weeks later we did just that.

In order to get a sense of flow with the big tasks I introduced a "scratch". Every man-day, roughly, was a scratch on a big note. Otherwise, they risked going stale - staying on the fridge "forever". It also meant we got a counter and a "reward". The quotes are needed, since a scratch is such a small reward, but none the less it works.

At this time we had introduced red notes. They were important high prio tasks that needed to be executed quickly, basically to push ahead of the ordinary yellow notes. This risked blocking out the fun stuff. Where is the R & R, if we just kept doing good? My solution was to introduce the green notes. It is a just such a natural color to indicate fun

Figure 2: The "before" image of the rooms.

Close to a year later, me and my children have finally built the rooms for Max and Felix.

All it took was: some 2,5 metric tons of building material, 97 man days of work (yes, I counted) and the ability to focus – all visible on our fridge.

Sometimes I even managed to find some work that was easy, but still important, for Bix (4). We were working on the roof/floor above the rooms and Bix had the important task of bending the floor boards. Boy, was he proud. All it took was some creativity in dividing the work.

Having a simple, visible system with understandable rules promotes transparency and understanding. As a parent this translates into less nagging.

Final thoughts

If you find yourself working really hard and being quite busy, without any real results to show – except for sweat – then stop and think. It will feel contradictory, but you need to limit your work so you can focus on getting something worthwhile done. Add some transparency and a shared prioritization and you get commitment. It doesn't really matter if the people around you are colleagues or kids. We are all pretty much wired the same way.

Having learnt all of this, I'm I immune? Or will I repeat my mistakes and try to do too much at the same time? Most likely the latter.

The experience might make me quicker seeing a solution, but it's still hard to convince myself - and others - that we need to do less in order to do more.

Figure 3: Max and Felix rooms.

Am I proud of what we accomplished? You bet.

//Björn
Originally published at Björn Granvik's Blog - Tumblelight.

The folks on the stage were:
James Bach - Author of Lessons Learned in Software Testing
Ola Bini - Thoughtworker, core developer of JRuby and creator of Ioke
Stu Halloway - Author of Programming Clojure
Scott Hanselman - Principal Programmer at MS and general spreader of good info for developers
Oren Eini (Ayende Rahien) - NHibernate Profiler, NHibernate, Castle, Rhino Mocks
Chris Hughes - AT&T iPhone Hacker

Scott Hanselman did a great job of setting up a live feed together with the Øredev people.
Here's a good page from Scott, http://bit.ly/3C2UIi, on the event with video and everything.

Oh, and the non-computer related books that the panel recommended:
* The Gathering Storm (12th book of The Wheel Of Time) - Neil Jordan
* Anathem - Neal Stephenson +1
* Gödel Escher Bach - Douglas Hofstadter
* Replay - Ken Grimwood
* Flow - Mihaly Csikszentmihaly

Thanks guys!
/Björn

After that we broke up into separate groups for discussion. There were many good questions and I wished I've had more time on hand. Anyway, thanks to the those who attended and for your great feedback.

The first part of this series can be found here: Scrum Shock Therapy, Part 1.

The Management Recipe

The checklist above is only a part of what it takes to go through Shock Therapy. I often find myself at new companies and need to work with a bigger picture than focusing solely on the team. As is evident from the polls and surveys above, we need to address management as well. The word shock is perhaps more applicable here. If it has learnt anything from the past it is that you have to "drive" development - delegate, follow up, check, adjust, hand out, recheck...
Telling them to trust the very group that has not delivered before is asking for a leap of faith.

Setting up a recipe for this group is tricky. You have to adapt to management style, the corporate culture and so forth and the things you ask for are softer. These can be very hard indeed to change! In plain English; The management has to take some more real tough decisions for a Scrum to work efficiently. If you need to kill a document standard or process step then do so! If this is impossible (for now) then go for "barely enough".

The Management

• Attend the Scrum training session with everyone else
• Hands off during 3 iterations
• Attend:
• Some Daily Scrums - be quiet
• All Sprint Reviews
• Start to work on waste - now!
• Management by walking, asking and listening, i.e. practice facilitation.
• Make the first step easy for the team
• ...

When learning something new you have to do it several times just to make sure you are not totally confused. I have found that three times a charm. Try your best to get management to abide by this "rule". After the three iterations everyone has better picture to judge the value of the effort and Scrum.
Eliminating waste is vital on any type of project or endeavor. In a transition it makes even more sense, you have to make space to learn something new.

Finally, management has to ask the people that will perform these miracles what they need to do just this. Have they? Have you?

The Management Exit

• One successful team
• Removed impediments and studied results
• Change in perception at "ground level"
• A good agile reason to change the rule

Having one successful team is sort of self-evident. This takes patience when the ride is anything but smooth. Being a part of this process is important. Management will have the best ability to change ambition level, removing impediments etc. Get cracking and be that good example.

If there is a change at ground level on how they perceive management, then you're probably on to something.

Is this recipe the final version - probably not? Your mileage will vary, adapt to your management.

The Organization Recipe

Many of our customers are just starting out doing Scrum. Therefore we typically come into play as an external effect. It is important for us to understand how the agile effort has started and its nature within our client's organization. We can basically divide this efforts into to two major types - "bottom-up" and "top-down". The typical traits for a bottom-up style is one where the programmers et al have decided to go agile. The management might be aware of this and even letting it run. Then again this might be a stealth and an under the cover job.

I have found the bottom-up approach to be the most common case. Programmers usually like to work in an agile way. In these type of setups my work usually revolves around questions like "How do we fit this to a waterfall context?" etcetera. This can be tough work, but I find it to be the more easy of the two - the people who do the day to day grinding are already on board.

The top-down effort of introducing Scrum comes with its own set of problems. Any methodology or decision that involves change tend to meet resistance from the organization. We need both experience and sideways effort to the transition.

The Top-Down Scrum Organization

• Get a Scrum Sensei
• Inject a Agile Senior Programmer into the teams
• Make sure there is organizational transparency

The Scrum Sensei is an experienced Scrum Master who's been there before. Much in agile and Scrum is common sense, but there is no need in making the simple mistakes. With a battle-trained mentor the whole organization get a sounding board (Swedish: bollplank) helping out to implement Scrum. This part is important to the Shock Therapy where he or she will be the contract owner enforcing the startup and approving exit. In some sense this person could act as a "bad cop" in a good-bad ScrumMaster setup.

Or in the words of Nanny McPhee - a children's movie where a nanny answers the seven ne'er-do-well children on how long she will stay:
- When you need me, but do not want me, then I will stay. When you want me, but do not need me, then I have to go.
The Scrum Sensei needs to work in similar way to bootstrap the team and management.

A top-down effort always risks resistance from the organization. My experience tells me that a side way force is needed for translation on the factory floor. Moreover, such a person has the experience on a technical level to do the hands on tools and practices that is a vital part of any agile projects. A seasoned programmer with agile experience knows what works and how to translate the management vision into bits and bytes.

"Self-evident" sometimes reads "evident to myself and no one else". If we want to affect the organization we also have to make sure that practices, experiences and results are easy to come by. Walking down a corridor should yield interesting information about ongoing projects. If there is a pilot project doing Scrum then visibility is high on the wish list. Not only does it mean commitment for the Scrum team, but also a pull factor for other teams to get on board. Organizational transparency comes in many flavors. Apply liberally!

Summing it up

There is no denying that projects have problems getting started with Scrum. But more often than not I believe that we can do something about it. Why not try some nice Shock Therapy?
It might be the sweetest hard deal around!

/Björn Granvik, Jayway

MySpace Therapy:
http://jeffsutherland.com/scrum/2008/09/shock-therapy-bootstrapping.html

Scrum Poll on Nokia Test Practice:
http://tinyurl.com/68vapj

VersionOne Report: State of Agile Development Survey:
http://www.versionone.com/agilesurvey/

Situational Leadership:
http://en.wikipedia.org/wiki/Situational_leadership_theory

Nanny McPhee:
http://www.imdb.com/title/tt0396752/

I asked for comments/questions. As it turns out I got mostly questions on Scrum in general and not so much on my topic - how to bootstrap Scrum. I'm not sure what to make of this.
Anyway, here are my takes on those questions. I hope they're of some value.

Dear Björn,

How do you motivate a team to produce more without paying more for IT (salaries)?
Hourly salary seems retarded for agile teams.
Thanks!

Dear anonymous,

I'll first look at the non-monetary part, mostly Scrum, and later on salaries and bonuses.

Self organizing
In many organizations people enjoy very limited control over their own situation. Being able to self organize is important. We humans just tend to like this.

Pick your tasks and choose your implementation
Again, if I can use my competence and decide (as far as possible) on how to implement a certain goal, I will enjoy my work the more. Using this approach I've even been able to rehire people to very problematic situations. Very powerful.

Deliver
When I ask programmers what they are most proud of, I usually hear words like "idea, made by me, real users". It might not be the hardest and certainly not the biggest project they worked on. They used their competence, created something and delivered! In Scrum you get the delivery feeling at every sprint. If you break it down into activities no bigger than a day, then you will get that nice "flow" and people will be able to say "I did" every morning.

Good Colleagues
I've found that Agile makes sense if for no other reason than you can keep and hire the good people. SmartFriends(tm) is a great way to work!

I'm sure I could pick more facets of Scrum and Agile on how to motivate your team. But let's move on to the Money. This part of my answer doesn't have so much to do with Scrum or Agile, but rather my beliefs. So you have to be the judge here - what would work for you and your situation?

Powerful, way too powerful
Salaries, bonuses etc affect you - all the way to the bank and your holiday and...
In short: Once you start using money in different forms as your primary means of rewards, you will get a powerful ally in driving your people. Perhaps to powerful.

Take bonuses at a consultancy firm (a real example from life). You have all the good intentions so you set up a bonus system so that everyone will benefit if they have a client. More hours with customers, bigger bonus. Easy. This way you can lower your costs in bad times. Nice, if you're just counting beans.

Effect: No one wants to come in do monthly meetings if it's going to cost them money.
Counter effect: Introduce a threshold so that there is room for a bonus even though it doesn't mean 100% with customer.

Another effect: You just removed your ability to make strategic decisions like "put someone on the big corporate account" that pays less, but means more hours. Who wants to loose money working for that customer if they have to take a cut money-wise?
Counter effect: You introduce another "rule" specifying that a lower price per hour will not affect their bonus.

Yet another effect: Holidays suddenly never cross the monthly boundaries. That would put your people below the threshold for the bonus on two separate salaries.
Counter effect: ...haven't got the faintest here what they did here.

I hope my example makes sense in your situation. My point is that money matters. When used to drive people you will get side-effects.
For me this is not good enough. I don't want just to persuade people's wallets - I want their hearts and minds. It has to be fun and engaging.

Here's my short take: First make sure you have decent salaries etc. When this in place, aim for those things that make our working day worth while. Set interesting goals, get good colleagues, the right work to do, empower people and so on.

How to ensure creativity and quality in Scrum?
/Fredrik

Hi Fredrik,
I liked the way you wrote this on a green note (meaning "good" when voting at the conference). Thanks

Creativity
I believe there doesn't have to be a contradiction between setting a goal and using proper frames (time, resources etc) vs. creativity - at least as long as we have the right to work to our own judgement within these constraints. I often find that this last part is missing. You get all the obligations, but no mandate.

In Scrum, one part of the creativity is built right into the process: Understanding the different goals. In the product backlog you should enter business value. This way the team has direct contact with the user's intentions and can suggest alternative solutions that might be better, i.e. be creative.

Quality
If we're talking IT, I would like to use automatic testing, continuous integration and so on to ensure consistent quality. Add to this an annoying email whenever something breaks and you have a good start

Moreover, the tight feedback loop using sprint reviews and such should pick up on issues like usability etc. Basically make sure you have a product owner that can spend time on the project.

Also make sure that your "definition of done" reflects your quality goals. It has to be very clear what "done" means within your organisation.

Hur gör man för att bryta ner gigantiska projekt över flera plattformar i lagom stora bitar för att köra Scrum?
[How to break down into gigantic projects over several platforms into decent chunks so that Scrum can be used.]
Sven Nilsson, SAAB

Hi Sven,

Your question seems to revolve around two hefty issues: Breaking down the project into several teams that are likely to depend on each others and breaking down the actual work to fit into a sprint. Perhaps "platform" has a special meaning within your organization and how you work. I would have to know a bit more to answer you on that point.

Teams and dependencies
This is tough on several levels. First let's do the pure Scrum answer - Scrum of Scrums. This basically means that we organize our teams so that one person from each group "steps up" and forms a team that work across several teams. Dependencies etc can be resolved in this group, set up an encompassing backlog and work much in the same fashion as a Scrum Team. Jeff Sutherland, co-fonder of Scrum, has run this set up on 500+ persons. I would love to work on such an outfit.

However, and this is a big however, this is a major change for most companies. The ones I've met (medium size and up) just aren't geared to handle such an approach right now. The number of issues and obstacles with such a transformation can be huge. If you find yourself in such a situation then I suggest you adapt piece by piece and continuously strive to be ever more agile. This is hard work and will mean small improvements upon each other, but maybe no hyper productive state.

This is where I chicken out and suggest you should get someone with experience. Every company is different and needs their set of actions.
Hell, buy me lunch and maybe I can point you in a good direction

Breaking up the work into chunks
This takes creativity.

First: Try to slice the work so that you will touch base with most layers/parts. This way we can have a better understanding of what it means to deliver the whole system. Therefore make the slice as thin as you can while at the same time deliver something "valuable". This might mean you need to mock other components (code that isolates different components with dummy answers). This can be very beneficial since it becomes some sort of contract with other teams.

If the chunk still is to big then you might have to resort to cutting up the chunk into parts by level in your architecture. This of course has the drawback that we don't know what it will take to implement the parts we didn't do. Business value might be less, but we might be able to "prove" that we're on the right track. What is "proof" to your product owner?
If you can, stay away of doing tasks in your product backlog. In worst case people will be task-driven: "I've changed the registry, can I go home now?"

If we want to/have to promise the customer a delivery date. How can we do that when we don't analyse the whole project?
We are focusing on the next sprint?

How can we tell management how many resources we will need in one month?
/Patrik Johansson, Ericsson

Hi Patrik,

Several questions and perhaps the most common ones. Let's dive into them.

Analyze the whole project?
Why we can't analyze the whole project? Because, this is blatant lie for anything bigger than a trivial project. I apologize for my frankness, but I've never seen a project with a single version of the Gantt schema, a single time plan, with a known set of resources...
They always change. Always.

If you and your management can't agree that things change then you might have to go dualistic - outwards project manager old style, inwards ScrumMaster. It's not easy, but in time you will gain some victories, err deliveries, and you can move the agile thinking further up. Hard work, but it's better than doing waterfall all the way.

Your question is still valid. How do we commit on delivery if most things might change? The customer still needs to plan an ad campaign.
One trick is to reinterpret the "commit to delivery date" into agile terms. Get a stable backlog and learn the team's velocities. This way you can commit to the same "distance". Things will change, but (as always) it's down to making things fit into the available time.

For this work we need some iterations under our belt to know our velocity and hashing out what the product backlog should contain. Therefore, mix the project plan's you have do at the start with some "real work" like coding. Inspect and adapt. After while I think you will able to commit to management.

Focus on the next sprint?
You shouldn't just focus on the next sprint. The closest work (sprint) is fine grained and the most well understood. The further away (further down on the product backlog), the more coarse grained should the user stories be. No point in being specific, when they're far into the future.

Resources?
Which resources can you get? Go for full time members. Make sure can keep them. Look at the product backlog and calculate what you can get done with the people (velocity etc) that you got. The important part is to couple the resources with the goals. All too often your resources get slashed and the goal knocked into orbit - and not on the same day.
Get them in synch so that a change in one of them will affect the other.

I hope this helped.

Regards,
Björn

I'd love to get your feedback. See you in the halls and the Way Group booth.
Or you can just give your comments about the session here on this blog.

Developer's conference in Malmö, Sweden

Scrum and Agile development has started to rock the world within IT in various ways. A simple, but powerful process that seems to deliver. Developers and customer alike are happy. What's not to like about it? Still, there are signs of problems. Projects that claim to use Scrum do not reap the benefits, management looses patience with this new method and team members struggle to adapt an agile approach to their everyday work life. Why is this? And more importantly, what can we do about it?

The Therapy: Get off to a good start by directing the team with a careful set of good practices and a strict agreement that leaves little or no choice. The team can then, over a couple of iterations, gradually take command themselves.

Easy, but still so hard

Why then is Scrum so hard? Well, first of all it is fail-fast, meaning that any problems will be quickly apparent. There are no artifacts or process steps to hide behind. This is never easy. To this list we can add even more pitfalls that are just plain hard to deal with whatever method we are using.

Still, it does not explain why there seems to be so many simple mistakes with such a simple framework. One of the best examples is the failure to keep backlog that is prioritized and up to date.
- We're doing Scrum, but we're too busy to work on the product backlog!

That one has always short-circuited my brain. What can be more important than to decide what is important? This pattern of falling short and missing basic parts of Scrum even has a name - "ScrumButt". If you look in the sentence above you see why.

Nokia created a test to make sure the projects are "Scrum enough". These plain questions form a lithmus test that can be used to analyze most agile projects.

The Nokia Test
Iterative Development?

• Iterations - time boxed, less than 4 weeks.
• Software features - tested and working at the end of each iteration.
• Iteration must start before specification is complete.

Scrum (in Nokia's opinion)?

• You know who the product owner is.
• There is a product backlog prioritized by business value.
• The product backlog has estimates created by the team.
• The team generates burndown charts and knows their velocity.
• No project managers (or anyone else) disrupting the work of the team.

The questions seem to be on the easy side. It turns out that this might not be the case.
One online poll, Nokia Test by Practice , about the ability to achieve the Nokia Test level gave some interesting answers. In essence, only one out of four give themselves a full mark. Half of the groups report that management interferes, not directs but interferes.

Informal queries by Jeff Sutherland among his audiences around the world give an even worse number - something like 1 out of 10 pass the Nokia Test. Hand on your heart: Does your project live up to this?

A survey by VersionOne tries to dig deeper into the current state of the Agile affairs. Under the headline "Top barriers to adopting Agile" we read the top four answers:

1. Organisational culture, 45%
2. General resistance to change, 44%
3. Lack of people with experience, 42%
4. Lack of management support, 32%

Take a long look at these barriers. No technical stuff. Nothing specific to agile. Just people.

What do we know?

Learn to walk before you run. Greek Proverb.

We could be a bit closer to today's reality than these ancient words of wisdom. The Situational Leadership offers an approach to management that has been around since the 60's. These theories say that there is no single leadership style that is optimal for all people in every situation. Situational leadership talks about four different leadership styles that need to be matched with the follower. Basically, when leading someone who is passionate, but have no experience, you should adapt and give clear directives. As the follower evolves his or her ability to execute, so should the leader using less directives and more encouragement. In the end the follower is able to perform with only a stated goal and little or no directives.

If this holds true for people, could it not be true for teams as well?

The Shock

So we have problems making Scrum and Agile efforts to run. What is the conclusion? Could it be that we adapt our leadership style to the group? Make them walk before running?

This is counter intuitive, at least to me: To go agile, we first need to control. We should not let our teams and managements start off without some kind of directives. Give them a good deal, some practices that make Scrum work. Otherwise, we are just repeating the same old mistakes as the next-door agile project. Set up an agreement with both management and team so that they can evolve and experience Scrum for real. Just reading a book (or article) or listening to some good speaker alone does not help you out there in real life. You have to experience it.

Shocking as it may feel: We need to exercise some control over the Scrum project start so that it can evolve and self organize! But, and this is a big but, this has to be done with compassion and genuine involvement, otherwise we stand the risk of destroying what we are trying to build.

The Therapy

So what can we do? We need to work the team, management and often the whole organization.

The Team Recipe

So how do we get started? Here's a recipe for the team as it used at MySpace:
The Team

• Scrum training session for everyone
• Sprint 1 week long
• Definition of Done:
• Feature Complete
• Code Complete
• No known defects
• Approved by the Product Owner
• Production Ready
• Story Points
• Physical Task Board
• All-in-one Sprint planning meeting.
• No Multi-tasking, work in priority order.

Scott Downey, Agile Coach at MySpace

The idea of this recipe is to set a good practice right from the start. Instead of debating the details on how to work in an agile way, we can focus on getting going.

Everyone has to have a common Scrum understanding to start from, hence the training session. One-week iteration sounds really tight for any reasonably sized projects. The thinking behind this is to get as quick iterations as possible - the faster that the group gets going the better. Short sprints help in this aspect. We learn faster with more turnarounds.
This in turn affects the meetings where MySpace has elected to combine them all, except the morning meeting, into one single occasion. The time is just too short to in a weekly sprint.

MySpace's definition of done is a good and basic list. However, as a programmer I lack for instance continuous integration, pair programming and so on. These are not mandatory to have, but I see them as enablers for Scrum and supporting your agile initiative.

The next two on the list - Story Points and Physical Task Board - are really effective. If you haven't tried them out then please do. They work. Finally we have something that is a no-brainer to me even though I have great problems avoiding it, "No Multi-tasking, work in priority order". Context-switching is expensive, just avoid it. The priorities are in order, you just have to follow them. In the Reference box you find a link to Scott Downey's description of their therapy.

When the team matures, they should evolve and handle things more on their own and no longer need directives. At MySpace the group can "prove" that they are ready for prime time by reaching the following goals.

The Team Exit

• Hyper-Productive (>240%)
• Three successful Sprints consecutively
• Good business reason to change the rule

The Result?

So how does this work out? At MySpace all groups achieved exit. All, but one, improved after that. One group even achieved a whopping 1,650% improvement after just four months (16 sprints). At Jayway one of the teams used such a bootstrap technique, primarily on the technical side, and reached 800% after 3 months.

The second part of this blog can be found here: Scrum Shock Therapy, Part 2 where I will look into how to handle management and organisation with some recipes.

/Björn Granvik, Jayway

After several CTO assignments at various companies, Jeff Sutherland found himself at Easel corporation where he created Scrum together with Ken Schwaber. Ken later presented this methodology at the OOPSLA conference in 1995.

A dozen years later I find myself in search for a good spot where I can concentrate on my interview. Jeff and I sit down at a café at the Øredev conference. My computer has been acting up going blue screen on me twice that day. Time is short and I wonder if it's an omen.

Photo of Dr Jeff Sutherland.

Q: I hope I've done my reading. As far as I understand you've been a fighter pilot in Vietnam, an assistant professor in math and medicine and the CTO at nine different high tech companies. Moreover, you travel the world to teach Scrum. Does it take a resumé like this to invent a process like Scrum?

The key part of what makes Scrum work is "complex adaptive systems" and you need some understanding of this. Also you need to understand systems theory and how to optimise a system as a whole.

You do not have to be smart, but you have to thoughtful.

Q: How did Scrum start and from where does it draw its heritage?
Scrum and Lean both derive from complex adaptive system theory. Constraint theory is a narrow subset of complex adaptive systems thinking. Lean implementations of these theories have been created at companies like Toyota and Honda. Honda was actually more aggressive at this in the nineties, but then Toyota was more successful in the market. They also were more formalised and better known.

Q: Why does it work?
The first reason for all of this is important - super intelligent performance out of ordinary developers. In order to do that we need we need to set up a simple framework so that people will self-organize. The second reason is that there is no central point of control. The manager needs to back off. That is critical.

The third principle is behaviour that emerges in the team based on self-organizing in order to get max production.

The fourth reason is that the production is far higher for the group than any single developer. Groups actually achieve more than any lone bright developer.

These are the basic principles of a complex adaptive system. Any organization is a complex adaptive system. Software production is an organizational phenomenon. It is an empirical process that must absorb significant change in requirements, technologies, priorities, and people.

Q: You talk about managers, why is it important for them to back off?
A company needs to stop sub-optimizing locally. That is the thing that Toyota figured out, largely due to the efforts of Edward Deming and other Americans who trained the Japanese in WWII industry processes. Most managers just care about local performance. Managers have to work as a team to look across the whole spectrum. It is difficult for them. They're paid and given bonuses on a single level, not the company as a whole.

For instance, look at the General Motors manufacturing plant in Fremont, California. GM shut down that plant 1982 due to several problems, among them quality. Two years later it reopened as a joint venture between Toyota and GM. Toyota needed a plant in the US in order to avoid import restrictions. In an agreement with the labour union they offered reemployment to the former employees.

Two years later the NUMMI plant was producing over 200 000 cars per year and was twice as productive as the typical GM plant. The thinking they applied is the same as "lean production" where Toyota makes the team responsible to figure out the best way to solve the problems and achieve the goals. NUMMI later won several awards for quality.

"Your battery is running low", declares my machine solemnly. Jeff and I make a run for a power outlet and find one on the second floor. My power chord is too short so we stack up real close to the wall. It will do. More than that actually, it feels like we really are working together on this interview.

Q: Some parts of Scrum are frightening, like making the group totally responsible for an implementation. How come people in management buy this?

The best answer I can give you, is the discussion I had with my first CEO when I introduced the ideas of Scrum. We had a critical project with a hard deadline. It was a question of survival.

The CEO expected a Gantt chart [ed: a timeline specifying activities and their dependencies, showing the progress of a project].

• How many Gantt charts have you received that actually worked? I asked the CEO.
• None, was the short answer. In my 25 years I haven't received a single one that was correct. I asked him if a 100% failure rate wouldn't make it foolish of me to give him one.
• What are you going to give me, he asked?
• Working software. Decide for your self to if we're on track. In return I made him promise not to disrupt the team before the deadline. At this point he started to worry.

I said that at the end of the month he could change everything he wanted, but not during that month.

• If you do this, you will get significant more code with better quality.
• I can live with that. Let's do it.

Scrum was born in that minute.

It's a basic contract between management and team. The team delivers twice as much stuff with twice as good quality (minimum) and the management supports the team in their efforts to self-organize and self-manage. If either party does not fulfil this contract then it will fail.

Q: Doesn't Scrum fail?

Scrum itself is a set of rules that causes self-organization if certain things are put in place. It's like the rules of soccer. Does soccer fail?
With Scrum you will fail significantly less.

The Standish Group \[ed: a company that specializes in IT studies\] reports that project in the range 3-6 million dollars with a traditional project plan fail more than 85% of the time. Scrum does a lot better than that!

Q: What are your top three tips on using Scrum?

Bas Vodde was the Lead trainer for Scum Master at Nokia Siemens Networks. He has the shortest set of questions to identify a dysfunctional Scrum team.

You must have iterations of 30 days or less with working software tested at system level at end of each iteration. You need an agile specification, just enough for programmers to start for that iteration.

You need a product owner who orders activities by business value of the feature set. The team estimates the product backlog.

And lastly, the team needs to monitor progress with a burn down chart and know its velocity at the end of the iteration.

Q: Finally, what is in the future for Scrum?

Hyper productivity on an economic and marketing level where companies consistently out perform their competitors. Scrum is a disruptive technology that will alter markets. Companies doing Scrum well will grow rapidly in both size and profitability and dominate their waterfall competitors. There is already a brain drain going on where the better developers are fleeing from waterfall companies to Agile companies. This will hasten the demise of traditional projects.

Q: Is this a shameless plug?
Oh no, we have achieved it in several departments at my company \[PatientKeeper\]. It is doable. Other companies I work with right here in Scandinavia are doing it as well.

Going away from this fast paced interview, I still have the feeling that I could have done more with my life. If Jeff can do it, then so can I ...I hope

Originally published in JayView.

Finally, an empty room, well almost. Another speaker, Erik Dörnenburg, is sitting half way into his screen and mutters.
- What's up, I ask.
- I've updated my machine and my demo doesn't work. I've got 45 minutes until the presentation.
We sat down next to him. Do not disturb a developer while he's coding...

So I got a man who has coined phrases like Dependency Injection and POJO in front of me. What next? Martin is easily recognizable both in accent and appearance, a frequent and brilliant speaker.
He has an excellent web site, www.martinfowler.com, which contains loads about his work. Articles and references abound. That is when it suddenly hits me - who is he as a programmer and person?

Q: When was the last time you coded?
Well, I do code my own website. But it's been a while since I had any paying customers. I've been pairing quite recently though. A real delivery? That was some time ago. I'm actually afraid to lose contact with code, but I have smart people around me.

Q: But what makes you tick?
I enjoy trying to figure out new techniques - to organize knowledge. I see myself as a conduit [ledning] for transferring knowledge, to process what is out there and make some kind of structure out of it. Brian Foot actually described me as an "intellectual jackal with a good taste in carrion" [intellektuell schackal med god smak för kadaver].
I look around for interesting stuff and try to make sense of it.
The "Refactoring" is a good example. I figured out how to describe it and wrote a book that came out when it could make a difference and move the area forward.
I also enjoy writing a lot, that's a big thing. I'm better now at speaking, but that's not what makes me tick.

Q: You've written quite a few books - how do they compare?
Out of the five, "Uml Distilled" sold more copies than the others put together. Usually you can't make a living out of your books, I guess I could though.
All of the books had their good sides, but I would have to say that it was fun to write with Kent Beck [red: wrote "Extreme Programming", created JUnit etc]. We were in tune and could support each other through the dull bits.
I would have to say though that I'm proudest of "Refactoring". It's an important technique and didn't get the attention it should have received – the book helped.

Q: How did you start out?
I was an independent consultant for many years. Giving talks was a good way of getting jobs. Articles same thing - it got my name known.
Also, I write something because I don't understand a certain area or technology. It's a good way to learn.
Erik is now on the phone with California. We calculate that time is roughly 6:30 there – in the morning.

Q: Then what? How come you started working for Thoughtworks (TW)?
I've been there for six years and done a lot of consulting. I never wanted to work for a company, but there was something about TW that made me interested.
Get the work done and tons of bright people. But more importantly is that it is a sort of social experiment. A notion that good people makes a difference.
I hope we can affect IT, which is a difficult and skilled exercise at best.

Q: What is the most difficult part of being a celebrity?
I'm not an extrovert person. I'm not good at the "person to person". I get emails with questions like "I got a problem on…what is the magic trick". They worked for months on it and I can only point to a book. That clearly wasn't an answer they liked. It's frustrating.
However, celebrity is also a nice thing – it opens a few doors. I can email people like Rod Johnson [red CEO of Interface 21 that created the Spring framework] if I have a question about something. And he will answer.
People tend to think I'm an ingenious programmer. I'm not. I'm pretty good, but not necessarily that great.
Erik suddenly spits out:
- F---!...ok the demo will be shorter.

Q: Looking forward, what's next?
Oh, there is tons of stuff to write about. The design patterns area for instance. I'm also interested in DSL [domain specific languages] and agile development. But in agile there are too many writers and I don't like competition. There are too many smart people in agile development.
My strategy is to look for topics that no one has written about. Basically I don't foretell the future.

Q: What are your top three pieces of advice to a programmer?
My first advice must be to learn to collaborate with the user or purchaser. The really good ideas usually come from them. You don't have to be an expert to do this. This I found to be a good general advice.
Secondly, it would be "continuous learning". It's like running up a downwards-moving escalator – you have to keep running.
The third one is difficult…
"Buy lots of books by good authors" would be it.
Erik suddenly releases a big:
- Yes!
I saw Erik's demo some twenty minutes later – it was really good.
As for Martin, our discussions continued well into the debate panel and beyond. He would frequently forget his back pain and sip into some extra energy pack. I wonder how he did that.

Originally published in JayView.

The relational database represents one of the most important developments in the
history of computer science. Upon its arrival some 30 years ago, it revolutionized the
way the industry views data management and today it is practically ubiquitous.

In fact, it is so taken for granted that we, as an industry, have stopped thinking. Could
there be a better way to represent and store our data? In some cases the answer is
– yes, absolutely. The relational database is showing its age. Some telltale signs:

• The mismatch between relational data and object oriented programming.
• Schema evolution – updating your data model when the domain model changes
  – is just so much manual labor.
• Semi-structured or network-oriented data is diffi cult to handle.

The Neo Database

Neo is a database that is built with a different philosophy. Where the relational da-
tabase squeezes all data into static tables, Neo uses a fl exible and dynamic network
model. This model allows data to evolve more naturally as business requirements
change. There’s no need for “alter table...” on your production databases after you
introduce a new version of the business layer and no need to rewire and migrate
your O/R mapping confi gurations. The network will evolve along with your busi-
ness logic. This spells agility.
Neo is an embedded persistence engine, which means it’s a small, lightweight and
non-intrusive Java library that is easy to include in your development environment.
It has been designed for performance and scalability and has been proven to handle
large networks of data (100+ millions of nodes, relationships and properties).
Neo is a newly founded open source project, but the software is robust. It has
been in commercial production in a highly demanding 24/7 environment for al-
most four years and has full support for enterprise-grade features such as distributed
ACID transactions, confi gurable isolation levels and full transaction recovery.
But so much for sweet talk, let’s cut to some code!

Model and Code

Representation

In the Neo model, everything is represented by nodes, relationships and properties.
A relationship connects two nodes and has a well-defi ned, mandatory type. Prop-
erties are key-value pairs that are attached to both nodes and relationships. When
you combine nodes, relationships between them and properties on both nodes and
relationships they form a node space – a coherent network representing your busi-
ness domain data.
This may sound fancy, but it’s all very intuitive. Here is how a simple social network
might be modeled:

Figure 1: An example of a social network from a somewhat famous movie. Note the different type on the relation between Agent Smith and his creator The Architect.

Note how all nodes have integer identifi ers and how all relationships have a type
(KNOWS or CODED_BY). In this example, all nodes have a “name” property. But
some nodes have other properties, for example, an “age” property (node 1) or a
“last name” property (node 3). There’s no overall schema that forces all nodes to
look the same. This allows Neo to capture so-called semi-structured information:
information that has a small amount of mandatory attributes but many optional at-
tributes. Furthermore, the relationships have properties as well. In this example, all
relationships have an “age” property to describe how long two people have known
each other and some relationships have a “disclosure” property to describe whether
the acquaintance is secret.

Working with nodes and relationships is easy. The basic operations are as follows:

This is an intuitive representation of a network and probably similar to many other
implementations that want to represent a network of data in an object-oriented
language.
It’s worth noting, however, that relationships in this model are full-blown objects
and not just implicit associations between nodes. If you have another look at the
social network example, you’ll see that there’s more information in the relationships
between nodes than in the nodes themselves. The value of a network is in the con-
nections between the nodes and Neo’s model captures that.

Creating a Node Space

And now, finally some code. Here’s how we would create the Matrix social network
from figure 1:

Transaction tx = Transaction.begin();
EmbeddedNeo neo = ... // Get factory
// Create Thomas ’Neo’ Anderson
Node mrAnderson = neo.createNode();
mrAnderson.setProperty( ”name”, ”Thomas Anderson” );
mrAnderson.setProperty( ”age”, 29 );
// Create Morpheus
Node morpheus = neo.createNode();
morpheus.setProperty( ”name”, ”Morpheus” );
morpheus.setProperty( ”rank”, ”Captain” );
morpheus.setProperty( ”occupation”, ”Total bad ass” );
// Create a relationship representing that they know each other
mrAnderson.createRelationshipTo( morpheus,
   MatrixRelationshipTypes.KNOWS );
// Create Trinity, Cypher, Agent Smith, Architect similarly
...
tx.commit();

As you can see in the code above: It is rather easy to construct the node space for our
Matrix example. And, of course, our network is made persistent once we commit.

Traversing a Node Space

Now that we know how to represent our domain model in the node space, how do
we get information out of it? Unlike a relational database, Neo does not support a
declarative query language. Instead, Neo provides an object-oriented traverser frame-
work that allows us to express complex queries in plain Java.
Working with the traverser framework is very straight-forward. The core abstrac-
tion is, unsurprisingly, the Traverser interface. A Traverser is a Java Iterable that
encapsulates a “query” – i.e. a traversal on the node space such as “give me all Mor-
pheus’ friends and his friends’ friends” or “does Trinity know someone who is acquainted with an agent?”. The most complex part of working with a Traverser is instantiating it. Here’s an example of how we would create a Traverser that will return all the
(transitive) friends of the “Thomas Anderson” node of the example above:

// Instantiate a traverser that returns all mrAnderson’s friends
Traverser friendsTraverser = mrAnderson.traverse(
    Traverser.Order.BREADTH_FIRST,
    StopEvaluator.END_OF_NETWORK,
    ReturnableEvaluator.ALL_BUT_START_NODE,
    MatrixRelationshipTypes.KNOWS,
    Direction.OUTGOING );

Here we can see that traversers are created by invoking the traverse(...) method
on a start node with a number of parameters. The parameters control the traver-
sal and in this example they tell Neo to traverse the network breadth-first (rather
than depth-fi rst), to traverse until it has covered all reachable nodes in the network
(StopEvaluator.END_OF_NETWORK), to return all nodes except the fi rst (Returna-
bleEvaluator.ALL_BUT_START_NODE), , and to traverse all OUTGOING relation-
ships of type KNOWS.
How would we go about if we wanted to list the output of this traversal? After
we’ve created a Traverser, working with it is as easy as working with any Java Iter-
able:

// Traverse the node space and print out the result
for ( Node friend : friendsTraverser )
{
    System.out.println( friend.getProperty( “name” ) + “ at depth “ +
        friendsTraverser.currentPosition().getDepth() );
}

Running the traversal above on the Matrix example would yield the following out-
put:

$ bin/run-neo-example
Morpheus at depth 1
Trinity at depth 1
Cypher at depth 2
Agent Smith at depth 3
$

As you can see, the Traverser has started at the “Thomas Anderson” node and run
through the entire network along the KNOWS relationship type, breadth fi rst, and
returned all nodes except the fi rst one. “The Architect” is missing from this output
since the relationship connecting him is of a different type, CODED_BY. This is a
small, contrived example. But the code would work equally well on a network with
hundreds of millions of nodes, relationships and properties.
Now, let’s look at a more complex traversal. Going with our example, suppose
that we wanted to fi nd all “hackers of the Matrix,” where we defi ne a hacker of the
Matrix as any node that you reach through a CODED_BY relationship. How would
we create a Traverser that gives us those nodes?
First off, we want to traverse both our relationship types (KNOWS and COD-
ED_BY). Secondly, we want to traverse until the end of the network and lastly, we
want to return only nodes which we came to through a CODED_BY relationship.
Here’s the code:

// Instantiate a traverser that returns all hackers of the Matrix
Traverser hackerTraverser = mrAnderson.traverse(
    Traverser.Order.BREADTH_FIRST,
    StopEvaluator.END_OF_NETWORK,
    new ReturnableEvaluator()
    {
        public boolean isReturnableNode( TraversalPosition pos )
        {
            return pos.getLastRelationshipTraversed().
                isType( MatrixRelationshipTypes.CODED_BY );
        }
 },
 MatrixRelationshipTypes.CODED_BY,
 Direction.OUTGOING,
 MatrixRelationshipTypes.KNOWS,
 Direction.OUTGOING ); 

Now it’s getting interesting! The ReturnableEvaluator.ALL_BUT_START_NODE con-
stant from the previous example was actually a convenience implementation of the
ReturnableEvaluator interface. This interface contains a single method and you
can supply a custom implementation of it to the traverser framework. It turns out
that this is a simple but powerful way to express complex queries.
Setting aside the anonymous inner class cruft surrounding the code in bold, we
basically pass in a snippet of code that checks whether we traversed a relationship of
type CODED_BY to get to the current node. If this statement is evaluated to “true”
then the current node will be included in the set of nodes that is returned from the
traverser.
When executed with a simple print loop, the above code prints the following:

$ bin/run-neo-example
The Architect
$

StopEvaluators work the same way. In our experience, writing custom evaluators
is very easy. Even the most advanced applications we have developed with Neo
– applications that traverse extremely large and complex networks – are based on
evaluators that are rarely more than a few lines of code.

Conclusion

Neo is not a silver bullet and some areas needs to improve, for instance tools, stand-
ardizing the model and a query language.
However, if your data is naturally ordered in a network or is semi-structured or you
just need to go truly agile, give the Neo database a run for your money. We hope
you find it, as we do, to be an elegant and fl exible alternative that is both robust and
fast.

Emil Eifrém, Neo Technology
Björn Granvik, Jayway

Links

Neo specification
www.neo4j.org

Originally published in JayView.

JavaOne conferences seem to come in three different flavours – announcement, middle and final. Several “new” technologies made their finale this year; a graduation year. EJB 3, Java EE 5 etc. were all more or less announced two years ago. Even the examples were in some cases identical to then: mature and perhaps a bit boring. However, EJB3 will play a role in many projects so “mature” is a good sign.
There were also some surprises and rejuvenation, mostly on the open source side even though Sun managed to squeeze in some surprises.
What happened in the Java SE and EE area? Let us check out some trends and
see what we can make of them.

AOP- still stillborn?

Sun has had a very cautious approach to aspect oriented programming. Two years
ago on JavaOne, a large, attentive audience tried to understand what Sun had to say
on the subject. The answer from the panel on aspects was like something taken from
an old police station series on TV:
- Let’s be careful out there!
Well, the “fireside chat” this year with Sun aluminaries and, of course, James Gos-
ling proved to be more of the same.
The EJB 3 gang also had something similar to say during the conference - along
the lines of: “why aspects, when interceptors will do the job”. Interceptors could be
described as poor man’s aspects using interfaces and proxies to catch calls to meth-
ods. Those of you with good memory banks will recall the Spring folks doing the
same rhetorical twist a couple of years ago. This was of course before they saw the
light and got the AspectJ guy on their payroll. Smart move.
My guess is that we will hear Sun speaking more on using aspects instead of in-
terceptors some two years from now. In the mean time, Spring will lead the way on
aspects and real life programming.

Scripting

In Java 6 there will be JVM support for hooking in your choice of scripting lan-
guage through the standard Java Scripting API. The contestants are already many
and include such names as JavaScript, Ruby, Groove, BeanShell and a bunch
you probably haven’t heard of. The driving force behind this is twofold; first the
amount of glue code needed in Java. It is sometimes just too much code for simple
stuff - or should I say stuff that should be simple. Secondly, the competition in the
language area is heating up. Ruby on Rails is a good example of powerful and fast
programming for setting up a website. Their 15-minute video does compete with
successful TV ads. You know the ones that make you buy something just because
it is such a good deal.
My forecast is that we will see a scripting case where the language and solution
just makes sense. Which one? Who knows. Unfortunately we might see a lot of bad
examples before the right one comes along.

Java 7 - Dolphin

The Mustang (Java 6) might not be on the loose just yet, but I had to check out the
next mammal in the Java sequel - Dolphin. Java 7 was apparent in several sessions,
but the common denominator was the vagueness. The speakers used phrases like
“thinking about”, “might” etc. Still it was interesting and some of the features are
needed.

XML in Java

For instance, what about supporting XML in Java more directly where the XML
would be a data type?

Current way

String name = “Björn”;
XML xml =
   <person>
      <name>{ name }</name>
      <age>{ 25 }</age>
   </person>;

Alternatively the XML could be expressed as, less verbose:

Possible new way

XML xml = #person
           #name { name }
           #age { 25 };

Less verbose but will it catch on? I find XML so mind numbing that I am ready to
try just about anything.

Super Packages

In large projects the notion of packages does not scale. How can we use a library
of classes without exposing internal classes best left in the dark? There are several
aspects to this problem, from distribution format to lifecycle. JSR 294 addresses
the modularity issue even if it includes a certain NIH factor (Not Invented Here).
OSGi, for example, already has a similar mechanism. But for now let us just exam-
ine how we can handle classes and their visibility, i.e. “super packages”.
Here’s a code snippet on what a definition for a super package would contain.

super package com.sun.myModule {
  // Classes visible outside of this super module.
  export com.sun.myModule.myStuff.*;
  export com.sun.myModule.yourStuff.Interface;
  // Not visible outside
  com.sun.myModule.myStuff;
  com.sun.myModule.yourStuff;
  com.sun.SomeOtherModule.theirStuff;
  org.someOpenSource.someCoolStuff;
}

As you can see super packages is essentially a package of packages. This way we can
only expose classes on a need to know basis. Solving this with current Java syntax
is tricky. Some even resort to removing any JavaDoc on the “internal” classes to
obscure their usage.

Java Module System

The next big thing is aimed at the JAR file format that, let’s face it, doesn’t scale and
has poor dependency enforcement especially when it comes to versioning. What
is needed is a system for resolving references between “Java modules” where each
module has meta-data about its version and related resources. This is exactly what
JSR 277 defines and yes, it sounds very much like shared assemblies in .NET.
However, combining super packages with Java modules forms a powerful way of
distributing, versioning and managing components. I like.

These three examples on what we might see in the next-next version of Java are
likely to change. Nevertheless I found them interesting.

Ajax, Ajax ...oh and Ajax

If there ever was a message being touted on the rooftops of Moscone Center in San
Francisco, it is Ajax. The intro sessions were packed, standing room only even on
the repeat sessions. Ajax is simple at its lowest level - some JavaScript to query the
backend and voilà, you’re done. At the face of it, this is deceptively easy. However,
once you have done that simple first try, you quickly get into more questions. Where
should we put retrieved data on the client? How do we handle lots of Ajax calls?
Will someone mesh up my data?
Performed correctly though, you do get neater web clients and that is actually an
attractive notion. The flip side of this, though, is all the hype. Everything from the
Colgate inspired salesmen - yes, they were there with their surreal suntan - to the
former Sun execs doing the IPO dance. “Next episode: Will they get cash in before
the expiry date?”
Ranting aside, Ajax is here and we all better start to learn it because it does matter.
And it does put an amicable face on your web site.

Far out Java container

Two years ago the chosen Java compatible container was ...a cool BMW. This year
it was an autonomous dune buggy named Tommy with software all in Java. It was
entered in a challenge to cross a patch of the American desert - without a driver. It
looks a bit like Flash Gordon with four tires instead of rockets, built in somebody’s
garage. I must say Tommy spurred my interest more than the BMW, but then again
you would not look too cool driving it.
Sun to ground control

NetBeans

It was quite evident that Sun has a new version of NetBeans out and that it does sup-
port the latest Java EE version. And, yes, it does look good. And the price tag is quite
right - zero. I just wish that it wasn’t being plugged at most every Sun keynote etc.
The audience did get the message and we will check it out. Boy, that IDE market
is tough!

Java 6

“Java 6 is here” was one part of the message and “compatibility matters” was the
other. Sun CEO Jonathan Schwarz has been going the open source route a lot and
many applications are being made OS. Even Java itself could be made open some
day. The “When” is still open though. Personally, this isn’t such a big deal for me.
Sun has been, for the most part, good at stewarding Java. They have also managed
to keep the code running, mostly, between versions. Opening it could be a problem,
but also very interesting. Making compatibility a part of the arguments makes sense
in such a scenario. Let us hope it stays just that - compatible.

“We want your help”

Making your software open source does change your way of thinking. Sun
has promoted a lot of its stuff into the OS arena. Good, I say! It is only logi-
cal that participation, from you and me, is seen as a great opportunity. Many
of the applications going open, Project Glassfish etc, often ended their ses-
sions with a “we need you”. Maybe Sun’s bad economy has a role in this?
To me it doesn’t matter. I like it and I am eagerly waiting to see what the future
might bring.

Summing up

JavaOne is a lot more than you can cram into an article such as this, but let us not
be stopped by that when summing up. EJB 3 has come of age. This was their prom
night and things were basically just as they said they would be two years ago. Keep
an eye on it. It will play a role in many projects.
Spring will deliver aspect oriented programming, not Sun, and it will go from hot
to “fun and here”.
Ajax is everywhere and you will use it. You might as well pick up a good book on
this subject and start hacking.
Java 6 will deliver lots of goodies. Will we get to use it? Or is your project stuck in Java JDK 1.4.2 unable to upgrade? Let us hope not. Check out scripting! It will change with Java 6. Who can tell which language will affect it big time? Someone will. Check out your local Javaforum to see if you can predict the winner.
Keep coding and may your code be with you.

Originally published in JayView.

Some forty people checked in for this, the first Javaforum event in Malmö for several years. The audience was a mo- saic of around fifteen companies. The forum handled subjects like project methodology Scrum, application servers like T4 and Geronimo, news of the Spring framework and finally sensory networks using tiny Java thingies. The sessions covered the small and the big, from the sublime to the surreal - and all in Java.

Feel like more Java? Check www.javaforum.se for up to date information.
Welcome next time around!

I could smell it straight away when I en- tered the small office - the fresh and raw scent of newly cut code. Two men sat in front of their computers. One of them smiled at me.
Jon Hauksson and I had hacked code, back to back, against a fast moving dead- line in a distant project. He had given up his daytime job as a consultant at a respectable firm. Now, he was shoulder deep into his new venture, bringing au- dio books to the mass market of mobile phones.

Jon and Andreas in a classical image – happy men with computers.

It has been said that developing a Java ME solution for all those different mo- biles is difficult and time consuming. Is it that hard?
Yes... but it has improved, especially for Nokia and Sony Ericsson. But some other brands can be trickier. We usually code for the Sony Ericsson emulator and then bring the code over to the Nokia one. Usually there aren’t any problems here. From here on we test the other brands. If we hit a problem we either try to solve it or we have to program our way around it. It used to be more difficult. The situation has improved in the last year. Especially Sony Ericsson is working hard to make it better.

Does this mean you have different sets of your code?
We have four variants of the result- ing jar/jad file and that is enough for us. Fortunately NetBeans has pre-process- ing that makes life easier and allows us to only work with one code base.

Without any time to think, what are the top three hard to learn lessons that you can you share with us?
1) Testing, testing, testing is extremely important. Many unforeseen things can happen in areas like operator handling, memory management, the mobile network and different quality issues - a lot can happen and usually does.

Bokilur’s application playing a book.

Would you do use Java again?
For sure, it is easy to work with and even though it has problems, it is getting better.
Although, we’ve chosen to imple- ment a number of our own frameworks even though there might be a good open source solution available. It is im- portant to us to keep our code size to a minimum and we usually don’t want the whole nine yards.

Any examples of when you’ve had to roll your own solution?
Well, we implemented a GUI frame- work a bit like J2ME Polish. This way we can target our application’s needs and keep control. We’ve also developed an RMI like protocol to interact with the servers. There are, however, a lot of open source solutions to try out.
We also have a simple debug solu- tion where the phone sends back debug information to the server so it can be logged. Very handy. And of course simple stuff like text han- dling.

Would you do anything differently now when you look back? How long has it been anyway?
One and a half year. Ha-ha, it feels a lot more! We are trying to improve the user friendliness of the entire browsing and purchasing process in the applica- tion. That’s user interaction, but I can’t think of anything technical. Keeping the program easy and intuitive is important to us.

Any practical hints on starting a prod- uct company in the mobile space?
Get the operators as partners. For a data rich service like ours, you need to get a deal without traffic charges. Other- wise it will be hard to develop a pricing model that is attractive to your targeted customers. Besides, the operators have a strong interest to bring in attractive services into their portals. They need more than just games and ring tones.
Oh, and one more thing, keep track of the top selling mobile phone list. That way you know which models to target during testing.

What about the future?
Our business idea is to be the best mobile literary service both here and abroad. You can expect us to go after the Nordic countries.

Has the “market” for new companies changed?
Yes. During the last year more of my former colleagues have started compa- nies of their own! It’s even come to the point where venture capital has a prob- lem finding something to invest in…

During our interview Bokilur’s other programmer, Andreas Melvanius, kicks in.
- We have a problem.
It turns out that a single Nokia phone is thrown into silence. A quick round of questions and they agree on some new tests.
After a while Jon asks whether I’d like a tour of the ”pavilion”. Walking in the corridors, we find a new com- pany behind every door. I cannot help but being impressed, such diversity. We stumble upon solutions for detecting schizophrenia, simulation of combus- tion engines, cameras that can see in fog and darkness and so on. I leave the barracks feeling elated – I too want to start up my own company.

PS. Curious about the Bokilur applica- tion? Check out www.bokilur.se.
PPS. Bokilur later changed their name to StoryTel.com
Originally published in JayView.

Bert R working on his sauna raft.

Bert comes across as the wise ol’ programmer who has seen most of what there is to see. Always in a good mood, I find it hard to see him loosing his cool despite being probed with difficult questions. But first, let’s start off with a simple question.

What’s it like being asked to comment on just about everything under the Sun?
There are two problems. If you have worked long enough, people expect you to be an expert at everything. The truth is that you only know a fraction of what is needed, but I do know who to ask.
Another major problem are magazines. They are mainly interested in either new information or mud raking. Some are seriously interested in what has happened, others... they only want to talk about things that don’t work. But it is my job. I just try and answer the question. Sometimes it’s actually flattering that people think I know so much.

Open Source has become quite important to Sun of late. As I understand it, you’re going to open source all of your code. Why?
It is correct that we plan to release all our source code, but I would like to point out that there is no time plan saying that at a certain point in time all the code will be released. The most important open source project for us now is OpenSolaris. The cat is, so to speak, out of the bag. We have been discussing this for several years. Once we took the decision, we needed to wash the code and make sure we had the copyrights to do this.
The effect is quite positive. We now have a community around OpenSolaris 10, and version 11 will contain features that wouldn’t otherwise have made it in there without the community. And bug tracking of course. Plus it defused the Linux versus Solaris debate. We can now discuss things with our customer in a much more interesting way. Someone at Sun said “It’s not about the code stupid, it’s about the dialogue!”
Internally it has also been a vitamin injection. Involvement is a lot higher. Everything we wished for has happened.
There was a suspicion that we would only let go of the old stuff. Instead we released innovative bits like DTrace etc. This has the positive side effect of code going cross operating systems. For example: a group of people are working on a distribution of FreeBSD, which will include DTrace. That’s one example of code becoming de facto standard outside the GPL arena.
Other high priority Open Source projects from Sun are OpenOffice and Netbeans. The end result of all of this is that we get more competitive. We get better tools and the risk of stagnation disappears.

What is the story with CDDL (pronounced “cuddle”), Common Development and Distribution License? Wasn’t the Mozilla open source license good enough for Solaris?
I’m no expert on licensing but CDDL is based on Mozilla except for the one paragraph that states that the license can be changed at any given moment. It doesn’t even require any approval. Our big clients don’t accept this single difference.

Most readers of JayView already know about the resurgent Javaforum. Apart from that, what is the status of Java in Sweden? Can you spot any trends?
Trends are meta trends and so... What I see from my angle is that Java still dominates the server side. Microsoft probably would have hoped that it would have made a more visible dent in the server side of things. We see very little impact from Dotnet among our customers.
The meta trend is SOA and web services and how to interact in a mixed environment such as Java and Dotnet. We work together with Microsoft on this and more is going to happen. J2EE dominance on the server is not threatened. From a customer point of view, it’s good to be able to encapsulate web services in the different worlds and that there is a consensus on how to interact between the two.
Looking on Java end-to-end, we’ve only started. There have been problems with limited midp hardware and different profiles between small devices. These mobiles will be more powerful. The problem of coping with differences between small platforms will be forgotten in 5 years.
We’re not there yet... but the APIs will be the same and so on.

Q: Sun has had this ambiguous relationship where it both owns Java, but also lets it play with the programmers on the block. It’s not hard too find examples of changing times. Take for example the Apache Harmony project (an open source implementation of Java 5 SE) or the interest in dynamic languages and the effort to provide support for these in the JVM in Java 6 SE. Are Sun’s dual roles over Java changing?
There is a concept within Sun which refers to “church and “state” as far as Java is concerned. Some work within the state it’s no more difficult than that. Java is a big investment for Sun and we want to see it spread, to complete its potential. It’s important that standards are kept and that nobody can corrupt them. Journalists typically want to make a big thing out of this. Our customers think JCP (Java community process) works. Maybe it is true that Sun has been able to keep the two roles apart and at the same time have products.
One strategy that we have followed is that every time there has been a split view, a 50-50 vote, on any subject within a JCP committee, we haven’t used our deciding vote. We’ve actually let the other point of view “win”. I believe that off the record even IBM will agree to this. The common denominator for those who complain, is that they haven’t actually looked into the JCP. It’s rather quick work nowadays. In the beginning some smaller companies complained, but that has been resolved. It’s rare to hear someone say “Damn Sun”.

Java is more of an ecosystem than just a language. What’s the status of that system today? And where is it going?
A flora of tools and frameworks has grown up, but doesn’t necessarily run within the JCP. Java is sort of the centre and further out are things like Ajax. You can go far out from the middle of this system and that is a good thing. James Gosling himself thinks this is very good. He was asked what happens if something can be done smarter in a different language to Java.
“I’m all for it!” That goes for most Sun folks. There is no single person in the world that can answer all the questions within that field – that’s good.

At the far end of that ecosystem I actually place Microsoft and C#. Some of the recent improvements in Java were inspired by the “other camp”, just as ideas and open source flow in the other direction. To me this is “competing symbiosis”. Take away one and the other would stagnate, much like Internet Explorer vs. Netscape. What’s your view on this?
It’s good with competition, but I’m critical of the fact that Microsoft with a budget exceeding some countries’ GNP cannot produce anything better than a pure Java clone, C#, with some minor improvements. Pitiful! But then again, competition is good. The Java community has a keen ear for improvements.
I have to give Microsoft credit for building tools that are easy to use. But this is partly at the expense of power and has meant that some things have not been developed. For instance, I’m totally convinced that Excel is a threat to mankind. People make decisions based on small errors that are impossible to debug.
If we at Sun can maintain the power and at the same time increase ease of use.

What is the best/worst thing that has happened in Java?
The best thing that is happening right now it is that we succeeded with Javaforum. It’s an embryo for an independent organisation. Tremendous. On a more technical level there are lots of good things happening. One thing that I like, but I would not classify it as “tremendous”, is annotation in Java 5.
The worst thing that has happened in Java was Microsoft signing an agreement, only to break it again immediately after. That wasn’t nice – not funny at all. But what was funny was them being made to pay.

Looking into your crystal ball, where is Java heading? Is there a device that will _not_ hold a JVM?
Different times place different demands on tools. Java’s dominance will be broken sooner or later. For instance, there are more network-oriented languages at academic level. Old languages don’t die. Look at how much Cobol code there is.
Java was the fist programming language for the net and shows no signs of old age. I would guess that Java will have a lifecycle similar to Cobol. It will take hundreds of years before it disappears – ha ha.

It has been said that Java will be the Cobol of the future. I dare you to make a guess at when that will be!
20 years from now it will be legacy. Not within five.

I once managed to make James Gosling speechless. He was taking questions from the audience and I managed to sneak in _”What’s the meaning of Java, as in ‘what’s the meaning of life’?”_ What’s your take on that?
It was the first programming system built for the net, just as NFS was the first file system for the net. That was the meaning.

Dang, I thought that at least the last question would stomp Bert.

Originally published in JayView.

Jonas Bonér is the founder of AspectWerkz, an aspect oriented framework without the need for special compiler. It later joined forces with AspectJ, which could be described as the Father Christmas of aspect oriented programming in the Java world. He used to work for BEA in Sweden, but has recently joined Terracotta, San Francisco.

Jonas you’re a long term AOP advocate. When and how did you start with aspects and, perhaps most importantly, why?
I started using AspectJ back in 2001 and I was immediately very fascinated by the concepts of AOP, its power, beauty and ability to solve really hard problems in such an elegant way. I have always valued clean design and simplicity and in AOP I found a way of letting design and concepts map directly to actual code.
I started by using ‘policy enforcement aspects’, e.g. AspectJ’s declare error/warning, logging and tracing aspects, as part of the build process. After a while I gradually started to use it for more advanced things, such as security, transaction demarcation, persistence, caching, “unit of work”, design patterns etc. for better modularity, reusability, maintainability and simplicity.

Why did AspectWerkz and AspectJ merge?
The short answer is that the users needed a standard. But let me elaborate a little bit. During recent years the AOP landscape for Java has flourished. When a technology is new and immature it is usually a good thing to have many frameworks/products competing, since they can inspire and push each other and the technology even further, but when the technology matures it starts to become a problem. For example, the users might end up not knowing which framework, syntax and semantics to start using, since they do not know which ones will even be around a year later. If you see this happen a lot, like it did with AOP, then there is a need for standardization.
During 2004, AspectWerkz and AspectJ slowly converged, but the two projects were still focused on different areas and had complimentary strength. We had some discussions and both teams saw the need for standardization and felt that both projects as well as the user community would benefit from unifying the projects, roadmaps and teams instead of competing. So we decided on the merger that was announced in the beginning of 2005 and was completed with the release of AspectJ 5 at the end of last year.

So where do you think we’re heading for in the future, as far as AOP is concerned?
I am confident that AOP will play an important role in the future of enterprise application development. Many vendors are already starting to embrace AOP as an enabling technology for separation of concerns, transparency, simplicity etc. For example Terracotta DSO, JBoss EJB 3, TopLink, Spring etc.
These are all examples of vendors using AOP to layer infrastructure services on the user’s domain models in a transparent fashion. That is great, but I hope that it won’t stop with that, my wish is that users will see the value of using AOP in their application specific code, in order to achieve more modular design, code that is more easily written, understood, reused and maintained. In some ways AOP had a healthy backlash over the last year, which has removed most of the hype around it. It has matured, has a standard in AspectJ 5 and is ready for real-world deployments.

Tool wise it seems that we have several things in place in Eclipse/AspectJ/ AJDT to get a good grip on aspects. Examples: being able to see what code an aspect affects, diff engines to compare changes to an aspect etc. Do we have all we need?
The AJDT team has done a tremendous job and I think that we have already come a long way, even though more work can of course be done and needs to be done in this area. But while this is true for static views of the system, like AJDT is showing, there is almost no support for monitoring and introspecting the runtime view of the system, something that is getting more important now when the usage of dynamic AOP is becoming more widespread, which has the ability of redefining the behavior of the system at runtime. This is an area in which I hope that the academic community will contribute more in the future.

Can you see anything that needs to be fixed or added before we see more widespread adoption of AOP?
I think that the most important thing now is education trainings, books, articles etc. We need to try to reach beyond the group of “expert” developers. Another thing is a standard library. We need an ADK (Aspect Development Kit) in the same sense that Java has its JDK. I am involved in an attempt to gather and develop a set of library aspects for AspectJ 5, and we’ll see where that leads. Finally I hope to see more best-practices, patterns as well anti-patterns emerge.

Terracotta, the new company you work for, has a distributed cache product. What’s so cool about it?
It is completely transparent. Meaning that zero code changes are required to cluster an arbitrary J2EE application. Our only requirement is that you have to write a correct multi-threaded application. We then take that multi-threaded single VM application and a tiny bit of XML configuration to declaratively specify what should be shared, lock semantics etc., and turn it into a multithreaded multi-JVM application. These are the features I find most interesting:
* True transparency.
* Noserialization.We only send the actual changes to an object graph (the delta) as well as keep track of who is referencing who, so we can send these changes only to the nodes that need it, e.g. lazily.
* Object identity is preserved. We maintain Java’s “pass-by-reference” semantics, so regular object references work, which means that you can use your domain model the way you have designed it, as well as traditional OO design patterns etc. without a need to think about distribution, caching or clustering. • Coordination and memory manage-ment. We maintain the Java Memory Model transparently throughout the cluster, including distributed coordination, for example wait(), notify(), synchronized() etc., distributed garbage collection etc. We work as a virtual heap, meaning that you can for example run an application with 200G heap on a machine with 4G of RAM in which we then page in and out the heap on a demand basis.

How does it work?
We use AOP technologies to adapt the application at class load time. In this phase we extend the application in order to ensure that the semantics of Java are correctly maintained across the cluster, this includes object references, thread coordination, garbage collection etc. For example, we extend the semantics of a regular synchronized block, or actually maintain them across the cluster, by taking a global lock for the object instance that you are synchronizing on right before entering the block and releasing it right after exiting the block. You can declaratively define the exact semantics for the block, e.g. read, write, concurrent etc.
Another example is the invocation of notifyAll(). Here we turn this call into a cluster wide notification, which will open up for all nodes to contend for the lock.
The architecture is hub and spoke based, meaning that we have a central server which manages the clients, we use TCP/IP so the server just needs to be somewhere on the network. The client in this case is simply your regular application together with the Terracotta JAR. People always ask whether the server is not a single-point of failure, but we have a SAN-based solution to support fail-over in an active-passive manner. You can have an arbitrary number of (passive) servers waiting in line and upon failure the selected one will pick up right where the master server that has crashed left off.

Finally, as an active open source contributor, do you have anything up your sleeve for the future?
I have some ideas, but nothing I can talk about now. Stay tuned...

Something tells me that we will hear more from Jonas Bonér.
His cold? Well the trip actually made it go away. He made JavaOne with half an hour to spare. I guess it’s that Viking blood.

Originally published in JayView.

Axis, a well-known creator of print servers, network cameras etc has done just this. They took one of their print servers and added Java for a big time printer manufacturer in Japan. How did they do it? And what did they learn? I teamed up with three of the people – Jens Johansson, Kristofer Johansson and Stefan Andersson – behind this Java enabled print server to get more of the gory details.

The Start

The project started around four years ago with a prototype after some seven months. The release onto the market was roughly one and half years ago. The first step, however, was to assess the feasibility of it. Could they perform to their customer’s demands? What type of handling of Java classes should they use just in time (JIT) or ahead of time (AOT) compiling? Even the choice of hardware wasn’t given from the start. Should they use third party chip dedicated to running Java or do it themselves? The former would have meant a bus and shuffling data in between the main chip and the Java chip.
Not interesting. Ten man-years later, here’s what they
ended up with.

A schematic view of the print server and its different parts. The functionality is extended by uploading Java classes as a normal jar file.

The Box

First off they had to decide which road to travel – base it on a hardor software? Roll their own or go third part?
Buying an ASIC block doing the Java and integrating it on their chip architecture would have been very expensive and wouldn’t have resulted in a cost effective system. Buying a third-party chip? That would have meant hooking it up on the system bus and making the whole system rather complex. In the end they settled on a software solution and doing it themselves.
Basically they took the Axis ETRAX 100LX chip, added more memory and used software to implement the Java support. The ETRAX 100LX systemon-chip is a 32 bit, 100 MHz RISC CPU. The design then uses the Java 2 Platform, Micro Edition (J2ME) with the CDC and Foundation profiles. This resembles the abilities of a PDA or a set top box on your TV.

The Java foundation classes reside in a separate memory and are loaded by the print server before any uploaded jar files from the file system on the board are run. The memory is divided into a 16 MB file system and 16 MB for all the executable code including the Java Foundation classes. Add to this a 64 MB RAM that houses the system, of which approximately 13 MB is used for Java. This is considerably more than the standard print server that typically has 4 MB of memory.

The operating system is Axis’ own proprietary RTOS for embedded systems. The unit consumes a sparing 0.3 W.Add to this a USB port and you get a pretty good idea of this competent little circuit board.
You change the function of the print server by uploading an ordinary Java jarfile. These compiled classes are then run on the print server and have access to the various ports and, of course, to its printer.
There is even a remote call possibility (RMI) to query the server for its status et al.

The result

Even though there were apprehensions at the start of the project about the performance, the result speaks for itself. CaffeineMark 3.0 is a Java benchmark. It is used to measure the speed of a Java Virtual Machine (JVM) running on a particular hardware platform. The test is calibrated to return a score of 100 running on a Pentium 133 MHz using Windows 95 and Sun’s JDK 1.1 interpreter. Even though this feels like an old PC, it does give you a good reference point for embedded solutions.
Axis’ print server landed on an impressive 60. This result is even more to write home about since the entire floating-point math is done in software.

The Lessons Learned

As with most projects, there were problems to overcome. In this case the floating-point library proved to contain bugs. The TCP stacks used at Axis were different compared to the Sun version. There were compiler issues going from Java to C. As coup de grace they needed the Java logo and that meant going through a grueling TCK test (Technology Compatibility Kit). This is a suite of tests, tools, etc that provide a way of testing an implementation for compliance with a Java.
”This has been among the most complex printer projects we’ve done ”, says Jens Johansson with a weary smile. However, the Java portion worked without any major problems as soon as the foundation classes were in order. ”For one and half year we haven’t had any Java related bugs”, explained the tech lead Kristofer Johansson.
They chose AOT compiling to implement the foundation classes, but this meant a large code base and it took time to implement. Hindsight is one of the best visual aids: might it have been better to use JIT instead?

Possibilities

So techno stuff is all just fine, but what can we do with this Java enabled print server? Ever forgot about an important printout that shouldn’t lie around? Well, why not a simply hook up a card reader? Once you arrive at the printer you swipe your card and, presto, your pulp stack pops out. Authentication and authorization could be done against an LDAP server.
Still too simple. Why not implement a distributed load-balancing scheme for printers – next available printer pulls a job from a print queue somewhere. Need more power? Just hook up another printer to the network. Could I combine the print server with a web camera and motion detection? Add something to sample the temperature and we get surveillance, fire detection and printing to go.

Puleeze Axis, can I get a couple of print servers to try out?

Originally published in JayView.

A scrum is when the teams pack in a special formation in rugby, head to head, in order to gain possession of the ball.
Here is the opening explanation from Wikipedia, assuming someone didn’t change it after printing.

“Scrum is an agile method for project management, first implemented by a team led by Jeff Sutherland at Easel Corporation in 1993. It has been called a ”hyper-productivity tool”, and has been documented to dramatically improve productivity in teams previously paralyzed by heavier methodologies.”

That sounds too good to be true! What is this?

* A scrum is when the teams pack in a special formation in rugby, heads to heads, in order to gain possession of the ball.

The short story

Scrum is an agile, iterative process where small self-organizing teams focus on producing a working demo of the system at the end of each sprint, iteration. One such sprint is typically four weeks.
The product owner handles the product backlog. This is a list of prioritised features or activities. At the start of a sprint, the team and product owner collaboratively select a goal for the coming sprint. They then select the product backlog items that best support that goal. These backlog items are then decomposed into the necessary tasks. This is known as the sprint backlog. While the team may add or remove items on the sprint backlog during the sprint, the sprint goal remains unchanged.
Through 15-minute daily meetings the team shares status information and the Scrum master removes any obstacles (impediments). The Scrum master controls the process, but the team is totally in control of the implementation.
An executable is presented at the end of the sprint. After this demo, a new sprint starts and a sprint backlog is created.

An overview of the Scrum process.

What is the problem anyway?

Several methodologies assume that building a system is something you can define or specify up front. The struggle to attain this level of confidence is often a difficult up hill marathon or just plain futile. Even small projects need to adapt during their implementation. Scrum, on the other hand, recognizes
that IT is so complex that the only way to control it is through an empirical process. Watch the process. Constantly monitor it in order to get the desired output. The complexity, or our inability to fully understand the problem, has become a dogma.

Who’s who?

The roles in Scrum are actually quite few – Product Owner, Scrum Master and the Team Members.

The Product Owner

First we have the product owner, and this perhaps is the easiest role to understand. This person handles the product backlog and is responsible for setting the priorities for the product.

The Scrum Master

The Scrum master is not far from being a project leader if it wasn’t for the many things he/she does not do. The Scrum master protects the group during the sprint, removes impediments that hinder development and guards the process itself. He or she does not hand out assignments, dictate a solution or even make decisions for the team.

The Team Members

This cross-functional team is made up of around seven people with different background – programmers, testers, etc. They self-organize and structure their work. This means they alone decide on how to form a working group that can implement a solution to reach the sprint goal. This is important and slightly terrifying. Scrum seeks to unleash the group’s potential to strive for a goal as effectively as possible. The group therefore not only has the normal burden of obligations, but more importantly the right to decide how it should be done. This means the group could decide to use its cousin XP (extreme programming) as a base for their development model or perhaps RUP.

Why so few people? In order to get a closely-knit development with fewer overheads, as is typical in agile projects, the group cannot be too big. Even the physical distance will affect the outcome. Going further than a ”coffee cup walk” could be a problem.

Why so many people? I’ve heard people say that a group should not extend beyond 3-4 people in order to stay tight and focused. Scrum, on the other hand, seeks to reach hyper productivity where the group is drastically more effective at cranking out solutions. Call it synergies. Call it direct coupling of brains. Whatever the name, people can be a lot more effective when interacting without obstacles. You get too little of this if the group is too small.

The Process

Scrum is built up around the sprint, or the iteration. Though before we can start, we need a Product Backlog. This list contains everything that needs to be done on the project – stories, activities and so on. The product owner prioritizes every item.

The Sprint Planning Meeting

The sprint planning meeting sets off the iteration and produces a sprint goal and a Sprint Backlog. The goal and this list is the sole target for the team during the sprint. Tasks may by adjusted or split during its course, but no new no product backlog items can be added to the sprint. No boss sidetracking the Scrum master, no desperate plea from the salespeople can alter the backlog. This produces a box of calm that lets the group do real work instead of endless switching between tasks and trying to hit a target that is constantly moving.
Is there no way to change the list? Well, there’s the simple case when tasks are completed faster than planned. The group can then decide to take on more tasks. In some cases, the product owner can OK changes to tasks in order to meet the deadline.
And of course there is the ultimate change the sprint is cancelled; but that is a rather drastic measure.

The Daily Scrum Meeting

How do the team steer the work effort? How does the Scrum master know that all’s well? The answer is the daily Scrum meeting. This meeting lasts roughly 15 minutes and each team member is responsible for answering three questions:

• What have you done since the last Scrum meeting?
• What is preventing you from doing your work?
• What will you do until the next daily Scrum meeting?

The Scrum master will pay close attention to what is said and how it is delivered. Are the team members doing what they should be doing? Is work progressing as it should be? Is the group functional or is something hindering it from performing?

Tracking

To track progress the team uses a Sprint Burn Down Chart. In this graph we can find the number of hours left to do and the number of days available. Hitting deadline is then a question of making sure the line reaches the x-axis by the last day.
In the example graph above we can see that the group’s remaining hours actually increased around day five. The level of complexity was fully understood at this point in time. On day six a meeting with the product owner resulted in a change in ambition and made it possible to reach the sprint goal, albeit with a reduced ambition.

The Sprint Burn Down Chart. Each Scrum team tends to have a ”signature” on how the remaining hours de- crease. Note the bump around day five.

The Sprint Review Meeting

The sprint’s final meeting is the review where the most important piece of artifact is shown to the product owner and others who might be interested – the executable. This piece of code should be something that is actually running. It might be small, it might just do one of the many things it will do in the end, but it is real. This means that there are no mockups, no PowerPoint slides and no dummies – just real stuff.
This concludes the sprint where we’ve done all the designing, coding and testing that is needed to get the executable part of our system to do a demo.
One more thing; the artifacts we need are marked in bold above, not a lot and very focused.

Scale? Control?

Having come this far you might be saying:
”This all sounds all well and good for the programmers, but it can’t scale.”
Actually, it can. By setting up a Scrum of Scrums – the Scrum masters from different projects form a Scrum of their own – you can scale up, as Jeff Sutherland has, to more than 500 people.
I asked Sutherland whether Scrum doesn’t fail sometimes:
”A high estimate would be that 5% fail, but they do so in two weeks.”
There are a lot of projects that take a lot longer to implode than a mere two weeks.
Scrum accommodates the complexity of IT and can increase efficiency drastically. It’s all about common sense and daring to live close to chaos. You let the team free and then check progress. Set free and monitor. Let go in order to gain control – a true paradox.

In conclusion

The process, the artifacts and hopefully even this article are easy to understand. However, Scrum is more, it is also a mindset. Without a deeper understanding of the process, the desired effects might not just appear. It’s a bit like mimicking Rembrandt, armed only with the angle and speed
of the master’s stroke. This is the only project management method that I’ve found I can relate to. So my final question has to
be... You wanna Scrum?

Originally published in JayView.

Det fanns en tid då Java-utvecklare kunde samlas för att ta del av det senaste inom Java och dessutom mingla. Efter några års dvala är det nu dags att starta denna uppskattade form av kompetensutbyte igen. Fast nu kommer vi i en starkare version både ansikte-mot-ansikte och på nätet.
Java handlar om öppenhet och samarbete. Javaforum är ett sätt att förverkliga visionen.
”Det finns dessutom stora synergieffekter i att koordinera aktiviteterna” säger Bert Rubaszkin (Sun), en av de drivande krafterna bakom JavaForum. ”I och med Jayways engagemang i Javaforum börjar nu ett stabilt fundament för ett långsiktigt samarbeta att ta form. Nu förväntar vi oss att andra intresserade partners, som är beredda att engagera sig i detta hör av sig!”
Seminarierna kommer att variera från det praktiska till det teoretiska, från det lilla till det stora men alltid vara intressanta.
Du är hjärtligt välkommen till Javaforum.

Kom in och anmäl dig nu på javaforum.se, så är det redan klart!

Urkopplad Nästa forum är den 23 mars kl 13:00 i Jayways nya lokaler på Hans Michelsensgatan 9. Skriv till bjorn.granvik snabel-a jayway.se och anmäl dig!
Direktkopplad www.javaforum.se

Vi ses!
Originally published in JayView.

The conference in our own backyard got off to a very good start indeed and featured internationally renowned speakers such as Eric Evans, Rickard Öberg. Kai Tödter etc etc. The number of attendees was 320 and they came from as far away as Copenhagen and Gothenburg. “Own backyard” is quite literal since Jayway was one of the principal organizers. Nevertheless, why not try and analyze our own effort?

Trends

As Java fans we had not only the Java track to enjoy. The Methods & Tools and Embedded tracks contained several interesting sessions with a Java base. This made it sometimes difficult to choose between colliding talks, just as it should be.
Looking at the reviews from the sessions, we find “9 ways to hack a webapp” at the top. It was a great talk given by Martin Nystrom (yes, there are no dots above the “o”) – but somewhat embarrassing. The “I’ve made that mistake!” feeling was a bit too apparent. The top position of this talk came as no surprise. JavaOne attendees gave it an honorable second place in a review of all presentations given there.
The talks covered a lot of ground. They ranged from the challenges of implementing Java on a mobile phone to 64-bit technology and its effects on the JVM, from standards like EJB3 to up-and-coming technologies like aspect oriented programming. On the anecdotal side we note Bert Rubaszkin, Chief Technologist at Sun Sweden, who in his “10 years with Java” talked about several achievements. Some of the examples included Rickard Öberg sitting in the audience. Times flies by faster within IT. Or, better still, it’s just the family!
A few rough edges around the conference were apparent: the sun (yes, the one in the sky) together with a curtain on the loose, made life difficult for some lecturers on the main scene, nothing that can’t be fixed for round two of this annual conference.

Mingling at Øredev 2005

Conclusion

The success of this, the first, developer’s conference in Öresund is promising. The conference will return this year in November. Let’s hope it continues to build on its promising start.

Originally published in JayView.

DDSteps is on open source project the brainchild of Adam Skogman which aim to make sense of your unit tests when they consist of god knows how many permutations of input. Read on to find out exactly how.

A Typical Project

Let us tell the tale of a too-successful project. It all started out as a prototype web site, quickly hacked together over a week to show to the investors. Big hit! Some swift fixes later it went live slow, rocky, but making money. Refactoring the code was an inevitable next. As new people joined the project, test driven development was introduced to make sure that programmers did not break each other’s code. The unit tests covered more and more of the code. Even the happy hackers in the group had to admit that things were getting better and bugs were fewer.
The business side of the now booming company poured new feature requests into the development and demanded that they appear in production “real soon”. Therefore, a shorter release cycle was introduced, releasing every month. Also, a quality assurance test team was set up to test each release. So developers had to “pre-test” the release before the test team got it. Testing now took two weeks. Bugs were all around and had to be corrected. At this point the site went global, requiring small specific changes for each country.
This is when it all broke down. Testing now took over a month and bugs were often reported months after the release was made. Nobody wanted to re-release and do all those tests again, so the site went into production with known, serious bugs. It was at this point that the programmers went: “Aaarrrgh!”

The Remedy

Testing your solution for every type of input and making sure it will pass function tests is difficult at best. Usually, this is done “by hand” and requires real people. And, yes, it is boring and time consuming. So you have to automate it, just like you did with JUnit tests for unit testing.
By Function tests we mean, ”Does it work like the use case says it should”. We mean full, system, end-to-end tests, using a production-like environment. We mean using a browser, surfing the web application and then checking the real database for results.
Automating function tests is hard, mostly since they suffer from the same problem as the manual testing. Many of the tests are the same; just the data is slightly different in each test.

Data driven testing on the other hand separates the testing code from its input. This and the reusable test steps makes it easy to maintain and evolve the test cases, you get reuse instead of copy-paste. Need another field? Just add new column in your input and handle it in your test case and voila. There will be no explosion of test methods, no massive round of changes!
Ok, let’s start from the top and look what DDSteps is and how it makes your life easier.

Figure: Overview of the DDSteps’ process. 1) Input is retrieved from an Excel file and populates your test cases and test step POJOs. 2) Yellow is your code. TestSomething is your test method that (re)uses different test steps. 3) The fixture F typically sets the database in the correct state for the test. The Navigators, Executors and Validators in this example use JWebUnit to perform their respective step. 4) Output – reports, console etc.

Since most tests are the same, with just different data, first we separate data (input) and the test code. The data, found in an Excel file, is inserted into your test case, each row becoming a test case run. The second important part is the framework of reusable test steps. Test cases are broken down into steps:

• Fixture – set up the needed data in your database.
• Navigator – Navigate your web site.
• Executor – Input data into the system, like filling out a form on a page and pressing a button.
• Validator – Validate the output on a page or a row in the database etc.
• Cleaner – Clean up any mess you have made.

You implement these types of test steps using for instance JWebUnit and Spring JDBC. You can easily imagine that many test cases will use the same executor, since they pass through the same web page, so reuse is everywhere.
Finally, DDSteps is just standard JUnit, so the test outcome is reported back via Ant, CruiseControl or your preferred JUnit compatible IDE. It integrates perfectly into your existing environment.

Divide and Conquer

Let us dive deeper. Again, how do we separate data from the code? You can do this several ways. We chose to use Excel. It’s not only easy to format and to enter data, it’s a de facto standard and you can use formulas etc. And if you want you can always use OpenOffice.
Let us take the following use case from PetClinic from Spring – ‘Add new pet’.

Figure: Use case ‘Add New Pet’. Green is data that is put into an Excel file. See next figure. The letters N, E and V are our test steps for this use case.

We have now divided our use case above into reusable test steps. Next is the Excel file. From our test case we can see that we need: Owner, pet name etc.

Figure: The Excel file that holds our input and fixture data.

Each test method is entered on separate worksheets. The fixture data we need for the database is entered as well. DDSteps find your test data in the spreadsheet using the method names in your test code, and uses JavaBeans get/set to inject data into your test case and your test steps.

Code

Next is the test code. Let us look at just one part of it – navigating. The example covers points 1-6,7 of the use case, i.e. the first and second test step. In order for this part to work our HTML pages need to be written with JWebUnit in mind, i.e. an id is put on elements, so that we can find it and “click” etc. Let us assume this has been done. We also use Spring even though this is optional.
The test case would then look something like this.

PetclinicTestCase.java

// Our test case, see PetFTest.xls for input.
public class PetFTest extends PetclinicTestCase {

    protected NavigateToAddPet nav;
    protected ValidatePetForm valForm;
    ...

    // The test method, same as tab name in Excel file.
    public void testAddPet_Ok() throws Exception {
        nav.runStep();
        valForm.runStep();
        ...
    }

    // Used from data file to access navigator properties, e.g. “nav.name”.
    public NavigateToAddPet getNav() {
        return nav;
    }
    ...

In the code snippet above we declare our PetFTest test case that inherits from PetclinicTestCase. This base class only holds common things like web browser, fixture etc. The test method testAddPet_Ok is simple and reduced to only use necessary test steps, nav (NavigateToAddPet) and valForm (ValidatePetForm).
Also note that we have getNav() which is used as the first part in the data file “nav. name”. The access to properties is JavaBean based, i.e. using get/set methods. We will only look at the first test step, the navigator NavigateToAddPet, since the other steps are similar in concept.

public class NavigateToAddPet extends JWebUnitTestStep {

    // Reuse another navigation step
    NavigateToOwner navigateToOwner;

    public NavigateToAddPet(WebBrowser webBrowser) {
        // The web browser is injected by Spring.
        super(webBrowser);
        navigateToOwner = new NavigateToOwner(webBrowser);
    }

    public void runStep() throws Exception {

        // Delegate
        navigateToOwner.runStep();

        // Click ‘Add new pet’ button,
        // which is the submit button in the form ’formAddPet’
        setWorkingForm(”formAddPet”);
        submit();

        // Snapshot of web page.
        writeTrail(”Add New Pet Form”);
    }

    // Full name is populated from ”nav.name” in the data file.
    public void setName(String name) {
        navigateToOwner.setName(name);
    }
}

This test step is a composite of another navigator, NavigateToOwner, and going to the “Add new Pet” page. WriteTrail will write specified html page to the hard disk, a visual page debugger if you will.

Run

Having come this far, we can now run our test code and get the result.

Figure: And finally the output, in this example, in Eclipse.

Oops, better fix our code! In the example above we see the errors per row, not just by test method.

What happened to the Project?

When our team employ DDSteps, they can automate their tests, and cut down the time for testing to minutes, not weeks. This means you can run all function tests every night or every time the source code changes! Suddenly, you can release to production with no bugs because as soon as you know there is a one, you fix it during ordinary development. Function testing is now a part of development, not an afterthought.

Conclusion

DDSteps both tries to break new ground and to reuse solutions perfected by others. We think it is a good mix to implement function tests using data driven testing. Is it for you? Who knows? Get it from www.ddsteps.org to see for yourself.
Originally published in JayView.

The story so far....

Within J2EE, EJB has been seen as one of the heaviest technologies - not just for its complexity, but also from the point of view of the various factors involved in doing something. The list of “points for improvement” could be long. Onto the stage came Microsoft with its Dotnet, and began to use words like architecture. Sun, which still is used to sing in the final scene when it comes to creating major systems, realized that it had to be easier to develop with EJB, preferably without losing power. Cur- tain up! Enter EJB3 stage left!

Objectives

There were several objectives behind the new version.
New simpler configuration. Only state what is different – configuration by
exception.

• Encapsulate the beans to reduce dependency and knowledge of the world around. No artificial methods which are used, etc.
• Simpler persistence through simpler Java objects – ”Plain old java object” (Pojo).
• Support for lightweight modelling, easy to test outside the container (no need for heavy application servers).
• Support for inheritance, polymorphism, etc. Yes, that’s right! Actual object orientation!
• No checked exceptions, e.g. RemoteException.
• ...and a whole pile of improvements.

In other words: easier, simpler and neater! Let’s take a closer look to see how successful they were.

Metadata

One of the first simplifications was to make use of the metadata which comes with Java 5 (JDK 1.5). To put it simply, it is a way of describing the code from a more comprehensive point of view. For example, why write long XML files when it should be enough just to say, “This method must be accessible from all machines.”

In our example, this will be ”@remote” in front of the method name. Obviously much simpler!

However, this has some unexpected effects. Now there are many new different meta settings and above all their default values. You don’t need to use all of them, but what is needed is new knowledge. Nevertheless, I still think it is better. The alternative would be to do as in the current version of EJB, where one is forced to always state values for all settings.

A simple bean

So let’s look at some code! A stateless session bean is the closest we get to “Hello World” with EJB.
Do you remember all those methods, for example ejbCreate, which had to be implemented despite being empty? And don’t forget the various interfaces and a description file with lots of XML.
Why not like this?

@Stateless
@Remote
public class FooBean {
    public void printBar() {
        System.out.println( ”Bar” );
    }
}

Much better the way I see it. Stateless indicates that this class is a stateless session bean. “Remote” indicates that it must be capable of being called from an- other machine. In reality more settings are needed but these either have standard values or are retrieved from the code. In the example we quote above, for instance, an interface file is generated, which we can later use in e.g. a client program which will call up the server.

And a session bean that saves its state isn’t all that much more difficult.

@Stateful
public class BarBean {
    @Tx(TxType.REQUIRED)
    @MethodPermission(”guest”)
    public void orderSomething( String aDrink ) { ... }
}

This time we had both transaction management and security. Note that it is just as easy to order an alcohol free alternative .

A wilder bean

However, the great challenge with EJB 3 isn’t the session beans but the entity beans (CMP/BMP). The principle for saving these in a database has seen a real change. Gone are the monoliths that were connected to the mother ship, the application server.

An entity bean is marked with ”Entity”.

/** Our customer Pojo. */
@Entity public class Customer {
    private Long id;
    private String name;
    // A customer has one address.
    private Address address;
    private Set orders = new HashSet();

    // Our primary key
    @Id(generate=SEQUENCE)
    public Long getID(){
        return id;
    }
    protected void setID (Long id){
        this.id =id;
    }

    // A customer has zero or many orders.
    @OneToMany(cascade=ALL)
    public Set getOrders(){
        return orders;
    }
    public void setOrders(Setorders){
        this.orders =orders
    }
    ...

All fields in the class are saved unless otherwise stated. Access to these fields is typically based on get and set methods in precisely the same way as for ordinary JavaBeans.

Both the name of the table and the columns are calculated in this case from the names we gave them in the code. Naturally, we can specify something different, but for the sake of simplicity we take a straightforward approach here. It is also possible to put the configuration in separate files - as previously – and in this way we could override the meta settings.

The first reference to another class is ”Address”. If it is marked as persistent, these instances are also read and written automatically.

Our primary key is “id”, which also contains information on how to generate new IDs.

We have also generated an Order pojo in a similar manner. The relation to this is written with “OneToMany”, as a customer has several orders. Order relates back to our Customer in the same way as the Address field above, thus the relation is two- way, which differs in outlook from a relational database. You will find an example of this further down in the article.

If we have read in a customer from the database, we have also automatically received that customer’s Orders. This will be an object tree where the root is the customer with his primitive values and references to the other sub-object Address and the list with Order.

Finally, the relation from customer to order is set as “cascade=ALL”, which speci- fies how events such as “save”, “delete”, etc are to be propagated. In the example we send all on to all order objects in the list.

Read a little, write a little

Let’s move on to retrieving a customer from the database. Therefore we insert a ses- sion bean that does just that. First we must acquaint ourselves with what replaces the application server – “EntityManager”. In a loose sense this class represents our database/session and manages the lifecycle for our pojos. It also contributes to gene- rating our queries (Query) to the database.

First a session bean:

@Stateless
public class OrderEntryBean {
    @Inject private EntityManager em;
    //...
}

Inject allows us to manage our pojos, i.e. get into the database – search, generate, etc. EntityManager can come from anything; it need not be an application server, but maybe a somewhat simpler test bench.
Now we can insert a method for searching for customers who have a certain name.

public List findByName (String name) {
    Query q = em.CreateQuery ( “SELECT c FROM Customer c ” + “WHERE c.name LIKE :custName ” );
    q.setParameter(“custName ”,name);
    q.setMaxResults(10);
    return q.listResults();
}

The result is a list of the customers which matched the names we included. Re- trieving the value of these is quite simply a matter of looping over the list and calling up get and set methods.
Now we’ll make it a bit more difficult and add an order.

public void enterOrder(int custID, Order newOrder){
    Customer c = em.find(“Customer ”,custID);
    c.getOrders().add(newOrder);
    newOrder.setCustomer(c);
}

The relation is two-way and therefore they both require a reference to each other.
As yet the object is not in our database. Somewhere we have to tell our Entity- Manger to do the job and save our customer “c”.

em.create(c);

The customer is already in the database and will therefore be ignored. The event “save” will be sent on to sub-object (cascade=all) and the order we had stored in the database.

EJB QL

The new specification does not just involve simplifications. We also have entirely normal improvements to EJB QL, for example:

• bulk processing of delete and update,
• group by, having,
• sub and dynamic queries,
• and more functions (UPPER, CURRENT_DATE, etc) and so on.

One of my favourites is probably a polymorphism, which can already be used here:

SELECT avg(e.salary) FROM Employee e

So if Manager now inherits from Employee, we will obtain an calculated mean value for everyone – both ordinary employees and managers. Though maybe it is a less interesting example to mix up salaries like this .

When and how?

If we use the number of pages in the specification as a mark of how much more needs to be done, then there is a lot. EJB 2.1 weighs in with a brave 646 pages. The draft of version 3 is more modest with 93. Moreover, many aspects invite discussion. At the time of this writing a second draft has been released. It is now divided into two documents – persistence is kept seperately. Combined they land at nearly 200 pages.

It’s going to take time. I hardly dare guess where the horizon lies. Shall we say a year before the specification is ready? And should we add another year until it is generally available? True enough, this is my pessimistic side talking - I hope. There are already some versions which, so to speak, comply with the standard. That’s why “now” is a good time to prepare for what is to come.

Would you like to have a deeper understanding of what it’s like to develop such a solution? Trying out a Hibernate/Xdoclet combo is good idea since it is so similar EJB3 persistence. If you are interested in experimenting, JBoss has a beta version of the EJB specification based on Hibernate.

Brave new EJB?

Yes, in fact. Sun has chosen the right path to take. And for that they deserve praise. It requires courage to break with old doctrines. The “old” EJB was a heavy affair which hasn’t exactly made life any easier for us programmers. But – and there’s always a but – the new specification is both simpler and more complex. The complexity is tied up with the new power that object orientation, pojos, etc gives us. But extra
power tends to require extra learning. There are going to be quite a few more ups and downs before we can set the “pedal to the pojo”.

Resources
JSR #220 http://www.jcp.org
Hibernate http://www.hibernate.org
Jboss http://www.jboss.com

Originally published in JayView.

Med denna varning ur vägen och utan eftertanke, låt oss dyka in i Javavärldens största konferens för programmerare – JavaOne 2004.

EoD

En av de viktigaste drivkrafterna på sistone hos Sun är EoD, Ease of Development. Denna idé om att det måste vara lättare att jobba med Java har fått starkt fotfäste. Tack Microsoft! Tack för Dotnet och för att ni tvingade Sun att konkurrera på nya villkor.
Ta till exempel Sun Java Studio Creator (SJSC) 1.0 som presenterades under dagarna. Det är en vanlig utvecklingsmiljö förklädd till Visual Basic. Detta låter kanske inte så häftigt, men faktum är att både gränssnitt och den genererade lösningen ser bra ut – till och med om man tar hänsyn till demons glittriga yta. Listan med förkortningar, JSP, JSTL, JSF, etcetera är precis så vanlig Java som man kunde hoppas på. Sun kan mycket väl lyckas med att attrahera f.d. VB-programmerare, och kanske även gamla härdade javaiter, som vill köra J2EE med krockkudde.

Tänk er att kunna skapa en prototyp i SJSC för att sedan rycka ut olika lager och ersätta det med något mer industriellt. Jag håller tummarna för att Sun gör det rätta. Lite rita-dra-ochtesta-kod skulle inte skada för en gångs skull.

Mer EoD – EJB 3

Men det finns andra mer långtgående effekter av EoD. Ta metadata, dvs. att man kan berätta saker om koden. Man skulle enkelt kunna ange att en metod är ”remote” och vips så genereras de filer som behövs för att skapa en web service. Bästa exemplet är nog EJB 3.0 som hade en del riktigt enkla powerpoint-slajds – de var helt enkelt tomma. Det lilla som fanns kvar var uttryckt som metadata i koden. Applåderna lät inte vänta på sig.

Jag får erkänna att jag aldrig tyckt om EJB och framförallt inte CMP. När jag talat om bristerna har jag ibland känt mig ganska gnällig. Expertgruppen för EJB har gjort en rejäl sväng och skapat en bra mycket mer elegant lösning. Tänk er enkla Java-bönor med metadata (typ Hibernate med XDoclet) så får ni en rätt bra bild. En så pass ny kurs innebär att gamla sanningar utsätts för hårda prövningar. Vad sägs om följande citat från konferensen ”You shouldn’t have to be a rocket scientist to be an EJB-developer” eller ”the Data Transfer Object [DTO] anti pattern”? Det sista innebär inte mindre än en dogms död för vad god EJB-programmering har inneburit.

Något oväntat kanske, så hamnade de nu i samma säng som JDO – Java Data Objects – en av Suns andra persistenslösningar. Diskussionerna både bakom och framför ridån var intensiv under dagarna. Resultatet har tack och lov inte väntat på sig. De två expertgrupperna har precis kommit ut med ett öppet brev där man lovar att arbeta ut en gemensam lösning. Det lär ta tid, men det är definitivt ett steg i rätt riktning. Jag får erkänna att jag antagligen inte kan gnälla länge till.

Det finns långt fler exempel och gemensamt för dessa nyheter är EoD. Vi kommer att få se mer av denna katalysator.

SOA, nu med XL hajpfaktor

Det verkar finnas en naturlag som alla konferenser måste följa – minst ett ämne måste trissas upp. Flosklerna ska flöda och en exakt förklaring saknas. I år vågar jag mig på att utnämna SOA till huvudkandidat. Service Oriented Architecture var på många föreläsares läppar och tanken på en sorts gemensam arkitektur är lockande. Jag kunde dock inte förstå exakt vad det är som skiljer SOA från web services, möjligtvis är den senare ett specialfall av SOA. Nåja, gräv ner fötterna i jordmyllan och var beredd på att höra mer om detta begrepp. Det finns många intressanta tankar, men också en hel del floskler som vi hört förr. Det lär ta tid, men chansen är att det kommer på en server nära dig.

Klienter, feta som mobila

Vi har fått leva i flera år med anorektiska klienter (läs: webbläsare med uselt gränssnitt som bara en mamma kan älska;-) men det verkar förändras nu. Det är inte längre självklart att en klient måste vara tillgänglig överallt på bekostnad av användargränssnitt, funktionalitet etc. Under konferensen fanns det flera exempel på varierade klienter – det var allt från att löften om att kunna generera feta klienter ”i nästa version” till skräddarsydda mobila varianter.
Står dina användare fortfarande ut med tunna skal som blinkar och fladdrar? Jag gissar att de närmaste åren kommer fler av oss att rycka fram de gamla böckerna om gui och Swing för att vi glömt vad vi redan kommer ihåg.

Femfemfem

PR-avdelningen på Sun har slagit till igen. Förra gången detta hände fick de för sig att använda både 1.2 och 2 som nummer för samma release – den första var JDK och den senare det mer övergripande och luddiga Java 2 Standard Edition. Nu räknar vi upp hela härligheten till Java 5.0 eller var det JDK:n? Och vad var det nu J2SE skulle heta...
Vi tar det igen; 1.5 är det interna numret, 5.0 är det externa. Och tvåan i J2SE blir då det utomjordiska numret?

Far out

Första kandidaten i denna klass är Nasa och deras Rover – Marslandaren. Både den och program runt omkring använder sig av Java. Det var roligt att höra om deras lösning med robotarmar och allt som fanns på deras bilder. När de fick frågan om vilken databas de använt för att spara all bilddata, så spred sig ett förtjust fniss bland åhörarna – MySQL. Man behöver tydligen inte så mycket mer om man bara ska till Mars.

Den andra kandidaten är Groovy som är ett nytt språk från veteraner som James Strachan (Geronimo, jelly, dom4j, maven, Jakarta commons etc.). De hade lagt märke till att mycket kodande går åt till att limma ihop olika komponenter. Varför inte uppfinna ett nytt språk som gör detta och mycket annat lättare? Född var Groovy. Några absolut minimala exempel:

str = ”testing”
// Notera inget semicolon!

c = str[-1]
// c är nu lika med ’g’

s1 = str[3..1]
// s1 är nu lika med ”tse”

v=[1,2,3].find{it>1}
// v är nu lika med 2

I listan ”1,2,3” så letar vi efter den första posten som uppfyller villkoret vi skickat med (”it” är en sorts standardparameter). Vi kan alltså skicka med kod som ska exekveras!
Man behöver många fler exempel för att förstå hur häftigt det är, så jag ska inte ens försöka göra det rättvisa här. Groovy fick dock det att klia i mina programmerarfingrar.

Siffror och visioner

När Suns ledning talade var det många siffror. Det var antalet Java X, antalet miljoner dollar, antalet... ja, ni förstår. Allt var förvisso intressant och visionen var också ”Everything and everyone connected to the Internet”. Och jag fick onekligen en känsla att Java är med överallt. Scott McNealy uttryckte det mer subtilt när Sun fick en utmärkelse för sin marknadsledande Java Card och dess dominans:
We prefer ’interesting market share’.

Var fanns då den rena råa visionen, passionen? Mestadels hittade jag den i de olika grupperna, allt från expertgrupper inom Sun till, och kanske framförallt, olika kommuniteter (”communities”). Här fanns de galna idéerna, de lovande framtida teknologierna och de intressanta verktygen. Det gör säkerligen inte våra liv lättare på kort sikt, men jösses vad roligt jag kommer att ha det!

Originally published in JayView.

* Microsoft vs. Sun over the J2EE blueprint called PetStore. It resulted in a hot debate with many arguments.

I was sort of waiting to meet someone, well, far out. Instead this wholesome dude with a four-day beard greets me with a smile. I can't help but to think of a strong caffe latte smooth milk blended with mind-altering caffeine.

Q: SiteVision is the content management system (CMS) sold by the company you work for, SenseLogic. Ok, without any prenuptial agreement, let's get at the first question why?
Why do you use aspect oriented programming in SiteVision? After all, there isn’t that many product grade systems using aspects as a core design choice.

A: There are several reasons. When we began writing SiteVision we soon realized that we had to encapsulate reusable code in a number of places, especially features that were side effects of method calls. Object had to be saved on setter calls, events had to be sent, logging had to be done, transactions should be managed, and so on. We couldn't figure out a way to do it using standard technology, e.g. EJB, so the only solution was to use AOP.

We were also on a very tight schedule. In just a couple of months we had to build a commercially viable CMS-tool using only five developers, and after that we had to maintain and develop it at such a rate as to catch up, and pass, our competition. It really should be impossible, and it would be with standard technology. The solution was to avoid writing code by using AOP. AOP allows an extreme degree of reuse of code, and because of this we managed to write lots of features with a minimal effort, and since we avoided writing unnecessary code to a large extent it also became easier to maintain. In addition, since AOP makes it easy to add functionality incrementally we were also able to enhance the architecture and implementation as we went along without having to change much of what was already written.

Q: Why roll your own aspect engine? Why didn't you decide to use AspectJ or some other aspect-inspired tool?
A: After the decision to use AOP was made I researched the available tools on the market, and compared their feature sets with our requirements, especially with regard to code maintenance, performance, scalability. None of the tools, including AspectJ, had been written with such requirements in mind, so we had no alternative but to write our own tools. My background in EJB made it possible for me to combine the principles of AOP with our requirements in a good way.

In hindsight I can conclude that it was the right decision, and if I were to make the same decision today I would still do the same. There is, in my opinion, still a lack of good AOP-tools that support the demands of a complex server side application. The awareness of the importance of such tools is on the increase however, so I would be surprised if this has not changed by next year.

Q: AOP being a true paradigm shift what are the biggest changes when going aspect?
A: There are two things that stand out, from a design and implementation point of view. First of all it takes some time to learn to recognize "cross-cuttting concerns", that is, code that can be extracted into an aspect. Second, the use of static introductions as a design tool gives one a whole new set of posssibilities with regard to domain model design. Instead of using inheritance as the main building block for reuse of code one would use design by composition, which gives you many more possibilities for combining existing components. It takes a while to get used to this new freedom, but once you do that everything is fine.

Q: SiteVision is soon to go version 2. Has your view on AOP changed during the trip?
A: In the beginning I was, as most others seem to be now, fascinated with the concept of interception. What difffers now, almost two years later, is partly a realization of the importance of static introduction, and partly the understanding of how important it is to have a powerful pointcut model. AOP has so much more to offer than just method call side effects.

As for AOP in general it is great to see that more developers are beginnning to see the advantages of it, even though the examples often are so trivial that it's hard to see the point of it. I'm also waiting for more people to realize just how powerful static introductions are as a design tool, and the consequences this has for design pattterns and such issues.
It's going to be quite a revolution, and several tools that exist today in order to avoid the problems of current system design techniques are going to get a tough time.

Q: Do you dare to mention tools, or types, that will have problems?
A: I suppose XDoclet is the most obvious one. We are not using any code generation at all in SiteVision, and that is solely because we have been able to avoid all the problem of standard design principles by using AOP.

Q: Let's pull out the tarot cards. What's in the future for AOP?
A: The theoretical part of AOP seems to be stabilizing, but we will probably see more tools in the AOP space. Some people ask, "Why not only use AspectJ?” but I think that's like saying, "Why not just drive BMW?". There's nothing wrong with a BMW, but sometimes a Volkswagen works better, and sometimes a Porsche is the only choice.
As usual it's about choosing the tool that best matches your requirements, and I can't see AspectJ being able to match all different kinds of requirements at the same time.

Apart from the AOP frameworks it will also be very important to have good support tools, especially with regard to visualization of AOP systems. Since AOP to a large extent is about fragmentizing and componentizing code it can sometimes be difficult to see what a component does just by reading code. A visualization tool for AOP can put together all the different pieces that make up the whole, and present them as one unit even though they have been developed separately. Access to this kind of tools is, of course, crucial.

We have built such a tool ourselves for our own system, and it has been very helpful when we are expanding the system and when we are looking for bugs.
The step after that, I guess, is the possibility to build packaged aspects that can be reusable in your own projects. However, predicting component markets have proven to be a notoriously difficult task so I'm not going to bet on it.

Q: ...and the future for SiteVision?
A: Without revealing too much we can see that our framework and way of building systems gives us interesting opportunities to build application using AOP which run in SiteVision as portlets. Our next version expands the product into the portal segment, and the next logical step after that is to include document management features. We are also looking into how to provide scalability through clustering, and have some rather unique ideas there. But, one thing at a time.

Q: For the finale What are your top five advices for the wannabe aspect programmer?
A:

1. Read "Design Patterns" (the GoFbook)
2. Read the documentation for AspectJ
3. Find a medium size example application and implement it fully using AOP. Pick the framework which best suits your needs. I would start looking at AspectJ for client side development and AspectWerkz for the server side.
4. Apply design patterns using AOP as far as possible.
5. Read the AOP-entries in my blog

It is somewhere around here, at the end of the interview, that I start to long for a good cup of coffee, some Java and lots of aspects

Resources
SenseLogic: http:// www.senselogic.se
Rickard's blog: http://www.jroller.com/page/rickard

Originally published in JayView.

Trots att vi anstränger oss till det yttersta att modellera våra system intill perfektion, nåja i alla fall väldigt, väldigt nära, så är det fortfarande svårt att fånga strukturen hos ett problemområde. Detta märks t ex genom att vi kopierar välbehövliga små bitar kod och lägger in dem överallt. Inte nog med detta, de klasser som helst bara skulle behöva lösa en uppgift, tvingas att känna till säkerhet, databas, loggning osv. Allt detta leder till system som är svåra att underhålla och förändra.

Vad skulle hända om vi kunde plocka ut all loggning i våra projekt och lägga dem i en separat klass – en aspekt? Istället för att sprida ut en viss lösning i vårt system, kan vi nu underhålla den på ett enda ställe. När programmet kompileras så förs koden tillbaks ut där vi hade den innan.

För att bättre förstå vad aspekter är tittar vi närmare på AspectJ, som är en variant av AOP baserad på öppen källkod. Den har flera år på nacken och skapades på Xerox PARC som ett forskningsprojekt med stöd av DARPA.

Ett exempel: Var finns egentligen koden för loggning?

Kodpunkt, punktsnitt och direktiv

I aspektorienterad programmering kan man samla alla dessa små bitar kod på ett enda ställe. Men vi måste ju fortfarande kunna köra dessa på givna ställlen i programmet? Lösningen i AspectJ är att identifiera punkter i exekveringen av ett program – så kalllade kodpunkter (joinpoints).
Det finns flera olika typer av kodpunkter man kan identifiera; metodanrop, skapande av objekt, att sätta attribut, utlösning av undantag (exceptions) osv. Ett punktsnitt samlar en omgång kodpunkter och ger dem ett namn.
Genom att ange kod, direktiv (advice), som ska köras vid dessa kodpunkter kan vi samla tvärgående intressen (crosscutting concerns) i en enda fil – en aspekt. Eller annorlunda uttryckt:

aspekt = punktsnitt(kodpunkter) + direktiv

En aspekt består av en omgång identifierbara punkter i programmet där extra kod ska köras.

Vad kan man göra mer?

Vi har bara gått igenom ett hyfsat enkelt exempel till höger, men det finns många saker man kan använda AspectJ:

• Olika former av loggning och debugging.
• Design-by-contract, d v s att man kollar inoch utgående tillstånd och parametrar. När man är nöjd att systemet uppfyller kraven kan man ta bort dessa aspekter.
• Testa optimering, alternativa lösningar etc.
• Cachning, synkronisering, accesskontroll etc.
• ... och fler tekniska aspekter som inte har med vårt problemområde att göra.

Innan har vi endast talat om dynamisk förändring av ett program, d v s att påverka arbetsflödet. Men det går också att ändra den statiska strukturen genom att lägga till t ex klassvariabler, metoder, ändra arv. Här uppstår fler möjligheter:

• Multipelt arv som t ex mix-in i C++
• Genomförande av kodstandard. ”Ingen får ändra en variabel direkt”. Denna koll kan t o m göras vid kompilering!

Listan kan göras mycket längre. Vi befinner oss bara i början av vår förståelse om var och hur vi bäst använder aspektorienterad programmering. Även om denna inte kommer att ersätta objektorienterad programmering (OOP) så kommer den att vara grunden för AOP på samma sätt som funktioner utgör grunden för OOP.

Ett enkelt (nåja) exempel

Vi skulle kunna gå igenom ett enkelt ”Hello Aspect World”, men jag väljer iställlet att dyka i lite djupare. Jag vill mäta hur lång tid det tar att anropa databasen i vårt hemmasnickrade modelllager.
Vår modellkod innehålller en abstrakt klass som definierar ett gränssnitt för att arbeta mot databasen. Personklassen representerar en post i person-tabellen och implementerar själva anropen med SQL mot databasen i metoderna dbSave, dbUpdate och dbRemove. I ett anfall av hybris lägger jag in mig själv i databasen. Demokod:

Vårt enkla modell-lager som kapslar in databasen.

DBObject tPerson = new Person();
tPerson.setField("firstName", "Björn");
tPerson.setField("lastName", "Granvik");
tPerson.dbSave();

tPerson.setField("company", "Jayway");
 tPerson.dbUpdate();

Du gamla vanliga lösning

Låt oss nu göra en enkel tidtagning. På det gamla sättet så blir det till att kopieraoch-klistra, så mycket som vi nu orkar. Till exempel skulle Person.dbSave kunna se ut som följer:

void dbSave() {
    long tTime = System.currentTimeMillis();
    // Do something...
    tTime = System.currentTimeMillis() tTime;
    System.out.println( thisJoinPoint + ": " + tTime );
}

Och på samma sätt för de andra metoderna dbUpdate och dbRemove. Även om vi förbättrar situationen genom att introducera en tidtagningsklass blir det bara marginellt bättre – det är fortfarande korkad kod! Dessutom så kommer den att ta tid att exekvera. Inget vi vill ha kvar i en produktionsversion.

Du sköna nya aspekt

Låt oss titta på hur man skulle kunna lösa problemet med hjälp av aspekter. Vår nya lösning innehåller en del nya ord som tillägg till Java-språket, se fetstil nedan, men är inte så svår som det först verkar.

/* A timing aspect on DBObject.db methods */
public aspect DbTimerAspect {

    /* Public DBObject methods starting with 'db',
     * taking no parameters and returning anything. */
    pointcut dbMethods() : execution( public * DBObject.db*());

    /* A simple timer advice to be called instead
     * of the original method. */
    void around() : dbMethods() {
        long tTime = System.currentTimeMillis();
        proceed();    // Proceed with call to DbObject.
        tTime = System.currentTimeMillis() tTime;
        System.out.println( thisJoinPoint + ": " + tTime );
    }
}

Vår aspekt DbTimerAspect innehåller dels de metoder som vi vill mäta och den tidmätare vi vill ska köras.
I kodsnittet dbMethods (pointcut) väljs de publika metoder i DBObject och dess subklasser som börjar på ”db”. Vi anger också att det är när metoden körs (execution) som är intressant. Här kan man välja på fler varianter; när metoden anropas, när ett attribut ändras, när ett objekt skapas och många fler sorters kodpunkter.

När demokoden anropar Person.dbSave så är det vårt direktiv som körs istället. Nyckelordet som anger detta är around. Vi hade naturligtvis kunnat ange att den skulle köras före, efter osv. Det första vi gör är att ta reda på tiden. I nästa steg anropar vi originalmetoden med ”proceed”. Nu körs Person.dbSave som vanligt.

Efter att vi kommer tillbaka räknar vi ut den tid som tillbringats i anropet och skriver ut den på konsolen. Lägg märke till att vi har tillgång till den kodpunkt som vi befinner oss i m h a thisJoinPoint. Resultat
När vi kompilerar vår kod gör vi det med kompilatorn från AspectJ. Den genererar ren Java ”byte code”, dvs. koden kan köras precis som vanligt.

Resultatet på konsolen blir:

execution(void se.jayway.jayview.aop.Person.dbSave()): 111
execution(void se.jayway.jayview.aop.Person.dbUpdate()): 30

Ganska mycket det vi förväntade oss.

Slutkläm

Denna artikel räcker egentligen inte för att förstå hela vidden av det man kan göra med aspekter. Jämför vi med en vinprovning har vi bara hunnit titta på etiketten. Men, likväl, vårt lilla exempel pekar på de stora möjligheter som finns med aspekter.
När och var bör man då använda AOP? Än så länge är aspekter inte ”bevisade”. Hur kommer de att skala? Hur påverkas arkitekturen i skarpt läge etc?
Däremot så är det mycket intresssant att förbättra hur vi utvecklar dessa system. Mitt råd blir därför; Skapa aspekter som stödjer din kodstandard, testar varianter av din lösning utan att behöva modifiera koden, gör verktyg som t ex loggningsaspekter, etc.
Om jag ska våga mig på en gissning tror jag att vi inom några år kommer att ha sådana ”tekniska” aspekter som öppen källkod. Fast jag kan ha fel – de kommer kanske redan om ett år eller så

Termer

kodpunkt (joinpoint) En punkt i exekveringen av ett program, till exempel i anropet av en metod i en klass.
punktsnitt (pointcut) En samling utvalda kodpunkter.
direktiv (advice) Kod som körs vid utvalt punktsnitt under angivna omständigheter, t ex kan man logga ett anrop innan det körs.
tvärgående intressen (crosscutting concerns) Ett system har oftast flera mål som det försöker uppfylla. Förutom att lösa grundproblemet (t ex lönehantering) så finns där också uppgifter som t ex loggning, säkerhet etc. Dessa uppgifter, eller intressen, är typiskt utspridda i systemet – de går på tvären genom strukturen.
OOP Objektorienterad programmering en programmeringsteknik och synsätt som gör det möjligt att öka komplexitetsgrad och återanvändning.
AOP Aspektorienterad programmering att göra fristående moduler som hanterar tvärgående intressen på ett sådant sätt att de kan sömlöst kan föras in i koden igen vid t ex kompilering.

Resurser
AspectJ
Eclipse, AspectJ plug in
JavaWorld: I want my AOP!
AOSD – Aspect Oriented Software Development

Originally published in JayView.

JWS-applikationer startas första gången typiskt från en länk på en html sida, applikationen laddas då ner till klienten. I fortsättningen kommer den dock bara att titta efter uppgraderingar från servern. Men JWS- applikationer är ingalunda kopplade till webbläsaren, de körs helt fristående vilket innebär att de även går att starta som van- liga applikationer.

En annan intressant funktion är den dyna- miska resurshanteringen. Första gången en applikation körs laddas ett minimum av den ner, vid behov laddas sedan ytterligare data ner under körtid.

För att tillhandahålla dessa funktioner lig- ger det under JWS ett api som heter Java Network Launching Protocol (JNLP). Den innehåller en rad olika services som tillåter sandlådsapplikationer att spara och öppna fi- ler, komma åt clipboard och skrivare med mera. Användaren måste dock via en dialog godkänna sådana operationer.

Vad krävs?

Så vad krävs för att köra JWS-applikatio- ner? Klienten behöver Java Runtime Environment 1.2.2 eller senare och Java Web Start 1.0.1 eller senare – inget utöver det vanliga. Dessutom behövs en standard webbserver som kan registrera nya MIME- typer.

För att utveckla JWS-applikationer behövs ingen speciell kod, exekveringen börjar på samma sätt som vanliga applikationer. Utvecklandet innebär följande steg:

• Skapa applikationens kod.
• Paketera applikationen och dess resur- ser till en eller flera jar-filer.
• Signera jar-filer(na).
• Skapa en XML-fil som beskriver applikationen, kallas JNLP-filen.
• Lägg upp allt på webbservern, tillsammans med en lämplig html-fil.

Första gången måste du även se till att din webbserver känner igen .jnlp filer genom att registrera den som en ny MIME-typ.

En fet klients räddning

När man läser rubrikerna från tiden då applets skulle rädda världsfreden är det svårt att låta bli och le. Java Web Start känns som client/server med rätt anslag. Om man har behov av av feta klienter är det klart intres- sant att kolla upp – annars lär man utveckla exakt samma kod själv.

JWS används med fördel av utvecklings- intensiva applikationer eller av applikatio- ner vars uppgraderingar snabbt måste ut till ett antal användare. Ett annat behov kan vara att bryta de bindningar som en traditionell applet har med sin webbläsare. Eller om man bara vill vara bekväm av sig.
Originally published in JayView.