4時に寝て8時に起きた。夜に資料作りに集中していたので家に帰ってきたのが3時頃で、くつろいだりアニメみたりしてから寝た。遅くに帰ってきてもすぐに寝るわけじゃなくて、だらだらして実際に寝るまで1-2時間はかかる。こういうところ、生活が堕落していて改善していくべきなのかもしれない。良かったこととして、ウォーキングのせいか、夜はよく眠れた。

みんなの Python 勉強会の資料作り

昨日の続き。一晩寝てから最後の仕上げをした。時間を置く、とくに一度寝てから資料を洗練させると改善点があちこち出てきてより良いものになっていく気がする。午前中に主催者に連絡したものの、午後になってから思い付いたことをちょくちょく修正したりもした。オンラインの資料だと、先方に連絡した後でも微修正できるところがよい。業務の資料だとさらに2-3日かけて洗練させていくけど、勉強会の資料だからこれでいいかな。タイトルはすごく気に入っているというわけではないけど「本と学びの段階」とした。ひとまず完成したので自分のやりたいことに取り組める。

神戸市長選

神戸市は衆議院選挙とは別に市長選挙も一緒にあった。神戸市長選 によると、投票率は53.79％で439,749 (67.7%)の得票を得た現職の市長が完勝した。3回目の当選になるらしい。私が神戸に戻ってきてから初めての市長選挙だった。起業してから手続きなどで行政が身近になったことから関心をもつようになってきた。自分ごとで考えるというのか、どんなものでも身近なことは関心をもつのかもしれない。

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

9.2 線形化可能性を読んだ。

線形化可能性 とは、データのコピーが1つしかなく、そのデータに対する操作がすべてアトミックであるかのようにシステムにみせることを指す。古くなったキャッシュやレプリカからの値ではないことを保証する、最新性の保証（recency guarantee） と言える。トランザクションの章に出てきた 直列化可能性 とはまったく異なる。直列化可能性が保証するのは、複数のトランザクションが何らかの順序で実行された場合に同じ結果になることを保証するもの。

あと「役に立たない CAP 定理」というコラムもおもしろい。CAP 定理とは次の3つはすべて成り立たず、2つを選択することを強いる。

• 一貫性（Consistency）
• 可用性（Availability）
• 分断耐性（Partition tolerance）

CAP 定理は歴史的にデータベースのトランザクションのトレードオフについての議論の出発点として引用され、有名な定理ではあるが、分散データベースの研究者の中では1970年代から知られていたことであったらしい。そして、ネットワークを介した分散システムは、分断耐性が必須 (ネットワークが切断しないことはないから) であることから一貫性か可用性のどちらかを選択するしかない。ここで一貫性とは線形化可能なシステムを実装することだが、これはパフォーマンスのデメリットが大きい。そのため、現代の多くの分散データベースは線形化可能性を提供しないことを選択しており、結果として可用性と分断耐性を選択することになっている。したがって、CAP 定理から議論を始めることは無意味であると言う。

昨日はいつ寝たんだろう？たぶん0時ぐらいに寝て7時に起きたものの二度寝して9時に起きて、それでも眠くてそのままお昼前まで寝てた。今週はなるべく6時に起きる生活リズムの移行をやっていたのでそろそろ疲れたのかもしれない。お昼から起き上がって活動を開始した。昨日に期日前投票を済ませておいたから今日はゆっくり過ごせた。本当は夜に選挙の総括をみたかった気持ちもあったけど、また明日でもいいか。

みんなの Python 勉強会の資料作り

昨日の続き。午後からオフィスで資料を作り始めた。夕方に晩ご飯食べに帰ってくつろいでからまた夜にウォーキングの途中でオフィスに戻ってきて資料を作っていた。気付いたら3時間ほどやってて9割ほどできた。本と読者と学びの段階みたいな、何が言いたいのか自分でもまだ明確ではない、学びの視点を考慮したプログラミングの話しを組み立ててみた。まだふわふわしているのでもう少し洗練させて詰めようと思う。資料の中に3つの話題があるのでなんかうまくまとまっていないような気がしている。タイトルも決まらない。

0時からウォーキングに出て1時に帰ってきて軽くストレッチして 宇宙よりも遠い場所 を3話までみた。たまたまタイムラインでツィートをみかけて気になってみたら確かにおもしろい。3時ぐらいから寝て6時半に一度起きたものの、2度寝して8時ぐらいまで寝てた。夕方に期日前投票やって、初めて出口調査に声を掛けられたのでそれもやってみた。

消防設備点検

点検があるとのことだったので軽く部屋を掃除した。朝ゴミ捨てに行ったらたまたま管理人さんがいて、点検の時間帯でもしいなかったら勝手に部屋に入ってやってもらってよいですと連絡してたら、点検員さんに掛け合ってくれてすぐに設備点検してもらえた。部屋とキッチンにある火災探知機がちゃんと作動するかどうかをテストしてた。2分ぐらいで完了した。おかげで今日の家を出る予定を前倒しできた。感謝。

ストレッチ

今週はジョギングしてない代わりにウォーキングをして筋肉痛を軽減しつつ臨んだ。平日のストレッチも3回ぐらいやっているので現状維持ぐらいかな？と思ったけど、開始前166cmで、ストレッチ後167cmで前回よりも数値は悪くなってた。物理的な体調はよいつもりだったけど、数値が悪化したのでなにか不足があるのか、平日のストレッチの時間が足りないのかもしれない。もしくは、ストレッチを受けていると、まだ右股関節の違和感とお尻の筋肉の張りは根強い。今週は5日ぐらいウォーキングしているのでその疲労もあるのかもしれない。トレーナーさんに夜にウォーキングするとよく眠れるという話しをしたら、ジョギングよりもウォーキングの方がリラックスできて、ジョギングや筋トレ (激しい運動) は交感神経を刺激して睡眠にはよくないといった話だった。ググったら ジョギングよりもウォーキングがお勧め という記事も出てきた。

みんなの Python 勉強会の資料作り

昨日の続き。発表の内容の構成を考えながら、過去に書いた本や資料、サンプルコードなどを見返していた。コンテンツはだいたい頭の中で固まってきた。あとは構成を練りながら実際にスライドとして仕上げていくだけ。いつもそうなんだけど、スライドの作り始めが一番難しい。何から書くか、どこから作り始めるのかに最も時間を割く。もう少し悩みながら考えておく。

サバクトビバッタの研究

たまたまタイムラインでみかけて 『バッタを倒しにアフリカへ』行き、必殺技を見つけてきました を読んでみたらすごくおもしろかった。国連にはバッタ予報官という専門職？があるのを記事などでみかけていた。日本だとイナゴになるんだろうけど、世界的にはバッタなんよね。そんなバッタの研究に、全然関係ない日本の若手研究者が、過去40年間誰もアフリカで腰を据えて研究しておらず、バッタ研究の歴史が止まったままであることに気付いて、何年もかけてシンプルな観察をメインにしたフィールドワークで成果をあげたという、ミドルエイジクライシスな自分にとっては痛快で元気がでる記事だった。著者のノリもおもしろいので、おそらく陽気な人なんだろうと思う。応援する意図でも バッタを倒しにアフリカへ を購入した。

2時から Connect 2021 のイベントをみてた。3時過ぎぐらいには眠くて耐えられなくなってそのまま寝落ちしたら7時に起きた。本当は6時から金朝ツメトギの朝活の日だったのに寝坊して参加できなかった。なんか疲れて家に帰って13時から17時まで寝てた。生活のリズムを崩すと大きく集中力がなくなる。その後、またオフィスに行って作業してた。

Connect 2021

マーク・ザッカーバーグの基調講演を聞いていると、機械学習の次のテックの波はメタバースなのかなぁとか思ったりもしたけど、あとで メタバースはディストピアの悪夢です。より良い現実の構築に焦点を当てましょう。 を読んでいて、やっぱり違うよなぁとも思った。自分がメタバースの世界で活動したり、アプリケーション開発をやってないから他人の意見に引っ張らられる。いずれにしても自分でちょっとやってみて、メタバースとの今後の付き合い方を考えないといけないということだけは理解した。今日の時点ではこのツィートがおもしろかった。

pic.twitter.com/4UHSycJ9HR

— seya (@sekikazu01) October 29, 2021

みんなの Python 勉強会

あべさんから依頼がきて みんなのPython勉強会#75 で発表することになった。いつだったか忘れたけど、コロナ禍になる前だったと思うけど、いつか発表してほしいみたいな話しをしたりしながら機会がなくていまに至るというのもあって、内容があうならいっかという感じで引き受けた。20-30分程度でできるPyとエキPy第3版の話しを半々ずつみたいな内容でやるつもり。週末に内容を詰めて資料を作るつもり。Python は普段使いのツールとして使っているものの、お仕事で Go や Java で開発するようになってからあまり深く関わらないようになってしまった。ずっと Python コミュニティの勉強会に行ってたから、いまでも Python の人とみられるのは仕方ないかなとも思う。

フラクタルスプリント

ある記事で フラクタルスプリント というキーワードをみかけて、なんのことか分からなかったので調べてみた。47機関というチームが実践しているスクラムをベースにした開発方法論と言えるのかな？次の発表動画をみて雰囲気は理解できた。

• 15分スプリントの具体的な進め方について動画で話した #15min_sprint

フラクタルスプリントのやり方はこんな感じ。

• 基本はスクラムのイベントをそれぞれのスプリントで行う
• スプリントの中にスプリントを含めるという入れ子構造をとる
  • 1ヶ月 → 1週間 → 1日 → 1時間 → 15分の入れ子
• それぞれのスプリントの20%程度の時間は自由時間にしてバッファをとる
  • 例えば、1時間のスプリントに含むのは 15分 x 3 のスプリントと残り時間は自由なスプリントの時間にする
• 15分スプリントは10分タスクを1つだけやるスプリントと言える
  • 残りの5分をスクラムイベントにあてる

極端にイテレーション期間の短いスプリントをすることで、通常のスクラムの開発方法論になかったイノベーションが起きるのではないか？といったところを狙いに47機関さんが業務で実践的にやっているプラクティスと言えるみたい。実際にやってみてうまくいったことなどを話しているので、ある種の学習コストを要求するものの、よいところもあるようには思える。おそらくは意図的に悪いところを話してなかったようには思える。例えば、それぞれのスプリントのイベントにおけるオーバーヘッドは大きくなるので作業時間が減るとか、10分タスクですべてチケット化すると、チケット数が増えるので必然的に過程の記録はチケットに残ってないはず。スプリントバックログを付箋の代わりに使うだけというのはスクラム開発一般の話ではあるけど、このやり方では開発者が何をやっているかを書く場所としてチケットは適切な場所ではなくなる。代わりに wiki にまとめるとは話してた。wiki だとフロー情報を監視するのが難しくなるが、その分、短いスプリントでのイベント (プランニング、レビュー、レトロスペクティブ) が頻繁にあるのでそれをフロー情報の監視の代替として機能するようにみえる。いわば強制で。

15分スプリントと聞いて先入観でイメージするよりも、合理的なところも理解できたのでチームの学習コストとスプリントイベントのオーバーヘッドを受け入れるなら悪くない開発方法論かもしれない。良い・悪いといった是非ではなく、47機関さんが大事にしているチームの価値観や文化、そしてチームをよくするための実践的な方法論と一緒に理解することでこの開発方法論は活きてくる。開発方法論だけをみてあれこれ言うのは適切ではないとも思えた。自分たちの業務や働き方にあった開発方法論を開発チームはずっと考え続けていくべきだと私は考えていて、47機関というチームはフラクタルスプリントという手法を編み出して、それ自体が素晴らしいなと思えた。

0時に寝て6時半に起きた。久しぶりに勉強会でたくさん話したせいか、疲れて抜け殻になってた。昨日もよく眠れた。今日は調整作業が多かったので集中力を欠いてチケットの業務は進められなかった。

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

第Ⅱ部の最後の章である9章の一貫性と合意を読み始めた。この章も内容は難しそう。9.1 まで読み終えた。時間をかけて1節ずつ読んでいく。

間違っているかもしれなくても動き続ける方が良いのか、それとも正しくあるべく停止してしまう方が良いのか？

―― Jay Kreps, “A Few Notes on Kafka and Jepsen” （ 2013 ）

冒頭の格言で kafka というキーワードが気になったので原文を探して (deepl で翻訳して) 読んでみた。一般論で考えたらこの問いの答えは停止してしまう方を選択するように私は考えてしまったが、原文の記事によると、この答えはアプリケーションに依るという。ダウンタイム=データの損失という特性のアプリケーションであれば、間違っている可能性があってもすぐに復旧して動かした方がよいという場合もあると言っている。kafka はどちらかと言えば、間違っていても動き続ける方のシステムに分類されると思う。メッセージの到達保証も At Least Once だし。

もう1点、意識しておかないといけないのはレプリケーションを行うデータベースの大半は 結果整合性（eventual consistency） であること。私は本書を読むまで、結果整合性をスケーラビリティやスループットの高い分散システムのキーバリューストアの特性だと考えていたが、RDB であってもレプリケーションはリアルタイムに行われるわけではなく、ネットワークという遅延の上限が保証されないインフラの上に構築されたものである以上、結果整合性で同期される。レプリケーションをしないデータベースシステム以外はすべて結果整合性の特性があると考えて設計や開発をする必要がある。

PMBOK ガイド第7版

プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版＋プロジェクトマネジメント標準 を購入して届いた。たぶんいつか電子版も出ると思うけど、現時点では紙の本しかなさそう。ぱらぱらとめくりながら中身を眺めているとそんなに文字がびっしり書いてあるような本ではないので読むのはそんなに大変ではなさそうな印象を受けた。索引で知りたいキーワードを探しながらその箇所を拾い読みしたりしてた。またがっつり読み込んでまとめていきたい。

選考面談の最終決定

先日受けた 選考面談 で2社ともオファーをいただいた。感謝。自分の中では決まっていたが、顧問さんにも双方の案件の概要を話してアドバイスをもらった。その結果、私の意思と顧問さんのアドバイスも一致した。何の憂いもなく Java の開発案件の方を選択した。11月上旬から働き始める予定。3ヶ月ほど課題管理の調査・研究みたいなことをやっていたけど、いつまでもやれるほど財務に余裕がないので普通に働きながら自社のプロダクト開発も並行してやっていく。以前は2社のお仕事を引き受けて他のことをやる余裕がなくなってしまっていただけど、その失敗を教訓に今回は1社の仕事だけを専念しつつ、自社の仕事も少しずつ進めていきたい。

2時に寝て6時に起きた。前日の夜にウォーキングしたせいか、よく眠れた。朝活を終えてから朝ご飯を作って食べてそのままオフィスに出社した。6時起きを日課にした方が生活のリズムがよい。夕方に眠くなって1時間ほど昼寝した。

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

【三宮.dev オンライン】リモート朝活もくもく会 で第4章の供給曲線を読んだ。需要曲線の逆からの視点なので考え方は同じで図の形が異なる。用語がいくつか出てきたのでまとめる。

• 収穫逓減 (しゅうかくていげん): 製品をより多く生産するのにかかる経費が増大していくこと
  • 生産活動において2倍の生産量を生み出すには2倍以上の経費がかかる
• 費用関数: 生産量と費用との関係をあらわす
• 限界費用: 追加的に1単位生産する費用
  • 3個を生産する費用は、1個目の限界費用 + 2個目の限界費用 + 3個目の限界費用
    • 個数が増えるごとに費用は高くなっていく
  • 費用を図示するときは限界費用に分解した方が視覚的にわかりやすい
• 限界費用逓増: 生産するごとに限界費用が高まっていくこと

「逓」という漢字は「つぎつぎ」や「だんだん」という意味をもつ。

• プライステイカー: 自分の生産量が価格に影響を与えられない
  • 減産により希少価値を高め価格を吊り上げる市場操作ができない
• 独占企業: プライステイカーの反対。
• 利潤: 売上 - 経費
• 最適解: 利潤を最大化する生産量
  • あと1個追加して生産すると利益がマイナスになるところ
• 生産者余剰: すべての企業の利潤の和
• 供給曲線: すべての企業の限界費用をヨコに足し合わせた曲線

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

昨日の続き。8.4 を読んで8章分散システムの問題を読み終えた。全体としても学びになったけれど、とくに 8.3 信頼性の低いクロックの節が全く開発・運用で意識したことがなかったので私にとっては学びになった。

分散システムにおいて発生する厄介な問題がある。

• ネットワーク経由でパケットを送信しようとした場合、そのパケットはロストしたり、どれほど遅延するか分からない。同様に、レスポンスもロストしたり遅延したりするので、レスポンスを受け取れなかった場合には元々のメッセージが到達したかどうかも分からない

• ノードのクロックは他のノードと大きくずれているかもしれない（できる限りの努力をして NTP をセットアップしたとしても）。クロックは急に進んだり戻ったりするかもしれず、たいていはクロックの誤差をうまく計る方法がないので、クロックに依存するのは危険

• プロセスは処理中にいつどれほどの長さ一時停止するかもしれず（おそらくはstop-the-worldガベージコレクタのため）、他のノードから落ちていると見なされた後に自身に一時停止があったことを理解しないままに復活するかもしれない。

こういった 部分障害 が生じうるのが分散システムの特徴と言える。ソフトウェアが他のノードが関わる何かをしようとした場合、それは時おり失敗したり、ランダムに速度が落ちたり、まったくレスポンスが返されない（そして最終的にはタイムアウトする）といった可能性がある。分散システムでは、部分障害への耐性をソフトウェアに組み込み、システムの構成要素が一部破損していてもシステム全体としては機能し続けられるようにする。

フォールトに耐えるための最初のステップはフォールトを 検出 することだが、それさえも難しい。多くのシステムは、ノードに障害が生じていることを検出する正確な仕組みを持たないので、ほとんどの分散アルゴリズムはリモートノードが生きているかどうかを判断するのにタイムアウトに頼る。しかし、タイムアウトはネットワークの障害とノードの障害を区別できず、ネットワークの遅延変動のために間違ってノードがクラッシュしていると誤検知することもある。弱っているものの落ちてはいないノードは、きれいに落ちているノードよりもさらに扱いが難しくなる可能性がある。

フォールトが検出されたとして、システムがそれに耐えられるようにすることも簡単ではない。マシン間にはグローバルな変数も、共有メモリも、共通の情報やその他何らかの共有された状態もない。ノードは現在の時刻についてさえ合意できず、ましてやもっと重大なことに合意することなどできない。あるノードから他のノードへ情報を流せる唯一の方法は、その情報を信頼できないネットワークを通じて送ることだけである。重要な判断は単一のノードだけで安全に下すことができないので、他のノードの助けを得てクオラムが合意に至るようにするためのプロトコルが必要となる。

同じ操作をすれば決まって同じ結果を返してくれるような、単一コンピュータにおける理想化された数学的な完全さの中でソフトウェアを書くのに慣れていると、分散システムの雑然とした物理的な現実への移行はちょっとしたショックを伴う。一方、分散システムのエンジニアは、しばしば単一のコンピュータ上で解決できる問題を簡単なものだと見なすが、実際のところ今日では単一のコンピュータがこなせる仕事量はかなりのものになっている。単一のマシンでシンプルにことを済ませられるなら、概してそうする価値はある。

分散システムを利用する理由はスケーラビリティだけではない。耐障害性や低レイテンシ（地理的にユーザーの近くにデータを置けることによる）も同様に重要な目標であり、こういったことは単一ノードでは実現できない。本章ではネットワーク、クロック、プロセスの信頼性の低さが避けがたい自然の法則なのかも調べた。安全ではなく、クリティカルではないシステムの多くでは、高価な高信頼性よりも安価な低信頼性が選択される。また、信頼性の高いコンポーネントを前提としているスーパーコンピュータも取り上げました。スーパーコンピュータはその前提が故に、コンポーネントに障害が生じてしまった場合には完全に停止させて再起動することになる。これに対し、分散システムはサービスレベルでは中断することなくいつまでも動作し続けられる。これは、少なくとも理論上はすべてのフォールトやメンテナンスはノードレベルで処理できるためである。

お昼ご飯

気分でスーパー寄って買いものして家に帰り、お昼ご飯を作って食べた。前に適当に作った かぼちゃの煮物 がおいしかったので再挑戦してみた。今度は圧力鍋を使っていろいろ具材を入れてみた。過去に作っておいしかった料理のレシピを evernote に書いたりしていたけど、もういまは書いてないので気が向いたら日記に書くようにする。

材料

• A
  • 水 900cc
  • めんつゆ 100c
  • 醤油 適量
• B
  • かぼちゃ 1/4切れ
  • なす 3個
  • にんじん 2本
  • 玉ねぎ 1個
  • しめじ 1パック
• C
  • 卵 2個
  • 豆苗
  • せみ餃子

作り方

1. 圧力鍋に A を入れて火にかける
2. B の野菜を切りながら圧力鍋に入れていく
3. 圧力鍋に B をすべて入れたら圧をかける (高圧30秒)
4. 圧が下がったら蓋をあけて C を入れる
5. C に火が通るまで2分ほど煮込む

所感

圧力が強過ぎたのか、かぼちゃが煮汁に溶け出してしまって原形がなくなってしまった。スープとして飲んでもおいしいけれども、水を入れ過ぎたのかもしれない。肉の代わりに餃子を使ってみた。水餃子っぽくなるので焼き餃子で油使うよりヘルシーな気持ちになっておいしい。

bizpy 勉強会

Python で Slack のインテグレーションをやってみる勉強会 #1 を開催した。半年以上開催してなかったので億劫になってしまっていたけど、再開できてよかった。10名ほどが参加してくれた。用意したコンテンツを話し終えたら8時半ぐらいで時間もちょうどよかった。初参加者も数人いた。slack インテグレーションの調査も兼ねてあと2-3回は集中的にやっていきたい。

4時に寝て7時に起きた。やや寝坊したけど、夜中に作業してよく眠れたのでまぁいっかとしておく。昨日のかぼちゃの煮物が残っていたので19時に帰って晩ご飯食べて、ちょっと休んでからウォーキングに出た。ウォーキングの途中でオフィスに寄って一作業してからまたウォーキングして帰るという、運動と作業の一石二鳥になることを思いついた。ちょっと天才。ウォーキングの合計時間は1時間強ぐらい。

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

8章分散システムの問題のうち、8.1, 8.2, 8.3を読んだ。

とくに 8.3 信頼性の低いクロックは私がこれまでアプリケーションを開発していて全く意識したことがなかった問題を扱っていてすごく勉強になった。おそらくミリ秒レベルでの障害調査をほとんどやったことがなかったので気にしてなかったのかもしれない。Cassandra が採用している LWW (last write wins、最後の書き込みを勝たせる) だと、短時間に連続して行われた書き込みと、本当に並行して行われた書き込みとの区別がつかないのでクロックの同期の状況によって因果律違反が発生する懸念がある。

NTP を使っていてもクロックの同期はミリ秒から秒レベルで正確ではない可能性があり、そこにプロセスの一時停止なんかも加わると容易に数秒の時間がズレてしまい、トランザクションにおける因果律違反が発生する可能性があるという話が丁寧に説明されている。実際に同じリソースに対してミリ秒レベルでトランザクションを発行するというのはあまりない状況だろうし、状態がよければあっても正常に動作する。但し、正常にトランザクションが実行されない懸念があるという理屈を知っておくのは大事なことに思えた。Google の Spanner が原子時計を導入して精度の高い時刻同期をしているというのは記事を見聞きして知っていたが、それがないとどんな問題が発生するのかが 8.3 節を読むと理解できる。

選考面談

そろそろお仕事をしないと会社の財務がやばいので選考を受けている。今日は2社の選考を受けた。1つは Go の開発案件、もう1つは Java の開発案件。どちらも業務内容はマッチングしていて勤務形態もフルリモートなのでいまの生活のまま、お仕事ができる。1社は正式にオファーが届いて、もう1社もおそらくオファーがくる想定。どちらかを選択する。転職だと面接を何回もして選考を受ける必要があるけど、業務委託だと大半が1回で決まる。昔フリーランスやってたときもそうだったかな？調整の管理コストが下がって望ましいことではある。もう私の中では承諾する方の案件は決まっているけど、念のため、1日寝かして顧問さんとも相談した後、最終決定しようと思う。

韃靼そば茶

少し前から家では 大阿蘇万能茶 を煮出して冷やして飲んでいる。村田園のサイトにはないので商品名が変わった？のかもしれない。この万能茶は、よく言えば後味すっきり、わるく言えば刺激がないと言える。おいしくないわけではない。近所のドラッグストアでノンカフェインのお茶を求めて購入した。もう少しお茶の主張がほしいなと思って、にっこくの 韃靼そば茶 を購入した。そば茶もノンカフェイン。これは水出しもできる。試しに水筒にティーパックを入れて、オフィスのウォーターサーバーで水を入れて作ってみた。時間が経つごとにそば茶の味が濃くなっていくけど、これはこれで私は好みなので問題なさそう。なるべく1日で飲みきって水筒を洗えばよさそう。

夜にうまく眠れなくなってから、夜にカフェインの入った飲みものを避けるようになった。ノンカフェインだとわかっているお茶なら安心して飲める。しばらく試してみる。

3時に寝て6時に起きた。今日はちゃんと起き上がって朝からお茶を煮出して粗熱とって冷やしたりしてた。その後、準備してオフィスに着いたのが7時20分。いつもより1時間早く起きているのでオフィスに着くのも1時間早くなる。先週 の水曜日と金曜日だけ朝活やってみて逆に生活のリズムが乱れてよくない感じがした。今週は毎日6時に起きて朝活に参加してみるのを試す。

ミクロ経済学入門の入門

早起きしたので打ち合わせ前の隙間時間に第3章の需要曲線を読んだ。まずは用語の整理から。

• 上級財: 所得が増えたときに消費が増える財
• 下級財: 所得が増えたときに消費が減る財

一般的な傾向として、ものは消費するほど有り難みが減る。たとえば僕はコーヒー1杯目に最大4ドルまでなら払ってよいけれど、2杯目には最大2ドルまでしか払いたくない、そして3杯目には最大1ドルまでしか払いたくない、というように。

食べものとか実際にボリュームディスカウントされることが多いので食べものだとイメージしやすい。スーパーで半額になった豚カツを2枚買うときの私の気持ちはこんな感じ。定価なら1枚しか買わないのに半額なら2枚買ってもいいかと思ったりする。たまに2枚を一度に食べて気分悪くなって後悔する。たいていは晩ご飯に1枚、翌日のお昼ゴハンに1枚を分けて食べる。

• 余剰: 価格と消費者がお金を払ってもよい金額との差額
  • コーヒー1杯に400円払ってよいと考えていて、100円のコーヒーを買うなら300円が余剰といえる
    • さらにコーヒー2杯目を50円で買ってよいと考えるなら350円が余剰と言える

すべての消費者の余剰を計算したものを消費者余剰という。需要曲線からある価格 p を取るときの次のグラフにおける面積を消費者余剰と呼ぶ。グラフにすると直観的にわかりやすい。

消費者余剰に対して、売る側の利潤の合計を生産者余剰と呼ぶ。消費者余剰と生産者余剰との和を社会的余剰と呼ぶ。社会的余剰を「市場のよさ」のモノサシとして使うと談合は禁止すべしということになる。

• ベルトラン価格競争
  • 同品質で同費用の業者が価格競争をした場合、顧客は価格が安い方から商品を購入する。こうした市場をベルトラン寡占市場と呼ぶ
  • このとき業者間の価格競争は最終的に「底辺への競争」が起こり、経費と同じ価格に近づく
    • この状態をベルトラン均衡と呼ぶ
  • 業者間で談合して価格を据え置けばよいが、業者の数が多くなるとこれは難しい
    • 裏切りが発生したり、信頼関係を維持するのが難しかったりして、長期的な利益や全体の利益を追求するのが難しい
      • ゲーム理論の話しのように読めた
• 価格弾力性
  • 価格の変化によって需要がどのぐらい弾んで動くかをあらわす
  • 弾力性が低いというと、価格が動いても需要はあまり変わらない状態をいう
  • 弾力性が高い財は値上げすると需要が大幅に下がる
    • 必需品は値上げしても需要が下がりにくい
      • 課税で考えると、必需品への課税は貧しい人の生活に与えるダメージが大きい
• ギッフェン財
  • 需要曲線は右下がりのカーブになるのが通常だが、経験的事実に即している
    • そうした財を正常財と呼ぶ
  • ごく稀に価格が上がるにつれ売れ行きが増すものがある、それをギッフェン財と呼ぶ
• 代替効果: ある商品が値上げしたときに別の商品に置き換えたくなる
• 所得効果: 生活にゆとりがなくなると、高いものは買えなくなり、安いものを買おうとする

内容はそう難しくないが、急にたくさんの用語が出てきて読み解くのに時間がかかった。

設計ドキュメントレビュー

先週から作っていた設計ドキュメントを顧問さんと一緒にレビューした。スライド40枚を2時間がっつり話してめっちゃ疲れた。話し終えて20-30分抜け殻になって軽く散歩してきた。ここ3ヶ月、調べものをしてきた内容の集大成でもあり、頭の中にしかなかった課題管理の実践知を明文化するといった取り組みの (途中) 結果でもある。品質の良し悪しで言えば、たった3ヶ月で出来たものなので大したことはない。あくまで途上における段階でしかないのだけど、私の中でも納得感は出てきたし、レビューしてもらって厳しい指摘もなかったので方向性は出てきた感じがある。このまま時間のあるときに進めていく。

Slack apps の調査

この水曜日にある勉強会の 資料作成 が完了した。Slack apps の調査を勢いよくやりたいので2週間ごとに開催することにする。ドキュメントを眺めていて次回は 新機能、アプリのホーム・ヴューを活用しよう:house_with_garden: のチュートリアルをやってみることに決めた。

お昼寝

睡眠時間が短かったせいか、朝早かったせいか、夕方に集中力がなくなったので17時に切り上げて帰って寝てた。今日は雨だったので徒歩通勤だったのもありウォーキングにもなった。途中でスーパーに寄って買いものして帰った。運動目的だと1時間ぐらい歩いても平気なのに通勤だと15分歩くだけで疲れる。同じ行動をしていても目的意識で変わってくる。18時ぐらいには家に着いてそのまま4時間ほど寝てた。その後、また起きて夜の作業に入った。起きてからお腹すいて即席でめんつゆと醤油とかぼちゃとささみと卵で煮物を作ってみたら意外とおいしかった。お腹すいているとちょっとしたものでもおいしい。気に入ったのでカバー画像にしてみた。

2時に寝て9時に起きた。寝る前に1時間ほどウォーキングしてきたせいか、よく眠れた。田んぼをしたり運動をしたり体を動かして疲れた方がよく眠れるような気がしてきた。しばらく続けてみようと思う。お昼は調べものをしていて夕方に眠くなって2時間ほど寝てまた夜も調べものをしていた。

Slack apps の調査

この水曜日に勉強会があるので調査と 資料作成 をしていた。いつの間にか slack app 作成のためのドキュメントもいくつか 日本語化 されていることに気付いた。Bolt フレームワークを使って Slack Bot を作ろう のドキュメントをみながら bolt-python を使って簡単な bot アプリを作成した。アプリの設定・開発の流れはだいたいこんな感じ。

1. slack app 作成
2. bot ユーザー作成
3. oauth スコープの設定
4. bolt アプリケーションの実装
5. イベントサブスクリプションの設定

bolt とは別に python-slack-sdk というライブラリが提供されていて、このライブラリを使って bolt というフレームワークが実装されている。bolt でやりにくいことがあったら直接 sdk を触ることもあるのかもしれない。

現時点で勉強会の参加者は17人もいる。半年以上さぼっていたけど、けっこうな人数が参加してくれている。slack app の調査も兼ねて3-4回ぐらいは勉強会を開く予定。初回はアプリを作成するときの雰囲気を学んでもらえればと思う。

3時に寝て9時に起きた。前日の夕方お昼寝して21時から2時ぐらいまで作業してから寝たので生活のリズムが狂ってしまったかもしれない。それでもよく眠れたので体調は良いように感じた。

ストレッチ

先週は木・金と連日にジョギングして筋肉痛になってた ので、今週は木曜日だけジョギングして金曜日はお休みしてストレッチを受けた。それでもまだ右股関節の違和感と若干の筋肉の張りは残っている。終わってから少し体が楽になったので疲れが溜まっていたのかもしれない。今日の開脚幅は開始前168cmで、ストレッチ後170cmだった。先週とほぼ変わらないので股関節の可動域は現状維持。トレーナーさんに自分でストレッチしていて感じた左右の違いや右股関節の違和感を相談してみてもらったりした。物理的な身体の変化や状態を相談できるというのもこのサービスの価値の1つでもあると思う。相談してこういうストレッチするとよいですよというアドバイスをもらうだけでも安心した気持ちになるように感じた。

設計ドキュメント修正

先日たたき台として作成したもの を見直しながら手直したしたりしてた。資料を作ってから2-3日寝かせてから見返すと粗がみえたり不足している内容を思いついたりする。事前に資料を作って余裕があるときはよくそうやって洗練させている。リファクタリングをやるような感覚。カバー画像にあるスライドを追加した。自分の頭の中にあるイメージを図として具現化できると、それ自体を楽しい・嬉しいといったポジティブな感情に捉えられる。資料を作成していて頭の中にある情報をうまく整理できないときに苦痛やしんどさを感じる。言いたいことがあり過ぎたり曖昧だったりしてまとめられないことがある。その反対だから快ちよく感じるのかもしれない。

ウォーキング

ジョギングしない日でもなるべく運動した方がいいかと思い始め、23時をまわってから歩くために出かけた。いまオフィスに着いてこれを書いている。19時頃に家に帰れば近所の公園へ行ってジョギングをする。21時をまわると晩ご飯を食べるのが遅くなってしまうから先に食べてしまって、くつろぐと面倒くさくなって外に出なくなる。あと夜遅くに公園で一人走るのも周りに人がいたらこわがられるんじゃないかと思ったりする。前に深夜2時に走りに行ったことがあるんだけど、最初は私1人しか走ってなかったのに途中でもう1人いるようになった。誰もいないと思って走ってて人がいるとなんかこわくなったので夜遅くに走るのはやめようと思った。ジョギングしなくても1時間ほど歩くだけでも健康にはよさそうだし、なるべく続けられるよう努めてみよう。

たまたま繁華街の付近を歩いてみたら、飲食店の営業時間制限が解除されていて、昔のように飲み歩くお客さんで賑わっていた。お店の中を覗くと繁盛しているお店もあれば、全然お客さんが入っていないお店もあった。完全にお客さんが戻ってくるのはちょっと時間がかかるのかな。いまは一時の休息のようなものなんだろうけど、コロナ禍で寂しかった街並みに活気が戻ったようでなんか気分がよかった。でも、狭い店舗でマスクせずに飲食しててまた感染者増えるんじゃないかと不安に思ったりもする。

4時に寝て6時に起きた。朝活があると何時に寝ても6時に起きれる。終わってからやっぱり眠くなって1時間ほど寝てた。お昼の外出から戻ってきて雑務やってから、なんか集中できなくて15時から帰ってお昼ご飯食べて2-3時間寝てた。寝る時間帯がずれると生活のリズムが狂ってしまい、全体でみると生産性が落ちるように思えてきた。水と金だけ6時に起きるのをやめて毎日6時に起きるべきだと強く思うようになった。

朝活

Webデザイントレンドのよりみち の金朝ツメトギに参加した。今回から「つめとぎ」から「ツメトギ」のカタカナに名前変更してパワーアップ？したみたい。本を読んでもよかったんだけど、チャット欄でコメントしながら live をみてみようと思って普通に聴いていた。#金朝ツメトギ というハッシュタグは私がコメントして生まれた。コミュニティ的に盛り上げるならタイムラインを共有した方がよいとは思う。youtube live のチャットにコメントした方がいいか、twitter で気軽にコメントした方がいいか、まだよくわかってない。youtube のチャット欄のコメントの一覧性とか、普段使いのツールになっていないせいか、なんとなく抵抗感がある。いま参加者が少ないせいか、コメントするとスピーカーがコメントに反応して返答したりするので、あまりカジュアルに書き過ぎるとスピーカーの作業の邪魔にならないかな？とか思ったりもした。youtube live という勉強会の人間関係の距離感が難しい。

あと Facebook Connect 2021 というイベントがあることを教えてもらった。友だちに共有したら会社を休んで参加するとか言っているので私も参加してみることにした。どうしようか迷ってたけど、身近な人たちが参加するとつられるのかもしれない。

法人県民税と法人市民税の中間申告と納付

前日(というか今日)に4時まで起きてたのは申告書の内容確認や記入をしてたから。せっかく申告書を作成したのですぐ納付したくなった。それで新長田の合同庁舎まで申告に行ってきた。eltax は相変わらず windows 向けの DL 版でないと申告できそうにない。WEB 版もあって一部対応しているようだけど、よくよく調べていくと DL 版でしかできないようにみえる。毎年 WEB 版でできるようになっているかどうかを調べている。この互換性を調べるような作業を都度やるのが面倒になってきた。vr 用途 (oculus link を使いたい) にも使えるので windows マシンを購入してもいいかもしれないと考えるようになってきた。申告書を郵送してもよいけど、1時間もあれば往復できる距離なので気分転換も兼ねて合同庁舎に出向いてきた。

帰りに新長田駅の近くの三菱UFJ銀行の支店で納付する。前回は窓口納付をしたが、今回は STM (Store Teller Machine) での納付に初挑戦した。STM(Store Teller Machine)の存在意義とは のブログ記事にも書かれている通り、納付書を OCR でスキャンすることでどんな納付書でも対応できるという汎用性はすごいと思うものの、その裏で人間がチェックしているんじゃないかと思えるメッセージや引き落とす合計金額はユーザーが手入力で決定する (OCR で合計がどの金額かわからなかった場合のみ？) といったオペレーションになっていて、なんか全く自動化されてない感があって残念に思った。見た目上、機械化されているけど、運用には人手がかかっているようにみえた。まぁでも、初めて使ってみて経験としてはおもしろかった。

Jira のフィルターとリマインダー

所得税や住民税の納付は原則毎月納付する必要があるけど、小さい企業は納付の特例という制度があって6ヶ月単位にまとめて納付できる。小さい企業の事務手続きの工数削減を狙いとしてある制度だと思う。うちもその特例制度を利用して6ヶ月ごとに納付している。カレンダーに繰り返し予定として登録してあるのでカレンダーをみていれば見落とすことはないのだけど、そのときに都度チケットを作ってやるのも面倒なので納付の親チケットを作っておいて、子タスクとして毎回作業するようにしている。それをみていて、納付期限を設定しておいてリマインダーしたら課題管理システムっぽくていいなと思って Jira でのやり方を調べてみた。Jiraにて期限の近い課題の通知を受け取りたい というのがあって、任意の JQL で期限を調べるフィルターを書いて、そのフィルターに対してサブスクリプションというメール配信設定を行う仕組みになっている。これはこれでよくできたうまい仕組みだと思う。しかし、いまチケットのイベントに対してメールを送る設定は無効にしていて、Slack インテグレーションを使ってすべて Slack の通知チャンネルにイベントを流すようにしている。できれば、Slack インテグレーションで期限のリマインダーを通知できるのが望ましいた。公式の Jira Slack app だと、JQL でフィルターはできるけど、イベント発生時に通知する仕組みなので毎週フィルター実行するような用途には使えない。

たまたまそんな話しをツィートしてたら Jira API と Slack API を使ってスクリプトを書いているというのを教えてもらった。これはこれで便利そう。

こんな感じのスクリプトでJIRAからslackに通知してます https://t.co/UzeIZ9Nbol

— Takanori Suzuki (@takanory) October 22, 2021