This week, I am learning how to use Wicket (http://wicket.apache.org/). It is Java web frameworks lets you do web application programming (in Java). There are many other programs out there that can do it, but Wicket is better than the majority of those out there. Even the software development class’ professor, Dr. P. Johnson wants us to learn Wicket. I was looking through examples from the book Wicket In Action by Martijn Dashorst and Eelco Hillenius. Looking at the examples and trying them out on a computer gives a better understanding of how Wicket works and what necessary files needed to make it work.
To start things off, I did not finish the assignment. I am planning on completing it by the end of tonight or the latest Tuesday night. Throughout Thursday my nose was bleeding out blood, twice in the morning and one in the afternoon. I was freaking out because this was so random so I stayed in bed. Went to the physician and got some medicines. I worked on it Friday night for about 30-45 minutes, got the program’s environment variables running, and got some of the necessary files working. I am depressed from Sunday, got into some personal problems. Also, I lost my earring when I took it off in the shower so I can wash my hair.
One problem was that I did not know where to start, what files to make. So I asked some fellow classmates who were also working on it. This is the first time I am programming web application in Java. All these years, I have been programming in HTML, dynamic HTML, and one period been using ColdFusion. I am learning a lot of things from Wicket, making sessions, displaying things and etc.
Following is the distributable file containing the program (still not finish): http://sites.google.com/site/phillipkhlau/files/stack-wicket-klau4-1.0.1124.zip
Monday, November 24, 2008
Monday, November 17, 2008
DueDates-Red System release 1.2
This week proves another challenging task – our DueDates system should be able to mail out an e-mail with a report stating books that are checked out, second it should be able to “wakeup” to do the search and email a report. The other member in this team includes C. Okada. I was in charge of having the system generate an e-mail and sending out a report in the body that includes books that are checked out and libraries. The task at first was easy to do, but thinking on how to do got me a little confused. At the end, the system is able to send out an e-mail. C. Okada did the wakeup, and he sent an e-mail stating that it is up and working.
One problem I had was one of the library, UH Manoa’s Hamilton Library, was not printing out a list of books checked out for my e-mail report. C. Okada got that part fixed, I do not know what the problem was and it just printed out a blank page. My team member also got the third-party command line parser going, so he was able to get some of the if and else statements out. My other problem was when I made test cases for UH Manoa’s Hamilton Library class, it worked Eclipse’s JUnit Testing, and it also passed verify on my laptop. BUT Hudson failed to build the system because of two test cases. I do not know why it did not work on Hudson, but passed on my local Eclipse and verify tests. It is also hard to maintain a high level of coverage, as we expand the system adding more lines to it, our coverage level goes down and we have to add in more test cases to boost back the coverage level.
My team member and me met after our software development class every other day to discuss about the tasks we have to do. Any problems we deal with it over Google mail, extreme problems we deal with it in person. This is working effectively, I do not know how else to improve this group process for our team.
Working on this latest release 1.2 was a little easier than working on release 1.1. One part is that I had a template to look at when doing the e-mail portion for the DueDates system. I am still learning how to use the third-party command line parser that my team partner installed and using for the system.
The software intensive care unit is alright; at least we know if the system was committed regularly, the development time on the system, how much the system was tested and if the system is in a “healthy” state. One problem I had with Hudson was that it failed on my test cases for UH Manoa’s Hamilton library. It worked on my laptop – passed verify and Eclipse’s JUnit testing. I do not know why it failed in Hudson, I had to put ‘@Ignore’ into two test cases so Hudson will pass verify build.
I, as a software developer have to work more effectively and time manages better. There were so much things going on last week that lasted to the weekend that it was not able to get things done.
One problem I had was one of the library, UH Manoa’s Hamilton Library, was not printing out a list of books checked out for my e-mail report. C. Okada got that part fixed, I do not know what the problem was and it just printed out a blank page. My team member also got the third-party command line parser going, so he was able to get some of the if and else statements out. My other problem was when I made test cases for UH Manoa’s Hamilton Library class, it worked Eclipse’s JUnit Testing, and it also passed verify on my laptop. BUT Hudson failed to build the system because of two test cases. I do not know why it did not work on Hudson, but passed on my local Eclipse and verify tests. It is also hard to maintain a high level of coverage, as we expand the system adding more lines to it, our coverage level goes down and we have to add in more test cases to boost back the coverage level.
My team member and me met after our software development class every other day to discuss about the tasks we have to do. Any problems we deal with it over Google mail, extreme problems we deal with it in person. This is working effectively, I do not know how else to improve this group process for our team.
Working on this latest release 1.2 was a little easier than working on release 1.1. One part is that I had a template to look at when doing the e-mail portion for the DueDates system. I am still learning how to use the third-party command line parser that my team partner installed and using for the system.
The software intensive care unit is alright; at least we know if the system was committed regularly, the development time on the system, how much the system was tested and if the system is in a “healthy” state. One problem I had with Hudson was that it failed on my test cases for UH Manoa’s Hamilton library. It worked on my laptop – passed verify and Eclipse’s JUnit testing. I do not know why it failed in Hudson, I had to put ‘@Ignore’ into two test cases so Hudson will pass verify build.
I, as a software developer have to work more effectively and time manages better. There were so much things going on last week that lasted to the weekend that it was not able to get things done.
Wednesday, November 5, 2008
Software Intensive Care Unit
I am continuing to work on the DueDates system with a fellow classmate C. Okada. For some of you who are not familiar with the project, it is a program that will display a list of books checked out from a list of libraries that is listed in the system. As of now the Hawaii State and University of Hawaii Libraries are on the list.
Our software engineering professor, Dr. P. Johnson, showed us automated quality-assurance tools (PMD, checkstyle, JUnit, findbugs, and etc…) to help our system along the way. Next he showed us an automated quality-assurance system (Hudson, https://hudson.dev.java.net/) that uses all those tools and sends an e-mail if there are warnings in the results. All those tools are great for program development. Now we are introduced with a NEW system that maintains the “health” of the DueDates system.
Hudson's List of projects
It is called a Software I.C.U (Intensive Care Unit) a.k.a. Hackystat (http://code.google.com/p/hackystat/). The system maintains the “health” of the DueDates project by checking on vital information – does all members contribute code at least one a day, does the system work and compiles with the help of Hudson, if there are any warnings from PMD, findbugs, checkstyle, etc, how is the line coverage from Emma tool, and other things that will keep the system in a “green” state. The software ICU displays little histograms next to each tool like Emma’s line coverage, lines of code, and etc… and it is color coded like red means need to look at A.S.A.P., yellow means cautious, and green means fine. Personally, I think this is a great tool for us, it shows us the areas we need make improvements and also the history we made on each area. This is great; I like this “health” status system that checks the state of the DueDates system.
Hackystat's Main
In order to get this software ICU software working, I had to install and configure my local computer. I am using a laptop with Windows XP Pro operating system. The software ICU works by gathering data from my laptop and sends it over to a server where Hudson will process all the data. So I was able to install all the required sensors (Eclipse sensor, ANT sensor, and so on). One problem I encountered was looking for the darn .hackystat folder; I did not know where the heck that folder was. In order to solve that problem, I invoke ANT in my command prompt and it will display an error saying unable to find sensor properties file in C:\Documents and Settings… So I found the folder and all is working properly. My team member, C. Okada, set up the systems Hackystat and Hudson to generate a result page from all the data that is gather. I went in to double check everything is good, and to see if my local machine was sending information to Hackystat server.
Hackystat's telemetry chart of a system
As of now, the DueDates system’s line coverage is really low; we have to make some more test cases for the system. We are submitting code to the system daily. Our code issue is in a green state (awesome, like our professor said at least we got something that is green, ha ha ha). I can say we are at an unstable condition; we have to make some major improvements to have the system back in a stable state. A lot of work ahead of us, cannot slack off on this system. I am looking forward to have the system out to the public.
Our software engineering professor, Dr. P. Johnson, showed us automated quality-assurance tools (PMD, checkstyle, JUnit, findbugs, and etc…) to help our system along the way. Next he showed us an automated quality-assurance system (Hudson, https://hudson.dev.java.net/) that uses all those tools and sends an e-mail if there are warnings in the results. All those tools are great for program development. Now we are introduced with a NEW system that maintains the “health” of the DueDates system.
Hudson's List of projectsIt is called a Software I.C.U (Intensive Care Unit) a.k.a. Hackystat (http://code.google.com/p/hackystat/). The system maintains the “health” of the DueDates project by checking on vital information – does all members contribute code at least one a day, does the system work and compiles with the help of Hudson, if there are any warnings from PMD, findbugs, checkstyle, etc, how is the line coverage from Emma tool, and other things that will keep the system in a “green” state. The software ICU displays little histograms next to each tool like Emma’s line coverage, lines of code, and etc… and it is color coded like red means need to look at A.S.A.P., yellow means cautious, and green means fine. Personally, I think this is a great tool for us, it shows us the areas we need make improvements and also the history we made on each area. This is great; I like this “health” status system that checks the state of the DueDates system.
Hackystat's MainIn order to get this software ICU software working, I had to install and configure my local computer. I am using a laptop with Windows XP Pro operating system. The software ICU works by gathering data from my laptop and sends it over to a server where Hudson will process all the data. So I was able to install all the required sensors (Eclipse sensor, ANT sensor, and so on). One problem I encountered was looking for the darn .hackystat folder; I did not know where the heck that folder was. In order to solve that problem, I invoke ANT in my command prompt and it will display an error saying unable to find sensor properties file in C:\Documents and Settings… So I found the folder and all is working properly. My team member, C. Okada, set up the systems Hackystat and Hudson to generate a result page from all the data that is gather. I went in to double check everything is good, and to see if my local machine was sending information to Hackystat server.
Hackystat's telemetry chart of a systemAs of now, the DueDates system’s line coverage is really low; we have to make some more test cases for the system. We are submitting code to the system daily. Our code issue is in a green state (awesome, like our professor said at least we got something that is green, ha ha ha). I can say we are at an unstable condition; we have to make some major improvements to have the system back in a stable state. A lot of work ahead of us, cannot slack off on this system. I am looking forward to have the system out to the public.
Monday, November 3, 2008
Second Release for DueDates-Red System
As of now, I am working on a program with fellow classmate C. Okada. As you may now know, this program will list all books that are checked out from a list of libraries in the program. Right now, the program only has the Hawaii State and University of Hawaii Hamilton Library systems. Our professor, P. Johnson, introduced to us to Hudson (Hudson monitors executions of repeated jobs, such as building a software project or jobs run by cron; https://hudson.dev.java.net/), a software monitor that will test the program to see if there are any errors in Findbugs, JUnit, PMD, and so on. It is an awesome monitoring system, I liked the fact it builds our system and generates an e-mail if it fails to build. Using Hudson was a great experience in continuous integration, I commit my system to Google Project Hosting and it will build the system for me. Hudson is like an assistant to me for building and checking any failures in the system.
Today is our second release of the Due Dates system; we accomplished a lot but now enough. This release was harder to do than our previous release, because we have to add three capabilities to our system – supporting more than one library, sorting, and within. Our system still does not sort by books and library; I think it is my fault for not knowing that it was my task to do it – so it should be there on the next release. My group member, C. Okada, finish with the “within” method. That method will display all books that are within a day range, like one day or three days or more from the current day on the user’s computer. The system also has the ability of displaying more than one library, so it is able to grab two libraries’ credentials and generate the list of those libraries.
We downloaded and use a third-party command line parser, the first time around it did not work well with our system. Also, we had to make the third-party file available for users and developers and how to install and use on their system. So that generates a lot of hassle for their end so we scrap that from the system. JUnit error checking will generate warnings when we create sub-packages in our system, still figuring a way to go around the warnings.
We were meeting at the University of Hawaii’s Hamilton Library every other day last week for one to 2 hours at the most. This is good because we were able to discuss about the system, I had a problem with the third-party command line parser so my group member was able to solve. I think this is better than communicating with only instant messaging and e-mails. We probably will keep the Hamilton library as the meeting place, our secondary meeting place is the Salt Lake Public Library because it have Wi-Fi connection for public library card holders.
Cannot slack off, have to time manage everything. I think I did not time manage well during this release. I cannot let it happen again before our next release will be really behind on features.
Today is our second release of the Due Dates system; we accomplished a lot but now enough. This release was harder to do than our previous release, because we have to add three capabilities to our system – supporting more than one library, sorting, and within. Our system still does not sort by books and library; I think it is my fault for not knowing that it was my task to do it – so it should be there on the next release. My group member, C. Okada, finish with the “within” method. That method will display all books that are within a day range, like one day or three days or more from the current day on the user’s computer. The system also has the ability of displaying more than one library, so it is able to grab two libraries’ credentials and generate the list of those libraries.
We downloaded and use a third-party command line parser, the first time around it did not work well with our system. Also, we had to make the third-party file available for users and developers and how to install and use on their system. So that generates a lot of hassle for their end so we scrap that from the system. JUnit error checking will generate warnings when we create sub-packages in our system, still figuring a way to go around the warnings.
We were meeting at the University of Hawaii’s Hamilton Library every other day last week for one to 2 hours at the most. This is good because we were able to discuss about the system, I had a problem with the third-party command line parser so my group member was able to solve. I think this is better than communicating with only instant messaging and e-mails. We probably will keep the Hamilton library as the meeting place, our secondary meeting place is the Salt Lake Public Library because it have Wi-Fi connection for public library card holders.
Cannot slack off, have to time manage everything. I think I did not time manage well during this release. I cannot let it happen again before our next release will be really behind on features.
Saturday, November 1, 2008
Google Project and Reviewing Code Part 2
As of now, I am working on a program (with team member C. Okada) that supposes to display books checked out from libraries that are listed in the program. We already let other programmers (who are in our software development class) to review our system. We got back the results and are pleased at what the reviewers found and commented on. We also had a chance in looking at our classmates’ system (we all are working on the similar idea) and gain some knowledge on what to improve in our own.
Since the reviews we did some improvements to our system. So we had another review session to see if what other things have to be done. This time around, my team had a chance to look at Team Violet’s system. We were getting ideas on making packages and sub-packages since their system is structure with packages. We are having problems in making sub-packages, every time we have sub-packages in our system, one of the automated error checking tools (PMD, findbugs, checkstyle, and JUnit) gives a warning. So we are figuring out a way to correct the warning.
I had a chance to look into Team Violet’s library code. I was looking for a way to find the length of tables displayed on a given web page but did not know what the command to find the length is. Team Violet had the answer: response.getTables().length; I did not know that this works, but now I know and I can change my part of the system without using try and catch statements.
We had Team Yellow’s members review our system. One of the members (J. Zhou) did not review our system – C. Okada and I still cannot find any reviews made by him and still did not receive an e-mail stating that he reviewed our system. We sent out e-mails to all Team Yellow’s members, and only J. Zhou did not review. We did get a feedback from other Team Yellow member, he was able to catch Javadoc errors, JUnit warning, also suggested us to look at another team’s system on how to improve our Emma line coverage (automated error tool).
We are using Google Project Host’s built-in review tool. The first time around I had some complications in using the review tool. There were some points where it did not let me publish my comments into the code, and other times where I did not need any comments to be published. This time around, I had no problems in publishing my comments, but I hated the fact that I have to look for a file all over again starting from the system’s main directory. Only if it stays in the same directory that I am on, it will make life a little easier. I also want my comments to be published with one of the issues, in the Google Project Host’s Issue Manager, instead of seeing my comments in one of the commit logs. If the review tool let us pick where we want to post our comments, in one of the issues or in the commit log, it will be excellent in my standards. For now, Google Code Host’s review tool is awesome, but will be better with my ideas in (ha ha ha ha!).
Since the reviews we did some improvements to our system. So we had another review session to see if what other things have to be done. This time around, my team had a chance to look at Team Violet’s system. We were getting ideas on making packages and sub-packages since their system is structure with packages. We are having problems in making sub-packages, every time we have sub-packages in our system, one of the automated error checking tools (PMD, findbugs, checkstyle, and JUnit) gives a warning. So we are figuring out a way to correct the warning.
I had a chance to look into Team Violet’s library code. I was looking for a way to find the length of tables displayed on a given web page but did not know what the command to find the length is. Team Violet had the answer: response.getTables().length; I did not know that this works, but now I know and I can change my part of the system without using try and catch statements.
We had Team Yellow’s members review our system. One of the members (J. Zhou) did not review our system – C. Okada and I still cannot find any reviews made by him and still did not receive an e-mail stating that he reviewed our system. We sent out e-mails to all Team Yellow’s members, and only J. Zhou did not review. We did get a feedback from other Team Yellow member, he was able to catch Javadoc errors, JUnit warning, also suggested us to look at another team’s system on how to improve our Emma line coverage (automated error tool).
We are using Google Project Host’s built-in review tool. The first time around I had some complications in using the review tool. There were some points where it did not let me publish my comments into the code, and other times where I did not need any comments to be published. This time around, I had no problems in publishing my comments, but I hated the fact that I have to look for a file all over again starting from the system’s main directory. Only if it stays in the same directory that I am on, it will make life a little easier. I also want my comments to be published with one of the issues, in the Google Project Host’s Issue Manager, instead of seeing my comments in one of the commit logs. If the review tool let us pick where we want to post our comments, in one of the issues or in the commit log, it will be excellent in my standards. For now, Google Code Host’s review tool is awesome, but will be better with my ideas in (ha ha ha ha!).
Subscribe to:
Posts (Atom)