For our software engineering class we have been assigned the task of creating a list of 10 question that students should be able to answer quickly as a practice for the midterm. I created my questions trying to address mostly issues of sofware engineering and effective communication and not general programming.
Well here is goes...Good Luck!
1.Name three different kinds of that you can perform using junit and give an example of each.
Answer:
Acceptance, Behavioral, Unit
2.What is the difference between white box and black box testing?
Answer:
Black box testing is testing a program without knowledge of its internal working. Providing input only to confirm proper output and not what happens in between.
White box testing is testing with the ability to check the functionality of the code on the inside Having knowledge/access to the source code.
3.Name 2 benefits and 1 negative factor of distributed versus centralized as it pertains to subversion.
Answer:
Distributed systems have greater speed performing most task. Doesn't have a single point of failure. Has the flaw of not having a "czar" to constantly oversee code progress and maintain code.
4.What is the different between pmd and findbugs?
Answer:
pmd checks source code and findbugs looks in the compiled byte code.
5.What are 3 things we used checkstyle to check for in this course?
Answer:
Spacing
JavaDoc
That the open bracket was on the same line as the start of a method/class/etc..
6.Why is a professional persona important?
Answer:
It allows potential employers and others to gain knowledge of our interest and skills pass what a one page resume is able to showcase.
7.What are the three prime directives we used in this course and why are they useful to software engineers?
Answer:
That the software is able to perform a useful task. This is tested by an end user and not the developer.
That the software has proper documentation that it can be installed and used without much input from the developer. This is tested by an external installer and not the developer.
That the software has proper documentation and general good programming so it can be understood, used and modified by another developer. This is tested by external developer.
8.List 3 reasons why it's good to be a single-tasker versus a multi-tasker.
Answer:
Accomplish task faster.
Reduce the amount of errors you incur performing a task.
Reduces stress.
9.list 2 reasons why is it good to document code properly?
Answer:
To make code more readable during development and after development.
Make code understandable by other developers.
10.Give an example of a good post if you are trying to get help for a coding issue online?
Answer:
Uninitialized object error at the start of a loop.
I am receiving an uninitialized object error when running the code below.
***code directly starting the loop and then going through loop at least 2 lines below error***
Basically showcase the code thats generating the error and providing a copy of exact error doesn't hurt.
Monday, October 19, 2009
Wednesday, October 14, 2009
To Google or not to ...
For the past few weeks, I have been working on my robocode Robot MikeTerry. But now I want to share my code so that other developers can edit MikeTerry and make it even better. By getting familiar with Google Project and SVN client.
The only part in my conquest to put MikeTerry out there that I was unable to succeed in was to add codesite-noreply@google.com as a discussion list member, but otherwise I didn't encounter any problems.
I have learned that Google provides great features for developers. By creating Google Projects and Discussion Boards, the simplicity of having another developer look at your code became a world wide affair.
Here is a link to my discussion group
The only part in my conquest to put MikeTerry out there that I was unable to succeed in was to add codesite-noreply@google.com as a discussion list member, but otherwise I didn't encounter any problems.
I have learned that Google provides great features for developers. By creating Google Projects and Discussion Boards, the simplicity of having another developer look at your code became a world wide affair.
Here is a link to my discussion group
Wednesday, October 7, 2009
Testing: Being on point.
During the past week, I had MikeTerry (please see previous posting) doing tests to make sure he knew what he was suppose to do. MikeTerry went thru six tests case, which he successfully passed with flying colors. Here are the tests and results of this past week testing phase.
Acceptance tests are to be making sure that MikeTerry can consistently beat one or more of the sample robots that I have been using in previous assignments.
Test 1- MikeTerry VS. Fire: MikeTerry constantly won against this robot.
Test 2 - MikeTerry VS. Crazy: MikeTerry constantly won against this robot.
Behavioral tests make sure that MikeTerry that his movements and strategies are on point.
Test 3 - Clockwise path: As part of MikeTerry’s strategy, he needs to move clockwise; by doing this test I was able to see that MikeTerry always used a clockwise path without making any changes in his coding.
Test 4 - All 4 corners: One of the other strategies is to move to all four corners, which MikeTerry did successfully without any major changes in his coding.
Test 5 - Out of the center: I wanted for MikeTerry to stay within the outter wall radius and he did it consistently.
Unit test verifies that MikeTerry ‘s individual methods calculate the correct output values given various input values.
Test 6 - Firing: MikeTerry tested that his firing power was consistent. He needed to fire his enemy at the power of 2 or less when the enemy is in the range greater then 200 pixel.
During the testing phase, I discovered that my coding style didn't require alot of changes for testing. Here is MikeTerry tests and results.
Coach's last words: It is easier to code with testing in mind versus coding like a mad programmer and finding bugs everywhere to drive you to be even more mad.
Acceptance tests are to be making sure that MikeTerry can consistently beat one or more of the sample robots that I have been using in previous assignments.
Test 1- MikeTerry VS. Fire: MikeTerry constantly won against this robot.
Test 2 - MikeTerry VS. Crazy: MikeTerry constantly won against this robot.
Behavioral tests make sure that MikeTerry that his movements and strategies are on point.
Test 3 - Clockwise path: As part of MikeTerry’s strategy, he needs to move clockwise; by doing this test I was able to see that MikeTerry always used a clockwise path without making any changes in his coding.
Test 4 - All 4 corners: One of the other strategies is to move to all four corners, which MikeTerry did successfully without any major changes in his coding.
Test 5 - Out of the center: I wanted for MikeTerry to stay within the outter wall radius and he did it consistently.
Unit test verifies that MikeTerry ‘s individual methods calculate the correct output values given various input values.
Test 6 - Firing: MikeTerry tested that his firing power was consistent. He needed to fire his enemy at the power of 2 or less when the enemy is in the range greater then 200 pixel.
During the testing phase, I discovered that my coding style didn't require alot of changes for testing. Here is MikeTerry tests and results.
Coach's last words: It is easier to code with testing in mind versus coding like a mad programmer and finding bugs everywhere to drive you to be even more mad.
Wednesday, September 30, 2009
Extra training for MikeTerry
In the world of rumbles and tournaments, in order to win, you must train. As part of training for a Robocode tournaments, one must assure that his or her code is error free. To do this, I called upon the help of specialized trainers.
What each trainers do: (according to their respective websites)
Ant: It is a Java-based build tool
that evaluates a set of dependencies, then execute commands.
Checkstyle: It provides checks that find class design problems, duplicate code, or bug patterns like double checked locking.
PMD: It scans the Java source code and looks for potential problems like:
•Possible bugs - empty try/catch/finally/switch statements
•Dead code - unused local variables, parameters and private methods
•Suboptimal code - wasteful String/StringBuffer usage
•Overcomplicated expressions - unnecessary if statements, for loops that could be while loops
•Duplicate code - copied/pasted code means copied/pasted bugs
FindBugs: It looks for bugs in the Java programs. It can find bugs by simply inspecting a program's code: executing the program is not necessary.
During the training sessions, MikeTerry was able to work on shortening his comments, labeling his parameters properly, and putting in the author tag. With these trainers MikeTerry's muscles (code) became more effective. The encounters between MikeyTerry and his trainers were unexpected. I had expected a few querrels and stubborness on either party but they worked pretty good with eachother. No particular problems. As the main trainer for MikeTerry, I have learned from his other trainers that my standarization coding must improve and how many ways I can improve other programs training. I really like these trainers as they simplify the training and elimate most of the tedious tasks that I have to encounter during a training.
After the training with the other trainers, MikeTerry and I worked on his level of energy for the next tournament. He was already well trained but with the increase of energy, he will be able to last longer in battles.
Here's a look at the before (this is a .jar file) and after (this is a .zip file) of MikeTerry's code.
What each trainers do: (according to their respective websites)
Ant: It is a Java-based build tool
that evaluates a set of dependencies, then execute commands.
Checkstyle: It provides checks that find class design problems, duplicate code, or bug patterns like double checked locking.
PMD: It scans the Java source code and looks for potential problems like:
•Possible bugs - empty try/catch/finally/switch statements
•Dead code - unused local variables, parameters and private methods
•Suboptimal code - wasteful String/StringBuffer usage
•Overcomplicated expressions - unnecessary if statements, for loops that could be while loops
•Duplicate code - copied/pasted code means copied/pasted bugs
FindBugs: It looks for bugs in the Java programs. It can find bugs by simply inspecting a program's code: executing the program is not necessary.
During the training sessions, MikeTerry was able to work on shortening his comments, labeling his parameters properly, and putting in the author tag. With these trainers MikeTerry's muscles (code) became more effective. The encounters between MikeyTerry and his trainers were unexpected. I had expected a few querrels and stubborness on either party but they worked pretty good with eachother. No particular problems. As the main trainer for MikeTerry, I have learned from his other trainers that my standarization coding must improve and how many ways I can improve other programs training. I really like these trainers as they simplify the training and elimate most of the tedious tasks that I have to encounter during a training.
After the training with the other trainers, MikeTerry and I worked on his level of energy for the next tournament. He was already well trained but with the increase of energy, he will be able to last longer in battles.
Here's a look at the before (this is a .jar file) and after (this is a .zip file) of MikeTerry's code.
Monday, September 21, 2009
In the blue corner, we have the contender MikeTerry v1.0...
In my previous posting, I reviewed the sample robots that we were assigned. And on Monday, we have a tournament with the advance robots that we wrote. As I prepare myself for the first RoboRumble, I am excited to see the competition.
MikeTerry v1.0 (Here is MikeTerry's code)
My robot’s name is MikeTerry, he is base on the sample robot Walls. The difference in my robot is that his fire power is based on enemy distance and if he is loosing, his fire power will be at 3.
I kept it relatively simple.
Practice Rounds
MikeTerry vs. Corners - Winner MikeTerry
MikeTerry vs. Crazy - Winner MikeTerry
MikeTerry vs. Fire - Winner MikeTerry
MikeTerry vs. SittingDuck - Winner MikeTerry
MikeTerry vs. RamFire - Winner MikeTerry
MikeTerry vs. SpinBot - Winner MikeTerry
MikeTerry vs. Tracker - Winner MikeTerry
MikeTerry vs. Wall - Winner MikeTerry (depending on starting points)
Training for next tournament
During the time following this tournament, I will train MikeTerry's strategy to beat the sample robot Wall.
Word of wisdom
It is hard to find one strategy to beat all the sample bots, it is easier to focus on beating as many as you can versus all of them.
MikeTerry v1.0 (Here is MikeTerry's code)
My robot’s name is MikeTerry, he is base on the sample robot Walls. The difference in my robot is that his fire power is based on enemy distance and if he is loosing, his fire power will be at 3.
I kept it relatively simple.
Practice Rounds
MikeTerry vs. Corners - Winner MikeTerry
MikeTerry vs. Crazy - Winner MikeTerry
MikeTerry vs. Fire - Winner MikeTerry
MikeTerry vs. SittingDuck - Winner MikeTerry
MikeTerry vs. RamFire - Winner MikeTerry
MikeTerry vs. SpinBot - Winner MikeTerry
MikeTerry vs. Tracker - Winner MikeTerry
MikeTerry vs. Wall - Winner MikeTerry (depending on starting points)
Training for next tournament
During the time following this tournament, I will train MikeTerry's strategy to beat the sample robot Wall.
Word of wisdom
It is hard to find one strategy to beat all the sample bots, it is easier to focus on beating as many as you can versus all of them.
Wednesday, September 16, 2009
The mole: Analyzing enemy’s strategies from the inside.
Before the big day of RoboRumble, I infiltrated into the enemy’s code, looking at the samples provided in the Robocode package I previously downloaded. The enemies called Walls, RamFire, SpinBot, Crazy, Fire, Sitting Duck, Corners, Tracker are analyzed in terms of movement, targeting, and firing, and their strategies are scrutinized. Here is what I discovered while I was in enemy base.Enemy Name: Walls
Movement: He will move away from the enemy whenever he is hit, he will travel along the wall.
Targeting: He rotates around the board while shooting at the enemy scanned.
Firing: He always fires at the same strength.
Enemy Name: RamFire
Movement: He tracks the enemy and attempts to ram him.
Targeting: He looks to gain bonus points by keeping enemy scanned alive to ram
Firing: He fires according to how much energy the enemy scanned has remaining.
Enemy Name: SpinBot
Movement: He spins around in a circle while shooting at the enemy scanned.
Targeting: He turns in a circle while scanning for an enemy.
Firing: He shoots on a constant strength depending if the enemy’s spotted bearing meets the criteria of being greater then -10, away and less than 10.
Enemy Name: Crazy
Movement: He moves in odd movements attempting to throw off robots without good tracking systems. If it hits wall, it reverses direction and it always does this if it hits a robot and its caused the collision.
Targeting: He looks for any enemy.
Firing: He always fires at a set strength once enemy is found.
Enemy Name: Fire
Movement: Only moves when he is hit.
Targeting: He spins his gun while scanning for an enemy.
Firing: He fires depending on the enemy’s health.
Enemy Name: Sitting Duck
Movement: He doesn’t move
Targeting: He doesn’t target
Firing: He doesn’t fire.
*He is definitely not an enemy that I will take any strategy from*
Enemy Name: Corners
Movement: He will retrieve to the corner while scanning for an enemy.
Targeting: He targets the first enemy he scans.
Firing: The close he is to the enemy, the more powerful bullets he will use.
Enemy Name: Tracker
Movement: He will not move until an enemy is targeted, he will follow and maintain a distance from the enemy.
Targeting: He concentrates on one enemy until it dies.
Firing: He will fire at the same strength.
With the opportunities of being on the inside, I was able to take some of the strategies in consideration for my warrior robot. Now I have to go prepare for battle. At war we shall meet again.
(image source: http://davidalves.net/images/robocode/robocodeII_logo_idea.gif)
Monday, September 14, 2009
Plastic Surgery for Robots
While observing Paul Galiza’s Code, I realized how important standardization was in the world of programming. As I look carefully at his code, I was amazed by the differences that people can have for coding the exact same function for the same project. Having a standardized coding helps future users and the author to decipher what is actually happening in the code.
After reading The Elements of Java Style, I started editing my robots’ code (from last week’s project) to meet the standards. I felt that I was a plastic surgeon giving my robots makeovers. I got so into editing my codes that I wanted to give a makeover to all of my previous projects to meet that same standard but I decided not too as I will probably start dreaming about coding and won’t be able to make the difference between English and Java after awhile.
Here is a link of my newly improved robots.
After reading The Elements of Java Style, I started editing my robots’ code (from last week’s project) to meet the standards. I felt that I was a plastic surgeon giving my robots makeovers. I got so into editing my codes that I wanted to give a makeover to all of my previous projects to meet that same standard but I decided not too as I will probably start dreaming about coding and won’t be able to make the difference between English and Java after awhile.
Here is a link of my newly improved robots.
Subscribe to:
Posts (Atom)