週報 - 2020年1月第5週
前週はこちら
やったこと
- Akka Typedの記事を書いていました
...が、書いているうちに、記事の目的というか、着地点に納得がいかず、断念
やること
- 次の課題に向けて、充電期間にしたいと思います
今の自分にとって、何が取り組むべき優先課題なのか、よく考えたい
その他
- やりたい、と思って計画したことであっても、本当にそこに価値があるのか突き詰めると、思ったほどの価値が見出せなかったりすることがある
それは、致し方ないとは言え、計画段階でもっと深く検討していれば、安易に踏み込まずに済むと反省している
週報 - 2020年1月第4週
前週はこちら
やったこと
やること
- Akka Typedに関する記事を書く
ずっと下書きのままになっているので、完成させます
その他
- 小さな目標を確実に達成する方が、大きな目標を達成できないよりも遥かに精神衛生上良い
週報 - 2020年1月第3週
前週はこちら
今週は体調を崩してほとんど個人開発できませんでした...（今も絶賛不調中です）
そして、今後もこのように、調子が良い時ばかりではないので、計画を立てるとしても最低限こなせる程度のものに絞った方が良いと反省しました。
というわけで、今後の「やること」は控えめにしつつ、確実にこなすようにしていきます。
やったこと
やること
- Scala MatsuriのCFPを出す！
その他
- 体調管理大事...
週報 - 2020年1月第2週
週報 - 2020年1月第1週
前週はこちら
ついに、2020年があけました。
オリンピックイヤーですね。無事に開催出来るのかな...
さあ、今年も頑張って開発するぞー！
やったこと
- tetricsのリファクタリングは継続中
合わせて、共通化出来るコードは別ライブラリに切り出したりしてます - オンラインで将棋が出来るちょっとしたサービスを作成中です
指し手をサーバに送り、バッチ処理で定期的に集計して局面に反映します
まだまだ不完全ですが、最低限の動作はするようになりました - 個人的な趣味の静的なサイトを作ってました
ただ単にHTMLを書くだけだと面白くないので、Scalaから生成する機構を（あえて）自作しています
やること
その他
- なかなかRustできない...
- 年末年始はいっぱいコード書けて楽しかった
プログラムを書いてから実行されるまでのラグ
あるプログラムを書くとします。
書いたプログラムが実行されるのはいつでしょうか？
プログラムのタイプにもよりますが、例えばWebアプリのコードだとして、自分でローカルで動かしてみるか、あるいはデプロイして開発環境で動かすか、あるいはなんらかのテスティングフレームワーク経由で動かすか。
依存性の大きいコードだと、動かす、も一筋縄ではいかないでしょう。
DBの状態、キャッシュの状態、デプロイ、DNS、その他のシステムを構成する様々な要素...。
コードを書く行為と実行して動作を確認するまでの間に、ラグが生じます。
このラグが大きいほど、開発に無駄なコストがかかっていると思っています。
書いて動かして改善する、のサイクルをなるべく早く回したい。
そのために取れる戦略が色々あります。
ローカル環境の整備、テストの充実、抽象化とモックによる部分的な動作環境の構築、デプロイの自動化、などなど。動かしたい対象の性質に合わせて様々です。
でも、そもそも、動かないものは動作確認も取れません。
最低限、動くを保証した上で、動作を確認する戦略を乗せたい。
静的型付けによるコンパイル時のチェックは、最低限のプログラムの動作を保証する重要な機構だと思います。
書いたコードに対して、最初のフィードバックを与えてくれるのはコンパイラ（あるいは、IDEが提供する型チェック）です。
書いたコードの正しさは、いくつかの層に分かれていて、言語機能でサポートされる層の保証が大きければ大きいほど、その上の層の負担が減ります。
型システムがどんなに進化しても、コンパイルが通ればそれだけで正しいコードである、というレベルにまではなかなか到達はしないでしょう。しかし、正しさを確認する工程の補助を強化することはできます。
システムの規模が大きくなるにつれ、書いたコードの実行までのラグが大きくなるので、これを小さくする工夫が開発を円滑にするための重要なファクターだと思います。
設計における静と動
設計には静的な側面と動的な側面があります。
静的な側面は、システムのある瞬間の状態を表現するもので、データ構造としてモデリングされます。
一方、動的な側面は、システムの状態がある状態から別な状態へと遷移する事象を表現するもので、ある種のトランザクション（DBのトランザクションとは限らない）とも言えるかと思います。
不揮発性のシステムを構築する場合はなんらかの方法で状態を再現できる必要がありますが、戦略として、前者の静的な状態を切り取って保持するのがステートソーシング、後者の動的な状態遷移を記録していくのがイベントソーシング、となります。
設計は、不変条件を守ることを主眼に行われます。即ち、状態内のあるデータとあるデータとの組み合わせが不正にならないことを保証するためのルール付けです。
静的側面からは、不正な状態の生成を拒否するなんらかの実装によってこれを実現しようとします。一方、動的な側面からは、状態の遷移を静的モデルに対して要求し、成功した場合と失敗した場合のそれぞれのシステムとしての挙動を制御します。また、処理の境界付けを行い、どこまでが一つのアトミックな処理であるのかを定義します。
データ構造に対する要求は機能/非機能を含め様々ケースがありうるため、その設計はこれがベスト、というものは無いと思います。重要なのは、何が目的でそのデータ構造が必要とされているのかを明確にすることです。それにより取りうる選択肢は変わるでしょうし、様々な要件の中から何を優先し何を切り捨てるか、という判断も変わります。
例えば、オンメモリで高速な演算が求められるケースであれば、適切なアルゴリズムが適用できるデータ構造の選択が重要でしょう。また、速度よりも、複雑なロジックを安全に管理したり、その拡張性が求められるようなケースであれば、また違った抽象化や効率的な保守が可能な構造を選択すべきなはずです。
ビジネス上の要求を度外視して、フレームワークや永続化層の都合に合わせたパターンにデータを押し込めるような設計は、後々様々な問題を引き起こすでしょう。
静と動の観点からシステムを見ると、参照と更新の分離のような戦略も比較的理解しやすいのではないでしょうか。
データの参照とは、ある瞬間のシステムの状態を切り取ってきて目的に合わせて整形して閲覧する行為です。閲覧するデータが最新であるとは限りません。なぜなら、ある瞬間のデータを切り取った時点で、そのあとに適用された変更は観測不能になっているからです。返却されたデータは閲覧している間に他のプロセスが変更しているかもしれません。
それに対して、データの更新とは、システムの現在の状態に対して、変更の要求の適用可否を判断し、適用可能であれば現在の状態から別な状態へと遷移させる行為です。注意すべき点は、変更を適用するための状態と適用後の状態との間に、他の変更が割り込むと、状態が破壊されうるということです。
何が許容できて、何が許容できないかは、コンテキスト次第で変わります。繰り返しになりますが、システムの目的を明確にし、適切な取捨の判断が重要です。
