Over the course of this semester, I learned about a lot of new concepts such as continuous integration, issue tracking, and configuration management. The application of these techniques can assist in making development more efficient and productive. These are valuable techniques that can be applied to future projects. I feel that learning these new skills have helped me become a more productive developer and I will try to continue practicing these techniques in the future.
There were also a number of new tools such as CheckStyle, JUnit, PMD, FindBugs, and Ant that were introduced that assist development by automating tasks that would otherwise have to be done by the developer. While these tools cannot guarantee code quality, they allow developers to concentrate on other more important tasks. This allows developers to use their time more productively.
I found the most valuable part of this course to be the experiences that I gained while developing the different projects. Each project taught new skills such as learning about an existing project by reading code. The projects also provided me experience in the development of a system that could be used by consumers. Up to this point, I only had experience developing school-type applications that couldn't be used in the real world. Also, we learned about team management which is useful since, when we get hired, we will most likely be working as part of a team of developers. We had to learn about time management, division of responsibility, and effective communication methods in order to have a successful project. These aspects can be applied to any team project and are critical to the success of the project.
I would like to have learned more about development of web applications. The final project required us to create a web application. The development of the final application was done in just a couple of weeks which didn't give us much time to learn everything. I wish that we had more time to become more proficient with the Wicket Framework, HTML, and CSS because skills with these tools can be applied to many different areas.
Overall, I found this class to be very useful. It taught me many different skills that I am able to take with me and apply in other projects. I think that I have become a more effective developer because of the new techniques and tools that I have learned about.
Wednesday, December 9, 2009
WattWaiter Version 2.1 Release
WattWaiter 2.1 is the second release of the WattWaiter system. Version 2.1 introduced two new pages. A stop light page which provides users a visual representation of the current hour's carbon intensity has been added as well as a grid info page which provides a graphical representation of the carbon intensities of a specified source. By providing this information, WattWaiter hopes to help increase consumers' awareness about when they should plan energy use. Consumers can make informed decisions about scheduling their electricity usage to coincide with low carbon intensity periods.
The stop light page categorizes the current hour's carbon intensity into three categories represented by a green, yellow, or red light for low, moderate, and high carbon intensity respectively. The hours are categorized into colors based on their predicted carbon intensities for that day. The twelve lowest hours are given a green rating, the six next highest hours are given a yellow rating, and the six highest hours are given a red rating. The Wattdepot system is queried at the top of the hour for the current carbon intensity level.
The grid info page provides users with a graphical representation of the carbon intensity over a period of time. A user is able to specify a source, start date, and end date. There are also other options that the user can select such as if they would like to see a cumulative or transitive display, whether they would like to see the carbon or energy generated, and the time frame for the graph. After selecting these options, a user is provided with a line graph that represents the changing carbon intentiy over the specified period of time.
There were many new thing that were learned throughout the course of this project. The Wicket Framework, HTML, and CSS were some of the topics that were new to me. I found that learning to use these new syntaxes was a challenging task. Prior to this project, I had a very limited knowledge of HTML and CSS. It took a while until I got the hang of using their syntax. I also struggled with the Wicket Framework at the start, but it became easier to understand through working with it. There were also team and project management issues that were learned such as getting the whole team involved in development and keeping track of project issues. The Google project issue tracker helped with both of these issues by allowing assignment of tasks to members so everyone knew what they were resonsible for. As in version 1.0, I thought that our team worked well together. We didn't have to make many adjustments to the way our group was functioning. We helped one another when we got stuck, so we could keep progress moving forward. Overall, I found this experience to be a positive one.
The WattWaiter project page, where users are able to download the WattWaiter 2.1 system, can be found here. There is also additional information such as a user guide, developer guide, and release notes that can be viewed. A screenshot of WattWaiter 2.1 is shown below.
The stop light page categorizes the current hour's carbon intensity into three categories represented by a green, yellow, or red light for low, moderate, and high carbon intensity respectively. The hours are categorized into colors based on their predicted carbon intensities for that day. The twelve lowest hours are given a green rating, the six next highest hours are given a yellow rating, and the six highest hours are given a red rating. The Wattdepot system is queried at the top of the hour for the current carbon intensity level.
The grid info page provides users with a graphical representation of the carbon intensity over a period of time. A user is able to specify a source, start date, and end date. There are also other options that the user can select such as if they would like to see a cumulative or transitive display, whether they would like to see the carbon or energy generated, and the time frame for the graph. After selecting these options, a user is provided with a line graph that represents the changing carbon intentiy over the specified period of time.
There were many new thing that were learned throughout the course of this project. The Wicket Framework, HTML, and CSS were some of the topics that were new to me. I found that learning to use these new syntaxes was a challenging task. Prior to this project, I had a very limited knowledge of HTML and CSS. It took a while until I got the hang of using their syntax. I also struggled with the Wicket Framework at the start, but it became easier to understand through working with it. There were also team and project management issues that were learned such as getting the whole team involved in development and keeping track of project issues. The Google project issue tracker helped with both of these issues by allowing assignment of tasks to members so everyone knew what they were resonsible for. As in version 1.0, I thought that our team worked well together. We didn't have to make many adjustments to the way our group was functioning. We helped one another when we got stuck, so we could keep progress moving forward. Overall, I found this experience to be a positive one.
The WattWaiter project page, where users are able to download the WattWaiter 2.1 system, can be found here. There is also additional information such as a user guide, developer guide, and release notes that can be viewed. A screenshot of WattWaiter 2.1 is shown below.
Tuesday, November 24, 2009
Ecologineers Review
The Ecologineers system provides a web application for users to query the Wattdepot database for carbon intensity readings. Readings for each hour are returned with a rating of red, yellow, or green assigned. Based on these readings, users are able to make decisions regarding their electrical usage. My job was to perform a review of the Ecologineers system. My full review of the system can be found here.
I found that the overall functionality of the system was good. The system met the functional specifications. It returns the reading and rating of a specified day's carbon intensity in hourly increments. A UserGuide, DeveloperGuide, and ReleaseNotes were provided on the project website. The design and implementation is good, however, the visual aspect of the web application could be improved. A more visually appealing user interface could be implemented which would greatly improve the web interface. There were a few bugs in the system such as entering a year that is far in the past or a year in the future. The testing implemented seems to only check "happy paths". Adding tests that check bad input and the functionality of the web application would further ensure the quality of the system. The Ecologineers team did a good job of not letting the system stay in a failed state for a long period of time. The "health" of the system was moderate. The group seems to be functioning ok, however, it may benefit from starting earlier on the development of the project. This could help improve the project's "health" by raising the churn and commit statistics.
I found that the overall functionality of the system was good. The system met the functional specifications. It returns the reading and rating of a specified day's carbon intensity in hourly increments. A UserGuide, DeveloperGuide, and ReleaseNotes were provided on the project website. The design and implementation is good, however, the visual aspect of the web application could be improved. A more visually appealing user interface could be implemented which would greatly improve the web interface. There were a few bugs in the system such as entering a year that is far in the past or a year in the future. The testing implemented seems to only check "happy paths". Adding tests that check bad input and the functionality of the web application would further ensure the quality of the system. The Ecologineers team did a good job of not letting the system stay in a failed state for a long period of time. The "health" of the system was moderate. The group seems to be functioning ok, however, it may benefit from starting earlier on the development of the project. This could help improve the project's "health" by raising the churn and commit statistics.
Sunday, November 22, 2009
Wattwaiter 1.0
Wattwaiter is a web application that allows users to query the Wattdepot database to determine carbon intensities for a given day. By obtaining this information, consumers are able to make educated decisions about electrical usage. Wattwaiter provides a visual breakdown of the carbon intensities by hour. Colored flags are assigned to each hour to indicate the intensity. The flags are colored green, yellow, and red which correspond to low, moderate, and high carbon intensities respectively. We hope by providing this information to consumers, they are able to adjust their electrical usage and become "smart" consumers.
Using Wicket was difficult for me because I don't have much experience in creating web applications. Luckily, other members in my group were more experienced and able to help me understand how it works when I got stuck. Wicket in Action was a good resource that explained how to accomplish basic tasks using Wicket. Also, I found the Wicket examples to be very useful. They allowed me to view working code that demonstrated how to create different components. I also had to familiarize myself with HTML. Now, I have a basic understanding of HTML and Wicket that I hope will grow as the project progresses. Overall, I felt that the project went well.
I feel that the design of our system was good. We were able to accomplish the goals of the application without making use complicated. It is simple for users to query different dates and interpret the data that is returned. This is an important aspect of the project, so users will not feel it is a hassle to use.
I feel that our group worked well together. We all contributed to the design and implementation of the project. Having several different perspectives helped to improve the design of the system by considering different approaches. Also, our communication was good which helped everyone stay on-track.
Shown below is a screenshot of our software ICU from Hackystat. By observing the metrics, it can be seen that there is room for improvement. The areas that need improvement are churn and testing. We will put more focus on these aspects during the cycle of the project.
Below is a link to our project website where guides on Wattwaiter and a distribution of the system can be found.
Wattwaiter 1.0
Using Wicket was difficult for me because I don't have much experience in creating web applications. Luckily, other members in my group were more experienced and able to help me understand how it works when I got stuck. Wicket in Action was a good resource that explained how to accomplish basic tasks using Wicket. Also, I found the Wicket examples to be very useful. They allowed me to view working code that demonstrated how to create different components. I also had to familiarize myself with HTML. Now, I have a basic understanding of HTML and Wicket that I hope will grow as the project progresses. Overall, I felt that the project went well.
I feel that the design of our system was good. We were able to accomplish the goals of the application without making use complicated. It is simple for users to query different dates and interpret the data that is returned. This is an important aspect of the project, so users will not feel it is a hassle to use.
I feel that our group worked well together. We all contributed to the design and implementation of the project. Having several different perspectives helped to improve the design of the system by considering different approaches. Also, our communication was good which helped everyone stay on-track.
Shown below is a screenshot of our software ICU from Hackystat. By observing the metrics, it can be seen that there is room for improvement. The areas that need improvement are churn and testing. We will put more focus on these aspects during the cycle of the project.
Below is a link to our project website where guides on Wattwaiter and a distribution of the system can be found.
Wattwaiter 1.0
Sunday, November 15, 2009
Wattdepot Version 2.0
The goal of the Wattdepot-CLI project was to create a command line interface that could access Wattdepot and return useful information to users. This information could then be used to improve electricity usage of consumers.
Wattdepot 2.0 is the second release of our command line interface. Wattdepot Version 2.0 features 3 new commands in addition to the previous commands that were originally released. Our initial version used the correct structure for the program which made creation of Version 2.0 much easier. The most commonly observed weakness of our original program was insufficient Javadocs. In Version 2.0, we improved the Javadocs in order to make the API easier for other developers to understand. The testing that was implemented for each command verified not only happy paths, but also covered input validation and exception checking. Our coverage was decent at 82%, however, there is still much room for improvement.
In order for this project to be successful, it took teamwork and dedication. We met in person as often as possible and regularly on IRC to discuss progress of the project as well as issues that arose. We divided the work evenly between the group members which ensured that each member was participating. I felt that all members of the group carried their weight. Each member's work was critical in the success of this project.
Hackystat is a software ICU which tracks the statistics of your project in order to ensure that you stay on track. It provides information dealing with the automated quality assurance tools we have been using as well as ANT and Eclipse. Hackystat also provides a visual summary of the projects "health". At a glance, developers are able to see the "health" of their project in order to keep a project's progress in the right direction. By looking at our Hackystat metrics, our project's "health" was decent, but our testing statistic could use some improvement. Our project's Hackystat chart is shown below. Click on the image for an enlarged view.
Below are the results to some queries that were executed using our Wattdepot-CLI.
What day and time during the month was Oahu energy usage at its highest? How many MW was this?
November 2-6, 9-13, 16-20, and 23-27 all had a usage of 995MW
What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
November 2-6, 9-13, 16-20, 23-27 all had a usage of 493MW
What day during the month did Oahu consume the most energy? How many MWh was this?
There was no data found for this.
What day during the month did Oahu consume the least energy? How many MWh was this?
There was no data found for this.
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
On November 4, 5, 16, 17, and 30, 29,959 lbs of carbon were emitted.
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
On November 7 and 8, 22,908 lbs of carbon were emitted.
Wattdepot 2.0 is the second release of our command line interface. Wattdepot Version 2.0 features 3 new commands in addition to the previous commands that were originally released. Our initial version used the correct structure for the program which made creation of Version 2.0 much easier. The most commonly observed weakness of our original program was insufficient Javadocs. In Version 2.0, we improved the Javadocs in order to make the API easier for other developers to understand. The testing that was implemented for each command verified not only happy paths, but also covered input validation and exception checking. Our coverage was decent at 82%, however, there is still much room for improvement.
In order for this project to be successful, it took teamwork and dedication. We met in person as often as possible and regularly on IRC to discuss progress of the project as well as issues that arose. We divided the work evenly between the group members which ensured that each member was participating. I felt that all members of the group carried their weight. Each member's work was critical in the success of this project.
Hackystat is a software ICU which tracks the statistics of your project in order to ensure that you stay on track. It provides information dealing with the automated quality assurance tools we have been using as well as ANT and Eclipse. Hackystat also provides a visual summary of the projects "health". At a glance, developers are able to see the "health" of their project in order to keep a project's progress in the right direction. By looking at our Hackystat metrics, our project's "health" was decent, but our testing statistic could use some improvement. Our project's Hackystat chart is shown below. Click on the image for an enlarged view.
Below are the results to some queries that were executed using our Wattdepot-CLI.
What day and time during the month was Oahu energy usage at its highest? How many MW was this?
November 2-6, 9-13, 16-20, and 23-27 all had a usage of 995MW
What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
November 2-6, 9-13, 16-20, 23-27 all had a usage of 493MW
What day during the month did Oahu consume the most energy? How many MWh was this?
There was no data found for this.
What day during the month did Oahu consume the least energy? How many MWh was this?
There was no data found for this.
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
On November 4, 5, 16, 17, and 30, 29,959 lbs of carbon were emitted.
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
On November 7 and 8, 22,908 lbs of carbon were emitted.
Tuesday, November 10, 2009
Software Review Experiences
Peer reviewing is a process where other developers review your code and provide comments about good and bad things that they find. Performing these reviews is not only beneficial to the project that you are reviewing, but also to yourself. Peer reviews are a great way to help other developers improve their code while improving your own skills at the same time.
While performing reviews, we are able to practice our code reading and understanding skills. These are important skills to have as many large projects require working with other developers. Being able to read and understand other's code makes you a valuable team member because you are able to help others when they run into problems. I was also able to view weak points in other programs. By taking note of areas that other projects need to improve, I was able to see areas in my own project that could use improvement.
There are many ways to write code to accomplish a certain task. Everyone's mind works differently, so people usually go about doing things in different ways. It is useful to observe how other people solve a problem as it is difficult for one person to think of all solutions. By reviewing other developer's code, we are able to learn new techniques that we can add to our own arsenal. This helps us to continually grow as programmers. While performing the reviews, I saw different ways of solving problems which made me re-think my solution. I think that a best solution is often produced by combining the good parts of many different solutions.
I was able to learn a lot by reading comments about our project. The information provided was very useful. Reviewers were able to find flaws in the program that we were unable to find during our own code review. We were also able to get feedback about which parts of our program were difficult to understand. The ability of other developers to understand your code is as important as the functionality of the code itself. By fixing these issues, we will improve the quality of our program and take one step closer to accomplishing Prime Directive Number 3 (an external developer can successfully understand and enhance the system).
I found peer reviews to be a very useful tool. It provided insight into other's code as well as my own. Performing reviews is great for learning new ways of accomplishing tasks while helping out fellow developers. Reading other's reviews of your code can give you insight into what other people see when they look at your code. If we let it, the information provided can show us different views which can help us improve our skills. In order to continue to grow as programmers, we must have an open mind.
While performing reviews, we are able to practice our code reading and understanding skills. These are important skills to have as many large projects require working with other developers. Being able to read and understand other's code makes you a valuable team member because you are able to help others when they run into problems. I was also able to view weak points in other programs. By taking note of areas that other projects need to improve, I was able to see areas in my own project that could use improvement.
There are many ways to write code to accomplish a certain task. Everyone's mind works differently, so people usually go about doing things in different ways. It is useful to observe how other people solve a problem as it is difficult for one person to think of all solutions. By reviewing other developer's code, we are able to learn new techniques that we can add to our own arsenal. This helps us to continually grow as programmers. While performing the reviews, I saw different ways of solving problems which made me re-think my solution. I think that a best solution is often produced by combining the good parts of many different solutions.
I was able to learn a lot by reading comments about our project. The information provided was very useful. Reviewers were able to find flaws in the program that we were unable to find during our own code review. We were also able to get feedback about which parts of our program were difficult to understand. The ability of other developers to understand your code is as important as the functionality of the code itself. By fixing these issues, we will improve the quality of our program and take one step closer to accomplishing Prime Directive Number 3 (an external developer can successfully understand and enhance the system).
I found peer reviews to be a very useful tool. It provided insight into other's code as well as my own. Performing reviews is great for learning new ways of accomplishing tasks while helping out fellow developers. Reading other's reviews of your code can give you insight into what other people see when they look at your code. If we let it, the information provided can show us different views which can help us improve our skills. In order to continue to grow as programmers, we must have an open mind.
Sunday, November 8, 2009
Wattdepot-CLI Review
After creating our Wattdepot-CLI, we were tasked to perform reviews of two other groups projects. The criteria for the reviews were provided and can be found here. The two projects that I reviewed were for Eiwa and Umi.
Eiwa - The project was able to be built successfully and all the commands were functional. Some changes may need to be made to either the help menu or the command names as they do not match. Different classes were created for each of the different commands. The JUnit tests implemented were good, however, additional testing needs to be implemented for the remaining untested methods. Some reorganization may need to be done. The full report for this project can be found here.
Umi - The project was able to be built successfully and all the commands were functional. Reorganization of the commands should probably be done, so multiple commands are not implemeted in a single class. Also, this project may want to seperate the command line interface and the commands into seperate packages. More test cases need to be generated to provide sufficient checks of functionality. The full report for this project can be found here.
Eiwa - The project was able to be built successfully and all the commands were functional. Some changes may need to be made to either the help menu or the command names as they do not match. Different classes were created for each of the different commands. The JUnit tests implemented were good, however, additional testing needs to be implemented for the remaining untested methods. Some reorganization may need to be done. The full report for this project can be found here.
Umi - The project was able to be built successfully and all the commands were functional. Reorganization of the commands should probably be done, so multiple commands are not implemeted in a single class. Also, this project may want to seperate the command line interface and the commands into seperate packages. More test cases need to be generated to provide sufficient checks of functionality. The full report for this project can be found here.
Subscribe to:
Posts (Atom)