Take Your Time

仕事や研究、コンピューターとの付き合い方

研究

無料でPrivateが使えるプランができた今すべてをGitHubにあげることを目標にする。

分析パイプライン結論?

delma.hatenablog.com delma.hatenablog.com 最近、Apple PencilでiPadに書きつけた手書きのメモをjupyterで from IPython.display import Image, display_png Image("tegaki_memo.jpg") と表示することで、メモ書き(=構想)、コード(=作業)を一体化し…

反省

今回のプレゼンは微妙。 やはり覚え込むまで練習しないとだめだ。しゃべるときに迷うようであればすでにだめ。覚えていないことで自信がないから早口になったりするし。 準備不足。 しかし、時間はかけた気がする。とにかくスクリプトがぜんぜんできなかった…

プレゼン逡巡

delma.hatenablog.com delma.hatenablog.com delma.hatenablog.com delma.hatenablog.com プレゼンについていろいろつらつら考えてきた。 今回はひたすらスクリプト作成から入った。 時間がめちゃくちゃかかった。だいたい20分のプレゼンで10時間くらいはか…

acmart acmフォーマットの論文の便利なコマンド

最初に書く \documentclass[sigconf]{acmart} こうすればカンファレンス情報落としたArXiv用 \documentclass[sigconf, noacm, screen]{acmart} こうすればダブルブラインド対応 \documentclass[sigconf, anonymous]{acmart}

生産的な研究のための時間割

数週間は同じタスクに集中する 1日うち3時間は割くが、だらだらやり続けない。疲れてきたら、あるいは沼にハマってきたら休憩して別のことをする。もしくは散歩する。 人に話す

クラウドでjupyterを触る時のTips

前提 AWS EC2 (ubuntu) Python3.6.3 バックグラウンドで動かす ssh接続が結構切れるので基本バックグラウンドで動かすべし nohup jupyter notebook > /dev/null 2>&1 & Elastic IPにすべし EC2はデフォルトだとインスタンスを停止するたびにIPが変わる。いち…

分析パイプラインを再構築する 振り返り

delma.hatenablog.com 課題点 * サーバーでやったのか、ローカルでやったのかわからなくなる。 どこかにまとめるべき? * RでやったのかPythonだったのかよくわからなくなる。 どっちかにまとめるべき? →日誌を書いたほうが良い気がしてきた。 1タスク1ノー…

Zotero connectorで文献管理を効率化

chrome.google.com そもそも使ってなかったのがおかしいんだけど、これまで、論文はPDFをZoteroにドラッグ・アンド・ドロップしてメタデータを抽出していた。 この方法だと殆どの場合うまく書誌データを拾ってくれない。 Zotero-connectorを使えば、Google S…

反省会

論文を一本出し終わったので反省会。 今回はすべてRで、しかもローカルでやりきった。 メモリをそんなに食わない研究だったのでローカルでやったのは問題ない。 ただ、クラウドでやったほうが日々の仕事とコンフリクトしないからよかったかも。 Rを使ったの…

サーベイの仕方

サーベイはアウトプットに利用しやすいようにまとめる サーベイが使われるのは、 Literature Review/Related Workでの言及 Reference レビューセクション以外での数字やデータ、手法等への言及 Referenceにどうせ載せるのであるから、Zoteroに研究論文一本に…

スピードを上げたい

論文生産のスピードを上げたい。 アイデアはあるしデータもある。ないのは技術と知識、時間

雑感2

グローバル変数が危険すぎる。 特にRStudioだと雑になりがちなので、実行前に必ずクリーンアップする。 3時間程度溶かしてしまった。。

雑感

これまでも散々書いているが、データ加工プロセスは細かく切ってディスクに落としておく。また、それぞれの小プロセスのvalidationをしつこくやる。 これをしないとヘンテコな結果になる。

雑感

研究、地道に計画立ててコツコツやって成果が出ればいいが、だいたい上手くいかずに気持ちがしぼんで投げ出したりする。 しかし、それでも立て直してうどうだやってるとある時一気に進む。 進まなくてもうだうだ進めることが大事だし、進められる時は一気に…

エンジンを吹かす

連休中に研究を進めようかと思ってたがとってもエンジンがかかるまで時間がかかる。 distractionがたくさんあるというのもあるけど、たっぷり寝てもだめだったり。 たっぷり寝て、 その研究への興味関心を高めて タスクを細分化してやることを明確化して 携…

始動が遅い

やりたいプロジェクトが多すぎるということもあるが、一週間のうちにプロジェクト間のスイッチを何回も行う。前そのプロジェクトをやっていた時期から時間が経つと集中が始まるのに時間がかかりすぎる。 よくあるのは、机に座ってやる気を出すために、spotif…

not to be smart but to be efficient

分析稼業はループの繰り返し。 あたりをつけて分析してそこで得られた知見をもとにまた計画を練り直してという感じ。 データが新しくなれば、手法が新しくなれば、前の知見は通用しないことが多い 結果的に無駄なぐるぐるを繰り返すことになるが、それは結果…

研究分析のパイプラインを考える(振り返り1回め)

delma.hatenablog.com 書いてから2週間経ったので振り返り。 新ルール(仮) とっかかりはrmdかjupyter。 検索可能性が上がるようにproject毎にまとめる。 projectごとにレポジトリを作る 作業のおおまかな計画的なやつはreadmeを更新していく。タスク管理…

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

課題感 様々な分析しごとをどうオーガナイズするかめちゃくちゃになっているのでルールを決めたい。 現状 研究 jupyter notebookかRmarkdownで実施。コードを書く前に動作を確認したいときはSQLミドルウェアも使う。 Pythonコードはgithubで管理。 最近あま…

Zoteroとsugarsyncで文献管理をする

年も改まったことだし論文管理環境を再構築する。 もともとmendeley派だったが、色々トラブルが多く一度Zoteroに以降した。ただ、ZoteroとSugarsyncを並行して使っていたためおかしなことに。 丸一日格闘した結果、Zoteroの動作をようやく理解したのでメモし…

スケジューリング、段取り

リサーチを効率的に進めるには段取りやスケジューリングがすべてと言っていいほど重要。 何をどこまでいつやるか。 何をするか決まればあとは作業するだけ。ここは純粋に作業なので大して脳には負荷がかからない。 むしろ何をすべきか、様々な条件から最適な…

そそっかしい性格

そそっかしい性格である。 当然、慎重さが要求されるコーディングやデータの管理には向かない。 特に、疲れてくると適当になる。 learning by doingで良い局面ならそれでもいいが、一旦コンピューターに計算を投げるという工程では、正確を帰さないと時間が…

研究で時間を浪費するパターン

研究は熟考し呻吟し深い考察を得ることが真髄であることは論を俟たないが、生産性革命、働き方改革の時代、研究者に時間を浪費することは許されていない。 研究の質を犠牲にすることなく最速でアウトプットを出すためには時間の浪費を避けなければいけない。…

ビッグデータを分析するときのティップス

データが大きいということは様々なリスクがあるということ。基本はしっかりアセスメントを行ってから分析を実行すべきということ。 まずは、メモリ管理。せっかく計算ができてもメモリエラーで止まってしまっては意味がない。一気に計算させて大丈夫なのか、…

リサーチの方向性

そろそろ本腰を入れてリサーチを始めていきたい。リサーチの優先順位は、まずは世の中へのインパクト、次に自分の強みが生かせるかどうかだ。 軸は当然、経済。一つの方向性として前の職場でエコノミストとして解き明かせなかったことを解き明かしていきたい…

雑感

(早いけど)今週のまとめ 今週は暇だったのでpythonの勉強。あと、部内での勉強会で発表、外回り。結局、企業内研究者として研究のための研究はできない。これは仕方ない。サービスに結びつく開発とセットになった研究がミッション。論文はその成果をまとめ…

ビッグデータの美しさ

1億レコードを超えるデータで分布を書いたら本当にきれいななだらかな指数分布になっていて感動した。収束という概念をはじめて目で見た気がした。

チェック2

チェックが大事と言いつつ、しかし現実問題として早さも重要になる。特にタイムリーに課題に答えなければならない実務の世界では。 ふだんは反射的な判断に頼りつつ熟考が必要な場面では徹底的に考えるというのが正解なのだろうが、どの問題に時間をかけるの…

チェック

チェックの大事さを思い知っている。 コーディングやデータのミスはともかく、結果の解釈には十分時間を書けなければならない。 チェックのためだけのコードも書くべきだ。比較したり、修正したり、最終的にはどれだけロジカルに考えぬけるかが勝負。