Final Lap

We are on the verge of the end. With about two weeks left we head into the end of this semester long software engineering project.

I'm still working diligently to churn out a few more meter/sensor pairs for possible meters we will be using for next semester.

Last week we had a major problem with the sensors not creating the property files needed to connect to the wattdepot servers. We soon discovered that we needed a folder that was created by the code, but it was never made only checked if it existed and then anyone without the folder would be unable to run the sensors. We have now resolved this issue but it requires further testing done by all members of the group. As it has shown in the past, just because one member confirms a piece of code running, the different configurations between different computers could cause problems.

Other than this issue, the meter code is just about finalized. We have decided to continue working on new meters with current progress being made on two meters, QuadLogic and Shark. We will continue to accept the energy generated as kWhr until we can get a confirmation and decision for wattdepot, which is currently taking energy as Whr.

With the unification and regular meeting and emails from the groups at this point, we will try our best to complete as many possible meter/sensor configuration for possible meters. With the time ticking down we will be scrambling throughout the remaining week.

A Rocky Road Turned Hazardous

These recent blog posts seem to me nothing more of a rant about the problems faced during this current project. I believe it to be very much about problems face, but it can also be about how we've meet with the problems and resolved their issues. But the fact is every time resolve a problem, it just seems to lead into another problem. I truly am starting to wonder when the last of the problems will be resolved.

I was finally able to get the build system working just before the milestone last week, but to my surprise when I had run verify, I was slammed in the fact with countless errors. Not only was the code that my group members working on filled with checkstyle errors, but some of it also contained PMD and Findbug errors. With so little time left until the mile stone, we were only able to do so much, and the fact that our coding style was sloppy was made very clear.

To that we have overcome. With everyone now under one subversion folder we were able to quickly share code that was needed to fix some of the problems. The team worked very diligently to clear up over 100 checkstyle errors that had occurred, many of them occurring from code that was unneeded because it was imported from a package.

With the errors gone we were just tasked with one thing left. Running a complete build system for a new developer. It was my first time working with ant really. Although I had used ant before, I had only been using the predefined build system given to us, but for the next step to progress I would have to start modifying and building my own build files. To this I have almost succeeded. In our current project we have two sub projects that needed to be ran separately. To do so it was almost impossible to use the pre-exsisting build commons we had utilized which were wrapped up in a single project. I separated the two projects each with their two targeted build commons. We can now run the projects and build them separately under one unified project folder that will do the consistency checks for the whole.

So close yet, for every problem we fix, there is always another problem that arises. The current issue this week will be to be able to test the project. For some reason, the sensor portion of the project is only able to run under Edwin's computer. So far Alan and I have tried unsuccessfully to run both my build of the project and the old build (confirmed to be working) by Edwin, but to no success. The problem is a missing property file that should be created on start, whether or not this file is created by you or automatically by the code is another thing. I have traced the code to which I believe it is the source of the problem, but it appears that this portion of code is working under Edwin but no one else. Good that it works, but bad that no one can confirm it other than Edwin.

Chaining Together Troubles: Milestone 3

Group projects are always either a hit or a miss. It doesn't matter if the end project doesn't exactly meet specifications, the goal of a group assignment, in my opinion, is the successful process of collaboration between the group the accomplish a goal. In this sense many group projects in sink or swim depending on whether the group is able to come together and harmonize or not.

So rounding the third mile stone of our software engineering project, where does my group stand?

As I see it was are barely limping towards that finish line, much of these injuries sustained during the process of familiarize ourselves with each others work habits.

At the beginning of the semester, the group formation process was much easier. We were able to essentially choose our group, picking people that we've worked before and are confortable with. This made the first two mile stones pretty easy, as being grouped with Ed Meyer and Kendyll Doi, worked out well for me since I've worked extensivly before and I have easy access to commincations with them. We were able to immediately become productive within the first week.

This however, for our third mile stone, was completely different. Having ending our previous Wattdepot-Apps project, we were put into new groups. Although I've interacted with Edwin, Alan, and Anthony before in other classes during our days on ICS students, I had never actually work extensively with any of them on a project, let alone anything other than a quick shot answer worksheet. Overcoming his hurdle was actually the hardest part for me in the entire month.

The group dynamic did not work as well as my previous group. We had trouble communicating with eachother. There was the occasional email and a brief 5-10 minute group meeting every Monday/Wednesday for a status report on the project. Although this could have possibly worked on my previous project, there was another factor that prevented the fluency of the group dynamic.

The chain of sub-projects that was our code. It was like a giant three piece cog that would only move if all the pieces fit. The project as a whole was subdivided into three parts. Alan was creating the code for the actual meters themselves using Jamod, Edwin was creating the code for the meter sensors that would retrieve data from the meters and write them into the Wattdepot servers where they could be read by applications such as the Wattdepot-Apps. These two items were the basis the the entire meter to wattdepot system. Since we have not finalized a meter yet we do not have any actual meters to read data with, which is where Anthony and I come in. We were tasked with creating a simulation system for the dorms, in which would give simulated numbers and feed them into Alan's meter to be sent to Edwin's sensors then to Wattdepot.

Kind of simple enough I though at first, since Edwin and Alan had been working on this project for quite sometime they were at the verge of completing their sensor and meter respectively, with only a few technical glitches standing in the way. Because of this separation of groups, there was no unity in the entire project. I was hard to test if my simulated data could be read with the meter and then sensor because with only one person on one sub-project for so long, there was no real need to them to have it under version control. Then when Anthony and I joined the group, it was still a very hard process for them to continue to commit to version control until we had a wake up call the week before this mile stone. While working and testing on our part of the code, since our code is directly related to Alan's, if Alan continued to work on his, we could never be sure if they were compatible, and that had actually happened on several occasions were our code would work, but then later on we find out that Alan had made an update to how his meter retrieves data. It was brought to our attention that our style of cooperation was very unprofessional.

This week we hope to change that. With most of our code working individually, we have to connect them properly and find all the hing for the oils to make it run smoothly. My previous group worked very well with everything on version control and our automated build system quickly alerted us to breaks in the code. Working with Edwin who seemed to be almost on the ball with this, we gathered everyone's code and then was able to get everything up on subversion. I took a loot at the ant manual to get a working build system running. I now have a successful build system, although previous bad coding practices have led to numerous checkstyles and some pmd errors, which will need fixing before I can put the project on Hudson.

Rounding Third: Union of the Pieces

I've been worried for quite a while on the current state of this new project I'm working on. With my original project, the Wattdepot-Apps, ending I quickly jumped into a new, already existing, group for the next leg of the semester. This had brought with it many problems related to time constraints and the integration of the new members of the group.

I must admit that we are working together a lot more. We do regular speak to each other and talk about the current status of the project. It is very different from my previous group, as we were always working close with each other, every part of an application was a team effort, but at this point the group is not as cohesive. In other words, we are like two separate groups. Edwin and Alan are putting together the code for the meters, while Anthony and I work on getting a Simulation of data that we will be using. We are all over the place so much that a lot of times, I have no idea what Alan and Edwin have done so far, and only am I updated the next time we meet. I also cannot add any code into subversion because I had been given old code that was working and the status of their projects have progressed too far off from the old one. Although it shouldn't be a problem as my part of this project is not reliant on that of the others, at the end what we hope to accomplish is to connect everything together and pray that it works.

For this week, I've generated some estimated numbers based on my interviews with dorm students from the previous week, in conjunction with some research on the power usage of common dorm items. We created some spreadsheets to look at the graphs generated to make sure it shows a good and probably distribution of energy usage throughout the day.

Left is the weekdays % of the total max estimated usage of 26.5 Kw, right is the weekend estimated values. The graphs are on the same scale, but my screen shot alignments need some work.

We then modified in existing methods of the basic (random) class they were using to allow easy configuration with our simulated data which could be changed at any time. We did this by creating an abstract class, which is very similar to using an interface. I added in abstract methods to which the classes use, so now by can use generic "Data" objects that can switch from giving random numbers from the basic or using our Simulated (pre-defined) numbers that model our graph.

I hear on the other end that Edwin and Alan are inches away from getting their meter code it work the way we want it to. So far on my end it looks like we are wrapping up the simulated data and will be look forward to connecting everything together into a final product for presentation.