VSCode の extension にコマンドを追加する時に使わない方がよい文字のメモ
"category"
に _
(アンダースコア文字) を入れてしまうと、実際に使う時にコマンドの絞り込みが期待動作しなくなって悲しい。
例: category を hoge_fuga
として description を puyopuyo
にすると…:
- CTRL+SHIFT+P して
>hgp
とか>gapu
とか入れてもコマンドが見つからなくなる hoge_fuga
を最初から入れれば出てくるけれど、完全に入力したり、そもそもコマンドで_
を省略せずに打鍵するのは高コストなので不便になる
という知見を得たのでメモを残しました。
category = hoge-fuga
だと >hf
のように -
を省略してもコマンドの絞り込みから外れないので便利を維持できる。
-
のほか、.
/
#
は同様に省略しても絞り込みで外れない区切り記号として使用できる
屋内撮影の照明のON/OFFに手スイッチ操作するよりOK,Googleできたら便利かなーって、スマート電球…ではなくてスマートプラグのやすいの買ってみたのです。のメモ
音声を出すのエネルギー使うにめんどくさいって思っていたのですが、すんごい便利でした…。
もの
買ってみたもの → VStarcam WIFIスマートプラグ スマートコンセント
お値段 = 1,499 円 (執筆時点; keepa価格推移↓)
届いたもの↓
専用アプリ tuya smart life と Google Home
箱や取扱説明書は紙質もよく日本語で表示されていますが、メーカー不明、その他いろいろ不明状態。取扱説明書もけっこーゆるふわ。たぶん技師属性持ちじゃないと扱えないかも。技師属性もちの人はたぶん簡単に扱えます。
懸念点として、専用アプリが .apk ぽん置きページへの誘導になっている事。箱や取扱説明書の QR を読むと Google Play とか Apple のそれじゃない謎のメーカーかどこか(ユーザーには箱や取扱説明書からはわからない…)の .apk ぽん置きウェブサイトへ飛びます。
飛びますのですが、ここでメーカーらしきところが "tuya" っぽい事がわかるので、野良 .apk はいやだーという事で Google Play で検索したらありました🙆♀️
と、いうわけで、
- tuya の smart life アプリを Google Play からインストールし、
- 取扱説明書に従ってスマートプラグの電源ボタンを5秒押し、
- アプリ右上のデバイスを追加するっぽいボタン → Auto Scan
- 設置場所の WiFi ネットワークの AP の接続情報を設定 (こわい<便利)
- スマートプラグに名前を付けて保存
するとアプリで on/off できるようになります。すごいべんり。応答もはやい。(LED電球とか繋ぐ照明も応答がはやい場合)
さらに、 Google の Home アプリをこの状態で起動すると自動的にデバイスを発見して画面の上の方に表示してくれています。表示をぽちって登録すると、
とかで音声操作できるようになります。べんり。 Google Home 経由だと応答はちょっともさる。音声認識からの応答としてはすごいはやいけどね。
ちなみに、スマートプラグに付ける名前を "light" とかにしておくと、 Google Home が照明らしい事を勝手に忖度してくれるようになり、
- 「おーけーぐっぐぅ、あかりつけて」
- 「おーけーぐっぐぅ、でんきつけて」
みたいな呼びかけにも期待動作してくれるようになります。
…すごい便利…。
WSL2 から X410 ( または vcxsrv など ) へ画面を投げる方法のメモ
WSL1 だと 127.0.0.1:0 で Windows ホスト側の X Server へ画面ぽーんできて楽でした。WSL2ではすこし手間がかかるようになりました。
X Client ( on WSL2 ) -> X Server ( X410 )
cat /etc/resolv.conf
で WSL2 (内側)から Windows ホスト(外側) へつながる IP を確認export DISPLAY=172.21.128.1:0
などしてDISPLAY
環境変数を設定- X410 の
Allow Public Access
を有効にする (vcxsrv
なら-ac
引数を有効にする ) konsole
など起動して動作を確認する
自動設定されるように工夫
シェル起動時に実行される適当なところ ( ~/.zshrc
とか) に以下を仕込む:
export DISPLAY="$(awk '/nameserver/ { print $2 }' < /etc/resolv.conf)":0
ちなみに WSL 以外の環境と ~/.zshrc
的なそれを共有したい場合は:
if [[ $(grep -i Microsoft /proc/version) ]]; then export DISPLAY="$(awk '/nameserver/ { print $2 }' < /etc/resolv.conf)":0 else export DISPLAY=127.0.0.1:0 fi
とかしておけば便利です。
参考
vscode: Terminal と Editor のアクティブを行ったり来たりトグルするキーの作り方のメモ
要求
キーは何でもよいのだけど、例えば
F7
を押すと- ターミナルではない何か(エディターやエクスプローラーなど)がアクティブな状態なら → ターミナルをアクティブに
- ターミナルがアクティブな状態なら → エディターをアクティブに
- キーボードのフォーカスのアクティブターゲットがトグル
する便利な状態にしたい需要があったとします。私にはありました😏
実現する方法
Keyboard shortcuts
を次のように2件ユーザー設定でカスタムします:
(1): ターミナルではない何か(エディターやエクスプローラーなど)がアクティブな状態なら → ターミナルをアクティブに
{ "key": "f7", "command": "workbench.action.terminal.focus" }
(2): ターミナルがアクティブな状態なら → エディターをアクティブに
{ "key": "f7", "command": "workbench.action.focusActiveEditorGroup", "when": "terminalFocus" }
Note: VSCode のキーボードショートカットの GUI 編集モードでも右クリックでコンテキストメニューを出せば When
を入力できます。
これで、 F7
を押すとエディター(あるいは他のどこか)にキーボードの入力フォーカスがある状態ならターミナルがアクティブに、ターミナルがアクティブな状態ならエディターがアクティブにトグルしてくれるようになります。けっこー端末でコマンドばばばばばばばばって打ちたい派には、これが理想の便利状態なひとも、いるかもね👩🔧
おまけ: Terminal でのスクロールとキーボードショートカット
VSCodeのTerminalでのスクロールのデフォルトはAltを使うパターンになっていて、ふだん使うことの多い端末エミュレーター等とはキー操作が異なる場合もあると思います。例えば Windows Terminal だと CTRL
+SHIFT
+↑
/↓
なので VSCode でも Terminal を頻繁に使うひとは、ついでに合わせておくと便利かもしれません。
{ "key": "ctrl+shift+down", "command": "workbench.action.terminal.scrollDown", "when": "terminalFocus" }
{ "key": "ctrl+shift+up", "command": "workbench.action.terminal.scrollUp", "when": "terminalFocus" }
眠くても、疲れていても、ひゅーまんがミスしにくい環境がよいです👩🔧
Olympus OM-D E-M1 Mark Ⅲ が Mark Ⅱ からの更新ユーザーとしては悲しすぎたので書き留めておくメモ。 Mark Ⅳ があってももう事前情報を好意的には見てはあげません。
OLYMPUS OM-D E-M1 Mark Ⅲ が初めてのフラッグシップモデル級のカメラ購入で、 OLYMPUS のサンプルを他社と比較して SPEC を確認した上で購入するなら…悪い製品ではありません。ただ、MarkⅡの時と違い、2020年現在では基本性能を上げてきた他社に対してセンサー、基本の解像度、動画性能などで足踏み状態なので良い選択肢としてオススメできるかは…やや人を選ぶ要求次第かもしれません。防塵防滴、7.5段手ブレ補正、TruePicⅨの基本性能と画像として取り出せる絵のピクセルレベルでの解像感の良さ、MFTでレンズ含めの携行性が非常に良くM.ZUIKOレンズも良い…そういった基本的な部分で選択するのは良いと思います。
これから書くこの記事の本体の悲しみのメモはその上で、特に Mark Ⅱ から Mark Ⅲ へメーカーの事前情報を好意的に信じ期待して高いお金を払って更新したユーザーの悲しみどころのメモです。もちろん、事前情報の確認が足りないだけと言ってしまえばそういう部分もありますが、2020年のフラッグシップモデルですしね…、カメラ本体の公式サイトに書いてある事は好意的に読んで期待したいじゃないですか…特に本体性能の数値的にはまるで進化がなかったので、それ以外での進化はけっこう頑張っているはずだ…って。
1. WiFi アクセスポイント経由で Olympus Capture と接続できるよ!
但し、 「接続中に本体を操作して撮影すると画像がPCへ自動コピーされる別モードでの接続ができるだけ」でした。Olympus Captureはリモートコントロールソフトです。接続できるって書いてあったらリモートコントロールできると思うじゃないですか…。できません。
プレビューしても遅延が数百ミリ秒発生してしまう、とかあるんでしょーけど、ユーザー的には遅延1秒でもコントロールさせて欲しいです。フォーカスとシャッターの制御しかできなくてもさせて欲しいです。本体でシャッター押した画像が転送されてくるだけとか完全にただのおまけ機能じゃないですか…。WiFi接続では画像転送しかできないのに、USB接続と同じような扱いに見える具合で対応しましたって言っちゃってるの、ダメだと思います。
小さく注意書きはあったのかな…。Captureの機能からは別モードというかおまけ程度の機能過ぎると思うのです。ゆえに、それにユーザーが期待してしまわない程度にはきちんと表示しておいてほしかったです。
Ⅲへの更新の期待の1/3はここでした。WiFiではCaptureからコントロールできないって、がっかりでした。
…そもそも O.I. Share ではアドホックモードのみで簡易的であれカメラコントロールできてるじゃないですか…。アクセスポイント経由の遅延に何か拘りがあるのかわかりませんが、ユーザーが本当にほしかったものを考えろです。
2. Bluetooth でスマフォと接続できるよ!
但し、「WiFiで接続可能な場合は従来どおりスマフォアプリが全自動で現在のWiFiを切断してアドホックにカメラのWiFiと接続するけどね!」でした。事実上 O.I. Share に Mark Ⅱ までのユーザーが期待した Mark Ⅲ でのBluetooth接続はできません。ⅢのWiFi/Bluetooth接続をONにすると、 O.I. Share は常に WiFi のアドホック接続を試みてしまうので WiFi 切り替えが従来通り発生してやぼったい、うざったいです。
では、 Bluetooth はいつどこで接続できるのかと言うと、カメラの電源をOFFにした時にバックグラウンド接続という形で使用できる、という事のようです。カメラを電源OFFにした状態でも Bluetooth の設定が済んでいれば O.I. Share からカメラの電源はOFF(という体裁でBTと一部の機能がバッテリーを消費して動作するモードでONになっている)のまま、写真の取り込みをできます。カメラの電源はOFFという体裁の接続モードなのでカメラの撮影関連のコントロールはできませんん。
カメラの電源をONにしている状態で再生モードでRECボタンでチェックを付け、OKボタンを押してメニューからシェア予約しておくと、電源OFFになった後、スマフォの O.I. Share が Bluetooth でこっそり接続し、シェア予約された画像をスマフォ側へ自動的に取り込んでくれる、という機能が主体のようです。実際これは便利なので、期待した動作とは異なりますが、若干救われたお気持ちです。
電源ON時もBluetoothだけで接続して欲しい…。PCのCaptureともBluetooth接続できて欲しい…。ユーザーが本当にほしかったものをよく考えてほしい。
3. USB PD で給電できるよ!
但し、「USBケーブルをつないだだけでは自動的に給電開始されずUSBの動作モード選択をぽちぽちしてPDを選ばないとならないし、そもそもPD対応ではない給電元からは給電一切受けないけどね!」という仕様みたい。
先ずね、USBケーブルが挿されたら、PDでも非PDでもプロファイルに応じた給電を受けなさいよ…と。PDもわざわざケーブルを挿した後で「どのモードにする?」とかメニューをぽちぽちユーザーに操作させずに自動的に給電受けて下さいよ…。めんどくさいよ…。そもそも、挿したUSB元がPDではなくても可能な電力量の給電をしきい値を設けるであれ受けて欲しー。悲しい。
ちなみにPD対応ではないが給電能力は十分なUSB元に接続してメニューぽちぽちでPDを選ぶと「しばらくお待ちください」表示になり固まります。(USBケーブルを抜けば復帰します)
ユーザーが本当にほしかったものを考えてほしい。ただでさえ数値的には本体性能上がらず Mark Ⅲ への更新には否定的なレビューも多かった今回の新型です。せめて数値的にあがっていない部分の4年分の更新を、できれば「これができるようになったよ!」と言うのなら、それを言われたユーザーが期待するであろう、対応の文言に釣られたユーザーが本当に期待したものを実現して欲しい。
4. 手持ちハイレゾ50MP!
(ご注意 この項は初稿では↑までのⅡ→Ⅲユーザーの期待感による優良誤認の悲しみから「手持ちハイレゾ50MP役に立たない」と勢いよく言い切ってしまいましたが、夜の屋内の白熱電球照明での試写で撮影条件としてはやや厳し目だった事もあり、後日、改めて楽しめないか試写&画像比較付きで追加メモを書こうと思います。)
いちおう撮影はできます。できますが、手持ちハイレゾは役に立ちませんでした。
両肘をテーブルに置いて軽く固定を意識した状態で手持ちハイレゾ撮影しても、ふつーに非ハイレゾで撮影した方がブレないだけ綺麗です。手持ちハイレゾでもよくブレを押さえて超解像してくれていると、技術的にはとても関心できる絵ができあがります。しかし、そもそもハイレゾにせず1枚だけ撮影した方が綺麗に撮れます。手持ちハイレゾの意味なし。
もちろんピクセルレベルに近い確認をすれば、という程度ですし、三脚モードにして静的な絵なら80MPで撮影できる点ではとても嬉しいハイテック機能ではあるのですが、手持ちハイレゾは実用性の無い釣り針だった事には代わりありません。
ちなみに三脚ハイレゾモードにしつつ手持ちで80MP撮影しても、手持ちハイレゾモードにしつつ50MP撮影しても、非ハイレゾシングルフレームの15.9MP撮影と比べると大差ないブレ度の絵が撮れます。そういうわけで、すごいのだけど、手持ちハイレゾが無意味だった事には代わりありません。
…ムキムキマッチョ筋肉人間三脚ゴッドハンド&ボディーをお持ちのよく訓練されたスーパープロフェッショナルカメラパーソンならあるいは…。まあ、素直に三脚ハイレゾしましょうという事ですね。
その他
ジョイスティックが増えた事について
付いている意味がほとんど無い気がする程度の機能性でした。十字より斜めを入力しやすいとは言え、器用にカーソリングするには小さすぎ&硬すぎです。そもそもタッチスクリーンもあるので器用にフォーカス位置を替えたりしたいユーザーはジョイスティックよりタッチスクリーン使えばいいですね。基本的にジョイスティックと十字の操作は同じ処理が割り当てられている事もあり、なおのこと要らないですね。
代わりにタクタイルスイッチを1つ増やしてくれた方がよっっっっっっぽど嬉しかった程度の謎の何かであったことがわかりました。一応PSやXBOXのゲームパッドのアナログスティックのように押し込みボタンとしても使えるのですが、方向入力に化け易く、素直にタクタイルスイッチを1つ付けてくれた方が嬉しいです。
MENUが左上へ行った事について
キャンセルボタンを兼ねているので、OK/CANCELを右手だけで操作できなくなりました。地味に不便。INFOが右下になった事はこれは便利なので、やっぱりジョイスティック要らないのでは感がマシマシに…。
褒めるところはないのですか?
あります。たいていは Mark Ⅱと変わっていないか、本質的には大差ない部分は良いカメラです。冒頭に書いた防塵防滴などなど。
ただ、数値で比較する基本性能が X-T4 はじめ圧倒的に負けてしまっていて、センサーサイズもMFTのデメリット(メリットも大きいけれど)を抱えつつお値段はそれら競合と大差ない、それでⅡからⅢへの変更点がほとんど実質的に微妙な程度だったのですから、信じてⅡからⅢへの更新を予約購入で行ったファンとしては悲しみです。
TruePicⅧからⅨへの更新は気持ち動作のキビキビ感は向上したような気もしますが、実感としては気の所為程度です。メニューが少しだけわかりやすく工夫されたとか地味な更新もありますが、Ⅱでもファームウェア更新で追従できた程度の事のような部分もあります。
少なくとも予約購入した事は過ちでした。もっとよく確認していればⅡからⅢへの更新はしなかったか、X-T4を買っていたかもしれませんし、Nikonへ帰っていたかもしれません。せめて、発売前情報で期待した「あれができる」「これができる」との釣り針を見たユーザーが想像した本当にほしかった機能を着実に実装してくれていたら、数値的な基本性能は変わらなくともⅢにしてよかった!ってついーと&メモを残していたと、思うのですけどね…。
なんだか、悲しい。
まあ…基本性能は…気に入っているからこれを使う事に悲しみを懐き続けるとか、X-T4にしておけばよかったと未練を何年も引きずって生きる事になる、という事はないのですが、予約購入したOM-D E-M1シリーズのファンとしては、更新にかけた期待を裏切られた悲しみはメモを残す程度にはありました。ダメですね、ファンというか、信者になってしまっては。次からはNikonからOlympusへ主力カメラを替えた時のように、しっかり吟味して更新していきたいと思います。
OpenSCAD でアニメーションを作成 -> 連番PNG -> ffmpeg で apng/mp4(h.264) にする方法のメモ
1. OpenSCAD でアニメーションを作る
use <../../../utility/color/HSL.scad> $fn = 6; for ( L = [ 0 : 1 / 6: 1 ] ) for ( S = [ 0 : 1 / 5: 1 ] ) for ( H = [ 0 : 30 : S > 0 ? 360 - 1 : 0 ] ) translate( [ S * cos( H ), S * sin( H ), L - 0.5 ] ) color( to_RGB_from_HSL( [ H, S, L ] ) ) rotate( [ $t * 720, 0, $t * 360 ] ) // 👈 ここの $t スペシャル変数がアニメーション用 scale( 1 - S ) cylinder( d = 0.1, h = 0.075, center = true );
ふつーに .scad を書いて、アニメーションを $t
(sec) で導入するだけでした。かんたん。
2. OpenSCAD でアニメーションをプレビュー&連番PNG出力する
OpenSCAD でアニメーションをプレビューしたい場合は:
- ↑ View -> Animate を on 状態にする
- ↑ プレビューとコンソールの間にアニメーション設定が出現するので
FPS
とSteps
を設定 (Time
はFPS
とSteps
を設定すると自動的に回りはじめます。この値がソースの$t
へ入りアニメーションします)
この状態で Export / PNG すると連番PNGが出てきそうな予感がしますが、 Export / PNG しても Export / PNG した瞬間の $t
の1枚だけが出力されます。そうじゃない動作になります。
- ↑
Dump Pictures
を on にします
Dump Pictures
を on にするとプレビューのアニメーションのフレームが描画されると同時に frame00000.png
, frame00001.png
, ... の連番PNGがしれっと .scad と同じディレクトリーへ出力され始めます。 OpenSCAD に設定した FPS
と Steps
を構成するすべての Time
の .png の出力が終わると Dump Pictures
のチェックが自動的に外れます。
3. 連番 PNG を ffmpeg で apng / mp4 へ変換する
ffmepg の他にも手段はたくさんあります。ウェブアプリで連番画像から apng を作れる EZGIF.COM/APNG maker もあります。しかし、 OpenSCAD を実用できる状態でおそらく手元にあるであろう PC に比べると手間と時間がかかります。Windows用のアプリとかいろいろあるみたいですが、今回のメモの作成では汎用性と可搬性がとても高い ffmpeg を WSL の Arch 環境から使いました。
# frame00000.png, frame00001.png, ... から apng ( animation png ) を ffmpeg で作成 ffmpeg -framerate 24 -i frame%05d.png -r 60 -plays 0 out.apng
# frame00000.png, frame00001.png, ... から mp4 ( h.264 ) を ffmpeg で作成 ffmpeg -framerate 24 -i frame%05d.png -r 60 -pix_fmt yuv420p -vcodec h264 -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" out.mp4
連番 .png --/ffmpeg/--> .apng --/ffmpeg/--> .mp4 ( h.264 ) も可能。(今回はわざわざそのルートで逐次変換する必要はないので .apng も .mp4 も直接生成)
ちなみに、 Twitter も Facebook も apng は投稿してもアニメーション削除されます。悲しい。😥
Imgur だと apng 期待動作のまま置いて貰えます。嬉しい。😃
↑ imgur に置いた画像を markdown で直接参照しています。
はてなブログ(はてなフォトライフ)は Twitter, Facebook と同様でアニメーション勝手に削除されます。悲しい😥
参考
Azure DevOps ちほーの git サーバーへ git@ssh しようとしたら Unable to negotiate で diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 を提案されたら思い出すメモ
状況
git clone git@ssh.dev.azure.com:v3/my_team/my_project/my_repos Cloning into 'my_repos'... Unable to negotiate with 40.81.25.218 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
エラーメッセージ訳:
40.81.25.218:22 との交渉はダメでした。鍵交換方式が合いません。
diffie-hellman-group1-sha1
,diffie-hellman-group14-sha1
とか試してみたらいいかもね。
解決方法
~/.ssh/config
にそういう事を言う git サーバー用の接続設定を特殊化します。今回の例だと ssh.dev.azure.com
に対して特殊化します:
Host ssh.dev.azure.com User git Port 22 HostName ssh.dev.azure.com IdentityFile ~/.ssh/id_rsa TCPKeepAlive yes IdentitiesOnly yes KexAlgorithms +diffie-hellman-group1-sha1
ついで設定もありますが、今回の解決方法の要は KexAlgorithms
を Host
/HostName
に対して設定している部分です。 "Kex" は "Key-eXchanging" とかそんなノリでしょうね。😅
ちなみに、 Azure DevOps の場合は残念ながらいまだに ECDSA とか使えず RSA 鍵を使わなければならないので IdentityFile
の特殊化も事実上必須です。かなしい。