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

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

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

Concepts

• Dr. Wong has redesigned the Java Resources page on his website so that it is easier to navigate. Dr. Wong finds it unlikely that he will be able to discuss all of the minute but important details of some of the topics that weĺl be doing soon, and therefore encourages everybody to visit the Java Resources page for in depth information.
• What is the “transient” modifier that is applied to the taskView instance variable inside of tasks? During serialization, an objects fields will be encoded into some stream of bytes, which will then be sent across the network. On the other end, Java will instantiate a new class of the same type, then insert all of the values that it finds in the serialized stream.
• Well, the taskView field is a reference to some other object; at some level just a number that identifies the other object. What would that number mean if we serialized it and sent it somewhere else? It would be meaningless outside the context in which it was created. /* This seems somewhat off-topic to me, because, as discussed below, this won’t happen. Java will attempt to serialize the entire referenced object. */ Transient indicates that the serializer should ignore the so-marked field.
• Note that normally, during serialization, the serializer will follow references (If Object A references Object B, and A is serialized, B will also be serialized). Be careful, therefore, not to serialize anonymous inner classes that close over other variables, as you can easily end up serializing and transmitting your entire system.
• Don’t confuse volatile and transient! volatile indicates to the Java Compiler that the value of some variable is not safe to cache (because the variable changes in parallel ways (?)) and that it shouldn’t try to optimize any code that uses the volatile variable.
• You can override (some interface…).readObject(…) (Something in Pi2.java…) if you need to do some sort of re-initialization whenever your Object is deserialized. You can call stream.defaultReadObject() to perform the normal deserialization, then take the opportunity to initialize your transient fields to some well-defined value.

Now we’re going to talk about generic list frameworks.

• Let’s take a generic list: IList<E>. What does it mean to run an algorithm on it?
• public abstract <R, P> R execute(IListAlgo<? super E, R, P> algo, P …)
• We declare that execute will return a type R: whatever the algorithm returns.
• We make a generic parameter P for whatever parameters the algorithm takes.
• ? super E: any algorithm that works on a supertype of E can work on this list of E‘s.
• Thus, we have a method, with generic parameters R and P (inside of an IList with generic parameter E), which accepts an algorithm that operates on a supertype of E, accepts parameters of type P, and returns a type R, and some number of parameters, each of type P.
• public abstract R emptyCase(IMTList<? extends E> host, P … inp);
• Declares a case in a visitor (the algorithm), that operates on any subtype of E.

Quotes

• “If you want a glass of water, there’s two components, right? The glass, and then the water! You only transmit the water from one glass to another; the glass is like the class, and the water is like the data.”
• “Never trust another programmer, especially not the one in the mirror.”
• “This is like the most intensely generic statement I’ve ever seen!” — Caleb
• “This is the easy one.” — Dr. Wong

Resources

Ambient Temperature: 74.4^oF

Concepts

1. More explanation of the RMI infrastructure.
2. If you are off-campus you must use VPN before you’ll be able to connect to an on-campus partner.
3. If you are behind your own router, you will have to make sure that you forward the appropriate ports to your computer.
4. public <Type> Type executeTask(ITask<Type> _task) throws RemoteException;
   This is a parameterized method. Its parameter is an ITask, which has been parameterized to some arbitrary type. Whatever the type of the ITask is, is what the method will return.

Resources

1. Lecture 26 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec26/
2. Lecture 25 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec25/
3. COMP 310 Resources on Generics: http://www.clear.rice.edu/comp310/JavaResources/generics/
4. Oracle Tutorial on Generic Methods: http://docs.oracle.com/javase/tutorial/extra/generics/methods.html