何をいってるんだ…、というタイトルですが😅
Surface Go 2 をサブ機として愛用していて、主な用途は会議中のPenでのメモ取りと、あとはKindleやYoutube/Netflix試聴といったiPadっぽい使い方が中心だけど、
たまにこれで仕事もしたりする。
そういう時は母艦にリモートデスクトップして作業している。画面サイズは小さくなってしまうが、そこそこの回線速度があれば、まったく違和感なく作業できてなかなか体験が良い。
唯一の問題としては、リモートデスクトップで繋いだ瞬間、母艦のほうのPCはログイン画面に戻ってしまうということ。
多くの場合これはまったく問題ない挙動なのだが、そのままの状態だと、リビングのTVでPCからストリーミングでゲームをしようとすると動かないのですね。<a class="footref" href="#fn1" id="r1">[1]</a>
PCのある部屋まで行かず、リモートからログイン状態に戻すことはできないかと思って検索した結果、
<pre><code class="text">tscon 1 /dest:console</code></pre>

というコマンドをコマンドプロンプト(管理者権限)で実行してやれば良いらしい。<a class="footref" href="#fn2" id="r2">[2]</a>
ソースは<a href="https://superuser.com/questions/80334/remote-desktop-connection-without-locking-the-remote-computer">このへん</a>とかいろいろQAサイトがひっかかる。
これを書いたbatファイルをつくって、それのショートカットをどっか適当なところにおいて、ショートカットの設定で管理者権限で実行するようにしておく。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50750753133/in/datetaken-public/" title="logout.bat"><img src="https://live.staticflickr.com/65535/50750753133_d2dfe146e6_b.jpg" width="982" height="849" alt="logout.bat"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

そうするとこんな感じで、Winキーからの検索でひっかかってくれるので楽。それをリモートデスクトップから実行すれば良い。
という自分用メモ。
<aside class="footdef">
<a href="#r1">[1]</a> <a href="https://store.google.com/us/product/chromecast_google_tv">Chromecast with Google TV</a> にPS4コントローラをペアリングして、Steam Link とか moonlight でPCゲーをまったりあそぶ、というのをよくやっている 
<a href="#r2">[2]</a> 昔のWindowsではこの 1 が 0 だったとのこと 
</aside>

リモートデスクトップ終了後、自動で再ログインする方法

<a href="https://x410.dev/">X410</a>というX Window Serverがかなり便利。X WindowをVNCみたいにまるっと表示するのではなくて、アプリケーション毎にWindowを分けて表示してくれるモードがあり<a class="footref" href="#fn1" id="r1">[1]</a>、LinuxのGUIアプリを普通のWindowsアプリと同じように扱える。
<div class="image">
 <div>
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50302921416/in/datetaken-public/" title="Run Linux GUI app as normal windows application"><img src="https://live.staticflickr.com/65535/50302921416_07462c0010_c.jpg" width="800" height="450" alt="Run Linux GUI app as normal windows application"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
 <div class="caption">ReactNative開発の図。左のDebuggerはLinux版</div>
 </div>
</div>

ただあくまでLinux上で動いているものなので、フォントとか日本語入力とか、キーボード周りの設定とかはもちろんLinux側で設定する必要がある。
日本語入力に関しては、それが必要なアプリは自分の使うアプリではいまのところEmacsしかないが、Emacsはそれ自体で日本語入力が可能なので特に設定する必要がない。
自分がEmacsのためにインストールしたのは以下:
<pre><code class="sh"># Emacs&#12391;&#20351;&#12387;&#12390;&#12427;&#12513;&#12452;&#12531;&#12501;&#12457;&#12531;&#12488;
yay -S otf-source-han-code-jp

# &#33521;&#25968;&#26085;&#26412;&#35486;&#20197;&#22806;&amp;&#32117;&#25991;&#23383;&#29992;
yay -S noto-fonts noto-fonts-cjk noto-fonts-emoji

# skkserv
yay -S yaskkserv

# for SandS
yay -S xcape</code></pre>

skkservは使わずでローカルの辞書だけでもskkはうごくのだが、
yaskkservは<a href="https://twitter.com/typester/status/1299885480058601472?s=20">ここ</a>にも書いたけど、入力した単語がローカル辞書に見つからなかった場合にGoogle検索を利用してくれるので、新語や人名の入力に便利なので使っている。
一度入力したものは個人辞書のほうに追加されるので、毎回Googleにアクセスがいくわけではないので安心して良い。
またyaskkservはArchLinuxパッケージ付属のsystemd unitファイルはbindアドレスが指定されていなくフルオープンになってしまうので、
<pre><code class="systemd"># ~/.config/systemd/user/yaskkserv.service
[Unit]
Description=Yet another SKK Japanese input method dictionary server

[Service]
ExecStart=/usr/bin/yaskkserv_hairy --no-daemonize --address 127.0.0.1 --google-japanese-input=notfound /usr/share/skk/SKK-JISYO.L.yaskkserv

[Install]
WantedBy=default.target</code></pre>

みたいな127.0.0.1にバインドするuser unitを自分で作って起動してる(WSL2の場合)。WSL1では使う時に毎回手動で起動しているw
あと個人的に必須といえるのがSandSおよびキーリピート加速だが、これは<a href="https://unknownplace.org/blog/2020/06/05/sands/">Linuxの時に使っていたもの</a>がそのまま使える。
<pre><code class="sh"># SandS
xmodmap -e 'keycode 255=space'
xmodmap -e 'keycode 65=Shift_L'
xcape -e '#65=space'

# &#12461;&#12540;&#12522;&#12500;&#12540;&#12488;
xset r rate 200 100</code></pre>

みたいな感じ。
あと、Windows側のSKKFEPとかでSandSの設定をしていると、そのままだとX Windowアプリのほうのスペースの挙動がおかしくなるので、入力ソースを別のもの(Englishとか)にしてあげる必要がある。
その時に全体の入力ソースが変わってしまうとアプリ切り替えるたびにソースを変更しなおす必要があってかなり面倒なので、Windows側の設定でアプリ毎に別の入力ソースを使える設定にしておくと良い。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50302162071/in/datetaken-public/" title="Input source setting"><img src="https://live.staticflickr.com/65535/50302162071_e2d19dd440_o.png" width="735" height="637" alt="Input source setting"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

↑のチェックボックスのところ。
こんなかんじでいろいろやると、Windows上でも違和感なくLinuxアプリが使える。いろいろやっていることが(当たり前だが)完全にLinuxでやってたことと同じなので、Linuxデスクトップを使っている人は自然に使えるはず。
あとやっぱウィンドウマネージャさえなんとかなればな〜〜という感じがいなめない。bug.nにはだいぶなれてサクサクつかえるようになってきたものの、やはりawesomeとちがって、
<ul>
<li>Emacs + Chrome</li>
<li>Emacs + Terminal</li>
<li>Terminal + Chrome</li>
<li>Terminal + Emacs</li>
</ul>

みたいな組み合せを瞬時に変えられないのがめんどくさい。いや、できることはできるのだが、そのためにはそのように設定したwindow(tag)を作っておく必要がある。
awesomeの場合はTerminalをtag0で、Emacsをtag1で、Chromeをtag2で出すようにしておいて、side-by-side表示したいときにはtag0&amp;1を表示する、みたいにtagをくみあわせて画面をつくれるのが良いのだ。
ここさえなんとかなればWindows上でもかなり快適にすごせそうなので、がんばって自作してみるのも手かもなぁと考えはじめている。
あとは、ArchWSL/ArchWSL2の作者には足を向けて寝られない。どちらもとてもよくカスタマイズされていて、Archをこういう環境<a class="footref" href="#fn2" id="r2">[2]</a>にいれて使うときにハマるポイントがほぼつぶされていて、とても快適に使える。ありがたい。
<aside class="footdef">
<a href="#r1">[1]</a> それがデフォルトっぽい 
<a href="#r2">[2]</a> たとえばTermuxArchとか使うとよくわかる。(TermuxはandroidでWSL1みたいなことをする環境) 
</aside>

WSL上のGUIアプリケーションの設定いろいろ、SandSとかキーリピート加速とか

WSLで動くLinuxとクリップボードを共有する方法は僕が知るかぎりでも、
<ol>
<li>clip.exeを使う</li>
<li>X Window Serverを経由する</li>
</ol>

などがある。自分はGUIアプリを使うこともあるので、もともとX Serverを立てているということもあり、汎用性が高い2のほうを使っている。
実際、
<pre><code class="sh"># copy
cat foo.txt | xsel -bi

# paste
xsel -bo &gt; foo.txt</code></pre>

というような操作はLinuxを使う時と一緒なので覚えやすい。自分はtmuxでcopyすると自動でXのクリップボードにもcopyされるという設定をもともと使っているので、それがそのまま使えるというのもありがたい。
ただ、このXのクリップボードをWindows側と共有してくれるには、それに対応したX Window Serverを使う必要がある。
自分は X410 というのを使っている。<a class="footref" href="#fn1" id="r1">[1]</a>
WSL上のLinuxとWindowsクリップボードの共有に関してはこのXを使う方法でほぼ問題ない。やることは、
<ul>
<li>Windows側でX Serverをあげておく</li>
<li>Linux側でDISPLAY環境変数にその情報を入れておく<a class="footref" href="#fn2" id="r2">[2]</a></li>
</ul>

だけ。
GUIでEmacsを使っていればこれだけで良いのだが、今はbug.nの操作に慣れていないということもあり、CLI上でEmacsを使っていて、そちらでも自動でXのクリップボードが同期されてくれるとうれしい。
ググると<a href="https://stackoverflow.com/a/21833639">stackoverflowにxselを使った良い設定を書いている人がいた</a>ので、それをそのまま拝借して以下の設定を追加:
<pre><code class="lisp-interaction">;; sync with x clipboard
(unless window-system
 (when (getenv "DISPLAY")
 ;; Callback for when user cuts
 (defun xsel-cut-function (text &amp;optional push)
 ;; Insert text to temp-buffer, and "send" content to xsel stdin
 (with-temp-buffer
 (insert text)
 ;; I prefer using the "clipboard" selection (the one the
 ;; typically is used by c-c/c-v) before the primary selection
 ;; (that uses mouse-select/middle-button-click)
 (call-process-region (point-min) (point-max) "xsel" nil 0 nil "--clipboard" "--input")))
 ;; Call back for when user pastes
 (defun xsel-paste-function()
 ;; Find out what is current selection by xsel. If it is different
 ;; from the top of the kill-ring (car kill-ring), then return
 ;; it. Else, nil is returned, so whatever is in the top of the
 ;; kill-ring will be used.
 (let ((xsel-output (shell-command-to-string "xsel --clipboard --output")))
 (unless (string= (car kill-ring) xsel-output)
 xsel-output )))
 ;; Attach callbacks to hooks
 (setq interprogram-cut-function 'xsel-cut-function)
 (setq interprogram-paste-function 'xsel-paste-function)
 ;; Idea from
 ;; http://shreevatsa.wordpress.com/2006/10/22/emacs-copypaste-and-x/
 ;; http://www.mail-archive.com/help-gnu-emacs@gnu.org/msg03577.html
 ))</code></pre>

これでかなり便利に。bug.nに慣れたらGUI版に戻そうとおもっていたが、このままでもいいかもなぁと思いはじめている。
<aside class="footdef">
<a href="#r1">[1]</a> よくセールしてるから定価で買うと損らしいので注意w ref: <a href="https://twitter.com/typester/status/1273708353202446336">https://twitter.com/typester/status/1273708353202446336</a>のコメント
<a href="#r2">[2]</a> WSL1では <code>127.0.0.1:0</code> 、WSL2では <code>$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0</code> を入れている
</aside>

WSL上のEmacs(nw)とWindowsとでクリップボードを共有する方法

サブPCとしてSurface Goを使っていることもあって、やっぱりメイン環境がHiDPIじゃないのがきになってきていたので、
<a href="https://www.eizo.com/products/flexscan/ev2785/">4Kモニタ</a>を導入してみたのだが、Linuxで使おうとするといろいろ問題がでてきた。
まず、LinuxでのHiDPI設定というのはいまだにこなれてなくて、アプリごとにいろいろな設定をする必要がある。詳しくは<a href="https://wiki.archlinux.org/index.php/HiDPI">ArchWikiの該当ページ</a>とかを参照。
まぁまだそれは良いとして、いまの自分の環境のように、HiDPIなモニタとそうじゃないモニタが混在しているマルチモニタ環境だと、HiDPI設定をしたアプリを普通のモニタで表示するとめっちゃでっかく表示されてしまったりと、かなりツラいことになる。
HiDPIなモニタで環境を統一してしまえばいいのかもしれないが、個人的にはHiDPIなモニタと、144Hzなど高リフレッシュレートのモニタの組み合せが現状ゲーマーエンジニア的にはベストなデュアルモニタ構成であると思っているので、しばらくはこの構成を維持しそうな気がしている。<a class="footref" href="#fn1" id="r1">[1]</a>
そんなわけでLinuxでこのディスプレイ構成は痛みしかなさそうなので、ダメ元でWindowsをメイン環境として試してみることにした。<a class="footref" href="#fn2" id="r2">[2]</a>
Surface Goで開発環境は一応整えていて、開発環境として使えはする、というところまでは分かっているのだが、快適な作業環境という意味でかなり重要なのがタイル型のウィンドウマネージャ的なウィンドウ操作ができるかどうか、ということがある。
素のWindowsで開発していてやはり気になるのが、各ウィンドウ位置を調整するのに手間どる、というところだ。
Linuxでは<a href="https://awesomewm.org/">awesome</a>というタイル型WMを愛用していて、これを使うとEmacsをフルスクリーンで使っているところに、シュッとChromeをside-by-side表示したりまたEmacsにもどしたり、ChromeにかわりにTerminalを出したり、ドキュメントビューワをだしたり、といったことが瞬時に行える。
この快適さに慣れてしまうと、マウスでちまちまウィンドウの位置を変える、とかはめんどくさくてやってられない。
Windows 10にはビルドインでWinキーとの組み合せで画面分割ができる仕組みがあってがんばって使ってみたものの、やはりタイル型WMにはほど遠い使い勝手。
Windowsで動くタイル型WMはないものか、と探すとすぐに見つかるのが<a href="https://github.com/fuhsjr00/bug.n">bug.n</a>というWM。AutoHotKeyでうごいてるらしいことにも驚く。
さっそく少し触ってみると、tagの概念がawesomeと違い(awesome流のほうが好み)、ワークフローを考えなおさないといけないが、なんとかなりそう。
というわけで本導入してみたら、ハマるわハマるわ…。bug.n自体もDPI違いのマルチディスプレイだとすんなりとは動いてくれないのであった………。本末転倒とはまさにこのこと😢
いろいろやってなんとか動かすことができたのが以下の環境:
<ul>
<li>8.4.0という古いバージョンを使う</li>
<li><code>Config_verticalBarPos=tray</code> は使わない</li>
</ul>

です。 <code>Config_verticalBarPos=tray</code> はbug.nのステータスバーをWindowsのタスクバーの上に表示してくれてカッコ良いし、違和感がないので、ほんとうは使いたかったが、どうしてもこれを有効にしたまま上手く動かすことができなかった。
とりあえずこの環境ならなんとかうまくうごいてくれて、ギリギリメイン環境としていけるかなぁ、という感じ。ちょっとbug.nが不安定すぎるのが気になる。とにかくしばらくこの状態で使ってみることにする。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50280877171/in/datetaken-public/" title="trying bug.n"><img src="https://live.staticflickr.com/65535/50280877171_6afefb0cf6_b.jpg" width="1024" height="575" alt="trying bug.n"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

こんな感じ。(これはあんまりタイル型っぽくないが…)
bug.nにしろ、WSLにしろ、なんとなく使えてはいるが、そこはかとなく本物じゃない感というか、不安定感があって、使っていて不安になる。
とはいえこのディスプレイ環境のままLinuxを使い続けるのはもっとつらそうだしな、とう感じで消去法で環境をきめていて、なんだかなーという感じだ。せっかく使うからにはもうちょいがんばってWindowsを使いやすくしていきていとは思っているが、いまのところ最低限使える程度、という感じ。
<aside class="footdef">
<a href="#r1">[1]</a> 4K+144Hzでゲームをうごかすスペックがまだまだ現実的ではないため
<a href="#r2">[2]</a> ちょうど新しくPCを組んだところだったというのも理由の一つ 
</aside>

Windowsをメイン開発環境として使ってみる試みでbug.nを導入

Surface Goでの作業環境をぼちぼち構築している。
家庭内リモート開発用<a class="footref" href="#fn1" id="r1">[1]</a>としてはほぼ完成した感はあるが、その中で見つけた、<a href="https://icons8.com/lunacy">Lunacy</a>というアプリが素晴しい。
一言で言えば、 Sketch for Windowsな感じで、同じようなベクターデザインツール。
Sketchのデータを完璧に開ける<a class="footref" href="#fn2" id="r2">[2]</a>ところがかなりポイントたかい上、それ以外もかなり良くできたアプリで質感も高く、これが無料なのはほんとうに意味がわからないレベル。
開発環境をLinuxに移行してから不便だったのがデザインデータの確認。figmaやzeplinとかオンラインでチェックできる案件だけであれば良いのだが、自分の場合はいまのところまだまだSketchファイルを開く必要があるので、そのためだけにMacを起動したりしていた。<a class="footref" href="#fn3" id="r3">[3]</a>
これがあればもうそんなことしなくてよくなる。メインのLinux環境で使えるわけではなく、Surfaceでやる必要がもちろんあるのだが、それでもだいぶん便利になる。
Windowsアプリってなんかあんまりかっこよくないイメージだったけど、こういうかっこいいアプリもあるんだなと気付かせてくれたアプリでもある。
これがWindowsプラットフォーム上のネイティブ実装、というか推奨されているUI実装なのかは、いまの自分ではわからないが、そうだったとしたらけっこう今後でてくるアプリは期待できるなぁ、とも思ったりした。
<aside class="footdef">
<a href="#r1">[1]</a> 仕事部屋のデスクトップにsshして作業するという意味
<a href="#r2">[2]</a> たまたま手元にあった数サンプルでしか試していないが 
<a href="#r3">[3]</a> 他には<a href="https://avocode.com/">avocode</a>とかも試したが満足いく結果を得られていない 
</aside>

LunacyというSketch for Windowsなアプリがとても良い

最近(といっても半年くらいたってる気がするが)、<a href="https://www.notion.so/">Notion</a>から<a href="https://orgmode.org/">org-mode</a>へドキュメント管理を戻している。
NotionはUS移住前から使っているので、2年以上使っていたことになる。もともとorg-modeを完全に置き換える形で、
<ul>
<li>タスク・習慣管理</li>
<li>メモ</li>
<li>ブックマーク</li>
<li>ゲーム・読書・映画記録</li>
<li>家族とのドキュメント共有</li>
</ul>

などかなりガチで使うようになっていたのだが、根本的な文章の書き味がEmacs上でやるのと比べ致命的に悪いという問題があった。
また、<a href="https://roamresearch.com/">Roam Research</a>とか<a href="https://obsidian.md/">Obsidian</a>のようなブレインマップを構築するようなノートアプリがいろいろ出てきているのも気になっていた。Notionでそういうことをするのはなかなか難しそうに思う。
そんな中で、org-modeでRoam Researchみたいなことをする<a href="https://www.orgroam.com/">org-roam</a>というものを知って、しばらく試していたのだが、なかなか良さそうなので本格的にorgに戻ってきている。
いまのところ、
<ul>
<li>タスク・習慣管理</li>
<li>メモ</li>
<li>ブックマーク</li>
</ul>

はEmacs上でおこなうように戻した。Notion上にあるものはまだ特にimportしたりはしていない。こういうのは最初から完璧を求めないで、徐々に気がむいたときにアップグレードするくらいじゃないと疲れてしまうし、完璧を目指すと破綻しやすいということが長年の経験で分かっているのである。(大人になったものだ)
ただ、orgの弱点はやはりモバイル環境だ。いまのところ、スマホしかないところでのメモやブックマークは現状いったんスマホ上に貯めておいて、適当なタイミングでorgのほうで手動で移している。これはそのうちもうちょい改善したいが、Notionのようにはなかなかいかないだろう。
そういうこともあって家族との共有は今後もNotionでいいかなと感じている。
ただ、やはり個人用のタスク管理+情報集約ツールとして、orgはやっぱりいいなぁと思う。org-roamはいまのところはまだ情報が少ないのであまりうれしさを感じないが、Zettelkasten Method的な情報管理には興味があるし、ゆっくり学んでいきたい。
それで、ブックマークに関してがこのエントリの本題なのだが、ブラウザとかからダイレクトにorgに記事を差し込めるorg-protocolという仕組みがあるけど、setupがかなり面倒なのでいままでは<a href="https://github.com/rexim/org-cliplink">org-cliplink</a>を使用して半手動で行なっていた。で、今回その重い腰をあげてorg-protocolをsetupしましたよ、という話。
ただでさえめんどそうなorg-protocolの設定が、WSL上でEmacsを使っているとよりめんどうになる。さらに自分の場合は<a href="https://github.com/sorah/subsystemctl">subsystemd</a>を使ってsystemdを動かしているので、さらにちょっとした修正が必要になった。
この環境でorg-protocolを使うには以下のようなregistryファイルを作って、取り込んでやればOK。すると、 <code>org://</code> をWSL上(&amp; subsystemd上)のemacsでリンクを受け取ることができるようになる。
<pre><code class="text">REGEDIT4

[HKEY_CLASSES_ROOT\org-protocol]
@="URL:Org Protocol"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\org-protocol\shell]
[HKEY_CLASSES_ROOT\org-protocol\shell\open]
[HKEY_CLASSES_ROOT\org-protocol\shell\open\command]
@="\"C:\\Windows\\System32\\wsl.exe\" -u typester -d ArchLinux subsystemctl exec emacsclient -- -s /run/user/1000/emacs/server \"%1\""</code></pre>

まぁ全く同じ環境の人はほとんどいないとおもうので、個人的な備忘録として残しておく。
あとは適当にbookmarkletをブラウザにセットすれば完了。ほんとはホットキーでブックマークしたいので、そのうち調べる。

Notionからorg-modeへの出戻りと、WSL上でのorg-protocol

Windows上でAndroidアプリを開発するとき、普通の人、というかWindowsに慣れている人は、普通にWindows上で開発すればいい案件なのだが、自分にとってはLinuxの世界で開発できたほうがいろいろ都合がよいので、WSL2上で開発をしている。
Android Studioや、<a href="https://github.com/jhen0409/react-native-debugger">react-native-debugger</a>といったツールたちは、WSL2+X Server (X410) という環境でも問題なく動く。
しかし問題はAndroidエミュレータを、WSL2上でうごかすことが現状ではできないのだ。<a class="footref" href="#fn1" id="r1">[1]</a>
それで、いままでうまい方法がよくわからなかったので、WSL2上でつくったapkを、Windowsのほうのadbで <code>adb install</code> して実機なりエミュレータにいれる、というかなりめんどくさいことをしていた。
ただ、通常ほとんどの開発がReact Nativeでのものだったため、ネイティブのほうの実装を変更することはあまりなく、一度apkを実機orエミュレータにインストールさえしてしまえばapkを入れなおす必要はないので、あまり問題にはなっていなかった。
ただ最近はReact Nativeばかり書いていて、何年もネイティブ開発をしていないという状況がつづいてしまっているので、ネイティブのほうのキャッチアップもしておかないとな〜という気持ちがたかまってきていて、Holiday projectとしていま仕事で書いてるわりとでかめのアプリをネイティブで再実装する、というのをはじめていて、そうなるってくるとこのいびつな開発環境だとつらすぎるので、ようやく重い腰をあげて、なにか良い方法はないかしらべはじめた。

<h3>TL;DR:</h3>
Windowsの <code>5037</code> ポートをWSL2へreverse port forward。(WLS2上で 127.0.0.1:5037 がWindowsの5037につながるように、という意味)

<h3>前準備</h3>
Windowsのほうにもadbが必要なのでAndroid Studioをいれておく。どのみちエミュレータをそっちで動かすので入れるとは思うが。

<h3>ポートフォワード</h3>
adbのhelpコマンドを良くみてみると
<pre><code class="text">-H name of adb server host [default=localhost]
-P port of adb server [default=5037]</code></pre>

という部分があって、他のホストのadb serverを使えそうな記述がある。しかし、adbは <code>127.0.0.1:5037</code> にbindしてしまうので、実質そのままでは他のホストにつなぐことはできない。<a class="footref" href="#fn2" id="r2">[2]</a>
なのでポートフォワードしてみることにした。方法はいろいろあるが、自分の場合はWSL1の環境もあるので、WSL1から
<pre><code class="sh">ssh -R 5037:127.0.0.1:5037 127.0.0.1</code></pre>

としている。127.0.0.1に接続していてなんのこっちゃという感じだが、Windowsホストの22番ポートはWSL2ホストにforwardされるようにしているのでこれでWSL2につながるのである。そうしてない人は接続先をWSL2のアドレスにする必要あり。
あと、これをする前にWSL2上でadb serverがうごいている場合はあらかじめ <code>adb kill-server</code> しておく、またWindowsのほうでは <code>adb start-server</code> しておく必要がある。<a class="footref" href="#fn3" id="r3">[3]</a>
この状態で、WSL2上で <code>adb devices</code> とかしてみると、Windowsのほうに繋っているエミュレータや実機が普通に見えるようになっているはず。adb shellや、adb installなどもWindowsから操作するのとおなじことがWSL2からおこなえるようになる。便利!
いままでこの環境だとうまく使えなかった<a href="https://fbflipper.com/">Flipper</a>もちゃんと(WSL2サイドで)動くようになってうれしいかぎり。

<h3>余談</h3>
とまぁ、最終的には実際5037を転送するだけでよかったのだが、最初はリモートのAndroidエミュレータに繋ぐ方法、みたいな検索ワードで調べていたのでまったく答えにたどりつけず、ハマりにハマってかなりの時間をとかしてしまった。あと、Flipperを起動するとadb serverが自動で起動されてしまうことに気付かず、 <code>kill-server</code> してるのになぜか終了できない!(pidがかわってうまれかわってくる)、みたいになってWSL2上のadb serverがとめられなくなったりもした。pstreeでみてみてもsystemdが親にみえるため、Flipperが原因だとはなかなか気が付けなかった。
とはいえ最終的につかえるようになったので、時間をかけたうえに「なんの成果も!! 得られませんでした!!」となる最悪の自体はさけられたのでよしとしよう。
<aside class="footdef">
<a href="#r1">[1]</a> intel CPUの人はできるかもしれない。AMDのCPUではまだ<a href="https://techcommunity.microsoft.com/t5/virtualization/amd-nested-virtualization-support/ba-p/1434841">nested virtualizationが一般向けには降りてきていない</a>ので使えないっぽい 
<a href="#r2">[2]</a> <code>-a</code> というオプションが <code>listen on all network interfaces, not just localhost</code> と書いてあるけどこれつけて <code>start-server</code> しても127.0.0.1にbindされていた😅
<a href="#r3">[3]</a> たぶんデフォルトの状態だとAndroidエミュレータを起動するだけでadb serverもたちあがるようになってるので実際はwindowsのほうで明示的にadb serverを上げることはあまりないかもしれない 
</aside>

WSL2のadbからWindowsのAndroid Emulatorを使う

WSL1/2環境として<a href="https://github.com/yuk7/ArchWSL">ArchWSL</a>を愛用してきたけど、そろそろ自分でWSLイメージを作ってみたいな。という思いがあり、<a href="https://docs.microsoft.com/en-us/windows/wsl/build-custom-distro">公式ページのドキュメント</a>に従って自分のイメージを作ってみようとしたのだが、いかんせん、Visual Studioの知識がなさすぎて、Distro Launcherのビルドすらままならない😭
Visual Studio 2019、installできるcomponentの選択肢が多過ぎてなにが必要なのか、とかが全然わからない。まじで難しいなぁ。ビルドしようとするときに足りてなかったら教えてくれる、とかそういう心づかいが欲しい…。
それでしばらく調べてみたら、Distro Launcherを使わずにイメージを作ってる人を発見:
<blockquote>
<a href="https://www.spatacoli.com/blog/2020/03/custom-wsl-image/">Custom WSL Image - Spatacoli</a>
</blockquote>

なんだ、 <code>wsl --import</code> なんていう方法もあるんだ。しかも、dockerイメージからファイルをとってきていて賢い。
ArchLinuxのdockerイメージはArchLinux公式がメンテしてるから安心だし。
そんなわけで作ってみた。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50889660557/in/datetaken-public/" title="ArchLinux on WSL2"><img src="https://live.staticflickr.com/65535/50889660557_53c71f182b_b.jpg" width="1024" height="590" alt="ArchLinux on WSL2"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

イメージ作成手順はリンク先の通りだから割愛。
Distro Launcherを使っていないイメージの場合、デフォルトユーザーをregistryに保存したりということができないので、 <code>wsl -u typester</code> のように毎回ユーザーを指定する必要があるが、Windows Terminalの設定にそれを書いてしまえば意識しないですむのでまったく問題ない。
あと、この記事でWindows Terminalの設定でタブバーのiconを自由に変更できるのを知ったので、真似してArchLinuxのアイコンにしてみたところなかなか満足度がたかくなった。おすすめ。
以下追加で作業したこと。

<h3>systemd (WSL2)</h3>
systemdはArchWSLのドキュメントからもリンクされているが、 <a href="https://github.com/sorah/subsystemctl">https://github.com/sorah/subsystemctl</a> を使うと簡単。
Windows Terminalを起動後、
<pre><code class="shell-script">sudo -E subsystemctl start
subsystemctl shell</code></pre>

というおまじないをしてる。Distro Launcher方式なら起動時に自動で実行されるようにできるかもだが、いまのままでも基本一度立ち上げたらずっと立ち上げっぱなしなのであまり問題ではない。

<h3>fakeroot-tcp (WSL1)</h3>
ArchLinuxはpackageの作成にfakerootという仕組みをつかうのだが、これがWSL1だと動かないので、代わりに<a href="https://aur.archlinux.org/packages/fakeroot-tcp/">fakeroot-tcp</a>というのを使う必要がある。
これは必須というわけではないが、なにかAURのパッケージを使う予定があるなら必要になる。
しかし、普通にAURでfakeroot-tcpパッケージを作ろうとするとそれにfakerootが必要で詰む。ので、一旦 <code>makepkg</code> でfakeroot-tcpのパッケージをつくるのはやめて、
<ol>
<li>一時的にどこかあとで消せるところに普通に自前でmakeして入れる<a class="footref" href="#fn1" id="r1">[1]</a></li>
<li>そこにパスを通すか <code>/usr/sbin/fakeroot</code> をそこへのsymlinkに置き換える</li>
<li>これでfakerootできるようになるので、あらためて <code>makepkg -si</code> して入れ直す</li>
<li>一時的にいれてたのを消す</li>
</ol>

みたいな感じでやる必要があってめんどくさい。このらへんの作業は<a href="https://github.com/TermuxArch/TermuxArch">TermuxArch</a>と同じなので自分的には慣れてしまっているが、最初はかなり苦労した覚えがある😅
あとはほんとに普通に使える。先人の知恵に感謝。
<aside class="footdef">
<a href="#r1">[1]</a> ビルド方法はPKGBUILDみれば分かる。prefixだけ変える感じで。 
</aside>

DockerイメージからWSLイメージを作る

TLDR: <a href="https://unknownplace.org/blog/2019/01/24/grive/">Google Drive経由で同期していた</a>orgファイルなどの同期を<a href="https://syncthing.net/">Syncthing</a>を使うように変更したら劇的に便利になった、という話。
最近はorg-modeを使いたおしている<a class="footref" href="#fn1" id="r1">[1]</a>のだが、いままではorgファイルの同期をGoogle Drive経由でやっていた。
これにいろいろ不満あった:
<ol>
<li>grive2がちょいちょい動かなくなる</li>
<li>grive2がちょくちょくビルドできなくなる or OAuth認証ができなくなる</li>
<li>Androidとの同期が微妙</li>
</ol>

1は、Google Driveへの同期ツールとしてgrive2というのを使っているのだが、このgrive2がたまーにうごかなくなることがある。
これはほとんどの場合、ArchLinuxでgrive2は公式パッケージには入っておらずAURになっているがboostに依存している、というのが原因。boostが更新されてもAURであるgrive2はそのまま再ビルドされないままになってしまい、結果libraryが読めなくなってうごかなくなる。
2は、ビルドできなくなるのはArchLinuxが新しすぎるパッケージを採用しすぎるのが原因なきがするが、最近も<a href="https://github.com/vitalif/grive2/issues/370">最新のgrepが入ってるとビルドできない</a>、みたいなのがあってこまった。OAuthのほうはよくわからないが(Googleのポリシー周り？)、しばらく新規認証できなくて新しいPCを同期対象にできなかったりもあった。
3はAndroidはGoogleケータイだしネイティブでGoogle Drive同期できるのでは？ みたいに思うかもしれませんが、実際のファイルとして同期しようとするとサードパーティツールをつかわないとできないのですね。<a href="https://play.google.com/store/apps/details?id=com.ttxapps.drivesync">Autosync for Google Drive</a>というのを使っていたが、これは無料だと1時間に1回しか同期してくれないのであった。
有料でもそんなに高くないのだけど、1,2の理由からGoogle Driveでのファイル同期は微妙だなという思いがあって購入しないままいまにいたる。
Androidでのorgの編集は
<ul>
<li>出先でなにかおもいついたことをinboxにメモ(あとでPC上でグルーミング)</li>
<li>習慣をやったよ、とマークする</li>
</ul>

だけなので、基本的に1時間syncでも問題がないというのもあった。
そんな感じでgriveをちょいちょい直して使う、みたいなことをしていたのだが、grepが原因でビルドできなくなったのをきっかけにもうこんなんやってられーん、という感じになってしまい重い腰をあげてなんとかしようとしてみた。
日常使っている端末(PC, Mac, Android)でいいかんじでファイル同期ができるものを探したところ、Syncthingがよさそうに思ったのでとりあえず評価してみた。<a class="footref" href="#fn2" id="r2">[2]</a>
結果、問題もなくはないが、同期の速度は爆速だし、Androidのバッテリー消費もそんなにわるくなってないように見えるし、体感としてはとてもよい。なにより、ふと気付いたらうごかなくなってる、みたいなgriveにあった不安さもないのが最高。
というわけでorgファイル以外もSyncthingをつかって同期するようになって、いまではこんな感じに。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/52658627437/in/datetaken-public/" title="My Syncthing sync flow"><img src="https://live.staticflickr.com/65535/52658627437_8133943baf_k.jpg" width="2048" height="901" alt="My Syncthing sync flow"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

<ul>
<li>orgファイル同期</li>
<li>Pixel 7とPixel 3の写真同期</li>
<li>一部ソースコードをLinuxとMacで同期</li>
</ul>

orgファイルの同期、PC/Mac間ではそこまで使い勝手に差はないが、やはりモバイルでした変更が即座にPCに反映されるのはあたりまえだけど便利だった。キッチンでコーヒーいれているときに思いついたことをinboxにいれて仕事部屋にもどってきても、その変更はまだきてない、みたいなことがなくなった。
Pixel 7と3の写真同期はまぁ単純にGoogle Photosの容量をケチってPixel 3経由でアップするようにする用。
ソースコード同期がやってみたら意外にも便利で手放せなくなった。
具体的には <code>~/dev/src/sync</code> 以下が自動で同期されるようにした。基本的に進行中のprojectのソースコードを置いておく。 同期しないディレクトリも指定できるので、RustのtargetディレクトリとかNodeのnode_modulesディレクトリとかはsyncしないようにもできる。便利!
これによってキリの悪いところで作業が中断してレポジトリにpushできていなくても、そのままの状態を他の端末で再開できるようになってかなり快適になった。
ただ、問題がないわけではなくて、以下のような問題があった:
<ol>
<li>Google Driveとはちがってバックアップがない</li>
<li>Hyper-VのNATを超えられない</li>
<li>Androidアプリが止まってることがある</li>
</ol>

1は上の図にもあるように、Windowsにもorgファイルをread onlyでコピーされるようにして、そこをGoogle Driveでバックアップする、というような運用にした。Windowsでやるのはgriveをつかいたくなかったからです。
このようにread onlyかread/writeかというような同期方法を選べるのも良いポイント。Pixel間の写真同期はあえてread/writeにしていて、こうするとPixel 3のほうのPhotoアプリでCleanup spacesするとPixel 7のほうも消えてくれて楽。
2は、自分のHyper-V VMのネットワークはNATを使って外に出ているのだが、このNATをSyncthingがうまくあつかえない模様。
Sync対象が外からみて同じグローバルIPを持っているとおなじLANにいる想定でうごいてしまうのか(?)、うまくおたがいをさがせなくなってしまう。
これは常時VPNを張っておくことで解決できた。PC/Macはもともと<a href="https://www.zerotier.com/">zerotier</a>を使ってつながっていたので、そこにAndroidも追加する形。
3は、めったにないのだが、ごくまれにAndroidアプリが止まっていることがある。再起動したタイミングとかなのかな？
まぁとにかく動作中は通知領域にアイコンがでるので、止まってる場合そのアイコンが消えているのでわりとすぐに気が付けるので良いのだけど、
ほんとはつねに通知領域にでているのはウザいので消してしまいたいのだが、そうすると止まっていることに気が付けないので消すに消せなくなっている…。これはちょっと残念ポイント。
そんなわけで良い点ばかりではないものの、トータルではとても良いものです。おすすめ。
<aside class="footdef">
<a href="#r1">[1]</a> <a href="https://unknownplace.org/blog/2021/05/06/org-protocol-wsl-subsystemd/">ここ</a>で書いた家族との共有以外はすべてorg-modeでやるように戻ってしまっている 
<a href="#r2">[2]</a> Syncthingは公式にはiOSに対応していないので、iOSで使いたい人は注意されたし。サードパーティ製はいくつかある模様 
</aside>

Syncthing便利

去年は厄年だったのではないかと思うのだが、モバイル用の開発環境<a class="footref" href="#fn1" id="r1">[1]</a>が立て続けにお亡くなりになり、Surface Goを買い直すには時期がわるそう<a class="footref" href="#fn2" id="r2">[2]</a>ということで、会社に相談してみたらM1のMacBook Airを貸与してもらえた。
ここ数年は、Windows/Linuxがメインで、MacはMac miniをほぼビルド専用機として使っている程度だった。
しかし、せっかくわりと最近のスペックのMacBookを貸してもらえたので、そこそこ本格的に使いたい機運になって、わりとメインに近い感じで使いはじめてみた。
いまは、モバイルの開発環境としてはもちろんメインになり、デスクトップでの開発でもReactNativeでのアプリ開発についてはMacをメインでそのまま使うようになった。
ReactNativeに関してはAndroidエミュレータでの開発のもっさりさが相当あるので、やはりMac上でiOSシミュレータで開発したほうがストレスがない。
一方、バックエンドの開発はまだまだLinuxのほうがやりやすいと感じる。Dockerの使いやすさはもちろんのこと、これはArchLinuxと比較しての話にはなるのだが、パッケージマネージャの使い勝手もずいぶん違う。
ArchLinuxの場合、基本的にすべてのパッケージが最新の状態に保てる。最新になりすぎるという問題はあるものの、開発環境として使う分には好都合なことしかないので問題なし。
Macだとbrewで古くなったものを手動で管理する必要がありめんどくさい、というのと、brewコマンドがめちゃくちゃ遅くてユーザー体験とても悪い。
他のパッケージマネージャが出てきてたりするのかな？と検索してみてもめぼしいものは見つからず、みんなこれに我慢しているのだろうか…？と疑問になるレベルである。
そんなこんなで結局MacBookでもバックエンド開発は家のPCにリモート接続して開発、みたいな形になってしまっている。宝のもちぐされだ。
やはりSurface Goが自分にとってはベストなモバイル開発環境な気がしてくる今日このごろ。次のモデルを待とう。
MacBook導入後のデスクトップの様子は以下のような感じで、4Kのモバイルモニターをメインモニタの下に置くようにしてみたらかなり作業しやすい感じになった。
マウス・キーボードは切り替え機でハードウェア的に切り替えもできるようにしているのだが、基本的には<a href="https://github.com/debauchee/barrier">Barrier</a>を使って共有している。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/52621449356/in/datetaken-public/" title="Desktop Jan 2023"><img src="https://live.staticflickr.com/65535/52621449356_ed8f617c0e_b.jpg" width="1024" height="771" alt="Desktop Jan 2023"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

しかし、このBarrierを使った共有でいまのところ解決できていない問題があって困っている。(ようやく本題)
<ol>
<li>Macをサーバーにする
<ul>
<li>Natural Scrollになってしまう
<ul>
<li>前提条件として、Trackpadではnaturalになってほしい。マウスではなってほしくない</li>
<li>というので<a href="https://mos.caldis.me/">Mos</a>というのを入れてみたが、MacBook単体では理想の挙動なものの、Windows側がnatural scrollingのままになってしまう</li>
</ul></li>
</ul></li>

<li>Windowsをサーバーにする
<ul>
<li>マウススクロール問題はおこらない</li>
<li>しかし、Mac側でKarabinerを使って実現しているSandS機能が動作しない</li>
</ul></li>
</ol>

という感じでこっちを立てればあっちが立たず、みたいな状況。
とりあえず現状は1で、デスクトップで作業する時は手動でNatural Scrollを切る、という不毛なワークアラウンドをしている毎日です。
<aside class="footdef">
<a href="#r1">[1]</a> Surface Goと、その代替として使っていた古いZenBook
<a href="#r2">[2]</a> どうせ買うなら次のを待ちたい
</aside>