PCの問題の記録。コミュニケーション苦手と感じる理由は、音声という一次元的な情報の伝達手法に難を覚えていることと関連している。読むべきVPoEのインタビュー記事のリストアップ。
あと、Rustの勉強記録(Result型周りの途中)。
diary
pc
また勝手に再起動が走った。
自動的に再起動するのをやめさえることにした。これで一度様子を見よう。
次はフリーズした。電源の問題ではないことがわかった。
BIOSの更新をして、これでもダメだったら、部品の交換をしなければならないだろう。
communciation
コミュニケーションが苦手と感じている理由は、思考と文法とが一致しないことが多い。
こうやって書いているときも、考えを改めてみたり、もしくは書いている途中で、末尾の動詞を変化して文章がおかしくなったり、順序を変えて助詞がおかしくなったりする。
これが話しているときは問題として顕著に表れる。
だから、コミュニケーションが苦手ということを語るうえでは、音声会話における一次元的な表現が苦手であることをとりあげないといけない。
team
会社で『Team Geek』の要約の発表をしているときもそうだ。
Team Geekの内容は当然であるが、当然のことを文章としてまとめ、これの重要性を箇条書きで伝えることは、実感を得ていますか?実践できていますか?と問いかけることにおいては重要である。
vision
VPoE
kiitokで結構まとめられていたので
メルペイ 木村さん
アカツキ 湯前さん
Wano 橋本さん
読んでないけれど、これらを読んで調べよう
今日の勉強
rust
TRPL pp.170-175
- Result enumが伝達するもの
File::open
を例にすると- 成功したか失敗したかを知らせる方法と
- ファイルハンドル(中身、
Ok
インスタンス)、または、エラー情報(エラーの種類の関する情報をより多く持つ、Err
インスタンス)
let f = match f {
Ok(v) => v,
Err(e) => {
... e ...
},
};
上記のように、match式でバインドして取り出すことができる
- 失敗理由によって動作を変えたい場合
io::Error
のインスタンスにkind()
メソッドを適用すると、io:ErrorKind
の値が返されるio:ErrorKind
はenumで、io処理の結果発生する可能性のある種類のエラーを表す列挙子がある
- マッチガードを使う
- matchアームの後に
if ...
- アームのパターンをさらに洗練するmatchアーム上のおまけの条件式
- アームコードを実行されるにはこれが真でなければならない
- 真でなければmatchの次のアームを考慮する
- matchアームの後に
- パターンでrefを使用する理由
- errorがガード条件式にムーブされないようにするのに必要
- ただ単にガード式で参照される
&
の代わりにref
を使う理由&
: 参照にマッチし、その値を返すref
: 値にマッチし、それへの参照を返す
- matchだと多少冗長になるので、ヘルパーメソッドがある
unwrap
- Ok列挙子ならその中身を返し
- Err列挙子ならpanic!マクロを呼ぶ
expect
- unwrapと似ているが、
- Err列挙子の場合に、panic!のエラーメッセージを選択させてくれる
- パニックの原因とその箇所を特定しやすくする
- エラーの委譲
- 定義
- 関数内でエラーを処理する代わりに
- 呼び出し元がどうするかを決められるようにエラーを返す
- 方法
Result<T, E>
型の値を返すようにする- TとEは具体型で埋める
- この型の決め方は中身の関数から決める
- TとEは具体型で埋める
- 定義