[SRE](/wiki/SRE)において、Service Level Objectiveの略で、サービスの質を図る指標の目標値こと。

正常応答率99%を目指そう！と言った時、正常応答率を99%というのがSLO。

[Rollup](/wiki/Rollup)手法の一つ。楽観的ロールアップとも呼ばれ、不正なブロックがめったに生成されないという前提の元、不正なブロックがあった場合には後から検証でブロックする方針。

Optimistic_Rollup


[グラフ理論](/wiki/グラフ理論)における[グラフ](/wiki/グラフ)の定義から、[辺](/wiki/辺)の集合ではない方の集合。

頂点

[ブロックチェーン](/wiki/ブロックチェーン)を用いた[暗号通貨](/wiki/暗号通貨)では、最も長いチェーンが有効とされる。

したがって、その分散ネットワークの全参加者のうち51%の信頼を獲得すれば、1人で最も長いチェーンを繋げることができる。これはつまり自由に台帳に取引履歴を書き込めるということで、そうなったら[暗号通貨](/wiki/暗号通貨)は終わる。

例えば[プルーフオブワーク](/wiki/プルーフオブワーク)では51%の計算リソースが必要で、[プルーフオブステーク](/wiki/プルーフオブステーク)では51%の[暗号通貨](/wiki/暗号通貨)が必要である。

[Bitcoin](/wiki/Bitcoin)等の規模が大きいネットワークでは攻撃はかなり難しいが、規模が小さい[暗号通貨](/wiki/暗号通貨)では実際に起こっている。

実例

https://coinpost.jp/?p=175687

51%攻撃

[暗号通貨](/wiki/暗号通貨)であり、[ステーブルコイン](/wiki/ステーブルコイン)の一種。

Tether Limited社が米ドルを担保に発行している。

シンボルはUSDT

Tether

開発者の生産性をどう捉えるかについてのヒントを与えてくれるフレームワーク。  

著者の一人であるNicole Forsgren氏は、[LeanとDevOpsの科学](/wiki/LeanとDevOpsの科学)の著者の一人でもあり、氏が2021年にGitHub、ビクトリア大学、Microsoft Researchのメンバーと共に発表した論文[The SPACE of Developer Productivity](https://queue.acm.org/detail.cfm?id=3454124)で提唱されている。

- Satisfaction and well being
	- 開発者が自分の仕事、チーム、ツール、文化にどれだけ満足しているか
- Performance
	- 開発者が書いたコードは、想定されたことを確実に実行したか？
- Activity
	- 業務を遂行する過程で完了した行動やアウトプットの数
- Communication and collaboration
	- メンバーやチームがどのようにコミュニケーションをとり、協力し合うか
- Efficiency and flow
	- 個人であれシステムであれ、中断や遅延を最小限に抑えて作業を進める、完了する能力

参考
https://zenn.dev/loglass/articles/28c565a875e9bd

SPACEフレームワーク


[潜在変数](/wiki/潜在変数)がある空間

潜在空間


Variational Auto Encoder
変分オートエンコーダ

入力を[潜在変数](/wiki/潜在変数)に良い感じにするやつ

https://ai-kenkyujo.com/term/what-is-vae/
https://zero2one.jp/ai-word/variational-autoencoder/


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

アーキテクチャの分解には[コンポーネントベース分解](/wiki/コンポーネントベース分解)と[戦術的フォーク](/wiki/戦術的フォーク)という2種類のやり方があり、それぞれメリットとデメリットがある。

[戦術的フォーク](/wiki/戦術的フォーク)は[コンポーネントベース分解](/wiki/コンポーネントベース分解)と比べて以下のような特徴がある。

- メリット
  - 事前の分析が不要なので作業開始が早い
  - コードは抽出するより消す方が簡単 (と書かれていたが本当か？)
- デメリット
    - 不要なコードを消す努力が必要
    - ロジックは汚いまま

アーキテクチャの分解に関するトレードオフ

[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)
フルーティー感あるのであんまり
すごい嫌いとかでもない

コスタリカフィデルス

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

うつ病


拡散モデル

[エンコーダーデコーダーモデル](/wiki/エンコーダーデコーダーモデル)で、ノイズを混ぜた画像からノイズ無しの画像を推論する訓練をすることで、最終的には無から画像を生成できる

モデルは[VAE](/wiki/VAE)

Diffusionモデル


いかなる[チューリングマシン](/wiki/チューリングマシン)もエミュレートできる[チューリングマシン](/wiki/チューリングマシン)のこと

万能チューリングマシン

以下の様にプログラミングすること

- 問題を小さな塊に分解し、それらを縫い合わせる  
- 最初に実装してしまうと全体が見えなくなる

対義語は[アウトサイドインプログラミング](/wiki/アウトサイドインプログラミング)

https://www.oreilly.co.jp/books/9784873118864/

インサイドアウトプログラミング


[ソフトウェア見積もり_人月の暗黙知を解き明かす](/wiki/ソフトウェア見積もり_人月の暗黙知を解き明かす)の内容が書かれている。

## 第1部 見積もりの考え方  
### 第1章 見積もりとは  
  
- 「見積もり」「ターゲット」「コミットメント」の違いを意識する  
  - 見積もり：そのままの意味  
    - 「この機能の実装は何人日」  
  - ターゲット：実現したいビジネス上の目標  
    - 「何日までにこの機能を提供したい」  
  - コミットメント：機能を一定のレベルで期日までに納品するという約束  
    - 「何日までにこの機能を提供します」  
- 見積もりと計画の違いを意識する  
  - 見積もりは正確性が重要  
  - 計画は結果が重要  
  - 偉い人にターゲットを達成するための計画を聞かれているのに見積もりを単に答えてはいけない  
    - 「このプロジェクトは何人月？期限は３ヶ月なんだ」  
    - 「見積もってみたところ５ヶ月かかります」  
    - 「ふざけるな！」  
  - 開発と期日どちらが優先かどうか尋ねる  
- 良い見積もりとは偉い人の意思決定に寄与する見積もりのこと  
  
### 第2章 見積もり能力のチェック  
  
- 直感で「90％確か」な見積もりは、実際には「30%確か」  
  - なので直感で90%とか言ってはいけない  
- 見積もりなんて幅があって当然。無理に狭めようとしない  
  
### 第3章 正確な見積もりの価値  
  
- 意図的に過小に見積もることはすべきではない  
  - 過大見積もりよりも深刻な被害が起きる  
  - では過大にすれば良いかというとそうでもなく、それなりに大きくしてあとは計画とコントロールで対処せよ  
  
### 第4章 見積もり誤差はなぜ起きる？  
  
- 見積もり期間を増やしても見積もりの不確実性は上がらない  
  - プロジェクト自体があやふやなのではどんなに頑張っても上がらない  
  - 見積もり期間を増やすのではなく、要件定義や設計を固めることでしか上がらない  
- 休暇、病欠、トレーニング、ミーティング等は必ず発生する。そのためのゆとりをもたせる  
- 開発者の見積もりはすでに必ず楽観的であるので削ってはいけない  
- 見積もりに「コントロールノブ」を持たせてはいけない  
  - コントロールノブとは見積もりに入れる主観的判断のこと  
  - 見積もりの客観性と共に正確性も落ちる  
- 即興の見積もりはしない  
  - たった15分の見積もりでさえもっと正確になる  
  
## 第2部 見積もりの技法の基礎  
  
### 第7章 数えて、計算して、判断する  
  
- できるときはまず何かを数える  
- 数えられない場合にのみ計算する  
- 計算すらしないのは最終手段  
  
### 第9章 専門家の判断  
  
- タスクで分解して見積もるときは長くても2日程度の粒度にする  
  
  
## 感想  
  
「技術者の見積もりは常に楽観的」というのはその通りだと思った。  
幅がある見積もりの中で最小の部分を提出する傾向があるような気がしているし、  
実際過小に見積もる圧力があるということも書かれていた。  
  
一方で、数えるだけの方がよほど正確に見積もれるというのは不思議だった。さすがにコード行数で数えるのはどうかと思うが。  
  
過去の開発にかかった工数と関連データの保存および可視化が出来ていないと不可能な手法ではあるので、これらの重要性はかなり高い。  
  
生産性向上とか言っておいて生産性を測る指標を可視化していないなんてことがザラにある状態では正確な見積もりなんて望めないということかもしれない。

見積もり

<p><a href="/wiki/SRE">SRE</a>において、Service Level Indicatorの略で、サービスの質を図る指標のこと。</p>
<p>正常応答率99%を目指そう！と言った時、正常応答率がSLI。</p>
