えらちおごはん

汚ねえメシ画像と学んだことのメモ

コード供養としての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

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

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

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

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

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

以下、読書メモです。 gist.github.com

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

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

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

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

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

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

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

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

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

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

エリック先生の教え

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

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

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

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

gist.github.com

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

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

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

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

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

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

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

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

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

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

gist.github.com

『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

『SpringBootプログラミング入門』を読んだ

仕事でSpringBoot使うことになったので読みました。

SpringBootプログラミング入門

SpringBootプログラミング入門

これでもか、ってくらい丁寧に書かれてるので、置いてけぼりを食らう心配がなく、安心して読めます。とはいえ、クラス作成するときのEclipseの操作方法、とかのレベルまでつぶさに書かれてるので、超初学者とかでない限りちょっと鬱陶しいかも。
津耶乃先生の本を読むのは『新人プログラマのためのjQuery Webアプリケーション開発講座』に次いで二冊目なんだけど、この人の本の良いところは、肩肘張らずにカジュアルに読めるところ。体系的な知識は欲しいんだけど、オライリー本読むのは敷居が高いんだよな……って気分の時に重宝すると思います。

新人プログラマのためのjQuery Webアプリケーション開発講座

新人プログラマのためのjQuery Webアプリケーション開発講座

SpringBootに関しては、

  • コード書く量をとにかく減らそう、という思想が良い
    • RestAPIがびっくりするくらい簡単に書ける
    • Spring Data JPAを使うことで、CRUDも超簡単に書ける
    • Ruby on Rails的なアソシエーションの仕組みもある
  • 設定ファイルだらけの開発から、アノテーションを使った開発へシフトしているのが良い
    • applicationContext.xmlと戦わなくて済むのが嬉しい
  • 各種構文が2.x系の時代からかなり変わっている
    • とはいえ、SpringFrameworkの経験があれば大騒ぎするほどのことじゃない気がする
    • 他のSpringシリーズと組み合わせて使えるので、Struts2やMyBatisを一生懸命組み合わせるよりシンプルにものが作れそう

だいたいこういう印象。SpringCloudConfigとか、Spring関連のフレームワークの知識をちゃんとアップデートしたいので、次はその辺の本を読んでおきたいです。
で、以下は読書メモ。Spring Tool Suiteに関する記述は読み飛ばしてます*1gist.github.com

*1:EclipseからIntelliJの軍門に下ったので……

無職活動報告

2月の中旬から始めた無職生活ですが、GW明けから働き始めることになったため、そろそろ終わりを迎えようとしています。
無職の間に何をして、何を考えていたかを「無職活動報告」としてここに書き残そうと思います。

転職活動

f:id:gushernobindsme:20170504221358p:plain 新卒の就活で苦労した方だったので、「転職活動やりたくないなー」という気持ちが強かったんだけど、やってみたらこれが意外と楽しかった。そう感じた大きな要因としては、

  • 自信を持って話せる経験がある
  • 学生時代なら相手してもらえなかった会社の人に会える
  • 因果関係がちゃんとわかる

というところが大きかったように思う。

自信を持って話せる経験がある

学生の頃は、学生時代に打ち込んだと言い切れるほどの経験が正直なくて、
「この話したら響くかな?」
みたいなエピソードを自分の経験から必死で探して、ひねり出して、それっぽく話すしかなかった。結局、フルタイムで働いた経験は学生にはないので、想像でやっていくしかなく、それは周りの学生も同じのようで、巷にはいわゆる「納豆人間」*1が溢れていた。

転職活動では、この点が大幅に改善された。
実務で実際に経験してきたことを話せるので、ものすごくやりやすいのだ。

  • これまでで一番やりがいを感じた瞬間は?
  • これまでに一番苦労したことは?
  • その経験から学んだことは?

こういったお決まりの質問が、これまでの実務経験から、具体的なエピソードを踏まえて、間にちょっと冗談を交えたりしながら話せる。話せることが無限にある、というのは新卒就活で苦労した人間からすると革命的で、「強くてニューゲーム」してるような気持ちになれた。

学生時代なら相手してもらえなかった会社の人に会える

自分は文系大学の出身だったので、技術系の仕事に就きたい、と思って履歴書を送っても結構な確率でお祈りされてしまうことが多かった(とはいえ、趣味プロダクトとかちゃんとやってる人であれば、その限りではないと思います)。

ただ、転職活動だと、大学での専攻よりも前職でのキャリアに目が向く。
職務経歴書をかなり気張って書いておくと、学生時代に書類段階でスルーされていた、憧れのイケイケな会社の会議室に通されたりするので、未来が開ける気持ちになると思う。

因果関係がちゃんとわかる

楽しい気持ちで活動できた一番の要因は多分これ。

転職活動では、基本的にみんなエージェントをつけて活動をすると思うんだけど、このエージェント氏がめちゃくちゃ優秀で、

  • 履歴書、職務経歴書の添削をしてもらえる
  • 書類審査で落ちた理由をフィードバックしてもらえる
    • メインで使ってる言語の経験が浅い、とか
    • 目的としてる人材を採用できたので募集自体を打ち切った、とか
  • (本人が希望すれば)面接対策をかなり丁寧にやってくれる
  • 面接で落ちた理由のフィードバックをもらえる
    • 人柄はいいんだけど筆記課題の点数がだめ、とか
    • 経験とかに問題はないんだけど、社内でポジションを用意できなかった、とか

この人がいてくれるだけで、ざっと、これだけのメリットがある。
就活自殺の背景には「落とされた理由がよく分からない」「自分のこれまでの人生を全否定されたような気持ちになる」ということがあったと記憶しているんだけど、エージェント氏がいれば、そういった不安とは概ね無縁でいられると思う。

あと、面接が通過した場合にも「どういう点が評価されたか」のフィードバックがもらえるし、企業の人材募集の背景なんかも教えてもらえるので、「自分をどう見せるか」みたいな作戦もめちゃくちゃ立てやすい。

で、上記のようなストレスフリーな環境で活動できるおかげで、自己分析にちゃんと時間をかけられるようになる。例えば、

  • 何をやってる時に喜びを感じるのか
  • 今後、どういうキャリアパスを歩みたいのか
  • 3年後、5年後どうなりたいのか

みたいなことって本来はめちゃめちゃ大事だったはずなんだけど、大人になると、目の前の仕事をこなすのに忙しくなって、だんだんと忘れていってしまう。さりとて、学生時代には「そんなん言われてもわかんねーよ」って感じだと思う(そうじゃない人はすみません)。

忘れてしまった「本当はこうありたかったはずだよな」という気持ちを思い出せただけでも、無職期間と、そこからの転職活動には意義があったと思う。

筋トレ

f:id:gushernobindsme:20170504221403p:plain ガリガリな体に対するコンプレックスを解消したかったので、ジムに通い始めた。
筋トレの良いところとしては、代謝がよくなって痩せる、単純にかっこいい体になれる、というのももちろんあるんだけど、副次的な効果として、

  • 自分の体調の良し悪しが分かるようになる
  • 胸を張って生活できるようになる

みたいなところもあると思う。

自分の体調の良し悪しが分かるようになる

これまでは、なんとなく体調の悪いような日があっても
「まあ気のせいだろ」
と思って無理をしてしまうことが多かったんだけど、筋トレをするようになると、今日は体調が悪いから休もう、という判断がちゃんと下せるようになる。

判断基準は明確で、普段こなせる運動がいつも通りにできるかどうか。
睡眠不足だったり、食事量が少なかったりすると、いつもなら上げられる重量が上がらなかったり、量をこなせなかったり、反応が分かりやすい形で現れてくる。
ちゃんと負荷がかけられないと、筋肉が育たなくて、フラストレーションが溜まるので、自然と規則正しい生活と十分な食事を意識するようになる、という訳である。筋トレすごい。実によくできてる。

胸を張って生活できるようになる

エンジニアがやっていく気持ちを作るために必要なのは、
「やったことないけどまあ勉強すればできるやろ」
という自己肯定感だよな、と常々思っていて、自己肯定感を健全に醸成するためには、目標の策定と達成の繰り返しが必要だと思うんだけど、そのサイクルをうまく回す仕組みとして、筋トレはものすごく分かりやすい。

目標を数値化しやすいし、できたか/できないかで毎日の効果測定もしやすい。
何より、成果が外見に分かりやすく現れてくるのが抜群に良い。

あと、マシントレーニングをするときの正しい姿勢は「胸を張ること」であることが多くて、「胸を張って生きろ」みたいな言説に「うるせえ」って反発しがちな人も、正しいフォームを学習する過程でちゃんと胸を張るようになる。
色々あって気持ちが落ち込んでいる人は、とりあえず筋トレを始めてみると、根拠は一旦置いといて、胸を張って、前を見て歩けるようになるので良いんじゃないでしょうか。

今後どうするか

面接で、
「自分のなるべき姿になるために何が足りないと思う?」
みたいな質問をされて、色々と思うところがあったので、今後はインプットとアウトプットを頑張ろうと思います。具体的にはこんな感じ。

  • インプット
    • 勉強会ちゃんと行ったりとか
    • 雑誌読んで最新動向ちゃんと追いかけたりとか
  • アウトプット
    • やったことちゃんとブログに残したりとか
    • GitHubにもリポジトリ立てて上げたりとか

現場からは以上です。

*1:「私は納豆のように粘り強い人間です!」という自己PR。亜種として、「人間関係を円滑にする」潤滑油人間、「スポンジのようになんでも吸収する」スポンジ人間などがいたと思う。皆さんは何人間でしたか?