Hawaii is in a very unique situation when it comes to the issue of energy. Energy prices in Hawaii can be from 3 to 6 times more expensive than those in the mainland US, these high prices have several causes. One of the main reasons Hawaii has higher energy prices is because of the states dependence on oil, a very high percentage of the energy ( 77 %) created in Hawaii is done so using oil. Oil has to be imported into Hawaii and is also more expensive initially than other resources, like coal, which is greatly used in mainland US production of energy (45 %). Another big difference between Hawaii and the mainland US is that Hawaii has several small power grids it runs off of, while the mainland US has one huge supergrid that deals with all the power supply. Having one large connected grid allows more flexibility than having smaller unconnected grids.
While having more expensive energy sounds like a bad deal, which it is, there is also a silver lining to this issue. Hawaii is lucky enough to have access to a plethora of different kinds of renewable energy resources including wind, geothermal, solar, biofuel etc. and because Hawaii is so dependent on oil when oil prices rise, the cost of oil dependent energy rises along with it. So how could this be a good thing? Renewable energy is expensive, and while the price of renewable energy remains greater than the price of other non renewable energy sources we will continue using these non renewable resources. Because the prices of oil produced energy in Hawaii will continue to rise rapidly into the future and because Hawaii has access to a multitude of renewable energy resources Hawaii is bound to find itself in a situation where renewables will become cheaper than imported oil produced energy, and this transition will happen before most every place in the world. This earlier transition along with support from local government puts Hawaii in a unique situation to get rid of its oil dependencies and also serve as a model for the mainland US, and world wide, on how to transition to renewable energy. This is also advantageous economically because Hawaii may develop new service exports dealing with these issues.
This is a software engineering log so lets talk software. This transition into renewable energy resources here in Hawaii has already begun, and it has funding. Along with the new technologies that are being developed and the studies being conducted there is a demand for software that can deal with these complex issues. As the movement towards green energy gains momentum there will be a lot of new opportunities for developing these new systems. This puts us future and current developers and researchers in a great situation in which we are looking at a potentially explosive field, not just in Hawaii but throughout the US, and one ground zero may in fact be Hawaii. Hawaii will be one of the first places to adopt renewable energies on a large scale and the associated software that supports these new systems, these new systems can potentially serve as a model for the rest of the US and other places in the world, which puts us in a very interesting and exciting situation.
While this is very exciting, it is also very difficult. There are many new and interesting challenges that have to be addressed and overcome and there are people that support the movement to renewable energy and those who also oppose it. Along with the development of new software and technologies that will make this transition possible, there are also political challenges such as local opposition to building windmills and geothermal plants on the islands especially when its to support the energy consumption of another island which is the issue of the very centralized use of power on Oahu compared to the other islands and how that can be dealt with.
To learn more please check out this series:
Click Here
Friday, October 28, 2011
Thursday, October 20, 2011
Review
What are the positives and negatives of a walkthrough code review?
Positive: cheap
Negative: unreliable Information/quality
Positive: cheap
Negative: unreliable Information/quality
Name 6 instances in which the verify.build.xml command can fail.
PMD, Checkstyle, FindBugs, Junit, JavaDoc, any .xml file error
PMD, Checkstyle, FindBugs, Junit, JavaDoc, any .xml file error
Explain the What X and Y are, and their relationship to each other:
<target name="X" depends="Y"....
X is the name of the target, Y is a dependency of the target, meaning X will not execute unless Y does.
X is the name of the target, Y is a dependency of the target, meaning X will not execute unless Y does.
Give an example of an error that would only be found by Find Bugs.
while (true) {
while (true) {
....
}
What is the shared data problem in respect to a RCS.
The shared data problem occurs when two developers want to edit/work with the same data or file in a project.
}
What is the shared data problem in respect to a RCS.
The shared data problem occurs when two developers want to edit/work with the same data or file in a project.
Wednesday, October 19, 2011
Configuration Management and Google Project Hosting
In order to streaming a software development process among a software team it is extremely valuable to utilize a configuration management system, a way to control the development process when multiple software developers are writing/editing possibly interdependent code. Without a configuration management system problems may arise during development such as inconsistant code among developers, no clear indication of when the system started or stopped working properly and what code was responsible, the problem of simultaneous updates which cause "clobbering" aka only one persons code being uploaded and the shared data problem which arises when two developers need to work on the same file/data.
Version control is a type of configuration management whose main goal is to maintain multiple versions of the system. Google Project Hosting is a version control system that uses Subversion, which is one of many different version control systems. Subversion uses a central repository, or a complete and always up to date version of the software project that can be checked out, modified (on an individual basis) and committed(update change/s to repository) by developers. Each commit made by developers is tracked by Subversion so that there is always a reference to each update in the system, which makes it easy to locate when and where an error occurred. Subversion also prevents clobbering, by maintaing each developers version of the repository through updates, and allows each developer to have a complete version of the system, which eliminates the shared data problem.
Getting a project started with Google project hosing is relatively simple, you just have to give it a name, upload files to the repository, and provide supporting documentation for users and developers. After that you are ready to start adding developers to the project. Here is an example of my first project through Google Project Hosting:
The above is the front page of my hosted project, as you can see we have a description in the text field of the project, there are multiple tabs at the top including downloads, wiki( aka documentation), issues and source. If you wanted to check out this project you would do so from the source tab, if you wanted a distribution of the system you could find a .jar file under downloads. please feel free to explore this project to get comfortable navigating a Google hosted project.
This is a project which contains my competitive Robocode robot. Please see previous posts if you are curious to what that is:
Java fueled robots
and
GreenMachine
Setting up a project in Google Project Hosting is straight forward, things that I found can tie you up a little would be the documentation, and making sure that the files in your repository are in the correct place. A few of the small things can be a little confusing but everything you need to know for setting up an new project can be found here if you get stuck:
Getting Started
This is a free and powerful tool for team software development, and as a side note in order to properly use a Subversion system you need to have a Subversion client on your machine, this is the one I am using for Mac.
SmartSVN
How to use a Subversion client is a whole different topic. You can use the documentation on the above website to get started.
Version control is a type of configuration management whose main goal is to maintain multiple versions of the system. Google Project Hosting is a version control system that uses Subversion, which is one of many different version control systems. Subversion uses a central repository, or a complete and always up to date version of the software project that can be checked out, modified (on an individual basis) and committed(update change/s to repository) by developers. Each commit made by developers is tracked by Subversion so that there is always a reference to each update in the system, which makes it easy to locate when and where an error occurred. Subversion also prevents clobbering, by maintaing each developers version of the repository through updates, and allows each developer to have a complete version of the system, which eliminates the shared data problem.
Getting a project started with Google project hosing is relatively simple, you just have to give it a name, upload files to the repository, and provide supporting documentation for users and developers. After that you are ready to start adding developers to the project. Here is an example of my first project through Google Project Hosting:
The above is the front page of my hosted project, as you can see we have a description in the text field of the project, there are multiple tabs at the top including downloads, wiki( aka documentation), issues and source. If you wanted to check out this project you would do so from the source tab, if you wanted a distribution of the system you could find a .jar file under downloads. please feel free to explore this project to get comfortable navigating a Google hosted project.
This is a project which contains my competitive Robocode robot. Please see previous posts if you are curious to what that is:
Java fueled robots
and
GreenMachine
Setting up a project in Google Project Hosting is straight forward, things that I found can tie you up a little would be the documentation, and making sure that the files in your repository are in the correct place. A few of the small things can be a little confusing but everything you need to know for setting up an new project can be found here if you get stuck:
Getting Started
This is a free and powerful tool for team software development, and as a side note in order to properly use a Subversion system you need to have a Subversion client on your machine, this is the one I am using for Mac.
SmartSVN
How to use a Subversion client is a whole different topic. You can use the documentation on the above website to get started.
Tuesday, October 11, 2011
GreenMachine ! Robocode robot
I have just completed my first battle ready Robocode robot that I named GreenMachine! If you are unfamiliar with the Robocode project you can read up on my previous post here:
robocode
If you want to download a distribution of my robot you can find it on my site:
Robot Distribution
The creation of this robot was inspired by a upcoming Robocode competition among some of my fellow classmates, I wish them well.. but I believe that the GreenMachine will do well given the short amount of time given for development of robots for the competition. The GreenMachine is a robocode robot that extends only the robot class, not the junior robot or advanced robot, which means that there are a lot less built in methods to utilise. Most of my robot is composed of original code except for one method I use to linear target robots that move in 90 degree angles, (such as sample.walls). the design ideas that I implemented are as follows:
Movment:
For my movement I could not think of a good way to avoid being hit except to be unpredictable... so what better way to be unpredictable then to use sporadic sudo random movements. For my movement method I use a built in Java random number generator and generate a random degree between 0-300 and a distance between 75-100 pixels. I chose to move such a short maximum distance per turn because moving in one way for any extended time will give an opponent a chance to preform linear targeting on my robot. This movement seems to evade a lot of shots, but we will see how it preforms in competition. A way to improve on this move method (I didn't have the time to) was to eliminate the possibility of moving directly towards or away from the enemy, as this would not change you retaliative bearing in comparison to the enemy.
Targeting/Firing:
For my targeting I continuously scan the field between moves and acquire a target. Once my target is acquired I will shoot a bullet at their bearing with power retaliative to their distance from my robot (farther away less power). If a shot hits its target then the overridden method onBulletHitEvent will immediately fire a mid-power bullet to the same X any Y coordinates that the first bullet struck the enemy, it does this after it moves just in case the enemy fire a retaliation shot in the direction it was struck by my bullet. In the event that my robot comes close to the enemy, within 100 pixels, the GreenMachine will charge its enemy full speed and on contact with the enemy fire a shot with maximum power, this method of close combat seems to work great. In the event that a robot is moving in 90 degree angles like sample.walls, GreenMachine will change its behaviour and use linear targeting to make shots that try and intercept the enemies future location. This behaviour was used from
walls killer
and was the only code in my robot that I did not write. Finally in the event my robot is hit by the enemies bullet I immediately fire a retaliation shot in the direction it came from then move.
Results of my Labor:
GreenMachine can beat most of the sample bots reliably including Walls, RamFire, Crazy, Fire, Corners, Tracker, SittingDuck. It does have some trouble with SpinBot because it does not have a method for dealing with circular predictive targeting, therefore it wins about half the time against SpinBot. To improve on this I need to create a way of identifying robots that move in circles and devise a way to track them.
Lets Take a Look: I suggest watching it expanded and in HD on YouTube.
Testing:
For my testing methods, I used Junit tests to judge my robots progress by having 10 round battle results quickly evaluated for each of the sample robots. This allowed me to quickly see the effect of any change I mad to my robot. In addition to these battle simulations I also tested different methods of my robot such as my firing techniques and my robots responses to events such as impact with another robot and impact with walls. I also utilised JaCoCo to see the coverage of my tests.
Lessons Learned:
I learned a lot from this project, I learned about creating a more advanced robot and how complicated robots can get. I also learned a lot of valuable skill on how to use Junit tests to test a program as well as guide the progress of software development. Throughout this experience I was utilising the Ant build system and therefore became very familiar with how the Ant and .xml files used in ant work. Towards the end of the development of GreenMachine I was utilizing Ant + Ivy in an efficient way. It has also become very clear to me the value of using a build system when developing software among multiple software developers. From a software perspective I would become very familiar with my build system before writing any code, and from a Robocode developer perspective I would search every nook and cranny of the Robocode API before beginning development to save on time and effort. I found that writing Junit tests after I began this project was difficult, If I could do it over again I would like to try the approach of writing my Junit tests before the code they are meant to test.
robocode
If you want to download a distribution of my robot you can find it on my site:
Robot Distribution
The creation of this robot was inspired by a upcoming Robocode competition among some of my fellow classmates, I wish them well.. but I believe that the GreenMachine will do well given the short amount of time given for development of robots for the competition. The GreenMachine is a robocode robot that extends only the robot class, not the junior robot or advanced robot, which means that there are a lot less built in methods to utilise. Most of my robot is composed of original code except for one method I use to linear target robots that move in 90 degree angles, (such as sample.walls). the design ideas that I implemented are as follows:
Movment:
For my movement I could not think of a good way to avoid being hit except to be unpredictable... so what better way to be unpredictable then to use sporadic sudo random movements. For my movement method I use a built in Java random number generator and generate a random degree between 0-300 and a distance between 75-100 pixels. I chose to move such a short maximum distance per turn because moving in one way for any extended time will give an opponent a chance to preform linear targeting on my robot. This movement seems to evade a lot of shots, but we will see how it preforms in competition. A way to improve on this move method (I didn't have the time to) was to eliminate the possibility of moving directly towards or away from the enemy, as this would not change you retaliative bearing in comparison to the enemy.
Targeting/Firing:
For my targeting I continuously scan the field between moves and acquire a target. Once my target is acquired I will shoot a bullet at their bearing with power retaliative to their distance from my robot (farther away less power). If a shot hits its target then the overridden method onBulletHitEvent will immediately fire a mid-power bullet to the same X any Y coordinates that the first bullet struck the enemy, it does this after it moves just in case the enemy fire a retaliation shot in the direction it was struck by my bullet. In the event that my robot comes close to the enemy, within 100 pixels, the GreenMachine will charge its enemy full speed and on contact with the enemy fire a shot with maximum power, this method of close combat seems to work great. In the event that a robot is moving in 90 degree angles like sample.walls, GreenMachine will change its behaviour and use linear targeting to make shots that try and intercept the enemies future location. This behaviour was used from
walls killer
and was the only code in my robot that I did not write. Finally in the event my robot is hit by the enemies bullet I immediately fire a retaliation shot in the direction it came from then move.
Results of my Labor:
GreenMachine can beat most of the sample bots reliably including Walls, RamFire, Crazy, Fire, Corners, Tracker, SittingDuck. It does have some trouble with SpinBot because it does not have a method for dealing with circular predictive targeting, therefore it wins about half the time against SpinBot. To improve on this I need to create a way of identifying robots that move in circles and devise a way to track them.
Lets Take a Look: I suggest watching it expanded and in HD on YouTube.
Testing:
For my testing methods, I used Junit tests to judge my robots progress by having 10 round battle results quickly evaluated for each of the sample robots. This allowed me to quickly see the effect of any change I mad to my robot. In addition to these battle simulations I also tested different methods of my robot such as my firing techniques and my robots responses to events such as impact with another robot and impact with walls. I also utilised JaCoCo to see the coverage of my tests.
Lessons Learned:
I learned a lot from this project, I learned about creating a more advanced robot and how complicated robots can get. I also learned a lot of valuable skill on how to use Junit tests to test a program as well as guide the progress of software development. Throughout this experience I was utilising the Ant build system and therefore became very familiar with how the Ant and .xml files used in ant work. Towards the end of the development of GreenMachine I was utilizing Ant + Ivy in an efficient way. It has also become very clear to me the value of using a build system when developing software among multiple software developers. From a software perspective I would become very familiar with my build system before writing any code, and from a Robocode developer perspective I would search every nook and cranny of the Robocode API before beginning development to save on time and effort. I found that writing Junit tests after I began this project was difficult, If I could do it over again I would like to try the approach of writing my Junit tests before the code they are meant to test.
Subscribe to:
Comments (Atom)