Modern society depends greatly on energy. Cars need gasoline to go anywhere (aside from downhill). Cell phones need batteries to operate. Software engineers need electricity to power their computers so that they can write blog entries. While this dependency upon energy is not necessarily a bad thing—cars, cell phones, and software engineers certainly offer their conveniences—this relationship between society and energy does create the potential for problems. Hawaii, as a very unique place, has unique strengths and weaknesses in working with energy.
At first glance, Hawaii would seem to have several severe disadvantages when considering energy needs. Being an archipelago rather far away from any typical sources of energy does make certain options unviable. Oil, which is what many people automatically think of when asked about energy sources, is not naturally found in Hawaii and must be imported. The same is true of many other raw materials used in energy production. Since these materials must be imported, they are much more expensive in Hawaii than in other locations. The fact that Hawaii is comprised of a number of islands also makes them divided, unable to easily share what energy they can produce with one another. These islands are also different from one another in many respects, such that a solution that works on one island may be unworkable on another.
There also exist concerns about the usage of land on which energy development might take place. As with most land issues, there are those who own the land, those who think they own the land, and those who know that they do not own the land but want everyone to think that they do. Across all of these situations though, there is the need to carefully consider a wide range of factors when constructing facilities for energy production. The islands of Hawaii have a very limited amount of land for development, so any plans to use the land must be well thought out. Residents may not want to live near a power plant, or fertile land may be better used for agriculture.
On the other hand, the Hawaiian Islands also provide certain unique benefits and opportunities in regards to energy development. Hawaii offers a great variety of renewable resources. While Hawaii does not always fit the tourist ideal of bright sunny skies, solar energy seems to be a common choice for alternative energy, especially for residential areas. Geothermal energy is also a possibility at the State or county level, though trying to use it for individual houses would be questionable (though as with anything involving heat and particularly magma, it would certainly be interesting; a moat of lava would probably be effective at keeping trick-or-treaters away).
Even the negative characteristics of Hawaii in terms of energy development can be turned into positives given the right frame. The current cost of energy provides an incentive to find some cheaper sources of energy, and the cost of those alternatives compared to those of more conventional methods certainly seems much more appealing than it might otherwise. The limited, isolated nature of the Hawaiian Islands can also serve as a positive factor in that the energy needs are also relatively limited.
Energy production in Hawaii offers several opportunities for software engineers to participate in research. Researchers will often benefit from having tools that can analyze the data that they obtain. The data itself is just numbers; software engineers can present that data in a meaningful form not only to the researchers but to the participants and even to the general public. Software engineers can also help in providing quality assurance tools to verify the data that the researchers gather. With the amount of money invested in this sort of research, ensuring that the results are valid becomes extremely important. On a larger scale though, most of the research on energy focuses on hardware solutions: building a particular power plant, or monitoring fluctuations in energy use in different locations. Software engineers can add a software-based perspective to solving energy problems. For example, given the problem of the lights in houses being left on throughout the night, a hardware solution might involve light bulbs that are energy-efficient and circuits that automatically shut off after a certain amount of time. While this works, the hardware solution is also rather inflexible—if the user wants to keep the lights on, he or she would have to manually turn the lights back on each time the lights automatically turned off. In contrast, a software solution might involve a program allowing the user to select how long to leave the lights on before automatically turning off, with the ability to make exceptions in special cases or account for variables, perhaps giving warnings at intervals before the lights are automatically turned off.
Monday, October 31, 2011
Friday, October 21, 2011
Reflections on Software Engineering
Over the past few months, I have been learning a great deal about various tools for use in software engineering as well as the principles behind their use. Of course, the actual use of these tools tends to take precedence in most of these blog entries since that tends to be the more exciting topic. Actually doing something is more glamorous than sitting around discussing theory. However, every once in a while there is the desire to relax and look back on these general principles. This is particularly true for students, who can use the study as a means of procrastinating on other assignments while still doing something academically related.
For these reasons, I have started reflecting on what I have done over these months and have found some questions that I have learned to answer through the work I have done.
1: How does an IDE differ from a build system?
An IDE allows developers to write, compile, and test code on their own systems. Build systems provide standardized compilation, testing, packaging, and automated quality assurance that works across platforms and IDEs. IDEs are suited for individual developers; build systems allow for efficient collaboration between project members. All functions of a build system should be IDE-independent.
2: What is the difference between using == and equals to test equality?
When used with objects, == tests object identity, while the equals method tests object value. As a result, == should be used to check if objects are the same—that is, if one object literally is the other—while equals should be used to determine if two objects have the same value.
3: In what order will Ant resolve dependencies?
Ant will not run a target until all dependencies for that target have been resolved. As a result, the target order will be like a stack in which the first targets are the last to be executed.
4: Does 100% coverage from a white-box test mean that the code is free of bugs?
No; 100% coverage only indicates that the test or tests went through every line of code. This result does not mean that there were no errors in the operation of the application.
5: If the trunk of an SVN project is always supposed to be a working version of the project, why is it necessary to run the “verify” target upon checkout of an updated version?
Running the “verify” target ensures that the updated version does in fact work. The fact that the trunk should always be a working version does not necessarily mean that it will always be a working version. If this initial use of “verify” does not produce any errors, then any errors that are produced after edits to the code must be due to those edits, making resolving those problems easier. However, if the trunk does not pass the “verify” target, then the trunk should be fixed before development can progress further.
For these reasons, I have started reflecting on what I have done over these months and have found some questions that I have learned to answer through the work I have done.
1: How does an IDE differ from a build system?
An IDE allows developers to write, compile, and test code on their own systems. Build systems provide standardized compilation, testing, packaging, and automated quality assurance that works across platforms and IDEs. IDEs are suited for individual developers; build systems allow for efficient collaboration between project members. All functions of a build system should be IDE-independent.
2: What is the difference between using == and equals to test equality?
When used with objects, == tests object identity, while the equals method tests object value. As a result, == should be used to check if objects are the same—that is, if one object literally is the other—while equals should be used to determine if two objects have the same value.
3: In what order will Ant resolve dependencies?
Ant will not run a target until all dependencies for that target have been resolved. As a result, the target order will be like a stack in which the first targets are the last to be executed.
4: Does 100% coverage from a white-box test mean that the code is free of bugs?
No; 100% coverage only indicates that the test or tests went through every line of code. This result does not mean that there were no errors in the operation of the application.
5: If the trunk of an SVN project is always supposed to be a working version of the project, why is it necessary to run the “verify” target upon checkout of an updated version?
Running the “verify” target ensures that the updated version does in fact work. The fact that the trunk should always be a working version does not necessarily mean that it will always be a working version. If this initial use of “verify” does not produce any errors, then any errors that are produced after edits to the code must be due to those edits, making resolving those problems easier. However, if the trunk does not pass the “verify” target, then the trunk should be fixed before development can progress further.
Wednesday, October 19, 2011
Configuration Management
Configuration management was relatively easy after the work done on the competitive Robocode robot. I was greatly aided in this in that I had previously used Google Project Hosting for another project, though my experiences with the service were somewhat mixed. Because I had no experience with SVN at that time, I was limited to editing the files that were already on the project page, which meant updating files one at a time. Obviously, this was a terribly inefficient method of working on the project. There were ultimately never any problems with the project not working—unless someone attempted to checkout the project while I was between updating files, no one would notice that the files were out of sync—but still, there was that risk, and there was also the danger that I might forget to update one or more files, resulting in a final product that did not work. On the positive side, having to update files one by one meant that I was recorded as making a lot of updates to the code, so someone taking a casual glance at the list of updates would assume that I was doing my fair share of the work.
I was successful in making updates to a sample project page and creating a project site for my own DeaconBlues Robocode robot. In doing this, I learned how to use Google Project Hosting and TortoiseSVN. There was a mild issue with TortoiseSVN in that the latest version does not support Windows XP with Service Pack 2, which is what my current system uses, so I am using version 1.6.16. However, at least for these early stages where I only have to checkout, update, and commit files, any loss in functionality is not noticeable.
Obviously, using SVN to commit changes to a project all at once is much easier than going through all of the files one by one. TortoiseSVN is a very convenient, clever system that allows me to easily commit changes. I remain more ambivalent about Google Project Hosting; though it certainly does what it is supposed to, I still think that being able to upload and especially to delete files through Google Project Hosting itself should be much easier than it is now. Although I can work around this with SVN (and doing so is in fact better since it allows me to run a verification check before committing the change), I think that since the files are on the project site, it should be possible to add to or delete from that set of files through the project site.
Overall though, this first experience with SVN and configuration management was positive. I can see how Google Project Hosting will be very useful for collaboration with others in the future.
I was successful in making updates to a sample project page and creating a project site for my own DeaconBlues Robocode robot. In doing this, I learned how to use Google Project Hosting and TortoiseSVN. There was a mild issue with TortoiseSVN in that the latest version does not support Windows XP with Service Pack 2, which is what my current system uses, so I am using version 1.6.16. However, at least for these early stages where I only have to checkout, update, and commit files, any loss in functionality is not noticeable.
Obviously, using SVN to commit changes to a project all at once is much easier than going through all of the files one by one. TortoiseSVN is a very convenient, clever system that allows me to easily commit changes. I remain more ambivalent about Google Project Hosting; though it certainly does what it is supposed to, I still think that being able to upload and especially to delete files through Google Project Hosting itself should be much easier than it is now. Although I can work around this with SVN (and doing so is in fact better since it allows me to run a verification check before committing the change), I think that since the files are on the project site, it should be possible to add to or delete from that set of files through the project site.
Overall though, this first experience with SVN and configuration management was positive. I can see how Google Project Hosting will be very useful for collaboration with others in the future.
Tuesday, October 11, 2011
Competitive Robocode Robot
Overview
In continuation of my work on the Robocode and Ant katas, I have produced a competitive robot called “DeaconBlues” (though represented as “deaconblues” in Robocode itself) for use in the Robocode system. I use “competitive” in the loosest possible sense, of course; this particular robot has difficulty even in defeating some of the sample robots. However, this robot does have the potential to succeed so long as circumstances are not too adverse.
My objective in this project was to create a robot that could reliably defeat the sample Walls robot; my understanding from my initial observations of Robocode was that Walls would be the most difficult to fight against. However, I spent most of the time from when I finished the Robocode katas until the present on developing a targeting system that would have been extremely valuable in any competitive robot. Of course, being able to track an enemy is useful for any target, not just against Walls. I actually did manage to implement my system a few days before this writing. It was fast, reasonably efficient, and only required knowledge of basic trigonometry to understand. It also did not work, which was a significant problem.
Fortunately, I also had a backup plan for a robot that focused primarily on defeating Walls. This robot is described below.
Design
Movement
DeaconBlues moves in a pattern very similar to that of Walls in that it circles around the outer edge of the field. When fighting against robots that are not Walls, DeaconBlues and Walls are virtually identical in their movement. However, when DeaconBlues detects an enemy that appears to be using a Walls strategy, it determines whether the enemy is moving clockwise or counterclockwise around the field and then goes in the opposite direction. The hope is that doing so will result in a situation such as that in the picture below.
The sample Walls robot always tries to face toward the center of the field. This leaves its flanks vulnerable as it moves along the edges. As the picture shows, DeaconBlues is able to fire at Walls without fear of counterattack, even though Walls has nearly seventy more energy than DeaconBlues does. In fact, a few seconds later DeaconBlues was able to destroy Walls through a combination of ramming and shooting.
Targeting
Unfortunately, targeting is one of the weak points in DeaconBlues. Without the working targeting system that I was hoping to develop, DeaconBlues must simply fire upon seeing an enemy and hope that it is still there when the bullet arrives. DeaconBlues also falls a bit short in selecting targets, though this is not as great a problem if DeaconBlues only has to deal with a single opponent at a time. The one aspect of targeting that DeaconBlues is reasonably competent in is remembering the characteristics of its targets; the downside is that DeaconBlues must thus focus wholly on a single target or else invalidate all that information.
Firing
DeaconBlues is somewhat weak in terms of firing, for the same reasons as its weakness in targeting. However, DeaconBlues does have a formula to determine the strength of its shots, accounting for factors such as enemy velocity, heading, bearing, and distance. As mentioned in the Targeting section, DeaconBlues fires as soon as it sees its target. Aside from quite possibly missing a moving target, this makes it difficult to hit even stationary targets at times. This is because DeaconBlues fires as soon as its radar detects the target, which is in the moment when the radar touches the edge of the enemy. As a result, DeaconBlues is aiming for the edge, not the center of the enemy, and thus from difficult angles misses are much more common for DeaconBlues.
Results
DeaconBlues can reliably beat any of the sample robots provided with Robocode. The results provided here may be slightly optimistic about the performance of DeaconBlues, as usually the scores are much closer. Nonetheless, DeaconBlues has an excellent record against the sample robots, with single defeats only to SpinBot, Tracker, and Walls.
SpinBot is difficult to fight against largely because of the circular motion, which makes aiming difficult. The same problem exists for Crazy, but SpinBot has a more regular pattern. Since DeaconBlues moves along the walls, if SpinBot is also near a wall that DeaconBlues must pass by there will inevitably be some shots exchanged.
Losing to Tracker was a bit of a surprise. My best guess as to what happened is that DeaconBlues was stuck in a corner at some point where Tracker should shoot at DeaconBlues while DeaconBlues was too focused on escaping to fight back.
I had anticipated that Walls would be a difficult opponent. I believe that this is so because Walls stays on the outside, away from danger, where enemies only have 180 degrees of space in which to aim at Walls. Walls also benefits from constantly moving around, making it difficult for opponents to aim shots. Since it is a very effective strategy, I integrated it into DeaconBlues as its course of action when not hunting down Walls.
Improvements to DeaconBlues would naturally be in the area where it is currently weakest: targeting. A good targeting system should make DeaconBlues a much more effective combatant.
Testing
Testing DeaconBlues provided another level of challenges to overcome. This was really my first time working with JUnit, and as such there were a few early struggles to deal with. After the initial learning curve though, JUnit was not too difficult to get used to.
I created six separate tests for DeaconBlues. The first two tests were fairly simple initially, as I only had to set up SpinBot and Walls to fight against DeaconBlues. As is usual for me though, I managed to make both more complicated than necessary. DeaconBlues only has to beat SpinBot seventy-five percent of the time to pass the test, and to pass Walls DeaconBlues must obtain more points than Walls during their fights. Despite these tests being objectively rather easy, DeaconBlues has some difficulty with them. DeaconBlues is not a very consistent competitor: on one test it might win all of its matches against Walls while on the next it must struggle to win half of the battles.
Three of the other tests focused on the behavior of DeaconBlues. One tested the ability of DeaconBlues to move to the corners. Since the decision of which corner to move to is somewhat random, this test looks more at how truly random the randomizing method is, keeping track of how often DeaconBlues moves to each corner and examining whether the time spent at these different corners is equally distributed amongst the corners. Another test examines the ability of DeaconBlues to evade enemy fire. That test is slightly inaccurate: it does notice when DeaconBlues takes damage, but it does not adequately discern between the different potential causes for the change in energy. DeaconBlues could have fired its cannon or run into an enemy, both of which could also cause a decrease in energy. The final behavioral test is on the accuracy of fire that DeaconBlues has. As noted above, DeaconBlues is horribly inaccurate.
The last test is a fairly simple unit test that runs through some of the utility methods in DeaconBlues. The calculations are nothing too intensive, and one could probably go through them even without a calculator to prove that DeaconBlues is performing as expected in that regard.
Lessons Learned
I have learned that software engineering is certainly a very intensive process. As I write this, I have spent three of the last four nights without sleep in order to work on DeaconBlues. At the same time, the work is amongst the most rewarding that I have ever done. I enjoy the work, and perhaps the fact that it is an enjoyable project helps as well.
From the perspective of software development, in the future I would prefer to incorporate testing into my project much earlier than I did this time. Checkstyle in particular caused a brief moment of panic when it informed me that I had twenty-seven errors to fix this past evening. Most of those errors were in regards to not simplifying expressions (ex. writing “if (isWalls == true)” instead of just “if (isWalls).”) My instinctive reaction to this was to remove the Boolean value and the comparison from all of the lines that Checkstyle warned about, grumbling that this would make the code more difficult to understand. This had an immediate effect on the code, as “if (isWalls == false)” is somewhat different in meaning from “if (isWalls).” Fortunately, I was able to find and fix these errors (at least the ones that I could find). In any event, this sort of testing would be better done earlier in the development process so that these problems could be discovered and resolved with less difficulty.
In continuation of my work on the Robocode and Ant katas, I have produced a competitive robot called “DeaconBlues” (though represented as “deaconblues” in Robocode itself) for use in the Robocode system. I use “competitive” in the loosest possible sense, of course; this particular robot has difficulty even in defeating some of the sample robots. However, this robot does have the potential to succeed so long as circumstances are not too adverse.
My objective in this project was to create a robot that could reliably defeat the sample Walls robot; my understanding from my initial observations of Robocode was that Walls would be the most difficult to fight against. However, I spent most of the time from when I finished the Robocode katas until the present on developing a targeting system that would have been extremely valuable in any competitive robot. Of course, being able to track an enemy is useful for any target, not just against Walls. I actually did manage to implement my system a few days before this writing. It was fast, reasonably efficient, and only required knowledge of basic trigonometry to understand. It also did not work, which was a significant problem.
Fortunately, I also had a backup plan for a robot that focused primarily on defeating Walls. This robot is described below.
Design
Movement
DeaconBlues moves in a pattern very similar to that of Walls in that it circles around the outer edge of the field. When fighting against robots that are not Walls, DeaconBlues and Walls are virtually identical in their movement. However, when DeaconBlues detects an enemy that appears to be using a Walls strategy, it determines whether the enemy is moving clockwise or counterclockwise around the field and then goes in the opposite direction. The hope is that doing so will result in a situation such as that in the picture below.
The sample Walls robot always tries to face toward the center of the field. This leaves its flanks vulnerable as it moves along the edges. As the picture shows, DeaconBlues is able to fire at Walls without fear of counterattack, even though Walls has nearly seventy more energy than DeaconBlues does. In fact, a few seconds later DeaconBlues was able to destroy Walls through a combination of ramming and shooting.
Targeting
Unfortunately, targeting is one of the weak points in DeaconBlues. Without the working targeting system that I was hoping to develop, DeaconBlues must simply fire upon seeing an enemy and hope that it is still there when the bullet arrives. DeaconBlues also falls a bit short in selecting targets, though this is not as great a problem if DeaconBlues only has to deal with a single opponent at a time. The one aspect of targeting that DeaconBlues is reasonably competent in is remembering the characteristics of its targets; the downside is that DeaconBlues must thus focus wholly on a single target or else invalidate all that information.
Firing
DeaconBlues is somewhat weak in terms of firing, for the same reasons as its weakness in targeting. However, DeaconBlues does have a formula to determine the strength of its shots, accounting for factors such as enemy velocity, heading, bearing, and distance. As mentioned in the Targeting section, DeaconBlues fires as soon as it sees its target. Aside from quite possibly missing a moving target, this makes it difficult to hit even stationary targets at times. This is because DeaconBlues fires as soon as its radar detects the target, which is in the moment when the radar touches the edge of the enemy. As a result, DeaconBlues is aiming for the edge, not the center of the enemy, and thus from difficult angles misses are much more common for DeaconBlues.
Results
DeaconBlues can reliably beat any of the sample robots provided with Robocode. The results provided here may be slightly optimistic about the performance of DeaconBlues, as usually the scores are much closer. Nonetheless, DeaconBlues has an excellent record against the sample robots, with single defeats only to SpinBot, Tracker, and Walls.
SpinBot is difficult to fight against largely because of the circular motion, which makes aiming difficult. The same problem exists for Crazy, but SpinBot has a more regular pattern. Since DeaconBlues moves along the walls, if SpinBot is also near a wall that DeaconBlues must pass by there will inevitably be some shots exchanged.
Losing to Tracker was a bit of a surprise. My best guess as to what happened is that DeaconBlues was stuck in a corner at some point where Tracker should shoot at DeaconBlues while DeaconBlues was too focused on escaping to fight back.
I had anticipated that Walls would be a difficult opponent. I believe that this is so because Walls stays on the outside, away from danger, where enemies only have 180 degrees of space in which to aim at Walls. Walls also benefits from constantly moving around, making it difficult for opponents to aim shots. Since it is a very effective strategy, I integrated it into DeaconBlues as its course of action when not hunting down Walls.
Improvements to DeaconBlues would naturally be in the area where it is currently weakest: targeting. A good targeting system should make DeaconBlues a much more effective combatant.
Testing
Testing DeaconBlues provided another level of challenges to overcome. This was really my first time working with JUnit, and as such there were a few early struggles to deal with. After the initial learning curve though, JUnit was not too difficult to get used to.
I created six separate tests for DeaconBlues. The first two tests were fairly simple initially, as I only had to set up SpinBot and Walls to fight against DeaconBlues. As is usual for me though, I managed to make both more complicated than necessary. DeaconBlues only has to beat SpinBot seventy-five percent of the time to pass the test, and to pass Walls DeaconBlues must obtain more points than Walls during their fights. Despite these tests being objectively rather easy, DeaconBlues has some difficulty with them. DeaconBlues is not a very consistent competitor: on one test it might win all of its matches against Walls while on the next it must struggle to win half of the battles.
Three of the other tests focused on the behavior of DeaconBlues. One tested the ability of DeaconBlues to move to the corners. Since the decision of which corner to move to is somewhat random, this test looks more at how truly random the randomizing method is, keeping track of how often DeaconBlues moves to each corner and examining whether the time spent at these different corners is equally distributed amongst the corners. Another test examines the ability of DeaconBlues to evade enemy fire. That test is slightly inaccurate: it does notice when DeaconBlues takes damage, but it does not adequately discern between the different potential causes for the change in energy. DeaconBlues could have fired its cannon or run into an enemy, both of which could also cause a decrease in energy. The final behavioral test is on the accuracy of fire that DeaconBlues has. As noted above, DeaconBlues is horribly inaccurate.
The last test is a fairly simple unit test that runs through some of the utility methods in DeaconBlues. The calculations are nothing too intensive, and one could probably go through them even without a calculator to prove that DeaconBlues is performing as expected in that regard.
Lessons Learned
I have learned that software engineering is certainly a very intensive process. As I write this, I have spent three of the last four nights without sleep in order to work on DeaconBlues. At the same time, the work is amongst the most rewarding that I have ever done. I enjoy the work, and perhaps the fact that it is an enjoyable project helps as well.
From the perspective of software development, in the future I would prefer to incorporate testing into my project much earlier than I did this time. Checkstyle in particular caused a brief moment of panic when it informed me that I had twenty-seven errors to fix this past evening. Most of those errors were in regards to not simplifying expressions (ex. writing “if (isWalls == true)” instead of just “if (isWalls).”) My instinctive reaction to this was to remove the Boolean value and the comparison from all of the lines that Checkstyle warned about, grumbling that this would make the code more difficult to understand. This had an immediate effect on the code, as “if (isWalls == false)” is somewhat different in meaning from “if (isWalls).” Fortunately, I was able to find and fix these errors (at least the ones that I could find). In any event, this sort of testing would be better done earlier in the development process so that these problems could be discovered and resolved with less difficulty.
Subscribe to:
Posts (Atom)