Posted by erustenburg in the early morning: September 27th, 2011
Running a great session at the ALE2011 conference last week gave me a great level of energy. Facilitating a story mapping session gave me a great boost of confidence. Running a similar session in a different context with a different group toke that confidence away. By eating my failure cake I was able to celebrate my failing and opened my eye to enable me to learn from the failure.
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.
Posted by Gerbrand van Dieijen in the early morning: September 28th, 2010
Last Friday, one week ago, the Software Development Day was at Xebia, the first one for me as I started at Xebia this year. As written by Iwein there was some discussion about the use of Javascript started by yours truly. Should we do all UI related functionality in Javascript? Do we do throw away our knowledge, tools and best practices we know when we start coding Javascript? Why should we code in Javascript using the browser as some sort of Virtual Machine, if in fact we want to create desktop application?
Posted by Age Mooij late at night: September 20th, 2010
Last week we had one of our infamous tech rallies and we had a lot of fun trying to build our own Posterous clone in a day, i.e. turning emails into blog posts.
The project sources are hosted on Github. We were working on this one-day project with about 20 developers spread over 4 teams and one of the things I noticed is that most of us did not have more than the very basic Git experience. This meant that we ran into a lot of merge conflicts and solving those is not always easy. Below is a little rundown of the Git learning stages we went through in team MongoDB to deal with this.
Posted by Iwein Fuld in the early evening: September 20th, 2010
Sharing knowledge is one of our core values and as lot’s of research confirms knowledge transfer is best done between peers. We have a great knowledge sharing platform at Xebia through bi-weekly evening sessions, where we do some experimental coding and some presentations. Once in a while we take it to the max and organise a tech rally. One of those happened last Friday and it was a total blast. I’ll give you some of the highlights. More detailed posts on the technical details will follow and I’ll update the list below as they do:
Posted by Geert Bossuyt just before lunchtime: April 29th, 2010
A Scrum team from London was trying
To deliver the app without dying
Sustainable pace
no more rat race
The feedback augmented the buy-in.