I recently had an opportunity to develop experience in issue driven management for a software project. What is "issue driven management", you may be asking? Well, it is a form of project management where the project as a whole is divided into smaller, more manageable portions. These portions, or issues, are then much more easily processed. With this particular project, I was working with a small team of software engineers. In such a scenario, you can then assign issues to each member in order to spread out the work evenly and ensure faster production. Giving people smaller, more specific issues to deal with enables the group to work with less confusion and prevents people from doing work on the same tasks. Each issue can then be broken up into smaller issues and assigned to appropriate members of the team if the issue is initially too large or complicated.
To implement issue driven management for a project, it is best to find a project management solution that allows for communication, issue tracking, and a central repository if you're working with code. My group chose to use Google project hosting at Google Code to host our project. This allowed for us to implement issue generation and tracking, as well as giving us a central repository. Our project was to create a command line interface for the WattDepot application. This command line interface we developed queries the WattDepot server for information about energy usage for the Hale Aloha building at the University of Hawaii at Manoa campus. Our team also used a combination of build automation with Apache's Ant and continuous integration with Jenkins.
Our project team was team "tiger" and the project was named "hale-aloha-cli-tiger", which you can find here at "http://code.google.com/p/hale-aloha-cli-tiger/". All together, the experience was an educational one to say the least. I learned a great deal about working with other people on a project, but also a lot about continuous integration and how you can have a build work locally but then fail an automated build on Jenkins. It certainly slammed the importance of running "ant -f verify.build.xml" before every single commit to the repository! And to make sure that if build directories find themselves in the repository, even if by someone else, you should immediately remove them. This prevents issues with Find Bugs failing a build when the problematic file has been removed. Another thing that is key is communication, which can be relatively difficult when people on the team all have different schedules and heavy commitment loads elsewhere that prevent consistent communication.
My group and I accomplished the task for which we were aiming. It was a great experience, and I enjoyed working with the others. It was a lot of fun and energizing to meet with each other and toss ideas back and forth regarding solutions to problems. I hope that I get another chance to work with each of them and I am glad that I was able to have this experience. We had a few problems, of course as any project might, but my group always came through. Is our project completely done? Well there are always areas in which we can improve a system, but yes it accomplishes what we wanted to achieve. We did a lot of automated quality assurance, but no system can completely account for everything a user can throw at it. Not without a much more exhaustive system of tests.
Tuesday, November 29, 2011
Tuesday, November 1, 2011
Hawaii Has Potential
We live in interesting times. Many people notice when things get rough and they have to shell out tons of money at the gas station. Those same people look at the rising prices in food and amenities, most likely with sighs of frustration and growing concern. In Hawaii, these things may have a heavier impact than that which would be felt by people living in the mainland United States. Much of the food and oil we consume everyday is shipped from sources outside our state. There is also another issue that many families in Hawaii have most likely noticed, issues with power. We see rising costs in our electric bills, and at the same time we perceive waning security with regards to consistent power availability. It doesn't seem to take much to cause 'brown-outs' or temporary 'black-outs' in various neighborhoods throughout the year. Well, there are some interesting possibilities here for those that are willing to look.
As I've mentioned about the growing costs associated with oil and how it affects different areas of our lives such as food and fuel, it also affects our power! Oil based power is prevalent in Hawaii, more so than on the mainland, and increases in oil prices across the world affect the cost of our electricity. If we want to move into the future and embrace growing concepts like clean energy and sustainability, Hawaii's power solutions need to be changed.
In addition to the problems widely known about fossil fuels, Hawaii's power utilities are also having a rough time keeping up with growing power consumption. It may surprise people that Hawaii's power grid is actually comprised of several small isolated grids, especially separated from different islands. If there is a power surplus from another island such as Lanai or Maui, Oahu may not be able to benefit from that power. What will it take to get clean sustainable power for everyone on each island?
One thing that is both promising and at the same time frustrating, is the fact that Hawaii has just about every current clean and sustainable source of power at our finger tips. Those sources remain currently untapped for the most part. We have solar power, wind power, geothermal power, ocean currents, you name it! Why is it that with all this raw power surrounding us, we still rely on oil primarily as a power source. If Hawaii is spending around six billion dollars each year to buy energy from external sources, imagine what opportunities exist for people who can find that power right here in Hawaii! That's right, six billion dollars a year could be funneled back into Hawaii creating jobs and opportunities if we can meet our energy needs independently.
Of course, simply maintaining the same power production and consumption does not address all of our power issues. It is apparent that we also need to find the means to track and monitor power usage so that we can cut expenditures. This has the double advantage of making it easier to switch to less developed sources of power by creating a smaller load, or demand, but will also allow statewide needs to be met consistently when the switch has been made. Tracking features such as 'smart meters' that can electronically monitor power consumption and send that data via wireless connection to the power utility companies will certainly help. This will allow such companies to analyze and monitor consumption habits and patterns. Through incentives, power companies may gain remote access to shut down air conditioners briefly across sections of the island in order to reduce load during peak usage, creating a more stable power grid and reducing the fuel consumed to generate power.
Those of us with interests in software and technology know that information is already a large area of development and opportunity. This certainly applies to our power situation when you realize that power companies will be generating massive amounts of data, without necessarily having software infrastructure to manage all of it. There are potential areas of opportunity in developing database structures and systems, as well as analytical software to glean useful information and trends from all of the raw data. When we add in the potential to one day have all of our power produced locally, that could mean six billion dollars of opportunity for those with an interest in developing power alternatives, but also for those who wish to help manage the information generated in that field.
This is especially true when we realize that solar power is a growing source of independent energy and all of the power generated from homes equipped with that technology needs to be measured and understood. For people whose job it is to balance and maintain a steady power grid, it is vitally important to be able to look at and account for all the power being generated via solar power. This will enable them to redistribute power appropriately. With this also comes a need to track power usage or generation for each home, and with that comes even more data. Software and technology solutions to manage data for each home in Hawaii will not only aid those attempting to move us forward to clean and sustainable energy, but it will provide valuable information and needed transparency to the consumer. It will empower people with the knowledge of how they can reduce wasted energy consumption and lower their electric bill each month. It will also allow people to be a part of and understand Hawaii's power related issues.
If we make changes towards clean, independent energy, and people in the technology field get behind those changes, we can see some wonderful opportunities in the future. Hawaii can generate less pollution, preserve paradise, produce jobs, provide power, and reduce costs in other areas of our lives. What a great potential we have!
As I've mentioned about the growing costs associated with oil and how it affects different areas of our lives such as food and fuel, it also affects our power! Oil based power is prevalent in Hawaii, more so than on the mainland, and increases in oil prices across the world affect the cost of our electricity. If we want to move into the future and embrace growing concepts like clean energy and sustainability, Hawaii's power solutions need to be changed.
In addition to the problems widely known about fossil fuels, Hawaii's power utilities are also having a rough time keeping up with growing power consumption. It may surprise people that Hawaii's power grid is actually comprised of several small isolated grids, especially separated from different islands. If there is a power surplus from another island such as Lanai or Maui, Oahu may not be able to benefit from that power. What will it take to get clean sustainable power for everyone on each island?
One thing that is both promising and at the same time frustrating, is the fact that Hawaii has just about every current clean and sustainable source of power at our finger tips. Those sources remain currently untapped for the most part. We have solar power, wind power, geothermal power, ocean currents, you name it! Why is it that with all this raw power surrounding us, we still rely on oil primarily as a power source. If Hawaii is spending around six billion dollars each year to buy energy from external sources, imagine what opportunities exist for people who can find that power right here in Hawaii! That's right, six billion dollars a year could be funneled back into Hawaii creating jobs and opportunities if we can meet our energy needs independently.
Of course, simply maintaining the same power production and consumption does not address all of our power issues. It is apparent that we also need to find the means to track and monitor power usage so that we can cut expenditures. This has the double advantage of making it easier to switch to less developed sources of power by creating a smaller load, or demand, but will also allow statewide needs to be met consistently when the switch has been made. Tracking features such as 'smart meters' that can electronically monitor power consumption and send that data via wireless connection to the power utility companies will certainly help. This will allow such companies to analyze and monitor consumption habits and patterns. Through incentives, power companies may gain remote access to shut down air conditioners briefly across sections of the island in order to reduce load during peak usage, creating a more stable power grid and reducing the fuel consumed to generate power.
Those of us with interests in software and technology know that information is already a large area of development and opportunity. This certainly applies to our power situation when you realize that power companies will be generating massive amounts of data, without necessarily having software infrastructure to manage all of it. There are potential areas of opportunity in developing database structures and systems, as well as analytical software to glean useful information and trends from all of the raw data. When we add in the potential to one day have all of our power produced locally, that could mean six billion dollars of opportunity for those with an interest in developing power alternatives, but also for those who wish to help manage the information generated in that field.
This is especially true when we realize that solar power is a growing source of independent energy and all of the power generated from homes equipped with that technology needs to be measured and understood. For people whose job it is to balance and maintain a steady power grid, it is vitally important to be able to look at and account for all the power being generated via solar power. This will enable them to redistribute power appropriately. With this also comes a need to track power usage or generation for each home, and with that comes even more data. Software and technology solutions to manage data for each home in Hawaii will not only aid those attempting to move us forward to clean and sustainable energy, but it will provide valuable information and needed transparency to the consumer. It will empower people with the knowledge of how they can reduce wasted energy consumption and lower their electric bill each month. It will also allow people to be a part of and understand Hawaii's power related issues.
If we make changes towards clean, independent energy, and people in the technology field get behind those changes, we can see some wonderful opportunities in the future. Hawaii can generate less pollution, preserve paradise, produce jobs, provide power, and reduce costs in other areas of our lives. What a great potential we have!
Tuesday, October 25, 2011
Things to Ponder
1. What does it mean when projects are created in the "cathedral" versus the "bazaar"?
Typically, the cathedral model is based on having a select group of trained professionals working on a project and closely monitoring its progress. This approach would likely be very controlling and not just anyone would be able to contribute.
The bazaar model would be open to all with little to no oversight and not as much control or management. People would be free to make changes at will and there wouldn't be a clear system of accountability.
2. Which system does an open source project typically look like?
As it turns out, it's a lot more like the cathedral model than people predicted. Most open source projects have a group of people that administrate and monitor changes to the system. They are the ones that give permissions for people to join the project, usually after demonstrating a certain level of professionalism and skill, who can then update and make changes to that system.
3. Why is it good for every programmer to get involved in an open source project?
Being accepted into an open source system as a developer is great for a number of reasons. It establishes a public example of the kind of code you are capable of writing, shows that you have a certain level of proficiency and professionalism, and it shows that you can coordinate in a lucid team environment with people from all over.
4. How many "learn to program in 10 days" books do you need to become a good programmer?
None. The 'best' way to become a 'good' programmer is to get a little experience each day. There are plenty of resources online such as language tutorials, API documentation, discussion forums, etc. that you can learn from. The idea that you can read a few "learn language such-and-such" in a short amount of time and be proficient at it is an error. You really need to take continual steps over a long period of time, closer to 10 years or so, before you really develop a lot of proficiency in a field. It is also good to continually push yourself further in your understanding by challenging yourself as you learn.
5. What are some basics that will be necessary for an interview as a programmer?
First of all, you should not be afraid to write some code in your interview! Be able to at the very least demonstrate a firm understanding of languages that you list on your resume, which means being able to write syntactically correct code from memory without references. One site recommends that you should be able to write code for various abstract data types and implement basic algorithms in each of your "proficient" languages. It is also helpful to know a variety of language types. Somethings are much more difficult to implement in an interview with an imperative language like C++ or Java, but can be accomplished easily with a scripting language like Perl or JavaScript. Also, be sure to know the basics of Object Oriented Programming and the primitive data types. (It also helps to dress for the interview, don't forget to present yourself as a professional in person)
Typically, the cathedral model is based on having a select group of trained professionals working on a project and closely monitoring its progress. This approach would likely be very controlling and not just anyone would be able to contribute.
The bazaar model would be open to all with little to no oversight and not as much control or management. People would be free to make changes at will and there wouldn't be a clear system of accountability.
2. Which system does an open source project typically look like?
As it turns out, it's a lot more like the cathedral model than people predicted. Most open source projects have a group of people that administrate and monitor changes to the system. They are the ones that give permissions for people to join the project, usually after demonstrating a certain level of professionalism and skill, who can then update and make changes to that system.
3. Why is it good for every programmer to get involved in an open source project?
Being accepted into an open source system as a developer is great for a number of reasons. It establishes a public example of the kind of code you are capable of writing, shows that you have a certain level of proficiency and professionalism, and it shows that you can coordinate in a lucid team environment with people from all over.
4. How many "learn to program in 10 days" books do you need to become a good programmer?
None. The 'best' way to become a 'good' programmer is to get a little experience each day. There are plenty of resources online such as language tutorials, API documentation, discussion forums, etc. that you can learn from. The idea that you can read a few "learn language such-and-such" in a short amount of time and be proficient at it is an error. You really need to take continual steps over a long period of time, closer to 10 years or so, before you really develop a lot of proficiency in a field. It is also good to continually push yourself further in your understanding by challenging yourself as you learn.
5. What are some basics that will be necessary for an interview as a programmer?
First of all, you should not be afraid to write some code in your interview! Be able to at the very least demonstrate a firm understanding of languages that you list on your resume, which means being able to write syntactically correct code from memory without references. One site recommends that you should be able to write code for various abstract data types and implement basic algorithms in each of your "proficient" languages. It is also helpful to know a variety of language types. Somethings are much more difficult to implement in an interview with an imperative language like C++ or Java, but can be accomplished easily with a scripting language like Perl or JavaScript. Also, be sure to know the basics of Object Oriented Programming and the primitive data types. (It also helps to dress for the interview, don't forget to present yourself as a professional in person)
Friday, October 14, 2011
Working with Configuration Management
So far, I have had a little experience with configuration management and version control systems. I have currently worked with Unfuddle and recently posted a project on Google Project Hosting. Both of these sites allow for free project management tools and each has SVN hosting. I enjoy working with Unfuddle since it has many useful features, not the least of which is the ability to close tickets from within your SVN commit message. My experience with both of these systems has been extremely positive!
For now, I am going to focus on the project that I recently set up on Google Project Hosting. If you managed to read my last post about a rather dismal Robocode robot named Tankadin, then you know that the robot is not going to win many championships. However, creating the robot, its build system, and now having set up project hosting for it, has all been an interesting endeavor. I have learned a lot about the Java based Ant build system and how to manage a project locally. From there, I have learned more about how to actually host a project and start up a subversion repository. I've already been using subversion for a few months now, so I started this project out with a degree of familiarity.
While I am already used to the idea of configuration management tools due to my experience with Unfuddle, I continue to learn and expand my capabilities and experience as I learn and use other tools. As far as open source projects go, Google Project Hosting is decent in that you can easily set up wiki pages for the general public to inform people of your project and allow for easy downloading to anyone. For my Robocode project, I added a User Guide page which shows anyone how to download and install my robot, Tankadin for target practice. I have also included a Developer Guide that describes what dependencies are needed to make much needed improvements to the robot, as well as information about how to checkout a working copy from the SVN repository. For the developer guide page, I copied the template from another Robocode project.
Right now, I only have one other member to the project, although I would welcome anyone that wanted to work on the robot. My goal is to continue working on the project when I finish more of my current responsibilities and have some free time to spare. If you stumble upon this page, please feel free to check out the project and see what changes have been made. I have a link to it in the first paragraph, but you can also click here.
For now, I am going to focus on the project that I recently set up on Google Project Hosting. If you managed to read my last post about a rather dismal Robocode robot named Tankadin, then you know that the robot is not going to win many championships. However, creating the robot, its build system, and now having set up project hosting for it, has all been an interesting endeavor. I have learned a lot about the Java based Ant build system and how to manage a project locally. From there, I have learned more about how to actually host a project and start up a subversion repository. I've already been using subversion for a few months now, so I started this project out with a degree of familiarity.
While I am already used to the idea of configuration management tools due to my experience with Unfuddle, I continue to learn and expand my capabilities and experience as I learn and use other tools. As far as open source projects go, Google Project Hosting is decent in that you can easily set up wiki pages for the general public to inform people of your project and allow for easy downloading to anyone. For my Robocode project, I added a User Guide page which shows anyone how to download and install my robot, Tankadin for target practice. I have also included a Developer Guide that describes what dependencies are needed to make much needed improvements to the robot, as well as information about how to checkout a working copy from the SVN repository. For the developer guide page, I copied the template from another Robocode project.
Right now, I only have one other member to the project, although I would welcome anyone that wanted to work on the robot. My goal is to continue working on the project when I finish more of my current responsibilities and have some free time to spare. If you stumble upon this page, please feel free to check out the project and see what changes have been made. I have a link to it in the first paragraph, but you can also click here.
Tuesday, October 11, 2011
An Exercise in Frustration and Futility
We cannot always win. That is a perfectly true statement. Oh sure, we may have winning streaks here and there, but we will inevitably meet with opposition which defeats us. Sometimes, it can seem almost as if we cannot even manage to win at all. That is how I felt with regards to my personal competition robot for the robocode system.
To be completely honest, I am frustrated, disappointed, and depressed by the fact that my robot is horrible. My robot, which I called "Tankadin" as a nod to my appreciation of paladins, could not consistently beat a single test robot that shot back at it. That is correct, I could beat most of the sample robots in robocode some of the time, but never one of the others all of the time. That is, aside from the "SittingDuck" robot, as well as "Target" or any other robots that never shot at me.
Where did I go wrong? Most likely it was due to the fact that I wanted to implement a movement strategy that utilized one of my favorite methods from my robocode kata robots, the method that allowed my robot to move to any specific location on the map. Unfortunately, the best use that I could think of for this ability was to send my robot to various corners of the map. But I wanted to be able to use that movement over and over during an engagement, so I developed a method that allowed me to randomly move to any of the 4 corners of the battlefield. As I left it, the robot moves to random corners when it hits a wall or another robot. I had implemented dodging capabilities and on-bullet-hit behaviors that were subsequently removed due to ineffectiveness or conflicts with targeting mechanics.
I soon realized that whilst my robot was in transit, it was not firing and often got pummeled to death en-route to its destination. I had also wanted to utilize my tracking ability to follow enemy robots with the gun so that most shots would land. What I managed to end up with was a less-than mediocre robot. Although, my robot does track and fire consistently when at rest.
I also wanted to implement some decent test cases, but I spent so much time changing behaviors, adding new movement strategies, removing them, and eventually settling for a disappointment that I didn't have time to implement them.
There were a few changes along the way that would beat one robot, but then lose consistently with all the others. Thus, I found myself trying new strategies only to have to remove the code for those strategies because they impeded on previously successful behaviors.
I have learned a great deal in the process of building "Tankadin". I realized that either movement or firing should be simple. Trying to implement tracking and fancy movement can often have bad side-effects such as interfering with the ability to dodge incoming shots, or to be able to consistently track your opponent. Also, as far as testing is concerned it would be best to settle on a particular strategy such that you can develop test cases right away to help determine effectiveness rather than trying to "fix" behavioral flaws in the robot as you see new situations arise with different opponents. Also, being able to devote more time towards development would greatly aid in the evolution process. I believe that would have allowed me to generate a decent level of performance in my robot.
To be completely honest, I am frustrated, disappointed, and depressed by the fact that my robot is horrible. My robot, which I called "Tankadin" as a nod to my appreciation of paladins, could not consistently beat a single test robot that shot back at it. That is correct, I could beat most of the sample robots in robocode some of the time, but never one of the others all of the time. That is, aside from the "SittingDuck" robot, as well as "Target" or any other robots that never shot at me.
Where did I go wrong? Most likely it was due to the fact that I wanted to implement a movement strategy that utilized one of my favorite methods from my robocode kata robots, the method that allowed my robot to move to any specific location on the map. Unfortunately, the best use that I could think of for this ability was to send my robot to various corners of the map. But I wanted to be able to use that movement over and over during an engagement, so I developed a method that allowed me to randomly move to any of the 4 corners of the battlefield. As I left it, the robot moves to random corners when it hits a wall or another robot. I had implemented dodging capabilities and on-bullet-hit behaviors that were subsequently removed due to ineffectiveness or conflicts with targeting mechanics.
I soon realized that whilst my robot was in transit, it was not firing and often got pummeled to death en-route to its destination. I had also wanted to utilize my tracking ability to follow enemy robots with the gun so that most shots would land. What I managed to end up with was a less-than mediocre robot. Although, my robot does track and fire consistently when at rest.
I also wanted to implement some decent test cases, but I spent so much time changing behaviors, adding new movement strategies, removing them, and eventually settling for a disappointment that I didn't have time to implement them.
There were a few changes along the way that would beat one robot, but then lose consistently with all the others. Thus, I found myself trying new strategies only to have to remove the code for those strategies because they impeded on previously successful behaviors.
I have learned a great deal in the process of building "Tankadin". I realized that either movement or firing should be simple. Trying to implement tracking and fancy movement can often have bad side-effects such as interfering with the ability to dodge incoming shots, or to be able to consistently track your opponent. Also, as far as testing is concerned it would be best to settle on a particular strategy such that you can develop test cases right away to help determine effectiveness rather than trying to "fix" behavioral flaws in the robot as you see new situations arise with different opponents. Also, being able to devote more time towards development would greatly aid in the evolution process. I believe that would have allowed me to generate a decent level of performance in my robot.
Thursday, September 29, 2011
My Experience with Ant Build Systems
I have recently been learning about the XML-based build system known as Ant and how it can improve your Java projects. Ant is a build system that is primarily designed for Java, which allows you access to a wide range of project management capabilities. Similar to the Unix Make command, you can set dependencies for targets and Ant will only compile or process certain required tasks that need to be done, rather than doing everything again each time you call it. You can automate a great deal of XML scripting in order to better manage your project files or even generate javadoc files.
Thus far, I have completed a number of Kata exercises for Ant, which have helped me learn a lot more about Ant's usefulness. Listed below are 8 very basic katas that each covers a different aspect of Ant build systems:
Thus far, I have completed a number of Kata exercises for Ant, which have helped me learn a lot more about Ant's usefulness. Listed below are 8 very basic katas that each covers a different aspect of Ant build systems:
1. Ant Hello World
This Kata covers basic structure of an Ant basic XML file. It simply echos "Hello World".
2. Ant Immutable Properties
This Kata covers basic Ant properties and how they cannot be changed after they have been set.
3. Ant Dependencies
This one dealt with dependencies and how they work.
4. Hello Ant Compilation
This one compiled a java file "HelloAnt.java" and placed the class file into another directory.
5. Hello Ant Execution
This is the Kata with which I had an issue. It is supposed to simply run the compiled "HelloAnt" program, but for some reason I couldn't understand how to set up the classpath properly and was met with several errors. The execution target depends on the file being already compiled, which I didn't have any problems with.
6. Hello Ant Documentation
This generates all of the javadoc files for the project.
7. Cleaning Hello Ant
This exercise simply deletes all of the build directories that the previous Ant scripts generate.8. Packaging Hello Ant
This exercise creates a zip file for the current directory and all of its sub-directories. It depends on the compilation, execution, documentation, and then cleans the build directory before creating the zip file. As I was unable to get my execution script to work properly, I left that dependency out of the equation for now. I intend to go back and add that once I determine why my execution script did not work.Overall, it was a rewarding experience to delve into XML and learn how to work with targets, dependencies, paths, and even how to manipulate file structures and directories. Once I figure out how to fix my error with the execution script, I will be able to fully set up a build system for future projects from scratch. All that is left now is to go over information regarding testing and automated quality assurance. After I cover those basics, working with large projects should be much easier to deal with.
Tuesday, September 20, 2011
Meanwhile, Down at the Robocode Factory...
You may be asking what a "Robocode factory" is, or for that matter just "Robocode". Well, Robocode is an open source project that was started a while ago by some folks at IBM. It has since been kept alive by "John Q. Public" (people like you and me). You can check out their homepage here: http://robocode.sourceforge.net/
When someone trains their skills for tournaments or fighting, they often have to practice certain moves over and over. Back in the day, martial artists in many different styles learned to comprise basic moves into "sets" or "katas" that they could practice over and over in order to develop muscle memory and the physical development needed to be able to repeat one or more such moves at a later time. This would enable them to use moves from their kata instinctively and with ease.
In a similar manner, I have been training my skills in developing robots for Robocode by building 13 basic robots, each of which is like a kata that contains particular "moves" that relate to Robocode robot functionality. This training has been an exercise in basic programming, math, and robot behavior. The robots themselves are quite simple in their nature as they only have 3 basic aspects: moving, scanning, and shooting. Here are the 13 basic katas that I completed for my Robocode training:
Interestingly, I had the most trouble with getting the robot to move in a circle of a particular radius as you can see in Position06. I had created this really elaborate calculation that turned the circle into a polygon with adjustable "resolution", or number of sides, and moved accordingly. It had some very complex calculations, and was a labor of love. Alas, I eventually threw it away when I later realized how all the inner angles added up to 360 degrees and you can just divide up the circumference by the number of angles you want the 360 degrees divided into. Then I simply went through a for loop moving forward and turning a little at a time. All the external angles are actually the same as the inner angles, and I was able to make a method that takes a radius and a "resolution" as parameters. This way, I can later reduce the number of turns for faster maneuvers, or increase them for a smoother circle. When being shot at, speed is a key factor in avoidance, and so I would probably opt for an ugly "circle" if it meant that I could avoid bullets!
Tracking was rather fun, but far easier once I delved through the Robocode API for a while. The API takes care of getting all the information regarding angles and distance that you need. There's even a really nifty utility method that normalizes angles to between 0 and either 180 or -180 degrees, which is very useful to avoid "overturning" when trying to get the main gun to bear down on your target. I had done some angle normalization on my own for the "goTo" method, but when I found the utility method in the API, I decided to use that for my Boom04 robot as it is more elegant code.
Altogether, I learned a lot about how the robots behave based on some trial and error I did in organizing my methods. I've also gained a few inspirations that I would like to try out on a competitive robot that I want to make next. If you are a casual coder, someone with an interest in games, or perhaps even just bored, I sincerely recommend that you check out Robocode! I had a lot of fun and spent far too much time playing around with the code. I am quite positive that you too would really enjoy it if you put in the effort to learn the basics. They even have a number of Java and Robocode tutorials that you can look at to get started. I also seriously recommend going through each of the aforementioned katas as they will help you get an understanding of how to get the robots to do what you want, as well as how to interact with other robots.
When someone trains their skills for tournaments or fighting, they often have to practice certain moves over and over. Back in the day, martial artists in many different styles learned to comprise basic moves into "sets" or "katas" that they could practice over and over in order to develop muscle memory and the physical development needed to be able to repeat one or more such moves at a later time. This would enable them to use moves from their kata instinctively and with ease.
In a similar manner, I have been training my skills in developing robots for Robocode by building 13 basic robots, each of which is like a kata that contains particular "moves" that relate to Robocode robot functionality. This training has been an exercise in basic programming, math, and robot behavior. The robots themselves are quite simple in their nature as they only have 3 basic aspects: moving, scanning, and shooting. Here are the 13 basic katas that I completed for my Robocode training:
- Position01: The minimal robot. Does absolutely nothing at all.
- Position02: Move forward a total of 100 pixels per turn. When you hit a wall, reverse direction.
- Position03: Each turn, move forward a total of N pixels per turn, then turn right. N is initialized to 15, and increases by 15 per turn.
- Position04: Move to the center of the playing field, spin around in a circle, and stop.
- Position05: Move to the upper right corner. Then move to the lower left corner. Then move to the upper left corner. Then move to the lower right corner.
- Position06: Move to the center, then move in a circle with a radius of approximately 100 pixels, ending up where you started.
- Follow01: Pick one enemy and follow them.
- Follow02: Pick one enemy and follow them, but stop if your robot gets within 50 pixels of them.
- Follow03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
- Boom01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
- Boom02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
- Boom03: Sit still. Rotate gun. When it is pointing at an enemy, use bullet power proportional to the distance of the enemy from you. The farther away the enemy, the less power your bullet should use (since far targets increase the odds that the bullet will miss).
- Boom04: Sit still. Pick one enemy and attempt to track it with your gun. In other words, try to have your gun always pointing at that enemy. Don't fire (you don't want to kill it).
Interestingly, I had the most trouble with getting the robot to move in a circle of a particular radius as you can see in Position06. I had created this really elaborate calculation that turned the circle into a polygon with adjustable "resolution", or number of sides, and moved accordingly. It had some very complex calculations, and was a labor of love. Alas, I eventually threw it away when I later realized how all the inner angles added up to 360 degrees and you can just divide up the circumference by the number of angles you want the 360 degrees divided into. Then I simply went through a for loop moving forward and turning a little at a time. All the external angles are actually the same as the inner angles, and I was able to make a method that takes a radius and a "resolution" as parameters. This way, I can later reduce the number of turns for faster maneuvers, or increase them for a smoother circle. When being shot at, speed is a key factor in avoidance, and so I would probably opt for an ugly "circle" if it meant that I could avoid bullets!
Tracking was rather fun, but far easier once I delved through the Robocode API for a while. The API takes care of getting all the information regarding angles and distance that you need. There's even a really nifty utility method that normalizes angles to between 0 and either 180 or -180 degrees, which is very useful to avoid "overturning" when trying to get the main gun to bear down on your target. I had done some angle normalization on my own for the "goTo" method, but when I found the utility method in the API, I decided to use that for my Boom04 robot as it is more elegant code.
Altogether, I learned a lot about how the robots behave based on some trial and error I did in organizing my methods. I've also gained a few inspirations that I would like to try out on a competitive robot that I want to make next. If you are a casual coder, someone with an interest in games, or perhaps even just bored, I sincerely recommend that you check out Robocode! I had a lot of fun and spent far too much time playing around with the code. I am quite positive that you too would really enjoy it if you put in the effort to learn the basics. They even have a number of Java and Robocode tutorials that you can look at to get started. I also seriously recommend going through each of the aforementioned katas as they will help you get an understanding of how to get the robots to do what you want, as well as how to interact with other robots.
Tuesday, August 30, 2011
What The FizzBuzz?
So, I know that there are numerous blogs discussing the "FizzBuzz test" that is given to interviewees as a "weed-out" measure to eliminate bad programmers. As an exercise in simplicity and timing, I have done a timed trial of implementing the program using Java as the programming language. The environment used was Eclipse 3.7, which drastically reduces the time needed to complete the exercise as typing is much faster than writing code by hand.
Here is a sample of my code for the simple version:
This took me a total of 3 minutes and 50 seconds after opening Eclipse, but only 2 minutes and 48 seconds from the moment I started typing in the editor to the moment that I saved, compiled, and ran the program. Now, to be honest this was my third time writing this particular program. I have previously written it by hand, which took me over 4 minutes to write after first seeing the problem. I was happy to say that my very first attempt at this problem was actually correct, albeit the algorithm was not quite so simple and had the redundancy of checking modulo 15 twice. It was the first time I was actually timed when writing code and the experience was flustering to say the least.
After being exposed to a potential solution after my initial test, I decided to implement it at home so that I could play around with the JUnit testing aspect. This exercise was not timed. Below is the code I used for that brief exercise:
Also, here is the code for the test-file:
I chose not to fully document everything as it was a personal exercise out of curiosity. I simply wanted to get my hands dirty experimenting with some JUnit tests.
So, why did I start out with a "time-trial" of such a simple program, when I have already become familiar with it? Part of the reason is that I want to gain practice producing code "under pressure". Another reason is to see how well my time had improved after becoming familiar with the problem, as well as the Eclipse Integrated Development Environment. The fact that it was being timed also resulted in the simplistic code, not having any comments, and the absence of a method implementation approach for ease of testing. Overall, this was a very simple exercise and I did not run into any obstacles with Java or Eclipse. It was encouraging to see that my time had improved a little, which is to be expected after repetition.
Furthermore, I am well aware of the fact that all interviews are different and that practicing potential and otherwise trivial problems proves nothing of my capabilities as a software engineer. I simply think that it is a good idea to practice in different areas. As such, writing code against a clock is a good way to begin to think in terms of potential "crunch-time" scenarios were a solution needs to be generated as quickly as possible to solve a serious problem. It is always ideal when given a problem to generate an elegant, well thought out, and creative solution. Wisdom would dictate that not all scenarios are ideal and so it is a good idea to be prepared for situations which are not ideal.
Here is a sample of my code for the simple version:
This took me a total of 3 minutes and 50 seconds after opening Eclipse, but only 2 minutes and 48 seconds from the moment I started typing in the editor to the moment that I saved, compiled, and ran the program. Now, to be honest this was my third time writing this particular program. I have previously written it by hand, which took me over 4 minutes to write after first seeing the problem. I was happy to say that my very first attempt at this problem was actually correct, albeit the algorithm was not quite so simple and had the redundancy of checking modulo 15 twice. It was the first time I was actually timed when writing code and the experience was flustering to say the least.
After being exposed to a potential solution after my initial test, I decided to implement it at home so that I could play around with the JUnit testing aspect. This exercise was not timed. Below is the code I used for that brief exercise:
Also, here is the code for the test-file:
I chose not to fully document everything as it was a personal exercise out of curiosity. I simply wanted to get my hands dirty experimenting with some JUnit tests.
So, why did I start out with a "time-trial" of such a simple program, when I have already become familiar with it? Part of the reason is that I want to gain practice producing code "under pressure". Another reason is to see how well my time had improved after becoming familiar with the problem, as well as the Eclipse Integrated Development Environment. The fact that it was being timed also resulted in the simplistic code, not having any comments, and the absence of a method implementation approach for ease of testing. Overall, this was a very simple exercise and I did not run into any obstacles with Java or Eclipse. It was encouraging to see that my time had improved a little, which is to be expected after repetition.
Furthermore, I am well aware of the fact that all interviews are different and that practicing potential and otherwise trivial problems proves nothing of my capabilities as a software engineer. I simply think that it is a good idea to practice in different areas. As such, writing code against a clock is a good way to begin to think in terms of potential "crunch-time" scenarios were a solution needs to be generated as quickly as possible to solve a serious problem. It is always ideal when given a problem to generate an elegant, well thought out, and creative solution. Wisdom would dictate that not all scenarios are ideal and so it is a good idea to be prepared for situations which are not ideal.
Monday, August 29, 2011
The Prime Directives Applied to BZFlag
BZFlag is an open source game that is designed for entertainment purposes, which utilizes several programming languages to create a three-dimensional tank simulation game. The source code is written primarily in C++, but it also incorporates modules that are written in PHP, Perl, and Python. The homepage for the project can be found at: http://bzflag.org/ Alternatively, you can access the project via sourceforge.net at: http://sourceforge.net/projects/bzflag/
The name BZFlag is derived from "Battle Zone capture the Flag", although the game engine now supports other scenarios via server settings such as Free For All and Rabbit Hunt. According to their homepage, BZFlag boasts that it is "...one of the most popular open source games ever." Whether or not this is truly the case, the game works on several different platforms including Mac OS, Windows, Linux, and many other platforms. Intended as a cross-platform multiplayer game, being available on so many different platforms is a tremendous feat. This is especially true, considering all of the differences in various operating systems.
Since this is an open source project, what standards can we apply to measure its success and usefulness? The Three Prime Directives of Open Source Software provide us with useful means of comparative analysis. So then, how does BZFlag meet each of the Prime Directives?
1. The system successfully accomplishes a useful task.
Okay, some may argue that games by their very nature do not accomplish ANY useful tasks. In relation to productivity, no they do not succeed in this endeavor. However, in the context of creative expression, entertainment, and leisure, games do indeed serve a purpose. As such, BZFlag accomplishes these tasks quite well. It offers variable gameplay modes with the option of single player or multiplayer environments. I was able customize server settings, create my own server, and join existing games on servers created by other people. It is by no means competitive compared to top-tier mainstream video games, but it is quite impressive for a game that is available cross-platform and with no cost. I certainly appreciated the customization available for server settings, and I tried out a variety of scenarios.
2. An external user can successfully install and use the system.
BZFlag is exceptionally easy to install on Mac OS. All I have to do is download the zip file from their website, or via sourceforge.net. Once I open the zip file, I simply move the application file into my application folder and I am finished. Of course, the game will work from any directory on Mac OS; having the program file in the applications folder just makes it easy to find. Once it is installed, I simply double click the application icon and the game starts up. The menus are easy to navigate, and within moments I can have a server up and start blasting away at other tanks. The controls are relatively basic and intuitive, and the user interface is simple yet informative.
3. An external developer can successfully understand and enhance the system.
While it does take a bit of navigation through the project structure, the project is relatively well organized. There are files for the game client, for the server, and for server administrator tools. The C++ code is not consistently commented, although with enough exploration and examination it makes sense. I have to admit that I did not have any prior experience with program structure for a game with a Graphical User Interface. As such, some of the code is currently beyond my expertise or understanding. This project is definitely not for the feint of heart, or those with no prior C++ experience. I have a little understanding of the code, which is enough to modify the game here and there. In fact one of the things I would like to attempt is to modify the movement controls to allow for strafing and eventually a toggle for y-axis movement.
All in all, if you are familiar with 3D game client structure and such, it would be relatively easy to understand and enhance BZFlag. There is a wiki-page with information about the project, forums for use and development, and plenty of developer-level documentation available online. Also included in the source code directories are plenty of the documentation files which are available on the website.
Here are some screen shots from the program:
The name BZFlag is derived from "Battle Zone capture the Flag", although the game engine now supports other scenarios via server settings such as Free For All and Rabbit Hunt. According to their homepage, BZFlag boasts that it is "...one of the most popular open source games ever." Whether or not this is truly the case, the game works on several different platforms including Mac OS, Windows, Linux, and many other platforms. Intended as a cross-platform multiplayer game, being available on so many different platforms is a tremendous feat. This is especially true, considering all of the differences in various operating systems.
Since this is an open source project, what standards can we apply to measure its success and usefulness? The Three Prime Directives of Open Source Software provide us with useful means of comparative analysis. So then, how does BZFlag meet each of the Prime Directives?
1. The system successfully accomplishes a useful task.
Okay, some may argue that games by their very nature do not accomplish ANY useful tasks. In relation to productivity, no they do not succeed in this endeavor. However, in the context of creative expression, entertainment, and leisure, games do indeed serve a purpose. As such, BZFlag accomplishes these tasks quite well. It offers variable gameplay modes with the option of single player or multiplayer environments. I was able customize server settings, create my own server, and join existing games on servers created by other people. It is by no means competitive compared to top-tier mainstream video games, but it is quite impressive for a game that is available cross-platform and with no cost. I certainly appreciated the customization available for server settings, and I tried out a variety of scenarios.
2. An external user can successfully install and use the system.
BZFlag is exceptionally easy to install on Mac OS. All I have to do is download the zip file from their website, or via sourceforge.net. Once I open the zip file, I simply move the application file into my application folder and I am finished. Of course, the game will work from any directory on Mac OS; having the program file in the applications folder just makes it easy to find. Once it is installed, I simply double click the application icon and the game starts up. The menus are easy to navigate, and within moments I can have a server up and start blasting away at other tanks. The controls are relatively basic and intuitive, and the user interface is simple yet informative.
3. An external developer can successfully understand and enhance the system.
While it does take a bit of navigation through the project structure, the project is relatively well organized. There are files for the game client, for the server, and for server administrator tools. The C++ code is not consistently commented, although with enough exploration and examination it makes sense. I have to admit that I did not have any prior experience with program structure for a game with a Graphical User Interface. As such, some of the code is currently beyond my expertise or understanding. This project is definitely not for the feint of heart, or those with no prior C++ experience. I have a little understanding of the code, which is enough to modify the game here and there. In fact one of the things I would like to attempt is to modify the movement controls to allow for strafing and eventually a toggle for y-axis movement.
All in all, if you are familiar with 3D game client structure and such, it would be relatively easy to understand and enhance BZFlag. There is a wiki-page with information about the project, forums for use and development, and plenty of developer-level documentation available online. Also included in the source code directories are plenty of the documentation files which are available on the website.
Here are some screen shots from the program:
 |
| Start Menu |
 |
| Just Cruisin |
 |
| Firing a Shot |
Subscribe to:
Posts (Atom)