環境変数 CHROMIUM_FLAGS と Chromium のオプション –enable-remote-extensions

自分用メモ。

ほかはどうか知らないが少なくともこれを書いている時点の Debian (Stretch (testing))で、Chromium の拡張機能が無効になってしまった。検索してみると、

バグ報告の最後あたりのコメントにあるように、
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-remote-extensions"

~/.profile に書き加える。あるいは /usr/share/doc/chromium/NEWS.Debian.gz を参照のこと。

chromium-browser (55.0.2883.75-4) unstable; urgency=medium

  * External extensions are now disabled by default.  Chromium will only load
    extensions that are explicitly specified with the --load-extension command
    line option passed into CHROMIUM_FLAGS.  See the chromium-lwn4chrome
    package for an example of how to do this.
  * You can also use the --enable-remote-extensions command line argument to
    chromium, which will bypass this restriction.

これで拡張機能を有効にできる……はずなのだが、起動時に ~/.profile が読み込まれていない。長いことこれに気がついていなかった。既に不要となった環境変数設定くらいしか書いてなかったからな。

少なくとも Debian の Lightdm を使っている場合、~/.xsessionrc を作ってその中に

. $HOME/.profile

と書いておけば、これが読み込まれる。

プログラミング入門の入門

小学2年生のスウちゃん(仮名)は最近、“プログラミング”づいている。

「ロボットごっこ」

1年生の終わりころ、スウちゃんが「ロボットごっこ」をしかけてきた。たとえば「スウちゃん、ちょっと新聞とってきて」と頼んでも、「動かないよ。ロボットに命令してみて。」ってな感じで、新聞一つとってきてもらうのに「前に5歩、左向け。ドアを開けろ。前に8歩……」と延々と指令しなければならない。ゲラゲラ笑ったあと、ロボットと命令者を交代してまたゲラゲラ。

Scratch

これを楽しむということは“プログラミング”に興味を持つかも、と思い、まずはタブレットで楽しめる Scratch Jr. を紹介したら大喜び。が、操作性が今ひとつ(なかなかブロックが思うように移動・接続できない)なのと、単純すぎるのか、ほどなく飽きてしまった。

そこで PC で Scratch を教えてみる。ちょうどその頃(2016年3月末) NHK で「Why!? プログラミング」という番組の放送があり、ますます興味が湧いてきて、かなり真剣に取り組んでいる。

ところが今度は Scratch の自由度の高さが仇となった。キャラクター(コスチューム)を自由に描き変えることができるのだが、そこでお絵かきに夢中になり肝心のプログラムのほうはそっちのけ。まあそれはそれでいいのだけれど。

さらには、なんだか複雑なゲームを構想してしまい、とてもじゃないがすぐに結果が出ないので熱気が冷めてしまった。その前に習得しなければならないものがとてもたくさんある。

ハードウェア IchigoJam

一方で、機会があって「IchigoJam 体験」に参加。スウちゃんは初めてのハンダ付けに挑んだ。案外うまくできるものだ。CPUと数点のパーツだが自分で組み立てて、それでテレビに文字が出るというのは感動するようだ。手で触れることのできる形あるものというも実に大事なことなのだなとあらためて思う。

しかし、いろいろとハードルが高い。コンポジット出力なのでPC用モニターにつなげず、下手をするとテレビにもその端子がなかったりする。家のは大丈夫だったが、いざ始めようとするとテレビの真ん前に本体とキーボードをいちいちセットしなければならないのがちょっと面倒だ。それにそのキーボードの端子も PS/2 だ。これは家にもいくつかあることはあったがどれも US 配列で、日本語JIS配列が前提の IchigoJam BASIC だと、多用するダブルクオーテーションや丸括弧がキートップの印字と異なっていて、スウちゃんはひどく苦労している。しかも黒い画面に表示できるのは白い文字のみ。おっさんホイホイであることは間違いないが、現代の子どもにとって快適な環境とは言えなさそうだ。これを楽しめるようになるには、もうしばらく別のところでの修行が必要だ。

Code.org

Scratch は自由度が高くて的が絞れず、BASIC は何かと障壁が高い上に味気なく、どうしたものかと思っていたところに Code.org にたどり着いた。

  • (+) ステージが細かく設定してある。ゴールが設定されているため気が散らない。
  • (+) ゲーム感覚でクリアしていくことで、飽きることなく続けることができる。
  • (-) 日本語がおかしなところが多い。子ども向けだと翻訳も変えなければならないのだと思わされた。

ゲームっぽいところは良し悪しで、ただそのステージをクリアすることのみが目的となってしまうのがちょっとよくないところ。

スウちゃんは「コース2」から始め、現在はそれを終了しようとしている。「コース3」は日本語訳がされておらず英語のままだ。課題のところはちょっとした文章になっているから自分で理解するのは当分のあいだは無理で隣から教えてやるしかなさそうだが、せめてブロックの単語は英語で覚えてもらうことにしようかなと思っているところ。

ともかく小学2年生である現在のスウちゃんには、これがいちばん受け容れられた。

「ルビィのぼうけん」

そうこうしているあいだに、絵本「ルビィのぼうけん」がちょうど出版された(2016年5月)のでさっそく購入。スウちゃんは主人公が自分と似ているなあととても親近感を覚えて、かなり気に入ったようだ。ワークも、もともと手を動かすのが好きなので特に着せ替えなどは大いに楽しんでいる。

ただ、前に Scratch や Code.org などのビジュアルプログラミング言語を体験してしまっているためか、頭の中だけとか紙と鉛筆だけだけだとなんというか、まどろっこしいような感じらしい。もっと早い時期か、あるいは逆に高学年か中学生くらいになって概念だけを抽象化して捉えられるようになってからのほうが楽しめるのかもしれない。

まとめ

親としてもしっかり事前に構えていたわけではなかったので、いきあたりばったり的に「そういえばこれはどうだろう」と思いついたものに触れさせてみたという感じで、ここまでスウちゃんが実際に体験した順に書いてきた。

いまになって振り返ってみて、ここまでに挙げたものを「小学生が“プログラミング”入門するのに適した順番」に並べ替えてみると、

  1. 「ルビィのぼうけん」
  2. Code.org
  3. Scratch
  4. ハードウェア (IchigoJam や Arduino?)

になるだろうか。最後の項目に前後してテキスト型プログラミング言語(Python だろうか)が入るかなあ。

「子どものプログラミング」というのは流行のようで、習い事としても人気になりつつあるらしい。ちょっと調べてみただけでもいろいろな教材があって、正直言って驚いた。それでもまだ未成熟という感じもして、もう数年経てばきっと多くの事例がフィードバックされて、より洗練された言語、教材、教授法が出てくるのだろうと思った。

「プログラミング学ぶ」ではなく「プログラミング学ぶ」

さて結局のところ、小学校低学年というこの時期だと“プログラミング”といっても、言語はどれかとか具体的なコーディングとかではなく、プログラミングに通じる思考法みたいなもの、つまり

  • 論理的に考える
  • 手順をこまかく分割
  • 類型化してまとめる
  • 条件分岐を考える

というようなことを習得する、ということに尽きる。そしてそれは日頃の遊びやお手伝い(たとえば工作、お料理の手伝い……)にすぐに活かされるものだ。

そう考えると将来プログラムを組めるようになる、とかとはまったく無関係に単に「日常生活にとって大事なことを学ぶ」という、何と言うことはない普段の学校や家庭での学びと何も変わらないのだ。

だから、小学生低学年程度の子どもが“プログラミング”に接するというのは、「プログラミング学ぶ」ではなく「プログラミング学ぶ」ということ、“プログラミング”そのものが目的ではなく、ひとつの手段・道具に過ぎないのだと思う。

Debian 8 の Mailman 2.1.18 に更新したらトラブルが起きた

メーリングリスト(ML)を運用しているサーバー の OS を Debian 7 (Wheezy) から Debian 8 (Jessie) に更新しました。これにより、ML 管理ソフト Mailman のバージョンが 2.1.15 から 2.1.18 になりました。

すると ML の配信に失敗する(ML に宛ててメールを出してもどこにも配信されない。エラーも返ってこない)状態になってしまいました。OS のバージョンアップだったので、関係するソフトウェアの多くが更新されており(たとえば Bind9, Postfix, Python,…)、しばらくどこが原因かわからず途方に暮れていましたが、ようやくエラーログを見つけ出し、それを検索して調べることで解決できました。

結局のところ、この人と同じで、MLの説明などを日本語(EUC-JP)で記述していた箇所を Web の管理画面から書き直すことで、何のことはなく問題は解消しました。

こういうのはだいたい解決してしまった後に見つけるものですが、/usr/share/doc/mailman/NEWS.Debian.gz に、

mailman (1:2.1.16-1exp1) experimental; urgency=low

  This version has changed the encoding of most strings, templates
  and pages to UTF-8 to meet the Debian release goal of full UTF-8
  support in all packages. It also no longer automatically converts
  mails to ISO-8859-1.

  If you have been using any nōn-ASCII strings in places such as
  the mailing list description, these were be stored wrongly in the
  list configuration file (config.pck), so you will need to change
  those (e.g. via the webinterface) again in order to have them be
  displayed correctly.

と書いてありました。

さてメールは配信されるようになったものの、ヘッダーに DKIM-Signature: が残っていて、設定ファイル /etc/mailman/mm_cfg.py に記述していた REMOVE_DKIM_HEADERS が効いていないようです。以前はちゃんと機能していました。

これまた検索してみると、オプション from_is_list と組み合わせないと効かないようで、それと無関係に効かせようとしてもバグがあるようです。上流の新しい版では修正されているので、Mailman/Handlers/CleanseDKIM.py を差し替えました。

その上で、設定ファイルで REMOVE_DKIM_HEADERS = 2 としました。

hubot-slack アダプタ v2 から v3 へ

もう日も変わろうという時間になっても Hubot Advent Calendar 2014 の13日目が埋まっていないようなので急遽飛び込んでみます。うーん、ちっともそれ向きの話ではないかも。

hubot の Slack アダプタ がバージョン 2 から 3 (これを書いている時点では 3.1.0)になりました。これに伴って Slack 側の Hubot Integration も様変わりしています。

試しに触ってみて、気づいた点をメモしておきます。

大きく変わったこと

Slack 側の Hubot Integration

発行される token の形式が変わりました。v2 から v3 に変更すると以前のものは使えず、改めてもうひとつ Hubot の integration を追加する必要があります(以前のものはあとで不要になれば削除)。

hubot の名前はここで設定します。

チャンネルは、はじめは #general にのみ参加している状態になります(後述)。

以前にはあった Hubot URL の欄はなくなりました。自前ホストの Hubot と Slack を連携させる場合につまづく点だったのですが、なくなりました。ということは、Hubot を動かすサーバーはたとえ NAT 越しの LAN の中でもよくなりました。テストのとき便利です。

環境変数はひとつ

Hubot 側で設定する環境変数は、上記の token の HUBOT_SLACK_TOKEN のみになりました。HUBOT_SLACK_TEAM は不要となり(たぶん token にその情報が含まれるのでしょう)、HUBOT_SLACK_BOTNAME も不要になりました(上記のように Slack 側で設定)。

名簿に現れるようになった

以前は名簿に現れず隠れメンバーのようなものでしたが、v3 ではまるで一般メンバーと同等の扱いです。従ってその名前をちゃんと設定しておく必要があり、それが Hubot Integration で行うものです。

一般メンバーに対して行うように、ダイレクトメッセージを送ることができます。名簿で hubot の名前をクリックするとその画面になりますが、ここではいつものように hubot ping と bot 名を前置せず、単に ping と入力するとちょうどいいという形になります。

参加チャンネル

はじめ、hubot は #general のみに参加している状態です。ほかのチャンネルに招待( /invite @hubot )すれば、そこに参加させることができます。プライベートグループにも参加させることができます。

これまで使っていたスクリプトが動かなくなるなどの影響について

今後更新されるかもしれませんので、あくまでこれを書いている時点の問題です。

【追記】2014年12月17日現在の最新版 3.2.0 で、下記のアットマーク問題とURL問題は解決されているようです。したがって以下のパッチは不要です。【追記終わり】

robot.messageRoom での room 名

これまでのバージョンでは Readme にも

Slack API uses channel ID’s by default, which uses computer-friendly alphanumeric ID. To use the pretty names, prefix it with a hash.
  robot.respond /hello$/i, (msg) ->
    robot.messageRoom '#general', 'hello there'

と書かれており、room 名にハッシュ(#)を付けることになっていました。

v3 ではちょうど逆になって、ハッシュ(#)を付けないようになりました。これが付いていると正しく動作しません。

たとえば現時点の hubot-rss-reader が引っかかりました。

アットマーク付きbot名に反応しない

これまでは、bot 名の前にアットマーク(@)があってもなくても、また後ろにコロン(:)またはカンマ(,)があってもなくてもよかった、つまり

hubot ping
hubot: ping
@hubot ping
@hubot: ping

はいずれもhubotへの命令として有効だったのですが、v3になってなぜか@付きが無効になっています。不具合だと思われますので、早晩解決するでしょう。

対策

プルリクエストされているパッチに、さらにコロンとカンマのところを修正して適用してみました(下記)。

URLをパラメーターにすると括弧がついてしまう

たとえば hubot-rss-reader

hubot add http://example.com/index.rdf

みたいにして使うのですが、自動的に hubot add 〈http://example.com/index.rdf〉 のように山括弧( 〈 と 〉 )が付加されたものが bot に渡されるため、スクリプトがこれを URL と認識しない、ということになってしまいます。

v2 にはこれに対する処理があったのですが、v3ではすっかりなくなっています。不具合だと思うのですが、開発者は割と悠長な構えに見えます。

対策

v2 にあった処理を持ってきて適用してみました。なにか不都合があるのかなあ。

attachment が使えなくなった

この機能を使っていないので詳しいことは述べません。さっそく別のスクリプト hubot-slack-attachment ができているようです。

Hubot で docomo 「雑談対話」API を使う — “敬称”を Hubot コマンドに

これは Hubot Advent Calendar 2014 の 5 日目の記事です。が、その流れにうまく乗れているのかいないのか。1週間ほど前に自分の書いた「Hubot ping の日本語化」に引き続き、Hubot を日本語で楽しく使おうという話です。Advent Calendar の前日(4日)の記事の最後のほうでも、メッセージを日本語化するとより親しみがわく(あるいは腹が立つ)というお話でしたね。

さてさて、存在確認(ping)以外にもう少し会話的なものを楽しみたいのですが、大量の質問と答を仕込むのは労力の割に楽しくなさそうだし、人口無能みたいなものを組み込むのはこちらの技量からして難しいし……と考えあぐねていたところに、docomo Developer support 提供のAPI「雑談対話」というものを見つけました。しかもちょうど開発用APIキー有効期間の制限が廃止され、特に本申請をせずともよくなりました。

hubot-docomo-dialogue をつくった」を参考にしました。そこでは、すべての発言に反応するよう

...
  robot.hear /.*/, (res) ->
...

となっていました。しかし、これではまじめな話をしているところに割り込んできてうっとうしいので robot.respond にしたいところです。さりとて、コマンドを日本語化したとしても

user> わぷー 雑談 今日は寒かったね。

というのも無粋というか興ざめです(「わぷー」というのは bot の名前です。hubot の起動時に bin/hubot --name wapuu --alias わぷー として起動して、日本語名を与えています)。

“敬称”をコマンドに

ちょっと思案して、敬称の「さん」をコマンドにしてみました。

...
  robot.respond /さん(?:、)?\s*(.*)/, (res) ->
...

使用する時は、bot名とコマンドのあいだの空白は実はなくても大丈夫なので、

user> わぷーさん、今日は寒かったね。

と、ずいぶん自然な文体にすることができます。「わぷー」がbot名、「さん、」がコマンド、「今日は寒かったね。」が処理に渡されるパラメータと解釈されます。

Hubot のほかのちゃんとしたコマンドのときは呼び捨て、雑談したいときは「さん」付け、と使い分けることになります。

Wikipedia「敬称」にあるものを適当に詰め込み、読点をつけてもつけなくてもいい(ただし呼び捨てに読点を付けると雑談になる)ようにしました。

雑談対話 API

雑談対話と知識Q&A雑談対話 API には“会話の継続”というものがあります。いったん言葉(リクエスト)を投げかけ、返答に含まれる「コンテキストID」を次のリクエストにつければ継続的な対話になるというものです。この機能も組み込むことにしました。これでしりとりもできるようになりました(「わぷー、りんご」みたいにいちいち呼びかけなければなりませんが)。そして、2分あいだをあけると継続としないことにしました。

できた script は

です。

試してみましたが、しりとりは確かに上手にできます。しかし継続対話は期待ほどではなく、的外れなものになりがちでした。API の向こう側の対話能力は今後バージョンアップされるのでしょうか。

同様の docomo API 「知識Q&A」を利用するための docomo-knowledge.coffee も作ってみました。

こちらも試してみましたが、うーん、あんまり実用的な答は返ってきませんね。

user> わぷー教えて、ロスはいま何時?
wapuu> ロサンゼルスの今の時刻は15時35分です。

がちょっと便利なくらいです。

Hubot ping の日本語化 — 「いるのか?」の正規表現

Hubot の ping コマンド

hubot_wapuuSlack というコミュニケーションツールを利用することになって、そこでこれは便利かもということで Hubot をいじってみています。

現時点での安定版 Debian Wheezy に Hubot をインストールするにはどうすればいいんだとか、Slack に連携させるときに Heroku を使う方法ならすぐに見つかるが、自前ホストのHubotとSlackを連携させるにはどうするんだとか、いくつか引っかかりながらも、ここにリンクした情報が既にあったのでうまくいきました。

この bot がちゃんと作動しているかどうか反応を見るのに、ping というコマンドがはじめからサンプルとして付属しています。bot の名前に ping と付けて問いかけると、PONG と答えるというものです。

user> hubot ping
hubot> PONG

さて、「HubotのScriptを翻訳するとかわいい」にありますように、日本語化すると愛着がわきます。ping の Script はとても簡単で、肝は

  robot.respond /PING$/i, (msg) ->
    msg.send "PONG"

です。使用目的はとにかく存在確認ですから、日本語にすると

  robot.respond /いるのか\?$/i, (msg) ->
    msg.send "はい、ここにいます!"

です。

また、Hubot を起動するときに bot 自身の名前と別名を付けることができます。そこでこれを日本語で

bin/hubot --name wapuu --alias わぷー

と付けてやると、ますます親しみがわきます。これで応答は

user> わぷー いるのか?
wapuu> はい、ここにいます!

となりました。

「いるのか?」のバリエーションの正規表現

このままですと、script の質問文のところは正規表現で書けるのに、ただ「いるのか?」に正確にマッチしないと返答しないということになっています。

「いるのか?」の分解存在確認の日本文「いるのか?」を考察してみます。これを4つ(疑問符を入れると5つ)に分けて、それぞれのバリエーションとその組み合わせを思いつくまま挙げてみました(図)。ありえない組み合わせ—たとえば、2段目が「ります」のとき、その前に「い」はありえない—の制限を付け加えながら、正規表現にして書いてみると、次のようになりました。

/(((い|ゐ|居)(て?))(?!り)|(お|を|居)|((い|居)(て?)は)(?!ま))((る|ん(?=の))|((り?)ます)(?!ん))((の?ん?)(です)?|(んだ)(?!か))?(か(い?な?|よ|ね)?|(よ?)(ね|な))?\s?(\?|?)/

これで、質問文は「いる?」から「いてはりますのんかいな?」(いや、これが現実にありうる表現かどうか確証は持てないのですが)まで対応できます。

ping の目的は存在確認なので、日本語では「生きてる?」とも言いそうです。1段目の前に「生きて」を付けて、元の1段目を必須から任意に変更すればよさそうです。さらに、「調子どう?」「元気?」というフレーズもよく使いそうですね。これはもうそのままということにします。だんだん手抜きになってきました。

結局、日本語版 ping はこうなりました。

  robot.respond /(((い|ゐ|居)(て?))(?!り)|(お|を|居)|((い|居)(て?)は)(?!ま))((る|ん(?=の))|((り?)ます)(?!ん))((の?ん?)(です)?|(んだ)(?!か))?(か(い?な?|よ|ね)?|(よ?)(ね|な))?\s?(\?|?)/i, (msg) ->
    msg.send "はい、ここにいます!"

  robot.respond /(い|生|活)きて(((い|ゐ|居)(て?))(?!り)|(お|を|居)|)?((る|ん(?=の))|((り?)ます)(?!ん))((の?ん?)(です)?|(んだ)(?!か))?(か(い?な?|よ|ね)?|(よ?)(ね|な))?/i, (msg) ->
    msg.send "はい、ここにいます。"

  robot.respond /(調子どう|元気)/i, (msg) ->
    msg.send "はい、元気です。"

wapuu_pingちゃんと数えていませんが、これで「いるのか?」を意味する数十種類の表現に答えることができるようになりました。

このWapuu bot は、WordPress の日本語コミュニティがこれから活用していこうとしている Slack にいます。WordPress 本体の開発元でこの Slack を使っていくことになったことに触発され、そこに収まりきれない話題—日本語圏特有の話題、日本語で話したほうが楽な話題など—を扱っていこうという場所です(たぶん)。単に「WordPressの使い方」を尋ねるような場所ではありませんが、何かちょっとでも手助けしたい(日本語圏で最も求められているのはたぶん翻訳です。本体のみならず多くのドキュメントやニュースなどが翻訳されるのを待っています。もちろんほかにも何かがあります。たとえばこの記事のように、どうでもいいような冗談を仕込むとかもきっと)と思っている方があればぜひ参加してみてください。参加資格などなく、参加方法の手続きを踏めさえすれば誰でも参加できます。Wapuu bot はそこで待っています。

リモートに置いてある音楽ファイルをローカルPCのスピーカーで鳴らす

以前に「インターネットラジオを FM ラジオで聴く」というのを書きました。少し離れた場所にあるマシンにFMトランスミッターを付け、目の前のPCから操作する(そしてFMラジオで聴く)というものでした。

それから月日は流れ、ハードウェアを入れ換えたり、その際にOSもすっかりインストールし直したりしているうちに、そのリモートのマシンでの音声出力ができない状態になってしまいました。

そこで前回とは逆に「リモートに置いてある音楽ファイルをローカルPCのスピーカーで鳴らす」というのが、今回やりたいことです。目新しいことは何もなく、既に情報がどこかにあったので楽でした。自分のためのメモも兼ねてここに書いておきます。

先にまとめておくと、

  • リモート
    • 音楽ファイルが置いてある
    • Pulseaudio
    • MPD
  • ローカル
    • スピーカーが接続されている
    • Pulseaudio
    • gmpc

という構成になります。

Pulseaudio

ここではリモートもローカルも OS は Debian (これを書いている時点での安定版)です。

まず、ローカルで

sudo apt-get install pulseaudio
と pulseaudio をインストールし、

paplay local-sample.ogg

などとやってちゃんと動いていることを確認します。ところがここで音が出ませんでした。

sudo apt-get install pavucontrol

とやって pavucontrol で、「出力装置」を見ると、ポートが「HDMI」になっていました。ここの環境ではそこにスピーカーはなく、USBポートにサウンドアダプタを挿してその先にスピーカーがある状態です。「設定」で、GF108 High Difinition Audio Controller が HDMI になっているので、これを Off にすると、「出力装置」のポートが「スピーカー」または「デジタル出力(S/PDIF)」になって、音が出るようになりました。

リモートとローカルの Pulseaudio の設定

ローカルの /etc/pulse/default.pa で、

load-module module-native-protocol-tcp auth-ip-acl=192.168.1.0/24

リモートの /etc/pulse/client.conf で、

default-server = 192.168.1.xxx (スピーカーのあるPC)

とします。必要に応じてローカルのポート 4713 を開けます(今回のローカルPCはファイアーウォールを置いていないので特に設定の必要なし)。

テストとして、リモートで

paplay remote-sample.ogg

などとやるとローカルのスピーカーが鳴ります。

MPD

当初の目的は達成されましたが、このままでは不便なので、MPD を使うことにします。これは音楽再生やプレイリスト管理をリモートから行うためのものです。

リモート

まず

sudo apt-get install mpd

でインストールします。/etc/mpd.conf で、music_directory に音楽ファイルの置いてあるディレクトリを設定し、bind_to_address に接続を許すアドレス(今回は(LAN内の)どこからでも接続できるよう “any” としました)を設定します。

出力先の設定は

audio_output {
        type            "pulse"
        name            "My Pulse Output"
#       server          "remote_server"         # optional
#       sink            "remote_server_sink"    # optional
}

とします。ここで mpd を再起動します。

ローカル

ローカルPCには、gmpc をインストールして使います。これは高機能で、細かな設定やプレイリストの管理を行うことができます。ふだんは、再生/ポーズ/停止くらいの操作しか必要ではないので、シンプルな xfce4-mpc-plugin をパネルに置いてこれを使うことにします。

sudo apt-get install gmpc xfce4-mpc-plugin

どちらも、ホストとして MPD を動かしているリモートのマシンを指すように設定します。