静かな待降節ソング

この記事は KainokiKaede Advent Calendar 2014 20日目の記事です（大嘘）

世間一般では賑やかな季節となってまいりましたが、欧米ではこの季節は日本の年の瀬みたいな感じでしんみりと祝い、むしろ新年のほうを盛大に祝うようです。だから日本もそうしよう！ なんてことは言いませんが、せめてその雰囲気を伝えたいと思い、賑やかな曲だけでなくしんみりとした曲も多いのだよ、と主張したくてこの記事を書きました。アドベントカレンダーっぽい記事を書いてみたかったというのもあります。ではどうぞ。

Veni Veni Emmanuel

曲名は「来たれ、来たれ、エマヌエルよ」。エマヌエルはキリストの別名です。キリストには7つの別名があって（O Antiphons）、それらをひとつひとつ挙げていって「こうこうこういう人が生まれるから喜べ (Gaude) ！」という曲です。しっとりとした中に希望を感じさせる曲。

Carol of the Bells

この記事を書くきっかけになった曲です。楽しい季節の曲のはずなのにおどろおどろしいというか、なにか迫りくるものを感じさせる曲です。ホーム・アローンで流れていたので有名かも。

また、この曲を原曲とした クトゥルフネタの替え歌 も有名。

Puer Natus in Bethlehem

そのまんま「ベツレヘムで子供が生まれた」って曲ですね。詞は13世紀、曲は14世紀だそうです（英語版 Wikipedia）。

こんな感じの、永久に同じことを続けられそうな曲が好きです。

Coventry Carol

L の音がつながっていって心地いい曲。

L の音が心地良いといえばこんな小説がありましたね（ゲス顔）： "Lolita, light of my life, fire of my loins. My sin, my soul. Lo-lee-ta:”

Kings College Choir - 24 Dec. 2011

ミサ兼発表会みたいな感じなのかな。有名な曲が合唱＋パイプオルガンで歌われています。知ってる曲もいくつか出てくると思うので作業用にどうぞ。

最初に出てくるショタがかわいい（小並感）

ヴァチカンの動画

最後に、待降節ソングというわけでもないですが、2013年の降誕祭の晩の祈り＠ヴァチカンの映像です。こんなものを公式が提供してくれるなんていい時代になったなぁと思います。クリスチャンではないのでやはり作業用BGMに最適です（冒涜）。

結句

ということでみなさんも今年は大人しく家族と家で聖歌でも聴いて過ごしましょう。絶対だかんな！

Git 初心者が詰まったところをメモ

この記事は KainokiKaede Advent Calendar 19日目の記事です（大嘘）

最近は Mercurial から Git に乗り換えて開発をしているのですが、この乗り換えの際に気になった点をメモ。Git の哲学を学ぶという意味でも。まぁ半分ぐらい愚痴エントリです。

個人的な印象だけど、Git は Mercurial と比較して「人間はミスらない」ことを前提として作られている気がする（破壊的な動作が多すぎる）。

merge と rebase はどう違うの（merge だけでよくない？）

• merge: すべてのコミットがその時点のものとなる（動くようにコミットし続けていれば、動く）。
• rebase: rebase される枝のコミットはコミットされた時点のものではなくなる（他の箇所が変更されていたりすると、動かなくなる）。

rebase には全く利点がないように思える。公式の解説 を参考にすると、要は「コミットグラフが綺麗になる（それ得かな？ 複雑なほうが気持ちよくない？）」「fast-forward でコミットされた側を移動させることができるようになるので、受け取った側が楽（でもこれも merge すれば同じじゃねーの？）」「公開したコミットをリベースしてはいけない」に尽きるっぽい。

「リベースはあくまでもプッシュする前のコミットをきれいにするための方法であるととらえ、リベースするのはまだ公開していないコミットのみに限定するようにしている限りはすべてがうまく進みます。」だそうだ。

ここ を読むと、merge したときのコミットっていうのは基本的には「機械的に生成された、だれもテストしてないコミット」なので、動く保証はない。だから rebase をするのだ、と読めるが、rebase したときのコミットも基本的には機械生成されたもんだと思う。

ここ の図はわりとわかりやすく、要は「直接 merge するのではなく、rebase してから merge すれば、rebase した時点でもう1回テストできる」ということ。 でもそれも、一回 master を topic にマージした後に、そこでテストをして、OKなら topic を master にマージ、みたいにしたほうが（たしかにグラフは汚くなるかもしれないけど）過去の動いていたはずのコードを破棄する必要がなくて安心なのでは。

ここ によれば「書いた通り rebase じゃなくて merge で済む場面がほとんどです。」らしいので rebase は忘れよう。

なんでブランチを消すとその枝が全部消えるの（ログとしてとっておきたいのに）

ここ から読み取れることは、「ログとして残したいならブランチをつけておけ」ということである。でもブランチリストに表示されるのがイライラすんだよなぁ。Mercurial ならブランチがどこからも参照されていなくても残り続けるから安心なのだ。

タグをつければいいじゃんという意見もあるが、それは今度はタグリストに表示されるじゃん、無意味でしょ。

でも Mercurial を使うわけにはいかないので（デファクトスタンダードを使わなければならない）、ゴミを電気に変えなければならない（Mr. Fusion）。

とりあえず、ブランチを消しても30日間は reflog とかいうログに残るらしい（30日間ってなんだよ、永遠に残せよ）。だから消してすぐならブランチをつけ直すことで対処できる。

結局「ブランチリストには出てきてほしくないけど、過去の変更のログを残すためにそこにいてほしい」みたいな使い方をすることはできないんだね（やはりゴミかな？）。

ここ で紹介されている方法は一応2つ？ refs/archive/branchname みたいなところに格納するか、 git tag archive/branchname みたいにタグ付けするか。で、後者のほうが正解っぽい、と。 SourceTree はブランチ名をディレクトリっぽく書けばそれを認識して折りたたんでくれるみたいだから、それでもいいのかなぁ。

ここ によれば「Mercurial の哲学は、“履歴は永久的で神聖である”ということです。」らしくて完全に同意である。

pull いらなくない？（fetch + merge でよくない？）

pull は基本的にはコンフリクトが起こらないと確信できる状態でしか使わない。

こんな記事 とか こんな記事 とかがあって、要は送りたいときは push, 貰いたいときは fetch, 繋げたいときは merge と覚えておけば予期せぬ動作をすることはあまりないようだ。

amend, cherry-pick, squash, rebase -i とかコミットログを混乱させるだけでは

そうだよ（便乗） とくに rebase -i とか問題を起こさずに実行する自信がまったくない。

• amend: 1つ前のメッセージを変える。
• revert: あるコミットを打ち消すコミットを作る。（間違えて revert した場合は reset する。）
• reset: あるコミットまで戻る。（間違えて reset した場合は reflog を参照したり ORIG_HEAD を参照したりして対処する。）

このあたりはもしかしたら使うことがあるかもしれないけど、基本的に全ての commit は final であるという意識を持つべきだと思う。

origin/HEAD がズレる（更新したい）

もともと origin/HEAD は master に向いていた→Redmine を使うとかの関係で develop に symbolic-ref を張り替えた→でもいくらフェッチしても僕のコピーの origin/HEAD は master に向いたまま。

ここ によれば、

origin/HEAD is set automatically when you clone a repository, and that's about it. Bizarrely, that it's not set by commands like git remote update - I believe the only way it will change is if you manually change it.

だそうなので、つまりは「リモートの変更を同期する」みたいなオプションは与えられてないってことだ。たいがいクソだと思うが、ふつうに local で origin/HEAD に symbolic-ref を張ってやればいいのかな。

Mercurial が恋しい

むかし Mercurial を使っていたときは特に問題なく直感的に使えていたのに Git を使い始めてからこれだけ意味不明感が出てきたの、あきらかに Git の不親切を感じるしこれがデファクトスタンダードであることに違和感を感じるしやはり世界同時革命しかない。

Google Calendar で複数のカレンダーにまたがる予定をウィジェットとして公開する

この記事は KainokiKaede Advent Calendar 2014 18日目の記事です（大嘘）

東大の早野先生は ご自分のサイトで予定を公開 なさっている。ウェブベースのカレンダーを使うことの利点のひとつに、このような他者との予定の共有があるので、自分のカレンダーも公開してみようと思い立った。

しかし自分はカレンダーを用途別に分けて使っている。これら用途別のカレンダーを1つのウィジェットにまとめて表示させたい。ひとつのカレンダーをウィジェットとして表示するのは簡単（Google Calendar から直接できる）なのだが、複数を1つのウィジェットの中に同時に表示させるには Google が提供している Google Embeddable Calendar Helper を利用する必要がある。これを使えば、どのカレンダーをどの色で表示してウィジェット化する、などの設定を簡単に弄ることができる。

ちなみにどのように予定が表示されるか（ただ「予定あり」と表示されるのか、予定の内容も表示されるのか、予定すら表示されないのか）は各々のカレンダーの設定に依存する。その設定は上記の Helper からでは不可能で、Google Calendar の設定を弄る必要がある（方法は このあたり などを参照）。

カレンダーの中の個々の項目をプライベートに設定するには この記事 を参照。

非公開URLを使うことは推奨されない、表示されたリンクをクリックしてもいけない、という 記事 も見ておくとカレンダーをウェブで公開するためのリテラシーが高まる。

Mac で Adobe Reader を用いて右綴じの本を見開きで表示する

この記事は KainokiKaede Advent Calendar 2014 17日目の記事です（大嘘）

Mac で PDF を閲覧するときは標準の Preview.app を用いると便利である。しかし Preview.app には右綴じの本を表示する機能がついていない。日本語以外にも右綴じを必要とする言語はあると思うのだが、Apple のデバイスはそのような国では普及していないのだろうか？

とにもかくにも Preview.app では不可能なので、別のソフトを用いることになる。ComicViewer for Mac というソフトがあるが、サポートフォーラム を見るかぎり開発が停止して久しい。

さすがに PDF の大元である Adobe 御大ならばいかような PDF の表示も可能であろうと推察し、Adobe Reader をダウンロード した。最初は Retina ディスプレイに対応していないバージョンがインストールされて閉口したが、バージョンを 11.0.10 に上げれば高解像度対応の問題は解決した。

さてそこで見開きの問題である。そのままでは Preview.app と同じ方向（左綴じ）で表示される。PDF ファイルの設定を変更すれば修正されるようだが（そしてそれが正しい方法に思えるが）、残念ながら Acrobat を持っていないと簡単には変更不可能なようだ。ということで Adobe Reader の設定を変更して右綴じ専用ビューワとすることで対処する。

方法としては、環境設定で以下を設定する。

• フルスクリーンモード > 1ページ全体をフルスクリーン表示 のチェックを外す。
• ページ表示 > デフォルトレイアウトとズーム を 見開きページ 全体表示 にする。
• 言語 > デフォルトの読み上げ方向 を 右から左へ にする。

以上で、フルスクリーンモードで右綴じの本をちゃんと表示できる。ページが1ページズレるという現象に対しては、

• メニューバーの 表示 > ページ表示 > 見開きページ表示で表紙を表示 にチェック

することで対処可能である。ちなみにフルスクリーンモードへの移行のショートカットキーは Cmd+L である。

ただしこれでも次のページに進むためには右矢印を押す必要があり直感的ではない。しかしまぁこのくらいは許容可能であるし、右矢印のほうがキーボードの外側にあるため押しやすく便利でもある。

夜にメールを書いて朝に送る（Gmail を特定時刻に自動で送信する）

この記事は KainokiKaede Advent Calendar 2014 16日目の記事です（大嘘）

生活リズムが崩壊しているので常識的な時刻にメールを送ることができない。できれば夜に書いて朝に送り、睡眠時間を偽装したい。

Thunderbird などのメーラーを使っているならアドオンでなんとかすればいいが、残念ながら完全に Gmail のウェブアプリに移行してしまっているためアドオンを付け加えることが不可能である。

Boomerang みたいな Gmail 自動送信アプリを使おうとも思ったが有料だし、なんか外部サービスに Gmail を預けるのがちょっと抵抗があるのでやめておきたい。

そこで Google Spreadsheets のスケジューリング機能を使って Gmail を送信しようということになる。幸い既にそのための コード を書いてくれている人がいて、それを簡単に利用できるようにする スプレッドシートを配布 してくれている人もいる。解説動画 もある（親切だ）。

手順としては：

1. Gmail でメッセージを作成して、送信せずに下書きに保存する。送信予約をした後に編集をすると予約がキャンセルされてしまうので注意。ちゃんと完成させてから以下の手順に移る。
2. このリンク をクリックして上記のコードが既に導入されているスプレッドシートを自分の Google Drive にコピーする。
3. そのままだとタイムゾーンがインドになっているので（たぶん元の製作者がインド人）、File > Spreadsheet Settings からタイムゾーンを自分の場所のものに変更する。
4. メニューバーの Gmail Scheduler > Step 1: Authorize を選択して Spreadsheet から Gmail を操作できるようにする。なにやってるのかわからないから不安だという人は、 Tools > Script Editor からこのシートで組まれているコードを読むことができる。300行弱の JavaScript コードなので読んでみると面白いかも。外部にメールなどを送るようなコードは書かれていないように見える（責任は持てないが……）。
5. Gmail Scheduler > Step 2: Fetch Messages を押すと、下書きに入っているメールが Spreadsheet にリストアップされる。
6. 時刻を設定する。適当に入力しても Google 先生がなんとかしてくれるが、私は 2014-12-16 08:00 のように（手で）入力している。
7. Gmail Scheduler > Step 3: Schedule Messages を押すと、Status のところに Scheduled と表示される。この状態になったら勝手に送信されるので Spreadsheet を閉じてもかまわない。
8. 送信予約をキャンセルしたい場合は Gmail Scheduler > Cancel Pending Jobs を押せばキャンセルされ、Status に Not Scheduled と表示される。
9. 必要なくなった行は行ごと削除してしまってかまわない（たぶん）。

便利なのは、Gmail 上で編集したものをそのままスケジューリングできること。画像とか添付ファイルとかを設定しておけば、それをそのまま送ることができる（コードを読むと実はそのまま送っているわけではなくてまるまるコピーして送ったのちに元のメールを削除するということをしているのだが（それゆえ元のメールがゴミ箱に残るのだが）、まぁその部分の処理はわりと頑張って書かれているようなのでおおむね問題なかろう）。

でも正直 Gmail の標準機能として実装してほしいところである。はてなブログにすら「日時を指定して投稿」機能があるのに Gmail にないってのはどういう了見なのか。

Vim で Evernote を編集するために vim-geeknote を導入する

この記事は KainokiKaede Advent Calendar 2014 15日目の記事です（大嘘）

Evernote を Vim で編集したい。Geeknote と vim-geeknote を導入してこれを実現する。

環境： OS X Yosemite 10.10.1, MacVim-KaoriYa, NeoBundle

Geeknote の導入

コマンドラインから Evernote を編集するプログラムである Geeknote をまずは導入します。

公式 を参考に。

$ git clone git://github.com/VitaliyRodnenko/geeknote.git
$ cd geeknote
$ sudo /usr/bin/python setup.py install  # Install to the system python (/usr/bin/python), not to the Homebrewed python (python).
$ geeknote login

vim-geeknote の導入

公式

Geeknote から Evernote にログインした状態でしか使えないので注意。

NeoBundle ’neilagabriel/vim-geeknote'

vim-geeknote を使う

詳しい使い方は上記の公式ページを参照。

:Geeknote でノートのリストを表示。Enter でノートの編集を開始。ふつうに :w すれば保存可能（ほぼ同時に Sync される）。:GeeknoteSync で Evernote 側の変更をフェッチすることもできる。

ノートの1行目はタイトルなので削除してはいけない（リネームは可能）。タイトルのリネームはリストを書き換えて保存することでも可能（まじすか）。これと同じ発想でノートの移動も可能（ノートの行を他のノートの中に移動させる）。

:GeeknoteCreateNote <name> で新しいノートを（現在選択されているノートブックの中に）作成。

ちょっと見栄えを良くするために vimrc に次を記述。リスト表示の横幅の最大を制限するのと、行数表示を消す。

let g:GeeknoteMaxExplorerWidth=60
autocmd FileType geeknote setlocal nonumber

Mac OS X Mavericks に Ureka1.4.1 を導入

この記事は KainokiKaede Advent Calendar 2014 14日目の記事です（大嘘）

なぜ Yosemite ではなく Mavericks の記事かというと、書き溜めだからです。ごめんなさいね。

Astropy, IRAF, PyRAF をそれぞれ単独で導入することの困難さを解決したい

Python を用いて天文データの解析を行いたいが、Astropy が pip でインストールできない。IRAF を入れたはずだがうまく動かない。PyRAF も動かない。どうしようかと悩んでいたら Ureka なるパッケージを見つけた。上記のものがいっぺんに導入される。何がインストールされるかは Components を参考に。入れるのが難しそうなモジュールがいろいろ入っていて、これ天文以外にも使えるんじゃないですかねといった感じだ。アンインストール も簡単である。

Ureka のインストール

導入方法は 公式 を参考に。

sh install_ureka_1.4.1 をしたディレクトリに Ureka ディレクトリができ、その下にバイナリが展開される。なのでたとえば Downloads ディレクトリでこのコマンドを打つべきではない。適当なディレクトリを見つけてそこに展開してやるべきだろう。ちなみに Downloads に展開してしまっても、Ureka ディレクトリごとどこかに移して、そのディレクトリで bin/ur_normalize を実行すれば移行が完了する。しかしその際はリファレンスの書き換えなどが行われて時間を食うので、どうせやるなら最初から目的のディレクトリで sh install_ureka_1.4.1 を実行しておくべきだ。

インストールには30分ぐらいかかるけど辛抱。Updating shebang lines… で長時間止まったように見えるけど辛抱。

$ sh install_ureka_1.4.1
About to install Ureka 1.4.1 in
/Users/hogehoge/Ureka
Continue? Enter yes or no [yes]: yes
...
======================================================================
Ureka is installed.  Log in a new terminal window and type the command
    ur_setup
or
    ur_setup common primary
to select your Ureka environment.  'ur_setup -h' will show some help.

Installation complete

For more information about how to use Ureka, check out the online
documentation: http://ssb.stsci.edu/ureka/1.4.1/docs/index.html

使い方は ドキュメント を読む。ur_setup で Ureka 由来のコマンドが使えるようになる。ur_forget でそれらを deactivate する。

ds9 とかを使えるようにするために XQuarts も入れておく。

PyRAF を使用してみる

ついでに、せっかくインストールしたのだから IRAF の Python によるラッパである PyRAF を使ってみよう。PyRAF は実行ディレクトリにいろいろとファイルを作るので、あらかじめ実行用のディレクトリを作っておいたほうがよい。

$ mkdir pyraf
$ cd pyraf

とりあえず mkiraf を実行して login.cl を作ってもらおう。ターミナルタイプをデフォルトの xterm-256color のままにするとエラーが出る。公式 によれば xgterm でないと動かないものもあるようなのでそれにしよう。

$ mkiraf
Enter terminal type [default xterm-256color]: xgterm

そして pyraf を起動する

$ pyraf

コマンドリストは ? で表示できる。プロンプトから抜けるときは .exit と打つ。

これ以降の使い方は人によって異なると思うので私はここで筆を置く。