Rhythmbox を DLNA クライアントとして使う

何を今さらというような内容かもしれませんが、ちょっと苦労したのでメモしておきます。

やりたいことは以前書いた「リモートに置いてある音楽ファイルをローカルPCのスピーカーで鳴らす」と同じです。あれから時間が経ってまたまた環境がずいぶん変わってしまいました。現在は宅内のリモートマシンで DLNAサーバー (Debian の minidlna パッケージ) を動かしており、それから手元の PC で何らかの手段で音楽を聴きたいのです。

手元の PC (OS は Debian testing です) にはインターネットラジオを聴くのに Rhythmbox がインストールされていて (Debian パッケージで言うと rhythmbox と rhythmbox-plugins)、これで DLNA を使えればいい訳で、検索してみると Ubuntu 情報ですが、パッケージ grilo-plugins-0.3 と libgrilo-0.3-0 を追加インストールすれば左欄に DLNA サーバーが現れるかその一番下の + でサーバーが見つかるようになる……はずなのですが、ぜんぜん反応しません。

なかなか手がかりがなく困り果てていたのですが、ふと

(rhythmbox:16045): Grilo-WARNING **: [dleyna] grl-dleyna-servers-manager.c:138: Unable to fetch the list of available servers: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.intel.dleyna-server was not provided by any .service files

の警告 (エラーではないのであまり気にしていなかった) の中のキーワードから、dleyna-server という Debian のパッケージを追加したら、無事に左欄の「共有」のところに DLNA サーバーが現れました。

結局、必要なのは

  • rhythmbox
  • rhythmbox-plugins

  • grilo-plugins-0.3

のほかに

  • dleyna-server

でした (依存関係でそのほかいくつか)。

しかし、dleyna-server に言及している情報にほとんど行き当たらなかったのはどうしてだろう……。

dvipdfmx の map の置き場所

TeXLive 2016 から 2017 での変化なのか、Debian 固有の問題なのかわからないが、メモ。

LaTeX から PDF を作るのに dvipdfmx を使っている。いまどきは、はじめから pdfLaTeX とか LuaLaTeX を使うのだろうが、もう10年ほどもこの方法で、スクリプトにしてやっているからそのままだ。

つい最近、Debian Testing (Buster) でパッケージを更新したら TeXLive が 2016 から 2017 になったようで、dvipdfmx でフォントを埋め込む際に参照する map ファイルが見つけられず PDF を作れなくなってしまった。map ファイルは /etc/texmf/dvipdfmx/ 以下にある。

調べてみると、/usr/share/texlive/texmf-dist/web2c/texmf.cnf で、以前も今も

TEXMFSYSCONFIG = /etc/texmf

は変わらないが、

TEXMF = {$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFDEBIAN,!!$TEXMFDIST}

TEXMF = {$TEXMFAUXTREES$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDEBIAN,!!$TEXMFDIST}

になり、

TEXMFDBS = {!!$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFDEBIAN,!!$TEXMFDIST}

TEXMFDBS = {!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDEBIAN,!!$TEXMFDIST}

に変更されていた。要するに $TEXMFSYSCONFIG に !! が付き、それが $TEXMFDBS に含められている。

対処としては texmf.cnf の設定を以前と同じようにすればいいのかもしれないが、/etc/texmf/ls-R を (mktexlsr で) 作成すれば、すんなり元のように PDF を作れるようになった。どちらのほうがいいのだろう。

環境変数 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 にあった処理を持ってきて適用してみました。なにか不都合があるのかなあ。

--- slack.coffee.orig 2014-12-13 17:53:24.290393342 +0900
+++ slack.coffee 2014-12-13 19:42:08.788464223 +0900
@@ -8,6 +8,7 @@
constructor: (robot) ->
@robot = robot
+ @botUserID = null
run: ->
# Take our options from the environment, and set otherwise suitable defaults
@@ -44,6 +45,13 @@
loggedIn: (self, team) =>
@robot.logger.info "Logged in as #{self.name} of #{team.name}, but not yet connected"
+ # Go through the list of known users and find the name that matches ours
+ for id, user of @client.users
+ if user.is_bot and user.name == self.name
+ @botUserID = id
+ break
+ @robot.logger.info "Bot's Slack user ID is #{@botUserID}"
+
# Provide our name to Hubot
@robot.name = self.name
@@ -103,6 +111,11 @@
# If this is a DM, pretend it was addressed to us
if msg.getChannelType() == 'DM'
txt = "#{@robot.name} #{txt}"
+ # Or, if we were @-mentioned
+ else if matches = txt.match(/<@([^>]+)>[:,]?\s?(.*)/)
+ [userID, someText] = matches[1..2]
+ if @botUserID and (userID == @botUserID)
+ txt = "#{@robot.name} #{someText}"
@receive new TextMessage user, txt, msg.ts
view raw atmark.patch hosted with ❤ by GitHub
--- slack.coffee.orig 2014-12-13 17:53:24.290393342 +0900
+++ slack.coffee 2014-12-13 17:53:51.421673532 +0900
@@ -61,6 +61,24 @@
@client.removeListener 'close', @.close
@client.removeListener 'message', @.message
+ ###################################################################
+ # HTML helpers.
+ ###################################################################
+ unescapeHtml: (string) ->
+ try
+ string
+ # Unescape entities
+ .replace(/&amp;/g, '&')
+ .replace(/&lt;/g, '<')
+ .replace(/&gt;/g, '>')
+
+ # Convert markup into plain url string.
+ .replace(/<((\bhttps?)[^|]+)(\|(.*))+>/g, '$1')
+ .replace(/<((\bhttps?)(.*))?>/g, '$1')
+ catch e
+ @robot.logger.error "Failed to unescape HTML: #{e}"
+ return ''
+
message: (msg) =>
return if msg.hidden
return if not msg.text and not msg.attachments
@@ -96,7 +114,7 @@
else
# Build message text to respond to, including all attachments
- txt = msg.getBody()
+ txt = @unescapeHtml msg.getBody()
@robot.logger.debug "Received message: '#{txt}' in channel: #{channel.name}, from: #{user.name}"

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分です。

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