DoSPOT 設置をあきらめる

ずっとデスクトップ PC の前に座っている生活なので無線 LAN はあまり考えていませんでしたが、最近 Nexus7 を手に入れたので、これまた数年前に入手していた無線 LAN ルーター WN-G300DGR を置いて使ってみていました。まあ特に支障はありません。

そこへ「DoSPOT」の営業の電話がかかってきました。DoSPOT というのは、客側から見ると、時間・回数制限付きの公衆無線アクセスポイントということになります。また、「フレッツ・スポット」のユーザーなら制限なしに利用できます。設置側としては、「Wi-Fi 使えます」と言えますし、「フレッツ・スポット」提供エリアとしてそのページに掲載されるという宣伝効果? が期待できます。またオーナー側に SSID (一般客には公開しない) があり、既存の無線 LAN ルーターに置き換えることができるかなと思えました。月額500円(税抜)ですが、1年間は無料というのでとりあえず OK しました。

LAN 環境

ところで現在の LAN 環境は、LAN 内部に公開サーバーを置いていたり、ネットワーク接続のプリンターがあったりという、単に外につなげればいいというだけではなくそもそも単純ではない状態です。したがって内部向けの DNS サーバーが存在し、これを参照するようにしないと自分のところの Web を内部から見ることができません。

DoSPOT ルーター

しばらくして、担当者が DoSPOT ルーターを持って「工事」にやってきました。が、設置場所の問題だの既存の無線 LAN ルーターを外したりだのややこしかったので、「設置はこちらでやるから」と言って機械だけ置いていってもらいました。DoSPOT ルーターは NEC 製 の MW-3301-R (PDF) というものでした。

さて自分で設置して設定しようとすると、MW-3301-R が上述の LAN 環境に対応できないことが判明しました。

有線 LAN ポートが足りない

まず MW-3301-R には有線 LAN ポートが2口しかありません。一方、既存の無線 LAN ルーターには3口あって、宅内にはそれを全部塞ぐだけの機器があります。増設ならともかく置き換えることはできません。すると今度は(設置場所に)電源の口が足りません。

DNSの設定ができない

MW-3301-R の設定は、それに接続した PC などのブラウザで Web 画面をとおして行います。と言っても設定を変更できるのは、オーナー向け SSID (デフォルトでは「DoSPOT-OWNER」)についてのみ。それについては DNS の設定もできるので、プライマリに内部向け DNS サーバー、セカンダリにゲートウェイ(プロバイダの DNS を代理している)を設定することで事なきを得ました。

ところが、客側が接続する SSID (「DoSPOT-FREE」や「NTTWEST-SPOT」)に関する設定は一切できないようです。DoSPOT カスタマーセンターに電話して聞いてみたところ、はじめは DNS について「オーナー向け設定と連動しているかも」との回答だったのですが、とてもそのような挙動には見えないので強くそのように言うと、数時間後に「再現テストしてみたところ連動しておらず、それらは一切設定変更できません」との回答がありました。

DoSPOT の売り文句

Point 3 店舗や施設の情報をお客様に見てもらえる

  • Wi-Fiを利用する際に店舗ホームページを表示できる
  • 店舗や施設のホームページを紹介

    お客様がDoSPOTを利用される際に店舗や施設のホームページを紹介します。

    同じことを客側から

    Point 3 店舗や施設の情報を確認できる

    • 店舗情報、クーポン、ブログなどをチェック。
    Wi-Fiを利用する際に店舗ホームページで情報をゲット!

    無料ログインの際に、店舗ホームページがある場合は表示されますので、店舗情報やクーポンのチェック、ブログなどが閲覧可能です。

    とあるのですが、これがまったく使えないということになります。

    そのほか残念なところ

    時刻の設定が、再起動のたびに元(1970年1月1日)に戻ってしまうようです。と言ってもログにもこの時刻は使われていません。何なんだろう。

    「DoDPOT-FREE」は暗号なし。うーん、そうなんだ……。

    結局使わないことに

    DoSPOT がまったくダメとは言いません。うちの環境に合わなかったというだけです。有線 LAN のポート数は事前に知ろうと思えば知ることはできました。それを見落としていたのはこちらの落ち度でした。DNS の設定については、実際に試してみるまでわかりませんでした。その手段がまったくないとは思っていませんでした。

    既存の無線 LAN ルーターかまたはそれよりちょっとだけましな、マルチ SSID のできる機器で、ひとつの SSID を自分で客用に設定してやればすむ話です。宣伝効果? は、FREESPOT マップ にでも登録すればいいかもしれません。そもそも Wi-Fi 環境うんぬんで客足に影響するような商売でもありませんし。いずれにせよ無料だからまだいいようなものの、月額料金、電気代(これは微々たるものか)を払って、こちらに何の得があるというのでしょう (いや、そういう形態の商売もあるでしょうが)。しばらく放置して、無料期間が終わるまでに解約することにしようと思います。やれやれ。

    WordPress 翻訳祭り—今さら注意してもらえない「日本語」について

    今週末、全国各地で WordPress 翻訳祭りが開催されるようです。WordPressの各言語版がどのような仕組みで実現されているか、とか、実際に翻訳作業をするアプリケーションの説明などが、あちこちに見られるようになりました。(【追記】このあと WordCamp Kansai 2014 コントリビューターデイもありますし、今後も参照されるかもしれないので若干手直ししました。)

    でも、もっとも根っこのところにある「日本語」については、日本語の話者ならもう今さら言うことはないという感じで、なかなか誰も注意してくれません。

    ふだん自分が書く日本語と違う点は、これが協調作業だということです。WordPress 本体と、テーマやプラグイン、Codex で、書き手によって文体や表現がバラバラだと、読み手に対していらぬストレスを与えることになります。ここは自分が気持ちよく書くことよりも、自分だけ外れた書き方になっていないか、に注意することが必要です。

    日本語スタイルガイド

    WordPress 本体の翻訳にあたっては、ガイドラインを定めています

    まず基本となる「日本語スタイルガイド」(簡易版の PDF) があって、そこに書かれているルールから外れる WordPress 日本語版独自のルールという形で決めています。翻訳祭りに参加される方は、ぜひ事前に目を通して、もちろん全部覚えておくことは難しいでしょうが、「あれ、どうだったっけ?」と引っかかる程度にはしておくといいでしょう。

    • 日本語の句点は全角の「。」を、読点は全角の「、」を使う。
    • 日本語には全角文字 (2 バイト文字) を使う。
    • 英数字、符号には半角文字 (1 バイト文字) を使う。(例外は句読点、鍵括弧、中黒。これらは全角文字を使う)
    • 数字は、慣習的に使われている場合を除いて、算用数字 (1、2、3) を使う。

    このあたりまでは、特に気をつけなくても大丈夫だと思います。

    以下、気をつけないと自分の癖が出てしまいそうなところを挙げてみます。

    文字間のスペース

    • 半角文字と全角文字の間には、半角文字 1 字分のスペースを入れる。ただし例外は
      • 半角文字の前後が『』 「 」 。、の場合は半角スペースを入れない。
      • 丸括弧 ( ) の外側には、全角文字がきても半角文字がきても半角文字 1 字分のスペースを入れる。
      • 丸括弧 ( ) の内側には、全角文字がきても半角文字がきてもスペースを入れない。
      • コロン : の前には半角スペースを入れない[1]
      • 半角数字の前後には半角スペースを入れない(日時など。例: 2009年5月10日12時30分48秒、1件のコメント、150ピクセル)

    です。これははじめに意識しておかないと、うっかり適当にやってしまいがちです。

    外来語カタカナ末尾の長音表記

    基本的には内閣告示第二号「外来語の表記」に従います。

    ざっくり言うと原則として、英語の語末が -er、-or、-ar のときは長音記号を付け、-y のときは長音記号を付けません。ただし例外も多くあります。

    漢字かな表記

    漢字にするかかな書きするかは

    • 原則として名詞と動詞には漢字を使い、接続詞、連体詞、助動詞、補助動詞、助詞、連語、形式名詞、接頭語、接尾語はかな書きにする。

    です。「日本語スタイルガイド」 (長いほうの PDF) の付録に一覧表があります。「してください」「すでに」「すべて」「だれも」などはかな書きです[2]

    ここまで、WordPress 本体のガイドラインを紹介しました。テーマやプラグインもぜひこれに準拠してほしいと思います。

    Codex もほぼ準拠していると思いますが(どこかにガイドラインが示されていましたっけ?)、外れているものもけっこう見られます。括弧が全角になっていたり、和文-欧文間のスペースがあったりなかったり……。今回のような催しをきっかけにこのあたりのルールも整備されればいいなと思います。

    ところで、「用語」は、WordPress 本体やテーマ・プラグインを参照して、合わせる必要があります。WordPress 本体で見かけた語が Codex では別の訳語になっていた、ではたいへん困ります。手間ではありますが、すでにある訳語を探して、合わせましょう。どうしてもそれらが間違った訳と思える場合には、それぞれの作者・翻訳者、日本語版作成チームに連絡して、連携して全体をよくしていきましょう。

    それでは、Happy translating!

    1. 「日本語スタイルガイド」に明記はされていませんが、例文によるとこうなっています。
    2. 「すべて」「だれ」がかな書きなのは、この日本語スタイルガイドが作られた時点では常用漢字にそれらが含まれていなかったからだと思います。2010年の改定で「全て」の読み「すべて」、「誰」という漢字が含まれたので、今後はこれらは漢字書きでもいいかもしれません。しかしいま勝手にそう判断しても統一がとれませんので、全体の合意が形成されるまで当面はかな書きのままとしましょう。

    Share the LOVE 分かちあい

    今年6月に開催予定の WordCamp Kansai 2014 のキーワードは「分かちあい」だそうです。

    WordCamp Kansai 2014のコピーにそっと入っている「Share the LOVE」の文字。これはWordPressのreadme.htmlにある一節で日本語版作成チームの方が「分かちあい」と訳してくださっています。(Makoさんが提案されたと聞いています)

    「分かちあい」。WordCamp Kansai 2014では、この分かちあいをテーマにしています。
    灯りをわけあうように知識を経験を、そしてこれからの未来をわかちあう。

    WordCamp Kansai 2014 開催します!

    ここに名前を挙げてもらって光栄に思うのと同時に、日本語版作成チームの皆さんの同意があってはじめてこうなっているのであって、私としては大いに照れているところです。とは言え、実は自分でも自分の案ということを何度か言ったことがあったのでした。

    この際なので、もっとじっくり掘り出してみました。

    まず大元の英語版の readme.html を見てみると、changeset 2338 で Share the Love が現れています。2005年2月のことです。これが日本語では、どういう経緯かわからないけれど「WordPress 愛用者の皆さんへ」と訳されていました。

    日本語版作成チームのメーリングリストを探してみると、2008年2月24日に、確かに私が「分かち合い」を提案していました[1]このときの変更点の一番下のあたりです。漢字かかな書きかはその後2回ほど変えて、現在の「分かちあい」にしました。

    いやあ、どんな変更があってどんな話をしていたかすっかりオープンな状態で、いつでも誰でも見られるんですね。オープンであること、自由であることが「WordPressってすごい」ところです。

    もう少しなにか気の利いたことを書けたらいいのでしょうが、WordCamp Kansai 2014 実行委員長の挨拶を読むと「WordPressってすごい」「分かちあい」に書かれていることにまったく同感なので、そちらをぜひ見てみてください。

    どこか自慢話のようになってしまったかもしれません。たかが一単語の日本語訳ですから、誰がやってもそう違いはありません。もし私がやらなくても誰かがやってくれたでしょう。でも逆に考えれば、たかがそのくらいを、たいして力のない私がやることができて、こうして WordCamp サイトオープンの挨拶で取り上げてもらえました。ああ自分じゃない誰かにいくらかでも何かを届けることができたんだな、と感じさせてもらえてとても幸せです。次は、これを目にしているあなたの番かもしれませんよ。「自分がやらなくても誰かがやってくれる」からほんの一歩だけでも踏み出してみませんか。

    ところで、share は、この界隈では「共有」という訳で広まっています。しかし私はどうもしっくりこないと感じています。ということをどこかに書いたことがあったのでした。「共有」だと「(他人と一緒ではあるけれど)自分も持つ」という意味合いが強いような気がして、それよりむしろ「配る、分け与える、ほかの人にも持たせる」というニュアンスを出せないものかと考えています。最近、Twitter も share に、というニュースも見ました。「共有」なんて訳語にならなきゃいいなと思っています。

    1. なお、ここで署名に出てくる URL はすでに手放しており、現在表示されるのはまったく無関係です。それについては「迂濶にドメイン名を手放すのはよくない」に書きました。

    pandoc の使い方メモ — 相互参照について

    やりたいことは「元の文章を markdown で複数のファイルに分割して書き、それをウェブで公開するために個々に HTML に変換したい。もう一方では印刷できるような一括した PDF を LaTeX 経由で作りたい。ついでに EPUB も作りたい」です。割とありがちなケースだと思うので、もっとすっきりした方法があるように思うのですが、うまく見つけられませんでした。

    相互参照とは、HTML では id 属性と a タグで実現されるもの、LaTeX では \label{}\ref{} で表現されるものです。

    索引は、LaTeX では後で処理するために \index{} で印を付けておくものです。HTML と EPUB では使いません。

    例を挙げます。

    a.md
    
    はじめに {#hajimeni}
    ========
    
    ...
    
    用意するもの
    ============
    
    ...
    
    道具 {#dougu}
    ----
    
    * 包丁
    * まな板
    * ...
    
    これらは[「下ごしらえ」](b.html#shita)で使います。
    
    * 大きな鍋\index{おおきななべ@大きな鍋}
    * ...
    
    これらは[「調理」](b.html#chouri)で使います。
    
    材料 {#zairyo}
    ----
    
    ...
    
    
    b.md
    
    手順
    ====
    
    下ごしらえ {#shita}
    ----------
    
    ここで使う材料は[「材料」](a.html#zairyo)にまとめてあります。
    ...
    
    調理 {#chouri}
    ----
    
    ...
    大きな鍋\index{おおきななべ@大きな鍋}([「道具」](a.html#dougu)を参照のこと)を使います。
    ...
    
    盛り付け {#moritsuke}
    --------
    
    おわりに
    ========
    
    ...
    
    
    

    という文書が元になります。

    HTML

    a.md → a.html, b.md → b.html のように個々のページを独立して生成することにします。それを見越して、md ではリンクの書式のところにこれらのファイル名を入れておきます。

    md を pandoc

    pandoc -o a.html a.md
    pandoc -o b.html b.md
    

    と処理すると

    a.html
    <h1 id="hajimeni">はじめに</h1>
    <p>...</p>
    <h1 id="用意するもの">用意するもの</h1>
    <p>...</p>
    <h2 id="dougu">道具</h2>
    <ul>
    <li>包丁</li>
    <li>まな板</li>
    <li>...</li>
    </ul>
    <p>これらは<a href="b.html#shita">「下ごしらえ」</a>で使います。</p>
    <ul>
    <li>大きな鍋</li>
    <li>...</li>
    </ul>
    <p>これらは<a href="b.html#chouri">「調理」</a>で使います。</p>
    <h2 id="zairyo">材料</h2>
    <p>...</p>
    
    b.html
    <h1 id="手順">手順</h1>
    <h2 id="shita">下ごしらえ</h2>
    <p>ここで使う材料は<a href="a.html#zairyo">「材料」</a>にまとめてあります。 ...</p>
    <h2 id="chouri">調理</h2>
    <p>... 大きな鍋(<a href="a.html#dougu">「道具」</a>を参照のこと)を使います。 ...</p>
    <h2 id="moritsuke">盛り付け</h2>
    <h1 id="おわりに">おわりに</h1>
    <p>...</p>
    

    ができます。LaTeX の索引のために挿入しておいた \index{} は無視されるので、特に気にすることはありません。

    LaTeX 経由 PDF

    ソースは複数ファイルに分割されていても最終的な成果物はひとつであってほしいため、main.tex を用意しておき、

    main.tex
    \documentclass[a5paper]{jarticle}
    \usepackage[dvipdfmx]{hyperref}
    \usepackage{makeidx}
    \makeindex
    \begin{document}
    \tableofcontents
    %
    \input{a}
    \input{b}
    %
    \printindex
    \end{document}
    

    これから dvi を作り、さらにそれから pdf を作ることにします(pandoc から PDF を出力させることもできるようですが、日本語のとおる環境を設定したり次に述べる処理を挟んだりするのがやりにくいので、こういうやり方にします)。

    さて、ここで読み込まれる a.tex, b.tex を md から pandoc で生成するのですが、単純にやるだけでは、HTML 向けに書いていたリンクのところが

    これらは\href{b.html\#shita}{「下ごしらえ」}で使います。
    

    のようになってしまいます。これではよろしくないので、

    sed 's/\(\[[^\]*\]\)[\(][^#]*\(#[^\)]*\)[\)]/\1(\2)/g' a.md \
    | pandoc -t latex \
    | sed 's/\(\\hyperref\[\([^\]*\)\]\)[\{][^\}]*[\}]/\1\{\\ref\{\2\}\}/g' \
    > a.tex
    

    のようにします。バックスラッシュと括弧だらけでわかりにくいですが、前段の sed

    [「下ごしらえ」](b.html#shita)
    

    [「下ごしらえ」](#shita)
    

    のように、丸カッコ内のファイル名相当の部分を削除します。これで生成物の当該部分は

    \hyperref[shita]{「下ごしらえ」}
    

    となるので、後段の sed でこれを

    \hyperref[shita]{\ref{shita}}
    

    のように書き換えます。

    これにより、生成物は

    a.tex
    \section{はじめに}\label{hajimeni}
    
    \ldots{}
    
    \section{用意するもの}\label{ux7528ux610fux3059ux308bux3082ux306e}
    
    \ldots{}
    
    \subsection{道具}\label{dougu}
    
    \begin{itemize}
    \itemsep1pt\parskip0pt\parsep0pt
    \item
      包丁
    \item
      まな板
    \item
      \ldots{}
    \end{itemize}
    
    これらは\hyperref[shita]{\ref{shita}}で使います。
    
    \begin{itemize}
    \itemsep1pt\parskip0pt\parsep0pt
    \item
      大きな鍋\index{おおきななべ@大きな鍋}
    \item
      \ldots{}
    \end{itemize}
    
    これらは\hyperref[chouri]{\ref{chouri}}で使います。
    
    \subsection{材料}\label{zairyo}
    
    \ldots{}
    
    b.tex
    \section{手順}\label{ux624bux9806}
    
    \subsection{下ごしらえ}\label{shita}
    
    ここで使う材料は\hyperref[zairyo]{\ref{zairyo}}にまとめてあります。 \ldots{}
    
    \subsection{調理}\label{chouri}
    
    \ldots{}
    大きな鍋\index{おおきななべ@大きな鍋}(\hyperref[dougu]{\ref{dougu}}を参照のこと)を使います。
    \ldots{}
    
    \subsection{盛り付け}\label{moritsuke}
    
    \section{おわりに}\label{ux304aux308fux308aux306b}
    
    \ldots{}
    

    となります。

    これで相互参照が正しくなった中間ソース a.tex, b.tex ができましたので、main.tex を

    platex main
    platex main
    mendex main
    platex main
    dvipdfmx main
    

    と処理して、最終的に main.pdf を得ることができます。

    EPUB

    pandoc は EPUB 形式を出力することもできます。

    ソースは複数ファイルに分割されていても成果物はひとつにまとまっていたほうがいいので cat でつなぎます。また、HTML 向けに付けていたリンクの書き方を変更して(LaTeX の場合の前処理と同じです)、pandoc にかけます。

    cat a.md b.md \
    | sed 's/\(\[[^\]*\]\)[\(][^#]*\(#[^\)]*\)[\)]/\1(\2)/g' \
    | pandoc --self-contained -o main.epub
    

    これで最終成果物の main.epub ができます。LaTeX の索引のために挿入しておいた \index{} は無視されるので、特に気にすることはありません。

    HTML や LaTeX、EPUB を出力する際には、もっと適切な pandoc のオプションを付けたり、テンプレートを用意したほうがいいのですが、ここでは相互参照に絞って説明するため、これらを割愛しました。

    KVM に Kernel Samepage Merging (KSM)

    いわゆる自宅サーバーの機器を更新し、これを機にソフトも KVM の上に載せてみることにしました。

    用途と向きによって仮想サーバーを切り分けます。ホストも複数のゲストも、ぜんぶ Debian で同じバージョンです。ネットの検索によって得た知識でも何とかなります。

    当初気づかずに、後から「こういうのがあるのか」と気づいたのが、KSM (Kernel Samepage Merging) でした(解説はたとえば Linux カーネル共有メモリーの徹底調査)。

    KVM on Debian Squeeze – My Notes を参考に設定しました。

    ホストとゲストの両方で /etc/rc.local を編集し、次を追加します。

    echo 1 > /sys/kernel/mm/ksm/run
    echo 300 > /sys/kernel/mm/ksm/sleep_millisecs
    

    再起動後、/sys/kernel/mm/KSM/pages_sharing がゼロより大きな値になっていれば、有効になっています。

    KSM は使わないほうがいい?

    さて、はじめ気づかなかった KSM についての情報に行き当たったのは、とりあえずしばらく動かしていると、ゲストOSが徐々にメモリを食いつぶしていくという現象をどうにかしたいと思って調べてみたからです。 そこで上記のように KSM を有効にしてみたのですが、引き続き検索していると、「KVMで複数VMを起動してVM間の相互作用を減らしたいときに考えること 」という記事を見つけました。
    • メモリはオーバーコミットしない
      • メモリをオーバーコミットするとろくなことがありません。なので要るだけ積みあげます。安いし。
        • 特にゲストOSがlinuxの場合、メモリはあるだけ使おうとする。本来だとキャッシュとしての有効活用になるキャッシュを積極的に使う戦略が、メモリオーバーコミット環境下ではswapを多発させる原因になってしまう

    うーむ。これが原因かもしれません。個々のゲストはさほど深刻な負荷があるわけではなし、一方が急に働くことになっても他方はそれほどでもないことがほとんどなので、個々のゲストのメモリ割り当てを、ほぼ実メモリと同じくらい、としていました。すなわち、ゲストに割り当てたメモリを合計すると実メモリの数倍になっていました。しかし、この記述によると

      • メモリは足りてるはずなのでKSMは停止する

    確かに KSM はホストに負荷がかかるので、動かさずに済むならそのほうがいいかもしれません。

    もうしばらく様子を見ながら(まだ理解できていないことも多いし)、考えたいと思います。

    チャットサポートを構築する (その4) 連絡先の設定とまとめ

    【2018年4月20日追記】この記事は内容が古くなっている部分があります。「あらためてチャットサポートを構築する」もご覧ください。【追記ここまで】

    共有名簿 (shared roster)

    ふつうの XMPP では、相手先名簿 (roster) は JID に紐付けられ、サーバーに保持されています。ところが匿名サーバーの場合、接続要求があった際にそのアカウントが新たに一時的に生成されるため、その JID には相手先名簿がありません。そこで、XMPP の共有名簿(shared roster)という機能を使うことにします。

    ejabberd の設定ファイル ejabberd.cfg では

    {modules,
     [
      ...
      {mod_shared_roster,[]},
      ...
    ]}.
    

    とモジュールを有効化しておきます。

    ejabberd のウェブ管理画面の「ヴァーチャルホスト -> anonymous.example.net -> 共有名簿グループ」の画面で、まずひとつのグループを作成します。たとえば

    • 名前: support
    • 説明: サポート窓口
    • メンバー: support@example.net
    • 表示グループ: (空欄)

    のようにします。ここで support@example.net は、窓口側(問い合わせを受ける側)の JID です。

    さらにもうひとつグループを作成します。

    • 名前: all
    • 説明: 全ユーザー
    • メンバー: @all@
    • 表示グループ: support

    ここで @all@ は、「全ユーザー」を意味します。

    これで、「anonymous.example.net の全ユーザーの名簿に support グループのメンバー(ここでは support@example.net のみ)を自動的にセットする」ことができ、上述の(3)をクリアできました。

    チャットサポート構築のまとめ

    ここまでで、どうにかチャットサポートを構築できました。まとめますと、「チャットサポート」に求められる要件、

    1. アプリケーションの事前インストールが不要
    2. アカウント(JID)の登録が不要
    3. 連絡先が登録済み

    に対して、(1)は Converse.js を導入することで、(2)はクッキーを利用し匿名サーバーを設定することで、そして(3)は共有名簿 (shared roster) を使うことでクリアして、一応「チャットサポート」的なものができました。そしてこれらを WordPress のサイトに導入するために プラグイン化しました。試しにこのサイトに設置してみました。画面の右下に小さなタブが見えると思います。

    とりあえずはできたものの、課題も残っています。

    前にも書いたとおり、事前接続のところがよく理解できていないこともあって、匿名サーバーだと使えますが、特定の JID を事前設定しようとするとうまくいきません。また、ページ遷移に対応できていません。

    匿名サーバーの場合、共有名簿を使ってみましたが、多重に読み込んでいるのか、同じ相手先が増殖することがあります。どういうことなのかよくわかりません。また、これは匿名サーバーの宿命なのですが、接続した時点で相手先からは認証されていないので(その時点で生成された ID なので当然)、その相手先の在席状況が不明で「オフライン」と表示されてしまいます。印象が悪いので、WordPress のプラグインではこれを隠すようにしてみました。

    今回、恥を忍んで中途半端な状態でも公開してこのような文を書いたのは、誰か能力のある人がちゃんとした実装を教えてくれることを期待してのことです。XMPP ならまだしも、Strophe.js や Converse.js で検索しても、とにかく日本語での情報は非常に少なく、どこで聞いたらいいかもわからないほどです。

    何かわかる方がありましたら、教えてください。または情報をぜひ公開してください。お願いします。

    チャットサポートを構築する (その3) Converse.js を WordPress で使うプラグイン ConverseJS for WordPress

    【2018年4月20日追記】この記事は内容が古くなっている部分があります。「あらためてチャットサポートを構築する」もご覧ください。【追記ここまで】

    (その1)テストのページに示したように、Converse.js は、css と設定のための script を読みこめば簡単に設置できます。ということは、WordPress のサイトにも設置できます。これを実現するプラグインを作り、公開しました。

    GitHub にも置いています

    Converse.js を同梱しているので、このプラグインをインストールするだけで済みます。

    ダッシュボード -> 設定 -> Converse.js で、主な設定値の変更ができるようにしています。設定値の詳細は Converse.js のマニュアルを参照してください。

    設定項目の最初の Converse.js URL は、空白にすると、プラグイン同梱の converse-min.js を読み込みます。ただのファイル名 converse.jsconverse-no-otr.min.jsconverse-no-locales-no-otr.min.js と書くと、やはりプラグイン同梱のものを読み込みます。外部のものを使いたい場合は、正しい URL を設定してください。

    2番めの BOSH Server URL は、空白にすると、Converse.js が用意しているテストのための https://bind.opkode.im を使います。なるべくほかの BOSH サーバーを指定してください。

    (その2)にも書きましたように、事前接続はまだよく理解していないので、正しい実装ができていません。設定の prebind (事前接続)にチェックを入れ、JID とパスワードを入力しておくと、正しく接続できて名簿も取得できるように見えるのですが、会話ができません。Converse.js の GitHub でのこの議論と同じだと思うのですが、具体的にどうしたらいいかわかりません。詳しい方がありましたら、ぜひ教えてください。下に述べるように、匿名サーバーに接続してチャットサポート的に使うことはできます。

    設定例

    オープンな XMPP クライアント

    初期状態のままで、ふつうの XMPP クライアントのようになります。右下にウィンドウが表示されているはずです。JID とパスワードを入力すれば、そのまま使用できます。

    チャットに使用するアカウント (JID と呼ばれます)を持っていなければ、公開サーバー(たとえば STEP.im)で作ることができます。あるいは WordPress.com のアカウントを持っていれば、name@im.wordpress.com の形で、JID として使うことができます。

    facebook のチャットにも使えます(たぶん)。JID に (ユーザー名)@chat.facebook.com を入力します。facebook はその中で閉じているので、facebook 以外と会話することはできません。

    チャットサポート

    匿名サーバーに事前接続することで、チャットサポートの形にすることができます。

    prebind にチェックを入れます。JID 欄には匿名サーバーのホスト名だけを入れます。パスワード欄は空のままにしておきます。これで、これが設置してあるページを開くと、自動的に匿名サーバーに接続し、IDを割り振られます。

    一応これで使えるのですが、やはり事前接続の正しい理解と実装ができていないので、ページ遷移(WordPressの同一サイト内で別のページに移動した場合)に対応していません。いったん接続が切れて、また新たに接続する(匿名サーバーだと新しいIDになってしまう)ことになってしまいます。詳しい方がありましたら、ぜひ教えてください。

    この項もう少し続く