After the cramming of making our projects work, now it is time to review each others projects and if we got them to work correctly. The group project I was assigned to was Greensmart. Their project looked very good. The home page looked very professional and the logo they have makes it a legit looking program.
The project was able to handle anything that i threw into it. Al l the error handling captured each thing I wrote. What I really like from the error handling was that it knows when you have entered a date too long ago when electricity was not being documented yet and if you enter a date after today's date, it says it cannot retrieve things in the future.
To look at my full review, click here.
But overall, I think the project looks good, but for a brand new computer user, it would be hard to understand how to work the program. The changes needed would just be to make it like Greensmart for Dummies.
Tuesday, November 24, 2009
Monday, November 23, 2009
The OscarWebApp called Greendepot
So far throughout the development of Wattdepot, there were many struggles. If you look at my previous blogs it would tell you a tale of hardship and pain. Greendepot is an add on to Wattdepot. But instead of just printing numbers to the screen, this project uses a user friendly web page that displays the carbon emission of the given day and displays when a home owner should use electricity, via green, yellow, or red flag.
This project was a very big task. It was hard to implement this project because setting up the build files, hackystat, and subversion took us a lot of time to get them up and running. Although, it was not our fault, hackkystat was giving a lot of errors and that stopped us from moving forward because without hackystat, our work for the project would not be displayed. From the countless time we took looking into the error, we found that it was an update to the site and everything would be normal later. If that was known we would have been able to start the project earlier. With this setback, we now had to rush and make the project.
The group worked very well together. We met during the day and when class was not in session. The build of the project is not so great because of us rushing to get it working.
Above is the work that my group has done. As you can see not much was done in the beginning, (Commit). That was where we were trying to get hackystat and the .xml files working. Then we started on the project and that is where you can see spikes in the build. I really believe that if we were told about hackystat, the project would be complete.
As of now, the web app takes in the user's input and just echos it. But we have the command line printing what is suppose to be in the web app. We could not integrate the output into the web app in time.
The download for our project could be found here.
This project was a very big task. It was hard to implement this project because setting up the build files, hackystat, and subversion took us a lot of time to get them up and running. Although, it was not our fault, hackkystat was giving a lot of errors and that stopped us from moving forward because without hackystat, our work for the project would not be displayed. From the countless time we took looking into the error, we found that it was an update to the site and everything would be normal later. If that was known we would have been able to start the project earlier. With this setback, we now had to rush and make the project.
The group worked very well together. We met during the day and when class was not in session. The build of the project is not so great because of us rushing to get it working.
Above is the work that my group has done. As you can see not much was done in the beginning, (Commit). That was where we were trying to get hackystat and the .xml files working. Then we started on the project and that is where you can see spikes in the build. I really believe that if we were told about hackystat, the project would be complete.
As of now, the web app takes in the user's input and just echos it. But we have the command line printing what is suppose to be in the web app. We could not integrate the output into the web app in time.
The download for our project could be found here.
Monday, November 16, 2009
WattDepot 2.0!!!!!!!!!!!!!
After our class reviewed each others code for Wattdepot, we all needed to remake everything. And now here is 2.0!!!!!! The program could be downloaded here. Click on WattDepotCli Version 2 by Team Eiwa.
This project, Wattdepot, collects information about electrical data from meters in certain areas. We created a program that takes this information and organizes it in a way for easy readability. And what is new in the new version 2.0, we added a SoftwareICU system called Hackystat. Hackystat gives us great information on analysis, visualization, interpretation, annotation, and dissemination for us to monitor the project.
Our system fulfills all of the requirements. We changed most of the issues made by our reviewers, but documentation could still be improved. We also created a somewhat high-quality system design. I had it in a way where test commands and regular commands was in different packages for easy readability, but there was changes to that. And due to our reviews about testing our code, we made test cases for every command.
The group could not meet regularly due to conflicting schedules. We did split the work equally, but changes were made to each others code so we both corrected each others code.
The Software ICU shows that our test coverage is mostly stable. It also shows that our builds, tests, and commits a spiky, this is because the group doesn't meet regularly so we are doing the project on our own and that makes the graph jumpy.
The following is the questions we had to answer using our program:
What day and time during the month was Oahu energy usage at its highest? How many MW was this?
Time: 2009-11-02T20:00:00.000-10:00 Power: 995.0 MegaWatts
What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
Time: 2009-11-02T04:00:00.000-10:00 Power: 493.0 MegaWatts
What day during the month did Oahu consume the most energy? How many MWh was this?
Time: 2009-11-02T00:00:00.000-10:00 Power: 14764.0 MegaWatt-Hours
What day during the month did Oahu consume the least energy? How many MWh was this?
Time: 2009-11-01T00:00:00.000-10:00 Power: 14089.0 MegaWatt-Hours
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
Time: 2009-11-04T00:00:00.000-10:00 Carbon: 29959472 pounds
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
Time: 2009-11-07T00:00:00.000-10:00 Carbon: 22908808 pounds
This project, Wattdepot, collects information about electrical data from meters in certain areas. We created a program that takes this information and organizes it in a way for easy readability. And what is new in the new version 2.0, we added a SoftwareICU system called Hackystat. Hackystat gives us great information on analysis, visualization, interpretation, annotation, and dissemination for us to monitor the project.
Our system fulfills all of the requirements. We changed most of the issues made by our reviewers, but documentation could still be improved. We also created a somewhat high-quality system design. I had it in a way where test commands and regular commands was in different packages for easy readability, but there was changes to that. And due to our reviews about testing our code, we made test cases for every command.
The group could not meet regularly due to conflicting schedules. We did split the work equally, but changes were made to each others code so we both corrected each others code.
The Software ICU shows that our test coverage is mostly stable. It also shows that our builds, tests, and commits a spiky, this is because the group doesn't meet regularly so we are doing the project on our own and that makes the graph jumpy.
The following is the questions we had to answer using our program:
What day and time during the month was Oahu energy usage at its highest? How many MW was this?
Time: 2009-11-02T20:00:00.000-10:00 Power: 995.0 MegaWatts
What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
Time: 2009-11-02T04:00:00.000-10:00 Power: 493.0 MegaWatts
What day during the month did Oahu consume the most energy? How many MWh was this?
Time: 2009-11-02T00:00:00.000-10:00 Power: 14764.0 MegaWatt-Hours
What day during the month did Oahu consume the least energy? How many MWh was this?
Time: 2009-11-01T00:00:00.000-10:00 Power: 14089.0 MegaWatt-Hours
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
Time: 2009-11-04T00:00:00.000-10:00 Carbon: 29959472 pounds
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
Time: 2009-11-07T00:00:00.000-10:00 Carbon: 22908808 pounds
Tuesday, November 10, 2009
My Review Experience
After reviewing my peers code, I learned a lot of things. A lot of us procrastinates. When the deadline is near, everyone starts putting whatever they can together. That is why there is no test cases, comments, and "one person doing the job". What we all should do differently is set for ourselves an earlier date so that we do not procrastinate on the real due date.
Not much people did test cases because they are concentrating to get the project done. But while rushing to get the project done, they have been "testing" it the whole time, because they look to see if what they just made is outputting the right thing. However, just because we see that the program works we still need to make test castes. We should show test cases because then the programmer/reviewer can know that the code is working correctly or incorrectly. But the most important thing that I saw while reviewing my peers code is comments. Comments help the most for the user or reviewer to know what is going on in the code. It may seem stupid to comment something small, but it is important.
What I learned from my reviews is that to start early. It is bad to start late because you will get crappy code and not get everything done and lose sleep time.
Not much people did test cases because they are concentrating to get the project done. But while rushing to get the project done, they have been "testing" it the whole time, because they look to see if what they just made is outputting the right thing. However, just because we see that the program works we still need to make test castes. We should show test cases because then the programmer/reviewer can know that the code is working correctly or incorrectly. But the most important thing that I saw while reviewing my peers code is comments. Comments help the most for the user or reviewer to know what is going on in the code. It may seem stupid to comment something small, but it is important.
What I learned from my reviews is that to start early. It is bad to start late because you will get crappy code and not get everything done and lose sleep time.
Monday, November 9, 2009
Wattdepot Reviews
After the long nights and cramming the making of our wattdepot-cli projects, we were tasked to perform reviews on our peers' project. The Criteria for this review could be found here. We were tasked to review two projects, the two that I reviewed was ewalu and umi.
Ewalu:
An overview of this project is that it builds and it runs. However what I could not figure out is how to do other methods than just quit, help, and list sources. The other commands do not work. What could be improved in this project is the separating the commands into a package and each in their own class. To see the full report click here.
Umi:
An overview of this project is that it build and it runs. What could be improved in this project is the separation of the commands and putting them into a package and different classes. Also, to make test cases for the project because there is none made. To see the full report click here.
Ewalu:
An overview of this project is that it builds and it runs. However what I could not figure out is how to do other methods than just quit, help, and list sources. The other commands do not work. What could be improved in this project is the separating the commands into a package and each in their own class. To see the full report click here.
Umi:
An overview of this project is that it build and it runs. What could be improved in this project is the separation of the commands and putting them into a package and different classes. Also, to make test cases for the project because there is none made. To see the full report click here.
Wednesday, November 4, 2009
Learning integration through Wattdepot
For one week, my class has been working on a new project called Wattdepot. Wattdepot is a system that is accessible by anyone to store and analyze power consumption. This tool is great for consumers that want to monitor their power consumption. However, this tool can make the bill more accurate and could cost more if you are not careful.
My partner for this project is David Mau. We split the work up by looking at the list that needs to be done and did every other to split the workload. David did a great job in making the code easily read and understood. I say this because I had to do the CommandLineInterface and every file he made, I was able to implement it easily. To not stray away from his style, I followed it as closely as i could so that the whole project has the same style.
About every goal was achieved during this past week. However, on my part, I did not make any test cases for my commands and the CommandLineInterface that my teacher wanted was not implemented. But what I did do was make a CommandLineInterface that was able to run everything with no problem. As for test cases, I should be able to make some but not before the deadline. Plus I think I did so many test cases for myself because I did the CommandLineInterface and checked to see every time that what I needed to print printed. ahahhahaha. date, timestamp, description.... By looking at our project code, everything had a return statement except for the quitCommand. Also, for the power chart, I tried my best to figure out how to get the file, but I am really not sure how that works.
Overall, I had fun working with David even though we could not meet up every day. I think not meeting up about every day or other day broke a communication barrier for this project. We both had things to do so setting our minds straight for this project was difficult. But, David is a great partner and smart is coding.
After this, I will definitely fix the code to work properly and look more efficient. Click here to download our project. Our project name is wattdepot-cli-eiwa.
My partner for this project is David Mau. We split the work up by looking at the list that needs to be done and did every other to split the workload. David did a great job in making the code easily read and understood. I say this because I had to do the CommandLineInterface and every file he made, I was able to implement it easily. To not stray away from his style, I followed it as closely as i could so that the whole project has the same style.
About every goal was achieved during this past week. However, on my part, I did not make any test cases for my commands and the CommandLineInterface that my teacher wanted was not implemented. But what I did do was make a CommandLineInterface that was able to run everything with no problem. As for test cases, I should be able to make some but not before the deadline. Plus I think I did so many test cases for myself because I did the CommandLineInterface and checked to see every time that what I needed to print printed. ahahhahaha. date, timestamp, description.... By looking at our project code, everything had a return statement except for the quitCommand. Also, for the power chart, I tried my best to figure out how to get the file, but I am really not sure how that works.
Overall, I had fun working with David even though we could not meet up every day. I think not meeting up about every day or other day broke a communication barrier for this project. We both had things to do so setting our minds straight for this project was difficult. But, David is a great partner and smart is coding.
After this, I will definitely fix the code to work properly and look more efficient. Click here to download our project. Our project name is wattdepot-cli-eiwa.
Monday, November 2, 2009
Hudson the System Checker
Continuous Integration is a software development practice where members of a team integrate their work frequently/daily. Each integration would be verified by an automated build to detect errors. By doing integration frequently/daily, there are less integration problems and it allows the team to develop software quickly.
What we are using for our watt-depot-cli project is Hudson. We configured Hudson to work side by side with SVN, which checks changes made to the project. Whenever changes are made to the project, Hudson would ensure that everything is working correctly. If it is not, it would send email notifications to whoever is associated with the project. This great feature allows developers to know that there was an update made that failed, and it can be fixed by anyone.
Right away when testing small parts of our code, I could see the benefits of using continuous integration. It keeps the user updated for every single thing. Also, it gives little symbols of what is going on with the code and if the code is working correctly or not.
One small problem I see with Hudson is that the little cloud symbols don't give the right symbol. It starts off with a sun saying everything is great and running correctly. Then when we tested Hudson to see if it works with our project, it gives a little cloud. Which was correct because we were just testing it. But when we fixed it, it did not change back to the sun. If anyone was to just look at that symbol, they would think that the code is not doing what it is suppose to do even though it is fine.
I think that this is a great tool to use when in a group project. If you cannot meet with the group all the time, this tool helps by keeping you updated.
What we are using for our watt-depot-cli project is Hudson. We configured Hudson to work side by side with SVN, which checks changes made to the project. Whenever changes are made to the project, Hudson would ensure that everything is working correctly. If it is not, it would send email notifications to whoever is associated with the project. This great feature allows developers to know that there was an update made that failed, and it can be fixed by anyone.
Right away when testing small parts of our code, I could see the benefits of using continuous integration. It keeps the user updated for every single thing. Also, it gives little symbols of what is going on with the code and if the code is working correctly or not.
One small problem I see with Hudson is that the little cloud symbols don't give the right symbol. It starts off with a sun saying everything is great and running correctly. Then when we tested Hudson to see if it works with our project, it gives a little cloud. Which was correct because we were just testing it. But when we fixed it, it did not change back to the sun. If anyone was to just look at that symbol, they would think that the code is not doing what it is suppose to do even though it is fine.
I think that this is a great tool to use when in a group project. If you cannot meet with the group all the time, this tool helps by keeping you updated.
Subscribe to:
Posts (Atom)