カーネギーメロン大学で客員研究員してきた話

２０１７年８月から２０１８年９月の頭まで，約1年間，Carnegie Mellon University (CMU)のLanguage Technologies Institute (LTI)で客員研究員をしてきた．博士号も持っておらず，大学では別の研究としていた私が，どのような留学してきたが，記憶が新鮮なうちに記事をまとめておく．なんとなくこの記事では，ですます，はやめる．尚この記事は，個人の感想であり，企業を代表した記事ではないことは初めに断っておく．

留学決定まで

私の会社は恵まれていて，海外留学制度があり，毎年留学生を何名か輩出している．社内の選考を通過すると，海外ラボで1年間，自由に研究できる権利が与えらる．その間，仕事はしなくて良いので（月報とかはあるが），ほぼ１００％研究にコミットできるという，かなり留学者側には美味しい条件になっている（ただ，どういった内容で研究するか，をアピールすることで選考が行われるので，それまでの選考と完全にずれたような研究はできない．が，具体的なテーマ名を決定する必要はない）．当時自分のスキルの伸び悩み，キャリアパスに悩んでいたので，割と勢いで応募した．

選考を無事通過したところで，そこから先は自分で留学先を選定し，自分で担当の教授と交渉を行う．コネがある場合はそれを使えればよいが，私の場合は特にそんなものはなかったので，興味のある先生にCVとカバーレターをいきなりメールで送りつけ，交渉を行った．この制度では，研究費，出張費などはすべて会社側で負担してくれるので，金銭的な負担がないのであれば，先生側も客員研究員を受け入れやすいという傾向があるように思える．これまでの留学経験者によると，メールに返信してもらえなかったり，金銭面の折り合いがつかなかったり，先生が退官したりと，第１志望の先生に行ける確率はそう高くはないが，金銭的な負担がないことが功をそうしてか，留学先の先生を決めることができなかった，という人は聞いたことがない．私は言語（対話）系の研究室を選んだのだが，大学院はP2Pのネットワークを研究していたので，言語系の論文など書いたことがなかった．ただある製品で言語系のUIを担当していたのが先生に気に入られたようだった．この先生はCMUのLTIに所属していた．LTIというのはComputer Scienceの部門の中で言語系に関する部門である．かなり大きな部門であり，言語系のトップカンファレンスでCMUがやたら多いのは，まずLTIによる研究だと思う．色々な先生がいるので色々な研究が同じところで行われていて面白い．雰囲気などは，こちらの方の留学日記が参考になると思う．中国・台湾人は本当に多い．

CMUの中国人コミュニティ

留学まで

留学が決定したのは，留学まで残り１０ヶ月ぐらい．会社からは基本的なオリエンテーションはあるものの，大学側との契約，渡航準備，ビザ準備，滞在先手配，などは基本的にすべて自分が中心となって行う．もちろん会社側にそれぞれの手配のサポートを行う部門はあるものの，海外転勤などと異なり，その辺りのサポートは手薄い（仕事ではないのであえてそうしているフシがあるが）．また，私の場合は，妻に帯同してもらえ，色々と相談しながら決めていった． また事前に先生とはSkypeで面接及び研究の話をした．学生でCMUに入学する場合，TOEFLの点数がそれなりに高くないと足切りされるのだが，客員研究員の場合，先生が英語問題なし！と言えばOKになるらしい．先生方も，色々な外国人を相手にやり取りをしているわけで，英語レベルは流暢である必要はない．そのため，学部生，院生は流暢な英語をみんな喋るが，客員研究員は英語が下手な場合が（私も含めて）結構あるように思える．

英語の勉強は，それまでDMM英会話をやっていた．ただこれもマンネリ状態だったので，GABAに通ったり，Netflixでfriendsを見たり，英語力向上に努めた．が，正直そこまで上達した実感もなく留学に突入する．技術が分かれば，正直英語のレベルはそんなに問題ではない，とか思ってる暇があったら英語勉強しろ．１年経過した今でも英語には困っている．

研究に関する勉強に関しては，論文を読んだりDNNの勉強をしたり，ガッツリと勉強したかったのだが，業務後になってしまうし，渡航準備の事務作業も多くなっていたので，正直微妙な状態で留学に突入してしまった．

滞在先，Pittsburghについて

Pittsburghはペンシルバニア州で，NYとシカゴの間あたり．緯度が高いため，冬は長く，寒い時はマイナス２０度ぐらいの死の世界が訪れる．その分，夏はカラっと快適であり，今年猛暑だった日本にいなくて本当に良かったと思う．アメリカの中では中規模都市にあたり，観光に来るような街ではないが，自然の多さ，治安の良さ，物価，のバランスが非常に良い．CMUの他にピッツバーグ大などもある学術都市なので，企業もGoogleやAmazonも支社を構えて，優秀な学生を捕まえている．ただし海がないので，海産物は高級で鮭ぐらいしかない．食事は日本食品も扱う中華マーケットにお世話になる．

留学前半（２０１７年８月〜１２月）

Pittsburghに到着して二日後ぐらいにさっそく研究室のミーティングに呼ばれ簡単な自己紹介を行った．当時は先生以外みんなアジア人だった（中国・台湾・韓国）．言語系，機械学習の勉強はある程度してきたものの，そこまで知識があったわけではないので，最初の３ヶ月ぐらいはテーマを探しつつ，色々な論文を読んで，DNNのモデルの追試をしたりと，基礎力の向上に努めた．その研究室のプロジェクトにコミットすることもできたのだが，研究というよりは既に開発フェーズに移っていたので，あまり恩恵はなさそうということでプロジェクトに入ることはしなかった．このときは色々なモデルの実装にハマッており，githubに毎日草を生やすのが楽しくなっていた．またスター数も留学してから１５０近く増えたと思う．スターをくれるのは中華系アカウントが多く，ここでも言語系のリサーチャー人口は中華系が多いなと思うことになった．

github.com

また読んだ論文はgithubのissueに上げると，他の人も見れるし自分も管理しやすいことに気づき，増やしていった．

github.com

ちなみに，LTIでは，いわゆる日本のような大部屋な研究室というのはなく，大きな建物の中に，先生の部屋やPh.Dの人（基本的に２〜４人部屋，入っている人はランダム）などの部屋が雑然と並んでいる．作業スペースが大きいのはありがたいが，日本のような研究室団らんのようなものがないので，ちょっと寂しい．同居人によっては，英語をまったくしゃべらない日も普通に多い．ミーティングを除くと基本的にみんな自分の部屋で作業している．また，大学院生は日本と違って，研究室に所属して論文を書く必要がないので，基本的に接する機会が少ない．相当やる気のある人が授業などと並行して，研究室に所属して論文を書いているようだ．

話を私の研究に戻す．色々なDNNのモデルを勉強して実装して，というフェーズは非常に勉強になったし，楽しかったのだが，そろそろ研究テーマを形にしないとまずい，と思い，研究室での進捗報告を増やしていった．私の研究室では，週に２回全体ミーティングがあり，そのどちらでも自由に進捗があれば発表して良い，という形が取られていた．また先生とも１対１ミーティングを行い，テーマを固めていく．ちょっと寄り道しすぎたかもと反省．研究テーマがある日，頭の中から出てくる，という考えは甘すぎた．

留学中半（２０１８年１月〜４月）

ACLやSIGDIALという学会の投稿期日が迫っていた．ACLは言語系頂点といっても過言でないトップカンファレンスであり，SIGDIALは規模は小さいものの，対話にフォーカスした最大学会であり，広く認められた学会であったため，こちらを選んで論文を仕上げた．第１稿の完成から１０回近く先生に赤ペンを入れてもらえたので，非常に恵まれていたと思う．ただ年末・年始は今思い出しても，胃に穴が空きそうなぐらい辛く忙しい時期で，家か研究室にこもってずっと作業をしていた．奥さんごめんなさい． 更にSIGDIALの結果はrejectで，ダークサイドに落ちる．が，先生に励まされ，なんとか立て直した．私の先生は厳しいことで他の研究者から恐れられていたようなのだが，私にはとても良い先生であった．

留学後半（２０１８年５月〜８月）

SIGDIALの結果が出るまで，２つ目のテーマに移行していたのだが，rejectを受け，改めて最初のテーマをやり直すことにした．査読者のコメントは，最初は画面が霞んで見えたものではなかったが，よく見ると至極真っ当であり，非常に有益なコメントであった．このコメントをバネに実験を重ね，IEEE SLTという，音声言語処理に関する学会に投稿する．投稿後，２週間は燃え尽き状態になり，２つ目のテーマにちゃんと戻るのに時間がかかってしまった．その関係でこのテーマは留学期間中に終わることなく，留学後，企業に戻ってからも続けることになる．そして帰国間際のこの時期に，SLTから通知が届き，acceptをもらった．留学中になんとしてもacceptが欲しく，胃が痛い日々が続いていたので，この通知をもらった後は，アパートの廊下を全力で走ったのは記憶に新しい．

総括

私はもともと会社ではUI/UXのエンジニアとして働いていたのだが，言語処理に２０１５年ごろから興味を持ち始め，SIGDIALに聴講させに行ってもらったりと少しずつ勉強を初めた．それは２８歳ぐらいのときであり，大学では言語，機械学習の勉強などまったくしなかった（更に専攻の研究も正直しょぼい）．そこから海外のトップ大学で，国際学会に論文を出せたのは，我ながら夢のある話だと思った． この１年は，今後の人生においても，もっとも濃密な１年の１つになるのは間違いない．ただ海外の優秀な学生と一緒に研究することで，研究思考不足，英語力不足，を痛感する１年でもあったように思える．ただそれを鑑みても，大局的には貴重な経験であったと思う．私はこれまで素敵な研究キャリアパスを歩んだわけではないし，英語も別にうまくないのだが，こういう道があった，ということは残しておきたく，気持ちが冷めないうちに記事にしておく．留学経験者はいつも「絶対留学したほうがいいよ！」って言ってくるので，「ちっ，うぜぇなぁ」ぐらいにしか思っていなかったが，これからは私も，留学絶対にしたほうがいいよおじさん，として余生を過ごしたいと思う．

pudbで機械学習開発を加速させる

皆さん，pythonで機械学習のコードを書くときに，どのような環境で実装してますか？私は師匠もおらず，自分なりにいろいろ試していたところpudbに落ち着きました．pudbはデバッガーでpdbにUIが付いたようなものになります．pdbはC++でいうgdbみたいなもんですが，まぁガッツリ使うのは辛いです．pudbは下記の画像のようにターミナル上でグラフィカルにデバッグをできます． pudbを使うとどのようなことができるのか，この記事ではgifアニメーションをもとに紹介します．

なぜpudbが便利か，AtomやVS Codeは使わないの？

動作例の説明の前に，簡単にpudbに落ち着いた理由を説明しておきます． 私の環境だと，GPUが載ったマシンが手元になく（AWS，大学，会社），リモート（SSH経由）で開発する必要がありました．マシンが物理的に近くにあるときは，そのマシン上でVS Codeを動かす分には特に不満はありませんでしたが，リモートでの開発方法がまったく分かりませんでした．どうやらリモートプロセスもアタッチできるようなのですが，ネットワーク設定等，面倒な雰囲気があり試していません． VNCやリモートデスクトップではラグが気になり，AWSでは普通GUI付きのインスタンスなんて準備していない状況です． コーディングに関してはvimでいけるものの，printデバッグとか流石に辛いよね，と探して見つけたのがpudbです．逆にリモートでも開発できるデバッガがあるのか，周りの人はどうしてるのか気になってます．

インストールと設定

pip install pudbで入ります．起動は，pudb3 hoge.pyという形で，普通のpythonを実行する形で問題ありません． 初回起動時あるいはctrl-pにより，設定画面がでます．私はここではshellをipythonに，themeをmonokai-256に変えています．ここはお好みで．

カーソル移動

j, kで上下１行ずつ移動．ctrl-d，ctrl-uでまとまって上下移動．vimと同じですね． こちらはカーソルを動かしているだけで，プログラムは１行目から動いて（実行して）いません．

ステップ移動

nでステップオーバー，sでステップイン（その関数に入り込む），fでその関数内の最後に飛びます．また動画にはないですが，cがcontinueのcでプログラム開始になります．ブレークポイントがない限り最後まで実行しようとします．

ファイルを開く

mでファイルを検索し，開くことができます．built-inでない自分で作ったプログラムなどはimportした後でないと検索に出てこないので注意．

ブレークポイント

カーソル行のあたっているところに，bでブレークポイントを貼れます．cキーでcontinueなので，次のブレークポイントまで飛びます．この際，プログラム終了前であればctrl-cにより，プログラムを一旦止めることができます．中断処理は次に説明します．（ブレークポイントがない場合，終了まで実行しようとする）．またブレークポイントはpudbを終了しても保存されていますので，毎回貼り直す必要はありません．shift-bで右下のブレークポイントエリアに飛べるので，不要なブレークポイントはdで消せます．またはすでにブレークポイントが貼ってあるところで，再度bでも消せます．

重い処理の中断

ctrl-cにより，プログラムを一旦停止させることができます．重い処理をしているときに途中結果などを確認するときに便利です．またこの動画ではshift-sによりStackエリアにフォーカスをあて，ファイルを移動しています．カーソルキーで目的のファイルを選択してEnterすることで，該当箇所を開くことができます．

エラー時のデバッグ

エラーが発生すると，ポストモーテムモードになります．eによりエラーを確認できます．エラー発生箇所で，該当データなどをコマンドラインエリア上で確認したりしてエラー原因を分析します．またshift-sによりスタックエリアに飛べるので，エラーの前のコード部分に飛んでエラー分析，といったこともできます．ちなみにエリアからフォーカスを外すにはctrl-xで外せます．ショートカットがうまく動かないときは試してみてください．

現在のコンソールへの出力を確認する

oにより，現在のコンソールへの出力を確認できます．Enterで戻ります．

shellを利用する

プログラムの途中で，データの中を細かく確認したいときがあります．そのときは画面左下のコマンドラインエリアに切り替えるか（ctrl-x）か，!でshellモードに切り替えてipythonを使うこともできます．ipythonが使えるのでかなり自由にデータを確認したり，簡単なコードを実行できて便利です．エラー発生時に最も威力を発揮するモードです．ipythonから戻るにはctrl-dで戻れます．

再描画する

ctrl-lで崩れた表示を再描画します．

ショートカットを確認する

?を押せば，ショートカットの一覧が確認できます

リスタートor終了する

qにより，デバッグのリスタートや終了のメニューが選べます．

気をつけておくこと

pudbはデバッガなので，デバッガを起動しないときよりもpythonの実行速度は落ちます（体感的に半分ぐらい）．そのため，大きめの辞書を一から構成する，などの処理をpudbの処理中にやるのはあまり向いていません．辞書は予めpickleなどにしておき，それを読み込むようにすることで，時間短縮ができたりします．

まとめ

前回のログTipsに続き，今回はデバッガの話をしてみました．pudbについては多くの記事を見かけるものの，まだまだ知名度は高くない気もしていて，もっと実践開発の知見が貯まればと思い書いてみました．私も自己流なのでまだまだ知らないことが多いと思いますので，こんな使い方も便利だよ，というのがありました是非コメントください．

www.jonki.net

Fitbitのアプリ開発環境がイケてる件について

Fitbit フィットビット スマートウォッチ Versa 心拍数測定 睡眠 パーソナルコーチ 耐水仕様 Black/Black Aluminium L/Sサイズ【日本正規品】 FB505GMBK-CJK

愛用していたPebbleが買収されたので，買収元のFitbitからVersaを買ってみました．スマートウォッチ使いたい，というよりは開発環境が楽しそうなので買ってみたというのが本音です．Pebble時代はWeb上でアプリを開発できて，とてもイケてる開発環境だったのですが，C言語でUIを書くというのがとにかく大変でした．こちらの記事はPebbleでPomodoroを書いた時のもの．
www.jonki.net

VersaではWeb上での開発環境そのままに，JavaScript，CSS，SVGが使えちゃいます．またコンパニオンアプリとのメッセージングやOAuthなどのライブラリは提供されているため，必要最低限のコーディングだけで良いのが魅力的です．またWin/Macのどちらにも実機シミュレータがあり，使い勝手がよいです．トップ画面は今回作ったClockfaceです．アプリは時計アプリであるClockfaceと一般アプリに大別されるようです．

この記事では，具体的な実装方法ではなく，今回のClockfaceを作る上での準備内容，参考にしたページ，ハマったところなどを書いていきます．参考リンクに貼った公式ページがよく出来ていて基本的にコピペで作れます．またコードは下記に公開しています．
https://github.com/jojonki/fitbit-image-clock

環境セットアップ

Getting Startedに従って，Fitbitのアカウントセットアップ及び，Fitbit OS Simulatorをインストールして下さい．開発は，Fitbit Studio上で行います．プロジェクトのテンプレートとしていくつか用意されているので，最初はそれを眺めるのが良いと思います．

• fitbit studio

いわゆるIDEです．ブラウザベースなのですぐに使えます．ここからシミュレータや実機にアプリをインストールしたり，公開用のアプリバイナリを生成できたりします．またログの出力もここで確認できます．

• fitbit Simulator

見たまんまシミュレータです．物理ボタンや画面タッチをマウスで行うエミュレートもできます．

プロジェクト構成

構成はとても簡易なものでわかりやすいです．app/上には実機上で動くjsが配置されます．companion/上にはスマホのコンパニオンアプリで動くjsが配置されます．companionアプリ上では外部リソース（http上の画像とか）を取得してもらったりします．resources/には画像やレイアウト情報を配置します．index.guiはいわゆるindex.html的なものでsvgによるDOMを配置します．cssはその名の通りスタイルシートです．

実機インストール

実機にインストールする場合には，PhonesとDevicesの中からシミュレータでなく，それぞれスマホ（私の場合Sony F5321）及び実機（Versa）を選択する必要があります．コンパニオンアプリからVersaを選択し，[開発者向けメニュー]->[開発者用ブリッジ接続]をオンにします．次にVersa本体のメニューから[Settings]->[Developer Bridge]をタッチし，Connected to ..となるようにします．たぶんPC/Mac，スマホと同じWiFiにいる必要があります．接続できたらfitbit studio上のRunボタンを押すことでインストールできます．（下記の画像はシミュレータを選択しているものなので注意）
うまくつながらないときはfitbit studio上でプロジェクトを開き直したり，コンパニオンアプリのブリッジ接続トグルを入れ直したりして下さい．

アプリの公開

Fitbit Gallery App Managerでアプリプロファイルを作ります．fitbit studio上でDownloadのメニューからpublishを選択すると.fbaファイルがダウンロードできるので，それをアプリ公開ページに添付することで公開できます．ただ実際にはレビューリクエストを経てからなので，ストアに並ぶまでには時間がかかります（私もいま申請中）．アプリインストール用のリンクが生成されるので，それをモバイルから開くことで，限定公開によるインストールも行うことができます．そのため一般公開せずに限定的なリリース（テストとか）もできます．

ハマりどころ

• テキストが一部削られて表示されている

New element text larger than buffer! Consider increasing text-length to avoid truncation. とstudio上で出ていませんか？CSSでtext-lengthを指定して，文字数の上限を指定しましょう．メモリが少ないのでケチケチ削りましょう．

• Simulator上で表示される画像が実機で表示されない

画像の解像度が大きかったり，pngが8bitじゃなかったりすると起きるかも？参考．
Solved: Clockface with images not working - Fitbit Community

• 実機あるいはコンパニオンアプリに繋がらない

studio上でプロジェクト開き直す，PC/Macとスマホが同じWiFiにいるか確認する，WiFi変えてみる．同じWiFiにいても認証が必要なケースとかだと繋がらない場合があるかも．．

ここが辛い

• CSS変更によるリアルタイムでのプレビューができず，毎回インストール（５秒ぐらい）が必要．そのためデザインをシミュレータ上で試行錯誤するのは結構面倒．
• 実機上で画像転送すると遅い．シミュレータでは１秒かかってないような画像取得が実機上だと１０秒ほどかかっていた．シミュレータは実機のパフォーマンス制約を再現しきれていない気がする．
• コードのGit連携できない．.zipでExportはできるが．．．
• fitbit studioでタブが開けないので，ファイルの切り替えが面倒．

参考リンク

SDK Guidesを見ながら開発することになると思います．大体の情報はここに載っています．

• SVG Guide, SVGやCSSについて．UI周り全般．
• Animations Guide, 非力だが簡単なアニメーションもできるっぽい．
• File Transfer Guide, 画像の送受信のサンプル．本体からは直接は画像をダウンロードできないため，予めアップしておくかcompanion経由でアクセスする必要がある
• Messaging Guide, 本体とコンパニオンでのWebsocketのメッセージのやり取り．天気のAPIを叩く例もある．
• User-activity API, ユーザーアクティビティ系（歩数取得とか）
• Power API, バッテリ，充電状態の取得

まとめ

雑多な感じですがまとめてみました．JavaScriptベースなので非常に開発が楽です．また開発環境もシミュレータのみインストールが必要ですが，基本的にはブラウザベースで敷居が非常に低いです．とても今時な開発環境なのでエンジニアの方は触ってみるととても勉強になると思います．また， fitbitを持っていなくてもシミュレータ上で開発できるので，ぜひ皆さんも何か作ってみましょう．

機械学習における実践ログTips

機械学習（深層学習）の開発では，一般的なプログラミングでの開発とは異なり，実行から結果の確認までのフィードバックまでの時間がとても長いです．機械学習初心者の私はその違いをあまり深く認識しておらず，当初はその特性の違いで困っていました．失敗をしていく上で，このやり方でログをまとめると便利だなと思うTipsが溜まったので共有したいと思います．師匠や長年機械学習をやってきたわけではないので，何を当たり前な．．みたいなことを思う方もいらっしゃるかもしれませんが，あしからず．機械学習系のブログは理論解説が多く，実践的な開発ノウハウが少ない気がするので，これを機にこういうエントリが増えたらと思います．こういうやり方も便利だよ，というのがありましたら是非コメント欄にてフィードバック頂けると幸いです．

なお今回の話は，ポッドキャストのrebuild.fmでのhigeponさんの回に深く同意する内容になっています．
Rebuild: 208: Oculus Go On The Go (higepon)

ロガーの準備

pythonを前提にする場合は，私はいつも下記のような形で使ってます．ファイル名は基本的にタイムスタンプにしていて，必要に応じて実行時引数でログファイル名を指定しています．

import logging
import argparse

parser = argparse.ArgumentParser()
parser.add_argument('--log', type=str, help='Specify a logger\'s output filename')


date_label = datetime.datetime.now().strftime('%Y%m%d-%H%M%S')
log_fname = args.log if args.log is not None else 'logs/{}.log'.format(date_label)
logging.basicConfig(level=logging.DEBUG,
                    filename=log_fname,
                    format='%(asctime)s %(message)s',
                    datefmt='%Y%m%d-%H%M%S')
console = logging.StreamHandler()
console.setLevel(logging.DEBUG)
formatter = logging.Formatter('%(message)s')
console.setFormatter(formatter)
logging.getLogger('').addHandler(console)
log = logging.getLogger(__name__)

log.info('log file: {}'.format(log_fname))

引数一覧はログに出力する

深層学習の開発ではいろいろとモデルをカスタムしていく上で，様々な実行時引数を取るようにカスタムする傾向にあると思います．そこで私は実行時には下記のようにして実行時引数（指定しなかった場合はデフォルトの引数も）をログに残しておくようにします．これにより，隠れ層の次元数を引数でしているけど何を指定したっけな．．みたいなことがなくなります．

for arg in vars(args):
    log.info('Arg: {}={}'.format(arg, getattr(args, arg)))

20180630-000951 log file: logs/20180630-000951.log
20180630-000951 Arg: batch_size=32
20180630-000951 Arg: n_epochs=25
...

実行時引数を利用してメモを残しておく

実行時引数を利用してメモを取れるようにしておきます．プログラム実行には時間がかかるので，何か目的があって実行したプログラムのはずなのに，なんでこれ動かしたんだっけ．．みたいなことが防げます．

parser.add_argument('--note', type=str, help='Note for this running.')

$ python train_model.py --note "OptimizerをSGDからAdamに変更してみた"

Gitのリビジョン番号をログに残す

プログラムは常に更新していると思います．そのため私はこまめにコミットをしているのですが，ログにも実行時のリビジョン番号をしっかりと残しておくと，あとあと自分の結果の再現をするときに便利です．ただ毎度コミットした状態で実行するとは限らないので，先程の"note"ハックとセットで使うと便利です．

import subprocess

rev = subprocess.check_output(['git', 'describe', '--always']).strip().decode('utf-8')
log.info('Git rev: {}'.format(rev))

Git rev: 33c55c9

実行時間は計算しておく

深層学習の実行は時間がかかるので夜中とかに回しとくことが多いです．そのためどれぐらい実行に時間がかかるかを残しておくことは，作業時間の見積もりに対して有用です．

import time

begin_time = time.time()
# ....

# プログラムの最後
log.info('Process time: {:.3f}h'.format((time.time() - begin_time)/3600))

実行完了時のログは整理した情報を出力し，Evernoteなどにコピペできるようにする．

実行完了後，実行結果を要約してレポートを出力するようにします．私はEvernoteを使っていて，この最後のレポートをEvernoteにコピペするようにしています．Evernoteなどのメモソフトにこのようなレポートをコピペしておけば，また後日このコピペ内容からログファイルを見たりするのが容易です．例えば，このパワポで進捗報告した82.476%の性能って，どの段階でで出たんだっけ？みたいなときにEvernoteで検索するとこれがヒットします．もちろんそのためにはEvernoteのノートのタイトルや，メモを残しておいた方が（自分に）親切です．

20180630-022147 -----Final Report. Running mode: 3 ------
20180630-022147 Hoge1 Acc      : 82.476%
20180630-022147 Hoge2 Acc      : 71.46%
20180630-022147 log file: logs/20180630-000951.log
20180630-022147 python train_my_model.py --mode 3 --resume ckpts/hoge1.model --note "MLPのレイヤ数を3に増やしてみる"
20180630-022147 Git rev: 9ac7188
20180630-022147 Process time: 3.5h

- MLPのレイヤ数を３に増やして，性能向上を試みる
// ここに先程のログをコピペ

ログはfilterを通して閲覧する

ログは漏れがあるといけないので基本的に冗長に出力するケースが多いと思います．そのため出力されたログから迅速に必要な情報をフィルターする必要があります．私はpecoを使っています．これはlessなどとパイプで組み合わせて，該当行を高速に表示してくれます．リンク先に動作gifがあるのでご参考に．

less logs/my_log.txt | peco

また私はログファイルがタイムスタンプになっていて探るのが面倒なので，あるディレクトリ下の最新のログファイルをtailとpecoで読み取るスクリプトを利用しています．リアルタイムログ閲覧＋pecoにより，決まったログだけを眺めることができて経過を見守れます．

#!/bin/sh
ls -t logs/* | head -1 | xargs tail -f -n+1 | peco

と雑多に書いてみましたがこんな感じです．ログは面倒ですが，人の記憶は適当なものなので，たった数分前の自分がやったことも理解できなかったりします．こういったログTipsが他にも増えたらと思います．
次回は需要があれば，pudbによるリモート開発Tipsをできたらと思います．

あるサブディレクトリ内の最新のファイルを一発で開く方法

大量のログファイルとかがあるときに便利なコマンド．
こんな感じ．サブディレクトリの次に＊（アスタリスク）を入れると，相対パスも含めて表示してくれるのがミソ．

ls -t subdir/* | head -1 | xargs less

pecoとか入れてるなら更にパイプでつなげると便利．

ls -t subdir/* | head -1 | xargs less | peco