鉄道模型には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にはなってくれないのです。こういう理由で、鉄道模型は現実感を無視した運転にならざるをえないのだと思います。
2017-02-10
問題の解決の見通しと過去の経験
去年の夏頃から、所有している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)