Although there was so much reading and implementing a lot of code. ICS 413 was a very informative and fun class. This class taught a lot about standardization and major development. I believe these two things made me a better programmer. By doing all the reviews for classmates, it was very noticeable that standardization was very important in programming.
What I would like to learn more about is User Interface. I noticed that we all have problems with a good user interface. When any group went up in front of the class to present their project, they then notice that a part of their project could look better, and the teacher would point out something we would not notice.
I had fun in this class because the teacher was the most interesting teacher than any teacher I had so far (This is not me brown nosing). I think that the only thing that was hard was the major reading. It was hard to get the reading done, code, and get other classes done also. However, overall this class was fun and informative.
Friday, December 18, 2009
The Final: Greendepot 2.1
It has been a long semester of cramming code together to finish our last project, and it is over!!!! Since the 16th of November, we have worked on a project called Greendepot. This project takes what we learned in Wattdepot and output the information for users on the internet. It is just like any basic website, homepage and links to other pages. Certain pages inform the user about the carbon intensity. The stoplight page tells the intensity now and Gridinfo outputs a graph. And we have a home page and a contact page.
What we did now was update a lot of the looks for our website. It was a really hard start for this project, but if you look at the differences when we first started and now, there is a huge difference. Between 2.0 and 2.1 we tried to implement bonus things and we fixed a lot of the errors we had at 2.0. I tried to implement the google visualization, but I could not figure out how to implement it very well. I was able to have it output to the screen but not get the information i needed for the output to be correct. So, instead of leaving a non working visualization, I left what we had before for 2.1 Overall, we corrected the errors we had such as default settings for the drop down lists.
SO, version 2.1 could be found here. My last 413 project. Until next semester with 414. Have a nice break.
What we did now was update a lot of the looks for our website. It was a really hard start for this project, but if you look at the differences when we first started and now, there is a huge difference. Between 2.0 and 2.1 we tried to implement bonus things and we fixed a lot of the errors we had at 2.0. I tried to implement the google visualization, but I could not figure out how to implement it very well. I was able to have it output to the screen but not get the information i needed for the output to be correct. So, instead of leaving a non working visualization, I left what we had before for 2.1 Overall, we corrected the errors we had such as default settings for the drop down lists.
SO, version 2.1 could be found here. My last 413 project. Until next semester with 414. Have a nice break.
Tuesday, November 24, 2009
Review of Greensmart
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.
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.
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.
Subscribe to:
Posts (Atom)