nDiki : 作り方

■ 手縫いで作る革のカバン

「吉田カバン」の創業者である吉田吉蔵氏の次女、野谷久仁子氏によるレザークラフトの本。新宿の紀伊國屋書店でみかけて買い。

すごい格好いいバッグや小物の作り方が説明されている。 基本的なテクニックがカラーで解説されており独習にも最適。

自分の持っていた英語の本はカウボーイ向けで、サドルレザーを使った薬夾入れとかナイフケースとかそんなのが多かったのだが、この本をみているともっと洗練されたのが作れそうな気分になってくる。

Arc-LS 用レザーケースを作って以来2年近くレザークラフトご無沙汰だし、またなんか作ろうかな。

この間階下で赤ちゃんが生まれたので菱目打ちはちょっとはばかられるので、そこんとこは会社で昼休みにでもやるか?

• 手縫いで作る革のカバン

[ 書評 ]

■ Module::Build でソースパッケージング

@ ExtUtils::MakeMaker

私が Perl が好きな理由の一つに、標準でExtUtils::MakeMakerという Makefile ジェネレータがついているところである。これを使って Makefile.PL を書くと

 perl Makefile.PL
 make manifest
 make
 make test
 make dist

で <pacakge>-<versionno>.tar.gz というソースパッケージを作ることができ、

 tar zxvf <pacakge>-<versionno>.tar.gz
 cd <pacakge>-<versionno>
 perl Makefile.PL
 make
 make test
 make install

という手順でインストールする事ができるようになる。 パッケージの作り方が確立されているので、容易に新しいパッケージを開発しはじめられる。

逆に Java でプログラムを書くのが億劫なのは、このあたりの準備が面倒だからである。 Ant を使っても結局ここら辺自分でやらなければならないし。

@ ちょっとしたアーカイブの作成

ちょっとしたパッケージを作りたいと思うことは良くある。 例えばいくつかのデータファイルと、READMEファイルなんかをひとまとめにしてアーカイブにするとか。

本当にちょっとしたであれば、手動でアーカイブすれば良いのだが、

• アーカイブしたいファイル群がバージョン管理下にあって、CVS ディレクトリや .svn ディレクトリがある (除外してアーカイブする必要がある)
• 同じディレクトリにある、作業用のファイルはアーカイブしたくない (除外してアーカイブする必要がある)
• アーカイブする前に、チェック用のリグレッションテスト一式を走らせたい (リグレッションテストをかけられるようにする)
• UNIX でも Windows でもアーカイブ化できるようにしたい。

あたりを考慮しなければならない時は面倒くさくなってくる。

自動化としては

• シェルスクリプト/バッチファイルを書く
• Makefile を書く
• GNU Autotools を使う

あたりがぱっと思い浮かぶ。 しかし、最初の2つは毎回同じようなものを書くのが面倒だし保守もしにくい。 GNU Autotools はちょっとごっつすぎだし、Windows での環境構築も面倒。

@ ExtUtils::MakeMaker の欠点

ということで最初は ExtUtils::MakeMaker を使うという線で考えてみた。 もともと Perl モジュール用で汎用用途にはちょっと邪魔な振舞いもあるが、使えないことはないと思う。 しかし make (GNU Make あるいは nmake など) に依存しているという欠点がある。

@ Module::Build で

ということで ExtUtils::MakeMaker の代替である Module::Build ベースで汎用用途に使えないか検討してみた。こちらは pure Perl で make を必要としない。

Module::Build も Perl モジュールビルドにあわせた振舞いがあるものの、ちょっとカスタマイズすれば使えそうだ。 で、いろいろいじった結果、次のような感じにすると使いやすそうだ。

 use Module::Build;
 my $class = Module::Build
   ->subclass(class => 'NonmoduleBuilder',
              code => q{
                        # Don't make blib
                        sub ACTION_code {};
                        # Don't make blib
                        sub ACTION_docs {};
                        # Don't make META.yml
                        sub ACTION_distmeta {
                          # no warning on ACTION_distdir
                          $_[0]->{metafile} = 'MANIFEST';
                        };
                        # Don't add MEATA.yml to MANIFEST
                        sub ACTION_manifest {
                          $_[0]->{metafile} = 'MANIFEST',
                          $_[0]->SUPER::ACTION_manifest(@_);
                        };
                       });

 # Set your archive name and version.
 $class->new(dist_name => 'mypackage',
             dist_version => '1.0.2',
             )->create_build_script;

カスタマイズした部分は以下(Module::Build 0.26 で動作確認)。

• Perl モジュールビルドに特有の blib ディレクトリを作らないようにする。
• META.yml を生成しないようにし、アーカイブに含まれないようにする。

上記のようなファイルを Build.PL という名前で作っておけば

 perl Build.PL
 ./Build manifest
 ./Build
 ./Build test
 ./Build dist

等として、アーカイブ作成が容易にできるようになる。

しばらくこの方法でいろいろ試してみることにしてみよう。

■ ソフト契約と見積りの基本がよ～くわかる本

最近契約的な視点での決め事にかかわる事が多くなってきたので先日買ってみた。 見積もりの部分はおまけ程度で、契約・契約書の作り方が中心。 ソフトウェア取引の契約について

• ソフトウェア開発委託契約
• ソフトウェア使用許諾契約
• ソフトウェア保守契約
• 情報処理委託契約

などがあることやそれらの概要を確認できるという点でなかなか良い。

権利的には

• 著作権
• 所有権
• 使用権
• 特許権・実用新案権

などかからんでくるのだが、ソフトウェア特有の複雑さがありすぐ混乱してくる。 やっかい。

面倒な世界であるな。

書籍はわかりやすいが、契約(書)例が少ないのが残念。 著作権等がどちらの権利になるかなどについてもう少し解説があると嬉しい。 第三者ソフトウェアがからんできた時の説明も欲しい。

またソフトウェア開発委託契約例はウォーターフォール的なモデルにもとづいており、現場としてアジャイル的なモデルで進めたいと思っても相容れない部分が多い。

それと「図解入門」シリーズということで図がふんだんに使われている。 図があった方がわかりやすいのだが、わざわざ図にする必要のないものを無理やり図にしたり図が間違っていたりするものがあったりする。ちょっと注意。

• ソフト契約と見積りの基本がよ～くわかる本

委託・受託双方にハッピーな結果(と権利関係)が得られる契約が作れるのが一番いいんだけれど、実際のところ

• 力関係
• 雛型がある場合、組織の方針・風潮として(全く/あまり)変えられない事が往々にしてある
• 面倒。時間がかかる。

などなかなか思うようにいかないものである。

この辺りについてカバーされている書籍があれば、ぜひ読んでみたい。

[ 書評 ] [ 読書ノート ]

■ WiKicker でソフトウェアかんばん

情報カードベースでソフトウェアかんばん(ストーリーカード + タスクカード)を作っている開発プロジェクトがあるのだが作ったっきりあまり活用されていないので、今回は試験的に WiKicker による Wiki 上でかんばんを作ることにした。

まだ荒削りだけれども、まずはとにかく以下のルールで始めてみる。

@ ルール

@ カードの作り方

基本的には 1カード毎に WikiPage を作るようにする。 ページ名はストーリーカードを表す SC と 状態 (TODO / DOING / DONE) を含む名前にする。

• SC/TODO/<ストーリー名>
• SC/DOING/<ストーリー名>
• SC/DONE/<ストーリー名>

タスク名も同様に作る。

• TC/TODO/<ストーリー名>
• TC/DOING/<ストーリー名>
• TC/DONE/<ストーリー名>

カードの内容は XP で扱っている内容で。 新規作成が楽なようにテンプレートページを作っておき、これをコピーして作れるようにしておく。

@ 状態変更

TODO -> DOING -> DONE という状態変化にあわせて、WikiPage 名を変更してページを移動させる。

 例:
 TC/TODO/名前をつけて保存メニューを追加
   |
   V
 TC/DOING/名前をつけて保存メニューを追加
   |
   V
 TC/DONE/名前をつけて保存メニューを追加

@ 一覧ページの作成

SC/TODO、SC/DOING、SC/DONE、TC/TODO、TC/DOING、TC/DONE ページを作りそれぞれに、子階層の一覧を表示させる (WiKicker の [[index:child]] を使用)。

@ 参照

タスクカードからは「SC/<ストーリー名>」という名前で、ストーリーカードへリンクさせる。

WiKicker では「SC/<ストーリー名>」というページない場合、「SC/*/<ストーリー名>」というページを探してリンクしてくれる。この機能のおかげで、状態にあわせてページ名を変更してもリンクはそのままで追従してくれる。

@ 担当者

担当者が割り当てられて実行中のタスクカードには [[DOING:担当者名]] という文字列を記述しておく。

「DOING:担当者名」で検索することで、各担当者が何を実行中なのかリストアップすることができる。また DOING: を「DOING:担当者名」を検索する Wiki 自身への InterWiki として定義しておくことで、この記述自体を検索結果へのリンクとすることができる。

■ 今日のさえずり - オーナメントすぐもがれる

@ 2008年11月14日

• 09:14 アンパンマンの鼻と頬のハイライトってなんで正方形なの?[mb]
• 09:29 スターバックスで赤カップ版クリスマスオーナメント在庫聞いたら、隣の店舗まで取りに行ってくれるとのこと。さすがスターバックス。クリスマス ブレンド頂きながら待ってます。[mb]
• 09:50 今日は西の車窓から青い東京タワーを眺めながら帰りたい。[mb]
• 10:16 @lynmock 「役に立たないアンパンマンの被り物の作り方」を読んで返信もらった意味がわかりました(モバツイだとログ追いきれなくて)。リアルにあの曲面に正方形のハイライト出す照明あてるのって至難ですよねぇ。
• 11:13 オフィスのクリスマスツリー出して飾った。って書き忘れて zakwa に先こされた。
• 12:14 @yamakiyo ミラーレンズって。リングぼけ楽しみたいとか?
• 12:31 自分は「クロン」 [B!] F's Garage：cronの読み方 http://www.milkstand.net/.../001445.html
• 13:01 [photo] スターバックス レッドカップオーナメント http://tinyurl.com/5ph49n
• 14:16 @yamakiyo 500mm F6.3 のミラーレンズだと用途狭すぎじゃないですか? 色収差が少なかったとして何を撮るのか興味津々。
• 17:07 @zakwa 自分も最初「なんで2次元?」って思ったよ。
• 17:08 @yamakiyo 撮りたいものが撮れないのなら色収差が少なくても意味ないですね。
• 17:29 ソニッケアーのブラシがえらく変色してきている。やはり6カ月待たずして交換だな。
• 17:52 あわよくばいれたくない「ラベル屋さんHOME」インストール中。
• 20:00 今日は最後ですね。
• 20:53 残業って慣れるもんだね。ヤバイヤバイ。[mb]
• 21:10 席に座っていて青い東京タワーが見えない。[mb]
• 22:47 ようやく P3 を 3.23 から 3.40 にアップデートした。
• 23:05 urchin.js のままだったので、ga.js にする。
• 23:27 ttree 2.9 から accept を使用しているなら、ディレクトリも accept にマッチしなければならなくなった。

@ 2008年11月15日

• 10:17 電気ファンヒータ出した。[mb]
• 16:50 クリスマスツリー出した。オーナメントすぐもがれる。[mb]
• 21:28 明日は 10:00 - 11:00 でオフィス停電なのでサーバお守りしにいく。雨降るなよ(雨降ると停電延期の可能性有り)。

■ 今日のさえずり - パスポートみたら有効期限切れてた

@ 2010年02月11日

• 11:22 自分の Google アカウントも Gmail に Google Buzz きた。
• 11:38 Google Buzz にいったん Twitter と Flickr を関連付けたけれど、Google アカウントのポジションを考えてやっぱり外した。もう少しどういう位置付けにするか考えてみる。
• 12:05 やはりビジネス関係は別の Gmail アカウントが必要だな。
• 15:07 他ドメインのメールアドレスで登録していた Google アカウントに Gmail アカウント新規登録した。最初から Google Buzz 付き。
• 15:29 既存の Google アカウントに Gmail アカウント追加しても前のメールアドレスでログインできるんだ。
• 15:51 Gmail アカウントを2つに分けたのでコンタクトリストをインポート/エクスポートして割り振り。
• 17:28 Gmail での POP3 受信設定の1つを新 Gmail アカウントに移動。旧 Gmail アカウントへは転送するように設定。
• 17:36 Gmail での送信メールアドレスのいくつかを新 Gmail アカウントに移動。旧 Gmail アカウントから削除。
• 20:22 ふとパスポートみたら有効期限切れてた。
• 20:30 あちゃ。壁湿ってた。
• 20:47 新 Gmail アカウントからの POP3 受信設定を fetchmail の設定ファイルに追加。
• 20:58 Gmail のコンタクトリスト整理したので Google Buzz で再度 Twitter と Flickr を関連付け。
• 22:11 既存のメールアドレスでとった Google アカウントに Gmail アカウントつけたんだけれど、Gmail の SMTP サーバ経由で外部からメールを送ると送信者登録してあっても From: が Gmail アドレスに書き換えられてしまう。
• 22:12 Web インタフェースからだと選んだ送信者がきちんと From: になるので、Gmail SMTP サーバ経由で送った時だけ。
• 22:14 まず Gmail アドレスありきの Google アカウントだと、Gmail に送信者追加したメールアドレスを From: にして外部から Gmail の SMTP サーバ経由で送ってもきちんとその From: で送信できる。
• 22:15 後付けの Gmail アカントだとちょっと挙動が違うのか。素直にそのメールアカウントの SMTP サーバを使うようにするか。
• 22:21 @Keiichi_SHIGA これは Sender と From についてですよね?
• 22:25 @freedomcat 最初の Google アカウント作成で指定したメールアドレスは SMTP サーバを Gmail にするか他にするか選べないんです。
• 22:34 @Keiichi_SHIGA Gmail アカウントに後から送信者追加したメールアドレスを From: に指定する分には Web からでも外から Gmail の SMTP サーバを使ってもその From: のままです (Sender: は @gmail.com)。
• 22:36 @Keiichi_SHIGA でも Google アカウントをまず他のメールアドレスでとって、そこに Gmail アカウントを足すと、 Gmail SMTP サーバ経由でメールを送った際 From: が @gmail.com に書き換えられてしまいました。
• 22:46 @Keiichi_SHIGA Gmail アカウントの作り方によって挙動が違うようですね。Google アカウント作成時のメールアドレスは Gmail の設定から外せませんし、外部の SMTP サーバを指定することもできないです。
• 22:51 @Keiichi_SHIGA Google Apps はまた違うんですか。そのうち Google Apps への移行も考えていたので後でまたはまりそうです。
• 23:25 Mew のメール送信一部修正した。追加 Gmail アカウントの SMTP サーバ経由するのは諦めて本来の SMTP サーバを使うようにした。これだと Dcc で自分宛に送ったメールが Gmail から転送できるし POP できるし悪くなかった。

■ 今日のさえずり: RELAX NG って現役だよね?

@ 2010年10月25日

• 10:07 @machu 「入門Git」 http://amzn.to/d2PLOD ですね。WEB+DB PRESS Vol.50 #wdpress 買った時に書店でパラパラとめくってみました。そちらもぜひ読んでみようと思います。
• 10:24 UPS がうるさい。
• 12:08 中華弁当 498円。
• 15:27 お面の作り方。 http://movapic.com/...
• 18:07 RELAX NG って現役だよね?
• 20:59 ドラッグストア3店のべ5店まわって今日の買い物終了。
• 21:03 w3m + Evernote モバイル向けページ。 RT @yakifumi: EmacsからEvernoteつかえるemacs-lispはあるのかなぁ？あると便利な気がする #Emacs #Evernote
• 23:38 PandaHome のアップデート版が91熊猫桌面になってしまった記念に、ADW.Launcher (donut) に乗り換え。何コレ、行列数変更(ページ・ウィジェット)とか凄すぎ。 #Android #Xperia
• 24:19 REGZA に繋いでいる USB HDD の電源連動が働かなくてうるさい。

■ YAPC::Asia Tokyo 2011 1日目

@941 → @obra → @miyagawa → @naoya_ito → @ockeghem → @fujiwara → @zigorou → @ikasam_a → @overlast → @lestrrat (LT)

今年は講堂に YAPC タイムラインを写すスクリーンが公式に用意されたため、発表者が Growl 起動してなくても Tweet をシェアできるようになった。自分の端末に目を落とさなくても良いのでいいね。機材や場所の制約があって難しいのだろうけど、他の会場にもあると嬉しいな。

@ トーク

@ Perl 5.16 and beyond: Jesse Vincent (@obra)

Perl 5 が互換性を大切にしていく。コアを小さくしていく。

成熟期に入っているので、膨大な資産が継続して使い続けられることはとても重要な要素。

@ Carton: CPAN dependencies manager: Tatsuhiko Miyagawa

CPAN モジュールインストール状態の記録と再構築を容易にする Carton の紹介。

6年前とかにこういうの欲しかった。 特にパッケージ製品とか作っていると、動作確認のとれた依存ライブラリ一式の保存と管理が大切。自前で tarball 保存(+ PPM パッケージ作成と PPM リポジトリの構築)をしていた日々が思い出される。

@ SmartPhone development guide with Node/CoffeeScript and HTML5 technologies, for Perl programmers: Naoya Ito

JavaScript のお話。

@ Webアプリでパスワード保護はどこまでやればいいか: 徳丸浩

まだまだソルト健在。レインボーテーブルは発想が賢い。

• 体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践

@ Perlで構築された中規模サイトのDC引っ越し記録: FUJIWARA Shunichiro

稼働中のサービスのサーバ移転に関する顛末。

@ Mobage オープンプラットフォームの事件簿: Toru Yamaguchi

MySQL なお話。

@ 他言語から見たPerlのテスト: Masaki Nakagawa

テストフレームワーク・テスト用モジュールいろいろあるね。 浅く広く紹介。

@ Apporoで類似文字列検索: Toshinori Satou

前半は技術開発プロセスに関する雑感、後半は類似文字列検索 Apporo の紹介。

@overlast 氏とは懇親会で話をさせていただいて「うーん、やはり悪徳業者投稿コンテンツの検出はヒューリスティックにやっていくしかないのかな」という点で意見が一致。

@ LT

いろいろ。

@ 懇親会

思ったより食えました。

前職で一緒に研究開発をしていた @k12u 氏と再会できて嬉しかった。かわらず元気そうで何より。

「Perlっ!」って話は最初の2本で、後はその他の技術もろもろ。アリだけど個人的にはもっと Perl の話も聞きたーい。

■ YAPC::Asia Tokyo 2011 関連 300人超 Twitter リストの作り方

YAPC::Asia Tokyo 2011 が終わってはや2週間。クロージングの時の発表だと参加者数は672人だったとか。 今回も当初から参加者・関係者らしき Twitter-ers のリストを作ってたんだけれど、最終的には300人以上を GET(すでに削除済みです)。 そのリストの作り方を以下にまとめておこう。 イベント参加時や主催時に役に立つかも。

@ リストを作ってまずメインをおさえる

まず公式アカウントを登録。 そして運営の中心人物のアカウントなどを登録。鉄板。

follow 推奨。

@ チケット発売開始ぐらいから Twitter 検索

チケット発売開始後「チケット買った」というのが Tweet されるようになる。公式ハッシュタグ #yapcasia や YAPC キーワードで定期的に

• Twitter 検索や
• Yahoo!検索 (リアルタイム)

で検索してピックアップ。

チケット買ったという人はほぼほぼ参加者。 ただしこの手の Tweet はそれほど多くない。 また発売直後以外は細々といった感じである。

参加者を事前にキャッチしておくのにイベント名や公式ハッシュタグの検索が有効そうな気もするが、いくつもイベント参加者収集をした経験からすると開催日前日ぐらいまではほとんど Tweet されないと思った方が良い。

@ 個人スポンサーをチェックする

YAPC::Asia Tokyo では今年から個人でスポンサーになれるようになった。 個人スポンサーの方々は「スポンサードしたった!という名誉」ページにニックネームとアイコンが掲載される(Anonymous の方もいる)。 感謝するとともにリストに登録。

たいがいニックネームが Twitter アカウント名と一致するけど、そうでない場合は Google 検索するとかアイコンを Google 画像検索するかでだいたい捕捉できる。

これらの方々は deep な方が多いので follow 推奨。

@ スピーカーが発表されたらチェックする

公式サイトでトークが確定したらスピーカーをチェック。YAPC::Asia Tokyo だとニックネームが併記(あるいはニックネームのみ)されているので、これらで Twitter アカウントを捕捉。9割以上は見つかる。鉄板。

follow 推奨。

@ 1週間ぐらい前からこまめにハッシュタグ・キーワード検索

「開催日前日ぐらいまではほとんど Tweet されないと思った方が良い。」と先には書いたが、YAPC::Asia Tokyo に限っていえば、1週間ぐらい前からスピーカーとか遠方からの参加者を中心に Tweet が散見されるようになる。

公式タイムテーブルにのらない LT 関連の人も発表どうするかなといった Tweet が見つかる。

これらを捕捉。

@ ATND

参加者捕捉で最強なのは ATND。 ATND アカウントは Twitter と関連付けされている場合が多いので、勉強会などで ATND 使っていると、かなり特定分野に興味がある Twitter-er を見つけることができる。

今回は懇親会と後夜祭で ATND が使われていたので、Twitter 関連付けされているアカントで参加表明している人をどんどんリストに登録。

片っ端からの登録作業をしていると twitter.com Web サイト上で limit にかかってしまうぐらい強力。

@ 当日

当日になると参加者がイベント名やハッシュタグ付きでガンガン投稿しはじめる。 参加者捕捉的には一番ホット。 ただし「あ今日やっているんだ」「行けなくて残念」的な投稿も相当数あるので見分けるエネルギーが必要もあったりする。

実際のところは自分もイベント会場にいてトークを聞いたり Tweet したりで忙しいのでリスト管理はほとんどできない。 当日は直接会えた人との時間を大切にしたり、検索タイムラインでリアルタイムにその場の雰囲気を共有したりするのにエネルギーを費した方が吉。

@ 開催中の帰宅後

今回は補助的に Formulists(紹介記事) のキーワード検索結果からの自動リスト生成を補助として動かしててみてはいた。 帰宅してからこの自動リストをチェックしてリストへ追加はするなど。

@ ここまででルール

なおお約束としては、リストを公開リストにするならば

• 参加表明的な投稿を public にしている
• スピーカーなど公開情報として参加が衆知である

以外の人は、仮に参加することがわかっていてもリストに登録しない。

@ なんでそんなリスト作りするの?

パンフレットには「YAPC::Asia Tokyo 2011の楽しみ方」として

• トークを楽しもう!
• 交流しよう!
• 企業・スポンサーの方達も!

というのが上げられている。交流できるといいよね! でも想いと行動が一致しなくて悶々としているシャイな人も多いはず(含む自分)。

事前に Twitter で follow しておくと、当日「Twitter で見たことあります」「この間 follow してくれましたよね」と言われることが結構あり話題のきっかけになる。 当日アイコン入りの名刺やカードを ID ケースに入れておくと効果あり(イベントでマイ ID ケースをさげるの有効)。 もちろん follow しておけば無敵というわけではなくて、あくまでも交流には勇気がいるわけであって勇気がないと全然足しにはならないわけではあります。

しかしながら当日交流できなかったとしても、同じ分野に興味を持つ Twitter-ers を見つけられること自体結構価値がある。

シャイな Twitter-er は勉強会やイベントの前にやってみるといいよ。

■ 今日のさえずり: チキン難民

@ 2011年12月24日

• 08:49 「フィードバックを適切に与え、受けとめる」
• 09:34 貼られている写真は半切りすらしていないところがシュール。 RT @as_tone: Wikipediaより「柚子湯の作り方としては、柚子の果実を5 - 6個輪切りにして、湯に浮かべる。」ええっ？！
• 10:41 二酸化マンガン二酸化マンガン (チェッチェッコリ)。
• 14:31 ケーキ作り始まってる。
• 15:22 K-9 Mail の設定がまた飛んでる……。
• 16:12 Android Market の K-9 Mail は 3.802 で止まっているけど、http://t.co/CMAKcjtB の方のは 4.103 まで上がってる。最近のバージョンだと設定のインポート/エクスポートがついてるんだね……。
• 16:47 チキン難民。
• 17:26 今日チキンを切らしている肉屋の存在意義を疑った。
• 20:35 K-9 Mail 最新にして再設定完了。設定のエクスポートも。
• 20:46 やばい、買いそう(未承認)。 PEN E-P3 レンズキット シルバー E-P3 LKIT SLV http://t.co/rDy8wuKE
• 21:39 しまった。12月29日は、りんかい線一般乗車 NG デーか……。 #C81
• 22:22 @py0n 沿線住民にはインパクトでかい。
• 22:59 かわりに Nikon D5100 どうよと思ったが、ボディー内モーター無いのか。
• 24:06 もう Mew を使わなくなってから11カ月ほどになるけど、無意識に M-x mew してしまう。