hkoba blog

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

謹賀新年/2020目標

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

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

2019 の良かったこと

  • 遅まきながら、少しずつ GCP の業務投入を始められたこと。
  • libperl-rs の開発経験を通して、Rust に活路を見いだせそうな予感を得たこと(まだまだ勉強中ですが…)
  • マニュアルを書くためのツール、sphinx も試したけど mdbook の方が設定無しですぐにそこそこ使えて自分向きだと分かったこと。
  • (以前から構想していたことだけど、実際に)職場の Perl の新人教育のプロセスを -nle.pm から始めるよう試した結果、それなりの効果を確認できたこと。少なくとも .pm から教えることは現代的には全く問題が無い。ボイラープレートは File::AddIncM4I の CLI_JSON にまとめる方向で引き続き。

  • 艦これアーケードの秋イベント、なんとか甲クリアを継続できたこと

2019 の反省点

  • 仕事
    • 職場の新人教育、途中から私が多忙で放置になってしまったこと。もっとフィードバックを返したかった。
    • タスク管理が迷走したこと。 phabricator ←→ redmine どっちも合わない。ぐぬぬ
    • GCP での環境構築、スケジュールに追われたせいでシステム化(自動化)が後回しになっていること。
    • YATT の LSP、emacs の lsp-mode との組合せが今一思い通りにならず、その後の機能強化も停滞。後半に eglot に切り替えて少しマシになったけど。
      • かといって VS Code もまだ手に馴染むほどではなく… Emacs 使っている時より全体的に半分以下の速度しか出せない感覚…何が原因なのか…画面の切り替え?カーソル移動?マウスを触っている時間?
  • 生活
    • ジム中断(肘の痛みが原因)
    • 部屋の片付け・もの減らしが停滞している。
    • 婚活進展ゼロ。50歳なので街コンも行けないのだ。
      • とら婚さんにも相談してみたけど、結婚感というやつを言語化するのが大事だそうな。

2020 の目標

  • もっとドッグフード食っていきたい。
  • GCP 周りの自動化をもっと。ただし自分のフィールドを見失わない(世間の流行りのツールが自分の領域に適するかどうかは別問題)。Ansible とはまた違うアプローチを探りたい。
  • libperl-rs を引き続き強化して、 Perl コードの静的解析のための基盤へと育てる
    • Rust をもっと自分の道具にする。YATT や GUI ツール、自作言語のためにも使えないか。
  • 今年こそタスク管理ツールの移行を… gitlab か gogs か…
  • ジム再開?(肘の痛みは、持病と思うしか無いかも…)

-nle と .pm から始める Perl 入門とかどうかしら?(後編)

-nle と .pm から始める Perl 入門とかどうかしら?(後編)

この記事は Perl Advent Calendar 2019 の 12/5 の記事です。内容は主に職場で Perl教える側 の人に向けた、提案です。


コマンド行からエディタ+ファイルに移る時

昨日の記事は、Perl 屋の新人教育を コマンド行ツールとしての Perl から初めてはどうかしら?という提案でした。

今日の記事は、その新人さんの教育が進んで、コマンド行では収まらず、 エディタ+ファイルを使いたい規模に進んだ時に、今までどおりに *.pl の書き方を教え続けるのが良いのだろうか? いやむしろ、 コマンド行の次は即座に *.pm の書き方を 教えては?という話です。

.pl 飛ばして、 .pm から教えては?案

私が *.pm の書き方から教えることをお勧めする理由は、以下の2点です。

  1. 仕事で Perl を書く人の場合、モジュールの読み書きは避けては通れないから。
  2. *.pm*.pl を兼ねることが出来る(後述の Modulino)が、逆は違うから。

職場にもよるでしょうが、 今の時代に Perl を書くお仕事は、新規開発よりも保守改良のお仕事の方が多いのではないでしょうか。 その保守改良では、既存の業務のコードベースのモジュール群(つまり *.pm)を読み書きする能力が 不可欠です。だとしたら、 *.pl を学ぶことは新人さんにとって回り道なのではないか? という疑問があるのです。

もちろん *.pl*.pm よりもプログラミングの際の決まり事が少ないのは事実です。 教育の初期において負荷は少ないほうが良いという意見も分かります。 ただ、その部分はコマンド行の Perl でカバーしても良いのではないでしょうか?

何より、新人教育期間はただ知識を吸収するためだけではなく、 トレーニングのために確保された期間でもあります。 トレーニングは今後の仕事で必要となる作業に対して、その負荷に慣れて自然に動けるように力を 成長させるためのプロセスです。最終的に職場で要求されるのが *.pm であるなら、 その負荷に慣れるトレーニングを早めに始めることが大事なのではないでしょうか?

念のため、 *.pl, *.pm の長所・短所を整理してみます。

.pl の長所・短所

  • *.pl の長所
    • コマンド行の Perl で学んだこととのギャップが無い
    • ファイル名に制約が無い (拡張子が .pl である必要すら、無い)
    • #!/usr/bin/perlPerl のコマンド行オプションを書ける(制限有り)
  • *.pl の短所
    • *.pl ファイルをただ書いても、require, use で使えるモジュールにはならない。
      • == *.pl の中の関数を他のファイルから呼び出せない。
      • == ファイルの一部分だけを簡単に試す、ことが出来ない
        • 簡単に試せるように、仕様を絞って関数を書く、という動機が発生しない
    • テストを書くのが難しい
    • 結局 *.pl で書いたコードは単一の用途・文脈でしか役に立たないコードになる。

.pm の長所・短所

  • *.pm の長所
    • require, use, perl -Mモジュール名 で他のプログラムに読み込める
    • ファイルの一部の関数を他のファイルから呼び出す、という事が可能になる
      • == 呼び出した時に便利になるように、仕様を整理する動機も生まれる
    • テストを書くために Perl の標準的な道具が利用できる
  • *.pm の短所
    • モジュールの書き方の約束に従う必要が有る
    • ファイル名を(*.pl の時よりは)真面目に考える必要が生じる。(拡張子も .pm固定)
    • *.pm を実行可能にするには、 Modulino の書き方を覚える必要が有る

実行可能な Perl モジュール (Modulino = モジュリーノ)の書き方

では具体的に、新人教育でモジュールの書き方をどう教えればよいのでしょうか? 私は (Modulino = モジュリーノ) と呼ばれる書き方を使って、 スクリプトとしても実行可能なモジュールを書いてもらうことを提案します。

最初のモジュールは、おもちゃでも構いません。 むしろ怖がらないで済むように、おもちゃで始めるのが良いのではと思います。

例えば *.pl で最初に教えてきたのが print "Hello world!\n" なら、 同じことを実行可能なモジュールで教えれば良いでしょう。 練習ですから、ファイル名も細かいことは言わないで、ストレートなものが良いでしょう。

Hello.pm

#!/usr/bin/env perl
package Hello;

unless (caller) {
  print "Hello world!\n"
}

1;

あとはこのファイルに実行 permission を与えて、動かすのみ。

% chmod a+x Hello.pm
% ./Hello.pm
Hello world!
% 

モジュールとして読み込む場合はこうなります。

% perl -I. -MHello -e0
%

ただこれだと何も起こらなくて、嬉しさが伝わりませんね。 なので、教育の中で『関数が必要な題材』が出てきた段階で、初めて作る Perlスクリプトファイルとして *.pm の書き方を教える、というのが良いのではないかと思います。

行儀の良いモジュールの書き方に、どうシフトしていくか?

上で挙げた例の Hello.pmuse strict; use warnings が無いことを見て、 凍りついた人もいるかもしれません。業務に耐えるレベルのモジュールを書ける人になってもらうためには、 勿論、避けて通れない話です。この点は教育課程の練りどころで、私も現在、研究の最中です。 皆さんと情報交換していけたら有り難いです。

一つ言えるのは、コマンド行 Perl の教育と *.pm ファイルの教育は 必ずしもスパッと二期に分ける必要はないのではないか?ということです。例えば コマンド行で課題をしてもらっている中で、新人さんが変数の typo で苦労をし始めていることを 観測したら、その時点で *.pm ファイルの書き方に教育をスイッチして use strictmy を教える、というようにです。また逆に、新しい機能を紹介する時は、まず最初にコマンド行で実演してみせる、という手も有りえます。

多人数の同時教育では難しいかもしれませんが、ペア・プログラミングで徒弟的に教育を進められる場合は、 有力な方法ではないかと思います。(教育プロセスにもTMTOWTDI、なんちゃって…) Perl教育すごろくとかあると面白いかも…〇〇に詰まったら☓☓を教える、みたいな)

まとめ

職場の新人さんに向けた Perl教育で、コマンド行ツールとしての Perl を教えた後は 即座に Modulino で *.pm の書き方を教えるのはどうでしょう?という提案でした。

(実は Modulino の書き方に関してはFile::AddInc で @INC を調整する話とかオブジェクト化とサブコマンドの話とか use fields でオプションを表現する話とか引数/出力のJSON標準化の話とかネタは色々有るので、アドカレの空きが有ったら書くかもしれません…書けないかもしれません…><)

Perl Advent Calendar 2019, 明日の担当は, AnaTofuZ さんです.

-nle と .pm から始める Perl 入門とかどうかしら?(前編)

-nle と .pm から始める Perl 入門とかどうかしら?(前編)

この記事は Perl Advent Calendar 2019 の 12/4 の記事です。内容は主に職場で Perl教える側 の人に向けた提案です。

(今から仕事で Perl を学び始める人は、多分 Linux/Unix 環境に関わる人であろう、と想定しています。違ったらごめんなさい。)


初めて書く Perl は何が良い?

皆さんは職場の新人さんに Perl を教えるとき、初めにどんな形式でプログラムを書いてもらっていますか?

普通は何らかのエディタで foo.pl, hello.pl のように *.pl ファイルを作ってもらって実行、ではないかと思います。この方法は、使い慣れたエディタが有る人には最も安心感を与える方法でしょう。

ですが、この方法には二つの弱点があるのではないでしょうか?

  1. $_ などの特殊変数や、その省略法則(ex.デフォルトの m// の対象、split の第2引数、 -X テストの対象…)を教える切っ掛けが乏しい
  2. *.pm 形式のモジュールの書き方が先送りされる

そして何より、 今さら、 Perl を学ぶメリット を語る力が弱いのではないか?と私は思うのです。 1990年代ならともかく、現代では PerlPython, Ruby, PHP そして JavaScript と 強く比較しながら使われる時代です。今さら何故 Perl? という問いに答えを用意してあったほうが、 学ぶ人も意欲を持ちやすいのではないかしら?という考えです。

最初はコマンド行のワンライナーから、でどうでしょう?

その意味で、私は、最初に教える Perl はコマンド行での perl -nle … が良いのではないか? と考えます。何故なら、 コマンド行ツールとしての Perl の強さは、2020年代を迎える今でも十分な輝きを保っているからです。幾つか挙げるなら、

  • とにかく記述量が少ない。なのに、大きな働きをしてくれる
  • 起動が速い、実行速度も十分速い、もちろんビルド不要
  • 多くの Linux/Unix 系システムで、環境構築作業をほぼせずに、使い始められる
  • コア機能だけで十分役に立ってくれる(パッケージ管理の勉強を後回しに出来る)
  • 仕様が長期に渡って安定している

つまり、コマンド行ツールとしての Perl から始める理由は、簡単に学習を始められる上に、努力と得られるメリットの比率も抜群だからです。

また、Perl を学ぶ時の難所である $_ などの特殊変数やその省略法則を教えるという点でも、 コマンド行スタートにはメリットが有ります。何故なら、それらが ワンライナーを少しでも短く楽に書けるように設計された、lwall からのギフトだからです。 なのにコマンド行を全く避けてしまうと、その短い記法が分かりにくさ・読み難さの元凶、 害悪にしか思えなくなるでしょう。説明する側も言い訳がましくなり、辛いところです。

他にも副次的効果を何個も挙げられます。

  • shell と端末に馴染む機会にもなる
    • 特にワンライナーを書いてすぐ試す、リズムを会得できる。これは後のプログラミングにも有効。
  • sed, awk などの作ってきた Unix 文化の説明の良い機会にもなる
  • ミスが増えるので、perl -w の説明も導入しやすい
  • perl -d のデバッガに馴染む切っ掛けにも繋げやすい (ただし Term::ReadLine::Gnu の導入を推奨)
  • 段々プログラムが複雑化する過程で、変数名の綴り間違いの怖さに気づく切っ掛けにもなり、 use strict の意義を伝えやすくなる。
  • BEGIN {}, END {} を教える切っ掛けも作りやすい

この教育方法の弱点

この方法の弱点は、学習の記録を残すことが難しいことです。 学習の効果を定着させるには、学習者が学んだことを容易に振り返って復習出来ることが大事です。 しかしコマンド行は一過性の側面が大きいため、そこを不安に(不安定に)感じる人もいるでしょう。

これについては、以下の対策が有りえます。

  1. シェルのヒストリー機能とそのダンプ方法(history -w, fc -W)を初期に教える。
    • ヒストリーのダンプを git に保存しても良いかもしれない
  2. コマンド行の短縮記法を教えた後に、B::Deparse を使いながら冗長な(省略を廃した) 記法も教える。それをスクリプトファイルとして残し、これを git に保存する。
  3. いっそ script コマンド で全て記録するとか? ttyrec? asciinema?

組織を超えた教材化は難しいかも?

あとひとつ難しいかもしれないのは、コマンド行での Perl の使い方は環境(組織、文脈)に特化する面が大きく、 汎用の教材を作りにくい、かもしれないことです。例えば業務の副次的なプログラムのエラーログから 情報を抜き出して DB に投入するとか…それが一般的で頻出する問題なら、既に専用のプログラムが 作られていたり、予め構造化してログを吐くことが出来ているはずです。 (もっと良いツールがあるのに何で自分で書くの?と言われると…教える時の言い訳が増えますね…内容次第ですが…)

なので、教育のためのシナリオと、そこで使うデータセットの準備が、最も 手間取る所になりそうです。

(適切なツールが既に存在しても、それを探し出すのに何十分もかかるなら、自分でさっとスクリプトを書いたほうが早い、というケースの話も、しても良いかもしれません)

とはいえ、既存の教材も無くはないので、例えば↓この辺りから 題材を抜き出しつつ教えるのも良いかもしれません。

ミニマルPerl ―Unix/LinuxユーザのためのPerl習得法

ミニマルPerl ―Unix/LinuxユーザのためのPerl習得法

あと、同じくフィルタに向いた言語のご先祖様であるプログラミング言語AWKの本からも例題を拾えるかもしれません。

プログラミング言語AWK

プログラミング言語AWK

まとめ

Perl 屋の新人教育、最初はコマンド行の Perl から初めてはどうかしら?という提案でした。

では、学んだコードをファイルにしたくなった時、 *.pl に入れるのが良いのだろうか? いやむしろ、最初から *.pm で学ぶと良いのでは?

そういう話を明日の後編記事に書きます。

odc2019 聞きに行ってきました

odc2019 (オープンデベロッパーズカンファレンス) に初めて行ってきました。非常に勉強になりました!

www.ospn.jp

聞けたトーク

(本当は朝から行きたかったのですが、うっかり宅配便の受け取り予定を入れてしまって…お昼からに…)

日本語入力の危機を乗り越える インプットメソッド・フレームワークとかな漢字変換に訪れている課題とその対策

私も Fedora Linux を使っていて日本語入力には日々お世話になっているので、動向把握のために行きました。

  • これまでは GUI ツールキットと日本語入力フレームワークの組合せは GTK_IM_MODULE や QT_IM_MODULE を通して選択可能だった。 xim / uim / ibus / fcitx …
  • 今後は Gtk4 や Qt5? 等々が直接 ibus を話す方向に進んでいる、とのこと。ibus (protocol? api?) がデファクト標準化しつつある模様。
  • 最新の DebianGnome が Wayland ベースになった際に、従来の /etc/X11/... の仕組みが使われなくなり、 日本語入力が出来ない問題が起き、 im-config周りに変更を入れた
  • Waylandにはカーソル位置を取得する API が無い??(ゆえに変換ウィンドウの位置を制御できない??)

個人的には、 ibusデファクト標準の地位を得つつ有るらしい、という情報が一番有益でした。 Fedora ユーザーなので ibus をずっと使っているものの、他の仕組みに切り替えるほうが良いのかも?という迷いがずっと有ったので…)

運用ドキュメント2019 ~ 手軽にスピーディに継続的に保守するためのドキュメント入門~

私も職場での運用手順や開発関連のドキュメントをどう構築管理するのが良いか悩んでいるので聞きに行きました。非常に耳に痛い、有益な主張がてんこ盛りでした。流石にそこを本業にしている人は切れ味が鋭いなぁと。

そもそも運用ドキュメントとは何のためのものか?からストーリーが組まれていたので、議論について行きやすかったのも有難かったです。

運用ドキュメントのレベル

  • Lv0.記録: 事実であること(言語化)
  • Lv1.整理: 論理的に正しいこと(論理化) → 知る
  • Lv2.客観化: 客観的であること(抽象化) → 説明する
  • Lv3.脱属人化: 再現性があること(具体化) → 永続化

刺さったスライドを挙げていくと切りがないですが…

スライドに無い話も非常に興味深かったです。

  • 35歳の壁の話(固有名詞が出てこなくなる)とか。←言われてみれば自分もそうだったかも!
  • 運用ドキュメントを即興 shell script で組み立てる(組み立てられるように、パーツとなる文書を貯めていく)という話も驚きでした。
    • そして↑そういう事をするには sphinx が適している(というか include が大事)とのこと。やっぱりそうですか… (mdBook とかでも行けるかしら?)

懇親会も楽しかったです

libreoffice の方や opensuse の方が同テーブルでした。unix/linux の話が普通に出来るのは、やはり有り難いですね。(WindowsMac が支配的な世界だと、ちょっと肩身が狭くて…) (迷惑だったかもですが)私が仕事先のチームで何故 XWindow の業務環境を維持しているのかという話も聞いてもらえて。 前田薫さんにも Runnable Module + JSON CLI や自作テンプレートエンジンの話を聞いてもらったり。逆に TypeScript/Go/Python の書き味の比較の話を聞かせてもらったり。

他人に説明する過程で自分がその立ち位置を選んだ理由を明確化できるので、こういう対話の機会はやはり有り難いです。そして、自分の主張を予めブログにまとめておけば良かったなと反省したり…ライブラリーの添付マニュアルや(発表のスライドは書いて公開しても、ブログに書いてないものが多いなと)

というわけで、今後はもっとブログに主張を残そうと思います、はい。

五反田pm#19 楽しかったです〜

五反田pm#19 に参加してしてきました。

gotanda-pm.connpass.com

感想あれこれ

@kfly8 さんと運営の皆様お疲れ様でした! 最近では珍しく Perl の濃い話を全力で話してもドン引きされるどころか喜ばれる会で、とても有難かったです。 懇親会のお酒とお寿司も美味しかったです!モバファクさんありがとうございました!

  • 最初のコマンド行 Perl の話から質問が出て皆で答えて盛り上がりましたね〜
  • JSON 関連モジュールの知見が色々聞けて勉強になったです。
  • Perl TeX の話はびっくりしました。 TeX であそこまで出来るんですね…
  • 初心者枠からの Perl で辛い所の話も、リファレンス、コンテキストと、あー詰まるよね分かる有るある!って感じで。
  • PadWalker 登場で盛り上がるの、とても好きです〜
  • トミールさんの、Perl での経験が ErlangGolang でも色々思い出される話も良かったです〜。

私の発表

私は3月頃から書き続けてきた Language Server の発表をさせてもらいました。

hkoba.github.io

use fields の布教が少し出来たかも?しれないのが、一番の収穫だったかも? もし fields (というか our %FIELDS ) の活用法に興味が湧いた方がおられたら、 昔の吉祥寺pm7 のスライドもどうぞ〜>

https://hkoba.github.io/slides/kichijojipm7/hkoba.github.io

(うぉーogを後から変えたから展開されぬ…)

謹賀新年/2019目標

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

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

2018 の良かったこと

  • Perl方面
  • Tcl/Tk方面
  • Emacs方面
  • Linuxデスクトップ方面
    • リモート勤務者に linux notepc を支給して、開発用サーバー兼クライアントとして使ってもらう業務フローを開拓出来たこと。
      • そのための linux notepc のインストール&設定の手順をほぼ自動化出来たこと。
    • Windows ベースの開発者のための、 WSL + VcXsrv ベースの開発環境を作れたこと。
  • サーバー方面
    • イントラネット上の社内サーバーの letsencrypt 移行が出来たこと。これでようやく、社内向け WebApp を安全に作れる土台が出来たよ…
    • azure と gcp への移行実験を開始できたこと。
  • 生活面
    • ジム通いの結果、以前より体が疲れにくくなった?こと。
    • 新居の生活に順応出来たこと。

2018 の反省点

  • オレオレ言語の研究が完全にストップしたこと…(仕事は充実してた気がするものの、これでは本末転倒…)
  • それに限らず、昨年立てた目標のうち、体力づくり位しか進展が無いこと。
  • 引越し後の荷解きが、予想通り、ほとんど進まなかったこと。
  • 通勤が伸びたことにより、起床が一時間早まったこと。
  • 体の故障が増えてきたこと。時間もお金も掛かった上に、原因不明瞭で終わることが多いのが厳しい。けどそういう年齢よねと。

2019 の目標

  • 新人プログラマーさんが来てくれたら、育ってもらえるよう教育を頑張る。
  • 仕事も個人生活も gcp / gsuite に土台を移す。
    • sshcomm + tkhtml3 ベースで、gcp にも使える deploy / admin ツールを作る。 Ansible とは違う、アドホック性の強い分野に REPL + GUI でアプローチする。
    • yatt_litegcp + oauth2 サンプルを作り、その上に自分の情報生活環境を構築する。
      • 自作会計システムの Web化?
  • 荷解き→物の整理。自宅での研究開発に支障が無いように。(オレオレ言語の研究開発に戻れるように。戻れるように…)

perldebugger (perl -d) を楽に使うコツ的な話

この記事は Perl Advent Calendar 2018 の 12/4 の記事です

Perl Debugger (perl -d) を効率的に使うコツ的な話を書きます。 perl の標準デバッガなんて役に立たないと思っている人のための記事です。

TL;DR step/next は最低限に。break したい個所が予め決まっているなら、デバッグ対象コードにダミー関数の呼び出しを加える手も有る。

Perl Debugger とは

Perl Debuggerperl に標準で添付されたデバッガで、perl 起動時に -d オプションを渡すことで利用できます。使い方は一般的なデバッガとよく似ていて、

  • l 関数名 で関数のソースを表示
  • b 行番号b 関数名 で breakpoint を設定
  • c で実行を継続, s で関数の中までステップ実行, n で次の行まで実行

といった感じです。Term::ReadLine::Gnu などをインストールすると、lb で関数名のタブ補完も効くようになります。 (参考)

h で出るヘルプ画面には沢山コマンドが並びますが、 使うコマンドはそう多くはありません。よく使うコマンドに印をつけたので 参考にどうぞ。

f:id:hkoba501:20181203212405p:plain
perl debugger の help 画面(hkoba のよく使うものに青印をつけてあります)

動的にロードされるコードに breakpoint を仕込むには

そんな Perl Debugger ですが、いざバグ取りに使おうとした時に 肝心のデバッグしたい関数に breakpoint を置けなくて困ることがあります。 この問題は、Perl がその関数が定義されているモジュールをまだ読み込んでいない時に起こります。

(一応、 b load FILE コマンドを使えば、 require でファイルがロードされる所に breakpoint を仕込むことが出来る、らしいのですが、 FILE のパスの扱いで私は失敗してばかり…なので使わなくなってしまいました)

特に Plack や Mojolicious のようなフレームワークを用いた開発で、動的に読み込まれる .psgi ファイルやモジュールの中のコードをデバッガで調べたい場合に、 step/next を打ち続けて絶望する初心者も散見されます。

正攻法で行く場合

このように動的にロードされるコードをデバッグする場合、正攻法では動的ロードを行う側のコードの挙動を理解して、 step/next を打つ回数を減らすことが大事です。

手順としては、

  • そのフレームワークがモジュールの読み込みを行う関数を探し、
  • そのローダー関数に最初の breakpoint を置いて実行、
  • ローダー関数に達したら、おもむろに r で return して自分のコードを実際に読み込ませる
  • その後、自分のコードに breakpoint を置く

という流れになるでしょう。以下の例は、Mojolicious から呼ばれる startup をデバッグする流れです。

逆転の発想:breakpointを置くためだけのダミー関数を使う

ただ、上記のやり方は個々のフレームワークの内部実装に対するある程度の理解が必要になるため、 準備に時間がかかりますし、正直面倒です。

それよりも、もし breakpoint を仕込みたい個所が予め決まっていて、 かつそのコードを書き換えることが可能なケースであれば、 breakpoint を置くためだけの(中身のない)ダミー関数を使う方法が有効です。

すなわち、

  • ダミー関数の名前を決める(例えば main::breakpoint)
  • break したい個所に、そのダミー関数への呼び出しを書き入れる(ただし注意有り)
 # This method will run once at server start
 sub startup {
   my $self = shift;
+
+  main::breakpoint();

   # Load configuration from hash returned by "my_app.conf"
   my $config = $self->plugin('Config');
  • デバッガを起動
  • x sub main::breakpoint {} などしてダミー関数を定義
    • (予めプログラム内で定義しておいても良い)
  • b main::breakpoint でダミー関数に breakpoint を設定
  • c でダミー関数まで飛ぶ
  • r で該当コードに移る

この方法なら実質 c 一発で該当のダミー関数まで到達出来るため、途中のフレームワークの実装に 関する知識は実質的に不要になります。

注意点:ダミー関数を呼んだままでは本番でコケる

ただし、このままでは(ダミー関数は本番には存在しないので)、 本番で動かないコードになってしまいます。ですので、このダミー関数の存在の有無を perl$pkg->can($methodName) で確認してから呼ぶようにすると良いでしょう。

  if (my $sub = main->can('breakpoint')) {
      $sub->();
  }

手順としては、こんな感じです>

なお、自作のコードの場合は、ダミー関数の定義を正式なコードに予め含めておくほうが楽です。 その場合は main::breakpoint ではなく、もっと別の名前空間に入れる方が衝突のリスクが少なくて安全です。breakpoint だけを入れたモジュール XXX::Breakpoint みたいなものを用意しておく手も有るでしょう。

終わりに

Perl Debugger で今どきのコードをデバッグする時に困りがちな『 breakpoint を置くのが大変』問題を、breakpoint 用のダミー関数で軽減する方法について解説しました。

明日は @ytnobody さんです。