こんにちは、プレイドの @nashibao です。今回は少し前に話題になった <a href="https://metaparticle.io/tutorials/javascript/">Metaparticle</a> というプロジェクトについて紹介します。
<code>Metaparticle</code>は <code>a standard library for cloud native applications on Kubernetes.</code>と唄っていますが、要はjava/javascript/goなどのapplication code上にdocker/k8sのInfrastructure/Orchestrationのうち、Applicationとして関心がある部分は組み込んでしまおう、というプロジェクトです。
多機能のサービスを開発していると、様々なところで有限のベストプラクティス（ただし単一では無い）に沿ったDistributed Programmingをして堅牢性や冗長性を高めたり負荷分散をしたくなります。
ただ、これらを実現したいと考えて設計/実装をするのは多くはApplicationエンジニアですが、Infrastructure/Orchestrationの様々なツールがその間に横たわっていて機動性が失われてしまいます。
<h1>CloudのThread/ProcessとしてのContainer</h1>
Threadは扱いやすいです。パフォーマンス等を考えて様々なパターンを駆使して劇的にApplicationのパフォーマンスを上げることができます。
Processは？そこまで隔たりはありません。プレイドで好んで使っているNode.jsでいえば <a href="https://nodejs.org/api/cluster.html">Cluster</a> moduleを使うだけです。
<pre><code>const cluster = require('cluster');
if (cluster.isMaster) {
 // master
 cluster.fork();
} else {
 // worker
}
</code></pre>
ThreadもProcessもどちらもworkerへの分散には色々なパターンがあって、それらを使うと並列性が高いプログラムを容易にかけます。iOSの<code>NSOperationQueue</code>などその代表ですが、各言語に様々なパターンがあります。そしてこれはApplicationエンジニアの手元にあって自由に設計できます。
Containerは？yamlの世界、kubectlの世界です。Applicationエンジニアの手元にあるように見えて遠くに行きがちです。PortとVolumeがコントロールされていて、古き良きPubsub/Queueやmessaging用の各ツール（zeromqは好きだ）を使って自由に協調はできますが、言語が異なる他のPlatformというものが邪魔をします。
<h1>Language idiomatic cloud</h1>
分散性をある程度ラップしつつ、コントローラブルにするアプローチは昔からあって、例えば <code>MapReduce</code> があります。<code>Metaparticle</code>と目的は似ているがPipeline状のData処理に特化している所が異なります。<code>PySpark</code>を使うとlambda関数を単にローカルで動かしているのと同じように見えます。<code>Google Dataflow</code>や<code>Apatch Beam</code>もまま似てる。
Microservice流行りで、<a href="https://aws.amazon.com/jp/lambda/">AWS Lambda</a>や <a href="https://cloud.google.com/functions/">Cloud Functions</a> のような便利なツールが出てきてるので <a href="https://github.com/pywren/pywren">pywren</a>のように、それらをwrapしちゃえば良くね？みたいなアプローチもあります。
<pre><code class="language-python"> def my_function(b):
 x = np.random.normal(0, b, 1024)
 A = np.random.normal(0, b, (1024, 1024))
 return np.dot(A, x)

 pwex = pywren.default_executor()
 res = pwex.map(my_function, np.linspace(0.1, 100, 1000))
</code></pre>
サイトに書いてあるコードそのままだけれど、中が同一スレッドだろうが、別プロセスだろうがAWS Lambdaだろうが同じようなマナーで書けます。
<h1>Metaparticle</h1>
<code>Spark</code>や<code>pywren</code>はかなり抽象化されていて、やれることも制限されますが（その代わりパフォーマンスに焦点がある）、<code>Metaparticle</code>はもう少し自由度に焦点があります。つまりdocker/k8sのconfigへcompileするためのメタ言語のようなものです。
<pre><code>const mp = require('@metaparticle/package');

mp.containerize(
	{
 	ports: [8080],
 	replicas: 4,
		 runner: 'metaparticle',
		 repository: 'docker.io/docker-user-goes-here',
		 publish: true,
		 public: true
	},
	() =&gt; {
		// closure for each workers
	}
);

</code></pre>
これだけです。これを素で使っても良いけれど、先ほどいった有限のパターンについては <code>standard library</code>なので当然提供する。sharingなら
<pre><code>const http = require('http');
const os = require('os');
const mp = require('@metaparticle/package');

const port = 8080;

const server = http.createServer((request, response) =&gt; {
	console.log(request.url);
	response.end(`Hello World: hostname: ${os.hostname()}\n`);
});

mp.containerize(
	{
		ports: [8080],
		shardSpec: {
			shards: 3,
			&quot;urlPattern&quot;: &quot;\\/users\\/(.*)[^\\/]&quot;
		},
 repository: 'docker.io/your-docker-user-goes-here',
 publish: true,
 public: true,
		runner: 'metaparticle',
	},
	() =&gt; {
		server.listen(port, (err) =&gt; {
			if (err) {
				return console.log('server startup error: ', err);
			}
			console.log(`server up on ${port}`);
		});
	}
);
</code></pre>
だし、electionなら
<pre><code>var mp = require('@metaparticle/sync');

var election = new mp.Election(
 // Name of the election shard
 'test',
 // Event handler, called when a program becomes the leader.
 () =&gt; {
 console.log('I am the leader');
 },
 // Event handler, called when a program that was leader is no longer leader.
 () =&gt; {
 console.log('I lost the leader');
 });

election.run();
</code></pre>
という感じです。上に書いたように、ここは有限のパターンがそれなりにあるので、それらが今後作られていくのだろうと思うが今の所ほぼ上の二つくらいしか書かれてないw
<h1>感想</h1>
thread/processとのアナロジーなどからContainerが扱いやすくなることについて書きましたが、<code>metaparticle</code>自体はdynamicにcluster/podを変更するわけではありません。scriptでdynamicに変更できるようになると、より上記のアナロジーがハマり、k8sに乗っかったままかなり柔軟に分散プログラムが書けると思ったりします。 
プレイドでも下手にクラスタ管理や組込済みの単純なオートスケールを使うより、nodeのgcp/api経由でインスタンス数の増減をさせるやり方をやってみたりしつつ、なんか違うな、と思ったりしていますw
今回は<code>a standard library for cloud native applications on Kubernetes.</code>な<code>Metaparticle</code>を紹介しました。個人的にはこのアプローチの先にDistributed Programmingの桃源郷があるのかもしれないし無いかもしれないと思っています。
CXプラットフォーム「<a href="karte.io">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。

こんにちは、プレイドの @nashibao です。今回は少し前に話題になった [Metaparticle](https://metaparticle.io/tutorials/javascript/) というプロジェクトについて紹介

Kubernetes to Metaparticle. 分散プログラミングへの新しいアプローチ | PLAID engineer blog

Kubernetes to Metaparticle. 分散プログラミングへの新しいアプローチ

KARTEのロゴ刷新に至った経緯やデザインプロセスについてお伝えします！

刷新したKARTEロゴのプロセス公開 ー プロダクトが目指す理想像から始めるアプローチ | PLAID engineer blog

刷新したKARTEロゴのプロセス公開 ー プロダクトが目指す理想像から始めるアプローチ

おはようございます！プレイドのエンジニアの <a href="https://twitter.com/jumpei_ikegami">@jumpei_ikegami</a> です。 
趣味はポッドキャスト配信です。
さて、プレイドでは定期的に、開発チームで合宿に行っています。
(過去の開発合宿のブログ記事は下記）
<a href="http://blog-plaid.com/event/2772/">2016年:秋</a>
<a href="/plaid-developpers-camp-2017-spring/">2017年:春</a>
今回は、開発フォーカスの区切りということで、前フォーカスの振り返り、4月以降の新チーム体制でのフォーカス、プロダクトの見せ方などについて、議論を深めてきました。
開発をしない開発合宿も珍しいと思いますが、目の前の開発業務を離れて、長期的な視野で開発の仕方や、何をするべきかを見つめ直すことで、本当にやるべき仕事にフォーカスできるようになります。
特に、<a href="/software-development-not-start-from-shu/">先日のエンジニアブログ記事</a>で弊社kadoppeが書いていた、「『常にゼロベースで考えて進む』プレイドの文化」が、議論の中にも表れていました。
そんな開発チーム合宿の様子を、写真多めでお送りします。
<h1>五反田発、館山行き貸切バス</h1>
館山の合宿先までは、オフィスのある五反田から貸切バスで移動しました。
バスの写真は、私が寝ぼけていたのでありません。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5e8fb80a-ae61-455a-af07-e722a3f393cd/010-2.jpg" alt=""> 
（途中のサービスエリアで食べた、「つみれ汁:¥200」と、「ふきのとうの天ぷら:¥50」）
お酒が無いのが不思議です。
車内では、遠足気分を高めるための駄菓子の配給がありました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1a37dd1e-d700-42ad-b9c1-bef6a1f0573b/020-2.jpg" alt=""> 
(宿に着いてから「ソースせんべい」を食べる、ぐろっちさん)
<h1>海の見える宿</h1>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cf8baae9-a779-4953-9634-11eb1c205532/030-1.jpg" alt="">
今回は、千葉県館山市、房総半島の南の端にある「<a href="https://tateyama-retreat.jp/">館山リトリート</a>」という宿にお世話になりました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/68720b41-1492-4546-8ba8-e91932fae1d7/040-2.jpg" alt="">
議論に使った大広間からも、海が見えました。
考えに詰まったら大海原をみながら頭を整理することができました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/22d452a0-ffb7-47b8-85c4-9132b17c34a1/043-1.jpg" alt="">
食事は自分たちで準備するスタイルで、広々としたキッチンを自由に使えます。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cc1ae859-d3bd-40e0-b4c3-49cd063ec2ee/045.jpg" alt="">
<h1>ゼロベースで議論！議論！議論！</h1>
合宿のコンテンツは、ひたすら議論を重ねるものでした。
主な内容は4つありました。
<h2>未来のユーザーに、KARTEをどのように見せる？</h2>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23b7183b-23a9-4614-a915-7627c592c3a8/050.jpg" alt="">
「<a href="https://karte.io/">KARTE</a>のキャッチコピーを考える」という題材を通して、未来のKARTEユーザーにどんなメッセージを伝えたいかを考えました。
出た意見をいくつか挙げます。
<ul>
<li>KARTEを単なるツールとしてではなく、プラットフォームとして見せていくべき</li>
<li>要望への「最適化」では足りない。それを知った上で、どう期待を超えていくか？</li>
<li>クライアント企業の指標を上げるだけではなく、その先のエンドユーザーを幸せにすることを含めて見せ方を考えたい。是即ち「愛」</li>
</ul>
開発チームの仕事は、ただプロダクトを作って終わりではありません。 
自分たちが作っているプロダクトがどのようにユーザーに届けられるのか、という点についても関心が高いのが、プレイドの開発チームのよいところだと感じました。
<h2>チーム間の連携、どうすればうまくいく？</h2>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3640d85d-416a-4dc6-a5cd-d9d31267dfdb/060.jpg" alt="">
これまで、開発内の別チームや、ビジネス側のチームとの連携などがうまくいかなかったことで、手戻りが発生したり、ユーザーへのデリバリー方法に問題が生じたりしました。
そこで、「チーム間連携」というテーマで、理想・課題・解決策を挙げるために議論しました。
出た意見をいくつか挙げます。
<ul>
<li>理想は、「スタンドプレーから生じるチームワーク」</li>
<li>チームを固定化せずに、ビジネスメンバーも巻き込んで流動的に変えていく</li>
<li>生産性を優先すると、社内で情報格差が生じてカオスになる。それをある程度許容すべき。ルールを作るのではなく、そういうカオスな状況でもパフォーマンスを出せるメンバーを増やしていく方が建設的</li>
</ul>
「チーム間連携」という話だと、「定例ミーティングしよう！」というような安易な話になりがちです。 
それを超えて、さらに深い議論に発展していたのが、印象的でした。
プレイドには「常にゼロベースで考える」以外にも、「ルールをなるべく作らない」という文化があります。今回の議論も、ルールではなく、マインドやチームのあり方の話で課題を解決しようとするところに、「らしさ」が出ていました。
<h2>コーヒーブレイク</h2>
休憩時間では、コーヒー好きが集まるプレイドらしく、コーヒーミルを持ち込んで、コーヒーを飲むメンバーもいました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/705d5c03-7111-4b1e-bece-7e74b01ea541/070.jpg" alt=""> 
(ハッピーターン」を取りに来た、デザイナーのミギーさん)
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2b9eb2ad-e8c2-46db-8418-ecf2ef85ff3e/080.jpg" alt=""> 
(カメラを向けると、わざとらしい笑顔を向けてくる、ぐろっちさんと、ノブくん)
全く外に出る時間はありませんでしたが、昼間の天気も最高でした！ 
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/08c6cf6d-e1c3-45bd-9261-d249b0b55700/090.jpg" alt="">
<h2>新しいチームでのミッションどうしよう？</h2>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/320f652e-821e-49ba-a0f5-cf3a5ad302bd/100.jpg" alt="">
4月から開発チームの再編があり、最初の3ヶ月で行うミッションの言語化、状態目標の設定、注力issueの洗い出し、などを行いました。
PLAIDには固定的な「部署」という概念はなく、定期的にチーム構成が再編されます。 
それによって、ナレッジが蛸壺化しにくくなったり、個人が色々な役割を担えるようになります。
開発チームも同様で、機能の多いKARTEの中でも、定期的に自分が開発を担当する機能が変わっていきます。
この議論では、前のチームでのやり方に捉われず、そもそもどんな課題を解決するべきか？を「ゼロベース」で考えていきました。
私はBizDevチームというビジネスサイドのチームに属しているのですが、「開発チームが作った機能のデリバリーに関して課題があり、その整備に注力していこう」という目線合わせができてよかったです。
<h2>前フォーカスどうだった？</h2>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9b6f792f-35a1-426e-8286-857fc92ad9fd/110.jpg" alt=""> 
(CTOが買って飲まなかった「プロテインドリンク」をみんなで勝手に飲んでいる図)
最後に前回のフォーカスについて、その進め方のKeepとProblemをみんなで挙げていきました。
出た意見をいくつか挙げます。
<ul>
<li>Keep
<ul>
<li>作り始めたものを一回壊して、ゼロから作り直すことで、本当に良いものができた</li>
<li>「既存機能の改善」を束ねて大きくリリースしたのは、ただ新機能を出すより難しいことができた</li>
<li>チームが自律的にパラレルで動けるようになった</li>
<li>1人でやるよりもチームでやることで、より良いものができた実感がある</li>
</ul>
</li>
<li>Problem
<ul>
<li>差し込みタスクでスイッチングコストがかかった</li>
<li>もっと細かい粒度でリリースして、反応を見ながら開発しても良かった</li>
<li>チームの壁が厚く似たようなものを別で作ってしまったので、もっと流動的に人の入れ替えがあると良かった</li>
<li>不安定なテストがあるなど、フォーカス外のissueが放置されがちで、負債が溜まってしまった</li>
</ul>
</li>
</ul>
この議論についても、結果として、「新しいルール作ろう！」ではなく、「次に同じ状況になったらもっとうまくできる！」という実感の共有をできたのが、良かったと思いました。
次に似たような課題に直面するときも、チームメンバーやプロダクトの状況はそのときとは違うかもしれません。 
無批判にルールを当てはめるのではなく、その都度「全力で考える」という前提を置いた上で、その考えるための材料を、この議論で洗い出せたと思います。
<h1>うまい魚に、うまい酒</h1>
議論の合間の食事も、みんなで楽しみました。
1日目の夜は、豪勢に鯛のあら汁と寿司でした。 
寿司には、「ストロング・ゼロ」がよく合います。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f7e8c85f-a71a-414b-a8c0-7e9d1ce06a31/120.jpg" alt="">
一日中議論をしても、飲み会の話題は尽きません。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9b190878-dacf-49c9-9f36-5eb0c99582f3/130-1.jpg" alt="">
期待のルーキー、カンテの悪酔いに、先輩藤川くんも苦笑い。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18de3482-98db-424d-bf9b-2ba505576086/135.jpg" alt="">
2日目の朝から、余った寿司を食べました。箸がなかったので、まさかのスプーンです。 
寿司は昼まで余ったので、夢の「3食お寿司のすしざんまい生活」が実現しました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/58f58376-5fc2-46c8-8f64-56aa9dc73d8b/140-1.jpg" alt="">
2日目の昼は、なんと海鮮鍋でした。 
このシズル感。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/73a2f0aa-8395-4c20-92f9-27e8b27fa2c5/150-1.jpg" alt="">
鍋にすると、こうなります。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5a4dbb25-68cc-4721-a775-77225a2a81d2/160.jpg" alt="">
<h1>アクアラインを通って五反田へ</h1>
2日間の日程も、あっという間に過ぎました。
帰りも、バスでアクアラインを通って東京に帰りました。
この日は強風が吹いていて、途中の「<a href="https://www.umihotaru.com/">海ほたる</a>」では階段を登っている途中で吹き飛ばされるかと思いました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2a1f54dd-515d-4c6e-b694-2eede764e709/170.jpg" alt="">
バスでは、一部のメンバーが余った「ストロング・ゼロ」で宴会をしていました。私も2本目を空けるまでは記憶がありました。
思えば、この合宿で何本の「ストロング・ゼロ」を飲んだのだろう。プレイドの文化は、「常にゼロベースで考える」こと。昼に「ゼロベース」の議論を重ねて、夜に「ストロング・ゼロ」を飲み明かす。これが本当の......「ストロング・ゼロ・ベース思考」？？
......ふと、目を開くと、そこはいつもの五反田の街でした。
ということで、合宿で持ち帰ったアイデアを、ここ五反田のオフィスから実現していきます！
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5cd766d1-f9ac-4d98-ab5f-f0654af798c3/180.jpg" alt="">
<h4>最後に</h4>
ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニアやインターンを募集しています。 
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a> 
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> 
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
 (function(d, s, id) {
 var js, fjs = d.getElementsByTagName(s)[0];
 if (d.getElementById(id)) return;
 js = d.createElement(s); js.id = id;
 js.src = "https://platform.wantedly.com/visit_buttons/script.js";
 fjs.parentNode.insertBefore(js, fjs);
 }(document, "script", "wantedly-visit-buttons-wjs"));
</script>

開発チームで、千葉県館山市に合宿に行って来ました！開発の節目ということで、KARTEをどう見せていくか、何にフォーカスすべきかなど、1泊2日に�

刷新したKARTEロゴのプロセス公開 ー プロダクトが目指す理想像から始めるアプローチ

刷新したKARTEロゴのプロセス公開ープロダクトが目指す理想像から始めるアプローチ