Finally some time to talk about my most recent pet pieve. Rest assured, the message is just the same as with my rants on Test-Driven Development. But as Dan says: It's all about getting the words right. Dan has gotten this impulse from Domain Driven Design, and you all should know how I feel about that.
So what is the core message: TDD is not about testing, it's all about behaviour!!! Behaviour-Driven Design helps us put the right focus on unit testing. Is this really any different from TDD? Well, not if you do it right. The problem is that the right way to do TDD is often hidden by the word Test. Many people think the main benefit of Test-Driven Design is testing your code, which is natural with this name.
WRONG!
The most important benefit of TDD is that it drives the design, the behaviour of your code. This is what BDD helps point out. BDD is an extension of TDD and Acceptance-Test Driven Planning. Basically it gives a template to use when defining User stories, that includes a context for the story, a benefit that the feature will give and a set of scenarios that can be used for acceptance tests.
For me this puts a required frame around the whole concept of developing quality code. There needs to be a connection between the story with its acceptance criteria, and the tests that we write for the code.
JBehave is a testing framwork that tries to make it easier to write tests the way the should be written. Its Ruby cousin is rBehave (the site is not operational yet, coming soon). I haven't had the chance to try them out yet, so the code will have to wait until another time. Be sure to check it out.
Monday, October 09, 2006
Thursday, October 05, 2006
MEGO
Kevlin Henney tought me a new expression in his talk, that I think it is worth to share:
MEGO - My Eyes Glace Over...
which refers to the effect you see when people are just not getting what you talk about.
MEGO - My Eyes Glace Over...
which refers to the effect you see when people are just not getting what you talk about.
People I didn't get the chance to meet
The problem with a big conference like JAOO has become, is that it is just impossible to get around to talking to all the people you would like to. There were a couple of the speakers I would have liked to talked to. Karsten Lentzsch was here, you know, the JGoodies guy. I also would have liked to catch up with Patrick Linskey from BEA. We have some outstanding questions with them. Still I'm only one person.
The biggest regret though, is not being able to talk to more of the other developers that are here. It is a great chance to meet other people with the same interests. I think one of the problems is that the conference has gotten so big, and being split across the SAS hotel and the Musikkhuset Concert Hall, it gets harder to meet people.
The biggest regret though, is not being able to talk to more of the other developers that are here. It is a great chance to meet other people with the same interests. I think one of the problems is that the conference has gotten so big, and being split across the SAS hotel and the Musikkhuset Concert Hall, it gets harder to meet people.
Wednesday, October 04, 2006
JAOO Day Three - Wednesday
There was an especially interesting track today, and thats the track called "Back to the Future". This is one of Dave Thomas' brainchild, which allows him to present the things that have been done before. One of his pet pieves is that we need to study the past in order to develop the right technology the right way for the future. And I totally agree with him. That's why I spent most of my time in that track today.
The first session was the introduction to the track by Dave Thomas, a talk he calles "Hot old ideas". In this talk he goes through much of the history of computing and programming languages, basically listing all the languages and given a brief description. You'll have to look at the presentation. The message is: It is dangerous to live in a monoculture! Learn about other languages and technologies to find out what was done in the past, what worked, what didn't and most importantly: WHY!!!
The second talk was done by Guy Steele (father of the Scheme language, together with Gerald Sussman). His talk was about "The history of Scheme". He explained the tradition at MIT that led up to the creation of Scheme, as well as some of the other languages that was created at MIT prior to Scheme. This was very interesting, especially after having studied the Abelson/Sussman lectures, which use lisp (of which Scheme is a dialect).
After lunch I went to a presentation by Dan North and Niclas Nilsson about "Behaviour -Driven Development". As I have mentioned earlier, I have spent some time talking to these guys over the last couple of days, and I must say that BDD really interests me. In fact I think it is a key to doing software development right!! Wow. That's a big statement. I think that deserves a separate blog entry. To be continued.
The last session of the day was a brilliant talk by Kevlin Henney called "The five considerations of Software Architecture". In this talk Kevlin lists five considerations that should be in the back of our minds when we are dealing with software development. The considerations are:
These are not rules, simply considerations that needs to be taken into account when we are making the decisions that make up the architecture and design of our systems. After the talk, Kevlin told me that he really has a four hour talk on this subject that shows how these considerations really are applicable to any level of development from the business analysis to the coding itself. Since Kevlin is such a brilliant speaker, I'm considering brining him to Stavanger to do this talk for Statoil. I think it would do us good.
The day ended with a panel of selected speaker talking about the future of programming, more specifically how will we be programming in 2016 (ten years from now). Dave Thomas moderated the panel, which consisted of Guy Steele, Ole Lehrmann Madsen, Steve Vinoski, Kevlin Henney and Erik Meijer. In my opinion, the panel really didn't take the subject far enough, and ended up talking about how concurrency will influence future programming. There was also some discussion about how tools and programming languages will evolve. All in all pretty interesting.
After this event I would up in the hotel bar for a couple of hours with Dan North, Niclas Nilsson and a couple of other guys, one of them was a thoughtworker called Ian Cartwright. He's a young guy, but as all thoughtworkers, pretty smart, and actually the substitute for Martin Fowler. Turns out he has co-presented with Martin on a number of occations. This was an enjoyable couple of hours, and we got to talk a little bit about our situation in Statoil, and the thoughtworkers shared a couple of tips with me. They all offered to help us out if we wanted, which is good to know. We also spent some time discussion Aspect oriented programming, and a seed for a new article was sawn. I think it is time to give some counter examples to this AOP thing, since all we hear is that it is useful for things like logging and security. I'm considering doing an article on this even if it means I'll have to read up on AOP a bit. We'll see. It's good to know that these guys, who are unbelievably smart guys, are actually interested in the opinions of a guy like me. Cool.
The first session was the introduction to the track by Dave Thomas, a talk he calles "Hot old ideas". In this talk he goes through much of the history of computing and programming languages, basically listing all the languages and given a brief description. You'll have to look at the presentation. The message is: It is dangerous to live in a monoculture! Learn about other languages and technologies to find out what was done in the past, what worked, what didn't and most importantly: WHY!!!
The second talk was done by Guy Steele (father of the Scheme language, together with Gerald Sussman). His talk was about "The history of Scheme". He explained the tradition at MIT that led up to the creation of Scheme, as well as some of the other languages that was created at MIT prior to Scheme. This was very interesting, especially after having studied the Abelson/Sussman lectures, which use lisp (of which Scheme is a dialect).
After lunch I went to a presentation by Dan North and Niclas Nilsson about "Behaviour -Driven Development". As I have mentioned earlier, I have spent some time talking to these guys over the last couple of days, and I must say that BDD really interests me. In fact I think it is a key to doing software development right!! Wow. That's a big statement. I think that deserves a separate blog entry. To be continued.
The last session of the day was a brilliant talk by Kevlin Henney called "The five considerations of Software Architecture". In this talk Kevlin lists five considerations that should be in the back of our minds when we are dealing with software development. The considerations are:
- Economy
- Visibility
- Spacing
- Symmetry
- Emergence
These are not rules, simply considerations that needs to be taken into account when we are making the decisions that make up the architecture and design of our systems. After the talk, Kevlin told me that he really has a four hour talk on this subject that shows how these considerations really are applicable to any level of development from the business analysis to the coding itself. Since Kevlin is such a brilliant speaker, I'm considering brining him to Stavanger to do this talk for Statoil. I think it would do us good.
The day ended with a panel of selected speaker talking about the future of programming, more specifically how will we be programming in 2016 (ten years from now). Dave Thomas moderated the panel, which consisted of Guy Steele, Ole Lehrmann Madsen, Steve Vinoski, Kevlin Henney and Erik Meijer. In my opinion, the panel really didn't take the subject far enough, and ended up talking about how concurrency will influence future programming. There was also some discussion about how tools and programming languages will evolve. All in all pretty interesting.
After this event I would up in the hotel bar for a couple of hours with Dan North, Niclas Nilsson and a couple of other guys, one of them was a thoughtworker called Ian Cartwright. He's a young guy, but as all thoughtworkers, pretty smart, and actually the substitute for Martin Fowler. Turns out he has co-presented with Martin on a number of occations. This was an enjoyable couple of hours, and we got to talk a little bit about our situation in Statoil, and the thoughtworkers shared a couple of tips with me. They all offered to help us out if we wanted, which is good to know. We also spent some time discussion Aspect oriented programming, and a seed for a new article was sawn. I think it is time to give some counter examples to this AOP thing, since all we hear is that it is useful for things like logging and security. I'm considering doing an article on this even if it means I'll have to read up on AOP a bit. We'll see. It's good to know that these guys, who are unbelievably smart guys, are actually interested in the opinions of a guy like me. Cool.
Common pitfals and misconceptions of Agile methods
I really found that the insights offered by Jutta Eckstein in her talk yesterday deserves a separate post. I'll list the pitfalls she mentioned and describe them a little.
Agility is ...
Agility really is:
Too much focus on practices
This means that we implement the practices like daily meetings, test-driven development and so on without looking at the values that these practices are supporting. This is a key point! It is the agile values that makes agile methods work. The practices of for instance XP or Scrum are just there to support and enforce the values. Many people doesn't get this.Missing result orientation
One of the fundamental ideas in agile methods is the goal of producing a product that is useful to a customer. If we loose track of this and start to focus on just delivering without the link to creating business value, there is no overall goal, and the project fails.Too many interruptions
Not taking sufficient steps to protect the team during an iteration can be fatal to projects. If the team is not working on a fixed task list during an iteration, or the team is not fully allocated to the task at hand. Scrum helps with this by isolating the team for the iteration and removing other impediments.Repeat the same mistakes
Do retrospectives and learn from it. The mistake many new agile projects make is that they identify the mistakes in retrospectives, but don't do anything to make it better. Point is to adapt to the things that are identified.Lacking integration of the product
The importance of integration is ignored or underestimated. Frequent build failures or build takes too long is often a problem. This cannot be ignored during an iteration or sprint.No overall release plan
Most people plan individual iterations or sprints but some forget that it is the product roadmap or release plan that is the most important.Agile is for developers only
Agile methods affects the entire the whole organization. Jeff Sutherland (Scrum) argues that the entire organization needs to be organized as a set of Scrums in order to reach the hyper-productive states. He has done this, so he knows what he is talking about.Common misunderstandings
Agility is ...
- ... a specific methodology only - NO there are many
- ... defined by practices - NO actually it is the values that matter
- ... and undiciplined approach - NO it takes a lot of diciplin to do agile
Agility really is:
- Value system
- Neither chaos nor dogmatism
- Joint responsibility
- Culture of change
- Continuous learning
Tuesday, October 03, 2006
JAOO Day Two - Tuesday
The day started with a really interesting keynote by Guy Steele from Sun Microsystems. He is a language designer and the father of Scheme (lisp dialect used in Emacs among other things). The talk was about an interesting new language under development called Fortress. It is supposed to be a language for the scientific community, and as he said "It is supposed to do for Fortran what Java did for C". By which he means remove the possibility for making the most common mistakes, as well as providing platform independance and multithreading. The goal is to make the syntax of the language as close to mathematical notation as possible, plus they want to grow the type system and compiler, which means that they have to have an extendable type system where the types are not built in but specified in libraries (which you can override with your own implementations of course). Very cool stuff.
Most of the rest of the day I spent in the track titled "What makes agile work?". The introduction was by Jutta Eckstein, and she talked about common pitfalls when adopting agile methods especially in large organizations. I'll do a separate post on that, as I think it is especially important for us in Statoil.
Similarly, Roman Pichler talked about a failed attempt of introducing agile in a company, and why that failed. The main reason was that the initiative came from management, and as soon as the going got though, the management backed out and reverted to the "safe" old ways of the gant chart and the project plan.
After lunch I enjoyed a session with Kevlin Henney, where he talks about the "Six faces of Agile Development". This are six different aspects of agile methods that influence how it works and how it can be implemented. The six faces are:
One of the most interesting talks of the day was by Jeff Sutherland (father of Scrum), on "Making good Scrum". The main message here was that Scrum easily gives you a productivity gain of the factor of 2, just by implementing it correctly. That is just by using product backlogs, sprints, daily scrums and so on. The potential, as shown by Toyota, and numerous examples in the IT industry, is a productivity gain in the order of 5-10 times. In order to acchieve this, the first step is to be really agressive in removing impediments for the teams. This attitude has to go all the way up to the top management. The next steps are really just becomming more agressive in the whole scrum implementation. Also the scrum implementation needs to be done throughout the organization, not just in the software development teams. The most successful companies, like PatientKeeper where Jeff now works as CTO, actually organize all levels of management as scrum teams. These are very cool idea that makes me look forward to the Scrum Master training class I'll be taking with him on Thursday and Friday.
Afther this, Esther Derby, author of many books, among others "Behind Closed Doors - Secrets of Great Managers" (which I recommend all should read), had a talk about "Organizational Culture and agile adoptation". This basically had to do with how different organization cultures influence how you can introduce agile methods. Nothing really new here, but it is important that we evaluate the culture when we try to implement agile methods.
For the last session of the day, I chose Eric Evans and his talk on how Domain Driven Design can benefit from Domain Specific Languages. Eric admits to being a little sceptical to DSLs and their use for core business domains. He thinks it might be just too complicated to build domain languages for business domains. Charles Simonyi from Intentional Software (the DSL guys referred to in Martin Fowlers Language Workbenches article) of course disagrees, and there was a little interesting discussion of this after the talk. Erics position is that the DSL are more useful for the generic subdomains, especially the technical ones. He used examples from time and money to show how a DSL could improve that code.
After the talk we had a little discussion between Eric Evans, Dave Thomas and Obie Fernandez (Ruby on Rails guy working for ThoughtWorks in the US) (I was there too, but contributed very little to the discussion ;-) . It started out with Dave commenting on that the stuff Eric is doing in Time and Money has already been done many times by others, for instance the code in Kent Becks TDD book (actually written for Dave by Ward Cunningham !!!), and that "real" languages has these concepts built in. He referred to technology developed as part of financial applications. The discussion went on to discuss quality of libraries for languages, and that there really isn't any market for this as people does not want to pay for them, which leads to questionable quality in many if not most cases. We also touched upon other languages like Ruby and Ruby on Rails, and Obie was saying that with JRuby we would be able to deploy Rails apps on Tomcat, which would be great because then companies hosting Java web apps can host Rails apps. Then Dave said that that will bring the servers down because the Java VM is not resource sharable, which basically means that each session has its own JVM with resources and instances of shared libraries and the whole shebang. My point in relating this is that talking to Dave (or listening to him) always leaves me with a mixed feeling. The guy has been around for so long, and done so many different things, that he more or less knows as everything works (at least that's what it feels like to me), so while I'm excited to learn this stuff, I'm also bummed out by his disillusioned outlook on things. I guess that it comes at time when we all start being more realistic. I certainly allways learn alot from these discussions.
After this I was quite exhausted after a long day, so I went to get some food and went to bed early. Tomorrow is another full day of interesting talks.
Most of the rest of the day I spent in the track titled "What makes agile work?". The introduction was by Jutta Eckstein, and she talked about common pitfalls when adopting agile methods especially in large organizations. I'll do a separate post on that, as I think it is especially important for us in Statoil.
Similarly, Roman Pichler talked about a failed attempt of introducing agile in a company, and why that failed. The main reason was that the initiative came from management, and as soon as the going got though, the management backed out and reverted to the "safe" old ways of the gant chart and the project plan.
After lunch I enjoyed a session with Kevlin Henney, where he talks about the "Six faces of Agile Development". This are six different aspects of agile methods that influence how it works and how it can be implemented. The six faces are:
- Practices
- Organization
- Architecture
- Tools
- Skills
- Attitude
One of the most interesting talks of the day was by Jeff Sutherland (father of Scrum), on "Making good Scrum". The main message here was that Scrum easily gives you a productivity gain of the factor of 2, just by implementing it correctly. That is just by using product backlogs, sprints, daily scrums and so on. The potential, as shown by Toyota, and numerous examples in the IT industry, is a productivity gain in the order of 5-10 times. In order to acchieve this, the first step is to be really agressive in removing impediments for the teams. This attitude has to go all the way up to the top management. The next steps are really just becomming more agressive in the whole scrum implementation. Also the scrum implementation needs to be done throughout the organization, not just in the software development teams. The most successful companies, like PatientKeeper where Jeff now works as CTO, actually organize all levels of management as scrum teams. These are very cool idea that makes me look forward to the Scrum Master training class I'll be taking with him on Thursday and Friday.
Afther this, Esther Derby, author of many books, among others "Behind Closed Doors - Secrets of Great Managers" (which I recommend all should read), had a talk about "Organizational Culture and agile adoptation". This basically had to do with how different organization cultures influence how you can introduce agile methods. Nothing really new here, but it is important that we evaluate the culture when we try to implement agile methods.
For the last session of the day, I chose Eric Evans and his talk on how Domain Driven Design can benefit from Domain Specific Languages. Eric admits to being a little sceptical to DSLs and their use for core business domains. He thinks it might be just too complicated to build domain languages for business domains. Charles Simonyi from Intentional Software (the DSL guys referred to in Martin Fowlers Language Workbenches article) of course disagrees, and there was a little interesting discussion of this after the talk. Erics position is that the DSL are more useful for the generic subdomains, especially the technical ones. He used examples from time and money to show how a DSL could improve that code.
After the talk we had a little discussion between Eric Evans, Dave Thomas and Obie Fernandez (Ruby on Rails guy working for ThoughtWorks in the US) (I was there too, but contributed very little to the discussion ;-) . It started out with Dave commenting on that the stuff Eric is doing in Time and Money has already been done many times by others, for instance the code in Kent Becks TDD book (actually written for Dave by Ward Cunningham !!!), and that "real" languages has these concepts built in. He referred to technology developed as part of financial applications. The discussion went on to discuss quality of libraries for languages, and that there really isn't any market for this as people does not want to pay for them, which leads to questionable quality in many if not most cases. We also touched upon other languages like Ruby and Ruby on Rails, and Obie was saying that with JRuby we would be able to deploy Rails apps on Tomcat, which would be great because then companies hosting Java web apps can host Rails apps. Then Dave said that that will bring the servers down because the Java VM is not resource sharable, which basically means that each session has its own JVM with resources and instances of shared libraries and the whole shebang. My point in relating this is that talking to Dave (or listening to him) always leaves me with a mixed feeling. The guy has been around for so long, and done so many different things, that he more or less knows as everything works (at least that's what it feels like to me), so while I'm excited to learn this stuff, I'm also bummed out by his disillusioned outlook on things. I guess that it comes at time when we all start being more realistic. I certainly allways learn alot from these discussions.
After this I was quite exhausted after a long day, so I went to get some food and went to bed early. Tomorrow is another full day of interesting talks.
Monday, October 02, 2006
JAOO Day One - Monday
This has been a most interesting day. Usually the first day, and at least the first half of the first day is pretty slow when you're at a conference. You haven't really made much contact with the other participants yet, and you're just adjusting to the conference.
I went to a few sessions in the Modelling and Design track, and some in the SOA track. Martin Fowler was supposed to chair the modelling track, but unfortunately he was unable to come due to back problems (apparently he has cronic back problems), and it was Dave Thomas (the original, not pragmatic), and he was reiterating the theme from last year (see previous blog) that models and modelling is not equivalent to UML and UML diagrams. Model driven development should be all about human communication and alignment of the model in everyones head. Much in the way Eric Evans has preach to us.
After that I was in a presentation that sounded very promising as its title was Resources, Event, Agents. So I was thinking that we might get some of the SJEF ideas here, but it turned out that he was referring to the REA business pattern, so I was quite disappointed, so I left.
I caught a talk by Beat Schwegler of Microsoft about "Architecting Applications for a changing world". His main theme was to make sure that what is implemented can be directly traced to value for the business. The business model must be mapped to the service model which again should be mapped to the technical model. There are two messages here one is that the service model must reflect the business model, and the other is that the service interfaces should be separated from the underlying (or implementing) technology. This last point is just as important, as this will make sure that the service interfaces are not technology driven.
Gregor Hohpe had a talk about conversational patterns in messaging systems. It was very interesting to see the different patterns of message interaction. This is work in progress from Gregor.
Finally I was fortunately enough to catch a talk by Erik Dürenburg of Thoughtworks about Software Vizualization. Basically this was about creating tools to answer the questions you want answered about your systems. Tool creation is a much vider topic (which I will return to), but in this context it is about analysing source code or running systems to provide answers to questions. Visualization can range from tables of metrics (like the ones we get from JDepend) to graphs of class dependencies. He showed that with very limited efforts they were able to analyse jar file dependencies, using a tool called CodeCrawler to visualize them. They also use a small tool like GraphViz Dot for most of the graphics generation. This is definately something we should use. There is a critical need to monitor the runtime jar dependencies of our system. How cool would it be to build a tool that does this for us.
I intentionally missed Eric Evans sessions, as I've been through that a number of times before, but I met up with him after his talk and we had a chat, and we ended up going to the ending keynote together. This was an inspiring talk by Alistair Cockburn on Methodology and the human aspects of agile methodologies. Very interesting stuff.
The day ended with the conference party, and I was fortunate enough to end up at a table next to Alistair Cockburn (so I finally met him), Dan North, Niclas Nilsson and serval other interesting people. We ended up discussing various agile topics. Great guys to talk to. Dan North is the man behind a new concept called Behaviour-Driven Development which is a step beyond Test-Driven Development. He and Niclas has a talk on this on Wednesday, which I look forward to. We ended up talking and drinking beer for most of the evening, and I had a great time.
I also got the chance to speak with Kevlin Henney, Dave Thomas and Gregor Hohpe. After this, the rest of the conference will be much more fun. This is what I mean when I say the first part of the first day is slow. Looking forward to tomorrow.
I went to a few sessions in the Modelling and Design track, and some in the SOA track. Martin Fowler was supposed to chair the modelling track, but unfortunately he was unable to come due to back problems (apparently he has cronic back problems), and it was Dave Thomas (the original, not pragmatic), and he was reiterating the theme from last year (see previous blog) that models and modelling is not equivalent to UML and UML diagrams. Model driven development should be all about human communication and alignment of the model in everyones head. Much in the way Eric Evans has preach to us.
After that I was in a presentation that sounded very promising as its title was Resources, Event, Agents. So I was thinking that we might get some of the SJEF ideas here, but it turned out that he was referring to the REA business pattern, so I was quite disappointed, so I left.
I caught a talk by Beat Schwegler of Microsoft about "Architecting Applications for a changing world". His main theme was to make sure that what is implemented can be directly traced to value for the business. The business model must be mapped to the service model which again should be mapped to the technical model. There are two messages here one is that the service model must reflect the business model, and the other is that the service interfaces should be separated from the underlying (or implementing) technology. This last point is just as important, as this will make sure that the service interfaces are not technology driven.
Gregor Hohpe had a talk about conversational patterns in messaging systems. It was very interesting to see the different patterns of message interaction. This is work in progress from Gregor.
Finally I was fortunately enough to catch a talk by Erik Dürenburg of Thoughtworks about Software Vizualization. Basically this was about creating tools to answer the questions you want answered about your systems. Tool creation is a much vider topic (which I will return to), but in this context it is about analysing source code or running systems to provide answers to questions. Visualization can range from tables of metrics (like the ones we get from JDepend) to graphs of class dependencies. He showed that with very limited efforts they were able to analyse jar file dependencies, using a tool called CodeCrawler to visualize them. They also use a small tool like GraphViz Dot for most of the graphics generation. This is definately something we should use. There is a critical need to monitor the runtime jar dependencies of our system. How cool would it be to build a tool that does this for us.
I intentionally missed Eric Evans sessions, as I've been through that a number of times before, but I met up with him after his talk and we had a chat, and we ended up going to the ending keynote together. This was an inspiring talk by Alistair Cockburn on Methodology and the human aspects of agile methodologies. Very interesting stuff.
The day ended with the conference party, and I was fortunate enough to end up at a table next to Alistair Cockburn (so I finally met him), Dan North, Niclas Nilsson and serval other interesting people. We ended up discussing various agile topics. Great guys to talk to. Dan North is the man behind a new concept called Behaviour-Driven Development which is a step beyond Test-Driven Development. He and Niclas has a talk on this on Wednesday, which I look forward to. We ended up talking and drinking beer for most of the evening, and I had a great time.
I also got the chance to speak with Kevlin Henney, Dave Thomas and Gregor Hohpe. After this, the rest of the conference will be much more fun. This is what I mean when I say the first part of the first day is slow. Looking forward to tomorrow.
JAOO Opening keynote: The Amazon.com technical platform
Werner Vogels held the opening keynote, talking about the technology platform behind the Amazon.com success.
Amazon.com is really a technical platform, not just a web site. This makes it possible to support other sites, not just selling products from other vendors, but also running their sites and fully integrating their e-commerce sites. This is possible due to an architecture with extensive use of webservices to wrap both functionality and data. The services are split into a set of Foundation services and a set of Aggregator services. All of which are available to customers of Amazon.
Very interesting to see how the need for scalability has driven the development of a service oriented architecture using webservices. The resulting architecture is very close to the SJEF principles that we adhere to.
Amazon.com is really a technical platform, not just a web site. This makes it possible to support other sites, not just selling products from other vendors, but also running their sites and fully integrating their e-commerce sites. This is possible due to an architecture with extensive use of webservices to wrap both functionality and data. The services are split into a set of Foundation services and a set of Aggregator services. All of which are available to customers of Amazon.
Very interesting to see how the need for scalability has driven the development of a service oriented architecture using webservices. The resulting architecture is very close to the SJEF principles that we adhere to.
Kick off for JAOO 2006
I'm now at the JAOO 2006 conference. This year looks very promising with a lot of great speakers like Eric Evans, Martin Fowler, Jeff Sutherland, Alistair Cockburn, Jutta Eckstein, Dave Thomas, Gregor Hophe and the list just goes on and on.
I'll try to attend as many sessions as I can over the next couple of days. My only regret is that I'm alone from Statoil, as there is just too much for one guy to cover.
I'll keep you posted by things that I pick up during the next days, so be sure to keep your eyes (or RSS readers) fixed on this blog for the next couple of days.
I'll try to attend as many sessions as I can over the next couple of days. My only regret is that I'm alone from Statoil, as there is just too much for one guy to cover.
I'll keep you posted by things that I pick up during the next days, so be sure to keep your eyes (or RSS readers) fixed on this blog for the next couple of days.
SPE Annual Technical Conference and Exhibition
I just returned from San Antonio, Texas, where a collegue and myself were fortunate enough to be allowed to participate with a paper on software agents and their potential in the upstream oil business.
The conference was a huge success for us. Lots of interest in our paper, and we learned some things about the state of practice as well. And quite frankly we are not impressed.
San Antonio was very nice, as well. It is a very nice city, and we got to se a lot of it. The weather was nice as well with the temperature in the high twenties, low thirties all week (centigrades of course). We enjoyed the riverwalk, the Alamo and the other sights tremendously. Even got some souvenirs...
The conference was a huge success for us. Lots of interest in our paper, and we learned some things about the state of practice as well. And quite frankly we are not impressed.
San Antonio was very nice, as well. It is a very nice city, and we got to se a lot of it. The weather was nice as well with the temperature in the high twenties, low thirties all week (centigrades of course). We enjoyed the riverwalk, the Alamo and the other sights tremendously. Even got some souvenirs...
Saturday, January 28, 2006
Does Java 5 Generics give you better code?
I think I start to understand at least part of the Java 5 Generics now. I'm really not convinced that the benefit is worth the syntax and reduced readability. I'll try to explain why...
I must confess that I see the point for the simple cases. In Java 1.4 the code for finding payments over a certain limit in a list of Payments would look like this:
And the bad thing is that we've all gotten used to that horrible casting syntax. With Java 5 we could change this function to something like this:
And that's much better, right?
My problem is with the more advanced uses of this new tool. I'll admit that I haven't fully understood this, but if you want to create code that must accept a typed collection or even worse a map, you'll have to learn the more advanced syntax where
This is where it gets hairy, and where I start to think it might just not be worth it. On the other hand, I could leave that problem to the framework makers.
I must confess that I see the point for the simple cases. In Java 1.4 the code for finding payments over a certain limit in a list of Payments would look like this:
public List findAllPaymentsOverLimit(List payments,
int limit)
{
List overLimitPayments = new ArrayList();
for(Iterator each = payments.iterator(); each.hasNext(); ) {
Payment payment = (Payment) each.next();
if (payment.amount > limit)
overLimitPayments.add(payment);
}
return overLimitPayments;
}
And the bad thing is that we've all gotten used to that horrible casting syntax. With Java 5 we could change this function to something like this:
public List<Payment> findAllPaymentsOverLimit(
List<Payment> payments,
int limit)
{
List<Payment> overLimitPayments
= new ArrayList<Payment>();
for (Payment payment : payments) {
if (payment.amount > limit)
overLimitPayments.add(payment);
}
return overLimitPayments;
}
And that's much better, right?
My problem is with the more advanced uses of this new tool. I'll admit that I haven't fully understood this, but if you want to create code that must accept a typed collection or even worse a map, you'll have to learn the more advanced syntax where
List<? extends Class>or
List<? super Class>
This is where it gets hairy, and where I start to think it might just not be worth it. On the other hand, I could leave that problem to the framework makers.
What have I been doing?
As can be seen from the blog it has been quite a while since my last post. I could always say that I've been busy (which is true), or that I haven't had that much to say, but that would just be excuses.
In these past months I've been busy working on getting more agile practices accepted at work. Ever since our sessions with Eric Evens and his guys, I've been convinced that we must change the way we develop software. The full implications of this did not register until I experienced the talk by Robert C. Martin at JAOO last autumn. Since then I've been devouring everything I could find on agile development, and it has been my main focus. I've also tried to speed up the process of change in my company, but as all big corporations it is slow.
I have, however, also found the time for some coding. God forbid I should forget how to do that. At work I've been busy doing some integration work, so it has been a lot of Java and XML. At home I've found just a little time to play a little bit with Ruby and Java 5 (more on that later).
Well, lets hope the next post doesn't delay as long as this one. See you.
In these past months I've been busy working on getting more agile practices accepted at work. Ever since our sessions with Eric Evens and his guys, I've been convinced that we must change the way we develop software. The full implications of this did not register until I experienced the talk by Robert C. Martin at JAOO last autumn. Since then I've been devouring everything I could find on agile development, and it has been my main focus. I've also tried to speed up the process of change in my company, but as all big corporations it is slow.
I have, however, also found the time for some coding. God forbid I should forget how to do that. At work I've been busy doing some integration work, so it has been a lot of Java and XML. At home I've found just a little time to play a little bit with Ruby and Java 5 (more on that later).
Well, lets hope the next post doesn't delay as long as this one. See you.
Subscribe to:
Posts (Atom)