Diary

表の画像を取得する API を作りたい

そんなこともあるかと思います。具体的には Slack にスッと表を貼りたいとかそういうときね。 Block Kit 使えばもしかしたらできるのかもしれないけど、あんなもん覚えたくないし Outgoing Webhook かなんかで一瞬で実装できるとよい。

table image creator とか適当に検索してもあまりいい感じの結果が得られなかったので、数十秒考えた結果以下のようになった。

1. HTML で普通に table を作る Web アプリを作る
2. puppeteer でそれにアクセスして table の中身をスクショして画像を返すのを express で作る

で Slack に画像を貼る場合は、 Outgoing Webhook がきたら 2. にアクセスして画像を得て Gyazo に投げてその URL をリプライするという web アプリをさらに作ります(アクセス事に別の画像 URL を得たいのと、 puppeteer を使う重いアプリに Slack 接続者がみんなアクセスしてきたら嫌だから)。

で、できたのが以下のようなもの。

Web アプリが 3 個もあって大変ですが、 Cloud Run にデプロイしておけば運用コストはタダみたいなもんだし本当によかったですね。

もうちょっとスマートに実装したいところですが、とりあえず個々のアプリ自体はシンプルなのでこれでよしとします。

それでも Rails のアップデートをする

Rails 5.0 あたりから DHH らが考える Web 開発と自分の手元にあるソフトウェアの設計の乖離が激しくなっていると感じていて、まあはっきり言えば Rails のアップデートでうれしい、と感じる機会は減っている。

Web アプリケーションフレームワークは Rails のようなフルスタックなものより Sinatra/express 風のシンプルな DSL 風のものが好まれるようになっていて、歴史に Rails が残した影響が何かといえば「assets pipeline を導入したことにより、 Web フロントエンドを別言語から JS/CSS にコンパイルするという習慣を広く普及させた」ということになるのではないか、と感じている(GWT とかまあいろいろあったけど Rails 3.1 によって決定的にこういう考え方は普及したでしょう)。

Action Cable も Webpacker も Active Storage も Action Mailbox もつかってないし、 Action Text は正気の沙汰とは思えないし、 Rails が公式にサポートするずっと前からテストは並列化していた。データベース単位のコネクション切り替えを使うぐらいならリードオンリーなスレーブにつなぐマイクロサービスを導入するほうが楽だなと感じるしそのようにしている。

それでも Rails のアップデートには追従し続けていて、僕がメンテしている Web アプリケーションはだいたいどれも Rails 6.1 で全部テストが通っていて、年明けには多分 Rails 6.1 版をリリースする。

なんでこんなことをしているか、ということなのだけど。 Rails は目玉の機能以外にも当然いろいろと改善が行われていて、まあはっきりと言えばそれで互換性が壊れていく。互換性が壊れると手元のアプリも壊れることになるんだけど、それはだいたい「とても悪い書き方をしていて、意味不明なエッジケースを踏んでいるところ」が壊れる。

メンテナ達は互換性を壊したくて壊してるわけじゃないので、こういうものについて報告すればまあ Rails 側が直るんだけど、鉱山のカナリアのようなもの(?)で、 Rails のアップデートに最速についていくと悪いコードがそのタイミングで明らかになる。

そういうものを直すタイミングとして結構いいきっかけになるので Rails のアップデートには追従し続けている。しかし、まあ、その程度。

Rails の ActionMailer で正しく view の helper を使う

Rails の ActionMailer では Rails ActionMailer helper とかで検索すると、「ActionMailer で helper メソッドを使用するには add_template_helper を使おう」というような記事が複数ヒットする

• 例
  • ActionMailerでhelperメソッドを使用する - Qiita
  • How to use my view helpers in my ActionMailer views?

他にもたくさんこう書かれている記事がある。しかしなんとこれは実は間違ったやり方である。 ActionMailer::Base を継承したクラスで add_template_helper というメソッドが使えるのは ActionMailer::Base が include AbstractController::Helpers しているからで、では AbstractController::Helpers を実際に見てみると実はなんと add_template_helper は private なメソッドで Rails の利用者が使うことを想定していない。

で、簡単に調べた限り Rails 3.0 の時からそのようになっていた。

結果として、このメソッドはこのコミットで削除されてしまい、そしてそのまま Rails 6.1 でこのコミットはリリースされた。おそらく結構いろんなところで Rails 6.1 にするだけでメール送信まわりが壊れていると思うのだが(すくなくとも俺がメンテしてるアプリ 4 個で壊れた)、もちろんこれをコミットした人やこれをリリースした人が悪いのではなくて、 private メソッドを使うバッドノウハウを広げていた人やそれを無批判に採用していた人が悪い。俺も悪い(自分でそのコードを書いたことはないが気にしたこともなかった)。

ではどうすべきだったか、というと Rails 3.0 の時点でそうであったように、以下のように書くのがよい

class HogeMailer < ActionMailer::Base
  helper :hogehoge # 使いたいヘルパーファイルをこのように指定する
end

とっても有名な OSS について 10 年以上にわたって間違った、とても悪いノウハウが広まっていて特に訂正される気配もなかった、というお話でした。

SQL で 10 行に 1 個ずつデータを取得したい

何を言ってんだ？って感じですが時系列に記録されているデータの場合そういうこともあると思います、今あった。

こんな雑なテーブルがあるとする。で、これにたいして created_at で並べたのにたいして 10 行に 1 個合計 50 行取得したい場合以下のようにすればよい。

select * from(
  select 
    JSON_EXTRACT_SCALAR(body, '$.nanika.nanika[0].nanika') as nanika, 
    created_at, 
    ROW_NUMBER() OVER (ORDER BY created_at DESC) as number
    from `garbage_table`
  )
where MOD(number, 10) = 0
imit 50;

今必要に迫られて書いたのがだいたいこんなんだったんですがもっとシンプルに書けるかもしれない。

常識的に考えればこんなクエリ吐いたりすることなんてまずないんですが、常識が通じないシチュエーションはあるし、そういう時 BigQuery であればこんなクエリにたいしてもすばやく結果を返してくれる。よかったですね。

React アプリ構築するときのディレクトリ構成とかについて最近やっていること

こんにちは。私は最近 React アプリを作る時以下のようなディレクトリ構成でやっていっています。

src/ ---> App.tsx
      |---> Components/ ---> Fuck/ ---> index.tsx
      |                  |          |-> useSomething.ts
      |                  |          |---> SubComponent/ ---> index.tsx
      |                  |
      |                  |-> Shit/ ---> index.tsx
      |
      |---> hooks/ ---> useGarbage.ts
      |             |-> useShit.ts
      |
      |---> store/ ---> index.ts
                    |-> modules/ ---> gomi.ts
                                  |-> unko.ts         

store 以下は redux を使う場合で Ducks っぽい奴がいます。しかし最近はもう useState で済まして redux 使わないことも多い(あんまり SSR しないなどの事情もあり)。

非常にシンプル、かつ Components 以下にとにかくなんでもコンポーネントを置いて、さらにコンポーネントの中は秩序をあまり求めない、というルール。サブコンポーネントを複数持った巨大なコンポーネントもいれば、 4 行ぐらいしかない超小さいのもあったりする。

Component について比較的よく見るのが「画面」と「それ以外」でさらに分類する、というようなやつで、僕も昔はそれをやっていたんですが辞めました。というのも何が「画面」なのかは恣意的な分類で意味がないという考えに至ったからです。よくある感じだと react-router で URL 振られているもののトップコンポーネントを「画面」とみなすとかそんなんでしょうか。しかしそれだけ特別扱いする理由もとくにないです。

またモバイルファーストなアプリの場合、モーダルのような挙動であらわれて完全に全画面占有しているものにたいして URL をふるかどうかっていうのも場合場合によって決まってくるし、あるいは PC 版では画面の一要素でしかないものがモバイル版では URL を振ったうえで全画面占有であるといったこともあり得ます。

React Native の場合はさらに難しく、 react-navigation を多段で使っているとかごく普通のことで、結局「画面」というのは極めて恣意的な分類であることがわかります。

というようなことを考えていくと React Component をなんらかのかたちで分類していくことは非常に恣意的で自転車小屋になりやすいのではないか、ということでとにかく全部 Components に入れるし中の実装にもルールとして干渉しない、というふうに今はやっています。 Components ディレクトリ以下にはたくさんディレクトリができますが、まあでもそれで困ってないです、今は。

ただこのあたり今ぼくが働いてる会社のチームの規模だとこれがいい、という話でスキルレベルがもっと分散してたらルールで縛るとか必要になるし、規模が大きいチームだともっとマイクロフロントエンド的な何かでやっていく必要がでてきたりもするでしょう。

まあでもこれくらいの脳筋でも案外どうにかなるっていうか結構快適ですよ。

next.js の SSG は糞

ぼくは next.js 結構好きでこのブログとかも next.js で作ってるんですが、最近の next.js の方向性にはちょっと危うさを感じています。 next.js
は最近は静的サイトジェネレータ+αみたいな感じになっていて、サーバーサイドジェネレーションなる機能のサポートが入っています。

でもこれどう考えてもゴミでしょ。いや記事が 500 件とかならいいけど、 50 万件あったらデプロイのたびにどんだけ時間かかる？という話で。それからサイトが生きているかぎり結局のところ記事はどんどん増えていく以上トップページは動的生成にならざるを得ないわけで。あまりはっきりと言われているわけではありませんが、 next.js を開発している人たちは WordPress のテーマを PHP で書きたくない人というペルソナをもとに開発していて、その人たちは CDN を自分で使いこなすことはできないという前提を持っているような気がします。

実際のところ、 WordPress + next.js + SSG で幸せになれる人というのは一定数いるとは思うのですが、それで幸せになったとしてある時自分で足回りの面倒をみないといけないときがきます。 vercel にデプロイすれば幸せになれるかというと、 vercel そんなに出来よくないというか、はっきりと言えばまあゴミです。

で、自分で CDN の面倒みられるなら SSG なんかせずに SSR 使ったほうが楽です。 SSG できていないもの(デプロイ後に追加されたコンテンツや歴史が積み重なっていて SSG できないコード)については結局 SSR するしかないわけですから、単純にやることが一個減りますし、 redux だって使えるようになります。

最近の進化の方向性は別として better react-router + SSR としての next.js は極めて便利なのでまあ当面使っていけばいいと思いますが、 vercel が上手く行くとはとても思えず長期的には依存したくない(とはいえ react-router を使いたくない)という複雑な気持ちで生きている。

特定セッションをあとからつぶせない(やるなら全消しになる) というのを受け入れるだけですべての設計が楽になるのを改めて感じている。現状 Rails の cookie store 使ってるので現状と変わらないといえるのだが、せっかく認証いじっていくならここも現代的にしたいねえ、などと思ってしまう。

複数の問題を一気に解決しようとするのはいい態度ではないが、一方現状弊社のサービスの認証のありかたが現代で受け入れられるものなのかとかもあるので、このあたりよくよく考えないといかん。

彼自身は私怨はないみたいにいってて、いやまあ実際そうなんだろうけど とはいえ彼のなかに「広報」という職種に対するトラウマがあるように見えてならなくて。

それはもうしょうがないよね、セキュリティやプライバシーに対して誠実であることと、資本主義下の企業の広報というの、利害が一致しないケースはそれなりにある。そして「技術者」がプロフェッショナルであることが求められるように「広報マン」も当然プロフェッショナルであることが求められるし、そこで対立することはむしろ推奨されたりする。

俺は大企業にいたことがないからそれがどんなに辛いものなのかは知らない。かなり辛いことだろうとは思う。しかしそのうえで「広報」という職種にたいして攻撃するようなムーブが問題解決、すなわち note のユーザーの利益に繋がるとはとても思えなくて。

「広報」と「技術的な誠実さ」は基本的には両立するものだけどある時には対立する、みたいなことを前提にしたとき、この矛盾を最終的に解決するのは CTO と COO の議論であるはずで、 note のあのあまりよろしくない広報は、広報マンの誠実さが不足しているというよりは、職種間の縄張り意識とムーブの調整をすべき経営層のほうに問題がある可能性が高いのではないかと思う。

いや「彼」がそんなことを分かっていないとは思えないし、明確に個人攻撃をしているというわけでもない。ただ、技術者の立場に共感して「広報」を攻撃しているとしか見えない発言が多く、そしてなんというかそれに乗っかっている人も多い。このままだと結局誰も得しない結果となり事態に真に責任を持つ人は自分の態度を改めることもなく、最終的に再びユーザーのプライバシーがまた侵されるという事態になるんではないですかね、これ。

えび

@babel/plugin-proposal-do-expressions 便利だなと感じるのだけど これを便利と感じる時点で何かが間違っているんでしょうね

かに

認証自作、 Rails 、 Devise

https://ockeghem.pageful.app/post/item/uQFX4oRNbnax82V

これを読んで思ったことなんですけど、 Ruby On Rails 界隈では「認証は自作すべきではない、デファクトスタンダードの Devise を使うべき」という考え方が一般にあるように思います。

ではその Devise なんですけど、ドキュメントに以下のようにあります。

Starting with Rails?

If you are building your first Rails application, we recommend you do not use Devise. Devise requires a good understanding of the Rails Framework. In such cases, we advise you to start a simple authentication system from scratch. Here's a few resources that should help you get started:

https://github.com/heartcombo/devise#starting-with-rails

「Rails について深い理解がないならば、 Devise は使うな」とあります。この方針は10 年近く前から書かれています。

これは実際大変重要な指針で、例えば Devise はログイン時にログインした IP アドレスを User モデルに保存しますが、この User モデルを何も考えずに to_json して公開 API として提供してしまえば、ログインユーザーの IP アドレスが漏洩してしまいます。これがどういう問題かは今まさにホットな出来事です。

はっきりといえば Devise は「やりすぎ」「おせっかい」なライブラリであり、実際に Rails のフレームワーク、認証認可の知識、セキュリティや法務の知識がある程度そろっていなければ使いこなせないライブラリです。

なので僕はこれは絶対に使ってはいけないものだと思っています。まず自分自身が「good understanding of the Rails Framework」を持っていると自信を持って言い切れるでしょうか。僕はその自信はありません。例えそう言い切れるとしても、あなたが作っているプロダクトにかかわる人員が今後絶対に「good understanding of the Rails Framework」を持っていると言い切ることができるでしょうか。そんなことはありえないのであって、いつかどこかでチームはジュニアレベルのエンジニアを受け入れるものです。

私なら枯れたソフトウェアを使います。

徳丸さんのいうところのこの言葉は真実だとは思うのですが、コミュニティにおいて深く受け入れられており、 10 年以上の歴史があるような認証ライブラリが、安心して安全に使えるものだとは言い切れません。すくなくとも Devise という悪い実例があります。

じゃあどうすべきかとか言われると僕もどうしたらいいのか分からないのですが、「デファクトスタンダードになっていても案外信用はできない」「README はよく読め」ぐらいはすくなくとも言えると思います。

next.js の SSG がどうにも受け入れられなくて SSR + CDN でいいじゃんって思う。いや SSG 的な発想でもいずれにせよ CDN 層は必要なわけでしょ。結局事前ビルドとインクリメンタルビルドという複雑さを導入してるだけで誰も幸せにならないんじゃないの？

vercel のマーケティングありきという話なら、それこそ複雑さは vercel 側に寄せればいいだけの話で、わざわざ事前にビルドされるという複雑さをユーザーが認識しないといけない理由が分からない。 CDN よく分かんなくて nginx で直接アプリ配信してますみたいな人でも速度を得られるメリットがあるのか？ そのニッチってどれだけ存在してるんだろうか。でも EC2 の IP アドレス直接公開してるような Web アプリ/サイトってよくあるからそこが幸せになると幸せな人って案外多いんだろうか。

CDN とフロントエンドのことを毎日考えて生きてる人が地球規模で案外少ないことはなんとなく最近理解したけど、これって本当に楽しいのでみんなもやろう。このサイトは fastly + next.js の SSR + Go で書いた API みたいな感じでうごかしている。

鶏肉のすき焼きが食べたいが、調べたらわりと高くてがっかりした

セキュリティ

脆弱性をみつけたときに

1. 適切な手段で連絡をとって迅速になおしてもらう
2. 連絡とっても直してもらえないので粘り強く連絡を続けて問題を認識してなおしてもらう
3. 連絡とっても直してもらえないので、適当にインターネットでバカにしたりゼロデイしたりして燃やしてなおしてもらう

全部やった経験があります。 1. についてはなんの問題もありません、素晴しい。では 2. と 3. とを比べたときに、あきらかに、 3. の方が問題がはやく解決して、個人情報やユーザーの資産が晒される脅威も減るわけです。そしてこれははっきりと言っておきたいのだが、 3. はとても楽しい。これ以上に楽しいことはなかなかない。安全が守られ、自分も楽しい、素晴しい。

で、それでいいのか?ということなのですが、 3. をやっている人、知人だったりそうではなかったりしますが、そういう人って気付くと技術者としてダメになっていき、最終的にはインターネットで管を巻くだけの気持ち悪い何かになっていることが多いことに僕はある時気付きました。で、今ではあんまりそういうことをしなくなっています。

ただまあ若い人はガンガンゼロデイしたほうがいいと思います。

Heroku のデータベースには RDS を使ってよい(あるいはそれが嫌なら Heroku を使うべきではない)という話

Heroku を使うときに問題になるのは、データベースに何を使うかということです。

• Heroku 標準の PostgreSQL
• Amazon RDS
• ClearDB (Heroku で MySQL を使えるアドオン)

などが代表的な選択肢としてあります。ここで Heroku 公式が公開している RDS を使う方法についてのドキュメントを見ると、 RDS のインスタンスをインターネットに全公開して Heroku から接続せよと書かれています。

ネットワーク的な防壁がそろった環境が当然の現代においてこの方針はいかにも許容できないもののように思えます。しかし、ここで ClearDB と Heroku 標準の PostgreSQL について考えてみましょう。

まず ClearDB ですがこれはインスタンスがインターネットに全公開されています。 RDS を使う場合と同じです。そして標準 PostgreSQL のほうですが、これは Heroku 内部からしか接続できません。しかし、アカウント A のφというアプリにデプロイしたインスタンスにアカウント B のΩというアプリから接続することが可能です。このため攻撃者は Heroku 内部に攻撃環境をデプロイすればいいだけのことで、実質的にはインターネットに全公開されているのとまったく変わりません。

なので結局のところインターネットに全公開した RDS を使う以上のセキュリティを Heroku 環境で簡単に獲得することはできません。このため、運用コストが低い Amazon Aurora を使うことが最も現実的な選択肢になりますし、またこれが生理的、セキュリティ的に嫌という場合は Heroku を使ってはいけません。

ですがクラウド各社が「Heroku っぽいんだけど Heroku ほど便利ではない」というものをリリースしてきたというのが結局のところこの 13 年の大いなる歴史だったと言えると思います。セキュリティ的に通常の Heroku が許容できない場合、 Heroku Enterprise の Heroku Private Spaces (自分の VPC 内ですべてが動く)を検討する価値は十分にあるでしょう。ただ高いのでおすすめはしない。

Remmina は拡大できるのに mstsc は拡大できなくてつかえねーな などと長年思っていたが、実は 5 年ぐらい前から mstsc も拡大できるようになっていたということをさっき知った。

流行りのフロントエンド技術よりもサイト構築や SEO の基礎知識のほうが重要だ みたいな主張があり、 WordPress のカスタマイズをしている人たちがこれを言いがちであり、実際間違ってないと思います。

では我々(我々とは誰か？)がそれに対していえることが何かというと、 PHP と jQuery で頑張って WordPress をカスタマイズするよりも JSON API と nuxt.js/next.js でサイトを組んだほうが簡単だということです。

WordPress のカスタマイズをやってきた人たちは長年のノウハウを積み上げており、それを活用してバリューを出しているわけですが、 nuxt.js でやっていっている人たちが熟達したとき、すべてが破壊されます。

じゃあ実際僕が nuxt.js でかっこいいサイト作る仕事して WordPress の人たちの仕事を奪っていくぞ！！！という気持ちになるかというとならないわけで、なにかというとその仕事の給料がせいぜい年収 550 万円とかであることを知っているからです。なので、 PHP と jQuery と熟練の現実の Web の知識さえあればキャリアを通じて逃げ切れる可能性も高いとは思います。

ただまあ逃げ切れなかったからといって何の心配もなくて、 React や Vue ってマジで簡単なんで、 jQuery で UI やアニメ組める人なら一瞬で使えるようなると思う。

これを書き始めた 5 分前の俺は何を言いたかったんだろうか。すべてを忘れてしまった。

ボケンミホドボが販売するコデマクロシのカヒシオ

僕は Amazon で安いロボット掃除機を適当に購入するという趣味を持っています。 Amazon には怪しい中華商品が大量に散乱しており、そのなかから良い商品を見抜くために以下のようなことに注意せよとよく言われています

• 商品名の先頭がブランド名になっていないものを避ける
• 商品一枚目の写真に余計なエフェクトがのっているものを避ける
  • 上記 2 項目は規約違反なので
• レビューが不自然な商品を避ける
  • 不自然に 5 が多いとか同じ時期に大量投稿されてるとか、その商品しかレビューしてない人がたくさんいるとか

しかし少なくとも格安ロボット掃除機というカテゴリーにおいては、これらのノウハウはほぼ役に立たないものだと思います。理由としはいくつかあります。まず格安ロボット掃除機ではほぼすべてレビューは捏造されており、商品名や商品写真は規約を守っていません(というよりこれらの規約はほぼ有名無実化しています)。

ではこの分野の商品が全部ゴミなのかというとそうではなくてそこそこ使えるものもたまに転がっています。その「使える」商品をどうやって探すのかというと、それはもう返品の繰り返しです。買って、 2-3 回使ってみて、ダメであれば返品します。体感ですが 1 万円未満のゴミロボットの使える率は 10% 無いぐらいです。

この時、他人の言うことを信用してはいけません。それは以下のような理由からです。

• 家の中のコンディションが人によって全然違う
  • 築 30 年で家の中に畳や段差がたくさんある家に住んでいる人と、新築でバリアフリーで段差がまったくない家に住んでいる人ではまたく事情が違ってきます。段差を乗り越えたりする性能や落下防止センサーの性能の重要性は人によって違うわけです。
• ロボット掃除機に求めるものは人によって違います
  • ロボット掃除機だけで掃除を済ませたい人とたまに手動で掃除をしてロボット掃除機はある程度掃除してくれればいいみたいな人がいます

このため、自分の環境にあった商品を見つけるためにはとにかく手当たり次第に買ってみて使えるもの以外返品するというのがもっとも近道となります。幸い Amazon の返品はそんなに大変ではないので、ある程度これを繰り返していると安いけど使えるロボット掃除機を見つけることができるでしょう。

ボケンミホドボが販売するコデマクロシのカヒシオは少なくとも僕の環境ではかなりよく使えました。吸引力は弱いですが毎日走らせてればそんなに問題ありません。

じゃあこれをこれを読んでいるあなたにもオススメするかというとオススメしませんが、、、

Recoil

どういうライブラリなのはか他所をみてくれ。簡単にさわってみた。設計の要点としては、 atom の key がグローバルユニークなんで、

• src/states/session.ts
• src/states/posts.ts
• src/states/garbage.ts

みたいな感じで Recoil の states はディレクトリ上で一箇所にまとめるのがよいと思う。各ファイルは ducks のモジュール + α のようなイメージ。具体的には以下のような感じ(型はめんどいのでつけてない)。

garbage.ts

import { useSession } from './session';
import axios from 'axios';
import { atom, useRecoilState } from "recoil";

const garbagesState = atom({
  key: "garbages",
  default: [],
});

export const useGarbages = () => {
  const [garbages, setGarbages] = useRecoilState(garbagesState);
  const { session } = useSession();

  const fetchGarbages = async () => {
    const res = await axios.get(
      "https://example.com/api/v3/gomi_no_yama",
      { headers: { Authorization: `Bearer ${session.accessToken}` } }
    );
    setGarbages(res.data.garbages);
  };

  const updateGarbage = async (garbage) => {
    const res = await axios.post(
      `https://example.com/api/v3/gomi_no_yama/${garbage.id}, 
      garbage,
       { headers: { Authorization: `Bearer ${session.accessToken}` } }
    );
    const newArray = garbages.map(g => g.id === garbage.id ? res.data.garbage : g);
    setGarbages(newArray);     
  };

  return { garbages, fetchGarbages, updateGarbage };
};

状態の管理と API アクセスを redux で無理するよりもはるかに綺麗に React Hooks の形でカプセル化することができる。これは非常に革命的だと思う。

リモートデスクトップ

Web 開発するために Linux につなぐ前提

• VNC
  • xrdp が簡単にまともに動く時代なので特に選択する理由はないと思う
• xrdp + なんらかの VPN
  • とても安定している
  • Debian 10 とかだと何も考えずに apt-get install xrdp で動く
  • VPN の世話は面倒
    • AWS Lightsail に Pritunl を入れているが、 AWS からインターネットに出ていくことになった結果ちょいちょいアクセスできないサイトとか出てくる
  • Windows/Mac/Linux のクライアントで修飾キーがちゃんと動く
  • Chrome OS で動かない
  • iPad 用の公式 RDP クライアントで物理キーボードの修飾キーがちゃんと動く
• Chrome Remote Desktop
  • たまに刺さるがそこそこには安定している
  • セットアップはわりかしめんどう
    • Compute Engine での Chrome リモート デスクトップのセットアップというドキュメントが一番よくまとまっている
  • VPN がいらいない、クライアントはブラウザさえあればよい
  • 修飾キーがちゃんと動かない
    • キーマッピングなどを駆使してごまかす必要あり
  • Chrome OS で動くし、 Chrome OS だと修飾キーがだいたいまともに動く
  • iOS クライアントは正直そんなに出来よくない

VPN + RDP を受け入れるのがよい感じはある、もうちょっと考えていきたい

かに食いてえ

とりあえず https://diary.app.ssig33.com/404 を表示できるようにしつつ SSG できるようになったが 最悪のワークアラウンドの集合体という感じだし、 next.js 使うときはこのあたり慎重に URL 設計したほうがいいし、既存のものに next.js 充てるのも考え物であるかもしれない。

ただまあ SSR + CDN でキャッシュ戦略ならなんも困りはしないのでそれはそれでって感じやね。

URL が 404 だと next.js の SSG ちゃんと動かない 問題があって、対処法を探している。

SSG + SSR + Fastly でキャッシュ みたいな構成に移行しようとしているが、なんとも迂遠な感じがすごい

Cypress で Firebase つかったログインをテストする

結論: jest-puppeteer で我慢できるならそっちのほうがいい

https://github.com/cypress-io/cypress/issues/408

を見てくださいで終わってしまう話なのだが、 Cypress はサードパーティーの cookie をクリアすることが出来ない。これは典型的にどういうときに問題になるかというと、 Firebase のような外部の認証プロバイダーを用いてアプリにログインしているとき、テストの実行事にログインセッションがクリアされない。

これが大きな問題であることは明らかで、↑のとおり Cypress の創業者もこれを改善する意思を示しているのだが、実際これを実装する難しさは issue で説明されてる通りで 3 年間放置されている。

https://github.com/cypress-io/cypress/issues/408#issuecomment-555394035

結局このコメントのとおりに回避をしていくしかない。

I found a workaround which is to have a logout call before each test.

である。

じゃあこういう処理を Cypress でどのように実装すべきかというと、

https://docs.cypress.io/guides/core-concepts/conditional-testing.html#Element-existence

が参考になるだろう。テストがどのようなシチュエーションで実行されるかはわからない(CI かもしれないし開発者のデスクトップかもしれない)ので、「ログインしてるかどうかを確認して、ログインしていればログアウトする」という処理を beforeEach 内で実行するとよい。

cy.get('body').then(($body) => {
  $body.find(selector)
});

で DOM の有無を観測できるので、ログインしてるときにだけ発生する DOM があるかを確認して、ログインしているのであれば、ログアウトボタンかなにかをクリックする処理を書けばよい。

Cypress はあんまり難しくないことをしている限りは jest-puppeteer よりもはるかに書きやすくて気持ちがいいのだが、こういう風にちょっと複雑なことをしようとするとすぐに内部の気持ちを察したことをさせられる。また、ドキュメントの雰囲気からも察せられることと思うが案外 jQuery 的な価値観で全てが作られていてともするとレガシーさを感じることになる。

そのあたりも含めて SPA の E2E を書くなら jest-puppeteer より Cypress のほうが優れているとは思うが、よく注意して使ったほうがいい。

PDF を Gyazo に展開して Scrapbox の記事にして全文検索する という試みについてです。

まず PDF を Gyazo に展開して Scrapbox の記事にするということですが、これについてブラウザ上で簡単に動くツールを実装しました。

https://ssig33.github.io/pdftoscrapbox/

おそろしく素朴な見た目ですがとりあえず動きます。Chrome や Edge に Tamper Monkey (試してないけど Firefox と Greasemonkey でも動くんじゃないかな)を入れて、 input に Scrapbox のプロジェクト名を入れて user.js をインストールした上で赤いところに PDFをドラッグ&ドロップすると、 PDF.js で PDF でレンダリングした上で全てのページを Gyazo にアップロードして Scrapbox のページを作成します。

何故 user.js を使っているかというと、 CORS 制限を突破する目的です。

これで実際どういう記事が出来るかということなのですが、

こういう感じです。

ページごとに画像になっているので、特定のページへのリンクを作成できますし、また Scrapbox の機能を用いていろいろとメモを書いていくことも可能です。

ではこうやって PDF を Scrapbox に展開できたとして検索が出来なければあまり使いやすいとはいえません。ですが、 Gyazo には強力な OCR 機能があり、画像内の文字列をかなり正確に検索することができます。

この結果を用いて Scrapbox を検索することができると便利です。というわけでそれも作りました。こちらの user.js をインストールすると Gyazo の OCR 結果を使って Scrapbox を検索することができます。

こんな感じで新しいボタンが出るようになるので、これをクリックすると

こう。ちなみにこの機能をまともに使うには Gyazo Pro に課金する必要がありますが、画像を強力に OCR して検索できるツールが月額たったの $5 と思えば大変に安いものです、是非契約しましょう。

PDF がいろいろ集まってくるけど読めない、管理できない、読んだメモを残せない、という人は結構多いと思うのですが、個人用の Scrapbox とこれらのスクリプトを用いることで非常によい検索性とメモ環境を得られると思います。

今回つくったツールのソースコードは https://github.com/ssig33/pdftoscrapbox にあります。ソースを見れば分かる通りですが今回作られたツールはすべてブラウザ上で動作し、僕が管理するサーバーをデータを通過することがないため安全に使うことができます(ぼくがこのツールの運用に支払うコストがゼロであることも意味します)。

コアラ

はーだるい

GraphQL を CDN にキャッシュさせるのってどうするのがいいの