泥水エンジニア日記

泥水の数だけ強くなれる

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:したことない人はすみません。優秀なんですね

『エリック・エヴァンスのドメイン駆動設計』を読んだ

会社の先輩にオススメされたので読んでみた。抽象的な話が多くて読むのにものすごい時間がかかったんですが、読んどいてよかった。良書でした。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

そういえば設計ってよくわかってなかった

最近、自社のサービスのコア部分に関するコードをリプレースすることになり、「どうせ書き換えるのであれば、もっと分かりやすくしよう!」と息巻いていたんだけど、コードを書けども書けどもいい感じにならない。綺麗にまとまった!と思った先から情報がもつれてしまう。試行錯誤しながら何とか形にしたんだけど、「何の業務のために何をしているのか」がどうにも分かりにくく、レビューでめちゃめちゃ指摘を受けてしまった。

何でこんなにうまく行かないんだ?と思ったけれど、考えてみれば当然で、そういえば自分はちゃんと設計について学んだことがなかった。

クソ文学部なので、こういう時は本に頼ります。

エリック先生の教え

エリック・エヴァンスが書いていることをすげーざっくりまとめると以下のような感じ。

  • ドメインの実践者(OpsとかBizとかの人)とソフトウェアの実践者(Devの人)による創造的な共同作業を通じて、モデルを探求すること
    • ソフトウェアに現実世界の情報を何でも何でも反映させる必要はなくて、「業務を回す上で重要な情報か」という切り口で取捨選択して、シンプルに抽象化することが大事
    • 良いモデルを見つけるためには、自分たちの知識を意識的に育てて、「継続的学習」を実践することが大事
  • コアドメインに集中すること
    • コアドメインとは、アプリケーションを差別化して価値あるものにする、モデルのもっとも特徴的な部分のこと
    • コアとそれ以外を分けることで、最も価値のある領域に作業を集中させることができる
    • 逆に、本質的じゃない部分について、優先度を下げたり、アウトソーシングしたりする際の指針になる
  • 明示的な境界づけられたコンテキストの内部で、ユビキタス言語を語ること
    • ドメインエキスパートとエンジニアが会話する際は、「この業務についてはこう表現しよう」と決めた共通言語(ユビキタス言語)で話すこと
      • ユビキタス言語が浸透して、会話上でもコード上でも使われるようになると、エンジニアがドメインエキスパートに自分の成果物を見せられるようになる
      • フィードバックループが二者間で完結するようになるので、スピード感を持って開発できる
    • 境界づけられたコンテキストとは、モデルを適用できる限定された範囲のこと
      • ボーダーラインを定めることで、チームメンバは何を一致させるべきで、何を独立して開発できるのか、について理解を明確にできる
      • マイクロサービスにおける、「サービス」の単位と一致させると良さそう?

分かったような気はするけれど、まだ全然実践できる気はしていないので、次は『実践ドメイン駆動設計』を読んでおきたい。

以下、自分用の読書メモです。

『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』を読んだ

転職してからコードレビューを受ける機会が結構増えたんだけど、コードの「読みやすさ」に関する指摘をもらうことが結構多く、いいコードを書きたいなー、というかそれ以前にレビュアヘの負荷を減らしたいなー、と思って読んでみた。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

まずはみなさん本の概要を知りたいと思うんですが、訳者の前書きに概要がすごく綺麗にまとまっていたので、引用で楽をします。

タイトルが示す通り、本書のテーマは「読みやすいコード」である。
(中略)
「読みやすい」コードを書くのに「面白い」ことをする必要はない。いい名前をつける。適切なコメントを書く。意味のある単位に分割する。キレイに整形する。こうした基本的なことを着実にやればいい。このことを丁寧に説明してくれるのが本書である。

プログラマなら誰しも、わかりやすいコードを書きたい、という気持ちを持っていると思うんだけど、「じゃあどうすればいいのさ?」って聞かれると案外答えるのが難しい。そういった、言語化しにくい「読みやすさの指標」みたいなものを、この本は明確にしてくれる。

で、この本のどこが面白いのかについてですが、これも前書きに全部書いてあります。
無能なのでそのまま引用します。

本書が面白いのは、アドバイスの仕方がいいからだと思う。よくありがちな「コードはこう書きなさい」という説教じみたものじゃなく、かといってふざけたものでもなく(挿絵はふざけてるけどな!)、先輩から「こうした方がいいよ」と優しくアドバイスを受けているような感じがする。説明用のサンプルコードも豊富だし、今日からすぐに使えるヒントも満載だ。

書いてある内容もそんなにヘビィじゃなく読みやすいので、コードレビューでもやもやしてる人や、僕みたいに本棚に死蔵してた人は読んでみるといいんじゃないでしょうか。
以下は自分用の読書メモです。

『Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング』を読んだ

Java SE7 までは経験ある人が SE8 の知識をつけるのに良い本ないかなー、と本屋を徘徊していたところ見つけた一冊。表紙はかわいいですが、中身は結構えぐくて、読み応えばっちりです。

いまさら僕が説明するまでもなく、 Java SE8 では、

  • Lambda
  • Stream
  • Optional
  • Date And Time
  • Completable Future

など、プログラミング言語やライブラリの機能が大幅に追加されています。

が、この辺のパラダイムについていくのって結構大変で、いつもの手癖で for 文書いたり if null 書いたりしがちだったりする。この本では、そういうプログラマのために、Java8 を導入することでコーディングスタイルがどう変わるか、 before と after を提示してくれるのでものすごくわかりやすい。after の形に書き換えることでどういうメリットがあるか(並列処理が高速になる、直感的なコードになる、など)とかもしっかり書かれてて便利。古の Java プログラマー老害化から救う本としては、これ以上の入門書はないんじゃないだろうか。

翻訳書特有のクセはちょっとあるけど、文章は簡潔で読みやすい。

純日本製の技術書と比べるとコードサンプルはやや少なめだけど、地道に写経しながら読み進めていくことで、 Java SE8 の考え方がしっかり身につく良書でした。老害にならずに済みそうでよかった。

以下はお勉強用のリポジトリです。

github.com