社内でモブプログラミング交流会を開催しました #MobProgramming

モブプロをもっとみんなで楽しみたい！の思いから社内でモブプロでの交流会開催しました。

業務後に希望者で集まって、軽くお酒とお菓子も用意して、ゆるーく楽しめる会を目指しました。

開催にあたって、以前参加させていただいた Mob Programming Val を参考にさせて頂きました！

当日の流れ

おおまかな流れとしては下記のような感じでした。

※全体でおよそ２時間くらい

• 業務終了後、買い出しにいく
• モブプロするプログラミング言語を決める
• モブプロするテーマを決める
• Hello Worldしてみる
• テストできるようにする
• モブプロする
• ふりかえり
• 解散

言語えらび

今回は開発環境を用意するのに手間のかからない repl.it を前提にしていたので、対応しているものの中からみんなで相談して決めました。

repl.it - online REPL, Compiler & IDE

せっかくならやったことない言語にしよう！ということで今回は Rust になりました。

僕は名前しか聞いたことありませんでした笑

テーマえらび

テーマはTDDのお題なんかだとやりやすい、という話を聞いていたので、下記サイトの中から皆で相談して決めました。

d.hatena.ne.jp

テーマが分かりやすく、進めやすそうだね、ということで今回は 野球の打率計算 になりました。

モブプロ！

いよいよ実際にモブプロ開始です。

マシンは１台で、Mobsterを使って１人７分で回しました。

github.com

はじめての言語なのでみんな当然苦戦しますが、ワイワイガヤガヤで作りあげていくのは本当に楽しいです。

限られた時間なので妥協したところもたくさんありますが、最終的に

• 打率を計算する処理
• 打率を表示する処理

の２つを実装できました（もちろんテストもあります！）。

最後に受け入れテストとして、

• イチローの成績をググってパラメータとして渡した結果、同じ打率を表示することに成功！

拍手で終えたのでした。

想像以上に盛況！

ふりかえり

最後にみんなで軽くふりかえりをしました。

慣れ親しんでいる、ということもあるのでKPTでやりました。

• K: よかったこと
• P: もやもやしたとこ
• T: 次回やるとしたらこうしたい

Rustのここがいいかも、いやここ微妙じゃない？みたいなエンジニアっぽい意見もありつつ、

• みんなでやると心強い
• ひとりでやるよりハードル低い
• 他の人のコーディングを見ると気付き（学び）がある

のように、モブプロの良さを体感してくれた意見が出たのはとてもうれしかったです。

個人的にはSlackのというチャンネルを用意してあったので、そこで実況できたのは結構良かったかなと思っています。

調べたURLとかコードの例とかを貼っつけられたりするのに便利でした。

ただ「ちょっと慌ただしい」みたいな意見もあったので、立ち止まって一度足並みを揃える時間や、掘り下げる時間を設けても良かったのかな、というのが反省点です。

Pが少ない！

Try!!

みんなからポジティブな反応が出ていて、とりあえずもう一回同じような場を設けようという流れになっています。

ふりかえりでも

• 慣れた言語だとどうなるかやってみたい
• モデリングなど設計が必要な大きさの課題だとどうか
• 開発環境をもっと整えてやりたい

などの意見が出て、もう皆モブプロに興味津々 で完全に僕の思う壺 です。

まとめ

ちょっと気軽に体験できる場として、モブプロの場を設けるのはとても良いと思うのでおすすめです。

単純に普段直接的な接点がない人が集まって交流する場としてもよいのではないでしょうか。

モブプロ楽しいですよモブプロ！

GO言語でHello Worldしてみた #golang

Macで Hello golang してみた。

インストール

brew install go

bash_profileの編集

export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin

追記して source する。

ワークスペースの作成

mkdir $HOME/go
mkdir -p $GOPATH/src/github.com/su-kun1899

プロジェクトの作成

mkdir -p $GOPATH/src/github.com/hello-golang

実装

$GOPATH/src/github.com/su-kun1899/hello-golang に hello.go という名前でファイルを作成する。

package main

import "fmt"

func main() {
  fmt.Printf("Hello, world.\n")
}

実行

$ cd $GOPATH/src/github.com/su-kun1899/hello-golang
$ go install
$ hello-golang

Hello, world. が表示されれば成功！

GitHub

github.com

Visual Studio Codeの設定をいじってみた

Qiitaの記事を参考に修正してみた。

qiita.com

一部上記の記事では古くなっている設定項目もあったが、設定画面で丁寧に説明が書いてあるので特に困らなかった。

最終的に出来上がったのがこちら。

{
    // フォントファミリー(お好みで)
    "editor.fontFamily": "'Source Han Code JP', Menlo, Monaco, 'Courier New', monospace",
    // フォントサイズ(お好みで)
    "editor.fontSize": 12,
    // (お好みで)スペース2個インデントの言語を触ることが多いので
    "editor.tabSize": 2,
    // ウインドウ幅で折り返す
    "editor.wordWrap": "on",
    // 自動フォーマットする
    "editor.formatOnType": true,
    // ファイルを自動保存
    "files.autoSave": "afterDelay",
    "workbench.colorTheme": "Quiet Light",
    // 制御文字を表示する
    "editor.renderControlCharacters": true,
    // ホワイトスペースを表示する。ただし単語間の単一スペースは表示しない
    "editor.renderWhitespace": "boundary",
    // インデントガイド(インデントに沿って縦線を表示)
    "editor.renderIndentGuides": true,
    // 現在行をガターを含めてハイライトするので視認性が上がる
    "editor.renderLineHighlight": "all",
    // 差分を横に並べて表示ではなく行内に表示する
    "diffEditor.renderSideBySide": false,
    // 再起動時に開いていたウインドウをすべて復元する
    "window.restoreWindows": "folders",
    // タイトルバーにファイルのフルパスを表示する
    "window.title": "${activeEditorLong}",
    // ファイルの末尾は改行で終わらせる
    "files.insertFinalNewline": true,
    // 拡張機能を自動更新
    "extensions.autoUpdate": true
}

gistに置いておく。

VsCode.md · GitHub

RabbitMQをMacにインストールしてみた

Homebrewでインストール

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

管理画面にアクセス

http://localhost:15672/

• user:guest
• password:guest

まとめ

ここで力尽きた。

以前activeMQを使っていた時の「めんどくせぇなぁ」という記憶が強いために、メッセージキューイングのツールで便利になる感覚がイメージできない。

それゆえモチベーションも上がらない。。

参考

qiita.com

ls がどうにもこうにも帰ってこないとき

サーバで、このディレクトリ何だろ？と思って ls を打ってみたけど、待てど暮せど帰ってこない。

どうやら大量にファイルがあるみたい。

それでも見たい、そんなとき。

-U オプションを使う

lsはソートをしてろい、ソートに時間がかかっているらしい。

-U を使うとソートをしないので早くなるみたい。

（ -f でもいいみたい。）

find する

ソートを切ったくらいじゃ変わらない時。

find -type f すると中身をちら見するくらいはできます。（順々に出力されるので）

参考

qiita.com

spring-security-testを使おう

Spring Securityを使ってるSpring BootのWebアプリでテストを書く時に、認証自体をテストしたいのでなければ spring-security-test で認証情報を簡単にMockできる。

pom.xml

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

@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 に便利なものいろいろあるからそれ使えばいいってだけの話だった気がする。

参考

ishiis.net

「Global Scrum Gathering参加報告会＆Hunter Industries社の見学報告会」に参加してきた #ScrumTokyo

www.eventbrite.com

「Global Scrum Gathering参加報告会＆Hunter Industries社の見学報告会」に参加してきた。

内容は下記の３つ。

• Global SCRUM GATHERING San Diego 2017への参加報告
• Hunter Industries社への訪問リポート
• Global SCRUM GATHERING® Singapore 2017への参加報告

特にまとめもせず、印象に残ったことを残しておく。

スクラムのスケール

ジェフ・サザーランドのスクラムのスケールの話から感じたこと。

スケールするに従いバックログの抽象度はどんどん上がっていく。

ストーリーからエピックへ、経営方針的なものになったり。

多分分解されながら、それぞれのチームにタスクとして具象化されていくんだろう。

そこの具象化とつなぎ込みも難しいんだろうけど、

• バックログが必ず優先順位どおりに並んでいて誰もが見えるところにある
• 抽象度が違うどんなことでも、最終的に結びつくのはたった一つのバックログアイテムである

ってすることが大切だろうな、なんて思った。

どこかで、一度に2つのことをやろうとしてしまいそうなので。

コミュニケーションの価値

ワークショップに参加された方が全く英語ができなかったらしく、チームとコミュニケーションが取れなかったらしい。

んで、コミュニケーションとれないと単純作業者になってしまうっていう話があったんだけど。

これにはもう一つ学びがあるなぁ、と思って。

適切なコミュニケーションが取られていないと、その人が本来持っている力が適切に発揮されないんじゃないかなとも思った。

逆にいうと、コミュニケーションの問題を解決してあげれば、すごく活躍できる可能性があると。

リチーミング

Growth、あるいはShrinkのためにチームを再構築するという話。

チームが固定化されると、マンネリにもなるし、チーム外に対してクローズになっていってしまうきらいはあると思う。

なので能動的にチーム（メンバー）の流動性を高めていくっていうのは非常に賛成。

とはいえリチーミング、トップダウンの組織変更だったり、メンバーの離任だったりで、致し方なくやらざるをえないことが多いよね。。

5段階の合意形成

合意形成を5段階でやるというプラクティスが紹介された。

5段階にすることで、合意形成しやすくするというもの。

• 5: 完全に同意
• 4: よいと思う
• 3: やってみるか
• 2: 引っかかるけど、やってみるか。。
• 1: 賛同できないな
• 0: 絶対にダメだ

これのポイントは、２から既に「やってみる」であること。

まず実際にやってみることを重要視しているところが非常によいと思った。

機会があれば積極的に取り入れていきたい。

モブはそこにある

今のモブプログラミングの源流といえるHunter Industries社の見学報告。

ご本人たちもうまく言語化ができていないとのことだったけど、伝わってくるものがあった。

うまくまとめられないけど、この話が聞けただけで、足を運んだ甲斐があったと思ってる。

モブは仕事に取り組むいいプラクティスだくらいに思っていたけど、そうじゃなかった。

ハンター社では働き方になっていた。

仕事をメンバーやチームにアサインしていくのではなく。

“そこ"にもう物理的な場所として、モブ（仕事）があって、そこに皆で立ち向かう的な。。

あー、うまく言葉に出来ない。

モブの人事評価

モブワークだと人事評価どうしているの？というのは当然の疑問なのだけれど、紹介されていたのでまとめておく。

とても興味深かった。

• 半年に一回評価をする
  • その半年間のメンターを被評価者が自分で指名する
  • メンターは誰でもいい
  • メンターとのコミュニケーションは上司には共有しない
  • 半年間のイベント(出来事)を振り返る
  • 感情をふりかえる
    • よかったこと
    • いやだったこと
  • Smartなゴールを作る
    • Smartなゴールだけ上司に共有する
    • 上司はゴールに対してのみ評価する
• SMARTなゴール
  • Specific（具体的に）
  • Measurable（測定可能な）
  • Achievable（達成可能な）
  • Related（経営目標に関連した）
  • Time-bound（時間制約がある）

こういう目標設定の仕方いいなぁ。

メンター選びは難しそうだけど。

A day of Mob Programming 2016

2016年のハンター社のモブプロ動画。

オフィスの雰囲気とてもいい。

ディスプレイでかい。

こんなところで仕事したい。

www.youtube.com

まとめ

ハンター社の話はテンション上がった。

ので勢いのままブログを書いた。

メモ

Global Scrum Gathering参加報告会＆Hunter Industries社の見学報告会参加メモ · GitHub