Sunao Tanabe sunaot

git pull の動作

pull は引数なしが推奨です。 pull は誤った (意図しない) リモートリポジトリやブランチを指定したときも動いて、そのリポジトリのリモートブランチから展開されているワークツリーへのマージとして働きます。一方、引数省略するとリモート追跡ブランチから自動的に pull 対象を決定します。こちらのほうが一般的に事故は少ないです。

git push の動作

こちらは git のバージョンしだいで推奨が変わって、次のようにわかれます。

ユニットテストでテストを書くか書かないかの判断の話

お題

メソッドの出力の結果が、true か false のどちらでも返ってくる可能性がある場合、assert 文を書く時は true の場合だけで良いのだろうか

テストとは

まず、基本の考えとしてなぜテストをするのか？というのがあります。

問い

permits ってなに？

class FoodsController < ApplicationController
  permits :name, :amonut
  
  ...
end

Subversion を Git へ移行したい (そして共有方法として GitHub を使いたい) 場合に考える観点をあげてみます。

人

チームに Git にくわしい人がいるか？　いない場合、聞く先があるか？
- チャットに git ルームをつくるなど
習熟度に不安があったら、やってはいけないことリストとこうすべきリストの整備が初期の混乱を防ぎます
- force push 禁止
ブランチはリモート追跡ブランチからきる

どこの層まで Thor であることを意識させるかというのはポイントになりそうな気がします。 database は Thor 以外からはけして呼ばれないでしょうか？たとえば、Web インターフェイスをかぶせた場合。bot を呼出し元として使い始めた場合。実際にそれらを作り始めて不都合が出てから変えてもいいのですが、今の時点で

+--------------+ +-----------+
|  dispatcher  | |   view    |
+--------------+ +-----------+
+----------------------------+

自動化をしていくときに大切なこと

心得

作業を自動化しようと思う者であれば、定型作業はすべて悪だと思い、人がやる以上は必ずその作業に判断とそれによる付加価値が発生することを求める。付加価値があるときも、時間と費やす集中力に見合う付加価値があるのか、他のことに時間を使えばもっと価値があるんじゃないかと徹底的にこだわる。

自動化できない作業をせざるをえないときに同じ心持ちだとただただ消耗するので、そこはそれと切り替えよう。思考を停止し自分は機械だと思いこなそう。現実は厳しく、"Done is better than perfect." だ。

大切なこと

リハーサルはなぜ重要か

(実施告知の文章から抜粋)

ええと、みなさんAWS移行の準備も大詰めでリハですね。リハーサルってなぜやるかわかってる人もわかっていない人もいると思うので書いておきます。結論を先に書くと、本番当日もそのまま手順を踏襲するとそれで移行が終わる詳細な手順が書かれた移行手順書を書いてリハをしてください。リハの中で手順どおりには行かなかったところはその時にすべて手順書に反映して、本番のときは手順どおりでやれるようにしてください。

本番一発勝負というのは難しいもので、人間どんなに考えていても失敗します。でも失敗を糧に二度目をすると一度目にやった失敗は回避できます (できるようにします)。システム開発というのは一般的に大体予測不能なところで失敗するものなので、一度本番同様に動かしてみるというのが非常に重要になってます (アジャイルが繰り返し開発するのも動くソフトウェアを信じるからですね)。

性質として事実上そういうものなのですが、私達の気持ちとしては当然失敗はしたくありません。そこで、失敗をするはずの一度目としてリハーサルという疑似本番をやるわけです。そうすることで、失敗の予行演習ができます。本番に向けて失敗の予防ができます。ここを人手でやると再現性が落ちるのでベストは自動化され、何度やっても繰り返し同じことが実現できる状態です。でも、それはしやすいものとむずかしいものもあるので人間がそのとおりに実行をしたら同じ結果になるという手順書というのが大事になってきます。

レビューコメントから

「問合せている」のは手段で、目的として得たいものは別ですよね。名前は実装や手段ではなく、意味や意図、結果、目的に対して付けます。
実装じゃなくて意味に付けようって話はコードコンプリートに書いていて、たぶんリーダブルコードにも書いていて、超基本的なんですが最重要なので、すべての名前で今自分はなにに対して名前を付けたのかを自問自答する癖をつけるのをおすすめです。

Clean Code より。

意図を表現した名前をつける (Use intention revealing names)

	module EnumHashSelector
	DEFAULT_RESOLVER = ->(model_class, method_name, key) {
	"activerecord.enums.#{model_class.name.underscore}.#{method_name.to_s}.#{key}"
	}

	def self.i18n_path_resolver=(resolver = DEFAULT_RESOLVER)
	resolver.call(model_class, method_name, key)
	end

	def enum_selector(model_class, method_name)

	require 'minitest/autorun'

	class ModuleTest < Minitest::Test
	def test_module_eval
	debugger = Object.new
	debugger.class.module_eval do
	define_method(:debug) {\|s\| %(debug: #{s}) }
	end
	assert_equal 'debug: Hello', debugger.debug("Hello")
	end