読者です 読者をやめる 読者になる 読者になる

CourseraのMachine Learning Foundations: A Case Study Approachを受講 & 修了した

couseraのコース、人生初修了!
https://www.coursera.org/learn/ml-foundations
https://www.coursera.org/account/accomplishments/certificate/4VN5VC73889M
履修して良かったな〜と思えるコースだった割には、このコースを始める前に色々とぐぐった時には日本語の情報は見付けられなかったので、メモなど。

Why I choose this course?

  • 機械学習の盛り上がり。
    • この分野のspecialistにはなれなそうだけど、面白そうだし、ある程度の素養を付けておきたい。
    • deep learning, neutral networkの概念が理解できてない。 最低限の理論が分かってライブラリがあれば使える程度には理解したい。
  • これ系は色んな本に手を出したけど、なかなか最後まで続かない。。
    • 進捗が見えやすくてshareもできるmoocの中で色々と比較検討し、このコースに辿り着いた。
  • Coursera内ではこっちのコースの方がmajorっぽく、日本語の修了ブログも散見されたけど、Syllabusを見るに今の自分のスキルで、これを1人で修了するのは厳しそう。
  • ↑のコースが全11週なのに対し、これは全6週。何とかいけそう!?
  • 実際にはこのコースは↓のSpecializationの最初のコースで、このコースで最初にさらっと色んな分析手法の概要を説明して、各手法の詳細については後続のコースで詳細を学ぶ形。
  • 使用している言語がpythonなので、とっつきやすそう & 業務とかに転用しやすそう。

実際始めてみて、最初のほうであれっと思ったのは、quizの回答をsubmitするだけでも、$79の有料コースに登録する必要あり。(昔は違ったような) ちょっと迷ったのですが、分かりやすいフィードバックがないと、本読んでるのと同じ感じになって心が折れそうな気がしたのと、week1とweek2のquizの手前までで、先生の雰囲気がいい感じで、続けられそうな気がしたので、week2のquizのタイミングから、えいやっと有料コースに登録して履修していました。Stanfordのほうは11週で$49に対し、こっちは6週で$79なので、相当な割高感は否めませんが。。

How was it?

  • どっちの先生も声がクリアで、そんなに早く喋らないので英語は結構聞き取りやすかった。
    • 今の所、日本語の字幕は存在しない。
  • 数学的知識は(良くも悪くも)あまり必要なし。
    • 各手法の概念や触りの数式がlecutureで説明されて、それを実現する部分は細かいロジックはすっ飛ばしてgraphlabの関数を利用。
    • 細かいロジックの話は後続のコースでフォローされる模様。
  • 細かい所は飛ばしつつも、ちゃんと動く物がoutputとしてできるし、自分の知識レベルだと、いきなり一つずつ深入りされてしまうと、容易に居場所を見失ってしまうので、このアプローチは自分にとってはすごく良かった!
  • graphlab すごい
    • ちょっとしたレコメンド機能とかはほんとサクッと作れてしまう時代なんだな〜と。
    • ただし、このコースに出てくるのは単一マシン上で走るロジックばかりで、scaleしなそう。scale outついてはこのコースでは触れられず。
    • 後続コースの紹介で、map-reduceに触れるそうなので、scale outのさせ方についてはそこで説明がありそう。
  • ipython notebook すごい
  • week2 以降の課題は、レクチャーの内容をちょっとだけひねった感じ。別途hintもあるので、それに従ってやっていけばOK。
  • 第6週 (deep learning) だけ、ぐっと難易度が高めに感じた。
    • 他の週以上に、色んな難しいことはすっ飛ばされてはいるんだけど、逆にすっ飛ばされすぎてて何をやってるかよく分からずで、他の手法と同じ時間内にまとめること自体に無理があるように感じた。
    • Capstone までたどり着いて、もう少し理解できるようになりたい。。

次の"Machine Learning: Regression" も修了してブログ書くぞ!きっと。少し間を空けてから。。

postgresqlの "terminating connection due to conflict with recovery" に対応するためのパラメータ

FATAL: terminating connection due to conflict with recovery というエラーについて前書いてたけど、
PostgreSQLのFATAL: terminating connection due to conflict with recovery - seikoudoku2000のブログ
今更ながらに2015のRDS postgresqlのsessionを見てたら、2014の時よりしっかりと説明がされてたので、更新 & 自分の文字での情報を増やしてみた。
AWS re:Invent 2015 | (DAT402) Amazon RDS PostgreSQL: Lessons Learned & New Features - YouTube

この問題は、以下の3つのパラメータで対応可能。

  • vacuum_defer_cleanup_age
    • vacuumで消された行をどれくらいの間残しておくか。ただし、設定が時間単位ではなく、transaction数単位で、設定が難しいのであまり使われていない。
  • max_standby_streaming_delay
    • slaveで実行中のqueryが必要とする行がvacuum対象となっている時、replication streamingの実行を中断し、queryの実行を優先させる際の最大のdelayの許容時間。
      • 大きく設定すれば、queryは流れやすくなるが、delayが大きくなる可能性がある。
    • 全てのtransactionでその挙動が保証されるわけではない。(ここはちょっと意味が聞き取りきれず、ドキュメントでも記載を見つけれなかった。要確認。)
    • primaryの挙動に影響を与えないという点で、安心感があって人気がある。
  • hot_standby_feedback
    • slaveからprimaryに実行中のqueryの情報を定期的に送信し、primaryはその情報を元に必要とされているrowをvacuumしないようにする。
    • slave上のqueryはほぼ走りきるが、vacuumをブロックするので、disk容量が膨らむ可能性がある。
    • プレゼンしてる人のおすすめ

さらなる詳細は貼付けた動画+公式ドキュメントへ。


2016/05/12 追記。
あれこれと調べていたら、max_standby_streaming_delay が上手く動かない場合に関する、こんな記述を見つけた。`cumulative delay`ってのを上手く訳せないが、connection単位でのdelayではなく、流れているqueryの累計になるから、運が悪いとqueryはcancelされちゃうよってことかな。
https://books.google.co.jp/books?id=RmpGCgAAQBAJ&pg=PA100&lpg=PA100&dq=max_standby_streaming_delay+cumulative&source=bl&ots=RdP2-O09Yf&sig=8t_Ktyk7l-UxXql9j2wuNjOVzKg&hl=ja&sa=X&ved=0ahUKEwjjtI3Kg9TMAhWlqqYKHaZrA7kQ6AEIIDAB#v=onepage&q=max_standby_streaming_delay%20cumulative&f=false
```
These settings cover a cumulative delay.
That is, if there are ten queries pending, they don't get 30 seconds each to delay replication.
So a query might run for 10 milliseconds and got cancelled because it was unlucky to be at the end of the delay, causing the user to wonder what happened.
```

docomoからmineoにMNPした

2年に1回の携帯キャリア見直しタイム。
digno(ISW11K)を買った - seikoudoku2000のブログ
iPhone5s を買った #docomo #mnp - seikoudoku2000のブログ


前回の時に、こう書いていてけど、今はMNPキャッシュバックの規制やMVNOの台頭など、ほんと変わったもんだなと。

2年後のMNP事情はどうなっているんだろうな〜。今の競争の形は健全ではないと散々言われているて自分もそう思うし、ケータイ買いたいだけなのに訳の分からんコンテンツにとりあえず登録させられて速攻で解約してと、せっかく新しい端末を買っているのに買い物していて気持ちよくないし、、と前回同様、再び残念な気持ちを味わうことになったので、いい方向に変わっているといいな〜。


今回は諸々検討の結果、mineoにMNPした。回線切替の待ち時間中なう。今回の手続きは実店舗に足を運ぶことなくオンラインで完結したし、価格設定もシンプルで速攻で解約しないといけない変なオプションはないし、2年毎縛りもなく、1年利用すると、以降は違約金が発生しなくなるなどなど、前回と比べると、大分すっきりした気分の契約体験だな〜と思います。
なお、ここ経由でmineoの契約をすると1000円分のamazonポイントが貰えます (ボクもw)
mineo.jp


以下、今回の結論に至った流れ。

3大キャリア vs MVNO -> MVNO

  • あまり詳しくない親族がスマフォの機種変更の際、薦められるがままに、タブレット契約 + オプション漬けな契約していて、全然使ってないのに合計すると結構な額のお金を支払っていて、何かもう、ほんと嫌になった。
    • (勿論、 違法じゃないんだろうけど、明らかに使わないものを、よく分かってない人に売りつけるってのが残念すぎる。しかも本家のdocomoショップで。)
  • 前回買ったiphone 5sがまだまだ使えそう。
    • キャリアの2年契約は2年ごとに端末を買えて月々割を貰う前提で成り立ってる気がするので、端末を変えなくていいなら、よりmvnoがお得。
    • docomoiphoneの端末の保険が無くなるのがちょっと痛いけど、何かあった際はMVNOで提供されている2万円台のAndroidでも十分かなと。もしくはその前にiphone SEがもう一段階の値下げに期待。

MVNOの概要の把握、キャリアの絞り込み -> DMM か mineo

容量と高速/低速切替のポイントを満たしている事、その他、諸々のメディアからボクの中の刷り込まれたイメージでDMMかmineoに絞り込み。

DMMとmineoの比較 -> mineo

  • DMMの利点
  • mineoの利点
    • androidlover.netを見ている感じ、回線速度はDMMより安定していそう。
    • 回線の高速/低速 の切替で、DMMは低速時に3日間で366MBでさらに速度制限が入るのに対して、mineoは低速時の利用には制限がない。
    • パケットギフトや、パケットタンクなど、これまでに無いサービスを展開していて、とても力を入れている感じがある。
    • 価格.com 経由だと、3,000円のamazon point。
  • その他のポイント、考えたこと
    • DMMだと利用料金の10%が一ヶ月期間限定ポイントになるけど、それを無理に使おうと時間をとられたり、無駄な買い物をしたりしてしまいそうだし、使わないと、それはそれで損した気分になりそう。
    • mineoはパケットギフトの制度を利用して、パケットがヤフオクやらメルカリでやり取りされている。ボクが見た時点では300円/GBくらいの相場。万が一、足りなくなったらそれを購入することもできるが、勿論DMMのように確実にゲットできるわけではない。また、あまり使わなかった月は、逆に売る事もできそう。(規約上OKなことなのかは要確認。)

どっちも一長一短で決め手がなく、最後の最後まで迷って、エイってmineoに決めてしまった感じ。

そして、ここ経由でmineoの契約をすると1000円分のamazonポイントが貰えます(2回目)!ただし、前述の通り、価格.com経由だと、3,000ポイントだったので、そのキャンペーンが続いていたら、どう考えてもそっちがお得w
mineo.jp

Principles Of Microservices by Sam Newman を1年前に見たかった。

会社でshareされて流れてきた動画。かなり勉強になると同時に、耳の痛い所が色々とあったw。1年前に見たかったな〜としみじみと思った。ただ、後悔していても始まらないので、とりあえず、忘れないように内容のメモ。


Principles Of Microservices by Sam Newman

() 内は自分での補足や感想。

  • Microservicesの定義 -> Autonomous services that work together. 一緒に動く自立したサービスの集まり。

なぜprincipleの話をするかというと、Microservicesをやるにあたっては多くの選択/決定をしなければならないので、軸となるルールを持っておくことが大事だから。herokuのthe twelve factors的な感じ。
(これは本当そうだよな〜と。とりあえず、Microservicesだ〜と色々と分けて作ることは出来るけど、変な分け方をした所はボディブローのように苦しくなってくるし、かといって、作る前から完全に見通すのはとても難しいので、ルールに沿ってるかをチェックすることで、大きな設計ミスが防げるのはとてもいいと思うし、そこからはみ出るにしてもしっかりとした理由づけができそう。また、そういう軸があることで、設計に関する議論も、抽象的なものから、もう一歩踏み込んだ所で議論しやすいように思う。)

以下、Microservicesの原則。

  • Modelled Around Business Domain
    • Domain Driven Design is a good place to start
    • (エリック・エヴァンスの本を読み直した方が良さそう。)
  • Culture or Automation
    • Infrastructure Automation, Automated Testing, Continuous Delivery
    • 初期コストはかかるが、最初の仕組みが整えば、加速的にサービスを増やすことが可能になる。
  • Hide implementation details
    • Hide your database. 例えば、複数のアプリケーションを同じテーブルにアクセスさせると、カラムの変更が複数アプリケーションにまたがってしまうのでNG。代わりに1つのアプリケーションにだけサクセスさせ、他のアプリケーションからはAPIでデータを取得できるように。
    • 隠してる情報/フィールドをexposeするのは簡単だが、その逆は大変なので、最初はできるだけ隠す。
  • Decenterize All The Things
  • Deploy Independently
    • Most important!!!! あなたのシステムがこれができている状態なら、結構、いい感じだよ。
    • そして、これが守られていないなら、新しいサービスを足す前に、その状況を直す必要がある。 (耳がとても痛い。。)
    • 複雑性を避けるため、大体の人がone hostにmultiple application ではなく、one host, one applicationに帰結していく。 ただ、one host, one applicationは効率的なリソースの使い方とはいえないので、one host, multiple applicationを容易にする点が、dockerが人気を集めている一つの要因。
    • consumer driven contract. consumerからのserviceの使い方を両者間の契約とみなし、service側の変更では、その契約に違反していない事をルールづける。
    • https://github.com/realestate-com-au/pactcom
    • (consumer driveの話はこの記事に詳しく書いてて分かりやすかった。 サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ )
    • (後でユニークIDは導入コスト高いみたいな話があったけど、これもかなり導入コスト高そうだなと思った。)
    • consumerをservice側の変更と同時にデプロイすることを強要することはNG。service側は破壊的な変更はせずに新しいAPI end-pointを用意し、consumerのupgradeを待って、古いエンドポイントを削除。 ただし、bug fixとかのservice側のメンテナンスはちょっと大変。
    • ( publicなAPIはどうすんだろう?と思ったけど、この記事で出てきたAPIs are foreverという言葉を思い出した。 10 Lessons from 10 Years of Amazon Web Services - All Things Distributed )
  • Consumer First
  • Isolate Failure
    • much easier to make less resilient, more machines, more network boundaries which can timeout. microservicesにすると、システムが堅牢になると思いがちだが、むしろ脆くなりやすい。マシンは増えるし、ネットワーク越しのやり取りも増えるから。
    • あるモノリシックな1つの巨大システムを12個に分割したけど、そのどれか1つでも止まると、全部が上手く動かなくなるという分割をした会社があった。私なら、1個の巨大サービスに戻す事をオススメする!
    • ↑のことをdistributed single point of failure って名づけた人がいた。 (この言葉は言い得て妙で、気に入ってしまった。他人事ではないがw。)
    • strangler app (level 7の振り分けのproxy layer?) を入れるパターンはあるあるだけど、そこがSPOFになりがち。一個のapplicationがthread poolを食いつぶしてしまうことで、全部のシステムがアクセス不可能になってしまう。
    • まずは妥当なtimeoutを設定しよう。
    • thread poolをapplication単位で準備するとなお良し。一つのアプリケーションがハングしても、他のアプリケーションには問題なくアクセスできるように。bulk head pattern
    • circuit breakers。エラーが繰り返される場合、timeoutを待たせるのではなく、素早くerrorを返してしまう。それにより二次災害を防ぐ。databaseアクセスにも使える。
    • (この辺は見事に踏んでた所なので、凄く納得。microservicesにすることで、異常系のパターンは増えるし、こういった仕組みも含めてしっかりとテストしないといけないな〜と。)
  • Higly Observable
    • log aggreation
    • passing through correlation ids. 処理が始まった所でユニークなIDを発行し、全てのサービスのログで記録する。逆引きして、サービス間の依存関係をvisualizeするというお洒落なことをやってる人もいた。
    • ただし、correlationが欲しくなった時にはこれを導入するコストも高いよ。デバッグが大変なくらいシステムが育ってるから必要になる訳で、ある意味必然。
    • GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system


今の会社でもmicroservicesな感じで、色々分けだしているけど、障害につながったポイントや、ここ上手くいってないな〜と感じるポイントが、見事に指摘されていて、結構感動してしまった。いやー、ほんとに1年前に見たかった。。

違うイベントのだけど、多分ほぼ一緒なスライド。

www.slideshare.net

この発表者の方は、自分もちょっと前に読んだこちらの本の作者で、勿論、本のほうもとてもいいんだけど、結構なボリュームで、現在地を見失いがちになってしまったので、先にこの動画を見て、全体を把握してからこの本に出会いたかったな〜と思った。とりあえず、microservices怖くない。(ちゃんとやれば。)

Building Microservices

Building Microservices

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

第17回ハイテクハーフマラソン を走った

「村上さんのところ」を読んで以降、すっかりはまってしまい、村上春樹さんの本やエッセイで紹介されている本をちょいちょいと読んでいる。
「村上さんのところ コンプリート版」読了した - seikoudoku2000のブログ
その中でちょいちょい出てくるランニング話に影響されて、自分も10月から走り出した。特にこの本の影響はでかし。

走ることについて語るときに僕の語ること (文春文庫)

走ることについて語るときに僕の語ること (文春文庫)

元々、ちょっと走ってみたいな〜と思っていた所をぐぐぐいっと背中を押された感じ。健康のため、仕事に必要な体力のためもあるけど、村上春樹さんの見てる世界に近付いてみたいな〜という何とも言葉にしづらいモチベーションに火がついたような(笑)。
読み終わった次の週末に、家の近くのMIZUNOショップに入ってみたら、1番いいな〜と思ったやつの丁度良いサイズがちょっと安くなってて、「これは運命だ!」と思って衝動買いして、ランニングウェアはこれまた家の近くのバッタもん屋で揃えて、1周1kmのジョギングコースをぐるぐると走っている。ここまでの所、大体月に100kmくらい。

途中ケガしたりで走れない時期があったりもしたけど、何だかんだと走り方のコツも掴めてきて、距離/記録ともに成長を感じられるようになったので、次ステップとモチベーションの維持のために、もう2週間も前になるけれど、人生初のハーフマラソンを走った。
右も左も分からずに参加したけど、事前に送付されてくる案内がしっかりしていたこともあって、特に迷う事無くスタートできた。スタート前のトイレがめちゃめちゃ混んでて、男子の立ち小便コーナーですら並んでみたら20分以上かかって、出発の30秒前にトイレが終わったり(スタート遅れた人もいっぱいいたと思う)でバタバタしたことだけが次回への反省点。
天気良くて走ってて凄い気持ちよかったし、無事に目標の2時間切りを果たせて良かった^^ 順位は男子3053人中1759位だったそうな。まだまだ先は長い。
次はフルマラソン挑戦するぞ!
f:id:seikoudoku2000:20160124153225p:plain
f:id:seikoudoku2000:20160124153832j:plain
f:id:seikoudoku2000:20160124153840j:plain

「村上さんのところ コンプリート版」読了した

村上さんのところ コンプリート版

村上さんのところ コンプリート版

購入したのが7/24で、ついさっき読み終わった!
期間中、ずっとこれだけ読んでたわけではないけど、1ヶ月と3週間くらいかかった。感慨深い。
コンパクト版が紙でも出てるけど、村上さんがどっかの回答(ブックマークし忘れたのでもはや探索不能w)の中で、今回はたくさんの"量"を積み重ねることに意味があると考えている、みたいなことを書いていて、それはホントにそうだな〜とコンプリート版を読み終えて感じている。(ただ、勿論、紙のほうは読んでないので、実はそっちでも似たような効能を得られるのかもしれないw)
過去に村上春樹さんの小説は何度かトライはしたものの、あまり好きになれなくて、ゆえに、どんな人かも全然知らなかったけど、この本や、並行して読んだ他のエッセイや小説を通して、ボクも無事に(?)村上主義者になれた気がする。

この本はトピックもランダムだし、量も凄いので、感想は書きづらいけど、ボクが一番良かったな〜と思うのは、全体を通じて物語の必要性が説かれていたり、本を読む事が絶対的に肯定されていて、自分の中の読書熱がぐぐっと高まったこと。年齢と共に保守的になってきたようで、あんまり新しい作家さんやジャンルには手を出さなくなりつつあったり、その前から翻訳モノって食わず嫌いしたりしていたけど、色々と読んでみようかなと思い始めた。

以下、回答の中で紹介されてた本のメモ。"The great Gatsby"と"心臓を貫かれて"は何回も言及されてたので、この辺からかな〜。でも、一番始めは"鉄道大バザール"と決めているw。

「でもさ、あの長い旅行から帰ってきたら、留守中に女房が浮気しているのが分かってね、それで離婚したんだ。参ったよ。」とポールがこのあいだ打ち明けてくれました。



鉄道大バザール 上 (講談社文芸文庫)

鉄道大バザール 上 (講談社文芸文庫)

鉄道大バザール 下 (講談社文芸文庫)

鉄道大バザール 下 (講談社文芸文庫)

The Great Gatsby (English Edition)

The Great Gatsby (English Edition)

グレート・ギャツビー (村上春樹翻訳ライブラリー)

グレート・ギャツビー (村上春樹翻訳ライブラリー)

心臓を貫かれて〈上〉 (文春文庫)

心臓を貫かれて〈上〉 (文春文庫)

極北

極北

The Goldfinch

The Goldfinch

すべての美しい馬 (ハヤカワepi文庫)

すべての美しい馬 (ハヤカワepi文庫)

第三帝国の興亡〈1〉アドルフ・ヒトラーの台頭

第三帝国の興亡〈1〉アドルフ・ヒトラーの台頭

ダーク・スター・サファリ ―― カイロからケープタウンへ、アフリカ縦断の旅 (series on the move)

ダーク・スター・サファリ ―― カイロからケープタウンへ、アフリカ縦断の旅 (series on the move)

はい、泳げません

はい、泳げません

三四郎

三四郎

偉大なるデスリフ (村上春樹翻訳ライブラリー)

偉大なるデスリフ (村上春樹翻訳ライブラリー)

AWS Startup Tech 夏のLT大会で話した

こちらのイベントにお声掛けいただいて"Monitoring Gengo using Saas"というタイトルでLTをしてきた。eventdots.jp

モニタリングはボク自身、経験が浅く、探り探りやってるので、ちょっとでも他社の事例を聞けるきっかになればいいな〜と思ったのと、後、ここで出た話をベースにschooさんで授業が行われるかもという話があったので、モニタリングという分野は必須な割にニッチなポイントなのでそこそこ枠取れるかなと思ってチョイスしてみた。ちなみにschooさんでの授業自体は無事に開催が決まったとの発表あり!
スタートアップでのAWS(Amazon Web Services)活用事例 2015 高山 博史 先生 - 無料動画学習|schoo(スクー)

私自身のLTはちょっとというか、大分ミスった気がするので次への反省。。言いたかったのは、devopsやらの概念の中でdevとopsの垣根をなくす事が大事!みたいなのがあったり、Continous Integrationという概念がかなり一般的になってきているから、それをモニタリングでもやっていこうぜみたいなことだったんだけど、前半で時間を使い過ぎてしまってグダグダに。。それでも、終了後に何人かの人に質問してもらえたので、そこは良かったのかなと。

www.slideshare.net

後はこちらで紹介されているように、ほぼ同性同名の方(ボクは点がないほう)と握手した。「じゃない方芸人」ならぬ「じゃないほうトミタヨウスケ」とならないよう、引き続き、頑張っていかないといけないな〜と決意を新たにしたwイベントとなりました。aws.typepad.com


ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

Effective Monitoring and Alerting: For Web Operations

Effective Monitoring and Alerting: For Web Operations