|
|
|
|
Final journal
1. Name
|
| | Christopher Alme |
| | | 1 (25%) | |
|
|
| | Dennis Qian |
| | | 1 (25%) | |
|
|
| | Stanley Roberts |
| | | 1 (25%) | |
|
|
| | Christopher Nunu |
| | | 1 (25%) | |
|
|
Total: 4 |
2. Milestone Status: Gains made (If possible, include hyperlinks to what you mention here.)
|
| | Since the last journal, I've reworked the entire feature extractor architecture to accept a list of rules. This makes the rules less hard wried to their inputs and more extensible. An individual feature extractor module can now have multiple rules plugged into it so different features can be computed on a stream and forwarded to different sources. The other big gains I have made or interacting with the control processor and user panel for the creation of new feature extractors. We've created serializeable object messages that allow us to easily communicate data structures as messages. The feature extractor can now take in create feature extractor messages and add edge messages and it is completely integrated with the database.
Stanley created a simple serializable object table that allows things to be easily searched on guids. With this and our new messaging system, it is easy to code up data structures to communicate between modules. He has also worked on making the mixer module. He has functions and a synchronization method created. Nunu has started looking at how they will be configured and how the user panel and control process will communicate their creation.
Dennis has been working on the user panel and sending create messages through the cp to the network. He has also come a long way on making an intuitive UI for lambda creation. |
| | | 1 (25%) | |
|
|
| | Doing this last journal a little bit late, but got a lot to report in terms of progress.
UI
The UI is about 75% done with a few missing model components that allow for feature rule mapping. I've moved parts of the model for the UI to the control processor in the cloud actually. This way the UI can reconnect and disconnect and still have all the information.
Streams
Alme is picking up streams again after being unable to construct a network to test our 'cloud death bug'. He's proposed and implemented a few streams including a weather stream, twitter stream, and our generic mouse and wiimote streams.
Mixer
Stanley did great work on getting the guts of the Mixer fleshed and tested. The mixer currently does synchronization and has config objects to configure itself for dynamic remodeling and connections. There's still a little patching up to do in the Mixer but its mostly there.
View Adapter
The view adapter is pretty much done and just ready to be configured for a network.
This weekend, Nunu and I spent a LOT of time debugging ridiculous bugs in the cloud. I'll go into detail about those bugs below. In the meantime, Stanley has begun implementing network creation logic and Alme has been partially working on streams while trying to get some mock streaming done in the cloud. |
| | | 1 (25%) | |
|
|
| | Oh god, oh god…
Where to begin, so many changes. Mixer Module. So I created a Mixer module that is able to receive connections, sync messages and process results. This included creating a messaging scheme for setting up a mixer. I had help from Nunu to implement the MixerRole. I started creating the built in functions that the Mixer module can apply. So far I have written arithmetic and Boolean operations.
The state repository. I have created many tables to handle the setting up of roles across the cloud. There are revamp tables for basically all roles.
Communication Messages, I have created the objects that are used as communication between the CP and basically all role. These messages include starting modules, adding connections, stopping modules.
I have also done work in getting the Stream Manager and the GUI working. This was basically debugging the control flow.
|
| | | 1 (25%) | |
|
|
| | Last Journal!
Things I've accomplished thus far:
- Completed the Mixer Role minus CP communications which Stanley finished.
- Updated the Display object so that Dennis can use dictionary lookups on commands in the User Panel to populate his UI
- Stanley wrote up the CP communication objects to the VA which I then implemented, so the CP can talk in a structured manner to the VA
- As a class, we (read: Joan Chao) designed the poster for our presentation. Working on getting it printed (see next section)
- With Alme, designed an edges table the CP can use to map connections to modules in managed by the various roles.
Things left to do for me:
- Implement some other displays to be used in the demo. (Vague I know, but I have to sit with Alme tomorrow to go over what he actually wants me to do in detail)
- Testing testing testing!
|
| | | 1 (25%) | |
|
|
Total: 4 |
3. Milestone Status: Obstacles Encountered
|
| | When we retooled the system, we took out a lot of the hacks that allowed data to be easily set up and streamed through. As a result, we I have been unable to replicate a bug that causes the feature extractor to die when data is being streamed. I'm about to try to get a stream sending mouse positions to a feature extractor who will send them to a view adapter who will do nothing with them. Hopefully this will allow me to replicate the bug and look into it further. |
| | | 1 (25%) | |
|
|
| | Mixer vagueness not really
Network creation logic hole
bug 1 - missing messages
bug 2 - unable to reconnect up
|
| | | 1 (25%) | |
|
|
| | Time is working against us. Fortunately I have very little work remaining in other classes, so I can devote almost my entire attention to this project from now until our presentation.
Debugging is becoming an issue. Parts of the cloud system do not have easy ways to debug. Recreating a bug often requires many different and time consuming steps. Individual pieces of the project are too closely tied to each other, which is killing us in testing.
|
| | | 1 (25%) | |
|
|
| | There's a hack in the network layer that escaped our notice until now where AConnection guids are not symmetric across a connection. This causes problems when a Role tries to make a new connection somewhere and then add that connection object to the correct module that it manages. I know where the bug is though and how to fix it fortunately. It's going to take a little time, I would venture a guess of two hours worth of work to get it done and tested for correctness (you know what's awesome? I can actually say that now without any BS!)
One other problem we've encountered is that our credentials are not accepted by whatever system OEDK uses to do printing. We keep getting authorization denied errors. This has meant we've been unable to actually print a draft of the poster to verify if it's acceptable (legibility, size, etc...) |
| | | 1 (25%) | |
|
|
Total: 4 |
4. Milestone Status: Proposed Solutions
|
| | The view adapter creation and display configurations should be getting wrapped up tomorrow. We should be able to create a simple dummy setup of the network and deploy to the cloud and hopefully replicate the bug. Beacuse this is so time consuming, I'm going to make sure I have plenty of small stream tasks to look into and understand so when it comes down to crunch time, I'll have the knowledge to easily throw together streams and feature extractors for those streams. |
| | | 1 (25%) | |
|
|
| | base case for network logic
fix for bug 1
fix for bug 2
|
| | | 1 (25%) | |
|
|
| | Time: I checked ebay. We can get a DeLorean for under $20k. Dr. Wong, make it happen!
Debugging: We need to create a strategy to better test modules. I have set up dummy network connections for testing the mixer module, but the role on the cloud is much harder to test. Given the time constraints, this is killing us. We don’t really have time to change the architecture to better handle testing. On the other hand, debugging is too difficult. So, change some, deal with some is the strategy we are going with.
|
| | | 1 (25%) | |
|
|
| | For the network bug, as I've said, i've got it figured out, just have to do it.
For the printing, I'm sending an email to Dr. Wong about the credentials. I still can't seem to send emails to the comp410 listserve... My fault for not staying on this issue til it was fixed. It's so easy to be distracted by work... Stanely is going to go to Kinko's to print the posters instead so we will have them by monday regardless. Flyers as well. |
| | | 1 (25%) | |
|
|
Total: 4 |
5. Development Process: What seems to be working and why?
|
| | The serialized object messages have made us much better at explicitly telling each other what needs to be communicated between modules other people are working on. Writing it down is nice, but if you write it down in code, the project won't build unless you both conform to the object specifications. |
| | | 1 (25%) | |
|
|
| | everyone freeing up time
poster inspiration, thanks joan |
| | | 1 (25%) | |
|
|
| | We are all putting in a lot of time. Right now we need to invest man hours. Every night we have been getting together and working. Working together promotes productivity. It is easier to have questions answered when we are in the room together.
|
| | | 1 (25%) | |
|
|
| | Group crunch time, impending deadlines, and tasks keep us focused. Not much has changed since my last journal. Also, now that classes are done and *most* of my other work is complete, I can really focus on what I need to get done. It's amazing how much more efficient you can be when you haven't got a million things going on in your life. This is true for all of us. We are a honed machine now. |
| | | 1 (25%) | |
|
|
Total: 4 |
6. Development Process: What does not seem to be working and why?
|
| | When using your code in conjunction with someone else's and an error arises, its hard to isolate exactly where that error came from. You really aren't familiar enough with the other person's code to step through and completely understand and fix the error. Sometimes the error is in your code and you just make yourself believe its someone else's fault. Problems are exacerbated because a unit test can be written to work on the local host, or across a single role instance, and then fail when they are extended to multiple role instances of deployed to the cloud. |
| | | 1 (25%) | |
|
|
| | demo mode
lol unit tests |
| | | 1 (25%) | |
|
|
| | Not sleeping. It promotes stupid mistakes. Hours are spent figuring out stupid mistakes made because of touching the code with a fuzzy head.
Some People have not been doing unit tests!
|
| | | 1 (25%) | |
|
|
| | So again, my fault for not really getting in people about this, but the frightening realization of the day was when I moved some stuff around and had to update all the unit tests, it came to light that at minimum, Stanley and I are responsible for 80% of the generated united tests. We definitely did not do 80% of the work....
|
| | | 1 (25%) | |
|
|
Total: 4 |
7. Development Process: Proposals for change--issues addressed and why the change will help.
|
| | Making sure you stop and isolate the bug as best you can is crucial. I spend too long taking shots in the dark trying to fix the problem instead of approaching it with a level head and stepping through the proper debugging. When I get stuck on a problem, I need to realize sooner and take a step back sooner so I can make better educated decisions in the debugging process. I also need to be quicker to ask other people for help when I come across a bug that I get stuck on. Even talking about it with someone can help you realize a simple error or a case you hadn't thought of. |
| | | 1 (25%) | |
|
|
| | impressive demo, explanation of possibliity |
| | | 1 (25%) | |
|
|
| | Sleep! It pays off in the long run. Sleeping an extra hour or two at night clears your head. It makes debugging easier and you save time in the long run. Of course, the intention to sleep does not always make sleep.
Do Unit Tests people!
|
| | | 1 (25%) | |
|
|
| | This is not really pertinent to the comments above, but sleep! Or actually, if you're an insomniac like me, power nap! Rest your eyes often for short periods of time. Let your mind relax. Dennis today was nearly crazed from sleep deprivation until he took a two hour nap and came back to blow his way through the User Panel like a boss. |
| | | 1 (25%) | |
|
|
Total: 4 |
8. Peer review: Positive or negative feedback for other class members
|
| | |
| | | 1 (50%) | |
|
|
| | Dennis: GUIs owned, network layout fleshed out, you sir are the man.
Stanely: I think you, out of all of us, has been thrown around the place on this project the most. Good job staying sane and ty for working Mixers.
Alme: The cloud death bug is really worrying the rest of the team, including myself. If you need help on it, ask us |
| | | 1 (50%) | |
|
|
Total: 2 |
9. Additional Comments
|
| | sm -> fe -> mx all through cp and up |
| | | 1 (33%) | |
|
|
| | |
| | | 1 (33%) | |
|
|
| | After wednesday, I am getting drunk. Or sleeping for a day. Possibly both. That is all. |
| | | 1 (33%) | |
|
|
Total: 3 |
10. Advice for future Comp410 classes
|
| | You will work your ass off. But it is totally worth it. Interviewers will be impressed. It is a great experience. There is no other class like it at Rice. |
| | | 1 (50%) | |
|
|
| | The last advice I can give you all is to fight for what you believe in. Sounds corny, I know, but really, don't just agree to go with something just because someone else proposed it. Argue (Some would say discuss, but i would say that if it's an idea you really want, some added fire is a good thing!). If you have time, sit down and think out why it should be done your way. Even if you're wrong, until someone can definitively point out why you are wrong, it means that NO ONE truly understands the problem. Identifying why something is wrong is often just as valuable as getting the right solution. Also, it is tempting to go for the solution that works and is easiest. Don't jump on the bandwagon. The solution that works and is easiest oftentimes becomes the thing that you spend far too much time undoing or working around because you didn't really think through how you were going to use it. At the end of the day, a decision must be made, and if you are to accomplish anything, that decision must be respected by all. But until the final call, think, argue, and then congratulate yourselves on a job well done. The journey is a tough one, but you will learn so much about yourselves, about other people, and let's be honest, it's going to be effing sick to have on your resume. Good luck. |
| | | 1 (50%) | |
|
|
Total: 2 |
|
|
|
|
|
|