Friday, December 18, 2009

The Last Review for this Semester

Although there was so much reading and implementing a lot of code. ICS 413 was a very informative and fun class. This class taught a lot about standardization and major development. I believe these two things made me a better programmer. By doing all the reviews for classmates, it was very noticeable that standardization was very important in programming.

What I would like to learn more about is User Interface. I noticed that we all have problems with a good user interface. When any group went up in front of the class to present their project, they then notice that a part of their project could look better, and the teacher would point out something we would not notice.

I had fun in this class because the teacher was the most interesting teacher than any teacher I had so far (This is not me brown nosing). I think that the only thing that was hard was the major reading. It was hard to get the reading done, code, and get other classes done also. However, overall this class was fun and informative.

The Final: Greendepot 2.1

It has been a long semester of cramming code together to finish our last project, and it is over!!!! Since the 16th of November, we have worked on a project called Greendepot. This project takes what we learned in Wattdepot and output the information for users on the internet. It is just like any basic website, homepage and links to other pages. Certain pages inform the user about the carbon intensity. The stoplight page tells the intensity now and Gridinfo outputs a graph. And we have a home page and a contact page.

What we did now was update a lot of the looks for our website. It was a really hard start for this project, but if you look at the differences when we first started and now, there is a huge difference. Between 2.0 and 2.1 we tried to implement bonus things and we fixed a lot of the errors we had at 2.0. I tried to implement the google visualization, but I could not figure out how to implement it very well. I was able to have it output to the screen but not get the information i needed for the output to be correct. So, instead of leaving a non working visualization, I left what we had before for 2.1 Overall, we corrected the errors we had such as default settings for the drop down lists.

SO, version 2.1 could be found here. My last 413 project. Until next semester with 414. Have a nice break.

Tuesday, November 24, 2009

Review of Greensmart

After the cramming of making our projects work, now it is time to review each others projects and if we got them to work correctly. The group project I was assigned to was Greensmart. Their project looked very good. The home page looked very professional and the logo they have makes it a legit looking program.

The project was able to handle anything that i threw into it. Al l the error handling captured each thing I wrote. What I really like from the error handling was that it knows when you have entered a date too long ago when electricity was not being documented yet and if you enter a date after today's date, it says it cannot retrieve things in the future.

To look at my full review, click here.

But overall, I think the project looks good, but for a brand new computer user, it would be hard to understand how to work the program. The changes needed would just be to make it like Greensmart for Dummies.

Monday, November 23, 2009

The OscarWebApp called Greendepot

So far throughout the development of Wattdepot, there were many struggles. If you look at my previous blogs it would tell you a tale of hardship and pain. Greendepot is an add on to Wattdepot. But instead of just printing numbers to the screen, this project uses a user friendly web page that displays the carbon emission of the given day and displays when a home owner should use electricity, via green, yellow, or red flag.

This project was a very big task. It was hard to implement this project because setting up the build files, hackystat, and subversion took us a lot of time to get them up and running. Although, it was not our fault, hackkystat was giving a lot of errors and that stopped us from moving forward because without hackystat, our work for the project would not be displayed. From the countless time we took looking into the error, we found that it was an update to the site and everything would be normal later. If that was known we would have been able to start the project earlier. With this setback, we now had to rush and make the project.

The group worked very well together. We met during the day and when class was not in session. The build of the project is not so great because of us rushing to get it working.



Above is the work that my group has done. As you can see not much was done in the beginning, (Commit). That was where we were trying to get hackystat and the .xml files working. Then we started on the project and that is where you can see spikes in the build. I really believe that if we were told about hackystat, the project would be complete.

As of now, the web app takes in the user's input and just echos it. But we have the command line printing what is suppose to be in the web app. We could not integrate the output into the web app in time.

The download for our project could be found here.

Monday, November 16, 2009

WattDepot 2.0!!!!!!!!!!!!!

After our class reviewed each others code for Wattdepot, we all needed to remake everything. And now here is 2.0!!!!!! The program could be downloaded here. Click on WattDepotCli Version 2 by Team Eiwa.

This project, Wattdepot, collects information about electrical data from meters in certain areas. We created a program that takes this information and organizes it in a way for easy readability. And what is new in the new version 2.0, we added a SoftwareICU system called Hackystat. Hackystat gives us great information on analysis, visualization, interpretation, annotation, and dissemination for us to monitor the project.

Our system fulfills all of the requirements. We changed most of the issues made by our reviewers, but documentation could still be improved. We also created a somewhat high-quality system design. I had it in a way where test commands and regular commands was in different packages for easy readability, but there was changes to that. And due to our reviews about testing our code, we made test cases for every command.

The group could not meet regularly due to conflicting schedules. We did split the work equally, but changes were made to each others code so we both corrected each others code.




The Software ICU shows that our test coverage is mostly stable. It also shows that our builds, tests, and commits a spiky, this is because the group doesn't meet regularly so we are doing the project on our own and that makes the graph jumpy.

The following is the questions we had to answer using our program:

What day and time during the month was Oahu energy usage at its highest? How many MW was this?
Time: 2009-11-02T20:00:00.000-10:00 Power: 995.0 MegaWatts

What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
Time: 2009-11-02T04:00:00.000-10:00 Power: 493.0 MegaWatts

What day during the month did Oahu consume the most energy? How many MWh was this?
Time: 2009-11-02T00:00:00.000-10:00 Power: 14764.0 MegaWatt-Hours

What day during the month did Oahu consume the least energy? How many MWh was this?
Time: 2009-11-01T00:00:00.000-10:00 Power: 14089.0 MegaWatt-Hours

What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
Time: 2009-11-04T00:00:00.000-10:00 Carbon: 29959472 pounds

What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
Time: 2009-11-07T00:00:00.000-10:00 Carbon: 22908808 pounds

Tuesday, November 10, 2009

My Review Experience

After reviewing my peers code, I learned a lot of things. A lot of us procrastinates. When the deadline is near, everyone starts putting whatever they can together. That is why there is no test cases, comments, and "one person doing the job". What we all should do differently is set for ourselves an earlier date so that we do not procrastinate on the real due date.

Not much people did test cases because they are concentrating to get the project done. But while rushing to get the project done, they have been "testing" it the whole time, because they look to see if what they just made is outputting the right thing. However, just because we see that the program works we still need to make test castes. We should show test cases because then the programmer/reviewer can know that the code is working correctly or incorrectly. But the most important thing that I saw while reviewing my peers code is comments. Comments help the most for the user or reviewer to know what is going on in the code. It may seem stupid to comment something small, but it is important.

What I learned from my reviews is that to start early. It is bad to start late because you will get crappy code and not get everything done and lose sleep time.

Monday, November 9, 2009

Wattdepot Reviews

After the long nights and cramming the making of our wattdepot-cli projects, we were tasked to perform reviews on our peers' project. The Criteria for this review could be found here. We were tasked to review two projects, the two that I reviewed was ewalu and umi.

Ewalu:
An overview of this project is that it builds and it runs. However what I could not figure out is how to do other methods than just quit, help, and list sources. The other commands do not work. What could be improved in this project is the separating the commands into a package and each in their own class. To see the full report click here.

Umi:
An overview of this project is that it build and it runs. What could be improved in this project is the separation of the commands and putting them into a package and different classes. Also, to make test cases for the project because there is none made. To see the full report click here.

Wednesday, November 4, 2009

Learning integration through Wattdepot

For one week, my class has been working on a new project called Wattdepot. Wattdepot is a system that is accessible by anyone to store and analyze power consumption. This tool is great for consumers that want to monitor their power consumption. However, this tool can make the bill more accurate and could cost more if you are not careful.

My partner for this project is David Mau. We split the work up by looking at the list that needs to be done and did every other to split the workload. David did a great job in making the code easily read and understood. I say this because I had to do the CommandLineInterface and every file he made, I was able to implement it easily. To not stray away from his style, I followed it as closely as i could so that the whole project has the same style.

About every goal was achieved during this past week. However, on my part, I did not make any test cases for my commands and the CommandLineInterface that my teacher wanted was not implemented. But what I did do was make a CommandLineInterface that was able to run everything with no problem. As for test cases, I should be able to make some but not before the deadline. Plus I think I did so many test cases for myself because I did the CommandLineInterface and checked to see every time that what I needed to print printed. ahahhahaha. date, timestamp, description.... By looking at our project code, everything had a return statement except for the quitCommand. Also, for the power chart, I tried my best to figure out how to get the file, but I am really not sure how that works.

Overall, I had fun working with David even though we could not meet up every day. I think not meeting up about every day or other day broke a communication barrier for this project. We both had things to do so setting our minds straight for this project was difficult. But, David is a great partner and smart is coding.

After this, I will definitely fix the code to work properly and look more efficient. Click here to download our project. Our project name is wattdepot-cli-eiwa.

Monday, November 2, 2009

Hudson the System Checker

Continuous Integration is a software development practice where members of a team integrate their work frequently/daily. Each integration would be verified by an automated build to detect errors. By doing integration frequently/daily, there are less integration problems and it allows the team to develop software quickly.

What we are using for our watt-depot-cli project is Hudson. We configured Hudson to work side by side with SVN, which checks changes made to the project. Whenever changes are made to the project, Hudson would ensure that everything is working correctly. If it is not, it would send email notifications to whoever is associated with the project. This great feature allows developers to know that there was an update made that failed, and it can be fixed by anyone.

Right away when testing small parts of our code, I could see the benefits of using continuous integration. It keeps the user updated for every single thing. Also, it gives little symbols of what is going on with the code and if the code is working correctly or not.

One small problem I see with Hudson is that the little cloud symbols don't give the right symbol. It starts off with a sun saying everything is great and running correctly. Then when we tested Hudson to see if it works with our project, it gives a little cloud. Which was correct because we were just testing it. But when we fixed it, it did not change back to the sun. If anyone was to just look at that symbol, they would think that the code is not doing what it is suppose to do even though it is fine.

I think that this is a great tool to use when in a group project. If you cannot meet with the group all the time, this tool helps by keeping you updated.

Monday, October 19, 2009

Quicky Questions

Midterm is coming up! What could be on the test? Here are some questions that ask what we have learned so far.

1. As a programmer, why is the code "import java.util.*" not something you should have in your code?
You want to let the viewer to be able to understand and trace every part of the source code.
By using a wildcard, this makes the viewer unable to help resolve issues, if there are in
your code, because the viewer does not know what you imported.

2. Why is a FizzBuzz program being used as an entry question to any programming job?
There are people who know a whole lot about programming, but not a lot about writing
source code. FizzBuzz weeds out those type of people at a programming job interview.

3. What is it called when someone watches tv, checks their phone, checks their email, checks their myspace, and trying to do their programming all at the same time? As a programmer, why is this bad?
Multi-tasking. For a programmer this is bad because their focus is not 100% on their work.
If a programmer does not have full focus on their work then the code will not have high
quality also.

4. Write a FizzBuzz program, but instead of using for loops and while loops, do it recursively.
public class RecursiveFizzBuz {
private static int x = 1;
public static void main(String[]args){
recursive();
}
public static void recursive(){
if (x != 101){
if((x % 15) == 0){
System.out.println("FizzBuzz");
} else if ((x % 3 )== 0){
System.out.println("Fizz");
} else if ((x % 5)==0){
System.out.println("Buzz");
} else {
System.out.println(x);
}
x++;
recursive();
}
}
}

5. What is open source software? What is so good about it?
Open source software is source code that is viewable to the public and is open for the public
use. The public can use, change, and improve the software, and redistribute it. What is
so good about it is that any one can help improve the code because the code is viewable.

6. In a forum, does a subject "HELP!!!!!" give you any insight of what that person needs? Is this a proper subject line? What should be a proper subject line?
No. No. A proper subject line should describe something fully and precisely on what you
need help on.

7. Why would you test your own code? What are three types of testing?
You should test your code to see that your code is doing what you want it to do. Acceptance,
behavioral, and unit.

8. What is so good about ANT? What are some things that ANT does?
ANT is a java-based build tool that checks your project and says if your project is ready to
be distributed. Some things is that it checks your source code, byte code, and runs
tests.

9. Why should you comment your code? Is updating your comments important? Why?
You should comment your code to state what is going on in certain areas of the code, what
the program is about, and why it is doing what it is doing. Yes, it is important because
if you do not update your code then whoever is looking at your code is trying to figure
what is going on, they will read that comment, and that comment and the code will not
match each other.

10. What is subversion and why is it helpful.
Subversion is a free open source version control system. It is helpful because it manages
files and directories and the changes made to them. The owner can keep track of what
has changed, and backup to older versions of the code if they want to.

Wednesday, October 14, 2009

Project Management and SVN

Working with Google's Project Management and SVN has shown me two programs that are very useful. SVN or subversion, is a useful tool that a group could use when working on a big project. It allows the group of people to make small or big changes to the projects and commit the changes to the source server for everyone in the group to update. SVN differs on different machines, so what I used was TortoiseSVN, MAC uses smartSVN. What is really great about SVN is that it always checks for the most recent version, so if you were to try and commit the code you fixed and someone else has done so before you, you have to update according to their fix before you can commit yours. This feature gets rid of update problems.

By learning so many things about programming, it has shown me lots of resources. I did not know Google had so many features. Google Project Management has made it easy to load all my project files on to one server, and anyone can access it and make comments. Which is really great because the more input from people the better my project will be.

To go to my discussion page click here

To go to my project page click here

Thursday, October 8, 2009

JUnit: Robocode Testing ... not a Crew

JUnit testing is code that is programmed to test a programmers main code to see that the code that they wrote is doing what it is suppose to be doing, or it could be used to see statistics in the code so that the programmer can make the program better.

When we first started using JUnit, I noticed that not just me but everyone was having a hard time just trying to write code to test our main java file. I thought it was a little funny but it is pretty hard. However, now that I know how to do it and how it works I think I can make more JUnit cases for future programs.

What I tested in my robocode program is if my robot can beat two sample robots, if it turns to try and ram another robot if another robot is close, fire power, if my robot loses all its energy, and if it at least hits another robot when it fires. I believe that all these test cases were hard to make because at first I had no clue on what I was doing. I had to sit and look at classmate's JUnit cases and understand how and what they are doing. And since I took too long I am turning in my assignment late. I could have turned it in on time, but I wanted to understand the code fully instead of just turning it in.

Now that I do understand it, there is no problem making another one. What I could change though is how I made my robot because then writing these test cases would be a whole lot easier. What Emma did for me is run my test cases and show me if they failed or executed. This showed me what needed improvement.

Alright!!! without taking more time and not turning my code in, my robocode could be found here.

Wednesday, September 30, 2009

A Nightmare for a Programmer

Anyone can write the best code that they can, but there will always be something very small that could mess up the whole program. The one nightmare for a programmer is a program that was written in one hour but still being debugged for three hours. Any programmer or ICS student knows what I am talking about. But what I have learned about Ant has helped tremendously in making sure my code is correctly made.

In a workplace, having a standard for everything can keep the workplace safe, quickly done, and easily understood by others. Formatting code helps greatly for others in the workplace to understand your code, but what about the world? What about other platforms that want to download the program that you made on your own computer? This is where the program Ant comes in. Ant is a program that contains a bunch of xml files that can check your program and the build of your program. It can check the style of your code and prompt you for every line that is incorrect. Also, it can look for bugs which check your code for incorrect inputs. The most important thing that Ant does is create a file that could be run on any pc.

When I started this program, I found that the style of my java file had a bunch of errors. What was great even though it had a lot of errors was that each error said what was wrong and where it was. It took me a while at first to figure how to correct some errors but they were easy. Most of my errors was when I was commenting about @params. But after fixing that and some whitespace my program was fine. Also what was hard was correctly assigning the titles for the xmls. I had to find each title and change it to mine.

I you would like to learn about my new Robocode file click here.

Monday, September 21, 2009

KillaRobot is ALIVE!!!!!!

Up until now, we have been messing around with a program called Robocode. We have been looking at how the robots work, learning how to make them move, and brainstorming strategies to defeat other robots. Coming up is a tournament that has been put together by our professor called Robowars. In Robowars we can challenge other people over the internet with the robot I created and the robot they created. But for now we are going to challenge people within our class. The robot I put together now to challenge my classmates with is called KillaRobot, KR for short.

Now that we have learned the basic movements and some strategies, it was time to design our own robots. KillaRobot does basic movements, but it destroys 7 out 8 sample robots at best 2 out of 3. The sample robots can be viewed in my last blog entry.

Creating KillaRobot
Upon building my robot, my main concern was how am I going to fire at the other robots. After doing the basic scan the battlefield and fire on scanned robot, then came the idea of just moving straight to be able to dodge enemy bullets. But after getting those two basic movements and observing that with just the basic movements I can destroy most sample robots, Ramfire comes and just destroys me. I did not know how to counter Ramfire. I tried moving away when I got hit. I tried doing circles. But it kept on winning the overall battle. Then I thought, how about I just hit Ramfire back, because I have the advantage first because I shoot it a couple times first before it hits me. Then after applying this thought, I was able to make "KillaRobot".

Movements
KillaRobot's movements are really basic. It moves in a straight line while scanning the battlefield. When it sees another robot, it fires max power. If it hits a wall, it will turn right and move forward again. What is unique about KillaRobot is that when it gets hit or hits another robot first, it will act like Ramfire. It will run into the enemy robot and fire max power. Another thing that makes KillaRobot unique is that when it gets hit by a bullet it will turn right and move forward. I made it do this when it get hits by a bullet because I noticed that it died alot when facing Spinbot. I thought how am I dying by Spinbot. I found out that since KillaRobot moves in a straight line, if it moved horizontal on the playing field Spinbot was able to hit KillaRobot. When applying the turn when KillaRobot gets hit by a bullet, KillaRobot was able to defeat Spinbot.

Victories
The robots KillaRobot was able to defeat was RamFire, SpinBot, Crazy, Fire, Sitting Duck, Corners, Tracker. Tracker wins sometimes, but overall KillaRobot wins. A win is a win. Walls is the only robot that KillaRobot cannot defeat. The next build, I will concentrate on defeating walls. Since Ramfire was what I concentrated on first, I stuck with it. And it destroyed 7 out of 8.

You can see my robot's abilies HERE.

Wednesday, September 16, 2009

RoboCode: Review of the Sample Robots

After learning the basic movements for robocode, it has become fun and interesting. Seeing the robot move, track, and fire has made this ICS class fun. But the time is getting near for RoboWars and we need strategies for making our own KRs. KILLA ROBOTS. The following 8 robots are samples that I have reviewed to make a KR.

Walls:
This robot's movement has the simplest movement. It finds the nearest wall, goes to it, and moves along the walls shooting at the enemy. It only shoots at the enemy with medium power and when the enemy is in front of the gun. The movement for this robot is not very effective. If there was an enemy in the robot's path, it treats that enemy as a wall. The enemy robot could be towards the middle of a wall and if this sample robot hits the enemy robot, it would then move along the middle of the map as if it is moving along a wall. The firing for this robot is also not that effective because if it is correctly moving along the walls it would only shoot when the enemy robot is in front of the gun. If it is not moving correctly along the walls, then it could be missing the all the robots it does not see.

Ramfire:
A robot that is like a bulldozer with a gun fixed to it. This robot will pick an enemy robot that it will fire at and run into until that enemy is dead. This would be a very effective robot if it was able to stop the paths of other robots. If it doesn't stop the paths of other robots, it is just a straight moving robot because it does not fire at the enemy until it rams the enemy robot first. Ramfire has no special movements but ramming and getting extra points and no special fire abilities because it will not shoot the enemy robot until it hits the enemy first.

Spinbot:
This robot is a very dizzying robot. It spins in a circle while wildly firing at an enemy robot at full power. Most of the time this robot misses its target. The movement of this robot has no strategy, when it has an enemy in front of its gun it fires and mostly missing. It is a little effective for dodging bullets but not very. If its target is sitting still, then this robot will win.

Crazy:
Crazy is pretty crazy... The movement of this robot is very effective for enemy robots to miss. In its code it uses setTurns, setAhead, and waitFor in the AdvancedRobot. These methods give this robot the ability to move in a curve. Unlike robot, it has to use call a lot of methods to do the same. Although it uses advanced movements, its tracking and firing abilities are terrible. The gun and radar is fixed, so when the enemy is in front of the gun, it then shoots. What is worse, it fires with the least amount of energy.

Fire:
Ouch I got hit let me move from this spot... The movements of this robot is very bad. It sits in one spot until it gets hit, then it will just move a little either left or right. The tracking is also bad because the radar and fixed gun only turns to the right scanning the field. And judging only if the enemy is close, less than 50 pixels, it will use max fire power. If the enemy is far then it will use the least fire power. What is good about this robot is if it gets hit, the gun will turn real fast pointing to the enemy robot who hit it, and fires at maximum power.

Sitting Duck:
Shoot me!!!! This robot has nothing at all. There is no movement, scanning, or firing. Basically it is a target.

Corners:
Go to the corner... This robot has a good thought strategy but is very ineffective. It is good that it goes to a corner because no one can shoot it from behind. However, if it is stopped from getting to an actual corner, this robot is useless because it thinks it is at a corner but it is not. The tracking for this robot is ok, when it reaches its corner, it sweeps its gun from 0-90 and does a little tracking when locked on to a robot. Its firepower is also ok because it fires at the enemy when it is in front of the gun. It uses low power if the enemy is far and max when the enemy is close.

Tracker:
I got you in my sights... This robot is like Tracking02, but when it gets withing a certain distance between the enemy it open fires. The movement for this robot is not effective. It just tracks an enemy and either moves toward it or away and then fires. Its targeting is good because it sweeps its radar left to right if it lost its target. If it finds it then it moves foward or backward. If it does not find it in its left to right sweep, it then spins looking for another target. Its fire power is at maximum when it gets to a certain distance between the enemy. If another enemy hits the robot, it will open fire at maximum at that robot.

Reviewing these robots have given me a little insight on what I can use as strategy for my KR.

Monday, September 14, 2009

Coding Standards - Why they are important

Coding Standards in our codes is very important in today's developing world. If there are no standards, how can anyone read your or anybody's code? If there was no MLA formmating in writing, everyones citations for their paper's would be all over the place and no one could understand where that writer got their resources. MLA formmating and Coding Standards give guidelines so anyone anywhere can read the code.

So far using using coding standards in class has not been difficult. I have been using it for my college career and it is easy to read my own code when I bring it up again to look at it. The only difference between now and when I first started my Software Engineering class, is the use of tabs. Tabs made the code look real nice and organized, however learning that tabs could be interpreted differently in a different environmet made it hard to stop using it. But since eclipse has a format option, it made it easy to eliminate those tabs.

Click here to see my new robocoding standards.

What is new in my code
While looking at my classmate's code, I noticed that on some of my codes I use the most complicated way to make it work. This reminded me from what my professor has said about his career, there is always a way that what your doing could be made simpler. While looking at my classmate BJ DelaCruz's code, I noticed that the code I wrote is a billion lines longer than what he had. So I looked at his code and made mine similar to what he had, I tried to make my code unique so it is not like I copied his code line for line, BUT his code is so simple that there is no way to not see the difference.

In everything you do, there will always be someone that could do better.

Wednesday, September 9, 2009

Robocode *****&&%%%%^^&**^%

Oh my, robots have taken over my mind... This assignment was tough on some parts and easy on others. To look at my code click here. The assignment had robots that had to do nothing and robots that had to track another robot and follow them or shoot them. IT WAS CRAZY TO FIGURE OUT ALL THE METHODS. aaaaahhhhhhh. But in the end when the robot worked, I understood very well how the robot works.

Experiences

Some robots needed a little bit of math. I have forgotten some basics of math and i needed to refresh it by looking it up in google. For example, the robot for Movement05 needed to move to one corner and move to the opposite corner. I forgot the basic a^2 + b^2 = c^2. I just needed the distance c to move across the board. lol But it was a funny refresher. Other codes needed some sitting back and thinking because they needed to do things specially. For example the tracking robots, they needed to scan the field and follow the robot it scanned.

Future build

From learning basic movements, tracking, and firing, I think that when we have to make a competitive robot, I will be able to last for a while. I would make my robot be able to recognize fired bullets and dodge them.

Monday, August 31, 2009

OSS Experience

Overview:

jEdit (http://sourceforge.net/projects/jedit/) is a programmer's text editor written in Java. It is like any other text editor, but with a little more power. It is supported on multiple systems, mac or pc. With the correct plugins, this not so simple text editor can be a powerful tool for a new java programmer.

PD1:

Right after download and startup, this text editor is like any other text editor. I tried writing my previous posted program and it was like notepad but with a little more features. Unlike eclipse, this text editor does not help too much when first downloaded. However, with the correct plugins, jEdit could be a powerful editor (said by the website).

PD2:

When downloaded, jEdit is just one executable file. After download, with just a few clicks as to where the user would like to save the program and have certain features, the program is up and running. If the user is a first time computer user, this type of download could not be any easier. However, when using this type of text editor, it should not be a for a first time java programmer and computer user, because without the correct plugins, it will not help for a first time java programmer, and finding the correct plugins for a first time computer user is not so great also.

PD3:

For an experienced computer user and java user, this program can be very easily used. Again, with the right plugins this program could be very powerful, even though it is like a simple text editor. To improve this program as a developer, I would give the option of downloading the program with plugins already installed. As it is now after download, the program is almost identical as notepad. If it came with an option for certain plugins, jEdit could be like eclipse after download. As a new developer, this program could be easily modified because it gives the new developer to write and update modes, write macros and plugins, and fix plugins or core bugs.

FizzBuzz

The FizzBuzz Program:

The purpose of this program is to print integers from 1 - 100 with the following exception, every number divisible by 3 prints Fizz, 5 prints Buzz, 3 and 5 prints FizzBuzz. It was assigned to test
"programmers", who say they can program, but in reality they can not. This simple program helped companies to not hire people who can not do a simple program.

Time took to do this: 5 min

Problems: A little basics

Solutions: Look for examples online or the java API

Overview:

Fun refresher when done in class. It was interesting to learn the JUnit test case program and implementing it with this program. So far the class seems great. Love the structure of how we are doing work in class and not mostly at home.

Code:

public class FizzBuzz {
//Constructor to print out the numbers.
public FizzBuzz(){
for(int x = 1; x <= 100; x++){ if((x % 15) == 0){//number is 15 because that is 3 and 5 System.out.println("FizzBuzz"); } else if ((x % 3 ) == 0){ System.out.println("Fizz"); } else if ((x % 5) == 0){ System.out.println("Buzz"); } else { System.out.println(x); } } }


public static void main(String[]args){
FizzBuzz fizzer = new FizzBuzz();
}

}