hkoba blog

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

喪中につき年賀を失礼します/2024近況報告

昨秋、父が亡くなりました

喪中につき新年のご挨拶を失礼させていただきます。

旧年中に仲良くしてくださった皆様、ありがとうございました。

今年もよろしくお願いします。

宮崎に移住しました

また、皆様へのご連絡が遅れましたが、昨年半ばから東京を離れ宮崎へ移住をしております。きっかけは父の入院・闘病が始まったことでしたが、 移住を決断した理由は、母を独居にしてしまうと色々と心配が増えるためでした。兄弟の中では自分が最も身軽なので、ここはお兄ちゃんが頑張るしかあるまいと…長男ﾀﾞｶﾗｰ（お仕事自体はリモートで継続です）。東京で借りていたマンションもすでに引き払いました。

とはいえ移住にあたっての諸々はまだまだ続くので、当面は暮らしのペースを掴むことを最優先にしていこうと考えています。

宮崎はなかなか良いところです。機会が有ればぜひ遊びに来てください。

仮説：Twitter の広告ビジネスは（login ユーザーじゃなく）guest をターゲットにしたほうが、うまく機能するのではないか？

  1. 現在 Twitter はビジネスの持続性を得るため、 login 済みアカウントへのターゲット広告を主な収入源にしようとしている（のですよね？私はそう理解しています）

    • ゆえに、↑そのビジネスモデルに直接的には貢献しない bot API アクセスの料金プランを値上げした
    • その結果、スクレイピングが横行したので、guest/public read も禁止しようとしている

  2. しかし、Twitter がバズを生み出すハブ・プラットフォームとして社会的に唯一無二であった点は、その guest/public readability とソーシャルグラフとの掛け算の大きさにあったのではないか？

    • インフルエンサーが（他の blog などで長文を書いたあとで）twitter にリンクを投稿するのは、ここに乗せれば guest も含めて万人への timely な広報になるからだった。
    • どんな流行も、early adapter より遅れてくる（＝話題に接する）人のほうが多い。遅れてくる人＝ guest、埋め込みなどで他のメディアで知る人と思って良いのでは。
    • guest/public read 切り捨ては、late majority の切り捨てであり、バズを生み出すハブとしての地位を自ら捨てるようなもの
    • 今すすめている閲覧制限は、自殺行為なのではないか？

  3. もし、late majority がほぼ guest でありバズの本体であるとするなら…広告は guest に対して出すほうが効果的なのではないか？

    • 例えば、tweet 埋め込みに対して広告を出す、など

まぁ、素人考えかもですが…

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

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