色々行ってきた

タイトルが雑ですが、コミティア→コミックZIN→絵師100人展→ヨドバシでした。

5/5は午前中にubuntuを18.04にし、病院行こうと思ったらGWなので休んでいて断念、コミティアに行く、秋葉原に行く途中で迷いつつも秋葉原に行ってコミックZINさんで同人誌買い足し、絵師100人展に行く、ヨドバシでHHKBとVOICEROIDを購入するという、歩くと財布が薄くなる（実際にはカードだから平気（平気じゃない））という生活でした。

Ubuntu 18.04 LTS

良いですね。今日5/6もいじってます。R環境、python環境まわりを。cudaまで終わった。が、keras動かせねぇと意味ないのだよ…。

コミティア

去年は技術書典には行ったものの、それ以外の創作系は冬コミから行ったことがありませんでしたので、久々のイベント…。
14時くらいに着くように行ったのですが、それでも結構人がいましたね。そして、暑い。夏コミ行ったことないけど修羅場になるんだろうな…。

目的はちゃんと果たした。会場にいたらしい電子回路工作勢の方とはエンカウントできませんでしたが…（私自身は全然工作してません、はい）

次はMFT2018ですかねー。楽しみ。

まぁ、それ以前に何か工作イベントがあれば、そこでお会いできるかもしれませんね～

時間の許す範囲で会場をぐるっと回ってきましたが、この大きな会場に、これだけの人が思い思いに自分の創作物を持ち寄って…という場と空気が最高でした。もっと早く行くべきだったよな…。
そして、５－６か所刺さる絵柄があって、思わず購入しそうになりましたが…無限に沼が増えるのでやめておきたい。電子化されていて、作者さんにお金が入る仕組みで、なんとか（絵は無限に増えて場所を取るので。本は…本もだけどさ……）

コミックZIN

コミティアの会場でZINさんの中の人とお話して、技術書典の本は順次はいってきそうということで、とりあえず行ってきた（）
結果、気になっていた2冊と見たことなかったのを1冊。買いすぎじゃない？

また来月くらいに行ってみましょうかねー

ヨド

HHKB買ってしまいました。既に東プレ2台あるのにね…。まぁ良いのだ。 そして、VOICEROID2を買ってきました。ゆかりさんがいなかったので茜・葵ちゃんを。早速触ってみましたが、感情表現対応ということでパラメータ振ってみてましたが、聞き比べたらわかるんだけど…イントネーションいじらないとわからんかもな。あと、関西イントネーションがわからなくて標準語だけで作りそうです。

一応個人向けの商用ライセンスがあるんですね。

VOICEROID 個人向け商用ライセンス｜製品情報｜AHS(AH-Software)

これ、先日のインフラ勉強会がきっかけの1つになってます。結構自然になるもんだなーって思ったので。
ボカロから調整も出来るんですが、パラメータが多すぎてねぇ…。その点、こちらは喋ることに特化しているので簡単にそれらしく喋ってくれるのが良いですね。

勉強会とかだと商用ライセンスには触れないと思うんだけど、半導体のお勉強とかのコンテンツ作るなら…考えるかな。

まぁコレでしばらくの砂漠生活を乗り切れるのではないかと思います…。何せ次の祝日は7月の後半ですからね…HAHAHA...

乗り切ろう。

B5サイズのブックカバーを購入した

これで同人誌を傷つけずに読むことが出来る…

B5サイズのビニール？のブックカバー、普通に文房具屋さんで安価（2-300円くらい）に手に入るものなのですねぇ。技術書典で購入した同人誌、B5サイズのモノも多く、通勤時に読んでいるとやはり角にダメージがあったりして悲しい（しかし読むためには仕方がないと割り切っている）のですが、これでノーダメージで読み進めることが出来る…うれしい…。

というお話でした。

これ以外にもブックカバーをいくつか購入。ブックカバー、書けたまま積読に再度回される本があるためにいつも行方不明になりますね。いったい僕はいくつのブックカバーを購入し、そして失っていくのか…

それとは関係なく買った文庫本サイズのブックカバーもある。ねこ柄がかわいいので。最近文庫本読んでないなぁ…。

(R) Rでファイルを扱うfsパッケージを使う (1回目)

とりあえず触りだけ…

さて、r-libには色々と便利なパッケージがあるのでたまに覗いてみると新しいパッケージがあったりして（たとえばioパッケージとか）面白いですね。ということで、今回は（長らく放置していた）fsパッケージの話です。
内容はREADMEの適当な訳みたいになってます。

fsパッケージとは

GitHubのレポジトリはここ github.com

CRANにも上がっています¹。Rにはファイルを取り扱う関数は色々あるけれども、例によって関数名に統一感がなかったり²、OS、プラットフォーム毎に出力結果が異なったり、明示的なエラーを返さない³など色々と使い勝手が悪いところがあったようです。それをこのfsパッケージではプラットフォーム間の違いを吸収したり、エラーを明示的に返したり、関数名を整然とさせたようですね。詳しくは上記のリンク先のREADMEに書いてあるので読んでみてください。 とはいえ、ファイル操作系の関数はあまり使ったことがないので使っていって慣れていくかな…。

fsパッケージを使うメリット

これもREADMEに書かれている通りですが、 * 全てのfsの関数はベクトル化されている（旧来の関数はそうではないのか） * 全てのfsの関数はパスの文字列のベクトル、パス名と同じ名前付きの整数か論理型のベクトルを返す。（旧来のは論理ベクトルやエラーコードを返すらしい） * 明示的にエラーを返す。（旧来のものはwarningを返したりOS依存のエラーコードを返すらしい） * UTF-8を常に使うようになったようです。受け取ったものはUTF-8に変換するし、返すときもUTF-8。旧来のモノはOSに依存した文字コードを返すようですね * 関数のネーミングルールがわかりやすくなっています。(例として、path.expand() vs normalizePath(); Sys.chmod() vs file.access()があげられていました。確かに全然わからん)

みたいなことが書かれていますね。RのOS依存の動きってのが結構きつくて、先日もwriteLines()でUTF-8のファイルをWindows上で出力しようとして辛さを感じました（解決済みですが）

パスについて

READMEにはTidy Pathsって書いてありますね。はいはい、tidy,tidyといった気持ち⁴。 ファイルパスの区切り文字⁵には常に/を使うようです。\は使わない。あと//とかにもならない…らしい。
あと、ファイルの種類やパーミッションによって色が変わるらしい（ただし、ターミナルがサポートしていればという条件あり）

使い方

対象としているファイルの種類によって関数名の最初の文字が変わるように作られています。これはRのコンソール上での補完をするときに便利かもしれません。 * path_ はパスの操作に * file_ はファイルの操作に * dir_ はディレクトリに * link_ はリンクにそれぞれ対応している。

実際に使ってみる

READMEはまだ続きますが、実際に使ってみた方がわかるだろうということで。

library(fs)

# linuxのlsコマンドと同じようにカレントディレクトリに存在するファイルを返す。
dir_ls()
#> fs_test.Rproj

# Rディレクトリを作成する
fs::dir_create("R")

# 出来たことを確認。ファイルの種類やパーミッションなどで色が変わるので便利(winだとパーミッションとは…？状態）
dir_ls()
#> fs_test.Rproj R             

# ディレクトリ下にファイルが存在しない場合はcharactor(0)が返ってくる
dir_ls("R")
#> character(0)

# Rディレクトリ下にファイルを作成する
fs::file_create("R/hoge.txt")

# 出来ていることを確認。
dir_ls("./R")
#> ./R/hoge.txt

# カレントディレクトリを変更する
setwd("R")

# R/がカレントディレクトリなので、dir_lsの結果はR/下のファイル
dir_ls()
#> hoge.txt

# 今いるディレクトリに依らずに、プロジェクトのファイルを参照したい場合はhere::here()と組み合わせる
# ただし結果はfull pathになる。
dir_ls(here::here())
C:/Users/niszet/Documents/r work/fs_test/fs_test.Rproj C:/Users/niszet/Documents/r work/fs_test/R   

# path_file() で囲うとファイル名だけを取り出せる。
path_file(dir_ls(here::here()))
fs_test.Rproj R      

と、ファイル処理なので無限に例が書けますね…。基本的にlinuxで使っているコマンド群になれていれば、それに対応する関数があるはずなので、あまり違和感なく使えるのではないか？と思います。

個人的には何気にpath_系がかなり便利な気がします。

今回は触りだけでしたが、このパッケージ使えるようになるとコンソールから動かずにファイル処理が出来てとても良いです。画期的。

ファイル名に色が着くことはてなブログでは表現できないので、適当にggbode作業dirのキャプチャ画面でも⁶。環境に依っては色が違うかもしれませんね。これもどこかで設定できる（か、上書きして乗っ取ることが出来る）はず。

RとRmd、pngとjpgがそれぞれ同じような色分けになっていたり、ディレクトリや圧縮ファイルも色付けされているものの、exeやpdf、ショートカットファイルであるlnkなどは色づかないことから、多分内部で拡張子毎に色付けをしているのですね。が、対応するコードを見つけられず。どこにあるんだ…。

2回目はいつになるかなぁ…

Enjoy!!

---

1. そういえばGitHub版はdevtoolsじゃなくてremote使った方が格好良かったりする？↩

2. 後から必要に応じて関数が追加されていったという歴史的背景があるようですが…↩

3. あってるかな・・・↩

4. 最近はもうtidy疲れって言わなくなりましたか…？↩

5. 何て呼ぶのが良いのか…↩

6. ファイル名については突っ込まないで…。↩

(R) suppressPackageStartupMessagesでライブラリをアタッチする際のメッセージを抑制する

ただし、むやみに使ってはいけませんよ…

さて、いくつかのパッケージは`library()'で読んだ際に（警告を含む）メッセージを出してきます。重要なメッセージの場合もありますが、既に確認済みで「問題なし」と判断できている場合は毎回出てくるメッセージはうざったいことがありますよね。

例えばこういうのがライブラリを読み込んだ時に出てくるわけです。

library(tidyverse)
#> -- Attaching packages --------------------------------------- tidyverse 1.2.1 --
#> √ ggplot2 2.2.1     √ purrr   0.2.4
#> √ tibble  1.4.2     √ dplyr   0.7.4
#> √ tidyr   0.8.0     √ stringr 1.3.0
#> √ readr   1.1.1     √ forcats 0.3.0
#> -- Conflicts ------------------------------------------ tidyverse_conflicts() --
#> x dplyr::filter() masks stats::filter()
#> x dplyr::lag()    masks stats::lag()

まさかのtidyverse名指し批判。ちなみにRが3.5.0になっていないのは1か月くらい様子見している期間を入れているためです（パッケージの移行が、ね…）

Rmd中の場合、knitrのchunk optionでinclude=FALSEの指定をするとこの（に限らず、Rのコードの処理の結果どれもが）出力が抑制されるのですが、それ以外のシーンでも抑制したいなーということがあるはずです。

こうします。

suppressPackageStartupMessages(library(tidyverse))

これで上記のような表示が一切なくパッケージを使うことが出来ます。

同様に、関数内部で'message()'や'warning()'によって発せられたメッセージや警告については下記の関数で抑制¹できます。

suppressMessages()
suppressWarnings()

何度も書きますが、メッセージや警告はパッケージ作成者がわざわざ出しているメッセージですので、それを無視して本当に大丈夫であることがわかっているときだけ、これらの関数で抑制しましょう。
「おかしな結果が出るなぁ…？」からの「実はwarning出てたじゃん…！suppressしてた…orz」までの流れは様式美です。気をつけなされ・・・

Enjoy!!

---

1. 実際のところは無視しているのか非表示にしているのか…？warnings()で確認できるだろうか？↩

(R) 再現性を確保するためにdrakeパッケージを使おう、らしいですね…？

まだよく分からない…

先日の記事

niszet.hatenablog.com

にもちょっとだけ書いた、drakeってパッケージ、

github.com

を、つかいはじめているものの、イマイチ使い方を理解しきれておりませぬ。

そんななか、TwitterのShinyappsRecentのつぶやき、

New Shiny App: one supporting drake itself https://t.co/xYFc0cTOHF #rstats pic.twitter.com/wTS7MhEC9o

— Recent Shiny Apps (@ShinyappsRecent) 2018年4月28日

で、shinyのアプリでdrakeのtutorialがあることを知りました。

https://krlmlr.shinyapps.io/cooking-drake-tutorial/

正直drakeパッケージ公式のvignetteとかReadmeは読んでも良く分からないところがあるので（なんとなくはわかる）、手を動かして体験できるのは良いですね。

一応、Rmdに対しても使えるようで、 Rmdファイルの例として、テンプレートで生成される下記のコードを含んだファイルをhoge.Rmdとして保存し、

---
title: "Untitled"
author: "niszet"
date: "2018年4月29日"
output: html_document
---

\```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)
\```

## R Markdown

This is an R Markdown document. Markdown is a simple formatting syntax for authoring HTML, PDF, and MS Word documents. For more details on using R Markdown see <http://rmarkdown.rstudio.com>.

When you click the **Knit** button a document will be generated that includes both content as well as the output of any embedded R code chunks within the document. You can embed an R code chunk like this:

\```{r cars}
summary(cars)
\```

## Including Plots

You can also embed plots, for example:

\```{r pressure, echo=FALSE}
plot(pressure)
\```

Note that the `echo = FALSE` parameter was added to the code chunk to prevent printing of the R code that generated the plot.

以下でplanを作成、make()してconfigを作って依存関係を表示すると、

plan <- drake_plan(
  rmarkdown::render(
    knitr_in("hoge.Rmd"),
    output_file=file_out("hoge.html"),
    encoding = "UTF-8"
  )
)
make(plan)
config<-drake_config(plan)
vis_drake_graph(config)

のように表示されました。ので、Rmdであっても一応動くようです。

20180430 1510追記

ここで、Rmd中に日本語が含まれているとNGという形で書いていたのですが、yutannihilationさんから

render()に関しては、encoding="UTF-8"でいけたりします？

— Hiroaki Yutani (@yutannihilation) 2018年4月30日

とご指摘いただき、試してみたところうまくいきました。Rmd->htmlへの変換のrender()部分でencodingの指定さえしていれば変換自体は問題なく動作しました。上記コードにはそのオプションも追記している形で、Rmdの日付も日本語の表記にしておきました。お試しください。

ただし、drake自体は日本語を受け付けていないような挙動があったので、調査中です。ソース中のコメントに日本語が入っているとダメだった気がするので…。これの再現性を確認しないといけないですね…。

あと、Rmd中でデータのimportをしている場合にその依存性を検知していない（はず）です。具体的にはread_csv()'とかで読んでいるファイルが変化してもmake()が反応しない、とか。これも調査中です。最終的には成果物をRmdにして管理したいので、drakeとRmdをうまく共存させたいのですよね。単なるプロジェクトとしてならばdrake`で十分管理できるとは思うのですが。

パッケージ化とかパッケージのバージョン管理とかの話もあるし、どのタイミングで何をどう管理するのが良いのか？がまだ良く分かりません…精進。。。

20180430 1510 追記ココまで

そして、たまに暗黙の依存関係を解決できない旨のwraningが出たり、htmlを出力出来ているのにdrake側からそれを検知できないということがあります。

再現可能なコードを作ってissue投げたいんですが、うまく再現しないこともあるのでちょっとコードを理解しないとこれは厳しいか…？？

再現可能な環境の作成は大事なので、ちょっと頑張る…かも。

Enjoy!!

WI-1000Xがたまに接続できなくなる…

再現性がまだとれていない…。

先日購入した、WI-1000Xというヘッドホン（イヤホン）ですが、機能・性能面では非常に満足しています。音が良いしノイズキャンセリングがかなり良い感じに周りの音を消してくれます。とくに居室での装置音が気になっていたのですが、これをつけるといっきに「シン…」となります。びっくり。

niszet.hatenablog.com

n=2、同一個体にて。

が、過去に2回あったのですが、Bluetoothでの接続がどうやってもうまくいかなくなる（ペアリングの開始でコケる）時があります。この時はマニュアルを参照してリセットをかけて再度ペアリングしました。なので、故障が起きたわけではなさそう。

心あたりとしては、接続状態で電波の届かないところまで離れてしまったことで、2回目はこれの直後に接続できなくなったので、おそらく…。

本体は接続していると思っていて、しかしヘッドホン側は切れている（と認識している）ので、実は本体側の問題かもしれませんね。本体は接続状態が維持できていると感じているので、同じID（実装が何かは知らない…MACアドレス？）のペアリングを許可してないんでしょうね。

まぁ、原因がわかっていれば特に問題はない（本体の電源を切ってから離れる、問題起きてもリセットで解決する）ので、相変わらず快適なミュージックライフってやつでした。

(R) Rで名刺を作る、をやってみた

未完の大作…。なお、これはリスペクト記事です。

先日のTokyo.Rと技術書典では首からカードをぶら下げて参加しました。
僕は人の顔と名前を一致させるのが苦手で、よく名前が分からなくなります。TokyoRは自己紹介タイムがあるものの、60人いたら確実に覚えられません…。「なんか、〇〇をやっているって言っていた人がいたような…？？」みたいな、エピソード的なものは覚えているのですが…。

でもまぁ、交流はしたい。LTで発表したとしても、誰が誰だっけ…？となるので、状況は同じ。…ということで名刺です。
nizetは若干ツイ廃なので、このアカウントのアイコンを表示しておけば、あぁ、あの〇〇〇〇の人…¹！となることうけあいです。

ということで、こちらのill-identifiedさんの記事をパクリリスペクトして、自分用の名刺を作るべくやってみました。

ill-identified.hatenablog.com

結果はこんな感じ。

名刺じゃなくて、首から下げるカードにしたのは前日に作ったので発注が間に合わなかったからです！計画的にやろうね！

名前が若干大きめになっています。これは、首から下げるのである程度遠くから見ても分かるように、です。
メールアドレスは公開するもんでもないでしょ…と思ったので伏せました²。 次回はちゃんと名刺作って配ろう…！

Enjoy!!

---

1. 何が入るのかはお楽しみ↩

2. ていうか、よく見たら間違ってたわ…配布しなくて良かった～…↩