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

ノイマンの自然数(非負整数)生成プログラムについて

結城浩さんの一連のツイート に触発されて、「ノイマンの自然数（あるいは非負整数）」表現を生成するプログラムを色々書いてしまった。(要するに現実逃避:-)

まずはProlog (処理系は SWI-Prolog を使用)

nnn(0, []).
nnn(X, L) :-
    length(L, X),
    append(M, [M], L),
    succ(Y, X),
    nnn(Y, M).

これは、双方向に使えます。例えば、「?- nnn(2, X).」のようにすると整数からノイマンの形式に、また、「?- nnn(X, [[], [[]]]).」のようにすれば、ノイマンの形式に対応する整数が得られます。 しかも「?- nnn(X, Y).」とすれば、まず0について、「;」でバックトラックすると1, 2, 3, 4と次々に生成します。

次にCommon Lisp (処理系は CLISP を使用)

(defun nnn (x)
    (if (zerop x)
        nil
        (let ((m (nnn (1- x))))
            (append m (list m)))))

Prologに比べると当たり前過ぎてイマイチ面白くない(こらこら:-)

と、ここまでは「再帰的な構造しているから、プログラムも再帰呼び出し必須だよなぁ」と思ってたんですが、ふと、「COBOL で書けないかな？」と思いついたけど、流石に COBOL は最近触ってないし、可変長データ構造のサポートの現状がわからないので、「そうか、再帰を使わずに繰り返しで書ければ COBOL でも実質書けると言えるか」と思い、Common Lispで再帰を使わずに書いてみました。

(defun nnni (x)
    (prog ((i 0) (r nil))
        loop
        (if (>= i x) (return r))
        (setq r (append r (list r)))
        (setq i (1+ i))
        (go loop)))

いやぁ、 Lisp とは名ばかりなキチャナイプログラムになりました。繰り返しのスタイルが古臭いのは勘弁してください:-)

で、ここまでで一旦掲載。この後他の言語等追加するかもしれません。

それさえもおそらくは現実逃避:-)

以下、追加第1陣(2016/5/20 01:45頃)

さて、非再起な手続き型といえば古のMS-BASICですが、それっぽいものでプチコンV1.2が手元にあったので、それでも組んでみました。あまり頑張ってません:-)

画面ではコードが一部切れているので、手で転記すると、、、

INPUT X
IF X==0 THEN PRINT "{}":END
I=0
R$="{{}}"
@LOOP
IF I>=X-1 THEN PRINT R$:END
R$=MID$(R$,0,LEN(R$)-1)+","+R$+"}"
I=I+1
GOTO @LOOP

となります。(久々の手コピー:-)

というわけで、この辺にしときましょう。

---

(2016/5/20 23:37頃)
プチコンのBASICプログラムに冗長な行が1行あったので、削除しました。

---

(2016/5/21 0:40頃)
COBOLでやってみるとか(old)awk、bashではなくshとか、色々考えたんですけど、少し変な言語ということで、Windowsのバッチファイルで書いてみました:-)

ただ世の中でバッチファイルというと16ビット時代からの COMMAND.COM で実行する *.BAT と思われるようですが、今や64ビット時代なので:-)、32ビットWindowsからずっと使えている CMD.EXE で実行する *.CMD として作成しました。というか、 *.BAT では流石に無理があります:-)

@echo off
set /p x=?
if %x% equ 0 (
  echo {}
  goto :end
)
set i=0
set r={{}}
:loop
set /a x1=%x%-1
if %i% geq %x1% (
  echo %r%
  goto :end
)
set r=%r:~0,-1%,%r%}
set /a i=%i%+1
goto :loop
:end

これを越える「変な」言語とすれば、vimではなく元祖viぐらいしかのこってないかもしれない:-)

地デジ受信でブースターを入れるかどうか？

このエントリは今日ツイッターでポータブルテレビでうまく受信できないという件があったので、そのアフタフォローとして書くので、必ずしも一般的なものとは限りません。

＊テレビについて
そのテレビは地デジは俗に言うフルセグ(地デジのハイビジョンの放送)とワンセグに対応していて、電波が弱いと自動的にフルセグからワンセグに切り替わる機能を備えている。

＊状況
以前使っていたフルセグのテレビは問題なく受信できたけど、今度のものは電波が弱いということでワンセグに切り替わり、画質が低くなってしまう(「ざりざりな画像」)。

＊確認結果
他の通常のテレビに使っていたアンテナ線などにつなぎ替えても状況は変わらず。当然それら他のテレビ(フルセグ)は普通に受信できている。

＊考えられる状況
当該ポータブルテレビの受信感度が他のテレビに比べて低い。あるいは、何らかの不具合で受信不良を起こしていると思われる。

＊切り分けたいこと
そのテレビが不具合で受信不良を起こしているのか、それとも正常だけど感度が低いだけなのか？

＊確認事項
他のテレビで「アンテナレベル」の表示を行い、十分なレベルになっているかを確認する。以下はREGZAの例（アンテナレベルの表示方法はテレビの取扱説明書を御覧ください）。

バーのレベルが左から赤、黄、緑になっており、緑は十分なレベル、黄はやや弱く場合によっては画面が乱れたりして放送が見れなくなる場合がある。赤は見ることができない。という目安になっている。この例ではやや低めであるが緑なので、十分なレベルとなっている。

＊診断パターン
A. 他のテレビで十分なレベルの場合（上の例で緑の範囲に十分入っている場合）、そのポータブルテレビの感度が極めて低いと思われ、不具合や故障の可能性が考えられる。販売店等に点検や修理の相談が適当と思われる。（ブースターを入れても改善しない可能性がある）

B. やや低いレベルの場合(上の例の黄、あるいは緑と黄の境目ぐらいの場合)、ポータブルテレビの感度がやや低いだけの可能性があるので、そうと思われる場合は、市販のUHFブースターをアンテナ線の途中につなぐことで改善が期待できる。（ただし、不具合の可能性も0ではないので、販売店に相談する方が良いかもしれない）

以上のような感じになるでしょうか。なお、もしブースターを購入する際は地デジのみであればUHFブースターで十分です。CSやBS、FMなどのブースト機能は不要ですね。

とりあえず。