そこに仁義はあるのか(仮)

略してそこ仁!

GETのクエリパラメータの値をオブジェクト変換してvalidationをかけるときのやりかた(spring-boot)

メモだよ

✏️ パラメータ受け取り

RequestParamでクエリパラメータを取れる。他の取り方もある!
Spring Boot 使い方メモ - Qiita

@GetMapping(value = "/")
@ResponseBody
String getType(@RequestParam Map<String, String> queryParameters) {
    ....
}

✏️ Objectに変換する

ObjectMapperをつかってmapからObjectにする
クエリパラメータがsnake caseでくる場合は、ObjectMapperに設定を追加する

XXForm form = new ObjectMapper().convertValue(queryParameters, XXXForm.class);

XXForm form = new ObjectMapper().setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE).convertValue(queryParameters, XXXForm.class);

✏️ validationを実行する

Formにバリデーションを定義して、Validation実行。
精査に問題があったときは、violationsにエラー情報が設定される。

public class XXXForm {
    @NotNull
    public String type;
}
ValidatorFactory validatorFactory = Validation.buildDefaultValidatorFactory();
Validator validator = validatorFactory.getValidator();
Set<ConstraintViolation<Object>> violations = validator.validate(form);
if (!violations.isEmpty()) {
    // バリデーションエラーのときの処理
}

✏️ 全体はこんな感じ

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.PropertyNamingStrategy;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;

import javax.validation.*;
import java.util.Map;
import java.util.Set;

@Controller
public class AuthenticationController {

    @GetMapping(value = "/")
    @ResponseBody
    String getType(@RequestParam Map<String, String> queryParameters) {
        XXForm form = getObjectMapper().convertValue(queryParameters, XXXForm.class);
        validate(authorize);
        // 正常処理
        return ...
    }

    private ObjectMapper getObjectMapper() {
        return new ObjectMapper().setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE);
    }

    private void validate(Object form) {
        ValidatorFactory validatorFactory = Validation.buildDefaultValidatorFactory();
        Validator validator = validatorFactory.getValidator();
        Set<ConstraintViolation<Object>> violations = validator.validate(form);
        if (!violations.isEmpty()) {
            // バリデーションエラーのときの処理
        }
    }

}
import javax.validation.constraints.AssertTrue;
import javax.validation.constraints.NotNull;

public class XXXForm {
    @NotNull
    public String type;

    public String state;

    @AssertTrue
    public boolean isType() {
        return responseType.equals("hogehoge");
    }
}

💭 うーーーーん

validationのときに、この値はこういうものだよ!って細かく定義したいけど、それって@AssertTrue使うのかな…?
相関ってわけじゃないので、モヤモヤする〜〜〜。
やりたいこととしては、そもそものプロパティのドメインって感じなんだけどな〜〜〜。

BeanValidationの相関バリデーションとそもそもの話 — 裏紙

上の記事がまさにソレ~!で、ドメインとして定義したい…

プログラマのためのDocker教科書をよんだ!やっぱり阿佐さんの本はわかりやすい〜〜

Dockerに入門する必要があったので、プログラマのためのDocker教科書を慌てて読んだ!📖

AWSの本を読んだときも思ったけど、阿佐さんの本は超わかりやすい〜
『ハードウェアってなに?ミドルウェアってなに?』っていう基本的なところから、『マルチホスト環境やクラスタ構成でのDockerの使い方』っていう応用っぽい内容まで、一冊の本にわかりやすく書いているの、本当にすごい…!

目次はここに書いてあります!
プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化(WINGSプロジェクト阿佐志保 山田祥寛) | 翔泳社の本

特に知りたかった、

  • Dockerコンテナがどういう単位で区画化されるか
  • コンテナ同士、コンテナと外部ネットワークの通信
  • Docker Composeによる複数のコンテナの管理

あたりを学べました!

そうなんだー!って思ったのは
「Dockerfileの命令ごとにイメージを作成する」ってところ!

たとえば、Dockerfileに

FROM centos:latest

RUN yum install -y httpd

COPY index.html /var/www/html

CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]

って書いてdocker buildすると、1行に1つずつイメージができるので、↑のDockerfileだと4つのイメージができて、それを積み重ねていくような作りになっているってこと!
ストレージドライバによって、イメージを積み重ねられる数に上限があるから、Dockerfileに命令を書く時は、命令を適切にまとめて書いて、命令の数が無駄に増えないように気をつけなければならない、ってこと!

株式会社はてなさんとLT FREESTYLE BATTLEをしました!

Mackerel サーバ監視[実践]入門の発売で話題の株式会社はてなさんと、7/7にLT FREESTYLE BATTLEを実施しました!

🎉 LT FREESTYLE BATTLEとは?

異なる団体の情報を共有しあって理解・交流することで、会社の一体感を高めたりお互いに刺激を与えたりすることを目的としたイベントです!
2つの団体に所属するメンバーが交互にLTをして、どちらの団体が聴講者の心を熱くさせたかを競います!
こちらにも記事を書いてます!
LT FREE STYLE BATTLEという取り組みと挑戦者大募集 - そこに仁義はあるのか(仮)

🎤 イベントの様子

発表者はこちらのみなさまでした!なんと、はてな社長の栗栖さんにも発表していただきました!
ありがとうございます!

株式会社はてなさん

TIS

🎤 イベント開始!

まずは、スポーツマンシップに則り、両チームの大将である、id:chris4403 さんと@さんの握手から!

f:id:syobochim:20170707191112j:plain

id:chris4403 さんは元TISの社員であり、二人は10年前にTISの社内イベントにて 同じ時間帯・別レーンで発表していた仲だったのです!
二人が同じイベントで登壇するのは、それ以来!まさに、因縁の(?)対決です!

(10年前のTIS Kaigi2007アジェンダ↓)
f:id:syobochim:20170830135114g:plain
※Notes Hackが@さん、嗚呼素晴らしきかなGoogleとその仲間達が id:chris4403 さんの発表です!

🎤 発表スタート

合計10人のLTだったのですが、発表はデモあり、ゲームあり(?)で、聴いている人たちが全く飽きない、ワクワクできるようなLTばかりでした!

f:id:syobochim:20170707201249j:plain

f:id:syobochim:20170707200253j:plain

f:id:syobochim:20170707190734j:plain


はてなさんからは、社長から、セールスエンジニアやテックリード、デザイナーなど、様々な職種の方にお話をしていただきました!
全く知らない視点での話だったので、全部の内容がとても新鮮でした!(✌'ω' ✌)
TISは「エンジニア」というくくりはありますが、役割を分類しているわけではないので、弊社のイベント参加社員にとっても、驚きが多かったと思います!

TISは『エンジニア』という大きなくくりの中で「自分の変態性がどこにあるか」という話が多く、とても楽しめました!
自宅のサーバの話や、1人slack(?)、スマホサーバ化(?)、Holo嫁(?)、マカレルクエスト(?)など、聴いていると、「まじで、この人たち何言ってんだろう(真顔)」って話が多くてとても胸がアツくなりました!!

どちらのチームも、コンテンツ力がすごい熱意ある発表ばかりでした!
参加者からもこんな感想をもらいました!

  • 技術力がまだまだ足りないので楽しめるか不安でしたが、とても楽しかったです!!
  • あんなにのびのび話されるデモが新鮮で、楽しかったです。あそこで発表できるように、変態度を上げていきたい。
  • 色々な会社の話を聞けて、刺激を受けてモチベをあげています。

🎉 懇親会

はてなさんにMackerel Tシャツをいただきました!ありがとうございます!
懇親会では、いただいたMackerel Tシャツをかけて、急遽じゃんけん大会を開催しました!(✌'ω' ✌)

f:id:syobochim:20170707210423j:plain

懇親会のスポンサーとして、
会長、社長、副社長、常務、エクゼクティブフェロー
の方々からご支援いただき、お酒とご飯を提供させていただきました!

🎉 最後に

運営面でいたらないところがあり、いろんな方にご迷惑をおかけしましたが、はてなのみなさま、発表者のみなさま、参加者のみなさま、スポンサーになっていただいているTISの偉い人たち(!)のおかげで、大成功のイベントにすることができました!
特に、 id:Soudai さん、運営に ご協力いただき、本当にありがとうございました…!
みなさまに、本当に感謝感謝感謝感謝です…!!

今後も、改善を続けながら、イベントをやっていこうと思います…!
応援をよろしくお願いします!!

はてなさん、本当にありがとうございました!

みなさん、Mackerel本買うんやで!

Mackerel サーバ監視[実践]入門

Mackerel サーバ監視[実践]入門

「SMTPサーバをたてといたから、メール送るプログラム作って」って言われたときのやりかた

メモだよ

やったこと

1. ✏️ SMTPサーバの情報を調べる
2. ✏️ spring-bootでメールを送る
おまけ. ✏️ 相手に送信できたかどうか調べるには
おまけのおまけ. ✏️ AWS SESとバウンス率

続きを読む

アジャイルレトロスペクティブズを読んで『ふりかえり』のやり方をKPTから変えてみた

『ふりかえり』のやり方を変えてみました٩( ´ω` )و

私たちのチームでは、スプリントのふりかえりにKPTを採用していたのですが、あまりうまくいっていませんでした。

😥『ふりかえり』がうまくいかない

『ふりかえり』にて、以下のようにKPTをやっていました。

  1. 個人個人が思いついたことをK/Pとして書き出す
  2. 全体でそのK/Pを共有する
  3. とりあえず目についたK/Pについて話あい、Tを決める

しかし、このやり方ではチームの問題がポイントにフォーカスされてしまい、スプリント全体を見ないまま『ふりかえり』を進めてしまっているという実感がありました。
(ひとりがKPTを出したときに「そういえば、そういうこともありましたね。」という発言が多々出ていました。)

また、指標値の決定や測定をしておらず、振り返りによって問題が改善できているか把握できていませんでした。
いよいよチームとしてのベロシティも下がり、チームのムードもよくない感じになってきたので、『ふりかえり』のやり方を変えてみることにしました。

💡 アジャイルレトロスペクティブズ

『ふりかえり』のやり方について、色んな人に相談したところアジャイルレトロスペクティブズという書籍を教えてもらいました。

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズには、強いチームを育てる『ふりかえり』の手引きが書かれています。(サブタイトルそのまま!)
本1冊、『ふりかえり』のことしか書かれていない、『ふりかえり』のための本です!
アジャイルレトロスペクティブズを読んで知ったこととして、以下の2つがあります。

  1. 『ふりかえり』に構成があること
  2. 『ふりかえり』のやり方がたくさんあること

1. 『ふりかえり』に構成があること

『ふりかえり』は以下のように構成されます。

1. 場を設定する
 ・『ふりかえり』の目標やアジェンダの確認、チェックイン、チームの約束レビュー
2. データを収集する
 ・イテレーション/リリース/プロジェクトで起きたことを全員の共通理解にする
3. アイデアを出す
 ・データを評価・分析し、変化のためのヒントを見つけ出す。
4. 何をすべきか決定する
 ・アクションを提案し、目標を設定する。
5. 『ふりかえり』を終了する
 ・継続的改善のためのアンケート、ふりかえりのふりかえりを行う。

2. 『ふりかえり』の手法がたくさんあること

ふりかえりを構成するそれぞれの要素についても、手法がたくさんあります。
たとえば、上記の「4. 何をすべきか決定する」だけでも、

  • レトロスペクティブ計画ゲーム
  • SMARTな目標
  • 質問の輪
  • 短い話題

の手法が本に載っています。
実際どんな手法があるかは、数が多いので書きませんが、Kindleの「なか見検索!」やオーム社の本紹介ページで目次が見れるので、そこの第4章〜第8章を見ればわかります…!

我々がやっていたKPTは、「短い話題」という手法の一部として紹介されています。
私たちはいままで、『ふりかえり』の構成の中のほんの一部しか実施していなかったのです(!)

💪 実践してみた

アジャイルレトロスペクティブズの本を読んで、今回の『ふりかえり』は以下のような構成にしました。
『ふりかえり』の手法が多く載っているので、「数ある手法の中で今のチームに合う方法はどれだろう…?」と考えながら、構成を組んでいきました。

1. 場を設定する
 ・Check - in
 ・Focus On / Focus Off
2. データを収集する
 ・満足Histgram
 ・Timeline(★)
3. アイデアを出す
 ・Patterns and Shift
4. 何をすべきか決定する
 ・SMARTな目標
5. 『ふりかえり』を終了する
 ・役立った、邪魔だった、仮定した
 ・感謝
★Timeline

せっかくなので(?)ひとつだけ手法を紹介します!
Timelineは、スプリント/プロジェクト/リリースで何が起こったかを書き出していくことで、全体像をつかみ、かつ全員で認識を合わせていくことができる手法です!
横軸に日付を起き、その日に発生した「事実」と「感情」を付箋に書いて貼っていきました。

本の内容から更に工夫したこととしては、

  • 感情の付箋の色を、喜怒哀と謝(感謝や謝りたいこと)で分けた。(『喜怒哀』という手法を取り込んだ)
  • それぞれの日のチームメンバーごとのモチベーションを書き出してみた(『満足ヒストグラム』という手法を取り込んだ)

チームでやった、Timelineの結果がこんな感じです!(あえて解像度落としてます!)
f:id:syobochim:20170728174722j:plain

本には、Timelineは長期間の振り返りに向いているって書かれていましたが、1スプリント分(2週間)でも、「前半なにやったかな…?」って人がちらほらいたので、「スプリント単位のふりかえりでTimelineを作って、データを積み重ねていく方がいいんじゃないかな〜?」と思いました。

💬『スプリントの振り返り』をやってみて

スプリント全体をみてふりかえることができたという実感があり、チームメンバーの『ふりかえり』に対する満足度も高かったです。
特に、「データを収集する」>「TimeLine」では、スプリントで発生したイベントやそのときそれぞれが感じたこと・思ったことを共有することができ、データ収集しながら「この人ってこのときにこんな事を思っていたのか!」という気づきも多くありました。
「ふりかえりを終了する」>「役立った、邪魔だった、仮定した」では、『ふりかえり』そのもののレビューをすることで、「次回の『ふりかえり』をよりよいものにするにはどうすればいいか」という成長の機会を得ることが出来ました。
(ちなみに、ファシリテーターの準備は結構大変だった!)

まだ始めたばかりなので、今回の振り返りを継続して実施し、効果を測定していきます(✌'ω' ✌)
みなさまも、チームにFitした『ふりかえり』を作っていくために、アジャイルレトロスペクティブズを読んでみてはいかがでしょう!٩( ´ω` )و

大規模SIerだけど、推し技術でなぐり合うLT BATTLEを企画・運営して社長表彰とりました!

タイトルの通り、推し技術でなぐり合うLT BATTLEイベントで社長表彰をもらいました!

下の記事でも書いた、LT FREE STYLE BATTLEです(✌'ω' ✌)
syobochim.hatenablog.com

🎉 社長表彰のようす

弊社の社長表彰には「優秀プロジェクト賞」や「ベストセールス賞」、「グローバルチャレンジ賞」「生産革新賞」など、様々な賞があります。
その中の「グッジョブ賞」(よい行いをしました。)を獲得しました!(✌'ω' ✌)



社長から賞品をいただいている様子。
会場には、他の賞をとった方達と本部長、事業部長、部長がいました。
f:id:syobochim:20170514191432p:plain

続きを読む

ウェルカムバルーンはじめました

超スーパーパイパーめちゃくちゃ今更感あるけど、「ウェルカムバルーンやろう!」といって始めました(✌'ω' ✌)

🎈 やろうと思った きっかけ

同じチームの人と
「新人さんが来た時に歓迎しているような雰囲気をだせたらいいねー。」
「いま僕が常駐している会社では、『ようこそ〇〇さん!』って書かれた垂れ幕が下がっているよ!」
「ウェルカムバルーンがお手軽でちょうどいいのでは!やるぞ!!(✌'ω' ✌)」
となったのがきっかけです。

最近、他の会社のオフィスをちょこちょこ見せてもらったりしているのですが、ウェルカムバルーンをやっている会社があり、「オフィスが賑やかに(?)なっていいなー」と思っていたので、この機会に取り入れてみました。

部長に「ウェルカムバルーンやりたいんですが…。」と話すと、さっくりOKが出ました(✌'ω' ✌)

🎈 なんでウェルカムバルーンなの?

ウェルカムバルーンにした理由はこんな感じです!٩( ´ω` )و

  • ひと目で歓迎している雰囲気が伝わる
  • 設置が簡単に出来る
  • 費用が安い
  • バルーンに名前を書くことで、新人さんの名前を覚えるきっかけが増える
  • 時間が経つにつれて しぼんでいくので、ある程度の期間が来たら撤去できる

🎈 ようす

こんな感じでぷかぷかと浮かべています!

f:id:syobochim:20170510132438j:plain

「Welcome〇〇さん」って書いてるよ

f:id:syobochim:20170510132426j:plain

🎈 どうすすめたか

完全に思いつきだったので、「ウェルカムバルーンやりたいのでみなさまお金徴収します!」ではなく、「ウェルカムバルーンやるので、『いいね』と思う方はご協力ください!」という感じで寄付でお金を集めました!
今回、一回目の実績を作れたので、来年以降の進め方はまた考えなきゃなぁ、と思っています٩( ´ω` )و
さらに、予算よりも多めにお金が集まったので、バルーンを多めに購入しました。
例えば、社長表彰受賞とか、KPI達成とか、案件獲得とか、そういうお祝い事に使っていきたいなぁ、と思います!(✌'ω' ✌)

🎈 反応

オフィスですれ違う人が「なんだこれ!」や「見たことある!」と振り返ってくれるので、反応は上々です!
twitterでも、同じフロアの人がつぶやいていました!

とりあえず、新人さんも先ほど無事に(?)席に到着出来ました。
(特に感想は聞いてない)
新人さんに話かけるきっかけづくりに出来るといいなぁ、という感じです。(✌'ω' ✌)