イベント行ってきたブログが続きます！(✌'ω' ✌)
💬全体の感想
遅れて参加してしまったので、最後の２セッションしか聞けませんでした…。
でも、
1つめのセッションは、APIとビジネスのお話が中心
2つめのセッションは、AIとTechのお話が中心
という内容だったので、イベント全体としてテーマのバランスがすごく良かったのではないかな〜〜と思います！
運営のみなさま、お疲れ様でした！！
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の相関バリデーションとそもそもの話 — 裏紙
上の記事がまさにソレ～！で、ドメインとして定義したい…
プログラマのためのDocker教科書をよんだ！やっぱり阿佐さんの本はわかりやすい〜〜
Dockerに入門する必要があったので、プログラマのためのDocker教科書を慌てて読んだ！📖
プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化
- 作者: 阿佐志保,山田祥寛
- 出版社/メーカー: 翔泳社
- 発売日: 2015/11/20
- メディア: 大型本
- この商品を含むブログ (3件) を見る
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という取り組みと挑戦者大募集 - そこに仁義はあるのか(仮)
🎤 イベントの様子
発表者はこちらのみなさまでした！なんと、はてな社長の栗栖さんにも発表していただきました！
ありがとうございます！
株式会社はてなさん
id:chris4403 さん
id:Soudai さん
id:KGA さん
id:papix さん
id:mazco さん
TIS
- 川島 義隆さん（ kawasima - Qiita）
- 井出 将弘さん（decchi - Qiita）
- 村木 暢哉さん
- 斎藤 辰徳さん（bbrfkr - Qiita）
- 八代 光平さん（ko-he-8 - Qiita）
🎤 イベント開始！
まずは、スポーツマンシップに則り、両チームの大将である、id:chris4403 さんと@kawasimaさんの握手から！
id:chris4403 さんは元TISの社員であり、二人は10年前にTISの社内イベントにて 同じ時間帯・別レーンで発表していた仲だったのです！
二人が同じイベントで登壇するのは、それ以来！まさに、因縁の（？）対決です！
（10年前のTIS Kaigi2007アジェンダ↓）
※Notes Hackが@kawasimaさん、嗚呼素晴らしきかなGoogleとその仲間達が id:chris4403 さんの発表です！
🎤 発表スタート
合計10人のLTだったのですが、発表はデモあり、ゲームあり（？）で、聴いている人たちが全く飽きない、ワクワクできるようなLTばかりでした！
はてなさんからは、社長から、セールスエンジニアやテックリード、デザイナーなど、様々な職種の方にお話をしていただきました！
全く知らない視点での話だったので、全部の内容がとても新鮮でした！(✌'ω' ✌)
TISは「エンジニア」というくくりはありますが、役割を分類しているわけではないので、弊社のイベント参加社員にとっても、驚きが多かったと思います！
TISは『エンジニア』という大きなくくりの中で「自分の変態性がどこにあるか」という話が多く、とても楽しめました！
自宅のサーバの話や、1人slack（？）、スマホサーバ化（？）、Holo嫁（？）、マカレルクエスト（？）など、聴いていると、「まじで、この人たち何言ってんだろう（真顔）」って話が多くてとても胸がアツくなりました！！
どちらのチームも、コンテンツ力がすごい熱意ある発表ばかりでした！
参加者からもこんな感想をもらいました！
- 技術力がまだまだ足りないので楽しめるか不安でしたが、とても楽しかったです！！
- あんなにのびのび話されるデモが新鮮で、楽しかったです。あそこで発表できるように、変態度を上げていきたい。
- 色々な会社の話を聞けて、刺激を受けてモチベをあげています。
🎉 懇親会
はてなさんにMackerel Tシャツをいただきました！ありがとうございます！
懇親会では、いただいたMackerel Tシャツをかけて、急遽じゃんけん大会を開催しました！(✌'ω' ✌)
懇親会のスポンサーとして、
会長、社長、副社長、常務、エクゼクティブフェロー
の方々からご支援いただき、お酒とご飯を提供させていただきました！
🎉 最後に
運営面でいたらないところがあり、いろんな方にご迷惑をおかけしましたが、はてなのみなさま、発表者のみなさま、参加者のみなさま、スポンサーになっていただいているTISの偉い人たち（！）のおかげで、大成功のイベントにすることができました！
特に、 id:Soudai さん、運営に ご協力いただき、本当にありがとうございました…！
みなさまに、本当に感謝感謝感謝感謝です…！！
今後も、改善を続けながら、イベントをやっていこうと思います…！
応援をよろしくお願いします！！
はてなさん、本当にありがとうございました！
みなさん、Mackerel本買うんやで！
![Mackerel サーバ監視[実践]入門](https://images-fe.ssl-images-amazon.com/images/I/515Evik7GRL._SL160_.jpg "Mackerel サーバ監視[実践]入門")
- 作者: 井上大輔,粕谷大輔,杉山広通,田中慎司,坪内佑樹,松木雅幸
- 出版社/メーカー: 技術評論社
- 発売日: 2017/08/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る