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

VSCode

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にインストールしてみた

RabbitMQ

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 がどうにもこうにも帰ってこないとき

linux shell

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

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

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

-U オプションを使う

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

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

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

find する

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

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

参考

qiita.com

spring-security-testを使おう

SpringBoot 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

Agile Scrum MobProgramming 勉強会

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

spring-bootアプリをherokuにデプロイする #heroku #SpringBoot

Heroku SpringBoot

前提

  • herokuのアカウントは作成済
  • SpringBoot単独で起動可能にしている（外部DB等を必要としない）
  • git管理されている

heroku CLIのインストール

Macだとhomebrew。

brew install heroku

Procfileの作成

プロジェクト直下に 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上のログがトレースできる。

参考

モブプロディスカッションに参加してきた！ #mobProgramming #MobDiscussion

MobProgramming 勉強会 ポエム

モブプロディスカッションに参加してきました！

www.eventbrite.com

内容としては及部さんがDevLOVEの講演の再演をした後、会場の質問を中心にパネラーがディスカッションするというもの。

自分のチームでモブプログラミング、モブワークをし始めてだいぶこなれてきた感が出てきたけど、色々刺激を貰って考えることも多かった。

何より会場の熱量が高くて、それを感じられたのが大きかったかも。

思ったこと

モブプロはもちろん銀の弾丸じゃない。

パネラーの人たちも繰り返し言ってたし、それはきっとみんな重々承知している。

いいチームだからいいモブができる。

モブをやったからって必ずしもいいチームになるわけじゃない。

まず、いいチームを作ろう。

感じたこと

でもそれを飛び越えて伝わってくる、モブプログラミングの楽しさや素晴らしさ。

自分にも実感としてある。

本当に「一緒に作ってる」っていう感覚になる。

問題に一丸となって立ち向かうあの感じ。

突破口を切り開いて、全員で一気に加速するあの感じ。

迷っている時に、背中を押してくれるあの感じ。

困っている時に助けてくれるあの感じ。

モブプロをしたから最高になるわけじゃない。

でもきっと僕らがモブプロをしたら最高だ。

まとめ

モブプロしようぜ！

f:id:su-kun1899:20170711233439p:plain