Sprint to the Finish Line

We are currently in the final week of school and the projects and finals from other classes will start to pile up making it increasingly harder to find time to work on this project. Though we are no where near completion of all four of the meters/sensors in our original goal.

Within the last two weeks the groups have split into two forces, each working on their own meter. Edwin and Alan duoing the QuadLogic sensor and meter respectively, while Anthony and I start work on just the meter portion of the Shark meter.

When we were being briefed on the design of the project, we would always hear that after the first set of meters/sensors are done it will become quite easy to complete the other three, just find the registers and then change them. I though that it would be simple enough for sure, but I was wrong about that on so many levels.

When I opened up the PDF manuel for the Shark meter, I expected to find some table index of the registers that stored the data, but soon did a realize that it was far from it. To be able to program for a meter you must fully understand how they work and what you are looking for. I spent half an hour pursing for some kind of register values until I locked onto something about using modbus to program it, yet I could not make out a single work on what I had read.

Our inexperience with these meters have really put a road block into the development. I could clearly see the difference between those who have spent hours learning how to deal with these things as Alan and Edwin have churned out an almost fully function Meter/Sensor pair within the two weeks, where as Anthony and I have basically some research on the inner workings of the meter and a lot of prewritten code by Alan.

I still remain optimistic of course and I hope to be able to finish at least our meter maybe with the help of Alan to push us in the right direction. For the four milestone we plan to have maybe three of the four meters/sensor pairs working.

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.

The Sims: Dorm Energy

Before entering the hibernation mode that was spring break, we set forth a few goals for our new group. Split up into two groups, one working on the sensors (Edwin, Alan) and the other with getting some numbers that could mimic the energy usage patterns of the typical dorm students.

Two things I had though about for this energy. How much energy can a floor use, we need numbers that are close to what we would typically see in our real readings. So my first task was to take a look at some floor plans and make an educated guess...estimate on the max and minimum consumption of energy for a typical floor. The second thing was to look at the typical patterns of a college student.

The first step was simple enough I believe. With some help from a few assistants I found somewhere in my office, I was able to get an accurate floor plan. In conjunction I found floor plans of each dorm and mapped out typical items found in one room.

Not sure which dorm we are going to be installing the sensors in, I'll have to have one of my group members clarify, but for now we'll use this as a bases, The Hale Aloha towers. Though I have accurate floor plans for every dorm.

Never actually dorming myself, I had to look to others around me to assist. Lucky I had plenty of people who've had experiences in this area. One graduate student, a friend, has been in all of these dorms over the course of her experience here at Manoa, so I believe she is well equipped to explain the experiences of a college student. A typical room has a a fridge, extra lamps for lighting other than the one ~ three built in lights provided. Many students also brought in surge protectors to expand the measly 2x2 outlets(2 outlets on each side of the room) they were given. Then there are the quad rooms, but thats another story.

I took on interviewing a few people already in hopes that I might better understand how a college dorming student lives so I can understand and predict when energy usage would be at its highs and lows. One interesting thing that I discussed with a few students is the question of weekend energy usage, because I don't dorm my energy usage usually spikes during the weekend, but this is probably because I stay in much of the time. I generalized that the same thing would happen during the weekends at the dorms, but I was quickly put in place by the more experienced dormers. They had explained to me that many students that live on the islands or even neighboring islands would often go home to their families on weekends (especially 3 day weekends for those in the neighboring islands). Other students were also very active opting to go out, these would offset the energy from the lack of classes and the time spent studying or completing assignments from students who would spend more time inside their dorms.

Together with these people, I've somewhat mapped out a trend that I would like to model our data after. Hopefully when we plug in a real monitor and get the apps hooked up to it, even if the watt data is off hopefully the trend lines will be spot on.

In other news, our sensors and monitors and now both working, all that is left is simulated test data to try and if first tests look good, we may be on our way to having all four types of meters working soon.

Watts For Sensors: New Beginnings

Last week we saw the conclusion of the Wattdepot-Apps group, our two month going project. This week I pick up a new group that has already begun development of their project, so I will be as they say hitting the ground running.

My new group for this next milestone will be the Dorm Energy Simulation group. Our task is to develop a simulated energy program that will send simulation data into the actual Wattdepot servers we were working with.

We haven't had much time to meet or discuss our plans which we will hopefully get together by our first meeting this week, but so far from what I've heard, our two goals right now is to get a working conversion from the data of the meters into actual data that the Wattdepot servers use. The next goal is the actual simulated data in which we are currently doing research on appliances and other items found in dorms that we can base our simulated data on. Once this research is completed we can plug in actual numbers and get this data written into wattdepot to be visualized and queried by all sorts of applications.

Not much else to report this week as I'm still getting my sea legs. This is always a problem that I believe anyone would encounter when joining an existing project. Half the members in our group were already working on this project when I had joined, they will be the more productive members until the rest of us can get it together. In the mean time I hope they continue to be supportive and take lead in the project to direct us new members until we can be a fully functional part of the team.

Wattdepot v.2: Overcoming Challenges

It is now almost four O'clock in the morning and I am still waiting in front of my computer half asleep. Trouble seems to strike at the most inconvenient time these days, but I guess anytime trouble hits it becomes an inconvenient time.

Its been a little over two hours since my internet cut out on me, disconnected from my group and unable to contribute anymore progress into the overall system. Lets recap this previous week and hopefully by the end of this textedit post the internet will be back up.

This project is finally coming to an end. We started off with 3 applications in mind, we've only seen the completion of 2. Not the best, but considering the amount of time spent in refining the other applications we've accomplished plenty in the two months we were given.

This past week we've been scrambling quite a bit, what should have been a week to do finishing touches on our public release of the Monitor application and the next version of the Visualization application met with some road blocks.

In our last weekly meeting we were given comments on a code review that Professor Johnson did… and it was a disaster. There were many comments that issues presented in the meeting that really opened our eyes to the messy code that we have presented.

The first issue was our previous wiki pages. We had slapped together wikis as a placeholder using base from our previous coding assignments. I had use my groups Developers Guide from a previous semester and I had thought all the references to to old project was removed, but Professor Johnson managed to find some. I had forgotten to remove all the links that lead back to the wrong project page.

This week we've had a complete overhaul on the wikis based on the suggestions by Robert and Professor Johnson. It should now be comprehensive and informative enough for both users and developers each on their on level.

The second issue discussed was a package we were using in our code. This semester isn't the first time we are working with Wattdepot. In a previous semester we had written a command line interface for users to quickly query some data based on preset commands. When we first started our project we had though this old code would be useful and save time, so we reused it turning it into a "Command" package. Turns out that instead of directly accessing Wattdepot with all the nice methods presented to us by Robert, we were using this faux command line on top of it and having to do all this extra work before we actually did any calls. This was very inefficient and from a outside developer's standpoint almost impossible to understand.

This week, we did a total overhaul and re-factored the code. We looked at the command methods took what we needed and scarped the rest. Now completely gone is the Command package, each application now only uses what it needs to rather than importing the entire package.

Other than the code clean up, comments, and documentation for the release, we were able to squeeze in some extra enhancements to the Monitor application.

Last week I talked about going portable, so we've added in a proof of concept parameterized link for users to send to others.

Although there are issues with it that I would like to see get fixed in the future, it is a very neat feature to have and I believe it will be useful to users.

Wattdepot Portable: Rounding 3rd!

Another week and a step closer to our second milestone. We are currently in the third week of milestone two. With one more week to go, just how close are we to completion?

This past week has seen some work from each member of the team. At last week's meeting, it has been decided that we are close to the completion of the project. The only thing left on the visualizer is a small issue with loading and column naming issues, along with testing. For the monitor page, we needed to have some error checking and do dynamic type conversions.

One great enhancement that will be useful for both applications is portability. We would like to make the urls portable by allowing users to share urls that pass parameters into the pages. Since this deals with both the monitor page is the visualizer page, as the middle man between both projects, I was assigned this task.

So far its been difficult. I do have portable urls working and the parameters being passed. Below we take a look at the new Urls being use for the applications.

Old Url: Very ugly, What the heck is "wicket:interface=:0:"?

• http://localhost:8003/wattdepotapps/home?wicket:interface=:0:MonitorPageButton::ILinkListener::

New Url: Nice url, 1.1 does represent the pageID, hoping to get rid of it in a future release.

• http://localhost:8003/wattdepotapps/monitor.1.1

Portable Url: All parameters passed using slashes in url encoding.

• http://localhost:8003/wattdepotapps/monitor/Source/SIM_AES/Type/Power%20Consumed/Interval/5%20sec

One problem I am currently running into is finding a way for the url to update without having the page refresh. Since the monitor does do a query or "monitor" in its case on load, I cannot just send all the parameters to a new page for the url and have it start. It is however possible for the visualizer which loads on start so I can apply my current code to the visualizer.

Hopefully I will run across a fix for this, or someone from the wicket mailing list will have an idea. For far no luck, but hopefully we will have a fix within the next week.

One last issue for the overall system is to have a dynamic host uri and port number arguments. This will be helpful because Robert wants to install a second Wattdepot server and using this command argument in the cli, we will be able to have both servers running. This does not seem too hard so it has been set to low priority, it is also there since we have nothing to test it with until Robert add this second server.

It has been recently decided that since we are approaching our next milestone and only two out of the three applications will be ready by then, it is a waste of resources of three people to be working on just the Browser application in the third milestone, so most likely we will be parting ways or if we share similar interests, we will be switching to new projects.

There are already a list of projects to choose from and many do look interesting, hopefully we are able to complete the two required applications we do have left to its fullest before we take our next step.

Wattdepot Monitor:1..2..3..4..5..Change!

Today marks the second week of the second milestone.

After a brief meeting last week, since we didn't have as much to show, we were sent on our way to continue work on our project.

Our current checklist of to do items stands as:

TO DO

• Visualizer multi-select of sources
• Small layout changes
• Monitor base functionality

Our current progress stands with all of the above items completed. A successful week as I would say.

This week I focused mostly on helping the Monitor team. The base page and drop down was up, so what we needed to complete from last week was to link the page to the Wattdepot servers and display the data. Ed was able to link up to Wattdepot and grab all the data. For man job I was assigned to format the returned data for display. It was initially thought of as a simple job, but the task was slightly more complicated with both of the time values displayed being in a different format. I had to break each one down and rebuild them into something usable for display.

There were two problems that we ran into. The first being a thread issue in which caused what seemed to be a double update whenever we hit the interval. This issue took a somewhat large chunk of time from both Ed and I, and Ed was finally able to resolve it through a time comparison. The second issue which is similar to the first issue is a delay in update, this issue is going to be mark as such because at the current moment we are unsure how to approach it. The issue is caused by a delay from the Wattdepot server when we request data from large sources. Most of the time we have a small 1 second delay for the initial connection and then it runs fine, but in the case with a large source, in our case SIM_OAHU_GRID, the delay time is as much as 10 seconds added to our interval sleep time, so at minimum it was updating everything 15 seconds even when set to 5 second intervals. We've talked to Robert about this issue and he has recommended a fix, but it requires us to update in advance for compensate for each source's delay.

On the visualizer side, we are finally complete with all functionality working. Hopefully this will be or somewhat final release version. There might be small layout issues that need fixing but all functionality is currently working.

On current plans for this coming week is up in the air. Since we might be finishing up with the Visualizer project, we will either be working on enhancements for the monitor or continuing on with the browser project we had put on hold for the monitor. It will play out depending on our weekly meeting.

Here's hoping a finalized visualizer!

Milestone Two Goals Set! Engage~

We are now in the second milestone of our project. With new goals and priorities set we are ready to engage in phase two of our Wattdepot-apps project... after a short intermission.

This past week has been a very busy and eventful week. After reaching our first milestone last week Tuesday, we have come up with some new goals for this next milestone.

During our regularly scheduled meeting with Professor Johnson we have discussed some new enhancements for our visualizer project which is now out in its public release of version 1.0, but he rejected our layout for a more simple layout. We also discussed our new subproject priorities which has had wattdepot-monitor moving up to the top of the list. In the meeting we also discussed about splitting off into two teams, one leading the development of the monitor, while the other completes the enhancements to the layout and our final requested feature for our visualizer. With only three members on our team we decided to split it evenly with one and a half members on each project. With the group indecisive about the middle man, I've volunteer to work with both projects. Although at this point I do not know if I can be a fully functioning member of the team or become a assistant to the dedicated members.

This week also brought about the harsh reality of life and school into our overall goals, the group is hitting some major midterm road blocks in the past and upcoming weeks. Although I do expect the new split in the project to get off to a somewhat slow start. The two(three) holiday weekend, with Valentines Day, Chinese New Years, and Presidents Day, coupled with the busy schedules of each of the projects members have cause the project to lag behind a little.

Currently we have completed a new layout for our visualizer page, although a weird problem in which our html/javascript formatting(mainly the spacing) cause quite a few hours of headaches, we finally resolved most of our issues and have started to focus on the final two enhancements on the visualizer page.

On the other project we have completed a base page for the monitor. Although not functional yet, the foundations for the drop-down menus and the selection in all there. We hope to see a functional application by the next meeting.

Checkpoint Reached: Milestone Pitstop

Its been four weeks since we started the Wattdepot apps project and we are now entering the first of our monthly milestones. At the end of each milestone the groups will present on their progress and it is decided of the project is completed or will be continued.

So the first deadline of February 9th approaches and there have been major modifications to our original plans.

When we first started the project, I felt that we would have all three items : the visualizer, browser, and monitor; completed by the time the milestone came, but this is not the case. Within the first week of our project we were able to get the basic visualizer up and I thought that although with some minor adjustments we were done with it, but that project ended up evolving the encompass the entirety of the milestone.

We are very far from our original basic visualizer and the current version. There are many enhancements and this is the one thing that is "almost" complete, there are a few issues that we will be updating in the future, while all the other projects were pushed back to future mile stones.

I have come to realize now that this one project that are currently one, to refine it to a professional quality may be at least one or two more milestones, but that may have been the original intention.

In the last week we have made many strides since our previous meeting. Not only was it a busy school week for the group members but it was also a super bowl weekend, much which have hindered some of our work time, but we managed to pull through with a decent amount of effort and work put into polishing up the "almost" final version of the visualizer.

While the others worked on refining the code and adding last minute touches, and added in the error checking to prevent and warn users when they are using the product incorrectly. I've also allowed users to query both types of data (calculated and sensor) in this new version. As a group we were able to implement a cancel button to allow users to cancel queries if they wished to. Other than those two big changes most of the time was used to polish up the remainder of the code and get the documentation and wikiPages ready for a distribution onto the public servers.

The one item that we were not able to implement was allow the comparison between multiple sources on the same graph or allow users to view sub-sources of a large source. We hope to be able to complete these features in the future, but for now in the upcoming milestone, I believe we plan to focus our attention on completing the next piece of our three planned applications for wattdepot, the browser. We already have a base page up and it is half working, so we hope to be able to complete it within the week and use the remaining time refining and making enhancements like we've done in the previous milestone.

As far as group work is going, for the most part it has been going smoothly, each member is contributing to the overall goal, although there are still those times were we get into disagreements. We have no plans to split up and work on a different project for the next milestone so hopefully it will go as planned.

One down, three to go!

Three Weeks Down! One to Go! Scramble For The FInish Line!

We are now entering the fourth week of school and the third week of out first project, Wattdepot-Apps. Its been a bumpy trip, but an overall good experience.

Continuing on from last weeks post, we are still currently working on the first two parts of our three part design, the visualizer and the browser page.

In the previous week, the entire team was busy with other classes taking up their time, and two out of the three of use were unavailable during the entire weekend. This delayed the progress of the overall project a little bit, but I believe we were able to churn out a decent amount of enhancements.

The first new thing that we've added to the project is the base page for the WattDepot browser. Ed, our wicket hero has put up the base layout and the ball is now in Kendyll's court to implement the call for the source summaries. We are currently hitting some snags at this point in the browser development as we haven't yet completed the basic functionality of the page for public users. We hope to have this resolved as soon as Wednesday.

Last week Ed and I had finished completing the base page for the visualization and implementing the basic functionality, Ed working most of the wicket and the page layout, and I doing most of the javascript. Since Ed and I were busy during the weekend, we handed the visualization to Kendyll who converted the annotated time line we used into tabular form. To further add upon this we implemented many suggestions that arose during our weekly meetings with Professor Johnson. One of the things we have progressed on so far is having combination box selection for items. Although only the datatypes are currently functional with multiple selection.

Ed and I have also been able to resolve the problem of granularity of the sampling intervals. The problem arose last week when we noticed that when sampling the smallest time frame (during that implementation), one day, it would take well over five minutes and counting and even possibly time out one the data query, when the sampling interval was set to lower than 10~ minutes. We discussed our plan of action with Robert and Johnson at the meeting and we came to the conclusion that we would keep the small interval, but allow the user to choose a smaller time period such as one hour~. So, yesterday morning, Ed had added in time picker drop downs for us to use, and I was able to link them into the timestamp generation functions. We are now able to pick right down to the minute. (Although it is unwise to choose 1 min)

Overall, we are still on track to completing on time, although we have fallen behind a slight bit. We hope to be able to resolve the issues we are facing and plan to switch our focus on the problems with the browser ahead. We can delay enhancements on the visualization in order to have complete functionality of the other two items, but as it stands, we are still waiting on user data for the browser and real time updates from wattdepot, but that area is still waiting confirmation from Robert.

Checkpoint Reached: Wattdepot Apps At A Glance

It has been about a week since we have got started with our Wattdepot Apps project, so I'm here to report on our current progress.

The team has reached its first checkpoint and we have completed a functional Visualization! We have two checkpoints left including the Wattdepot browser and Realtime updates.

This first week had everyone planning a lot. We meet with Robert Brewer on two separate occasions for questions and we had our first meeting with Professor Johnson. We laid out a plan last week and have discussed the idea of introducing various ideas into future versions of the visualizer, such as user defined annotations to our visualization timeline and support for multiple selections.

After the initial planning stages, we separated the work load into three separate components. The wicket, the javascript and annotated timeline visualization, and the table visualization. Our group member Ed was quick to jump on the task and had completed the basic layout of the applications and included all the required drop down and wicket for user selection. Although I didn't have much time during the week to look at our project, I was able to free up my schedule over the weekend and have churned out the completed javascript within the html files and we now have a fully functional although basic annotated timeline visualization. We are currently waiting for Kendyll to add in the ability to choose between the timeline or a quick table format to view the data.

So what items are left on the list? We have the Wattdepot Browser and the Realtime updates. Since The third time cannot be worked on until Robert can update wattdepot to support this push of data will have decided to split up the work into two parts for the coming week. We will be working on enhancements for the visualization app to add more functionality to it and simplify the look. We will also be planning out the basic layout for the Browser. Our plans are to hopefully have both the Browser and the Visualizations working by next week, then work on enhancing the product until we can move onto the final leg before our February 9th milestone.

New Semester, New Beginnings, Same Old Wattdepot

After an uneventful holiday break, we are back to work in the new semester. This semester in software engineering we will be tackling the topic of energy and sustainability.

In our initial week we were debriefed on the our overall goals by Professor Philip Johnson, and then assigned sub-project teams.

The first subproject I will be working on for the first checkpoint is Wattdepot Apps. This is basically taking what we had been working on last semester and applying it into individual standalone distributable applications for wattdepot users.

On this project, I am joined by a former group member from our Greenometer wicket application from last semester Edward Meyer and classmate Kendyll Doi. We are also fortunate enough to have Robert Brew, the man behind wattdepot, on our team.

Together we are tasked with creating three main applications for the initial wattdepot apps. A standalone visualization using Google Visualization, a Wattdepot browser that will be similar to a GUI version of the Wattdepot CLI from the previous semester, and a Wattdepot monitor that will be bring us real time updates.

In our initial meeting, we met with Robert to discuss some of the requirements for the current sub-project. We will be putting the third part of the project on hold until Robert can get Wattdepot to allow pushing of data for the updates. Meanwhile the remaining three of us will be collaborating to complete the first two parts of the project by the time robert can update wattdepot for real time date updates.

We currently have our google-project page set up and have assigned issues to be worked on by the group members. We have started looking as ways into which we can implement the first part of the project, the google visualizations. One current problem we have come across is that one of the reference projects from last semester "Carbonometer", which used google visualizations, is currently not working. We are inquiring the group as to if it was a problem on their side or our side and we hope to get it resolved as soon as possible.

As for this coming week, we have a tentative schedule to get the basic visualizations working by the end of the week.