Diary

@ssig33

CDN であれこれやっていっているのは仕事でそういうことをしたいからで 自分が覚えるより知ってる人材雇ってもらうほうがはやいんじゃないの?とは思ってるんだが、そんな人材は求人市場にあんまり出てきてないっぽいんだよな。 死を感じる。

02 Apr 2018 Mon 17:04

iMac 買うか、、、

02 Apr 2018 Mon 14:04

人間性

29 Mar 2018 Thu 13:33

ねむい

29 Mar 2018 Thu 13:33

キャッシュに使う CDN Fastly にしてみた

ずいぶん前に Fastly 使ったとき Web 管理画面意味不明だったんだけど、今はかなりまともになってる。 とりあえず Fastly 試してみたいで導入しただけなのでこのサイトいまかなりやばいことになってて、 TLS 化するために Cloudflare 使っててその後ろに Fastly がいるみたいになってる。完全に無駄。

26 Mar 2018 Mon 23:02

Firebase がデフォルトで対応してない OAuth2 Provider に Firebase でログイン できたら便利だなと思ったのでやってみる。今回僕が扱いたい「Firebase がデフォルトで対応してない OAuth2 Provider」というのは今働いている会社であるところのユビレジです。

カスタム認証というのが提供されていて、そういうことをしたい時これを利用すればよいのだと思われる。ところが、これは基本的にはサーバーサイドで Firebase とやり取りして認証用トークンを作成する必要がある。

今回いじりたいのは自社サービスなので、そっちをいじってもいいのだろうと思う。ただまあめんどうなのでクライアントサイドと Cloud Functions だけで問題を解決したい。

というわけで CloudFunctions 側に以下のようなものを実装した。ここにある oauth2 というのは simple-oauth2 というライブラリのアレです、アレ。 redirect_uri はとりあえず http://localhost:5000/callback を指定している。

exports.auth = functions.https.onRequest((req, res) => {
  const authorizationUri = oauth2.authorizationCode.authorizeURL({ redirect_uri: redirect_uri });
  res.redirect(authorizationUri);
});

exports.callback = functions.https.onRequest((req, res) => {
  const tokenConfig = {
    code: req.query.code,
    redirect_uri: redirect_uri
  };
  // ユビレジの accessToken を取得
  oauth2.authorizationCode.getToken(tokenConfig).then((result)=>{
    const accessToken = oauth2.accessToken.create(result);
    const account_id = String(accessToken.token.account_id);
    // カスタムトークンを生成
    admin.auth().createCustomToken(account_id).then((customToken)=>{
      // ユビレジの accessToken を firestore に保存しておく
      const db = admin.firestore()
      const ref = db.collection('credentials').doc(account_id)
      ref.set(accessToken.token).then(()=>{
        ref.update(accessToken.token).then(()=>{
          res.redirect(`/?customToken=${customToken}`);
        });
      });
    });
  });
});

ルーティングは以下のように

  • / は index.html を普通に返す
  • /auth で ↑ の auth
  • /callback で ↑ の callback

を使う。

で index.html 側では location.search を見て customeToken があれば

firebase.auth().signInWithCustomToken

で認証してやっていく。たぶんこれでセキュリティ上の問題もない、よね?

これで Firebase Hosting と Firebase Cloud Functions だけで Firebase がデフォルトで対応していない OAuth2 Provider にログインが出来た。

サーバサイドで accessToken などを Cloud Firestore に入れているので、認証後はそこから accessToken をとってきてユビレジ API にアクセスできる。

というつもりだったのだが、ここまで作って気付いたことがあり、なんとユビレジ API は CORS 対応してないので、 Cloud Functions でプロキシしてあげないといまのままだと動かない、、、

というわけなので CORS 対応 Pull Request を作ろうと思う。

09 Mar 2018 Fri 17:31

Firebase 使ってみた 2018

最近は技術についてはレイトマジョリティでいいなと思ってる。 Firebase はもう完全にやっていけるかんじっぽいのというのを各方面から聞いたので試してみた。

だいぶ前に Firebase を使ってみたとき、 Realtime Database のクセが強すぎてこれはあかんなという感じだった。今では Cloud Firestore があるので話が違うだろうと思いあらためて実用アプリを一個作ってみた。

前にクライアントサイドだけで実行して保存先は Google Drive という野蛮なメモツールを作ったことがあった。これのバックエンドを Google Drive から Firebase にしてみた。

元々のツールが Google Drive との接続部分を一つのファイルに切り出していたので、これをいじって Firebase に対応するだけでスッと作れた。

出来たメモツール、 Markdown メモツールとして結構素性いい感じになったので別途公開したりしたい。

さらに React Native を使って iPhone クライアントも作ってみた。

Firebase の感想 2018 年版

Cloud Firestore はすごい

Realtime Database は本当にリアルタイムなアプリケーション専用の設計になっていて、リアルタイム性別にいらないんだけど、、、みたいな時はすごく使いづらかった。

Cloud Firestore は集計関連以外だいたい RDBMS みたいな感覚で使える。大抵のアプリにおいて Realtime Database よりも遥かに簡単に使えると思う。普通の Web 系プログラマーにとってはかなり直感的。

ただし、書き込み速度についてはかなり遅くて、たとえば特定のドキュメントのカウンターとかを頻繁に更新する場合は、そのドキュメントの配下にカウンター専用シャーディングドキュメントみたいのを作って更新時にランダムに選択したカウンターをインクリメントし表示時に合算せよみたいな地獄のノウハウが公式から提供されている。正直こんなのまともな人間がやることではない。

こういう無理なことをするくらいなら Cloud Functions 経由で BigQuery にデータをコピーし、 Cloud Functions に適切に API を実装することが楽である場合が多いだろうと思う。

「殆どの」ワークロードは Cloud Functions 抜きで実装でき、結果として自分で一からサーバーサイドをなんとかするより遥かに低コストになると思う。

全文検索も Cloud Functions で解決することが推奨されているタスクだ。このドキュメントで紹介されている algolia という全文検索ソリューションはかなり強力で、 Firebase に興味がないという人もこれだけは使ってみる価値があると思った。

また Firebase の特筆事項として「 Google/Twitter/Facebook およびメールアドレスとパスワード」でログインできるみたいなサイトを本当に一瞬で作れる点がある。認証まわりの気軽さは本当にすごい。

React Native と Firebase

react-native-firebase というライブラリがあって、結構楽にやっていける。ただし、 react-native-firebase で認証まわりを作るには現状かなりのエアリーディング力がもとめられる。各種ライブラリの README やドキュメントを読むだけでは動くものにはならないのが現状。

まとめ

これまで何度か Firebase で遊んでみて、その度に「これはダメだな、まだまだ Rails でサーバーを書く時代だ」などと思ったものだけど、そろそろ山が動いたと思った。

あと一言

Firebase という名前を mBaaS とアクセス解析という相互にそんなに関係ない二つの分野にひろがるブランド名に使っている結果検索性が非常に悪い。マーケティング担当者は切腹したほうがいい。

06 Mar 2018 Tue 14:50

泥酔

14 Feb 2018 Wed 14:28

死んだ人の悪口を書こうと思い書き始めたら長文になってきた

11 Feb 2018 Sun 14:26

ゴリラ

11 Feb 2018 Sun 14:23

CDN がネガティブキャッシュもしてほしい

08 Feb 2018 Thu 11:36

マンガは売れなくなったのか? ということが気になっていて、検証してみた。

ソースは以下の 2 点

紙の単行本

2016 年

紙のコミックス(単行本)が同7.4%減の1,947億円

2017 年

コミックス単行本が約13%減と大幅に減少しました。

ということなので 2017 年のコミックス単行本の売り上げは 1,694 億円。 253 億円減少。

電子の単行本

2016 年

電子が同27.5%増の1,491億円

2017 年

内訳は電子コミックが同17.2%増の1,711億円

220 億円増加。

すくなくとも単行本については「紙が売れなくなった分電子が売れている」という以上の話ではないように思います。少なくとも出版、最後の砦マンガ沈む 海賊版横行で販売2ケタ減 というような話はウソの類いでしょう。海賊版が横行し、メディアミックスも不発の中着実に紙から電子書籍への移行が進んでいるという状態だと思います。

雑誌は、どうなんでしょうね。こっちは 2017 年の分析見る限り確実に落ちていると思われます。こういう状態ですので「暇潰しコンテンツについては確実にスマホコンテンツに客を取られているが、じっくり金払ってマンガを単行本で読む層は増えも減りもしていない」というのが正確なところだと思います。

30 Jan 2018 Tue 18:23

最近仕事ばっかしていてよくない

30 Jan 2018 Tue 12:45

Heroku でのスケジュールタスクの実行(Rails の場合)

Heroku ではいわゆる cron 的なことをしたい人のために Heroku Schedulerというものが用意されています。

ですがこれはかなり問題の多いプロダクトで、シリアスな業務で用いるにはいろいろと厳しいです。まず設定 UI が非常に貧弱で、設定ミスをしても気付きづらいです。またセッション管理の点にも問題があり、自分がいじってるつもりと別アプリの設定をいじってしまうという事故はわりとよく起きます。

そして最大の問題ですが、公式のドキュメント

Scheduler job execution is expected but not guaranteed. Scheduler is known to occasionally (but rarely) miss the execution of scheduled jobs.

とある通り実行されるかどうかは無保証です。実行漏れは「rarely」だと書かれていますが、実感としてレアかどうかと言われると、ガチャのレアぐらいのレアさだなと思います。ユビレジの場合酷いときはまいにちなにか抜けてリカバリーを開発者が手動でやるなんてことをやってる時期がありました。

そこでドキュメントには

If scheduled jobs are a critical component of your application, it is recommended to run a custom clock process instead for more reliability, control, and visibility.

とありますのでこの行き方でやっていく必要があります。ようするに計時専門の Dyno を立ててそこで自前で cron 的なことをしろってわけ。 Rails の場合 resque-schedulerはよい選択肢です。設定がコードになってリポジトリに入れられるのも非常によい(デプロイターゲットに応じてこのあたりの設定をいじりたいとかなってくると欠点として認識されることもあるかもしれませんが)。

ところで Heroku の Dyno は最大でも 24 時間しか連続起動してくれません。また CLI から restart かけただとかデプロイしたとかで頻繁に再起動されます(ユビレジでは一日数回〜数十回のデプロイが行なわれます、最近ではわりとどこの会社もこんなかんじですよね?)。そうなるとその再起動のタイミングで resque-scheduler がなにかすべきだった!!!みたいなときにデプロイが走ったりすると実行漏れが起きます。体感ですけど heroku scheduler のときの半分ぐらいの頻度でこれらが原因となって実行漏れが起きました。

resque-scheduler はこういうことを想定して作られており

You may want to have resque-scheduler running on multiple machines for redundancy. Electing a master and failover is built in and default.

とあります。 Heroku でこれを活用したいときはわりと話は単純で

heroku scale scheduler=2

とかするだけです。ところが

Precautions are taken to prevent jobs from potentially being queued twice during failover even when the clocks of the scheduler machines are slightly out of sync (or load affects scheduled job firing time).

ともあり、 resque-scheduler を複数プロセス実行している場合に重複実行されるケースがあるようです。今のところユビレジでは重複実行されて致命的な事態となりうるジョブがあまりないためこの問題への対処は手をつけていません。ただしユビレジからのメールが二通届いてしまうなどという事態が稀に生じていることは確認されており、頻度次第ですが今後対処を行なう必要があるとは思います。

対処法としてはアプリ側でもう実行済みかどうか確認してハネるみたいなのが必要でしょう。実はユビレジでは一部のジョブでそれが導入されています。というのも Heroku Scheduler 時代に「1 時間に 1 回のタスクがたまに抜けるなら 5 分に 1 回実行して、アプリ側で重複実行だったら弾けばいいんじゃない?」みたいなのが導入されたからです(なおこれは多重実行されて困る系のタスクではなく、重いので実行されまくると困るというタイプのタスクでした)。

Heroku 公式のドキュメントにも説明あるし、いろいろとツールも揃っているのですが、なかなかこういう話を日本語で見聞したことがないので書いておきました。

25 Dec 2017 Mon 17:03

このサイト HTTPS 対応 + HTTPS 強制にした のだが、いろいろやりかた考えた結果 Cloudflare に金払うのが一番楽ということでそのようになったのだが、完全に Cloudflare に依存する人生という感じで危ないですね。

04 Dec 2017 Mon 16:04

優秀なプレイヤーを管理職にするなとかよく言うけど すくなくとも俺はプレイヤーとして自分よりダメな奴に管理されたくないんだよな。いいコーチはかならずしもいいプレイヤー出身じゃないとかよく言うけど、それは横綱クラスじゃないという話であって幕下の奴がいい親方になるのか?優秀なプレイヤーを十分集めてそのなかから管理職をやりたがっててかつその能力のありそうな奴を管理職にするべきなんじゃないのか。

02 Dec 2017 Sat 14:59

Nahoruru

28 Nov 2017 Tue 22:28

かに

22 Nov 2017 Wed 18:00

CDN 最高

22 Nov 2017 Wed 18:00

と思ったらうまくいくようになった、、、

18 Nov 2017 Sat 16:38

CloudFlare の purge が API 経由でうまくいかなくて困ってる

18 Nov 2017 Sat 16:38

ねむい

17 Nov 2017 Fri 16:18

修正すべきことは多分 1 行とか なんだけど、

  • 問題を理解すること
  • 影響範囲を明らかにすること
  • 分かった影響範囲に対してテストコードや人力 QA の手順を確立させること

みたいなところで膨大なコストがかかる作業をしていて、なんでかまあそれの仕切り役の一人みたいになっている(なぜかといえば職務がそういうことのリーダーシップをとることというようになったからです)。

ここでまあ問題はなにかというと「問題を理解する」のに莫大な手間がかかってしまう原因がなにかといえば、理由はまあいろいろあるんですが、その一つが俺が昔書いたコードがアレというものだからです。

我々は常に過去の自分の影と戦闘することになるのだが、今や我々のチーム力は過去と比べものにならないくらい大きいので、僕以外の人が一番厳しい部分をやってくれている。これはいつ殺害されてもおかしくない状況なので緊張感がある。

16 Nov 2017 Thu 18:36

コーヒー豆の量規定の 2 倍にしたら全然うまくなくて、規定量の正しさを感じる

16 Nov 2017 Thu 17:43

かに

16 Nov 2017 Thu 16:54

Web アプリの非同期処理に goroutine 使う の多分だめだと思うんだけどわりとみんなやってるしもうあんま気にせずやっていくことにしてくという気持ちになってきてる。

失敗してもいい非同期処理ならまあこれでもいいのだろう、、、

16 Nov 2017 Thu 16:50

頭痛い、、、

16 Nov 2017 Thu 16:47

dev.to には勝ってた

このサイトは速い

もう 1 か 2 スコア上げて阿部寛もぶち抜きたい

16 Nov 2017 Thu 02:32

日本の店舗でクレカ普及しないのってリボ払いが普及しないせい で結果としてクレカ会社が儲からないから手数料に転嫁されるせい、というのはみんなよく言ってる。

じゃあリボ払いが普及しなかったのがいいことだったのか?というとそれはどうなんだろう。貧しくて資産がなくても資金繰りさえ回ってればまあ生活はできるわけで。毎月ごとにクレカの支払い方法と借金の借り換えで苦労するアメリカ人みたいなの、大変なんだろうけど、そこでクレカという金融システムがなければ彼らが生活を維持できる時間は格段に短くなる。

市民社会の成立にはそういう金融システムというのは不可欠な要素だと言えるのではないか。では現代日本でクレカとリボ払いという要素が受け入れられなかった結果何が起きたかといえば、ロードサイドに立ち並ぶ質屋であり、そして今雨後の筍のようにボコボコと出てきている怪しげは「フィンテック」アプリであろう。これらが最悪なのが「金融サービスである」という理解をされないまま人々に利用されている点であり、特に「フィンテック」界隈に顕著だが意図的に騙しにかかっていることだ。

「これは借金である」という認識をみんながちゃんと持って、クレカのリボ払いに苦労してる社会の方が今と比べればなんぼかマシだったんではないかと思う。

08 Nov 2017 Wed 16:22

Next