こんなEnum public enum InsideHead { JOY, SADNESS, FEAR } こんなクラスで使うとして。 @Accessors(fluent = true) @Getter @ToString @EqualsAndHashCode public class Bufferings { private InsideHead insideHead = InsideHead.JOY; public void eatChocolate() { this.setInsideHead(InsideHead.JOY); } public void workOvertime() { this.setInsideHead(InsideHead.SADNESS); } public void seeSourceCodeWithNoTest() { this.setInsideHea

今朝と昨日の朝にテストについてのブログ書いたけど bufferings.hatenablog.com まとめるとこんな感じかな。 個人的にはUsecaseTestが気に入ってる。

昨日はFeatureSpec/FeatureSpecTestの話を書いたので今日はその続き。 テスト呑み。SpecTest。思ってたんと違う！をふせぎたい。 - Mitsuyuki.Shiiba ざっくり書いてしまおう。 ドキュメント周り ドキュメントは、最初から完成してることは全然なくて、作りながら書いて、書いては作って、最終的に、その機能をリリースするときに最後の仕上げをする感じ。 仕様系 名前 内容 FeatureSpec プロダクトオーナーチームが作る。実現させたい機能の概要が書いてある。 UISpec WebUIのドキュメント。FeatureSpecに入れると大きくなっちゃうので、切り出してるだけ。プロダクトオーナーチームが理解できる。 DevSpec 開発チーム用の詳細ドキュメント。例外時の動作とかそういうのも含めて。 OpsSpec 開発チームがこの機能を運用するときのための

テスト呑み 昨日はこざけさんとぽざさんとテストの話をしようと集まってデータベースの話をしてました。(あれ？) 二人のおかげで色々頭の中が整理できてきたので。今、自分がやってることを出力しておこうかなと。 どこから話をしたらいいのかな。開発の流れに沿ってみようかな。じゃあまずはSpecから。 Spec 最初にプロダクトオーナーチームが機能概要のドキュメントをConfluenceに書きます。僕のチームではこれをSpecと呼んだり、FeatureSpecと呼んだりします。 もともとビジネス側の人が「こんなことができるといいな」って、ざっくりとした想いを語ってくれていて。それをプロダクトオーナーチームが、FeatureSpecという開発可能な単位に落としこみます。 プロダクトオーナーチームは、ビジネスオーナーとプロデューサーとディレクターとエンジニアで組んでてプロデューサーが取りまとめてる感じ。

明後日21日(土)は楽天テクノロジーカンファレンスです！ おぉ。もうすぐ12時まわるから、もう明日かな！ てことでおまちしてまーす！！ ノベルティグッズのカレイドスコープ。かわいい。 発表がんばるー(๑•̀ㅂ•́)و✧ Go Register!! お申し込みまだの方はこちらからよろしくお願いしますー！ Rakuten Technology Conference 2015 Tickets 大阪サテライト詳細はこちらbufferings.hatenablog.com

Rakuten Technology Conference 2015 Osaka Satellite Rakuten Technology Conference 2015 will be held at Futako Tamagawa Rakuten Crimson House on Nov. 21st, inviting a variety of top-class speakers. There are so many great sessions. And we will hold Osaka Satellite this year, too. We're so excited to see you at Rakuten Osaka Cafeteria. Please register and enjoy the satellite together eating snacks. O

Rakuten Technology Conference 2015 Osaka Satellite Rakuten Technology Conference 2015 will be held at Futako Tamagawa Rakuten Crimson House on Nov. 21st, inviting a variety of top-class speakers. There are so many great sessions. And we will hold Osaka Satellite this year, too. We're so excited to see you at Rakuten Osaka Cafeteria. Please register and enjoy the satellite together eating snacks. O

Rakuten Technology Conference 2015 Osaka Satellite Rakuten Technology Conference 2015 will be held at Futako Tamagawa Rakuten Crimson House on Nov. 21st, inviting a variety of top-class speakers. There are so many great sessions. And we will hold Osaka Satellite this year, too. We're so excited to see you at Rakuten Osaka Cafeteria. Please register and enjoy the satellite together eating snacks. O

Rakuten Technology Conference 2015 will be held at Futako Tamagawa Rakuten Crimson House on Nov. 21st, inviting a variety of top-class speakers. There are so many great sessions. And we will hold Osaka Satellite this year, too. We're so excited to see you at Rakuten Osaka Cafeteria. Please register and enjoy the satellite together eating snacks. Of course, let's enjoy beer bash as well! Official W

ということで、 楽天テックカンファ2015の大阪サテライトやりまーす 数日前にも書いたけど、今年も楽天テクノロジーカンファレンス2015の大阪サテライトやりますん。(サテライトというのは、東京でやっているセッションの放送を大阪でみんなで集まって観るというスタイルです！) 11/21(土)に大阪支社( Map )でやりますー。 スタッフが一番楽しみにしてるカンファレンス というのを、今年の大阪会場のプチテーマにしてみました。 「そんなの、あたりまえだろ！？」という声が聞こえてきそうですが。ま、そういうとこからいこーよ、というのが大阪支社っぽいす。 スタッフのみんなで色々話をしたんですけどね、やっぱりスタッフをやる僕達が、緊張してるよりも一番楽しみにしてその日を迎えるイベントがいいよねって。んで、僕らがお客さんとして来て、「あぁ来て良かったな、面白かったなー」と思えるような場を作ろうよねって。

できる人、足せるけど引けない人、になってしまうと、気づいたら年老いてるんじゃないかなって印象ある。 気を抜くとそっちに流れていきそうになってる自分がいるので、気をつけようと思います。 できる人 自分が知ってるやり方でできる場合に、新しいやり方を知ろうとしない人。新しく高速道路ができて、そっちを使えば1時間で行けるのに、過去に通ったことがある山道(3時間かかる)以外使おうとしない人。「え？だって、こっちで行けるでしょ？なんでもかんでも新しければいいってワケじゃないよ！」って。 足せるけど引けない人 今までやってきたやり方、たとえばチェックリストとかを、足すことはできるんだけど、引くことができない人。日に日にチェック項目は増えていくんだけど、もう既に要らなくなったチェックや、新しく足されたチェック項目によって過去の10個分のチェックはカバーできてたりするんだけど。消すの怖い。 失敗しない でも

今年も楽天テクノロジーカンファレンスの大阪サテライトをやりますー！ 11/21(土) ですー。連休の初日に遊びに来てね。 tech.rakuten.co.jp 今年は楽天クリムゾンハウスのお披露目って感じなのですが。 いや、それって大阪あんまり関係ないじゃん！って思うかもだけど。 そう。あんまり関係ナイです！はい！( ﾟ∀ﾟ)･∵. ｸﾞﾊｯ!! なのだけど、それはそれとして。 大阪ではお菓子食べたりジュースとか飲んだりしながら 初めての人も参加したことがある人も、学生も社会人もみんなで 英語のセッションをもぐもぐしてまったり楽しみましょう。 参加申し込み は、こちらですー。www.eventbrite.com REGISTERボタンを押したら、大阪サテライトってでてきますん。 大阪のタイムテーブル 僕が参加者なら、こんな感じがいいなーって思ってるんですけどね。 来週あたりには最終決定する

9月 の頭にインターン生がやってきました。そして月末に、タイトルの言葉を残して大学に帰って行きました。その後ろ姿を見送りながら、おれたちって、プロなのか・・・(照)と思いました。そりゃそうか。 かなり優秀で。アドバイスされたことは次の日には吸収してたし。エンジニアとして「分からなくて悔しいから自分で調べたい」という気持ちと「チームの進捗のことを考えると今はメンバーに質問をした方が良い」という判断のバランス感覚が素晴らしく良かったし。 一見温厚そうな中にもギラギラとしたものがあって、こちらも沢山の刺激を受けたし。1ヶ月間ありがとう。楽しかった。 違う感じだったなー。 7月には、新卒の方のOJTをやったのだけど。それとはまた違う感じだったなー。bufferings.hatenablog.com OJTのときのゴールは「今後、会社の中で仕事をしていくうえで必要なスキルを伝える」って感じでやったの

モヤモヤ チームのメンバーから「ホワイトボードが使いづらいー」というモヤモヤがあがってきました。今まで、ホワイトボードに付箋を貼ってスプリントボードにしてたんです。でも、ちょっと前に席替えがあって、ホワイトボードが使いづらい場所になっちゃったんですね。 モヤモヤ会 余談ですが。楽天の大阪の開発部ではモヤモヤ会というものがたまにあって、そこでは全員が集まって今モヤモヤしてることを共有するんです。そこで出たモヤモヤは、マネージャーやリーダーが出来る限り解決していきます。詳しくはAgile Japanでうちのマネージャと一緒に話したこのスライドで。後半部分ね。 組織とスクラムチームのあいだ from Mitsuyuki Shiiba スチレンボード？ んー。どうしようかなー。と考えてみて思い出したのが、川口さん( @kawaguti )と佐藤さん( @sato_ryu )の「スチレンボードいい

ユーザーストーリーマッピングを読んだ。面白かった。 0章から5章までと、12章が好きです。books.rakuten.co.jp しっくりこない 僕のチームでは、スクラムを自分たちに合うようにアレンジして開発してます。 開発自体は、まぁ、そんなにもう悩んでなくて。 でも、その前の部分がいまいちしっくりこないなぁって思ってたん。 つまり、バックログを作るまでの部分のことね。 回想 勘でやってた期 最初の頃は、バックログを作る部分をプロデューサーとUI/UXディレクターと僕でやってました。 んで、エンジニアリーダーとしての僕は、勘だけで適当にやってました。それなりにうまくいってたんじゃないかな。 仕組みにする期 でも、まぁ、その仕事をしてるのが僕だけってのも、あんまり良くないし。つーか、僕もコード書きたいし。 リーダーを交代制にしようぜー。って言って、別のメンバーが僕と交代でエンジニアリーダー

(追記 20150830) 読んでるときにノートにメモしたやつをマインドマップに起こしておきました。後の自分のために。 DDD20150830.pdf - Google ドライブ ////// Domain Driven Design を読み終わりました。疲れた。books.rakuten.co.jp 数年かけて 数年前に買って、ちょっとは読んでたんだけど。そのときは、EntityやValueObject、Repositoryなどが印象に残ってて。それは今考えるとDDDの中のMODEL-DRIVEN DESIGNの構成要素であって、本質ではなかったんだなぁ。と気づきました。 それにしても、ユビキタス言語さん。 これまでずっと、喋るときは日本語で、コード書くときは英語なので、知らず知らずのうちに、そういうもんだと思ってたんだけど。試しに英語で色々やってみたら、喋ってる言葉がそのままクラス名や

OJT今年入社の新卒の方が大阪支社に配属になって｢いきなりどっかのチームにどっぷり入るより、色んなチーム見て回る方が面白い？｣ってことで、いくつかのチームを渡り歩くことになりました。 んで、僕のチームが2番目で、7月から1ヶ月間くらい一緒に仕事してました。 ｢このチームで学んだのはMind｣各チームを渡り歩く中で、毎回｢成果発表会｣って感じで、その1ヶ月で何を学んだかをみんなの前でプレゼンするんですけど、そこで ｢今回、このチームで学んだのはMindでした。技術も学んだのですが、それよりも、Mindの重要さと難しさを学びました｣ と言ってくれたので良かった٩(ˊᗜˋ*)و 何をやったかプロジェクトに参加失敗しても大丈夫な小さ目のタスクを渡してそれで学んでもらう、というのは1番目のチームでやってたので。 今回はチームが実際にやってるプロジェクトにメンバーとして参加してもらうことにしました。失

今日は勉強する気が起きなかったので、お絵かきしてた。 今、ちらちらと「ユーザーストーリーマッピング」を読んでるんだけど books.rakuten.co.jp 今までなんとなく感覚でやってたことが、まとまってて読んでて楽しい。 で、↑の絵を描いたんだけど。これが今の僕のチームの開発スタイルです。 今もずっと改善し続けてるから、もっと良くなっていきそう。 左下の人の絵 ビジネスチーム、開発チーム、UI/UXチームがあるよってことで。 そのそれぞれの代表が意見を出しあうProduct Owner Teamが真ん中にあります。 それを取りまとめるのが、Product Ownerです。 左上のスマイリー POTがメインで話し合うことです。 1. うちの会社が困ってること 2. それは誰が、どういうことで困ってるからなのか？ 3. じゃあ、うちの会社がいい感じになるってどういう状況？ 4. そのため

IDDDを読んで、それなりに書いてあることは分かり始めたかな。と思ってたけど。 いざサンプルプロジェクトを読んでみたら、全然そんなことなかった。(ﾉД`)ｼｸｼｸ github.com いつものように、自分メモ。 プロジェクトの構成 全部で3プロジェクトと1ライブラリがある。 iddd_agilepm データストアとしてKVS(LevelDB)を使用。 DIコンテナは使ってない。 iddd_collaboration Event Sourcing と CQRS。ORM使わずにやってみた。 例をシンプルにするために、Event Sourcedな書き込みモデルと、CQRSの読み込みモデルを1スレッドで実行してる。イベントジャーナルとしてLevelDBを、リードモデル用にMySQLを使ってるのでほんのちょっとだけ一貫性がない状態が発生する可能性がある。別々のデータストアを使って、でも、できるだけ

DomainEvent ドメインエキスパートが「…した『とき』に、こうなる。」とか。 何かの状態変更をトリガーにして、別の処理をしたい場合にドメインイベントを使う。 イベントオブジェクトがイベントの情報を運んでくれる。 source data & processing data Domain Event ドメインイベントはイミュータブルな「source data」とミュータブルな「processing data」で構成される。 source dataってのは「イベントが発生した」という部分の情報で、これは一旦作成されたら変更されることはないよね。 processing dataは「システムがこのイベントをどうしたか」って情報ね。分けてもいいかもね。 Aggregate & DomainEvent DDDでは、1つのユースケース(トランザクション)で触ってイイ集約は1個だけ。なんだよね。 だ