code prole


coding for the proletariat since 1977

Learning Curves

Recently my career has taken a few curves, learning curves to be exact.  After several years of little or no professional programming, I am re-entering the development side of the house.  Lately I’ve been immersed in Java, Eclipse, WebSphere, JDBC, ODBC, Maven, and CVS.

Each of these technologies individually wold make for a decent learning curve, taking them all on at once, in the midst of a major re-engineering effort, has made for some frustrating days.  The organization is in flux, the development standards are changing (we’re switching from CVS to Subversion as I type), new managers and new employees are altering the status quo at every turn.  It is exciting and terrifying all at the same time.


Filed under: Software,

Components Scale

Recently at work we’ve been discussing components and how to classify them. It occurrs to me that what is missing in most definitions of components is the context. The context determines the scale of the component.

A Java class is a component, and a simple application utilizes one or more classes as components in completing it’s function or purpose. A larger application may utilize individual classes or call upon a service that choreographs the efforts of several classes or services. From the viewpoint of the application the objects it calls are components. In this example the individual class may no longer be considered a true component – it’s just a building block.

In any given business there will always be a context through which the application is viewed. Having that context is necessary in order to see the components that make up the application. In the context of a small expense tracking program the component scale is small, individual classes, maybe even methods within those classes. If, however, the application is something as large as MIDAS, then there would be layers of components. At the highest enterprise level, the components would be entire applications. Once you move down to that level the components would be business service orchestrator (I’m hesitant to use the work aggregator due to it’s UML implications). Once you drill down to the business service orchestrator the components become functional services and perhaps technical infrastructure supporting objects.

For me at least, having a taxonomy of components that differentiates between business component and technical component, service and embedded, isn’t really useful. What is useful is being able to scale your viewpoint to see the next layer of services or functions from the viewpoint of the current requestor. If it helps people with poor(er) visualization skills to think of enterprise components utilizing business components, which in turn orchestrate functional or technical components, which are comprised of language components, then so be it. But to my way of thinking a component is any self-contained, reusable function or service exposed through a stable and well defined interface.

Just my $0.02.

Filed under: Concepts, Software

Trac Rockz

Recently, the pre-pre-startup team I am working with decided to start using Trac, from Edgewell Software. It is amazingly simple to use, and provides exactly the level of SCM and Project Management we want – minimal, agile, and unobtrusive.

Within minutes of having our site up we had modified the wiki, added new pages, and started tracking tasks through the ticket system.  With the integration to Subversion we now have an industrial strength SCM solution that just plain works. As a professional I am work within the confines of the clients local software environment, and  usually this means costly (in terms of both capital outlay and learning curve/backend maintenance) softwre suites. Henceforth, when I am asked for tools to use my answer will be Trac, Subversion, and MyEclipse.

Filed under: Project Management, Software

Model Management

As a professional consultant I use the tools provided by the client. On occasion, when allowed, I make suggestions and try to steer the tool set towards what I am familiar with, and what I think works best. My present engagement is heavy into the IBM/Rational suite of software development tools. The trinity of WSAD, XDE, and ClearCase allows us to develop collaboratively, a large scale application. There are times however when this industrial strength solution leaves me wanting more.

The weakest piece of his trio is ClearCase. It is intrusive, sluggish performing, and occasionally cantankerous. The layered architecture we are using for this application results in extremely long package names, which combined with any kind of decent path name in the files system, overruns the 256 character limit imposed by ClearCase. In other words, it is possible to create a new package in XDE, fill it with objects and save your work, only to have ClearCase truncate the path/file name to 256 characters WITHOUT TELLING YOU. The next time you open your model, you get missing unit errors. Very messy to resolve. We are in the midst of a migration to a later release of CC, which should expand our file name limit to 1000 characters.

We are also in preparation to migrate to RSM/RAD, or Rational Software Modeler and Rational Application Developer – WSAD 6 and XDE++. (I know about RSA, Rational Software Architect, and it would be ideal to have and use. Licensing costs make it prohibitive for this client, unfortunately.) This is not as easy and simply opening new software and importing your model. It seems that XDE, in trying to be all things to all people, supports multiple model types whereas RSM supports only one. The RSM model is pure UML, which is a Good Thing. However, since we were utilizing the code generation feature of XDE (auto sync on), we were using Java Code Models. In a JCM an interface is really a Java class with a special stereotype. In a UML model (or Basic as it is called in XDE) an interface is represented by, well, an interface. Converting to RSM will result in all the interfaces being converted to java classes, that happen to have a stereotype of interface. We will have to either convert the model and then clean up all the now broken interface touch points, or convert the model to UML in XDE and then import it into RSM.

Both XDE and RSM support configurable transforms that would allow the correction of our interfaces to be scripted. However, this is not a trivial task itself, and we are under tight deadlines. As we sort out the steps, and the transforms required, I’ll try to post a guideline here. Maybe we are the only ones in this pickle, but I suspect not.

Filed under: Software

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