Chamberlain returning from Munich, waving the Munich Agreement

This so called peace, however, was short-lived, as Hitler, emboldened by his military power and encouraged by the failure of the other European nations to respond in kind, went on to occupy the rest of Czechoslovakia and set the stage for World War II.If there’s a lesson to be learned from this story, it is that extraordinary results require extraordinary effort. I will explain what I mean in the course of this article.

Let’s switch gears for a while, and talk a little bit about career planning as a means to illustrate my point. If you are possessed with even a bit of ambition, you are probably not going to be content doing the same job year after year. As time goes on, you expect to be endowed with greater responsibilities, and improve your standing in society (have a house, a car and 2.5 children – the classic American Dream).

Achieving these unsaid objectives might possibly come from working a 9-5 job for twenty or more years, until finally, you have accomplished your life’s goals.

Indeed, this is the path that many working professionals seek to follow. And this path does produce its rewards. However, at Ishi, we believe in another path. That path is the path of entrepreneurship. Entrepreneurship involves an understanding of risk and reward, and picking those investments that yield the greatest reward. Entrepreneurship also involves managing risk in a way that maximizes your upside, and reduces your downside.

The problem with entrepreneurship is that most people perceive themselves as risk-averse, and think that entrepreneurship means taking risks that are not worth taking because of the downside. However, to reiterate what I have said earlier, entrepreneurship is not about taking risks, but about managing and understanding risk.

At Ishi, the engine of entrepreneurship is learning. You frequently hear it mentioned that Ishi is a learning organization. At Ishi, there is a premium on learning activities, and the value that they add to individual growth and the firm’s business objectives. It’s a winning proposition for all. If I were to summarize a strategy for learning and entrepreneurship at Ishi, it would be as follows:

• Increase your investment into yourself
• The easiest way to increase investment into yourself is through learning
• Increase your investments into others
• The easiest way to increase your investments into others is through mentoring
• Learning does not happen through osmosis, but by active participation
• Career progress is hard work

And finally

• Extraordinary results require extraordinary effort.

There’s a sort of justice in this, isn’t there? After all, why should those who work hard above and beyond what is required from their job description be afforded the rewards that they deserve? At an entrepreneurial firm such as Ishi, the job of building the firm is not the responsibility of a chosen few, but of each person who has chosen to be an entrepreneur. While this paradigm does not suit everybody, the firm does reward entrepreneurship. Career progress at Ishi is very difficult in the absence of entrepreneurial activity.

Sit still, and you run the risk that one day you will be faced with the same words that Neville Chamberlain was presented with when he was forced to step down as Prime Minister: “You have sat too long here for any good you have been doing. Depart, I say, and let us have done with you. In the name of God, go”.

For some background reading, see: http://en.wikipedia.org/wiki/Munich_Agreement

Ishi professes to be a learning organization. This is an idea that is central to our philosophy, and forms a solid foundation on which our core values and governing principles are based. More than once, I have been asked, “What is a learning organization?” In this column, I will address this question, as well as some other related principles in an attempt to elucidate some of the ideas on which Ishi is based.

A learning organization is not an educational institution but a community which promotes learning and the evolution of individuals as well as the whole – in other words, the community itself. It is a platform for collaboration and creativity. It adapts and prevails for its own sake versus that of individual interests.

A living company

The idea of a living company is synonymous with the idea of a learning organization. It has been researched that the average life of a company is twelve years. Yet, the oldest company in the world is more than 700 years old (Stora, a copper mine in Sweden).

Interestingly, there is a huge gap between the maximum possible life of a company and the average life span of one. To understand this gap, we might want to view a company as a life form with its own purpose. A living company is not just a money-making machine for its shareholders, but rather a community whose primary purpose is to survive and perpetuate itself. Living companies improve their chances of survival by learning and adapting to their environment more quickly than companies that exist for purely economic reasons. That said, financial success is definitely a stated goal at Ishi. However, we see it as the by-product of sound decision making and the successful execution of our strategy rather than an objective in itself. We see the practice and cultivation of a learning organization as ways to manifest our philosophy and enable our corporate strategy.

There is also value in adjusting our perspective of what a company is. Seeing it as simply a machine implies that it is controlled externally, and that it is fixed and static in its purpose and the nature of its growth. Alternatively, seeing a company as a living organism implies that it creates its own processes — just as human body manufactures its own cells — so that it may subsequently evolve naturally.

Group intelligence, and its ramifications for Ishi

This idea is linked to another interesting idea — that of Group Intelligence. This idea suggests that when a group of people interact in a cohesive fashion to achieve a set of common goals, a meta-intelligence forms, which is beyond the individual intellectual contributions to the group. This intelligence is that of the group, not an aggregation of the individual intellects. This may seem far fetched, but to understand this in a within a real framework, let us consider a colony of ants.

We know ant colonies as collections of many very-low-in-the-food-chain organisms that exhibit effective intelligence as a cooperative group. ‘Hive intelligence’ is another phrase used to describe similar seemingly intelligent behavior from groups of bees. The other day, I saw a documentary in which an ant colony was relocating overnight from one nest to another. Similarly, bees have evolved a complex structure of communication, cooperation and specialization by which the community as a whole survives from one generation to the next. These rather intriguing phenomena are very real and with deeper investigation, we find that the keys to this kind of “group intelligence” are very advanced communication (signaling in case of ants, a special dance in the case of bees) systems perfected over a long period of time.

When such collaboration and communication develops in an organization, extraordinary results can be achieved. Such an organization learns as much from failure as from success. It rejects the adage “if it ain’t broken, don’t fix it” and continues to investigate new methods of process improvement. A learning organization creates channels to move knowledge seamlessly. Learning organizations also look outside their own boundaries for knowledge. These practices result in an organization that is decentralized, encourages open communication and encourages individuals to work in teams.

Ishi is in its formative years — just entering its tenth year compared with the 700 years of Stora. This is the time we can lay the foundation of an organization that will outlive us many times. For us to develop this platform of knowledge and collaboration, we are instilling a culture of learning and excellence. This brings us a sense of achievement, belonging and security. I believe such a goal is worth pursuing for the reasons we’ve just discussed.

For related reading, see: “Where is your Group Intelligence?” by Rick Dove[http://www.parshift.com/Essays/essay048.htm]

Oriented towards objects

Introductory OO programming classes repeat the fact that object oriented programming arose out of a desire to accurately represent the world around us. It was also based on the understanding that software systems were essentially based on the ability to model the properties, functionality and interactions of real-world objects. We all absorbed this information, and then promptly forgot it once our teachers started talking to us about such esoteric ideas as encapsulation and polymorphism. How many of us took a step back to ask the following question, “If OO is based on the real world, and we’re learning about encapsulation and polymorphism, then shouldn’t these ideas exist in the real world?”

Design patterns and the real world

A similar question arises with respect to design patterns. I frequently emphasize the fact that design patterns are solutions to problems in context. It is these last two words that many software ‘designers’ often forget. Just because a software system has been put together using design patterns does not mean that it possesses good design.
Let’s take a walk into the real world to explore this idea a bit. Assume that I am building an office building, and I need to create a way for my employees to enter the building. Given this problem, a novice architect might suggest that we install a door (Let’s call this the Door (with a capital ‘D’) design pattern. However, when I add context to my problem, other solutions surface. I realize that I actually need two separate ways to allow employees to enter:

1. At the entrance to the building, I need a door, but since I am planning to have security cameras installed, I want to ensure that people enter one at a time. Additionally, I want to control traffic flow in and out of the lobby area. Finally, because the building is insulated in summer and winter, I want to ensure that the outside environment does not interfere with the climate-controlled inside
2. Once employees are inside, I am still interested in controlling the flow of traffic, but I want to install an access point, so that IDs can be checked, and employees admitted to the building once their credentials have been verified.

Upon careful thought, I realize that I can use the following design patterns from the real world to solve these problems. At an abstract level, they are extensions of the Door design pattern. These design patterns are RevolvingDoor and Turnstile, respectively. Look around, and you will see another useful design pattern – SlidingDoor (subway cars use them). As a building architect, I would seek to accumulate an understanding of as many of these patterns as I can. However, I would also carry around with me the understanding that context is more important than the pattern itself. Think of how ridiculous it would be to install a RevolvingDoor where a SlidingDoor was called for. Now ask yourself if you’ve seen software design patterns used in contexts for which they were ill suited. I suspect that each one of us can think of at least one.

The real world and components

A well-designed component can be one of the most beautiful things in the real world. Frequently, the best components are so well designed that we do not even notice their presence. Components help drive the economy. The success of technology is based on something called ‘network externalities’ – a topic that I will explore in a future article. Components in the real world also follow design patterns. Think about a cassette tape – it has a published interface that it uses to communicate with its container (the tape player). The existence of a container-component interface allows multiple vendors to provide tape players as well as the tapes themselves. So you can see the why having different component and container vendors is a useful idea. This is not an idea that exists solely in the world of software.

What does all of this have to do with the New York City Subway?

I decided to write this article because I use the subway every day. The subway system is an example of the real world system (and in my opinion, a well designed system). Since we are in the business of developing software systems, there must be lessons that we can learn. Here, I present some of the ways in which observations of the subway have helped me refine some of my ideas about system design.

• Keep things simple If you’ve ever attempted to navigate the subway on your own, you will have noticed that you are presented with a bewildering array of choices – uptown, downtown, local, express, letters, numbers, etc. However, the subway map is a model of simplicity. After a while, it becomes almost automatic to figure out mentally how to get from one place to another using the subway. It helps if you realize that the subways in Manhattan generally follow the Avenues, and that the express stops (where you can transfer to the local lines) are located on the designated two-way streets. At its heart, the subway system is designed around the idea of making things as simple as possible, and no simpler. The result is a system that uses its resources in an optimized fashion, and keeps its customers happy.

• Provide feedback and information The subway system recently began replacing the classic ‘Redbird’ cars with modern cars that display the time of day as well as the next scheduled stop. As a result, passengers no longer have to decrypt what can best be described as the garbled static of announcements over the PA system. Another interesting feature is a route map that plots all the stations on that particular route (see the picture below), and tells you which direction the train is moving. However, I discovered that this is actually bad design. It is a perfect example of ‘tight coupling’. Essentially, a subway car is a component. So it should be possible to take a subway car that runs on the ‘2’ line, for example, and plug it into the ‘5’ line. But as soon as you do this, the nice helpful route map is no longer valid. To their credit, the designers did include a portion of the map that lights up, stating, “This route is not valid for this trip”.

• Keep your customers satisfied This should be the objective of anyone who aspires to be a designer. Good design is not that which can be appreciated by your peers, but rather by those who use it on a daily basis. New York is known to be a city that’s short on forgiveness. If something doesn’t work, you’ll be sure to hear about it. In fact, a group known as the Straphangers maintains a site (http://www.straphangers.org/) that tracks the performance and reliability of the subway system. Imagine a scenario where a system that you designed was laid bare for the world to see. How frequently do you think of your users when you design systems?

There are other ideas that I could hint at, but leave up to you to explore. If you can manage it, riding the subways for work or for pleasure is highly recommended. See if you can recognize examples of interoperability between systems (for example, being able to use the subway’s Metrocard to pay for your PATH fare), the use of standards (why is the track a certain gauge?), other examples of container-component contracts, and of course design patterns. At some point, it would be useful to keep a notebook to see if the subway is a resource for design ideas, including design idioms and anti-patterns. Happy riding!

I wanted to write this article to describe my attempts to create an “interesting” piece of technology using available frameworks. It all started when I recently decided to get myself an mp3 player. No run of the mill iPod for me. I had some very specific requirements. So, I created a features-benefits matrix to help me make a decision. Here it is:

Sound like a tall order? Well, maybe just a year or so ago this would have been as fanciful as sighting the Loch Ness monster on a UFO. However, I found that I had quite a few options to choose from. I reviewed a number of mp3 players from Samsung, Sony, Apple, Creative and iRiver, and then finally settled on the Cowon iAudio U2 player, which had not only a great set of features, but fantastic reviews online as well.

The Earl of Salisbury craveth supply…

Now that I had selected an mp3 player, I had to figure out what kind of content I wanted on it. While music was an obvious choice, there were also other sources of content that were available. I found http://www.americanrhetoric.com/ which featured numerous speeches in mp3 format that were interesting and sometimes amusing (cf: Nixon’s “Checkers” speech). Another site was the UBUWeb “365 days” project [http://www.ubu.com/outsiders/365/] that presented a collection of quirky and rare recordings. Finally, I discovered Podcasting.
Podcasting is a way to have mp3 content automatically downloaded to your computer using RSS. Podcasting clients such as iPodder can even sync this content with your mp3 device. (Note: this is a short introduction. More information can be found online, or in the Resources section).

Podcasting essentially consists of two steps:
1. A publish step, in which the creator (or publisher) of the content makes it available on a server.
2. A subscribe step, in which a subscriber uses a podcasting client to download the published material.

An overview of this process is shown in the diagram below:

Figure 1: Podcasting Overview

…which but to-day by feeding is allay’d

Podcasting provides mp3 fans with a whole new way of accessing content. Content providers such as bloggers, Internet radio stations and online news providers can create automatic feeds of their content for consumption by subscribers. The advantage of this format is that content is updated automatically by the client and can be downloaded to the mp3 device according to a specified schedule.

Discovering podcasting added a new dimension to my thinking about mp3 and its applications. I began to consider ways in which podcasting could be used to deliver various types of content to users. One of the ideas that occurred to me was to create a feed of incoming email in mp3 format. This would provide a way for you to take your email with you on your mp3 device and listen to it whenever you wanted. I started to think about the technology that would be required to make this idea work. Specifically, the following problems would need to be solved (the second column lists the technologies I identified to solve each problem):

Due to space limitations, I will not cover these technologies in depth. However, the Resources section points to online locations for more information.

Pretty too! What say you, James Soundpost?

Although each of the technologies listed above is important in addressing a piece of the puzzle, it is James that lies at the center of the processing logic. James provides pluggable components called mailets that are very similar to servlets in their architecture. In that famliar paradigm, mailets implement init(), destroy() and service() methods, and are subclassed from a base class called GenericMailet.
The service() method takes a parameter of type Mail that allows you to perform processing actions on a Mail item. James can be configured to load a set of mailets on startup. The James installation also comes with a number of mailets that allow an administrator to configure actions such as redirecting undeliverable mail, or adding a footer to an email message.
In order to generate an mp3 from an email message, we can write a mailet that will intercept each email received at the server, extract the text from it, and then use the FreeTTS (text-to-speech) libraries to synthesize the associated speech. This allows James to create sound posts (to borrow from Shakespeare) of email messages. The utility libraries packaged with FreePod contain the logic required to invoke the Lame mp3 encoder that is needed to actually generate the mp3 files. These mp3 files can then be stored on the server for use by the feed generator. Look at Listing 1 for the code for the service() method of such a mailet.

An overview of the approach (with the key API method calls) is shown below:

Figure 2: Inside the code

I know this man well: he hath been since an ape-bearer; then a process-server

The final piece of the puzzle is to have a process serve the rss. For this, I visualized a servlet that would accept any requests for files ending in .rss. The servlet would incorporate any security requirements (for example, authenticating against LDAP tp gain access to the user’s mailbox) and then scan the appropriate spool directory for mp3 files and generate the podcast rss on the fly. Again FeedPod’s libraries can be used to access any functionality that has already been written.
iPodder could be configured to retrieve the feed from a pre-specified URL. Each user on the system could have a unique URL, or access the same URL after passing authentication parameters. When iPodder sends the request to the server, the servlet will process the request and return the content.

Give not this rotten orange to your friend

There are still additional issues to be resolved, namely:

• The mailet code as written may not be thread-safe owing to the dependencies on other libraries. This needs to be tested and fixed if necessary (for example, James may process a second email while the first email is still being written to file as mp3).
• Need to understand James’ classloading architecture so that the dependencies can be located in the correct libraries. Currently, external libraries can be placed in james/lib, james/bin/lib or james/apps/james/SAR-INF/lib. Not sure how (or in what order) James loads classes from each of these locations. Also, James is an Avalon application, which means that Avalon acts as the container. This has some implications here as well.
• James has a mailet passthrough option that allows multiple mailets to handle the same email. This flag may need to be set.
• Would like to remove dependencies on FeedPod and code directly against the underlying libraries
• Need to create proper procedures to access the RSS feeds in a secure manner (so that each user accesses his or her own podcast)
• Solve any integration issues between James and Tomcat (should the mp3 files be written to a web location, or should the RSS generator read from a mail spool directory?)
• Handle multiple content types (ex: text/plain, text/html, etc.). Can probably use java.net.ContentHandler for this. Feedpod also has a Html2Text class that may be useful here.
• The mp3 folder needs to be refreshed after a certain period (daily? weekly?) or the podcast needs to pick up only the last n files to avoid overwhelming clients and servers.
• Need to invent a naming scheme for the generated mp3 files so that they are unique. Right now, it’s coded to use:
  sender@host.com_subject_date as the format.
• FreeTTS can be improved with better voices and better voice modulation through some customization (ex: MBROLA). This would result in the generation of better sounding MP3’s.
• etc.

If you are interested in working on this project, or in examining the source code in further detail, please let me know via email.

Great floods have flown from simple sources

Pease use the following for reference while exploring the technologies behind the solution discussed in this article:

• Apache James mail server: http://james.apache.org/
• FreeTTS text-to-speech engine: http://freetts.sourceforge.net/docs/index.php
• Tritonus JSAPI implementation: http://tritonus.org/
• jid3 – A java ID3 implementation: http://jid3.blinkenlights.org/
• The LAME project: http://lame.sourceforge.net/; http://jthz.com/~lame/
• FeedPod: https://feedpod.dev.java.net/
• iPodder: http://ipodder.sourceforge.net/index.php. This is also the starting point for learning about podcasting.
• Podifier: http://www.podifier.com/

Also see

• A couple of good articles on James:
  o http://www-128.ibm.com/developerworks/java/library/j-james1.html
  o http://www-128.ibm.com/developerworks/java/library/j-james2.html
• Java Sound Resources: http://www.jsresources.org/faq_general.html
• An introduction to using FreeTTS in your applications – sound-enabling your Ant build:
  http://javaswamy.blogspot.com/2004/10/adding-sound-to-boring-build.html

Listing 1

public void service(Mail incoming) {
MailImpl email = (MailImpl) incoming;
try {
log(”in mp3 Mailet’s service method”); // Example to show how to log status messages

String outputFolder = “C:\\MP3″; // hard-coded for now; but can use input parameters
File temp = new File(outputFolder);
temp.mkdirs(); // create the directory if it doesn’t exist

// Extract the message portion of the email
MimeMessage emailMessage = email.getMessage();

// Extract identifying information
String fromAddress =
((InternetAddress)emailMessage.getFrom()[0]).getAddress();

// Generate the filename for the audio file
String basicFileName = (new StringBuilder()
.append(outputFolder)
.append(File.separator)
.append(fromAddress)
.append(”_”)
.append(emailMessage.getSubject())
.append(”_”)
.append(DateFormat.getDateInstance().format(emailMessage.getSentDate())).toString());

String mp3FileName = (new StringBuilder()
.append(basicFileName)
.append(”.mp3″)).toString();

String wavFileName = (new StringBuilder()
.append(basicFileName)
.append(”.wav”)).toString();

// Compose the IDv3 tag for the mp3 file
String title = emailMessage.getSubject();
if (title == null)
title = “No Title Available”;

String author = ((MailAddress) email.getSender()).getUser().toString();
if (author == null) {
author = “Ishi Mail2MP3″;
}
String year = (new StringBuilder()).append(””).append(
(new GregorianCalendar()).get(1)).toString();

String comment = “Ishi Mail2MP3″;
String album = “Email’s Greatest Hits”;

// Get the message body
String emailString = emailMessage.getContent().toString();
if (emailString == null) {
emailString = “There was no content in this email from ”
+ email.getSender().toString();
}

File mp3File = new File(mp3FileName);

try {
// 1. Create a wav file using the TTS engine
speakToFile(emailString, wavFileName);

// 2. Encode the wav file into MP3
MP3Encoder.writeFile(wavFileName);

// 3. Add the IDv3 information
MP3Encoder.writeID3(new File(mp3FileName), title, author, album, comment, year);

} catch (Exception e) {
e.printStackTrace();

}
} catch (Exception e) {
e.printStackTrace();
}
}

Remember Java? Yes that’s the language most of us are programming in, these days. Remember exceptions? Of course you do. They are your responsibility! The importance of exception handling in your program is right up there with the importance of memory management in C/C++ programs. Lot of times they are syntactically required, but it is just too easy to work your way around it: Bury it! Do you? Hopefully not. Because that would be a crime, just like accessing an un-initialized pointer in a C program.

Without spending more original thoughts/sentences about programming philosophy here (that would be text for another article!), let me humbly suggest productive ways of handling exceptions in your programs. Now, I am not an authority on exception handling, or even programming. These are techniques I use and that I have learnt over a period of time, practicing exception handling and reading articles. By no means is this supposed to be a comprehensive coverage on the topic of exceptions. Do yourself a favor, give the last section “References and Suggested Readings” a second look!

Exceptional Design!

Exception Handling deserves thought as early as design time. Specifically, when identifying business objects in the system, one must always question if there is a possibility of a business object being unable to perform its function. Furthermore, one must also ask questions about the destiny of the exception raised under such circumstances. How must other business objects handle an instance of such an exception? Whether such business failures would lead to a “user-friendly” error message to the user or is the system capable of solving the problem – by fixing it or resorting to an alternate process? A design with such questions (and answers) in mind lays the foundations of a fault-tolerant, possibly even a “self-healing” system.

Classification by Syntax: Checked Exceptions and Unchecked Exceptions

Typically all exceptions you throw must be declared in your method signature. Exception to this rule is the RuntimeException. You can throw one when you like, without explicitly declaring that your method throws it. Also, any method you call potentially can throw this exception; the java compiler does not require you to check for this exception. Hence “Unchecked Exceptions”. Usually these exceptions are used in system errors: division by zero, deferencing a null pointer, bounds checking failure. Mostly you need not worry about them. By intent, such exceptions are not meant to be handled by the client. In general, if you encounter these when your code executes, it is probably a good idea to refactor it.

Classification by Meaning: Technical Exceptions and Business Exceptions

Technical exceptions arise out of technical failures. There’s a whole slew of them… “file not found”, “class not found”, “socket can not connect”, “database transaction failed”. Just to name a few. Business exceptions arise out of failures in business actions. Consider these business exceptions – “Configuration missing”, “Plug-in not found”, “Remote service unavailable” and “System busy, Please try your request later again”. One thing is clear, users do not care about technical exceptions. If you pay attention, you will notice a direct mapping between the technical exceptions and the business exceptions mentioned above. Subsequently, another thing becomes clear – all technical exceptions must translate to business exceptions before they reach the user. Business exceptions may also arise out of logical failures: “you do not have enough money in your account to buy your requested item: an Airbus A-340”.

Throwing an exception

So when you run into an error condition, what exception should you throw? Remember, the purpose of instantiating an exception object is not only to reflect a real-life physical or logical error condition, but to also provide as much detail as possible about this error condition. An exception class is just like any other class, except that one of its ancestors is the Throwable class. Several things become information to the client when it will catch this exception: The exception class name, the exception class package, the stack trace stored in it, any public properties you provide as extra information. Try to use pre-existing exception classes, if you can fully express the error condition with that class, otherwise you need to create a new exception class that addresses the need for you to be able to fully express the error condition. Consider a descriptive name. Another particularly useful guideline in choice of which exception to throw is: You should favor throwing exceptions which belong to the package that propagates them. This avoids undesirable package dependencies.

Catches win matches; judging the exception

Fielders in the game of cricket never have to make a decision about whether to catch, and what to do after catching. You, as a Java programmer, have an advantage though, you tell the compiler about your intent to catch, and it is guaranteed! So what must you do when you catch an exception? You judge its meaning. The first point of judgment is based on the exception class itself. You may choose to ignore it (you do not try to catch it, so compiler makes you declare that you throw it). You may choose to catch, wrap and propagate (you create a new exception – one which reflects your perspective of the problem, but as details, contains the original exception object) or you could handle it (for ex. File not found in /home/foo/etc, try with /etc next). Most well designed exception classes provide a good description of what happened using exception properties. This information, when applied to your well defined business logic, becomes a basis of what needs to be done when you want to catch, wrap & propagate or handle the exception.

Encapsulation

One important observation to make when you ignore an exception/propagate it – by declaring that you throw it, is that the client becomes aware/ must be aware of this particular exception class. Done carelessly, this can lead to breaking encapsulation in your design. For instance, you write a data access layer, which can fetch data from a database. Needless to say, if the client needs to be aware of the exceptions you encounter (ex. the ubiquitous SQLException), then you have failed to encapsulate the business function of your object. Perhaps a new exception class needs to be written: DataAccessExeception or something akin to that.

On a closing note for this article, I once again invite you to read the articles mentioned in “References and Suggested Readings” section below.

References and Suggested Readings

• Best Practices for Exception Handling
  http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html
• Best Practices in EJB Exception Handling
  http://www-106.ibm.com/developerworks/java/library/j-ejbexcept.html
• Beware the dangers of generic exceptions
  http://www.javaworld.com/javaworld/jw-10-2003/jw-1003-generics.html
• Performance improvement techniques in Exceptions
  http://www.precisejava.com/javaperf/j2se/Exceptions.htm

In modern times, the approach of looking at complex problems by focusing on one particular aspect of the problem has become valued as a thinking tool. Sometimes, a problem may be too difficult to understand or its scope may be too large to grasp unless one looks at a little piece at a time. In this article, I look at some of the ways in which we can use this technique to become better problem solvers.

One of the problems I face when working on new projects is that I walk in the door and am confronted with a mountain of code to understand and work with. When I was less experienced, I used to apply a brute force method — walk through the code with the help of a debugger, and test out all the functionality of the application until I understood exactly what each module, class and method did. However, this approach requires time, and that is not always a luxury one has. One is usually expected to jump right in and be productive.

What light through yonder window shines?

One of the tools that I’ve found to be helpful in assisting me with code comprehension is Juliet (see the Resources section for more information). Juliet is not merely a code browser. Given a codebase, Juliet parses the code to discover relationships that may not immediately be obvious. For example, I’ve sometimes provided Juliet with supplementary code, such as the JDK, or weblogic.jar in order to discover how application code relates to the deployment platform.

Figure 2: Juliet in action

When Juliet analyzes the code, it does so by focusing on a particular perspective of the code that I am interested in. Juliet is even considerate enough to let me hide comments and collapse methods down to their signatures. As you can tell, this is a huge improvement over the brute force method described earlier. For example, if I want to know exactly what code fragment A does, and how it relates to code fragment B, Juliet helps me figure it out. All tokens (variables, methods, classes, etc.) are hyperlinked so that I can instantly browse to the artifact of choice. Figure 2 is a screenshot of Juliet. (Who says you can’t design great user interfaces using AWT?) This perspective-based approach lets me focus on what’s important and neglect other code that may be unnecessary for my analysis.

Everything under the Sun is in tune

The idea that a codebase can be examined using a set of “perspectives” is familiar to anyone who has used Eclipse for development. The designers of Eclipse understand that as a developer, I don’t want to see my entire codebase all at once. I might perform many different actions with the same code. For example, I might want to interact with the codebase using a ‘work-with-scm-codebase’ mentality. If so, I can easily switch Eclipse to CVS perspective, and perform all my actions that are relevant to the SCM tool. Or, I might want to set up datasources for my J2EE application and run some test queries against a database. To do this, I can switch to a Database view. This focuses my efforts. I don’t have to sort through different menus trying to find the functionality I want (Is it under Tools? Edit?). I know that when I switch perspectives, I am working with a particular mindset, and all the actions I perform on the code will be relevant to that mindset.

One word, my boy: aspects!

This approach has been applied to software development in the form of aspect-oriented programming (AOP). AOP is a concept that is complementary to OOP. AOP gives us a way to deal with concerns (AOP calls these crosscutting concerns) that affect multiple objects all at the same time. Common examples include transactions, security and logging. You need to handle transactions in multiple objects and in multiple methods across your code. The same goes for logging. However, transactions and logging have nothing to do with the core business logic that you are using objects (and OOP) for. They are complementary concerns. AOP lets you deal with these concerns by viewing them as ‘aspects’ of your code. Doing this helps you focus on problems that span objects without getting sidetracked by the object-orientedness of your code.
If aspects are such a useful way to look at code, does it make sense to apply this way of thinking to everyday problems? In other words, can we train ourselves to think in aspects, and therefore become more effective thinkers? This would allow us to migrate this idea out of the realm of programming into the real world, allowing us to address problems that don’t traditionally require code to solve.

Six hats to rule them all

As it turns out, this is not such a far-fetched idea. In his book, Six Thinking Hats, Edward de Bono argues that we can train ourselves to think exactly like this. He contends that doing so can make us better thinkers and allow us to solve problems faster. This approach has been tested in real world situations, and in many instances has made it easier for groups of people to make decisions. It has also facilitated better communication among group members. Mr. de Bono encourages readers of his book to visualize different modes of thinking as hats of different colors. Then, when confronted with a problem, the thinker can mentally put on a relevant hat and invoke the method of thinking associated with that hat. This practice helps avoid the chaos that is caused when one tries to look at a problem in many different ways all at once.

As we’ve seen, the concept of crosscutting concerns can be adopted as a problem-solving tool in many different ways. At a fundamental level, it encourages a way of thinking about the world in terms of a particular perspective, so that common aspects of complex problems can be addressed. As developers, aspect-oriented programming can enhance our thinking and give us another way to model systems (complementing OOP and design patterns). With this in mind, I would encourage you to seek out and understand frameworks such as AspectJ, AspectWerkz and Spring-AOP that provide support for AOP. I also encourage you to read Six Thinking Hats to understand how you can apply aspect-oriented thinking to your own life.

Resources

• Juliet can be downloaded from http://www.infotectonica.com/
• Learn more about perspectives in the Eclipse platform at:
  http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html
• Learn about AspectJ at: http://www.eclipse.org/aspectj/
• AspectWerkz can be found at: http://aspectwerkz.codehaus.org/
• Spring AOP is discussed in the Spring documentation at:http://www.springframework.org/docs/reference/aop.html
• I want my AOP! is a series of JavaWorld articles on AOP using AspectJ:
• www.javaworld.com/javaworld/ jw-01-2002/jw-0118-aspect.html
• O’Reilly’s OnJava site has an introduction to Spring-AOP:http://www.onjava.com/pub/a/onjava/2004/07/14/springaop.html
• You can read the first chapter of Six Thinking Hats here:
  http://www.twbookmark.com/books/62/0316177911/chapter_excerpt9537.html

Entertainment
Some amusement might be found by deciphering the cultural references alluded to in the section headings of this article.

Wikipedia has an excellent entry for Blog, which I wholeheartedly recommend.

Blog – the word.

The word blog is simply the words “web log” processed through a lazy person word compressor algorithm. The word blogging is simply the same treatment applied to “web logging”.

Blog – the meaning.

To put it straight without much elaboration, a blog is a frequent (which depends from blogger to blogger) record/commentary/small essay/article/blurb about content on the web, personal experience, observations or public events possibly with an option of readers feedback, which may or may not be used.

The onset.

The roots of blogging lie in public communication and a need for self expression. Historically, public writing has been somewhat regulated/controlled by the authority of the media in context. In the past, the only communication devices available to a person have been telephone, ham radios and the Internet. Although the user is almost in full control of these devices and the communications made using them, telephone sadly lack the ability to broadcast. That leaves the ham radios and Internet as practical options to provide the user with a virtual dais to stand on and opine away. The vehicle of choice to deliver, however, is the Internet. It is used by the corporate world, the hacker world, as well as the philosophists, and families; the list goes on.
In the Internet world, the predecessor to blogs were perhaps journals. Another prominent influence was the popularity of message boards: Choose a topic, start one, host it and watch the readers post their content (Rules, guidelines and limitations vary). Another definite predecessor of blogs is the “homepage” – a nineties phenomenon that sprouted up everywhere. One reason why blogs have succeeded more than either of these is perhaps because the dynamic web has evolved to the point where the content has finally gained more importance than the delivery mechanism. Public content posters have grown used to these technologies, the technology of public posting is not the issue, the issue is what they want to post. Blogging is made easy by low-cost, easy-to-use technology that lets anyone — not just propellor-heads — be a publisher.

Welcome to Blogopolis

In the online city of Blogopolis, you are what you blog, what you blog about; it’s a cathartic experience (the word “blog” even sounds like the meaning of cathartic!). As a citizen of Blogopolis – an online persona – free to express oneself solely through the written word…and perhaps pictures. In Blogopolis, you can find a blog on just about any subject. The content varies from the blog that Martin Fowler writes about object oriented development and design patterns to blogs written by people about the progress they make in the latest diet they are on. You can read blogs of CSS gurus as well as blogs containing the ramblings of an average person living out the ordinary life. People write blogs about the work they did in the office today, they write blogs to express their political agenda, or chronicle the events of their presidential campaign, and when they loose, they may write blogs encouraging readers not to let certain people back in the White House. They are writing a blow-by-blow account of the Iraq war and about their visit to Falluja in Iraq. People are writing blogs because they got shut out as journalists and this is their chosen media of publishing now. And need I mention, people are writing blogs about other blogs! Check out the links section at the end of the article to see some interesting sampling of blogs.

Blog – Why some people don’t.

I’ll make some guesses here, but I shall elaborate in the next article.
You’re really lazy. You love privacy. Your life is not worth talking about. Legal restrictions. Fear of legal issues.

Blogminator.

No, this paragraph is not about a blog about Arnold Schwarzenegger, this in fact just means that this paragraph is the terminator of this blog article.

Oh I almost forgot… The Links section.

• The Martin Fowler Blog - http://martinfowler.com/bliki/
• The Diet Blogs - http://www.google.com/search?q=diet+blog
• The CSS Blogs - http://www.google.com/search?q=CSS+blog
• Daily Life Blogs - http://www.google.com/search?q=daily+life+blog
• The Political Blogs - http://www.google.com/search?q=presidential+campaign+blog
• More Blogs - http://www.google.com/search?q=blogs

When BEA released WebLogic Platform 8.1, they introduced an enhanced version of Workshop 8.1. Workshop 8.1 was not just another IDE but an IDE plus an application development framework all built into one solution.

Even though BEA might deny allegations that Workshop is based on Microsoft’s Visual development tools, the fact remains that the primary Architect on this project was Adam Bosworth, who formerly worked for Microsoft.

The primary intention BEA had in introducing an application development framework was to make it easier for developers to develop complex web applications, manipulate XML, use web services and integrate with 3rd party resources or other applications.

In May 2004, BEA announced that it was going to extract the application development framework from Workshop and make it an Open Source initiative. It also announced that this initiative would be an Apache project. It would be called the Beehive project.

Overview

The Beehive project consists of the following components:
1. Page Flows
2. Controls
3. Java Web Services
4. XML Beans (this is not considered part of the Beehive project but will be packaged in the first release)

The figure below shows how all these components all fit together.

Source: BEA dev2dev website

Architecture

The Beehive implementation is dependant on JDK 1.5 (or also called J2SE 5.0). JDK 1.5 introduces annotations to the Java language. Annotations can be thought of as meta-data on Java classes. The advantages of such an approach (i.e. annotations) are that any existing Java class/component can be transformed to expose functionality based on the requirements.

Beehive heavily relies on annotations. This is different from the implementation that ships with Workshop 8.1 as no annotations were used. Also Workshop 8.1 is JDK 1.4 compliant. Beehive also exposes all its interfaces as simple Java Beans (POJOs).

Details

In this section we will cover details of every component that is part of the Beehive initiative.

1. XML Beans
   XML beans are a Java representation of XML documents. Most of developers find the need to manipulate XML in their applications. Technologies like JAXB help developers bind XML to Java objects. But how XML Beans differ is that they treat Java Beans and XML as one entity. So when a developer modifies the Java Object using accessor methods like setters, the underlying XML document is modified. The advantages of such an approach is:
   • Ease of use
   • Developers focusing on solving the business problems rather than technological nuances
2. Controls
   Controls are a mechanism of exposing interfaces to either 3rd party applications/projects, components or simple Java APIs. The advantage of such an approach is the ability for developers to use controls to integrate with existing functionality or APIs rather than re-writing all the logic again. 

   BEA has tons of pre-written controls that ship with Workshop 8.1. Examples of common controls are:
   • Documentum Controls
   • JDBC Controls
   • Entity Bean Controls
   • JMS Controls
   • WebSphere MQ Controls

   Another benefit is developers can now share components by exposing their code as a control. Controls have properties (implemented as member variables) and methods (providing the business functionality).

   Example: With a JDBC control, a developer would not need to worry about opening and cleaning up of connections but would just be required to provide the SQL and get the result.

3. Java Web Services
   Java Web Services is a mechanism to expose any Java Component (or a simple class) as a Web Service. Again this is done through the use of annotations. 

   This enables developers to concentrate on the business aspect of the solution rather than focusing on how web services work, how marshalling/un-marshalling is handled etc.

   Another advantage is the ability for application developers to expose existing functionality as web services.

4. Page Flows
   Page Flows is an easy-to-use web development framework. It is built on top of the Struts Programming Model. 

   Beehive uses annotations on Java Beans to represent the flow of the application. The use of annotations replaces the need for Struts developers to define the struts-config.xml An IDE like Workshop adds benefits like visually being able to create a flow for a web application.

Example 1
public class UserRegistrationController
extends PageFlowController
{

/**
* @jpf:action
* @jpf:forward name=”getAddress”
*              path=”address.jsp”
*/
public Forward name_next( … )
{
…

return new Forward(”getAddress”);
}

…
}

Source: BEA website

Note the highlighted code. Annotations are built into the Java class to represent what page needs to be called.

Page Flows are a grouping of JSPs and actions to provide functionality to the end-users. A web application generally consists of multiple modules. Each web module in Beehive can be implemented as a Page Flow. There exists a master Page Flow that links all the modules together. Page Flows correspond to the concept of modules in Struts.

Conclusion

Beehive is still nascent. But the concept is sound. Developers have always had problems with the technical implementation rather than focusing on delivering the solution. Beehive makes it easier for developers to use technologies like Struts, XML, JMS and Web Services. Developers can now focus on the “what” rather than the “how”.

References

http://incubator.apache.org/projects/beehive.html/
http://www.controlhaus.org/
http://www.oracle.com/technetwork/middleware/beehive/platform-098968.html
http://www.eclipse.org/proposals/eclipse-pollinate/
http://java.sun.com/j2se/1.5.0/index.jsp