Just back from OOP 2008 in Munich - this is a fantastic conference, with a great programme and a really smart bunch of attendees. My thanks to Wolfgang Reuter and all the OOP staff for putting together such as great event.
I gave two presentations at the event, a 45 minute presentation on using CXF and GWT to create and consume RESTful services, and then a full-day workshop on building services with CXF - I really enjoyed both; in particular, I was chuffed with the attendance and enthusiasm for CXF at the workshop. One of the attendees has already written up some thoughts on the workshop - thanks James!
I'll happily send on the PDF of my presentation slides for the RESTful services session - just drop me a line in the comments below.
Monday, January 28, 2008
Monday, January 14, 2008
The Dark Side of the Source
One of the great benefits of using open-source, or any source-available software in general, is that, well, you have the source. If you run into a problem then you can debug right into the source-code of your third-party libraries and figure out what's going on. Fantastic. As a consultant on the road I welcome the ability to dive deep.
However, there is a dark side to source code availability: you can get sucked in very easily debugging code that isn't yours. Think about that. You encounter a bug, and, instead of having X lines of code to debug (where X is the number of lines of application code) you've got X + Y lines of code to debug (where Y is the number of of open-source lines of code). Now, the extra lines of code (Y) may give you greater visibility in solving your problem. Or, you may end up loosing time trying to figure out somebody elses code: I call this "The Dark Side of the Source". Recently, I found myself deep in code involving Jetty Continuations, and lost a lot of time trying to figure out what was going on. In the end we had to get directly in touch with the code author to get a fix: if only we'd known to go their first!
So: having the source is great. But don't assume that just because you have the source you can solve all the problems all the time: the source will help you, but you have to be mindful of the impact on your productivity. Go with an open source community that can help you if you get into trouble, and one that gives you a professional support offering for when you get into deeper trouble. The guys at Redmonk (Michael Cote and Stephen O'Grady) have written a nice paper on this - "Working with Open-Source Companies". I got the paper for free from the open.iona.com communities site; I recommend the read.
However, there is a dark side to source code availability: you can get sucked in very easily debugging code that isn't yours. Think about that. You encounter a bug, and, instead of having X lines of code to debug (where X is the number of lines of application code) you've got X + Y lines of code to debug (where Y is the number of of open-source lines of code). Now, the extra lines of code (Y) may give you greater visibility in solving your problem. Or, you may end up loosing time trying to figure out somebody elses code: I call this "The Dark Side of the Source". Recently, I found myself deep in code involving Jetty Continuations, and lost a lot of time trying to figure out what was going on. In the end we had to get directly in touch with the code author to get a fix: if only we'd known to go their first!
So: having the source is great. But don't assume that just because you have the source you can solve all the problems all the time: the source will help you, but you have to be mindful of the impact on your productivity. Go with an open source community that can help you if you get into trouble, and one that gives you a professional support offering for when you get into deeper trouble. The guys at Redmonk (Michael Cote and Stephen O'Grady) have written a nice paper on this - "Working with Open-Source Companies". I got the paper for free from the open.iona.com communities site; I recommend the read.
Subscribe to:
Posts (Atom)
