Monday, February 20, 2006
Dependency Injection in Geronimo, Part 2
As surely as Spring follows winter, the 2nd part of my depenency injection article on DeveloperWorks is now live. This version builds on the "raw" topic of dependency injection in the 1st part and shows how it applies to Geronimo. Geronimo has a very interesting architecture, and will surprise some people who think that "dependency injection" == "Spring".
Saturday, February 11, 2006
My Last Borland Post Ever (I Promise!)
Those of you who follow my blog know that I post an inordinate amount of material about Borland. I have a long-standing love for Borland: my first book was on Delphi (Developing with Delphi: Object-oriented Techniques) and my second was on JBuilder (JBuilder 3 Unleashed). I learned about real software development using Borland tools. When I bought my first computer, I bought just 2 pieces of software: DOS 3.3 and Turbo Pascal 5. And I didn't need any other software for almost a year.
Borland has perpetual financial and directional problems over the years. But, like loyal fans of Saturday Night Live, most of us stuck around even when it sucked (Inprise, anyone?)
Now, though, Borland has taken the last fatal step towards irrelevance: they are in the process of divesting their entire IDE division (check out this eWeek article). Yes, that's right: the company that brought us Turbo Pascal, Turbo C, Turbo Prolog (OK, maybe we didn't need that one), Delphi, and JBuilder will no longer sell a single compiler. I wonder what Anders thinks about this (or if he even noticed).
Borland is reinventing itself as a strictly ALM (Application Lifecycle Management) company, selling tools that have awesome support for Big Design Up Front (BDUF) like CaliberRM, TogetherJ, and the Segue tools they just acquired. What a great day for Waterfall projects (I wonder if they would consider sponsoring the Waterfall 2006 conference)?
For those of us with an irrational (pun intended) love of Borland, this is indeed a dark day. RIP.
Borland has perpetual financial and directional problems over the years. But, like loyal fans of Saturday Night Live, most of us stuck around even when it sucked (Inprise, anyone?)
Now, though, Borland has taken the last fatal step towards irrelevance: they are in the process of divesting their entire IDE division (check out this eWeek article). Yes, that's right: the company that brought us Turbo Pascal, Turbo C, Turbo Prolog (OK, maybe we didn't need that one), Delphi, and JBuilder will no longer sell a single compiler. I wonder what Anders thinks about this (or if he even noticed).
Borland is reinventing itself as a strictly ALM (Application Lifecycle Management) company, selling tools that have awesome support for Big Design Up Front (BDUF) like CaliberRM, TogetherJ, and the Segue tools they just acquired. What a great day for Waterfall projects (I wonder if they would consider sponsoring the Waterfall 2006 conference)?
For those of us with an irrational (pun intended) love of Borland, this is indeed a dark day. RIP.
Continuous Integration Conference
An interesting (free!) conference is coming to Chicago in early April this year, an Open Space event on Continuous Integration and Automated Testing. Both of these subjects are dear to my heart, so I'm hoping to help get the word out about this conference. They organizers haven't set the date yet because they need to see how many people are interested before they will know how big a space to reserve.
Support CI and AT: contact Jeffrey Fredrick (jtf@agitar.com) or Paul Julius (pj@thoughtworks.com) through the Yahoo group groups.yahoo.com/group/citcon and sign up for the mailing list.
Automation and Testing are Good Things!
Support CI and AT: contact Jeffrey Fredrick (jtf@agitar.com) or Paul Julius (pj@thoughtworks.com) through the Yahoo group groups.yahoo.com/group/citcon and sign up for the mailing list.
Automation and Testing are Good Things!
Wednesday, February 08, 2006
Dependency Injection in Geronimo Part 1
IBM DeveloperWorks has posted the first of a two-part series on dependency injection in the Geronimo J2EE container. This article focuses on the mechanisms of DI and uses PicoContainer as the container. I did this to divorce the idea of DI from the particular implementation in Geronimo. One of the problems I see in concepts like DI revolves around how you learn it: the implementation from which you learn influences your perception of if forever. Many developers think that DI and the way Spring works are the same thing. By using the lightest weight container I could find (PicoContainer), I hope to show DI in as context-free an environment as possible. The next part of the article takes the concepts and injects (pun intended) them in to Geronimo.
Tuesday, February 07, 2006
SOA Under a Giant Arch
I'm flying to St. Louis tonight to speak at the Gateway JUG. I'm doing my SOA: The Future of Distributed Computing or the Return of the Son of CORBA? talk, helping to promote the upcoming No Fluff, Just Stuff Gateway Software Symposium. Because there is so much sound and fury with so little substance in most SOA discussions, I'm trying to take a pragmatic approach to building SOA, which includes the (what I consider essential) focus on agile development techniques. I feel like I can offer some insight on this subject because I've lived through a lot of distributed computing initiatives and seen a lot of failures. This talk is about how to achieve some of the lofty goals espoused by SOA advocates with a healthy dose of skepticism.
Thursday, February 02, 2006
D-Cubed
I recently read about a most interesting innovation in software development methodology I've heard in a while: Defect Driven Design (D3, pronounced "D Cubed"). This methodology addresses the weak points of most other development methodologies.
Working in D3 is very simple. At the start of the project, you announce that all development is complete and the application is ready for user acceptance testing. The first thing the user will say is "Hey, I thought there was supposed to be an icon on the desktop to launch the application". That's our first defect. We implement code to put an icon on the desktop and announce again that we are done. The user clicks on the icon and nothing happens: "Where is the application?" That's our next defect. You can imagine what the rest of the development rhythm.
The brilliance in this methodology lies in the estimation power. We can estimate with absolute accuracy: 0 days. The entire lifecycle lies in maintenance, which is more realistic because useful software is never actually complete.
Working in D3 is very simple. At the start of the project, you announce that all development is complete and the application is ready for user acceptance testing. The first thing the user will say is "Hey, I thought there was supposed to be an icon on the desktop to launch the application". That's our first defect. We implement code to put an icon on the desktop and announce again that we are done. The user clicks on the icon and nothing happens: "Where is the application?" That's our next defect. You can imagine what the rest of the development rhythm.
The brilliance in this methodology lies in the estimation power. We can estimate with absolute accuracy: 0 days. The entire lifecycle lies in maintenance, which is more realistic because useful software is never actually complete.
Subscribe to:
Posts (Atom)