hkoba blog

プログラマーです。プログラミング言語ミーハーです。ツッコミ歓迎です。よろしくどうぞ(能代口調)

謹賀新年/2023目標

あけましておめでとうございます

旧年中に仲良くしてくださった皆様、ありがとうございました。
本年も変わらず元気で、日々を地道に生き抜き、暮らしを作っていきましょう

昨年の振り返り、良かったこと

  • 仕事

    • 業務で他社さまの営業の方とのオンラインミーティングの機会をもらえたこと。アカリクさん、GCP さん、どちらも打てば響く感じがあって、とても楽しかったです。ありがとうございました。

    • mermaid-js でシーケンス図を書く方法を覚えたこと。これで業務フローの聞き取り・整理がとてもはかどった

      mermaid.js.org

    • marp.appでスライドを書く方法を覚えたこと。マニュアルは mdbookで書いて、講習の資料は marp スライドで書く、みたいな使い分け。（次は slidev にも挑戦してみたい）

    • gitlab の活用を（徐々にだけど）拡大出来ていること

      • gitlab-ci → mdbook / marpで社内全員向けドキュメントやスライドを量産しやすくなった（apache + shell executor だけど）
      • cvstrac の ticket を gitlab の issue へと差分取り込みする手順を作れたことと、 GitLab Meetup でその発表を出来たこと hkoba.github.io

    • buildah を覚えたことで（Dockerfile じゃ困難なものでも）コンテナ化出来るようになったこと。下記の記事の Buildahとは何か？なぜ使うのか？ と、別の記事に有った unshare コマンドの話 が大きなヒントになりました。

      rheb.hatenablog.com

    • stefafafan さんが記事で紹介してくれていた、IAP によるゼロトラスト保護にワイルドカード証明書を使う方法と、それを使って IAP 保護下で Cloud Run サービスを量産する方法を、概ねうちでも再現できたこと。

    • 逆terraform(terraformer)の導入。これで GCP の設定を tf ファイル群としてダンプすることが出来るので、クラウドの設定変更を git で履歴管理＆ gitlab issue への紐付けが可能になった。

  • プライベート

    • ほぼ健康に過ごせたこと
    • 夏コミ行けたこと

    • 観艦式2022 行けたこと！

      いずも
      もがみとあたご
      くにさき

    • SteamDeck ゲット！

    • （未完成で未だ他人様には勧められないけど）yatt-js の実装を大分進められたこと
      • typescript での開発のリズム的なものが、少しずつだけど、つかめつつあること

昨年の反省点や残念だったこと

  • いまだ javascript 周りのキャッチアップが終わらない（終わるのか？）
    • npm へのパッケージ公開のお作法的なもの、誰かに教わりたい・相談したい…命名とかバージョンどの程度から publish してよいかとか workspace とサブパッケージの分け方とか…
  • 外出が苦手になりつつあること…特に夜や冬場
  • 部屋の片付け、してないな…
  • 好きで通っていたご飯やさんが、辞めてしまったこと。コロナ禍ゆるすまじ
  • .oO(…身近なところで、食っていけないという話を聞いてしまった。ちょっと考えないと…)

今年の目標

  • yatt-js を生活か仕事に実戦投入し、それを通して他人様にも使ってもらえるレベルに育てる
  • No Code/Low Code DB の OSS、どれが使えそうか選定して活用を試みる
  • 嫁・彼女探しを…諦めない…
    （致命的な衝突をしないですむ人を、どうやって探せば良いのかしら…）

謹賀新年/2022目標

あけましておめでとうございます。

旧年中に仲良くして下さった皆様、ありがとうございました。本年もよろしくお願いいたします。

2021 振り返り、良かったこと

  • 仕事

    • 主要な業務サーバーの脱VPN・ゼロトラストセキュリティ化が出来たこと。
      具体的には GCP の IAP - Identity-Aware Proxy の導入

      cloud.google.com

      並びにその setup/teardown 手順をある程度はスクリプトに出来たことで、ゼロトラスト保護されたサーバーの量産が容易になったこと

    • ゼロトラスト保護された gitlab の導入と、 gitea, redmine からのデータ移行を実現できたこと
      標準の import 機能だけでは issue の取りこぼし、プルリク上の議論の取りこぼし、commit からのチケット参照が無視される件などで満足できず。gitlab のソースを解読・切り貼りして import 用 ruby スクリプトを書いて実現（実質初 ruby）
      • 出来上がったスクリプト、公開はしたいけど、手法が手法だけに、適切な公開方法が分からない。アドバイス頂ければ公開できるかも…

  • プライベート

    • ほぼ健康に過ごせたこと
      新型コロナによる死は決して見知らぬ他人事ではない、そう思わされる出来事があり。 それゆえに、今後も己の身命を慎重に大事に使っていかねばならないなと。健康に過ごせたことを感謝しつつ、警戒を続けたい。（ウザがられるかもだけど…）

    • 艦これアーケードを続けられていること

    • yatt の typescript 版の実装を大分進めることができたこと（さきほど Public にしました）
      github.com

2021 の反省点

  • 運動不足・外出不足

  • 同僚とのコミュニケーション不足…害は有るはずだけど、自分にそれが見えてないのが危うい

2022 の目標

  • typescript 版 yatt を他人に使ってもらえるレベルに仕上げる＆個人的な情報生活の道具として使い始めること

    • npm にどの段階で公開すべきか？誰か node 慣れした人にアドバイスをもらいに行きたい…

  • 友達作り？パートナー探し？

謹賀新年/2021目標

あけまして、おめでとうございます

旧年中に仲良くして下さった皆様、有難うございました。本年もよろしくお願いします。

2020 の良かったこと

2020 の反省点

  • 仕事
    • Gitリポジトリ管理の迷走。 phabricator → gitea へ移行したものの、グループ管理周りが不満で、全社導入には向かないと判明。
    • GCP 以外の部分に停滞感があったこと。優先順位的に仕方がなかったとはいえ…
    • 作ったツールを他の人に使ってもらうための、ドキュメントが書き足りない。
  • 生活
    • 運動不足。足が弱ってそうな気がする。
    • 視力低下。引きこもりだから。対策がほしい…

2021 の目標

  • GCP、まだまだ理解不足や設定自動化が出来てない部分が多いので、引き続き勉強してツール化を進める
  • GAS 力を付ける
  • yatt を typescript へ移植する

zsh 上で .pm のメソッド名を補完する話

perl zsh

この記事は Perl Advent Calendar 2020 の 12/3 の記事です。

想定読者は、自分で Perl のモジュールを書く機会が有り、かつそのモジュールのメソッドをコマンド行からさっと試したい！ と思ったことの有る人です。

Perlモジュール（.pm ファイル）を実行可能なスクリプトにする技法（モジュールに unless caller で直接実行時の処理を書いておく）は 90年代から存在し、Modulino （モジュリーノ）という名前でも知られています。 更にオブジェクト指向のクラスとして書かれた Modulino にメソッドディスパッチの機能を持たせて OO な Modulino とする手法は、多くのメソッドをコマンド行から即座に試せるため、一層便利です。 私も何度かの 記事や勉強会で発表してきました。もちろん私が仕事で新たに書く Perl モジュールは原則として全て OO Modulino です。

ただ、そんな私でも、半年前に書いたモジュールを久しぶりに使う時などは、そのモジュールがどんなメソッドを実装しているかをもう忘れているのが普通です。そのため、例えコマンド行からメソッドを呼び出せる仕組みが有ったとしても、 結局 ソースを一通り眺めて適切なメソッドを探すという無駄な時間 を要していました。

ここでもし、シェルのコマンド行の補完機能で、メソッドやオプションの名前（と、その説明文）の一覧を見ることが出来たら、（その後でソースを確認する必要は残るとしても）適切なメソッドを探す時間を大分節約できるのではないか…？ そう考えて実装したのが、 zsh の completer、 _perl_oo_modulino です。(CPAN に公開済み)

デモ動画を用意しましたので、良ければご覧ください（無音、約2.5分）＞

デモコードのリポジトリはこちらです。 デモ用に、業務コードからメソッドやオプションとその解説文だけを切り出したものです。解説文を定義している部分を以下に抜粋します＞

付録

簡単に試したい

デモコードに Dockerfile を用意したのでお試し下さい。run すると zsh が起動します。 上記の demo3 が workdir /data/ の下にあります。

hkoba の Base クラスって何？

こちらです。（長い名前なので、私は普段 CLI_JSON と呼んでいます）＞

MOP4Import::Base::CLI_JSON - metacpan.org

この CLI_JSON を継承したクラスじゃないと動かないの？

必ずしも継承する必要はない（はず）です。

  • CLI のサブコマンドをメソッドへとマップする、 OO な Modulino になっていれば、意味の有る補完が出来るはずです。

    • メソッドの解説は code attribute から取得しています。ですので、 :Doc() を定義・取得出来るよう、 MODIFY_CODE_ATTRIBUTES と FETCH_CODE_ATTRIBUTES を実装する必要があります。
      • とはいえ現状では取得側は my ($atts) = grep {ref $_ eq 'HASH'} attributes::get(\&method); $atts->{Doc} みたいなコードです。attributes の使い方を間違っている可能性もあります。ツッコミ希望です。

  • CLI のオプションを %FIELDS で定義したフィールド（メンバー変数）へとマップする仕組みなら、オプション名の補完も効くはずです。

    • オプションの解説は $FIELDS{フィールド名}->{doc} から取得しています。

zsh 側はどういう仕組み？

zsh には コマンド名のパターンに対する補完関数を定義する機能 compdef -P があります。これを使えば拡張子 *.pm 全てに対する補完を定義できます。

bash に同等の機能が有るかどうかは分かりません。有れば実装できる可能性は有ります。

以上です

読んで下さりありがとうございました。明日の記事は utgwkk さんです。

フロー vs ストックは誤った二分法なのか否かについて

この記事は、元記事に対する私の呟き

に対して西尾さんから頂いたこのお返事↓に対する返信です。

目次：

どこに、どんな違和感を感じたか

まず最初に、私の主張を明確にするため、私が西尾さんの主張の骨子だと解釈した部分を元記事から抜粋させて頂きます。

  • かつて[フロー]と[ストック]の境目が明確だった時代もあった
    • チャットがIRCだった時代のイメージ
  • そんな時代は過去の話だ
    • チャットサービスであるSlackは、チャット機能を無償提供する
    • 「チャットログのストックへのアクセス権」で課金するモデルだ
  • 今の時代、ほとんどのサービスが以下の機能を持つ
    • 情報をストックする

これに対して私が感じた違和感・疑問点は、

  • (私も職場で 2015 から有償版の Slack を使ってきたし検索も沢山使うけど) ログの検索があるから大丈夫と思ったことはない、必要な情報を得る大変さは今も変わっていないではないか。
  • そもそも Slack の（会話が蓄積されているだけの）ログは、私の考えるストックと呼べる代物だろうか？

でした。

「ストック」の定義の差異

西尾さんは記事の末尾にこう書いています。

  • この文章は「情報が流れさるのがフロー、情報が蓄積されるのがストック」と考えて書いた

つまり「ストック＝情報の蓄積」という定義でしょう。

ここで辞書でストックを引いてみると 在庫, 貯めておくこと などの言葉が出てくるので、 それでも良いのかもしれません。情報処理システムの議論においては、その定義を用いる人も多いのかもしれません。

dictionary.goo.ne.jp

ですが私は、世間で「ストック, フロー」という語のペアが使われる時は、 （計算機が発明される以前から使われてきた）会計や経営、経済学における定義・概念が輸入されて使われるケースもあるのではないか？と思うのです。 （どちらの使い方が多いのか、分野によって使い方の差が有るのかは調べていません）

私は会計は独学でしか学んでいないのですが、岡部先生の複式簿記(リンク先 PDF) の「第2章 財務諸表の作成の実際」の冒頭には以下のように書かれています。

簿記をつける最大の目的は、財産移動を日々記録して、一定の会計期間の財産移動とその結果と しての財産の現状を掴むことである。財産の蓄積状況をストック (stock) と呼び、財産の変動状況 をフロー (flow) と呼ぶ。一般には、フローが起るたびにストックが変化することになるが、その 都度一々計算するのは大変であるので、会計計算には会計年度とか会計期間とかいった一年や半年 や四半期の会計の締切の周期を設け、その終了時にその直前の会計期間のフローの状況を集計し、 財産のストックを計算する。

```

       期首ストック + 当期フロー = 期末ストック

```

（引用内のコードブロックに生でバッククォートが出ていますが、これよりマシな表現が出来ず…ご了承下さい）

会計における定義を私なりに書き下します：

  • ストックとは（科目、残高）の組の集合
  • フローとは（日付、増えた科目、金額、減った科目）の組の順序列
    • フローを記録したものをジャーナルと呼びます。（明らかに、これはログです）

改めて辞書のストックの定義に 在庫 とあったことを思い出して下さい。 例えば他人から「在庫を教えて？」と聞かれて、「今週頭に10個あって、月曜に3個出荷、火曜に2個入荷…」 と返事をすることは非効率です。その意味でもストックという語の訳に当てられる在庫とは、 その時点での総数のことと考えたほうが、より適切ではないかと私は考えます。

会計の定義は情報システムの改善の議論には関係あるか？無いか？

会計の話は計算機による情報システムには関係ない、と思うかもしれませんが…会計におけるストックの定義が（ログではなく）残高であることには 情報システムにおいても重要な意味があると、私は考えます。なぜなら 一般化すれば、ストックとは長大なログに何らかの要約（サマリー）作用を適用して情報を圧縮したもの と言えそうだからです。 つまりそれは、人間が生ログから情報を得ようとすることに掛かるコストを節約するために生まれた知恵なのではないでしょうか？。 そのログが金勘定なのか、日々の様々な対話なのかは捨象して良いことですが、フローのログを人が直接触るより要約を作って置いたほうが良いケースだけは必ず有るだろうと思います。

今来た三行 は何にでもある…そういう話かと思います。

結論は？

  • 「フロー vs ストック」という用語・二分法は計算機システムよりも以前に、会計（複式簿記）の世界で定義され広く用いられてきた。
  • ログが蓄積されているだけでストックと呼ぶ用法は、従来の用法とは一致しない。
  • 情報システムの議論においても、会計における用語・概念整理を用いたほうが、実りが有るのではないか？

こんなお返事で如何でしょうか？

私がシェルスクリプトをZshで書く理由

zsh

まず最初に、４つのファイル foo, bar, *, xxx yyy があるディレクトリがあるとします。(試したい場合は新規のディレクトリで下記のコマンドを実行してください。)

touch foo bar \* 'xxx yyy'

さてここで、ループを使って各ファイルを一つ一つ、コマンドに食わせたいとします。 そのために、こんなループを書いたとしましょう＞

for f in *; do
  ls -l $f
done

それがこんな動作になるシェルは 疲れる から、です。 f:id:hkoba501:20200603120813p:plain

zsh であれば、デフォルトの設定（ no_sh_word_split かつ no_glob_subst ）で使っていれば、期待通りに４回だけ、一つずつファイルを渡しながらコマンドを実行してくれます。

f:id:hkoba501:20200603123244p:plain

（なお実行中の zsh をデフォルト設定にリセットするには emulate -L zsh コマンドが使えます）

他にも理由はありますが、これだけでも十分な理由かなと。

読んで下さり、ありがとうございました。

シングルサーバーの管理自動化に、Make に代わるものが欲しい

tcl linux

シングルサーバーの管理自動化に ansible や chef は良い道具か？

ansible によるサーバー運用管理の自動化が流行っているようですね。管理対象サーバーが沢山有り、なおかつ既存のレシピ（ansible だと module？）が自分の業務に活用できるなら、強力なのでしょう。

ですが世の中には、サーバー一台でも全ての業務を余裕で処理できてしまい、かつ自社の独自アプリ群の運用が主なテーマであるようなお仕事もありまして…

そういうお仕事で、 ansible (に限らず、流行の運用自動化ツール… chef? puppet?) は果たして便利なんだろうか？という疑問が有ったりします。例えば：

  • ansible は yaml で簡潔に書けるように頑張ってるけど、ツイッターを見ていると、変数展開？の挙動に関する苦情をチラホラ見かけるような？ （何となく、グリーンスパンの第10法則が思い出されます…）
    • chef の設定ファイルは ruby だから、そういうピジン言語の悩みは無さそうですが…
  • chef も、設定ファイルが ruby だとファイル名を沢山書く時に疲れませんか？ doublequote の嵐で…
    • サーバーの設定はファイル名やらホスト名やら…大量の文字列を扱うので、それを汎用言語の構文に収まるように変換しながら書くことは、単純に労力が大きい、という面があるかと思います。
  • そしてしばしば、最後は shell (bash) スクリプトの呼び出しになってませんか？

みたいなことを思うのです。

生の shell(bash) スクリプトも色々辛い

かと言って生の shellスクリプトだと（確かにファイル名とかは雑に書けて楽なのですが）、 そもそも shell(bash)スクリプトの弱点として

  • 変数展開一つとっても罠が多い（初心者殺し）
  • エラー処理を堅く書くのが大変（難度が高い）
  • Unit Test を書くのも大変

という問題があります。

その上、管理自動化用の機能を全部自分で書く必要があるでしょう。例えば：

  1. べき等性の実現方法
  2. dry-run の仕組み
  3. タスクの依存関係の処理

このうち 1, 2 は shellスクリプトの書き方に慣れればある程度は対応できます。 ただ、shell(bash)スクリプトでは複雑なデータ構造のサポートが足りないため、タスクの依存関係の処理までは 手が回らないことが多いのではないでしょうか？

Makefile はファイルの mtime ベースでしか依存関係を扱えない

この 3つを一挙に解決する道具として Makefile を使う手もあります。 特に最終的な目標がファイルの作成である場合は、とても有効です。

しかし、Makefile はファイルのタイムスタンプのみに基づいて依存関係を処理します。 ですから例えば /etc/ のあるファイルの中に〇〇が記述されていなければ記述を足す、みたいな処理を書くことは困難です。 つまり、サーバーの設定ファイルの自動書き換えには向かない面があります。

bash が嫌なら Tcl はどうか

ところで皆さんお忘れですが Tcl という言語が存在します。 Tcl は文字列の扱いに関して shell よりも更に緩くかつ構文を最小限に絞っています。 にも関わらず例外処理や名前空間があり、ある程度複雑なものも書ける、本格的なプログラミング言語です。

ということは、 Tcl に Make に似た依存関係探索ライブラリーが有ったら、サーバー管理の自動化に 使えるのではないかしら？

という思いつきで実験を重ねてきたコードがこちらです。その名の通り wip ですが、やりたいことは伝わるのではと＞ GitHub - hkoba/wip-TclTaskRunner0: WIP: Small task runner library in Tcl. Makefile alternative.

この現在の実験版では、例えば、 webmaster というユーザーと devel というグループのべき等な追加処理を下記のように書けます。 check が検査のコードで、check が false を返した時のみ、 action ブロックが実行されます。 ** は dry-run のマーカーです。タスク定義ファイルの中には普通の Tcl の手続きや変数を定義して使うことも可能です：

#!/usr/bin/env TclTaskRunner.tcl

import {file-has} from utils.tcl

default target all dependsTasks {
    webmaster
    devel
}

target webmaster check {
    check-user $target
} action {
    ** exec useradd -s /sbin/nologin $target
}

target devel check {
    check-group $target
} action {
    ** exec groupadd $target
}

proc check-user {user} {
    # id コマンドの呼び出しても良いですが、ファイルの中身の確認の例ということで…
    file-has ^${user}: /etc/passwd
}

proc check-group {group} {
    file-has ^${group}: /etc/group
}

こういう構想にご興味ございましたら是非お話しましょう〜

いまは例えばこういう所を悩んでいます：

  • タスクを宣言するコマンドの名前は target よりも task の方が良い？ (タスクランナーって名乗っているのだから…けど依存関係は target って言ったほうが自然な気がする)
  • 再帰 Make 的なものの実例が欲しい気がする。
  • リモートなタスクへの依存関係も記述したい。 (リモート実行は sshcomm の出番)
  • make -j みたいな並列実行もしたいのでは？ thread か？
  • Make の重要な機能である、変数をコマンド行からオーバライドする機能が欲しい気がするが、どんな実例を書こうか

ここまで読んで下さり、有難うございました。