カイゼンジャーニーを読んだ

アジャイルとか開発組織どうするか〜みたいな話はしばらく遠ざかっていたけど、最近、"マネージャー"という役職につき、ちょっとそっちの方に注力する必要が出てきたので、今、流行りのカイゼンジャーニーを読みました。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

さて、カイゼンジャーニーですが、評判通り、とても良かったです。
1人で始めたカイゼンが全社を変えたぜ〜!みたいな現実感のないシンデレラストーリーではなく、実際にはカイゼンしきれないままプロジェクトを移っちゃったりしつつも、その中で色んな人と出会いつつ成長していって段々とやれることを広げていくという、現実の世界に近い (著者の方の体験や実際にあったケースをモデルにしてる?) 気がして、引き込まれるように読めました。

個人的に1番いいな〜と思ったのは、物語の文脈に乗せて、色んな形式のMTG方法とかファシリテーションの方法が紹介されている事。
"マネージャー"という事で、場自体のセッティング / ファシリテーションをする場面が増えてきてますが、そういう経験はあまりなくて引き出しも全くないので、これがめっちゃ大変。。
単純に方法だけ紹介されていても中々腹落ちしないだろうし、また逆にこんな時はどんな方法がいいんだろう?って疑問に思ってもそれをどういう単語でググればいいんだろう、、ってなりますが、この本の中ではMTG/ディスカッションの方法が物語のコンテキストと一緒に紹介されているので、自分のチームの中で今はこういう感じのことをしっかり議論したいな〜という時に、本の中の似たような場面を思い出して、そこで紹介されているディスカッションの方法を参照すればいい。
インセプションデッキ、むきなおり、リーダーズ・インテグレーション、ハンガーフライトの場作り等々。ちょっと油断するとどんどんチームって停滞してしまうんだなーと感じるものの、引き出しが少なすぎてどうしたもんかな〜という状態だったけど、大きなヒントをもらった感じなので、今後、色々試していこう。


ちょっと話は変わって、この本のスコープからは外れるけど、自分が納得できて健全と思える方法でモノをしっかりとまっとうと思える方法で作れるってのはもちろん大事なんだけど、そもそも、そこがゴールなんだっけ?っていう疑問が最近自分の中で強く燻っている。
アメリカのスタートアップとかを見てると、日本では考えづらいようなスピードで組織をスケールして最新の技術を取り入れつつも、プロダクトも進化を続けている所がいっぱいあるのに、色んな組織で発生しているあるあるな問題に同じように苦しんで解決してバンザーイってだけで、そういった所に肩を並べるプロダクト/開発組織って作れるのか!?その辺はクリアした上で、もっと上のレベルの戦いが繰り広げられている世界もあるのではないか? っていう疑問というか、思いというか。

その中で、最近の自分にとって身近な問題として、"マネージャー"って何なんだろう??/どういう存在になるべきなんだろう??ってのがある。"技術分かってるマネージャーに指揮されたい vs マネージャーはマネジメントに集中すべき問題" に、 "エンジニアのキャリアパスがマネージャーしかない問題"、"そもそもマネージャーって何(プロダクト / プロジェクト / チーム...)をマネージする存在なの?問題" 等々。こういったモノをしっかりに向き合って解決していく必要がありそうだと思う一方で、こういうあるあるな問題に事前に上手く対策することもできない組織が、良いエンジニアリングをして、プロダクトを他社より上手に改善し続けられるのか?って思ったり。
ガーンといくアメリカのスタートアップは、こういうあるあるな問題に対して、それなりの解を持っていて、事前に備えているからこそ、ガーンといけるんじゃないかな〜と思ったり。

こういうのを解決するために、組織体制とか開発手法の分野で膨大に学ぶべき/実践すべきことはありそうな予感がしつつ、正直こういう部分に時間を取られることがストレスに感じる部分もあり、有限な時間の中で自分が注力したいのは、エンジニアリングのことをキャッチアップし続けて、しっかりと現場に携わった形でエンジニアとしてのキャリアを積んでいく所で、こういった組織とか開発手法の分野はそこに注力したい人がやるのがベターのでは?と思ったり。。一方でその考え自体が、実は自分の変化を恐れて今までの延長線上で仕事をしたいという甘えでは?みたいな思いも頭をよぎ流こともあり、、、ほんと最近は思考がぐちゃぐちゃw
40という年齢はキャリアの中の1つ大きな節目らしいですが、まだ数年あるものの、そこに向けて色々と考えたくなる年頃なのかな〜。

ここまでの思考のぐちゃぐちゃ感は、久しくなかった感じで、こっから自分がどういう選択をして、どういうキャリアを築いていくにしても、数ヶ月後/数年後に振り返ってみたら面白いかな〜と思って、久々のブログに書いておいた。

子育てエンジニアとジョギング

この記事は 子育てエンジニア Advent Calendar 2016 - Qiita の7日目です。
僕自身は3人の娘(7歳、4歳、3ヶ月)の父で、ジョギング暦は1年程度ですが、もっと早く始めておけば良かったな〜と感じていて、もしかしたら他の子育てエンジニア/将来の子育てエンジニアの人にも参考になるかもしれないと思い、記事を書いてみました。

子育てエンジニアにジョギングがおすすめな理由

短時間でできる

大体、ランニング時間が30分〜60分程度。開始前の着替えと終了後のシャワーを入れても60分〜90分で全行程が終了。奥さん/旦那さんと子供を置いて、仕事帰りや休みの日に定期的にジムやボルダリングに行くのが難しくても、これくらいの時間であれば、確保できるのではないでしょうか?また、朝早くや子供が寝てからちょっと走りに行ったりもできます。
また、先日、日曜日のハーフマラソンの大会に出場したのですが、朝10時頃のスタートで12時頃にはゴールなので、その後はしっかりと家族と過ごせますし、また、河川敷で開かれた大会で、天気も良かったためか、家族連れで来ている人もちらほらと見かけました。

1人になる時間を持つことによるリフレッシュ

仕事から帰って見る子供の顔はとても愛おしいものですが、休日の間ずっと一緒にいると、その気持ちを保つのが難しい時があります。そんな時、ちょっと1人で外で走ることはとてもいいリフレッシュになって、愛おしさを取り戻すことができます。

自分の成長を感じることができる

子供ができると、自分の勉強にあてることのできる時間は減ってしまうし、色々とインターラプトされて集中を削がれることも多くなります。そうすると、自分の成長が阻害されている気持ちになり、ストレスがたまってしまうことがあります。しかし、外で1人で走っている間は、誰にも邪魔されることはないし、また、特に最初の頃は走ることのできる距離やペースが目に見えて伸びやすく、自分の成長を感じることができ、そういった面でのストレスの解消につながります。

食事が楽しくなる

日常的に体を動かすようになると、食事の量が増えて、食べる物にも少し気を使うようになります。そうすると、日々の食事の重要性が増し、スーパーでちょっといい食材を買って料理して食べるだけで、とっても幸せな気持ちになるので、小さな子供がいて、しょっちゅう遠くにお出掛けするのがしんどい子育て期にはとってもいいです。

村上春樹も走っている

「走ることについて〜」は僕がジョギングを始めることになった大きなきっかけでした。ジョギングしたらこんないいことがありますよ!って書いてるわけではなく、彼がどんなことを思いながら日々走っているかが淡々と書かれているエッセイなのですが、不思議とめちゃくちゃやる気になりました。また、65歳を超えても一線の小説家として日々机に向かって創作を続けている彼が、ランニングを日課としていて、それを仕事のクオリティを保つために必要と感じているということは、エンジニアとして一線で仕事を続けていくにあたっても、何か繋がるところがあるに違いない!と勝手に感じていて、ボクの中ではモチベーションの一つとなっています。



読んだ本とか

そんなに色々と読んだわけではないですが、面白かった/役に立った本の紹介。

EAT & RUN

めちゃくちゃすごいウルトラマラソンランナーの人の自伝。書名でぐぐるといっぱいこの本の素晴らしさが書かれた書評が出てくるので、詳細は割愛しますが、とても読み応えがあって面白い本でした。
基本は自伝なのですが、所々に走り方に関するコラムがあって、その中の一つで走る時は足を身体の真下につけるべしみたいなことが書いてあり、僕にはそれがぴったりと合って、それを意識するようになって以来、足の痛みに悩まされることがなくなり、そういう意味でもとても役に立った一冊でした。

EAT&RUN

EAT&RUN

マラソンは毎日走っても完走できない

走る以上は、ただのfun runではなく、何らかの進歩が欲しいという人にはオススメ。さくっと読める新書サイズにぎゅっと色んなエッセンスがまとめられているし、監督としての実績が凄すぎる人なので言葉に重みもあります。インターバル走は辛いけど、、確かに成長する感はあるw。

谷川真里が案内するご当地マラソン

パラパラ読むのに楽しい一冊。日本のマラソン大会事情について全然知らなかったけど、1年を通じて日本全国で様々な大会が行われているので、この時期に〇〇に旅行がてら大会に参加しつつ、XXを観光したら楽しそうだな〜、、、と色々と妄想が進みました。まだ、遠くの大会に参加したことはありませんが、小さな夢を見れる一冊でした。

村上さんのところ

先述の通り、「走ることについて〜」に大きな影響は受けたのですが、そのちょっと前まで村上春樹さんのことは完全に読まず嫌いでした。この企画(村上春樹がメールで送られてきた質問にひたすら日々答えていく)がネット上で行われていた時に、時々はてぶでエントリーが上がってきて、彼の文章をちょくちょくと読む様になり、そうすると自分の中の勝手なイメージと全然違う人で、文章も面白くて、最終的にこの本を買って完読したことが、今にして思うと、僕がジョギングを始めた大元のきっかけとなりました。なので、特に村上春樹を読まず嫌いしている人におすすめです(笑)。

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

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


Let's enjoy being a parent, engineering and jogging :)

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が大きくなる可能性がある。
    • 全sessionの累積なので、全ての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