Here at the Oredev 2009 conference in Malmo, Sweden, I had the chance to connect with Herbjorn Wilhelmsen, one of the members of the SOA Manifesto Working Group. Herbjorn presented a 'lightning talk' on the Manifesto, describing its vision and overarching values. While 15 minutes is far from enough time to cover a document of such constitutional magnitude (he wasn't able to go over all the principles), Herbjorn drove home one very essential point that is implicit in the document -- that SOA is not a product. You can't buy one nor bake one. It must be built with people. processes and most importantly, business values in mind.

Apache's ten year anniversary celebrations wrapped up last week at ApacheCon 2009. DZone recently got the chance to speak with Justin Erenkrantz, the President of the Apache Software Foundation. In this exclusive interview, we took the opportunity to reflect on the last ten years at Apache and find out what drives the foundation's continued success.

10 things you should know about Model Driven Development. An introduction into MDD with some highlights of more advanced topics.

You have your site, full of content, visitors come and go every minute and your Google analytics account shows that your site is very popular. You host this site on a great hosting provider that has a good price/quality value and you are sure that 40Gbs of monthly bandwidth is enough to serve your visitors. Or not?

Thoughts about testing in an agile environment.

Thoughts about testing in agile projects. What are the effects of acceptance test driven development and behavior driven development?

MeasureAgile Coaches and Consultants frequently warn their clients that traditional measures such as Earned Value, Hours Worked, Lines of Code, Code Coverage for Tests are not well suited to Agile Projects. But then our clients are left with the question what are good Agile Metrics? How would I tell a good metric from a bad one? Are there contexts where a good metric is bad?

I am a big fan of Uncle Bob and I think he is a master of object-oriented programming and architecture. However, in my opinion his Bowling Game kata (solution for the bowling game scoring problem) it's not the right example to explain design via Test-Driven Development.

From blog posts to books, sorting a list of items by user rating is a very common task. In this blog post, we discover how the writings of an obscure 18th-century British minister lets us implement a “smart” ranking algorithm that takes into account the “wisdom of the crowd”, and presents a fairer and more accurate representation of results.

None of the agile processes as described by their originators is perfect for your organization. Any may be a good starting point, but you will need to tailor the process to more precisely fit the unique circumstances of your organization, individuals, and industry. As Alistair Cockburn once told me, “Having a chance to change or personalize a process to fit themselves seems to be a critical success factor for a team to adopt a process. It’s the act of creation that seems to bind teams to ‘their own’ process.”

My mother is a psychologist and recently visited me us here in Idaho. We spent some time talking about the psychology behind some agile practices. Pretty cool! Additionally, we ended up on the one mystery topic that has always eaten away at me. That mystery for me is simple: Why does one person or team pursue excellence relentlessly while another hits the door at 5:01 and doesn’t think about software development until tomorrow morning?

During my childhood I was told by many that I was what they called an --- 'introvert'. As far as my side of the story was concerned; I found human beings; hugely complex creatures who were very difficult to understand and establish a connection with. If I can be honest here; it was not the human race that was a problem. I actually liked interacting with other human beings. It was just the first five minutes; the small-talk; the phony smile and the how-are-you-doing or how-is-the-whether-there discussion that I found hugely complicated and pointless.

The current problem is that hiring an agile consultant to be on-site and work with the team for a number of weeks or months is prohibitively expensive. But this is exactly what is needed to help impart Agile knowledge from person to person.

This article is aimed at readers at a more advanced level of understanding of the C++ language, and assumes familiarity with C++'s object oriented capabilities, as well as some understanding of the Standard Template Library. This article is intended for anybody who wishes to explore new techniques of object oriented software design and problem solving. The example shown takes a fairly common programming problem and completely re-factors the 'traditional' structured procedural solution into an object-oriented solution.

Conditional control statements are at the very core of programming, in almost any language. The idea behind conditional control is that it allows you to control the flow of the code that is executed based on different conditions in the program, input taken from the user, the internal state of the machine the program is running on, etc. Computers are very good at doing exactly what you tell them to do, but otherwise they are really quite stupid. However, imbuing them with the ability to make decisions through the use of conditional control can make them just a wee bit smarter – they start making the decisions that you tell them to. There are three major structures related to the conditional execution of code in C/C++ - the if statement, the if-else statement, and the switch-case statement. Each will be covered here. It is also possible to use looping structures, such as for-loops and while/do-while loops to conditionally execute code. However, they are covered in another tutorial, so I will not address them here.

I used to be strongly opposed to this idea but I started changing my mind recently. Here is what happened.

Suppose you have a huge number of items that you would like to group together by a fuzzy notion of similarity. Suppose the only tool available to you is a key-value store. Suppose you only have the resources to consider each object once. Never fear, simhashing is here!

I’d say 9 out of 10 project folders are a complete mess. The only people finding anything in these structures are the ones who put it there in the first place. Why is it so difficult to find anything in most of these trees? And how can we make it more easy?

Lately I have tried to provide significant test coverage for projects I work on. My problem is with buzz word fanatics, suits, zealous developers, and tangentially related technical staff who question myself or my team in our decision to not require test first methods as part of our normal development procedure.