tyamaguc07's hatenablog

考えたり調べたりしたことを書いていく。

プログラミング言語Rust 「4.1. 変数束縛」写経時のつぶやき

毎日Rust30分

2018/12/10

プログラミング言語Rust 「3.2 食事する哲学者」写経時のつぶやき

毎日Rust30分

2018/12/07

2018/12/08

2018/12/09

プログラミング言語Rust 3.1. 数当てゲーム つぶやきまとめ

毎日Rust30分

数当てゲーム 写経時のつぶやき

Rust開発環境 on Docker で Cargo new で "could not determine the current user, please set $USER" エラー 

root@7e6ba33a449a:/projects# cargo new hogehoge
error: Failed to create project `hogehoge` at `/projects/hogehoge`

Caused by:
  could not determine the current user, please set $USER
root@7e6ba33a449a:/projects# ls -al
total 4
drwxr-xr-x 5 root root  160 Dec  2 05:22 .
drwxr-xr-x 1 root root 4096 Dec  2 05:21 ..
drwxr-xr-x 6 root root  192 Dec  2 04:58 helloworld
drwxr-xr-x 4 root root  128 Dec  2 05:22 hogehoge
drwxr-xr-x 6 root root  192 Dec  2 05:20 new_hello_world

エラーになる。（ディレクトリは作成される） メッセージの通り、現在のユーザが特定出来ないというもの。

解決方法はいくつかある。

  1. docker run 時に --env USER=ユーザ名 をつける
  2. DockerfileにENV USER=ユーザ名をつける

Rust Tutorialをやっていくにあたっては、2の手段が楽だと思ったので採用。

Rust開発環境作成 with docker

  1. github にリポジトリ作成
  2. https://hub.docker.com/_/rust/ からDockerfileを取得
  3. イメージビルド
  4. docker run
    • docker run -it learn-rust
    • 各種バージョン確認

      root@5bb70de85a33:/# rustup --version
      rustup 1.14.0 (1e51b07cc 2018-10-04)
      root@5bb70de85a33:/# cargo --version
      cargo 1.30.0 (a1a4ad372 2018-11-02)
      root@5bb70de85a33:/# rustc --version
      rustc 1.30.1 (1433507eb 2018-11-07)

  5. Hello World
    • mkdir src
    • vi src/helloworld.rs

      fn main() {
      println!("Hello, world!");
      }

    • srcのマウントしてdocker run
      • docker run -itv $PWD:/project learn-rust
    • コンパイル
      • cd project/src
      • rustc helloworld.rs
    • 実行
      • ./helloworld

        Hello, world!

参考

qiita.com

qiita.com

指摘をくれる人は大切にしたい

「自分のダメなところを指摘してくる人は大切にしたほうがいいですよ。」とアドバイスを貰って１ヶ月。

久しぶりに指摘をもらいました。ほんとにありがたい。

指摘のついでにカウンセリングもしてもらい大変助かった。

そして、「指摘をくれる人を大切にする」ということがどういうことなのか深く学べた気がした。

どのようなことかというと、指摘のたびに落ち込む姿を見せることは、指摘する側の心理的コストが増してしまうので、

指摘を真摯に受け取るが落ち込む姿を見せないように心がけるようにしようと思った。

サブタスクなコードレビュー考察

他チームのコードレビューを依頼された場合の考察。

他チームのコードレビュー依頼がある状況と対応方法

該当チームのリードエンジニアのリソースが足りていない

一時的なリソース貸出に当たると思われるので、期日やレビュー範囲などの合意が取れればOKだと考える。

該当チームにリードエンジニア( が存在しない || の実力不足 )

ある一定以上の品質達成が該当チームだけでは成し得ない状況だと思われる。

この状態でのレビューは想像以上に高いコストとなることもあり、

最悪、何度も発生する差し戻しなどで、プロジェクト全体の進捗が滞ってしまう事もありえる。

そうならないように、品質的にはNGでもレビューOKとするルールを設定する必要があると考る。

例えば、以下のルールを設定する。 　

  • 一定の差し戻し回数を超えたものに関してはレビューOKとする
  • レビューは行うが、修正は行わないものとする
    • 今後の開発時に意識してほしい観点を伝えることを目的としたレビュー

まとめ

他チームのコードレビューは、レビューに関するルールの合意をとって実施するべき。