tyamaguc07 hatenablog com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

1月に読んだ本

2月も5日になってしまいましたが、1月に読んだ本を記す。

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

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

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

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

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

読了まで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) 

Haskellの環境構築は時間がかかる。

読書する気分でもなかったので、

Haskellでもやってみるかと思ったら環境構築に非常に時間がかかった at MacBookAir2011

おかげで読書が捗りました。

環境構築

以下のコマンド一発。

brew install haskell-stack

なのだが。依存関係があるghcとcabal-installのインストールにすごく時間がかかる。たぶん2時間強。

Haskellやろうと思ったら、前日にコマンドは叩いておきましょう!

以下入門に使った記事

第1章 関数プログラミングは難しくない!―初めて学ぶ人にも,挫折した人にもきちんとわかる:[入門]関数プログラミング―質の高いコードをすばやく直感的に書ける!|gihyo.jp … 技術評論社

第2章 関数プログラミングのパラダイム―命令プログラミングと何が違うのか:[入門]関数プログラミング―質の高いコードをすばやく直感的に書ける!|gihyo.jp … 技術評論社

型推論すげーと思いました。

3月までのミッション

マネージャーのミッションを明文化してほしいと宿題を出されていたので、ここに書いてみる。

1) 組織としてのビジョン、戦略の構築

  • これは個人でやることではなく、マネージャー全員で行うこと
    • 長期的にどんな組織にしたいのか

2) 若手の技術力向上

3) 実践共同体を生み出す種まき

  • 学習を自発的にかつ、個人ではなく、集団で行う文化の開発
    • 一人では難しいことも集団でなら頑張れる
    • 既存の勉強会制度とは別軸で動く
    • 具体的には読書会、輪読会、ワークショップなど
  • 実施し、KPTを回す
    • 継続的に行うことが一番難しいと思われるので

2016年の抱負

仕事面

今年は新卒教育に注力して動く。新卒だけでなく、配属先にも研修をより有意義に感じられるものにしたい。

また、社内に自ら学んでいくコミュニティを形成していく。(読書会、輪読会、ワークショップなど)

コミュニティの形成は、初期段階はスムーズに始められるのではないかと楽観的に捉えているが、

継続的な活動を行えばいろいろと問題が起こることは目に見えているので、そのあたりも踏まえて戦略・計画を立てて動きたい。

(これまでの経験から、この辺りをしっかりしておかないと、自身が折れてしまう可能性が高い)

技術面

自身の技術はそれほど高いわけではないので、地力を伸ばすための動きを行う。

具体的には、詳解 Linux カーネルを読むことと、関数型言語を学ぶこと。

が、進めるには挫折しそうなので、周りを巻き込んでいこうと考えている。

これは、仕事面の抱負で書いた、自ら学ぶコミュニティの形成と一緒にやれそうなので今からワクワクしている。

あと、情報収集のスタンスを変え。業務に直接結びつかないようなものでも追いかけるようにする。

学習

別記事で書こうと思っているが、とりあえず年間100冊の本を読む。

本の方向性としては、仕事面で活かせそうな教育論、組織論といった理論を中心に学べるもの。

技術面では、基礎を学び直せるもの、トレンドを追いかけれるもの。

そして、単純に読書が好きになることを忘れてはならない。