The Final Hurrah, but I won't stop

It took me awhile to think of a title, but this will do after my brain just got fried. This is the final hurrah for the semester, but this does not mean that I am at the end of my journey. Before I talk about my journey, I want to go over my final project.
As a team of four, our project goal was to implement our DueDates 2.0 with Wicket to create a web application for library books. Given two weeks to complete the project, we decided to spend the first few days getting acquainted with Ronn's DueDates 2.0 code and also assigning issues so that we all know what our focus is. Our project started to get rolling once we started meeting up and coding. We made great progress and we expected our project to be done by Friday, but a small road block became the Great Wall of China for us. Everything in the back end of the project seems to be complete, but connecting that with wicket was painful. Ronn was the one who tried to tackle this issue, but it was out fault for not being able to back him up when he needed us.

I think failing this project was the best thing for me. If this project had run smoothly, I would have not learned so much from my team and from myself. Coming into this project, I knew that I was the weakest link (Goodbye). Learning from my previous group (Violet), I built upon my mistakes and tried my best. As a group, we met almost everyday at Sinclair Library to program with each other for a few hours. This really helped us in keeping each other up to date and to resolve and issues quickly. During this project, I went to Ronn a lot because I saw him as the strongest one in the group. I learned a great deal with Ronn's help and I'm truly grateful for his patience. From the group, I was blessed with their great code. I've seen coding tricks that I have never seen before and styles that are more clean and friendly to future hackers on our project.

Over all, we worked well as a group. We all worked our fair share and what was asked of us. There are small issues with merge conflicts, but we resolve it quickly since we programmed together majority of the time. This was due to our willingness to meet with each other everyday for a few hours. The only problem we had was the wicket and how we assigned issues. By dividing the program, we lose sight of the big picture sometimes.

This is the end of our project and a small part of me feels sad that I won't be able to program with Ronn, Creighton, and John. I enjoyed hacking away with these guys even though the project was painful. I am graduating this winter and I am so lucky to learn so much from this group. I'm slowly hacking away at my "program" and I feel that I just knocked down a huge issue.

I'm going in to Relapse

Overview:
Given Philip Johnson's Stack project, I am given the task to set up a html page using Wicket. This page should implement the Stack by displaying a text field and three buttons. The three buttons are Push, Pop, and Clear. The page should also have personal session so that others can not interfere with each other's stack. More information on Wicket can be found at:
here

Process:
This is an individual project, but lucky the examples I received was very helpful. Using the examples, I was able to set up the basic Stack function. Unfortunately I was unable to finish the Session part of the project.

Reaction:
I greatly underestimated the project. At first I thought that I can finish it easily with the example and the book. I fell a little relapse in terms of how I felt before programming and my over confidence. As I started programming, all the little things started to wear me down. Things like setting up the classpath to correcting the Index Out of Bound Errors when trying to display an empty array in the first instance. I need to wake up from all this and rediscover the fire in me to succeed.


My Project:
here

Local Tech Companies

Yesterday, I attended UH's annual ICS Industry Day event. This event provides ICS students the opportunity to meet with local tech companies and to see what they are looking for in graduates. As a soon to be graduate, I was fortunate to hear presentations from Oceanit, Alion, Referentia, and DataHouse.
My first impression of tech companies was that of a very structured and programming intensive environment. All I can imagine was cubicals with people glued to monitors. Another impression I had was high expectations and zero failure. Lucky for me, I gained a better outlook after attending the event and listening to the speakers.
The first thing I notices was how friendly and passionate these people were. They seemed very down to earth and willing to train and promote growth and creativity. The next thing I notices was how important Johnson's class is to me. Everything I learned in Johnson's class can be used in these companies. From things like quality programming to subversion, I understood what these companies were looking for instead of worrying about being lost.
This has been a great experience for because I gained a better understanding of what Hawaii can offer. I always believed that mainland was the only option for me after I graduate, but these companies showed me that there are great opportunities right here.

What, my timers up?

Overview:
Console, email, and timer. These are the new functions we need to add to our project. Sounds hard, but its actually not that bad. The console and email are the two functions to control how the output are given to the user. The timer sets the program on a repeat depending on the time period the user gives.

Process:
As a group, I was in charge of the email and documentation and Anthony focused on the timer and parser. As I started work on JavaMail, I realized that it was harder for me to set it up then for me to use it. The documentation and example made it easy for me to start sending out spam to myself. With the class created, I started working on the documentations and guide.
AS we reached the home stretch, I looked into tasktimer to help get a simple sample into our code. The only thing left is to add to the parsing and to call or use the code I made.

Reaction:
In the end, it seems like we ran out of time. We still did not learn our lesson and it has finally caught up to us. We will continue to work on the project till the last minute, but the mood seems dire.

Send me to the ICU

Overview:
Santa came early and gave me new toys again. This time I got JavaNCSS, DependencyFinder, SCLC, and Hackystat. These new toys help monitor my project's health by connecting sensors to all the vital parts and giving me a daily report. In order to play with these toys, I had to configure my computer and Hudson to call on the sensors.

Results:
It took me awhile, but I finally got everything set up. The results from the sensors showed that me and Anthony's project is healthy. The only yellow we have is under coverage, but it is going to be green because we added more coverage testing. Hudson in the beginning had us listed as Thunderstorm because I had some issue with the build. In the end I went through everything to find that I simply forgot to see one configuration in Hudson. Once that was fixed, my mood followed our project's weather. These little hiccups are good in helping me build my confidence in solving any problem I see. At times, I really wanted to go to ICU because the problems can come from anything. Since everything was new, I ended up redoing everything to find the problem.

Rush to the Finish

Overview:
Another week and another rush to finish. Who would have thought little features like sort and within would be so much problem. Along with adding those two new features, we had to add the Hawaii State Library System as another library we can access. Lucky a time extension was given to let us sleep a extra night.

Process:
Communication was good in the beginning. We met up at Hamilton Library for a few hours and we got a lot of work done, but things turned fuzzy after that. Because of our busy schedules, we were limited to only Instant Messaging and Aim. We tried to schedule another meeting, but things came up so we had to cancel it. For me, it was hard for me to program since I did not know how the design was going to be. For example, I would be sitting in front of the computer reading Anthony's message and designing how the Library file will parse the sort and within parameters and then I see that Anthony created a robust parsing file. I end up retracing the program and frustrated that I was unable to help.

Results:
We completed the project with all the requirements needed. Our project automatically sorts the results by Library and the user can sort the books by due date. Both library systems are working and the within feature works fine. Continuous Integration is a very fun tool. It's like another person watching our submits and waiting to give us a red mark when we forget to verify.

Reflection:
I think the one thing that can improve my effectiveness would be to find more time to meet up face to face to program. Aim and email does not seem to work to well with me and I was able to see a major difference between me working alone and me working with my partner side by side. That is the optimal view, but I also need to improve my communication skills over the internet so that I can be more productive when I'm at home.

Self Reflection on Review

Overview:
As a team, me and Anthony are given the task to review another team's code. We need to help them test if we are able to download their code and configure our system to be able to start developing. Because we are developing an open source application, it is very important for our code to be robust and easy to set up for future development by other programmers.

Review:
It has always been hard for me to give a review because I would have to criticize their code and point out their flaws in design. I also run into uncertainty because I am reviewing code that are in the middle of development. Since I am not in their group, I would not no their goals and I would be wrong with my review. When I was reviewing purple's code, I felt really back because I was unable to get the code working. In my mind, I believe that it should be working and the fault was with me. I ended up not being able to run their code in Eclipse, so I just traced the code to help review other parts of the code.
After doing the review, I talked to Anthony and I was surprised that we both gave the same review. I guess because we worked together on our code, their design thoughts were the same. It was also nice to know that I was not the only one having problems getting their code to work. Looking at Purple's code also gave us ideas on how to solve our problems.

By Our Powers Combined

Overview:
To expand our experience, I will be review three other teams code. I hope that by looking at their code, I will see how other people solve the same problem I had. During projects, we often base our solution on our current tools and knowledge. In return for review other team's code, our code are also reviewed by others to give us helpful tips on improvement.

Reaction:
When I review other people's code, I notice that 1 hour is not enough because of what we are asked to do. Following the User and Developer Guide can sometimes be a problem and the only what I was able complete a review is because I have first hand experience when setting up my own project. Another important key I notice was how groups priorities their task and set their goals. Some focus on creating expandability while others focused on the user experience. As a programmer, I was mostly drawn to the structure of the project. Because this is an ongoing project, creating classes to ease future development is important. There were a lot of small things me and my partner Anthony Du over looked. Review other people project reminded me of taking a step back and looking at the big picture.

Putting our Tools to the Test

Overview:
Now that I have all these tools in software development, the next step would be to test it. To test how effective I will be, I will be partnering up with Anthony Du in creating a program. The goal of this program is to help users quickly obtain a listing of all the books they are currently borrowing. Because this is in the beginning stages, the user will be using the command prompt to access the UHM Library and Hawaii State Library system. We hope to expand this to other library systems and to create a more user friendly interface.

Procedure:
This is pretty straight forward. Develop the code Philip Johnson gave us and create User and Developer guides. As a team, we need to create daily objectives to meet our goal in one week. This also helps with splitting the work load and to promote better teamwork.

Reaction:
It's amazing how fast time flies in a week. We tried to meet up early to give ourselves more time to work on it, but that ended up being a weekend programming marathon. Personally, I still have some problems starting the project. A little bit of fear and procrastination is enough to keep me from starting till I absolutely need too. The fear factor has gone down because I'm starting to enjoy solving these bugs. Google has amazingly pulled me through on this project without a problem. The only thing that makes me want to pull my hair out is the collisions me and Anthony face in submitting our code. It has almost come down to a horse race in submitting first so I don't have to fix the merge. I also have to admit that I sometimes forget to verify before Committing. Thankfully, the project was small enough that it did not hurt that much to fix it. In order to work around to constant merging collision, we decided to work on different parts of the project to minimize the time in reviewing and merging the code. Following is an image of the worst thing I saw this weekend:

Part 2 of SVN and Google Project Hosting

Overview:
After becoming familiar with SVN and Google Project Hosting, I will be working with a partner in sharing and editing each others code. This will simulate a small scale of what program development will be like. By practicing how to use SVN effectively, future program developments will run much smoothly.

Procedure:
With the Google Project I created earlier, I will invite my partner, Robin Raqueno, as a member. Being a member means that he can have access to the stack program I uploaded and the ability to make changes to it. In return I will be given access to his code to review and make changes if needed. Once corrections have been made to our partner's code, we can then commit it to Google Project Hosting to update the trunk.

Review:
This excercise was every useful for me because my partner was able to find errors in my code that I over looked. He was able to email me and we both corrected my problems. The only problem I had was when I tried to commit the corrections I made. I got an error message saying that the code was in conflict. Then I remember that I had to update and merge before I can commit again. Turn around time on fixing code was much faster to because I did not have to wait for my partner to send me the code he fixed and we both will always have a working set of code on Google Project Hosting and all the revisions.

New Experiences with SVN and Google Project Hosting

Overview:
This week, I will be taking a first hand look into SVN by using TortoiseSVN and Google Project Hosting. SVN is a version control software that aids programmers in software development by allowing everyone in the project to concurrently update and make changes to the code. This also keeps a history of all changes so projects can be reverted if there are major bugs found. By getting familiar with the software, I will be able to increase productivity and reduce collisions during development.

Procedure:
The first task that I should complete is to install TortoiseSVN and read the directions and how it works. Once I become familiar with TortoiseSVN I should connect and modify an existing project of Google Project Hosting. My target would be stack-johnson. Once I download all hte files for the project, I should make some "improvements", run verify to make sure it still runs, and then commit the changes. The third task would be to create my own Google Project Hosting to see how it can be customized.

Conclusion:
SVN seems to be one of the most useful tools I have learned so far. Before this, the only concept in programming as a group would be to split the work into coding and documentation or to code one person at a time. This was always time consuming because one person would be waiting for the other person to finish before starting. It is also very helpful with the code being hosted online so that it would be easier with different work schedules.

Limitations of Coverage Testing

Overview:
As a continuation of the coverage testing for the Stack program, I will now look for flaws in this type of testing. Because coverage testing only checks to see if you tested every line, it does not fully test the logic behind each line. To build upon my 100% coverage testing on the Stack program, I will edit the testing or the Stack program to show a major bug while maintaining the 100% coverage. This new bug can be demonstrated with a new test I create.

Procedure:
As I think of ways to create a major bug that coverage testing can not detect, Philip Johnson gave us an example where if we set a limit on the array size, we can create a bug if we push to much. As I looked more into JUnit and Coverage testing, I can see that I just have to change the logic and return variable to show a bug. I decided to hard code the return string for toString in Stack.java to work around the coverage test. A test class "testLimit" has been created to show this bug in testStack.java.

Conclusion:
This exercise showed me that coverage testing is not enough to find all bugs in a program. There needs to be thorough testing instead of just aiming for 100% coverage. All coverage can tell you is if you missed a method, line, or block in testing.

Distribution file

Review on StackOverFlow

Overview:
This week I took a look at this programming website (http://stackoverflow.com/) and I tried to see what is the purpose of this website and how it can benefit me. As I continue to learn about all the available resources and tools in programming, I need to evaluate and note down those that are helpful for me currently and those that can help me in the future. StackOverFlow is a simple website that follows the same concept as (www.digg.com) and (www.reddit.com) where users can post information and others can rate it up or down and post comments. StackOverFlow takes this and message board concept to provide users with access to many other helpful programmers.

The interface is pretty straight forward. Questions are listed by the date it was posted and there are counts on views and replies. The questions can also be categorized by subject which is helpful when looking for questions and answers that you may have. Reputation is also a nice feature to allow people to see who are knowledgeable in each subject. I particularly love the user profile because it gives a history of all the questions and answers a person has given.

Conclusion:
StackOverFlow seems to be a very useful tool for those that are stuck and need a push. A good reputation on this website can also help improve ones professional persona. I would recommend it to friends to browser through when there are down times to learn more. I would use it to help broaden my knowledge and to find answers to specific questions.

Ant, PMD, FindBugs, and Checkstyle

Overview:
With the introduction of Ant, PMD, Findbugs, and Checkstyle, we are given the task to test these new tools and to observer the different types of errors we can get. The stack code comes with a few errors to show us how errors are displayed and resolved.

Reaction:
There has always been a sense of fear when I think about programming and it becomes more apparent when I'm faced with more complex issues. I always attribute my poor work habits towards my procrastination and this fear. It is very demoralizing for me when I hit a brick wall and I'm resorted to asking for help. I am starting to feel more comfortable with programming now because the only what I can remove this fear is to work on programming more.
This exercise took me around four hours complete in a spread of two days. There were a few issues with ant not seeing my environment variables, but I was able to resolve it by deleting and re-adding the variables. The corrections in stack was fairly easy, except for the pmd error. I had to google more into Set interface because the example given was unclear for me. I had to walk away from the computer a few times to reset my brain, but in the end I was able to complete all three tasks.
Corrected Stack

CodeRuler

Overview:
After going over everyone’s CodeRuler code in class, we are given the task to example another team’s code to find any inconsistency with the coding standard of “The Elements of Java Style” and “ICS-SE-Java”. By examining other team’s code, I would be able to point out proper coding faster and to learn how others solve the same problem.

Review:
The JavaDocs in Kaneshige and Ly's code are clear and concise. It gives a short explanation of what the code does for each class or method. It helped me locate the exact code that controls the knights, peasants, and production. The methods are created and listed in a logical matter following the author’s hierarchy.

Conclusion:
Over all, the code was nice and clear. The strategy for the decoy peasants is clever and effective for simple “hack and slash” strategy. Production strategy seems to run into problems if the enemy goes after the peasants first. One thing that particularly caught my eye was when I was looking for improper coding format. I was able to see two distinct style of coding. For short codes, this would not matter, but I can see the importance of following one style when there are larger codes to review.

File	Lines	Violation	Comments
MyRuler.java	7	EJS-46	@author and @version
MyRuler.java	20, 54, 131, *	EJS-56	Documentation on precondition and post condition
MyRuler.java	15, 18	EJS-62	End line comment
MyRuler.java	49, 50, 51, *	EJS-64	Label highly nested structures
MyRuler.java	59	EJS-69	Smaller methods
MyRuler.java	105, 114, 148, *	EJS-5	Else statement should be on new line

New Beginning

Welcome to my blog.
I hope you will enjoy this journey with me as I develop my software engineering skills. This blog will mainly focus on the projects and experiences I have in ICS 413. I am excited in expanding my portfolio and learning new things to expand my set of software engineering tools.

The first assignment for the class is to program a simple Java function called FizzBuzz. This function will count from 1 to 100. If the number is a multiple of three, I should print out "Fizz". If the number is a multiple of five, I should print out "Buzz". If the number is a multiple of both three and five, I should print out "FizzBuzz". And finally, if the number does not fit any of the above it will just print the number.

The purpose of the assignment is to brush up on our Java skills because our use of Java are very limited after ICS 211. By refocusing on Java, we can build upon our foundation and to experience software engineering in a larger scale.

After installing Eclipse, I went through the short tutorial and started programming FizzBuzz. I mainly used Notepad++ when coding and I can see the big difference immediately. It was very nice for Eclipse to set up all the classes for me and to watch all my brackets. The only problem I have so far was to locate the compile/run button. Everything was straight forward and I'm looking forward to finding more tools in Eclipse to use.


public class FizzBuzz {

/**
* @param args
*/
public static void FizzBuzzFunction (int n){
for(int i = 0; i <= n; i++){
if((i % 3 == 0) && (i % 5 == 0)){
System.out.println("FizzBuzz");
}
else{
if(i % 3 == 0){
System.out.println("Fizz");
}
else{
if(i % 5 == 0){
System.out.println("Buzz");
}
else{
System.out.println("" +i);
}
}
}
}
}

public static void main(String[] args) {
// TODO Auto-generated method stub
FizzBuzzFunction(100);
}
}