関数型プログラミングから得られる改善
関数型で書いた際に、どういった事が可能になるか。
- コード量が少なくなる
- 最適化がしやすい
- 並行/並列化がしやすい -ドキュメントが少なくなる
- 状態を持たないので、関数を組み合わせて利用しても相互に影響しない
- 定理と証明
see also
「許可を求めるな、謝罪せよ」の言葉を通して
「許可を求めるな、謝罪せよ」
こういった企業文化いいなと思ったので、幾つか抜粋メモ。
事前に許可がおりることを持っているより 思い立ったらとにかくやってみるといい、 うまくいかなくても後から謝り、改良すればよい というハッカーマインドを鼓舞する言葉
まずはやってみる
- まずは作る、思い立ったらスピードを最優先する方が結果最終的によい方向に進みやすい
- 半ば強引なまでの積極性がないと
- チャレンジグになりたい
- 従え、心の声に
最小の許可で、行動をしたい。
see also
「ピクサー流 創造するちから」を読んだ
ピクサー流 創造するちから―小さな可能性から、大きな価値を生み出す方法
- 作者: エド・キャットムル著,エイミー・ワラス著,石原薫訳
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2014/10/03
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (9件) を見る
想像力と創造性を生みだす手助けとなるエッセンス、メッセージが沢山含まれている本であり、 エド・キャットムル氏が語るマネジメント論、ピクサーの想像力と創造性の秘密だけではなく、 各ヒット作の裏側。スティーブジョブズの人間性など、様々な側面が語られた本だと思う。
以下、メッセージをセクション毎に抜き出した。*1
デミングと日本企業に学んだこと
問題を見つけて直すのは、製造ラインの最上位の管理者から最も末端の人まで、すべての社員の責任である。 責任を持つことに許可はいらない。
いいアイデアといいスタッフ、どちらが大切か
正直さと素直さ
正直になることが義務のように感じられる人は、素直さを求められると多少気が楽になる。
できるだけ早く失敗しよう
失敗する可能性のあることに取り組むのが、本当に創造的な企業だ。
信頼とは、相手が失敗しないことを信じるのではなく、相手が失敗しても信じることである。
組織には野獣も必要
目標は緩く、意思は固くもつほうがいい。
創業者にしがみつかない
変化を止めて自分を守ろうとするか、変化を受け入れてそれを武器に返るのかどちらかだ。
ピクサーが集合的な思考の意識転換を図るために使用している8つのメカニズム
- 全員で問題解決（デイリーズ）
- 現地調査でつかむ本物感
テクニックは既知のもので、それを予期せぬ方法で使うのがアートだ。
- 制約の力
- テクノロジーとアートの融合
芸術は技術を挑発し、技術は芸術に刺激を与える。
- 短編で実験する
- 観察力を養う
- 反省会
- 学び続ける（ピクサー・ユニバーシティ）
生まれ変わったクリエイティブ集団
誰にとっても現金のボーナスは嬉しいが、それと同じくらい価値のあるものがある。
それは、尊敬する相手から面と向かって「ありがとう」と言われることだ。
まとめ
素直さや自由、建設な批判がピクサーの大切にしてある文化であり、
創造的になるための条件だと感じた。
パンチのある名言が満載でポジティブな気持ちになれる、また期間を開けて読み返そう。
see alsp
- ピクサーの魔法は「新しいアイデアが守られる文化」にあり ｜ ライフハッカー［日本版］
- 第16回 『ピクサー流創造するちから 小さな可能性から、大きな価値を生み出す方法』 〜映画という特殊な商品をビジネスとして成功させ、スタジオに活気をもたらすには、どうしたら良いか? - 映画ジャーナリスト ニュー斉藤シネマ１,２｜BOOKSTAND映画部！
*1:巻末付録に企業運営の指針が載っているのはとても親切
Facebookの文化「ハッカーの流儀」
Facebookの文化であり、マネジメント手法と唄っている
ハッカーの流儀
を読んで、共感する部分があったので纏めた。
ハッカーの流儀というのは継続的な改善と反復をともなう構築アプローチです。 ハッカーは常に物事は改良でき、いかなるものも完成することはないと信じています。彼らは直さずにいられないのです。 時には現状に満足した人々やそんなこと不可能だと言う人ばかりがいる中でそうします。
終わりがないものに挑んでいるからこそ、満足してそこで手が止まったらダメだと感じた。
以下、5つの価値
インパクトへの集中
最良の方法は常にもっとも重要な問題に集中するということ
素早く動く
壊してでも早く進め
大胆に
最もリスクが高いのは何もリスクを取らないこと
オープンに
人々はより多くの情報を手にしてより良い決断をし、よりインパクトの大きなことができるようになります。
社会的価値を生み出す
何をするときであれ、世界のために本当の価値をどう作り出すかに常に集中するということです。
まとめ
「コードは議論に勝る」
「リーダブルコード」を再び読んだ
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本（ソフトカバー）
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (132件) を見る
発売当初に読んだが、再び読んでみた。
TL;DL
「自分のコードを他人が読んだ時、理解するまでの時間が最短になる為のコーディング手段」を提示してくれる。今後も色褪せない良書であり、プログラマであれば、読むべき書だと思う。
Readableの定義
コードは他の人が最短で理解できるように書かなければならない
以下、各章で気になった言葉をメモしていく
2. 名前に情報を詰め込む
直行する概念は無理に1つにまとめようとせずに、別々に使えるようにするといい
3. 誤解されない名前
最善の名前とは、誤解されないものである。
4. 美しさ
間違ったスタイルであろうと、プロジェクトの規約に従う。
一貫性のあるスタイルは「正しい」スタイルよりも大切だ。
5. コメントするべきでは「ない」こと
コードからすぐに分かることをコメントに書かない。
6. コメントは正確で簡潔に
コメントは領域に対する情報の比率が高くなければならない。
7. 制御フローを読みやすくする
行数を短くするよりも、他の人が理解するのにかかる時間を短くする。
8. 巨大な式を分割する
「頭がいい」コードに気を付ける。あとで他の人がコードを読むときにわかりにくくなる。
9. 変数と読みやすさ
- クラスのメンバへのアクセスを制限する方法
- scopeは短く
- メソッドを出来るだけstaticに(メンバ変数とは関係ないことが分かる)
- 大きなクラスを小さなクラスの分割する
- 但、分割後のクラスが独立していれば問題ないが、クラスで相互にメンバを参照し合うようなら分割しても意味がない
- そもそも、一度だけ書き込む変数を使う、immutableに
10. 無関係の下位問題を抽出する
- 無関係の下位問題を積極的に探し出して、分離する
13. 短いコードを書く
最も読みやすいコードは、何も書かれていないコードだ。
14. テストと読みやすさ
- テストを読みやすくする、一般的な設計原則として
- 大切でない詳細はユーザから隠し、大切な詳細は目立つようにする
まとめ
目標かつ日々意識することを忘れたり、ぶれたりするような事があった際に、
この本に立ち返りたいと思う。
See also
「UNIXという考え方」を読んだ
- 作者: Mike Gancarz,芳尾桂
- 出版社/メーカー: オーム社
- 発売日: 2001/02
- メディア: 単行本
- 購入: 40人 クリック: 498回
- この商品を含むブログ (140件) を見る
古典を読んだ
基本的な9つの定理
- スモール・イズ・ビューティフル
- 1つのプログラムには1つのことをうまくやらせる
- できるだけ早く施策する
- 効率より移植性を優先する
- 数値データはASCIIフラットファイルに保存する
- ソフトウェアを梃子(てこ)として使う
- シェルスクリプトによって梃子(てこ)の効果と移植性を高める
- 過渡の対話的インターフェースを避ける
- すべてのプログラムをフィルタとして設計する
小定理
- 好みに応じて自分で環境を調整できるようにする
- オペレーティングシステムのカーネルを小さくする
- 小文字を使い、短く
- 紙のドキュメントを用いない
- 沈黙は金
- 同時に考える
- 部分の総和は全体よりも大きい
- 90パーセントの解を目指す
- 劣るほうが優れている
- 階層的に考える
まとめ
徹底して、「小さく小さく」「一つのことをうまくやらせる」べしと唄っている印象を受けた。
オブジェクト指向設計の基本原則「単一責任の原則（Single Responsibility Principle）」にもリンクする気がする。
