｢１日ひとつだけ、強くなる。｣を読んだ

１日ひとつだけ、強くなる。

プロゲーマーでおなじみ, 梅原大吾(ウメハラ)さんの本.

自分はいわゆる格ゲーは遊ばない(苦手)なのだけれど, そういった世界で戦う｢プロゲーマー｣と呼ばれる人達には若干興味があって, 紹介エントリなどをちまちまと読だ事が昔あったのでした. そうした時に得た情報と, この本に書かれているウメハラさんの体験談を繋げながら読むことで, 最初から最後まで楽しく一気に読むことができました.

本の内容としては, ウメハラさんのプロゲーマーとしての経験や姿勢, 考え方などを元に, 勝負論, 成長論について述べる... といった感じでしょうか. 当然のように格ゲーの話題がたくさん出てきますが, その説明も前提として丁寧に述べられているので, ｢格ゲー全然知らないんだけど?｣という人でもスムーズに読めると思います.

個人的には｢視点｣の話題が印象に残りました:

うまくいかない、結果が出ない、そういった不首尾に終わった結果があって初めて考える。これは少し受け身だと思う。悪い結果が出ていないからといって、考えようとしないのも心もとない。もちろん、悪い結果が出ても対処しようとしないのは論外だ。

①うまくいっているが、視点レベルでより良く修正して場面に反映させる。
②うまくいっているが、場面レベルでより良く修正して場面に反映させる。
③うまくいかなかったので、視点レベルで修正して場面に反映させる。
④うまくいかなかったので、場面レベルで修正して場面に反映させる。

優劣の問題ではなく、いずれのやり方が欠けても良くない。これらは互いに影響を与え合う関係でもあるからだ。

ウメハラさんは, ｢一番多いのが④しかやらない人, 次に多いのが④と②だけやる人, 加えて③までやる人はぐっと少なくなり, ①までやる人はほとんどいない｣と述べていて, それで言うと確かに自分も④しか出来ていないな... と思ったのでした. 例えば, ｢今の現状や手札はこうで, なのでこうしよう｣という, 今目の前の状態から考えるだけでなく, ｢こういう結果に至るには, この手札を持つ必要があるな｣とか, ｢こういう手札があったら, どういう事ができるだろう?｣とか, そいった感じで別の視点で考える事も必要なのかな... と思うなどしました. とはいえ, そういった思考には体力と健全な精神衛生が必要と思っていて(それらがないと, そういった事を考える余裕がないと思っている), まずはそこからかな...

その他, 成長論や自信について, ｢こうではないか?｣と個人的に考えていた事をウメハラさんも述べられていて, その辺りは実践していくにあたって自信を持てた気がします. 例えば,

結局、苦手なことから目を背けていると自信を持てない、ということだと思う。苦手に挑戦していれば、たとえうまくできなくても、挑戦していることで自分を肯定的に見られるようになる。それが自信になる。

という所とか. 最近は, これまで｢苦手だし, なんとなく...｣でやっていたことを, きちんと調べてメモして, 知見と経験を蓄積するような試みをしているので, こういった事も継続して自信に繋げることが出来ればいいなと思います.

単純に読み物として面白いですし, ｢成長｣について悩みがある人にとっては良い示唆が得られる本だなと感じました. これより前に執筆された, 『勝ち続ける意志力: 世界一プロ・ゲーマーの「仕事術」』もKindleで買っている(そしてそのまま積んでいる...)ので, 今度はそちらも読みたいですね.

勝ち続ける意志力　世界一プロ・ゲーマーの「仕事術」　(小学館101新書)

GitHub ActionsでS3にキャッシュを保存できるpapix/action-cache-s3を作りました

先日, こちらのエントリでGitHub公式のactions/cacheを使わずに, 自前でS3を使ってキャッシュする方法を紹介しました.

papix.hatenablog.com

｢これ, actionに切り出して再利用できるようにしてみては?｣という意見を頂いたので, 日曜日にサクッと実装してみました.

github.com

S3にキャッシュをするので, 予めS3バケットを作り, そこに読み書きが可能なAWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEYをリポジトリ/オーガニゼーションのSecretsで指定した上で, 次のようなワークフローを記述することで利用できます.

on: push

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - uses: papix/action-cache-s3@master
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_DEFAULT_REGION: ap-northeast-1
      with:
        bucket: cache-s3-test-bucket
        key: node_modules-${{ hashFiles('package.json') }}
        path: node_modules

一応, actions/cacheとほぼほぼ似た使い勝手になるように作っています(実際にS3へキャッシュする部分をジョブの最後に実行するようにしたりとか). ...但しドキュメントやテストはほぼ未整備ですし, actions/cacheにあるrestore-keysのような仕組みもまだないので, これらは追々整備していこうと思います.

papix.hatenablog.com

こちらのエントリでも紹介しましたが, GitHub公式のactions/cacheは現状若干クセがある... と言えると思っています. その辺りで困っている方は是非使ってみていただければと思います(Pull Requestも歓迎です!).

あと, これを作るにあたっていろいろとGitHub Actionsのactionを実装する際の知見を得ることが出来たので, これらについて別エントリでご紹介しようと思います.

GitHub Actionsでactions/cacheを使わずS3で必要なファイルをキャッシュする

papix.hatenablog.com

先日, ｢GitHub Actionsの知見ご紹介｣でactions/cacheが意図通り動作しないケースがある, ということをご紹介しました. 今回は, actions/cacheの代わりにS3を使ってキャッシュを実現する方法をご紹介します. ...まあ, ご紹介しますというか, まあ普通にawsコマンドを使って必要なファイルをS3に置いたり引っ張ってきたりするだけなのですが.

ここでは, 例としてcpanfile.snapshotを元にして, Perlのモジュールがインストールされるディレクトリ(local)をS3でキャッシュする例をご紹介します. Node.jsであれば, cpanfile.snapshotをpackage.json, localをnode_modulesと読み替えればOKです.

前提として, 適当なS3バケット(以下の例では, sample-cache-bucketという名前としました)を用意しておいてください. また, S3への読み書きが可能なIAMアカウントを用意して, そのAccess Key IDとSecret Access KeyをGitHubのSecrets(リポジトリのSettings→Secrets)で, それぞれAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYという名前で登録しておく必要があります.

env:
  cache-bucket: sample-cache-bucket
  cache-directory: perl

jobs:
  prepare:
    runs-on: ubuntu-latest
    steps:

    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-northeast-1

    - name: Fetch cached perl modules
      run: |
        if [[ $(aws s3 ls s3://${{ env.cache-bucket }}/${{ env.cache-directory }}/${{ hashFiles('cpanfile.snapshot') }}.tar.gz | wc -l) > 0 ]]; then
          aws s3 cp --no-progress s3://${{ env.cache-bucket }}/${{ env.cache-directory }}/${{ hashFiles('cpanfile.snapshot') }}.tar.gz perl-modules.tar.gz
          tar -zxf perl-modules.tar.gz
        else
          echo "Cache not found"
        fi

    # ここで必要に応じてライブラリのインストール(carton install, npm installなど)を実行する

    - name: Cache perl modules
      run: |
        if [[ $(aws s3 ls s3://${{ env.cache-bucket }}/${{ env.cache-directory }}/${{ hashFiles('cpanfile.snapshot') }}.tar.gz | wc -l) > 0 ]]; then
          echo "Cache already exists"
        else
          tar -zcf perl-modules.tar.gz local
          aws s3 cp --no-progress perl-modules.tar.gz s3://${{ env.cache-bucket }}/${{ env.cache-directory }}/${{ hashFiles('cpanfile.snapshot') }}.tar.gz
        fi

...少なくとも, runs-onがubuntu-latestの場合, デフォルトでawsコマンドが/usr/local/bin/awsに用意されています. 2020年5月現在バージョンは1.18.37となっているようで, 最新の2系ではないのですが, 例なので今回はこれをそのままを使うことにしましょう(より新しいバージョンのawsコマンドが必要であれば, 別途インストールしてください).

後はaws-actions/configure-aws-credentials@v1を利用して適切にAWSアカウントの認証(ここでSecretsで設定したAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYを利用します)をした上で, awsコマンドを使って S3からファイルを撮ってくる/ファイルを設置するだけです.

これで,

• cpanfile.snapshotに対応するキャッシュがあれば...
  • S3からこれをダウンロードして利用する
  • 必要なライブラリは全てキャッシュから復元されているはずなので, ライブラリのインストールをしても差分なしですぐに完了する
• cpanfile.snapshotが書き換えられるなどしており, 対応するキャッシュがないなら...
  • ライブラリのインストールを実行して, その結果を最後にS3にアップロードする
  • 2回目以降はキャッシュが利用されるようになる

...という挙動が実現できます.

S3を使えば, 前のエントリで紹介したactions/cacheのハマりポイントを意識する必要はありませんし(2〜3週間運用していますが, キャッシュの取得にミスした事例はほぼほぼなくなった), 必要があればAWSのWebコンソールなどを使って, キャッシュを削除したりできるので, 適切なS3バケットが用意できるのであればむしろこちらの方が便利なのでは...? という気がしています.

一方で, 当然ながら別途S3の料金が必要になるのはデメリットですね. なるべく料金を節約できるよう, ライフサイクルルールを設定するなどしつつ利用すると良さそうです.

｢Kubernetes完全ガイド｣読んだ

Kubernetes完全ガイド (impress top gear)

Kubernetesの入り口として推薦してもらっていて, 調べた所Kindle Unlimitedで読めたのでここ最近ちまちまと読み進めていました.

感想としては, Kubernetesの概要というか, 雰囲気を掴む本としてとても良いと感じました. 特に, 巻末付録に｢よくある質問とその答え｣コーナーがあるのが良かったです. ここを見るだけで, ｢Kubernetesでは◯◯が出来る｣ということを一通り(薄く)抑えることが出来るので, それを元に興味を持った部分を読み進めるとか, 或いは業務に活かすといったことが出来そうと思います.

あとはKubernetesにおけるモニタリング(15章), ログの扱い(16章), CIやCD(17章)について述べられていたのも参考になりました. この辺りはまだ前時代的(?)な考えでやっているので, そのコンテナの時代(?)とのギャップを埋める第一歩になりました.

まあそうですね, という感じではありますが, 本を読むだけだと雰囲気は掴めるものの実際に技術として身につく(?)感じは少ないので, この本を入り口にしてGKEとか使って実際に手を動かしてみる... という感じでやっていってみたいと思いました.

PerlでTSVをパースする

小ネタです, 忘備録として残しておきます.

metacpan.org

PerlにはText::CSVという, CSV(Comma Separated Value)をパースするモジュールがあります. 一方で, TSV(Tab Separated Value)をパースするモジュールは, パッと見た感じいいのがなさそうでした.

解決策は以下の3つがありそうです:

split など駆使して手動でパースする

一番素朴なのは, こういう感じで split などを使って, タブを切り分ける方法でしょう($line が1行のTSVとします).

my @fields = split /\t/, $line;

...とはいえ素朴ですし, エッジケース(あるのか?)に対応していないかも... という気がするので, なるべくよしなにモジュールの力を借りたいと思うかもしれません. そういう時は...

Text::CSV_XS::TSV を使う

metacpan.org

結局のところ, CSVとTSVは似ている部分が多いので, 適切な設定をすればText::CSVでもTSVをパースできます. 例えばText::CSV_XS::TSVというCPANモジュールがあり, これはTSVを適切にパースできる設定が有効になったText::CSV_XSを提供する... というモノです.

Text::CSVのオプションを変更する

さて, Text::CSV_XS::TSVのドキュメントを鑑みると, もしText::CSVでTSVをパースしたいのであれば,, 次のように設定してあげると良さそうです:

my $tsv = Text::CSV->new({
    sep_char => "\t",
    quote_char => undef,
    escape_char => undef,
});

...多分, これが一番ベターだと思います.

とはいえ, Text::CSVはコアモジュールではないので, コアモジュール縛りで行くならsplit を駆使する手を採用するということもあるでしょう. TMTOWTDIということで, その時々で最適な選択肢を選んでTSVをパースしていけると良さそうです.