最近では「マイクロサービス」と呼ばれる、機能毎に細かくサービスを分割して開発や運用を行うアーキテクチャの採用例が増えている。本記事ではこのマイクロサービスアーキテクチャや、それに使われる技術について紹介する。 マイクロサービスとは 近年、ITシステムの開発・運用において「Microservice（マイクロサービス）」というアーキテクチャを採用する例が増えている。マイクロサービスアーキテクチャは、簡単に言えばサービスを構成する各要素を「マイクロサービス」と呼ばれる独立した小さなコンポーネントとして実装するという手法で、2011年ごろから提唱されているものだ。 マイクロサービスについては、2014年に公開された「Microservices」という文書が有名だ（有志による日本語訳）。また、さくらのナレッジでも2015年に紹介されている。マイクロサービスの詳しい思想についてはこれら記事を参照してほ

本記事はコネヒト Advent Calendar 2018 - Qiitaの4日目のエントリーです！ こんにちは！人事をやっています宮崎です。お土産では岩手のかもめの玉子が好きです。 今日は近年流行しているOKRに関する話をしたいと思います。コネヒトでもOKRを導入しておりますが、その推進でこれまで大事にしてきたことを一部共有させてください。 OKRとは何か？ OKRは雑に言うと、目標管理のメソッドです。Objective ＆ Key Resultsの頭文字をとって呼んでいます。 2014年に出版されたHow Google Worksで、Googleが採用している管理手法だと紹介され、ITスタートアップを中心に流行しています。国内ではメルカリさんが上手に導入しているのが有名ですね。ちなみにこのメソッドを生み出したのはGoogleではなくインテルの創業者らしいです。（豆知識） Objecti

今年もMercari Advent Calendar 2018 が始まりました。初日は @stanaka がお送りします。 メルカリでは創業以来開発してきたPHPのアプリケーションから(主に)Goで実装されたマイクロサービスアーキテクチャへの移行を進めています。これまでにMercari Tech Conferenceやその他のカンファレンスでMicroservice化の意義、移行の方法、基盤となるMicroservice Platformの概要などについて様々な発表をしてきました。 現在、来年からの本格的なマイクロサービスアーキテクチャでの開発に向けて、これまでのサービスの施策ドリブンのチーム編成から、マイクロサービスを軸としたチーム編成に移行しようとしています。 しかし、マイクロサービスアーキテクチャを成功させるためには、各種プラットフォームの機能を揃え、それらを利用したマイクロサービス

『場所』とは重要だ… この世で唯一無二を意味する座標。 だが、杜王町は『2ヶ所』あった。 旅の記録 GWにギリシャへ行ってきた。このこともブログに書くつもりであるが*1、それより優先すべきものがある。俺は年末年始に杜王町へ行ってきた。『ジョジョの奇妙な冒険』の聖地巡礼である。 ジョジョの奇妙な冒険 第4部 モノクロ版 1 (ジャンプコミックスDIGITAL) 作者:荒木飛呂彦集英社Amazon ジョジョの奇妙な冒険 第8部 モノクロ版 1 (ジャンプコミックスDIGITAL) 作者:荒木飛呂彦集英社Amazon 本当なら一枚のＣＤを聞き終わったら、キチッとケースにしまってから次のＣＤを聞くように、記事を書いてから次の旅へ出るつもりであった。しかし様々な事情*2から成しえなかった。 だからせめて『流れ』は変えずに書くことにした。『流れ』とは比喩ではあるが、逆らわなければ目標に必ずたどり着ける

現在IETFで仕様策定が進められている、UDPをベースに効率的で高速な通信を実現するためのプロトコル「QUIC」をトラスポート層に用いる新しいHTTPの名称が「HTTP/3」になることが決まりました。 HTTP/3のベースはGoogleが開発したQUIC。IETFで標準化へ もともとQUICは、Googleが高速なHTTPの通信を実現するためのプロトコルとして2013年に発表し、同社のChromeブラウザやクラウドサービスなどに実装してきました。 QUICは、従来のHTTPでトランスポート層に用いられているTCPの代わりに、UDPを用いています。 TCPはエラー訂正機能などを備え信頼性の高い通信が可能な一方、比較的オーバーヘッドの大きなプロトコルです。そこでTCPの代わりに通信の信頼性は保証されないもののオーバーヘッドの小さいUDPを用い、独自に一定の信頼性を保つ実装を組み込みつつHTTP

エンジニアのためのマネジメントキャリアパスという書籍が出版されました。 タイトルに書いたとおり、マネジメントに興味がなくても、読むこと大きな学びをもらえる本です。 及川さんが前書きを書いており 本書を読み終わった後、私はひどく落ち込んでいる自分に気づきました。 ~中略~ 内容が素晴らしい故に、いかに自分が未熟であったかを思い知らされた と、記載があって衝撃を受けました。 及川さんが落ち込んだら、私なんて精神崩壊してしまうのではないか…！？ 本書を読んで、精神崩壊こそしなかったですが、ひどく落ち込みました。自分のレベルの低さを痛感します。 本記事では本書の知識定着のためのアウトプットと、所感をまとめています。各章毎にピックアップして記載します。 書籍の内容 1章 マネジメントの基本 2章 メンタリング 3章 テックリード 4章 人の管理 5章 チームの管理 6章 複数チームの管理 7章 複数

先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と

2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ．タイトルの通り，コンテナのデザインパターンがまとまっていて，これからコンテナ設計をする人も，既にコンテナを運用している人も，デザインパターンを学べるのは価値があると思う．一部ミスリードをしているかもしれない． Design patterns for container-based distributed systems 論文も公開されている． https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45406.pdf パターン一覧 Single-container management pattern

grpc-gatewayの開発に学ぶ、ソフトウェアの設計手法～Yuguiが定めた、2つの基本設計方針 良いソフトウェアとはどのような方針のもとに設計されているのでしょうか。広く使われているOSSであるgrpc-gatewayの開発過程を作者のYuguiさんが振り返り、その設計手法を解説してもらいました。 こんにちは。 Yuguiと言います。 本記事では読者がより良いソフトウェア設計を行うための参考として、筆者が経験してきた設計上の決定をご紹介します。 筆者はこれまでRuby 1.9のリリースマネジメントを担当したり、Google Mapsの日本向け地理データ処理やgrpc-gatewayの開発などをしてきました。そしてこれらを通じて、広く長く使われて拡張されていくソフトウェアを設計するための方針決定に携わったり、方針に関わる良い議論を目にしたりする機会に恵まれてきました。中でも本記事では、

つい先日、メルカリ社＠六本木ヒルズにお邪魔してきました。 今や、東京だけではなく、仙台や福岡、そしてサンフランシスコからロンドンに至るまでグローバルに組織展開をしているメルカリ。 創業期に参画し、現在は社長を務めている小泉文明さんに、従業員数も数十人から1000人以上に至るまでの組織づくりの秘訣をご教授いただきました。 メルカリ@Koizumi さんによるHR勉強会参加してきました。 コーポレート・デザインは極めて重要な経営者マターで、思想レベルから運用レベルまで一貫した骨格が整えられるとポジティブなサイクルに入れて、良い組織が良いプロダクトを創る。 そのためのHOWをたくさん頂いたので、需要あればまとめます。 — 吉兼 周優 / SHUYU（Azit） (@shuyu_y) 2018年8月28日 ツイートした通り、スタートアップの経営者として目から鱗の連続でして、このメモを自分のものだけ

米Googleは9月12日（現地時間）、メールサービス「Inbox」の提供を2019年3月に終了すると発表した。メールサービスを「Gmail」に一本化する。 Googleは2014年10月に、Inboxをメールの実験的な機能をアグレッシブに提供していく場として立ち上げた。 Googleは、Inbox終了の理由を「誰にとっても最高のメール体験を提供するために、より重点的なアプローチをとっていくため」と説明する。 「スマートリプライ」など、Inboxで好評だった機能がGmailに追加されてきた。今年の4月にはGmailの大幅アップデートで、多数のInboxの機能がGmailに反映された。

<a href="http://archive.today/ziDQ8"> <img style="width:300px;height:200px;background-color:white" src="https://archive.md/ziDQ8/737033e9e30423acf2c23fbedbcd1520665bd28d/scr.png"><br> M社の採用について · GitHub<br> アーカイブされた 2018年9月11日 10:48:44 UTC </a> {{cite web | title = M社の採用について · GitHub | url = https://gist.github.com/syguer/1d035473bd964a122dba9b4bbef191e6 | date = 2018-09-11 | archiveurl = http://a

つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018

突然ですが皆さまはタコの刺身、好きでしょうか。僕は好きです。 生でもボイルでも分け隔てなく好きなのですが、あの絶妙の味加減と弾力のある歯ごたえ。虜になるなと言うのが土台無理な話で、とにかく刺身といえばタコというところまで追いつめられているのです。タコの刺身、好きすぎる。 この思いを多くの人が共有してくれると思うのですが、ある日、とんでもないことに気が付いてしまったのです。 いつものように行きつけの居酒屋にてタコの刺身を味わっていた時のことでした。当たり前のように美味い刺身なのですが、なにかいつもと違う。こうなんというか、いつもと違う深いコクが立体構造のようになって口の中に広がったのです。これはどういうことだとマジマジと刺身を眺めたのですが、まあ、普段と変わらないタコです。むしろいつもより鮮度が悪いとすら感じました。それなのになぜここまで深い味わいが出るのだろうか。 しばらく考えたのですが、

ソフトウェア開発の様々な局面で役に立つ、心理学的現象や行動経済学についての知識です。 経験則で把握済の事柄もあるかもしれませんが、 言語化して名前を与えることで何かのときにスッと出せたり、周囲の方々と議論しやすくなったりすると思います。 以下の3つの分類で記載いたします。 打ち合わせやチームワークに役立つ知識 設計やプログラミングに役立つ知識 メンタルヘルスケアに役立つ知識 打ち合わせやチームワークに役立つ知識 自己効力感 自己効力感とは、自分には何かを達成する能力がある、と信じる感覚です。 自己効力感が形成されていると、仕事の意欲が増したり、効率が上がったりします。 「この仕事は絶対ムリ～(>_<)！」と感じている仕事についてやる気がわかなかったり進捗が出なかったりするのは、自己効力感の欠如が原因であることがあります。一旦やる気を出すと案外簡単に進められたとか、真剣に取り組むと思ったより

はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを

「アプリケーションエンジニアが知るべきDNSの基本」というタイトルで、builderscon tokyo 2018 で登壇するスライドです