先日、2017-03-04(土)に、YAPC::Kansaiにゲスト スピーカーとしてお招きに預かりました。
 私はなにしろハッカー コミュニティに不案内で、初対面の方ばかりのなか、緊張するかと思っていたのですが、みなさん温かい方々ばかりで、大変楽しく、刺激的な時間を過ごしました。
 いずれ、大阪での思い出、YAPCで印象に残ったこと、さまざまな方との出会い、他の方のプレゼンで勉強になったことなども、おいおい狂ったようにブログにまとめようかと思っていますが、何しろ「前夜祭の前の日、勝手に前乗りして行ったホルモン焼きの話」から書かなければならないと思っているので、それだといつ終わるかわからないし、なかなかPerlの話が出てこなくてイライラされる方もいると思いますので、ここでは自分が行ったプレゼン「実録!『すぐわかるPerl』〜社内ツール悲喜こもごも〜」について解説しようと思います。

 PowerPointのファイル(.pptx)自体は、以下に公開しました。

 実録『すぐわかるPerl』〜社内ツール悲喜こもごも〜

 こちらでは、スライドをめくりながら補足した話や、質疑応答、その他を補足します。全部で66スライドあるので、暇で暇でしょうがないときに読んで下さい。


スライド01
1: まずはタイトルですが、『すぐわかるPerl』という本を書きながら、ぼくが会社でPerlを使ってどーゆー作業をしていたかという気持ちで書きました。
スライド02
2: 連絡先を晒しました。SNSでは技術的なことは書いてないですが、みなさんよろしかったら絡んでください。
スライド03
3: ここから怒涛のCMコーナーです。1999年のこの本、会場にいる多くの方が読んでくださっていて感激しました。

スライド04

4: 私がLTで最も感銘を受けた(=笑った)まかまかさんが懇親会でこの本を読んでくださっていたと聞き、感激しました。

スライド05
5: この本にDanKogaiさんがブログで素晴らしいレビューをしてくださったことが私の人生の支えになっています。Danさんともご挨拶できて良かった〜

スライド06
6: この本の献本分が家に8冊あったので、プレゼントに提供しました。8人以上の方に希望していただいてよかったです。

スライド07
7: 「作業の省力化の省力化」などと言っても、メタプログラミングとか難しい話をするわけではありません。要はいかにプログラミングの手を抜くかという話。

スライド08
8: 1995年に入った会社はソフトハウスだったのですが、業務内容が翻訳中心に変わり、一部プログラマーは退職しましたが私は残り、レビューアーやPM業務の傍ら社内ツールを書いていました。
スライド09
9: Sprintって知ってますか。私はよく知りません。
スライド10
10: これ、UNIXの標準の開発体制ですよね。私は無知で、awkも、sedも、shも知らず、しかも、微妙にそれぞれ似ているのが弱りました。
スライド11
11: この会社はいい会社で、動物の本が読み放題、勉強し放題だったのが助かりました。
スライド12
12: まったく偶然なのですが、Larryさんがそのときの私に、個人的にメッセージをくれたように思ったのでした。その結果、先輩が作ったawkやshのスクリプトを少しPerlに移植し、リファクタリングして、その会社にも馴染んだのでした。
スライド13
13: これは私見による分類です。どれが上でどれが下ということもありません。私の考えでは、第3段階、第4段階は語り尽くされている。第1段階は、開発者であれば無意識にやっている。問題は、第2段階が十分供給されてないことじゃないかと思うんです。
スライド14
14: ではいよいよ一般的な話に入ります。
スライド15
15: テンライナーというのはワンライナーをもじった造語です。
スライド16
16: ワンライナーをヒストリにいっぱい貯めていて「先月やったあのワンライナーが良かった」とか言っている人がいるそうです。これはDanさんのブログをネタにしましたw
スライド17
17: 環境はMac+El Capitan+Emacs+シェルモードです。前夜祭でエディター戦争の話がありましたが、ぼくはEmacsを気に入っています。Emacsは最強のエディターという意味らしいです。「いいMAX」なんてなあ(ヤヤウケ)。ちなみに、前夜祭でエイリアス芸の話もありましたが、ぼくはEmacsで日本語の文章を書いていてあまりにも「M-x しぇ」と間違って打ってしまうので、これでシェルが起動するようにエイリアスを作っています(ヤヤウケ)。

スライド18
18: スライド16のワンライナーを、10行に書き伸ばすと、なんとなくやっていることが分かる、ということです。
スライド19
19: さらに書き伸ばして汎用的なツールにします。use strictとuse warningsは必ず入れるようにしています。
スライド20
20: このスクリプトのキモはFile::Basename::fileparseという関数ですが、使い方が木本さんの「サンプルコードによるPerl入門」に詳述されていたのでコメントに貼らせてもらいました。
スライド21
21: 正規表現がたまにメールで送られてきます。これを使えばいいよ、という。で、動かしてみると、動かない。そういうときどうするかの話です。
スライド22
22: /xスイッチを使って空白と注釈を入れるだけでもグッと読みやすくなります。本当に空白を書くときはエスケープする必要があります。
スライド23
23: 実際にはまだヌルさが足りないのでもっと書き伸ばします。まず__DATA__を読み込むテスト ドライバーを作ります。
スライド24
24: ここが正規表現の本体です。サブルーチンis_creditは、真偽値コンテキストで評価すると正しいクレジットカードかどうかを返す、文字列コンテキストで評価するとクレジットカードの会社名を返す関数として使えます。
スライド25
25: ありがちなカード番号もためておきます。
スライド26
26: ゆるふわで書いているとメンテもカンタンです。
スライド27
27: ブワーッとした正規表現を誰が送ってくるのか。ブワーッとした正規表現が来てもPerlで書き伸ばせば簡単にメンテできるようになります。
スライド28
28: TMTOWDIは"There's More Than One Way To Do It."の略で、「やり方はひとつじゃない」というPerlのスローガン。ぬるハッカーに生存権があるw
スライド29
29: このミソグラという言葉が受けたっぽくて嬉しかったです。
スライド30
30: 大きなアプリを開発する時、新しい機能を追加します。そのとき、大きなアプリをメンテするだけじゃなくて、新機能のテストだけのためのテンライナーも作って、手元に置いておけばいいんじゃないかという提案です。
スライド31
31: このテンライナーは、できればデータ付き完動サンプルにすると便利です。なお、質疑応答で、ぼくの味噌蔵は何個ぐらいプログラムがあるかと聞かれて、咄嗟に200個って答えましたが、そんなはずはないですね。20000個ぐらいかもしれません。ただ、プレゼンのとき使ってたMacに入っていた、最近比較的良くかき混ぜている、腐ってない味噌が200個ぐらい? という意味でした。
スライド32
32: この「かな漢字逆変換」は後でちょっと実用的な使い方が出てきます。
スライド33
33: モジュールにはシノプシスがついているが、コード スニペットのことが多い(それでいい)。
スライド34
34: でも、ユーザー側で、テンライナーに書き伸ばして、ちゃんと動作させると、ちゃんと使えるという確信が得られ、味噌蔵が充実するので、いいのではないか。他に、ラクダ本、Effective Perl、Perl Cookbookなどの本に出てくるスニペットをテンライナー化するいいです。ただ本を読んでいると、ついつい読み飛ばしてしまい、いつの間にか眠くなってしまうw
スライド35
35: 特定のアプリをディスっているわけではありませんw
スライド36
36: これは「Team-A」という固定文字列を含む行を抽出するプログラムです。

 プレゼンでは、ちょっとしたライブ コーディングもどきを行いました。
 *Team-Kを抽出するにはどうするか。その場合Team-Aを抽出する行をコピペして、前の行はコメントとして取っておくといい
 *単純に /Team-K/ と書くとTeam-KIIまでマッチしてしまう。その場合もこういう正規表現で失敗したという事例をコメントで取っておくといい
 *デバッグするには /Team-K\b/とか書く。この時点で自分の正規表現の勉強の歴史とか、失敗の歴史が残る。これが資産になるのでは、みたいな話

スライド37
37: 1999年の『すぐわかるPerl』では人名のデータに「SPEED」の人を使っていたんですが、2016年の『かんたんPerl』ではAKB48に対応しました(ヤヤウケ)。上記の /Team-K/ のバグは、16位の須田亜香里さんまで入れないと出てこないわけで、ある程度現実味のあるデータを、ある程度大量に食わせないと、テストにならないんじゃないかなーと愚考します。
スライド38
38: 会社でツールを開発している「WordやExcelのデータを扱うプログラムを書いてください」と言われる。それだけならいんですが「VBAを使って書いてください」とも言われます。やなこった。その対処法。
スライド39
39: 真ん中の竹の部分を羅宇(らう)と言うそうです。
スライド40
40: お客さんからもらったWordのデータとします。
スライド41
41: 簡単なWord文書ですが、バイナリーなので、Wordを使わないと開けません。もっとも、今のWordの.docxというファイルは、実はzipファイルで、回答するとEPUBみたいにディレクトリー構造があって、中にXMLが入っているんですが、ここではそれを直接処理する方法は取りませんでした。
スライド42
42: docxからXMLにエクスポート、および、XMLからdocxにインポートするVBAマクロを開発します。開発だけならまだいいんですが、これを配布するのが結構たいへんです。ぼくがとっているのは、.docm(マクロ実行可能ドキュメント)ファイルにマクロをアタッチして、その文書を配ることです。文書には使い方のインストラクションの他に、マクロを起動するフォーム ボタンを付けます。これはお手軽でおすすめ。
スライド43
43: Wordの「名前をつけて保存」(SaveAs2)を使って、docxをXMLに保存するVBAです。どこかからもらってきたものですが、ファイルが100個限定でちょっとダサいですね。もらってきておいてひどいですが。。
スライド44
44: エクスポートが終わって、XMLが5つできました。
スライド45
45: XMLを開いたところです。こうなると好き放題にいじれると思います。
スライド46
46: スライド43の逆で、XMLをdocxに名前をつけて保存します。
スライド47
47: これでハンドオフされたdocx、中間的なXML、納品するdocxのセットができました。
スライド48
48: 次はお墓方式です。これはぼくが考えた名前だと思いますが、似たようなことは各所で行われていると思います。スクリプトがなくなっているので、概念だけの説明で失礼します。
スライド49
49: 英文を日本語に翻訳するというプロジェクトを考えます。索引が{XE}フィールドという隠し文字に入っています。
スライド50
50: 索引をビルドすると英語順に並びます。
スライド51
51: 原文と同時に索引項目を単純に翻訳してしまいました。
スライド52
52: 索引が文字コード順になってしまいました。ちなみに、ぼくはこういう「索引が文字コード順になった本」を町で見たことがありますが、あってはならないと思います。索引はよみがな順であるべきです。
スライド53
53: Wordの{XE}フィールドによる索引の場合は、\yスイッチというものを使い、{XE "漢字" \y "よみがな}という書式で読みがなを入れることができます(yはよみがなのことだと思います)。ここでは、読み仮名の漢字まで入れたという前提で、\yスイッチをはさんでよみがなを入れる工程を自動化したいとします。
スライド54
54: まず、VBAのスクリプトで、{XE}フィールドを検索して、漢字を抽出します。この時、単純に抜き出しただけだと戻すのが大変なので、★1★、★2★…というタグを代わりに残して行きます。これを「お墓」と読んでいます。(実際のスクリプトはもう残っていず、現状お見せできません。スミマセン!)
スライド55
55: 上のスライドと同じVBAを使って、抽出した漢字と対応するお墓をタブ区切りテキストに抽出します。
スライド56
56: これに、スライド32で紹介したText::Kakasiを応用したPerlの漢字かな逆変換スクリプトを応用してよみがなをタブ区切りで追加します。
スライド57
57: さきほどのVBAと逆のスクリプトを使ってテキスト ファイルの「★n★ -> 漢字 -> よみがな」という行を読み込み、★n★というお墓を「漢字 \y よみがな」に置換します。
スライド58
58: よみがなが入った状態で索引を作ると、きちんとあいうえお順になりました。やったー
スライド59
59: これで分かるのは「ツールを作ると作業が合理化し、フローを改善することができる」ということです。
スライド60
60: 社内ツールの社会学 a.k.a. グチのコーナーw
スライド61
61: 汎用の(市販の)GUIアプリの作業手順書を書くのは超大変です。xxメニューを開いてxxボタンを押して、とか書いて。。スクリーンショットとか撮って。。だんだん「できるシリーズ」を編集してるみたいになります。で、2年もすればすぐ陳腐化してしまいます。
スライド62
62: エンドユーザーにとっても、重厚長大なGUIアプリを起動して複雑なメニューを使うより、軽量のスクリプトを使うだけの方がラクチンな場合があります。同じ会社に開発者がいるので、要望してくれればすぐにパワーアップできます。コマンドラインが使えるようになれば、エンドユーザーにも損はないはず。
スライド63
63: エンドユーザー(実作業者)は社内ツールのテストを業としているわけではないので、いろいろ問題が起きます。社内ツールは開発技術と同じぐらいコミュ力が重要だと思います。(そのことにもっと早く気づくべきだった。。)
スライド64
64: 63の裏返しです。開発者側からグチを述べるようなセッションになってしまいましたが、逆にぼくが人に迷惑を掛けている面もあったでしょう。
スライド65
65: せっかく会社で、協働しているわけだから、お互いの個性を生かして、リスペクトし合っていけば、努力せずに生産性を上げることができるのではないか。
スライド66
66: ヌルいスピーチでスミマセンでした!


 とりあえずパワポの解説だけでいったん失礼します。何かあったらTwitter、Facebook、メールでお知らせ下されると幸いです。お聞きくださったみなさん、本当にありがとうございました!