Diary

@ssig33

かに

01 Feb 2020 Sat 22:48

next.js で作った動的なサイトを CDN で全力でキャッシュさせる

というようなことをしたくなることもあると思います。その上で動的なサイトの場合 CDN のキャッシュをリアルタイムで飛ばしたいことも多いかと思いますので、 CDN の選択肢は事実上 fastly 一つということになります。

この時、 next.js なアプリをどこにどうやってデプロイするかが問題になってきます。

1. ZEIT

next.js をつくってるところのホスティングサービスで、すごく簡単に使えていいのですが、キャッシュさせようと思うとすごくめんどくさくなります。ZEIT 標準の CDN とキャッシュ機構もありますが使いやすくないですし、 fastly でキャッシュさせるためにカスタムヘッダーを吐かせようとしても now.json とかにゴチャゴチャ書くことになってあまりよろしくない。

ZEIT 自体よく出来てる気はするのだがあと一歩という感じがする。

2. firebase

next.js のデプロイ先として定番だと思うのですが、今回はダメでした。 firebase の CDN はなぜか Cloud CDN でなく fastly であることがよく知られています。このためさらに前に fastly を置こうとすると firebase の fastly に Surrogate-Key ヘッダーを握り潰されてしまいます。

3. Netlify

これも定番なんだろうけど触ったことないので知らん

4. で、どうしたか

Docker で固めて Cloud Run において fastly => Cloud Run という構成にしました。カスタムサーバーは以下のようになっています。

const express = require("express");
const next = require("next");

const port = parseInt(process.env.PORT, 10) || 3000;
const dev = process.env.NODE_ENV !== "production";
const app = next({ dev });

const handle = app.getRequestHandler();

app.prepare().then(() => {
  const server = express();

  server.get("*", (req, res) => {
    res.setHeader("Surrogate-Key", "SOME_KEY");
    handle(req, res);
  });

  server.listen(port, err => {
    if (err) throw err;
    console.log(`> Ready on http://localhost:${port}`);
  });
});

URL ごとにキャッシュのルール変えたいときとかはここで Surrogate-Key 出し分ければよさそうですね。しかしまあ ZEIT にサクっと上げて超全力でキャッシュしてくれるとかそういうのできればそれが楽なのでどうにかできないのか、、、

01 Feb 2020 Sat 16:46

はーめんどくせ

01 Feb 2020 Sat 16:37

firebase の前に fastly おくと fastly => fastly になってしまってあんまりよくないっぽいな、、、

01 Feb 2020 Sat 16:25

フロントエンド firebase においたが 暖まってないと Cloud Run より起動遅いな

01 Feb 2020 Sat 15:22

ページ遷移わりと最速になった

31 Jan 2020 Fri 11:43

CDN おじさんになったところで 、潰しがきかないんだろうと思っていて、あまり深入りしないようにはしている

30 Jan 2020 Thu 23:53

Cloudflare がいらんことしていた

30 Jan 2020 Thu 23:52

test

30 Jan 2020 Thu 23:48

キャッシュできてるけど思ったとおりに飛んでねえな

30 Jan 2020 Thu 23:37

もうちょっといじって

Cloudflare(HTTPS化) => Fastly(キャッシュ) => Cloud Run(ここで next.js 動かす) => Cloudflare => Fastly => Cloud Run(Go で書かれた API)

という構成にした。

30 Jan 2020 Thu 23:35

CDN 沢山つかってるとキャッシュとばすのまじでめんどう

30 Jan 2020 Thu 22:58

キャッシュ

30 Jan 2020 Thu 22:34

おなかすいた、、、

30 Jan 2020 Thu 18:13

コアラ

30 Jan 2020 Thu 18:00

ゴリラ

30 Jan 2020 Thu 17:59

サイトの構成かえた

Cloudflare (HTTPS 化) => Fastly (キャッシュなど) => ZEIT (next.js の実行) => Fastly(キャッシュ) => Cloud Run (Go で書かれた API)

というような構成にした。だいぶ破滅的でやばいがいろいろいじりやすくはなった。

30 Jan 2020 Thu 17:45

ジャバ

30 Jan 2020 Thu 15:33

ねむい

30 Jan 2020 Thu 14:37

canvas を使って画像をトリミングする

const img = document.querySelector('img');
const canvas = document.createElement('canvas');
canvas.width = width;
canvas.height = height;
const context = canvas.getContext("2d");
context.drawImage(img, x, y, width, height, 0, 0, width, height);

というようなコードが紹介されることが多いですが、ダメです。これはディスプレイの解像度が伝統的な 96DPI になっていることに依存したコードで、現代的な HiDPI 環境では思った通りに動きません。

こうした問題に対応するためにwindow.devicePixelRatioという値を使用することができます。

const ratio = window.devicePixelRatio;
const img = document.querySelector('img');
const canvas = document.createElement('canvas');
canvas.width = width * ratio;
canvas.height = height * ratio;
const context = canvas.getContext("2d");
context.drawImage(img, x * ratio, y * ratio, width * ratio, height * ratio, 0, 0, width * ratio, height * ratio);

というような感じで devicePixelRatio をかけてサイズを補正してあげれば大丈夫です。

14 Jan 2020 Tue 14:22

Qrio (旧モデル)から Sesami mini にかえた

転居に共ない鍵が 2 個ついてるドアになったので Sesami mini に変えてみた。セールで 1 個 1 万ちょいとかで買えた。

Pros

  • 安い
  • 取り付けしやすい
    • 高さ調整の仕組みはこっちのほうが使いやすいと思う
  • 自動開錠は Sesami のほうがまともに動くと思う
    • とはいえ家の中の移動で自動開錠誤爆されたりするので正直今一ではある
    • Qrio は開かない、こっちは開きすぎという印象
      • 自動開錠開きすぎ問題に対処するための答えがノック開錠という機能なのだと思うが、ノックのほうも誤爆多い感じなのでいまいちです

Cons

  • 開閉の認識が正直いまいち
    • 閉まってるのに開いてる(あるいは逆)と認識しがちなので、開閉の設定のところでちゃんと動くような設定を詰める必要がある
    • これがあるので完全に Sesami だけに頼って鍵は一切持ち歩かないという運用はちょっと怖い
      • 怖いけどまあ最悪どうにかなるだろの精神で鍵持ち歩いてませんが
  • 鍵の共有が鍵の近くじゃないとできない
    • 遠隔で鍵をわたすには WiFi に接続するための高いやつを買っとかないとダメみたい
    • 家にくる予定の人に「鍵渡しとくからよろしく」とかは出来ない
      • まあそんなことしたの結局 2 回ぐらいしかないんでそんな問題ではないと思う

ほかにもいろいろあるらしいが乗り換えた感想としてはこんなもん。開閉の認識がいまいちという問題があるのでちょっと怖い。そういうものだと認識して確認しながら使ってるので今のところ締め出されなどの問題は発生していないのだけど、 Qrio と比較すると安心感は低い。

とはいえ値段の差を考えればというところではある。

Qrio Lock (新モデル)のことはよく知りませんが、金があるなら Qrio Lock のほうがいいのではないかという予感はしている。しかしまあ Sesami でも別に困りはしてないです、以上です。

18 Dec 2019 Wed 17:18

React でレンダリングを遅延させたい ということがありまして。

const Todesking = ()=> {
  return <>
    <LightComponent />
    <UltraHeavyComponent />
  </>
}

このようなコンポーネント。 LightComponent のレンダリングは一瞬、UltraHeavyComponent は複雑な state の処理が遅い。で、 LightComponent の中身はとりあえずさっさと表示しておくと UX が向上する、というような事例。そういうことありませんかね?

そこで以下のようなことをした。

const useDelay = msec => {
  const [waiting, setWaiting] = useState(true);
  useEffect(()=>{
    setTimeout(()=> setWaiting(false), msec);
  }, []);
  return waiting
}

const Todesking = ()=> {
  const waiting = useDelay(200);
  
  return <>
    <LightComponent />
    {!waiting && <UltraHeavyComponent />}
  </>
}

指定した msec だけレンダリングの発生を遅延させる。今回はトランジションとのかねあいなどでレンダリング開始を遅延させる時間を場面ごとに調整したかったので、こんな感じのカスタムフックを作ってみました。

完全なる大破滅、こんなことをするなら UltraHeavyComponent をどうにかしろという話なのですが、とりあえず逃げなければならない時だってある。

05 Dec 2019 Thu 15:44

Rails の system test case でブラウザリロードのテスト

そういうことをしたくなることもあると思います。一般的には minitest より rspec を使ってる人が多いような気はしますがそのあたりは適当に読み替えてください(今は rspec も system test case 使えるんだっけ?よく知らない)。

Capybara には evaluate_script というものがあり、ブラウザには performanceNavigation.type(MDN) というものがあります。

というわけですっごい雑ですが以下のような感じでリロードの仕様に関するテストが書けます。

以下のようなページがあるとして

<h1>todesking</1>
<button class="todesprincess" onClick={()=> location.reload()}>リロード</button>
test "button を押すとブラウザがリロードされる" do
  visit "/todesking"
  assert_selector "button.todesprincess", count: 1
  
  assert_equal 0, page.evaluate_script("performance.navigation.type")

  
  find("button.todesprincess").click()
  
  reloaded = false
  100.times do
    reloaded = 1 == page.evaluate_script("performance.navigation.type")
    break if reloaded
    sleep 0.1
  end
  assert reloaded
end

こんなかんじ。これでとりあえずボタン押したら 10 秒以内にはリロードされるということがテストできます。なんかもうちょっとがんばればループとか使わずにテスト出来そうな予感はありますがとりあえずこれで最低限はいける

03 Dec 2019 Tue 10:19

LAN ケーブルを作る作業員として余生を過している

18 Nov 2019 Mon 14:25

昔はサーバー代ケチるためにめちゃくちゃやるのが好きだったんだけど 今は Cloud Run とかのおかげでほぼなんでもかんでもタダになってかつ全然全体の構成にも無理がないみたいになって、世の中便利になったんだけどこれはこれで非常に寂しいものがある。

14 Nov 2019 Thu 16:57

Go でひさしぶりに Web アプリを書いてみたが 特に思うところは、、、という程度の書き味であった

14 Nov 2019 Thu 16:55

非常にだるい

14 Nov 2019 Thu 16:36

ノーパンクタイヤを買った

ライダーズカフェというところのノーパンクタイヤを買ってみた。

とりあえずつけてちょっと走り回ってみた。

まず、取り付けはこの世の地獄。楽天などでレビューを見ると 30-120 分はかかるとみんな脅しているが実際それくらいかかるのは覚悟したほうが良い。金属製のタイヤレバーを持っているとわりと話が速いと思う。ある程度はめ込むことができたら、その部分をテープでぐるぐる巻きにして次にいくみたいな破滅的な手法も非常に有効。また、以下の他社製品の取り付けの様子も参考になる

乗り心地はかなり悪くなる。今回後輪だけこれにしてみたが、振動がダイレクトに体に来るので結構不愉快。一方で速度低下は一切感じない。またスリップもない。今回買う前にこの手の商品をいくつか調べたのだが「たしかにパンクしないがいつでもパンクしてるような乗り心地」みたいなレビューがついている商品が多くかなり身構えていたのだが、これにかんしてはそういうことはなくかなりよかった。

今回これを買った理由としては、

  1. リムがへこんでそこからパンクしまくるホイールがある
  2. とはいえ金使いたくないしそれを使いまわしたい
  3. ノーパンクタイヤならまあなんとかなるんでは

という思惑で、これにかんしてはうまくいったといえる。一方で、振動がここまでガタガタ来るところからするとフレームやホイール、特にホイールにはかなりのダメージが行くと考えたほうが良いと思う。今回は廃ホイールの再利用という理由もあったのでこれで非常に満足しているが、じゃあみんなもこれ買えばいいよとは言えない。

そんなに長距離乗るわけでもない自転車でパンクがまじでだるいみたいな人は選択肢に入れてもいいと思う。調べた限りこのジャンルの最有力選択肢のタンナスというメーカーと比較して 1/3 ぐらいの値段なのでとりあえず買ってみるみたいなことができる価格帯なので。

03 Nov 2019 Sun 21:38

かに

24 Oct 2019 Thu 16:14

Windows が生成する EFI System Partition (ESP) を拡張する ということをしたくなることがあるかと思います。具体的には

  1. Windows が入ってたところにマルチブートで Linux 入れたい
  2. Windows が生成した ESP を boot として使いまわしたい
  3. しかし Windows が生成した ESP は 100MB しかないのでカーネルが複数入らない
  • Linux 用に ESP 別途生成すればいいんですかね? ESP mutiple とかで検索しても「ESP を複数作る必要はない、使い回せ」みたいなことばっか書かれていて辛い

というような状況。

という Q&A を読むと、 MiniTool Partition Wizard Free を使うとよいであろう、とあります。これで実際に希望の要件を達成することができましたが、若干面倒な操作が必要でした。

Windows を何も考えずにインストールすると

  • ESP :100MB
  • Microsoft Reserved (MSR): 16MB
  • C:

の 3 個が生成されることが知られています。で、この MSR がなんなのか俺は知らないし知ろうとも思っていないのだがとにかく消してはいかんらしい。

MiniTool Partition Wizard Free では C: を縮小して後ろにつめることもできますし、 ESP を拡張することもできるのですが、 MSR を処理することは一見できないように見えます。

そこで Google に聞くと

What you can do is to Copy the MSR partition to an unallocated space block

とあるので信じます。すなわち MiniTool Partition Wizard Free 上で

  1. C: を縮小して後ろにずらす
  2. MSR を後ろにコピーする形でずらす
  3. もとの MSR を削除する;
  4. ESP を空いた部分に拡張する

という操作を予約し、適用します。すると期待どおりに ESP が拡張されますし、 MSR をこのように移動させても Windows の挙動に問題はないようです。ようですと書いたのはこの操作をしてからまだ 10 時間程度しか経過していないために副作用があるかどうかを知らないからです。

とにかくこれで Windows が生成した ESP を拡張して /boot に沢山のカーネルを入れることができて便利になりました、よかったですね。

19 Sep 2019 Thu 14:00

Next