ありがとう。また会おう。

ゆるいかんじで。かたのちからぬいて。やってます。

PHPerKaigi 2018に参加した

phperkaigi.jp

PHP界隈のエンジニアが集うイベント、とても楽しかったです。
ほんとは前夜祭も行きたかったんだけど、業務都合でやむなく断念。
後日の動画アップを心待ちにしています。

こういうイベントで発表を聞いていると、いろいろ気づきがあって。
あ、この部分うちの会社にも取り入れたいな、とか
あ～それあるあるだよね～とか、得るものが多いので
自分としてはできるだけ大事にしてて、できるだけ現場で聞きたいなと思ってます。
（あとでスライドだけとか、動画公開するイベントもあるけど、現場でしか感じれないものもあると思っていて）

で、細かいイベント報告はきっといろんな人があげると思うので（手抜きしてすいません）
今回のこのイベントが自分にとってちょっと特別だったことがあって。

自分が所属する会社がスポンサードする初のイベントだったのです。

自分は今の会社が7社目なんですが
いままで所属していた会社は、あまりこういうエンジニアイベントに理解がないのか興味が無いのか
エンジニアがなかなか採用できないとか言ってるわりには
そもそも世間的にもさほど名前知られてない会社なのに
エンジニアに集まるところに社名露出していかないと難しくね？、って思っていたのです。

で、1月のPHP勉強会に参加した時に、
主催者の @tomzoh さんが PHPerKaigiの告知をされてた時に

と軽い気持ちでつぶやいたら（あえてハッシュタグ外してたんですが）

と捕捉されたので、まぁじゃあ社内で軽く話してみっか…と、翌日中途採用担当に話をしたら
思いの外ノリノリでトントン拍子で話が進んで

となり、めでたくスポンサードすることになりました。

今の会社、まだ入社して4ヶ月そこそこなんですが
入社したての人間の提案を心よく受け入れてくれた今の会社には本当に感謝しています。

とはいえ、ほんとにここはまだまだ第一歩で
今度は発表する立場に回りたいなと思ってます。
スポンサードも、もっといろいろなイベントでできるよう、社内に働きかけようかなと。

スタッフの皆様、登壇者の皆様、主催者の @tomzoh さん、
とても素晴らしいイベントありがとうございました！

退職しました。

3年2ヶ月勤めたEMTGを退職しました。
（厳密には10月いっぱいは籍はあり、有給消化中。11月から次の会社へいきます。）

EMTGは、音楽アーティストのファンクラブサイトの運営や
電子チケット事業、EC事業などを展開しています。
自分はその中で、前半はファンクラブサイトの運営を
後半は全社的なインフラ・セキュリティ・情シス周りを担当していました。

自分は音楽ライブに行くのが好きで
このブログタイトル「ありがとう。また会おう。」も（わかりにくいですが）それに由来してるんですが
音楽業界をITで支えるという仕事はなかなか刺激的であり
趣味と実益が一致しているので楽しい仕事でした。
エンジニアの方で、音楽・ライブ好き、あるいは最近は野球やBリーグもやっているので
そのあたりに興味ある方であれば、楽しく仕事できるのではないかと思います。

なぜ今回退職を決断したかというと
一番は自分のライフスタイルの変化、というところが大きかったです。
今までは独り身だったので、多少の無茶があってもなんとかしていたのですが
昨年5月に結婚して、妻を持ち、またまだ予定は無いですが将来的に子供を授かった時に
より子育てしやすい、妻にも自分にも負担にならない環境を求めて、というところです。

ただ、100％きれいごとだけではなく、少々自分の価値観の中で合わないな・・・という部分が
特に入社して1年半くらいたってからでしょうか、ぼんやりと感じでいた事も率直にいうとあります。
俗に言う「音楽性の違い」ってやつですね。

また、エンジニアとしての成長を考えた時に
一つの会社に留まるよりも、いろいろな会社を経験した方が
より多くの経験値が得られるな、とも思っています。
確かに転職はいろいろ面倒なことも多いし、有休がゼロリセットになることもあるのですが
自分にとっては今のところ転職することで様々な視野をもつことができて
プラスになっているなと感じています。
（とはいえやはり大変なので、年齢的にもそろそろ落ち着きたいのですが）

11月からまた新しい会社で働きます。
次が7社目ですね。
今まで通り、自分のできることを愚直にやっていくだけですが
引き続きよろしくお願いします。

2017-03-25 脆弱性ええんやでルーキーズ

security-testing.doorkeeper.jp

脆弱性ええんやで、は3度めの参戦。
今回は時間も長かったこともあって、
OWASP ZAPの基本的な使い方の部分をしっかり学べたのでよかった。

いつものごとく、memo

最初に設定しておいたほうがいい項目

■基本設定
　セーフモード
　プロテクトモード★ これに切り替えること！
　標準モード（これがデフォルト）
　ATTACKモード

　※標準モードだと管理外サイトに診断が走ってしまう可能性があるため


■オプション
　ローカル・プロキシ
　　Address
　　ポート　：他サービスとかぶらないよう、5桁のがお勧め
　スパイダー（クローリング）
　　Maximum depth to crawl：
　　　スパイダーをすすめる階層の深さ。サイトの作りによって決めましょう
　　並列スキャンスレッド数
　　　大きくすれば早くなるがマシン負荷かかる
　　　通常は１で大丈夫なはず
　　　※逆に遅延させることはできない
　　　　やるならfiddler噛ませて遅延させる
　　他の設定はとりあえずデフォルトで大丈夫
　動的スキャン
　　並列スキャンするホスト数：１にしておくことお勧め
　　並列スキャンスレッド数
　　　大きくすれば早くなるがマシン負荷かかる
　　　通常は１で大丈夫なはず
　　スキャン中のミリ秒単位の遅延（最大1000ms）
　　　サイトに負荷かけすぎないよう、遅めが良い
　ネットワーク
　　「外部プロキシサーバ利用」のチェックは外す
　　　この設定を使うのは、ZAPを通った後の通信先にプロキシ通す場合。
　　　会社のプロキシとか、Fiddlerかます時とか

■ポリシー
　スキャンポリシー

■アドオン
　インストール
　アップデート
　　ヘルプ→アップデートのチェック
　　マーケットプレイス
　　　PortScannerは入れないほうが良い　上級者向け
　　　ActiveScannerRuleとPassiveScannerRuleはお勧め

起動時に出る「ZAPセッションの保存方法」
ZAPセッション：ZAPを通過した通信を保存するデータベースのこと
　「指定した場所と名前で保存」を選択
　「次回から表示しない」を選択してしまった場合の変更方法は
　オプション→データベースにある

Firefox
　FoxyProxyを使う場合はFirefoxのプロキシ設定は「プロキシを使用しない」にしておく　ポート番号はZAPの設定と同じにする

スパイダーを始めるには
左側のツリーを右クリック
　Include TO Context ＞規定のコンテキスト
　　コンテキストとは、その診断で対象となるドメインのこと
　でてきたダイアログはそのままOK
　ツリーのフォルダアイコンが赤い丸がつけばOK。スパイダー／診断対象となる
もういちど右クリック＞攻撃＞スパイダー


■LT
設計段階からセキュリティや運用を考慮
最近出た脆弱性はほぼアップデートで解決可能
運用上アップデートできる体制にする
EOLにならないような製品選択（LTS）

構築しながらの脆弱性検査

～～～～～

あと、最近みんなこの話題に触れるｗ

blogs.itmedia.co.jp

僕も該当するんで気をつけます^^;

2017-03-24 Vuls祭り#2

vuls-jp.connpass.com

Vuls, 以前なんかの勉強会で知って、かなり便利そうだなという印象があって
今回このMeetupがあるってことで参加しました。

発表資料は上記サイトに上がっているのでそれをみてもらうとして。

それにしてもセキュリティ界隈の方々はいろいろな意味で猛者が多いというか
自分はまだまだ底辺だな…と痛感してしまう。
もっと勉強真剣に進めないとな…

Vulsはぜひ実務でも導入してみたい。

2017-03-18 Productivity Engineering − Forkwell Meetup #4

https://forkwell.connpass.com/event/51332/

いつものごとくですが、雑なmemo。

～～～～～～～～～～～～～～～

■クックパッドにおけるモバイルアプリ開発の工夫　クックパッド @ichiko_revjune

リリース間隔　2週間から1ヶ月
関わるエンジニア　10名程度
リリース間隔の最初にキックオフを実施

朝会をSlack上に移動
　（会社がフルフレックスになったこともある）
　観察に得られる情報がなくなる（順調か、疲労はなど）

■Effective Retrospective　アトラクタ @ryuzee

Retrospective　＝　ふりかえり
有名なのはKPT
目的
　・もっとうまくできるように
　・強制的に仕事を停止する
　　　忙しいときほど止まれないが止まらないと事故が起こる
　　　強制的にとまって冷静に考える時間を作る

ふりかえりにおける大前提＝心理的安全性
　立場の上下関係、人事評価の恐怖があると本当の問題にたどり着かない
　まずはその場を安全にすること
　「あなたvsわたし」を「問題vsわたしたち」にする

「アジャイルレトロスペクティブス」
　１）場を設定する
　　会議の冒頭に全員に口を開いてもらうと主体的参加度が上がる傾向
　　進め方を説明
　２）データを収集する
　　意見だけを元にすると解決策が危うくなる
　３）アイデアを出す
　４）何をすべきかを決定する
　　誰がいつまでにやるのかをはっきりする
　　「拳から5本指」
　５）終了する
　　記録を残す

失敗例と対策
　KPTばかりではなく、やり方を変える（タイムライン）
　　KPTは断片になりがちなので、ときには全体をみる
　場所を変える

いい話を若干大げさに褒め称える
早めの時間にやる


■自己言及的なチームをつくる　GMOペパボ @june29

自分たちに自覚的である、会話している
自分たちの問題を解決できるのは自分たちの行動だけ
自力で前進できると意識することも重要
いちばん難しいのは無関心
「加点方式」でチームを捉える　信頼貯金をためる
　「減点方式」チームはトラブルを隠す

自分たちの日々を自分たちでデザインする

言葉を尽くす、行動で示す
　チームにとっての良さを言葉にする
　褒める
　率先して行動する

個の価値観の押しつけはチームの価値観を壊す

Google Spreadsheet as Cron（はてな）

「思考停止するな」


■最速で価値を提供する　ネクスト @masamichi

狩野モデル
　魅力的品質
　性能品質
　当たり前品質

ISO/IEC25010
品質の仕様化
　言語化されない品質は作られない
「品質は誰かにとっての価値である」（Weinberg）

トレードオフではなくANDの発想（ビジョナリー・カンパニー）



■ペアプログラミングの使いどころ　タワーズ・クエスト @t_wada

ペアプログラミングのやりかた（大事なこと）
　喋る
　　（考えを声に出す、時にはホワイトボードなどに書く）
　喜ぶ、
　交代する（例：テストを書く人と実装の人をわける）
　でかいディスプレイお勧め
　
いつ、誰とやるか
　チームに新しいメンバーが入ってきたとき
　不具合修正
　新機能作成
　日ｏｒ週に一回決まった時間に

なぜやるか？
　稼働率よりスループット
　ペアプロは常にレビューを回すプロセス
　書き終えた後の指摘より書いている最中の指摘のほうが受け入れやすい
　スキル伝授にペアプロ最速
　　コードを書く瞬間の思考にアドバイスを貰えるから

FAQ
　コストが倍になるのでは？
　　エラーを超初期に直せる。将来の時間が省かれた形でやってくる
　　現実として、コストは1倍と2倍のあいだ
　開発環境がバラバラ
　　「お前のこのみとチームの成功とで大事なのはどっちだ？」（Kent Beck）
　揮発性が高い
　　（2人の間だけで、チームの共有にならない）
　　→モブプログラミングというやり方
　上級者にメリットあるの？
　　「教えることが一番の学び」教えることで知識が整理される（きのこ80）
　プレッシャーが強いから苦手
　　心理的安全性が一番大事
　　個人を尊重する
　　　全員ができるものではない


ソロプロはOSS活動に費やす

「食わず嫌いはもったいない」（塹壕からのScrumとXP）

質疑応答
　経営層への説得方法は？
　→「許可を求めるな、謝罪せよ」
　　リファクタリングも
　　また、短時間だけ導入するのもあり
　　不具合修正はペアプロで、とかも説得しやすい
　　　（不具合修正はチーム成長のチャンス）

2017-03-08 社内Meetupを主催した。

先週水曜日、社内Meetupを主催した。

今までうちの会社ではほとんど勉強会的なことはやっていなくて
前職では毎週勉強会みたいな会社にいた身としては
全く無いのもどうなのかなぁ・・・とずっともやもやとした思いを抱いていた。

そんな折、2月に社長も含めて社内のエンジニア集めて飲む機会があったのが
その飲み会自体、そもそも社長が
「エンジニアはコミュニケーション取れてるのか？飲んでるのか？」
という話がきっかけだったと聞いている。
で、その飲み会の中で、数名で勉強会的なことやりたいね、ということになり
今回の運びとなった。

第1回は、ちょうど Japan AWS Users Groupの祭典、JAWS DAYSが直前だったので
AWS総復習と題して、自分が喋ることにした。
スライドはこちら。

www.slideshare.net

内容は総復習っってことで、かなり上っ面部分だけになっているのと
かなり喋りでカバーしてるので、雑な作りになっているのはご容赦を。

で、実際にやってみて、こういう場は定期的にやったほうがいいな、と改めて実感した。
特にうちの会社は、今エンジニアが複数部署にわかれていて
建物も別のところにいたりするので（たいして離れた場所ではないが）
部署が違うと向こうが何してるのかわからない、みたいなことで、知識の分断が発生していて
その交流を促す意味でも、こういう場は必要だなと。
また、だからこそ「勉強会」ではなく「Meetup」というタイトルに意味を込めてて
誰かが先生になって教える、ではなく、全員が対等にコミュニケーションする場を提供したい、という思いでであった。

参加者には好評だったので、今後も2回、3回・・・と続けていきたいと思っている。
まだ、社内Meetupという位置づけだが、ゆくゆくは社外の人を呼べるような場に育てていきたい。

2017-03-11 JAWS DAYS 2017

http://jawsdays2017.jaws-ug.jp/

AWS User Group Japan の年に一度の大イベント。
昨年に続き今年も参加しました。
やはりこの熱気はすごい。
スライド見るだけではなく、現地で感じることが大事だと思う。

■赤ドクロ Presents 『AWSで開発するならこれやっときゃいいよ的な話』

EFSの話でてたけど、東京リージョンまだきてないんだよね・・・AWSさん、お願いします。

The Twelve Factor App の話。
https://12factor.net/ja/
本来はクラウドとは関係ないが、クラウドではより重要になってくるプラクティス。

DevOps はCultureが大事で、続いてPractice, Tool。

■AWS SECURITY DEATH \m/ ～セキュ鮫様からのお告げ～ by Security-JAWS

Security Groupはステートフルなので戻り通信の設定は不要
Network ACLはステートレスなのでin/out両方設定が必要

Shield（DDos対策)
　CloudFrontでオプションを有効化すれば使える
　CloudFront, ELB/ALB、Route53に有効
　コスト：Basicは無料 Advancedは 300$/月
　　※DDosに該当する通信の転送量はかからない

AWS WAF
　CloudFront, ELB, ALBに仕込める
　デメリット
　　正規表現でルール書けない、細かいカスタマイズが難しい
　　POST通信の中身がみれない（遮断はできる）

設計段階でのセキュリティ考慮が大事

AWS Config　構成管理
　ELBはALBのみ対応。Classic ELBは非対応
　監査・コンプライアンス、トラブルシュート用途に
　コストはお安め
　AWS Config Rules
　　構成管理設設定をチェックするツール
　　AWSが用意するマネージドルールとLambdaで定義するカスタムルールがある
EC2 Systems Manager
　→OSの中の情報をマネージメントコンソールで確認

■コミュニティで拓く、パラレルキャリアへの道

5社で働くってすごい。。。
関係者への「期待値コントロール」大事

■知らない間に使われていませんか？ ～AWSの利用監査対策～

CloudWatch Logs
CloudTrail→CloudWatch Logs連携
AWS CIS・・・不正操作の代表的なものを挙げている
「オオカミ少年」にならないよう、バランスが必要

カスタム通知
CloudTrail→CloudWatch Logs→Lambda→SNS
Lambdaでメール本文を日本語化してSNSでメール送信してる

ログの集約、検索、レポート
「sumologic」を利用（AWSのパートナーになっている）
　無料枠あり
　CloudTrail、S3、ELB、Inspector等と連携
　Deep Securityのログも見れる

Bastion監査も似たような仕組みで実施
（誰がSSH接続したか、失敗形跡など）

■武闘派CIO３人が、ホンネで語るITの現実

去年も長谷川さんのトークセッション聞いたけどほんと面白い。

AmazonGoすごい。
「学び方を学ぶ」
「忍者の草飛び」
　…最初は低い草を飛ぶ、草が成長してだんだん高くなるやつ
　　なんか忍者ハットリくんだか、藤子不二雄系の漫画で見た記憶ある
「客を捕まえてから新規事業提案」が鉄則
CIOはゴールキーパー的役割
同じ過ちを３回した場合と自分ごとにしない人には叱る

■AWSデータベースアップデート 2017

Redis
　オリジナルではなく、Amazonが改修いれたものを使っている
　海外ではRedisに永続データを入れるケースが増えている

Aurora
　r3.xlarge以上になると、MySQLとのパフォーマンス差が顕著に
　PostgreSQL Aurora
　　Performance Insight
　　　クエリパフォーマンスをマネージメントコンソールで見れる
　　　他のエンジンにも展開予定あり
　オンラインDDLが爆速（NULL許可でカラム追加の場合）
　今後のアップデート
　　Online Point in Time Restore
　　Database cloning
　　　コピーしてもボリュームコスト２倍にならない。差分分のみ増える
　Aurora Auditing
　　MySQLのAuditプラグインよりパフォーマンス劣化が小さい
　Index構築も速い
　空間Indexも速い

DMS
　fan in（複数DBを１つに）、fan out（1つのDBを複数DBに）も可能
　オンプレ→AWSだけでなく、AWS→オンプレもできる
　評価レポート・・・移行のしやすさを評価したもの

Athena
　S3のファイルをSQLで直接検索
　LTSV,CSV,JSON等対応。gz圧縮対応
　裏はPrestoで動いている
　Amazon QuickSight
　　S3、RDSにつないでグラフ生成。13種類

今後のリリース予定
　Amazon Glue・・・マネージドなETL