do_su_0805's blog

dairyquestions は typo です。

M1 Mac と Type-C モニター(USB-A ハブ付き) の相性

MBP2021 (M1/13inch) と HP U28 4K における話。

 

U28 4K の USB ハブに HHKB Pro2 Type-S と Scarlett Solo Gen.3 (オーディオインターフェース) を挿して、 USB Type-C ケーブルで MBP と繋いでる。

 

なんとなくわかってきた相性として、「起動時にType-C 挿しっぱなし」だとほぼほぼ USBインターフェースが認識しない(ディスプレイとしては認識する)。そのタイミング〜ログイン画面では USB ハブ側のケーブルも、Type-C ケーブルも抜き差ししたところでなかなか認識されない。たまに認識されるがなぜかはわからない。

 

が、一度ログインしてデスクトップまで行ってから Type-C ケーブルを抜き差しすると(記憶が確かなら)100%認識する。

 

不思議。一瞬オーディオインターフェースの起電力的なあれか?とか思ったけど、別に HHKB だけ挿してもさほど症状は変わらなかった。

「頭が冴える! 毎日が充実する! スゴい早起き」を読んだ

注意

感想記事を書くにあたって、「ブログや scrapbox といった公共発信においてどこまで内容などに触れて良いか」を軽く調査しました。
結果として、「引用や翻案権に注意する」「表紙の写真は貼らない」などのポイントが見えてきたのでそれを実践しつつ記載して見ます。
何か問題などありましたら do_su_0805 (@do_su_0805) | Twitter までよろしくお願いいたします。
慣れてきたりもう少しまとまってきたらそちらもブログに書けたらと思います。

読んだ本

https://www.amazon.co.jp/dp/B07KWLFXX1/

ISBN-10 ‏ : 4799107771 ISBN-13 ‏ : 978-4799107775

感想

はじめに、僕は結構この手の本を読むのを諦めることが多い。
理由としては、ライフスタイルなどに関する本において、大体筆者の行動のきっかけに共感ができなかったり、差し込みにイラッとすることが多いからである。 *1

今回もそうかなぁ... とビクビクしながら読んでみたところ、そこまでのものはなく「そういうことがしたかったんだね」くらいに思える程度での紹介などで読みやすかったというのが助かった。*2.

タイトルの通り、「早起きをして活動を行うとどういうメリットがあるか」という話ではあるんだが、筆者の体験や経験、理論に基づいて「別の誰か」に実践したもらった時のストーリーや結果があるのがパターン評価できてよかった。
結構「とにかく早起きはすごいんだ!」みたいな論調になる本を見かけるけど、この本だと「この人はこういう目標がある中こういうことに困っていた。そこで早起きをして活動時間を確保したところ、こういうメリットを享受できて、結果目標を達成できた(ないしはできそうである)」という流れでの紹介が何パターンもあり、自分の場合どういう実践が取れるかという参考になるのがとてもよかった。

また、心理学的なメソッドやパターンを紹介しつつ、それに当てはめた説明がなされることも納得感がありよかった。根性論みたいな話題でもないので心穏やかな気持ちで読み進めることができた。

少し引いた視点で読んでみると、「早起きをするという『活動』を継続するためのメソッド」をさまざまに説明してくれている本でもあるので、任意の活動に置き換えた時のアプローチパターンという読み方もできるな、と終盤気づいてこれは新鮮な気持ちになった。
( ただし、具体的なメソッドを省いて要約するとつまりは PDCA なんだな、ということもなんとなくわかり、PDCA!PDCA! と叫ぶだけではなくて、それが自然と遂行されるような具体的なメソッドまで落とし込んで説明・理解することが大事なんだな、ということにも気づいて面白かった )

終わりに

  • 結局具体的なメソッドをメモるには private scrapbox しかないのかもう... ってなった
  • Kindle でマンガ以外読むのが大の苦手なのでその訓練も兼ねて読んだんだけど、意外と読めたことに驚きつつ、この本が「位置」表記なのでページがわからなくて困った。こういうもんなのだろうか。

*1: 僕は早とちりかつ若干価値観が変なので、要は手段をくれ!って気持ちになったり、そんな崇高な気持ちはないんじゃ... とへこたれてしまうことが多い

*2:僕の耐性がついただけかはわからない

今日遭遇した ShellCheck

久々に shellscript 書いていたら二つほど koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts に注意されたのでメモ

SC2003 expr is antiquated. Consider rewriting this using $((..)), ${} or [[ ]].

SC2003 · koalaman/shellcheck Wiki

shellscript の中で expr を使ったところ食らった。シェルコマンドに組み込まれている奴らを使いなさいな、とのこと。
自然と expr ${i} + 1 書きがちだし気をつけようと思った

SC2012 Use find instead of ls to better handle non-alphanumeric filenames.

SC2012 · koalaman/shellcheck Wiki

とあるフォルダ配下に、実行後のログファイルを連番でおいていこうとした時に、ついこう書いてしまった。

count=$(ls ${dir} | wc -l)
if [ "${count}" == "" ]; then 
  ${count}=0
fi
filenum=$(expr ${count} + 1)

これも (*.gz) とか知らなかったし、さっきの SC2003 にもあった #var とかも全然使ってないのでふむふむといいながらやっていた。
今回の場合は、count=$(find ${dir} -maxdepth 1 -type f -name "*.csv.gz" | wc -l) にした。一応いいところ取りのつもりではある。

余談

  • alphanumeric : 英数字 はえ〜ってなった。

おまけ : VSCode で ShellCheck

timonwong/vscode-shellcheck: An extension to use shellcheck linter in vscode があるので是非使いましょう。便利

何に使っているかわからない github repository の webhook の正体を探る ( AWS CodeBuild / AWS CodePipeline 編)

題目の通りですが、なんか気づいたらリポジトリに webhook が設定されていたけど、「これなんの webhook だ?」ってなることありませんか?私はあります。

今回は、AWS CodeBuild / AWS CodePipeline 向けの Webhook が「どのプロジェクト」であったり「どのパイプライン」に紐づくものなのかという話です。

AWS CodePipeline 編

CodePipeline が生成する webhook については、aws codepipeline list-webhooks というずばりなコマンドが aws-cli にありますので活用しましょう。 ドキュメントはこちら list-webhooks — AWS CLI 2.1.33 Command Reference

後述の CodeBuild とは違い、CodePipeline 側の設定から github 側の hook 設定画面に飛べるわけではないですが、おそらくご期待の調査は可能かなと思います。

注意点としては、SecretToken など普通に出てくるので実行環境などには注意しましょう。

CodePipeline については、コンソールから調べる方法はわかりませんでした。何かあったら教えてください。

AWS CodeBuild 編

CodeBuild が生成する Webhook については、上手い感じに探せる方法はとりあえずは見つからなく、コンソールからプロジェクトの「ビルドの詳細」画面でちまちまみていくのが良さそうです。画像のような画面の「プライマリソースのウェブフックイベント」にある「ウェブフック」にあるリンクから github repository 側の hook 設定画面にいけますので、それで対応を取ってください。

(逆にいうと、当該リポジトリに対する webhook がなかったらアカウントが違うかそれとも放置されたかって感じです。最低限プロジェクトなかったら webhook 自体がエラーになって github 側からわかると思うのでその辺りはよしなに...)

f:id:do_su_0805:20210331211547p:plain
CodeBuild の設定画面

2021/03/31現在、aws-cli/2.1.32 の時点で aws-cli には webhook 関係が create/update/delete しかなく、webhook 中心の調査ができなさそうです。また、コンソールから開いても同様です。頑張ってください。*1

ドキュメントはこちらです。 codebuild — AWS CLI 2.1.33 Command Reference

*1: 私はがんばりました

aws-cdk の最新版に member の typo を見つけたので報告した

(ec2): typo variable name "clientVpnEndoint" · Issue #13810 · aws/aws-cdk の話。 最近やっと少しずつ OSS に issue を立てられるようになってきたのと、今回の体験がなんかよかったので記録がてら。

( 一応書きますが typo を責めているわけではないです。)

報告

aws-cdk は、リリースされたら changelog は眺めてるんだけど、ちょうど最近「まだ Low Level Construct か〜」となった ClinetVPN 周りが 1.95.0 で現れた

おーって思いながら読んでたんだけど、ふと member に clientVpnEndoint っていう typo がいるのに気づいた。 *1

member の typo はこの PR の中でもわかるように、補完によってすぐに広がってしまってあとで困るなぁと思い、「とにかく伝えなきゃ!」ってなって調べつつ報告してみた。

aws-cdk/CONTRIBUTING.md at master · aws/aws-cdk を読んだところ、「PR だすなら issue 番号と紐づけてね」ってあったので、まず issue 作るか〜ってなってとりあえず急いで作ったので上記 issue でした。

返信

先ほど返信があったんだけど、とてもわかりやすい返信ですげーってなった。

  • 見つけてくれてありがとな
  • こういうの直す時は「正しい名前の member を用意する」「 typo した ( typo'ed ) member に @deprecated をつけてあげることだぜ」*2
  • PR 用意してもいいかい? ( おそらく 「PR を用意し始めていないか?」とか、「せっかくだしやってみないか?」というニュアンスを含んでいると思う )

なるべくシュッと直せる人がシュッと直してもらった方がいいだろうなぁとか、今はちょっといろいろドタバタしてたので、「今回は用意してないんだ、ごめんね。また今度、good first issue に挑戦してみるよ。ありがとう!」って返信した。


できる人にはできる簡単なことと思うんですけど、結構ハードル高いなーというのが最近小さくできつつあるので、こういうの見て少しでも増えるといいかな、って書いてみた。

OSSへの貢献をさらに良い形にしたい | はてなで働く itchyny にアンケート [#13] - Hatena Developer Blog みたいな動きもあって、こういうチャンスに :oss-chance: が押されて集まったり、やってみたい時に相談できる環境があるってのもやる気になれた要因なのかな、とは思っている。*3

社内のSlackには #oss-guild というチャンネルがあって、OSSが好きなメンバーが集っています。:oss-chance:() という絵文字もあって、Slackでの発言にこのemojiでリアクションすることにより #oss-guild に通知が流れます。このように間口を広げることで、OSSに貢献したいけど踏み出せない人を応援しています。

OSSへの貢献をさらに良い形にしたい | はてなで働く itchyny にアンケート [#13] - Hatena Developer Blog

今後も続けていきたいし、当たり前のように issue / PR を作っていきたいですね

2021/04/01 追記

id:puhitaku から、以下のようにコメントをもらった

Mind submitting a PR for that? は多分 Would you mind ~ ? の砕けた言い方で、PR 提出してくれませんか?て意味だと思う。だから普通に PR 出しちゃっていいんじゃないかな
この good first issue は初回 issue を歓迎するよていう優しい意思表示で、ナチュラルな発想としては Issue の Author が直すってなる → そしてこのお兄さんは具体的なプランを提示したので、それで PR 作ってくれない?ってなってる → ボールがこっちに来て止まってる

色々と相談に乗ってもらって、僕が勘違いしているから明示的に「今はできない」と返答しないとということになり、再度返信をした。

僕には「問題とわかっていてもできないのであれば閉じる」とか、「issue の Author が直すってなる」みたいな感覚が一切なかったし、good first issue を「コントリビュート初心者向け issue だよ。(コントリビュートしてみたい人やってみて)」みたいに恣意的に勘違いしていたのでなるほどまだまだ全然わかってないな、となった。

その後このようにもコメントをいただいた

あとこういう issue を維持するか閉じるかはわからないので一旦聞いてみたら良いのではという感じで、対応できないから即閉じてもらうのが OSS 一般としていいってわけではないので注意

*1:最初 variable って表現したんだけど、同僚に「variableよりは property か member の方が typescript っぽいかも。」といただいたので修正した

*2: この表現好き

*3: 今回はなんだかんだでチームメンバーがみてくれた

様々な wifi 接続設定共有の仕組みが便利だった

ルータを置き換えた時に様々な機器の設定を切り替えて行ったんだけど、様々な仕組みのおかげで昔みたいに全部入力せずに済んで便利だった

QR コード読み込み

これは結構最近だと知られてきているけど、wifi の接続設定は QR コードで共有することができる。
生成方法は調べるといくらか出てくるが、どれが信頼できるかなどはちょっとわからなかったのでここでは触れないこととする。

Android ( Pixel 3 / Android 11 で確認 ) では、「ネットワークとインターネット」から「Wi-Fi」に行った後、「ネットワークを追加」の右にある QR コードマークを押した先で QR コードを読み込むと接続できる。

iPhone ( iPhone SE2 / iOS 14.4 および iPad mini 4 / iOS 14.4 で確認 ) では、カメラアプリを起動して QR コードに向けると接続用のポップアップが表示される。

なお、LINE の QR コードリーダーだとうまくいかなかった。 ( Android / iPad にて確認)

同じユーザで認証している MacBook / iPhone など

iPhone、iPad、iPod touch で Wi-Fi のパスワードを共有する方法 - Apple サポート

同じ Apple ID でログインしている端末のうち、他の端末で当該 SSID に接続しようとすると、接続済みな端末側で共有を許可するかどうかのポップアップが出てくるので、共有すると勝手に接続されるようになる。

余談

今回勢いよく記号ありパスワードを生成したんですが、どうも Nintendo Switch だけつながらなくて困った。入力しているから失敗しているのか、記号で認められないものがあるのかよくわかっていない...

macOS VSCode Terminal .bashrc 読まれない

2020/12/21 20:36 追記

  • 同僚から、以下コメントをいただきました。

    Terminall.app だったら 一般 -> 開くシェル で コマンド (完全パス) で -i を渡せばいいんじゃないか
    iTerm2 は Profile の General タブの Command で渡すことができそうね

2020/12/21 20:21 追記

対応

  • 以下を .bash_profile に記載する。(やり方はまかせますが要はこうしてください)
### for interactive only shell
shopt -q login_shell

if [[ $? -eq 0 ]]; then
  source ~/.bashrc
fi

なぜ

  • ターミナルの起動には「インタラクティブシェル」「ログインシェル」がある
  • (詳しく調べてないが) terminal.app や iTerm2 起動時は「インタラクティブシェル」になる
  • VSCodeTerminal › External: Osx Exec 設定では Terminal.app が読まれるようになっている

何をしたの

  • ログインシェルかどうかを shopt -q login_shell で判別して、ログインシェルではなかったら .bashrc も読むようにした
    • これにより terminal.app や iTerm2 や VSCode が起動する Terminal でも .bashrc が読まれるようになった

試してない・調べてないもの

参考文献