
# 環境設置

## 本文使用系統

OS: Windows 10
顯卡: GTX 960
CUDA: 9.0
cuDNN: 7.6.4
Terminal: 以管理員權限執行cmd.exe

## 安裝步驟

1. 檢查自己顯卡相容性

    https://developer.nvidia.com/cuda-gpus#compute

2. 安裝相容的CUDA Tookkit版本

    例如[Windows 10 x64 CUDA Toolkit 9.0](https://developer.nvidia.com/cuda-90-download-archive?target_os=Windows&target_arch=x86_64&target_version=10&target_type=exenetwork)

3. 安裝相容CUDA的cuDNN版本

    例如[cuDNN v7.6.4, for CUDA 9.0](https://developer.nvidia.com/rdp/cudnn-download)

3. 安裝Anaconda

4. 使用conda建立虛擬化的python執行環境，例如命名為`faceswap`

    ```shell
    conda create -n faceswap python=3.6
    conda activate faceswap
    ```

5. 初始化訓練環境

    ```shell
    git clone --depth 1 https://github.com/deepfakes/faceswap.git
    cd faceswap
    python setup.py
    ```

    Nvidia的docker只支援linux，而我們使用的是windows，所以enable不了...

6. 開始使用

    ```shell
    python faceswap.py -h
    ```

# Data Preparation

```shell
python faceswap.py extract -i src\b.mp4 -o src/face_target
python faceswap.py extract -i src\c.avi -o src/face_source
```

開始訓練模型

```shell
python faceswap.py train -A src/face_source -B src/face_target -m src/face_source_to_target_model/ -bs 32 --memory-saving-gradients --optimizer-savings
```

抽取影格

```shell
python tools.py effmpeg -i src\c.avi -o src\frames_raw -s 00:19:00 -e 00:20:00 --logfile tmp.log
```

# 環境清理

1. 移除python虛擬環境

    ```
    conda env remove --name faceswap
    ```

2. 從`程式與功能`中移除CUDA、Anaconda


初試 Deepfake


# 時間和空間

如果在一個飛行中的飛機中往前走動10步，15分鐘後再往後走10步，是否能說是回到「原位」呢？對飛機上的人來說也許是，但對地面上的人而言可能就不是了，因此物體的運動與否是取決於所處的虛擬座標空間。如果把虛擬座標系統的中心放在宇宙的中心，是否就能建立絕對空間呢？我們知道星系正以極快的速度朝其他星系的反方向奔跑，且離我們越遠的星系跑得愈快，所以我們仍然無法知道自己的運動方向和速度，也就無法建立絕對的系統。

根據羅素斷言，一個理論如果沒有實驗能夠驗證真偽的話，那麼這個理論就沒有意義了；同樣地，從飛機的例子中，我們無法找到一個方法來觀測絕對速度，也無法證明自己是否處於運動中，那麼是否處於「原位」自然無法判斷，因此，絕對空間（亞里斯多德空間）的概念也就沒有意義。被迫跳脫絕對空間的思維束縛，我們能觀測的就只有相對空間。既然運動與空間是相對的，而運動又是單位時間內物體在空間中移動的距離，那麼時間是否也可能是相對的呢？

# 光的速度

法拉第發現電磁感應，並且提出「場」的概念，場的重要性在於它能跨越空間，馬克思威爾在法拉第去世後，更進一步歸納出一套方程式來總結各種電子學及磁力學現象。馬克思威爾為了使方程式適用法拉第的實驗觀測結果，在方程式裡引入「位移電流」，卻意外發現新的方程式能以波動方程式的方式表達，並預測了電磁波的存在。馬克思威爾方程式更預測電場與磁場的強度比就是波的速度，即299,792,458m/s，令人驚訝的是，這就是光速！由於此速度的計算過程沒有牽涉波源或接受裝置的速度，所以不是相對的，比較像是自然界中的常數。

在十九世紀末，科學家廣泛相信波必須透過介質才能傳送，因此認為光必須藉由以太這種媒介來傳播，但是邁克生－莫雷眾多檢測以太的實驗都得到無效的結果，最終被迫捨棄以太的概念。以一個簡單的例子來比喻，假如一個人在平靜水面的泳速是5000m/s，河流水流速度3000m/s，對河岸上的人來說，此人順流時會是8000m/s，逆流時會是2000m/s。邁克生－莫雷的實驗就類似這個例子，游泳的人就是實驗中的光束，河流代表以太，河岸就是實驗設備，固定在地球上靜止不動。如果宇宙中存在以太，那麼光速應該會發生變化，但最終測得任何時間任何方向上，光速都是相同的。

根據常識，想像一個人以接近光速前進追上一束光，那麼此人看到的光速和我們看到的光速就會不一樣，這與邁克生－莫雷實驗產生矛盾；因此我們只能被迫接受馬克思威爾方程式的正確性：不管我們跑多快，光都會以299,792,458m/s的速度離我們而去。這代表我們永遠無法追上一束光，也暗示我們應該拋棄絕對時間的概念。（光束本身的時間過得比較快？）

> ### 時間軸
> 法拉第（電磁感應）→ 馬克思威爾（電磁波）→ 邁克生－莫雷（以太）

# 狹義相對論

在討論$E=mc^2$之前，首先要理解愛因斯坦的觀點，也就是狹義相對論。

## 第一部分：透過公理來計算結論

狹義相對論存在兩個公理：
1. 馬克思威爾方程式成立，光速永遠保持不變，無論光源或觀察者本身的速度是多少
2. 遵循伽利略提出的觀點：沒有任何實驗能測量出絕對速度

根據愛因斯坦光鐘與火車的想像實驗，運動中的光鐘需要走較遠的距離，需要更長的時間來完成一個滴答，如果根據馬克斯威爾說的光速不變，那麼時間在不同地方是以不同速度運行，它的快慢取決於觀測者之間的相對速度。因此，絕對時間與恆定光速之間有矛盾。

![](/posts/2019-09-11-mass-energy-equation/light-clock.png "光鐘示意圖")

根據光鐘實驗，我們可以進一步推導出相對論中非常重要的一條公式—時間延長性：
$$$
\gamma = \frac{1}{\sqrt{1 - \frac{v^2}{c^2}}}
$$$

> 詳細推導過程可參考書中pp.63-66，只需要知道畢氏定理即可理解

## 第二部分：藉由實驗來驗證

布魯克黑文實驗室在20世紀初製造了一架機器，可以發射一束緲子（緲子是一個類似電子的基本粒子，生命週期只有2.2微秒），並圍繞著14公尺的環形軌道，以99.94%的光速運行。按照常理，2.2微秒只能使緲子繞著軌道轉15圈，但實際上它們轉了超過400圈，生命週期變成29倍，大約比60微秒稍多。如果將實驗結果帶入公式，可以發現與理論吻合：

$$$
\begin{aligned}
\gamma &= \frac{1}{\sqrt{1 - \frac{v^2}{c^2}}} \\
       &= \frac{1}{\sqrt{1 - 0.9994^2}} \\
       &= \frac{1}{0.0346358196091849} \\
       &\approx 28.87
\end{aligned}
$$$

以上只是從觀察者的角度來看，換成運動者的角度來思考，如果我們和緲子一起環繞軌道，這表示2.2微秒內一共繞了400圈，乍聽之下會覺得奇怪，但其實是因為軌道的周長是會縮短的，而且縮短的程度與緲子生命週期被延長的程度正好一樣。換言之，空間也具有延展性，當物體移動時會變小！

# 時空

p77
愛因斯坦理論的三個核心：不變性、因果性、距離

p83
不變性：假設時間和空間可以合而為一變成一個整體，稱為「時空」，則時空中的距離就是具有不變性的

p84
因果性：起因和結果的先後順序不能反轉，但事件發生間隔足夠遠時，它們之間不存在任何可能的聯繫，這些事件之間的順序是可以顛倒的

p88
測地線：兩點之間的距離

p91
對任意事件，我們都能找到四個獨有的數字來描述它

p92
時間$t$與距離$x$可以透過校準速度$v$進行互換：$v=\frac{x}{t}$
天文學中常見的例子就是「光年」，所用的校準速度是光速

p94-95
奧坎剃刀原則：應該先嘗試最簡單的假設，在假設失敗時才逐漸提高複雜程度，直到假設符合實驗結果。
因此假設空間屬於歐幾里得式，已知的測量方法都可以套用至新系統，同時假設時空是不變的，在各處都是一樣的，最終時空中的距離只有兩種可能的計算方式：
1. $s^2=(ct)^2+x^2$
2. $s^2=(ct)^2-x^2$

p98-101
$s$保持不變的情況下，不同觀測者會得出不同的$x$和$t$，做出時空圖會發現第一種計算方式（加法畢氏定理）違反因果性，因此只剩下第二種計算方式，也代表歐氏幾何並不適用，於是數學家將適用這條公式計算兩點距離的空間另取了名字，稱為「雙曲空間」，物理學家則稱「閔考斯基時空」

p107
B無法對O造成任何影響，因此事件O和B沒有因果聯繫，沒有違反因果性

p108
45度軸夾住的上下兩區，其中發生的事件與O之間的資訊傳遞速度 < c，左右兩區 > c
c即光速

p115
雙生子矛盾，考慮加速度？

# 為什麼$E=mc^2$

p128-129
第一部分：時空中也可以使用向量，且需要四個數字來描述，稱為「時空速度向量」，向量長度為$c$，且被限制在未來光錐中。

p131-132
第二部分：宇宙中存在一個特殊的向量，稱為「動量向量」，不論周遭宇宙發生任何變化，它都不會改變，這個獨一無二的向量是疊加許多其他向量而得到的

p138
移動的事物可以用動量向量來表達
能量守恆定律
因為物理法則對時間具有不變性，所以能量守恆才能實現

p142
基礎方程式必須用存在於時空中的事物來建構，而不是任何只存在空間或時間中的事物

> 動量這種最基礎的定理，只是存在空間中的箭頭，是否在時空中也適用（具有不變性）？時空中確實存在一個具有不變性的物理量(p143)

p144-146
空間中動量向量的長度可表示為$m\frac{\Delta x}{\Delta t}$
則在四維中，根據閔考斯基時空距離的公式，時空中箭頭的長度可表示為$(\Delta s)^2=(c\Delta t)^2-(\Delta x)^2$
其中只有$\Delta s$所代表的長度對每個觀測者都一樣（$\Delta t$和$\Delta x$都無法滿足這個要求），且光速$c$在時空中也不變
假如$\Delta s$單位是公尺，且光速$c$的單位是公尺每秒，則$\frac{\Delta s}{c}$的單位為秒（四維的時間段長度）
若將$\Delta x$替換成$\Delta s$，將$\Delta t$替換成$\frac{\Delta s}{c}$，即可從三維的$\frac{\Delta x}{\Delta t}$推算四維中的速度：
$$$
\frac{\Delta s}{\frac{\Delta s}{c}} = c
$$$
我們得到了三維中的動量在四維中對應的量，就是宇宙航速極限$c$，一個在時空中運動的事物所擁有的速度大小總是$c$，而它的方向取決於事物所運動的方向。新的動量箭頭長度總是$mc$

p148
$$$
\frac{\Delta s}{c} = \frac{\sqrt{(c\Delta t)^2-(\Delta x)^2}}{c} = \frac{\Delta t}{\gamma}
$$$
其中$\gamma = 1/\sqrt{1 - v^2/c^2}$且$v=\frac{\Delta x}{\Delta t}$

p149
時空中動量向量在空間方向上的長度為$\gamma mv$，在時間方向上的長度為$\gamma mc$

p151-152
由於$c$是常數，從所有觀測者的角度來說都不變，因此$\gamma mc$可視為質量守恆
如果$\gamma mc$守恆，則$\gamma mc^2$亦守恆
對於不超過光速百分之十的速度（$v/c=0.1$）的情況，可以用簡化公式估算$\gamma$：

$$$
\begin{aligned}
\gamma &= \frac{1}{\sqrt{1 - \frac{v^2}{c^2}}} \\
       &\approx 1 + \frac{1}{2}\frac{v^2}{c^2}
\end{aligned}
$$$

則
$$$
\gamma mc^2 \approx mc^2 + \frac{1}{2}mv^2
$$$
是守恆的
> 守恆的能量 = 所有粒子的質量和乘以$c^2$ + 所有粒子的動能和

p159
目前研究光子的人都同意，光子是沒有質量的，那麼運動速度就是$c$

# 為什麼原子、捕鼠夾和星星的能量都值得我們關注？

p169
科學知識都只是那些還沒被證明是錯誤的理論和世界觀的集合

# 質量之源

# 彎曲的時空

兩個人從赤道的兩點沿著平行直線往北走，沒有受到外力干擾，最終卻會碰在一起，這是因為地球上任意點都可以假設適用歐式平面幾何，但當這些點組合在一起時，就形成球體而具有彎曲的表面了；同樣地，在時空中，從局部來說任何地方都適用平坦的閔考斯基時空，但將細微的時空塊組合在一起之後，就變成彎曲的時空了。結論就是，由於幾何的原因，萬有引力被剔除了。太陽是具有巨大質量的物體，因此它附近的時空發生彎曲，地球自身其實是在時空中自由地運行著，只是因為太陽周圍的時空發生了彎曲才使地球看上去像在繞圈。

# 參考資料

- [《為什麼E=mc2？看懂質能互換與相對論的第一本書》](https://www.books.com.tw/products/0010826425)
- [為什麼E=mc2？看懂質能互換與相對論的第一本書 - 考克斯(Brian Cox)、福肖(Jeff Forshaw) - Google 圖書](https://books.google.com.tw/books?id=vM2mDwAAQBAJ&printsec=frontcover&hl=zh-TW#v=onepage&q&f=false)


《為什麼 E=mc^2》閱讀筆記

第一部分：透過公理來計算結論

為什麼原子、捕鼠夾和星星的能量都值得我們關注？


在Dashboard的應用裡，總是少不了精緻好看的互動式圖形，諸如長條圖、折線圖等，雖然現今已有許多免費而且內建多種圖形的Library可以直接採用，但是需要客製化樣式的時候，就知道哪個Library沒穿褲子了。因此，不如打從一開始就學好低階的繪圖工具，不管想刻什麼圖都能搞定，而其中最廣為人知的就是D3這套Library了。

# TL;DR

步驟一：使用React維護DOM Tree
步驟二：使用D3映射Datapoint至DOM元素屬性
步驟三：使用CSS處理靜態樣式細節

# D3

官方正式全名為`Data-Driven Documents`，乍看之下完全無法理解D3到底是什麼，所以我個人認為解讀成`Vectorized jQuery`較容易理解。

## 與jQuery相似之處

直接舉個例子來看，D3的API支援Method chain，而且是直接操作DOM tree（`select`、`append`、`attr`、`style`、...）

```js showLineNumbers
/* https://codepen.io/gocreating/pen/PrRbZo */

d3.select('body')
  .append('div')
  .attr('class', 'red')
  .style('width', '20px')
  .style('height', '10px')
  .style('border', '10px solid red')
```

![](/posts/2019-06-24-how-to-integrate-react-with-d3/demo1.png "效果預覽")

## 向量化之處

D3最大的特色就是能夠將資料綁定至DOM元素，並以向量化的方式來操作DOM tree。如下方範例，`.data(data).enter()`之後的method都是批次套用至data內的每一筆entry，因此我們目前有三筆entry，就會`append('rect')`三次。

而向量化呼叫D3 API時，可以透過傳入的callback function來映射datapoint至對應的DOM元素屬性，以下例而言，我們將datapoint的`value`及`color`映射至不同rect元素的寬度`width`及背景色`fill`，而`y`座標與datapoint本身無關，但與索引順序相關，因此只取index值來進行映射。

```js showLineNumbers highlightLines="10"
/* https://codepen.io/gocreating/pen/PrRbyz */

const data = [
  { value: 100, color: '#f00'},
  { value: 150, color: '#0f0' },
  { value: 50, color: '#00f' },
]
d3.select('#my-svg')
  .selectAll('.my-bar')
  .data(data)
  .enter()
  .append('rect')
  .attr('class', 'my-bar')
  .attr('y', (d, i) => i * 30)
  .attr('width', (d) => d.value)
  .attr('height', 20)
  .attr('fill', (d, i) => d.color)
```

![](/posts/2019-06-24-how-to-integrate-react-with-d3/demo2.png "效果預覽")

使用Vanilla D3必須熟悉`enter()`、`exit()`及`update()`三個重要觀念，但是本文著重在與React的整合，以結論而言，最終並不會使用到這三個method。

# SVG

眼尖的讀者應該已經發現，前面的例子其實是使用SVG元素來做為整個圖形的容器，但是D3並不侷限於用在SVG上，你也可以使用`div`或`span`等HTML元素來畫出圖形，只是慣例上使用SVG會比使用其他HTML元素更方便也更有效率，因此D3的使用者一般都是搭配SVG來繪圖。此外，D3也針對SVG繪圖提供了一些好用的helper，像是axis、tooltip等常見的圖形元素。

常見的SVG元素包括：

- `<g />`（群組）
- `<rect />`
- `<circle />`
- `<line />`
- `<path />`（不規則形）
- `<text />`
- etc.

多數元素都能直覺地顧名思義，而其中`<g />`可能較難判斷，它表示群組的概念，也可以想成Photoshop或是Illustrator中的`圖層`。如果想更加深入了解SVG，非常推薦閱讀參考資料中的[SVG 完整教學 31 天](https://www.oxxostudio.tw/articles/201410/svg-tutorial.html)。

# 在React中使用D3

D3會操作到DOM，React也會操作到DOM，如果兩套Library一起使用，顯然會互相衝突而導致程式碼難以維護。「[3 ways to integrate React and D3](https://frontendcharts.com/react-d3-integrate/)」一文中提供了三種整合React與D3的策略：`D3-oriented`、`React-oriented`與`Hybrid`，筆者認為混用才是上策，經過自家產品實驗至目前為止，還沒遇過實作不出來的設計，Production環境下也都正常運作。

## 範例

讓我們直接從一個例子來說明，假設我們想將3筆資料轉化成Scatter plot，並依據資料值來設定每個圓的座標及半徑：

![](/posts/2019-06-24-how-to-integrate-react-with-d3/demo3.png "效果預覽")

在React中，我們當然會將這張圖封裝成一個Component，姑且稱做`SomeAwesomeGraph`，而資料源由外部傳入做為prop。從生命週期來看，分別在`componentDidMount()`及`componentDidUpdate()`時呼叫instance method `draw()`，也就是使用D3進行繪圖操作的核心。

```js showLineNumbers highlightLines="7-9,23-29,38-43"
/* https://codepen.io/gocreating/pen/QXmpaL */

const { Component } = React

// 步驟三：使用CSS處理靜態樣式細節
const Graph = styled.svg`
  .my-circle {
    fill: red;
  }
`

class SomeAwesomeGraph extends Component {
  componentDidMount() {
    this.draw()
  }

  componentDidUpdate() {
    this.draw()
  }

  draw = () => {
    // 步驟二：使用D3映射Datapoint至DOM元素屬性
    const { data } = this.props
    d3.select('#my-svg g.container')
      .selectAll('.my-circle')
      .data(data)
      .attr('cx', d => d.cx)
      .attr('cy', d => d.cy)
      .attr('r', d => d.value * 2)
  }

  render() {
    // 步驟一：使用React維護DOM Tree
    const { data } = this.props
    return (
      <Graph id="my-svg">
        <g className="container">
          {data.map((d, i) => (
            <circle
              key={i}
              className="my-circle"
            />
          ))}
        </g>
      </Graph>
    )
  }
}

const App = () => (
  <SomeAwesomeGraph
    data={[
      { cx: 100, cy: 100, value: 7 },
      { cx: 150, cy: 70, value: 15 },
      { cx: 50, cy: 30, value: 4 },
    ]}
  />
)

ReactDOM.render(<App />, document.getElementById('app'));
```

實際整合的步驟可以分為三個：

## 步驟一：使用React維護DOM Tree

（Line 38-43）
透過JS array的`map()`將datapoint轉換成DOM元素，這是非常典型的React語法。由於DOM元素的建立及刪除寫在`render()`裡，所以完全利用了React的vDOM達到最佳性能，非常乾淨俐落。

## 步驟二：使用D3映射Datapoint至DOM元素屬性

（Line 23-29）
DOM Tree既已建立，便不需要理解D3複雜的`enter()`、`exit()`和`update()`機制，更能專注在`draw()`裡面繪製圖形。`draw()`的實作應著重在將datapoint映射至DOM元素的屬性，所以會呼叫大量的`attr`、`style`、`text`等調整屬性的API，若圖形中有使用到繪製X軸Y軸或Tooltip之類的Helper，也須在`draw()`內一起使用。如果圖形過大，也建議將`draw()`拆分成更細小的模組增加可讀性。

## 步驟三：使用CSS處理靜態樣式細節

（Line 7-9）
一個完整圖形裡肯定會有不隨資料變動的樣式，像是本例中圓圈的背景色，只需要視情況套用適合的CSS即可（inline、className、styled-component、CSS-in-JS、...）

# Reference

- [Official site](https://d3js.org/)
- [SVG 完整教學 31 天](https://www.oxxostudio.tw/articles/201410/svg-tutorial.html)
- [3 ways to integrate React and D3](https://frontendcharts.com/react-d3-integrate/)


如何整合React與D3

步驟二：使用D3映射Datapoint至DOM元素屬性

步驟三：使用CSS處理靜態樣式細節


完整程式碼：[Virtual Table | CodePen](https://codepen.io/gocreating/pen/mYNNxg)

# 使用情境

各家Virtual List的Library總是號稱自己好棒棒，但是真實的世界總是會面臨多種困境，以至於我們無法簡單粗暴的套用現成Library：

1. 需要大量的客製化設計

    眾所周知，第三方Library好處是快速驗證，壞處就是每當想要客製化樣式時，絕對是場災難

2. 技術債太多

    通常產品開發為求快速，一開始的需求都盡可能忽略效能，當功能越加越多，效能負擔越來越重，最終遇到了渲染時的效能瓶頸，才發現Legacy Code已經堆積如山，想改也不是一時半會的功夫

3. Library都是假表格

    這其實算是個人潔癖了，html本身是帶有語意的，如果可以，應該盡可能使用正確的標籤，然而各家Library通常為了支援各種華麗的特效，會使用`div`偽裝成表格元素來簡化實作難度，有點本末倒置而失去html原始含意

由於上述的幾個事實，我不得不說reinventing其實比reusing更有效率，也使我決定親自實作virtual table，並將過程中的體悟記錄於本文。

# 資料結構

如果你的資料量多到會造成效能問題，那麼資料肯定不會是以inline的方式塞在Component裡，所以合理地假設資料結構是一個物件陣列：

```js showLineNumbers
const data = [
  { id: 'a', value: 'Apple' },
  { id: 'b', value: 'Banana' },
  { id: 'c', value: 'Cat' },
  // ...
  { id: 'x', value: 'X-ray' },
  { id: 'y', value: 'Yield' },
  { id: 'z', value: 'Zebra' },
]
```

# 虛擬化原理

我們從DOM的座標系統可以計算出實際會出現在可視範圍（Viewport）內的表格列的index範圍`indexBegin`至`indexEnd`，而可視範圍外的表格列根本不會被看到，因此可以不進行渲染，也就是透過虛擬化可視範圍外的表格列來換取效能。實作方式可以在表格的頭尾各加上一個填充空間用的placeholder，透過計算給予精確的高度，如此就能避免跑版：

```jsx showLineNumbers highlightLines="18,20"
const range = (begin, end) => [...Array(Math.max(end - begin, 0)).keys()].map(n => n + begin)

class VirtualTable extends Component {
  table = React.createRef()

  state = {
    viewportHeight: 0,
    indexBegin: 0,
    indexEnd: 0,
  }

  render() {
    const { rowHeight, renderRow } = this.props
    const { indexBegin, indexEnd } = this.state

    return (
      <table ref={this.table}>
        <tr style={{ height: rowHeight * indexBegin }} />
        {range(indexBegin, indexEnd).map(rowIndex => renderRow(data[rowIndex]))}
        <tr style={{ height: rowHeight * (data.length - indexEnd) }} />
      </table>
    )
  }
}
```

# 演算法

已知輸入：
- $N$–資料筆數
- $N_{margin}$–Margin列數，使我們可以虛擬地擴展可視範圍，來達到預渲染可視範圍外的表格列的效果
- $H_{viewport}$–可視範圍高度
- $H_{row}$–表格每列的固定行高
- $Y_{row}^{(0)}$–表格第一列上緣的Y軸座標

欲求輸出：
- $i_{begin}$–可視範圍內第一個表格列的index值
- $i_{end}$–可視範圍內最後一個表格列的index值加1

為使計算方便及符合iterator的使用慣例，$i_{end}$指向的是可視範圍外的表格列，使渲染的表格列index範圍$\in[i_{begin},i_{end})$，完整演算法如下：

$$$
\begin{aligned}
& \bold{Input}:\\
& ~~~~N,~N_{margin},~H_{viewport},~H_{row},~Y_{row}^{(0)} \\
& \bold{Output}: \\
& ~~~~i_{begin},~i_{end}~where
  ~0
  ~\leqslant~i_{begin}
  ~\leqslant~i_{end}
  ~\leqslant~N \\
\\
& h_{margin}~= N_{margin} \times H_{row}^{(N)} \\
& y_{upper}~~~= Y_{row}^{(0)} + h_{margin} \\
& y_{lower}~~~= Y_{row}^{(0)} + \Sigma_{k=0}^N{H_{row}^{(k)}} - h_{margin} \\
& ~~~~~~~~~~~~= Y_{row}^{(0)} + N \times H_{row} - h_{margin} \\
\\
& \bold{switch}~y_{upper}~\bold{do} \\
& ~~~~\bold{when}~\in[0, H_{viewport}] \\
& ~~~~~~~~i_{begin} = 0 \\
& ~~~~\bold{when} \gt H_{viewport} \\
& ~~~~~~~~i_{begin} = N \\
& ~~~~\bold{else} \\
& ~~~~~~~~i_{begin} = \lfloor \frac{-y_{upper}}{H_{row}^{(N)}} \rfloor \\
& \bold{end} \\
\\
& \bold{switch}~y_{lower}~\bold{do} \\
& ~~~~\bold{when} \lt 0 \\
& ~~~~~~~~i_{end} = 0 \\
& ~~~~\bold{when}~\in[0, H_{viewport}] \\
& ~~~~~~~~i_{end} = N \\
& ~~~~\bold{else} \\
& ~~~~~~~~i_{end} = N - \lfloor \frac{y_{lower}-H_{viewport}}{H_{row}^{(N)}} \rfloor \\
& \bold{end} \\
\\
& \bold{Return}~i_{begin}, i_{end}
\end{aligned}
$$$

# 演算法實作

在react中可以直接將演算法實作於Component的member function，input來自props、state以及呼叫DOM API的執行結果，output則套用至state中儲存：

```jsx showLineNumbers highlightLines="4-36"
class VirtualTable extends Component {
  // ...

  syncTable = () => {
    const { marginRowCount, rowHeight, data } = this.props
    const { viewportHeight } = this.state
    const rectTable = this.table.current.getBoundingClientRect()
    const rowCount = data.length
    const heightMargin = marginRowCount * rowHeight
    const yUpper = rectTable.top + heightMargin
    const yLower = rectTable.top + rowHeight * rowCount - heightMargin

    let indexBegin
    let indexEnd

    if (0 <= yUpper && yUpper <= viewportHeight) {
      indexBegin = 0
    } else if (yUpper > viewportHeight) {
      indexBegin = rowCount
    } else {
      indexBegin = Math.floor(-yUpper / rowHeight)
    }

    if (yLower < 0) {
      indexEnd = 0
    } else if (0 <= yLower && yLower <= viewportHeight) {
      indexEnd = rowCount
    } else {
      indexEnd = rowCount - Math.floor((yLower - viewportHeight) / rowHeight)
    }

    this.setState({
      indexBegin,
      indexEnd,
    })
  }

  render() {
    // ...
  }
}
```

## 事件綁定

有了核心演算法之後，只需在viewport的scroll及resize事件中進行重繪，就能製造出如假包換的表格了！

```jsx showLineNumbers highlightLines="4-9,11-14,16-22,24-26"
class VirtualTable extends Component {
  // ...

  componentDidMount() {
    this.handleWindowResize()
    this.handleWindowScroll()
    window.addEventListener('resize', this.handleWindowResize)
    window.addEventListener('scroll', this.handleWindowScroll)
  }

  componentWillUnmount() {
    window.removeEventListener('resize', this.handleWindowResize)
    window.removeEventListener('scroll', this.handleWindowScroll)
  }

  handleWindowResize = () => {
    const viewportHeight = Math.max(
      document.documentElement.clientHeight,
      window.innerHeight || 0
    )
    this.setState({ viewportHeight }, () => this.syncTable())
  }

  handleWindowScroll = () => {
    this.syncTable()
  }

  syncTable = () => {
    // ...
  }

  render() {
    // ...
  }
}
```

# 效果瀏覽

如下圖所示，隨著頁面捲動，可視範圍外的表格列不會被渲染出來，且最頂部及最底部的placeholder會不斷修正高度來避免跑版，只可視範圍內的每一列都會被渲染出來：

![](/posts/2019-06-10-how-to-implement-virtual-table-with-react/demo1.gif)

此外，如果將`marginRowCount`設定為負數，還可以看到有趣的效果：

![](/posts/2019-06-10-how-to-implement-virtual-table-with-react/demo2.gif)

# 結語

其實寫過Android的朋友應該知道，ListView在OS level就實作列表的虛擬化了，然而網頁領域目前沒有原生的方式可以達到，只能透過像是本文實作的方法自行Hack。文中提供了通用的演算法，並且以react為例，以最簡潔的程式碼實作出一個POC，比起套用繁雜瑣碎的Library，其實自行實作難度一點都不高，也能保有高度客製化樣式的自由度。

## Virtual Table的陷阱

多數情況下其實我們不會用到Virtual Table，但是要使用的朋友還需注意一個小問題。由於可視範圍外的表格列沒有真的被渲染，所以真正被渲染的表格列在DOM裡的index其實是浮動的，因此諸如`tr:nth-child(odd)`或`tr:nth-child(even)`之類的CSS選擇器將不適用。


如何以React實作 Virtual Table?


看過這部影集之前，從來沒有認真研究過車諾比事故的前因後果，一直以為這場核災只是技術不純熟還有天時地利的巧合所導致，殊不知背後隱藏的其實是共產主義的層層包庇與謊言。

電廠一直以來都在進行蒸汽渦輪測試，但是前三次都失敗了，事發當日的值班主任阿基莫夫領頭進行第四次測試，由於心裡預期測試不會通過，又必須向「上級」給個交代，因此毫不遵照程序，罔顧安全胡亂指揮，只為產生測試結果好交差了事，最終釀成一場浩劫。

![](/posts/2019-06-07-chernobyl/Aleksandr-Akimov.jpg "亞歷山大·費奧多羅維奇·阿基莫夫")

雖然表面上抓出了戰犯，也判處了10年刑期，但實際上這更應該解讀為因共產主義而釀成的悲劇。共產黨的一貫作風是解決不了問題，就解決提出問題的人，還有發生災難時優先宣布「沒事兒沒事兒」來掩蓋事實，在劇中總是能一再感受到黨的威嚴，諷刺的是正是黨的體制造成了同志們慣性以謊言掩蓋真相，延誤了許多可以被挽救的災情。

![](/posts/2019-06-07-chernobyl/Chernobyl.jpg "車諾比地理位置示意")

雖然台灣是民主體制，但是媒體和人民似乎都已經受到黨的控制，每天都活在謊言之中，誰能保證台灣不會發生核災等級的事故呢？

# 參考資料

- [切爾諾貝利核電站是為何爆炸的？李永樂老師講核反應堆原理](https://www.youtube.com/watch?v=Cc-xlILOeEM)


我看《核爆家園》


完整程式碼：[Flexible Layout | CodePen](https://codepen.io/gocreating/pen/arggJm)

# 使用情境

同一個網站裡，每一頁總會有一部份的元素是共用的，例如Navigation、Header、Footer、Sidebar等，通常我們會將這些重複的UI抽象化成樣板元件，雖然這樣做已經大幅提升元件的復用性，卻未必能保留充足的彈性。真實的產品面對不同的需求，可能會需要實作各種Layout的頁面：
- 有Header也有Sidebar
- 有Sticky Header但不要Sidebar
- 有Sticky Header與Sticky Secondary Navigation還要有Sidebar
- ...

甚至要支援透過互動來改變Layout：
- 點擊全螢幕按鈕時隱藏Sidebar
- 向上捲動時顯示Navigation，向下捲動時則隱藏
- ...

# Layout Component

為了因應不同需求，我們可以將需要復用的元件（`Navigation`、`Footer`）集中在Layout元件（`AppLayout`）裡：

```jsx
const Navigation = () => (
  <ul>
    <li><Link to="/page/1">Page One</Link></li>
    <li><Link to="/page/2">Page Two</Link></li>
    <li><Link to="/page/3">Page Three</Link></li>
  </ul>
)

const Footer = () => (
  <footer>
    <hr />
    This page has footer.
  </footer>
)

const AppLayout = ({ navigation, footer, children }) => (
  <>
    <Navigation />
    {children}
    {footer && <Footer />}
  </>
)

AppLayout.propTypes = {
  navigation: PropTypes.bool,
  footer: PropTypes.bool,
}

AppLayout.defaultProps = {
  navigation: true,
  footer: false,
}
```

在需要套用樣板的頁面就可以直接將`AppLayout`當作root component來使用，如果想為特定頁面調整Layout，只需要改變傳入的props即可：

```jsx highlightLines="2, 4, 10"
const PageOne = () => (
  <AppLayout footer>
    This is a page wrapped with layout component.
  </AppLayout>
)

const App = () => (
  <BrowserRouter>
    <Switch>
      <Route exact path="/page/1" component={PageOne} />
      <Route component={PageOne} />
    </Switch>
  </BrowserRouter>
)
```

# 使用HOC擴充彈性

如果每一個頁面的Layout不會隨著使用者的互動而改變，也就是各頁面裡`AppLayout`的prop始終不變的話，我們其實可以將其提升為HOC `withAppLayout`：

```jsx
const withAppLayout = layoutProps => WrappedComponent => pageProps => (
  <AppLayout {...layoutProps}>
    <WrappedComponent {...pageProps} />
  </AppLayout>
)
```

使用方式可以在page level：

```jsx highlightLines="1, 11"
const PageTwo = withAppLayout({ footer: true })(() => (
  <>
    This is a page wrapped with page-level layout HOC.
  </>
))

const App = () => (
  <BrowserRouter>
    <Switch>
      <Route exact path="/page/1" component={PageOne} />
      <Route exact path="/page/2" component={PageTwo} />
      <Route component={PageOne} />
    </Switch>
  </BrowserRouter>
)
```

甚至可以在route level：

```jsx highlightLines="12"
const PageThree = () => (
  <>
    This is a page wrapped with route-level layout HOC.
  </>
)

const App = () => (
  <BrowserRouter>
    <Switch>
      <Route exact path="/page/1" component={PageOne} />
      <Route exact path="/page/2" component={PageTwo} />
      <Route exact path="/page/3" component={withAppLayout({ footer: true })(PageThree)} />
      <Route component={PageOne} />
    </Switch>
  </BrowserRouter>
)
```

# 技術總結

Layout的實作方式可以透過Component的抽象，也可以透過簡單的封裝提供HOC的抽象，`withAppLayout`的`layoutProps`不僅與`AppLayout`的`props`保持一致，提高復用性，甚至可以在路由的層級就決定好每一個頁面的Layout，方便集中管理，偶爾遇到需要動態Layout的頁面也能隨時改用`AppLayout`元件，傳入不同的props就能根據使用者的行為做出千變萬化的Layout了。


如何彈性地抽象化網站樣板的UI?


# 參考效果

![](/posts/2019-05-28-how-to-implement-paginated-progress-bar/demo.gif)

完整程式碼：[Progress Navigation | Codepen](https://codepen.io/gocreating/pen/OYwENp)

# 使用情境

在某些應用裡，偶爾會需要像是`安裝精靈`或是`入門導覽`等long-term navigation的操作體驗，每一個步驟都不太能立刻完成，甚至需要等到下次登入時再繼續進行。最近要以React來實作這般功能時，發現不如預期中容易，關鍵在於此功能必須滿足：

## 容易分工維護及整合

從工程團隊的角度來看，程式碼本身應該要簡潔明確，核心的routing邏輯應該抽成獨立模組來維護，且不同team member應該要能平行且專注於刻出不同步驟的內頁。

## 保留擴充功能的彈性

根據產品需求，這個功能在未來可能加入新的擴充，例如：

- user切換步驟的行為要被記錄或追蹤（例如背景傳送至Mixpanel或GA）
- 容易在分頁內管理整體流程，隨時可以插入新的實驗性路徑（例如對男性使用者，要直接從`Step 3`跳至`Step 7`）
- 儲存目前進行到的步驟，以便下次登入時回到未完成的步驟

因此，架構上可以採用react-router來維護每個獨立的步驟，並且給定每個步驟的唯一路徑：

``` jsx
const App = () => (
  <BrowserRouter>
    <Switch>
      <Route exact path="/page/1" component={StepOne} />
      <Route exact path="/page/2" component={StepTwo} />
      <Route exact path="/page/3" component={StepThree} />
      <Route component={StepOne} />
    </Switch>
  </BrowserRouter>
)
```

# 步驟間的路由抽象化

每個步驟之間必須由一個獨立模組來管理跳頁，還要保持步驟內頁可以掌控整體流程的權限，還要監聽頁面切換以便蒐集user的操作行為，一個可靠的作法就是模仿react-router中的`withRouter`，自己實作一個步驟間路由的HOC，封裝react-router的`push` method，並且提供`goToPath`之類的method給步驟內頁元件來掌控整體流程：

``` jsx
const withProgressRouter = (WrappedComponent) => {
  class HelperComponent extends Component {
    goToPath = (path) => {
      const { history } = this.props;
      // 可以在此與backend互動
      history.push(path);
    }

    render() {
      return (
        <WrappedComponent
          goToPath={this.goToPath}
          {...this.props}
        />
      );
    }
  }
  return withRouter(HelperComponent)
}
```

不同步驟之間共享的UI（例如`上一步`、`下一步`）可以獨立成一個Component：

``` jsx
const ProgressRouter = ({ onBackClick, onNextClick, children }) => (
  <>
    <button onClick={onBackClick}>back</button>
    <button onClick={onNextClick}>next</button>
    <hr />
    {children}
  </>
)
```

# 使用方式

步驟內頁只要透過HOC提供的`goToPath`就能自由地控制整體流程，同時也能共享同一套切換步驟的UI，完全專注於步驟內頁的設計：

``` jsx
const StepOne = withProgressRouter(({ goToPath }) => (
  <ProgressRouter
    onBackClick={() => goToPath('/step/1')}
    onNextClick={() => goToPath('/step/2')}
  >
    Step One
  </ProgressRouter>
))

const StepTwo = withProgressRouter(({ goToPath }) => (
  <ProgressRouter
    onBackClick={() => goToPath('/step/1')}
    onNextClick={() => goToPath('/step/3')}
  >
    Step Two
  </ProgressRouter>
))

const StepThree = withProgressRouter(({ goToPath }) => (
  <ProgressRouter
    onBackClick={() => goToPath('/step/2')}
    onNextClick={() => goToPath('/step/3')}
  >
    Step Three
  </ProgressRouter>
))
```


如何實作分頁式的Progress Navigation?


# 失落文明

現今地球各處皆可發現歐帕茲的蹤跡，可以合理懷疑古代曾經存在高度文明。
但現今都已無法考究歐帕茲產生的動機、原理及背景，表示人們沒有將這些東西傳承至今，其原因很可能是這些文明都是一夕之間消失或滅亡，如遭遇火山爆發、地殼變動或者大洪水。現今之所以查無失落文明的蹤跡，可能是因為這些文明的所在地已經沉入海底，依據目前已經發現的遺跡，可以合理推測幾個曾經存在的陸上古文明：

- 大西洋-亞特蘭提斯
- 太平洋-姆大陸
- 印度洋-雷姆利亞大陸

## 亞特蘭提斯（Atlantis）

與大西洋（Atlantic Ocean）是否有關？

## 姆大陸（Mu continent）

巽他古陸?

## 雷姆利亞大陸（Lemuria）

# 歐帕茲

- 獅身人面像（Sphinx）
- 羽蛇神（Quetzalcoatl）
- 三星堆突目面具
- 亞利桑那恐龍壁畫
- 巨人
    - 奧爾梅克巨石人頭像
    - 南非巨人腳印
    - 卡迪夫巨人化石（Cardiff Giant，證實捏造）
    - 阿傑爾高原岩畫–白色巨人

        [公認最有可能是「外星人派來考察地球的白色巨人」](https://kknews.cc/zh-tw/news/29bg34z.html)

- 俄羅斯長頭人

    [俄羅斯挖到外星人蛋型頭骨？專家曝光驚人發現](https://www.chinatimes.com/hottopic/20190125001189-260809?chdtv)

- [遮光器土偶](https://zh.wikipedia.org/wiki/%E5%9C%9F%E5%81%B6)
- 知部善古墳外星人
- 福國沛洞窟內的有翼人
- 秘魯外星人

    [秘魯森林的巨頭木乃伊 不同於地球人類(圖)](https://kknews.cc/news/mj4689.html)

- 艾爾巴爾遺跡噴火怪物浮雕

## 技術類歐帕茲

- 安提基特拉機械
- 水晶骷髏（Hedges skull）
- [南非凹槽金屬球](https://zh.wikipedia.org/wiki/南非凹槽金属球)
- 遺留彈痕的原牛頭骨
- [巴格達電池](https://zh.wikipedia.org/wiki/巴格達電池)
- 鎂鋁合金製的牡鹿雕像
- [德里鐵柱](https://zh.wikipedia.org/wiki/德里鐵柱)
- 秘魯腦外科手術
  [古代印加文明的腦外科手術從何而來(圖)](https://m.renminbao.com/rmb/articles/2019/1/9/68527mb.html)
- 德州白堊紀地層發現的人造鐵錘

## 知識類歐帕茲

- 納斯卡線

# 超古代遺跡

## 地球上的超古代遺跡

- [復活節島摩艾石像（Moai）](https://zh.wikipedia.org/wiki/摩艾石像)
- [阿布辛貝神殿](https://zh.wikipedia.org/wiki/阿布辛拜勒神廟)
- [埃夫伯里石圈](https://zh.wikipedia.org/wiki/埃夫伯里)
- [巨石陣（Stonehenge）](https://zh.wikipedia.org/wiki/巨石阵)
- [卡奈克巨石林](https://zh.wikipedia.org/wiki/卡纳克巨石林)
- [紐格萊奇墓（Newgrange）](https://zh.wikipedia.org/wiki/纽格莱奇墓)
- [特奧蒂瓦坎（Teotihuacan）](https://zh.wikipedia.org/wiki/特奧蒂瓦坎)
- [克諾索斯宮殿（Κνωσός）](https://zh.wikipedia.org/wiki/克诺索斯)
- [加泰土丘](https://zh.wikipedia.org/wiki/加泰土丘)
- [蛇敦（Serpent Mound）](https://en.wikipedia.org/wiki/Serpent_Mound)
- [烏爾金字形神塔（ziggurat）](https://zh.wikipedia.org/wiki/金字形神塔)
- [佩特拉](https://zh.wikipedia.org/wiki/佩特拉)
- [奇琴伊察／契琴伊薩（chich'en itza'）](https://zh.wikipedia.org/wiki/奇琴伊察)
- [哥貝克力石陣（Göbekli Tepe）](https://zh.wikipedia.org/wiki/哥贝克力石阵)
- [葦嶽山](https://ja.wikipedia.org/wiki/葦嶽山)
- [出雲大社](https://zh.wikipedia.org/wiki/出雲大社)
- [石之寶殿／生石神社](https://ja.wikipedia.org/wiki/生石神社)
- [梅薩維德](https://zh.wikipedia.org/wiki/梅萨维德国家公园)
- [馬丘比丘](https://zh.wikipedia.org/wiki/马丘比丘)
- [蒂卡爾](https://zh.wikipedia.org/wiki/蒂卡尔)
- 恰奇羅／恰奇羅遺跡／十三塔
- [南馬都爾](https://zh.wikipedia.org/wiki/南馬都爾)
- [與那國島海底遺跡（Yonaguni Monument）](https://zh.wikipedia.org/wiki/與那國島海底地形)
- [秦始皇陵](https://zh.wikipedia.org/wiki/秦始皇陵)
- [皆神山](https://ja.wikipedia.org/wiki/皆神山)

## 宇宙中的超古代遺跡

- [火星人面岩](https://ja.wikipedia.org/wiki/火星の人面岩)
- 火星金字塔群
- 火星上的磐石
- 月球表面的城堡
- 月球表面的碎片
- [火衛一的磐石／火衛一獨石](https://zh.wikipedia.org/wiki/火卫一独石)
- 愛神星的長方體
- 金星金字塔
- 月球表面的大太空船

# 議題

## 人類曾與恐龍共存？

- [阿坎巴羅雕像](https://zh.wikipedia.org/wiki/阿坎巴羅雕像)

    測定年代為1939年，應屬偽作（測定年代與其他文章不一致?）

- 伊卡黑石（Ica Stones）

    已證實為騙局

- 恐龍時代的地層有人類腳印

    帕拉克斯川腳印化石
    推翻—[6500萬年前與恐龍同行的人類腳印？！令人嘆服的真相！](https://kknews.cc/zh-tw/science/megbl5p.html)
    [三葉蟲化石上竟有巨大「鞋印」，腦洞大開的解釋為何都不靠譜？](https://kknews.cc/zh-tw/science/lmr9e.html)
    格羅倫斯手指化石 -> [億年前人類手指化石證實：歷史非我們所想的](http://big5.zhengjian.org/node/234667)（無法證實為人類手指，有可能只是靈長類）

## 人類曾發生核戰？

## 真的遭遇大洪水了嗎？

各地的洪水傳說
- 《舊約聖經》〈諾亞的大洪水〉
- 希臘神話
- 印度教的聖經
- 阿茲特克神話
- 霍皮族的神話

## 世界七大奇蹟

- 金字塔（現在僅存的唯一奇蹟）
- 巴比倫空中花園
- 以弗所的阿耳忒彌斯神廟
- 奧林匹亞的宙斯神像
- 哈利卡那索斯的摩索拉斯王零廟
- 羅德島的太陽神銅像
- 亞歷山卓的大燈塔

## 地球空洞說

- 極地是前進地球內部的入口
- 沉睡於地底的烏托邦香巴拉

# 隨手筆記

- 移動迷宮、霍金大見解->會不會人類其實只是上帝的實驗品?
- [【结尾感动】为什么我们都爱玩模拟经营？【GAMKER九尾 No.02】](https://youtu.be/Sssl2uQkb8I)->人類是很渺小的
