---

2/01/2002 01:08:00 PM

So a minor confusion arose last night in the midst of all the pair hacking. It was again related to the unit testing of distributed systems... I think I figured it out... At least in relation to what we were confused over last night..

So we were trying to test the Experiment on/off message SENDING functionality of the Command Computer... and we were contemplating over how to start up the Command Computer server (which would lead to an infinite loop) then also be able to invoke methods on the instance of the Command Computer... I just realized that you DON'T need to start up the server to test the SENDING functionality of the Command Computer. The ONLY time we need to start up the server is when we're testing it for its RECEIVE related functionality. So what we need to do is on one Xterm start up an Experiment Computer (i.e. python ExperimentComputer.py) then in another Xterm start up the Command Computer test (i.e. python testCommandComputer.py). This will make testCommandComputer (without starting up the CommandComputer server itself) test the sendToExperimentComputer method. You'll see the result of the message on the Xterm which has the Experiment Computer running.

I have modified the test to do this ( really all I did was comment out a few lines and add comments and print outs ). So the test passes now when you do as instructed. Hope that clears this up somewhat.

You should try running all the tests and they should all pass. I'll be on zephyr so lemme know if you have any questions while working. ;) Don't forget to commit the files into CVS after you're done cuz we didn't do that last night.

posted by dJsLiM | Link | Edit

---

1/30/2002 06:07:00 PM


I think our pair programming session last night went pretty well. Sarah was sleep and food deprived, but she succeeded in catching all the stupid mistakes that I would have made without her presence. ;) It's definitely a good feeling to see tests fail, yes even when it fails since you know it's supposed to fail it feels good, and to also see it pass. As mentioned in class today, it was much easier to unit test a self-contained unit. When we were writing the test for the Computer base class (which is essentially a stand-alone single threaded asynchronous server), we were faced with the fact that we can't really unit test it the way we unit test other modules. But, it wasn't too long before we realized that all we had to do was create a client on the test and test it that way... I guess we were perhaps thrown away by the term "unit testing" into thinking that we needed to load that particular unit within the test and run methods on it to test the functionality. So, for those of you interested, just check the latest CVS and read through the files.

No, we did not finish the entire set of tasks, but I think we accomplished a big chunk of it. Especially having finished the base Computer class gets the whole server headache off of our things to do. Let's keep chugging~~


posted by dJsLiM | Link | Edit

---

1/29/2002 07:54:00 PM

Tonight's pair programming agenda is:


The Command Computer decodes experiment on/off commands from the Ground Control and sends them to the Experiment Computers. (1)


Coder
Slim
Partner
Sarah


Objects involved
Exeperiment on/off Message
Command Computer
Ground Computer
Experiment Computer

Classes involved
Message
Computer


Tasks
The Command Computer can receive messages
The Command Computer can receive experiment on/off CMD messages
Ground Computer can send messages
Ground Computer can send experiment on/off CMD messages
Experiment Computer can receive messages
Experiment Computer can receive experiment on/off CMD messages
Message can be serialized for delivery across wire
Each computer runs a single threaded stateless tcp server that asynchronously reads/writes data

posted by dJsLiM | Link | Edit

---

1/29/2002 06:42:00 PM

I'm posting our story here just so that we all have a central place for accessing them.


A kernel of the Data Computer's functionality shall reside on an Experiment Computer. (1)

A kernel of the Command Computer's functionality shall reside on an experiement Computer. (1)

A kernel of the Attribute Computer's functionality shall reside on an Experiment Computer. (1)

An Experiment Computer can run the functionality of any of the primary computers. (2)

An Experiment Computer sends raw data of its experiment to the Data Computer. (1)

The Command Computer can turn experiments running on experiment computers on or off (1)

The Command Computer decodes attitude change commands from the Ground Control and sends them to the Attitude Computer. (1)

The Command Computer decodes experiment on/off commands from the Ground Control and sends them to the Experiment Computers. (1)

The Ground Computer sends experiment on/off commands and attitude change commands to the Command Computer (2)

The Data Computer receives then formats raw data passed to it by an experiment into a form understandable by the Ground Computer (2)

The Data Computer sends formmated data to the Ground Computer. (1)

The Star Tracker is able to report the direction in which the spacecraft is pointed. (3)

The Attitude Computer is assited by the Star Tracker in finding out the coordinates. (2)

The Attitude Computer makes explicit changes in the attitude of the spacecraft. (1)

The Attitude Computer keeps the spacecraft pointed in a given direction unless instructed otherwise (2)

The heartbeat can check if any of the primary computer has failed. (1)

The heartbeat can ask the Attitude computer for a status report (1)

When the heartbeat notices a failed computer, it uses the fault tolerance sw for remedy. (1)

All Primary Computers responds to the heartbeat query (3)

The Fault Tolerance SW reinstantiates the functionality of any of the failed primary computer, including the Command Computer on any of the experiement computers. (3)


posted by dJsLiM | Link | Edit

---

1/29/2002 12:11:00 AM

Alright, pair programming time team... let's remember that we're not supposed to really design anything apart from having an overarching architecture. I think we have that from our diagram and the metaphor. Let's not worry about how other modules will be implemented, but instead we'll refactor if we see duplicate code later on. It seems like Prof. Tomayko wanted to really stress the flexible nature of xP during our discussion today in class. I think we can dive directly into dissecting the story we've picked into tasks when we meet tomorrow and go straight to writing tests. This ... should be interesting. ;)

posted by dJsLiM | Link | Edit

---

1/28/2002 12:16:00 PM

Here is the updated Python Elements of style. I know it could be a pain to follow standards when it comes to writing code, but for the sake of consistency throughout our code base, let's give it a shot. ;) Also, here's a sample python code that shows the style in action.

posted by dJsLiM | Link | Edit