4-5時に6時に起きた。寝られなかったというよりは寝る気がなくて3時頃にお茶を沸かして冷ましたりしてた。6時から 【三宮.dev オンライン】リモート朝活もくもく会 に参加してメンバーと雑談してた。もはや朝活というよりは雑談会になっているw 普通に起きたら7時まわってから起きるのが、イベントがあると6時に起きれるのでそれはそれで早起きするモチベーションになっていいかとは思っている。とはいえ、お昼やっぱり眠くなって1時間ほど昼寝した。昨日あまり寝てなかったら夜も集中力なくなってバテた。

Slack apps の調査

日記に書くの忘れてた。さらに3つのアプリを試してみた。

ToDoBot

Task Management App for Slack

これは基本的には個人向けのタスク管理ツール。タスクをグルーピングする機能をもっているのでそれを共有することでチーム単位でも使えるとは思うけど、あまりチーム向けに機能が用意されているようにはみえない。

Sidequest

Meet the Missing Task Manager for Slack.

個人/グループのタスク管理とチームでタスクを共有する用途にも機能が提供されている。タスクを作る際にチャンネルに作成すると、そのチャンネルにいるユーザーが確認して適切な人を担当者として割り当てるといった運用になる。タスク作成からの導線と担当者を割り当てる UI が自然な流れになっていてよさそうに思えた。課題管理システムの代わりにはならないけど、ヘルプデスクの用途にはちょうどよさそうにみえる。

Streamly

A complete task management suite in Slack

目指しているものは課題管理システムではあるけど、Stream (プロジェクト)、Request (チケット) といった新しい名前 (概念) を導入しているので、まず用語からして学習コストが上がる。プロジェクトはチャンネルごとに設定して、Request の接頭辞やカスタムフィールドも設定できるようになっていて、課題管理システムを目指しているんだなという雰囲気はする。UI は Slack のフォームを使っているので1つ1つの操作が API 呼び出しになって操作量やフォーム入力が増えてあまり使いやすくは感じなかった。同じような操作を何度もさせられるといった印象を受ける。

一旦、これで Slack apps で適当に検索した課題管理システムに近いツールの調査を終える。1-2時間さらっと表面的なところしか触ってないけど、どれもプロダクション品質になっているのだから、内部はよく作り込まれているんだと推測する。

設計ドキュメント着手

課題管理システムの設計を資料にまとめ始めた。先週ぐらいからチケットに設計の要素を書き始めてだいたいのイメージは頭の中では固まっている。これまで3ヶ月調べた内容もあるのでそれなりの背景をもった設計資料にはなる。頭の中のイメージはできているけど、それを言語化する作業を今日・明日ぐらいでやりたい。書くことの難しいところはいざ言語化しようとするとやっぱり時間がかかる。たぶんわかった気になって本当のところはちゃんと分かってないことの裏返しだと思う。

VR イベント参加

【大阪オンライン】XRミーティング 2021/10/20【AR/CR/MR/SR/VR】 に参加した。zoom を複数地域と接続して youtube live で配信していたせいか、始まるまで時間がかかった。参加者のアバターがそれぞれ独自のものでかっこいいなと思って眺めてた。登壇者が5名いて全員が HoloLens を使っていた。電話してたり調べものしてたりしたので断片的にみていた。長めの発表と LT のような短い発表とバラバラ。適当に所感を書いていく。HoloLens の Moving Platform Mode の紹介はあまり見た目は派手ではなかったけど、どういう仕組みかを説明して動画で実際の振る舞いを説明してた。へーって感じで聞いていた。次に HoloLens 触ってはまって20年働いた会社をやめて VR 系の会社に転職した人。前職が大企業だったので給料もだいぶ下がったけど、家族を説得したらしい。給与以上に HoloLens の将来性を感じたとのこと。HoloLens で OpenCV や Azure Face API を使って顔認識するアプリケーションの紹介してた。おもしろそうだった。最後は HoloLens のアプリ開発の発表だった。Microsoft が Mixed Reality Tool Kit というライブラリを提供していて、クラウスプラットフォームで開発できる。ライブラリの Plane Finding という機能を紹介してた。空間の平面だしをする部品。水平面や垂直面を抽出したりできる。この機能を使ってアプリケーション開発のサンプルなどの話をしてた。

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 がある。これにはシンプルなパーティションを認識するロードバランシングから、洗練された並列クエリ実行エンジンまで様々である。すべてのパーティションは、ほぼ独立に動作できるように設計されている。パーティショニングされたデータベースが複数のマシンにまでスケールできるのはそのおかげである。

2時に寝て6時半に起きた。連日ジョギングして体を動かしたせいか、よく眠れて体調がよい気がした。機動戦士ガンダム 閃光のハサウェイ が今日からオンライン配信を開始した。私は載っているどの動画配信プラットフォームも使ってないが、iTunes Store で普通に購入できるようになっているのに気付いた。昨日の夜は閃光のハサウェイをみながら寝落ちしたので朝起きてから途中から見直した。映画館でみてたけど、戦闘のシーンは暗くてよくわからなかったので何回かみた方が発見もあるかもしれない。市街地の降ってくる炎を避けて逃げるシーンが好き。

ストレッチ

一昨日、昨日と連日でジョギングしたせいか、右股関節からお尻と右ももにかけて筋肉痛で張りがあった。そのせいかもしれないけど、今日の開脚幅は開始前168cmで、ストレッチ後170cmだった。先週とほぼ変わらないので股関節の可動域は現状維持だった。それでもトレーナーさんに筋肉痛だったところをストレッチしてもらってかなり楽になった。ジョギングして痛くなる内容が、最近は関節の痛みから筋肉の張りになっている気がしてこれはよい傾向かもしれない。前は腰にも負担がきていたけど、それも少しましになった。今日は可もなく不可もなくといったところか。

VR イベント参加

【三宮.dev オンライン】３周年記念交流会 に参加した。cluster のイベントを開いた。Oculus Quest で VR 参加できるのは Windows 向けのアプリだけっぽく macOS では VR 参加できなかった。

オープンなイベントとして開催したので誰でも参加することができて、途中で子どもが入ってきて参加者に無邪気に質問して微笑ましいカオスをもたらしていた。大人はよく知らないイベントに入って、なんの前提知識もなく参加者に話しかけたりしないだろう。そういうやり取りをみていて、子どものときから VR 空間でいろんな人と接すると子どもたちはどんな大人になるんだろう？私では想像もつかないイノベーションを起こすんだろうな。

1.5年前に1度だけ macOS のアプリで cluster イベント参加したことがあった。アプリは3回ぐらい落ちて不安定なので途中で Web でみたりしてた。そのときに比べたら今日は1度も落ちなかったので安定していた。参加者数の違いによるものかもしれないけど。前回から1.5年も経っているのに機能的なものは何も変わってないようにみえてあんまり流行ってないのかな？とも思えた。

参加者にたぬきのアバターがいて「たぬきさん、いますね」みたいな感じで和んでた。動物のアバターいいなと思って、カスタムアバターに興味がでた。VRoidStudio を使えば作れるらしい。また REALITY で作ったアバターを cluster で REALITY 連携 して使うこともできるらしい。Oculus ブログの記事 をみてたら Oculus は Oculus で独自のアバターの仕組みになるのかな。外部のツールで作ったカスタムアバターを持ち込めるようにはみえない。

Slack apps の調査

Wrangle を試してみた。

Approval and Ticketing Workflows in Slack

3つの機能をもっている。

• ちょっとした ToDo リスト管理
• 承認依頼を管理
• ステップと承認のワークフローを管理

とくに SaaS 型の Web アプリケーションもなく Slack app 単体で完結するアプリケーションにみえる。組織として承認履歴を残したいといったときにチャットツール上でワークフローを定義してちゃちゃっとできるといったところが売りなのではないかと推測する。課題管理として使うアプリケーションではなかった。

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 で構築されば課題管理システムも調べてみようと思う。

昨日は晩ご飯食べてからのんびりしていた。寝て起きての繰り返しだったので何時に寝たのかよくわからない。夜、本を読もうと思っていたのにダラダラ過ごしてしまった。朝は7時半に起きた。朝起きたら Python で Unicode 正規化 NFC/NFD の文字列を扱う がはてブでホットエントリ化してた。昨日、書評を書いたからその記事かと期待したけど、なぜか2年ほど前に書いた古い記事だった。なんかがっかり。そして、その理由は全くわからない。1日経って夜の時点ではてブが82個ついている。昔は10個もついたら嬉しかったものだけど、いまは100個ぐらいついてもなんとも思わない。

fin-pyコードリーディング会に発表準備

fin-pyコードリーディング会#4 に参加することにした。過去にオブジェクトストレージの開発に関わっていたからデータストアやストレージに関することは興味がある。たまたまツールの store.py を題材にしていたので読んでしまった。簡単にコードを読んで気になったところをイベントの hackmd に記載した。やっていることの詳細をよくわかっていないので、コードレビューみたいになってしまった。

• https://hackmd.io/bFBFaPbYS1Kqfc97HMlp7Q?view

BizPy のコミュニティ活動を再開

前にやってたお仕事がうまくいかなくて他のことに時間を費やす余裕がなくてお休みしてた。本当はもっと早く再開してもよかったんだけど、新しいことに挑戦しているときにあまり他のことに注意を取られたくないという考えもあって少し保留していた。新しいことへの活動も一段落して方向性や展望もみえてきたので BizPy も再開することにした。ちょうど Slack のインテグレーションを調べようと思ったところだったので弾みを付ける意図でも都合がよい。複数の意味でタイミングがよかった。また参加者が戻ってきてくれると嬉しい。

• Python で Slack のインテグレーションをやってみる勉強会 #1

プロコンの続き

ネットで話題になったせいか、当事者同士で話し合う場が設けられたという公式発表が行われた。

第32回高専プロコン秋田大会自由部門プレゼン審査発表順番号５の質疑応答について、発表者・質問者双方の相互理解の場を設けさせて頂きました。#procon32 pic.twitter.com/nlzujvJ7Hv

— KosenProcon (@KosenProcon) October 10, 2021

これ以上、外野がとやかく言う必要はないと思うけど、一方で立場の強い人が有利になってしまうため、運営はハラスメント行為を行った審査員へ然るべき措置をすべきといった意見もみられた。一理あるかもしれないが、そこまでするほどの問題かというのは個人的に思う。タイムラインを眺めていると、ハラスメントを問題視する人は、その背景や経緯や意図はすべて横に置いておいてハラスメント的言動や態度を糾弾する。この人たちと背景も考慮して整理しようとする人たちとは全く議論が噛み合わない。ハラスメントは絶対許すまじという社会の変化や誤った人への行き過ぎたキャンセルカルチャーに私はやや圧倒される。

そう思っていると、私のタイムラインでは「まさかりを投げる」という表現そのものや行為のハラスメントの是非の議論も巻き起こっていた。あまり最近はまさかりを投げるという表現は見かけないんだけど、「マウント禁止」というのをちょくちょくみかける。ハラスメントと根っこは同じで悪気の有無に関係なく発信側が責めを負うようになったんだなと感じる。

まさかりの議論とは別に、最近勉強会で「マウント禁止」というルールもよくみかける。これもマウントされたと感じる人と、知っていることを教えようとする人との関係の難しさを感じる。多少の間違いやもっとこうした方がいいよといったアドバイスをしなくなる人も多いのでは？という気はする。

— Tetsuya Morimoto (@t2y) October 11, 2021

2時に寝て7時に起きる。昨日 86―エイティシックス― の第2クールの初回をみた。起きてから第1クールの後半の内容を見返したりしてた。内容がすごくおもしろいというわけではないんだけど、作品の世界観と音楽がよい。というか、澤野弘之 氏のファンなので彼が音楽を手がける作品はみてしまう。第1クールの音楽も素晴らしかった。音楽がよいと映画やアニメのシーンが盛り上がるし、音楽だけを聞いているときにもそのシーンのイメージが想起されて音楽そのものにも深みが出るような気がする。

Terminal のカスタマイズ

月別一覧のページを作成した。Hugo には Taxonomies という仕組みがあって、任意のラベルでカテゴライズできる。デフォルトでは categories と tags が提供されている。設定ファイルに dates というカスタム Taxonomies を定義する。

[taxonomies]
  date = "dates"
  tag = "tags"

コンテンツのメタデータには次のように年月のラベルを付与する。

dates: [2021/10]

これは hugo new したときに自動生成されるので自分で明示的に設定する必要はない。

dates: [{{ dateFormat "2006/01" .Date }}]

ラベル名に / を含めると自動的に月ごとのサブディレクトリになってくれるので月別のアーカイブを生成するのに都合がよい。

$ tree -L 3 public/dates/
public/dates/
├── 2021
│   ├── 09
│   │   ├── index.html
│   │   ├── index.xml
│   │   └── page
│   └── 10
│       ├── index.html
│       ├── index.xml
│       └── page

タグ一覧とは異なり、年単位・月単位にまとめて一覧表示するためにテンプレートをカスタマイズする。Taxonomy Templates は terms.html によって提供されている。Terminal が提供しているこのテンプレートをカスタマイズすることで月別一覧を次のような表示になるようカスタマイズした。

実際の修正内容は次になる。

• https://github.com/t2y/diary/commit/783d9685ae3698b85e428bce178bdd9ebe2c3dca