self と self.class の違い
self.classは自身のクラスを返す。selfは自身のクラスまたはインスタンスを返す。
class Hoge def moge puts self.class.methods end def noge puts self.methods end end h = Hoge.new h.moge puts "-----" h.noge
出力結果は下記となる。
new allocate superclass <=> module_exec class_exec <= >= == === include? included_modules ancestors name public_instance_methods instance_methods private_instance_methods protected_instance_methods const_get constants const_defined? const_set class_variables class_variable_get remove_class_variable class_variable_defined? class_variable_set private_constant public_constant singleton_class? deprecate_constant freeze inspect module_eval const_missing prepend method_defined? class_eval public_method_defined? private_method_defined? < public_class_method > protected_method_defined? private_class_method to_s autoload autoload? instance_method public_instance_method include instance_of? public_send instance_variable_get instance_variable_set instance_variable_defined? remove_instance_variable private_methods kind_of? instance_variables tap public_method singleton_method is_a? extend define_singleton_method method to_enum enum_for =~ !~ eql? respond_to? display object_id send nil? hash class singleton_class clone dup itself taint tainted? untaint untrust trust untrusted? methods protected_methods frozen? public_methods singleton_methods ! != __send__ equal? instance_eval instance_exec __id__ ----- moge noge instance_of? public_send instance_variable_get instance_variable_set instance_variable_defined? remove_instance_variable private_methods kind_of? instance_variables tap public_method singleton_method is_a? extend define_singleton_method method to_enum enum_for <=> === =~ !~ eql? respond_to? freeze inspect display object_id send to_s nil? hash class singleton_class clone dup itself taint tainted? untaint untrust trust untrusted? methods protected_methods frozen? public_methods singleton_methods ! == != __send__ equal? instance_eval instance_exec __id__
手段が目的となっても良い
概要
「手段と目的を混同してはいけない」「手段の目的化はダメ」のようなセリフはこれまで生きてきて何度も聞いていて、その意味や伝えたいことはなんとなく理解していたつもりでしたが、具体的に考えてみると違和感が出てきました。結論として、手段が目的化することは必然的であり、むしろ「手段が目的になるように手段を設定しなければならない」という考えに至りましたので、下記に整理しておきます。
目的の定義
目的は達成するべき事柄です。目的と手段は木構造となっており、最上部に位置する目的をここでは「根本の目的」と呼びます。
手段の定義
手段は目的を達成するために、実行しなければならない行動や達成しなければならない事柄です。
目的と手段の関係
目的を達成するためには、1つ以上の手段を実行しなければなりません。実行しなければならない手段は、そもそも達成するべき事柄として設定したはずなので、目的とも言い換えることができます。つまり手段が発生した段階でそれは同時に目的でもあるということです。
逆に達成する必要のない手段を設定してしまった場合は、それは意味がありません。目的の達成条件として過不足のない手段を設定することが理想です。
目的化できるような手段を設定する
この構造を破綻させないようにするには、目的化しても良い手段を設定する必要があります。目的化してはいけない手段が設定されていたとしたら、それは手段そのものや手段の達成条件の設定に誤りがあります。
「目的と手段を混同してはいけない」と表現される理由
人により何を根本の目的とするのかは異なります。複数人が協調して動く場合、達成するべき事柄は同じでも、ある人にとっては根本の目的であり、またある人にとっては手段である場合があり、この認識のズレのことを「目的と手段を混同してはいけない」という表現されているのではないかと考えました。
ではどう表現するのか
複数人で協調する場合は、重要なことは「目的と手段を混同してはいけない」のではなく、「根本の目的を一致させること」または「ある人にとっての根本の目的と、ある人にとっての手段を一致させること」がより正確な表現となると考えます。
unicorn のプロセスを終了させる
下記のコマンドを実行する。
kill -QUIT `cat tmp/pids/unicorn.pid`
- unicorn の親プロセスの ID は
tmp/pids/unicorn.pidに保存されている。
親プロセスのプロセスIDを調べる
ps alx コマンドで表示される PPID が親のプロセスIDを示す。
unicorn の起動コマンド
bundle exec unicorn_rails -c config/unicorn.rb -E development -D
-c: コンフィグファイルのパスを指定する。
-E: Rails の環境を指定する。この場合は development 環境となる。
-D: バックグラウンドで実行する。
指定した名前のDockerコンテナが存在すればdocker stopコマンドを実行する
sudo docker ps -a --filter "name=app" | awk 'BEGIN{i=0}{i++;}END{if(i>=2)system("sudo docker stop app")}'
--fileter "name=app"はdocker ps -aの結果の中からコンテナ名がappであるものだけを表示するオプション。sudo docker ps -a --filter "name=app"で出力された行数を awk でカウントし、2行以上であればappコンテナが存在するものとしてsudo docker stop appを実行する。
全てのDockerイメージを削除する
sudo docker images -q | xargs sudo docker rmi
