Archive for November, 2008


Posted: November 19, 2008 by ralliart12 in academia, Mnemonics

Hope you have received the package by now. I wanted this to be a birthday gift (edit: belated) for you, but it turns out unfortunately, this present now serves double-purpose as some form of an apology as well.

You may not know how grateful & appreciative when you welcomed me to your CS3214 team. I’ve long branded myself as “un-proficient” at Java EE when I didn’t manage to complete CS2261 previously. I was more than prepared to join a foreign team and become their barnacle. But it turns out I dunno how to turn you down. I joined your ensemble, hoping that if I try my best I’ll be able to be of more use than a multi-plug.

But alas, it turned out that I was not only “un-proficient” but also inadequate. My limited skills (or lack thereof) inadvertently caused the presence of the following flaws in the modules I was responsible for:

  • Did NOT use EJB relationship-model to design student portfolio assignments and student enrollments; which result in the eventual impossibilities for their Jasper reports to be generated (even with much guidance from Mr. TWK).
  • Did NOT use EJB QL-format to perform queries to retrieves all objects of Module E6; which result in you being unable to apply your essential “sort-by” algorithm (as per Module E4) to E6’s listings. [But on the other hand, the reason I use the relationships-model, i.e.

PortalEntity portal = entityManager.find(PortalEntity.class, portalId);

return portal.getEnrollments();

is because I was advised by R that it’ll be simple and straight-forward.] I didn’t realise this simplicity will equate to its limitations. Another one of my many oversights.

  • Did NOT implement the highlighted portion in the photo as shown below; simply because I forgot! I wished we had enough time to perform a thorough system walk-through so as to expose such “mistakes” (of mine), but I was expected to implement it and it slipped my mind.

  • Made last minute changes to the format of date that is stored for each invoice, which broke your SQL update algorithm; causing the “overdue-check” upon each login to be vaporware in the end

The major sins were above; I’m positive that there are many other such monstrosities hidden within my modules that I can only pray the evaluators overlook. But I’m unsure if there are many others which are as careless as me.

I’m truly apologetic to have failed you on my parts. I didn’t wish for your disappointment but I’m afraid that my inadequacies have cascaded onto your project. If there’s something, anything, that I can do to “fix” this, I would. I really would, if I could, if I have more just a bit more time I will “correct” all the flaws above. But time, as we know, is a luxury none of us can really afford [on this project]…😦

Hope the item in the package will be a practical addition to your everyday life. Happy belated birthday, to a good friend, wonderful team-mate, and a fantastic leader.

Seeking your forgiveness,




Posted: November 17, 2008 by ralliart12 in academia, Mnemonics



“Am so furious with myself currently; that I can terminate thee if not for the fact that such a termination will equate to a lack of manpower on the impending Wednesday. … In retrospect, I suppose if given adequate time, where a run-through of the entire system will expose such inadequacies, perhaps my sins will surface themselves to the light of public scrutiny much earlier. But alas, hindsight, as they say, is always 20/20.”

Well, being an SoC IS student, I suppose taking this module is inevitable. Have heard many horror stories about it; in fact, it seems the “duty” of every CS3214 student to remark or document the progress and aftermath of their experience (just search for “3214” on your favorite blog sites). So, here’s my version:

I did not manage to accomplish the major “Assignment 2” of a “foundation” module in prior years, the CS2261. CS2261 is a basic introduction to Java EE programming, & since I was never very strong in programming, I was unable to handle the programming assignments well, at least, not the “heavy” ones. Hence, I was very fortunate to be adopted by my classmate, H, to join his team for CS3214. I did, exhaustively, make known to him about my CS2261’s experience, and hinted strongly that I may be a liability to the team but he accepted me nonetheless; & I’m grateful for that.

H has a wide network of friends, and the team was easily formed way b4 the semester begins. The team members became my good friends as the project progresses. It was also rather daunting that we have to attend Java EE workshops during our holidays b4 the curriculum even begins; to refresh our skills that’s what the dept claimed.

Since I knew last year’s CS3214’s project specifications, when we received ours, I admit it appears slightly easier upon comparison. At least the scenario is less serious: design a business portal management system(last year’s some CRM system for banks). Anyway, I do not wish to bore you readers with the intricate details, so the short version is our team of 6 divided into pairs of 3s to work on autonomously-allocated modules. Those of us with slightly more language flair assisted further with the documentation & presentation; whereas those with stronger programming foundation brutally assaulted the coding perspective. I’m more than pleased to say every single one of us contributed fairly & extensively to this project, no free-loaders here; all gave blood & sweat in copious amounts. It was also functionally convenient that we share the pursuit of another common module: CS3251 and that made meetings for both modules easier. We literally clocked a lot of time together with each other.

Last 3 nights b4 D-day

Last 3 nights b4 D-day

Progress was slow but steady, meetings were long and weary. Our efforts escalated exponentially with the countdown towards the final deadlines. 1 thing to note: the multiple deadlines enforced our accomplishments of designated milestones. The highlight of the project, to me, was the overnight sessions during T-36hrs b4 the clock runs out. I managed to deliver sufficient amount of waking hours to be useful to the team and I could see it was very strenuous for H and the rest as well. We managed to submit a reasonable and agreed-upon set of functionalities upon the deadline, but the nightmare was the build-up to the much-latter presentation.

It turned out that the version we submitted was really quite buggy and we have to decide how many fixes to implement on presentation day as each fix permitted carries with it an equivalent penalty. I can literally feel the stress that consumed H during this time frame, & he’s a better man for he did not lose his temper once. Luckily, the module co-coordinator, Mr. Tan Wee Kiat, is reasonably lenient with us; probably the camaraderie of our team overflow unto him as zeal & enthusiasm? He gave us a reasonable bargain in terms of penalty-vs-fixes. The presentation was “reasonably” flaw-less and least to say, I cannot thank everybody enough, namely H and team, Mr. Tan Wee Kiat and Ms Yi Cheng. Mr. Tan is an incredibly dedicated co-ordinator, i.e. his email response was slightly faster than instantaneous, and during the last few days b4 the deadline, he was physically making rounds in SoC1, soothing any cries for help. In fact, I’ve heard of his fantastic reputation last semester from my schoolmate, where he was the teaching assistant for my friend’s team.

Lastly, I have a list of improvements that can make future similar projects better in terms of team management and progress tracking:

  • Team leader has the right to, and should enforce internal deadlines as he deemed fit
  • When there are disagreements as to what should be pursued further, or what should be left as it is, team leader has final say, and it should not even be disputed further when there is unanimous consensus from the majority of the members.
  • Every day you will tell yourself, “there’s only X no. of functionalities left to accomplish”. This is never true, as X will explode into a larger number of finer sub-functionalities of which some are difficult to, or run contrary to what the current design permits. So, when you think there’s X no. of things left, you should work exponentially faster.
  • Have an internal “white board” listing down unfinished functionalities/components/modules AND their individual owners. This makes everybody’s workload transparent and provides adequate but intrinsic pressure for us to work more efficiently. Furthermore, these should serve as a checklist for submission.

Oh, & there are things I’m not that pleased with, & think could be done better:

  • Code reuse: the team should sit down, review the project specifications, and list down functionalities that are technically similar; this will promote a sense of consistency across the project to our end-users, and it will save the effort of 2 person coding the same thing.
  • Internal testing: no testing = no discovery of semantic bugs beforehand = submission of buggy version. Planning for internal testing also forces one to complete faster than the “market rate”. This is one point that I’m rather dissatisfied with. Cannot be emphasized enough, my desire for iterative internal stress-test.
Fantastic team

Fantastic team

All in all, fantastic team with solid effort. My impression of individual members is consistent from the 1st day to the last. It is a joy working with this team and the experience is something that I relinquish. Pat on our backs, everyone. Thank you for your effort and thanks for accepting me.