do_su_0805's blog

dairyquestions は typo です。

今日遭遇した 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 が読まれるようになった

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

参考文献

ファイル名が意図しないものがあったら異常終了させるワンライナー、およびそれを GitHubActions で動かすまで

TL;DR

  • find は対象が見つかろうが見つからなかろうが exit 0 する
  • find を異常終了させるには -exec false {} + が楽そう
  • せっかくなので GithubActions で動かしてみたよ

ことのあらまし

  • 特定の拡張子のファイルを見て処理を行う仕組みがあった。
  • ある時、ファイルをアップロードして処理されないと言う事件が起きた。
    • 原因が拡張子の誤りだったんだけど、一文字間違いくらいでなかなか気づけなかった。
  • これは人間が確認すべきじゃないので CI に載せたくて、とりあえず「特定の拡張子でないファイルが現れたら異常終了する」術がないかなぁと調べ始めた

「特定の拡張子でないファイルが現れたら異常終了する」術

例として、 .json 以外出て来れられたらおかしい世界を考える

  • ぱっと思いついたのは find . | grep -v "\.json$" みたいな話
    • だけど grep は「条件に引っ掛かったら exit 0」という世界なので、日頃問題ない世界では exit 1 される
    • いろいろパイプなり、いっそスクリプトにするなどしたら使えるけど今回はもうちょっと気楽にやりたかった
  • 次に思いついたのは 「 find 自体でどうにかできないか? 」だった
    • 試してみたところ、どうやら「コマンドオプション自体がエラーじゃないととにかく正常終了する」世界
      • そりゃそうだ、一覧を出すだけだからね
  • 試しに 「find returncode」 とかで調べたところ、こんな記事が引っ掛かった
  • ちょうど同じニーズっぽい。中段くらいにある false を使う例がスッキリしていたので試したみたところ、ちゃんと「 json しかない時は正常終了し、json 以外がある時は異常終了する」世界ができた。
    • find -not -name "*.json" -exec "false {} +"
  • とはいえ、CI で実行時に失敗だけ言われても辛いので、見つけたファイルも出すようにした。
    • find -not -name "*.json" -exec "false {} +" -print

術が生まれたので GithubActions で自動検知させてみた

do-su-0805/Unintentional_filename_detection_example に例をおいてみました。

やっていることはこんな感じ。先ほど生み出した術を走らせる最小構成です。jsondir というディレクトリに *.json 以外が紛れ込んだら落ちる CI が完成です。

on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
jobs:
  detector:
    name: Detect unintentional file ( not "*.json" )
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: exec detection
      working-directory: jsondir
      run: find . -type f -not -name "*.json" -exec false {} + -print

実際に動いている例としては unintentional file exemple by do-su-0805 · Pull Request #1 · do-su-0805/Unintentional_filename_detection_example に用意しました。json フォルダに yaml をおいてしまったという世界です。

f:id:do_su_0805:20200703204150p:plain
検知例。ちゃんと test.yaml を検知してエラー落ちしていますね。

こういう細かいところを機械がみてくれるのは心地よいですね。

hangout meets の MacOS におけるロック状態での挙動

まとめ

  • 画面配信 + ビデオ配信中に、 Mac をロック状態にすると、
    • 画面配信は切れる。復帰後も配信は中止されている。
    • ビデオ配信は継続される。復帰後もそのまま

試した環境

やったこと

  • hangout meets に JOIN
  • 画面配信とビデオ配信をしたまま、「画面をロック」を実施
    • 左上のりんごマークから行けるやつ。タッチバーの鍵っぽいあいこんのあれ
  • その後、別端末から当該 meets に JOIN して状況を確認した。

確認できたこと

  • 文頭「まとめ」通り