コードレビューの際に気をつけること - Qiita
コードレビューをする際と、してもらう際に気をつけるべきだと思っているをまとめておきます。 レビュイーとして大切なこと コードレビューをお願いする前に レビュアーが高いパフォーマンスを発揮するためには、レビューを受ける人の心構えと事前の打ち合わせが実は最も大切です。 特に大きめの変更のコードレビューをお願いする前にすると良いこととしては、 まず、レビュアーを確保する そのレビュアーと大まかな設計の合意をとる という方針でやっていくのが良いです。 レビューしていても、根本をひっくり返すような指摘はしにくいですし、したとしても、それなら1から書いたほうがはやくて良い物が出来るといったことが簡単に起きます。 「レビュー後に直せるもの < レビュー前に直せるもの」 ということを意識して、Issueなどを用いて、出来る限り事前に設計、打ち合わせをしましょう。そうすればレビュアーもすんなりレビューできる
Wantedlyで行っている開発者用Macの設定方法（主にインターン用） - Qiita
Wantedlyでは、開発PCは基本的にはMacで統一しており、社員全員にMacbook AirかMacbook Proを支給している。 インターンも最近人数が多いのである程度の数のMacを用意しておいて、それを使いまわすという運用を行うようになってきている。 Wantedlyでは、新しいMacを買ってから行う設定をある程度自動化しているので、今回はこの流れを公開しようと思う。 本来はこの作業を行った後、プロジェクトごと（Web/iOS/Android等)のセットアップを行うという流れになる。ここも特にWeb用の設定は結構自動化されている。 Macの初回セットアップ 日本語でセットアップ iCloudなどEmailが必要なものは登録しないでスキップ 起動後、Xcodeダウンロードまで Dockにデフォルトで存在しているものを消す 好みの問題だがほぼすべて消してOK 最終的に以下の2つぐらい
Ruby力を一段アップするために読んだほうが良い公式ドキュメント集 - Qiita
インスタンス化に関係する ::new, #new, #allocate と継承に関係する #superclass, #inhereted しか定義されていない。 その他のメソッドはすべてスーパークラスであるModuleに定義されている。Classはインスタンス化できるModuleと考えれば良い。 SuperClassの関係 [1] pry(main)> Class.superclass => Module [2] pry(main)> Module.superclass => Object [3] pry(main)> Object.superclass => BasicObject [4] pry(main)> BasicObject.superclass => nil [5] pry(main)> nil.superclass NoMethodError: undefined meth
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
