2017-07-09

junior engneerがインターン先Rでそこそこちゃんと仕事をして思ったことまとめ

ライブラリの選定

何かプラグインなり、ライブラリを使いたい時は、なぜそれを使いたいのか、なぜそれが良いと思うか、どう使いたいかを伝える。

ライブラリ導入時のチェック項目

[ ] issueの数
[ ] 星の数
[ ] それに関連する技術のバージョンを調べる
[ ] 何年前から使われているか調べる（枯れているか）

仕事の順序

(自分が手がけているプロジェクトと同様の環境の遊び場を使っていじったりする)

1.ゴールを理解する、解決したいことを明確にする（それについてわからないこと、知りたいことを明確にする、それは調べる方法（ググるのか、githubでコードを読むのか）も同様） ex)　一部のリソースへアクセスするポリシーの作りかた、またそのコード

2.その解決方法を調べて、上長にこの方向で解決しようと思うのだがどうか？（自分なりの仮説、メリットデメリットを具体的かつ簡潔に伝える）という形で質問する

3.PRをwipで出して、実装方針を整理し、正しい方向性か上長に聞く。そのコードについて深く考える。その冗長だったら何て言うか考える。

4.PRのreviewをお願いする。PRはreviewerが疑問に思う可能性がある処についてなぜそうしたのか、ちゃんと説明す。reviewerの負担を減らすことを考える、他のメンバーのことも考える。

一言

「仕事とはただqiitaにまとめてあるような実装をして、コードを書いて動かすようにするだけではない。そのコードに責任感を持ち、問題解決を行うのが仕事である。」と思いました。

なんか自分がやってきたことってわりとrailsのコードを書いて何かを動かすようにするという感じで、しかもゴリゴリのスタートアップだったのでとりあえず動くようにして当然のごとくテストなんて書かないしという感じだったので、仕事といえばただ動かすようにすればいいという感じでした。だから、Rに入って技術選定からドキュメントの作成、社内でのコミュニケーションなどあーエンジニアってコード書くだけじゃなくて、問題解決が仕事なんだと思いました。なんか自分で作る時はデバッグして動いたー！！楽しい！！って感じだけど、仕事はそうじゃないなと。ググって一番上に出て来たやつを何も考えずに採用している場合ではないなとおもいました。

あと仕事って最終的なゴールはこのフローを上長の存在なしでできるようにすることだと思う。そうすると自然と上長に何か聞くことが少なくなって、あいつは「仕事ができる」ということになるのではないか。

また明日から頑張っていきたい。

2017-07-05

これを見るだけで読んだ気になれるリーダブルコードチェックリスト +α

名前に情報を詰め込む

[ ] 明確な単語を選べていますか？
- 類語辞典
- send, deliver, announce, distribute, route
- find, search, extract, locate, recover
- start, launch, create, begin, open
- make, create, set up, build, generate, compose, add, new
[ ] 汎用的な名前を避けていますか？（あるいは使う状況を選ぶ）
- tmp, retval, イテレータ(i,j,k) これらの汎用的な名前を使うときは。それ相応の理由を用意（一時的な保管が最も大切な場合など）
[ ] 抽象的な名前より具体的な名前を使えていますか？
[ ] 接尾辞や接頭辞を使って情報を追加していますか？
- 時間やバイト数のように計測できるものであれば単位をつける
[ ] 名前の長さは短いですか？
- 長い名前を避ける
- スコープが小さければ短い名前でもいい
- 頭文字と省略形
  - doc document
  - eval evaluation
  - str string
- 不要な単語を投げ捨てる
  - 名前に含まれる単語を削除しても情報が全く損なわれないこともある
    - ConvertToString → ToString
    - DoServerLoop() → ServerLoop()
[ ] 名前のフォーマットで情報を伝えていますか？
- クラスのメンバ変数にアンダースコアをつけてローカル変数と区別する

誤解されない名前

名前が他の意味と間違えられることはないだろうかと何度も自問自答する

[ ] より具体的な意味を持った動詞を使えていますか？
- filter() → select, exclude
- clip() → remove, trancate
[ ] 範囲の値の変数はそれで正しいですか？
- min/max 限界値を明確にする場合（未満、以下）
- first/last or begin/end
[ ] 真偽値は以下の項目を満たしていますか？
- [ ] 頭にis, has, can, shouldなどをつけてわかりやすくする
- [ ] 否定形を避け肯定形にする

命名するときの手順

1.その関数、変数に関わる情報を日本語で考えて、ブレストする

2.それを英訳して、類語辞典・githubで調べて適切な単語を抜き出す

3.その言語の命名規則にそって命名する

命名する前に読んだほうがいいリンク

コードのレイアウト

[ ] 一貫性のある簡潔な改行位置ですか？
[ ] メソッドを使って冗長な処理をまとめていますか？
[ ] たての線（列）はまっすぐですか？

hoge("tanakatanaka", "foo"     , "");
hoge("sato"        , "fugafuga", "");
hoge("matz"        , "bar"     , "phone");
hoge("dhh"         , "piyo"    , "jobs");

[ ] 意味のある順番にならべていますか？
- 最重要
- アルファベット順
- 複雑なもの
[ ] 宣言はブロックにまとめられていますか？
- 論理的なグループにわける
[ ] コードは似ている考えごとに段落に分割されていますか？

コメントの目的は書き手の意図を読み手に知らせること基本的にはコードや、その名前でわかるべき。だが関数といして抽出していない処理などは何をやっているかわかりにくい場合があるので補足したほうがいいとは思う

コメントすべきことを知る

[ ] コードからすぐわかることはコメントすべきでない
[ ] ひどい名前はコメントせずに名前を変えろ優れたコード>ひどいコード+優れたコメント　
自分の考えを記録する（exこのクラスは汚くなってきている）
コードの欠陥にコメントをつける

TODO: あとで手をつける FIXME: 既知の不具合があるコード HACK: あまり綺麗じゃない解決策 XXX: 危険大きな問題がある

定数を定義する際には、その定数が何をするのか、なぜその値を持っているのかという背景が存在する場合が多いのでコメントをしよう
[ ] 質問されそうなことを想像する
ハマりそうな罠を告知する
全体像についてコメントする
処理についての要約のコメント
コメントは適当に書き出す→コメントを読んで改善が必要なものを見つける→改善の手順で書く。

コメントは正確で簡潔に

コメントはその書いた領域に対する情報の比率が高くないといけない

[ ] 複数のものを指す可能性がある「それ」や「これ」などのあいまいな代名詞を避ける
[ ] 歯切れの悪い文章を磨く
[ ] 関数の動作をより正確に具体的に記述する
[ ] 入出力のパターンを伝えることができる実例をコメントに書いておく
[ ] コードの意図を詳細レベルではなく、高レベルで記述する
[ ] よくわからない引数には、pythonでできるような名前付き引数コメントをつける
[ ] 情報密度の高い（多くの意味が詰め込まれた言葉や表現）を使ってコメントを簡潔に保つ

制御フローを読みやすくする

[ ] 左が調査対象（変化する）、右が比較対象（あまり変化しない）
[ ] 単純な条件を先に書く
[ ] 関心を引く条件や目立つ条件を先に書く
[ ] 条件は否定形より肯定形を使う
[ ] 否定形であっても単純で関心や注意を引く場合があるので、その場合はそっちを先に処理をする
[ ] 三項演算子はわかりにくくならないもの（単純な二つの値から一つを選ぶようなもの）なら使う
[ ] do-whileは使わない
[ ] 関数から早く返す(ネストを浅くするときも使うことができる)
[ ] if文などのループから返すのを内部で行うにはcontinueを使う
[ ] go toは使わない
[ ] ネストを浅くする

巨大な式を分割する

説明変数（式を表す変数）を使う

username = line.split(':')[0].strip()
if username == "hoge"

要約変数（大きなコードの塊を小さな名前に置き換えて、管理や把握を簡単にする変数）を使う

final boolean user_owns_document = (hoge == fuga);

ド・モルガンの法則を使う

not (a or b or c) <=> (not a) and (not b) and (not c)
not (a and b and c) <=> (not a) or (not b) or (not c)

分かりにくい短絡評価は良くない

assert((!(bucket = FindBucket(key)))||!bucket->IsOccupied());

今回の場合以下の方がわかりやすい

bucket = FindBucket(key);
if (bucket != null) assert(!bucket->IsOccupied());

複雑なロジックはhogeの反対を考えてみたり、否定したりして、もっと簡単で綺麗な書き方を見つける

コードが読みやすくならない変数の削除

変数の追跡が難しくなる、スコープが大きいと把握する時間が長くなる、変数の頻繁な変更に伴い現在の値の把握が難しくなる

[ ] 複雑な式を分割していない
[ ] より明確になっていない（変数にしなくても十分明確）
[ ] 一度しか使っていないので重複コードの削除になっていない
[ ] 中間結果を削除する

function hoge(array, value_to_remove){
    var index_to_remove = null;
    for (fugafuga) {
        if(array[i] === value_to_remove) {
            index_to_remove = i;
            break;
        }
    }
    if (index_to_remove !== null) {
        array.splice(index_to_remove, 1);
    }
}

関数から早く返すことで削除できる

function hoge(array, value_to_remove){
    var index_to_remove = null;
    for (fugafuga) {
        if(array[i] === value_to_remove) {
            array.splice(i, 1);
        }
    }
}

[ ] 制御フロー変数を削除するプログラムの実行を制御するためだけの変数であり、実際のプログラムに関係のあるデータは含まれていない

boolean done = false;

[ ] 変数のスコープを縮める
- アクセス修飾詞を使う
- 大きなクラスを小さなクラスに分割する
- 最初から全ての変数を知る必要はないので、変数の定義は変数を使う直前に移動する（変数の数による）
[ ] 変数は一度だけ書き込む変数を操作する場所が増えると、現在値の判断が難しくなる

無関係の下位問題を抽出する

プロジェクト固有のコードから汎用コードを分離するということ 1.関数やコードブロックを見て「このコードの高レベルの目標は何か？」と自問する 2.コードの各行に対して「高レベルの目標に直接的に効果があるのか？あるいは無関係の下位の問題を解決しているのか」と自問する 3.無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする

ただし、新しい関数をコードに追加すると、ごくわずかに読みにくさのコストが発生する。そことの兼ね合い。

一度に一つのことを

単一責任の原則

コードに思いを込める

1.コードの動作を簡単な言葉で同僚にもわかるように説明する 2.その説明の中で使っているキーワードやフレーズに注目する 3.その説明に合わせてコードを書く

[ ] ロジックを明確に説明する
[ ] ライブラリを知る
[ ] 解決策を言葉で説明する

プログラムを言語化（自然言語）することで、明確な形となる

短いコードを書く、コードを小さく保つ

もっとも読みやすいコードは何も書かれていないコード

不必要な機能をプロダクトから削除する、過剰な機能はもたせない
[ ] もっとも簡単に問題を解決できるような要求を考える
[ ] 定期的に全てのAPIを読んで、標準ライブラリに慣れ親しんでおく
- [ ] js
- [ ] ruby

テスト

今後追加します

参考リンク

http://qiita.com/Kenya/items/faec4cc374edd5ffbba6

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
出版社/メーカー: オライリージャパン
発売日: 2012/06/23
メディア: 単行本（ソフトカバー）
購入: 68人クリック: 1,802回
この商品を含むブログ (137件) を見る

2017-06-28

minify javascript

どうすれば王道の方法にたどりつけるか考えて検索できた。

minify js google でgoogleのdeveloperガイドが出てきて、jsを軽量化するには、uglifyjsかClosure Compilerでやるといいと書いて合ったので、githubのreadmeを読みつつやって見たら、ちゃんと一行にして、軽量化できた。

$ uglifyjs source/javascripts/vendor/cookie.js -c -m -o source/javascripts/vendor/cookie.js

-o, --output <file>          Output file (default STDOUT).
-c, --compress [options]     Enable compressor/specify compressor options.
-m, --mangle [options]       Mangle names/specify mangler options.

参考リンク

https://developers.google.com/speed/docs/insights/MinifyResources https://stackoverflow.com/questions/20653578/how-to-uglify-javascript-using-uglifyjs-2 https://github.com/mishoo/UglifyJS2 https://developers.google.com/closure/compiler/

2017-06-26

誰もあなたには興味がない、恥をかいた分だけ幸せになろう　「多動力」堀江貴文

多動力 (NewsPicks Book)

作者: 堀江貴文
出版社/メーカー: 幻冬舎
発売日: 2017/05/27
メディア: 単行本
この商品を含むブログ (3件) を見る

メモ

車輪の再発明をしないように気をつける
三つの肩書きを持てば1/100万。一万時間→1/100。仕事を掛け算するときは遠く離れてるものを掛け合わせた方が希少性が高まる。
全部自分でやらなければならないという思い込みをしていては多くの仕事をすることはできない、自分がもっとも力を発揮できる仕事だけをやろう
やりたいことはやりたいときに全部やり倒す習慣をつける
恥をかいた分だけ自由になれる
資産が人をダメにする。自分が持っているものをなんとか生かそうとすることであなたの動きは遅くなる、手持ちのカードを捨てやりたいことに最短距離で行こう hogeをしたい→hogeが必要が重要であり hogeをもっている→hogeをしないともったいないというのはよくない
予定調和の幸福を求める人生はつまらない、未体験の予定を詰め込んでみたことのない景色を見よう

感想、所感

ホリエモンはどの本でも一貫して、「やりたいことを今すぐやれ」ということしか言ってない気がする。すべてはそこから始まると

実際にできること

[ ] 一万時間がどのくらいなのか、年で計算する
[ ] 抱えているタスクをすべて書き出す
[ ] やらないタスクをやらない方法を考える
[ ] どんな形でもいいからアウトプットをする
[ ] 一日24時間をこと細かに書き出す
[ ] その中でワクワクしないことをやめる
[ ] 会うことがワクワクしない人は次会うので最後にする
[ ] 受けない仕事リストを作る
[ ] 退社時間を早めることで効率的に仕事を終わらせられるようにする
[ ] 同じような予定を過ごさない、土日の予定を考える

2017-06-26

あきらめない強い精神とは、まるで実態のない「できる」という呪文を頭のなかで反復する行為　「図解モチベーション大百科」

動機付け

キャンディ効果　メンバーのいい気分を作る　作業捗る
ご褒美の効果は二ヶ月
自問式セルフトーク　断定よりも疑問の方が答えとモチベーションを引き出す助けになる
日記に自分にとって今一番大切なことは何か、その価値に結びつくどんな行動をとったか書いてもらう、自分の価値観を思い出すと自信が強まり、周りの人に対する愛情が深まる
自発的な行動に対してご褒美を与えると内発的動機づけが損なわれる
なんの見返りも意義も生産性もないからこそ良い
やりたいことは手順を減らし、やめたいことは手順を減らす
他人の比較よりも自分の成長度合いによって評価された方が人は努力しやすい、前と比べてどうだったかを評価規準にする、客観的理由でやらない
インセンティブは成功したらあげるより、失敗したら取り上げる方が効果がある。基本的には安定や現状維持をめざしながら生きている

人をうごかすものは最終的には6つしかない

安定感
変化（不安定感）
重要感
つながり
成長
貢献

人材育成

人の考えは理由をたずねると強化され、目的をたずねると軟化する傾向がある
他人の言葉遣いに引っ張られず自分らしい言葉を使おう
やりたくないことはどうしたらやりたくなるかを考えよう
存在にむすびつけて褒めた方が意識の深いところに影響を与える
人は自分と主義が似ているけど考えを徹底していない人のことを嫌う傾向がある
仕事のずっと先を想像する、今自分が取り組んでいる仕事が社会にどんな風に役立つかを考えるとモチベーションが上がる
ダメだったものをまた試す、つまり何度か失敗したというだけでうまくいく可能性が残されているのにも関わらず私たちはいともたやすくあきらめやすい

目標設定

人は求められた以上のことはしない傾向にあるが、具体的で難しすぎず、受け入れられるレベルの目標を提示されるとやる気をだす、いつでもだれでも同じように解釈できる具体的なもの
競争心ではなく、あなたならできると向上心をあおる
信頼関係を築くには一緒に楽しいことをするより、協力が必要な場面を共有した方が信頼関係が芽生えやすい
目の前で起きている出来事そのものが、ラッキーかアンラッキーか決めているわけではなく、結果はその出来事に対して、どういう意味づけをするのかによって変化する
人は期限が見えないと集中できない
理由を考えると行動力が鈍り、何をすべきかに意識を向けると具体的な行動をしやすくなる
守らないと他人にどういう影響があるかを伝えよう
自分の作業日数は楽観的に見積もりやい
自分のこととなると安定志向になるが他人のことになると「なにをすれば後悔しないのかわかる」
エクササイズは2/3で疲れると予想する（コーチに10回やれと言われたら、15回くらいだと思うことにする）

意思決定

プロスペクト理論、得るものか失うものか話の順番によって選びたいものが変わる傾向がある
得られるものは何かにフォーカス→リスクのある選択肢を避ける、失うものは何かにフォーカス→多少のリスクをとってもいいと考えるようになる
穏やかに快適に暮らす幸せもある。あとで振り返った時にあのときは大変だったけど、良い経験だったと思える方が脳はより幸福を感じる。
自分の作業計画書を作る、必要なものをあたまで覚えていると必要以外のものも買ってしまいやすくなる、必要なものを紙に書いておけば衝動買いは減る、これは一日の予定も同様、朝一番に今日やることを紙に書いて、デスクの一番目立つところに貼っておく、シチュエーション別にやることを決める。休日も同様。
決定を先延ばしにすることによって自分にとって最適な答えを見つけやすくなる
常識はずれなものごとからはじめると独創的なアイデアがうまれやすい

OOCEMR

OUTCOME 何を差し置いても得たい結果を明らかにする
OPTION 選択肢を出し続けること
CONSEQUENSE なんでもいいからとにかく結果を出すこと
EVALUATE 得たい結果にどれだけ近づいているかを評価する
MITIGRATE マイナス面を減らすこと
RESOLVE 締め切りをつくること

自己管理

疲れているときほど、動作を大きくゆっくりにしよう
背中を丸めるとストレスのホルモンが出る
事前に考えすぎたり、分析しすぎたりすると行動力が鈍っていく
やりたくないことをするたびに自制心が減っていき、感情的になり、目の前の出来事に流されやすくなる
交互練習は集中練習と比べて、理解しづらく、成果も実感しにくいが、長期記憶の役にたつ
自分でコントロールできることがあると、幸せで健康的な生活を維持できる
ポジティブな空想は人をリラックスさせると同時に人の行動力を奪う可能性がある

発想転換

あきらめない強い精神とは、まるで実態のない「できる」という呪文を頭のなかで反復する行為
自分が直面している問題より他人が直面している問題の方が答えを見つけやすい
ピンチはチャンスというが、はじめからどこにでもチャンスはあるもの、ただピンチに没頭しているとチャンスが目の前を通っても気づけない
仮定で考えるよりそうなった前提から考えた方が、発想が膨らみやすい

感想、おもったこと

今回はメモしなかったが、人を巻き込む・仕事をしてもらう方法もたくさん書いてあったので、たくさんのひとに仕事を振るような立場になったら、もう一度読み返したい
モチベーションで大事なのは他人ではなく自分がどのくらい成長したか
物事を具体的にすれば行動につながる
期限とかを月単位のもの、週単位のもの、日単位のもの、三時間単位のもの、この30分間というように細かいものにしておくと、すぐに期限がせまってくるので、行動しやすくなる。結局だらだらまだ大丈夫というのは期限が先にあるからであって、常に期限が迫っている状態であれば、ケツに火がついてるどころか、ケツにロケットエンジンつけてるくらいのスピードで仕事できるのではないか。それはあと少し、あと少しと思い続けることによって工夫や行動の回数が増える。そしてその積み重なった達成感が自信に変わり、最終的にでかいことができる
プロスペクト理論はちょっと物事の言い方を変えるだけで、行動を促しやすくなるのでいいと思った。（リスクをとる選択肢を取って欲しかったら失うものは何かにフォーカスすればよい）
だれかに夢を語って気持ちよくなっていたらその時点でリラックスしてしまっているので、早くオフィスに帰って仕事をしましょう

具体的に実践できること

[ ] 今はポモドーロ効果を狙って、25分単位で作業をしているが、期限が細かく設定されていなかったので、二時間単位とかでの細かい目標もたてて、作業をする
[ ] 自分が取り組んでいる作業が自分のまわりの人、それよりもっと多くの人にとってどういう影響を与えているかを考える
[ ] すべてがうまくいったとしてどれくらいまでいけそうかを基準に目標を立てる
[ ] 二ヶ月後にご褒美を用意する
[ ] 自分が投下できると思った時間に2/3をかけて時間を割り出す
[ ] 普段の会話の中でプロスペクト理論を使う
[ ] 更新していないやりたいことリストを更新する
[ ] 前日の夜疲れている時間に次の日にやることを紙に書き出す
[ ] シチュエーション別にやることリストを作っておく
[ ] もう絶対に行かない授業を決める
[ ] 重要なこと（その課題の解決方法・実装方法など）は休憩を挟んでから決める
[ ] 人とは違う視点で物事を見るため、スケボーに引き続き乗り続ける
[ ] 飽きたらすぐ他の技術書・記事・リファレンスを読む
[ ] 夢を語ったら、夢が覚める前に現実に向けた一歩をふむ

図解モチベーション大百科

作者: 池田貴将
出版社/メーカー: サンクチュアリ出版
発売日: 2017/06/12
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

2017-06-19

pryについて

今まで

rubyのドキュメント( http://ref.xaio.jp/ruby )とかでそれっぽいメソッドを探していた。しかもこのドキュメントよく見たら、1.9くらいだった笑
検証したいときは、適当なとこにbinding.pry書いて、無理やりインタープリターを起動して検証したりしていた。

pryのちゃんとした使い方を知って

MacBook-Pro:~ hogehoge$ pry
[1] pry(main)> cd String
[2] pry(String):1> ls
String.methods: try_convert
String#methods:
  %    []           casecmp?    concat     each_codepoint  getbyte   length   ord           rstrip       slice        succ       to_str               unpack1
  *    []=          center      count      each_line       gsub      lines    partition     rstrip!      slice!       succ! 
……
……
……
……
locals: _  __  _dir_  _ex_  _file_  _in_  _out_  _pry_
[3] pry(String):1> show-doc upcase
From: string.c (C Method):
Owner: String
Visibility: public
Signature: upcase(*arg1)
Number of lines: 6

Returns a copy of str with all lowercase letters replaced with their
uppercase counterparts.

See String#downcase for meaning of options and use with different encodings.

   "hEllO".upcase   #=> "HELLO"
[4] pry(String):1> hoge = "hoge";
[5] pry(String):1> hoge.upcase!
=> "HOGE"
[6] pry(String):1> hoge
=> "HOGE"

みたいな感じで単純にメソッド探して、確認できるみたいな便利なことができると知りました。無知ですいませんでした。

[5] pry(main)> help

とやると他にも便利なメソッドがたくさんありそうです。

今流行りのdockerで使うには？？

$ docker-compose run --service-ports hoge

Run command with the service’s ports enabled and mapped to the host.

だそうです。

所感

ここら辺のserviceportとかとか、pryとかirbがどんな感じで動いてるかとかあまりわからないので、勉強しないと。

参考リンク

qiita.com

2017-06-19

rubyで最近へーと思った箇所まとめ

右辺が , 区切りで複数ある場合には配列に変換される

a = 1, 2 => [1, 2]
a.class => Array

右辺の要素の残り全部を配列として受け取ることもできる

a, *b = 1, 2, 3 => [1, 2, 3]
a.class => Integer
b.class => Array

全部捨てる←これは笑った

[11] pry(main)> * = 1, 2, 3 => [1, 2, 3]

hashは通常、一つの値として代入されるが、* をつけると Hash#to_a されて多重代入できるようになる

a = { a: 1, b: 2 } 
=> {:a=>1, :b=>2}
a 
=> {:a=>1, :b=>2}
a, b = { a: 1, b: 2 } 
=> {:a=>1, :b=>2}
a 
=> {:a=>1, :b=>2}
b 
=> nil
a.class 
=> Hash
b.class 
=> NilClass
a = *{ a: 1, b: 2 } 
=> [[:a, 1], [:b, 2]]
a.class 
=> Array
a 
=> [[:a, 1], [:b, 2]]
a, b = *{ a: 1, b: 2 } 
=> [[:a, 1], [:b, 2]]
a.class 
=> Array
a 
=> [:a, 1]
b 
=> [:b, 2]
b.class 
=> Array

FixnumクラスとBignumクラスがIntegerクラスに統合されたいつもこのwarningが出てて、その原因がわかってすっきり

/app/vendor/bundle/ruby/2.4.0/gems/middleman-core-4.1.10/lib/middleman-core/sitemap/resource.rb:88: warning: constant ::Fixnum is deprecated
/app/vendor/bundle/ruby/2.4.0/gems/sprockets-3.7.0/lib/sprockets/digest_utils.rb:47: warning: constant ::Fixnum is deprecated
/app/vendor/bundle/ruby/2.4.0/gems/sprockets-3.7.0/lib/sprockets/digest_utils.rb:51: warning: constant ::Bignum is deprecated
/app/vendor/bundle/ruby/2.4.0/gems/sprockets-3.7.0/lib/sprockets/processor_utils.rb:110: warning: constant ::Fixnum is deprecated
/app/vendor/bundle/ruby/2.4.0/gems/sprockets-3.7.0/lib/sprockets/processor_utils.rb:111: warning: constant ::Bignum is deprecated
/app/vendor/bundle/ruby/2.4.0/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:206: warning: constant ::Fixnum is deprecated

sumメソッド、引数で初期値変更、アルゴリズム的に、+より誤差が少ない、少数は誤差発生

[0.1, 0.1, 0.1].sum
=> 0.30000000000000004
['foo', 'bar'].sum('')
=> "foobar"
[[1, 2], [3, 1, 5]].sum([])
=> [1, 2, 3, 1, 5]

2.3.0~ digコマンド

h = { foo: {bar: {baz: 1}}}
=> {:foo=>{:bar=>{:baz=>1}}}
h.dig(:foo, :bar, :baz)
=> 1
h.dig(:foo, :zot, :xyz)
=> nil

From: hash.c (C Method):
Owner: Hash
Visibility: public
Number of lines: 9

VALUE
rb_hash_dig(int argc, VALUE *argv, VALUE self)
{
    rb_check_arity(argc, 1, UNLIMITED_ARGUMENTS);
    self = rb_hash_aref(self, *argv);
    if (!--argc) return self;
    ++argv;
    return rb_obj_dig(argc, argv, self, Qnil);
}

From: array.c (C Method):
Owner: Array
Visibility: public
Number of lines: 9

VALUE
rb_ary_dig(int argc, VALUE *argv, VALUE self)
{
    rb_check_arity(argc, 1, UNLIMITED_ARGUMENTS);
    self = rb_ary_at(self, *argv);
    if (!--argc) return self;
    ++argv;
    return rb_obj_dig(argc, argv, self, Qnil);
}

&. safe navigation operator nilでもNoMethodErrorにならずにnilを返してくれる

[18] pry(main)> str = nil
=> nil
[19] pry(main)> str.upcase
NoMethodError: undefined method `upcase' for nil:NilClass
from (pry):10:in `__pry__'
[20] pry(main)> str&.upcase
=> nil

所感

rubyはjavaとかに型とかのキャストの柔軟性とかが比べてすごい！！
C言語勉強して、rubyの裏も読めたらいいなー
*強い