libperl-rs の話
昨年2019の夏頃から libperl-rs というライブラリを作っています(現状では仕事とは無関係の、純然たる自宅研究です。進みも間欠的です)。これは Perl5 のランタイムライブラリーである libperl を Rust から呼び出すためのラッパーライブラリーです。
libperl-rs については、これまでは YAPC Japan 2019 名古屋で発表した以外は、 これといった情報開示をしてきませんでした。
別に秘密というわけではなく、 単に blog を書くことを面倒臭がっていただけで、 github 上には 少しずつ進展を出してはいました。ですが最近、私が前もって現状を整理して公開していれば、誰かさんを困らせなくて済んだのかもなー…と思うこともあり…
ちょっと現状を整理して開示しておこうと思います。
libperl-rs の開発目標、libperl-rs で何を出来るようにしたいか
私が libperl-rs で一番やりたいことは、 Perl プログラムの AST (OP Tree) の解析です。 特に、動的に生成されるスクリプトの AST を解析し、その実行前にエラーを検出したり、 Language Server やデバッガーを提供したり…ということが出来るような道を開きたいと考えています。 (そこまでたどり着けるとは言い切れませんが…)
libperl-rs の現状
現在の libperl-rs は3つの crate から構成されています。
- libperl-config - env perl からビルド情報を取り出すためのライブラリーです。 2., 3. のビルドに用います。
- libperl-sys - env perl 付属の libperl に対する Rust binding を生成する crate です。bindgen を用いて C のヘッダーから Rust のコードを自動生成します。
- 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 版と非スレッド版の2系統が存在します。それを Rust の層で抽象化し直す必要があります。 私がまだ Rust の修行中であることもあり、一発で正解にたどり着く自信はありません。 とても API が固まったとは言えない状況です。
そのため、現在は主として examples ディレクトリーの下に 実験的なコードを書き、その中で今後 libperl-rs の本体に組み入れると良さそうなコードを eg サブディレクトリーに作り貯めている所です。 皆さんのツッコミをお待ちしております。
今の libperl-rs で出来ること
今の段階の libperl-rs で出来ることは、どれも B モジュール で (とても頑張れば)出来ることばかりだと思います。
とはいえ、OP Tree に対してパターンマッチが出来るようになりつつあることは、
少なからぬメリットなのではないでしょうか。以下は Perl のサブルーチンの冒頭から
my (...) = @_
に相当する AST を抜き出すための、パターンマッチのコードです。
(少し冗長ですが)
let ast = op_extractor.extract(cv, CvROOT(cv)); match ast { Op::UNOP(opcode::OP_LEAVESUB, _ , Op::LISTOP(opcode::OP_LINESEQ, _ , Op::COP(opcode::OP_NEXTSTATE, body), _), _) => { println!("preamble!"); match body { Op::BINOP(opcode::OP_AASSIGN, _ , Op::UNOP(opcode::OP_NULL, _ , Op::OP(opcode::OP_PADRANGE, _, _ , Op::UNOP(opcode::OP_RV2AV, _ , Op::PADOP(opcode::OP_GV, _ , Sv::GLOB { name: ref nm, .. }) , _)) , lvalue) , _) if nm == "_" => { println!("first array assignment from @_, lvalue = {:?}" , match_param_list(lvalue)); } _ => { println!("first statement is not an array assignment"); } } } _ => { println!("doesn't match") } }
他にも (perl_parse の作る) 静的な OP Tree を調べるコードだけではなく、 perl_parse 後に任意のクラスの任意のメソッドを Rust から呼び出してみるサンプルも、(まだまだベタな書き方ですし不足もありますが)動き始めています(抜粋)。
#[cfg(all(perl_useithreads,perlapi_ver26))] fn call_list_method(perl: &mut Perl, class_name: String, method_name: String, args: Vec<String>) -> Result<Vec<Sv>,String> { let mut my_perl = perl.my_perl(); // dSP let mut sp = my_perl.Istack_sp; // ENTER unsafe_perl_api!{Perl_push_scope(perl.my_perl)}; // SAVETMPS unsafe_perl_api!{Perl_savetmps(perl.my_perl)}; // PUSHMARK(SP) perl.pushmark(sp); // (... argument pushing ...) // EXTEND(SP, 1+method_args.len()) sp = unsafe_perl_api!{Perl_stack_grow(perl.my_perl, sp, sp, (1 + args.len()).try_into().unwrap())}; for s in [&[class_name], args.as_slice()].concat() { sp_push!(sp, perl.str2svpv_mortal(s.as_str())); } // PUTBACK my_perl.Istack_sp = sp; // call_method let cnt = unsafe_perl_api!{Perl_call_method(perl.my_perl, method_name.as_ptr() as *const i8, (G_METHOD_NAMED | G_ARRAY) as i32)}; // SPAGAIN // sp = my_perl.Istack_sp; // (PUTBACK) let res = stack_extract(&perl, cnt); // FREETMPS perl.free_tmps(); // LEAVE unsafe_perl_api!{Perl_pop_scope(perl.my_perl)}; Ok(res) }
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") }]
最後に
ここまで読んで下さり有難うございました。ご意見お待ちしております!
2022-03-30 追記: gist-it が死んでいてソースコード参照が動いていなかった箇所をコード埋め込みに変えました。
謹賀新年/2020目標
あけまして、おめでとうございます
旧年中に仲良くして下さった皆さん、有難うございました。 今年もどうぞよろしくお願いします。
2019 の良かったこと
- 遅まきながら、少しずつ GCP の業務投入を始められたこと。
- YATT::Lite + GCP + Google OAuth のひな型化を進められつつ有ること。 ex. Google App Engine版を作れたこと
- libperl-rs の開発経験を通して、Rust に活路を見いだせそうな予感を得たこと(まだまだ勉強中ですが…)
- その感触を YAPC::Japan 2019 名古屋 で他の Perl Monger に多少なりとも伝えられた?こと。
- マニュアルを書くためのツール、sphinx も試したけど mdbook の方が設定無しですぐにそこそこ使えて自分向きだと分かったこと。
(以前から構想していたことだけど、実際に)職場の Perl の新人教育のプロセスを -nle と .pm から始めるよう試した結果、それなりの効果を確認できたこと。少なくとも .pm から教えることは現代的には全く問題が無い。ボイラープレートは File::AddInc と M4I の CLI_JSON にまとめる方向で引き続き。
艦これアーケードの秋イベント、なんとか甲クリアを継続できたこと
2019 の反省点
- 仕事
- 生活
- ジム中断(肘の痛みが原因)
- 部屋の片付け・もの減らしが停滞している。
- 婚活進展ゼロ。50歳なので街コンも行けないのだ。
- とら婚さんにも相談してみたけど、結婚感というやつを言語化するのが大事だそうな。
2020 の目標
-nle と .pm から始める Perl 入門とかどうかしら?(後編)
-nle と .pm から始める Perl 入門とかどうかしら?(後編)
この記事は Perl Advent Calendar 2019 の 12/5 の記事です。内容は主に職場で Perl を 教える側 の人に向けた、提案です。
コマンド行からエディタ+ファイルに移る時
昨日の記事は、Perl 屋の新人教育を コマンド行ツールとしての Perl から初めてはどうかしら?という提案でした。
今日の記事は、その新人さんの教育が進んで、コマンド行では収まらず、
エディタ+ファイルを使いたい規模に進んだ時に、今までどおりに
*.pl
の書き方を教え続けるのが良いのだろうか?
いやむしろ、 コマンド行の次は即座に *.pm
の書き方を 教えては?という話です。
.pl
飛ばして、 .pm
から教えては?案
私が *.pm
の書き方から教えることをお勧めする理由は、以下の2点です。
- 仕事で Perl を書く人の場合、モジュールの読み書きは避けては通れないから。
*.pm
は*.pl
を兼ねることが出来る(後述の Modulino)が、逆は違うから。
職場にもよるでしょうが、
今の時代に Perl を書くお仕事は、新規開発よりも保守改良のお仕事の方が多いのではないでしょうか。
その保守改良では、既存の業務のコードベースのモジュール群(つまり *.pm
)を読み書きする能力が
不可欠です。だとしたら、 *.pl
を学ぶことは新人さんにとって回り道なのではないか?
という疑問があるのです。
もちろん *.pl
は *.pm
よりもプログラミングの際の決まり事が少ないのは事実です。
教育の初期において負荷は少ないほうが良いという意見も分かります。
ただ、その部分はコマンド行の Perl でカバーしても良いのではないでしょうか?
何より、新人教育期間はただ知識を吸収するためだけではなく、
トレーニングのために確保された期間でもあります。
トレーニングは今後の仕事で必要となる作業に対して、その負荷に慣れて自然に動けるように力を
成長させるためのプロセスです。最終的に職場で要求されるのが *.pm
であるなら、
その負荷に慣れるトレーニングを早めに始めることが大事なのではないでしょうか?
念のため、 *.pl
, *.pm
の長所・短所を整理してみます。
.pl
の長所・短所
*.pl
の長所*.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 入門とかどうかしら?(前編)
-nle と .pm から始める Perl 入門とかどうかしら?(前編)
この記事は Perl Advent Calendar 2019 の 12/4 の記事です。内容は主に職場で Perl を 教える側 の人に向けた提案です。
(今から仕事で Perl を学び始める人は、多分 Linux/Unix 環境に関わる人であろう、と想定しています。違ったらごめんなさい。)
初めて書く Perl は何が良い?
皆さんは職場の新人さんに Perl を教えるとき、初めにどんな形式でプログラムを書いてもらっていますか?
普通は何らかのエディタで foo.pl, hello.pl のように *.pl
ファイルを作ってもらって実行、ではないかと思います。この方法は、使い慣れたエディタが有る人には最も安心感を与える方法でしょう。
ですが、この方法には二つの弱点があるのではないでしょうか?
$_
などの特殊変数や、その省略法則(ex.デフォルトのm//
の対象、split
の第2引数、-X
テストの対象…)を教える切っ掛けが乏しい*.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 {}
を教える切っ掛けも作りやすい
この教育方法の弱点
この方法の弱点は、学習の記録を残すことが難しいことです。 学習の効果を定着させるには、学習者が学んだことを容易に振り返って復習出来ることが大事です。 しかしコマンド行は一過性の側面が大きいため、そこを不安に(不安定に)感じる人もいるでしょう。
これについては、以下の対策が有りえます。
- シェルのヒストリー機能とそのダンプ方法(
history -w, fc -W
)を初期に教える。- ヒストリーのダンプを git に保存しても良いかもしれない
- コマンド行の短縮記法を教えた後に、
B::Deparse
を使いながら冗長な(省略を廃した) 記法も教える。それをスクリプトファイルとして残し、これを git に保存する。 - いっそ script コマンド で全て記録するとか? ttyrec? asciinema?
組織を超えた教材化は難しいかも?
あとひとつ難しいかもしれないのは、コマンド行での Perl の使い方は環境(組織、文脈)に特化する面が大きく、 汎用の教材を作りにくい、かもしれないことです。例えば業務の副次的なプログラムのエラーログから 情報を抜き出して DB に投入するとか…それが一般的で頻出する問題なら、既に専用のプログラムが 作られていたり、予め構造化してログを吐くことが出来ているはずです。 (もっと良いツールがあるのに何で自分で書くの?と言われると…教える時の言い訳が増えますね…内容次第ですが…)
なので、教育のためのシナリオと、そこで使うデータセットの準備が、最も 手間取る所になりそうです。
(適切なツールが既に存在しても、それを探し出すのに何十分もかかるなら、自分でさっとスクリプトを書いたほうが早い、というケースの話も、しても良いかもしれません)
とはいえ、既存の教材も無くはないので、例えば↓この辺りから 題材を抜き出しつつ教えるのも良いかもしれません。
あと、同じくフィルタに向いた言語のご先祖様であるプログラミング言語AWKの本からも例題を拾えるかもしれません。
- 作者:A.V.エイホ,P.J.ワインバーガー,B.W.カーニハン
- 出版社/メーカー: USP研究所
- 発売日: 2010/01/01
- メディア: 単行本(ソフトカバー)
まとめ
Perl 屋の新人教育、最初はコマンド行の Perl から初めてはどうかしら?という提案でした。
では、学んだコードをファイルにしたくなった時、 *.pl
に入れるのが良いのだろうか?
いやむしろ、最初から *.pm
で学ぶと良いのでは?
そういう話を明日の後編記事に書きます。
odc2019 聞きに行ってきました
odc2019 (オープンデベロッパーズカンファレンス) に初めて行ってきました。非常に勉強になりました!
聞けたトーク
(本当は朝から行きたかったのですが、うっかり宅配便の受け取り予定を入れてしまって…お昼からに…)
日本語入力の危機を乗り越える インプットメソッド・フレームワークとかな漢字変換に訪れている課題とその対策
私も 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 ~ 手軽にスピーディに継続的に保守するためのドキュメント入門~
資料公開しました。
— HATANO Hirokazu (@tcsh) 2019年8月24日
運用ドキュメント2019 〜 手軽にスピーディに継続的に保守するためのドキュメント入門https://t.co/joEp2YCkQx
#opendevcon
私も職場での運用手順や開発関連のドキュメントをどう構築管理するのが良いか悩んでいるので聞きに行きました。非常に耳に痛い、有益な主張がてんこ盛りでした。流石にそこを本業にしている人は切れ味が鋭いなぁと。
そもそも運用ドキュメントとは何のためのものか?からストーリーが組まれていたので、議論について行きやすかったのも有難かったです。
#opendevcon pic.twitter.com/qQ1KmttBsO
— Shinji Enoki (@eno_eno) 2019年8月24日
運用ドキュメントのレベル
— Miyahan (@miyahancom) 2019年8月24日
Lv0.記録: 事実であること(言語化)
↓
Lv1.整理: 論理的に正しいこと(論理化) → 知る
↓
Lv2.客観化: 客観的であること(抽象化) → 説明する
↓
Lv3.脱属人化: 再現性があること(具体化) → 永続化#opendevcon
運用ドキュメントのレベル
- Lv0.記録: 事実であること(言語化)
- Lv1.整理: 論理的に正しいこと(論理化) → 知る
- Lv2.客観化: 客観的であること(抽象化) → 説明する
- Lv3.脱属人化: 再現性があること(具体化) → 永続化
刺さったスライドを挙げていくと切りがないですが…
「運用業務をドキュメント化しないと、会社として、無い仕事にされる」(忙しそうだけど、何してるのか分からない、になる。 Job Description 化のススメ)
- 一方日本は「聞き手責任」 分からないやつが悪い…
スライドに無い話も非常に興味深かったです。
- 35歳の壁の話(固有名詞が出てこなくなる)とか。←言われてみれば自分もそうだったかも!
- 運用ドキュメントを即興 shell script で組み立てる(組み立てられるように、パーツとなる文書を貯めていく)という話も驚きでした。
- そして↑そういう事をするには sphinx が適している(というか include が大事)とのこと。やっぱりそうですか… (mdBook とかでも行けるかしら?)
懇親会も楽しかったです
libreoffice の方や opensuse の方が同テーブルでした。unix/linux の話が普通に出来るのは、やはり有り難いですね。(Windows や Mac が支配的な世界だと、ちょっと肩身が狭くて…) (迷惑だったかもですが)私が仕事先のチームで何故 XWindow の業務環境を維持しているのかという話も聞いてもらえて。 前田薫さんにも Runnable Module + JSON CLI や自作テンプレートエンジンの話を聞いてもらったり。逆に TypeScript/Go/Python の書き味の比較の話を聞かせてもらったり。
他人に説明する過程で自分がその立ち位置を選んだ理由を明確化できるので、こういう対話の機会はやはり有り難いです。そして、自分の主張を予めブログにまとめておけば良かったなと反省したり…ライブラリーの添付マニュアルや(発表のスライドは書いて公開しても、ブログに書いてないものが多いなと)
というわけで、今後はもっとブログに主張を残そうと思います、はい。
五反田pm#19 楽しかったです〜
五反田pm#19 に参加してしてきました。
感想あれこれ
@kfly8 さんと運営の皆様お疲れ様でした! 最近では珍しく Perl の濃い話を全力で話してもドン引きされるどころか喜ばれる会で、とても有難かったです。 懇親会のお酒とお寿司も美味しかったです!モバファクさんありがとうございました!
- 最初のコマンド行 Perl の話から質問が出て皆で答えて盛り上がりましたね〜
- JSON 関連モジュールの知見が色々聞けて勉強になったです。
- Perl TeX の話はびっくりしました。 TeX であそこまで出来るんですね…
- 初心者枠からの Perl で辛い所の話も、リファレンス、コンテキストと、あー詰まるよね分かる有るある!って感じで。
- PadWalker 登場で盛り上がるの、とても好きです〜
- トミールさんの、Perl での経験が Erlang や Golang でも色々思い出される話も良かったです〜。
私の発表
私は3月頃から書き続けてきた Language Server の発表をさせてもらいました。
use fields
の布教が少し出来たかも?しれないのが、一番の収穫だったかも?
もし fields (というか our %FIELDS
) の活用法に興味が湧いた方がおられたら、
昔の吉祥寺pm7 のスライドもどうぞ〜>
https://hkoba.github.io/slides/kichijojipm7/hkoba.github.io
(うぉーogを後から変えたから展開されぬ…)
謹賀新年/2019目標
明けまして、おめでとうございます
仲良くして下さった皆様、ありがとうございました。また今年もよろしくお願いします。
2018 の良かったこと
- Perl方面
- CLI_JSON を複数の業務で実戦投入して有効性を確認できたこと。 その実用性を更に向上させられたこと。
- 言語処理系勉強会 で yatt_lite の発表をさせてもらえたこと。
- Tcl/Tk方面
- tktable と tkhtml3 を fedora の copr に出せたこと。 これで yum/dnf でどこでも tkhtml3 をインストール可能になった。
- Emacs方面
- Emacs で Language Server を使うための lsp-mode に対して、それを自分流に活用するための道具 https://github.com/hkoba/emacs-on-save-jump-to-lsp-error を作れたこと (スライド)。(これで安心して typescript の開発に進める、はず…)
- Linuxデスクトップ方面
- サーバー方面
- 生活面
- ジム通いの結果、以前より体が疲れにくくなった?こと。
- 新居の生活に順応出来たこと。
2018 の反省点
- オレオレ言語の研究が完全にストップしたこと…(仕事は充実してた気がするものの、これでは本末転倒…)
- それに限らず、昨年立てた目標のうち、体力づくり位しか進展が無いこと。
- 引越し後の荷解きが、予想通り、ほとんど進まなかったこと。
- 通勤が伸びたことにより、起床が一時間早まったこと。
- 体の故障が増えてきたこと。時間もお金も掛かった上に、原因不明瞭で終わることが多いのが厳しい。けどそういう年齢よねと。