Macのターミナルの配色が絶望的なのでなんとかした

Macで標準のターミナルを使っていると、カスタマイズができなくて困ることがある。

特に、デフォルトの色はあまりにも残念で、ディスプレイと環境光によっては青が全然見えなかったりするが、これは通常編集できない。

先日、初めてフルHDのディスプレイを購入したが、昨日から梅雨が明けて太陽が出るやいなや、ruby-modeの関数名が全く見えなくなってしまった。

そこで、TerminalColoreopardをインストールして、色を変更することに。

http://niw.at/articles/2007/11/02/TerminalColoreopard/ja

詳しいインストール方法や使い方はリンク先に任せるが、あとは環境に合わせて見やすい色にすればよい。

そういえば、このディスプレイを買ってから、晴れた日に部屋でコードを書いていなかった。

Twitterの規制について気づいたこと

たまにはこんな話でも。クライアントやBOTを作っていて気づいたことを幾つか。

Twitterをクライアントソフトウェアを通して使っている人は多いと思うが、一時間ごとに問い合わせられる回数が決まっており（規制）、その回数制限に悩まされている人が多い。その規制の種類や、回避策、今後の変化を総合的に考察してみたい。

ここでいう規制とは、データの取得にかかる規制のことで、投稿とは関係ない。投稿は、TL取得規制がかかってもすることができるので、実は規制されてもクライアントソフトウェアでつぶやくことはできる。

まず、規制には以下の種類がある(以下に書いた名前は正式名称ではない／括弧内は１時間あたりの回数制限)

1. OAuth規制(175)
2. Basic認証規制(75)
3. IPアドレス規制(150)
4. Streaming API(∞)

OAuth認証規制

OAuthは新しい認証方式で、コンシューマ（ふぁぼったーやTweenのようないわば２次サービス）がそのユーザのパスワードを知ること無くアクセス出来る認証方式。これを使うと、規制回数がBasic認証の１０倍にあたる１５００回になる。・・・のだが、最近では３５０に引き下げられてしまった・・・と思ったら、従量制APIが導入され、Twitterの負荷によってAPIの規制回数が変動するようになった。今は１７５に固定されているらしい。誰もが予想したとおりの展開だった。

Basic認証規制

HTTPのBasic認証を使った認証方式。単純で実装が用意だったが、パスワードをコンシューマに教える必要があり、危険だったのでOAuthに取って変わられる。１５０回の制限だったが、今は７５回になったらしい。もともと、６月いっぱいで終了する予定だったので、今となっては殆ど誰も使っていないのではないだろうか。

IPアドレス規制

意外と知らない人が多い制限その１。

実は、Twitterには、つぶやき検索や公開リスト、つぶやきIDを指定してつぶやきを取得など、ログインせずに見ることが出来る情報が結構ある。ログインせずに見ることが出来るのだから、OAuthやBasicの回数制限とは関係ない。

しかし、コンピュータに割り当てられる※本当は違うけど勘弁IPアドレス毎に、毎時間１５０回までと、ここでも規制がかかっている。OAuthやBasicとは当然別にカウントされているので、クライアントを作るときは可能ならこちらを使うようにしたほうがユーザには親切ということだ。

Streaming API

知られていないその２。

Streaming APIは、定期的にツイッターに問い合わせるのではなく、ずっとつなぎっぱなしにしておき、新しいつぶやきがあれば順次向こうから送ってくるというもの。その性質上、回数制限はない。Basic認証で認証されるため、パスワードが必要。このAPIに対応しているクライアントはあまりないし、時々取りこぼしがあるようだが、一切規制の心配がないし、つぶやきが投稿されたら数秒でそれが取得できる。

で、

Streaming APIは置いておくとして（クライアントの対応次第なので）、実はIP回数制限を、通常のタイムライン取得に使うことが出来る。

公開リストは、取得するためにログインする必要がない。つまりIPアドレス規制の範囲で取得することができる。

ということは、フォローしている人全員が入ったリストを作っておけば、OAuthやBasic認証が規制されてもクライアントソフトウェアから見ることが出来る（IPアドレス問い合わせに対応していない、リストに対応していない場合は不可能だが）。

また、似たような方法でリプライも取得することが出来る。検索もIP問い合わせで取得できるので、「@ユーザ名」で検索をかければ、自分のリプライがすべて見られる（なお、この方法を使えば、誰に対するリプライでも見ることが出来る。自分宛以外でも）。

問い合わせ方法を上手に使い分ければ、規制に悩まされることも減るのではないだろうか。

クライアントソフトウェアの対応

現在はまだテスト中らしいが、chirp user streamを使えば、規制の影響を受けずに、わずか数秒のタイムラグでつぶやきを受け取ることが出来る。しかも、フォローされたとき、誰かが自分のつぶやきをお気に入りにいれたとき（ふぁぼられた時）にも、数秒でわかる。これは今後どうなるかわからないが、Twitter使い方が大きく変わるだろうし、規制を過去の遺物にならしめることだろう。

しかし、これが一般に利用されるようになったとしたら、Twitterのサーバは大丈夫なのだろうか。少し心配だ。

Subversionには実行権限を記録させておけるらしい

% svn propset svn:executable 1 mikutter.rb

property 'svn:executable' set on 'mikutter.rb'

なんでも、実行権限があればいい具合に扱ってくれるので、今まで知らなかった（忘れていた？）らしい。ぐぐっても、誤って付与されてしまった実行権限を取る方法のほうがよく出てくる。

1ってなんなんだろう。最近gitが流行りなので、Subversionのバッドノウハウにはすっかり興味がなくなってしまった。

あの言語は今

あの言語は識者の助言からMIKUという名前になり、今もちょっとづつ開発が進んでいる。
とにかく、今は無名関数が使えるようになったのでいわゆるアキュムレータを返す関数が定義出来る。
すなわち、関数genacmは、「数値をとり、過去にとった数値と合計した値を返す関数」を返す関数だ。

(setf 'genacm (lambda () (set 'now 0) (lambda (inc) (set 'now (+ inc now)))))
(setf 'a1 (genacm)) ; => #
(setf 'a2 (genacm)) ; => #
(a1 1) ; => 1
(a2 2) ; => 2
(a1 3) ; => 4
(a2 4) ; => 6

パーサが前に書いたようなルールで読み取ってくれるならこう書けるはずだ。

setf[genacm {()
now = 0
{(inc) now = inc + now}]
setf[a1 genacm[]] ; => #
setf[a2 genacm[]] ; => #
a1[1] ; => 1
a2[2] ; => 2
a1[3] ; => 4
a2[4] ; => 6

例示しておいてなんだけどシンタックスは特に触れない。
注目すべきは、a1とa2は、何れもgenacmが作った関数であり、それは毎回nowに引数を加算するだけだが、nowはgenacmが呼び出される度に新たに作られる（a1とa2のnowは別物）。レキシカルスコープを持ったクロージャだ。
MIKUで定義した無名関数は、Rubyにおける無名関数と等価だ。つまり、Rubyのメソッドにそのまま渡すことが出来る。
問題は、Rubyでは無名関数を渡すときに「ブロック引数」として渡す。この特別扱いによってさも構文を拡張したかのように振る舞えるが、MIKUから渡すには新たにシンタックスを加えることになる。

ary.each{ |x| p x } # eachメソッドにブロック引数を渡している

Rubyに似せるならこんな方法があるだろう。

each[ary |x| p x]

|が出てきたら、そのリストの終わりまでを全て無名関数に変換して、ブロック引数として渡す。
一見いいような気がするが、これができるようになるということは、MIKUで定義した無名関数もブロック引数をとれるということになってしまう。そして、所詮RubyのProcオブジェクトなので、実は手を加えなくてもnew[Proc]とするだけでブロック引数を取得することが出来る。
ブロック引数は、Rubyには良いアイデアだったが、曲がりなりにもLispな言語に組み込んでも、紛らわしいだけな気がする。

とにかく、無くても死なないので、当分このまま放置。しかしこれが使えないとなると、Rubyのメソッドが叩けるとはいえないのも事実。

key chord

Emacsにはキーバインドが不足している。私は矢印キーなどを使う軟弱者なので、幸いC-[bfpn]は開いているが、でも足りない。例えば、replace-stringやreplace-regexpは割と使用頻度が高いが、さてこれをどこに割り当てたものか。あと、１ストロークで実行したいものもたくさんある。

そんな時はkey-chordというelispを使えばいいらしい。（http://www.emacswiki.org/cgi-bin/wiki/download/key-chord.el）

;; key-chord

(require 'key-chord)

(key-chord-mode 1)

(setq key-chord-two-keys-delay 0.05)

;; key setting

(key-chord-define-global "gl" 'goto-line)

(key-chord-define-global "as" 'auto-save-buffers-toggle)

(key-chord-define-global "re" 'replace-string)

(key-chord-define-global "zx" 'undo)

key-chord-define-global は、第一引数で指定された文字全てが同時に（key-chord-two-keys-delay秒以内の誤差で）押されたら、関数がコールされるというもの。

例えば、指定行に行きたいときにはgoto-line(M-g g)を使うが、これがgとl同時押しでよいのだ。同じ要領で、reでreplace-stringも使えるようにした。これこそ、私にしてみればワンストロークでやりたかったことだった。

今回は頭文字をとってキーバインドを適当に決めたが、実際にはおしやすさが重要。中途半端に離れているととても打ちづらい。なので、実は現実的な割当数は思ったよりは少ないが、それでも大変な数のキーバインドを手にいれることが出来る。

key-chord.elにはcopyright 2003とか書いてあった。こういうelispを知る度に、一週間くらいずっと拡張ばっかりする時間が欲しいと思うのだが、結局そんな時間は取れた試しが無い。まだ数日しか使っていないが、手放せないelispになりそうだ。

なお、ターミナルではキルリングとクリップボードの共有（とりあえずMac）をやっておかないと、クリップボードから貼りつけると、いろんなキーがほぼ同時に押されたことになって大変なことになるので注意。

キルリングとクリップボードの共有（とりあえずMac）

emacsは独自のキルリングを使っているので、emacsで C-w などでコピーしたところで、例えばFirefoxにそれを貼り付けることはできない。

回避策として、ターミナルなら、それのコピー機能を使用することで、外部アプリケーションに張り付けられる。逆に、クリップボードの文字列も同様の方法でemacsに貼り付けることが出来る。

しかしこれには致命的な欠点があり:

• 見えたままクリップボードに入るので、ウィンドウ分割していると上手くコピーできない
• クリップボードからペーストすると、一文字ずつ打ったことになるので、重いしインデントが勝手につく

と、スマートとはいえない状態だ。GUIから起動すると、メニューからコピーなどができるようになっているが、Screenバンザイなのでそちらに行こうとは思えなかった。

そこで、以下のようなelispを、.emacsに書き加えた。（ソース:http://blog.lathi.net/articles/2007/11/07/sharing-the-mac-clipboard-with-emacs）

; http://blog.lathi.net/articles/2007/11/07/sharing-the-mac-clipboard-with-emacs
(defun copy-from-osx ()
 (shell-command-to-string "pbpaste"))

(defun paste-to-osx (text &optional push)
 (let ((process-connection-type nil))
     (let ((proc (start-process "pbcopy" "*Messages*" "pbcopy")))
       (process-send-string proc text)
       (process-send-eof proc))))

(setq interprogram-cut-function 'paste-to-osx)
(setq interprogram-paste-function 'copy-from-osx)

これでシェアされる。ただしMac限定。

仕組みは簡単で、macのコマンドpbcopyとpbpasteを利用しているだけだ。コマンドの名前があまりにも自明なのであえて説明はしない。

要するに、linux, windowsでも同様のコマンドがあれば、コマンド名の書換だけで使用できるようになる。現在度重なる不幸によって（笑）自分用のubuntu開発機を持っていないので、Linuxでの対応はまたその時にしたいと思うが、少し調べたら同様のコマンドはあるみたいだし、GTKを使えば数行のコードで実現出来るはずだ。

まだまだやりたい事は出来ていない・・・

先日、mikutterの着想から半年が経っていたことに気がついた。途中なんども開発を停止しているし、別のこともいろいろとやっていたので本当に半年やっていたわけではないが、結構経ってしまった。
実際には、CHIを書き始めたのは１０月であり、今まで何をしていたんだ、と落胆しそうになったが、とりあえずこれだけの機能がつけられた。

• ホームタイムライン
• リプライタイムライン
• 検索
• saved search
  
• 通知
• URL短縮
• リプライ元つぶやきの表示
• リプライ
• リツイート
• 公式リツイート
• お気に入り
  

と、非常に少ない。亀進行である。未だにプロトタイプのレベルを出ていない。
主観だが、以下の機能が「普通のクライアント」を名乗るためには足りないのではないだろうか。

• ダイレクトメッセージ
• お気に入りに入れたつぶやきのタイムライン
• スマートリスト（フィルタ）

逆に、現時点では以下の機能が普通のクライアントを上回っていると考えている

• twitter.comからつぶやきを検索出来る
• ハッシュタグの内容をmikutterから閲覧出来る
• Webで保存した検索をタブに表示できる
• あるつぶやきのリプライ元をノークリックで見ることが出来る

特に検索関係は強い。とりあえずだが自動更新も有り、少し改良すればtsudaる用途にもいい線を行くのではないだろうか。
つぶやきのリプライ元表示は良いアイデアで、構想段階からすでにあった。単純に、フォントを変えて下にリプライ元を表示しているだけだが、これだけでタイムラインの見た目はぐっと変わり、一番の長所といっていい。が、こんなものは簡単にパクられる。
# つぶやきの表示にリストビューを使っちゃった人たちには簡単にはパクれないかもしれない

では、構想段階ではどのようなことを考えていたのか、再び挙げてみたい。これは、１２月の時点で既に欲しいと思っていた機能だ（既に実現したものは外している）

• ダイレクトメッセージ
• お気に入り
• ふぁぼられ
  
• 特定のつぶやきだけをまとめたリスト（Togetterのようなイメージ）
• 公式リストへの完全対応
• フォローしている人一覧
• フォロワー一覧
• 特定の人のプロフィール確認
• 自分のプロフィールの編集
• フォロー・リムーブ・ブロック・ミュート・マーク
• スマートリスト
• つぶやきの永久保存及び検索
• 画像アップロード
• 画像インライン表示（少なくともブラウザを介さない）
• Twitlongerを利用したつぶやきの短縮
• スレッド
  

Togetterのようなものだが、これは今はどうかな、と思っている。使いたいケースがあまり思いつかないからだ。何故欲しいと思ったんだろう（とはいえ、この程度のことはプラグインで出来るので、後で作ってもいいかも）。
ミュート、マークはオリジナルの概念だ。ミュートは、フォローしているにも関わらず特定の人のつぶやきを一切ホームタイムラインに表示させない。逆にマークは、フォローしていないにもかかわらず特定の人のつぶやきをホームタイムラインに表示させる。相手に知られること無く、フォロー／リムーブができる。幾つかのクライアントソフトには、既に実装されている。
ミュート、マークはスマートリストで実現可能かもしれない。スマートリストは、簡単なフィルタ言語等でつぶやきを絞り込んで表示するタブで、フィルタ言語にはHatsuneLispを検討している。スマートリストは、ホームタイムラインやリプライタイムラインを実現可能なので、これ一つで大抵のことをしてしまう時がくるかもしれない。
つぶやきの永久保存及び検索は、MySQLとSQLiteを用いて実装したが、万人受けするものではない割にライブラリ等の依存関係がややこしいので配布には至っていない。
最後のスレッドとは、つぶやきの親子関係を再帰的に辿り、一連の会話のツリーを構成するるぶやきをタイムラインに並べる機能。これがあれば、つぶやきを一つ拾えば会話全体が見えるようになり、革新的な機能となるだろう。

かなり盛りだくさんに見えるかもしれないが、これくらいないと使い物にならないと考えている。mikutterは、現在のTwitterクライアントに対する問題提起なのだ。作り始めたきっかけが「良いクライアントがない」という現状をなんとかするため、だったからだ。

こうしてみると、やりたい事の半分以下も出来ていないように見える。しかし、拡張可能な基板は整いつつあり、現在はつぶやきの保存方法すらプラグインで拡張出来るようになっている。つぶやきを投稿したら１秒くらいでフォロワー全員のところに届くのが当たり前の時代もついにすぐそこまで来ているし、半年後は今では想像もできない使い方をしているだろう。
# ハッシュタグとか、去年は公式サポートなかったんじゃなかったっけ・・・あと公式リツイート？検索っていつついたっけ？
とにかく・・・Twitterが本気を出す頃には、Twitterをちゃんと使えるクライアントにしておきたい。