最近読んだ本

最近ちょっと仕事が忙しく, 疲弊気味だったので, ｢業務に活きそう重点｣ではなく｢面白そう重点｣で, Kindle Unlimitedで配信されている本をいろいろ読んでいました. 軽く感想を書きます.

情報なき国家の悲劇 大本営参謀の情報戦記

情報なき国家の悲劇　大本営参謀の情報戦記 (文春文庫)

第二次世界大戦において, 陸軍の情報参謀を務め, 後に陸上自衛隊の陸将補になった堀栄三氏の著書. 第二次世界大戦において, 突然情報参謀に任じられた筆者が, 如何にして情報分析に従事し, 米軍の侵攻パターンを予測するに至ったかについて振り返っている本です. 単純に読み物としても面白いし(戦後の, ドイツ駐在武官としてキューバ危機に対峙した時のエピソードが面白かった), 今に当てはめれば｢内情が見えない競合他社の情報分析｣と言えるので, そういった視点でも示唆がある本だと思いました.

血と汗とピクセル: 大ヒットゲーム開発者たちの激戦記

血と汗とピクセル: 大ヒットゲーム開発者たちの激戦記

｢ディアブロⅢ｣, ｢アンチャーテッド4｣など, 著名なゲームの開発の様子を関係者のインタビューを元に綴った1冊です. 個人的には数年前にハマって遊びまくった｢スターデューバレー｣も取り上げられていたのが良かったです. ゲーム開発も, 自分が従事するウェブサービス開発のようにエンジニア/プログラマーの働きが必要不可欠な職種だけれど, その働き方, 取り組み方などは違っている部分もあって, ｢そういう世界なのか...｣と感じることが出来ました. ｢スターデューバレー｣のように1人で作ったゲームもあれば, 大人数のチームで作ったゲーム, 成功したパターン, うまくいかなかったパターンなど, いろいろな事例が取り上げられていて, 日本の作品は1つもないけれど, ｢ゲーム業界の内情｣というか, その雰囲気を知ることが出来る良い本だと思いました. ゲーム好きには確実にオススメ出来る1冊だと思います.

他...

絶滅できない動物たち――自然と科学の間で繰り広げられる大いなるジレンマ

現代語訳　信長公記 (新人物文庫)

皇国の守護者（全）　１～９＋外伝集 (中公文庫)

...なんというか, かなり雑多に読んでいますね. 引き続き, ちまちま積ん読を消化していきたいと思います.

最近読んだ本たち

転生したらスプレッドシートだった件

転生したらスプレッドシートだった件

カクヨムから生まれた初の技術評論社の書籍, ｢転生したらスプレッドシートだった件｣を読みました. 著者は id:minemuracoffee 先生.

仕事でExcelやGoogle Spreadsheetをバリバリ使いこなしているぜ! という方には物足りない内容かもしれませんが, これから使い始める人, 或いは適当に(他の人が作ったシートを参考にしながら...)使っている人にとってはためになる知見が得られそうと思います. ラノベ形式なのでサクサク読める点もありがたいです. ラノベ形式なので(?), 登場人物たちが関数を技名のように呼ぶわけですが, カタカナで呼ぶのは最初｢なんとなくダサい感じがあるな...｣と思ったりしていました. しかし, よくよく考えると｢この関数を口頭で説明するときにはこう呼べばいい｣というのがわかって逆に便利(?)だ, という事に途中で気付きました.

...あと,お恥ずかしい話ですが, これまで例えば｢A2以降全て｣みたいな指定をするときに, A2:A1000 みたいなのをたくさん書いてましたが, これA2:Aとすると良い, というのはこの本で知りました...

個人的には, 索引というか, ｢この機能はこの章で取り扱っています｣という一覧があれば良かったかな, という気はしています. まあ, 自分の場合は電子書籍版(Kindle)で購入したので, それで検索したら良いのでは? という気はしますが...

外資系コンサルが教える 読書を仕事につなげる技術

外資系コンサルが教える　読書を仕事につなげる技術

同僚の, どなたかのブログで紹介されていて, 面白そう! と思ったところ, Kindle Unlimitedで読めたのでサクッと読んだ本.

著者は外資系コンサルの方なので, 書かれている内容が自分たちのようなエンジニアにそのまま流用出来るか... というとそうではないのですが, その元となる考え方とかは参考になりそう, と思いました.

例えば, ビジネス書において｢ビジネス書は狭く深く読む｣/｢教養書は広く浅く読む｣と良い, と紹介されていますが, これをエンジニアに例えるなら｢ビジネス書｣は言語やアーキテクチャの解説書籍(例えば, ｢初めてのPerl｣や｢エリック・エヴァンスのドメイン駆動設計｣など)は狭く深く, ｢教養書｣は例えば｢WEB+DB PRESS｣や｢Software Design｣などの雑誌, 或いは｢リーダブルコード｣など特定のテーマに沿った本として捉えて, こういったものは広く深く読むと良い... のかな? とか考えることができました.

後は, 割と本を読む時はなるべく全部読もうとするのですが, ｢2割だけ読めばいい｣と書かれていたのも印象深かったです. この辺りは, ビジネス書や教養書だけでなく, エンジニア向けの本でもそうだと思っていて, なんとなくわかっているつもりでも実践出来ていないのですよね...

ちなみに, ｢うまく2割を読む方法｣としては, ｢目次を見る→総括, 結論といった章があれば読む→これを踏まえて面白そうな章の冒頭を読む｣と進み, ピンと来なかったら手を出さない... という方法が紹介されています. 本, 買うと｢もったいない｣という気持ちで読み進めようとしてしまうので(いつも積んでるのに...), こういう考え方は試してみたいと思いました.

既に読書習慣が構築できていて, うまく本を通してインプットが出来ている人からすれば｢そうっッスね｣という内容かもしれませんが, そうでない人にとってはいろいろ気付きがある本なのかな, と思いました. そのまま真似をするのではなく, これを参考に仮説を立てて, いろいろ試してみる... という感じで今後の読書に取り組んでいけたらいいなー, と思いました.

他にも...

戦略思考コンプリートブック

人生は、運よりも実力よりも「勘違いさせる力」で決まっている

ざっくり分かるファイナンス～経営センスを磨くための財務～ (光文社新書)

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

反応しない練習 あらゆる悩みが消えていくブッダの超・合理的な「考え方」

去年から今年にかけて, 上記を含めていろいろ本を読んでいたのですが, 感想をまとめるのを忘れてしまっています. 読みながら/読んだ後すぐに感想とか書かないと, どんどん揮発してしまうので気をつけたいですね. せっかくなので折を見て読み返してみたいと思っています.

小ネタ: PerlのDateTime::Durationで日数の差を出すのはdays... ではなくdelta_days

小ネタです. Perlにおいて時間を扱うライブラリの1つにDateTimeがあります.

metacpan.org

DateTimeには, DateTime::Durationというパッケージがあり, これはある時間Aとある時間Bの間の"期間"を表すものです.

metacpan.org

さて, 今次のようなコードで2020年7月22日と, 2020年7月1日の間の期間(DateTime::Duration)を取得したとします.

my $dt1 = DateTime->new(
    year  => 2020,
    month => 7,
    day   => 22,
);
my $dt2 = DateTime->new(
    year  => 2020,
    month => 6,
    day   => 5,
);

my $d = $dt1->subtract_datetime($dt2);

...なんとなく, ｢じゃあ, ここから日数の差を出すならdaysか...?｣と思ってdaysメソッドを使うと, 次のような結果になります.

print $d->days; # => 3

結論から言うと, DateTime::Durationのdaysや, months/weeksなどのメソッドは, ｢より大きな単位に変換した後の余り｣を出すようになっています.

These methods return numbers indicating how many of the given unit the object represents, after having done a conversion to any larger units. For example, days are first converted to weeks, and then the remainder is returned. These numbers are always positive.

つまりこの｢3｣という数字は, 実際の日数の差17から, より大きな単位である週(= 7日)に変換した余りを表す, ということです: 17 - 14 = 3

実際に, 先の$dt1, $dt2の差となる日数を取得するには, 次のようにdelta_daysを使う必要があります.

print $d->delta_days; # => 17

更に余談ですが, DateTime::Durationにおいてdelta_系のメソッドはdelta_months, delta_days, delta_minutes, delta_seconds, delta_nanosecondsのみが提供されており, delta_hoursは存在しない点には注意しましょう(1敗).

｢Search Inside Yourself─仕事と人生を飛躍させるグーグルのマインド｣を読んだ

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

ちょっと最近, 精神的な面(?)のコントロールが上手く出来ていなくて, そういったことを相談した時に紹介してもらいました. タイトルにもあるように, Googleで実践されている｢マインドフルネス｣のプログラムをまとめた本です. そのためのエクササイズとして｢瞑想｣が取り入れられていて, 瞑想というと｢なんとなく胡散臭そう...｣という印象を持つかもしれませんが, 学術的研究やその成果に基づいて説明が書かれているので, そういった意味での説得力がちゃんとある本だなと思いました.

本によると, EQ(Emotional Intelligence Quotient, 日本語では｢こころの知能指数｣と表現されている)というものが注目されていて, EQの恩恵としては職務遂行能力の向上やリーダーシップなどがあるそうです. そして昨今の研究により, EQは大人になってからも育てることができるということが判明していて, そのため欧米では社会人向けに, このEQを伸ばすためのセミナーなども開催されているそうです. 本書では, このEQを育てる入り口として, マインドフルネスを用いています.

最初は, ｢マインドフルネス瞑想｣という1人で行う瞑想からスタートして, 自分自身, 他の誰か, そしてチームへと, マインドフルネスを広げていくような形で構成されています. 基本的には, 序盤の｢マインドフルネス瞑想｣に基づいてエクササイズの紹介が続いていくので, 都合の良い所だけをつまみ食いするのではなく, 最初から(エクササイズも実践しつつ)読んでいくのが良いのかな, と思います. 今の自分のような, 少し自分自身のメンタルコントロールに苦戦しているという人は, 序盤だけ読んでエクササイズを実践してみる... という形でも良いのかもしれません.

あと, この本を読んでいて思ったのは, 自分自身もこれまで, 無意識のうちに本書で紹介されている｢瞑想｣のようなモノをしていたのかな...? ということです. 具体的には旅行で, 旅行中に交通機関に乗っている時や, 目的地に向かって歩いている時は, 結構瞑想に近い(?)状態になっていた気がするのですよね... なんというか, 良い意味で心をリラックスさせて, 気持ちを切り替える機会になっていたというか. 実際本書にも, ｢歩く瞑想｣というエクササイズが紹介されていますし... そういう意味では, 毎日の通勤時間もそういった効果があったのかもしれません.

昨今の新型コロナウイルスの影響で, 旅行(移動)が困難になっていて, そういう時間(機会)を作れなくなっている... というのは, 最近の精神的なトラブルの要因の1つ, なのかもしれません. あとは, ｢ずっと自宅で作業している｣ということもマイナスに働いているのかな, という気がしています.

ここ数ヶ月, 自宅 = 職場という状況になりつつあるのですが, そういった日々が続くと, どうしても自宅にいるだけで, 常に仕事に関する事が頭の中をよぎってしまう感じがするのですよね... なので, 仕事中はもちろんの事, そうでない時ですら, 仕事はうまくこなせているか? 同僚とうまくコミュニケーション出来ているか? そして期待に答えられているだろうか...? ということを, ずっと延々と考えてしまっている気がします.

こういった状況(?)に銀の弾丸が存在しないのは十分承知しているのですが, とは言え｢もしかして...?｣というヒントを得た気持ちになりました. 1日数十分の｢マインドフルネス瞑想｣であれば, やってみて, うまく行かなかったとしても悔いは残らない(?)と思ったので, ひとまず試してみようかな, と思っています. 暫くして, また効果などブログに書けたらいいな, と思っています.

GitHub Actionsで使えるactionを自分で作る

先日, papix/action-cache-s3という, GitHub Actionsのactionを作ったというエントリを書きました.

papix.hatenablog.com

このエントリでは, このactionを作るにあたって得た知見について, 雑に記しておきます.

actionの雛形

折角なので, TypeScriptでactionを書いてみようと思った訳ですが, 何と公式からTypeScript用の雛形が提供されています. 余程の理由がなければこれを使うと良いでしょう.

github.com

...今回, これを使うにあたって初めて知ったのですが, ｢Use this template｣なるボタン(機能)が存在していて, これをクリックするとそのリポジトリを雛形にして新しいリポジトリをシュッと作ることができるのですね.

というわけで, ボタンを押すと...

こういう感じでリポジトリの作成画面に遷移します. あとはリポジトリ名など指定して｢Create repository from template｣をクリックすればOKです.

ローカルでの実行

actionを実装するにあたり, 動作確認を実際にGitHub Actionsで実行するのではなく, 手元のマシンで実行したいと思うはずです. 改修を加える度にcommitして, pushして, 動作を確認する... というのはとても手間です.

そういった際に気になるのが, actionを実装するにあたって利用可能なツールキットであるところのactions/toolkitが提供する, core.getInputやcore.getStateで取得できるinput/stateを, 手元の環境で指定できるのか...? という点です. これが出来れば, 例えばTypeScriptのテンプレートを使って実装しているactionであれば, ts-nodeなどを使ってローカルで動作確認をすることができそうです.

結論としては,

help.github.com

のドキュメントにあるように, core.getInputについてはINPUT_をprefixにした環境変数で, core.getStateについては, STATE_をprefixにした環境変数で, それぞれ指定できることができます.

例えば, 環境変数INPUT_SAMPLEをtest-inputとしてts-nodeなどでactionを手元で実行すると, core.getInput('SAMPLE')はtest-inputを返します. また, 環境変数STATE_SAMPLEをtest-stateとしてactionを手元で実行すると, 今度はcore.getState('SAMPLE')はtest-stateを返してくれます.

これで, 余程の事がなければ, GitHub Actionsのactionは手元のマシンで開発し, 動作確認ができると思います.

バージョニング

GitHub Actionsのためのactionのバージョニングについては, 以下のドキュメントが参考になります.

github.com

掻い摘んで説明すると... まず, actionをワークフローで(usesによって)利用する場合, どのバージョンを利用するかを指定しなければなりません.

例えば, GitHub公式のactions/cacheのExample workflowを見てみると, 次のように v1 を指定しています.

    - name: Cache Primes
      id: cache-primes
      uses: actions/cache@v1
      with:
        path: prime-numbers
        key: ${{ runner.os }}-primes

このバージョンニングは, 実態としてはGitのrefを利用しています. 例えば, actions/cache@v1を指定した場合, actions/cache リポジトリにある v1 というタグを参照することになります.

従って, やろうと思えば次のようにshaを直接指定したり, ブランチ名を指定することも可能です(なお, ここでは例としてpapix/sample-actionという架空のactionを開発しているとします).

steps:
    - uses: papix/sample-action@41775a4da8ffae865553a738ab8ac1cd5a3c0044
    - uses: papix/sample-action@master

actionを開発している際, 別のリポジトリで動作を試したい! という時は, これらの方法でバージョン指定すると良さそうです.

但し, このようにmasterブランチを指定することについては, 先程紹介したドキュメントにおいて,

Warning: do not reference master since that is the latest code and can be carrying breaking changes of the next major version.

と記載されています. ｢そりゃそうだ｣という感じではありますが, masterを指定していると常に最新のactionが利用されることになり, 意図しない変更が含まれる可能性があるので, 基本的にはmasterを参照しないようにしましょう.

...閑話休題. ここまでの話を振り返ると, GitHub Actionsのactionを開発するにあたって, バージョニングは適切なタグを付与することで実現していることがわかります.

例えば, 今開発しているpapix/sample-actionの先頭のcommitをv1.0.0として指定するのであれば, 次のようにしてv1.0.0タグを付与し, それをpushします. そうすると, ワークフローにおいて papix/sample-action@v1.0.0 としてactionを利用できるようになります.

$ git tag v1.0.0
$ git push origin v1.0.0

注意点としては, v1.0.0のタグだけを付与している時, ワークフローにおいて papix/sample-action@v1 というバージョンを指定してactionを利用することはできません. つまり, ワークフローでactionを利用するとき, そのバージョン指定はあくまでrefに従っていて, v1.* の最新のものを v1 として扱う... といった処理は, GitHub Actionsには存在しません.

そこで, 次のようにv1.0.0に加えて, 別途v1のタグを付与し, pushしてあげる必要があります.

$ git tag v1
$ git push origin v1

更に, この後に幾つかcommitを重ねて新しいバージョン(例えばv1.0.1)をリリース(= タグを付与してpush)した場合, v1 がそれを指すように上書きする必要があります(既に存在するv1タグを上書きするので, -f/--forceオプションが必要です).

$ git tag --force v1
$ git push origin v1 --force

会社で教えてもらった情報ですが, この辺りのバージョニングをGitHub ActionsでよしなにやってくれるGitHub Actionsのactionもあります. 必要に応じて利用を検討してみても良いでしょう.

github.com

まとめ

というわけで, 備忘録を兼ねてpapix/action-cache-s3を作る時に得た知見などをまとめました. GitHub Actionsはとにかく便利ですが, 自分でactionを作ることで更に便利することができるので, 良いアイデアがあればactionを作ってみては如何でしょうか.