同じ資産の2つの取引所の評価額の差を使って儲ける取引手法のこと。

アービトラージ

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

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


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)
かなり香りが良く酸味が強い印象がある。[エイジドマンデリン](/wiki/エイジドマンデリン)と比べるとブラックには全然向かず、砂糖やミルクと一緒に飲むと良い。
その前提であればリピしたいレベル。

ホンジュラスパトリアルカ


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

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

戦術的フォーク


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

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

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

潜在変数


[Bitcoin](/wiki/Bitcoin)の[L2ソリューション](/wiki/L2ソリューション)の一つ。

送金の問題を解決するため、事前にライトニングネットワーク上に[Bitcoin](/wiki/Bitcoin)をチャージし、その残高をライトニングネットワーク上でP2Pでやりとりするような仕組み。

送金はライトニングネットワーク内で仲介でき、送金者は新しくP2Pネットワークを繋げなくて済む一方、仲介者は手数料を受け取れる。

参考

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

ライトニングネットワーク


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

- まずは[リファクタリング](/wiki/リファクタリング)し、モジュールを分けていく。
- 分けられたモジュールをサービスに切り出す。

[戦術的フォーク](/wiki/戦術的フォーク)と比べて以下の様なメリットがある。

- 不要なコードは生まれない
- ロジックが綺麗になる

コンポーネントベース分解


[グラフ理論](/wiki/グラフ理論)における[グラフ](/wiki/グラフ)の定義から、[頂点](/wiki/頂点)の組の集合。


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)

なんかあんまり美味しくない
ほげほげマウンテンはあんまり好きじゃ無いのかもしれない
苦味が薄めな感じ

クリスタルマウンテン

[DevOps Research and Assessment（DORA）](https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling)チームが実施した 6 年間の研究から確立されたソフトウェア開発チームのパフォーマンスを示す 以下の4 つの指標のこと。

- **デプロイの頻度** - 組織による正常な本番環境へのリリースの頻度
- **変更のリードタイム** - commit から本番環境稼働までの所要時間
- **変更障害率** - デプロイが原因で本番環境で障害が発生する割合（%）
- **サービス復元時間** - 組織が本番環境での障害から回復するのにかかる時間

参考
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

Four_Keys


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

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

見積もり


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)
比較的すっきり目でブラックでも飲める。香りは強いというわけではない。とはいえ[エイジドマンデリン](/wiki/エイジドマンデリン)と比べると少しブラックに向かない。苦味よりも酸味や甘さが強めなので。
悪くはないがこれを買うなら[エイジドマンデリン](/wiki/エイジドマンデリン)を買う。


コスタリカエルアルコン

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

51%攻撃


[Googleのソフトウェアエンジニアリング](/wiki/Googleのソフトウェアエンジニアリング)の定義では

> コードの挙動を変えずに整理された内容に書き直すこと

である。

つまり、最も重要なのは自動テストである。自動テストがないと挙動が変わってないことが担保できないからである。

参考
https://qiita.com/miketako3/items/3085e225a35cdf89cd55

リファクタリング


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)

あんまりだった
さすがに安定している味だったが

珈琲問屋冬のブレンド雪灯り

<h2 id="%E6%A6%82%E8%A6%81"><a class="header-anchor-link" href="#%E6%A6%82%E8%A6%81" aria-hidden="true"></a> 概要</h2>
<p>「ソフトウェアテストをカイゼンする50のアイデア」</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__3a32057f50af1" src="https://embed.zenn.studio/card#zenn-embedded__3a32057f50af1" data-content="http%3A%2F%2Fwww.eijipress.co.jp%2Fbook%2Fbook.php%3Fepcode%3D2085" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="http://www.eijipress.co.jp/book/book.php?epcode=2085" style="display:none" target="_blank" rel="nofollow noopener noreferrer">http://www.eijipress.co.jp/book/book.php?epcode=2085</a></p>
<p><a href="/wiki/Attribute_Component_Capability">Attribute_Component_Capability</a></p>
