はじめに こんにちは、SaaS Product Teamのヒロオカです。 SPEEDAではSpring Webfluxの採用が行われおり、一部リアクティブなシステムが動いています。 今回は、R2DBCという、リアクティブな非同期でRDBにするための仕様とSpring(Reactor Project) による実装およびサポートを利用して、APIの実装を試してみたいと思います。 はじめに R2DBとは リアクティブシステムにおけるJDBCの問題点 実際に使っていく 環境 事前準備 プロジェクトの作成 DBの起動 APIを実装していく 空ハンドラーの実装とルーティングの設定 リポジトリの実装 DBの諸々の設定 BDの初期化処理の記述 エンティティの作成 ReactiveCrudRepositoryを継承したリポジトリインターフェースを作成 ハンドラーの修正 終わりに 参考資料 R2DBとは 前述

この記事はRSGT2021に参加する方に向けて書いています。 さっこんの情勢を踏まえ、今年のRSGTにオンサイトで参加することを諦めました。 RSGTは僕にとってすでに一年ぶんの元気をもらう大切な場所になっていて、苦渋の決断です。 オンラインで参加すると腹をくくったので、この制約のもとで最大限RSGTを楽しむにはどうすればいいか？を考えてみました。 もし賛同してくれる方がいらっしゃったら、ぜひDiscordでぼくにおこえがけください。IDは suyama#7142 です！ 大前提ですが、当然、オンサイトで参加される方、またはカンファレンス自体、関連するいかなる個人・団体を非難したり貶める意図はまったくありません。 ですが、この記事は「僕がRSGTを楽しむために、いまから僕にできること」を念頭に、主に自分のために書きました。 もしこれを見て不快に感じる方がいらっしゃったら、申し訳ありません。

やったこと 68 冊 今年読んだ本は、68 冊で着地。 年始に 50 冊以下にするという目標を立て、7 月に 80 冊までに下方（上方？）修正したが、無事 80 冊以下にすることができた。 と言ってはみたものの、上限の 80 冊に対してずいぶん余裕があることからもわかるように、あまり意識的に努力して数をおさえた、という感覚がない。ふつうに読んでいたらこうなっただけ。 こうなった大きな要因の一つは、おそらく通勤がなくなったことだと思う。短い通勤時間（ドアツードアで 30 分）ではあるけれども、されど往復 1 時間。週 5 日、月 20 日で考えると、月に 20 時間、年間 240 時間にもなる。1 冊読むのにかかる時間が平均 4 時間だとすると、これだけで実に 60 冊分だ。なるほど。 ともあれ、冊数は減った。では、もともとの目的に対してはどうだったか。 もっと読むのに時間がかかるような本や

SaaS Product Team の野口です。 以前にもいくつかの記事で触れたように、SaaS Product Team では XP（エクストリーム・プログラミング）をベースとしたチーム開発に取り組んでおり、ほぼ全ての作業をペアで行っています。*1 かく言う私もこのチームに入ってから 1 年以上の間 *2、日々ペアプログラミングに取り組む中でわかってきたことがあるので、この記事で共有したいと思います。 XP はうまくいくことを極限（エクストリーム）まで推し進めることから生まれた ペアプログラミングは XP の 5 つの価値を極限まで推し進める 注記 コミュニケーション シンプリシティ フィードバック 勇気 リスペクト 旅は続く 一緒にペアプログラミングと XP を探求しませんか？ XP はうまくいくことを極限（エクストリーム）まで推し進めることから生まれた Kent Beck の『エクス

この記事は、Forgotten practices: The Backlog Priority Game (Zuzi Sochova) の翻訳です。 バックログの優先順位付けは、多くの企業にとってアジャイルの受容におけるもっとも難しい部分の一つです。では、それを正しく行う方法は何でしょうか？　推奨事項や、何らかの手法があるのでしょうか。それとも、プロダクトオーナーが決めればそれで十分なのでしょうか？　こういった質問や、似たような質問がよく出てきます。 バックログの優先順位付けについて、最もよくあるシナリオは次のような主張から始まります。「要件の優先順位は常に定めてきたし、今までそれなりにうまくいってるのに、どうして何かを変える必要があるっていうんだ？」　ところが、そのプラクティスをよく見て理解しようとしてみると、現実は通常、まったく調和の取れたものではないことがわかります。チームは個々の機

はじめに 「バックログ優先順位ゲーム（Backlog Priority Game）」について説明するこの記事を読んでいて、「魔法見積もり（Magic Estimation）」という手法に出会った。 agile-scrum.com You can play Planning Poker or do Magic Estimations to get the values, but remember that, to get good estimates, the numbers are just a side effect of the discussion, ... （値を得るために、プランニングポーカーや魔法見積もりをすることができる。ただし、よい見積もりを得るためには、数字はあくまで議論の脇役にすぎないことを覚えておくこと...） 魔法見積もり、むやみにワクワクする響きだな……！？　と思

ふと思い立ったので、2020 年前半をふりかえってみる。 やったこと 42 冊 読書メーターの記録によると、2020 年前半に読んだ本は 42 冊。 もともと 2020 年は読書数の上限を 50 冊までにするという目標を立てていたのだけれど、達成できそうにない。（超えてしまいそう） 6 月に会社の制度を利用して一週間の休暇を取ったとき、一気に 8 冊読んでしまうなど、消化が激しかった。 本の誘惑には抗いがたい。 新製品開発 この半年は新製品の開発に関わっていた。 事業開発・デザイナーのメンバーと組んで、高い技術力を持った開発チームの中で、既存のマイクロサービス群も活用しながら、とはいえほぼ一から Web サービスを組み上げる仕事。 システムシンキング 昨年はデザインシンキング、ロジカルシンキング、そしてアートシンキングと、さまざまな思考のあり方に触れる年だった。 そして今年になって、システ

はじめに マイクロサービスで、E2Eテストを書く際にマイクロサービスが依存するマイクロサービスを立ち上げるのが面倒だったり、時には現実的では無い場合があるなぁと最近感じてます。 そんな中でConsumer Driven Contract（CDC）という考え方を耳にはさみ、調べてみるとSpring Cloud Contractと言うプロジェクトでCDCをサポートしているということを知り、その機能を試して見ようと思います。 このブログでは以下のことを目指します。 CDCの概要を学ぶ Spring Cloud Contractの基本的な機能を利用してCDCしてみる Consumer Driven Contract(CDC)とは？ マイクロサービスアーキテクチャにおいて、マイクロサービスAのE2Eテストしたいと考えた際に、マイクロサービスAがマイクロサービスBに依存していて、更にそのマイクロサービ

社内slackでGoについて質問されて、それなりに長文で回答したのでその内容を加筆修正したものをブログに残しておく。 質問内容としては以下のイメージ。 RubyだとRailsがあり、MVCを利用することになるが、Goだとそこらへんはどうなるのか? Go初心者なのでGoのモダンなアーキテクチャとフレームワークについて教えて欲しい。 これ系の質問はGo経験者であれば「あーこれなー」と思うだろーし、 Go初心者のときに一度は悩んだことがあるだろう。 なので、個人的な意見を残しておく。 自分の意見が正しいかどうかは自己判断して欲しい。 結論 アプリケーションアーキテクチャの複雑化とMVCフレームワーク システムアーキテクチャの複雑化とフルスタックなフレームワーク マイクロフレームワーク 改めて質問内容を振り返る pospomeが考えるGoのフレームワーク選定 pospomeが考えるGoのアーキテク

初めて会社のブログに書きます。SPEEDA事業でCTOをしている林です。 TDDをこよなく愛する身として今日はDartでTDD、そしてテストの独立性を担保していく上で欠かせないMockライブラリーのMockitoについて書こうと思います。 Mockitoとは 今回Mock化するクラス 事前準備 Mock用クラスを定義する 振る舞いを定義する 振る舞いを定義する（Future、Streamの場合） 検証する 検証する（回数チェック） 検証する（引数チェック） 検証する（呼び出し順序） Fakeクラス 出来ない事 まとめ Mockitoとは Dart開発チームが作成している公式Mockライブラリーです。 名前の通りJavaにおいてメジャーなMockライブラリーの1つであるMockitoにインスパイアされたもので、DartでMockオブジェクトを使う場合においてもっともメジャーな選択肢となってい

2019 年をふりかえります。 やったこと 1000 冊 読書メーターの記録によると、今年は本を 100 冊ほど読んだ。 ここ数年、安定してそれくらいのペースで読んでいる。 これで、読書メーターを始めた 2011 年からの 9 年間で読んだ本が 1000 冊を超えた。 転職 7 月には転職した。 転職先の開発チームがなかなかユニークな文化を持っていて、入社からこれまでの半年間に Kotlin、Go、Clojure、Dart という（実務で使ったことのなかった ）4 種類の言語を学び、使うことになった。（というか、初日から一通り書くことになった） また、（こちらは慣れ親しんでいた）TDD やペアプログラミングといった XP のプラクティスを日々実践することになったものの、想像以上の文化の違いに慣れるのに少々時間がかかった。 シンキング 今年の序盤にはデザインのことをずっと考えていて、いわゆる

今日は。 SPEEDAの開発をやっている濱口です。 SPEEDA開発チームではテスト駆動開発(TDD)、ペアプログラミングを徹底しています。 だからなのか、『テスト駆動開発』はすごく楽しく読めました。 今回ハンズオンを行った「第I部 多国通貨」でも、ペアプロをしながら著者が語りかけてくるような感じで、 読者側も、著者の意図をひとつずつ理解しながら読み進めていけるようになっています。 有意義なハンズオンを、より有意義にしたい 古くてあたらしい言語(環境)、Smalltalkにふれたい Smalltalkでは、わりと忠実な写経が可能だった Javaのコンストラクタのような特別なメソッドが無い インスタンス変数のスコープと意図を伝えるためのプロトコル 型が無い(untyped） 有意義なハンズオンを、より有意義にしたい ただ、そうは言っても、 読むだけよりも手を動かしたほうがよいと思いますし、

こんにちは、SPEEDA開発チームの @tkitsunai です。 最近リリースされたプロダクションコードにようやくGo言語が採用されました。嬉しい。 今回はGo言語でオブジェクト指向プログラミングで型表現についてのテクニックや考え方の基礎を紹介します。もっとGopherが増えて欲しい！ 対象読者 型を定義する 型で厳格さを作り、その型を洗練させる 改良1: プリミティブ型をなくす 改良2: Unitの特性を型で表現する 型に厳格さを求める完全コンストラクタを活用する ファーストクラスコレクションと型定義によってメンバーに対する操作を制限する 列挙型で表現力を高める 構造体埋め込みで表現をする まとめ 型を厳格にする意義 SPEEDAプロダクトユニットではエンジニアを募集しています 対象読者 Go言語をこれから始める人 Go言語の型宣言で表現力を高めたい人 オブジェクト指向プログラミングに

今年で4回目となるプロダクトマネージャーカンファレンス2019が開催されます。 日時：11/12(月) - 11/13（火） 会場：ベルサール渋谷ファースト 私は本年も実行委員として開催に関わっております。 今年のテーマは「すべての企業にプロダクトマネジメントを」 プロダクト開発の現場において、プロダクトマネジメントの必要性を疑う人は少ないのではないでしょうか。一方で、プロダクトマネジメントのあり方に正解はなく、共通する部分はある一方でプロダクトマネージャーの職務内容は各社様々です。そうしたなかで「プロダクトマネジメントを導入したいが自社に適用できるのかわからない」「自社のやり方が正しいのかわからない」という声もまだまだ耳にします。 今回のカンファレンスでは、様々な事業フェーズ、様々な業界におけるプロダクト開発の第一人者をお招きしております。前述のような課題感を感じる方は、ぜひ本カンファレ

こんにちは！SPEEDAプロダクト開発チームの成です。 去年の秋ごろからRustを触り始め、徐々にRustの魅力に惚れられました。 最初は日々コンパイラーにボコボコにされていましたが、 The Book *1 を読みながら、Rustを少しずつ理解していくと、段々コンパイラーと仲良くなってきて、Rustを書くのも楽しくなりました。 小さいな作業効率化のツールから、Rest Api Server、色んな処理を並列化するBatchなどをRustで作ってきました。最近プロダクトのマイクロサービスの極一部もRustで作っており、幸せ感満喫です！！ 本日は、HTTPリクエストを並列化するときハマったことをお話したいと思います。 今日の内容はある程度Rustの知識が必要ですが、初めての方は上の The Book の日本語版 から参考できます。 Rustは独特なメモリ管理仕組みを持ち、安全かつRuntim

降り続ける雨を、流れる“涙”の比喩としよう。この街では、誰かがいつも泣いているからだ。映画のキーヴィジュアルに選ばれたのは代々木会館だった。『傷だらけの天使』（1974）でお馴染みの通称“エンジェルビル“*1。つまり、これは現代社会から爪弾きにされた天使たち（≒若者たち）の、その涙の物語なのだ。この映画で多発されるイリーガルな行為の数々は、あらゆることが許されていた『傷だらけの天使』などの犯罪青春ドラマへの憧れなのだろう。「美しさと倫理は両立しない」というのが、『君の名は。』（2016）から続く新海誠が創作において取り組む、隠れたテーマであるように思う。『君の名は。』は、一つの街を消し去り、多くの命を奪った隕石が落下していく様子を、「美しい眺めだった」と思ってしまう少年の話だった。この『天気の子』においても、警官への暴力をカタルシスとして配置し、水に沈む都市をフェティッシュに描いてしまう。

こんにちは！SPEEDA開発チームの岩見です。 この記事では私たちSPEEDA開発チームの中でも特徴的な文化のひとつとなっている、ふりかえりについてご紹介します。 以下のような方々のお役に立つことを願っています。 自分たちのチームでもふりかえりをやってみたい方 ふりかえりはやってるけどなんだかマンネリ化している方 色々なふりかえりの運用、実例が知りたい方 SPEEDA開発チームにおけるふりかえり SPEEDA開発チームのふりかえりの特徴 SPEEDA開発チームにおけるファシリテーターの役割 議論しやすい場の設定 アクティビティの選定を含めた全体の進行 ファシリテーターを置くメリット ファシリテーターが他のチームへの理解を深めることができる ファシリテーターが問題を構造的・俯瞰的にとらえる能力が高まる チームのメンバーが議論に集中することができる さいごに SPEEDA開発チームにおけるふり

前回のエントリーでエンジニアを募集して半年が経ちました。その後どうなったのか？と気にしてくださる方もいて、直接お会いした方にはお話ししていたのですが、募集をしたこのブログの場できちんと結果報告ができていなかったので、今日は結果報告をしたいと思います。 結論から言うと、チームができました。そして第一弾の開発が完了して9/1にサービス開始されました。 2/27にブログに記事を書いて、その後ブログのフォームから連絡いただいたり、知人を通じて連絡をいただいたりして、32人の方とお話しさせていただきました。たまたまですが、16進法的にも区切りの良い数になりました。 中には遠方から連絡いただいた方もいて、Skypeで会話させていただいたり、東京に来る際にお会いさせていただいたりした方もいました。1人は今回私たちの開発チームに参加するために家族で仙台から引っ越してきてくれました。 4月に1人、5月に1人

LAPRAS株式会社では全社的にHolacracy(ホラクラシー)という組織体系を導入しています。一方で開発チームではアジャイル開発のフレームワークであるスクラムを導入して開発を進めています。ホラクラシーの思想は個々人が別々の役割を持って、各人が優先順位を決めて主体的に動いていくものである一方、スクラムはだれもがどんなバックログアイテムでもできるのが理想で、プロダクトオーナーが決めた優先順位に従って開発をしていきます。根本的に違う思想を持っているように見える2つのフレームワークが同居できるのか、運用して1年ぐらい経つのでまとめてみることにしました。 ホラクラシー組織のおさらいホラクラシー組織とはティール組織の一種です。より詳細な話は 代表の島田 がいくつか記事を書いているので、それを参考にしてもらうと良いです。参考になりそうなものをピックアップしてみました。 - ホラクラシー組織への誤解と