2017年10月20日 (金)

CancelEventArgs は Serializable じゃない

System.ComponentModel.CancelEventArgs は Serializable じゃない。だから remoting で渡せない。
 
だったらこんなの使わねーよ、自分で作るよ、たかが bool 一個なんだし、みたいな。
こうして、名前が違うだけで同じ内容のクラスがどんどん増える。再利用せずに。
System.ComponentModel という namespace の名前が空々しい。
 
というか、まあ、謎の誤動作の原因を調べたらこれだったという、俺の1日を返せ、みたいな。でも、なんというか、EventArgs 的なクラスはいつでも必ず絶対に Serializeable なものだと思い込んでいて、早い段階で間違った道に突き進んでしまったのが敗因なんですけど。
 
とはいえ、なぜ Microsoft がわざわざこれを Serializable なしにしているのか疑問ではある。さすがに「うっかり忘れました、テヘペロ」じゃないよね…。

2017年6月17日 (土)

DBANをUSBメモリーにインストールする

私は昔からハードディスク消去ソフトとしてDBAN (Darik's Boot and Nuke) を愛用している。

これはCD用のisoイメージで提供されるのだが、イマドキCDはいやなのでUSBメモリーにインストールしたい。ところが、Universal USB Installerではうまくインストールできなかった。

いろいろ調べたが、原因がよくわからない。昔、たしかにDBANをUSBメモリーにインストールしたことがあって、そのときはUniversal USB Installerを使ったはずなのだが、両方ともバージョンが上がっているし、PCのブート環境もUEFIとかいろいろあるので、状況が変わったということなのだろう。

isoイメージをUSBにインストールするというソフトは他にもいろいろあるので、適当に評判の良さそうなものを試したが、なぜかどれもうまくいかない。結局、3つ目か4つ目に試したRufusでうまくインストールできた。

結果オーライ。

因みにバージョンは、DBANは2.3.0、Rufusは2.15を使用。どちらも今日時点の最新版。

2017年6月11日 (日)

その後の食洗機

4年ほど前に、狭い台所に無理やり食洗機を置いた話を書いたが、その後もう少し台所が広い部屋に引っ越して、今はまぁ普通に置いている。
現在の様子はこんな感じだ。
Washer1
 
Washer2
シンクの左側は、本来冷蔵庫を置くスペースだと思うのだが、かなり余裕があったので、シンクの左に食洗機用の台を置き、その左に冷蔵庫を置いている。台は、以前使っていたキッチンワゴンでもよかったのだが、食洗機に入れる食器の水が垂れることがあり、ワゴンに入れてあるものが濡れてしまうことがあった。シンクのすぐ隣に置けば水はねもあるだろう。そう考えて、ワゴンは別の場所に置き、ここは専用の台を用意することにした。ホームセンターで見つけた組み立て式の棚だが、棚板をほとんど入れず、実際には大型のごみ箱を置いている。
 

2017年5月28日 (日)

久しぶりのPCアップグレード

10年くらい前は結構頻繁にPCの部品買っていたのですが、最近はあまりやらなくなってました。ふと気が付くと、最近のゲームが動きにくくなっていて、久々にアップグレード。
AMD Ryzen 7 1700
ASRock AB350M Pro4
G.Skill F4-2400C15D-32GVR (DDR4-2400 16GB CL15 x 2)
Samsung 960EVO (M.2 NVMe SSD 500GB)
久々だったので coldsweats01 これだけまとめて買い込みました。
 
Ryzenはメモリの相性が、みたいな話があるので心配だったのですが、適当に買ったモジュールで特に問題なく動作しました。
また、RyzenはUSB3が、みたいな話がありますが、今のところなにも問題起きていません。もっとも、手持ちの USB3デバイスはストレージだけで、残りのキーボード、マウス、ゲームコントローラーはどれもUSB2デバイスだから、かもしれません。

2016年8月27日 (土)

WPF で OpenFileDialog にコントロールを追加する

結論
  • Microsoft.Win32.OpenFileDialog をハックするのは困難。
  • それよりも Microsoft Windows API Code Pack の CommonOpenFileDialog を使う方が良さそう。
  • Microsoft Windows API Code Pack は nuget にある。
ということで、やはり自分で作るより出来合いのものを拾うのが吉ということか。
Microsoft Windows API Code Pack は、msdn のページも削除されて久しいし、メンテされていない。フォークをメンテしようとしている人もいるようだが、あまり活発ではない様子。ソースはあるので、自分に必要な個所だけ自力で直す覚悟をすることになるのだろう。
 
 

2015年11月 1日 (日)

昨日土曜日はハロウィンだったわけですが

金曜日の夜、また日は昼間から夜まで、新宿、原宿、渋谷あたりでは妙な衣装の人たちを大勢見かけた。たぶんハロウィンのイベントとかパーティとかに行く人たちなのだろう。帰る人もいたかもしれない。みなさん衣装のまま電車に乗り、ふつうの街中を歩いていた。

その姿で交番の前を通りすぎる人たちもいて、警官も別に気にしていないようだった。

なぜなのか。

いや、僕は別に警察が取り締まるべきだと思っているわけではない。だが、コミケに代表されるマンガ・アニメのイベントでコスプレをする人たちは「会場で着替える」ということになっていて、「コスプレ衣装のまま会場敷地から外へは絶対に出るな。出たら犯罪だ。」みたいな話になっている。それとの落差が気持ち悪いのだ。

なぜ、マンガ・アニメのイベントに参加する人は、衣装のまま街を歩いてはいけなくて、ハロウィンのイベントに参加する人は、衣装のまま街を歩いても問題ないのか。

理由がさっぱりわからない。

ちなみに、僕が実際に見かけただけで、セーラームーンっぽい女の子5人組とか、マリオとルイジっぽい人たちとか、スパイダーマンっぽい人とか、コミケのコスプレで見かけても違和感のない人がそれなりに混ざっていた。だから、具体的にどういう恰好かということは、街を歩いていいかどうかの基準とは関係ないのだろう。

不思議だ。

kono

2015年10月18日 (日)

すし職人ロボット

東洋経済オンラインで「人間の生活は人工知能に脅かされるのか?」という記事を読んだ。その中の一部に疑問、というかイチャモン。
この記事では、1ページ目の最後に
人工知能搭載の寿司職人ロボットが、本物の寿司職人を凌駕する日が来るかもしれません。
と述べ、それを受けた「そうなると、寿司職人も失業してしまう?」という問いに対して
そうはならないでしょう。
ロボットを前にして寿司をつまむのが楽しいでしょうか。私なら、ベテランの寿司職人と会話を楽しみながら寿司を食べるほうがいい。
として、すし職人をりょうがするロボットができても職人は失業しないだろうと主張する。
本当だろうか?僕には、そうは思えない。
それは、すしを作るのが人間の職人よりも上手なロボットが実用化され、それが妥当な価格で供給されたら、すしはロボットに作らせ、客との会話が得意な(すし職人ではない)人間を接客用に雇うのが合理的だと思うからだ。たぶん、すし職人にも、客との会話が得意な職人も、得意じゃない職人もいるのだろう。客との会話が上手なことがすし職人の必須スキルなのであれば(そうなのかどうか、よく知らないが)、一流のすし職人は必ず会話が上手ということになるが、その場合は「会話が苦手というだけの理由で二流とみなされている、すしを作る技術は超一流の職人」みたいな人が大勢いるのかもしれない。
なんであれ、たぶん世の中には、そういうすし職人さんよりも、すしは握れなくとも会話が得意という人が大勢いるはずだ。会話が得意なすし職人と、会話が得意なだけの人とを比べたら、たぶん会話が得意なだけの人のほうが会話は上手なのではないか。少なくとも同程度の賃金で雇えば。逆に言うと、会話の技術が同程度の人を、すし職人でもある会話が得意な人よりは、会話だけが得意な人を雇ったほうが安上がりに雇えるだろう、ということだ。
そもそも、この記事自体が
人工知能が得意な分野は人工知能に任せてしまい、私たち人間は人間にしかできない、人間の脳が得意とする分野で力を発揮する。人間と人工知能が互いにすみ分けをしながら、共存していけばいい
と述べているのだ。すしを作るのは人工知能のほうが得意、というのが本当になったなら(冒頭に紹介した議論は、仮にそうなったら、という前提の話だ)、すしを握るのはロボットに任せてしまい、客が楽しく会話する相手をするという、人間にしかできない分野を人間が担当すればいい、という主張にどうしてならないのか。それがおかしいと思った。
ちなみに、実は僕は、「ベテランの寿司職人と会話を楽しむ」という感覚がさっぱりわからない。僕は、すし職人にかぎらず、外食店にも限らず、店員と会話したくない。口をききたくない。こちらから話しかけるのも、何か話しかけられるのもイヤだ。だから僕は、(店員と会話して注文を伝える必要のない)券売機で注文品を選べる店が好きだし、すし職人が作るすし屋でもカウンターじゃなくてテーブルに座りたいし、もっと言うと多少まずくても回転ずしのほうが好きだ(注文を口頭で伝える必要がないことのほうが、多少の味の良し悪しよりも、僕には重要なのだ。まぁ、値段が安いというのも魅力だが。coldsweats01)だから僕は、そういう人間の職人よりもうまいすしを作るロボットが実用化されたら、そもそも会話用に人間をやとうこともしない店(たぶん、そういうのも登場するだろう)を好むことになるに違いない。
まぁ、最後の部分は、たぶん、僕が変なヤツだと言っているだけで、元記事の問題ではないのだが。

2015年9月22日 (火)

今までに見た中で最低のWindowsのメッセージ

日本語版Windowsの出すメッセージは誤訳が多い。
昔(Windows 3.1 とか)のWindowsが出すメッセージは、誤訳というよりも日本語として成立していないようなものとか、文法上は日本語になっているが内容が意味をなさないものとかが多かったが、最近のWindowsのメッセージは、文法上まったく正しい流暢な日本語で、一見すると(その文だけを文脈なしに読むと)意味もよくわかるが、でも文脈と整合していないという類の誤訳になってきている。
でも、文脈と整合していなければ何かおかしいと気づく、それは素晴らしいことなのだなと、今日痛感した。それは、今朝Window 7からWindows 10にアップデートしたあと、こんなメッセージが出たからだ。
About_to_fail
「バックアップを保存するディスクに障害が発生しようとしています。」と言っている。これは、まぁ要はディスクが壊れかかっているという意味だと思うよね。ってゆーか他に考えられない。
この「バックアップの場所」というのは、実際には増設ハードディスクで、たぶんもう5年以上使っている。(バックアップされていた一番古いファイルは2012年4月というタイムスタンプだった。3年半経っている。)そろそろ壊れても何の不思議もない。SMARTなんてものもあるし、ドライブのファームウェアが不調を検出して、それをWindows 10になって機能強化されたバックアップソフトが教えてくれた、なんて、非常にまともなシナリオだ。文脈に照らしてもきわめて妥当だ。
…でも、そうじゃなかった。(だから誤訳の話から入ったわけだし。coldsweats01)
最初は、ディスクが壊れかけているのだと信じて、何も疑わず、ただ、どれくらい緊急なのかを知りたいと思っただけなのだ。それで、このメッセージをぐぐってみた。「このメッセージが出たらあと××日くらいで故障が起きると思いましょう」みたいな解説記事を期待したのだ。が、ヒットしない。1件もヒットしない。似た文言はいくらでもあるが、そのものズバリがない。
Windowsのメッセージで検索すると、たいていは対処法の記事がみつかるものなので、これには驚いた。ひょっとして、このメッセージは滅多に出ない、きわめてマレなものなのだろうか。確かに、Windowsの標準のバックアップソフトで自動バックアップを設定していて、そのバックアップ先を増設ディスクにしている人というのは、あまりいないのかもしれない。その少ない人数の人が、たまたまディスクの故障に遭遇するのはめずらしいことなのかもしれない。そう思った。
そこで、日本語版Windowsに比べれば圧倒的に利用者の多い英語版Windowsの同じメッセージで調べれば何かわかるだろうと思い、マイクロソフトのLocalized Error Message Lookupで英語のメッセージを調べた。実は、僕がここで英語メッセージを調べるのは、誤訳としか思えないメッセージをみつけ、その正しい意味が知りたい時だ。そのため、ひょっとしてこのメッセージも誤訳かも、という気が一瞬したが、どうも、そういうことではないようだった。
英語のメッセージは、「The disk that your backup is saved on is about to fail.」というものだった。この英文も、ディスクが壊れかけているという意味に見える。「バックアップを保存するディスクに障害が発生しようとしています。」という翻訳も、まったく妥当に見える。
それで、この英語のメッセージを検索してみると、記事がいくつか見つかったが、どれも「買って間もないディスクでこのメッセージが出た」とか「冗長構成NASでこのメッセージが出たが、NASの管理ソフトで診断しても何ら異常はみつからない」とか、このメッセージの内容が状況と整合していないと感じた人たちの当惑がフォーラムに投稿されたものだった。そして、その結論は驚くべきものだった。
このメッセージは、そういう意味じゃないのだ。ディスクが壊れかけているわけではないのだ。
フォーラムの回答によると、このメッセージが伝えようとしている内容は、「このままこのディスクにバックアップを続けると、バックアップ処理が失敗しますよ。」ということなのだそうだ。
びっくりだ。
では、バックアップがなぜ失敗しそうなのか。それは「システム イメージ」のバックアップをしているから、らしい。「システム イメージ」というのは、要はOSそのもので、Windowsをアップグレードすると、システム イメージの形式が変わって同じ場所に上書きでバックアップできなくなるのだそうだ。
そんなこと、このメッセージからは絶対にわからない。
どうやら、英語でも同じ状況のようで、英語のネイティブスピーカーが、そういう意味だとわかった上でこの「The disk that your backup is saved on is about to fail」という文を読み返しても、そういう意味に解釈するのは無理らしい。真相は不明だが、英語がへたくそな(でも、たぶんプログラムを書くのは上手な)エンジニアが書いた、英文として成立していない変な英文をテクニカルライターがチェックして、内容を誤解した上で「文法上正しいきれいな英文」に書き直したのだろう、みたいな話になっていた。うーん。まぁ、そういうこともあるかも。
ということで、本件の結論。
「バックアップを保存するディスクに障害が発生しようとしています。」というメッセージは、「ディスクが壊れかけている」という意味ではない。「このままの設定でバックアップを取るとソフトウェアの仕様によりエラーが起きる。」という意味である。
この奇妙な日本語メッセージの原因は誤訳ではない。おかしな英語のメッセージを正確にそのまま翻訳したことが原因。
いやはや。最低だ。

2015年7月12日 (日)

新骨言道、あるいは、WPFが言語を意識してフォントを切り替えているらしい件

 WPFには Language という dependency property (日本語では「依存関係プロパティ」と言うらしい) がある。このあたりに説明があるが、これを読んでも、どういう働きをするのかさっぱりわからない。

それで、ふと思いついてサンプルプログラムを書いてみたところ、どうやら font fallback (日本語では「フォンント フォールバック」と言うらしい) の選択に使っているらしい。いや、他にも使っているのかもしれないが。

と、いうことで、これがサンプル。(例によって、画像をクリックすると拡大します。)

Wpf1

バリバリのWPFプログラマーの皆さんには常識だったりするのかもしれないが、そういう層と、こういう地域による漢字の字体差に関心がある層との間にはかなり距離があるような気がする。後者の人たちは、マイクロソフトがどういう努力をしているか全然知らないんじゃないかという気もする。このサンプルを見て面白がっていただければ幸いです。

さて、プログラマ的には、見所は、

  • XAML の Label 要素には、それぞれ異なる Language 属性を指定しているが、フォントに類するものは指定していない。
  • フォントの指定は Window 要素に対して行っており、そこに FontFamily="Arial" と書いてある。

というあたり。

後者がどうして見所なのかというと、次のスクリーンショットを見るとわかる。

Wpf2

こちらは、Language の値によらず同じ表示になっているが、XAML 上の違いは、WindowFontFamily を削除しただけ。なぜ、そうなるのか、よくわかっていないのだが、どうやら Label/@Languageの働きは、最初からフォントを選ぶわけではなくて、フォント フォールバックに影響を与えるだけらしい、という気がする。

Visual Studio で WPF アプリの XAML 書いている人は先刻ご承知と思うが、Visual Studio のウィザードが生成する雛形 XAML には、FontFamily 属性はついていない。FontFamily 属性を指定していない XAML の要素のプロパティを Visual Studio で見ると、FontFamily のデフォルトは Meirio UI である、と表示される。(日本語 Windows で開発している場合。) この、「デフォルトは Meiryo UI」ということの意味も、よくわからないのだが、これは「実行時には Meiryo UI が使われる」ということではなくて、「FontFamily として Meiryo UI が指定されているものとみなす」ということのようだ。そうでないと、ここで観察した動作は説明できないように思う。

つまり、FontFamily="Arial" があると、各 Label では Arial を使って「新骨言道」と表示しようとするが、Arial というフォントにはそんな文字は含まれていない。それでフォント フォールバックの仕組みが働き、Language の値を参照してフォントを選択する。他方、FontFamilyがないと、まず FontFamily のデフォルト値として Meiryo UI が採用され、各 Label は Meiryo UI を使って「新骨言道」と表示しようとする。Meiryo UI にはこの4文字が含まれるのでフォント フォールバックの仕組みは働かず、Langauge が参照されることもない。そういうことなのだろうと思う。

いわゆる英語版のウィンドウズでは、フォントのデフォルトは Meiryo UI ではない。Segoe UI になるはずだ。Segoe UI にも、「新骨言道」は含まれない。ということは、上の 2 個目のサンプル プログラムは、完全に同一の XAML であっても、英語版の Windows で開発すると、1 個目のサンプルと同じ表示になるのだろうか。それとも、開発した環境じゃなくて、実行した環境によって、つまり 2 個目のサンプル プログラムは、英語版の Windows で実行すると、1 個目のサンプルと同じ表示になるのだろうか。いずれにしても気持ち悪いし、前者ならまだしも、後者だとすると、これはサポート担当者には悪夢じゃなかろうか。(この悪夢を避けるためには、Language 属性の使用を禁止するだけでいいのだろうが。

ちなみに、WPF ではデフォルトのフォントはどうやって決まるのか、という点は、世界中のプログラマを悩ませている謎のようだ。英語でそれっぽい検索をすると、様々な驚くべき現象に出会った人たちがみつかる。MSDN のサポート フォーラムにも似たような質問が多数ある。マイクロソフト側の人の回答は大抵の場合「様々な要因によって最適なものが選択されます」みたいな、意味がわからないものだ。たぶん、回答している人にもよくわかってないんじゃないかと思う。

«プライバシーポリシー