荒地山を登ったときに見たネコたち。
しましまと茶色とふさふさの 3 匹いたみたい。
ずっとついてきてなにかをねだるネコ
ついてくる
ねだり鳴き
うらめしい
ロッククライミングネコ
しなやか
「理想」「現実」「方法」「実行」に分けてみた
スクラムで出てくる振り返りとプロセス改善について考えていると、「理想」と「現実」のどっちも認識してそのギャップを埋める「方法」を適切に見つけ出した上に「実行」できることを自然と求められていて、それは大変に困難なことなのではないだろうか……と思って書き始めた。そもそも「理想」「現実」「方法」「実行」に分けてどれだけ考えているだろうかなーと。
勉強会に行ったり本を読むことは「方法」を学ぶことなんだけれど、実はその「方法」を適用することで達成される「理想」の状態についても知ることができる。自分はこれがとても大切だと思っている。どんなことをするにも最善の状態を認識できていないと、いまできることに引っ張られてしまってどうしても妥協が強く出たアウトプットしか出なくなるから。「現実」からの積み上げだけだと最終的な結果が必要なものに届きにくいと感じているのもある。ゴールに「理想」をおいて、ゴールまでの道のりまでを一定の粒度や単位に分解して進めていく方が、最も短くブレなくゴールに着けるんじゃないかなーと。
一方で「現実」の方もきちんと理解しないといけないと思っている。状況が見えていないのに「理想」だけ追い求めてもそれは無謀というものになってしまう。できないことをいきなりやろうとしてもうまくいかないし、結果が求めていたものじゃないかもしれない。より効果的でより効率的な「方法」を選び取るには「現実」を理解しておかないといけないと思うから。
「理想」と「現実」のどちらも「方法」選択に重要な要素なんだけれども、ここがあいまいなまま「方法」を選択してしまうからうまくいかなかったり、手段が目的になっているなんて言われたりしてしまうのかもしれない。 ケースがたくさん出てきそう。
- アウトプットは出てもアウトカムじゃないってときなのかもしれない
- なにかを複数人で進めていると他人に対してどうしてそんなことしたの？と疑問に思うこともあるけど、きっと見ていた「理想」の程度や方向性が違っていたのかもしれないし、もしかするとそもそも「理想」像が見えていないのに無理をしていた・させていたのかもしれない。
- 視座の高さとか視野の広さっていうのは「理想」をどれだけ見れているのかってことなのかもしれない
- エンジニアなら勉強会に参加しよう、みたいなのは社外の大きな世界で高い「理想」に触れてほしいという思いからなのかもしれない
- キャリアパスってどう考えてる？なんて面談で聞かれるのは「理想」と「現実」をどう捉えていますか？という質問なのかもしれない
しれないしれない問答。思い当たるところがたくさん？
「実行」について……どんなに「理想」と「現実」から良い「方法」を見つけても「実行」されないと意味がないはず。なんだけれど、個人的にはコツコツやらないといけないここが難しい。どれだけ早く理解できてもやらなきゃなにもはじまらない。結果が見えた気になってるだけだとダメ……そう思って、意識してこれを書き始めたのかも。
はじめに戻ると、
「理想」と「現実」のどっちも認識してそのギャップを埋める「方法」を適切に見つけ出した上に「実行」できること。それは大変に困難なことなのではないだろうか
だから、きっと工夫の仕方や考え方のフレームワークという形で「方法」がたくさん別の名前で存在しているのだろう。けれどもそれはやはり「方法」でしかないので気をつけないといけないのかなって。
「理想」のところを目的とか 5W1H でいう Why のところに置き換えるとまた違ったことが考えられるかも？時間切れなのでまた考えてみようー
認定スクラムマスター（CSM）になった
認定スクラムマスター研修 を受けてテストも合格したので認定スクラムマスターになりました。だからといって完璧っていうものでもないので「俺たちの戦いはこれからだ！」ですね。日々精進あるのみ。
研修はだいたい 5 人チームが 6 つで進行、少し説明を受けてあとはチームで議論したりワークしたりを 2 日間みっちりやる感じでした。講師の方は車をモジュール化することで早いフィードバックと改善ができるようにした経験をお持ちの方。ハードウェアでもそういった進め方ができるのかと興味深く聞いていたけど、そういえば昔この人のプレゼン動画を見た記憶が……。最近では航空機、特に戦闘機の開発にもスクラムの考えが取り入れられているお話おもしろかったです。
1 日目の終わりに「ハッピーアワー」と称した会は英語日本語混じりにとても盛り上がった！素早いリリースができるようにしておく準備の重要さと同じくらい、英語のスピーキングが必要だと痛感……
ところで、これから仕事でスクラムマスターなことするのかというときっと否。
仕事ではいまのところマネージャーとして自社サービス事業の責任を持っています。人数も少ない小さなチームなので、役割はスクラムマスターかというとそうでもなく、（名刺にある）プロダクトオーナーかというとそうでもなく、何でもやる人。確かなのは利益に責任があること。
機会があれば別のチームや部署でスクラムマスターとして役割を持てると良いのかな。考えてみよう。
その他のその他
2019 年の振り返りで書いた
その他 いつも自分で改行を入れてみていたけど、スマートフォンなど横幅がせまい環境だと変に改行して逆に見づらいのかなとも思った。なので今回は改行を自分で入れずに段落な感じに書いてみた。どちらが読みやすいかあとで自分で確認してみよう。
↑これ、まあこれはこれで見やすいし書かれた「文章」って感じがしたので継続してみる……
2019年と2020年
わりと自分用の記録（？）と展望
2019年
毎年 1 回くらいはどこかで機会をつくって社外の場で登壇するようにしていたのだけれど、2019 年は 1 回も社外で話をすることが無かった。仕事での変化や事業のテコ入れなどいつもより多少考えることが大きかったのもあるけれど、生活の方での動きが大きかったのが一番の理由になりそう。
仕事の方では、会社ではじめて早数年のサービスのプロダクトオーナーを人に譲ってみて、半年後にまたプロダクトオーナーになった。プロダクトオーナーといっても役割定義にこだわっていられる状況でもないので、サービスの進む方向を決めたり予算管理もする一方で開発もすれば運用もするしインフラ構築整備もしながらプロモーションの管理をしつつ問い合わせ対応だってする感じ。こういう未分化なのが良くないのかもしれないけれど、状況をどう変えていくのが良いのかなーと思いつつ改善のために様々変化させつつ日々が過ぎていった……。結果を出したいなー。
生活の方では引っ越ししてみたり山登りを始めてみたり。夏からはじめた山登りは、まだハイキング程度のものだけれど今後も続けて体力・技術を上げていきたい。それにしても 2019 年はこの山登りをはじめたのが自分にとって一番大きな変化だったかもしれない。アウトドア趣味なんて親や親戚もほとんどなかったから、そもそもこれまでやったこともなくて学校行事で林間学校や野外活動するくらい。可能であればずっと家にいたいタイプなので、個人的には大事件。
山登りは YAMAP があるのも大きかった。自分の活動記録はこれ こういった形でログが取れるのも良いし、GPS を使ったスマートフォンでルーティングができるのも良い。こういうユーザーと直接接するサービスに関わってみたいなと思えた。ちなみに 2019 年 7 月から今日までで YAMAP に記録されたのは
- 距離 合計 81,572 m
- 標高 合計 5,447 m
らしい。
摩耶山・六甲山がほとんどで、金剛山と加西アルプスが少し離れたところに。金剛山は標高 1,125 メートルで実際に登れるのはもう少し低いところまで、上り下りは 750 メートルくらいが最大なのでまだまだ……。
2020 年
仕事の方はいまの事業をなんとかしてみたいのが半分、そろそろなにか違うことを考えてみたいのが半分。後者はずっと言ってるのでどうしたものか。余り書くと会社であれなのでこの話を書くのはここまで。でも会社最適されすぎないように、自分の力が通用するのかはかるためにも、会社の外・別で仕事してみたいな。
生活の方は 2,000 メートル級の山に登ってみたいなーと思っている！雪がなくなるまでに近所の低山で体力（と技術）を上げておきたい。あと雪山を（登るのではなくて）歩いてみたい。
その他
いつも自分で改行を入れてみていたけど、スマートフォンなど横幅がせまい環境だと変に改行して逆に見づらいのかなとも思った。なので今回は改行を自分で入れずに段落な感じに書いてみた。どちらが読みやすいかあとで自分で確認してみよう。
Windows の開発環境を作りなおした ver.2019 の後日談
けっきょく WSL1 で環境を作りなおしました。
というのも VM とのホストオンリーアダプタ接続が VPN 接続すると使えなくなってしまい
ssh も Samba も断絶してしまうため……。
ssh は NAT でポートフォワーディングすれば使えますが、
Samba は速度もほしいのでいまひとつ。
なにより作業中に VPN 接続して Samba が切れて作業が飛ぶのが怖い。。
ということで WSL1 で環境を作りなおしたのでした。
けっきょく WSL 側にソース類を置いておけば git 等のファイルアクセスも問題無いし、
Windows から IDE でソースをさわるときは WSL1 に入った 9P 経由で
WSL 側に置いたファイルをネットワークドライブで繋いでそのまま IDE から参照。
ちょうど VM + Samba でやっていたことを WSL + 9P でやったら
設定もしなくて良いし安定性も高いという。
WSL2 が来てもソース類は WSL の中に置きそうなので
いまひとつ WSL2 に魅力を感じなくなってきたような？
速度が WSL1 より大幅に改善したりなど乗り換えたくなる良さが出てくるのかな。
なにはともあれしばらくこれで行ってみようと思います。
Windows の開発環境を作りなおした ver.2019
2016 年頃に WSL が使えるようになってからというもの
ずっと WSL で開発を続けてきました。
Java に Scala に js に fish shell に Emacs、
最近では Visual Studio Code と Remote WSL でかなり快適でした。
ファイルアクセスが遅いので git やビルドがもたつくことと、
WSL のプロセスが動いていると WMI Provider Host が
CPU を数 % だけずっと消費しつづけることが少し不満でしたが、
それでも昔に比べれば随分と快適でした。
にもかかわらず、魔が差して全てを消してしまったのでした。。
最近使えるようになった WSL2 を試してみたのが全てのきっかけ。
WSL1 に超最適化された環境と比べるといまひとつなところが多かったので
Insider Preview から戻したのですが気がついた時は手遅れ。
WSL2 から WSL1 に戻さずに Windows のバージョンを戻してしまったのです。
結果、WSL 環境がまっさらになりました。（＊自分の責任）
もう一度 Insider に上げてみても状況は変わらず。。
ということで 1 から開発用の環境を構築しはじめたのでした……。
VirtualBox
もとのとおり WSL1 を使っても良かったのですが、
せっかくなので WSL 以前に使っていた VirtualBox を使うことにしました。
通常どおりインストールして、
ホストマシンとはホストオンリーアダプタで通信するように設定。
OS は趣味で Manjaro にしてみました。
あとは起動用にウィンドウを表示しないオプション headless を付けた
VBoxManage startvm manjaro --type headless
と bat ファイルを用意しておいて、
Windows のタスクスケジューラでホストマシン起動時に
この bat を実行させることで、
VM も自動でバックグラウンド起動するようにしています。
SSH
Windows 用の OpenSSH-Win64 が一番動きが良く表示崩れが無いようでした。
一番新しい v7.9.0.0p1-Beta でないと接続時に
warning: agent returned different signature type ssh-rsa (expected rsa-sha2-512)
と表示され鍵認証できませんでした。
はじめから入っている ssh は 7.7p1、署名のアルゴリズムが古い……。
Samba or SSHFS
vboxsf でホストのディレクトリをゲストと共有できますが、
ビルドなど主な作業をおこなうゲスト側からのアクセスが遅く
git や sbt でのビルド・パッケージングの際にもっさり感があります。
ソースをゲストに置けば速度の問題は解決しますが、
今度はホストの Windows で動かしたい IDE などが使えないことに。
そこでゲストマシンで Samba の設定をしておいて、
開発に使うリポジトリやソースコードの類はゲスト側に置いて、
Windows からはネットワークドライブとしてマウントしています。
また、Samba と併用してみているのが SSHFS。
Samba の設定が面倒なのとファイルの権限や所有者の問題が発生したので
SSHFS ならどうかなとテスト中です。
利用したのは
- GitHub - billziss-gh/winfsp: Windows File System Proxy - FUSE for Windows
- GitHub - billziss-gh/sshfs-win: SSHFS For Windows
の 2 つ。
WinFsp 2019.3 B1 をインストール後に SSHFS-Win 3.5 BETA をインストールしました。
するとエクスプローラのアドレスバーに
\\sshfs\ユーザー名@ゲストVMのIP と入力すれば SSHFS にアクセスできるようになります。
GUI でマウントの管理をするなら sshfs-win の README で
が紹介されていましたが、少し UI が独特でなんとも……。
単にネットワークドライブとして割り当ててしまえば良い気がします。
Samba よい安定していて良ければ乗り換え予定。
クリップボード共有
Windows 側から Hyper や Windows Terminal で Manjaro に繋いでいますが、
そのままでは tmux でコピーしても Windows のクリップボードに入りません。
これを lemonade で解決しています。
Manjaro は AUR にあるので
yay -S lemonade-git
でインストール完了。
Windows 用には実行時に黒い窓無しのバックグラウンドで起動できるように
-ldflags="-H windowsgui" を付けてビルドしたいので、
Manjaro の yay がビルドに使ったファイルを流用して
GOOS=windows GOARCH=amd64 go get -u -ldflags="-H windowsgui" github.com/pocke/lemonade
とすると Windows 用の exe が $GOPATH/bin/windows_amd64 にできるので、
これを Windows へコピーします。
Windows 側は
start /b C:\Users\ko-yamamoto\bin\lemonade.exe server --allow="VMのIP"
のような bat を作っておいて、
これもタスクスケジューラでログイン時に起動するようにしています。
tmux の設定は ↓ を参考にさせていただきました。
if-shell 'which lemonade' \ 'bind ] run-shell "lemonade paste | tmux load-buffer -" \; paste-buffer ; \ bind -T copy-mode-vi y send -X copy-pipe-and-cancel "lemonade copy"'
google-ime-skk
Windows では CorvusSKK を使って日本語を入力しています。
辞書に無い言葉を簡単に変換できるように google-ime-skk を利用します。
Manjaro 側で
gem install google-ime-skk
としてインストールしたら、
sudo vim /etc/systemd/system/google-ime-skk.service
↓ ExecStart のパスは環境にあわせて変更してください。
以下は linuxbrew で Ruby をインストールしている場合です。
[Unit] Description=google-ime-skk [Service] ExecStart=/home/linuxbrew/.linuxbrew/bin/google-ime-skk [Install] WantedBy=multi-user.target
あとは
sudo systemctl enable google-ime-skk sudo systemctl status google-ime-skk
としておけば Manjaro 起動時、上で設定したので Windows 起動時に
自動的に google-ime-skk が使えるようになっています。
CorvusSKK の設定から VM の IP を「SKK辞書サーバ」に指定すれば OK です。
その他
- Windows 側では Git Bash を使っています
- Visual Studio Code の
codeに PATH を通すと Git Bash から VScode が起動できて便利 - Hyper も見た目が良いけど Windows Terminal が表示崩れが少ない気がします
おわりに
バックグラウンド起動とコピペ（クリップボード）共有は
設定しておくと使い勝手がかなり良くなるので良いですね。
WSL に慣れてしまっていたので VM の git や sbt がきびきび動いて気持ち良いです！
その後（2019/06/27 追記）
VPN で VM のホストオンリーアダプタが使えないことが判明。。
→ Windows の開発環境を作りなおした ver.2019 の後日談 - あじーん-0.0.2-SNAPSHOT
2019/05/14版_Windows Terminal をビルドしてみる（VS2019)・設定とキーバインド変更
はじめに
Windows Terminal はどんどん開発が進んでいます。
この記事は 2019/05/14 時点でのメモなので
数日後には使えなくなっている可能性があります。
準備
Visual Studio
現時点では Visual Studio 2017 でビルドするのが一番安定するみたいですが
手に入る Visual Studio 2019 の Community を使います。
これは通常どおりインストールするだけ。
WinRT C++ library
いろいろ試した結果 winrt/TerminalApp.h が無いぞとエラーになったので
はじめからインストールしておいた方が無難そう。
むしろこれが原因と思っている。
ここからダウンロードしてインストール。
Windows Terminal のソース
これはふつうに以下から git clone する。
nuget
インストールしていない人は nuget を使えるようにする。
通常どおりの手順でインストールするのが良いはずだが、
Windows Terminal のソース中 dep\nuget\nuget.exe にあるので
PATH のとおったところにコピーしても動作した。
ビルド
- cmd.exe で git clone した Windows Terminal のディレクトリへ移動する
git submodule update --init --recursivenuget restore OpenConsole.sln- Windows Terminal のソースにある
OpenConsole.slnを開いて Visual Studio を起動する。 - 日本語 Windows だと文字コードの問題があるので以下のソースを UTF-8 BOM 付きで保存しなおす。
diff は下の方に。
src\tools\vtpipeterm\main.cppsrc\inc\test\CommonState.hppsrc\terminal\parser\ut_parser\InputEngineTest.cpp
- 同様に
src\tools\vtpipeterm\main.cppの UTF-8 な文字列にu8を追加する。 - Visual Studio のメニューバー下で「Release」「x64」「CascadiaPackage」を選択
- Visual Studio のメニューから「ビルド」→「ソリューションのビルド」を選択してビルド開始
- 無事ビルドが成功したら Visual Studio のメニューから「ビルド」→「ソリューションの配置」を選択して Windows に登録
9 まで完了すると Windows のスタートメニューに Windows Terminal (Dev Build) が追加されている。
なお、手順によってはプラットフォームツールセットを v142 にせよとも見たが
上記の手順では v141 のままで成功している。
src\tools\vtpipeterm\main.cpp の文字列に u8 を付ける diff は以下。
switch(lang)
{
case TEST_LANG_CYRILLIC:
- str = "Лорем ипсум долор сит амет, пер цлита поссит ех, ат мунере фабулас петентиум сит.";
+ str = u8"Лорем ипсум долор сит амет, пер цлита поссит ех, ат мунере фабулас петентиум сит.";
break;
case TEST_LANG_CHINESE:
- str = "側経意責家方家閉討店暖育田庁載社転線宇。";
+ str = u8"側経意責家方家閉討店暖育田庁載社転線宇。";
break;
case TEST_LANG_JAPANESE:
- str = "旅ロ京青利セムレ弱改フヨス波府かばぼ意送でぼ調掲察たス日西重ケアナ住橋ユムミク順待ふかんぼ人奨貯鏡すびそ。";
+ str = u8"旅ロ京青利セムレ弱改フヨス波府かばぼ意送でぼ調掲察たス日西重ケアナ住橋ユムミク順待ふかんぼ人奨貯鏡すびそ。";
break;
case TEST_LANG_KOREAN:
- str = "국민경제의 발전을 위한 중요정책의 수립에 관하여 대통령의 자문에 응하기 위하여 국민경제자문회의를 둘 수 있다.";
+ str = u8"국민경제의 발전을 위한 중요정책의 수립에 관하여 대통령의 자문에 응하기 위하여 국민경제자문회의를 둘 수 있다.";
break;
設定変更
git リポジトリにも説明があるので変更したところだけ。
プロファイル
起動するターミナルやカラーテーマを指定するプロファイル。
WSL を使いたかったので profiles に以下を追加した。
guid は適当に指定したが正しいか調べられていない。
あとはフォントの種類やサイズ等を指定。
{ "guid": "{cmd のプロファイルをもとに適当に指定}", "name": "wsl", "colorscheme": "nord wave", "historySize": 9001, "snapOnInput": true, "cursorColor": "#FFFFFF", "cursorShape": "bar", "commandline": "wsl.exe", "fontFace": "Noto Sans Mono CJK JP", "fontSize": 11, "acrylicOpacity": 0.75, "useAcrylic": true, "closeOnExit": false, "padding": "10, 10, 10, 10" }
タブ関連
タイトルバーの中にタブを表示したかったので以下を追加。
追加位置は defaultProfile や profiles と同階層。
"alwaysShowTabs": false, "showTerminalTitleInTitlebar": true,
デフォルトのターミナル設定
defaultProfile に上で追加した WSL のプロファイルの guid を指定した。
カラーテーマ
Visual Studio Code でも使っている Nord Wave からカラーパレットを移植した。
以下を schemes 以下に追加すると profiles 以下で指定するプロファイルで使えるようになる。
{ "name": "nord wave", "foreground": "#d8dee9", "background": "#212121", "colors": [ "#3b4252", "#bf616a", "#a3be8c", "#ebcb8b", "#81a1c1", "#b48ead", "#88c0d0", "#e5e9f0", "#4c566a", "#bf616a", "#a3be8c", "#ebcb8b", "#81a1c1", "#b48ead", "#8fbcbb", "#eceff4" ] }
キーバインド変更
このままでは
C-tでタブを開くC-wでタブを閉じる
の動作をしてしまい、
シェルの操作や tmux 等に割り当てたキーとバッティングしてしまうので都合が悪い。
特に C-w はシェルで前方語消去のキーなので
間違えてタブを閉じる事故が頻発してしまうのでなんとかしたかった。
キーバインド変更はいずれ設定できるようになると思われるが
現時点ではハードコーディングされていそうなので
src\cascadia\TerminalApp\CascadiaSettings.cpp のソースを変更して対応した。
Ctrl の代わりに Alt でタブを操作するようにしている。
+ // keyBindings.SetKeyBinding(ShortcutAction::NewTab, + // KeyChord{ KeyModifiers::Ctrl, + // static_cast<int>('T') }); keyBindings.SetKeyBinding(ShortcutAction::NewTab, - KeyChord{ KeyModifiers::Ctrl, + KeyChord{ KeyModifiers::Alt, static_cast<int>('T') }); + // keyBindings.SetKeyBinding(ShortcutAction::CloseTab, + // KeyChord{ KeyModifiers::Ctrl, + // static_cast<int>('W') }); keyBindings.SetKeyBinding(ShortcutAction::CloseTab, - KeyChord{ KeyModifiers::Ctrl, + KeyChord{ KeyModifiers::Alt, static_cast<int>('W') });
きっとすぐにキー変更機能もつくだろうからその時には上記変更は戻す予定。
おわりに
こんな感じになりました。
なぜそこまでして使うのか……という気もしないでもないですが
新しいものが使ってみたい試してみたいというのと、
どんどん開発が進んでいくプロダクトに触れてみたいという感じです。
追記（2019/05/21）
git から最新ソース取得したところエラーが発生するようになった。 C++/WinRT 関連だったので NuGet で
Install-Package Microsoft.Windows.CppWinRT -Version 2.0.190506.1
を実行したところ解消した。
気分転換に日本語入力の方法を変えてみる
タイトルのとおり変えてみる
SKK はどうも 5 から 6 年ぶりくらいに使うらしい。
効率とかよりも気分転換がメインなので
「予測変換が優秀な方が早く……」とかは一回忘れてみようと思う。
これを入力している今も SKK で若干もたついているので
いつまで続けるかはわからないけれどそんな記録。
（片手入力派なので Godan はもしかするとすぐにでもやめそう……）
記録だけだとなんだか申し訳ないので少し設定の紹介を。
Win では crvskkserv を利用させてもらって Google から変換候補をとれるように、
Mac では AquaSKK で skkserv を有効にして Gem の google-ime-skk を利用して同じようにしてます。
Emacs からは Win でも Mac でも skkserv に接続させてます。
これで変換がまとまる感じに。
SKK は日本語を入力というか打ち込んでる感じがしていて楽しい。
- coexe.web.fc2.com
- nathancorvussolis.github.io
- github.com
- blog.sushi.money
- なにってもう 8 年も前のことに衝撃を覚えた……
- github.com
Scala福岡2019に参加してきた
この週末にScala福岡2019に参加してきました。
関西から片道2時間ちょっとの旅。
地元が福岡に近いので、
あまり考えずに申し込んでみたら関西からはちょっと遠かった。
でも行って良かった！
個人的には内容について、
Scalaの話ではあるものの
Scalaそのものよりもその周辺にフォーカスしていたのが
とても勉強・参考になったなと思います。
他言語との比較、アーキテクチャ、DDD、ETL、活かし方、パーザコンビネータ。
「Scalaのツッコんだ話がききたい！」人にはもしかするとかもしれませんが、
私のいまの興味関心がその周囲にあるのでとてもタイムリー。
福岡まで行って参加して良かったなと思います。
運営のみなさま、登壇者のみなさま、参加者のみなさまありがとうございました！
あと、みなさんにどっちが目的だよと散々ツッコまれましたが
福岡のお酒、食べ物は最高でした。
ゴマサバをはじめお魚は刺身（お造りとは言わない）でも火を通しても最高。
うどんにラーメン（食べてない）に麺類も最高。
もつ鍋も水炊き（食べてない）も素晴らしい。。
こじゃれたお店もありながら屋台（行けてない）もあって楽しいし、
深夜回ってもやたら活気のあふれた街に驚かされました。
九州というと焼酎のイメージですが、
北側の方は日本酒も多くてとてもおいしいのでさらに良い🍶
食べてない・行けてないところが多いので
ぜひまた福岡に行きたい！！
mozc-mode有効時にmultiple-cursorsが使えないので
ふと気がついた。
multiple-cursorsを使おうとしてもなぜか1つ目のカーソルにしか編集が有効にならない。
例えば以下のようにmultiple-cursorsで1から4行目の行頭にカーソルを作っておいて
この状態で例えば 1 と入力すれば、全ての行頭に 1 が入力されるはず。
それなのになぜかたまに（必ずではなく）
のようになることに気がついた。
なぜだろう？
いろいろ設定を有効・無効切り替えて試していると、
日本語入力のためにmozc-modeが有効になっていると発生することがわかった。
かといって日本語入力しないわけにもいかないし
いまさら数年ぶりにskkに戻るのもなぁと。
本質的には何が原因なのかまで突き止められていないけれど、
ひとまずはmultiple-cursorsを使いたいときにmozc-modeを無効にすればワークアラウンド。
ただ、ATOKを普段は使っていて
- 変換 → 日本語入力オン
- 無変換 → 直接入力
としているので、
Emacsでも同じような挙動にしようと
どのバッファでもmozc-modeをオンにしておいて
- 変換 → 日本語入力有効
- 無変換 → 日本語入力無効
としていたのだけれど、
これだと常にmozc-modeがオンなのでmultiple-cursorsが使えない……。
ということはEmacsでのキーの挙動が
- 変換 → mozc-mode有効にしてさらに日本語入力有効
- 無変換 → mozc-mode無効
となれば良い。
少し悩んだのがmozc-mode有効時に直接mozc-modeを無効にする方法。
というのも、mozc-modeを有効にしていると
キーがmozc（WSLなのでGoogle日本語入力）に取られてしまうので
無変換キーを押すと日本語がオフになるだけでmozc-modeは有効のまま。
無変換キーを2回連打すればmozc-modeもオフになるけどなんだか微妙。
無変換キーを1回押すだけでmozc-modeがオフになってほしい。
けっきょく下のようにmozc-handle-event に無変換キー入力の場合の挙動をdefadviceして
無変換キー入力時はそのままmozc-modeをオフにするようにしてみた。
;; mozcオンでも無変換キーはEmacsにわたすようにキーイベントを横取りする (defadvice mozc-handle-event (around intercept-keys (event)) (if (member event (list 'zenkaku-hankaku 'muhenkan)) (progn (mozc-clean-up-session) ;; (toggle-input-method) (mozc-mode nil) (deactivate-input-method)) (progn ;(message "%s" event) ;debug ad-do-it))) (ad-activate 'mozc-handle-event)
ついでに変換キーを押すとmozc-modeをオンにした上で
日本語入力モードもオンにするように以下の設定も追加。
;; 変換キーでon (global-set-key [henkan] (lambda () (interactive) (mozc-mode 1) (when (null current-input-method) (toggle-input-method)))) ;; 無変換キーでoff (global-set-key [muhenkan] (lambda () (interactive) (deactivate-input-method)))
あわせると以下のような感じになりました。
;; 変換キーでon (global-set-key [henkan] (lambda () (interactive) (mozc-mode 1) (when (null current-input-method) (toggle-input-method)))) ;; 無変換キーでoff (global-set-key [muhenkan] (lambda () (interactive) (deactivate-input-method))) ;; mozcオンでも無変換キーはEmacsにわたすようにキーイベントを横取りする (defadvice mozc-handle-event (around intercept-keys (event)) (if (member event (list 'zenkaku-hankaku 'muhenkan)) (progn (mozc-clean-up-session) ;; (toggle-input-method) (mozc-mode nil) (deactivate-input-method)) (progn ;(message "%s" event) ;debug ad-do-it))) (ad-activate 'mozc-handle-event)
いまのところ変換・無変換キーで違和感無く日本語入力の切り替えができていて満足。
そもそもの日本語入力中にmultiple-cursorsを使いたいときは
multiple-cursorsの前に無変換キーを1回押す必要があるけれど
まあ許容範囲かな……。
これを書いてて気がついたけど、
multiple-cursorsがはじまるのをフック（multiple-cursors-mode-hook）して
mozc-modeをオフにしても良い気もする。
こんな感じ。
(add-hook 'multiple-cursors-mode-hook (lambda () (mozc-mode nil) (deactivate-input-method)))
それにしても調べても見かけなかったから
mozc-modeとmultiple-cursorsの併用はニッチなのだろう……。
