« 2024年9月 | トップページ | 2024年11月 »
ウェブで (Cookpadじゃない 😃) 見つけたプロっぽい人の焼き豚のレシピなのですが、変なポイントだけ書くと、
このレシピだと、仕込み (前日) のうちに片栗粉を水で溶いて、そのまま一晩+４時間おいておく、ってことになっちゃいますよね。なぜ、そんなことをするのだろうか…。(しかも、そのころにはせっかく溶いた片栗粉がすっかり沈殿しちゃっているはず … って、そこは大事じゃありませんが。)
このブログに書くのは初めてだと思うのだが、数年前から Google の Cloud Translation API というものを使っている。主に Advanced Service、通称「v3」。
それで、昨日、この API を使うあるツールを修正していたら、そのツールが動かなくなってしまった。
ちょっと大掛かりな修正 (機能追加) をやっていて、しばらくビルドできない状況が続いていたが、やっとビルドできるようになったので試したところ動かなかった。それだけなら至極よくあることだし、特に驚くようなことではないが、今回触ったのはコンテンツの部分だけなのに Cloud Translation API を呼び出す部分で例外が出ていた。ちょっとしたラッパークラスを自分で作っていて、そこは一切触っていなかったのだが、そのクラスの中で。Google.Cloud.Translate.V3.TranslationServiceClient.DeleteGlossary というメソッドの呼び出しが失敗して Grpc.Core.RpcException になる。
例外の StatusCode は InvalidArgument だった。Status.Details を見ても単に "Invalid argument." と書いてあるだけ。当惑したのは、このメッソドには引数が一つしかなく (実際は二つあるのだが、もう一つは省略していた)、文字列型で、そこには毎回固定の文字列を渡しているだけだったからだ。(その文字列は削除する glossary の識別子のようなもので、そのツールでは固定の glossary を一つだけ使うので。) もちろん、その文字列も今まで動いていたものから変更していない。もうちょっとエラーの詳細が知りたいところだが、「InvalidArgument」という以上の追加情報は得られないようだった。
最初に考えたのは、例外が発生するのはこのメソッドだが、実際に間違っているのはこれ以前の Cloud Translation API の呼び出しで、たまたまこのメソッドで間違いが発覚するのではないか、というもの。それで、ほとんど何もせずにこのメソッドに来るようにパッチしたコードを作り、少しずつ呼び出しを増やして原因を探ろうと考えた。ところが、何もしなくてもこのメソッドはエラーになる。クライアントオブジェクトを作って、クレデンシャルを設定して、それですぐ削除しても例外。クレデンシャルの設定に間違いがあるならその部分でエラーになるはずだし、そもそも削除の前の手順はさっきまで問題なく動いていたし。(ちなみに、削除するべき glossary は存在していたし (それはすぐに調べた)、もしも存在しない glossary を削除しようとすると StatusCode.InvalidArgument ではなく StatusCode.NotFound になることは分かっていた。)
いろいろと小さなテストコードを書いて状況を調べたりしたのだが、原因どころか、何が起きているのかもさっぱり分からず。もう深夜になっていたので、あきらめて寝た。
それで、今朝だ。朝起きてすぐに調査の続きをやろうと思ったら … 例外が発生しません。問題なく動きます。
いや、その。動いたからいいとも言えるが、昨日のアレは何だったんだ、と。Google さん、勘弁してよ、と。
とりあえず、不満の掃け口として、ブログに書いてみました。
ということで、たった一つの事象を一般化して導き出した法則:
Google の Cloud Translation API は、勝手に不調になって謎の例外が起きることがある。
その場合、放っておけば翌日には回復する。
(うーむ、本当だろうか?)
ちなみに、Cloud Transationi API を使い始めたころに作ったサンプルがここにあります。GCPのアカウントがあれば API を使った翻訳を試してみることができます。 (トラブったツールはこれじゃありませんがもしも機能これを動かしたら、一部機能は動作しなかったはず。DeleteGlossary 呼ぶ場所があるので。)
日本語で git のことを解説している記事を読むと、初心者向けのものも、かなり高度な内容のものも、だいたいどれも「ワークツリー」という用語を使っているようだ。記事によっては「作業ツリー」になっている場合もあり、また work tree とアルファベットで書いている場合もあるが、アルファベット表記の場合は worktree と一語で書いている記事と work tree と二語で書いている記事が両方あるようだ。
それで、本来英語ではどういうのかと思って git の公式の (英語の) ドキュメントを調べた。そうしたら、なんと、work tree でも worktree でもなくて working tree と呼ぶのが正しいようだった。
びっくりだ。
git のコマンドには、git worktree というものがあって、これは一語の worktree が正しいサブコマンド名。また、git が受け付ける共通オプションの中に --work-tree= というものがあって、これは work tree と二語で書く (ものを、単一のオプション名にするために間にハイフンを入れる) のが正しい。コマンドとしてはそれが正しいのだが、ドキュメントの説明の文章が、それを指す言葉としては、worktree とか work tree とかは使われてなくて、一貫して working tree という言葉を使っているのだ。少なくとも、git の公式ドキュメントは。(The Git Reference Manuals も、Pro Git も。どちらも英語版。)
それで、Reference Manual はだいたいどれも公式の日本語訳があったなと思って調べたところ、どうやら公式訳は「作業ツリー」と訳しているようだった。ただ、一か所だけ、用語集が「作業ツリー (working tree)」と英ママ (というか、対訳?) で書いている。
ということで、git のこの用語は、英語は「working tree」で、日本語は「ワークツリー」または「作業ツリー」ということらしい。
なぜ、英語の working tree をカタカナで書くと「ワーキングツリー」ではなくて「ワークツリー」になるのか。
すぐに思いつくのは、コマンドに出てくるのが worktree と work-tree なので、それが正しい用語だと思い込んでしまった、というもの。また、英文の公式ドキュメントを読まずに、日本語の解説記事ばかり読んでいるとどれも「ワークツリー」と書いてあるので、それを覚えてしまう人が続出して広まった、というもの。ストーリーとしてはもっともらしい。
でも、意図的にそうしている可能性もあるかもしれない。それは、世の中には英語からカタカナ表記を作る際の「ルール」みたいなものがあって、その中に「～ing は省く」みたいなのがあった気がするからだ。(「あるからだ。」と書こうとしてウェブで調べたが、そのルールを発見できなかった。なので「気がするからだ。」と書いた。私の思い込みかもしれない…。)
実際はどういう理由なのだろうか？
最近のコメント