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.
Subscribe to:
Comments (Atom)