Archive for the 'Java' Category

FSD - I am Alive!

FSD - I am Alive!

This post related to FST articles. It was hard during Summer to write on a regular basis, but now … Import tool already alive. Yes, I already implemented the following features:

  • Basic import with restoring folders structure
  • Plain import (all documents being imported into selected folder)
  • Import with compression folders to ZIP archives
  • Import with converting text files to PDF format
  • Import with conversion TIFF files to PDF format
  • Extracting ZIP files and imports them as a folder

During the work it became an obvious that tool need a comfortable way to interact with Docbase (check imported documents and structure, etc.) This requires create a sample browser, with some basic features set. So I make decision to split project into two subprojects

  • Library with Swing components for Documentum
  • Import tool project

Of course second project will be the first subscriber of the library.

No Comments »

FSD - Round 2

FSD - Round 2

Fast report for the passed time.

  • Was refactored code which is display docbase structure as a swing tree
  • Based on refactored code was created Swing component to choose target documentum type

    Docbase Type - Folder Type Chooser

    Docbase Type - Document Type Chooser
  • Also was created component to choose ACL
    ACL Selector

Ok, as a result number of Documentum Swing widgets was increased by two select dialog.

1 Comment »

Doc, Coffee Doc

Doc, Coffee Doc

Here is some my thought about java doc.

Personally me sceptical about putting lots of javadoc and examples of usage in javadoc.

The reasons I say so:

  • Due to human nature nobody in the project will read them.
  • Most of projects are business oriented, and not used as a public library, so javadoc is not such critical, so your code will not be used as a black box by many developers all over the world
  • I believe that the code should be the primary documentation because it has all the details, when developers looking into code they are getting better understanding of the things and can change them in more desired way.
  • Support of javadocs will add additional time overhead and will make refactoring task more complex (or after the code refactoring javadoc will be dirty).
  • In 90% cases, javadocs created by developer not give more information then method signature, e.g. javadoc for the function getFile will be “This method return the file”.
  • For the distributed team specific (people who working 10-15 hours per week) spend 1-2 hours to put javadocs looks too prodigally as for me.

So I am follower of the idea, that code should be understandable in the same level that javadoc and instead of putting code example into the comments, it is better to create a JUnit test.

Some examples of the comments-javadocs I saw recently:


/**
* Construct object instance with default parameters.
*/
public SomeClass(){
...
}


/**
* Registers new listener.
*
* @param l
* the listener to register.
*/
public void addChangeListener(ChangeListener l) {
...
}


// Start transaction.
session.beginTransaction();
....
// Commit all changes.
session.commit();

Well, as for me such comments just add additional lines to code and make it harder to read(good that eclipse has folding feature for the method javadoc).

So again, javadoc is very useful for open source projects, but I am skeptical about using them in business related projects, and developers can’t write good javadoc documentation.

No Comments »

Next »