htmxについて

 htmxというフロントエンドのフレームワークがあります。というかつい最近知ったんですが。

• もうjsなんていらない！世界で流行っているHTMXについてまとめてみた #JavaScript - Qiita
• htmxとは何なのか？ その背景にある思想について #rest - Qiita

ここしばらくフロントエンド開発から離れていたので全然キャッチアップできておらずお恥ずかしい話ですが、去年あたりから世界的に流行っているらしいですね。

このフレームワークについての説明は上記の記事や公式サイトに任せますが、これを見たときに最初に思ったことは「ついに来たか」でした。

フロントエンド開発の変遷からして、いずれはこういうものが来ると思っていたのです。

20年ほど前にJavaScriptを使ったリッチなフロントエンドの開発が流行り始めたとき、最初はjQueryやPrototypeなどのライブラリーを使ってDOMを直接操作していました。Ajaxとかいう言葉が騒がれ始めたのもこの頃です。

しかし変数の値が変わるたびにDOMを操作する、あるいはDOMの構成が変わるたびに変数に反映させるという処理はややこしかったので、やがて変数とDOMをバインディングさせるという発想が出てきました。AngularJSやReactです。ReactはVDOMという別の概念ももたらしたのですが、これは別の話。

さて、「DOM直接操作」から「変数とDOMをバインディング」と変遷して開発者はロジックの記述のみに専念できるようになったわけですが、このあたりから「次はそもそもロジックを書かずに済むフレームワークが出てくるんだろうな」と考えていました。

ロジック（≒プログラム）を書かず、イベントが発生したときに呼ぶAPIと、戻り値を反映させる先をYAMLファイルのようなもので指定しておくだけで済めばデバッグの手間も大幅に減ります。なんでも作れるというわけではありませんが、これで十分なウェブアプリケーションも決して少なくない。そんなフレームワークがそろそろ出るだろうと。

このhtmxは、まさにこの思想から生まれたものだと思っています。YAMLではなくHTML内に直接指定ですが、そこは些細なこと。要はロジックを書かずに宣言的にアプリケーションを作れる時代がやってきたということです。

あ、上のアイデア（YAMLで指定する云々）を誰かパクって新しいフレームワーク作ってもいいんですよ？

ZIP爆弾で不正アクセス撃退

 不正アクセスに悩まされているサイト管理者は多いかと思います。特に "wp-admin.php" のようなパスへのアクセスがひっきりなしに来るサイトもあるでしょう。そういう不正アクセスに対して面白い（？）撃退方法があるようです。

ウェブサイトに侵入してくる相手にZIP爆弾を送りつけて撃退する方法

小さなサイズの圧縮ファイルが展開すると数GBや数TBに膨れ上がるZIP爆弾と呼ばれるものがありますが、それをブラウザー経由でやるというもの。

これの面白い（？）と思ったところは2つあります。

ブラウザーの標準機能を使っていること。GZIP圧縮によるデータ転送はHTTPの規格で定義されており、ほとんどすべてのブラウザーが対応しています。自動的にデータの展開まで行うので、攻撃者が気づいたときには時すでに遅し。ブラウザーではなくcurlなどでアクセスした場合でも、Accept-Encodingヘッダーを指定していれば自動的に展開されます。

この手法は「攻撃」ではないということ。例えば、UAの脆弱性を突いてリモートコード実行したり、リクエスト側を乗っ取るようなレスポンスデータが含まれていると、逆にサービス側が不正アクセスとみなされる可能性が高いと思います。でもこの手法は単にレスポンスデータが大きいだけなので、それを処理する能力がブラウザー側にないことやストレージの空きがないことはサービス提供者側の責任ではありません。

とはいえ、「攻撃者側を困らせてやろう」と思ってやっているであろうことは変わりないため、いざ裁判を起こされたときにどのように無罪を勝ち取れるかは保証できません^※し、この方法を推奨するわけでもありませんので誤解なきよう。あくまで技術的に面白いと思った（ZIP爆弾自体は知識として知っていましたが、こういう使い方があったか、と感心した）だけです。

※「攻撃するほうが悪い」「攻撃者側が裁判を起こすなんて恥知らずだ」という理屈は法治国家では通用しません。弁護士の腕や裁判官によって結果は大きく変わるでしょう。

機械学習で全然精度が上がらない

 最近、seq2seqの独自実装にハマっています。まあ独自実装といってもまだ自慢できるような工夫はほとんどないんですが、翻訳とかチャットボットとかになんか使えそうなのでとりあえずエンジンを作っている段階です。

そんな自作seq2seqを使って試しに英日翻訳エンジンを作ってみたんですが、どれだけ学習させても全くもってトンチンカンな翻訳結果にしかなりません。多分アルゴリズムは合ってるはずだし学習データもネット上で公開されている機械学習用のトレーニングデータを使っています。ただデータ量が多いので、ある程度まとめてミニバッチ学習をさせています。何がおかしいんだ・・・

数日悩んでいましたが、ある日ソースコードを見直して気づきました。

ミニバッチ学習させるときに、パディングの影響を最小限にするためにトレーニングデータを長さ順にソートしています。それはいいんですが、入力と出力を独立にソートしていたため、英文と和文の対応がグチャグチャになっていることに。

対応がずれないように、英文の長さを基準にして「英文・和文のペアの配列」をソートして再学習させたところ、無事それっぽい翻訳結果が出ました。そのうちどこかで公開したり、基礎から始めるseq2seq的な記事を書いたりするかもしれません。

良い子のみんな、学習データの入力と出力は別々にソートしちゃダメだよ！こんなことするのは他にいないと思うけどね！

新年のごあいさつ

 あけましておめでとうございます・・・と言える気分ではなく、新年早々大変なことが続いていますがみなさんお元気でしょうか。被災されたみなさんにお見舞いを申し上げます。

こちら（兵庫県）は地震の影響は全くなく、家族の中で揺れに気づいたのが自分だけという状況です。「またいつものザコ地震か・・・」と高をくくっていたところ、ニュースを見て驚きました。

姉の家族が金沢に住んでいるのですが、家具がひっくり返って汚部屋ならぬ汚家になったくらいで人的被害はなし、物流・電気・水道などのインフラも問題なしとのことで安心しました。

金沢以北の能登地方が大変ということで、一日も早い復興を願っています。今年もよろしくおねがいします。