Markdownの文章をHTML化して同ネットワーク内の別デバイスから見られるようにするまで

普段、日本語文章による原稿はMacVimで書いてるのだけど(といっても日本語以外の文章は書いてないので「すべての原稿」と言うべきかもしれないが)、最近めずらしく原稿をMarkdown形式で納品する機会があったので、それに関連するハック。

前提

第一に、ぼくが普段Markdownで文章を書く場合、HTMLにレンダリングするということはほとんどない。

というのも、ぼくがMarkdownを使うとしたらそれは文章の「構造化」のためであって、「見栄え」のためではないから。

もう少し具体的に言うと、これは3月のYAPC::Okinawaの発表でもけっこう説明したのだけど、

(この動画の21分9秒ぐらいから。一応そこから始まるはず)

www.youtube.com

画像にするとこんな感じで、

gyazo.com

これはこれでちょっとわかりづらいんだけど、ようは左カラムにあるMarkdown形式の文章のうち、「#」や「##」で始まる見出し部分だけが右のサイドバーに列記されている。

で、これはVimプラグインのtagbarとか、ctagsの設定などを組み合わせて実現しているんだけど、この辺の作り方については上記の動画でも紹介したとおり、以下のSoftware Design誌で @mattn さんが詳しく説明していたのを参考にしてる。

これの何がいいかっていうと、左の文章全体の構造が、右の見出し一覧を見るだけで大体つかめるということ。

右の方をちょっと眺めれば、わざわざ文章全体を上に下にとスクロールしなくても、どの見出しの前後にどんな見出しがあるか、みたいな大まかな流れがわかる。

ちなみに、この画像にあるのはscholaという音楽全集の企画で「ロマン派音楽」を扱ったときのテキストだけど、クラシック音楽のビッグネームであるところのワーグナーやリストやブルックナーといった人たちの当時のリアルな関係、とくには時系列的なつながりが、素人にはなかなか把握できない入り組み方をしていて、作業の終盤に入っても「あの話題はあの話題より先だっけ、後だっけ・・」みたいな整理がつきづらかったので、この見出し一覧機能は本当に重宝した。

話を戻すと、こういうことが出来る、というのがぼくにとってのMarkdownの一番の利点であって、だからわざわざHTMLに変換して眺めることはほとんどない。

なんだけど、じゃあこのMarkdownファイルを他人に見せよう、あるいは仕上がりとして納品しよう、となったらまた事情が変わってくるわけで、とくに仕上がりデータとして渡すということは、渡された相手は当然、HTML変換後の姿を見るわけで、それなら僕もブラウザでの見え方を確認しながら文章を仕上げていかなくてはならない。

ということで、そういうときに役立つのがprevimというウルトラ神プラグインで、

github.com

これについては多分、このブログでも幾度となく紹介しているので多くは語らないけれど、ざっくり動画化してみるとこんな感じで。

gyazo.com

右側のVimに書いた内容が、左側のブラウザの方にリアルタイムに反映されていく。(このときはややもっさりしてるけど・・作業中はそんなに気にならず快適)

ただ、これも一人の作業だったらこれだけで十分なんだけど、他人との協業ということを考えると、「あ〜、今このブラウザで自分が見てる最新データ、そのまま他人にもリアルタイムで見れるようにしたいな〜!」なんて思ってしまう。

先回りして言っておくと、これ、べつにVimにこだわらなくていいなら、ScrapboxとかGoogleドキュメントを使えばそれで解決する。

とくにScrapboxは軽くて快適で、目的さえ一致すれば非エンジニアも含めて誰でも入りやすいツールなので良いと思う。

しかし問題はVimにあるというか、ぼくはあくまでMacVimという自分の執筆環境を維持しながら、また自分ではこのprevimを使いたいという前提があるので、それらを使わない選択肢はここでは外れる。

で、どうしたらいいのか・・といろいろ考えたり試したりしたのだけど、結論的には、

1. VagrantLinuxを立ち上げる。
2. その中でnginxを立ち上げる。
3. Rijiを使ってMarkdownファイルをブログ(HTML)化する。
4. 2のサーバーとVagrantの共有フォルダ機能を組み合わせて、3のHTMLページを同ネットワークから誰でも見られるようにする。

という方法が一番イメージに近いかなと思っている。

手順

ということで、以下はそれを実現する手順。

まず、Vagrantでnginxを立ち上げるところまでは、以前に書いたこの記事でほとんど行ける。

note103.hateblo.jp

ただし、その記事を書いたときからけっこう時間も経っていて、実際に今回やったこととは多少なりズレがあるので、この機会に少しアップデートしておく。

Vagrantの準備

初めにVirtualBoxVagrantをダウンロード&インストールしておく必要があるけど、その辺りの基本的な部分についてはドットインストールさんにお任せ。
(2013年のレッスンだけど、概念的なことは変わらないと思う)

https://dotinstall.com/lessons/basic_vagrant

その上で、以前の解説記事では ubuntu/trusty64 というVagrant boxを使っていたのだけど、今回は公式サイトのクイックスタートガイドで紹介されていたhashicorp/precise64というboxを使ってみる。*1

www.vagrantup.com

ではさっそく、今回作業するディレクトリを作って&入って、上述のboxを指定してvagrant init.

$ vagrant init hashicorp/precise64

このとき、もしまだこのVagrant boxを入れていなかったら、インストールにはけっこう時間がかかる。どのぐらいか? boxにもよるけど、5〜10分ぐらいは見ておいた方がいいかも。

Vagrant boxのインストール&initが完了すると、ディレクトリ内にVagrantfileができる。これはなんだろう、設計書みたいなもの? かどうかはわからないけど、ともかくそれをエディタで開いて、30〜35行目ぐらいに以下を挿入。

config.vm.network "public_network", ip: "10.0.1.100", bridge: "en0: Wi-Fi (AirPort)"

IPアドレスは経験的にその辺が間違いないので使っているけど、なぜそれを使っているかは自分でもわかってない。とりあえず雰囲気でそのアドレスにしている。

またその挿入箇所、実際には1行目でも100行目でもいいと思うのだけど、その近辺にこれがあるので、

  # config.vm.network "private_network", ip: "192.168.33.10"

自分の場合はその下にそれを並べている。

なお、今回共有したいページを他人のマシンや自分の他デバイスから見る必要がなければ、上記のpublic_networkは使わずに、そのprivate_networkのコメントアウトを外すだけでもOK。
ただし、それなら別にVagrant使わなくても、後述のRiji や、あるいは@mattnさんが作ったmemoアプリのサーバー機能を使って閲覧するだけでもいい気はする。

mattn.kaoriya.net

Vagrantfileの編集が終わったら、保存してからおもむろにvagrant up & ssh

$ vagrant up
$ vagrant ssh

これで、Ubuntuの中に入った状態。

nginxを動かす

次、nginxのインストールと起動。これはまったく以前の記事に書いたまま。

$ sudo apt-get update
$ sudo apt-get install nginx -y
$ sudo service nginx start

ステータスを確認。

$ service nginx status
 * nginx is running

で、先ほど設定した http://10.0.1.100/ を見にいくと・・

f:id:note103:20180613131605p:plain

OK。

共有フォルダの設定

次に、ローカルなHTMLファイルを今立ち上げたサーバー経由でブラウザから見られるようにする。

この手順も以前の記事とほぼ同じなんだけど、前に使ったubuntu/trusty64だと/usr/share/nginx/htmlというディレクトリにアクセスしていたのが、今回の場合は最後がhtmlではなくwwwなので、そこがちょっと違う。

具体的には、こんな感じで操作した。

$ cd /usr/share/nginx/
$ sudo cp -r www www_orig
$ ls
www www_orig
$ sudo rm -rf www
$ ls
www_orig
$ sudo ln -s /vagrant www
$ ls -F
www@ www_orig/
$ ls www
Vagrantfile

これで、ローカルの作業ディレクトリとサーバーがつながった状態。

では試しに、そこにhello.htmlなど作ってみる。(最小限で・・)

<!DOCTYPE html>
<body>
  <h1>Hello World!</h1>
</body>
</html>

で、アクセス。

f:id:note103:20180613135700p:plain

OK。(でかい)

ちなみに、この一連の環境構築作業、Vagrantfileにシェルスクリプトで設定してやると、最初の vagrant up コマンドだけで一気に終わる。かなり便利。

具体的には、こんな感じのコードを入れる。(ファイルの終盤にシェルスクリプト用のひな形が用意されていたので、一瞬で出来た)

  config.vm.provision "shell", inline: <<-SHELL
    sudo apt-get update
    sudo apt-get install -y nginx
    sudo service nginx start
    sudo cp -r /usr/share/nginx/www /usr/share/nginx/www_orig
    sudo rm -rf /usr/share/nginx/www
    sudo ln -s /vagrant /usr/share/nginx/www
  SHELL

たしかVagrantの理念というか思想として、「vagrant up 一発で全部終わるってふうにしたかった」的なことを何かの本で読んだけど、たしかにこれで事前にやりたいことはほぼ終わってるのでスゴイ。

Rijiとつなげる

さて、元はと言えば、手元のMarkdownファイルを簡便な方法で他者・他デバイスからも見られるようにしたい、という話だった。

で、ここまでの作業によって、ひとまず「HTMLページさえできていればどこからでも閲覧できる」という状況になっている。

よってここからは、「手元のMarkdownファイルをササッとHTML化する」方法に入るわけだけど、そのためにここで使うのが、Perl製のシンプルなMarkdown用ブログツール、Riji。

github.com

ぼくはPerlに馴染みがあるのでこれを使っているけど、JekyllやHugoでも似た感じにできる気はする。

Rijiの使い方については、作者の@songmuさんによるチュートリアルがわかりやすい。

Riji tutorial

もしまだモジュールが入ってなかったら、とりあえずcpanmでインストールしてから、今回のブログ環境をサクッとセットアップ。

$ cpanm Riji
$ riji setup --force

2行目でforceというオプションを入れているけど、これはデフォルトのsetupコマンドが空ディレクトリでの操作を前提にしているからで、すでにディレクトリ内に他のファイルが入っている場合は、このforceを付ける。

今回は作業ディレクトリにVagrantfileなどが入っているので、このオプションを入れている。

この時点でtreeを見ると、こんな感じ。

.
├── README.md
├── Vagrantfile
├── article
│   ├── archives.md
│   ├── entry
│   │   └── sample.md
│   └── index.md
├── cpanfile
├── hello.html
├── riji.yml
└── share
    └── tmpl
        ├── base.tx
        ├── default.tx
        ├── entry.tx
        ├── index.tx
        └── tag.tx

4 directories, 13 files

このうち、今回の主役であるMarkdownファイルをどこに収納すればいいかと言ったら、上から5番目のarticle/entryディレクトリに入れる。

また、RijiはMarkdownファイルをGit管理しながらブログ化していくので、新たなファイルを作ったり、更新したりした場合には、HTML化する前にコミットしておく。

その後、後述のブログ生成コマンド(riji publish)を叩くと、Vagrantfileやarticleディレクトリなどと同階層にblogというディレクトリができて、その中にHTMLファイルがダダダッと入ってくる。

今回は、すでにarticle/entryディレクトリの中にサンプルのMarkdownファイルが入っているので、それを表示してみる。

riji publish

RijiでMarkdownファイルからブログページ(HTML)を生成するには、本来であれば、以下のコマンドを使う。

$ riji publish

しかし、ここでひとつ注意点。いま「本来であれば」と書いたとおり、この機会ではそのコマンドだけでは足りない。

というのも、なぜかこのコマンドを打つと、HTMLファイルが生成されるblogディレクトリのパーミッションがそのつど700になってしまって、肝心のブログページがブラウザから見えなくなってしまうから。

よって、このコマンドにパーミッション処理も加えて、こんな感じにする。

$ riji publish && chmod 755 blog

と同時に、これを毎回打つのは苦しいので、.bashrcにこんなエイリアスを入れておく。

# .bashrc
alias rjp="riji publish && chmod 755 blog"

これでぼくの場合は、rjpと打てばそのつどMarkdownファイルがHTMLページに変換されることになる。

最後にもう一つ、ブログのルートディレクトリにriji.ymlという設定ファイルがあるのだけど、この中のsite_urlという項目にブログのトップページを仕込んでおくと大変便利になる。今回の場合は、こんな感じ。

site_url: 'http://10.0.1.100/blog/'

これで、ブログ内をリンクでスイスイ動けるようになる。

結果

ページ生成後のブログトップはこんな感じ。(MacBookGoogle Chromeから見たところ)

f:id:note103:20180614000901p:plain:w300

iPhoneSafariから見ると、こんな感じ。

f:id:note103:20180614112109p:plain:w300

そのままトップページからSampleページ(sample.mdで作ったもの)に移動すると、こんな感じ。

f:id:note103:20180614112124p:plain:w300

グレイト。

まとめ

一連の流れをまとめると、VagrantとRijiの設定をした上で、

  1. Markdownで記事を書く。
  2. 作業リポジトリの article/entry にファイルを置く。
  3. git add && commit
  4. riji publish (&& chmod 755 blog)

とすれば、上の例なら http://10.0.1.100/blog に行けばHTML化された同記事を見ることができる。

デザイン

以下はオマケ。ここまで来ると、もうひと押し、デザインにも少し手を入れたいと思えてくる。

デザインについては、チュートリアルのこの辺りでテンプレートの編集方法が解説されているので、参考になる。

http://songmu.github.io/p5-Riji/blog/entry/005_template.html

ぼくがどうしているかと言うと、まずshare/tmpl ディレクトリにあるbase.txを開いて、上の方にあるBootstrap CDNのリンクを別の好きなものに入れ替えている。

Bootstrap CDNについては、こちらがわかりやすかった。(サワリしか読んでいないけど)

codezine.jp

デザインはいろいろググった結果、ここから選ぶのが良さそうだった。

www.bootstrapcdn.com

今回はその中から、Unitedというのを試してみる。

Bootswatch: United

変更前のこれを・・

  <link href="//netdna.bootstrapcdn.com/bootstrap/3.0.0-rc1/css/bootstrap.min.css" rel="stylesheet">

これにする。

  <link href="https://stackpath.bootstrapcdn.com/bootswatch/4.1.1/united/bootstrap.min.css" rel="stylesheet">

またついでに、現状だと全体に左上の方に寄っているので、少し右下に動かしたい。
さらについでに、フォントを少し大きくしたい。
ということで、諸々雑にこんな感じで追記。

<div style="margin-top : 30px">
<div style="margin-left : 5%">
<div style="margin-right : 5%">
<font size="+1">

変更前。

f:id:note103:20180614133053p:plain:w300

変更後。

f:id:note103:20180614133111p:plain:w300

iPhoneから見たところ。

f:id:note103:20180614151100p:plain:w300

オッケー。

感想

長文を書いていると、避けがたく誤字脱字や壊れた言い回しなどが生じてくるが、これに自分で気づくのはなかなか難しい。

その理由としては、書いている人間が「そこに何が書いてあるのか」を誰よりも知っているがゆえに、「あまりきちんと読み直さないから」ということがあるだろう。

言い換えれば、「飽きるから」。

しかしこのような、個人の日記レベルの文章ならばともかく、他人に見せる、それも仕事として渡す前提の文章だったら、「飽きるから」なんて理由で不備だらけの文章を作ることもできない。

そのようなとき、その「飽き」を解消する方法として有効なのは「他人になること」で、一番簡単なのは時間を空けてまた読むことだろう。

しかしそれだけの余裕もないのなら、読む環境を変えるのがいい。ここで言う「環境」とは、場所もそうだけど、おもにはデバイス
ついでに、ページの背景やフォントなどの見栄えが変わればなお新鮮に読めるかもしれない。

文章(ページ)の見え方が変わると、自分の中に擬似的な時間移動が生じて、まるで他人の書いた文章のようにそれを読むことができる。

同ネットワークにいる他人に読ませる方法としても、他人のような自分に読ませる方法としても、本記事の手法は地味に役立つように思う。

*1:以前はドットインストールさんの何かの解説動画でtrusty64を使っていたからそれに準拠したのだけど、今回念のため探したらその動画が見つからなかったのと、とりあえず公式のスタートガイドにあるものを使った方がより安心かと思ったので。

JupyterにPerlを入れてMacで使うまで

Jupyterという、ブラウザで動くエディタ兼ターミナルみたいなものがあるらしく、基本的にPythonで使われているようなのだけど、Perlも動くっぽい、と何かで見たのでやってみました。

jupyter.org

Jupyterとは

概要的には、ググって最初に出てきたこちらの冒頭の説明がわかりやすかったです。

Jupyter Notebook を使ってみよう – Python でデータサイエンス

Jupyter Notebook (読み方は「ジュパイター・ノートブック」または「ジュピター・ノートブック」) とは、ノートブックと呼ばれる形式で作成したプログラムを実行し、実行結果を記録しながら、データの分析作業を進めるためのツールです。
プログラムとその実行結果やその際のメモを簡単に作成、確認することができるため、自分自身の過去の作業内容の振り返りや、チームメンバーへ作業結果を共有する際に便利なほか、スクール形式での授業や研修などでの利用にも向いています。

経緯

事の発端というか、そもそもなんでそんな事しようと思ったかというと、仕事の合間にふと息抜きでこちらを見ていたら、

www.youtube.com

プログラミング入門者にanacondaのインストール一発でPythonとJupyterの環境を同時に作る手順を丁寧に解説してるんだけど、それを見て「うわ、こんなに簡単にスタートできるのか」と驚きながらとりあえずJupyterの環境まで作って、そこでふと「これでPerlも動かないかなあ」と思ったのでした。

IPerl

Perlを使えるようにする手順としては、Qiitaに書かれたこちらがわかりやすかったのですが、

qiita.com

あいにくここで紹介されているのはCentOSへのインストール方法だったので、ぼくが使っているMacへの導入となると、部分的に読み替えが必要になります。

ということで、大枠は上記Qiita記事で把握しつつ、主要モジュールと思われるDevel::IPerlのリポジトリへ。

github.com

READMEをしばし熟読。なるほど・・ということで、すでに上記動画をもとにPython3とJupyterは入っているので、そのREADMEにあるZeroMQ(zmq)と、PerlモジュールのDevel::IPerlを入れてあげれば良さそうです。

前者については、macOS版なのでこちら。

https://github.com/EntropyOrg/p5-Devel-IPerl#macos

で、Jupyterのところは飛ばして、モジュールインストールのこれ。(といっても1行だけど)

https://github.com/EntropyOrg/p5-Devel-IPerl#install-from-cpan

で、めでたく完了!

と思いきや、動かない・・。

それからしばらく、何が足りないのかとあちこちいじったりググったりしていましたが、結果的にはこれで。


ぼくはPerlのヴァージョン管理でplenvを使っているのですが、こういうときは大抵plenv rehashが必要なのですね。

今回もそれをやらずに「動かない・・」とかやっていました。

$ plenv rehash

で、動くようになりました。

実行

具体的には、ターミナルでどこか作業したい場所に入ってから、

$ iperl notebook

または

$ jupyter notebook

でブラウザがブワッと開いてくれます。

https://i.gyazo.com/5a5a41df4516fec292fc17486e430cd7.gif

いい感じです。

ちなみに、サブコマンドのnotebookをconsoleにすると、ターミナル上で同じことができるようです。

$ iperl console

gyazo.com

ということで、これで「ぼくも流行りのJupyterでPerlを動かしたい!」という目標を達成できました。

用途的には、普段から小さなPerlのサンプルコードを手元で一瞬動作確認したい、みたいなことがよくあるので、そういう時に使いやすいかなと思っています。

ローカルのファイルからデータを入出力したり、標準以外のモジュールを使ったりすることもできるようです。

https://i.gyazo.com/f8a9e1aa7e978c4e48ae456101ffa43e.gif

素晴らしい!

応用情報技術者試験を受けてきた

昨日2018/4/15、応用情報の試験を受けてきました。場所は東京情報大学というところです。

昨年10月に基本の方になんとか受かって、

note103.hateblo.jp

さて、これからどうしよう、応用も行くかどうか・・と悩んでいました。

悩んだ理由は、単純に「難しいかも」というのもありましたが、それとは別に、最近簿記2級の勉強を復活しているので、仕事に加えて異なる種類の勉強を2本同時にやるというのは、どっちつかずになって効率悪いかもな・・というのが大きかったです。

ただ、それでも今は基本情報技術者試験のための知識が一番残っているときでもありますし、今のうちにその辺をもう少し頭や体に定着させておきたい、という貧乏性的な気持ちがあったのと、あとはやっぱり、これは以下にも書きましたが、元々のこうした情報系資格試験を受けようと思ったきっかけとして、ちょまどさんが「基本も応用も合格した」という話が根っこにあったので、

note103.hateblo.jp
(例によって長い記事ですが、真ん中ぐらいで言及してます)

ひとつのキリとして応用まで行けたら綺麗だよなあ、という気持ちが根強くあって、結局申し込んだのでした。

しかしその後、やはりというか、けっこう頭の使い方が異なる2つの試験勉強を並行するのはきついというか、片方がわかりかけたときにもう片方をやらなきゃいけない、という感じでロスが大きいように思ったので、ちょうど4月に入ったぐらいから、思いきってより優先的な簿記の方に舵を切ることにして、応用の勉強はストップしていました。

そしてそのまま2週間ぐらい、時間ができるたびに簿記の勉強にすべてを費やしていたので、「もうこれじゃ応用、受けに行っても時間のムダだなあ〜・・。行けば丸一日つぶれるし、受験料はもったいないけど、休むか」と思っていたのですが、試験の前々日ぐらいになって、彼女から「応用はどうするのか」と聞かれて、「いや〜、迷ってるんだけどね〜・・」と、本当はもう行かないつもり95%ぐらいでしたが、ちょっと体裁が悪かったのであたかも迷っている風にぼんやり答えたところ、「行った方がいいんじゃないの」と言われたので「あ、はい」という感じで行くことに180度方針転換し、当日は朝からすさまじい暴風雨でしたが、もろともせずに(というか諦念と共に)行ってきた次第でした。

前回と前々回に基本情報を受験した会場は、たしか新習志野千葉工業大学で、行く道すがら応用の教科書を読んでいる受験生もいたようだったので、当然今回もそこだと思っていましたが、結局そのように受験前日になって慌てて受験票に写真を貼り付けたり、会場の場所を確認したりしていたところ、今回は千葉の千城台というところにある東京情報大学で、初めて行く場所というだけでなく、アクセス的にもだいぶ時間や労力を費やしそうだとわかって暗澹たる気持ちになりましたが、実際にはJR千葉駅から大学前まで1本で行けるバスがそれなりの頻度で(日曜でも)走ってくれていたので、それほどの苦労はありませんでした。

とはいえ、当日は上記のとおり暴風雨で、基本的に皆同じバスで向かうだろうと思えたので、試験開始の1時間前には着くよう早めに出発したのも良かったのだと思います。

会場に着くと、基本情報のときとちょっと違うなと思ったのは、おじさんの割合が少し多かったことでした。

基本情報のときは、周りは若者ばかりで、高校生ぐらいに見える人も少なくなく、「うーん、やはりIT系の資格で、自分のように40代に入ってからわざわざ受けにくる酔狂な人はいないんかな」と感じ、「おじさんもどんどんこういう勉強したらいいのに、いろいろ役立つのに」などと偉そうに思ったりしていましたが、応用の会場には自分と同世代か、もしかしたらちょっと上かも、ぐらいの人もいて、ただこれは後から思いましたが、応用の場合は、これはこれでべつにぼくのような勉強とか趣味とかいう理由ではなく、仕事に関わるというか、この資格があれば昇進とか昇給とか転職とかに有利とか、そういった理由によるものかな・・とも思ったりはしましたが。

女性の割合は、あくまで感覚的なものですが、基本情報のときの方が多かったかな・・という気はしました。
やっぱり受ける世代が若くなるほど、女性の割合が多くなるのかな・・と、狭い観測範囲からざっくり感じているところです。

会場に到着後、ひとしきり筆記用具などの準備を終えた段階で、まだ試験開始まで45分ぐらいあったので、とりあえず何か飲み物でも買おうと思って構内を探しましたが、自動販売機がありません。

あれ、と思って入り口で案内をしていた職員の人に聞いてみたところ、今いる棟を一旦出て、向こうの何号館だかのそばにある、と教えてもらいましたが、その職員さんが指差す先、自動販売機のあるらしい場所と現在地との間には風雨が荒れ狂っており、今ここでそんなエネルギーを使ったら試験にもろ影響しそう・・と思って諦めました。

代わりに、昼ごはんのためにサンドイッチとおにぎりを買っておいたのですが、これは自分にはちょっと多くて、どちらかを残すことになるだろうと思っていたので、このうちおにぎりの方を食べてしまうことにしました。

以前からのささやかな知見として、のどが渇いたときには何かを食べると解消する、ということがわかっていたからです。
(食べ物にもよると思いますが)

思ったとおり、おにぎりを食べ終わる頃には水を飲みたい気持ちも消えていて、安心して試験開始を迎えられることになりました。

ちなみに、なぜそれらの弁当を用意した段階でお茶も買っておかなかったのかというと、それらはすでに前日のうちに買ってあって、家から持参したので、そのときに飲み物まで持っていくと荷物が重くなると思ったからでした。

もちろん、そうした前提には、会場である大学構内に自動販売機があるだろうという考えがあったわけですが、それがなかったので問題になったわけでした。

教訓としては、小さいお茶でもいいので、昼休憩までもつ程度の飲み物は持参しておいた方が安全だなということがわかりました。

午前の試験が始まって、すぐに思ったのは「イスが硬い・・」ということでした。

以前の会場ではとくに感じなかった気がしますが、今回はけっこう顕著な感覚で、途中で何度も座り直すなど、これをやり過ごすのには苦労しました。

資格試験に関わるセオリーみたいなもので、会場に座布団を持っていきましょう、みたいな話を聞いたことはありましたが、これまでの経験ではそういった必要性を感じたことがなかったので、自分には関係ないと思っていました。
しかし今回の経験で、今後はちょっとそれ、本格的に考えた方がいいなと思いました。

なお、一応フォローしておくと、今回の大学が他に比べてとりわけイスが硬いのかどうかはわかりません。
今回は「どうせ無理」という前提もあり、そこそこリラックスしていたので(緊張感が薄いというか)、その辺まで感覚が行き渡ってしまったのかも、とも思います。

その午前の試験、自分は計算の必要な問題が苦手だとわかっていたので、知識や記憶ですぐに答えられるものをまずどんどん回答(マークシートにマーキング)していきました。

具体的には、回答したものには問題用紙の問題番号の部分に◯とか◎とか△を付けて、すぐに回答できなかったものについては、「↓」とか「?」を付けていきました。

これらのマークは、以下のような意味です。

自信アリ
多分大丈夫
合ってるかもしれないけど間違ってるかもしれない
時間をかけて考えればわかる可能性があるけど、とりあえず後回し
皆目わからん。問題が何を言ってるのか意味不明

これで一度最後まで行ったら、そのまま逆方向にページをめくりながら(第80問から第1問に向けて)、マークミスがないかをチェックしていきました。

この際、「↓(後回し)」マークのうち、「ちょっと考えればできそう」みたいなものがあれば取り組んでしまい、回答が出たらそのままマークします。

これでまた第1問まで戻った頃には、全体の7割強ぐらいは埋まっている状態で、感触としては、「そこそこ出来てるじゃん」みたいな感じでした。

まあ、「自信があるもの」から順に埋めているので、当然といえば当然ですが、とはいえ、自信があるもの&そこそこ出来そうなものだけで7割以上埋まっているということは、この時点で合格基準点の60点を超えている可能性もけっこうあるわけで、にわかに「午前は行けるかも」と思えたのも自然なことだとは思います。

(ただし実際には、この時点ではまだ全然基準点を超えておらず、それどころかだいぶ厳しい状態に置かれていたことが帰宅後、自己採点をしてみてわかったのですが)

そこまで来たら、今度はまた第1問から、上記で「↓」や「?」を付けた問題のうち取り組みやすそうなものを選んで回答していきます。

ただし、ここであまりレイヤーを分けると後がつらくなりそうだったので、この段階ではもう「超絶難しい、当てずっぽうでやるしかない」か、「時間をかければできるかも」の2段階程度までに分けることにして、後者だったらその場で解く、という感じにしました。

これで最後まで行ったら、最後に残った「超絶難しい」グループに答えていきます。というか、当てずっぽうタイムなわけですが。

といっても、ここまで来るともう残り10問もなかったと思います。
それらについて、一応問題も読んでから、「それらしいやつ」を選んでマークしていきます。

後から自己採点をしてわかったことですが、この当てずっぽうグループが3〜4割程度当たっていたようです。

そしてこれも多分あとで書きますが、自己採点の結果は、80問中50問正解、基準点60点に対して62.5点だったので、これらの「まぐれ当たり」がなければ余裕で午前で落ちていたと思います。

さて、そんな状況とはつゆ知らず、「けっこう出来てんじゃん」とほくほくしていたこともあり、一旦すべての問題に回答し終えた頃から、基本情報の時にさえやらなかった「途中退室」を考えはじめました。

というのも、午前をフルで受け切ると、試験が終わるのが12時ちょうどで、午後試験は13時スタート、しかしその事前の説明は15分前ぐらいから始まってしまうので、昼食の時間はもちろんのこと、午後のための最後の詰め込みや、休憩を取る時間すら実質的にはほとんど取れないことになります。

今回はまともな試験勉強をしていない前提ではあったものの、やるからにはギリギリまで情報を頭に詰め込んでおきたいと思っていたので、そのまま「午前の回答を見返す時間」と、「午後のための勉強に使う時間(および休息)」とを天秤にかけて、より得点効率の高そうな後者を選びました。

といっても、その午前問題に回答しきって、マークシートの回答漏れやズレがないことを確認し終えたのは、退室可能なリミットである11時半の数分前で、まだ充分に見直しをしたわけでもなければ、これまでの試験で途中退室をした経験がなかったこともあり、やはりそこで出るのは不安が大きかったです。

実際、答案を提出してから、あれ、受験番号ちゃんと書いたっけ・・という不安に襲われましたが、上記のように、両方のメリットを取ることはできないので、それならそれで仕方ないと割り切りました。

初めての途中退室をギリギリで果たした後は、午前に確認した自動販売機の場所まで行って、お茶を買いました。

この時にはすでに雨は上がっており、風だけが勢いを増していましたが、それでも広々とした大学の敷地は懐かしいような、自由なような雰囲気があり、一瞬でけっこうリフレッシュできました。

会場近くの静かなスペースを見つけて、サンドイッチを食べながら午後対策の参考書を読みました。

午前問題に関しては以下の過去問を使いましたが(ぼくが実際に持っているのは平成29年度版ですが、ここでは新しい方を貼っておきます)、

午後対策としては、以下を使いました。

平成30-01年度 応用情報技術者 試験によくでる問題集【午後】 (情報処理技術者試験)

平成30-01年度 応用情報技術者 試験によくでる問題集【午後】 (情報処理技術者試験)

後者の著者である大滝みや子さんの本には、冒頭で挙げた以下の記事にも書きましたが(再掲)、

基本情報技術者試験にうかった - the code to rock

基本情報の学習時にずいぶん助けてもらいました。

今回の本でもポイントが非常に絞られ、丁寧にまとめられ、なおかつとても親しみやすい語り口でスイスイ書かれているので、ともすれば悲壮感に包まれそうな直前の詰め込み作業にも、最小限の負担であたることができました。

そして実際、このときにパラパラとめくってはフムフムと眺めていた、「システム監査」のページに書かれていたキーワードがその後の試験にバッチリ出てくれて、かなり助かりました。
「試験によくでる」と謳われている本ですが、少なくともぼくにとってはまさにその通りでした。

ちなみに、前者の過去問集ですが、こちらは同書掲載の直近回である平成28年度秋試験、その1回分だけを80問すべて事前に解いておき、その間違えた箇所や、正解した設問でも意味のわからない選択肢やキーワードがあれば、対面ページにある解説に目を通すようにしていました。

対象を1回分だけにしたのは、単純に時間がなかったからでもありますが、それ以上に「一度間違えたところ」や「一度目を通した問題・解説」をくり返し読めるようにするためでした。

同じ時間を使って、新しい80問に取り組めばあと1回分(平成28年度春試験など)は解けたと思いますが、それよりも限られた問題をきちんと理解した方が効率がいいはずだと思いました。

あるいは、基本情報の勉強で使った過去問をもう一度確認して、苦手箇所を基礎から勉強し直すという方法も考えていましたが、これも結局は時間との兼ね合いで、応用の過去問に集中した方が手っ取り早く得点につながるはずだと思い、午前対策としては、その応用の過去問から直近の1回分に絞りました。

感触としては、その戦略は功を奏したように思われ、そこで出てきたのと同じ問題や、それに類する問題がいくつもあり、なにしろ直前に目を通していたので答えごと覚えているようなものもあり、午前をパスできたのは(あくまで自己採点ですが)そのおかげもあるかなと思っています。

昼休憩が終わり、午後に入り、イスが硬いなと思いながらもなんとか最後まで終えました。

今回の目標は、「午前合格、午後は回答欄を埋めきる」というものでしたが、残念ながら、午後に選択した問題の回答欄を埋めきることはできませんでした。

今回選択したのは、必須問題である第1問「情報セキュリティ」をはじめ、以下でした。

  • 問1 情報セキュリティ
  • 問2 経営戦略
  • 問9 プロジェクトマネジメント
  • 問10 サービスマネジメント
  • 問11 システム監査

じつは今年の3月頃、まだ日々の学習を簿記に振り切る前の段階では、第3問の「プログラミング」や、第5問の「ネットワーク」、それから第6問の「データベース」なども選択対象の候補に含めていました。

というのも、元々はその辺りの技術について詳しくなりたい、という気持ちが受験理由の一つにあったからで、逆に言うと、仮にマネジメント系の問題で合格したとしても、あまり達成感がないというか、そんなに嬉しくない・・という気がしていたからでした。
あくまで、技術的な分野で腕を磨きたいな、という。

しかし、今回の勉強時間でそれらに手を出すのは自滅と言うに等しく、おそらくトライしたとしても、わからなすぎてまったく面白くないだろうと思い、結局選択問題はすべて非技術系(ストラテジ&マネジメント系)で固めることにしました。

といっても、じつは第10問の「サービスマネジメント」というのが、基本情報のときには比較的相性が良かったカテゴリでしたが、この応用情報ではやけに難しく感じられることが多く、一方、第8問の「情報システム開発」を過去問で見たときには、存外スラスラ解けることがあったので、このどちらを取るかは当日に問題を見るまでわからないな、とも思っていました。

果たして、本試験の問題を見てみると、相性が良かったはずの「情報システム開発」の方はバリバリのプログラミング系、すなわち、オートマトン風の図や、擬似言語プログラム、あるいは聞いたことのないキーワード(サイクロマティック複雑度・・?)が踊り狂う問題になっており、ひと目で「サービスマネジメントにしよう」と決まりました。

マネジメント系をはじめとする、いわば文系的な問題では、問題文が小説のような架空の物語を舞台に作られており、これがなかなか面白く読めます。

そしてこの点は、「技術的な要素を避けられる」ということ以外の、これらの問題を選ぶ上でのメリットだと感じます。

ぼくは正直、他人が書いた長文を読むのは苦手なのですが(嫌いなのではなく、頭に入ってきづらいことが多いので)、どうしても読まなければならないのだとしたら、こういうフィクション仕立てのものの方が飽きずに読めて、楽しめます。

とはいえ、限られた試験時間を有効に使うためには、漫然と頭から読むのでは効率が悪いので、最初の1〜2段落だけ読んで概要を掴んだら(あるいは無理にでも掴んだ気になって)、先に設問の方にすべて目を通します。

そうすると大体、問題文中のどの箇所(空欄や下線など)に対して、どんな問いが投げかけられているのかがわかりますから、まずはその「問い」の方をある程度読み込んでから、そういう問いが来ることを前提に、問題文に戻って頭からスラーッと読んでいきます。

ちなみにこの際、問題文で空欄を問うものがあった場合、問題文全体を読まなくても、空欄を埋める選択肢や、その空欄前後の文脈だけで答えがわかる場合が少なくありません。
よって、それで埋められるところはこの段階で回答してしまいます。

応用情報の午後問題では、基本情報との大きな違いとして、記述式の部分が少なからずあります。

5字以内で答えよ、というものから、長いものだと45字以内、とかでしょうか。

これについては、多少は過去問や、上記の大滝さんの本などで「答え方」を練習してはいましたが、ぼくはこの「字数に収めつつ言いたいことを過不足なく言い切る」という作業で時間をかけすぎてしまったように思います。

じつのところ、この「字数に収めつつ言いたいことを過不足なく言い切る」というのは、ぼくが仕事でやっている編集作業のど真ん中で使うスキルなので、むしろ有利では? という気もしますが、ぼくの場合は、仕事であればとくに、ある程度納得行くまで直し続けたりするので、その「直しすぎる(時間をかけてしまう)」というのが足を引っ張ってしまったかなと。

もちろんというか、プロの編集者の中には、パッと見てパッと文字数に収める、みたいなスキルが高い人も多いと思うので、そういう人には有利かもしれないですが・・。

とくに今回の場合、第9問のプロジェクトマネジメントで、その文章づくりにちょっと時間をかけすぎました。

時間配分としては、本来1問につき20〜25分程度で進めて、残った30分程度を、後回しにした問題なり、見直しなりにあてようと思っていましたが、この第9問では、7〜8割ほど回答するだけでも35分ぐらいかけてしまい、時間の貯金をだいぶ使ってしまいました。

今「後回しにした問題」と書きましたが、この午後問題でも、午前と同様、時間がかかりそうな難しい設問には深入りせず、サクッと解けるものから埋めていきました。

結局は、その後回しにした問題を埋めるだけの時間を最後に確保できなかった、というのが途中答案になってしまった敗因なのだと思いますし、そのまた要因になったのが、プロジェクトマネジメントの問題だったのだと思います。

ちなみに、プロジェクトマネジメントに時間がかかったのは、上記のような文字数の調整や、言い回しを適切にすることについこだわってしまった、ということもあると思いますが、同時に、その架空の世界に入り込みすぎた、というのもあるかなと思っています。

難しい設問には深入りしないように注意していましたが、問題世界の方に深入りしてしまったというか、つい時間を忘れて、その中の登場人物たちに感情移入してしまったような、そういう感覚がありました。

架空の世界を元にした問題文には、「退屈せずに集中できる」というメリットがあると書きましたが、そういう思わぬデメリットもありそうだとうっすら感じます。

空欄のまま提出、という残念な部分はあったものの、すべて終わったときの感覚としては、「思ったより、できたな」という感じでした。

「こりゃ、受かるな」というほどではないですが、前々日まで行かないつもりだった試験とは思えないほどの成果とは言えます。

帰り道には、ちょうどバスが出てしまったばかりだったこともあり、次の次ぐらいの停留所まで、バス通りに沿った一本道を歩きながら、最近なぜかハマっているサザンオールスターズの『バラッド』を聴きました。

バラッド '77~'82

バラッド '77~'82

このアルバムは、「いとしのエリー」「Oh! クラウディア」「Ya Ya」などの有名曲が揃っているベスト盤のようなものですが、個人的には「ラチエン通りのシスター」「涙のアベニュー」「恋はお熱く」「わすれじのレイド・バック」あたりを好んで聴いています。

こういうのを聴いていると、サザンは日本のブルースであり、ソウルだなと感じます。
猥雑で、なんでも取り込みながら国民音楽的なポピュラリティを醸し、なおかつ最後にはサザンでしかない音に仕上げてくるところには生真面目さも感じますし、それより何より、桑田佳祐の歌はすごいです。生きているうちに聴けて良かったと思います。*1

気がつけば、永遠に続くかと思われた暴風はすっかり収まっていて、空は不穏な灰色に覆われていたものの、わずかに湿った春風に吹かれるこの帰途は、なかなか心地よいものでした。

帰宅後、頭が覚えているうちに午後試験の再現答案を作りました。

択一式の問題に関しては、持ち帰った問題にすべて回答がマークしてあるので、その必要はありませんが、記述式の方ではメモ程度にしか書き残していないものや、答案に転記した際に少しアレンジしたものや、試験の最後の方ではメモすら取る時間がなく、直接答案に書いたものも少なくなかったため、このままだと解答が発表されても自己採点をできないと思ったからです。

といっても、じつは普段は簿記にしても、前回の基本情報にしても、自己採点なんてやっても落ち込むだけだからと進んでやることはほとんど無いのですが、今回は元々どこか吹っ切れていたせいか、できるところまでやっておこう、みたいな意識高いモードになっており、やっておくことにしました。

必ずしも厳密ではないものの、ひとまずすべての再現を終えた頃、午前問題の解答が公開されました。

IPA 独立行政法人 情報処理推進機構:問題冊子・配点割合・解答例・採点講評(2018、平成30年)

午後問題の解答が公開されるのは、合格発表の5日前である6/15とのことで、おいおい、それなら自己採点用の答案、わざわざ作る必要なかったのでは・・とそのときに思いましたが、まあ答案用紙は戻ってこないはずなので、覚えているうちに再現しておけたのはやはり良い面もあったと思います。

と同時に、ここで午前分の自己採点も一気にやってみたところ、上記のとおり、合格基準点60点に対して、62.5点でした。

調子に乗って途中退室なんてしたわりには、思ったよりギリギリで焦りましたが、その後にあらためて正答・誤答状況を確認してみたところ、自信がなかったり当てずっぽうだったりした部分がけっこう当たっていて、それがなければ落ちていたのだとわかり、さらに焦りました。

自信アリの回答については、正解のものが多かったですが、「ちょっと自信ないけどたぶん大丈夫だろう」というものが案外どれもこれも間違っていて、これが実力というものか、と痛感しました。

午後問題については、上記のとおり、終わった時点での感触は「悪くない」という感じで、とくに択一系の(記述式ではない)問題についてはそこそこ自信があるつもりでしたが、この午前の結果を見るかぎり、やはり期待はしづらいな・・と思っているところです。

最後に免責事項を。

途中でいろいろと勉強法について偉そうに書きましたが、自分では通ったと思っている午前問題すら、まだ結果は出ていませんし、ましてや全体に関して言えば、「この方法を実践すれば受かる!」みたいなことはまったく言えませんので、あくまでそのような前提として捉えてほしいと思います。

さて、合格発表は6/20ということで、なんと2ヶ月以上先ですか。

記述式の答案がある以上、仕方ないと思いますが、基本情報の方が合格発表まで1ヶ月だったにもかかわらず、かなり長く感じましたので、この応用については、一旦「忘れておく」ぐらいの方がいいのかもしれません。

考えてみれば、それ以前に6/10、ぼくが現在、勉強分野としてはメインで取り組んでいる日商簿記検定2級の試験もありますので、まずはそこに向けて集中するべきでしょう。

ともあれ、以上、応用情報技術者試験を初めて受けた感想を、記憶の鮮明なうちに記録しておきました。

*1:自分が生きているうちに、という意味ですが。

ボッチでもOK

こちらは「春のPerl入学式リレーブログ」の7日目の記事です。
blog.perl-entrance.org

ひとつ前は、 id:kousy さんによる以下の記事でした。
kousy.hatenablog.com

Perl入学式での経験が仕事につながるというのは、すごすぎますね! 敬服します。
東京でのプログラマー生活、ぜひがんばってください。

今回の記事では、ぼくが初めてPerl入学式に参加したときのことを書きます。

ぼくが初めてPerl入学式に参加したのは、38才の夏でした。
これは同時に、ぼくがプログラミングの講義に参加した最初の機会であり、また初めて「プログラマー」と呼ばれる人々に対面した日でもありました。

その時のことは、以下の記事に書いています。
note103.hatenablog.com

今でもそうですが、ぼくは当時からプログラミングにまったく関係のない仕事をしていて、IT企業に勤める知り合いもいなかったので、このときには一人で参加することになり、会場には知ってる人が誰もいませんでした。

緊張していたせいか、時間よりも少し早めに会場に着くと、サポーター(スタッフにあたる人々) の id:papix さんや id:mackee_w さんたちもちょうど同じぐらいに着いていて、同じエレベーターに乗って上の階まで一緒に上がりました。

papix さんたちにはその時に少しだけ挨拶をしましたが、その後は基本的にサポーターさんはサポーター同士で楽しそうに話をしていて、今だから言えることですが、ぼくはうっすらと疎外感のような気持ちを抱いていました。

なにしろ、ぼくは年齢的に他の皆よりひと回りも(あるいはそれ以上に)離れていましたし、ITに関係ない仕事をしているのでその話題もまったく意味がわからず、周りに知り合いもおらず、Perl入学式自体も初めてで、さらにはその年の第3回の補講という、中途半端な回からの参加でもありました。

言うまでもなく、その疎外感はぼくが勝手に感じていたもので、サポーターの人たちから嫌な態度を示されたとかいうことは一切ありません。

ただ、自分以外の人は皆知り合いで、その人たちが共通の話題について楽しそうに話している、というその状況が、なんというか、チョット厳しかったわけです。

そしてぼんやりと、「ああ、自分が来るところではなかった」という気持ちになりました。

「呼ばれてもいないのに、身の程も知らずに、なぜこんな冒険をしてしまったのだろう?」と。

「あと何時間、この状況に耐えればいいんだ・・」と。

しかしながら、ボッチでも構わないから参加しよう、と思ったのは自分自身です。

とにかく時間が終わるまで頑張ろうと、そこは38才、なけなしの社会性を発揮して、こめかみには脂汗を浮かべながら、また周りの受講生の人たちともポツポツ会話を交わしながら、最後までなんとか時間を過ごしました。

それまでの人生でも、一人でイベントなどに参加することはよくありました。

知っている人が誰もいない場所に、後先考えずとりあえず飛び込んで、そのままコミュニティとの付き合いが始まったり、意図せず仕事につながったりすることもありました。

そういう経験が知らぬ間に体に染みついていたのか、初めは「すぐにでも帰りたい」と思っていたはずが、講義後の懇親会にも参加することになり、受講生やサポーターの人たちと少なからずおしゃべりをしながら、結局会場が閉まるまで残っていました。

その何日か後に、YAPC::Asia 2013が神奈川県の日吉で開催され、その中で行われたPerl入学式出張版にも参加しました。

Perl入学式 @ YAPC - YAPC::Asia Tokyo 2013
YAPC::Asiaで行われるPerl入学式のワークショップについて色々インタビューしてみました! | YAPC::Asia Tokyo 2013

なぜ一度痛い目にあったのに、懲りずにまた参加したのかというと、じつはYAPC::Asiaのチケットの方を先に買っていて、その下見のようなつもりで上記の講義(第3回補講)を受けていたからでした。

そして、このYAPC::Asiaでもまた、基本的にはずっと一人でした。

YAPCでのPerl入学式には、サポーターはもちろんのこと、先の受講生も何人か参加していたので、今度はまったくの一人ではなかったものの、YAPC全体を通してみれば、前夜祭でも、初日の懇親会でも、大半の時間は一人で過ごすことになり、それが数日間にわたり続いたため、このときには疎外感というより、もう少し重々しい、とりとめのない孤独のようなものを感じていました。

ちなみに、YAPCにおけるPerl入学式の内容は、普段とはちょっと違う番外編のようなもので、入門というにはひねりの効いた、少なくともぼくにはなかなかハードルの高いもので、何をやっているのかよくわからないうちに終わってしまった、という感じでした。

そういうこともあって、「やっぱりYAPC、俺には早すぎた・・」という後ろ向きな感想を持ちましたが、なぜかその後もPerl入学式には参加し続けることになり、翌年の4月からはサポーター側に回ることになりました。

ある種、痛切ともいえるボッチ体験に遭遇しながら、なぜその後もやめずに続けられたのかと考えると、結局のところ、その疎外感とか、孤独感とかいったツラさは最初に味わうものが一番大きくて、その後は痛みに慣れるというか、弱まるというか、軽減される一方だから、ということが言えると思います。

喩えてみると、バンソコウをはがす時に、最初にピャッとはがしてしまえばそれで終わるというか。

あるいはインフルエンザの予防接種を受けるときに、「はい、チクッとしますよ〜」とか言われて、「ひえ〜!」と思っても、その数秒後には全部終わってる、みたいな。

新しい体験がもたらす痛みは、最初の方ほど強く、しかし後は弱まる一方で、やがてそれは心地よい自分の居場所になっていきます。

この記事の前半で、エレベーターに乗ったときの話を書きましたが、今思えば、サポーターさんはサポーターさんで、普段はそれぞれ別の職場で仕事や生活をしていますから、Perl入学式という場で、気の置けない友人たちに久しぶりに会えたなら、普段はできない楽しい会話に時間を使いたくなるのはごく自然なことです。

当時のぼくからすれば、「自分と自分以外」という物の見方しかできていませんでしたが、実際には、サポーターにはサポーターの、特別な場としてのPerl入学式があったわけです。

普段の生活習慣から離れた場に、一人で飛び込むというのは、不安もあると思いますし、実際、人によってはツライ思いをすることもあるかもしれませんが、その次の瞬間から、欲しいものは確実に手に入ってきます。

ぼくの場合、それはプログラミングの技術でした。

だいぶ時間はかかりましたし、今なおかかっていますが、当初では考えられなかったほど、その技術を自分のものにし、それを楽しんでもいます。

プログラミングの勉強を始めるときに、一緒にやってくれる友達は不要です。
自分の体ひとつあればOKです。

Perl入学式では講義資料を広く公開していますし、

講義資料 - Perl入学式 | Perl Entrance

全国各地でも開催していますので、もし都合が合えば、いつでも参加してみてください。
www.perl-entrance.org

ノンプログラマーのプログラミング活用法

去る3月3日に沖縄で開催されましたYAPC::Okinawaでの発表内容をスクリーンキャスト形式で新たに収録してみました。

www.youtube.com

ただし、めっちゃ長いので(85分)各チャプターの頭出しをしたリンクも以下に並べておきます。
興味に近いところなどありそうでしたら、適当につまみ見してください。

  1. はじめに: https://youtu.be/jJZD3k6-q0c?t=0s
  2. 自己紹介: https://youtu.be/jJZD3k6-q0c?t=3m45s
  3. Vim: https://youtu.be/jJZD3k6-q0c?t=13m46s
  4. Shell: https://youtu.be/jJZD3k6-q0c?t=31m38s
  5. Perl: https://youtu.be/jJZD3k6-q0c?t=50m54s
  6. Excel: https://youtu.be/jJZD3k6-q0c?t=1h1m40s
  7. ふり返り: https://youtu.be/jJZD3k6-q0c?t=1h18m12s
  8. まとめ: https://youtu.be/jJZD3k6-q0c?t=1h22m1s

冒頭でも少し説明していますが、今回は発表の録画も録音もしてなくて、一応スライドは公開しているけどDEMOも多用しているので、スライドだけだと一部しかわからないし、まあ「そういうものだ」と割り切るのもアリなんだけど、実際はかなり準備していった話だからこのまま終わってしまうのもな〜・・と思って、このような形で再現してみました。

YAPC本番では40分以内に収めるためにいろいろトピックを削ってしまいましたが(Shell編の文字列検索とか)、今回はそれも含めて基本的には全部入りにしたので、そういう意味ではフルバージョンです。

と言いつつ、これも今聞き直してみたら「あ〜、あの話忘れた」「こう表現すればよかった」といった部分がポロポロ出てきているので、これはこれでひとつの未完成版というか、新たなライブ盤というか、YAPCとはまた別の即興的な何かかな、とも思います。

あとはYAPCの本番だとやっぱり、聞いている人たちの反応コミでの面白さみたいなのがあったので、その意味でも現場でのパフォーマンスとは別物といえば別物な気もします。

とはいえ、当日聞いてくれた人にとってはその補足というか、その日の内容を思い出したり、カットされた話を知るものとして聞けるかなと思いますし、沖縄まで行けなかった〜という人には、スライドではわからない部分を聞いてもらえる機会になると思うので、記憶がなくならないうちになんとか形にできて良かったなと。

なお、この発表に関するざっくりした話(というかスライド作成の過程など)については前回の記事に書きました。
YAPC::Okinawa 2018 ONNASONの記録 - the code to rock

発表スライドはこちら。
The Non-Programmer's Programming Techniques // Speaker Deck

その他、個別具体的なトピックについてはまだまだ語り足りない面もありますが、とはいえキリがなさそうなのでしばらくナシかな・・。

それよりはむしろ、イベント前後の前夜祭、ハッカソン、お土産屋めぐりなどについてまだ書いてないことがいろいろあるので、次に時間ができたらその辺りを書き残しておければ、という感じです。

最後になりますが、このような機会を作ってくれたYAPC::Okinawa運営スタッフおよび関係各位、参加者の皆さん、そして何より時間を割いてB会場で聞いてくれた方々、ありがとうございました!

YAPC::Okinawa 2018 ONNASONの記録

2018/03/03に沖縄県恩納村で開催されたYAPCに参加してきた。
yapcjapan.org

今回はなんと、スピーカーとしての参加。
http://yapcjapan.org/2018okinawa/timetable.html#/detail/10

初めはこの一連の出来事を時系列にまとめようと思っていたのだけど、あまりにもトピックや感想が多すぎて、ちゃんと書こうと思ったら完全に「仕事」になりそうだったので、頭に浮かんだ順に即興的に書いていくことにした。

スライドができるまで

今回、ぼくが発表したスライドは以下。

speakerdeck.com

ただし、当日の発表ではDEMOを多用しているので、このスライドに載っているのは全体の半分からせいぜい3分の2程度。

それは今回のスライドを作るときに強く意識していたことで、発表時にただスライドを読み上げるだけみたいな、紙芝居のように「スライドをめくりながらそれを見て喋る」みたいにはしたくなかった。

理想としては、スライドには見出しだけを列記する。そしてその一つ一つについて、画像なりDEMOなり、あるいは身ぶり手ぶりで説明してく、みたいにしたかった。

だから、スライドだけを見ても面白くもなんともない、現場にいないと(あるいは動画などで発表の様子を見ないと)意味がわからない、そんな感じにしたかったし、それで良いと思っていた。

(実際には、スライドだけを見てもある程度内容を想像できるようになっているとは思うのだけど。ただ事前の方針として、「後からスライドを見る人のために現場では不要な説明を加えたりしないようにしよう」と思っていたということ)

なにしろ今回一番大事にしたかったのは、わざわざ40分もの間ぼくの発表に付き合ってくれる人たちで、その人たちが「うひー、退屈だな」と思わないようにする、というのがほとんど最大のミッションでもあった。

スライドに書かれた文字が読み上げられるだけ、というのはなかなかツライ。大学の授業でもそういう先生が時々いた。
逆に、「その場にいないと得られない情報がどんどん飛んでくる」というのはスリリングで面白い。

だから、構想を練って項目を立てている最中もスライド化のことはなるべく考えず、Keynoteを立ち上げるのも可能なかぎり後に回した。

シャドープレゼンテーション

構想の練り方としては、だからスライドを作りながら考えるのではなく、かといってメモ帳やノート系のアプリを使うのでもなく、とにかく実際に喋ってみた。

頭の中にあるネタを喋りきって、それをすべて録音して、それを自動音声入力でテキスト化して、それをtextlintでざっくり表記統一して、それをプリントアウトして、それを眺めながら紙のノートにパラパラと見出しを書き出して、それを見ながらまた喋る。

これをたぶん3〜4周やった。

とにかく喋る&録音する、というのはシャドーボクシングならぬシャドープレゼンテーションみたいな感じ。

話を聞いている人たちのことを思い浮かべながら(その人たちは皆ぼくの発表に好意的だと設定しつつ)、その人たちに語りかける。

これはちょっとラジオにも近い。目の前にはいない、でもたしかに存在するはずの人々を想像しながら喋っていく。

だからこれは、「ポッドキャスト風ブレスト」とも言える方法で、それをやりながらどんどん構想を煮詰めていった。

ノートにプロットを書き出しつつ構成する、というのも試してはみたのだけど、プロポーザルを見てもわかる通り、ネタがあまりにも多すぎて、まともに精査していたら時間がいくらあっても足りないし、単純にもの凄く疲れそうだった。

その点、とりあえず思うままに喋るだけなら、頭の中はほとんど無意識というか、自動操縦のような感じになって、あまりくたびれずに膨大なアイディアを吐き出せたと思う。

加えて、喋りながら構想を練ると、60分も90分も喋っているうちにどんどん体が疲れてきて、また気分的にも飽きてくるので、この段階でネタの淘汰も進んでいく。

この話、そんなに無理してまで言わなくてもいいな・・みたいなストッパーが自然にかかるというか。

先にスライドを作り込んでからそれを実践するという順番だと、頭で考えた計画に体を従わせる感じになるが、この方法だと先に体の限界を設定しておいて、その条件を考慮しながら構想を作っていく感じになって、より現実的というか、結果的にではあるが、案外効率的だったように思っている。

ミニマルなスライドのメリット/デメリット

初めにブレスト的に、一旦最後まで喋ったときには90分ぐらいかかった。

理想としては、40分の持ち時間のうち、最後に5分の質疑応答を入れるとしたら発表自体は35分に収める必要があるから、ほとんど1時間オーバーしてる。

さすがにこれはまずい、と見出しのメモを見ながらあれこれ削って、やがて70分になり、50分になり、「ここから先は同じ方法では削れないな」と判断したところで、ようやくスライドを作りはじめた。

この時点で全体の構成はほとんど頭に入っていたから、スライドの初稿は1時間もかからずできたのではなかったか。
かなりあっさり最後まで行って、びっくりした。

とはいえ、この段階では上記のとおり、見出し中心の簡素な内容だったから、枚数も少ない。たぶんその時点では20枚ちょっと。

スライドの枚数が少ないと、短時間で作れるし、修正もラクだし、1枚あたりのクオリティも上げられるから、そういう意味ではメリットが大きい。

ただし、そのぶん本番ではスライドをカンペ的に使うことができないから、当日のプレッシャーや負担が大きくなる。
これはトレードオフで、実際ぼくも発表直前まで、本番で内容を全部忘れてしまったらどうしよう? という不安がつきまとった。

スライドの言葉

初稿ができた後は、少しずつ画像を足したり、説明文を補足したりして推敲を重ねた。
これにより、スライドの枚数も、1枚あたりの文字数も増えていった。

その作業をしていて気づいたが、スライドを作りながら物を考えると、「スライドの中の言葉」で思考するようになっていく。
言い換えると、その「スライドの言葉」を使わなければ論理が進まなくなっていく。

「スライドの言葉」とは、普段ぼくらが誰かに直接話しかけるときの「言葉」とはちょっと違って、スライドの中の世界だけで鳴り響く言葉だ。
これを使い始めると、スライド上の文字は加速度的に増殖していく。

その言葉を使うこと自体は悪いことでないけれど、文字数が増えるのは良いことではない。
単純に見づらくなるし、何より前述の「スライド読み上げプレゼン」まで一直線だ。

それはまずい、ということで、そこからまた文字を削ったり、枚数を減らしたり、最大限の抵抗はしたけれど、やはり終盤のまとめに至るあたりでは、そういった説明的な言葉が優勢になってしまった感がある。

いらすとや回避

スライドに文字をなるべく載せない方策としては、DEMOやスクリーンショットを使うこともそうだが、イラストを活用することも考えた。

この点、いらすとやさんに行けば大抵のフィーリングはイラスト化されていて、これはたしかに依存しやすいというか、めちゃくちゃ便利なツールだなと思わされた。

ただ、各所でいらすとやさんのイラストを使ったものを見ていると、中にはハイコンテクストにうまく活用している事例もあるものの、あまり多用すると誰の発表なのかわからなくなるというか、そもそもいらすとやさんのイラストというのはけっこう記名性が高いように感じられるので(匿名的ではないというか)、発表を乗っとられてしまうような危惧があった。

そこで2番めの案として、自分で手書きしてみることを考えた。

具体的には、以前にきしだなおきさんのブログで見た、こちらのような感じ。
d.hatena.ne.jp

さらさらっとルーズリーフのような紙に絵を描いて、そのままポンとプレゼンしている。スゴイ。

しかしどうも簡単には真似できない。ざっと描いてみることまでは出来ても、ぼくだったらその後の推敲であーでもないこーでもないとかえって時間をかけてしまいそうで、今回はそれだけの時間はないな、と思い直して諦めた。

それでふと「あー、これしかないか」と思ったのがGitHubやSlackでもおなじみのemojiを使うことで、ためしにKeynoteに入れていったら、思いのほか効果的だった。🤗

主張しすぎることもなく、かといって地味すぎることもなく、また微妙なフィーリングもそこそこ表現できて、何より簡単に入れたり外したりできる。

おかげで、文字ばっかりの状態に比べて少し楽しげな感じになって、おそらくはそれが奏功してウケた部分もあって*1、ホッとした。

客層とテーマのマッチング

沖縄までわざわざITカンファレンスに行くような人といったら、その時点で大半がエンジニア/プログラマーだろう、とはぼくも思っていた。

にもかかわらず、ぼくの発表は「ノンプログラマーがどうやってプログラミングを役立てているか」というものだったから、客層とマッチしないのでは? という懸念があった。

普通に考えたら、そのテーマから想定される客層というのは、「これからプログラミングを始めてみたいノンプログラマー」であり、その関心はと言えば、「自分がプログラミングを導入したら普段の仕事がどれだけ捗るのか?」みたいなことだろう。

しかし一方で、ぼくの今回の発表の価値というのはそういうところだけにあったのではなく、これはプロポーザルにも書いたことだが、「大半のプログラミング技術に関する情報はプログラマーが発信しているが、ここではノンプログラマーの私がそれを発信する」という点に意味があった。

通常、プログラミングに触れるノンプログラマーは、つねに「教わる側」であり、教わる側は言葉を持たない。

「わからないな」と思ったとき、それは「わからない自分が悪いのだ」と思ってしまいがちだ。

しかし実際には、ノンプログラマーがプログラミングに触れるとき、そこではいろいろなことが起こっている。
わからないのは、「教科書が間違っているから」かもしれないし、「教え方が悪いから」かもしれないし、「カリキュラム(勉強の仕方)が合ってないから」かもしれない。

ぼくはプログラミングを始めたのが38才を過ぎてからで、今では43才になろうとしているから、まあこれは年齢のせいというよりも性格のせいかもしれないが、いずれにせよ、自分の考えを伝えるための言葉を少しは持っている。

だから、変だなと思ったら「変だ」と言うし、しょうもない成果物でも「できた!」と言うし、YAPCトークにも応募する(それも今回で2回め)。

結果的に、普段あまり人々が聞く機会のない発表が実現したわけで、これは誰が聞いても新鮮であるには違いない。

残る問題は、ぼくがそこでどれだけ「純度の高い情報」を提供できるかということで、だからその点には神経を費やした。

もしそこで、ノンプログラマーにも背景がわかるように・・と終始基礎的な話をしていたら(ターミナルの立ち上げ方とか 、Vimの初期設定の手順とか)、一緒に聞いているプログラマーには退屈な時間になってしまうだろうし、かといって専門的な話をしようとしても中途半端になるだけだろう。

だから、とことん「自分が面白いと思ってる話」だけを取り上げることにした。

枝葉的な解説は最小限にとどめ、自分自身がエキサイトするような事象を集めて、そのことだけを話そう、と。

その純度が高ければ高いほど、つまりぼく自身が「この話、面白い!」と思えれば思えるほど、発表はきちんと聞き手に届くはずだと思って、そうした。

懇親会の終わりに話したこと

入門書のジレンマ

発表が終わり、懇親会になり、その終盤、朝からつづいた雨も上がり、会場から一人また一人と夜の庭へ出ていくのが見えた。

それにつられるように、ぼくも会場からフラフラと出ていったところで、ぼくの発表を見たという人から声をかけられた。

その人は、自分もプログラマーではなく、今回スポンサーをしている会社のひとつに勤めているのだと言った。

それからしばらく、いろいろと嬉しい感想をもらいながら、上に書いた「ノンプログラマー発の技術情報であることに意味がある」みたいな話をした。

ぼくらノンプログラマーが技術情報に触れようとしたとき、それを書いているのはつねにプログラマーなのだと。

その人は、プログラマーが書いた入門書などを読んでもわからないことがあると言い、ぼくは「それは自然なことだ」と言った。

プログラマーはノンプログラマーではないがゆえに、ノンプログラマーがどこでつまづくのかをわからないのだと。

もちろん、中には例外的な人もいて、結城浩さんなどはその例にはあたらない。

結城さんはつねに、読者が「今どこにいるのか」を考えながら書いているから、相手がプログラマーであろうとノンプログラマーであろうと、読者を置いてけぼりにはしない。

逆に言えば、わかりづらい入門書とは、読者が「今どこにいるのか」を想像できていないのだ。

何であれ、情報を整理して他人に伝えるときには、膨大な、かつ茫漠とした情報の海の中から、必要と思える要素を取捨選択しなければならず、それはつまり不要な部分を省略しなければならないということだ。

わかりづらい入門書というのは、そのとき、省略してはいけない部分を省略してしまっている。

ビルの上の階まで上がろうというとき、適切な高さの階段が均等に積まれていれば誰でも上がっていけるが、所々に異様に高い段差があったら、上がれない人が出てくる。

入門書を書くような人というのは、すでに専門家として何年もキャリアを積んでいる人だから、「どの階段を省略したら入門者がついてこれなくなるのか」を想像しながら書いていくのが難しいのかもしれない。

だからこそ、自分のようなノンプログラマーが技術情報を発信することには何らかの価値があるだろうと思うし、そのときもたぶんそういう話をした。

プログラマーとノンプログラマーを分けるもの

そのときに話したことをもう一つ書いておくと、これは本来、今回の発表にも入れたいと思っていたのだけど、とても時間が足りなくてカットしたもので、「プログラマーとノンプログラマーの違いは何か?」という話。

また喩え話になるが、ノンプログラマーによるプログラミングが「趣味の魚釣り」だとしたら、プログラマーによるプログラミングは「漁業」である。

趣味の魚釣りと漁業との違いは、「誰のために魚を獲るのか?」ということで、言い換えれば、「獲った魚を食べるのは誰か?」ということだ。

漁師は自分たちの食べ物を確保するために漁をしているのではなく、不特定多数の他人が食べる魚を獲っている。

一方で、趣味の釣り人は自分が楽しむために魚を釣っている。

どちらが偉いわけでもないが、他人の口に入るものを扱う以上、責任は漁師の方が遥かに重い。
それゆえ、面倒なこともたくさんしなければならないし、多くの技術を身につける必要もある。

どれだけ多くの魚を獲れるかという意味で、趣味の釣り人が漁師に勝てる日は来ない。やっていることのケタが違うのだ。

くり返すが、これはべつにプログラマーがノンプログラマーより偉いという話ではない。

視点を変えて、たとえばぼくは今編集を生業にしているけれど、その分野で言ったらぼくの方が漁師ということになる。

だから考えるべきは、趣味の釣り人が魚を釣るように、ノンプログラマーのぼくがプログラミングをかじったところでそれが何になるのか? ということだ。

その答えはある。

ぼくにとってのプログラミングはどこまでも趣味に過ぎず、その技術が毎日大量のトラフィックを重い責任のもとにさばいているプログラマーのそれを超える日は永遠に来ないが、それでもプログラミングを通してぼくの本業の生産性が高まったら、それはめぐりめぐって、プログラマーを含む社会への貢献を果たすことになるだろう。

何もプログラミングの世界で職業プログラマーに勝つ必要などなく、自分の生産性を上げたり、あるいは自分の人生を豊かにしたりできれば、それだけでも充分意味のあることなのだ。

ジェロニモと私

最後にもうひとつ、これを書いてこの記事を終わるが、その会話の最後の方で、「結局、ノンプログラマーがプログラミングを習得する方法としては、やっぱり仕事に取り込むっていうのが効果的なのでしょうか?」みたいな質問をもらって、それについてあらためて考えられたのもよかった。

ぼく自身がなぜプログラミングを続けてこれたのかと考えたら、それは「仕事に役立つから」というより、プログラマーの人たちがいつもなんだか楽しそうで、「あんな風になりたいな〜・・」と思ったからだった。

これは以前、吉祥寺.pmというイベントで発表したとき、そのスライドに入れるつもりだったものの結局時間がなくて削った話なのだけど、『キン肉マン』という漫画に出てくるジェロニモというキャラクターがいて、彼は本当は人間なんだけど、超人のテリーマンたちに憧れて正義超人の仲間に入って、しかしその後悪魔超人たちと闘ってメタメタにやられてしまう。

そこで出てくる名ゼリフに、「だってオラは人間だから」というのがあって、ノンプログラマーでプログラミングなんてやってると、そんなのばっかり。

プログラマーと自分とではまったくいる場所が違うというか、素地が違うというか、土台が違いすぎるので相手にならない。ツライ。

だけど、大事なのは勝つとか負けるとか、誇らしいとかみっともないとかではなくて、そのジェロニモテリーマンとかキン肉マンとかに対して抱いたような「憧れ」があるかどうかなのだと思う。

プログラミングをやる理由が「仕事に役立つ!」というだけだとちょっと弱くて、それだけだと「だって人間だから・・」みたいな感じでつぶれちゃう。くじけてしまう。そんな気がする。

だけどそこに、「憧れ」が残っていたら続けられる。というか勝手に続いていく。

それはべつに特定の誰かに対するものでなくても、ぼくだったらテクノロジーを味方につけることで稀に体験する、「それまで100日かかっていた作業が5分で終わった」みたいな劇的な変化への憧れというか、希求がいつもある。

ぼく自身が経験的に責任をもって言えるのはそこまでなんだけど・・と、そういう話をした。

その他のトピック

上記の機会では、相手の方からのコメントが本当にどれもクリエイティブ&丁寧なものだったので、普段考えていることをどんどん話すことができて、他にもたくさん面白い会話をしたのだけど、ひとまずここまで。

YAPC::Okinawaについては、前夜祭やイベント翌日のハッカソン、その後のお土産屋めぐりや、そもそものプロポーザルに至る話など、まだまだトピックはあるのだけど、その辺はまた時間ができたら、続編として書いてみたい。

*1:P19.「Finderは疲れる」というあたりなど。

tigの車輪の再発明

複数ファイルが立ち並ぶディレクトリにおいて、1つまたはいくつかの限られたファイルだけを`git add`したいという場合、いちいちそのファイル名を打ち込んでいくのがメンドイ。

https://i.gyazo.com/2ea3f4f42a20f00f66837cef4191a00e.gif

こういう時、peco的なものでバッとリストを出して、インクリメントに対象を絞り込みつつ直感的に選択できないものか? と思っていた。

で、こういうのを作った。(コマンドは`ga`)

https://i.gyazo.com/b41528b638db51e86643b50d41c2f6c1.gif

Perl製。
とくにリポジトリを公開したりしていないので、生コードはこんな感じで。
(.bashrcと組み合わせる)

# .bashrc
function gi {
    local arg="$@"
    local pick=$(perl /path/to/gi.pl)  #パスは任意の場所で

    if [ -z "$pick" ]; then
        echo Canceled.
    elif [ -z "$arg" ]; then
        echo Input a command.
    elif [ ! -z "$pick" ]; then
        git $arg $pick
        if [[ "$arg" == add ]]; then
            echo Add $pick
        fi
    fi
}
alias ga="gi add"
alias gr="gi reset HEAD"
#!/usr/bin/env perl
#
# gi.pl
use strict;
use warnings;
use feature 'say';

my $status = `git status`;
my @msg = split /\n/, $status;

my $msg;
my %msg;
my $marker = '';

for (@msg) {
    if ($_ =~ /\AChanges to be committed:/) {
        $marker = 'staged';
    }
    elsif ($_ =~ /\AChanges not staged for commit:/) {
        $marker = 'not staged';
    }
    elsif ($_ =~ /\AUntracked files:/) {
        $marker = 'untracked';
    }

    if ($_ =~ /\A\t(.+)\z/) {
        $msg = $1;
        if ($marker eq 'staged') {
            if ($msg =~ /\A(.+):\s+(.+)\z/) {
                $msg{$2} = 'staged';
            }
        }
        elsif ($marker eq 'not staged') {
            if ($msg =~ /\A(.+):\s+(.+)\z/) {
                $msg{$2} = $1;
            }
        }
        elsif ($marker eq 'untracked') {
            if ($msg =~ /(.+)\z/) {
                $msg{$1} = 'untracked';
            }
        }
    }
}

my @result = ();

while (1) {
    my @list = ();
    my $list = '';

    for (sort keys %msg) {
        push @list, "$msg{$_}:\t$_";
    }
    $list = join "\n", 'OK', @list;

    my $selected_line = `echo "$list" | peco`;
    chomp $selected_line;

    my $selected_status;
    my $selected_file = '';

    if ($selected_line =~ /\* (.+):\t(.+)\z/) {
        $selected_status = $1;
        $selected_file = $2;
        shift @result;
    }
    elsif ($selected_line =~ /(.+):\t(.+)\z/) {
        $selected_status = '* '.$1;
        $selected_file = $2;
        push @result, $selected_file;
    }
    delete $msg{$selected_file};
    $msg{$selected_file} = $selected_status;

    if ($selected_line =~ /\A(OK|)\z/) {
        if ($selected_line eq '' || ($selected_line eq 'OK' && scalar(@result) == 0)) {
            @result = ();
        }
        last;
    }
}

print "@result";

`gi`の後に何らかのgitコマンドを入れれば、選択したファイルに対してそれをする。

ここでは事前にエイリアスを設定して、`ga`と打てば`git add`、`gr`と打てば`git reset HEAD`になるようにしている。

何度も試しながら、結局半日ぐらいかかった気がするが、ひとまず「ん〜、いいじゃん、こういうのが欲しかったのだよ」と満足できる感じにはなった。

が、そこまで来てからふと、「しかし普通のプログラマーたちが毎日そんなメンドイことをしてるはずがないな……皆どうしてるんだろう?」と思った。
まあIDEや各種エディタ、あるいはGUIツールを使っている人なども少なくはないだろうけど、ターミナル操作で済ませている人も多いだろうしなあ、と。

そこでようやく、時々耳にするtigというツールを使えば似たようなことが出来るかも? と思い至り、簡単に調べてみた。

qiita.com

上記でほぼ把握。自分の手元でもやってみた。

https://i.gyazo.com/0d10e3b193ff13468148dca7ca2da9a9.gif

最初に`tig`と打つと、`git log --oneline`的な画面が出てきて、そこで`S`(Shift+s)を打つと`git status`の情報が出てくる。

そこでjk(上下)移動しつつ目当てのファイルの上で`u`を押すと、さくさくステージ/アンステージしてくれる。
めっちゃお手軽!

Vimとほぼ同じ動かし方なので、直感的に使える。
pecoのようなインクリメントな絞り込みはできないけど、必要十分とは言えるだろう。

何より、上記ではaddだけやっているけど、このtigにはその他のgit系機能も盛りだくさんである。
先ほど`git blame`を試してみたけど、これもけっこう目覚ましい体験だった。

これがあるとわかっていれば、わざわざ冒頭のようなコードも書かなかったなあ……と一瞬思ったが、でもどうだろう。

初めからtigを使っていたら、tigの「使い方」には詳しくなったかもしれないけど、コードを書く技術は上がらなかっただろう。

ぼくが望むのは確かに「直感的に`git add`すること」だったけど、同時に「コードをより上手に書けること」も求めていて、言い換えると、ぼくが最終的に求めているのは道具の「使い方」ではなくて「作り方」を知ることなのだと思える。

最新のガジェットやそれらを「使いこなす」ことにあまり興味を持てないのもそのことと関係している気がする。

さらに突き詰めて考えるなら、ぼくが欲してるのは「自由」なのだとも思う。

最新のガジェットに興味がないとは書いたが、そうは言ってもiPhoneが初めて日本で発売されたとき(2008年の6月とかだった)、ぼくはまだソフトバンクで機種変更してから半年ぐらいしか経っていなかったけど、迷わずiPhoneを予約してすぐ交換した。

じゃあなんだ、新しいガジェットに興味あるじゃないか、とも言えるが、それを買ったのは「絶対的に未知の体験を死ぬ前に味わっておかなくてはならない」と思ったからで、それは「現在という束縛からの逃避・逸脱・自由」を求めてのことだったと思える。

他人が作った道具を使うというのは、結局どこまで行っても作り手の想定の範疇から抜け出せない行為のように感じられて、あまり強い欲求が生じないのかもしれない。

たとえば作り手がその大元のルールを変えてしまったら、せっかく覚えた使い方も無効になってしまう。その不自由さがいやなのだ。

それよりは、シンプルで小さな道具を自分なりに組み合わせて、他の誰も使わないかもしれないが自分に最適化された、自分にとって最高の道具を作り、それまでの人生で味わったことのない体験をしたい、という気持ちがある。

プログラミングにはそういう欲求を駆り立てるものがあるようで、「作ること」と「それを使って体験すること」とのバランスが絶妙に感じられる。

[PR] YAPC::Okinawa で発表します

その話と直接の関係はありませんが&次にいつブログ書けるかわからないのでこのまま書いてしまいますが、3/3に沖縄で開催されるYAPC::Okinawa 2018 ONNASON で登壇することになりました。

yapcjapan.org
http://yapcjapan.org/2018okinawa/talks.html#/detail/10

チケットは完売とのことですが(おめでとうございます!>各位)現地に行かれる皆さんにおきましては、ご興味ありましたらぜひお越しください!