2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て

こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut

【プレゼントのお知らせ】 電ファミDiscordサーバーにて、『DIMENSION REIGN』の特設チャンネルを開設しました。 特設チャンネル内でコメントいただいた方から抽選で5名様に『DIMENSION REIGN』Steamコードをプレゼントします！ ぜひゲームへのご意見やご感想などをお聞かせください！ 聞き手／TAITAI 聞き手・文／実存 類地健太郎氏ソーシャルゲームに必要なコストが上がりすぎた──今回の取材の趣旨としては、長年ソーシャルゲーム業界でゲームを作り、さまざまなタイトルを手掛けてきた類地さんが、なぜSteamでゲームを作ろうとしているのか、をお訊きしたいと思います。 普通に考えたら、独立したとはいえ、スマホのソーシャルゲームをずっと作ってきたという強みがあるのだから、そこで戦えばいいんじゃないかと思うんです。 類地健太郎氏（以下、類地氏）： 一番大きな原因としては、「

この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき

ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という

こんにちは。普段は「冬木糸一」というハンドルネームで、ブログ「基本読書」などにSFやらノンフィクションについての記事を書き続けています。 SFとは「サイエンス・フィクション」の略で、ざっくりと説明すれば、科学的空想（社会科学や人文科学も含む）が投入された作品群のこと。その中でも、今回は「初心者向けのSFを紹介してください」との依頼を受けたので、その線に沿って作品を紹介していこうと思う。 とはいえ、何らかの基準がなければ作品を列挙し続ける羽目になる。そのため、今回紹介する切り口としては、まず「古典的名作SF」は省くことにした。また、実際に僕自身がSFを読み始めるきっかけになった作品、短編集、登場人物の恋愛模様を描いた作品、ハリウッド映画の原作など、文庫化済みで手に取りやすいものを選んでいる。 自分のSF読書歴を振り返ってみるに、どこかの瞬間にSFというジャンルへガツンと入り込んだという記憶は

品質の高いコードを書くには、TDD（テスト駆動開発）ではなくてもテストを念頭に置いてコーディングする必要があります。ところが、数あるPHPのテストツールから必要な機能は備えつつも、重すぎない適したツールを選ぶのは大変です。 そこで2017年時点でおすすめする、8つのテストツールを紹介します。 PHPUnit PHPUnitは幅広く使えるテストフレームワークです。2014年にSebastian Bergmannが開発し、最新版はバージョン6。PHP 7が必要です。 Cucumber Cucumberは仕様に基づいて受入れテストを作成するフレームワークです。自然な文章の説明文を生成することで有名です。Cucumberの公式なPHPの実装はBehatです。 Behatの初心者向けチュートリアルです。以下のサンプルで、期待される動作がどう表現するのか分かります。 Feature: Listing

ども、@kimihom です。 今回は月額課金モデルの Web サービスを実現したい企業向けに設計の参考になる情報を提供できればと思う。こういう情報は割と自分なりに設計して実装するっていうパターンが多いかと思うが、とても大事なことなので慎重に検討していこう。 決済サービスの選択 まずは決済サービスをどれにするかって話。ここで一番大事なのは、扱うカード提供会社の種類だ。 Visa, Master は当然として、その他のクレジットカード会社が使えるのかどうか。ここは顧客のカード登録の自由度を決めるので、実は決済手数料よりもよっぽど大事な項目になる。要チェックだ。 あとは企業によっては収益が出た後の支払いフローも確認しておいたほうがいいかもしれない。収益の確定はいつで、支払いはいつなのか。黒字倒産するほど急成長することは稀だとは思うが、そのあたりのキャシュフローも事前に把握しておく必要がある。

はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1

数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM

この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談

このウェブサイトは販売用です！ cunited.jp は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、cunited.jpが全てとなります。あなたがお探しの内容が見つかることを願っています！

AWSでは様々な便利なサービスが提供されています。中にはRDSやElasticCacheのように既存のミドルウェアに対するマネージドサービスを提供するものもあり、これらについては既存のミドルウェアを使って開発することができますが、AWS固有のサービスについてはアプリケーションを動作させるには実際にサービスに接続する必要があり、開発環境が制限されてしまいます。 もちろんソフトウェア側で抽象化しておき、DIなどの手法を用いてモックに差し替えるという方法も考えられますが、特にストレージとして利用するサービスなどの場合はインタラクションが必要になるのでモックでは再現しづらいですし、やはり実際に動作するサービスに接続して開発やテストを行うほうが効率的です。 そこで、AWSのサービスを擬似的にローカルで再現することのできるプロダクトを集めてみました。 S3 node.jsで動作するs3-proxyが使

はじめよう TypeScript - 入門から実践まで - 素の JavaScript とはさようなら!

http://nanapi.jp 本日2009年9月1日、株式会社ロケットスタートの新サービス「ナナピ」をリリースしました。 「ナナピ」はライフレシピと呼ばれる生活の便利な知恵や、ノウハウをみんなに共有してしまおう！というサービスです。 なんとか予定通り9/1にリリースをすることができました。すでに投稿数が160ほどあり、生活に便利な内容が投稿されています。 http://r.nanapi.jp/162/%E3%81%82%E3%81%8F%E3%81%B3%E3%82%92%E6%AD%A2%E3%82%81%E3%82%8B%E6%96%B9%E6%B3%95/ http://r.nanapi.jp/158/%E3%83%AC%E3%83%99%E3%83%AB%E3%81%8C%E4%B8%8A%E3%81%8C%E3%82%8B%E6%8C%A8%E6%8B%B6%E3%81%AE