Today was the last official class meeting for my software engineering class, and as a final assignment, we were asked to write a blog post summarizing our thoughts on software engineering and the course in particular.
I started the class not knowing what exactly software engineering was, but being excited about the opportunity to work with others to develop code. In all previous classes, we received very stern warnings that we were not to work with others on homework assignments, so I developed a very strong mentality of programming everything on my own with only minimal conversations between my classmates and I regarding our code. As a result, I took the class wanting to see what it was like to program with others.
Throughout the course, I've learned that software engineering is a complex process, but that there are many tools available for programmers to use to help them do software engineering with the least possible pain. Before the class, I didn't know how complicated it was to share a project with new developers; nor did I anticipate how difficult it would be to have two people working on the same programming project. Among the tools that we learned in class were JUnit, to test the code for constant functionality; Ant, to standardize the development environment; Subversion, to facilitate sharing code; and Google Project Hosting, to provide hosting for the project code and a way to track issues on the project. All of these tools were difficult to learn or get used to at first, but once I got a basic understanding of them, they definitely made group work a lot easier.
I think that one of the most important aspects of the class for me wasn't necessarily the programming experience, but the development of a professional person that I can use to present myself to graduate schools and prospective employers. This includes not only the programming and software engineering skills that I picked up on in the course, but also my professional portfolio and this blog. These are both items that I will be able to continue to update and to use to present my programming skills and my knowledge of software engineering.
This class was a lot of work, and I definitely spent more time working on assignments for this class than for any of my other courses this semester (and possibly any of the other courses in my undergraduate career). However, because of this, I feel that I have a much better understanding of what is involved in the creation, development, and deployment of a programming project. I now know how much time is involved in the process and I know of the tools available for use to facilitate software engineering. It was a tough experience, but it was a good experience to have had.
Wednesday, December 9, 2009
Eco-Depot version 2.0
As the final project for my software engineering class, my group and I worked on improving the design and increasing the functionality of the Eco-Depot web application, as discussed in my last few blog posts. This involved going back to our previous implementation to make it more user friendly while adding additional features to the system.
For those of you who have not read my previous posts, Eco-Depot is a web application that seeks to provide information to users on the state of the Oahu power grid, based on the WattDepot system. This is done by analyzing the ratio of carbon versus energy produced, so that Oahu residents can reduce their carbon footprint on the environtment. Additional features for version 2.0 allow users to easily access information on the amount of energy produced by the grid. The application seeks to provide energy consumers with the information that they need to become smart consumers. As a side note, the WattDepot system currently uses simulated data for the grid.
One of the main problems with our version 1.0 implementation is that it was not designed with an ordinary user in mind. It had very few instructions, no obvious purpose, and had a very bleak look and feel. One of the main things that we tried to do for version 2.0 was to make it easier for an average user to understand and use the site. This was done by adding in a main page with an introduction to the system, as well as providing additional information on pages with functionality. We also included more graphics (all made by Kendyll) and used CSS to provide a standard look and feel for the page.
The second major item that we needed to accomplish for version 2.0 was to convert our table of carbon content data into a stoplight to display only the current analysis, as well as to write a second page that would allow users to see the energy produced by any of the Oahu power sources over a specified period of time. Most of these items were not extremely difficult to do - it was all of the background work that took a long time to understand. In particular, we had to wrestle with understanding and implementing sessions for the pages so that multiple users would be able to use the application without inadvertent sharing of the information between the two. Additionally, we experienced problems with Wicket because of our lack of experience working with the language.
Overall, I learned a lot about Wicket from working with this project. Also, and perhaps more importantly, the entire web application creation process gave me a better understanding of software engineering and the effort that it takes to program something with a team of people rather than alone. One of my group's biggest problems was generally communication - communication about what we were working on, communication about what we needed help on, and communication on what everyone else needed to do so that everything would come together smoothly. Although we used the Issues management feature of Google Code, sometimes we ran into problems where one developer's item relied on things being written by another developer, but the two pieces needed additional work in order to communicate together. As we neared the project due date, I feel that we were a lot better about communication because we had all realized that we needed to constantly keep in touch so that everyone would be able to work on something at the same time with minimal clashes.
Our completed product can be downloaded for use as a Java jar file, and with the complete code in a zipped distribution file on the project's Google Code Downloads page. Additional information on the product and its development are also available on the project's page.
For those of you who have not read my previous posts, Eco-Depot is a web application that seeks to provide information to users on the state of the Oahu power grid, based on the WattDepot system. This is done by analyzing the ratio of carbon versus energy produced, so that Oahu residents can reduce their carbon footprint on the environtment. Additional features for version 2.0 allow users to easily access information on the amount of energy produced by the grid. The application seeks to provide energy consumers with the information that they need to become smart consumers. As a side note, the WattDepot system currently uses simulated data for the grid.
One of the main problems with our version 1.0 implementation is that it was not designed with an ordinary user in mind. It had very few instructions, no obvious purpose, and had a very bleak look and feel. One of the main things that we tried to do for version 2.0 was to make it easier for an average user to understand and use the site. This was done by adding in a main page with an introduction to the system, as well as providing additional information on pages with functionality. We also included more graphics (all made by Kendyll) and used CSS to provide a standard look and feel for the page.
The second major item that we needed to accomplish for version 2.0 was to convert our table of carbon content data into a stoplight to display only the current analysis, as well as to write a second page that would allow users to see the energy produced by any of the Oahu power sources over a specified period of time. Most of these items were not extremely difficult to do - it was all of the background work that took a long time to understand. In particular, we had to wrestle with understanding and implementing sessions for the pages so that multiple users would be able to use the application without inadvertent sharing of the information between the two. Additionally, we experienced problems with Wicket because of our lack of experience working with the language.
Overall, I learned a lot about Wicket from working with this project. Also, and perhaps more importantly, the entire web application creation process gave me a better understanding of software engineering and the effort that it takes to program something with a team of people rather than alone. One of my group's biggest problems was generally communication - communication about what we were working on, communication about what we needed help on, and communication on what everyone else needed to do so that everything would come together smoothly. Although we used the Issues management feature of Google Code, sometimes we ran into problems where one developer's item relied on things being written by another developer, but the two pieces needed additional work in order to communicate together. As we neared the project due date, I feel that we were a lot better about communication because we had all realized that we needed to constantly keep in touch so that everyone would be able to work on something at the same time with minimal clashes.
Our completed product can be downloaded for use as a Java jar file, and with the complete code in a zipped distribution file on the project's Google Code Downloads page. Additional information on the product and its development are also available on the project's page.
Tuesday, November 24, 2009
Reviewing the Greendepot Wicket Web Application
The application that I worked on as described in my last blog post was a class project in which each group of 3-4 members created their own application. Here, I present a coding review of the Greendepot web application, which can be found on Google Code here.
My full review of the project can be downloaded here, but in this blog post, I would like to make comments on a few key points regarding the project.
First of all, the application just needs a bit more time and work. The main thing is that results are printed on the command line, rather than on the web page. This is one thing that definitely needs to be cleaned up before the next version release, as it is not very user-friendly. Additionally, although it provides the carbon content for each hour for a day, it does not analyze the actual numbers to say if it would be a good idea to use electricity at a specific time or not.
Second, I found one area in the code that would be worth considering refactoring. This is the setDate method in the CarbonCalculator class. Briefly, this method seems to do a lot more than its name implies, so at the very least the method name should be changed, although I think it would be best to split up the tasks done by the method. Rather than setting the date, creating a list of data, and saving the string of data (for output purposes), it would be better if these three tasks should be split into three separate methods.
Finally, in regards to Continuous Integration, I would like to make the point that the Hudson build for the greendepot project does not seem to be executing any Ant tasks when changes in the code are detected. This is important for monitoring the project and should be fixed as soon as possible.
Again, these are the two main problems that I found. Please refer to my full review, referenced above, for complete comments.
My full review of the project can be downloaded here, but in this blog post, I would like to make comments on a few key points regarding the project.
First of all, the application just needs a bit more time and work. The main thing is that results are printed on the command line, rather than on the web page. This is one thing that definitely needs to be cleaned up before the next version release, as it is not very user-friendly. Additionally, although it provides the carbon content for each hour for a day, it does not analyze the actual numbers to say if it would be a good idea to use electricity at a specific time or not.
Second, I found one area in the code that would be worth considering refactoring. This is the setDate method in the CarbonCalculator class. Briefly, this method seems to do a lot more than its name implies, so at the very least the method name should be changed, although I think it would be best to split up the tasks done by the method. Rather than setting the date, creating a list of data, and saving the string of data (for output purposes), it would be better if these three tasks should be split into three separate methods.
Finally, in regards to Continuous Integration, I would like to make the point that the Hudson build for the greendepot project does not seem to be executing any Ant tasks when changes in the code are detected. This is important for monitoring the project and should be fixed as soon as possible.
Again, these are the two main problems that I found. Please refer to my full review, referenced above, for complete comments.
Monday, November 23, 2009
Introducing Eco-Depot!
For my software engineering class, this past week has involved working on another aspect of interaction with the WattDepot client. Whereas before we focused on creating a command line interface for the system, this past week we began to look at designing a web application for it, which is intended to make the system more user-friendly and accessible to the general public. In particular, we were to design a web application that would take a date as input, and output a table showing the carbon content of the simulated Oahu grid per hour, analyzing if the carbon output is low, medium, or high. My group chose to name our project Eco-Depot.
This time, we got assigned to groups of four for the assignment, generally with two pairs being put into one larger group. At first, it was pretty difficult for me to work with a larger group. One thing was definitely the fact that we did not meet face-to-face much, and were not consistent with virtual communication. As a result, we ended up with a few instances of group members not realizing that tasks had not been completed, or group members wondering exactly what they were supposed to do.
My main task for the development of the web application was to write the Java code for the main interaction with the WattDepot client. The hardest part of this was anticipating what would be necessary for the people who were mainly writing Wicket. To tackle this problem, I first tired to extend the command line interface that Kendyll and I had written last week, but found that I was second-guessing myself, especially when trying to add things to the Wicket application. As a result, I wrote several key methods, let my team members work on it, then looked to that for feedback on what else I needed to write. The biggest disconnect that I noticed was when they used arrays to handle working with data, while lists were the most convenient data structure for my end of the programming.
Overall, I think that although my group got the assigned task done, we could have worked better together. The main thing that I think we needed to do was to communicate better; Kendyll and I had a good system of relying on Google's chat to talk while we were programming, and we knew that we would check our e-mail multiple times a day, but this didn't seem to be the case for our other two group members. Getting things like this straightened out from the start probably would have saved a lot of hassle and last-minute worry on our part.
Here is the ICU for our Eco-Depot project over the last week:
As you can probably tell from it, we did most of our coding over the weekend. I think this is an indication of an increased workload for all of our classes as the semester ends. Personally, I simply didn't have the time to dedicate to the project until the weekend because of projects and a take-home midterm due throughout the week.
Our initial version of the code can be downloaded from Google Code here. Please refer to the Wiki page for additional information regarding the use of the product.
This time, we got assigned to groups of four for the assignment, generally with two pairs being put into one larger group. At first, it was pretty difficult for me to work with a larger group. One thing was definitely the fact that we did not meet face-to-face much, and were not consistent with virtual communication. As a result, we ended up with a few instances of group members not realizing that tasks had not been completed, or group members wondering exactly what they were supposed to do.
My main task for the development of the web application was to write the Java code for the main interaction with the WattDepot client. The hardest part of this was anticipating what would be necessary for the people who were mainly writing Wicket. To tackle this problem, I first tired to extend the command line interface that Kendyll and I had written last week, but found that I was second-guessing myself, especially when trying to add things to the Wicket application. As a result, I wrote several key methods, let my team members work on it, then looked to that for feedback on what else I needed to write. The biggest disconnect that I noticed was when they used arrays to handle working with data, while lists were the most convenient data structure for my end of the programming.
Overall, I think that although my group got the assigned task done, we could have worked better together. The main thing that I think we needed to do was to communicate better; Kendyll and I had a good system of relying on Google's chat to talk while we were programming, and we knew that we would check our e-mail multiple times a day, but this didn't seem to be the case for our other two group members. Getting things like this straightened out from the start probably would have saved a lot of hassle and last-minute worry on our part.
Here is the ICU for our Eco-Depot project over the last week:
As you can probably tell from it, we did most of our coding over the weekend. I think this is an indication of an increased workload for all of our classes as the semester ends. Personally, I simply didn't have the time to dedicate to the project until the weekend because of projects and a take-home midterm due throughout the week.
Our initial version of the code can be downloaded from Google Code here. Please refer to the Wiki page for additional information regarding the use of the product.
Monday, November 16, 2009
WattDepotCLI Version 2.0: A second look at the system
Over the past week, I have worked with my partner to implement a version 2.0 of the WattDepot CommandLineInterface that we have been working on for approximately three weeks. This process involved taking the comments from the code review completed a week ago, and incorporating the appropriate updates to the code, in addition to creating implementations for three additional methods.
The main comments from the code review basically said to just spend more time on the project to add more functionality, so this was one of my main focuses for the week. I implemented test cases for the commands that I had originally implemented, and I also split up all of the files into two separate packages, to separate the parsing of commands from the methods to carry out those processes. The test cases took some time, but I found that once I got the general structure of one completed that it wasn't as difficult to implement additional test cases for my methods after that. As for the reorganizing of files, I really took advantage of the Refactoring tool in Eclipse to make it a quick and painless process. Also, one item that we didn't get in our code review but that concerned us was the consistency of our code. We worked to refactor some methods so that the method signatures would have a similar style.
I did not regularly meet in person with Kendyll to work on the code since we both had busy weeks with our other coursework, but we kept in touch with each other regularly via e-mail and instant messaging. This worked well because we were able to work on our own time when we had the chance, but also always had an idea of what we were supposed to be working on at all times. We tried to partition the workload evenly, but found that at times we were setting it up where one person would work on the code for a while, make a commit, then let the other person work for a while, just because our schedules didn't allow for a more consistent division of work at all times.
As part of the adaptations we made for version 2.0, we also began using the Hackystat ProjectBrowser to monitor the "health" of our project using nine different key areas. The overall ICU for our project over the past week is:
For the most part, you can see a trend in increasing coverage and decreasing complexity, which are both signs of a healthy project. From this image, you can see that there is a clear increase in work done as time progressed, which occurred because both Kendyll and I were busy for most of the week and had to wait until the weekend to get work done, although we both tried to do some minor work on the system each day. Probably the only thing to really worry about from the ICU was the trend in coupling, which indicates that our files were becoming more tied together. I believe that the increase was caused by the fact that many classes either implement or extend other classes, and we could not get around this
I would like to address the "churn" factor, which looks ridiculous at first glance. The reason it is so high is that I did not refactor the system into different packages until yesterday. Thus, the system registered this as hundreds of lines of code being deleted and hundreds of lines of code being written in one commit, when it really only involved files being moved around. If you exclude this day
Finally, we were asked to use our system to generate the answers to several commands. Kendyll did this part, so please refer to his blog post for the full details. However, the answers were:
The main comments from the code review basically said to just spend more time on the project to add more functionality, so this was one of my main focuses for the week. I implemented test cases for the commands that I had originally implemented, and I also split up all of the files into two separate packages, to separate the parsing of commands from the methods to carry out those processes. The test cases took some time, but I found that once I got the general structure of one completed that it wasn't as difficult to implement additional test cases for my methods after that. As for the reorganizing of files, I really took advantage of the Refactoring tool in Eclipse to make it a quick and painless process. Also, one item that we didn't get in our code review but that concerned us was the consistency of our code. We worked to refactor some methods so that the method signatures would have a similar style.
I did not regularly meet in person with Kendyll to work on the code since we both had busy weeks with our other coursework, but we kept in touch with each other regularly via e-mail and instant messaging. This worked well because we were able to work on our own time when we had the chance, but also always had an idea of what we were supposed to be working on at all times. We tried to partition the workload evenly, but found that at times we were setting it up where one person would work on the code for a while, make a commit, then let the other person work for a while, just because our schedules didn't allow for a more consistent division of work at all times.
As part of the adaptations we made for version 2.0, we also began using the Hackystat ProjectBrowser to monitor the "health" of our project using nine different key areas. The overall ICU for our project over the past week is:
For the most part, you can see a trend in increasing coverage and decreasing complexity, which are both signs of a healthy project. From this image, you can see that there is a clear increase in work done as time progressed, which occurred because both Kendyll and I were busy for most of the week and had to wait until the weekend to get work done, although we both tried to do some minor work on the system each day. Probably the only thing to really worry about from the ICU was the trend in coupling, which indicates that our files were becoming more tied together. I believe that the increase was caused by the fact that many classes either implement or extend other classes, and we could not get around this
I would like to address the "churn" factor, which looks ridiculous at first glance. The reason it is so high is that I did not refactor the system into different packages until yesterday. Thus, the system registered this as hundreds of lines of code being deleted and hundreds of lines of code being written in one commit, when it really only involved files being moved around. If you exclude this day
Finally, we were asked to use our system to generate the answers to several commands. Kendyll did this part, so please refer to his blog post for the full details. However, the answers were:
- What day and time during the month was Oahu energy usage at its highest? How many MW was this?
>power generated SIM_OAHU_GRID timestamp 2009-11-26T20:00:00.00-10:00
4.96E8 - What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
> power generated SIM_OAHU_GRID timestamp 2009-11-28T02:45:00.000-10:00
9.95E2 - What day during the month did Oahu consume the most energy? How many MWh was this?
>powerstats generated SIM_OAHU_GRID day 2009-11-26 sampling-interval 60 statistic max
9.95E2
What day during the month did Oahu consume the least energy? How many MWh was this?
>powerstats generated SIM_OAHU_GRID day 2009-11-26 sampling-interval 60 statistic min
4.93E2
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
>total carbon generated SIM_OAHU_GRID day 2009-11-04 sampling-interval 60
29959 - What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
>total carbon generated SIM_OAHU_GRID day 2009-11-07 sampling-interval 60
22908
Wednesday, November 11, 2009
My Code Review Experience
My software engineering class implemented a code review over the past week, to help each of the pairs get feedback on our implementation of the WattDepot command line interface. A code review is a systematic examination of source code intended to find mistakes overlooked in the development phase; it improves both the overall quality of the code, and the skills of all developers involved in the review.
I was assigned to review two other systems. In doing this reviewing, I noticed several things that could be implemented or improved in my own system. For instance, I found a way to break one system (by putting in an incorrectly formatted timestamp), and I knew that the error was not caught in my own implementation. I also found more efficient ways to do things, such as creating a method to check that a timestamp was correctly created, since this is something that almost every method executing a command requires.
On the side of the coder whose system was reviewed, I received good feedback from all four of the reviewers. The basic message from all of them was that the code that was already written was good, with a few minor things to fix, and that mostly we needed to continue working on the code to implement test cases or to refine error messages. I also got some good feedback on errors that we need to catch because they currently cause the system to stop working properly.
Overall, this code review gave me a lot of ideas on things that we can improve in our system, and I think that we'll be doing a lot of improvement in the next five days before version 2.0 of our system is due.
I was assigned to review two other systems. In doing this reviewing, I noticed several things that could be implemented or improved in my own system. For instance, I found a way to break one system (by putting in an incorrectly formatted timestamp), and I knew that the error was not caught in my own implementation. I also found more efficient ways to do things, such as creating a method to check that a timestamp was correctly created, since this is something that almost every method executing a command requires.
On the side of the coder whose system was reviewed, I received good feedback from all four of the reviewers. The basic message from all of them was that the code that was already written was good, with a few minor things to fix, and that mostly we needed to continue working on the code to implement test cases or to refine error messages. I also got some good feedback on errors that we need to catch because they currently cause the system to stop working properly.
Overall, this code review gave me a lot of ideas on things that we can improve in our system, and I think that we'll be doing a lot of improvement in the next five days before version 2.0 of our system is due.
Saturday, November 7, 2009
Code Review of WattDepot-CLI Branches
After spending the first half of last week working hard to finish our version 1.0 of the WattDepot command line interface, my software engineering class took a break of sorts from straight programming to conduct a code review for our various branches of the code. We were each assigned two other implementations to review, meaning that each group would receive feedback from four or five other people. I was assigned to review the Elua and Eha branches of the project.
To conduct this review, each of us used the template that was provided by my teacher. Essentially, I went through the code, first ensuring that it compiled and passed the automated quality assurance tools and doing basic testing. After that, I looked through the JavaDocs for the code, as well as the code itself, to determine if there were any additional problems.
My full reviews for the two branches can be found here:
I will be giving a few of the main points for each branch here, but if you are interested in my full comments, please refer to the PDF files linked to above.
Elua branch
Overall, I found few major problems with this branch. All of the commands work, although some fine-tuning is in order to ensure that there are no problems with incorrect commands being accepted. I would say that the biggest area for improvement is in the JavaDocs, some of which are missing @param or @return tags, and all of which would feel vauge to a new user of the system. Testing of the branch was thorough, although it would be a good idea to test one or two of the cases in which errors occur, since this is the main reason for lack of coverage by the tests provided.
Eha branch
This system worked well, but I feel that there are two major points that would benefit from additional work before future versions are released. First of all, the organization of the classes and methods could use some work. As detailed in my comments, the UserCommandInterface class should be broken up into several new classes, based on the type of command being called. Second, the test cases could use improvement, as they check the handling of correct vs incorrect input, and not the actual information that is output by the system.
To conduct this review, each of us used the template that was provided by my teacher. Essentially, I went through the code, first ensuring that it compiled and passed the automated quality assurance tools and doing basic testing. After that, I looked through the JavaDocs for the code, as well as the code itself, to determine if there were any additional problems.
My full reviews for the two branches can be found here:
I will be giving a few of the main points for each branch here, but if you are interested in my full comments, please refer to the PDF files linked to above.
Elua branch
Overall, I found few major problems with this branch. All of the commands work, although some fine-tuning is in order to ensure that there are no problems with incorrect commands being accepted. I would say that the biggest area for improvement is in the JavaDocs, some of which are missing @param or @return tags, and all of which would feel vauge to a new user of the system. Testing of the branch was thorough, although it would be a good idea to test one or two of the cases in which errors occur, since this is the main reason for lack of coverage by the tests provided.
Eha branch
This system worked well, but I feel that there are two major points that would benefit from additional work before future versions are released. First of all, the organization of the classes and methods could use some work. As detailed in my comments, the UserCommandInterface class should be broken up into several new classes, based on the type of command being called. Second, the test cases could use improvement, as they check the handling of correct vs incorrect input, and not the actual information that is output by the system.
Subscribe to:
Posts (Atom)