冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

2018/5に読んだ本

今月は少し少なかったです。大物があったのと、ちょっとプライベートの諸々が重なっておりました。

仕事面では、AWS Batchを使って連携基盤を作ってたり、ちょっとエンジニアリングによったことをしてます。可能な範囲については発信できたら良いなあ。

先月読んだ本

印象に残った本

フィクション

WOMBSですね。ちょっと他のを優先させていて間が空いちゃったんですが(テーマが重いというのもちょっと)、いい感じのタイミングだったので。

WOMBS 3 (IKKI COMIX)

WOMBS 3 (IKKI COMIX)

WOMBS(4) (IKKI COMIX)

WOMBS(4) (IKKI COMIX)

まだ最終巻にたどり着いていないので、全体的な感想はまだ保留したいと思いますが、作中の男どもの考え方のエグさに結構ムカついております。自分が男だからというところもあるのでしょうが、あまり冷静に語れるタイプの作品ではない気もしてます。

ノンフィクション

「エンジニアリング組織論への招待」と「ティール組織」をようやく読みました。ただ、これは近いうちに何度か再読するだろうなあ、というのが予測できていたため、まずは読み切ることを重視した読み方です(通読した結果、予測は当たってました)。

まず、「エンジニアリング組織論への招待」については、Chapter 1以外はかなり実務的な本だと思います。ここでいう「実務的」とは、問題を捉えるために実務的ということです。私にとって特に新鮮だったのはChapter 2とChapter 5で、これは単純に今までしっかりと追いかけてこなかった領域だったからなのですが、具体的に問題を捉えるためのモデルや考え方がキャッチアップできました。

そして、「ティール組織」ですが、これはしばらくDDDが初めて日本で出版されたときのような扱いになるのではないかな、と思います。新しい組織の形について、著者もまた捉えきれてないのは明らかです。が、明らかに著者の中には同時に「この形がくる」というビジョンだけはあって、なんとかロジックとしてつかもうとしているという印象。言ってみればスピリチュアルな本な訳ですが(表現的にも)、それを踏まえた上で自分の思う組織について考えながら読むのがいいと思います。誤解しないで欲しいのですが、この本には読む価値はありますよ。

ティール組織――マネジメントの常識を覆す次世代型組織の出現

ティール組織――マネジメントの常識を覆す次世代型組織の出現

2018/4に読んだ本

やはりゲームがないと読書が捗りますね。今月は漫画が多かったですが。

先月読んだ本

印象的な本

フィクション

フィクションが非常に収穫多かったです。もともと追いかけていたダンジョン飯とランドの最新刊は安定の面白さだったのですが、それ以外に良かった作品もほとんどがあたりという確変月。

ダンジョン飯は若干当初の趣旨から離れていっている感があって、その意味でドラゴンボール的な流れを思い起こさせます。メインキャラクターがライオスのサイコパスっぷりに慣れてきてたところなので、新しいツッコミ役が来たのは良かったと思います。というか、このサイコパスが主人公で大丈夫か?

ダンジョン飯 6巻 (ハルタコミックス)

ダンジョン飯 6巻 (ハルタコミックス)

ランドは、世界の内情が少しずつ見えて来た感じですね。どこに着地させようとしているのかはまだわかりませんが。続きが楽しみです。

ランド(6) (モーニング KC)

ランド(6) (モーニング KC)

そして、唐突に出会った「ズルい枠」。ダンジョン飯に初めて出会った時のような感覚でした。同じ事象が異なるスケールで描写されるだけで、こんなにも感覚にズレが出て来て面白いのか、と思わせる作品。

超人間要塞 ヒロシ戦記(1) (イブニングコミックス)

超人間要塞 ヒロシ戦記(1) (イブニングコミックス)

それから、何と言っても「プシスファイラ」ですね。Kindle Unlimitedにあったので何気なく読むリストに放り込んでいたのですが、これがまた注釈も含めた情報量的に偏執狂としか言いようがない感じで。内容としてもディアスポラに行き着くまでという世界観で良いです。ネットワークに対して深い知識を持っていると思われるので、その点でも読み応えあり。

プシスファイラ

プシスファイラ

後は、「水上悟志短編集 放浪世界」と「怪盗ルパン伝 アバンチュリエ」と「甘々と稲妻」が良かったですね。いやあ、あたり月です。

「虚無をゆく」がとにかく良い。

ルパン作品はあまり読んだことがないので、新鮮でした。

ちょっと「うさぎドロップ」あたりにも感じが似てて好きです。

ノンフィクション

読み物系ノンフィクションかな?と思ったら、案外ビジネスにも使える本だったのが「ダンナ様はFBI」でした。文章も軽めなだし、Kindle Unlimited契約している方は読んでみてもいいと思います。

ダンナ様はFBI (幻冬舎文庫)

ダンナ様はFBI (幻冬舎文庫)

「サーバントであれ」は、サーバントリーダーが必要な理由についての説明が中心の小論集でした。いい本でしたが、若干今求めているものとは違うかな、と。サーバントリーダーシップの方を読むべきか。ブックオフで見つけたのがこっちだったので文句は言えませんが。

サーバントであれ――奉仕して導く、リーダーの生き方

サーバントであれ――奉仕して導く、リーダーの生き方

2018/3に読んだ本

先月は大物が多くて、あまり数読めませんでした。

妻の退院とその辺に関わる諸々が少し落ち着いてきて、生活サイクルも少し落ち着きました。

先月読んだ本

印象的な本

フィクション系

先月読んだフィクションと言えば「イルミナエ・ファイル」一作なんですが、これがすごくいいです。お値段張るから文庫待ち、とか思ってるそこの諸兄、この本絶対に文庫化されないと思うので今買いましょう。

イルミナエ・ファイル

イルミナエ・ファイル

この本の魅力はなんと言っても、フォーマットから何からこだわって書かれた表現方法と、それを翻訳した執念です。「印刷されたあらゆるもの」に情報量が入り込みすぎて、文章の軽く2〜3倍の情報量があります。SF的に目新しいことがあるわけではなく、むしろオーソドックスな題材の組み合わせですが、この手法をエンターテインメントとして仕上げるためにはこのくらいのベタさ加減でちょうどいいと思うくらい。

ノンフィクション系

今回は全て印象的でした。「Adaptive Code 第2版」については先日書いた記事に任せるとして、他2冊。

mao-instantlife.hatenablog.com

「チームギーク」は今更ながらなんですが、よかったですね。ただ、自分がマネージャの仕事として思ってたあれやこれやがリーダーの仕事となっていて、マネージャ・リーダー観ってのはまだまだ人によってブレがありそうだな、と感じました。どんなつもりでその人が説明しようとしているのか、というのは話聞くときに考えておいた方が良さそう。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

「会社を育てる戦略地図」は、これからのキャリアパスで捉えた方がいい本だと感じました。自分がいる会社がどのフェーズにいるのか、は別に経営者だけの話ではなくて、社員としても要求される振る舞いに合わせないと評価されない、という話になりますので。

0 to 100 会社を育てる戦略地図

0 to 100 会社を育てる戦略地図

Serverless Application Repositoryからデプロイしたアプリケーションのアップデートを試す

まだ検証したいことはいくつか残っていますが、話題としてキリがよくなってきたので一旦エントリにまとめます。

Serverless Application Repositoryとは、っていう話はこちらから。

dev.classmethod.jp

アプリケーションの公開も、既に記事になっています。

dev.classmethod.jp

で、こういうのを見るとアプリケーションのライフサイクルとか更新時どうなってるんだろう、とか諸々考えてしまう性癖なのが私です。

やること

  • テスト用のアプリケーションを公開してデプロイ
  • アプリケーションの変更をして公開しなおして(同じスタックに)デプロイ

のライフサイクルを実際にやってみて、以下の点について現状の仕様を確認してみようと思います。

  • デプロイ済みアプリケーションへの更新通知とか
  • アプリケーションの更新手順

これからやりたいこと

以下はこれから検証したいこと。

  • デプロイした後にCloudFormationの設定を変更してからアプリケーションの更新
  • デプロイした複数のアプリケーションを取りまとめて一つのアプリケーションにするための良いプラクティスの模索

検証

さて、ここから検証です。

アプリケーションの1stバージョンのpublishとデプロイ

これについては先ほどあげたクラスメソッドさんの記事のママで問題ないでしょう。

dev.classmethod.jp

この記事の通りにやらなかったこととか、書かれていない範囲での気づきは以下の通りです。

  • デフォルトでの公開範囲はプライベートで、その場合は作成アカウントから同リージョンのLambdaにのみ作成可能
  • 公開でpublishされたアプリケーションは東京リージョンのLambdaへもデプロイ可能
  • ライセンスは一度publishすると編集できないっぽい
  • デプロイ時にAuthorizerの追加とかデプロイのカスタマイズの設定がない

今回は、適当なJSONレスポンスを返すものを作ってみました。

github.com

で、デプロイした時のスタックログとLamndaのテスト実行の結果は以下です。

f:id:mao_instantlife:20180324053609p:plain

f:id:mao_instantlife:20180324053626p:plain

SAMアプリケーション前提とはいえ、Lambdaのコンソールからデプロイなんだなあ、と少ししっくりきていないところです。

2ndバージョンのpublish

さて、実際のアプリケーションの運用においては、一度publishされたアプリケーションが更新されないことはないと思いますので、アプリケーションを変更してみます。DynamoDBをリソースに追加して、JSONレスポンスに追記してみました。これを、新たなバージョンとしてpublishしてみましょう。

新しいバージョンを追加するには、リポジトリの「マイアプリケーション」からpublish済みアプリケーションのページを開きます。右側のバージョンリストに「新しいバージョンを発行」というボタンが出てるのでそれをクリック。

f:id:mao_instantlife:20180324053738p:plain

新しいバージョン番号とyamlを指定します。

f:id:mao_instantlife:20180324053754p:plain

「公開バージョン」をクリックすればpublishされます。

2ndバージョンの更新検知の有無を確認

デプロイ済みのアプリケーションに何か通知があったりするかなあ、とか思ってしばらく待っていたのですが、そんなことはありませんでした。

まあ、パッケージリポジトリとパッケージの関係のようなものなので、リポジトリからプッシュ通知みたいなことはしないのでしょう。ましてや問答無用でバージョンアップとかされても怖いですし。

2ndバージョンのデプロイ

同じアプリケーションに更新デプロイしてみます。ここがまだ流れとして不自然だな、と感じたところ。

CloudFormationのスタックからはリポジトリ参照で更新みたいな流れは見つけられなかったので少し逡巡してしまいました。結論としては、Lambdaから新規関数の作成に進んで、リポジトリから選択、スタック名を同じにしてデプロイするという感じです。

f:id:mao_instantlife:20180324054012p:plain

デプロイ済みの関数が更新され、関連するCloudFormationスタックのリソースやイベントが更新されています。

f:id:mao_instantlife:20180324053934p:plain

まとめ

このリポジトリに公開できるのはSAMなので、どちらかというとこれだけで完結するというよりは、gradleやmavenやGemのようにパッケージとして扱って組合わせてアプリケーションを構築する、みたいな未来をAWSは想像しているはずです。そういう未来になるのは、まだアプリケーションのライフサイクルだったり、パッケージ管理に相当するものだったりが足りないなあ、という印象。同じスタックで新規作成というのも少し迷いました。

ただ、この辺は順次解決されていくでしょう、AWSですから。CloudFormationがServerless Application Respositoryに対応して、パッケージマネージャみたいな位置付けになっていくんじゃないかな、と思います。パッケージマネージャ的なものを自力で作るという手もありますが(Serverless Frameworkのプラグインとか?)。

Adaptive Code 第2版を読んだ

長澤さんよりご恵投いただきました(厳正なる抽選の上)。多謝。

Adaptive Code ~ C#実践開発手法 第2版 (マイクロソフト関連書)

Adaptive Code ~ C#実践開発手法 第2版 (マイクロソフト関連書)

3行所感

所感

本の内容をなぞるだけのレビューは大嫌いなので、ここは読みながら私が感じたことを書いてみたいと思います。

コードは書いた瞬間から鮮度が落ちていくもので、それに抗う必要がある

致し方ないことですよね。プロダクトが未来永劫同じ使われ方をして、同じニーズにこたえ続けるわけではなく、ユーザや市場も変化し続けているわけです。そのため、プロダクトが果たさなければならない役割も変化し続ける。

で、これも仕方のないことですが、コード自体はリリースしたタイミングを起点に次のリリースまでどんどん鮮度が落ちていきます。書き逃げのようなプロダクトならともかく、ユーザとともに育っていくつもりのプロダクトなら、この変化に対応しないといけないわけです。本書ではこの変化に対応しやすいコードのことを「Adaptive Code(適応的なコード)」と称しているわけです。

そして、これにどうやって抗うのか、ということが書いてあります。中でも重要なポイントは以下の3点だと思いました。

  • 適時にリリースできるようにする
  • コードの上でも抽象と具象を分ける
  • 抽象ベースに依存関係を作りやすい構成にする

デリバリーフレームワークという言葉と構成に感じる強い意志

「Adaptive Code」というタイトルながら、本書の頭1/3くらいは「デリバリーフレームワーク」と表現された開発プロセス(Scrumとカンバン)と、コードの配置の仕方について力を入れて書かれています。いうなれば兵站に相当するようなことなわけですが、具体的なコーディングテクニックの前にやるべきこと、考えることについて目を向けており、章立てから非常に強い意志を感じる構成です。個人的にはやっぱりカンバンが好きだなあ、と思いました。

それはそうと「デリバリーフレームワーク」というのは良い表現ですね。コードもデリバリーも適応的にいくべきだ、という思いを感じる表現です。著者がカンバンを成熟したチームのためのフレームワークと表現しているのは、カンバンの方がよりシンプルでかつ適応的であると考えているのでしょう。

ただ、カンバンのところにある「サービスクラス」と「SLA」の例えは、ちょっと唐突な感じがしました。このところは理解するのに少し時間がかかったというか、まだちゃんと理解できているか怪しいところです。

すべてはインターフェイスのために(違

Javaを使い始めのころは、インターフェイスの利点をよくわかっていませんでした。そのころに入った案件では、結構うまくインターフェイスを利用していたのですが、「どうせ実装クラス出てくるのにぶっちゃけ邪魔だなー」としか。それからデザインパターンを知り、インターフェイスを使って柔軟性を確保する方法を知り、今となってはインターフェイスの恩恵を受けないことなど考えられないくらいです。

で、本書では、段階的にその利点を感じながら使いどころを抑えていくためのサンプルとコーディングテクニックにあふれています。それはもう、インターフェイスを使いやすくするために各種パターンやコーディングテクニックがあるのだ、と言わんばかり(あくまで「言わんばかり」ですよ)。

まとめ

長澤さん、ありがとうございます。とても良い本でした。

初学者の段階からすべてを把握することは厳しいかもしれませんが、備えておくべき資質になると思うので、早いうちから読んでいく本だと思います。また、C Sharpに限らず(第2版は原題から外されている模様)、オブジェクト指向言語を扱ってコードを書いている人には有用な本だと思います。