寝ていて夜中に目が覚めるときがあります。部屋が暗いので枕元にある時計の時間を読むことは出来ないのですが、ボタンを押すと時刻が音声合成音で流れる仕組みになっているので何時頃なのかが分かります。
夜中に目が覚めるたびに時刻を聞くようにしていると、次第にある傾向が見えてきました。それは目が覚める間隔は90分程度になっているということです。必ず90分たつと目が覚めるわけではないし、1時間ごとや、2時間ごとに目が覚めることだってあります。しかし巷に流布している「90分睡眠サイクル説」は、自分の体験から考えると（絶対に正しい不変的な法則とは思いませんが）概ね正しいと感じています。
毎朝の起きる時間は（休日も含めて） 同じにするように心がけています。目覚ましをかける時間は一念を通じて（若干の例外を除き）同じです。正直に告白すると、目覚ましが鳴っても起きられず、二度寝してしまうことが無いわけではありませんが、出来る限り一定時刻に起床するように心がけています。
このような生活を続けていると、身体のリズムが自分の生活習慣に同期してくるようです。つまり朝になって、目覚ましが鳴っていないのに、ふと目が覚めてみると起床予定時刻の1分前だったというような体験をするようになります。
もし生活の都合（夜勤と日勤が交互に繰り返されるなどの事情）で、就寝時刻や起床時刻が一定しないとすると、身体リズムが混乱するのではないかと思います。寝ようとしても眠れないとか、起きようとしても起きられないとかなるのではないでしょうか。
人間の生活のリズムは、朝起きた時点でリセットされると言われます。就寝時刻が多少変動したとしても、起床した時点で人間の身体リズムがリセットされるから、体調を整えるには起床時刻を一定にすることが大切だと指導されたりもするようです。
朝起きるのが苦手と訴える人は少なくありません。その理由として、低血圧だからとか、実は人間の身体リズムは24時間ではないからだとか、真偽の定かではない主張をします。その主張が妥当であるか否かは簡単に結論がでるような問題ではなさそうです。物理法則のように古今東西いつでも原則を違うことはないというような理論はできないのではないでしょうか。いろいろな事情があるとしても、人間も生物（動物と言うべきでしょうか）の一種として、原始的な身体リズムとは無縁ではいられないと思うので、規則的な習慣と身体リズムの関係を意識しておくことも（他にも大切なことは数多く考えられますが）大切だと思います。
2017-02-22
LibreOffice Calcのキーボードショートカットの扱いの違い
dynabook SS SX/15AにNetBSD/i386を入れて、従来Windows Vistaでおこなってきたのと同等の環境を構築しようとしています。これまでもLibreOfficeを使っていたので、NetBSDに切り替えても問題は無いだろうと見込んでいました。
試験的にNetBSDのLibreOffice Calcを使って、これまでWindowsのLibreOfficeでおこなってきた作業をやってみました。メッセージが日本語になっていないとか、バージョンが若干違う（Windowsはバージョン5.2.5.1ですが、NetBSDのpkgsrcから入れたLinuxバイナリ版ではバージョン5.1.0.3）などの相違があるものの、ほぼ問題なく作業を行えました。
ただしキーボードショートカットの動作がWindowsの場合とNetBSDとでは大きく異なりました。具体的には「Ctrl+Shift+;」において「現在時刻の挿入」であるべきところが「Insert Cells」になってしまうのです。
メニューから[Tools]-[Customize ...]を選択し、開いたウィンドウのタブKeyboardを確認したところ「Ctrl+Shift+;」は「Insert Current Time」に割り当てられていました。これはWindowsと同じなので、それであれば現在時刻が挿入されるはずです。
ところが「Ctrl++」には「Insert Cells」が割り当てられています。dynabook SS SX/15Aのキーボードは日本語配列なので「;」の刻印のあるキーは、シフトすれば「+」になります。ということは「Ctrl+Shift+;」というショートカットのつもりなのに「Shift+;」が「+」と扱われてしまうため、結局「Ctrl++」になってしまっているようです。
このような理屈は分からないでもないのですが、それならば何故Windowsでは問題にならなかったのでしょう。Windowsでも日本語配列のキーボードを使っているのです。
キーボードショートカットだけの問題であれば定義を変えてしまえば解決することです。どうやらWindowsとNetBSDの各OS上で動作するアプリケーションにおけるキーボード入力の扱い方の相違という根本的な問題がありそうです。
試験的にNetBSDのLibreOffice Calcを使って、これまでWindowsのLibreOfficeでおこなってきた作業をやってみました。メッセージが日本語になっていないとか、バージョンが若干違う（Windowsはバージョン5.2.5.1ですが、NetBSDのpkgsrcから入れたLinuxバイナリ版ではバージョン5.1.0.3）などの相違があるものの、ほぼ問題なく作業を行えました。
ただしキーボードショートカットの動作がWindowsの場合とNetBSDとでは大きく異なりました。具体的には「Ctrl+Shift+;」において「現在時刻の挿入」であるべきところが「Insert Cells」になってしまうのです。
メニューから[Tools]-[Customize ...]を選択し、開いたウィンドウのタブKeyboardを確認したところ「Ctrl+Shift+;」は「Insert Current Time」に割り当てられていました。これはWindowsと同じなので、それであれば現在時刻が挿入されるはずです。
ところが「Ctrl++」には「Insert Cells」が割り当てられています。dynabook SS SX/15Aのキーボードは日本語配列なので「;」の刻印のあるキーは、シフトすれば「+」になります。ということは「Ctrl+Shift+;」というショートカットのつもりなのに「Shift+;」が「+」と扱われてしまうため、結局「Ctrl++」になってしまっているようです。
このような理屈は分からないでもないのですが、それならば何故Windowsでは問題にならなかったのでしょう。Windowsでも日本語配列のキーボードを使っているのです。
キーボードショートカットだけの問題であれば定義を変えてしまえば解決することです。どうやらWindowsとNetBSDの各OS上で動作するアプリケーションにおけるキーボード入力の扱い方の相違という根本的な問題がありそうです。
2017-02-21
2017-02-19
XML構造化をおこなうための「思想」はどこで学べるのか
O'REILLYの『入門XML 第2版』を読んでいます。技術的側面は何とでもなると思いますが、思想的側面を学ぶにはどうしたよいのだろうかと考えています。例えば、次のようなことです。
「3章 情報のモデル化」において「例3-1 小切手帳の文書例」から一部を抜粋します。
「支出」というものの中に「金額」、「日付」、「支払い先」、「明細」があります。しかし「分類」は「支出」の一属性として扱われています。何故でしょう。「分類」も「金額」などと同じ副項目に落としてはいけないのでしょうか。また逆に「金額」などを「支出」の属性としてはいけないのでしょうか。
これは何かの方針に基づく決め事なのではないかと想像しています。その方針（または思想）に応じて決めれば良いのでしょう。何かが絶対的に正しく、何かがそうではないというわけではないのだと思います。
ひとつの類推として、RDBにおける正規化の理論が思いつきます。理論的に正規化すべきではあるけれど、実装などの都合で正規化をくずすことも無いわけではないようです。これはRDBの知識に欠けた担当者が、やみくもに実現するという情けない理由ではなく、それなりの判断の結果として、そういうこともあるということです。
XMLの文書化にも同様の理論的背景があるんじゃないと思っています。もっと抽象的に言えば、XMLという具体的な技術に拘らず、もっと一般的に情報をまとめ上げるときに、どうすべきなのかという指針と言ってもよいのです。
いろいろあるよ、一言では語れないよ、というなら勿論それでも良いのです。こういう大きな問題を一言で語るのは難しいでしょう。その「いろいろある」というのを、具体的に知りたいのです。大きな問題を細かく分割していくことで扱いやすくなっていくはずだからです。
「3章 情報のモデル化」において「例3-1 小切手帳の文書例」から一部を抜粋します。
<支出 分類="消耗品">これは「XMLとはこういうもの」を示す例にすぎないので、この妥当性を議論するのはお門違いかと思いますが、ちょっと考えてみます。
<金額> 10.58</金額>
<日付><年>2002</年><月>1</月><日>10</日></日付>
<支払い先> Exxon Saugus</支払い先>
<明細>ガソリン</明細>
</支出>
「支出」というものの中に「金額」、「日付」、「支払い先」、「明細」があります。しかし「分類」は「支出」の一属性として扱われています。何故でしょう。「分類」も「金額」などと同じ副項目に落としてはいけないのでしょうか。また逆に「金額」などを「支出」の属性としてはいけないのでしょうか。
これは何かの方針に基づく決め事なのではないかと想像しています。その方針（または思想）に応じて決めれば良いのでしょう。何かが絶対的に正しく、何かがそうではないというわけではないのだと思います。
ひとつの類推として、RDBにおける正規化の理論が思いつきます。理論的に正規化すべきではあるけれど、実装などの都合で正規化をくずすことも無いわけではないようです。これはRDBの知識に欠けた担当者が、やみくもに実現するという情けない理由ではなく、それなりの判断の結果として、そういうこともあるということです。
XMLの文書化にも同様の理論的背景があるんじゃないと思っています。もっと抽象的に言えば、XMLという具体的な技術に拘らず、もっと一般的に情報をまとめ上げるときに、どうすべきなのかという指針と言ってもよいのです。
いろいろあるよ、一言では語れないよ、というなら勿論それでも良いのです。こういう大きな問題を一言で語るのは難しいでしょう。その「いろいろある」というのを、具体的に知りたいのです。大きな問題を細かく分割していくことで扱いやすくなっていくはずだからです。
FAQって本当に「よくある」質問なのか
FAQ（Frequently Asked Questions）とは「よくある(あるいはあると想定される)質問とその回答」とウィキペディアで説明されています。冗談でFAQのAはAskedじゃなくてAnswered（Frequently Answered Questions、要するに「よく答えている質問」）だと言ったりすることもあります。
しかし実際のところ、FAQと称される質問がくるのでしょうか。
『Subversion によるバージョン管理』（Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato）では「まえがき」で次のように書いています。
質問者の問いかけは「アナログ」的で想定外の振れ幅で投げかけられると思いますが、回答者が受け止めるのは想定している「FAQ」で量子化した結果の応答でしかないでしょう。両者の認識範囲（常識レベルと言ってもいいです）が近ければ、この方法でも概ね問題にはならないとおもいます。しかしその前提が崩れれば、かみ合わない応答になるでしょう。
究極には異文化交流にはこのような側面があると思います。自分の常識が決して相手にも常識とは限らないのです。かみ合わない応答に時間を費やすのは苦しい体験です。同じ常識が通じる範囲に閉じこもりたくなります。しかし内向きになればなるほど、常識範囲は狭くなっていくでしょう。
無理をしてでも外の世界に出ていかなければならないと感じるところです。
しかし実際のところ、FAQと称される質問がくるのでしょうか。
『Subversion によるバージョン管理』（Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato）では「まえがき」で次のように書いています。
だめな「よくある質問集(FAQ)」には実際にユーザが聞きたいことではなく、著者がユーザに聞いて欲しいことが書いてあります。おそらく経験があるでしょう:この文章は、本気半分、冗談半分というところかもしれません。でも組織にしろ個人にしろ、質問や問い合わせを受けて回答するような行為を生業としている場合、「本当に」よくある質問というのが現実にあるはずですが、「おそらく尋ねられる筈だと想定している」よくある質問に置き換えて鸚鵡返しで対応しているんじゃないだろうか、と思うことがあります。
Q: チームの生産性を最大にするにはどうやってGlorbo ソフト社のXYZ を使えばよいのでしょう?
A: 顧客の多くは私たちの特許であるオフィスグループウェアテクノロジを通じた生産性の向上の方法について知りたいと考えています。答えは簡単: まず「ファイル」メニューをクリックし、「生産性向上」メニューを選択しましょう、それから…
このようなFAQ の問題点は、文字通りFAQ でも何でもないというところです。技術サポートに電話をして「どうやったら生産性が最大になるのでしょうか?」などと聞く人は一人もいないのです。
質問者の問いかけは「アナログ」的で想定外の振れ幅で投げかけられると思いますが、回答者が受け止めるのは想定している「FAQ」で量子化した結果の応答でしかないでしょう。両者の認識範囲（常識レベルと言ってもいいです）が近ければ、この方法でも概ね問題にはならないとおもいます。しかしその前提が崩れれば、かみ合わない応答になるでしょう。
究極には異文化交流にはこのような側面があると思います。自分の常識が決して相手にも常識とは限らないのです。かみ合わない応答に時間を費やすのは苦しい体験です。同じ常識が通じる範囲に閉じこもりたくなります。しかし内向きになればなるほど、常識範囲は狭くなっていくでしょう。
無理をしてでも外の世界に出ていかなければならないと感じるところです。
野良猫のフンと立ちションの相違点
自宅でふと庭に目を移すと野良猫が歩いてくるのが見えました。突如立ち止まると前脚で地面を掘りはじめるかと思いや、どうもフンをしているようです。自宅の庭では、もう何年も野良猫のフン害に悩まされています。対策しても他の場所にされてしまうし、おさまったかと思えば、いつの間にか再び始まったりして、根本的に解決できずにいます。
ところが今回は様子をうかがっていると、場所を変えて何か所でも同じ行為を繰り返しています。これは要するに「マーキング行為」というものではないかと思います。便意をもよおしたのではなくて（そういう意図も多少はあるかもしれませんが）、自分の縄張りを主張しているのでしょう。
話は変わり、近所を歩いていたら堤防下の物陰で年配の男性が立ちションをしていました。これは流石に「マーキング行為」ではなく、たんに尿意をもよおしただけでしょう。
人間だって、何億年も前の人類の進化の途上では「マーキング行為」をしていたんじゃないかと思いますが（違うのかな？）、縄張り主張の意図は消えて、ただの排泄校異に変化しています。尾籠な話ではありますが、マーキング行為を必要としなくなった人類進化の要因とは何だったのか、ちょっと気になりました。
ところが今回は様子をうかがっていると、場所を変えて何か所でも同じ行為を繰り返しています。これは要するに「マーキング行為」というものではないかと思います。便意をもよおしたのではなくて（そういう意図も多少はあるかもしれませんが）、自分の縄張りを主張しているのでしょう。
話は変わり、近所を歩いていたら堤防下の物陰で年配の男性が立ちションをしていました。これは流石に「マーキング行為」ではなく、たんに尿意をもよおしただけでしょう。
人間だって、何億年も前の人類の進化の途上では「マーキング行為」をしていたんじゃないかと思いますが（違うのかな？）、縄張り主張の意図は消えて、ただの排泄校異に変化しています。尾籠な話ではありますが、マーキング行為を必要としなくなった人類進化の要因とは何だったのか、ちょっと気になりました。
2017-02-17
NetBSDのログイン環境の初期設定に関わるファイル群
dynabook SS SX/15AにNetBSD/i386をインストールして環境を構築してきましたが、ログインの仕方の違いや、ログインするユーザの違いによって、環境が微妙に異なっているので困っていました。具体的には、次のようになっています。
rootのシェルをCSH系にするというのも一案ではありますが、伝統的にrootはSH(1)を使ってきた（BASHですらなく）という経緯があるので、シェルを統一してしまうのは気が引けます。アカウントやログイン経路なども、何かに限定するわけにもいきません。
ここは覚悟を決めて、統一した環境を作ることを考えてみます。SH(1)にしろCSH(1)にしろ、初期設定を行うファイルは、全部使うかどうかは別にして、次のようになっています。これらを組み合わせて計4種類のファイルがあります
環境を設定するための基本方針を次のように定めました。
XDMはホームディレクトリにある.xsessionというファイルを使って初期設定をおこないます。このファイルは実行ビットが立っていてもいなくても構わないのですが、実行ビットが落ちている場合にはSH(1)のスクリプトとして扱われます。そうなるとユーザがCSH系のシェルに切り替えている場合、環境変数などをSH系としてもCSH系としても定義しておくことになり、重複して環境をメンテナンスするのは間違いのもとです。
この問題を解決するためにホームディレクトリにある.xsessionはユーザで使っているシェルにあわせることにしました。CSH系を利用するのであれば、このファイルもCSHのスクリプトとして書いておきます。さらに実行ビットを立てておかないと、shを介して実行されてしまいますから、忘れずにchmodしておきます。そして~/.xsessionの最初の方で/etcやホームディレクトリにあるシェル用の環境設定ファイルを読み込むようにしておきます。
以上のようにしておけば、環境を設定するための情報をあちこちに書かずにすむようになると思います。
上述した環境を整えている段階で/etc/login.confという設定ファイルがあるのも気にかかっていました。このファイルでも環境変数などを設定できるので、ここで設定しておいた方が良いのだろうかと悩みました。結局このファイルは使わない決断をしましたが、その理由はXDM経由でログインした場合の扱いが不明だったことです。XDMやLightDMなどを利用した場合に/etc/login.confで設定してはずの内容が使われないのであれば無駄になると思ったのです。
そもそも/etc/login.confが存在する歴史的経緯や、どのような利用方法を想定しているのかが分からないので、今回は使わないこととしました。
- アカウントは、rootと、2つの非特権ユーザがあり、合計で3つのアカウントがある。
- シェルには、rootはshだが、非特権ユーザはtcsh（場合によってはcsh）を使う。
- 各アカウントには、xdm経由でログインする場合と、TeratermやSSHなどの端末経由でログインする場合がある。
- xdmでログインした場合、twmを利用するアカウントと、MATEを利用するアカウントがある。
rootのシェルをCSH系にするというのも一案ではありますが、伝統的にrootはSH(1)を使ってきた（BASHですらなく）という経緯があるので、シェルを統一してしまうのは気が引けます。アカウントやログイン経路なども、何かに限定するわけにもいきません。
ここは覚悟を決めて、統一した環境を作ることを考えてみます。SH(1)にしろCSH(1)にしろ、初期設定を行うファイルは、全部使うかどうかは別にして、次のようになっています。これらを組み合わせて計4種類のファイルがあります
- /etcに置かれるシステム全体のものと、ホームディレクトリに置かれるユーザ固有のもの
- ログインシェルの場合に呼び出されるものと、サブシェルでも呼び出されるもの
環境を設定するための基本方針を次のように定めました。
- 基本的に/etcにあるファイルで設定をおこなう。
- ユーザ固有の設定がある場合のみホームディレクトリのファイルで設定する。従ってユーザ固有の設定がなければ、ファイルは空のままになる。
- 環境変数PATHやLANGのような情報はログインシェルの場合に読み込まれるファイルで設定し、シェル変数やコマンド・エイリアスなどはサブシェルでも読み込まれるファイルで設定する。
XDMはホームディレクトリにある.xsessionというファイルを使って初期設定をおこないます。このファイルは実行ビットが立っていてもいなくても構わないのですが、実行ビットが落ちている場合にはSH(1)のスクリプトとして扱われます。そうなるとユーザがCSH系のシェルに切り替えている場合、環境変数などをSH系としてもCSH系としても定義しておくことになり、重複して環境をメンテナンスするのは間違いのもとです。
この問題を解決するためにホームディレクトリにある.xsessionはユーザで使っているシェルにあわせることにしました。CSH系を利用するのであれば、このファイルもCSHのスクリプトとして書いておきます。さらに実行ビットを立てておかないと、shを介して実行されてしまいますから、忘れずにchmodしておきます。そして~/.xsessionの最初の方で/etcやホームディレクトリにあるシェル用の環境設定ファイルを読み込むようにしておきます。
以上のようにしておけば、環境を設定するための情報をあちこちに書かずにすむようになると思います。
上述した環境を整えている段階で/etc/login.confという設定ファイルがあるのも気にかかっていました。このファイルでも環境変数などを設定できるので、ここで設定しておいた方が良いのだろうかと悩みました。結局このファイルは使わない決断をしましたが、その理由はXDM経由でログインした場合の扱いが不明だったことです。XDMやLightDMなどを利用した場合に/etc/login.confで設定してはずの内容が使われないのであれば無駄になると思ったのです。
そもそも/etc/login.confが存在する歴史的経緯や、どのような利用方法を想定しているのかが分からないので、今回は使わないこととしました。
NetBSDのSH(1)内蔵コマンドcdにおける拡張機能
NetBSDのSH(1)のマニュアルをみていると内蔵コマンドcdが拡張されていることに気が付きました。マニュアルでは次のような構文になっています。
いろいろと試行錯誤してみたところ、次のようなことができるようです。例えば/usr/pkgsrcのように同一階層のディレクトリに多くのサブディレクトリが並んでいる場合を考えます。もしカレントディレクトリが/usr/pkgsrc/mailだったとすると、次のようなコマンドを打つことで/usr/pkgsrc/netに移ることができるようです。
このような機能があれば便利な状況もあると思いますが、他のOSでは使えないため手が覚えてしまうと困ったことになりそうです。ただしNetBSDを利用するのであれば、覚えておいても良いでしょう。
cd [-P] [directory [replace]]replaceという部分が拡張されたところです。マニュアルでは「If replace is specified, then the new directory name is generated by replacing the first occurrence of directory in the current directory name with replace.」と説明されていますが、具体的にどういうことなのか、よくわかりません。
いろいろと試行錯誤してみたところ、次のようなことができるようです。例えば/usr/pkgsrcのように同一階層のディレクトリに多くのサブディレクトリが並んでいる場合を考えます。もしカレントディレクトリが/usr/pkgsrc/mailだったとすると、次のようなコマンドを打つことで/usr/pkgsrc/netに移ることができるようです。
cd mail netこの機能はFreeBSDのSH(1)やGNU BASHなどには無いようですが、ZSHには似たような機能があるそうです。
このような機能があれば便利な状況もあると思いますが、他のOSでは使えないため手が覚えてしまうと困ったことになりそうです。ただしNetBSDを利用するのであれば、覚えておいても良いでしょう。
NHK「空想大河ドラマ 小田信夫」
NHKで「空想大河ドラマ小田信夫」というドラマを放送しているそうです。2017年2月4日（土）から全4回です。Webで話題になっているのを見て知ったので、初回は見逃しました。面白いです。NHKを代表する番組である「大河ドラマ」（今年は、おんな城主 直虎ですが）をパロディーにしています。その発想は以前にやはりNHKで放送されていた「サラリーマンNEO」の初期の頃の作品を思わせます。
放送が深夜時間帯ですし、全4回で長くはないので、視聴者の反応を探る目的が強そうな作品ですが、その割には本物の大河ドラマと見劣りしないほど、しっかり作られています。本物の大河ドラマで何度も繰り返し取り上げられてきた戦国時代を扱っているので、舞台セットや衣装なども準備するのは（現代劇に比べて）大変だと思いますが、結構ちゃんとしています。オープニング、ナレーション、エンディングも、本物そっくりです。そこがまた笑いを誘います。
近年の大河ドラマは番組の最後に（大河ドラマに由来の土地を訪ねる）「○△紀行」というミニ番組を流しているので、空想大河ドラマでもやって欲しいところです。
放送が深夜時間帯ですし、全4回で長くはないので、視聴者の反応を探る目的が強そうな作品ですが、その割には本物の大河ドラマと見劣りしないほど、しっかり作られています。本物の大河ドラマで何度も繰り返し取り上げられてきた戦国時代を扱っているので、舞台セットや衣装なども準備するのは（現代劇に比べて）大変だと思いますが、結構ちゃんとしています。オープニング、ナレーション、エンディングも、本物そっくりです。そこがまた笑いを誘います。
近年の大河ドラマは番組の最後に（大河ドラマに由来の土地を訪ねる）「○△紀行」というミニ番組を流しているので、空想大河ドラマでもやって欲しいところです。
2017-02-15
簡体字と旧仮名遣い
The Japan Times STの2017年2月10日号にTan Ying Zhenさんのエッセイ「Happy learning!」が掲載されていました。著者はシンガポール出身とのことなのですが、中国本土出身の中国系なのかもしれません。そう思ったのはイラストに簡体字が使われていたからです。例えば「笑口常开」（これは「Keep smiling!」という意味だそうです）のような簡体字を用いた中国語が描かれていました。中国系であったとしても台湾出身ならば繁体字をつかうのではないかと思いました。
簡体字はウィキペディアでは「1950年代に中華人民共和国で制定された」と説明しています。日本でも戦前まで使われていた漢字の字体を簡略化しましたが、簡体字はもっと大胆です。一方で台湾では今日でも昔と同じ字体（これが繁体字）を使っているので、日本と台湾と中国本土で三者三様です。
シンガポールの中国出身者の滞在時期にもよると思いますが、簡体字が使われる前からシンガポールに在住していた中国系シンガポール人であれば簡体字の教育は受けていないでしょう。おそらく繁体字を用いた教育を受けているはずです。しかし中国本土で簡体字が使われるようになると、 その影響を受けざるをえないと思います。次第に簡体字を使うようになっていくのではないでしょうか。それでも幼少期に受けた教育が繁体字をベースにしているはずなので、その影響で、たまには文章の中に繁体字が姿を見せることがあるのではないかと思います。
これは日本語の教育が戦前の旧仮名遣いから戦後の現代仮名遣いに切り替わったことに似ていると思います。旧仮名遣いの頃の教育を受けた世代は、戦後になって時代の趨勢が現代仮名遣いになると、自らの書く文章も現代仮名遣いに切り替えることになりますが、何かの拍子に文章中に旧仮名遣いが姿を見せてしまうことがあります。「～でせうか」とか無意識に書いてしまうことが、極稀にあるようです。
幼少期に学んだことは、普段抑えられていても、何かの拍子に顔を出すことがあるようです。
簡体字はウィキペディアでは「1950年代に中華人民共和国で制定された」と説明しています。日本でも戦前まで使われていた漢字の字体を簡略化しましたが、簡体字はもっと大胆です。一方で台湾では今日でも昔と同じ字体（これが繁体字）を使っているので、日本と台湾と中国本土で三者三様です。
シンガポールの中国出身者の滞在時期にもよると思いますが、簡体字が使われる前からシンガポールに在住していた中国系シンガポール人であれば簡体字の教育は受けていないでしょう。おそらく繁体字を用いた教育を受けているはずです。しかし中国本土で簡体字が使われるようになると、 その影響を受けざるをえないと思います。次第に簡体字を使うようになっていくのではないでしょうか。それでも幼少期に受けた教育が繁体字をベースにしているはずなので、その影響で、たまには文章の中に繁体字が姿を見せることがあるのではないかと思います。
これは日本語の教育が戦前の旧仮名遣いから戦後の現代仮名遣いに切り替わったことに似ていると思います。旧仮名遣いの頃の教育を受けた世代は、戦後になって時代の趨勢が現代仮名遣いになると、自らの書く文章も現代仮名遣いに切り替えることになりますが、何かの拍子に文章中に旧仮名遣いが姿を見せてしまうことがあります。「～でせうか」とか無意識に書いてしまうことが、極稀にあるようです。
幼少期に学んだことは、普段抑えられていても、何かの拍子に顔を出すことがあるようです。
環境変数SHELLの役割とは？
NetBSDの場合、新しくアカウント作るとホームディレクトリの下にはテンプレートからコピーされたファイルが置かれます。そのうち.loginには次のような記述が含まれています。
環境変数 SHELLが未定義だった場合/bin/cshという内容で定義している訳ですが、これは何故このようなことをしているのでしょうか？
疑問点は2つあります。
if ( ! $?SHELL ) then
setenv SHELL /bin/csh
endif
環境変数 SHELLが未定義だった場合/bin/cshという内容で定義している訳ですが、これは何故このようなことをしているのでしょうか？
疑問点は2つあります。
- この記述は~/.loginにありますから、cshに固有な初期設定ファイルです。このファイルが処理されている時に「環境変数SHELLが未定義である」のは一体どのような状況を想定しているのでしょうか？
- 環境変数SHELLが未定義の場合どういう問題が起きるのでしょうか？ 何か困ることがあるのでしょうか。例えば環境変数PATHが未定義だとすれば、コマンドが見つけられなくなってしまうわけです。しかし環境変数SHELLが未定であったとしても、問題がおきる状況というのが想像できません。
NetBSDのホームディレクトリに置くログイン環境設定ファイルについて
dynabook SS SX/15Aで動作させようとしているNetBSD/i386の環境設定について考えてみます。これまでは、そもそもNetBSD/i386の動作に問題がないか、使おうと考えているアプリケーションに支障がないか等を主に注意してみてきました。動くかどうかが問題だったので、詳細な動作環境の微調整は後回しにしてきました。しかし動作自体には問題がないことが確認されつつあるので、今後はお留守になっていた動作環境の設定に気を配っていこうと思います。
まず最初に設定しておきたいのは、端末を開いたときにシェルの初期設定をおこなうためのファイル群です。要するにshなら.profileであったり、cshなら.cshrcとか.loginのことです。
NetBSDをインストールしたノートPCは多人数で共有するわけではありませんが、そうかと言って何でもrootアカウントだけで利用するつもりはありません。普段は非特権ユーザを作っておいて、そちらを使うつもりです。
そうなるとユーザによってシェルが異なってくるため、どのユーザであっても同じように環境変数などが設定されるようにしておくためには、気を配らなければならないことがあると考えています。
さらにcshでは.cshrcと.loginの違いを意識しておかなければなりませんし、ユーザを越えてシステム全体に影響する/etc/csh.cshrcや/etc/csh.loginというファイルも使うことになるかもしれません。しかもcshではなくてtcshを利用しようとも考えているので、さらに考慮しておく事柄が多くなります。
また外部PCからTeratermでログインした場合は.loginが読み込まれますが、 xdmからログインすると.lgoinの出番はなくて.xsessionに必要な環境変数を定義しておかなければならなくなります。
ここまで考えてきたような多様な状況やファイルを考えるのは、面倒と言えば面倒です。結局は自分ひとりで使うマシンなので、 あちこちのファイルを操作しなくても構わないんじゃないかとも考えるのですが、ここはじっくり考えてみたいと思います。いろいろとファイルが分かれているのには（多分）それなりに理由があるはずなので、とりあえずは全体像を理解しておこうと思います。
まず最初に設定しておきたいのは、端末を開いたときにシェルの初期設定をおこなうためのファイル群です。要するにshなら.profileであったり、cshなら.cshrcとか.loginのことです。
NetBSDをインストールしたノートPCは多人数で共有するわけではありませんが、そうかと言って何でもrootアカウントだけで利用するつもりはありません。普段は非特権ユーザを作っておいて、そちらを使うつもりです。
そうなるとユーザによってシェルが異なってくるため、どのユーザであっても同じように環境変数などが設定されるようにしておくためには、気を配らなければならないことがあると考えています。
さらにcshでは.cshrcと.loginの違いを意識しておかなければなりませんし、ユーザを越えてシステム全体に影響する/etc/csh.cshrcや/etc/csh.loginというファイルも使うことになるかもしれません。しかもcshではなくてtcshを利用しようとも考えているので、さらに考慮しておく事柄が多くなります。
また外部PCからTeratermでログインした場合は.loginが読み込まれますが、 xdmからログインすると.lgoinの出番はなくて.xsessionに必要な環境変数を定義しておかなければならなくなります。
ここまで考えてきたような多様な状況やファイルを考えるのは、面倒と言えば面倒です。結局は自分ひとりで使うマシンなので、 あちこちのファイルを操作しなくても構わないんじゃないかとも考えるのですが、ここはじっくり考えてみたいと思います。いろいろとファイルが分かれているのには（多分）それなりに理由があるはずなので、とりあえずは全体像を理解しておこうと思います。
2017-02-14
映画「この世界の片隅に」
映画「この世界の片隅に」を観ました。以前から気になっていたのですが、なかなか機会がありませんでした。公開後の評判も良く、予想以上に長期に亘って上映されています。しかしこのままいつまでも上映され続けるわけではないでしょうし、あまりにも遠くの映画館でしかみられなくなるのも困るので、腰を上げることにしました。
よくある戦争映画とは違い、直接的な描写や台詞で物語をすすめるのではなく、間接的に心情を伝えていくので、その描写の奥にあるものを受け止められるかどうかは自分自身にかかっています。画面の一部であったり、台詞の断片を、何気なしに見過ごしてしまったり、聞き逃してしまっても、もし何も気付かないとしたら、作品が訴えようとしていることが分かっていないのかもしれません。
とても良い作品だったと思います。主役の声もイメージとピッタリで、作品をより引き立てていると思います。
よくある戦争映画とは違い、直接的な描写や台詞で物語をすすめるのではなく、間接的に心情を伝えていくので、その描写の奥にあるものを受け止められるかどうかは自分自身にかかっています。画面の一部であったり、台詞の断片を、何気なしに見過ごしてしまったり、聞き逃してしまっても、もし何も気付かないとしたら、作品が訴えようとしていることが分かっていないのかもしれません。
とても良い作品だったと思います。主役の声もイメージとピッタリで、作品をより引き立てていると思います。
2017-02-13
pkg_rolling-replace
pkgsrcからインストールしたパッケージを更新するために自作スクリプトを利用しようと思いましたが、どうも調子が良くありません。気になった問題点は次のようなところです。
これらの問題を頑張って解決するように自作スクリプトを改良するよりも、既に利用されているツールを使う方が安心感があると思うようになりました。pkgsrcの中にpkgtools/pkg_rolling-replaceというものがあるので使ってみました。
使ってみたところ、今後のpkgsrcの更新はpkg_rolling-replaceを使っていこうという気になりました。ただし若干問題点があるので注意は必要です。
依存関係を辿って多くのパッケージをビルドし直すために、とても時間がかかります。もしビルド中にエラーが出てしまうとシステムの不整合がおきる可能性が残ります。これは最終的にpkg_rolling-replaceが正常終了してくれれば整合性が保たれることになりますが、途中でエラーが出たら放置しておいてはいけません。このことは「how to upgrade packages」でも指摘されています。
今回の実行中には次のようなエラーが出てしまいました。出力されているメッセージだけを見るとディレクトリを変えられなかったというだけで、何が問題なのか見えません。どうやら数か月前にdevel/gmockが廃止され、devel/googletestに統合されたようです。既にdevel/gmockがインストールされていたので、pkg_rolling-replaceは更新対象としようとしてエラーが出てしまったようです。pkg_deleteでgmockを削除しようとしたら、依存関係があるため単独では消せませんでした。-fオプションを指定して強制的に削除して、あとはpkg_rolling-replaceの処理にまかせました。
またpkgsrcの各パッケージが必要とするdistfilesをダウンロードするため/usr/pkgsrc/mk/defaults/mk.confから日本固有の設定を/etc/mk.confに転記しておいたのですが、こうするとパッケージによってはdistfilesをダウンロードできなくてビルドが止まってしまいました。この設定を調整して問題がないようにすべきところでしょうが、今後の課題とします。
- 処理中にエラーが出た場合、運が悪いと依存するパッケージの一部が削除済みになっていて、復活させる手段がない。
- 依存するパッケージを何度もビルドしているような気がして、効率が悪そうな気がする。
これらの問題を頑張って解決するように自作スクリプトを改良するよりも、既に利用されているツールを使う方が安心感があると思うようになりました。pkgsrcの中にpkgtools/pkg_rolling-replaceというものがあるので使ってみました。
使ってみたところ、今後のpkgsrcの更新はpkg_rolling-replaceを使っていこうという気になりました。ただし若干問題点があるので注意は必要です。
依存関係を辿って多くのパッケージをビルドし直すために、とても時間がかかります。もしビルド中にエラーが出てしまうとシステムの不整合がおきる可能性が残ります。これは最終的にpkg_rolling-replaceが正常終了してくれれば整合性が保たれることになりますが、途中でエラーが出たら放置しておいてはいけません。このことは「how to upgrade packages」でも指摘されています。
Because pkg_rolling-replace just invokes make replace, the problems of ABI changes with make replace apply to pkg_rolling-replace, and the system will be in a state which might be inconsistent while pkg_rolling-replace is executing. But, by the time pkg_rolling-replace has successfully finished, the system will be consistent because every package that has a depending package 'make replaced' out from under it will be marked unsafe_depends, and then replaced itself. This replace "rolls" up the dependency tree because pkg_rolling-replace sorts the packages by dependency and replaces the earliest needing-rebuild package first.
今回の実行中には次のようなエラーが出てしまいました。出力されているメッセージだけを見るとディレクトリを変えられなかったというだけで、何が問題なのか見えません。どうやら数か月前にdevel/gmockが廃止され、devel/googletestに統合されたようです。既にdevel/gmockがインストールされていたので、pkg_rolling-replaceは更新対象としようとしてエラーが出てしまったようです。pkg_deleteでgmockを削除しようとしたら、依存関係があるため単独では消せませんでした。-fオプションを指定して強制的に削除して、あとはpkg_rolling-replaceの処理にまかせました。
RR> Checking if gmock has new depends...
cd: can't cd to /usr/pkgsrc/devel/gmock
make: don't know how to make show-depends. Stop
またpkgsrcの各パッケージが必要とするdistfilesをダウンロードするため/usr/pkgsrc/mk/defaults/mk.confから日本固有の設定を/etc/mk.confに転記しておいたのですが、こうするとパッケージによってはdistfilesをダウンロードできなくてビルドが止まってしまいました。この設定を調整して問題がないようにすべきところでしょうが、今後の課題とします。
2017-02-11
「Think global, act local」に思う
「Think global, act local」という標語があります。この言葉は、ずいぶん前に放送大学教養学部に在学していた時に環境問題に関する面接授業（放送大学では一般に「スクーリング」と呼ばれている形態の授業を「面接授業」と呼んでいます）を受講した時に学びました。その意図するところは「地球規模で思考し、地域的に活動する」ということです。英語版Wikipediaには「Think globally, act locally」というエントリがありますが、冒頭で以下のように記しているので要するに同じことです。
グローバルな活動がおこなわれる現代社会には国境はないと発言する人もいます。インターネットを使えば世界中の情報を瞬時にアクセスできるので、まさにグローバルな社会を実感します。金融の世界などでも、どこかの市場の影響があっという間に世界に拡がるので、グローバルに取引されていることが窺えます。
個人的な経験ですが、古本の洋書を購入するため「AbeBooks.com」というサイトを利用しています。望む書籍のタイトルなどを指定すると全世界の古書店（対象となるのはAbeBooksと提携している書店だけですが）を対象に検索してくれます。これだけでも十分にグローバルであることを実感しますが、さらに驚いたのは、ある米国の古書店に注文を出したらヨーロッパの倉庫から発送されてきたという事例がありました。
このような活動が日々の生活で当たり前となっていれば、時代の趨勢はグローバル化であり、無国境化であり、全てがフラットな社会こそ未来の姿だと思うことでしょう。
さて、数年前に「超高速！参勤交代」という娯楽映画を観ました。続編もあり、時代劇のスタイルをとっており、時代考証もされていますが、これで歴史を学ぶものではなく、純粋に楽しめばよい作品です。江戸時代の小藩が巻き込まれた事件（もちろん創作です）をコミカルに描写していますが、見所のひとつは藩士たちの郷土愛の強さです。ある意味で現代のグローバル化の対極に位置しているかと思わせるような様相です。藩士たちにとって世界とは自分の属する藩領であり、一生をそこで終えるのが幸福な終末だったことでしょう。
江戸時代以降の歴史を知っている人間からすれば、鎖国をやめ世界に門戸を開き、そして今日のグローバル社会がある訳です。当時の藩士たちは自分の属する藩の中しか知らず（あと多少江戸も） 、広い世界を知らずに一生を終えるわけですから、お気の毒な事だと思うかもしれませんが、はたしてそうでしょうか。
現代に生きる我々は、江戸時代のように土地に縛られておらず、何処でも好きなところに好きな時に移ることができます。可能性としては、日本国内に留まらず、世界中のどこにでも移ることができるはずです。それは諸手を挙げて喜ぶべきことなのでしょうか。そうであれば何故に映画「レオン」の最終シーンのような描写がなされるのでしょう。
世界の人口は70億人を超えており、今後100億人になろうともしています。人口が爆発的に増えていますが、第2次世界大戦の頃の世界の人口は20数億人でしたし、 19世紀初頭の世界の人口は10億人程度でした。現在の中国の人口よりも全世界の人口が少なかったというのは驚きです。
グローバル社会に生きる私たちは、昔の人達と比べて、これほど多くの人間に関心を寄せるほど心が広くなっていると言えるでしょうか。世界を股にかけて活動しているとしても、視野に入っているのは極めて限定された範囲なのではないでしょうか。冒頭の標語を捩れば「Think local, act global」に逆転していませんか。
つい先ごろ、世界の富豪62人の資産が、全世界の人口の半分の富と同じだという報道がありました。「グローバル社会」を謳歌する富豪たちがいる一方で、「グローバル社会」という名のもとに経済的に追い詰められる膨大な数の人達が生まれてしまっています。このままでいくと、世界のことなんかどうでもよい、自分さえよければいいという風潮が加速してしまいます。意識が内向きになればなるほど、他人がどうなろうと気にならないのかもしれませんが、これは六道のなかのどれになるのでしょうか。あわせてニーメラーの言葉も思い起こしたいと思います。
The phrase "Think globally, act locally" or "Think global, act local" has been used in various contexts, including planning, environment, education, mathematics, and business.
グローバルな活動がおこなわれる現代社会には国境はないと発言する人もいます。インターネットを使えば世界中の情報を瞬時にアクセスできるので、まさにグローバルな社会を実感します。金融の世界などでも、どこかの市場の影響があっという間に世界に拡がるので、グローバルに取引されていることが窺えます。
個人的な経験ですが、古本の洋書を購入するため「AbeBooks.com」というサイトを利用しています。望む書籍のタイトルなどを指定すると全世界の古書店（対象となるのはAbeBooksと提携している書店だけですが）を対象に検索してくれます。これだけでも十分にグローバルであることを実感しますが、さらに驚いたのは、ある米国の古書店に注文を出したらヨーロッパの倉庫から発送されてきたという事例がありました。
このような活動が日々の生活で当たり前となっていれば、時代の趨勢はグローバル化であり、無国境化であり、全てがフラットな社会こそ未来の姿だと思うことでしょう。
さて、数年前に「超高速！参勤交代」という娯楽映画を観ました。続編もあり、時代劇のスタイルをとっており、時代考証もされていますが、これで歴史を学ぶものではなく、純粋に楽しめばよい作品です。江戸時代の小藩が巻き込まれた事件（もちろん創作です）をコミカルに描写していますが、見所のひとつは藩士たちの郷土愛の強さです。ある意味で現代のグローバル化の対極に位置しているかと思わせるような様相です。藩士たちにとって世界とは自分の属する藩領であり、一生をそこで終えるのが幸福な終末だったことでしょう。
江戸時代以降の歴史を知っている人間からすれば、鎖国をやめ世界に門戸を開き、そして今日のグローバル社会がある訳です。当時の藩士たちは自分の属する藩の中しか知らず（あと多少江戸も） 、広い世界を知らずに一生を終えるわけですから、お気の毒な事だと思うかもしれませんが、はたしてそうでしょうか。
現代に生きる我々は、江戸時代のように土地に縛られておらず、何処でも好きなところに好きな時に移ることができます。可能性としては、日本国内に留まらず、世界中のどこにでも移ることができるはずです。それは諸手を挙げて喜ぶべきことなのでしょうか。そうであれば何故に映画「レオン」の最終シーンのような描写がなされるのでしょう。
世界の人口は70億人を超えており、今後100億人になろうともしています。人口が爆発的に増えていますが、第2次世界大戦の頃の世界の人口は20数億人でしたし、 19世紀初頭の世界の人口は10億人程度でした。現在の中国の人口よりも全世界の人口が少なかったというのは驚きです。
グローバル社会に生きる私たちは、昔の人達と比べて、これほど多くの人間に関心を寄せるほど心が広くなっていると言えるでしょうか。世界を股にかけて活動しているとしても、視野に入っているのは極めて限定された範囲なのではないでしょうか。冒頭の標語を捩れば「Think local, act global」に逆転していませんか。
つい先ごろ、世界の富豪62人の資産が、全世界の人口の半分の富と同じだという報道がありました。「グローバル社会」を謳歌する富豪たちがいる一方で、「グローバル社会」という名のもとに経済的に追い詰められる膨大な数の人達が生まれてしまっています。このままでいくと、世界のことなんかどうでもよい、自分さえよければいいという風潮が加速してしまいます。意識が内向きになればなるほど、他人がどうなろうと気にならないのかもしれませんが、これは六道のなかのどれになるのでしょうか。あわせてニーメラーの言葉も思い起こしたいと思います。
2017-02-10
鉄道模型の運転速度は早すぎる
鉄道模型にはNゲージ（150分の1）やHOゲージ（80分の1）があります。これよりも小さいZゲージ（220分の1）とかOゲージ（43分の1）などもありますが、一般的ではないでしょう。レイアウト（最近はジオラマと呼ばれたりするようですが違和感があります）を作って運転を楽しむにはNゲージの方が良いだろうし、車両の製作を楽しむならHOゲージの方が作りやすいと思います。縮尺が小さくなれば製作しやすくなりますが、出来上がりが大きくなるので、レイアウトを作って運転を楽しむのが極めて難しくなります。
以前から思っていたのですが、鉄道模型を運転しているところを見ていると、スケール感がないような気がします。要するに異常に速度が速いのです。「独楽鼠が走り回っているようだ」と評されることもあるようです。
現実の鉄道車両の平均速度を考えてみます。最高速度はそれなりに出ると思いますが、実際の運用では最高速度で走っているわけではありません。ローカル線の気動車だったりすれば時速50キロメートルくらいでしょう。例示した時速50キロメートルというのは現実世界の速さですが、Nゲージであれば150分の1でなければならないのです。具体的に計算してみましょう。
1時間は60分×60秒より3,600秒です。したがって時速50キロメートルというのは秒速で約0.0139キロメートルになります。鉄道模型の世界ではキロメートルという単位は大きすぎるので、ミリメートルに変換します。1キロメートルは1,000×1,000ミリメートルですから、秒速0.0139キロメートルというのは秒速13,900ミリメートルということです。
ここまでは現実世界の数値（例示した時速50キロメートル）の単位を変えただけですから、ここでNゲージ（150分の1）の世界の値に変更します。秒速13,900ミリメートルを150分の1にすると、秒速92.67ミリメートルという値が出てきます。これが現実世界における時速50キロメートルを、Nゲージの世界で実現すべき速度（秒速92.67ミリメートル）です。
数字だけでは実感がわかないと思います。Yahoo!JAPAN知恵袋で「距離約2300ミリを3.9秒で走行したので、秒速約590ミリ」 という事例を見つけました。これは全速力で動かしているときですが、それでも相当速いです。現実世界なら時速300キロメートルを越えているので、新幹線並みです。鉄道模型では電車だろうが蒸気機関車だろうが、結局は内蔵モータで動いているので、C62型蒸気機関車だって同等速さで走れるでしょう。現実の蒸気機関車ではありえない速さです。銀河鉄道999のC6250なら出せるかもしれません。
鉄道模型の運転速度が速くなりすぎるのは人間の感覚が150分の1になるわけではないからだと思います。仮にスケール感を保って150分の1の速度で運転しようとすると、周囲で見ている人間からは「亀のように遅すぎる」と感じてしまうのでしょう。
また鉄道模型自体の構造的な問題もあるのではないかと思います。鉄道模型の速度制御は車両の内蔵モータにかける電圧を変えることで実現されています。速度をおとすために電圧を下げてしまうと、車輪などの駆動部分の摩擦抵抗に負けてしまって、動けなくなってしまうのです。摩擦抵抗などの物理法則は150分の1にはなってくれないのです。こういう理由で、鉄道模型は現実感を無視した運転にならざるをえないのだと思います。
以前から思っていたのですが、鉄道模型を運転しているところを見ていると、スケール感がないような気がします。要するに異常に速度が速いのです。「独楽鼠が走り回っているようだ」と評されることもあるようです。
現実の鉄道車両の平均速度を考えてみます。最高速度はそれなりに出ると思いますが、実際の運用では最高速度で走っているわけではありません。ローカル線の気動車だったりすれば時速50キロメートルくらいでしょう。例示した時速50キロメートルというのは現実世界の速さですが、Nゲージであれば150分の1でなければならないのです。具体的に計算してみましょう。
1時間は60分×60秒より3,600秒です。したがって時速50キロメートルというのは秒速で約0.0139キロメートルになります。鉄道模型の世界ではキロメートルという単位は大きすぎるので、ミリメートルに変換します。1キロメートルは1,000×1,000ミリメートルですから、秒速0.0139キロメートルというのは秒速13,900ミリメートルということです。
ここまでは現実世界の数値（例示した時速50キロメートル）の単位を変えただけですから、ここでNゲージ（150分の1）の世界の値に変更します。秒速13,900ミリメートルを150分の1にすると、秒速92.67ミリメートルという値が出てきます。これが現実世界における時速50キロメートルを、Nゲージの世界で実現すべき速度（秒速92.67ミリメートル）です。
数字だけでは実感がわかないと思います。Yahoo!JAPAN知恵袋で「距離約2300ミリを3.9秒で走行したので、秒速約590ミリ」 という事例を見つけました。これは全速力で動かしているときですが、それでも相当速いです。現実世界なら時速300キロメートルを越えているので、新幹線並みです。鉄道模型では電車だろうが蒸気機関車だろうが、結局は内蔵モータで動いているので、C62型蒸気機関車だって同等速さで走れるでしょう。現実の蒸気機関車ではありえない速さです。銀河鉄道999のC6250なら出せるかもしれません。
鉄道模型の運転速度が速くなりすぎるのは人間の感覚が150分の1になるわけではないからだと思います。仮にスケール感を保って150分の1の速度で運転しようとすると、周囲で見ている人間からは「亀のように遅すぎる」と感じてしまうのでしょう。
また鉄道模型自体の構造的な問題もあるのではないかと思います。鉄道模型の速度制御は車両の内蔵モータにかける電圧を変えることで実現されています。速度をおとすために電圧を下げてしまうと、車輪などの駆動部分の摩擦抵抗に負けてしまって、動けなくなってしまうのです。摩擦抵抗などの物理法則は150分の1にはなってくれないのです。こういう理由で、鉄道模型は現実感を無視した運転にならざるをえないのだと思います。
問題の解決の見通しと過去の経験
去年の夏頃から、所有しているWindows Vistaがインストールされているdynabook SS SX/15AにNetBSD/i386をインストールして環境を構築してきました。Vistaのサポート期限は2017年4月11日ということですからあと2ヶ月ほどです。現時点では内蔵HDDにはVistaの環境が入ったままになっており、NetBSDの環境はUSBの外付けHDDに作っています。4月前後には内蔵HDDをNetBSDにしようと考えています。
NetBSDの環境を構築してみて、全てが順調という訳でもありませんでした。大小様々な問題がありました。
ここで述べてきたような問題と、その解決の見通しの関係について考えてみたいと思います。但しあまりにも単純な問題（typoとか）ではなく、ある程度深刻な問題を対象とします。
真っ先に考えることは、過去に同じ経験をしたことがあるか否かです。もし過去に（全く）同様の問題を解決していたことがあるなら、その問題で過去に如何に苦しんで解決に時間がかかったとしても、今回は容易に解決できるはずです。そのためには記憶に頼るのではなく、記録を残してあることが重要です。往々にして問題があった時だけ記録を残そうとしがちですが、それでは必要な情報を記録できずに取りこぼす恐れがあります。普段から淡々と記録を残していくべきでしょう。そのために僕はTiddlyWikiを活用しています。
自分で経験したことがなくても、世界中の誰かが経験しているかもしれません。運が良ければ、それをWebで検索できるかもしれないので、検索エンジンで探してみることは大切です。単純な検索キーワードで直ちに見つかることもあるし、いろいろなキーワードを駆使して情報を見つけ出すこともあります。いずれにしても情報が見つかれば幸運ですが、見つからないことの方が多いのです。
しかし仮に見つかったとしても、その情報が直ちに役立つとは限りません。その人物はそれで解決したとしても、こちらの環境とはOSやバージョンなどが異なっているため、同じ方法では解決できないかもしれないのです。ただし解決方法としては役立たないとしても、解決に至るアプローチを示唆する情報としては役立つ可能性があります。自分では気づかなかったアプローチが提示されていることもあるので、決して無駄という訳ではありません。
問題を認識した時、それが解決するまでの見通しは、過去の経験を基準にして考えるしかないでしょう。今までに経験した類の問題ではないならば、その解決までに数日で済むのか、1週間ほどなのか、1ヵ月は見込まなければならないのか、それ以上なのか、はっきり言って、やってみなければわからないというのが正直なところではないかと思います。
かと言って、闇雲に問題に没頭して時間を費やしたところで、問題が解決しないまま時間だけが過ぎていたというのは、避けたいところです。
「やってみないとわからない」ということと、「時間だけが過ぎるのは避けたい」ということのトレードオフはどうしたら良いでしょう。一つの方法として、1週間ほど問題に没頭してみて、問題が解決しそうか見通しをつけるというのは、どうでしょう。もしかしたら1週間もしないうちに問題が解決してしまうかもしれませんし、それならそれで結構なことです。もし問題が解決しなくても、今後の方向性は見えてくるのではないでしょうし、費やす期間も見えてくるでしょう。
個別の問題点は上述した方法論でしのげるとしても、これは職人魂をもった技術寄りの発想です。一方で、全体の工程を管理する側であったり、何かの構築の依頼者側の視点ではどうなるのでしょうか。
問題が解決できるのは大前提だとしても、解決しない問題だったあるのは認められても、何時になったら解決するのか 見通しがたたないと仕事柄（それが管理者の仕事ですから）困るでしょう。
結局のところ、「見通しをたてる」のは「過去の経験」に依存するしかないのでしょう。そうすると、過去に経験したことがないことに対しては見通しが立てられないということです。新技術を採用した場合に発生する未知の問題における「問題の解決見通し」とは 、「ないものねだり」か「希望的観測」にすぎないと思います。そうかもしれませんが、そうも言っていられないならば、未知の問題を既知の問題に分割して持ち込むことでしょう。それが容易な事かどうかは、わかりません。
NetBSDの環境を構築してみて、全てが順調という訳でもありませんでした。大小様々な問題がありました。
- 直近ではサウンドデバイスがカーネルで認識できない問題がありました。カーネルのソースを追いかけて問題個所は絞り込めましたが、どうしたら修正できるのか不明なのでsend-prしました。予想していたとおり放置されていますが、僕個人的には許容できる障害なので、いずれ解決できれば十分です。
- 当初はNetBSDではなくFreeBSDを使うつもりでした。しかしUSB接続メディア（メモリでもHDDでも）から起動できず、簡単には解決できそうもないので、FreeBSDを断念してNetBSDに決めました。
- X11のログイン画面をxdmではなくLightDMを利用しようとしました。コンパイルは出来たものの、設定方法が分からないので、現時点ではxdmを使っています。xdmよりはLightDMの方がログイン画面の見た目がカッコよいと感じています。これはログインする瞬間だけの問題ですが、ゆくゆくはxdmを止めてLightDMにしようと思っています。
- Linuxエミュレーション環境上のLibreOfficeでiBus-Mozcが動きませんでした。Windows環境から移行するにあたり、LibreOfficeで日本語が入らないのは大問題なので解決方法を模索しました。幸いにして、完ぺきではないものの、解決に至りましたが、これは必然ではなく、偶然の賜物だと思っています。
- pkgsrcからMATEをインストールしていたら、一部のパッケージでコンパイルエラーになりました。修正箇所がわかってみると、pkgsrcが提供する枠組みにおける設定不備のように見えます。どうして本家のビルドではエラーになっていないのか、逆に気になるのです。
ここで述べてきたような問題と、その解決の見通しの関係について考えてみたいと思います。但しあまりにも単純な問題（typoとか）ではなく、ある程度深刻な問題を対象とします。
真っ先に考えることは、過去に同じ経験をしたことがあるか否かです。もし過去に（全く）同様の問題を解決していたことがあるなら、その問題で過去に如何に苦しんで解決に時間がかかったとしても、今回は容易に解決できるはずです。そのためには記憶に頼るのではなく、記録を残してあることが重要です。往々にして問題があった時だけ記録を残そうとしがちですが、それでは必要な情報を記録できずに取りこぼす恐れがあります。普段から淡々と記録を残していくべきでしょう。そのために僕はTiddlyWikiを活用しています。
自分で経験したことがなくても、世界中の誰かが経験しているかもしれません。運が良ければ、それをWebで検索できるかもしれないので、検索エンジンで探してみることは大切です。単純な検索キーワードで直ちに見つかることもあるし、いろいろなキーワードを駆使して情報を見つけ出すこともあります。いずれにしても情報が見つかれば幸運ですが、見つからないことの方が多いのです。
しかし仮に見つかったとしても、その情報が直ちに役立つとは限りません。その人物はそれで解決したとしても、こちらの環境とはOSやバージョンなどが異なっているため、同じ方法では解決できないかもしれないのです。ただし解決方法としては役立たないとしても、解決に至るアプローチを示唆する情報としては役立つ可能性があります。自分では気づかなかったアプローチが提示されていることもあるので、決して無駄という訳ではありません。
問題を認識した時、それが解決するまでの見通しは、過去の経験を基準にして考えるしかないでしょう。今までに経験した類の問題ではないならば、その解決までに数日で済むのか、1週間ほどなのか、1ヵ月は見込まなければならないのか、それ以上なのか、はっきり言って、やってみなければわからないというのが正直なところではないかと思います。
かと言って、闇雲に問題に没頭して時間を費やしたところで、問題が解決しないまま時間だけが過ぎていたというのは、避けたいところです。
「やってみないとわからない」ということと、「時間だけが過ぎるのは避けたい」ということのトレードオフはどうしたら良いでしょう。一つの方法として、1週間ほど問題に没頭してみて、問題が解決しそうか見通しをつけるというのは、どうでしょう。もしかしたら1週間もしないうちに問題が解決してしまうかもしれませんし、それならそれで結構なことです。もし問題が解決しなくても、今後の方向性は見えてくるのではないでしょうし、費やす期間も見えてくるでしょう。
個別の問題点は上述した方法論でしのげるとしても、これは職人魂をもった技術寄りの発想です。一方で、全体の工程を管理する側であったり、何かの構築の依頼者側の視点ではどうなるのでしょうか。
問題が解決できるのは大前提だとしても、解決しない問題だったあるのは認められても、何時になったら解決するのか 見通しがたたないと仕事柄（それが管理者の仕事ですから）困るでしょう。
結局のところ、「見通しをたてる」のは「過去の経験」に依存するしかないのでしょう。そうすると、過去に経験したことがないことに対しては見通しが立てられないということです。新技術を採用した場合に発生する未知の問題における「問題の解決見通し」とは 、「ないものねだり」か「希望的観測」にすぎないと思います。そうかもしれませんが、そうも言っていられないならば、未知の問題を既知の問題に分割して持ち込むことでしょう。それが容易な事かどうかは、わかりません。
2017-02-09
抽象画と例え話との類似性
美術館や博物館などでは友の会に入会していると常設展を（場合によっては特別展も）無料で鑑賞できるようになります。さらに提携している美術館などの常設展にも入れることがあるので、うまく利用すれば、多くの作品を気軽に楽しめるようになります。
ただし常設展の場合は展示替えをしない場合もあるので、同じ作品を何度見てもしょうがないと思う向きもあるかもしれません。ここでよく考えておきたいのは、作品を多少一瞥したくらいで何かがわかるものだろうか、ということです。仮に見た瞬間に作品や画家の意図が一瞬にしてわかるという体験をしたとするなら、それを否定するつもりはありません。僕にもそういう経験が（ごくごく稀に）ないわけではありません。
そうはいっても、数多くの美術館で数多くの常設展にある作品に接した時に、あらゆる作品でそのような経験をするものでしょうか。見る作品すべてにおいて魂が揺さぶられるような気持ちになるのであれば、常設展の出口についたころには疲れはてていたりするのではないでしょうか。
現代美術の抽象画は分かり難いと言われます。その一方で古典的な宗教画や近代の印象派などは「わかりやすい」と思われています。本当にそうでしょうか。確かに描かれているのが風景だったり、聖書の一場面だったりすることは「わかる」かもしれませんが、それでわかったことにして終わりなのでしょうか。
美術作品を鑑賞する時に、ややこしい理屈を持ち出さずに「見たままに感じればよい」とする意見があるようです。それで納得できる人はそうすれば良いでしょうけれども、僕はもっと意識的に鑑賞したいと思っています。鑑賞の参考になりそうな書籍は数多く出版されていますが、ふとしたきっかけで僕が知りたいと思っていたようなことが書かれている本を知りました。これを基にして勉強してみようと思っています。
書籍の解説を読んだり、美術館で作品に触れたり、他の美術館の別の作品をみたりすることを何度も繰り返していると、いずれわかってくる（かもしれない）と思っています。諺に「読書百遍意自ずから通ず」とあるので、作品を何度も見ることが大切だと思います。そのためにも、常設展に何度でも入れる友の会特典は助かります。
前言を翻すようですが、何度見たところで分かった気にならないのが、現代美術の抽象画です。抽象画の理屈はわからないでもないのです。要するに現代社会を特徴づける何かひとつを取り出して、具象的ではなく（抽象的に）表現しているのでしょう。それは良いのですが、作品を前にすると「これは何？」という気持ちにしかなりません。たまには「あぁ、そういうことか」と思う作品に出合うこともありますが、たいていは謎のままです。
ふと思ったのですが、抽象的に表現するのは「例え話」に似ているような気がします。例え話というのは、本当に伝えたいことをストレートに表現するのではなく、相手の理解しやすい（と思った）内容に変換して「例えば」として伝える手法です。これが成功すれば「なんて分かりやすいんだ」と評価してもらえるでしょうけど、失敗すると「何の話をしているの？」とか「だったら、〇×なんでしょう？」とか見当はずれの応答が返ってきたりします。
考えてみるに「例え話」とは、伝えたい事柄から枝葉末節を捨て去って本質だと思うことを取り出して、別の事柄として伝えるテクニックということではないかと思います。これは「抽象画」がおこなっていることに似ているのではないでしょうか。
ただし常設展の場合は展示替えをしない場合もあるので、同じ作品を何度見てもしょうがないと思う向きもあるかもしれません。ここでよく考えておきたいのは、作品を多少一瞥したくらいで何かがわかるものだろうか、ということです。仮に見た瞬間に作品や画家の意図が一瞬にしてわかるという体験をしたとするなら、それを否定するつもりはありません。僕にもそういう経験が（ごくごく稀に）ないわけではありません。
そうはいっても、数多くの美術館で数多くの常設展にある作品に接した時に、あらゆる作品でそのような経験をするものでしょうか。見る作品すべてにおいて魂が揺さぶられるような気持ちになるのであれば、常設展の出口についたころには疲れはてていたりするのではないでしょうか。
現代美術の抽象画は分かり難いと言われます。その一方で古典的な宗教画や近代の印象派などは「わかりやすい」と思われています。本当にそうでしょうか。確かに描かれているのが風景だったり、聖書の一場面だったりすることは「わかる」かもしれませんが、それでわかったことにして終わりなのでしょうか。
美術作品を鑑賞する時に、ややこしい理屈を持ち出さずに「見たままに感じればよい」とする意見があるようです。それで納得できる人はそうすれば良いでしょうけれども、僕はもっと意識的に鑑賞したいと思っています。鑑賞の参考になりそうな書籍は数多く出版されていますが、ふとしたきっかけで僕が知りたいと思っていたようなことが書かれている本を知りました。これを基にして勉強してみようと思っています。
- 三浦篤『まなざしのレッスン (1)西洋伝統絵画』、東京大学出版会、2001年。
- 三浦篤『まなざしのレッスン (2)西洋近現代絵画』、東京大学出版会、2015年。
書籍の解説を読んだり、美術館で作品に触れたり、他の美術館の別の作品をみたりすることを何度も繰り返していると、いずれわかってくる（かもしれない）と思っています。諺に「読書百遍意自ずから通ず」とあるので、作品を何度も見ることが大切だと思います。そのためにも、常設展に何度でも入れる友の会特典は助かります。
前言を翻すようですが、何度見たところで分かった気にならないのが、現代美術の抽象画です。抽象画の理屈はわからないでもないのです。要するに現代社会を特徴づける何かひとつを取り出して、具象的ではなく（抽象的に）表現しているのでしょう。それは良いのですが、作品を前にすると「これは何？」という気持ちにしかなりません。たまには「あぁ、そういうことか」と思う作品に出合うこともありますが、たいていは謎のままです。
ふと思ったのですが、抽象的に表現するのは「例え話」に似ているような気がします。例え話というのは、本当に伝えたいことをストレートに表現するのではなく、相手の理解しやすい（と思った）内容に変換して「例えば」として伝える手法です。これが成功すれば「なんて分かりやすいんだ」と評価してもらえるでしょうけど、失敗すると「何の話をしているの？」とか「だったら、〇×なんでしょう？」とか見当はずれの応答が返ってきたりします。
考えてみるに「例え話」とは、伝えたい事柄から枝葉末節を捨て去って本質だと思うことを取り出して、別の事柄として伝えるテクニックということではないかと思います。これは「抽象画」がおこなっていることに似ているのではないでしょうか。
pkgsrcのパッケージを更新すると無くなるパッケージが出てくる
pkgsrcからインストールしたパッケージについては、次のような情報から更新する必要性の有無を判断しています。
ところが更新処理中に何らかのエラーが発生して、処理が中断してしまうことがあります。ここでエラーとなった問題を解決して、再度更新処理をおこなったとしても、エラー発生前の再帰処理中に消されてしまったパッケージがあるので、更新処理を再開したとしても削除されたパッケージが復活してくれるわけではありません。その結果インストールしておいたはずのパッケージが何時の間にか無くなっているという状況になってしまいます。
pkgsrcそのものの仕組みの中で上述した問題の解決策があれば有り難いのですが、pkgsrc自体ではどうしようもないのであれば、自前のスクリプトを用意しようと思います。
- pkgsrcからインストールしたpkgtools/lintpkgsrcを利用して「lintpkgsrc -i」 の結果
- 毎日起動されるdailyスクリプトで指摘された脆弱性のあるパッケージ名
ところが更新処理中に何らかのエラーが発生して、処理が中断してしまうことがあります。ここでエラーとなった問題を解決して、再度更新処理をおこなったとしても、エラー発生前の再帰処理中に消されてしまったパッケージがあるので、更新処理を再開したとしても削除されたパッケージが復活してくれるわけではありません。その結果インストールしておいたはずのパッケージが何時の間にか無くなっているという状況になってしまいます。
pkgsrcそのものの仕組みの中で上述した問題の解決策があれば有り難いのですが、pkgsrc自体ではどうしようもないのであれば、自前のスクリプトを用意しようと思います。
2017-02-08
ピースボードの思い出をフォトブックにしてみました
一昔前にピースボードで旅行をしました。この時に初めてデジカメを買って持っていきました。それまでは昔ながらのフィルム式のコンパクトカメラを使っていたので、どちらかというとフィルム式カメラの方が馴染みがあり、旅行の最初の頃はデジカメは使いませんでした。
しかしフィルム式だと現像しないと撮影した写真が見られないし、現像したりプリントするのにお金がかかると思うと、デジカメを使うのに慣れようと考えました。当時のデジカメは、現在と比べると画素数が少ないし、処理速度が遅いのでシャッターを切るタイミングが一呼吸遅れることがよくありました。
しかしデジカメの最大の利点は、撮影した画像ファイルをPCで直ちに見られることです。しかも記録メディアに入るうちなら余分に撮影しても、要らなければ消せば良いだけの話なので、プリントしない限りお金の心配をしなくても済みます。
デジカメを使う場合には、シャッターチャンスを待ってからシャッターを切っては遅いということに気付き、シャッターを余分に切ったところで不要なら画像ファイルを消せば良いということに気付いたので、旅行中はデジカメで撮影しまくりました。最終的に2,400枚ほど撮影しましたが、気に入らない写真を消して、結局900枚ほどが残りました。シャッターチャンスを逃すより撮りすぎる方がマシという発想に転換しました。
旅行から戻ってからは、たまに思い出したように写真を眺めて旅行中の記憶を呼び覚ましていたのですが、ずいぶん長いことパソコンのディスクの肥やしとなって眠っていました。
ここ数年ほどは旅行中に撮影した写真をまとめてフォトブックを制作しています。このようなサービスを提供している会社は幾つかあり、どこを利用しようかと迷ったのですが、評判や直感で決断して「photoback」を利用し続けています。最初の頃は、フォトブックを制作するための基本的な考え方もわからなかったし、photobackが提供するサービスの概念をどのように活かしたらよいのか見当がつかなかったので、ずいぶん苦労しました。最近は作り慣れてきたので、出来上がったフォトブックのイメージを頭の中に思い描きながら、楽しく制作できるようになっています。
ピースボートの旅行の始めの頃は、フィルム式カメラで撮影した写真しかないので、スキャナでデジタル化しました。さすがに画像が荒くなってしまいますが、個人的な作品なので許容範囲です。
旅行中の写真が900枚ほどあるとは言え、さすがに全部をフォトブックに使う訳にはいきません。ひとつひとつの写真は貴重な旅行中の想い出なので、できるだけ多くをフォトブックに使いたいのはやまやまです。しかしフォトブックを制作する上では、ただ無作為に写真を並べるのではなくて、何らかのストーリー性を持たせつつ、写真の大きさや配置をコントロールして、一貫性のある作品に仕上げたいと思っています。
一方でphotobackが提供するフォトブックの最大ページ数の制限も考えなければなりません。結局使用した写真は184枚でした。分冊して制作すれば、もっと多くの写真を使ったり、レイアウトを工夫したりできたでしょう。このフォトブックは思い出を一冊にまとめることが大事であって、全ての写真を見たければパソコンの中に全て入っているのです。
しかしフィルム式だと現像しないと撮影した写真が見られないし、現像したりプリントするのにお金がかかると思うと、デジカメを使うのに慣れようと考えました。当時のデジカメは、現在と比べると画素数が少ないし、処理速度が遅いのでシャッターを切るタイミングが一呼吸遅れることがよくありました。
しかしデジカメの最大の利点は、撮影した画像ファイルをPCで直ちに見られることです。しかも記録メディアに入るうちなら余分に撮影しても、要らなければ消せば良いだけの話なので、プリントしない限りお金の心配をしなくても済みます。
デジカメを使う場合には、シャッターチャンスを待ってからシャッターを切っては遅いということに気付き、シャッターを余分に切ったところで不要なら画像ファイルを消せば良いということに気付いたので、旅行中はデジカメで撮影しまくりました。最終的に2,400枚ほど撮影しましたが、気に入らない写真を消して、結局900枚ほどが残りました。シャッターチャンスを逃すより撮りすぎる方がマシという発想に転換しました。
旅行から戻ってからは、たまに思い出したように写真を眺めて旅行中の記憶を呼び覚ましていたのですが、ずいぶん長いことパソコンのディスクの肥やしとなって眠っていました。
ここ数年ほどは旅行中に撮影した写真をまとめてフォトブックを制作しています。このようなサービスを提供している会社は幾つかあり、どこを利用しようかと迷ったのですが、評判や直感で決断して「photoback」を利用し続けています。最初の頃は、フォトブックを制作するための基本的な考え方もわからなかったし、photobackが提供するサービスの概念をどのように活かしたらよいのか見当がつかなかったので、ずいぶん苦労しました。最近は作り慣れてきたので、出来上がったフォトブックのイメージを頭の中に思い描きながら、楽しく制作できるようになっています。
ピースボートの旅行の始めの頃は、フィルム式カメラで撮影した写真しかないので、スキャナでデジタル化しました。さすがに画像が荒くなってしまいますが、個人的な作品なので許容範囲です。
旅行中の写真が900枚ほどあるとは言え、さすがに全部をフォトブックに使う訳にはいきません。ひとつひとつの写真は貴重な旅行中の想い出なので、できるだけ多くをフォトブックに使いたいのはやまやまです。しかしフォトブックを制作する上では、ただ無作為に写真を並べるのではなくて、何らかのストーリー性を持たせつつ、写真の大きさや配置をコントロールして、一貫性のある作品に仕上げたいと思っています。
一方でphotobackが提供するフォトブックの最大ページ数の制限も考えなければなりません。結局使用した写真は184枚でした。分冊して制作すれば、もっと多くの写真を使ったり、レイアウトを工夫したりできたでしょう。このフォトブックは思い出を一冊にまとめることが大事であって、全ての写真を見たければパソコンの中に全て入っているのです。
2017-02-06
『句動詞の底力』の各章の見出しにみる日英の発想の違い
プレイスから出版されているクリストファ・バーナード著『句動詞の底力』（ISBN978-4-903738-32-1）の各章の見出しにある日本語と英語の表現の違いから日英の発想の違いを見てみようと思います。ちなみにプレイスからは「底力シリーズ」として何冊も出版されていますが、どれも特定の項目を深く掘り下げた良書だと思います。
まず目次から各章の見出しを拾ってみます。
これらの対応の事例をもって和文英訳に役立てようと思っているわけではないので、各章の見出しが直訳的であろうと意訳的であろうと、別にそれは問題ではないのですが、少なくとも日英の発想の違いが垣間見えると思います。
例えば日本人が母語（日本語）を基にした発想で文章を考えてから和文英訳的に英文を書こうとすると、なかなか上述したような英文は出てこないのではないでしょうか。13番目の「句動詞と1語の動詞との関わり」という和文から英文を発想しても「When to Use a Phrasal Verb」 にはならないでしょう。
このような発想は一朝一夕に身につくわけではないと思うので、時間をかけて学んでいこうと思います。
まず目次から各章の見出しを拾ってみます。
- 英語は空間が大好き！
- これは前置詞？ それとも副詞？
- 句動詞とは何だろう？
- 句動詞の文法的なパターン
- 基本動詞と基本パーティクル
- パーティクルの王様OUTとUP
- GETの意味を正しく知る
- プラス／マイナスそして次元から考える
- 日本語から逆方向に考えると
- 句動詞のエキスとは何だろう？
- 意味の地図を作ろう
- 句動詞から名詞へ：語彙を広げるために
- 句動詞と1語の動詞との関わり
- English Loves Space!
- Is this a Preposition or an Adverb?
- What is a Phrasal Verb?
- Seven Patterns of Phrasal Verbs
- The Basic Building Blocks
- Basic Meanings of OUT and UP
- A Detailed Look at "GET"
- The point of View of Positive / Negative and Dimension
- Thinking in the Reverse Direction
- What is the Essence of Phrasal Verbs?
- Creating a Meaning Map from a Particle
- Nouns from Phrasal Verbs: Expanding your Range of Expression
- When to Use a Phrasal Verb
これらの対応の事例をもって和文英訳に役立てようと思っているわけではないので、各章の見出しが直訳的であろうと意訳的であろうと、別にそれは問題ではないのですが、少なくとも日英の発想の違いが垣間見えると思います。
例えば日本人が母語（日本語）を基にした発想で文章を考えてから和文英訳的に英文を書こうとすると、なかなか上述したような英文は出てこないのではないでしょうか。13番目の「句動詞と1語の動詞との関わり」という和文から英文を発想しても「When to Use a Phrasal Verb」 にはならないでしょう。
このような発想は一朝一夕に身につくわけではないと思うので、時間をかけて学んでいこうと思います。
2017-02-01
KeePassを利用したパスワード管理
Microsoft WindowsではID Managerを利用してパスワード管理を行ってきました。この度dynabook SS SX/15AのWindows VistaをNetBSD/i386に移行するにあたり、ID Managerに変わる環境を用意する必要がでてきました。
パスワード管理をおこなう方法はいろいろあるようですが、ローカルマシンで完結していることや使用料金が発生しないものを探していくとKeePassおよび派生アプリケーションが見つかりました。これらはパスワード管理をおこなう機能しか持っていないようで、ブラウザとの連携をとるためにはブラウザ毎にアドオンを入れなければならないようです。
当初はKeePassXでパスワードを管理し、FirefoxのアドオンにはKeyFoxを入れるつもりでした。ところがKeyFoxはNetBSDが動作対象外とされインストールできません。またKeePassXはブラウザとの連携は実験的実装に留まっているみたいで、FAQには次のような回答があります。KeePassXから派生したKeePassXCというものが出ているようですが、pkgsrcに含まれていないので候補から外しました。
Windowsで利用していたID Managerとは使い勝手が違いますが、同等の環境が得られたのでNetBSDではKeePassを使っていこうと思います。
KeePassを使ってみて戸惑ったのは、初回にユーザ認証をしたときに「Firefoxに情報を記録させますか」という意味のダイアログボックスが現れたことです。Firefoxにもユーザ認証を補助する機能が入っていますが、これを使わずにKeePassを利用することに決めたハズなので、ここで「No」を選択したのですが、実は「Yes」とすべきだったようです。おそらくPassIFoxが入っていれば、メッセージ的には「Firefoxに」と出ていても、実際にはKeePassに情報が記録されるようです。
またKeePassの画面から「終了」を選択しても、psで見るとプロセスが消えてくれません。killすれば消せるのですが、うっかりして多重に起動させてしまうとトラブルの原因となりそうです。
ID ManagerやKeePassは情報をXML形式で交換できるようなので、ID Managerで管理している情報をXSLTで変換してKeePassに登録しようと考えています。
パスワード管理をおこなう方法はいろいろあるようですが、ローカルマシンで完結していることや使用料金が発生しないものを探していくとKeePassおよび派生アプリケーションが見つかりました。これらはパスワード管理をおこなう機能しか持っていないようで、ブラウザとの連携をとるためにはブラウザ毎にアドオンを入れなければならないようです。
当初はKeePassXでパスワードを管理し、FirefoxのアドオンにはKeyFoxを入れるつもりでした。ところがKeyFoxはNetBSDが動作対象外とされインストールできません。またKeePassXはブラウザとの連携は実験的実装に留まっているみたいで、FAQには次のような回答があります。KeePassXから派生したKeePassXCというものが出ているようですが、pkgsrcに含まれていないので候補から外しました。
Q: Is Auto-Type supported on Mac OS X or Windows?結局KeePassを利用することとしてpkgsrcからインストールしました。ブラウザと連携させるにはKeePassHttpが必要となるようです。公式サイトからKeePassHttp.plgxを入手し、以下のように所定のディレクトリに置きました。またFirefoxアドオンとしてPassIFoxをインストールしました。
A: No, Auto-Type is currently supported on Linux only.
-rw-r--r-- 1 root wheel 160499 Feb 1 08:57 /usr/pkg/libexec/KeePass/KeePassHttp.plgxここで/usr/pkg/bin/KeePassを起動して待機させておきます。Firefoxから何かユーザ認証が必要なサイトにいくと、KeePassとの接続を求められるので、それに従い接続を確立しておきます。最初はユーザ名とパスワードを手動入力しますが、次回以降は自動的に入力されるのを確認しました。
Windowsで利用していたID Managerとは使い勝手が違いますが、同等の環境が得られたのでNetBSDではKeePassを使っていこうと思います。
KeePassを使ってみて戸惑ったのは、初回にユーザ認証をしたときに「Firefoxに情報を記録させますか」という意味のダイアログボックスが現れたことです。Firefoxにもユーザ認証を補助する機能が入っていますが、これを使わずにKeePassを利用することに決めたハズなので、ここで「No」を選択したのですが、実は「Yes」とすべきだったようです。おそらくPassIFoxが入っていれば、メッセージ的には「Firefoxに」と出ていても、実際にはKeePassに情報が記録されるようです。
またKeePassの画面から「終了」を選択しても、psで見るとプロセスが消えてくれません。killすれば消せるのですが、うっかりして多重に起動させてしまうとトラブルの原因となりそうです。
ID ManagerやKeePassは情報をXML形式で交換できるようなので、ID Managerで管理している情報をXSLTで変換してKeePassに登録しようと考えています。
登録:
投稿 (Atom)