Evite if's longos

Nesse aqui dá para matar a condição logo na primeira linha, evitando a
indentação a seguir, que pode embananar a coisa, especialmente com um if longo.
Não precisa incluir o diretório log no controle de versão.

Polui muito na hora do diff.
Randomizei os minutos também.

Fica melhor criar dados mais aleatórios para ver o retorno dos testes. Do jeito
que estava, os minutos sempre ficavam em 0.
Refatorado o método working_time

O working time pelo que eu entendi é para retornar a quantidade de horas e
minutos, formatada de acordo com o clock_style, como uma String. Movi o cálculo
da diferença para fora do método, pois assim ele fica "testável" como um método
separado, que retorna nulo se por acaso o cálculo não pode ser efetuado (in ou
out vazios) ou uma Hash com os valores a serem formatados.
Agora sim o working_time pode ser testado.

Inclusive, a minha interpretação do clock_style estava errada, e o teste pegou.
;-)
Um pouco de DRY no teste e na factory do checking.
Alterado e testado o set_value

Pelo que eu entendi aqui (mas posso estar errado), você quis colocar uma
precedência entre os valores que poderiam servir como multiplicadores, sendo que
se o valor for passado para o método, assume ele, ou o hour_value. Mas quando
você coloca na condição

value.nil? || hour_value.present ? hour_value : <else>

e o valor é nulo mas o hour_value também é nulo, bum!, o treco explode.

Então eu deixei na condição de "curto-circuito": se foi enviado o valor, assume
ele, senão tenta o hour_value, senão, assume 0, o que vai multiplicar por 0 e
não mais por Nil.

Ali foi outro lugar que dá para notar como fica útil separar a lógica dos
métodos: utilizei o time_difference, que antes eram linhas de código dentro do
working_time.
Working time retorna nulo se algum dos horários está vazio.

Aqui é outro comportamento interessante: ao invés de retornar aquela String
válida, com "00:00", porém *que não indicava que tinha alguma coisa errada*, é
melhor retornar nulo.
Você não precisa especificar allow_(blank|null) como false se usa o presence.
Pode user o length direto na mesma linha.
Matando if's logo quando atende a condição.

Aquele esquema: se já atende, vaza, não abre o bicho.
Mais alguns if's e refatorado o código de escolha de layout.
Enviando um callable para o objeto de geolocalização.

Era isso que eu ia te falar um pouco depois que dei a dica de passar o form para
o objeto de geolocalização: melhor do que passar um objeto específico, é melhor
passar um callable, no caso aqui uma função anônima, que vai fazer o que você
precisar quando a geolocalização retornar. No caso dessa página específica, pode
ser preencher os campos e fazer o submit do form, mas pode ser utilizada para
trocentas situações diferentes dessa forma, só enviando a função anônima
necessária no construtor da Geolocation.
Merge pull request #6 from taq/master

Alterações feitas pelo Taq