COMP 310

Concepts

1. Meeting tonight to practice chatting. 7:00pm. Location TBA, meet outside DH 1064 (where we normally have class).
2. Owlspace polls are closed. No official design decisions were made. de facto design decision is therefore no changes to the interface.
3. Most of the salient points happen in the in-class discussions. It is likely to be this way for the rest of the year.

Resources

1. Lecture 35 webpage: http://www.clear.rice.edu/comp310/f12/
2. Polls on Owlspace: https://owlspace-ccm.rice.edu/portal/site/COMP-310-F12/page/218d0c21-9305-43ca-b542-fb96d1b53f4c

Ambient Temperature: Unknown; thermometer battery low.

Concepts

1. HW08 extension: HW08 is now due by class time on Wednesday, November 14th.
2. Dr. Wong offers to have evening office hours on Monday, November 12th, to assist with testing and debugging the final project.
3. Class design decisions:
1. The receiver of a data packet MUST be able to determine who sent the data packet. To accomplish this, Data Packets will contain the user that sent them.
2. ICmd2ModelAdapter will remain unchanged.

Quotes

Resources

1. Lecture 34 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec34/
2. Threading in Java: http://www.clear.rice.edu/comp310/JavaResources/threads.html

Ambient Temperature: 73.9^oF

Concepts

1. We’re using the interface from last year. Dr. Wong will post it to the provided code in the SVN soon.

Quotes

Resources

1. Lecture 33 webpage:  http://www.clear.rice.edu/comp310/f12/lectures/lec33

Concepts

1. Java GUIs run in their own single thread. RMI runs in its own single thread. Your code will run in a third thread of its own. When communicating between threads, either through data accesses or function calls, you need to be careful.
2. Java has provided a super-simple way to guarantee that any operation you may want to perform with GUI objects, can be executed in a thread-safe manner: SwingUtilities.invokeLater(…);
   SwingUtilities.invokeLater( new Runnable() {
   public void run() {
   // Your code here
   });
3. Blocking Queues help the Producer-Consumer model of asynchronous processing work. Blocking Queues block the consumer, not the producer, allowing data to arrive as fast as it wants.
4. The class then broke into groups to decide:
1. What should the return value of a sent data packet RMI invocation be?
2. What is the protocol for figuring out how to handle unknown commands?
5. No decisions were reached.

Resources

1. Lab 10 webpage: http://www.clear.rice.edu/comp310/f12/labs/lab10/
2. More reading on Cross-Thread Invocations: http://www.clear.rice.edu/comp310/JavaResources/crossthread.html
3. Group Design Brainstorms Wiki: https://owlspace-ccm.rice.edu/portal/tool/6207c4c3-bbc0-47d3-8161-8e88cf4286b2?pageName=%2Fsite%2FCOMP-310-F12%2Flab10&action=view&panel=Main&realm=%2Fsite%2FCOMP-310-F12

Ambient Temperature: 74.3^oF

Concepts

1. Dr. Wong’s talking points:
1. Mini-MVCs: Consider making an MVC for a “chat room,” and then having your ChatApp add those MVCs as you join chat rooms. This could be a helpful delegation of tasks in your design.
2. Equality of Stubs: When you call .equals() on a Stub, there’s no guarantee that it will use the .equals() provided in the actual object that the stub points to. This is because the Stub is also a Java Object, and its .equals() will get used instead. Dr. Wong suggests wrapping all received stubs in a class that properly implement comparison methods (compareTo, equals, and hashCode) based on the available data in the stub.
2. Class Design Decisions
1. None

Resources

1. Lecture 32 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec32/
2. Dr. Wong’s ProxyUser equality wrapper: http://www.clear.rice.edu/comp310/JavaResources/RMI/compare.html
3. Completed HW08 public API with working chat room reference implementation: http://comp310.blogs.rice.edu/hw08-public-api/

Ambient Temperature: 75.5^oF

Concepts

1. How to Design Software
1. Use Cases: Talk to your user(s) and find out what they want the application to do. When that’s done, you know what tasks your application must be able to accomplish in order to satisfy the user. These will not be phrased in terms of code at all, as the users don’t know or care about code. Example: “Talk to multiple groups of people over the internet.”
2. Specification: Using your knowledge as a programmer and the Use Cases from step 1, enumerate all of the tasks that your program must be able to perform in order to satisfy the use cases. Example: “Allow user to choose an avatar graphic from their local machine.” versus the use-case of “I want to be able to have a picture display next to my name.”
3. Protocol: Describe a language for your program to use to communicate that will allow it to fulfill all of the tasks in the Specification, including:
1. The format of its input.
2. The format of its output.
3. Assumptions that your program makes about the input it receives.
4. Assumptions that third parties can make about your program’s output.
4. Interface: Using your knowledge as a programmer, design a code interface that will allow you to implement the Protocol.
5. Test Cases: Write test cases to for the code interface that can be used to verify its functionality.
6. Implementation: Write the code that implements the Protocol.
2. Dr. Wong decided that the protocol for Homework 8 will be a fully peer-to-peer model. There will be no notion of centralization.
3. Design decisions by the class:
1. Connection to other clients will be handled with one RMI stub per activity.
2. There will be separate stubs for pre-conversation methods and for the methods involved in participating in a conversation.
3. The pre-conversation stub will be called IHost. Different machines will exchange IHost stubs before they can chat with each other.
4. IHost‘s method that will be called by a remote host to send it a data packet will be called receive(…).

Resources

1. Lecture 31 Webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec31/
2. Some people collaborating on Google Docs:  https://docs.google.com/a/rice.edu/document/d/1gjDWVNwe5zArtCF1MeePVy37-9U7f0uJRGvCkT3ZHgA/edit

Ambient Temperature 74.9^oF

Concepts

1. The lecture webpage lists several desirable features of a given piece of software:
1. Minimal and Complete: “Strive for the minimum number of methods that for a complete set, enabling all required operations to be performed.”
1. Convenience methods that are composed of other functions in the interface do not belong in the interface. Convenience methods add no new capabilities to the interface, and are therefore entirely in the domain of the implementation, not the interface.
2. Orthogonality: “All methods should be maximally independent of each other and not perform operations that are also partially performed by other methods.”
1. In other words “no interface method should perform tasks that include all of the tasks of another interface method.”
3. Implementation Independent: “The user of a method or object should not be concerned with how it is implemented.”
1. If a method won’t work unless it is implemented in a specific matter, that method should not be part of the interface.
2. In designing the interface, you cannot make assumptions about the state before, or computations after, a given method call.
4. Flexibility: “All possible operations must be able to be accomplished with the defined set of operations and objects without the need for special cases.”
5. Extensibility: “The addition of new operations and/or capabilities should not require major reconfiguration of the system, preferably no changes at all.”
1. Builds on Flexibility: Flexible systems are more easily extended than inflexible systems.
6. Robustness: “The system should be designed to gracefully handle user or other errors that may occur.”
1. Rather than checking to see if input or actions are valid, instead avoid providing any interface methods that allow invalid input or actions. Also applies to Security, below.
7. Security:  “The system should be gracefully disallow deliberate attempts to circumvent proper operation.”
1. If you don’t want users to be able to mess with something, make that thing immutable or invariant.
2. Do not use anonymous inner classes in any object that will get sent over the network. Java handles this poorly.
3. The class went over the union of all lab groups’ ideas for ChatApp features.

Resources

1. Lecture 30 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec30/
2. Why not to serialize anonymous inner classes: http://www.clear.rice.edu/comp310/JavaResources/RMI/index.html#tiptraps
3. Lab groups’ feature list: https://owlspace-ccm.rice.edu/portal/site/COMP-310-F12/page/57ffcbae-4fb2-4126-8976-734432cce374

Concepts

1. Creately online spec design
1. Design
2. Code
3. Goto step 1
2. When done, export it as an image, and post it to the Lab09 wiki.
3. After about 20 minutes of lecture, we broke into groups to do steps 1 and 2 above.

Resources

1. Lab09 webpage: http://www.clear.rice.edu/comp310/f12/labs/lab09/
2. Creately online spec design software: http://creately.com
3. COMP310 Owlspace Wiki Home: https://owlspace-ccm.rice.edu/portal/site/COMP-310-F12/page/57ffcbae-4fb2-4126-8976-734432cce374

Ambient Temperature: 73.8^oF

Concepts

1. The class will be collaborating to design some of API for HW08. This is the API that will be used to communicate between the ChatApp programs of you an your classmates.
2. But first, we’ll review the Data Packet and extended generic visitor architecture from Lecture 28.
3. We will need to produce a Use Case Diagram for the chat application.

Quotes

1. “I predict PAAAIIIN!” – Dr. Wong, with respect to the consequences of starting late on HW08.

Resources

1. Lecture 29 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec29/
2. Use Case Diagrams: http://www.clear.rice.edu/comp310/JavaResources/usecases.html