引数にオブジェクトを渡すか、個別に渡すか

メソッドを作成するときに、引数の数が増えてくるとどう対応したものかよく迷う。
と思ったらコードコンプリートに答えが書いてあった。

「第二部 7.5 ルーチンの引数の使用」あたりでの僕の理解。

  • 2つの意見がある

    • 個別に渡して結びつきを最小限に抑える
    • オブジェクトを渡して柔軟性を持たせ、インターフェイスを安定させる
  • どちらも短絡的

  • ルーチンの抽象化概念がオブジェクトを使って何かをすることであればオブジェクトを渡すべき

  • たまたま同じオブジェクトが提供するということであれば、個別に渡すべき

つまり引数の数がたとえ少なくても、その抽象化概念がオブジェクトに対するものなら、引数はオブジェクトであるべきってことなのね。
うん、しっくりくる(実践は難しそうだけど)。

短絡的な2つでいつも悩んでた。。

CircleCIでdot(graphviz)が動かなくなった

概要

qiita.com

↑な感じでDB定義の管理にSchemaSpyを利用しているんだが、リレーションの描画にSchemaSpyは Graphviz を使っている。 しかし最新のビルドでリレーションの描画がされていなかった。 その調査と対応のまとめ。

現象

SchemaSpyで描画されなかったメッセージ。

SchemaSpy was unable to generate a diagram of table relationships. 
SchemaSpy requires Graphviz version 2.2.1 or versions greater than 2.4 from www.graphviz.org.

SchemaSpyの実行ログ。

Failed to query Graphviz version information
  with: dot -V
  java.io.IOException: Cannot run program "dot": error=2, No such file or directory

原因と対応

CircleCIのコンテナイメージを変更したのが原因。
Graphviz は Ubuntu14 で動かない。

[Project Setting] → [Build Environment]→ [OS to use for builds]

Ubuntu 14.04 (Trusty)」を「Ubuntu 12.04 (Precise)」に変更することで解決する。

調査の記録

Rebuild with ssh してコンテナにSSHしてみた。

ubuntu@box32:~$ dot -V
The program 'dot' is currently not installed. You can install it by typing:
sudo apt-get install graphviz

無いと言われる。。描画されていたときのコンテナもsshしてみる。

ubuntu@box1032:~$ dot -V
dot - graphviz version 2.26.3 (20100126.1600)

もしかして無くなってしまった?と思い公式を確認。

Ubuntu 12.04 (Precise) - CircleCI

あるって書いてある。。

こんな記事を見つけた。

mao-instantlife.hatenablog.com

サンプルプロジェクトで自分でビルドしてインストールするようにしてみた。 →うまく行ったヽ(=´▽`=)ノ

dependencies:
  cache_directories:
    - graphviz-2.38.0
  pre:
    - wget -O graphviz.tar.gz --quiet http://www.graphviz.org/pub/graphviz/ARCHIVE/graphviz-2.38.0.tar.gz
    - tar -zxf graphviz.tar.gz
    - graphviz-2.38.0/configure --silent
    - make --silent --ignore-errors && make --silent --ignore-errors install > /dev/null
    - echo 'which dot && version:'
    - which dot
    - dot -V

自分でビルドするのはイマイチなので、バイナリをインストールするように修正。

dependencies:
  pre:
    - wget -O ../graphviz-dev_2.38.0-1~precise_all.deb http://www.graphviz.org/pub/graphviz/stable/ubuntu/ub12.04/i386/graphviz-dev_2.38.0-1~precise_all.deb
    - sudo dpkg -i ../graphviz-dev_2.38.0-1~precise_all.deb
    - dot -V

wget毎回するのも嫌なので、プロジェクト内部で持つように修正。

pre:
    - sudo dpkg -i ./.circleci/graphviz-dev_2.38.0-1-precise_all.deb
    - dot -V

サンプルプロジェクトで動作検証できたので、本ちゃんのプロジェクトに適用!

ところが

$ dot -V
bash: line 1: dot: command not found

dot -V returned exit code 127

Action failed: dot -V

CIのログをサンプルプロジェクトと細かく比較してみる →Start containerに差分

CIRCLE_BUILD_IMAGE=ubuntu-12.04
CIRCLE_BUILD_IMAGE=ubuntu-14.04

どうも意図せずコンテナイメージを変更していたらしい。。

[Project Setting] → [Build Environment]→ [OS to use for builds]

Ubuntu 14.04 (Trusty)」を「Ubuntu 12.04 (Precise)」に変更。

そもそも Ubuntu14 で動かないのであった。。

久々のrubyをバージョンアップ

概要

久々にRuby触ろうとしたらバージョンが古かったので更新した。

現状確認

Rubyは入ってる。

$ ruby -v
ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin15]

rbenvも入ってた。

$ rbenv --version
rbenv 1.0.0

欲しいバージョン(2.3.1)がいない。

rbenv install --list

rbenvの更新

$ rm -rf ~/.rbenv/plugins/ruby-build
$ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

欲しいバージョン(2.3.1)が増えた。

rbenv install --list

rubyの更新

$ rbenv install 2.3.1
$ rbenv global 2.3.1
$ rbenv rehash

rubyの更新

でけた

$ ruby -v
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin15]

削除したリモートブランチをローカルに反映する

概要

Pull Request マージされて、featureブランチ削除したのに、git branch -a すると出てくる。

手順

pull or fetch のときに --prune を使う。

o$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/hoge
  remotes/origin/fuga
  remotes/origin/piyo
$ git fetch --prune
From github.com:xxxx
 x [deleted]         (none)     -> origin/hoge
 x [deleted]         (none)     -> origin/fuga
 x [deleted]         (none)     -> origin/piyo
git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

スッキリしたヽ(=´▽`=)ノ

参考

UnitTestでのprivateメソッドとの向き合い方

privateメソッドのUnitTestについて、下記のような扱いがあると思う。

  • スコープを(例えばprotectedに)拡張する
  • 直接間接を問わず、リフレクションなどを活用してテストする

これらに対して、ずっと何か違和感を覚えていた。
実践JUnitでちょっと触れられている箇所があって、自分なりの読み解きで何となく向き合い方が腹落ちしたので書いておく。

  • UnitTestはメソッドのテストではなく、そのふるまいのテストにより重きが置かれるべき
  • privateメソッドは実装の内部詳細であり、その変更はふるまいに影響をあたえるべきではない

上記の前提を考えると、基本的にはpublicスコープに対してのテストで十分になりえるはず。

そのクラスのふるまいであるなら少なくともパッケージ以上にスコープが(テストのためではなく)拡張されることに違和感はない。
そうでないならば別のクラスに切り出すようなふるまいなのかもしれない。

結局のところ、privateメソッドの詳細に踏み込んだテストが必要になった時は、設計に何か問題がある可能性が高いということなのだと思う。

実践 JUnit ―達人プログラマーのユニットテスト技法

実践 JUnit ―達人プログラマーのユニットテスト技法

追記

@t_wada さんにTwitterで参考記事を教えていただきました!

qa.atmarkit.co.jp

追記その2

@backpaper0 さんのブログ

backpaper0.github.io

AWS CLIの導入

概要

aws cliMacで使えるようになるまで。

手順

pythonのインストール

$ python --version

はいってた

aws cli のインストール

$ curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
$ sudo python get-pip.py
$ sudo pip install awscli --upgrade --ignore-installed six

インストールの確認

$ aws --version

認証の設定

aws configure set aws_access_key_id {IAMユーザのアクセスキーID}
aws configure set aws_secret_access_key {IAMユーザのアクセスキー}
  • ~/.aws/credentials に設定される

おまけ

Bundled Installer を使った手順

最初こっちでやってみたけどpipでやるほうが一般的みたい。

$ curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
$ unzip awscli-bundle.zip
$ sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws

Installing the AWS Command Line Interface - AWS Command Line Interface

アンイストール手順

$ sudo rm -rf /usr/local/aws
$ sudo rm /usr/local/bin/aws

Uninstalling the AWS CLI - AWS Command Line Interface

Pythonの導入

virtualenvで環境作ってpipが一般的らしい

Virtual Environments — The Hitchhiker's Guide to Python Pythonの仮想環境を構築できるvirtualenvを使ってみる - Qiita

メリットとしては下記。

  • 複数バージョンの利用
  • ライブラリ環境の独立性
  • 環境丸ごと他にコピーしたり入れ替えられたりする

参考

OS X EI Caption(10.11.1)でAWS CLIのインストールエラー - Qiita

GitHubでtagをmasterにする

概要

GitHub上のOSSをフォークして開発したい。
でも、フォーク元のmasterではなくtagから派生させたい。
ので自分のリポジトリ(フォーク先)ではtagをmasterにする手順。

手順

リポジトリをForkする

GitHubから普通にForkするだけ

tagを開発ブランチとしてpushする

cloneした後、tagを確認する

git tag -l

tagからブランチを作成する

git checkout -b ${ブランチ名} refs/tags/${タグ名}

作成したブランチをpushしておく

masterブランチを削除する

GitHubではdefaultブランチがmasterになっている。
そしてdefaultブランチは削除できないのでGitHubの画面から変更する。
変更先はtagから作成したブランチ。

[settings]→[branches]→[Default branch]

masterを削除する
※削除せずにリネームでも良い

git push origin :master
tagから作ったブランチをmasterにする

ローカルのブランチ名変更

git branch -m hoge master

リモートに反映。

git push origin master

GitHubでdefaultブランチをmasterに変更する。
実質的には別名同ブランチが存在する状態になるので、不要なブランチ等は必要に応じて削除する。
(ローカルもリモートも)

参考