tyamaguc07's hatenablog

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

プログラミング言語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とする
  • レビューは行うが、修正は行わないものとする
    • 今後の開発時に意識してほしい観点を伝えることを目的としたレビュー

まとめ

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

１月に読んだ本

２月も５日になってしまいましたが、１月に読んだ本を記す。

ひとりでも部下のいる人のための世界一シンプルなマネジメント術 3分間コーチ

ひとりでも部下のいる人のための世界一シンプルなマネジメント術 3分間コーチ

後輩が読むと言っていたので、読んだ本。

すごく読みやすい本で、後輩がいる人にオススメしたい本でした。

自身の普段の行動を振り返ることもできよかった。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

読了まで20日かかった本。

エピソードや事例紹介などが多く、分量が単純に多かったが、

なにより、自身の読書週間がついていなかったことが原因。

本から学ぶことも多かったが、何よりも、読書週間について見直せたことが大きかった。

思考の「型」を身につけよう　人生の最適解を導くヒント

思考の「型」を身につけよう　人生の最適解を導くヒント

自分の思考を効率的に出来ないかなと思い読み始めたが、

思っていた内容とは少し違った。

だが、学ぶことは多かったので読んでよかった。

定期的に読みなおして型を身に着けたい。

人工知能は人間を超えるか (角川ＥＰＵＢ選書)

人工知能は人間を超えるか (角川ＥＰＵＢ選書)

あんちぽちゃんさんがお勧めしていた、かつ、購入済みだったので読んでみた。

すると、ものすごく、ものすごく面白く。なんでもっと早く読まなかったんだと思える本だった。

ディープラーニングの理解への第一歩にもなるので、ほんとオススメです。

ダメな議論―論理思考で見抜く (ちくま新書)

ダメな議論―論理思考で見抜く (ちくま新書)

1月中にもう1冊読みたいなと思って、読み始めた本。

思っていた内容ではなく、ちょっと肩透かし感。

業務にも使えるな内容ではあるものの、どちらかというと、世の中の情報の取捨選択の方法論。

http://gihyo.jp/dev/feature/01/functional-prog/0003 の正誤表

下の記事をやっていたら、説明が間違っていると思われる箇所や、うまく動かないサンプルコードがあったので正誤表を書いてみた。

Haskell歴2日なので、至らない点があるのであればご教授いただけると助かります。

gihyo.jp

図3の正誤表

mapに関数渡してなかった。

 -- '1'にisDigitが適用され，残りのリストにコンスされる
- isDigit '1' : map ['a']
+ isDigit '1' : map isDigit ['a']
 
 -- ↓
 
 -- isDigit '1'がTrueになる
- True : map ['a']
+ True : map isDigit ['a']

リスト1の正誤表

そのままだと動かなかった。

maxDupStrの定義に関しては、こうしたら動いたというだけなのでなんとも。

makePairの方は、単純に第一引数が抜け落ちてた。

 
 --最長重複文字列を計算する
 maxDupStr :: [Char] -> [Char]
-maxDupStr = extract . chooseMax . calcLen . makePair . sort . tails
+maxDupStr xs = extract(chooseMax(calcLen(makePair(sort(tails xs)))))
 
 --隣り合う要素を組にする
-makePair ::  -> [([Char], [Char])]
+makePair :: [[Char]] -> [([Char], [Char])]
 makePair xs = zip xs (tail xs)