Beautiful Code [71]
Don't get me wrong. I'm not against Web Services. I'm just not a big fan of making technical decisions based solely on whatever happens to be in style at the moment. This chapter will address some of the reasons for using a Web Services architecture, as well as explore some of the options to consider when integrating systems with the outside world.
In this chapter, I'll walk you through a real-life project that involves exposing a set of services to a business partner, and discuss some design choices that were made along the way. Technologies that were used included Java (J2EE), XML, the Rosettanet E-Business protocol, and a function library used to communicate with a program running on an AS/400 system. I will also cover the use of interfaces and the factory design pattern as I show how I made the system extensible for future distributors who may use different protocols and may need to access different services.
27.1. Project Background
The project I'll be discussing in this chapter began with a call from one of our clients: "We need a set of Web Services to integrate our systems with one of our distributors." The client was a large manufacturer of electrical components. The system they were referring to was MAPICS, a manufacturing system written in RPG and running on their AS/400 machines. Their main distributor was upgrading its own business systems and needed to modify the way it tied into the order management system to check product availability and order status.
Previously, an operator at the distributor simply connected remotely to the manufacturer's AS/400 system and pressed a "hot key" to access the necessary screens (F13 or F14 as I recall). As you'll see in the code later, the new system I developed for them was named hotkey, since that had become part of their common language, much like the way google has become a modern-day verb.
Now that the distributor was implementing a new e-business system, it required an automated way to integrate manufacturer data with its own system. Since this was just a single distributor for this client, albeit the largest, the system also needed to allow for the future addition of other distributors and whatever protocols and requirements they might have. Another factor was the relatively low skill level of the staff that would maintain and extend this software. While they were very good in other areas, Java development (as well as any kind of web development) was still very new to them. So, I knew that whatever I built had to be simple and easy to extend.
Beautiful Debugging > Debugging a Debugger
28. Beautiful Debugging
Andreas Zeller
My name is andreas, and i have been debugging." Welcome to Debuggers Anonymous, where you can tell your debugging story and find relief in the stories of others. So you have spent another night away from home? Good thing you've only been in front of the debugger. So you still cannot tell your manager when that showstopper will be fixed? Let's hope for the best! The fellow in the cubicle next to you brags about searching for a bug for 36 consecutive hours? Now that's impressive!
No, there is nothing glamorous about debugging. It is the ugly duckling of our profession, the admission that we are far from perfect, the one activity that is the least predictable or accountable—and a constant impetus to feelings of remorse and guilt: "If only we had done better right from the start, we wouldn't be stuck in this mess." The defect is the crime; debugging is the punishment.
Let us assume, though, that we have done all we can to prevent errors. Yet, from time to time, we will find ourselves in a situation where we need to debug. And as with all other activities, we need to handle debugging in the most professional, maybe even "beautiful" way.
So, can there be any beauty in debugging? I believe there can. In my own life as a programmer, there have been a number of moments when I encountered true beauty in debugging. These moments