Honya Club.comの「店舗受取」に関する懸念？

今日もHonya Club.comで予約した書籍を店頭受取で買ってきました。

便利なサービスで、最寄りの書店の活用にもなるのがいいんですが、気になる点が。。

というわけで、以下は書店等で聞き取り調査等はせずに推測していることなので、事実誤認があれば御指摘歓迎。というわけで、twitterではなくblogにした次第。ただ、ダラダラとした書き方にはなりますが。

その問題は「取りこぼしが多い」ということです。
本稿での「取りこぼし」とは、予約した書籍が店舗に届いた際に、店頭受取のために別に取り置くはずのものを、通常の新刊だと見なして、店頭に並べてしまっている状態のことです。

この「取りこぼし」率が私の経験では1割を超えていて、ヒューマンエラーにしてもちょっと高率過ぎるのが気になる点です。店舗側(の責任ある立場の人)は、その度に謝罪の言葉と「以後気をつけます」とは言ってくれるんですが、実際には改善している様子がない。

ちなみに、予約ではなく、単なる注文の場合には経験したことはありません。

で、これは恐らくHonya Club.comの「店頭受取」のためのシステム設計にエラーを起こしやすくしている点があるんじゃないかと思ってしまうわけですね。
もうちょっとツッコむと、Honya Club.comのサイトで予約注文して、店頭受取を指定した場合に、指定された店舗にその情報がどう伝えられているかに問題があるような気がするわけです。

予約なので、発売予定日まで日がありますから、予約時点で伝えるというのは多分やってないでしょう。実効性を伴わせるとすれば、問屋から出荷したタイミングで通知するか、問屋から届いた荷物でわかるようにしているか、でしょう。
ちなみに、顧客には「予約完了」、「出荷」、「(店舗に)入荷」という3回のタイミングでメールが届きます。

私が考えると、店舗側の手間を省き、間違いが起きないようにするには、店舗に届いた荷物で解るようにするのがベストになります。
一番いいのは、予約分は別の荷物にして、個々の書籍に誰の予約かラベリングしておくことですが、別の荷物にするのはコストがかかるので多分選ばれない。

他の新刊その他の書籍とまとめて送るとして、箱詰めの効率を考えると予約本とそれ以外を物理的に分けておくのもコスト的には多分選びそうに思えません。

とすると、書籍そのものは新刊本としてまとめられているので、書籍だけを見て、どれが予約・店頭受取かを識別出来ないだろうから、別途伝える必要があると思います。

で、素人的には荷物には常識的に送付品リストを添付しているはずだから、そのリストで予約本をわかりやすく明記しておけばいいじゃないかと思うわけですよね。それなら、届いた荷物をリストと照合しながら荷ときしていけば、当然「あ、これは予約だから、取り置こう」となると。
でも、それなら1割を超えるエラーが説明できません。

で、思ったのが「店舗には出荷時に通知するが、その通知は店員が積極的に端末を操作して予約のリストを見ないと分からない」システムになっているのではないかと思った次第です。
で、通常の端末操作では「予約品が出荷されていることはわからず、積極的に予約進出荷リストを表示しないと分からない」とか。。。。いや、まさかとは思うんですが、、、。

つまり、店員が常に「今日は予約品が届いているかもしれないからリストをチェックしよう」と考えて、その操作をしない限り予約品が出荷されたかどうかが分からない、とすれば、「予約品が届く頻度が低い」と空振りな日がほとんどになって、つい、忘れてしまうのではないかと予想した次第です。

人にポリングさせる＆頻度が低いとそりゃ無理があるでしょうから、普通は避けると思いたいんですが。。。
で、ミスがあるとしばらくは一所懸命毎日チェック するけど、空振りな日がずっと続くので、やがて他の忙しさでチェックを忘れても実害がなかなか起きないので(以下略)

現に今日も入荷通知が来てないけど、棚に挿してあるのを見つけて店員に聞いたら、一所懸命端末(いやPCですが)を操作して画面をいくつも見て確認してましたし(画面の内容までは私は見てません)。

で、改善して欲しいわけですが、特定の小規模店舗に言っても無理だろうしねぇ。Honya Club.comにユーザとして要望を出すと、私の登録店舗に対して厳重注意、つまり「運用でカバーしろ」になるような気がして、、、。

で、なんで上記のような事になっているように想像したかというと、店頭で予約注文した際の古典的な流れをシステムの設計時にいれたんではないかと。店頭で受ければ、店員側で把握しているし、それなりにわかりやすく伝票を整理しておけば、見落としはそうそう起きないと思うけど、そうじゃないからねぇ。。。

単なる注文の時は、発売予定日前後でもなく、突然既刊本が交じるわけですから、「あれ？注文出したわけでもないのに？」となるから多分気づいて今まではエラーを起こさなかったのかなぁと。

今までは、棚に並べられても私が店に行く閉店間際まで売れずにいてくれたから良かったんですが、売れてたらどうなることやら。（まぁ、そう売れないような本だから予約しないと入らないだろうなぁと予想して予約しているわけですけど:-)

 せっかくのサービスなので、改善して欲しいなぁと思うわけです。

あ、懲りずにこれからも何度も使うつもりですよ。（と言うか今も数冊予約しているし）

Zebra Puzzle

たまたまTLに流れてきた
https://twitter.com/algoRafael0110/status/873469127364534272
に刺激されて、Zebra Puzzleを解くプログラムをPrologで書いてみました。

上記のツイートで言及されているのは、
http://qiita.com/ShunIchikawa/items/6449f492dc38a7201162
「Prolog実践入門 - AIに特化した老舗言語 - Qiita」
の簡易版と、英語版Wikipediaの解説
https://en.wikipedia.org/wiki/Zebra_Puzzle
「Zebra Puzzle - Wikipedia」

元のツイートで「is」述語を使っているのがパット見で気になって、「nth1があるよなぁ」と思いながらQiitaのページをちらっと見た後、自分で書いたら使う必要がなかった。。。

まぁこれで一応最低限は出来たと思います。

?- who(W, Z).

と問えばOK.
先のツイートで上手くいかなかったのを厳密に分析はしていませんが、is 述語はこの手の純粋なパズル系の問題では要注意だというのが私見です。

とりあえず。以下がコード。(SWI-Prologで確認。改行位置がきちゃないのはご勘弁を)

neighbour(X, Y, [X, Y| _]).
neighbour(X, Y, [Y, X| _]).
neighbour(X, Y, [_| R]) :- neighbour(X, Y, R).
right(X, Y, [Y, X| _]).
right(X, Y, [_| R]) :- right(X, Y, R).

who(Water, Zebra) :-
  Street = [H1, H2, H3, H4, H5],
  member(house(englishman, red, _, _, _), Street),
  member(house(spaniard, _, dog, _, _), Street),
  member(house(_, green, _, coffee, _), Street),
  member(house(ukrainian, _, _, tea, _), Street),
  right(house(_, green, _, _, _), house(_, ivory, _, _, _), Street),
  member(house(_, _, snails, _, old_gold), Street),
  member(house(_, yellow, _, _, kools), Street),
  house(_, _, _, milk, _) = H3,
  house(norwegian, _, _, _, _) = H1,
  neighbour(house(_, _, _, _, chesterfields), house(_, _, fox, _, _), Street),
  neighbour(house(_, _, _, _, kools), house(_, _, horse, _, _), Street),
  member(house(_, _, _, orange_juice, lucky_strike), Street),
  member(house(japanese, _, _, _, parliaments), Street),
  neighbour(house(norwegian, _, _, _, _), house(_, blue, _, _, _), Street),
  member(house(Water, _, _, water, _), Street),
  member(house(Zebra, _, zebra, _, _), Street).

2017年4月8日現在のtwitterの振る舞いアレコレ

ここ数年でtwitterも随分色んな機能が増えたようで、自分のメモ代わりにテキトーに列挙しておこうと思う。テキトーなメモなので、文章がこなれてないのはご勘弁を。
なお、twitter社の方針次第で今後もなんぼでも機能が変わる可能性があるので、あくまでもこのエントリの記述時点のものだということは、言うまでもないので、あしからず。

• reply(リプライ)は本文に単に「@スクリーン名」が含まれているだけではなく、リプライ先のツイートへのリンクが内部的に付与されている。
• 本文先頭が「@スクリーン名」の場合は、そのスクリーン名のアカウントのフォロワーのTLにしか出ないのが従来の振る舞いだった。ただ、少し前に発表されたものだと、その形式にかかわらずreplyとしてツイートされたもののみがリプライ先ツイートのアカウントのフォロワーのTLにしか表示されないようにするという。（これが現在の公式Web等のリプライの際の振る舞いにつながっている？)
• ちなみに、tweetを自動的にmixiに流す設定の場合、リプライ先への内部リンクがあるツイートはmixi側には流れないようになっている(リプライを流さないということらしい)
• 公式Webやtweetdeckではリプライの際はリプライ先を表す「@スクリーン名」は本文に含まれず、別途編集するようになっている（まるでメールのヘッダのよう？)。その結果、従来「リプライするけど、自分の全フォロワーのTLに流したい」目的で本文先頭にピリオドなどを挿入する手法が使えなくなっている。クライアントによってはまだ使用できるものもあるので、ツイートの内部的データ構造までは変わってない模様。
• 公式RTについては特に最近は変わってない？
• コメント付公式RTはコメントとなるツイートにコメント先になるツイートへの内部的リンクがある。ただし、公式Webやtweetdeckなどでは、本文に他のツイートのURLを記載するとコメント付公式RT扱いになる模様。(本文に複数のツイートのURLを記載した場合は確か最後のものに対するコメント付公式RT扱いになったと思います。。。)
• 通知(Notifications)はフォローされた場合と、リプライ、Likes、公式RT、コメント付公式RTが自分のツイートにされた場合に届く。設定である程度フィルタリング可能。
• 画像などのURLを本文に含むツイートの場合、その画像のサムネイルが見えるかどうかはその画像を載せているサービスとクライアントに依存。確実なのはtwitter公式の画像サービス。それ以外はクライアントによって見える・見えないがあると思ったほうが良い。
• 本文中のURLはすべてtwitter側で t.co短縮URLにされる。したがって、サードパーティのURL短縮サービスを使うのは短縮以外に積極的な意味があるかどうかが思案のしどころ。
• 公式Webやtweetdeckでリプライ先が本文外であるかのようなUIになったのは、リプライ先が本文の文字数にカウントされないようにするため。
• 色々と本文の長さに数えない要素が出てきたので、旧来のクライアントにとっては140文字を越えるツイートが出て来ることになるので、古いクライアントに対しては140文字を超える場合は、途中から「...」と略し、全文を見るためのURLが記載されるようになっている。その際のURLは「https://twitter.com/i/web/status/ツイート番号」となっている。
• 通常のツイートのWebブラウザで開く際のURLは「https://twitter.com/スクリーン名/status/ツイート番号」だが、実はスクリーン名のところは実在するものであれば、誰のものを書いても関係ない。（これは大昔から)
• 本文中にスクリーン名のところを「i/web」に置き換えたURLを書くとコメント付公式RT扱いにならない。クライアントで引用形式で表示されない不便さがあるが、リンクをブラウザでたどるとツイートがちゃんと見える。また、元ツイート主に通知もされない。
• リプライの内部リンクでスレッド化されているツイートの表示はクライアントに依存する。公式Webやtweetdeckはツイートを選ぶとそのツイートのリプライ先リンクを辿ったものに加えて、そのツイートにつけられたリプライの方も表示するが、janetterでは前者しか表示されない。

とこんなところかな？
将来の仕様変更についてはこのエントリで追従する気はないですが、もし事実誤認があれば、お知らせいただければ適宜修正かコメントをつけたいと思います。

内閣府の「国民の祝日」ページのCSVを使うサンプル

http://www8.cao.go.jp/chosei/shukujitsu/gaiyou.html
についてツイートでちょっと触れましたが、
https://twitter.com/tsaka1/status/834770830399647744
実はそんなに処理が複雑ではない事に気づいて、しょうもないサンプルプログラムを書いてみました。
Rubyの標準ライブラリにあるDateクラスを使って、年月日を入力するとその日が祝日なら、その名前を、それ以外なら曜日を表示するというものです。Windows上でsjisで書いたプログラムです。

なお、大したことはしてないので、解説は略します:-)

で、問題は来年以降もこのプログラムが無修正で使える形式で提供されるかどうかですよね:-)

---

#! ruby
# coding: sjis
#
# 「内閣府ホーム  >  内閣府の政策  >  制度  >  国民の祝日について」
# http://www8.cao.go.jp/chosei/shukujitsu/gaiyou.html
# のCSVファイルを使って祝日かどうかを返すプログラム例
#

FNAME = "syukujitsu.csv"

require("csv")
require("date")

WDAYS = [
  "日曜日",
  "月曜日",
  "火曜日",
  "水曜日",
  "木曜日",
  "金曜日",
  "土曜日"
]

$holidays = Hash.new

CSV.open(FNAME){ | cs |
  header1 = cs.gets
  header2 = cs.gets
  while row = cs.gets
    while !row.empty?
      name, date = row.shift(2)
      if !name || !date
        break
      end
      $holidays[Date.parse(date)] = name
    end
  end
}

puts("年月日を入力してください。入力終了はENTERのみです。")
while keyin = gets
  if keyin == "\n"
    break
  end
  d = Date.parse(keyin.chomp)
  if n = $holidays[d]
    printf("%s: %s\n", d.strftime("%Y/%m/%d"), n)
  else
    printf("%s: %s\n", d.strftime("%Y/%m/%d"), WDAYS[d.wday])
  end
end

FreeBSD11にvirtuoso-7をpkgでインストールしたときのメモ

タイトルどおりのメモです。

詳細なバージョンは以下の通り。

FreeBSD: 11.0-RELEASE-p2
Virtuoso: virtuoso-7.2.4.2_1 (pkgでの名称)

pkg install virtuoso-7.2.4.2_1
でインストール自体は問題なくできるが、実際に起動しようとすると、以下のような設定の調整が必要だった。

 1. /etc/rc.conf.local に設定ファイルの場所も指定する必要があった。標準は相対ディレクトリ指定になっている。
例: virtuoso_config="/usr/local/lib/virtuoso/virtuoso.ini"

2. データベースやログの置き場のディレクトリに virtuoso:virtuoso権限で動くプロセスに書き込み権限を与える必要がある。
例: chgrp virtuoso /usr/local/lib/virtuoso/db && chmod g+w /usr/local/lib/virtuoso/db
(これをしてないと起動した旨 /var/log/messagesに入るけど、実際にはプロセスがなく、エラーメッセージも残らないという羽目に陥るようです。)

3. pkgではvirtuoso.ini を /usr/local/lib/virtuoso/db に置いていますが、設定ファイルでは同じディレクトリにデータベースファイルやログを置くため、書き込み権限を出すから別ディレクトリの方が良いと思います。(私は一つ上のディレクトリにしました。see /etc/rc.conf.local)

以上で、最低限の起動はできますが、当然iniファイルの修正その他は必要ですよね。

PS. これ、pkg作成元に伝えるべきかとも思うけど、個人的にはこのぐらいの手当てが自分でできない人がサーバ運用することには疑問があるので、メモを書いとくだけにします:-)