「逆転力」を読んだ

読み取れたこと

  • キャラは自分じゃなくて他人に付けられるものだ
  • 付けられたキャラには全力で乗っかれ
  • 自分が勝てる舞台で勝負しろ
  • アンチは悪いことではない
  • ピンチはチャンス

感想

http://spotlight-media.jp/article/135371327043747048を読んで気になって読んでみた。テレビで見るアイドルの中でかなり異質な存在で目立っている指原さんには昔から興味があり、最近「ワイドなショー」などのコメンテータとして案外鋭い意見を出していて頭がいい子なんだろうと思っていた。でも、この本を読んで少し変わった。

若い割には知識も多いんだろうけど、そこまで突出して多いわけでもない。人生経験も壮絶と書かれているけど、そこまで壮絶なわけでもないと思う。そんな指原さんが芸能界で戦うために磨き上げた、磨き上がった力が「空気を読む力」と「客観視」なんだろう。どんな時でも自分を客観視しして、自分がどういう立場でここにいてどういう発言をすれば周りにどういう影響をあたえるかということを常に考えながら生きているんだろう。

読んだ感想としては良く言えば軽く読める、悪く言えば薄い本。大体1時間弱ぐらいで読める分量なのでちょっとした時間に読むにはちょうどいいのかもしれない。この内容を読むと5時間ぐらいアンケートしてそれを本に起こしたんじゃないかと邪推してしまう。読むなら気合を入れずに肩の力を抜いて読むのがいいんじゃなかろうか。

「たった一人の熱狂」を読んだ

読み取れたこと

  • 義理、人情、恩義を大切にしろ
  • 小さな約束でも無碍にするな
  • 熱狂できる仕事を見つけろ
  • 結果にこだわれ
  • 人はだますな
  • 安めを売るな。恩を売れ。

まとめ

http://spotlight-media.jp/article/122258070674086540を見て、興味をそそられて読んでみた。もともとすごく熱い人なんだろうと思っていたがこの本を読んでさらにその思いは強くなった。「たった一人の熱狂」というだけあって、この人はやることなす事全てに熱狂して生きてきたんだろうなと思う。

なかなか真似できない人生を歩んできているんだろうし、この人になろうとして真似しても普通の人はなかなか難しいんだと思う。そういう人だからこそこうやって本を書いて出版したりできるんだろうがここまで熱狂的な熱い文章を僕はあまり読んだことがない。1文字1文字にきっちりと魂を込めて書いているというか、確固たる自分というものを持っていて、自分の人生に絶対的なブレない価値観というものを持っていないとこんな文章は書けないんだと思う。

今日という1日は死から最も遠い日だ。1分後には、今より死に1分近づく。10分後には、今より10分死に近づく。僕は70歳で死ぬかもしれないし90歳まだ長生きするかもしれない。少なくとも今この瞬間は、死から一番遠い時間にいる。

本から抜粋したものだがこの文章が見城さんという人の生き方を一番表している文章なのではなかろうか。人はいつか必ず死ぬ。どうせ死ぬなら後悔しない人生を歩みたいと考えるのはふつうのことだろう。そこら辺を歩いている人間を捕まえて「あなたは死ぬときに後悔しないように生きたいですか?」と聞いたとして、「私は死ぬときに後悔したいです!」と答える人なんてほぼいないないだろう。大抵の人間は後悔しない人生を歩みたいと考えているものだ。

しかし、そう考えている人のなかで「あなたは死ぬときに後悔しない人生を歩めていますか?」と聞かれて自信をもって肯定できる人はどれだけいるのだろうか。どんなことにも妥協することなく、後悔しないように生きるなんてできるわけない。自分に厳しければ厳しいほど後悔はでるだろう。妥協なく自分を肯定するには毎日血反吐を吐き、これ以上に努力することは出来ないと自分が思えなければいけない。そして、今日一日血反吐を吐く努力をした次の日はそれを超える努力をする。その繰り返しができる人間こそ後悔しない人生を歩んでいると自信を持って言えるんではなかろうか。見城さんは自信をもって肯定できるように日々努力をしていて、その結果圧倒的熱狂が授かったんだと思う。

誰よりも熱く人生に熱狂しながら生きている人間が書いている文章を読める機会なんてそうそうないと思う。どこまでこの本を咀嚼して自分の中に取り込むことが出来たのかは分からないが、ここまで熱狂しながら生きている人間がいるからこそ社会は回るし人類は成長することが出来たのだろう。今までの人生を振り返ってきて、圧倒的な熱狂というものは存在せず今まで淡々と生きてきた気がする。ここまで熱狂していきたいとは思わないが少しは熱狂して生きてみるべきなのかもしれないと考えさせられた一冊だった。

「運を支配する」を読んだ

読みました。以下感想。

僕が読み取れた内容の箇条書き

  • 驕るな。自分はそんなに頭のいい人間ではない。
  • ただし、できないと悲観するな。ポジティブにやれ。
  • 運が無いと嘆くな。運は誰にでもいつか回ってくる。
  • 回ってきた時に掴み取るために日々淡々と努力して準備しておけ。
  • 運が回ってきて今が勝負だと思ったら死ぬ気で努力しろ。
  • 答えを求めるな。大抵のことに明確な答えはない。
  • いい人であれ。
  • 人に借りは作るな。貸しを作れ。
  • 失敗を悔やむな。俯瞰して失敗した原因を探れ
  • ただし、開き直るな。開き直るのは大抵の場合に悪手となる。

読み終わって思ったこと

一番心に残ったのは「物事には答えなんてない」ということ。たしかに実社会で起こる様々な問題には学校のテストのように明確な答えなんてない。人が変われば正解も変わるし、環境が変われば正解も変わるだろう。悩んだ末にたどり着く答えというのは現時点での自分にとっての最適解だというだけであって、それは絶対的な正解ではない。世の問題の答えは雲のように漂っていて見る角度や時間によって形は変わるものなのだろう。悩みに悩んだ正解もそれが絶対的に正しいということはないということを肝に命じて流動的に柔軟性を持って問題に向かい合い続けるのが大事なんだと思う。

文章的に読みやすく噛み砕いて書いてあるのでわかりやすいと思う。この間テレビを見ていて言っていたのだが大会社の社長ほど腰が低く驕らない人間が多いそうだ。自分はすごい人間だと思った時点でその人間の成長は衰退を始めるし足元をすくわれることも多くなるのかもしれない。「運がいい」というのは「勝負するタイミングを間違えない」ということだし、「運を手放さない」ということは「日々努力してチャンスを物にできる力をつける」ということなのだろう。本書でも記載されているがそう考えれば運が尽きるということはなく運は無限だ。何事にも近道はなくて近道を探せば運は遠のく。日々淡々と努力するのがあとから見ると一番の近道なのかもしれない。

JavaScriptの良い書き方とは

『JavaScript:The Good Parts 「良いパーツ」によるベストプラクティス』を読んだので覚書。内容はJavaScriptのバグの出にくい書き方をまとめた本。どちらかと言えば初心者向けの本で、こう書いたほうがいいですよーって感じのことを書いてる。けど、書き方が難しい。。。Good Partsの本と書いてあるけど、付録に記載のある「ひどいパーツ」「悪いパーツ」を見たほうが勉強になると思う。JavaScriptに特化していて、やらないほうがいいってことを書きだしてみる。

グローバル変数は使うな!

JavaScriptだとブロックスコープがないので、気をつけないとグローバル変数になってしまう。うまく関数スコープを使用してグローバル領域を汚さないようにプログラムを書きましょう。

(function(){
    // こんな感じで即時実行関数で括ってしまえば
    // グローバル領域を汚さない
    var hoge, hogehoge;
})()

==, != は使うな!

==, != の判定は予想外の行動を起こすことがある。==, != は、大抵の場合 ===, !== に置き換えれるため、こちらを使いましょう。

withは使うな!

JavaScriptではプログラムの記載を省略するためにwithを使用することができるが、こいつも予想外の行動を起こしやすいので使用しないようにしましょう。

newは使うな!

newを書き忘れるとバグの発見にすごく手間がかかるのでnewを使うのはやめましょう。って書いてあるんだけど、僕としてはnewは使うなというか、Classの概念を持ってくることはあまり好ましくないような気がしている。Classの概念とJavaScriptは相性が悪いと思う。

evalは使うな!

文字列をコンパイルして実行するevalを使うのは極力控えましょう。evalはコンパイルが走る分実行速度が遅くなります。

setTimeout、setIntervalに文字列を渡すな!

setTimeoutやsetIntervalでは第一引数に文字列を渡すとevalが走って実行することになります。そのため実行速度が遅くなります。わざわざevalを実行させる必要はないので、functionできっちりと定義しましょう。

まとめ

なかなか面白い本だった。記載してあるグッドプラクティスはすべての言語で共通して言えることも多いので、これからJavaScriptをはじめる人っていうよりもこれからプログラミングをはじめる人が読むといい本かもしれない。

人は(ry を読んだ感想

「人は自分が期待するほど自分を見ていてはくれないががっかりするほど見ていなくはない」を読んだので感想。読み終わって引っかかったものを書いてみる。

縛りがあるから面白い

俳句の例とか非常にわかりやすい。人はなにか縛りがあるから面白いものをひらめくっていうのはそのとおりかもしれない。視点を変えてみると、幅が狭い中でみんなで考えているから出てくるものが少なくて、それがあったかーって他の人がなり易いから面白いものをひらめいているように見えるってだけかもしれない。ただ、何かを考えるときにわざと幅を狭めて考えるっていうのは案が収束しやすくなることは確か。

友情だけはギブアンドテイク

これは寂しい。僕は逆に仕事がギブアンドテイクだと思う。何かもらえるから仕事をするわけで、見返りを求めなければいい仕事は出来るって言ってるけど、たぶんそれはその先に何かがあると踏んでいるから見返りを求めずに仕事が出来るんじゃないかと思ってしまう。友情こそ見返りを求めずにいけるんじゃなかろうか。切磋琢磨する素晴らしい友人関係もあればその人達の中にいると安らかになるという友人関係もあってもいいと思う。

ヒットしたものは全て正しい

腑に落ちる言葉。自分から見たらどんな馬鹿げたものに見えたとしても他の人に欲求があったからヒットするわけで、自分の面白い・面白くないっていう感想を抜きにするのであればこの言葉は正しい。ただ、流行ると思うけどこれは作りたくないっていうものとか、流行らないと思うけどこれは作りたいとか個人的にはあって、そういうのがあるから技術者なのかなーと思う。

独占は成功の母

アメーバの戦略が出てて面白い。

わが友、不眠症

どちらの方もよく働かれている。1日30分しかねらずにずっと仕事を考えてるとかすごすぎる。前に読んだ「渋谷で働く社長の日記」を読んだ時も働く時間が長いなーと思ったけど、見城さんもすごい。人間は最低でも1度はすごい仕事をする時間というものをとらないとこの方々みたいにはなれないんだろうな。絶対にうまくいくかわからないものに対してここまで熱い時間を投資するって感覚を持つ必要があるのかも。少しは見習いたいものです。

人は一つの人生しか生きられない

成功していろいろなものに手を出して失敗しちゃった人は僕も見たことある。他の人がそれに対して心血を注いでやっているのに、それを片手間でやって成功しようという考えがそもそも甘いと僕も思う。

まとめ

前の本でも思ったけど、見城さんが「剛」で藤田さんが「柔」っていう見え方をする本に出来上がっていると思う。おふたりとも仕事に心血を注いでいる感がひしひしと伝わってきて成功する、成功したとみなされてる人っていうのはここまで努力をしているのかと改めて思わされた。

JavaScriptの高速化試作の覚書 – JavaScriptグラフィックス

『JavaScriptグラフィックス – ゲーム・スマートフォン・ウェブで使う最新テクニック』ってのを読んだので必要そうな部分を抜粋

速度測定の指標

動作速度は端末によって違う。だからある一定の指標が必要。以下のコードを走らせることで、その端末で1秒間にどれだけの動作を行うことができるのかの指標を取得することができる。これを用いることでどの端末でも動作改善試作が表す影響を見ることができる。

var StartTime = new Date().getTime(); for(var count=0 ; timeElapsed < 1000 ; count++) { // ここで検証する動作を行う timeElaspsed = new Date().getTime() - startTime; } [/code]

countが増えれば増えるほど動作速度の向上を意味しており、改善前と改善後での数値の差に注目する。ただし、Firebugとかで計測できる環境があるならそれを使うのが一番いい。

高速化実装試作

  • 80-20のルール(20%のコードが80%のCPU時間を使う)に基づいて20%に力を入れて高速化をおこなったほうがいい
  • 三角関数等の重い計算処理を行うのであれば、結果をテーブルとして持ち近似値を使用したほうが早い
  • 複数の判定要素がある場合は、各ビットでフラグを表現し&演算子で判定を行ったほうが早い
  • XORをうまく使ってtoggleを実現できる(ex. toggle ^= 1;)
  • Math.Floor()よりもビットシフトを使用したほうが早い(ex. x = y >> 0)
  • jQueryのセレクタ指定は呼ばれるたびに検索が走るので複数呼ばない。複数呼ぶ場合は変数へキャッシュする。
  • jQueryのセレクタ指定は検索開始を指定することができる(ex. $(‘.class’, start-element);)
  • jQueryのcss演算子は遅い。複数変更する必要がある場合は、styleオブジェクトを抽出して変更する。(ex. $(‘#element’)[0].style)
  • 複数の要素を追加する場合は追加する文字列を作成して一回で追加したほうが早い。

アニメーション

どのような端末でも一定のスピードを保証するためにフレームレートを指定する。1秒間にどの程度の動作を行うことができるかを取得して、それに伴いアニメーションの移動距離を変えることでどの端末でも一意のスピードを保証することができる。例えば、1秒間に500回動作する端末(A)と1秒間に100回動さする端末(B)があった場合、どちらも同一のスピードを再現したいのであればBは1回の動作でAの移動距離の5倍移動させれば同じスピードを表現することができる。

まとめ

高速化について知りたくて呼んでみた本なんだけど、高速化の実装は最初の方にしか書いてなかったので非常に残念。アニメーションをJavaScriptで記載する場合(ゲーム等)は参考になる記述もたくさんあるようなので、もしゲームを作ることになったら更に深く読むことにする。


アジャイルという考え方

アジャイルサムライを読んだ。組み込み系からWeb業界に移動してきた僕にとっては有益な話が多かくて、忘れる前にメモ程度に書いておこうと思う。

インセンティブデッキを作成する

以下の5項目をプロジェクト開始時に決めておく。

  1. 我々はなぜここにいるのか?
  2. エレベータピッチ
  3. パッケージデザイン
  4. やらないことリスト
  5. ご近所さんリスト

自分たちが何を作成するために集められて、それを作成することでどういうことが起きるのかをまず統一化する。エレベータピッチをみんなで共有することもそうだし、パッケージデザインで作るものの意識を共通化させるのもそう。作成している間にやりたいことやこれがあったらいいというものはどんどん増えていくけど、これは今回の開発では絶対に「やらない」というものを決めておくというのも面白い。ご近所さんリストは大規模開発じゃないとあまりないかなーと思う。

見積もりは変わる

きっちりとした見積なんて最初からできないものだと割りきって考える。最初からできないんだから後からすこしずつ変えていけばいい。そうすれば見積が変わっていくことに対していちいちストレスを感じることもない。出していた見積は作業をすることで時間が変わるものだし、要件は作成している間に増えるものである。要件が増えそうになった際には時にやらないことリストや、パッケージデザインをそれは本当に必要かをその都度見積り直せば良い。まずは大体で見積もって終わりになるほど精度が高くなればいい。

ストーリーを語る

技術者は技術で語る癖がある。データベースのレスポンスを早くする。とか、アニメーション処理をCSSで書くとか。それは技術者間で話すには良いのだけど、技術者ではない人と話す場合はその作業によってユーザ見えでどう変わるのかを話したほうが良い。データベースのレスポンスが早くする。っていうのは、画面表示を早くするって言い換えれるかもしれないし、アニメーションをCSSで書くというのはなめらかなアニメーションを実現するって言い換えれるかもしれない。やっていることがどういう効能があるというのを共用することは大事。

概算見積もり

技術者から見て同じぐらいの重さのものをグループ化してポイント化する。例えば10個のタスクがあったとして、1ptが5個、2ptが3個、3ptが2個みたいな感じで。これも大体でいいらしい。んで、とりあえずやってみる事で、1ptにつきどの程度時間が掛かるかを見積もる。こうすることでスケジュールが進むに連れて見積もりの精度がすごく高くなる(*1)。どう考えても最初に提出したスケジュールに間に合わない場合は、タスクを削る。もしくは時間を伸ばす。間に合わないということがわかるのも見積もりを行なっているからで、スケジュールに間に合わないということが早めにわかって良かったとポジティブに考える。基本的にはスケジュールを伸ばすのではなくタスクを削るほうがうまくいく。作成した機能の25%程度しか使われないのが一般的らしいのでシェイプアップという意味でもタスクを削るっていうのはいいのかもしれない。

バーンダウンチャート

横軸に時間。縦軸に残作業量でグラフを書く。時間が立つほど残作業量が減っていき、残作業量がなくなった時点で作業は終了。見積もりが正しければ作業量と時間がきちんと見積もれているため右下に一直線のグラフとなる。作業量と時間とがわかりやすくていいなぁと思う。Readmineとかでも同じといえば同じなんだけど、全体の作業量から引いていくっていう感じで作れないものかなぁ。僕としては縦軸を作業量としてある一定量まで上に上がれば作業が終了としたほうがいいと思う。こっちの方が途中の仕様変更等で作業量の絶対値が増えた場合に対処がしやすいし、わかりやすい。可視化って大事だと思った。

まとめ

僕は組み込み系のきっちり決まった仕様・スケジュールで仕事をしてきて、今現在状況に応じて変わるスケジュール・仕様・作業量が変わる業界に移って戸惑っているんだけど、考え方を変えるって意味で読んでみてよかった。いろいろ腑に落ちる考え方とかも多かったし可変的にものを作成する環境にいる人は読んで損はない本だと思います。

*1: 書いてて思ったけど、まぁ普通にやってるな・・・。