人にものを伝える時は 3 つのissue と 1 つのお願いという形式が楽。
diary
how to assert
人にお願いするときは、3つの課題と1つのお願いという形式が楽だな、とよく感じる。
こちらが意図的にコンパクトにしていると、相手がどう読むかわかりやすいし、相手はすぐ読める。(結局、伝えられることが一番だから)
例えば、以下のような内容があるだろう。
- 小腹が空いていると集中力が落ちます
- 軽食を買いに外に出るのは時間の無駄です
- 会社に軽食があると共通の話題を作りやすくなります
お願い:会社におやつを置いてください。
Communication
相手への尊敬の念や、共感や労りの気持ちを持つのは非常に難しいが、それっぽいふるまいをするのは簡単である。 (そして、共感をしすぎて共依存するのもよくないから、先んじて境界線を引いておく)
たとえ、相手の意見やお願いの筋が通っていなくても、一旦それを受け入れ共感を示して、労りとしてやってみて、提示して、やっぱり違うね、という共通見解を得てから、もとの意見やお願いを訂正する、というのが角が立ちにくくなるだろう。 これはとてもコストが高く、無駄が多い。 が、人間は愚かで、伝えられた言葉や伝え方に無駄や冗長さがないと、自分が馬鹿にされた気分になるらしい。
なんでこれでうまくいくのかはわからないが、うまくいくんだったらその方法を採用する。
Wi-Fi
契約状態を確認して、CAF番号を確認して、終端装置を確認して、サポートされているルーターを確認して、設定し、と一連の作業をしてやっと設定できた。
全体のフローを先に知っておかないと無駄に時間を浪費してしまう。(およそ6時間ほど時間を使ったことになるが、知っていたら2時間もかからなかっただろう)
配線もそうだが、専門の業者様が如何に素晴らしいサービスを提供しているか。尊敬を覚える。
今日の勉強
rust
TRPL
pp. 36-44
shadowing
とmut
との違い- シャドウイングは新しい変数を作っているので、値の型を変えつつ、同じ変数名をつかえる
- 可変変数の場合は、同じ変数なので、型を変えることはできない
型注釈が必要な場合がある
- 型推論をして、複数の型が推論される場合がある
- Rustは静的型付け言語であり、コンパイル時にすべての型が判明している必要がある
- だから、型注釈で型を明示する必要がある
スカラー型
- スカラーは単独の値のこと
- 整数型
- 整数型の基準型は
i32
- 整数型の基準型は
- 浮動小数点型
- 浮動小数点型の基準型は
f64
- 浮動小数点型の基準型は
- 論理値型
- 文字型(文字列型ではない)
char
はunicodeのスカラー値- 補足: 文字はUNICODEの概念ではない。
複合型
- 複数の値を1つの型にまとめることができる。
- タプル型: 複数の型の値を1つの複合型に。位置ごとに型が定められている。
- タプル型の値へのアクセス方法は、パターンマッチングによる分配か、
.0
や.1
などピリオドと添え字による方法。
- タプル型の値へのアクセス方法は、パターンマッチングによる分配か、
- 配列型: 全要素は同じ型。固定長。
- 配列型の値へのアクセス方法は、
[0]
や[1]
などのかっこで添え字を囲む。 - 配列型は固定長であり、サイズの伸縮はできない。ベクタ型という配列型とよく似たコレクション型はサイズの伸縮ができる。
- 固定長の配列型では、長さ以上の添え字を使った場合、無効なアクセスとして、処理を継続させず終了させる。
- 疑問: テキストでは、実行時エラーが発生させるとあるが、実際にやってみたところコンパイル時のエラーが発生した。
- 配列型の値へのアクセス方法は、