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時間ほど寝てた。その後、また起きて夜の作業に入った。起きてからお腹すいて即席でめんつゆと醤油とかぼちゃとささみと卵で煮物を作ってみたら意外とおいしかった。お腹すいているとちょっとしたものでもおいしい。気に入ったのでカバー画像にしてみた。

0-1時ぐらいに寝て7時半に起きた。よく眠れたか眠れてないかもわからないような目覚め方をして少しぼおっとしてた。朝ゆっくりしてもいいかと思いつつ準備して移動したら9時前にはオフィスにいたので普通の日とそう変わらない一日の始めだった。夜にジョギング行こうかと思ってたけど、ちょうど通り雨が降ったりやんだりしててやめた。代わりに雨やんでからオフィス行って調べてものしてた。

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

7.3を読んで7章トランザクションを読み終えた。トランザクションの章は言葉も知らないし、あまりクリティカルなアプリケーションの開発に関わってこなかったのでそこまで意識したことがなかった。トランザクションで問題が発生する分離レベルと典型的なパターンが体系的に整理されていてすごく勉強になった。結果的にトランザクションを使わないとしても、トランザクションの要否や起きうる整合性の問題を理解しておくとデータ定義やアプリケーションの設計にも活かせる気がする。7章まで読んだ中でもっとも知らないことが多かった。約300ページなのでだいたい半分読み終えた。まだまだ先は長い。

トランザクションの開始時点でロックをかけるべきオブジェクトが存在せず、あるトランザクションでの書き込みが他のトランザクションの検索クエリの結果を変化させてしまう問題を ファントム と呼ぶ。ファントムの対策の1つとして、あらかじめそのデータを作っておき SELECT FOR UPDATE でロックを取得するやり方を 衝突の実体化 (materializing conflicts) と呼ぶらしい。グループウェアの開発をしていた頃、1つのスレッドしかトランザクションを実行できないことを保証するための切り札として、ロック用途のテーブルを設けておき、そのロックを獲得したスレッドだけ処理できるようにしていた。当時はわからなかったけど、あれは衝突の実体化という手法だったんだといま気付いた。

データベースのクラッシュや整合性に関する問題に対する信頼性を保つために、それらの問題を単純化するために、この数十年にわたって選択されてきた仕組みが トランザクション である。トランザクションは、アプリケーションが複数の読み書きを論理的な単位としてまとめる方法である。概念的には、トランザクション中のすべての読み書きは1つの操作として実行される。トランザクションは抽象化のレイヤーであり、アプリケーションはある種の並行性の問題や、ある種のハードウェアやソフトウェアの問題が存在しないかのように振る舞えるようになる。

トランザクションは全体として成功（ コミット（commit） ）もしくは失敗（ 中断（abort） 、 ロールバック（rollback） ）する。トランザクションが失敗した場合には、アプリケーションは安全にリトライできる。トランザクションは自然法則ではなく、データベースにアクセスするアプリケーションのためのプログラミングモデルをシンプルにするという目的を持って生み出された。トランザクションを利用すれば、ある種の潜在的なエラーの状況や並行性の問題はデータベースが面倒を見てくれるので、アプリケーションはそれらを気にしなくてよくなる（このことは 安全性の保証 と呼ばれる）。

トランザクションが提供する安全性の保証は ACID で示される。

原子性 (Atomicity)

• 原子（アトミック） はそれ以上小さな部分に分割できないものを指して使われる言葉
• マルチスレッドのプログラミングにおいては、あるスレッドがアトミックな処理を実行しているというなら、それは他のスレッドからはその処理の半分だけ完了した途中の状態を見る方法が存在しないことを意味する。システムが取りえる状態は、その処理が始まる前と終わった後の状態だけであり、その中間の状態になることはない
  • 前にメモリモデルの文脈で、あるプロセスが書き込み完了したデータが、他のプロセスからも確実に読めることをアトミックな操作と習ったことがある
• 原子性と並行性は関係がない
• エラーの際にトランザクションを中断し、そのトランザクションのすべての書き込みを破棄できることが、 ACID の原子性を決定づける特徴と言える
  • アプリケーションがリトライしても安全であることを保証する
  • 中断可能性（abortability） の方が原子性よりも良い言葉だったと思われる

一貫性 (Consistency)

• 一貫性は多くの意味で使われる
  • とくに日本語では整合性とも訳される
• 非同期のレプリケーションシステムでは結果整合性の問題が発生する (5章)
• コンシステントハッシュ法は、リバランシングのためにいくつかのシステムで利用されているパーティショニングのアプローチ
• CAP 定理では、一貫性という言葉は線形化可能性の意味で使われる (9章)
• ACID の文脈における一貫性は、データベースが「良い状態」にあることを示すアプリケーション固有の概念を指す

同じ言葉を少なくとも4つの異なる意味で使われている。ACID における一貫性という概念は、データについて常に真でなければならない何らかの言明（ 不変性 ）があることを指す。たとえば、会計システムの場合、すべてのアカウントでまとめれば常に貸方と借方は等しくならなければならない。この一貫性の概念はアプリケーション固有の不変性の概念に依存しており、一貫性を保つようにトランザクションを適切に定義することはアプリケーションの責任となる。原子性、分離性、永続性はデータベースの特性だが、一貫性は（ ACID という考え方においては）アプリケーションの特性である。したがって、 C は実際には ACID に属していない。

分離性 (Isolation)

多くのデータベースは、同時に複数のクライアントからアクセスされる。データベース中の同じレコードにアクセスするときに並行性の問題（レース条件［ race condition ］）が生じる可能性がある。データベース中に保存されているカウンタを、2つのクライアントが同時にインクリメントすると仮定する。それぞれのクライアントは現在の値を読み取り、1を加え、新しい値を書き戻す。ACID における分離性とは、並行して実行されたトランザクションがお互いから分離されており、お互いのつま先を踏みつけあうようなことがないという意味である。実際の運用では、パフォーマンスの制約から分離レベルによって保証される分離性が変わってくる。

永続性 (Durability)

データベースシステムが目的とするのは、データを失う恐れなく保存できる安全な場所を提供すること。永続性は、トランザクションのコミットが成功したら、仮にハードウェアの障害やデータベースのクラッシュがあったとしても、そのトランザクションで書き込まれたすべてのデータは失われないことを約束する。

用語の整理

トランザクションはデータモデルがどういったものであるかにかかわらず、価値あるデータベースの機能と言える。並行に実行されたトランザクションがお互いに影響しあわない分離性における保証を 分離レベル と呼ぶ。

• read committed
• スナップショット分離（repeatable read とも呼ばれる）
• 直列化可能

これらの分離レベルに対してトランザクションで発生する様々なレース条件がある。

• ダーティリード
  • あるクライアントが他のクライアントのまだコミットされていない書き込みを読める
  • read committed 分離レベル及びそれ以上に強い分離レベルはダーティリードは生じない
• ダーティライト
  • あるクライアントが他のクライアントによるまだコミットされていない書き込みの内容を上書きしてしまう
  • ほぼすべてのトランザクションの実装は、ダーティライトを生じない
• 読み取りスキュー（nonrepeatable read）
  • クライアントが異なる時刻にデータベースの異なる部分を見ること
  • この問題の最も一般的な回避策はスナップショット分離によるもので、これはトランザクションがある時点での一貫したスナップショットから読み取りを行えるようにする
  • 通常、MVCC（multi-version concurrency control）を利用して実装される
• 更新のロスト
  • 2つのクライアントが並行して read-modify-write サイクルを実行するとき、片方が他方の書き込みをその変更内容を考慮せずに上書きしてしまい、データが失われること
  • スナップショット分離レベルの実装にはこの異常を自動的に回避してくれるものもあるが、明示的なロック（ SELECT FOR UPDATE ）をしなければならない実装もある
• 書き込みスキュー
  • トランザクションが何かを読み取り、その値に基づいて判断を下し、その結果をデータベースに書き込む
  • この状況で、書き込みが行われた時点で判断の根拠となったプレミスが真ではなくなっている場合を指す
  • 直列化可能分離レベルのみがこの異常を回避できる
• ファントムリード
  • トランザクションが何らかの検索条件にマッチするオブジェクトを読み取り、他のクライアントはその検索結果に影響する書き込みを行う
  • スナップショット分離レベルは単純なファントムリードを回避してくれるが、書き込みスキューを伴うファントムに対してはインデックス範囲ロックのような特別な対応が必要となる

弱い分離レベルは、これらの異常のいくつかを防いでくれるが、それ以外はアプリケーション開発者に対処する必要がある（たとえば明示的なロックなど）。すべての問題に対する保護を提供してくれるのは直列化可能分離レベルのみ。直列化可能なトランザクションの実装方法は、3 種類ある。

• トランザクションを順次実行する
  • それぞれのトランザクションをきわめて高速に実行でき、加えて単一の CPU コアで十分処理できる程度にトランザクションのスループットが低いのであれば、これはシンプルで効果的な選択肢となる
• ツーフェーズロック
  • 数十年にわたって直列化可能分離レベルの実装において標準的な方法であった
  • パフォーマンス上の特性から多くのアプリケーションがツーフェーズロックの利用は避けている
• 直列化可能スナップショット分離（SSI、serializable snapshot isolation）
  • 新しいアルゴリズムであり、これまでのアプローチが持つ欠点のほとんどを回避している
  • SSI は楽観的アプローチを取っており、トランザクションはブロックされることなく処理を進められる
  • トランザクションはコミットの時点でチェックされ、その実行が直列化可能になっていなければ中断される

改正法人税法等の説明会

改正法人税法等の説明会 に参加してきた。所感からまとめるとこんな感じ。

• 神戸文化ホールについて
  • 電源がない
  • FREESPOT が提供されていてフリー wifi として利用できるが、通信品質は不安定
    • スマホでテザリングもやってみたが、電波状態がよくなくてもっと不安定
  • ラップトップ向きの場所ではない
• 税制を身近にするイベントとしては参加してもよい
• もらった資料をたんたんと説明するだけなのでイベントに参加することで得られる付加価値はとくにない
• 気分転換や時間があれば参加すればいい、忙しかったら参加しなくてもよさそう

公益社団法人 神戸納税協会 という組織がある。年会費 (うちの会社だと7,800円) がいるのでいまは入らないけど、無料税務相談があるので余裕ができたら困ったときの相談相手になってもらう意図で入会してもよいかもしれない。冒頭の神戸税務署長の挨拶で法人税の申告における e-tax の利用率は 88.4% だと話してた。うちは紙で申請しているので意外とみんな e-tax 使っているんだなと自社を恥じた。だって Windows マシンないとできへんねんもん。参加したことによる学びとして書いていくとこれらかな。

• 「研究開発費」は会計上の用語、「試験研究費」は税法上の用語
• DX 投資促進税制の創設

内容は基本知らないことなので、知らないことに触れるイベントという点では斬新ではあった。ほうほうと聞いてただけなんだけど。直接うちの会社に影響を与える税法の改正はインボイス制度ぐらいかな。

いつ寝たのか覚えてないけど、スマホをみたら1時過ぎに寝て6時に起きたことになっている。だいたいいつも5-6時には一度目が覚める。そのまま起きるときもあれば起きないときもある。今日はちゃんと起き上がったのは7-8時ぐらいだった気がする。夜にジョギング行こうかとも考えていただけど、帰って先に晩ご飯食べたら疲れてそのままだらだらしてた。

エージェント面談

そろそろ次のお仕事を探す準備のために エンジニアファクトリー というサービスに登録してみた。KOBE JOB PORT で紹介されていたのをみつけた。前に Remogu さんで探していた ように、プロジェクトマネージャー案件か、リモートワークの開発者案件を探している。マネージャーだと常駐系の方が多かったり、実務経験必須だったりすることが多いため、神戸から通える範囲の案件も探してみようという意図になる。だいたいこんな内容を話してた。

• 職務経歴の内容から個人を特定できないよう、エージェントがブラインド化した資料を企業に公開する
• 単価が高い案件は東京の会社のリモートワークに多い
• 契約は準委任契約がほとんどである
• 法人として契約もできる
• 6ヶ月や1年といった短期開発案件も多い

求職者の情報を匿名化する背景は、企業が直接交渉するのを避けるためなのかな？求人プラットフォームごとに情報入力しないといけないのが面倒なところ。

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

7章トランザクションのうち、7.1と7.2を読んだ。トランザクションの章は内容も難しく量も多いので2日にかけて読むことにする。昔、業務アプリケーションやグループウェアを開発していたときはトランザクションを意識してコードを書いていたけど、Web アプリケーションを開発していると、あまりクリティカルな処理を実装することが少ないせいか、トランザクションをそんな意識しなくなったなと漠然と思えた。Cassandra だとトランザクションもないし。非同期 + 結果整合性で運用できるアプリケーションであればトランザクションいらないというのはそうなのかもしれない。

3時に寝て8時半に起きた。夜眠れなくて、野菜サラダに目玉焼きをのせて食べたり、お茶をわかしてボトルに入れ替えたりしてた。休日だと時間に余裕があるせいか、空き時間に自炊してなにか作ることが多い。

豆苗の再生栽培

朝ご飯は野菜サラダと納豆を、お昼ご飯は豚肉としめじと2回目の豆苗を炒めたものを目玉焼きでとじたものを食べた。豆苗のパッケージに食べた後の根を水に浸しておけばまた生えてくるとあったので試しにやってみた。キッチンという日当たりのよくない場所で育てたせいか、薄い緑色の苗が生えてきた。

今回は適当に育てた。再生栽培のコツ を読んで次はもうちょっとちゃんと育ててみよう。

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

6章パーティショニングを読んだ。昔からパーティショニングとシャーディングの違いはなんだろう？と漠然と思っていた。パーティションの設計 を読むと、3つのパーティション分割があげられている。

• 水平的パーティション分割 (シャーディング)
• 列方向のパーティション分割
• 機能的パーティション分割

パーティショニングは大規模なデータセットをデータ分割するための手法または概念として広い意味をもって使われるように読める。一方でシャーディングと呼ばれるものは水平パーティショニングのことを指している。いま分散データベースで一般的に使われている仕組みがそうなのかもしれない。本書では水平・垂直のパーティショニングの定義は行われていないが、次の説明が出てくる。おそらく主に水平パーティショニングを意図しているのではないかと思う。まとめはこんな感じ。

用語の混乱

ここで パーティション と呼んでいるものは、 MongoDB 、 Elasticsearch 、 SolrCloud では シャード と呼ばれています。これは HBase では リージョン 、 Bigtable では タブレット 、Cassandra や Riak では vnode 、 Couchbase では vBucket と呼ばれています。とはいえ最も確立されている用語は パーティショニング なので、本書ではこの呼び方を使っていきます。

パーティショニングも普通に開発をしていたらデータベースの設計で必要になるので身近な概念と言える。だいたいは知っている内容ではあったけど、パーティショニングとセカンダリインデックスの仕組みとか考えたことがなかった。Cassandra ではセカンダリインデックスをうまく設計しないとパフォーマンスに影響を与えることからあまり使われない傾向にあると思う。

大規模なデータセットを小さな部分集合にデータ分割することをパーティショニングと呼ぶ。パーティショニングが必要になるのは、単一のマシンで保存や処理をするのが現実的ではないほどのデータがある場合になる。パーティショニングが目標とするのは、データやクエリの負荷を複数のマシン間で均等に分配し、ホットスポット（不均衡に高い負荷がかかるノード）が生じないようにすること。パーティショニングが均等になっておらず、一部のパーティションが他に比べて多くのデータやクエリを受け持っているような状態は スキュー（skew） と呼ばれる。そのためには、データに適したパーティショニングのスキームを選択し、クラスタへのノードの追加やクラスタからのノードの削除が生じたときにパーティション群をリバランシングする。

パーティショニングのアプローチとして主に2つがある。

• キーの範囲によるパーティショニング
  • キーはソートされ、1つのパーティションには何らかの最小値と最大値の間にあるすべてのキーが保存される
  • キーをソートすることで、範囲に対するクエリが効率的に処理できるというメリットがある
  • アプリケーションが頻繁にアクセスするキーがソート順の中で近接していると、ホットスポットが生じるリスクがある
  • 通常このアプローチでは、パーティションのリバランシングはパーティションが大きくなりすぎたときにその範囲を2つに分割することによって動的に行われる
• ハッシュパーティショニング
  • ハッシュ関数がそれぞれのキーに対して適用され、1つのパーティションにはハッシュの一定の範囲を保存される
  • この方法ではキーの順序が失われるので範囲に対するクエリは非効率になるが、負荷分散より均等にしやすい
  • ハッシュによってパーティショニングを行う場合は、事前に固定数のパーティションを作成し、各ノードに複数のパーティションを割り当てておき、ノードの追加や削除が行われた場合にはパーティションをそのままあるノードから他のノードに移動させるのが一般的となる。また、動的パーティショニングも利用できる

ハイブリッドなアプローチを取ることもできる。たとえば複合キーを使い、キーの一部でパーティションを決め、他の部分でソート順を決めるといったやり方がある。Cassandra のプライマリーキーはこのアプローチを採用している。また、セカンダリインデックスもパーティショニングする方法が2つある。

• ドキュメントによってパーティショニングされたインデックス（ローカルインデックス）
  • セカンダリインデックスをプライマリキー及び値と同じパーティションに保存する
  • 書き込みの際に更新しなければならないパーティションが1つですむ
  • セカンダリインデックスの読み取りにはすべてのパーティションに対する スキャッタ/ギャザー が必要となる
• 語によってパーティショニングされたインデックス（グローバルインデックス）
  • セカンダリインデックスはインデックスが張られた値を使って独立にパーティショニングされる
  • セカンダリインデックスのエントリには、プライマリキーのあらゆるパーティションのレコード群が含まれる
  • ドキュメントが書き込まれる際には、セカンダリインデックスの複数のパーティションを更新しなければならない
  • 読み取りは単一のパーティションだけで処理できる

クエリを適切なパーティションにルーティングする手法は、データベースに限った話題ではなく、サービスディスカバリ と呼ばれる一般的な問題である。有名な OSS として ZooKeeper がある。これにはシンプルなパーティションを認識するロードバランシングから、洗練された並列クエリ実行エンジンまで様々である。すべてのパーティションは、ほぼ独立に動作できるように設計されている。パーティショニングされたデータベースが複数のマシンにまでスケールできるのはそのおかげである。

0時に寝て6時に起きた。だいたい夜中に2-3回は起きるのが普通になりつつあって、前日ジョギングしてたせいか腰やお尻の筋肉に張りがあったので3時頃起きてストレッチして張りの箇所を伸ばしたりしながら寝てた。午前中、いけさんから上等なお酒をいただいた。造り酒屋の一族らしい。感謝。

朝活

朝起きる目的にいいかも？と思って Webデザイントレンドのよりみち の金朝つめとぎに参加してみた。やっぱり目的があれば6時に起きれる。でも、終わってから1時間ほど寝てたので今日はプラスマイナスゼロ。前回の朝活 と同様、ミクロ経済学の入門書を読んでた。第2章の予算線と最適化を読んだ。経済学とはこういうものだという説明が腑におちた。当たるかどうかよりも考え方を理解しておく方が大事なように思えた。

ときどき経済学に対して「経済学が想定するほど実際の消費者は懸命に選択しているとは限らない」といった批判がなされることがある。でもこれまでの説明から明らかなように、その批判は勘違いにもとづくものだ。批判したいなら「経済学は、消費者がはたから見て確実に愚かな選択をしても、それを非難しない傾向が強い」というほうが適切だろう。

もう1つおもしろかったのがこの一節。

予算線と選好を用いたミクロ経済学的分析は、現金給付のよさを指摘する。ただし、制度の悪用、人々の支持、必要原理といったことを考えると、現物給付のほうが好ましいとなる。現金給付と現物給付のどちらが総合的によいのか、これらの話だけで結論づけることはできない。とはいえここで、ミクロ経済学が有用な政策分析ツールたりえること、またミクロ経済学だけで政策を論じるのは不十分ということが分かったのは十分な収穫である。

人間の活動を予測するような学問の便宜上、前提条件や制約を課している。経済という人間にとって重要な社会システムを扱う経済学への期待値が大き過ぎるがために経済学の言うことが当たった・当たってないといった議論になりがちなのかもしれないと思えた。

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

5章レプリケーションを読んだ。200ページ超えたことで1/3を読み終えた。まだまだ先は長い。

シングルリーダーレプリケーションは一般的なものだし、Cassandra の運用をしていたのでリーダーレスレプリケーションもだいたいは知っていた。並行書き込みの問題は意識したことがなかった。そういう状況が発生するアプリケーションにおいてはとても難しい問題なことが理解できた。Cassandra で採用されている衝突解決アルゴリズムは 最後の書き込みを勝たせる（last write wins、LWW） というものであり、これで十分なように考えていたけど、不十分なケースもあることがわかった。

レプリケーションとは、ネットワークで接続された複数のマシンに同じデータのコピーを保持しておくこと。

• データを地理的にユーザーの近くで保持しておく => レイテンシを下げる
• 一部に障害があってもシステムが動作し続けられる => 可用性を高める
• 読み取りクエリを処理するマシンをスケールアウトする => スループットを高める

レプリケーションはいくつかの目的で使われる。

• 高可用性/耐障害性
• レイテンシ
• スケーラビリティ

対象のデータが時間が経っても変化しないのであれば、レプリケーションは容易。単にデータのコピーを各ノードに一度だけコピーすれば完了するから。レプリケーションの難しさは、すべてレプリケーションされたデータへの変更の扱いから生じる。変更をノード間でレプリケーションするのに広く使われているアルゴリズムは次の3つになる。

• シングルリーダーレプリケーション
  • クライアントはすべての書き込みを1つのノード（リーダー）に送り、リーダーはデータ変更イベントのストリームを他のレプリカ（フォロワー）に送る
  • 読み取りは任意のレプリカから行えるが、フォロワーから読み取るデータは古い可能性がある
• マルチリーダーレプリケーション
  • クライアント群は、それぞれの書き込みを複数あるリーダーノードのいずれかに送信する
  • これらのリーダーノードはどれも書き込みを受け付ける
  • リーダー群は、データ変更イベントのストリームをお互いに、そしてすべてのフォロワーノードに送信する
• リーダーレスレプリケーション
  • クライアントは、それぞれの書き込みを複数のノードに送信し、古いデータを持つノードを修正するために読み取りを複数のノードから並列に行う

データベースのレプリケーションの原理は1970年代から研究されていてそれほど変わっていない。とはいえ、分散データベースがメインストリームで利用されるようになったのは最近のこと。アプリケーション開発者の経験不足により 結果整合性 のような問題に関しては多くの誤解が生じた。いずれのレプリケーションのアプローチにもメリットとデメリットがある。シングルリーダーレプリケーションは理解しやすく、衝突解決を気にする必要がないことから、広く使われている。マルチリーダーとリーダーレスのレプリケーションは、ノードの障害、ネットワークの障害、レイテンシのスパイクがあっても頑健になる。しかし障害の理由を説明するのが難しく、一貫性についても弱い保証しか示せない。

レプリケーションは、 同期 で行うことも 非同期 で行うこともできる。どちらにするのかは、障害があったときのシステムの振る舞いに大きく影響する。非同期のレプリケーションは、システムがスムーズに動作しているときには高速に動作するが、重要なのはレプリケーションのラグが大きくなったり、サーバーに障害が生じたりしたときに何が起こるのかを理解しておくことになる。リーダーに障害が発生し、非同期に更新されていたフォロワーを新しいリーダーに昇格させたら、直前にコミットされたデータは失われてしまう可能性がある。

レプリケーションラグが生じている状況下でアプリケーションがどのように振る舞うべきなのかを決める際に役立つ一貫性モデル。

• 書き込み後読み取り (read-your-writes)
  • ユーザーは、自分自身が投入したデータを常に見れる
• モノトニック読み取り (monotonic reads)
  • ある時点のデータをユーザーが一度見たら、それ以前の時点のデータは見れない
• 一貫性のあるプレフィックス読み取り
  • ユーザーは、たとえば質問とその質問への回答を適切な順序でといったように、適切な因果関係を保持した状態でデータを見れる

マルチリーダーとリーダーレスのアプローチは本質的に並行性の問題を抱えている。複数の書き込みが並列に行われることがあるので、衝突が生じる場合がある。ある操作が他の操作よりも先に行われたのか、あるいはそれらが並行して行われたかを判断するためのアルゴリズムについて説明されている。

Slack apps の調査

Workstreams.ai を試してみた。

Results-driven task management for Slack, Microsoft Teams and Google

結果駆動タスクマネジメントという聞いたことない用語が書いてある。SaaS 型の Web アプリケーションとしての課題管理システムとチャットツールとの連携が密になったプロダクトにみえる。UI もよく作り込まれている。Workstreams.ai のアカウント管理は Sign in with Slack を使っている。ドキュメントによると openid connect と oauth 2.0 の仕組みを組み合わせているのかな。認証よくわかってないので背景も勉強しないといけない。簡単にタスク作成やコメント、更新などを Slack クライアントと Web アプリケーション上で触ってみた。

もう1つ Google Sheets for Workflow Builder というのも試してみた。ワークフロービルダーのステップに簡単に Google Sheet との連携を実装できるのでめっちゃ簡単。ワークフロービルダーは本当によくできているな。

ジョギング

今日は調子はよかったけど、お仕事の区切りがよかったので19時に終えて近所の公園にジョギングしてきた。昨日も走ってたのでやや筋肉痛が残りつつ、走り始めは筋肉がきしむ感じだったけど、走っているうちに体があたたまってきて気にならなくなった。時間帯は同じだけど、昨日より陸上部の人たちが半分ぐらい少なかった。曜日によって違うのかなぁ。

0時過ぎに寝て7時に起きた。けれど、なんかしんどくて起き上がれなくてそのまま2度寝した。1時間ほど寝たらすぐに起きれた。あのしんどさは何だったのか。とはいえ、気付いたら8時半にはオフィスにいたので普段の仕事始めと変わらない見た目になった。お昼に体温を測っていたら37.1℃になってたので熱っぽい雰囲気。日中は特にしんどくはないんだけど。

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

4章エンコーディングと進化を読んだ。だんだん内容が難しくなってきて読むのに時間がかかる。これで第一部のデータシステムの基礎を読了した。4章のまとめ。

データシステムの変更のしやすさ、アジリティのことを本書では 進化性 を呼んでいる。

進化性を高めるには、システムのバージョンアップが容易にできなくてはならない。このとき、サーバーサイドアプリケーションは、大抵の場合、一度にすべてのノードをのバージョンアップができないことから、 ローリングアップグレード という手法を用いる。ローリングアップグレードを可能にするには、データフォーマットやスキーマの変更に対して、新旧どちらのフォーマットも、新旧どちらのコードからも扱えないといけない。データフォーマットやスキーマの 前方/後方互換性 を維持することが進化性を高めることに大きく影響する。

メモリを共有していないプロセス間でデータを渡すとき、そのデータをバイト列へエンコードしないといけない。通常プログラムはデータを (少なくとも) 2つの異なる表現で扱う。

1. CPU によるアクセスや操作が効率的になるよう最適化されてメモリ内で表現される
2. ファイルやネットワーク経由でデータをやり取りするにはバイト列にエンコードしないといけない
   この表現はメモリ内のデータ構造とはまったく異なる

この2つの表現の間で何らかの変換が必要になる。インメモリの表現からバイトの並びへの変換は エンコーディング (シリアライゼーション、マーシャリングとも呼ぶ) 、その逆は デコーディング (パース、デシリアライぜーション、アンマーシャリングとも呼ぶ) と呼ぶ。

データエンコーディングフォーマットと、それらの互換性に関する特性。

• プログラミング言語固有のエンコーディングは1つのプログラミング言語に限定され、しばしば前方及び後方互換性を欠く
• JSON, XML, CSV といったテキストフォーマットは広く利用されており、その互換性は利用の方法に依存する
  • オプションのスキーマ言語はあるが、それらは助けになることもあればむしろ障害になることもある
  • これらのフォーマットはデータ型について多少の曖昧さがあるので、数値やバイナリ文字列などについては注意が必要
• thrift, protocol buffers, aro といったスキーマを持つバイナリフォーマットではコンパクトで効率的なエンコーディングが可能であり、前方及び後方互換性のセマンティクスも明確に定義されている
  • これらのスキーマは、ドキュメンテーションと静的型付き言語でのコード生成に役立つ
  • ただし、バイナリフォーマットにはデコードしなければ人にはデータが読めないという欠点もある

データフローの形態とエンコーディング。

• データベースでは、データベースへの書き込みを行うプロセスがデータをエンコードし、データベースからの読み取りを行うプロセスがそのデータをデコードする
• RPC と REST API では、クライアントがリクエストをエンコードし、サーバーはそのリクエストをデコードしてレスポンスをエンコードする。そして最後にクライアントがレスポンスをデコードする
• 非同期のメッセージパッシング（メッセージブローカーあるいはアクター）では、ノードはお互いにメッセージを送信することによって通信し、送信側がメッセージをエンコードし、受信側がそのメッセージをデコードする
  • kafka などを使ったイベント駆動アーキテクチャはこの形態になる

多少の注意を払うことで前方/後方互換性やローリングアップグレードは十分に実現可能となる。

霖 (ながめ)

プロダクトの名前を考えるために万葉集を眺めてた。ふとみつけた 霖 ということばを気に入った。一文字だと「ながめ」または「ながあめ」と読む。霖雨と書くと「りんう」と読むらしい。万葉集では次の和歌で詠まれている。和歌では「長雨」と「眺め」をかけて使うのが常套句らしい。また古文でいうところの眺めはぼんやり見ながら物思いに耽るという意味になるそうだ。

4217 卯(う)の花を　腐(くた)す霖雨(ながめ)の　始水(みずはな)に　寄るこつみなす　寄らむ児(こ)もがも　大伴家持

(現代語訳) 卯の花を腐らせるほどに痛めつける長雨、この雨のせいで流れ出す大水の鼻先に寄りつく木っ端のように、私に寄り添ってくれる娘でもいてくれたらなあ

新版　万葉集　四　現代語訳付き

この季節の長雨には「卯の花腐し」という別名があります。画像は改元でも話題となった『万葉集』より「卯の花を腐す霖雨の…」という大伴家持の和歌。初夏の卯の花が枯れてしまうような長雨の表現です。詳しくは7月から始まる企画展「雨に詠えば―空模様の古典文学―」にて！ https://t.co/ZyU1h8TyNv pic.twitter.com/VaXKX0FGEI

— 国立公文書館 (@JPNatArchives) May 21, 2019

ジョギング

あまり調子がよくなかったので19時にお仕事を終えて近所の公園にジョギングに行ってきた。ワクチンを接種してから運動を控えていたのでジョギングしたのは初めてかな。2-3日に1回ぐらいの頻度でジョギングしている。ワクチン接種した週はウォーキングに留め、次の週は実家で田んぼ仕事でバテてて、今週は初めて行ってきた。ちょっと早い時間帯だったせいか、2つの陸上部が練習していてやや人が多かった。400m級のトラックがあって陸上部の人たちが練習している。練習の邪魔にならないよう、トラックの内側を20-30分とぼとぼジョギングしている。疲れたら歩きながらなのでそんなに距離は走ってない。ジョギング終えてから30分ぐらいストレッチをした。

2時頃に寝て6時に起きる。普段、日記は vim で書いている。ちょっとした過去の日記の検索に vimgrep でこと足りるのが嬉しい。テキストで日記を書いていることの利点かな。夜に fin-pyコードリーディング会#4 に参加した。事前に hackmd に発表内容のメモを書いてた。いろんな発表者の視点があってコードリーディングのイベントはおもしろかった。

朝活

【三宮.dev オンライン】リモート朝活もくもく会 に参加してみた。何もなかったらだいたい7時頃に起きるのがなにか目的があると6時に起きれる。人体の不思議。せっかく起きたので 前に More Joel on Software を読んだとき に学生向けのアドバイスにあったミクロ経済学の勉強のためにその入門書を読み始めた。参加者が勉強会の常連ばかりだったので朝からわりと雑談してた。2人転職するという話で2人とも東京の会社でフルリモートワークで働くらしい。働き方が変わったなと感じる。その後、第1章の無差別曲線を読んだ。

YouTube 配信と集中力

あんちぽさんの 2021年10月9日 の日記でスライド作成の興がのらないので YouTube 配信しながらやったら集中できてよかったと書いてあったのでちょっと眺めてみた。なんかスライドの作成のやり方とか、自分と違うのかな？とか思いながらみたけど、やり方自体は普通だった。ただ集中できてよかったとあるので普段のやり方とは異なることをすることに意義があるのかな？とも思えた。試しに YouTube Live やってみようとしたら初期設定？に24時間かかるとのこと。代わりに kazam というスクリーンリコーダーの使い方を調べてた。勉強会で作業したログとかを録画しておいてなにかに使えたりするかもしれない。

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

半日ほどかかって3章ストレージと抽出を読んだ。読みながら書いているので時間がかかる。今日はこれだけ。まとめはこんな感じ。

データベースのシステムには2つの用途があり、その特性やパフォーマンスを最適化するためにストレージエンジンやデータ構造が異なるもので運用されるようになってきた。

• オンライントランザクション処理 (OLTP)
  • 行指向、トランザクション処理
• オンライン分析処理 (OLAP)
  • 列指向、分析クエリ

OLTP には2つの主要なストレージエンジンがある。

• B ツリー
  • 1970年代からあり、成熟していて且つ効率的なインデックスのデータ構造
• LSM ツリー
  • 比較的最近開発された、ディスク上でのランダムアクセスをシステム的にシーケンシャルアクセスに変換して、書き込みのスループットを高める手法。もとは Google の BigTable の論文？

OLAP の典型的なデータウェアハウスの高レベルでのアーキテクチャでは、大量の行をシーケンシャルにスキャンしなければならないクエリの場合、インデックスはあまり関係なく、データを非常にコンパクトにエンコードし、クエリがディスクから読まなければならないデータの量を最小限にとどめることが重要となる。この目標を達成するのに列指向のストレージが役立つ。

過去に Cassandra を使ったプロダクトの開発に関わっていたから B ツリーと LSM ツリーの概要は知っていて3章で書いてあることはだいたい理解できた。データウェアハウスに関しては、前にお手伝いしていた会社で普通のログを Amazon Athena で処理すると1時間とかかかって分析クエリが Parquet に変換すると数分で完了したりするのを目の当たりにしてた。分析処理で読み込むデータ量を削減する列指向の考え方は理解しておく必要がある。行指向のデータを列指向フォーマットである Parquet に変換する columnify のコードも読んだことがあったので内容のイメージはできるけど、実務経験が少ないと全体像がわかっておらず、本書を読みながら学び直ししてた。

昨日は1時半に寝て7時半に起きた。なんか疲れが溜まっているのか寝不足なのか、しゃきっとしなくて15時頃にお昼ご飯食べてきて、戻ってきて2時間ほど寝てた。夕方に寝ると夜の睡眠が悪くなるかもしれない。

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

データ指向アプリケーションデザイン -信頼性、拡張性、保守性の高い分散システム設計の原理

先週末から読み始めようと思いつつ、ダラダラしていて今日から読み始めた。600ページ超と分量が多いので少しずつ読んでいく。買ったのは2019年7月なので2年越しの積ん読。前職で書籍購入の補助制度があったのでその予算消化のために買ったみたいなもの。でも買っておくといつか読むので買っておいてよかった。今日は2章まで読んだ。

「データ指向」という用語は、cpu のデータ処理がボトルネックとなり、且つそのデータ量や複雑さなどが主な課題となるアプリケーションのことをデータ指向と定義している。ソフトウェアシステムにおける3つの課題。これはすべて非機能要件になる。

• 信頼性
• スケーラビリティ
• メンテンナンス性

リレーショナルデータベースと NoSQL の台頭から始まり、ドキュメントデータベースやグラフデータベースの概要やリレーショナルデータベースとの比較などが書いてある。また NoSQL 系のデータベースのクエリ言語とか、よく知らないので勉強になった。12章あるので1日1-2章ぐらいのペースで今月中に読めたらいいや。

Slack のワークフロービルダーの調査

今度、勉強会をするので調べ始めた。ワークフロービルダーは簡単に定型的な処理を作成できるけど、有料プランでしか使えないのでコミュニティなどでは使いにくい。試しにいくつかワークフローを作ってみて感触を理解した。おそらくワークフロービルダーは Slack app を作成するためのフレームワークにみえる。作成したワークフローの1つ1つが Slack app になるのではないか。

• https://github.com/t2y/python-study/tree/master/BizPy/slack/20211027

Slack native? first? な課題管理システムもいくつかみつけた。非開発者に課題管理システムを使ってもらうのはかなり難しいので Slack と課題管理システムが連携すれば課題管理の方法論に新しい価値が出てくるのではないかと考え始めた。この機会に Slack app で構築されば課題管理システムも調べてみようと思う。

0時に寝て6時に起きる。昨日も田んぼ仕事の疲れが残っていたのでよく眠れた。1週間で6時頃に起きる癖がついたのですぐに起きれた。

Terminal のカスタマイズ

昨日からいくつか修正をしていた。

• 画像のパス問題の修正
• favicon の追加
• タグ一覧リンクの追加
• atom フィードに icon 要素の追加 (feedly では読み取れない)

atom フィードに favicon を指す要素を埋め込んでみたんだけど、feedly ではダメっぽい。たまたまヒットした GitHub issue でもそういったコメントをみかけた。

• https://github.com/huginn/huginn/issues/1628#issuecomment-882103625

ストレッチ

毎週土曜日はストレッチの日。田んぼ仕事のおかげで全身軽い筋肉痛になっている。ストレッチを受けると、いつものときとの違いから、股関節から右ももと腕の筋肉がすごく張っているのに気付く。田んぼのような突発的に体を動かして疲労が溜まったときにもストレッチでほぐせるのがよい。今日の開脚幅は開始前169cmで、ストレッチ後170cmかな。前より少し落ちたのは田んぼ仕事に疲れて平日にあまりストレッチが出来なかったのと筋肉痛のせいかもしれない。

Joel on Software

本当は実家に帰っているときに書き上げようと考えていたものの、田んぼ作業での疲れと実家のパソコンを使って作業する環境の悪さから書くことに集中できなくなって断念していた。集中できる環境なら3時間ほどで書けた。動機づけよりも価値観、価値観がブレないならその次は集中できる環境作りにこだわっていきたい。

• https://t2y.hatenablog.jp/entry/2021/10/09/162618

職務質問

買いものして帰ろうとしてたら警察官に止められて職務質問をうけた。自転車の盗難が多いので防犯登録を調べたいとのこと。はいはいって感じで免許証を提示する。自転車は東京で購入したもので10年以上乗っている。防犯登録は警視庁になっているらしく、兵庫県警の警察官では調べられないみたい。次に車体番号も読み取って調べていたけど、よくわからなかったみたい。結局、私が本物の持ち主とその場で調べることができなくて、警察官もたぶん本物だと思いますみたいな歯切れの悪い結果で職務質問を終えた。仮にその自転車が盗難にあってもその防犯登録から私を辿ることはできないので近所の自転車屋さんで防犯登録入り直してくださいと言われた。あー、またこの件か。都道府県の防犯登録のシステムが全国で統合されていればいい話しなのに、なんで引っ越したら防犯登録をやり直さないとあかんねんと。現場の警察官に言っても仕方ないので何も言わないことにした。

プロコン

たまたまタイムラインでみかけてちょっと眺めてた。動画で同じ内容をみて、ハラスメントを問題視する人と、プロダクトの新規性について言及する人がいて、感じ方は人それぞれだなぁと思いながら ハッシュタグ を眺めてた。

3時に寝て4時半に起きる。ほとんど寝てない。蚊がいて飛んでいるのが気になったり刺されてかゆかったりして寝るの諦めた。もう涼しくなって大丈夫かと思ってたけど、まだ蚊取り線香が必要だった。

畑の水やり

6時半から7時半まで。玉ねぎ、茄子、大根、ミニトマトなど、いろいろ野菜が植えてある。玉ねぎはいま芽が出てきたところで水をたくさんやらないといけないらしい。

Joel on Software

書評の続き。空き時間に少し書いた。実家だとオフィスより環境がよくないので集中力が下がり、その結果として効率が落ちる。本書の中でもオフィスのこだわりの章があったけど、環境が大事ということが実感できた。

田んぼの草刈り

午後から草場となった田んぼの草刈り。ある程度草を刈っておかないとトラクターの爪に巻き込むので耕すことができない。草刈機で刈り取りつつ、それを集めてきて、乾かして焼く。焼畑農業みたいなことをしないといけない。刈ったばかりの草は水分を含むのですぐには焼けない。一方で乾いた草はよく燃えるので燃え拡がってしまう。下手すると周りに燃え拡がって火事になってしまう。刈り取った草の集約や配置を調整しないといけない。日中、暑かったし、あまり寝てなかったから夕方は眠くてバテてた。

0時に寝て9時頃に起きる。今朝は寝起きが悪くてベッドでぐだぐだしてた。ダイの大冒険をみて家事をした。数日、家を空けるので冷蔵庫の中を空にして、洗いものやゴミの始末をする。11時半頃にオフィスに着く。

OMRON connect

グラフは今週の平均体温の推移を示したもの。ワクチン摂取後の体温は36.5-37.0℃の間を行ったり来たりしているものの、体調はまったくしんどくないのであまり気にしてない。そもそも摂取後に体温を測り始めたので自分の平熱がどのぐらいなのかすら把握してないことに気付いた。音波通信体温計 MC-6800B　けんおんくん を使っていて OMRON connect というスマホアプリで計測した体温を記録できる。

Joel on Software

書評を書き始めた。自分が学んだところや関心をひいたところは、読みながらメモ書きで課題管理システムのチケットに書いてある。それらを見返しながら、一般向けの書評にまとめる。自分にしかわからない内容を補足したり、見返すと言及するほどではないことを取り除いたり。あとは書く根気と時間次第になるわけだが、いまは時間がたっぷりあるので比較的、時間がかかっても学びの質をあげるためになるべく書くようにしている。5時間ほどかけて1/3ぐらい書けた。まだ途中。

実家へ

16時30分の高速バスで実家へ帰る。18時前ぐらいに実家の最寄りのバス停につく。そこから車で10分ほど。片道が2,090円で、往復券だと割引で3,760円になり、420円お得になる。この距離だと大した金額ではない。東京にいたら新幹線が往復で3万円ほどで、乗り継ぎの時間を入れると移動時間も6-7時間になってしまう。東京から神戸に戻ってきた理由として実家に気軽に帰りやすいというメリットがある。

今回の帰省の目的は田んぼの一部が草場になっているので耕さないといけない。本当は9月中にやりたかったが、天候とワクチン摂取などを調整してたら10月になってしまった。自分の会社でよいのは、(他社の仕事を受けてなければ) 自分の都合で休日・平日関係なく業務の調整ができること。来週は実家の雑務: 田んぼや裁判の傍聴などをやりながら隙間に会社の仕事をする。