code prole


coding for the proletariat since 1977


I’ve been aware of Aspect Oriented Programming (AOP) for some time now, but I haven’t ever really looked into it. My current project team is angling for an architectural decision that would allow us to use the Spring framework for transaction management. In reading about Spring and experimenting with some sample code I’ve discovered that it is really an implementation of AOP.

Simply put, AOP seeks to address common aspects of objects across the layers of your application. Object Oriented Programming (OOP) allows us to model our applications after real world objects, making them easier to design, develop, and implement. However, there are some aspects of the real world that apply to multiple objects. When translated into source code these aspects often end up repeated in multiple objects. And we all know what happens when you start repeating code.

Take logging for example. Any application that has a logging requirement is likely to have calls to a logging service scattered through out the various layers of the application and the numerous objects comprising that layer. Wouldn’t it be better if the objects just focused on the business task at hand, while the logging was handled in a separate framework? That’s what AOP is all about. Every object in the application that requires logging services shares an aspect: the need for logging. Using AOP techniques and tools allows the application objects to be tightly focused on the business requirements, while the cross-cutting aspects are addressed through AOP.

Filed under: Aspect Oriented Programming


Recently I ran across SLOCCount, a set of tools for counting physical source lines of code (SLOC). Installation was easily accomplished on my Mac OS X 10.3.8 system, and now I can count the lines of source code in my own projects, and those I am involved with at work.

Counting lines of source code has always interested me, and at one time I could tell you how much professional code I personally had worked on. Unfortunately over the years I’ve lost track. I do have copies of a lot of the code I’ve worked on so over the weekend I’ll untar the archive directory and see what counts I get.

Filed under: Unix

Project Politics

Perhaps the most annoying of aspects of any IT project is politics. Every company, every agency, every engagement has politics. In the best of cases the political aspect of a project is well managed, understood, and used to the greater advantage of all involved. This case has never existed anywhere in the known world.

The worst case results in shouting, terminations, and bitter enmity that survives long after the reasons for the issue have been forgotten. I personally have participated in more than one of these projects.

In the middle lies the typical project scenario. Political pressure of one sort or another skews the objective or success factors enough to make project life uncomfortable, but ultimately a product is created and everyone moves on to other assignments. Politics, as I am using it here, can be likened to non-functional specifications. Just as every project has requirements that drive out specifications, and by logical progression non-functional specifications; every project has people who bring humanness to a project, and by logical extension, politics.

None of us are educated or prepared to deal with human nature or emotions by design. Any understanding an individual possesses about human nature, emotions, group psychology, et cetera, has been gained through often painful personal experience. And very few of us have spent any serious effort figuring out the ins and outs of our personal emotional landscape. We all react to external stimuli; few of us really understand why. Put four or six or twelve people in a room and ask them to perform as a unified team and you likely get an emotional pressure-cooker, primed to blowup.

Emotions that are unexpressed by individuals, or expressed inappropriately are the ignition source for the political fire. Once burning, these issues become the gas that feeds fire, and the wind that fans it ever higher. Stakeholders and management external to the team are put into the position of reacting to interpersonal issues. The people external to the project have no better tools for dealing with these issues than the team members; so the controls placed on the team become burdensome. They only add to the pressure, they don’t relieve it. Since no one is able to communicate fully and openly, no one is getting their needs met.

Stakeholders aren’t getting the automation desired, team members aren’t getting the professional satisfaction they crave, management is frustrated and stymied by both other groups. In the end political expediency is used as a trump card to force a solution on everyone. Management agrees to outrageous deadlines or success criteria. Team members subvert their personal lives and goals to please management. Stakeholders settle for something not quiet matching what was asked for – all because the modern western corporate landscape chooses to ignore the reality that people are just that — people.

Until we can stop trying to do everything politically and start approaching projects from a humanist stance we will continue to have spectacular failures, bitter memories, and emotionally wounded people. The cycle will repeat itself endless until we, the people in the midst of it, change it.

Filed under: Miscellaneous


Subject matter experts are a critical resource for any development effort. Without knowledgeable technical resources on your team during requirements analysis, analysis, and design it will be impossible to accurately and completely capture the essence of the desired application. All the modeling tools in the world can’t replace one SME.

In a consulting engagement, the SME role has a heightened significance. Resources who are experts in the methodology or tooling can be contracted for the project. But they cannot know the business at sufficient detail to move the project forward. The client must provide unfettered access to one or more SME resources in order to assure success.

My current engagement is frustrating as SME are constantly being pulled off the project to put out fires elsewhere. Repeated attempts to tie delivery date slippage to SME availability has had only limited success. In other words, we are still tasked with meeting our deadline even though we have just lost our SME for at least a quarter of the remaining project duration.

In true geek gallows humor the team has started to refer to itself as the “Kobiashi Maru” after the unsolvable command problem in “The Wrath of Kahn” from the Star Trek movie series.

Filed under: Project Management

Project Set Files and Eclipse Preference FIles

Working in a collabrative development environment presents some challenges. Once you have your source control approach ironed out and working you still have the problem of keeping every one’s IDE in sync in terms of option settings.

Luckily the Eclipse platform, and WebSphere Studio Application Developer (WSAD) which inherits from Eclipse, provides two mechanisms for assiting a team of developers who wish to keep their individual environments in sync with each other. The first is project team sets and the second, eclipse preference files.

Team Project Sets (PSF) Project team sets, or PSF files, allow you to capture the setup and contents of a workspace to allow sharing with other team members. This tool is dependent upon the use of a centralized source control system such as CVS, ClearCase, or Subversion. Since the resources inside a project under version control are kept in the repository, it is possible to share projects with team members by sharing a reference to the repository specific information needed to reconstruct a project in the workspace. This is done using a special type of file export for team project sets.

Once you have the project setup properly in one workspace, you select the project and export it as a Team Project Set. Other team members can then use this PSF file to construct their workspaces.

Eclipse Preference File (EPF) The other area that can cause multiple developers working against shared source difficulties is IDE preferences. For example in WSAD with Rational XDE integration there is a code generation tool that can keep the Java code model in sync with the UML model and vice-versa. If one team member has auto-sync turned on and another team member doesn’t inconsistencies in the model and source will rapidly result. Considerable time will be lost has effort will have to be expended to untangle the two views of the project.

By establishing a set of preferences and exporting them as a EPF file, and sharing that file will all team members it is possible to avoid at least some of the problems resulting from different IDE preference settings.

Filed under: Eclipse

MyEclipse 3.8.4 Beta for 3.1M6

Recently I upgraded from the milestone 5 build of Eclipse 3.1 to milestone 6. Afterwards I reinstalled MyEclipse only to discover I’d lost some functionality. The XML editor no longer seemed to function but I could open Ant build scripts via the Ant editor. Just to add spice, the Ant run option was missing from the Run menu. Very odd indeed.

One of the cool things about MyEclipse is that it is a subscription service as well as the best J2EE plugin suite for Eclipse. Visiting the forums at MyEclipse I was able to find explanations and work around techniques for both situations.

The XML editor problem was solved by removing the “links” folder from my Eclipse installation. The only entry in this folder pointed to the MyEclipse installation elsewhere in my file system. Even though I had re-installed MyEclipse, this linkage wasn’t operating correctly. Removing (or just renaming) the links folder and installed MyEclipse once again resulting in a work XML editor.

The Ant build script problem is really just a case of a missing menu item. The functionality is still included. Using the Option-Shift-X keystroke combination on Mac OS X (Alt-Shift-X on Windows) gives me a popup menu that list several run choices. Selecting “Q” runs the currently selected build.xml file in Ant. Nice.

Like many others I am eagerly awaiting the release later this week of Version 4.0 of MyEclipse which includes UML modeling among other enhancements. With just a couple of months of full-time MyEclipse use under by belt I must say I am very impressed. If the UML functionality is up to their already high standard, I will be very pleased.

Filed under: MyEclipse

Subversion Rocks

In the past I have tried to use CVS for my source control solution. Having used various CLI tools in the past I wasn’t put off by its interface. However I never quite clicked with the CVS way of doing things. In particular I was put off by the difficulty in renaming or moving files once they were under source control.

Subversion, from Tigris, is a breath in fresh air. The biggest departure from CVS is that Subversion tracks files, directories, and the metadata about those objects. And it easily allows renaming and moving files or directories.

The Subclipse plugin for Eclipse rather seamlessly integrates your repository in the IDE. In just a couple of weeks I’ve managed to place all of my websites, and several complex work related project, under source control.

I can highly recommend the Pragmatic Version Control Using Subversion book. And I can highly recommend Subversion itself.

Filed under: Software, Source Control

Use Case Specifications

Once upon a time I read an essay about the difference between writing and word processing. In the end it boiled down to the difficulty maintaining a coherent creative thread while faced with a myriad of formatting options, real-time spelling corrections, and puzzling grammar suggestions. The author of this essay proposed writing out new material on paper with pencil in order to capture the thought without distraction. Only when the content was fully realized did they advocate entering the document into your word processor of choice.

In my current engagement we are tasked with producing use case specifications from user requirements. Naturally we are using a word processor and document template for the artifacts. Most of the team has worked with use cases in the past, and we are all used to a particular format; one that utilizes tables to structure the normal flow of events and any alternate flows that arise. The table format is short, concise, and very functional. However the table format caused problems with our chosen requirements management software, Rational RequisitePro.

ReqisitePro allows you to tag entries in various artifacts as significant in some way. Later as you develop your application design you can trace back to these significant requirements, thus showing you’ve satisfied them in some way. Unfortunately, RequisitePro had an inability to tag text embedded within a table properly. This client decided to tackle the lack of table support by eliminating the tables from use case specifications.

The new table-less format is perhaps cleaner to the eye, but it relies upon bulleted lists to enumerate the pre and post conditions, normal flow, and alternate flows. Each bullet point has to be named since the numbering is inserted automatically and may change with future revisions. Coming up with a creative and descriptive bullet name is proving to be surprisingly difficult.

All of which brings me back to my central point. Separating the creative process from the presentation process is as important as separating the presentation layer of an application from its business services and persistence mechanisms. At least for the use cases I personally am charged with creating, I am going to capture the content in notepad so as to avoid the temptation to format as I go.

Filed under: UML

Eclipse Project Dependencies

Until now my J2EE project development experience has consisted of single project applications. My currently client has a tiered application architecture that splits application interfaces from business services, and business services from persistent services. This is all well and good. The resulting project structure in WebSphere Studio Application Developer (WSAD) or Eclipse consists of three parts: Common to house the framework, a Java project to hold the persistence and business layers, and a web project for the application interface itself.

WSAD allows you to define supplier projects to eliminate the need to replicate code in multiple projects. Nifty. Eclipse (being the underpinnings of WSAD) also allows project dependencies. In the Forte world we called these relationships “supplier plans.” In the J2EE world its known as the project classpath. Get your classpath setup correctly and magic happens. Miss a dependency and misery ensues.

Filed under: Eclipse


I have been developing software in one from of another since the late 1970s. In that time I’ve used mainframe tools, client-server platforms, 4th generation languages, structured programming and object oriented paradigms. I’m a relatively recent convert to the whole Java platform. And I have to say that at first blush it is no way to develop applications.

I spent most of the late 1990s and early part of this decade using a proprietary distributed development platform called Forte. Originally its own company, Forte Software was years ahead of its time. Unfortunately, proprietary platforms, no matter how well concieved or executed are expensive. The fate of Forte was to be purchased by Sun Microsystems. When you have one free, widely accepted development platform (Java) and you buy the only enterprise level distributed application development platform that is your competition. And that platform is costly in terms of licensing (and knowledgeable resources) only one outcome is possible. Forte has been renamed Sun Unified Development Server (UDS) and quietly swept under the carpet to wither away and die.

So I’ve made the leap to J2EE development. Coming from an integrated end-to-end solution it is a rude shock indeed to spend my days sorting out a dozen or more technologies just to get data from the database to the client. Hibernate, Spring, Eclipse, Struts, Tapestry, JAAS, JAX, Edge Servers, WAS, WSAD, MQ Series, and on and on. It is daunting to sort out all the capabilities, functionalities, dependancies and best practices. Still, it’s a living. Or at least a paycheck.

Filed under: J2EE