Relocation to http://froland.be

From now on, new content will be published to a new URL: http://froland.be.

Previous content has been copied to the new site so you can change your bookmarks.

See you soon on http://froland.be.

Git Branching for Agile teams

In this webinar, Sven Peters @svenpet shared some thoughts about git workflows used at Atlassian.

Hadoop data-mining swiss army knife by @plopezFr and @BertrandDechoux at #devoxx #DV13-HadoopCode

Hadoop data-mining swiss army knife

The website voyages-sncf.com sells half of the Thalys tickets in France and is one of the most visited websites in Europe. That high load triggered a huge amount of logs that, at first, were not used. After some time, they wanted to sek value in those logs and started investigating solutions for distributed computing.

Google+

Google+

Shaping the future of web development by Lars Bak at #devoxx

Shaping the future of web development

Conference given by Lars Bak at Devoxx 2013.

Nowadays, an ever growing part of the population don’t even bother to start any other application than a browser. More and more applications are web applications.

An obstacle to web applications is the development productivity.

Javascript is not a well structure language and lacks both complete and consistent libraries and tooling.

Practical RESTful persistence by @shaunmsmith at #devoxx

Practical RESTful persistence

EclipseLink provides a JPA-RS implementation. Let’s see what hides behind this.

The use case is a web application with the main logic inside the browser and a backend providing only persistency. We want to provide a REST API to that persistence.

Java 8 and beyond #devoxx #dv13 by @mreinold and @BrianGoetz

Java 8 and beyond

Keynote performed at Devoxx 2013 by Mark Reinhold and Brian Goetz

Java exists for 18 years. Nothing can stay so long in the field without evolving.

One of the latest evolution in computer science is multiplication of cores and pipelines in processor.

For that reason it is intersting to look at problems from a perspective where everything is splitted in parallel data flows which split and split and split until complex problems resolve themselves as a multitude of simple parallel calculation.

To support that perspective, closures were added.

Fault tolerance made easy by @ufried at #devoxx

Fault tolerance made easy

Given by Uwe Friedrichsen at Devoxx 2013.

It describes a series of patterns applicable to vast majority of applications in order to support a user-friendly degradation of functionalities when a resource becomes unavailable or that the load becomes too high to cope with every request in a satisfactory way.

Environment-specific configuration in a maven-spring-mvc project

Hi,

For once, this article is not about a conference but about some issues I thought about recently.

The context is a training session I give in my company. In that training session, I use a web app to illustrate some points and let the attendees perform some exercises. The web app project uses maven, spring-mvc and multiple databases (mysql and hsqldb) for different purposes (local playing, local integration tests, CI integration tests and “production”).

Those different purposes have different needs. Ideally, I would like to have something like:

1. local playing –> local mysql database
2. local integration tests –> hsqldb in-memory database
3. CI integration tests –> dedicated mysql database running on the CI server
4. “production” –> dedicated mysql database running on the “production” server

To update schema updates, I use liquibase. I would like to run it in update mode on environments 1, 2 and 4 and in drop-and-create mode on environment 3.

I know a lot of different solutions that can achieve this situation, but the solution must be neat (it’s a beginner training application and thus shouldn’t attract the focus on themes I don’t want to talk about). Currently, I still haven’t found THE perfect solution. So I’ll describe the ones I’ve already tried with some kind of success in coming articles. Feel free to propose anything in comment. I’ll be glad to investigate your propositions.

Devoxx 2012 article: How to make good teams great

Introduction

This presentation rocked. This is only my personal advice and is completely subjective. Anyway, I’ll repeat it: this presentation rocked.

Everything was there: good slideware, an interesting and well-structured content and, last but not least, a smiling and entertaining presenter.

Sven Peter (@svenpet) presents himself as an Atlassian Ambassador.

Let’s go and see what this guy had to say.

About programmers, employers and change

The programmer heaven can shortly be described as working in a kick-ass team to develop a kick-ass product.

What big companies are doing in hiring great people and paying them bonus of all kind… to finally put them in jail and force them to follow strict rules.

So what can we do?

Starting a revolution… and being at high stakes of losing our job?

Complaining. Not very effective.

So the idea is to “be the change you want”.

But don’t be a fool. The changes have to be profitable for everyone. The developer. The company. And don’t forget your customer. So for every change you want to implement, be sure to measure the change impact and to use time boxes when appropriate. You want to be seen as the guy who brought smart changes. Not as a cowboy. But even then, be prepared to fail. As that is inherent to great ideas. Some of them works. And then there are the others.

Tips to improve your team

Following are 7 things that we can do to improve our team spirit and productivity. These have been tested at Atlassian. Remember that this doesn’t mean they will work for you or that there aren’t other (even better) ideas to try.

Flow time

Let’s define flow time as an uninterrupted time period you get to do your work. No urgent email, no phone call and noone to disturb you. This is the time when we programmer are the most productive.

The ideal is that we can work alone in a closed-door office. But right now, companies are building large open-space landscape working place. But then there is still hope.

• You can define a “Do Not Disturb” time
• You can elect someone in the team as the single point of contact so that other teammate are not disturb

Both of these require some degree of collaboration and maybe some visuals to clearly state who to contact and when not to bother the team.

Score: 4 out of 5 feasibility points and 2 out of 5 awesomeness points.

Feed your brain

A developer’s brain is always hungry. So you’ve got to feed it. Here are some ways.

• Attend conferences. Some take multiple days (Devoxx), some are scheduled after work (BeJUG, BruJUG or any other user group you’re interested in).
• You can organize coding sessions or dojo’s in the evening too. Even if it’s true that people often have other occupations then.
• You can organize brown bag sessions during lunch time. These take no spare time and no business time. Except of course the time needed to prepare it.
• And if you cannot even afford the time to prepare a lunchback, you can organize video watching (http://parleys.com for example) during that same lunch time.

Score: 5 out of 5 feasibility points and 2 out of 5 awesomeness points.

Say “Well done!”

Appreciation, even of small things, is important for happiness. And to carry even more effectiveness, it should be made easy to say thank you publicly to everyone without censorship.

Score: 2 out of 5 feasibility points and 3 out of 5 awesomeness points.

Report robot

We should record and report over everything possible. We can make reports about time, features, code reviews, velecity, sales, web traffic, support cases, interviews, …

Those facts can be recorded easily in databases and reports generated automatically. Those automatic reports can then be displayed on information radiators (i.e. large screen in the hallway).

Score: 2 out of 5 feasibility points and 4 out of 5 awesomeness points.

Eat your own dog food

Everytime it’s possible (come on, there’s always a way to do it) we should use the product we are developping by ourselves. Meaning developers team should be its own alpha tester.

Acting as your customer make you more akin to understand her.

Even if using your own tools will often prove to be painful, this is the shortest way to get feedback. This will allow you to use less QA and to use it better.

Score: 2 out of 5 feasibility points and 5 out of 5 awesomeness points.

Do a special day

Over time, we tend to accumulate a backlog of unpleasant things. So it’s sometimes useful to forget about the current sprint for a day and have a special day to empty this backlog.

Exemple of special days are:

• 1-day doc sprint Developers spend one day to write as much docunentation as possible with the help of technical writers.
• 3-hour blitz-test Developers get 3 hours to test as many things as they can. Their sole aim should be to find as many bugs as they can.
• clean up day Developers get one day to clean up everything about the application.

The purpose of those special days are to put stuff out of the door and keep the focus on the sprint the other days.

Score: 5 out of 5 feasibility points and 3 out of 5 awesomeness points.

Experimentation time

At Atlassian, experimentation time is declined in multiple ways.

Ship It days

Ship it days are some kind of hackathon.

2 to 3 weeks before the Ship It day, a brown bag session is organized to gather ideas and federate teams around them.

2 days before, a mini sprint planning meeting is held to organize the work on that day.

On the Ship It day, teams are working non-stop during 24 hours to deliver something. At the end of those 24 hours, each team is given the opportunity to present what they’ve done during a lightning presentation and a winner is voted for.

These days are a cool way to foster the innovation and make your nerdy developers happy.

20\% time

Each team member is given 20 % of his work time to explore. This time is reserved for innovation. This time is independent altough it must have something to do with the company business.

This kind of policy can create conflicts. People may be needed by others while on their 20% time. The workload may be too high so that people themselves cut it out. The sprint goals may be put at risk because of it.

So sometimes it is more manageable to turn those 20% time into an innovation week.

The score of both Ship It days and 20% time: 4 out of 5 feasibility points and 5 out of 5 awesomeness points.

Conclusion

Here are some interesting ideas to try. So let’s try to put at least some of them in practice. But remember that they can fail too. So take precautions. Measure the impact. And make it one step at a time.

The presentation slides are available at http://svenpet.com/slides.