取引所の[Binance](/wiki/Binance)が運営している手数料が安い[暗号通貨](/wiki/暗号通貨)で、[スマートコントラクト](/wiki/スマートコントラクト)ができるので[DApp](/wiki/DApp)開発に有用。

Binance Smart Chain

[SRE](/wiki/SRE)においてService Level Agreementの略で、対外的に満たすことを約束している指標のこと。

正常応答率99%を目指そう！と内部的に言うなら[SLO](/wiki/SLO)だが、対外的に約束してしまうとSLAになる。


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

アーキテクチャ量子の定義  
  
> アーキテクチャ量子とは、高度な機能的凝集、高度な静的結合、同期／非同期による動的結合を持つ、独立してデプロイが可能なアーティファクトを指す。アーキテクチャ量子の一般的な例には、あるワークフロー内の整ったマイクロサービスなどがある。  
  
これはすなわち、データベースを共有しているアプリケーションは全て1つのアーキテクチャ量子である。  

アーキテクチャ量子


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

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

見積もり


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

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

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

Zettelkasten

[暗号通貨](/wiki/暗号通貨)において[オラクル](/wiki/オラクル)を提供する分散ネットワークを実現した企業、およびそのネットワーク名。

51%攻撃


[Bitcoin](/wiki/Bitcoin)の論文を公開した人物。匿名であり誰なのかはわかっていない。

サトシナカモト


[機械学習](/wiki/機械学習)において入力層でも出力層でもないやつ

中間層


アプリ開発とかでチュートリアル的にスライドが何枚か出てくるやつのこと

語源は知らない

ウォークスルー


モノリスからサービスベースアーキテクチャを経てマイクロサービスへ移行していくためのやり方のうちの一つで、以下の様な手法。

- まるっと別アプリケーションとしてコピーして立て、それぞれ1部の機能しか使っていない状態にする。  
- その後、不要な機能をリファクタリングによって削除していく。

戦術的フォーク


[Bitcoin](/wiki/Bitcoin)等の[暗号通貨](/wiki/暗号通貨)に使われている[コンセンサスアルゴリズム](/wiki/コンセンサスアルゴリズム)の一つ、およびそこで計算される値。

具体的には、与えられたデータに対して、加えるとハッシュ値の先頭数十桁が0になるような値のこと、およびそれを計算する行為。

プルーフオブワーク

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

Optimistic_Rollup


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

[ハードパーツ](/wiki/ハードパーツ)としてのコントラクトの定義は以下である。  
  
> アーキテクチャの部品が情報や依存関係を伝えるために使用するフォーマット。  
  
コントラクトとして例えば以下の様なものがあり、トレードオフがある。  
  
- 堅い
  - 例
    - gRPC  
  - メリット
    - 型
    - バージョニング
    - 検証が用意
    - ドキュメント  
  - デメリット
    - 密結合  
- 緩い
  - 例
    - JSON
  - メリット
    - 疎結合
    - 進化しやすさ
  - デメリット
    - 型がない
    - コンシューマ駆動契約等の適応度関数が必要

帯域幅は無限だと思うな。

コントラクトに関するトレードオフ

[グラフ](/wiki/グラフ)に関する数学の理論のこと。

グラフ理論

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

うつ病

<p>以下の様にプログラミングすること</p>
<ul>
<li>問題を小さな塊に分解し、それらを縫い合わせる</li>
<li>最初に実装してしまうと全体が見えなくなる</li>
</ul>
<p>対義語は<a href="/wiki/%E3%82%A2%E3%82%A6%E3%83%88%E3%82%B5%E3%82%A4%E3%83%89%E3%82%A4%E3%83%B3%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0">アウトサイドインプログラミング</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__395ff876ec8be" src="https://embed.zenn.studio/card#zenn-embedded__395ff876ec8be" data-content="https%3A%2F%2Fwww.oreilly.co.jp%2Fbooks%2F9784873118864%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.oreilly.co.jp/books/9784873118864/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.oreilly.co.jp/books/9784873118864/</a></p>


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