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 としました。

6÷2(1+2)問題あらため2a÷2a=1問題 — はてなブックマークのコメントに反応してみる

前の記事『「6÷2(1+2)」問題について教育委員会に問い合わせてみた』は、予想以上に多くの人の目に触れたようです。自分のブログでこれほど読まれた記事は過去になく、これまで「はてなブックマーク」というものを気にしたことはありませんでした。今回はそこから導かれてくる人もけっこうあるようなので見てみましたら、そこにいくつかのコメントがありました。言いっぱなしで、それについての反応を期待されていないものとは思いますが、あえて応えてみます。

「6÷2(1+2)」というタイトルについて

最近よく見かけていた「6÷2(1+2)」をタイトルに持って来ましたが、私はその本質を、それが数字だけの式だからというより、『「記号の省略されたかけ算」と「記号の明記されたわり算」の優先順位』の問題だと思っていました。ですから「2a÷2a=1 問題」とでも言ったほうが誤解が少なかったかもしれません。念のため付け加えますが、「÷」を「/」と書いて「2a/2a」でも同じ問題があると思っています。つまり私にとっての関心は、数字か文字かということではなく、「÷」という記号でもない、ということです。

「中学数学もろくに……」について

むしろ中学数学しか知らなければ「2a÷2a=1」に疑問を感じないのかもしれません。そこから先に、高校や大学で数学や物理に触れる機会が増えるほど、この表記を疑わしく感じるのでないかと思います。

私自身がいつからそう思うようになったか、というはじめのところは覚えていませんが、大学のときにその混乱に遭遇したことは覚えています。

1/xy のような簡素なものなら 1/(xy) の意味かと思いやすいかもしれません(それでも疑わしく考えますが)。それよりもやや複雑な k/2(x2+y2+z2) のような形を教科書だか論文だかで目にしました。紙幅を節約するためか、TeXでいう「ディスプレイ形式」ではなく、1行に収めるように表記されている場合、しかも k と 2 の間の線が水平ではなく斜めになっている場合に、この不安が呼び起こされます。そしてこの (x2+y2+z2) は分子の側だっけ、分母の側だっけ、と数ページ前にさかのぼってこの式の導出されるところを確認しなければならないことになります。ゼミのような場面で読み合わせているときにもそれは起こったので、私だけではなくそこに居合わせた学生のみならず教官も含めて、こんなあいまいな書き方はよくないよね、というのがその場での共通認識でした。

中学より後の数学に触れたことのある人で、「2a/2a は 1 か a2 か」と問われて「1 に決まってる」という人はまずいないだろうと思います(私自身が調査をしていませんので断言はしませんが)。はてなブックマークのコメントで「明白だ、中学数学もろくに……、算数できない人……」という人(星を付けた人も含めて)が、いまなぜこれほどいるのか不思議でしかたありません。

「明白」について

私は、

  1. かけ算とわり算の優先順位は同列である
  2. かけ算の記号(×)は省略できる。ab は a×b と同じ
  3. 2a÷2a=1 である

の3つは同時には成り立ち得ない、と理解しています。(1)(2)を前提とするならば、2a÷2a は a2 にしかなりません。

(3)が成り立つと主張する人は、(1)や(2)を否定、つまり、

1′. かけ算の記号を書いたときと省略したときでは意味が違い、省略されたかけ算は明記されたものより優先順位が高い

というルールをいつのまにか導入しています。そうでなければ、どうにも 2a÷2a は 1 になりません。

この(1′)は、学習指導要領や教科書、指導書などに明記されているでしょうか? おそらくないでしょう。(3) を持ち込みながら、一方では (1)(2)を否定しないふりをしている、という姑息な状態になっています。

さてついでに、

というコメントですが、どうもこの人たちの中では、2a は単項式で 2×a は多項式のようです。意味が通じません。

何を測る問題なのか

はてなブックマークのコメントで有益なものはありませんでしたが、そのページからのリンクで発見した『Raccで「6÷2(1+2)」』の後半には、たいへん示唆に富む情報がありました。

https://twitter.com/metameta007/status/576296729949044736から始まる一連のツイートについて,情報源を調べてみました.

自分では探そうともしていなかったので、ありがたい情報です。このような資料を示されると、自分の考えをいくらか改めなくてはならないかもしれません。

しかし、現在においても

  • (1′)が提唱されていたが、数学の世界にひろく浸透していない
  • そのため大抵の人は、紛らわしさを回避するため括弧を使うなど、このルールによる表記法を避けている
  • そのため、ますます(1′)は浸透しない

という状況だと推測します。

「提唱されてはいるが評価が定まっていない」「信用できない」「誤解を招くため書くことがためらわれる」ようなものが入試問題として適切かという懸念は、それでも残ります。上に引用したブログの方は学習指導要領(解説)も調べているようですが、(1′)はあからさまには記述されていないようです。それはなぜかということも気になります。

この設問(簡単に 2a÷2a と書きます)は、何を計測しようとしていることになるのでしょうか。『「単項式を単項式で割る」を理解しているか』を見るつもりなら、2a÷(2a) のように括弧を付けてもその目的を達することができます。曖昧さが排除されているので、今回取り上げたような問題は起こりません。

やはり、入試問題としては不適切と言わざるを得ません。

【2019年2月4日追記】

この記事へのコメントは非常に長大になり、今後この記事を目にする人たちにとっては苦痛とも言えるほどになってしまいました。そのため、この記事へのコメントの受付は2019年2月4日をもって停止します。自由に意見を述べることを封殺する意図はありません。後にここを目にする人たちに対しての配慮です。ご理解ください。

この話題の続編とも言える記事が『「6÷2(1+2)」問題は100年前にも議論されていた』にあります。そちらにコメントしようとする場合は、ここに既にあるコメントと内容的に重複しないよう、慎重に考えた上でお願いします。

「6÷2(1+2)」問題について教育委員会に問い合わせてみた

厳密には「6÷2(1+2)」ではなくて、数字の部分が文字になっているものですが。「かけ算の順序問題」のように、呼びやすい名前があるといいのですが、そうでもないので、最近よく目にする「6÷2(1+2)」をタイトルにしてみました。

さて本題。

記号が省略されたかけ算と、明記されたわり算の優先順位については、検索すればいろいろ見つかります。最近では「6÷2(1+2)=1 or 9 まとめ」など。私は、そのまとめのコメント欄にも登場している黒木さん(過去のtweet)にまったく同意するものです。

入試問題

mondaiそんな中ちょうど、新聞で高校入試の問題を目にしました(画像は試験当日の夕刊)。そこにまさにこの問題が出ていたのです。1(1)ウがそれです。

問い合わせてみた

そこで、これを実施した県教育委員会にメールで問い合わせてみました。

---------------------------------
質問1
新聞では「解答例(県教委)」として本設問の答が「6a」となっていた。これは県教委が発表したものに間違いないか?

質問2
その答は、『「記号の省略されたかけ算」は「記号の明記されたわり算」より優先する』を前提としたときに導かれるが、この理解で正しいか?

質問3
そうだとすると、『「記号の省略されたかけ算」は「記号の明記されたわり算」より優先する』の根拠は何か? できれば典拠を示していただきたい。

質問4
数学において『「記号の省略されたかけ算」は「記号の明記されたわり算」より優先する』は常識ではない。すると本設問の答は「6 a^5 b^4」でもあり得る(ここで ^ はべき乗)。これも正解としないのか?

質問5
以上のように本設問はあいまいであり、入学試験問題としては不適切である。見解を伺いたい。
---------------------------------

回答があった

翌日にさっそくPDFファイルが添付されたメールで回答がありました。PDFといっても、1枚の画像そのままです。PDFにしている意味がよくわかりません。

回答の内容を書き写すと、

  • 答えは、県教委が発表したもので間違いありません。
  • 中学2年の数学『単項式の乗法、除法』において学習しています。
    • (教科書(啓林館)の例)
    • 「平成26年度 全国学力・学習状況調査」の出題例
  • 以上のように、中学校での学習や国の調査問題でも指導されております。このことから、学力検査問題として適切なものと考えております。

ということでした(式の部分はここに書き写すのが難しいのでPDFファイルを見てください)。

これから

こちらからの質問4、「これは数学においては常識ではない」がちょっと弱かったなと反省しています。自分でもそうは思っていたのですが、なるべく早く問い合わせたほうがいいと考えたので、じっくり考えて書く暇がなかったのでした。今回の回答のような“逃げ”を打たれないように、もう少し裏打ちのある根拠をこちらから挙げて聞くことができればよかったと思っています。このへん、どのような質問にすれば有効か、お知恵がありましたらコメントをいただければさいわいです。

ネットでああだこうだ言っていても、それだけで中学校の授業や高校入試の状況に影響を与えるのはなかなか難しいでしょう。しかし、高校入試というのはたいへんいい機会です。今回のように新聞に発表されますし、問い合わせれば出題ミスの可能性がある限り、まじめに検討して回答せざるを得ません。多くの問い合わせがあれば、各教育委員会からさらに本省のほうへ問い合わせが行くようになるかもしれません。少なくとも今回のような問題は「悪問」として、入試では避けよう、となるかもしれません。

何もしないよりはましだろうとまずは行動してみたよ、というお話でした。

【2019年2月4日追記】

この記事へのコメントは非常に長大になり、今後この記事を目にする人たちにとっては苦痛とも言えるほどになってしまいました。そのため、この記事へのコメントの受付は2019年2月4日をもって停止します。自由に意見を述べることを封殺する意図はありません。後にここを目にする人たちに対しての配慮です。ご理解ください。

この話題の続編とも言える記事が『「6÷2(1+2)」問題は100年前にも議論されていた』にあります。そちらにコメントしようとする場合は、ここに既にあるコメントと内容的に重複しないよう、慎重に考えた上でお願いします。

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

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

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 はそこで待っています。

昨年のクリスマスプレゼント「ビルダーキット テクノ ツールボックス」

今年もそろそろサンタクロースの代理としてクリスマスプレゼントを考えなければならない時期になりました。昨年のプレゼントを思い出してみますと……。

当時5歳のスウちゃん(仮名)に届いたのは、Quercetti の「ビルダーキット テクノ ツールボックス」。しばらく前から、大人がちょっとした家具を組み立てたり自動車のタイヤを交換したりするときに「スウちゃんも!」とスクリュードライバーやスパナを持ちたがるので、こういうものにしてみました。

難易度はそれほど高くなく、前年(4歳)の Zometool と順番が逆だったかなという感じも少ししましたが、これはこれで非常に楽しんでくれました。

簡単な作成例(完成図のみ)の冊子が付いていて、はじめはそれをまねて作っていました。徐々にオリジナルの車や、収納箱の蓋(たくさん穴が開いていてネジがきってある)に平面状に絵を作ったり。

場所によって適切な長さを選ぶとか、その頭のミゾに合わせて工具を変えるとか、さらにナットを締めるときに反対側のボルトも工具で押さえておかなくてはならないというような、どうかすると大人でもうっかりしそうな技を習得しつつあります。

プラスチック製のボルトとナットで(ほかのパーツや工具もすべて)、車のハンドルなど可動部はすぐに緩んできてしまうのがやや難ですが、逆にこれがきっちり締まるようになっていると、幼児の手ではとれなくなってしまうのかもしれません。