Confessions of a researchaholic

July 28, 2013

The matrix concert

Filed under: Imaginary,Real — liyiwei @ 1:54 pm
Tags:

I went to the Matrix in Concert with the San Francisco Symphony conducted by Don Davis, who is also the composer for the Matrix trilogy.

Basically, what they did is to play the first matrix movie with music accompanied by the orchestra.
I enjoyed the show for a variety of reasons: I am a fan of the original movies, the visual setup (black dressing + green lighting) is fitting, and the music integrates seamlessly with the movie.

The most interesting aspect is that the music adds (yet) another layer of performance + reality, over the original movie, which is already layered. The music starts with the opening scenes and ends after the end credits. So the entire show starts before the movie starts and ends after the movie ends. In a movie theater, most audience would walk out during the end credits, but we should sit through this one. (It was very funny to see a few folks who left during the end credits.)

What has not changed is that I want to be agent Smith if I can choose to become one of the characters.
πŸ™‚

July 26, 2013

Cool dude in town

Filed under: Real — liyiwei @ 3:32 pm
Tags:

I am thrilled that one of my previous interns will join cityu.edu.hk as an assistant professor. A record holder in several aspects:

He is my last MSR intern.

He is also the most senior (not equal to old), with an associate professor title during the internship.

Somehow he managed to become associate professor without even getting his PhD first, both in the same university.
(He is a cool guy already, but this is just awesome.)
πŸ™‚

Laptop-less in Anaheim

Filed under: Real — liyiwei @ 3:30 pm
Tags: , ,

I did not bring my laptop to SIGGRAPH this year to discourage myself from working inside the convention center or the hotel room.

Experimental results indicated that this motivated me to spend more time hanging out with people, which is supposed to be the main goal for a conference. I can easily schedule all events and meetings via my smart phone and tablet. (Even the tablet is probably not necessary, if I can address a few technical issues of my phone.)

I probably would have had to bring my laptop if I had to give any talks. None of the Android apps I know of can adequately author talk slides. If such apps eventually show up (and I expect they will), I would happily travel with only my phone in the future.

Eventually though, the phones will likely become powerful enough for me to work inside the hotel rooms (again).
πŸ™‚

July 18, 2013

Managing paper committee meeting

Filed under: Real — liyiwei @ 3:38 pm
Tags: ,

Most paper committees I have served have purely electronic review processes. These are relatively easy. Those with in-person meetings (e.g. SIGGRAPH) are more challenging as they involve live human interactions in real-time.
Below are some of my personal experiences to make the process more fun and effective.

Emotion

The most important and yet difficult task is to remain neutral, no matter what happens. It could be quite some experience to see your paper getting rejected and immediately you have to discuss a paper you reviewed.

I have a very simple strategy that works superbly well for me so far: I just assume all my papers are (or will be) rejected, even if they have very high ratings. (Anything could happen, and has happened before.) By assuming the worst case scenario, I can never be disappointed. I also do my best NOT to track my papers; I did not even look at the status on the spreadsheet when I am outside the room. Then it is easier for me to remain cool.

It also helps if you naturally care less.
One possibility is to not have any submission, but this is not common for people who are still productive.
Another possibility is to have enough prior papers so that you care less.
The paper chairs like to recruit more senior people not only for experiences but also for this “care less” factor.

Other things being equal, it is usually better to be positive than negative. My rule of thumb is to accept if unsure. This is better for humanity; a good paper wrongly rejected will not be read by anyone, while a bad paper wrongly accepted will likely be ignored by future research anyway. This is also better for myself; I do not want to leave a reputation for being a paper killer.

Workload

It is a lot of work to review 20-something papers. You will look bad if you do not seem to know what each paper is about, especially during the plenary sessions or breakout discussions. So make sure you put in enough efforts.

I also keep enough dark chocolate around to maintain my brain function at the end of the (long) day. (OK this is probably some lame excuses; I overdose cocoa no matter what.)

I am probably lucky (or maybe I am good at requesting papers; dunno yet) in that I usually get good assignments (high quality submission fitting my interests and expertise well), so I usually know each paper well. For those few that are outside my expertise, I just admit it to other committee members and reviewers. Nobody knows everything, so honesty is often the best policy.
Plus, I guess many of you have seen reviewers who clearly have no idea what the f*** they are talking about, so try not to be such jerks.

Participation

For those of you who think the committee members have some edges in getting their papers in, you might be disappointed; as far as I can tell, no such advantages exist, and the system has been well designed so that it is very difficult to game.

However, the committee members do have advantages in organizing the paper sessions, which is also the most fun part of the committee service in my opinion. You can influence where and when papers (including yours) go and which sessions you chair. People who do not show up might find papers (they authored or reviewed) going to a strangely titled session with a motley collection of seemingly unrelated papers, or find themselves chairing sessions that are too early for many people to wake up or too late in the last day for many people to remain behind.

July 17, 2013

Advices on advising

Filed under: Real — liyiwei @ 5:51 pm
Tags: ,

I stumbled upon these advices on advising by David Patterson (here) and Jeff Ullman (here) today. I found both insanely useful, especially after having a few years of advising experiences. The advices differ in the way that Patterson is mainly on systems and Ullman mainly on theory. But they also share similarities such as the importance of identifying problems and collaborative work.
(I would really love to hear from someone in graphics and HCI, fields with more emphasis on human side applications. I am thinking about asking my former school advisers/professors to write such articles.)

I reflected upon my (unusual) style of individual work and asynchronous communication. This has been quite effective so far, but I never stop thinking it could go wrong, at least for some students. So what I did is to make sure there is always at least one co-adviser who can help with the normal human side of needs, like in person meetings and emotional support.
Exposure to industry labs or even startups, fortunately, should be the benefit of working with me, given where I came from and whom I know.

I encourage all my past, current, and future students to read these articles, and let me know if you have any comments.

July 10, 2013

Picking up HCI

Filed under: Real — liyiwei @ 3:37 pm
Tags:

I am picking up HCI as it is becoming more relevant to my teaching and research. Here is a log of what I have found useful. As work in progress things are going to be in a flux. If you have suggestions I would love to hear.

PS: Back in grad school my PhD adviser once commented that UI design is my Achilles heel. πŸ™‚

Books


The design of everyday things by Donald Norman is an old text but has aged quite well. The thing I like most about the book is that it provides many highly intuitive examples and counter examples to illustrate many of the practical design issues.


I learned about user studies from measuring the user experience by Tullis and Albert. It is pretty comprehensive, but for detailed math/theory you will need to look up elsewhere.

Courses

The coursera course by Scott Klemmer covers several main aspects of HCI and is fun to participate. I quickly went through it off season within a few days so I just watched the videos and did the quizzes. I plan to join the next offering and do the homework assignments (for real).

Scam

Filed under: Real — liyiwei @ 9:58 am
Tags: ,

This morning I got a phone message from an alleged debt collector. It smelled full of scam so I looked up online and confirmed my suspicion.

Basically, what seems to be happening is that if you call them, they will ask you for your personal information. In other words, it is identity theft taking advantage of human weakness. Many people, upon hearing that they owe debt, would feel guilty. Thus, they are more likely to put their guard down and divulge their personal information.

But this is probably less effective for people with different kinds or degrees of conscience.
πŸ™‚

I wonder why debtors should fear creditors. Do you think you are more afraid of your bank (where you deposit/lend your money) or the other way around?

July 5, 2013

SVN post commit email notification

Filed under: Real — liyiwei @ 1:33 pm
Tags: ,

To some of my collaborators who have recent troubles with svn auto notification:

Instead of the usual spam run on my svn mail server, this time the issue seemed to come from over-zealous spam filtering. That is beyond my control, so I did a workaround.
(See below for more details if interested.)
The only difference is that you will see only yourself as the email recipient instead of everyone else on the cc list.
But this is probably a good thing as it can discourage the temptation to reply all through email.

Let me know if you still see issues.

Setup guide

Here is a quick guide on setup for linux. I will let you search online for other systems and more details.

. Under the “hooks” directory of your repository, there should already be a file named “post-commit.tmpl”. Copy it to a file named “post-commit”, and set x permission for ug. As the name implies, this is the file that will be automatically evoked after commit.

. There should already be a line similar to the following at the end of that post-commit file. All you need to do is to set the proper directory for commit-email.pl and append proper email list.

/usr/share/subversion/hook-scripts/commit-email.pl “$REPOS” “$REV” -s “Project Name” person1@foo.bar person2@foo.bar

. Alternatively, you can also use mailer.py in lieu of commit-email.pl. The former will give you more options while the latter is simpler. For mailer.py, use the following line instead of the commit-emai.pl line above:

/usr/share/subversion/hook-scripts/mailer/mailer.py commit “$REPOS” “$REV” “$REPOS”/hooks/mailer.conf

You also need to put a mailer.conf file under the same directory.
Below is a simple basic setup that works well for me.

[general]

# This command will be invoked with destination addresses on the command
# line, and the message piped into it.
mail_command = /usr/sbin/sendmail

[defaults]

# This is not passed to the shell, so do not use shell metacharacters.
# The command is split around whitespace, so if you want to include
# whitespace in the command, then ### something ###.
diff = /usr/bin/diff -u -L %(label_from)s -L %(label_to)s %(from)s %(to)s

# The default prefix for the Subject: header for commits.
commit_subject_prefix = Project Name

# The default To: addresses for message. One or more addresses,
# separated by whitespace (no commas).
# NOTE: If you want to use a different character for separating the
# addresses put it in front of the addresses included in square
# brackets ‘[ ]’.
to_addr = person1@foo.bar person2@foo.bar

# If this is set, then a Reply-To: will be inserted into the message.
reply_to = noreply@foo.bar

# Specify which types of repository changes mailer.py will create
# diffs for. Valid options are any combination of
# ‘add copy modify delete’, or ‘none’ to never create diffs.
# add: generates diffs for all added paths
# copy: generates diffs for all copied paths
# which were not changed after copying
# modify: generates diffs for all modified paths, including paths that were
# copied and modified afterwards (within the same commit)
# delete: generates diffs for all removed paths
generate_diffs = add copy modify

# A revision is reported on if any of its changed paths match the
# for_paths option. If only some of the changed paths of a revision
# match, this variable controls the behaviour for the non-matching
# paths. Possible values are:
#
# yes: (Default) Show in both summary and diffs.
# summary: Show the changed paths in the summary, but omit the diffs.
# no: Show nothing more than a note saying “and changes in other areas”
#
show_nonmatching_paths = yes

My workaround

The mail filter appeared to be rejecting and considering as spam some automatic notifications with multiple recipients. So a quick workaround is to send out emails once at a time to individual recipients. This can be easily achieved via commit-email.pl as follows:

for person in person1@foo.bar person2@foo.bar
do
/usr/share/subversion/hook-scripts/commit-email.pl “$REPOS” “$REV” -s “Project Name” $person
done

For mailer.py, you will need separate conf files for individual recipients. This does not look very convenient to me.

Theme: Rubric. Get a free blog at WordPress.com