Posted by Geert Bossuyt at around evening time: February 16th, 2011
MoreAgile organizations support the following principles :
Complexity is a choice; we choose simplicity.
We carry out our vision and strategy
so that our people can make decisions in line with the mission of our organization.
Effectiveness is worth inefficiency.
We optimize the end to end value chain to maximize the result of our work.
We support selforganizing stable teams.
We create an environment that encourages people and teams to take responsibility and show entrepreneurship.
Our primary measurement for success is realized business value.
Our customers are the people that use our products.
Even when they are not the ones paying for our products.
We establish equal relationships on all levels
to empower knowledge sharing, commitment and shared responsibility.
We create opportunities from change, to continuously improve our products.
We prioritize all work in line with our vision and strategy.
Planning is a natural product of priority and sustainable pace.
We work smart, rather than hard, and learn every day.
Posted by Kris Geusebroek in the late evening: February 14th, 2011
At our project the focus is at making the application stable and controllable. So instead of building cool new features
we are spending our time making sure the application is able to run stable in the production environment.
After the first few issues the so called ‘Transaction timeout’ issue raised it’s ugly head.
Every now and then the application threw an exception due to a transaction timeout.
This was very strange since the timeout was set to 30 seconds and the complete processing of the whole
application was done in less than 2 seconds (spread over more than 1 transaction).
(more…)
Posted by Andrew Phillips mid-morning: February 13th, 2011
Implementing a Java SPI isn’t a particularly 2011 experience1. Creating a correctly-named text file in META-INF/services, making sure it is correctly packaged and remembering to keep it up to date when you refactor is sufficiently annoying and error-prone that there are at least a couple of utils that aim to make this easier.
At XebiaLabs, however, we’re not just the implementors of our plugin SPI. We also write the deployment engine that consumes these plugins. And unfortunately, there isn’t much out there to help you read, load and verify services. Hence MultiSPI.
(more…)
Posted by Wilfred Springer mid-afternoon: February 9th, 2011
Roger Bodamer from 10Gen, the company that develops and supports MongoDB, has agreed to come speak about all things MongoDB on Wednesday February 16th, at Xebia in Hilversum. We will start with a basic technical introduction to MongoDB but Roger knows MongoDB inside and out so feel free to suggest topics that you would like to hear more about. Of course there will be a Q&A at the end.
For more information about Roger and 10gen, have a look at their team page (he’s third from the top).
Note that we need to put a limit on the number of registrants, so if you considered joining, register now. You can register at the Dutch NoSQL Meetup page found here.
Posted by Niklas Odding mid-morning: February 9th, 2011
In my last post I stated that there is a lot of emphasis on the fact that architects have to help to get the scrum team to work better, faster en with more quality. By following the agile values the architect will help “strengthening the heartbeat” of the scrum teams. However the activities of architects should encompass more. In this blog I will explain what this is and how to incorporate this in your way of working with scrum teams.
Posted by Wilfred Springer in the early morning: February 9th, 2011
Before you start wondering, ‘deconfluencing’ is not a word you can lookup in Merriam Webster. Perhaps it should be. It certainly is something I needed, and eventually ended up creating myself.
Posted by Jan Vermeir at around evening time: February 8th, 2011
We’ve been busy for a couple of weeks now refactoring a fairly complex code base of just under 500 classes. None of us really knew all the details about this part of the system, but we didn’t let that stop us of course. After some regrouping/-shuffling/-factoring/*ing, the whole thing built OK and all unit tests were green again. All that was left to do was fix the Fitnesse tests. I remember thinking this should be easy since we had all those green unit test.
Evil laughter sounds.
(more…)
Posted by Xebia App Incubator in the early evening: February 7th, 2011
This is the first update since we started development on the LogStore. Despite the bumpy ride, we have quite a lot accomplished.
To summarize, the LogStore is a storage solution for logging statements. It’s based on CouchDB (document oriented database) and Elastic Search (schemaless search engine). The view on the log statements stored is built on CouchApp, a tool on CouchDB for creating HTML pages that are served directly from CouchDB instead of a separate application server.
Posted by Friso van Vollenhoven in the early afternoon: February 7th, 2011
Q: “Where in the world was the situation in Egypt the hottest talk of the town?”
A: “People in UK / London were all over it, also the Middle East and US east coast cities show more interest than the rest of the world.”
Q: “How do you know?”
A: “Just take a couple hundred thousand Twitter messages containing ‘egypt’ and run them through a MapReduce job that counts the number of messages per location and plot that on a map like this:”
(http://geocommons.com/maps/49541)
The map shows the number of Twitter messages containing the word ‘egypt’ that originated from locations around the world. A larger circle means more messages from that place. The messages were gathered during a five hour period on january 28, the day after the Egyptian internet was crippled.
(more…)
Posted by Age Mooij in the late afternoon: February 3rd, 2011
Trying to produce bad quality code is quite hard when you are using Test Driven Development (TDD), even when you are doing it wrong on purpose.
Recently Iwein and me were preparing some labs for a developer training and the plan was to create some really bad quality Java code as a starting point. Students would then be asked to clean it up and add some new features, all this of course with the intent to show the effect of bad code quality on your ability to quickly add new features. This was going to be a piece of cake!
After some brainstorming for interesting standalone programming challenges, we came up with the idea of writing a JSON to XML converter. It should be able to take any valid JSON string and convert it into a simple XML representation. Out of habit and without really considering the option of skipping this step, we started with a simple failing test. Here it is:
@Test
public void shouldConvertTopLevelEmptyArray() {
assertThat(converter.convert("[]"), is("<array></array>"));
}
Simple, right? To implement our converter we decided to use the well known “red, green, as little refactoring as possible” anti-pattern, which we expected to result in lots of copy-paste duplication, very long methods, and the other typical code smells we all know and loath. Our first implementation approach was to go for some all-time favorite candidates for producing bad code: string manipulation and regular expressions. As Jamie Zawinski famously said: “When some people have a problem, they think: ‘I know, I’ll use regular expressions’. Then they have two problems.” We had created a sure thing recipe for disaster. It was going to be all downhill from here, or so we thought.