I experienced what it was like to take over a project that was already completed and add more to it. This project is the same software that I reviewed in my last post. For this project, we apply issue based project management.
In this project, we did not have much trouble with creating issues, rather the issues were minimal. We first focused on completing the new classes to be added to the software then decided on which issues were needed then. While we already perform testing side by side in development, we also created issues for further testing. In the end, we didn't spend too much time worrying about issues. Like before, I found the issues to cause me anxiety over whether or not something warrants an issue and if someone will take over it.
In this little enhancement, we added three classes, a class for monitoring if a tower meets their goal, it's helper class on setting a goal, and a power monitor. They all had their own challenges and I was assigned the helper class which is called "SetBaseline." I mixed my code with the already existing code for parsing input during the creation of my class to reduce development time. I've had to modify it to suit my needs. Using my own style helps greatly during testing since it differentiates itself from the other classes when it came time to integrating it with the main class. The challenge for this class was finding out how to store the baseline data throughout the software. I wasn't able to quite find out the solution to this problem myself and had to ask the other project members for assistance. Their solution was to create a static variable in the main class and import the main class into my class. From there, the baseline data can now be stored somewhere where it can be accessed anywhere. All it took was only two lines of code to enable this functionality. Quite frustrating.
The other two classes were monitor goal and monitor power and they had different approaches. Instead of being a one-time call, they were called and ran until the user decides to stop. To enable that, the Timer and TimerTask classes had to be implemented. I didn't have much to do with their development since we kept our work separate as project management requires to keep integration conflicts to a minimum.
Looking back on this, I've tangled with the Three Prime Directives on all levels, from the basic user to full-time developer. It helped me to see what condition the software was in and the quality of it and review its structure. Performing this enhancement has been an interesting experience for me. While I haven't tried out other management styles, I've been able to practice using issue-based management more. I've become more comfortable using Jenkins as a continuous integration tool, which came at a good time. Testing the software enhancements has become somewhat of a nightmare recently due to it constantly timing out when connected to the server, whereas on the Jenkins server, it tests fine.
This will be the last post I will make in a long time, possibly until I decide I want to blog again. It might be useful if I decide to start an extensive software project.
Wednesday, December 14, 2011
Thursday, December 8, 2011
Technical Review: A Continuation
Last time, I posted about continuous integration. This time, I will perform a technical review of another group's project. The project they are working on is a command line interface for a system known as Watt Depot. The Watt Depot system are servers located in the dorms of UH Manoa that monitor everyday use of electricity and is an ongoing project to reduce consumption of electricity. This group goes by the name of BackR, which means back row because they all sit there. The interface communicates with Watt Depot by getting information about power usage and displaying it for the user. More information about BackR's software can be found at this link.
This software was developed using two project management practices, including issue-based project management. The other practice used are continuous integration. To reiterate what issue-based project management is, this practice takes advantage of Google project's issue function to create issues on parts of the software to be worked on. Essentially, it is creating jobs to do. Continuous integration is the practice of reducing duplicate and conflicting work to a minimum. It uses a server software known as Jenkins which downloads the project from Google and uses Ant to verify that all there are no conflicts whenever a new build is uploaded.
I will be using the Three Prime Directives to review this project. These directives are:
Prime Directive #1: The system accomplishes a useful task.
Prime Directive #2: The system can successfully be installed and used by a new user.
Prime Directive #3: The system can successfully be understood and enhanced by a new developer.
Prime Directive # 1
The command line interface can accomplish a few tasks. At the moment, five commands are implemented: rank-towers, daily-energy, energy-since, current-power, and help. The rank-tower command ranks all the sources by how much power they consumed during a certain period of time. The towers are ranked from the least to the most consumed. daily-energy lists the power that source consumed on that day. energy-since tells you how much power was consumed from that day up to today. current-power tells you the current power consumption of that source. Finally the help command tells you all the available commands and how to use them.
I would say that it accomplishes a few useful tasks.
Prime Directive # 2
Downloading the program, it came with the source code and the jar file. The jar file was complete and didn't require any further action on my part to get it to work other than to execute it. It contains a version number.
This shows an example of this program in action.
It wasn't immediately known to me on how I would run such a program. Fortunately, there was a user guide available that I could read to find out. It lists the available commands but there wasn't an example of how they would be used. Installation seemed to be confusing as there was no link available to download Ant, a guide on how to install Ant, or whether it was necessary for a non-developer to use it. Executing the program itself was easy as there was an example of how to start it.
Below shows some invalid and valid inputs to test how the command line interface handles them:
current-power
daily-energy
energy-since
rank-towers
From this tests, it would be safe to say that it is easy for new users to install and use.
Prime Directive # 3
As a developer, I might want to add something to this myself if I find something lacking. It's an open source project after all and I should treat it as such. Looking at the developer guide, it tells me how I would begin development and which classes have been implemented. There is no way for me to find out what kind of standards the developers are using or if I'm going to meet them. The is a small note on what kind of management they use and that I should use it when I attempt something. There is no mention of whether or not it follows Continuous Integration.
Downloading the software from the SVN and generating Java documentation was a painless process. The information written were fairly short descriptions of each class. It supports information hiding by making all the global variables private and having accessor methods. I was able to build the system without any errors. Looking at the test source code, I can see that they have a large number of test cases for each class. Since each class has only one method for performing everything, it would be hard for a new developer to make modifications to these classes without breaking the test cases. The source code looked easy to understand since there were just enough comments that didn't make up more than the source code itself. Comparing the issues with the commits, it was clear who I could go to if I were to have any questions about the code. Although, it looked like one developer did the most work while the others did some. On their CI page, there was at least a daily development. Any issues they had were corrected promptly, usually on the same day.
A new developer would have a fairly difficult time modifying an existing class without breaking anything. Whereas creating a new module would be easy. It is easy to understand how the system works because the classes have been documented fairly well.
This software was developed using two project management practices, including issue-based project management. The other practice used are continuous integration. To reiterate what issue-based project management is, this practice takes advantage of Google project's issue function to create issues on parts of the software to be worked on. Essentially, it is creating jobs to do. Continuous integration is the practice of reducing duplicate and conflicting work to a minimum. It uses a server software known as Jenkins which downloads the project from Google and uses Ant to verify that all there are no conflicts whenever a new build is uploaded.
I will be using the Three Prime Directives to review this project. These directives are:
Prime Directive #1: The system accomplishes a useful task.
Prime Directive #2: The system can successfully be installed and used by a new user.
Prime Directive #3: The system can successfully be understood and enhanced by a new developer.
Prime Directive # 1
The command line interface can accomplish a few tasks. At the moment, five commands are implemented: rank-towers, daily-energy, energy-since, current-power, and help. The rank-tower command ranks all the sources by how much power they consumed during a certain period of time. The towers are ranked from the least to the most consumed. daily-energy lists the power that source consumed on that day. energy-since tells you how much power was consumed from that day up to today. current-power tells you the current power consumption of that source. Finally the help command tells you all the available commands and how to use them.
I would say that it accomplishes a few useful tasks.
Prime Directive # 2
Downloading the program, it came with the source code and the jar file. The jar file was complete and didn't require any further action on my part to get it to work other than to execute it. It contains a version number.
This shows an example of this program in action.
It wasn't immediately known to me on how I would run such a program. Fortunately, there was a user guide available that I could read to find out. It lists the available commands but there wasn't an example of how they would be used. Installation seemed to be confusing as there was no link available to download Ant, a guide on how to install Ant, or whether it was necessary for a non-developer to use it. Executing the program itself was easy as there was an example of how to start it.
Below shows some invalid and valid inputs to test how the command line interface handles them:
current-power
daily-energy
energy-since
rank-towers
From this tests, it would be safe to say that it is easy for new users to install and use.
Prime Directive # 3
As a developer, I might want to add something to this myself if I find something lacking. It's an open source project after all and I should treat it as such. Looking at the developer guide, it tells me how I would begin development and which classes have been implemented. There is no way for me to find out what kind of standards the developers are using or if I'm going to meet them. The is a small note on what kind of management they use and that I should use it when I attempt something. There is no mention of whether or not it follows Continuous Integration.
Downloading the software from the SVN and generating Java documentation was a painless process. The information written were fairly short descriptions of each class. It supports information hiding by making all the global variables private and having accessor methods. I was able to build the system without any errors. Looking at the test source code, I can see that they have a large number of test cases for each class. Since each class has only one method for performing everything, it would be hard for a new developer to make modifications to these classes without breaking the test cases. The source code looked easy to understand since there were just enough comments that didn't make up more than the source code itself. Comparing the issues with the commits, it was clear who I could go to if I were to have any questions about the code. Although, it looked like one developer did the most work while the others did some. On their CI page, there was at least a daily development. Any issues they had were corrected promptly, usually on the same day.
A new developer would have a fairly difficult time modifying an existing class without breaking anything. Whereas creating a new module would be easy. It is easy to understand how the system works because the classes have been documented fairly well.
Friday, December 2, 2011
Experimenting with Software Development Management
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.
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.
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.
Wednesday, August 31, 2011
FizzBuzz
Creating this program took me 5:36. I've noticed that I had a hard time imagining the output in my head. I spent too much time making sure my formatting and indents were correct. I actually finished writing the program at around 3:00, but it was wrong when I checked. Before I started writing again, I thought about how I should implement it by writing it on paper. It helps me to think. Before getting into the habit of stopping, I spent a lot of time thinking about how my method would work if I implemented it a certain way and not writing it down. I traced it in my head and I never got to do any actual coding or whenever I did, it was haphazardly.
Frankly, I have not learned anything new from this assignment or this class relating to software engineering. What I've learned so far is how to make myself look good instead of making good programs, which is pretty important, but it's not something that I believe I should spend class time on. Looking at the readings,specifically those related to fizzbuzz, I am lead to believe that being able to write a simple working program within a certain time limit gauges the quality of programmers. Doing this fizzbuzz exercise tells me that I am not cut out to be a software engineer how I am right now.
Sunday, August 28, 2011
GFP - Personal Finance Manager 0.8.1
The art of financial security is not taught to anyone while they are growing up. When they finally become independent, matters concerning their financial health are severely crippled by their lack of skill in managing their finances. There is an industry centered around this financial mismanagement that can be costly to the user. Fortunately, there are programs that can do the same work, but for free.
GFP is an open-source program written in Java with a GUI provided by Java's swing library. Since the program is using strictly it's own library and Java's, it is platform independent. The purpose of GFP is to provide help on managing finances to users with limited financial knowledge and ability. Using a limited number of input fields, much of the work is done by GFP in creating readable financial spreadsheets. Even though it was last modified in 2007, GFP still receives many hits and downloads.
GFP can be downloaded from: http://sourceforge.net/projects/gfd/
For a program to be classified as an open source software, the following prime directives must be fulfilled. More information on these prime directives can be found on this page.
Prime Directive 1: The system successfully accomplishes a useful task.
GFP successfully fulfills this prime directive.
GFP provides users an easy-to-use financial manager to manager their banks, assets, and credit cards. Included among these features are report and chart generation.
Prime Directive 2: An external user can successfully install and use the system.
GFP successfully fulfills this prime directive.
Download and installation was very simple for a non-developer. Starting up the program is also relatively simple, as the user is first prompted to input their country and language, then to select their account book. While it is not immediately obvious that the user should set up their account information first before they can start using GFP, data entry was very simple to input as all buttons are labeled or have descriptive icons. A step-by-step guide on how to use the features is located on the top bar labeled help.
Prime Directive 3: An external developer can successfully understand and enhance the system.
GFP does not fulfill this prime directive.
The source code for the latest release is provided here. There is lack of a readme file that details the contents. Documentation is not provided anywhere. The code is formatted correctly and have proper indentation. Looking at the source code itself, it is formatted properly and similar functions are in their own classes.. The source code is in Portuguese, which makes it harder for anyone who doesn't read the language to work on it.
GFP is an open-source program written in Java with a GUI provided by Java's swing library. Since the program is using strictly it's own library and Java's, it is platform independent. The purpose of GFP is to provide help on managing finances to users with limited financial knowledge and ability. Using a limited number of input fields, much of the work is done by GFP in creating readable financial spreadsheets. Even though it was last modified in 2007, GFP still receives many hits and downloads.
GFP can be downloaded from: http://sourceforge.net/projects/gfd/
 |
| Screenshot of GFP's GUI |
For a program to be classified as an open source software, the following prime directives must be fulfilled. More information on these prime directives can be found on this page.
Prime Directive 1: The system successfully accomplishes a useful task.
GFP successfully fulfills this prime directive.
GFP provides users an easy-to-use financial manager to manager their banks, assets, and credit cards. Included among these features are report and chart generation.
Prime Directive 2: An external user can successfully install and use the system.
GFP successfully fulfills this prime directive.
Download and installation was very simple for a non-developer. Starting up the program is also relatively simple, as the user is first prompted to input their country and language, then to select their account book. While it is not immediately obvious that the user should set up their account information first before they can start using GFP, data entry was very simple to input as all buttons are labeled or have descriptive icons. A step-by-step guide on how to use the features is located on the top bar labeled help.
Prime Directive 3: An external developer can successfully understand and enhance the system.
GFP does not fulfill this prime directive.
The source code for the latest release is provided here. There is lack of a readme file that details the contents. Documentation is not provided anywhere. The code is formatted correctly and have proper indentation. Looking at the source code itself, it is formatted properly and similar functions are in their own classes.. The source code is in Portuguese, which makes it harder for anyone who doesn't read the language to work on it.
Subscribe to:
Comments (Atom)