What makes a cat a cat?

When defining a new concept, we need to identify the boundary, i.e. the characteristics (or a specific grouping of characteristics) that make the thing unique.

What makes a cat a cat? Because it is living, which is different from rocks. Because it moves, which is different from plants. Because it catches and feeds on rats, which is different from dogs.

What makes a program different from a program fragment? Because it can compile and run whereas the fragment cannot.

If we find it so hard to identify the boundary of the new concept, chances are that we are trying to invent a new name for a century ancient thing.

It's not what you say, it's how you say it

The instructor did give us an effective two-day presentation: a pretty good course -- made some good points, got us many chances to practice. All of the content sound like common sense, but in fact until someone points those out, you are not aware of them. Even worse, it is so easy to forget and requires so much effort to master when you are on the "stage". I call them commonly insensible common senses.

Just give a boring yet useful list of reminders for myself:
== What ==
- The "So-what". This is a good point, and this is such a common sense: when you speak, think in the position of audience. Why they want to spend half an hour listening your ramble? What benefit can they get from it?
- Get to the main point quicker, get to the "so-what" quicker. "The audience are hopeless impatient." They are so easy to be distracted. So get to what they are really interested in as soon as possible.
- Anecdotal. Examples, not abstract concepts.
- Next step. After the conclusion, you'd better show the audience ways for them to participate, act, or response rather than forgetting what you have said in the first minute.

== How ==
- Take control of your space, be aware of the room. He gave an example that a speaker keeps bumping into a chair. Everybody down there would say "God.. move it!". A confident speaker should observe the room and take full control of his presenting space. You own that space and you should do whatever that makes you comfortable and makes your presentation go smoothly.
- Connection: Eye contact(distribute, keep the connection); use the big screen instead of reading laptop screen; don't talk while not looking at audience
- Be comfortable with pause: It's interesting that it is so easy to learn filling words when you learn another language. I tend to use those filling words right after I hear from someone else, such as "you know", "like" etc. When you are presenting, it sounds really worse than you might think. I started to be aware of this when the instructor echo ed back my filling words. So whenever you are thinking of what to say next, just pause. The audience won't mind that.
- All about variation: volume, pace. The excise really feels like in an acting class. Everyone had to go to the front, and speak out three phases in whatever variation of volume and/or pace to express different emotion.
- Rest position of hands

First taste of Ruby

Googled and wrote a very simple Ruby program:


File.open("c:/model.ecore").each { |line|
puts line if line =~ /name="(\w+)" eSuperTypes=".*\1.*"/
}


Run Ruby in the command line, and... it just worked!

Although it's not a representative Ruby program, the fact that it just worked did impress me and give me more motivation to learn this buzzword.

Removing by not adding

When creating subclasses, there are chances that we want to remove some inherited operations/fields. This requirement appears more frequently when dealing with multiple inheritance. Why doesn't Java (or any other OO languages) provide a facility that does such removal? Because it is evil. This removal facility will rapidly create unmanageable code because no operation in a class is guaranteed to exist.

Then how do we deal with this case using OO paradigm? Well, if such requirement arises, it normally implies a bad design! We should decompose super-classes/interfaces (break into pieces), group those operations that we wanted to remove, and just not add corresponding classes/interfaces as super types.

Random Thoughts about API

API, Application Programming Interface, is meant to provide clients an easy and simple access to use a code package. (Although other stuff could have API too, I only talk about software here)

When designing an API, we should notice some of its additional benefits.

It helps you think clearly and explicitly what kind of work your code does. You can verify and be confident of the correctness (or should we say robustness?) of your code by testing the API. You can easily measure the performance of your code by profiling the API. A good designed API should hide as much as implementation details as possible. It is an abstraction of the entire code package. It tells about the essence of the entire code package. It helps you identify the boundary of your code package. By constructing an easy and simple API, we can avoid convoluted code logic and we have a clear purpose.

Test driven development is to design an API first in some sense: you design the "API" for the code unit, write the test for this "API" first, and then implement it.

So, when you design a code package, construct an API first. Should we call this API-driven development?

AOSD Demo a success

I like the idea of Demo madness: using that tiny bit one minute, I managed to attract 40+ people coming to my talk (The average number of attendance is 10 or even less). People got excited about the idea and the tool, asking whether it's open source, making interesting suggestions. I handled their questions surprisingly well, which even surprised myself too. I can still remember the applause at the end of the demo.

Their feedbacks/questions include:
- will this be open source?
- will this be part of AJDT?
- Performance issue
- Use the same idea of suggesting to include some join point shadows to exclude some jps
- Quick fix addition
- Almost matched jps should be in different level (the idea of "more" button)
- What is the criteria of being selected as almost matches? (heuristics)
- Heuristics available on website? (will be on a paper)

Overall, I'm surprised and excited that I could do that well speaking in public: one minute in front of over 1000+ ppl and 30 minutes on 40+ ppl (I am bad at counting, so these numbers could be totally wrong), for madness and the demo respectively. It was really a success for myself.

Really nice user interface

I just got a new dock station for my T60 at work. I must say it works so great... Here's an example:

when I want to undock my laptop, I need to:
- push the small button on the dock until something shows up on my screen
- insert my key and rotate so that the little red lock light is off
- wait until the green arrow light is on
- push the big pop up button.

Wow, four steps are required, and you will have to pay close attention to the screen and those little lights. Notice that if you forget to push the small button but do put in your key, the green arrow light will still be on but you are not able to push the popup button...

I wish I could get my mini-dock back from school.. There is only one button for undocking and one power indicator. And of course only one button pushing is needed for undocking.

This really shows us the principle of user interface design: less is more.. and more is less...

strange "overridden" java field

In Java, fields could also be "overridden", and for each overridden field, a copy of memory is allocated. These versions of field could be only accessed by means of type casting. This seems strange enough--what's the point to have "overridden" fields? Are there better ways to access those "versions" of fields?

For example, the output of the following program will be:
t.f=3 p.f=1


public class FieldSignatures {
static class P {
int f;
}

static class S extends P {
int f;
}

static class T extends S {
T() {
((P)this).f = 1;
((S)this).f = 2;
this.f = 3;
}
}

public static void main(String[] args) {
T t = new T();
P p = t;
System.out.println("t.f="+t.f+" p.f="+p.f);
}
}