2014-04-24

iphone_dev_jp feat. Ben Zotto の講演まとめ

2014-04-22、iphone_dev_jp において Penultimate の開発者 Ben Zotto 氏の講演が開かれた。

  • 日時: 2014-04-22 (火) 19:00-21:30
  • 場所: アーク森ビル 31F 株式会社ドコモ・イノベーションベンチャーズ ラウンジ

Penultimate は iPad 用の手描きアプリ。Evernote に描いた絵を保存できる。

講演では、Penultimate のパフォーマンスでボトルネックとなった「画像」の内部処理が語られた。

iOS と Evernote

Penultimate は特定のタイミングとイベントで Evernote と同期 (sync) する。Evernote API は画像のデルタ保存 (差分だけを保存する技術) をサポートしていないので、全て上書きになる。

iOS には画像を扱うメソッドが 2 つある。

  • UIImagePNGRepresentation
  • UIImageJPEGRepresentation

PNG と JPEG のメソッド。PNG は可逆圧縮で、JPEG は不可逆圧縮。

2.5 MB の RAW データをそれぞれの方式で圧縮した場合のデータが示された。使う画像は、メモのような書き物、画像的な図、そして書き物と図を一緒にした dense。

結果は、メモや図では PNG に運配が上がる (メモ: 145 KB < 155 KB; 図: 110 KB < 136 KB) ものの、dense では JPEG の方が良かった (dense: 251 KB > 191 KB)。

PNG-8

Dense を考えれば PNG より JPEG の方が好ましいか。

ここで Penultimate が扱うデータに注目してみる。Penultimate では 32bit の PNG 画像など扱わない。せいぜい使う色の数は 256。ならば、256 色のカラー・パレットを持つ PNG-8 形式を使えば画像サイズは 1/4 になる。

PNG-8 には pngquant というツールで変換できる。その結果は次の通り:

PNGJPEGPNG-8
メモ145 KB155 KB61 KB
110 KB136 KB36 KB
Dense251 KB191 KB91 KB

このように、Dense であっても PNG-8 の方が JPEG よりサイズが小さい。

補: Quantization

PNG (32bit) から PNG-8 に変換する手順を簡単に書いておく。

  1. 元の画像から色のヒストグラムを作成する
  2. 最適化されたカラー・パレットを決定する
  3. 各ピクセルに対して、カラー・パレットから最適な「色」を決める

3 番目の手順は、コードで書けばこんな感じになる。

for (pixel in image) {
  for (color in palette) {
    // 元の色に対して color が合うかどうか判定する
  }
  // 選んだ色をピクセルに貼り付ける
}

第 1 試行

Mac では 0.7 ms で実行できた。

iPad では 6 秒かかった。

遅すぎる!!

プロファイルを取ると、Quantization の手順 3. で時間を喰っていることが分かった。

第 2 試行

上記コードの内側のループを SSE のアセンブラで、外側のループを OpenMP で処理したい...

のだけど、どちらも iOS にはない。

ので、SSE の代わりに ARM NEON を、OpenMP の代わりに Grand Central Dispatch を使う。

その結果は... 5 秒だった。

The fastest implementation of a slow algorithm is still slow.

遅いアルゴリズムを最速にチューニングしても、遅いものは遅い (意訳)

第 3 試行

内側のループを外してみる。

pngquant は「どんな画像」に対しても「良い」カラー・パレットを作成する。けれど、Penultimate は手描きアプリだから描ける画に制限がある。だから、事前に「ある程度良い」カラー・パレットを作成可能なはず... というアイデア。

具体的には pngquant をオフラインで実行し予めパレットとテーブルを作成する。これらを最初からアプリの中に保存。必要な時に (都度々々作成するのではなく) ロードする。

これで実行速度は 0.5 秒になった。

第 4 試行

そして、最後の試み。予め作ったカラー・パレットを 3 次元表示してみる。

Color palette in 3D

これはまるで、立方体にテクスチャーを貼ったもののように見える。3D テクスチャーと言えば OpenGL。

3 次元を 2 次元に展開すると (ref. ボロノイ図) こうなる。

Color palette in 2D

このデータを OpenGL から使うように再コーディング。OpenGL は CPU ではなく GPU を使うことができるので (特にこの手の処理では) 処理能力の向上が期待される。

結果... 0.025 秒。

圧倒的じゃないか!!

Morals of the Story

Zotto 氏は最後に開発の肝を紹介した講演を閉じた:

  1. Find your bottlenecks with profiling
  2. Use peculiarities of your data to find opportunities
  3. Put the platform to work!

(意訳)

  1. プロファイリングでボトルネックを見つけなさい
  2. 扱うデータの特異性を有効利用しなさい
  3. プラットホームで動くようにしなさい

あとがき

iOS の話だったけど、XCode とか、UI とか、NSObject とか全く出なかった。データ最適化の手法を見せつけられた。なんか、C の世界に戻って来た気がした。

OpenGL の高速化には舌を巻いた。

最後の質問タイムで、こんな質問が出た。「何をもって、最適化の『終点』としたのか? 何故 0.5 秒で満足しなかったのか?」。Zotto 氏は「自分はエンジニアで...云々」「でも、当時はプロジェクト・マネージャーもやってて...云々」と前置きを宣わって、こうとどめを刺した。

そこに OpenGL のパイプラインがあって、数時間でやれるんだったら、試してみたくなるだろう?

2014-04-23

ダンボーのモバイル・バッテリー — アクトインディ送別会でのプレゼント その 2

cheero power plus DANBOARD version

アクトインディの送別会でよつばとのマグカップを頂いた。実はもう一つプレゼントをもらっていた。それが、ダンボーのモバイル・バッテリー。正式名称は cheero power plus BANBOARD version -mini-。

モバイル・バッテリーで有名な cheero がキャラクター・ダンボーとコラボした製品。人づてに聞いて確認していないのだけど、このダンボーは、マンガ「よつばと」で生まれたのだとか。マグカップといい、「よつばと」繋がりでプレゼントは選定されたっぽい。

ますます、「よつばと」を読まなきゃな気分になる。ネット喫茶に置いてあったかな?

コンパクトなモバイル・バッテリー

ぼくは今、2 つのモバイル・バッテリーを持っている。cheero power plus と Anker astro M3 の 2 つ。cheero が 10,000 mAh で、Anker が 13,000 mAh。

ぼくが今回もらったのは、ダンボーは mini バージョンなので 6,400 mAh。

せっかく 3 つ持っているので、サイズの比較をしてみた。

モバイル・バッテリーのサイズ比較

上から、ダンボー、cheero、Anker。どんどんサイズが大きくなっていく。バッテリー容量で言えばダンボーは Anker の半分なんだもの。納得のコンパクトさ。ダンボーは、iPhone なら 2 回は満充電できるはず。使い勝手、良いよね。

もらったものは使ってナンボ、ってのはあるけれど、貰い物を傷つきやすい鞄の中に放り込むのは抵抗があって、ダンボー君は今で待機状態。メイン機は Anker になっている。白いのが Mac や iPhone と色のマッチングが良くてね (バッテリー容量はあまり気にしていない)。

おしゃれなお出かけがあったら、ダンボーを持って行きたいな。素敵なプレゼントをありがとう。あと、よつばと、読みます。

2014-04-14

よつばとのマグカップ — アクトインディ送別会でのプレゼント 1

よつばと! マグカップ (牛・300ml)

2014-03-31 をもってアクトインディ株式会社を退職した。3/28 に会社の人達が送別会を開いて下さり、プレゼントを頂いた。そのうちの一つがマンガ「よつばと」のマグカップだった。会社でコーヒーを飲んでいたのが印象に残ったのかな?

さて、ぼくは「よつばと」を読んでいない。なぜ「よつばと」のマグカップなのか。これは、マンガも読みなさい、というお達しなのかな?

サイズは 300ml ということで、ぼくが愛用している Amazon のマグカップ (380ml) より一回り小さい。

【Amazon.co.jp限定】Amazonオリジナルマグカップ白
【Amazon.co.jp限定】Amazonオリジナルマグカップ白

今回、記事にするに当たりネットで価格を見たのだけど、これ 2,680 円もするのね! びっくり。家用に置いておこ。家ではコーヒーは飲まないけれど、サイダーを飲みながら、音楽を聴きつつ、本を読むのがぼくの至福の時の一つなので、そんな時に活躍してもらう!

素敵なマグカップをありがとう!!

2014-04-10

複数の Github アカウントを使う方法

GitHub は一人が複数のアカウントを持つことを良しとしていない。とはいえ、何らかの事情で複数のアカウントを取得する人もいると思う。例えば、個人と会社でアカウントを分けなければいけない場合など。

ここでは仮に ataka-private と ataka-work という 2 つのアカウントを取得した場合を考えてみる。

デフォールトは仕事用

仕事用アカウントで big-project リポジトリーを作成したとする。この場合、git clone/pull/push は次のようになる。

$ git clone git@github.com:ataka-work/big-project.git
$ git pull git@github.com:ataka-work/big-project.git
$ git push git@github.com:ataka-work/big-project.git

仕事用の設定は特に問題ない。ところが、同じ様に ataka-private アカウントに git でアクセスすることが出来ない。

プライベート用の設定

まず、プライベート用の ssh キーを作る。

$ ssh-keygen -C ataka@private

デフォールトでは id_rsa というファイル名になるけれど、ここは id_rsa_private という名前に変えておく。github の ataka-private アカウントに id_rsa_private.pub の中身を登録。

ataka-private アカウントにアクセスするのに、id_rsa_private を使う様、~/.ssh/config に次の設定を追加する:

Host github.com-ataka-private
  HostName github
  User git
  IdentityFile ~/.ssh/id_rsa_private

ataka-private アカウントにある misc プロジェクトを git clone してみよう。github が推奨するように remote を設定する。ただし、github が提示する URL に一つ変更を加える。

$ git remote add origin git@github.com-ataka-private:ataka-private/misc.git

これで、clone/pull/push が出来るようになる。

$ git clone git@github.com-ataka-private:ataka-private/misc.git
$ git pull origin master
$ git push origin master

アカウントの数が増えても、同様に対処していけばいいだけ。

あとがき

ここでは仕事用をデフォールトにしたけど、逆にしてしまっても良いし、.ssh/config に仕事用の設定を追加してもいい。ま、どうしても複数アカウントを作らなきゃいけない場合に参考にして頂ければ嬉しい。

ref

2014-04-02

最近の rbenv (2014-04)

rbenv を使うと複数バージョンの Ruby を入れられる。過去にも一度記事にしたけれど、最近、少し使い方が変わったのでもう一度書く。

準備

Debian 系では下記パッケージを事前にインストール。

$ sudo apt-get install build-essential libreadline-dev libssl-dev zlib1g-dev

OS X では XCode Command Line が入っていれば大丈夫... かな?

rbenv インストール

rbenv は git リポジトリーからインストールする。

$ git clone git://github.com/sstephenson/rbenv.git ~/.rbenv

Bash の場合、設定を .profile と .bashrc のどちらに書くか難しい。.profile はログイン時のみ読み込み、.bashrc は bash 起動時に読み込み。screen で複数のスクリーンを起動する場合、.bashrc に設定を書いておかないと、新しいスクリーンで rbenv の設定が読み込まれない。

ところが、Debian 系が用意している .bashrc には非対話で呼ばれた時に、後ろの設定を無視するコードが入っている。これは sudo で呼び出した時に rbenv の設定が読み込まれず困る。よって、設定を書くなら、.bashrc の最初に書くのが良い。というのが、今のぼくの結論。

export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

ruby-build のインストール

最近の ruby-build は ~/.rbenv/plugins ディレクトリー下に入れるのが主流らしい。

$ mkdir -p ~/.rbenv/plugins
$ git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

ruby と bundle のインストール

ruby をインストールする。

$ rbenv install -l
$ rbenv install 2.1.1
$ rbenv global 2.1.1
$ rbenv rehash

bundle もインストール。

$ rbenv exec gem install bundle --no-ri --no-rdoc

あとがき

rbenv の設定ファイルの書き方にハマったので説明を加えたのと、ruby-build のインストール方法が変わったので記事を書き直した。bundle を gem install bundle するのと rbenv exec gem install bundle するので、どう違いがあるのか実は分かっていない ^^;

2014-04-01

ChatWork に入社しました

2014-04-01 (火)、本日よりチャットワーク (ChatWork) 株式会社に入社した。チャットワーク社は「チャットワーク」というサービスを運営している。サービスとしては、Skype や LINE らと同種の「チャット」サービス。企業でも使える「使い勝手」「安心感」が本サービスの売りか。

退職前夜

前職アクトインディで iPhone アプリを開発していたことは、昨日の記事で書いた。

実を言えば、ヘッドハンティング的なお誘いは数件来ていた。でも、iPhone アプリを開発していた時のぼくは、その誘いを断っていた。iPhone アプリ開発は決して楽しいことばかりじゃなかったけど、少しずつ改良されていく手応え、整っていく開発体制、何より一から育てたアプリの成長を見るのが嬉しかった。

作っている作品の質が悪くないことは自分が分かっていた。

認知率は低かったけれど、一つきっかけさえ在れば... という思いがあった。

そして運命の 11 月。隣でサービスを開発してたエンジニアが、メールで送られた「アプリ開発中止」の知らせを教えてくれた。心に穴が開いた。

その後、何度か保守目的で iPhone アプリのソースコードをいじった。

楽しかった。

iOS アプリの開発をしたい。

思いが強くなった。

転職活動をしてみた。

数社当たったところで、仕事の方が忙しくなり転職活動はなりを潜めた。それが去年の末のこと。

ChatWork との出会い

1 月に入って、ChatWork から連絡が入った。昨年末に面接を受けた結果だった。

驚いたことに面接に受かっていた。

次は二次。

ChatWork では二日間の体験入社を経てスキルと人柄とのマッチングを見る。初日午前中はセッティングや会社概要の説明ビデオ。そしてランチ。ゲストは食事が食べられない、と恐れられるランチ。エンジニア陣に囲まれて質問を受けながら食事を食べる。この時、用意されたお弁当を間違えて取ってしまったのはここだけの話。内容は、現職 (アクトインディ)、前職 (JVC ケンウッド) に及び、Emacs 使い・Dvorak 配列・T-Code と脇道に逸れたり、組み込み系のプログラミングの話に喰いつく人があったり、とこちらも随分楽しむランチとなった。もちろん、お弁当も完食。

午後からはプログラミング実習。課題を出されて、コーディングをする。そのリポジトリー名を見てひっくり返った。「deep-dive」。深く潜る者。

ぼくは...何をした? ランチでとてつもなくハードルを高くしてしまったらしい。

社内の雰囲気は良かったけれど、外は危険な天気となっていった。

いや、マジで。

体験入社二日目は 2014-02-14 (金)。あの東京大降雪の日。ChatWork に向かって電車に乗ったところ、一駅も進まない内に電話が鳴った。

「今日の体験入社はリモート作業でお願いします」

ですよね〜。

雪のおかげで、お昼に出かけるのも大変だったし、自作プログラムのプレゼンテーション時間が早まったりしたしで困った。今だから言うけれど、プレゼンが終わった後、落ちたと思ってほうけてた。「YES」という答えが信じられなかった。

最終面接を経て、ChatWork への転職が決まった。

あとがき

体験入社二日間。これはとても面白い試みだった。実際に社内に入って、仕事をしている姿を見せる・見る。ぼくもこれならば... と思えた。ChatWork もぼくを採ってくれた。

今、自分の実力を見るに、まだ経験値が低い。ちょっと作りたいアプリもあることだし、自作アプリも作って経験を増やしたい。願わくば、人がワクワクできるアプリを会社でも個人でも作っていきたい。

アクトインディの面白制度

2014-03-31 (月) をもってアクトインディ株式会社を退職した。半年で社員数が 3 倍に増える激動の一年を過ごせたことをありがたく思う。

さて、アクトインディで残念だと思ったことがある。それは、自分達のマーケティングが下手なこと。例えば、エンジニアの募集をする。募集要項を書く。その募集要項が他社と比べて魅力的に見えない。拙い筆ではあるけれど、アクトインディの面白い制度・便利な制度を紹介するとともに、ぼく自身のコメントも加えてみたい。

エンジニア向け制度

自宅勤務 (リモート作業) 制度

週に最大 2 回、自宅で作業できる制度。周りとの連携を考えて、大抵その週の初めに申請を行なう。もちろん、会社に出る方が効率の良い場合は、自宅勤務する権利を使わなくても良い。

ぼくは、この制度を少し変型させて、ゴールデン・ウィークに利用させてもらったりもした。お蔭で、普通の人より長期の帰省をすることができた。帰省先でも仕事が出来る仕組みは有難いものだった。

リモート作業については、過去に一つ記事を書いているので、そちらも参照して欲しい。

ちなみに、現在はママさんデザイナーが一人社員に居て、その方は週 4 程の自宅勤務をしている。

最新の Ruby と Rails

サービスの開発は Ruby on Rails を使っている。この場合、Rails が枯れてきてからアップデートする派と、常に最新を追っている派に別れる。アクトインディは後者で、Ruby も一早く 2.0 を採用したし、今は 2.1 系に移行している。Rails も 4.1 系へ移行が進んでいる。

チケット駆動開発

Redmine にチケットを登録し、マイルストーンを管理している。

Redmine を使うと、どうしても「ウォッチャー」のメールが大量に飛ぶことになるけど、その解決策をぼくは見出せなかった。とはいえ、「チケットにない作業は闇作業」という文化は根づいているので、混乱は小さい。編集・営業・デザイナーといった人達も Redmine を使ってチケット起票してくれる文化が育っている ((プログラマーだけしか Redmine を使っていないのと、周りの人達全員が Redmine を使っているのとでは、随分と作業効率違うよね)。

テスト・ファースト

テスト駆動開発を採用している。

シナリオ系のテストは少ないかな? モデル系のテストはほぼ書いている。

Github フローとレビュー

チケットに対して 1 つのトピック・ブランチが作られ、trunk ブランチに取り込まれる際にレビューを受ける仕組みが出来ている。

これは最初のトライ。レビューはほぼほぼ良い感じに動いている。レビューを取り入れが前までは git flow を使っていたけれど、今は Github フローに変えようか... と移行作業中。

技術書購入

月三万円までエンジニアで技術書を購入できる。

この制度は、デザイナーさんも含んでいるのかな? ちょっと覚えていないや。

出勤時間の自由化

一応、コア・タイムはある。でも、コア・タイムは短め (10:00-15:00 だったかな?) で、8 時間働けるなら何時に出社しても構わない。ただし、事前に「何時に出社する」という約束をする必要はある。フレックス制度というよりも、社員一人一人に対して会社が出社時間の契約をしている感じ。

ぼくは、朝 7 時出社の 16 時退社で働いていた。会社から家まで遠いのと、田園都市線の (有名な) 混雑を避けるのを考えたら、出社時間がこんなになってしまった。朝型のぼくにはありがたい制度だった。もちろん、会社では一番出社。何故か掃除のおじさんと仲良くなってしまった。

定時退社する日に限って、帰りの電車の遅延に巻き込まれるジンクスあり。ちょっち涙。

リスペクト手当て

4 か月に一回、尊敬・感謝の言葉を伝える制度。ネガティブなことは書かないのがルール。コメントは匿名で対象者に知らされる。

言葉を伝えると伴にポイントも渡せる。持ちポイントは 1 人 100 ポイント。1 人に 100 ポイント上げても良いし、適当に配分しても構わない。ポイントに対してその期の業積に応じた手当給が付く。

部門間を越えた 360 度評価と言っても良いかもしれない。

人数が 10 人前後だった時は、とても良い制度だった。考えるコメントの数も 10 個で良かったし (書く書かないは個人の自由)、ポイント配分も楽だった。100 ポイントを 10 で割れば 10 ポイント。特にお世話になった人に 20 ポイント、その他の人は 5 ポイント... という風に傾斜を付け易かった。

人数が 30 人に増えると大変。30 人分のコメントを書くのは一仕事。コメントする言葉が見つからない人も出てきてしまった。そもそも仕事で絡まないと、リスペクトも何もない。ポイントも 100 ポイントを 30 で割ると 1 人頭 3 ポイント。傾斜を付けつつ、全員にポイントを上げようとすると、1 ポイントしか上げられない人とか出てきちゃった。

それでも、この制度。ポイントはなくても良いから、メッセージだけでも貰いたい・あげたい、という程人気だったりする。ぼく自身、部門を越えたメッセージをもらうと元気が出た。なくならないで欲しい制度だけど、一工夫必要な仕組みだとぼくは思っている。

お墓参り手当

アクトインディでは先祖・先達への感謝を大事にしている。墓参りもその一つ。

最近、墓参りに行く若者が減ってきたということもあり、こういう制度は面白いと思う。基本、自己申告制だけど、多くの人は、墓参りの様子を Yammer などに投稿している。そこから、墓参りの地方による違いなどに話題が広がったことも。

カフェ手当

作業環境を変えたい人向けの制度。忘れられた制度。

新しいオフィスになって、一人で立ち作業できるオシャレな空間が用意された。作業環境を変えたい人は、カフェなどに行かず、スタンディング・テーブルで作業している。

あとがき

以上、アクトインディの面白制度を紹介してみた。同じ制度を導入している会社もあると思うけど、こんな制度もあるのか。うちも取り入れてみようかな? なんて考えてくれたなら嬉しい。

2014-03-31

アクトインディ株式会社を退職しました

2014-03-31 (月) をもって、アクトインディ株式会社を退職する。最終出社日は 3/28 (土)。

入社から 1 年 1 か月。短いようで、激動の 1 年だった。少し振り返ってみたい。

ぼくの経験した 1 年間

2013 年 3 月の入社時点。アクトインディの東京オフィスは 10 人程度のメンバー構成だった。

当時のエンジニアはぼくsi除いて 2 人。うち一人は、ぼくの入社と交替するように退職した。また、ぼくの入社から 2 日遅れで新しいエンジニアが入った。結果、3 人のエンジニア体制が半年ほど続く。

5 月、大きな変化が訪れた。メイン・サービスである 子供とお出かけ情報「いこーよ」 を大きく成長させることになった。サービス拡大のために人材を積極的に採用し始めた。人が増えたことでオフィスが手狭になった。そして、新オフィスへ引越をした。5 月半ばのことだった。前オフィスと比べて 3 倍くらい広いように感じた。

積極的な人材採用は 11 月頃まで続いた。結果、社員数は 10 人ちょっとから 30 人近くに膨れ上がった。ほぼ半年で 3 倍の社員数になった。ママさんを主体とする「ママさんチーム」が生まれた。紙媒体で活躍していた人達を採用して、「編集部」が発足した。デザイナーも 1 人から 4 人に増えた。エンジニアも 3 人から 6 人に増えた。ディレクターも採用され、「開発」の組織化が進んだ。

オフィスの引越と、急激な社員数増化という「変化」の中に居られたのは、とても貴重な経験だった。

エンジニアとして...

ぼくは 4〜11 月の間 iPhone アプリの開発担当者として働いた。最初のバージョン 1.0 はリリースが遅れて 8/21 だった。その後数回のバージョン・アップを繰り返し、バージョン 1.1.2 が 11/15 にリリースされた。

この開発で一番大変だった出来事は、iOS 7 のリリースだった。ぼくはネイティブ Objective-C で開発していたけれども、様々な変化にとまどった。対応に手こずった。iOS 6 と iOS 7 の両方をサポートするのは大変だった。デザイナーには iOS 7 の「新コンセプト」の説明が必要だった。そのために Yahoo! の勉強会に参加し、スライドを作った。

このスライドを SlideShare にアップしたところ、それなりの反響があったので嬉しかった。

バージョン 1.1.2 を最後に iPhone アプリの開発がストップ。ぼくは いこーよ (Ruby on Rails) の開発に移った。

いこーよの開発において、Ruby on Rails だけでなく、Chef や VirtualBox, Vagrant, Nginx, AWS などに触れることが出来たのは楽しかった。

また営業やママさんチーム、経理の方などから PC の使い方について質問を受け付けるのもエンジニアの役目だった。セキュリティ・ソフトのアップデートに失敗するといったものから、ファイル・サーバーに繋がらない、無線 LAN の調子が悪いといった幅広いリクエストの受け口になった。一つ解決して「ありがとう」と言われるのは、嬉しいものだった。

そして、退職...

iPhone アプリの開発が止まって心に穴が開いた。保守案件で iPhone アプリのソースコードを触る時、楽しかった。iPhone アプリの開発を続けたいという要求が強くなった。

幸運にも、お互いのニーズがマッチする会社と出会えたので、転職する。転職先については、また改めて記事にしたい。

2014-02-10

Ubuntu ですぐに画面ロックする

Ubuntu 12.10 を使っている。諸事情で、離席時にはパスワード入力するよう求められるようになった。最初、サスペンドするコマンドとサスペンドから復帰する時にパスワードを求める設定を加えようと思ったけど、画面ロックする方が楽と分かったので方針を転換した。

画面ロックから戻る時に、パスワード入力を求めるようにする設定は簡単なので省略。

Gnome を使っているなら、次の実行ファイルを path のある場所に置く。ぼくは ~/bin/lock という名前にした。実行権限を与えるのを忘れずに。

#!/bin/sh
lock='gnome-screensaver-command -l'
$lock

これで lock コマンド一つで画面ロックがかかる。コマンド名を l だけにしようかと思ったけど、タイポした時悲惨そうなので止めた。

サスペンドと違って画面ロックは管理者権限が要らない。sudo なしで実行できるのは安全かつ楽。

ちなみに、

  • Ctrl + Alt + L

で画面ロックをかけることができる。ぼくは... このキーバインドを Emacs でいつか潰しそうな気がしたので、lock コマンドを作った。このエントリーを書きながら、何度か試したけど、Ctrl + Alt + L の方が便利かもしれない。

2014-02-06

Emacs の TRAMP を使って他のサーバーにアクセスする

最近、Emacs の TRAMP にお世話になっているのでまとめておく。

Tramp は Emacs からリモート環境 (リモート・サーバー) にアクセスする機能・パッケージ。Emacs 22 からデフォールトに含まれた。使い方はファイル・オープンの延長。

remote サーバーのファイルを開く

設定は必要ない。

  • アクセス方法: ssh
  • ユーザー: foo
  • サーバー: bar.com
  • ファイル: /home/foo/.bashrc

上記のファイルを編集する場合。C-x C-f (M-x find-file) から、次の様に入力する:

Fird file:  /ssh:foo@bar.com:/home/foo/.bashrc

これでパスフレーズが聞かれる。authorized_keys をちゃんと設定していれば、パスフレーズ入力なしでファイルを開ける。

ssh の前に / を置くのがポイント。あとは、ssh でログインしている人にはおなじみかな。

ぼくは直接ファイルを開かず、Dired を起動している。

Fird file:  /ssh:foo@bar.com:/home/foo/

こっちの方が、サーバーの中で動き易いから。

TRAMP を使うと、サーバーに Emacs が入っていなくっても問題ないし、サーバーに -X オプション付きで ssh ログインする必要もないし、ssh でログインしてターミナル版 Emacs で作業する必要もない。便利!