[ブロックチェーン](/wiki/ブロックチェーン)を使ったアプリでdecenterlized Appの略。



DApp

## そもそもうつ病とは何なのか  
  
情報ソースはほぼネットのみなので詳しくは専門のソースを見てほしいですが、ある程度は自分で調べて理解したつもりです。  
  
### 概要  
  
うつ病とは気分障害の一種で、うつ状態 (いわゆるうつ病っぽい状態) が2週間以上続いている場合につけられる診断です。原因はよくわかっていないようですが、脳内のセロトニン等が不足したことによって起きるという説がありますし、少なくとも脳に病的な何かが起きて発症したと考えられています。ただの精神的な問題ではないということです。  
  
いわゆる新型うつ等と呼ばれることもある適応障害とは区別され、原因を切り離した時にうつ状態ではなくなるのが適応障害で、そもそも原因が定かではないのがうつ病という理解です。(なので、適応障害の場合は業務は無理でも休日は元気だったりするわけです)  
  
### 症状  
  
症状としては精神的なものとお肉体的なものがあり、例えば以下のようなものがあります。肉体的な症状があるということは知らない人には意外なんじゃないかなと思います。  
  
- 精神的  
  - 気分が落ち込む  
  - 意欲が無くなる  
  - 集中力が無くなる  
  - 不安になる  
- 肉体的  
  - 頭痛  
  - 腰痛  
  - 肩こり  
  - 睡眠障害  
  - 食欲不振や過食  
  
### 診断  
  
うつ病や適応障害の診断は操作的診断というものによって行われます。わかりやすく言えば心理テストみたいなやつです。  
  
いまのところそれらを正確に検査するのは難しく、症状によって診断するしかありません。そのため、医者によらない客観性のある診断をするために心理テストの規格を作っているみたいなことのようです。  
  
以下の記事によれば、うつ病の9割弱がICDという診断基準、残りがDSMという診断基準で診断されています。  
  
http://www.kokoronomori.jp/2014/05/21/post-53  
  
つまり、ICDやDSMを覚えれば誰でもうつ病の診断を得られる可能性があるわけです。これは、本当にうつ病に悩む人にとってはあまり良いことではないと思います。自分の症状はただの甘えなんじゃないかという気持ちになってしまいます。まあ本当に患っている人はそんな勉強する余裕は無いわけですが、ライフハック的に使用する心無い人によって偏見に晒される可能性を考えると早く検査法が確立してほしいと願うばかりです。  
  
### 治療  
  
うつ病の治療で重要なのは以下の4つです。  
  
- 休養  
- 環境調整  
- 薬物治療  
- 精神療法  
  
そのため、精神科や心療内科でうつ病と診断されると、休職の診断書が出たり薬が処方されたりするわけです。  
  
なお、精神科や心療内科、クリニックはほぼ同じ意味です。名付けが自由なのでばらつきがあるというだけです。  
  
精神科で薬物治療と聞くとなんだか怖いイメージがありますが、最近は副作用が比較的少ない薬もありますし、イメージほどのヤバい薬が処方されることはあまり無いんじゃないかなと思います。  
  
また、治療の効果は徐々に現れていきます。風邪等と一緒である瞬間からいきなり全快とはならないので、最初は寝たきりだとしても徐々に活動量が上がっていくと思います。そのため、うつ病だからといって何もできないわけではないです。これも世間一般のイメージと乖離があるんじゃないかなと思います。  
  
### お金周り  
休職中は一般的には傷病手当金というものが健康保険から支給されます。金額としては月給の2/3程度です。 また、企業によってはさらに所得保障がある場合があり、月給の2/9程度が追加で支給されます。ボーナスはありませんし、支給までにかなりタイムラグがあるとはいえ、この期間は働かずにお金がもらえるわけですね。  
  
働かずにお金がもらえるなんて最高じゃないかと私も休職以前は思っていたのですが、やってみるとそんなに良いものではありません。  
  
そもそも大半の期間は遊んだり出来る余裕が体調的にありませんし、精神的にも遊んでいられるような状態ではありませんでした。本来感じる必要は無いのですが、ズル休みをしているような感覚になります。  
  
かなりの図太さがないと悠々自適に過ごすのは難しいでしょうし、そのような人はうつ病にならなそうです。  
  
さらに、治療が進んでいないと思われれば不要に薬が増やされるわけで、副作用があることを考えればあまりやりたくはありません。  
  
結局は真面目に治療に専念するのが一番良いわけで、そういう意味では安心して休める傷病手当金という制度は良いものだと思います。

うつ病


ゴール、シグナル、メトリクスを明確に区別する (GSMフレームワーク)。  
  
- ゴール: 達成するべき目標。  
- シグナル: ゴールを達成したことを知る手段。必ずしも計測可能である必要はない。  
- メトリクス: シグナルの計測可能な代替品。  
  
メトリクスを計測する前に、それを計測した後どう行動するのかを考えるべき。  
  
生産性のゴールにはトレードオフがあるため、一部だけを計測するのはよくない。  
QuANTSのゴールを全て計測することで、網羅的に計測ができる。  
  
| 頭文字 | 英語                           | 日本語      |  
|-----|------------------------------|----------|  
| Qu  | **Qu**ality of the code      | コード品質    |  
| A   | **A**ttention from engineers | エンジニアの注意 |  
| N   | I**n**tellectual complexity  | 知的複雑性    |  
| T   | **T**empo and velocity       | テンポと速度   |  
| S   | **S**atisfaction             | 満足       |  

QuANTS


https://ja.m.wikipedia.org/wiki/マトロイド

[貪欲法](/wiki/貪欲法)で最適化できる性質を持つ集合のこと

- [空集合](/wiki/空集合)を含む
- [部分集合](/wiki/部分集合)は必ず含まれる
- 小さいものから大きいものへの遷移が可能

これであれば[貪欲法](/wiki/貪欲法)の[局所解](/wiki/局所解)が[最適解](/wiki/最適解)と一緒になるのでで解ける

[グラフ](/wiki/グラフ)の[辺](/wiki/辺)集合における[森](/wiki/森)の集合とかがマトロイドになるので、つまり[最小全域木問題](/wiki/最小全域木問題)が解けることになる

そういうマトロイドのことを[グラフマトロイド](/wiki/グラフマトロイド)とか[閉路マトロイド](/wiki/閉路マトロイド)とかいう

閉路マトロイドの[基](/wiki/基)は[全域木](/wiki/全域木)になる

マトロイド


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)で定義されている概念。

アーキテクトの問題はそれぞれユニークなため、ベストプラクティスが存在しない。  

だからこそ「ハード」パーツである。  

- 難しい問題  
- 堅い、システムの土台となる部分

ハードパーツ


[機械学習](/wiki/機械学習)においては[中間層](/wiki/中間層)の変数のこととほぼ同義

中間層はだいたい入力より次元が低く、その次元で入力の特徴を捉えるようにチューニングするので、入力の特徴だけを捉えたものになる

関連：[潜在空間](/wiki/潜在空間)

潜在変数


[VAE](/wiki/VAE)的なやつ

入力 -> エンコーダー -> 潜在空間 -> デコーダー -> 出力

という形のやつ

エンコーダーデコーダーモデル


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)

データベースを分けるか？分けないか？もトレードオフである。  
  
データを分解する要因として以下のようなものがある。  
  
- 変更制御  
  - カラムの変更等の影響が多岐にわたる  
- コネクション管理  
  - 1つのデータベースだけを使うとコネクション数の管理が難しい  
- スケーラビリティ  
  - コネクション数  
  - 容量  
  - スループット  
  - パフォーマンス  
- 耐障害性  
  - 1つのデータベースだけを使うとデータベースが単一障害点となってしまう  
- [アーキテクチャ量子](/wiki/アーキテクチャ量子)
  - 1つのデータベースだけを使うと1つの[アーキテクチャ量子](/wiki/アーキテクチャ量子)となってしまう (つまり独立してデプロイできない、等)  
- データベース種別の最適化  
  - 1つのデータベースだけを使うと1つの保存方法だけしか使えない (つまりデータ特性ごとに最適な選択肢が取れない)  
  
逆に、データを統合する要因としては以下のようなものがある。  
  
- データ関係  
  - 密結合な外部キー等があるか？  
- トランザクション  
  - 単一のトランザクション単位が必要か？  
  
モノリスなデータベースを分解するには5段階のプロセスを踏むと良い。  
  
1. 分析し、ドメインを特定する  
2. ドメインごとにテーブルを割り当て、移動する  
3. コネクションをドメインごとに分離する  
4. スキーマをそれぞれのデータベースに移動する  
5. コネクションを切り替える

業務データの分解に関するトレードオフ


メインの[暗号通貨](/wiki/暗号通貨)の[ブロックチェーン](/wiki/ブロックチェーン)と連携する目的で作られた別の[ブロックチェーン](/wiki/ブロックチェーン)のこと。

サイドチェーン


与えられた命題が真であることを、それ以外の情報を与えずに証明すること。

ゼロ知識証明


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)

マイクロサービスの粒度を大きくするか？小さくするか？もトレードオフである。  
  
粒度を小さくする要因としては以下のようなものがある。  
  
- サービスの範囲と機能  
  - 凝集性が高い状態になっているか？  
- コード変動率  
  - 一部のコードだけ変更頻度が高くないか？  
- スケーラビリティとスループット  
  - 一部だけスケールする必要があるか？  
- 耐障害性  
  - 一部の故障で全体が故障してしまわないか？  
- セキュリティ  
  - 一部だけ高いセキュリティが必要か？  
- 拡張性  
  - どの程度拡張されるか？  
  
粒度を大きくする要因としては以下のようなものがある。  
  
- トランザクション  
  - サービスをまたいだトランザクションが必要か？  
- ワークフローとコレオグラフィ  
  - サービス同士がやりとりする必要はあるか？  
- 共有コード  
  - サービス同士がコード共有の必要はあるか？  
- データ関係  
  - データは分解できるか？

サービスの粒度に関するトレードオフ


https://en.wikipedia.org/wiki/Four-dimensionalism

時間的に連続なことが重要だから、三次元的に全く異なっている物体でも連続してるんじゃね？的な考え

[テセウスの船](/wiki/テセウスの船)とか[スワンプマン](/wiki/スワンプマン)の解決策

四次元主義


昔の人が編み出したノート術。
Atomicなノートをリンクで繋げる。

1. カード1枚につき1アイデアを記入
2.  カードの内容を完結させる
3.  カードは常に他のカードとリンクさせる
4.  カードのリンクが何を意味するかを説明する
5.  自分の言葉を使う
6.  参考文献を残しておく
7.  自分の考えを加える
8.  構造を気にしない
9.  続カードを追加する
10.  アウトラインカードを追加する
11.  カードを削除しない
12.  恐れずにカードを追加する

参考
https://gigazine.net/news/20200604-zettelkasten-note/

Zettelkasten


https://mickindex.sakura.ne.jp/schlick/schlick_MV_jp.html

ある命題が立てられているとき、この命題が有意味であるか無意味であるかという問いを立てるとしたならば、その命題が有意味であるための条件が問われている。
命題が有意味であるとはそれが検証可能であるということだ……という考え方が、意味の検証理論

意味の検証理論


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)

通信、整合性、調整についてそれぞれ2パターンあり、組み合わせると合計8パターンのサーガ (アーキテクチャの大別) がある。

| パターン名       | 通信  | 整合性   | 調整         | 結合度   | 複雑さ   | 応答性/可用性 | スケーラビリティ |  
|-------------|-----|-------|------------|-------|-------|---------|----------|  
| エピックサーガ     | 同期  | アトミック | オーケストレーション | とても高い | 低い    | 低い      | とても低い    |  
| 伝言ゲームサーガ    | 同期  | アトミック | コレオグラフィ    | 高い    | 高い    | 低い      | 低い       |  
| おとぎ話サーガ     | 同期  | 結果整合性 | オーケストレーション | 高い    | とても低い | 中程度     | 高い       |  
| 時間旅行サーガ     | 同期  | 結果整合性 | コレオグラフィ    | 中程度   | 低い    | 中程度     | 低い       |  
| ファンタジーサーガ   | 非同期 | アトミック | オーケストレーション | 高い    | 高い    | 低い      | 低い       |  
| ホラーストーリーサーガ | 非同期 | アトミック | コレオグラフィ    | 中程度   | とても高い | 低い      | 中程度      |  
| パラレルサーガ     | 非同期 | 結果整合性 | オーケストレーション | 低い    | 低い    | 高い      | 高い       |  
| アンソロジーサーガ   | 非同期 | 結果整合性 | コレオグラフィ    | とても低い | 高い    | 高い      | とても高い    |

トランザクショナルサーガ

<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__47f942b066d89" src="https://embed.zenn.studio/card#zenn-embedded__47f942b066d89" data-content="https%3A%2F%2Fwww.amazon.co.jp%2F%25E3%2582%25BD%25E3%2583%2595%25E3%2583%2588%25E3%2582%25A6%25E3%2582%25A7%25E3%2582%25A2%25E8%25A6%258B%25E7%25A9%258D%25E3%2582%258A-%25E4%25BA%25BA%25E6%259C%2588%25E3%2581%25AE%25E6%259A%2597%25E9%25BB%2599%25E7%259F%25A5%25E3%2582%2592%25E8%25A7%25A3%25E3%2581%258D%25E6%2598%258E%25E3%2581%258B%25E3%2581%2599-%25E3%2582%25B9%25E3%2583%2586%25E3%2582%25A3%25E3%2583%25BC%25E3%2583%2596-%25E3%2583%259E%25E3%2582%25B3%25E3%2583%258D%25E3%2583%25AB-ebook%2Fdp%2FB00KR96M6K" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A6%8B%E7%A9%8D%E3%82%8A-%E4%BA%BA%E6%9C%88%E3%81%AE%E6%9A%97%E9%BB%99%E7%9F%A5%E3%82%92%E8%A7%A3%E3%81%8D%E6%98%8E%E3%81%8B%E3%81%99-%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%96-%E3%83%9E%E3%82%B3%E3%83%8D%E3%83%AB-ebook/dp/B00KR96M6K" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.amazon.co.jp/ソフトウェア見積り-人月の暗黙知を解き明かす-スティーブ-マコネル-ebook/dp/B00KR96M6K</a></p>
<p><a href="/wiki/%E8%A6%8B%E7%A9%8D%E3%82%82%E3%82%8A">見積もり</a></p>


ソフトウェア見積もり_人月の暗黙知を解き明かす