シリカゲルの滑り止め？

アマゾンの様々な商品の説明を見ていると、変な場所に「シリカゲル」という言葉が使われているものがある。滑り止めやシール材をシリカゲルで作るはずはなく、実物はゴムっぽい素材なので、おそらくシリコーンゴムなのだと思う。そういう場合に販売者の住所を見ると、(今まで私が気づいたものは) 全て中国だ。逆に、(最近気にしているのだが) 住所が中国になっている販売者のいささか怪しい日本語の商品説明中で「シリコーンゴム」という言葉を見たことがない。常に「シリカゲル」と言っている。

おそらく、アマゾンが提供している機械翻訳システム (アマゾンに商品を出品する際に、商品説明を英語か中国語で入力すると自動的に日本語に翻訳してくれるらしい) が、中国語で「シリコーンゴム」を意味する言葉を「シリカゲル」と翻訳してしまうのではないかと想像して、いろいろと調べたのだが、良く分からない。

辞書などで調べると、「シリコーンゴム」は中国語では「硅橡胶」「矽氧橡胶」「聚烃硅氧」などと言うらしいのだが、実際にAWSの自動翻訳サービスで試すと前二者はちゃんと「シリコーンゴム」と翻訳される。最後の「聚烃硅氧」は「ポリ炭化水素シロキサン」という訳語になるのだが、どうやらこれは「オルガノポリシロキサン」の異称らしい。いわゆるシリコーン樹脂類の総称だ。(そういう意味では、「聚烃硅氧」はゴム質ではないシリコーン樹脂も包含する言葉なのかもしれないが、よく分からない。)

一方「シリカゲル」もいくつかの呼び方があるようだが、その中に「硅胶」というものがある。「硅橡胶」と比べると中一文字が抜けたものになっている。なので、(日本語や英語で「シリコン / silicon」と「シリコーン / silicone」を混同している人がいるように) 「硅胶」と「硅橡胶」を混同している人がいて中国語の原稿に最初から「硅胶」(シリカゲル) と書いてしまうことがある、ということならありそうだが、しかしそうであれば、ときどきシリカゲルになっている商品があるくらいならわかるが、100%どの商品説明もシリカゲルにはならないだろうと思う。

不思議だ。

何か変な焼き豚レシピ

ウェブで (Cookpadじゃない 😃) 見つけたプロっぽい人の焼き豚のレシピなのですが、変なポイントだけ書くと、

1. (いろいろ下準備) ... 片栗粉は倍量の水で溶いておく。


2. (タレを作ってかたまり肉を漬ける)


3. 冷蔵庫に入れて一晩おく。


4. 肉を低温加熱調理する (4時間)。


5. 煮汁を小鍋にとって 1 の水溶き片栗粉を加え …

このレシピだと、仕込み (前日) のうちに片栗粉を水で溶いて、そのまま一晩+４時間おいておく、ってことになっちゃいますよね。なぜ、そんなことをするのだろうか…。(しかも、そのころにはせっかく溶いた片栗粉がすっかり沈殿しちゃっているはず … って、そこは大事じゃありませんが。)

Google の Cloud Translation API Advanced Service (v3) って昨日は不調でしたか?

このブログに書くのは初めてだと思うのだが、数年前から 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 の「ワークツリー」という用語

日本語で 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 は省く」みたいなのがあった気がするからだ。(「あるからだ。」と書こうとしてウェブで調べたが、そのルールを発見できなかった。なので「気がするからだ。」と書いた。私の思い込みかもしれない…。)

実際はどういう理由なのだろうか？

AngleSharpでHTMLファイルを更新する

AngleSharpというと、皆さんウェブサイトのスクレイピングを目的に、専らHTMLの解析と情報の取り出しに使っているようだが、実はHTMLの書き換えや新規作成にも使える。そして、そういう使い方でも、かなり便利だ。

ということで、AngleSharpを、ローカルファイルのHTMLの更新に使う話。(AngleSharpでスクレイピングするやり方は、ウェブに説明が多数あるので、それと重複することには触れない。)

SgmlReaderとの比較

AngleSharpを紹介する記事 (のうち、比較的初期のもの) はたいてい「C#でスクレイピングをしようと思ったら、昔はSgmlReaderが定番だった」みたいに書いている。SgmlReaderはDTDを読んでそれに基づいてSGML文書を解析する機能を持っているので、HTML以外にも「XMLじゃないSGML」を何でも解析できるのが売りだったのだが、実際にはHTMLの解析にばかり使われていたようだ。

そのSgmlReaderとAngleSharp (のHtmlParser) を、HTMLファイルを読み込んで修正して (一部を書き換えて) 保存する、という使い方に関して比較すると、こんな感じだと思う。

	SgmlReader	AngleSharp
入力	TextReader、string	Stream、string、char[]、ReadOnlyMemory<char>
出力	Stream、TextWriter、ファイル、string	TextWriter、string
オブジェクトモデル・要素	全ての要素はXElement型という同じ型になっている。個々の要素の区別はNameプロパティを文字列として参照。(Linq to XMLの仕様)	それぞれの要素が専用の型になっている。IHtmlElementという共通のインターフェースもあり、要素を区別しないで扱うことも可能。
オブジェクトモデル・属性	属性を表すXattribute型があり、全ての属性は同じ型。個々の属性の区別はNameプロパティを文字列として参照。属性値は全てstring型 (整数などへの変換は容易)。(Linq to XMLの仕様)	各要素の型に、要素の属性に対応したプロパティがある。各プロパティの型は許される属性値を意識していて、stringの他にintだったりboolだったりする。ITokenList型なんてのもある。 他方、IElementには、属性名も属性値も文字列として操作するメソッドもあり、Linq to XMLのようなダックタイピング的な操作も可能。 要素ごとの型のプロパティで属性値を操作する場合と、IElementとして名前で属性を操作する場合とは連動していて、「両者を混ぜて使っていたら値がずれてしまった」みたいなことにはならない。
ドキュメント	Readmeがあるだけだが、機能が小さい上に、基本的にはXmlReaderと同じAPIを提供するだけなので、これで十分使える。	書きかけの(?)ドキュメントが10ページほどあるが、AngleSharpは巨大なライブラリー (30個以上のパッケージに分かれていて、パブリックな型だけで400以上ある) なので全然足りない。ソースにはdocumentation commentが書いてあるが、当たり前のことを機械的に書いた印象が強く、Intellisensも構文以上のことはほとんど教えてくれない。なので、使おうと思ったら、ソースを調べるか、ウェブを検索しまくるしかない。 開発チームの誰かが本を書いて売る、みたいな話もあるようだが、今のところ実現していないようだ。

AngleSharpの方がずっといいよね、一見して明らか、みたいな表になる予定だったのに、そうなってない。おかしいな…。

入力のエンコーディング

これはスクレイピングにも関係するので分かっている人が多いと思うが、SgmlReaderの入力はTextReaderか文字列かの二択。ファイルやネットワークから入手したバイト列であるStreamを直接扱うことはできない。つまり、エンコーディングは、SgmlReaderを使う以前に、アプリ側で判定してStreamReaderなりを呼び出す際に指定する必要がある。これは、一般的なSGMLを処理するのであれば、こうならざるを得ない。

ところが、実際のHTMLでは、エンコーディングはHTML文書中にmetaタグを使って書いてある。HTMLをパースした後でなければエンコーデイングが分からない。スクレイピングであれば、HTTP応答を見ることも可能だが、ローカルファイルを読むときにはContent-Typeとかcharsetとかを教えてもらうことはできない。また、特定サイトをスクレイピングするのであれば、あらかじめ使われているエンコーディングを調べてハードコードしてもいいし、2024年時点ではHTMLはUTF-8で作るのが常識だからUTF-8決め打ちで問題ないという考え方もあるだろう。でも、HTMLを扱うローカルツールとしては、UTF-8専用は気持ちが悪い。

SgmlReaderとは違い、AngleSharpは、入力をStreamで渡せば、metaに書いてあるエンコーデイングに従ってよろしく処理してくれる。素晴らしい。

ただし、AngleSharpでも出力はTextWriterなので、アプリ側でエンコーディングを指定してStreamWriterなどを用意しておく必要がある。書き出すときには解析済みのHTMLがあるので、metaを参照するのは簡単だが手間ではある。この手間をはぶくと、.NETのStreamWriterはデフォルトでUTF-8なので、元のHTMLがUTF-8以外のcharsetを使っているとおかしなことになってしまうので注意が必要。

出力のシリアライズ

SgmlReaderを使う場合、更新したHTMLを書き出すのは難しい。(SgmlReaderという名前なので、この点を責めるのはどうかとも思うが。)

SgmlReaderには対になるSgmlWriterのようなものは存在しない。なので、SgmlReaderで読んだHTMLを普通に書き出そうと思うと、XElement.Saveを使ったり、XElement.ToStringしてからFile.WriteAllTextを使ったりすることになると思うが、これは内部的に、XmlWriterというXMLをシリアライズする機能が使われるので、正しいHTMLにならない (*1)。

「<img src="...">」が「<img src="..." />」になるのはxhtmlでもそうなので許してもらえることが多いと思うが、空のscript要素、つまり「<script src="..."></script>」が「<script src="..." />」になってしまうのは非常に困る。

というわけで、書き出したい場合は、SgmlReaderは適さない。

AngleSharpは、もともとHTML用で、自分自身の出力機能を備えているので、問題なく書き出せる。

更新方法と書き出し方

• ドキュメントの更新は、要素に関しては、いわゆる普通のDOMのAPIがそろっており、clone、add、append、remove、replaceといったメソッドで操作できる。拡張メソッドだがInsertAfterとかInsertBeforeなどもある。
• 新しい要素の作成は、IDocumentのCreateElementを使う。(IDocumentは、IHtmlDocumentの親インターフェースの一つ。)
• ただし、要素をいくつも作って組み立てるのは面倒なので、パターンが決まっているなら、IElementのInnerHtmlプロパティを書き換えるのが簡単。これはstring型で、JavaScriptのInnerHTMLと同じように機能する。
• 既存の要素の属性値を書き換えるのは、対応するプロパティに値をセットするだけでいい。
• 属性自体を削除したい場合は、名前を指定してIElement.RemoveAttribute(string)を呼ぶ。

更新が終わって書き出すときは、

• IHtmlDocument html のときに、html.ToHtml() とするとHTML文書全体が一つの文字列になる。
• また、TextWriter writer のときに、html.ToHtml(writer) とすると、ファイル等に書き出せる。

---

*1 実は、XmlWriterのインスタンスを作るときに使うXmlReaderSettingsというクラスにはXmlOutputMethodというプロパティがあり、値としてXmlOutputMethod.Htmlを取ることができる。マイクロソフトによる、このプロパティの説明には、こう書いてある:

出力は、HTMLの規則やXML 1.0の規則などによってシリアライズできます。
この設定は、XSLTプロセッサが設定したり、Visual Studioが内部的に使用したりします。

なるほど、これはXSLTの <xsl:output method="html" ... /> を実現するためのものなのね、これでいいじゃん、と思って、プロパティを設定しようとすると、このプロパティは読み取り専用 (getのみでsetがない) ということに気づいて驚く。実際には、セッターが存在しないのではなくて、internal なだけなので、リフレクションを使えば好きな値を設定できる。そうやってXmlWriter.Createで取得したインスタンスは、正しいHTMLを作ることができる。

できるのだが、これはかなり「ウラワザ」的なので、お勧めできない。どうしてもやりたければ、リフレクションに頼るのではなく、XslTransformを使った方がいいように思う。大げさになってしまうが、正式な公開APIだけでHTML出力を実現できる。(XSLTプロセッサが作ったHTML出力のXmlWriterが動くわけだ。たぶん。)

Microsoft Wordの変更履歴の記録に使うXML要素

Microsoft Wordの.docxファイルというのは、実態はzipファイルで、中にいくつかのファイルが入っている。そのうち主要部分はdocument.xmlというXMLファイル。これはOffice Open XML (ECMA 376 / ISO/IEC 29500) という標準のうち、WordprocessingML というマークアップ言語 (というか、XMLスキーマ) に基づいている (*1)。ここまでは、割と良く知られていると思う。

それで、ちょっと事情があって、WordprocessingMLで、Wordの「変更履歴の記録」の機能がどういう風に表現されるのか調べた。そしたらこれが非常に複雑で、専門家と思われる人が書いた解説に矛盾があったりして (某氏のブログでは「以下に示す28種類の要素が」と書いた後の表が26項目しかない、など…) 全体を把握するのに苦労した。そこで、理解できたことの要点だけまとめておく。

(詳細を説明すると膨大な文章になってしまうので、要素の一覧と、仕様の該当箇所だけ。)

変更履歴の記録に使うXML要素

分類	要素	定義の場所	一言説明
表	cellDel	17.13.5.1	表のセルを削除
	cellIns	17.13.5.2	表のセルを追加
	cellMerge	17.13.5.3	表のセルを結合/解除
	tcPrChange	17.13.5.36	表のセルの書式を変更
	trPrChange	17.13.5.37	表の行の書式を変更
	tblGridChange	17.13.5.33	表の列の書式を変更
	tblPrChange	17.13.5.34	表の書式を変更
	tblPrExChange	17.13.5.35	表の例外書式を変更
挿入削除	del	17.13.5.12～15	削除
	ins	17.13.5.16～20	挿入
	moveFrom	17.13.5.21～22	移動元 (移動の操作によって削除)
	moveFromRangeStart	17.13.5.24	移動元の範囲の先頭の印
	moveFromRangeEnd	17.13.5.23	移動元の範囲の末尾の印
	moveTo	17.13.5.25～26	移動先 (移動の操作によって挿入)
	moveToRangeStart	17.13.5.28	移動先の範囲の先頭の印
	moveToRangeEnd	17.13.5.27	移動先の範囲の末尾の印
	delInstrText	17.16.13	削除されたフィールドコード文字列
	delText	17.3.3.7	削除された文字列
書式	rPrChange	17.13.5.30～31	文字書式の変更
	pPrChange	17.13.5.29	段落書式の変更
	sectPrChange	17.13.5.32	セクション書式の変更
	NumberingChange	(記載なし)	段落番号の変更

「定義の場所」は、ISO/IEC 29500-1の箇条番号。ここからPDFをダウンロードできる (「EN」というリンクをクリック。その下のElectronic Insertsでスキーマ定義のファイルなどもダウンロード可)。なお、この話の詳細を知るために29500を読む場合は、いきなり17.13.5.Xを読むのではなく、まず「8. Overview」を読み、次に「Annex L」の「L.1」(4,538ページから) を読むといいと思う。

NumberingChangeというのは、ECMA 376の初版に含まれていたが、その後削除された要素。このため、現在の29500には記載がないが、私が使う予定のOpenXML SDKはサポートしているし、今でもNumberingChangeを含んだdocxファイルは使われているらしいので、上の表に入れておいた。

他に、カスタムXMLマークアップの変更に使う要素が8種定義されている (17.13.5.4～11) が、興味ないし普通の人は使わない機能 (*2) だと思うので省略。

---

*1: 歴史的に正確に言うと、これは逆で、国際標準がWordの.docxファイル仕様に基づいている、というのが正しい。現在の.docxファイルというのは、もともとMicrosoft Office 2007のときにプロプラ仕様として作ったものを、Officeのバージョンアップのたびに少しずつ手直ししたものだ。他方ISO/IEC 29500というのは、このOffice 2007の.docxファイルを基にした国際標準として後から仕様化したものだが、このときに「いくらなんでも、これはダメでしょう」とか「国際標準としてここはマズいんじゃ」みたいな部分をちょっと変更したのでOffice 2007の.docxと少し違ってしまったのだ。

*2: カスタムXMLマークアップというのは、ワードの文章中にOffice OpenXMLとは別のXML要素を埋め込んでおいてユーザーアプリが自由に使うという機能。要は、XMLなんだから名前空間を分ければ何でも混ぜることができるわけなのだが、Word 2007にこの機能が追加されたときに、特許侵害と言われて裁判が起きた。莫大な損害賠償を請求された結果、マイクロソフトは (比較的少額の) 賠償金を支払い当該機能をOfficeから削除するということで和解した。この和解を履行するために、Word 2010以降のWordはカスタムXMLマークアップを新規に追加できないばかりか、Word 2007で作成されたカスタムXMLマークアップを含むdocxファイルを開いた際に強制的にカスタムXMLマークアップを全削除するという機能が追加された。

エクセルの「区切り位置」という機能

マイクロソフトのエクセルには「区切り位置」という機能がある。いわゆるCSVのように、項目をコンマとかタブとかで区切って並べたテキストファイルの各行がまとめて一つのセルに入ってしまっているものを、項目ごとにバラして複数の列に入れ直す機能だ。(この機能についてちゃんと知りたい人はネットで検索すれば、解説記事が大量に見つかる。) 

これはかなり昔からある機能で、便利なので私もときどき使うのだが、「区切り位置」という名前が直観的でなくて覚えられず、使うたびにメニュー (リボン) のどれだったか分からなくて毎回苦労する。この機能を使うときには「区切り位置指定ウィザード」というダイアログが開いて、どうやって各項目を切り分けるのかを選ぶようになっている。おそらく、それが「区切り位置」という名前の理由なのだろうと思ってはいた。この命名センスはどうなのかともずっと思っていた。(そんなことを考えているのに「区切り位置」という名前が覚えられないのもちょっとアレだが。)

ところで、Google Spreadsheetにも同じ機能があるのだが、そちらは「テキストを列に分割」という名前になっている。こっちの方がずっと分かりやすいし、機能の存在を知らない人がたまたまメニューで見かけても、何をやる機能か予想がつくんじゃないかと思う。(「区切り位置」の機能は、名前か想像するのは難しいだろう。)

それで、私は「マイクロソフトの (またはエクセルの) 開発チームの命名センスは変わっているのだろうな」と思っていた。ずっと。でも、そうじゃなかった。

今朝気づいたのだが、エクセルの英語版では、この機能は「Text to Columns」という名前だったのだ。つまり「テキストを列に」だ。分かりやすい。

つまり、命名センスがおかしいのは、エクセルの開発チームじゃなくて、エクセルのUIを日本語に訳した人だったのだ。ってゆーか。英語の「Text to Columns」という言葉を見て、それをそのまま翻訳したら、「区切り位置」にはならないよね。絶対に。だからこれは「単純に『テキストを列に』なんて訳しても、日本語圏の人には意味が分からないだろう。言葉を訳すんじゃなくて、内容が伝わるように分かりやすく言い直そう。」と考えた上での訳としか思えない。思えないのだが… これって分かりやすくなっているどころか、意味不明になってますよねえ。

いったいどうしてこういうことに…。

日本語Windowsのdotnetコマンドの出力を英語にする方法

.NET SDKの「dotnet」コマンドをWindowsにインストールすると、メッセージは「OSの言語」で表示される。つまり日本語Windowsだと日本語メッセージになってしまう。日本語話者なのでちゃんとした日本語メッセージならうれしいが、誤訳ばかりで意味不明なメッセージはいやだ。

そういう場合は DOTNET_CLI_UI_LANGUAGE という環境変数を en に設定すれば英語メッセージになる。fr ならフランス語、de ならドイツ語。好きな言葉を選べばOK。どれも日本語よりは大分まともらしい。(英語以外は私には評価できませんが。)

ただの環境変数なので、どうやって設定してもいいのだが、お勧めはアカウントに設定してしまうこと。こうすればcmd.exeでもPowerShellでも、あるいはvscodeが直接スポーンするような場合も効く。

[設定] > [システム] > [バージョン情報] > [システムの詳細設定] > [環境変数] から設定できる。

実行例はこんな感じ。

Snapdragon Dev Kit for Windows を購入してしまった

勤務先をクビになったこともあり、Snapdragon Dev Kit for Windows というものをポチってしまった。Snapdragon X Elite を搭載したミニPCで、Windows+PCをターゲットとした開発作業に最適ということになっている。Windows Dev Kit 2023の「AI対応版」という説明を見かけるが、Windows Dev Kit 2023はマイクロソフト製だったのに対して、こちらはQualcom製だ。(どちらの会社もPCの組み立て工場を持っているわけではないと思うので「XX製」というのは責任の所在という程度の意味だと思うが。)

送料込みで通常価格$899のところ、10%OFFクーポンをもらったので$809.10だった。クレカの請求額は¥127,045になるらしい。割高感があるが、円安なのでこんなものかな。

アメリカから発送し5日程度で届くとのこと。ちゃんと来るだろうか。

---

7月23日追記

いよいよ届くかなと思ってOrder Historyを確認したら、Est. Delivery (お届け予定日) が8月16日に書き換わっていました。なんだ、それ。悲しい。

---

8月1日追記

住所に使用できない文字が含まれているので修正せよ、みたいなメールが来た。それでウェブサイトにアクセスしたら、またもお届け予定日が変わっていて、今度は9月5日になっていた。どんどん遅くなっているが、それどころか、確認した日からお届け予定日までの日数も増え続けている。5日後 → 23日後 → 35日後。予定日変更に関する連絡や説明などは一切なし。不愉快だなあ。

とりあえず住所は修正したが、もうキャンセルしちゃうかなあ…。

---

8月10日追記

先週「もうキャンセルしちゃうかなあ」と書いたが、実際はそのまま放置してあった。しかし、ハローワークで面白くないことがあったので、半ば八つ当たりで発注をキャンセルする気になってArrow Electronicsにアクセスした。

すると、なんと、またまたいつの間にかお届け予定日が変わっていたのだが、今回は初の前倒しで、8月16日予定になっていた。つまり1週間後だ。7月23日の状況に戻ったとも言える。

1週間なら待ってもいいなあ、などと、また気が変わり、オーダーはキープ。さて、今度こそ無事に届くのでしょうか。

---

8月16日追記

届きませんでした。本日のお届け予定日は8月20日とのこと。

しかし、いったい何なんでしょうね、この予定日が頻繁に変わる販売システムって？ 何らかの理由で計画通り生産できていない？ 生産は計画通りなのだが、お得意様や大口注文が入るとそっち優先で出荷してしまい私のような重要でない顧客の分は後回しになる？ そもそも生産計画と無関係に適当にお届け予定日を決めている？

8月16日追記2

ebayに出品している人がいる。https://www.ebay.com/itm/305712232803
新品未使用で2個あるとのこと。(まとめ売りじゃなくて1個ずつの販売。)

価格は、なんと$2,499.00。標準価格の約3倍。いわゆる転売ヤーさんなんですかね。そうだとしても、どうやって入手したのかは気になる。「これは絶対品薄になる」と予測して、販売開始から秒で何台も発注した感じですかね？

※ 関係ないけど、ebayは同じものを複数販売する場合「×個あります」という形で出品できる。上の出品もその仕組みを使って2個販売している。逆に、同じ人が全く同じ商品を多数出品することは禁止されているらしい。メルカリもそうすればいいのに。

---

8月18日追記

今見たら、上に書いたebayの出品は残り1台になっていました。つまり、1台売れたってことですかね。そういう意味では、元々もっとたくさんあったのが、16日には残り2台になっていたという可能性もあるわけで。

PS5のような一般消費者向けの商品でなくても、転売ビジネスは成立するということなのでしょうか。

まあでも、検索してもSnapdragon Dev Kit for Windowsを売りに出しているのはこのebayの出品者しか見つからないので、「転売ヤーたちが買い占めてるから一般人が購入できない」わけではなさそう。

---

8月20日追記

お届け予定日は8月20日から変わっていないが、order statusも「pending」のまま変わっていない。これは1か月以上前に注文した直後からずっと同じ。pendingは解釈が難しいが、まだ出荷されていないのは間違いないのだろう。

---

8月23日追記

実は20日の追記を書いた後で、カスタマーサポートに問い合わせた。

ウェブでContact Supportというページを見ると、アメリカとイギリスと中国の電話番号が記載されているが、これはパス。よくあるウェブ問い合わせフォームもあったので、そこから「estimated delivery dateを過ぎていますがどうなっているのですか?」みたいなことを書いて送信。その後24時間待ったが返事がない。

それで、あまり気が進まなかったが「テキストチャットサポート」を試してみた。最近のチャットサポートはたいていAIが返事をするのだが、Arrowもそうで、意味のある回答が得られない。たいてい、しばらくチャットを続けているとAIがあきらめて人間を出してくれるので、それまで付き合う必要がある (これがイヤなのだ、私は)。で、ついに「それでは人間のオペレーターに交代します」みたいになって人間 (と思われる) サポート要員が出てきた。「予定日を過ぎても出荷されていないようなのだがオーダーが今どういう状況なのか知りたい」みたいなことを言うと「状況を確認しますのでしばらくお待ちください」みたいなことを言われた。これは普通だ。しかし、そのまま無言。しばらく (1分くらい?) 待っても無言のままなので「Hello?」とか「Are you still there?」とか何度か入力してみるが全く返事がない。その後5分ほど無言が続いたので「じゃあ、返事はメールで送ってください」みたいなことを書いてセッション終了。それが21日。

で、翌22日も音沙汰無だったが、今日23日にメールが来た。「Your order is currently processing, and we're doing everything we can to get it delivered to you right on time.」だと。「注文は現在処理中です。予定通りに届けることができるよう全力を尽くしています。」みたいな感じか? まあ定型文なのだろうが。「いや、だから、もう予定を過ぎてるから問い合わせたんだけど。そもそも発注したときの予定から1か月過ぎてるんだけど。」と思ってウェブのOrder Statusを確認したところ、予想通りというか何というか、またお届け予定日が書き換わっていて、今度は9月20日になっていた。

---

9月2日追記

もう待てないという気持ちになったことと、他に欲しいものができてしまったことから、今度こそ (8月10日の追記参照) Snapdragon Dev Kit for Windowsはキャンセルすることにした。

Arrow Electronicsの通販サイトでキャンセルボタンを探すが見つからない。FAQを探したら「商品によってキャンセル方法が違うので、チャットで問い合わせろ」みたいに書いてある。そこでAIチャットから問い合わせる。が、一向にキャンセル方法を教えてくれない。最初はいろいろと長く書いていたのだが「何を言っているのか分からりません。別の言い方を試してください。」みたいなことを言われる。ひょっとしてキャンセル要求が来ると分からないフリをするように訓練されたAIなのかとも思ったが、何回か表現を変えて繰り返すが変わらず。最後に「I want to cancel my order!」と入れたら (最後のビックリマークが効いたのか?) ついに「人間のオペレーターに交代します」になったが、十数秒後に「現在対応できるオペレーターがいません。後ほどメールで連絡します。」となって終わった。

で、また待たされるかと思ったら、今度は数時間でメールが来て「注文をキャンセルしたいのですね。喜んでお手伝いします。」みたいに書いて来た。それで「すでにこの注文はキャンセルできました。」(the order has been successfully canceled) と書いてあったので、キャンセルは対応が早いなと思ってウエブサイトを確認したところ、キャンセルされておらず、相変わらずstatusがPendingで、お届け予定日も9月20日と表示されるままになっていた。

むむむ。

---

9月5日追記

キャンセルできたかどうか不安だと思っていたところ、昨夜 (4日) 「Delivery update (配送状況のお知らせ)」というメールが来た。「お客様のご注文は9月後半に必ずお届けします」みたいに書いてある。キャンセルできていないのかと驚きウェブサイトを確認したところ、statusがCancelled (キャンセル済み) になり、金額も$0.00になっていた。なぜメールが来たのか分からないが、注文は無事にキャンセルできているように見える。

メールには「仕様変更のお知らせ」も含まれていて「Your device will now ship with a USB-C to HDMI dongle, in lieu of an embedded HDMI port.」と書いてある。「内蔵HDMIポートの代わりに、USB-CからHDMIへの変換器を添付します」という感じか。つまり、「HDMIポートは削除になった。代わりに変換器を付けるから許してね」ということだろう。確かに製品仕様も書き換わっている。

今の製品仕様: Snapdragon-Dev-Kit-for-Windows-Product-Brief-original.pdf
注文したときの製品仕様: Wayback Machine (archive.org)

よく見ると価格も変わっていて (値下げ)、私が注文したときには$899.00を10%オフのクーポンで$809.10になったのだが、今はだれでも (クーポンなしでも) $809.10のようだ。ちなみに販売サイトの在庫状況は「在庫なし、入荷予定: 13週間後」のようだ。

なんか、もう、いろいろグダグダですね。

I225-V driver

インテルI225-V (2.5Gb Ethernet) のWindows 11用ドライバーを単体で入手して手動でインストールしたい場合、「インテルイーサネット・アダプターコンプリート・ドライバー・パック」というものをダウンロードして、この中からファイルを取り出すことができる。(中点の入り方が気持ち悪いが、これが正式な日本語名称らしい。)

かなり大きなzipファイルをダウンロードして展開すると、たくさんのフォルダーに分かれてたくさんのファイルが入っているが、その中のPRO2500/Winx64/W11というフォルダーに入っている５本のファイルがI225-Vのドライバー。これら5本のうち、readme.txtを除く残りの4本のファイルをzipから取り出して適当なフォルダーに入れておき、e2fn.infを右クリックして [インストール] を選べばインストールできる。

インテルイーサネット・アダプターコンプリート・ドライバー・パックは インテル® イーサネット・アダプターコンプリート・ドライバー・パック (intel.co.jp) からダウンロードできる。

この zip ファイルには、ほとんどの インテル® イーサネット アダプターで現在サポートされているバージョンの Windows*、Linux*、および FreeBSD* 用のインテル® イーサネットネットワークドライバーとソフトウェアがすべて含まれています。

ということなので、Windows 11以外のOSや、I225-V以外のチップのドライバーを探している人にも役に立つかもしれない。