（技術書典5）niszet工房の宣伝のページ

大体できたな（）

イベント概要

というわけで、10月08日、技術書典にサークル名niszet工房として参加します。工房って言っても特に何かモノを作っているわけではないんですが。いずれはね…ということで。 techbookfest.org

なお、イベントの規模が大きくなったので場所は秋葉原ではなく、池袋サンシャインシティ2F 展示ホールD（文化会館ビル2F）となりました。ご注意を。駅からちょっと歩きますね。

内容

今回は、R MarkdownでWord文書を作ろうという、いったいどこに需要があるのかわからない内容です。
多分需要がないからですが、この辺りのまとまった情報がなくて今回調べまくっていました。しかし、PandocにしろWordにしろ、そしてRに関してもとても薄い本ですべてを説明できるような規模ではないなぁ・・・と改めて思いました。
今回は割と辞書的に使えるようにというコンセプトで作り始めたので、あまり初心者向けにはなっていません。まぁ良書がすでに世にありますから…。
ただ、環境を合わせる必要があるので、これをインストールしろあれをインストールしろと書いてあるし、サポートページにサンプルコードは載せて実際に手を動かせるようにはしたいので（そして、フィードバックを得て、情報を集めてよりよくしていきたい）色々とモリモリにしていきたいなぁと思います。興味があれば、サークルチェックしていただければ。部数、何冊にすればよいのかわからないので…。

技術書典5の弊サークルのページはこちら。 techbookfest.org

サポートページを作ってみた。中身はまだない。 github.com

一応、80Pくらい、800円くらいかなぁ？を想定しています。ちゃんと出ればね…。

あとは全体の校正、あとがきとかの細かい点の追加で終わりそう…。あ、表紙がないわ。やらなきゃ。

とりあえず目次はこんな感じです。たぶんもう大きくは変更ないかな、と。

まぁ、ゆるふわ系な内容なので…。ふ～んって感じで読んでもらえれば。あとマサカリください。

9/22

普通に目次変わりました。わっははは。あとは表紙を…まぁ適当でいいか。

Enjoy!

（雑記）何かを書くタイミングは2回ある

先日のつぶやきのはなし。

何かをわかりかけたタイミングと、理解し終わって全体を俯瞰することが出来るようになったタイミングとで2回。

何故か、わかってしまうと「何がわからなかったのかがわからなくなる」という現象が起こる。そのため、わかりかけて書けるタイミングになったところで書いておくとよい。何がわからなかったのか、何をしてわかるようになったのか。この時点では本当にわかっているわけではないかもしれない。でも、それも含めて書いておく。理解しにくいところという見方もできるから。

全体を俯瞰した書き方は、全容を把握していないと出来ない。そして、それらを整理整頓して書く必要がある。これはある程度理解が出来て定着したら書いた方がよい。これもまたどうせ忘れるから。

説明として聞いたときにわかった感がでるのは後者。しかし実際に手を動かすときに参考になるのは前者（わかっていない場合）になるので、どちらも大事。後者の場合は抽象化する（あるいは階層を上にあげる）ことが絡むので、実作業そのものから離れることがあるから、かもしれないけど。

前者の、わかっていないところの気持ちや作業の粒度感を失わずに、後者の視点を持って説明できるのが理想なんですけどね。まぁ、それでも書かないと何も始まらないので、とりあえず何か書きましょう。

というお話だったのさ。

この話もまだ、わかりかけの文章なので、これもまたいずれまとめ直す必要があるんじゃないかな。

twitterに接続できない…

昨日の夜くらいから接続できなくなって、今もできない。 Facebookもなぜか恐ろしく重い。

まぁこれはいいとしても、techbookfest.orgが見れないので困った。。。

しかし、hatenaやgithubは見れる…。何か遮断されているような感じに…（PC/タブレット共にダメ）

ぬおぉどうすれば・・・

(R) (node.js) Browserifyではchild_processが扱えない（という理解でよいのだろうか

V8を使ってやりたかった。

RのパッケージでV8というのがあって、Rから(shinyではなく）javascriptを動かすならこれかjsパッケージでやるっぽい。昨日のnode.jsを直接動かしていたのをRから動かしたかった。結局のところ、難しいという判断。

V8のvignettesにnode.jsのパッケージを使う方法が書いてある。

https://cran.r-project.org/web/packages/V8/vignettes/npm.html

node.jsはjavascriptを使ってブラウザ上ではなく実行できる（？）が、ブラウザ上で動かしたくなった時に不便。というか、require自体が素のjavascriptにないみたいなので、これを解決する必要がある。Browserifyを使う。

しかし、外部ファイルを実行するようなことは出来ないようだ。そもそもブラウザ上で動作するように考えられていたのだから当たり前かもしれない。よって、plantumlを実行することが出来ないので、V8をつかってRの方で閉じるやり方は出来なさそうで、昨日のやり方が正しそう。

ただ、nodeをチャンクで動作させる必要も特にないので、Rから単純に実行コマンドとして呼んだ方が扱いは楽そう。引数も与えやすいし。

ということで、ネタがひとつ没になった。まぁ昨日のを積み増しして書くんですけど。

(R) RMarkdownのチャンクでnodeを動かす

探しても見つからなかったので書く。

R MarkdownのチャンクにPythonが使えるようになったことは有名？ですが、他にも様々な言語で使用できます。

bookdown.org

そのなかで、nodeが使えるわけですがこれについての記述が探しても見つからなかったで書いておきます。

-eオプションがついている

いわゆるワンライナーが走るような状態です。結果は'-e'オプションだと結果は返ってこないみたい。なので、nodeで何か処理をして外部ファイルに書き出してそれを使うみたいな方法が良いかな、と。何か設定できるかもしれないけど。

nodeへのパスが通っている必要。

当然ながら、チャンクの中身を実行するための各種ソフトウェアはあらかじめインストールされて使用できる状態になっていないといけません。node.jsならここから入手してインストールします。

Node.js

内部で使用しているライブラリがあればそれもnpm installでインストールします。コマンドが通る必要があるならばグローバル環境にインストールするように'-g'をつけた方が良さそうです。node.js自体を実行するのでこの場合はbrowserifyは不要。browserify もグローバルにインストールしておこう。よく使うし。

あとはまぁ普通に

```{node}
var mkpuml = require('./mkpuml.js');
mkpuml.run()
```

の形で書く。呼ばれる側はexportsしないといけない。適当なメソッドに充ててあげればよい。exports.run = function mkpuml(){}のように。

とりあえず使えることがわかったのでこれも技術同人誌に書いておこうと思う。

RMarkdown側から動的に制御するならV8使った方が良さそう。その場合はbrowserifyを使う必要があるのでまぁ環境構築面が不安になってきますね。

Enjoy!!

（技術書典）サークルページが公開されました。

探すの大変そう…。

そんなわけで、シンプルイズベストなページが公開されました。

techbookfest.org

被チェック数は印刷する冊数の参考にするのでもし気になったらチェックをお願いします。正直、バッドノウハウだらけになってしまっている感がすごい。あと文才がなくてすごい。やばい。

とにかくそんな感じです。頑張ります（現在進行形

手を動かしながらチェックリストを作っていく

あらかじめ、チェックすべき内容がわかっていて言語化されていない場合の話。

チェックリストがない。これはどういう状態になればよいのか、だれもわからない。これは本当に良い状態になったのだろうか？全部見た気もするけど自信がない。あれ？これ前回なおした気がするけどまたバグってる？おかしい。いったい何をすればいいんだ…。

よくある光景ですね。

まずは暗黙知を形式知へ変えていきましょう。まずはチェックリストですね。何をやったのかをリストアップしていけば、それがチェックリストになります。まずはこれを作る。

幸いにして、Markdownの書式でチェックリストが書ける。まぁ書けない拡張もあるんだけど。

• [x] 書いたけどはてなブログでは有効にならないっぽい？

早速書けなかった。まぁいいか。

チェックしたことを書く。このときに、何を、というかどういう項目をチェックしたのか、を分類しておこう。

• [x] 日付がYYYY-MM-DDの書式になっている

みたいな。

• [x] チェックツールのログにエラーがゼロ

とか。チェックリストの項目は、正しい状態で定義しても、間違った状態について定義しても良いが、統一した方が良い。あと説明は書くな。読みづらい。説明が必要ならば別途マニュアルを書くのだ。

チェックの完了報告ならば、正しい状態を定義したリストでよい。その方が日本語的にもわかりやすいし、終わった時に全てにチェックが入っていてよい気持ちになる。

道中、必要なタイミングでチェックをする。このときは次に引き渡してはいけないような問題をキャッチアップできるように、悪い状態を書いておく。具体的に書く。これが正しいタイミングで行われて、それが重要で、かつ具体的であれば効果がでかい。

これは、最終的な状態のリストが出来て、それを処理する時系列にまとめたあとに配分すればよいが、実際に手を動かしているのであれば、どういうフェーズでやったかを書いておけばよい。やったことは全部かけ。

最終的にはリストは長大になる。可能であれば項目を削る。しかし、その代わりにどこかに分離する。問題が起きたことであればいずれまた再発する。設計者が注意して対応する、では解決にならない。

チェックツールのログを見る、という話であれば、そのツールが見ている項目はサブチェックリストとなる。仕様を把握してリストアップし、このツールによるチェックがパスしていたらどの項目が信頼できる状態になっているか？をまとめよう。これらを階層化して管理しておけるならばそれが一番良い。

ツールでチェックできるようにするためには、入出力の仕様が必要。なので、ここで目視でチェックしている項目も、何をチェックしてどのような状態になっていればよいのか？の情報がまとまっているだけで、先に進めやすくなる。

そのために、まずはチェックリストを作っていくのだ。はよつくれ自分。

しかし、こういったことをやれる人が全然いない気がする。はじめは小さく始めればよいのに。長大なマニュアルなんて誰も読まないでしょ …？

というポエムでした。

昔、アナタはなぜチェックリストを使わないのか？を読んで、久々にチェックリスト作成のためのチェックリストを見直してみたけど、全然できてねぇのな…。

アナタはなぜチェックリストを使わないのか？ | 晋遊舎ONLINE

まぁ、遊びがなさすぎるんでしょうね。なければ作ればよい。何事も。