スクラムの起源

5時に寝て7時半に起きた。前週末は遊んでたので夜はいろいろ作業してた。朝起きる習慣がついてきたので何時に寝ても起きれる感じになってきた。うまく体調管理もできている。

年末調整と住民税の納付

年末調整は1月末まで、住民税の特別徴収は納付の特例を使うと6-11月の6ヶ月分を12月10日までに納める。年末調整も11月の給与を確定したら調整額を算出して12月の給与に反映する。必要な情報を入力したら会計システム (freee) で自動算出してくれて書類も一通り作ってくれるので難しくない。ここで出力される給与支払報告書を市役所と税務署のそれぞれに申請する。市役所向けの手続きは eLTAX で行い、税務署向けの手続きは e-Tax で行う。先日 Windows マシンを購入 したので、今回は eLTAX の DL 版で完全な手続きができるはず。ただし、e-Tax も eLTAX も祝日・日曜日は利用できないのでやろうと思ったものの、今日は祝日だからできなかった。

住民税の特別徴収の納付も今回が初めての試み。企業が社員に代わり住民税を納付するのが原則であり、これを特別徴収と呼ぶ。昨年は特別徴収への切り替え申請をしないといけないのを私が知らなくて手続きが遅れた結果、個人宛に届いた納付書でそのまま支払いした。納付自体はそれでも問題はない。おそらく徴税側からみたら源泉徴収して企業の担当者が納付した方が誤りがなく確実でサポートコストを削減できるという狙いなんだろうと推測する。住民税の納付も eLTAX でできるようなので後日挑戦してみる。

アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

4日前から読み進めていて、第1部アジャイル開発とは何か、スクラムとは何か (第1章から第5章) を読み終えた。

冒頭の序論を読んでいて、スクラムは 1980 年代の日本の製造業の (革新的な) 製品開発スタイルの論文がオリジナルだというのを知った。ソフトウェア開発の文脈だと、米国から輸入した方法論のようにみえるが、もとは日本で編み出された方法論だったという。1986年に書かれたハーバード・ビジネス・レビューに投稿された論文がオリジナルらしい。

前に スクラムガイド2020 を一通り読んでいたので、スクラムについての内容はだいたい理解できた。補足でよかったのは、スクラムガイド 2017 から 2020 で改訂された内容やその背景や意図などがコラムで紹介されていた。それらを知ることで、よりスクラムで陥りやすい失敗や誤解されがちなところを理解できた。たとえば「開発チーム」という用語から「開発者」に改められた。スクラムチームの中に別のチームがあるようにみえ、プロダクトオーナー vs 開発チームのような対立構造にならないよう、チームはスクラムチームという1つしかないという意図だという。そして、開発チームの自己組織化 (Self-organized) というキーワードが、スクラムチームの自己管理型 (Self-managed) へといったように、主体である開発チームだけ自律的且つ協働するように読めたのを、スクラムチームという1つのチームしかないと強調されている。

コラム: 2020 スクラムガイド改訂とスクラムの3つの罠
  • スクラムが形式的、儀式的になってしまっている
    • 目的を理解せずにハウツーをなぞるだけのチームが増えたので抽象的な表現に変更した
    • 例) デイリースクラムがただの報告するだけになっている
      • デイリースクラムの目的は状況にあわせた再計画であるため、形式的な報告ではいけない
  • プロダクトオーナー vs 開発チームの構図に陥ってしまっている
    • チーム内の分断をなくし、ワンチームになることが強調されている
    • 開発チームから開発者へ、チームはスクラムチームが唯一
    • プロダクトオーナー vs 開発者が対立構図になることが多かった
      • 「開発チームの自己組織化」から「スクラムチームの自己管理」へ
      • スクラムは役割を超えて協力していくことが欠かせない
        • 問題 vs 私たち (スクラムチーム) という構図を引き出すことが重要
  • スクラムマスターがスクラム警察もしくは雑用係になってしまっている
    • スクラムマスターが「サーバントリーダー」とされていたが、単にサーバントになってしまうことがあった
    • スクラムマスターはプロダクトの成果や組織の目標にコミットメントしないといけない
      • ただスクラムルールを守らせたり、会議の司会役をするだけではない
    • 「真のリーダー」としての資質とプロダクトの成果や組織の目標にコミットメントしていくための熱量を重視して専任していく必要がある

これらのコラムを読むと、私が傍からみていたスクラムは本来の意図したスクラムの開発方法論ではなく、正しく運用されていなかったスクラムなのかもしれないとも思えてきた。本書の第1部を読み進めてみて、スクラムの意図している目的や価値には私が共感できるところが多々あった。

kustomize のパッチ適用の違い

22時ぐらいには寝て6時半に起きた。昨日はお出かけしてきてバテたんで19時頃からうたた寝を繰り返してずっと寝てた。実家に帰っていた期間を除いて、土日のどちらかを休むのはここ3ヶ月はなかったと思うし、土日の2日間ほとんど仕事をしなかったのは半年ぐらいはなかったと思う。久しぶりに土日に仕事しなかったなという印象で、その理由は業務委託のお仕事の契約が決まって余裕があるからだと思う。

kustomize の Inline Patch

Inline Patch に次の3つのやり方が説明されている。

  • patchesStrategicMerge: Strategic Merge Patch として解析されるパッチファイルのリスト
  • patchesJSON6902: 1つのターゲットリソースのみに適用可能な JSON Patch として解析されるパッチと関連付けされるターゲットのリスト
  • patches: 関連付けされるターゲットとパッチのリスト。このパッチは複数のオブジェクトに適用でき、パッチが Strategic Merge Patch なのか JSON Patch かは自動的に検出

patches は patchesStrategicMerge と patchesJSON6902 の両方を記述できる。運用上は patchesStrategicMerge か patchesJSON6902 を適用したいパッチの内容によって使い分けることになる。おそらく前者は base にない要素を追加したり、base の要素をすべて置き換えたりするときに使う。後者は base にある map や list の一部の要素のみを限定して置き換えたり、削除したりするときに使う。ちなみに patchesJSON6902 の 6902 というのは RFC 6902 JavaScript Object Notation (JSON) Patch に由来する。

patchesJson6902 の例として次のような設定にパッチを適用する。base から読まれた metadata の要素から namespace のみを削除したり、spec.metadata の1番目のリストの secretKeyRef が参照する Secret を my-secret で置き換えたりできる。こういったパッチを patchesStrategicMerge で実現することはできないのではないかと思う (詳しくないので私が間違っているかもしれない) 。

base.yml
apiVersion: apps/v1
kind: Component
metadata:
  name: my-component
  namespace: default
spec:
  metadata:
  - name: username
    value: user
  - name: password
    secretKeyRef:
      name: base-secret
      key: password
kustomization.yml
...
patchesJson6902:
  - path: my-patch.yaml
    target:
      group: apps
      version: v1
      kind: Component
      name: my-component
...
my-patch.yaml
- op: remove
  path: /metadata/namespace
- op: replace
  path: /spec/metadata/1/secretKeyRef/name
  value: my-secret

リーンキャンバスレビュー (前半)

前に作ったリーンキャンバス を使って友だちにプロダクトの設計をレビューしてもらった。私がリーンキャンバスを作ったことがなかったので、この項目にはどういった内容を書くか、それぞれの項目がどういった関連付けや粒度で整理するかといった、リーンキャンバスの書き方そのものも含めて教えてもらった。

私が設計のために作った40枚のスライドを話すと2時間必要とするが、リーンキャンバスを使えば要点のみ15分で話せるようになるのが狙いになるみたい。とはいえ、リーンキャンバスの書いてある内容の半分を確認するだけで今日は2時間弱かかってしまった。議事録を取りながらだったので話すだけならもっと短くなったかもしれないし、その背景や根拠を細かくツッコミしていくとそれなりの時間はかかるのかもしれない。リーンキャンバス上は数枚の付箋で簡潔に書いてあるが、これどういうこと?みたいな問いになると詳細を説明しないといけないので時間がかかったように思う。リーンキャンバスの精度や品質が上がれば、読み手が詳細を確認しなくても意図を理解しやすくて詳細のツッコミが不要になるのかもしれない。これまで使ったことがないツールでおもしろいので週末に後半を行う。課題管理の背景には実践知、認知心理学、情報共有、組織論といった様々な分野にまたがるのでそのコンテキストを共有するのはなかなか難しいのではないかという思いもある。

六甲山と灘五郷

六甲山と灘五郷

1時ぐらいに寝て6時に起きた。

オリックスレンタカー

昨日、9:00 - 17:00 で予約したものの、8時には出掛けられる状態になったので電話で確認したら早くてもよいと言う話だったので 8:15 から車を借りる。車種は トヨタ・ヴィッツ 1.3l だった。wikipedia によると、2020年3月31日で販売終了になっているみたい。六甲山のような山登りを普通に走る分にはコンパクトな車体で快適に走行できた。私は車に全くこだわりがないのでこのぐらいのサイズの車で十分だと感じた。保険やWeb割引を含めて8時間レンタルして7,700円だった。

神戸市立森林植物園

三ノ宮市内から約30分ほどで 神戸市立森林植物園 に着いた。8時15分ぐらいに出発したので比較的車が少なくて渋滞にあわずに行けたのもある。六甲山の山道は2車線しかなく、森林植物園の少し手前で渋滞になった。なぜ渋滞しているかというと、駐車場に入るところで料金の支払いが手作業だから。私が行った9時前の時間帯では駐車場のキャパシティは十分にあったが、駐車場の料金支払いで渋滞を引き起こしていたようにみえた。ネットワーク回線がどのような状態かわからないけど、ETC のような機器があれば渋滞を緩和できるのだろうと推測する。六甲山行くならなるべく朝早く出発した方がよいとわかった。

森林植物園全体の1/3ぐらいしかまわれなかったけど、写真とかでみる想像通りの場所でとてもよかった。11月は紅葉シーズンでライトアップもしているらしい。朝みても紅葉がすごくきれいだったのでライトアップも期待して見に行ってよさそうに思えた。時間があれば3時間ぐらいハイキングしても楽しめると思う。

六甲山牧場

森林植物園から10分ちょっとぐらいで 六甲山牧場 に着いた。ここも北エリアしかまわれなかったけど、山羊と羊と馬と牛に触れながらのほほんできるような場所。小さい子ども連れの家族が多かったので、子どもが動物と遊んでいるところの邪魔をしないように配慮しながら楽しむ感じ。

ちょっと前に山羊は草を食べてくれるという榛葉賀津也氏のツィートをみかけた。実家に草刈りのために定期的に帰るのが面倒だと常々思っていたので山羊を飼えばいいんじゃないかと考えている。そのためには山羊が生活する場所を作ってあげないといけない。田んぼの余っているスペースに柵を設け、一緒に山羊小屋も作ってあげればよさそう。六甲山牧場でも山羊はずっと草を食べていた。その辺に生えている雑草を食べるのかどうかわからないけど、確かに草を食べてくれそうな雰囲気はした。すぐに出来ることではないけど、段階的に実家で山羊を飼うための調査をしていこうと思う。

六甲山天覧台

六甲山天覧台 も行こうと予定していたが、道を間違えて辿り着けなかった。次回の機会があれば挑戦する。

菊正宗酒造記念館と櫻正宗記念館

お昼ごろに六甲山を降ってきたので 菊正宗酒造記念館 に行ってみた。お酒造りの道具や作業方法などの展示があって、お土産コーナーで無料試飲と有料試飲があって、無料でも2種類のきき酒ができる。お金を払うと4種類+つまみやアイスなどが付いてくるみたい。私は運転しないといけないのできき酒は飲めなかったけど、お酒が好きな人はいろんなお酒を試せておもしろそうに思う。

ついでにすぐ近くにある 櫻正宗記念館“櫻宴” にも寄ってみた。ここは菊正宗記念館に比べると展示類などは少ないが、お土産コーナーは充実していたのとカフェと食事処は充実していた。また無料試飲はなく有料試飲のみだった。

灘五郷にはこういった記念館がたくさんあるので 灘五郷酒蔵めぐり をしても楽しそうに思えた。

人と防災未来センター

レンタカーのレンタル時間がまだ少しあったので 人と防災未来センター に行ってみた。西館と東館に分かれていて、西館は阪神・淡路大震災の映像や展示など、東館は地震や津波一般の展示が行われているらしい。西館だけみてきた。10分ぐらいの阪神・淡路大震災の再現映像をみたけど、これはかなり迫力があって、震度7という地震の恐ろしさが伝わってきた。私は南あわじ市で15歳のときに震災を経験したけど、南あわじ市は震度4で大した被害がなかったと思う。震度7とか死んでてもおかしくないというのが再現映像から受け取れた。この映像をみて防災意識を高めるだけでも価値があったように思う。

レンタカーを予約した

1時前後に寝て6時に起きた。前日から母が泊まっていて、母は5時ぐらい起きて作業し始めるので必然的に朝起こされる。部屋を掃除してくれたのできれいになった。

ストレッチ

今週もお仕事に忙しくてあまりストレッチもウォーキングはできなかったものの、前週から中殿筋 (ちゅうでんきん) の張りはずっと残っていて、今日もトレーナーさんによく伸ばしてもらったものの張りが強いなと言う印象がある。今日の開脚幅は開始前168cmで、ストレッチ後169.5cmだった。前週とほぼ同じで現状維持ちょっとよくなったぐらいかな。ボールを使った中殿筋のストレッチが気持ちよくて疲れたときによくやっているけど、やっぱり1人でやるストレッチには限界があって、誰かに押してもらったり伸ばしてもらったりする方がよく効く。

三ノ宮・元町観光

親族が来ているので観光案内してきた。うちの会社のオフィスなども紹介した。三ノ宮・元町でショッピングして、南京町で豚まんや小籠包を買い食いしてきた。お昼は 饂飩の四國 という老舗のうどん屋さんに入った。前からお店は知っていて、いつか入りたいなと思いつつ、やや価格帯も高いのでうどんだとちょっと高いかな?とも思っていたけど、今日初めて入ってみて食べたらおいしかったので価格は妥当と言える。私はおろし醤油焼きなすうどんを食べた。コシがあって長い麺はそれだけでもおいしかった。天ぷらが豪華だったので、接待などで天ざるや天丼をお勧めするのもよさそう。

オリックスレンタカー

住んでいるところに一番近いレンタカーに オリックスレンタカー がある。前に一度借りたことがあって、そのときは普通にお店に行って明日借りたいと言えば予約できた。今日も同じノリで明日借りたいと言ったら予約が埋まってますと返された。仕方ないと思って次に近いトヨタレンタカーで尋ねてみたけど、同様に予約が埋まっていますと返された。ネットで探すかなぁと思って、試しにオリックスレンタカーのアカウント作成して、予約検索してみたらちょうど探していたコンパクトサイズで予約できた。ほんの1時間前は予約で埋まっていると店員さんが言っていたのに、、、と思い返しながらいくつかのケースを考察した。

  • 私が質問して帰った後にたまたまキャンセルが出た
  • 店舗予約とネット予約の在庫を別で管理していて、店舗予約在庫はなくなっていたが、ネット予約在庫だけ残っていた
  • 店員さんが在庫を勘違いしていて実は1車だけ残っていた
  • Web の予約システムがバグっていて実は在庫がないのにネットから予約できてしまった
  • ネット予約すると近くの他の支店で余っている車両を再配置するワークフローがあるために予約できた

昨日のメタ認知が暴走するではないけど、メタ認知を働かせるといろんなケースが出てくる。明日お店に行ってちゃんと配車されることを期待する。

メタ認知にもの思い

0時に寝て6時に起きた。昨日も疲れててウォーキングには出掛けられなくて寝て、3時や4時に起きつつも気付いたら5時半に起きてて、そう言えばと思い出したときに6時だったというふわふわした寝起きだった。

朝活: ミクロ経済学入門の入門

[金朝ツメトギ] 2021-11-19 AM 6 で第10章の再分配を読んだ。この本はほとんど朝活で読み終えた。

市場は社会的余剰が最大化されるので社会全体の富を増やす働きの強い制度だという。その増える富の方向性をタテとヨコで表現しているが、タテ方向に増やす働き (資本家が莫大な富をもつ) はあっても、ヨコ方向に拡げていく (みんなが裕福になる) 機能はないという。本章では所得の再分配と、再分配が適正かどうかを測るための指標として ジニ係数 について説明されている。ジニ係数を使うと、所得分布から不平等の状態を客観的に把握することに優れているという。富める者から貧しい者へ所得を移転することでジニ係数が下がる。ただし、両者の貧富を逆転させないものを ピグー・ドールトン移転 と呼ぶ。このピグー・ドールトン移転を実行し続けると、最終的に所得分布は全員が同じである 完全平等分布 になる。このときのジニ係数はゼロになる。その逆に、1人がこの世すべての所得を独り占めすると 完全不平等分布 となり、そのジニ係数は 1 (に近い値) となる。

  • 絶対的貧困: 世界銀行は生命の維持に必要な基準として1日の所得1.25ドルと定めている、絶対的貧困の指標の1つと考えられる
  • 相対的貧困: 所得分布の真ん中の50%と OECD が定めている
    • 相対的貧困の基準に満たない人口の占める割合を 相対的貧困率 と呼ぶ
    • 2019年 国民生活基礎調査の概況 によると、2019年の値は 15.7% になるらしい。6-7人に1人ぐらいの割合になる

メタ認知が暴走

あんちぽさんの日記 に次の動画が紹介されてた。メタ認知で〈学ぶ力〉を高める:認知心理学が解き明かす効果的学習法 を読んでから、学びや書くことについてメタ認知というキーワードを意識して考えるようになっている。この動画ではメタ認知を「相対化」と説明していた。自己を相対化して、様々な文脈や状況、相手の意図なども考慮して結論が出せなくなったり、思考がまとまらなくなってしまうという。そういうメタ認知が暴走する人間を メタモン と名付けていた。ここでいう「モン」はモンスターの短縮なのかな?なかなかおもしろい。こんな極端ではないけど、私も相手の意図や状況を深読みしてしまって静観の姿勢を取るものの、なにも考えてない人だったりすると無駄に時間を浪費してしまうこともある。他にも 銃・病原菌・鉄 の話題が気になって wikipedia を軽く読んだりした。

会食

姪が大学に進学するそうでその面接に来たので一緒に晩ご飯することに。姉の勤め先の関係会社で 神戸プレジール という神戸牛ステーキのややたっかい系のレストランで食べてきた。コース料理で1万円/人で飲みものやデザートなどは別途6千円ほどだった。但馬牛や神戸牛のステーキはもちろんとてもおいしかったんだけど、もう自分はこういう料理を求めてないなというのも感じた。個室で食べてたんやけど、姉の仕事の関係者が5-6人ぐらい、入れ代わり立ち代わりにやってきて、姉は直売所のパートだったのが、いつの間にか社員になって、いつの間にかナンバー2になっているらしい。おまけでフォークリフト免許まで取っている。なんやかんやも含めて、この場所を晩ご飯に選んでいるのもあるんだろうけど、職場の周りの人にしか言っていない今日の予定を、どこかで聞きつけて挨拶にくる関係者の人たち。私が学生の頃「田舎の噂は isdn より速い」と言ったものだけど、いまは「光回線よりも速い」と言うらしい。姉がいろんな関係者に挨拶しているのをみながら、もう自分はこういう仕事もたぶんできないなと実感した。

今年は忘年会やる

1時に寝て3時に起きて2度寝して6時に起きた。起き上がれなくて6時半までだらだらしてから起きた。

リポジトリの改行コード指定

git のリポジトリ設定で .gitattributes という設定方法がある。ざっくり理解するには .gitattributesによる改行コードの変換設定 を読むのが早い。とりあえずこんな設定にしてみた。すでに crlf の改行コードでコミットされたファイルがあるため、それらを lf に変換しないといけない。eol=lf にすると crlf でコミットされている既存ファイルも変換してくれるみたい。おそらくチェックアウトしたときにそうなるのかな?

*       text=auto eol=lf
*.jar   binary

ここ数年は Windows マシンを開発に使っている開発者と一緒に働いたことがなかったけど、OS 混在環境だとリポジトリ設定が必要だということに気付いた。多様性は大事。

忘年会

三宮.dev&bizpy 合同忘年会 に参加登録した。bizpy だけだと、忘年会の参加者を集めるのは厳しそうなので三ノ宮.devと共同でやる。これなら最低でも2人は確定しているのでイベントがなくなることはない。日程は参加者の希望を聞きながら水曜か金曜でやるみたい。いましか飲み会できないだろうからいいと思う。

ミクロ経済学入門の入門

第9章の公共財を読んだ。市場を考察するときに扱う財は一般論として 私的財 を想定している。私的財は次の2つの性質を満たす。

  • 競合的: 複数の人々が同時に利用できない
  • 排除的: 拠出に貢献した特定のメンバーしか利用できない

一方で私的財と対偶の関係にある競合的でも排除的でもない財を 公共財 と呼ぶ。例えば、国防サービスや一般道路などが相当する。侵攻してくる敵国から自国を防衛するときにすべての国民、納税していない人であっても国防の利益にあずかれる。非競合的だが、排除的である財を クラブ財 と呼ぶ。高速道路などが相当する。みんなが利用できるが、利用料金を収めないと利用できない。競合的だが非排除的な財を コモンプール財 と呼ぶ。漁場などが相当する。どの漁師が魚を獲るかは競合しているが、漁業権をもっている限り漁そのものは制限されない。

これをまとめると、財は次の4つの分類になる。

競合的非競合的
排除的私的財クラブ財
非排除的コモンプール財公共財

公共財の自発的供給の問いとして、排除的でも競合的でもない公共財が人々の自発的な行動で十分に供給できるかを考える。自分のお金を寄付する・寄付しないの2択でマトリクスを作成する。自分は寄付せず、他人の寄付から利益を得ることを フリーライド と呼ぶ。みんながフリーライドをしようとすると公共財はまったく供給されない。A と B の2者間における利得表を表すと次のようになる。相手が寄付して、自分が寄付しないときに最大の利益となり、どちらも寄付しないよりは両者が寄付した方が利益が大きくなる。

A \ B寄付する寄付しない
寄付する4, 42, 5
寄付しない5, 23, 3

A が寄付するか・しないかの選択は、B の寄付の有無に関係なく、A は寄付しない方が寄付したよりもトクすることになる。相手がどういった選択をしても自分にとって一番トクな選択肢が同じときにその選択肢を 支配戦略 という。この話は B からみても同じになる。A も B も寄付しないがトクする状態のことを 支配戦略均衡 という。この状態が最善かと言えば、そうではなく、両者が寄付した方が両者が寄付しないよりもトクする状態になる。このように公共財の供給を個々のプレイヤーに任せていては パレート劣位 な結果となってしまう。この状態からどうやって両者が寄付する パレート優位 な状態に移行できるかを考えるのが、政府の徴税の方策と言える。

政府が誰にいくらの税を課して、どの程度の量の公共財を適切と決めるのかは難しい問題である。放っておいて上手くいかないものの、政府に任せて上手くいくことも保証されない。このようなゲーム理論を制度設計に活用する メカニズムデザイン という専門分野がある。

Testcontainers を触ってみた

23時頃に寝て3時に起きて、そこから寝たり起きたりしながら6時に半に起きた。怖い夢をみて眠れなくなって中途半端に寝てた。

朝活: 雑談

【三宮.dev オンライン】リモート朝活もくもく会 に参加した。寝坊、、、というよりは起きてたけど、イベントを忘れていて6時45分ぐらいから参加して主催者しかいなかったのでそのまま7時半まで雑談してた。始めが悪いとだらだらしてしまう。気をつけねば。

三宮.dev の主催者や参加者の常連さんたちとはだいぶ身近に話すにようになってきた。コミュニティって人間関係だと思っていて、話したり顔をあわせたりする回数が増えるに従って身近な知人になっていって、それ自体が価値の1つだったりすると思う。いま忘年会の企画を三宮.dev でも行っているが、bizpy と合同でやっていいんじゃないかと考えている。

Testcontainers

DB を使ったユニットテストのために Testcontainers Postgres Module を使ってみた。docker hub からイメージを取得して JUnit のテストプロセスの中からアクセスできるようにするためのライブラリになる。コンテナの扱いをテストコードから管理したいときなどに便利。ちょっと調べて簡単に設定できたのでまた時間のあるときに会社のブログに記事を書こうと思う。

カスタム GitHub Actions のサンプルを作ってみた

23時半に寝て5時半に起きた。昨夜は夜にウォーキングに出掛けようと思いつつ、22時頃に1時間ほど寝てしまった。それで出掛けるのが面倒になってそのまま寝てた。早く寝た分、早く起きた。せっかく早起きしたのでドラクエタクトのデイリーミッションやって、それから起きて7時ぐらいにはオフィスに着いてたと思う。

カスタム GitHub Actions 作成

GitHub Docs の アクションの作成 をみながらサンプルを作ってみた。カスタムアクションは3つの作成方法がある。

  • docker コンテナを使ったアクション
  • javascript を使ったアクション
  • シェルスクリプトなどを使ったアクション (composite アクション)

たぶんランタイムに何を使うかでアクションの作り方が異なるようにみえる。最後の composite アクションは呼び出される環境で動くことを想定しているのかな?サンプルには bash 上で動くものを紹介していた。ほとんどチュートリアルの内容そのままんだけど、動かして雰囲気を掴むために自分で composite アクションを作ってみた。単一のリポジトリに閉じたものなら通常のワークフローの設定に書けばいいけど、複数のリポジトリで同じ処理をしたい場合は composite アクションとして再利用できるようにするとよさそう。

お仕事しかしなかった一日

2時に寝て6時半に起きた。寝る前にウォーキングしてくるとよく眠れる気がする。お仕事で簡単に終わると思ってた作業にちょっとはまってトラブルシューティングしてたら疲れた。原因はわかって自己解決できたのはよかったけど、消耗して早くお仕事を終えて帰ってくつろいでた。

ローカル開発環境の整備

お仕事でローカルの k8s 環境の保守の作業をしている。minikube でローカルの k8s クラスターを作成して kubectl コマンドで制御する。k8s の yaml の設定ファイルのことをマニフェストと呼ぶのかな?そのテンプレート?ジェネレーター的なツールに kustomize を使っている。先週から1週間触っていたので cli の操作にはだいぶ慣れてきた。

まだ基本的な delete & apply みたいなことしかやってないけど、また余裕のあるときに細かいコマンドやロールバックのやり方なども学習しようと思う。デプロイで一番重要なのはロールバック、次にローリングアップデート、ローリングアップデートができればカナリアリリースもできるかな?その2つがあれば運用は大幅にコスト削減できるし、開発のアジリティも上げられる。たぶん k8s を使えば簡単にできるんだろうなというのは delete & apply だけみてもそう受け取れる。k8s クラスターさえマネージドならよく出来た仕組みだなと感心した。

リーンキャンバスやってみた

リーンキャンバスやってみた

2時に寝て8時に起きた。起きてからドラクエタクトのダイの大冒険コラボイベントをお昼前までやってた。午前中遊んでた割には今日はいろいろ作業した。ゆっくり寝たせいか、個々の作業は集中してできた。

リーンキャンバス

友だちにプロダクトの設計についてレビューしてもらう機会を調整してたらリーンキャンバス作るとよいとアドバイスをもらった。全然やったことがないので試しに自分でもやってみることにした。リーンキャンバス(Lean Canvas)を活用した企画書の書き方【テンプレート付】 を読みながら Canvanizer というツールで作成してみた。リーンキャンバスの利点の1つとしてA4サイズ1枚程度におさめるので短時間で作成できるというのがある。プロダクトの要件定義と設計はすでにできているので、リーンキャンバスは1時間も経たないうちにたたき台を作成できた。また友だちにレビューしてもらうときにフィードバックをもらいながら精度をあげていく。

データ指向アプリケーションデザイン

昨日から 9.4 分散トランザクションと合意の後半の3つの節を読んだ。第Ⅱ部、400ページを超えたので2/3ほど読み終えた。

  • 9.4.3 耐障害性を持つ合意
  • 9.4.4 メンバーシップと協調サービス
  • まとめ

合意の問題は、次のように形式化される。1つ以上のノードが値を 提案(propose) し、合意アルゴリズムはそれらの値の中から1つを 決定(deside) する。この形式化においては、合意アルゴリズムは次の性質を満たさなければならない。

  • 一様同意(uniform agreement) : 2 つのノードが異なる決定をしていないこと
  • 整合性(integrity) : 2 回決定をしているノードがないこと
  • 妥当性(validity) : ノードが値 v を決定したら、 v を提案しているノードがあること
  • 終了性(termination) : クラッシュしていないすべてのノードは、最終的に何らかの値を決定すること

耐障害性を持つ合意アルゴリズムで最も広く知られているのは、Viewstamped Replication( VSR )、Paxos、Raft、Zab であり、こういった合意のアルゴリズムは全順序ブロードキャストを実装しており、複数回にわたって合意が行われる。全順序ブロードキャストによって耐障害性を保ちながら線形化可能でアトミックな操作を実装できる。ZooKeeper のようなツールが、アプリケーションから利用できる合意、障害検出、メンバーシップの「アウトソーシング」サービスを提供する上で、重要な役割を果たしている。分散システムにおける様々な問題に耐えうるようなアルゴリズムを独自に開発するよりははるかによいといえる。合意へと落とし込めるような問題の処理が必要で、さらに耐障害性が求められるなら ZooKeeper のようなサービスを使うとよい。

神戸駆動開発イベント

大阪駆動開発 という xr (vr/ar/mr) のコミュニティがあって、いろんな地域に拡張しているようで、その支部?の1つに神戸駆動開発ができて、そのイベントとして 【神戸】XR体験&交流会 に参加してきた。会場が 神戸電子専門学校 だったのでどんなところかを見に行く意図でも出かけてきた。三宮.dev の主催者も神戸電子専門学校の中の人とつながりがあるらしく、今度オフラインの勉強会をそこでしようか検討しているといった話しもあった。bizpy もコロナが落ち着いたらオフラインの勉強会をやってもいいかなとは考えているので接点を作っておいてもいいかもしれない。神戸なんて狭い地域なのでコミュニティ関係者はすぐにつながるけど、神戸でオフラインの勉強会を開くに当たって適当な場所がないというのはあちこちで聞く話しでもあるので、神戸電子専門学校がそういったコミュニティをつなぐハブ的な場になるならそれはそれでいいのかもしれない。

HoloLens 2Nreal Light と iphone や apple watch とレンズやミラーを組み合わせて作った手作りのデバイスなども体験させてもらった。HoloLens が思ったよりも映像がみえにくくて、ロボットを操作してロケットを発射させるコンテンツをやってみたんだけど、操作よりもコンテンツが明確にみえなくて難しかった。もしかしたら装着の仕方が悪かったのかもしれない。それに比べて Nreal Light はアイドルのライブみたいなコンテンツをみたんだけど、映像も音声もはっきりしていたので印象はよかった。

適当にスタッフの人と話していて、センサーを使って現実のモノや事象を vr 空間に持ち込むと vr コンテンツを作るのは簡単かも?という話しをした。なんかセンサーを探してもいいかもしれない。そのスタッフの人はピアノを弾くのでピアノ音を取り込んで加工したりしていると話していた。

傾斜枕

胃食道逆流症(英語表記Gastro Esophageal Reflux DiseaseからGERD(ガード)とも呼ばれています)は、主に胃の中の酸が食道へ逆流することにより、胸やけ(みぞおちの上の焼けるようなジリジリする感じ、しみる感じなど)や呑酸(酸っぱい液体が上がってくる感じ)などの不快な自覚症状を感じたり、食道の粘膜がただれたり(食道炎)する病気です。胸が詰まるような痛みを感じたり、のどの違和感や慢性的に咳が持続する患者さんもいます。胃酸の逆流は食後2~3時間までに起こることが多いため、食後にこれらの症状を感じたときは胃酸の逆流が起きている可能性を考える必要があります。

(…)

現在では成人の10~20%がこの病気にかかっていると推測されています。

胃食道逆流症(GERD)

ここ1-2年、睡眠がうまくとれなくなったことと関連して、寝ていて胃酸が逆流してむせるといったことも2-3ヶ月に1回ぐらいと稀ではあるけれど、起きるということに気付いた。2年ほど前、健康診断で胃カメラを受診したときに医師から胃の入り口の弁が、普通の人は逆流しないように閉じているものが私のは開いているという話があった。そのときは特に日常生活に困ってないからいいんじゃないで流してたんだけど、加齢とともに胃食道逆流症が起こっているのかもしれないと、いくつかの事象を認識して思うようになってきた。喉の違和感も気になるようになっていた。その症状の軽減に逆流しにくいように傾斜を付けて寝るとよさそうというのをみつけて、傾斜枕を買ってみた。しばらく試してみて寝心地や胃食道逆流症がどうなるかを観察してみる。

寝てた

1時に寝て8時に起きた。もっと早く目覚めてはいたけど、休日なんでゆっくりするかとのんびりしてた。本を読んで眠くなってきたので夕方から帰って寝てた。

ストレッチ

今週は勉強会の発表や週の真ん中で飲みにいってバテてしまってウォーキングは4日ぐらいしかできてなかった。前の週よりはあまり運動ができていない。前週からの右足太もも後ろの筋が張りはまだ少し残っているものの、ちょっとよくなった気がする。今日の開脚幅は開始前168cmで、ストレッチ後169cmだった。前週よりは数値がよくなって、また170cmの大台にのりそうな雰囲気になってきた。

中殿筋 (ちゅうでんきん) という、お尻の横の筋肉があまりよくなくて、ここが悪いと腰痛の原因になるらしい。歩いたり走ったりするときにも使う筋肉だという。中殿筋のストレッチとトレーニング のようなストレッチはいまもやっているけど、トレーニングはやってなかったのでまたやってみようと思う。

勉強会兼もくもく会

【三宮.dev オンライン】ついに出たぜNuxt3!Nuxt.js LT大会 に参加した。LT 発表する人が少なかったのでもくもく会になって本を読んでた。70歳の参加者の方がいて web 開発をするのに vue.js と react.js のどちらを選べばいいか?といった話題で盛り上がりつつ、その方の背景などを聞いていた。技術の話しは通じたのである程度、開発の素養もあってちゃんと勉強している人にみえた。私と同じマイクロ法人をやっているようで、自分のビジネスのアプリケーションを自分で開発するといったスタンスで取り組まれていて、70歳になってもやっている姿勢に敬意をもてた。