2015-02-19

fcopy.el を MELPA に登録した

Emacs 用のコピー・パッケージ fcopyMELPA に登録した。

fcopy とは?

奇妙なコピーという意味で Funny Copy と名付けた。略して fcopy。

普通のコピーは「コピーする対象」を「コピー」してから「貼り付け場所」に移動して「ペースト」を行なう。

fcopy は手順が逆になる。今、カーソルのある場所が「貼り付け場所」。先に「貼り付け場所」が決まってる。この前提で fcopy コマンドを実行 (M-x fcopy) すると、「コピーする対象」を探す・選択するモード (fcopy-mode) に移行する。「コピーする対象」を選んで RET を押すと、「貼り付け場所」(fcopy を始めた場所) に自動的に戻って「ペースト」が実行される。

対話的に「挿入」を行なう、とも言える。interactive-insert とかに名前を変えようかと思ったけど、ぼくの意識は「挿入」よりも「コピー」なので、fcopy という名前を使い続けてる。

fcopy-mode では、いくつかワンストロークのコマンドも用意している:

  • バッファーへの書き込みは禁止され、誤編集ができなくなる
  • 代わりに SPACE キーでスクロール、f キーでワード単位の移動、. (ピリオド) でマーク
  • ( で括弧単位のコピー (括弧含む)、) で括弧の中身のコピー
  • C-g で元の場所に戻って fcopy の終了、q でその場で fcopy の終了

詳しくは、過去記事 clmemo@aka: Fcopy.el ver.6.0 リリースataka/fcopy の README をどうぞ。

インストール

Emacs 24 系なら MELPA からインストールできる。

MELPA の準備:

(require 'package)
(add-to-list 'package-archives '("melpa" . "http://melpa.milkbox.net/packages/") t)
(package-initialize)

M-x package-list-packages でパッケージ一覧を取得して、fcopy を探して RETInstall ボタンの上で RET。これでインストール終了。

適当なキーに割り当てる:

(global-set-key "\C-ck" 'fcopy)

もし古い fcopy.el があるようなら、消除を忘れずに。

過去からの変更点

MELPA に登録したことで、バージョン番号を 7.0 へ上げた。主な変更点は 2 つ。

  • fcopy というコマンドを用意した (もう fcopy-mode は直接呼ばない)
  • fmodify というペースト直前に編集を行なうコードをなくした

あとがき

fcopy は、今やぼくが Emacs を使う時になくてはならないパッケージになった。今まで、新しい環境に移るたびに fcopy.el をダウンロードしてインストールしていたけれど、Emacs のパッケージ・システムを使えばそんな手間をかける必要もなくなる。

修正も github に push すれば、他の環境にパッケージ・システム経由でアップデートできる。便利になった。自分が一番喜んでいる。

これからは、古い Emacs でも動くようにコードをレガシー対応させるつもり。というのも、以前、リモートでログインした環境に Mule 2 (Emacs 19 相当) しか入ってなくて泣きそうな目にあったから。他のパッケージは最新 Emacs で動けばいいと割り切ってるけど、fcopy だけはどの環境でも動いてくれないとぼくがツラい。緊急性は低いので、ゆっくりやってくつもり。

もちろん、他の機能強化項目があれば手を付ける。

Funny Copy。どうぞ、よろしく。

2015-02-14

iOS オールスターズ勉強会、参加メモ #dotsios

2015-02-14 (土) に開かれた iOS オールスターズ勉強会に参加したので、発表内容の簡単なメモを残しておく。

既にまとめもあがっているのでリンク。

Adaptive Collection View (LINE, 石川)

Adaptive = いろんな端末に対応。

UITableView と UICollectionView が似ているので、使い分けるより UICollectionView だけで UI を設計してしまえば iPad, iPhone 対応が手軽にできる。iPhone は UITableView, iPad は UICollectionView で作成することが多いけど、同じコードを二回書かなきゃいけないことが多い。UICollectionView を上手く使えば、画面サイズに応じて小さな分岐を入れるだけでコードを一つにまとめることができる。

Swift で使いやすい API を考える (ユピレジ, 岸川)

KeychainAccess という自作ライブラリーを例に Swift から加わった機能の説明など。

struct 型は不変な class という促え方をしてて目から鱗が落ちた。Swift は型が非常に厳密なので、Optinal 型を使わない設計が良いかも。デフォルト引数は良い機能だけど、補完がいまいち (XCode の要改善点?) なのと、フレームワークを作る時にデフォールト値がユーザーに伝えられないので困る。戻り値のオーバーロードは、キャストが必要になるのでリズムが悪い。エラー処理の戻り値は Either 型で success or error を返す。Playgroud を付けてライブラリーを提供すると、ユーザーに優しい。Functional style API は書けなくはない程度なので、普通の API と並録する方がよさそう。等々。

let UIWebView as WiKiWebView (ヤフー, 佐野)

iOS 8 以降から使える WKWebView と iOS 7 以前でも使える UIWebView を同居させなきゃいけなくなった時に、最小の修正で切り抜けるノウハウの紹介。

通信のパフォーマンス改善 (Wantedly, 杉上)

Wantedly は海外進出する! (らしい) ので、低速回線での使用を考慮に入れた開発を行なった。その技術分析と対処のノウハウ集。

New Relic Mobile の分析は大雑把すぎたので、square/PonyDebugger を利用。使ってない通信があること、画像の通信量が多いことなどが分かった。ボトルネックを見つけて潰すと、また別のボトルネックが見つかるので、それを潰す。

rs/SDWebImage が素晴らしいが、まだまだ便利な機能があることを皆知らない。WebP に対応している。SDWebImagePrefetcher で画像の先読みができる。SDWebImageOptions で画像取得の優先度を 3 段階で付けられる。画像取得のキャンセルができる (遷移前のビューの画像を取っているケースなどに有効)。等々。

WebP は pod で SDWebImage/WebP で取得できる。サーバーが大変。嬉しいことに、docker を用意して公開している。

AsyncDisplayKit と仮想 View について (Glee, 矢口)

大原則は「やることを減らす」。通信コストの削減。サーバーに処理を任せるのも手。API 共通化・REST にこだわらないのも良い。

WatchKit を実際にさわってみてわかったこと (フリーランス, 堤)

WatchKit 初見は意外と出来ない子。よく見てみると、それほど悪くもない。

animatedImage は、アニメーション用画像を配列で渡すとパラパラ漫画風アニメーションを実現。

話変わるけど、来月「iOS x BLE プログラミング 〜Core Bluetooth 徹底解説〜」という上を発売予定。Amazon では、まだヒットせず。

長生きするために心臓に悪いリリースはもうやめよう (Cookpad, 所)

Internal Testers はリリース・ビルドのアプリを審査前に小人数でテストできるので使おう。25 人、iOS 8 でしか使えないという弱点あり。

エンジニア戦記 〜 小さなチーム 大きな未来 〜 (クラスメソッド, 平井)

WebAPI の作成が難しい。iOS エンジニアも WebAPI の知識が必要。サーバー・エンジニアも分かってくれる。「1 Screen, 1 API call」。WebAPI を iOS エンジニアが分かってないと、炎上すよ。

まだ iOS でリッチな演出に消耗しているの? (カヤック, 布田)

アニメーションには iOS 7 から使えるようになった 2D ゲーム・フレームワーク SpriteKit が便利。あまり知られてないけど、UIView との親和性も高い。(0,0) の位置が UIView は左上なのに対して SKView は左下なので注意。軽いとはいわないが、描画領域を小さくして部品化すれば、十分実用点。アニメーションの作成 (Particle) はコードじゃないので、デザイナーに作ってもらうことも出来る。

あとがき

メモで書きなぐったことをのせただけ。一部、質疑応答でのやりとりも入れてある。

何人かの発表者はスライドを、講演前に公開していた。スライドを自分のペースで見ながら (自分が読み終わらない内に先に進まれても、手元にスライドがあれば安心して話が聞ける)、必要なポイントだけメモが取れて良かった。自分が発表する時の参考にしよう。

2015-02-10

EmacsLisp でマクロを使う (初級編)

EmacsLisp のマクロは byte-compile することで、ソースコードに埋めこまれる。マクロは defun の代わりに defmacro を使って書く。シンプルなマクロは、関数を書くのと変わらない。一点注意するとしたら、マクロは使われる前に定義しておくこと。

マクロの特徴の一つに、byte-compile 時に式を評価できることが挙げられる。一例として deprecated (廃止された) 関数の呼び出しを書いてみる。

関数を使う

Emacs は進化とともに廃止される関数がある。ここでは interactive-p という関数を取り上げてみよう。この関数は、関数がコマンドとして呼ばれた時は t を返し、関数の中から呼ばれた時は nil を返す。しかし、Emacs 23.2 で called-interactively-p という関数に置き換わった。

古い Emacs でも動作を保証するために、関数 called-interactively-p が存在する時はこれを使い、存在しないなら古くからある interactive-p を使う関数 foo-called-interactively-p を作る。自作の EmacsLisp では called-interactively-pinteractive-p を直接呼ばず、 foo-called-interactively-p を使う。

(defun foo-called-interactively-p ()
  (cond
   ((fboundp 'called-interactively-p) (called-interactively-p 'any))
   (t (interactive-p))))

この関数には気に入らない点が二つある。

  1. Emacs 23.2 以降でソースコードを byte-compile すると、 interactive-p は deprecated だと警告が出る
  2. foo-called-interactively-p を呼び出す度に、関数 called-interactively-p が存在するかチェックする

マクロを使う

foo-called-interactively-p をマクロで書き直してみる。マクロを使うと、byte-compile 時に評価が出来るので、 called-interactively-p が存在するか否かのチェックは byte-compile 時に行なえる。

また、マクロによって展開されたコードに (Emacs が 23.2 以降なら) interactive-p は含まれていないので、警告も出ない。Emacs の byte-compiler が出す「本当の警告」に集中することができる。

マクロを使って書き直したコードは次のようになる:

(defmacro foo-called-interactively-p ()
  (cond
   ((fboundp 'called-interactively-p) '(called-interactively-p 'any))
   (t '(interactive-p))))

byte-compile 時に評価するコードはそのまま書いて、残すコードを quote している。

試しに macroexpand を使って、このマクロを展開してみる (Emacs 24.4 にて評価)。結果は次の通り:

(macroexpand '(foo-called-interactively-p))
-> (called-interactively-p (quote any))

called-interactively-p を使うコードだけが残った。

あとがき

EmacsLisp では、C 言語より高度なマクロを書くことができる。使いすぎは毒だけど、適度に使えばとても便利。バッククォートと組み合わせると、更に便利になる。何か良い例題があったら中級編も書いてみたい。

ちなみに、今回紹介したコードは fcopy.el で使っている。

2015-02-05

Github で fork したリポジトリーをオリジナル・リポジトリーに同期させる

Github で milkypostman/melpa を fork して ataka/melpa を作った。

Pull Request を作って、本家にマージしてもらった。それから数か月経った。また Pull Request を作ろうと思った。ところが、ローカル・リポジトリーは最新じゃない。リモート・リポジトリーを pull しても意味がない。何故なら、リモート先はオリジナルのリポジトリーじゃなくて、ぼくが Fork したリポジトリーだから。Fork したリポジトリーをオリジナルに同期させなきゃいけない。

サイトを探したら、英語の説明があった。自分用メモとして訳しておく。

$ git remote add upstream git@github.com:milkypostman/melpa.git
$ git fetch upstream
$ git checkout master
$ git rebase upstream/master
$ git push origin master

upstream リモートを作って fetch。master ブランチで upstream/master を rebase。最後に push で Github に反映させる。以上。

Mac の Emacs で aspell

Mac 環境にて Emacs からスペルチェックする。

スペルチェックには ispell コマンドが有名だけど、最近、ispell の後継とされる GNU Aspell が気になったので、こちらを試してみた。

上記サイトを参考にした。上記サイトでは Mac Ports を使っているらしく、Homebrew の内容と混在していたので、Homebrew の設定だけを抜きだしてメモしておく。

インストール

$ brew install aspell --lang=en

設定

.emacs に aspell を使う設定を追加。

(setq ispell-program-name "/usr/local/bin/aspell")

~/.aspell.conf というファイルを作って、次の一行を書く:

lang en

以上で設定はお終い。

使ってみる

適当な英単語の上で M-$ (M-x ispell-word) してみる。間違ってたら、正解の候補が現れる。あとは、M-x ispell-buffer を知ってればいいかな。これはバッファ全体に対して ispell (この場合 aspell コマンド) を実行する。

これでスペルチェックができるようになった。よかった、よかった。

2015-02-03

GitHub Flavored Markdown でリストの中に code block を入れる

Github では Markdown (SM: Standard Markdown) を拡張した GFM (GitHub Flavored Markdown) が使われる。

リストの中でソースコードを書くのに手こずったので、メモしておく。

HTML で書くとこんなコードを書いて:

<ul>
  <li>This is test C code:
  <pre><code>int main(void) {
    printf("Hello World!\n");
    return 0;
}</code></pre></li>
  <li>secod item</li>
</ul>

次のような出力を得ることを期待している。

  • This is test C code:
    int main(void) {
        printf("Hello World!\n");
        return 0;
    }
  • secod item

GFM の code block

GFM には二種類の code block 書式がある。

一つはコードの前に 4 つのスペースを置く方式。GFM では non-fenced code blocks と呼んでいる。

    int main(void) {
        printf("Hello World!\n");
        return 0;
    }

もう一つはコードを ``` で囲む方式。GFM では fenced code blocks と呼んでいる。この方式はインデントしなくて済むのがメリット。

```
int main(void) {
    printf("Hello World!\n");
    return 0;
}
```

更に fenced code blocks では ```言語 という書式を使って言語のコードハイライトができる。

```c
int main(void) {
    printf("Hello World!\n");
    return 0;
}
```

リストの中にコード・ブロック

GFM ではリストの中にコード・ブロックを入れるのに 2 つの制限がある

  1. non-fenced code blocks しか使えない
  2. インデントは 4 ではなく 8

よって、本ページ冒頭に示した HTML コードを GFM で書くなら、こうなる。

- This is test C Code:

        int main(void) {
            printf("Hello World!\n");
            return 0;
        }

- second item

リストの入れ子とコード・ブロック

応用編。リストの入れ子にコード・ブロックを入れる場合、non-fenced code blocks のインデントは 16 になる!!

- This is test C Code:

        int main(void) {
            printf("Hello World!\n");
            return 0;
        }

  - C Header is required

                #include <stdio.h>

- second item

あとがき

当然のことだけど、non-fenced code blocks はコード・ハイライトに対応していない。口惜しいけど仕方ない。

Github のマニュアルはサラリとしか、この事を説明していないので、読み逃してしまう。おかげで README.md を 17 回も書き直してしまった。次回、同じコードを書くことになったら、また困りそうなのでメモとして残しておく。

2015-01-29

chatwork.el に To を補完入力する機能を追加した

拙作 chatwork.el に To を補完入力する機能を追加した。chatwork-send-message-in-region と一緒に使うことを想定している。

前提

ChatWork では相手を指定してメッセージを送ることができる。Twitter の @記法 のようなもの。To で自分が指定されたメッセージを受け取ったら、ChatWork 上の「To」タブにバッジが付く。

To の指定方法は簡単。チャットの送信領域から「To」をクリックして送信相手を選択するだけ。すると、送信フィールドに「To タグ」が挿入される。こんな感じ。

chatwork-to

ちなみに、複数の To を送りたい場合は Shift ボタンを押しながら。全員に To を送る場合は、「メンバー名を検索」の下にある「すべて選択」をクリックする。

設定方法

「名前」と「To タグ」のコンスセルを chatwork-room-member-alist に設定する。「To タグ」はウェブから実際に人を選択して現れた「To タグ」をコピペするのが楽。というか、それ以外に方法はないんじゃないかな。人の選択は「名前」で行なうけど、日本語入力をオン・オフするのは手間なのでぼくはアルファベットで入れている。

設定例はこんな感じ:

(setq chatwork-room-member-alist '(
  ("ataka"   . "[To:927811] 安宅 正之さん")
  ("someone" . "[To:123456] Mr. Foo")
  ))

これを .emacs にでも入れておく。

使い方

M-x chatwork-insert-tag-to で入力プロンプトが出る。「名前」を補完入力すると、カーソル部分に「To タグ」が挿入される。

適当なバッファに「To タグ」とテキスト本文を書き込んで、chatwork-send-message-in-region でチャットワークに送信する。そんな使い方を想定している。

あとがき

To の候補リストは自分のいる「チャットルーム」ごとに変わる。具体的には、「チャットルーム」に所属している人しか候補に現れない。

ぼくの方式では、「チャットルーム」にいない人にでも To が書けてしまう。送ったところで、チャットルームにその人はいないので、単なるテキストが送られるのと変わらないけど。

この方式の悪い所は、chatwork-room-member-alist が大きくなると、収拾がつかなくなること。これから送ろうと思ってるチャットルームに、その相手がいるかどうか分からない。

本当はルームを選択した上で、そのルームに含まれる人だけを候補に出す仕組みにしたかった。何でしかなかったかと言うと、そういうコードを書くのが手間で、それより先に、とにかく To を送る仕組みが欲しかったから! ちゃんとした To 送信の機能は、時間をかけて作るつもり。それまで、この簡易版でご容謝を。

Kinesis Ergo Elan のキーボード音をトグルする

Kinesis のキーボードはほとんど音のしないメカニカル・スイッチを使っている。けれど、デフォールトでは、打鍵時に「キー音」が出るようになっている (キーボードの打鍵音を「出す」キーボードというのをぼくは Kinesis 以外に知らない)。

自宅で使ってる時は「キー音」が心地良いのだけど、静かなオフィスでは白い目で見られることがある。

Kinesis の良い所は「キー音」すらオン/オフできること。悲しいかな、Kinesis Ergo Elan の説明書をどこかへやってしまったので、その設定が分からなくなってた。Kinesis のサイトにも Ergo Elan の説明書はもう置いてっぽい。困っていたら、メモを残しているサイトを見つけた。このサイトを見失ったら、おそらくもう一度辿りつくのは至難とる予感。リンクとやり方をメモしておく。

Program キーを押しながら [ キーを押すと「キー音」のトグルができる。

2015-01-28

Kinesis Ergo Elan (PS/2) を USB 変換アダプターを使って MacBook Air に繋ぐ

ぼくは Kinesis の Contoured Keyboard を 2 台持っている。モデル名で言うと、Ergo Elan と Advantage for PC & Mac。

Kinesis のキーボードは大きい。だから、持ち運びには難がある。2 台のキーボードは会社用と自宅用。といっても自宅の MacBook Air は軽さがウリのノート PC なので Kinesis を繋いだことはなかった。状況が変わったのは昨日のこと。ウィルス性胃腸炎をやってしまったので、会社の PC を自宅に持って帰って在宅勤務することになった。それも 1 週間以上。会社には愛用 Kinesis Advantage を置いておき、家にある Kinesis Ergo Elan を繋ごうとした。

ここで問題点が一つ。ぼくの持ってる Ergo Elan は旧き良き時代の PS/2 端子。一方、MacBook Air は USB か Bluetooth でキーボードを接続するのが主流なマシン。このままでは、Ergo Elan キーボードを MacBook Air に繋げない!!

USB-PS/2 コンバーター・ケーブル

そこで引っぱり出してきたのが、サンワサプライの USB-PS/2 コンバーターケーブル USB-CVPS1

Untitled

PS/2 端子を USB に変換してくれる代物。去年、こんなこともあろうかと購入したっきり、忘れていたものだった。備えあれば憂れいなし。

この手の変換アダプターは相性問題とかあって、実際、使ってみるまで正常動作するか不安があるのだけど、幸い大きな不具合なく動いている。マウスの右クリックの調子がおかしいように感じるのは、気のせいか?

流石に会社の仕事をするのに長時間タイピングするとあっては、Kinesis キーボードなしだと (ぼくは) ツラい。Ergo Elan は PS/2 端子しかないので、もはや最新の PC には使えないかと危惧していたけど、そんなことはなかった。

一つ残念な点を挙げれば、Ergo Elan。Mac 対応じゃないのよね。Mac 特有の「コマンド・キー」が存在しない。コピーとかペーストとかには、マウスや MacBook Air のキーボードを使って凌いでいる。ほとんどの入力作業を Emacs でやっているから、それほど不便は感じないんだけどね。やはり、このキーボードは Linux に合わせるのが一番なのかなぁ。

2015-01-26

今日から 7 日間、在宅勤務

今日 (2015-01-26) から 2015-02-03 まで、7 日間、在宅勤務となった。

理由は遡ること一週間ほど前。2015-01-18 の早朝に吐いたことから始まった。ウィルス性胃腸炎だった。2 日会社を休み、なんとか出社。悲しいかな、一人、また一人と胃腸炎で臥せる人が出てきた。

2 人目の病人は、ぼくが会社を休んでる間に病気になったので、ぼくがうつしたのではない、と信じたい (潜伏期間とか体力によって数日の差があったりするかもなので確証はないけれど)。

で、どんどん感染していくのでコリャ、ヤバイね、と。

あと、この注意書きがショッキングだった。

治ったと思っても2週間はウィルスが便、嘔吐物で排出される。

ウィルス性胃腸炎にかかりました。子供にうつらないようにするポイント。 より引用

ぼくの体調は完調じゃないのに、ウィルスさんお元気ねぇ!!

これ以上、感染者を出さないためにも「2 週間の在宅勤務」。まあ、英断だよね。

ちなみに、会社の近くに引越してから初めての在宅勤務。歩いて 10 分ほどの位置にオフィスがあるのに在宅してる、ってのは何か不思議な気持ち。これだけ家とオフィスの距離が近いと、次に在宅勤務をするのは何年後かしらん。

良かったこと・悪かったこと

在宅勤務についての所見は、過去記事に書いてある。

今のぼくは、これ以上のことは書けないけど、この在宅勤務期間が終わったら何か記事を書くかも。

とりあえず、今日一日やってみての感想。

メリット
  • 部屋が暖かい
  • 自分好みの音楽聴き放題
  • お茶飲み放題

会社は部屋が広いので暖房がいくら強力とはいえ、暖まるのに時間がかかる。8 畳程度の (会社と比べて) 小さな部屋ならちょっとした暖房ですぐ暖かくなる。地味にメリット。

会社ではランダムに音楽を再生しているけど、家ではオーディオを使って音楽が楽しめる。音楽好きな自分にはたまらない。

会社では専らコーヒー派のぼく。緑茶もほうじ茶も飲むんだけど、会社と自宅の両方に全部をセットするわけにもいかなくて... リラックスできる環境は自宅だからこそ作れる。ただし、コーヒー/緑茶はまだ刺激が強くて飲めない。お腹がまだ本調子じゃない。これはツライところ。

デメリット

  • 机が狭い
  • 椅子がお粗末
  • 人さみしい

会社の机はやっぱり広い。ぼくの机は、キッチン・ワゴン! 狭い!! これに 24 インチのディスプレイと Kinesis のキーボードを置いたら、殆んどのスペースを取ってしまう。昔は大きな机を持ってたんだけど、扱いきれず引越のタイミングで捨てちゃった。

会社の椅子はイイ! パイプイスで 8 時間座るのはつらい。快適さだけを取れば、座椅子の方が快適なんだけど、その高さに合う机がなくてねぇ。それに、どうも座椅子で PC をタイプするのは、どうもぼくの性に合わないみたい。

そして一番のデメリット。初日にして。寂しい。オフィスとの距離が近いのも原因の一つかな。あんな目と鼻の先で、ワイワイガヤガヤやっている! それに交ざれないのが、なんとも切ない。

あとがき

体調はおかげさまで 9 割回復、と思って昨日、コーヒーをオーダーしたら随分、胃にこたえた。身体は正直ね。気力は 10 割。体調 6 割くらいなのかもしれない。コーヒーが好きなので、コーヒー飲めないのはもどかしい。