泥水エンジニア日記

泥水の数だけ強くなれる

『プログラマのための Docker 教科書』を読んだ

Docker は本業でも副業でも使っていて、 Dockerfile の読み書きもある程度はできるんだけど、なんとなく使ってる感があって。そういうのやめたいなー、と思ったので入門書を一冊通読することにしました。

プログラマのためのDocker教科書 第2版 インフラの基礎知識&コードによる環境構築の自動化

プログラマのためのDocker教科書 第2版 インフラの基礎知識&コードによる環境構築の自動化

Docker コマンドや Dockerfile、docker-compose.yml の文法についてちゃんと把握できるようになれればいいかな、くらいの気持ちで読み始めたんだけど、

  • Docker が動く仕組み
  • Docker Machine の使い方
  • Kubernetes の概要

なんかも書いてあって満足度の高い一冊でした。

普段インフラ寄りの仕事をしていない人でも理解しやすいような構成だったので、アプリケーションエンジニアのステップアップやら、新人研修やらにも使えそうな印象。とりあえずこれ読んどいてね、でいろんなことが解決しそう。安心の WINGS プロジェクト本。

で、個人的には、Kubernetes の概要がざっくりだけど把握できたのが嬉しかったです。先日『一晩で Kubernetes を覚えて帰ろう。ワンナイト BootCamp!』という勉強会に参加したのだけど、Kubernetes の基礎がそもそも分かっておらず、うまく知識を持ち帰れなかったので……。

いざ本を読んでみたら「あ、あの勉強会で言ってたやつだ!」的なアハ体験があり、理解が進みました。

cnd.connpass.com

いつもの読書メモはこんな感じ。

Docker をちゃんと理解して使いたい人や、(コンテナ技術を使うことを前提として)インフラ寄りの話にもうちょっと詳しくなりたい人は読んでみるといいんじゃないでしょうか。

『Vue.js入門』を読んだ

  • 趣味で作った GAS が限界を迎えたので、いい感じの Web アプリケーションに作り変えたい
  • せっかくなので今風のフロントエンド技術を使った SPA にしよう
  • 最近新しいこと学んでないのでついでに色々試してみよう

みたいな背景から、ちょうど気になっていた Vue.js に入門してみました。

Vue.js入門 基礎から実践アプリケーション開発まで

Vue.js入門 基礎から実践アプリケーション開発まで

フロントエンド開発の知識はちょうど jQuery で止まってて、ES2015 とか webpack とか AltJS とかなんもわからん、みたいな感じだったんだけど、まさにそういう初学者向けに書かれた入門書になっていて、驚くほどサクサク読めました。双方向バインディングすごい。俺は今まで jQuery でコソコソと何をやっていたんだ、という感じ。

あとは、「便利になったもんだ」という感想を持った一方で、「フロントエンド側の業務領域って随分増えたんすね」とも思った。昔はルーティングの制御とかはサーバ側のお仕事だったのにねえ。フロントエンドエンジニアの気持ちがちょっとだけ理解できました。

で、この本と『サーバーレスシングルページアプリケーション』のおかげで人生初の SPA をサクッと実装してデプロイするところまでいけました。作ろうとしてたものの性質的に DynamoDB とかを使うのがマッチしなくて、結局サーバレスな構成にはしなかったんだけど、こちらも良書だったのでリンク貼っておきます。

いつもの読書メモはこんな感じ。

「Vue.js の高度な機能」「Vuex によるデータフローの設計・状態管理」あたりは読み飛ばしちゃいました。必要になったらまた読むかも。

そんな訳で、

  • フロントエンド開発の流れに全然ついていけてない
  • でももはやどこから手をつけていいのか全然わからない
  • 本職はサーバサイドエンジニアだけど、フロントエンドの技術要素についても知っておきたい

みたいな人は手に取ってみるといいんじゃないでしょうか。

この本を参考に作った SPA の話はまたいずれ。

2018年の振り返り

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

去年やってみたら意外とよかったので今年も振り返りを書いてみる。日々撮り貯めていたウニの写真と共にお楽しみください。

インフラ面でできることが増えた

f:id:gushernobindsme:20181231210402j:plain

今年はちょうど、小規模な Web アプリケーションのインフラをイチから自分で設計・構築してみる、という機会に恵まれて、これのお陰で AWS インフラの理解が進んだ。VPC 切って、サブネット切って、NAT ゲートウェイとインターネットゲートウェイをアタッチして、ルートテーブル設定して……みたいなところって、実際に自分でやってみないとなかなか理解できないところだと思うんだけど、実業務でそれを経験できたのは非常にラッキーだった。ネットワークを基礎から学び直す時間が作れたのもよかったです。

gushernobindsme.hatenablog.com

あとは、AWS ソリューションアーキテクト・アソシエイトを受けてみたりもした。試験対策はある程度必要になるけれど、AWS のインフラ知識を体系的に身につけられる良い試験でした。

gushernobindsme.hatenablog.com

上期できちんと基礎を身につけられたお陰で下期からはインフラの改善業にもきちんと参加できるようになって、既存のサーバのSSL 証明書を Certificate Manager に総入れ替えしたり、一部のサーバを ECS に移行したりしてました。特に ECS は、実際に手を動かしてみることでクラスタ・タスク・サービスの関係性がちゃんと理解できて、とても勉強になりました。老害にならないで済みそうでよかった。

写真は『うに小屋』渋谷店のウニ4種盛りです。

アプリケーション面でできることが増えた

f:id:gushernobindsme:20181231210358j:plain

REST API の勉強をやり直したり、モバイルアプリ向けのエンドポイント群を一揃い設計する仕事を取りに行ったりしたお陰で、去年よりは API 設計をちゃんとできるようになった。特に『Web API: The Good Parts』をきちんと読み直したのが奏功したかなあと思っていて、仕様の妥当性を第三者にきちんと説明しきれるエンドポイントが作れたと思う。

gushernobindsme.hatenablog.com

去年はハチャメチャなエンドポイントを実装してはハチャメチャに直される、みたいな状況を繰り返していたので、今年はそれが改善できてよかったかな。

写真は中目黒のお寿司屋さん『鮨 尚充』のウニ三種盛りです。

外部の勉強会で登壇できた

f:id:gushernobindsme:20181231211332j:plain

今年は FinTech Engineers Drink Up というイベントにお誘いいただいて、人生初の登壇を経験することができた。「30 歳になる前に勉強会の登壇ができるエンジニアになる」という夢が叶ったのがエポックで大変よかったです。「また一緒に何かやりましょう!」と言ってもらえたのもすごく嬉しかった……引き続き頑張ります。

fintech-engineers-drink-up.connpass.com

写真は恵比寿に店を構える『ALMA』にて期間限定で開催されたウニ祭りの様子です。

その他

f:id:gushernobindsme:20181231195536j:plain

あとはなんか散文的なことをいくつか。去年ぼんやり考えてたこととしては、大きくは三つあって、

  • 自分で責任をもつ、自分で決める
  • どうやったらフェアになるか考えてみる
  • 「自分が何が得意か」の解像度をあげる

こんな感じ。一度つらつら書いてみたんだけれど、全然まとまりそうにないのでまた今度気が向いたら書きます。あとは、ハーフマラソンを無事完走したり、ベンチプレスで 50kg × 5 レップ上がるようになったり色々ありました。

写真は新宿三丁目『いちりん』の名物、雲丹しゃぶしゃぶの〆の雑炊です。

終わりに

意外と 去年の宣言 通りに、サーバサイドの設計・開発力と AWS 力にステ振りする一年になったかなあ、と思います。様々なしがらみがあって、なかなか色んなものを早く作れずにいるけれど、引き続き頑張ろうと思います。

来年もたくさんウニを食べたいですね。おわり。

『Web API The Good Parts』を読んだ

API の設計する機会も増えてきたので。これまでにも何度かリファレンス的に読んでた本なんだけど、微妙に誤読してるところとかあって、そういうんじゃダメだよね、と思って通読してみました。API 設計におけるバイブル的な一冊。

Web API: The Good Parts

Web API: The Good Parts

  • エンドポイントの URI はどんな感じにしたら分かりやすい?
  • レスポンスデータはどうするのがベスト?
  • クライアントに対するエラー表示は?
  • セキュリティ的に気をつけるポイントは?

などなど、API を設計する際に悩むポイントは色々あると思うんだけど、『Web API The Good Parts』では、「広く公開されている API ではどう対応しているか」「HTTP の仕様と照らし合わせて適切か」を分かりやすくまとめてくれていて、設計思想の拠り所になってくれる。

オライリーの本だけど、変な日本語訳もなく、ページ数も 200 ページと少なめなのでとても読みやすい。とても有名な本なので Qiita に要約があったり、ブログにまとめが載っていたりするけれど、この本については原典にあたることをオススメします。手元に置いておいてチラ見するのでもいいけど。

尺が余ったので目次を引用してお茶を濁します。

  • Web API とは何か
  • エンドポイントの設計とリクエストの形式
  • レスポンスデータの設計
  • HTTP の仕様を最大限利用する
  • 設計変更をしやすい Web API を作る
  • 堅牢な Web API を作る

いい章立てですね。読書メモ置いておきます。

API 設計についてモヤモヤした気持ちを抱えている人は手に取ってみるといいんじゃないでしょうか。

『合格対策 AWS 認定ソリューションアーキテクト・アソシエイト』を読んで AWS SAA に合格した

経緯

AWS は実務で触っていて、なんとなく使えてはいるんだけど、

  • 「なんとなく使える」の域から脱したい
  • AWS についての体系的な知識を獲得したい

ということで AWS SAA(ソリューションアーキテクトアソシエイト)試験を受けてみました。

試験受けるなら対策本買わなきゃね、ってことで手に取ったのがリックテレコムの『合格対策 AWS 認定ソリューションアーキテクト・アソシエイト』。おそらく、現時点で唯一の AWS 試験対策本です*1。この本なしでは合格できなかった……出版してくれてありがとう……。

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

やったこと

受験するにあたって、まずは『合格対策 AWS 認定ソリューションアーキテクト・アソシエイト』を読了。AWS の用語の説明だけに終始せず、クラウドでシステムを構築する上で重要な考え方についてもしっかり書かれているため、すんなり読めた印象。最新のサービスについては言及されていないものの、基礎を身につけるにはとても良い本でした。

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

で、早速 AWS のサイトから模擬試験を受験してみたんだけれど、これが全然答えられない。全然わからない、ってほど致命的ではないんだけど、自信を持って答えを選べない感じ。で、試験対策の定石通り問題演習やんなきゃだめかなあ、と思っていたところいいサイトが見つかったので、ひたすらここで問題を解いておりました。

aws.koiwaclub.com

ある程度「量」を解いておきたかったので、上記のサイトのシルバープランに加入。1,580 円を Stripe 経由で支払うと、サイト運営者が作成した 120 題のオリジナル問題が解けるようになります*2。やってみたらまあ、結構解けなかったので、不正解だった問題の解説文をまとめて、こちらも markdown を gist にあげて眺めることにしました。

で、いけそうかな?という自信がついてきたので秋葉原の試験会場を予約して受験。5/1 に無事合格判定をもらえました。すごいあっさりしたメールで通知が来るのでちょっと不安になる。

反省点とか

  • 合格こそしたからいいものの、正答率があんましよくない(65%)
  • とはいえ、 gist になんでも残す作戦は試験対策でも有効っぽい
  • 模擬試験に 2,160 円、WEB 試験の有料会員登録に 1,580 円かかるが、とにかく金をケチらないことが合格の秘訣
  • AWS 認定ソリューションアーキテクト – アソシエイト (新版)』というのが 2018 年 4 月付でリリースされてるんだけど、チキって古い方を受けてしまった
  • 老害になりたくない人は新しい方を受けましょう

お仕事に活かせるといいですね。おわり。

*1:AWS 界隈は機能のバージョンアップが多く、新しいサービスも次々にリリースされるため、対策本をなかなか出しにくい、というのが現状みたい

*2:その上位ランクのゴールドプラン、プラチナプランというのもあるらしい。やってみてないけど

『安全な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 を実践することはまだできていないんですが、引き続きやっていこうと思います。おわり。