21.MyISERN-1.2

There were many things difficult about this project. A lot of the issues were from the XML itself. The first issue was trying to figure out how to marshall things back into XML format in general. After our first meeting, we were able to figure this out with very little difficulty. We thought that this project would be easy but in actuality, I ended up losing a night's sleep just to finish all the tasks. I'm proudly, and very wearily, able to pronounce that we have finished all the tasks. Although I'm not sure if this is the most robust piece of code I’ve written however.

More difficulties arose from creating all the different adding function. Each in itself wasn't very hard but it was very tedious. I believe each one took us numerous hours because as we were writing each one, we kept running into slight problems with omission errors and just fixings those errors took many hours. I've learned having a clear and complete design before going off and writing code would have helped us tremendously. I can honestly say that when I started to code, I went off in my usually "I'll think of it as I'm writing it" kind of mode. This eventually lead me to the "Oh, god. I'm going to kill myself soon..." mode.

With each section being so long and requiring many methods and variables here and there, I often found myself stuck with merging conflict with my partner who was right next to me or generally waiting for him to finish his side of the code. We decided that since it took so long to write each section, we would split the work up. This actually led to more problems because we all kind of just jumped right into the code. I'll remember to hold a meeting where we go through the design of the code before we actually implement it.

The last and most excruciating difficulty was loading the XML files with all the researchers, organizations, and collaborations. Not only was it difficult to find all the connections in general, we all decided to split up the work and had a horrible time trying to merge everything together. At 4 in the morning, after doing all the work over myself, I finally got everything to work while developing carpel-tunnel syndrome in places I never knew possible.

But alas, in my semi-delirious state, I write this blog as my final testament to finishing this code that practically store another weekend away from me. Hurt, but proud that I could finish such a monstrous task.

As for organizing the group and carrying out the work, we went about it in our normal way of choosing a starting position and coding our way to each other. This definitely was not the best way to carry out this task. A united front would have saved us much time. Deliberately holding out on the coding and planning everything ahead of time would have been the best solution. I have learned another lesson yet again, the hard way.

And here's my link to our program: http://myisern-1-green.googlecode.com/files/myisern-xml-1.2.1022.zip

22.MyISERN-1.1.Review

1. Installation Review:

I decided to review Hong Nguyen project because it was among the few left over, and because I worked with him at the library and I'm curious to see how his project came out. I was able to download the installation file from their code.google.com website with no problems. From there, I was able to launch the system without using ant or eclipse and even got a nifty help feature when I just called the jar file. I also got an error telling me that there were no arguments so I know that at least that part is error free. I was able to run the verify build task with no problem and it completed successfully. I was also able to run the program normally, calling all the tables finding certain researchers, and etc. with no problems at all. It was very easy to use the program normally because of the help file.

2. Code format and conventions review

I didn't really find any code format and convention errors. If I was to be really picky, then I would say that some of the parameter names could have been named better but the general meaning is still easily derived from the names that they have chosen.

3. Test case review

Black Box testing:
All the tests were successful and it seem like they have a test for pretty much every single scenario. What's important for black box testing is testing for omission and it seems like the tests are very complete in the sense that they cover every single viable input. Since this program simply prints out the information it contains, black box testing consists mostly of ensuring that the right information is outputted. This Hong's group was smart in creating fake files and making sure that the data was complete and true.

White Box testing:
For line coverage, EMMA came up with:
class 100%
method 100%
block 98%
line 98%

This is quite amazing since our group was only able to get to 96% for our block coverage. After looking at the code, I found that the coverage wasn't 100% because there were lines that could have only been passed through if there was an error within the XML files, an error with linking, or errors with duplicate values.

Break the buggah:
The program was able to handle all the input I could give it. I ran through all the different possible inputs and their erroneous versions as well. I tried to test for all the different cases of omission and misspelling. Since this program really doesn't do much then listing the information it has in the XML files, it's really easy to code so that it is not error prone.

4. Summary and Lessons Learned

For previous review assignments I was usually handed code that wasn't always complete or didn't have much or any testing at all, so this was a great learning experience. I learned a lot about black box testing and just what it is exactly. I learned that black box testing is used to ensure that the data that comes out was the "right" data and that there were no omission errors. What I've learned from reviewing Hong's group's code was that I should try to test for more. Hong' group tested to see if their code would work with erroneous XML data and I should have done that too because it not only tests to see if the linking is working but also tests to see if duplicates were caught or not. It would have also been good to test if the XML files were found at all and to send out an error if that occurred. Basically I learned to test for complete coverage over the whole system and not just the code. I can try and pass through every single line of code but I should also test that everything works from when you start the program and it looks for data file to the output being correct.

18.MyISERN-1.1

The only thing that was difficult about this assignment was trying to figure out how to link all the different fields together. After brainstorming for the first day, we all had different ideas about how to go about it. I thought about creating another class that would be a link to all three fields but we felt that it was too much work and too much thinking. Eventually, our mighty teacher, Philip Johnson, posted a different way to look at the problem. By using a map, we could keep each field in an array and used their unique ID as a key. This way each field had their own link to each other and we could reference them anywhere in the code. This was the method we decided to use for our code.
Other than that, there really weren’t too many problems. It was a very long and tedious job but because our group met everyday, we managed to complete the project early. I was actually out for most of the week because of some issues with my full time job outside of class and also due to a motorcycle accident on Wednesday but I was able to quickly catch up and help my team through this assignment.
As for carrying out the work, we splitting the group work would be a better idea than working through XP. Jon started out in the back end by working with the XML files and trying to develop the maps for each field, while I worked on the interface and built my way back. Jung also helped out here and there. I believe that the fact that my team got together everyday starting from Thursday really helped us to finish this project quick. With that said I can proudly say that we finished all the tasks and wrote some very robust code. I tried to make sure that there was no way to break the code at all.
For the next milestone date, I would really change much at all. I believe that the work ethic that I have right now with my team is probably the driving force that keeps our project done on time. If anything, the only thing I would really change is trying to make sure that I don't get into anymore motorcycle accidents.

link to file: http://myisern-1-green.googlecode.com/files/myisern-xml-1.1.1014.zip

16.MyIsernReview

1. Installation Review

I was able to download the program successfully from their code.google.com website with no problems. I also able to run the system using without using ant (using java -jar method) and was pleasantly surprised to see an actual window pop up with all the information in a neat table instead of the usual print out to dos. That was a very nice touch. It made things a lot easier to see and made it look very professional. After I ran the ant verify task and found that the coverage wasn't at 100% but aside from that all the other tasks went through fine and verify passed. After taking a look at the code, I found that the only reason EMMA wasn't at 100% was because of a catch statement in case something went wrong. Since was only had the file that we were given and here are no errors there, I don't expect the coverage not being at 100% a problem.

2. Code Format and Conventions Review

For once, I could not spot any code format or conventions violations. I actually spent the time to go through the Elements of Java Style book and looked for each format violation and couldn't find anything. Good job!

3. Test Case Review

Since this a simple application that just takes data from xml files and then converts them to Java usable files that can e displayed easily in a window there really isn't much to break. Hence, there was no other option that I could use to bring up the table other than actually calling it. As for black box testing, the same can pretty much be said. There isn't much that can be done for testing. The data comes from an xml file and is converted into something that can be used in Java. So as long as the data in the xml file matches the data that comes up on screen and runs then pretty all tests will pass. All the tests included follow along this line of thought. If any part of the program fails, an equivalent test fails as well.

As for white box testing, Phil's coverage is at 99% which might actually be better than 100% because his code include a catch statement that really can't be tested but will notify users of an error if anything does happen to go wrong.

As for breaking the code, since no arguments are passed when the program is called, anything written after the java -jar *.jar command is effectively ignored which is good and bad because it won't crash the program but the user doesn’t know that anything included in the call isn't used at all.

4. Summery

Phil has really gone above and beyond for this assignment. Where I just made sure the jar file was created and run an output the screen, Phil made a GUI that displays the information in a nice table. This program was a bit hard to test for because it was really hard to create a test for something that just prints information to the screen. Off the top of my head, I can only think of testing that the data is right during each step it is being converted. But at the same time, just looking at the output in general is about the same thing. If there is an error usually the error is apparent in the output, i.e. getting a block address instead of a name. I know that I didn't really put many tests other than just making sure the output was sent to the screen. But Phil actually has a few lines that test whether a few of the steps along the way also pass.

15.MyISERN-1.0-Green

link to MyISERN-1-Green: http://www2.hawaii.edu/~eykim/myisern-xml-1.0.1007.zip

JAXB: JAXB is a great tool to convert XML to Java, and vice-versa, and was very easy to use. Since everything was set up already, I didn't really learn too much about it but from the code that I did inspect, it seems like one of those tools that "just works." The one thing I needed to learn was how the marshaller and unmashaller worked, and from there I pretty much could tell that I could just pull information as I wanted. JAXB's marshaller and unmarshaller could be used to change XML data to a file and the data in the file was converted to a type: collaborations, organizations, or researchers from which I could pull information that was previously in XML format.

XML: With each assignment I start to learn more and more about XML. This assignment probably helped me the most because I wanted to go above and beyond and create a jar file that was command line executable. To do this, I really had to dig deep into all the previous assignments and see what I needed to do to create a jar file. It was pretty simple using the format of the previous assignments but I gained a deeper understanding of the file structure and formatting of XML. Before this, when I looked at the build file, it really looked like a jumbled mess. Now I look at it and I can see clear distinctions within the code, kind of like when you first start looking at Java or C++ code. It seems really fuzzy and confusing at first but with more practice and a common standard, everything starts to really make sense. I think I came away from this assignment with that sense of clarity.

Group Software Development: In previous ICS classes, working in groups really wasn't enforced too much. But in the real world, it seems like most of the time, you will be working with another person or probably an entire group of people trying to get a single project done. It's probably safe to say that more often then not; you will be working people in real life, so I really liked working in a group. My group tried to do Extreme programming and found that it was extremely helpful. We could get better code done in a shorter amount of time. We would often catch each others mistakes and sometimes find better ways of doing things. Although we only met twice and the second time our third partner wasn't there, we pretty much got the whole assignment done within those two meetings. We even tried doing SCRUM programming and at times that worked well too. I think each specific situation calls for its own programming method.

MISC.: One of the problems that I ran into during this whole process was waiting for people to catch up to me assignment wise. Since my other two partner didn't really finish the previous assignments completely, one more so than the other, it really took away at the amount of time we could have spent coding. Luckily, it gave me time to go set up all the pages for svn, discuss, and the google project hosting. Other than that, I think I had a great group and I feel a little sad that I'm going to be with other people. I just hope that I don't run into a lot of problems with the other groups.

14.CM.Practice

I was able to complete all three tasks although most of the tasks were easy; the last task specifically the google groups creation was quite confusing. I was able to install tortoiseSVN with no problems and aside from using https instead of http to commit; I really didn't have much problem with that task either. But with the third task, I was a bit confused with creating all these groups and the project hosting site as well. Creating the project hosting site was done with no problems but trying to configure and to find out the use of the google groups was a bit complicated. I wasn't exactly sure where to put the mailing lists and just how it all worked. Also having multiple tabs open and trying to get all the windows to accomplish single goals was a bit overwhelming as well.
I guess my lesson learned really was just getting used to using google groups and the whole idea of the mailing list. After I've run through the whole assignment and I getting everything to work, I have a better grip on just what each group is doing but I think I still need more practice to really have a firm grasp on it. I think after creating another group and running through the procedures over again will really solidify my hold on this subject.

12.Webspider Review

Program author: Jung Kim

1. Installation Review
I. Running software
Jung Kim's program pretty much worked "right out of the box." I was able to extract the file successfully, and I could import it with no problem.

II. Build tests

JUnit: It ran successfully.

CheckStyle: CheckStyle had one error.
"Using the '.*' form of import should be avoided - java.util.logging.*."
Upon looking at his code, he didn't even use this library so I deleted it and checkstyle ran fine.

PMD: It ran successfully.

FindBugs: It ran successfully.

Emma: Emma did not run at all.
The error that was found was "C:\webspider-kimjung-1.0.927\emma.build.xml:68: input file C:\webspider-kimjung-1.0.927\build\emma\coverage.xml does not exist." I believe the lack of JUnit tests caused an error in Emma so that it cannot run at all.

Verify: Build failed because of the Emma error.

III. Building the jar file
ant -f dist.build.xml worked fine and created another distribution. ant jar also worked and created just the jar file.

IV. Invocation
I was able to successfully invoke "java -jar webspider-kimjung.jar -totallinks http://www.hackystat.org 100." But it gave me a total of one link. When I looked into the code, I realized that he didn't change much at all. The code still looks at the page that it's given and returns the number of links on that page alone. It doesn't travel to any other pages and retrieve links.

2. Code Format Review

File	Lines	Violation	Comments
WebSpiderExample.java	7	ICS-SE-Java-2	Do not use wild cards in import statements.
WebSpiderExample.java	12, 43, 44, ...	EJS-33	Keep code and comments in sync

3. Test Case Review
There simply was no test cases. Not even a JUnit annotation was present. In order to break the program, all that's needed is to travel outside of the format originally given. So if I was to enter "java -jar webspider-kimjung.jar http://www.hackystat.org” I would get an array out of bound error. I also know that the last argument, which handles how many pages it need to travels till it stops, really does nothing at all. There is no ways to distinguish from -totallinks to -mostpopular nor is there any kind of logging available in the code. In the end, there really isn't much to review at all.

4. Summary
I really didn't learn much from this exercise at all. Seeing as Jung Kim's assignment didn't really leave me much to work with, I couldn't really learn much from this experience. The sum total number of things I did was 4. I fixed a checkstyle error, figured out that Emma won't run without any test to run on, read code that was basically unchanged, and wrote a blog. I really wish I could have learned something from this experience but after reading Randy Cox's blog, I generally understand the point that this lesson is trying to get across. I should not look at a program as being done until I've crossed over to the other side, users versus programmers, and actually try to run my program from that perspective. I should experience everything from first installing the package on a fresh system to actually trying to break the program as a user and not a programmer.

Although I did not get to really think much about black box or white box testing with this program, I do see the difference. After reading other people's blogs and experience, it seems like black box testing aligns more with the point of view of the user. You put in something and expect something to come out. If what comes out is not what you expect, then something wrong. On the other hand, white box testing is generally good for programmers that want to make sure all the methods are being executed. If a code doesn't have 100% coverage, then you know that one of you methods, catch statements, etc. aren't being used. This helps to write more tests and eventually have a more robust code.