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

略してそこ仁!

MacBook Pro touch barでIntelliJ IDEAを使う私が本当に求めていたプラグイン #intellij

💡 2018/5/26 追記

この記事は古いです。↓の記事に新しい情報を載せているので、よければ見てみてください。

syobochim.hatenablog.com

以下、本文です。

まさにコレが私の本当に求めているものだったので、プラグインを紹介したい。

💡 最高のプラグイン

MacBookPro の touch bar をここまで活かせるプラグインがあっただろうか。

プラグインの紹介ページに全て書いてあるんだけど、
このプラグインを使うことで、IntelliJ IDEAを使うときのtouch barを最大限に活かすことができる!!!

plugins.jetbrains.com

💡 どうなるか

こんな感じで、自分の好きなアクションをtouch barに設定することができる!
あのキーとこのキーを一緒に押して…ってしなくても、ポンッとtouch barに触れればアクションを実行できるの、最高すぎる…。

f:id:syobochim:20180416014731j:plain

💡 使い方

インストール方法

Pluginから「Browse repositories...」を選択する

f:id:syobochim:20180416014131p:plain

↓あたりに「install」ボタンがあるので、クリックして、IntelliJを再起動する

f:id:syobochim:20180416014305p:plain

設定方法

IntelliJ IDEAの設定画面の「Appearance & Behavior > Menus and Toolbars」から、アクションを設定できる!
特に必要なさがあるけど、アイコンも自分で設定できるっぽい。

f:id:syobochim:20180416015122p:plain

「Appearance & Behavior > Menus and Toolbars > Touch Bar」の「Refresh touch bar」ボタンを押すと、設定がtouch barに反映される!

f:id:syobochim:20180416015225p:plain

最高…。

約6年勤めた某大規模SIerを退職しました

新卒から約6年間勤めたSIerを退職しました。
入社時点では、Linuxコマンドを1つも知らない。。。という状態だった私を育ててもらった、本当に恩のある会社です。

会社が嫌になったわけでは無く、むしろ、最後まで本当に好きな会社でしたが、色んな縁が重なり退職することになりました。

💬 SIerでやってきたこと

すごく大きなシステムの保守開発、業務アプリケーション開発、システムの基盤部品開発などなど、色んなシステム/案件に関わってきました。
炎上案件だったこともあるけど、どのプロジェクトでも学ぶことが多くあったし、「あの時は大変だったよね〜〜」と、ほとんどが笑って話せる思い出です。
また、どのプロジェクトにも憧れるような凄いエンジニアが居たし、業務外でも部署内・外を問わず、多くのエンジニアと関わることが出来ました。
会社が大きいと、色んなコンテキストの中で働いている多くの方と関わることが出来るし、自分にはあっていたかな〜と思います。
私がいた会社では社外のコミュニティで活発に活動している人も多いので、コミュニティで出会った人と後になって会社で会うということもありました( 'ω' )

最後の1年間は施策をやる部署に居て、AWSを使って社内展開向けのサービスを作りながら、サービスを使ってもらうべく、社内へのサービスの宣伝活動をしていました。
あまりコードを書くポジションにはいませんでしたが、人との関わりも今までと比べると一層増え、転職のきっかけになるような働き方が出来ました。

💬 会社のことをどう思うか

環境や状況は「どういう案件に入るか」という要因が大きいので、一概にどうということは言えませんが、少なくとも私のいた会社では変わっていく状況に対応しようとビジネスモデルを変えていこうとしていたり、パワーをかけるところを変えていこうとしているように感じました。
(私のいた部署は、「色んな部署でやっている案件にJOINして、一緒に開発をしていく」という部署だったので、会社全体の雰囲気にも触れやすかったのでは、と思います。)
今の時点で会社にJOINしても、きっと楽しいだろうと思います。

よく言われる、↓のような話も、「えっ、本当に違うんだけど…。」と思えるような環境に居ることが出来ました。

ウォーターフォールの大きい案件しかないんでしょ?

もちろん、ウォーターフォールで規模の大きい案件もあります。
ただ、最近ではアジャイルの案件もかなり増えてきていました。
案件の数でいうと、私の部署で対応している案件はアジャイルの方が多いくらいだったかな…?

お客様から、「変わっていく環境に対応するためにアジャイルでやってほしい」という要望が来ることもあります。
ビジネスと本気で向き合っているお客様にパートナーとして貢献できるよう、色んな形で案件に入ることが出来るようになっていく必要があるので、プロセスの整理や案件同士の情報共有など、SIerという組織自体が変化に対応するために、かなり力を入れているように感じました。

マネージャーしかキャリアパスがないんでしょ?

マネージャーではなく、エンジニアとしてエキスパートになる、というキャリアパスも用意されています。
また、スクラムマスターを増やしたりと(認定資格を取らせたり、実際の案件で動いたり)、一概にマネージャーといっても色んなキャリアが出来てきているように感じました。
ただ、大きい会社ならではで、評価制度などは追いついてない感じはありましたが、事業部や部署にある程度の裁量はもたせている感じなので、そこでカバー出来ているところも多いのではと思います。

コードを書くかどうかは、本当に個人のポジショニングの問題な気がするな…。
最後の1年間、私はあまりコードを書く感じではなかったのですが、そこは、自分がどこに力を入れて成果を出していくかという話なのかと思います。
私より先輩でもコードをバリバリ書いている人もいれば、他の方への説明・調整やチームのコントロールなどで案件を推進している人もいれば、アーキテクチャの話を検討・導入している人もいれば、、、、という感じなので。。。

古い技術ばっかり使ってるんでしょ?

これも、案件によりますが、ビジネスと本気で向き合っているお客様にパートナーとして貢献できるようになるためには色んな技術を身につける必要があると思っています。
お客様から、クラウドでやってほしい、とか、スマホアプリを、とか、アジャイルで、とか、様々な指定がきます。
ここ最近は、それに対応しなければいけない案件が本当に多かったので、多くの案件が「あんなことやっているんだ!楽しそう!」と思える感じでした。


と、SIerは結構私は好きでした。
そして、私のいた会社は6000人規模の会社でしたが、会社の偉い人たちが、業務外のイベントなど、若手の活動を応援(資金面での援助を含めて)してくれる、本当に風通しのいい会社だと感じていました。
(人事に色々聞きたい!というイベントを開くと、人事部長が来てフランクに質問に答えてくれるなど、無礼なことも笑って許してくれる、そんな風土がありました。)

💬 なんで辞めるのか

自分の半径2m以内で起こった、自分の環境独特なことは書きません。

自分の環境を変えてみたいと思ったことや、新しいキャリアにチャレンジしたくなるようなご縁があったことなど、色々な要因が重なったことが理由です。

会社としての不満はほぼ無いのですが、唯一言うならば、女性として重要な時期(産休とか育休とか)と、会社のキャリアアップのタイミングが被っているように、私には感じました。
(今のところ、産休・育休の予定はありませんが…!)
大きな会社らしく、制度としてはしっかり整備されているとわかってはいたのですが、会社の制度が変わるタイミングに巻き込まれる(?)ことが多く、 そういうところは不満が溜まっていました。
ただ、人事の方々とお話して、改善していこう・力を入れていこうとしていることは知っているので、今後よりよく改善されていくと思います。

💬 今後どうするのか

今後どうするのかは、また改めてブログ書こうと思います。

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した『ふりかえり』を作っていくために、アジャイルレトロスペクティブズを読んでみてはいかがでしょう!٩( ´ω` )و