Java Day Tokyo 2018 の参加レポと、Night Sessionで司会をしました！ #JavaDayTokyo
遅くなってしまいましたが、個人的な観点からのJava Day Tokyoの参加レポートです。
💬 全体を通しての感想
基調講演は参加出来ず、午後からの参加でした…！
Night SessionでAsk the speakersという企画の司会をやることになっていたので、なるべく登壇者のセッションを聞きにいくようにしていた結果、海外からの登壇者ばかりのセッションばかり参加していました…！
でも、翻訳イヤホンがもらえるので問題なし！
私が受けたセッションがそうだったのかもしれませんが、ジャバジャバ（Java Java）した話というよりは、
コンテナやサーバレスなど、これからのプラットフォームに対してJavaで作るシステムを適用していくための話、というのが多かった印象でした。
あとは、私は聞いていないセッションでしたが、JDKのリリースモデルの変更に関するセッションは会場から人が溢れるほど聴講者が居て、やはり関心が高いんだなぁ、と感じました。
📖 全ての資料はこちらで公開されています
以下、セッションのメモや感想です。
慣れない英語セッションの参加だったので、解釈間違ってるところもあるかもですが・・・。
IntelliJ IDEAでMacBook Proのtouch barが使えるようになって最高 #intellij
もともと、この記事を書いていましたが、
なんと本家でtouch barを活用出来るようになったとのことだったので、そちらを使うようにしてみました！
さようなら、intellij-touchプラグイン・・・。大好きだったよ・・・。
😍 どうなるか
IntelliJのリリース報告に全て書いてあるので、そこを見ていただく＋サムライズムさんのツイートを見ていただければ、わかるかと思います！
IntelliJ IDEA 2018.2 Early Access Program is open! | IntelliJ IDEA Blog
@syobochim IntelliJ IDEA2018.2ではデフォルトでタッチバーに対応致します。気に入っていただけるかと！(インストール済みのタッチバーサポートプラグインは外してください) pic.twitter.com/nEukDM2lTd
— 株式会社サムライズム (@samuraism) 2018年5月21日
API Meetup Tokyo #25『AIの民主化を推進する日本のAPI提供者』に行ってきました！
Japan Container Days V18.04に行ってきました！
Japan Container Daysに参加してきました！
💬 全体を通しての感想
↑のサイトのセッション一覧を見てもわかりますが、Kubernates祭り！という感じで、私が参加したセッションは全て、Kubernatesを絡めた内容が入っていました。
コンテナを実際に運用するうえでは、Kubernatesが欠かせない存在になっているみたいで、
開発プロセスや運用について紹介する際は、
Kubernetesありき＋合わせて使うと便利なツールやサービス
という内容ばかりでした。
また、ツールやサービスも、複数のセッションで同じツール名を聞くこともあり、ある程度「これがメジャー」というものが確立し始めているように感じました。
Keynoteで聞いた事例が面白かったし、もっとメルカリさんみたいな事例の話が聞きたいなぁ…と思いましたが、あまりそういうセッションはなく…。
そもそも、実際Kubernetesを使って運用している事例があまり無いのかも…。
『Japan Container Daysに来ている参加者』という、コンテナに興味がある人が集まったカンファレンスでさえ、
セッション中にあった「実際にKubernetesを使って運用している人？」という問いには、ほとんど手が上がらずでした…。
Kubernetes自体の説明や、Kubernetes周りのツール紹介などの内容をメインとするセッションが多かった印象なので、これから運用を始める人というターゲットには合致したセッションだったのかもです。
🛠 紹介されていたツール
私がメモしたサービスとかツールとか
（まじで、学ばねばならないこと多すぎ…）
Cloud Native Landscape（なにかするときはココからサービスを選べ）
Serverlessとは何か（是非読めとのこと）
wg-serverless/whitepaper at master · cncf/wg-serverless · GitHub
- モニタリング
- テストツール
- デリバリ
- パッケージング
- - Helm
- その他
以下、セッションのメモや感想です。
MacBook Pro touch barでIntelliJ IDEAを使う私が本当に求めていたプラグイン #intellij
以下、本文です。
まさにコレが私の本当に求めているものだったので、プラグインを紹介したい。
💡 最高のプラグイン
MacBookPro の touch bar をここまで活かせるプラグインがあっただろうか。
プラグインの紹介ページに全て書いてあるんだけど、
このプラグインを使うことで、IntelliJ IDEAを使うときのtouch barを最大限に活かすことができる！！！
💡 どうなるか
こんな感じで、自分の好きなアクションをtouch barに設定することができる！
あのキーとこのキーを一緒に押して…ってしなくても、ポンッとtouch barに触れればアクションを実行できるの、最高すぎる…。
💡 使い方
設定方法
IntelliJ IDEAの設定画面の「Appearance & Behavior ＞ Menus and Toolbars」から、アクションを設定できる！
特に必要なさがあるけど、アイコンも自分で設定できるっぽい。
「Appearance & Behavior ＞ Menus and Toolbars ＞ Touch Bar」の「Refresh touch bar」ボタンを押すと、設定がtouch barに反映される！
最高…。
約6年勤めた某大規模SIerを退職しました
新卒から約6年間勤めたSIerを退職しました。
入社時点では、Linuxコマンドを１つも知らない。。。という状態だった私を育ててもらった、本当に恩のある会社です。
会社が嫌になったわけでは無く、むしろ、最後まで本当に好きな会社でしたが、色んな縁が重なり退職することになりました。
💬 SIerでやってきたこと
すごく大きなシステムの保守開発、業務アプリケーション開発、システムの基盤部品開発などなど、色んなシステム／案件に関わってきました。
炎上案件だったこともあるけど、どのプロジェクトでも学ぶことが多くあったし、「あの時は大変だったよね〜〜」と、ほとんどが笑って話せる思い出です。
また、どのプロジェクトにも憧れるような凄いエンジニアが居たし、業務外でも部署内・外を問わず、多くのエンジニアと関わることが出来ました。
会社が大きいと、色んなコンテキストの中で働いている多くの方と関わることが出来るし、自分にはあっていたかな〜と思います。
私がいた会社では社外のコミュニティで活発に活動している人も多いので、コミュニティで出会った人と後になって会社で会うということもありました( 'ω' )
最後の１年間は施策をやる部署に居て、AWSを使って社内展開向けのサービスを作りながら、サービスを使ってもらうべく、社内へのサービスの宣伝活動をしていました。
あまりコードを書くポジションにはいませんでしたが、人との関わりも今までと比べると一層増え、転職のきっかけになるような働き方が出来ました。
💬 会社のことをどう思うか
環境や状況は「どういう案件に入るか」という要因が大きいので、一概にどうということは言えませんが、少なくとも私のいた会社では変わっていく状況に対応しようとビジネスモデルを変えていこうとしていたり、パワーをかけるところを変えていこうとしているように感じました。
（私のいた部署は、「色んな部署でやっている案件にJOINして、一緒に開発をしていく」という部署だったので、会社全体の雰囲気にも触れやすかったのでは、と思います。）
今の時点で会社にJOINしても、きっと楽しいだろうと思います。
よく言われる、↓のような話も、「えっ、本当に違うんだけど…。」と思えるような環境に居ることが出来ました。
ウォーターフォールの大きい案件しかないんでしょ？
もちろん、ウォーターフォールで規模の大きい案件もあります。
ただ、最近ではアジャイルの案件もかなり増えてきていました。
案件の数でいうと、私の部署で対応している案件はアジャイルの方が多いくらいだったかな…？
お客様から、「変わっていく環境に対応するためにアジャイルでやってほしい」という要望が来ることもあります。
ビジネスと本気で向き合っているお客様にパートナーとして貢献できるよう、色んな形で案件に入ることが出来るようになっていく必要があるので、プロセスの整理や案件同士の情報共有など、SIerという組織自体が変化に対応するために、かなり力を入れているように感じました。
マネージャーしかキャリアパスがないんでしょ？
マネージャーではなく、エンジニアとしてエキスパートになる、というキャリアパスも用意されています。
また、スクラムマスターを増やしたりと（認定資格を取らせたり、実際の案件で動いたり）、一概にマネージャーといっても色んなキャリアが出来てきているように感じました。
ただ、大きい会社ならではで、評価制度などは追いついてない感じはありましたが、事業部や部署にある程度の裁量はもたせている感じなので、そこでカバー出来ているところも多いのではと思います。
コードを書くかどうかは、本当に個人のポジショニングの問題な気がするな…。
最後の１年間、私はあまりコードを書く感じではなかったのですが、そこは、自分がどこに力を入れて成果を出していくかという話なのかと思います。
私より先輩でもコードをバリバリ書いている人もいれば、他の方への説明・調整やチームのコントロールなどで案件を推進している人もいれば、アーキテクチャの話を検討・導入している人もいれば、、、、という感じなので。。。
古い技術ばっかり使ってるんでしょ？
これも、案件によりますが、ビジネスと本気で向き合っているお客様にパートナーとして貢献できるようになるためには色んな技術を身につける必要があると思っています。
お客様から、クラウドでやってほしい、とか、スマホアプリを、とか、アジャイルで、とか、様々な指定がきます。
ここ最近は、それに対応しなければいけない案件が本当に多かったので、多くの案件が「あんなことやっているんだ！楽しそう！」と思える感じでした。
と、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の相関バリデーションとそもそもの話 — 裏紙
上の記事がまさにソレ～！で、ドメインとして定義したい…