Mercurial has a useful command, hg summary, that prints out some basic information about your current repository status. git status prints most of this information, but omits some useful details such as the ID and message of the most recent commit.

The following shell script will fix this, printing the current commit followed by the output of git status:

#!/bin/sh

HEAD_REV=`git rev-parse --short HEAD 2>/dev/null`
if [ "$?" -ne 0 ]; then
    exec git status
fi
HEAD_MSG=`git show -s --format=%s HEAD`

echo "Parent revision is $HEAD_REV: $HEAD_MSG"
exec git status

Save this script somewhere on your $PATH as git-summary (~/bin is a good option). If you are on Windows, save it in a file called git-summary in the usr\bin subdirectory of your Git installation (often C:\Program Files\Git). Then you can run git summary to see this augmented display:

Search and recommendation are very interrelated concepts.

@alansaid @xamat @mitultiwari I'm not really a #recsys guy – am more of a search guy. Though #recsys is just search with a null query. :-)

— Daniel Tunkelang (@dtunkelang) October 13, 2013

IR folks: how is the "zero query" scenario not just rec sys?

— I am K (@vanessa_murdock) October 13, 2015

What is search, but query-directed recommendation? Or recommendation, but zero-query search?

My students asked me about this relationship in my recommender systems class last spring. Trying to answer this question brought me to a formulation that seemed to help them, and perhaps it will be more broadly illuminating as well. For some of you this may well be old hat.

My second-year evaluation packet is due in a couple of weeks. A lot of my materials were in order; I took the time to reorganize and backfill my archive, so the next review submissions will hopefully be pretty easy. And there will be many of them: reappointment reviews until tenure, annual performance reviews to determine pay raises, the Big One for tenure and promotion itself, and hopefully someday an application for Full Professor.

The two biggest problems for preparing these packets seems to be maintaining a complete log of relevant activities, and maintaining supporting documentation for them. Given the importance of these reviews, and the many other activities that require some form of CV or snapshot of accomplishments, it seems worth some up-front investment in tooling and organization.

Here’s how I do it.

The theme of my RecSys 2015 paper, along with the other papers in its session, is on giving users control over their recommendation experience.

Why do we want to do this? Isn’t the idea of recommender systems to figure out what the user wants and give it to them, without needing significant intervention?

There are a few reasons I think user control is an important research direction for recommender systems. First, different users have different needs, and different algorithms have different strengths. This is the idea behind McNee’s human-recommender interaction framework, and the thesis and results of several of my experiments. So far, we don’t have good meta-recommenders for identifying which recommender will best meet a particular user’s needs, so giving them control is a way to punt on this.

First-and-a-half, if we give users control in the short term, then we can obtain more training data to develop potential meta-recommenders to provide a better user experience.

This is a paper about a drop-down menu. I’ll be presenting on it in the first session on Monday at RecSys 2015; the work is joint work with Daniel Kluver, Max Harper, and Joe Konstan at GroupLens.

In our previous paper, we examined what algorithms users say they prefer and the differences they perceive between those algorithms. This paper asks the follow-up question: when users are allowed to select the algorithm they actually use, what do they do?