Jazzon 2011, Day 3

26. June, 2011

The day started with a keynote from a M$ guy:

Jazzon 2011, Day 3 – How to become a famous author and publish a book: Using Freemium Content with a Profit – Pouline Middleton

26. June, 2011

How to become a famous author and publish a book: Using Freemium Content with a Profit – Pouline Middleton

Pouline showed us the obstacles in which you run when you try to publish your own book. It confirmed my own conclusions: Unless your name is Stephen King or J. K. Rowling, publishers aren’t really for you. They most often want to own your work but selling it is more of a second thought.

Instead of using the common channels to sell her book, she chose a freemium model. You can read the book as blog posts, by email or buy it from herself (she eventually founded her own publishing company Fiction Works.

The fun (or sad) part is that she made much more money this way than she could have hoped for if she had used the traditional channels.

Here is an example. Say you have 1’000 die hard fans (not so hard to come by when the Internet has almost 1 billion users). Each of them buys from you for $100. Again not so much. That gives you $100’000.

Jazzon 2011, Day 3 – Web Security: Develop. Penetrate. Smile. – Matt Raible

26. June, 2011

Web Security: Develop. Penetrate. Smile. – Matt Raible

Matt demonstrated how to “implement authentication in your Java web applications using Spring Security, Apache Shiro and good ol’ Java EE Container Manager Authentication. You’ll also learn how to secure your REST API with OAuth and do it all securely with SSL.”

Nothing spectacular but the usual mix of nice code and how to avoid the most common pitfalls.

Some things to remember: Firewalls don’t work, not even if they’re stateful and inspect the HTTP stream.

If you’re interested in web app security, you should have a look at OWASP. Right now, there are a lot of non-developers there. What we all desperately need is web frameworks which make it more simple to configure a secure web app correctly than configuring a normal web app.


Jazzon 2011, Day 3 – Turning up the heat – techniques for self-organizing teams – Joseph Pelrine

26. June, 2011

Turning up the heat – techniques for self-organizing teams – Joseph Pelrine

Joseph reminded us that teams always organize themselves, if we want it or not. Those social forces are pretty strong which is why agile methods have given up to fight with them. Instead, they try to prevent the worst and/or alert you early of problems.

The most important three words of the talk: “Leave them alone.”

But the result is probably not going to be the way you want. Also, team building this way can take a long time. Or it can be surprisingly quick. It can take as little as 2 seconds for a group of strangers to clap in unison (as he demonstrated in the presentation using the audience). One reason why this works is because we wanted it to happen. If part of the team refuses to be part of it, you’re in trouble.

When we say “self-organizing,” who or what is this “self” really? It’s a “system” composed of a group of people and their environment. This simple fact is an often overlooked. Renovating a shabby workplace can be better for quality than a raise or bonus. Listening to people and acting on their input is more effective than bringing in external consultant. Usually, they are brought in to make the “act upon” part more easy.

Every such system defines its own rules and responsibilities. Without any regard to what people want or what happens to them. Martyr anyone? The problem: We want people to do what we want without us telling them. Only if you ignore (part of) the system, you will fail because the forces in the system can be tremendous. Again, agile lists methods that often work but you should still be aware that there are reasons why changes to the system fail.

For example, Art Kleiner came up with the Core Group Theory: For every system, there will be a small group of people who control the system. Dictator in a dictatorship. If the boss doesn’t take control, the system still enforces that the “underlings” follow – they will make fun of the boss but they will still follow orders. Most often to the letter. Financial crisis: Small group of greedy people almost ruined the world’s economy.

One important point is that you need energy from the outside if the system’s equilibrium isn’t what you want it to be. Say your developers aren’t testing enough. You need some incentive for them. This external energy is consumed but it doesn’t necessarily alter the system permanently.  For that to happen, you must look at the system (people + environment) and find a way to make sure it’s in the system’s best interest to change (and not only in the people’s best interest!)

How can you do that? You turn up the “stress” or “heat.” Note that too little heat and nothing will happen. The resistance of the system will simply swallow your efforts. Too much heat and the system will retaliate or overreact. So it need to be applied with care.

One way is to use the physical formula PV = nRT which means pressure * volume = temperature. You can increase the temperature (the heat) by increasing the pressure (add more tasks) or by reducing the time to complete the tasks.

Another is to look at the system as a star with five tips: Attractors (like bonuses), boundaries (who is on the team, who isn’t), identities (who was which role/responsibility), diversity (homogeneous systems tend to inbreed) and environment.

Which means you can try these things:

  • Offer a price like a holiday or free pizza for all (attractor)
  • Add/remove people to/from the team like mixing the testers with the development team.
  • Move a difficult customer to a different support guy
  • Bring in new blood and ideas
  • Get them new computers, remove the telephones so they don’t get interrupted every 11 minutes.

Remember: Changes are like really long hikes; one step at a time.


Jazzon 2011, Day 3 – Spring 3.1 in a Nutshell – Sam Brannen

26. June, 2011

Spring 3.1 in a Nutshell – Sam Brannen

Sam gave an overview of Spring 3.1. If you don’t like XML, this one is for you.

Along with Servlet 3.0, it’s possible to write web apps that need no XML (not even web.xml).

Profiles and environments allow to use the same code in test and production. There are more concise ways to replace properties in your config. The MVC API has learned a couple of new tricks. Good stuff and probably not too far off.

Jazzon 2011, Day 3 – The Power of Retrospection – Linda Rising

26. June, 2011

The Power of Retrospection – Linda Rising

After the keynote the day before, I decided to skip “What’s next in the Java Webtier,” “Giving Your Application a Social Life with Spring Social and Spring Integration” and “Tricks of the Trade – What Every Developer Should Know About Application Security“. A hard decision but worth it. Technical details can always be learned later (or never) but social knowledge is eternal.

What’s retrospection? Well, a manager asked what the second guy did while pair programming. Answer: Thinking. Manager: “We don’t have time for that!”

In the struggle of an ongoing project, we are often too busy to stand back for a minute and consider: Are we achieving something or only spinning our wheels?

This isn’t about problem solving, it’s more like a scientific experiment. It’s considering the options, making an assumption, considering ways to disprove the assumption and then doing just that.

See, many problems we face today have no solution. If they had, they wouldn’t be problems in the first place. Customer too dumb and you want to hit them over the head with a cluebat? How could you possibly “fix” that?

But you can try different approaches to improve the situation. Maybe someone else in the team has better social skills to handle a difficult customer? Or you can hire someone to handle them? Or call in an expert to train you on the topic. Or maybe buy a book. Talk to your wife/friends/ask in an Internet forum? Piss the customer off so badly that they never dare to call you again – ever?

As you can see, ideas can start to flow as soon as you power down and sit back to … think for a minute. Maybe none of them works. Chances are: One of them will. But you’ll never know if you don’t take that hour off, walk the stress out of your system and sit down to stare at nothing and think.

That’s a retrospection. It’s a look back. What was good, bad, surprising? What do you want to do more? It’s about fine tuning, not changing the world. Even if you’re Facebook, changing the world does take years.

It’s not about consensus either. If everyone agrees, nothing ever changes.

It’s about reaching closure. It’s about that wall in Washington DC that lists the names of every soldier killed in the Vietnam War. Imagine standing there, reaching out, trying to grasp what all those names mean, what the wall means, how horrible must have happened. And world is still turning …

Your project is killed after two years of effort, huge amounts of personal stress and overtime. Well, at least it’s finally over.

You should think about everything that went bad but don’t soak in it. Also remember what went well. No time? Five minutes can be enough. In fact, it can be better than a two hour retrospective because it will be much more focused.

Keep in mind the Prime Directive of retrospections:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.


Jazzon 2011, Day 3 – Behind the scenes: Microsoft and Open Source – Gianugo Rabellino

26. June, 2011

Behind the scenes: Microsoft and Open Source – Gianugo Rabellino

Disclaimer: I have M$.

According to Gianugo, M$ knows a lot about open source. Sounds good? Maybe. “Know your enemy” 😉 Well, of course they know. OSS is a threat to their business model so they early applied their usual tactics of “embrace, extend and extinguish” to handle it.

When that didn’t work (and they found it wasn’t necessary because most people don’t understand OSS), they gave it up so they can now pretend to be “good guys” (or maybe “better guys” than they were before the year 2000).

My main objection is their definition of open: “Open” for them seems to mean “honest” or “listening to customers” or “doesn’t cost anything.”

That’s wrong. Open means: I can solve my problems myself. Example: Say I found a bug in Word. I know how to fix it. Will it be fixed? No. Why not? Because I’m just one of 300 million Word customers. My tiny complaint is simply drowned in the majority’s cry for more features.

Open source means: If I know how to fix it, I can. If I don’t, I can ask for a fix. If the original developers can’t help, and I still need the fix, I can hire someone to fix it for me! I have options. With M$ (and any other big company for that matter), I have none. For me, these people are an endless source of frustration.

Why I have M$ more than most? Because they make my life miserable every day for the past 25 years. Every day, I get Office documents that LibreOffice can’t open. And I can’t run Office on Linux. I could run it in a VM but that would infest my pretty secure computer with a viruphile OS that is hard to maintain, update and use.

Where was I? Oh yes, the presentation.

One slide said that they were open for interoperability and standards. M$ is member of a whole lot of standards committees. Which sounds great. But big companies usually become members of standards committees to make sure either theirunderstanding of the technology because the standard (so everyone else has to catch up and/or pay them royalties)  or to make sure nothing is every agreed upon. Since every committee contains at least one member of both groups … you get the idea.

It’s like religion. Question: Who goes to hell? Answer: Everyone. Proof: There are at least two religions which believe that anyone who doesn’t share their specific belief goes to hell.

Anyway. M$ is driven by money. If there is money to be made, they jump. If not, they can’t be bothered. So if the customers want interoperability, M$ couldn’t care less. If the customer pays for this, sure, why not.

For these reasons, IE9 is not OSS. But at least they’re trying to be compatible to HTML(5) – since no one really is, it doesn’t really matter. The point is that customers are running away to other browsers like Firefox and Chrome. On top of that, FF and Chrome have been leading innovation in the browser market (I’m sure the M$ marketing department disagrees and next year, we’ll see a lot of ads says that “M$ invented HTML, the Internet and Walking Upright(tm)”).

What M$ also cares for is wasting money. Support is such an area. So they decided to split IE9 into the stable, basic product for John Doe. Developers can download all kinds of cool extensions from some website (links anyone?) to tamper with the bleeding edge. When the bleeding edge has been dulled from all the blood (= something has emerged and a lot of people want it), M$ can move it into the IE9 installation package (or an update) and claim to have invented that, too.

Nice idea. I actually like it, even though I worry what it means for fragmentation of web development. But making people “trust IE9” because the base product is stable, fast and dependable, that should help to move people more quickly away from IE6 and that’s always a good thing. Of course, this mess is also M$’s fault in the first place. But at least for once, they try to clean it up.

The talk did contain two items which I agree: WebSockets are the best and the worst of HTML(5). They are a great idea and would solve a whole lot of problems that web developers face today. Unfortunately, they’re also a huge security risk.

The other thing is that cloud means “I don’t care.” Cloud computing really means that you want to concentrate on the few things that you do best and leave the rest (network administration, backups, fault tolerance, installing updates, etc.) to someone else.

Funny fact: All slides had “Microsoft Confidential” on them.

Conclusion: Gianugo sold his soul well. I talked a couple of minutes to him after the presentation. We didn’t agree but at least we did it in a civilized manner.

Jazoon 2011, Day 2

26. June, 2011

It’s day 2 and it starts with a very interesting keynote.

Jazoon 2011, Day 2 – Jazoon Rookie Award

26. June, 2011

Benjamin Muskalla showed a better workflow to handle patches by OSS contributors using Eclipse MylynSee this video for an introduction to the idea.

After him, Alessandro Nadalin showed some advantages of using REST (and when not to use it). My criticism is that HTTP caching is brittle as it stands and can cause all kinds of problems. So, yes, if the caching works, REST is great. But if it breaks, all kinds of havoc can ensue. Worse, many problems simply don’t well with REST. Twitter and RSS feed downloads? Yes. Web conversations? No.

Lastly, we had Ivo  Neskovic demonstrating Project FoX which allows to define mathematical rules to which some code has to comply. The demonstrated example (a buffer) was simple enough. As always, there was no telling how amount of work grows with code size. Most of these tools suffer from the problem that a) the effort grows exponentially (so you need 4 times the effort to handle twice as much code) and/or b) there is an explosion of test cases (so you might have all the tests but it would take years to run them).

Jazoon 2011, Day 2 – Compositional CRUD: A novel approach for doing CRUD in Enterprise/SOA Environments – Rene Mas and Thipor Kong

26. June, 2011

Compositional CRUD: A novel approach for doing CRUD in Enterprise/SOA Environments – Rene Mas and Thipor Kong

One of the advantages of CRUD is that each operation is simple to understand and implement. Every developer knows thatdependencies are bad. The disadvantage is that the operations are so simple. If you need something more complex, you have to execute many of them and this can get complex in its own right. Worse, the usual CRUD APIs only allow to execute the operations individually.

The idea behind Compositional CRUD is to be able to build arbitrarily complex commands from simple CRUD operations. All of them can be executed as a single operation (within one transaction, for example). This applies the ideas of the command patternand Promise Pipelining.

Seems like such an obvious idea, it’s probably already patented …

%d bloggers like this: