たれぱんのびぼーろく

わたしの備忘録、生物学とプログラミングが多いかも

"上手く"やること

上手くやりたいか、をまず自分に問うこと

目的を見定める。
価値の源泉を具体化して磨いて作って最速で作り上げる。
だんだんと肉付けしていく。

Justitiaからの学び
目的を具体化し、何が欲しいのか明示する
具体化した目的の根源にあるものを磨いていって、それをまず実現する
無限にできるから、絞る。やらないことを選ぶ
やらないことの選択crieria: 目的

LTCM本から学ぶ

不正確なリスク見積もりに基づくレバレッジ

LTCMが想定した戦略
低リターンのrelative value投資を高いレバレッジで行う

戦略に必要な道具
低い手数料 (取引・融資)
多くの原資
高いレバレッジ

道具を揃えるための仕組み
レバレッジを用いた高リターン期待に基づく良条件の原資・融資
リスク定量化による高レバレッジの正当化

起きたこと
数年の成功 (運が当然からむ)
成功が道具を揃えやすくする
運用額急増によるクジラ化、市場効率化による取引機会・利益の減少
(ヘッジしない投資を含む多角化)
価格の逆方向への変動
ほぼ起きない前提の価格に突入
LTCM・同様の戦術を取っていた市場参加者に対する信用収縮
信用収縮による投売り、更なる価格悪化、流動性喪失、更なる信用収縮加速
おわり

破綻原因: 市場全体が低く見積もったリスクに基づいて過剰なレバレッジを設定しそれが市場全体での信用収縮を引き起こしたこと
破綻規模が大きくなった原因: 過剰なレバレッジによる初期運用効率の良さと、正しいと信じられた正当化がもたらした、多額かつ良条件の出資・融資

出来た対策
計画自体が半分破綻している。
良き資金調達と高いレバレッジが低リターン市場への投資を可能にしている
理論武装した高いレバレッジが他の全てをもたらしてくれるが、高いレバレッジはリスクと実際は釣り合っていない
高いレバレッジが不可能なら、資金も集まらない
そもそも計画段階から破綻していたとみるのが妥当

不正確なリスク見積もり

正規分布に基づくリスク表現 (ロングテールの見落とし)
(前者を含んでるはずだが) 分散投資によるリスク低下 (中心極限定理使ったけど独立分布じゃなかった、とかだと思う、本には書いてない)

VSCodeの使い勝手を良くする: 各種設定の内容と利用方法

Settingsによって変更できる.

  • User Settings: そのエディタで開く全てのものに適用される
  • Workspace Settings: workspaceにのみ適用される

Settings

VSCodeが公開しているdefault settings(一覧)と、拡張機能がsettingsへ公開している設定事項がsettingsにて制御できる。
User SettingsはAPPDATA的ディレクトリにしまってある
Workspace Settingsは.vscodeディレクトリ下 (.vscodeはルート直下)に1、settings.jsonの形で置く。あるいは (multi-root workspace用として) .code-workspaceファイル内"settings"属性として書く.
.code-workspaceとsettings.jsonは共存できる。ただし各settings.jsonがエディタ全体に関わる設定をしていると衝突してしまうので、multi-root workspace利用時には一部のsettingがsettings.jsonで利用できなくなる。

/.vscode/settings.json [ref]

{
  "diffEditor.ignoreTrimWhitespace": true,
  "diffEditor.renderIndicators": true,
}

.code-workspace [ref]

{
    "settings": {
        "window.zoomLevel": 1,
        "files.autoSave": "afterDelay"
    }
}

拡張機能 / Extensions

拡張機能のインストール要求

Workspace recommended extensions - official

.vscode/extensions.json [ref]

{
    "recommendations": [
        "eg2.tslint",
        "dbaeumer.vscode-eslint",
        "msjsdiag.debugger-for-chrome"
    ]
}

*.code-workspace [ref]

{
    "extensions": {
        "recommendations": [
            "eg2.tslint",
            "dbaeumer.vscode-eslint",
            "msjsdiag.debugger-for-chrome"
        ]
    }
}

Recommendationというより強制したい場合はrecommendationを消せなくさせればよい.
settingsにおいて [ref]

extensions.showRecommendationsOnlyOnDemand: false,
extensions.ignoreRecommendations: false

multi-root workspace / .code-workspace

*.code-workspaceファイルにて設定.
workspaceに含まれるroot directriesを指定する.

UseCase: 特定のプロジェクト (workspace) でのみ拡張機能を有効にしたい

エディタ一般が悩む問題として、拡張機能の入れすぎでエディタが重くなる問題がある。
ユーザー設定で拡張機能を入れていくと、各プロジェクトspecificな拡張機能がじゃんじゃん追加され、使っていないけど重さの原因となることがしばしばある。
拡張機能の設定をworkspace settingsで行えば、必要な機能のみをenable (≠specific install) にできる(はず)


  1. The workspace setting file is located under the .vscode folder in your root folder. ref

世代継承率(生涯無子率)を考える

結論: 7割くらい

考え方

日本では非嫡出子率が2%くらいしかないので、未婚率と結婚経験者の出産率を見ればなんとかなりそう

先行研究

toyokeizai.net

データ

未婚率
男23.4%, 女14.1% @2015 (内閣府)
2035年には29.0%/19.2%と予測
第1部 少子化対策の現状(第1章 2): 子ども・子育て本部 - 内閣府

非嫡出子率
いわゆる「未婚の母」による出生率をグラフ化してみる(最新) - ガベージニュース

考察

未婚での出生は大まかに無視できる
よっておおまかに2割は無子と考えられる.
合計結婚出生率が2くらい、つまり結婚したら2人くらい産んでる.
データ探すのが面倒で探していないが、1割くらいが子なし夫婦と考える。
世代継承率は7割ほど.

ソフトウェアやサービスの何が重要なのか

ソフトウェア、サービス: ユーザーに使われるもの
ユーザーに価値を提供するもの

価値そのものを生む場所、価値を生むことを実現する技術
スーパー黒子

DDDにおけるドメイン: 価値の源泉

ソフトウェア/サービスと金の延べ棒の違い

利用に価値があるのか、存在に価値があるのか
道具なのか、資産なのか

金は存在自体に価値がある。金の延べ棒を貰ったらとても嬉しいけど、金は食べれもしないし明日の天気を教えてくれもしない。金は利用して価値を生むものではなく、存在自体が(交換可能な)価値をもつ類の存在である。要は資産。

一般に、ソフトウェアやサービスは資産(動産)、すなわちその存在そのものが交換可能な価値をもっている存在ではない。
ソフトウェアやサービスは、使って価値を生む道具である。
だから生み出す価値が全て。ソフトウェアやサービスの存在/所有自体に対する価値は小さい。
利用者が生み出す価値が全て。利用者に提供できる価値が全て。
ソフトウェアの価値は、ユーザーに提供できる価値で決まる。

ToDoリストサービスは、やるべきことリストの書き留めと引き出しという価値を提供する。
DBアクセス権を売ってるわけではない。DBを無くすことができるかどうかは価値に直結しない。

開発手法

価値を生む仕組みが完璧に構築できるのなら、それに従ったソフトウェアを書けば完全なソフトウェアができる (価値を生むことが約束された仕組みを実装したのだから)
現実には、人間は不完全。価値を生む仕組み(ビジネスモデル)を完全に予見できる人間なんかいない。
不完全な価値産生仮説に基づいてソフトウェアを書き、仮説を検証・修正し、それに合わせてソフトウェアを改修する。
この方が合理的。
この方法を取るためには、ソフトウェアの柔軟な改修を可能にする必要がある。
また、仮説の考察にソフトウェア側から貢献できればなおよい。

kuranuki.sonicgarden.jp

ソフトウェアが占める、ユーザーの価値産生における重要度、もポイント。
ソフトウェアの重要度が上がれば上がるほど、開発手法を合理化する意味が大きくなる。