ナンモワカランアザラシ

技術的なアレコレを自分の言葉で書いて保管・公開しておくための静かなインターネット

PGPとかGPGとかって何だ

PGPは、Pretty Good Privacyの略で、暗号化に使われるプログラムである。
https://en.wikipedia.org/wiki/Pretty_Good_Privacy

GPGは、GnuPGの略で、Gnuプロジェクトで作られた暗号化プログラムである。GPGはOpenPGPという規格に沿っているらしい。
https://gnupg.org/software/index.html

OpenPGPとは、RFC4880として標準化された規格である。PGPから生まれた規格ではあるが、名前の権利関係からPGPとOpenPGPとは分けているらしい。
https://www.ietf.org/rfc/rfc4880.txt

GNUプロジェクトは、自由を標榜しているソフトウェアコミュニティだ。Gnu's Not Unix!のアクロニムだそうだ。
https://www.gnu.org/gnu/thegnuproject.html.en

個人開発者がPGPというプログラムを作り、PGPを基にOpenPGPという規格が作られ、GNUというコミュニティの人たちがGnuPGPとしてGPGを作った、という流れだ。

蓋を開けてみたらソフトウェア界隈でよくあるやつだった。ソフトウェアコミュニティ、すぐOpenとかつけたがりがち。

きちんとした日本語文章を書くときに気を付けていること

仕事で、他の人が書いた日本語文章をレビューをする機会がある。 複数の人に同じようなレビューコメントを書いているので、私が普段気にしていることをまとめてみる。

総合すると、「読み手に親切にしようね」という身も蓋もないアドバイスになる。親切さがあれば自然と、ここで書くようなポイントを直したくなる......と主張するつもりはない。やはりプラクティス的に身に着けておくのが手っ取り早いだろう。

きちんとした日本語文章を書くときに気を付けていること

文章を構成するコンポーネントを「語」「文」「文章」のレベルで分けながら、それぞれのレベルで気になるポイントを挙げていく。

語レベル

一単語レベルで書き直すことが多いポイントを挙げる。

同じ助詞の連続を避ける

「~の~の~のhogehoge」や「~て~て」を避けたい。同じ語が連続すると読みのリズムが悪くなったり、意味が不明瞭になったりするからだ。

なお、助詞とは、それ一単語で文にならず、かつ活用がない語である。

例文①

「私の同僚の愛用のキーボードは割れている。」

助詞「の」は所属や主格など複数の意味を表せるので気を抜くと連続しやすい。 例えば次のようにすると文がすっきりする。

「私の同僚が愛用しているキーボードは割れている。」

例文②

「上司は同僚の分割キーボードを見て、自分も分割キーボードが欲しくなって、キーボードを二つ並べて「割れている」と言い張った。」

助詞「て」は迂闊に使っても意味が通ってしまうので連続させがちだ。論理や因果を表すのであれば「ので」や「ため」、「から」で言い換えるとすっきりする。 例えば次のようにすると文が比較的すっきりする。

「上司は同僚の分割キーボードを見たことによって、自分も分割キーボードが欲しくなったので、キーボードを二つ並べて「割れている」と言い張った。」

ちなみに後の項目でも述べるが、このくらい一文が長くなるならそもそも文を分けたい。

語彙が通用する範囲を意識する

語彙が適切かどうかを考慮し、言い換えや補足を検討したい。 その文書を届けたい界隈で慣用的に使われている語だろうか?と考えるとやりやすい。

例えば、次のような疑問を常に頭に浮かべておく。

  • 実はXXという概念は社内だけで通用するものではないだろうか?
  • エラーが発生することを「怒られ」と表現するのはオタクだけではないだろうか?
  • 「分割キーボード」は世間に広く知られている概念ではないから補足が必要ではないだろうか?

名前を間違えない

ものの名前の誤りは、文章をスムーズに読み進めるための阻害要因になる。 サービス名やプロダクト名は間違えがちなので特に注意したい。

例えば、私がよく見る誤りは次の通りだ。

漢字を開く

漢字表記をかな表記にすることを「漢字を開く」と呼ぶ。慣例に沿って適切に開いておくと読みやすさが増す。

ただ、どれを開いてどれを閉じるかは好みの範疇にもなるかもしれない。しかし少なくとも同一文書内では漢字の開く・閉じるは統一したい。

例えば、個人的に開くようにしている語は次の通りだ。

  • 補助動詞
    • して置く → しておく
    • させて頂く → させていただく
    • して欲しい → してほしい
  • 副助詞
    • XX迄に → XXまでに
    • XXな位 → XXなくらい

指示語・形式名詞は具体的にする

指示語・形式名詞は具体的な名詞にしておかないと意味を取りにくくなる場合がある。

指示語とは、「この」や「その」などいわゆる「こそあど言葉」である。 形式名詞とは、「私が書くこと」の「こと」のような、他の語に修飾されることによって意味が補完される、抽象的な名詞である。

どちらも語から具体性が減少しがちである。そのため意味の読解を読み手に委ねることになるので、具体的な語で補完してあげると親切だ。文脈によって意味の取りづらさは変わるので、必要に応じて付け足しをしたい。

例文①

初めての体験なのに、すでにどこかで経験したことがあるかのように感じることがある。これをデジャビュと呼ぶ。

→ 初めての体験なのに、すでにどこかで経験したことがあるかのように感じることがある。この現象をデジャビュと呼ぶ。

例文②

個人的に開くようにしているのは次の通りだ。

→ 個人的に開くようにしているは次の通りだ。

文レベル

文や文節レベルで意識していることを挙げる。

主語と述語を対応させる

主述の非対応は、意外とよくあるミスなので気を付けたい。主述が対応していないと、頑張って読解しようとする読み手にストレスを与えることになる。

そもそも主語を書く

日本語で文章を書くと、主語のない文が誕生しがちである。主語を省略すると、意味の補完を読み手に委ねることになるので読み手に対して不親切だ。

ちなみにこの記事中には主語のない文が複数ある。個人のブログなので、「私は」の文節を補完してくれるだろうと読み手に甘えている。ごめん。

主述が捻じれてないか?

一文が長くなると、主述の対応がおかしくなりがちである。

例文①

プロジェクトは、彼の努力によって成し遂げた。

この文の主語は「プロジェクト」だ。 この文の述語は「成し遂げた」だ。 つまり、この文をシンプルにすると「プロジェクトは、成し遂げた」となる。能動・受動が捻じれている。

次のようにすると主述が対応する文になる。

プロジェクトは、彼の努力によって成し遂げられた。

例文②

彼にとっての自己成長とは、様々な挑戦を乗り越え、新たな視点を獲得していく。

この文の主語は「自己成長」だ。 この文の述語は「獲得していく」だ。 つまり、この文をシンプルにすると「自己成長とは、獲得していく」となる。主述が対応していない。

次のようにすると主述が対応する文になる。

彼にとっての自己成長とは、様々な挑戦を乗り越え、新たな視点を獲得していくことだ。

修飾関係が一意に定まる文にする

読み手の解釈によって語同士の修飾関係が一意に定まらない文は改善したい。

例文

頭が赤い魚を食べる猫

「頭」は魚の頭か、猫の頭か?「赤い」のは魚か、魚の頭か、猫か、猫の頭か?「食べる」主格は頭か、猫か?

一意に定めようとすると次のようになる。

魚がある。その魚は赤い。猫がいる。その猫の頭がその魚を食べる。

文章レベル

『入門 考える技術・書く技術――日本人のロジカルシンキング実践法』という本に必要なことがだいたい書いてある。その中でも特に私が気を付けていることを挙げていく。

https://www.amazon.co.jp/%E5%85%A5%E9%96%80-%E8%80%83%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93%E3%83%BB%E6%9B%B8%E3%81%8F%E6%8A%80%E8%A1%93%E2%80%95%E2%80%95%E6%97%A5%E6%9C%AC%E4%BA%BA%E3%81%AE%E3%83%AD%E3%82%B8%E3%82%AB%E3%83%AB%E3%82%B7%E3%83%B3%E3%82%AD%E3%83%B3%E3%82%B0%E5%AE%9F%E8%B7%B5%E6%B3%95-%E5%B1%B1%E5%B4%8E-%E5%BA%B7%E5%8F%B8/dp/4478014582

一文を短くする

一文は短ければ短いほど良い。長い文はそれだけで読みにくいからだ。 一文に二つ以上の主述関係があれば、分割を検討する。分割した文同士は、適切な論理を表す接続詞で繋ぐ。

論理を明確にする

適切な接続詞を使うと論理が明確になる。裏を返すと、すべて「~で、」「~して、」などで繋ぐと論理関係が伝わりにくい。

順接なのか、逆説なのか、並列なのか、例示なのか、時系列の連続なのか、etc......。

抽象度を操る

抽象的な結論→抽象的な理由→具体性を帯びた説明→具体例 のような文章構造にすることが多い。

おわり

以上、私が文章を書く際に気を付けていることを思いつくままに挙げていった。個人の好みによる内容もあるだろうが、少しでも誰かの参考になれば嬉しい。

このあたりはAIってやつで自動でいい感じにしてほしいものだが、まだ難しいようだ。余裕で捻じれた文を出してくることもある。

bunでOpenTelemetryチュートリアル

bunはかわいいjs/tsランタイム兼バンドラ兼テストランナーのやつである。ロゴが可愛い。

https://github.com/oven-sh/bun

OpenTelemetryは抽象化・標準化された可観測性のためのプロジェクトだ。Node.jsのsdkが開発されており、チュートリアルもある。

https://opentelemetry.io/docs/languages/js/getting-started/nodejs/

これをbunで走らせたいと思った。

チュートリアルではinstrumentation.tsapp.tsを用意して、次のコマンドを走らせている。

$ npx ts-node --require ./instrumentation.ts app.ts

ts-nodeはts実行パッケージだ。 --requireオプションでモジュールの事前ロードが可能になる。 instrumentation.tsでOTelExporterを走らせ、app.tsでWebサーバーを立てる。

この--requireと同等のオプションをbunで探すのに手間取った。

https://github.com/oven-sh/bun/discussions/5016

-rオプションでOKだった。helpを見るべし。

あとは、チュートリアルnpm installbun installに読み替え、実行を次のようにすればいいだけだった。

$ bun -r ./instrumentation.ts app.ts

これでnode.jsと同等にチュートリアルが動いた。

https://github.com/TypeStrong/ts-node

Datadog Loggingで`/users/ID`みたいな動的なパスをまとめつつ静的なパスはそのままにするやつ

シュッと実装できなかったので備忘録。 検索しても即効性のあるドキュメントがでてこない。Datadogあるある。

LoggingのPipelinesのページでログの処理を追加すればよい。

Datadogの画面の一部のスクリーンショット。`Pipelines`のページに遷移するためのボタンUIがある。

たとえば@http.url_details.path属性にpathが保持されているとする。

1. Path remapperでpathの属性をremapする

DatadogのPath remapperの設定画面のスクリーンショット

Set attribute(s) or tag key to remapには、元の属性名を入れる。例えば@http.url_details.pathなど。 Set target attribute or tag keyには、適当な属性名を入れる。例えばcategorized_pathなど、他と被らないように気を付ける。 Preserve source attributeを有効化しておけば、元の属性も保持されるのだと思う。

2. Category Processorで、動的なパスをまとめる

DatadogのCategory Processorの設定画面のスクリーンショット

Set target category attributeには、1で指定したSet target attribute or tag keyの属性名を入れる。 Populate categoryAll events that match:には、動的なパスを絞れるクエリを入れる。例えば@http.url_details.path:/users/*など。 Populate categoryAppear under the value name:には、動的なパスを意味してほしい値を入れる。例えば/users/IDなど。 動的なパスの条件を一つ一つAddしていく。

完了!

これで、@categorized_path属性に、まとめられたパス名が入る。 2の工程のみだと、動的なパスのみが@categorized_pathに入る。事前に1の工程でremapをしておくことで、静的なパスはそのままで、動的なパスはカテゴライズされて保持されるようになる。

これらの工程によって追加課金はない......はず。Datadogの課金体系は気をつけないと容易に事故死するのでお気をつけあれ。

Google CloudでインスタンスのOS Loginを有効化しても従来の鍵で認証できる

OS Loginとは、Google Cloudが提供するSSHアクセスの管理方法の一種である。

https://cloud.google.com/compute/docs/oslogin?hl=ja

OS Loginを有効化すると、LinuxユーザーをGoogleアカウントに紐づけてくれる。認可はIAMで行われる。つまり、公開鍵・秘密鍵の管理が不要になる。うれしい。

さて、OS Loginを有効化したときの挙動はドキュメントには次のように書かれている。

VM の authorized_keys ファイルを削除します。 AuthorizedKeysCommand オプションを使用して OpenSSH サーバーを構成します。このコマンドにより、ログイン操作の認証に使用する、Linux ユーザー アカウントに関連付けられた SSH 認証鍵を取得します。

注: OS Login が有効になっている場合でも、ローカル ユーザー アカウントのアクセスをプロビジョニングするように authorized_keys ファイルを構成できます。構成すると、authorized_keys ファイルで構成された SSH 公開鍵を使用して、ローカル ユーザーによるユーザー ログイン試行の認証が行われます。ローカル ユーザー アカウントには、OS Login ユーザーが使用するものとは異なるユーザー名と UID が必要です。

authorized_keysが削除される。すなわち、その時点で公開鍵による認証はできなくなる。 「OS Login が有効になっている場合でも、ローカル ユーザー アカウントのアクセスをプロビジョニングするように authorized_keys ファイルを構成できます」と書かれているが、どうやって「構成でき」るのかは書かれていない。困る。OS Loginを有効にしながら従来の鍵でログインできないだろうか。

結論、できる。単純に、OS Loginでsshしてauthorized_keysがもともとあった場所に手作業で元の内容のままで再配置すればよい。そうすればOS Loginでログインできるし元の鍵でもログインできる。 きっと、AuthorizedKeysCommandで、IAMによる鍵取得だけでなく元の鍵の選択肢もサポートされたままなのだろう。AuthorizedKeysCommandについて調べたくなる。

『実践Vim 思考のスピードで編集しよう!』を読んだ

https://www.amazon.co.jp/gp/product/B00HWLJI3U/ref=ppx_yo_dt_b_d_asin_title_351_o01

vimの機能をTIPSという形式で大量に書き連ねた本である。

いまだにvimによるコーディング速度がVSCodeによるそれの1/10くらいだなあと悩んでいたのでタイトルに惹かれて買った。 半年ほど前から、私物のPCではneovimを使うようにしている。vimについては、編集するのに困ることはないが思うように速度が上がらず困っている状態である。本に書かれているTIPSのうち、8割くらいは普段使いしていない機能であった。 序盤で思想として「繰り返し」を強調しているのがよかった。とりあえず触ってから、思想を知ることで、より深く扱えるようになるというのは理想的な習得方法だと思う。

ぶっちゃけ読んだことの9割くらいはすでに頭から抜け落ちた。エッセンスだけ頭の片隅に置いておいて、その場面に出会った際にリファレンスとしてこの本を開く、という使い方がよいのだろう。電子書籍で買ったことを少しだけ後悔している。

TTY・PTYってなんだ、`docker exec`コマンドの`-t`って何してるんだ

ターミナル関係でよく聞く言葉、という認識しかなかったので調べてまとめる。 dockerコマンドの-tオプションが何をやってるのかが分かるのをゴールとする。

TTYとは何か

信頼できない情報源の記述をまとめると、TTYとはどうやらUnixLinuxが持つ機能の一部らしい。

https://www.kernel.org/doc/html/latest/driver-api/tty/index.html

Linux Kernel Documentation』内に説明ページがあった。

Teletypewriter (TTY) layer takes care of all those serial devices. Including the virtual ones like pseudoterminal (PTY).

TTYとはTeletypewriterの略であり、疑似端末を含むシリアルデバイスの面倒を見るレイヤーだそうだ。

シリアルデバイスとは?

シリアルデバイスは、シリアルデータを送受信できるデバイスである。 シリアルデータとは、連続的なデータである。データを1ビットずつ連続して送受信できる装置がシリアルデバイスだ。

「面倒を見る」とは何をしているのか?

Every character received by the kernel (both from devices and users) is passed through a preselected TTY Line Discipline (in short ldisc; in C, struct tty_ldisc_ops). Its task is to transform characters as defined by a particular ldisc or by user too. The default one is n_tty, implementing echoes, signal handling, jobs control, special characters processing, and more. The transformed characters are passed further to user/device, depending on the source.

カーネルが受信した文字(たぶんシリアルデータのこと)はTTY Line Disciplineというものを通過する。通過する際に、その文字をいい感じに変換してくれるくん、という理解であっているだろうか。 TTY Line Disciplineは"ldisc"と略される。略称にTTYは登場しないんだ。デフォルトのldiscはn_ttyというものである。n_tty`はなんかいろいろやってくれるらしい。便利。

pseudoterminal、PTYとは?

https://docs.kernel.org/filesystems/devpts.html

Each mount of the devpts filesystem is now distinct such that ptys and their indices allocated in one mount are independent from ptys and their indices in all other mounts.

このあたりから察するに、PTYとは物理端末ではない仮想シリアルデバイスのことだろう。Linuxファイルシステムにマウントされるようだ。

docker execコマンドの-t

https://docs.docker.jp/engine/reference/commandline/exec.htmlhttps://docs.docker.com/reference/cli/docker/container/exec/

-t, --tty

Allocate a pseudo-TTY

ここまでの議論からまとめると、docker execコマンドの-tとは、シリアルデータを送受信するための疑似端末をコンテナに割り当てるためのオプションである、と言えるだろう。つまり-tオプションをつけるとターミナルでコンテナに入出力できるようになる。