イーラーニングやってる社長のブログ

くらふとわーくす開発室ブログはじめました

Fri, 02 Jul 2010 00:50:10 +0900

最近twitterの方にぽつぽつ書いていて、すっかりこのブログの更新がなくなっとるわけですが、仕事の方はいい感じでがんばってます。

こちらのブログは完全に落書きモード？にしてしまって、自分が作っているサービス・製品の「eラーニングサービスeden」と「読書共有サービスReadShare」のことだけを書くブログを「くらふとわーくす開発室ブログ」として分離することにしました。

もしよければそちらの方もチェックみてください。

iPadを買ったらまずコレやろうずwww

Fri, 28 May 2010 02:29:05 +0900

iPadがそろそろ日本でも発売というらしい。友達に頼んで一足先にゲットして使ってみているんだけど、iPadは「ビューア」としては最強ということは自信を持って言える。

Webページを初めとして、WordやPPT、PDFなどある程度のボリュームのあるコンテンツを見るためのデバイスとして、これほど快適なものはない。持ち上げるには少し重いので姿勢によっては辛いのだが、iPad発表の時にジョブズがやっていたようにソファに座って膝の上に乗せるというスタイルであれば本当に快適だ。

PPTやPDFなどの「ファイルの閲覧」ということなら「i文庫HD」がベストなんだけど、問題はWebページの閲覧だ。特にニュースサイトなどでは1つの記事が複数ページに分かれていることが多く、iPadのSafariで見るときにページを描画の段階でどうしてもモタついてしまう。これが非常にもったいないわけだ。

・ xAutoPagerize使おうず

というわけで、iPadをゲットした人は、何はともあれまずは「xAutoPagerize」を入れるべきだ。これは「複数のページに分かれているWebページを自動的に1枚につなげてくれる」というもので、これを使えば大抵のWebページにおいて、スクロールをしていくだけで全文が読めるようになる。

これは元々PC版のChromeやFirefoxでブラウザの拡張機能として作られていたものを、拡張機能に対応していないブラウザでも実現するために作られたものだ。ブックマークレットとして提供されているので、iPadのSafariでも問題なく使える。

PCでニュースサイトなどを見ている限りだと、たとえ1枚のページにつなげてくれたとしても、「ディスプレイで長文を読む」という行為そのものがボトルネックになっていたのだが、iPadでは長文を読むこと自体はまったくボトルネックにならない。文章を読んでいて「思考が途切れさせずに済む」というのは本当にありがたい。

・インストール方法

xAutoPagerizeのインストール方法なんだけども、PCであれば作者さんのWebサイトに行けば問題ないんだけど、iPadのSafariだと導入がちょいと面倒くさい。というわけで、iPadでもなるべく簡単にできるように、こちらのページにまとめておいたのでよかったらどうぞ。

・おまけ：xAutoPagerize＋PDF＋i文庫HDで腹がよじれる

もしAcrobatなどのPDF印刷ツールをインストールしている人がいれば、次の手順を試してみてもらえば、もう一度腹がよじれることが確実なので試してみるといいだろう。

・xAutoPagerizeで全てのページつなげる
・本文箇所だけをだーっとコピーしてテキストエディタなどに貼り付ける
・PDFに変換してi文庫HDで読む
・腹がよじれる

たとえば「全7回のインタビュー連載」みたいな数万字を超えるようなボリュームの文章でも、これで快適に読める。（この方法は、iPadに限らずKindleでも使えるんだけど、やっぱりサクサク感ではiPadに軍配が上がる。）

久しぶりにテレビをゆっくり見て思ったこと

Sun, 07 Feb 2010 11:32:56 +0900

普段はもうほとんどテレビを見ないんだけど、正月実家に帰ったときにゆっくり見る機会があったので、そのときに感じたことをダラダラ書いてみた。（「あのぅ、もう2月なんですけど・・・」というツッコミはなしで）

ネットにどっぷりな人間から見た、素直な感想という感じで読んでもらえれば。

・画質
地デジの画質がいいのに驚いた。最近はYoutubeなどのネット上の動画コンテンツも高画質なものが増えてきたなあと思っていたけど、地デジは段違いだった。50インチの大画面TVとか何が面白いんじゃい、と思っていたけど、地デジ＋50インチは確かに悪くない。女優とかアイドルがマジで涙目になるんじゃないかと思うほどの高画質だ。ブルーレイもそんな感じなんかのう。

・番組の作り方
番組の中でいちいち次の展開を説明してから先に進む、というのがすごく増えた。「次の瞬間、～が取った驚くべき行動とは！」みたいなやつ。要するに「どこが面白いのかを逐一解説しながら進む」というやり方ですな。「笑いどころを解説してあげる」という意味では字幕も同じようにウザイが、「番組の流れを止めてまでわざわざ解説してあげる」というのは字幕と違って無視できないので余計にタチが悪い。CMを入れるタイミングにしても、見ていてこんなにイライラするものはないと思うんだけど、作り手側も「これだけウザくしてもわざわざ見てくれる人」だけを相手にするしかないんだ、と腹をくくっているんだろうか。こんなことをしていても長期的にはテレビ離れを促進するだけだというのは分かっているんだけど、従来的なマスメディアには焼き畑以外の選択肢はない、ということなのかなあと思った。

・TV的な広告モデル
「シルシルミシル」とか「アメトーーク」の家電芸人とか、「CMとコンテンツが密接に結びついている番組（広告費をもらっているのかは分からないけど、特定の企業や製品に肩入れするという意味で）」は素直に面白かった。リクルートのビジネスモデル的というか、「単体ではただの広告にしかならないものでも、たくさん集めて編集してあげることで、コンテンツとしての価値が出てくる」というやり方がきちんと機能しているように感じた。録画機能がどんどん高度化していけば（全部のチャンネルを同時に録画できるレコーダーとかあるみたいですな）普通のCMはどんどん飛ばされていくようになるはずで、そうなると「コンテンツすなわちCM」という番組以外、広告モデルがまともに機能しなくなる気がする。

ただ、「コンテンツすなわちCM」方式は「いろいろありすぎてどれを選んだらいいか分からない」という状態になっている商材以外に適用するのは難しいか。（だとすると「Webサービス芸人」とかも出てくるんだろうか。「DropboxとSugarSyncの違いは～」「Gmailはメールアドレスに+の記号を入れると～」みたいな話が飛び交ったら面白いかもしれん。まあ今やったところで視聴率はまったく取れないだろうけど。。。。）

・その他
なんかの番組で「番組のtwitterアカウントはこちら！」みたいなのをやっていたのは驚いた。

電子書籍の世界で出版社や編集者は必要とされるのか

Sat, 30 Jan 2010 20:22:30 +0900

iPadが発表されたことで、いよいよ電子書籍の可能性がマジメに議論されるようになってきたようだ。今話題になっているのは、「出版社や編集者って必要なの？」ということらしい。「本」のサプライチェーンを考えてみると、「企画」「執筆」「校正・編集」「レイアウト・デザイン」「製本・印刷」「在庫管理」「営業（書店の売り場確保）」「宣伝」「読者の対応」だろうか。そして、今まで出版社や編集者が担ってきた「校正・編集」より後ろの工程のうち、電子書籍によって大部分が不要になってしまうのではないか、ということが問題になっている。おそらく「製本・印刷」「在庫管理」「営業」あたりは、電子書籍になれば全部不要になる。これははっきりしていると思う。

だとすれば残りの部分について、出版社や編集者がどの程度必要とされるのかということだ。おれも何冊か本を書いているので、編集周りの作業が非常に大変であることは、何となくではあるが知っている。

たとえばレイアウト。書籍では、節や章の切り替わりではページ送りが発生することになるが、編集者はページ送り時の余白がなるべく少なくなるように、スペースや画像の配置などをいろいろと工夫をしなくてはならない。（編集者側の努力ではどうしても余白が埋まらない場合は、「この節の余白を埋めるために、あと300字程度内容を追加してください」と著者に依頼することになる。）

また、「～ページを参照してください」というような他のページの参照箇所と、実際のページ数のつじつま合わせもかなり面倒くさい。書籍の執筆は初校、第二校、第三校というように進んでいくのだが、具体的なページ数が入るのはかなり後の方になってからである。また、いったん具体的なページ数を入れてしまった後では、ページがずれてしまうような修正（内容を追加したり削ったり）は基本的にできなくなる。参照と言うことでいえば、索引の作成なんかも地味に面倒くさい作業になる。

だから、こういった苦労をしてきた出版社や編集者からすれば、「印刷や流通が必要なくなったとしても、本を出すまでには他にもいろいろと大変な作業がいっぱいあるんだよ。それを著者だけで全部やれるわけねーだろ」という思いは当然あると思う。

でも電子書籍上では、ここで書いてきたような編集作業もほとんど不必要になってしまう。たとえば、レイアウトや余白を編集側では制御することはできなくなる。文字の大きさや行間、フォントの種類などは、すべて読者が自分に合わせて変えてしまうからだ。（今のKindleを見れば分かる。）文字の大きさが自由に変えられるということは、ページも自動的にずれていくため、相互参照の形もソフトウェアが自動的に調整する形になるだろう。また、索引も必要なくなる。電子書籍がテキストのデータを持っているのであれば、全文検索すれば済んでしまう。

つまり電子書籍では、「編集側の行為の一部が読者に委ねられる」という形になるわけだ。その結果として「編集や校正」という仕事の中身も変わってくる。（だから、電子書籍のオーサリングツールは、電子書籍ならではの都合を考えた機能を持たなければならなくなるだろう。たとえば相互参照をページ以外の単位で指定できる、など。）電子書籍の世界で出版社や編集者がどれくらい必要とされるのかは分からないが、少なくとも「レイアウト・デザイン」という工程は、紙の書籍におけるような重要性を持たなくなるという点から考えても、生き残りが大変になるのは確実なんじゃないだろうか。

上手なだまし方

Wed, 27 Jan 2010 23:40:49 +0900

「ネカマしたことあるやつしか分からないこと」になかなか面白いことが書いてあった。どうやって相手に「自分が女であると信じ込ませるか」についてだ。

男キャラで口調も男にする
↓
ある程度したらポロッと女っぽい発言をする
↓
そのうち実は女と言う
↓
完全にこっちのもん

で、それに対するレス。

わかるｗｗｗｗ
一回くつがえったものは二度とくつがえらないからなｗｗｗ

「一回くつがえったものは二度とくつがえらない」というのはなかなか面白いな、と思ってtwitterを見ていたらこんな話が。
http://twitter.com/rhenin/status/8272042223

『すまいろん』最新号より「一番大きいのは、分譲マンションの問題点が、住まい手に知らされていないということだと思います。…分譲の原価率は60％、タワーマンションになると45％くらいです。２番目はタワーマンションについて調べると、…流産死産の率が10階以上に住んでいる人だと38.9％

一瞬「おおっ？」と思ったけど、これもいくらでも疑える話だ。そもそも統計なんて見せ方次第というのは有名だろう。たとえば、「偏差値の高い大学に合格している高校生ほど食費が高い」というデータがあったとする。単純に考えると「高いメシ食わせれば成績が上がる」という結論になってしまうけど、「家が裕福」という原因があって、それが「教育にカネがかけられる→成績が上がる」という現象と、「食事にカネがかけられる」という現象につながっているかもしれない、とも言えるわけだ。だとすれば、貧乏人が無理して食事にカネをかけても成績は上がらないということになる。

高層マンションと流産率の話で言えば、単純に「高い階に住める→所得が高い→年齢が高い」という相関も考えられるし、あるいは「所得が高い→勤務時間が長い、不規則」みたいな相関もあり得る。さらに、高い階に住んでいる人ほど人数が少ないだろうし、それだけパーセンテージが跳ね上がることになるかもしれない。もちろんこれは仮説に過ぎないし、出典に直接当たらない以上何も言えない。ただ、「何も言えない」という意味では、「高層マンションって危険なんだガクブル」という態度も同じようにナンセンスだと言うことになるはずだ。しかし、「流産の可能性が跳ね上がる」というようなショッキングな話だと、どうしても「ホントかなあ？」という態度にはなりにくいかもしれない。

（ちなみに、その元データをWebで探してみると、次の2つが見つかった。
http://plaza.rakuten.co.jp/hhayashi/diary/200902020002/
http://d.hatena.ne.jp/flats/20090831
どちらもデータの出所は逢坂文夫氏（とその周辺？）ということになりそうだ。高層ビル自体がそれほど歴史が長いわけではないから、もちろん危険性は否定できないけど、この人たちの研究データだけでは何の結論も出せないよなあ。1つめのサイトでも「疑わしきは罰する、と意図で書いているんだ」と言っているわけだし。）

要するに「驚く」と「疑う」は両立しにくいということだろう。「疑う」というのは冷めていないとできないわけだから、いったん「ま、まじっすか！！！」と驚かせてしまえば、「おいおい、ホントかよ」という低いテンションにはなかなか戻らない。さっきの「一回くつがえったものは二度とくつがえらない」というのも、要するにびっくりさせることによって疑う気持ちを忘れさせるというやり方なのだろう。参考になるわぁ。（何のだ）

これはひどいGoogleですね

Sun, 03 Jan 2010 20:11:02 +0900

今金沢に帰ってきているのだが、片町（＝金沢市内の繁華街）を歩いていると、突然Googleの看板を発見。最近はテレビCMもやっているが、ついに町中に看板まで出すようになったのか、しかも金沢、と思ってよく見てみると、何かが違う。

本来のGoogleの看板（ロゴ）はこうだ。

で、おれが見かけた看板はこれ。

青色の「G」から始まって、赤、黄色、青・・・というような配色は同じだが、綴りがやや違うようだ。ちょっと通りがかっただけなので中を見ることまではできなかったが、この写真をよく見ると（分かりにくいかもしれないが）左上に「KATAMACHI 無料案内所」と書いてある。繁華街で無料案内所と言えば、おそらく観光客などを「楽しいお店」に案内してあげて、その代わりお店から紹介料をもらう、というようなビジネスモデルのアレだろう。

考えてみれば、Googleもインターネットの無料案内所であり、お金をくれたサイトを優先的に紹介してあげるというビジネスモデルなわけだから、まあおんなじと言えばおんなじようなものかもしれませんな。ネットのことをよく知らないおじさんに「リスティング広告ってなんだ？」って聞かれたら、「温泉街にある無料案内所みたいなやつですよガハハ」と説明しとけば分かってもらえるかもしれん。余計分からんか。

某サービスのセキュリティホールについて

Fri, 11 Dec 2009 23:05:02 +0900

「おい、今度の新サービスにはちゃんとCSRF脆弱性入れておけよ」

「えっ、どうしてですか」

「ヤツが必ずやってくるはずだ。『こんにちはこんにちは』が広まれば必ず話題になれる」

「でも、そんなことしたら我々の技術力が疑われるんじゃ・・・」

「大丈夫だ。そんなコムズカシイ話が分かるやつはとっくにtwitterを使っている。我が社のサービスの客層を考えろ。いざとなったら被害者ヅラすればいいんだ」

「分かりました」

・・・というやりとりがあったかどうかは知らない。

SQLObjectでRDB以外を使えるようにがんばるの巻(1)

Mon, 30 Nov 2009 23:53:48 +0900

最近はほとんどのWebアプリをPythonで書いていて、O/RマッパーはSQLObject 0.8を多少改変したものを使っている。（変更点としては、マルチプロセスあるいは複数台のAPサーバーで使えるようにキャッシュ機構を変えたり、あるいはリレーションの仕組みなどはそのまま使えるようにしつつテーブルごとに別のDBサーバーを指定できるようにしたりといった感じだ。）

データストアは基本的にはRDBでいいと思っているんだけど、これから大規模な（パフォーマンス要件が厳しいという意味での）アプリを書くことが増えそうなので、それであればやはりKVSにも簡単に対応できるようにしたくなってくる。もちろん、keyとvalueを放り込むだけのシンプルなKVSを使うだけであれば特に何も考える必要はないと思うんだけど、Google App EngineのデータストアやTokyo Tyrantなどは、検索機能についてもRDBにかなり近い感じで使えるようにしてくれている。joinなどはとっくの昔に使っていないので、あとはRDBとKVSの大きな違いといえばORが使えないくらいと言っていい。だとすれば、SQLObjectをそのまま使えるように出来れば、必要に応じてデータストアを簡単に切り替えられることになる。追加や更新、削除あたりは簡単に切り替えられそうだが、問題になるのはやはり検索だろう。SQLObjectでの検索の記法は直感的で非常に使いやすいので、それを何とか継承したい。というわけで、しばらくはこのあたりの変更のログ代わりにブログにまとめていこうと思う。

まず、SQLObjectでの検索時の記法についてまとめていく。たとえばnameとageというフィールドを持つPersonというモデルがあって、その中からAgeが30以上のレコードだけを取得したければ次のような感じで書ける。

for person in Person.select(Person.q.age < 30):
print person.name

ここでポイントなのは、条件として「Person.q.age > 30」みたいな記述をそのまま渡せるところ。普通に考えれば、「a > 30」というように書けば、boolが返ってきそうな気がするのだが、そうではない処理がされているというわけだ。これはPythonの機能である比較演算子のオーバーライド（演算子といえばオーバーロードじゃないかという気もするけど、別に引数の型が関係するわけではなくて、サブクラスで上書きするだけだからオーバーロードではない）で実現されている。要は、クラスを定義するときに、__lt__などのインスタンスメソッドをオーバーライドすることで、比較の動作をカスタマイズできるということだ。たとえばこんな感じのコードが書ける。

class Person(object):
     def __init__(self,name):
          self.name = name

     def __lt__(self, other):
          return self.name +"（自分）と"+ other.name + "（相手）との比較"

p1 = Person("山田")
p2 = Person("鈴木")

#「山田（自分）と鈴木（相手）との比較」という文字列が表示される
print p1 < p2

#表示されるのは「<type 'str'>」
print (p1 < p2).__class__

最後の一文を見れば分かるように、「<」を使った比較であるにも関わらずboolではなくてstrを返している。SQLObjectを使って検索時に「Person.select(Person.q.age > 30)」というような書き方ができるのは、この仕組みを使っているわけだ。

じゃあ具体的なクラスの構造はどうなっているのか。SQLObjectではモデルのクラスにおいて、各フィールドに対応した「Person.q.age」といった変数が自動的に生成されるが、これらはSQLObjectFieldクラスのインスタンスになっている。そして、SQLObjectFieldの親クラスを辿っていくと、Field->SQLExpressionとたどり着き、このSQLExpressionクラスでほとんどの演算子がオーバーライドされていることが分かる。そして、SQLExpressionクラスでの演算子の戻り値は、SQLExpressionクラスのサブクラスであるSQLOpになっている（うーん、ややこしい）。そして、このSQLOpクラスが検索条件のセマンティックスを表現しているようだ。あとは、SQLOpクラスのインスタンスを使って、データベースに合わせたSQLのシンタックスが生成されるというわけである。とりあえずこの辺りに着目すれば、SQLObjectの検索記法からGQLを生成するくらいなら割と簡単に行けそうな気がしてきた。とりあえず今回はここまで。

Kindle届いたぜ

Fri, 30 Oct 2009 01:07:34 +0900

うっかりKindle買ったったので、そのレポートを書きます。Kindleというのは電子ブックリーダーという感じですな。いわゆる「電子インク」というヤツを採用していて、画面を表示しっぱなしでも電力を消費しない（切り替えの時しか電力を消費しない）という仕組みになっているので、軽くて薄い上に、長時間使えて視認性も高いというシロモノなわけです。日本円にして、送料込みで3万円弱。日本語対応していないということだったので、ちょっと迷っていたのだけど、Web上でのいろいろなレポートを見ていて、自分がやりたいことはできそうだと感じたので、思い切って購入してみた。

注文したのが26日深夜で、家に届いたのが29日16時なので、日本で注文したものがアメリカから発送されてくるのに3日かからなかったということである。UPS仕事早すぎだ。

それで、どういう使い方を想定したのか。それは「紙の書籍を少しでも減らす」という使い方である。オフィス撤収のついでに、自分の部屋も改めて整理しているのだが（仕事スペースも確保したいし）、やはり本が一番場所を取ってしまうわけである。本を処分する方針として、次の2つの作戦で行くことにした。

・もう読まないであろう本はイーブックオフにどしどし送りつける（着払いで送ると勝手に処分してくれるサービスがあるのだ）
・残しておきたい本はスキャンして電子化してから捨てる

大量にスキャンしようとすると大変そうだが、ScanSnapというすんばらしいスキャナを使えば、1ページあたり2、3秒程度でどしどしスキャンできる。素手で本をバラしたとしても1冊10分程度で作業完了だ。しかも、付属しているAdobe AcrobatのOCRを使えば、画像から文字データを抜き出すこともできるので、検索したり、マーカーを引いたりすることもできるようになる。

そうすると残る問題は、スキャンした本をどうやって読むのか、ということである。今は、昔買ったピュアタブレットPC（NECのVersa Pro）を使って読んでいる。これも悪くはないのだが、さすがにバッテリーも劣化していて1時間と持たない。あと、いくら軽いと言っても885gでは、さすがにいつでも持ち歩くというわけにはいかないのだ。

そこでKindleの登場だ。Kindleであれば重さは289gで、バッテリーも5日は持つというから「とりあえず持ち歩いておく」ということができそうだと思ったのだ。日本語に対応していないと言っても、そもそもスキャンした画像データを読むのだから、問題は「PDFを簡単に読めるのかどうか」ということだけなのである。PDFを直接読むことはできないが、何らかの形で変換できれば問題なしというわけだ。

ああ、前置きがすっかり長くなって使用レポートどころじゃねえ。詳しい使用レポートはまた改めて書くことにしよう。とりあえず写真だけ何枚かアップしておく。

まず全体像の写真。

次にちょっとアップにしたところ。今写っている画面はいわゆるスリープ用の画面だが、半端ない解像度であることが分かる。確かに紙に近い見た目という言い方もできる。

あと大きさ。iPod Touchと並べてみた。だいたい横にしたiPod Touch3つ分といったところか。

最後に薄さ。iPod Touchとほぼ同等と言っていい。携帯性という意味では十分に合格点だろう。

あとは、これでスキャンした書籍を快適に読めれば最高なのだが、どうだろうか。待て次号！

めふめふにしてやんよ

Fri, 02 Oct 2009 19:34:52 +0900

マイコミジャーナルで書かせてもらった小連載の最後がアップされました。今回のテーマはMEF、Management Extensibility Frameworkです。

Beta版で試す! VS 2010と.NET 4.0の新機能(3) - MEFの機能と使い方

.NET Framework 4.0の新機能のうち、ぱっと見た感じで最も分かりにくいのはMEFなんじゃないかと思う。一言でいえば、「面倒くさくないDI」といったところだろうか。もちろん（本文でも触れているが）DIを目指した仕組みではなく、あくまで「拡張性を確保するためのDI的な仕組み」といったところだろうか。

いずれにせよ、インターフェースだけを先に決めておいて、実行時に具体的なクラスを決定する、という仕組みとしては、非常に簡単に使えるようになっていると思う。ちょっととっつきにくいかもしれないけれど、サンプルコードも添付しているのでさらっと読んでみていただきたい。

オフィス絶賛撤退中

Thu, 01 Oct 2009 02:19:35 +0900

勢いで借りてみたオフィスだったけど、結局あまり活用できてないので、このままムダ金使うのもどーなんだ、というわけで撤収することにした。仕事をする場所は自宅＆近くのスタバというパターンに戻ることになりますな。そもそもまだ事業として体をなしてないのに、オフィスなんて必要ないんだよな。そんなこと今更気づいたのかよ！と言われるとぐぅの音も出ませんが。どこぞの軍隊の台詞を借りれば「戦略的前進」というところであります(´・ω・`)

引っ越しの準備は先に済ませてしまおう、ということで机もすべて運べる状態にバラしてしまった。じゃあどうやって仕事すんだ、という話なのだが、そこは一時的な超前衛的オフィスを構築したので問題ない。現状はこんな状態だ。

まさに専用ブース。

これはさすがに狭いんじゃ、、、と思う人もいるかもしれないが問題ない。ブースのすぐ横にちゃんとものを置くスペースも確保済みである。

あれ、そういえば机はバラしたんじゃないの、と思われた方もいるかもしれないが、心配無用だ。これは本棚である。

横から見るとこんな状態なのだ。光を取り入れるための一工夫などは、我ながらすばらしいの一言に尽きる。

以上の写真から、超前衛的オフィスで戦略的前進中であることがお分かりいただけたと思う。

今月でオフィスは撤収するけど、「ゼロから新規事業を作っていくこと」の面白さと難しさがようやく分かってきたところなので、「学習＆教育」という領域で引き続き勝負していきます。よろしくー。

F#超入門の記事

Wed, 16 Sep 2009 10:39:45 +0900

前回に引き続き、マイコミジャーナルでVisual Studio 2010の小連載2回目が掲載されました。今回は関数型言語なんかほとんど知らん！という人向けへのF#入門の記事になっとります。

Beta版で試す! VS 2010と.NET 4.0の新機能(2) - 関数型言語F#と、C#の強化点

C#は、バージョンが上がるごとにいろいろな仕様が追加されている。匿名デリゲート、ラムダ式、あるいはvarによる簡単な型推論などだ。ただし、それらの追加仕様は基本的に関数型言語を参考にしているものばかりである。だからF#を使うかどうかはいったん置いておいても、ここらで一発関数型言語を一通り使ってみることは、決してムダにはならない。

今回は、なるべく「関数型言語的な用語」を使わずに、C#やVB.NETをメインで使っている人向けに、F#の面白いところをダイジェスト版で書いてみた（最後にC#の動的型付けとタプルについても書いた）。そんなに気合いを入れなくても、サクッと読めるようになっているので、ぜひ読んでみてくださいまし。

[補足]

F#の記事内容に突っ込みをもらったので補足しておきます。

この記事では、「束縛」という用語はほとんど使わずに「代入」という用語で説明している。というのは、短い記事で「関数型言語そもそも論」をやってしまうと、関数束縛って何よ？みたいな話も必要になってしまい、「やっぱりよくワカンネ」と思われるかなあと思ったからなのです。

（入門記事において、どこまで正確な説明に徹するべきかということについては、「頭のいい人は、難しい概念も簡単に説明できるはずだ」問題についてあたりでも書いたように考えています）

それで、この記事の範囲では「束縛」＝C#における「代入」と考えてもらってもたいした問題ではないので、最初だけ「代入（束縛）」という書き方をして、後は代入という用語で書いてみたのです。これは本文中でも補足しておくべきだったかもしれないですね。

というか今からでも修正をお願いするか。。。

Visual Studio 2010の小連載始まりました

Wed, 09 Sep 2009 21:56:33 +0900

mycomジャーナルでまた記事を書かせてもらいました。今度のテーマはVisual Studio 2010 & .NET Framework 4.0でございます。

Beta版で試す! VS 2010と.NET 4.0の新機能 - (1)ASP.NET Ajaxにおけるクライアントサイドレンダリング

タイトルが「(1)」となっていることからも分かるように、単発の記事ではなく全3回でお送りします。1回目のテーマはASP.NET AJAXになっているけど、あと2回はそれぞれ違ったテーマの記事。全体を見渡してみて、目を引きそうなところをピックアップしてみたつもりなので、エンジニアのしとはチェキってみてくだされ。初めは1回で完結する予定だったのだけど、さすがにそのボリュームでは本当に概要をちょこっと書くだけで終わってしまいそうだったので、3回分にワクを増やしてもらったのだ。

しかしASP.NETとかどんどん進化しているが、ちゃんとついてきてくれている人はどれくらいいるんだろう。。。.NET開発系の記事を書くとき、どのくらいのレベル感を想定すればいいのかはなかなか難しい問題でありますな。

Windows 7とWindows Azure触ってみた

Sun, 06 Sep 2009 10:09:10 +0900

ふと思い立って、Windows 7とAzureを触ってみた。

7の方は、ダウンロードしてあったRCを余っていたLet's Note T5に入れてみた。こいつはメモリが1GB、CPUがCore Solo（Duoじゃないですよ） 1.06MHzというスペックなので、これでマトモに動くようなら、次は7を入れてもいいかなあ、と思ったわけだ。

で、結論としては問題なく動いている感じだ。もちろんXPに比べればちょっと重い感じはあるが、一応満足できるパフォーマンスと言える。これならマシンのスペックさえマトモであれば、サクサク動くことが期待できそうだ。

また、7自体の使い勝手もよくなった。特にタスクバーは相当いい感じだ。Vistaのフリップ3Dはすばらしく無意味な機能だったけど、「ウィンドウごとに画像バッファを持つ」という技術が、今度こそはうまく使われている気がする。個人的にはMacのExposeよりいいんじゃないかと。

互換性もいい感じだ。T5はVistaに対応しているので、サウンドカードやタッチパッドのドライバはVista用のものを使ってみた。ダウンロードしたファイルを実行しようとするとエラーが発生したが、Windows 7の「自動パッチ当て機能」（正式名称知らん）のおかげで問題なく実行できて、タッチパッドもサウンドカードもちゃんと使えるようになった。

あとは、そのままVisual Studio 2008の評価版を入れて、Azureも試してみた（AzureのプログラムはXPでは開発できないらしい）。CPUパワー不足でVS 2008 SP1のインストールに3時間くらいかかったのはさすがに勘弁して欲しかったが、とりあえずHello World程度のものはさくっと動いた。VSからAzureに発行できる機能もあったりして、なかなか期待できる感じだ。とりあえず作ったのはこれ。まあテキストボックスに文字を入力して、ボタンを押すとラベルが変わるだけのものなのだが。

http://uru.cloudapp.net

端から見ていて、ぶっちゃけMSはここ3年くらいは冴えない感じだったが、7とAzureはいい感じになっていると思う。GoogleもWaveとかOSとか出してくるみたいだし、これからいろいろまた盛り上がるといいですなあ。

「友愛」がヤクザ的概念かどうか調べてみた

Tue, 01 Sep 2009 12:58:47 +0900

最近「友愛」というキーワードをよく見かけるようになった。とは言っても、今の政治について語れるだけの知識があるわけではないので、例によって語源とか翻訳とか、そういう話です。

友愛というと、「自由・平等・博愛（友愛）」みたいな感じで使われることが多いようだ。ただ、ふと思ったのは塩野七生が「自由・平等・博愛と訳されることが多いけれど、博愛というよりは同志愛といった方がいいのではないか」ということをどこかで書いていて（ソースは忘れた）、それでちょっと気になって調べてみたのだ。

まず国語辞書で博愛と友愛を調べてみると、こんな感じだ。

博愛
すべての人を等しく愛すること。

友愛
兄弟間の情愛。また、友人に対する親しみの情。友情。

友愛が身内向けなのに対して、博愛の方は「全人類を分け隔てなく愛する」というニュアンスのようである。（確かに博愛主義者というと、キリストみたいなイメージがピッタリ来る。）やはり博愛と友愛は全然違う意味ということになりそうだ。

じゃあ「自由・平等・博愛」って元々は何を訳したものなんだろうか。これまた調べてみると、どうやら「liberté égalité fraternité」らしい。そして、これを英訳したものが「liberty equality fraternity」というわけだ。ということで、この「fraternity」を辞書で調べてみると、「兄弟の間柄［情愛］; 友愛団体; 同業［好］者仲間; 〔米〕男子学生の同好会 ((cf. sorority)).」となっていて、結局ニュアンスがはっきり分からない。今度は英英辞典でfraternityを調べてみると、「a feeling of friendship between members of a group」となっている。訳すとすれば「グループのメンバーに対する愛情、友情」とでもいったところだろう。塩野七生が書いていた「同志愛」というのはこういうことみたいですな。要は「お兄ちゃんはヤクザだけど妹の私には優しかったんです！！」みたいな感じで、やっぱりちょっとヤクザっぽい感じ。

ついでに、自由が「liberty」になってるけど、「freedom」とはどう違うのかも調べてみた。
・freedom
the right to do what you want without being controlled or restricted by anyone

・liberty
the freedom and the right to do whatever you want without asking permission or being afraid of authority:

こちらの方はそれほど大きな違いはないが、libertyの方が「permission」とか「authority」が関係している分、より政治的なニュアンスが強いように思える。これと友愛のニュアンスを含めて考えると、「自由・平等・博愛」というのは理想やキレイごとではなくて、もっと血なまぐさくて暴力的な「革命スローガン」だったのかもしれんね。まあフランス革命って処刑とか粛正とか、そんなイメージしかないのだが。