Group projects sound pretty simple in it's own context. Throw software engineering in and it becomes an entirely different animal. Unlike regular group projects where everyone does their own thing, software engineering uses a management concept known as "issue-based project management." This concept utilizes issues concerning the project which each member accepts to work on. Each group member works on nothing else but the issues they've accepted. The reasoning behind this is to reduce conflicts when integrating your work with another member's work effort. This sounds efficient in concept, but is it effective in practice?
I spent a few weeks practicing this management concept and I have things say about it. It seems cumbersome to work with considering that I have to created detailed issues to work on and then accept the same issues to work on.. Issues will definitely come up during testing which needs to be detailed and added to the list of issues needed to be looked at. Considering that there were only three of us working on this project, I can imagine that it causes less anxiety because there might not be any issues to work on when the project isn't finished. It would be less of an issue then.
By separating the work, I felt not so pressured when I could check up on what progress the others have made. Despite the fact that we created these issues, we haven't exactly discussed a standard way of solving these issues. It was fortunate that our project was designed to be modular, with only one point of entry for each module. We used an interface to standardize this point of entry then went ahead and did our own thing. Unfortunately, after the entry point, this non-standardized approach for our modules would make it harder for new developers if they were to look at our code since for each module, the modules we worked on were made with our own little quirks. One of the other group members had a completely different way of parsing a date compared to mines. When I created a date parser, it grew into a huge monstrosity that needed it's own class. I can't say that it was the same for theirs since it was contained within a single class.
I find issue-based project management to not be an effective management style to use when there are only three members working on a project. The amount of effort needed to find issues and consider whether or not it is worthy of it's own issue isn't worth it. Not to mention that Google Project hosting doesn't exactly make updating issue statuses convenient. Perhaps if we had someone who doesn't necessarily have to know how to program, but should at least know how to find issues for us to fix, this management style would have worked out better with less headaches.
Still, we were lucky enough to be not be grouped with any slackers and finished this project ahead of schedule, with the last few days spent just tweaking our modules and doing tests. We didn't miss any of the planned features. Our project is hosted here if you want to have a look.
Friday, December 2, 2011
Tuesday, November 1, 2011
Green Hawai'i
Living on a rock in the middle of the ocean, 5000 miles away from the nearest civilization, comes with expensive perks like clean air, beaches within walking distance, and nice weather most of the time. I say expensive because everything is imported into Hawai'i, including fuel. Our top import in Hawai'i is oil, which accounts for 77% of the state energy use. This is a big contrast to the mainland, where they get only 1% of their energy from oil. Not to mention the fact that they have a lot more alternatives and space.
The only choice that we have in Hawai'i is to use less energy. Even if we were to attempt to replace energy production with renewable resources, it wouldn't stop the fact that there would be an increase in energy use over time just from population growth. That's assuming if we continued to use the same amount of energy now.
On the mainland, energy companies can buy and sell power as needed. This only works because they are all connected to form a giant electricity grid. It's different in Hawai'i because each island have their own grids, but they aren't connected. Electricity is 0.30 per kWh on Oahu. It's much worse on other islands. It doesn't help that each island is separated by a big stretch of water so it's probably impossible for Hawai'i to consolidate energy production or even share electricity. The power plants themselves aren't efficient at all because they're just so tiny.
One of my pet peeves of trying to use energy is trying to read the meter. Unfortunately, my house was built during a time when it was a good idea to keep information away from the general populace. The only way to find out how much energy I use is at the end of every month, which I'm very impatient about. It would help me a lot to see how much energy I use exactly per day so that I could adjust my behavior accordingly, or at least where my energy is going to.
Living in paradise comes with a lot of strings attached. Paying more for electricity shouldn't be one of those strings. Hawai'i needs to be more aggressive with researching alternative energy production, than building a monorail or making laws against the homeless. Just the savings alone would free up so much money for other projects, like making the homeless not homeless anymore or better schools so there are more people looking for alternative energy.
The only choice that we have in Hawai'i is to use less energy. Even if we were to attempt to replace energy production with renewable resources, it wouldn't stop the fact that there would be an increase in energy use over time just from population growth. That's assuming if we continued to use the same amount of energy now.
On the mainland, energy companies can buy and sell power as needed. This only works because they are all connected to form a giant electricity grid. It's different in Hawai'i because each island have their own grids, but they aren't connected. Electricity is 0.30 per kWh on Oahu. It's much worse on other islands. It doesn't help that each island is separated by a big stretch of water so it's probably impossible for Hawai'i to consolidate energy production or even share electricity. The power plants themselves aren't efficient at all because they're just so tiny.
One of my pet peeves of trying to use energy is trying to read the meter. Unfortunately, my house was built during a time when it was a good idea to keep information away from the general populace. The only way to find out how much energy I use is at the end of every month, which I'm very impatient about. It would help me a lot to see how much energy I use exactly per day so that I could adjust my behavior accordingly, or at least where my energy is going to.
Living in paradise comes with a lot of strings attached. Paying more for electricity shouldn't be one of those strings. Hawai'i needs to be more aggressive with researching alternative energy production, than building a monorail or making laws against the homeless. Just the savings alone would free up so much money for other projects, like making the homeless not homeless anymore or better schools so there are more people looking for alternative energy.
Tuesday, October 25, 2011
Some Programmer Things to Know
1. What are some effective ways to ask a question and why are they so?
One way is by giving a full detail of what happened and what you did leading up to the problem that you are getting. By immediately giving all the details, the person helping will know exactly why it is happening and give you solutions.
Another way is by doing the research first. Doing your own research may turn up answers to your problem faster than asking someone else. Even if you did research, it would help to share this information with the person helping you in case you did not find anything. They would be able to get a grasp of what kind of problem you are having and offer solutions.
2. How would you implement a task in Ant to create a JAR file?
3. How are PMD and FindBugs different even though they both fundamentally find bugs?
PMD analyzes the source code itself without running the program, as in it will read what you can see on the screen in an IDE. FindBugs reads the bytecode of the program. To read the bytecode, the program has to be compiled.
4. Why is JUnit very useful?
JUnit can test individual classes and determine that the input they get gives out the expected output. The best part about this is that it can be scaled to include a very large amount of tests cases for individual classes. The amount of classes and test cases JUnit can test is not limited either.
5. What are some of the terminology of configuration management?
Mainline, branch, checkout, edit, sync, lock, label, merge, checkin, resolve, head.
One way is by giving a full detail of what happened and what you did leading up to the problem that you are getting. By immediately giving all the details, the person helping will know exactly why it is happening and give you solutions.
Another way is by doing the research first. Doing your own research may turn up answers to your problem faster than asking someone else. Even if you did research, it would help to share this information with the person helping you in case you did not find anything. They would be able to get a grasp of what kind of problem you are having and offer solutions.
2. How would you implement a task in Ant to create a JAR file?
3. How are PMD and FindBugs different even though they both fundamentally find bugs?
PMD analyzes the source code itself without running the program, as in it will read what you can see on the screen in an IDE. FindBugs reads the bytecode of the program. To read the bytecode, the program has to be compiled.
4. Why is JUnit very useful?
JUnit can test individual classes and determine that the input they get gives out the expected output. The best part about this is that it can be scaled to include a very large amount of tests cases for individual classes. The amount of classes and test cases JUnit can test is not limited either.
5. What are some of the terminology of configuration management?
Mainline, branch, checkout, edit, sync, lock, label, merge, checkin, resolve, head.
Thursday, October 20, 2011
Cloud Backups
A few days ago, someone was robbed and they had their computers stolen. What the computers contained was months long source code for an important project. That computer also happened to have the only copy of the source code. Suffice to say, there were many unhappy customers because they paid for an incomplete product and are most likely feeling buyers' remorse.
Backing up source code is no laughing matter, because a catastrophes may be uncommon, but when they do happen, you had better be prepared for the worst. It is especially shameful when creating backups is extremely easy and painless. Google Project Hosting provide free online storage for code backups so you have no excuse to not have a backup of everything important you have online.
Having a backup is also not just useful for cataclysmic events, but they also help speed up development. Backups are extremely important in the configuration management systems. They are a set of ideas of how software developers would develop their programs. Using configuration management, software developers will have a version to fall back on, so can code all they want and if they run into something problematic that requires everything to be reverted, they have something to fall back on to. They can also created their own versions without tampering with the original code. It's a very handy thing to have in a group project, especially when these groups can grow to huge sizes and it becomes a logistical nightmare having to keep everyone up to date.
Initially, I found configuration management systems to be somewhat time consuming as I only considered myself as the sole developer. By thinking about how it would benefit groups, it sounded much more appealing. When I first started using Google Project Hosting, I found it confusing as everything was not immediately apparent to me. There were not any descriptions of which link went to where. It took me a while to find out how to upload my Robocode. After I got done uploading, something seemed to click and I grasped everything Google Project Hosting offered easily. I was able to add another committer to my project, create labels, add wiki pages, and edit my front page so the wiki page shows on the front page.
I have learned how important it is to have a backup not just for in case something happens, but for software development. I also learned how to use Google Project Hosting as a repository for all of my source code. It was not hard to learn to use it because what I mostly did was click on every link and read everything that it told me to do.
My Google Project can be found at http://code.google.com/p/roocode-wca-chinpogum/
Backing up source code is no laughing matter, because a catastrophes may be uncommon, but when they do happen, you had better be prepared for the worst. It is especially shameful when creating backups is extremely easy and painless. Google Project Hosting provide free online storage for code backups so you have no excuse to not have a backup of everything important you have online.
Having a backup is also not just useful for cataclysmic events, but they also help speed up development. Backups are extremely important in the configuration management systems. They are a set of ideas of how software developers would develop their programs. Using configuration management, software developers will have a version to fall back on, so can code all they want and if they run into something problematic that requires everything to be reverted, they have something to fall back on to. They can also created their own versions without tampering with the original code. It's a very handy thing to have in a group project, especially when these groups can grow to huge sizes and it becomes a logistical nightmare having to keep everyone up to date.
Initially, I found configuration management systems to be somewhat time consuming as I only considered myself as the sole developer. By thinking about how it would benefit groups, it sounded much more appealing. When I first started using Google Project Hosting, I found it confusing as everything was not immediately apparent to me. There were not any descriptions of which link went to where. It took me a while to find out how to upload my Robocode. After I got done uploading, something seemed to click and I grasped everything Google Project Hosting offered easily. I was able to add another committer to my project, create labels, add wiki pages, and edit my front page so the wiki page shows on the front page.
I have learned how important it is to have a backup not just for in case something happens, but for software development. I also learned how to use Google Project Hosting as a repository for all of my source code. It was not hard to learn to use it because what I mostly did was click on every link and read everything that it told me to do.
My Google Project can be found at http://code.google.com/p/roocode-wca-chinpogum/
Professional Robocode Player
Serious development for serious Robocode competitions will require serious testing. While the competition is a whiles away, I will still need to individually test each behavior of my robot. To do this, I will have to perform something called "behavioral testing." Behavioral testing is the practice of testing individual features in a controlled environment using JUnit which is provided by Eclipse.
The art of behavioral testing itself isn't something that is picked up easily. The idea of choosing scenarios can have many different factors, most of which you will never think of because you do not have all the time in the world to think of them. Behavioral testing is still an important function within software development because it helps expose logic errors that would otherwise be missed. Logic errors being that they are technically correct, but the code does not perform the way you want. It is also a cheap and fast way to expose logic errors.
I designed my robot to be as reactive as possible instead of merely pointing and shooting. I chose to make my robot ram its targets as I want to gain as much points as possible. At the moment, when my robot finds a target, it will stay on that target and nothing else, hence it has tunnel vision. It does not have very good situational awareness. Lastly, I try to reserve the shooting as much as possible. When my robot scans a target, it does not immediately fire at it. Rather, it will ram the target and them fire. It will also return fire in the direction the bullet came from, which is problematic because it stops my robot from moving and resets the scanner. It will also fire at the target if it stays still too long.
So far, my robot has performed poorly against all the robots. Especially against wall robots. I am not proud of my robot. Here are the percentages of how often my robot wins against the samples:
Sitting Duck: 100%
Walls: 10%
Crazy: 40%
Spin: 30%
Corners: 50%
I learned a very important lesson doing this. Despite the fact that I could visually inspect how well my robot is doing, I could find out so much more faster when I can run multiple tests alongside each other with minimal time involved. The behavioral tests are an invaluable tool for finding bugs.
The art of behavioral testing itself isn't something that is picked up easily. The idea of choosing scenarios can have many different factors, most of which you will never think of because you do not have all the time in the world to think of them. Behavioral testing is still an important function within software development because it helps expose logic errors that would otherwise be missed. Logic errors being that they are technically correct, but the code does not perform the way you want. It is also a cheap and fast way to expose logic errors.
I designed my robot to be as reactive as possible instead of merely pointing and shooting. I chose to make my robot ram its targets as I want to gain as much points as possible. At the moment, when my robot finds a target, it will stay on that target and nothing else, hence it has tunnel vision. It does not have very good situational awareness. Lastly, I try to reserve the shooting as much as possible. When my robot scans a target, it does not immediately fire at it. Rather, it will ram the target and them fire. It will also return fire in the direction the bullet came from, which is problematic because it stops my robot from moving and resets the scanner. It will also fire at the target if it stays still too long.
So far, my robot has performed poorly against all the robots. Especially against wall robots. I am not proud of my robot. Here are the percentages of how often my robot wins against the samples:
Sitting Duck: 100%
Walls: 10%
Crazy: 40%
Spin: 30%
Corners: 50%
I learned a very important lesson doing this. Despite the fact that I could visually inspect how well my robot is doing, I could find out so much more faster when I can run multiple tests alongside each other with minimal time involved. The behavioral tests are an invaluable tool for finding bugs.
Thursday, September 29, 2011
Ant
Using Ant, I saw how easy it was to deploy development source code on different systems. Being a build system, Ant serves this purpose very well. Since Ant is separate from any IDE, it makes open source projects at lot less painful to work with since distribution is standardized and removes human error. It even verifies the build for you and it is a script you could switch out. Build systems like Ant will also fill in the holes for you by downloading missing libraries.
Most of the commands available to me were simple and easy to master. It's versatility knows no bounds, because it has a command to create zip files by itself. It is also possible to create a new directory with the zip command by itself, where other commands would give me if I tried the same. Ant also allows me to create my own commands which I can use to do specific actions on my build, such as creating a lighter version of my build. The dependencies are very convenient and is more open than extend in Java since it allows multiple targets.
Although, I find the interchanging between "name" and "dir" disorienting whenever I create a target or directory. Despite the fact that Eclipse claimed it has Ant supported, it seemed like it was never fully thought out. It took me a while to enable Ant formatting before I decided to restart Eclipse for it to recognize it as an Ant file.
Tuesday, September 20, 2011
Robocode
Writing robocode was not as exciting as I had hoped it would be. Rather, I found that having a strong background in trigonometry would help immensely. At the very least, was pretty neat that I could design my own robot and have them fight each other.
For some of the uninitiated, robocode was a program originally created by IBM and was later dropped by them and became an open source project. Over the years it created a fan base that programmed robots and even held competitions for it.
I was not able to complete all the assignments which was to implement simple robot behaviors. They were named according to what their behavior was supposed to be. The only ones that still remained were boom02-04 and position05. Again it was my having a weak background in trigonometry that held me back. I spent many days on position04 alone refining the trigonometric calculation so it would give me the correct direction towards the center. Even then it still took detours despite that it was heading in the wrong direction. I felt I could use what I learned from position04 for position05. I was somewhat wrong as I had to account for my robot running into the wall. When I fixed that, I realized I should have gotten a clarification on whether it should be exactly in the corner or near there. At the moment, I have it ramming the wall and reversing to turn a few degrees just like Austin Powers. Boom02-04 all depended on each other and since I could not do boom02, I was not able to complete the rest. Even though there were less trigonometry, I still found it hard to tell my robot when to stop turning its gun.
I learned that robots were very obedient, if somewhat frustrating in that it was completely obedient. Everything about robocode had to be overly specific, with all contingencies covered. Without this exact specific behavioral programming, the robots tend to either die and mislead you or seem to have developed a mind of its own.
Having a set of code katas helped in refining the robot's behavior, but rather they helped in getting my feet wet. Generally, code katas are good practice. Knowing that I spent time practicing this kind of thing gives me confidence in myself, which is important when people start to ask questions. Unfortunately, even with this, I still do not have any ideas or plans on how to create a competitive robot yet. I am not a very creative person.
For some of the uninitiated, robocode was a program originally created by IBM and was later dropped by them and became an open source project. Over the years it created a fan base that programmed robots and even held competitions for it.
I was not able to complete all the assignments which was to implement simple robot behaviors. They were named according to what their behavior was supposed to be. The only ones that still remained were boom02-04 and position05. Again it was my having a weak background in trigonometry that held me back. I spent many days on position04 alone refining the trigonometric calculation so it would give me the correct direction towards the center. Even then it still took detours despite that it was heading in the wrong direction. I felt I could use what I learned from position04 for position05. I was somewhat wrong as I had to account for my robot running into the wall. When I fixed that, I realized I should have gotten a clarification on whether it should be exactly in the corner or near there. At the moment, I have it ramming the wall and reversing to turn a few degrees just like Austin Powers. Boom02-04 all depended on each other and since I could not do boom02, I was not able to complete the rest. Even though there were less trigonometry, I still found it hard to tell my robot when to stop turning its gun.
I learned that robots were very obedient, if somewhat frustrating in that it was completely obedient. Everything about robocode had to be overly specific, with all contingencies covered. Without this exact specific behavioral programming, the robots tend to either die and mislead you or seem to have developed a mind of its own.
Having a set of code katas helped in refining the robot's behavior, but rather they helped in getting my feet wet. Generally, code katas are good practice. Knowing that I spent time practicing this kind of thing gives me confidence in myself, which is important when people start to ask questions. Unfortunately, even with this, I still do not have any ideas or plans on how to create a competitive robot yet. I am not a very creative person.
Subscribe to:
Posts (Atom)