Peer Review: Take 2!

With the recent project that we're been working on, we have been doing a peer review after the completion of version 1. So now, after completing version 1 of our OscarWebApp "greenometer", we are once again task to review another group's project. As for me, I was task to review the Ecologineer project. Please click on the link to see my full report.

Wicket + Wattdepot = Green web

This week, we were introduced to a java web application framework called Wicket. We were task to use wicket and our wattdepot project to create a web page that shows and classifies the carbon intensity for a given day(24 hours), similar to the Ecotricity UK Grid Live website. The goal of this task was to introduce us to the simple web application development using wicket, to further our experience with the use of Software ICU, and gain experience with using Google Issue system.

At first, Wicket seems really complicated considering that I wasn't that experienced with HTML and was a bit rusty in java. But after reading the first few chapters of Wicket in Action and doing some of the examples in the book, It started to look less complicated.

As we start this project, communication was a bit of a problem. I guess it was a bit hard to get 4 people together with different time availabilities. So most of our communicating was thru email, google chat, and AIM. Kelvin, one of our team member took charge and design the ground work of the project while everyone help to edit and improve it. We didnt really use the google issue system because with only 4 members, it was easier to just send email or instants messages to keep everyone updated but i think we should begin to use it so we can get use to it for larger projects with more members. For improvements, we could have a better communication methods and distribution of task. But we manage to accomplish all the given tasks.

To get a copy of the our greenometer, Just click on the link and select either the Zip file or Jar file to download. You can follow the User Guide to install the program and get it running.

Below is a screenshot of the Software ICU data for the last 7 days...

Wattdepot-CLI take 2

This week, we were given a second chance to fix whatever bugs we have with my Wattdepot-cli project in addition of adding 3 new commands to our existing project. This was a great opportunity for us to used what we've learned from the peer review last week and apply it to our project. I think the our project satisfies all the requirements given in Command Specification page.

As for fixing all the problems that was raised by our reviewers, we did not fix the console bug in using eclipse but we will inform the reviewers that I must be ran in the command prompt. This week, we focused more on designing higher quality test cases and overall improvement of the design.

As a result, posted below is our emma coverage report:
[concat] Emma Coverage summary
[concat] class: 100% (27/27)
[concat] method: 96% (74/77)
[concat] block: 86% (3538/4098)
[concat] line: 78% (668.4/860)

We communicate with each other mainly through email and instant messaging with the occasional meetings before and during class. We tried our best to distribute the work load evenly, but my lack of java programming has made my partner carry more of the wieght.

To help us monitor our work progress, we have installed the SoftwareICU which is a tool to help monitor our progress. It also display infomation on coverage, complexity, coupling, churn, and more. posted below is a screenshot of our last 7-day

In testing to see if our commands are working properly, we were tasked to answer a few question:
What day and time during the month was Oahu energy usage at its highest?
Nov 28th 02:45:00.00-10:00
How many MW was this?
995 MW
What day and time during the month was Oahu energy usage at its lowest?
Nov 26th 20:00:00.00-10:00
How many MW was this?
496 MW
What day during the month did Oahu consume the most energy?
Nov 28th
How many MWh was this?
995 MW
What day during the month did Oahu consume the least energy?
Nov 26th
How many MWh was this?
496 MW
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)?
Nov 4th
How many lbs of carbon were emitted?
29,959 lbs
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)?
Nov 7th
How many lbs of carbon were emitted?
22,908 lbs

To download a copy of our project, please go to this page and download the wattdepot-cli-umikumakahi-2.0.1116.zip file.

Peer review: Having more sets of eyes

After doing the peer review, it made me realized that I need to change the way that I write programs. As I've notice from the two other systems that I've reviewed, there wasn't any testing done at all and require a bit more error handling. Maybe because we're still in school and the first thing we think about is completing the required task first to do what it's intended to do. Since a program that is incomplete will receive a worser grade. We will definitely have to change this mentality once we get into the real working world.

During the meeting, I felt a bit of awkwardness when it came to giving critiques to peers face-to-face. As I'm not sure how they would take my critiques and they probably think the same way. But once we got the ball rolling, it went really smooth as each team was eager to hear how they can improve their codes. It's almost like a teaching and learning experience all in one.

Majority of the critiques that we received had the same issues. They were able to get it to work with the Eclipse IDE, so they couldn't test the codes.We did all of the testing for our program in the command prompt so we didn't know it couldn't compile in Eclipse. When I try running it in Eclipse, I received a NullPointerException, it have to do with us using the "console.readline" to read user input. Other critiques were that we needed more comments to make our code easier to understand. We will be working on these issues and hopefully get it all fixed back this week.

Over all, This peer review was a great experience and an eye-opener for the ways we program.

Code Review: Help yourself by helping your peers

After working a week on creating the command line interface for the Wattdepot project, we now begin a process called "Code Review". Our code review is an informal peer review consisting of peers examining each others source codes to find mistakes and possible improvements to their quality of their work, thus improving our own skills as a developer. We were each assign 2 other team's code to review. I will be doing my review on team "Umi" and "Umikumalua" codes which can be found here.

Team Umi:
Team Umi's system was well design with all commands working as intended. There were only a few minor error which could be easily fixed. Their javadocs were a bit brief but descriptive. One major thing they can work in is making test cases for each command. Here is my full review on Team Umi's system.

Team Umikumalua:
Team Umikumakahi's system competed most of the commands with a few not working as intended (chart, source summary). The javadoc were good but might have to work on some consistency between different authors. Things they can work on is making the remaining command work as intended, add more error messages, and make test cases for the commands. Here is my full review on Team UmiKumakahi's system.

Wattdepot: puts you in command

As you all know, we got a new task this week for our Software Engineering class. We started our new project working with WattDepot, a program that collects and stores data on power consumption. With this tool, we are capable of retrieve the data, analyze it, and output it to a chart. This program would be extremely useful for smart consumers to monitor their power consumption. (But for this project, we are currently working with simulated data)

This was our first task that was done in a group. The task was to create a Command Line Interface for this project which will allow users to issue commands listed on the CommandSpecificationpage. Programming has never been one of my strong points. Working in a group has allowed me to learn better programming from my partner and improve my java programming skills. I was lucky enough to a partner that was knowledgeable in Java and patient in helping me to understand the codes. My partner contributed a lot more than I have in this project, Which mean I definitely have to improve on my programming skills to catch up with everyone.

Major problems that we're encounter were satisfying Checkstyle, PMD, and FindBug. To satisfy these criteria, we had to change a lot of the codes to codes that we're less familiar with, which was quite frustrating but a good learning experience. Unfortunately we were unable to create test cases to test each command due to time constraints.

If you want to take a look at our code for the Command Line Interface, you can find it in this list. Our group is umikumakahi...

Hudson, a continuous secondary check...

If you wondering what Hudson is, it is a a popular open source continuous integration server. We were introduced to Hudson for our first group project in creating a command line interface for the WattDepot project. Continuous integration is great for group work where you want to ensure that the code quality and standards are consistent throughout the whole development process. It can assist teams with software build automation, continuous automated build verification, build testing, and post-buuild procedure automation.



When we began to setup the job in the Hudson server, we were having some connection issues. It was really slow in connecting and there were time where I couldn't load the page up at all. But when it was back up and running, creating the job as a cinch. We were enabled to sync our project with the Hudson server through the use of SVN. So now whenever a member commits new code, Hudson will do a verify test just like the ones we do with ANT, and if it fails the build, it's setup to send emails to the whole discussion group. Isn't it a nifty tool to have? I was quite impress with it. The only drawback that I've experience with this tool so far is the connection problem. As I'm typing this blog, I'm not able to connect to our Hudson project page to get a screenshot of it. I'm not sure what's causing this issue but I hope it'll get resolve soon.

Quickie Questions for a Quicky "A".

Here are some questions that could help you study for the upcoming midterm.

1. In the "Getting Answers" guide, 10 strategies were given. List 3 of these strategies.

A. Explain what doesn't work
   Provide Everything up-front
   Post your code
   Do your research beforehand
   Do your research during
   Do your research afterwards
   Don't post the same question repeatedly
   Follow up after you get an answer
   Treat the list like people
   Always consider the answer
  
2. Give one good and one bad example of a post to ask for answers. (include subject line and body).
A. (Bad) 
   Subject: Help, Code not working!!!
   Body: Ahhhh... I cant get my code to work... Please help me ASAP

   (Good)
   Subject: Roboode Junit test error: "robocode home not set"
   Body: I received this error while trying to run a Junit test on my robocode project. 
         I need to set the robocode home path but I dont know how to set it in Eclipse. 
         Could someone please tell me where i can set this path in Eclipse. 
         Thank you.  
         attached is my code and my file path.
   

3. what is the difference between foo.equals(bar) and foo == bar?
A. foo.equals(bar) is true when their values are the same but could be in different memory location
   foo==bar is true only if they are in the same memory location

4. Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" 
instead of the number and for the multiples of five print "Buzz". 
For numbers which are multiples of both three and five print "FizzBuzz".
A.
public class FizzBuzz{
  public static void main(String [] args){
    for (int i = 1; i <= 100; i++){
      if (i % 15 == 0){
        System.out.print("FizzBuzz");
      }
      else if (i % 3 == 0){
        System.out.print("Fizz");
      }
      else if (i % 5 == 0){
        System.out.print("Buzz");
      }
      else{
        System.out.print(i);
      }
         
    }
  }
}

5. Find a violation of checkstyle and findbug in the code below.

  public void xFire(double robotDistance) {
    if (robotDistance > 400) {
      doNothing();
    }
    else if (robotDistance > 200) 
      fire(1);
    
    else if (robotDistance > 100) {
      fire(2)
    }
    else if (robotDistance > 50) {
      fire(3);
    }
  }

A. Checkstyle: missing "{}" on first else if.   
   Findbug: missing ";" inside second else if.

6. Why did our RoboCode not follow the coding standard of being within the package hierachy "edu.hawaii" ?
A. this standard may be superceded by "adhere to the style of the original", as in the case of RoboCode.

7. In the antipattern article, what is the "Happy path test"?
A. A happy path test is a test within boundaries, pretty testing something that you know will pass.

8. What is the difference between white box testing and black box testing?
A. White box testing uses an internal perspective of the system to design test cases based on internal structure while Black box testing takes an external perspective of the test object to derive test cases.


9. What is the benefit of using a coverage tool?
A. It make sure that the program is performing normally; producing expected results with the smallest number of errors. Also shows you which line is being executed and if it contains errors or not.


10. What is the goal of GNU and what foundation did they create to help reach that goal?
A. The goal of GNU was to give users freedom, freedom to run the program, copy the program, modify the program, and distribute modified versions. They created the Free Software Foundation

Google hosting with express SVN checkout

For our final chapter in our robocode project, we got to create our own google project and discussion group. Yes, it might not sound like a fun thing to do, but rest assure that knowing how to do this will make collaboration on future projects a breeze.

Following the instructions from our professor, we managed to host our own project on google and create a discussion group to support our project. Being the owner of the project, we could select who to invite to be our members and give them access to our project. Couple that with a SVN program such as SmartSVN for Mac users or tortoiseSVN for PC, members can check out the project, make modifications to it, and upload it back to the project site with the new modifications. With this, everyone can work on the same project without having to be in the same place. Now isn't this a great thing to know.

With the instructions given, I didn't have much problem completing the tasks. The only hiccup that I ran into was adding codesite-noreply@google.com as a discussion list member. Following the link given by our instructor, I made a posting on googles support site and the moderator was able to give us a quick solution.

Please be sure that you understand that I am *not* adding 
codesite-noreply@google.com to your mailing list.  
Instead, I am changing your project so that it send 
email From: PROJECTNAME@googlecode.com.  
It is then up to you to subscribe that email address 
to your mailing list (if it only allows posts from members).

I've added our discussion list "robocode-aak-sidestep-discuss@googlegroups.com" to receive notification of any new changes/commits, but I didn't receive receive a notification email. Maybe I'm doing it wrong.

Something that I've learned from this is the usefulness of google project and SVN is. I've used google docs to share documents among group members before, but this is taking it to a different level.

Here are the links to my project page and my discussion group page.

Improved Junit testing With Help From Emma

So last week, we were introduced to Ant and Ivy which are great Quality Assurance tools. This week we go even further into QA by writing our own test cases and testing them with Junit. Why do test case, you asked? well, so far with Ant and Ivy, we're checked to see if our code is within a certain coding standard, that it'll compile with no error, and a simple test case to see if it'll beat SittingDuck. But we haven't test it to see if it does what its suppose to do. That's where you'll need the additional test case.

There were three types of test case that we have to write and test our robots with. They are acceptance (if the robot can consistently beat it's target), behavioral (verify that the robot satisfies a component of the strategy), and unit (verify that individual methods calculate the correct value) tests. The acceptance test were quite easy since our professor gave us an example of it which was tested against SittingDuck. By making a modification to the code changing the target robot name, I was able to create 2 new acceptance test case for my robot (SideStep) to go against Crazy and Walls. Both test passed via Eclipse and Ant, which was great considering that I had the hardest time getting Junit to work in Eclipse. ( After many fail attempts, I finally deleted Eclipse and reinstalled it and somehow Junit is working now with the same configuration that I used with the old one).

For the behavioral test, I created one that would test to see if my robot would fire only if the target is within 400 pixels. First off, writing test code was a lot harder than writing the actual code. I couldn't figure out how to call methods from other classes that I used in the actual code. After writing the test code by trail and error, it was able to pass the Junit test. Junit is still very new to me and I will probably need more time to look into it. But due to time constraints from my other classes (projects and exams) this week, I didn't have enough time into reading up on it, which I'll probably do over the remainder of this week.

Even with the help of Emma, I'm only about 50% sure that I'm testing the right thing. Emma is a great tool which outputs a html file that shows which line in the code it is testing and shows if the line fail or pass the test. I will continue this assignment through the rest of this week and will update this post with new test cases and discoveries.

Here is the code for my robot including its test cases.

SideStep Steps up with Better QA

After suffering a tragic defeat at the Robocode Tournament last week. I was determine to return victorious for the next tournament. As you all know, my robot (SideStep) was able to consistently beat all but one of the 8 sample robots, which was pretty good. But ironically, most of my classmates modeled their robots off that ONE robot(Walls) that it can't beat. Hence forcing me to revise my robot....

Luckily this week we're learning about Quality Assurance using Ant and Ivy build system. These build system are great tools for almost any programmer. It consolidate a bunch of automated quality tools such as Checkstyle, FindBugs, and PMD all in one. Using these tools will cut out a lot of time spend searching for errors in your code and proof reading for formatting errors.

To perform the automated quality assurance on our project we had to invoke the following commands:

• ant -f checkstyle.build.xml
  
• ant -f pmd.build.xml
  
• ant -f findbugs.build.xml
  

After running these commands, checkstyle was the only one that returned with errors.

Missing package-info-.java file. line 0 (1 error)
Missing a Javadoc comment. (5 error)
*After fixing errors above*
First sentence should end with a period. (1 error)
Expected @param tag for "robotDistance". (1 error)

Most of the error were in the javadoc comments, since none of my previous course ever stress on it. I've never ran into a missing package-info-.java file error before and had no clue what it is. After looking at the sample project giving by our professor, I realized that I was missing a package.html file which I later created and the error was fixed.

These tools helped my immensely because I was constantly hacking up my codes conducting trail and error in attempt to beat Walls. After many fail attempts I've realize why I was losing to it. It was because I would use up all my energy moving and firing it ending up being disabled. I didn't work to change the movement or velocity because that was the bread and butter of my robot. So I decide to lower the firepower of the bullets, and voila. Walls ends up being disabled before mine does and it becomes a sitting duck.

Now, I'll just wait patiently to see what improvements the my "Walls" competition made.
If you want to see source code, you can click SideStep v. 1.1.

A robot that'll side step the competition...

As you all know by now from reading my recent blogs, we're been working with RoboCode these pass weeks. As this project comes near the end, we're task to design a robot that will not just beat the 8 sample programs that came along with the program, but also the robots design by our fellow classmates. To beat all the sample robots is no easy task considering that some of their movements and tactics are completely opposite, such as Walls and RamFire. Here is a brief overview of my design:

Movement: Movement is the most important part of this design. In order to beat the 8 sample robots, it had to be able to out maneuver them. I wanted to keep my robot at a certain range away from the enemy robot, where it can chose between different firepower. This is extremely useful when dealing with robots that have a fixed firepower. To get to this certain range, it goes in a diagonal pattern so it avoids majority of the incoming bullets. And when dealing with bots that charges or gets extremely close, it backs off a bit and side steps the enemy. With this design, I was able to keep away from enemies that charges in, and get close to enemies that runs around or away.

Targeting: For target, I used codes from one of the sample robots written by Mathew A. Nelson. It allows the gun to follow the enemy during the onScannedRobot. This is a lot faster than turning the whole robot with a stationary gun.

Firing: For firing, I used a modified version of the smartFire method in the Corner robot. This allow me to adjust the robot's firepower with it's distance away from the enemy. A very useful strategy to conserve energy, and attack enemies with fixed firepower.

Now that you know what the basic design of my robot does, Here are the results from battling the 8 sample robot. To test my robot, I did a 100 rounds against each of the robots.

SittingDuck: Win: 100/100
Fire: Win: 100/100
Corners: Win: 100/100
Tracker: Win: 96 /100
RamFire: Win: 90 /100
Crazy: Win: 97 /100
SpinBot: Win: 67 /100
Walls: Win: 34 /100

As you can see from my result, it didn't do so well against Walls and SpinBot, I knew from the start that these 2 robots would be the hardest to beat. Going up against these 2 robots with my design is seeing how lucky I am at dodging their bullets. I ran a few more test with SpinBot and Walls and the result fluctuate between 50-75% for SpinBot and 25%-40% on Walls. It's not the best design but it's the best that I can come up with at the moment.

I have to admit, I did do some googling to see what the strategies were for some of the advance robots. You know, just to get the feel and some ideas for similar strategies. but the implementation for some of the strategies that I found were way too complicated for me to understand. So I used a simplified version of the "chicken" strategy that I found. Instead of hiding behind other robots, it simply moves back and to the side as the enemy comes close. I know this is just the tip of the iceberg for RoboCode and for Java programming. Hopefully with time, I'll be able to explore deeper into this iceberg.

To download my source code for this SideStep Robot, Please click Here!

Simple Samples, Learn by Examples

So to increase our knowledge of RoboCode and give us some strategic ideas, we were tasked to review the codes for some of the sample robots that came with the RoboCode Installation. This was a great idea, because after reviewing their codes and actually running them in Robocode, I can see each of their strengths and weaknesses.Below is a brief subscription of the sample robots that I reviewed...

Corners: This robot will start off going to the upper-left hand corner. Once it gets there, it'll remain there and fire at any robot that it finds. If it dies while there are more than 75% of other robots remaining, it'll change it corner going clockwise. The bad side to this is that it becomes a sitting duck once it gets to the corner. Or worst if it bumps into a robot, it treats it as a wall. So if it bumps into another robot, it'll think that it's a corner and stops there. When it scans and finds a robot, it'll use it's smartFire methods which chooses the firepower depending on the distance of the enemy. This looks good on paper, but when testing it up other robots, it tends to lose to robots that uses a stronger firepower.

Crazy: This robot's movement is just like it's name. It's movement is so unpredictable which makes it really hard to hit. Once it's scan and finds a robot, it'll fire a weak bullet. But due to its weird movements and weak firepower, it's more of a decoy bot if it was in a team battle.

Fire: This robot is a partial sitting duck. It's starts off by spinning it's gun and radar and fires at the first robot it sees. When it gets hit, it'll move perpendicular to the bullet by 50 pixels and sits until it gets hit again. These small movement help it avoid getting hit by a chain of bullets. It constantly scans 360 degrees with its radar/gun each time it gets hit and chooses either max or min firepower depending on the distance of the target.

RamFire: This robot scans for enemy robots and attempts to ram the first one it see. It doeesnt fire until it gets into point blank range. It also lowers it's firepower depending on the target's energy trying to finish it off by ramming it to get the bonus points. This robot's strategy will normally lose to other robot that uses a high firepower or smart fire, because it's not firing at the target until it's at point blank and it lowers it's firepower when it's about to kill it's target. In my opinion, this robot is too greedy for the bonus point which is not really worth it. It's also horrible at chasing highly mobile robots such s Walls and Crazy.

Sitting Duck: This robot does extra what it's name says. It pretty much just sits there like a target dummy. But it also does one extra thing which is that it outputs a file called "count.dat" which contains the number of rounds and battles that it was it.

SpinBot: This robot constantly moves in a circular motion scanning and firing max firepower bullets at it's targets. It's circular movements helps it avoid bullets and it's max firepower allows it to tear apart stationary target with eases.

Tracker: This robot is quite similar to the RamFire in the sense that it scans for a enemy robot and chases after it, but not to a point blank range. It'll stop about 140 pixels away form it's target and then fires max firepower bullets at it. This robot similar to RamFire will have a disadvantage against high mobile robot and robot that use max firepower or smart fire. A simple improvement to this and RamFire is to just make them begin firing at their target once it's found.

Walls:This robot is the king of the sample robots and I can see why. It is always constantly moving along the walls making it a hard target. And since it's running allow the walls, it can never get hit from behind. It also peeks at the next wall before turning to make sure that there's no robots on it. That way, it doesn't get flanked from the side. I was told that the corner robot was a counter to this robot, but after reading their codes and running tests with them, the Walls always wins. It's because the Walls robot uses a fixed medium firepower while the Corner robot uses smartFire. SmartFire becomes a disadvantage because these 2 robots are always firing at each other at a full length/width of the battlefield. So if Corner uses a stronger fixed firepower, it'll probably win.

So after reading all the source code for these sample robot and doing actual tests with them, I got a pretty good idea on what strategies to implement for my robot. I'll be looking forward to see what strategies my classmates came up with and Hopefully I'll find a counter strategy.

Meeting the standards while setting the standards

When I took my first programming course a few years back. I use to think "why do I have to format my code to the professor's way? As long as I can read my code and it does what it's suppose to do, it should be fine." Boy, was I naive back then. As the programs get more difficult, I was having a harder time debugging my code. And when asking classmates for help, it took them a very long time just to follow my code and find any errors.

The point of me telling this story is that if you ever want to a real programmer and be able to write codes with other programmers, you need to follow a coding standard. The point of setting standards and meeting these standards is so that everyone is on the same page. There are technically no real "set" standards that everyone MUST follow, but there are a lot of general guidelines that most programmers follow.

For our Robocode project, we follow the following three guidelines(standards)

• Elements of Java Style
• ICS Coding Standards
• ICS Robocode Standards

By following these standards, we are able to easily follow and edit codes that are written by other classmates. In the real world, writing code that only you can read don't set you apart for the others. Its writing codes that everyone can easily read and follow that makes you special. So be meeting the standards, you are setting the standards...

Here is a link to my revised codes following these standards...

Robocode, Show your Java supremacy

Robocode, an open source once created by IBM has now became an educational game designed to help people learn to program Java and have fun doing it. For me, it's been quite a while since I've did any serious programing in Java. To be honest, programming has never been my strong point, so when we were giving this assignment, memories of staying up all night debugging code came flashing through my head.

But to my surprise, this assignment was quite enjoyable. We were task to design 13 robot to do certain tasks. The first robot we designed was a sitting duck, which like it's name just sits there and do nothing. This was basically a "Hello World" program, as simple as it gets. But by completing this first design, I was about to run the Robocode program and see my "sitting duck". I was actually proud of myself for making this robot, kind of like a new parent seeing their new born baby. It made me feel enthusiastic and motivated to program and design more robots.

As I complete more robot designs, the task which they perform gets a little more complicated to program, and eventually I ran into a few problems. Due to my lack of program skills and time away from the Java language, I wasn't able to complete all of the 13 designs. I've managed to complete 10 out of the 13 leaving Tracking03, Firing03, and Firing04 unfinished. I was stuck on tracking03 for quite a while trying to figure out how to scan for the closest enemy, but time ran out on me before I could figure it out.

One thing that I've learned from this assignment is that these robot vary greatly depending on the programmer. A novice programmer can create simple robot that does 1 simple task, while expert programmer can create robot to be like Rombo (Rambo) a one man killing machine.

As of right now, I'm no where near these expert programmer that design robot worthy of competition. But someday, I will show you my java supremacy and create a robot worthy of competition. Til then, I'll be bushing up on my Java, and I hope you will too.

Here is the link to download my design

FizzBuzz, Know your drinking games...

I was a bit surprised when "FizzBuzz", a drinking game that I remembered playing a few years back was our first programming assignment for our Software Engineering class. It has been almost 2 years since I've programmed in Java and it took me a while to remember the syntax.

After installing the Eclipse IDE and quickly going over some of the samples codes, I began to write my FizzBuzz program. It took me around 15 minutes to get the program working properly, a bit longer than I've expected. The output was coming out wrong because I was using all "if" statements at first rather than using "else if".

Running into problems with such a simple code tells me that I definitely need to review and refresh my java.


Below is my code for FizzBuzz


PUBLIC class FizzBuzz {

   PUBLIC static void main(String[] args) {

       FOR (INT i = 1; i <= 100; i++) {

           IF (i % 15 == 0) {
               System.out.println("FizzBuzz";
           }

           ELSE IF (i % 5 == 0) {
               System.out.println("Buzz";
           }

           ELSE IF (i % 3 == 0) {
               System.out.println("Fizz";

           }
          
           ELSE {
               System.out.println(i);
           }
       }
   }

}