私をペロペロするがよい

lazy_dog のブログです。

foobar2000 for iOS に iTunes なしでバッチファイル一発で音声ファイルを転送する

foobar2000プラグインiPod manager (foo_dop.dll)が最新の iTunes のサポートをされなくなり、iPhone で楽曲を聴く場合には iTunes を利用しなければならなくなった。iTunes は全ての操作を GUI でやらないといけなく、しかも GUI がもっさりとしていて画面数も多い。私の環境では sync が上手くいかない事が頻発しており、非常に使い辛い。

しかも、ライブラリに登録できる曲は FLAC ファイルが NG で、トランスコードする場合、ローカルのどこかに iTunes で読める形式にしたファイルを保存し続けなければならない。これが結構、容量を食う。

iPhone で曲を聴くのはそろそろ限界かなと思っていた矢先、foobar2000 for iOS がリリースされた。開発中であることは知っていたが、正直、全く期待していなかった。が、これが非常に素晴しい完成度で、とても使いやすい。iPhone 純正のプレイヤーも foobar2000 for iOS のできが良いので、最近は全く使用していない。

難を言えば、デフォルトのスキンがアイコンなどヤボったく、見た目は純正プレイヤーの方に軍配が上がるが

  • FTP で楽曲が転送可能(iTunes 不要)
  • ReplayGain (iTunes でトランスコードすると ReplayGain タグが消される?)
  • 使いやすい GUI
  • 動作もさくさく

良い感じの仕上り。

なお、この Windows Mobile/Android/iOS でのプレイヤー開発って Peter がちゃんと開発しているようだ。最初は foobar2000 の名義貸しだけで、こういうの嫌がりそうな勝手な想像があったのだけども。

ftp で曲(音声ファイル)を転送するバッチファイル

を作った。foobar2000 から Converter で作成したファイルをフォルダごと FTP 転送する。

> foobar2000_ios_media_ftp_uploader.bat "C:\Path\to\Directory"

そこまで作り込みしなくてもいいとは思うけど、まだエラー処理が甘く、ftp 転送のところでエラーチェックはしていないので注意。

Windows ftp コマンド備忘録

Windowsftp コマンドを debug をオンにして使ってみると分かるのだけど、foobar2000 for iOSftp を使用する場合、どうも Windowsftp コマンドは少々考慮が必要のようだ。

例えば、Windowsftp コマンドにおける mkdirxmkd というコマンドを ftp サーバに実行している。これは foobar2000 for iOS では実行できないコマンドになる。なので、quote オプションで foobar2000 for iOS でサポートされている mkd を実行するようにしなければならない。

C:\>ftp
ftp> debug
デバッグ オン。
ftp> open 192.168.0.12
192.168.0.12 に接続しました。
220 PPFTPD all your base are belong to us
---> OPTS UTF8 ON
...

ftp> mkdir test1234
---> XMKD test1234
502 Unknown command
ftp> quote mkd test1234
---> mkd test1234
250 Create directory successful
ftp>

xmkdWindows における方言か、というとそうでもなく、"RFC 775" で標準化されている。 ref: https://tools.ietf.org/html/rfc775

rmdir なども。

ftp> rmdir test1234
---> XRMD test1234
502 Unknown command
ftp> quote rmd test1234
---> rmd test1234
250 Remove directory successful
ftp>

ftp コマンドは、実際に実行するコマンドとサーバに送信しているコマンドは違う、ということが分かった。

セーラー万年筆の「ふでDEまんねん」や「マイファースト」のレビューなど

このエントリーは、下記についてのレビューなどである。

以前、散歩がてら寄った文房具屋さんで、セーラー万年筆の「マイファースト」を購入した。

マイファーストという名前だけあって初心者向けであり、一本の胴軸にニブ(ペン先)が 2 本付いてくるものである。

万年筆練習。SCP-1678

lazy_dogさん(@ampll)が投稿した写真 -

恥ずかしながら以前試しに書いたものであるが、これがすこぶる良かった。

元々毛筆をやっていてたので、字を書く際の道具はどうしても毛筆で書いたときの書き心地と比べてしまう。個人的にはゲルインクのボールペンとは相性が良くって、インクのノリを指先でコントロールできるようにすらっと書けるのが良かったが、万年筆はそれがよりコントロールできるのがいい。万年筆のインクは潤滑や強弱が付けやすく、狙った感じに紙に書ける。おいらには筆圧も高い癖があるが、問題はなかった。

それから数ヶ月ほど色々書いてみたが、万年筆で字を書くことは楽しい。手入れやインク漏れという、ボールペンには無いデメリットはあるが、それ以上に書き心地という楽しさが勝る。

「マイファースト」が良かったところ

ケースや包装は残念ながらお洒落っ気のあるものでは決してない。 カクノ が「万年筆に触れたことのない」人を対象にしながら手に取ってもらいやすいデザインであるが、反面、こちらは超最低限のシンプルさである。胴軸に関しては、もうちょっとなんとかならんかったかと本当に思う。 しかし、マイファースト と名うっているだけあり、ニブのお手入れ方法を書いたマニュアルも同梱されている。インクも黒・赤(ピンク)・青と揃っている。黒を使いきった後に青を試してみたが、とても綺麗なスカイブルーで良かった。

セーラーの My First と特殊ペン先。万年筆のインクの青って綺麗ね。scp-2700

lazy_dogさん(@ampll)が投稿した写真 -

後述するが、ニブは 2 種類付いており、細字特殊ペン先 が付属している。

細字と特殊ペン先について

結論から言うと、それぞれとても書きやすい。高級万年筆と比較すれば不満はあるであろうが、初学者が初めて使った感想としては、何も不満はなく感動すら覚えるほどだった。

細字 はステンレス製であるので、カリカリとした書き心地である。ニブの先がつっかかるような感じがする分重く感じるが、筆圧を抑えて書くようにすればいい。潤滑も少々浮かせて素早く書けば狙ってかすれが出るが、基本的にはニブの細さという想像以上にインクがのる。

特殊ペン先 はお気に入りで、これはとてもいい。このニブのためにマイファースト買っとけ、と思うくらい。

f:id:lazy_dog:20161226182900j:plain

ニブの先は曲がっているので紙に刺さるのではなく、刷毛のように紙をなぞるように書くことができる。これの書き心地がとてもよい。強弱が付けやすく、また付っかかりがないので手首への負担がない。ゆっくり書けばインクが出るが、かすれは出ない気がする。太さ細さは出るが、殆ど抑揚は出にくいようである。

両方とも普段使いにはぴったりで、急ぎのメモ書きや会議の内容をノートに書くのも得意である。また、結婚式の準備の際には、両方とも大活躍だった。丁寧な字を書く分にもよい。

プロフィットふでDEまんねんふでDEまんねん(45度) について。

ふでDEまんねんの無印とプロフィットを比べる

セーラーの「プロフィット」と言うと安価帯のモデルから頭一つ抜けた、より上位のモデルとなる。普及価格帯でもあり、Amazon のレビュー数も多い。なので「プロフィットふでDEまんねん」は通常の「ふでDEまんねん」はより良いものなんじゃないか、と思うが、メモや通常使いには通常の「ふでDEまんねん」の方が良かった。

「プロフィットふでDEまんねん」は、ニブの先の曲がりである 55 度 という角度が人を選びすぎる。筆という書き心地を再現しようとするとこの角度になるらしいが、メモとしての字は太くなりすぎる。その分、強弱を付けることができるが、、、普通の万年筆の「強」はプロフィットふでDEまんねんにとっては「弱」になる。使い所は難しい。

f:id:lazy_dog:20161226182920j:plain

「ふでDEまんねん」はプロフィットより少々角度は浅く、ニブの先の曲がりは 45 度 である。恐らく、マイファーストの特殊ペン先と同等であるはず。筆としての書き心地は残念ながら分からないが、太さは常識の範囲内である。なので、こちらは普段使いできる。

横書きしたときの右に筆を滑らすときの横画に、マイファーストの特殊ペン先には無い微妙に重さのある付っかかりがあり、それが少々書き心地を落としている感じはある。しかし、マイファーストより強弱は出やすく、インクの潤滑も分かりやすい。マイファーストの「のっぺり」に対し、よりメリハリはある字が書ける。

今では、プロフィットの方の胴軸に無印の「ふでDEまんねん」のニブを付けて普段使いにしている。無印の「ふでDEまんねん」の胴軸は、もうちょっとどうにかならなかったのか、と思う。刻印なしの方が普段使いしやすいのに、どうしてこうなってしまったのだろうか。

Amazon では「マイファースト」のレビュー自体は多くはなく、他の初心者向けの万年筆に埋もれているが、とても良い万年筆だと思うので試してみてもらいたい。「プロフィットふでDEまんねん」はちょっと今のところ常用はできず、どうしようかと思っているが、また使う機会があれば。。。

あと、胴軸とニブをもっと自由に入れ替えられるようにできたらなあと思う。胴軸だけ単品で売ってくれればなあ。

Google Calendar と todo.txt を連携させた「todo-txt_gcaladd.sh」

TODO 管理を 2Do から todo.txt に替えた。todo.txt の場合、データファイルが通常のテキストであり、CLI のテキストユーティリティから参照や連携が容易。CLI で連携できるということで、Google Calendar と連携できるようにした。 下記、作ったスクリプトの紹介と使いかたについて。

todo-txt_gcaladd.sh について

  • due:yyyy-mm-ddgcal:on が入力されている行のタスクを、due:yyyy-mm-dd の日のスケジュールとして Google Calendar に登録する。
  • タスクがコンプリートした場合、具体的には todo.txtdone.txt に記載されているタスクの先頭に x が入力されたタスクについては、Google Calendar からスケジュールを削除する。 具体的な todo-txt_gcaladd.sh の動作は、下記「具体的に todo-txt_gcaladd.sh はどういう動きをしているのか?」項を参照。 色々テストはしているが、 うちの環境では きちんと動いている。"AT YOUR OWN RISK" でお願いします。

使用に必要なもの

$ gcalcli list でリスト一覧が取れれば問題なく動作すると思われる。

使い方

1. gcalcli をインストール及び設定

https://github.com/insanum/gcalcli の通り。

2. todo-txt_gcaladd.sh をインストール及び設定

https://bitbucket.org/lazy_dog/todo-txt_options/src からダウンロード願います。適当にパスが通るところなどに保存する。 スクリプト内の変数にオプションの指定があるので、下記の通り設定する。

## Temporary data directory
TMPDIR=/tmp

## Target calendar name
TARGETCALENDAR=TODOs

# todo.txt
TARGETTODOTXT=${TODODIR}/todo.txt

# done.txt
TARGETDONETXT=${TODODIR}/done.txt
  • TMPDIR=: 一時ファイルの作成ディレクトリ。 # アクセスできて write ができないと todo.txt が更新されないバグに、今これを書いている途中気付いた。。。
  • TARGETCALENDAR=: Google Calendar のスケジュールを登録するカレンダーの指定。
  • TARGETTODOTXT=: ターゲットとなる todo.txt へのパス。
  • TARGETDONETXT=: ターゲットとなる done.txt へのパス。

3. todo-txt_gcaladd.sh を cron に登録する

cron など自動実行ができるようにする。もちろん、手動で todo-txt_gcaladd.sh を叩くでも問題はない。

4. todo.txt へタスクを追加

todo.txt に Google Calendar と連携したい TODO を追加する。その行のどこにでもいいので、due:yyyy-mm-dd という形で日付を指定。gcal:on というオプションを付与する。ただし、上記 key:value の前後に半角スペースがないと上手く動かないと思うので注意。

図書館に本を返す due:2016-10-20 gcal:on

行頭に x が付いた完了タスクは、自動的に Google Calendar から削除される。

具体的に todo-txt_gcaladd.sh はどういう動きをしているのか?

todo.txt の内容を読み込み、Google Calendar にスケジュールをポストする。例えば、todo.txt に下記のようなタスクを追加したとする。

図書館に本を返す due:2016-10-20 gcal:on

due の日付は yyyy-mm-dd が必須とした。理由は SwiftoDo http://swiftodoapp.com/ という iPhone アプリが左記フォーマットの ISO 8601 https://ja.wikipedia.org/wiki/ISO_8601 を必須としているので、それに倣った。また gcal: という key に対し value が on でなければ連携は発動しない。 cron などで実行された todo-txt_gcaladd.sh は該当の行を確認し、gcalcli を使用して Google Calendar にスケジュールをポストする。

f:id:lazy_dog:20161016021713p:plain

スケジュールの詳細には tuid:.... という文字列が追記されているが、これが todo.txt と Google Calendar のスケジュールを紐付けている。また、この時 todo.txt の該当のタスクの行は下記の通り gcal: の value が uid に書き変わる。

図書館に本を返す due:2016-10-20 gcal:.5801c61eTa

タスクが完了した場合、todo.txt または done.txt の行の頭には x を付けるというルールがある。

x 図書館に本を返す due:2016-10-20 gcal:.5801c61eTa

todo-txt_gcaladd.sh は該当の行を確認し、Google Calendar から該当のスケジュールを削除する。同時に、該当の行の gcal: の value を done に変更する。

x 図書館に本を返す due:2016-10-20 gcal:done

todo-txt_gcaladd.sh が定期的に実行されれば、特に Google Calendar を手動で操作する必要はなく、全て todo.txt 側の操作のみで完結する。

余談: スクリプト書いていたときの雑多なこと

uid について

gcal:... 及び Google Calendar のスケジュールに記入される tuid:... について、ユニークな値をどうするか悩んだ。結論は、1970-01-01 00:00:00 UTC からの現在の秒数を 16 進数にし、それにランダムな文字 2 つとした。

GETDATE=`date +"%s"`
TODOUID=`printf '%x\n' ${GETDATE}`
TODOUID=`echo ${TODOUID}``cat /dev/urandom | env LC_CTYPE=C tr -dc '0-9a-zA-Z' | fold -w 2 | head -n 1`

兎に角、ユニークな値にしたかったので、処理時の時間であればユニーク値になるであろうとした。それを 16 進数にすることで桁数(文字数)を稼いだ。ただし、処理が早いから同じ秒で実行され、uid が被るという現象が確認できたので、/dev/urandom から 2 つの文字を持ってくることにした。 date コマンドでナノ秒を出すこともできるが、BSD 版の date コマンドでは使用できず。

# from "man date" from Cygwin
%N     nanoseconds (000000000..999999999)

uid の桁は単純に 16 進数ではなく、工夫すればもっと桁を稼げると思うが、とりあえずはこうした。

正規表現はどの環境でも使えるように

どのUNIXコマンドでも使える正規表現 - Qiita: http://qiita.com/richmikan@github/items/b6fb641e5b2b9af3522e

こちらの記事を参考に、正規表現を書くことを意識した。と言っても、下記ぐらいしか気をつけるべきところはなかったが。

  • 1 文字以上の繰り返しである + を使わず \{1,\} とした。
  • 最短一致は使用せず、その状態でもマッチするようにした。

他、半角スペース * などで繰り返しを行う場合、[ ] と指定して見易くなるように心掛けてみた。

三項演算子な書き方を多様してスリムにした

if で複数行に渡るのではなく、可能であれば三項演算子のような書き方を多様した。

## Is exist target todo.txt file
[ -e "${TARGETTODOTXT}" ] || { echo "Target todo.txt file could not be found."; exit 1; }
## check if ${line} is "^$"
### 2016-10-26: break だと while read の loop が終了してしまうので、continue に修正。
[ -z "${line}" ] && continue

ref: 初心者向け、「上手い」シェルスクリプトの書き方メモ - Qiita: http://qiita.com/m-yamashita/items/889c116b92dc0bf4ea7d

複雑なことでなければ、ワンライナーかつシンプルに記載ができる。 なお、{ CMD; }( CMD ) は違うことを意識する。 ( CMD ) はサブシェルであり、子プロセスとして動く。

# 上手く動かない
[ -e "${TARGETTODOTXT}" ] || ( echo "Target todo.txt file could not be found." && exit 1 )

上記は、|| 以降がサブシェルとして動いてしまうので、exit 1 はサブシェルである子プロセスの bash を exit するだけになる。そのため、後続のスクリプトも動いてしまう。

[ -e "${TARGETTODOTXT}" ] || { echo "Target todo.txt file could not be found."; exit 1; }

こちらが正解。

ref: bashの";", "&&", "||" に関する補足ネタ。コマンドグルーピングとの併用例 - Qiita: http://qiita.com/jpshadowapps/items/3f3fa3b214a998afd819

type コマンドでファイル(コマンド)があるかを確認

## Is exit gcalcli command
type gcalcli || { echo "gcalcli command could not be found."; exit 3; }

Bashでコマンドの存在チェックはwhichよりhashの方が良いかも→いやtypeが最強 - Qiita: http://qiita.com/kawaz/items/1b61ee2dd4d1acc7cc94

上記の記事に倣った。対象のファイルやディレクト/dev 以下のデバイスにも使えるので、これからも積極的に使っていこうと思う。

変数に格納した改行のあるテキストをヒアドキュメント(while read line)にする場合

while read line
do
    # check if ${line} is "^$"
    ## 2016-10-26: continue に修正
    [ -z "${line}" ] && continue


...

done <<< "${TARGET}"

この形式なら間違いなく処理してくれると思う。変数に空行が入っていても continue が聞くので、その空行は処理されない。色々試してみたが、これが一番シンプルで確実に動く。

ref: bash - How do I "read" a variable on a while loop - Stack Overflow: http://stackoverflow.com/questions/13122441/how-do-i-read-a-variable-on-a-while-loop

sed の -i オプションは使わない

有名な話であるが、sed コマンドの -i オプションは GNUsed のみであり、BSD 環境などでは使用できない場合がある。それを Twitter で呟いたら、perl を使用するという案を頂いた。

というご意見を頂いたのにもかかわらず、POSIX にこだわりたいというのがあったので中間ファイルを作るということで妥協した。perlPOSIX には入っていないようだ。

ref: POSIXコマンドチートシート(を作る) - Qiita: http://qiita.com/richmikan@github/items/e4cb1537d38966c10f4b

gcalcli の delete や search はスケジュールのタイトルのみならず、詳細も見てくれる

表題の通り。

~ $ gcalcli search "uid:1234abcd"

2016-10-15   9:00am  テスト "delete" me!

~ $ gcalcli delete "uid:1234abcd"

2016-10-15   9:00am  テスト "delete" me!
Delete? [N]o [y]es [q]uit: n

~ $ gcalcli --iamaexpert delete "uid:1234abcd"

2016-10-15   9:00am  テスト "delete" me!
Deleted!

~ $

のどかで Toggle 実行時にタスクトレイのアイコンを切り替え

変換キーを押すと Lock0 の状態にさせて、vi キーバインドのモードに移行するように設定した。その際、ノーマルの状態なのか vi の状態なのかが分からないため、タスクトレイのアイコンを変化させるようにした。例では 変換キー がトグルスイッチになっている。

# Set Lock0 vi-mode on
key *変換 = &Toggle(Lock0,on) &IconColor(2)
  key L0-J = ↓
  Key L0-K = ↑
  key L0-H = ←
  key L0-L = →

# Set Lock0 vi-mode off
key L0-変換 = &Toggle(Lock0,off) &IconColor(0)

vi キーバインドの状態であればトレイのアイコンは赤く、ノーマルの状態だと通常時の灰色になる。

通常

f:id:lazy_dog:20160811144340p:plain

vi キーバインド

f:id:lazy_dog:20160811144408p:plain

のどかは set VAR=xxx のように変数を入れることができないため、&Toggle を使うことで条件分岐できる。

参考

Ubuntu 14.04 + Chinachu で録画環境を作った (ACPI を利用して shutdown 状態から自動起動)

空いていたデスクトップマシンを 40 インチのテレビに HDMI で繋いで、テレビ録画環境にした。その時の構築ログ。

環境

  • メモリが DDR2 世代のちょっと古い PC
    • ただし、CPU は Q9550 で、メモリ 8GB なのでリソースは割と潤沢。
    • 割と新しめの AMD の安いグラボも積んでる。
    • 普段は Youtube とか Hulu を夫婦で見る用。
  • Ubuntu 14.04 64bit
    • PT3 を購入当時、まだ 15 系がリリースされてなかった。本当は systemd で管理したいので、こちらに移行したいのだが。。。

パーツ

PT3 と Gemalto のカードリーダを使用した。Gemalto のカードリーダは、当時 NTTcom のカードリーダがどこも品切れの状態で、しょうがなくこちらを選択した。

 # すさまじく、PT3 が値上りしている。。。

ちなみに、この Gemalto が結構くせもの。後述するように、安定稼動のためにはカードリーダのアプリケーションやライブラリに一手間を加える必要がある。

分配器とテレビケーブルは、適当に家電量販店で購入した。Amazon でも評判が良さそうなのが買えるので、こっちで購入することをオススメする。店で買うより安いし。注意しないといけないのは、部屋のテレビ出力口がテレビと BS 混在なのかそうでないかで分配器の種類が違うようだ。事前によく調べておかないと損するので注意。

1, 電源の自動起動と停止をできるように

Ubuntu が起動していないともちろん録画もできないので、自動で電源を起動させる仕組みにした。テレビの録画時間によって自動起動も考えたが、Chinachu との連携がめんどくさそうだったのと、録画したい番組は大抵 18 時以降のものが多いと考えて、指定した時間(18:00)に起動するような簡易な設定にした。

仕組みとしては、ACPI の機能を使用して電源を自動起動する。/sys/class/rtc/rtc0/wakealarm に起動したい時間をリダイレクトすると、その時間に shutdown 状態から電源が入る。ただし、BIOS が対応していることが必須。

wakePower.sh

このスクリプトを cron で 0:00 に実行するという、とっても簡素な仕組みだ。
シャットダウンも同じように時間決め打ちで、自動で電源が落ちるようにした。cron で shutdown -h now を走らせるというだけの愚直なもの。

shutdown.sh

これを毎日 1:15 に実行している。時間になったらテレビ見てないで、早く寝ろ、という心遣いを感じて欲しい。

2, ハードウェアアクセラレーションを効かして動画再生をできるように

録画した番組は VLC で見ている。しかし、普通に再生すると全て CPU 処理となってしまうので負荷が高い。具体的には 1 core をまるっと使いきる程度。せっかくグラフィックボードを積んでいるので、GPU ハードウェアアクセラレータを有効にした。

手順としては、

  1. プロプライエタリ版の AMD Catalyst Drive をインストール。Ubuntu の設定ダイアログから簡単にインストールできる。
  2. ハードウェアアクセラレータを有効にする AMD 向け VDPAU のライブラリをインストールする。ついでに Info を表示するツールも。
# apt-get install vdpauinfo libvdpau-va-gl1
  1. VLC の設定で、ハードウェアアクセラレータを有効にする。GUI で設定するか、 ${HOME}/.config/vlc/vlcrc の設定を下記のように変更する。
# Hardware decoding (string)
avcodec-hw=any

3. 普通に PT3 and Chinachu 環境を構築する

その辺のサイトをご覧ください。特別な設定なく、recpt1 コマンドが実行できるようにする。

4. pcsc-tools の最新版をソースコードからインストールする

NTTcom のカードリーダでは問題ないと思うが、Gemalto のカードリーダーでは Chinachu で録画すると、下記エラーが出て録画データが正常に再生できない現象が頻発する。apt-get でインストールできる pcsc-tools でも最初は問題なくても、そのうち変になる。

20 Dec 18:30:05 - #recpt1: b25->put failed b25_decode failed (code=-9). fall back to encrypted recording.

Gemalto のカードリーダーが B-CAS カードの読み込みに失敗して、デコードに失敗するようだ。その際、 pcsc_scan をすると、上手くカードを認識していない状態が確認できる。そのため、apt-get からインストールできる pcsc-tools ではなく公式サイトからソースコードを直接ダウンロードしてインストールしたほうがいい。

pcsc-tools http://ludovic.rousseau.free.fr/softwares/pcsc-tools/

普通に ./configure して make && make install すれば OK。"libusb.h" が見つからない、というエラーが出たら apt-get install libusb-dev で "libusb-dev" をインストールすればいけた。

5. あとは適当に cron

に登録する。

ターミナルでのキー入力最速計画

あらすじ

「なんかターミナルのキー入力が遅い気がする。」 蝉のように命は儚い。一瞬の無駄なディレイも、エンジニアには尊い時間なのだ。ストレスも塵も積れば人は死ぬ。

あらすじで言いたかったこと

本エントリーでは、ターミナルのキー入力環境を改善し、ストレスがないターミナル環境を構築するまでに至る経緯を記載する。なお、設定や dotfiles を調整し、バイナリは弄らない (弄れない) という方針。

環境

というよくある構成。

やったこと

iTerm2 から Terminal.app への乗り換え

なんか iTerm2 の描画が遅いなあ、と感じた。 Terminal.app の場合、少々つっかかりはあるものの描画はそこそこヌルヌルと悪くない感じだったが、iTerm はつっかかりがある感じ。文字の入力に描画が追いついていないようだった。 iTerm2 がいいところって

  • タブウインドウ
  • ACSII 文字とは別に 2 バイト文字のフォントを別途選択可能。
  • なんか細かく設定できるっぽい。

くらいしかなく、必要最低限機能が揃っている Terminal.app でなんら問題はなかった。 これにより、「なんか描画遅い」というストレスが解決した。

Karabiner でキーリピートの間隔を調整

Windows マシンでもやっているように、キーリピートの間隔を調整した。これは、Karabiner の "Key Repeat" タブから設定ができる。 現在、"Delay until repeat" は 225 ms で "Key repeat" を 15 にしている。 これがすこぶる快適で、キータッチが軽くなったような印象を受ける。 キーのリピート間隔と、リピートが始まるまでのディレイを調節する機能なので、カーソル移動や BS を押し続けている際、恩恵がある。

.zshrc に KEYTIMEOUT=0 の行を追加する

おいらは vi キーバインドを使用しているので、ESC キーは多用する。ESC キーを押す際、何かつっかかりがあってストレスだった。具体的には、ESC を押した際、画面が微妙に固まるような動きをする。 それもそのはず、デフォルトでは 10ms のディレイが発生しているらしい。

15.6 Parameters Used By The Shell http://zsh.sourceforge.net/Doc/Release/Parameters.html#Parameters-Used-By-The-Shell-1

KEYTIMEOUT The time the shell waits, in hundredths of seconds, for another key to be pressed when reading bound multi-character sequences.

このディレイを 0 にしてあげれば、ESC を押したときのストレスが軽減されるはず。

.zshrc

KEYTIMEOUT=0

tmux や vim にも

tmux の場合、

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1 escape-time time Set the time in milliseconds for which tmux waits after an escape is input to determine if it is part of a function or meta key sequences. The default is 500 milliseconds.

というように、ESC を押した後に特定のキーを押すまでにウェイトがかかるようだ。デフォルトでは 500ms。 ただし、この設定を 0 にしても個人的には体感できる実感はなく。。。記載の通り、"function or meta key sequences" のキーを押すような人には恩恵があるのかもしれない。 vim にも set timeoutlen= という設定があるが、tmux と同様に、モードの切り替えのタイミングなど特に遅いと実感することもなく、現状デフォルトのまま。

まとめ

こう書いてみると大したことがない設定をしているようだけど、実際、設定によりすごく快適になったので、万人に設定を是非見直してもらいたい。特に zsh の設定で KEYTIMEOUT の値を変更した際は、本当に感動した。今まで ESC を押したとき遅いなあ、と感じていたことが、キー入力に吸い付くようにターミナルの描画されるように感じたときは嬉しかった。

Windows NTFS 圧縮は便利なので積極的に使っていこう

れずれずアドベントカレンダー 3 日目です。表題の件、会社の Becky!Teraterm のログの貯蔵ディレクトリに NTFS 圧縮を使用しているけど、そこそこ圧縮してくれるので便利。

使っている、という声をあんまり聞かないので、今回はこれを紹介してみる。

そもそも NTFS 圧縮ってなに?

NTFS(Windowsファイルシステム)の機能の一つ。

対象のディレクトリに対し、Windows (NTFS) 側で自動的にファイル圧縮をかけてくれる。見かけは普通のディレクトリとファイルであるので、NTFS 圧縮が有効になっているディレクトリのファイルは、通常のファイルを扱うのとなんら変わりはない。しかし、こっそり圧縮をかけているので、実際の使用容量は減っており、ファイルの読み書きのタイミングで圧縮・解凍がかけられている。(「透過的な圧縮」と呼ばれるらしい。by Wikipedia

どうやって設定すればいいの?

  1. 対象のファイル・フォルダのプロパティを開く。
  2. 「全般」タブ内の「属性」の欄の「詳細設定」を開く。
  3. 「属性の詳細」のダイアログが表示されるので、「圧縮属性または暗号化属性」欄の「内容を圧縮してディスク容量を節約する」にチェックを入れる。
  4. 全部 OK を押して、今までのウインドウを閉じる。

ラクチン!!!

NTFS 圧縮が効果を発揮するファイル

所謂、ファイル圧縮の処理を行っているため、既に圧縮されたファイル(zip, mp3, jpg...)などのファイルが多いディレクトリには適さない。

しかし、Teraterm のログなどテキストファイルや、圧縮すると縮むファイルが多く存在するディレクトリには効果を発揮する。

適応例

Teraterm のログを保存しているディレクトリに対し、適応してみた。

1/3 より高い圧縮率! 4TB の HDD が売られている今日日、大した容量節約ではないでしょうが、塵も積もればなんとやら。数ステップで効果を出してくれるので、使わない手はないでしょう。

逆に効果の無いものは?

  • 既に圧縮されたファイル(zip, mp3, jpg...)
  • 動画ファイルやデータベースなど、ごりごり重い読み書きをするファイル

のようなものがある場合、容量が節約できないか、処理が遅くなる可能性がある。ただし、Becky!Thunderbird のデータフォルダ程度なら、特に処理が遅くなるという感覚は覚えなかった。

まとめ

良い御年を。