1. What are some effective ways to ask a question and why are they so?
One way is by giving a full detail of what happened and what you did leading up to the problem that you are getting. By immediately giving all the details, the person helping will know exactly why it is happening and give you solutions.
Another way is by doing the research first. Doing your own research may turn up answers to your problem faster than asking someone else. Even if you did research, it would help to share this information with the person helping you in case you did not find anything. They would be able to get a grasp of what kind of problem you are having and offer solutions.
2. How would you implement a task in Ant to create a JAR file?
3. How are PMD and FindBugs different even though they both fundamentally find bugs?
PMD analyzes the source code itself without running the program, as in it will read what you can see on the screen in an IDE. FindBugs reads the bytecode of the program. To read the bytecode, the program has to be compiled.
4. Why is JUnit very useful?
JUnit can test individual classes and determine that the input they get gives out the expected output. The best part about this is that it can be scaled to include a very large amount of tests cases for individual classes. The amount of classes and test cases JUnit can test is not limited either.
5. What are some of the terminology of configuration management?
Mainline, branch, checkout, edit, sync, lock, label, merge, checkin, resolve, head.
Tuesday, October 25, 2011
Thursday, October 20, 2011
Cloud Backups
A few days ago, someone was robbed and they had their computers stolen. What the computers contained was months long source code for an important project. That computer also happened to have the only copy of the source code. Suffice to say, there were many unhappy customers because they paid for an incomplete product and are most likely feeling buyers' remorse.
Backing up source code is no laughing matter, because a catastrophes may be uncommon, but when they do happen, you had better be prepared for the worst. It is especially shameful when creating backups is extremely easy and painless. Google Project Hosting provide free online storage for code backups so you have no excuse to not have a backup of everything important you have online.
Having a backup is also not just useful for cataclysmic events, but they also help speed up development. Backups are extremely important in the configuration management systems. They are a set of ideas of how software developers would develop their programs. Using configuration management, software developers will have a version to fall back on, so can code all they want and if they run into something problematic that requires everything to be reverted, they have something to fall back on to. They can also created their own versions without tampering with the original code. It's a very handy thing to have in a group project, especially when these groups can grow to huge sizes and it becomes a logistical nightmare having to keep everyone up to date.
Initially, I found configuration management systems to be somewhat time consuming as I only considered myself as the sole developer. By thinking about how it would benefit groups, it sounded much more appealing. When I first started using Google Project Hosting, I found it confusing as everything was not immediately apparent to me. There were not any descriptions of which link went to where. It took me a while to find out how to upload my Robocode. After I got done uploading, something seemed to click and I grasped everything Google Project Hosting offered easily. I was able to add another committer to my project, create labels, add wiki pages, and edit my front page so the wiki page shows on the front page.
I have learned how important it is to have a backup not just for in case something happens, but for software development. I also learned how to use Google Project Hosting as a repository for all of my source code. It was not hard to learn to use it because what I mostly did was click on every link and read everything that it told me to do.
My Google Project can be found at http://code.google.com/p/roocode-wca-chinpogum/
Backing up source code is no laughing matter, because a catastrophes may be uncommon, but when they do happen, you had better be prepared for the worst. It is especially shameful when creating backups is extremely easy and painless. Google Project Hosting provide free online storage for code backups so you have no excuse to not have a backup of everything important you have online.
Having a backup is also not just useful for cataclysmic events, but they also help speed up development. Backups are extremely important in the configuration management systems. They are a set of ideas of how software developers would develop their programs. Using configuration management, software developers will have a version to fall back on, so can code all they want and if they run into something problematic that requires everything to be reverted, they have something to fall back on to. They can also created their own versions without tampering with the original code. It's a very handy thing to have in a group project, especially when these groups can grow to huge sizes and it becomes a logistical nightmare having to keep everyone up to date.
Initially, I found configuration management systems to be somewhat time consuming as I only considered myself as the sole developer. By thinking about how it would benefit groups, it sounded much more appealing. When I first started using Google Project Hosting, I found it confusing as everything was not immediately apparent to me. There were not any descriptions of which link went to where. It took me a while to find out how to upload my Robocode. After I got done uploading, something seemed to click and I grasped everything Google Project Hosting offered easily. I was able to add another committer to my project, create labels, add wiki pages, and edit my front page so the wiki page shows on the front page.
I have learned how important it is to have a backup not just for in case something happens, but for software development. I also learned how to use Google Project Hosting as a repository for all of my source code. It was not hard to learn to use it because what I mostly did was click on every link and read everything that it told me to do.
My Google Project can be found at http://code.google.com/p/roocode-wca-chinpogum/
Professional Robocode Player
Serious development for serious Robocode competitions will require serious testing. While the competition is a whiles away, I will still need to individually test each behavior of my robot. To do this, I will have to perform something called "behavioral testing." Behavioral testing is the practice of testing individual features in a controlled environment using JUnit which is provided by Eclipse.
The art of behavioral testing itself isn't something that is picked up easily. The idea of choosing scenarios can have many different factors, most of which you will never think of because you do not have all the time in the world to think of them. Behavioral testing is still an important function within software development because it helps expose logic errors that would otherwise be missed. Logic errors being that they are technically correct, but the code does not perform the way you want. It is also a cheap and fast way to expose logic errors.
I designed my robot to be as reactive as possible instead of merely pointing and shooting. I chose to make my robot ram its targets as I want to gain as much points as possible. At the moment, when my robot finds a target, it will stay on that target and nothing else, hence it has tunnel vision. It does not have very good situational awareness. Lastly, I try to reserve the shooting as much as possible. When my robot scans a target, it does not immediately fire at it. Rather, it will ram the target and them fire. It will also return fire in the direction the bullet came from, which is problematic because it stops my robot from moving and resets the scanner. It will also fire at the target if it stays still too long.
So far, my robot has performed poorly against all the robots. Especially against wall robots. I am not proud of my robot. Here are the percentages of how often my robot wins against the samples:
Sitting Duck: 100%
Walls: 10%
Crazy: 40%
Spin: 30%
Corners: 50%
I learned a very important lesson doing this. Despite the fact that I could visually inspect how well my robot is doing, I could find out so much more faster when I can run multiple tests alongside each other with minimal time involved. The behavioral tests are an invaluable tool for finding bugs.
The art of behavioral testing itself isn't something that is picked up easily. The idea of choosing scenarios can have many different factors, most of which you will never think of because you do not have all the time in the world to think of them. Behavioral testing is still an important function within software development because it helps expose logic errors that would otherwise be missed. Logic errors being that they are technically correct, but the code does not perform the way you want. It is also a cheap and fast way to expose logic errors.
I designed my robot to be as reactive as possible instead of merely pointing and shooting. I chose to make my robot ram its targets as I want to gain as much points as possible. At the moment, when my robot finds a target, it will stay on that target and nothing else, hence it has tunnel vision. It does not have very good situational awareness. Lastly, I try to reserve the shooting as much as possible. When my robot scans a target, it does not immediately fire at it. Rather, it will ram the target and them fire. It will also return fire in the direction the bullet came from, which is problematic because it stops my robot from moving and resets the scanner. It will also fire at the target if it stays still too long.
So far, my robot has performed poorly against all the robots. Especially against wall robots. I am not proud of my robot. Here are the percentages of how often my robot wins against the samples:
Sitting Duck: 100%
Walls: 10%
Crazy: 40%
Spin: 30%
Corners: 50%
I learned a very important lesson doing this. Despite the fact that I could visually inspect how well my robot is doing, I could find out so much more faster when I can run multiple tests alongside each other with minimal time involved. The behavioral tests are an invaluable tool for finding bugs.
Subscribe to:
Comments (Atom)