読者です 読者をやめる 読者になる 読者になる

bufferingsはwebjarsを覚えた

Java

JJUG CCCのデモアプリ作るときに色々勉強になったのでメモに残そかなと。

mavenで管理できるの安心感あるね。本番で使うかどうかは考えてないけど、個人の開発なら楽だなー。

<dependency>
  <groupId>org.webjars</groupId>
  <artifactId>jquery</artifactId>
  <version>2.2.4</version>
</dependency>
<dependency>
  <groupId>org.webjars</groupId>
  <artifactId>angularjs</artifactId>
  <version>1.5.9</version>
</dependency>
<dependency>
  <groupId>org.webjars</groupId>
  <artifactId>materializecss</artifactId>
  <version>0.97.7</version>
</dependency>

これで、angularjsとmaterializecssが使えるー。この二つについてはまた気が向いたら書く。

jarのなかはこんな風になってて

f:id:bufferings:20161205191814p:plain

こんな風にして使える

f:id:bufferings:20161205191930p:plain

便利だった。

ここから探せる

WebJars - Web Libraries in Jars

#jjug_ccc DDDとMicroservicesについて喋ってきましたー(∩´∀`)∩

DDD Doma kafka Spring

楽しかった!

DDD & Microservices with Spring Cloud

  • 前半がこれまで僕が経験してきたDDD
  • 後半がこれからのために素振りしておきたいこと

f:id:bufferings:20161204110830p:plain

これまで僕が経験してきたDDD

最近、組織について考えるようになってきたのもあって「境界づけられたコンテキスト」が一番大切だなって実感してる。全てを一度に相手にするのではなく、切り取られた世界を作って、その中で適用していく。その切り取られた世界の間の関係性もデザインしていく。そうすることで複雑さを手に負える大きさでコントロールできる。

DDDを知った当初は、エンジニアとしてEntityやValueObjectのところが面白いなーって思ってゴニョゴニョコード書いてたりしてたんだけど、しばらくして「もっと良いコード書くためにはその土台となるチームづくりをしなきゃ!」と思ってスクラムを導入してたんだけど、しばらくして「チームを良くしようと思ったら、組織構造について考えなきゃ!」ってイマココ。ちょうどDDD本の2部→3部→4部って流れかな。

第1部のユビキタス言語については、最近ストンと腑に落ちた。英語のユビキタス言語を英語のまま会話で使って、それがコードに反映されていく感覚。そういうのに興味あるけど、日本語使わなきゃだしなぁ、って人は連絡ください!楽天で一緒に働きましょう!(おい

f:id:bufferings:20161204111306p:plain

  • 左上が、境界づけられたコンテキストの話
  • 真ん中下が、色んなコンテキストを1つのモデルでまかなおうとするとお化けモデルになるよの話
  • 右上が、目の前の最短の道は泥沼に向かうかもしれない、最短の道ではなくて壁を乗り越えて向こう側に行くには、勇気とスキルが必要の話

これからのために素振りしておきたいこと

DDDでドメインモデルを作っていくときに、自分のスキルでできる部分だけを適用してきてるから、もう少しスキルを上げるともっと世界が広がりそうだなと思って、素振り。結果整合性を運んでくれるドメインイベント。ビューの関心事を分離させてくれるCQRS。組織が大きくなってきたときのためのMicroservice。

特にCQRSは、僕が一番身につけておきたいスキルだなぁ。というのも、やっぱりビューに引きずられるんだよね。ビューには効率性やスピードを求めたいから、ドメインモデルが更新されたことに反応してビュー用のモデルを更新したいなぁって思ってる。そうすることでリポジトリがビューに引きずられにくくなる。

f:id:bufferings:20161204131114p:plain

変化していけるアーキテクチャ

とはいえ、DAOバージョンが良くない!っていう気はなく。むしろ、それでサクッとビジネスを立ち上げるのは良いよなって思う。だけど、そのまま拡張していくと大変になると思うので、ビジネスのフェーズに合わせて変化していけるアーキテクチャが大切だよなと。

  • あたるかどうかも分からないような立ち上げ時はRDB中心のDAOモデルでサクッと立ち上げる
  • ビジネスが「これはいけそう!」って分かってきたら、それまでに得た知識を元にドメインモデリングをしていく。
  • ドメインモデルが大きくなってきたら、境界づけられたコンテキスト(Bounded Context: BC)をシステム内に作っていく。
  • チームが複数に分かれるときには、BC単位でシステムを分割していく。その際にマイクロサービスアーキテクチャになっていく。

ということだろうかなと思ってる。

f:id:bufferings:20161204124002p:plain

でも、どうやったら変化していける?

考えてみた。なんとなく、ユーザー認証系は最初から切り離しておきたいなって思うので。こんな形で始められると良さそうかなって思う。

f:id:bufferings:20161204133111p:plain

  • Config Service: 設定の外出し管理用
  • Discovery Service: サービス同士の通信用
  • Edge Service: 裏側にサービスを切り出していくため用
  • Auth Service: 認可サービス
  • User Service: 認可サービスからもらった情報を元にユーザー情報を提供する用

この状態でビジネスを立ち上げて、DAOスタイル→DDDスタイル→DomainEvent→CQRSまでやっておく。その後チームが分かれるときに、BC単位でEdgeサービスの後ろ側に移動していく。というイメージ。デモの5-msa0では、この構成でアプリを作ってみた。

デモアプリ

回転寿司屋さんの席についてるタブレットアプリを思い浮かべて作ったよ!

f:id:bufferings:20161204123301p:plain

注意点
  • Domaを使ってるのでIDEにAPTの設定が必要です。Eclipseならm2eかな。
  • "3-event"以降は、Kafkaの0.10がローカルで動いてなきゃです。
  • Lombokを使ってるのでIDEにLombokの設定が必要です。
機能

f:id:bufferings:20161204123411p:plain

バージョン
  • 1-init/kaiten-sushi-web1→DAOバージョン
  • 2-ddd/kaiten-sushi-web2→DDDスタイル
  • 3-event/kaiten-sushi-web3→ドメインイベントのお試し実装
  • 4-cqrs/kaiten-sushi-web4→イベントを受信してCQRS
  • 5-msa0→MSAに向かうための第一歩(ユーザーログインつき、user/password。シークレットタブとかでログインするほうがよいかもです。)
起動

Spring Bootアプリを起動して以下のURLにアクセスー。

楽しかった!

今回はテンパってて他の人のセッションを全然聞けなかったから、次はお客さんできたいなー!それかもっと余裕持って準備するか。

KafkaStreamsを触ってみた

kafka

こんな感じで書くと

gist.github.com

streams-file-inputのデータを読んで、streams-wordcount-outputに結果を書いていくっぽい。こういう処理を触るのは初めてなんだけど、面白いなー。

こういうデータを食わせたら

all streams lead to kafka
hello kafka streams
join kafka summit

こうなった

all	1
streams	1
lead	1
to	1
kafka	1
hello	1
kafka	2
streams	2
join	1
kafka	3
summit	1

全然Kafka分かんないから色々はまったけど、動いてスッキリした記念にメモ。

ここを読みながらやったよ。

https://kafka.apache.org/documentation#quickstart_kafkastreams

はまったのは。あれ。Dockerで動かしてたからで。ローカルで動かしたらさらっとうごいた。

エンジニア立ち居振舞い: _(:3 」∠ )_

雑記

お題「エンジニア立ち居振舞い」

僕はWebアプリエンジニアなんだけど。

最近は、どんなことに気をつけてるかなぁ・・・。

楽をする。かなぁ。

  • 楽をするために、勉強しといたり
  • 楽をするために、自動化してみたり
  • 楽をするために、テストから考えたり
  • 楽をするために、プロトタイプとかで意見を早めに引き出しといたり
  • 楽をするために、チームを育てておいたり

とかー。

で、楽をすることができて作れた時間で、もっと、楽をするための手を打っとくー。

ゴロゴロ_(:3 」∠ )_

デイリースクラムで「困っていることは?」って言ってもでてこなくなった話

Team

最近は、他のチームのプロセスだったりシステムだったりを改善していくサポートをしたりしてるんだけど。今日はデイリースクラムのお話。

進捗報告じゃないよ?

デイリースクラムって「昨日やったこと」「今日やること」「困っていること」を話すけど。誰かに対する進捗報告じゃなくて、お互いに対する共有だよね。って思う。

3つの質問は手段でしかないよ?

それと、デイリースクラムの3つの質問は手段であって、大切なのは「スプリントゴールに対して今僕らはどの位置にいるか」っていう足下確認をすることかなって思ってる。

ちょっと違うのかも?

んで、僕の見てるチームの特性として、ちょっと他のチームと違うのかなって最近感じてるのは、「全てのタスクをペアで担当している」ということ。

プログラミングだけじゃなくて、設計したり、ドキュメント書いたり、テストを作ったり、実施したりとか、そういう全てのタスクをペアで担当している。

困っていることがなくなった?

最初の頃は、デイリースクラムで「困っていることは?」って言ったら色々出てきてたんだけど、チームがペア開発に慣れてくるとでてこなくなった。

それは、困っていることがなくなったというわけじゃなくて、困ってたら朝まで持ち越さずに、まずはペアに相談するから。だな。だし、ちょっと解決に時間がかかるような困っていることは、ピザサイズなチーム全体にすぐに情報が回る。

だから、朝の時点で共有しないといけない困ってることってのがなくなったの。

それとレトロスペクティブ

あと、スプリント最終日に「振り返り」があるので、今回のプロジェクトには直接関係ないけど、長いスパンでは解決していきたいなぁって感じのはそこで共有されるし。

スプリントとは別で「改善ミーティング」って週に1回集まってどうやって負債を返していくかをあれこれ考え始めたみたいだし。そういうのも良いね。

選ばなかったもの・選んだもの

チームはインタラプトされることを選んだのだ。1日中誰にも邪魔されずにコーディングに集中できる、という環境は選ばなかった。すぐに「相談があるー!」って声をかけられるオープンなチームを選んだ。

今のチームの状況を考えると、それは良い選択だなって思った。

それはまた時間をかけて、色々と変わっていくんだろうなぁと思うけど、今のチームに必要なものをチーム自身が理解して選び続けているので、良いなぁって思う。

こちらもよろしう

bufferings.hatenablog.com

RSGT2017のセッションに応募しましたー

Team

confengine.com

RSGTは僕の中では年に一度のスクラムのお祭りです!みんなの投票を元にセッションが選ばれます。

なので、行きたいなーって思ってる方は特に、ばーって見てみて「これ聞きたいな!」って思うやつに投票してください!

で、僕のは↓これですー。もし聞きたいなって思ってもらえたら投票してくれるとそれだけで僕は幸せです(∩´∀`)∩ワーイ

confengine.com

よろしくー

カラフルで楽しい

雑記

昨日は楽天テックカンファで、大阪サテライトにもたくさんの人が来てくれて幸せだった。控え目に言って最高の1日だった。

その反動で、今日は1日中ぼけーっと過ごした。ぼーっとしながら、今年はスタッフに海外出身のメンバーがたくさんいたなぁとか考えたりして、そういえば、大阪支社もバラエティ豊かになったなぁって思った。

うちの会社は英語化ってのをやってるんだけど、その中の、TOEICの点数とかじゃなくて、色んな文化がそこにあるのが普通の景色になる、ってところで、僕はすごく好き。

日本の考え方だけじゃなくて、中国やカナダ、ナイジェリアとかそういう色んな国から来たみんなが、お互いの違いを尊重し合いながら、1つのことに取り組んでるのが好き。

んで、日本人の中にも年代とか育ってきた背景の違いとかで、考え方違ったりするよなぁとか思ったりして。

だから、自分の色を押し付けたりするんじゃなくて、みんながそれぞれの色で輝くのが良いんね。そんなみんなが集まって開発をしてると、カラフルで楽しい。

さて、明日からはまた頭を切り替えてがんばろうー。