オライリー・マイクロサービスアーキテクチャを読む ~マイクロサービスの概念とその利点~

　マイクロサービスアーキテクチャ、というやつは、数年前からいつの間にか僕たちにとって非常に馴染みの深い隣人になった。
　僕も彼の顔には見覚えがあるし、周りの人間も、彼とは長い付き合いだとでも言わんばかりに、彼のことを声高に賞賛し、時にこれでもかというほどこっぴどく貶した。
　しかし、いつの間にか僕たちの隣人としてうろつき回る彼が、一体何者なのか、どこから来たのか、なんのためにここに連れてこられたかを知っている人間はきっと、彼を僕たちの日常へ誘い込んだ、ごく一部の幼馴染たちだけなのだろう。

と、いうことで、いつの間にかみじかになってしまった割に、具体的な定義や設計思想、想定される使用ケースなど、きちんと理解している気が全くしない、件のマイクロサービスアーキテクチャとやらを、この際だからきちんと勉強してやろうと思い立って書き始めました。
題材は先日帰国した時に購入したオライリーのマイクロサービスアーキテクチャと、プロダクションレディマイクロサービス。

ということで、勉強した内容を自分用メモもかねて、ここにまとめていこうと思います。
太字で囲ってある箇所は正規の引用ではなく、解釈し要約した物を書いています。もし間違いがあればご指摘ください。

第1章 マイクロサービス

マイクロサービスとは

マイクロサービスの定義

マイクロサービスの定義 : マイクロサービスとは協調して動作する小規模なサービスのことである。
まぁ定義は大事だよね。これは割とイメージと合ってる。

モノリシックなシステムの問題点と凝集性について

モノリシックなサービスの問題点:
モノリシックなシステムは大規模化すればするほど変更が必要な箇所はわかりにくくなる。
モノリシックな大規模システムは各機能を抽象化しモジューライズすることで管理を容易にしようとする手法が一般的だが、この手法を取っていても各プロセス内の指針がない境界は損なわれてしまうことが多い。
結果として、類似の機能が各所に散在し、修正や実装は困難になりがちである。

これもまた経験的に真であるとわかりますね。
いくらモジュールとして独立させ、ドメインの境界を定義し設計をしていったとしても、現実の開発現場ではスケジュールや技術力の不足に起因する現場都合の例外的な実装も増えて来ます。
また、設計がシステムそのものの複雑さに耐えられなくなり最終的に当初の設計理念に沿わない実装も徐々に増加してくることは珍しくないでしょう。

モノリシックなシステムでは、機能を抽象化しモジュール化することで凝集性(関連するコードを同じ箇所に集めるようにすること。）を高め修正や拡張が複雑になりすぎないようにすることが多い。
この凝集性の概念はマイクロサービスでも同様に重要であり、凝集性を高めるというアプローチを独立したサービスに対して行う。

ふむふむ。 本題ではないのですが、面白いことが書いてありますね。
凝集性はRobert C Martinが単一責任原則について語ったエッセイの中で紹介された定義が強く認識されてるみたいなんですが、その定義というのが、

凝集性の定義：　変更する理由が同じものは集める、変更する理由が違うものは分ける。

なんだそうです。
DRY原則を徹底しすぎて大量のコードから参照を持ったせいで変更が加えづらくなったクラスとか結構経験があるので、なるほど納得です。
このエッセイはオライリーから出てる「プログラマーが知るべき97のこと」というエッセイ集に載ってるみたいです。

マイクロサービスにおける凝集性

マイクロサービスで凝集性を実現するためのアプローチ: サービスの境界をドメインコンテクスト(ビジネス）の境界に合わせ、サービスの責任範囲を明示する事でサービスが過度に肥大化するのを防ぎ、サービスを大規模にしようとしてしまう衝動とそれに付随して発生する複雑さを回避する。

まぁ認識通り。

サービスの大きさに関する指針

サービスが大きすぎるかどうかの判断基準に関して
・ドメインの複雑さや言語の使用によって行数やコードの量は大きく変化するためコードの量はあまり関係ないが、チームのサイズとサービスの大きさのバランスは一つの指針になる。
→チームで全てのソースが管理できなくなった場合、サービスを分ける事を考えた方が良い。

・感覚的な判断も指針となり得る。メンバの多くが大きすぎると感じているときは実際に大きくなりすぎている可能性が高い。（ほんとか？）
・一つの定義として、Jon Eavesは二週間で書き直せるサイズをマイクロサービスの基準として特徴付けている。 → あくまで彼の経験則

ドメインの境界に合わせるに比べてなんか頼りない感じの例示だな、おい。

サービスの大きさとメリット・デメリットの関係

サービスが小さくなればなるほどマイクロサービスアーキテクチャの利点と欠点が最大化される。小さければ小さいほど相互に強調し合う必要がある箇所が増えるため複雑性も増す。 この複雑性にうまく対応できるようになると、よりサービスを小さく分割できるようになる。
確かにサービス間の協調の方法になれてない時はすごく処理が冗長に感じたし、設計も自信が持てなかったとこはあるな。

マイクロサービスの自率性

この本で説明されるマイクロサービスは独立したエンティティなのでサービスは必ずしもPaasにデプロイされるとは限らない。

まぁそれはそうでしょうね。サービスの中には一部オンプレで動くサービスやコンテナの中で走り続けるOSプロセスが合ったっていいわけだし。

それぞれのサービスは同一のマシンに詰め込まないように努めるべきである。 この分離によって、機能の呼び出しにオーバーヘッドがかかることは予想されるが、一方で構成が簡潔化し分散システムをより構築しやすくなる。 また、各サービスが独立することによって、これらのオーバヘッドを緩和するより新しい手法を導入しやすくなる。

ここでいうマシンは、かなり定義が曖昧なことはきちんとメンションされてますね。
ソフトかハードか、ソフトにしてもコンテナレベルなのかVMレベルなのかとか、マシンに関する定義はかなりあいまい。
あとで詳しく説明してくれるらしい。
ソースコードレベルならどれでも大きな差はない気がするけど、実行時にどういう振る舞いをするかはこのマシンの定義が大きく関わってくる。と思う。

マイクロサービスの分離と協調

サービス間の呼び出しは、全てネットワーク経由で行うことで、サービス間の分離を強制し、サービス同士が密結合することを防ぐ。 それぞれのサービスはAPIを公開し、サービス同士の協調はAPI経由で行う。

これも認識してた通りかな。ソースレベルでの結合が許されない以上、自然にAPI経由で連携しましょうという話になる。
この後の話題にも関係してくるけど、入力出力が一般的なフォーマットに則っていれば言語や基盤も関係なくなるので、各サービスが使用する技術という意味でも独立できる。

APIの設計とマイクロサービスの独立性

APIを公開する際、何を公開し何を隠すかについてはきちんと設計しなくてはいけない。それぞれのコンシューマの変更なく独立して変更・デプロイできなくてはいけないため、あまりに詳細な共有を行いすぎると、結果として自身のサービスとAPIをコンシューム(利用)するサービスが密結合してしまうことになりかねない。 マイクロサービスの黄金律は他のサービスには何も変更を加えずに単独で変更・デプロイできることであり、この黄金律に反する設計ではマイクロサービスのメリットを十分に享受することができない。

はい。おっしゃる通りです。特にコメントはないです。

マイクロサービスの利点

マイクロサービスの利点は分散システムの利点であり、サービス指向アーキテクチャや分散型アーキテクチャの利点をより拡大するものである。

技術異質性

それぞれのサービスがマイクロサービス化する事でそれぞれのサービスは好きな技術スタックを選択できるようになる。 それぞれのサービスが技術的に独立した基盤を持てる場合、それぞれのサービスは自身にとって最適な基盤を選択できることに加え、最新の技術を他のサービスに対して影響を与えることなく検証・使用することができる。

これは重要ですよね。うちはEC2にコンテナ立ててRDB使ったクラサバで、うちはヒストリ解析が主だからサーバレスでいいや、DBはDynamoDBでみたいな選択もできるわけなので。
また独立して最新の技術試せるっていうのも大きくて、大規模開発ではフレームワークやミドルウェアのバージョン上げるだけでもひと仕事なんですよね。
独立して最新の技術を検証・使用できれば最新技術のメリットを享受できるだけじゃなくて、組織としての技術スタックも積まれることになるので。

ただし、複数の技術の採用にはオーバヘッドがかかるため、NetflixやTwitterなどの企業はJVM上で動くことを条件づけるなど、制約を与えることで調整を測ることも多い。　　

まぁそうですね。Google並みに開発者が揃ってて多くのライブラリに対する保守が行えるなら話は別かもしれないけど。(あくまでクライアントライブラリの話です。)

回復性

サービス間がマシンレベルで分離されることにより、そこに隔壁が生まれ、一箇所で起きた問題が他のサービスに波及しづらくなる。
ただし、サービスの一部がダウンすることで協調動作ができなくなり、エンドユーザが一部の機能が使えなくなることがある。
サービスの開発者はその影響に対して対応した実装を行い、またサービス提供者はどのように復旧するかをあらかじめ想定しておく必要がある。

そうですね。マイクロサービス同士は疎結合とはいえ、どうしても相互依存する形になるので、どこか一箇所で問題が起きた場合に自分のサービスがどのような挙動をすべきかをあらかじめ考えて置かなくてはいけませんね。
先日うちの現場でもこの話をしました。

スケーリング

モノリシックなサービスの場合全てのサービスのリソースを一気にスケーリングしなくてはいけないが、マイクロサービスの場合、サービスがドメインレベルで分離しているため、負荷の高いサービスだけをスケーリングすることができる。

特にコメントはないです。その通りですね。

デプロイの容易性

サービスの単位が大きくなればなるほどビルド・デプロイにかかる時間は大きくなる。ビルド・デプロイの時間が長くなれば必然的にデプロイ回数は減るため、デプロイ間の変更が大きくなり、継続的統合(CI)が難しくなる。
マイクロサービスにおいて、デプロイの対象はサービスだけなのでビルド・デプロイともに時間が節約され、より細かい単位でのデプロイが可能になる。

次に上げるメリットとも関わるんですが、アジャイルを効率的に回すためには、こまめなデプロイを行い変更箇所を小さくすることが求められますね。
ごもっともです。

組織面の一致

モノリシックな開発現場では単一のチームとして開発することは難しかったが、サービス規模が小さくなることで、開発チームとサービスの一致が可能になる。
小規模コードベースで働く小規模なチームで開発した方が効率がいいことは自明であり、開発効率を最適化することができる。

本文の中ではアジャイルという言葉は使われていませんでしたが、小規模チームによる小規模コードベース開発といえば、やはりアジャイル開発が真っ先に頭に浮かびます。
まああんまりアジャイルアジャイル言ってるとアホっぽくなるのであれなんですが、要するに機動性の高い小規模なチームで開発を行えれば効率がいいですし、大規模な開発現場でも独立した小規模チ開発ームをたくさん持つことでそのメリットを享受できるようになりますよということだと思います。

プラットフォームに対する柔軟性

PC web, Mobile web, Mobile Native, Wearable, Tabletなどサービスを提供するチャネルは凄まじいスピードで拡大し、サービスはそれらのチャネルの拡大に対して柔軟に対応していかなくてはいけない。
モノリシックなサービスの場合、公開される接合部は荒く大きいくくりのものが多くなりがちだが、個別にサービス同士がAPIを経由して協調し合うマイクロサービスにおいてはサービスの提供する接合部は粒度が小さく機能の再利用や新規チャネルとの統合がしやすくなる。

これに関しては正直良し悪しかなと。サービスの粒度が小さくなれば当然個別のAPIの粒度も細かくなる。APIの粒度が細かくなればクライアントの実装もシンプルになる代わりにコードの行数も増えてくる。
ここら辺はAPIの設計の話なので、Real World HttpのClient sideから見たWebapiやWeb API: The Good Partsを読んだ方がはやい。

交換可能性

機能がサービスごとに分割されていることで、APIスペックを変更しない限りにおいて、サービスのコードは容易に置き換えが可能になる。
巨大なレガシシステムのように、一部の機能を置き換えることで起こりうるあらゆる想定不可能な不具合リスクを気にすることなく、部分的な書き換えや置き換えが可能になる。
またコードベースも小規模で、数百行程度に収まるようなものであれば、開発者が愛着を持ってしまい書き換えができなくなるという事態も防ぐことができる。

個人的に前半部分は今まで言ってたことの言い換えって感じだなぁと思ったのですが、後半の部分大事ですよね。
今作ってるものを捨てて新しいものに置きかえようってなったとき、どうしても愛着のあるシステムには抵抗があるものですし。

以上。以下途中でメンションした参考文献。
では!

ブリッジエンジニアはコードを書くべきではないか(いや、書くべきだ)

※この記事は過去の自分に対する自戒と体験共有の意味を含んでいます。

Shut the fxxk up and write some code!
御託はいいからさっさとコードを書けなんて名言がまかり通る世界ではありますが、一部例外的に実装の現場にいながらあまりコードを書かない人がいますね。
そう、オフショア開発におけるブリッジエンジニアです。
技術関連記事三稿目です。

彼ら、そして私たちブリッジエンジニアは高い(かどうかは知らん)語学力とマネジメントスキルを買われ、遠い海の向こうで働くプログラマの同志たちに、仕様を伝え、進捗を管理し、品質を担保してデリバーすると言うしちめんどくさい 重要な役割を任されているわけなのです。
英語ができるPMみたいなイメージですかね？まぁ英語ができれば出来る職種という訳でもないのですが。
このブリッジエンジニア、まぁコード書かないんですよ。
自分の仕事は仕様書の英訳と問い合わせ対応と進捗管理だみたいな認識の人もいますし、そういう認識を持っていなくても立場上それらの仕事に専念せざるをえない人もいます。

本題

さて、今回の記事では、ブリッジエンジニアがコードを書くべきだと言う理由をつらつらと並べ立てて行こうかなと思っております。
特に、コードに自信がある、コーディングが好きだ、もしくはコーディングに興味があるのに、このしちめんどくさい(もう消さない)役職を押し付けられてしまったエンジニアの方々が、自分で書きたいと言う意思を上司なり元請けなりに説得する材料になればいいんじゃないかなと思っています。
そう言う意思があるのに書けなくてやめていく同僚を見てるのも苦しいしね。

メリットとしては、以下の四つをあげています。
1. 進捗見積もりが正確になる
2. 多少の遅れは自分で巻きとれるようになる
3. メンバの教育ができるようになる
4. 双方のモチベーションが上がる

説得の材料になりそうで、具体性がある物を先に書いていきましたが、現場の人間としてメリットを感じているのは4->1の順番です。
好きなものだけ好きに使ってください。

書くべきメリットその１ 進捗見積もりが正確になる

進捗見積もりというのはオフショア先で勝手に見積もられるものだったりしますが、これが全くあてにならないのが世の常です。
この見積もりの曖昧さを起源とする遅延を、「途上国のルーズな時間感覚」や「先方の技術力不足」のせいにする発注者は非常に多いのですが、実際開発の見積もりなどというのはもともと決してあてになるものじゃないというのはアジャイル開発における前提認識のようなものです。
なんだそれ聞いたことねーよという方はアジャイルサムライの3章くらいを参照（爆）してください。

この本ではだいたい3ヶ月後くらいまでの開発計画が予測可能な限度だと紹介されており、実際にはその3ヶ月ですら開発者のレベルや使用される技術に対する習熟度などによって大幅に遅れることが経験的にわかります。
(ちなみに具体的な現場でどのように対応すべきかなども紹介されているので、読んだことない方はぜひご一読することをお勧めします。)

では仮に3ヶ月で見積もりを行うとして、あなたにとってその判断材料となるのは何があるでしょう？
* 過去の実績？全く同じシステムと技術を扱うわけでもないのに？
* 先方の見積もり？あてにならないから今まで遅延したプロジェクトが出てきたのでは？
* かつて見たメンバの力量？オフショアに置いてあなたの知ってる先方エンジニアが今もいる可能性は限りなく薄いです。彼らはすぐ辞めるので。
そう、実際にその見積もりに対して十分に有益になりうる材料って意外とないのです。

しかし、もしあなたが現場で彼らと一緒にコーディングを行っていればどうでしょう。
もしあなたが使用する言語やフレームワーク、ライブラリに対する知見があれば？

当然ながら、実装に時間がかかるポイントや習熟にかかる時間、また実装に関する具体的なイメージが持てるので、当然見積もりはより正確になります。
コーディングでは、書かなければわからないことなど山のようにあります。そのイメージが持てるでも見積もりに対して大きな判断材料となり得るでしょう。

書くべきメリットその2 多少の遅れは自分で巻きとれるようになる

僕の尊敬するエンジニア兼マネージャの方の受け売りなのですが、自分が部下に好きにさせていいのは自分が巻きとれるとこまでなのです。 オフショアの発注先は部下ではありませんが、それでも大きな遅延が発生した時は自分(もしくは自社の人間)で巻き取らなくてはいけないケースも多々あります。
自分がコードを書いていない場合、まず技術のキャッチアップに始まり、既存コードの把握し、遅延分のコードを書き始めるというデスマの夜が始まります。

設計はなんとなくわかるけど全く読んだことのないコード、しかもレビュがないので信じられないくらい汚いコードがそこに横たわっている。  
「どこから手をつけよう。」  
「まずは読まなきゃ。」  
「うーん、読めない、なんstepあるんだこのメソッド。」  
「リファクタリングするか。」  
「いや、テストがない。これではリファクタリングもできない。」  
「テストを書くか。」  
「いや、それでは間に合わない。そもそも入出力が全く参照透過じゃない。」  
「くそ、とりあえずコメント書きながらでも読むしかない。」  
「あぁ、朝だ…あと三日で終わらせないと…」  

こんなケースが現実に十分起こりうるわけです。
*あなたがコードを書かず、読まず、進捗だけを気にしていたせいで。 * ※この記事は過去の自分に対する自(ry

あなたが現場で一緒にコーディングを行うことで、あなたはコードの構造や設計、実装に対して当然ながら現場開発者並みに詳しくなります。
テストが必要な箇所や汚いコードに対してコメントすることもできます。
遅れが発生していた場合も、あなたはその遅れの最前線にいるので、その遅れを真っ先に知ることができます。
そして結果として、あなた自身がその遅れをコーディングによって比較的早い段階で容易に取り返すことができます。

遅れが発生して自分で巻き取らなくてはいけない状況というのは、ブリッジエンジニアとしてはマネジメント能力不足を問われかねない悲しい状況ではありますが、プロジェクトの目的は顧客に対して納期通りにデリバーすることです。
自分で巻きとれず遅延したり、全く知らないコードに苦悶しながらデスマしたりするよりかは、自分自身でいつでも巻きとれるようにしておくというのは、確実に顧客にとっても自分自身にとっても価値のある行為でしょう。

書くべきメリットその３ メンバの教育ができるようになる

このメリットは自分もコードが書けるのに書かせてもらえない方向けのメリットになります。
メリットその１の冒頭で例示した先方エンジニアの技術力不足というのは実は当たらずも遠からじなんですよね。
なぜなら、途上国におけるITビジネス、特にオフショア開発というのはまさに発展途上で、日本に比べて経験豊富なエンジニアの数というのが比較的少ないのです。
これは大学で理数系を専攻していた人間しかエンジニアになれないという海外では当たり前の採用基準も関係してたりするのですが。
何はともあれ、先方のエンジニアは年が若く技術力もまだまだ発展途上なことは非常に多いです。

では、そんな彼らに全ての実装を任せっぱなしにしていいのだろうか、いや良くない。

彼らの国では手本となる先輩も少なく、自然言語上のマイナ言語ではqiitaやstackoverflowなどのサービスもないのです。
では、あなたが一緒に現場で書いていればどうでしょう？
自分の書いたソースを参考として見せることも出来ますし、Pull Requestに対してコメントしたり、テストの書き方を教えたり、時には設計に関する講座を開いたり、ペアプログラミングなどで手っ取り早く技術力向上を測ったりできるわけです。
先方のエンジニアにとっても技術力向上の機会は得難いもので、喜ばれること間違いなしです。

書くべきメリットその４ 双方のモチベーションが上がる

実は個人的に一番メリットを感じてるのはここなんですよね。
ブリッジエンジニアと現場のエンジニアって、かなりクライアントと発注先という壁があってチームとして活動してる感覚がない人が多いんです。
酷い場合だと先方の代表者とだけしか話せなかったりして、現場の開発者の顔も名前も知らないなんてことはザラですね。

人間って基本的に顔を知ってる人のためには頑張るし、顔を知らない誰かに対しては平気で無責任になれるんですよ。
あなたが顔を知らない開発者に対して怒りをぶちまけたり、逆に向こうの開発者が悪びれもなく遅延して来たりするのもこれが大きな原因だったりします。

それでは、もしあなたが一緒に現場で開発していたらどうでしょう？
誰かが作ったモジュールに対して質問をしたり、逆にあなたが質問されたり、当然現場の開発者とのコミュニケーションが増えます。
あなたがコーディングの現場に開発者として参加するだけで、顔の見える人間同士のチームとしてのコミュニケーションが可能になるんです。

あなたが十分にコーディング力のある開発者であれば尊敬されることも増えて来ます。
偉そうに踏ん反り返ってる発注元のおっさんから、尊敬するエンジニアの一人に成れればこちらのものです。
先方のあなたに対する信頼と開発に対するモチベーションは確実に高まるでしょう。

あなた自身のモチベーションもそうです。自分自身でコードが書ける上に、きちんとリスペクトを払ってもらえる。ただ発注元として進捗管理していた時は味わえない感覚です。
時には先方のエンジニアから学ぶこともあるでしょう。

僕は「SpringのAutowiredはプロパティベースよりコンストラクタベースの方がいいよ。」というのを先方のエンジニアに教えてもらいました。
考えてみれば当たり前なのですが、仕事としてコードを書くことから離れ、趣味でしか書けなかった時代にはなかなかたどり着けなかったでしょう。
自分でコードを書き、自分のコードを相手に見せているからこそできる体験です。発注者として進捗管理をしていたらきっと僕はいまだにfield値にAutowiredしていたことでしょう。

最後に

ブリッジエンジニアがコーディングを行うメリットをつらつらと書いてきましたが、いかがだったでしょう？
前時代のSIer的なオフショア開発は双方にとってあまりメリットがなく、双方がリスペクトしあい、発注者・受注者の垣根なく開発を楽しめる現場を作るためにも、ブリッジエンジニアもどんどんコードの開発現場に入っていくべきだと僕自身は考えております。
今もしコードが書きたいのに立場上書けないエンジニアの方々がいらっしゃれば、ぜひこの記事を参考に上司に掛け合ってみてもらいたいです。
コーディングは楽しいですし、コーディングと技術を愛するあなたが現場に入ることはきっと製品にとっても有益なはずです。
以上、エンジニアはコードを書くべきではないか(いや、書くべきだ)でした。

コマンドラインからAWSでMFA(多要素認証)する

こんにちは？こんばんは？四時って言ったらどっちかなぁ？
よし！こんばちは！

さて、技術関連記事の2回目です。 (書き溜めてるので、本当に二番目に公開されてるかは知らない) 最近ちまちまとbashスクリプトを書くのに疲れて来たので、真剣にスクリプト言語を勉強し始めました。
もともとPHPとnodeは少し書けるんですが、これから解析系の仕事が増えてくるので、Pythonかなぁってことで、Pythonです。

最初に書くスクリプトどうしようかなぁと思ってたんですが、最近AWSのMFAを自分のスマホからやってる人多くないですか？
あれBYD禁止の会社でも普通にやってる人いて普通に気持ち悪いなぁと思ったので、コマンドラインから認証、session tokenを取得して環境変数にセットするところまで書いて公開しようかなと考えております。

本題へ

さて、タイトルの通り、今回の記事ではまずコマンドラインからAWSの多要素認証をする方法について書こうかなと思います。

やり方は非常に簡単。以下の手順でpipからmfaをインストールします。 pipを使うので、pythonをインストールしておいてください。

$ pip install mfa

mfaがインストール出来たら、次のコマンドで秘密鍵を登録します。

$ mfa set ${key} ${secret_key}

ちなみにご存知かと思いますが、秘密鍵はここから取れます。

これで準備は完了、loginに必要な６桁の認証番号は次のコマンドで取れます。

$ mfa otp ${key}
123456

※otp=One Time Pass。。。かな？

これであなたもちょっとセキュリティ意識高まった系。 ちなみにmfaはpipが使えることからわかるようにきちんとPyplで公開されてます。 pypi.org ソースはここ。 github.com

Python楽しいですね。4000円出して買ったかいがあった。

きっと誰も読むことのない自己紹介

やあ （´・ω・｀) ようこそ、バーボンハウスへ。 このテキーラはサービスだから、まず飲んで落ち着いて欲しい。 うん、「初めて」なんだ。済まない。

...っと、釣りではありません。そもそも釣れるタイトルじゃないし。

初めまして、まんちかんと申します。

日本を離れ、アジアのある国でSaas開発者として働いています。 下請けじゃないよ、ちゃんとサービス作ってるよ。

さて、もともと文章を書くのがそれほど得意な方ではないのですが、技術的アウトプットが自分と会社だけに持っていかれるのも癪なので、ブログをはじめてみました。 技術者自称する以上はきちんと書かないとね。コミュニティに貢献しないとね。

それにね、勉強した内容が増えるにつれてね、忘れてくんですよ。 JVMのC2コンパイラの仕組みも、RealmSwiftのupdateを柔軟に書く方法も、昨日の晩御飯も、彼女との楽しかった思い出も。

記憶するだけではいけないのだろう。思い出さなくてはいけないのだろう。

って数学ガールにも書いてあったしね。（調べたら小林秀雄の言葉だったらしい）

と言うことで、暇なときに勉強したこと、発見した技術的課題への解決方法、今いる国のこと、読んだ本とか、色々更新していこうかなと思っています。 基本的には日本語で、見つけたもん勝ちのbugや例外への対応方法、新しい技術に関する話題なんかは英語で書いていこうかなと思っています。

ではでは。