Throughout the semester, we have been working on this DueDates Project. I just started out as a command line program that incorporated screen scraping using Java and HTTPUnit. The next thing you know, its a full-on web application that uses all functionality that we programmed throughout the semester. If you step back and take a look at the bigger picture, the process was actually quite intriguing. After going through semester after semester, writing programs and running them through a command line, it was "satisfying" seeing them come to life on a web browser. I think this was actually the most fun I had in regards to a project-type assignment.
We were able to finish all core requirements with no real problems. I think the key to getting to this state was to have started early and tackle obstacles quickly. The night the assignment was assigned, I went ahead and got the wicket files and configuration setup with a basic CSS layout, with the ability to fetch due dates and output them into the screen. The others were glad to have the framework for the system. The only thing that they had to get through was the learning the code of my previous DueDates system, DueDate-Blue. We initially voted on which system we were going to adopt, so after the choose, I had to run through the way the classes were coupled and what not. I believe our work flow as a group, was great. We originally appointed a "leader", which happened to be John Ancheta. I personally think that he did a good job handling scheduled Google chat sessions, calendar trajectory, task distribution, basically trying to keep the group afloat and on the same level.
Some aspects of working on this 2.0 version were easier, in a sense that the functionality of the system was already implemented; The hard part was learning techniques and logic that wicket programmers use. Since my group member, Yasu Kaneshige had a good deal of CSS practice, he did take over the visual design aspect of the system. Anthony Du and I tried to tackle the extra credit requirement. The use of Derby and connection drops gave me a huge headache; it was frustrating because I did have it functionally working the first night, then after doing pmd and findbug fixes, the connection would drop. I guess the fact that I had to try and learn it in 2 days played a role also. I would love to try and implement another project with a database back end.
After all is said and done, this project was great. Aside from the errors from the hacky-stat setup, and the downtime from Thanksgiving weekend, I didn't find anything to be much of a bother or setback. If there was one thing that I could change, is when we made the jump from 1 partner to 3 partners: the ability to keep your existing partner and join a pair. I really think the end product of all project would have significantly increased.
Monday, December 8, 2008
Friday, November 21, 2008
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
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
Monday, November 17, 2008
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:
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!
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 1will 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!
Friday, November 7, 2008
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.
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.
Monday, November 3, 2008
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?
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?
Saturday, November 1, 2008
The Code Review. Part 2
What review?
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.
Friday, October 24, 2008
Code Reviews: Pros/Cons
Overview
This past week we were given our first crack at a review for our classmates DueDates Software system. Some were good, some were bad... The thing is, we were previously given a bootstrap of the software, so about 80% of the programming was done for us! The programming portion of the assignment was really simple, just simple arg handling in the main(). I feel that the real exercise of the assignment was to make use of all of the techniques and tool that learned the first half of the semester and execute something useful. The review process is nice and quick, thanks to Google Code Project hosting. The tasks/issues, commit logs, and source change logs make this a peice of cake.
Pros
Reading other people's code opens a whole new insight on things: coding styles, logic, and feedback on our own code. I find reading code that makes sense to be a treat, a lot harder to find these days. The feedback we get on your code is great, another form of constructive crisitism! Funny how this is the first time someone has ever told me to use the Scanner class vs Buffered Reader (Something I learned back in 04'). I feel that we need more peer code review in software development; I find it to be a big help when it comes to improving the quality of my code.
Cons
Its really a disappointment when you are reviewing code that is supposed to be "completed" and there are just signs of "last minute effort" all over the code. There was a group that didn't even check if the table being retrieved was the table of interest. Also comments like "Author: Philip Johnson" and "Assume the first table is the one we need. Not true in general." were ignored. The amount of time spent on the project is really reflected on the amount of time that was put into it.
This past week we were given our first crack at a review for our classmates DueDates Software system. Some were good, some were bad... The thing is, we were previously given a bootstrap of the software, so about 80% of the programming was done for us! The programming portion of the assignment was really simple, just simple arg handling in the main(). I feel that the real exercise of the assignment was to make use of all of the techniques and tool that learned the first half of the semester and execute something useful. The review process is nice and quick, thanks to Google Code Project hosting. The tasks/issues, commit logs, and source change logs make this a peice of cake.
Pros
Reading other people's code opens a whole new insight on things: coding styles, logic, and feedback on our own code. I find reading code that makes sense to be a treat, a lot harder to find these days. The feedback we get on your code is great, another form of constructive crisitism! Funny how this is the first time someone has ever told me to use the Scanner class vs Buffered Reader (Something I learned back in 04'). I feel that we need more peer code review in software development; I find it to be a big help when it comes to improving the quality of my code.
Cons
Its really a disappointment when you are reviewing code that is supposed to be "completed" and there are just signs of "last minute effort" all over the code. There was a group that didn't even check if the table being retrieved was the table of interest. Also comments like "Author: Philip Johnson" and "Assume the first table is the one we need. Not true in general." were ignored. The amount of time spent on the project is really reflected on the amount of time that was put into it.
Subscribe to:
Posts (Atom)