メールをGnusに移行

(この文書はI Transitioned Local E-mail Management to Gnusの和訳版です。

これまでメールはGmailやGoogle Apps(最近はGoogle Apps for Workに変わったんでしたけ)を公私ともに使用しているため、ほとんどGmailのインターフェースで使用していたのですが、ローカルなメール環境に関しては結構模索を行っていました。Mozilla Thunderbirdなども使うことはあったのですが、結構重いのが欠点でした。

個人的には以下のような要件を満たす必要があります。

  1. 大量のメール(数百件/日)を処理できること。全て深く読むわけではないですが、ML内のメールを高速に走査できることが重要。
  2. 一般的なプレーンテキストのメールを処理し送信できる機能(詳細後述)
  3. MacとLinuxを中心に使っている関係上、これらのプラットフォームをサポートしていること。(Microsoft Outlookが絶対に候補に上がらないのはこの理由の他にも過去の苦い経験もあります。上記1番の使用に耐えうるものでもないですし……。
  4. OpenPGPをサポートすること
  5. 複数アカウントをサポートすること(個人・仕事)

基本的には3番目のポイントで選択がかなり狭まりました。それで考えたのは、どうせマルチプラットフォームでEmacsを毎日のように使っているんだからこれで内蔵のものを使っちゃおうということでした。

「こうして越前康介はGnusを手に入れた」

ということ(?)で、個人的にはGnusを使う利点としては以下のようなものでした。

  • 上記の要項を全て満たした。
  • テキスト編集はテキストエディタである関係上、非常に強力な機能を備えている。
  • 隠し事が少ない分、細かい部分まで制御できる。(反対にいうとそれだけ操作性が粗い、ってことですが。)
  • それなりにEmacs Lispをいじったことがあるのでそこそこの改良を加えることができる。
  • Org-modeと連携できる!(リンク設定などが可能。)

今回の検討で考慮に入れなかったのは以下の通り:

  • 検索能力……どうせGmail系なんだから、餅は餅屋に任せるやりかた。結局はある程度の自動タグのほかはフラットに時系列に行っているので数週間前のメールは検索に頼った方が速いので。反対にいうと一覧表示で見つからないほど古いメールは古すぎて役に立たないか、それ以降一度もタッチしないことがほとんどなので、その管理に労力は使ってません。一応残してはいますが。
  • 通知機能……スマフォやスマートウォッチが知らせてくれるので使ってません。一応Gnus内でこれを設定することは可能のようですがあまり意味はなさそうなのでやってません。
  • リッチテキスト編集機能……HTMLやリッチテキストを送ることはないので。自分をよく知っている人ならわかるかも知れませんが、このようなマークアップでのメールは基本的に送信しません。あっても時々シンプルなマークダウンを行うぐらい。自分からのHTMLメールが届いた、という人はそれはほぼ100%、Gmail for Androidがそのように送信してしまったからです。あのアプリ、プレーンテキストしか送れないくせにHTMLメールで送信するんですよね。閲覧はブラウザを通してすることは可能です。普通はHTMLメールは互換形式としてプレーンテキストとしてついてくるので、それを閲覧しますが、プレーンテキスト版がついてくるので時々行儀が悪い(もしくは設定が不完全)なメーラーがHTMLだけで送ってくることがあります。ちなみにそういうメールは無視されるか、良くても閲覧順の最後尾に容赦なく持っていきます。

なので、上記のような機能に興味がある人は多分この記事は面白くないので、さっさとご退場をおすすめします。

さて、複数のGmail/Google Appsのアカウントを使用しているため、SMTPの使い分けが必要になってきます。この実現には
emacs 30 Day Challengeのusing ‘gnus’ to read mailという記事が参考になりました。ここでは自動的にSMTPアカウントを切り替える方法が書かれていますが、送信の規則性が非常に複雑なこともあり、ここは手動処理の余地を個人的には残しています。つまり、X-Message-SMTP-MethodやFromの変更をする方式になっています。このサイトに含まれるコードは誤って存在しないアカウントなどからメールを送信しないような対策として使用しています。この設定は以下のような感じです。

(defun gnus-set-mail ()
  (interactive)
  (message-goto-from)
  (kill-whole-line)
  (insert "X-Message-SMTP-Method: smtp smtp.googlemail.com 587 example@gmail.com.com\nFrom: Example \n\n")
  (message-goto-body)
  )

ちなみに、KDEを使っていますが、Ctrl-Alt-TはUnityみたいにターミナルを起動する設定になっていますので、Gnusでのスレッド表示切り替えはC-M-tからC-c C-tに置き換えています。ちなみにこの設定は簡単……。

(define-key gnus-summary-mode-map "\C-c\C-t" 'gnus-summary-toggle-threads)

GnusにはMMLという書式が組み込まれているため、MIME構造を柔軟にいじることができます。例えばMIMEパートを自由に入れたりといったようなことが可能ですが、基本的には添付ファイルの扱いを細かく制御するために使っています。

MIMEパートを設定してみる
MIMEパートを設定してみる

とりあえずはうまく動いていますが、今後は必要に応じて細かい挙動をカスタマイズしていく予定。

LINEのタイマートークで思うこと

LINEに新しく、タイマートークという機能が追加されました。

現在、「日本、中国以外でご登録いただいているお客さま」以外にしか使用可能になっていないそうですが、そのうちオープンになるんじゃないでしょうか。(中国では永遠に使用できないかも知れませんが)

どういう機能かというとSnapchatのように制限時間をつけたメッセージを送れるということです。(当然、両環境が最近のバージョンかつ上記の地域制限に引っかかっていない地域のユーザーである必要があります。)

使用を試みると以下のような表示がでます。

Screenshot_2014-07-31-21-24-22

これを見るとエンドツーエンドで暗号化しているようです。メニューにも暗号化キーを表示できるようになっています。見ると128ビット長のユーザー固有の鍵が使用されているです。

Screenshot_2014-07-31-21-24-36

タイマートークのメッセージを受信すると以下のようにタイマーメッセージであることが表示されます。メッセージの内容を通知する設定になっている場合もタイマーメッセージの場合、内容は表示されません。

Screenshot_2014-07-31-21-25-33

メッセージをタップすると双方でカウントダウンが表示されるのが確認できます。この長さは2秒から1週間まで選択できるようになっているようです。

Screenshot_2014-07-31-21-25-45

さて、この機能なのですが、一応エンドツーエンドをLINEで実現しようという機能は評価できるのですがいくつか思いつく問題や懸念としては……。

  1. 暗号が正しく使用されているか、また運営会社や当事者以外の機関(政府機関を含む)の鍵に対して勝手に暗号化を行っていないか
  2. 暗号鍵が変更できない使用になっているが、乱数などでちゃんと生成されたものなのか
  3. メッセージはきちんとソルトされているか

1に関してはこれはクローズドソースの宿命なので、回避のしようのない問題と言えます。これは別にLINEに限らずWindowsなどのOSを含め、どのようなソフトでも当てはまります。
2に関しては、いくら暗号を使用していたとしても暗号鍵が予想できる情報から推測できるものが生成されるような仕様になっていると無駄になってしまいます。また、正しく実装された乱数から取り出されたものであっても、変更が行われない仕様になっていると暗号鍵が漏洩した場合、役に立たなくなってしまいます。これに関しては手動で鍵を再生成し拡散できるような仕組みが欲しいところです。どちらにしても署名目的には使用していない仕様と思われますので、鍵を定期的に再生成するぐらい仕組みでもいいかと思います。
3に関しては特にLINEの場合、既知のスタンプなどパターン化されたメッセージが頻繁に使用されるシステムのため、ソルトがきちんとなされていないとリプレイ攻撃などが容易に行われてしまいます。そのため、他のソリューション以上にソルトが重要であるかと思われます。

尚、評価できる点としてはスクリーンショットの防止・通知など幻想のセキュリティが想起されるような実装を行っていないところです。Snapchatではこれが行われていますが、実際のところその通知がないからと言ってスクリーンショットが撮られていない、という保証はありませんし、基本的に他のユーザーに送られた場合、送られた情報はそのユーザーがどうとでもできる、という前提に使われるべきです。将来的にこれらが実装されるのかは分かりませんが、現時点で敢えてそれらに関して対策を行っていないのはある意味まともとも言えるかも知れません。ただ、ヘルプなどでスクリーンショットなどの撮影が可能なので、タイマーメッセージで送付先ユーザーがそのメッセージを受け取った後は必ずしも安全でない、ということは示されるべきであると考えます。

DockerでTorアプライアンス(的なもの)を作ってみる

最近個人的に注目しているものにDockerがあるのですが、これ、簡単にいうと、Linuxの構成をコンテナ化して、システム間での可搬性を実現するシステムです。コンテナ内のプロセスは隔離されるため、要は仮想環境を構成するシステムなわけですが仮想マシンと違って環境を走らせるオーバーヘッドが非常に軽く、普通のソフトウェアを動作させる感覚でコンテナが実行できます。また、Ubuntuを使っていてCentOSやFedoraの環境を構成したい、というようなことも可能です。(Linuxをベースにして走らせる仕組みになっていますので、例えばWindowsを走らせたり、反対にWindowsからコンテナをそのまま実行したり、ということはできません。その場合は仮想環境を作るソフトが必要になります。)

どういうことに使えるか、というと

  • 現場環境に近いテスト環境を作成する
  • 環境をローカルで構築し、Dockerがデプロイされている環境にそのまま移植する)
  • メイン環境に手を加えずにシステムに変更を加えるようなソフトウェアを利用する(特にroot権限を要するようなプロセスを走らせないといけない場合、-vオプションなのでファイルシステムのアクセスを与えない限りファイルのアクセス権限はコンテナ内に制限されるため、比較的安全に実行できます。極端な話、コンテナ内でrm -rf /*が実行された場合でも外部にコンテナ外には影響は及びません。)

など、いろいろと考えられると思います。例えば、PHP実行環境のバージョンが異なったウェブサーバを立ち上げる、ということができるようになります。

今回これを利用してTorのアプライアンス的なものを作ってみることにしました。

Torのファイル自体は公式レポジトリのものを使用します。

空のディレクトリにDockerfileというファイルを作成し、以下のように記述しました。

FROM ubuntu:13.10
MAINTAINER Hideki Saito 
RUN echo "deb http://deb.torproject.org/torproject.org saucy main" >> /etc/apt/sources.list
RUN gpg --keyserver keys.gnupg.net --recv 886DDD89
RUN gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -
RUN apt-get update && apt-get install -y tor
ADD files/torrc /etc/tor/torrc
EXPOSE 9050
ENTRYPOINT ["tor"]

このスクリプトによりTorのレポジトリを追加し、インストールした上で、目的に書き換えたfiles/torrcを含めた上でコンテナ化する、という設定になっています。レポジトリがない場合でも、依存を設定した上で、最新ソースを引っ張り、コンパイルした上で配置、クリーンアップしてコンテナ化する、といったようなことももちろん可能になります。このファイルを作成した上で、files/torrcにTorの設定を記述し、docker build -t “hsaito/torbox” .を実行しました。すると自動的にapt-getによるファイルの入手や、インストールが行われ、ローカルのイメージリストにhsaito/torboxが作成されます。この場合はhsaito/torboxとして作成し、Docker Indexにプッシュしました。このプッシュという方式はGitによく似ています。プッシュやプルの場合、差分のみが送受信される形になります。

Dockerが強力などが派生環境を非常に手軽に作れることです。例えば、今回の例の場合、アプライアンスとしてのSOCKS環境ではなくて、Tor relayサーバをコンテナ化したいとします。そうなると必要なDockerfileの定義は以下のようになります。

FROM hsaito/torbox
MAINTAINER Hideki Saito 
ADD files/torrc /etc/tor/torrc
EXPOSE 9001
ENTRYPOINT ["tor"]

この場合、上記と違い「FROM hsaito/torbox」を設定しているため、すでにhsaito/torboxを持っている場合はそれが再利用され、差分だけがダウンロードされます。(こちらはhsaito/torbox-relayとしてプッシュしました。)そのため、レポジトリからTorをインストールしたりする定義は行っていません。変わっているのは独自のtorrcを差し替え、露出されるポート番号を変更しているだけになります。実は上記の場合も元のイメージの「ubuntu:13.10」を前提に作っています。これを利用することにより、例えばウェブサーバを含んだコンテナをまず作成しライブラリのみを差し替えた差分コンテナを作成する、という方法をとることにより、楽にコンテナ環境が作成・管理できます。

ちなみに上記はそれぞれdocker pull hsaito/torboxとすることでダウンロードし、docker run -d hsaito/torboxなどで実行できます。(relay版を使用する場合はhsaito/torboxをhsaito/torbox-relayに置き換えて下さい。

UUIDの生成

最近UUIDを生成することが多いので、uuidgenを使って生成していたのですが、使用しているEmacsより簡単に起こす方法を模索していたら、以前Ergoemacsでその記事があったのを発見。

例として以下のようなものでした。

(defun insert-random-uuid ()
  (interactive)
  (shell-command "uuidgen" t))

まあ、普通にuuidgenを呼び出しているコードなので、これでも全く問題がないわけですが、必要になったときのために、Emacs内で関係させる方法を見ていると同記事にいくつか例がありました。

掲載されているコードですが、4番目のセクションの最初の文字が必ず「a」が出力されるようになっています。別にUUIDの規格上正しいものが出力される(この文字は「8」、「9」、「a」、「b」のいずれかである必要がある)のですが、固定はちょっと気持ち悪いので以下のように変更し、規格上正しいもののいずれかが出力されるように変更しました。

;; by Christopher Wellons. 2011-11-18. Editted by Xah Lee.
;; Edited by Hideki Saito further to generate all valid variants for "N"
;; in xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx format. 
(defun insert-uuid-internal ()
  "Insert a UUID. This uses a simple hashing of variable data."
  (interactive)
  (let ((myStr (md5 (format "%s%s%s%s%s%s%s%s%s%s"
                (user-uid)
                (emacs-pid)
                (system-name)
                (user-full-name)
                (current-time)
                (emacs-uptime)
                (garbage-collect)
                (buffer-string)
                (random)
                (recent-keys)))))
    
    (insert (format "%s-%s-4%s-%s%s-%s"
                    (substring myStr 0 8)
                    (substring myStr 8 12)
                    (substring myStr 13 16)
                    (format "%x" (+ 8 (random 4)))
                    (substring myStr 17 20)
                    (substring myStr 20 32)))))

まあ、uuidgenが使える環境であれば/dev/urandomをソースとするuuidgenを使用したほうが乱数源などを考えると一番ベストなわけですがUUIDを生成する程度のことであればそれほど大差はないかもしれません。

完全なコードHidekiBinにおいてあります。

Vocaloidに必要なのはキュレーションかもしれない

Project Diva F (先日米国でも正式リリース)をプレイしてて改めて思うのは、初音ミク(というかVocaloid全般)という「歌手」が更に飛躍するために必要なのはコンテンツのキュレーションなのかな、と思う。

前に書いたことの繰り返しになるけど、Vocaloid達の歌というのは「歌手」としては非常に多数の持ち歌があって、そのスタイルも非常に幅広いので、いい曲は多いのだが、その反面、とっつきにくい、という面もある。

Karentなど、歌を集めて配信しているものはあるけど、Spotifyなんかからこれらを検索して目につくのはその発見性の悪さ。ニコニコ動画なんかでVocaloid楽曲に馴染んでいる人であれば作者名なんかからも好きな曲を発見できるのかもしれないけど……。

自分はVocaloidのソフトも持っていて遊んではいるけど、コミュニティの中にいるとは言い難い立場なので、もともとコミュニティ内でメインストリームへのアプローチがどのくらい重視されているのかはわからないけど、楽曲の波にいいコンテンツが埋もれてしまっているかもしれない。これを広くアピールできないのはもったいないかもしれない。

この記事の英語版はこちら / An English Version of this article is here

萌えモデリングをまた始めてみる

ポリゴン分割モディファイアを使用したキャラクターの作り方について解説しているビデオがあったのでそれを応用してまた萌えモデリングを試してます。
モデリングしているのは「ゆゆ式」から野々原ゆずこ。

modeling

確かにポリゴン分割モディファイアを使用することによりかなりあたりが取りやすい。これまでは四角形からそれを押し出す形で作ってたけど、なかなか形にならなかったので。

yuyu.blend

髪の毛の試行錯誤も開始。こちらも同じ方法でできないかと考えてます。

色とアニメとそのグラフ……

Blenderの画像・映像ビューワーには各種分析機能が備わってて色の確認ができるようになっているのですが、ちょっと遊んでみました。

yuyushiki

右に表示されているのがそのグラフ群。上からヒストグラム、波形、ベクトルスコープ。

あまり詳しくはないのでわかりやすい解説はできませんが、ヒストグラムは画像中に含まれる色成分(この表示の場合はRGB)の量を示したものです。デジカメの液晶でも表示できたりするあれと同じものです。「ゆゆ式」のこのプロモ画像の場合はピークが尖っているので特定の色に集中した絵作りになっているということになります。

nyaruko

「ニャル子さん」の場合は白い部分が多いのでそれもヒストグラムに現れてます。

上から二番目の波形というのは(表示されているものは)YCbCrの表示。左(マゼンダ)から輝度で、画像の明るさのグラフです。その横が色差信号を示していて、真ん中(黄色)が青色成分から輝度を引いて、一定の定数を掛けたもの、一番右(青)が赤色成分から輝度を引いて一定の定数を掛けたものです。ちなみに縦が明るさ、横が画像の横方向のラインを示します。(Blenderではその他では輝度、RGBなどの波形を表示することも可能。)

muromi

「むろみさん」の画像の場合、更に広い範囲に色が広がっているのがヒストグラムから分かります。

ikamusume

同じ海をテーマにしたアニメの「イカ娘」だとこんな感じ。「むろみさん」が広い範囲の色を均一的に使っているのに対して、一定の色が強く出ているのが「イカ娘」

一番下に出ているのがベクトルスコープ。少し薄いですが12時の位置の四角い印が時計回りにマゼンダ、青、サイアン、緑、黄色、赤を示しています。ちなみになぜこのような円の配置になっているかというとこれが前述の色差信号をCrの部分を縦軸、Cbの部分を横軸にしているからです。

中心に行くほど色がない状態に近く、外側に行くほど色が強くなってきます。四角い印はカラーバーで調整する時に使用するもので、それぞれの色がここに合うようにします。

colorbar

ちなみに上のプロモ画像の場合、色の強さなどが放送に配慮したものではないため、多分そのままでは放送できないと思われます。(ベクトルスコープの円から大きく逸脱している部分があるので……。)

muromi-scr

そのため、本編だと結構押さえ気味になっているようです。

BitTorrent Sync

BitTorrent SyncみたいなP2P型のファイル同期システムって、AeroFSや、Tonidoなど、いろいろと同じようなコンセプトのサービスがあるのだが、BitTorrent Syncで注目したいのはアカウント登録がいらないこと。(ここはやっぱりBitTorrentで培ってきた技術があるのか。)他のサービスの場合、まずはアカウントを作ってそのログイン情報でログインして使う必要がある。P2Pなのにアカウント登録が必要ってのがなんだかな、という感じ。その点BitTorrent Syncでは共有に対する鍵を渡すだけで同期ができる。ちなみにRBU7XLPET43IWGFSLNJEGREIOZI6V4YE2を登録すると自家製Emacs(Windows版及びMac版+ソースコード)が流れてきますので試したい人はどうぞ。(読み取り専用なので勝手に誰かがファイルを加えたり変更はできません。)

Emacsカスタムスプラッシュの設定方法

これまで何回かスクリーンショットを載せたことのある、このEmacsの画面、設定の仕方の問い合わせが何回かあったのでここに掲載しておきます。(Emacsの内蔵機能です。)

emacs-homebrew

 

まずは適当な画像を用意します。恐らく表示できる範囲のものであればどんなサイズの画像でもOKかと思います。ちなみにデフォルトの画像は270×217なので、これに合わせるのがいいかも知れません。ファイル形式はEmacsが対応する画像(どのようにコンパイルされたかによって異なる)のですが通常はXPMが無難かもしれません。

次にM-x customizeで設定画面に入ります。

customize

Searchの項目にfancy splashと検索すると、通常、一つの項目が出てくると思います。通常はDefaultとなっていると思いますが、これをFileに変更し、出てくるFileボックスに先ほど準備した画像のファイル名をフルパスで指定し、設定を保存します。

fancyset

これでC-h C-aを表示するとスプラッシュ画像が設定されているはずです。

Sakura-Con 2013日本人ゲスト担当課におけるソフトウェアの使用

昨年、Sakura-Conの日本人ゲスト担当課においてはOrg-modeを多用したわけだが、今年はそれを推し進め、更に多彩なソフトウェアを採用した。

Emacs/Org-modeの使用に関しては昨年の同じ程度のものであったが、今年はそれに加え、LaTeXとMobileOrgの使用も開始した。

LaTeX書類がどのように使われたか

LaTeXは大小問わず多彩な書類の作成に使用され、これらには議事録やマスタースケジュールブックなどが含まれた。これを実践するに辺り、LaTeXソースそのものの編集はテンプレートの更新程度に留め、Org-modeで行い、それを出力することを重視した。これはOrg-modeで記述されるデータの一貫性を保つことと、また、自分以外のメンバーが書類を更新する必要がある際に、できるだけ負担を減らす意味合いもある。(もちろんEmacsの使い方に関する学習曲線というものは存在するものの、Org-modeの記述の方がLaTeXよりも解読が容易であるため。)また、Org-modeは他のフォーマット、例えばOpenDocumentなどに出力する機能も備えており、共同編集の場合にはそれを行うためのファイルを出力することも可能であった。

書類作成としてLaTeXを採用したことにより、シェルスクリプトを使用することにより、個別に宛てた手紙なども作成することも可能であった。(これはシェルスクリプト経由で個別のジョブに対して違った変数を与えることで実行した。)

もともと手紙に関しては自分以外の担当者により準備されていたが、今回はギリギリまで変更が加えられる可能性があったため、このプロセスを採用することとなったが、この種類の書類に関してはその体裁も非常に重要となるため、ヘッダなどのデザイン要素をPDF部品として準備してもらい、それをLaTeX経由で入力していった。これは日本語と英語で行われ、行末のハイフン処理なども含め、非常にプロフェッショナルな体裁を使用することができた。

MobileOrg

MobileOrgの使用は以前より計画されていたものの、今回は限定的な使用にとどまった。現在のMobileOrg(Android版)の可用性があまり高くなく、まだまだ混乱しやすいものであった。そのため、シンプルなTODO情報をUbuntu Oneサービス経由で同期を行った。こちらに関しては引き続きプライベートな使用を続けており、今後また検証を行う予定である。

Sakura-ConでのOSS使用の今後

尚、この情報に関しては自分が所属する課で限定的に使用したものにとどまり、コンベンション自体が同じシステムを採用しているわけではない。ただし、Sakura-Conのような非営利組織の場合、個人のIT要件がそれぞれことなり、どのようなソフトウェアが個人でインストールされているかがわからないのも事実である。LaTeXを自由に使いこなす技術というのはMicrosoft Officeや、LibreOfficeなどに比べると比較的高いが、複数の環境で同様の体裁を予想できる形で出力できるという利点がある。

今後はオートメーションなどを更に進め、大きなライフサイクルとしての書類管理を目指したいと思う。