TL;DR: <a href="https://github.com/alixaxel/chrome-aws-lambda">chrome-aws-lambda</a> 使えばok。
次男の通っている保育園が共有サイトでちょくちょく写真を共有してくれてありがたいのだが、いかんせんそのサイトが使いにくすぎるので、スクレイピングして写真をとってきてGoogle PhotosなりFlickrなりに自動でアップしてくれるソリューションがほしくなった。
こういうのは僕たちPlagger世代にはお手のものだぜ、ってんで軽く考えて作業を開始したが、このサイトがjsベースのサイトで昔ながらの方法でスクレイピングするとなるとAPIの解析が必要になりとてもめんどくさいことがわかった…。<a class="footref" href="#fn1" id="r1">[1]</a>
<a href="https://phantomjs.org/">PhantomJS</a> のようなheadlessブラウザでやるのが楽そうだが、これは開発が停止しているし、いまだとなにでやるのがいいのかな〜と<a href="https://twitter.com/typester/status/1194312174199398400">tweet</a>したら、headless chrome とか puppeteer をおすすめされたので、とりあえずそれをみてみる。
<a href="https://github.com/GoogleChrome/puppeteer">Puppeteer</a>はChrome/ChromiumのDevTools Protocolを使ってそれらをコントロールできるNode.jsのモジュールで、Google謹製だしなかなか良さそう。
問題のサイトがポップアップメニューからメニューをたどる必要があったりとか、ダウンロードリンクの飛び先がそのままだとpuppeteerから扱えなかったりとか、いろいろ問題はあったが、なんとか目的のスクリプトは作成できた。
あとはこのスクリプトを定期実行すればよいが、それによさそうなサーバをいまは契約していないのでlambdaとかでうごかせたりしないのかな？ と思ったら<a href="https://github.com/alixaxel/chrome-aws-lambda">chrome-aws-lambda</a>というまさにそのためのプロジェクトがあって、これをつかえばlambdaでうごかすためのchromiumバイナリをかんたんにバンドルできてかなり素晴しい。
ただこのchrome-aws-lambda、TypeScriptの型情報がないのだけが惜しい。まぁ、ほぼpuppeteerのラッパーなので、使う部分だけ型情報を書くのはサクッとできる。以下のようなのを書いた:

<h3>追記@2019-11-22</h3>
いま見たら普通に型情報ついてました…。↓のショボいのはまったく必要なし! すばらしい。
<pre><code class="typescript">declare module "chrome-aws-lambda" {
 import { LaunchOptions, Browser } from "puppeteer";

 interface ChromeAwsLambda {
 puppeteer: {
 launch: (options?: LaunchOptions) =&gt; Promise&lt;Browser&gt;;
 };

 args: string[];
 defaultViewport: any;
 executablePath: Promise&lt;string&gt;;
 headless: boolean;
 }

 const chromium: ChromeAwsLambda;
 export default chromium;
}</code></pre>

あとはもうREADME通りにやるだけで完璧に動作した。
さいごにPlaggerでこれをやるならどうしたらいいのだろう？と思ったが、Perlにも<a href="https://metacpan.org/pod/Chrome::DevToolsProtocol">Chrome::DevToolsProtocol</a>はあってさらにそれをつかう<a href="https://metacpan.org/release/WWW-Mechanize-Chrome">WWW::Mechanize::Chrome</a>もあってすでに簡単にできそうな感じだった。さすが!
<aside class="footdef">
<a href="#r1">[1]</a> こういう場合、昔なら意気揚々とAPIの解析を開始してたとおもうが、これが加齢というやつか…w
</aside>

AWS Lambdaでpuppeteerを使う

今朝、近くの道路が交通事故のため閉鎖されていた。こういう時はPoliceのtwitterを見るとたいてい原因と状況が分かる。
<blockquote class="twitter-tweet" data-theme="light">Traffic <a href="https://twitter.com/hashtag/alert?src=hash&amp;ref_src=twsrc%5Etfw">#alert</a>: SE Division closed from 40-41 due to hit and run crash where telephone pole was struck. Involved Subaru located near 89/Division. K9 track underway&mdash; Portland Police (@PortlandPolice) <a href="https://twitter.com/PortlandPolice/status/1192081037037191168?ref_src=twsrc%5Etfw">November 6, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

このTweetを見て状況は分かったが、「はて、K9とは？」という新たな疑問が出て調べてみると、警察犬のことを K9 or K-9 と表記するらしい。
イヌ科を表す単語 <code>canine</code> と同じ発音だからだそうだ。ソースは<a href="https://en.wikipedia.org/wiki/Police_dog">wikipedia</a>。
こういうのの積み重ねで、現地のことを学んでに溶け込んでいくのだな〜としみじみ思ったので忘れないようにメモ。
それ以前に引っ越してきた当初だったら、 <code>SE Division closed from 40-41</code> とか、 <code>89/Division</code> とかもどこのことか分からないだろうな。
いまだともう大体あそこらへんだな、ということが分かる。

現地の言葉を覚えるということ

数年ぶりにPebbleアプリを書いている。公式のsdk(というかpebbleコマンド)は、使ってるサーバがもう動いていないので動かない。
<a href="https://rebble.io/">Rebble</a>の有志がforkして運用してくれてる <a href="https://github.com/pebble/pebble-tool">https://github.com/pebble/pebble-tool</a> を使えば良い。
ArchLinuxだとaurにパッケージがあるので、
<pre><code class="sh">yay -S pebble-tool-git python2-virtualenv</code></pre>

とするだけで昔とおなじように開発できるようになる。<a class="footref" href="#fn1" id="r1">[1]</a> ありがたい。
今はlanguage serverとかエディタ側が進化しているので、補完や定義ジャンプをばりばり使って書けるようになっていて、sdkが当時のままでもなかなか新鮮な感じでプログラミングできて面白いし、快適だ。
language serverの使い方は普通のCプロジェクトとおなじ。
自分は定義作るのに<a href="https://github.com/rizsotto/Bear">bear</a>、language serverには<a href="https://github.com/MaskRay/ccls">ccls</a>を使っている。
<pre><code class="sh">bear pebble build</code></pre>

としてbuild時にbearをかませばcclsに渡せる定義ファイル(compile_commands.json)ができるので、それをcclsから使えば良い。
<aside class="footdef">
<a href="#r1">[1]</a> virtualenvはsdkのダウンロードに必要
</aside>

2019年にPebbleアプリを作る

結論から書くと、<a href="https://unknownplace.org/blog/2019/10/23/v4l2loopback/">前回</a>書いたv4l2loopbackと<a href="https://play.google.com/store/apps/details?id=com.pas.webcam&amp;hl=en_US">IP Webcam</a>というAndroidアプリを組みあわせればいける。
<a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/48953456078/in/datetaken/" title="2019-10-24-114609_683x549_scrot"><img src="https://live.staticflickr.com/65535/48953456078_1314c4ab25_z.jpg" width="640" height="514" alt="2019-10-24-114609_683x549_scrot"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>

IP Webcamの使い方はいまのところまだよくわかってないが、Start serverすると、 <code>http://ip:8080/video</code> <a class="footref" href="#fn1" id="r1">[1]</a> で、mjpegストリームが取れるっぽいので、
<pre><code class="sh">ffmpeg -i http://ip:8080/video -f v4l2 -pix_fmt yuv420p /dev/video0</code></pre>

とかで流しこんでやればokぽい。 <code>-pix_fmt</code> はないとエラーが出たので適当に付けて回避したものなのでもっと良い指定があるやもしれず。
日本で使っていたカメラや、ノートPCのそれより全然良いので、もはやこれで良いなぁ。
あと、この方法だと、静止画流しこんだり、デスクトップキャプチャを流しこんだり、本来カメラしか使えないところでもいろいろ応用ができるのもよさそう。
<aside class="footdef">
<a href="#r1">[1]</a> ipって書いてるところはスマホのIP。念のため。
</aside>

Pixel3をwebcamとして使う

日本で使っていたWebカメラは処分してしまったので、デスクトップPCでビデオ会議するためには、また新しく買わないとなぁと思っていたのだが、
画質良いやつを買おうとすると、結構高いし悩む。(会議に画質をもとめなくてもいいとは思うが…w
スマホをWebcamとして使える方法ないのかな？ と検索してみると、Androidだと <a href="https://www.dev47apps.com">DroidCam</a> というアプリでまさにそういうことが出来そう。
ただ、専用のソフトウェア(Linuxの場合kernel module)をインストールする必要があって、あんまりやりたくない感じがする。
用途的におそらくカーネルモジュールは入れる必要はあるとは思うが、もう少しオープンなものor汎用的なものはないのかと探して見つけたのが、 <a href="https://github.com/umlaeute/v4l2loopback">v4l2loopback</a> というプロジェクト。
これはv4l2の仮想入出力デバイスを作ってくれるもので、v4l2に対応してるアプリならなんでもつかえそうなのでなかなか良さそう。
とりあえず、
<pre><code class="sh">sudo modprobe v4l2loopback exclusive_caps=1
ffmpeg -re -i foo.mp4 -f v4l2 /dev/video0</code></pre>

として、適当な動画をChromeからwebcamとして使えるところまでは確認した。<a class="footref" href="#fn1" id="r1">[1]</a>
あとはffmpegに何らかの方法でスマホのカメラ画像を渡せばやりたいことはできそう。
<aside class="footdef">
<a href="#r1">[1]</a> <code>exclusive_caps=1</code> を付けないとChromeが認識してくれない ref: <a href="https://github.com/umlaeute/v4l2loopback/issues/78">https://github.com/umlaeute/v4l2loopback/issues/78</a>
</aside>

v4l2loopbackで仮想videoデバイスを作る

オレゴン州ポートランドに引っ越しをして2ヶ月くらいが経過した。
現在のところ、とくに大きな不自由はなく生活している。
ブログでは家を決める前のところから更新が途絶えているから、そこから書いておくと、住んでいるのは2ベッドルームのアパートで、
そこには7月まで知り合いが住んでいたのだが、ちょうど日本に帰国するというので、契約を引き継いで借りている。
これはとてつもなくラッキーだった。英語はあやしいし、こちらでの信用もないから、家を探すのはかなり大変だと思っていたので。
家の設備も申し分なく、いまのところの不満は、シャワーが固定で使いづらいのと、トイレにウォシュレットがないことくらい。
前者は市販されているシャワーヘッドに置き換えれば良いと教えてもらって交換した。
<blockquote class="twitter-tweet">こうなりました。ありがとうございます！！ <a href="https://t.co/f3UuZ03Lcf">pic.twitter.com/f3UuZ03Lcf</a>&mdash; Daisuke Murase (@typester) <a href="https://twitter.com/typester/status/1165038515148574721?ref_src=twsrc%5Etfw">August 23, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

後者はそんなこともあろうかと日本にいるときに携帯用のやつを買って持ちこんでいたので、問題はなかった。
インターネット回線は、契約時にもらった資料から、このアパートには光回線が来ていることが分かったので、そちらを契約。
契約時に電話でいわれるままに作業をするのだが、まったく繋がる気配がなく、しかもこちらは無理だと思っているのに、電話越しのサポート担当はあきらめようとしないw
ので、めんどくさくなって$50かかるといわれたがサポートエンジニアに来て作業してもらってなんとか開通した。
<a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/48905119571/in/datetaken/" title="Internet speed at our new home"><img src="https://live.staticflickr.com/65535/48905119571_06ebde2f32_b.jpg" width="512" height="1024" alt="Internet speed at our new home"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>

画像は開通直後に速度を計測した時のもの。かなり速くて日本にいた時より快適なので、この点はかなり満足。
事前にFiberがきてるなんて知らなかったので、これもラッキーだった。
もろもろの支払いは (家賃、光熱費、電気ガス、健康保険、家の保険、保育料から小学校への寄付まで) 、すべてが日本のカードでも支払えるのも助かっている。こっちのカードも早く手にいれたいところ…。
あとは先週とどいた船便の荷物を整理して、作業デスクを設置したりすれば、ほぼ住環境は整う気がする。
次のミッションとしては、このあたりは車があると週末の遊びスポットがものすごい増えそうなので、レンタカーをつかえるようにするべく、免許の取得かな。<a class="footref" href="#fn1" id="r1">[1]</a>
<aside class="footdef">
<a href="#r1">[1]</a> 日本の免許でも運転可能だが、オレゴンの法律的には住民は引っ越して1ヶ月以内にオレゴンの免許に切り替えろ、となっているようなので、それをすぎている現在では日本の免許での運転はしないほうがよさそう
</aside>

ポートランドへの引っ越しを完了した

英語の勉強の習慣付けがどうにもうまくいかないので、なにか違うことをやったらどうだろうかと、<a href="https://coach.fitbit.com/">Fitbit coach</a>を使って運動を始めてみたのが3月。
こっちは続けられている。なんでだろう？とかんがえてみると、やはり運動は結果がすぐに(といっても2週間〜1ヶ月くらいは必要？)わかる、というのが大きい。
体脂肪率はリニアに減りつづけているのと、前に無理だったトレーニングメニューがだんだんと出来るようになっていくのが分かるのが楽しい。
High knee (腿上げ) とか最初30秒くらいでダウンしてたやつがいまは90秒くらいはいける、とか。
Fitbit coachは運動メニューも各々にあわせて調整してくれるので、そういうのを考える必要がなくて、ただ毎日アプリを起動して始めるだけでいいというのもいいのかも。<a class="footref" href="#fn1" id="r1">[1]</a>
ちなみに、最初に数値目標としてあげたのは、Fitbitのメインのほうのアプリで確認できるCardio Fitness Score<a class="footref" href="#fn3" id="r3">[3]</a>でExcellentになること。
35歳-40歳男性のExcellentは55+で最初はその下のVery goodクラス(50-54)だったので、40歳までにexcellentになること、をとりあえずの目標にしている。
現在は以下のように若干Excellentに足を踏み入れたとこまでいってる。
<a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/48089633122/in/datetaken/" title="2019-06-19-101816_657x1084_scrot"><img src="https://live.staticflickr.com/65535/48089633122_1a066f4192_b.jpg" width="621" height="1024" alt="2019-06-19-101816_657x1084_scrot"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>

この調子で完全Excellentを達成したい。
そしてこの結果、運動の習慣付けはできたということ、から、当初の目的である英語もやりかたを工夫すればいけそうだな〜ということがわかったのでそっちもやっていきたい。
<aside class="footdef">
<a href="#r1">[1]</a> 毎日といってもだいたいweekdayだけ。あと筋肉痛がひどいばあいは水曜はおやすみにしている<a class="footref" href="#fn2" id="r2">[2]</a> 
<a href="#r2">[2]</a> 
<a href="#r3">[3]</a> VO2 Maxというのを擬似的に算出した値らしい 
</aside>

Fitbit coachを始めて3ヶ月

LinuxのGUIアプリの起動は基本的には WM (awesomewm) のコマンド実行機能(<code>super-r</code>)でやっている。
この方法だと実行する名前を少なくとも頭文字くらいは覚えておかないといけない。
たまにしかつかわないようなアプリはけっこうなんだっけ？ってなることが多くてつらい
<ul>
<li><code>zeal</code> ドキュメントビューワ</li>
<li><code>evince</code> PDFリーダー</li>
<li><code>scrot</code> スクショ取り</li>
<li><code>peek</code> gif動画取り</li>
</ul>

などなど…。
awesomewmにもmenubarというWindowsでいうところのスタートメニューみたいな機能があるので、そういうのをもっと活用すべきなんだろうな〜とおもいつつ。

Linuxのアプリの名前を覚えるのが難しい

<a href="http://rebuild.fm/239/">rebuild.fm ep239</a>でも少し話をしたが、アメリカに移住することになった。
我が家には保育園の年中クラス(5歳)の息子がいて、彼の学校を決めるのがいちばん優先度のたかいタスクだった。
というのも、学校自体はわりとはやく目星をつけていて、Dual Language Immersionプログラムというので日本語をやっている学校がよさそうだと思っていたのだが、その学校は入学受付が抽選で、その申し込み期限が3月とわりと早めに設定されているからなのであった。
Dual Language Immersionプログラムというのはバイリンガル教育の方法の一種で、
母国語(English)とターゲット言語(Japanese<a class="footref" href="#fn1" id="r1">[1]</a>)をそれぞれのネイティブ話者の生徒をごちゃまぜにし、授業もそれぞれの言語でおこなうというものらしい。この授業の言語比率は学校によって違うようだが、息子が申し込んだところは50%英語50%日本語という感じらしい。
この学校が良いなとおもったのは、次男(2歳)くらいの年齢ならともかく、長男は5歳で。そのくらいになると日本語もとても流暢だし、読み書きもかなりできるようになっているタイミング。
いろいろなことが分かってきて人格も形成されてきているところだろう。そこでいきなり日本語の通じない現地の学校に放り込まれるのはあまりにも酷だと思ったから。
こういう学校であれば多少はマシかなぁと。
そんなわけで2月くらいから申し込み作業をしていたわけだけど、いろいろトラブルがあり、かなり心配していたのだが、
<blockquote>
(息子の名前)'s place will be held until you are able to bring in the registration paperwork this summer.
</blockquote>

というメールをいただきまして、あとは必要書類を提出するだけ、というところまで無事たどりついた。
このDual Language Immersionプログラムの性質上、ターゲット言語のネイティブスピーカーという存在は必要不可欠なので抽選でも優遇される、ということは分かっていたので、
これでダメだったら完全に僕のせい、と思っていたのでこれで肩の荷がおりた感じ…。やれやれ。
必要書類で足りてないのは、Vision and Dental Screening と Proof of Residency。
前者は検査をうけるだけだとおもうが、目のほうは日本語でうけられるところがあったらそちらのほうがいいのか？とかいろいろよくわかってないので要調査。
日本の視力検査のイメージだと子供が検査する人と直接コミュニケーションができないとだめなきがするので。ともかくこれはなにもわかってないのでしらべなくては。
やりとりをしていた小学校の窓口の人がかなり親切なので、彼女に相談してみるのも手だろう。
問題はやっぱり Proof of Residency、これ。つぎなる最優先タスクはこれですな〜。がんばろう!
<aside class="footdef">
<a href="#r1">[1]</a> 僕らの場合は日本語だがこれは学校によって異なる
</aside>

息子の小学校の枠を確保した

最近、<a href="https://www.kleankanteen.jp/collections/coffee/products/insulated-coffee-mug-12oz">クリーンカンティーンの水筒</a>を愛用している。
朝これにコーヒーを入れてもちあるき、ちょいちょい飲み、だいたい16時ごろに飲みおわるまで、常に暖かいコーヒーがそばにある、というのは体験してみるとなかなか素晴しい。
また休みの日などは、これをお気に入りのコーヒーショップに持っていっておいしいコーヒーを入れてもらい、そのままそれを片手に子供たちと散歩というような使い方もしている。とにかく自分の生活になくてはならないものになった。
たがしかし、これはとても万人にすすめられるものではない。
この水筒の特徴は<a href="https://www.kleankanteen.jp/products/cafe-cap">カフェキャップ2.0</a>という蓋で、これはなかなか斬新で、蓋をつけたまま、中身を飲むことができる…!
それでいて中身は漏れないから、カバンのなかに無造作につっこんでも大丈夫、ということになっているのだが、実際には漏れる(笑)
正確には、一度飲むと蓋の部分に若干の飲み物が付着し、それがボトルをふったりするとこぼれてしまうわけです。
なんでまぁ微量なわけですが、それでもカバンの中に無造作につっこむ、というわけにはとてもいかない。
ただまぁ一度も飲んでなければ歌い文句通り完全に漏れないので、会社に着くまでは一切飲まないで、会社で飲みきる、というような場合はそういう無造作スタイルもいけるかもしれない。
僕の場合は<a href="https://www.castendesign.com/">使っている鞄</a>が二層構造になっていて<a class="footref" href="#fn1" id="r1">[1]</a>、万一漏れた場合でも他に被害がでるのを防げるのと、ほかにそこに入れている物との兼ね合いで、ボトルを立てた状態で入れることができるので、蓋に付着した少量の水分くらいならほぼこぼれないような状態にできる。
というように、この商品はかなり人を選ぶ。
マッチする人にはめちゃめちゃ便利だろうが、ほとんどの人には許容できないものなきがする。
そしてこの話を友人とチャットしていて、自分はこういう性質の物がすごく好きだということに気がついた。
万人向きの汎用性のあるものではなくて、自分に特化しているようなものが好きなのだ。
「エディタとかカスタマイズしていくとそれに依存してしまって他の環境に行きづらくなるから、デフォルト状態で使う」みたいな人をたまに見かけるが、それはそれでなかなか極端だとはおもうが、自分はそれを真逆に極端にした感じっぽい(笑)
よく使うもの、というかよく使うものこそ、最高に自分の好みにあっていて気持ち良く使える物をつかいたい。
というようなことを考え続けた結果か、そういえば自分には愛用の品というというものがかなりある。物に思い入れありすぎ(笑)
上記のなんでもデフォルトで使うというような人って物に愛着ってないのかなー？
自分からみるとかなりさみしいきがするが、それはそれで生きやすいきがする。
<aside class="footdef">
<a href="#r1">[1]</a> PCやノートなどオフィス用品と、ジム用の着替えなどを分けるという用途っぽい 
</aside>

万人向きではないピーキーなものが好き

TL;DR: <code>hexedit --color</code> 良い。
バイナリーファイルを編集するというような機会は、いままでそんなになかった。
表示して確認したいということはそこそこあったが、編集するということはあってもせいぜい1byte書き換えるとかその程度。
なのでだいたい、 <code>hexdump</code> か Emacs の <code>hexl-mode</code> でことたりてた。
ただ最近わりとがっつりバイナリーを編集する必要があって、いままでのようにhexl-modeを使っていたのだが、
ガーっと入力できるのはasciiだけで、hex値での入力は毎回 <code>C-M-x</code> をおして1byteずつやらなければいけない。
めちゃくちゃ不便。
そもそもhexl-modeはそのようにがっつりバイナリーをいじる用途向けではなさそうだ。
適当に検索すると
<ul>
<li><a href="https://qiita.com/hachisukansw/items/7f0219d17707e149f389">Linuxで大きめのファイルの扱えるバイナリエディタ - Qiita</a></li>
<li><a href="https://www.tecmint.com/best-hex-editors-for-linux/">Top Hex Editors for Linux</a></li>
</ul>

とかがひっかかる。CUI、GUIけっこういろいろある。
いろいろ試して決めようとおもうが、
<ul>
<li>なるべくArchLinuxのデフォルトでパッケージがあるやつ<a class="footref" href="#fn1" id="r1">[1]</a></li>
<li>どこでもつかえるからCUIのやつ</li>
</ul>

という条件で検索すると
<ul>
<li>hexedit</li>
<li>dhex</li>
</ul>

のどっちかかなと。dhexは上の記事によるとキーバインドが独特っぽかったのでとりあえずhexeditを試す
<pre><code class="sh">yay -S hexedit</code></pre>

とりあえず軽く使ってみた感じでは
<ul>
<li>変なキーをおすとダイアログみたいなやつが出て親切</li>
<li>F1でmanがひらける(↑のダイアログにでる)</li>
<li>カーソル移動はEmacsキーバインドが使える</li>
<li>hex領域とascii領域の行き来はtab</li>
<li><code>--color</code> で起動すれば色つきになる<a class="footref" href="#fn2" id="r2">[2]</a></li>
</ul>

という感じでもうこれでいいじゃん、というかかなり気にいってしまった。こまったらF1おせばシンプルに使い方がわかるし、Emacsバインドがつかえるのも個人的には最高。
もはや表示だけでも <code>hexedit --color</code> をつかうレベル。
もっとはやくさがしておけばよかったな〜
<aside class="footdef">
<a href="#r1">[1]</a> AURはあまり増やすとアップデート時に時間かかるから最小限にしたい 
<a href="#r2">[2]</a> ちゃんとカーソル位置がhexのところとasciiのところの色が連動するので見易い
</aside>

バイナリエディターを探す旅

TL;DR: <code>git rev-parse --show-toplevel</code>
Cのプロジェクトで、language serverのために <code>compile_commands.json</code> を作るのだが、
ライブラリーのレポジトリだったりすると、makeするのはrootディレクトリではなくて、examples以下だったりする。
そこでmakeするけど、 <code>compile_commands.json</code> はgitのrootにおきたい、みたいな時に
<pre><code class="sh">bear -a -o ../../compile_commands.json make</code></pre>

みたいにしてたんだけど、ほかのプロジェクトでこの履歴をそのまま使うとこまることもある。
gitのrootをコマンドラインで取得できれば、これを共通のコマンドにできそう。
というわけで調べたら <code>git rev-parse --show-toplevel</code> で出来た。
さっきのコマンドは
<pre><code class="fish">bear -a -o (git rev-parse --show-toplevel)/compile_commands.json make</code></pre>

みたいにすればだいたいどこでもつかえるものに。<a class="footref" href="#fn1" id="r1">[1]</a>
<aside class="footdef">
<a href="#r1">[1]</a> fish使ってるからサブコマンド表記が一般的でない
</aside>

Gitのworking dirのrootを取得する

ブログに画像を貼り付ける方法に良い方法がなくてこまっている。
写真などは基本的にGoogle PhotosにすべてUPしているので、そこから貼り付けられるのがベストだが、
Goole Photosで普通にShareしようとしてもURLしか発行されないし…、
また、そのURLを開くと位置情報などのプライベートな情報も見れてしまってあまりよろしくない。
ググると、Share URLから画像のURLだけを取ってきて使っている人が結構いる…(そういうツールやサービスもあるようだ)
が、それってGoogle Photos的にオッケーなのか？ という疑問があるし、
そもそもその画像URLは永続的に使える保証もなさそうだし微妙な感じ。
Flickrはそのへんよくできてたんだよなぁ。位置情報はFamily &amp; Friendsのみに共有。
みたいに細かくプライバシーの設定ができたし。
とにかくなにか良い方法をさがさないと画像が貼れないぞ! 困ったな〜

Google Photosの画像をブログにはりつけたい

夜仕事しながらもビールを飲んでいたりして、でもよくよく考えると、そういう時ってあまりあじわって飲んでいない。
たんじゅんに口がさびしいからという理由で飲んでいる気がする。
昼間はそれがコーヒーなわけだが、夜にカフェインを取りたくはないので、そうなるととりあえずビール…となってしまうわけだな(笑)
そこで代替を考えてみる。
まず最初にくるのはやっぱりカフェイン抜きのコーヒー。最近の水で抽出したものはなかなかおいしくて、
味だけならぜんぜん代替になる。が、コスパがわるすぎる。普通のコーヒーよりだいぶ値が張る。
つぎはお茶とか？ でもこれは物によってはカフェイン入ってそうだし、昆布茶とか好きだけどこれは塩分とりすぎになりそう。
ただ種類がいろいろあるところなので、調べたらおもしろそう。ここは今後要調査ということにしておく。
他にいま家にあるものでよさそうなのをさがしてたどりついたのが、レモン水。
ホットで飲むとレモネードみたいになってうまい。お湯わかして、そこにレモン汁を注入するだけの簡単さも良い。

口がさびしいからという理由でビールを飲むのをやめる

そろそろ自分のサイトもhttpsにしないとな〜と思いつつも、証明書の管理とか自分でやりたくないので、いろいろ考えた結果、
firebaseでホスティングすることにした。
いろいろな理由:
<ol>
<li>動的生成をやめたい</li>
<li>React+TypeScriptでサイトを作りたい</li>
</ol>

のため、ついにblosxomと決別することとなった。
2に関しては仕事で慣れ親しんだ環境だからだ。ただ、Webの世界で使ったことはないので<a class="footref" href="#fn1" id="r1">[1]</a>、
良い感じにめんどくさいことを隠蔽してくれそうな <a href="https://nextjs.org">Next.js</a> を使ってみた。
結果、特にハマることもなくサイト作れたので、なかなか良いフレームワークだと思う。
とはいえ、もろもろ突貫で移行したので、いろいろ中途半端なところが残っているが、気長にちょこちょこ対応していく所存だ。
<aside class="footdef">
<a href="#r1">[1]</a> 仕事でやってるのはReact Native 
</aside>

サイトをFirebaseに移行した

Emacsのフォントは長くRictyを使っていたのだが、なんとなく変えたくなり、検索してみたところ、 <a href="https://github.com/adobe-fonts/source-han-code-jp">Source Han Code JP</a> というフォントが良さそうだったので、それにしてみた。
英字部分の Source Code Pro はなかなか見易くて気にいったのだけど、
英字と日本語の幅のレートがが 1:2 ではなく、 1:1.5 になっていて、org-modeのテーブルが崩れてしまうのが残念。
Emacsの日本語フォントをうまく設定すれば 1:2 にすることはできそうだけど、調べるのがめんどうでやりたくない…。

エディタのフォントを変えた

howmメモ、orgファイル、skkの個人辞書などをいままではDropboxにいれてsyncしていたが、Google Driveに変更した。
syncツールには <a href="https://github.com/vitalif/grive2">grive2</a> というのを採用。Arch Linuxだとaurにあるので、
<pre><code class="sh">yay -S grive-git</code></pre>

でokだった。<a class="footref" href="#fn1" id="r1">[1]</a>
全部syncしてほしくはないので <code>~/drive/.griveignore</code> として以下のようなファイルを作る:
<pre><code class="text">*
!howm
!org
!skk</code></pre>

それを作ったあとで、
<pre><code class="sh">cd ~/drive
grive -a</code></pre>

とすると、OAuth認証のプロセスになって、それが通ると初回同期が走る。認証だけじゃなくて、ファイルもおとしてきてしまうので、ignoreファイルを最初に作っておかないと悲しいことになる(なった…w)
あとはこれを自動で動かすために、
<pre><code class="sh">systemctl --user enable grive-timer@drive.timer
systemctl --user start grive-timer@drive.timer
systemctl --user enable grive-changes@drive.service
systemctl --user start grive-changes@drive.service</code></pre>

をやっておけば勝手に同期してくれるっぽい。<a class="footref" href="#fn2" id="r2">[2]</a>
<aside class="footdef">
<a href="#r1">[1]</a> gitのほうを使わないと .griveignore が使えない 
<a href="#r2">[2]</a> inotify-toolsのインストールが必要 
</aside>

Google Driveを使う

あけましておめでとうございます。
すっかりサイトを更新しないままはや数年…。
ちゃんとした記事を公開しようとすると、ドラフトの山ができるということがわかったので、
ちゃんとしてない記事を公開する場所をあらたにブログとして新設した。
今年は下の子もだいぶ大きくなって手がかからなくなってきたので、ようやくいろんな意味で社会復帰できそうだなぁという感じ。

ブログというか日記というか

何をいってるんだ…、というタイトルですが😅
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>

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

コロナのせいで時間がないので、しばらく買う気はなかった Cyberpunk 2077。
だけど、いろいろニュース記事とかを見ようとすると、どこも「ネタバレ注意!」みたいな記載があって、おいおいそんなこと言われまくると、なにも知らないまっさらな状態でプレイしたくなるじゃないか…
というわけで買ってしまいました。情報遮断しつつちょっとずつやっていく所存です。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50702901978/in/datetaken/" title="20201209212519"><img src="https://live.staticflickr.com/65535/50702901978_8d5ef007a1_b.jpg" width="1024" height="694" alt="20201209212519"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

買ったのはSteam版。
最初はどういうゲームかほんとに知らなかったので、まったりコントローラでプレイしようとしたけど、途中でめっちゃエイムいるやんけ、となってマウス&amp;キーボードのFPSスタイルに変更した。エイムアシストもオフにしてようやく快適に。
コントローラでエイムするの苦手すぎてそれがストレスになりすぎるので、Steam版(PC版)を買って正解だった。
ネタバレきにすると、なかなか事前の情報収集もしづらいし大変よね。
コントローラエイムだめな人がコントローラでやる場合は近接中心でやっていく感じがいいんかな〜。それはそれで、世界観とあいまってボーダーランズのZeroみたいな感じでかっこよさげではある。
Steam版の問題点としては、言語設定回りがちょっとバグっていて、英語音声+日本語字幕でプレイしようとすると、起動するたびに全部英語にもどってしまうという問題がある。めんどくさいので全部日本語にしてみたが、人の台詞とかの字幕が小さかったり画面外にでちゃってて読めなかったりすることがよくあったので、字幕よめなくてもokな日本語音声でこのままプレイしてもいいかな〜という気持ちになってきてる。
あとデフォルトだとレイトレがONになってて、自分の環境だと1080pでも30FPSくらいしかでないので即オフにした。残念。フォトモードでだけレイトレONとかできるのかな？ 試してないけどできてほしいな。
まだ序盤も序盤だけど、なかなかおもしろい。攻殻機動隊とかブレードランナーみたいな世界観でのオープンワールドRPG(シューティング？)という感じ？ まぁ時間が無限にとけそうなやつなのでみなさん気をつけましょう😇

Cyberpunk 2077

順調にスケートボードにハマっている。晴れた日は基本毎日30分〜1時間ほど滑っている。あと、一人で近場へ移動する時はクルーザーで移動するようになった。
当初は毎日筋肉痛という状況だったが、最近ではあまりならなくなってきた。スケートボードをする筋力がついてきたと思われる。
で、沼なのだが、追加でもう一つスケートボードを組んだ。
というのも、最初に買った二つはどちらもソフトウィールで、ソフトウィールだと荒れた路面を走ったりするのには良いのだが、グリップ力が高く、横滑りするようなトリックをやるのが難しい。
公道など荒れた路面を走る用にはクルーザーがあるので、公園などで練習をする時にだけ使えればいいので、練習用ボードがソフトウィールである必要はまったくない。あと普通のボードは子供用しかなかったので、大人用の普通ボードが欲しくなったのもある。
というわけで所持ボードが
<ul>
<li>子供用ソフトウィール</li>
<li>クルーザーソフトウィール</li>
<li>練習用ハードウィール (new!)</li>
</ul>

という感じになった。良いのでは😊
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50555917381/in/datetaken-public/" title="20201023125441"><img src="https://live.staticflickr.com/65535/50555917381_7c437cce2a_b.jpg" width="1024" height="768" alt="20201023125441"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

スケートボードは完成品も売ってはいるが、基本はこんな感じでパーツをバラバラに買って組むのが普通。いろいろ乗って自分好みのパーツを探していく楽しみもある。
自分はまだなにも分からないので、また例の友人におすすめを聞いて、その通りにパーツを注文して組んだ。以下のような感じ:
<ul>
<li>Baker / Brand Logo - Black/White Deck 8.125"</li>
<li>Thunder / Polished Skateboard Trucks polished (147) 8.0 axle</li>
<li>Bones Bearings / Reds Skateboard Bearings (red)</li>
<li>Thunder / Phillips Thunder Bolts Skateboard Hardware (black/silver 1in)</li>
<li>MOB GRIP / Perforated Skateboard Grip Tape (black 9in x 33in)</li>
<li>Spitfire / Classics 99d Skateboard Wheels 52 mm, White</li>
</ul>

全部で$160くらい。
デッキはBakerの 8.125" or 8.2" くらいのサイズがいいよと言われていたが、ローカルのショップに良いデザインのがなかったので、公式サイトから注文した。
自分のサイズ(身長160cm、靴US7)だと、8.125"は太めなきがしたが、太いのがいいのか細いのがよいのかは人それぞれだし、一度は乗ってみないと違いがわからないと思ったので、すなおにオススメにしたがうことにした。
<div class="image">
 <div>
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50555185383/in/datetaken-public/" title="PXL_20201024_010413842.MP"><img src="https://live.staticflickr.com/65535/50555185383_ce1e56e659_b.jpg" width="1024" height="768" alt="PXL_20201024_010413842.MP"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
 <div class="caption">組みあがり</div>
 </div>
</div>

Thunderのトラックは、クルーザーでつかってるIndependentのトラックと比較してだいぶ固く、安定感があって良い。太いデッキと組みあわせてるのもあって、より安定感があるのかも。オーリーの着地のときなどかなり安心感があるので、太いデッキ+Thunderトラックは初心者によいのかもしれない。トラックの重さなどは正直いまはよくわからない。(Thunderはだいぶ軽いらしい)
ハードウィールは最高。エンドオーバーなど、回りが中途半端でもなんとかなっちゃう。ソフトウィールだとそういう時はひっかかって転ぶので、めっちゃこわかった。というかエンドオーバーとかソフトウィールで練習するものじゃないのかも？😅
1個不満なのが、グリップテープがちょっとグリップしすぎて、手がすごいガサガサになるので、もうちょい弱めのでもよかったかなーと思っている。TwitterでJessupのは弱めで良いと教えてもらったので、次買うときはそれにしてみようとおもう。
で、いまはなにを練習しているかというと、ひたすらオーリーとショービットをやっている。
どっちもまだまだ。練習あるのみ!

スケートボードを追加で組んだ

COVID-19の状況の中、9月から本格的に長男(1st grade)のリモート授業もはじまり、共働き&amp;子ども2人という我が家はかなり苦しい生活ルーチーンになっている。
1st gradeの授業はまだまだ親のサポートが必要。とくにうちの子の場合はいまのところ英語があまりできないので、そのサポートも必要というのも大きいが。
またそのサポートをしている間もまだまだ一人だけで遊んだりするのが難しい次男(3歳)もいるという。そういう状況だと、日中に満足に仕事をこなすのがかなり難しい。
どうしているかというと、まず、夫婦の仕事をする時間をずらした。昼間は基本的に自分が仕事、妻が子どもたちを見る。
夜に自分が子どもたちを寝かせ、妻がそのあと仕事をする。結果妻は夜遅くまで仕事をすることになるので朝は遅くまで寝てもらう。朝食を作ったり、朝の授業のサポートなどは僕がやる。<a class="footref" href="#fn1" id="r1">[1]</a>
そんなわけで、夫婦おたがいに自分の時間がほぼないという状況になっている。僕は早朝、妻は深夜にそれぞれ自分の時間を作ろうとおもえば作れるが、そんなに多い時間を確保できるわけではない。
ポートランドの公立学校はもともと最低でも11月まで(1学期おわるまで)はリモート授業、と発表されていたものが、いまは少なくとも1月まで(2学期おわるまで)このままのフルリモートの状態を続ける、ということが最近発表され、このままの生活がしばらく続きそうなので、親のリラックス方法や気分転換方法を新たに開拓する必要があるなと思っていた。
いまの生活スタイルになにかそういうものを取り込むには、子どもが一緒にいても出来ること、という条件がある。また、ステイホームでずっと家にこもりっぱなしなので、できれば外で出来るものが良い。
そんな感じで探しててちょうどよさそうだったのがスケートボードだった。子どもの友達の親でとても上手いスケーターがいて、彼にいろいろ教えてもらえそうだった、というのもある。
その彼におすすめのショップに連れていってもらい、子ども用のコンプリートデッキ<a class="footref" href="#fn2" id="r2">[2]</a>を一つと、大人用のクルーザー<a class="footref" href="#fn3" id="r3">[3]</a>(こっちはぜんぶ彼のおすすめで組んでもらった)を一つ買った。
<div class="image">
 <div>
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50394750827/in/datetaken-public/" title="PXL_20200927_193114336.MP"><img src="https://live.staticflickr.com/65535/50394750827_dbd7c9d096_b.jpg" width="768" height="1024" alt="PXL_20200927_193114336.MP"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
 <div class="caption">おしゃれショップ。ガレージ的なところを想像してたら全然違った</div>
 </div>
</div>

<div class="image">
 <div>
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50394580811/in/datetaken-public/" title="PXL_20200928_005900034.MP"><img src="https://live.staticflickr.com/65535/50394580811_e800607d6f_b.jpg" width="1024" height="768" alt="PXL_20200928_005900034.MP"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
 <div class="caption">買ったボード</div>
 </div>
</div>

始めてみると、思っていた以上に楽しい。まず、ただプッシュ(地面を蹴るやつ)してガーッと進むだけでも楽しい。それだけでも相当楽しいと思ったが、いろいろ練習して出来ることが増えてくるとより楽しく感じる。いままでは子どもの付き合いで公園に行っていたが、むしろ率先して公園行こうぜ!ってなっている(笑)
始めてちょうど2週間くらいで、いまの状況と練習してるやつはこんな感じ:
<ul>
<li>プッシュ</li>
<li>チックタック (だいぶスムーズに加速できるようになった</li>
<li>エンドウォーク、エンドオーバー (ぜんぜんスムーズではないがいちおう出来るように</li>
<li>バックサイドターン (できない…し、テールが削れそうなのであまり積極的にやれていない</li>
<li>オーリー (ぜんぜんできない</li>
</ul>

上から順番にやっていってて、そこそこ出来るようになってきたら新しく練習するのを増やして平行して練習みたいな感じで徐々に増やしていっている。
プッシュは初日からそこそこ出来るようにはなったが、チックタックはなかなか進めるようにならず苦労した。YouTubeでいろいろ動画を参考に見てたら自分の出来てなかったポイントに気付いて、次の日それに気をつけてやってみたら進捗し、いまではわりとスムーズに加速できる。動画見てなかったらまだ苦労してそうだな〜と思うと良い時代だなぁ〜。
エンドウォーク、エンドオーバーはまたさらに壁があり、できるようになるまで何回も転んだ。とくにエンドオーバーの後ろ側に回るやつ。いまもスムーズにできるわけではなく、エンドオーバーも180度ずつなんとか回ってる感じ。360度シュッと回ってるように見えるようになるのが夢。
オーリーの練習は数日前から始めた。全然できないのだが、できてない理由を自分なりに考えて、どうしたらいいのかの仮説をたて、やってみて検証する。というループが楽しい。あと全然できないトリックのほうが進捗した時うれしい、というのもあり、いまは結構こればっかりやっちゃってる。もちろん他のも練習しないと忘れちゃうんで継続してやってるけども。
これね、公園いってもいるんですよ、全然オーリーできてないのにずっとそればっかり練習してる人、いままではそれ見ててなにが楽しいんだろうな〜？って思ってたんだけど、自分でやるようになって分かった。それで十分楽しいんすわw

<h3>ポートランドのスケボー事情</h3>
これはスケートボードを始めてあとで調べて知ったんだけど、ポートランドではスケートボードは公道では自転車と同じ扱いになるので、公道を普通に走行可能らしい。
日本の感覚だとすっごい危なそうだけど、ポートランドではメインの通り以外の小さい道路はほとんどが自転車優先か専用道路になっているので、そういうところをスケートボードで走る分にはそこまで危なくはない。
スケートボードは持ち運びも楽だし、こちらでは移動手段の一つとしてもなかなか良いように思う。そういう意味でも乗れるようになるのはメリットがある。
また、気持ちの良い公園がいっぱいあるのも良い。練習場所には困らない。
ただポートランドは雨がおおいので、その問題はあるが…。
<div class="image">
 <div>
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50405233177/in/datetaken-public/" title="PXL_20200929_012854266.MP"><img src="https://live.staticflickr.com/65535/50405233177_d7cdd5fc87_b.jpg" width="1024" height="768" alt="PXL_20200929_012854266.MP"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
 <div class="caption">いちばん良く行くところ、個人練している人が多くて落ち着く</div>
 </div>
</div>

<div class="image">
 <div>
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50405081681/in/datetaken-public/" title="PXL_20200930_223656616.MP"><img src="https://live.staticflickr.com/65535/50405081681_f795486521_b.jpg" width="1024" height="768" alt="PXL_20200930_223656616.MP"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
 <div class="caption">子どもたちお気に入りの広い公園。プッシュの練習しまくれる</div>
 </div>
</div>

そんな感じで良い気分転換になっているし、運動不足の解消にもなっているし、いまのところ良いことしかない。
ある程度のるとデッキを交換したりしないといけないので買い直す必要があったり、いまソフトウィールなボードしかないのでハードウィールのも欲しいな…とかなっていて沼な気配もしているが、デッキだけだったら$50とかだし、まるっと組んでも$200いかないくらいなので、比較的リーズナブルな趣味ともいえそう。
<aside class="footdef">
<a href="#r1">[1]</a> うちはたまたま妻が日本との仕事が多いので、このように時間をずらすことができた。どちらもおなじタイムゾーンで仕事をしているような場合は数時間ごとに交代、とかになるのだろうか…。それも大変そうだ。 
<a href="#r2">[2]</a> まるっと完成品で売られてるものをコンプリートというらしい
<a href="#r3">[3]</a> 移動用につかうやつ
</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を導入

無事引っ越しが完了した。といっても1ヶ月ほど前の話だが…w
前に住んでいたSEの31thあたりからやや西に移動したところの閑静な住宅街にある一軒家を借りた。
築ほぼ100年の古い家だが、キッチンや水回りは結構最近リフォームされており、そこそこ快適である。
とくにキッチンのアプライアンス(ガスレンジ、オーブン、食洗機、冷蔵庫)はかなりグレードが高いものが付いており、ここに慣れてしまうと次引っ越すときおなじレベルのものを探そうとするとかなり大変だろうな、というレベルだ。
<div class="image">
<a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50145464428/in/datetaken-public/" title="Our new home!"><img src="https://live.staticflickr.com/65535/50145464428_cf3c678820_c.jpg" width="800" height="600" alt="Our new home!"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

職業柄(という理由にしている)、家のスマートホーム化をすすめており、Nestドアベル、スマートロック、通路の照明の自動点灯などを徐々にととのえているところ。
Nestのドアベルはかなり便利で、だれかが玄関にくるとスマホに通知がくるのがとても良い。
こちらは荷物などの届け物は玄関前のポーチに放置される<a class="footref" href="#fn1" id="r1">[1]</a>ので、防犯上の理由からもすぐに回収したいので、かなり役立っている。
スマートロックもかなり便利。いちおうオーナーや管理会社が緊急時に入れないと怒られそうなので、裏口(勝手口)の鍵だけを置きかえているが、鍵をもたずに外出できるのはとても良い。
現状開錠するのにスマホで操作するか、パスコードを入力する必要がある。これも将来的にはNFCとかでタッチしたら開けられるようにしたいと思っている。<a class="footref" href="#fn2" id="r2">[2]</a>
ここ数ヶ月で、引っ越し以外にも、転職したり、車を買ったり、とライフイベントがもりだくさんでなかなか落ち着かなかったが、やっと最近生活リズムがつくれてきている今日このごろ。
他のイベントに関してはまた別途書く。
<aside class="footdef">
<a href="#r1">[1]</a> COVID-19のシチュエーションでコンタクトレスデリバリーという概念が出ているので余計にそうなっている 
<a href="#r2">[2]</a> NFC対応のスマートロックは既製品もあるにはあるが、家の他のシステムとの兼ね合いでそれは見送ったのであった
</aside>

引っ越し完了とかいろいろ

結論を先に書くと、<a href="https://unknownplace.org/blog/2020/06/22/looking-for-new-house/">前回試しに申し込んでみた</a>家にそのまま引っ越しが決まった。
この家は申し込み期間の始まる前からリスティングされていたので、じっくり検討する時間があった。
申し込み開始は6/21の3pmということだったので、ほぼその時間に申し込みをしようと思っていたのだが、必要な書類をそろえるのに手間取り、結局申し込んだのは4pm過ぎてたと思う。
ためしに申し込みをしてみただけのつもりだったからそこまで急いではいなかった。夫婦どちらもが申し込みをする必要があって、申し込みfeeも2倍かかるのは想定外だったが…。
それで、翌日(6/22)にあなたは列の3番目です、という旨の連絡がきた。
3番目なら無理そうかなぁと思っていたら土曜(6/27)になって前の人たちが辞退したけどまだ興味ある？と連絡がきた。
興味あるよ、と連絡すると審査開始の連絡。Rent history提出関係の書類にサインしたりした。
翌週火曜に審査通過の連絡。24時間以内に契約書にサインしろと。
その時点ではまだ物件を実際に見てもいないし、先の人たちが辞退したのも気になるので、サインするまえに見学できる？と聞いてみたら次の日の昼にセッティングしてくれて、その日の終わりまでにサインしてくれればいいことになる。適当だなw
次の日みんなで見学をし、まーちょっと気になるところもあるものの概ね気に入ったので帰宅後サインした。
気になったポイントは
<ul>
<li>リビングおもったより狭い</li>
<li>バックヤードやっぱ狭い</li>
<li>バックヤードまでの道が遠い</li>
</ul>

リビングが狭いのはいま住んでいるところがダイニングリビングなので余計そう感じる。こんどのところはダイニングが別部屋で存在するので。
ただこれは部屋数が予想より多かったし、2Fがめっちゃ広かったり、ほかの良いポイントで打ち消された。
バックヤードが狭そうなのは元々リスティングされてるのを見てたときから思っていたが、やっぱ狭い。あと直で出られずに最短でもキッチン横の勝手口から出て一角曲ってガレージ横の狭い道をいった先にあるのでアクセスもめんどう。
とはいえ、探しているエリア的になかなか広いバックヤードがある物件はないので、ここには目をつぶり、今後も継続して物件をさがしていこうと思ってる。
BBQとかは表のパティオでやってもよいっぽいし。
見学するまえまで不安だったのは、basement部分の画像が存在しなかったのでそこがめっちゃ汚いのでは？と思っていたがそこは予想に反して普通で、洗濯機とかも綺麗だったので、全然心配することはなかった。
そんな感じでいろいろ不満はあるのだが、立地はすこぶるよく、いまより近くにいろんな店があるにもかかわらず、物件自体は閑静な住宅街にあるという最高な感じなので、楽しんでいきたい。

家が決まった

Linuxデスクトップ環境では<a href="https://awesomewm.org/">awesome</a>というウィンドウマネージャを愛用している。
かなり前の話なのだが、このWMがフォントのレンダリングにつかっているpangoというライブラリがビットマップフォントのサポートをドロップしてしまった。
以下の画像のようにTamsynというビットマップフォントを使用してUIを作っているだが、あるときupdateしたらぜんぶ豆腐になってしまって大変困り、とりあえずpangoは1.43でバージョン固定して、更新しない、という方針でながらくしのいでいた。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50035187302/in/datetaken-public/" title="tamsym-font-otb x awesomewm"><img src="https://live.staticflickr.com/65535/50035187302_5110b5cc22_o.png" width="547" height="63" alt="tamsym-font-otb x awesomewm"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

今日別件で<a href="https://wiki.archlinux.org/index.php/fonts">ArchWikiのFontのページ</a>を見ていたら、OpenType Bitmap (otb) という種類のビットマップフォントならpango 1.44以降でも使えるというのを見て、さっそく、 <code>tamsym-font-otb</code> を入れたら、あっさり最新のpangoでもそのまま(configもそのままで)同じ見た目になって、なんだそれだけのことか…となっている。
しかし、tamsymはotb版はaurにしかないのがちょっとめんどくさいくらい。もっとはやくしらべておけばよかった案件。

pango 1.44以降でのbitmapフォント

COVID-19の影響で子どもたちがずっと家にいる状況だと、いまの2ベッドルームの部屋ではかなり手狭だし、子どもたちが遊べる庭がほしい気持ちが相当たかまってきている。
いま借りているアパートは1年契約で7月末に契約がきれるというのもあるし、家さがしをはじめた。
条件は
<ul>
<li>3BR+</li>
<li>子どもたちがあそべる広さのバックヤード</li>
<li>Gas or Inductionレンジ</li>
<li>オフストリートパーキング</li>
<li>学校まで歩いていける範囲</li>
</ul>

という感じだ(上から優先度高
学校から近いという条件は最初必須と考えていたが(妻が運転しないため)、そうすると物件が少ないため、最近はすこし範囲を広げている。
いままで何件か条件にマッチする物件があったが、見学希望や質問などをしているうちに決まっていってしまってなかなか厳しい。
ポートランドの人気エリアで家探しをするとはこういうことかとあらためて感じている。
気にいった物件はapplyするだけしてからいろいろ聞くのが正解なのかとためしに、いまいちばん気になっているところに申し込みをしてみた。どうなるか。

家探し

タイトルのとおりなのだが、esp-idfのBuild Systemをついにcmakeのほうに変更した。
<a href="https://github.com/espressif/esp-idf">esp-idf</a>というのは、ESP32というマイクロチップのsdkのことで、まえまではmakeによるビルドシステムがメインだった。
それがいつのころか忘れたがcmakeもサポートしはじめ、バージョン3.4くらい(？)からcmakeがデフォルトのビルドシステムとなるようになって、makeのほうはレガシービルドシステムという扱いにされてしまっている。
そうは知りつつもずっとmakeのほうを使いつづけてたわけだが、それには理由があって、
cmakeのほうは基本的に <code>idf.py</code> という、esp-idfが提供するスクリプトからいろいろ操作をするデザインになっていて、そのスクリプトを動かすための前提条件として、 <code>export.sh</code> というのを実行しもろもろ環境変数を設定する必要がある。
しかし、fish shellをメインで使用しているので、その <code>export.sh</code> を使うことができず、そのスクリプトを読解して同等の環境変数を自前で提供してやらねばならぬなぁめんどいなぁ、というのが理由で移行していなかった。
で、最近CO2センサーを買ったので、それを使うためのESP32プロジェクトを始めようと思っていたので、どうせならついでにがんばってcmakeのほうに移行してみるか、という気持ちでやってみたところ、拍子抜けするくらいアッサリ移行できてしまった。
どういうことかというと、<a href="https://github.com/edc/bass">bass</a>というのを使うと、fish shellからbashスクリプトを使ったり読み込んだりできるのだ。これを使って、
<pre><code class="sh">bass source $IDF_PATH/export.sh</code></pre>

とやるだけでよかったのだった。
移行してみた結果:
<ul>
<li>ビルド時間めっちゃ短縮された</li>
<li>compile_commands.jsonが自動で生成される</li>
</ul>

などのメリットがあって、もっと早くやっておけばよかった、感。
compile_commands.json というのはclangdとかcclsとかのlsp-serverの動作のために必要な定義ファイルで、makeのときは<a href="https://github.com/rizsotto/Bear">bear</a>とかを使って自分でがんばって生成していた…。あの苦労はいったい。
そんなわけで、最近はCO2センサーで遊んでいる。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50009307248/in/datetaken/" title="Home environment checker by ESP32 + DHT11 + CCS811"><img src="https://live.staticflickr.com/65535/50009307248_d02c9bc01a_c.jpg" width="800" height="600" alt="Home environment checker by ESP32 + DHT11 + CCS811"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

これについてはまた追って書こうと思う。

esp-idfのBuild Systemをついにcmakeのほうに変更した

子どものときはアスパラが大好きだった。
市販されているアスパラではなく、おばあちゃんが畑で作っていたのを基本食べていた。
上京してから、スーパーとかでアスパラを買ってみると、おばあちゃんのアスパラと比べるとどうしてもおいしくなくて、
結果あまり食べなくなっていた。
市販されているアスパラってなんか育ちすぎ(?)なのか、固い部分がおおいのだよな。<a class="footref" href="#fn1" id="r1">[1]</a>
一方、オレゴンで買えるアスパラはなんと、おばあちゃんのアスパラみたいにやわらかい。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/49976406627/in/datetaken/" title="Oregon asparagus"><img src="https://live.staticflickr.com/65535/49976406627_6f4cc8fc01_b.jpg" width="768" height="1024" alt="Oregon asparagus"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

しかも安い。
こんな遠くはなれた異国で、なつかしのおばあちゃんの味が堪能できて最高すぎて毎回アスパラ買ってる。最高。
<aside class="footdef">
<a href="#r1">[1]</a> 最近どこかでアスパラは上下半分に分けて下の固い部分と上の柔かい部分は別料理で使う、というのを見てなるほどとおもったりした 
</aside>

オレゴンのアスパラはおいしい

自分の思うままに操れる開発スタック<a class="footref" href="#fn1" id="r1">[1]</a>を持っているのといないのとでは、開発速度がまったく違うものになる。
昔Perlでいろいろサービス開発をしていたころは
<ul>
<li>Catalyst or Ark (Web Application Framework)</li>
<li>DBIx::Class (O/R Mapper)</li>
</ul>

に、nginx+MySQL+Redisを併せる、という馴染みまくった環境があり、手足のようにそれらを使っているような感覚があった。
CatalystもDBIx::Classもどちらも開発にコミットしていたし、Arkにいたっては自分が作ったものなので、あたりまえといえばあたりまえだが。
また、それら以外の部分、言語自体が好きとか書いてるエディタの環境とか、そういったものがぜんぶそろわないとしっくり手に馴染むとはいえない。
そのくらい思うままに操れるようになるというのは簡単ではない。
最近そういった開発スタックがなくて悩んでいたが、フロントエンドでは、React (Next.js or ReactNative) with TypeScript がだいぶ手に馴染んでいいかんじになってきた。
Reactはわりと長く使っているがずっとしっくりきていなかったのだが、近年、Hooksという概念が登場し、FunctionComponentをメインに使うようになってきていて、それでやっと自分的にしっくりきて馴染むツールになりつつある。<a class="footref" href="#fn2" id="r2">[2]</a>
バックエンドではいまはそういう環境がないのがいまの悩み。Goを長く使っているが、好きで使っているというよりはいろいろな理由で消去法で決めるとそれになる、という感じで、全然しっくりきていない。
困ったもんだ。
<aside class="footdef">
<a href="#r1">[1]</a> フレームワークとかライブラリとかという意味で使っている 
<a href="#r2">[2]</a> とはいえReactNativeには山ほど気にいらないところがあるのも事実だが…(笑) 
</aside>

手に馴染む開発スタックがない問題

SKKを日本語入力として使っている利点の一つに、Linux、Windows、(キーボード付きAndroid、&amp; 昔はMacも)、どのプラットフォームでも基本的にほぼ同じ操作感で入力がおこなえる、というのがある。
しかし、SKKは仕組み上Shiftキーを酷使する入力方法であり、親指シフト的な入力スタイルを使用しないとつらいというのも事実。
自分はSandSという仕組みでそれを回避している。
SandS (Space and Shift) とは、SpaceキーをShiftの代わりに使う方法で、単純にキーを入れかえるというわけではなく、
単体でSpaceを入力した場合にはSpaceとして機能し、他のキーとの組み合せで入力した場合はShiftになる、というようなものだ。
Macを使っていた時代からSandSを使用してきているので、いろいろなプラットフォームでの実現方法がたまってきているのでここで紹介しておく。

<h3>自作キーボード</h3>
キーボード自体でSandSをサポートしてしまうのが、プラットフォームのことを考えなくてよいので、最も効率的な方法だ。
いまどうなってるか追ってないので不明だが、数年前の<a href="https://github.com/qmk/qmk_firmware">QMKファームウェア</a>では、そのままでは実現できなかったので<a href="https://gist.github.com/typester/1ce6cbf4365b52ee59f011f70fd5b870">パッチ</a>を書いた覚えがある。2 years agoらしい。
これでlayoutに <code>LSFT_T(KC_SPC)</code> と指定すればSandSになる。
ゲームとか、このままだと不都合がおこるアプリケーションも多いので、普通のスペースとして動作するレイヤーも作っておくと良い。

<h3>Linux</h3>
<a href="https://github.com/alols/xcape">xcape</a>とxmodmapで実現できる。
<pre><code class="sh"># SandS
xmodmap -e 'keycode 255=space'
xmodmap -e 'keycode 65=Shift_L'
xcape -e '#65=space'</code></pre>

<h3>Windows</h3>
<a href="http://coexe.web.fc2.com/skkfep.html">SKK日本語入力FEP</a>自体にそのオプションがある。素晴しい。

<h3>Mac</h3>
<a href="https://karabiner-elements.pqrs.org/">Karabiner-Elements</a>で実現できる？
自分は普通のKarabinerのころまでしかMacを使っていなかったので不明。Karabinerのころは設定にSandSの項目があった。

<h4>追記@&lt;2020-06-05 Fri 18:41&gt;</h4>
<a href="https://twitter.com/k0kubun/status/1269014581726203904">Karabiner-Elementsでもできる</a>とのこと!

<h3>Android</h3>
キーボード付きAndroid端末(Gemini PDA)での話。普通のスマホではSKKは使っていない。
<a href="http://ray-mizuki.la.coocan.jp/software/skk_jp.html">SandSを使えるSKK実装</a>を作ってくれてる人がいるが、そのままだと日本語入力中しかSandSが効かないので、適当に改変して常にSandSになるようにして使っている。
また、Termux上のEmacsなどでは、EmacsのSKKを使ったほうが自然な感じで入力できるので、変換機能はもたない、ただSandSのみを提供するキーボードを作って公開している。
<a href="https://github.com/typester/android-sands-keyboard">
https://github.com/typester/android-sands-keyboard</a>

<h3>まとめ</h3>
慣れてしまうと手放せなくなるSandS、もともとはSKKで日本語を楽に入力するために導入したものだが、いまでは普通にプログラミング書くときすら必須に感じる。
慣れっておそろしい。
あまり使用人口は多くないはずだが、おそらく使っている人はみんな手放せないので、ここまでいろんなツールがメンテされているのだろうなぁ、と感じる。

SandS (Space and Shift) いろんなプラットフォームでのやり方

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なアプリがとても良い

実際使ってみるといろいろ微妙なところや、不具合があって困ったのでメモしておく。
<ul>
<li>Zoomがまともにできない</li>
<li>スリープ中usb-c経由の充電がされないっぽい</li>
<li>スリープ復帰後WiFiが激遅になる問題</li>
<li>ユーザー名の罠</li>
<li>GrammarlyとSKK日本語入力FEPの相性がわるい</li>
<li>タッチパッドでのマウスドラッグのロックができない</li>
</ul>

後半はSurface Go固有の問題ではないが、併記してしまう。

<h3>Zoomがまともにできない</h3>
これが一番困っている。Zoomミーティングがまぁほぼまともに出来ない。
普段は別にいままで通りデスクトップで会議に参加すればいいので問題ないけど、
Surface Goだけを持って旅行に行ったり、とかいうシチュエーションを考えるとなかなか厳しさがある…。
まだこれはいろいろ検証中なので、確実な原因についてはあまり書けないのだが、
<ul>
<li>USB-C給電中だとほぼダメで、映像・音声ともにブチブチ飛ぶ</li>
<li>ACアダプタ給電orバッテリー駆動だと30分くらいは普通に動く</li>
<li>それでも長時間のミーティングになると同様にブチブチになってしまう</li>
</ul>

Zoomの使い方は、チーム(5人or3人)でのミーティングがいちばん多い、1:1だともっと長時間いけるかもしれないがためしていない。
長時間やるとだめになる、というのはCPUとかが熱もってスロットリングがかかってる、というのがありえそうだが、
そういう状況でも動いてほしいのだけどなぁ。USB-C のは謎すぎる。
Go 2 のセールスポイントの一つとして、高品質なフロントカメラとデュアルマイクがあって、それはこういうリモート会議のためのものだと思うので、期待からの落差がすごい。

<h3>スリープ中usb-c経由の充電がされないっぽい</h3>
これはそのまんま。かなり使い勝手がわるい。
独自ACアダプタを使ってほしいからわざとこうしてるのか？
いずれにしても、Zoomの問題もあるし、USB-Cの実装にいろいろ問題はかかえていそう。

<h3>スリープ復帰後WiFiが激遅になる問題</h3>
これは初心者殺しの不具合でかなりビックリしたが、通常300Mbpsくらいは普通に出る環境で、sleepから復帰すると300kbpsとかになってまともに通信できなくなる。
最初は一回 Airplane mode をトグルしたら直ったのでそうやっていたが、毎回毎回おそくなるのでこりゃたまらんとググったら以下のredditの投稿を発掘:
<a href="https://www.reddit.com/r/Surface/comments/dp96pb/psa_workaround_for_slow_wifi_after_waking_from/">https://www.reddit.com/r/Surface/comments/dp96pb/psa_workaround_for_slow_wifi_after_waking_from/</a>
これによるとこれは Go 2 だけの問題ではなく、同じ Intel AX201 を使ってる新しめ Surface 共通の問題らしいが、これがいまだに解決されてないというのに驚く。
この投稿の通りに設定していちおうの解決をみている。

<h3>ユーザー名の罠</h3>
Windowsの初期設定で普通にMicrosoftアカウントでサインインしたら、ユーザー名(ファイルシステム上でホームディレクトリ名とかでつかわれるやつ)が <code>types</code> になってて笑った。
まぁべつにそれでもいいか、と最初は無視してたんだけど、WSLを設定して使いだしたらそこでのユーザー名がほかのPCたちと違ってるといろいろ面倒なのでやはり変更することにした、が、かなり大変だった。
手順は以下のサイトを参考にした:
<a href="https://www.groovypost.com/howto/change-account-name-windows-10/">https://www.groovypost.com/howto/change-account-name-windows-10/</a>
とても手順がおおくて大変すぎた。初期設定のところで設定なにかみのがしたかなぁ？

<h3>GrammarlyとSKK日本語入力FEPの相性がわるい</h3>
Google Chromeで日本語入力をしてると入力中の文字が頻繁に消えて困った。
なにかと思ったらどうもGrammarlyの拡張が悪さをしてるらしい。Linuxだとこの問題はおきてない<a class="footref" href="#fn1" id="r1">[1]</a>ので、Windows版のChromeのほうの実装の問題かもしれない。
とりあえずGrammarlyの拡張はメニューバー(アドレスバー?)のアイコンをクリックしないと動作しないようにして回避してるが、不便だ。

<h3>タッチパッドでのマウスドラッグのロックができない</h3>
これは説明が難しいのだが、MacやLinuxでできるような、ダブルタップでマウスドラッグをスタートし、そのまま指を離してもドラッグが維持され、再度タップでドラッグ終了というのがWindowsだとできないっぽい。
なにか追加でソフトウェアいれてもよいから実現したいが、いまのところ解決法はない。かなり不便。

<h4>追記@&lt;2020-05-29 Fri 10:36&gt;</h4>
これは <code>Settings -&gt; Devies -&gt; Mouse -&gt; Additional mouse options -&gt; ClickLock</code> の設定で実現できる、と<a href="https://twitter.com/hnakamur2/status/1266408839575769094">教えてもらった</a>。
これは実は前にも試したことがあったのだが、うまく発動させられなくて違うオプションだと思っていたのであった。
これはドラッグを維持している時間に応じてこの機能がアクティベートされるようになっているからっぽく、さらに奥のSettingsでその発動するまでの時間を短く設定したら違和感なく使えるようになった、きがする。しばらくこれで試してみる。
<aside class="footdef">
<a href="#r1">[1]</a> Linuxでの日本語入力周りは別の問題があって昨年レポートしたことはあるが、すぐになおしてもらえた
</aside>

Surface Go 2 微妙なところ

発表された日に注文して、発売日(5/12)に届いた。LTEモデル。
だいたい2週間ほど使っていることになるが、いまのところ、かなり満足している。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/49940892433/in/datetaken/" title="P5268375"><img src="https://live.staticflickr.com/65535/49940892433_a8da7085f0_k.jpg" width="2048" height="1536" alt="P5268375"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

自分の場合、ここ数年は日常的に使用しているコンピュータは、スマホを除くと、
<ul>
<li>デスクトップPC (自作機、メイン作業環境、Linux)</li>
<li>ラップトップ (ASUS ZenBook3、Linux)</li>
<li>iPad Pro 9.7inch (iOS)</li>
<li>Gemini PDA (Android + Termux)</li>
</ul>

というような感じになっていた。
日本に住んでいたころは、オフィスではラップトップで作業し、家ではデスクトップで、というように使いわけていたが、
アメリカに引っ越してからはずっとWFHなこともあり、仕事にはほとんどデスクトップしか使わなくなっていた。
しかしラップトップを全然使わなくなったか、というとそういうわけではなく、
子どもみながらSlackやメールを読み書きしたりとか、諸事情でPCからしかストリーミングできない動画をTVに流したりと、そこまで頻度は高くないがちょいちょい使っている、という状況。
iPadも同じような頻度で使っていて、こちらは主に読書、楽譜表示、Webブラウジング用。
もともと小説を読むのにはKindleを使っていたのだが、別途充電するのがめんどくなって家では基本iPadですますようになった。<a class="footref" href="#fn1" id="r1">[1]</a>
しかし、メインPCに比べると使用頻度が高くないこの二つのデバイスの充電を維持するのがなかなか面倒になってきていて、
特にiPadは充電がLightningケーブルということもあり、使おうとするとバッテリーなくなりそうになってる、みたいなことが頻発していた。
そんなわけで、これらを1つにまとめられないかな〜と思っていたところに、Surface Go 2 の噂が流れていたので、ひそかに狙っていたのであった。
結果として、iPadの置き換えは一瞬で完了した。もともとほぼKindleとブラウザしか使ってなかったので、Kindleアプリいれたらもう終わり、みたいな感じ。
使用感は iPad 9.7inch と比較すると重く、ずっしりと重量を感じるが、まぁ許容範囲。Kindleアプリの使い勝手がいろいろ違うので若干とまどうが慣れると思っている。漫画がまとまらないのはツラいなぁ…
<div class="image">
 <div>
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/49936459058/in/datetaken/" title="00100lrPORTRAIT_00100_BURST20200513184217798_COVER"><img src="https://live.staticflickr.com/65535/49936459058_2bbcc545d0_k.jpg" width="2048" height="1536" alt="00100lrPORTRAIT_00100_BURST20200513184217798_COVER"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
 <div class="caption">単体で自立するのは地味に便利</div>
 </div>
</div>

ラップトップの置き換えもSlackもGmailもブラウザさえあればいいのですぐに完了。
タイプカバーキーボードは思ってたよりキーピッチが狭いが、問題なくタッチタイプ可能。<a class="footref" href="#fn2" id="r2">[2]</a>
いちおう仕事も出来るように環境を整えようとしたら、これがなかなか大変で時間がかかった。
こちらはまた時間があるときに別途エントリーにしようと思っているが、メモリもマシンパワーも限られているので、基本的にデスクトップに<a href="https://mosh.org/">mosh</a>で繋いで作業する前提の環境として構築。
また、微妙な仕様や、不具合っぽい挙動など、あまり良くない点もいろいろあった。こちらもまた別途まとめたいと思う。
全体的にみてとても良いデバイスで気に入っているが、いろいろ制約も多く、人にすすめられるかと言うと微妙だ。
このサイズ、スタイルでスペック強いのが出たらもちろん最高だが、そうなるとエントリーモデルという位置付けではなくなってしまうし、おそらくそういうのはあまり出ないだろう。
ノートPCの市場自体も大型化が進んでいて、スペックの良いのは基本的に13inch以上、それ以下の小さいものはChromebookとか廉価な学生用とかエントリー向け、というような流れになってしまっている。
なので、自分のように小さいラップトップを好む人たちは、小さいが廉価なPCを買って高スペックなデスクトップなりサーバに繋いで作業する、という時代がしばらく続くのではないかなぁと思っている。
<aside class="footdef">
<a href="#r1">[1]</a> 旅行とかには逆にiPadではなく、Kindleを持っていく
<a href="#r2">[2]</a> 自分はGemini PDAでも高速タイピング可能なのであまり参考にならないとは思うが 
</aside>

Surface Go 2 を買った

このサイトの<a href="https://nextjs.org/">Next.js</a>はずっと更新していなかったのだが、<a href="https://nextjs.org/blog/next-9-3">9.3</a>でこういう静的サイトの構築に便利な機能が追加されたのでアップデート。
<code>index.json</code> とか、 <code>exportPathMap</code> をがんばってscriptで生成したりする必要がなくなっただいぶスッキリした。
しかし結局RSS Feedの生成はする必要があって、そのスクリプトはRSS専用に残った…、のであんまり変わっていない。
まぁ、npm auditのsecurity警告がいっぱい出ていたので、それを消せただけでもヨシとする。

Next.jsをアップデートした

今月来月と、妻の仕事の関係で、家族で日本に滞在している。
いまのこの状況を考えると、妻だけで帰国したほうが良かったと思うのだが、もろもろ飛行機の手配などをしたタイミングでは、日本ではコロナはだいぶ落ち着いていると予想していたので、家族全員で帰国する良い機会だと思ってしまったのであった。
結果、ホテルなどでの強制隔離はなかったものの、成田で延々待たされ、その後も公共交通機関は利用できないのでレンタカー移動だったりと、なかなか大変であった。
ただ、レンタカーについては体験が思いのほか良いので、今後も帰国の際には利用するかもしれない。
というのも、僕も妻も実家が超田舎のため、車がないと親の車に頼ることになり、かなり不便なのである。また子どもを連れて大荷物をもって移動する際も車移動のほうがかなり楽なので親サイドとしては良いことが多い。
一方、運転手が疲れる、とか、乗り物好きの子どもの欲求が満されない、などのデメリットもある。
ただ、前者はUSで運転しまくっているので、昔ほど運転に疲れなくなったのであんまり関係なくなり、後者は今回は隔離がおわっても公共交通機関はなるべく避けたいので、今回にかぎっては我慢してもらうことに。
そんなこんなで2週間の隔離期間も終わり、日本を堪能するぞーという時に子どもが熱をだしてしまった。
とりあえず隔離期間はおわっているので普通に受診して良いはずと、近所の小児科医院に連絡するも、
海外からの帰国中で熱があることを伝えると、熱だとうちでは診るのは無理なので大きい病院に連絡してもらえますか？ と断われれてしまう。しかも結構対応がひどく、熱があることを伝えると「熱www」みたいな反応でこちらが悪いことしている気分になってくる。
二週間の隔離は終わってるって伝えてはいたのだが…。
そんなわけで今度は最寄りの総合病院に連絡、ただここは小児科が空いてる日じゃなかったので翌日以降でないと見てもらえなかった。
ただ、電話口の方が親身に相談にのってくれて、厚生センターの最寄り支店の電話番号などをおしえてもらえた。
で、厚生センターのその支店に連絡すると、やはり2週間の隔離がおわっていれば普通に受診して良いというお墨付きをもらう。
ただどこに行けば良いか？っていう質問にはどこでも良いですよ、としか言われず、また困ってしまう。あんまり特定の病院をおすすめしてはいけないのかな？
最初にかけた小児科に厚生センターの見解をつたえて交渉する、という手もあったが、最初の電話でかなり印象が悪かったので、まったく連絡する気になれず、義母が評判が良いと聞いているという別の小児科に連絡してみる。
最初の小児科で、外国から来ている人への不信感がある病院があるということがわかったので、今回も厚生センターの話はしないで連絡してみた。
ほんとは嫌だけど厚生センターが良いって言ってるなら診ますよ、みたいに嫌々対応されるとこっちも嫌だからだ。あと、最悪翌日になれば少なくともさっき連絡した総合病院では診てもらえることがわかっていたので。
心配をよそに、今回はあっさりと「診ますよ〜」と言ってくれてその場で30分後くらいの予約を入れてくれて、かなりスムーズに診察してもらえた。
駐車場で診察を待つスタイル(USっぽい)になってて、スタッフの対応もよく、薬局も隣にあり、とても良い病院であった。
なんというか結果的には最初にかけた病院がだめだっただけっていう話で、運がわるかったということなのだが、無駄に疲弊してしまった。まぁ最終的には帰省先の良い小児科を見つけられたので悪いことだけではないけど。
帰国者に対する謎の不のイメージがあるっていう話は良く聞くけどこれがそうか〜〜という体験であった。

一時帰国中の病院

E
この1年ほどメイン開発環境をWindowsにしてみる、というのをやってみていたが、1年たってもしっくりこないままなので、結局Linuxに戻してしまった。
ただ、Windowsの良かった点もいくつかあって、一番はリモートデスクトップがとても良くできているところ。
自分の普段使いのマシン構成は、高スペックデスクトップPC + Surface Go 2 で、Surface Goはかなり非力なのでそれ単体で仕事をしたりするのはかなり厳しい。 しかし、Windowsのリモートデスクトップを使えば、Surface Goから違和感なくデスクトップPCを操作することができ、安定したネット環境さえあればどこでもそれで十分作業ができる。これはなかなか良い体験だった。
リモートデスクトップが実用的に使えると、Surface Goはサブマシンとしてかなり良い。iPadの代わりのタブレットとしての用途だけでなく、やろうとおもえばガッツリ仕事にも使える。持ちはこぶのも楽々だし。
その体験がとても良かったので、Linuxホスト(Windowsクライアント)でもおなじような環境が作れないものかといろいろ試行錯誤した。結果、Chrome Remote Desktopがいまのところ一番満足度が高いという結果になった。
CRDの良いところは、
<ol>
<li>クライアントのスクリーン解像度にあわせてリモート側の解像度も変わる</li>
<li>音も出る</li>
<li>低遅延<a class="footref" href="#fn1" id="r1">[1]</a></li>
<li>4K(+ HiDPI)でも実用に耐える</li>
</ol>

という感じ。他にもそれ単体でNAT越え機能がついてるというのも人によっては嬉しいだろう。僕の場合はVPN経由でもアクセスできるようにしているのでこれはどうでもよいのだが。
1,2ができることで、Windowsのリモートデスクトップと使用感がかなり似ている。ただし、Windowsのそれは本体側のスクリーンをそのまま操作するようになっているのに対し、LinuxホストのCRDは本体側で別途リモート専用のXセッションを立ち上げる形で実装されているので、重複起動ができないアプリを本体側で起動していたりするとめんどうなことになる。あと開発系のツールでport空けるやつとかが使おうとしてる環境とは別側で動いてたりとかも。
4K HiDPIな環境で使うには少しトリッキーなことをする必要がある。WindowsでHiDPIにしていると、(例えば3840x2160のディスプレイを200%にスケールさせて使っていると、)Linux側では1920x1080のデスクトップとして扱われてしまうので、全体的にぼんやりとして表示になってしまう。 めんどうだが、まずWindows側のディスプレイ設定を100%にした上でリモート接続する。その上でLinux側で普通にHiDPIの設定をするとすべて上手く行く。 ただ、3840x2160のディスプレイ解像度で接続しつつ通信量を見てみたのだが、瞬間的に20Mbps近くいくこともあるっぽいので、テザリングでこれやるのは慎重に。
Linux側の設定は、xinitでXを起動している僕のようなユーザーにとってはかなりとっつきやすいものになっている。 <code>~/.xinitrc</code> の代わりにCRDでは <code>~/.chrome-remote-desktop-session</code> が使われるのでそこに同じようなことを書けば良い。
HiDPIの設定は <code>.Xresources.remote</code> に書いている<a class="footref" href="#fn2" id="r2">[2]</a>。ここがいま一番悩ましいところで、使うディスプレイによって200%が良いときと150%が良いときがあるし、他にも出先でLTE回線で使う時は100%で使いたい、とかクライアントの事情によってフレキシブルに変更したいことがあるのでこの仕様は不便だ。
自分がリモートデスクトップを良く使う環境はまずSurface Goでこれは150%表示で使いたい。次にがっつり作業したい時などはSurface Goにポータブルモニタを繋げてそちらにリモートデスクトップをわりあてている。この時はできれば200%表示が良い…、みたいな感じ。倍率変えて起動しなおすのもそこまで手間ではないが、リモートデスクトップを使う時の手順がまずWindowsのほうで使うディスプレイを倍率100%にするところから始める必要があるので、リモートの倍率設定までしているとかなり手順が多くなってしまう。
他の悩ましい点としては、Win-LキーがWindows側にどうしてもとられてしまって、リモートでは使えないところ。awesome wmでwindowのサイズ変更に使用しているので、ちょっと困る。他のキーに割り当てを追加したが、慣れるまでは大変そうだ。
などなど微妙な点もそれなりにあるものの、トータルではこの環境にかなり満足している。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/51413138381" title="My mobile workstation 2021"><img src="https://live.staticflickr.com/65535/51413138381_35903df32f_h.jpg" width="1600" height="900" alt="My mobile workstation 2021"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

ガチで作業するときの図。右がLinux、左に普段はMacをそれぞれリモート接続している。Surface GoのようなタブレットPCは単体で使うと本体なのにサブディスプレイ的なポジションにもなれるのも良い。
<aside class="footdef">
<a href="#r1">[1]</a> VNC、xrdp、X forwarding via sshと試した中で一番良かった
<a href="#r2">[2]</a> これを前述のinitファイルから xrdb -merge してる
</aside>

LinuxホストでのChrome Remote Desktopはとても快適

<a href="https://unknownplace.org/blog/2020/08/25/moved/">1年前に引っ越しをしたばかり</a>なのだが、その家のオーナーが家を売りたいということで、急遽引っ越しが必要になった。
最初に連絡が来たのは契約の更新のタイミングで、その時は正式な通知書を準備しているところ、ということで、
その通知書を受け取った時から90日以内に引っ越す必要があるということだった。
Rentに出して1年で売るなら最初っから言っておいてくれよ〜という感じだが、このCOVID状況下ではいろいろ予想外のライフイベントが発生するからまぁしょうがないよなぁという感じだ。<a class="footref" href="#fn1" id="r1">[1]</a>
というわけで引っ越し、二回目なのでだいぶ慣れている。基本的には<a href="https://www.zillow.com/">zillow</a>で探す。条件設定しておくて該当物件が出たときにメールで通知してくれるので便利だ。
craigslistとかにも出ているのだけど、scamがあったりするので、今回はまったく見なかった。
今回はSellwoodというエリアと、Richmondというエリアを重点的に探した。
前者は新興住宅地っぽい感じなのだが、町の雰囲気が夫婦ともに好きなのと、おきにいりグロッサリーであるNew seasons market(の大きいやつ)もあり、なんといってもSellwood Parkは川遊びプール遊びができ、Playgroundも広くしかも日陰、スケボースポット(パークではないけど)もある最強エリアでとても気になっていた。
後者は1年前まで住んでいたあたりで、Divisionストリートというオシャレストリート沿い。土地勘もあるし、子どもたちの学校に歩いていけるということで当然の候補に。
この辺のエリアは、良い物件はzillowに出た瞬間に申し込みをしないと、だれかに持っていかれてしまう。
1年前はじめて引っ越しをしたときは最初それがわかっていなくて、日本の賃貸の感覚で内見の申し込みをして〜みたいなことをやっていたら<a href="https://unknownplace.org/blog/2020/06/22/looking-for-new-house/">全然だめだった</a>のを思いだす…(笑)
今回はそれを踏まえ、良い物件があったら即apply。applyしたあと、契約できそうな順番がまわってきてから内見をし、そのあとでサインするか決める。という流れだ。なのでapplyしても絶対に契約しないといけない、というわけではない。
ただ、applyするには手数料がかかるのが普通で、$20〜$40くらいなのだけど、大人の人数分かかるので、何件もapplyしているとけっこうな額になってしまう。なかなか良い商売だな〜。
今回はまずSellwoodの物件に問い合わせ。この物件はまだapplyできなかった。前住民が退去したあと内見できるということで、そのwaitlistに加えておいてもらう。
その次にRichmondで良い物件があったので申し込み。リストされた日に申し込みをしたにもかかわらず、すでにzillow上では申し込み数が4と出ていた。でも4ならけっこう可能性がある。1年前の引っ越しのときも3番目だったのだが、前2組が辞退したので順番が回ってきたのだ。みんなこうやって複数申し込みをしているので、先にどこか決まると抜けていくのである。あと当然、中見てみたら気にいらなかった、とかもあるし。
他にも継続して探していたのだが、Richmondのほうのオーナーから、「君が一番目なんだけど、どうする？」みたいに連絡がくる…。あれ…、4番目じゃないのか？ 前回の物件は管理会社が入っていたので、機械的に申し込み順で処理してたけど、今回はオーナーが直に管理しているところなので、 applicationの中からどれを選ぶのかはオーナー次第なのかもしれない。
いずれにしてもラッキーだ、すぐに内見の申し込みをする。
その時はまだ前の住人がいたのだが、そのタイミングで家を空けてくれる、ということで、すぐに内見することができた。個人的には、清掃されて綺麗な状態より、実際に人が住んでいるところを見れたほうが参考になるからこれまたラッキー。
物件は3BRで引っ越し前と同じなのだが、前のところはそれにカウントされない部屋というかスペースがあり実質4BRだったので、少し狭くなってしまう。
ただ、今回のところはアホみたいに広いベースメントがあるのと、広いバックヤードがある。あとガレージも広くなる。まえのところはバックヤードもガレージもとても狭く、ほとんど使えなかったのでその点はかなり良い。
キッチンのアプライアンスも問題なし、むしろキッチンはかなり良い。キッチンからバックヤードが見えるのもポイントたかい。あと全フロアがフローリングなのもよし。こっち結構カーペットの家あるけど個人的にはあんまり好きじゃないのよね。
とまぁ、そんな感じで、今までの家と比較してマイナスポイントがほぼない。先述のようにちょっと部屋数が減るのと、あとは広くて眺めのよかったお風呂がなくなるのがちょっとさびしいくらい。
それでも圧倒的にプラスなことがおおい。そして家賃も微妙に安くなる…(重要)! ので、この物件で即決した。
最終的にいろいろapplyしまくることになると思いきや、2つ(実質1つ)で済み、とてもスムーズな契約だった。なぞにツイてるな〜。
で、先週半ばに引っ越しをし、先週末に前の物件を引き払い、unboxingしながらの生活をしております。
ちょうど<a href="https://www.hom.ma/pro">仕事もめっちゃ忙しい</a>時で、なかなか開封がすすまないのだけど、あまりそれを言い訳にしていると奥さんに負担がめっちゃかかるので、ちょっとずつでもやっていくぞ!
しかし、最初に住んだアパートも次に住んだ家もどちらも日本からのお客さんを一人も招かないまま引っ越してしまった。はやくCOVIDがおちついていろいろな人が来てくれるようになると良いなぁ。
<aside class="footdef">
<a href="#r1">[1]</a> あとでオーナーと会う機会があったのだが、やはりどこかに引っ越すみたいな感じだった 
</aside>

2回目の引っ越し

最近(といっても半年くらいたってる気がするが)、<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

その昔(10年以上まえ？)、IRCにハンターたちが集う <code>#mhmhmh</code> というチャンネルがあった。
当時のモンハン(MHP2 &amp; 2G)は、インターネット越しでマルチプレイすることはできなかった。
ただ、同じ場所にいる人たちとのアドホックネットワークをつかったマルチプレイはサポートされていたので、XLink Kai <a class="footref" href="#fn1" id="r1">[1]</a>というインターネット越しでローカルのアドホックネットワークをエミュレートするツールを利用して無理やりインターネット越しにマルチプレイをしていた。
このkaiというツール、仕組み上、WiFiドングルが必要だったりして、セットアップがかなり難しかった。それにもかかわらず、 <code>#mhmhmh</code> はいつも人がいて、みんなの情熱がすごすぎた🤭
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/2220296859/in/photolist-2JqXjc-4ogEVb-4AZEmB-4B4VVC-4ocB16-4ocAZe-4ogF6d-4ocAXc-4ocAWr-4ogF3u-4ocAUk-4ocATn-4ocAS8-4ocAR8-4ocAQe-4ogEWh-4ocAMx-4ogETs-4ocAKt-4ocAJF-4ogEQs-4ogEPA-4ogENw-4ocAEz-4ogELG-4ogEKU-3JnriK-3JnrcZ-2ZgBmA-2ZeHow-3aQrUH-3aQrST-3aQrQV-3aUY21-3aUXZj-3aQrKg-2UEthR-2UJSK9" title="20080119175342"><img src="https://live.staticflickr.com/2189/2220296859_b70c0749a3.jpg" width="480" height="272" alt="20080119175342"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/2221090812/in/photolist-2kfrCi9-4xPxQ9-7iKKd-7bCiiQ-4xKkft-qgwE-cFPzx-6F4yd-4xPwSU-4xKkuR-6F4yC-2JqXjc-cFPrn-4AZEmB-4B4VVC-5X7Keg-4xPx9C-4xPwDm-4ocB16-4ocAZe-4ogF6d-4ocAXc-4ocAWr-4ogF3u-4ocAUk-4ocATn-4ocAS8-4ocAR8-4ocAQe-4ogEWh-4ogEVb-4ocAMx-4ogETs-4ocAKt-4ocAJF-4ogEQs-4ogEPA-4ogENw-4ocAEz-4ogELG-4ogEKU-3JnriK-3JnrcZ-2ZgBmA-2ZeHow/" title="20080119163608"><img src="https://live.staticflickr.com/2341/2221090812_67816b9dbc.jpg" width="480" height="272" alt="20080119163608"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/1792188849/in/photolist-2JqXjc-4ogEVb-4AZEmB-4B4VVC-4ocB16-4ocAZe-4ogF6d-4ocAXc-4ocAWr-4ogF3u-4ocAUk-4ocATn-4ocAS8-4ocAR8-4ocAQe-4ogEWh-4ocAMx-4ogETs-4ocAKt-4ocAJF-4ogEQs-4ogEPA-4ogENw-4ocAEz-4ogELG-4ogEKU-3JnriK-3JnrcZ-2ZgBmA-2ZeHow-3aQrUH-3aQrST-3aQrQV-3aUY21-3aUXZj-3aQrKg-2UEthR-2UJSK9" title="シャキーン"><img src="https://live.staticflickr.com/2089/1792188849_380e9a37a8.jpg" width="480" height="272" alt="シャキーン"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

それからモンハンは何作も出てきて、だいたいプレイしてきたけど、どれも当時ほどの盛り上がりを持てなかったし、プレイ時間も100時間行くことはなかったように思う。(MHP2Gは800時間くらいやりました……)
しかし、Switchで3月に発売された Monster Hunter Rise、これはちょっと、いやかなり面白い。体験版をやった時にビビッと来て、またやる気になった。
なんというか翔虫(かけりむし)という仕組みを導入したことで、いままでのシリーズの良いところを総取りしたようなうまいバランスになっていて、絶妙の面白さになっている。
というか発売されて1ヶ月くらいだけど、もう翔虫のないモンハンとかあまりかんがえられない感じになっちゃってる。次作どうするんだろう…。
そんなわけで、 元 #mhmhmh のみなさんも、そうじゃない人も、ゆるーくつながって一緒に狩りにいきましょうってことで、新しくDiscordサーバを立てたのでこぞって参加ください。
<blockquote>
MHMHMH - Discord
<a href="https://discord.gg/jujcvzjh3k">https://discord.gg/jujcvzjh3k</a>
</blockquote>
<aside class="footdef">
<a href="#r1">[1]</a> 検索したらまだあって笑った。需要はいまだにあるっぽい <a href="https://www.teamxlink.co.uk/">https://www.teamxlink.co.uk/</a>
</aside>

#mhmhmh復活。知ってる人も知らない人も一狩り行こう

若い頃からコーヒーが好きで、おそらく高校生(もしかしたら中学生かも)くらいから習慣的に飲んでいて、20代のころはそれこそ一日中コーヒーを飲んでいた。
僕と一緒に仕事をしたことがある人は、職場にコーヒー道具一式を持ち込んでいたから、どのくらいコーヒー狂いか知っているだろう😅
それでも、効果的な睡眠を模索していると午後のカフェイン摂取は厳禁、みたいな話があったり、そもそもカフェインのとりすぎはよくないという風潮なので、ここ5年ほどは朝一のコーヒー+仕事始めのコーヒーの2回だけ淹れる、という感じになっていた。
ただ、1回につき2杯分淹れ、奥さんが欲しいといったら半分あげる、みたいな感じなので、日によってかなり摂取量にバラつきがあった。全部一人で飲んだ日は4杯分、600ml以上摂取してることになる。<a class="footref" href="#fn1" id="r1">[1]</a>
特に健康に影響があるのは感じでいなかったのだけど、最近またいろんなところでカフェイン摂取を減らしたりする記事を見かけるので、気になってきており、そんな時にけんすうさんの以下の記事を見かけた:
<blockquote>
<a href="https://kensuu.com/n/n97bc2640600e">カフェインリセットをしてみたら結構よかったよという話｜けんすう</a>
</blockquote>

単純におもしろそうだ、というのと、止めるとどういう効果があるのだろうという好奇心で自分もやってみることにした。
自分の場合、飲むとスッキリするとか頭がクリアになるとかそういうカフェイン起因のブースト効果は普段あまり体感していなくて、たんじゅんにコーヒーが好きだから飲んでいる感じだったので<a class="footref" href="#fn2" id="r2">[2]</a>、
とくにやめても問題はおきないのでは？という予想のもと気軽な気持ちで始めた。
ところがどっこい、やめた2日目くらいから激しい頭痛におそわれる…😭
ピークは3、4日目だったかなぁ。それから痛みはだんだんおさまっていったが、大体1週間ほどはツラい状態が続いた。完全にカフェイン中毒だったということが判明。
あと、この頭痛には身に覚えがあった。たまに起こる頭痛があって、原因がカフェインではないかと疑ったことはあるのだが、コーヒーを摂取してもあまり良くならないので違うと思っていた。
だが、今回やめた2日目から頭痛が発生したことからこれには時差があって、おそらく直るのにも時差があるんだろう。(完全に予想で書いてます)
つまり直前ではなくもうすこし前にカフェインが切れた期間があると頭痛がおこっていたのかも。直前のことしか気にしていなく、そこまでトラッキングしていなかったので盲点だった。
頭痛がおさまると、こんどは昼間の眠けが気になるように。あまりにダメな時は昼寝して対応。
それも徐々になくなり、1ヶ月もすればほとんど元通りの生活がおくれるようになっていた。
ただ調子が良くなったかといわれるとよくわからない、あんまり変わってない気がするw
とはいえ変わってないように感じても、以前はカフェインの影響で常に血管が収縮状態にあったわけで、それを解消できただけでもうれしい。

<h3>コーヒー再開</h3>
コーヒーを飲まない生活にも慣れて、とくになくても困らなくはなったが、コーヒーは好きだし、せっかくコーヒー豆屋がいっぱいあるポートランドに住んでいるので、少しは飲みたいよなーということで、1ヶ月半ほどしてコーヒーを一杯飲んでみた。
そしたら、やばい。コーヒーやばい。カフェインが体にない状態でコーヒーを飲むと、なにかヤバいものを飲んでる感をものすごく感じる。
体になにかがフワァっと染みわたっていく感じがする。これが本来のカフェインの覚醒感なんだろうか？
コーヒーがとても美味しく感じるし、ヤバい物飲んでる感じの特別感がすごくある。
それ以降は飲んでも1日に1杯だけ、というようにしている。あと、飲まない日も作っている。というのも毎日1杯飲むようにしたら上記の感覚が薄れてしまったので。

<h3>効果</h3>
体調がよくなったりとかはあんまり感じない。中毒状態ではなくなったので確実によくはなっているはずだが、体感的にはあんまりかわらない。飲まなくても頭痛がおきない安心感はあるが。
あとはあたりまえだがコーヒー豆の消費がめっちゃ減ったことにより経済的になった。逆に1つの豆の消費に時間がかかるのでいろいろな豆を試せなくなった。
そしてこれが個人的に一番重要なのだが、コーヒーがより美味しく楽しめるようになった。コーヒーが好きな人こそやってみてほしい。

<h3>コーヒーの代わり</h3>
コーヒーは飲んでも1杯しか飲まなくなったので、その代わりの飲み物を探す必要があった。いろいろ試したがいまは生姜湯とデカフェのコーヒーで落ち着いている。
生姜湯はしょうがを2、3スライスしたのをマグにいれ、そこにお湯をそそぐだけ、というシンプルなもの。たまにはちみつをいれたりもする。はちみつをいれるとかなりおいしくなる上、頭脳労働の疲労回復にもよいので一石二鳥。
めんどくさいので、しょうがはスライスした当日の間は再利用していて、2杯目以降はお湯(+はちみつ)をつぎたすだけ、という感じの手軽さ。そのためにすりおろすではなくスライスにしている。
デカフェは習慣としては飲んでいないけどいちおう買ってあって、なにかコーヒーとあわせたらおいしいものとかがあるときに淹れている。普通のコーヒーと比べるとやっぱりおいしくないので、ここはなにか良い代替品をもうすこし探したい。
そんな感じで、あまり目にみえる体調向上とかはないけど、総合的にはやってよかった! やるべきだった! という結論。

<h3>注意</h3>
離脱症状で頭痛がおきるのは、中毒状態だとカフェインで血管が収縮状態にあるからというのが理由らしいので、人によっては一気に完全にカフェイン摂取をやめてしまうと危険な場合がありそう。高血圧の人とか。なのでもしこれを読んでやってみよう、と思ったひとがいたらそのへんを十分注意してやってほしい。
<aside class="footdef">
<a href="#r1">[1]</a> うちでは一杯160mlくらい
<a href="#r2">[2]</a> 今かんがえるとこれはカフェイン過剰摂取の影響でカフェインの効果が感じられない状態だったと思われるのだが
</aside>

コーヒーを1ヶ月半ほど止めてみた

もう1年近く前の話なのだけど、去年の4月から <a href="https://www.hom.ma/">HOMMA Inc.</a> でソフトウェアエンジニアとして働いている。
最近(といってもこれも数ヶ月前の話なんだけど😅)ジョインしてくれたエンジニアがSlackに入ったときに僕を見つけて驚いた、と言っていて、そういえばどこにも所属をあきらかにしてなかったな、などと思ったのでいまこれを書いている。
ポートランドに移住してから、いままでやっていた日本の仕事を継続して手伝いつつ、こちらでの仕事を探していた。そんな時に以前からの知人であるきょろちゃんが以下の記事を書いていて、とても興味を持った。
<blockquote>
<a href="https://sftt.jp/2020/02/07/building_smart_home_as_software_engineer/">ソフトウェアエンジニアとして家を建てる仕事をはじめました - SF Tech-Tech</a>
</blockquote>

スキル的に、自分はWebのバックエンドからキャリアを始めたが、興味あることに手を出しまくった結果、いまではWeb&amp;Mobile開発はフロントエンド・バックエンドどちらもできるし、Cでネットワークや音声処理したりとか、さらにはFreeRTOSでのファームウェア開発まで、幅広くできるようになってしまった。そういうわりとなんでもできるのを生かせそうだと思ったのが一点。
もう一つはスマートホームという分野。いままでもいわゆるスマートホームデバイスの開発をやっていたので、引き続きやってきたことが生かせそうだし、あとづけでデバイスを設置するのではなく、家をいちから作るというのは、いままでかかえていたいろいろな制約を超えられそうだという個人的な興味もあった。
それだけではなく、なんとこの会社の次のプロジェクトはポートランドらしい、ということで、これはジョインするしかないのでは、ということで早速コンタクトをとったというわけ。

<h3>近況</h3>
最近はそのポートランドのプロジェクトが始まり、そこに入れるソフトウェアの開発に集中している。
<blockquote>
<a href="https://www.hom.ma/homma-x">HOMMA X</a>
<div class="image">
 <a href="https://www.hom.ma/homma-x">
 <img src="https://images.squarespace-cdn.com/content/v1/5e8763e7333b8827ab08204c/1594929210944-X3O9J8YG6416W8ONO7JS/ke17ZwdGBToddI8pDm48kPTrHXgsMrSIMwe6YW3w1AZ7gQa3H78H3Y0txjaiv_0fDoOvxcdMmMKkDsyUqMSsMWxHk725yiiHCCLfrh8O1z4YTzHvnKhyp6Da-NYroOW3ZGjoBKy3azqku80C789l0k5fwC0WRNFJBIXiBeNI5fKTrY37saURwPBw8fO2esROAxn-RKSrlQamlL27g22X2A/FINAL_Burnside_View2-Street.jpg?format=2500w"/>
 </a>
</div>
</blockquote>

このサイトは家から車で10分ほどの位置なので、ごはんテイクアウトついでとかにチラ見しにいったりできるのだけど、おもった以上に工事のペースがはやいので、ソフトウェアサイドとしては焦りを感じている…😇
HOMMAのメンバーは少人数だけど、それぞれが何かの専門家、みたいなチームになっていて、建築士やマーケター、リアルエステートの専門家とかいままで関わりのなかった人たちと関われるも面白い。
開発陣はいまのところみんなフルスタックな感じなので、担当箇所がフレキシブルだし、話も早いしで快適。
とりあえずはこのプロジェクトに集中! という感じだけど次のプロジェクトの話もいろいろ進んでいるのでそれも楽しみ。
また、エンジニアは絶賛採用中なので、興味ある人は連絡くれたら紹介しますので是非。

HOMMA Inc. にジョイン

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イメージを作る

週末に練習しているときにスケートシューズに穴が空いているのに気付いた。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50872805072/in/datetaken-public/" title="Hole on my skateshoes"><img src="https://live.staticflickr.com/65535/50872805072_db9b4efb01_b.jpg" width="768" height="1024" alt="Hole on my skateshoes"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

デッキと擦れるところに穴があく、という話を聞いてはいたので、スケートを始めて早々に専用のスケートシューズ<a class="footref" href="#fn1" id="r1">[1]</a>を買っていたのだが、まさかこんなに早く穴があくとは思っていなかった。
みんなここを補強するようにシューグーという糊とかボンドみたいなのを塗るらしいが、やはり塗る必要がありそう。
まだ表の1層に穴があいただけで貫通してしまったわけではないので、いまからでも間に合うだろう。B氏がいうには完全に穴があいてしまっても、靴の中からダクトテープを貼って表からシューグーで固めるという手もあるらしい。
でも、ここがボロボロになっていないのは似非スケーターみたいな雰囲気があるので、ちゃんとスケーターの仲間入りしたっぽい気がしてちょっとうれしい。
<aside class="footdef">
<a href="#r1">[1]</a> 擦れるところが丈夫になっている他、デッキの感覚がわかりやすいように底が平になっていたり、着地の衝撃を吸収してくれるインナーになっていたりとかいろいろあるらしい
</aside>

スケートシューズに穴があいた

去年の9月の終わりにスケートボードを始めて3ヶ月とちょっとがたった。
ポートランドは去年の12月がほとんど雨、もしくは路面が濡れている状態だったため、3週間くらい滑れない期間があったのだが、
それ以外の日はほぼ毎日滑っていた。
といっても、常に練習できていたわけではなく、足首捻挫気味になったり、スケートツールをパーカーのポケットにいれたままそれを体との間で挟むようにして転んでしまい<a class="footref" href="#fn1" id="r1">[1]</a>、肋骨やられたりしたことがあり、そういう時は無理せずプッシュのみ、みたいな感じでゆるくやっている。
そんな感じで12月からほとんど滑れていなかったのだが、雨でぜんぜん滑れないよ、と師匠のB氏<a class="footref" href="#fn2" id="r2">[2]</a>に嘆いたら、雨でもすべれるスポット(しかもうちから車で10分以内)を教えてくれたので、それ以降はまた練習ペースがもどっている。
<div class="image">
 <div>
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50820129783/in/datetaken-public/" title="Covered skate spot"><img src="https://live.staticflickr.com/65535/50820129783_e6db57746f_b.jpg" width="1024" height="768" alt="Covered skate spot"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
 <div class="caption">雨でも練習できるスポット</div>
 </div>
</div>

いまフォーカスしているのは相変わらずオーリー。難しくておもしろい。
いまはだいぶ出来るようになってきていて、前足の擦りの感覚とかもわかってきた。走りながらのオーリーがまだ安定しないので、いまはそれを重点的にやっている。できるようになってきたらいよいよ物越えだ〜というところ。
いままでもいろいろスポーツやってきたけど、このオーリーというのはその中でも郡を抜いて複雑な動きで、しかもそれを一瞬でやらないといけないという、めちゃめちゃ難しい技術。
<ol>
<li>板の上でジャンプ</li>
<li>ジャンプする瞬間、後ろ足でテールを弾く</li>
<li>弾くとき前足が上がっていないとノーズが上がってくるのを邪魔するので前足はすぐに上げる</li>
<li>ノーズが上がってきたらそれを前足で抑えつつ、ノーズにむかって足を擦り上げる</li>
<li>そうするとテコの原理でこんどはテールが上がってくる</li>
<li>その時、後ろ足が伸びたままだとテールがあがってくるのを邪魔するので後ろ足も上げる</li>
<li>板が平行になる</li>
<li>着地</li>
</ol>

この、1から7までをほぼ一瞬でやる必要がある。脳が考えてから手足が動くまでの反応速度がおよそ0.2秒ほどと言われているとおもうので、
考えながらオーリーをやることは不可能で、体に覚えさせるしかない。
YouTubeでうまい人の動画をみてイメトレしたり、自分の動作を動画にとってチェックしてどこが悪いのか分析したりしつつやっていて、少しずつできるようになってきた。
このジワジワうまくなっていく感覚がとても楽しくて、帰ってきて動画みたりしてると、なるほどもっとここをこうすればいいのかな？みたいな仮説がでてきて、すぐにまた滑りたくなってくる。
よくわからないけど脳内に麻薬的な物質でてそうw
そんな難しいトリックなのに、ここから派生するトリックがいっぱいあるという基本的なトリックという位置づけなのがすごい。
パスタでいうとペペロンチーノ的な。そういえばペペロンチーノもちゃんと作るのは難しいと言われるきがする。
他にもショービットやマニュアルも平行して練習してるけど、オーリー練が楽しすぎてほぼオーリー漬けという感じ。
あとは移動にもなるべくスケートボードを使うようにしていて(乗るのになるべく慣れたいから)、路面がよいときはクルーザーボードで、濡れているときはPenny<a class="footref" href="#fn3" id="r3">[3]</a>で自転車専用or優先道路を走っている。
最初はすぐ疲れてあまり効率の良い移動手段とは言えないきがしていたが、最近は1,2マイルなら全然疲れず移動できるようになってきて、移動手段としてもなかなか優秀だなと思いなおしてきた。長い下り坂とかも最初は怖すぎて無理だったけど、いまはブレーキかけながら下りれるようになり、むしろ楽しい…!という感じに。
ほかにも副次的な効果として、体がひきしまってきた、というのがある。とにかく最初はすぐに足の裏がいたくなってつらかった。たぶん板の上で踏ん張るという動作は日常生活にはあまりない動作なので、普段全然使わない筋肉が必要だからだろう。
そういえば最近は足の裏は全然痛くならなくなった。けど、いまでも太股やふくらはぎはどこかかんか常に筋肉痛という状態。いつまでつづくのか…？
今後はスケートパークでもっと遊べるようになりたい。いまは行っても設備が全然使えず、フラットでトリックを練習してるだけなので。
<aside class="footdef">
<a href="#r1">[1]</a> これまじで危ないので、これ以降カバンなど背負っている時はトリックの練習はしないようにしている
<a href="#r2">[2]</a> 前にも登場したスケーターのパパ友。最近は心の中では師匠と呼んでいる🤭
<a href="#r3">[3]</a> ポートランドは秋冬は雨が多く、路面が濡れてる日がおおいので、そういう日のために買いました。<a href="https://www.pennyskateboards.com/collections/22-skateboards">Penny 22 inch</a>。
</aside>

スケートボード進捗

ここ半年ほど、<a href="https://www.youtube.com/channel/UC3p5OTQsMEnmZktWUkw_Y0A">コウケンテツさんがYouTubeで紹介している</a>レシピにハマって、良く作っている。
<blockquote class="twitter-tweet">例によってコウケンテツレシピディナー。今日はクッパ。簡単だしうまかったしあたたまるし、予想に反して子どもにも人気だったので百点😊 <a href="https://t.co/KR2jFH0yvN">pic.twitter.com/KR2jFH0yvN</a>&mdash; Daisuke Murase (@typester) <a href="https://twitter.com/typester/status/1350999459254165511?ref_src=twsrc%5Etfw">January 18, 2021</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

もともと、<a href="https://www.tv-tokyo.co.jp/danshigohan/">男子ごはん</a>を好きでよく見ていて、そこにたまにゲストとして登場するので、存在は知ってはいた。
ある日YouTubeのおすすめに出てきたので懐しいなとおもってみはじめたのがきっかけ。
このチャンネルの良いところはめちゃめちゃ庶民的なレシピばかりだということ。
たとえば、男子ごはんってわりとご馳走料理とか男の料理とかそういうイメージがあって、
なんか材料費にいとめをつけないとか、普段つかわないような材料つかったり、何時間か煮こんだり、みたいな週末料理って感じがすごくする(まぁ週末放送だし)。
そういうのも良いけど毎日の料理にはあまり使えない感じ。
コウケンテツさんのチャンネルで紹介されているのは逆に、普段の材料で簡単に作れるものが多いので、毎日の料理の参考にめちゃめちゃなる。
しかも簡単でシンプルなのに、どれもすこし工夫されていて、それで劇的においしくなるのよね。そこがほんとにすごいなーと思う。
以下、リピートしてるレシピ列挙:
<ul>
<li><a href="https://youtu.be/ThcfmTZr3-I">【韓国家庭料理】素材3つでボリューム満点カリカリモチモチ豚ニラチヂミを作る方法</a></li>
<li><a href="https://youtu.be/w1_pZcetqCs">粉もんじゃない！○○もんだった！素材3つでカリふわなお好み焼きの作り方</a></li>
</ul>

チヂミ&amp;お好み焼き。チヂミはなれると15〜20分くらいで作れる&amp;材料適当にあるものをぶちこむでもよいので朝飯こまったときの定番。
お好み焼きのほうはじっくり焼くのでチヂミ比では時間かかるが、めちゃめちゃおいしい。家族からリピート依頼がくるほどです。
<ul>
<li><a href="https://youtu.be/XIR5_jmOJlQ">ザクっと旨辛！ビールとベストマッチ！これが本場韓国料理！ヤンニョムチキンの作り方</a></li>
</ul>

これがたぶん一番最初に作ったレシピかな？ ビールとって書いてあるけど、無限にごはんもなくなるやつです。
最後の辛味をまぜるところを省けばそのまま子ども用のからあげにもなるので、うま辛いもの食べたいときに良い。
<ul>
<li><a href="https://youtu.be/GNUIVk_2ewA">手を汚さず簡単おしゃれ！みんな大好き！濃厚クリームミートボールの作り方</a></li>
<li><a href="https://youtu.be/vSqMkR9ukyw">3つの素材でボリューム満点！こんがりジューシー焼き焼売（シュウマイ）をつくる方法【革命的な皮の包み方】</a></li>
</ul>

目から鱗の作り方シリーズ、え？そうやってつくる？ってなります。簡単、そしてめちゃ美味い。言うことなし。
<ul>
<li><a href="https://youtu.be/6tJZoQksAIs">おうち韓国料理！短時間で信じられないウマさ！野菜たっぷり！豚バラのクッパの作り方</a></li>
</ul>

いちばん最近おぼえたやつ。うまいし、あたたまるし、子どもにも人気だしで即リピートいり。
そんなこんなで、まだまだ作ってないレシピもあるし、どんどん増えていくし、楽しみがつきない。おすすめです。

コウケンテツのレシピにハマっている

スマホのキャリアを<a href="https://www.reachmobile.com/">Reach Mobile</a>というところのものに変更した。
それまでは、<a href="https://ting.com/">ting</a>を使っていて、料金面ではとてもよかったのだが、いかんせん回線がT-Mobileのものなので、Verizonの回線のMVNOを探してReach Mobileにたどりついた、という感じだ。
というのも自分の住んでいるあたりでは、T-Mobileの電波はよわよわなのである。
純粋なカバーエリア(田舎で入るかどうかみたいな)でも最弱をほこっているが、カバーエリア内でも屋内に入ったりするとぜんぜん通信できなかったり、ということが多々ある。
個人的な感覚では、 Verizon &gt;&gt;&gt; AT&amp;T &gt; T-Mobile という感じなきがする。あくまでこの辺りではね。
(自分の評価したAT&amp;Tは車のネット回線なので純粋なスマホ同士での比較ではないが)
日本にいるときは現在はあまりカバーエリアを気にすることはないようになったかもしれないが、オレゴンはちょっと田舎にいくとすぐに圏外になってしまうので、昔でいうところの田舎ならドコモみたいな感じでVerizonが選ばれている気がする。
そういうわけで、Verizon回線にしたいなぁと思ってVerizonのサイトをみてみると、料金たかすぎ…😱
普通の家のネット回線レベルの値段なのでとても無理。というわけでVerizonのMVNOはないかと探してみると、いちおうあるにはあるが、そんなに安くはない。
Reach Mobileは3GBで月$30という感じ。ほかのところもだいたいおなじような感じだと思う。
その中でReach Mobileを選んだのは単純にWebサイトのクオリティとデザインが一番好みだったから。これは個人的にはカスタマーサポートの質などに直結していると思っているので、重要な指標だと思っている。
実際、最初に届いたSIMカードが初期不良だったのかスマホに認識されなくて早速サポートのお世話になったのだが、対応はかなりよかった。
<div class="image">
 <div>
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/51885877716/in/datetaken/" title="Switched to Reach Mobile"><img src="https://live.staticflickr.com/65535/51885877716_1a248921e0_h.jpg" width="1600" height="1200" alt="Switched to Reach Mobile"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
 <div class="caption">T-Mobile系だとここはちゃんとMVNOの名前になるが、Verizon系はこのままなのかしら？</div>
 </div>
</div>

で、だいたい現在で一ヶ月弱つかっているところだが、いまのところかなり満足している。
まだ田舎にはあまり行っていないのでそのへんはまだ未評価なのだが、いろいろ電波弱くて辛かった屋内スペースがすべてしっかり電波がとどくようになって、とても快適になった。
たとえば、グロッサリーで買うものの相談で奥さんにビデオ通話、みたいなのをたまにやろうとするけど、いつも電波よわくて全然ビデオだと画像が判別できず、結局画像をメッセージでおくる、みたいなことになっててかなりめんどうだった(しかも画像送信にもめっちゃ時間かかる)、のが解決した。
最安でも$30というのはけっこう出費だなーというのはあるが、そこにはいまのところ目をつむろうとおもう。それだけの快適さはある。

スマホのキャリアをReach Mobileに変えてみた

もうだいぶ前の話になってしまうのだが、3月くらいに<a href="https://store.steampowered.com/steamdeck">Steam Deck</a>がセールされていて、もともと興味もあったのでついつい購入してしまった。
Steam Deckの話はまた別に投稿するかもしれないけど、これはめちゃめちゃおすすめなデバイスである。$350の価値はありすぎる。
このSteam DeckにはSteam OSというArch LinuxベースのOSが搭載されていて、このOSには、ゲームモードとデスクトップモードの二種類のモードがある。
通常立ち上がるのはゲームモードで、これはSteamのBig PictureモードのUIがそのままOSになったみたいな感じのものだ。
デスクトップモードは普通のLinuxデスクトップで、デフォルトだとKDE Plasmaの環境が立ち上がる。デスクトップモードはいったんゲームモードで立ち上げたあと、電源メニューからデスクトップに切り替える必要がある。実際このへんは<a href="https://wiki.archlinux.org/title/SDDM">SDDM</a>を使ってやっているっぽく<a class="footref" href="#fn1" id="r1">[1]</a>、好きに変更することも不可能ではなさそうだが、OSアップデートのたびにホームディレクトリ以外の場所は初期化されてしまうようなのであまりそういうことはしないほうがよさそう。
そんな感じでデスクトップモードはいろいろ制約がおおいのだが、<a href="https://www.reddit.com/r/SteamDeck/comments/10toj3c/linux_handheld_desktop_gaming_pc_feat/">Waylandベースのデスクトップ環境をゲームモードで立ち上げる</a>、という猛者がいるのを発見した。
この方法だと、ゲームモードのまま、ゲームを起動する感覚でデスクトップ環境を立ち上げられるのでめちゃくちゃ便利。外部ディスプレイで稼動させるのもいろいろ制約はあるもののちゃんと動く。以下は4Kのモバイルモニタを使っている様子↓
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/52807289765/in/datetaken-public/" title="4K Linux desktop on Steam Deck"><img src="https://live.staticflickr.com/65535/52807289765_9e1c31dd63_b.jpg" width="1024" height="771" alt="4K Linux desktop on Steam Deck"/></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

おなじような方法でXorgベースなWMを起動するのもトライしてみたが、いちおう起動はできたものの解像度の設定がどうやってやるのかわからず…。
ゲームモード上ではX Windowのアプリはgamescopeというアプリにトラップされて全画面表示になってしまうのだが、このように起動したWMもおなじgamescopeの中に入ってしまう。
ちなみにWayland WMの中でも従来のXを使うアプリはgamescopeに囚われてしまうので、基本このゲームモード上のデスクトップ環境では純粋なWaylandアプリのみを使えるということになる。
それでも自分の普段使っているアプリでWaylandに完全に対応していないのはAndroid Studioくらいなので、わりといろんなことができる。

<h3>ゲーム機としては？</h3>
Linuxマシンとしてはかなり遊べるデバイスだが、ゲーム機としてはどうか？ 自分はもともとゲーミングPCを持っているということもあり、最初はまったく期待していなかったのだが、いまではゲーム機としてもかなり気にいっている。
まず、一番おどろいたのは自分のSteamライブラリーのゲームのほとんどが問題なくうごいてしまうところ。モンハンなんてめちゃくちゃサクサクでビックリする。
720pという解像度だからというのもあるだろうが、このパフォーマンスのよさには正直おどろいた。また、画面自体も小さいからか、解像度の低さもあんまり気にならない。むしろどこでも好きなときにPCゲーが遊べる、というのがとてもよい。
あとはコントローラの質がめちゃくちゃ良い。過去に発売されていたSteam Controllerもすごく評判がよかったけど、こういうことかと。若干レイアウトがくるしいところはあるものの、手持ちのコントローラの中では断トツに良いのでSteam Deckの重さなんかを加味してもトータルのプレイ体験が良い。
あと、普通の携帯ゲーム機のような感覚でいつでも電源ボタンをおしてゲームを中断・再開できるのもよい<a class="footref" href="#fn2" id="r2">[2]</a>
そんなわけで、積みゲー消化マシンとしてはとても良く、Life Is Strange2 と Star Wars Fallen Order をたてつづけにクリアした。あ、そうそう、Diablo4 のベータも快適にプレイできましたよ。

<h3>Wayland</h3>
という感じでSteam Deck契機でWayland環境をためすことになったのだが、その後はメインPCのほうでもWaylandを試している。
メインのデスクトップ環境はマルチモニタで、それぞれのスケール設定が異なる。Xorgではそのような設定はできないため解像度が低いほうは無理矢理scaleさせて縮小表示するようになっていて、ただでさえHiDPIとくらべて画質がわるいのにさらに悪くなってしまうのが気になっていた。
Waylandだとそのへんはモニタ毎に自由にscale設定できるし、runtimeでscaleを変えたりもできるし、かつそのへんの動作がかなりサクサクなので、その時点でけっこう惹かれてしまった。
ただ問題は自分が<a href="https://awesomewm.org/">awesomewm</a>ライクなワークスペース操作になれてしまっているので、<a href="https://swaywm.org/">Sway</a>や<a href="https://hyprland.org/">Hyprland</a>にどうしてもなじめなかった。
そんな中発見した<a href="https://github.com/riverwm/river">river</a>というWMがawesomeとおなじtagベースなワークスペース管理があり、設定方法なんかも好みで、最高やん！と思ってしばらく使っていたのだが、どうしても画面共有がうまく動かせないのと、IMEが動かないアプリがあるのが残念で、現時点では常用はむずかしそうということに。惜しい。ただとても気にいっているのでriverは今後もwatchしたい。
いま試しているのは、<a href="https://github.com/typester/hyprtag/">Hyprlandにタグベースのワークスペース機能をあとづけする</a>、というものだ。
最初はネタのつもりでサクっと必要最小限の機能を作ってみたら、一気にHyprlandが便利になってしまい、これは完成すれば普通にHyprlandに移行できるかも？ という感じになってしまったので、それ以降空き時間にちょこちょこ開発している。まだ使えないユースケースがおおいので他の人が使うことは想定していない(のでREADMEも書いていない)段階だが、そのうちちゃんとととのえていきたい。
先週末にマルチモニタにも対応したので自分用としては最小限の機能は一通りおわった感じがある<a class="footref" href="#fn3" id="r3">[3]</a>。あとは、
<ul>
<li>runtimeでのモニタの増減に対応</li>
<li>各種statusを通知するAPI (ステータスバーとかWidget用</li>
<li>条件にマッチしたclientにfocusする機能</li>
</ul>

くらいでとりあえず十分なものになるきがする。
<aside class="footdef">
<a href="#r1">[1]</a> ゲームモードにauotloginする設定があるのは確認した
<a href="#r2">[2]</a> たまにバグるけどw
<a href="#r3">[3]</a> 先週まではawesomeと併用してたけど今週からHyprlandオンリーの生活をおくっています 
</aside>

Steam Deck, Waylandお試し中

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>

2023

2022

2021

2020

2019