ブックマークサービスQiNeel関連の記事や身の回りのよしなしごとをそこはかとなく書きつくっています。
Google広告費の影響を受けない新たなWebブラウザが必要だと、スクラッチからWebブラウザを開発する「Ladybird Browser Initiative」、元GitHub創業者らが立ち上げ
動機は納得だし、健全な競争のためにも大いに応援したいと思っています。ただここまで巨大化したウェブ標準をフルスクラッチで実装するのは骨が折れるどころか粉末状に砕けるレベルの大仕事でしょうね・・・
当面の問題は、開発人材の確保と運営資金でしょうか。
とりあえずリンクをぺたり。みなさんも応援してあげてください。
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編）
記事の内容は「メソッドの名前がおかしいが実装わかりやすいコード」と「メソッドの名前は問題ないが実装がややこしいコード」の2つを50人ほどのJavaプログラマーに解読してもらい、メソッド名と実装のどちらを先に修正すべきかというものです。
統計結果を見る前に思ったのは、メソッド名を先に直すべきではないかということ。理由は記事中にある
構造的問題は局所的に起こるが、命名的問題はコードのどこにでも出てくるものがあるため
「命名的問題」があるとコードが信じられなくなる
などです。そして上記記事でも「命名が不適切なコードの方が読解精度が低い」という結果が出ました。
また実際の開発現場でも、命名が不適切なコードの方が読解精度が低い」という結果ですが、コードリーティングの際に実装がややこしい場合は「何だこれ？」と思って注意して読み進めるのに対し、命名が不適切な場合はメソッドの役割を勘違いしたまま開発を進めてしまう可能性があるので命名的問題のほうが深刻だと考えています。
先日7/3-5に、奈良でJANOG54 Meetingが開催されました。毎回ネットワーク分野の錚々たる企業が集まっており、日本国内でインターネットが壊れた場合は大抵ここの参加企業のどこかが何かやらかしていると考えて間違いないです。
色々ブースを見て回った他、さくらインターネットのブースで「高火力 DOK」の説明も行いました。AI関連のサービスなのでネットワークと直接関係はないんですが、6/27に発表されて1週間ほどしか経っていないサービスなので、広報も兼ねて説明要員としても参加しました。
サービスインしたので晴れてプロフィール更新
— おだしま@手品をするITエンジニア (@shimataro999) June 27, 2024
このサービスの開発マネージャーをしています
なお開発マネージャーの仕事は、やることをメンバーにぶん投げてケツ叩いてあたかも自分の功績かのように見せることですhttps://t.co/nleAbVGDkk
ネットワークなどの低レイヤーにあまり興味のないウェブ開発者もいると思いますが、自分たちが開発している（あるいは普段使っている）サービスの土台を知るためにもこういうカンファレンスはおすすめです。最初は言っていることがさっぱりわからないかもしれませんが、何度も参加しているうちに知り合いができたり話の内容も理解できたりするので面白いですよ。
奈良には学生時代に数年（今回の会場から2駅ほどしか離れていない場所に）いたんですが、さすがに当時から時間が経っているので駅前がかなり開発されていますね。ただ夏暑く冬寒いという気候は相変わらずでしたが。
やや混み気味の電車に乗っていたとき、外国人の家族連れが降りようとしていました。そのときに聞いたのが “Excuse us”
こういうときのイディオムは “Excuse me” が定番だと思っていましたが、usは初めて聞きました。
よく考えれば、許してもらう対象が家族という「複数」の場合はusを使う、というのは当たり前といえば当たり前ですね。知っている人にとっては「何を今更」という感じでしょうが、今まで習ったことも聞いたこともない表現だったので勉強になりました。
／⌒ヽ / ´_ゝ`） ／⌒ヽ Excuse us... | / / ´_ゝ`） | /| | | / // | | | /| | Ｕ .Ｕ // | | Ｕ .Ｕ
インドの物理学者がひも理論の研究から偶然「円周率」の新しい公式を発見
いやー、こういう発見があるから数学は面白い。数学が「自然科学の言語」と言われるのも納得です。
原論文はこちら。実際の計算公式は以下のとおりです。
\begin{eqnarray*} \pi=4+\sum_{n=1}^{\infty}\frac{1}{n!}\left(\frac{1}{n+\lambda} - \frac{4}{2n+1}\right)\left(\frac{(2n+1)^{2}}{4(n+\lambda)}-n\right)_{n-1} \end{eqnarray*}
2つほど補足すると、唐突に出てくる\(\lambda\)は実部が\(-1\)より大きな任意の複素数、右下の小さな\({}_{n-1}\)はポッホハマー記号（昇冪）です。
Pythonで書くとこんな感じ。元の式をできるだけ忠実に表しているので、メモ化などの最適化はしていません。
# https://gigazine.net/news/20240619-string-theory-pi/
# 原論文: https://journals.aps.org/prl/pdf/10.1103/PhysRevLett.132.221601
import math
def poch(x: float, n: int) -> float:
# ポッホハマー記号（昇冪）
# https://ja.wikipedia.org/wiki/%E3%83%9D%E3%83%83%E3%83%9B%E3%83%8F%E3%83%9E%E3%83%BC%E8%A8%98%E5%8F%B7
y = 1
for j in range(n):
y *= x + j
return y
def term(lambda_: float, n: int) -> float:
# 第n項を計算
a = 1/(n+lambda_) - 4/(2*n+1)
b = (2*n+1)**2 / (4*(n + lambda_)) - n
return a * poch(b, n-1) / math.factorial(n)
def pi(lambda_: float, n: int) -> float:
# 円周率を計算
p = 4
for n_ in range(1, n):
p += term(lambda_, n_)
return p
print(pi(1000, 100))
Python Praygroundにコードを貼り付けると結果が出てきます。pi関数に渡す値を色々いじって遊んでみてください。
わざわざこの記事を取り上げた理由はこの記事そのものではなく、これに対するGoogle翻訳。
のように、ちゃんと文脈を捉えて訳しているのが興味深かったです。
𝕏関連の文章も大量に学習させたんでしょうけど、過学習起こしてないよな・・・？
先日、FirefoxのプライベートモードでEnpass拡張機能が動作しなくなったという記事を書きました。記事中にあるとおり公式フォーラムでも報告したんですが、「プライベート拡張機能を有効にする設定にしてね」というコメントをいただき、ちょっと話が噛み合っていませんでした。
そして最近Firefoxを更新したところ、拡張機能が使えるようになっていました。何もしてないのに壊れて何もしてないのに直りました。
Firefox本体の仕様の問題だったんでしょうか。でも全ての拡張機能が使えなくなっていたわけでないので詳しいことはよくわかっていません。モヤモヤ感は残りますが、とりあえずフォーラムにも報告して一件落着（？）です。
総務省のサイバーセキュリティ https://t.co/o01Iy1ems9 パスワード管理ツールを推奨、パスワードの定期的な変更は不要と断言、すばらしい pic.twitter.com/a7FsA7Xh4z
— Haruhiko Okumura (@h_okumura) May 25, 2024
昔、アルゴリズム辞典やLaTeXの本などで大変お世話になった奥村先生のポストより。
このポストについては何も異論はないのですが、とはいえこのブログで何度か取り上げたように「パスワードは半角英数16文字以内」のようにお前絶対ハッシュ化しとらんやろというウェブサービスがいまだ存在しています。
そういうサービスがSQLインジェクションのような基本的な攻撃に正しく対応しているところばかりとも思えないので、「いつかデータを引っこ抜かれることを想定した定期的なパスワード変更」は必ずしも無意味ではないと思います。
何事も臨機応変に。
ちょっと前にPythonを滅ぼそうやない会とかいう記事が投稿され、それに対するアンサー記事も投稿されるなどまあまあ賛否両論だった記憶があります。
個人的にはシンタックス云々に一部同意する部分もありつつ、でも英語の語順的にまあそうだろうなーというアンサー記事に同意する部分もありつつ、でも英語話者以外が使うことも考えてくれよなーと思いつつというどっちつかずの状態です。
個人的ついでに書くと、三項演算子やラムダ式などの省略記法は基本的に書きません。リストの内包表記も使いません。理由はあとで自分がすんなり読める自信がないから。
「そんなもんも読めないお前のスキルが低いだけ」と言われたら返す言葉もないんですが、とはいえ大抵のプログラマーは数ヶ月前、いや数週間前に書いた自分のコードが理解できないという状況を経験しているはずで、なるべく平凡な書き方のほうが大抵の人が理解しやすいでしょう。
Pythonに限らず、他の言語でもあまり省略記法やシンタックスシュガーは使わない傾向ですね。例えばJavaScriptのオプショナルチェーンとかも使いません。
JavaScriptといえば、個人的には互換性を数十年引きずっているあの言語仕様はなんとかならんもんかと思ってます。とはいえ上澄みをすくおうと頑張っているAltJSが生まれては消え、スーパーセットを謳っているTypeScriptが事実上のデファクトスタンダードという現状を見ると、これが市場の意思なんだと納得するしかないですね。JSConfの運営ボランティアにも入っていながらこんなこと言うのもアレなんですが。
結局何を言いたいのかよくわからん記事になってしまいましたが、要するに自分は平凡なソースコードを書いてるよという極めて平凡な内容しか書いてないですね。
ニューラルネットワークの活性化関数にReLUってあるじゃないですか。あれがどうもよくわからんのです。
数学的な定義とか「正の値の微分が1なので勾配消失問題に強い」とかは知ってるんですけど、なぜこれを使うと精度が向上するのか、負の値を一律で0にすることがニューラルネットワーク上でどういう意味を持つのかがわかりません。
上でリンクを張ったWikipediaでは
2000年にHahnloseらによって強い生物学的動機と数学的正当化を持って、動的ネットワークへに導入された
とありますが、生物学的な動機ってなんだろう。。。
そしてPyTorchのseq2seqとAttentionのチュートリアルでは、デコーダーの単語埋め込み（ベクトル表現）に対してReLUを適用していますが、これって大丈夫なん？
ベクトル表現の負の値を0にしてしまうと別の単語が同じ表現になってしまったり、特に全ての要素が負の値で表現される単語があったら、ゼロベクトル（PADやUNKなどの特別な単語）として扱われたりするんじゃないかと。
まあ内部状態は刻々と変化するのでゼロベクトルが渡されたからといって毎回出力結果が同じになるわけじゃないですし、そうなることを織り込み済みで学習させているので問題ないという理屈なんでしょうか。
誰か詳しい人教えてください。生物学的動機についても。
𝕏で、時々勝手に引用ポスト（大抵は大喜利みたいなネタ）させてもらっているアカウントがいくつかあります。
その中の1つのアカウントで、こんなポストがありました。
｢プロジェクトを成功させる人とは？｣と聞かれたら｢試行錯誤にくじけない人｣だと答えたい。PDCAを回すには、自己否定の数がモノを言う。自分で決めたプランの欠点を分析するのは正直しんどい。でも逃げたらダメ。｢失敗は成功のもと｣その言葉の裏にあるのは、何度心折れても投げ出さない強さだ
— 雪@言語化する広報 (@yuki8marketer) May 10, 2024
自分だったらこういう質問に対してどう返すかな？というのが今回のテーマです。
先日zedの記事を書きましたが、早速Gentoo用のebuildファイルの作成に取り掛かっています。
このへんを見るとtomlファイルから自動的にebuildを作るスクリプトもあるようですが、どうも依存パッケージの解決まわりがうまくいかず作業が止まっています。Rustなにもわからない。
とりあえず一旦ebuildファイルの作成は休憩して、Linux向けの依存パッケージインストールスクリプトをGentoo対応するPullRequestを出してみました。サクッとマージされてv0.134.1-preで導入されたようです。
これで、このドキュメントに沿ってGentooでビルドできるようになったはずです。ちなみに依存パッケージインストールスクリプトを実行するにはrustupも必要ですが、これはデフォルトではインストールできないのでキーワード指定する必要があります。
v0.134.1-preからLinux用のバイナリーも同梱されているようなので、どうにもならなければバイナリーをインストールするebuildを作ればいいのですが、せっかくのGentooなのでソースコードからビルドするebuildにチャレンジしています。あるいは誰かRustに強い人手を貸してください。
タイトル通り、MS-DOS 4.0がオープンソース化されたそうです。ライセンスはMIT。
https://github.com/microsoft/MS-DOS
記事にも書いてありますが、10年前の2014年にはMS-DOS 1.1と2.0、そしてWord 1.1のソースコードが公開されており、今回はそれに続く公開です。
現在MS-DOSと同等の環境がほしいならFreeDOSがあるので技術的な価値はほぼゼロでしょうが、歴史資料としての価値はとても大きい（気がします）。
そのうちWindowsの旧バージョン（NTより前）とかもオープンソースになるんでしょうか。まあこれも技術的には不完全とはいえReactOSがあるんですが。
新しいテキストエディタの存在を知りました。
Discordのようなマルチプラットフォームデスクトップアプリを開発するために使われるElectron.jsや、Visual Codeの登場以前で最も優れたテキストエディタの一つとされたAtomエディタの開発者たちが、これまでにない先端的なテキストエディタ「Zed」の開発に取り組んでいます。… pic.twitter.com/K461B9jmeU
— Jeffry Alvarado (@jalva_dev) April 20, 2024
このポストやウェブサイトを見た感じの事前情報としてはこんな感じでしょうか。
ポストVSCodeとして期待できるかもしれない、ということで早速インストールしてみました。ほんの少ししか使っていませんが現時点のレビューを書いておきます。全然使いこなしていないので的外れなことを書いているかもしれません。
まずデフォルトでVimモードを選択できます。わかってるなこいつ。
試しにvalue-schemaを開いてみると、ソースコードの解析がすぐに終わりました。VSCodeよりも爆速です。Rustで作っているせいなのか、必要最低限の解析にとどめているのか、もしくは手元のVSCodeに拡張機能を入れまくっているせいなのかわかりませんが、とにかく速い。
定義場所へのジャンプや参照場所の一覧表示もバッチリ。ESLintの設定も自動的に読んで、問題箇所を指摘してくれます。この辺はVSCodeと同様。
エディタ内で端末も使えるのでちょっとした作業も問題なし。
まだ本当に少ししかいじっていませんが、エディタとしては問題なく使えています。ただ、内部にフォーマットルールがあるのか、ファイルを保存するときに勝手にフォーマットをかけてしまうのがｳｰﾝという感じです。多分これは設定をいじれるんじゃないかと思いますがまだ試せていません。EditorConfigにもまだ対応していないようです。
拡張機能にも対応していますが、今のところ使える拡張機能はそこまで多くありません。とはいえおそらくまだサードパーティー製の拡張機能があまり作られていないであろう現状では十分に多いといえるのかもしれませんが。
総評として、公式で謳っているだけあってパフォーマンスは素晴らしい。保存時の挙動が気になる以外は、（サポートしている言語であれば）現状でもソースコードエディタとしては問題なく使え、今後にも期待できる出来です。拡張機能の充実にも期待しましょう。Linuxに対応したらGentoo用のebuildファイルを作って応援します。
開発が進むにつれて機能がてんこ盛り、動作が遅くなる・・・というのはあらゆるソフトウェアの宿命なので、いい感じに折り合いをつけていただきたいです。
そういえば似たようなコンセプトのエディタにJetBrains Fleetがありますが、こちらもまだ正式版ではありませんが頻繁に更新されていますね。
新たなエディタ戦争、楽しみです。
MD5の新たな衝突が発見されたそうです。
Here is a 72-byte alphanum MD5 collision with 1-byte difference for fun:
— Marc Stevens (@realhashbreaker) March 19, 2024
md5("TEXTCOLLBYfGiJUETHQ4hAcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak")
=
md5("TEXTCOLLBYfGiJUETHQ4hEcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak")
MD5自体はかなり以前に強衝突耐性が突破されているので、衝突するデータのペアが見つかったこと自体は大したニュースではありません。
今回は「すべてASCIIの印刷可能文字からなる」「1文字違い（さらに言うなら1ビット違い）の文字列が」衝突したというニュースです。
いやすごいんですけど、これどうやって見つけたんだ。
先週XZ Utilsのバックドアのニュース（CVE-2024-3094）を記事にしましたが、1週間して色々な情報が出てきました。
このバックドアを悪用するとSSHサーバーに侵入できるとか、バックドアを仕込んだ人物は数年かけてXZ Utilsチームの信頼を得た後に仕込んだとか、バックドアに気づいたのは本当に偶然だったとか。
今回の時系列は以下のページが詳しいですね。
XZ Utilsにバックドア攻撃が行われるまでのタイムラインまとめ
これを見ると2人組による計画のようにも見えますが、真相はいかに。
大抵のLinuxディストリビューションに含まれているXZ Utilsにバックドアが仕込まれていたというニュースを小耳に挟みました。
XZ UtilsはLZMAやxz形式の圧縮ファイルを扱うためのライブラリーで、上述の通り大抵のLinuxディストリビューションに含まれています。
バックドアが仕込まれてから発覚するまでが1ヶ月程度だったというのもあって、影響を受けたディストリビューションはあまり多くないようです。あまりいないとは思いますが、ここ1ヶ月ほどの間にソースコードからXZ Utilsをビルドしている方は影響を受けている可能性が高いのでダウングレードしたほうがよさそうです。
さて、我らがGentoo Linuxへの影響はというと・・・Changelogを見る限りこんな時系列でしょうか（日付はUTC）
というわけで、3月24日〜30日の間にパッケージを更新した人がバックドアのあるものを掴んだ可能性が高いです。一刻も早いうどんワールドをおねがいします。
こちらにも諸々やり取りがあります。
数学とコンピューター好きの端くれとして、円周率ネタは大好きなんです。中学生くらいの頃は無駄に300桁くらい覚えていたり、円周率の計算式を独自に導出したりしていました（後にすでに発表されていることが判明したんですが・・・）
直近ではGoogleが100兆桁まで計算していて、今回はそれを5兆桁更新したというニュースです。
記事にあるとおり、この計算をしたのはストレージの専門家なのですが、「なぜ円周率の計算をストレージ専門家が？」というところが興味深いので今回ネタにしました。
というのも、こういう計算系はアルゴリズムの工夫によって記録が更新されるように見えますが、近年の円周率業界はy-cruncherというソフトで「チュドノフスキー級数」を計算する・・・という方法が定番で、アルゴリズムはもうほぼギリギリまでチューニングしきっているような世界なのです。
そのため、昨今の円周率業界で一番のボトルネックはストレージのI/O。ストレージの専門家が記録を更新するのもうなずけます。
ちなみに、ガウス＝ルジャンドルのアルゴリズムやボールウェインの4次式のように、理論的にはチュドノフスキー級数よりも格段に収束の速い計算方法はあります。しかしコンピューターで多倍長演算する上では整数の四則演算以外（平方根計算など）をなるべく減らしたいとか、前回の計算結果を利用してさらに多くの桁数を計算するというテクニックを使うために今でもチュドノフスキー級数が使われています。個人的には、ボールウェインの4次式を整数の四則演算だけで多倍長計算できるようなアルゴリズムとか出てきたらなんかアガります。
円周率は決して終わりのないことが証明されているので、おそらくコンピューターがある限り円周率の記録更新はこれからも続くでしょう。
新たなサーバサイドJavaScriptランタイム「WinterJS 1.0」正式リリース、WebAssemblyへのコンパイルも可能。Wasmerが開発
去年の10月ごろに出た新しいJavaScriptランタイムが正式版になったようです。今回の開発元はWasmer。爆速を謳っているBunよりも速いと主張しています。
まだ使ってないので評価も何もできないのですが、元記事をざっと見た感じではDenoやBunとは違ってTypeScriptのネイティブサポートはないようですね。
これでV8（Chrome） / JavaScriptCore（Safari） / SpiderMonkey（Firefox）のエンジンを使ったランタイムが揃ったので、みなさんいい感じに競争してほしいです。
先日、Linuxを入れているPCを再起動したら画面にこんなメッセージが出て起動できなくなりました。
error: file /boot/ not found.
Gentoo Linuxを使っているんで時々カーネルのアップデートはするけど、特にブートローダー周りをいじってるわけでもないし現に今まではこういうエラーも特に出なかったし、うーんなんだろなー🤔 このマシン使えないと副業も何もできんし困ったなー🤔
とりあえずエラーメッセージで検索しても原因らしきものは見つからず。仕方ないのでこういうこともあろうかと用意していたUbuntu入りのUSBメモリーで起動し、パーティションをマウント。マウントできたので、とりあえずストレージやパーティションに致命的な障害があるわけではなさそう。
あらためてカーネルの再構築やらgrub-mkconfigやらを実行して再起動。でもまだ同じエラーが出る。
半日近くあれこれ試行錯誤しましたが、最終的にパーティションをマウントしたディレクトリーにchrootしてgrub-installをやり直したら直りました。
grub-install --target=x86_64-efi --efi-directory=/boot/eft --bootloader-id=boot /dev/sda
結局原因はわからずじまいだけど、きっと何かの拍子になんかおかしくなったんでしょう。そうに違いない。
このマシン自体は4年前くらいに買ったやつで、今でもスペック的に大きな不満はないんだけどそろそろ買い換えどきかなぁ🤔
ここ数年パスワードマネージャーにEnpassを使っています。機能的に不満はなく、有料ですがサブスク方式ではなく一括払いのプランもあるので愛用しています。
ただ、最近特定の環境でブラウザーのパスワード自動入力ができなくなってしまいました。
詳細はEnpass公式フォーラムに書きましたが、Firefox v123.0のプライベートモードで自動入力機能が使えません。別の環境（Firefox v115.7）では問題ないので、バージョンアップした際にプライベートモードの拡張機能の仕様が何か変わったのかもしれない・・・と推測しているのですが詳しいことはわかりません。
別の環境のFirefoxをv123.0にしたら少しはハッキリするかもですが、動かなくなったら嫌だしなぁ・・・
誰か解決方法を知っていたら教えてください。
断られた→返信しない「メール1往復主義」の若手が増加中！タイパ重視の本末転倒
こんな記事がありました。個人的にも確かにこういう経験はあります。
このブログでも度々取り上げていますが、LinkedInなどで明らかにこちらのプロフィールや希望に全く目を通していない（おそらく一斉送信の）スカウトメールが来ることがあります。そういうメールは機械的に弾けるような仕組みを入れているのでスルーするんですが、大体1週間後くらいに「どうしても諦めきれないので再度連絡します」みたいなメールが来ます。それも大抵スルーするんですが、時々気が向いたら「そんなに真剣なのになんでプロフィール読まんのや、ああん？」という趣旨の内容をオブラートに3重くらい包んで送ったりします。まず間違いなく、それ以降先方からの連絡はありません。
こういう経験談は置いといて、冒頭の記事を読んでちょっと気になったところが。
相手は本当に「若手」なんでしょうか？
記事内ではひたすら「若手」が強調されていますが、記事を一通り読んでも「一往復主義を行うのは若手」という確たる根拠はないように見えます。例えば相手が年齢を名乗ったとか、送り主の名前で検索したらSNSで若い人がヒットしたとか、知り合いの会社の人が「うちの若い営業はこんな感じだよ」と言っていたとか・・・そんな話は一切出てきません。
このようなことから、最後の返信を省くことは、現代のビジネス環境においては、不適切ではなく、タイムパフォーマンスから見ても正当化でき、相手にとっても余計な時間を費やさせない正しい行動である、と若手社員は考えているようなのである。
という書き方からして、実際にこういう営業スタイルの若者に聞いたわけではなく、「タイムパフォーマンス的に問題ないから正当化できる、こういう考え方をするのは若者だろう」あるいは「昔は違った、今はこうだ、だからこういうことをやっているのは若手に違いない」という推測が多分に混じっているように見えます。
ただこれは乱暴すぎやしませんか。後者の「昔は違った〜〜」に関しても、新入社員当時のやり方に違和感を持った人が、ベテランと呼ばれはじめた今になってこういうやり方を採用している可能性を排除できていません。
Install SSH Keyもだいぶ機能的には成熟してきたので、更新頻度もかなり減ってきました。SSH鍵を使う上での機能は過不足なく揃っていると思います。希望を言い出したらキリがありませんが、ごく一部の人しか使わないようなニッチな機能をつける予定はありません。
先日、半年ぶりくらいに新バージョンv2.7.0をリリースしました。内容は大したことではなく、使用しているNode.jsランタイムをv16からv20へ変更したのがメインです。
先月の時点ですでにIssueには報告があり、親切にもPull Requestが投稿されていました。半月くらい放置して取り込むだけの簡単なお仕事です。報告＆PRを作ってくれた人たちありがとう。
これに伴い、DockerコンテナのUbuntu 16.04とCentOS 7のサポート（CIによる動作検証）を切りました。多分glibcのバージョンの問題で、これらのOS上でNode.js v20は動きません。
数学好きにはよく知られた方法ですが、排中律という証明方法があります。厳密にはこれは証明ではなく「『Aである』または『Aではない』は常に成り立つ」というある意味当たり前の原理なのですが、これをうまく使った証明のやり方があります。
高校までには習わない（というか大学でも習った記憶がない）のですが、考え方は高校数学レベルで十分理解できます。かなり使い道は限られるのですが、個人的にはこの排中律が一番「すげえ！」と思った証明方法です。
Gentoo Linuxの派生ディストリビューションにSabayon Linuxというものがあります。派生といっても、ソースコードベースで変態御用達のGentooとは正反対の、Ubuntuと同程度に簡単に使えるディストリビューションです。
そんなSabayon Linuxのことをふと思い出したので、どれくらい進化しているか確認しようとしたら・・・
いや進化しすぎぃ！進化しすぎてカジノサイトになっとる！！
譲渡したのかドメインが切れたのか乗っ取られたのか事業変更したのか詳しいことはわかりませんが、どうやら公式サイトは消滅してしまったようです。Wayback Machineによると、2023年3月13日の時点ではちゃんと存在していたものが3月14日にカジノサイトになっているようですね。
開発チームは今どうなってるんでしょうか。GitHubのSabayon orgを見てみると、サイトのURLが変わっているようです。
モカチーノと読むんでしょうか。Sabayonから新たに派生したみたいです。リポジトリーもmocaccinoOS orgが新しく作られているようです。
何の気なしに「そういえばアレどうなってるんだっけ」から調べたものが、意外と激動していました。
htmxというフロントエンドのフレームワークがあります。というかつい最近知ったんですが。
ここしばらくフロントエンド開発から離れていたので全然キャッチアップできておらずお恥ずかしい話ですが、去年あたりから世界的に流行っているらしいですね。
このフレームワークについての説明は上記の記事や公式サイトに任せますが、これを見たときに最初に思ったことは「ついに来たか」でした。
フロントエンド開発の変遷からして、いずれはこういうものが来ると思っていたのです。
20年ほど前にJavaScriptを使ったリッチなフロントエンドの開発が流行り始めたとき、最初はjQueryやPrototypeなどのライブラリーを使ってDOMを直接操作していました。Ajaxとかいう言葉が騒がれ始めたのもこの頃です。
しかし変数の値が変わるたびにDOMを操作する、あるいはDOMの構成が変わるたびに変数に反映させるという処理はややこしかったので、やがて変数とDOMをバインディングさせるという発想が出てきました。AngularJSやReactです。ReactはVDOMという別の概念ももたらしたのですが、これは別の話。
さて、「DOM直接操作」から「変数とDOMをバインディング」と変遷して開発者はロジックの記述のみに専念できるようになったわけですが、このあたりから「次はそもそもロジックを書かずに済むフレームワークが出てくるんだろうな」と考えていました。
ロジック（≒プログラム）を書かず、イベントが発生したときに呼ぶAPIと、戻り値を反映させる先をYAMLファイルのようなもので指定しておくだけで済めばデバッグの手間も大幅に減ります。なんでも作れるというわけではありませんが、これで十分なウェブアプリケーションも決して少なくない。そんなフレームワークがそろそろ出るだろうと。
このhtmxは、まさにこの思想から生まれたものだと思っています。YAMLではなくHTML内に直接指定ですが、そこは些細なこと。要はロジックを書かずに宣言的にアプリケーションを作れる時代がやってきたということです。
あ、上のアイデア（YAMLで指定する云々）を誰かパクって新しいフレームワーク作ってもいいんですよ？
不正アクセスに悩まされているサイト管理者は多いかと思います。特に "wp-admin.php" のようなパスへのアクセスがひっきりなしに来るサイトもあるでしょう。そういう不正アクセスに対して面白い（？）撃退方法があるようです。
ウェブサイトに侵入してくる相手にZIP爆弾を送りつけて撃退する方法
小さなサイズの圧縮ファイルが展開すると数GBや数TBに膨れ上がるZIP爆弾と呼ばれるものがありますが、それをブラウザー経由でやるというもの。
これの面白い（？）と思ったところは2つあります。
ブラウザーの標準機能を使っていること。GZIP圧縮によるデータ転送はHTTPの規格で定義されており、ほとんどすべてのブラウザーが対応しています。自動的にデータの展開まで行うので、攻撃者が気づいたときには時すでに遅し。ブラウザーではなくcurlなどでアクセスした場合でも、Accept-Encodingヘッダーを指定していれば自動的に展開されます。
この手法は「攻撃」ではないということ。例えば、UAの脆弱性を突いてリモートコード実行したり、リクエスト側を乗っ取るようなレスポンスデータが含まれていると、逆にサービス側が不正アクセスとみなされる可能性が高いと思います。でもこの手法は単にレスポンスデータが大きいだけなので、それを処理する能力がブラウザー側にないことやストレージの空きがないことはサービス提供者側の責任ではありません。
とはいえ、「攻撃者側を困らせてやろう」と思ってやっているであろうことは変わりないため、いざ裁判を起こされたときにどのように無罪を勝ち取れるかは保証できません※し、この方法を推奨するわけでもありませんので誤解なきよう。あくまで技術的に面白いと思った（ZIP爆弾自体は知識として知っていましたが、こういう使い方があったか、と感心した）だけです。
※「攻撃するほうが悪い」「攻撃者側が裁判を起こすなんて恥知らずだ」という理屈は法治国家では通用しません。弁護士の腕や裁判官によって結果は大きく変わるでしょう。
最近、seq2seqの独自実装にハマっています。まあ独自実装といってもまだ自慢できるような工夫はほとんどないんですが、翻訳とかチャットボットとかになんか使えそうなのでとりあえずエンジンを作っている段階です。
そんな自作seq2seqを使って試しに英日翻訳エンジンを作ってみたんですが、どれだけ学習させても全くもってトンチンカンな翻訳結果にしかなりません。多分アルゴリズムは合ってるはずだし学習データもネット上で公開されている機械学習用のトレーニングデータを使っています。ただデータ量が多いので、ある程度まとめてミニバッチ学習をさせています。何がおかしいんだ・・・
数日悩んでいましたが、ある日ソースコードを見直して気づきました。
ミニバッチ学習させるときに、パディングの影響を最小限にするためにトレーニングデータを長さ順にソートしています。それはいいんですが、入力と出力を独立にソートしていたため、英文と和文の対応がグチャグチャになっていることに。
対応がずれないように、英文の長さを基準にして「英文・和文のペアの配列」をソートして再学習させたところ、無事それっぽい翻訳結果が出ました。そのうちどこかで公開したり、基礎から始めるseq2seq的な記事を書いたりするかもしれません。
良い子のみんな、学習データの入力と出力は別々にソートしちゃダメだよ！こんなことするのは他にいないと思うけどね！
あけましておめでとうございます・・・と言える気分ではなく、新年早々大変なことが続いていますがみなさんお元気でしょうか。被災されたみなさんにお見舞いを申し上げます。
こちら（兵庫県）は地震の影響は全くなく、家族の中で揺れに気づいたのが自分だけという状況です。「またいつものザコ地震か・・・」と高をくくっていたところ、ニュースを見て驚きました。
姉の家族が金沢に住んでいるのですが、家具がひっくり返って汚部屋ならぬ汚家になったくらいで人的被害はなし、物流・電気・水道などのインフラも問題なしとのことで安心しました。
金沢以北の能登地方が大変ということで、一日も早い復興を願っています。今年もよろしくおねがいします。