ふり返る暇なんて無いね

日々のメモ書きをつらつらと。メインブログに書くほどでもないことを流してます

あとで調べる: Venturaにアップグレード後にxcrunが見つからないと言われる件、ところでxrunってなに

tech

makeとかhomebrewで入れたツール類を実行しようとすると以下のエラーが出るようになった。

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

対処方としてはxcodeのcommand line toolsをインストールすれば良いのですが、

xcode-select --install

ところでxcrunってなんですかね?manを引くとこんな感じ。

複数のxcodeのツールチェーンをサポートするためにMakefileなどを変更せずにも、コマンドラインからデベロッパーツールを呼び出したり見つけたりする機能を提供する。らしい。xcode回りを雰囲気で使ってるのでこの辺よく分からないので、あとで深みにはまりたいところ。

ビルド済みのコマンドとか実行するのに必要そうな感じは受けないのだが、どこでどう使われてるかも調べたいところ。

XCRUN(1)                                                                     BSD General Commands Manual                                                                    XCRUN(1)

NAME
       xcrun - Run or locate development tools and properties.

SYNOPSIS
       xcrun [--sdk <SDK name>] --find <tool name>

       xcrun [--sdk <SDK name>] <tool name> ... tool arguments ...

       <tool name> ... tool arguments ...

DESCRIPTION
       xcrun provides a means to locate or invoke developer tools from the command-line, without requiring users to modify Makefiles or otherwise take inconvenient measures to
       support multiple Xcode tool chains.

       The tool xcode-select(1) is used to set a system default for the active developer directory, and may be overridden by the DEVELOPER_DIR environment variable (see
       ENVIRONMENT).

       The SDK which will be searched defaults to the most recent available SDK, and can be specified by the SDKROOT environment variable or the --sdk option (which takes
       precedences over SDKROOT). When used to invoke another tool (as opposed to simply finding it), xcrun will provide the absolute path to the selected SDK in the SDKROOT
       environment variable. See ENVIRONMENT for more information.

未解決: Cloud Runのオートスケールする条件が分からなかった

tech

Cloud Runのオートスケールする条件がいまいちよく分からなかったので、調べてました。

結論として、ちゃんとした条件が分からなかったので、時間が取れるときにちゃんと実験したいです。

確実なのは公式ドキュメントなので、関係のありそうな歌唱から読んでいきます。

コンテナ インスタンスの自動スケーリングについて  |  Cloud Run のドキュメント  |  Google Cloud

Cloud Run では、リビジョンのスケーリングが自動的に行われます。すべての受信リクエストまたはイベントを処理できるように、必要なコンテナ インスタンスの数が調整されます。リビジョンがトラフィックを受信しない場合、デフォルトでは、コンテナ インスタンスの数がゼロにスケールインされます。このデフォルトは必要に応じて変更できます。インスタンスをアイドル状態のままにすることも、最小インスタンスの設定を使用してウォームアップを指定することもできます。

受信リクエストまたはイベントのレートに加えて、スケジュールされるインスタンスの数は以下の影響を受けます。

ここでは、CPU使用率が60%を維持するようにつまり60%を超えるとスケールするように読み取れます。

インスタンスあたりの最大同時リクエスト数（サービス）  |  Cloud Run のドキュメント  |  Google Cloud

Cloud Run サービスでは、リビジョンのスケーリングが自動的に行われます。すべての受信リクエストを処理できるように、必要なコンテナ インスタンスの数が調整されます。

ここでは、現在稼働してるインスタンスの合計最大同時実行数ではリクエストを処理しきれなくなりそうになるとスケールするように読み取れます。

リソースモデル  |  Cloud Run のドキュメント  |  Google Cloud

リビジョンは、受信したすべてのリクエストを処理できるように、コンテナ インスタンスの数を自動的にスケーリングします。1 つのコンテナ インスタンスが同時に多くのリクエストを受信する場合があります。同時実行の設定を使用すると、1 つのコンテナ インスタンスに同時に送信されるリクエストの最大数を設定できます。

ここも同じこと言ってますね。

まとめると、

  • CPU60%を維持(超えない)ようにスケーリングする
  • すべてのリクエストを処理できるように(同時実行数を超えると)スケーリングする
    • ただし、最大インスタンス数の制限を超えてスケールすることはできない。

ということでいいんですかね?

余談ですが、Cloud Runのオートスケーリングについて調べてたときに見つけたこの動画すごく参考になりました。オートスケーリングに関しては、何も得るものがなかったんですが、ログとリクエストの紐付けとか運用上役に立つ知識が得られました。

www.youtube.com

故障と障害の違いがわからずに困惑してた

tech

ふと調査ごとをしてて故障と障害ってなんか違いあるんだっけ?と疑問に思い調べてました。

JIS X 0014:1999 情報処理用語－信頼性、保守性及び可用性

いったん、JIS X 0014:1999の定義を見てみることにします。

故障は要求された機能の能力がなくなること。できごとを表す感じですかね?

故障
要求された機能を遂行する，機能単位の能力がなくなること。
備考 この定義はJIS Z 8115 : 1981と同一であるが，JIS Z 8115 : 1981には更に幾つかの備考がある。

なるほど。障害は要求された機能が実行できない異常状態らしいです。

障害
要求された機能を遂行する機能単位の能力の，縮退又は喪失を引き起こす，異常な状態。
備考 JIS Z 8115 : 1981では，予防保守又は他の計画的な作業の間に発生する場合，及び外部資源の不足のために発生する場合を除いて，要求された機能を遂行できない状態を“フォールト”と定義している

ちょっとこれだけだとよくわからないので、言及されてるJIS Z 8115を見てみましょう。

JIS Z 8115 : 2000 デイペンダビリティ（信頼性）用語

JIS Z 8115 : 1981が見つからないので今回はJIS Z 8115 : 2000を見ていきます。

これも機能を失うこと。イベントですね。故障はイベント、フォールト(障害)は状態という区別らしいです。そしてそれらを厳密に区別しないこともある。

故障
アイテムが要求機能達成能力を失うこと。

備考1.  一般に，アイテムは故障の後フォールトをもつ。
2.故障は，イベントであり，状態であるフォールトと区別される。
3.ソフトウェアを含むシステムは故障事象をもち，その要因はシステムを構成するハードウェア，ソフトウェア，及び人的要素等の個々の状態又はそれらの組み合わさった複合状態に起因した不具合及び故障によっても発生する。
4.システム故障は系全体の機能の喪失又は規定された機能水準を下回る，系の一時的機能低下，すなわち，系のサービス中断として用いる。
5.ソフトウェア故障という用語は，一般にシステム故障が発生したときの状態において使用される。
6.イベントと状態を厳密に区別しないで故障ということかある。参考  正しい理解と使用のために解説を参照する

障害にあたるフォールトを見てみると。1つ目は機能が実行できない状態。2つ目がちょっとわかりにくいですが、こちらも状態としてとっていいのかな。

フォールト
a)ある要求された機能を遂行不可能なアイテムの状態，また，その状態にあるアイテムの部分。
b)アイテムの要求機能遂行能力を失わせたり，要求機能遂行能力に支障を起こさせる原因（設計の状態）。ただし，予防保全又はその他の計画された活動にる場合，若しくは外部からの供給不良による場合は除く。

備考1.  フォールトはアイテム自体の故障の結果であるが，先行ずる故障がなくても存在することがある。
2.故障発生の過程を原因−結果の連鎖とした場合，故障の原因をフォールトとみなすこともある。フォールトは，着目しているアイテムの下位のアイテムの故障である場合もあるが，アイテム自身に内包されている場合もある。
3.ソフトウェアアイテムの場合，コンピュータシステムではプログラム全体てのプログラミング，論理構成，プログラムプロセス，チータ定義などの間違いを意味する。
4.ソフトウェアフォールトはハードウェアの故障要因と区別するときに使用する場合がある。参考  正しい理解と使用のために解説を参照する

ところで、アイテムとは、

アイテム
ディペンダビリティの対象となる，部品，構成品，デバイス，装置，機能ユニット，機器，サブシステム，システムなどの総称又はいずれか。
備考1.  アイテムは，ハードウェア，ソフトウェア，又は両方から構成される。さらに，特別な場合は，人間も含む。
2.複数のアイテム，例えば，アイテムの母集団及びサンプルは，それ自身アイテムとして考えることができる。
3.ソフトウェアアイテムとして用いる場合は，例えば，ソースコード，オブジェクトコード，ジョブ制御言語．関連文書類又はこれらの集合体を指す（SW1 参照）。
参考  IEC 60050 (191)  の対応英語 entity は除いてある（解説を参照）。

ISTQB 用語集

昔、JATQBの試験を受けたときにこの辺の単語見た気がしたので改めて用語集を見てみます。

ISTQB Glossary failure

日本語だと状態を表してるように読み取れますが、原文だとEventになってます。JISでいうところの故障と同じような概念を指してるように見えます。

故障（failure）
コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと。
An event in which a component or system does not perform a required function within specified limits.

ISTQB Glossary fault

フォールトそのものは載ってないのですが、Synonymとしてdefectがありました。ただ、JISでいうところのフォールトとは違う意味のように取れます。うーむ?

欠陥（defect）
作業成果物に存在する、要件または仕様を満たさない不備または欠点。
Synonyms: バグ（bug）, フォールト（fault）, 問題（problem）
An imperfection or deficiency in a work product where it does not meet its requirements or specifications.

結果

余計困惑しました。

アイテムが故障した結果、フォールト(障害)の状態になるというのが基本的な理解で、ただ、故障とフォールトは厳密に区別せずに使われることもある。そういう理解で良いのでしょうか?

ワクチン4回目打った💉💉💉💉

diary

3回目までは職域接種だったのでモデルナだったのですが、今回は転職して、職域接種なさそうなので、近くのクリニックでファイザーを受けてきました。

オミクロン対応の2価ワクチン(BA.1)ですね。

前回までは、副反応で頭痛と熱が出ててだいぶ辛かったのですが、今回はファイザーなせいか今の所寒気がする程度です。今回鎮痛剤をもらってないので不安だったのですが、この漢字なら耐えられそうです。

11月末ターゲットで2個資格試験受けます

diary

Google Cloud Professional Cloud DeveloperとKubernetes and Cloud Native Associateを11月中に受ける予定です。

KCNAはたぶん大丈夫だと思いつつ、PCDの方は10/28から新しい試験に変わるんですよね。変わってみないと状況がちょっとわからないですが、PCAを受けてみたみた感じの難易度はそこまででもないので、難易度が大幅に変わらない限りは順当に勉強すれば行けそうな気はしてます。

ただ、11月からのお仕事はGoogle CloudもたぶんKubernetesも使わない気がしてるので、その点モチベーション上がりにくいですが、未来への自己投資ということで、がんばりまっする💪

技術書を複数回読むということ

book diary

これは技術書に限らずどの本にも当てはまるのかも知れないです。最近既読の技術書を読み返したときに感じた、複数回読むことの効果に関する気付きです。

次から次に出てくる新しい本や新しい技術に終われて持ってる本を一読するだけでもつらいのに複数回読む時間がなかなか取れないと思いますが、新しい本を読む時間を削ってでも理解を深めるには2周目が大事だと感じました。

1回目読むときにも得るものはあるのですが、自分自身理解力がある人間ではないので、2回目でやっと理解できることが多いなと感じてます。

また、ある程度技術要素を理解した後に読み直すと新しい発見だったり、今まで理解できてなかった概念をひもとけたりと良い効果があります。というか今現在下記の二つの本を読み直してて、特に感じてます。

もののジャンルや難易度にもよって変わるかも知れませんが、概念をつかむために一読、ある程度その分野を触ってから二読目をすると効果が高いんじゃないかなと感じました。

Kubernetes完全ガイド 第2版 impress top gearシリーズ

Kubernetes完全ガイド 第2版 impress top gearシリーズ

Amazon

エンタープライズのためのGoogle Cloud クラウドを活用したシステムの構築と運用

エンタープライズのためのGoogle Cloud クラウドを活用したシステムの構築と運用

Amazon

積ん読に焦らず、自分が身につけたい分野の本はじっくり腰を据えて複数回読むことが大事だなと感じた今日この頃でした。(目の前の大量の未読の本から目をそらしつつ)

まとまってないし、オチも特にないです。

GitHub Actionsで `save-state` と`set-output` が廃止されるようです。

tech

ふとGitHub Actionsを実行ログを眺めてたら、下記のwarningsがでてることに気づきました。

The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

なんだろと思いつつ、示されてた参考リンクを見ると set-output が使えなくなる模様。

10月11日にリリースしたrunner version 2.298.2からこのwarningsがでるようになってて、2023年6月1日からsave-stateまたはset-outputを使うと失敗するようになるので、それ以降使えないとのこと。

それまでに対応する必要がありそう。

リンクの例に書かれてますが、今回使えなくなる set-output と save-state の形式がこれで、

- name: Save state
  run: echo "::save-state name={name}::{value}"

- name: Set output
  run: echo "::set-output name={name}::{value}"

今後は、こっちのように指定のファイルに出力するように対応すれば良い。

- name: Save state
  run: echo "{name}={value}" >> $GITHUB_STATE

- name: Set output
  run: echo "{name}={value}" >> $GITHUB_OUTPUT

しかし、10月11日からwarningsでてたはずなのに気づいてなかった。。。

はてなブログのカテゴリごとのRSSフィード

tech

こんな形式のURLになってます。

https://${domain}/rss/category/${category}
https://${domain}/feed/category/${category}

うちのでいうとこんな感じですね。

このブログわりかし技術系以外の内容が含まれてるので、技術系のカテゴリだけslackに流したいなと思って、特定カテゴリだけのRSSフィードがないか探してました。

これで良い感じにできそう。