3回目の転職活動で利用した転職サービスの雑感
転職（その２） Advent Calendar 2016 11日目の記事です。
久しぶりに転職活動を行ったので、その雑感を書いていきます。
筆者のスペック
Ruby、Javaでシステムの受託開発がメインで要件定義 〜 開発まで一通りやらせてもらった。
いままでは受託オンリーの仕事をしており、事業会社でのエンジニア経験も積みたかったので、転職を決めた。
転職エージェントは使えるか？
使おうかどうか迷ってたが、結局今回も2社ほどお願いした。
1社は今の会社の転職でもお世話になった転職サービス大手のI社だ。
もう一社はヒカリエに本社を構えるエンジニア転職に特化したR社である。
R社に関しては、エンジニア転職をメインに行っていると聞き、技術的なところも理解した上で色んな会社を紹介してくれると期待したが、エージェントの技術的な知識が皆無で、I社にくらべて、R社を利用するメリットが無いと感じた。
そんなわけで最終的にR社は切ってしまった。
後、今回は年収を上げることも目的としてあったのだが、これに関してはどちらのエージェントも態度が消極的だった印象がある。
本音を言うと、年収upの戦略や助言みたいなのも期待していたので、残念だった。
転職ドラフトも使ってみたよ。
これも3回くらいドラフトに参加した。
ありがたいことに色んな企業から面接のオファーを頂くことも出来た。
このサービスは自分の経歴を企業側が読んで、予め想定年収を提示してくれるため、終盤のメンドクサイ年収交渉をある程度スキップできるところが非常に良かった。
興味がある会社から面接オファーが来ても、提示年収が低ければ、断ることもできるので、余計な労力を使わずに済んだのは非常にありがたかった。
また、ある会社が他のエンジニアにどれくらいの年収でオファーを出すのかも分かるので、その会社の年収相場みたいなものも分かるのが良かった。
これにより、興味はあるが、年収相場があまりにも低い企業を発見できたりと、色々調査できるのが面白い。
最後に
最終的にエージェントを通して、転職が決まったが、個人的には転職ドラフトは大きくなってほしいサービスだと思っているので、次、もし転職する機会があれば、また使ってみたいとは思っている。
【Objective-C】翌日の指定時間のNSDateを取得する。
翌日の指定時間を取得したかったので、色々調べた結果 下記のような感じで書けそう。
NSDate* date = [NSDate date];
NSCalendar *calendar = [NSCalendar currentCalendar];
NSDateComponents *dateComps = [calendar components:NSYearCalendarUnit |
NSMonthCalendarUnit |
NSDayCalendarUnit |
NSHourCalendarUnit |
NSMinuteCalendarUnit |
NSSecondCalendarUnit fromDate:date];
// 例）翌日の20:00を取得したい。
[dateComps setDay:(dateComps.day + 1)];
[dateComps setHour:20];
[dateComps setMinute:0];
[dateComps setSecond:0];
NSDate * notification_date = [calendar dateFromComponents:dateComps];
NSLog(@"date: %@", notification_date);
date: 2014-06-19 11:00:00 +0000
リファクタリング：Rubyエディション を読んだ。 〜 6章まで
- 作者: Jay Fields,Shane Harvie,Martin Fowler,Kent Beck,長尾高弘
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2010/02/27
- メディア: 大型本
- 購入: 9人 クリック: 321回
- この商品を含むブログ (47件) を見る
久しぶりにリファクタリングについて勉強したくなったので、 読んで、重要と思った部分をメモ書きする。
第1章 リファクタリング
一時変数をメソッドにリファクタリングする際にパフォーマンスの低下が懸念されるかもしれない。（P41）
- そんなに問題にならないケースが多い。
- できるだけ、リファクタリングは保守性を重視して、読みやすく変更を加えてやるべき。
- 一時変数は無用に多くの引数をやりとりする原因になる点でない方が良い。
- 一時変数を取り除けば、コードが何を使用としているのかがはっきりと分かるようになる。
※ 実際は一時変数をメソッドに置き換えて、リファクタリングをする人がどれくらいいるのか調べてみても良いかもしれない。
リファクタリングの問題点
インターフェースを公表済みの場合
- 公表済みのインターフェースをリファクタリングをするのは、それの周知にコストがかかる。
- したがって、普通は旧インターフェースと新インターフェースを両存させる。
第6章 メソッドの構成
メソッドの抽出
コードの断片をメソッドにして、その目的を説明する名前をつける。
利点
Tips
一時変数から問い合わせメソッドへ
式をメソッドにする。一時変数の全ての参照箇所を式に置き換える。新しいメソッドは他のメソッドからも使える。
利点
一時変数からチェインへ
チェイニングをサポートするようなメソッドに書き換え、一時変数を不要にする。
利点
- 不要な一時変数を削除できる。
- 自然に読めるようにコードを組み合わせられるインターフェースが増えるので、保守性が向上する。
Tips
- チェイニングできるようにしたいメソッドからはselfを返すように実装する。
- 一つのオブジェクト内でチェインは完結させたほうが良い。そうすることによって、表現力を高めることができる。
説明用変数の導入
処理の目的を説明するような名前を持つ一時変数に式、または式の一部の結果を代入する。
利点
- 複雑な条件式が読みにくい場合は一時変数を使えば、式を管理しやすい形に分解出来る。
Tips
一時変数の分割
代入毎に別々の一時変数を用意する。
利点
- ループ変数や結果蓄積用変数でないにもかかわらず、同じコンテキスト内で同名変数を使用すると、読み手が混乱するため、必ず別々の変数名を用意すること。
メソッドからメソッドオブジェクトへ
「メソッドの抽出」ができないようなローカル変数の使い方をしている長いメソッドがあるとして、メソッドを独自のオブジェクトに変え、全てのローカル変数がそのオブジェクトのインスタンス変数になるようにする。こうすれば、メソッドを分解して、同じオブジェクトの別のメソッドにすることが可能になる。
利点
- ローカル変数はメソッドオブジェクトの属性になり、このオブジェクトを対象として「メソッドの抽出」を行うと、元のメソッド分解して小さなメソッドを作ることが可能になる。
- 作成したオブジェクトのメソッドに処理を委譲することで、引数渡しの心配をせずにメソッドの抽出が可能になる。
ループからコレクションクロージャメソッドへ
利点
- コレクションの中を行き来したり、派生コレクションを作ったりするためのインフラストラクチャコードを隠し、ビジネスロジックに集中できるようにしてくれる。
Tips
managerOfiices = employees.select {|e| e.manager? }.
collect{|e| e.office }
- 合計の計算のように、ループ内で一つの値を生み出すような処理をしなくてはいけない時には、
injectメソッドを使用する。
total = employees.inject(0) {|sum, e| sum + e.salary}
サンドイッチメソッドの抽出
重複部分を抽出して、ブロック付きのメソッドにする。この種のメソッドは呼び出し元に一時的に制御を返してくる。呼び出し元は、制御を返された時に実行するコードをブロック内に記述する。
利点
- 前後の重複部分を抽出してメソッドにまとめることができる。
- インフラストラクチャコード（コネクションを反復処理するためのコード）を隠して、ビジネスロジックを全面に押し出すことができる。
- つまり、公開メソッド内に保つことができるのでメンテナンスがしやすくなる。
クラスアノテーションの導入
クラス定義からクラスメソッドを呼び出してふるまいを宣言する。
利点
- 宣言的な構文でコードの目的が明確につかめる場合には、「クラスアノテーションの導入」を使うと、コードの意図を明確にできる。
- 有名な例としては、属性アクセッサが挙げられる。
Tips
- 様々なクラスで使いまわせそうであれば、Moduleとして抽出して、Classクラスに移した方が良い。
名前付き引数の導入
引数リストをハッシュに変換し、ハッシュキーを引数の名前として使う。
利点
- 他のオブジェクトに処理を移譲をしようする際に、渡す引数の役割が明確になっていれば（公開インターフェースが明確な振る舞いをきちんと表現していれば）、移譲先のオブジェクトの詳細を深く見なくても済む。
Tips
- アサーションの導入すると、下記２点の利点がある。
- 渡さなければいけない引数の種類の明確化
- キーの綴りの間違い時の検出
module AssertValidKeys def assert_valid_keys(*valid_keys) unknown_keys = keys - [valid_keys].flatten if unknown_keys.any? raise(ArgumentError, "Unknown key(s): #{unknown_keys.join(",")}") end end Hash.send(:include, AssertValidKeys) # Hashオブジェクトを拡張する。 Class Books def self.find(selector, hash={}) # ここでhashに渡すキーの種類が確認できる。 # 誤ったキーが与えられるとArgument Error が発生する。 hash.assert_valid_keys :conditions, :joins # 以下、省略
Books.find(:all) Books.find(:first, :conditions => "authors.name = 'Jerry James'", :joins => [:authors])
- 呼び出し元のコードが分かりやすくなるという利点がある一方で、呼び出されるメソッドが複雑になるコストもかかってしまうので、呼び出されるメソッドをそこまで複雑にする必要性がない場合は、名前付き引数を取り除く
動的メソッド定義
メソッドを動的に定義する。
利点
- 読みやすくメンテナンスし易い形式でメソッド定義を簡潔に表現できる。
Tips
class Class def def_each(*method_names, $block) method_names.each do |method_name| define_method method_name do instance_exec method_name, &block end end end end
def_each :failure, :error do |method_name| self.state = mathod_name end
- クラスアノテーションを使用すれば、より表現力の高いコードが書ける。
class Post def self.states(*args) args.each do |arg| define_method arg do self.state = arg end end end states :failure, :error, :success end
- 動的に定義されたモジュールをextendしてメソッドを定義する。
class to_module def to_module hash = self Module.new.do hash.each_pair do |key, value| define_method key do value end end end end end
class PostData def initialize(post_data) self.extend post_data.to_module end end
動的レセプタから動的メソッド定義へ
利点
- method_missingを利用したクラスのデバッグは悲惨になりやすく、最悪の場合スタックレベルが深くなりすぎてエラーになる。オブジェクトがどのように使われているかわかっているケースではmethod_missingを使わずに振る舞いを実現できる。
Tips
- method_missingを使わない動的な移譲
- 無効なメソッド呼び出しはデコレータのNoMethodErrorsとして正しく報告される。
- method_missing定義もないため、スタックレベルが深くなりすぎることもない。
class Decorator def initialize(subject) subject.public_methods(false).each do |meth| (class << self; self; end).class_eval do define_method meth do |*args| subject.send meth, *args end end end end end
属性の中にnilのものがあるかどうかを判定する。
class Person def self.attrs_with_empty_predicate(*args) attr_accessor *args args.each do |attribute| define_method "empty_#{attribute}?" do self.send(attribute).nil? end end end attrs_with_empty_predicate :name, :age end
動的レセプタの分離
新しいクラスを導入し、method_missingのロジックをそのクラスに移す。
利点
- 新しいクラスにメソッドmethod_missingを移動させることによって、method_missingを利用することで発生するデメリット（予想外のNoMethodErrorの頻発やSystemStackErrorを発生）を抑えることができる。
Tips
Gitポケットリファレンスを読んだ
- 作者: 岡本隆史,武田健太郎,相良幸範
- 出版社/メーカー: 技術評論社
- 発売日: 2012/07/10
- メディア: 単行本（ソフトカバー）
- 購入: 7人 クリック: 103回
- この商品を含むブログ (25件) を見る
プロジェクトでGitを使う機会が増えてきて、 通常の業務で困ることがなくなったけど、 もうワンランク使いこなせるようになりたいなーと思ったので、 読んでみた。
以下、勉強になったコマンドを張り付けていく。
git config
Git の各種設定を表示、変更する。
以下、興味をもった設定のみ記載。
commit.template
コミットメッセージのテンプレートをファイルで指定する。
core.whitespace
git diffなどで不正な空白文字を検出して通知する。
push.default
引数なしでgit pushされた際に、どのブランチにプッシュするか指定する。
git commit
インデックスに登録した変更内容をローカルリポジトリに反映する。
-a
バージョン管理している全変更をコミットする。
-c
コミットメッセージを以前のコミットやタグから読み込む
--dry-run
コミット結果を表示。実行はしない
git add
変更内容をインデックスに登録して、コミット対象にする。
-p
パッチ形式で確認しながら１つずつインデックスに登録する。
-A
バージョン管理対象になっていないファイルも含め、すべてをインデックスに登録する。
-n
addコマンドの実行結果を確認する。
-i
変更内容をファイルずつ確認しながら、インデックスるに登録する。
git rm
バージョン管理しているファイルを削除して、バージョン管理の対象外とする。
-- cached ファイルを残したまま、バージョン管理対象からファイルを削除する。
git reset
インデックスに登録したファイルをコミット対象から外します。
-p
インデックスに登録された変更箇所をバッチ形式で１つずつ選択して、インデックスから取り除きます。
--hard HEAD^
直前のコミットの一つ前の状態にソースを戻す。
--hardを間違えて実行した場合
reflogを使う。
git revert
コミットした内容を取り消すコミットを実行する。
-m parent-number
マージコミットを取り消す際にどのブランチをメインラインとして残すかを指定する。
--no-edit
revert用に自動生成されるコミットメッセージをそのまま採用する場合に指定する。
-n（--no-commit）
revert内容のコミットを自動で行わない。
git pull
共有リポジトリ（リモートリポジトリ）から変更を取得し、現在のブランチにマージします。
--rebase
変更を取得した後、rebaseを行う。
--no-ff
必ず、マージコミットを行う。明示的にマージしたコミットを残す際に利用する。
--squash
リモートブランチの複数のコミットを一つのコミットにまとめてブランチに取り込む。
git fetch
共有リポジトリ上のリモートブランチの変更を取得する。
-p
取得後に存在しなかったリモート追跡ブランチを削除する。
--dry-run
取得結果を確認する。取得結果の反映はしない。
git push
ローカルブランチへの変更を共有リポジトリへ送信します。
-u
新規に作成したリポジトリやブランチをプッシュする際に、ローカルリポジトリのブランチとプッシュ先リポジトリのブランチの対応付けを行う。
--mirror
リモートリポジトリにローカルリポジトリの内容をそのまま複製したいときに使用する。
git remote
リモートリポジトリを一覧表示、追加、削除、変更をします。
-t branch
pullコマンドで更新内容を取得するリモートリポジトリを限定できる。
remote prune
リモート名
git branch
--no-merged
カレントブランチにマージされていないブランチを表示する。
--merged
マージ済みブランチを表示
デフォルトでは共有リポジトリのタグやブランチをどのユーザでも消せてしまうので、共有リポジトリにフックを設定することでそれを防ぐことが可能。
git checkout
-b
ブランチを作成して、切り替える。
-t
リモート追跡ブランチからブランチ作成をする前に、作成するブランチにアップストリーム設定をする。 ※ アップストリーム設定とはpushやpull時の指定を省略できる。
-p
パッチ形式で確認しながら1つずつコミット時点のものに戻す。
git tag
-a
注釈付きのタグを作成する。
-s
署名付きのタグを作成する。
git archive
配布用のファイルを作成する。
git merge
対象ブランチの変更を現在のブランチに取り込む
--no-ff
マージコミットを必ず生成する。
--log
マージコミットのコミットメッセージにマージされるコミット郡の一行目のコミットメッセージを含める。
--no-commit
マージ後、自動的に行われるコミットを行わない。
競合発生時でファイル単位で解決を行う場合
git checkout MERGE_HEAD XXXX.txt git checkout ORIG_HEAD XXXX.txt で解決できる。
Merge時にFast-forwardマージとコミットマージのどちらを採用すればよいか？
ウォータフォール的にかっちりとした開発モデルのプロジェクトの場合はどのブランチで作業して、いつマージしたかを分かりやすく把握するためにコミットマージを使用する。開発者が分散していて、自由度の高いOSSプロジェクトの場合は、「履歴を一直線に保って見やすくする」方針を取ることが多い。
git rebase
コミット履歴を変更して、ブランチの分岐元を置き換えることができる。また、コミットの順番の入れ替え等、コミット履歴を編集できる。
--onto []
ブランチが「どこのブランチから分岐したか」を修正します。実行後は、
rebase | --continue | --skip | --abort
rebase実行中に、競合が発生した場合、競合を解決してrebaseを続けるか、競合が発生したコミットをスキップしてrebaseを続けるか、rebaseを取りやめて、rebase実行前の状態に戻るか選択する。
--continue
競合解決中にリベースを再開したい場合に使用する。
--skip
競合解決中にそのコミットをスキップしたいときに使う。スキップしたコミットは適用されない。
--abort
競合解決中にリベースを中止し、リベース開始前の状態に戻りたい場合に使用する。
--squash
複数のコミットを一つにまとめる。
git log
現在のブランチのコミットメッセージを表示します。
--graph
コミットの履歴をグラフで表示する。
--color
出力を色付けする。
--left--right
2つのブランチ間のコミットの差を表示する場合に使用する。
--reverse
逆順に表示する。（古いコミットから順に表示する。）
git diff
インデックスに未登録の内容や次のコミットで反映される内容を表示します。
--cached
特定のコミットとインデックス間の差分を表示する。
-w
行同士を比較するときに、すべての空白文字を無視して比較する。
-b
行末の差分を無視して、差分を表示する。
git show
コミットの差分、もしくはファイルの内容を表示する。
--oneline
コミットメッセージを1行で表示する。
git blame
ファイルの特定の場所がどのコミットで変更されたかを参照できる。
-L
表示する行の範囲を指定する。
-M
同じファイル内でコピー&ペーストした行を検出し、元となるコミットを表示する。
git reflog
リポジトリの操作履歴を確認できる。
git svn
SubversionのリポジトリをGitで操作する。
Subversionを共有リポジトリに使用していても、ローカルではGitを使用できる。
パーフェクトRuby を読んだ。
- 作者: Rubyサポーターズ,すがわらまさのり,寺田玄太郎,三村益隆,近藤宇智朗,橋立友宏,関口亮一
- 出版社/メーカー: 技術評論社
- 発売日: 2013/08/10
- メディア: 大型本
- この商品を含むブログ (16件) を見る
Ruby歴3年ですが、ここで初心に戻って、 パーフェクトRubyを読んだので、興味のあるところを 備忘録で示す。
例外処理
rescue 引数なしは Standard Error を補足
begin
error_method # 例外発生を含むメソッド
rescue => e # standard Error とそのサブクラスを補足。
end
rescue後のraiseで同様のエラーを発生させられる。
begin
error_method # 例外発生を含むメソッド
rescue => e
raise # eと同じ内容の例外が発生
end
後置rescueはStandard Errorのみ補足
（例１）
raise rescue puts('error') # error (例外を補足する)
（例２）
raise Exception rescue puts('error') # これはエラーを補足しない。
メソッドで例外を補足する。
def
error_method
rescue
## メソッド呼び出し時に例外発生した場合に補足
end
クラスやモジュールで例外を補足する。
class
## 何らかの処理
rescue
## クラス定義時に例外発生した場合に補足
end
例外のリトライ
rescueの中でリトライをするとbeginからやり直す。
その他
- 例外が発生しなかった時のみ処理するelseが使用できる。
大域脱出
任意処理からの脱出
- ネストしたループなどで一気にループを抜け出したいときはcatch,throwを使う。
- throw時にループを抜ける箇所を指定するシンボルを指定することができる。
メソッド定義と呼び出し
メソッドのカッコ（）の付け所
括弧がいらないケース
- 戻り値が必要ない。
set_current member
- メソッド引数がない。
member = find_menber_first
メソッド呼び出しとローカル変数
- メソッド呼び出し（括弧なし）とローカル変数はかぶるので、注意する。 そういう時は明示的に（）をつける。
ブロック
- yealdを含むメソッドはブロックを必ず渡すこと。でないと、エラーになる。
- 仮引数に＆blockとすると、Procオブジェクトとしてブロックにアクセスできる。
- ブロック内でnext,breakが使用できる。戻り値の返し方がそれぞれ違うので注意。
- ブロック内の変数はスコープ外の変数にアクセスすることができる。
- メソッド呼び出し時、実引数の先頭に「&」をつけると、Procオブジェクトをブロックとして渡せる。
people = %w(Alice Bob Charlie)
block = Proc.new{|name| puts name}
people.each %block # Alice Bob Charlie
- ブロック引数に引数なしのメソッドを使う場合は下記の用に書ける。
container.map(&:method_name)
ブロックは準備 → 本質的な処理 → 後片付け といった前後の処理を共通化する際に役立つ。
- ファイルのOpen/Close、DBへの接続/切断
ブロックにはブロック外の同名変数に影響を受けないブロックローカル変数が存在する。
someone = 'Dave'
%w(Alice Bob).each do |person; someone| # ;のあとに定義する。
someone = person
end
someone # => 'Dave'
外部ファイルの読み込み
- require や load は $: , $LOAD_PATH に格納されているファイル・ディレクトリを探す。
モジュール
- クラスがモジュールを取り込んだ際、インスタンスメソッドを取り込み事ができる。
- 特徴」と取り込むことができる。
- extend でオブジェクトに特異メソッドを取り込むことができる。
- クラス内でextend モジュールでクラスメソッドを定義する。
- モジュール関数 ... サブルーチンとして利用されることを目的としたメソッド
- Privateなインスタンスメソッド
- モジュールの特異メソッド
- autoload 必要時に読み込みする。
オブジェクト
オブジェクトのコピー
- dup, clone でも参照先の配列の要素はコピーしない。したがって、コピー元の要素を変えた場合、コピー先の要素も変わってしまう。
Enumerable
Hash
- Ruby1.9ではHashは順序を保持する。
外部イテレータを用いると、柔軟な繰り返しが行えて、複数の配列を一度に使用したいことができる。
- Enumerator#rewind, Enumerator#next を使う。
IO・File
- Enumerator#rewind, Enumerator#next を使う。
ファイルのオープン・クローズはブロックを使用した方が手軽に書ける。
- 各１行の取り出しはeach_line を使う。
- エンコーディング情報は外部と内部で所持しているため、適切に指定すること。
スレッド
あとで試す。
Struct
- 構造体を示すクラス。
- 使いドコロがいまいちわからん。
クラスオブジェクト
- Class.new でクラスの定義が可能
- Class XXX end との違いは？
- Class.new でクラス定義するメリットはブロックでメソッドを定義するため外部スコープの変数を参照できる。
- Class.newを定数に代入するか、変数で代入するかで挙動が変わる。
- 定数の場合 … クラス名を持ったClassオブジェクト
- 変数の場合 … 無名クラスができる。
- selfがクラス自身を表す部分で定義するインスタンス変数をクラスインスタンス変数と呼ぶ。
- クラスメソッドはクラスオブジェクトに定義された特異メソッドである。
- クラスの定義外でもクラスメソッドを定義することが可能。
- インスタンスメソッドもメソッド定義式を使わずに定義可能。
- Module#define_methodを使えば可能
メソッド探索方法
- include module でインクルードしたクラスの一つ上の階層に無名クラスが定義される。
- 連続でmoduleをincludeした場合は、後のmoduleが近くなる。
Module#prepend
- メソッド実行前に処理をはさみたいときはModule#prependを使用する。
- prependにて同名のメソッド内にsuperを組み込むことによって、prependしたクラスの前処理を挟むことが可能。
7-2 BasicObject#method_missing
- method_missing内で存在しないメソッドを呼ぶと無限ループになってします。
7-3 eval
- evalで文字列をそのプログラミング言語の式として評価できる。
- 実行コンテキストを共有するために、実行中のコンテキスト内の変数を共有できる。
- evalにてメソッド定義が可能。
- メソッド名が違うけど、ほとんど同じような処理を行っているものの定義に有効。
- 動的なメソッドの追加も可能。
- あるコンテキストで定義された変数やメソッドなどをまとめたオブジェクトをBindingオブジェクトと呼ぶ。
- コンテキストの内容を様々な場所で持ち回すことが可能。
- eval の第2引数 もしくは Binding#evalで呼び出し可能。
- module_eval, class_eval, instance_evalで式を評価するコンテキストとなるモジュール、クラス、オブジェクトを指定してevalすることが可能。
8-1 Procクラス
- Proc#===でProcオブジェクトで定義したブロックを呼び出す。
- when式ではcase式で評価したい値と\=\=\=でマッチさせたい式を書くため、Procを渡すと\=\=\=でブロックが実行されるため、ブロック内の返り値と評価させることができ、柔軟な評価式を記述することが可能。
8-2 Proc#new以外のProcオブジェクトの作り方
- Kernel#lambda で Proc を生成可能。
- -> が lambda のシンタックスシュガー
- Proc#new, Kernel#proc, Kernel.lambdaでreturnやbreakの挙動が異なるので注意。
- Kernel#lambdaは引数の数が一致していないとエラーになる。
10-1 オブジェクトについて調べる
- インスタンス変数名の確認や更新をアクセサを無視して、行えるメソッドがある。
- オブジェクトのインスタンス変数を確認。
- Object#instance_variables
- Object#instance_variable_defined?
- オブジェクト変数の値を更新
- Object#instance_variable_get
- オブジェクトのインスタンス変数を確認。
- オブジェクトが持つメソッドの調べ方
- メソッドの可視性によって、使うメソッドが異なる。
| メソッド | スコープ |
|---|---|
| Object#methods | プライベートメソッド以外のメソッド |
| Object#public_methods | パブリックメソッド |
| Object#private_methods | プライベートメソッド |
| Object#protected_methods | プロテクテッドメソッド |
| Object#singleton_methods | 特異メソッド |
- オブジェクトが持つメソッドの調べ方 その2
- Object#respond_to?
- メソッドの可視性に関わらず、Object#sendでメソッド呼び出し。
- sendは他の場所で使われている可能性があるメソッド名のため、sendがエイリアスとして、使用できる。
10-2 クラスについて調べる
- Module#ancestors で継承しているモジュールやクラスがわかる。
- Module#included_modules でインクルードしているモジュールのみわかる。
- Module#nesting でモジュールの階層が判明する。
- クラスメソッドは未定義にしたり、新しく定義したりすることが可能。
- ActiveSupport::Concern をextendしたモジュールはClassMethodsをモジュールとして定義することで、そのモジュールをincludeしたクラスにクラスメソッドを提供する。
10-3 イベントをフックする
- クラスの継承されたタイミングやモジュールがincludeされた際にフックが可能。
- Module#included モジュールのinclude時
- Module#extended モジュールのextend時
- Class#inherited クラスの継承時
- メソッドの追加、削除、禁止時にイベントをフックすることも可能
12-1 組み込みツール
- irb
- RubyGems
- gemのコマンドに対して、常にオプションを指定できるように .gemrc を定義可能。
- 複数あるバージョンの古い方を削除する cleanup
- -d でドライランが可能。
- インストールしたgemパッケージを元に戻す prinstine
14-1 標準外のツール
Bundler
- bundle outdated はインストール済みのバージョンと最新バージョンを比較する。
- bundle open はGemをインストールしたディレクトリでエディタを開く。
- Gemの動作を確認したい際に便利
- bundle console はgemを読み込んだ状態でpryを呼び出す。
- 開発ツール系のGemはアプリケーションに読み込ませる必要はない。
- Gemfileでrequire => false とすると、アプリに読み込まないので、 メモリの使用量を抑えることが可能。
- bundle package でキャッシュしたGemをインストール可能
- デプロイの度にbundle installしている時間が膨大な場合はこちらを利用すると良い。
Capistrano
- デフォルトのデプロイ先は /u/apps/#{app_name}
- cap -v でログを表示制御 -vv, -vvv でより詳細
- タスクの中にTrnsactionとRollbackを載せることが可能。
- Capistranoのフック
- 複数登録ができる。
- フックする内容をブロックで渡せる。
- パスワードを書くのはセキュリティ上問題になるので、コマンドラインインターフェースを使用する。
- 実行結果を利用して、Capistranoの処理を分岐させることが可能。
- capture
- 指定した:roleの最初のサーバで実行した内容を取得できる。 - サーバのディスク容量を確認して、なんらかの処理を行う等の確認ができる。
- stream
- 複数のサーバに継続的にアウトプットを得たいときに利用する。
- tailを利用すると、複数のサーバのログを全部覗くことができる。
- 複数のサーバに継続的にアウトプットを得たいときに利用する。
- capture
yard
- yard diff
- gemのバージョン間でのdiffを行ってくれる。
- バージョンupのメソッドやクラスの増減をチェックしてくれる。
pry
binding.pry
- 埋め込んだ部分のスコープでオブジェクトの内容を確認できる。
- 変数の書き換えも可能。
show-source
- gemのソースを見る。
- show-doc
- ドキュメントを見る。
- edit
- Pryからエディタを起動させて、評価することができる。
- .pryrcで起動時にデフォルト設定をする。
- 詳細はPryのwiki もしくは Pry::Configを参照。
- pry-stack_explorer
- 起動した時点での呼び出しスタックを表示して、スタックが示すコンテキストの選択と移動が可能。
- さらにそのコンテキストのスコープで変数の確認も可能
- デバッグや開発中のソースを追うことができる。
- 起動した時点での呼び出しスタックを表示して、スタックが示すコンテキストの選択と移動が可能。
- pry-debugger
- ブレイクポイントを設定して、デバッグが可能。
capistrano の topメソッド
topメソッドが何してくれるのかわからなかったので、調査。
Definition
top()
Module
Capistrano::Configuration::Namespaces
使い方
namespace :cache do
task :warm_up do
# ...
end
end
namespace :deploy do
namespace :cache do
task :restart do
# ...
end
end
task :default do
update_code # (1) 同じネームスペースのupdate_codeが呼ばれる。
cache.warm_up # (2) トップレベルの「cache」ネームスペースではなく、「deploy:cache」ネームスペースのwarm_upが呼ばれる。
end
task :update_code do
# ...
end
end
（２）でトップレベルの「cache」ネームスペースのwarm_upを呼びたい場合は下記の書く。
task :default do update_code # calls the task in the same scope top.cache.warm_up # uses the top-level cache namespace end
