hkoba blog

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

シングルサーバーの管理自動化に、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 の重要な機能である、変数をコマンド行からオーバライドする機能が欲しい気がするが、どんな実例を書こうか

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

Modulino + OOPの提案 - CLIからオブジェクトと遊ぼう

perl

この記事は *.pm による Perl のクラス定義を CLI から直接的に試せるようにする開発技法の提案・解説です。

はじめに

Perl のモジュールを CLI コマンドとしても使えるようにする手法は Modulino (モジュリーノ＝コマンドとしても実行可能なモジュール) と呼ばれます。この記事では私が長年探求してきた Modulino を OOP と組合せて Perl 開発に役立てる方法の、最も基礎となる部分について解説します。 （OO Modulino 技法とでも言いましょうか）

要約すると

  • クラス定義を Modulino にし、CLIから起動できるようにしておく
  • CLI へのサブコマンドをメソッドに対応付けて dispatch する
  • CLI への posix 風オプション(--name=value) を new の引数にする

というアプローチが良いという考えです。

復習: Modulino（モジュリーノ） とは

Modulino とは、 Perl の正当なモジュールファイルであり、 なおかつ端末からコマンドとして実行することも出来るような .pm ファイルのことです。

例えば以下のような（Modulino ではない）普通のクラス定義モジュールファイル A.pm を考えます。 （ここでは説明を簡略化するため use strict; use warnings; を省略します。）

package A;
sub new  { my $class = shift; bless +{@_}, $class }
sub hello { my $self = shift; join " ", "Hello", $self->{name} }
1;

これをコマンド行から試すには、こう書く必要があります。

% perl -I. -MA -le 'print A->new(name => "world")->hello'
Hello world
%

そこそこ長いですね。初心者に打たせるのは厳しい感じですし、 Perl に慣れた人でも少しダルく感じるのではないでしょうか。

これを Modulino に書き換えてみましょう。 unless (caller) という見慣れない構文が鍵となります。

#!/usr/bin/env perl
package A;
unless (caller) {
  # コマンド行から呼ばれた時にしたい処理をここに書く。例えば…
  print A->new(name => shift)->hello, "\n";
}
sub new  { my $class = shift; bless +{@_}, $class }
sub hello { my $self = shift; join " ", "Hello", $self->{name} }
1;

これなら、コマンド行から即座に実行できます。 ファイル名に shell の補完も効きますし。

% chmod +x A.pm
% ./A.pm world
Hello world

また、perlデバッガーを呼び出したい時も頭に perl -d を付けるだけです。余計なコーディングは不要です。

% perl -d ./A.pm world

OOP なモジュールの unless caller には何を書くと便利か

サブコマンドをメソッドに

先程の A.pm は unless caller ブロックで A->hello を直接呼び出していました。

しかし大抵のクラスのオブジェクトは複数のメソッドを持つでしょう。 他のメソッドを試したい時は、やはり CLI に長いコマンドを書く必要が生じます。

% perl -I. -MA -le 'print A->new(name => "world")->goodnight'

なら git のようにサブコマンドを取ることにして、 それをメソッド名として解釈してはどうでしょう？つまり unless caller ブロックに第一引数に基づく dispatch 処理を組み込むのです。 （引数不足のエラー処理は省略します）

unless (caller) {
  my $self = A->new(name => "world");
  my $cmd = shift;  # CLI の第一引数をメソッド名に使う
  print $self->$cmd(@ARGV), "\n";
}

これで任意のメソッド名を呼び出すことが出来ます

% ./A.pm goodnight
Good night world

posix long オプションを new の引数に

任意のメソッドを呼び出すことは出来るようになりました。…けど、まだ不満が有りますね？ そう、new の引数が name => "world" に固定なのです。これもコマンド行から変更可能にしたい。

これも git のように、サブコマンドの前の --name=value スタイルの引数列を全て new に渡すようにしては どうでしょう？

unless (caller) {
  # CLI から渡された --name=value 形式の引数を全て new に渡す
  my $self = A->new(name => 'world', _parse_posix_opts(\@ARGV));
  my $cmd = shift;
  print $self->$cmd(@ARGV), "\n";
}

sub _parse_posix_opts {
  my ($list) = @_;
  my @opts;
  while (@$list and $list->[0] =~ /^--(?:(\w+)(?:=(.*))?)?\z/s) {
    shift @$list;
    push @opts, $1, $2 // 1;
  }
  @opts;
}

これで new の引数も CLI から制御できるようになりました。

% ./A.pm hello
Hello world
% ./A.pm --name=Perl hello
Hello Perl

まとめ

Perl のクラス定義に unless (caller) ブロックを加えて、 オブジェクトの挙動をコマンド行から簡単に試せるようにする技法の基礎について 解説しました。

OO Modulino には他にも

  • Modulino の @INC 調整に FindBin を使った場合に起きる問題とその対処法
  • オブジェクトのメンバー変数を use fields で宣言しておき、メソッドの引数宣言を my TYPE $self のようにクラス名も書くことで、メンバー変数の typo をコンパイル時に検出する
    • 加えて new 時に fields::new($class) を使うことで、不正なオプションを渡されても実行時エラーにする
  • メソッドの戻り値は Data::Dumper や JSON を使ってシリアライズして出力する
    • CLI 専用に作ったメソッドと一般のメソッドを区別できるよう、 cmd_ などのメソッド名接頭辞を予め決めておく。
  • CLI の引数に {..} [..] が現れた場合は JSON として扱う
  • ./A.pm <TAB> でメソッド名やオプション名を補完する zsh completer

などの発展的な話題があります。それらを全て盛り込んだベースクラス MOP4Import::Base::CLI_JSON の話も、機会が有れば書いてみたいと思います。

また、新人教育に Modulino を取り入れる方法のメリットについてはこちらの記事も参考にどうぞ＞
-nle と .pm から始める Perl 入門とかどうかしら？（後編） - hkoba blog

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

libperl-rs の話

perl rust

f:id:hkoba501:20200329224058p:plain
Rustだからカニを貼ってみた

昨年2019の夏頃から libperl-rs というライブラリを作っています（現状では仕事とは無関係の、純然たる自宅研究です。進みも間欠的です）。これは Perl5 のランタイムライブラリーである libperl を Rust から呼び出すためのラッパーライブラリーです。

github.com

libperl-rs については、これまでは YAPC Japan 2019 名古屋で発表した以外は、 これといった情報開示をしてきませんでした。

hkoba.github.io

別に秘密というわけではなく、 単に blog を書くことを面倒臭がっていただけで、 github 上には 少しずつ進展を出してはいました。ですが最近、私が前もって現状を整理して公開していれば、誰かさんを困らせなくて済んだのかもなー…と思うこともあり…

ちょっと現状を整理して開示しておこうと思います。

libperl-rs の開発目標、libperl-rs で何を出来るようにしたいか

私が libperl-rs で一番やりたいことは、 Perl プログラムの AST (OP Tree) の解析です。 特に、動的に生成されるスクリプトの AST を解析し、その実行前にエラーを検出したり、 Language Server やデバッガーを提供したり…ということが出来るような道を開きたいと考えています。 （そこまでたどり着けるとは言い切れませんが…）

libperl-rs の現状

現在の libperl-rs は３つの crate から構成されています。

  1. libperl-config - env perl からビルド情報を取り出すためのライブラリーです。 2., 3. のビルドに用います。
  2. libperl-sys - env perl 付属の libperl に対する Rust binding を生成する crate です。bindgen を用いて C のヘッダーから Rust のコードを自動生成します。
  3. libperl-rs - libperl-sys の機能を Rust らしく扱えるようにするためのラッパーライブラリーです。
%  tree -L 2
.
├── Cargo.lock
├── Cargo.toml
├── LICENSE
├── build.rs
├── examples
│   ├── 000_perl_parse.rs
│   ├── 001_perl_parse_args.rs
│   ├── 100_scan_ops.rs
│   ├── 101_scan_ops_debug.rs
│   ├── 102_padname_type.rs
│   ├── 103_scan_op_tree.rs
│   ├── 104_enum_op_tree.rs
│   ├── 105_scan_stash.rs
│   ├── 106_scan_allpackage.rs
│   ├── 107_scan_subs_in_a_file.rs
│   ├── 108_scan_subs_in_a_file2.rs
│   ├── 109_scan_subs_intro1.rs
│   ├── 110_call_method.rs
│   └── eg
├── libperl-config
│   ├── Cargo.lock
│   ├── Cargo.toml
│   └── src
├── libperl-sys
│   ├── Cargo.lock
│   ├── Cargo.toml
│   ├── LICENSE
│   ├── build.rs
│   ├── examples
│   ├── script
│   ├── src
│   └── wrapper.h
├── release.toml
├── runtest-docker.zsh
├── src
│   ├── lib.rs
│   └── perl.rs
└── target
    ├── debug
    └── rls

現状では 1., 2. については API はほぼ安定しているのではないかと思います。（改良の余地は有るかもしれません）

問題は 3. の libperl-rs です。 2. のbindgen によって生成された libperl-sys は Perl の C API からマクロを取り去った、裸の API です。しかも threaded 版と非スレッド版の２系統が存在します。それを Rust の層で抽象化し直す必要があります。 私がまだ Rust の修行中であることもあり、一発で正解にたどり着く自信はありません。 とても API が固まったとは言えない状況です。

そのため、現在は主として examples ディレクトリーの下に 実験的なコードを書き、その中で今後 libperl-rs の本体に組み入れると良さそうなコードを eg サブディレクトリーに作り貯めている所です。 皆さんのツッコミをお待ちしております。

今の libperl-rs で出来ること

今の段階の libperl-rs で出来ることは、どれも B モジュール で (とても頑張れば)出来ることばかりだと思います。

とはいえ、OP Tree に対してパターンマッチが出来るようになりつつあることは、 少なからぬメリットなのではないでしょうか。以下は Perl のサブルーチンの冒頭から my (...) = @_ に相当する AST を抜き出すための、パターンマッチのコードです。 (少し冗長ですが)

他にも (perl_parse の作る) 静的な OP Tree を調べるコードだけではなく、 perl_parse 後に任意のクラスの任意のメソッドを Rust から呼び出してみるサンプルも、（まだまだベタな書き方ですし不足もありますが）動き始めています（抜粋）。

libperl-rs の試し方

現段階では github の master を試して頂くのが良いと思います。(crates.io にあるものは、YAPC Japan 2019 名古屋の 時のバージョンです。それ以後の改良部分を crates.io に送るのは、もう少し API が固まってからが良いのかなと…)

私自身の開発環境は Fedora 30 ＋ System Perl (perl5.28) + System Rust (1.42) ですが、 travis-ci 上では Perl 公式 Docker イメージを用いて Perl 5.30〜5.22 での動作を確認してあります。 (発展的な例は threaded build な Perl5.26以上限定です) (libperl-sys までなら、もっと古い Perl でもビルド出来そうな気がします)

ですので、Debian, Ubuntu の上であれば以下の手順で動かしてみることは可能でしょう＞

準備
    apt update &&
    apt install -y llvm-dev libclang-dev clang &&
    curl --proto "=https" --tlsv1.2 -sSf https://sh.rustup.rs > rustup.sh &&
    sh rustup.sh -y &&
    source $HOME/.cargo/env &&
    rustup component add rustfmt

git clone https://github.com/hkoba/libperl-rs && cd libperl-rs
実行

examples/109_scan_subs_intro1.rs を実行してみる（渡したスクリプトの namespace から my (...) = @_ 形式の引数宣言だけを抜き出すサンプル)

% Z-chtholly(pts/2)% cargo run --example 109_scan_subs_intro1 -- -le '
package Int; 
sub foo { (my Int $x, my Int $y) = @_; $x + $y }
'
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/examples/109_scan_subs_intro1 -le '
package Int; 
sub foo { (my Int $x, my Int $y) = @_; $x + $y }
'`
$0 = "-e"
sub "foo"
preamble!
first array assignment from @_, lvalue = [PadNameType { name: Some("$x"), typ: Some("Int") }, PadNameType { name: Some("$y"), typ: Some("Int") }]

最後に

ここまで読んで下さり有難うございました。ご意見お待ちしております！

謹賀新年/2020目標

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

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

2019 の良かったこと

  • 遅まきながら、少しずつ GCP の業務投入を始められたこと。
  • libperl-rs の開発経験を通して、Rust に活路を見いだせそうな予感を得たこと（まだまだ勉強中ですが…）
  • マニュアルを書くためのツール、sphinx も試したけど mdbook の方が設定無しですぐにそこそこ使えて自分向きだと分かったこと。

  • （以前から構想していたことだけど、実際に）職場の Perl の新人教育のプロセスを -nle と .pm から始めるよう試した結果、それなりの効果を確認できたこと。少なくとも .pm から教えることは現代的には全く問題が無い。ボイラープレートは File::AddInc と M4I の 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 の書き方から教えることをお勧めする理由は、以下の２点です。

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

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

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

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

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

.pl の長所・短所

  • *.pl の長所
    • コマンド行の Perl で学んだこととのギャップが無い
    • ファイル名に制約が無い （拡張子が .pl である必要すら、無い）
    • #!/usr/bin/perl に Perl のコマンド行オプションを書ける（制限有り）
  • *.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.pm に use strict; use warnings が無いことを見て、 凍りついた人もいるかもしれません。業務に耐えるレベルのモジュールを書ける人になってもらうためには、 勿論、避けて通れない話です。この点は教育課程の練りどころで、私も現在、研究の最中です。 皆さんと情報交換していけたら有り難いです。

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

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

まとめ

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

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

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

-nle と .pm から始める Perl 入門とかどうかしら？（前編）

perl linux

-nle と .pm から始める Perl 入門とかどうかしら？（前編）

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

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

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

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

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

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

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

そして何より、 今さら、 Perl を学ぶメリット を語る力が弱いのではないか？と私は思うのです。 1990年代ならともかく、現代では Perl は Python, 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 聞きに行ってきました

linux xwindow

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

www.ospn.jp

聞けたトーク

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

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

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

  • これまでは GUI ツールキットと日本語入力フレームワークの組合せは GTK_IM_MODULE や QT_IM_MODULE を通して選択可能だった。 xim / uim / ibus / fcitx …
  • 今後は Gtk4 や Qt5? 等々が直接 ibus を話す方向に進んでいる、とのこと。ibus (protocol? api?) がデファクト標準化しつつある模様。
  • 最新の Debian で Gnome が 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 の話が普通に出来るのは、やはり有り難いですね。(Windows や Mac が支配的な世界だと、ちょっと肩身が狭くて…) （迷惑だったかもですが）私が仕事先のチームで何故 XWindow の業務環境を維持しているのかという話も聞いてもらえて。 前田薫さんにも Runnable Module + JSON CLI や自作テンプレートエンジンの話を聞いてもらったり。逆に TypeScript/Go/Python の書き味の比較の話を聞かせてもらったり。

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

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