diary

pc

CPUの温度がやばいのが原因だと判明。

とりあえず、IPAと熊グリスを購入。明日、塗り直しをする。

ここ2年ほどグリスの塗り替えをしていなかったので、全部私が悪い。

communication

音声を用いた一次元的な伝達内容の作成と連絡が苦手、という話を昨日のweblogで記録した。

今日は、初めて会う人とオンラインミーティングをした時に気づいたことがある。人と会話をするときに、この苦手を露出させないようにするために、ある程度、自分で発言や思考、振る舞いを調整できている。

具体的に行っている対処は、複雑な内容を語るときは、話す内容を分割し、短いセンテンスにしている。さらに、相手の反応を見たり、相手に問いかけたりしている。

自分の苦手さを克服しようとしている傾向に自分で気づけた。

ただ、そこでまた別で気づいたのだが、初めて会う人との会話では脇汗がすごい出る。

alocohol

ビールを飲むと寝ている時に痒みが出る。

お酒はやはり控えようと思う。

今日の勉強

rust

TRPL pp.175-187

エラーを委譲する
- Result型の値を扱う
  - 失敗したら、panic!を呼び出す代わりにエラー値を早期リターンし、それを呼び出し元に返す
  - 成功したら次の処理で値を取り出し、Result型の値を返す
    - 操作し、返すのはResult型
    - 最後の式だったら、returnは不要
- 全体の返り値はResult型となる
  - 呼び出し元のコードに成功や失敗情報を全て委譲する、そしてそこには十分な情報があるはずなので適切に扱える
エラー委譲のショートカット: ?演算子
- 定型コードの多くを排除できる
- ?演算子
  - matchを使った定型コードでやっていたのと類似の動作をする
    - Okなら、その中身がこの式から返ってくる
    - Errなら関数全体からErrの中身が返ってくる、早期リターンする
      - Errの中身はFromトレイトで定義され
      - from関数を呼び出すと
        受け取ったエラー型が、
        現在の関数の戻り値型で定義されている
        エラー型に返還される
  - 関数が失敗する可能性を全て1つのエラー型で表現して返すときに有用
  - ?演算子の直後にメソッド呼び出しを連結することができ、それによってコードを短くできる
- ?演算子は、Resultを返す関数でしか使用できない。
  - match式を使った定型コードと類似の動作をするのだから
  - ResultやTryトレイトに関しての怒られが発生する
エラーを呼び出し元に委譲するなら、?演算子
Resultを返さない関数ならmatchかResult
panicすべきかResultを返すべきか、その決定方法
- 分類
  - panic
    - 回復不能
  - Result
    - 呼び出し側に、回復不能と断定するか、回復を試みるかと、選択肢を与える
- ほとんどResult型がよいが、panicが適切になる場面はある
- panicが適切になる場合
  - 例
    - つまり、何らかの概念を具体化しているとき
    - 頑健なエラー処理コードが例の明瞭さを欠かせる
    - panicする可能性があるところというのは、アプリ側で処理してほしい方法へのプレースホルダーを表示する
  - プロトタイプ
    - エラーの処理方法を決定する前において
    - プログラムを頑健にする明らかなマーカーとなる
  - テストコード
    - 呼び出しがテスト内で失敗したら、テスト全体が失敗してほしい
    - つまり、テストが失敗と印づけられる手段として、unwrapやexpectが必要
- コンパイラよりもプログラマがより情報を持っている場合
  - Ok値であると確認する何らかの別のロジックがある場合、unwrapした方がいい
    - プログラマは知っている
    - コンパイラは知らない
  - 特定の場面では起こりえないが、一般的には失敗する可能性がある時
  - ユーザー起源のもので、それゆえに確かに失敗する可能性がある場合、
    - Resultをもっと頑健な方法で対処したほうがいい
panicすべきかどうかのガイドライン
- 悪い状態に陥る可能性があるとき、パニックさせる
  - 悪い状態とは、何らかの前提、保証、契約、不変性が破られるとき
    - 関数には契約がある
      - 入力が特定の条件を満たすときにのみ振る舞いが保証されている
      - 破られた時にパニックするのは道理に適っている
- panicを起こして、自分のコードの使用者にバグがあることを通知したり、外部コードで修正しようのない無効な状態を返す時がある
- Resultを返して、悪い状態を委譲して、呼び出し側が、問題の処理方法を決定できるようにするという選択が良い場合もある
- コードは
  - 値が合法であるか確認し、
  - 合法でなければパニックになるべき。
    - これは安全上の理由による
検証のために独自の型を作る
- たくさんのエラーチェックを行うことは冗長で煩わしい
- Rustの型システムを使用して、合法な値があると、コンパイラがすでに確認している
  - 確実性を持って前に進める
- ifでの値チェックする方法は、理想的な解決策ではない
  - 面倒だし、パフォーマンスへの悪影響がある
- 新しい型を作って、関数本体内で確認するのではなく、検証をその型のインスタンスを生成するところに追いやる
  - 関連案数で、それを生成するところでふるいにかける
    - フィールドを非公開にし、直接セットさせず、インスタンスを生成せざるえなくさせる
    - この関連関数の契約を明示する方法については、ドキュメントの規約に書けばよい(cf: chap14)
- 関数が新しい型をシグニチャに用い、受け取った値を自信をもって使用することは安全になる
  - 受け取った値を取り出すゲッターというメソッドを作らないといけない。

10章

ジェネリックス
- 概念の重複を効率的に扱う道具
  - 独自の型、関数、メソッドをジェネリックスとともに定義できる
    - コードの重複を減らせる
- 具体型や他のプロパティの抽象的な代役
  - ジェネリックスの位置に何が入るか知ることなく
  - ジェネリックスの振る舞いや他のジェネリックスとの関係を記述することができる
    - トレイトを使用して、ジェネリックな方法で振る舞いを定義できる
      - ジェネリックな型とトレイトで、型を特定の振る舞いのある方のみに制限できる
- ライフタイム
  - コンパイラに参照がお互いにどう関係しているかの情報をどう関係しているかの情報を与える一種のジェネリックス
  - これのおかげで
    - コンパイラに参照が有効であることを確認してもらうことを可能にしつつ多くの場面で値を借用できる
関数の抽出と、ジェネリックスを使用するのも同じようなこと
- 関数の抽出の仕方
  - まず重複したコードを見分ける
  - 次に関数を抽出する
    - 関数に渡す可能性のあるあらゆる値の具体的な型を示す
    - 入力と戻り値を関数シグニチャで指定する
  - 取り除く
    - 関数を代わりに呼び出すように更新する
- ジェネリックスは、抽象的な型に対して、処理するコードを可能にする

isabelle

L_correctの証明を追いかける。
- テキストにダイアグラムがあり、
- Isabelleのgoalsを解釈しながらだと、
- 証明の内容と証明すべきことがすぐわかった。
Optimizer buryの定義を読む
- 死んだ変数へのアサインメントを、SKIPに置き換えることで、除外する
このOptimizationが正しいことの意味について
- 基準は、変形されたものがもとのものと同じかどうか、である。

team

『1on1マネジメント』を読み進める

読み進めながら思ったことは、『Team Geek』とGoogleのガイドラインを足して、日本の中間管理職向けに(チームおよびチーム文化の側面や、チームメイトであるというところが抜けているような印象を受けたので「管理職向け」と私は感じたのだろう)、具体例を盛り込んだような内容。

退屈であるが、具体例に富んでおり、また、Googleの方々の欧米ライク、もしくは、日本人に合わないところを、日本の状況に合わせている点は好印象。

時々読み返して、振り返ってみて、自分を改善するところでは役に立つかもしれない。

communication pc alcohol rust isabelle team