ikejirirb 12回目Jun 1

※週一ランチタイムの読書会 ikejirirb/POODR

やったこと

  • p237 ~ p263
  • 第9章費用対効果の高いテストを設計する ~ 9.2 受信メッセージをテストする

memo

  • p237

    • 変更可能性こそが設計時に唯一問題と鳴る指標です。
    • リファクタリングとは、ソフトウェアの外部の振る舞いを保ったままで、内部の構造を改善していく作業を指します
  • p238

    • リファクタリングでは新たな振る舞いを追加することはない
    • リファクタリングは小さくカニのような歩みでインクリメンタルに慎重にコードを変えていく厳密なプロセス :crab:
    • 変更可能なコードを書くためには、価値の高いテストを書く能力が求められる
    • テストの真の目的はコストの削減
  • p239

    • テストにコストが掛かることの解決方法は、テストをやめることではなく、テストを書くのをうまくなること
    • できることを初期段階で知ることは将来利用可能は設計の選択肢をかえるために、他の案を選択し直すきっかけになる
    • テストは唯一信頼できる設計の仕様書になる
    • 将来の自分は記憶喪失になっているとでも思ってテストを書こう
  • p240

    • 具体的なケースを単一の抽象として扱うコードによって、いつか報われるときが来ることは知っているものの、現時点ではその抽象がどんなものになるか予測するための十分な情報がない
    • 意図的にインターフェースに依存することに寄って、テストを使い、設計の決定を安全に代償もなく遅らせることができる
  • p240

    • 良い設計は自然と抽象に依存する独立した小さなObjectの集まりになる
  • p241

    • コードベースが拡大し幾つもの抽象が育っていくと、テストの重要性も一層ましていく
    • テストを書くのが大変なのであれば、他のObjectから見ても再利用が難しい
    • テストにコストがかかるカロ言って、必ずしもアプリの設計がまずいわけではない
  • p243

    • 一般規則として、Objectは、自信のパブリックインターフェースを構成するメッセージにたいしてのみ、状態についての表明を行うべき
  • p244

    • このような送信メッセージはクエリ(質問)として知られていて、送りてのObjectでテストされる必要はない
    • 受信メッセージは、その戻り値の状態がテストされるべき
  • p245

    • テストの価値を信じ続けることが大事
  • p246

    • 経験を積んだ設計者は、問題に対し「スパイクを打つ」ということを知っている
  • p251

    • 依存されていない、使われていないコードが見つかったら削除する

所感

将来の自分は記憶喪失になっているとでも思ってテストを書こう

ハイ!

ikejirirbApr 20

やったこと

  • 第5ç« 

memo

  • p117

    • オブジェクトはそのクラスよりもそのふるまいによって定義される
  • p118

    • 物理世界における美とおなじいように、アプリにおけるオブジェクトの型は、見るものの目にやどります。オブジェクトの使い手はそのクラスを気にする必要はなく、気にするべきでもない
    • 重要なのはオブジェクトが何で有るかではなく、 何をするか
  • p119

    • クラスをまたいだ型を認識すること、パブリックインターフェースを ~略~ 意図をもって入念につくること
  • p122

    • 心の奥底では、引数はMechanicであるとおもってしまっている
      • おもってしまっている時点で特定のクラスを期待してる
      • クラスは気にしてはいけないものなので no good :no_good:
  • p123

    • シーケンス図はそれが描いているコードよりも常にかんたんなものでなければならない
  • p124

    • prepare メソッドは旅行の準備をすること(prepare)を望みます。その引数も旅行の準備に協力しようとやってきます。prepareが引数のその動作を単に信頼すれば、設計はより簡潔になるでしょう。
  • p126

    • Prepareerと相互作用するオブジェクトに必要なのは、それがPreparerのインターフェースを実装していると信頼すること だけ
  • p128

    • ポリモーフィズム
  • p129

    • ダックタイプの実装は比較的簡単だが、ダックタイプが必要であることに気づくことと、そのインターフェースを抽象化することが難しい
    • 隠れたダック :chicken: を認識する
      • :police_car: :cop: :oncoming_police_car:
      • クラスで分岐するcase文
      • kind_of?とis_a?
      • responds_to>
  • p132

    • ダックを信頼する
  • p135

    • 動的型付けを恐れるプログラマーは、コード内でオブジェクトのクラスを検査する傾向にある。この検査こそ、まさに動的型付けの力を削ぐものであり、ダックタイプの利用を不可能にしているのです
    • 静的型付けを信じるプログラマーは、型エラーでfailすることを理由に型検査が必要だ!っていうけど、この問題の唯一の解決策は型検査を全部とりのぞくこと
  • p136

    • 静的型付けのメリット * コンパイラがコンパイル時に型エラーを発見してくれる * コンパイラが型を検査しない限り、実行時の型エラーがおこる場合 * 可視化された型情報は文書の役割を果たしてくれる * 方がなければプログラマーがコードを理解できない場合 * コンパイルされたコードは最適化され高速に動作する * 最適化がないとアプリの動作がおそすぎる場合
    • 動的型付けのメリット
      • コードは逐次実行され動的に読み込まれるため、コンパイル/makeのサイクルがない
        • アプリ全体の開発はコンパイル・makeのサイクルがない方が拘束な場合
      • ソースコードは明示的な型情報を含まない
        • 型宣言がコードに含まれないときのほうがプログラマーにとって理解するのが簡単な場合
      • メタプログラミングより簡単
        • メタプログラミングが言語機能として必要な場合

感想

メタプログラミングRuby 読まねば

Strengths Finder with emoji 🐶Mar 30

なに

  • @tbprgさんの真似をして、Strengths FinderにでてくるStrengthsに絵文字をつけてみた!
  • どうせなので、他のStrengthsのemojiも考えてみた!
  • Thanks to @tbprg、@out_of_kaya ! :tada:

Strengths with emoji

  • 💪 達成欲
  • ⚡️ 活発性
  • 🏄 適応性
  • 🤔 分析思考 
  • 🎨 アレンジ
  • 💎 信念
  • 📣 指令性
  • 🗣 コミュニケーション
  • 🏅 競争性
  • 🔮 運命思考
  • 🗿 原点思考
  • ⚠️ 慎重さ
  • 🌾 成長促進
  • 📃 規律性
  • 💞 共感性
  • ⚖ 公平性
  • 🏁 目標志向
  • 🚀 未来志向
  • 🙏 調和性
  • 💡 着想
  • 🤗 包含
  • ❄️ 個別化
  • 📦 収集心
  • 💭 内省
  • ✏️ 学習欲
  • 🏆 最上志向
  • 😄 ポジティブ
  • 👫 親密性
  • 😤 責任感
  • 🏥 回復志向
  • 👑 自己確信
  • 😏 自我
  • 📈 戦略性
  • 👥 社交性

感想

  • 個別化の ❄のチョイスが気に入っている :relaxed:

Strengths Finderをやっていた!Mar 28

Strengths Finderとは

わたし

活発性

「活発性」の才能の持ち主は、何かを始動するきっかけを作ります。アイデアを行動に変える方法を、彼らは自然と理解します。そして、それを実現させます。彼らのエネルギーは伝染し、人を惹きつけます。重要なプロジェクトや有能なグループがあり、あとは「始めるだけ」という状況にあるときは、「活発性」の持ち主を探せばよいのです。彼らはエネルギーと瞬時の推進力をもたらしてくれます。

  • だれもやってないから最初にやるわ〜 :raising_hand: ていうかも

「押しの強さ」が他人を萎縮させる場合があることを認識しておく必要があります。

  • わかる〜 :sweat_smile:

収集

徐々にボキャブラリーを増やすようにします。意識的に新しい言葉を集め、その意味を学習してください。

  • はい、日本語が不自由ですみません :sweat_smile:

内省

文章を書く時間を取るようにします。書くことは、あなたにとって考えをまとめるのに最高の方法かもしれません。

共感性

黙っていることが大切な場合もあります。あなたには、周りの人が言葉を発しなくても気持ちをわかってくれる、と感じさせる才能があります。時間をかけて、言葉に頼らないコミュニケーションのスキルを磨くようにしましょう。

  • はい :sweat_smile:

責任感

ときには「ノー」と言わなければならないことを覚えておく必要があります。あなたは生来の責任感の強さから、相手の提案を拒否できないことがあります。それを回避するために、物事をよく見極める必要があります。

  • 先日、ノーといえたことがあったけど、そのまえにイェスっていってんだな。責任感だったのか。

所感

会社がめちゃくちゃいやなときに、会社の研修でやったものなので信憑性が△
もっかいやりたい

mysql2のエラーMar 27

やったこと

mysql2というgemをインストールしようとしたら、エラー出てもた :scream:

$ gem install mysql2
~ 略 ~
An error occurred while installing mysql2 (0.4.5), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.4.5'` succeeds before bundling.

対処

xcode-select --install する

brainf*ck-goを使って言語を作る!Mar 27

やったこと

手順

結果

books.json
{
  "next": "📕",
  "prev": "📒",
  "inc": "📗",
  "dec": "📘",
  "read": "📔",
  "write": "📓",
  "open": "[",
  "close": "]",
  "whitespaces": " \t\r\n"
}
fizzbuzz.bf
📗📗📗📗📗📗[📘📕📗📗📗📗📕 📕📗📕📗📕📘📒📒📒📒📒]📕[📒📗📗📗📗📕 📕📗📗📗📕📗📗📗📗📕 📕📗📗📗📕📗
📗📗📗📗📕📗📗📗📗📗📕 📕 📕 📕 📕 📕📗📗📕 📕📗📗📒📒📒📒📒📒📒📒📒📒📒📒📒📒📘]📒📗📗📗📗📕📗📗📗
📕📘📘📕📗📗📗📕📘📕 📕📘📘📘📕📗📗📕 📕 📕📗📗📗📗📗[📘📕📗📗📕📗📗📒📒]📒📒📒📒📒📒📒📒📒📒[📘📕📘
[📕 📕 📕 📕 📕 📕 📕]📕[📒📗📗📗📕📓📕📓📕 📕 📕 📕📓📓📕 📕 📕📗📒]📒📒📒📒📒📘[📕 📕 📕 📕]📕[📒📗
📗📗📗📗📕📓📕📓📕📓📓📕 📕 📕📗📒]📕 📕 📕 📕📗📒📘[📒📒📒]📒[[📘📒📒📗📕 📕]📕 📕 📕📗📕📗📒📒📒📒📒
📒[📘📕 📕📗📕📗📕📘📒📒📒📒]📒]📕📕[[📘]📒]📕[📕 📕 📕[📕📓📒📒📓📒📒📒]📒[📓📒📒📒📒]📕]📕📓📒📒📒📒
📒📒📒📒📒📒📒]
🌸 ~/.go/bin/brainfuck-go -conf books.json fizzbuzz.bf
Input: 📗📗📗📗📗📗[📘📕📗📗📗📗📕 📕📗📕📗📕📘📒📒📒📒📒]📕[📒📗📗📗📗📕 📕📗📗📗📕📗📗📗📗📕 📕📗📗📗📕📗
📗📗📗📗📕📗📗📗📗📗📕 📕 📕 📕 📕 📕📗📗📕 📕📗📗📒📒📒📒📒📒📒📒📒📒📒📒📒📒📘]📒📗📗📗📗📕📗📗📗
📕📘📘📕📗📗📗📕📘📕 📕📘📘📘📕📗📗📕 📕 📕📗📗📗📗📗[📘📕📗📗📕📗📗📒📒]📒📒📒📒📒📒📒📒📒📒[📘📕📘
[📕 📕 📕 📕 📕 📕 📕]📕[📒📗📗📗📕📓📕📓📕 📕 📕 📕📓📓📕 📕 📕📗📒]📒📒📒📒📒📘[📕 📕 📕 📕]📕[📒📗
📗📗📗📗📕📓📕📓📕📓📓📕 📕 📕📗📒]📕 📕 📕 📕📗📒📘[📒📒📒]📒[[📘📒📒📗📕 📕]📕 📕 📕📗📕📗📒📒📒📒📒
📒[📘📕 📕📗📕📗📕📘📒📒📒📒]📒]📕📕[[📘]📒]📕[📕 📕 📕[📕📓📒📒📓📒📒📒]📒[📓📒📒📒📒]📕]📕📓📒📒📒📒
📒📒📒📒📒📒📒]

1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
FizzBuzz
~ 中略 ~
(END)

感想

  • emojiのチョイスが大変単調なものになってしまい、emoji力の低まりを感じた☹️ 鍛えないと・・・🏋️🏋️🏋️

ikejiri.rb 4回目Mar 23

※週一ランチタイムの読書会 ikejirirb/POODR

やったこと

4.1 インターフェースを理解する 〜 4.3 パブリックインターフェースを見つける

memo

  • p89

    • 問題の根源はクラスが「何をするか」ではなく、「何を明らかにするか」にある
  • p 91

    • パブリックインターフェース
      • クラスの主要な責任を明らかにする
      • 外部から実行される
      • 気まぐれに変更されない
      • 他社がそこに依存しても安全
      • テストで完全に文書化されている
    • プライベートインターフェース
      • 実装の詳細に関わる
      • 他のオブジェクトから送られてくることは想定されていない
      • どんな理由でも変更されうる
      • 他者がそこに依存するのは危険
      • テストでは言及されないことすらある
    • 「変更の可能性が低いところに依存する」という考えはクラス「内」のメソッドにも当てはまる
  • p 93

    • アプリケーションに置いて「データ」「振る舞い」の両方を兼ね備えた「名詞」をあらわすものを「ドメインオブジェクト」
    • 「ドメインオブジェクト」は大きくて目に見える現実世界のものを表し、かつ 最終的にデーターベースに表されるもの
  • p93

    • オブジェクトではなく、オブジェクト間でかわされるメッセージに注意を向ける
  • p96

    • ユースケースでの名詞はシーケンス図でオブジェクトになる
    • シーケンス図はオブジェクト間でかわされるメッセージを明記する
  • p 97

    • オブジェクトが存在するからメッセージを送るのではなく、メッセージを送るためにオブジェクトは存在する
  • p98

    • 「どのように」を伝えるのではなく、「何を」を頼む
  • p100

    • 図4.5と図4.6のちがい
      • Mechanicのパブリックインターフェースのサイズが小さくなった
      • パブリックインターフェースが小さいということは、ほかのところから依存されるメソッドが少ないということ
    • コンテキストは、Tripがどこへでも来て回るコートのこと
    • オブジェクトが要求するコンテキストはオブジェクトの再利用性の難しさに関わってくる
    • 複雑なコンテクストをもつオブジェクトは使うのもテストするのも難しい
    • :100: オブジェクトがコンテキストから完全に独立していること
    • :100: 相手が誰かも、何をするかも知らずに他のオブジェクトと共同作業できるオブジェクト
      • dependency injection
  • p103

    • 他のオブジェクトを信頼する
  • p 104

    • 私は自分が何を望んでいるか知っていて、あなたが何をするかもしっているよ → 私は自分が何を望んでいるかを知っているし、あなたはあなたの担当部分をやってくれると信じてるよ
    • 手放しの信頼

感想

  • 4章、まだまだ終わらない

ikejiri.rbMar 13

※週一ランチタイムの読書会 ikejirirb/POODR

やったこと

  • POODR 3ç«  依存関係を管理する

memo

  • p59

    • オブジェクトに望まれる振る舞い
      • オブジェクト自身が知っている
      • 継承している
      • メッセージを理解する他のオブジェクトを知っている
  • p60

    • 一方のオブジェクトを変更したとき他方も変更しないといけないなら、片方に依存している
  • p61

    • 他のオブジェクトへの依存がありそうな場合 :pig_nose:
      • 他のクラスの名前がある
      • 他のオブジェクトのメッセージを知っている
      • メッセージの引数を知っている
      • 引数の順番を知っている
  • p63

    • 幾つものメッセージをチェーンのように繋いで遠くのオブジェクトに存在する振る舞いを実行しようとするのはやばい
  • p65

    • GearからWheelへの参照がgear_inchesメソッドの内部という深いところでハードコートされているとき「Wheelインスタンスのギアインチしか計算する意思はない:ということ
  • p67

    • 依存オブジェクトの注入(dependency injection)
    • 明示的依存⇔注入
  • p68

    • 不必要な依存を除去できないのなら、クラス内で隔離する
  • p69

    • 依存しているということを明らかにする
  • p 75

    • fetch
      • :thought_balloon: みたことない!
      • もう必要ないのでは?

感想

  • dependency injection(依存性注入)ということばはわかりづらいので、ことばにながされない!
  • ようは、依存している箇所を、メソッドの奥深くから取り出して依存がわかるようにしておくこと
  • 依存している箇所をとりだして置くことで、テストするときのモックデータとかを入れやすくなる
  • 2.0.0以降はキーワード引数があるから、第3章にあったような引数のデフォルト値の書き方はちょっと古い。でも、ライブラリのソースで出ることがあるので、古い書き方を知っておくのは大事!

ikejiri.rbMar 8

※週一ランチタイムの読書会 ikejirirb/POODR

やったこと

memo

🔑 Keywords

  • 設計とは可変性を保つために技巧を凝らすこと

かんたんさの定義

  • 変更は副作用をもたらさない
  • 要件の変更が小さければコードの変更も小さい
  • 既存のコードはかんたんに再利用できる
  • 最もかんたんな変更方法はコードの追加
  • 凝縮度
  • 単一責任の原則
  • データではなく振る舞いに依存する
  • データ(どこからでも参照される)
  • 振る舞い(一箇所で定義される)
  • 変数にアクセスするようにするにはメッセージを送るようにしたほうがいい

:sparkles: TRUE

  • :sparkles: Transparent
    • 見通しが良い
  • :sparkles: Reasonable
    • 合理的
  • :sparkles: Usable
    • 利用性が高い
  • :sparkles: Exemplary
    • 模範的

📝

  • コグは歯車の歯のこと! ⚙️
  • Exemplary
    • 模範的

AlbedoとEmissionFeb 27

やったこと

  • UnityのMaterialに色を設定しようとしてAlbetoに色を設定したら、Scene View 上では設定したものより黒っぽい色が表示された :scream: そこで、もう一つ色が選べそうなところがあったのでそっちに色を設定してみたら、期待通りの鮮やかな青が表示された。

Albelto

アルベドパラメーターは、表面のベースカラーを制御します。

Emission

表面から放出される光の色と強度を制御します。emissive マテリアルは、シーン内で使用される場合、それ自体が可視光の光源であるように見えます。オブジェクトは “自己発光” しているように見えます。

結論

Albelto はものの色。光があたってないところは黒くなる。
emmision はLED電球の色みたいな感じ。その他の光源がなければその色に見える。