Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方 を読んだ

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方

• 競合が必要
• 新しいマーケットを作るのはとてもむずかしい。
• 自分がこの製品を使うか
• ソフトウェアの方法論の話は、なんとなく自分が感じてる違和感と似てる部分があるなぁ。
• より優れているではなく、違っていることが大事。

空気を読むな、本を読め

空気を読むな、本を読め。 小飼弾の頭が強くなる読書法 (East Press Business)

目的

• 自分を読むとかどういうことか
• 「手」で読む、「脳」で読む とは
• 具体的にどう読んでるのかを知りたい

方針

• 2章、3章、4章をじっくり。あとはざっくり読む。

メモ

• 読書量と収入は比例する 　→感覚として分かる気がする…
• 読書を「〜しなけｒばならない」にするのはよくない
• 時間をコストで考える → 時給換算
• 相手が一方的に押し付けてくる情報はすべて捨てる
• 情報がない状態をみずからつくって、情報に飢える
• 読んだらアウトプットしましょう
• マキャベリ「君主論」「政略論」 　→政略論初耳
• 難しい本を読んで自信をつける
• とにかくページをめくることを繰り返す。わからなくてもいいからめくるのもいい。 →手で読む
• 書くことは大切。
• 伏線張っちゃうと「解説」になる。→目次が付箋の役割を果たしてる
• 初めて読む本を考えながら読んではいけない 　→ 2度読む方が理解深まる
• 目次で気になるところだけ読む
• 目的を持つことをやめる≒「〜しなければならないこと」をやめる
• 参考文献を読む
• 1冊読む→参考文献から読んだ本と関係無さそうな本を読むを6冊ほど
• 自分の意見とまっ効果あ対立する本を読む 　→これは意識的にやるようにしてるけど、最近弱くなってるかも…
• ケチをつけながら読む
• エロに求められるハードルの高さ 　→これはわかる。逆の場合も成立しそうだけど。とりあえず可愛い子がやってればいいみたいなやつ。AVだと前置きはいいからSEXシーンだけみたいな。

Computer Science... without a Computer!

最近、ニコニコ動画にあるエンジニアのプレゼンをよく見てる。

今日はずっとこれを見てた。Googleの鵜飼さんのプレゼン。

そこで紹介されてたコンピュータサイエンスの本をさっきまで読んでた。
Computer Science Unplugged |

日本語版はコレ

コンピュータを使わない情報教育アンプラグドコンピュータサイエンス

すごくわかりやすい。一度やさしいコンピュータサイエンスに目を通していたけど、こうして改めて読んでみるとまた発見がある。

昨日みた。河野先生のインタビューのやつも、訳書が出てからでは遅いとかいう話もしていたし、確かいい論文ほど英語で出ているって記事を見たや。

未知の分野の論文を読むときの10のポイント - EchizenBlog-Zwei

小学生向けのやつだったからかわからないけど、時間はかかったけど、結構読みやすかった。
毎日読む習慣が付けれるように、来週あたりまでは読むようにしよう。

たくさんフリーの本あるしね！
無料で見られるプログラミング関連書籍一覧 - YAMAGUCHI::weblog

ソフトウェアの達人たちを読んだ

ソフトウェアの達人たち―認知科学からのアプローチ

感じたのは、すごくベタだけど、何かモノに触れるときは、ユーザーが使い方を考えずにいかにふれることができるのかってこと。

UIとかUXとかそこらの話になるんだろうけど、そこも読んだり使ったりして、学んでいきたいなぁ。

どんどんたまる知識欲。

今度はこれ、読んでみよう。

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

すごい物を見てもへこたれないために - teruyastarはかく語りき

こういうマインドセットで、頭悪いなりにこなしていくことを楽しめたら、見たい世界がみえるんだろうね。

codecomplete読み(4)

Code Complete第2版〈下〉―完全なプログラミングを目指して

23章 デバッグ

• 最初はエラーが自分の責任ではないように見えたとしても、そうであると考えてみるべきである。そう考えるだけでもデバッグに役立つ。

• 欠陥を検出する効果的な方法

　1.エラーを確実に再現させる
　2.エラーの原因を特定する
　3.欠陥を修正する
　4.修正をテストする
　5.同様のエラーを探す

• よく考えることと良いデバッガを使用することが最も効果的な組み合わせである

「バグは自分の作ったプログラムを説明できないことから発生するもの」と読んでて思った。

デバッグとかそんなにしたことないひよっこなので、実感として湧かない部分が多く、「そうなんだー」ぐらいにしか思ってないので、再読の必要がありそうです。

実践 デバッグ技法 ―GDB、DDD、Eclipseによるデバッギング

この本がギー沖にあるので、手を動かしながらやってみたい。

Wikiで沖縄を見たい。

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

以前、ギー沖に一週間ほど滞在して下さった、@etoさんの本を読んだ。

用語とか分からなくて、挫折するんだろうなーと思ったけど、サクサク読めたし、むしろわからなくてもここで説明してくれてるので、逆にとっかかりとしてすごくいい本だなぁと思います。

参考文献に掲載されている本も漁ってみよう。

でこの本を読んでて思ったのが、僕の今いる、沖縄ってものをWikiを使ってまとめることってできないのかなってことです。

観光情報とか、書店で売ってるものよりも、住んでる人とか、沖縄フリークで自身のおすすめスポットなんかも持ってるはずだし、それが各人だけにストックされてるよりは、もっとオープンに、まとまる場所があってもいいと思った。

そういう各人それぞれに依存してる、ノウハウというか、情報をまとめるような何かが欲しいなぁ。

というのも、ギー沖にお越しになる方が、実は僕らよりも沖縄詳しいってことに遭遇するのが、すごく面白くて、なんというか、そこで新しい沖縄に出会えてる感じになる。

と頭で語ってもしょうがないので、ちょっと作ってみようかなと思った。

PythonでもWikiエンジンあるみたいですね。
MoinMoin - Wikipedia

codecomplete読み(2)

Code Complete第2版〈上〉―完全なプログラミングを目指して

19章 制御構造の問題

• 深いネストを減らすテクニック

　・条件の部分的な再評価
　・if-then-else文への書き換え
　・case文への書き換え
　・深くネストしたコードのルーチンへのファクタリング
　・深くネストしたコード全体の設計の見直し　など

• 構造化プログラミング

　→核心はプログラムは入り口１つ、出口が１つの制御構造を使用すべき

• 構造化プログラミングの３つの要素

　・連続（代入文、ルーチン呼び出し）
　・選択（if-then-else文）
　・反復（while, for文）

• 制御構造の複雑さ

　→理解の労力≒構造の複雑さ
　　→なるべく複雑さを取り除いた形を目指す

• 複雑さを軽減するためには

　・プログラムを理解するために必要な頭の中で理解するオブジェクトの数に磨きをかける
　　→せいぜい５〜９とかだろう
　・プログラムの複雑さを減らして、理解に必要な集中力を減らす
（前節と同じ事を言ってるようなななな...解決策じゃないんじゃないかなぁ）

• 複雑さの定量化

１．ルーチンのストレートなパスを１と数える
２．if, while, repeat, for, and, or,などにそれらに相当するキーワードを検出するたびに１を追加
３．case文の選択肢ごとに１を足す

ルーチンひとつに0〜5個以内であれば、適切なルーチンとする。

チェックリストは以下（登録してないと見れない...。登録した。）

Code Complete 2nd Edition