「データサイエンティスト養成読本 ビジネス活用編」を読んだ (9月中旬読了)
参考になりそうな感想文
[1] https://medium.com/@shinichitakayanagi/データサイエンティスト養成読本ビジネス活用編-7082e8ef044b
動機
データサイエンティストではないが、データをもとに、（面と向かってではないにしても文書ごしに）顧客に説明する機会が存在する。また、データ分析自体にも興味があり、実際のところどのように案件が進行するのか、されていくのか興味があったため。
また、メルカリさんが公開していた事例紹介がドンピシャで役に立ったことがあり、メルカリの人の事例がのっていたのも一因。
感想（一部）
□ 1章
ビジネス上の課題を洗い出すとき、データ分析の具体的な方法を考えてはいけない、データをどう使うか、あるいは使わないべきかはそのあと考える、という注意点は確かにと納得した。[1]の人の言う通り、データ分析（や機械学習）を使わない事例にも取り組むべきか、は立場や個人・企業のブランディング戦略にもよると思う。使わなくてよい場面でDeepとか分析とかやろうとすると地獄に近づくという話は、それはそう。
□ ３章
特に良かった。機械学習プロジェクトを運営するためのノウハウがよくかかれている。プロジェクト全体のサイクルや各工程での注意点、特にビジネスデザインについて紙面を割いて記述されている。
現場との期待値調節についての項も大変参考になる。
以上。
メモ：機械学習モデルのデプロイ手段（エンドポイントの用意の手段）
メモ：
機械学習モデルのデプロイのの手段。モデルのロードはマシンごとに初めに済ます、という要件がある。
* （何らかのライブラリを用いて）webAPIを自身で作成する
* gRPCを使う
RPCはRESTと同じくWeb APIを実現するための手法です。各サービス間の連携方法として広く採用されているのはRESTですが、RESTは一定の原則こそあるものの、複雑で自由度が高くベストプラクティス的なものがほぼ存在しません。
一方、RPCは仕様がすでに決まっていることが多く、開発者は考慮するべき点が絞られるため本来集中すべき開発に時間を割くことができます。
> https://qiita.com/jumpyoshim/items/a027f2f18f926d975683#rest-vs-rpc
* TensorRTなどのDeploy（推論）用ライブラリを用いる。
画像認識などcommonタスクなら、ソース例があって便利そう。TensorRTでは、gRPCとHTTPのエンドポイントが用意できる。
The NVIDIA TensorRT Inference Server provides a cloud inferencing solution optimized for NVIDIA GPUs. The server provides an inference service via an HTTP or GRPC endpoint, allowing remote clients to request inferencing for any model being managed by the server.
> https://docs.nvidia.com/deeplearning/sdk/tensorrt-inference-server-guide/docs/
* クラウドプラットフォームを用いる（詳細知らず）
https://cloud.google.com/ml-engine/docs/tensorflow/deploying-models?hl=ja
「クラウドエンジニア養成読本」を読んだ
動機
最近コンテナを使用する機会があり、仮想化とともに語られる（パブリック）クラウドについて最低限知っておきたかったため。
雑多な感想
なんとなくしか知らなかった、クラウドベンダの各種サービス概要を知ることができてよかった。Bigquery便利そう
ハードの面倒を見なくてよいのは相当魅力的だが、制約もあり、色々くわしくないと使うのに勇気がいる。また、料金体系がオンプレミスと比較してどうなのか、残念ながら判断がつかない。
後半の事例集が面白かった。NRIは検討事項や語り口が明瞭で、きちんとSIやっているんやな～と勝手な印象を持った。LambdaのNode.jsがEoLになって強制アップデートされるのは盲点だった。ドキュメントに明記してくれなければ嵌りそうな罠。
ハンズラボの事例では、ユニケージ開発(!)がでてきて驚いた（正直眉唾だと思っていたので…）。また、初めはデータ保管をDynamoDBを使っていて、あとからRDBに変更するあたりなどに、多様な物事の在り方を感じる。闇を感じるシステムを社内調節しつつ全面クラウド移行したのは素直にすごいと思った。腕力があればこそだろうなと。
コーディング規約と生産性
適切な規約を選択し、チーム内で順守することで、コードが読みやすくなり、アンチパターンを回避できたり、不要な議論をなくすことができる。
私自身は、コードを引き継く機会もそこそこある。そういった場合には、既存のコーディングパターンに従う必要がある。
コードを編集しているとき、元のコードが、本ガイドのルールではなく、別のルールに従っていると気づくことがあるかもしれません。そのような場合には、そのコードの規約との一貫性を保つために、本ガイドのルールからは外れなくてはならないでしょう。
> https://ttsuki.github.io/styleguide/cppguide.ja.html#Existing_Non-conformant_Code
ここまでは教科書的な内容。
話が変わるが、読み手至上に過ぎる決まりは、書き手の手間を増やし過ぎるのではないかと思っていた。例えば、「末尾コメントが続く場合はスタート位置をそろえるべき」など（この状況は、デバイスドライバの定数定義のマクロとかで発生する）。
などと思っていたが、GoogleのC++の規約に以下のように言及があった。
コードの(書き手ではなく)読み手に優しいこと
我々のコードベース(と、ほとんどの個々のコンポーネント)は、今後長い長い時を経ていくことが予想されます。 結果的に、そのコードを書くのに費やした時間に比べて、はるかに多くの時間がコードを読むために割かれることでしょう。 私たちは、私たちの平均的なエンジニアが「簡単にコードが書けること」よりも、「コードを読み、メンテし、デバッグがやりやすいこと」に最適化することを明示的に選択します。
自分のケースにはめると、書いた後にメンテし続けるものはすくないので、「簡単に書けること」を明示的に選択する選択肢もあり得ると思う。
先のC++の規約では、行末の複数行コメントのインデントはそろえることを推奨している。
後続の行にも続けてコメントを書くときは、それらを揃えたほうが読みやすいです。
ちなみに、pythonのデファクトの規約であるpep8には（覚えている限り）それへの言及はないが、イコールの位置を揃えるためにスペースを入れるべきではない、とは書かれている。
次の場合に、余計な空白文字を使うのはやめましょう:
(略)
須山ベイズ本読んだ
「機械学習スタートアップシリーズ ベイズ推論による機械学習入門」。略名：須山ベイズ本
動機：
元々、PRMLを5章途中まで読んでいた。PRMLを読むの結構大変（というか全数式はおえていない）ので、ほかの優しめの本を読んだ方が良いという判断で鞍替えした。
感想：
PRMLよりは数式が追いやすくて安心感がある。不確実性を定量できるのは魅力的で、機会があれば個人的な問題で試してみたい。ただし、数式力と手間がいる[*1]。また、計算量も気になるところだがよくわかっていない。
*1: 著者本人もそういっている。
> http://machine-learning.hatenablog.com/entry/2016/12/19/205222
> ご指摘のとおり、ベイズ学習は習得コストや導出コストがかかるためあまり一般的ではないかもしれません。自分がベイズ学習を使っている理由は、単純にこの方法じゃないと解けない課題を長く取り組んでいたからです。逆に1週間で良い結果を出せ、と言われたら僕も迷わずランダムフォレストやSVMを使う気がします。
