brew install rabbitmq
/usr/local/sbin/rabbitmq-server
detachedを付けるとバックグラウンド実行らしいが、何か警告が出る。
$ /usr/local/sbin/rabbitmq-server -detached Warning: PID file not written; -detached was passed.
起動はしているようだ。
$ /usr/local/sbin/rabbitmqctl status
$ /usr/local/sbin/rabbitmqctl stop
ここで力尽きた。
以前activeMQを使っていた時の「めんどくせぇなぁ」という記憶が強いために、メッセージキューイングのツールで便利になる感覚がイメージできない。
それゆえモチベーションも上がらない。。
Spring Securityを使ってるSpring BootのWebアプリでテストを書く時に、認証自体をテストしたいのでなければ spring-security-test で認証情報を簡単にMockできる。
spring-security-test を dependency に追加する
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-test</artifactId> <scope>test</scope> </dependency>
@WithMockUser をテストメソッドに付与することで、認証情報をモックできる。
ユーザ名やROLEも簡単にMockできそうである。
@RunWith(SpringRunner.class) @SpringBootTest( webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT, classes = SpringbootWebSampleApplication.class) @AutoConfigureMockMvc public class CustomerControllerIntegrationTest { @Autowired private MockMvc mvc; @Test @WithMockUser public void whenGetCustomers_thenStatus200() throws Exception { mvc.perform(get("/customers")) .andExpect(status().isOk()); } }
なんかすごい見当違いの方向でがんばってたんだけど、Spring Security使ってるなら、spring-security-test に便利なものいろいろあるからそれ使えばいいってだけの話だった気がする。
「Global Scrum Gathering参加報告会＆Hunter Industries社の見学報告会」に参加してきた。
内容は下記の３つ。
特にまとめもせず、印象に残ったことを残しておく。
ジェフ・サザーランドのスクラムのスケールの話から感じたこと。
スケールするに従いバックログの抽象度はどんどん上がっていく。
ストーリーからエピックへ、経営方針的なものになったり。
多分分解されながら、それぞれのチームにタスクとして具象化されていくんだろう。
そこの具象化とつなぎ込みも難しいんだろうけど、
ってすることが大切だろうな、なんて思った。
どこかで、一度に2つのことをやろうとしてしまいそうなので。
ワークショップに参加された方が全く英語ができなかったらしく、チームとコミュニケーションが取れなかったらしい。
んで、コミュニケーションとれないと単純作業者になってしまうっていう話があったんだけど。
これにはもう一つ学びがあるなぁ、と思って。
適切なコミュニケーションが取られていないと、その人が本来持っている力が適切に発揮されないんじゃないかなとも思った。
逆にいうと、コミュニケーションの問題を解決してあげれば、すごく活躍できる可能性があると。
Growth、あるいはShrinkのためにチームを再構築するという話。
チームが固定化されると、マンネリにもなるし、チーム外に対してクローズになっていってしまうきらいはあると思う。
なので能動的にチーム（メンバー）の流動性を高めていくっていうのは非常に賛成。
とはいえリチーミング、トップダウンの組織変更だったり、メンバーの離任だったりで、致し方なくやらざるをえないことが多いよね。。
合意形成を5段階でやるというプラクティスが紹介された。
5段階にすることで、合意形成しやすくするというもの。
これのポイントは、２から既に「やってみる」であること。
まず実際にやってみることを重要視しているところが非常によいと思った。
機会があれば積極的に取り入れていきたい。
今のモブプログラミングの源流といえるHunter Industries社の見学報告。
ご本人たちもうまく言語化ができていないとのことだったけど、伝わってくるものがあった。
うまくまとめられないけど、この話が聞けただけで、足を運んだ甲斐があったと思ってる。
モブは仕事に取り組むいいプラクティスだくらいに思っていたけど、そうじゃなかった。
ハンター社では働き方になっていた。
仕事をメンバーやチームにアサインしていくのではなく。
“そこ"にもう物理的な場所として、モブ（仕事）があって、そこに皆で立ち向かう的な。。
あー、うまく言葉に出来ない。
モブワークだと人事評価どうしているの？というのは当然の疑問なのだけれど、紹介されていたのでまとめておく。
とても興味深かった。
こういう目標設定の仕方いいなぁ。
メンター選びは難しそうだけど。
2016年のハンター社のモブプロ動画。
オフィスの雰囲気とてもいい。
ディスプレイでかい。
こんなところで仕事したい。
ハンター社の話はテンション上がった。
ので勢いのままブログを書いた。
Global Scrum Gathering参加報告会＆Hunter Industries社の見学報告会参加メモ · GitHub
Macだとhomebrew。
brew install heroku
プロジェクト直下に Procfile という名前でファイルを作成する。
web: java -jar target/hoge-app.jar --server.port=${PORT}
herokuでは起動ポートが動的に変わるようなので、SpringBoot側のポート番号もherokuの環境変数で書き換えている。
作成したらコミットしておく。
$ heroku create $ git push heroku master
勝手にビルドが始まり、デプロイしてくれる。便利！
なお heroku create は初回だけでOK。
以降は修正をコミットしたら heroku push だけすればいい。
pushした最後にURLがログに出るけど、 heroku open すると、ブラウザを起動してくれる。
heroku logs --tail しておくと、heroku上のログがトレースできる。
モブプロディスカッションに参加してきました！
内容としては及部さんがDevLOVEの講演の再演をした後、会場の質問を中心にパネラーがディスカッションするというもの。
自分のチームでモブプログラミング、モブワークをし始めてだいぶこなれてきた感が出てきたけど、色々刺激を貰って考えることも多かった。
何より会場の熱量が高くて、それを感じられたのが大きかったかも。
モブプロはもちろん銀の弾丸じゃない。
パネラーの人たちも繰り返し言ってたし、それはきっとみんな重々承知している。
いいチームだからいいモブができる。
モブをやったからって必ずしもいいチームになるわけじゃない。
まず、いいチームを作ろう。
でもそれを飛び越えて伝わってくる、モブプログラミングの楽しさや素晴らしさ。
自分にも実感としてある。
本当に「一緒に作ってる」っていう感覚になる。
問題に一丸となって立ち向かうあの感じ。
突破口を切り開いて、全員で一気に加速するあの感じ。
迷っている時に、背中を押してくれるあの感じ。
困っている時に助けてくれるあの感じ。
モブプロをしたから最高になるわけじゃない。
でもきっと僕らがモブプロをしたら最高だ。
モブプロしようぜ！
はぁー、楽しかった。
— すーくん (@su_kun_1899) 2017年7月11日
ほんとモブプロ楽しくて最高なのでみんなでやりましょうという気持ち！ #MobDiscussion
gitignoreで、明示的に指定したファイルしか扱えないようにホワイトリストを作成する方法について（意外と手間取ったので）残しておく。
ここではgit管理において、明示的にgitignoreに指定したファイル以外バージョン管理としないという意味で使っています。
. ├── abc.txt ├── hoge │ ├── aaa.txt │ ├── fuga │ │ ├── bbb.txt │ │ ├── piyo │ │ │ ├── ccc.txt │ │ │ └── zzz.txt │ │ └── yyy.txt │ └── xxx.txt └── xyz.txt
こんな感じにするとうまく管理できる。
# すべてをignore * # すべてのディレクトリをホワイトリストに追加する !*/ # ホワイトリストに入れたいファイルを戸別に許可する !.gitignore !xyz.txt !hoge/aaa.txt !hoge/fuga/yyy.txt !hoge/fuga/piyo/ccc.txt
この例の場合、(書くまでもなさそうだけど)下記のファイルがバージョン管理対象となる。
ポイントはすべてのディレクトリをホワイトリストに追加していること。
なぜわざわざこんなことをしているかというと、どうもgitignoreは上位ディレクトリがignoreされていると、下階層を再帰的には見てくれないらしい。
上述の例だと、ディレクトリをホワイトリストに入れないとaaa.txt、ccc.txt、yyy.txtはignoreされてしまう。
逆に言うと特定のディレクトリ配下を除外したい場合はそのまま指定すればよい（ hoge/fuga/ とやればfuga配下は丸っとignoreされる ）
ディレクトリがホワイトリストではなくなってしまうけど、gitは空ディレクトリは無視するし、.gitkeepも明示的に指定する必要があるので、実質問題ないと思う。
