昨日の夜くらいから接続できなくなって、今もできない。 Facebookもなぜか恐ろしく重い。
まぁこれはいいとしても、techbookfest.orgが見れないので困った。。。
しかし、hatenaやgithubは見れる…。何か遮断されているような感じに…(PC/タブレット共にダメ)
ぬおぉどうすれば・・・
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 MarkdownのチャンクにPythonが使えるようになったことは有名?ですが、他にも様々な言語で使用できます。
そのなかで、nodeが使えるわけですがこれについての記述が探しても見つからなかったで書いておきます。
いわゆるワンライナーが走るような状態です。結果は'-e'オプションだと結果は返ってこないみたい。なので、nodeで何か処理をして外部ファイルに書き出してそれを使うみたいな方法が良いかな、と。何か設定できるかもしれないけど。
当然ながら、チャンクの中身を実行するための各種ソフトウェアはあらかじめインストールされて使用できる状態になっていないといけません。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!!
そんなわけで、シンプルイズベストなページが公開されました。
被チェック数は印刷する冊数の参考にするのでもし気になったらチェックをお願いします。正直、バッドノウハウだらけになってしまっている感がすごい。あと文才がなくてすごい。やばい。
とにかくそんな感じです。頑張ります(現在進行形
チェックリストがない。これはどういう状態になればよいのか、だれもわからない。これは本当に良い状態になったのだろうか?全部見た気もするけど自信がない。あれ?これ前回なおした気がするけどまたバグってる?おかしい。いったい何をすればいいんだ…。
よくある光景ですね。
まずは暗黙知を形式知へ変えていきましょう。まずはチェックリストですね。何をやったのかをリストアップしていけば、それがチェックリストになります。まずはこれを作る。
幸いにして、Markdownの書式でチェックリストが書ける。まぁ書けない拡張もあるんだけど。
早速書けなかった。まぁいいか。
チェックしたことを書く。このときに、何を、というかどういう項目をチェックしたのか、を分類しておこう。
みたいな。
とか。チェックリストの項目は、正しい状態で定義しても、間違った状態について定義しても良いが、統一した方が良い。あと説明は書くな。読みづらい。説明が必要ならば別途マニュアルを書くのだ。
チェックの完了報告ならば、正しい状態を定義したリストでよい。その方が日本語的にもわかりやすいし、終わった時に全てにチェックが入っていてよい気持ちになる。
道中、必要なタイミングでチェックをする。このときは次に引き渡してはいけないような問題をキャッチアップできるように、悪い状態を書いておく。具体的に書く。これが正しいタイミングで行われて、それが重要で、かつ具体的であれば効果がでかい。
これは、最終的な状態のリストが出来て、それを処理する時系列にまとめたあとに配分すればよいが、実際に手を動かしているのであれば、どういうフェーズでやったかを書いておけばよい。やったことは全部かけ。
最終的にはリストは長大になる。可能であれば項目を削る。しかし、その代わりにどこかに分離する。問題が起きたことであればいずれまた再発する。設計者が注意して対応する、では解決にならない。
チェックツールのログを見る、という話であれば、そのツールが見ている項目はサブチェックリストとなる。仕様を把握してリストアップし、このツールによるチェックがパスしていたらどの項目が信頼できる状態になっているか?をまとめよう。これらを階層化して管理しておけるならばそれが一番良い。
ツールでチェックできるようにするためには、入出力の仕様が必要。なので、ここで目視でチェックしている項目も、何をチェックしてどのような状態になっていればよいのか?の情報がまとまっているだけで、先に進めやすくなる。
そのために、まずはチェックリストを作っていくのだ。はよつくれ自分。
しかし、こういったことをやれる人が全然いない気がする。はじめは小さく始めればよいのに。長大なマニュアルなんて誰も読まないでしょ …?
というポエムでした。
昔、アナタはなぜチェックリストを使わないのか?を読んで、久々にチェックリスト作成のためのチェックリストを見直してみたけど、全然できてねぇのな…。
アナタはなぜチェックリストを使わないのか? | 晋遊舎ONLINE
まぁ、遊びがなさすぎるんでしょうね。なければ作ればよい。何事も。
さて、たまには緩い話を。
最近、このブログとかTwitterとかを監視見ていただいて方が増えてきたようなので、みんなも書こうぜっていう話です。
技術者…に限った話じゃないかもしれませんが、一度わかってしまったことって自分の中で常識化してしまって、新人や後輩に教えるときとかに「何がわかっていないのか」の前提が共有できなくなってしまったりしますよね。あとは特定の技術に対して、その下地になる別の多数の基本技術との関係とか。何がきっかけでわかるようになったのか、わからないときはどういうイメージだったのか、などなど。
そして、何かをまとめるとき、自分の中で常識化してしまったものはこのわかるようになる過程を書いていくのが結構難しい、というかもう覚えてないわけですから書けないんですよね。
一方で、トップダウン的に情報を整理整頓して階層構造、依存関係を明らかにしてまとめていくっていうのは"完全に理解した"あとでないとなかなか難しいのですが。
まぁ何が言いたいかって、「!?…わかったかも?」くらいのタイミングでブログとかにどんどんアウトプットしていきましょうっていう話で、↑に書いたみたいに理解してから書こうと思うと、わかる過程の感覚が書けないのです。こうやったらできた、とか、こうではうまくいかない…という記録が、わかる過程の記録です。書いておくとよいと思うのです。
もちろん自分が再入門("全部忘れた!"とき)するときも、役に立ちますね。
この、アウトプットする過程で情報をある程度整理して書かねばならないので、自分の理解がどこまでか?みたいなこともわかるわけですね。そして、不足している部分が見つかって、それを勉強する・・・と。
一方で、よくわかってからトップダウン的に整理整頓して書く時も、なんだかんだで抜けている部分があるので、そこも自分が振り返れるようにまとめておくのは良いのではないかなーって思うのでした。
という、まさに「!?…わかったかも?」のタイミングで書いている文章が↑なのでした。
これは雑記帳としての記事なのでこれでいいかな。本当はもうちょっと整理した方が良いですね。読みにくいから。
でも、読みやすい文章とは…とか構成…校正…みたいにやってる中の息抜き文章ということでここはひとつ。
作業にもどろう。
資料は公開しています。Rmdもあるので画像以外は使えるので、RMarkdown書く時のご参考に。
TokyoR 72 LTskimrとsummarytoolsパッケージの紹介
はい。
なんだかんだでスライドに収める部分が一番苦労しましたね…。skimrはヒストグラムが文字化けする、summarytoolsはそもそもほとんどカスタマイズできないので頑張って一枚に収まるように加工する、など。
発表でも説明しましたが、可視化という意味ではどちらも強いですが、欠測の有無の確認や分布の確認が同時にでき、結果をdata.frame(tibble)で渡せる点はskimrの強みです(summarytoolsは多分渡せないと思う…)
ぱっと結果を見るならsummarytools、使い込むならskimrじゃないかなと思います。が、どうなんでしょ
もっと詳しく説明できる部分があるので、まとまった時間が取れたときにでもQiitaあたりに記事を作っていこうと思います。
しばらくは技術書典に向けて全力なので、9月のブログの更新量はかなり落とすと思います(本当かな?
Enjoy!!