1. What is the difference between Checkstyle, PMD, and FindBugs?
Checkstyle finds bugs directly within the source code that do not fit the coding standards. PMD analyzes code using static analysis by looking at the class files without actually running the code. It finds any unnecessary lines of code. FindBugs focuses on finding code that could potentially be dangerous to the system such as infinite loops.
2.What are some differences between Ant and Make?
Make supports any programming languages and is very widely used. It allows the user to invoke shell commands without constantly typing in the same commands. Ant's build.xml file is much simpler than makefile. It is also java based and therefore supports the java community. It also simplifies cross-platform development.
3. In a professional blog, why should you write for the world and not the teacher?
That way, any software engineer will be able to gain insite to what you are trying to say. Enough information should be given so that anyone will know what you are talking about and not just the teacher or a small group of people.
4. What are 5 conventions for naming variables/methods in Java?
Pluralize group related attributes, Use nouns when naming interfaces, Use camel notation (ie. myVariable), use verbs for naming methods, use JavaBeans convention for accessor methods (is/get/set).
5.What is the difference between a version and a configuration?
A version is a sequence of updates overtime and are parallel variants. Configurations are types of systems that exist for different users, different systems, and/or for different functionality and/or pricing.
Friday, October 21, 2011
Thursday, October 20, 2011
Care to make my robot better?
In my last blog, I discussed my Robocode robot and what it does. Well now the source code of my robot is up online and can be found here. But then you ask "hey, what if I want to work on that project (or any other project) with a group of some of my friends?" Well, you can do that too with a little thing called subversion (SVN). What is SVN? SVN is a way to share files with groups of people, make changes, and then uploading it back for the others to work on. What is also very nice about it, is that it leaves a log of the changes made and when they were made.
I was able to finish all the tasks required for the SVN and found it to be very interesting. Before this "sharing" files would be done just be e-mail within the group and more times than none, all of the files are so different that you pretty much have to restart the entire project. The tasks themselves weren't too difficult as not too much programming was involved; it was more like, modifying some things. The most important thing I think I learned from this is how you can share files through google and allow group members to work on said project while automatically keeping a log of the changes made.
Links:
http://code.google.com/p/robocode-mma-mizuonegai/
I was able to finish all the tasks required for the SVN and found it to be very interesting. Before this "sharing" files would be done just be e-mail within the group and more times than none, all of the files are so different that you pretty much have to restart the entire project. The tasks themselves weren't too difficult as not too much programming was involved; it was more like, modifying some things. The most important thing I think I learned from this is how you can share files through google and allow group members to work on said project while automatically keeping a log of the changes made.
Links:
http://code.google.com/p/robocode-mma-mizuonegai/
Tuesday, October 11, 2011
Let's Get Ready To Rumble!!!!
It's the moment you've all been waiting for. The robocode competition. After weeks of testing, learning things with ant, and designing our very own robot, it's time to test our skills as well as our imagination. With this project, I was attempting to design a robot where that would be both offensive and defensive. It is actually quite hard to explain, much easier if you watch it in action.
So what does my robot do exactly. It's actually quite simple. For the movement, I designed my robot to simply follow other robots. At first, it will lock on to a single robot and follow it until either it (the enemy) or itself dies. In the case of a melee situation where more than 2 robots are involved, once the enemy is destroyed, it will then lock on to the nearest enemy and repeat the process. This way, the robot isn't stuck once the enemy is following is destroyed.
Like I mentioned earlier, targeting is done by means of scanning for the nearest robot. It will not change targets until one of the two robots is destroyed. It is a very risky procedure, but it reduces the amount of time required for the robot to re-lock on to a new target. This could potentially save the robot's butt.
Although firing could potentially refuel the robot, it also costs a pretty significant amount of energy to even fire off a bullet. Because of this, my robot will only fire when it is near the enemy. If the enemy begins to move away, my robot will be close enough where the odds of the bullet hitting would be pretty high and for this reason, the robot will always fire at the highest strength allowed by the rules.
Against the sample AI robots, my robot did fairly well. It would always win (obviously) against the ones that didn't move like SittingDuck and the two interactive ones. Against the ones that did move (and even fire back) my robot could consistently beat the Target robot. Against a few of the other robots, my robot would often win between 60 to 90% of the time. However, against the Walls robot I was unable to beat it. It was just too fast and well protected by the walls. The reason it couldn't beat Walls, well, my robot had to know where the other robot was before it moved and since walls basically just goes in a circle, my robot simply could not keep up. Would I change my design? I probably would. I would try to incorporate a faster way for my robot to turn and move, probably by implementing the AdvancedRobot class instead.
Because my robot had such a simple design, not much testing was required. The types of testing I did was to make sure I could beat a hand full of the sample robots more than 50% of the time, along with make sure my robot knew how to move away if it made a collision with the enemy robot. I tried getting my robot to limit itself in a "safety bubble" by having it stay near a wall, but often times it ran out of energy.
So from all of this and weeks of programming, what have I learned? I learned quite a bit actually. I learned the amount of time it takes to create larger programs as well as the sheer amount of testing it takes in order to make the program do what I wanted it to do. I also learned by means of the kata I finished earlier, that it is better to break a large program into smaller pieces of code via the divide-and-conquer technique and just have your code do a bunch of small things before putting it all together. So now that it has all been said, lets FIGHT!
So what does my robot do exactly. It's actually quite simple. For the movement, I designed my robot to simply follow other robots. At first, it will lock on to a single robot and follow it until either it (the enemy) or itself dies. In the case of a melee situation where more than 2 robots are involved, once the enemy is destroyed, it will then lock on to the nearest enemy and repeat the process. This way, the robot isn't stuck once the enemy is following is destroyed.
Like I mentioned earlier, targeting is done by means of scanning for the nearest robot. It will not change targets until one of the two robots is destroyed. It is a very risky procedure, but it reduces the amount of time required for the robot to re-lock on to a new target. This could potentially save the robot's butt.
Although firing could potentially refuel the robot, it also costs a pretty significant amount of energy to even fire off a bullet. Because of this, my robot will only fire when it is near the enemy. If the enemy begins to move away, my robot will be close enough where the odds of the bullet hitting would be pretty high and for this reason, the robot will always fire at the highest strength allowed by the rules.
Against the sample AI robots, my robot did fairly well. It would always win (obviously) against the ones that didn't move like SittingDuck and the two interactive ones. Against the ones that did move (and even fire back) my robot could consistently beat the Target robot. Against a few of the other robots, my robot would often win between 60 to 90% of the time. However, against the Walls robot I was unable to beat it. It was just too fast and well protected by the walls. The reason it couldn't beat Walls, well, my robot had to know where the other robot was before it moved and since walls basically just goes in a circle, my robot simply could not keep up. Would I change my design? I probably would. I would try to incorporate a faster way for my robot to turn and move, probably by implementing the AdvancedRobot class instead.
Because my robot had such a simple design, not much testing was required. The types of testing I did was to make sure I could beat a hand full of the sample robots more than 50% of the time, along with make sure my robot knew how to move away if it made a collision with the enemy robot. I tried getting my robot to limit itself in a "safety bubble" by having it stay near a wall, but often times it ran out of energy.
So from all of this and weeks of programming, what have I learned? I learned quite a bit actually. I learned the amount of time it takes to create larger programs as well as the sheer amount of testing it takes in order to make the program do what I wanted it to do. I also learned by means of the kata I finished earlier, that it is better to break a large program into smaller pieces of code via the divide-and-conquer technique and just have your code do a bunch of small things before putting it all together. So now that it has all been said, lets FIGHT!
Subscribe to:
Posts (Atom)