Diary

@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 にキャッシュさせるのってどうするのがいいの

ゴアラについて考えている

ゴリラについて考えている

とてもだるい

消費者庁のサイトが speechSynthesis を使って読み上げ機能を提供しているが壊れている

現代のブラウザには speechSynthesis という API があってそれなりの性能の読み上げをすぐ実装できて便利なのだが、あまり活用例はないという状態だった。

ところが昨日偶然消費者庁がやっている特商法の解説サイトがこれを活用しているのを発見した。しかし盛大に壊れている。どう壊れているかは以下をご確認頂きたい。

で、なんでこんなことになっているのかとソースコードを見てみた。ぶっ壊れの理由は以下のような実装になっているからである(一部省略して核心部だけ示している)。

var voiceNum = 0;       
if(navigator.userAgent.toLowerCase().indexOf('firefox') != -1) {
    voiceNum = 0;
    console.log('win firefox');
}else if(navigator.appVersion.indexOf('Edge') != -1) {
    voiceNum = 0;
    console.log('win Edge');
}else if(navigator.appVersion.indexOf('Chrome') != -1) {
    voiceNum = 11;
    voiceRate = 1.1;
    console.log('win Chrome');
}else{
    voiceNum = 0;
    console.log('win');
}

var utterance = new SpeechSynthesisUtterance();
utterance.lang = 'ja-JP';
utterance.rate = voiceRate;
utterance.voice = speechSynthesis.getVoices()[voiceNum];

このコードは、 speechSynthesis.getVoices() の値が常に一定であることに依存している。しかし MDNの解説を見る限りそれは保証されていないようだし(そもそも This is an experimental technology とある)、実際僕の環境は実装者の意図とは違う値がかえってきているようだ。

ちょっと確認した限りでは、

• Windows 10 の Chrome と Edge ではダメ
• Mac の Chrome は大丈夫
• Mac の Firefox もダメ

というかんじであった。

ではどうすればよかったのか?というと以下のようにすべきである

speechSynthesis.getVoices().find(v => v.lang === 'ja-JP')

で、 Windows 10 の Chrome でこれに置き換えてみたら以下のようになった。

感想

• experimental と書かれている機能を使う場合、継続的にちゃんと動いているかの確認が必要と思う
• speechSynthesis は(ちゃんと使えば)想像以上によく動く。積極的に導入していく価値がある

Fastly のログイン画面をどうにかしてほしいという話

複数の Fastly アカウントにまたがって構築されいるシステムのメンテナンスという作業をしていて、気付いたらかなり体調が悪化してて、激しい頭痛と吐き気の襲われた。というのも、ログアウト => ログインを何度も何度も繰り返すことになるから↑の画面を何度も何度も何度も何度もみていたわけだ。

これを 30 インチのディスプレイに全画面でドカーンと出していたので、これはつまりポケモンショック同様の症状ということだと思う。

自分がそういう状態になっていると気付いてからは、以下の user.css を書いて回避した(user.css の適用にはこの拡張を使っている)。しかしまあ一度崩れた体調は今に至るまで回復していない。

section.authentication{
  background-color:darkred;
}

Fastly は実際驚異的な CDN で、これなしに自分の仕事、生活はもはやなりたたないほどで本当に感謝しているのだが、さすがにこのログイン画面はしんどすぎる。どうにかしてほしい、、、

かに

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 にサクっと上げて超全力でキャッシュしてくれるとかそういうのできればそれが楽なのでどうにかできないのか、、、

はーめんどくせ

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