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 をかけてサイズを補正してあげれば大丈夫です。

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

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

Pros

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

Cons

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

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

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

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

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 をどうにかしろという話なのですが、とりあえず逃げなければならない時だってある。

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 秒以内にはリロードされるということがテストできます。なんかもうちょっとがんばればループとか使わずにテスト出来そうな予感はありますがとりあえずこれで最低限はいける

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

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

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

非常にだるい

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

この投稿をInstagramで見る

ノーパンクタイヤ的なものを買った、取り付けがマジで地獄、乗り心地は悪い、スピードは落ちない、総じてよい

Rick Koike(@ssig33)がシェアした投稿 - 2019年11月月3日午前4時28分PST

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

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

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

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

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

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

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

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

かに

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

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

というような状況。

• How to enlarge Windows 10 EFI partition

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

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

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

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

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

そこで Google に聞くと

• Move MSR partition?

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 に沢山のカーネルを入れることができて便利になりました、よかったですね。

CircleCI (Performance Plan) vs. Github Actions

結論: CircleCI を買おう

現在ユビレジでは CI は CircleCI (Performance Plan)と TravisCI を使っていて、

• CircleCI:
  • サーバーサイド(いろんな言語がある)
  • Web フロントエンド(Rails アプリのなかで webpack が動いていたり、 create-react-app で作られたペラっとしたものがあったりいろいろある)
• TravisCI:
  • iOS アプリ

というような感じで使い分けている。 Performance Plan なんだから iOS のも Travis から引っ越せばいいんじゃねえの?と思わんでもないのだが、

• Travis の annual 課金がまだ残ってる
• iOS の CI と TravisCI と CircleCI に全部詳しいかつやる気がある人はいない

という事情があり、このようになっている。

ここで CircleCI の Performance Plan について簡単に説明すると

• 課金体系は従量課金
  • 使ってる人数*月15ドルの固定課金
  • 使ったインスタンスの時間あたりの課金
• 並列数は無制限
  • 昔は UI 上 200 並列が上限であるように見えてたけど実際どうなのかは不明。この表示自体はシステムを従来プランと使い回していた故のように思える
  • 200 並列にまだ頭ぶつけたことないので実際どうなのかは知らない、気になる人は営業に問い合わせてみましょう
• 開始時に営業に問い合わせが必要
  • 日本ブランチはあるので日本語でやり取り可能です

といった特徴があります。簡単に言うと安くて便利。というわけで CircleCI Performance Plan でテストを回していたプロダクトの一つで Github Actions を使ってみることにしました。

Github Actions はだいたい以下のような特徴があります

• リポジトリごとに 20 並列までいける
• OSS なら無料、 Private は 11 月から有料化
  • プランはまだ未発表
• 裏側には Azure Pipelines というものが使われている

今回何故か Beta 開始日から我々の組織では Actions (CI)を使うことができたので、今回僕が面倒(?)をみているプロダクトの一つで Github Actions を使用してみました。 create-react-app で開始した SPA で(現在では eject 済み)、純粋に Web フロントエンドだけが存在しているリポジトリです。テストは全て E2E テストで、 jest-puppeteer を使っています。あんまり関係ない話ですがどうも Web フロントエンド界隈ではコンポーネントのユニットテストと型でアプリを守るという思想が流行っているようですが、これらは全て無意味だと僕は思っています。型は VSCode の補完で便利という程度に捉えておくほうがよいと思う。ユニットテストはクソ。

リポジトリごとに 20 並列という制限は、大規模なモノリスがあり多くの従業員がそこで作業をしているという場合簡単に頭をぶつけることになるでしょう。ただし今回僕が Actions を仮投入してみたプロダクトは開発者が 3 名しかいないプロダクトでしたのでそこが問題になることはありませんでした。

プランについては発表しようにも評価のしようがありません。

裏側である Azure Pipelines というか CI の実行部分については、これはもう悲惨としか言いようがない水準です。

• CircleCI の一番下の VM と比べてもかなり遅い
  • CPU も遅いしディスク I/O も遅い
  • 結果としてセットアップフェイズが猛烈に遅くなり大変辛い
• サービス自体安定しているとは言えない
  • 一番辛いトラブルとしてはUbuntu のミラーリポジトリがぶっ壊れているせいで長時間まともに動かないというのがあった
  • その他なぜかいきなり落ちるとか多発

今回 CircleCI と平行するかたちで Github Actions の利用をはじめ、落ち着いてきたら Actions のほうだけに統一みたいなつもりでいたのですが、一向に落ち着くことはなかったので 8/13 に使用しはじめた Github Actions ですが 9/4 で使用を中止し CircleCI だけに戻しました。

あまりにもサービスの品質に問題を感じるため、周囲のエンジニアにインタビューをとってみましたが、 Azure Pipelines 自体が悲惨な品質で、リリース以来あまり改善されてこなかったという話をいくつか聞くことができました。

なお、今回のプロダクトでは CI で実行するあれこれの処理を Makefile に記述し、 CI の設定ファイル内では make hogehoge みたいのだけを書くようにしていたこともあり、 Github Actions の利用開始自体は 30 分もかからずに行なうことができました。このあたり一切面倒なところはありません。

全体として、 Github Actions は非常にストレスフルなプロダクトで、仕事としてやっているプロダクトで金銭的な出費が許される場合には CircleCI の Performance プランを使用することを強くオススメします。11 月に発表される料金がかなり安かったとしてもそれはそうで、出費を節約した結果 CI の不可解な挙動でエンジニアの生産性が落ちるようでは話になりません。

Azure Pipelines の改善が進まなかったことには、そもそもサービスのユーザーが多くなくメトリクスなりユーザーの意見なりを十分に収集できていなかったという可能性はあります。今後 Actions 経由でこれを利用する開発者が増えれば改善されていく可能性はあります。ただし、僕はこれまで Azure のマネージドサービスについて多くの場合において品質面での問題を感じていました。今回だけまともになることあるかなあ、、、

来年の夏ぐらいにまた検証してみたい。

待遇にも文句ないしプロダクトにも愛着は強いんだけど 環境への飽きみたいのが出てきていて、これはまあどうしようもないねえ。

最近同人誌即売会いっても 机全部みればいいじゃんみたいな感じで事前にカタログみたりしなくなっちゃって。なんかでも机全部みるのってそれはそれで見落しありそうということでティアズマガジンちゃんと見てみることにした。

ここのバックエンド Cloud Run にしたらほとんど運用費タダになった。 そこそこアクセスあったからどうなんだろとか思ってたけど Fastly がほぼ全部吸ってくれるから最高。

だるい

はい

Host ヘッダー上書きしたらアプリの動作おかしくなった けどまあなんとかなるだろう。

ここのバックエンド Cloud Run にした

ここはもともと Cloudflare (HTTPS化) => Fastly (キャッシュ) => GKE というかんじで動いていて、 GKE の部分を Cloud Run に差し替えた。

Fastly から Cloud Run を使うには、 Fastly に Host ヘッダーを上書きしてもらえばいい。そのものズバリな説明があって最高便利、よかったですね、 Fastly 最高、金払ってないけど。

React で Android 向けとそれ以外でインタラクションを分ける

コンセプトとしては

const Android = ({children})=>(
  isAndroid() ? children : null
)

const NotAndroid = ({children})=>{
  isAndroid() ? null : children
}

というようなコンポーネントを用意しておいて

<Android>
  <アニメーションとか使わない地味なインタラクション>
    <HogeFuga>
      <Nanika />
    </HogeFuga>
  </アニメーションとか使わない地味なインタラクション>
</Android>

<NotAndroid>
  <豪華なインタラクション>
    <HogeFuga>
      <Nanika />
    </HogeFuga>
  </豪華なインタラクション>
</NotAndroid>

とかこんなん。まあ Android と NotAndroid の中身は適当に想像してください。

なんでこんなことをしたいかというと、

• iOS 端末については年々 GPU が進歩している
• Windows についても Intel の IGP すらわりと進歩している
• 一方で Android 低価格機の GPU はショボいまま

という問題があるので。 Windows 環境でも若干そういう傾向はあるが、特に Android 機において低価格機の GPU は「表示できれば十分でしょ」から進歩しない。なんでこんなことになってんだと思うけど、もうそういうものとして考えていくしかないと思う。

とすると、 Android にだけアニメーションとかを適用しないショボいバージョンを見せる、という選択肢がでてくると思う。 React を使っている場合、しっかりコンポーネントを設計していれば、↑のような感じでそれなりによろしく書いていったりできるんじゃないかな、、、という考え。

実際に現時点でこんなことを実務でやっているわけではないです。今は全体にたいしてなるべくアニメーションとか使わないようなものを出していこうという方針でものを作っています。

ただ、エフェクトの有無が UX に影響するみたいなことが分かってきたら、なるべく多くの環境向けにエフェクトを出そうとかなると思うし、そうなると↑みたいな対処になるのかなーとか。

みんなこういうのどうしてるんだろう。

https://scrapbox.io/shokai/CSS%E3%83%AC%E3%82%B9%E3%83%9D%E3%83%B3%E3%82%B7%E3%83%96%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%82%92SPA%E3%81%A7%E4%BD%BF%E3%81%86%E3%81%A8%E7%A0%B4%E6%BB%85%E3%81%99%E3%82%8B からインスパイアされてこんなことを考えています。

ここの裏側 Go から ruby にもどした

仕事と給与と評価の関係

(1) 仕事の成果を適切に評価することは困難です

営業なら売り上げだろ?違います。売り上げまくってるけど CS 部門に迷惑かける客ばかりつれてくる人とかいますよね。 CRM 使えばそういう人を適切に評価することができるかもしれませんが、大抵おとぎ話でしょう。

(2) 給与ははっきりいって適当に決まります、運です

評価制度やグレード制度が決まってる場合でも結局その運用は最終的には人手なので、、、

(3) 「会社の利益を意識せよ」と言ってくる経営者を信用してはいけない

そういうことはスタッフグレードの人が考えるのであって、現場はそんなことを考えないといけないのであれば組織が成り立ってない。「会社の利益を意識する」というのは「情報の収集と評価」とより抽象化できるが、それは非常に高度で専門的なミッションであって、そんなことを片手間にやると業務執行の質がガタ落ちします。下級管理職やワーカーが利益につながる仕事をできるようにするのが上の人の仕事。

(4) どこかでダメでも別のところでならいける可能性がある

給料上がんなかったら異動願いか転職かしてみましょう

(5) とはいえどこいってもダメみたいな場合もあるかもしれない

まあ、人生いろいろある

かに

ここの実行環境 Cloud Run にしてみた

わりと気軽でいいですね

谷甲州 『硫黄島航空戦線』

マジでやばいな、谷甲州がこんなことになるところを見たくはなかった pic.twitter.com/LtW8PQ2WqT

— 小池陸@ネパール垢 (@ssig33) March 17, 2019

https://www.amazon.co.jp/dp/4125013993/

この記事を先に読んでいただければと思います。

先生の病状は明らかにさらに悪化しておられます。展開は常に意味不明で物事の前後関係は判然とせず、登場人物の人格は常に混沌としています。設定には多くの不整合があり、とても以前の谷先生の作品とは比べられるものではありません。

さらに読んでいて辛くなるのが、おそらく谷先生自身そうした自身の頭脳に迫りくる問題を、認識する瞬間があるのだろうということが文面から伝わってくるからです。

この辺とか読んでてつらい、書いてる谷先生がなにもわからなくなっていることを自覚されてこういう文面になるのだろう、、、 pic.twitter.com/ABHEsFzzUp

— 小池陸@ネパール垢 (@ssig33) March 17, 2019

言いたいことは以前の記事に全部書いたからあまり言葉を重ねたくはない。言いたくないことなのですが、中央公論新社で編集を担当されている方、なぜこれを出版してよいと思ったのでしょうか。本当によく考えてほしい。

Android 機の GPU ってめっちゃショボいことが多いから Web アプリでも Android 向けにはなるべくアニメーション出さないみたいな対処をやっていく必要がある。

React 使って普通に Web サイト書いてるだけなのに iOS と Android 向けにめっちゃコード出し分けていかないといけなくてほんとうに辛い。

iOS にもアニメーション出さない的な方向性でもいいとは思うんですけど、ユーザーテストとかするとアニメある方がずっといろいろよかったりするわけです。

React Hooks 使いまくったプロダクトリリースしました

cookpad TechConf 2019 にいってきた

面白かった、参考になったトーク

スライドとかは Qiita に cookpad がまとめを作っています。

藤井 謙士朗 - 新規サービス開発を加速させる技術とデザイン

このサービスについて、エンジニア視点で書かれた紹介記事はあって Firebaseでバックエンドエンジニア不在のアプリ開発　クックパッドが体感した、メリットと課題 これは結構面白い記事で、レスとしてこんなものを書いたりした。

KomercoではReactでWebの管理画面やティザー画面を作っていて、デザイナーがコードを書いているので、フロントエンジニアもいないんです

と何事もないかのように書かれているところに実際何があるかをデザイナーが何をしているかというのをデザイナー視点で話していた。紹介されているツールや技法は非常に興味深い一方で、

これ簡単にまとめると、プログラミングができる強いデザイナーがいると素早く開発できますみたいな感じの話で、実際ユビレジも異様に強いデザイナーがいて素早く開発できているので非常にその通りだなと思う一方、だからなんだという感じでもあります

— 小池陸@ニューギニア垢 (@ssig33) February 27, 2019

というような一面があったことも否めない。ただ強いデザイナーは強いのでどのように採用するかとか育成するかとかそういうことは常に考えたほうがいいんでしょうね。

水谷 正慶 - スケーラブルなセキュリティ監視基盤の作り方

大企業におけるセキュリティの実務の実際を何一つ知らないので聞いてもへぇとしかならないのだけど、既存の業務においてとにかく膨大な量の手作業がつまっていることはなんとなく感じられた。

リスク評価を Lambda に置いた Go で書かれたプログラムでやってることぐらいしか正直伝わってこなかったんだけど、膨大な手作業をこなしているであろうチームがこうした施策を積極的に取り組んでいることに強い敬意を覚えた次第。俺には無理だわ。

宇津 宏一 - 新規アプリ開発を支えるユーザ・決済基盤

社内向けの基盤みたいなのは非常に大変だろうし、 cookpad もガラケー時代から連綿と伝わるユーザー基盤、決済基盤などがあるなかでこういう作業をやっていくのは本当に大変なことだろうと思う。とにかく大変そう。

その他

https://tabedori.jp/ のたけのこ鳥みたいなキャラがかわいい。

ダメだこりゃというやつ

宇野 雄 - クックパッドが目指す、これからのデザインとプロダクトのあり方

2 月入社の方がクックパッドはダメですという話をして、ひたすら抽象的なトークをするというセッション。「私がクックパッドのデザインプロセスを破壊します」という話をこの人がしたあと、そのあとべつのデザイナーが「既存のクックパッドのデザインプロセスを紹介します」というトークの構成になっていて、当初は聞いていて「これ宇野さんの後の話なんの意味もないよね」と思っていたのだがまあいろいろあるらしいです。

成田 一生 - 基調講演

これは非常に悪いと感じた。「クックパッドは料理を楽しくする会社で、地球人がみな料理を楽しめるようにすることが目的」という内容だった。

この問題について、この基調講演でも触れられていたが、貧困により、料理をせざるを得ない人達というのがいることが「料理が楽しくない」ということの本質的な原因であろうと思う。この問題を解決するにあたって、今クックパッドが取り組んでいる「料理のプロセスを改善する」という方法は殆ど無意味なのではないか。

料理というプロセスがどれだけ改善されたところで、そもそも料理をしたくない人がせざるを得ないという状況があるかぎり、どうにもならない。

この基調講演において「健康的な食事を外食ですることは高い」という問題が触れられていたが、健康的な食事を安価に手に入れられるようになるか、地球人がみな豊かになるかすればいいわけで、農業とかエネルギーとかそういった問題に取り組んだほうが「みなが料理を楽しめる」という状態に早く近付けるのではないか。

LT

内容はすごくよかったのだけど、採用イベントで来場者を床にころがすのが適切かどうかについてはじっくり考えてほしい。会場の問題などいろいろあるのでこのあたり難しいことなのは分かっているつもりですが、、、

LT大盛況です #CookpadTechConf pic.twitter.com/OqOxX2ipf4

— Cookpad Tech Life (@cookpad_tech) February 27, 2019

というわけなので義務は果した。

Encrypted SNI は完全に無意味

政府の役人や政治家はまともにインターネット使ってないので Fastly や Cloudflare を丸ごとブロックしてくるだけ。あんなのにリソース使う暇あったら別のことやったほうがいい。

前ほど Fastly がアグレッシブにキャッシュしてくれない気する