Hello everybody!
This time, I will go a little bit off-topic.
A few days ago, I started a podcast. The reason this is off-topic is that the podcast is not related to Java or Agile; it is about a game: World of Warcraft. I really love this game, and it happens that there is no podcast about it in Portuguese, so I decided to start one. Let’s see how it goes!
tauren
If you are interested, take a look at Lichcast! But be warned that it is recorded in Portuguese…
Bye!
Do you know what podcasts are? If not, shame on you!
Podcasts are one of the best things invented in the last few years. And I really mean it. Podcasts are like radio shows, but you can download them, put in your mp3 player (it doesn’t have to be an iPod), and listen anytime you want. Actually, I use my mobile phone as a mp3 player to listen to podcasts.
Stuck on traffic? You can be learning something from a podcast while wainting to get home (or work). Or you can liston to something nice while doing the dishes… Or whanever you can think of.
So, bellow are a few ones I listen to all the time. But this is only the tip of the iceberg.
Java Posse – The best java podcast. Ever. Four great java developers discuss java related stuff and makes you laugh in the process.
Java Mobility Podcast – Get up to date in mobility related topics.
Agile Toolkit – So you are into Agile development? Then this podcast is a must. It features a lot of invaluable information.
Talking Metal – Relax a little bit and get some heavy-metal music news 😉
If you listen to any good podcast you think I should also listen to, please leave a comment! 🙂
According to the classical definition of a peer-to-peer network, peers that are part of this network should be able to run both as a client and as a server. This is what Jxta allows you to do.
Jxta is a platform for developing peer-to-peer applications. It supports the definition stated above, plus a lot of infrastructure features that most peer-to-peer applications might need. One example of such a feature is firewall traversal, which is done transparently for us. Also, it has some other very important qualities:
It is important to note that Jxta is not an API – that’s why it can be independent of the programming language. Jxta defines a set of protocols, that can be implemented in a variety of different platforms. Currently, these are the protocols specified by Jxta:
Those are of course very basic definitions of the protocols, but should be enough for now.
Jxta is not difficult to learn but it is extensive. If you are to fully use it, you have a lot to learn. You can find a lot of resources on the internet. There is the official site, which is the best starting point. And the community is active in the mailing lists. Also, I’m currently reading this book, which you can download for free.
This last Monday and Tuesday hold the Sun Tech Days 2008, in São Paulo, Brazil. It was a nice and interesting event, although the last edition was better. The event happened in a good but small venue, Amcham. I had the chance to keep in touch with some people and I ate some good food as well.
Maybe the reason I didn’t like it as must as the last one was the lack of really new and unexpected things… The speeches and tech talks were basically the same as in few other events I attended not too long ago. A little bit more up-to-date, but not that exciting nonetheless.
The only thing I really loved was a demo presented by Simon Ritter, where he used a Nintendo Wii controller and a projector. With the projector he painted a card in a piece of wood he was holding, of the size of an open magazine. He had put infra-red sensors on three of the wood piece corners. The Wii controller was standing on the table, and it was detecting the position of the piece of wood as Simon moved it. With this information, the projector updated the image of the card in the correct location, keeping it always inside the wooden piece.
Then he flipped the wood. And what happens? The back of the card is shown! And all of this written in Java! Amazing =)
To end this post, two pictures:
Fábio and Claudio at the Conference
People having fun at the Conference
I took these pictures at the reception party at the end of the first day. More food and drinks!
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!
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 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.
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:
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!
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:
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.
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.
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.
Another backpack from JustJava. No comments.
To be honest, I don't remember where this is from...
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 😉
Hello! My name is Paulo Renato, and I’ll be the writer of this blog =)
To get this started, I want to talk about value. There are several other subjects to talk about in the topics that this blog intend to cover, but value is a good start since it is what should be guiding you anyway.
In agile development, we always try to develop what brings most value to the client – this is key to any successful project. Now, the point is that the most important thing in anything you do is actually value. You just have to define what value means for each specific case.
The client may not be beautiful, but his value is what matters.
To use this blog as an example of both what to do and what not to do, I’ll tell the history behind its creation. I’ve been planning to write a blog for a long time now. But I wanted to make something big, not just a blog. I wanted to do a lot of other possibly interesting things together. I kept planning for sometime, but I never found the time to put it all up and running. So this is what not to do: don’t try to get everything done at once when planning and / or executing your ideas, projects or whatever. If you don’t have the resources required (time, in this case), you can end up having nothing, which means no value at all.
Then I thought: “What is the most important thing for now? What would bring my potential readers the most value, right away?” In this case, the value is the information I what to put out and, also, my own satisfaction with this. The rest can come later, If there is demand and I can afford the time. So this is what to do: break the problem in smaller chunks, choose whatever would bring the most value, and do it. Leave the rest for later, and if “later” never comes, it probably means you don’t need it.
That’s it for the first post, right to the point!
Thank you for reading! And don’t forget to subscribe to the blog’s feed 😉
JCranky 