スキルシートと求人データのスキーマ構造が欲しいと思った
求人サイト(という名前の人身売買業)はある程度仕事していると思ってますが・・・
そもそも抜きすぎでは？的な話もチョットあったり
根本的に解消するには？ってぼんやり考えてたら
スキルシートを個人が提供する
求人データを法人が提供する
適切にマッチングが行われて、あとは自由にやりとりが行える
最後にお互いを評価
みたいなサイトがあれば良いのにって思った
ビジネスプランはノーアイデアだけどｗ
お金を求人サイトに払ってる会社が数社まとまって一部を投資すれば、比較的すぐ出来そうな気がする・・・
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サービスがどんな追加サービスを提供してくれるのかっていう本来の勝負になる気がした
2018年の振り返り
2018年も残すところあと少しなのでどーでも良い感じの振り返りを・・・
その1
部屋の模様替え計画2018が唐突にスタート(2017の今の時期から唐突にｗ)
ちなみに、当初の予定の後半はまだ終わってないので2019として年明けくらいから開始になる予定
その2
地元へ何度か
何がびっくりって姪っ子が二人とも20才ちかくて、甥っ子がまた増えてたこと
その3
テレビ買った。
テレビと言いつつアンテナケーブル刺さってないのでモニターですがｗ
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の情報が複数来たら必ずパスする
感想
なんか作れる気はする。
作りたいかどうかは別だし、ビジネス的な所の方が面倒だけどｗ
