code prole

Icon

coding for the proletariat since 1977

Subclipse and Eclipse 3.1

With the release of Eclipse 3.1 and MyEclipse 4.0M2 for Eclipse 3.1, I updated my development environment to the latest release of both products. This required adding the Subclipse plugin from Tigris to allow access to my repository.

Tigris has yet to release a plug in for Eclipse 3.1, however I have been able to use the 3.0 plugin with minimal difficulty.

The local update site from Tigris doesn’t work for me at all. I have repeated downloaded the update site ZIP file, unzipped it and added the resulting folder as a local update site in Eclipse. The update has never worked this way.

The 0.9.31 release of Subclipse does not work for me under the final release of Eclipse 3.1. And, since the local update site path doesn’t work either, I was forced to copy the feature and plugin jars from my previous Eclipse (3.1M6) installation to the new 3.1 final installation. This reverted me to the 0.9.30 release of Subclipse and restored access to my repository.

The problem with 0.9.31 is an inability to access the ‘root url’ setting when setting a new repository location. In 0.9.30 the browse button displayed various parcings of the repository url, allowing you to make a selection. In 0.9.31 this button doesn’t work. At least on Mac OS X 10.3.9.

By coping over the JARs from features and plugins I was able to regain access.

Filed under: Eclipse

Eclipse Tricks

Recently I uncovered some new (to me anyway) Eclipse tricks.

First up is the “lightbulb” icon that appears in the line number. In addition to providing assistance with errors, it also provides context sensitive wizards. For example, it will appear for nonexistent classes giving you access to the new class or new interface dialog. Very slick.

Second, I learned that the Source menu contains an entry for generating getters and setters. I actually think I had seen this before, but was so used to hand-coding these methods that I had forgotten about it. This past week, with some new coding to do after a long hiatus, I am appreciating the time savings of using generated accessors and mutators.

Like its big brother WSAD, Eclipse is a rich platform that contains many features. I’ve never purchased a book about an IDE before, but I’d be tempted for Eclipse.

Filed under: Eclipse

Project Estimating

One of the hardest aspects of any project is developing an
accurate estimate of effort and resources. There are really only three
variables that directly impact project delivery dates: feature scope, resource
availability, and time.

In my experience the scope is almost always set outside the sight of, or
control of, the design and development team. The client wants certain features
and is largely unwilling to barter on the set required for a successful
product. Granted the majority of my experience has been for government or
pseudo-government clients (e.g. Utility companies). While these clients aren’t
bottom-line driven, scope, and often time, are fixed variables in the equation
of project delivery.

At my current client the feature set required is immense (approximately 54 Use
Cases of effort) and the timeframe is rigidly set – 9 months. Using the
historical metrics available to us we have come up with an estimate of effort,
in person-months, of 255. Two-hundred and fifty-five person months of effort.
With team size the only variable we can adjust (i.e., time) we need 28 people
on the team to reach our goal.

 Just managing 28 people will require additional resources. Our
best guess is that project management and technical management each represent
about 10% of any successful project team. So our 28 person design team will
need three project  managers and three technical managers.

 If the client had unlimited funds, and if we could acquire a
total of 28 skilled resources, and if we could gather 5 or 6 dedicated
managers, and if we started today we could just make our date.

 In reality we have 8 people, 5 of whom need considerable mentoring
and who are not fully dedicated to the project. In short we are 20-24 people
short of meeting our goal.

Even if our team works double time for the next nine months, the equivelent of 16 people, we would still fall far short of delivery on time.

It’s going to be a long year.

Filed under: Project Management