Markdown で書いた文書を LaTeX でリアルタイムでタイプセット(Pandoc と latexmk を利用)

この記事は KainokiKaede Advent Calendar 2014 23日目の記事です(大嘘)

Markdown で原稿を書いて、リアルタイムで TeX ファイルに変換・タイプセット ということをやりたかった。

流れ

main.texhoge.md とを作る。 main.tex の中で hoge.tex をインクルードしておく。 hoge.md から Pandoc で hoge.tex を作る。すると latexmk が更新に反応して pdf を作ってくれる。みたいな流れを考えた。

なぜ Pandoc だけで pdf 作成までやらないかというと、テンプレートを書くのがめんどいというのが一つ。章ごとにわけてタイプセットしたいというのが一つ(md ファイルを分割する方法があるのかもしれないけれども調べていない)。

ファイル構造は次のような感じになる。

main.tex (内部で hoge.tex を input)
hoge.md (編集対象)
hoge.tex (自動的に生成される・編集しない)

コード

とりあえず超てけとーだけど、ファイルの更新をチェックして勝手に Pandoc を回すコードを組んだ。select というモジュールを使った。

import select
import argparse
import os

def watchfile(filename):
    outfilename = filename.split('.')[0]+'.tex'
    f = open(filename)
    # when monitoring a directory: f = os.open("foo", os.O_RDONLY)
    kq = select.kqueue()
    ke = select.kevent(f, filter=select.KQ_FILTER_VNODE,
        flags=select.KQ_EV_ADD | select.KQ_EV_ENABLE | select.KQ_EV_CLEAR,
        fflags=select.KQ_NOTE_DELETE | select.KQ_NOTE_WRITE)
    events = kq.control([ke], 0, None)
    while True:
        r_events = kq.control([ke], 1, None)
        for event in r_events:
            print event
            if event.fflags & select.KQ_NOTE_DELETE:
                print "file was deleted!"
            if event.fflags & select.KQ_NOTE_WRITE:
                os.system('pandoc -i {0} -o {1}'.format(filename, outfilename))
                print "file was updated!"
    f.close()


if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument('filename')
    args = parser.parse_args()

    watchfile(args.filename)
$ python automd2tex.py hoge.md

で、自動的に更新があったら Pandoc を動かして tex にするようにした。 つまり1窓でこれを、もう1窓で latexmk を動かせば md を更新すると pdf が自動生成される。 bashrc のエイリアスを使って、 md2tex hoge.md で同じ効果が得られるようにした。

でもなんつうか、これ auto じゃなくてもよくね。どうせ md とか Vim でしか書かないんだから、quickrun 的な発想で

autocmd FileType markdown nnoremap gpa :<C-u>! pandoc -i "%:p” -o "%:p:r”.tex<CR>

こんなんでできないの?(できた) 一応これで md で tex を書けるようになったけどなんかめんどいですね。

(MacBook Air + Traktor) + (iPad + TouchOSC) でモバイルワイヤレス DJ 行為

この記事は KainokiKaede Advent Calendar 2014 22日目の記事です(大嘘)

Native Instruments の Traktor はセールがあると3000円ぐらいまで価格が落ちる。そんなときにたまたまお金に余裕があったので衝動的に買ってしまった、そういう人は多いと思う。しかし MacBook Air は持っているが DJ 用のコントローラーは無いし、買うと高いので、手持ちの iPad でなんとかコントロールしたいという欲求が生まれる。

iPad には自由に MIDI コントローラーを作ることができる TouchOSC というアプリが存在し、その TouchOSC には Traktor 用のテンプレートとして Jog-On が付属している。これと MBA とを無線で繋げることができればモバイルワイヤレス DJ 行為が可能である。

準備

ソフトのインストールなど

まずは上記のアプリなどを全て入手する。可能であれば MBA のイヤホン出力以外にもう1つステレオ出力のあるオーディオインターフェースがあるとよいが、ないなら Traktor DJ Cable などの、ステレオ出力をモノラル2つに分配するケーブルを使えばよい。

MBA と TouchOSC を繋ぐには TouchOSC のページから TouchOSC Bridge を入手・MBA にインストールしておく必要があるので、それもやっておく。

もちもの

DJ をはじめる直前の準備

  1. MBA の システム環境設定 → 共有 → インターネット共有 がオンになっていることを確認する。
    • 共有する接続経路は Wi-Fi, 相手のコンピュータが使用するポートは Bluetooth PAN にする。
  2. iPad の 設定 から Bluetooth をオン → MBA に繋ぐ。
  3. MBA で TouchOSC Bridge を起動。
  4. iPad で ToushOSC を起動。MIDI Bridge からホストを選ぶ(初期状態では前回繋いだときのホストが選択されているが、たとえホストが同じでもこのまま繋げようとしても繋がらないことがあるので、必ず下のホスト一覧から新しく選択しなおす)。
  5. MBATraktor を起動。適切なルーティングが選択されているかどうか確認。
    • オーディオインターフェース2つでやる場合、一度 Mac 側で Audio MIDI 設定 アプリを開いてインターフェースが正しく接続されているかを確認。その後、Traktor の設定から適切な出力に適切な入力が割り当てられているか確認。
    • オーディオインターフェース1つでやる場合( などの分配ケーブルを利用)、ヘッドホン側とスピーカー側とを取り間違えていないか確認。
      • Traktor DJ Cable を MBA 標準の音声出力で使う場合は、Traktor 側の Output Monitor の L を 2, Output Master の L を 1 に設定する。

あとは曲を流すだけである。

ハマりポイント

  1. Jog-On のテンプレート使用時に FX まわりがうまく動かない!
    • このテンプレートにおいて、左右の FX はそれぞれ FX 3, 4 にアサインされています。ですのでこれらを使えるように設定の Effects で 4 FX Units を選択しておく必要があります。
  2. Mash, Slice, Stop が動かない!
    • これらは、Deck A は FX 1, Deck B は FX 2 の Delay, Beat Slicer, Reverse Gain にそれぞれ割り当てられています(このために通常使用する FX が 3, 4 に割り当てられているのでしょう)。よってかならず常に Deck A は FX 1 へ、Deck B は FX 2 へルーティングしておくようにしましょう。ボタンを押して、これらのエフェクトが動作することを確認してください。

国際キャッシュカードを作ろう

この記事は KainokiKaede Advent Calendar 2014 21日目の記事です(大嘘)

トラベラーズチェックの国内販売が終了した

一昔前までは海外旅行の必需品といえばアメリカン・エキスプレスのトラベラーズチェックであったが、残念ながら 日本国内での販売は 2014年3月をもって終了した 。これによって旅行者が現地で買い物をする手段は、ほぼ次の方法しかなくなった。

  • クレジットカード(ショッピング枠)を利用
  • 日本で外貨現金に換金して持っていく
  • クレジットカード(キャッシング枠)を利用
  • 国際キャッシュカードを利用

手数料などを考慮して、換金率のよい順に並べたつもりである。なおクレジットカード(キャッシング枠)を利用する場合の順位は利息に依る。

これらのうち、クレジットカード(ショッピング枠)を利用すれば手数料などが割安で済むので可能であればそれを選択すればよいのだが、ショッピング枠はいざというときに限度額制限に引っかかったり(海外旅行などの事情があるときは一時的に限度額を引き上げることも可能であるが、それも限度がある)、タガが外れて使いすぎてしまったり(こういう人はそもそもクレジットカードを持つべきではない)、現金が必要なときにどうしようもなかったり(ショッピング枠を現金化しようとしてはいけない)と不便も多い。

日本で外貨現金に換金して持っていく方法はもっとも確実だが、盗難の危険や、現金が不足したときにどうしようもなくなる(現地で換金するために日本円を持っていくなどの対策が必要)という問題がある。

クレジットカード(キャッシング枠)を利用すると支払日(最大で2ヶ月先になりうる)までの利息(年利約18%)が発生してしまうので、なるべく選択したくない。帰国したらすぐに一括返済をすることで利息を安めに抑えるという手法もあるようだが、若干面倒である(忘れそうで怖い)。また、使用者が学生だったりするとそもそもキャッシング枠をつけられないこともある(ショッピング枠とは異なり、こちらは旅行などの事情があってもダメな場合がある)。

ということで、どこかの銀行に日本円でお金を預け、世界各国で使えるキャッシュカードを使って現地通貨で引き出せれば便利である。預金が不足した場合も家族や友人にその口座へ入金してくれるように頼めば対処できる。国際キャッシュカードの利用を検討しよう。

国際キャッシュカードの種類と比較

比較サイトとしては ここ が詳しい。

日本に現在存在する、銀行口座付帯の国際キャッシュカードは 楽天銀行新生銀行シティバンク銀行 の3択。Wikipedia を見ると他にもいくつか選択肢がありそうに書かれているが、よくよく読むとそれらはほとんどが現在では使用できない。

シティバンク銀行は、預金額が50万円以内だと、月2000円程度の口座維持費がかかる。よって選択肢から外れる。新生銀行 or 楽天銀行 の間で検討してみよう。

楽天銀行デビットカード

新生銀行キャッシュカード

どちらのほうが安いかは微妙だと思ったので計算してみたところ、年間12万円ぐらいで両者がだいたい一致。それ以下ならば新生銀行のほうが安い。それ以上ならば楽天銀行のほうが安い。

さすがに海外で年間12万円は使わないので、私にとっては新生銀行が最善に思います。

静かな待降節ソング

この記事は 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 である。

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