It's just over 3 months since my retirement, and time has passed quickly. I'm still enjoying it, and I haven't had a moment's regret for my decision to retire. The start of 2009 seems like a good time to take stock of my experiences of retired life so far.
Some things have changed a lot for me since I retired, but the basics of life are still the same. For example, I have good days and not so good days, just like I had at work. The good days are mostly when I feel I have accomplished something. The more tangible and physical the accomplishment is (i.e., not mainly involving time spent in front of a computer), the better.
Top of the list so far of "feel good" accomplishments was completing phase 1 of the Great Tree Stump Project by ripping the first enormous stump out of the ground, after having spent months patiently encircling it and removing its roots (also enormous) one by one with a combination of electric and hand sawing. The key to success is to move enough earth away from the root so that it's completely exposed with daylight underneath. For my enormous stump and enormous roots, this involved digging down very deep and moving a large amount of earth, which needs a fairly large area where the earth can be placed. I discovered by experience that this process needs careful planning so that the earth receiving area is cleared and prepared first, before even starting the encircling and sawing campaign on the stump's roots.
The two stumps I'm removing are in an area of my garden that was once a flower bed but has become completely overrun by weeds, including extensive infestations of bindweed and ivy. The stump removal is part of a larger project to reinstate this area to its original purpose. I'm removing the weeds by digging them out completely by hand, so the earth moving for stump removal purposes has the nice side benefit of enabling me to remove the weeds at the same time. As well as the weeds, the soil is full of very large stones, which I am removing as I go and placing them in rubble sacks filled to the maximum weight that I can lift. I have filled about 20 of these sacks so far, and I'm expecting to have between 25 and 30 when the project is finished. This doesn't include the largest and most attractive flints, which have been separated out for future use in building a rockery on part of the area that's being cleared.
Progress has been slow over the last few weeks because of the wet and cold winter weather and the very limited hours of daylight. Despite this, I have cleared around 80% of the total area and I am about 60% through the encircling campaign on the second stump. The final completion will be announced here and celebrated in a suitable manner!
In my next blog post I'll say more about the other things currently occupying my time and attention. I'll also talk about whether retirement (and life) should be more about "doing" (tree stumps, etc.) or about "being".
It only remains for me to wish you all a healthy and happy New Year! Part of the joy of blogging is that I don't know who will be reading this. I used to be somewhat concerned about this and it made me feel rather inhibited, but now I'm beginning to see it much more as an opportunity. I know I have at least a few readers, from the comments to my last post. Thanks for your kind words, and keep those comments coming!
Thursday, 8 January 2009
Sunday, 5 October 2008
Retiring!
Today is my official last day as an IBM employee. I am retiring after 34 years with IBM, which according to my calculations is around 61% of my life! I've had a great time at IBM, and I have enjoyed the opportunity to do many interesting and satisfying things. The best part has been the relationships I have developed with people I have worked with over the years, many of whom have become close colleagues and friends. My IBM career has been an exciting ride with some wonderful experiences, and now it's the right time for me to move on to the next stage of my life with a different work/life balance and more time for personal and family things.
I'm not completely giving up technical work. I'll still be active as a Tuscany committer and in the SCA standardization work at OASIS. I'm also co-authoring a book on Tuscany. I'll post updates here as the project progresses.
I have made some resolutions for my retirement. One is to go for a walk first thing after breakfast every weekday. I've been doing this for the last 3 weeks when I've been on pre-retirement vacation, and I'm really enjoying it. As well as making me fitter, I'm finding it really good to have some time to think about the things I want to do that day. Thinking while walking seems to be a good combination for me.
Another resolution is to write more of these blog entries! I'm not quite sure how this one will turn out. It takes more effort for me to write a blog entry than go for a walk, but maybe that will change with more practice. My thoughts at the moment are to talk about various things that are occupying me at the moment. These might be technical topics related to Tuscany or SCA, other computer-related matters like my experiences with networked printing at home, or things that have nothing to do with computers such as the Great Tree Stump Project. More about that another day...
I'm not completely giving up technical work. I'll still be active as a Tuscany committer and in the SCA standardization work at OASIS. I'm also co-authoring a book on Tuscany. I'll post updates here as the project progresses.
I have made some resolutions for my retirement. One is to go for a walk first thing after breakfast every weekday. I've been doing this for the last 3 weeks when I've been on pre-retirement vacation, and I'm really enjoying it. As well as making me fitter, I'm finding it really good to have some time to think about the things I want to do that day. Thinking while walking seems to be a good combination for me.
Another resolution is to write more of these blog entries! I'm not quite sure how this one will turn out. It takes more effort for me to write a blog entry than go for a walk, but maybe that will change with more practice. My thoughts at the moment are to talk about various things that are occupying me at the moment. These might be technical topics related to Tuscany or SCA, other computer-related matters like my experiences with networked printing at home, or things that have nothing to do with computers such as the Great Tree Stump Project. More about that another day...
Friday, 8 June 2007
SCA: flexible, extensible, and useful for ordering a beer
This is my first ever blog post so I'd like to start by introducing myself. I'm a member of the Apache Tuscany developer community and I've been involved with Tuscany since the project started in 2005. I'm also an IBM Distinguished Engineer and I have worked on so many software development projects over my career that you really don't want the complete list (trust me). I'll just mention two of these into which I put an especially large dose of myself, with rather different results: RMI-IIOP, which brought together Java RMI and CORBA, became part of the Java platform, and is used by every JEE application server; and Object Rexx, which broke new ground technically for object-oriented scripting languages, but never achieved its full commercial potential for various reasons including the success of Java.
My passion these days is for Service Component Architecture (SCA) and I have started this blog to give my perspective on SCA and explain why it is an important step forward for building distributed applications in a service-oriented style. The views I'll express here are my personal opinions and don't necessarily represent IBM's positions.
Others (Dave Chappell here, Mike Rowley here, Sanjay Patil here, and Steve Kinder here) have expressed their views on whether SCA is a new programming model or not. For me the main value of SCA is not the programming model "in the small" (whether new or not new), but rather that SCA provides a common framework for bringing together assets from a wide range of technologies to create a solution that delivers business value. This isn't a new concept (remember CORBA?), but SCA puts a different spin on it with a framework that's designed for extensibility and isn't prescriptive about using any particular underlying technology. SCA strikes the delicate balance between defining a consistent set of common high-level SOA concepts and being flexible about how these concepts are rendered into different implementation environments that participate in the SCA ecosystem.
CORBA specified IDL for interface definitions and IIOP for the wire protocol. To come to the CORBA party, you needed to be able to define your interfaces using IDL and speak IIOP on the wire. RMI defined its interfaces using Java and spoke the JRMP protocol on the wire, so RMI-IIOP was created to allow RMI to become part of the CORBA ecosystem. With SCA, this uniformity of interface definitions and wire protocols isn't required. The architectural constructs that SCA defines (services, components, references, bindings, interfaces, implementations, composites, wires, policy intents) are designed to be flexible and extensible so that different SCA implementations can render them in different ways into the lower-level specifics of that implementation.
These renderings could differ significantly for different implementation technologies. The SCA 1.0 specs define renderings for Java, BPEL, Spring and C++ as implementation types, and Web services, JMS and EJB as protocol bindings. This set will grow in the future, but SCA usage doesn't need to be bounded by what the spec supports. There's a PHP implementation of SCA, providing a rendering that makes sense in a lightweight scripting environment. The scripting theme also surfaces in Apache Tuscany, which provides SCA renderings for various scripting languages including Ruby, Python, JavaScript and Groovy, as well as the more mainstream support for Java, Spring and C++ that's defined by the SCA specs. In the last week I've seen interest in implementing SCA support for OSGi, and having XSLT transformations as SCA implementations. You can think of SCA as a "lingua franca" for SOA that brings all these technologies together, not at a low level of interface definitions and wire protocols, but at a higher level of assembling, composing and customizing services.
What if some implementations only provide a partial rendering of SCA? Is this OK, or should SCA insist on a strictly defined minimum set of capabilities that everyone needs in order to come to SCA's party? The discussion on this will get going at OASIS soon (the SCA 1.0 specifications don't specify compliance points), so there's no official SCA position on this yet. I understand the value of uniformity and tight specifications, but I'm inclined to think that SCA shouldn't be too rigid and prescriptive about this. Imagine two people talking in a natural language such as English or French, who aren't native speakers and have an imperfect grasp of the language they are using, but can still communicate well enough to get by in their conversation. I was in Italy some years ago trying find a particular village, getting lost on back roads in deepest rural Tuscany, and trying to ask directions from an Italian man who spoke no English. My Italian is pretty bad too (I can manage "una birra, per favore"), and despite best efforts on both sides, it just wasn't going to work. My wife had a brainwave and started talking to the man in French. Success! The Italian man and my English wife both spoke enough French to ask for and receive the directions. Applying this to SCA, if different environments speak different dialects or subsets of SCA, there needs to be enough overlap and mutual understanding to "get by" for some business purpose, but how much shared vocabulary is needed will depend on the particular needs of the services involved. Some environments will provide a full implementation of SCA (fluent native speakers), and others will have just enough vocabulary and grammar to be able to order a beer. More fluency is always better, but let's also remember the greatest values that SCA has to offer: its flexibility, extensibility, and inclusivity.
My passion these days is for Service Component Architecture (SCA) and I have started this blog to give my perspective on SCA and explain why it is an important step forward for building distributed applications in a service-oriented style. The views I'll express here are my personal opinions and don't necessarily represent IBM's positions.
Others (Dave Chappell here, Mike Rowley here, Sanjay Patil here, and Steve Kinder here) have expressed their views on whether SCA is a new programming model or not. For me the main value of SCA is not the programming model "in the small" (whether new or not new), but rather that SCA provides a common framework for bringing together assets from a wide range of technologies to create a solution that delivers business value. This isn't a new concept (remember CORBA?), but SCA puts a different spin on it with a framework that's designed for extensibility and isn't prescriptive about using any particular underlying technology. SCA strikes the delicate balance between defining a consistent set of common high-level SOA concepts and being flexible about how these concepts are rendered into different implementation environments that participate in the SCA ecosystem.
CORBA specified IDL for interface definitions and IIOP for the wire protocol. To come to the CORBA party, you needed to be able to define your interfaces using IDL and speak IIOP on the wire. RMI defined its interfaces using Java and spoke the JRMP protocol on the wire, so RMI-IIOP was created to allow RMI to become part of the CORBA ecosystem. With SCA, this uniformity of interface definitions and wire protocols isn't required. The architectural constructs that SCA defines (services, components, references, bindings, interfaces, implementations, composites, wires, policy intents) are designed to be flexible and extensible so that different SCA implementations can render them in different ways into the lower-level specifics of that implementation.
These renderings could differ significantly for different implementation technologies. The SCA 1.0 specs define renderings for Java, BPEL, Spring and C++ as implementation types, and Web services, JMS and EJB as protocol bindings. This set will grow in the future, but SCA usage doesn't need to be bounded by what the spec supports. There's a PHP implementation of SCA, providing a rendering that makes sense in a lightweight scripting environment. The scripting theme also surfaces in Apache Tuscany, which provides SCA renderings for various scripting languages including Ruby, Python, JavaScript and Groovy, as well as the more mainstream support for Java, Spring and C++ that's defined by the SCA specs. In the last week I've seen interest in implementing SCA support for OSGi, and having XSLT transformations as SCA implementations. You can think of SCA as a "lingua franca" for SOA that brings all these technologies together, not at a low level of interface definitions and wire protocols, but at a higher level of assembling, composing and customizing services.
What if some implementations only provide a partial rendering of SCA? Is this OK, or should SCA insist on a strictly defined minimum set of capabilities that everyone needs in order to come to SCA's party? The discussion on this will get going at OASIS soon (the SCA 1.0 specifications don't specify compliance points), so there's no official SCA position on this yet. I understand the value of uniformity and tight specifications, but I'm inclined to think that SCA shouldn't be too rigid and prescriptive about this. Imagine two people talking in a natural language such as English or French, who aren't native speakers and have an imperfect grasp of the language they are using, but can still communicate well enough to get by in their conversation. I was in Italy some years ago trying find a particular village, getting lost on back roads in deepest rural Tuscany, and trying to ask directions from an Italian man who spoke no English. My Italian is pretty bad too (I can manage "una birra, per favore"), and despite best efforts on both sides, it just wasn't going to work. My wife had a brainwave and started talking to the man in French. Success! The Italian man and my English wife both spoke enough French to ask for and receive the directions. Applying this to SCA, if different environments speak different dialects or subsets of SCA, there needs to be enough overlap and mutual understanding to "get by" for some business purpose, but how much shared vocabulary is needed will depend on the particular needs of the services involved. Some environments will provide a full implementation of SCA (fluent native speakers), and others will have just enough vocabulary and grammar to be able to order a beer. More fluency is always better, but let's also remember the greatest values that SCA has to offer: its flexibility, extensibility, and inclusivity.
Subscribe to:
Posts (Atom)
