I came across "The Craftsman" article series by Robert C. Martin (Uncle Bob), when I was looking for articles on agile development on the ObjectMentor web site.
This is a series written in monthly installments, with the latest installment (#40) published in the October issue of this year. The series is published in the magazine Software Developer and describes the story of a young developer called Alphonse and his transition from apprentice to craftsman programmer. He goes through a set of learning experiences in each of the articles that improves his skills. It is written in a scifi setting, but this shouldn't put anyone off as it only adds to the narrative of the series. It is extremely well written and (I find) entertaining.
Articles 1 through 31 can be found on the ObjectMentor web site, and the remaining can be found in the Software Developer magazine for those that have a subscription. (Installment 31 was published in January 2005.)
You should definitely check out this article series at is will teach you quite a bit, no matter what level of programmer you are.
Thursday, October 06, 2005
Monday, October 03, 2005
JAOO wrapup
I want to summarize my impressions and thoughts from JAOO this year. I've barely had the time to adjust to the ordinary life and spent the weekend not thinking too much about these things.
Besides going to a lot if interesting talks (not to mention the tutorials), and getting a lot of new ideas from that, the main thing has been that I've met a great many interesting people. This is what is good about JAOO, the speakers are very interested in talking to the other participants, and the schedule facilitates this with the parties and other activities.
I already mentioned meeting Robert C. Martin (Uncle Bob), Dave Thomas and Kevlin Henney. Dave also introduced me to Brian Berry who was his co-godfather of Eclipse. I also had a brief chance to speak with Martin Fowler, but he's more like a rock star these days. Steve Freeman and Nat Pryce of jMock and NMock were also two people I had the pleasure to meet. I especially got to spend quite some time with Steve, and we had quite a few discussions on agile development and computer science fundamentals. Another interesting guy was Adam Bien, an independant consultant from Germany. He has some down to earth views on how to develop J2EE applications, and in his talk called Are Java Fat Clients Dead?, he discusses alternatives to the thin client which are very similar to what we're trying to do with TOPS.
Of course I also talked to a lot of other guys too, and all of the different people have something to add to the conversation. This is what makes JAOO such a good conference, this and the extremely good program and set of speakers.
I hope to be back next year.
Besides going to a lot if interesting talks (not to mention the tutorials), and getting a lot of new ideas from that, the main thing has been that I've met a great many interesting people. This is what is good about JAOO, the speakers are very interested in talking to the other participants, and the schedule facilitates this with the parties and other activities.
I already mentioned meeting Robert C. Martin (Uncle Bob), Dave Thomas and Kevlin Henney. Dave also introduced me to Brian Berry who was his co-godfather of Eclipse. I also had a brief chance to speak with Martin Fowler, but he's more like a rock star these days. Steve Freeman and Nat Pryce of jMock and NMock were also two people I had the pleasure to meet. I especially got to spend quite some time with Steve, and we had quite a few discussions on agile development and computer science fundamentals. Another interesting guy was Adam Bien, an independant consultant from Germany. He has some down to earth views on how to develop J2EE applications, and in his talk called Are Java Fat Clients Dead?, he discusses alternatives to the thin client which are very similar to what we're trying to do with TOPS.
Of course I also talked to a lot of other guys too, and all of the different people have something to add to the conversation. This is what makes JAOO such a good conference, this and the extremely good program and set of speakers.
I hope to be back next year.
Saturday, October 01, 2005
Model doesn't mean UML
Everywhere in the software industry today we encounter the notion of model. Certainly the schedule at JAOO was filled with references to it; it even had a separate track on Model Driven Architecture.
I've always been very sceptical to the ideal that of executable UML and the whole "software through pictures" crowd, because I really think it isn't that simple. The thing is that this has given me a very negative association to anything that sounds like "Model Driven Something", because model has to be a set of UML diagrams, right?
Wrong!
When most well-established speakers and software professionals like Martin Fowler, Eric Evans, Dave Thomas, Andy Hunt, Kevlin Henney and the like, talk about models, they are talking about the mental concepts that we build during our investigation of the problem domain.
The main point is that a model is an abstraction of the problem area or domain for which we build the software. Now this can sometimes be represented by UML diagrams, but seldom completely and never in an absolute way.
So remember this: UML is a communication tool, the model is ultimately in your head (and hopefully in the head of your teammates...).
And whenever someone speaks about Model Driven Design or Model Driven Development, take a closer look and don't dismiss it even if you are (rightly) sceptical of Model Driven Architecture.
I've always been very sceptical to the ideal that of executable UML and the whole "software through pictures" crowd, because I really think it isn't that simple. The thing is that this has given me a very negative association to anything that sounds like "Model Driven Something", because model has to be a set of UML diagrams, right?
Wrong!
When most well-established speakers and software professionals like Martin Fowler, Eric Evans, Dave Thomas, Andy Hunt, Kevlin Henney and the like, talk about models, they are talking about the mental concepts that we build during our investigation of the problem domain.
The main point is that a model is an abstraction of the problem area or domain for which we build the software. Now this can sometimes be represented by UML diagrams, but seldom completely and never in an absolute way.
So remember this: UML is a communication tool, the model is ultimately in your head (and hopefully in the head of your teammates...).
And whenever someone speaks about Model Driven Design or Model Driven Development, take a closer look and don't dismiss it even if you are (rightly) sceptical of Model Driven Architecture.
Subscribe to:
Posts (Atom)