はてなブログを開設してみた

かたちづくりはてなブログ版)
最近の日記っぽいダラダラした記事ははてなブログに移行しようかと思う。ということはダラダラしない記事はこちらに書くのか、と問われると返答に詰まる。こちらは放置になる可能性が高いかもしれない・・・。

もう少し先の話だが引越しを検討しているので、これを機に本を整理しようと思っている。要らない本はバッサリ捨ててスッキリさせようという計画だが、やはり本には読んだ当時の記憶がまとわりついていてなかなかに捨てづらい。

まず捨てることを決めたのは古いWindowsプログラミング関係の本。Win32 API とか COM/ATL などの書籍は全部捨てる。ああいう本は賞味期限が過ぎたらもう使えないし、別に愛着もない。

次なる候補はC++関連。もうすっかりC#プログラマC++に戻る気は無いので、基本的には全部捨てたって大した問題は起こらないはず。あとは僕の気持ちの問題。まず「大規模C++ソフトウェアデザイン」は捨てる。いい本だったが、もうC++は使ってないし、あの本は厚くて場所をとる。しかしここから先に進めない。「Modern C++ Design」は変態的な template プログラミングの本。「変態だー!変態だー!」と思いながらウンウン唸って読んだ思い出があるので捨てられない。同様に「Exceptional C++」も、C++の例外安全性などかなりマニアックなトピックについて書かれた本で、捨ててしまうか迷っている。

XP関連の本は思ったよりも気軽に捨ててしまえそう。XP本は一時大量に発売されていたし、乱読気味だったのでポイポイ捨ててしまおうかと思っている。アジャイル開発プロセスは自分の中でブームが去ってしまった感がある。

ソフトウェア設計関係も結構捨てがたい本が多い。GoFデザインパターン」は学生時代に買ってもうボロボロになっているが、買った当時は布団で読みながら寝てしまい枕がわりにしていた想い出のある本なので捨てられない。メイヤーの「オブジェクト指向入門」もキープ。一方 POSA は捨てることにした。あの本は有名なんだけど、どうも僕にはそれほどピンと来なかった本だったので。

全く捨てる気が無いのは数学の本。「数学ガール」や志賀浩二の30講シリーズなどの純粋数学モノから、実用的な応用数学線形代数、職業柄必要な幾何学や形状表現モノ。数学には賞味期限がないからね。

7名の作家が自炊代行業者を訴えるそうだ。

訴えが正当なものかどうかについては、僕には分からない。電子書籍については、Kindleを購入して以来実に読書が楽しめているので、どんどん広がって欲しいなとは願っている。だからこのような訴訟が電子書籍の未来に水を差すものであって欲しくはないと思う。

ただ、訴えを起こした作家たちを批判するのも何か違う気がしている。

これも Innovator's Dilemma の構図と思う。電子書籍市場は成長分野だと思うが、絶対規模は少なくとも日本においてはまだまだ小さいだろう。だから既存の大手出版社や売れっ子作家にとっては電子書籍市場は魅力的には映らないだろうし、下手に手を出すと紙の書籍の売上を落としてしまう可能性だってあるだろう。

つまり、大手出版社や売れっ子作家が「自炊」や電子書籍を忌避するのは、彼らなりの合理的な判断の結果なんだろうなと斟酌する。

ただ、裁判所がどう判断するか、するべきか、は日本におけるこれからの書籍のあり方、ひいては社会のデザインに大きく影響を与えるものであるから、大いに議論し意見するべきだろうなと思う。

それから、Innovator's Dilemma の構図で考えれば電子書籍イノベーションを既存のマーケットリーダーに期待するのは的外れではなかろうか。別のプレーヤーが市場を破壊しひっくり返す未来に期待するべきじゃなかろうか。

例えば製造業のような巨大な産業は、経済のいわば心臓なのだろう。この心臓が送り出す血液は、マネーであり、労働力であり、製品である。

お金の流れを考えてみる。産業構造の頂点にいる企業がモノやサービスを販売し、広く一般消費者からお金を集めてくる。集まったお金は二次請け、三次請けと産業ピラミッドの下方に向かって分配されていく。頂点の企業は、消費者からお金を集め業界に分配する漏斗のような役割を果たしている。

当然ながらサービスの流れはこれと全く逆になる。産業を構造化し階層化し労働力を集約し、モノやサービスに仕上げて一般消費者へと流れていく。ここでも頂点の企業は労働力を集約する漏斗の役割を果たしている。

かつてコンシューマ市場への販売チャネルを持ち経済の漏斗となるのは大企業の特権であったように思う。しかし最近はそういった構図が崩れてきているのかなと思う。

メディア業界が分かりやすい。かつてメディアを持ち広く情報を発信できるのはテレビ局や新聞社、出版社など限られた企業のみであった。しかし今やブログやツイッターを利用すれば誰でもメディアになることが出来るようになった。一部の企業が「情報の漏斗」たる地位を独占することはできなくなった。

直観的に、今後の進化の方向性として「高度化」「効率化」「大型化」は難しいという気がする。「多様化」する以外にない気がする。多様化するということはつまり分散するということである。分散するということは大きな「漏斗」が無くなっていく、減っていく、ということである。太い動脈ではなく無数の毛細血管を張り巡らせて血液を循環させるようになるということである。

我ながら何を偉そうに書いているのか、と思う。ぜんぜん分かってないのに。どんな未来が待っているのだろうか。せいぜい目を凝らしてみるくらいの努力はしてみようかと思う。

先週の金曜日は3D-GANのセミナー&忘年会であった。

セミナーでは最近映画などでよく耳にする「〇〇製作委員会」の仕組みについての説明があった。製作委員会というのは民法上の組合であり、登記も定款も必要なく、単に組合員で契約書を取り交わすだけで成立してしまうという非常にお手軽でゆるーい仕組みらしい。組合員となる各社が出資金を出しあい、その出資金の比率に応じて利益を按分するというのがおおまかな仕組みだ。製作委員会を作る目的は一次利用(映画の上映)ではなく、その二次利用(DVD、イベント、キャラクターグッズ)の管理にある。ちなみに最初に出した出資金は資産計上され、年々償却していくのが通例とのこと。

その後の忘年会では、いろんな方と楽しく歓談させて頂いた。

  • kickstarter という米国のマイクロファンディング(?)の話
  • CTによる形状スキャンの話
  • 光造形のサポート材設計の話
  • NURBS曲面のトリムの話
  • ゲーム業界は新興のケータイゲーム、ソーシャルゲームをどう見ているのかという話
  • 製造業系のCAD/CAM業界、景気悪いよねー、右肩下がりだよねー、なんかしないとねー、という話

などなど。
お付き合い頂いた方々、ありがとうございました。来年もよろしくお願いいたします。

今日はTwitterで「普通に美味しい」の意味が話題になった。紹介してもらった下記の記事がナカナカに面白いものであった。

いまや既に「普通」の意見などというものは、なんらかの前提を否定する形でしかあり得ないという認識だ。そこでは、流行語だから、あるいは、言葉が乱れているから「普通に〜」などという言い回しを用いているわけではない。そうせざるを得ない社会的な前提があるから、そういう言い回しで物事を評価しているのだ。つまり、端的に「普通」なものなどないから、あえて「普通」なものを見いださねばならないのだ。

「普通においしい」という言い回しは、「日本語の乱れ」あるいはそれを否定する議論とは無縁である - Kentaro Kuribayashi's blog

僕も「普通に〜」は使っていると思う。多分その理由は、一種の予防線なのだと思う。迂闊に「あの店は美味しいよ」などと人に言おうものなら、グルメ番組でレポーターが大げさに美味しいと騒ぎ立てるように美味しいのかと勘違いされて「期待したほどじゃなかったぞ」などとお叱りを受けかねないのでその予防線として「普通に〜」と言うのである。
それから、たぶん、普通に美味しいのではなくて美味しいのが普通になったのだ。どの店で何を食べても大抵は美味しいと僕は思っている。そういう意味では幸せな国、幸せな時代に生きているんだと思う。たぶん昔は、美味しいことが普通ではない時代があったのだ。そういう時代には「普通に美味しい」という表現などあろうはずがない。しかし僕たちは何を食べても美味しい世界に生きている。だから「普通に美味しい」という表現を僕たちは普通に使うのだ。

float や double のような浮動小数点型は、有限桁で切られているので当然ながら実数体を成していない。浮動小数点型では連続体濃度を表現できないのだ。

しかしこれをもって「コンピュータは連続体濃度を持つ実数体の演算ができない」と断じて良いものだろうか。float や double にはできないだけであって、何か別の数値表現を考えれば連続体濃度を扱うことだって出来るかもしれないじゃないか。

簡単のため、[0, 1) の範囲の実数だけを考えることにしよう。範囲を限定しても実数であるからには連続体濃度を持つことに変わりはない。この範囲の任意の数値は次の型で表現できるのではないだろうか。

IEnumerable<int>

どういうことかというと、IEnumerable が表現する数列を小数点以下の各桁の数字の列として考えようということだ。この考えに従うと、次のように様々な数値が表現できる。

IEnumerable<int> Num1() { yield return 1; yield return 2; yield return 3; } // 0.123
IEnumerable<int> Num2() { while ( true ) yield return 3; } // 0.33333... == 1/3
IEnumerable<int> Num2() { while ( true ) yield return 9; } // 0.99999... == 1

そもそも無限の定義とかε-δ論法とか実に「遅延評価的」だと思う。なので遅延評価を理解しているプログラマはすべからくε-δ論法もすんなりと理解できる、なんてことはない?