Plexicon

Plexicon actually has a rather long story behind it. The original idea behind it was that it would be something like Dictionary.com, only for programming concepts. It was a final project for several generations of seniors about to graduate, but it never really got to be used much, because it was always delivered too late. Basically, in the beginning of a school year, the students would start working on it, but by the time they are done, the semester would be coming to an end, and so the usage would be deferred to the next semester, when someone else would take over the project, and decide to rewrite it from scratch.

I learned about Plexicon during the spring semester of the second year in college, when I was a TA for a C class - CS2130 - Languages and Translation. The reason I heard about it there, is because the content of Plexicon has traditionally been targeted at the students of that class.

When fellow TAs and I examined Plexicon and its contents, we were disappointed, to say the least. The articles were inaccurate, had mistakes even our students didn't make, and the interface wasn't too convenient. Hence, the summer after, Jose "The Nub" Caban (yes, yes, the same dude I worked on Lemmings with) and I took on the job of making it good. And boy, did we ever.

The first little bit of shock came, when I first got my hands on the code. Having talked with the previous "owners" of Plexicon, we gathered that it was written in PHP, with a MySQL back end. To my surprise, however, after I downloaded and extracted the source code of Plexicon on my hard disk, I couldn't locate a single PHP file, and instead saw quite a few Java classes. As it turned out, the whole thing was written using a single Dispatcher servlet, and a few Data Access Objects. I examined the code and the wish-list, and determined that it would be impossible for me to implement the desired changes, without rewriting everything - mildly put, the code wasn't very extensible.

I should make an aside here: at the time, I didn't even know such a thing as Java Servlet existed. All my web-app experience came from using ASP.NET / C# / MSSQL, and apart from hearing a little of JSP, I didn't even know much of the Server-Side scripting technology existed for Java. Hence, my first impulse was to rewrite everything from scratch using PHP.

Fortunately, I overcame that impulse, and decided to read some books on Servlets instead. And so I did, and I realized just what kind of power the technology gave. It was crazy - you could write normal Java classes, like it was a simple application, and just stick some JSP for the front-end, and it would all automagically cooperate.

Having learned a little bit about all the cool new (to me) Java technology, I came back for another inspection of the code. And I must say, I didn't like it any better the second time around. I saw that instead of harnessing the power of JSP, a custom scripting engine was used, and it wasn't terribly efficient. I saw also a number of other flaws, into which I will not delve. In the end, I ended up rewriting everything to my own liking, and that was good, fast, and extensible.

All in all, I am pretty satisfied with the project as of now, save for one thing. I made a mistake of writing my own Data Access Object code. That is, I did use JDBC, but wrote my own DAOs, and in an attempt to make them very flexible, I'm afraid I over-engineered them by far, and while they do offer very nice flexibility for simple tasks, more complex ones become clunky, and hard to read in a hurry.