makotan _at_ gmail dot com

DevIO Cafeいってみた

あの辺りに用事があったので、ついでに行ってみた

別にコーヒーを飲みたかったわけでもなく、単にみてみたかっただけ

  • モバイルで注文するのはなんとなく理解できる
  • カフェなのにレジがない
  • カフェなのに店員が店舗にいない時間が多い(用事があれば出てくる)
  • カフェなのにgyp社の人多い(あたりまえか)
  • 注文して意外とすぐ出てきた

という普通のカフェな感じと

一応ためしてみたくなるAmazon Goのコピーのウォークスルーな購入(こっちがメイン)

事前にカフェラテ飲みながら天井見たり色々した結果、天井はあんまり目立たないなぁ〜って印象だった。棚の方には色々ケーブルやら電子機器やらあったのでそっちも色んな仕組みがありそう

んで、色んなBlogでエラーもあったらしいって情報だったのでぼんやり行ってみたら

どこにもレジがない。店員もいない。

すっごい不思議な(悪いことしてる)感覚だった

商業ビルの一角にこれがあったらバカ売れ間違いないだろうなぁ〜って思った

あと、コンビニが全面的にこれになったら良いのになぁ〜って思った

 

また用事が出来たら行ってみよ〜っと

Open Pay Protocolを作れば良いのにと思った話

あんまりにもPayサービスが多いのでぼんやりしてたらふと思いついた

 

考えなきゃいけないことは

QRコード、バーコードそれぞれをオープンに規格化

各社同士の同期処理用APIと確定処理のバッチインタフェース仕様

各社同士の差額決済機能

参加各社の仕様準拠の担保

 

やりたいことその1

OPPのQRを任意のPayアプリで撮影

PayサーバがQRに書かれた所へ定期のバッチ処理で指定金額を送信

 

やりたいことその2

OPP準拠のバーコードをPOSに見せる

POSでバーコードから対象の会社へ残高確保の問い合わせ

OKならバッチ処理で指定金額の決済を送信

 

最後に各社がお互いに差額決済を1日1回実施

 

あとは各Payサービスがどんな追加サービスを提供してくれるのかっていう本来の勝負になる気がした

 

シン・ゴジラとアメリカのGODZILLAをみたイメージ

GODZILLAは一人の人とその家族を軸にストーリー展開してる

シン・ゴジラも一人の人が軸だけど家族の演出が全くなくてずっと仕事してる

GODZILLAは目的を持って現れてそして去って行く

シン・ゴジラは目的もなく現れて退治される

 

わかりやすさで言えば圧倒的にGODZILLAだなぁ〜と思った

 

紅白歌合戦の投票数の61万って少なくね?って思った件

気になったのでふんわり計算してみた

総務省の統計によると世帯数は5340万世帯

紅白歌合戦の視聴率が大体40%弱なので、紅白歌合戦を見てる世帯数は2136万世帯

ということは、2.855%の投票率・・・そんなに悪い数値じゃない気がする

巨大なファン層を抱えてるグループが複数ある事を考えると全体として白に偏りそうだけどw

 

2018年の振り返り

2018年も残すところあと少しなのでどーでも良い感じの振り返りを・・・

 

その1

部屋の模様替え計画2018が唐突にスタート(2017の今の時期から唐突にw)

ちなみに、当初の予定の後半はまだ終わってないので2019として年明けくらいから開始になる予定

 

その2

地元へ何度か

何がびっくりって姪っ子が二人とも20才ちかくて、甥っ子がまた増えてたこと

 

その3

テレビ買った。

テレビと言いつつアンテナケーブル刺さってないのでモニターですがw

paypay第二弾まだかなぁ〜

 

その4

風邪ひいてない気がする。

○○は風邪ひかないって言わないように!

 

その5

新型iPad pro良い!

 

 

巨大で無停止の決済サービスを作るアーキテクチャをぼんやり考えてみた

昭和の最後の正月まであと少しなので、巨大で無停止で超高負荷に耐えれる低コストな決済機能を作るアーキテクチャを考えてた

前提

日本の決済サービスとかじゃなく、アリペイを1から作るならって考えた(決済ルールが似てる奴・・・ACHとか・・・ならこれでいける気がする)。

アクティブなユーザが相当数いないとベースのコストが高くて大変そう

アリペイ並の低コスト決済サービスが出来るとは一言も言ってない

サーバ構成

A群:全体をコントロールする為のサーバ群、単時間ならダウンしても良い程度

B群:DB,MQ,APサーバ,LBから構成されるサーバ群、通常B群はユーザと1:Nで紐付く

C群:基本的にWebベースのサーバ群、フロントアプリから呼ばれたりする

D群:巨大ストレージサーバ

ポイント

全サーバをダウンする前提にすること

独立したB群を必要なだけM個配置すること

B群のフェイルオーバーを各レイヤでやること

B群のDBサーバを含むサーバ群をOSSで固めることで低コスト化

バージョンアップとかサーバの入れ替えはまるっと落とせる!(ダウン前提なので)

ソフトウェア的な事

C群がB群にアクセスするときA群(のキャッシュ)に問い合わせて宛先を決める

B群はフェイルオーバーに備えてフェイルオーバー先のMQにデータのコピーを送り込み続ける

A群はB群をかなりの高頻度で動作確認して問い合わせ先テーブルを更新する

C群はB群のサーバから一定時間レスポンスがなければ再処理する

B群のサーバは同じリクエストIDの情報が複数来たら必ずパスする

感想

なんか作れる気はする。

作りたいかどうかは別だし、ビジネス的な所の方が面倒だけどw

 

サンタの配送の仕組みをふんわり考えた

あるクリスマスイブの日にサンタの配送は一体どのくらいの人数でやってるのか気になったので計算してみた

 

一戸の配達に20分かかって、6時間以内に配達を完了する必要がある場合

サンタの人数は国内だけで15,000人弱(ただしトナカイ除く)

世界規模でやるとサンタの人数はさらに激増しそうだなぁ〜って思った

ただ、国内に限っていえば多分ヤマト運輸の方が凄いので、ヤマトの仕組みをそのまま使えばサンタは楽になりそう

ちなみに、子供のプレゼントの平均の値段を5000円としたところサンタが贈るプレゼントの国内での総額は452億円になったので、このプレゼント+配送を世界規模でやれるって相当(以降自主規制

 

メリークリスマス!