バイブル的書籍にざっと目を通す（大体「プログラミング言語○○」って名前）
辞書的なリファレンスマニュアルと首っ引きでなんか作る(.chmみたいのでさくさく引ける状況が理想だけどオンラインマニュアルでも可)
2, 3個作ってみて「なんか時間かかるなー」「なんか無駄がある気がするなー」と思う
「その言語を美しく効果的に適切に使うための本」を読んで何度も頷く ”
言っていることがいちいちすごいまとも。勝間和代って言っていることは、ものすごいまともなんです。たくさん本を読んで情報を蓄えた上で、インタビューの質問に対して「視聴者に自分の価値を如何に高く見せるか」をものすごく意識した回答を丁寧にしていると思います。これこそ経済評論家としてのプロの姿勢です。そのプロの姿勢が彼女のおもしろさを引き立てています。 ”
自然淘汰はある（むしろふつうに店を運営するよりもよっぽど淘汰される確率は高い）。だけど、俺にとってもアルバイトにとっても、可能な限りストレス少なく、高レベルの店を回すということについては悪くない方法だと思っている。
まあ、実際にはこの方法には、たとえば研修はやたらに丁寧にやらなきゃいけないとか、採用する人間は厳選しなきゃいけない、つまりは面接のテクニックが重要になってくるとか、いろいろ付随する条件はあるんだけど、基本的には、店のトップが「仕事を高いレベルでこなすことは喜びなんだ」という一点を表面上は疑わないこと。そしてその「喜び」を伝えるためにやってるんだと信じること。それさえしっかりしてればどうにかなると思う。
ちなみに、最悪なことに、俺自身は、仕事を高いレベルでこなすことそのものに大して喜びなんか感じなくて、ただ利益のためにやってる部分が多いんだけど、トップだけは、前提を無根拠に信じないことが重要なんじゃないか、と最近は思っている。仕事はすばらしい、社会貢献最高、利益のアップが無条件でモチベーションアップにつながるとか、そういうお題目を、トップだけは疑ったうえで、現状にあわせて、選択的に当面の店の方針を決める。それができないと状況が変化したときに、ドグマにしがみついて自滅するんじゃないかな、とかも思ってる。
”種明かしはこうだ。簡単なことだ。店のなかから笑顔が消えた。なるほど、声は出てる。接客もマニュアル的には悪くない。けど、客がその店に入ってきたときに真っ先に感じるものはなにか。
おそらくは、威圧感だ。
コンビニに来る人間にはさまざまな人がいる。みながみな買いもののためだけに来るわけじゃない。「なんとなく入って、無駄遣いしていく人」が、コンビニにとっては相当に重要だ。日常、コンビニに限らない、利用する店について人はなんとなくイメージを持っている。「なんとなくいい店」「なんとなく感じの悪い店」などなど。その「なんとなく」の源泉は、もちろん接客でもあるだろうし、意外に重要なものとしては店の照度だったりもする。俺は、恐怖支配で店を運営するうちに、この「なんとなく」をごっそりと取り落とした。客にとって「なんとなく寄りたい店」を作ることができなかった。客の来店頻度は落ち、常連客を取り逃す。
そして崩壊だ。
崩壊は、クレーマーと店内不正というかたちでやってきた。些細なミスに対して寄せられたクレームに対する対応を俺は誤った。うちの店は完璧だという自負がある。取るに足らないミスでそこまで執拗に追求される覚えはない。頑強に突っぱねたクレームは恨みを呼ぶ。客の店に対する愛着のなさが、クレーマーというかたちで突出した。いまの俺はそう考える。当時は「異常な人間はほっとくしかない」って考えてたけど。
”未踏などでもやたらオープンソースにしたがる採択者が多かったが、闇雲にオープンソースに拘るあまり実際の事業化が遠ざかっているように見える人を散見した。
よく考えて欲しい。成功しているWeb2.0企業は重要なコードなどなにひとつオープンソースになんかしていないのだ。
Google、Twitter、mixi、Facebook、Amazon。彼らはオープンソースコミュニティの成果を利用しこそすれ、自分たちの利益を生む最も重要なシステムのコードを公開することは決して無い。それはとても意味のあることなのた。
”それでも今回のような流用のされかたが嫌だったら、ソースの中に仕掛けをして、ソースを読み解かないとタイトル画面が変えられないような難読化をするとか、肝心の部分はサーバサイドにして、クライアントサイドのソースはどうでもいいものにするくらいしか対策はない。それでも嫌なら無制限にソースは出さないことだ。
ソースを公開するときに最も考えなければならないのは、「ソースを利用されて自分が一番嫌なパターンはどんな使われかたか?」ということだ。それを先に想定し、先回りして禁止しておかなくてはならない。もちろん完璧なものは(あのストールマンとて)無理だが、有る程度のことは覚悟出来る。
サンプルコードに加えたわずか10%の変更がソフトのアイデンティティになったからだ。
サンプルコードなんて90%以上は誰が書いても同じになるような定型文で、そもそも定型文とはなにかを学ばせるためにあるのがサンプルコードだ。
エジソンではないが、1%のインスピレーションが全てを変えてしまうのである。
プレイステーションのゲームだってサンプルコードから作られたゲームは無数にあるだろう。
僕が作った時は、ムービー再生の部分まるごとコピペした。
広い意味でいえば、サンプルコードとはソース付きの標準フレームワークのようなものだ。
便利ならば使った方がいいに決まってるのである。
”しかし実際にオープンソース活動をやっている人たちは、ヒッピーのユートピア的な発想のまま無防備にソースを公開し、あとで嫌な思いをしていることが多いように思える。
モラルが低い人をどれだけ憎もうと、そういう人間は確実に存在するし、根絶は不可能なのだ。
ゴキブリをどれだけ憎んでもその存在が消滅しないのと同じである。
ではどうするか。
ゴキブリが生きて行けないような家に住むしかないのである。
バルサンを定期的に焚き、ゴキブリコンバットを要所要所に配置するなど、それは対処療法ではあるが確実に効果のある方法だ。
最近GNUライセンスが嫌われているのは、要するにこれは過剰なまでに攻撃的な防衛戦略を織り込んだライセンスだからである。
コードの原型の作者がなにをされたら嫌か、それを徹底的に考えてある。
”この本は、「アキレスとカメ」を含むゼノンの4つのパラドックスについて、俗書が論じてるその論じ方に対し、批判的検討をするものだ。例えば、「アキレスとカメ」は、ご存じのように「のろまのカメが、足の速いアキレスよりもちょっとでも早く出発すれば、アキレスはカメには追いつけない」というもの。多くの本では、無限等比級数の和の公式を使って、「追いつく」ことを示し、このパラドックスを打破した、としている。けれども、吉永さんは、そういう方法では打破できていない、と打破を打破している。
まず、吉永さんが主張するのは、「ちゃんと原典を読め」ということである。オリジナルでないものに対して打破してもそれは打破ではないだろう、というわけだ。オリジナルの文は、次のようなものだそうだ。
走ることの最も遅いものですら最も速いものによって決して追い着かれないであろう。なぜなら、追うものは、追い着く以前に、逃げるものが走りはじめた点に着かねばならず、したがって、より遅いものは常にいくらかずつ先んじていなければならないからである。 アリストテレス「自然学」
吉永さんは、このオリジナルの文章の中に、いくつか注目すべき点がある、と指摘している。第一は、どこにもアキレスやカメの「速度が一定」などとは書かれていない、ということ。第二は、どこにも「永遠に追いつかない」という「時間」に関する言及がない、ということ。第三に、さりげなく「点」ということばを入れ、ユークリッドが「原論」の中で「点とは面積がないものである」というイデア的な定義を与えた、その定義に立脚していることを匂わせていること。
その上で吉永さんは、無限等比級数を使った打破が、打破になっていないことを論じる。実際、全く同じような数理モデルでこのオリジナルの文章に適合するものを作り、「追いつかない例」を具体的に与えている。もちろん、これは「永遠に」追いつかない例だから、トンチ解答とかでは全くない。ぼくもこれまで聞いたことのない反駁方法で、とても感心した。これ以上書くと、ネタバレになってしまって、せっかくの吉永さんの功績を邪魔してしまうので、その「打破の打破」は本を買って読んで欲しい。
”