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

まぁゆるりとやっていきますよと。

「Clean Architecture」読了

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

素晴らしい本だった。今年自分が読んだ本の中で間違いなくNo.1。

自分はけして本を読むのが速い方ではないのだが、この本はとにかく面白くて
続きが読みたくて、あっという間に読み切った。(それでも1週間かかったので遅読だろう)

概念と実例がほどよいテンポで混ざっているのが良い。
Clean Architectureとかヘキサゴナルアーキテクチャとか、今までなんとなく理解していた気でいたけど
この本でだいぶ腹落ちした気がする。

読んだだけで満足してたのではだめなので、実践していきたい。
とりあえず思い浮かんだのは、今まで業務で関わったシステムを
この本の理論に従って再構築するとどんな設計になるか、思考実験してみようと思う。

あと、おそらくこの本は、業務でしばらく経験したあとにもう一度読むと
また学びが得られそうな予感がする。
そう、いわゆるスルメ本。噛めば噛むほど味が出そう。

職場にぜひ1冊おいて、若手から中堅、ベテランまで読んでほしい一冊だった。

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:
   スパイダーをすすめる階層の深さ。サイトの作りによって決めましょう
  並列スキャンスレッド数
   大きくすれば早くなるがマシン負荷かかる
   通常は1で大丈夫なはず
   ※逆に遅延させることはできない
    やるならfiddler噛ませて遅延させる
  他の設定はとりあえずデフォルトで大丈夫
 動的スキャン
  並列スキャンするホスト数:1にしておくことお勧め
  並列スキャンスレッド数
   大きくすれば早くなるがマシン負荷かかる
   通常は1で大丈夫なはず
  スキャン中のミリ秒単位の遅延(最大1000ms)
   サイトに負荷かけすぎないよう、遅めが良い
 ネットワーク
  「外部プロキシサーバ利用」のチェックは外す
   この設定を使うのは、ZAPを通った後の通信先にプロキシ通す場合。
   会社のプロキシとか、Fiddlerかます時とか

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

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

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

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

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


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

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

~~~~~

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

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わたしたち」にする

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

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

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


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

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

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

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

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

Google Spreadsheet as Cron(はてな

「思考停止するな」


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

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

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

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



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

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

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

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という位置づけだが、ゆくゆくは社外の人を呼べるような場に育てていきたい。