Let Me Just Write That Into My Schedule ... Not

I knew when I was assigned the task to develop a schedule for our project it wouldn't be easy. I just didn't have any idea how not easy it would be. I'll review a few of the decisions that we made regarding how schedules will be implemented in our project.

1. Lights, Rooms, and Houses will have schedules. This is opposed to a system where a schedule would be in charge of managing all of the parts of a house. If a schedule were to be in charge of managing the house, it would simplify things because all of the schedule information would be located in one place. On the other hand, Lights, Rooms, and Houses each having their own schedule feels like a better reflection of how the world works. I like to think that I have my own personal schedule that I choose to follow in going to classes and appointments, rather than my schedule ruling over me and dictating what I must do.

2. Triggered events are represented by a start time AND an end time. This decision was primarily made based upon how we plan to implement checking whether or not the light should be on a schedule. The plan is to examine the current time and the light's schedule, and if the current time indicates that the light is scheduled to be in a certain state, then the light will be switched to that state. Then if a user changes the state of the light from its scheduled state, a variable will be set indicating that the light is intended to be in the state that it is, rather than its scheduled state. Once the end time has been reached, this "override" switch can be reset to off so that the schedule will work as planned in the future.

In an ideal world, we would like the database to push information regarding whether the lights should be on or off to the client rather than having the client constantly fetch what state the lights are in on the database. For this reason, our decisions on how to implement the schedule may change in the future. 

Standing Meeting 5: Report from the First Split

This week was the first time that our team tried assigning specific tasks to specific people, let's see how we did.

• Arik:
• Make the website look pretty. All that we have so far is black text displayed on a white background. Arik plans on looking into how Twitter Bootstrap can be integrated into Django.
• Zach:
• Complete tests to simulate Amber's success story. This will be accomplished by checking to make sure the views that are returned are the correct views for a logged in user.
• Karl: 
• Re-organize code so that authentication files are contained in one location. Implement the Light model to the project.
• Entire Group:
• Write tests for the basic model structure that will be implemented for this week.
• Further solidify the UML diagram for the project.

Arik's success of integrating twitter bootstrap into our project is a huge confidence boost. It makes our website look like it wasn't built by a fourth grader. Check out our new homepage!

Zach made significant progress towards attaining his goal, but difficulties with the svn repository due to power outages prevented him from being able to complete his goal for the week. 

Karl successfully reorganized the authentication files after quite a bit of difficulty regarding URLs and templates. A light model has been successfully added so that an administrator can add lights to a specific user.

Our lack of tests added for the models to be implemented is due in part to our unfamiliarity with the test first coding practice and also in part due to ambiguous UML diagrams. Since we aren't familiar with how to write tests and exactly what tests to write, it is difficult to complete the task.

There really isn't much excuse for the lack of a further solidified UML, this will be our first priority for next week, hopefully allowing other pieces of the project to be more easily understood and implemented.

These are our goals for next week (or whenever, since we will be going on Spring Break next week):

• Arik:
• Continue to update new pages which we develop to be wrapped in the beautiful environment that is twitter bootstrap.
• Develop the House model for the management app.
• Implement tests for the house model.
• Adding a house to the database.
• Adding a room to the house.
• Removing a room from the house.
• Accessing a house by the user.
• Zach
• Complete tests to simulate Amber's success story. This will be accomplished by checking to make sure the views that are returned are the correct views for a logged in user.
• Develop the Room model for the management app.
• Implement tests for the room model.
• Adding a room to the database.
• Adding a light to a room.
• Removing a light from the room.
• Karl
• Solidify the UML diagrams for the project. Make these in the Violet UML editor.
• Provide users with a view to see what lights are in their house, not necessarily organized by house or room.
• Allow users to change the state of a light.
• Whole group
• Start programming on the Pis, install all necessary software on the devices so that they can function as our "houses".
• Implement Napoleon's success story.

Napoleon is a registered user of the project HAM website. He wants to see how many lights are currently on in his house. He logs into the website and is immediately greeted by a display which indicates how many lights are controlled by the system in his house and whether those lights are off or on.