Displaying posts tagged with

“読書”

海外ETFの本

タイトルはちょっとアレだが、至極真っ当な本。インデックス連動型の海外ETFを買って、世界経済の成長に参加しよう!というお話。敢えて一文、本書の肝となる主張を抜き出すとしたら、次の文だろうか(258ページ):

長期的にみて、世界経済が発展する限り、市場は全体として右肩上がりになります。

この理屈が理解できなかったせいで、私にとって長らく投資という行為は胡散臭い儲け話と区別がつかなかった。いや、多分今でも心の底では理解できていないと思う。失われた10年に青春を過ごした私(たちの世代)にとって、世の中というのは「短期的な上下を繰り返しながらも、緩やかに下降していく」ものだという認識が染みついているので、株価であれ、何らかの指数であれ、投資信託の基準価格であれ、中長期的に右肩上がりに上昇し続けるというのは、鼻で笑ってしまうような馬鹿げた幻想にしか思えないのだ。……むしろそういう世界観を相対化してみたくて、今の私は投資を行っているのかも知れない。

それで海外ETFだが、実際に買おうと思うと、やはり普通の投資信託よりもいろいろと敷居が高くて躊躇している。特に面倒なのが税金。海外ETFは海外株式と同じ扱いになるため、手数料の安いネット証券では特定口座が利用できない。ならば自分で確定申告を、と考えて調べてみると、これがよく分からない。売買差益が譲渡所得で申告分離課税、為替差益が雑所得で総合課税という基本は簡単なのだが、ここで日本円を米ドルに換えて、ここで○○ドルでETFを買って、ここで××ドル分を売却したとして……というリアルなシナリオに沿って考えていくと、いつどのレートでどういう所得が発生するのか、頭がこんがらがってくる。

他にも、これは本にも書いてあることだが、ETFは最低取引金額がまだ高いし、購入する際の手数料もかかるので、小額ずつ積み立てて行くのには向いていない。やはり当面は普通の投資信託で積み立てていくのが簡単そうだ。本書執筆時点では存在していなかったMSCI エマージング・マーケット・インデックスに連動するインデックスファンドも登場したことだし……。

『実践Common Lisp』読みかけの感想

11章途中まで読んだ。

他言語のプログラマに向けたLisp本。リストがどうしたコンスセルがどうしたという定番の説明をすっ飛ばして、とにかくまずはCommon Lispの凄さを見ろと言わんばかりに、最短距離でマクロの実演に突き進む。その姿勢は正しいと思う。ある程度経験のあるプログラマならリストやコンスセルの基礎くらいは知っているものだし、その上で「Lispって、結局何がどう凄いのかよくワカンネ」という人がこの本のターゲットだろう。

実際途中まで読んだだけでも、マクロの凄さはひしひしと伝わってくる。他言語での経験を振り返って、果たしてプログラムを書くということはどういうことだっただろうかと、改めて考え直してしまうくらい示唆に富んだ内容を含んでいる……。

ところでマクロのイディオムとして、次のように処理の”本体”となるコードを埋め込む形が多用されている。

(defmacro foo (a b &body body)
    `(bar (baz ,@body))

これはRubyのブロックによく似ている。一般にRubyのブロックは無名関数に対するシンタックスシュガーと見なされることが多いのだが、むしろLispのマクロを意識した部分も大きいのかも知れない。

…検索してみるとやはりLispのマクロとRubyのブロックを比較する視点は存在するようだ。Ruby作者のまつもとさん自身も取り上げている:

実践 Common Lisp 3.8

少しずつだが『実践Common Lisp』を読み始めた。3章の where の例で早くも感動。Lispのマクロはとにかく凄いのだと、著者がくどいくらいに主張する理由が分かってきた。確かにこれは凄い。

練習のために update のマクロ版も書いてみた。後の章で出てくるのかも知れないが。

(defun make-update-expr (field value)
  `(setf (getf cd ,field) ,value))
 
(defmacro update (selector-fn &rest clauses)
  `(setf *db*
	 (mapcar
	  #'(lambda (cd)
	      (when (funcall ,selector-fn cd)
		,@(make-expr-list #'make-update-expr clauses))
	      cd)
	  *db*)))

make-expr-list は make-comparison-list を一般化したもので、次の通り。

(defun make-expr-list (make-expr-fn fields)
  (loop while fields
       collecting (funcall make-expr-fn (pop fields) (pop fields))))

Authenticated encryption(認証暗号?)

Authenticated encryption:機密性と完全性を同時に守るための暗号システム。対称暗号とMACとの組み合わせで実現するか、もしくは専用に設計された対称ブロック暗号のモードを使用する。最近になって活発に研究されている分野らしい。

そのような対称ブロック暗号のモードは Authenticated Encryption Modes といった名称で分類され、中でもNISTが標準化しているのは CCM と GCM モード。CCM モードは IEEE 802.11i 規格の一部として実用化されている。また他にNISTに提案されているものとしては CWC, EAX, OCB モードなどがある。

一般に使用可能な実装としては、Brian Gladman氏のサイトで CCM, GCM, EAX, CWC モードの実装がBSDライクなライセンスで公開されている。またパブリックドメインの暗号化ライブラリ libTomCrypt工事中の新サイト) では EAX, OCB, CCM, GCM モードが利用できる。

C/C++セキュアプログラミングクックブック〈VOLUME2〉対称鍵暗号の実装』でイチ押しされているのは CWC モードだが、世間的にはNIST標準である CCM モードや GCM モードの方が広く使われているようだ。

比較的新しい分野のためか、WEB上には日本語の情報は少ない(探し方が悪いのかも)。唯一CRYPTREC が2003年に公開した報告書(pdf)『ブロック暗号を使った秘匿、メッセージ認証、及び認証暗号を目的とした利用モードの技術調査報告』の中で「認証暗号に関するモード」として安全性や効率について詳しい検討を行っているが、ちょっと専門的過ぎる。一方でWikipedia英語版の充実振りは素晴らしい。

GW読書中

GWなので欲しかった本をまとめ買いしてきた。

『WEB+DB PRESS vol.50』
だいたい読み終えた。Gitの記事とkey-value storeの記事が面白かった。Gitは内部の構造まで理解しないと使いこなすのが難しい。Subversion とは対照的。でも総合的な使い勝手ではやっぱりGitの方が上だと思う。

Subversion が提示する世界観は分かりやすい。リポジトリ全体は「ディレクトリツリー」なのだという比喩が中心にあって、そのツリーに対する更新やらコピーやらの操作が、各種バージョン管理の操作に対応するようインターフェイスが工夫されている。オブジェクト指向的とも言えるかも知れない。一方Gitは機能指向的というか、まず自分が何をすべきなのか、どのような操作を実行すべきなのか理解した上で、対応するコマンド(とコマンドラインオプション)を選ばなければいけない。操作対象の抽象度も低く、あくまでもプログラマ向けという匂いが強い。そして実際、プログラマなら(慣れれば)Gitの方が使いやすい。

一見「分かりやすい」比喩を用意したとしても上手くいくとは限らないということか、単に比喩の妥当性の問題なのか。いろいろ考えさせられる。

『C/C++セキュアプログラミングクックブック』
前々から買おうかどうか迷っていた本。熟慮の末volume 2と3を買った。立ち読みした限りではそこまでハードなC言語の知識は要求していないっぽい。ギリギリ「コードが読める」レベルの私でもなんとかなりそう。

まだvolume 2を読み始めたばかりだが、まさに私が求めていた本、かもしれない。暗号化周りは実際にコードを書こうとすると分からなくなることが多すぎる。「IVって公開して良いの?」とか「『鍵』ってパスワードみたいにコード中に直接書いておけば良いの?」とか「ソルトってどうやって作って管理すれば良いの?」とか。自力で一つ一つ理屈を積み重ねて判断していくのは辛過ぎる…。しかもこの分野ほど”素人の直感”が裏目に出やすい分野はない。

本文中では「一般人は生の暗号化操作をするな。信頼できる高水準のインターフェイスを使え」と繰り返されている。Ruby やら PHP やらの階層でごにょごにょやるより、既存のC実装へのインターフェイスを作った方が良いのかも知れない(私にそのスキルがあればの話だが)。

以下はまだほとんど手付かず。

ノンデザイナーズ・デザインブック

自分でデザインした文書やWebページや壁紙から漂ってくる、あの如何ともしがたい素人臭はこれが原因だったのか!

タイトル通り、非デザイナー向けのデザイン本。本屋で立ち読みして衝動買い。「Third Edition」「新装増補版」とあるのを見ると、その筋では結構有名な本だったりするんだろうか。基本的に英語圏の本なのだが、大部分はそのまま日本語でも通用するはず。本文中に載っている”悪い見本”が、これまで自分が作ってきたダサダサなデザインとあまりにも似過ぎていて、「これ!まさにこれ!」と思わず叫び出してしまうほど。

個人的に特に参考になった内容をまとめておく:

  • 関連のある要素は近付け、関連のない要素は離す。空白を恐れてはいけない
  • 全ての要素をきちんと整列させる
  • 文字の中央揃えは使ってはいけない
  • コントラストは大胆につける
  • 似て非なる要素は衝突を起こす。全く同じか、はっきり違うか、どちらかにする
  • 活字にはカテゴリーがあり、組み合わせ方にルールがある

あと、非英語圏の人間にはあまり参考にはならないのだが、「文字を全部大文字にしてはいけない」としきりに強調しているのも印象的だった。あれはやっぱり読み難いよなあ。ネイティブはそうは思わないんだろうかと前々から疑問だった。

Zend Framework 徹底入門

PHP用のMVCフレームワークを選定している。

『Zend Framework徹底入門』は、この手のフレームワーク本としてはちょっと珍しいくらいに内容が充実していて、2chのZFスレでも非常に評価が高い(あまりにも絶賛意見が多いので当初は「宣伝乙」とか思ってました…ごめんなさい)。もともとZFは公式ドキュメントが充実しているので、この本と合わせればそれでもう十分な情報量になる。

しかしいくら情報量が多くても、フレームワーク自体が使いにくければどうしようもない。そして私にとってZFは、使いやすいとは言い難い。一人のプログラマとして設計やコードを眺めるととても美しいと感じるのだが、いざ一人のユーザとして使ってみると、あらゆる種類の不親切さにうんざりしてしまう。

”Rails以前”のフレームワークを現代風に洗練した感じ、とでも言おうか。Railsは「皆さんはもっとラクをして良いんですよ」というメッセージを堂々と打ち出してきたことが衝撃的だった。ZFにはそういう意識は感じられない。優れた設計・コードはあっても、使いやすくするための工夫は少ない。

ZFの上にもう一枚、自分用フレームワークの層を構築するべきか。それとも他のフレームワークをあたるのが早いか。

新約聖書 訳と註 3 パウロ書簡 その一

田川建三訳著『新約聖書 訳と註 3 パウロ書簡 その一』。夕食後に少しずつ読み進め、1ヶ月ほどかけて読了。

この翻訳が読める時代・言語圏に生まれて幸運だったと思える。同著者の『書物としての新約聖書』を読んでいると心底そう思う。訳文からも膨大な訳注からも、著者の学問的誠実さがひしひしと伝わってきて、読んでいて清々しく感じる。一方、他翻訳(主に口語訳と新共同訳)の誤りを指摘する際にはかなり頻繁に露骨な嫌味が添えられているので、読んでいて何だか荒んだ気分になってくる……。

この第3巻にはパウロの真筆書簡が収められている。日本では宗教・信仰と言うと『信じるものは救われる』的な考え方が一般的だと思うのだが、パウロ本来の考え方はその真逆と言っていいもので、有り体に言えばもっとずっと「深い」。パウロの書簡の中にはそういう思想的に深いところと、その思想ゆえの自己矛盾と驕りとが隣り合わせになっている。

そういったことは、その筋の人にとっては良く知られた事実なのだろうけれども、一般人が漠然と聖書の本文を読んでいるだけではやはり分からない。翻訳の質がどうという以前に、一言一節の意図を考える一つのきっかけとして、註の存在はとてもありがたい。