Saturday, January 5, 2008

Requirements as versioned documents

A requirements document is almost always under revision control. Any requirements management process worth it's salt has a change process. But individual requirements as versioned documents... Again, requirements can be tied to code releases. And it should make the change process easier, as well as querying for requirements. A requirements compatibility matrix could be generated (based on versions of each requirement.) Requirements implemented in this release is just another generated document, based on the source control logs.

Tests as versioned documents

A test under version control could also be branched with a code release. A versioned test suite could change to meet new requirements. A tag of tests could be a suite. Versions could even keep track of test completion status and actual results, but that might be going too far.

Bugs as versioned documents

A bug that is a document under version control could have the heading and description edited without worrying about affecting credibility. Previous versions of the bug would contain the original text. A bug under version control could be branched, and branches could be tied to certain code branches or tags.

Document centrism

A test is a document
A bug is a document
A requirement is a document
A task is a document

A document should have the following capabilities:
Editing,
Versioning,
Commenting,
Sharing,
Searching

A semantic document (like XML) could also be queryable, and have better searching. It could be populated from a template plus data.

Reports are documents generated from a template plus data.
Forms are applications that retrieve data, potentially by processing documents.

A collection of tests, requirements, or bugs is a report generated by querying multiple documents.

System Integrator

According to wikipedia, One Shore pretty much matches the definition of a system integrator.
We pretty much build a QA system from open source parts. A QA site is a hosting solution, a Linux server or VPS, a collection of open source tools, including version control (svn,cvs), build automation (ant, maven, luntbuild), bug tracking (bugzilla, trac, mantis), test management (qatraq, test-site, testopia), automated tests(fit, testng, junit, selenium, watir, samie)project management (dotproject, phprojekt, trac), document management (knowledgetree, alfresco), wiki (dokuwiki, dekiwiki, moinmoin, trac), forum(punbb), blogs(wordpress-mu), etc. and integrating them.

I noticed trac is in there three times. Fit and trac are popular for a reason, and I think it has to do with document-centrism.

Friday, January 4, 2008

Java EE5 setup

Installation Directory [/opt/SDK]: /opt/java/ee5/sdk
Admin User [admin] : admin
Admin Password : secret123
Admin Port: 4848
HTTP Port: 8080
HTTPS Port: 8181
The following items for the product Java Platform, Enterprise Edition 5 SDK
will be installed:

Product: Java Platform, Enterprise Edition 5 SDK
Location: /opt/java/ee5/sdk
Space Required: 215.65 MB
------------------------------------------------
Java 2 SDK, Standard Edition 5.0
Sun Java System Message Queue 4.0
Sun Java System Application Server Platform Edition 9 Update 1
Sample Applications
Java BluePrints
First Cup of Java Tutorial
Open ESB Starter Kit with JBI and BPEL

------------------------------------------------


Installation Successful.

Next Steps:

1. Access the About Application Server PE 9 welcome page at:
file:///opt/java/ee5/sdk/docs/about.html

2. Start the Application Server by executing:
/opt/java/ee5/sdk/bin/asadmin start-domain domain1

3. Start the Admin Console:
http://localhost:4848

Java 6 on Fedora, CentOS5, RHEL5 needs compat-libstdc++-33.i386

I downloaded Java 1.6 with EE 5 and tried to install it on CentOS 5. But it complained about libstdc++.

./java_ee_sdk-5_01-linux.bin: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

I have libstdc++ installed, but have /usr/lib/libstdc++.so.6.0.8

Sun has a bug on it.

Aparently, Fedora, Redhat, and CentOS are not supported. What they needed was to statically link. The solution is to install a previous version of libstdc++ (libstdc++.s0.5). You can do that with yum:

yum install compat-libstdc++-33.i386

and then run the java installer:

./java_ee_sdk-5_01-linux.bin

--

I got Java 1.6 installed, but java_ee_sdk-5 is still hanging:

see http://docs.sun.com/app/docs/doc/820-0135/gazry?a=view

export JAVA_HOME=/usr/java/jdk1.6.0_03