泥水エンジニア日記

泥水の数だけ強くなれる

『安全なWebアプリケーションの作り方』を読んだ

とか言ってたら、社長に『安全なWebアプリケーションの作り方』を買ってもらえました。感謝。

さて、『安全なWebアプリケーションの作り方』についてですが、こちらも今更僕が何かを語るまでもないソフトウェア開発の名著です。Web セキュリティの第一人者、徳丸先生の書いたセキュリティ本。

セキュリティ監査の対応とかやってた割に、この辺の知識を体系的に説明できないのがコンプレックスで、来年の監査が始まる前に読んでおこうと思ったのがきっかけです。

この本の良いところはとにかく徹底して「体系的」なこと。

クロスサイトスクリプティングSQL インジェクションなどの代表的なセキュリティ上のバグを取り上げ、それらについて、

  • どんな箇所で起きるか
  • どんな影響があるか
  • 利用者の関与が必要か
  • 脆弱性が生まれる原因
  • 対策方法

が漏れなく説明されており、セキュリティ対策として「どういう理由で何をすればいいのか」が一目でわかる。常に手元に置いておきたい一冊です。

本の構成についても、そもそも Web 脆弱性とは何か、から始まり、HTTP やセッション管理など、Web の仕組みのおさらいをした上で、Web アプリケーションの機能別にみるセキュリティバグ(SQLインジェクションとか)、セキュリティ機能(認証・認可とか)の話に移る、という構成で、迷子にならずにスイスイ読めます。

今年の6月に改訂版が出版される、という話も出ていて、 Web APIJavaScript のセキュリティについてや、安全でないデシリアライゼーション、XXE に関する解説が追加されるそうです。未読の人は、ちょうどいいタイミングなので読んでみるといいんじゃないでしょうか。

以下、いつのも読書メモです。

『実践ドメイン駆動設計』を読んで社内勉強会をやった

経緯

little-hands.hatenablog.com

JJUG2017Fall で「DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話」というセッションを見て、その発表をした @little_hand_s さんとお話させていただいて、「DDDってすごい!俺もやる!」という気持ちになったのがきっかけ。

ちょうど同じくらいの時期に自社サービスの追加開発の話があって、

  • 既存のコードベースとは別のリポジトリで開発できそう
  • どうせやるなら理想の設計を追求したい
  • DDD ってやつのどこがいいのかいっちょ教えてくれや泥水さんよぉ

という流れで、開発チームのみんなを集めて社内勉強会をする運びになりました。

進め方

勉強会の教材に使ったのはヴァーン・ヴァーノンの『実践ドメイン駆動設計』。

実践ドメイン駆動設計 (Object Oriented SELECTION)

実践ドメイン駆動設計 (Object Oriented SELECTION)

『エリック・エヴァンスのドメイン駆動設計』とどちらにしようか悩んだんだけど、

  • 前に一度読んだことがあるものの、雲を掴むような話がずっと続いて辛かった
  • 「『実践』の方が圧倒的にわかりやすい」という話を @little_hand_s さんから聞いてた

という事情を加味してこちらにしました。『エリック・エヴァンスのドメイン駆動設計』に興味がある人は過去のブログ記事を読んでみてください。

gushernobindsme.hatenablog.com

構成

『実践ドメイン駆動設計』の章立てに沿って、三部構成で勉強会を実施しました。

  • 第1部:DDD の概要(第1章)
  • 第2部:戦略的設計(第2章〜第3章)
  • 第3部:戦術的設計(第4章〜第14章)

まずは DDD を導入するとどういうメリットがあるのか(あるいはオーバヘッドがあるのか)を理解してもらい、その上で、「戦略的設計」と「戦術的設計」という二つのツールの役割と使い方を説明する、という構成です。『実践ドメイン駆動設計』の受け売りですね。

勉強会には『実践ドメイン駆動設計』を全く読んでいない人にも参加してもらったんですが、この二つをはっきり分けて説明する構成にしたお陰で、みんな脱落することなく最後まで完走することができました。DDD に興味のあるデザイナ氏も遊びに来てくれたりして、和気藹々とした会になって良かったです。総スライド数155ページという最悪の構成で無茶のある進行をしたのに、みんなブチ切れることなく話を聞いてくれて本当に良かった。

全3回の勉強会を終えたあとは、ワークショップっぽい感じのコンテンツとして以下を用意しました。

  • みんなで現状のコンテキストマップについて認識合わせ
  • 理想のコンテキストマップを描いてみよう

「理想のコンテキストマップ」については、ホントはやりたかったんだけど、準備不足でうまく進行できなかったので割愛。とはいえ、4days の勉強会を通じて「レガシーシステムのここを直したい」「将来的にはこんな構成にしたいと思ってる」「ビジネスサイドの話をもっとたくさん聞いた方が良さそう」など、色々意見交換できたのはよかったかなと思っています。

DDD を実践することはまだできていないんですが、引き続きやっていこうと思います。おわり。

『この一冊で全部わかるネットワークの基本』を読んだ

最近、インフラを触る機会が増えてきたんだけど、実現不可能なはちゃめちゃな構成図を書いてしまったり、ボスとの会話がうまく噛み合わなかったり、みたいなことが結構あった。

で、なんでうまく行かないかって考えると、理由は明らかで、これまでの人生でネットワークの基礎知識を固める作業から逃げ回ってきたから。多分、一般的にはみんな基本情報技術者試験とかを受ける過程でこの辺の知識を身につけていくと思うんだけど、この試験の合格基準は60点なので、出題範囲となる分野を丸々一個捨てていても、ぶっちゃけ合格はできてしまう(実体験)。そんな訳で、とりあえず試験に合格だけしまった自分としては、この辺の領域をなあなあにしてきたことについてのコンプレックスがこれまでずっとあった。

とはいえ、いつまでも逃げ回る訳にも行かないし、そろそろちゃんと立ち向かうか、ということで手に取ったのがこの本。

「今更そんな本手に取るの?!」と先輩からは驚かれたんだけど(実際そうだと思うんですけど……)、これ、ものすごく良い本でした。

左のページに本文、右のページに図、というのが本書の基本構成になるんだけど、この構成が圧倒的にわかりやすい。最初から最後までこの構成が一貫して続いているので、次の展開が想像できて、頭の中がとっちらかることなくグイグイ読めます。

書いてある内容については、

  • ネットワークの基礎知識
  • TCP/IP の基礎知識
  • TCP/IP で通信するための仕組み
  • ネットワーク機器と仮想化
  • ネットワークのサービス
  • ネットワークのセキュリティ
  • ネットワークの構築と運用

こんな感じ。章立てをそのまま引用しただけですが、なんとなくイメージは伝わるかなと。

タイトルの通り、本当に初心者向けの内容なので、基礎をちゃんと勉強済みの人や、ある程度インフラ構築の経験がある人には物足りないと思います。ただ、僕はこの本を読んでようやく TCP/IP とかサブネットの意味がきちんと理解できたので、刺さる人にはきっちり刺さる内容のはず。

これから基本情報技術試験を受けるという人や、ネットワーク知識コンプレックス*1がある人なんかは、買ってみるといいんじゃないでしょうか。

コンプレックス解消作戦として↓の本も買ったんだけど、こちらはまた後ほど読みます。インフラエンジニアじゃないけど。

現場のインフラ屋が教える インフラエンジニアになるための教科書

現場のインフラ屋が教える インフラエンジニアになるための教科書

*1:いま考えた造語

2017年の振り返り

今週のお題「2018年の抱負」

f:id:gushernobindsme:20171215122740j:plain

年末の 1on1 でなんだかうまく喋れなかったので、去年の振り返りを書いてみる。ガーデンプレイスの39階で「恵比寿はワシのもんや!」と言いながら撮った写真とともにお楽しみください。

良い習慣を持てるようになった

2017年5月、人生で初の転職を経験した。

転職して良かったこととしては、年収が上がった、新しい技術に触れられるようになった、など色々あるけれど、一番大きいのは時間の余裕ができたことだと思う。土日と祝日に憂いなく休める環境のおかげで、習慣的に物事に取り組めるようになった。

習慣化できたこととしては3つあって、そのうちの1つは読書。技術書とかクレカに関する本を毎週末読むようになって、今年だけで 15 冊読めた。また、今年からは本の内容を MarkDown で要約して gist にアップし、ブログにリンクを貼り付ける、ということを試験的にやってみている。前職で「お前は知識はあるけど知恵がないな」とか言われたのを僕はいまだに根に持っていて、読んだ本の内容をちゃんと自分に根付かせる方法をずっと模索していたのだけど、ようやくしっくりくるやり方が見つかった気がする。

2つ目はエンジニア勉強会の定期参加。JJUG、渋谷JavaAPI STUDY、Security-JAWS、Fin-JAWS、Tech Beer Bash、SRE Meetup Tokyo、PPUG など色々な勉強会に顔を出した。社外の勉強会というものに対してずっと憧れを抱いていたため、その反動でちょっと出歩き過ぎたかな、というきらいはあるけれど、会を通じて多くのエンジニアと知り合いになれて「俺ももっと頑張らなきゃなー」という気持ちを強くすることができた。勉強会で拾ってきた情報を持ち帰って社内に共有しまくってたら割と喜ばれたので、こちらの活動も引き続きやっていけるといいな、と思っている。

3つ目は運動。ここで書いた筋トレが意外にもまだ継続できていて、2017年12月末の時点でも、毎週一回ペースを継続できている。「体育会系マインド身に付けるのとか無理だし目標管理とか絶対にできる気がしないので、パーソナルトレーナーに金払ってアウトソースしたろ」と割り切ったスタンスで臨んだのが良かったんだと思う。社の人の影響で、今ではランニングも習慣的にやるようになっていて、毎週5kmくらいは走るようになった。

習慣化の力ってすごくて、「毎週決まった時間にこれをやるぞ」と決めていると、いつもの行動を取っていないだけでなんだかムズムズしてくるようになる。前職での気に入らなかったことに「お前みたいな馬鹿が俺以外の下で働けると思うなよ」という発言があり、いまだに根に持っているんだけど(二回目)、頭が悪かろうと、物覚えが悪かろうと、コツコツ積み上げた知識と経験があればそれなりに戦えるはずだと思っていて、今年は多少なりそれを証明できたので良かったと思う。引き続き良い習慣をやっていきましょう。

得意分野を活かして働けるようになった

前職では、フロントエンドとバックエンドを全てできるようにする必要があり(というよりフロントとバックエンドを分けるという発想がそもそもなかった)、苦手な UI 周りの作業でドチャクソ怒られて意気消沈することが多かった。「苦手なことを克服しなければお前に生きる道はない」とひたすら脅され続けて育ったんですけど、なんか、世の中そういう訳じゃないみたいですね。

今の職場では(比較的)得意な方の技術スタックであるバックエンドの仕事を主にさせてもらっている。好きこそものの上手なれ、じゃないけれど、得意なことをやってると楽しく働けて、楽しいと学習意欲が湧くので自然に勉強するようになって、できることが色々増えていく。

前向きな気持ちで働いていると得意ジャンルも増えるのか、最近では資料作成のタスクもうまくやれるようになってきた。多分、知識を十分に噛み砕いてから作業を始めるのがコツなんだと思う。前職では何か資料を作るたびにドチャクソ怒られてて、ずっと資料作成に対して苦手意識があったんだけど、これまでの苦労は一体なんだったんだと遠い気持ちになる。

あとは、JAWS 系のイベントに参加しまくったおかげか、インフラ系、セキュリティ系の仕事についてもちょっとずつできることが増えてきた。Security by Design の観点から、どうすればより良い構成にできるかを考えるのはとても楽しい。人に何かを説明するような機会も(事前に資料とか図とかを起こして整理した上であれば)うまくやれる自信がついてきたので、引き続きできることを増やしていきたい。

もっと色んなものを早く作れたはず

ここからは反省パート。

ある程度は覚悟していたことだったけれど、とにかく自分の知識不足がやばく、調べ物や、指摘修正に多くの時間がかかってしまい、全体的にゆっくりとした進行になってしまった。

例えば、API 設計の基礎知識が足りていないために、レビューで根幹を揺るがす指摘をもらってしまい中々リリースできない状況になったりとか。AWS のインフラ知識が足りていないために中々手順を整理できず、リリース日が遅くなったりとか。前者は『Web API: The Good Parts』、後者は『Amazon Web Services実践入門』あたりを読んで勉強する必要があるなあ、と思っている。

Web API: The Good Parts

Web API: The Good Parts

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

あとは、教養として『安全なWebアプリケーションの作り方』『マイクロサービスアーキテクチャ』あたりも抑えておきたい。特に一冊目は事前に読んでおけばもっと色んな説明がスムーズにできたと思うので……。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

2018年やりたいこと

  • 技術書展に出店する
  • 何かしらの勉強会で発表できるようになる
  • AWS ソリューションアーキテクトアソシエイトを受ける
  • 上に挙げた本を読む
  • もっとコードを書く
  • テストをもっとよくする
  • 監査をもっと楽にする
  • ベンチプレス 50kg 上げられるようになる
  • ハーフマラソンを完走する

という感じで頑張ります。

直近としては、バックエンドの設計・開発力と AWS 力にステ振りして、もっと色んなものを早く作れるようになりたい。あと、根に持つのをやめる。

『エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド』を読んだ

実は実務で MySQL 触るの初めてなんすよね、みたいな話をしてたところ、会社の先輩が貸してくれた一冊。情報量が多くて手強いんですが、教養として読んどいてよかった。「漢(オトコ)のコンピュータ道」で有名な奥野さんの書いた MySQL 本です。

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

Oracle についてはそれなりに経験があるけれど、同じようなことって MySQL だとどうやればいいんだっけ?という人に大変オススメの一冊。500 ページ超の大作で、とにかく情報量が多い!DBA 向けの内容に絞ってこのボリュームなので、とにかく説明がめちゃくちゃ詳しいです。

特に第3章の EXPLAIN に関する項は必読。Oracle の DBA 向けの本でも、ここまで詳細な(しかもわかりやすい)統計情報の読み解き方のレクチャーは、今まで一度もお目にかかったことがないです。ここだけで 3,564 円分の価値がある、と言っても全然言い過ぎじゃない。

DB サーバの管理が AWS にお任せできる時代になったとはいえ、MySQL 経験の浅い人は、本書を一読しておくとテンパらずに済んでいいんじゃないでしょうか。

とはいえ、2017 年の後半はずっとこの本読んでた気がするので、来年はもっと早く本を読めるようになりたいですね。

いつもの読書メモを置いておきます。

コード供養としてのQiita

経緯

からの、

実践

という訳で、連休を利用して以下の 3 記事を Qiita に投稿しました。*1

qiita.com qiita.com qiita.com

直近でプロダクトの役に立たなかったとしても、いつか必要になる日が来るかもしれない訳で、その日のために知見を書き残しておくのは(遥か古の commit log を引っ張り出してくるのに比べたら)まあまあ悪くないんじゃないかなあ、と思ったりした。

書き残しておきたいことは他にもたくさんあって、

  • AWS
    • AWS で簡単 VPC 環境構築
  • SpringBoot
    • Spring Actuator について
    • キャッシュについて
    • AsyncTaskExecutor を使った並列化について
    • Aspect Oriented Programmingについて
  • Ansible

あたりはちゃんとまとめておきたい。まあ、そもそもコード供養が必要になるような局面をもっと減らして打率上げようよ、という気もするのだけど、その辺は今後の宿題にします。

*1:厳密には、一番上の記事はちゃんとプロダクトに還元できそうなのでちょっと意味合いが違うんだけど、わざわざ説明するほどのことでもないので省略

『ライト、ついてますか―問題発見の人間学』を読んだ

最近、社内で「もっとテストに力入れていかないとね」みたいな機運が高まっていて、自分としてもそこに貢献したい気持ちがあって、うまくハマる本はないものか、と記憶を掘り起こしていたところピンと来る一冊があった。それがこの本。

ライト、ついてますか―問題発見の人間学

ライト、ついてますか―問題発見の人間学

本書はいわゆる、ソフトウェア工学における古典*1で、コンサルの入門書としても有名なため、読んだ人も多いのではないかと思う。本の中で取り上げている事例に計算機の話とかが出てきて、古臭さを感じるところは多少あるけれど、今読んでも全く色褪せない。学ぶところが多い一冊です。

結構みんながやりがちな失敗として、問題を読まずに解こうとする、ということがあると思っていて、

  • 障害報告が運用部門からあがってくる
    • 報告内容を読む限り、仕様通りの動きをしていなさそうだ
    • コードを追いかけてみる
      • 確かに報告内容にある通りのロジックになっているぞ!
      • 意気揚々と直す
    • 念のため仕様書にもう一回目を通してみる
      • 仕様と今の実装が正しいことがわかる
      • 運用部門と話をしてみると、運用部門の理解が間違っていたことがわかる
      • 泣きながら三時間分の作業を revert する

みたいな経験をした人は結構多いんじゃないでしょうか。*2

こういうケースで効いてくるのがこの本に書かれている「問題発見学」。問題を解くためには、まず問題を発見する(定義する)ことが重要である、と本書では説いています。

本書の目次の構成にもなっている、

  • 何が問題か?
  • 問題は何なのか?
  • 問題は本当のところ何か?
  • それは誰の問題か?
  • それはどこからきたか?
  • われわれはそれを本当に解きたいか?

を、問題を解き始める前に、まず問い直してみることが重要なのだそう。耳が痛い話ですが、小粋なジョークとパンチの効いた挿絵が随所に散りばめられているので、不思議と説教臭さを感じることなくスイスイ読めます。

品質向上、みたいな話で困っている人は息抜きがてら読んでみるといいんじゃないでしょうか。

以下、読書メモです。

*1:『人月の神話』、『熊とワルツを』などが広く知られていますが読んだことはありません

*2:したことない人はすみません。優秀なんですね