Monthly Archives: September 2008

Extreme Programming Explained

A while ago, I read the book Extreme Programming Explained – Embrace Change (2nd Edition), from Kent Beck. You can find it at amazon.com. In this post I’ll talk a little bit about this book.

In this book, Kent Beck talks about Extreme Programming (XP), going through several values, principles and practices and how this all fits together. If you already have some experience with XP and want to go further, this is an excellent book for you. But if you have no idea of what XP is, you are better off searching for a beginners book on the subject, and then coming back to this one later.

I haven’t read the first version of this book, but according to the author, several things changed. He explains a lot of those changes, and what inspired them. For example, he tells that at first, he wouldn’t consider XP for really big projects, with large teams. But today, some success stories about this kind of XP usage can be found (mainly breaking a large team into small teams).

One point to notice is that, even though the book is excelent, it isn’t its contents that I like the most. It actually is the extensive bibliography. The author lists a lot of books on XP related subjects, with short yet usefull comments on each of them. A great place to go to find a new book to read!

So, grab this book and go for more XP!


A peer-to-peer project

Since a few weeks ago, we’ve been involved in a peer-to-peer project, somewhat deeply – and a little less than this before. Then, in the last two weeks, we started to implement something. Just a small demonstration code (for now), to be sure the work is feasible.

So, first question: What?

After some discussions, we decided to use guigoh‘s conference as a first scenario to test the ideas. But before that, we should be able to have some independent peers communicating. This would be the very foundation for any work that comes later. Something like this:

peers communications across a network

peers communicating across a network

This means that Peer1 must be able to reach Peer2, and any other Peer, across a network. It shouldn’t have to worry about the details on how to find and send a message to them. Also, the peers cannot depend on any central server or any kind of node that could represent a single point of failure. And the same must be true for all peers.

Based on some ideas from guigoh‘s conference application, and from the Dynamic Virtual Super Peer (DVSP) model (more on this one in a future post, if Amir and Sotiris don’t mind ;) ), plus the small concept explained above, we planned what should be done in terms of functionality. So this is it, in two simple steps:

The conference initialization: One peer creates a new conference, store its information in what we are calling ConferenceContext, and send invitations to the other peers it wants to have part in the conference. The ConferenceContext is also sent with the invitation. Each of these peers can accept or decline the invitation, which will then define who the conference participants are.

An ongoing conference: When the time for the conference arrives, a conference window is displayed at the peer’s screen. In this window, the user can type messages that the peers will exchange between themselves. In the end, it is a simple chat, but in a pure peer-to-peer architecture.

Now for the difficult question: How?

The next decision was technological: how is this going to be implemented? Doing everything from scratch is probably not a very good idea. Just Imagine having to write firewall traversal code by yourself, for a simple example of the trouble. There is just too much basic infrastructure work that would be necessary. And thus a lot of resources, which we don’t have.

There are a few options around the web, but not that much actually. I won’t list them here because I don’t tend to remember things I put aside (sorry :-p). The important thing to mention is the chosen technology: Jxta.

I won’t dive into Jxta right now. Instead, the next post will probably be about it. So if you have any questions feel free to send it to me, and I’ll try to address them.


Pair Programming

This is the way it works: every time anyone in the team needs to develop something, whatever it is, she does it in pairs. This means that two developers sit together and work to solve the same problem. Having done it for some time, and being the coacher of a team that does it, bellow are some considerations about this subject.

With pair programming, we put in practice the principle of “Collective Code Ownership” – which means that there is no such thing as an owner for any part of the project’s code or related artifacts. This is mainly possible because the developer is not coding alone. She always (or almost always) has someone else working together on the same code, on the same functionality.

As it is said, “Two heads are better then one”. Pair programming is a practice where math doesn’t work quite well because 1 + 1 > 2 here. This means that the value created by two programmers working together is greater than the one created by each of them separately and then summed up.

Pair programming also brings a lot of other benefits, both for the project and for the developers involved. For instance, the code quality rises. It gets better design and fewer bugs that it would end up having if it was developed by a single programmer. And the code ends up getting reviewed all the time.

On the other hand, despite maybe being counter-intuitive, the productivity also rises. Two people together can find a better solution for a problem much faster. How many times have you asked for an opinion from a co-worker that helped you with that terrible problem quickly? Now imagine that you have the co-worker available to help you all the time.

For the developer, pair programming is also great because it stimulates his professional growth. With pair programming, a developer has the chance to learn from its pair’s experience. At the same time, she also has the opportunity to transmit some knowledge. This learning is much faster than reading, for example. And as they say, teaching is the better way to learn.

Unfortunately, it is not always possible to do pair programming. A few things might prevent doing it:

  • you mighty be the only one developer in a small project;
  • there might be an odd number of developers (and thus someone must stay alone);
  • or, in the worst scenario, the company won’t allow you to do it.

Or maybe any other reason I can’t think up now. Anyway, it is always worth the effort trying to do pair programming so, if you can, go for it!


Backpacks

If you attend to developer conferences frequently, you probably have a lot of backpacks. Usually crap ones, but anyway… And this is my case, of course. The other day I was taking a look at these old stuff and got a little bit nostalgic… So, here are some of them:

duke backpack

This one is quite big but... I gave it to my girlfriend a few weeks ago and it is ripping already.

This one is terrible. Small and ugly... It's probably from a Sun Tech Days event.

This one is terrible. Small and ugly... It's probably from a Sun Tech Days event.

Another one from a Sun Tech Days. I use it to hold small things inside the bag when I'm travelling.

Another one from a Sun Tech Days. I use it to hold small things inside the bag when I'm travelling.

This one is so green that it hurts... Another Sun Tech Days.

This one is so green that it hurts... Another Sun Tech Days.

A nice one! This holds well small books and magazines, maybe even a small notebook.

A nice one! This holds well small books and magazines, maybe even a small notebook.

No backpack will NEVER rip as fast as this one from JustJava.

No backpack will NEVER rip as fast as this one from JustJava.

Another backpack from JustJava. No comments.

Another backpack from JustJava. No comments.

To be honest, I don't remember where this is from...

To be honest, I don't remember where this is from...

From some event organized by SouJava.

From some event organized by SouJava.

This is a lot of backpacks, isn’t it? And it is not all! But this is enough for this post, you are probably tired of looking at backpacks already ;)


Follow

Get every new post delivered to your Inbox.