Ajaqs is a web-based application used to warehouse FAQs on a per-project basis. In that sense, it functions like the original FAQ-o-matic, written by Jon Howell.
I first used the original FAQ-o-matic at apache.org in 1999 when I was working for a company called MATRAnet in San Carlos, California. I found the online question-and-answer forum very helpful. At the time, I was becoming familiar with Internet technologies and Java tools (like servlets), and thought it would be interesting to re-implement the FAQ-o-matic as a servlet application. So, finally finding some spare time in Africa (where I work as a Peace Corps Volunteer in Uganda), I've done it. Ajaqs is the result.
Because of the tremendous effort of the Free Software Foundation, and the role it has played in my own professional development, I have felt compelled to donate this work to the software community (please see licensing details). My hope is that Ajaqs will help engineering groups maintain and perpetuate their knowledge-base. In my own experience, one of the great challenges of engineering a new project is not in fact the project itself, but instead, the storage, transmission (often to novices), and searching, of all the knowledge that grows up around the project. Companies have a vested interest not only in making this knowledge readily understood, but also stand to gain when their top-tier engineers are spending time on new projects, not dealing with questions on old ones.
Ajaqs uses modern, open-source Java technologies. This table lists which technologies are required:
| Purpose | Technology | Version |
|---|---|---|
| configuration / build | Ant | 1.6.1 |
| compilation | Java | 1.5.0-beta2 |
| front-end | Java Servlets | 2.4 |
| front-end | Java Server Pages (JSP) | 2.0 |
| front-end | JSP Standard Tag Library (JSTL) | 1.1 |
| front-end | request (custom taglib from jakarta) | 1.0.1 |
| front-end | XHTML | 1.0 Transitional |
| front-end | Cascading Style Sheets | 2.0 |
| back-end | Castor | 0.9.5.3 |
| back-end | MultipartRequest | 1.30b3 |
| back-end | MySQL | MySQL-4.0.20c |
| datbase-connection pooling |
PoolMan | 2.0.4 |
| logging / debugging | log4j | 1.2.8 |
We use Castor for two reasons:
To make Ajaqs independent of the database vendor. That is, Ajaqs in theory can be mapped onto a variety of database products, provided Castor supports the vendor in question.
To support transactions. That is, every page in Ajaqs is processed as a transaction, so either the whole page works fine and we commit (where need be) to the database, or we rollback and do not commit any changes at all.
The default configuration for Ajaqs relies on MySQL-Max. We use INNODB tables, provided in MySQL-Max, in order to get transactional behavior in the back-end.
Flexibility. The end-user should be able to use any major commercial (or open-source) database on the market. Moreover, the end-user should be able to customize the look-and-feel of the front-end; this includes the ability to internationalize the application.
Maintenance. Both external documentation (like this) and inline javadocs should explain how things work. I've tried to write clean Java code so that developers who build on Ajaqs will have a clear, easily extensible starting point.
Ease of Use. Installation is simple; you just have to create a .war file and drop it in the right directory/folder. The Ajaqs interface is text-based, and intended to provide easy access to search operations.
Security. File system security issues are completely off-loaded to the Java security model (i.e., the Java sandbox) and whatever access-policy may be in place for the database. Ajaqs-specific security in connection with particular web content is off-loaded to the security model for the application server under use. Ajaqs-specific security that deals with end-users is role-based, and leverages Castor's JDO mapping model to restrict, automatically, what data from the back-end some end-user can access.
Here are some disadvantages of using Ajaqs:
Castor. Although this is a big design advantage, in practice it poses occasional problems, partly because of sketchy documentation.
Non-trivial design. Ajaqs may be powerful, but it comes at a great price. As the list of technologies above indicates, it takes a well-versed Java developer to understand all the issues involved in making Ajaqs work properly.
Ajaqs stands for a Java FAQ-o-matic, and is pronounced like the proper noun Ajax, which is the name once given to a great warrior in ancient Greek mythology.
Here are some contributors who have helped make this package possible:
Jon Howell, author of the original FAQ-o-matic.
Academy for Educational Development, which donated the computer equipment and the Internet hook-up where I work.
Peace Corps, which provided a place in Uganda where I can work in peace.
Redhat, which supplied the free OS (Redhat 7.1) and superior development tools with which I wrote Ajaqs.
You can help make Ajaqs a better tool in the following ways: