分析、研究パイプラインを真面目に考える

課題感

様々な分析しごとをどうオーガナイズするかめちゃくちゃになっているのでルールを決めたい。

現状

研究

• jupyter notebookかRmarkdownで実施。コードを書く前に動作を確認したいときはSQLミドルウェアも使う。
• Pythonコードはgithubで管理。
• 最近あまりやっていないがJuliaもgithub
• 報告についてはスライドを作成するか、Rmarkdownそのまま
• 社内打ち合わせはjupyterでやってしまうことも多い。
• 日報的な感じでesaを使っている。論文の概要とかはesa
• 最終アウトプットはoverleaf
• 紙のノートも使う。特にうだうだ考えたり計算したりモデル書いたりするとき。

分析

• jupyterかRmarkdown
• 報告のときはスライド

問題点

• 正直どれを使うか迷う。
• そしてあとから見返すときにどこに何があるかわからない。
• スライドを作成するのが億劫（ただし、どこに何があるかわかっていればそれほど辛くはない）
• スライドがダサい
• esaの使い所がわからないが、社内共有にはこれしかない
• ちょっとしたアイデアを書く場所がない。

考慮すべき点

• jupyter, Rmdは離れられない。
• jupyter, Rmdはメモ的な扱いにしたいが、あとから検索可能性が上がるようにしたい。
• どこにあげるかを決めたい。
• esaの共有性をどうするか
• データ→分析メモ→アウトプットを円滑に進めたい
• 一人仕事と複数人仕事で状況が変わる。

新ルール（仮）

• とっかかりはrmdかjupyter。
• 検索可能性が上がるようにproject毎にまとめる。
• projectごとにレポジトリを作る
• 作業のおおまかな計画的なやつはreadmeを更新していく。タスク管理はgithubのissueを使う
• rmdもjupyterもファイル名に日付をいれる。"[prjname]_20190201.{Rmd|ipynb}"
• 日付ごとに作り直す。
• esa, google suit, overleafは用途に応じてメモからつくる
• 社内向けや時間がない場合はjupyterはcolaboratoryに変換してシェア。rmdはpdfにする

一旦これでやってみる。

jupyter ルール

• 新しいことをするときは新しくノートブックをつくる。
• コードを再利用するときは新しいものに貼る
• importは作業の直前。重複しても可。（セルで独立して仕事ができるようにする）
• 日付をいれる
• 一度実行したセルは修正しない
• エラーを消さない
• はじめにやることを書いておく

pandas join merge concatではまったこと

pandasは便利だが、結合あたりが非常にわかりにくい。 いい感じにやっておいてほしいところが全然やってくれない。

concat:

indexがビシッと揃ってる場合はこれで大丈夫。

join

これが使いづらい。sqlの雰囲気でやるとハマる。近づかないほうがいいかもしれない。

mege

一番まし。ただし、型が違うとダメ、カラムが複数レベルになっている場合はdataframe.column.droplevel()しないとダメ。

■

結局プログラミングは時間かけるしかないという気がしてきた。 最近、システムのアーキテクチャを考えて設計図書いてからコードを書くことが多いけど、こういうのも何回も実際にものを作ってみないと書けなかった。 Python歴は１年ちょっとだが、ようやくQiitaに書いてないこともできる気がしてきた。１年はかかるって感じかな。

■

今回の統計問題、ビッグデータ推進派にはむしろ朗報かも。サーベイデータや、その加工に問題が多いのであれば、できるだけ人手のかからない間違いの少ない方法でやるしかない

Zoteroとsugarsyncで文献管理をする

年も改まったことだし論文管理環境を再構築する。

もともとmendeley派だったが、色々トラブルが多く一度Zoteroに以降した。ただ、ZoteroとSugarsyncを並行して使っていたためおかしなことに。

丸一日格闘した結果、Zoteroの動作をようやく理解したのでメモしておく。

Zoteroの文献管理方法は独特で、文献のメタデータを「データ」と呼び、PDFファイルなど文献本体は「ファイル」と呼ぶ。 「ファイル」は「データ」の添付として扱われる。 例えば、Taro Yamada (2019) "super cool research"という文献があった場合、"著者：Taro Yamada, 刊行年:2019, タイトル: super cool research"がデータ、"Yamada_2019_super_cool_research.pdf"はファイルと呼ばれる。

すでにローカルに保存されてあるファイルを、Zoteroにドラッグアンドドロップし、右クリックでメタデータを読み込むを選択すると自動的にメタデータから文献情報ファイルを作ってくれる。これがデータだ。

このデータ自体はホームディレクトリ以下のZoteroのおそらくsqliteファイルに保存されている。なので、sqliteをコピーすれば文献情報を共有することができる。

PDFデータ、つまりファイルはどうなるのか。これが厄介で、Zoteroはファイルを一旦Zoteroディレクトリ以下のstorageディレクトリにコピーしていく。ファイルのリネームを行ってももともと読み込ませたPDFは変わらずstorage以下のファイルの名前が変わる。

このデータとファイルの二元管理がSugarsyncとの相性を悪くしている。つまり、「データ」であるsqliteとローカルのPDFファイル群を別のPCと同期してもZoteroは「データ」とローカルのPDFファイルを紐付けることができない。「データ」に書いてある「ファイル」の所在はstorage以下のファイルになっているからだ。

これを避けるためにはいくつか方法があるが、一番簡単なZoteroのオンラインストレージを使う方法を今回は用いない。お金がもったいないからだ。これから述べるのはもともとのSugarsyncを用いてPDFをsyncする方法だ。

１からやり直したいのでZoteroデータを一旦全消去する。Zoteroディレクトリにあるsqliteやストレージを全て削除。たいていホームディレクトリの直下にあるはず。

ローカルが綺麗に削除されたらオンラインライブラリのリセットにうつる。

Macの場合、環境設定から同期タブをクリックし、さらにリセットタブをクリックするとこの画面になる。

zotero

「多くの場合、リセットすることでさらなる問題を引き起こす」と、やや恐ろしい説明が書いてあるが無視する。 オンラインライブラリを上書きする、を選択してリセットする。

この時ウェブのZotero.orgにログインしてマイライブラリを確認するとすごい勢いでメタデータが消されていくのがわかる。

すべて削除できたら完了。

一旦Zoteroを削除して再インストールする。しなくてもいいかもしれない。

再構築に入る。まずいちばん大事なことはZoteroのオンラインストレージを絶対に使わないことだ。設定はこうだ。

全文を同期するはオフにする。また下部のストレージどうのこうのすべてオフだ。これで「データ」のみ同期してくれる。

Zoteroのストレージのフリースペースは300MBしかないのでそもそもまともに使えないし、Sugarsyncによる同期と輻輳して変なことになるのを避ける。

次に、Sugarsync側の設定で、ホームディレクトリ以下のZotero/storage/ディレクトリのみを同期する。sqliteなどはZoteroがオンラインサーバー経由で同期するの無視する。¹ 繰り返しになるが、Zoteroが見に行くのはZotero/storage/以下のファイルだ。これを同期する。もともと保存してあったPDF群は同期をやめる。

個人的にはいつかZoteroをやめるかもしれないのでPDF群自体は廃棄しないが基本的にはもう使わない。

---

1. そもそもZotero側で同期を使わずにすべてSugarsync側に任せるという方法もありうる。↩

■

正月後やる気が出ない。寝てばっかり。と思って過去の１月の日記を見ると、割と頑張っていたようだ。歳か？？