My First Java Web App

After years of learning to programming as an undergraduate, we finally get to see it "come to life" on the big screen! Well, a webpage... but anywho, this pretty cool looking at a a dynamic website that is java powered. I have a stronger background in PHP/MySql development and light experience with ColdFusion so I have a good amount of knowledge when it comes to dynamic web page elements and html.

The assignment this week was to revisit the Stack and implement a web interface for it. A stack is a generic data structure a stack is an abstract data type and data structure based on the principle of Last In First Out (LIFO). With a stack, you can add, retain, and remove data. Use the interface below to visually see the behavior of a stack data structure. Really simple concept, so the brainstorming was easy. 3 options presented to the user: Push, Pop, and Clear.

The tools introduced to us this time around is Wicket, Jetty, and Slf4J. With a combination of these tools and a little bit of imagination, you can have yourself a Java Web App! As a structure for the assignment, Professor Johnson provided us with wicket examples.

I did take a little time to create css div and changed the general appearance of my site. Here is a screen shot:














In the last remaining weeks, I look forward to dealing more with Java web apps and converting our DueDates project into something great.

Download stack-wicket-erinjuneilkim.zip

More DueDates!

Whats new?

So this weeks task was to add email and "wakeup" functionality to our project. If a user uses -email argument, the results of program is emailed to the given email address versus just printed in the terminal. This makes printing and referencing back to items remarkably easier. The "wakeup" function gives the user the ability to just have they system sleep for a certain amount of time, then "wakeup" and run the program. Now at frist, this sounds kind of useless or seem like spam messaging, but when paired with the -within arg, its actually a handy reminder tool. Invoking something like:

-email youremail@do.main mail.hawaii.edu -wakeup 1 -within 1

will run the system once a day and email you if you have something due the next day! The concept is cool and a lot more practicality to our system.

Implementation

Got our first taste of javamail! Easy to use after a couple of examples. I have had some previous experience with Sendmail so it wasn't that hard to grasp any of the concepts. Unfortunately, we did run into complications when it came to running it on the Eclipse IDE vs Terminal. After spending some time debugging and class discussions, we found that we had to import the mail.jar file into the actual Java IDE Directory. Everything was running as expected after that.

Within was handled by my partner, Arthur. The concept was basically a cronjob, so it was just manipulation and use of the Timer class. He finished this implementation fairly quickly with no real hassles.

What now?

The tasks given to us were fairly easy to get going; the only problems we really ran into were jar file complications. Aside from the class meeting together, we didn't meet make and effort to meet outside of class this week. Though, we did have daily messenger conversations to communicate our ideas to each other. It worked out well. In comparison to the previous upgrade implementation, I found it to be on the same level of difficulty. When taking a step back and reflecting on the project, I find it pretty cool on how we are slowing adding functionality to the system and ultimately make it what we want. This upcoming week, we will start to look at web apps and see how we can somehow integrate that into our system. Pretty exciting!

Software ICU???

ICU?

So the general idea behind a standard intensive care unit (ICU) is to check for vital sign regularity. Everything in the "norm" (adjusted depending on illness and severity) will look and sound normal; when someone is about to die, then the machine goes crazy. Brilliant idea in the medical field. Now, how in the world do you hook up virtual software to an ICU? The idea was great! It pretty much takes out the hassle of running tools every single day and the entire process is automated! Another cool tool add to the software engineering arsenal.

Here is a sample screenshot of the output






In our case vital signs are found at the top of the columns. The only term that seemed foreign to me was "Churn", which basically means the measured amount of code line change.

Arthur and I have successfully finished the assignment meeting all requirements. The entire class did have a run-in with the failed ant -f hudson.build.xml. After a huge online class discussion, we resolved the issue by adding a UserMaps.xml to our home sensor-bin directory.

Currently, our project is lacking in the coverage column. The main issue is that we have an entire class, DueDates.java, which meets 0% coverage. Arthur and I are currently coming up with a way to properly test it. Other than this, we have pretty satisfactory "vital" signs for our project.

DueDates -- Revisited

The 2nd part of our original assignment was quite interesting. Compared to the previous assignment, this had a little more head scratching and brainstorming, which is great! 75% of the code wasn't done for us which left room for different approaches and logic models across the various groups in the class. The code review that just took place was great insight on how other groups approached the assignment. Since I have a little more experience in programming with scripting languages, php and perl, screen scraping and string manipulation is something that I toy around with a lot. I did feel that a good portion of the assignment had to deal with date comparison; I also had a good lesson in how Java handles string/date differentiation. Luckily, Arthur and I were successful in implementing all the requirements to the assignment. The Hudson service was also introduced to us this time around. Incredible tool. I found it to be a great help because of its ability to automatically build the system every time there is a commit and sends email if the build contained and error. This takes out the frustration of tracking down the last person to commit and troubleshooting code. Upon completion and a code review done by DueDates-Purple, my partner Arthur went ahead and restructured the system by making a separate "library" package. A great improvement for modularity and robustness.

Arthur and I spent almost everyday talking about the project over AIM chat client but meet face to face on some occasions. Most of our ideas were effectively communicated to each other and ambiguity was non existent. A huge part of our communication was through Mac OS X Leopards iChat client were we could speak and look at each others screen to troubleshoot code. Again, the tasks were split based on the issue log that we updated on GoogleCode. We committed code almost everyday at least once a day, tackling issue after issue. There isn't anything I would really change as far as the process of how Arthur and I get things done. we

The next time around, I think it would be great if we could actually work with more members. Pair programming is something that I have practiced over the past years, but working on a system with a bigger team would be great. I do predict that this would be harder because we would all have to meet on our free time to communicate effectively. Since everyone is on the go and will probably have conflicting schedules, perhaps a group based message board would help? Chat rooms?

The Code Review. Part 2

What review?

Hmm... This past week we were given updated tasks to further enhance our system. Review process again worked two ways. From the looks of it DueDates-Green has not done any work since their first review. I just stopped reviewing their code after my first couple of comments. Thats when I noticed no progression was made after thier first submission. Professor Johnson mentioned that they are away for a trip, still I feel that it is unfortunate to miss out on growth and improvement on your system that you are going to work on for the rest of the semester!

Feedback

As usual, the feed back was great. Our system has evolved in a huge way, and this time, 85% of our code isn't programmed for us! We had a lot of implementation to do. One of the biggest changes was in our logic. We created an entirely new class for borrowed objects which we felt was a great object-oriented approach to solve the problem of adding multiple libraries, which ultimately makes the program more robust. The comments that were received from DueDates-Purple were somewhat helpful. The complements on the User guid and Developer Guides ensured us that we are heading in the right direction to make them as clear as possible. We did revamp our project home to be much more visually pleasing, got a couple of comments about or previous version. I think its great to hear that people find your program to be great and they will look into adapting our logic/code into their system. And of course their other recommendations will be taken into consideration.

In the end
I'm just glad that the party that wasn't here was the one that we were to review. It would just be unfair for someone to scratch someone's back and have it be unreciprocated; in this case, DueDates-Orange. Maybe next time, if there was a group that didn't make the effort to progress, they could be skipped over in that weeks review? This would ensure that no one will be left behind for those who are making an effort.