JSの設定

2012年12月30日日曜日

who knows what が英語のわけ

http://welself.blogspot.jp/2012/11/blog-post_26.html
ここにも書評があるが、『世界の経営学者はいま何を考えているのか』を立ち読みした。
個人的には、「組織の記憶力を高めるためにはWhatよりもWho knows whatが大事」というトランザクティブメモリーの話や、イノベーションを起こすための「知の探索と知の進化の両利きの経営」といったトピックは、いまの会社の経営にも参考になり、とても面白かった。
とブログに書いてあるが、トランザクティブメモリーをもうちょっと詳しく説明すると{知識そのものよりも「誰が何を知っているか」に関する知識が重要}ということである。自分に各専門分野の知識が足りなくても、ある問題を聞いた時に誰だったらそれを解決できそうか分かるならば困ることはない。

しかし本稿で注目するポイントは経営論ではなく、どうして日本語で書かれた本にWho knows what という英語表現が出てくるかである。簡単に言えば、前述の説明に登場した「誰が何を知っているか」という文章を構成している「」を省略する役割を持っている。※1
つまり次の2つの文章は同じ意味である。

A:<知識そのものよりも「誰が何を知っているか」に関する知識が重要>
B:<知識そのものよりもWho knows what に関する知識が重要>

「」を使った文章をAタイプ、英語を使った文章をBタイプと呼ぶことにしよう。
Bタイプの利点は、日本語の文章全体をパッと見た時に英語部分が明らかに異物であるために、どこからどこまでが異物なのか範囲が明確なことである。Aタイプでは「」の中身も日本語なので、カッコのどちらか一方を見落とせばその中身は簡単に外側の日本語と混ざり合ってしまう。上記ではカッコの中身が短いからまだいいが、長いとカッコの始まりと終わりを見つけるだけで大変な作業である。

同様の例は他にもある。例えば物理の公式。以下はブラッグの法則と言われるもの(説明のために少し形を変えてある)。
sinθ=nλ
注目すべきは、ギリシャ文字が含まれていることである。θはシータ、λはラムダと読む。私たち日本人にとってアルファベットですら異物なのに、さらに異物のギリシャ文字を使うのは何故か。そのメリットの1つは、やはり「周囲と混ざらない」ということである(単純に、使える文字が増えるというのも勿論ある)。

上記の式を敢えて日本語で読むと次のようになる。
”シータのサインはエヌとラムダの掛け算に等しい”
もしギリシャ文字を使っていなければどうなるか、例を見よう。
sing=no
θを”g”に、λを”o”に変えただけなので、当然次の意味になるべきである。
”ジーのサインはエヌとオーの掛け算に等しい”

しかし”sing=no”を見てこの読み方ができる人はいないだろう。
どう見ても”歌う=ダメ”なのだから。gやoは完璧に周囲と混ざる例であったが、式全体をパッと見た時に全ての文字が同一文字種(この場合アルファベット)で出来ていれば、人間の目はまずそれを何らかの単語として見るのである。gやo以外の、混ざるか混ざらないか微妙なアルファベットを使った場合はギリシャ文字と同様の読み方ができるかもしれないが、それには「何らかの単語として見るのが失敗する」という不快な出来事を乗り越える必要がある。

この無駄がなくなるため、意味の塊を異物で表記するメリットがある。閾値のことをThresholdと言い換えても意味はほとんど同じであるが、それでも日本語の中に異物を登場させることにより「そこにキーワードがある」という事実を強調する役割はある。ただ逆に言えば、文脈においてそれがキーワードではないのに恰好つけるために異物を混ぜれば(文章全体の見通しを損なう)ノイズにしかならないということである。従って、無条件の恰好つけと無条件の異物嫌悪はどちらも避けるべきである。

※1
Who knows what は、それがキーワードだけで出来ているのも利点である。「誰が何を知っているか」と書いた場合、意味の大部分を成すのは「誰」「何」「知」の漢字3文字であり、残りのひらがな7文字は余分である(※2)。余分な文字の数が(10文字から成る)文章全体の7割を占める点でこの文章は全体の見通しが悪く、そこへ行くとWho knows what は優れている。


※2
ひらがな7文字が余分というのは、日本語が英語より劣っていることを意味しない。小回りが利く言語は時に表現が冗長だということである。Who knows what という3ワード文は、それ単体で「誰が何を知っているか」より細かいニュアンスを表現できる可能性は低いだろう。しかし「Who knows what の詳しい説明」=γなどと定義して、それ以降の文ではγを使えば「誰が何を知っているか」と書く以上に表現力は高い(かつ、『世界の経営学者はいま何を考えているのか』全体を通してγが頻出するのであれば、筆者にとって書くのがだいぶ楽になり読者にとっても見通しが良い)。

そう考えるとWho knows what を使うことは、γを使うよりワード数が少し増えるものの、パッと見て定義を思い出しやすいという利点を持つ。そういう戦略なのだろうと考えることができる。




2012年12月26日水曜日

言葉はすべて実用世界の住人である

感謝、敬意、挨拶など、世間一般で大切と言われているのに、それがどうして大切なのか説明するのが難しい言葉がある。説明が難しいとはどういうことなのか示すために、説明が簡単な例を取り上げよう。スプーンの使い方、お金の概念、歴史、我慢すること。これらが大切な理由を説明することは簡単だろう。

説明が難しい概念をD(difficult)群、簡単な概念をE(easy)群と呼ぼう。説明が難しいのに子供の頃から身につける必要があるD群は、それを習慣化させることによって親から子に伝承されるのが普通である。年上の人は敬いなさい、いいことをされたら感謝しなさい、人に会ったら挨拶しなさいという具合に、なぜそれをする必要があるのか説明されない。

これにはいくつか利点がある。第一にD群の内容は難しいので、うまく説明できない可能性が高い。説明しなければ、少なくとも間違った説明を相手に教えてしまうリスクがない。第二に、うまく説明できたとしても、D群の正確な説明文は難解なので相手に相応の読解能力がないと理解してもらえない。第三に、仮に難解な説明文を相手が理解してくれたとしても、習慣化されていない行動はいざという時に発動しない恐れがある。

しかし本稿では、中学生にも高校生にもD群の説明が与えられないことに対する欠点を指摘する。僕自身、日常世界の全概念がD群とE群に分割されていることに気持ちの悪さを覚え続けてきたからである。もう少し正確にいえば、D群があたかも説明不可能なもののように扱われているのが気持ち悪く、その気持ち悪さを周りの人は感じていないように見えるのが僕を不安にさせたということだ。

今考えてみれば、当然D群は実用世界の言葉として説明可能である。
例えば「東京駅」と比べて「こんにちは」は文言としてあまり意味がないように感じられるが、実際使ってみれば意味があるわけである。共通の、TPOに即した話題がすぐには思い浮かばない程度の相手に対して、変に思われない発声ができるとしたら挨拶以外にない。声を聞かせ、返事を聞くことによって生物学的な情報を交換し、その情報を土台にして次の発言に必要なステップを小さくできる。

上記は「挨拶」の説明文である。「挨拶したほうが気分いいじゃん」という簡明な文によって挨拶の大切さを説明することもできるが、気分がよいのは経験的に挨拶後の気分の良さを知っている常識人にとってだけであって、気分がよい経験をしたことがない(もしくは経験したことがあっても、”こんにちは”の「文言としての意味のなさ」に対する失望感が、気分のよさに勝ってしまう)人にとってその簡明な説明は受け入れがたい。

「今は何で大切なのかよく分からないけど、大きくなれば分かるだろう」とスルーできる子供は常識的に見て確かに賢い。しかし、そうでない子供もたくさんいる。難解な説明文がもし理解できなくても、それが参照可能なところにあることを知るだけで安心するはずである。なぜなら、大切とされていることに理由がなくて周囲の大人も分かっていないのなら、自分が大きくなっても分かると思えるはずがないからである。

また、子供の悩みを緩和するという側面の他にも、D群の言葉を実用世界のものとして説明することは意味がある。つまり、実用上の意味が分からないまま大人になり昔の習慣を軽視するようになると、その概念は簡単に元に戻ってはくれないのである。例えば日頃の感謝を忘れることは大人の世界では日常茶飯事であるが、これは”感謝”の説明文があれば起こりにくいと思われる。

感謝とは、{「相手が何のために何をしたか」を自分が認識している、という事実 }を相手に伝える行為の一種である。自分が何を認識しているかを伝えることはコミュニケーション上重要である。その情報があれば相手は自分のことをより理解して行動してくれるようになるのだから。

感謝の意味はもちろん、そのように単純なものだけではない。
例えば、そもそも相手に関する認識を伝えるためには「相手」という1つの外的世界を理解する必要があり、感謝する相手や対象が増えることは「自分が理解している外的世界が増える」ことを意味する。それが内的世界の理解につながることもあるだろう。

このように色々な物事に対する理解が深まることは確かに良いことではあるが、いま主張したいことは「実用的な意味のない言葉はない」ということと「言葉の意味は、その実用的な側面から順番に教えよ」ということである。「言葉はすべて実用世界の住人である」ことを明確にすることによって多数の子供は安心し、多数の大人は大事なものを失わずに非実用的な価値を積み重ねていくことができるだろう。


2012年12月15日土曜日

決断力はどれくらい偉いのか

僕は以前から、決断力という言葉に違和感を覚えていた。
例えば誰かに「100円か500円どちらか好きなほうあげるけど、どっちがいい?」と聞かれて迷う人っているんだろうか。ほとんどの人は500円と即答するだろうし、
万が一「500円もらったら可哀想だ」と考える人がいるとしても(500円ほしいという欲望に打ち勝つために普通の人より時間はかかるであろうものの)そんなに迷わず100円と答えるだろう。つまりこの質問に答える場合は決断力の出番がない。

では夕飯のメニューを決める場合はどうだろう。カレーにするか、ステーキにするか。
どちらも好物なら迷うだろう。どちらも久しぶりなら迷うだろう。一日の栄養バランスを考えなければ迷うだろう。しかし逆にいうと「A:一方だけが好物」か「B:一方だけが久しぶり」か「C:一方だけが一日の栄養バランスを満たす」ならば迷いにくい。

つまり決断力があるように見える人とは、次のXタイプとYタイプがいるのである。
Xタイプ:選択肢の中からランダムに行動を選ぶのが速い人
Yタイプ:A・B・Cなどいずれかの前提を、カレーまたはステーキのどちらか一方に決める十分な理由として信じられる人

500円を選んだ時は「100円より500円もらったほうが得という前提を、500円もらうことにする十分な理由として信じた」のであり、これはYタイプと同じである。また、この例では決断力の出番はなかったのだから、Yタイプは決断力を使っていないことになる。それでもYタイプは「決断力があるように見える人」なので世間的には決断力がある人と言われる。

僕が感じた違和感はそういうことである。決断力が、印象通りのカッコいい言葉だとするならば、XやYの能力はカッコいい決断力だとは評価しにくい。ここから、決断力に本来の地位を取り戻させるためにもう少し突っ込んで考えてみる。

Yタイプに属する人「Y1」は、「A1:カレーが大好物(肉は普通)」であるとしよう。Y1は夕飯をカレーに決める理由として、A1を十分なものとして信じた。しかしハッキリ言って、ただ1度の夕飯のメニューなんてカレーでも肉でも問題はない。だからあまり真剣に考えなくても(A・B・Cを総合的に比較検討しなくても)信じることができる。

では、自分の将来に重大な違いを与える選択肢から選ぶ場合はどうだろう。例えば会社Nと会社Mから就職先を選ぶとする。Nに可愛い子犬がいたからといって、それを十分な理由として信じられる人はまずいない。Nの給料がMの給料より高ければどうか?この場合は子犬より魅力的かも知れないが、それだけでNを選ぶ十分な理由になるかは人によるだろう。

それだけで十分な理由になる人は、そうでない人より決断力が高いのだろうか。
重大事なのに総合判断をしていないという意味で、前者の選択は常識的に見て軽すぎる。
だからこれはカッコいい決断力ではない。では、MよりNが優れているという総合判断をそれぞれ独自に行なった2人の人物PとQがいたとして、Pは自分の判断を信じて入社を決意するのに3時間かかり、Qは一週間かかったとしたらどうか。この場合、PはQよりカッコいい決断力があるように見える。

しかし、そう決めつける前に2人の総合判断の内容を比較しなければならない。Pの判断が常識的に見て軽すぎない内容であるならば、3時間という数字はやはり常識的に見て小さいのでPには一般的決断力があると見てよいだろう。しかしQがPより決断力が鈍いかどうかは分からない。なぜならQは、Pより多くの事実を確認・比較し自分のニーズとよくよく照らしあわせて決めたかもしれないからである。そうであればQはPより、Nという会社に対して適性がある可能性が高い。すると急に、Pの一般的決断力が色あせて見えてくる。

色あせて見えたので、やはりPの決断力はカッコいいタイプではないようだ。
ではQはカッコいい決断力を持っていたのか?PとQは総合判断の内容が違っていたので、比較することができない。一週間という数字も、常識的に見て長いのか短いのか分からない。そこで、Qと似ている別人Oを用意しよう。彼もQと同様に独自に総合判断を行い、しかもQと同等の深い検討をしたとする。また同様に「自分が入社する対象としてMよりNが優れている」という結論を下した。

OもQと同様に一旦はその結論の正しさを信じたが、「部分的にNよりMが優れている点があるのも確かだし・・・」と迷い始めた。迷って迷って、三週間かけて入社を決意したとする。この場合、Oの迷いは女々しいだけであるからQより優れている点が何もない。とりあえず他者との比較によって、カッコいい決断力を持つ人物の存在が確認された。

ここに至り、我々はYタイプをさらに分類する必要性を知った。
Yタイプ:A・B・Cなどいずれかの前提を、カレーまたはステーキのどちらか一方に決める十分な理由として信じられる人

Yαタイプ:しょうもない理由でもその正しさを信じられる人
Yβタイプ:理由の正しさを十分に検証する姿勢を持ちながら、その検証をパスした結論を実行に移す覚悟が迷わず出来る人

つまり本当の決断力を持っているのはYβタイプである。そして僕は「(相談やチェックリストなどの方法も使いつつ)自分を騙さず、十分に検証した結論が一旦出たと思ったならば迷わずそれに従うという"心の中の取り決め"」が即ち決断力の正体であると主張する。

これによって一応は「"決断力"に本来の地位を取り戻させる」試みは成功したと考えるが、それでもやはり以前から感じていた違和感も妥当なものだと思う。なぜなら決断力は、単に上記のような"心の中の取り決め"に従うだけで行使したことになるからである。決断力という言葉が持つ世間的なカッコ良さはそれを行使するために必要なエネルギーが源泉だという印象があるが、これは一概に正しくない。十分な検証を行うのにエネルギーが大量に必要なことは確かにあるが、ほとんど必要ないことも多いからである。

経験や学習は、A・B・Cなどの前提を導き出し、それらを総合的に比較検討する速度と正確性を上げる方向に作用する。だから、経験や学習によって十分な知識を得ている人はそうでない人より決断力が上がるのである。知識の補助を得て為される決断はカッコいいタイプではあるものの、大したエネルギーは使わない。

一方「"心の中の取り決め"に迷わず従おうとしても躊躇せざるを得ない」ような重大な責任を伴う行為については、いくら知識の補助があっても大量のエネルギーが必要である。そのようなエネルギーを惜しげなく出すことが正真正銘の決断だと思うので、そこらへんに転がっているカッコいいタイプの決断を「決断」と呼ぶことに違和感を禁じ得ないのである。


2012年12月7日金曜日

URLは偉大だ

ウェブシステム開発の話をしたので、その中で感じたことを追加で書いてみよう。
開発パートナー会社や他部署の関係者と新しいサイトに関する取り決めを話し合っていくとき、もれなく使うコミュニケーション補助ツールがある。Redmineというウェブシステムで、これは簡単に言うとインターネット掲示板の進化形である。

下記はデモ用のサイトであり、テーマごとにスレッド(掲示板の最小単位)が立てられている。掲示板の世界でスレッドと言っていたものが、Redmineではチケットと呼ばれる。
https://my.redmine.jp/demo/projects/demo/issues

(ちなみに掲示板スレッドとはこんな感じのものである)
http://ikura.2ch.net/expo/#1

並んでいるチケットのうち、「アップデート手順の改善」というものをクリックしてみよう。するとチケットの内容が表示される。
https://my.redmine.jp/demo/issues/2587

「説明」と書いてあるところがチケットのテーマである。決めるべきテーマを誰かがチケットとして提示し、提示された者が返信し、やりとりを繰り返すうちに決定事項がでてチケットのステータスが終了となる(※)。こういったやりとりはメールでも行うことができるが、時間がたってから一部を引用しやすいのがRedmineの特徴である。

例えば下記のURLをクリックすると、先ほどのテーマAに対する1つ目の返信がピックアップされる。これは「良いんじゃないでしょうか」と書いてある欄の右方にある「#1」のリンク先URLである。
https://my.redmine.jp/demo/issues/2587#note-1
同様に、2つ目の返信は次のURLで示される。
https://my.redmine.jp/demo/issues/2587#note-2

時間がたってから一部を引用しやすいというのは、上記のようなURLにより文章をピンポイントで指示できるということである。例えば、先のチケットにおける決定事項とそこに至る経緯を忘れた頃に、開発パートナーとやりとり(チャットなど)をしていてテーマAに関する情報を相手に示す必要に迫られたとしよう。この場合、テーマ名などのキーワードによりRedmineの中を検索し、まず先ほどのチケットを見つける。次にチケット上のやりとりを見て、相手に示したい情報が含まれている箇所を見つける。その右方にある「#数字」部分のリンク先URLを拾えば、あとはチャットにそれを打ち込むだけである。

もし初めにRedmineではなく電子メールでそのやりとりをしていたなら、引用部分をURLで指示することができない。何月何日のメールでやりとりをした件・・・と言うことはできるが、相手方にもそのメールが残っている保証はなく、残っていても相手がそれを検索する手間がかかる。チケットのケースでは、検索をしたのは一人だけである。またチャットの送信履歴にチケットのURLが残るため、よく引用する箇所は再検索しなくて済むようになっていく。

後で振り返るケースではなく、現在進行形のケースでも引用のしやすさは威力を発揮する。
開発パートナー会社との間で、結論が出ていないテーマが全てチケット上で議論されているとしよう。さっさと全ての結論を出すため、グループチャット(複数人で同時に行うチャット)によりバーチャル会議を行うことにする。そこへ、事前に準備したチケットのURLリストを打ち込む。「今日の議題はこれらです。まずチケット番号2587のNote2をご覧ください・・・」メールでやりとりをしていた場合、こんなことはできない。

「URLは偉大だ」ということをもう少し詳しく言えば、「指示できることと、指示先をすぐに参照できることは偉大だ」ということである。家族で一緒にみかんを食べていて、カゴの中の1つを指さして「これうまそうだね」と言うのと似ている。

「これ」の一言で特定のみかんを指示できるのは、状況(みんなが近くにいてみかんに注意を払える)と常識(指さした方向が厳密にはカゴを向いていたとしても、みかんを指しているのだろうと推測する)のおかげである。カッコ内の状況がなければ誰も返事できないし、カッコ内の常識がない場合の返事は「カゴがうまそうなわけないだろう」かもしれない。

「指示したつもり」だけだったら誰でもできるが、それが相手に伝わるには指示先をすぐに参照してもらう必要がある。また、指示対象を勘違いさせてはならない。そういう意味でURLは偉大であり、その価値を十分に引き出すRedmineに類するツール(一般的にはタスク管理システムという)はよく出来ている。コミュニケーションを重んじて仕事をするのであれば、指示にまつわる効率性をよく考えてみる必要がある。


チケットはそれ自体が属性を持つ。これが掲示板スレッドとの大きな違いである。
https://my.redmine.jp/demo/issues/2587
上記において、「ステータス」「優先度」「担当者」などと並んでいる項目がチケットの属性であり、Redmineでは任意の属性でチケット全体を検索することができる。メールでは基本的に全文検索を行うしかないので、関係ないメールもたくさん拾ってしまう。つまり検索効率単体で比べても、タスク管理システムはメールより優れている。

2012年9月8日土曜日

幸せな持続とは何か?



企画展「世界の終わりのものがたり~もはや逃れられない73の問い」
http://www.miraikan.jp/sekainoowari/outline

日本科学未来館で開催された企画展に行って、特に印象に残ったのが上の写真。
質問A:「なにを持続すれば、あなたは幸せですか?」
質問B:「持続可能」とは「今」を持続することでしょうか?
と書いてある。

持続可能な社会という言葉は環境問題の文脈で使われる。なんかもう聞き慣れていて、持続可能と言った場合に「その対象が何か」なんて考えたこともなかったが、言われてみると簡単でない。

「◯はこれまで持続してきた」という時、◯に当てはまる言葉として僕がまず思い浮かぶのは「現代文明」である。他にはないだろうか?「人類の歴史」とかも考えられる。しかし、人類の歴史が続いても「この現代文明」が一挙に別の文明にリニューアルされるのは(少なくとも最高に)幸せな持続ではない。逆に質問Bのように「今」を持続するのが幸せだと言うのは、人間の願望として自然だ。ただ現実的に無理である。

そう考えていくと、幸せな持続とは「今の持続」より妥協できるが「人類史の持続」より妥協できないラインに存在するように思われる。例えば、同じような社会的生活を世襲的に繰り返していくようなイメージ。しかしながら、前の世代と後の世代が経験する社会的生活は、全く「同じよう」ではないのである。だから最低でも、「ゆっくりと変化する社会的生活を世襲的に繰り返す」イメージは許す必要がある。そんな中で持続しているものを見つければ、それが質問Aの答えだ。

ゆっくりとした変化を無数に繰り返すと、元の面影は跡形もなくなる。例えば特定の大人の顔と彼が幼児だったときの顔は全然違う。しかし彼の親は彼のことをずっと同じ名前で呼ぶし、彼が変化(成長)することを喜びさえする。この過程で持続しているのは、ある時点での子供の身体が、次の時点で僅かしか変化しないという意味における、物理的な構成である。

また「僅かな変化」はある程度、親の期待に添っていることが重要である。たとえ僅かな変化でも、妙な変化を繰り返して妙な大人に成長したら親は幸せではない。ゴール(成人後)のイメージが、「僅かな変化」が親の期待にどれほど添っているのか判断する材料になるだろう。つまり、元の面影が跡形もなくなるような長時間経過後のことも、幸せな持続に無関係ではないといえる。

一応の結論を出しておこう。何を持続すれば幸せか?
それは自分にとって重要な全ての対象であり、それぞれに期待するゴール(その実像はぼやけているものの、期待しないゴールは明確に存在する)から逆算される、それぞれごとに特徴的な「変化」である。変化ですら持続対象であるということが、恐らく質問AとBが難解に感じられた理由であろう。

※変化してもらっては困るものもある。自宅にあるノートPCなどは、ディスク上のデータ以外いかなる変化もしてほしくない。この場合は、たまたま期待するゴールが購入時と同じだったということである。

※ゴールは1つの対象につき1つだけではない。例えば赤ん坊が育ったら2年くらいで言葉を覚えてほしいとかどんな小学生になってほしいとか、中間目標はいくらでも設定することができる。そのやり方によって、それぞれの変化の幸せ度が決まる。

2012年6月2日土曜日

意識の拡大率

拡大率。グーグルマップなどを使ったことがある人はすぐ分かるだろう。それが高いと視野が狭くなり、細かい部分がよく見えるようになる。逆に低いと視野が広くなり、細かい部分がよく見えなくなる。どちらが優れているという訳ではなく、その時々の目的に応じて使い分けるのが普通である。

人は何かを意識する時、拡大率と似たようなプロパティを持っている。本を読むという行為を例にとってこの拡大率を説明してみよう。特に速読技術のない人が、1冊の本の内容を素早くざっと捉えたいと思っているとする。目次を見る。この時点で意識の拡大率は低い。見た感じ、1章と2章で著者が言わんとしていることの意図は分かるから、興味のある3章から見てみよう。と思って3章に進み1文1文丁寧に読んでいった。この時点で拡大率は高い。

意識の拡大率が高くなったので、彼の視野は狭くなって本来の目的を見失っている。丁寧に読み進めていき興味のある箇所は通り過ぎたのに、結局3章は全て読破してしまった。この本は面白くないなぁと思って読むのをやめた。

彼はもともと、内容を全て詳細に読み込むつもりはなかったのだ。全体概要を掴みたかったのにその目的が全く達成できなかったのは、興味のある箇所を通り過ぎたところで拡大率の再変更を行わなかったからである。一旦目次に戻り3章以降の興味ある章を再度探しその章を読み満足したところでまた目次に戻り・・・ということを繰り返していれば、とりあえず興味のある部分は全て読めただろう。

グーグルマップの拡大率は縦方向のバーによって表示されているが、意識の拡大率は自分で認識するよりない。自分が作業対象についての興味を失っていることに「素早く」気づき、その時点で拡大率を一挙に引き下げるのが重要である。素早く気づく体質になるための訓練としては、作業中に一定の時間間隔で「自分は今それについて興味を持っているか?」と問うてみるのが有効かもしれない。問われれば答えられるだろう。※

やるべきことはたくさんあるので、締め切りなどの与えられた順番ばかり気にして効率を落とすことは避けたいものだ。興味のない事柄Aが大事そうに見えたら、その周辺で興味のある事柄B,Cを探してみよう。BやCを経験したあとAを再度見て興味が湧いたら取り掛かれば良いし、それでも湧かなければ「大事そうに見えた」のは気のせいだったのだ。世界には、自分と関わりを持てないものはどうしたってある。

※問われれば答えられる・・・このエントリーでは車の運転に関連して、認知より判断のほうが容易であることを述べている。







2012年5月27日日曜日

思考スイッチについて

仕事が忙しかったりすると、とりあえず日々のTodoを捌いているうちに月単位の時間があっという間に過ぎ、いくつかの意味で遠いところにある重要なことに考えを巡らせることがなくなってしまう。例えば、習慣、人、将来といったようなことだ。

ここでいう習慣とは、自分の生活習慣全体の改善である。人とは、普段会っていない人を考えることである。それには離れている家族や、連絡をとってみたいと前から思っていたが勇気がでなくてそうしていない人や、歴史上の人物などが考えられる。将来とは、自分の将来についての計画や家族や日本の将来に関することである。

さて、習慣全体の改善案として、思考スイッチというものを考えてみた。僕の場合は上記の3つに加えて趣味と読み書きの計5つを左手の5本の指にそれぞれ割り当てており、例えば人さし指の腹(指紋の渦があるあたり)を爪でチクっと刺激すると「人」を考えることにしている。親指は「読み書き」であり、読んでいない本のどれを次に読もうかとか、どんな本をこれから買っていこうか、ブログに何を書くかなどを考える。思考を開始するためのスイッチという意味で「思考スイッチ」と呼んでいる。

身体に思考スイッチの機能を持たせることは、「遠いところにある重要なことに考えを巡らせる」機会を身近に置くために有効である。つまり、頭が冴えた時に「指をチクっとしてみよう」と思いさえすれば5つの分野のいずれか(あるいは全部)を考えることができる。思考スイッチがなければ、「遠いところにある重要なことは何か?」という出発点から考えなければならず、しかもこの問いをすら忘れてしまう可能性がある。

余裕がある人は右手に違う役割を当てたり、第2関節や第3関節を使ってもよいだろう。しかし重要なのは、思考が実際に行われるだけで満足しないことである。例えば、普段会っていない人のことを考えたけれども特に連絡をとらないのであれば大した意義はない。メモレベルでもいいから考えたことはアウトプットし、それが何回か繰り返された時に何らかの具体的なアクションに結びつけることができれば、とりあえず日々のTodoを捌いている日常よりは満足することができるだろう。

2012年4月30日月曜日

会社で寝ること


もはや今の時代、少しウトウトすると能率が上がることはほとんどの人が認めるところだと思うが、それでも完全に成果主義ではない会社の場合は特に「人目」の観点から会社で寝ることをよく思わない管理職もいるだろう。人目の観点とは簡単にいえば周囲の士気を下げるということである。しかしそれに対しては簡単な反論をすれば十分と考える。少し眠ることで能率よく仕事をしている様を見せることが士気を上げる効果があるだろう、という反論だ。もちろんその効果の大きさは測定できないが、寝姿を見せることが士気を下げる効果の大きさも測定できない。従ってこれらの主張は(ナイーブに考えれば)互角で、「士気を上げる論者」は単にその説得力を「士気を下げる」論者のそれから大きく離されないようにだけ気をつけていればよい。時代の追い風もある、ラクな闘いだと思うがどうだろう。

「眠くなった社員は寝てもよい」――さいたま市のリフォーム会社が昼寝制度を導入 (オルタナ) - Yahoo!ニュース
http://zasshi.news.yahoo.co.jp/article?a=20120410-00000301-alterna-bus_all

※もちろん、昼寝が良い効果を持つことをほとんどの人が認めているのであれば、反論など省略して上記リフォーム会社のように公式に制度化するのが建設的である。しかし現在なんとなく昼寝が人目をはばかる雰囲気の職場で、ほっといても制度化しそうにないならば、とりあえず寝てみて文句言われたら反論してみてはどうだろう。波風を立てなければ方向転換は起きない。ただし、理論武装なしに波風立てると勝てないし相手にも迷惑だ。

2012年4月29日日曜日

第101回 職団戦

平成24年4月28日@東京体育館
内閣総理大臣杯 第101回 職域団体対抗将棋大会
いつも略して職団戦といってるので忘れがちだが正式名称は上記。

参加チーム 370(1チーム5名)
クラスS、A、B、C、D、E、F
※Sだけ8チームのリーグ戦、持ち時間20分、秒読み30秒。その他は64チームによるトーナメント。A、Bは持ち時間30分、秒読みなし(切れ負け)。C~Fは持ち時間なし、長引いたら30秒の秒読みとなる。

マイナビは前回一軍がSからAに落ち、2軍がBからAに上がったのでAクラスに2チーム参加となった。以下、個人棋譜。

1回戦、VS JFEスチール千葉
http://kenteki.sakura.ne.jp/shogiman24r/kif/cgi-bin/shogi/shogi.cgi?mode=shogi&no=545 65手目84歩で先手よし。5-0で幸先よいスタート。

2回戦、VS リコージャパン
http://kenteki.sakura.ne.jp/shogiman24r/kif/cgi-bin/shogi/shogi.cgi?mode=shogi&no=546 73手目35銀が薄い手で一気に悪くなった。感想戦では35金か47銀でどうか、となった。
この大将戦を除いて全勝で4-1。

3回戦、VS JP労組
http://kenteki.sakura.ne.jp/shogiman24r/kif/cgi-bin/shogi/shogi.cgi?mode=shogi&no=547 38手目75銀ではなく24歩のほうが良かったかもしれない。本譜は24歩が遅れたため3筋を先攻されることになった。57手目35飛車が好手で後手苦しい。しかしそのあと先手が少しずつ間違え、92手目61香で勝ちと思った。チームは5-0。

4回戦、VS 日本生命
http://kenteki.sakura.ne.jp/shogiman24r/kif/cgi-bin/shogi/shogi.cgi?mode=shogi&no=548 89飛車から玉頭を好き勝手攻められるのを牽制するため46手目51飛車。これに対して23角は55で精算して34角成に56角と合わせて指せる。59飛車と守った後は23角が生じるので32金と寄り、68角と手放したら42金と戻る。その後2回、金寄りを繰り返すが72手目はさすがにぬるかったか。代わる手としては83歩、62玉が考えられる。端攻めを食らったので80手目55銀を決行、無理攻めと思うが相手の持ち時間が少ないためいい勝負。勝負手の94手目68桂成が通った。5-0。

5回戦、VS 三菱UFJ
http://kenteki.sakura.ne.jp/shogiman24r/kif/cgi-bin/shogi/shogi.cgi?mode=shogi&no=549 27手目77金が趣向、35手目74同飛の時に66の駒が銀なら75歩と蓋をされて困る。金なら、75歩を同金と取り73銀上がりに64金が飛車取りになる仕組み。しかし37手目、飛車の引き場所を間違えた。78まで引いておくべきであった。もしくは、76に引いたなら55手目は45歩としなければならない。このへんでミスをしたため時間的にも苦しくなり敗れた。1-4でチームも敗退。

という感じで、マイナビ一軍はA級3位でした。賞品はなぜかラジオ。

2012年4月27日金曜日

空気を利用してキャラクターを作る


「あるキャラクターになる」とは、周囲が「その人はそのキャラクターである」と認識することである。
例えば「お調子者」がいたとしたらその人は周囲からお調子者と見られており、その人に対してお調子者としての振る舞いを期待する。期待されたら、それに応えないのはマイナス評価であるから普通は応えようとする。そうしてキャラクターは固まっていき、その人にどのように働きかければ何をしてくれるか明確になり、コミュニケーション量を必要最小限で済ませられるようになる。いわゆるツーカーの仲に近づく。

さて、自分をどのようなキャラクターにするかは重要な問題だ。お調子者としての振る舞いを期待されるのがとても楽しければ自分をお調子者に育てるとよい。しかし、キャラクターの種類はお調子者を初めとする数種類に限定されるものではなく、周囲はその人を一般名詞的なレッテル(お調子者はその例)で見ていることはほとんどない。少なくとも、コミュニケーションをとる当人同士が近しい間柄なのであれば、周囲はその人の個人名をキャラクター名そのものとして受け取っているだろう。

その状態で自分のキャラクターを育てていく、あるいは変えていくとは、レッテルを張り替えることではなく「自分という振る舞い全体」の一部分を少しずつ変えることである。いわゆるデビューは、かなりの経験値と捨て身の勇気がなければ成功しない。中学生の自分が嫌いで、高校生になったから新しい自分に生まれ変わろうとしても、そもそも模範となるキャラクターを経験していないのだからそれを演じることは難しく、できることといえばゼロから再構築を試みるくらいである。しかしそれは、周囲から見ればとても変だろう。そういうギャンブルな人生もあるかもしれないが。

少しずつ自分を変えていくのでも何年も続ければ別人になることは、有名人の過去の写真など紹介するテレビ番組を見れば分かるだろう。あの頃の自分と今の自分では考え方も見た目も全然違うと、よく言っている。僕は思うのだが、例えば職場の環境が悪くてなかなか帰れないとか、言いたいことが言えないとかいうのは、単にキャラクター作りに失敗しているだけじゃないだろうか。社会人になって何年かは、さすがにそのことに確信が持てなかった、単に自分のバックグラウンドがたまたま恵まれているのかとも思ったが、33にもなるとさすがにそうではないと感じる。正確に言うと、それだけではないと感じる。

あるキャラクターを演じるのに必要な資質は確かにある。例えば「言いたいことを言う」に必要な資質は、彼が「文脈に即しているとか面白いとか問題解決に役立つ」などのセリフを言えることである。「早く帰る」に必要な資質・バックグラウンドは「効率良く仕事をする、そもそも仕事が多すぎる職場に就かない」などである。しかし、その資質があるかどうかを試そうとしない人が多い。早く帰れるかどうかを「空気を読んで」判断するのは馬鹿げている。注意すべきは「明日の仕事が明日片付くか」それだけである。

早く帰ることが周囲に「あの人は早く帰る人なんだ」と思わせ、その期待が自分に伝わり「帰っていい空気」になる。失敗してもデビューほどのリスクはないし、成功したらその空気を利用してキャラクターを定着させよう。遅くまで仕事している人はみんな、部署異動しても遅くまで仕事しているよ。それは空気が自分の制御圏にある証拠だ。

2012年4月22日日曜日

Ruby Programmer Gold の試験を受けて

1ヶ月前に紀伊半島一周しながらRubyの試験勉強してた時からだいぶ時間がたってGoldの受験となった。本当はSilverを受ける前にGoldを受けようと考えていたのだが、ずっと発売延期となっていた『Ruby公式資格教科書 Ruby技術者認定試験Silver/Gold対応』が発売されたことを知りこれを読んでから受験することにした。4/21のtwitterログから引用する。
Ruby技術者認定試験Gold、終了。76点でギリギリ合格。厳しい時間だった…公式資格教科書についてる模擬試験より全然むずいじゃんか。 
50問中、12も間違えたわけだ。どこを間違えたのか、3つくらいの心当たりしかないが…しかし、12間違えても合格なのだから、完璧主義は封印して、自信ない問題には早々に見切りをつけたほうが良かったかもしれない。  
一画面に収まらない長文の問題は後回しにしたが、結局それらを解くだけで90分使ってしまい、全体の確認に時間を残せなかった。4択で、正しいものを全て選べ系の難問に迷うよりは、一つしか正解がない問題をたくさん見直すほうが率が良い。しかし、一問目が一番難しいのには痺れた。 
 ちなみにSilverのほうは50問中47問正解で、簡単だった。公式資格教科書だけで十分いける。Ruby技術者認定試験Goldにチャレンジする人は、まずこちらでPC受験の独特の雰囲気と時間配分に慣れてから受けることをオススメしたい。 
3問間違いと12問間違いの間には9問の差があるが、感覚としてそのうち4問くらいは確認に残せた時間の差という気がする。そしてもう少し言えば、長文に出くわした時にそれが単に長い問題なのか本当の難問なのか見極める即時的判断力があると、後回しにするというオーバーヘッドを減らせたと思う。 
試験場にあるPCの画面解像度が低いので、長文問題だとスクロールしないと回答の選択肢が見えず嫌らしいが、そこは慌てずサッと回答に目を通したほうが良さそうだ。即時的難問判断に必要なスクロール。 
90分の持ち時間は長いようだが、問題全体の見通しの悪さと、ディスプレイにペンで書き込みが出来ない点、残り時間のカウントダウンが刻々と表示されて焦らさせる点などを考えると全く油断できない。シルバーのほうも最後のアンケートを入力し終わったらほとんど時間残らなかった。
 Ruby技術者認定試験は持ち時間90分、CBT(Computer Based Testing)と言われるコンピュータ試験、50問の選択式で合格ライン75%となっている。だから76点はまさにギリギリで、あと1問まちがえればアウトだ。貴重品等を入れるロッカーの鍵番号と同じ番号の席に座り受験番号を入力してスタートボタンを押せばテスト(と持ち時間のカウントダウン)が始まる。持ち時間が切れると容赦無くテストが終了し、同時に点数と合否が表示されるという味わいのないシステムである。「合格」の文字の前に「不」がついてないか2度見した。

やっぱり、紙に比べれば明らかに試験はやりにくい。上記ログでいうところの即時的難問判断も全部の問題がバッと見渡せたほうがラクだし、問題文の近くにメモを書けるのもメリットだ。CBTではメモ用紙は配られるもののペンが太いマジックで書きにくいし問題文が書いてないからメモする量が増える。例えばX行目の変数の内容を書くのに、問題用紙に書けるなら変数の内容だけで済むところを、まっさらなメモ用紙には変数名も書かなければならない。

まぁしかしそのへんの条件は皆同じわけで、要はそういうやりにくさがあるということを事前に知っておき対策を立てられたらベターということだ。で肝心の内容のほうは、あーありがち技術メモbasyura’s blogなどにある通りでRubyという言語の本質を突いた良問が多い印象。読んで役にたったと思う本は『Ruby公式資格教科書 Ruby技術者認定試験Silver/Gold対応』の他は『メタプログラミングRuby』のみ。ITトレメの問題は模擬試験の品質を備えていない。

また出題範囲が1.8.7なので下手に1.9系の本を読まないほうがいい、例えばプログラミング言語 Rubyとか良書だがスコープを超えすぎる(※混乱しない自信があれば有益ではある)。『メタプログラミングRuby』も、メタプログラミングの魅力に取り憑かれるのは後回しにしてメソッド探索のルートやスコープの基礎論を重点的に、irbも使いつつ読み込んだほうがいい。

それと以下も重要。入れ子になったクラスのそれぞれで下記3種変数の宣言をしたり代入をしたり参照したりでどうなるか確認する。
「クラス変数とクラスインスタンス変数とインスタンス変数の違いについて - 遅咲きのエンジニア」
http://d.hatena.ne.jp/kabakiyo/20080525/1211728832

その他、トップレベルとか。
「Rubyのトップレベルのメソッドの不思議 - As Sloth As Possible」
http://blog.livedoor.jp/faulist/archives/1222830.html

enum_forとか。
「Rubyist Magazine - 標準添付ライブラリ紹介 【第 5 回】 enumerator」
http://jp.rubyist.net/magazine/?0011-BundledLibraries
「イテレータを便利にするenum_for - Slow Dance」
http://d.hatena.ne.jp/LukeSilvia/20081113/p1

ところでこの試験、プラチナも策定中みたいです。受かる自信がない。

2012年3月3日土曜日

紀伊半島一周メモ

紀伊半島一周計画
http://spinel3.blogspot.com/2012/02/blog-post_29.html

の通りにだいたい運んだ。しかしスーパーくろしおは思ったより揺れたので勉強は捗らなかった。
13時前に紀伊勝浦に着き、外に出て周りを見渡すとすごい静か。
木曜だとこんなもんなのか。

近くのマグロ丼屋でミックスマグロ丼(1500円)を頼んだ。美味しいが、1500円あったら別のものを食べたい。
でもバスの時間があって、手っ取り早く昼を済ませたかったから仕方ない。

13時半くらいのバスで那智山へ向かう(往復千円)。乗車率は40%といったところか。
最後の3駅が熊野古道、那智の滝、那智山。終点で降りて那智熊野大社に向かう時の写真がこれ。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715275928496066498

世界遺産ってこんなに民家あるんだ~
と思いつつ登っていく。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715275979194587586

でこれが那智熊野大社。これ含めいくつかスマホで撮ったものは順序が後の方になっている。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715279918522034434

次は滝に向かう。大社の近くからでもこんな風に見える(3倍ズーム)。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715276202128441250

滝の動画。picasaは動画もアップできるんですな。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715276531873126498

近くのバス停から下山する。待ち時間があったので那智黒あめ入りのソフトクリームを食べた。
このへんの店ってほんと那智黒とマグロしか目に入らない。

紀伊勝浦の駅に戻り、ホテルを探す。多分このとき16時くらい。
サイトの地図には体育館の近くっぽく書いてあったので、まず体育館に行くことにする。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715276554431920962
地図を読み間違えて・・・とコメントがあるが体育館の方角に正しく進んではいた。
ただ、体育館とホテルが実はぜんぜん近くなかったのだ。

17時くらいにホテルに着いた。驚くほど田舎で、来る途中の食事処といえばマグロしか見えなかった。
素泊まりプランだし、マグロ以外の飯にありつけるか不安であった。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715276572567238834

ホテルで一服し適当に勉強してから、フロントでもらったマグロマップを研究する。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715279696560534866
やっぱマグロ屋しかないんかーい
と思って懸命に探した結果、中華屋さんを発見したのでそこにする。マグロ入りラーメン美味しかった。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715276608740570178

ホテルは、ホテルと呼べるギリギリのラインと思ったが、温泉は素直によかった。
これは部屋からの景色だけども、だいたいこんな景色をぐるっと見渡しながらお湯に浸かることができる。
食事前と翌朝6時、2回入った。朝は完全に一人だった。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715279784471355042

朝風呂に浸かったら、朝食がないので早々にチェックアウトして、いい感じの時間に伊勢で昼ごはんにありつかねばならない。それまではフロントで買った那智黒のど飴で凌ぐ。ところが紀伊勝浦で、電車来てるからとりあえず早く乗れと駅員に急かされていた前方の人につられ乗った電車が逆方向だった。40分に1本くらいしか電車ないのに最悪だ。しかしこうなれば、15分くらい進んでから折り返してやろうと思いながら乗っていた。ところが、途中の駅で止まってもドアが開かない。他の乗客は高校生ばかりで、携帯もいじくることなく静かに座っている。どうやってドアを開けるのか、降りる人の行動を注視して学習しようと思ったがなかなか誰も降りない。なんかドアのところに「開」「閉」というボタンがあるが、その上には非常用と書かれている。日常生活でこんな謎に遭遇するとは思わなかった。

困りながら耳をすませていると、「・・・ドアは前の車両の一番前のしか開きません」というアナウンスが聞こえてきた。どうも、駅員がいない小さい駅では乗車時に整理券を受け取る仕組みになっており、同様に小さい駅で降りるとき1両目に1人だけいる車掌に整理券を見せて運賃を精算することになっているようだ。でもこのことは、アナウンスを聞いて実際に降りてみなければ分からなかった。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715276648083525634

降りるとき、車掌に新宮行きの切符をとられた。またすぐ逆方向に戻るのに。雨の駅で30分くらい待つはめになった。
ちょうどいいからiPadでも読もうと取り出したら、雨がiPadにかかって使えない。和歌山、すごいところだ。
で、新宮行きに乗って・・・
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715276691109206786

新宮で整理券を見せ無駄金を払う。特急ワイドビュー南紀4号で多気まで行く。9時13分発だったか。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715279579818321890

多気に着いたのはツイッターによると11時24分だ。特急早い!
多気から参宮線(一両編成)で伊勢に向かう。霧がすごい。 (@ 多気駅 (Taki Sta.)) http://4sq.com/wD7bwN

で伊勢市に着く。ここから特に事件はない。
https://picasaweb.google.com/108229091054904450501/yjGkLK#5715276708281767922

平成25年は20年に一度の式年遷宮に当たるらしい。
http://www.isejingu.or.jp/shikinensengu/shikinen-index.html

2012年2月29日水曜日

紀伊半島一周計画

3/1 8時ごろ三田を出発し、こう行って

昼ごろ紀伊勝浦に着き、そのへんを見てまわり夕方に
海のホテル一の滝 にチェックインし
http://www.jalan.net/yad390486/


翌朝こう行って昼ごろ伊勢市に着き、伊勢神宮を見てまわり

夕方にこう行って三田に戻ってくることにした。雨よ降るな。

2012年2月28日火曜日

rubyの試験勉強をする旅行プラン

最近Rubyを勉強することが多かったので、1週間の休暇明けに
Ruby技術者認定試験(Ruby Association Certified Ruby Programmer Gold)
でも受けてみようかと思っている。

どうやらGoldの資格はSilverの試験とGoldの試験に両方受からなければもらえないようだが、どちらから受験してもいいようである。よく分からないが、Silverの対策本は出版されているもののGoldの対策本はないようだ。だから、SilverよりGoldを受けたほうが心配感によって幅広く真面目に勉強せざるをえないだろう。というわけでGoldから受験する。rubyの本は全部iPadに入っているので、これを持って三重県の伊勢神宮にでも行き、余力があれば那智の滝でも見に行き、道中iPadを眺めるという不真面目なプランを考えている。

ここは兵庫県三田市なので、新大阪あたりからJR特急スーパーくろしおで紀伊半島の海岸線を西側からぐるっと進み先に那智を訪れ、そのへんで滝や熊野那智大社を見たり温泉に浸かったりし、一泊してから北上して伊勢神宮を見てまわりその後東京へ帰るというのが本気プランではある。ただ水曜と木曜の天気が今ひとつなのと、旅行のための本気プランが勉強にどう影響するかが読みきれず、どうしようかなぁと思っているところだ。伊勢神宮も那智勝浦も直線距離ではそんなに違わないのに、かかる時間とお金が全然ちがう。

2012年2月27日月曜日

Developers Summit 2012 の資料など

講演資料が揃ったようなので個人的に重要と思われるものをまとめておこう。上2つは実際に聞いたやつで下2つは聞きたかったけど他のセッションとかぶってて聞けなかったやつ。うーん、twitter( http://twitter.com/#!/devsumi )とかじゃなくてタイムテーブル( http://seshop.com/se/timetable/21 )に資料の欄を追加してほしいな・・・終わったら急に手抜きになるのはどうか。

【16-A-1】及川卓也氏「見る前に翔べ ~ギークの工夫で社会を変えよう~」
http://www.slideshare.net/takoratta/ss-11690864

【17-E-3】 オンライン機械学習で実現する大規模データ処理
http://www.slideshare.net/devsumi/17e3

【16-C-2】桑野章弘氏/並河祐貴氏「大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~」
http://www.slideshare.net/akuwano/mongodbchef
http://www.slideshare.net/namikawa/devsumi2012-pigglife-chef

【16-A-7】市谷聡啓氏「あの人の自分戦略を聞きたい!」
http://www.slideshare.net/papanda/moon-and-strategy

あと、下の2つは資料がないね。せっかく良かったのに残念だ。特に16-E-7は建築の専門家が出てきて、津波のシミュレーションから防災設計の優先順位等を意思決定する話を紹介してくれて大変ためになった。17-C-6は進行役がのんびりしすぎていてスケジュールを捌ききれてなく、興味深いテーマが2つくらいかっとばされた。

【16-E-7】3・11から見えた社会基盤としてのIT
【17-C-6】ライターズ・フィロソフィー―IT業界で書いて食っていくひとたちの哲学をきこう

16-A-1の中で、マーク・ザッカーバーグの有名なセリフ「Done is better than Perfect」が出てきた。完璧を目指すよりまずは完了させること、という意味でアジャイル思想と強く関係する言葉だと思われるが、適切な分割設計なしには達成できない巨大なプロジェクト・作業・情報処理に広く応用できそうだ。

大きいことをしたい → 大人数を投入 → 各人に仕事を配るため、完成させたい巨大なものを分割しなければならない → 分割されたもの(部品)は、全て組み立てるまで動かないのでは困る → 部品がそれ単体で意味を持ち、正しく動作するような分割の仕方が要求される というプロジェクト一般の流れは、この矢印を逆に辿っていけば個人でも大きいことができることを意味している。「各人」を、今日・明日・明後日の自分と読みかえればいい。この流れに適合する部品だけがいい部品であり、それ以外は「Done」してもしなくても「Perfect」にやりたい内容とは無関係のことだ。

そこへいくと Done is better than Perfectの教訓というのは、やれることからコツコツ実現しようという当たり前のことではなく、全体と部分の関係についての直感を常に働かせよということではないか。部品を見て組み上がりが想像できるかどうか。何かの目標のために始めた習慣が、ただ惰性となって残り元来の目標が何だったか忘れてしまったとか。何か調べたいことがあって分厚い本を最初から丁寧に読み始めたが、つまらないので捗らずそのうち調べたいことを忘れ、なぜそれを調べたいと思ったのかも忘れてしまったとか。

目に見えるのは常に部品だけであり、全体は最後に現れるか下手をするとずっと抽象物のままである。周囲の人々の行動を見れば、やっていることは大して珍しくもないし高度でもない。にもかかわらず人によって蓄積に違いが出るのは、各人の持っている部品がそのように分割されている意味の濃さによるのだろう。

2012年2月19日日曜日

Developers Summit 2012 の感想

10年後も世界で通じるエンジニアであるために Developers Summit 2012
http://codezine.jp/devsumi/2012

デブサミに2日連続で行ってきたので、とりあえず感想を書こうと思う。
まー今回は10周年ということでこの10年間のまとめみたいなテーマが多かったように思われ、
特に印象に残ったのは「3・11から見えた社会基盤としてのIT」と「ライターズ・フィロソフィー IT業界で書いて食っていくひとたちの哲学をきこう(仮)」という、ちょっとテクノロジー寄りではないセッションであった。
資料がアップされたら各セッションの詳細を振り返ることにする。

で、内容を詳しく覚えているわけじゃないんだけど今回は何故か開発プロセスのセッションを3つも受けてしまった。
全部面白かったけれども、スクラムだとか(アジャイルの一種)をどう日頃の開発業務に取り入れていくべきかっていう話は少なくともうちの会社には時期尚早なので、セッションの内容とは直接関係ないことばっかり考えることになったのだ。

うちの会社は就職・転職情報サイトなどリクルート的なウェブサイトをいくつか運営していて各サイトごとに社内SEみたいのがついているが、例えばソーシャルゲーム開発ができるほどの部隊がいないためエンジニアは基本的に売上を生まず人件費だけかかる存在としか(事実上)考えられておらず、上層部がITに疎いことも相まってエンジニアの数を増やす経営判断は後手に回りがちなのである。
別に自社批判をしているつもりはなく、彼らは彼らにとって確信的なビジョンのない博打をしないだけであろうと思っている。面白いソーシャルゲームに自然とユーザが集まる、つまり営業・販促の費用が抑えられエンジニアの人件費だけで莫大なPVを得られることが分かっているならエンジニアを増やす判断は難しくない。しかしノウハウもない会社が突然ソーシャルゲーム市場に参入できるわけもないので、別の例を用いてそういった「判断が難しくない状況」に持っていくことが重要になってくる。

最近DVDで「無法地帯」を見ていて、その中で元帝国陸軍大本営参謀の壹岐正がシベリア抑留を経て近畿商事(伊藤忠がモデルとされている)に入社し商社の大本営たる業務本部創設を社長に提言するが、壹岐がそれをしなければ近畿商事はしばらく重要な組織を欠いた状態のままであったと思われる。壱岐の提言が受け入れられたのは、彼の大本営参謀としての頭脳に社長が信頼を寄せていたこともあるかもしれないが、業務本部を作ることのメリットがデメリットを上回る、しかも割と短期的にそうであることをうまく説明することによって社長を「判断が難しくない状況」に持っていったのだろう。

ある分野に対する上層部の理解がないという状況でありがちだと思うのは、提言がとても中途半端なために単なる愚痴や文句になってしまい聞き入れてもらえずそれ以降あきらめるというパターンである。エンジニアの話でいえば、要は1人雇うと1人分以上の利益が出るようなエンジニアの使い方(体制)を予め用意できていればいいわけで、その用意ができるのはITに疎い上層部ではない。しかしその用意をするためには時間と方法論が必要であり、方法論のほうはエンジニアが習得すべきことであるが時間を与えるのは上層部の役目である。しかしその時間を与える理由が前述のような体制を作るためであって、時間があるとこれこれこのように体制が実現する見込みであると説明するのはエンジニアの役目である。

簡単に考えれば、既存のサイトが例えば1PVあたり1円の儲けになるとすると、100万ほど月平均PVをアップさせればいい(厳密に言うと、その原因をエンジニアに帰着させなければいけない)のだが、新しくA人のエンジニアを採用して同じサイトをA☓100万PV増やすのはAが大きくなるほど難しくなる。よって、そのサイトの総PVが100万に対して非常に大きいか(例えば月1億PVのサイトであれば、わずかな直帰率の改善で大きくPVが増える)、少なくとも同規模のサイトが複数存在する必要がある。

つまり、まず増やしやすいのは既存サイトの改善部隊であろう。PVアップの施策を行い、うまくいったらその原因を自分たちの施策に帰着させるためのレポートを行う。反対に、新規サイトの自社構築部隊は後回しになるだろう。新規サイトが増えていけばそれぞれに改善部隊を設けることができ、エンジニアの絶対数が増えるとGoogleの20%ルールのようなプロジェクトによって自前でβサービスを立ち上げられるようになる可能性が高い。

他社構築が前提となっている状態の問題点は、コーディングスキルの高い人がつまらないこと(ひいては、そういう人の需要も供給もなくなる)、また他社構築を要するほど大きい案件ばかりでは新規サイトが増えるスピードが遅いためエンジニアの絶対数が増えるスピードも遅く、20%ルールを適用するのに必要な余剰時間が作れないこと、つまりコンテンツエンジニア※が生まれないことである。

※コンテンツエンジニア
例えばソーシャルゲームのコンテンツをエンジニアが提供しているとすれば、その人はコンテンツエンジニアである。MovableTypeで記事を作るのがライターなのであれば、そのMTを用意した人はコンテンツエンジニアではない。
PVを生む当の人がエンジニアである場合を含めれば、前述の改善部隊も広義のコンテンツエンジニアと呼べるかもしれない。

まーしかし、ここに矛盾が1つあって、自社にコンテンツエンジニア部隊を持ちたいと考える人は自分がその部隊に入りたいのであって、体制を作っていく当事者になりたいとは限らないしその手の才能なり元気なり覚悟なりがあるとも限らない。うちのエンジニアに聞いてもそのように言っている人はいる。他社構築から自社構築へと転換した話としては昨年のデブサミでDeNAの南場さんが自社の例を紹介していたが、ぼんやり覚えている限りでは、自社で開発しないのにコンサルなんてできねぇよみたいな思いから端を発していた。ふむ、そりゃそうだ。だからDeNAでは上層部のレベルでハードランディング路線を決める判断に確信が持てたんだろう。

うちの場合はコンサルなんてやってないし、他社構築でも直近では問題ない。だから少なくとも論理レベルでは、自社構築路線に転換するにはソフトランディング路線が求められる。デブサミは新しい技術、開発プロセス、クラウドなどの新製品、エンジニアのキャリアに関するセッションはあるが、非IT企業がIT企業になる過程の話を聞くことはあまりない。ある程度組織の基盤が固まったらその先は開発プロセスの分野からヒントが見つかる気もするが、その前は・・・経営論でも参照すると何か書いてあるんだろうか。

2012年2月14日火曜日

利他について

タイム・コンサルタントの日誌から : 書評:「持続不可能性」 サイモン・レヴィン著
http://brevis.exblog.jp/14689955/

生物界には、「利他的」としか言いようのない、不思議な現象が時々ある。それを、めぐりめぐって最終的には自己や自種の適応可能性を高めるから、という視点から説明しようという、いかにもネオ・ダーウィニズム的な研究アプローチである。

しかし、本当にそういう説明ですべてが納得できるのだろうか。進化ゲーム理論やネオ・ダーウィニズムには、競争原理はあれども、協働原理は存在しようがない。前提条件から排除されているからだ。

なんか前にもReblogしたような気がするけど・・・既視感かもしれないけど・・・なんか気になるテーマです、利他。
ふつうは生物の進化は自然淘汰がその原理とされている。個体が自分自身のためにつまり「利己的に」生き、その生き方が自分の長寿というか繁栄力をもたらすのであれば、その生き方に対応した遺伝子が次の世代において優勢になる。これは利他を装った利己であっても同じことでしょう。なぜなら「生き方が自分の長寿というか繁栄力をもたらすのであれば・・・」という文章中の「生き方」は、それがどんな内容であっても文章全体の意味を壊さないから。

でも引用文中の「自種の適応可能性を高めるから」という部分は簡単に見逃せない。ここで言ってるのは、ある生き方が(めぐりめぐって最終的に)自分のためにならなくても、自分の生物種の繁栄をもたらすならばその生き方が自然淘汰によって優勢になるという意味かと思うが、るろけんの志々雄真実も言ってるとおり「強い者が生き残るんじゃない、生き残ったものが強いんだ」であり、遺伝子の拡散ってそもそも個体が生き残らないことには起きようがないわけで、仮にある生き方が自分の生物種の繁栄に寄与するものだとしても自分自身のためにならないならその生き方は後世に伝わらない。

といっても、人間なら利他があっても不思議はないかなという気もする。人間には遺伝子とは別の形で文化を伝える手段があり、それぞれ文化Aと文化Bを持つ国家AとBがあって、それらが戦争でもして国家Bが消滅した場合、Bの文化もあらかた消滅するわけであるから文化Aが後世に残るだろう。この場合、利他が国家のためになるなら利他が美徳として奨励されていたのは文化BではなくAのほうである可能性が高い。要するに利他は文化であって本能じゃないんじゃなかろうか。

もし利他が本能なのだとしたら、わざわざ奨励する必要はないわけである。お母さんを大切にしましょう・・・これは遠まわしな利己だ、だからそんなに奨励する必要はない。でも子供が成人したら彼は母親なしで生きていける、だから成人した子供が母親を大切にするのは遠まわしな利己とは言えない、つまり利他だ、だから奨励する必要があって、実際奨励に用いられている言葉は「親孝行」でありその対象は大人である。

もし原始的な生物に利他があるとするなら、その生物種の個体間にも文化的なものがあるんじゃないだろうか。例えば模倣とか。ある個体が気まぐれで利他アクションを起こし、それがなんか真似したい感じだったので近くにいた個体が次々に真似をして、世代間のオーバーラップによって伝えられていくような。集団的にその利他アクションを行うと生物種にとって良い影響があるなら、利他アクションを行わない類似の生物種より繁栄しやすいことになるだろう。

つまり、遺伝子じゃなくアフォーダンス的な反応(原始的な模倣)によって伝わっていくことって実は結構あるのだが、我々から見て利己的と思われる行動は自然淘汰ということにして、利他的と思われる行動は何とか利己に帰着させようという、そういう間違いをしてる可能性ってないのかしらと思ったりした。

2012年1月28日土曜日

SinatraとSequel・Hamlで掲示板アプリを作る そしてHerokuへあげる

WEB+DB Press Vol.65「Write Less, Do More」のコラムから引用:
(Railsの進化によって)Rubyの記述量がどんどん削減された結果、今度はそれ以外のコードがネックになってきたと言えるでしょう。だから次はRuby以外のコードをあまり書かなくていいようにと、SCSSやCoffeeScriptが取り込まれたのでしょう
ネックになってきたというか、なんでrubyは綺麗に書けるのにHTMLとかCSSとかこんな冗長にしか書けないんだという不満が潔癖症のプログラマを動かしたように思う。まぁ、haml・coffee・scssを導入したらしたで、新しい書き方が3つ増えるわけで、一人でやる分にはいいけどチームで開発する時どうなんだという気がしないでもないが・・・やはり目先の学習コストに対する寛容さは人それぞれだと思うし。

それはそれとして、以下のアプリはHamlとsassのイージーサンプルとなっているので掘り起こしてみた。

Ruby Freaks Lounge:第9回 SinatraとSequel・Hamlで掲示板アプリを作る|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/ruby/0009

上の通り、公開されてるコード( http://github.com/yhara/sinatbbs/tree/magazine )をとってきて動かせばローカルで掲示板アプリがサクっと動くが、Herokuで動かすには少し修正がいる。以下、その手順をメモ。

◯ファイル追加など
- Gemfile
 sinatra, haml, sequel, sqlite3, heroku をGemfileに書き、bundle install --path ./vendor/bundle としておく。

- start.rb 修正
 require './model/comment.rb' (./を先頭につける)

Ruby 1.9.2から$LOAD_PATHにカレントディレクトリが含まれなくなった - ぬいぐるみライフ(仮)
http://d.hatena.ne.jp/mickey24/20100907/1283869273

- comment.rb 修正
 Sequel.connect(ENV['DATABASE_URL'] || "sqlite://db/development.sqlite3")

デプロイ時も考慮して、DBへの接続は Sequel.connect(ENV['DATABASE_URL'] || 'sqlite://my.db') という感じで書く必要あり。 - Lost+Found
http://d.hatena.ne.jp/Snaka/20090704/1246712748

- migration用ファイルの作成
 db/migrate/001_create_posts.rb
class CreateComments < Sequel::Migration
  def up
    create_table :comments do
      primary_key :id
      text :name
      text :title
      text :message
      timestamp :posted_date
    end
  end
end
- Rakefile作成
require 'rubygems'
require 'rake'
require 'sequel'
require 'sequel/extensions/migration'

namespace :db do
  desc "migrate database"
  task :migrate do
    DB = Sequel.connect(ENV['DATABASE_URL'] ||'sqlite://db/development.sqlite3')
    Sequel::Migrator.apply(DB, './db/migrate')
  end
end

- config.ru作成
require './start.rb'
run Sinatra::Application


Ruby Freaks Lounge:第23回 Rackとは何か(1)Rackの生まれた背景|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/ruby/0023

◯ローカルで動かしてみる

# rake db:migrate
※sqliteなので不要だが、herokuで必要なので確認しておく
# rackup

◯Herokuで動かす

# git init
# git add ./
# git commit -am "<コメント>"
# heroku create <app名>
# git push heroku master
# heroku rake db:migrate
# heroku open

http://bbs-sp3.heroku.com/
完成。


参考サイト:
CSS拡張メタ言語「SCSS(Sass)」と「LESS」の比較 - (DxD)∞
http://dxd8.com/archives/217/

Ruby Sequel DBアクセスライブラリ - yshのメモ日記
http://d.hatena.ne.jp/yshgt/20080629/1214720897

herokuでsqliteなsequelつかうときのメモ - Lost+Found
http://d.hatena.ne.jp/Snaka/20090709/1247155835

sequelでmigration | ゆーすけぶろぐ
http://yusukezzz.net/blog/archives/1574

Sinatraの使い方 - ayaketanのプログラミング勉強日記
http://d.hatena.ne.jp/ayaketan/20111219/1324295283

2012年1月22日日曜日

Heroku で lokka

lokkaという、sinatra(軽量rails)上で動くcmsをHeroku(ruby版Paas)にアップする手順メモ。

◯環境

Mac OS X 10.6.8
MacPorts 2.0.3
rvm 1.10.2
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin10.8.0]
gem 1.8.15
heroku (2.18.1)
git version 1.7.7.4

◯環境構築手順

http://www.macports.org/install.php
macportsのインストール(略)
rvmのインストール(略)
rubyのインストール(略)
gitのインストール(略)

git clone git://github.com/komagata/lokka.git #lokkaを取得する
cp -p database.default.yml database.yml #lokkaディレクトリ内にdatabase.ymlを作成
bundle install ./vendor/bundle --without development postgresql #postgresを使わない設定
bundle exec rake db:setup
bundle exec rackup #ローカルでlokkaが確認できる

gem install heroku #ここからherokuにデプロイしていく
heroku create
git push heroku master #ssh公開鍵を作成しておく必要がある
heroku rake db:setup
heroku open #デプロイされたlokkaを確認できる

gem install taps #ローカルでlokka確認したときユーザ作成などしていたらDBをpushする
heroku db:push sqlite://db/development.sqlite3

◯できたもの
http://spinel3-lokka.heroku.com/

◯参考サイト

HerokuでWebアプリ開発を始めるなら知っておきたいこと (7)ブログならLokka - アインシュタインの電話番号☎
http://d.hatena.ne.jp/ruedap/20110505/ruby_heroku_web_app_development_tips_7

LokkaをインストールしてHerokuにデプロイした - kk_Atakaの日記
http://d.hatena.ne.jp/kk_Ataka/20111127/1322329546

HerokuでDBのデータをダウンロードしたりアップロードしたり - アインシュタインの電話番号☎
http://d.hatena.ne.jp/ruedap/20110222/ruby_heroku_database_sqlite3_download_upload

HerokuにWebアプリ(Sinatra)をデプロイする手順をまとめた - kk_Atakaの日記
http://d.hatena.ne.jp/kk_Ataka/20111126/1322240459

2012年1月9日月曜日

第2図書係補佐に出てくる読みたい本

前回
http://spinel3.blogspot.com/2012/01/blog-post.html

「読み終わったらもう1周読んで、読んでみたい順に10冊程度ピックアップしてみようと思う。」
このように書いた。読み終わったので宣言通りピックアップしてみよう。

何もかも憂鬱な夜に
人間失格
深い河
コインロッカー・ベイビーズ
アラビアの夜の種族

世界の終わりとハードボイルド・ワンダーランド
親友交歓
笙野頼子三冠小説集 (河出文庫): http://goo.gl/HEv0X
中陰の花
わたしたちに許された特別な時間の終わり

コメント。

巻末に中村文則さんとの対談がのっている。彼の作品である「銃」か「何もかも憂鬱な夜に」の選択で後者を。
又吉ファンになったからには太宰は外せないので「人間失格」と「親友交歓」。
後者は太宰の面白い側面が見られるらしい。
深い河はインドが舞台ということで興味深い。
コインロッカー・ベイビーズは又吉の思い出とリンクしすぎている。この章と「右で蹴れや」の章は、ニヤつかずに読むことは難しい。人によっては爆笑するだろう。

アラビアの夜の種族は、災厄の書を読んでみたい。ちょっと紹介文から引用しよう。
「面白すぎて読む者が夢中になり破滅する」と伝えられる「災厄の書」をナポレオンに献上しナポレオンのエジプト侵攻を阻止するという設定からして規格外だ。それほど面白い物語であると冒頭で宣言した上で、実際に作中で「災厄の書」の内容を語るという真っ向勝負。

世界の終わりとハードボイルド・ワンダーランドは、面白いんだろうけどひょっとしたら読まないかもしれない。前に一度挫折したことがあるようなないような。
笙野頼子三冠小説集は閉ざしがちな女性たちを描いているということで興味ある。
「中陰の花」は現役僧侶の人が書いたということで興味深い。
わたしたちに許された特別な時間の終わりは、演劇そのものに対する嫌疑に満ち溢れているということで興味深い。紹介文から引用しよう。
・・・それが岡田利規さんが作・演出をするチェルフィッチュという劇団だった。チェルフィッチュの舞台は演劇そのものに対する嫌疑に満ち溢れていた。・・・公演された作品を岡田さん自身が小説化したのが、『わたしたちに許された特別な時間の終わり』である。

初めの5つは特に読んでみたいもの、あとの5つは余裕があったら読んでみたいもの。
第2図書係補佐を読まれた方、あなたの選択とは似ているでしょうか?

2012年1月8日日曜日

年末年始のインドア模様

年末実家に持って帰ったのが
・Rubyの試験本
・「ベッドルームで群論を」
だった。そんで実家でGalaxyTabに「運命の人(山崎豊子)」をダウンロードした。
東京に戻ってから又吉の「第2図書係補佐」、「zshの本」を購入。
休みの間に中国ドラマ「新・上海グランド」の続きが視聴できるようになってないか期待してたが解禁は1/19のようだ。
また1/13に映画「Railsways(2)」が公開終了なため、それは見た。

Railways(1)は島根、今回は富山。1ではエリートビジネスマンが突然会社をやめて子供の頃の夢だった電車の運転手になるのに対し2は48年間無事故無違反の運転手が定年退職する話。観客に若い人が全くいない。当然とも言えるし寂しいとも言えるが、やはり前作のほうが共感できる。でも富山鉄道から見える綺麗な景色がふんだんに使われていて映像としては楽しめた。

第2図書係補佐は初めて買った又吉本。「カキフライがないなら来なかった」とか「まさかジープで来るとは」とか、内容が想像できなかったから敬遠していたが今回のは本の本なのであろうということで購入した。でも読んでみるといわゆる本の紹介本ではない。一応各章に(だいたいは最後のほうに)その章のタイトルになってる本がちょろっと紹介されてはいるが、紹介の前に書いてあるのは基本的に又吉自身の体験談である。その体験談と本がリンクしていて、そのつながり具合を楽しむのがこの本の醍醐味であるようだ。読み終わったらもう1周読んで、読んでみたい順に10冊程度ピックアップしてみようと思う。しかし又吉、太宰のエピソードといいサッカーの話といい現役お笑い芸人であることといい、強烈なキャラクターではある。ツイッターをフォローしたが特に何もタイムラインに上がってこないのが残念だ。

第2~補佐は実家に帰る途中の尼崎で買ったんだったか。で実家では読まなかったのかもしれない。
尼崎の本屋は小さい本屋なのだがいつもいい本との出会いがある気がする。レイアウトがいいのか品揃えのバランスがいいのか、いつも電車の発車時刻を気にして急ぎながら何か良さげな本はないかと見回しているのがいいのか分からないが。その点新大阪駅の本屋は全然だめだ、バリケードのように正面に立ちふさがっている棚しか眺めたことがないしそこにはしょうもない自己啓発本しかないイメージがある。あとは新宿サブナードの本屋も立ち寄りやすい、ビブリア古書堂の事件手帖(2)は確かそこで買ったのだ。本屋はでかければいいというわけじゃない、いい出会いを直感してウロウロできるのが自分に合った本屋だと思う。

そういえば昔どっかの旅館で弟が(夕食の量があまりにも多かったために)「料理は量も味のうち」と言ってたことがあったが、それと似てる気がする。料理が多ければ残せばいいんだけども、そのコントロールを客にさせるのがフラストレーションになることもある。だいたい、全部食べられたほうが満足に決まってる。

2012年1月7日土曜日

blogger記事内のURLを自動でリンク化する

なんかBloggerってURLを貼りつけても勝手にクリッカブルになってくれないので参考サイトの情報をのっけるのが不便。
ということでまずChromeのエクステンションをインストールしてみる。

ページタイトルとURLを一発でコピーできるChrome拡張機能「Copy Fixer 」
http://web-marketing.zako.org/hacks/google-chrome/copy-title-and-url.html

次にBloggerの設定→デザイン→ガジェットの追加→HTML/JavaScript
として次のコードを貼り付ける。これで、CopyFixerで貼りつけたURLがクリッカブルになる。
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script>
$(function(){
var html = $("div.post-body").html().replace(/[^">](http:\/\/[^\s<"]+)/g,"<a href=\"$1\" target=\"_blank\">$1</a>");
$("div.post-body").html(html);
});
</script>

以下は全てCopyFixerを使って貼りつけたもの。

知って得する21のRubyのトリビアな記法
http://d.hatena.ne.jp/keyesberry/20110622/p1

Ruby 1.9の19のtips
http://memo.yomukaku.net/entries/229

CoffeeScript
http://coffeescript.org/

CoffeeScriptはインストールしなくてもブラウザ上で実行できるよという話 - ariyasacca(2011-02-21)
http://sangoukan.xrea.jp/cgi-bin/tDiary/?date=20110221

Underscore.js
http://documentcloud.github.com/underscore/

Learn You a Haskell for Great Good! - Starting Out
http://learnyouahaskell.com/starting-out

2012年1月3日火曜日

Coffee Script など

javascriptを使っていて、文字列変数strがあるときに "<p>" + str + "</p>"と書かないといけないのは耐え難い、rubyのように"<p>#{str}</p>"と書きたい、ヒアドキュメントも使いたいと思ったのが発端で CoffeeScript を調べ始めた。
rails3.1で採用されているので名前は知ってたが、よそ者と思って軽視していた。いや実際、よそ者ではあるのだが。

- CoffeeScriptとは:
今日から始めるCoffeeScript から抜粋。

・JavaScriptにコンパイルできる小さな言語
・コンパイル後はJavaScriptとして動作するため実行速度面ではほぼ変わらない
・構文がRubyやPythonライク
・ブラウザ用の開発にもサーバサイドの開発にも使える

変数の文字列埋め込みとヒアドキュメントという当初の目的はズバリ達せられるほか、コンパイルが挟まるのはメリットがありそうだ。コンパイルによって生成されたjsはエラーがないだろうから。なんならWebサイトのjsは全てコーヒーで書いておき、コンパイル→ファイル結合→minify→キャッシュ制御用パラメータの更新をするデプロイの仕組みを用意するといい感じかも。このへんは動的システムであればフレームワークに吸収される流れっぽいが。

コンパイルされたjsの実行には node.jsを使うようなので、用意したばかりのcolinuxにインストールしてやる。
rubyで言うところのrvmのようなバージョン選択ツールがないか探してみたらあった。
naveというらしい。しかし何だかうまくインストールできない。
バージョン選択をする切実性もないので普通にインストールすることに。
node -v → v0.6.6

rvmの話が出たのでrails3.1もインストールしておこう。あとでrails with coffeeの味を見るために。
rvm install 1.9.3 とし、ここにrails3.1のgemsetを作る。
rvm use 1.9.3 → rvm gemset create rails31 → gem list --remote rails(ふむふむ、このままインストールした場合のバージョンは3.1か)→ gem install rails

※ruby1.9.3をインストールするときにunable to convert "\xC3" to UTF-8 in conversion from ASCII-8BIT to UTF-8みたいなエラーがでる(このへん参照)、rdoc関係みたいなのでどうせ不要ということであれば --no-ri --no-rdoc オプションをつけてインストールするとよい。

さて、とりあえずサーバサイドjsに慣れるため node.js を使ってみよう。node.jsとMySQLで割と普通のデータベースウェブアプリを作ってみるチュートリアルを参考に進める。
「express フレームワークを使う」のところまで何ら問題なし。ejsテンプレートのところ、app.use(express.bodyDecoder());
とあるがここで初めてエラーが発生。本家サイトを見ると正解はapp.use(express.bodyParser()); のようだ。

「MySQLとの連動」のソース、長いのでそのままでは動かないだろうなと思ってたが案の定いくつかエラーでた。
以下、修正点。
var sys = require('util'), // ← sysからutilに変更。追加モジュール必要なし
    express = require('express'),
    ejs = require('ejs'),
    //Client = require('mysql').Client, // ←コメントアウト
    base62 = require('./base62');

var client = require('mysql').createClient({user: 'xxx', password: 'xxx', host:'127.0.0.1'}); // ←追加
client.query('use データベース名'); // ←追加

//mysql(function(client) { // ←2ヶ所あるこの記述をコメントアウト(もちろん、対応する閉じカッコも)
※そのままだとエラーになり、client.connect は自動的に行われますよと言われる

if (err && err.number != client.ERROR_DUP_ENTRY) { // ←Clientの先頭を小文字に変更

あと、Error: connect ECONNREFUSED と怒られたので my.cnf の skip-networking をコメントアウトした。
これでとりあえず動く。次はちゃんとコーヒースクリプトを。

参考サイト:
http://www.dbonline.jp/mysql/
node-inspector
node.jsでmysqlを使う
CoffeeScriptでNode.jsアプリを書いてみる
無料で見られるプログラミング書籍一覧
Ruby 1.9 で Web アプリを想定したベンチマークをとってみた

2012年1月2日月曜日

Arch linux on Colinux のインストールメモなど

新年あけましておめでとうございます。ブログのタイトルを、暑いから寒いにしてみました。
今年はもうちょっと頑張って更新しよう。ということでまず実家(三田@兵庫)に持ち込んだThinkPad(去年2万円で中古購入)にarch linuxをインストールした記録から。

- colinuxとは:
  http://goo.gl/ShFBV とかにあるとおり、linuxのエミュレータ。昔はCygwinとかあったけど今はもうcolinuxでしょう。VMwareは設定が簡単だけど動作が重い、モバイルPCでは使えない。

- colinuxのインストール:
  http://dqn.sakusakutto.jp/2011/07/colinux-manual.html このへんを見ながら本体と7zipをインストールする。c:\colinux にインストールしたと仮定。
※バージョンは0.7.9(2011-04-09)

- OSのイメージファイルを取得する:
  http://goo.gl/DTmE このへんから好きなやつをDLする。今回は軽さ重視で、Arch Linux。

- Arch Linuxとは:
  http://ja.wikipedia.org/wiki/Arch_Linux こんなやつ。

- Arch Linuxのインストール:
  http://goo.gl/N4ypF からArchLinux 2011.08.15(2011-11-27 modified)をDL、解凍、c:\colinuxに展開。

- まずはいじってみる:
  arch.cmd が起動バッチになっている。DOSプロンプトからこれを実行(arch.cmd arch)。
ユーザーrootでログイン。ネットーワーク(wifi)も問題なくつながる。

- rubyのインストール:
  とりあえず何かインストールしたい、ということで。http://goo.gl/eznSs を参考にpacman -Sy。
あとはpacman -S rubyなどと。
問題なく入る。ruby 1.9.3p0 (2011-10-30 revision 33570) [i686-linux]

- ディスクの拡張:
  スワップ領域が少ない。ディスク領域もほとんどない、ので新しいイメージを用意する。
colinux tips(http://goo.gl/WgByo)を参考に。

プロンプトから以下を実行(c:\colinuxで作業)。
fsutil file createnew swap.img 134217728

arch.cmdをエディタで開いて、13行目あたりの記述を修正する。
set SW_ARCH=swap.img
※これが・・・100行目あたり、:_install の項目にあるcolinux-daemon -t ntという起動コマンドのパラメータに渡っていく、ちょっと見てみよう。

- スワップ領域を有効にする
  まずcolinuxを終了させ、arch.cmd arch で再起動。mkswap /dev/hda2 としてフォーマット。
swapon /dev/hda2 として無事スワップの使用が開始された(freeコマンドを叩いてみよう)。
※再起動前に、下記にあるkeymap設定もしておくとよい。
http://goo.gl/yiCLX
http://goo.gl/r8XFg

- ディスクの拡張:
  スワップと同じ要領でデカいファイルを作る(下記は2G)。
fsutil file createnew arch_fs.img 2146435072

colinux tipsの「colinuxのディスクがいっぱいになってしまった。拡張したい。」(http://goo.gl/WgByo
にある通り、colinuxの起動パラメータに hda3=arch_fs.img を追加して再起動。
※arch.cmd 112行目あたり↓

colinux-daemon -t nt mem=%MEM% kernel=vmlinux initrd=initrd.gz hda1=%FS% hda2=%SW% hda3=arch_fs.img cofs1=c:\ root=/dev/hda1 eth0=slirp,,tcp:8022:22/tcp:3000:3000

※ちなみにtcp:8022:22/tcp:3000:3000のとこは、windowsの8022ポートへのアクセスをcolinux(10.0.2.x?)の22へ、3000を3000へフォワードする意味。なのでsshdを立ち上げておけばputtyとかから127.0.0.1:8022へアクセスできるし、railsとかnode.jsのテストサーバを10.0.2.x:3000で立ち上げておけばhttp://localhost:3000/でつながる。

再起動後、フォーマット。/mntにマウント。cp -a でコピー。アンマウント。あとはこれをhda1として起動するだけ。
※colinux tipsの記述とは少し違うコマンドになった。
cp -a /bin /boot /dev /etc /home /srv /run /media /lib /opt /root /sbin /usr /var /mnt/

再びarch.cmd編集。6~8行目あたり。
set FN_ARCH=arch_fs.img
set FS_ARCH=arch_fs.img

先ほど追加したhda3=arch_fs.imgをトル。これで準備完了、あとは再起動すれば拡張されている(df -hで確認しよう)。

- その他参考資料
ネットワーク設定