2014-08-11

Homebrew のパッケージを Brewfile で管理してみる

最近の Homebrew には、パッケージ管理ファイル Brewfile をデフォールトで使えるようになっている。

適当な場所に Brewfile を作成し、brow bundle コマンドを実行する。これで、Brewfile に書いてあるパッケージがインストールされる。書式に下記の通り:

$ cat Brewfile
# Packages

install git
$ brew bundle

上の例では git パッケージがインストールされる。

あとがき

Brewfile を使えば (Mac OS に) インストールするパッケージを git でバージョン管理することができるようになる。複数の Mac 環境を持っている場合に、パッケージを統一できるので便利。

追記

brew bundle を実行すると、こんな警告が出る。Brewfile はこれからも使えるのかな?

Warning: brew bundle is unsupported and will be replaced with another, incompatible version at some point.

2014-08-09

エアコンの除湿と冷房、効果と電気代の差について

Never まとめに良いまとめがあったので、自分メモ用にまとめとく。

結論を先に書くと、除湿だけなら「冷房の方が効果も高く、電気代も安くなる場合がある」。

目的

冷房と除湿では目的が違う:

冷房
部屋の「温度」を下げる
除湿
部屋の「湿度」を下げる

「冷房」の目的は温度を下げることだけど、副作用として除湿も行なってしまう。どれくらい除湿するかは考えられていない。何故なら、目的が部屋の温度を下げることだから。

「除湿」の目的は湿度を下げることだけど、「できるだけ温度を下げずに湿度を下げる」という制限がある。

二種類の除湿

除湿には二種類のタイプがある:

弱冷房除湿
冷房の機能を弱めたもの
再熱除湿
冷房機能で除湿した後、部屋が冷えないように温め直す

特に記述がなければ、普通の「除湿」は「弱冷房除湿」と思っていい。

電気代は 「弱冷房除湿 < 冷房 < 再熱除湿」という順になる。

比較表

温度低下湿度低下電気代金
冷房
再熱除湿
弱冷房除湿

あとがき

実家に帰ってエアコンの説明書を読んでみたけど、「弱冷房除湿」か「再熱除湿」かは分からなかった。最新のエアコンを調べてみると、「再熱除湿」がついていたり、ついていなかったり。比較的最近の機能なのかと思う。少くとも、うちがエアコンを買った数年前 (?) には、そんな機能はなかったんじゃないかな。

Never まとめにもあるよう:

電気代をおさえたいときは、弱冷房(じゃくれいぼう)除湿や、高めの温度に設定した冷房(れいぼう)がおすすめ

高温・多湿な夏に、除湿と冷房を同時に行ないたければ、(うちの機種だと) 冷房だけの方が電気代も効果も高そう。かなり勉強になった。

各種プロジェクト向け .gitignore ファイル

新しいフレームワーク、新しいツールを使ってプロジェクトを開始する時、当然そのプロジェクトは git で管理するとして、.gitignore をどうするかは頭痛のタネになる。

例えば、ぼくは XCode で iOS アプリを開発しようとしているけれども、どのファイルを Git で管理すれば良いのか分からない。どのファイルを無視して良いのか分からない。そこで役に立つのが GitHub が集積している .gitignore ファイル一群。

XCode ならば Objective-C.gitignore というファイルをコピーすればいい。

# Xcode
#
build/
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata
*.xccheckout
*.moved-aside
DerivedData
*.hmap
*.ipa
*.xcuserstate

# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control
#
# Pods/

内容充実な .gitignore ファイルが用意されている。

CocoaPods を使う場合は Pods ディレクトリーを .gitignore に含めることを勧めない、とのコメントもあり。ぼくは Pods ディレクトリーを ignore しちゃう派だけど、そこら辺は自己責任で決められたし。Pods ディレクトリーを含める・含めないについては下記記事を参照とのこと。

あとがき

ここには Objective-C の他にも、Android, Elisp, Rails, Scala, Swift, TeX と様々な言語・フレームワークへの gitignore ファイルが集まっている。gitignore ファイルをどうするか頭を悩ます時間があったら、サクッとここのファイルを使わせてもらおう。時間の節約にもなるし、勉強に繋がることもある。

bash 変数を使って cd を楽にする方法

深い階層へ軽動したい時、cd コマンドを打つのは面倒。たとえ bash のパス補完が効くとしても、手間はかかる。そこで、目的のパスを bash 変数に保存することでこの問題の対処をしている。例えば、このブログ記事の下書きが置いてあるディレクトリーへ移動するには、次のコマンドを使う:

$ cd $blog

.bashrc に書く設定は次の通り:

blog="$HOME/Documents/blog/"

ディレクトリー階層がどんなに深くても、この方法なら一発で辿り着けるので便利。

パスに空白が含まれる場合

時として、パスに空白が含まれる場合がある。自分でそういうパスを作ろうとは思わないけど、他人の git repository を clone したらパスに空白が空いていた、等々何ともしがたい状況はある。そういう時、同じ要領で変数を指定しても cd で失敗する。

$ grep somedir ~/.bashrc
somedir="$HOME/Documents/path with space"
$ cd $somedir
bash: cd: /Users/ataka/Documents/path: No such file or directory

path の中に含まれる空白が引数の区切りとして扱われている。「path with space」というディレクトリー名の最初の「path」しか cd に渡っていない。これを解決する方法は、多少武骨だけれども変数を "" で囲む。

$ cd "$somedir"

これで「path with space」へと移動できた。

あとがき

ディレクトリー移動はコマンドライン操作の基本。ここで楽できると、随分ストレスが減る。もし良ければ試してみて欲しい。