Hatena::ブログ(Diary)

..たれろぐ.. このページをアンテナに追加 RSSフィード

2016-09-12

なぜクレジットカード払いを使わないのか? → 主に管理が手間だから

カードを持ってるのに現金払いを好んで使う30代の友人に、その理由を聞いてみた。『なぜクレジットカード払いを使わないのか?』 - クレジットカードの読みもの
を読んでの感想文。


よく言われるクレジットカード払いのメリットは

  • 現金の支払いは基本的に後になればなるほど額面でお得(利息がつく場合)
  • 支払が手早い(現金払い比。ICカードには負ける模様)
  • ポイントが付く
  • 手元に現金が無いときに助かる場合がある
  • 海外に行くとき

これに対して、クレジットカード払いのデメリットを挙げると

  • セキュリティ懸念
    • 購入情報がカード会社に集約されるので、何かあったときに面倒なことになりそう(漏洩や司法当局の照会)
    • 不正利用が不安
  • 管理コストが増える
    • 現金が減るタイミングのズレ
    • 不正利用対策に明細を確認しろというが明細が増えると突合の手間がばかにならない
  • その他
    • サインレス増えてるとはいえサインやPIN入力が面倒
    • 支払先にかかる手数料が気になる
    • 現金なら手元分が上限だけど、カード払いにはそれがないからついつい使い込みそう
    • ポイント貯まるとはいえ使途が限定されていて使い物にならなかったり有効期限があったり確認が面倒(カードによる)

こんなものだろうか。

個人的には管理コストとセキュリティ懸念(主に購買情報が掌握される危険性)、加えて個人
の小規模店舗だと手数料の負担が心苦しい。


管理コストについては、やはり現金が必要となるタイミングが遅れるのが手間かなと。
(これはクレジットカードのメリットでもあるわけだが)

現金だと「現時点」に注目するだけで済む=忘れても OK なわけだけど、クレジットカード
払いでは未払い金が生じるので、実際に引き落とされるまで現金の出入りの見通しを立てて
引き落とし日に残高不足にならないようにしておかないと、うっかり引き落とし不能とかで
信用情報、いわゆるクレヒスに傷が入ってしまう。

本来、クレジットカードはここらの残高不安がない安定した資産と収入がある身分の人を対
象としたものなんだろうけど…
(だからこそカードには信用調査があるわけなんだけど、昨今はリボ払い誘導とか結構な情弱ビジネス臭もする)


これに加えて、明細確認の手間。

ブコメでも指摘があったように、カードの利用頻度が増えると明細も増える→利用実績
(自分の記憶やカード利用時のレシート)との突合が大変に面倒になる。

Amazonkindle、お前のことだ!
セールの時にあれもこれもと買うと、カードの明細に同じ日付の「AMAZON DOWNLOADS」が
ずらり並んでぶ。
購入IDとか載らないので、購入時のメールと&金額で突合するしか手が無く、コミックを
あれやこれやと手を出してると金額まで同じとかで大変に手間。
一般商品と同じくカートに入れて一括決済できるようにしてくれ、 Amazon よ。

閑話休題、「不正利用を防ぐためには明細確認が必須」とは言われているものの、例に挙げ
たようにここの突合が相当にコスト(記憶負担とかレシート保管&管理の手間とか)かかる
から辛いよねと。
現状のシステムだと、面倒だから確認しなくなって→不正利用だ、危険、怖い。となってし
まうのはだと致し方ないように思える。


コンビニとかの細々とした支払にも使っていると結構な手間だと思うのですが、世間の皆様
はどうやって管理してるんでしょうか。

自分は カードで支払う → Excel に未払い金として記録しておく → オンライン明細に上がっ
て来たと突合する → 引き落としが終わったものは削除する としてるものの、月10回未満
程度でも結構な手間でして。

店によってはカードの利用実績が上がるタイミングがずれてたりして、先月使ったはずなのに
明細に上がってこなくて、翌月に上がってきたり……とかあるし。


だれか、現金、ICカード残高、口座残高、カード利用状況突合をひっくるめて面倒見られる
いかした家計簿Excelくださいorz http://b.hatena.ne.jp/entry/300974916/comment/sgo2


マネーフォワードはね、ログイン情報渡してスクレイピングというのがイヤ。
住信SBIのようにカード各社が OAuth とか使った参照系 API を提供して、それを叩くのならまだ許せるんだけど。。
あと、結局明細が更新されるまで待たないといけないことに違いはないので、現状が即時反映さ
れないのは同じ。


デビットと電子マネーICカードでの支払いはどうだろうと考えると、

デビットは即時に残高減るから時間のズレの問題は消えるものの、上限額=預金額という天井の高さがネック。
チャージという形で任意に天井を設定できるチャージ式ICカードは悪くないけれど、、

双方とも、微妙に使い勝手が悪いのはカード内の残高を把握しにくい点。

ICカード単体型だとカードリーダーなりの端末がないと確認できないわけで、ふとしたときや
レジ待ち中に残高あったっけ?と、現金なら財布を覗けば終わることができない。

スマートフォン一体型だとその辺カバーされるんだろうけど、アプリ操作が必要なのでちょっと
手間なような気がする(使ったことないので何とも)。
あと、携帯持ち歩かないといけないという点(携帯の意義否定())

ICカード電子ペーパー付いてて都度残高表示が変わったりすればベターかな。
とはいえ、ICカードのIDによる利用者行動の追跡懸念は残るのでなんとかならんものかと…。


ここらが解消されて、取り扱いコストが利用者店舗側とも現金のそれよりに安くなる電子決済
システムができれば現金払いだと逆に手数料かかるみたいになって、がらりと風景変わるだろ
うけどねぇ。
ついでに、支払と同時にレシート,領収書がカードに記録されて後から電子的に参照可能なので
お願いしゃす。


最後に、利用状況を管理しないといけないようなビンボー人はカード使うなって言うならば、
そういうビンボー人にはカードを発行するべきじゃないし、そうなったビンボー人が現金払
いするのは見逃してね。それしか支払う術がないんだもの。
そしてクレジットカードは、その仕組み上、現金が常時潤沢で余裕のある人・店舗が使うこ
とが前提になってるので、そこから外れた日々カツカツで現金回してる人らには向かない決
済方法と。

2016-08-27

XBee 送信ステータス 0x26 の意味

XBeeブロードキャスト送信していると、その送信ステータスで 0x26 が返ることがあるんですよ。

公式リファレンス によると、

0x26 = Broadcast source failed to hear a neighbor relay the message

ということで、ご近所がリレーしたメッセージが聞こえなかった(直訳)ということらしい。

ZigBeeブロードキャスト送信がどうなっているのかというと、知らないブロードキャストメッセージを受信したら再送信。という仕組みになっているらしい(Zigbee Network Layer Tutorial - Part 3: Broadcasts and Neighbors)。

したがって、「ブロードキャストメッセージを投げたものの、ご近所が再送信するはずメッセージが聞こえなかった。何かおかしい!」と言う意味になります。

試しに、コーディネータだけ動かしておいて、ブロードキャスト送信すると、周りに再送信するノードが誰もいないので、送信後 1 秒ほどで 0x26 が返ってきます。
それに対して、ルータが 1 台でもいると、 0x00 が返ります。

つまりは ぼっち、寂しいよね。

XBeeの通信チャンネルの指定の仕方

2016/9/12 修正 当初 S2C で ch 26 が使えないとしてましたが対応しているようです。
元記事

XBee ついでなので、XBee ZB S2C が使う通信チャンネルの指定の仕方。

直感的には AT CH コマンドがあるから、これで指定できそうに見えるのだけれども、AT CH は無慈悲にも「read-only」。
どうすんだよ!と言うと、コーディネータで AT SC コマンドを使い、スキャンするチャンネル=選択可能なチャンネルを制限してしまう。
例えばチャンネル12を使いたい場合は SC に 0x0002 を与えて、そこしか選べないようにする。

ch11 0x0001
ch12 0x0002
ch13 0x0004
ch14 0x0008
...
ch25 0x4000
ch26 0x8000

という感じ。
チャネル26相当の 0x8000 も設定できてしまうけれど、XBee ZB S2C はチャンネル26に対応していないから通信できなくなる。(2016/9/12 修正)

また、ルータとエンドデバイスでは、この方法でチャンネル指定しないほうがよい。
ルータとエンドデバイスは、スタートアップ時にコーディネータにぶら下がる形になっているので、どのみちコーディネータが使っているチャネルになるし、コーディネータのチャンネルと違うチャンネルに制限してしまうとjoinできなくなってしまう。

情報源

Arduino + XBeeシールド + XBee で勝手にリセット

Arduino + XBee ZB S2C で遊んでて、時々勝手に Arduino がリセットするので何故だ、ということで。

結論を先に書くと、XBee のハードフロー制御動作と XBee シールドの回路の影響で、フロー制御がかかるとリセットしますよというお話。


環境は

状況としては、こちら(XBeeのリセットとXBee shieldの回路について - Arduinoを使い倒すページ)と似てるけれども、 XBee のリセットにつられて Arduino が落ちるのではなく、データをガンガン送信してる最中に突然 Arduino再起動するという感じ。

先人の話があるので、シールドの回路図(DFR0015)を調べると、XBee 12番ピンの DIO7/~CTSトランジスタを介して Arduino 側のリセット信号線に繋がっている状態。

となると、 DIO7/~CTS がなにかのはずみで HIGH になっている模様。
XBee のピン設定で DIO7 がどうなっていたかを確認すると、「CTS flow control [1]」になっている状態 (XBee AT D7 コマンド参照。ちなみにデフォルト値)。

つまり、起きている事象としては

  1. ArduinoXBee にがんがん送る
  2. XBee送信バッファがいっぱい
  3. XBee はフロー制御をかけようと CTS 信号を落とす
  4. 負論理なので12番ピンがHIGHに
  5. Arduino にリセット信号どーん。再起動

ということな模様。なるほど、「R3 外せ」ってそういうことね。
スイッチかジャンパピンになっていればいいのにねーとか思いつつ。

XBee はハードフロー制御しか対応していないので、真面目に対応しようと思うと、

  • R3 外す
  • XBee 12番ピンを Arduino の適当な Din に繋ぐ
  • Arduino のソフト側でその Din が Low なのを確認しつつ送信するように対応する

という改造が必要そう。


秋月電子で扱っているもう一つのXBeeシールドArduino公式版)のほうは、回路図を見る分にはCTSArduino側に繋がっていないのでこの問題は起きないはず。
DFRobotのシールドでも、XBeeの設定を変更して DIO7 を Disable か Low 固定にすれば大丈夫かと。

ただし、フロー制御が一切無いのでがんがん送ったときに何がおきるか、という危険性はありますが。
(いや、ちゃんと 0x8B Transmit Status 確認しながら送信すればソフトフロー制御相当か?はっ、自分の実装がクソというオチ!?)

2016-08-25

CentOS7 の USB インストール

1. 公式サイトから Minimal の isoダウンロードしてくる。
2. DD for Windows - Tech Info を使い、1. でダウンロードした isoUSBフラッシュメモリに書き込む
3. USB メモリをつっこんでターゲットを起動する

NetInstall イメージを使うと、ダウンロードリポジトリの機嫌が悪いのかパッケージメタデータダウンロードに時間はかかるし、その挙げ句、『ベースリポジトリのセットアップ中にエラー』とかで進めないので Minimal が無駄な時間を過ごさずに済む無難解。