


我最愛的 Ethereum 馬上就要 the Merge 啦。 🎉 proof-of-stake 即將到來！這個時間點不妨懷念一下 PoW。

PoW 想必大家都聽的多，但究竟他的原理是什麼？ 這篇短文就嘗試快速閒聊一下這個知識點。

PoW 即工作量證明，是一種由 BitCoin 開始採用的共識機制。用最簡單的語言描述，**就是一堆礦工利用自己的算力，嘗試用一種類似暴力破解的方式解決一個區塊鏈網路給出的數學問題，最快找到答案的礦工，贏得勝利，獲得新區塊打包權，取得獎勵**。

![](/image/blog/pow-mk.png)

再深入一點介紹，我們知道每一個 block 都有一堆交易信息，這堆交易資料會得出一個固定的 Hash A，這個固定 Hash A 再加上一個無意義 nonce ， 則可以再得到另外一個 Hash B， 

好，如果我說， 我需要計算得出 Hash B 的結果必須是 0000 四個零開頭的數字，換句話說就是要小過一個給定的值， 那麼因為  Hash A 已經固定，則必須透過不斷更改 nonce， 從而得到滿足要求的結果。這其實就是一個類似暴力運算過程，不斷循環遞歸 nonce 數值，得到不同的 Hash B，直至 Hash B 滿足網路給出的要求為止。 這裡所說的「網路給出的要求」也就是 「區塊難度」的概念。 這個 「區塊難度」，正如其名就是定義了這個數學問題的「難度」，難度越低，取得答案所需要的時間越短，需要的算力越低。說白了就是定義了為了找到正確的 Hash B，大約需要做出多少次 Hash 運算。用以太坊為例， 「區塊難度」會隨著上一個區塊的「解題時間」而動態變化，如果礦工得到結果太快，則難度會提升，反之難度則會下降。

其實大概已經解釋完了。。。 理論其實很簡單。

如果想要有一個更直觀的理解，誠意推薦大家看看[這個史詩級的 Video](https://www.youtube.com/watch?v=_160oMzblY8&t=2s&ab_channel=AndersBrownworth)。

若想再具體一點，用以太坊為例，目前採用的 mining 算法是 ETHASH，具體可以參考[官網的解釋](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining-algorithms/ethash/)。下圖是引用[ researchgate.net ](https://www.researchgate.net/figure/Flow-diagram-of-the-Ethash-algorithm-used-by-Ethereum-with-a-DAG-size-of-237-GB-of-late_fig2_350601431)上的圖表解釋 Ethash 的運算過程。

![](/image/blog/pow.png "Source: https://www.researchgate.net/figure/Flow-diagram-of-the-Ethash-algorithm-used-by-Ethereum-with-a-DAG-size-of-237-GB-of-late_fig2_350601431")









 🎉 喜迎 the Merge! PoW 聽的多，但究竟他的原理是什麼？ 這篇短文就嘗試快速閒聊一下這個知識點。

閒聊 PoW 共識原理


上文已經詳細講過可升級智能合約的原理，注意事項，以及使用 Transparent Proxy 製作一個 NFT 智能合約，本文就繼續講講 UUPS Proxy。

## Transparent Proxy 和 UUPS Proxy

Transparent Proxy 和 UUPS Proxy 其實究其根本實現的基礎都是一樣的， 都是使用 `delegatecall` 將邏輯剝離主合約。

```bash
User -- tx --> Proxy  ------> Implementation_v0
                     |
                      ------> Implementation_v1
                     |
                      ------> Implementation_v2
```

Transparent Proxy 是一個較早的 Proxy Pattern， 而 UUPS 則是較遲才推出的 Pattern，目前官方比較建議使用 UUPS 。 兩者最明顯的差異是升級邏輯放在哪裡。 

> While both of these share the same interface for upgrades, in UUPS proxies the upgrade is handled by the implementation, and can eventually be removed. Transparent proxies, on the other hand, include the upgrade and admin logic in the proxy itself. This means TransparentUpgradeableProxy is more expensive to deploy than what is possible with UUPS proxies.

從上面的官方描述可以得知，UUPS Proxy 的升級邏輯是由邏輯合約來執行，不像  Transparent Proxy，需要部署額外的 Admin 合約，以及升級的邏輯由 Proxy 合約來完成。 因此， UUPS Proxy 合約的部署成本會低於 Transparent Proxy，而且因為升級是由邏輯合約控制，我們甚至可以隨時終止合約的「可升級性」。


## 實戰

UUPS Proxy 可升級合約，和 Transparent Proxy 可升級合約在程式碼上其實沒有太大的不同，下面的例子我也是偷懶將上文的 Transparent Proxy 合約的實戰部分抄過來，稍作修改變為 UUPS Proxy 可升級合約 。

最明顯的不同是：
1. 邏輯合約需要繼承 OZ `UUPSUpgradeable` ；
2. 邏輯合約需要 Override `_authorizeUpgrade` function；

OZ `UUPSUpgradeable`提供了升級合約的必要邏輯， `_authorizeUpgrade` 則用於進行權限控制，會在執行 `upgradeTo` 和 `upgradeToAndCall`時被調用，用於指定誰可以進行合約升級操作。 如果未經授權的地址，這個 function 需要進行 revert。

廢話不多說，現在我們就來製作 UUPS 可升級 NFT 合約。

##### 建立工作資料夾，安裝 Hardhat

```bash
mkdir upgradable-demo-uups && cd upgradable-demo-uups
yarn init -y
yarn add dotenv hardhat
```

##### 安裝 OpenZeppelin Contracts 

```bash
yarn add @openzeppelin/contracts-upgradeable
```

##### 安裝並設定 Hardhat

```bash
yarn hardhat
```

然後根據提示選擇 `Create a basic sample project`, 之後全部選擇 Y 。 

完成後，安裝 `@openzeppelin/hardhat-upgrades` 

```bash
yarn add @openzeppelin/hardhat-upgrades
```

完成後，當前路徑會產生一個 `hardhat.config.js`  檔案， 打開這個檔案，在頂部加入如下 import 語句：

```js
// hardhat.config.js
require("@nomiclabs/hardhat-waffle");
require('@openzeppelin/hardhat-upgrades');
require('dotenv').config( { path: `.env.${process.env.NODE_ENV}` } )

```

##### 撰寫可升級 NFT 智能合約

準備工作完成，現在我們開始撰寫智能合約。

```bash
mkdir ./contracts && cd ./contracts
```

在 contracts 資料夾中我們建立一個智能合約 NFTUUPS.sol：

```js
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721EnumerableUpgradeable.sol";


contract FRANKNFTUUPS is Initializable, ERC721Upgradeable, ERC721EnumerableUpgradeable,  OwnableUpgradeable, UUPSUpgradeable {
    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }
    
    function initialize( string memory _name, string memory _symbol ) initializer public {
        __ERC721_init(_name, _symbol);
        __Ownable_init();
        __UUPSUpgradeable_init();
        __ERC721Enumerable_init();
    }

    function _baseURI() internal pure override returns (string memory) {
        return "ipfs://Qma2uFDzG1aWrHYrtpwiXdh7xqf7wpxdXJ6osJV6TyEydJ/";
    }

    // The following functions are overrides required by Solidity.

    function _beforeTokenTransfer(address from, address to, uint256 tokenId)
        internal
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
    {
        super._beforeTokenTransfer(from, to, tokenId);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }

    function _authorizeUpgrade(address newImplementation)
        internal
        onlyOwner
        override
    {}
}
```

#####  編譯智能合約：

```bash
% NODE_ENV=dev npx hardhat compile

Compiled 15 Solidity files successfully
```

##### 發佈智能合約

現在我們可以發佈智能合約到 Goerli 測試網路進行測試。 （當然，正常情況下我們要先進行 unit test，以及發佈在 local node 上進行測試，本文暫時省略 local 測試步驟）

在當前路徑下建立一個 `.env.dev` 檔案，並加入下面的內容：

```bash
RCP_URL=https://rinkeby.infura.io/v3/<你的ProjectID>
PRIVATE_KEY=<錢包 Private Key>
ETHERSCAN_API_KEY=<ethersscan 的 API key>
```

至此我們需要設定一些必要的參數，`RCP_URL` 是 RCP 的 URL， 我們這裡使用 alchemyapi，可以在  [infura.io](infura.io%20) 上免費註冊一個。`PRIVATE_KEY` 是用來發佈合約所使用錢包的私鑰， `ETHERSCAN_API_KEY` 則是為了在 etherscan 上驗證合約所需要的 API key，可以在 [etherscan](https://etherscan.io/myapikey) 上免費取得。

完成後，移步到 `hardhat.config.js` 檔案，加入網路設定：

```js
module.exports = {
  solidity: "0.8.4",
  networks: {
    goerli: {
      url: process.env.RCP_URL,
      chainId: 5,
      gas: 15000000,
      accounts: (process.env.PRIVATE_KEY || '').split(' ')
    },
  }
};
```

完成設定後，我們就可以準備發佈合約了。 在 `./script` 路徑下建立一個 `deploy-uups.js`

留意，相比 Transparent Proxy ， 我們在調用 `upgrades.deployProxy` 時需要附加一個參數`kind: 'uups'` 以作指定 UUPS Proxy 之用。

```js
const { ethers } = require("hardhat");
const { upgrades } = require("hardhat");

async function main() {

  const NFT = await ethers.getContractFactory("FRANKNFTUUPS")
  
  console.log("正在發佈 FRANKNFTUUPS ...")
  const proxy = await upgrades.deployProxy(NFT, ["FRANKNFTUUPS","FRANK"], { initializer: 'initialize', kind: 'uups' })
  
  console.log("Proxy 合約地址", proxy.address)
  console.log("等待兩個網路確認 ... ")
  const receipt = await proxy.deployTransaction.wait(2);
  console.log("邏輯合約地址 getImplementationAddress", await upgrades.erc1967.getImplementationAddress(proxy.address))
}

main().catch((error) => {
  console.error(error)
  process.exitCode = 1
})

```

完成後，便可以調用上面的 script 發佈我們的 NFT 智能合約了：

```bash
% NODE_ENV=dev yarn hardhat run scripts/deploy-uups.js --network goerli

正在發佈 FRANKNFTUUPS ...
Proxy 合約地址 xxxxx
等待兩個網路確認 ... 
邏輯合約地址 getImplementationAddress xxxxx
✨  Done in 33.51s.
```


##### 驗證智能合約

為了方便之後操作，下一步，我們在 etherscan 上驗證剛才發佈的邏輯合約：

```bash
yarn add @nomiclabs/hardhat-etherscan
```

在  `hardhat.config.js` 檔案，加入 etherscan 設定：

```js
module.exports = {
  solidity: "0.8.4",
  networks: {
    goerli: {
      url: process.env.RCP_URL,
      chainId: 5,
      gas: 15000000,
      accounts: (process.env.PRIVATE_KEY || '').split(' ')
    },
  },
  etherscan: {
    // Your API key for Etherscan
    // Obtain one at https://etherscan.io/
    apiKey: {
      goerli: '<你自己的 key>'
    }
   }
};

```

然後運行:

```bash
NODE_ENV=dev yarn hardhat verify <剛才上面一步顯示的邏輯合約地址> --network goerli

Nothing to compile
Successfully submitted source code for contract
contracts/NFT.sol:FRANKNFT at xxxxx
for verification on the block explorer. Waiting for verification result...

Successfully verified contract FRANKNFT on Etherscan.
https://goerli.etherscan.io/address/xxxxx#code
✨  Done in 34.51s.
```

完成後，來到 etherscan 上，就可以看到合約已經完成驗證了。 

接下來，我們在 etherscan 上找到剛才發佈的 Proxy 合約地址，在 「More Option」中驗證 Proxy，驗證完成後，會到 Proxy 合約，可以看到已經多出了「Read as Proxy」 和 「Write as Proxy」功能：

![](/image/blog/screen-20220612230136@2x.png)

至此，我們已經完成了第一個版本的 NFT 發佈和驗證。

##### 撰寫新版 NFT 智能合約

發佈合約後我們發現在 Version 1 的合約中忘記了加入 `mint` 功能。不急，現在我們加入 Version 2 的合約。

在 contracts 資料夾中我們建立一個智能合約 NFTUUPSV2.sol，加入 mint 的相關邏輯：

```js
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721EnumerableUpgradeable.sol";


contract FRANKNFTUUPSV2 is Initializable, ERC721Upgradeable, ERC721EnumerableUpgradeable,  OwnableUpgradeable, UUPSUpgradeable {
    
    uint256 counter;
    
    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }
    
    function initialize( string memory _name, string memory _symbol ) initializer public {
        __ERC721_init(_name, _symbol);
        __Ownable_init();
        __UUPSUpgradeable_init();
        __ERC721Enumerable_init();
    }

    function _baseURI() internal pure override returns (string memory) {
        return "ipfs://Qma2uFDzG1aWrHYrtpwiXdh7xqf7wpxdXJ6osJV6TyEydJ/";
    }

    function mint() external  {
        counter = counter + 1;
        _safeMint(_msgSender(), counter);
    }

    // The following functions are overrides required by Solidity.

    function _beforeTokenTransfer(address from, address to, uint256 tokenId)
        internal
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
    {
        super._beforeTokenTransfer(from, to, tokenId);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }

    function _authorizeUpgrade(address newImplementation)
        internal
        onlyOwner
        override
    {}
}

```

接著，在 ./script 中加入 `upgrade-uups.js`: 

```js
const { ethers } = require("hardhat");
const { upgrades } = require("hardhat");

const proxyAddress = '0xFC01Bd85cfe13AC20a84F81d6285CFb4212A6696'

async function main() {

  console.log("指定的 UUPS Proxy 合約地址", proxyAddress)

  const NFTV2 = await ethers.getContractFactory("FRANKNFTUUPSV2")
  console.log("升級合約進行中...")

  const proxy = await upgrades.upgradeProxy(proxyAddress, NFTV2)
  console.log("Proxy 合約地址", proxy.address)

  console.log("等待2個網路確認 ... ")
  const receipt = await proxy.deployTransaction.wait(2);

  console.log("邏輯合約地址 getImplementationAddress", await upgrades.erc1967.getImplementationAddress(proxy.address))

}

main().catch((error) => {
  console.error(error)
  process.exitCode = 1
})



```

執行升級：

```bash
% NODE_ENV=dev yarn hardhat run scripts/upgrade.js --network goerli
yarn run v1.22.4


Compiled 1 Solidity file successfully
指定的 UUPS Proxy 合約地址 XXX
升級合約進行中...
Proxy 合約地址 XXX
等待2個網路確認 ... 
邏輯合約地址 getImplementationAddress XXX

✨  Done in 57.30s.
```

驗證新版本合約：

```bash
NODE_ENV=dev yarn hardhat verify <剛才上面一步顯示的新邏輯合約地址> --network goerli
```

來到 etherscan，看到合約已經多了 mint 功能。


智能合約發佈到區塊鏈之後，原始碼無法再次進行更改，因此往往出現一種情況，就是智能合約發佈後，發現有 bug，或者需要加入其他功能時，則必須重新發佈新的合約，而且要將數據進行轉移，以及通知所有使用者使用新合約地址。這個過程非常麻煩。有沒有更好的方法？

NFT 可升級智能合約 UUPS



智能合約發佈到區塊鏈之後，原始碼無法再次進行更改，因此往往出現一種情況，就是智能合約發佈後，發現有 bug，或者需要加入其他功能時，則必須重新發佈新的合約，而且要將數據進行轉移，以及通知所有使用者使用新合約地址。這個過程非常麻煩。有沒有更好的方法？

答案是有的，Upgradable Contract 正式要解決這個問題。 Upgradable Contract  透過使用「代理 - 實現」 的模式，巧妙的做到了類似能夠更改合約內容的效果。

![](/image/blog/upgrade-237w2829.png)

之所以能夠實現「代理」效果，這就要說說 EVM `delegatecall`這個功能。 `delegatecall` 可以簡單理解為將對方的程式碼「copy & paste」到自己當下的運行環境中執行，因為只是「copy & paste」程式碼，因此所有智能合約的狀態(state)，都保留在調用`delegatecall`的合約中。因此，想要「升級合約」，只需要將`delegatecall`所指向的合約地址更改，即可做到宛如修改了合約內容一樣的效果。


## 使用 OpenZeppelin Upgradable Contract

強大的 OpenZeppelin 已經為我們準備好了所有可升級智能合約藍本。有兩種 Pattern 供我們選擇：
- Transparent Proxy Pattern
- UUPS Proxy (Universal Upgradeable Proxy Standard)

這兩種 Proxy Pattern，不同之處在於升級合約的邏輯放在哪裡，以及發佈所需要的 Gas 會有不同。詳細的比較，可以參考[官方具體的解釋](https://docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups)。

本文我們先來介紹 Transparent Proxy Pattern ， 這也是存在比較久的一種代理模式。

Transparent Proxy Pattern 的可升級合約，包括三個部分： 「代理合約」，「代理管理員合約 Proxy Admin」和「邏輯合約」。

![](/image/blog/upgrade-237w2829-1.png)

### 代理合約 Proxy Contract

顧名思義，代理合約就像現實生活中的代理一樣，「代為處理」業務邏輯。代理合約面向用戶，用戶直接和代理合約進行交互。 在收到交互請求後，代理合約會將請求透過 `delegatecall` 調用「邏輯實現合約」內的程式碼進行處理。因為使用 `delegatecall` 的關係，所有的業務數據，都依然保存在代理合約中，這包括智能合約的 state 以及合約內的財產。每次使用 `deployProxy` 指令發佈合約，都會產生一個新的代理合約。

舉例，在任何程式碼都不修改的情況下，進行兩次 `deployProxy` 後結果如下：

```bash
% yarn hardhat run scripts/deploy_proxy.js --network rinkeby

Deploying Box...
0xA2aE342f98B3f5052CBD5EA008c6d2DC79d5EAeD  代理合約
0x5794FD1d38e7F8CF573189C8c0b6F5EE9D126E77  邏輯實現合約
0x388A177C570CB0b3A68B30D90db5f31DA9bbb225  管理合約
✨  Done in 43.61s.


% yarn hardhat run scripts/deploy_proxy.js --network rinkeby

Deploying Box...
0x55D4526AABeE01a2C6140c4e101f47C6AC07369B  代理合約
0x5794FD1d38e7F8CF573189C8c0b6F5EE9D126E77  邏輯實現合約
0x388A177C570CB0b3A68B30D90db5f31DA9bbb225  管理合約
✨  Done in 30.55s.
```

可以看到兩次發佈，只有代理合約被重新發佈了，而邏輯實現合約和管理合約都沒有改變。

### 代理管理員合約 Proxy Admin 

Proxy Admin 合約是作為所有你所發佈的「代理合約」的管理員合所有者。Proxy Admin 合約可以對指定代理合約進行邏輯升級。值得留意的是，**每個地址在每個網路上只會發佈一次 Proxy Admin 合約**，Proxy Admin 合約的所有權可以透過調用 `transferOwnership` 來轉讓。

> What is a proxy admin?
> A ProxyAdmin is a contract that acts as the owner of all your proxies. Only one per network gets deployed. When you start your project, the ProxyAdmin is owned by the deployer address, but you can transfer ownership of it by calling transferOwnership.

### 邏輯實現合約 Implementation Contract 

和上面的代理合約對應，邏輯實現合約內包含真正的合約業務邏輯，被代理合約透過`delegatecall` 調用。**邏輯實現合約可以發佈無數新版本**，這也是我們能修改合約內容，升級合約的根源所在。但無論有多少個邏輯實現合約，同一時間代理合約只會指向一個邏輯實現合約。

```bash
User ---- tx ---> Proxy ----------> Implementation_v0
                     |
                      ------------> Implementation_v1
                     |
                      ------------> Implementation_v2
```


## 注意事項

使用 Transparent Proxy Pattern  的可升級智能合約，因為技術原因，必須滿足以下這些要求：

####  不能依賴 constructor 執行邏輯

可升級智能合約不會調用 constructor，因此寫在  constructor 內的邏輯將被忽略。

####  安全原因盡量不使用 delegatecall 和 selfdestruct 

在使用可升級的智能合約時，用戶其實是在和代理合約交互。所有數據亦都是保存在代理合約內。 因此，正常情況下用戶不會與底層邏輯實現合約交互。但當然，惡意或者好奇的朋友依然可以直接調直接向邏輯合約發送交易，但正如上面所說，我們所有數據都是保存在代理合約內，所以邏輯合約狀態改變一般不會影響代理合約的運作。

然而，如果對邏輯合約因為被惡意調用`selfdestruct` 而消失了，那就會有問題了。這會導致代理合約指向一個沒有任何程式碼的「空合約」，這將完全破壞合約運作，後果不堪設想。

同樣的，如果邏輯合約中使用了 `delegatecall`， 變相有可能可以做到同樣效果。如果合約可以透過某種方式 `delegatecall`一個包含自毀`selfdestruct`的惡意合約，那麼我們的邏輯合約也會被銷毀。 因此，合約中不使用 selfdestruct 或 delegatecall，才能確保合約安全。

####  不可使用 immutable variables

immutable variables 是 Solidity 0.6.5 後新引入的變數 modifier。 immutable variables 和 constant variables 都有類似的效果，保證該變數不可二次賦值。兩者的區別是，constant variables 的初始賦值是在智能合約編譯時已經完成，而immutable variables 則可以在 constructor 執行時進行賦值操作。

Upgradable contract 不支援 constructor， 因此如果 immutable variables 有在 constructor 中進行任何操作則會導致嚴重問題，所以，Upgradable contract 不可使用 immutable variables。

####  不可使用 external libraries

正因為可升級智能合約對於其邏輯合約有一些列的寫法要求，我們無法保證 external libaries 中是否有違反可升級智能合約要求的寫法而導致嚴重的安全或邏輯問題。基於這個原因，官方建議不要使用 external libraries。

####  不可刪除現有變數，不可更改現有變數的類型，排列次序，不可在現有變數前新加入其他變數，以及不可在有繼承關係的父合約中新加入任何新的變數

以上這些關於變數的要求，都和智能合約的底層數據存儲有關，詳細原因可以[參閱官方文檔](https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable)。

####  不可直接對非`constant` 的變數進行賦值

在定義變數的同時賦值，和在 constructor 中設定初始值效果一樣。上面已經一再強調，所有基於 constructor 而進行的操作都不受可升級智能合約支援。如果這樣寫，初始值不會被帶到代理合約中，變相會影響合約邏輯。

然而如果變數為 constant，則可以直接賦值，因為 constant 的賦值操作是在編譯 ( compile ) 時進行。

```js
contract MyContract {
	uint256 public initialVal = 16; // 不可
	uint256 public constant initialValC = 16; // constant 可以
}
```


## 實戰

上面說了很多理論，下面我們就手把手建立一個可升級的 NFT 智能合約。

確保電腦已經安裝 NodeJS ， yarn 等必備工具。

##### 建立工作資料夾，安裝 Hardhat

```bash
mkdir upgradable-demo && cd upgradable-demo
yarn init -y
yarn add hardhat
yarn add dotenv
```

##### 安裝 OpenZeppelin Contracts 

```bash
yarn add @openzeppelin/contracts-upgradeable
```

##### 安裝並設定 Hardhat

```bash
yarn hardhat
```

然後根據提示選擇 `Create a basic sample project`, 之後全部選擇 Y 。 

完成後，安裝 `@openzeppelin/hardhat-upgrades` 

```bash
yarn add @openzeppelin/hardhat-upgrades
```

完成後，當前路徑會產生一個 `hardhat.config.js`  檔案， 打開這個檔案，在頂部加入如下 import 語句：

```js
// hardhat.config.js
require("@nomiclabs/hardhat-waffle");
require('@openzeppelin/hardhat-upgrades');
require('dotenv').config( { path: `.env.${process.env.NODE_ENV}` } )

```

##### 撰寫可升級 NFT 智能合約

準備工作完成，現在我們開始撰寫智能合約。

```bash
mkdir ./contracts && cd ./contracts
```

在 contracts 資料夾中我們建立一個智能合約 NFT.sol：

```js
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721EnumerableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract FRANKNFT is Initializable, ERC721Upgradeable, ERC721EnumerableUpgradeable {
    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize( string memory _name, string memory _symbol ) initializer public {
        __ERC721_init(_name, _symbol);
        __ERC721Enumerable_init();
    }

    function _baseURI() internal pure override returns (string memory) {
        return "ipfs://Qma2uFDzG1aWrHYrtpwiXdh7xqf7wpxdXJ6osJV6TyEydJ/";
    }

    // The following functions are overrides required by Solidity.

    function _beforeTokenTransfer(address from, address to, uint256 tokenId)
        internal
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
    {
        super._beforeTokenTransfer(from, to, tokenId);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}
```

#####  編譯智能合約：

```bash
% NODE_ENV=dev npx hardhat compile

Compiled 15 Solidity files successfully
```

##### 發佈智能合約

現在我們可以發佈智能合約到 Goerli 測試網路進行測試。 （當然，正常情況下我們要先進行 unit test，以及發佈在 local node 上進行測試，本文暫時省略 local 測試步驟）

在當前路徑下建立一個 `.env.dev` 檔案，並加入下面的內容：

```bash
RCP_URL=https://rinkeby.infura.io/v3/<你的ProjectID>
PRIVATE_KEY=<錢包 Private Key>
ETHERSCAN_API_KEY=<ethersscan 的 API key>
```

至此我們需要設定一些必要的參數，`RCP_URL` 是 RCP 的 URL， 我們這裡使用 alchemyapi，可以在  [infura.io](infura.io%20) 上免費註冊一個。`PRIVATE_KEY` 是用來發佈合約所使用錢包的私鑰， `ETHERSCAN_API_KEY` 則是為了在 etherscan 上驗證合約所需要的 API key，可以在 [etherscan](https://etherscan.io/myapikey) 上免費取得。

完成後，移步到 `hardhat.config.js` 檔案，加入網路設定：

```js
module.exports = {
  solidity: "0.8.4",
  networks: {
    goerli: {
      url: process.env.RCP_URL,
      chainId: 5,
      gas: 15000000,
      accounts: (process.env.PRIVATE_KEY || '').split(' ')
    },
  }
};
```

完成設定後，我們就可以準備發佈合約了。 在 `./script` 路徑下建立一個 `deploy.js`

```js
// scripts/deploy.js

const { ethers } = require("hardhat");
const { upgrades } = require("hardhat");

async function main() {

  const NFT = await ethers.getContractFactory("FRANKNFT")
  
  console.log("正在發佈 FRANKNFT ...")
  const proxy = await upgrades.deployProxy(NFT, ["FRANKNFT","FRANK"], { initializer: 'initialize' })
  
  console.log("Proxy 合約地址", proxy.address)
  console.log("等待兩個網路確認 ... ")
  const receipt = await proxy.deployTransaction.wait(2);

  console.log("管理合約地址 getAdminAddress", await upgrades.erc1967.getAdminAddress(proxy.address))
  console.log("邏輯合約地址 getImplementationAddress", await upgrades.erc1967.getImplementationAddress(proxy.address))    
}

main().catch((error) => {
  console.error(error)
  process.exitCode = 1
})

```

完成後，便可以調用上面的 script 發佈我們的 NFT 智能合約了：

```bash
% NODE_ENV=dev yarn hardhat run scripts/deploy.js --network goerli

正在發佈 FRANKNFT ...
Proxy 合約地址 0xfA46A6Afd5a5925c1459Ee7D14fd680B022e234C
等待兩個網路確認 ... 
管理合約地址 getAdminAddress 0x97E276f42F587a6dFA8969845F0C83bFd649Add2
邏輯合約地址 getImplementationAddress 0xA8A837F1351FB8CA2961F8Fb952B49c940C0cF05
```


##### 驗證智能合約

為了方便之後操作，下一步，我們在 etherscan 上驗證剛才發佈的邏輯合約：

```bash
yarn add @nomiclabs/hardhat-etherscan
```

在  `hardhat.config.js` 檔案，加入 etherscan 設定：

```js
module.exports = {
  solidity: "0.8.4",
  networks: {
    goerli: {
      url: process.env.RCP_URL,
      chainId: 5,
      gas: 15000000,
      accounts: (process.env.PRIVATE_KEY || '').split(' ')
    },
  },
  etherscan: {
    // Your API key for Etherscan
    // Obtain one at https://etherscan.io/
    apiKey: {
      goerli: '<你自己的 key>'
    }
   }
};

```

然後運行:

```bash
NODE_ENV=dev yarn hardhat verify <剛才上面一步顯示的邏輯合約地址> --network goerli

Nothing to compile
Successfully submitted source code for contract
contracts/NFT.sol:FRANKNFT at 0xA8A837F1351FB8CA2961F8Fb952B49c940C0cF05
for verification on the block explorer. Waiting for verification result...

Successfully verified contract FRANKNFT on Etherscan.
https://goerli.etherscan.io/address/0xA8A837F1351FB8CA2961F8Fb952B49c940C0cF05#code
✨  Done in 34.51s.
```

完成後，來到 etherscan 上，就可以看到合約已經完成驗證了。 

接下來，我們在 etherscan 上找到剛才發佈的 Proxy 合約地址，在 「More Option」中驗證 Proxy：

![](/image/blog/screen-20220612222915@2x.png)

![](/image/blog/screen-20220612223210@2x.png)

驗證完成後，會到 Proxy 合約，可以看到已經多出了「Read as Proxy」 和 「Write as Proxy」功能：

![](/image/blog/screen-20220612230136@2x.png)

至此，我們已經完成了第一個版本的 NFT 發佈和驗證。

##### 撰寫新版 NFT 智能合約

發佈合約後我們發現在 Version 1 的合約中忘記了加入 `mint` 功能。不急，現在我們加入 Version 2 的合約。

在 contracts 資料夾中我們建立一個智能合約 NFTV2.sol，加入 mint 的相關邏輯：

```js
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721EnumerableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract FRANKNFTV2 is Initializable, ERC721Upgradeable, ERC721EnumerableUpgradeable {
    

    uint256 counter;

    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }
    
    function initialize( string memory _name, string memory _symbol ) initializer public {
        __ERC721_init(_name, _symbol);
        __ERC721Enumerable_init();
        counter = 0;
    }

    function _baseURI() internal pure override returns (string memory) {
        return "ipfs://Qma2uFDzG1aWrHYrtpwiXdh7xqf7wpxdXJ6osJV6TyEydJ/";
    }

    function mint() external  {
        counter = counter + 1;
        _safeMint(_msgSender(), counter);
    }



    // The following functions are overrides required by Solidity.

    function _beforeTokenTransfer(address from, address to, uint256 tokenId)
        internal
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
    {
        super._beforeTokenTransfer(from, to, tokenId);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}
```

接著，在 ./script 中加入 `upgrade.js`: 

```js
const { ethers } = require("hardhat");
const { upgrades } = require("hardhat");

const proxyAddress = '0xfA46A6Afd5a5925c1459Ee7D14fd680B022e234C'

async function main() {

  console.log("指定的Proxy 合約地址", proxyAddress)

  const NFTV2 = await ethers.getContractFactory("FRANKNFTV2")
  console.log("升級合約進行中...")

  const proxy = await upgrades.upgradeProxy(proxyAddress, NFTV2)
  console.log("Proxy 合約地址", proxy.address)

  console.log("等待2個網路確認 ... ")
  const receipt = await proxy.deployTransaction.wait(2);
  
  console.log("管理合約地址 getAdminAddress", await upgrades.erc1967.getAdminAddress(proxy.address))  
  console.log("邏輯合約地址 getImplementationAddress", await upgrades.erc1967.getImplementationAddress(proxy.address))

}

main().catch((error) => {
  console.error(error)
  process.exitCode = 1
})
```

執行升級：

```bash
% NODE_ENV=dev yarn hardhat run scripts/upgrade.js --network goerli
yarn run v1.22.4


指定的Proxy 合約地址 0xfA46A6Afd5a5925c1459Ee7D14fd680B022e234C
升級合約進行中...
Proxy 合約地址 0xfA46A6Afd5a5925c1459Ee7D14fd680B022e234C
等待2個網路確認 ... 
管理合約地址 getAdminAddress 0x97E276f42F587a6dFA8969845F0C83bFd649Add2
邏輯合約地址 getImplementationAddress 0xFc069d144840644c666f912b5b892aB1Afba59b8

✨  Done in 66.63s.
```

可以看到，升級完成後，**管理合約地址** 和  **Proxy 合約地址**都沒有改變，而邏輯合約地址則改變為最新的合約地址。

驗證新版本合約：

```bash
NODE_ENV=dev yarn hardhat verify <剛才上面一步顯示的新邏輯合約地址> --network goerli
```

來到 etherscan，看到合約已經多了 mint 功能。

![](/image/blog/screen-20220612230706@2x.png)

調用該功能後，我們成功 mint 到了 NFT。 可喜可賀。

![](/image/blog/screen-20220612231102@2x.png)

有興趣的讀者可以[去 etherscan 上了解詳情](https://goerli.etherscan.io/token/0xfa46a6afd5a5925c1459ee7d14fd680b022e234c#readProxyContract)。


NFT 可升級智能合約



我們現在已經能夠製作具有白名單功能的 NFT，但現今市場上的 NFT 多數都還會加入盲盒功能。這篇文章就來討論一下如何製作盲盒模式的 NFT 

## 設定CandyMachine以支持盲盒模式

前文說到，Candy Machine 有一個[核心的設定文件](https://docs.metaplex.com/candy-machine-v2/configuration) `config.js` ，裡面設定了所有 Candy Machine 的重要參數，參考之前的範例：

```js
{
    "price": 0.3, 
    "number": 10, 
    "gatekeeper": null,
    "solTreasuryAccount": "DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb", 
    "splTokenAccount": null,
    "splToken": null,
    "goLiveDate": "20 Mar 2022 00:00:00 GMT",
    "endSettings": null,
    "hiddenSettings": null,
    "whitelistMintSettings": null,
    "storage": "arweave-sol",
    "ipfsInfuraProjectId": null,
    "ipfsInfuraSecret": null,
    "awsS3Bucket": null,
    "noRetainAuthority": false,
    "noMutable": false
}  
```

留意裡面的 `hiddenSettings`  ，這個設定便是盲盒的關鍵。 `hiddenSettings` 允許我們將所有 NFT 的 metadata 都指向同一個地址，也就是 `hiddenSettings` 中設定的地址， 一般這個地址可以用來顯示沒有開啟盲盒時的圖案。同時，設定了  `hiddenSettings`  後，Candy Machine 也不需要在上載的過程中事先準備好相應的圖檔。以下是 `hiddenSettings` 的設定舉例，所有 NFT 的 metadata 都會被指向到相同的地址。

```js
"hiddenSettings": {
        "name":"Mystery Box NFT ",
        "uri":"https://ipfs.io/ipfs/QmNcfWgjJUBjyd2yN28XnnnfHYSQBzTo6f94iesN4Fp7Ux",
        "hash":"hashGWWsSgdqPMvmqYgTS78Mx2Bblind"
    },
```

留意，不知道是不是 Candy Machine 的 bug， 儘管設定了  `hiddenSettings`  後，Candy Machine 不會再上載相應的圖檔，但依然需要在 `asset` 資料夾中放入至少一個 json 和 image 檔案， （之後在 upload 的時候會 skip），否則在執行 upload 時會出現錯誤。 這可能是 Candy Machine 的 bug 之一。

設定好 `hiddenSettings`  之後的步驟和普通 NFT 一樣。可以參考前文進行操作。


## 開啟盲盒

開啟盲盒的原理和 ERC721 NFT 類似，都是更改 NFT 的 metadata 地址。 這裡我們需要用到另外一個工具： [Metaboss](https://metaboss.rs/) 。  Metaboss 是一個針對 Metaplex 的工具集，裡面集成了眾多實用的功能。

安裝 Metaboss： 可[參考官網的安裝步驟](https://metaboss.rs/)

```bash
bash <(curl -sSf https://raw.githubusercontent.com/samuelvanderwaal/metaboss/main/scripts/install.sh)
```

然後，要更改 metadata 地址，我們首先需要得到所有已鑄造出的 NFT Token Account:

```bash
metaboss snapshot mints -c 31JY8szaKFFh2JzjvFvXL5KWL6k9cRyNXgFTqJbxz4MD --v2
```

`-c` 後的地址為 Candy Machine 的 ID， 執行完成後會在當前路徑下產生一個 `xxx_mint_accounts.json` 的檔案，裡面會記錄所有 Mint Account 的地址。

```bash
["9mKUeXfPvCQJEKkrKEvjjm87ztUfGS9SE4FfKHKGfwp7","6DLUWuoLvNxuusy9ksRkKJNC5ZaFKdX7hMD4j1zksCW8","hqkD3qtJBsJM4AxAXsKSoYpHfbhWkzA3rz28vn8ojz5","Hmnb8kUfdF4eLTKFePgh6D7Tdj1k7pB9VPpALVFM5dP"]
```
 
然後，我們需要準備好每個 NFT 對應的新 URI , 格式如下：

`update.json`

```js

[
  {
    "mint_account": "9mKUeXfPvCQJEKkrKEvjjm87ztUfGS9SE4FfKHKGfwp7",
    "new_uri": "https://arweave.net/N36gZYJ6PEH8OE11i0MppIbPG4VXKV4iuQw1zaq3rls"
  },
  {
    "mint_account": "6DLUWuoLvNxuusy9ksRkKJNC5ZaFKdX7hMD4j1zksCW8",
    "new_uri": "https://arweave.net/FPGAv1XnyZidnqquOdEbSY6_ES735ckcDTdaAtI7GFw"
  },
  {
    "mint_account": "hqkD3qtJBsJM4AxAXsKSoYpHfbhWkzA3rz28vn8ojz5",
    "new_uri": "https://arweave.net/FPGAv1XnyZidnqquOdEbSY6_ES735ckcDTdaAtI7GFw"
  },
  {
    "mint_account": "Hmnb8kUfdF4eLTKFePgh6D7Tdj1k7pB9VPpALVFM5dP",
    "new_uri": "https://arweave.net/FPGAv1XnyZidnqquOdEbSY6_ES735ckcDTdaAtI7GFw"
  }
]
```

接著就可以執行 update 

```bash
metaboss update uri-all  --keypair ~/.config/solana/xxx.json   --json-file ./update.json
```

完成後，所有 NFT 的 metadata 就成功更新完成。盲盒開啟了。


我們現在已經能夠製作具有白名單功能的 NFT，但現今市場上的 NFT 多數都還會加入盲盒功能。這篇文章就來討論一下如何製作盲盒模式的 NFT 。

Solana NFT 開發第五話 盲盒模式


Solana Candy Machine 的白名單模式，相比 EVM 生態中的白名單略顯奇怪。至少我第一次接觸到的感覺是這樣。

Solana Candy Machine 的白名單，是透過發放給白名單用戶一個特殊的 SPL Token，藉此作為鑄造 NFT 的「許可證」。擁有這個 SPL Token 的用戶，則可以在白名單階段使用 SPL Token 來鑄造 NFT。

因此，使用白名單的大致步驟如下：

- 建立白名單 SPL Token 
- 將白名單 SPL Token 發放給指定用戶
- 設定並更新 Candy Machine 使用白名單功能
- 白名單用戶使用  SPL Token 鑄造 NFT

## 建立白名單 SPL Token

為了方便識別，我們採用一個新的 Key Pair 來建立白名單 SPL Token：

```bash
solana-keygen grind --starts-with WLT:1

Searching with 8 threads for:
	1 pubkey that starts with 'WLT' and ends with ''
Wrote keypair to WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy.json
```

然後使用這個 WLT 字頭的 Key Pair 來建立 SPL Token:

```bash
spl-token create-token --decimals 0 --url devnet WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy.json

Creating token WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy

Signature: 3F274okGHftmYXAjPQBVDc9REkYxmn9mbkTBsrFqTAKKKiVWp1csfefF32SsQB3cTGLqSwkVyMs9ZRmSqVAKh1ze
```

建立 SPL Token 後，接著建立 Token Account:

```bash
spl-token create-account WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy --url devnet
Creating account 827kMvguv5zoSYU8xokyzWdmuvbgBZWR2hJKxzYeBKiE

Signature: 2a29jLdEaPmNVBemK9Ty91LxFrLiJyWKenbTCG3oLevLToj7pXcgxyrTeQ27D3TArLig6vPQ6YZEmC9kbcQ4DXGt
```

到這裡先暫停一下，不知道你會不會和我當初一樣有些困惑，create-token 在做什麼？ Token Account 又是什麼？ 如果有，不妨往下看，若是沒有興趣，可以跳過。

在 Solana 的世界中，智能合約 ( Programs ) 不能儲存數據。所有鏈上數據，都是存儲在一個個 「Account」 中。

![](/image/blog/solana-exp-2.png)

我們使用 `create-token` 指令，就是和現有的 `token program` 交互，建立了一個新的 Mint Account。 這個 Mint Account 中記錄了這個 SPL Token 的基本資料，類如誰能夠鑄造這個Token，誰能夠凍結這個 Token，總共有多少供應量， Token 有多少數位等資料。 Mint Account 僅僅記錄這個 SPL Token 本身的資料， 但不包含「賬本」，即不包含誰擁有多少 Token 這個資料。

Token Account， 則是上面 SPL Token 的「賬本」， 記錄著：
- Token Account 的擁有者是陳大文
- 陳大文 擁有100個 Token
- 陳大文 授權 陳小文 可以使用陳大文的 16 個 Token

每一個 SPL Token， 都對應著千千萬萬個 Token Account，我們可以在 solscan 中輸入 Mint Account 的地址來查看對應的 Token Account。

![](/image/blog/screen-20220607123921.png)

好，廢話說完，明白了 Token Account 是什麼之後，我們就要鑄造一些 SPL Token 以做白名單之用。 透過 `spl-token mint` 指令，即可鑄造 SPL Token:

```bash
spl-token mint WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy 100 --url devnet 

Minting 100 tokens
  Token: WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy
  Recipient: 827kMvguv5zoSYU8xokyzWdmuvbgBZWR2hJKxzYeBKiE

Signature: 4pruix4WgwCWwZsWAgEHbA55TpRcEa2U1v8Pih6nXnSEWbwRABanWCGANqcreSZaLyTht6kWuM9m5rQzH8y5hLPe
```

完成後，檢查餘額：

```bash
spl-token accounts --url devnet

Token                                         Balance
---------------------------------------------------------------
WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy   100
```


## 給白名單用戶分發 SPL Token

### 透過 Transfer 處理

分發 Token， 可以透過普通的 Token Transfer 方式處理： 

```bash
spl-token transfer <TOKEN_ADDRESS> <TOKEN_AMOUNT> <RECIPIENT_ADDRESS or RECIPIENT_TOKEN_ACCOUNT_ADDRESS> --config <PATH>

spl-token transfer WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy 1 4zHCvFuRfRwJSbLkBJWdwU2ceYmsQ5EZKk6EGZspRpzs --url devnet --fund-recipient
```

### 透過 [Gumdrop](https://docs.metaplex.com/airdrops/create-gumdrop) 處理

Gumdrop 的好處是，可以將 SPL Token 分發給大量的用戶，用戶可以前往指定網址自行領取 SPL Token，從而節省主動 Transfer 時的大量 gas 消耗。

#### 安裝 Gumdrop 

截止撰文當日，gumdrop 僅支援 Node `14.17.6` ，如果更高版本的 NodeJS 暫時未能支援。因此如果需要使用 gumdrop，需要安裝指定版本的 NodeJS。 否則會出現下面的錯誤：  

```bash
Error: Debug Failure. False expression: Non-string value passed to ts.resolveTypeReferenceDirective
```

確認 Node 版本正確，就可以繼續了：

```bash
git clone https://github.com/metaplex-foundation/gumdrop
cd gumdrop
yarn install --network-timeout 100000  <-- 這個可能需要一段時間
yarn bootstrap
```

安裝完成後，我們需要準備白名單地址列表檔案。 建立一個 `whitelist.json` 檔案，內容如下：

```bash
[
  {
    "handle": "<USER WALLET>",
    "amount": 1
  },
  {
    "handle": "<USER WALLET>",
    "amount": 2
  },
]
```

然後，我們要選擇一個初始錢包，並轉入一定量的白名單 SPL Token：

```bash
spl-token transfer WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy 100 DEMgMtEAA1spKrRVKurxRBFZptZu7AZjZ8J9QuThdR1c --url devnet --fund-recipient
```

然後，就可以建立 Gumdrop 了：

```bash
ts-node ~/gumdrop/packages/cli/src/gumdrop-cli.ts create \
  --env "devnet" \
  --keypair "/Path/To/DEMgMtEAA1spKrRVKurxRBFZptZu7AZjZ8J9QuThdR1c.json" \
  --rpc-url "https://api.devnet.solana.com" \
  --claim-integration "transfer" \
  --transfer-mint "WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy" \
  --distribution-method "wallets" \
  --otp-auth "disable" \
  --distribution-list "/Path/to/whitelist.json"
```

其中，`--keypair` 是上面已經被轉入 SPL Token 的錢包 Key Pair ， `--transfer-mint` 則是 SPL Token 的 Mint Account， 留意所有路徑都需要使用絕對路徑。

完成後會在當前路徑產生一個 `.log`  資料夾，裡面會找到一個 `urls.json` ，在裡面會見到不同地址對應的 URL， 打開這個 URL，用戶即可以連接錢包後按「Claim」取得 白名單 SPL Token。

![](/image/blog/screen-20220607180820@2x.png) 


## Candy Machine 白名單設定

完成上面的步驟之後，最後也是最重要的一步，我們需要更改 Candy Machine 的設定，以便讓 Candy Machine 支援白名單功能。

打開 Candy Machine 的設定檔案，在 `whitelistMintSettings` 中加入如下設定：

```bash
"whitelistMintSettings": {
    "mode" : { "burnEveryTime": true }, --> 指定每次使用後會是否銷毀 Token
    "mint" : "WLTTJqBDVuWJRtpR9FnLmHV5jhBLGANA9zThoZLNVYy",  --> 白名單 Token 地址
    "presale" : true, --> 是否開啟允許白名單用戶在公開發售之前鑄造 
    "discountPrice" : 0.123 --> 設定不同的 Mint 價格
}
```

完成後，我們需要更新 Candy Machine 設定：

```bash
ts-node ~/metaplex/js/packages/cli/src/candy-machine-v2-cli.ts update_candy_machine -e devnet -k ~/.config/solana/DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb.json -cp config.json

wallet public key: DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb
update_candy_machine finished 21HHtsq5gcSDrzMXT8KQGc29NdfhRBJZZ51zGoEL7s6YkQ1WaV4tmiGzHcA9hPKRuchuQVX4F6o7xoowCCJQhvza
```

更新後可以看到，只有擁有白名單 Token 的錢包可以鑄造，而沒有白名單 Token 的錢包則無法鑄造。

![](/image/blog/screen-20220608171727.png) 

另外，鑄造時也可以見到，除了要消耗 SOL 之外，也需要消耗白名單 Token。

![](/image/blog/screen-20220608172217.png) 

至此，我們就完成了具有白名單功能的 NFT。 掌聲鼓勵！下一篇文章，將介紹另一個進階功能 - 盲盒模式。




Solana Candy Machine 的白名單模式，相比 EVM 生態中的白名單略顯奇怪。至少我第一次接觸到的感覺是這樣。這篇文章我們就來實現白名單功能。

Solana NFT 開發第四話 白名單


<Link href="/blog/solana-nft-2-candy-machine">上一篇</Link>文章我們已經完成了 Solana Candy Machine 的設定和上載 assets，並且已經可以用 Command Line 鑄造 NFT。 但距離一個能夠讓別人前往夠買的 NFT 項目專案還差了一步，那就是一個友好的前端界面，本文我們就來解決這個問題。

可喜的是，metaplex 已經包含了一個 UI 可供使用，而且開源社區亦有很多 UI 前端界面，可以直接拿來使用。只需要簡單的設定即可。

本文中，我們使用 [candy-machine-v2-responsive-ui](https://github.com/Fulgurus/candy-machine-v2-responsive-ui) 這個開源 UI。

```bash
git clone https://github.com/Fulgurus/candy-machine-v2-responsive-ui.git

cd candy-machine-v2-responsive-ui
```

在資料夾中我們看到有 `.env.example` 檔案，將其重命名為 `.env` 並打開他。

```bash
mv .env.example .env

vi .env
```

我們需要修改 `.env` 中的 `REACT_APP_CANDY_MACHINE_ID`的設定， 改為我們自己的 Candy Machine ID。

```bash
REACT_APP_CANDY_MACHINE_ID=   <-- 改為我們自己的 Candy Machine ID
REACT_APP_SOLANA_NETWORK=devnet   <-- 指定測試網路
REACT_APP_SOLANA_RPC_HOST=https://api.devnet.solana.com <- 測試網路RPC


# ADDITIONAL PARAMS TO SET IF USING SPL-TOKEN AS MINTING CURRENCY ONLY :
# Spl-Token symbol to display next the price
#REACT_APP_SPL_TOKEN_TO_MINT_NAME=

# Spl-token decimals place defined on creation (default is 9)
#REACT_APP_SPL_TOKEN_TO_MINT_DECIMALS=

# To avoid harmless compilation warnings generating a build error, keep CI set to false
CI=false
```

修改完成後保存即可。

接下來我們可以運行 UI 試試看。

```bash
yarn install
yarn start
```

啟動後，訪問 [http://localhost:3000/ ](http://localhost:3000/) ，就可以看到 UI 已經完成了。
 
![](/image/blog/screen-20220607103650.png)

這個 UI 已經是一個能夠完全正常運作的界面，可以基於這個 UI 根據自己的需要進行修改。

至此，一個能夠正常運作的 Solana NFT 已經完成了。 接下來，我們將繼續探討 NFT 的進階功能。下一篇文章，將講講怎樣做到白名單鑄造。

這篇文章我們來快速建立一個 Minting Website。

Solana NFT 開發第三話 Mint UI


# 

<Link href="/blog/solana-nft-1-get-ready">上文</Link>中我們完成了製作 NFT 的前期開發環境準備，現在就可以準備發佈 NFT 了。

首先準備好一個空的資料夾：

```bash
mkdir nft-blank
cd nft-blank
```

如果你安裝了 VS Code， 此時可以使用 VS Code 打開這個資料夾：

```bash
code .
```

## 準備CandyMachine的設定文件

Candy Machine 有一個[核心的設定文件](https://docs.metaplex.com/candy-machine-v2/configuration) `config.js` ，裡面設定了所有 Candy Machine 的重要參數，可以參考下面這個範例：

```js
{
    "price": 0.3, 
    "number": 10, 
    "gatekeeper": null,
    "solTreasuryAccount": "DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb", 
    "splTokenAccount": null,
    "splToken": null,
    "goLiveDate": "20 Mar 2022 00:00:00 GMT",
    "endSettings": null,
    "hiddenSettings": null,
    "whitelistMintSettings": null,
    "storage": "arweave-sol",
    "ipfsInfuraProjectId": null,
    "ipfsInfuraSecret": null,
    "awsS3Bucket": null,
    "noRetainAuthority": false,
    "noMutable": false
}  
```

- `price`: SOL 售價
- `number`: 發行上限
- `gatekeeper`: 防止機器人的相關設定
- `solTreasuryAccount`: 收款地址
- `goLiveDate`: 指定開售日期
- `endSettings`: 指定結束銷售的條件
- `hiddenSettings`: 如果希望所有 NFT metadata 都指向固定的 URI， 可以使用這個設定參數來控制
- `whitelistMintSettings`: 白名單的控制邏輯
- `storage`: 指定 NFT 存儲的空間
- `ipfsInfuraProjectId`: 如果使用 IPFS存儲，在這裡指定 infura 的 project id
- `ipfsInfuraSecret`: 同上，如果使用 IPFS存儲，在這裡指定 infura 的 secret 
- `noRetainAuthority`: 如果設定為 true，那每個 NFT 的`update authority` 將轉移給鑄造者。變相失去了 NFT 的控制權。絕大多數情況下要設定為 `false`
- `noMutable`: 指定 NFT 的metadata 是否可以被更改。

關於設定文件的詳細解釋，可以參考[官方資料](https://docs.metaplex.com/candy-machine-v2/configuration)。

首先我們在這篇文章中先完成一個最簡單的 NFT。之後的文章我們再逐步介紹盲盒，白名單，防止機器人等的進階功能。

## 準備 assets

在當前路徑下建立一個 asset 資料夾：

```bash
mkdir assets
```

這個資料夾中需要存放 NFT 的相關檔案， 格式是 `0.json` 和 `0.png` ，json 檔案是 NFT 的 metadata ， png 則是 NFT 的圖案。有多少個 NFT，就要準備多少對 json 和 png。 

Metadata 的格式如下：
```js
{
  "name": "Number #0001",
  "symbol": "NB",
  "description": "Collection of 10 numbers on the blockchain. This is the number 1/10.",
  "seller_fee_basis_points": 500,
  "image": "0.png",
  "attributes": [
    { "trait_type": "Layer-1", "value": "0" },
    { "trait_type": "Layer-2", "value": "0" },
    { "trait_type": "Layer-3", "value": "0" },
    { "trait_type": "Layer-4", "value": "1" }
  ],
  "properties": {
    "creators": [
      { "address": "N4f6zftYsuu4yT7icsjLwh4i6pB1zvvKbseHj2NmSQw", "share": 100 }
    ],
    "files": [{ "uri": "0.png", "type": "image/png" }]
  },
  "collection": { "name": "numbers", "family": "numbers" }
}
```

關於 metadata 中的參數解釋，可以參考[官方資料](https://docs.metaplex.com/programs/token-metadata/token-standard)。

官方提供了一個樣例 assets 方便讀者測試，可以[按此下載](https://docs.metaplex.com/assets/files/assets-934a7281da49092b2a477733d067d8a0.zip)。 

![](/image/blog/screen-20220606173236.png "assets 裡面的內容是這樣的結構")

## 驗證 assets

當我們準備好 assets 之後，最好進行進行一下驗證步驟，以免手殘打錯了資料。 我們可以使用 `verify_assets` 指令，輕鬆進行驗證。

```bash
ts-node ~/metaplex/js/packages/cli/src/candy-machine-v2-cli.ts verify_assets ./assets
```

如果出現 `Cannot find module` 等類似的錯誤，請確保你指定了正確的 metaplex 安裝路徑哦。  運行完成後會有如下輸出：

```bash
 ts-node ~/metaplex/js/packages/cli/src/candy-machine-v2-cli.ts verify_assets ./assets

Verifying token metadata for 100 (img+json) pairs
Checking manifest file: /Users/frank/solana/assets/0.json
Checking manifest file: /Users/frank/solana/assets/1.json
...
Checking manifest file: /Users/frank/solana/assets/17.json
Checking manifest file: /Users/frank/solana/assets/18.json
Checking manifest file: /Users/frank/solana/assets/19.json
ended at: Sun Jun 05 2022 13:47:08 GMT+0800 (Hong Kong Standard Time). time taken: 00:00:00
```

如果有驗證錯誤，控制台會有相應的錯誤原因，可以根據指示修改。

## 進一步驗證 assets 

運行完了上面的  `verify_assets` 指令，基本的格式錯誤已經檢測完畢，理論上已經可以繼續了。但因為這些 metadata json 對於 NFT 至關重要，出錯後不僅影響顯示，而且會影響出售的收益。所以我們在發佈前最好再次檢查 metadata 是否正確。

@levicook 在  [hackmd.io](hackmd.io) 上發佈了[一篇文章](https://hackmd.io/@levicook/HJcDneEWF)，裡面有一系列指令可以進一步檢測 metadata json，推薦大家前往一讀， 跟著文章中的步驟再檢測一次。

確認無誤後，便可準備將 assets 上載發佈了。

## 建立並上載Candy Machine

萬事俱備，只欠 upload。

現在可以使用如下指令上載我們的傑作了。

```bash
ts-node ~/metaplex/js/packages/cli/src/candy-machine-v2-cli.ts upload -e devnet -k ~/.config/solana/DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb.json -cp config.json ./assets

```

其中 `-k` 後的參數是指定使用的錢包，這個錢包的產生上一篇文章有提到過。 `-cp` 後的參數是指定設定檔案，就是本文頭部所述的那個。最後的 `./assets` 自然就是指定裝載 json 和圖像的資料夾，candy machine 會在這個步驟將資料夾內的 json 和圖片檔案上載到 arweave 中。

注意，這個過程中可能會出現錯誤，candy machine 允許我們「斷點續傳」，即遇到錯誤可以重新上載，程式會自動緊接上次繼續上載。

當上載完成後，控制台會顯示 candy machine 的  address 等重要資料：

```bash

wallet public key: DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb
(node:45002) ExperimentalWarning: buffer.Blob is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
WARNING: On Devnet, the arweave-sol storage option only stores your files for 1 week. Please upload via Mainnet Beta for your final collection.

Beginning the upload for 10 (img+json) pairs
started at: 1654522026597
initializing candy machine
Candy machine address:  31JY8szaKFFh2JzjvFvXL5KWL6k9cRyNXgFTqJbxz4MD
Collection metadata address:  52BntZ1rFWQ6XomG2u65rEL9chmijzsQDGPtFabGotRe
Collection metadata authority:  DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb
Collection master edition address:  2GihorhxXdagqex8wmWopnBg2ymdvgorFfGzMeBnw3AL
Collection mint address:  Ca6RmDVxmFn7TV2VHvrx3JotESrw3fomG7eYGAdjfY7P
Collection PDA address:  DpdSrm3wvBbSejc6c1VxRF3EUcQp2bWvEUq2LD4Y9Zu8
Collection authority record address:  EPNquPuJqtUvpLf4MUgPEdsXqopJDViHiMPrG2jgUid3
Collection:  {
  collectionMetadata: '52BntZ1rFWQ6XomG2u65rEL9chmijzsQDGPtFabGotRe',
  collectionPDA: 'DpdSrm3wvBbSejc6c1VxRF3EUcQp2bWvEUq2LD4Y9Zu8',
  txId: 'YB4ChhPTwRFkFNqGcABgJLa6LoRjhLnfa9yJbLdySUVK4tgG5WBvKe3Xi9qUso9u8KpXCtaiNHqZ6ruYWJGoArj'
}
initialized config for a candy machine with publickey: 31JY8szaKFFh2JzjvFvXL5KWL6k9cRyNXgFTqJbxz4MD
[0] out of [10] items have been uploaded
Starting upload for [10] items, format {"mediaExt":".png","index":"0"}
Saved bundle upload result to cache.
Computed Bundle range, including 10 file pair(s) totaling 0.218MB.
Processing file groups...
Progress: [████████████████████████████████████████] 100% | 10/10
Uploading bundle via Bundlr... in multiple transactions
0.00008592 SOL to upload 0.440MB with buffer. Sending fund txn...
Successfully funded Arweave Bundler, starting upload
Progress: [████████████████████████████████████████] 100% | 30/30
Bundle uploaded!
Saved bundle upload result to cache.
Upload done. Cleaning up...
Writing all indices in 1 transactions...
Progress: [████████████████████████████████████████] 100% | 1/1
Done. Successful = true.
ended at: 2022-06-06T13:27:51.177Z. time taken: 00:00:44
```

上面控制台列出的各種地址，都需要妥善保存起來，今後會用到。其中最重要的： 

```bash
Candy machine address:  31JY8szaKFFh2JzjvFvXL5KWL6k9cRyNXgFTqJbxz4MD
```

這個地址便是我們 candy machine 的地址了。

## 驗證上載的檔案

上一步上載完成後，我們可以進而進行驗證，確保上載的資料正確無誤。

留意上一步完成後，在當前目錄下會產生一個 `.cache` 資料夾，裡面會有一個 json 檔案，`<網路名稱>-temp.json` ，裡面記錄了 candy machine 的相關資料。這個 json 檔案中我們要找到 `cacheName` 部分，這個在下面的驗證環節需要用到。

得到 `cacheName` 之後，就可以執行驗證：

```bash
ts-node ~/metaplex/js/packages/cli/src/candy-machine-v2-cli.ts verify_upload \
    -e devnet \
    -k ~/.config/solana/DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb.json \
    -c temp
```

上面的 `-c` 後面的參數就是上面提到的 `cacheName` 哦。

```bash
ts-node ~/metaplex/js/packages/cli/src/candy-machine-v2-cli.ts verify_upload \
    -e devnet \
    -k ~/.config/solana/DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb.json \
    -c temp
wallet public key: DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb
uploaded (10) out of (10)
ready to deploy!
```

驗證成功喇！

## Mint NFT

至此，我們的 candy machine 已經接近完成了。現在可以透過 `mint_one_token` 指令來鑄造 NFT 喇：

```bash
ts-node ~/metaplex/js/packages/cli/src/candy-machine-v2-cli.ts mint_one_token \
    -e devnet \
    -k ~/.config/solana/DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb.json \
    -c temp


wallet public key: DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb
(node:59487) ExperimentalWarning: buffer.Blob is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
Transaction size estimate:  1074
mint_one_token finished 3gz8h53yYt6vbZurEkcbUGmwVE2GM7aYq1yM8Nn861M8w7Hg3Wrbqv6xnzGL4G9RDYTmQ5MtdA3YskvyHsCsgAvr
```

可以看到我們已經成功鑄造了一個 NFT 。在 solscan 上輸入上面的 trx hash， 在 `Token Balance Change` 中就可以看到喇。

![](/image/blog/screen-20220606221134.gif)

在 Phantom 錢包中也可以看到哦！

![](/image/blog/screen-20220606221940@2x.png)

這裡有個小插曲，我們看到在 Phantom Wallet 中顯示的 NFT 的系列名稱為 Collection NFT，而不是我們 Meta Data 中指定的名稱，這個是怎麼回事呢？ 大家不妨自己先研究一下，之後的文章會講到。 

<Link href="/blog/solana-nft-3-candy-machine-ui">下一篇文章</Link>，我們將會快速搭建一個 Minting Website，來和我們的 Candy Machine 交互。



上文中我們完成了製作 NFT 的前期開發環境準備，現在就可以準備發佈 NFT 了。

Solana NFT 開發第二話 製作並發佈 NFT



接下來的一系列文章，將說說怎樣在 Solana 上發佈 NFT。

首先，在 Solana 上發佈 NFT，相對比 Ethereum 上發佈 NFT 要來的簡單些。因為全過程可以完全不需要撰寫任何智能合約，透過一系列指令 (Command Line) ，就可以完成發佈過程。

開始前先說說簡單的 Solana NFT 背景。 在 Solana 的世界似乎並沒有一個類似 ERC721 這樣公認的標準， 而 Metaplex 則是其中一個目前最多被採用的 NFT 實現。 Metaplex 本身可以理解為是制定了一系列標準的NFT 工具平台，其中包括了一系列的智能合約，工具，甚至 UI，透過這些工具，可以讓大家快速發佈自己的 NFT。 Candy Machine 則是 Metaplex 的一部分，其本質是一個 Solana 智能合約 ( 在 Solana 中稱為 Program )，保證了 NFT 整個挖掘/出售過程能夠順利進行。而 Candy Machine CLI 則是 Metaplex 針對 Candy Machine NFT 推出的工具程式，透過幾行指令，即可完成 NFT 的發佈。

> The Candy Machine program behaves like a real-world mechanical candy machine, where a person expects to put a coin into the machine and get one item out of it. The usual exceptions apply, for example and most significantly it won't take your coin if it's out of candy.

## 安裝必須的工具

首先確保已經安裝了最新的 Git 以及 NodeJS，這部分本文省略。

然後我們從 github 下載 metaplex 的完整開源項目：
```bash
git clone git@github.com:metaplex-foundation/metaplex.git \
  ~/metaplex
```

另外，我們還要安裝 ts-node:
```bash
npm install -g ts-node
```

安裝完成後，檢查 ts-node version:
```bash
ts-node --version
v10.4.0
```

安裝 [Solana CLI ](https://docs.solana.com/cli):
```bash
sh -c "$(curl -sSfL https://release.solana.com/v1.10.23/install)"
```

安裝完成後確保可以順利執行 solana 指令，如果出現 command not found 等問題，需要檢查 path 是否已經設定好。 可參考[官方安裝指引](https://docs.solana.com/cli/install-solana-cli-tools)處理。
```bash
solana --version
solana-cli 1.9.13 (src:devbuild; feat:1070292356)
```

總結一下：

```bash
$ git version
git version 2.30.0

$ node --version
v16.15.0

$ yarn --version
1.22.4

$ ts-node --version
v10.4.0

$ solana --version
solana-cli 1.9.13 (src:devbuild; feat:1070292356)
```

## 設定開發網路和錢包

為了方便開發，我們將預設網路設為 devnet：
```bash
solana config set --url https://api.devnet.solana.com
```

然後，我們建立開發錢包： 

為了方便區分，可以使用可選的 `--starts-with` 來建立一個指定開頭的錢包地址：

```bash
solana-keygen grind --starts-with DEV:1  <---- 這個指令可以產生一個以 "DEV" 開頭的地址，純粹方便標記用途，這段話不要 copy 哦

Searching with 8 threads for:
	1 pubkey that starts with 'DEV' and ends with ''
Searched 1000000 keypairs in 5s. 0 matches found.
Searched 2000000 keypairs in 10s. 0 matches found.
Wrote keypair to DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb.json
```

上述指令完成後會在當前路徑產生一個 `WLTQ2Q6hzrixss5nM6yXvZSAczcYWiwHyQYoeAscVH9.json` 裡面記錄了錢包的 private key 等重要資料，**請務必保存在安全位置**。

為方便開發，我們將這個 key file 搬到   `~/.config/solana/`  中
```bash
mv DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb.json   ~/.config/solana/
```

設定預設使用剛才產生的 key file：
```bash
solana config set -k ~/.config/solana/DEVKXTfCTqEzgyZ98GUvxdW5raRCfMKXm5KxzgyTjRqb.json
```

任何 solana on-chain 的操作都需要支付 Gas，所以我們需要先取得一些測試用的 Solana:
```bash
solana airdrop 2
```

上述指令可以申請 2 個 devnet 的 SOL ， 完成後檢查錢包餘額：
```bash
solana balance --url devnet   
```

至此，準備工作已經完成， 接下來<Link href="/blog/solana-nft-2-candy-machine">下一篇文章</Link>，我們可以準備開始製作 NFT 了。

Solana 上製作 NFT，相比 EVM 上的 NFT 大有不同，這一系列的 Solana 文章，將說說怎樣在 Solana 上發佈 NFT

Solana NFT 開發第一話 準備篇


這次我們來說說關於 MetaMask 的簽名問題。

所謂簽名，就是用你保存在 MetaMask 中的 Private Key 去對某樣東西做簽署，從而認證「你就是你」，這和我們日常生活中簽署文件類似。

MetaMask 在不消耗 Gas Fee 的情況下（即簽名資料不上鏈），也是可以進行簽名認證的，這種簽名多用於網站登入，或者 Gasless MetaTransaction 等。例如 OpenSea 登入，會要求你對一段信息進行簽名認證，簽名後會得到一個 Hash，伺服器則可以根據這個 Hash 和你的 Public Key 即錢包地址去驗證這段 hash 是否由你簽署，從而完成「你就是你」的身分驗證。

目前 MataMask 提供的簽名方法大致有三種，不同的方式有不同的應用場景。

![](/image/blog/n7xzx.png)

#### Personal Sign

Personal Sign 可以用於簽署一段 UTF-8 編碼的文字，因此可以清楚顯示被簽名的內容，這種方式常見於網站登入。

#### eth_sign

eth_sign _是早期的簽名方法，這個方法必須傳入一個 32 byte 的 message hash 以供簽名，message hash 可以是任何內容的 hash，因此，僅憑 message hash，簽名者不會知道自己正在簽署什麼內容，可能是一個交易資料，又或者其它任何內容，因此有潛在的被釣魚的風險，現在 MetaMask 已經開始對這類的簽名請求彈出紅色警告。

#### EIP712 Sign

EIP712 簽名是一種更安全的簽名標準，是根據 EIP712 標準為 signature 加入了如domain，contract address 等資訊，從而提高簽名的安全性。

EIP712 簽名標準規定了簽名數據的結構，也加入了對數據的作用域限制，如 domain，verify contract address 等。這個標準的好處是，簽名者可以清楚看到自己在簽署的內容，很大程度上降低被釣魚的風險。

ERC712 簽名經常會被用在執行 metatransaction 等合約執行中，例如 OpenSea NFT 上架，降低價格等過程都會出現 EIP712 簽名請求。

我為三種簽名都做了[一個示例](https://codesandbox.io/s/xpmnzc?file=/src/App.js)，有興趣的讀者可以[去看看原始碼](https://codesandbox.io/s/xpmnzc?file=/src/App.js)，親自嘗試一下。

![](/image/blog/trdyu.png)



MetaMask 都有哪幾種簽名方式？ 每種方式有什麼不同？為什麼有時候會出現紅色警告？這次我們來說說關於 MetaMask 的簽名問題。

MetaMask 簽名出現紅色警告？


最近 STEPN 是好火爆呀，本人也沒有忍住嘗試了一下，感覺不錯。這篇文章基於自己的實際經驗，以問答形式列出一些大家都會有的疑問，以及新手可能遇到的問題（也是我自己遇到的問題），希望能讓大家對這個遊戲有一個大概的了解。**我寫這篇文章，絕對不是要給讀者任何玩或不玩的建議**，而只是把我常聽到的問題總結寫下來，給大家一些資訊的呈現，方便大家自行評估， Do Your Own Research 決定要不要試試看。建議先看看本文最後一個部分：風險 中的描述。


### STEPN 是什麼

STEPN 是一個運動 App， 和我們平時使用的 Runkeeper， Keep 等運動 app 類似，能夠在跑步的時候記錄運動軌跡，速度等等參數。而它和其它 app 的不同之處在於，STEPN 是一個 Move to Earn 的運動 App，透過運動，玩家可以獲得「GST」代幣，這個代幣可以在兌換成真正的金錢。

### 需要預先投入嗎，要投入多少

要。App 可以免費使用，也可以用來記錄跑步，但是如果不投入的話沒有辦法獲得收益。

遊戲裡面有「鞋子」的東西需要購買，「鞋子」有不同的款式，適用不同的場景。按照撰文當天來看，目前最低價格的跑鞋需要 12.5 Sol，兌換成美金大約 1,200 美金左右。

### 能有多少收益

收益的多少和「鞋子」的品類，級別，屬性息息相關。無法一概而論。普通「慢跑鞋」，在升級到 6 級左右(一天一升級的話需要 5 天時間)，按照目前 GST 價格計算 （GST上面說過是遊戲中獎勵的代幣，好像其它遊戲中的寶石一樣），每天會有大約 30 美金的收入。

### 回本要多久

因為收益的多少和「鞋子」的品類，級別，屬性息息相關。「鞋子」級別越高，屬性越好，收益會越多。另外因為遊戲中獲得的是 GST 代幣，它的市場價格也會波動，所以這裡面有很多不穩定因素（風險）。我們假設 GST 價格維持在 4.5 USD 左右， 每天都出去跑步，回本大約一個多月左右。

不過要留意，所謂回本，是指獲得的收益能夠抵消購買「鞋子」的支出。因為「鞋子」本身可以隨時在市場中出售（官方會收取 6% 的交易手續費），而且目前來看「鞋子」的價格一直在上升。 再加上因為我們會升級自己的「鞋子」，而級別越高的「鞋子」，價格也會更高。所以如果你決定放棄遊戲離場，賣出「鞋子」的話，也是可以將之前的投入拿回來的（如果「鞋子」價格不下跌的話）。

### 如何開始

首先要下載 STEPN App，然後註冊一個賬戶。之後就是要有一個「邀請碼」來激活，這個下面會講。激活之後就可以使用 App 了。 

進入 App 之後需要初始化錢包，**這個步驟至關重要，涉及到錢包的密碼等安全操作，一定要謹慎操作**。這個網路上有很多教學我這裡就不再贅述。錢包設定好後就可以在商店內挑選一對心儀的「鞋子」，然後就可以出去跑步喇。

### 如何獲得 Activation Code

官方為了限制人數，引入了「激活碼」機制。老用戶每消耗 10 點能量會得到一個「激活碼」。可以向老用戶索取，或者到遊戲的官方 Discord， Tg 群組內征求。 大家都很樂意分享。

### 如何買鞋

在遊戲內有跑鞋商城，可以在商城內直接購買。

![](/image/blog/numqq.png)

### 鞋子有什麼分類，每種鞋子有什麼不同？

這個問題很重要。遊戲中的這個主要道具其實頗為複雜。

鞋子分為四種，**「步行鞋」**，**「慢跑鞋」**，**「快跑鞋」**，**「全能鞋」**。每種鞋子都有不同的適用速度，**超出或者低於適用速度，不能獲得遊戲代幣**。

顧名思義，「步行鞋」適合走路適用，適用速度 1-6 km/h。 「慢跑鞋」適合快步走或者慢跑，適用速度 4-10 km/h。 「快跑鞋」適合快跑，適用速度 8-20 km/h。而「全能鞋」則全場景通用，適用速度 1-20 km/h，當然他的價格會最貴。

![](/image/blog/9qmcu.png)

而同種類的鞋子也有稀有度之分，分別是**普通**，**罕見**，**稀有**，**史詩**，**傳奇**。稀有度和鞋子的初始能力點數，能量上限，寶石插槽稀有度的差異，「mint」出的鞋子稀有度，升級的點數等直接相關。

另外，每雙鞋都有**「效率」、「運氣」、「舒適」**與**「彈性」**這四種屬性，屬性的不同，也直接導致價格的不同。

#### Efficiency 效率
效率和 GST 收入直接相關，效率值越高，在相同能量下獲得的 GST 會越多。

#### Luck 運氣
這個屬性個人覺得初級玩家不需要太在意。運氣會影響神秘盒空投的頻率和內容。神秘盒會含有寶石等物件，可以用來升級鞋子的屬性。

#### Comfort 舒適
舒適屬性個人覺得初級玩家也不需要太在意，根據官方介紹這個屬性會與 GMT 代幣的收入有關。

#### Resilience彈性
這個屬性和鞋子修復直接相關。每次跑步後鞋子都會有一定的耗損，當耗損度超過鞋子的 50% 時會影響收益。因此，及時修復鞋子也非常重要。彈性屬性值越高，鞋子每次的耗損就越少，修復成本也越低。

![](/image/blog/h8f0f.png)

### 不想玩了，鞋子可以賣出嗎？

可以，在 App 內的商城可以直接賣出鞋子。

### 收益的途徑有哪些？

收益的話我自己覺得至少有三種方式。

**第一種當然是乖乖跑步**，獲得收益。大概的收益上面已經提到過。

**第二種方式是炒賣鞋子**，低買高賣，俗稱「flip」。根據我的觀察因為不斷有人入場，鞋子的價格目前呈現上升趨勢，就算買了鞋子什麼都不做，待其價格上升後再出售也會有收益。

**第三種方式是炒賣鞋子的加強版**，因為鞋子可以升級以增加技能點數，升級後的鞋子價格也會隨之上漲。看下面的例子，同是 Jogger，0級，6級，10級對應的價格分別是 13， 18， 24 Sol，可見如果將鞋子從 0 升到 6級再出售，獲得的差價已經去到 5 sol，即 500 USD。 而升級的成本，從 0 到 6 需要 26 GST，按照當前價格折算約 115 USD。 而這些 GST 完全可以靠跑步獲得，無需額外投入。

![](/image/blog/2k3nv.png)

**第四種方式是鞋子工廠**，因為兩對鞋子可以「mint」出一對新的鞋子，儘管 mint 鞋需要消耗大量 GST，但換算回來還是比直接購買要低很多。因此不斷「mint」新鞋再拿去市場出售也是一個好方法。

但是要留意每「mint」一次鞋，鞋子的「mint」數會增加 1 ，每一對鞋最多只能「mint」7 次，而且每次索要消耗的成本會顯著增加。

### 鞋子升級以及升級成本是多少？

鞋子升級需要花費 GST 和時間成本，具體可以參考下表。

![](/image/blog/z1ewe.png)

### 「能量」的概念

「能量」是遊戲中的一個重要數值。 「能量」的多少直接決定你有多少時間可以獲取收益。跑步的時候，每 1 分鐘會消耗 0.2 能量，也就是說每一個能量點數，可以有 5 分鐘的時間可以獲取收益。 **能量消耗殆盡後，不會獲得任何收益**。

按照香港時間，每天的 3 點，9 點，15 點，21 點會補充你所有能量的 25%，也就是說 24 小時後所有能量會加滿。

獲取更多能量可以靠買更多的鞋子來獲得，但鞋子數量和能量增長並不是線性關係。1 對鞋和 2 對鞋，能量數都是 2 點，3 對鞋能量數會增加到 4 點，再往上就要 9 對鞋，能量數會增加到 9 點。

![](/image/blog/5dfn7.png)


###  GST / GMT 有什麼分別

GST 是遊戲內無限發行的主要功能代幣，也是我們跑步後會收到的獎勵。 GST 類似普通遊戲中的寶石，可以用來升級鞋子，修復鞋子，加速升級， 「mint」新鞋子等操作。

GMT 是遊戲的治理代幣，有發行上限，按照概念理解會和遊戲的發展有關，例如可以參與投票等。 GMT 在某些高等級的操作也需要使用，例如高等級的寶石合成，高等級的升級等。

### GST 的消耗途徑

上面說過，GST 可以用來升級鞋子，修復鞋子，加速升級「mint」新鞋子等操作。

### 沒有鞋子怎麼辦

沒有鞋子依然可以使用 App 記錄運動，只是沒有收益。 日後遊戲亦會推出鞋子租賃的功能，租賃者和放租者共享收益。

### 鞋子產生鞋子

當鞋子升級到 5 級時會解鎖「mint」功能，可以使用兩對鞋子來產生一對新的鞋子。這個過程需要花費 GST 或者 GMT。 每對鞋子最多只能「mint」 7 次，而且隨著「mint」數的增加，所花費的成本會顯著增加。

兩對鞋子所產生的「後代」的稀有度，也和這兩對鞋子的稀有度直接相關。 
- 普通鞋和普通鞋配對，後代 100% 是普通鞋。 
- 普通鞋和罕見鞋配對，出現普通和罕見鞋的幾率大約各自50%，並有極少數 1% 的機會會出現稀有鞋。
- 其它稀有等級配對以此類推。

### 風險

（這裡的風險，我們排除一些極端情況，例如錢包被駭客入侵，跑步的時候不慎造成健康傷害等）

首先入場這個遊戲是需要投入的，而且還不少。

最壞的情況就是遊戲突然「跑路」，你的投入完全清零。

然後就是遊戲內代幣 GST 的價格大幅下降。這個隨著 GST 的產出增多，如果遊戲項目方沒有好的方式去消耗 GST，那麼這個情況有大概率會發生。結合之前 Axie Infinity 的經驗，類似的遊戲代幣 SLP 價格從高峰的 0.35 跌落到現在的 0.01 ，下跌了 35 倍。

![](/image/blog/uykcs.png)

而再看 STEPN GST 價格，由發行到現在接近 5 個月時間，價格暫時是波動上升中，但這個趨勢能維持多久實在不好說。最近這幾天 GST 的價格也有明顯的波動。

![](/image/blog/e5qrs.png)

對於 STEPN 的經濟模式，需要不斷有新用戶入場才能得以持續。一旦沒有了新用戶，鞋子的需求降低，直接會導致鞋子價格下降。但另一方面，隨著越多人加入， GST 的產出也會越快，GST 的價格亦會隨之下降。雖然相較 Axie Infinity， STEPN 中的 GST 多了很多消耗的方式，但消耗和產出能否平衡這個目前還不好說。


### 我自己的想法

目前來看我對這個遊戲的看法還是相當正面的。拋開每日的收益不說，僅僅是因為這個 App 提供了強大的動力促使我能夠堅持每天跑步，這個轉變對我來說已經彌足珍貴。我本來算是喜歡跑步，但遠沒有能夠達到每天跑的程度。跑步所帶來的的健康上的收穫，相比金錢上的收益來的更加珍貴。

至於投入的成本，目前的入場費大約一台 MacBook 的價格。但因為風險是可以預見的。最壞的情況不外乎全數歸零，這個要看自己是否能夠承受。

最後，嘗試任何新事物之前一定要做好功課，切忌盲目跟風。特別是自己不了解的範疇。參與這個遊戲，需要一定的區塊鏈知識，這個也不是每個人都適合的。**我寫這篇文章，絕對不是要給讀者任何玩或不玩的建議**，而只是把我常聽到的問題總結寫下來，給大家一些資訊的呈現，方便大家自行評估。











最近 STEPN 是好火爆呀，本人也沒有忍住入場嘗試了一下，感覺不錯。這篇文章基於自己的實際經驗，以問答形式列出一些大家都會有的疑問，以及新手可能遇到的問題（也是我自己遇到的問題），希望能讓大家對這個遊戲有一個大概的了解。

STEPN 邊跑邊賺 問與答



首先看看我做的[這個 demo](https://testnets.opensea.io/collection/onchainnft-demo): [https://testnets.opensea.io/collection/onchainnft-demo](https://testnets.opensea.io/collection/onchainnft-demo)

![](/image/blog/5qqss.png)

這些 NFT 的特別之處在於，每個 NFT 的圖案都不一樣（ ID 不一樣），所有 NFT 的資料都是保存在區塊鏈上，沒有用到任何的伺服器或者 IPFS。 

我在[製作 ERC721 智能合約那篇文章](https://www.frank.hk/blog/nft-smart-contract)中說過，NFT 之所以會顯示圖案，是因為根據 NFT 的標準，每一個 NFT 都有一個 json 格式的 metadata 與之對應， metadata 中有一個參數是指定 NFT 的圖案，所以只要訪問這個 NFT 的 metadata，然後再得到圖像地址，就可以顯示出 NFT 的圖案了。

![](/image/blog/oxypa.png)

一般的 NFT，metadata 和 NFT 的圖案都是保存在非區塊鏈上，例如伺服器，或者是去中心化的 IPFS。這樣做其中有一個問題就是有可能會導致資料遺失。中心化伺服器自然不用多說，而即便是 IPFS 也是不能保證資料永遠在線（如果對 IPFS 有興趣，可以參考我之前寫的 [IPFS 問與答](https://www.frank.hk/blog/ipfs-q-and-a)）。如果所有資料都保存在區塊鏈上，則能夠完美解決這個問題。但是，在區塊鏈上保存大量數據非常昂貴，所以想要這樣做，必須盡量減少儲存的數據量，那我們今天就來看看可以怎麼做。

首先我們不可能將所有 NFT 的圖案都「原封不動」的保存在區塊鏈，這樣成本太高。如果有辦法能「即時產生」圖案，則可以大大降低成本。這時我們想到了 SVG 圖案檔。SVG 的本質其實就是一段文字，因此我們可以根據一定的要求隨時「拼湊」出來。

查看 [OpenSea  metadata 的標準](https://docs.opensea.io/docs/metadata-standards)，除了 `image` 欄位，還有一個 `image_data` 可供使用，這個`image_data` 則為我們「即時產生」圖案提供了可能性。

![](/image/blog/gooaq.png)

既然 NFT 的圖案可以做到「即時產生」，那純文字的 NFT  metadata 更不在話下，我們也可以按照這個思路，讓 `tokenURI()` 直接返回 NFT 的 metadata JSON， 而不是一個 http 或 ipfs 連接。

好了廢話不多說我們看看程式怎麼寫吧。  

`tokenURI()`  我們做如下處理，拼湊出符合要求的 metadata JSON ，用 Base64 編碼之後直接返回。 注意對 `string` 進行拼接需要用到 `abi.encodePacked` ， Base64 編碼使用到一個公用 library，文後會給出源碼。 

```Solidity
function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721)
        returns (string memory)
    {
        require(
            _exists(tokenId),
            "ERC721Metadata: URI query for nonexistent token"
        );
        
        string memory json = Base64.encode(
            bytes(
                string(
                    abi.encodePacked(
                        '{"name": "On Chain NFT #',
                        uint2str(tokenId),
                        '",',
                        '"image_data": "',
                        onChainSVG.getSvgImage(tokenId),
                        '"',
                        "}"
                    )
                )
            )
        );
        return string(abi.encodePacked("data:application/json;base64,", json));
    }
```

留意到上面拼接 json 時有一句 `onChainSVG.getSvgImage(tokenId)`  這個 function 的作用是根據傳入的 tokenId ，即時「產生」一個 SVG 數據。**產生 SVG 的邏輯我們調用了另外一個智能合約進行處理，而不是寫在同一個智能合約中。 原因是根據 2016 年實施的 EIP-170 標準，每張智能合約的大小不能夠超過 24.576 kb。所以如果寫在同一張智能合約中會導致智能合約超出要求而無法發佈。**

合約部署後，調用 `tokenURI()` 我們會看到合約直接給出了 metadata 的完整 JSON (Base64 編碼)
 ![](/image/blog/iloveyou.png)

如果想測試一下的話，可以到 etherscan 上，連接錢包（Rinkeby 測試網路），調用 mint function mint 一個 NFT 給你自己哦。 

![](/image/blog/ikw6g.png) 



兩張智能合約的原始碼:<br/>
[https://gitlab.com/0x0016/smart-contract-demo/-/tree/main/contracts/nft](https://gitlab.com/0x0016/smart-contract-demo/-/tree/main/contracts/nft)

OpenSea:<br/>
[https://testnets.opensea.io/collection/onchainnft-demo](https://testnets.opensea.io/collection/onchainnft-demo?search%5BsortAscending%5D=true&search%5BsortBy%5D=CREATED_DATE)

EtherScan:<br/>
[https://rinkeby.etherscan.io/address/0x5b97a3663d6a9be5ef6a21fb2108b93f93f8b2e5#writeContract](https://rinkeby.etherscan.io/address/0x5b97a3663d6a9be5ef6a21fb2108b93f93f8b2e5#writeContract)


這篇文章探討下怎樣製作連圖案都完全保存在區塊鏈的 NFT，沒有伺服器，沒有 IPFS，一切 On Chain！

教你製作完全 On-Chain 的 NFT 



[Zombie Club NFT](https://zombieclub.io/) 最近可謂紅的不得了。這個有潮流明星余文樂站台的項目一開始就引人關注。技術上個人感覺項目的技術處理還是很不錯的，白名單，公售都基本順暢，對於其智能合約的處理網路上已經有了很多技術分析文，這裡就不贅述。 

寫這篇文章的初衷，是因為昨天晚上聽了他們團隊的一個技術 AMA，聽到了來自官方團隊對技術上的一些分析和解釋。兩個多小時的 AMA，在最後的聽眾問答環節被推上高潮， 過程有聽眾對於智能合約的處理發出了質疑，問答的重點是關於公售時期幾百筆 out of gas 的原因追問。官方也花了很長時間解釋。但坦白講對於官方的回答有些地方我也不是十分認同。我也多次想發言可惜一直沒有被選中（事實上只有三個人被選中發言）。 星期日沒什麼事那這裡我們就來聊一聊這個 out of gas 是怎麼個回事。

![](/image/blog/ieeh5.png)

在討論關鍵問題之前，首先我們要理解幾個概念， **Gas Limit**，** Max Priority Fee** 和  **Max Fee**。

![](/image/blog/fmkxf.png)

### Gas Limit 

Gas Limit 指的是你最多允許這個交易消耗**多少單位**的 Gas。 注意這裡指的是 Gas 單位，**不涉及到金錢**。用平民化的例子來說，比如我要從元朗開車到中環，Gas Limit  就是指我允許這個旅程最多消耗多少升汽油。一般而言，傳入相同參數的智能合約 function 調用，如果智能合約中沒有特別的邏輯(下面會講)，其消耗的 gas 應該基本固定，這也是 metamask 進行 gas 預估的原理。用上面汽車的例子，同一架汽車從元朗開車到中環，行駛相同的路徑，每次消耗的汽油應該基本固定。

### Max Priority Fee

首先有個 「Fee」 字的都是和錢相關的概念。這個數值和最後我們支付的 gas fee 息息相關。 Max Priority Fee 是 [EIP-1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) 升級後新出的概念。 原本劃一收費的 gas price 現在會分為兩個部分， 一個是 **Base Fee**（基礎費用），這個費用可以理解為海鮮價，整個以太坊網路會根據網路繁忙程度自動計算，不可更改， 每個區塊內的所有交易 Base Fee 都相同。另一個是 **Priority Fee**（礦工小費）， 這個數字用戶可以自行設定，直接支付給礦工作為小費。Priority Fee 設置越高，該筆交易則會擁有越高的優先級，更快完成。**這個 Priority Fee 也是在 NFT 限量搶購等需要「鬥快」的交易中充當重要角色的參數**。同樣用汽車的例子，Priority Fee 可以理解為，想象有一堆人在加油站等待加油出發，而加油站的汽油卻有限，你願意為每升汽油多花多少錢給小費，給的小費越多，你便可以越快的速度被服務，加滿油開始你的旅程。

### Max Fee

Max Fee 和Max Priority Fee 一樣，都是關於「錢」的概念。 Max Fee 的概念是指你願意為每一單位的 Gas 支付的最大費用。 **Max Fee 必須大於或者等於 Base Fee + Max Priority Fee** 。看到這裡，不知大家會不會有疑問， 為什麼會有 Max Fee 的存在？ 直接 Base Fee + Priority Fee 不就好了？ 其實仔細想想就會知道， Max Fee 的存在是為了保障我們對交易的費用控制， 上面說了 Base Fee 是會網路狀況變動的「海鮮價」，如果沒有 Max Fee 的控制則可能會導致當網路突然異常繁忙時的 Gas 失控。

對於 Max Fee 的估算，EIP-1559 也給出了建議：

```Solidity
Max Fee = (2 * Base Fee) + Max Priority Fee
```

之所以會乘 2 是為了防止 Base Fee 在下一個 Block 增加而導致費用不足而交易失敗， 根據EIP-1559 對於 Base Fee 的約定， Base Fee 乘 2  可以保證在連續 6 個滿載區塊的情況下你的交易都可以順利執行。**絕大多數情況下， 真正的 Gas 消耗要比 Max Fee 少。**

了解了上面的概念後，我們就可以聊聊 Zombie Club NFT 公售時的這個小插曲了。 公售開始時[有大量的 Trx 出現 out of gas 的錯誤](https://etherscan.io/tx/0x6e82115917a4450dd280dbb6e83111480762824adb57201868c3db1397b7157a)。所謂 out of gas，就是指整個交易已經用盡了 Gas Limit  中指定的上限，因此礦工會放棄執行餘下的工作，該筆交易會立即失敗，並且因為礦工已經耗費了算力，因此消耗掉的 Gas 不會退回（但是交易中夾帶的 ETH 會返還）。所以說，**即便你的 Priority Fee 給的再高， 但只要 Gas Limit 設置的不夠，則最終依然會失敗，而且損失的錢會比因為  Priority Fee 不夠而最後失敗的那些交易還要多很多**。就好像[這個交易](https://etherscan.io/tx/0xafa6f551a1ce1e939d914960791828b2e69c26135e2d634e8bfa54a2f439d7a6)，Priority 已經設置到驚人的 11,111 Gwei，可惜還是因為 Gas Limit 不夠，而導致最終失敗。

我們可以發現， 出現 out of gas 的錯誤，集中發生在 1440443， 1440444， 1440445 這幾個區塊，也就是公售剛開始的前後幾個區塊中。昨晚官方 AMA 中的解釋，這是因為 Metamask 錯誤的估算了 Gas Limit 導致，可能是 Metamask 版本太舊，可能是用了其它的錢包等原因導致。 


### Gas 估算

**好了，那問題來了。 MetaMask 是怎麼估算 Gas Limit 的呢？**

如果做過 ethereum 區塊鏈開發的人大概都知道， 在 web3 等常用的工具中都有 `estimateGas` 這個 function，estimateGas 估算 gas 用量的方法是使用完全相同的參數，模擬真實情況透過 RPC 調用智能合約的 function，然整個交易模擬執行一次，從而計算出整個調用所需要的 Gas 用量。這個模擬調用，不會提交到區塊鏈，因此不會真正被礦工記錄，不會真正消耗 gas，但這個模擬調用，卻能夠較為精準的估算 Gas 用量，也可以發現可能遇到的錯誤。這也是有時候我們會見到 MetaMask 告訴我們 「This trx is expected to fail」的原因。

**那為什麼 MetaMask 會估算錯誤呢？**

首先上面講到， MetaMask 對 gas 的估算是傳入相同的參數，模擬執行智能合約，從而得出 Gas 用量。因此，如果智能合約的處理不當，在傳入相同參數的情況下兩次執行會出現不同的程式邏輯，則會導致估算的結果和實際的 gas 用量不符的情況。

舉個例子，假如智能合約使用 block number 或者 block timestamp 來決定執行邏輯，例如，如果區塊時間 > 22:00:00 則進行 public mint， 如果區塊時間 < 22:00:00 則進行 whitelist mint， 這裡因為區塊時間是一個變量，即便傳入的參數一樣，因為區塊時間的不同，因此會導致智能合約運行的邏輯不一樣，因此導致所謂「Gas 估算錯誤」。

再比如，如果調用的 function 中含有 for loop， 即便傳入的參數一樣，但 for loop 因為某些原因提早或延遲終止，也會導致 Gas 的消耗出現明顯差異。

回到 Zombie Club 的 Case， AMA 中官方有說明，智能合約中的確運用了 Block Timestamp 來進行某些邏輯判斷，如果我沒有理解錯就是根據 Block Timestamp 來區分目前是白名單 mint 還是公售 mint。而公售 mint 因為某些原因需要記錄 signature 而導致消耗的 gas 比白名單要多。所以不難想象出現 「Gas 估算錯誤」的原因就是 MetaMask 估算時，因為 timestamp 的不同而用白名單 mint 的邏輯進行了估算，但實際執行時卻是使用了 public mint 的邏輯，因此導致實際 gas 消耗要比估算高。


### Zombie Club的做法有問題嗎

不能說有問題，但我覺得應該有更好的處理方式。

首先，官方說他們的前端沒有去建議 Gas Limit，而是將之交給用戶去設定。作為一個源碼沒有公開的智能合約，作為用戶其實是沒有可能能夠預測 gas 的用量，更何況是在秒殺那種分秒必爭的情況下。因此說交給用戶去設定 gas limit，這個說法多少有點勉強。我覺得對於 mint 這種邏輯簡單的 function，前端網頁其實應該給出 gas limit 而不是靠 metamask 去估算。昨天的 AMA 中官方有提到這個問題，他們的說法是希望將這個控制權交給用戶去決定，就好像設置 Gas Price 一樣，而不是由官方決定。對於這個觀點，我持有保留態度。 gas limit，不同於 gas fee，只要合約沒有類似 for loop 等的會嚴重影響 gas 用量的不確定因素，每次合約調用的用量基本都是固定的，完全可以通過在測試網測試等方法提早得知。 網頁前端在提交 trx 給 metamask 時，完全可以根據測試網的 gas 用量， 再加上一個足夠的 buffer，例如測試得出的 gas 用量是 21,000， 那麼可以建議 gas limit 是 21,000+(21,000 x 0.5) = 31,500 ， 提交給 metamask，這樣基本可以避免出現 out of gas 的問題。 

另外就是官方有提到智能合約會根據 block timestamp 去決定當前是公售還是白名單， 這樣做的原因是為了「更加去中心化」，防止被懷疑「官方作弊」。 對於這個觀點我也持保留態度。首先對於 block timestamp 這個全局變量，solidity 社區應該都有共識，不應該用它來參與一些重要的邏輯，因為礦工對於這個參數有一定的控制力。如果一定要在智能合約中加入一個標記來決定，那也完全可以透過一個參數，例如 state = 1 是白名單， state = 2 是公開發售來控制。 再者，在 Zombie Club NFT 這個例子中，官方引入了中心化伺服器 API 簽名認證（這個做法本身非常棒），但這已經和官方「更加去中心化」的說法有違背。 既然有了 API 的簽名參與，整個邏輯已經完全可以由 API 控制，那麼加入 block timestamp 的驗證則顯得畫蛇添足，也因此導致了 metamask 的估算錯誤，出現幾百個 out of gas 的問題。


### 結語

這次的 out of gas，嚴格來講並不能說是完全是官方的責任，究其原因的確是因為 block timestamp 導致 MetaMask 對 gas limit 的估算錯誤，儘管這個問題開發者如果再考慮仔細一點本來應該是可以避免。作為開發者我想我們在設計程式的時候應該要考慮到區塊鏈上的不確定性，特別是對於 block timestamp 這類變量的控制。而作為參與者或許也應該在 MataMask 做出的 Gas Limit 估計上再增加一定的額外額度。 畢竟，秒殺這種東西，本來就風險很高，更何況當時的 NFT 存量只有少得可憐的 1000 多個，既然願意參與，那麼應該也要知道可能發生的風險。

我本人覺得 Zombie Club NFT 這個項目是一個非常棒和有潛力的項目。不難看出，項目方為了它花費了大量心血。技術上，智能合約對於 gas 的用量控制，以及機器人的防範，都做的非常好。儘管公開發售出現了 out of gas 的問題算是有點不完美。 一個項目的成功與否，技術是基石，但團隊後續的態度，對項目的經營，社區的維護和發展，對項目的成敗會更為重要。從項目的 discord 社群很容易能夠看出，社群裡面的參與者們，非常積極的出謀獻策，參與討論，這在其他的項目中是很少見的。 

衷心希望這個項目能夠成為藍籌之一。 







Zombie Club NFT 最近可謂紅的不得了。這個有潮流明星余文樂站台的項目一開始就引人關注。寫這篇文章的初衷，是因為昨天晚上聽了官方團隊的一個技術 AMA，聽到了來自官方對技術上的一些分析和解釋。兩個多小時的 AMA，在最後的聽眾問答環節被推上高潮， 過程有聽眾對於智能合約的處理發出了質疑，問答的重點是關於公售時期幾百筆 out of gas 的原因追問。官方也花了很長時間解釋。但坦白講對於官方的回答有些地方我也不是十分認同。 星期日沒什麼事那這裡我們就來聊一聊這個 out of gas 是怎麼個回事。

聊一聊 Zombie Club NFT 的技術八卦


再見 Codi ， 永遠愛你。

文字無法表達現在的心情。 過去14年，你給我們帶來了太多的歡樂。

再見， Codi。 你會永遠永遠活在我們心中。

![](/image/blog/p78ya.jpg)


文字無法表達現在的心情。 過去14年，你給我們帶來了太多的歡樂。

再見 Codi ， 永遠愛你。



有人說以太坊的 gas fee， 動輒幾十，幾百美金，這似乎是一道避不過的坑。 參與 NFT 的鑄造亦是如此，mint 一個 NFT，少說也要幾十美金上下，如果一次 mint 多過一個 NFT，gas 的消耗更是成倍上漲。

目前流通中的 NFT 項目，大多數都是基於 [OpenZeppelin](https://openzeppelin.com/) 的 ERC721 實現版本來進行。 稍微解釋一下， ERC721 是[一個標準](https://eips.ethereum.org/EIPS/eip-721)，這個標準規定了作為一個 ERC721 的智能合約必須做到什麼事情。 實現這個標準有很多不同的做法(implementation)， 只要智能合約能夠滿足ERC721的標準要求，則被視為是一個有效的 ERC721 智能合約。而 [OpenZeppelin](https://openzeppelin.com/) 的 ERC721 實現，則是目前市面上最廣為使用的一個 ERC721 實現。

因此， [OpenZeppelin](https://openzeppelin.com/) 的 ERC721 實現，當然不是 ERC721 的唯一做法，你，我，都可以自己去實現 ERC721 標準。 今天要介紹的 ERC721a，就是一個新的 ERC721 實現，對比 [OpenZeppelin](https://openzeppelin.com/) 的 ERC721 實現， 其 mint NFT 特別是 mint 多個 NFT 所需要的 gas 成倍減少。

ERC721a 實現是由 [Azuki](https://www.azuki.com/erc721a) 研發的新的 ERC721 實現。這個 ERC721a，已經運用到了他們發行的 [Azuki NFT Collection](https://opensea.io/collection/azuki) 中。根據他們的[網站介紹](https://www.azuki.com/erc721a)，鑄造一個 NFT 所消耗的 gas fee，相比 OZ ERC721，節省了一倍還多，如果是一次鑄造 5 個，節省的 gas 甚至達到 7 倍。

![](/image/blog/vv9ft.png)

換算成美金，鑄造一個 NFT 節省 $82 美金，鑄造 5 個則節省驚人的 $650 美金。

![](/image/blog/mhcrw.png)

光看沒用，自己實際測試一下才可以。 我對比 OZ ERC721 和 Azuki ERC721a 做了實際測試，結果如下：

**鑄造1個 NFT：**

ERC721 Gas 消耗: 229,528
[https://rinkeby.etherscan.io/tx/0xe8f0ee22f0d1f027f7c9a11db5088fe91c1ab63b0d2bb25694901e5175b96d12](https://rinkeby.etherscan.io/tx/0xe8f0ee22f0d1f027f7c9a11db5088fe91c1ab63b0d2bb25694901e5175b96d12)

ERC721A Gas 消耗: 156,382
[https://rinkeby.etherscan.io/tx/0xa8062804800150b03ba1172ceee64d4b3d6da9720f254d595a67bfdac6752aab](https://rinkeby.etherscan.io/tx/0xa8062804800150b03ba1172ceee64d4b3d6da9720f254d595a67bfdac6752aab)

**鑄造4個 NFT：**

721 Gas 消耗: 559,900
[https://rinkeby.etherscan.io/tx/0x7db57fd064723326140558dfa84757535c309e9576965db132a6d0d19cd85ef9](https://rinkeby.etherscan.io/tx/0x7db57fd064723326140558dfa84757535c309e9576965db132a6d0d19cd85ef9)

721A Gas 消耗: 126,906
[https://rinkeby.etherscan.io/tx/0x3013fb6ba02c86086e27a2f167ce56ed87fc6cde97b8b304f9e73ac9e225e729](https://rinkeby.etherscan.io/tx/0x3013fb6ba02c86086e27a2f167ce56ed87fc6cde97b8b304f9e73ac9e225e729)

明顯見到， ERC721a 在 gas 的用量上明顯節省很多。

### Why

Gas 節省這麼多，Why？ 

這裡要再說說另外一個接口 **ERC721Enumerable**。 為了讓我們能夠更容易的讀取 ERC721 NFT 智能合約關於發行總量，持有者等情況，大多數 NFT 智能合約都會實現另外一個標準，即 ERC721Enumerable，這個標準要求智能合約提供以下功能：

```js
totalSupply(): 該函數返回合約發行的未銷毀的 NFT 總數。此外，每個 token 都需要有一個不是 address(0) 的有效持有者地址。
tokenByIndex(): 該函數返回指定位置的 NFT 的 tokenId。
tokenOfOwnerByIndex(): 該函數返回指定的地址所擁有的 NFT token 中特定索引位置的 NFT 的 tokenId。
```

上面的解釋聽起來比較拗口，簡單講就是要求智能合約需要保存總共發行了多少 NFT，發行的次序，多少沒有被銷毀，持有者的情況等等。聽起來比較簡單，但深入想想，若是要實現這些功能則需要數據存儲，而在區塊鏈上存儲數據則需要花費金錢，這也是為什麼鑄造一個 NFT 需要花費大量 gas 的原因之一。

#### ERC721a 做了什麼優化？

**首先 ERC721a 對 ERC721Enumerable 中的實現做了優化，去除了一些不必要的存儲。**

我們看看 `totalSupply()` 這個例子：

OZ  ERC721Enumerable: 
```solidity
// Array with all token ids, used for enumeration
uint256[] private _allTokens;

/**
  * @dev See {IERC721Enumerable-totalSupply}.
  */
function totalSupply() public view virtual override returns (uint256) {
   return _allTokens.length;
}
```

Azuki ERC721a:
```solidity
uint256 private currentIndex = 0;

/**
  * @dev See {IERC721Enumerable-totalSupply}.
  */
function totalSupply() public view override returns (uint256) {
    return currentIndex;
}
```

可以看到相比 OZ ERC721Enumerable，  Azuki ERC721a 沒有使用昂貴的 array 存儲空間來保存 allTokens， 而是直接用 `currentIndex` 來返回（之所以能這樣做是因為 Azuki ERC721a 的所有 tokenID 都是從 0 開始，逐個增長）。

**然後，對於 mint function，Azuki ERC721a 也做了優化。**

OZ ERC721 的實現中並沒有提供批量鑄造的功能，換句話說如果我們要鑄造4個 NFT，那就必須循環調用 mint 4 次。因此這也就是為什麼 OZ ERC721 智能合約一次性鑄造 N 個 NFT 的 gas 消耗會隨著 N 的增加而成比例增加的原因。

對於這個問題， Azuki ERC721a 做出了優化，`_safeMint` 提供了 `quantity` 參數， 因此我們要鑄造多個 NFT，只需要傳入需要鑄造的數量，一次調用就可以完成。 

```solidity
function _safeMint(address to, uint256 quantity) internal {
    _safeMint(to, quantity, "");
}
```

不要小看這個參數的加入， 假設小明要鑄造 4 個 NFT， 如果用 OZ 的實現，我們要循環調用 `_safeMint` 4 次， 而每次 `_safeMint` 都會去更新小明擁有的 NFT 總數，當前總共發行的 NFT 總數等資料。所以為了把小明擁有的 NFT 總數從 0 變到4，OZ ERC721 會循環四次， 從 0 增加到 1， 再從 1 增加到2， 然後從2 增加到3，最後從 3 增加到 4。  而每次區塊鏈資料的更新，必然需要消耗 gas。 而 Azuki ERC721a ，則是直接將小明擁有的 NFT 總數從 0 變到4，這樣只需更新區塊鏈一次，即可達到效果，節省了3次不必要的更新。

```solidity
function _safeMint(
    address to,
    uint256 quantity,
    bytes memory _data
) internal {
    uint256 startTokenId = currentIndex;
    
    ...

    AddressData memory addressData = _addressData[to];
    _addressData[to] = AddressData(
        addressData.balance + uint128(quantity),
        addressData.numberMinted + uint128(quantity)
    );
    _ownerships[startTokenId] = TokenOwnership(to, uint64(block.timestamp));

    uint256 updatedIndex = startTokenId;

    for (uint256 i = 0; i < quantity; i++) {
        emit Transfer(address(0), to, updatedIndex);
        require(
            _checkOnERC721Received(address(0), to, updatedIndex, _data),
            "ERC721A: transfer to non ERC721Receiver implementer"
        );
        updatedIndex++;
    }

    currentIndex = updatedIndex;
    _afterTokenTransfers(address(0), to, startTokenId, quantity);
}
```

**最後，對於 `ownerOf()` 這個 function，Azuki ERC721a 也做了優化。 **

假設小明鑄造了 4 個 NFT，然後小強又鑄造了 4 個 NFT，OZ 的 ERC721 會將 8 個 NFT 每一個都標記各自的持有者，也就是會存儲 8 個持有者資料。 而 Azuki ERC721a ，只會在第一個 NFT 標記持有者為小明，第五個 NFT 標記持有者為小強。而其餘的 NFT 則不標記。這樣就可以節約大量的存儲空間。

那我們怎麼知道中間的沒有標記持有者的 NFT 是屬於誰？ 

其實不難，因為 tokenId 是連續增長，所以只要找到比這個 tokenId 小的最接近持有者，即可以認為該持有者亦擁有當前的 NFT。

### 問題

總體來說，經過多次測試，我覺得 Azuki ERC721a 的確可以節省大量的 gas 成本，特別是一次過鑄造多個 NFT ，其花費的 gas 和鑄造一個 NFT 相差不大。

然而 Azuki ERC721a 也不是沒有問題。

因為 Azuki ERC721a 中的主要邏輯都和 tokenId 必須要保持連續為基礎，所以目前的 Azuki ERC721a 並沒有提供 burn token 的功能。所以如果要使用類似銷毀 NFT 的功能，Azuki ERC721a 則不適用。 而且，如果你需要 NFT tokenId 不是連續增長，Azuki ERC721a 也不適用。

另外，偶然還發現 Azuki ERC721a 部署到 polygon mainnet 中後，如果一次過鑄造超過 4 個NFT，則該組 NFT 在 OpenSea 上無法看到（在 polygon scan 上看到智能合約的執行完全正常， 所有NFT，持有者資料都正確無誤）。 

例如 [這個 #16 號 NFT](https://opensea.io/assets/matic/0x4e6cc29436ceb11411202440f4e8aee482e8840a/16)， 在 OpenSea 上顯示 Not Found， 而這個 [\#22 號 NFT](https://opensea.io/assets/matic/0x4e6cc29436ceb11411202440f4e8aee482e8840a/22)，則可以正常顯示。因為我一次過鑄造了 14-18 號 NFT，超過了 4 個， 因此 14-18 號 NFT 都無法正常顯示， 而 19-22 號 NFT 則因為沒有超過 4 個，則可以正常顯示。** 奇怪的是，同樣的智能合約部署在 Rinkeby 測試網則完全沒有問題**， 所以我也不清楚究竟是 OpenSea 的問題還是 Polygon 的問題。

關於這個問題我已經聯絡了官方開發者，等待他們的回覆中。








鑄造以太坊的 NFT，動輒幾十，幾百美金。這是作為官方或者用家都不願意看到的。然而最近出了一個新的 ERC721 實現 (ERC721a)，能夠成倍節省 gas fee，特別是當鑄造多個 NFT 的時候，消耗的 gas fee 和鑄造一個 NFT 相若。這麼神奇？如何做到？想用，有沒有什麼問題？這篇文章就來分析一下。

大量節省 Gas Fee 的 ERC721A NFT 智能合約



這篇文章假設大家使用 [hardhat](https://hardhat.org/) 來進行智能合約開發。關於 hardhat 我有時間再詳細寫一寫懶人教學 😅。



大家如果常去 Etherscan 上查看智能合約 Smart Contract， 大概會看到兩種情況，第一種是如下這樣，在 Contract 下面看到是一堆「亂碼」，這堆「亂碼」其實是編譯過後的智能合約 ByteCode （字節碼），這明顯不是給人類閱讀的。

![](/image/blog/1mgva.png)

另一種則是如下圖所示，在 Contract Tab 旁邊能夠看到一個綠色的✓，下面能夠看到智能合約的原始代碼，並且可以直接在 Etherscan 上讀取，調用智能合約的 function。

![](/image/blog/riwuc.png)

明顯第二種合約給人的感覺會自信很多， 因為所有人都能夠清楚看到智能合約具體的運行邏輯，一切公開透明，不怕「黑箱作業」。

#### 那麼如何做到在 Etherscan 上「開放原始碼」呢？

一種方法是手動在 Etherscan 上提交原始碼，透過提交智能合約的地址，選擇編譯器版本，上載智能合約的原始碼等等一系列步驟之後便可以做到。

![](/image/blog/wfvhd.png)
![](/image/blog/bkzwe.png)

但這種方法的壞處是非常麻煩，要確保選對編譯器版本，上載所有需要上載的檔案，包括一些第三方的 library。一旦上載的原始碼檔案出現錯漏，則無法完成認證。 

有沒有更好的方法呢？

#### 隆重介紹  @nomiclabs/hardhat-etherscan 

使用 @nomiclabs/hardhat-etherscan  這個 npm package，能夠超級簡單的完成智能合約認證。這個 package 集成了 Etherscan 的 API，透過 API 的形式自動完成原始碼認證，免去了繁瑣的手動步驟。

### 第一步

首先我們需要在 Etherscan 上有一個賬戶，然後免費申請一個 API key。 [按此前往](https://etherscan.io/myapikey)。

![](/image/blog/8d80c.png)

在上述頁面中按下「ADD」即可申請一個全新的 API Key。得到這個 API Key 之後，將它放入你的 .env 檔案中。（假設你用 .env 檔案來保存環境變數）

```js
API_URL = xxx
PUBLIC_KEY = xxx
PRIVATE_KEY = xxx
ETHERSCAN_API_KEY = 這裡填上你上面得到的 API Key 
```

### 第二步

安裝  `@nomiclabs/hardhat-etherscan`‌ ， 使用 npm 或者 yarn 的方式安裝。這個應該不用多說了吧，是人都會了。

```bash
yarn add @nomiclabs/hardhat-etherscan‌ -D
```

### 第三步

現在我們需要設定 `hardhat.config.js` 。

首先，要在 `hardhat.config.js` 頂部引入這個 package 

```js
require("@nomiclabs/hardhat-etherscan");‌
```

然後，在 `hardhat.config.js` 添加如下設定：

```js
module.exports = {
  solidity: "0.8.4",
  networks: {
    rinkeby: { xxx }, // xxx 是省略的意思哦，你應該不會照抄吧 😒
  },
  etherscan: {
    // 下面這個就是 Etherscan 的 API Key 哦 
    // 和上面第一步中 .env 檔案中的對應
    apiKey: process.env.ETHERSCAN_API_KEY
 }
};
```

### 第四步

在完成智能合約編譯後，透過以下指令即可驗證智能合約原始碼：

```bash
npx hardhat verify --network rinkeby <你的已發佈智能合約地址>
```

舉例：

```bash
frank@MacBook demo % hh compile
Compiling 1 files with 0.8.4
Compilation finished successfully


frank@MacBook demo % npx hardhat run --network rinkeby scripts/DeployDemo.js                     
Deploying demo contract ... 
Waiting for 2 confirmations...
Contract deployed to:  0x4451ED9cD559Ac5e552c7AD757a642Af533EbD88


frank@MacBook demo % npx hardhat verify --network rinkeby 0x4451ED9cD559Ac5e552c7AD757a642Af533EbD88
Nothing to compile
Compiling 1 file with 0.8.4
Successfully submitted source code for contract
contracts/Demo.sol:Demo at 0x4451ED9cD559Ac5e552c7AD757a642Af533EbD88
for verification on Etherscan. Waiting for verification result...

Successfully verified contract Demo on Etherscan.
https://rinkeby.etherscan.io/address/0x4451ED9cD559Ac5e552c7AD757a642Af533EbD88#code


```

至此，打開 [Etherscan](https://rinkeby.etherscan.io/address/0x4451ED9cD559Ac5e552c7AD757a642Af533EbD88#code) ，就可以看到我們的智能合約已經認證成功啦。


DeployDemo.js 參考：

```js

const { ethers } = require("hardhat")

async function main() {

  console.info(`Deploying demo contract ... `)
  const Demo = await ethers.getContractFactory("Demo");
  const demo = await Demo.deploy();
  
  console.info(`Waiting for 2 confirmations...`)
  let transcation = demo.deployTransaction
  const receipt = await transcation.wait(2)
  const { gasUsed } = receipt
  console.log("Contract deployed to: ", demo.address);
  console.info(`Gas used           : ${gasUsed} `)

}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });


```


大家如果常去 Etherscan 上查看智能合約 Smart Contract， 有些智能合約會看到一堆「亂碼」，而有些智能合約則會看到很漂亮的原始碼，並且能夠直接在 Etherscan 上和智能合約交互。明顯第二種開放原始碼的智能合約給人的感覺會自信很多，那究竟怎樣才能完成原始碼認證呢？

在 Etherscan 上提交智能合約原始碼認證




不是標題黨哦，真的只要兩分鐘就可以發行你自己的 ERC20 Token。 

ERC20 Token，就是和 USDT，USDC 一樣的基於以太坊的一種代幣。任何人都可以在以太坊，或者是基於以太坊的區塊鏈上建立 ERC20 代幣。

### 構建 ERC20 智能合約
首先，我們使用 [OpenZeppelin 提供的在線工具](https://wizard.openzeppelin.com/)來輕鬆構建 ERC20 智能合約。前往 [https://wizard.openzeppelin.com/](https://wizard.openzeppelin.com/)：

![](/image/blog/srchc.png)
  
左上角選擇「ERC20」， 然後在 Name， Symbol，Premint 等輸入框內填上你自己 Token 的資料。
  
**Name**： Token 的名稱；
**Symbol**： Token 的符號；
**Premint**： 預先挖掘的數量， 這個數目的 Token 在智能合約發佈的時候會自動挖出，並且發送給部署智能合約的賬戶。

選中 Feature 中的選框後，會為智能合約添加對應的功能，例如 Mintable 可以允許 Token 在合約發佈之後可以再繼續發行，而不是固定的發行數量。這些功能在旁邊的小問號有詳細的解釋，這裡就不再贅述。


### 使用 Remix 發佈你的 ERC20 Token 到區塊鏈上

在設定好你的 ERC20 智能合約之後，就可以準備發佈到區塊鏈上了。

![](/image/blog/ueklo.png)

按下右上角的 「Open in Remix」， 就可以神奇的打開 Remix 在線 IDE。

![](/image/blog/erzhl.png)

Remix 打開之後你的智能合約已經在裡面了。

第一步，切換到 Deploy 窗口(上圖 1 所示按鈕 )；
第二步，選擇發佈的環境，如果要發佈到公共區塊鏈上，我們選擇「Injected Web 3」，這會要求你連接 MetaMask，根據你 MetaMask 所選擇的網路(Mainnet, Testnet， BSC 等等)，會發佈到對應的區塊鏈上。
第三步，在 「Contract」 中選擇當前畫面顯示的智能合約，我上面的例子就是 FrankToken 這個智能合約。
第四步，按下「Deploy」按鈕，這時會彈出 MetaMask 讓你簽名部署智能合約。

![](/image/blog/qeclm.png)

確認無誤後，按下 「Confirm」，稍作等待，就可以看到我們的 ERC20 Token 已經成功建立了。

![](/image/blog/e06fk.png)

### 在 MetaMask 中添加新建立的 Token

MetaMask 預設不會顯示自定義 Token，要想讓我們的 token 在 MetaMask 中顯示，我們需要講 Token 添加到 MetaMask 中。 

首先我們找到剛才部署的 ERC20 智能合約的地址。這個地址在 Remix ， 以及 MetaMask 的交易記錄中都可以找到。 然後，在 MetaMask 中的 Asset 畫面，最底部有一個 Import Token，按下之後，輸入剛才的合約地址，即可。 具體可參考下面的影片：


<div class="video-container" style={{paddingTop: "58%"}}>
<iframe
  src="https://player.cloudinary.com/embed/?cloud_name=dxuoive6n&public_id=Blog/import-token&fluid=true&controls=true&source_types%5B0%5D=mp4"
  allow="autoplay; fullscreen; encrypted-media; picture-in-picture"
  allowfullscreen
  frameborder="0"
></iframe>
</div>


大功告成，就是這麼簡單哦。








不是標題黨哦，真的只要兩分鐘就可以發行你自己的 ERC20 Token。 不需要寫代碼哦。

2 分鐘建立你自己的 ERC20 Token



如果玩過 NFT，相信你對「白名單」制度不會陌生。NFT公開發售之前，都會讓一小部分被授權的地址，可以提前購買。因為能夠保證取得購買資格，無需與其他人瘋搶，所以往往大家都非常想擠進這個白名單中去。

本文不討論 marketing 的策略，而是說說 NFT 智能合約如何更優雅的處理白名單。 

聰明的你肯定想到，可以用一個 mapping，來儲存所有 whitelist 的地址，當 presale 時檢查這個 mapping 中是否有這個地址即可。

```js
//SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.4;
import "@openzeppelin/contracts/access/Ownable.sol";

contract Whitelist is Ownable {
    mapping (address => bool) userAddr;

    function addToWhitelist (address[] calldata users) external onlyOwner {
        for (uint i = 0; i < users.length; i++) {
            userAddr[users[i]] = true;
        }
    }

    function preSale() external payable 
    {
        require(whiteList[msg.sender] == true, "STOP: not in whitelist");
        ...
    }

}
```

當然，這個方法絕對沒錯。很多 NFT 專案都是使用這個方法。 可是，這種的做法的一大問題就是成本太貴。 我做了[一個實驗](https://rinkeby.etherscan.io/tx/0xc1bf9bb1e6e9c055f9058c9e9a4a7f1e633d7d6e831f79c314640affda463b49)，假如按照 gas price 89 gwei 計算， 一次過儲存 1,000 個白名單地址，消耗 502,774 gwei gas， 需要支付 2.06 ETH，約合 67,885 港幣的費用。如果分開多次存儲，花費更高。

當然如果你「不差錢」，那麼就可以不要再看下去了。但如果不捨得這六萬元，我們可以看看有沒有更好的方法。

答案當然是有的。我們看看下面一段 solidity 程式：

```js
   function presale(
        bytes memory _ticket, // 伺服器發出的「票據」
        bytes memory _signature // 伺服器發出的「簽名」
    ) public payable {
         
        // 如果你想的話，我們可以在智能合約中檢查「票據」是否被使用過。
        require(!_ticketUsed[_ticket], "FRANK: ticket has already been used");

        // 驗證「票據」和「簽名」是否有效
        require(
            isAuthorized(
                msg.sender,
                _ticket,
                _signature,
                signerAddress
            ),
            "FRANK: ticket is invalid"
        );
    
        _mint();
    }
```

相信聰明的你看完後已經有點頭緒了。 這個做法就是引入了一個「票據」和「簽名」的概念。當用戶在你的網頁上 mint NFT 時，不僅僅是直接同智能合約互動，而是需要預先從 web 伺服器憑藉自己的地址，取得一個授權，這個授權包括一個「票據」和一個「簽名」。

從伺服器的角度來看，伺服器保管有一個簽名私鑰，可以根據用戶的地址，加上一個隨機生成的有意義或無意義數據，即「票據」，組合後進行數位簽署，從而得到一個「簽名」。

然後，用戶可以憑藉「票據」和「簽名」，向智能合約發起購買請求。當智能合約收到購買請求後，會對「票據」和「簽名」進行認證。

認證的步驟，我們會使用 solidity 的 ecrecover 方法。ecrecover 可以根據「簽名」，得出簽名者的公鑰地址。因此，在知道簽名者的公鑰地址的前提下，我們就可以透過核對這個地址，來判斷「簽名」是否由簽名者發出。

我們附帶一個「票據」，則某種程度上是為了防止「回放攻擊」( replay attack )。我們可以在智能合約中檢查該 「票據」是否已經被使用過，從而執行不同的邏輯。

```js
  function isAuthorized(
    address sender, // 發起 trx 人的地址；
    bytes memory ticket, // 伺服器發出的「票據」
    bytes memory signature, // 伺服器發出的「簽名」
    address signerAddress // 簽名人的地址
  ) private pure returns (bool) {
    bytes32 hash = keccak256(abi.encodePacked(sender, ticket));
    return signerAddress == hash.recover(signature);
  }
```

這種簽名認證的方法，好處非常明顯。我們完全不需要在智能合約中花費大量成本存儲任何白名單地址，就可以優雅的做到白名單效果，而且也可以隨時增加或減少白名單的數量。

不僅如此，使用這個方法，我們亦可以讓智能合約能夠輕易做到一些邏輯驗證。比如，一個購物的智能合約，需要驗證傳入的 ETH 是否和商品價格符合，一個做法是在智能合約中存儲一個商品ID和價格的列表，每當交易時進行比對。而使用簽名認證，則可以使用上述相同邏輯，透過傳入一個「簽名」，智能合約則可以驗證數據的真確性，而無需在智能合約中保存海量昂貴數據。





如果玩過 NFT，相信你對「白名單」制度不會陌生。NFT公開發售之前，都會讓一小部分被授權的地址，可以提前購買。可是作為智能合約開發者，你知不知道一次過儲存 1,000 個白名單地址， 竟然需要支付 2.06 ETH，約合 67,885 港幣的費用。那麼有沒有更優雅，更省錢，更靈活的白名單做法呢？進來看看吧。

如何更優雅的實現 NFT 智能合約的白名單功能


首先我們來欣賞一個 Etherscan 上的[交易記錄](https://etherscan.io/tx/0xde2c4d1d6939590a512e523bb89f9865ca17766b7507dd1c6ff05021f352792b)。這個交易是 2021年10月16日 早上 [Jungle Freaks](https://opensea.io/collection/jungle-freaks-by-trosley) 開賣時的其中一筆 mint 交易。各位請留意，這個交易， mint 了 3 個 NFT，每個 NFT 花費0.07 ETH， 但是，叮叮叮，有沒有注意到 Transaction Fee 竟然高達1.744 ETH，相等於 6,712 美元，52,195 港元。 

![](/image/blog/hckxu.png)

有沒有嚇到，有沒有震驚到。這就是以太坊上讓然目瞪口呆的 Gas War 的力量。

究竟發生了什麼？

首先我們需要知道區塊鏈上的每一筆操作都需要支付礦工費。這筆費用是以太坊上的礦工們幫你將數據寫入區塊鏈的「酬勞」。 而以太坊平均約 15 秒產生一個區塊， 而每個區塊內可以容納的 gas 上限大約為 15,000,000 個。區塊內的所有交易的 gas 總和，不能超過這個上限。

因此，當某一時刻出現交易量暴增，超過區塊容量的上限時，大量的交易會出現擁堵，大家都想盡快被礦工處理，擠進下一個區塊中。可是，以太坊上的礦工選取交易，並不是「先到先得」，而是「**價高者得**」，誰給的礦工費更高，礦工就會優先選擇誰。

在 NFT 新發售的時刻，因為發售價往往會非常低，有點像新股發售的概念，所以大家擠破頭皮都想在NFT 新發售的時候搶到，正因為如此，出現上面的情況就不足為奇了。一些熱門的 NFT 項目，如果公開發售是使用這種「大家同時一起 mint」的模式，那麼如果你想得到 NFT，不給出超乎常理高的 gas price，則基本沒有希望能夠成功。

![](/image/blog/arazl.png)

因為 NFT 的數量有限，一旦達到上限，之後的交易全部會註定失敗。可是發出去的交易指令，如果你不做任何操作，最終還是會被礦工處理，因此 gas fee 還是會照樣消耗（ 但因為智能合約會執行 revert 操作，不會執行餘下的邏輯，因此失敗的交易 gas 數量消耗會較少，而且對應的 eth 會退回）。

當然，你可以發出「取消」指令。但是，**取消的成本，可能更高**。

根據太坊網規則，同一地址的每一筆交易 nonce 值是**連續，不可跳躍，不可重複的**。舉例來說，假如你的錢包發起 5 筆轉賬，其中第一筆因為網路擁堵而處於「等待」狀態，那麼，因為 nonce 的連續性要求，餘下的 4 筆交易都必須等待，直到第一筆交易成功後，才能繼續執行。

可是，如果出現重複的 nonce 值，會怎麼樣呢？根據規定，如果同一個地址出現多個相同 nonce 值，礦工會選擇其中一個來進行處理，其它的則會被廢棄。而礦工們由於逐利的心態，往往會選擇 gas price 給的更高的一個來處理。正是這個原因，我們利用相同 nonce ，對已經提交的交易進行「加速」，或是「取消」操作。如果要加速，則重新提交一個 nonce 相同，交易內容相同，但 gas price 更高的操作；如果要取消交易，則重新提交一個 nonce 相同，交易金額為0，gas price 更高的交易。

所以說，無論「加速」，或是「取消」操作，**前提是你都需要重新提交一個 gas price 更高的交易**。而往往，在類似 NFT 發售這種「秒殺」的場合下，gas price 的升幅會非常驚人。如果你想取消之前的交易，所要付出的 gas ，絕對不低。

為什麼說 NFT 項目如果採取這種「大家同時一起 mint」的 Gas War 模式發售，是人神共憤，正式因為有大量，巨量，海量的交易，因為給的 gas price 不夠多，被礦工處理的不夠快，而導致最終因為 NFT 已經售罄而失敗，但這個過程，無論是否取消交易，都依然要付出昂貴的 gas 成本。這些成本，並沒有實現任何價值，完全是徹頭徹尾的浪費網路資源。

我比較認同的 NFT 出售方式，是 White List 形式，所有「鬥快」，「抽獎」，等等市場推廣的「伎倆」，其實完全可以透過 offchain 的方式處理，即便是想營造「秒殺」氛圍，都完全可以使用類似在一個指定時間開放登記，按照登記次序先到先得的模式進行。登記完成後，被選擇出來的地址才有上鏈 mint 的資格，這樣完全不會引致 Gas War， 會節省大量的金錢和網路成本。







 


mint 3 個 NFT，每個 NFT 花費 0.07 ETH， 但是交易費用竟然高達 1.744 ETH，相等於 6,712 美元，52,195 港元，究竟是為什麼？

人神共憤的 NFT Gas War






之前有寫過一篇文章教大家<Link href="/blog/nft-smart-contract">自己15分鐘寫 ERC721 智能合約</Link>，這篇文章則說一說 ERC721 的升級版，ERC1155 智能合約。建議大家先看看關於 <Link href="/blog/nft-smart-contract">ERC721</Link> 的那篇文章。

### ERC1155 和 ERC721 有什麼區別

開始介紹 ERC1155 智能合約的寫法之前，我覺得先要說說 ERC1155 和 ERC721 到底有什麼區別。
簡單來說，ERC1155 是 ERC721 的升級版，ERC1155 在 ERC721 的基礎上，主要增加或改善了如下功能：

- 同時支持可替換代幣(同質化代幣)和不可替換代幣(非同質化代幣)；
- 批量轉賬: 僅需要一次智能合約調用，就可以轉賬多種代幣資產；
- 批量查詢餘額：一次智能合約調用可以查詢多種代幣餘額資料；
- 批量授權：一次智能合約調用可以向指定地址授權多種代幣的使用權；

用再簡單一些的人話來講，就是一張 ERC1155 智能合約，裡面可以同時包含類似 USDT 這種代幣，和類似 [MekaVerse](https://opensea.io/collection/mekaverse) ，[無聊猿](https://opensea.io/collection/boredapeyachtclub)等這種獨一無二的 NFT 代幣。 另外，傳統的 ERC721 合約，如果要轉移 NFT，必須一個一個操作，沒有辦法做到批量轉賬。而 ERC1155，則宛如加入了類似「購物車」的概念，可以一堆代幣一次過轉移。不要小看這個「批量」功能，要知道每次和區塊鏈交互，都要消耗 gas，如果有某些應用場景需要大量，頻繁轉移資產，那 ERC1155 相比 ERC721 則能節約大量的 gas 成本。

我們可以試想一下，假如現在想要創作一款區塊鏈遊戲，裡面有類似 USDT 的可替換同質化代幣以進行金融操作，也需要有各種遊戲裝備，英雄角色等獨一無二不可替換代幣來進行遊戲，這兩種代幣也需要透過一定的機制進行交易互換，這個場景，使用 ERC1155 則可以完美實現。

我們不妨對比一下 ERC721 和 ERC1155 合約的規範接口：  
  
ERC721
```js

function balanceOf(address _owner) external view returns (uint256);
function ownerOf(uint256 _tokenId) external view returns (address);
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
function approve(address _approved, uint256 _tokenId) external payable;
function setApprovalForAll(address _operator, bool _approved) external;
function getApproved(uint256 _tokenId) external view returns (address);
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
```

ERC1155
```js
function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;
function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;
function balanceOf(address _owner, uint256 _id) external view returns (uint256);
function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);
function setApprovalForAll(address _operator, bool _approved) external;
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
```

可以明顯看到，ERC1155 在原有 ERC721 基礎上增加了很多 batch 的接口。再看看 OpenZeppelin 中的 ERC1155 實現，其中的 mint function 增加了 `amount` 參數， 不難想象，如果 `amount = 1`， 則代表這個代幣總共只發行一個，那這個代幣就是類似 ERC721 的 NFT 了。 

```js
function _mint(
    address account,
    uint256 id,
    uint256 amount,
    bytes memory data
) internal virtual {
    require(account != address(0), "ERC1155: mint to the zero address");
    address operator = _msgSender();
    _beforeTokenTransfer(operator, address(0), account, _asSingletonArray(id), _asSingletonArray(amount), data);
    _balances[id][account] += amount;
    emit TransferSingle(operator, address(0), account, id, amount);
    _doSafeTransferAcceptanceCheck(operator, address(0), account, id, amount, data);
}
```

說完了基本概念，下面我們就來 get your hands dirty，親手嘗試一下寫一個 ERC1155 智能合約，你會發現，其實遠比你想象的簡單。
 

### 15分鐘快速建立 ERC1155 智能合約

#### OpenZeppelin 
我們這個示例，依舊使用 OpenZeppelin 的合約為範本。[OpenZeppelin](https://openzeppelin.com/) 是一個開源的智能合約倉庫，上面已經有許許多多各種各樣的智能合約範本，包括 ERC721，ERC1155 等智能合約。因此我們只需要基於 OpenZeppelin 的現有合約，擴展我們自己特定的功能即可。

#### 安裝 OpenZeppelin Contracts

確保已經安裝最新版的 NodeJS，運行下面的指令：

```bash
npm install @openzeppelin/contracts
```

之後在當前目錄下就會安裝好 OpenZeppelin Contracts 的檔案。

#### 使用 Remix IDE

[Remix](https://remix.ethereum.org/) 是 Ethereum 官方提供的 IDE 。包含完整的編譯器、執行合約、發布合約等等的功能。無須安裝，只要用瀏覽器開啟 [https://remix.ethereum.org/](https://remix.ethereum.org/) 即可。

Remix 默認情況下會將所有資料存儲在瀏覽器的 Local Storage 中，所以當你清除瀏覽器緩存快取，或者在另外一台電腦打開 Remix，你的資料便會丟失。 Remix 也提供了使用本地文件系統來進行存儲的功能，但需要安裝一個 remixd 本地程式，具體方法可以[參考這裡](https://remix-ide.readthedocs.io/en/latest/remixd.html)。

當你安裝好 remixd 後，便可以透過運行下面的指令來建立 Remix 和本地檔案的連結：

```bash
remixd -s <absolute-path-to-the-shared-folder> --remix-ide <your-remix-ide-URL-instance>
```

#### 撰寫智能合約

完成上面的步驟後，我們便可以開始建立自己的 ERC1155 合約了。

![](/image/blog/qy2tu.png)


```js
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC1155/presets/ERC1155PresetMinterPauser.sol";


contract Marvel1155 is ERC1155PresetMinterPauser {
    
    uint256 public constant CAPTAIN_AMERICA = 0;
    uint256 public constant THOR = 1;
    uint256 public constant IRON_MAN = 2;
    uint256 public constant SPIDER_MAN = 3;
    
    constructor() ERC1155PresetMinterPauser( "https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json") {
        _mint(msg.sender, CAPTAIN_AMERICA, 10**18, "");
        _mint(msg.sender, THOR, 1, "");
        _mint(msg.sender, IRON_MAN, 5, "");
        _mint(msg.sender, SPIDER_MAN, 10, "");
    }
    
}

```

以上的代碼便是利用 OpenZeppelin 的 ERC1155 合約建立，我們只需要非常簡單的幾行代碼，便可以完成一個 ERC1155 智能合約。

簡單解釋一下以上代碼的意思：  

```js
uint256 public constant CAPTAIN_AMERICA = 0;
uint256 public constant THOR = 1;
uint256 public constant IRON_MAN = 2;
uint256 public constant SPIDER_MAN = 3;
```

上面這段代碼，是定義了這個合約中有幾種「類型」的代幣。（當然，直接在 mint 的時候傳入自定義類型也是可以的😂)

```js
constructor() ERC1155PresetMinterPauser( "https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json") {
    _mint(msg.sender, CAPTAIN_AMERICA, 10**18, "");
    _mint(msg.sender, THOR, 1, "");
    _mint(msg.sender, IRON_MAN, 5, "");
    _mint(msg.sender, SPIDER_MAN, 10, "");
}
```

上面這段代碼，則是「構造器」，在智能合約發佈的時候會被調用，挖掘了4款不同的代幣，每個代幣的發行總量分別是 10 <sup>18</sup>，1，5，10。因此可以理解為，THOR 這個代幣，就是一個 NFT，而其他的代幣，則是類似 ERC20 的同質化代幣。

「構造器」中傳入的 `https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json` 是代幣對應的 URI，這個和 ERC721 的概念是一樣的，OpenSea， Rarible 等 NFT 市場，會訪問這個 URI，去取得代幣的 metadata，下面我們會再講到。


#### 編譯，發布智能合約

編輯完成後， 就可以切換到 Compile 面板進行編譯。留意要選擇正確的編譯器版本，編譯器版本要和你合約中聲明的版本相符合，否則無法編譯。

![](/image/blog/cjoqp.png)

編譯完成後，便可以準備發布（deploy）了。切換到 Deploy 面板。此時我們要在左上角的 Environment 中選擇【Injected Web 3】，此時便會彈出 MetaMask 進行連結。如果還沒有安裝 MetaMask，可以先在 [Chrome Web Store](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn) 中安裝。

我們開始嘗試時一般都會選擇在測試網路（testnet）中進行，測試網絡和 Ethereum 主網在技術上沒有區別，但在測試網路中不需要花費真實的 ETH ，而是使用測試網路中的 ETH。一般我們開發的 Blockchain 程式，都要先在測試網路上做全面測試，之後才在主網中上線。要知道 Ethereum 主網的 Gas Fee 可高的驚人。

Ethereum 的測試網路有很多，例如 Ropsten， Rinkeby，Goerli 等等。為了能在 OpenSea 上測試，我們選擇 Rinkeby 測試網路（OpenSea 的testnet 預設為 Rinkeby 測試網路）。

使用測試網路，記得要在 MetaMask 中選擇 Rinkeby Test Network。

![](/image/blog/dmybz.png)

在 Ethereum 網路上任何導致更改數據的動作都需要花費 ETH，因此發布智能合約自然需要 ETH。如果沒有 testnet 的 ETH 可以在網上找到很多 testnet faucet 可以免費獲得 testnet 的 ETH ，例如[這裡](https://faucet.rinkeby.io/)。一切就緒後，就可以按下 【Deploy】，開始發布你的智能合約，中間會彈出 MetaMask 進行付款確認。

發布完成後，Remix 會顯示對應的 Transaction Hash，例如我自己上面的例子，對應的 Transaction 可以在 [https://rinkeby.etherscan.io](https://rinkeby.etherscan.io) 上看到，裡面亦可以看到我們建立的 ERC1155 智能合約地址。

![](/image/blog/vnoyw.png)

因為我們的示例合約中在構造器( constructor ) 中已經 mint 了4 種代幣，因此當合約發佈後，[在 OpenSea 中已經可以即時看到](https://testnets.opensea.io/collection/unidentified-contract-73ffvqbzsk)。

![](/image/blog/rcv3n.png)

#### Mint NFT

回到 Remix，可以看到 Deployed Contracts 中已經有我們剛才發布的智能合約，點開他之後可以看到裡面有一個 mint 的 Function，現在我們就可以調用這個 Function 來 Mint NFT 了。這個 mint function 需要傳入四個參數，分別是`擁有者地址`，`token id`，`發行數量`和`附加數據`。附加數據在 ERC1155 規範中並沒有指定用途，因此這個參數可以根據自己的需要來傳遞任何數據，如果沒有的話傳遞空值即可。

![](/image/blog/5bytu.png)

![](/image/blog/kkkmu.png)

當 mint 完成後，稍等一段時間便可以在 [OpenSea 中看到對應的 NFT](https://testnets.opensea.io/collection/unidentified-contract-73ffvqbzsk) 已經誕生了！

![](/image/blog/jzair.png)
 
到這裡其實我們已經完成了一個最基本的 NFT 的建立。

如果你是照抄我上面的例子😏，你 mint 出的 NFT 應該已經有圖案，名稱了。但你可能會問假如我要改 token 的名稱，圖像，屬性要怎麼做呢？

原來 NFT 對應的圖像以及其他屬性是由 NFT 的 Metadata 決定，要想 NFT 在 OpenSea 等平台 中顯示圖像和其他屬性，還需要指定該 NFT 的 Metadata。

我上面的例子之所以會有圖像，因為  `https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json` 這個地址會對應傳入的 `token id` 返回該 token 的 metadata，  而裡面則包括了 token 的圖像，名稱，描述等資料。

#### ERC721 Metadata

根據 OpenSea 上的 [Metadata 標準](https://docs.opensea.io/docs/metadata-standards)，OpenSea 會調用我們智能合約中的 `uri`  function，並傳入 tokenID，而這個 function 需要返回一個 HTTP 或 IPFS URL，這個 URL 則必須返回一個 JSON 格式的數據，例如[我例子中的這個](https://api.frank.hk/api/nft/demo/1155/marvel/1.json)，而這個 JSON 則定義了我們 NFT 的各種屬性。

![](/image/blog/uiaaw.png)

![](/image/blog/df4uq.png)

用我們上面寫的智能合約為例，留意我們在 constructor 中有如下寫法：

```js
constructor() ERC1155PresetMinterPauser( "https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json") {
    ...
}
```

其中 `https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json` 便是指定了我們 token 的 URI，當調用 `uri`  function 時，我們的合約就會 return `https://api.frank.hk/api/nft/demo/1155/marvel/{id}.json`。`{id}` 是一個「變數」， NFT 市場會將這個變數替換為對應的 token id 。

當這個 Metadata 設置好後，再 mint 出的 NFT 就會帶有圖像等屬性了。

![](/image/blog/nhhyf.png)


上面說過， ERC1155 和 ERC721 最大的不同，就是 ERC1155 可同時支援可替換代幣(同質化代幣)和不可替換代幣(非同質化代幣)，這點我們可以在 OpenSea 中清楚的看到。

![](/image/blog/zg8rf.png)

上面這個例子，因為 Iron Man 這個 token ， mint 時發行量輸入了 5 ， 而 Thor 這個 token 發行量僅為 1，所以我們看到 OpenSea 上的顯示會有不同。Thor 的顯示，則和 ERC721 的 NFT 類似。

在出售的時候，也會多出了數量選擇。

![](/image/blog/gatdv.png)


以上就是一個超級簡單的自己寫代碼製作 ERC1155 NFT 的教學了。如果有任何討論，或是錯誤指正，歡迎聯絡我不吝賜教。

感謝閱讀。



ERC1155 是 ERC721 的升級版，ERC721 和 ERC1155有什麼不同？如何用代碼快速寫一個屬於你自己的 ERC1155 NFT 智能合約並發佈到 OpenSea 上？進來看一看吧。

使用 Remix，OpenZeppelin 15 分鐘建立 NFT ERC 1155 智能合約



最近有留意一些 NFT 的項目專案，發現絕大多數都是採用了「盲盒模式」來玩，即購買的時候並不知道裡面是什麼，等到了一定的時間後，盲盒會開啟，才會知道你買的 NFT 具體的屬性，是否稀有等。

![MekaVerse 盲盒](/image/blog/xzyot.png)

這裏我們不討論 Marketing 的做法，純粹從技術角度探討一下「盲盒模式」要怎麼做到。

我<Link href="/blog/nft-smart-contract">之前寫過一篇文章</Link>講怎樣輕鬆編寫 ERC 721 智能合約，裡面有說過 NFT 在 OpenSea 等市場中顯示的名稱，圖像，屬性等資料，完全是由 NFT 的 metadata 決定，而 metadata 則是靠調用 NFT 智能合約中的 `tokenURI` function 而得到。因此，這個 metadata 並不是像大家想像的一樣不可更改，只要能夠讓智能合約返回不同的 `tokenURI`, 則在市場中顯示的圖像以及屬性就會隨之更改。

聰明的你可能想到，如果 `tokenURI` 是一個 http 連接，即 metadata 是存放在傳統伺服器中，則非常容易做到這個效果。只要修改伺服器程式，返回完全不同的 metadata 即可。沒錯，但如果 `tokenURI` 是一條 IPFS 連結，那要如何處理？ IPFS 不是不可更改嗎？ 哈哈，是的 IPFS 連結是不能更改，但是 `tokenURI` 可以呀。只要對智能合約的代碼做一點更改，便可以輕鬆做到效果。

我們的大概思路是，有一個開關參數控制盲盒開啟與否，如果 true，則 `tokenURI` 將返回一條盲盒專用的 metadata IPFS 連結，裡面的 name，image 等都是固定的名稱和圖像。另外我們還需要有兩個 function ，供授權的地址調用，一個用以改變上述開關參數的狀態，另一個用以設定盲盒開啟後新的 `baseURI`。等到開啟盲盒的神聖日子來臨，被授權的地址調用這兩個 function，即可揭開盲盒的神秘面紗。

(當然，聰明的你也應該想到，不使用開關參數，完全依靠更改`baseURI` 也是可以的。只是我覺得有個開關更容易操作一些)

以下是參考的代碼：

```bash
abstract contract BaseERC721BlindBox is BaseERC721 {
    using Strings for uint256;
    bool private _blindBoxOpened = false;
    string private _blindTokenURI =
        "ipfs://QmexqcLDvoP6HCTtSGumG3yzhZdH8guvV3z3kReCvf2QKn";

    function _isBlindBoxOpened() internal view returns (bool) {
        return _blindBoxOpened;
    }

    function setBlindBoxOpened(bool _status) public {
        require(
            hasRole(DEFAULT_ADMIN_ROLE, _msgSender()),
            "BaseERC721BlindBox: only admin can do this action"
        );
        _blindBoxOpened = _status;
    }

    // this function controls how the token URI is constructed
    function tokenURI(uint256 tokenId)
        public
        view
        virtual
        override
        returns (string memory)
    {
        require(
            _exists(tokenId),
            "ERC721Metadata: URI query for nonexistent token"
        );

        if (_blindBoxOpened) {
            string memory baseURI = _baseURI();
            return
                bytes(baseURI).length > 0
                    ? string(
                        abi.encodePacked(baseURI, tokenId.toString(), ".json")
                    )
                    : "";
        } else {
            return _blindTokenURI;
        }
    }
}
```

當盲盒沒有開啟時，進入 OpenSea 看到的會是[這樣](https://testnets.opensea.io/collection/cute-marvel-characters-v3)：
![](/image/blog/1wyst.png)

當盲盒開啟後，進入 OpenSea 看到的會是[這樣](https://testnets.opensea.io/collection/cute-marvel-characters-v4)：
![](/image/blog/gqqyq.png)


最近 NFT 很火爆，留意到絕大多數 NFT 項目專案都是採用了「盲盒模式」來玩，即購買的時候並不知道裡面是什麼，等到了一定的時間後，盲盒會開啟，才會知道你買的 NFT 具體的屬性，是否稀有等。本文純粹從技術角度探討一下「盲盒模式」要怎麼做到。

Smart Contract 智能合約玩轉 NFT 盲盒模式


OpenSea 是目前最大的 NFT 交易平台，就宛如現實世界中的 Amazon ， 淘寶網一樣。如果嘗試過在 OpenSea 中出售自己擁有的 NFT，估計你都會有印象，前後要經歷 3 次和 MetaMask 的「互動」， 可是你究竟是否了解這三次「互動」究竟是在做什麼？


## 上架 NFT

下面的影片，展示了在 OpenSea 上架的過程：



<div class="video-container" style={{paddingTop: "58%"}}>
<iframe
  src="https://player.cloudinary.com/embed/?cloud_name=dxuoive6n&public_id=UD/sell-nft-from-opensea_u7lljb&fluid=true&controls=true&source_types%5B0%5D=mp4"
  allow="autoplay; fullscreen; encrypted-media; picture-in-picture"
  allowfullscreen
  frameborder="0"
></iframe>
</div>

 
我們可以看到，過程中前後需要經歷 Initialize Wallet ，Approve Token，Confirm Listing 三個步驟，這三個步驟分別是在做什麼呢？


### Initialize Wallet


![](/image/blog/8ppkh.png)

我們可以從 MetaMask 中看到，所謂 Initialize Wallet， 其實是調用 OpenSea 上的「Proxy Registry」裡的一個 「Register Proxy」的 function。 從 [Etherscan](https://rinkeby.etherscan.io/tx/0x8c1563f458fc484d76e7e0b1926752c8d187ddad526f1711f5b886be18936233#internal) 上可以看到，這個 function 建立並部署了一個新的智能合約 `0x...548c`，也就是所謂的 Proxy 合約。

根據 OpenSea 的說明：「On OpenSea, each user has a "proxy" account that they control, and is ultimately called by the marketplace contracts to trade their items.」得知，每一個 OpenSea 賬戶， 都會有一個 Proxy 合約與之對應，因此如果是一個全新的賬戶，就必須要經過這個「部署 Proxy 合約」的步驟，但如果已經擁有了 Proxy 合約，則下次上架 NFT 就不需要再次部署了。

因為這個操作需要改寫區塊鏈的數據，因此需要支付礦工費。另外因為需要進行合約部署，礦工費用也會相較其他操作更貴。


### Approve Token

![](/image/blog/ynwsz.png)

Approve Token 則比較容易理解。有沒有想過你擁有的 NFT，為什麼 OpenSea 能夠代你賣給別人？它哪裡來的權力呢？答案就是這個步驟，我們看到這個 Approve Token 其實是調用了「Set Approval For All」function， 透過查看ERC721原始碼發現，這個 Set Approval For All ， 其實就是一個授權操作，一旦授權，被授權的地址將可以調用 transferFrom 將 NFT 的擁有權轉移到另一個地址。

![](/image/blog/nkspk.png)

從 [Etherscan](https://rinkeby.etherscan.io/tx/0x9cf04947041e4b081aa2edcab3cfc8cba9cbdaf48d2bcfb0d3ed787b73fbf2f1) 上看到，這個授權操作傳入了一個被授權地址，`0x...548c` ，而這個地址，正正是上面第一步「Initialize Wallet」時新建立的合約地址，也就是說，這一部完成後，你作為 NFT 的擁有者，便授權了`0x...548c` 這個合約可以轉移你的 NFT 資產。

因為這個操作也需要改寫區塊鏈的數據，因此也是需要支付礦工費的。

### Confirm Listing

![](/image/blog/mkhge.png)

最後一步 Confirm Listing， 則最為簡單，這個操作並沒有改寫任何區塊鏈的內容，因此不需要支付任何費用。這個操作是使用你的私鑰簽名一段信息，用以讓 OpenSea 認證你的身份，確認「你是你」，認證成功後才會代你進行上架操作。


## 購買 NFT

對比上架 NFT， 購買 NFT 則相對簡單。即便是新的帳戶，亦不需要太多的步驟。

![](/image/blog/kpjli.png)

購買的操作，調用了 OpenSea 交易所合約中的 「atomic match」function，這個 function 最後會做幾件事：

1. 轉帳該筆金額的 97.5% 給NFT 原擁有者；
2. 轉帳該筆金額的 2.5% 給 OpenSea；
3. 透過上面的 proxy 合約，調用 NFT 合約的 `transferFrom` function，轉移 NFT；

![](/image/blog/uiwpy.png)

至此，一個 NFT 的交易便完成了。 

透過查看 Etherscan 不難發現，OpenSea 背後使用的是 [Wyvern Protocol](https://wyvernprotocol.com/)  ， 這是一個基於以太坊的開放協議，用以交易虛擬資產。網上似乎並沒有太多的關於這個協議的資料。以後有時間再研究一下。

![](/image/blog/nqtrw.png)

 


OpenSea 是目前最大的 NFT 交易平台，就宛如現實世界中的 Amazon ， 淘寶網一樣。如果嘗試過在 OpenSea 中出售自己擁有的 NFT，估計你都會有印象，前後要經歷 3 次和 MetaMask 的「互動」， 可是你究竟是否了解這三次「互動」究竟是在做什麼？

OpenSea 簡易運作原理



以太坊的智能合約程式一旦發佈便無法更改，因此程式的安全性尤為重要。因此，使用檢測工具對程式碼進行檢測，可以發現一些常見的安全隱患，避免因程式漏洞引致的各種損失。

![Slither](/image/blog/ps5gm.png)

Slither 是一個用 Python 編寫的 Solidity 的「靜態」檢測工具，可以偵測常見的 Solidity 程式漏洞。其功能包括：

- 檢測 Solidity的常見程式漏洞，誤報率低；
- 標識錯誤在源程式中發生的位置；
- 可以集成到 CICD 中使用；
- 正確解析 99.9% 的所有公共 Solidity 程式；
- 掃描速度快，每個智能合約平均執行時間少於 1 秒；

### 安裝

[官網](https://github.com/crytic/slither#how-to-install)提供了多種安裝方式，因為考慮到有太多的依賴和開發環境設定，作為一個懶人，本人認為用 docker 方式安裝會最方便，因此本文就以 docker 安裝來舉例，其他安裝方式可以查閱[官網](https://github.com/crytic/slither#how-to-install)的說明。

安裝 docker image：

```bash
docker pull trailofbits/eth-security-toolbox
```

安裝 docker image 之後就可以運行 slither 了，但要記得指定 docker 共享 volume，這樣才可以在 docker 容器內訪問到電腦中的檔案：

```bash
docker run -it -v /your/share/folder:/share trailofbits/eth-security-toolbox
```

執行上述指令後便進入了 slither 的 container 中：

![](/image/blog/e69g4.png)

###  檢查 solc 版本

這裡要注意，因為 solidity 有很多不同的版本，掃描時最好根據要掃描的 solidity 檔案指定對應版本的 solc 編譯器。而預設的 image 中未必有你想要的 solc 編譯器版本，你可以在 container 內運行以下指令，可以查看已經安裝的 `solc`  編譯器：

```bash
solc-select -l
```

如果發現沒有安裝對應的 solc 版本，則需要先安裝 solc 後再繼續。

```bash
# 將下面的 v0.4.15 更改為你所需要的版本

curl -L https://github.com/ethereum/solidity/releases/download/v0.4.15/solc-static-linux --output solc-v0.4.15

sudo mv ./solc-v0.4.15 /usr/bin/

chmod +x /usr/bin/solc-v0.4.15
```

### 掃描本地 sol 檔案

因為共享了共享目錄，我們在 container 就可以直接運行 slither 指令：

```bash
slither path_to_your_contract.sol --solc /usr/bin/solc-v0.4.15 
```

其中 `path_to_your_contract.sol` 是你要掃描的 solidity 檔案， `--solc /usr/bin/solc-v0.4.15` 則是指定 solc 編譯器的版本。

![](/image/blog/mwo8l.png)

如上圖所示， slither 會在熒幕上顯示出掃描結果。根據問題的嚴重程度，會有不同的顏色表示。同時亦會給出問題的解釋，可以點開相應的連結查看。

如果想要將掃描結果以 json 形式輸出到檔案中，可以執行：

```bash
slither path_to_your_contract.sol --solc /usr/bin/solc-v0.4.15 --json result.json
```


如果你的智能合約中使用了類似 `import @openzeppelin/xxx` 等的以 “@” 開頭的 import 語句，可能會出現  File not found 的錯誤：

```bash
Error: Source "@openzeppelin/contracts/utils/Counters.sol" not found: File not found.
  --> /src/contracts/BaseERC721.sol:12:1:
   |
12 | import "@openzeppelin/contracts/utils/Counters.sol";
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

解決方法是需要指定 `--solc-remaps` 來告訴編譯器 openzeppelin 的具體位置：

```bash

slither path_to_your_contract.sol --solc /usr/bin/solc-v0.4.15 --solc-remaps @openzeppelin/=/src/node_modules/@openzeppelin/

```


### 掃描已經發佈的合約

slither 亦支援掃描已經將原始碼發佈到 etherscan 上的合約， 運行：

```bash
# 0x7F37f78cBD74481E593F9C737776F7113d76B315 是合約地址。
slither 0x7F37f78cBD74481E593F9C737776F7113d76B315

# 若是 testnet 網絡，地址前加上網絡名稱
slither rinkeby:0x7F37f78cBD74481E593F9C737776F7113d76B315
```

如果運行出現錯誤，可能是 solc 版本不相符， 使用 `solc-select` 切換到對應版本後再運行即可。如果對應版本沒有安裝，請參考上一節的做法安裝即可。







以太坊的智能合約程式一旦發佈便無法更改，因此程式的安全性尤為重要。因此，使用檢測工具對程式碼進行檢測，可以發現一些常見的安全隱患，避免因程式漏洞引致的各種損失。本文介紹使用 Slither 這個工具來進行 Solidity 檢測。

使用 Slither 來檢測你的 Solidity 智能合約程式碼


我承認是有點標題黨的味道，而且好像還有濃濃的「騙案」味道，到底是不是呢？

Axie Infinity， 是目前非常非常火爆的一款 NFT 遊戲。 其火爆程度，從 coinmarketcap 上的數據來看，任何一個類別都是穩坐 NFT 類別下的第一把交椅。

![](/image/blog/oj8wx.png)

所謂 NFT 遊戲，可以這麼理解，就是平時我們玩的普通遊戲，但是裡面的遊戲角色，遊戲道具，都是儲存在區塊鏈上，以 NFT (一種不可複製，獨一無二的區塊鏈代幣) 形式存在。 Axie Infinity 的遊戲方式其實和普通的手機卡牌類遊戲很類似，例如 Clash Royale 皇室戰爭， 都是有角色，技能之分。 每一場遊戲大約 3-5分鐘，你和一名隨機匹配的玩家進行對戰，利用各自不同的角色，不同的技能，贏得比賽。

![每個 Axie 都有不同的技能屬性](/image/blog/oausw.png)

### 真金白銀獲取收益

聽上去似乎很無聊？ 但這個遊戲的吸引人的地方，在於遊戲中會有一種遊戲代幣獎勵， SLP。**而這個 SLP，是可以兌換為真金白銀的現金**。

![SLP 當日價格](/image/blog/47x0e.png)

每當贏得比賽，或者每日簽到，完成每日探險任務，都會獲得 SLP 的獎勵，如果完成每天的遊戲任務，再贏得幾場對戰勝利，每日獲取 100 - 150 SLP 不是一件困難的事情， 根據撰文當天的價格 1 SLP = 0.20 USD ，即一日可以賺取 20-30 USD，一個月下來就會賺取 600-900USD，兌換成港幣即7000元左右。

### 入場費

這麼好賺？ 但，這個遊戲的入場費也不低。目前比較正常的遊戲角色，Axie，售價都在 0.1ETH 以上（撰文當天，Axie 的售價因為昨日公佈的遊戲獎勵規則改動有所下跌），若是比較好的 Axie，售價更是驚人。因為要開始遊戲，必須有至少 3 隻 Axie 才能組成一個戰隊， 所以至少要投入 0.3 ETH，按照現在的 ETH 價格，即將近1000美金，才能入場。

![](/image/blog/ivrpn.png)

### 收益模式
有了 Axie 戰隊，便可以開始開始透過「玩遊戲賺錢」了。 

遊戲有每日任務，目前的任務是每日簽到，完成一定量的「冒險」關卡，贏得5場 PvP 對戰，就可以獲得 75 SLP（之前是150SLP，撰文前一天改變了規則）。隨著你獎杯數量的增加，PvP 對戰每次獲勝會獲得更多的獎勵，一天獲取大約 100-130 SLP 是完全可以實現的。

除了透過每天花費約 2-3 小時完成任務，打 PvP 對戰獲得 SLP 獎勵， 要知道遊戲中的角色，Axie，本質是 NFT 代幣，所以是可以隨時交易的，而且，兩隻 Axie 可以繁殖最多 7 個寶寶（當然繁殖也是要付出成本的，但基本會比購買成年 Axie 便宜）。生下的寶寶也可以拿去售賣。


### 獎學金計劃
可能你會覺得，每天投入 2-3 小時比較奢侈，時間成本不划算。 好消息是，Axie 社群中有一個「獎學金計劃」，即「Manager」負責投資購買 Axie，然後招募「Scholar」來每日操作遊戲，贏得的 SLP 按照約定的比例分成。這樣就很好的將「有錢沒時間」和「沒錢有時間」的人，組合在一起，大家各取所需。 作為 「Manager」只需要出資購買 3隻 Axie，然後就可以將賬號 QR Code 分享給 「Scholar」，「Scholar」就可以進入遊戲賺取收益。

「Manager」作為「投資方」，掌握著區塊鏈錢包的秘鑰，擁有 NFT 的所有權，因此就算將遊戲登陸賬號(QR Code) 分享給「Scholar」，「Scholar」也無法進行任何對 Axie 的轉移，生育， SLP 提取等操作，當然這要求「Manager」一定要有誠信，在約定的時間要按時支付「Scholar」獲取的收益。

因為疫情原因，東南亞地區有大量的貧窮人口缺乏收入，所以 Axie 社群中有大量的 「Scholar」都在想盡一切辦法尋找「Manager」，要知道遊戲收入，基本上已經是發展中國家一個中等收入的在職人士的月薪了。這款 NFT 遊戲，變相也在為這些疫情期間受到嚴重衝擊的國家人民帶來了不少經濟上的收入。

![在官方 Discord 群組中有大量尋找 Manager 的人。](/image/blog/0pomu.png)

### 關於 NFT
NFT 的熱度一直是有增無減。我本人直至今日都不是很能夠理解類似 CryptoPunks 這種「沒有實際用途」的 NFT 除了炒賣之外的價值何在。
![](/image/blog/obgm2.png)
相比之下遊戲道具類的 NFT 就更容易理解，各種遊戲裝備透過 NFT 的形式出現，更接近新式生活中人們對物件的買賣，因此這種模式似乎更有「實際用途」。買到好的遊戲角色，則更容易在戰鬥中獲勝，從而贏取更高的回報。


Axie Infinity， 是目前非常非常火爆的一款 NFT 遊戲。 其火爆程度，從 coinmarketcap 上的數據來看，任何一個類別都是穩坐 NFT 類別下的第一把交椅。 通過玩遊戲，就能夠月入七千，到底靠不靠譜？

玩遊戲月入七千？ Axie Infinity

當我們逐漸邁向 Web3.0 的今天，原本的網站登入需要透過用戶名密碼的方式，現在又多了一個選擇。只要有一個數字貨幣錢包，便可以使用這個錢包作為身分認證的方式，完全不需要記住複雜的用戶名和密碼。本文將介紹和示範整個使用 MetaMask 錢包登入系統的流程。

使用 MetaMask 登入第三方網站

NTF 最近是街頭巷尾都在討論。本文將站在技術角度，教一教大家怎樣用代碼寫一個屬於你自己的 NFT 智能合約。

使用 Remix，OpenZeppelin 15 分鐘建立 NFT 智能合約

IPFS 是最近討論非常多的話題，經過自己嘗試，加上資料整理，本文用問答的形式來簡單介紹一下 IFPS 這個東西。

IPFS 問與答




IPFS 是一個非常科幻的檔案存儲系統。 如果想了解什麼是 IPFS，可參考這篇文章：<Link href="/blog/ipfs-q-and-a">IPFS 問與答</Link>

如果你有一台裝有 Docker 的伺服器，可以很方便的安裝 IPFS ，使你的伺服器變為 IPFS 中的一個節點。

IPFS 官方有提供 Docker 的[安裝指引](https://hub.docker.com/r/ipfs/go-ipfs/)， 我這裡將它變為 docker-compose 更容易操作一些。
### 步驟一
建立一個 docker-compose.yml 檔案，內容如下：
```bash
version: '3'
services:
  ipfs:
    image: ipfs/go-ipfs:latest
    container_name: ipfs_host
    volumes:
      - ./export:/export
      - ./ipfs_data:/data/ipfs
    ports:
      - '4001:4001'
      - '4001:4001/udp'
      - '127.0.0.1:8080:8080'
      - '127.0.0.1:5001:5001'
```
其中 5001 port 為 API 以及 WEB UI，8080 為 Proxy Gateway。 具體內容可以參閱官方網站詳細了解。
### 步驟二
確認伺服器已經安裝 docker， docker-compose ，在相同路徑下執行：
```bash
docker-compose up
```
即可。
### 步驟三
當 docker-compose up 成功啟動後，訪問瀏覽器 `localhost:5001/webui` 
即可開啟 WEB 界面：
![IFPS Web 管理界面](/image/blog/qsy1f.png)
在 WebUI 界面中可以看到你當前的節點的狀態，連接到了多少 peers，你也可以方便的在 WebUI 中添加檔案到 IPFS 中。

![](/image/blog/s09nn.png) 

### 可能遇到的問題 1
我第一次安裝時遇到了 WebUI 無響應的情況，即 127.0.0.1:5001/webui 無法開啟，半天沒有反應。查看 log 後發現因為我們使用 Docker 的形式安裝，而我的Docker Network 設定使得位於 Docker Container 內的 IPFS Deamon 無法連接 peers 導致。 解決這個問題，需要查看 Docker Container 的網絡設定：

```bash
docker inspect < your docker container id or name>
```

你會看到 Container 位於  172.19.0.0 subnet：

```bash
"IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.19.0.0/16",
                    "Gateway": "172.19.0.1"
                }
            ]
        },
```

因此需要添加 firewall rules 允許網絡連接：

```bash
firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=172.19.0.0/16 accept'

firewall-cmd --zone=public --add-masquerade --permanent

firewall-cmd --reload
```

### 可能遇到的問題 2

打開 WebUI 界面後，可能出現無法連接 API 的情況：
![](/image/blog/l8f0t.png)

這個是因為 API 跨域訪問限制導致，按照界面提示添加對應的 rules 即可：

```bash
docker exec ipfs_host ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://www.yourdomain.com:5001","https://www.yourdomain.com","https://www.yourdomain.com","http://localhost:3000", "http://127.0.0.1:5001", "https://webui.ipfs.io"]'
[root@LS-820311-4279 ipfs]# docker exec ipfs_host ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "POST"]'
```



IPFS 一個嶄新，自由，分佈式的檔案系統，安裝一個 IPFS 節點其實非常簡單，本文介紹用 Docker 的方式安裝 IPFS 節點，在 15 分鐘內即可完成。

用 Docker 安裝 IPFS



 
<FireWorks/>
 


<h3>換域名啦！</h3>

![](/image/blog/wznip.png)

終於可以用 frank.hk 這個域名。 早前註冊域名的時候， 發現 frank.hk 被一個乒乓球網站註冊了，於是只好註冊 franks.hk ，就這樣走過好多年。終於最近等到 frank.hk 被釋放，連續觀察了很久，由域名被 black out 開始每天都留意著，終於如願。

這次域名註冊使用的是 [UDomain](https://www.udomain.com/zh/main/index.php)， 操作簡單快捷，比 HKDNR 註冊的體驗要好幾條街。（我之前用 HKDNR 註冊，那個網站的 UX 簡直慘不忍睹。）註冊後很快就生效，這樣就有了新的域名啦！

新域名新開始，希望今後能多多更新網誌，記錄生活，分享經驗。



等了好多年，終於可以註冊到 frank.hk 的域名。超開心的！😙

更換域名



![](/image/blog/lhm9m.png)

# epub vs kepub

使用 kobo 一段時間後，常會遇到一個使用場景就是將其它地方獲得的 epub 檔案傳送到 kobo  中閱讀，很長一段時間我都是直接將 epub 檔案透過 dropbox  同步到 kobo 中，但經常會遇到一些問題：

- 第一次打開新傳入的 epub 檔案，經常會遇到開啟速度非常慢，看不到封面畫面，甚至一开启就發生「宕機」的情況；
- 無法更改 epub 檔案的行距。儘管在字型設定中有行距的選項，但是調節後其實不起任何作用；
- 沒有類似在 kobo 商店中直接購買的書籍的進階統計功能；
- 休眠模式下沒有剩餘閱讀時間統計；
- 頁數統計不是很準確，有時候讀幾頁後下方的頁數才增加一頁；

上面的問題我原本以為沒有辦法解決，這個可能是 kobo 商店中直接購買的書籍的先天優勢，所以也就慢慢習慣忍耐。但直到今天才發現，原來 kobo 的原生檔案格式是 kepub ，也就是一種針對 kobo 閱讀器特別優化處理的 epub 檔案。而嘗試了將之前的 epub 轉換為 kepub 之後， 驚喜的發現所有問題都解決了！！幾次嘗試後，發現 kepub 的檔案有如下優點：

- 快，非常的快。上面提到 epub 首次閱讀時的緩慢，無封面，「宕機」等情況完美解決，kepub 檔案封面會瞬間顯示，打開速度也非常迅速，多次嘗試完全沒有遇到「宕機」的情況；
- 行距可以完美調整；
- 按住左下角螢幕可以開啟快速翻頁功能；
- 有進階統計功能；
- 休眠模式下有剩餘閱讀時間統計；
- 非常準確的頁數統計；
- 更快的觸摸響應；
- 針對書內圖片可以雙擊放大；

![ePub vs kepub](/image/blog/owtaj.png)



# 如何將 epub 轉換為 kepub

將 epub 轉換為 kepub，有很多方法，我這裡推薦的是使用 [kepubify](https://pgaskin.net/kepubify/) 。Window 系統直接到官網下載，Mac 系統除了去官網下載，也可以使用 homebrew 快速安裝：

```bash
brew install kepubify
```

這個工具的使用是透過命令行模式執行，打開你電腦上的命令行工具，以 Mac 為例，打開 Terminal 程式，即可使用 `kepubify` 命令進行轉換：

```bash
kepubify -v /path/to/your/epub.epub
```

例子：

```bash
frank@Macbook ~ % kepubify -v 遠方的微笑.epub
Kepubify 3.1.4

[  1/  1] Converting 遠方的微笑.epub
          => 遠方的微笑_converted.kepub.epub

1 total: 1 converted, 0 copied, 0 skipped, 0 errored
frank@Macbook ~ %
```

這樣，在同一目錄下就會有一個  xxx.kepub.epub 的檔案，這個檔案就是 kepub 啦。**特別要留意的是，檔案的後綴名一定要是 .kepub.epub ，不可以做任何更改。刪除了 .kepub 或者 .epub 都可能另檔案無法識別為 kepub 檔案**。

將 xxx.kepub.epub 這個檔案傳輸到你的 kobo 中就可以享受 kepub 的體驗啦。


kobo 用家過來看！epub 和 kepub 有什麼不同？原來 kepub 竟然有這麼多優點！趕快把 epub 轉換為 kepub ，在你的 kobo 中享受更好的閱讀體驗吧。

epub vs kepub 有何不同？如何轉換


我是一個有條理的人嗎？某種程度上或許吧。但至少還遠未達到自己心目中的理想標準。最近一直待在家中，多了很多很多安靜的獨處的時間，讀到一些關於自我管理的書，也看了一些這方面的 Youtube 頻道影片，越來越認同自我管理，條理生活的重要性。鑑於此，自己也嘗試著學習提升一下自我管理，讓生活更有條理的技能。這篇文章，也算是將一些學到的心得做一個總結。

## 不要太相信自己的記憶能力

生活就是由大大小小各種不同的事情來組成，所以說有條理的前提，首先就是要確保不要遺漏事情，特別是重要的事情。但，人的大腦不是電腦，總會遺忘。所以第一個重點就是不要依靠大腦來存儲事情，而是要靠其它的媒介來儲存各種生活中的事情或重要資訊。而這個媒介，必須符合以下幾個要求：

- 易於獲取，即隨時隨地可以接觸到；
- 值得信任，你要放心把資料記錄在上面；
- 不會丟失，確保不會有一天你含著眼淚發現所有資料不見了；

我從很早前就使用 Evernote 來記錄生活中大大小小的瑣事，這個習慣一直延續到今天。我也曾經嘗試過用紙本筆記本來記錄一些事情，但畢竟紙本筆記本不能總是隨身攜帶，而且亦不便永久保存。

## 花時間去做計劃

若要想生活變得更加條理，做計劃是非常重要的。有人可能會反駁說「我就是一個隨性的人」，但其實有沒有想過，「隨性」，也免不了計劃。舉例說你突然想去吃一頓大餐，這個「想」，其實你已經在計劃了，只是提早多少時間計劃而已。做計劃的時候，往往會將一些自己「隨性」的時候不大會做的事情提上議程，舉我自己的例子，如果我不去做計劃，我「隨性」的時候斷然不會突然想去跑 5 公里，不會突然抽時間來整理抽屜，不會突然坐在電腦前寫現在這篇文章。做計劃的時候，也會不知不覺的讓生活變得更加高效。

做計劃，必須要有一個完整，安靜的時間。要靜下心來思考，怎樣對未來的自己發號施令。這時候可以參考艾森豪威爾決策法則，將事情根據重要性和緊急度來區分輕重緩急。當你手握大權，可以指揮未來的自己時，也請手下留情，計劃不能太苛刻，要可被執行，否則未來的自己執行起來就會像老闆要你加班拼命完成 mission impossible 時你的心態。

![圖片來源： https://j.mp/2Gb0Jxc](/image/blog/mdi6u.png)

另外，做計劃的時候，最好將類似的事情盡量放在一起，因為當大腦從一個 task 轉到另一個 task 是需要時間來進行適應的，如果將性質類似的 task 放在一起，大腦會更加順暢的無縫過渡，從而提高效率。舉例來說，如果你計劃明天要讀書，買菜，寫文章，洗衣，收拾房間，那不妨就將寫文章和讀書放在一個相鄰的位置，洗衣，買菜，收拾房間放在另一個相鄰位置

## 設計適合你的計劃系統

做計劃的方式多種多樣，沒有一個固定的答案說要怎樣計劃。最近很流行的「Bullet Journal 」，是一個美國設計師 Ryder Carroll 創立的筆記法，裡面有很詳細的內容格式，例如索引頁，未來規劃表，月計劃，日計劃等等。雖說這個 Bullet Journal 有它的優點，但就我自己目前而言我覺得這種計劃系統不是太適合我。我甚至覺得這種筆記法「形式大於內容」，可能更適合 show 給別人看而不是幫助自己計劃生活。網上可以找到很多非常有文藝風格的 Bullet Journal ，對我而言我覺得要製作出這樣的內容要花費大量的時間，因此很難持之以恆。

![Bullet Journal 例子 圖片來源：Unsplash @mattragland ](/image/blog/6xlba.png)



我自己比較喜歡的方式，是簡單的使用 Todo List 應用程式。因為我自己是 App 控，因此 Todo List 類的 App 試過不少，最初的 Evernote， 到專門的待辦清單 App 如 Wunder List， Any.do，Trello，Sorted， 2Do，Todoist 等等，基本都使用過它們的付費版。但總是覺得或多或少有缺憾。直到後來發現了 TickTick ，這個 Todo List App 探索之旅才終於算可以暫時停止了。

![TickTick](/image/blog/tkaxe.png)



TickTick 作為一個 Todo List App，它基本囊括了之前很受歡迎的 Todoist 的基本所有功能，如清單分類，標籤，自定義過濾器，自然語言識別，成就系統， Apple Watch 支援等等，還支援類似 Trello 的 Kanban 視圖。而 TickTick 的另一個特點是，它還集合了習慣養成，番茄時鐘，行事曆等功能。這些功能集中在一起，已經足以勝任我的個人規劃系統。（工作上的計劃則有另外的程式來處理，之前是 Trello，現在則開始使用 ClickUp ）

我現在正在嘗試在前一天晚上睡覺前，花約摸 10-15 分鐘時間想想看第二天的待辦清單，並進行分類和優先次序編排，透過這個過程，我切實體驗到很多事情，如果你不去計劃，則永遠不會去做的道理。同時，我也是用 TickTick 的習慣養成功能，將一些要持續的習慣用它來追蹤，例如最睡早起，閱讀，飲水等等。在這樣的計劃系統下，我這幾個月的成效算是令人滿意，疫情期間最難堅持的運動，都能基本保證每週至少有 5 天的運動次數。

 不過，計劃系統這個真是因人而異，但我覺得幾個重點是：

- 簡單可行，自己喜歡和用著開心；
- 隨時可以接觸到（因此我選擇 App 而不用傳統筆記本，任何平台都可以輕易取得）；
- 安全，可信賴，不會丟失數據；

## 花時間去作總結

計劃，執行之後就是作總結。作總結的好處是，可以將一段時間的經歷，收穫 ，教訓，強化到大腦裡，並且留下永久的記錄。其實就算不作總結，經歷了一些事情之後，當下的自己也定然會有一些得著，有一些「如果來多一次我會怎樣」的想法。作總結，便是將這些想法更加精要的加以提煉。作總結的時候會思考，這個思考的過程無形中也是一個很好的自我提升的過程。人畢竟不是機器，大腦的記憶力有限，很多事情如果不做記錄，要不了多久就會徹底忘記。

上面說到的「Bullet Journal 」，也可以用來進行很好的總結，但我還是喜歡用 App 來完成這個工作。我目前使用的是「Grid Diary 格誌」，它會用問答的形式讓你填寫一些預設的問題，或是你自己設計的問題，從而能夠快速而且有目的的完成當日總結，不至於無話可說。你可以設定每日，每週，每月的不同問題模板，從而進行不同時期的總結。

![Grid Diary 格誌](/image/blog/wkvxw.png)

## Simple is Better，簡單有時候會很美

我當然不是極簡主義者，也不認同極簡主義，但簡單就是美，在某種程度上我也是非常同意的。將生活中一些雜亂事物整理好，將不必要的事或物去除，對讓生活更有條理，有很大的幫助。

將生活中一些雜亂事物整理好，最直接的例子就是我們的生活環境，比如我們的書桌，我們的臥室。在一個乾淨整潔的環境中，人們的心情會更容易正向發展，從而更加 Productive。雖說我自己的環境並不會很雜亂，但我也經常出現東西找不到，拉開抽屜東西亂成一團的情況。因此這一點我還在不斷學習提高中。好在身邊有很好的榜樣，對比之下就會產生動力。因此最近我準備制定計劃，定期就要強制整理一下自己的周邊起居環境。

除了現實世界中的東西，虛擬世界中的東西亦是如此。電腦的桌面，手機的 Apps，都符合相同的邏輯。舉例我手機的主畫面，之前我喜歡將所有常用 App 放在檔案夾中全部堆砌在主畫面，最近這段時間則嘗試在這些「常用 App」中再進行「斷捨離」，只留下最最常用的 App 放在主畫面。這樣一來驚奇的發現每次看手機心情都好了一些，因為不用每次多按幾次，不用再在一堆檔案夾中尋找 App，另外發現，其實手機中那麼多 App （ 我安裝了 905 個 App ），真正常用的其實並不多。

![手機的 Apps](/image/blog/lg2ly.png)

## 「15 分鐘法」對付拖延症

拖延也是有條理生活的一大對手，人不是機器，總會有一大堆的理由將一些原本要做的事情一直拖著不做。（ 我寫這篇文章亦是如此，拖足14天 ）。但我最近在一個 Youtube Channel 中看到了有人介紹一種 「15分鐘法」來對付拖延症，具體的做法是當你應該做一件事但又提不起精神或者想拖延的時候，不妨嘗試硬著頭皮做 15 分鐘，如果 15 分鐘後都依然覺得不想做，那就光明正大的允許自己改期。

這個方法的妙處在於，很多時候，一旦我們開始做一件事情，則代表已經跨過了最難的一關，一旦開始，便很容易的能夠繼續下去。就好像我寫這篇文章一樣，拖足 14 日，直到今晚 7 點，才硬著頭皮開始寫，但沒想到一旦坐下，便無法收手，一氣呵成。

## 重視健康

健康是一切的基石， 沒有了健康，一切都是空談。只可惜有時候我們唯有等失去了才知道珍惜。

直到現在我依然記得十幾年前有個無良醫生在沒有確切證據的情況下對我說我可能有非常嚴重的疾病，結果在等待進一步報告的那兩個星期，我宛如行屍走肉一般，感覺死亡即將降臨。那兩個星期我不斷回想自己生活中的壞習慣，並且立志如果化驗結果正常我一定要改掉生活中的壞習慣。結果最後證明只是普通的炎症，頓時感覺重生一般。

健康是最重要的資本，沒有了健康，再有錢再有地位都是空談。有些健康問題我們無法避免，但更多的健康問題我們完全可以透過改變生活壞習慣來避免。透支健康而換取其它回報，實在是最傻最傻的做法。

因此，要想生活更有條理，重視健康，養成更健康的生活習慣是重中之重。戒除煙酒，[充足的睡眠](https://www.frank.hk/blog/why-we-sleep)，多運動，吃的更健康一點，工作生活平衡，現在多注意一點，日後的你必將感激今天的你。


我是一個有條理的人嗎？某種程度上或許吧。但至少還遠未達到自己心目中的理想標準。最近一直待在家中，多了很多很多安靜的獨處的時間，讀到一些關於自我管理的書，也看了一些這方面的 Youtube 頻道影片，越來越認同自我管理，條理生活的重要性。鑑於此，自己也嘗試著學習提升一下自我管理，讓生活更有條理的技能。這篇文章，也算是將一些學到的心得做一個總結。

學會讓生活更有條理


寫這篇文章的靈感，要從一個 [Youtube 影片](https://www.youtube.com/watch?v=Q_PfYlAtvHc&t=44s)說起。話說大約一個月前，一次在跑步機上跑步時看到了一個 [Youtube 影片](https://www.youtube.com/watch?v=Q_PfYlAtvHc&t=44s)，光名字就很有煽動性：「**為什麼許多人都改用 Notion 做為主力筆記軟體？看完這個你就明白了**」。要知道我是筆記軟件鼻祖 Evernote 的重度用家，從 2009 年 6 月開始到現在已經使用了超過 11 年，因此這個影片很成功的吸引到我的注意。影片介紹了一款名為 「Notion」的軟件，用很多實用例子介紹 Notion 的優點。坦白說在看的過程中真的是有被「驚艷」到，發現 Notion 不僅基本做到 Evernote 的大多數功能， 而且增加了很多實用的功能，例如筆記的排列方式，筆記的封面，Icon，排版，Markdown支援，甚至最強大的「資料庫」功能，能夠讓筆記發生關聯，甚至進行類似 Excel 的公式運算。這些功能讓 Notion 看起來似乎就是一個值得被膜拜的「神器」。

正式因為這個影片的吸引，我隨後立即開始研究 Notion，除了大量的對 Notion 的讚賞文章之外，發現網路上還有一堆的關於「離開 Evernote，擁抱 Notion」的討論。

![](/image/blog/tnyio.png)

![網上很多人都由 Evernote 轉投 Notion](/image/blog/7zd3g.png)

對於 Evernote 的不滿，主要是因為 Evernote 團隊的「緩慢」和「不進取」。App 很久都沒有更新，對於呼聲眾多的功能，例如 Markdown 支援，熒光筆的不同顏色，筆記的內部連結等等這些看起來非常簡單的功能，幾年過後都沒有理會。反觀 Evernote 的中國版「[印象筆記](https://www.yinxiang.com/)」，原本和 Evernote 國際版是基於同一個 Code Base，但現在印象筆記在功能上已經拋離 Evernote 幾條街，不僅上述呼聲最高的功能都早已實現，而且還逐漸加入類似 Notion 的「超級筆記」功能。因此有人甚至質疑 Evernote 已經逐漸沒落，最終可能退出市場。

看完這些「anti-Evernote」的資料後，我真的有被影響到，腦子裡萌生了「要不我也轉投 Notion 的懷抱？」的想法。要知道 Evernote 是我人生軟件清單中毋庸置疑的第一位，早在 2012 年，就寫過一片[關於 Evernote 的文章，介紹這個我心目中的最佳軟件。](https://www.frank.hk/blog/entry-1188) 正式因為如此，決定要離開 Evernote 當然不是一個容易的決定，這種情況就好像一邊是家中同舟共濟十幾年，略顯蒼老的伴侶，一邊是充滿新鮮感，充滿活力的新歡，而你要做出選擇一樣 😅。

可正如 Judy 所說：「習慣有時候緊要過功能」，究竟這個充滿新鮮感，充滿活力的新歡，到底適不適合你，這個還真的很難說。

於是我準備給自己一點時間試用一下 Notion，第一步是將 Evernote 中的資料遷移到 Notion 中。Notion 貼心(精明)地提供了 Import From Evernote 的功能， 這一步理論上應該不是很困難。但，事實上並不是如此。不知道是不是因為我的 Evernote 中的記錄實在太多，導入功能要麼就是無故終止，要麼就是導入的資料非常不完整。另外由於我的很多筆記中包含加密內容，即便成功導入後也無法看到原始資料。

另外，就是 UX，這個可能就是見仁見智的問題。Notion 同樣提供 Web， Desktop，手機的應用，但是感覺他們三者其實都是基於 Web 的應用，相比 Evernote 的 Native App 的體驗， Notion 在流暢性，無網絡下的使用都顯得差一些。另外，我自己覺得 Notion 的界面有很多的 「distraction」，比如輸入界面游標前的 + 號，有時候還真的覺得很煩人。

而且，我發現 Notion 的搜尋功能相比 Evernote 差很多，特別是對一些 Tag 的搜尋支援，非常不友好。很多時候無法快速，準確地搜尋到想要的資料。這個缺陷可謂致命。

總結起來，Notion 的缺點，或是說不能滿足我要求的地方是：

- 搜尋功能無法快速準確的找到想要的資料；
- Web App 沒有 Native App 的體驗好；
- 離線使用不方便；
- 不喜歡 Notion 左邊菜單欄的 UX；
- Web clipper，plug in，IFTTT 等周邊支援不夠；

一個月使用下來，我心目中已經逐漸清晰 Notion 和 Evernote 的不同定位。 Evernote 更像是大腦中的海馬迴，用於儲存記憶，生活中的各種零碎資料，比如拍下一些 Receipt，記錄一些偶爾看到的值得收藏的資訊，工作上的瑣事等等。而 Notion 因為其功能更加多樣化，而且有「資料庫」功能，可以做類似 Excel 的公式運算，則更像是大腦中的前額葉，適合用於做一些高層次而且需要處理的記錄，例如寫文章，做計劃，整理資料等。

所以現在可以放心的說，放棄 Evernote？不可能！使用 11 年後，Evernote 依然是我最喜歡的App。

Notion is awesome, but I still ❤️ Evernote 😙😙😙  most !!!


Notion 現在可謂是筆記軟件類的新星，身上充滿了各種光環。網上對它的讚美筆筆皆是。作為一個 11 年的 Evernote 重度用家，我有點苦惱是不是也要放棄 Evernote，轉投 Notion 的懷抱？

Notion vs Evernote 怎麼選


import  Callout  from "../../components/Callout"
import  Youtube  from "../../components/Youtube"

<Callout>

**題外話 1:** 我發現讀完一本書後，靜下心來寫寫讀後感，不僅能夠加強對內容的理解，也可留下一些當時的感想，日後回看也能夠快速回憶起書中的內容。 同一本書，不同的時間，不同的境遇下讀，體會到的東西也不一樣。所以更需要留下一點此時的記錄，算是給日後的自己一點回味的資本。希望這個做法能夠成為一個習慣堅持下去。

**題外話 2:** 同一本書(同樣是簡體中文版)，在不同的圖書市場的價格真是可以差很遠。

</Callout>


![Amazon vs Kobo 同一本書在不同的圖書市場的價格相差很遠 ](/image/blog/zl97r.png)



發現這本書，其實是因為在圖書市場中它的封面很特別，而且書名透露出一種文藝氣息，成功吸引到眼球。（所以外表還是很重要😂 ）後來再看看[豆瓣的評分](https://book.douban.com/subject/33440205/)，發現它有 8.8 的高分，而且它還是 [Bill Gates 的 2018 推薦書單](https://qz.com/1484067/bill-gates-book-list-2018-educated-and-bad-blood/)的第一名。於是就買來讀讀。

這本書有三個版本，繁簡英都有，書名各不相同，我比較喜歡簡體中文版的譯名，據說這個譯名的由來是作者親自選定，還有[一段故事](https://book.douban.com/review/10589105/)。 我這次買的也是簡體中文版。

![不同版本的譯名](/image/blog/qijgo.png)

這本書是作者 Tara 的自傳，也是她的處女作。Tara 十七歲前從未上過學，一直是在家中接受教育。後來通過自學考上大學，然後獲得蓋茨劍橋獎學金，直到最後獲得劍橋大學歷史學博士學位。2019 年 Tara 還因此書被《時代週刊》評為「年度影響力人物」。這本書讀下來是很輕鬆順暢的，仿佛就是跟隨著 Tara 在經歷著她的故事。這本書書名是「Education」，但其內容又不是傳統意義上的「教育」。正如作者所說「 I wanted to offer a story that wasn’t about education in the narrow sense of job training but in this larger sense, which is the idea of self-creation. 」這本書並不是一本勵志書，書中對於 Tara 是如何一路從完全沒有受過正規教育，直到拿到博士學位的詳細過程，只是篇幅很少地輕描淡寫。甚至輕描淡寫到了讓人覺得有點不可思議。但或許這就是作者的用意，她不想讓這本書成為「哈佛女孩」那樣的勵志雞湯，而是想讓讀者看到教育帶給和奪走她的東西。

![Tara Westover](/image/blog/4w1cu.png)


Tara 生長在一個非常傳統的宗教家庭中，有著一個極其權威，而又頑固不化地堅持著自己宗教理念的父親，在父親的觀念影響下，他們一家人不相信政府，不相信現代醫學，不相信教育，有著很多很多令人咂舌的保守觀念。父親逼迫 Tara 工作，不讓她接受學校教育，即便是 Tara 嚴重受傷後也不讓她接受醫生治療。另外 Tara 還有一個有嚴重暴力傾向的哥哥，這個哥哥給 Tara 造成了嚴重的生理和心理陰影。所以說 Tara 的童年和少年時代就是在這樣一種不可思議，有著扭曲世界觀的家庭環境中長大，在父親的權威下，只要稍有不同的想法，就被視為背叛，不孝以及對信仰的褻瀆。後來， Tara 在哥哥 Tyler 的影響下幾經周折終於決定離開大山去讀書，因此逐漸脫離家庭的束縛，最後甚至與父母斷絕聯絡，完全走進一個全新的世界。通過自己的努力，似乎進入一種「平步青雲」的狀態，一路不斷升級，最後獲得劍橋博士學位。

## 關於愛

愛這個主題貫穿全書。書中的 Tara 和他的家人的關係，很難一兩句話說得清楚。Tara 的父親不顧她的安危強迫 Tara 做一些充滿危險工作；在她嚴重受傷後拒絕讓她接受醫生治療；她的一個有嚴重暴力傾向的哥哥屢次做出令她身心受損的行為；她的母親在她最需要關愛的時候卻無視她所受的委屈而選擇沈默。家庭，這個本應用最溫暖的詞來形容的地方卻成了圍困她的牢籠，因此她最後選擇逃離，飛向自己的那座山。但也正因為如此，她和家庭的裂痕變得更深，更難以修復。

但是，又不難看出， Tara 以及她的親人的內心深處，依然深深愛著彼此。儘管彼此信仰不同，立場相左，但愛卻始終存在，無法割捨。

> You can love someone and still choose to say goodbye to them. You can miss a person every day, and still be glad that they are no longer in your life.
> 
你可以既深愛著某人卻又選擇和他離別。你可以每天都思念著他，卻又慶幸他們不再活在你的生命中

## 關於叛逆

合上書本後，對於「叛逆」這個行為，也有一些想法。或許在我們旁觀者眼中， Tara 的故事就是一個不為環境所迫而努力奮發的故事，然而在 Tara 的家人以及愛達荷州的人們眼中卻認為 Tara 是被無神論者和光明會間諜「洗腦」了，她叛逆，無可救藥，邪惡，完全不顧婦女應有的體統。她的父母甚至因此拒絕和她來往。

所謂對與錯，在不同的世界，有著完全不同的定義。當你堅信自己的信念，而周圍的人都質疑你的時候，是堅持，還是妥協，這很可能就是區分成功和平庸的關鍵。

## 關於教育

另外書中的主題是「教育」，那我也嘗試思考究竟什麼是教育，受教育和沒受教育的人的根本區別又會是什麼？想想看小學，中學，大學，這長達十幾年的教育對我們的現在究竟有什麼樣的影響？我自己也曾經覺得「讀大學似乎就是在浪費時間」，因為大學所學的科學知識，現在 90% 都已經忘記，或是對現在的工作沒有任何的幫助。但真的是這樣嗎？

後來在書的官方介紹中看到了 Tara 自己說的這樣一段話：

「**教育意味著獲得不同的視角，理解不同的人、經歷和歷史。接受教育，但不要讓你的教育僵化成傲慢。教育應該是思想的拓展，同理心的深化，視野的開闊。教育不應該使你的偏見變得更頑固。如果人們受過教育，他們應該變得不那麼確定，而不是更確定。他們應該多聽，少說，對差異滿懷激情，熱愛那些不同於他們的想法。**」

我想這個的確是一個很好的答案。

「教育是一棵樹搖動另一棵樹，一朵雲推動另一朵雲，一個靈魂喚醒另一個靈魂。」

## 結語

寫到這裡，越來越喜歡這本書的書名「**你當像鳥飛往你的山**」。隨著年齡漸長，似乎心中的銳氣也在慢慢消散。Tara 的故事，也算是給我們一個提醒，不要妥協，不要放棄，展開你的雙翅，無論在怎樣的環境中，都應該執著堅定的飛向屬於你的那座山。

最後是一段 Bill Gates 對 Tara 的訪問。

<Youtube youtubeId="a7Y6Udf_Nzo" />


這本書是 Bill Gates 2018 年度推薦書單第一名的書。是關於作者怎樣在一個有著嚴重扭曲世界觀的家庭中接受家庭教育直到最後拿到劍橋大學博士的過程。然而這本書並不是一本勵志書，書中對於「教育」的詳細過程，只是篇幅很少地輕描淡寫。但或許這就是作者的用意，她不想讓這本書成為「哈佛女孩」那樣的勵志雞湯，而是想讓讀者看到教育帶給和奪走她的東西。

你當像鳥飛往你的山


最近這段時間的生活方式的確是有了很大的不同。以前每到有時間總要想盡辦法逃離讓自己熟悉的環境，當時的理所當然卻變成了現在的奢望，失去了才知道珍惜。大半年的時間基本不出門，最近更又回到在家工作的模式，一天24小時在家裡不出門，多了很多獨處的時間。最近似乎又重拾了寫網誌的愛好，晚上開著橘黃的檯燈，聽著 Apple Music 中「流行輕聽」的播放列表，一邊想，一邊寫。外面的世界紛擾喧囂，看看書，寫寫字，像是自己對自己的傾訴，平淡又充滿樂趣。



言歸正傳，這次想說的是最近讀的一本書「為什麼要睡覺」(Why We Sleep)。其實不看也知道，這本書肯定是說睡眠的重要性，所以起初並沒有引起我多大的興趣，直到這段時間終於翻開，馬不停蹄幾個晚上就讀完了。這其實是一本非常科普的著作，沒有任何的情節可言，作者是加州大學柏克萊分校的神經科學暨心理學教授，曾在哈佛醫學院擔任精神病學教授，並創立「人類睡眠科學中心」的睡眠研究專家。書中16個章節事無事無鉅細的從方方面面闡述了睡眠的作用和重要性，並且給出了很多研究例證。

![](/image/blog/m2r2k.png)

讀完後的第一個感覺是，**所有人真的都應該仔細讀一遍這本書**。

於是將這本書推薦給家人，朋友，但似乎都沒有得到太多的回應。辛辛苦苦幫家人買電子書，轉檔，最後得到的回答是「**不如你看完之後將總結告訴我就好了**」。當時我也是不知道應該給什麼反應 😩。其實聽別人說所謂「總結」和自己去認真閱讀的收穫和體會是完全不同的。少了一個消化吸收的過程，對你的衝擊力自然就小了很多。

但「懶人包」總結還是要做的，透過這個總結我也可以記錄一下書中的重點，以便日後(或是另一個平行時空)的自己查閱😙：

## 睡眠的重要性-包治百病的偏方

「科學家們已經發現了一個可以讓你延長生命的革命性的新秘方。它能提高你的記憶力，增加你的魅力；讓你保持苗條，降低食慾；保護你不得癌症和老年痴呆；不讓你感冒和傷風；降低你心臟病、心梗和糖尿病的風險。你會感覺更快樂，不抑鬱，不緊張。你有興趣嗎？」

這個偏方就是「充足但不過量的睡眠」。

Walker 教授的觀點，我自己也十分同意，「**目前現代醫學辦不到的許多事，睡眠都可以做到**」。地球上已知的所有動物都會睡眠，這個看起來「浪費生命」的行為絕對不是上帝造人的bug。人體這部超級複雜的機器，有太多太多的秘密不被我們所了解，而睡眠就是其中最重要的一個。舉個頭痛的例子，吃止痛藥都無效，但只要好好睡一晚，第二天早上就神奇的完全不痛了。睡眠在人的生命中充當著極其重要的自我醫治角色。

## 睡眠的兩種形式(或稱睡眠階段)

我們每天晚上的睡眠都是在兩種睡眠形式中交替，「REM，快速動眼睡眠」和「NREM，非快速動眼睡眠」。

![圖片出自本書](/image/blog/q0pzq.jpg)

**快速動眼睡眠**，你的眼球會快速的移動，腦部的活動幾乎和清醒時一樣，但身體的其它肌肉處於放鬆的「鎖死」狀態。( 為了證實眼球會快速的左右移動，我自己在睡覺的時候用手機錄影，起來後再回看真的發現眼球咕嚕咕嚕轉個不停，很是有趣) 。在「快速動眼睡眠」時大腦是清醒的，因此所有做夢都是發生在這個階段。有趣的是你的大腦會在「快速動眼睡眠」時，切斷了一個大腦中傳遞信號給肌肉的「哨所」，因此你的全身自主肌肉處於癱瘓狀態，這樣做是為了保護機體不至於在大腦活動的過程中身體產生相應的運動導致危險。有些人醒來時大腦沒有來得及恢復這個「哨所」的信號，所以會產生所謂「鬼壓床」的情況。快速動眼睡眠對於記憶力的鞏固，白天吸收的知識梳理，重整，提升大腦的功能，提升創作力等等都有幫助。

**非快速動眼睡眠**，大腦的活動非常低，主要功能是機體修復，提高體質和免疫力等。非快速動眼睡眠又可以細分為四個階段，睡眠深度逐漸增加，越靠後的階段，越難把人叫醒。


## 褪黑素和腺苷

**褪黑素**和**腺苷**是兩種身體分泌的能影響睡眠的物質。褪黑素的作用是通知大腦中的其它組件，「現在該準備入睡了」。在接收到這個指令後，大腦中的各種組件會開始準備讓你入睡，包括使你開始感到睏意等。傍晚日落後，隨著自然光照和環境溫度的降低，（可能還有生物鐘的幫助下）大腦分泌的褪黑素會增多，指示各部位準備睡眠。褪黑素對喚起睡眠有幫助，**但褪黑素本身不會參與你的睡眠**，因為它僅僅是傳遞你要睡覺了的指令給大腦其它部位而已。所以褪黑素經常用來倒時差，的確有效果，但對於提升睡眠和幫助睡眠，其實作用不大。

就我自己的經驗，晚上服用褪黑素後，的確能夠在很短的時間內(大約15分鐘左右)產生睡意，但的確它對晚上睡眠的質量似乎沒有太大的幫助。褪黑素也不是處方藥，而是歸類為保健品，周圍的屈臣氏，萬寧都可以買到。

使我們入睡的是另一個角色是一種叫的腺苷，也可稱為「睡眠壓力」的物質。人體從清醒後身體會不斷產生這種腺苷，積累到一定程度，身體就會疲倦想睡覺了。而我們清除腺苷的唯一方法就是睡眠。如果睡眠時間不夠，第一天沒能清除的腺苷會累積到第二天，我們就欠了睡眠債。隨著我們累積的睡眠壓力增大，連續熬夜會更加困難。

## 咖啡因

上面說到人體從清醒後身體會不斷產生一種腺苷，而咖啡因會搶奪腦中本該接受腺苷的受體，從而從某種程度上欺騙大腦以為自己並不疲倦，進而擾亂身體的睡眠控制。咖啡因的半衰期平均為5-7小時。所以如果下午6:00喝了咖啡，這表示到了晚上11:00，還有將近一半的咖啡因在你的腦部組織中循環作用，因此會使你無法入睡。

## 睡眠量

書中說「人類是世界上唯一自主剝奪睡眠時間的生物」。甚至有些人會以犧牲睡眠為榮。但事實上是，**對絕大多數人來說，每天需要 7-9 個小時的睡眠**，才能讓身體完成全面的醫療修復。可能有些人認為自己睡六小時都足夠( 比如凌晨 1 點睡著，一覺睡到早上7點 ) ，而事實上確實有極少一部分人每天可以只睡6個小時(他們有一種獨特的基因)，但大約每1.2萬人中才有一個人有這種能力，也就是說我們自己有這種能力的概率比被雷擊的概率還小。

作者介紹了一些簡單的方法，可以測試自己睡眠是否足夠：

- 如果每天早上不用鬧鐘你會睡過頭，說明你需要更多的睡眠；
- 如果早上起床後你能在10點或11點再次入睡，說明你睡眠的長度和質量很可能有問題；
- 從起床到中午這段時間，如果你必須靠咖啡因才能高效工作，你很可能**長期睡眠不足**；
- 如果你讀文章時需要多次重讀同一句話，你也很可能缺乏足夠的睡眠。

## 關於做夢

「昨天晚上，你確實精神錯亂。今晚還會繼續發作。」

說的就是做夢。

做夢是一個很神秘的機制，目前科學似乎並無法完全解釋做夢的生理意義。書中介紹到在做夢的REM階段，大腦的視覺，運動，情緒和自傳式記憶相關的區域都十分活躍，而控制理性思維的前額葉皮質區域則不活躍。

書中提到夢境的確是和日間生活的內容有關，即「日有所思，夜有所夢」，但夢境不是日間生活的重播。做夢是一種夜間治療，撫平傷痛，解決問題，激發創意。在 REM 睡眠時期，大腦會嘗試將記憶中對你產生刺激的部分弱化，從而讓你第二天醒來時會好受一點。同時 REM 睡眠會用一種抽象且新穎的方式，加工，重組日間的記憶片段，再結合腦中的其它既有資訊，再我們醒來時會獲得一個經過優化的全新資訊網。因此你或許也曾遇到一覺睡醒，之前懸而未決的問題突然有了靈感，或是在夢中解決了你日間的問題等等。

好了，我原定這次只寫2000字，但發現不知不覺又寫到接近4000字了。時間也來到晚上11點，距離我預定的睡覺時間不遠了。那我先就此收筆。其實書中的內容遠不止上述這些，要了解所有內容，的確是非常建議認真讀讀全書，讀完後你或多或少會對睡眠有更深的認識，也許進而會更加重視睡眠，提升健康。

最後，下面是書中最尾部分的給讀者的忠告，也是本書的精華所在。這裡原文節錄：

## 健康睡眠的十二項守則（原文節錄）

1. 遵守規律的睡眠時間。每天同一時間上床，同一時間起床。
2. 運動好處多多，但是不能太晚運動。盡量每天運動至少三十分鐘，但要在睡前二至三小時前結束。
3. 遠離咖啡因和尼古丁。咖啡因是一種興奮劑，在咖啡、可樂、某些茶飲和巧克力中都有，它的效果可能要八小時才會完全退去，因此傍晚的一杯咖啡會讓你晚上難以入眠。尼古丁也是一種興奮劑，常使吸煙的人睡得很淺。另外，戒除尼古丁時，吸煙的人早上常會太早醒來。
4. 避免睡前飲酒。睡前小酌或許會讓你放鬆，但喝太多會使你缺少快速動眼睡眠，讓睡眠較淺。
5. 避免太晚吃大餐、喝太多飲料。輕食沒問題，但食物分量較多時會造成不消化，干擾睡眠。晚上喝太多飲料會導致夜裡必須常醒來上廁所。
6. 可能的話，不要服用會延後或干擾睡眠的藥物。
7. 不要在下午三點之後睡午覺。午睡可以補充睡眠不足，但太晚睡午覺的話，可能會讓晚上更難入睡。
8. 睡前要放鬆。不要把事情安排得太滿，讓你在睡覺前沒有機會放鬆。可以安排一些輕鬆的活動，例如閱讀或聽音樂，作為睡覺前的習慣。
9. 睡前泡個熱水澡。泡完澡後體溫會降低，可以幫助你覺得想睡，泡澡也會幫助你身心舒緩放鬆，更易於入睡。
10. 臥室要黑暗、稍涼、沒有電子產品。失眠的人常會盯著鐘看，因此要避免鐘面出現在視線所及之處，以免試著入睡時還在擔心時間。
11. 適當晒太陽。如果你有難以入睡的問題，睡眠專家建議應該在早晨晒一小時的陽光，並在睡覺之前把室內燈光調暗。
12. 不要醒著而仍躺在床上。如果你上床後二十分鐘仍然醒著，或開始覺得擔心或焦慮，最好起床做些輕鬆的活動，直到睡意產生。無法入睡的焦慮，會讓人更難入睡。














這次想說的是最近讀的一本書「為什麼要睡覺」(Why We Sleep)。其實不看也知道，這本書肯定是說睡眠的重要性，所以起初並沒有引起我多大的興趣，直到這段時間終於翻開，馬不停蹄幾個晚上就讀完了。書中16個章節事無事無鉅細的從方方面面闡述了睡眠的作用和重要性，並且給出了很多研究例證。的確是非常建議認真讀讀全書，讀完後你或多或少會對睡眠有更深的認識，也許進而會更加重視睡眠，提升健康。本文是我讀完後摘錄總結的的我覺得有趣的內容，透過這個總結我也可以記錄一下書中的重點，以便日後(或是另一個平行時空)的自己查閱。

為什麼要睡覺



讀這本書，全因被圖書市場上的推薦吸引，充滿視覺衝擊力的封面，以及眾多名人，媒體的好評，都讓我對這本書充滿了好奇和期望。

> 今年最絢爛繽紛，讓人想一路衝到底的小說，結尾合情入理到難以置信的地步。──衛報

> 一場峰迴路轉、在平行世界穿梭的尋家之旅，一本懸疑又毫不故弄玄虛的驚悚小說，掀起超暢快又超現實的閱讀高潮。──紐約郵報

其實類似上面這種令人驚艷的推薦還有很多，打開書的扉頁後就能看到。可是，說實話我第一次讀完之後並沒有感覺到被故事情節吸引到夜不能寐，特別是開始的部分。或許是我曾經讀過的衛斯理系列實在是太經典太天馬行空，我對再離奇的情節都能夠接受。我感覺本書作者的「編劇」水平和倪匡還是有一定的差距。

但不得不說的是這本書的一大看點便是「它讓量子物理變得浪漫了」。書中所述的故事的確是有一點燒腦，初初讀起來真的是有一點不適應。具體情節我這裏就不「劇透」了，有興趣了解的話可以買來一讀。書中的故事有一個關鍵的主線，或者說「類科學根基」，那就是平行時空理論，這也是讀完後引起了我好奇心的部分。

平行時空（又稱多重宇宙，平行宇宙，多元宇宙）這個詞相信你一定聽過，但具體的科學依據是什麼，可能你就未必了解。平行時空聽上去很科幻，但其實這個概念並非是小說家所創造，而真的是科學家們根據各種科學論證，推理，觀測後得到的結論。關於平行時空，其實有很多不同的分支理論，例如開放宇宙理論，泡沫宇宙理論，大反彈理論，量子力學理論等等，網路上關於他們的相關解釋有很多，這裏就不再贅述。因為「人生複本」中的情節，恰好就是和「量子力學理論」相關，那我也就順其自然的了解了一下量子力學理論對於平行宇宙的解釋，沒想到越了解發現越挑戰我的認知。

**燒腦的內容開始。**

## 光的楊氏雙縫實驗

要談量子力學理論對於平行宇宙的解釋，我先必須帶出幾個物理現象。首先是「光的楊氏雙縫實驗（又稱雙縫干涉實驗）」。這個實驗相信你讀書的時候一定親手做過。用一個點光源，照射一塊開有兩道平行狹縫的遮擋物，在後方的接收螢幕上，会接收到穿過狹縫後的光線。

![楊氏雙縫實驗 圖片源自互聯網](/image/blog/pobab.png)

試想一下。假如現在不是用光做這個實驗，而是用一把散彈槍，對著這個有兩道平行狹縫的遮擋物噴射，不難想象，後方的接收螢幕會出現兩條和狹縫類似的平行彈痕，因為通過狹縫的子彈直線傳播，抵達後方的接收螢幕。然而光的楊氏雙縫實驗結果卻不是這樣，最終我們看到的不是兩條和狹縫類似的平行豎線，而是出現許多明暗不同的條紋。

出現這個現象的原因，是因為光具有波的特徵。當光通過狹縫時，類似在狹縫出口處產生了兩個新的光波。這兩個光波，會彼此發生干涉 ( Wave Interference )，當光波抵達接收螢幕時，兩個波峰疊加在一起的地方強度疊加，光線更亮；波峰波谷疊加在一起的地方，強度抵消，光線最暗。類似的原理當今也用在了主動降噪耳機上，因為聲波也是一種波，也會發生干涉現象，因此耳機可以通過採樣，計算，發出一個和环境噪音振幅相近，相位完全相反的聲波，從而利用干涉現象抵消環境噪音。

![](/image/blog/2otbf.png)



## 單電子雙縫實驗

後來，隨著技術的進步，有了可以發射單獨電子的物理儀器，於是 Akira Tonomura 的團隊進行了新的實驗，他們使用單獨電子發射裝置，每次發射**一個電子**，確保每次最多只有一個電子通過雙狹縫（而不是類似激光那樣一次有一堆的電子穿過狹縫），再用裝置在後方接收電子，過程類似楊氏干涉實驗。

觀察發現，開始的時候每顆電子好像會隨機落在後方的接收螢幕上，但隨著不斷重複實驗，發現後方的接收螢幕上的新舊光點疊加起來慢慢出現了和楊氏干涉一模一樣的條紋。

![](/image/blog/9el7d.png)

看到這你可能覺得「不就是干涉嗎」？

**顛覆你認知事情即將發生。**

呵呵。

上面電子的這個實驗，和楊氏干涉實驗的不同之處在於， Akira Tonomura 實驗的電子，是**一個一個獨立打出去的**。換句話說，每次最多只有一個電子通過雙狹縫（而不是類似激光那樣一次有一堆的電子穿過狹縫）。因此實驗的結論，就有些詭異。即：用一個電子來實驗，依然會發生干涉現象。這裏邊可大有文章。

- 既然是「一個電子」，那麼它要麼從狹縫 A 通過，要麼從狹縫 B 通過，因此不會形成兩個波，干涉更無從說起，難道自己干涉自己？
- 再者，從電子的大小來看，這兩個狹縫的距離可能比地球和太陽的距離還遙遠，那一個電子，如何知道遙遠的地方還有另一個狹縫？
- 然後，我們知道最後產生的條紋形狀，是和兩條狹縫的距離直接相關，那一個電子，如何在一瞬間測量出了兩條狹縫的距離因而最終產生對應的干涉條紋？

沒錯，上面的這些疑問無法用經典物理學解釋，似乎唯一的可能性是「**電子同時通過了兩個狹縫**」。但說出這句話，似乎很可笑，一個電子，如何做到同時通過兩個狹縫？

為了搞清楚電子是否同時通過了兩個狹縫，有人提出可以在兩個狹縫安裝探測裝置，藉此「** 測量**」究竟哪個電子通過了哪個狹縫（量子擦除實驗 Quantum Eraser Experiment）。然而發現，一旦進行「** 測量**」，會發現電子只是通過了一個狹縫，但同時干涉現象也隨之神奇消失。


## 哥本哈根詮釋

上面說的「單電子雙縫實驗」的結果似乎超出了人們的認知。物理學者們不願接受這個結果，但也無法解釋原因。

上面說到，實驗結果似乎唯一的可能性是「**電子同時通過了兩個狹縫**」，於是有一些物理學家給出了某種意義上的解釋，即「[哥本哈根詮釋](https://zh.wikipedia.org/zh-hk/%E5%93%A5%E6%9C%AC%E5%93%88%E6%A0%B9%E8%A9%AE%E9%87%8B)」。這些解釋看文字可能非常「燒腦」，經過消化，我自己的理解如下：
- 量子世界中，粒子不像我們宏觀世界中的物體有確定性，在量子世界中，粒子是**不確定的**，電子的運動沒有確定的軌跡，只要不進行「**測量**」，它就以概率波的形式存在，彌散在空間裏，「在又不在」，「有又沒有」，「既在這裏，又在那裏」，「色即是空，空即是色」，這種狀態稱之為「**疊加態**」；
- 「**測量**」是粒子改變狀態的關鍵；
- 一旦進行「**測量**」，粒子就會發生「波函數坍塌」，粒子的「**不確定性**」隨即消失，立即進入其本徵態；

哥本哈根詮釋套用到「單電子雙縫實驗」中，在電子被發射後，它以概率波的形式傳播，因為其無處不在，所以同時穿過兩個狹縫，發生干涉，直到接觸到接收裝置的測量，發生「波函數坍塌」，轉化為本徵態，出現在接收裝置的某一點。

上面的這些理論，聽上去是不是覺得挑戰你的認知？是的，當時的物理學界，很多人(包括愛因斯坦大神)也都不是很 buy 這個聽上去腦洞大開，荒謬無比的理論。因此，根據「哥本哈根詮釋」的理論，物理學者[埃爾溫·薛定諤](https://zh.wikipedia.org/zh-hk/%E5%9F%83%E5%B0%94%E6%B8%A9%C2%B7%E8%96%9B%E5%AE%9A%E8%B0%94)提出了一個實驗構想，嘗試藉此反駁「哥本哈根詮釋」的荒謬性。那就是著名的「薛定諤的貓」(又稱薛丁格的貓) 實驗。

![](/image/blog/3j5hs.jpg)

為了避免本文篇幅過長，此文的<Link href="/blog/dark-matter-2">下半部分</Link>，將繼續說說這個怪異的實驗。












人生複本，的確是一本「燒腦」的書，印象中我似乎沒有試過讀完一本小說後花這麼多時間去了解其中的背景知識。這篇文章嘗試結合書中的內容，將我了解到的關於平行時空背後的科學探討進行簡單總結，包括楊氏雙縫實驗，單電子雙縫實驗，量子理論中的哥本哈根詮釋，薛定諤的貓實驗等等。這個過程中發現，了解的越多，反而意識到不懂的更多。這些之前想都沒有想過的知識，極大的衝擊了我的認知，不得不感嘆這個宇宙的奇妙，人類的渺小。

人生複本 - 讀後(1)




**此文是「人生複本」讀後感的第二篇，沒有看第一篇的可以先看看** <Link href="/blog/dark-matter-1">第一篇</Link>。

承接<Link href="/blog/dark-matter-1">上文</Link>，說到當時的物理學界，很多人(包括愛因斯坦大神)也都不是很 buy 這個聽上去腦洞大開，荒謬無比的理論。因此，根據「哥本哈根詮釋」的理論，物理學者[埃爾溫·薛定諤](https://zh.wikipedia.org/zh-hk/%E5%9F%83%E5%B0%94%E6%B8%A9%C2%B7%E8%96%9B%E5%AE%9A%E8%B0%94)提出了一個實驗構想，嘗試藉此反駁「哥本哈根詮釋」的荒謬性。那就是著名的「薛定諤的貓」(又稱薛丁格的貓) 實驗。

## 薛定諤的貓

薛定諤（中文譯名又稱薛丁格）是奧地利理論物理學家，量子力學奠基人之一。他提出了著名的「薛定諤方程式」，以描述物理系統的量子態怎樣隨時間演化。其後更因此獲得諾貝爾獎。

![](/image/blog/xgze2.png)

而薛定諤的貓， 則是他提出的一個思想實驗。（所謂思想實驗是指用想象力進行，實際上不可能或暫時不可能做到的實驗）。

實驗的構想大致如下：
- 把一隻活貓、一個裝有劇毒氣體的玻璃瓶、一個放射性物質、一個監控放射性物質衰變的裝置放進一個封閉的盒子內；
- 這個放射性物質有 50% 的可能性會衰變，50% 的可能性不會衰變；
- 當監控器偵測到衰變粒子時，就會打破玻璃瓶，進而釋放毒氣，殺死這隻貓；

![](/image/blog/3fxto.jpg)

用經典物理學的角度來看，放射性物質有 50% 的可能性會衰變，50% 的可能性不會衰變，因此貓有50% 的可能性死，50% 的可能性活，只能發生這兩種情況之一。

而根據「哥本哈根詮釋」，在不觀察的情況下，放射性物質處於即有衰變又沒衰變的
「**疊加態**」，因此聯動貓兒便處於又活又死的「**疊加態**」。一旦我們打開盒子，或者以任何形式進行「**測量**」，則會導致「波函數坍塌」，會讓貓兒回到「本徵態」，進而看到一隻活貓或一隻死貓。

「薛定諤的貓」實驗構想聽上去荒謬，一隻貓怎麼可能處於又死又活的狀態？其實薛定諤提出這個構想也就是為了用一個生活中的例子去嘗試證明「哥本哈根詮釋」的問題。可是似乎這個實驗構想並沒有達到薛定諤的預期效果，反而成為了量子理論中家喻戶曉的一個生活化例子。

## 平行時空

講到這裡，終於可以回到「平行時空」了。上面說了好多「哥本哈根詮釋」的內容，但是有人覺得這裡面還是有很多說不清楚的東西。例如「波函數坍塌」究竟是什麼？怎樣才會坍塌？怎麼坍塌？因此，有人提出了新的見解，就是「**多世界詮釋**」，即所謂平行時空理論。

這個理論，和「哥本哈根詮釋」最大的不同在於「**測量**」所帶來的結果。「多世界詮釋」認為，「**測量**」帶來的不是「波函數坍塌」，而是「**分裂**」的宇宙。

在「單電子雙縫實驗」中，當電子穿過雙縫時，就出現了兩個平行宇宙，在一個宇宙中電子通過了A狹縫，另一個宇宙中電子通過了B狹縫。而作為觀察者的我們則隨機進入了一個宇宙，進而看到了該宇宙中的後續結果。而另外一個宇宙中，有另一群「我們」在做著同樣的觀察，而他們看到的則是電子通過了另一個狹縫。同樣的，「薛定諤的貓」實驗中，當我們打開箱子時，變產生了兩個平行宇宙，一個宇宙中的我們看到貓活著，另一個宇宙中的我們看到貓死了。

而「**測量**」正是讓宇宙產生平行時空的開關。

## 人生複本

探討了一大堆物理學的內容，終於回到這本書「人生複本」了。為了不劇透，關於書中具體情節的感想我就不寫了。這裡就簡單記錄一下當下我讀完後的一些凌亂的想法。

書中的主人公，遇到了平行時空的自己，但同一個人，竟然有著完全不同的行為。合上書本，似乎打開了很多靈魂拷問。此時我也在想，假如真的遇到了自己的副本，一個一模一樣的自己，會是怎樣的一種感覺，我會歡迎他闖入我的世界，還是像書中一樣充滿敵意？從自己的角度看另外一個自己，又是怎樣的感覺？如果不同的選擇真的可以產生新的平行時空，那麼在這千百萬的平行時空中不同的自己會有多大的差別？又或者，根本不會有太多的平行時空，因為面對同樣的選擇，同一個自己根本不會做出不同的選擇？

這本書的獨到之處，不僅是因為腦洞大開地刻畫了一個在平行時空中的世界，更是因為在這個世界中融入了很多感性的元素。儘管有千千萬萬個平行時空，千千萬萬個傑森，而且他們各自的性格行為非常不同，但他們對於丹妮樂的愛卻始終如一。而丹妮樂愛著的那個傑森，就是那個唯一的，無法替代的傑森，即便是另一個傑森的複本，也不可以。

讀完這本書後，好奇心驅使我又找了很多相關的量子物理的文章來看，確實是學到了不少腦洞大開的新知識。看的越多，反而發現不懂的更多。這些之前想都沒有想過的新知識，極大的衝擊了我的認知，不得不感嘆這個宇宙的奇妙，人類的渺小。我們有太多太多的東西尚未掌握，這個世界有太多太多的東西超出我們的認知。很多我們覺得離譜，荒謬的事情，其實只是因為我們的思想還沒有到達那個階段。人類實在是應該用一顆謙卑而開放的心，來面對這個世界，接受不同，迎接未知。

我覺得這本小說值得再讀一次，特別是在了解了相關的物理學知識後，對第一次閱讀時一些難以理解到腦洞環節，可能會有更深的共鳴。


人生複本，的確是一本「燒腦」的書，印象中我似乎沒有試過讀完一本小說後花這麼多時間去了解其中的背景知識。這篇文章承接上文，從著名的「薛定諤的貓」實驗，回到平行時空的主題，最後再談談我讀完整本書的感受。

人生複本 - 讀後(2)


最近購買了一部 Kobo Forma 電子書閱讀器，愛不釋手。那也就藉此機會寫一下我對電子書閱讀器以及最新入手的 Kobo Forma 的看法。

## 電子書閱讀器
其實我在中學的時候，就開始鐘情於看電子書，還記得那時候流行 PDA，於是我便將網上下載的電子書傳到 PDA 中，上課時偷偷的看，就這樣一百多本衛斯理系列，以及其他各種有的沒的的小說，就這樣在那一行只能顯示幾個字的點陣螢幕上看完了。後來，資訊科技日漸發達，電腦，手機都成了生活標配，能夠閱讀電子書的渠道也是多了很多，後來出現的電子書閱讀器（又稱電紙書）就是其中的一個大類。

說到電子書閱讀器，那就先說說我使用下來，明顯感覺到的優點：

### 1. 如同真實紙張一般的顯示螢幕

電子書閱讀器的螢幕，應該算是最大的賣點了。它採用的是 E-ink 技術，顯示原理和手機，電腦螢幕有很大的區別。黑白電子書閱讀器的螢幕裡面，有很多的「顯示膠囊」，裡面裝有黑白兩種不同的粒子，在電荷的作用下，呈現不同的分佈狀態，因此會顯示出不同的灰階顏色。這種顯示方式，相比手機，電腦螢幕的 LCD，LED，最大的差別是「膠囊」本身不會發光，其呈現顏色的方式和真實的書籍是很類似的，都是靠光线的自然反射，所以閱讀時眼睛的體驗和閱讀真正的紙本書基本相同，相比閱讀手機和電腦那種主動發光的螢幕，眼睛會舒服許多。

![](https://www.frank.hk/pictures/uploads/HIW-JustTint-E.gif)
![](https://www.frank.hk/pictures/uploads/GIF_Capsule_E.gif)

### 2. 可以調節文字大小和字體

調節文字大小，這個也是提升閱讀體驗的不可或缺的一環。一般所有的電子書都可以提供調節文字大小和字體的功能，這樣在不同的場景和眼睛狀態下，就可以更容易的閱讀。

### 3. 便攜性

這個優點應該是毋庸置疑的，即便最小容量的電子書閱讀器，也能輕鬆容納過千本書，帶著一部小巧的閱讀器，就宛若有一座圖書館跟著你一樣。想想看若是帶著實體書，裝兩本就差不多一公斤了。想想看如果你喜歡讀書，經常買實體書，時間一長，在香港這種寸土寸金之地，一堆的書會佔用家中不少的空間。

### 4. 專注

有人會問手機也可以看電子書，那為什麼還要買閱讀器？對於這個問題我覺得首先是因為手機螢幕的主動發光，加上手機螢幕比較小，長時間看手機眼睛非常容易疲勞；其次，也是我覺得最重要的原因就是閱讀體驗。用手機閱讀時，大腦潛意識感覺我還是在「玩手機」，並沒有進入到一個旁若無人的閱讀心流狀態。加上手機不斷彈出的通知訊息，總能夠成功的將我的閱讀打斷，本來想看看書，最後看了半小時 facebook。

### 5. 購書平台以及價格優勢

這個優點應該算是所有電子書的共同優點，並不局限於電子書閱讀器。購書平台一般都會有大量的書籍供選擇，而且會根據你的閱讀習慣推薦相關的書籍給你，這一點我非常喜歡。有時候在這些平台上逛逛，似乎都有一種逛書店的感覺，總能找到自己有興趣的書。而且無論在哪個市場，電子書的價格總會比實體紙本書低，因為畢竟電子書相比實體紙本書少了材料，印刷，運輸，中間商等等環節的成本開支。

而電子書平台，因為我本人只看中文書，所以就中文電子書平台，我目前知道的主要有以下幾個：

![中文電子書平台](/image/blog/yx8qo.png)

其中除了微信讀書外，都有提供各自的電子書閱讀器。這些有提供閱讀器的平台中最出名的三家，藏書量比較如下：

#### Amazon Kindle
- 簡體中文書：約 70 萬冊
- 繁體中文書：約 2 萬餘冊
- 全球其它地區書籍：3300 萬冊

#### Kobo 
- 繁體中文書：約 8 萬餘冊
- 全球其它地區書籍：800 萬冊

#### 讀墨 Readmoo 
- 繁體中文書：約 10 萬餘冊

價格方面，不同的平台價格差異很大：

![不同平台價格差異很大](/image/blog/gskb1.png)

以我最近在看的一本書為例，Amazon 簡體中文版價格最低，台灣讀墨價格最高，兩者相差達到了十倍。因為出版社，地區的原因，普遍來講中國大陸平台的簡體中文書籍的價格都會比繁體中文的書籍低很多，而且不定期會推出各種優惠，價格優勢非常非常明顯。

理論上來講，在一個平台上購買的電子書，只能夠在該平台的閱讀器上閱讀，因為各家平台的電子書檔案，都會附加數位版權保護(DRM)，類似於給檔案加了密碼，只能夠在認可的裝置中解密讀取。但其實移除 DRM 也不是什麼困難的事情，在 Kindle 上買書，再將檔案傳至 Kobo 上閱讀，也是能夠很容易做到的。

## Kobo Forma 電子書閱讀器

上面鋪墊了這麼多電子書閱讀器的優點，那現在就說說我目前正在使用的 Kobo Forma。 其實我原本是用 2015年版的 Amazon Kindle Paperwhite 3，但使用下來對 Kindle 實在是有挺多不滿。

![](/image/blog/qmiwf.png)

首先是 Kindle 握持感非常不好。單手拿著它，右手的拇指總有一種不知道要放在哪裡的感覺。放在邊框上，翻頁時要来回移动手指；放在螢幕上，又會誤觸。Kindle Paperwhite 看起來小巧，但握在手上總覺得哪裡不對勁，總覺得拿不穩，握著不舒服。我曾經嘗試買一個後面有橡筋的保護套，這樣就可以將手指插在裡面，不用擔心單手握不穩的問題，但這樣一來整體重量又增加了一截。另外就是 Kindle Paperwhite 的螢幕，凹陷下去的螢幕，不僅容易積累灰塵，而且手指觸摸起來總覺得很彆扭。這兩點總結起來就是人體工學設計不佳。另外就是螢幕大小，6 吋的螢幕，和我的手機（iPhone XS Max）的 6.5 吋螢幕差不多大，總覺得看起來不夠爽。除此之外還有它的系統，總是充斥著各種廣告。雖說這些問題都不是致命缺陷，但就是因為這些小問題，讓我使用 Kindle 的意欲大減，很多時候最後都是買了書後還是在手機上閱讀，甚至一度已經徹底放棄電子書閱讀器這種產品。

後來最近在一個 FB 的群組中看到有人推薦 Kobo Forma，做了一番研究後前往店鋪，其實去之前本來並沒有想買，只是準備看看了解一下而已，但摸到了真機後，頓時愛不釋手。最大的吸引力是他的握持感非常棒。螢幕側邊設計了一個握持欄位，附有實體按鍵，拿上手後感覺到重心分配非常均勻，絲毫沒有抓不穩的感覺，翻頁的時候手指也不用移動，直接使用實體按鍵即可。8 吋的螢幕，尺寸非常接近真實的書本大小，而且螢幕是水平的，沒有像 Paperwhite 3 那樣的凹陷設計。更驚艷的是，上手的感覺真的非常輕，這麼大的一塊螢幕，拿在手上感覺比我的手機都要輕很多。

![Paperwhite 1：1 對比 Kobo Forma](/image/blog/z1jh6.png)

就在 Kobo Forma 的旁邊，放著 Kindle 的最新旗艦 Kindle Oasis，對比 Kobo Forma，螢幕小了一些，全金屬的機身，看起來是很高端，但拿起來後第一感覺是非常滑，因為金屬殼的摩擦力小，總覺得拿不穩。（有點類似 iPhone 6s 那種全金屬機身的上手感覺），握持感比 Paperwhite 3 要好，但依然覺得哪裡不對勁。

![Kindle 的最新旗艦 Kindle Oasis](/image/blog/pinht.jpg)

所以 Kindle Oasis 握在手中不超過 20 秒就放回去了。 回到 Kobo 的櫃檯，繼續看看它的其它功能，約摸30分鐘後，決定把它帶回家。

使用了 2 個星期，看了差不多兩本書，簡單總結一下我的感覺：

#### 優點
- 👍🏼 &nbsp;螢幕非常大，閱讀起來非常舒適；
- 👍🏼 &nbsp;握持感覺舒適，實體按鍵拇指不用經常移動，長時間閱讀手不會辛苦；
- 👍🏼 &nbsp;背部的防滑設計，拿起來非常穩；
- 👍🏼 &nbsp;暖光閱讀燈，甚至可以根據時間自動調節光線色溫；
- 👍🏼 &nbsp;可以連接 OverDrive 直接借閱香港公共圖書館的英文電子藏書；
- 👍🏼 &nbsp;可以使用 Pocket ，將網上的文章在 Kobo Forma 上閱讀；
- 👍🏼 &nbsp;可以使用 Dropbox 方便的同步資料， mobi，epub 等格式的檔案都可以輕鬆開啟；
- 👍🏼 &nbsp;有清晰的閱讀統計功能，讓你知道閱讀了多少時間，閱讀速度等等，還有類似遊戲的完成任務獎牌；

#### 缺點
- 👎🏼 &nbsp;書籍的橫排直排不能更改，要跟出版社的設定；
- 👎🏼 &nbsp;劃線的部分不能匯出(這個有方法解決，本文稍後分享)；
- 👎🏼 &nbsp;Kobo 書店的 UX 很一般；
- 👎🏼 &nbsp;中文字體不是很多(這個有方法解決，本文稍後分享)；
- 👎🏼 &nbsp;側邊的電源按鍵非常難按；
- 👎🏼 &nbsp;Micro USB 的接口而不是 USB-C；

另外，發現 Kobo Forma 還有一些隱藏的功能：

### 為 Kobo Forma 添加字體
Kobo Forma 本身沒有下載字體的功能，但其實可以輕鬆做到。只要在將 Kobo Forma 連接電腦後，在硬碟主目錄建立一個fonts資料夾，將字體文件放進去即可。

### Kobo Forma隱藏的開發者模式功能
在 **設定** \> **測試版功能** 中本來只有 **閱讀網頁** 和 **字體放大模式** 兩個選項。 但只要在 Kobo 商店的搜尋欄中輸入 `devmodeon` ，再按下搜尋鍵之後，回到 **設定** \> **測試版功能** 中便會發現多了畫板，數獨，接龍遊戲等功能；

### Kobo Forma 匯出劃線註記以及加入生詞本功能
直至現在 Kobo Forma 本身沒有匯出劃線註記的功能，這個好像一直被用家詬病。但其實系統本身是支援這個功能的，但需要編輯一些隱藏的設定文件。 將 Kobo Forma 連接電腦後，在`Kobo Forma 硬碟目錄/.kobo/Kobo`  中（留意 `.kobo`目錄是隱藏的，所以要開啟顯示隱藏檔案的相關選項），有一個 `Kobo eReader.conf` 檔案（，使用文字編輯器打開它，在最後一行新增如下內容：
 
```bash
[FeatureSettings] 
ExportHighlights=true
MyWords=true
```

保存之後即可。這樣在長按書封時便會有「匯出劃線」的選項了。另外在閱讀時使用字典功能時也可以將生詞加入單詞本，而且在「我的閱讀統計」中會出現一個新的「我的單字」欄目。

其實 Kobo 是使用 SQLite 資料庫存儲著所有劃線註記和其它用家資料，你可以在`.kobo` 目錄中找到一個名為 `KoboReader.sqlite` 的檔案，用任何一個  SQLite Reader 打開，也可以在 Bookmark Table 中看到你的劃線註記，當然這個需要有一點 IT 的基礎了。

![](/image/blog/hosk6.png)

## 寫在最後

信息時代的今天，人們獲取資訊的方式越來越廣闊。各種社交網站，應用程式，五花八門的資訊唾手可得。打開手機，撲面而來的無聊影片，低到沒有下限的新聞報導，每時每刻不在給我們「洗腦」。問問自己，有多少次，打開社交網站後不知不覺就過了幾小時？有多少次，打開一段沒營養的影片之後，就不知不覺一條接一條的看下去？大量的碎片信息和垃圾信息，慢慢地讓人們視野越來越窄，頭腦越來越簡單。相較之下，閱讀書籍卻能夠提供完全不同的效果，千百年來，都是如此。好的書籍，可以開闊視野，啟迪智慧；可以洗滌心靈，充盈生命。專注讀書的時候，你會進入一種忘我的心流狀態，這種狀態，絕非一般的社交媒體資訊所能夠企及。

我並不是一個非常喜愛讀書的人，這點上相比我的媽媽實在是相形見絀。家中最早擁有電子書閱讀器的，是她，搬家時幾大箱的書，也是她。即便現在我買的電子書，很多都是她讓我幫她買的時候才知道和了解的。真正愛書的人，其讀書的意願當然不會因為電子書閱讀器的高低好壞，或者有沒有電子書閱讀器而有絲毫的影響，科技產品的出現只是在閱讀的道路上助力而已。當然，我希望能夠藉助這塊 8 吋的螢幕，幫我打開更多的世界。

呀，沒想到寫了4千5百字。我是多麼喜愛 Kobo Forma。 ❤️ ❤️ ❤️





最近購買了一部 Kobo Forma 電子書閱讀器，愛不釋手。那也就藉此機會寫一下我對電子書閱讀器以及最新入手的 Kobo Forma 的看法。

Kobo Forma 電子書閱讀器


## 1

晚上，做了一個奇怪的夢。

![](/image/blog/cofuc.jpg)

一個荒漠中，我和一班戰友一起從事著秘密任務。這時，走過來兩個人，其中一個是自己現實生活中的某位上司，他命令手下選擇我們其中的一個人，當場處決。

我充滿自信的想著肯定不會是我，但沒想到自己的名字從上司的口中說了出來。於是在還沒有來得及抗辯的情況下，砰的一聲，頭上一陣發熱，身體便倒了下去。但奇怪的是，這時候似乎竟然還有知覺，甚至還暗自感歎，原來被槍擊中而死是這樣的感覺。這時，似乎能清楚的看得到自己已經倒下的身體，而且能聽到上司和手下們的談話，大家似乎都對上司的選擇很不解，「為什麼要選他，他可是得力戰將呀！」

上司在一旁笑笑，說「此人並非凡人，其絕招乃金剛不壞之軀，不需頃刻，其必復生」説罷，他看著我倒下的身體，開始呼喚我的名字，一遍又一遍。言語間，我感覺到我又回到身體中，慢慢感覺到了撲面而來的頭暈目眩，哦，我難道，死而復生了？

剛復活後的身體，癱軟無力，嘴巴中還不斷流著口水，地下濕了一片。上司將我扶起來，拿紙巾準備擦乾我掉在地下的口水。可我怎麼能讓他出手做這種事，立馬強打起精神自己把自己的口水擦乾淨。待我完全恢復後，上司坐在我身旁，說到「你有金剛不壞之軀的絕招，可能你自己都不知。是以方才我才有此舉，讓你了解自己有多強大。今日起我會降大任於你，第一個任務是要前往 A 機構做調研，你負責弄清楚一項重要機密，三日後交報告給我 ...」

話還沒說完，我就被貓叫聲驚醒。

夢醒後，似乎大腦還沒有完全清醒，有那麼一兩分鐘，我還真的以為自己有金剛不壞之軀的絕招。但很快，周圍熟悉的一切將我無情的拉回現實，望著身旁的貓兒，苦笑一聲，好一個「金剛不壞之軀」的絕招。

當下的世界，疫情肆虐，人心惶惶。以往在電影中才會出現的情節，似乎一步步成為現實。總是有那麼一些人，覺得自己似乎有金剛不壞之軀，能夠在這場瘟疫中倖免，於是舞照跳，馬照跑，可事實上，在這無孔不入的隱形病毒面前，人們的絕招，也僅僅只能是盡一切可能，遠離病毒。

希望這場浩劫能夠盡快平息，飽受摧殘的人們能夠儘快恢復平靜。

## 2



2013年，一部「來自星星的你」俘獲了多少男男女女的心。記得當時，只是輕輕一瞥這個電視劇的劇照，我已經對它沒有絲毫的興趣。雖說因為野蠻女友的關係喜歡全智賢，但是看到男主角那種面無表情，故作高冷的韓劇鍋蓋頭，以及大反派李載京小夫頭的扮相，實在提不起半點興趣來看。再加上什麼外星人的劇情，聽了都覺得是對自己智商的侮辱。

![](/image/blog/7gokx.jpg)


可是人終究是善變的。不同的時間，不同的空間，不同的經歷下，人的性格，喜好，都會不一樣。20多歲的時候討厭的東西，現在看來也沒那麼壞。差不多7年後的最近，在 Netflix 上又看到了這部劇，不知什麼原因我竟然按下了播放鍵。就這樣，每天回到家，都在這亦幻亦真的劇情中度過，情緒隨著千頌伊和都敏俊的感情線起落。

都敏俊xi擁有者各種離奇的絕招，瞬間移動，暫停時間，隔空取物。。。聽上去都覺得羨慕不已。一路看下去，我不止一次的希望我也有類似的絕招，瞬間移動到想去的地方，親人的身邊；暫停時間，讓這快如流水的時光凍結在最美好的時刻。當然，關掉電視後還是要回到現實，什麼瞬間移動時間靜止，也只能夠在夢中，或是薩爾達中才有機會實現了。與其羨慕那些有的沒的的奇怪超能力，還不如問問自己，在這現實世界中，你的絕招是什麼？又或者，你有絕招麼？

其實，我真的沒有答案。

## 3

在社交網站上看到一個很久沒有聯絡的朋友的更新，我被她貼子下的地點標記吸引了，「上海」。於是發信息問候了一下，才了解到原來她已經去上海工作了。聊了好長一段時間，感覺到她現在無論工作上生活上的狀態似乎都非常好。

於是思緒回到了幾年前，記得當時一起在海傍跑步時，她望著華燈初上的維多利亞港的說感覺到自己壓力很大，很辛苦，沒有動力，可能這輩子就這樣了。一轉眼幾年後，似乎整個人都有了另一種狀態。的確是這樣，有時候在一種環境下如璞玉般樸實無華，換一個環境可能就會大放異彩。我深信每個人身上都有自己與眾不同的絕招，關鍵是如何發掘，並且將之放在適合的環境下。當然，這不是一個容易的過程，你可能需要不斷探求，不斷改變。用我的朋友為例，想想看要離開一個自己成長的地方去另一個完全陌生而又文化不同的地方，那是要有多大的勇氣。

求變，並付出踏實的行動去不斷改變，這或許就是我所找尋的一個絕招吧。










一個荒漠中，我和一班戰友一起從事著秘密任務。這時，走過來兩個人，其中一個是自己現實生活中的某位上司，他命令手下選擇我們其中的一個人，當場處決。

絕招


莎士比亞，一個如雷貫耳的名字。光是聽到這四個字，頓時便會有一種高大上的感覺迎面撲來，籠罩全身，揮之不去。即便你沒有讀過，也一定聽過「哈姆雷特」，「羅密歐與朱麗葉」，「李爾王」，「仲夏夜之夢」，「奧賽羅」等等這些巨著的名字。

> 「我讀到他的第一頁，就使我這一生都屬於他了」<small style={{color:"#808080",fontSize:"50%"}}>- 歌德</small>


> 「如果有一天能上太空，又只能帶一套書，那必須是莎士比亞全集」<small  style={{color:"#808080",fontSize:"50%"}}>- 金庸</small>

莎士比亞的崇拜者，貫穿古今。大仲馬、狄更斯、雨果、丘吉爾、霍金、魯迅、金庸都是莎翁的忠實讀者，聯合國教科文組織還將他的忌日（4月23日）定為「世界讀書日」。毋庸置疑，莎士比亞輕鬆位居世界上最有影響力作家的第一把交椅。

![](/image/blog/gtlib.png)

## 謎團
然而，這個世界第一文豪，身上卻有著種種解不開的謎團。這些謎團中，包括莎士比亞的長相，出生地，名字，教育背景等等。然而所有這些謎團中被人討論最多的，就要算是本文標題的質疑，『你認識的莎士比亞，真的存在嗎？』如果有人告訴你，名滿世界的文豪莎士比亞，根本就是另有其人，那些如雷貫耳的巨著，都是出自他人之手，你會怎麼想呢？

請教 Google 大神，發現原來文學史上關於莎士比亞的真實身份爭議由來已久。儘管主流學界至今依然肯定莎士比亞的存在，但質疑的聲音向來都沒有中斷過。這其中不乏一些名人，比如馬克·吐溫，他就懷疑莎士比亞的存在，稱他是「這個星球上最著名的匿名人。」甚至還有人成立了莎士比亞劇作家身份研究聯盟，旨在揭開莎士比亞的真實身份。

那為什麼人們會懷疑莎士比亞的身份？


### 詞彙量
根據網路上的資料，不同的人以及電腦都曾統計過莎士比亞的英文詞彙量。根據斯坦福大學 Bradley Efron 和 Ronald Thisted 的統計，莎士比亞的詞彙量超過 30,000。 

![](/image/blog/uf8us.png)

這是什麼概念？ 一般英語母語的人生活中常用的詞彙量只有數千，而如果去英語國家讀研究生，考 GRE 的核心詞彙量在 1 萬左右。另外，要知道，知道一個詞是一回事，知道並且會用這個詞來進行寫作，則又是另外一回事。因此，莎士比亞的英文詞彙量，似乎多到超乎常理。可是，根據記載，莎士比亞出生於英格蘭中部斯特拉福鎮的一個羊毛商人家庭，父母的文化程度都不高，而且後來因為家庭生意破產，莎士比亞不得不早早的輟學謀生。1585年前後，他離開家鄉去倫敦，先在劇院打雜，後來當上一名演員，進而改編和編寫劇本。因此，對於莎士比亞在這樣的經歷下，如何能夠掌握如此巨量的詞彙，無法解釋。

### 教育程度和專業知識
正如上面所說，根據記載，莎士比亞的教育程度並不高，但是在他的作品中提到過很多關於皇家司法系統，貴族運動，文化，醫學等等的信息，這些內容，都不像是一個沒有接受過高等教育的人所能夠了解的。要知道那個年代，並沒有 Google，知識的獲取成本和難度比如今大得多。如果不是有權勢，有資源的人，基本上沒有可能有渠道學習到這些知識。

另外， 莎士比亞的作品中對一些專業領域的描寫都十分的精準。
#### 法律知識
莎士比亞的作品中，有大量的法律相關的描寫。例如「威尼斯商人」。而且，人們發現莎士比亞對於法律術語的掌握，精準到了不可思議的程度，絕非普通人通過短時間搜集資料所能掌握，若果不是長期在法律行業摸爬滾打，絕對不可能寫出如此專業的論述。在寫此文的時候看到[網上一篇文章](https://kknews.cc/zh-hk/culture/gyv9gl.html)關於莎士比亞法學知識的討論，有興趣可以看看。
#### 醫學知識
莎士比亞的作品中，有 700 多處關於醫學知識的描寫，內容涉及內外科，耳鼻喉，牙科，婦科，精神病學，解剖学等等，這些描寫基本都非常準確，可見作者對醫學知識的了解，也絕非普通人所能夠企及。

### 手稿
網路上還發現有這樣的說法，即莎士比亞沒有留下任何手稿。（但是[也有記錄](https://www.britishlibrary.cn/zh-hk/works/first-folio/)說 《湯瑪斯·莫爾爵士》是目前世上唯一一份含有莎士比亞手跡的手稿。根據筆跡、拼法、詞彙和文中的意象及構思，其中的三頁已鑒定來自莎翁本人。）試想一個撰寫了39部戲劇、154首十四行詩、兩首長敘事詩文學巨匠，怎麼可能沒有真實手稿流傳下來？

除了上面列舉的一些疑點，最近甚至還[有人利用當今科技，使用現在針對學術論文造假的查重軟件，掃描了莎士比亞的著作](https://www.nytimes.com/2018/02/07/books/plagiarism-software-unveils-a-new-source-for-11-of-shakespeares-plays.html)，他們發現莎士比亞的一些作品，與一位曾駐瑞典的大使喬治·諾斯（George North）的手稿「A Brief Discourse of Rebellion and Rebels」有著極多相似之處。

## 馬甲說

正因為上面所述的一些觀點，有很多人認為「莎士比亞」其實只是一個筆名。真正的作者另有其人。而最廣為流傳的人選，就要屬 *弗朗西斯·培根爵士* 和 *愛德華 · 德 · 維爾 牛津伯爵*。

### 弗朗西斯·培根爵士
有人認為，莎士比亞的真身應該是[弗朗西斯·培根爵士](https://zh.wikipedia.org/zh-hk/%E5%BC%97%E5%85%B0%E8%A5%BF%E6%96%AF%C2%B7%E5%9F%B9%E6%A0%B9)。因為無論從教育背景，經歷，專業背景等層面看，培根爵士似乎更符合一個上知天文，下通地理的人設。

![](/image/blog/9w1im.png)

這種質疑聲開始於莎士比亞去世後的200年，一位叫做 Delia Bacon 的美國女學者。她認為莎士比亞戲劇的真正作者是一個由培根爵士領導的編劇小組，而「威廉·莎士比亞」便是他們統一使用的代號。後來這種聲音愈演愈烈，甚至還有人成立了「[培根学会](https://francisbaconsociety.co.uk/)」。这个学会直到今天还依然健在。

![](/image/blog/o8mi8.png)

### 愛德華·德·維爾，第十七代牛津伯爵
另外，在1920年，又冒出了莎士比亞真身的新人選，由作家 J. Thomas Looney 所提出的[愛德華·德·維爾，牛津伯爵](https://zh.wikipedia.org/zh-hk/%E7%88%B1%E5%BE%B7%E5%8D%8E%C2%B7%E5%BE%B7%C2%B7%E7%BB%B4%E5%B0%94%EF%BC%8C%E7%AC%AC%E5%8D%81%E4%B8%83%E4%BB%A3%E7%89%9B%E6%B4%A5%E4%BC%AF%E7%88%B5)。

![](/image/blog/s3eed.jpg)

關於這個牛津伯爵的身世，似乎有很多「狗血」的劇情，這裡就不贅述了。

## 結語
這次之所以會寫這個題目，一方面是好奇，另一方面是因為和朋友的約定。不過一輪「研究」下來，最終覺得質疑莎翁身份這件事，更像是人們茶餘飯後無所事事的談資。

莎士比亞之所以被認為他不囿於一代，而照臨萬世，以致幾百年來，他的作品被後人不斷演繹、解讀、評論、研究、模仿，代代相傳，完全是因為拜讀他的作品時，人們所感受到的那種喜怒哀樂，那種真實，那種浪漫，那種細緻，那種優美。

莎士比亞的力量，是文字的力量。那一部部厚重的作品，深深地激發著人類心中的共鳴。喜劇也好，悲剧也罷，莎士比亞心中的執念，必定是予人向善，讓人看到愛，看到希望。

是的，無論你信或不信，這些文字，就在那裡。

至於這些巨著的封面上的人名是叫做莎士比亞，亦或是櫻木花道，重要嗎？

人已去。 The rest is silence. 

![](/image/blog/rogml.png)






如果有人告訴你，名滿世界的文豪莎士比亞，根本就是另有其人，那些如雷貫耳的巨著，都是出自他人之手，你會怎麼想呢？

你認識的莎士比亞，真的存在嗎？


如今基本任何一個 IT Project 都離不開開源社區中的軟件依賴包( Dependencies )， 在如今越來越注重資訊安全的年代，隨之而來的問題是，誰會能夠保證這些依賴包的安全性？如何監控這些開源軟件包的漏洞？人肉留意最新的漏洞信息，比如關注 [CVE](https://cve.mitre.org/) 網站之餘，有沒有更加自動化的方法？

答案當然是「有」。

## Snyk

Snyk 是一家美國的安全公司，致力於監控開源軟件包中的漏洞。Snyk 以其龐大的漏洞資料庫為基礎（由以色列和倫敦的資安研究專家團隊負責維護該資料庫），持續的監控開源社區中各種軟件包的安全情況，以及給出解決方案。 隨著 Snyk 的不斷發展，它已經可以做到輕鬆掃描，IDE配合，與原碼平台整合 (如 GitHub、BitBucket、GitLab等)、實現 CI/CD 流程。

![](/image/blog/vu9o1.png)

Snyk 雖然是一款商用漏洞掃描工具，但他對開源的項目免費。私有的項目，也可以用每月 200 次的掃描，對於一般的項目，個人感覺免費的計劃已經夠用。

## Snyk 支援的語言
根據[官網的文檔](https://support.snyk.io/hc/en-us/sections/360001087857-Language-package-manager-support)，目前 Snyc 支援以下語言：
- Javascript
- Java
- Python
- Php
- Ruby
- Golang
- Scala
- Swift & Objectiv-C
- .NET
### 對比 npm audit 
`npm audit` 也是一個常用且免費的漏洞掃描工具，snyk 對比 `npm audit` ，檢測能力上要強很多。[可以參考這篇文章](https://www.nearform.com/blog/comparing-npm-audit-with-snyk/)，作者有對兩者進行對比。


## 安裝
Snyk 透過 CLI 方式運行， CLI 的安裝十分簡單， [官網有詳細的介紹](https://support.snyk.io/hc/en-us/articles/360003812538-Install-the-Snyk-CLI)。如果是本地使用，可以透過下列步驟快速安裝：

```bash
npm install -g snyk
```

之後需要進行綁定你的 snyk 賬戶，進行授權

```bash
snyk auth
```

在打開的網頁中授權即可。

## 使用

安裝完成後，便可以使用 snyk 來檢測你的 Project 了。

```bash
cd /my/project/
snyk test
```

![](/image/blog/srhin.png)

## IDE 插件
snyk 對於 IDE 有插件 ( Plug-In) 可以使用，以 Intellij IDEA 為例， 可以在 Market Place 中直接搜尋安裝。

![](/image/blog/bgtpj.png)

裝好後就可以在 IDE 中直接查看檢測結果。

![](/image/blog/q7vad.png)

## 直接掃描 Git 中的項目專案 

Snyk 也可以直接接駁 GitLab， Github 等平台，直接進行掃描。因為我自己一般使用 Gitlab 為主，所以以下便以 Gitlab 舉例：

首先[登入你的 synk 賬戶](https://app.snyk.io/) ， 然後按照指示選擇代碼平台：

![](/image/blog/c8hwr.png)

如果是使用 Gitlab ，則要按 + 來選擇：

![](/image/blog/bb7xk.png)

然後需要你輸入 Gitlab 的 token：

![](/image/blog/ojs8m.png)

這個 token 可以在你的 Gitlab 中新建：

![](/image/blog/dmgdd.png)

之後，就可以選擇 Gitlab 中的 Project 來進行掃描了。

![](/image/blog/l7rb7.png)

完成後就可以查看掃描結果：

![](/image/blog/ujpfj.png)

![](/image/blog/samfz.png)

另外值得一提的是，在集成了 Git 之後， snyk 會自動對你的專案進行掃描，並且自動進行 patch。如果你查看 Gitlab 的 CI/CD ， 會看到 snyk 已經默默的幫你 patch 了一些漏洞。

![snyk 自動進行的 patch](/image/blog/twxil.png)

![](/image/blog/m1luc.png)


## 總結

Snyk 對於開源軟件的安全監控很有幫助，並且能夠非常簡單的使用，乃至整合到 CI/CD的流程中，是一個非常好的安全工具。但需要留意的是， Snyk 是一個依賴漏洞檢測工具，針對的僅僅是已知的軟件漏洞。它並不是一個防病毒工具，不能檢測任何惡意程式， 更不會檢測項目專案中自己寫的代碼。若要掃描自己的代碼，可以使用類似 [SonarQube](https://www.sonarqube.org/)，[Findbug](http://findbugs.sourceforge.net/)等的工具，有時間的話會另文分享。


如今基本任何一個 IT 項目專案都離不開開源社區中的軟件依賴包 ( Dependencies )， 在如今越來越注重資訊安全的年代，誰會能夠保證這些依賴包的安全性？如何監控這些開源軟件包的漏洞？人肉留意最新的漏洞信息，如關注CVE網站之餘，有沒有更加自動化的方法？ Snyk 便是一個很好的解決方案。

使用 Snyk 檢查開源軟件依賴中的漏洞



前不久使用 [Gatsby 將自己網站重寫](https://www.frank.hk/blog/gatsby-website-revamp "用GATSBY 改寫網站，GOOGLE PAGE SPEED INSIGHT 驚現98 的高分")，基本做到了網站靜態化，所有內容都是預先生成，這樣一個顯著的優勢就是讓網站更適合使用 CDN ，藉此提高全球訪問速度。所謂 CDN，就是你的網站資源會緩存一份在 CDN 伺服器，當別人訪問網站時，CDN 伺服器直接返回緩存的資源給用戶，而無需連接本來的原始伺服器。

之前我的網站主要使用的都是 [CloudFlare](https://www.cloudflare.com/)，免費而且有很好的操作界面，功能也很豐富。但唯一的一個問題，也是最關鍵的問題就是 [CloudFlare 國內訪問速度很慢](https://www.google.com/search?q=CloudFlare+%E5%9C%8B%E5%85%A7%E8%A8%AA%E5%95%8F%E9%80%9F%E5%BA%A6%E5%BE%88%E6%85%A2&rlz=1C5CHFA_enHK851HK853&oq=CloudFlare+%E5%9C%8B%E5%85%A7%E8%A8%AA%E5%95%8F%E9%80%9F%E5%BA%A6%E5%BE%88%E6%85%A2&aqs=chrome..69i57.163j0j7&sourceid=chrome&ie=UTF-8)，用了 CDN 反而導致網站打不開。因為中文的原因，我的網誌和網站有大量的內地流量，這個問題導致我最後無奈放棄 CloudFlare。但因為自己的伺服器位於香港，國內訪問速度一般，還是要尋找 CDN 比較好，之後試用了香港的寄存公司 [UDomain](https://www.udomain.hk/en)  的 CDN 服務，感覺發現了新大陸，非常不錯。

用 17CE 測試國內的訪問速度，未經加速的網站資源速度慘不忍睹，數據顯示速度基本都在 「差」和「警告」之間。

![未經CDN加速的訪問速度很一般](/image/blog/irs8o.png)

使用了 CDN 之後，自己也嚇了一跳，竟然一片綠色，全國範圍內都是「好」。

![國內訪問速度測試非常快](/image/blog/4aeqa.png)

原來這個 CDN 是使用了針對國內訪問線路優化的 CN2 網絡，才會有如此優秀的表現。

![CDN使用了 CN2 網絡](/image/blog/njsd5.png)

費用方面，UDomain CDN 提供 [14 日免費試用](https://passport.8338.hk/tc/cdn/signup?actionCode=CDN-TRIAL)，[註冊後立即自動開通服務](https://passport.8338.hk/tc/cdn/signup?actionCode=CDN-TRIAL)。而試用期過後，使用按用量收费的模式，每 GB 流量收費港幣 1.5，像我的網站每月流量不是太多的情況下，這個價錢可謂白菜價 (當然用的越多越便宜)。

功能方面基本的 CDN 功能都很全，控制台界面也很簡單易用。

![設置界面](/image/blog/51m9n.png)

![數據統計](/image/blog/rpftp.png)

另外一個很貼心的設置是，你可以針對非國內用戶設置另外的接入點，這樣的話就可以國內流量走 CDN，其它地區的流量回源或是使用其它的 CDN 服務。

![智能CDN可以設定非國內流量去其它地方](/image/blog/ngfez.png)

傳送門：  

試用鏈接：[按我](https://passport.8338.hk/tc/cdn/signup?actionCode=CDN-TRIAL)

直接開通按用量收費：[按我](https://www.udomain.hk/tc/service/network/china-cdn-content-delivery-network-icp/pricing?cid=8&pcode=CDN-CHINA-ROUTING-PAY-AS-YOU-GO)


網站用 Gatsby 靜態化後，開始尋找 CDN 解決方案，之前使用的 CloudFlare 用了之後國內訪問速度比不用還慢，無奈放棄。 現在使用 UDomain CN2 CDN，速度測試全國一片綠色！感覺發現了新大陸。

超快的中國CN2線路 CDN 推薦 - UDomain CDN



上星期去診所看牙，原本以為杜牙根(牙根管治療)可以解決問題，最後變成了拔牙+植牙。週期拉長了許多，費用也超出了許多，但考慮植牙可能是更長久的方案，也就決定去做了。具體植牙的過程，之後再另文分享。

話說在診所結賬的時候，收費港幣4420，自然是準備用信用卡結賬，結果護士刷卡後，POS機顯示「讀卡故障」。於是護士第二次嘗試，依然顯示「讀卡故障」，最後無奈改用EPS現金支付。因為之前也試過信用卡出現類似無法付款的情況，所以也沒有太在意，以為可能是網絡問題。離開診所後，去健身中心準備取消会籍，正巧要查閱健身中心信用卡扣款的記錄，所以打開了APP查閱，不看不知道，一看嚇一跳，原來剛才兩次顯示「讀卡故障」 的4000多的交易，都已經成功授權，並凍結了信用額度。

![賬單中竟然出現兩筆重複交易，已經授權](/image/blog/fzjbr.png)

於是立即致電信用卡中心查詢情況，銀行說已經成功授權扣款，目前的方案只能聯絡商戶進行取消(VOID)操作。於是立即前往診所交涉，結果對方不知道是不會操作還是系統故障，一番查詢後沒有找到任何交易記錄，耗費半小時後，依然無果。再次致電信用卡中心，銀行建議等待7日看該筆授權是否會「返單」，之後再做打算。於是也沒有其他辦法，只好靜觀其變。

在這個過程中，聽到很多和信用卡相關的術語，比如「授權」，「Hold數」，「返單」，「查單」，「VOID」，「釋放額度」，「誌賬」等等，因此也做了一番資料搜集，為了搞清楚信用卡的工作原理。

整個信用卡的交易，大約涉及 5 個不同的參與者，這也解釋了為什麼信用卡交易總感覺會比較慢。

### 持卡人
持卡人顧名思義就是你自己，手握信用卡的人。當你用信用卡消費時，變開啟了信用卡交易的步驟。
### 商戶
各種商店，餐廳，醫院等等提供商品，服務的機構，就是收取你信用卡付款的地方。
### 收單機構
認可的金融機構，直接面對商戶，受理信用卡支付的相關事項，可以理解為商戶所選用的銀行或金融機構(如 Paypal 等)。
### 清算機構
向成員機構提供信息交換、清算和結算、統一授權、品牌營銷、協助成員機構進行風險控制及反欺詐等服務的機構，最出名的如 MasterCard，Visa， American Express， UnionPay 等。
### 發卡機構
向持卡人發行信用卡，並通過提供各類相關服務的機構，一般為各大銀行，金融機構等。

了解了上述參與者之後，就可以說說一個交易的整個處理流程。

當你用信用卡付款時：

1. 這個收款請求首先經由商戶的 POS 機，到達收單機構。
2. 然後，收單機構聯絡清算機構發送授權請求。
3. 當清算機構收到請求後，會進而再聯絡該卡的發卡機構來進行授權。
4. 發卡機構收到收款請求後，會進行一系列驗證，比如卡片是否正常，額度是否足夠，該筆交易有無風險等。如果驗證通過，則發卡機構會發出授權，並返回一個授權編碼 (Approval Code / Auth Code)，同時，會在你的信用卡賬戶中將相同或相近數量的額度臨時凍結。此時，該筆款項並未從你的賬戶中轉出，僅僅是處於一個凍結狀態，也就是大家所說的**「Hold數」**。
5. 完成上述步驟後，發卡機構發出的授權，會原路經過清算機構，收單機構，返回到商戶的系統中。商戶得到這個授權之後，也就如同獲得了一個付款保障，基本上等同於拿到了一個雙方簽名作實的付款合同，即便未來用戶報失信用卡，更改信用卡號碼，甚至取消信用卡，都可以確保商戶能夠收到款項。
6. 上面說到商戶獲得扣款授權，在這個階段商戶並沒有真正收到真金白銀的款項，該筆款項此時依然在持卡人的賬戶中。直至商戶拿著扣款授權，向他的收單機構請款，這個請款要求也會一路經過收單機構，清算機構，最後到達發卡銀行。這個用授權來進行請款的操作，也就是我們常說的**「返單」**。
7. 發卡銀行收到請款要求後，此時才會真正將該筆資金從持卡人賬戶中扣除(或計入持卡人的賬單中，即**「誌賬」**)，然後將該筆撥款原路經過清算機構返回到收單機構，再有收單機構向商戶付款。
8. 至此，完整的信用卡交易才算完成。

需要留意的是，商戶拿到付款授權後，**一般情況下**商戶會在7日內安排請款，如果7日內商戶沒有請款，則發卡行可能會將之前為此交易凍結的額度釋放。此時對於持卡人來說可以完全感受不到此筆交易的存在，賬單上也不會有任何顯示。**但是，額度釋放並不等於此筆交易取消，因為授權的存在，商戶完全可以在未來的任何時間重新安排請款，即使持卡人已經更換，報失信用卡，在收到請款要求後，都需要向商戶付款。** 這也是為什麼有些人刷卡後，隔了幾個月才會在賬單中看到該筆交易出現的原因。

說完這一堆之後，再回到我的這次經歷，交易是1號發生，如今過去了6天，該筆交易的狀態依然是「待誌賬」( 即已經授權，但商戶未安排請款 )。 回想事件的原因，很有可能是在當時授權信息返回商戶的過程中，出現不明問題導致商戶沒有收到授權資料所致。

在咨詢銀行後，銀行告知在此情況下，有幾種處理方式：
1. 如果商戶沒有發出請款，則不作理會，但正如前文所述，發卡行發出授權，此時資金依然在持卡人賬戶中，一段時間後，之前凍結的的額度也會釋放，對持卡人沒有實際的影響。但是，也正因為已經發出授權(即付款合同已經訂立)，商戶完全可以在未來的任何時間重新安排請款，即使持卡人已經更換，報失信用卡，在收到請款要求後，都需要向商戶付款。所以這種方式有潛在的風險；
2.  聯絡商戶進行取消授權，即**「VOID」**操作，類似商戶主動退款，這樣該筆賬項則會安全徹底地消失；但這樣做相對麻煩，我之前也聯絡過商戶，但他們聲稱在系統中找不到任何資料，所以無法取消，幾次咨詢銀行後，銀行表示需要商戶以授權編號聯絡他的收單機構處理，所以相對複雜；
3.  聯絡你自己的發卡行進行「查單」的操作。這個相對來說是最麻煩的步驟。等同於打官司，銀行會有專門的部門處理，需要持卡人提供一系列的證據，然後由發卡行出面聯絡清算機構，收單機構和商戶去查核賬項，整個過程耗時可能長達90天，而且最後的結果也不保證能夠成功，如果不成功，甚至還會產生手續費。

事情到今天尚未徹底解決，儘管很大機會該筆賬項並不會計入賬戶中，但整個過程也非常令人煩惱。所以今後信用卡消費時，定要特別留意才好。


上星期去診所看牙，結賬時嘗試兩次 POS 機都顯示讀卡故障，本以為網路問題，結果後來發現兩次都已經成功付款。處理的過程中也了解了一下信用卡的工作原理。特記錄於此，希望對其它讀者有所幫助。

信用卡是怎麼運作的? 記信用卡被錯扣$8840之後


最近換了新的 MacBook，必不可少經歷了將舊電腦的資料轉移到新電腦的過程。蘋果的 Migration Assistant 使用上算是非常方便，幾百GB的資料轉移速度也是在數小時之內完成，並且轉移後新電腦基本和舊電腦無縫過渡，這個非常人性化。

然而，順利之餘，也發現了問題。 我原本一直在使用 iCloud Drive 的 2TB 計劃，有大量的檔案都是儲存在 iCloud Drive 中。Migration Assistant 轉移資料時，也順利將所有檔案轉移過來。然而發現新電腦的 iCloud Drive 中顯示有幾十萬個檔案需要上載，開機一天一夜都沒有太多進展。電腦 CPU 長期高負載，出現 `bird` 和 `cloudd` 的進程揮之不去，佔用大量資源。

![](/image/blog/2wqj5.png)

上網 Google ，各種建議都嘗試過，最後無奈唯有徹底關閉 iCloud，然後再重新開啟。結果這樣一操作，所有桌面以及檔案中的文件全部被清除（並沒有刪除，檔案依舊存在於 iCloud Drive 中）。清除也沒問題，心想重新啟用 iCloud Drive 之後應該可以解決問題，可結果重新啟用後，問題沒有解決，反而還帶來了新問題。首先是檔案不會立即下載，開啟 iCloud Drive 後沒有看到任何動靜。網上有人說 iCloud Drive 需要時間去初始化資料夾，於是等了10小時候終於看到資料開始下載了。然而，經過36小時之後，`bird` 和 `cloudd` 的進程依舊揮之不去，依舊長期佔用大量 CPU 資源， 實在不知究竟在做什麼。於是一氣之下將所有重要資料搬離 iCloud Drive，全部改用 Dropbox 。對比之下，Dropbox 的使用體驗簡直拋離 iCloud Drive 幾條街。

那就不妨數落一下 iCloud Drive 的四宗罪：

## 同步遲鈍，下載龜速

iCloud Drive 的同步，真心不知道什麼情況下才會觸發。很久前就試過使用 iCloud Drive 作為 Ulysses 的同步解決方案，結果發現在手機上寫的文章回到電腦上看竟然要等幾小時之後才出現。在電腦的 iCloud Drive 中放入的資料，手機上也要等或短或长的一段時間後才出現。對比 Dropbox，幾乎是立即就會開始同步。這個問題，是我決定拋棄 iCloud Drive 的最重要原因。

## 同步進度是個迷

直到現在我依然不知道如何查看 iCloud Drive 的同步狀態，哪些檔案已經上載了，上載了多少，完全不知道。雖然可以在 Finder 的狀態欄看到大致的情況，但我很想有好像 Dropbox 那樣清晰的狀態顯示。

## 重新安裝電腦後麻煩不斷

這個也就是我本文開始時遇到的問題，`bird` 和 `cloudd` 的進程長期佔用 CPU 資源，然而你並不知道他在做什麼。 iCloud Drive 中的檔案沒有任何變化，逼著人必須關閉再重新啟用  iCloud Drive。 重新啟用 iCloud Drive 之後，完全不知道為什麼檔案要等36小時才開始下載，為什麼不能快速開始，哪怕只是建立一些空的資料夾？ 

## 分享困難

雖然 iCloud Drive 的確是具有分享功能，但設計的非常不友好。相比 Dropbox 簡易的操作，實在還是有很大的進步空間。

![](/image/blog/kc7wk.png)

Apple雖然精於軟硬整合，他打造的 Apple 生態環境也是無人能及。 但是在雲端應用的穩定度以及經驗來說，和專門從事雲端存儲的 Dropbox 相比水準真是差了一大截。

寫到這，忍不住再看看 CPU 負載，真心想問一句，該死的 bird 什麼時候才能消失？

![](/image/blog/xqf8k.png)


iCloud Drive, 你覺得怎麼樣？ 反正我是不會再用它作為主力工具了。 換了電腦後，簡直被他折磨死。Apple雖然精於軟硬整合，他打造的 Apple 生態環境也是無人能及。 但是在雲端應用的穩定度以及經驗來說，和專門從事雲端存儲的 Dropbox 相比水準真是差了一大截。

數數 iCloud Drive 的四宗罪


## Ghost CMS 簡介

Ghost CMS 是一個免費，開源的內容管理系統，截止本文撰寫日期為止在 Github 上有 33.5k 的 Star。Ghost CMS 基於 Node.js ，安裝簡便，自帶一個非常優雅的管理界面，SEO 友好，並且配合強大的API ，非常適合作為 Headless CMS 使用。

![](/image/blog/smqdp.gif)

Ghost CMS 的一大賣點就是他的“可見即可得”編輯器，和大名鼎鼎的 Medium 編輯器非常相似。文字編輯非常輕鬆， 並且可以插入眾多的附加內容，如圖片，相冊，Markdown，影片等等。

![](/image/blog/uhmxu.gif)

除了 Web 版的管理界面，Ghost 還有一些 Native App 可供下載：

![](/image/blog/kyodg.png)

![](/image/blog/zttpz.png)


## Ghost CMS 安裝
### 本地安裝 Development 模式

Development 模式可以很快的安裝好一個本地運行的Ghost CMS， 無需設定任何資料庫, 默認使用 SQLite3 資料庫作為開發使用 。

```bash
# 安裝 ghost-cli 工具程式
npm install ghost-cli -g

# 安裝 ghost CMS
ghost install local

```

安裝完成後就可開啟瀏覽器 [http://localhost:2368/ghost](http://localhost:2368/ghost) 來訪問了。

![](/image/blog/55r5l.png)

注意這個模式下的 Ghost CMS 僅為開發使用，並不適合在伺服器上安裝（即便安裝後也會因為 IP binding 的問題無法遠程訪問）。

### 安裝 Production 模式

若要安裝 Production 模式的 Ghost CMS ， 可以透過以下指令進行：

```bash
ghost install
```

在安裝過程中需要指定資料庫 URL等重要參數，具體可以參考官方詳細的 [安裝指引](https://ghost.org/docs/api/v3/ghost-cli/install/) ，這裡不再贅述。

### 使用 docker & docker-compose 來安裝

使用 docker 來安裝則更加快捷，任何已經安裝 docker & docker-compose 的機器都可快速完成。

我建立了一個已經寫好的 docker-compose 供大家參考， 可以直接 clone 下來再做修改：

```bash
# Clone the template project
git clone https://gitlab.com/frannnnk/docker-compose-ghost-cms-quick-start.git
```

主要需要更改以下檔案中的設定

- `docker-compose.yml`  包含 docker 的設定
- `ghost/config.production.json` 包含 Ghost 的設定
- `ghost/config.development.json` 包含 Ghost 的設定

之後就可以啟動 Ghost CMS 

```bash
docker-compose up
```

## Ghost CMS Admin 界面

啟動 Ghost CMS 後，便可以透過 `http://domain:port/ghost/#/site` 來訪問管理界面。 

Ghost CMS 管理界面的操作都非常簡單，很容易上手。


<video width="100%" controls style={{outline: "none"}}>
  <source src="https://res.cloudinary.com/dxuoive6n/video/upload/v1588584396/ghost-article_bzth93.mp4" type="video/mp4"/>
Your browser does not support the video tag.
</video>


值得一提的是 Ghost CMS 的每篇文章都可以設定針對不同平台的 Meta，例如 meta:description, meta:title, og:description, og:image 等等。這對於 SEO 以及 Marketing 來說非常重要。

![](/image/blog/fv7pj.png)

## Ghost CMS API

Ghost CMS 的 API 針對不同的 Frontend 都有相對應的 starter template，具體可以 [參閱官網](https://ghost.org/docs/api/v3/)。

![](/image/blog/tllxd.gif)

這裡重點介紹一下 Rest API。 Rest API 分為 Content API 和 Admin API， Content API 是以只讀模式獲取 Ghost CMS 的內容， 而Admin API 則可以更改 CMS 的內容。 

要使用API，首先要在管理界面中增加一個 integration：

![](/image/blog/bmrtf.gif)

然後就可以使用  Content API Key / Admin API Key 來調用 Rest API 了。

```bash
curl http://{domain}/ghost/api/v3/content/posts?key={apikey}
```

![](/image/blog/go1fb.png)

API 的具體 Endpoint，可以在 [官網](https://ghost.org/docs/api/v3/content/) 查閱。

以上便是 Ghost CMS 的快速上手，當然 Ghost 的功能還有很多，例如 Theme， eCommerce 等等，如果有興趣，大家不妨仔細閱讀 [官網教學](https://ghost.org/docs/) ，來更深入地了解Ghost CMS 。 



Ghost CMS 是一個免費，開源的內容管理系統，截止本文撰寫日期為止在 Github 上有 33.5k 的 Star。Ghost CMS 基於 Node.js ，安裝簡便，自帶一個非常優雅的管理界面，SEO 友好，並且配合強大的API ，非常適合作為 Headless CMS 使用。本文將介紹 Ghost CMS 的快速安裝以及基本功能，供大家快速上手。

Ghost CMS 快速上手


首先先 Show Off 一下，用Gatsby 改寫網站後，Google Page Speed Insight  一度見到 98 分的高分。儘管這個分數對於普通用戶來說並沒有什麼感覺，但這代表著 Google 大神的肯定！自己那不知所謂的虛榮心瞬間得到滿足。真的要從內心呼喚：

> 了不起的 Gatsby！

![](/image/blog/sw37a.png)

言歸正傳。

其實我自己的網站，已經很久沒有更新。上一次改版已經是2017年的事，年齡增長，工作重心轉移，生活中也被各種瑣事纏繞，之前用心經營的網絡世界，已經慢慢封塵。2017 版的網站，完全是用 JSP 完成，一直以來運行順暢，沒有任何問題，所以自然沒有動力去改寫。直至近段時間，公司有前端愛好者介紹了 Gatsby 這個聽起來像是護髮用品的「東西」，才花時間去研究了一下，沒想到正因為如此，就陷入了 Gatsby 的泥潭無法自拔，趁著放長假把自己的網站改寫，把原本的伺服器大換血，也算是學到了不少新知識。

## Gatsby 是什麼

> Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps

對，Gatsby就是一个基于React 的工具，用於生成網站或者應用程式，並且兼具以下優點：

- 生成靜態的網頁： 非常利於SEO；
- 使用現代化的前端技術： React、Webpack、Graphql 等等；
- 支援眾多的數據源：filesystem，API，database，headless CMS 等等；
- PWA(漸進式網頁應用程式): 按需加載需要的數據，達到快速呈現內容；
- 生成的網頁默認已經進行了優化，比如圖片會生成各種不同尺寸的副本，因應不同裝置選擇顯示不同的圖片，慢加载，等等；
- 眾多的 Plugin 支持：很多你能想象到的功能，都有相應的Plugin 幫你解決；
- 維護相對簡單：因為Gatsby主打靜態化，沒有後端程式，而且使用 React 的 Component 模式開發，維護上相較傳統模式的 app 要簡單。
 
## Gatsby 是怎麼工作的

官網的這張圖，應該能夠比較好的解釋。
![](/image/blog/dnx8a.png)

Gatsby 的工作流程，大約分為幾個大階段：

1. 獲取網站必須的數據。這個數據可以是存儲在文件中，比如 Markdown File，可以是來自 CMS，也或者是 API ；
2. 利用上一步獲取到的數據填充到事先定義好的模板中，並生成所有的靜態頁面，數據文件等；
3. 之後，一個完全可以獨立運作的 App 就誕生了，你可以把 /public 中的文件發佈到任何支持靜態文件 hosting 的地方；

## 用 Gatsby 建立網站具體的流程

用我的網站為例，我這次主要經歷了幾個步驟：

1. 下載  gatsby-starter-blog ；
2. 將我所有的網誌文章都轉換成 MD 文件；
3. 指定 GraphQL 獲取數據的方式；
4. 根據網站的樣式建立 React 的 Component，並在合適的位置填入 GraphQL 獲取到的數據；
5. 後續的優化，分頁，Tag，評論，統計，Client side API 等等 （這一部分也是最花時間的）

有興趣嘗試的話，只需下面幾個步驟，你便可以在你的電腦中運行起一個簡單的[網誌網站](https://gatsbyjs.github.io/gatsby-starter-blog/)了。

```bash
# 安裝 gatsby-cli 工具
npm i -g gatsby-cli

# 根據 gatsby-starter-blog 建立一個新 project
gatsby new gatsby-blog https://github.com/gatsbyjs/gatsby-starter-blog

# 進入新建的 project
cd gatsby-blog

# 啟動開發伺服器，之後就可以透過 http://localhost:8000/ 訪問網誌網站了
gatsby develop
```

如果想要添加新文章，只需在pages 目錄中添加 .md 的 Markdown 文件，就可以自動生成新的頁面。 

當然，上面的例子僅僅是一個開始，諸如分頁，tag，評論等等的功能都沒有實現。這篇文章並不是一個 step by step 的教學，網路上關於 Gatsby 的教學資源非常的豐富，我這裡就不再贅述。

## Gatsby 網站的發佈

用 Gatsby 生成網站之後，發佈其實非常容易。你完全不需要購買任何寄存空間，就可以將你的網站發佈到互聯網。

### 使用 Gatsby Cloud

![](/image/blog/4ergq.png)

Gatsby Cloud 是 Gatsby 官方推出的平台， 官方形容為 “The best way to build and maintain Gatsby sites”。免費版提供免費 build 和發佈，但有一定的限制，具體可以參考[官網的價格說明](https://www.gatsbyjs.com/pricing)。

要使用 Gatsby Cloud 發佈 Gatsby 網站，首先你要有一個 Github 賬戶，因為 Gatsby Cloud 要使用 Github 登入。然後，你需要把你的 Gatsby Project 提交到 Github 中，公開或者私有都可以。然後，你就可以登入 [Gatsby Cloud](https://www.gatsbyjs.com/)， 然後通過幾個簡單步驟就可以將你的網站發佈在互聯網上。

 
<video width="100%" controls style={{outline: "none"}}>
  <source src="https://res.cloudinary.com/dxuoive6n/video/upload/c_scale,q_85,w_742/v1588509617/GatsbyCloud_hmpueg.webm" type="video/webm"/>
  <source src="https://res.cloudinary.com/dxuoive6n/video/upload/c_scale,q_85,w_742/v1588509617/GatsbyCloud_hmpueg.mp4" type="video/mp4"/>
Your browser does not support the video tag.
</video>
 

### 使用 Netlify

![](/image/blog/8akfh.png)

[Netlify](https://www.netlify.com/) 則是一個更為出名的全功能 Web 平台，同樣 Netlify 也是提供了免費的靜態網站寄存服務，並且自動集成了CICD， 可以無縫接駁Github、Gitlab裡的Project，需要更新時只要push到 Git 就可以觸發自動更新發佈。免費版每月可以使用300分鐘的 build time 以及 100GB 的網路流量， 具體的價目表可以參考[其官網的介紹](https://www.netlify.com/pricing/#features)。

在 [Netlify](https://www.netlify.com/) 上發佈，同樣非常簡單，一樣的你要有一個 Github 或者 Gitlab 賬戶，然後，你需要把你的 Gatsby Project 提交到 Github 中，公開或者私有都可以。然後，你就可以登入[Netlify](https://www.netlify.com/) ， 然後通過幾個簡單步驟就可以將你的網站發佈在互聯網上。

 
<video width="100%" controls style={{outline: "none"}}>
  <source src="https://res.cloudinary.com/dxuoive6n/video/upload/c_scale,w_742/v1588514109/Netlify_qcqzxz.webm" type="video/webm"/>
  <source src="https://res.cloudinary.com/dxuoive6n/video/upload/c_scale,w_742/v1588514109/Netlify_qcqzxz.mp4" type="video/mp4"/>
Your browser does not support the video tag.
</video>
 

如今發佈網站竟然如此簡單， 建立網站也早已不再是早些年必須要購買寄存空間的時代。Serverless (即無伺服器運算)當下正大行其道。公司或開發者不用過多考慮伺服器的問題，伺服器資源僅作為一種被簡化的服務而不再以物理硬體的形式出現。

這篇文章寫到這裡應該差不多了，當然在整個網站重構的過程中還遇到了其它很多的問題，我會在之後的文章中再具體分享。 











最近學習了下 Gatsby ，借這個機會將自己網站徹底用    Gatsby 和 React 重寫，過程中學到不少新東西，也經歷不少 WTF 的時刻，完成後用 Google Page Speed Insight 測試，竟然試過出現 98 分的高分，雖然不是每次都這麼高，但也足以驚艷我這見慣了幾十甚至十幾分的大腦。

用Gatsby 改寫網站，Google Page Speed Insight 驚現98 的高分


自己一貫對各種 IT，科技產品有著濃厚的興趣，每年總會買入很多科技產品，但並非每樣產品都是明智的消費，當中不乏三分鐘熱度的消費，購入之後後悔不已。此文回顧一下2019年在 Gadgets 上的消費，明智的和不明智的，供路過的讀者參考，供日後的自己回顧。


## Apple Homepod
![HomePod](/image/blog/ndutt.jpeg)
- 價格指數： \*\*\*
- 使用頻率：少
- 現時情況：基本僅用於 Siri，播放音樂的時間很少

Homepod 當時是朝著蘋果的品牌而去購買的，買回家後發現其音效並沒有想像中那麼好，Siri的確是比較靈敏，但是也因為如此搞到每次叫Siri的時候不知道是手機，手錶，還是 Homepod 會回應。
#### 如果可以再考慮
還是會買，雖說用處不是想像中那麼大，但是偶爾播放一下音樂也是不錯。另一方面是因為它和其他蘋果生態圈的設備無縫連接，其他裝置可能做不到這麼好。

## 小米VR 一體機
![小米 VR 一體機](/image/blog/vypmr.jpeg)
- 價格指數： \*
- 使用頻率：少
- 現時情況：封塵

買入小米VR一體機，主要是因為它是和大名鼎鼎的 Oculus 合作，硬體上完全和 Oculus Go 是一樣的。再加上聲稱的龐大內容庫，感覺應該是VR眼鏡中不錯的選擇。可是買回來之後發現即便硬體相同，軟件層面卻是完全不同，甚至可以說是兩個完全不同的系統，Oculus 上面的許多內容都被閹割，而且無法越獄改變版本。
#### 如果可以再考慮
不會買小米版，會考慮買 Oculus Go，當然這個結論是基於自己已經用過一段時間後已經沒有新鮮感的時候來說的。

## SONY WF-1000XM3 降噪耳機
![](/image/blog/klrxf.jpeg)
- 價格指數： \* \*
- 使用頻率：少
- 現時情況：已經轉手賣出

買入WF-1000XM3，全因網路上一致的好評。說他音質出色，續航優秀等等。購買前在 Youtube 上看了不少的開箱，Review，使用體驗等等，基本都是一面倒的正面評價。

買回來之後，第一個感覺就是佩戴不舒適，感覺耳朵脹痛，甚至聽不到半小時就疼痛難忍，不得不取下。另外它的體積也不算小巧，隨附的充電盒也比較巨型。轻触式操作有時候有些難以捉摸，明明按下了卻沒有反應。和別人說話時一定要取下才行。音質方面的確是可圈可點，效果非常不錯。

後來由於是在無法忍受佩戴的不舒適感，遂無奈轉手出售，用 Jaybird Tarah Pro 取代之。

#### 如果可以再考慮
不會買。

## Jaybird Tarah Pro
![](/image/blog/vpzzz.jpg)
- 價格指數： \* 
- 使用頻率：經常
- 現時情況：使用中，但基本被 AirPods Pro 取代

購買Jaybird Tarah Pro 的經歷比較曲折，原本是買入了 Jaybird X4，也是因為網路上比較多人推薦，而且輕便，自帶頸繩，這樣在不需要使用的時候能夠很輕易的掛在脖子上而不用找地方收納。

然而買回 Jaybird X4 之後，發現其電池續航實在不敢恭維，充滿電，回到公司電力已經掉了一半，這個非常不能接受，若是這樣正常使用估計一天要充兩次電。後來上網搜尋，到未有見到類似的狀況，所以不排除是個別情況。然而在搜尋過程中發現了Jaybird Tarah Pro ，這個相比 Jaybird X4 大大提升了電池續航，而且使用的材料以及音質都有不同程度的提升，所以和當初購買Jaybird X4的店鋪老闆詢問，可否退回X4，價錢購買Jaybird Tarah Pro。這裡要好好稱讚一下**觀塘榮昌工業中心5樓**的店鋪老闆，二話不說就同意了我的要求，當下他並沒有Tarah Pro 的存貨，他立即主動前往經銷商處幫我購入Tarah Pro，數小時內就完成更換。今時今日，這樣的服務態度，實在是以客为本，令人稱讚！以後有需要定會繼續找他。

Tarah Pro 的各方面表現均很出眾，電量續航基本一星期正常使用沒有任何問題，如果不是重度使用，數周續航都不成問題。我印象中在買回之後都沒有怎麼充過電。而且支援快速充電，充電五分鐘便可以續航2小時。Tarah Pro 也是全身IPX7防水，基本不用擔心入水的問題。它的音質也非常出色，低音非常強勁。另外配備 Jaybird App，可以設定不同的場景模式，或者下載其他人設計的場景模式，從而達到不同的音質效果，這個設計也非常的讚！

如果說缺點方面，一個是不支援主動降噪模式，（這個可能是我一直使用主動降噪耳機而養成的癖好），但其實本身 Tarah Pro  是封閉式入耳設計，所以隔音效果已經很好，倒不是很需要主動降噪。另一方面是它的充電線是使用自家專有線，跟機只有一條，所以若是丟失，或者忘記帶的話就完全沒有辦法充電。解決方法自然是萬能的淘寶，能用很低的價錢買到原廠的充電線，所以我現在總共有三條充電線，基本夠用了。

所以一句話總結就是非常非常滿意。儘管之後的 AirPods Pro 取代了它成為我的主力耳機，但Tarah Pro 依然會成為我首選耳機之一。

#### 如果可以再考慮
如果沒有 AirPods Pro 的話，一定會買。

## Bose Sleepbuds
![](/image/blog/yzizi.jpg)
- 價格指數： \* \*
- 使用頻率：經常
- 現時情況：仍在使用，但產品已經因電池問題停產

因為睡眠比較輕，特別是因為養貓的緣故，我晚上睡覺基本都要使用隔音耳塞。 得知 Bose Sleepbuds 能更用「遮噪」的方式提升睡眠質量，也忍不住一試。其實它是透過播放白噪音，比如流水聲，飛機轟鳴聲，風聲等等，麻痺大腦，覆蓋周圍的其它噪音。使用上開始不怎麼習慣，因為畢竟是有聲音在耳朵裡播放，後來使用幾次之後慢慢習慣，發現效果還真的不錯，睡眠質量有改善。

然而，好景不長，使用幾次之後就發現開始無法充滿電，每次總有一邊耳塞只能充電到 58% 就無法再繼續充電。因此晚上睡到一半，一邊的耳塞就停止播放，反而會因此而甦醒。後來找 Bose 售後服務中心，他們的服務倒非常不錯，立即幫我更換了全新的產品。然而，同樣的問題再次發生，於是再次更換，但問題依舊。所以來來回回更換了 5 次。直到最後一次更換，問題都沒有解決，所以基本認定是殘品缺陷，我已經放棄了繼續更換，想先等一段時間之後看看新的批次產品可否解決這個問題。

然而，時隔半年後官方竟然[宣佈產品停產](https://www.bose.hk/zh_hk/support/products/bose_headphones_support/bose_in_ear_headphones_support/noise-masking-sleepbuds.html)。正式因為無法解決的電池充電故障。可惜我看到這個消息時，已經錯過了退款的最後期限，所以也只能暫且將就使用了。

#### 如果可以再考慮
除非解決充電問題，否則不會買。

## Frontrow Camera
![](/image/blog/autdq.jpg)
- 價格指數： \* \* \*
- 使用頻率：偶爾
- 現時情況：使用中

Frontrow Camera， 說它是相機，其實它更像是一部生活記錄器。他的主打功能是 Story Mode，就是每隔一段時間（幾秒到幾分鐘），就會自動拍攝一張照片，然後可以將一天下來的所有照片合成為一段影片，你可以清楚地回憶這一天去過哪些地方，做過哪些事，類似 Time-lapse的概念。 

當然，作為一款相機，普通的相機功能它安全支持，Android 系統，高清觸屏，800萬像素主鏡頭、500萬像素背部鏡頭，148度廣角拍照，錄影，而且擁有直播模式，透過Facebook, Twitter 或 Youtube直播影像。

這個產品最大的好處便是用在旅行的時候或是生活中的重要時刻，你不想錯過每一分鐘的畫面，只要掛在脖子上，剩下的就交給它吧。

若說到它的缺點，剛開機的時候連續升級了5，6次，讓人有點無法接受，不知為什麼系統升級不能一步到位，而是要經歷所有的版本一個一個向上升級。另外就是估計它的售後服務基本為0，一旦故障，要麼寄回美國，要麼買一台新的。

#### 如果可以再考慮
一定會買。

## iPad Pro
![](/image/blog/k0xf7.jpg)
- 價格指數： \* \* \* \* \*
- 使用頻率：經常
- 現時情況：使用中

iPad Pro， 應該不用過多的介紹。對於是否需要買 iPad Pro，這個的確和你的工作和生活模式有關。之前一段時間我覺得 iPad 完全沒有任何意義，因為基本只是一個放大的 iPhone，所有功能都可以用 iPhone 做到，但後來，慢慢發現 iPad Pro 有非常大的不可取代性。

我會用他：
- 做筆記。 這個如果有學習的需要，配合 Apple Pencil，絕對是非常好的筆記工具。
- 寫文章。在沒有電腦的情況下，配合 Smart Keyboard，基本的文書操作完全可以用 iPad Pro 取代，在 iPad 上打字的感覺和在 iPhone 那塊小熒幕上輸入完全不可同日而語；
- 作為附加顯示器。新版本的iOS支援 iPad 作為附加顯示器，這個對於 IT 人士來講非常不錯。
- 畫圖。Procreate這個神器，iPad Pro 可以用來創作無窮無盡的世界；
- 看Netflix。 這塊大熒幕的好處，便是可以更舒服的看影片，飛機上用來看 Netflix，再適合不過了。

#### 如果可以再考慮
會買。

## DJI Mavic Mini
![Mavic Mini](/image/blog/dotfs.jpg)
- 價格指數： \* \* \* 
- 使用頻率：很少
- 現時情況：給了父母

Mavic Mini是我購買的第一台航拍機，一直以來都覺得航拍機受到的法例上的限制太多，沒有辦法充分發揮它的功能。每次使用前都要做足功課，研究當地法律，而且航拍機的體積都很龐大，旅行時攜帶非常不方便，所以一直沒有購買。直到 DJI 出了 Mavic Mini，超級輕便的重量，在很多地區都在監管紅線以下，決定入手一試。

買入後感覺也很不錯，小巧上手，使用上非常方便，拍攝的畫面称不上惊艳但也還不錯，去台灣旅行時也帶上它拍了一些影片。

至於不足方面，因為太輕，稍微有點大風的場合就無法起飛，而且沒有避障功能，飛行的時候要非常小心。另外訊號接收方面似乎很容易斷線，稍微有點阻隔就短線自動返航了。

但作為入門型的航拍機，感覺還是非常不錯的。

#### 如果可以再考慮
會買。


## SanDisk Extreme Portable
![](/image/blog/28lwr.jpg)
- 價格指數： \* 
- 使用頻率：很少
- 現時情況：封塵

SanDisk Extreme Portable 就是一款高速 SSD 存儲器，賣點就是小巧輕便，速度快。當初購買是為了旅行時萬一有存儲上的需要就可以將手機上的資料轉存到它裡面，但後來發現它不支援iPhone手機（但支援iPad），所以也只能作為普通的外置硬碟使用。在平時的工作生活中，現在各種雲端硬碟都很方便，能用到它的場景非常有限。

#### 如果可以再考慮
不會買。

## AirPods Pro
![](/image/blog/yskqf.jpeg)
- 價格指數： \* \* 
- 使用頻率：每天
- 現時情況：每天使用

兩個字，完美。

完。

#### 如果可以再考慮
還用問嗎？


2019年買過不少科技小玩意，HomePod, 小米VR, Jaybird Tarah Pro, Frontrow Camera, DJI Mavic Mini, Bose Sleepbuds 等等。 這裡回顧一下本年在 Gadgets 上的消費，明智的和不明智的，供路過的讀者參考，供日後的自己回顧。

回顧2019買過的 Gadgets


毫不誇張的說，這是我看過近幾年來最好看，最觸動人心的影片。

周六的下午，被悶熱的天氣衝擊的頭暈腦脹，拿起手機，看看現在正在上映的電影，復仇者聯盟終於不再是第一位，不想看打打殺殺的 John Wick ， 對 Pokemon 也興趣不大，最後眼睛被 「淪落人」吸引住。

看到電影的海報，第一印象就覺得這會是「閃亮人生 The Intouchables」的翻版，而對於主角黃秋生，也沒有特別的感覺，因此沒有期待這部電影會有多出色，但鑒於對 The Intouchables 的喜愛，以及出於對高分影評的好奇，購票進場。可真沒有想到，這部電影，對我的觸動竟是如此之大。

![](/image/blog/vbroh.jpg)

影片講述的是一個高位截癱的香港人，妻兒都不在身邊，獨自一人住在政府公屋，因此需要請一位「菲傭」照顧生活起居。而請到的這位菲傭不怎麼會廣東話，於是兩個人之間發生一連串的碰撞，誤會，笑話。從開始的完完全全的主僕關係，逐漸變得互相理解，互相支持，最後僱主昌榮全力支持菲傭 Evelyn 去追尋她的攝影夢想的故事。

影片的故事主線其實並不複雜，但影片所刻畫出來的細節，反映出的社會現實，都令人感同身受。香港有大量的菲傭、印傭，每到週日，總會在城市的角落發現他們的身影，三五成群，圍坐在紙皮上，嘻嘻哈哈，享受著她們自己的樂趣。而香港人，對於她們的態度呢，很多人會很自然地稱她們「賓妹」，「賓賓」，即使不說出口，也會從內心有一種自我優越感，感覺她們低人一等。記得幾年前有一次去中環，途徑一個天橋，發現那座天橋已經被「攻陷」，滿滿全是菲傭印傭，當時自己內心中著實是非常抵觸，大聲說著「唔該，唔該」，其實是想說「走開，別擋路」。影片的前半部分，男主角昌榮也是如此，言語中對 Evelyn 都是有一種呵斥，命令。當 Evelyn 談到自己的夢想時，昌榮甚至很自然地充滿鄙視地說「菲傭講咩夢想啊」。 想想看一個高位截癱的「淪落人」都能這樣，那一般的正常人就更不用說了。

但這部電影之所以觸動人心，正是因為後來昌榮對 Evelyn 的態度開始發生變化。具體情節就不多說了，有催淚的，也有讓人笑噴的，戲院內總是抽泣聲和笑聲此起彼伏。兩個淪落人，一個因為從天而降的意外而跌入谷底，一個因為家庭的不幸而要遠赴他鄉從事最底層的工作，就這樣，相遇，相知，彼此感動著彼此，找到了直面人生和追夢的勇氣。

傭人，是一個工作，但又怎會僅僅是一個工作。記得我小時候，家裡也請過傭人照顧我，雖然我現在已經沒有太多的印象，但是可以肯定的是當時自己是把她當家人一般對待。影片中的一個細節，一個 Evelyn 的朋友說起自己照顧了十幾年的老太太離去之後，那撕心裂肺的痛哭，揪人心脾。不難看出，她已經把僱主當做親人，那種傷心，發自內心。我深信這世界上人與人本平等，無論你社會地位有多高，絕對不要認為自己比其它人高人一等。任何善良的靈魂都值得尊重。

而這部電影之所以觸動我的另外一個原因，是因為最近自己去菲律賓多了，更了解這個國家和那裡的人。菲律賓給我的感覺是真誠，熱情，人與人距離很近。

馬尼拉有BGC (Bonifacio Global City)， 這裡高樓林立，遍佈各種世界級大公司，知名酒店，商場中高端名店應接不暇，馬路寬闊， 交通順暢，宛若在歐洲一般。

![](/image/blog/hua5h.jpg)

馬尼拉也有 Tondo ，這裡生活著最底層的人們，食不果腹，衣不遮体，你可以用最陰暗的形容詞來描述這裡，甚至出租車司機都拒絕前往這裡。

![](/image/blog/etg1l.jpeg)
 
的確，菲律賓有很多窮人，收入低的不敢想象，這裡人均月收入，只有大約 2,000 元港幣上下，即便相同性質的工作，收入也遠不及香港同等性質的工作，因此很多人被逼必須離鄉背井。每一個離開菲律賓的人，都背負著無奈，背負著家人的期望，背負著不向生活妥协的堅強，這種人，更值得尊敬。

「淪落人」並沒有什麼大場面，更沒有什麼精彩的視覺特效。但整個電影都能夠喚起強大的共鳴。兩位演員的表演，讓整部電影如同暖流一般穿透身體。從戲院走出來，周遭依然繁忙紛擾，陽光照在臉上，深呼一口氣，內心覺得非常溫暖。

> “Still Human , Still Dreaming."


「淪落人」並沒有什麼大場面，更沒有什麼精彩的視覺特效。但整個電影都能夠喚起強大的共鳴。兩位演員的表演，讓整部電影如同暖流一般穿透身體。從戲院走出來，周遭依然繁忙紛擾，陽光照在臉上，深呼一口氣，內心覺得非常溫暖。黃秋生和孔尚治的走心出演，毫不誇張的說，這是我看過近幾年來最好看，最觸動人心的影片。

淪落人


![日本夜景](/image/blog/ycp5x.jpg)

### 起源 ###

終於踏上了日本之旅，這個並不太吸引但又有種魔力的國度。不吸引的原因大約是因為太多人去，沒有一種「探險」的味道，再加上發達大城市估計也和香港大同小異，沒有太多的新意。至於充滿魔力，全因估計我已經不知道聽過多少人說日本是一個完美的國家，一切都是難以置信的有理有序。因此對這個國家充滿了好奇感。所以，就有了這次不長不短的，三天三夜日本之旅。

### 機場 ###

從公司出來，去巴士站搭機場巴士。午餐時間，在繁忙的觀塘工業區，拖著行李穿梭在西裝革履的人群中顯得格格不入，或許是還沒有從剛剛的工作會議中脫離出來，大腦似乎還沒有進入旅行狀態，覺得有點疲勞。坐上巴士渾渾噩噩就搖到了機場，想想看這好像是我第一次在下午來到機場，感覺機場裡面的人和物好像都處於一種慵懶的狀態，和之前的感覺很不一樣。

手機登機證讓我避開了蜿蜒的人龍，直接前往登機口，看看時間，竟然還有三個多小時。閒來無事，周圍走走，拍拍照，上上網，當然要借這個機會試試看經過 CDN 加速的網站在機場速度如何，結果感覺很快，不錯不錯。正在因為無聊而差不多要見周公的時候竟然發現相機的眼罩竟然不知所終，頓時有種晴天霹靂的感覺，睡意全無，雖說並不會太影響拍照，但這成功破壞了本應「完美」的設置。

### 飛機上 ###

![機艙內](/image/blog/8vwn8.jpg)

4 小時的飛行，真是疲憊不堪。沒有網絡，手機的功能立即被閹割了九成。聽聽歌，閉目養神，就這樣，降落在了羽田機場。

### 羽田機場 ###

一下機，已經感覺到了日本的不一樣。機艙門口的地勤人員對每一位乘客面帶微笑，鞠躬致意，笑容也是那種走心的微笑。因為要趕最後一班 JR 火車，下機後一路小跑，沒有太多的時間去仔細觀察羽田機場。或許是乘搭廉航的緣故，停機位距離入境檢查櫃檯十分十分遙遠。連跑帶走估計有十來分鐘才到入境檢查櫃檯。

入境檢查都十分順利，人龍很長但秩序良好，很快就通過檢查，海關人員也十分友好。

### 地鐵 ###

海關出來後，單軌電車的指引非常清楚，很快就找到了售票處，但看到這密密麻麻的車站，和看起來不怎麼友好的售票機，有點不知道要怎麼辦才好。因為時間原因也沒顧得上仔細研究，看到「浜松町」三個字就匆忙買下車票。

![](/image/blog/0g6u6.jpg)

![](/image/blog/0n1e3.jpg)

![](/image/blog/zolv8.jpg)

很快，就上了單軌電車，終於不用在機場過夜，心裏暗自慶幸了一下。

![](/image/blog/8utfl.jpg)

到了浜松町，轉車的時候遇到麻煩，將在機場買的車票放進閘機後就不知道要怎麼辦，一通詢問之後才知道原來買的票只是到這裡為止，若要換成山手線要在「精算機」做票價修正，而我已經把之前的票投入了閘機，所以值班的小哥耐心的幫我重新拿出一張臨時票，再在「精算機」上操作。其實可以直接在機場買中轉票，或者直接買 suica 卡（類似八達通的卡）大可不必這麼麻煩。

![](/image/blog/n9nlw.jpg)

![浜松町](/image/blog/dsqub.jpg)

然後，就真正搭上了日本的 JR 山手線，一下子撲面而來的日本氣息，擋也擋不住。將近凌晨一時，地鐵內竟好像早高峰一樣人頭攢動，每個人的臉上都透露出無限的疲倦，這個場景，加上車廂內色彩繽紛的各式廣告標語，彷彿宣告著，我，終於來到日本了。

![](/image/blog/axcpe.jpg)

### 初印象 ###

對於日本的初印象，其實在 JR 上已經感受到了。禮貌，繁忙，有序，辛苦，色彩繽紛，標語這些關鍵字可以概括一二。從 JR 線日暮里站出來，順利和朋友會合，至此也就結束了我「on my own」的場景，餘下來的時日，基本都像一個半白癡一樣，跟著日本通探索東京。

酒店附近，出租車好像方陣一樣整齊排開，但估計日本出租車這東西，也只能是看看而已。出租車司機西裝革履，禮貌恭謙，五星級的服務自然也是五星級的價格。還是看看就好了。

![](/image/blog/fgsqa.jpg)

這家叫做「日高屋」的中日混搭餐廳，將會被載入我的史冊。因為此生在日本的第一餐飯，在這裡隆重登場（笑）。

![](/image/blog/9ojsz.jpg)

凌晨時分，店內人不多但也不冷清，和印象中的日本餐廳的感覺非常吻合。叫了一碗麵，不油不膩，不鹹不淡。第一餐飯，完美！

![](/image/blog/dgihg.jpg)

![](/image/blog/pept1.jpg)

### 酒店 ###

日本的酒店，估計和香港一樣，「鳥籠」感十足。是次入住的酒店，應該算是歷來住過最小的酒店前三名了。屋內將行李箱打開後基本無法落腳，但不同之處在於，小，但五臟俱全，該有的全都有，不該有的也都有。而且溫馨舒適，不會有很強的壓抑感。一切設施，都一塵不染，而且諸如水龍頭，馬桶蓋，空氣清新機等，都充滿了科技感。除了枕頭比較低之外，也沒有什麼其他可抱怨的了。

酒店很小，小到無法拍照（笑），只能從模糊的背影中感受一下了，多謝這支提前準備好的透明可樂。

![](/image/blog/fdog2.jpg)

### 疲勞的日本人 ###

不想像流水帳一樣記錄日本的每一個行程，我想更好的方式是選擇一些觸動我的吸引我的地方，寫下來，供日後回味，會是更好的方式。

之所以這個點叫做疲勞的日本人，因為很多場景下，地鐵上，街上，無論什麼時候，都能看到昏昏欲睡的人們，穿的光鮮亮麗，但難掩一身的疲憊，借助僅有的一點時間，放鬆一下疲憊的身心。日本的工作壓力，可想而知。

![](/image/blog/0pykc.jpg)

### 複雜的交通 ###

日本的公共交通，已經找不到詞去形容其發達程度。先不提巴士，僅僅是軌道交通，就已經多到讓人眼花撩亂，頭皮發麻。不同的鐵路公司，各自經營不同的線路，地上的，地下的，單軌的，雙軌的，光是 JR 的線路圖，已經是密密麻麻讓人產生密集恐懼，如果加上地鐵，機鐵，各種不知道什麼鐵，算起來總共超過50條不同的軌道線路，真是難以想像是如何一種場景。乘搭軌道交通，一定要頭腦清醒，做足準備，隨便一個車站，就能換乘一堆的其他線路，去一個地方，有 n 種不同的乘搭方式，但注意了，可要看清楚你手中的票，要是買了 JR 套票，對不起地鐵不能用；要是買了東京地鐵套票，對不起 JR 不能用。如此情況，每次乘搭地鐵，總覺得如臨大敵一般，Google Map， Japan Travel 各種程式都看遍，才能稍微有點頭緒。

![](/image/blog/w1acx.jpg)

![](/image/blog/mxtrl.jpg)

### 廁所 ###

日本的廁所，毫不誇張地說，是所有我去過的國家中，甚至應該說包括沒去過的國家中，最乾淨，最智能的。這次日本四天，去過的所有廁所，是所有廁所，包括酒店的，火車站的，商場的，馬路邊的，都是乾乾淨淨，基本上沒有任何污漬，而且全部都配有電動清洗馬桶蓋。舉例下面這個路邊商店的廁所，一開門進去本來蓋住的馬桶蓋自動開啟，再次沖水，加熱，著實讓我覺得走進了科幻世界。使用後的各種自動清潔功能，更是眾所週知。為了遮蔽如廁時發出不雅的聲音，還可以播放虛擬沖水聲，這些細節，體現出日本這個國度的與眾不同。

![](/image/blog/pvxik.jpg)

### 便利店 ###

日本的便利店，除了多之外，出售的商品種類也非常齊全。酒店附近的 Family Mart，各式各樣的食品琳瑯滿目，擺放整齊有序，味道也非常棒。

便利店中除了出售食物，生活用品，甚至還有影印機，提款機，WiFi熱點等等，將「便利」二字發揮到極致。

![](/image/blog/ukimo.jpg)

![](/image/blog/sgnio.jpg)

### 自動飲品販賣機 ###

自動販賣機也是一個亮點，街道上每隔每隔一段距離就能發現幾台甚至十幾台自動飲品販賣機，售賣各種各樣千奇百怪的飲品，如此繁多的販賣機，但幾天下來從未見到補貨的情況，估計補貨都是發生在凌晨？很難現象這些販賣機背後的供應鏈和管理系統是發達到什麼程度。

聽說日本的自動販賣機公司，允許民眾打電話通報哪裡沒有販賣機覆蓋，一旦成功設置，通報的人會得到一筆不菲的獎勵。

![](/image/blog/ycfjq.jpg)

### 禮貌的人們 ###

日本人有禮貌，這估計是地球人都知道。但當真正踏足這裡，才能夠真正感受到他們有禮貌到什麼程度。路邊地盤的工人，疏導完交通後集體鞠躬給等候過路的行人；任何一個商鋪的職員，在付款收款時都不斷地面帶微笑重複著一些聽不懂但能感受到的語言表示感謝；地鐵站的職員，看到你面露難色時主動上來恭敬地詢問你是否需要幫助。

![](/image/blog/nkbvy.jpg)

### 十字路口 ###

幾天的東京遊，對過十字路口的印象也是十分深刻。曾經在電視上見到的 SHIBUYA 路口，終於是感受到了那種壯觀。交通燈發出一種類似鳥鳴一樣的，遙遠的，夢幻的提示聲音，人們猶如流水一樣穿過馬路，幾秒過後馬路又變得空空蕩蕩，週而復始。多少人在這個十字路口擦肩，茫茫人海，在這裡不期而遇，但你又可曾注意到他的存在？

![](/image/blog/qless.jpg)

![](/image/blog/hjkpn.jpg)

![](/image/blog/1g0sg.jpg)

### 街道 招牌 ###

東京的街頭，五顏六色的招牌一次又一次的提醒著自己這裡就是日本。各種不同的招牌，都極盡全力地展示著自己，相比香港的霓虹招牌，日本的招牌似乎顯得更為鮮豔，而且似乎很少有香港的橫式招牌，都是直立為主，因此看上去非常整齊俐落。

![](/image/blog/ettnm.jpg)

![](/image/blog/wvsjd.jpg)

![](/image/blog/ncabz.jpg)

夜晚的招牌，則更能顯示出美感，燈光的映襯下，已經成了一道獨特的風景，吸引著人們的目光。

![](/image/blog/ode6b.jpg)

![](/image/blog/isnbs.jpg)

![](/image/blog/dtpr6.jpg)

### 夜景 ###

東京的夜景，早有耳聞。這個繁華都市的夜晚，絢麗地讓人沉醉。身為一個過客，遊蕩在東京街頭，倒是有一種事不關己的自在。看著周圍五光十色的建築，身旁衣著光鮮但面帶倦色的人們，真的很想知道，生活在這樣的大都市的日本人，是「怎樣的一種體驗」。

![](/image/blog/offxy.jpg)

![](/image/blog/zetpm.jpg)

![](/image/blog/baxxt.jpg)

### 藍瓶子咖啡店 ###

藍瓶子咖啡店，是因為同事的推薦專程拜訪。很早前就在 instagram 看到過這個 IG 咖啡店，這次再經一位對咖啡很有研究的同事特別介紹，所以特別留了一下午去這裡一探究竟。

這間店的位置不是市中心，周圍的環境和市中心相比宛如兩個世界。這裡的周遭十分寧靜、休閒，沒有市中心那種繁忙和極速。這裡給人的感覺就是一個寧靜的日本。

![](/image/blog/kkoga.jpg)

![](/image/blog/aanbi.jpg)

![](/image/blog/onjvi.jpg)

而藍瓶子咖啡店，就坐落在這裡。這咖啡店也是連鎖企業，隸屬於雀巢集團。論咖啡的質素，比星巴克的咖啡，口感上要來的更柔和和回味。因為並不是專業人士，所以不做太多評價。但不難看出，相較其他咖啡店，這裡的工作人員對於沖調咖啡，有著不一樣的熱情。

![](/image/blog/6itoq.jpg)

![](/image/blog/jicgz.jpg)

![](/image/blog/whgy4.jpg)

![](/image/blog/hfxi9.jpg)

店舖的後半部，就是他們的倉庫。所以整個店舖有種走入咖啡工廠的奇妙感覺。空間感非常強，沒有星巴克那種擠迫的文藝感。

![](/image/blog/zi7su.jpg)

### 電子市場 ###

![](/image/blog/nqkf7.jpg)

秋葉原的電子市場，一進去之後似乎有點喘不過氣的感覺。龐大的賣場裡面，各種各樣的電子產品應有盡有，各種搶眼的標牌隨處可見，放眼望去，密密麻麻。東西雖然多，但不覺得亂，一切都是非常有序地排列著。

### Sky Tree ###

Sky Tree 是日本的第一高塔，全世界世界也算是數一數二的高塔了。這次有幸上到塔頂 445 米處遠望東京，這個景象著實驚到我哇的叫了出來。放眼望去密密麻麻的東京市區盡收眼底。

![](/image/blog/z3tdf.jpg)

![](/image/blog/h1boy.jpg)

![](/image/blog/ij2x6.jpg)

### Diver City 高達 ###

Diver City 門前的高達也是東京的一個亮點。這個高達的細節都是十分的逼真，包括所有的螺絲位，標籤，警告標語等等，真的讓你覺得下一秒他就要變形。 專門等到下午三點的表演，本以為他真的可以變身成其他什麼東西，不過看來是我想多了。

![](/image/blog/f46hh.jpg)

![](/image/blog/g6t35.jpg)

### 結語 ###

短短三天的日本之旅，留下了深刻的印象。非常明白為什麼那麼多人喜歡這個國家。我想每一個外來者都會被這個國家驚艷到，被這裡的人們驚艷到。這裡乾淨，有序，這裡的人們友善，禮貌，溫柔，和氣。即便是平時大大咧咧的人，來到這裡都會不自覺的被感化，被影響。

然而，身在這個國家的人們，他們是怎麼一種體驗？想想看，在這樣的一種環境中旅行是好，要是工作，無形之中會多了很多壓力，這也是為什麼看到那麼多疲勞的日本人的緣故。日本是一個以和為貴的民族，萬事講究和氣，每個人都客客氣氣，即便是不同意的，不喜歡的，也不會直接說明。這種情況下，可想而知會有很多不成文的禮數，約束，規則，規矩籠罩著你，壓得你喘不過氣。高度自律的國家，人們都生活在各種條條框框之下，戴著各自的面具生活。外人看起來光鮮亮麗，羨慕非常，但或許距離最本我的自己，卻愈走愈遠。

![](/image/blog/4dqff.jpg)

![](/image/blog/fvpyq.jpg)

![忠犬八公](/image/blog/ny0fb.jpg)


終於踏上了日本之旅，這篇網誌，記錄下日本給我留下的初印象。

日本 初


有點不知道要怎樣提筆。多麼想說「這次終於考過啦。」可事與願違，第二次考車依然是「雙肥」。

說實話有點沒有想到這次會有如此結果，棍波轉換為自動波，難度有了很大的降幅，而且考前的練習均沒有任何失誤，可沒想到考試第一個環節泊位，就因為緊張搞到「扭錯胎」，左右不分，又要「考牌主任做出行動」。心知這次又要「肥佬」，心情一下沉入深海。出師不利的確十分影響心情，雖說隨後調整心情，路試還算可以，但最後真是有點「撞邪」的在迴旋處選錯了行車路線，被考牌主任踩剎車，又拿到一個「嚴重」錯誤。

拿著成績單，心情失落。兩次都是「雙肥」，讓我有點「懷疑人生」(笑)。但我向來不是容易放棄的人，越是失敗，越要再戰。考車這個東西，真的需要過硬的技術加那麼一點運氣。本來想立即報名快期重考，後來想想看一不買車二不開車，實在沒有必要因為心裡不平衡而急於求成，畢竟考一次的花銷還是很大，不如用平常心對待。

下午回公司後同事們都很貼心的沒有主動提起考試的事情，讓我很是感激，反倒是我主動說出我的經歷，希望即將考試的同事不要犯相同的錯誤。

即將到來的日本之旅，應該開始期待了。


有點不知道要怎樣提筆。多麼想說「這次終於考過啦。。。」可事與願違，第二次考車依然是「雙肥」。

學車記 2


![香港國際機場](/image/blog/sqtdn.jpg)

自從上次寫網誌，又是好幾個月過去了，這中間其實發生了不少事情，包括第一次去印度，開始新的工作，認識新的朋友，第 n 次去泰國，買了新的相機，去馬尼拉看歌劇等等。其實有很多事情值得記錄，希望今後能夠慢慢補充吧。

這次的這篇雜文，又是一則無聊的感情抒發。

自己不知道為什麼，對於機場，尤其是香港國際機場，總是有一種特別的感覺。機場這個地方，是一個邊界，一個通向未知和變數的起始。這裡交集著各種面孔，各種故事，各種聲音，各種情感，每個到這裡的人，都目的明確，步履匆匆。在機場我很喜歡的一件事，就是找個地方坐下，聽著靜靜的音樂，看著人來人往，這個時刻，好像掏空了自己，進入到一種類似被催眠的狀態，一種放空了自己的觀察者的狀態。每個不經意從身邊經過的人，他們從何來，去何處？他們的身後，都是有一長串一長串的故事。

對面凳子上坐著的兩個韓國女士，用著我完全聽不懂的語言高興的交談著，臉上帶著令人羨慕的笑容。她們是剛剛結束了香港的旅程準備回國嗎？她們在香港都經歷了什麼呢？一定有去尖沙咀，山頂，女人街，廟街吧？她們喜歡路邊攤的魚蛋嗎？她們喜歡維多利亞港的夜晚嗎？旁邊座位上濃妝艷抹的女士，正用電話和不知什麼人高談闊論，在抱怨天氣炎熱，自己有多麼的辛苦，言語中充滿了怨氣，似乎整個世界都在和她作對。她背後有什麼故事呢？她是否經歷了很多不公平的待遇，慢慢令她對生活產生了很多不滿呢？總覺的生活中遇見的任何一個人，短到擦肩而過，你甚至不曾意識到他的存在；長到白頭偕老，攜手走過人生的大半段旅程，總是源於一種無法解讀的機緣。

我喜歡出發，我喜歡在路上。喜歡機場，也因為機場是通往一段未知的起始。從這裡開始，便是一段完全不同的世界。不同的語言，不同的生活，不同的人，不同的事，你不知道將會遇到什麼，將會面對什麼。每次來到機場，總覺得內心既興奮又平靜。有人說喜歡在路上的人是因為現實生活沒有一種穩固，溫暖的歸屬感，因此需要藉助不斷的出發而找到一種逃離，一種平衡，一種宣洩。某種程度上我認同這個說法。當一個人有了令他覺得一樣需要花費大量精力去追求，去維繫，去經營的東西的時候，自然不再渴望變數，不再嚮往未知。這兩種狀態沒有好壞之分，對我來說，兩種狀態都是我渴望的。Anyway，扯遠了。

好了好了，無聊的文章就不要寫太長了，免的自己今後再看都覺得臉紅。下個禮拜終於要第一次前往日本，體驗一下這個很多人心中最完美的國家。


這次的這篇雜文，又是一則無聊的感情抒發,自己不知道為什麼，對於機場，尤其是香港國際機場，總是有一種特別的感覺。機場這個地方，是一個邊界，一個通向未知和變數的起始。

機場亂想


現在是坐在飛機上寫這篇文章，窗外引擎轟鳴，一片漆黑，聽著音樂，倒是回憶過往的好時候。今天，在 HKBN 的最後半天，圓滿的結束，發電郵和同事道別，合影，收拾自己的工作台，整理電腦中的資料，然後和同事們吃完最後一頓午餐，平靜的搭電梯，下樓。健康街上的一切都是那麼的平常，依舊車來車往。深呼一口氣，很難形容自己是怎樣一種心情。不捨，釋懷，期望，懷念... 夾雜著各種感覺。就這樣，離開了這個相處了五年半的地方。

這五年半的旅程，自然不能用短短幾段文字概括。雖說並不轟烈，也不驚艷，沒有大喜，也沒有大悲，但就是這看似平靜的旅程，潛移默化影響著我，改變著我。在這裡，有幸遇到很多友善的同事，得到很多幫助和指導，專業知識水平以及其他一些軟實力得到了很大的提升。

不少同事朋友問我為什麼要選擇離開。對於這個問題，我自己也沒有確切的答案。只是覺得，是時候了。HKBN 是一間很有活力的公司，這在大中型企業中都是比較少見的。公司鼓勵同事們創新，求變，工作生活平衡，也正是在這樣的背景影響下，慢慢意識到很多事情要主動，要積極，要求變，要改變。這幾年間，工作之餘去了不少國家遊歷，去的地方多了，看到的東西多了，對很多事情的看法真的會不同了。自己現在的生活方式，和很多同齡人會有一定的差別，因此我也不斷問自己，究竟想要怎樣的生活，究竟應該要怎樣的生活。有答案嗎？有。答案正確嗎？不知道。然而有一點是肯定的，要一種積極，勇於嘗試，敢於跳出常態的生活方式。所以，轉換到一個新的環境，算是跨出了一步。

飛機即將降落。暫且收筆。想說的話自然沒有說完，心情複雜，有一點失落，有一點懷念，有一點不捨。收拾一下心情，繼續前行。

--------------------

### 寫給 HKBN 的同事，朋友們 ###

親愛的朋友們

今日是我在 HKBN 工作的最後一天，2048 天的 HKBN 之旅，在今日暫時告一段落。

文字無法形容現時的心情，這裡留下太多的回憶，遇到了太多良師益友，在這裡有失落，更有開心；有壓力，更有成長。閉上眼，5 年間的一幕幕宛若電影片段般在腦海中放映，百感交集。人生能有幾多個 5 年，感謝 HKBN 帶給我種種的美好回憶。這段旅程，必將在我的人生日記上，留下濃重且不可磨滅的篇章。

太多的同事，朋友需要感謝。感謝 Stephen Kwok, Keith Lai, Leo Chan, Kent Kwong 這幾位我的上司以及 Stephen Lui, Eric Ho 這幾位出色的領袖一路以來的關心和照顧，他們的引領，指引和幫助，讓我在 HKBN 的旅程中能夠一路前行。也感謝我可愛的 Teammates - William, Matthew, Franco, Andy, David, YS, Danny, Wendy, Jennifer, Mavin, Whybee 以及 Ben 一路以來的幫助和配合，非常高興能夠和你們度過這愉快的 5 年。我們不僅是同事，更是朋友。

也藉此機會，感謝 IT Team 的其他同事，感謝 ITSA WL, KH, Chris, Brian, Jordy, Harry, Jimmy, Edward, Jason, Don, Alex, Wayne, Marco 以及 NOC 的 Ivan, Gary, Franky, Ryan 每次急需 System 方面的幫助你們都很快的伸出援手; 感謝 ITAD 大家庭 Jethro, Wilson, Hydro, Erik, Annie Kwan, Stephanie, Allen, Joe, Herman, GK, Jason Chu, Johnny, Realson 一如既往的支持和幫助，也同樣感謝 Cindy, Mice, Martin, Fabel, Winsy, Cheuk, Ming, Kenny, Andy Chu, Hei, Candy, Gary, Stanley, Monza, Ben, Benny, Franco Ho, Mabel 在很多 Project 上的幫助和配合。

當然，亦要感謝 5 年間所有共事過的同事過的同事。 在 HKBN 遇到的每一位同事，都給我留下了一段美好的回憶。感謝在這 5 年中能夠遇到你們。

HKBN 獨特的企業文化， 讓我有機會接觸不同的 IT 範疇，拓展專業技能的同時亦在很多其他不同的領域獲得進步。另外，在獲得職業成長的同時有機會去探索世界，享受生活， 相信我會將這樣的生活方式繼續下去。

暫時的分別是為以後的重遇鋪墊，誠摯地祝願大家新春快樂，安康幸福！


五年的香港寬頻之旅，就此暫告段落。僅以此文懷念這段難忘，精彩的旅程。

再會 我熱愛的香港寬頻


這週末過得算是頗為「充實」。週六一早去入境事務處代領身份證，然後晚上公司進行「IT系統災難演習」，通宵待命，不斷監測自己負責的系統的健康狀況，以致一整晚都沒怎麼休息。週日一大早，就去參見好朋友的婚禮簽字儀式，這次我的角色是「攝影師」。

這次的儀式其實頗為簡單，簽字，吃飯，已經可以高度概括。但作為「攝影師」我可不敢怠慢，想方設法每個角度都拍，儘管其實自己並不專業，但也算是盡我所能，幫助朋友紀錄這個重要時刻吧。本來照說和新娘是很好的朋友，但鑒於這次出席的都是他們的親戚，加上自己獨特的專業身份，並沒有和新娘子有太多的溝通，能看出來在簽字的一刻，他們兩個都有些緊張，但也能夠看出幸福的光環籠罩著他們。從今天開始，生活正式進入下一個階段，衷心祝願他們能攜手走到永遠。

拍照之後，正巧遇到尖沙咀正在舉辦亞裔文化表演，亞洲各個國家都有各種表演，既然路過，就停下腳步，坐下來，慢慢欣賞，著實給這個忙碌的週末，帶來了一點愜意。穿梭在各個國家的攤位，夾雜在各個國家的人當中，仿若有一種久違的出國旅行的感覺，讓心情非常放鬆。

天星碼頭附近，遇到了行為藝術表演者，雖說類似形式已經見慣不怪，但每次遇到，都情不自禁駐足觀賞。

![行為藝術家](/image/blog/x4kdk.jpeg)

![行為藝術家](/image/blog/4yvli.jpeg)

![行為藝術家](/image/blog/gdvx4.jpeg)

![行為藝術家](/image/blog/wgw36.jpeg)

最後，遇到了一個來自烏克蘭的旅行者，他帶著一隻企鵝玩具，周遊世界，如今來到香港，在這裡出售明信片換取一部分路費。

![烏克蘭的旅行者在為我簽名](/image/blog/wkkmp.jpeg)

閒聊中，得知他本身有工作，但是每當工作一段時間後就會休息一段時間，做自己想做的事情，比如旅行。看著他的旅行足跡，心中也是百感交集，佩服他能有這樣的勇氣去做這樣的事情，也覺得這樣的生活態度和生活方式，在某種層面來說，也挺瀟灑。

![烏克蘭的旅行者](/image/blog/fkugr.jpeg)

![烏克蘭的旅行者](/image/blog/zmafb.jpeg)


超級忙碌的一個週末，入境處，DR Drill, 婚禮攝影師... 終於臨近尾聲。

忙碌的週末


![iPhone X](/image/blog/jtvfa.jpg)

期待了很久很久的新款 iPhone，終於在發售的第二日無意中透過 iReserve 買到。本想用於「炒機」之用，但後始終覺得不捨，加上當時的「炒價」收益頗低，思前想後終於出售一部，自用一部。留給自己的，自然是 256 太空黑這個搶手款。

關於使用感受，本想寫一堆的讚美之詞，從拆開包裝到上手使用，但想想看還是算了，千言萬語用兩個字「完美」高度概括。外媒評論， iPhoneX 是當今地球上最好的手機，沒有之一。這一點充分同意。沒有了 Home 鍵，但新的 UI 操作方式不但絲毫沒有任何影響，而且覺得更加能夠達到「人機一體」的感受。 FaceID， 也只有用過之後才能發現他的最大價值，就是讓你幾乎覺察不到它的存在。

iPhone 的價格不便宜，之前對於是否值得花這麼貴的價格去買一部手機，和朋友有過爭論，對於這一點，只能說見仁見智。對於我來講，衡量一個東西的價值，首先要看它能給你創造多少價值，這個包括令你的生活更方便，心情更開心，工作更高效，或者能夠帶來更多的其他價值。對於一個幾乎可以說是生活中最最最經常使用，每天朝夕相伴，構成現代生活所必不可缺的一個超主力裝置，我覺得智能手機的價值，絕對可以超過汽車。

好了，話鋒一轉，使用了 iPhone 兩周多之後，已經完全適應了這部手機。當初帶來的驚喜，興奮，已經逐漸在這種「習慣」中慢慢消失。新手機帶來的改變，依舊存在，但已經變成一種常態，一種不能夠讓自己覺得「有什麼了不起」的常態。

想起之前在 Youtube 上看到的一個短片，一個移民加拿大的富二代，20出頭就住在加拿大一個價值千萬上億的湖畔私人巨型別墅，開著林寶堅尼，沒事就去家旁邊一個美得令人窒息的湖畔遛狗，散步。可是她被人問到「你覺得這樣的生活，開心嗎」，她的回答，也是意料之中，「我已經習慣了這樣的生活，沒什麼感覺」。

「我已經習慣了這樣的生活」

寫到這裡，歎了一口氣。有時候，我們不斷努力追求更好的生活，住更大的房子，開更好的車，賺更多的錢，認為到那個時候自己會覺得更開心，可是等真正實現了，往往很快就會覺得「習慣了這樣的生活，不過如此」。當然，站在不同的高度，會看到不同的風景。只有不斷追求改變，才會成為向上的動力。一旦出現「我已經習慣了這樣的生活」時，或許就是需要做出改變的時候。不久前和 Beckie 聊天，聊了蠻多東西，覺得在人生有限的時間內，真是要不斷做出改變。努力去做出新的嘗試，認識新的人，踏足新的領域，養成新的習慣。感覺人生的意義，就是去不斷經歷，不斷體驗，不斷嘗試。

最後，真心希望好朋友的媽媽能夠早日康復。


蘋果最新款的手機拿到了，感覺，感想。

新手機


前不久生病，肺部感染，前後折騰了差不多兩個星期。本以為是普通的感冒，結果高燒不退，在香港做了基本的排查後也不明原因，最後要嚴重到每天拖著發燒的身子跑深圳專科醫院（為了能快速診斷沒有在香港看），去偏僻的不得了的醫院，做各種各樣的檢查，抽血，CT，氣管鏡，痰檢，為的是查明原因，排除肺結核等相對麻煩和嚴重的問題。等結果時也夠折騰，心裡七上八下，最後各項檢查都正常，並非肺結核等麻煩問題，只是普通的肺部感染，抗生素吃了三天後發燒得到控制，複查 CT 之前肺部的陰影也基本完全消退了。

到了三十來歲的年紀，健康的問題必須開始重視，前不久看了 BBC 的一些紀錄片，認識到一些問題，感覺到有必要很大程度改善飲食習慣，極大地減少肉類的攝取。片中認為肉類，特別是加工肉類可謂人類健康問題的罪魁禍首，我們應該以植物類飲食為主。當然，關於這個論題，現在還是有不少爭論，到底孰是孰非，不得而知，但是減少肉類，並不是完全不吃，在一定程度上控制那些油膩，多脂肪，多油，煎炸，過度烹調，加工肉類，相信對健康必然是有正面的作用。就在寫此文的前幾天，最好的一個朋友的親妹妹，才 27 歲，頸部出現腫大，去醫院看醫生說有 90% 的可能是淋巴癌，需要立即住院切除，我和我朋友都極度震驚，這事情也給大家造成了非常多的擔心和困擾，絕非文字能夠形容。

在住處附近發現一件素食餐廳，以往總是經過，覺得裡面氣氛怪異，宗教氣息濃厚，最近去過，才覺得其實裡面的選擇眾多，味道也非常棒，絲毫不會覺得因為沒有肉類而枯燥，估計此餐廳將是我以後最常光顧的地方。不過素食餐廳的價格普遍偏高，一餐飯均價50元上下，若是加上餐飲，要60-70元一餐。

發現身邊越來越多的朋友轉行做保險，不知作何感想。當初的同專業同學，很多都轉做保險業，包括一些本以為和保險八竿子打不著人。香港的財經行業發達，加上內地居民赴港投保增加，近幾年香港的保險業增長的確令人咋舌。朋友圈中有一對夫婦，和我有著差不多的背景，如今在保險公司工作，看看他們的生活，至少是感覺上覺得非常精彩，發展自己事業的同時，能夠幫助別人，而且能夠參加各種不同的活動，十分令人羨慕。或者，咱們也可考個保險牌照？哈哈

明天又是新的一周，生活就這樣繼續著，前不久去入境處辦完新的身份證，應該也算是一個新的開始吧，希望自己能夠依照自己的節奏，一路向前。


無題


今天值得紀念。

人生中第一次參加駕駛考試，路面測試和技術測試，均失敗告終。對於這個結果，有其必然性，因為天時地利人和，三者均與我無緣。昨晚一整晚幾乎無眠，早上四點就起床，做準備六點鐘去考場附近上堂，一直上到考試前，考試時人的精神狀態非常不理想；就在昨天，八號風球襲港，由於是週日的原因滿地的樹枝雜物還來不及清理；早上，天文台發出黃色暴雨警報，坐在車內幾乎看不清窗外情況；三手掉頭，考官偏偏選擇一條從未練習過的常康街...

看到成績，兩部分全部不及格，出現四個嚴重錯誤，分別是五手胎掉頭（超出規定的三手），太接近其他物體，駕駛錯誤導致考牌主任採取行動，以及轉換行車線前未有查看交通情況。看到這個結果，並沒有太驚訝，因為當我三手掉頭撞向路邊護欄，以致要考官出手干預的時候，已經註定了這樣的結果。

想想看，自己應當是對機械操作頗有感覺的人，這次失誤，其實有各種各樣的原因。仔細查看評分表格，四個嚴重錯誤三個都是因為掉頭失誤引致，剩餘的一個嚴重錯誤則是因為受到心情影響而忽略導致。換句話說，這些嚴重失誤都是可以避免的。至於其他的小錯誤，的確需要更多的練習，才能夠熟能生巧。

雖說考試失敗頗為令人不悅，但能夠有這樣的一次經驗也的確難的。跌倒了，下次再戰。

![考試表格](/image/blog/nkby2.jpeg)


慢慢學車路，不知何時是盡頭，僅以此文，紀念今天這首次人生中的駕駛考試。

學車記


星期三請假參加駕駛考試筆試， 非常順利，全過程十分鐘完成。下午閒來無事，難得在本應工作的日子能有半天的忙裡偷閒，於是便去戲院看了一場電影 La La Land 。

![](/image/blog/5lehq.png)

對這部歌舞電影本來的期待是好聽的歌，好看的舞，對劇情沒有太多的期望，可是一場電影看下來，竟讓我連續數日無法抽離，直到今天，現在，寫這篇文章的時候，耳邊依然在不斷的重複聽著電影的音樂，特別是那首主題旋律，每每響起，總覺得心頭會異常的寧靜，會有一絲憂傷，會有一點無奈，會替男主角覺得遺憾，同時也會讓我對解答自己最近一直在思考的問題找到了一點線索。

雖說電影畢竟是電影，並不能用電影的思路以及呈現出來的劇情帶入到生活中，但這部電影的確用一種華麗的方式演繹了真實的生活，兩個生活上懷才不遇的才子佳人相愛了，他們各自都很努力的去實現自己的價值，追逐自己的夢想，Seb 為了迎合現實而改變自己的初衷做自己並不喜歡的事情；Mia 則為了自己的人電影夢想而無數次的嘗試，失敗，嘗試，失敗，直到最後被打垮；可是，可幸的的他們都遇到了對的人，Mia 提醒 Seb 要堅持自己的理想，Seb 也因此最後終於堅持自己的初衷開了一家爵士音樂俱樂部；Seb 在 Mia 已經放棄自己夢想的時候萬水千山找到她讓她抓住了最終徹底改變了她生活的機會；然而，現實往往不會像童話故事一樣美麗，兩個人也最終因為各自生活上的變化而天各一方，未能走到一起。

人生何嘗不正是這樣一種得到和失去的交織，而這個過程中的重點就是怎樣選擇。究竟什麼對自己是最重要的？事業，感情，家庭，自由，亦或是理想？


星期三請假參加駕駛考試筆試， 非常順利，全過程十分鐘完成。下午閒來無事，難得在本應工作的日子能有半天的忙裡偷閒，於是便去戲院看了一場電影 La La Land 。 對這部歌舞電影本來的期待是好聽的歌，好看的舞，對劇情沒有太多的期望，可是一場 ...

迷霧


尼泊爾之旅，在結束哈爾濱之行後匆匆開始。顯得有些倉促，有些應接不暇。

週五晚上下班後，匆匆趕回家，拎起行李，直奔直通車火車站，到廣州東已經十一點，在酒店住下，半睡半醒的到  早上五點，乘搭早班地鐵馬不停蹄的前往廣州白雲機場。之前之所以選擇廣州飛，是考慮到機票價格和時間，後來發現國泰直飛竟然比在廣州飛還便宜，所以看來下次還是不要折騰的好。

本以為只有三小時的飛行，結果因為沒有考慮時差的緣故，結果飛了五個多接近六小時。下飛機已經頗為疲憊。入境順利的出乎想像，似乎中國人有特別的優待，本以為落地簽要花費很久，因為看到很多外國人在排落地簽申請窗口，後來問了一句，當地官員得知是中國人後指引我到了一條特別通道，不出五分鐘，過了海關，沒有花一分錢。辦好電話卡，順利和預定的接機小哥會合，但小哥後來問我們索要小費，我給了20，朋友 Simon 莫名其妙的給了500 。

 一路開往酒店，對尼泊爾加德滿都有了最初的印象。不得不說這座城市留下的第一印象是落後和混亂，一路驅車，滿目盡是錯綜複雜的破落商舖，猶如蜘蛛網一般懸在空中的電線，到處都是汽車喇叭聲，人們的呼喊聲，車和人就在馬路上鬥法一般的互相穿插。

![](/image/blog/kwbvk.jpeg)

![](/image/blog/6avm1.jpeg)

![](/image/blog/weu0s.jpeg)

入住的酒店還是很不錯的，甚至覺得和周遭的環境有點格格不入。從酒店望出去，放眼都是如廣州城中村一般的密集錯落的民房，這個國家生活的疾苦，可見一斑。

![](/image/blog/o2xlz.jpeg)

住下之後出來在街上走走，各式各樣的小商舖琳瑯滿目，耳邊飄過各種不明白的語言和偶爾幾句「你好」，充滿特色的薰香味瀰漫在整個街道，身體每個細胞都告訴你，你已經真實的來到了這座靠信仰支撐著的淨土。

![](/image/blog/ep61i.jpeg)

![](/image/blog/j0yin.jpeg)

![](/image/blog/flzbt.jpeg)

The dream garden 夢中花園。這座由當時控制尼泊爾的陸軍元帥修建於上世紀20年代的歐式花園，在加德滿都的喧囂中提供了一處安靜的角落。

![](/image/blog/vw9rs.jpeg)

![](/image/blog/nct1y.jpeg)

晚上，是2016年的最後一天。尼泊爾的人們盡情狂歡，音樂聲，歡呼聲響徹雲霄。感謝我們的領隊睿寶，為我們準備了意想不到的天燈，在這特別的時刻，願這天燈載著對新年的願景，衝破重重障礙，飛向更廣闊的天空。

![](/image/blog/z56ai.jpeg)

第二天，開始了加德滿都的文化探秘。晨間，穿插行走於加德滿都的街頭巷尾，更能體會什麼是混亂與祥和並存，古樸與自由同在。看似混亂的背後，更是能感受到人們的純樸與簡單，這裡沒有燈紅酒綠紙醉金迷，人們就是以一種原始的，自然的方式生活著，快樂著。

![](/image/blog/0jdfv.jpeg)

![](/image/blog/csfpj.jpeg)

![](/image/blog/jaoe2.jpeg)

![](/image/blog/bwhxh.jpeg)

穿行中，來到了 Shree Gha 寺廟。她就是這樣突然而又自然的出現在「城中村」之中。

![](/image/blog/iljjg.jpeg)

![](/image/blog/xqzdu.jpeg)

大片的鴿群停留在這裡，人們可以購買穀物投喂鴿子，一把撒出鴿子黑壓壓的一片鋪天蓋地的飛過來，那景象也頗為讚嘆。

![](/image/blog/1zfkf.jpeg)

![](/image/blog/vrkgm.jpeg)

寺廟周圍的各種雕塑，都靜靜的呈現著加德滿都的厚重歷史。

![](/image/blog/y2hz7.jpeg)

繼續走，來到了風格完全不同的 Seto Machhendranath 寺廟，這座廟周圍都被鐵籠包圍，顯得神秘。

![](/image/blog/udjfy.jpeg)

再往前，就到了久負盛名的加德滿都杜巴廣場。這裡充滿著各式各樣的16到19世紀建築，又稱為皇宮廣場。在兩年前的地震中這裡很多建築都遭到了不同程度的損毀甚至完全的摧毀。

加德滿都杜巴廣場，是尼泊爾三個杜巴廣場中最小也最精緻的一個，這裡也是尼泊爾皇室的正統皇宮。這裡集中了加德滿都古建築的精髓，囊括了16-19世紀建造的50多座宮殿和寺廟，在1979年就被列入世界文化遺產。

![](/image/blog/rifm4.jpeg)

![](/image/blog/85kvs.jpeg)

![](/image/blog/repeb.jpeg)

![](/image/blog/pypmv.jpeg)

![](/image/blog/89gcp.jpeg)

廣場入口處有一座同女神廟，裡面供奉著童女，這裡的人們不光信奉各種神靈菩薩，同時還供奉著活女神，她是一位被嚴格挑選出來的小女孩，經過重重篩選和考驗，具備三十二種美德、腳不能落地、不能流血，一直到月經前只能生活在神廟中。

![](/image/blog/cemfi.jpeg)

童女每天會有很短的時間露面，在閣樓二層的窗戶中俯視前來拜訪的眾人，這次我們也有幸得見，但由於嚴格禁止拍照，所以也未能用相機記錄下來。

下一站去往博達哈大佛塔，Boudhanath Temple，據說這是是世界上最大的圓佛塔。距今已有1200多年歷史，這裡人聲鼎沸，眾多信眾從四面八方前來參拜。在這裡，被香火味包圍著，強烈的藏傳佛教氣息撲面而來。

![](/image/blog/ogmjm.jpeg)

![](/image/blog/srbdq.jpeg)

![](/image/blog/wqw65.jpeg)

![](/image/blog/gc33m.jpeg)

![](/image/blog/ekdwv.jpeg)

![](/image/blog/dveb8.jpeg)

![](/image/blog/fvii9.jpeg)

![](/image/blog/nrte8.jpeg)

![](/image/blog/mhul2.jpeg)

![](/image/blog/wcsiu.jpeg)

最後一站，驅車前往巴克塔普爾，這裡有著另外一個杜巴廣場，之前的地震同樣給這裡帶來了毀滅性的打擊，很多著名的寺廟都毀於一旦。隨處可見人們在馬不停蹄地做著修復工作，衷心希望在各方的努力下，這裡的一切可以恢復舊有的美麗。

![](/image/blog/fjsdp.jpeg)

![](/image/blog/36v3e.jpeg)

![](/image/blog/q4odv.jpeg)

![](/image/blog/hgbwn.jpeg)

![](/image/blog/hrisi.jpeg)

![](/image/blog/swqyq.jpeg)


尼泊爾之旅，在結束哈爾濱之行後匆匆開始。顯得有些倉促，有些應接不暇。 週五晚上下班後，匆匆趕回家，拎起行李，直奔直通車火車站，到廣州東已經十一點，在酒店住下，半睡半醒的到 早上五點，乘搭早班地鐵馬不停蹄的前往廣州白雲機場。之前之所以選擇廣州 ...

撒歡尼泊爾 (1)


和同事們慶祝完部門的聖誕party，開完會，離開公司，坐上新開通的A32號機場巴士。聖誕，就這樣拉開序幕。

每次坐在前往機場的巴士上，目睹這漸漸褪去的橙黃，心裏都有種說不出的感覺。一種夾雜著興奮，期待，寧靜與擔憂的混合體，從頭到腳，包裹著我。

![](/image/blog/cqywj.jpeg)

機場，一個每次來都覺得興奮的地方。一個通往未知和無限的中轉站。望著來來往往的人，各種膚色，各種語言，各种神情。每個人背後都有說不完的故事，每個人都有將要去往的地方。就這麼靜靜的看著，望著，心思慢慢靜下來，想一想，我又要去往哪裡呢？

![](/image/blog/lxga4.jpeg)

![](/image/blog/welxs.jpeg)

在候機的時候，一堆小朋友在旁邊放肆地追逐，大喊大叫，吵得心煩。突然發現他們玩的遊戲我小時候也玩過，現在看起來那麼幼稚無聊的東西之前竟是那麼喜愛，小時候無憂無慮的天真生活竟是一去不復返了。但要說讓我回到過去，那我也是斷然不會答應的，人終究要向前走，對過去的懷念，也就只是停留在懷念吧。

![](/image/blog/epa9d.jpeg)

第一次乘坐春秋航空。對於這個航空公司也可以說是有特別的情節。工作後第一份工作時當時的老闆經常乘坐春秋航空，而且這個航空的價格非常便宜。所以一直以來都想坐這個飛機去旅行。後來終於有機會訂了一次，然而，那一次也成為了人生中唯一一次錯過登機。

![](/image/blog/ks8q0.jpeg)

飛機延誤兩個小時後終於登上了飛機。然而春秋航空果然不辜負國內航班延誤排行榜第一的美譽，登機後艙門久久不能關閉，機上廣播說什麼因為航路改變而要加油所以不能起飛。機上的乘客逐漸開始焦躁，都在質問乘務員何時起飛。在這個時候反而我很平靜，焦躁不能解決任何問題。何不安安靜靜，靜觀其變。

22:35 延誤了三個多小時後，機長宣佈因為經停的徐州機場大霧，無法降落，所以機長決定可能直飛石家莊。但是機上有很多乘客本是前往徐州，所以他們是否跟機前往石家莊，以及如果不跟機前往的話他們的行李怎麼處理，也是問題。機上一片混亂，人們各自有各自的立場，各自有各自的考量。爭執不下。

23:00 機上一片混亂，對罵，推搡空乘，之前新聞中見到的情境竟然親身經歷了。

23:14 機長決定起飛。

2:12 降落在石家莊。

走出機場的一瞬間，才真真感覺到冷。零下三度的氣溫，已經給我們來了個下馬威。從國際航站樓走到國內航站樓，百來米的路程已經凍的耳朵痛。

![](/image/blog/brbqg.jpeg)

國內航站樓內一片寂靜，人也不多，零星幾個人在一旁休息，完全沒有了香港機場那徹夜燈火通明的繁忙，一切都靜下來了。

![](/image/blog/ojtnt.jpeg)

找了幾張紙皮箱，鋪在地上就躺下了。這些文字就是在這裡寫的。

![](/image/blog/y36bl.jpeg)

早上，踏上去往哈爾濱的航班。經過兩個小時的飛行，抵達哈爾濱機場。踏出艙門，刺骨的寒冷撲面而來，猝不及防。很快找到了前往酒店的機場大巴，順利抵達酒店附近，下車的地點距離酒店僅僅幾百米，但那段路似乎是整個旅行中走的最長的一段路，同行的朋友因為路面結冰的緣故摔了個踉蹌。

在酒店稍作休息，就開始哈爾濱之旅了。  下午四點多，天色竟然黑的像晚上一樣。用手機叫了滴滴，直接前往中央大街附近，這也是我們此次哈爾濱之行不斷重複的僅有的地點。

松花江完完全全變成了冰，上面各種冰上活動，狗拉雪橇，滑冰，沖冰等等，琳瑯滿目。可惜同行朋友對此絲毫無興趣，所以我也只能控制住內心的童真，傻傻的看看作罷。

![](/image/blog/eeqre.jpeg)

中央大街是哈爾濱的必去地方了，這條大街始建於1898年，由石板鋪成，建有歐式建築71座，匯集了文藝復興、巴洛克、折衷主義及現代多種風格，極具歐陸風情。大街上有個馬迭爾賓館，是由俄羅斯籍猶太人約瑟·凱斯普出資興建，建成於1913年，是法國文藝復興時期路易十四式建築，建築風格受新藝術運動思潮影響。目前建築依然被馬迭爾賓館所用，是哈爾濱市I類保護建築。

中央大街上有各式各樣的小吃攤檔，其中最吸引我的莫過於馬迭爾雪糕，據說是中央大街的特色食品之一，距今100多年歷史，僅僅有兩重口味，而且沒有外包裝，且僅限專營店出售。至於口味，客觀的說可謂中規中矩，並不驚艷，但甜而不膩，冰中帶香，即使是在今天這五彩斑斕的時代，它的口味也是算得上不錯的，更不要說幾十年前了。

![](/image/blog/vl8bw.jpeg)

另外就是冰糖葫蘆，這個很受我們的喜歡，在零下20度的天氣下，真正成了“冰”糖葫蘆，吃起來非常過癮。前後我們共計吃了有10根。

![](/image/blog/hfrgj.jpeg)

至於哈爾濱紅腸，也是一大特色， 滿大街到處都是。這個我倒覺得一般，沒什麼技術含量，感覺就是普通香腸烤烤而已，油膩的很。

中央大街上亦能看到各種冰雕裝飾，以及大塊的冰塊，這景象對於我這個常年不見冰雪的人來說頗為驚奇。

![](/image/blog/avhjl.jpeg)

聖索菲亞大教堂，可謂哈爾濱的代表之一了。聖索菲亞教堂於1907年3月17日奠基修建，最初是俄羅斯帝國東西伯利亞第四步兵師修建的隨軍教堂；後來經過多次重建，以及各種運動的洗禮，破壞，改造，教堂終得以保留。哈爾濱市政府甚至拆除了周邊具有火災隱患的相鄰建築1.4萬平方米，闢建廣場7000平方米，並將教堂改作哈爾濱市建築藝術館之用。

![](/image/blog/sbv8j.jpeg)

第二日，我們奔向太陽島，一上島就要購買240元的景區門票，至今我也不知道那個具體是什麼景區，是冰雪大世界還是什麼鬼。進去後看到的各種雪雕冰雕還是挺不錯的。對於沒見過雪雕冰雕的人來說也算是大開眼界。放眼望去一片白色，各種形態各異的巨大雪雕展示著匠人門巧奪天工的手藝。

![](/image/blog/zku0z.jpeg)

![](/image/blog/oq0ae.jpeg)

![](/image/blog/i1mck.jpeg)

![](/image/blog/gzh3h.jpeg)

從太陽島出來，看到了過江纜車，盛惠100大元，橫過結冰的松花江，不知道是不是值得。不知道是不是哈爾濱的人賺錢很多，感覺這些旅遊景點啊，設施啊，貴的很。

![](/image/blog/7ahcg.jpeg)

之後去了一家大眾點評上排名第一的自助餐，吃了一頓盛大的聖誕大餐，也將策劃準備已久的禮物送了出去，大家都很開心。

哈爾濱的行程，基本就圍繞中央大街，聖索菲亞教堂，松花江不斷循環。雖說沒有去其他地方，但第一次感受如此的寒冷，也是非常值得懷念的。回到家後看到哈爾濱之行留下的衣物，心中難免有一種留戀之感，短短的幾天，很快就過去了，生活還是要不斷前行。

最後一天，轉機經過北京。北京這個城市，之前去過兩次，第一次是和好友阿昌去，充滿新鮮感，也是最快樂的一次。第二次去，是去探望當時在北京工作的 Josh ，整個旅程充滿了等待，無聊，和只有自己才明白的無奈。第三次也就是這次去，走馬觀花，重複拜訪了天安門，前門，南鑼鼓巷，奧體中心，另外去了之前期待已久的 798 藝術區，以及網上搜尋到的最具人氣第一名的西單大悅城商場。可以毫不誇張地說，所有地方，是所有地方，都是讓人極度失望。之前來北京一直沒有進入水立方去看，這次狠心買票進去，額滴神，裡面變成了一個遊樂場，和破破爛爛在裝修的類似演唱會的地方，我也是徹底無語了，朋友更是無奈。至於 798 ，只能呵呵了，可能是冬天的緣故，全部都關門謝客。逛了不到15分鐘，實在無法忍受，坐車回家。南鑼鼓巷，兩邊入口都半封閉，裡面的店舖也只是星星點點在營業，吃個餐，價格貴到你不信。西單大悅城，這真是我大北京最好的商場嗎？在裡面走了一圈不知道要吃什麼，無奈只得去漢堡王，那價格比香港還要貴很多。

哦對了，本來計劃好北京一天是要帶朋友參觀故宮，結果去了之後發現人家週一閉館。

![](/image/blog/wi0ui.jpeg)

四天的時間很快就過，哈爾濱留下的印象還是很不錯的，東北人的確粗獷好爽，哥兒們哥兒們的叫著開始還真有點不習慣。回到香港後好在有半天的時間給我緩衝，否則太快從夢中醒來估計會崩潰掉。

最近一直在想前路究竟要怎樣繼續，不想平平淡淡就此度過一生浪費青春，但一時間也沒有清晰的方向。2016轉瞬即逝，2017近在眼前。2017對我來說會有一些轉變，希望自己能好好把握。


和同事們慶祝完部門的聖誕party，開完會，離開公司，坐上新開通的A32號機場巴士。聖誕，就這樣拉開序幕。 每次坐在前往機場的巴士上，目睹這漸漸褪去的橙黃，心裏都有種說不出的感覺。一種夾雜著興奮，期待，寧靜與擔憂的混合體，從頭到腳，包裹著我 ...

哈爾濱冰雪之旅


現在是當地時間  凌晨兩點半，  香港時間早上六點半，一整晚沒睡，倒也就這樣過來了，也沒有說覺得特別辛苦，寫下這些文字的時候，正坐在登機口附近的咖啡店等侯和隊友會面和轉機前往安曼。

![](/image/blog/l8nkr.jpeg)

對於杜拜的第一印象，從飛機即將降落的那一刻開始產生。望出窗外，已然是接近零點的杜拜竟然是一片燈火通明，看的我目瞪口呆以致忘記了拍照。然後飛機降落杜拜機場，感覺就一個字，大。從飛機觸地，到行駛到落客位，足足用了有二十分鐘，然後乘坐巴士前往航站樓，又開了有十多分鐘。進到航站樓後，走到我轉機的登機口又走了我半個小時。

![](/image/blog/kxvof.jpeg)

凌晨的機場，依舊人潮湧動，密密麻麻，想去個廁所排隊要排五分鐘。

大歸大，可是這個機場給我留下的印象並不怎麼好。相比 香港國際機場的井井有條，這裡顯得有那麼一些混亂，從降落到我找到轉機登機口花了將近一個小時，兜兜轉轉上上下下好不辛苦。另外最令人不可接受的是免費 wifi 竟然只能使用一個小時，過了就必須花錢購買，盛惠港幣38元每小時，這麼基礎的服務竟然要這麼高的價格，對這個機場的印象一落千丈。

![](/image/blog/gtqgz.jpeg)

早上六點，成功和隊友色色會合，踏上飛往約旦的航機。

![](/image/blog/yburv.jpeg)

波音 777 相比 380 的確小了不少，頗為擁擠，從杜拜機場起飛後，看到沙漠中的杜拜，高樓林立，所說未能真正踏足這裡，但也確實感受到了這個地方的奢華。

![](/image/blog/4cdq9.jpeg)

兩個多小時的航程，很快就到達了約旦這個神秘而又期待已久的國度。從舷窗望出去，看到的竟然都是沙漠，零星的在沙漠中會有一點建築物，顯得那麼孤立無援，心想不會真的降落在這裡吧？這哪裡像是一個可以落地的地方，荒涼的可以說鳥不拉屎。可真的在五分鐘後航機就真的降落在這片沙漠中了。

![](/image/blog/zczqx.jpeg)

落地後見到約旦安曼的機場其實也不錯，該有的都有了，入境，換錢，電話卡什麼的都很順利的辦理成功，然後用神奇的 Uber 約了車前往酒店。司機是一個很帥的小哥，不懂英文，未能做太多溝通。

一路上看到其實這裡遠比自己想像的要好，並不是那種黃沙一片的感覺。安曼的感覺類似於國內的三線城市，雖說不那麼發達，但一切也是井井有條。

![](/image/blog/vtoms.jpeg)

在酒店住下後，因為大部分團友還未抵達，稍作休息就和先到的朋友一起出去探索一下這個城市。印象最深的應當就是下面圖中的這個景象，依山而建的居民樓密密麻麻，此情此景曾在電視上見過多次，但當親眼所見，還是不由得發出哇的驚訝。

![](/image/blog/mgxdz.jpeg)

因為是宰牲節的前夕（相當於基督教的聖誕節），各個地方的人都湧入安曼城採購年貨，因此交通比較擁堵，據聞這也是一年只有一次的擁堵。

![](/image/blog/trspi.jpeg)

傍晚時分也去逛了一下酒店附近僅有的一個大型商場，進入後感覺一下回到了一個熟悉的環境，因為各種熟悉的品牌在這裡都能見到。

![](/image/blog/qsuqt.jpeg)

今日的最後，在天橋上拍下一張照片，回看時發現竟然剛好是抓拍到了日落的景象。

![](/image/blog/dhfyv.jpeg)

明天的行程將會參觀傑拉什古城和清真寺，定會是艱苦但充滿期待的一天。

且聽下回分解。


現在是當地時間 凌晨兩點半， 香港時間早上六點半，一整晚沒睡，倒也就這樣過來了，也沒有說覺得特別辛苦，寫下這些文字的時候，正坐在登機口附近的咖啡店等侯和隊友會面和轉機前往安曼。 對於杜拜的第一印象，從飛機即將降落的那一刻開始產生。望出窗外， ...

約旦盛宴 Day 2 約旦初印象


寫下這篇文章，是在前往迪拜的航機上。阿聯酋航空公司 A380 寬體客機 50K 號座位。

![](/image/blog/fe3up.jpeg)

這次旅行，早在半年前就已經決定。記得當時因為各種原因，覺得很需要好好放鬆一下，規劃並實施一個遙遠的年度之旅。因為之前一直收聽一檔旅行播客，其中介紹了一個專為年輕人服務的深度遊旅行公司，因此就上他們網站看看，見到關於約旦深度遊的介紹和圖片，沒想到就這樣被成功的吸引過去了。

約旦，這個自己本層根本沒有任何認識和概念甚至聽到名字就有點不由自主的擔心的國度，就這樣有點意外的進入了日程表，開始了讓我長達半年的期待。然而真正當這一天到來的時候，卻並沒有原本預計的興奮難耐，或許是因為同  一時間一位好友要離開香港，或許是過去半年兩次預計之外的出行降低了我的期望值，或許是對這次這個遙遠國度的各種不確定性的擔心，或許是擔心和團友們沒有共同語言而不能盡興... 

飛機的發動機在耳旁轟鳴。癱坐在寬敞的椅子上，望著窗外一片漆黑，還真不知道這次旅程會發生什麼。阿聯酋的航機非常舒適，機上食物也是乘搭過這麼多航空公司中數一數二的。食物可口，貼心的準備了餐巾，濕巾，前菜，正餐，甜點，小吃，餅乾，朱古力，香口糖等等，能做到這麼細緻，真的令人倍感貼心。

![](/image/blog/9vsvw.jpeg)

還有六個小時的航程，就將抵達迪拜機場。決定利用這段時間先逛逛這個久聞大名的機場。然後就看看在哪裡能找個地方睡睡啦。

欲知後事如何，且聽下回分解。


寫下這篇文章，是在前往迪拜的航機上。阿聯酋航空公司 A380 寬體客機 50K 號座位。 這次旅行，早在半年前就已經決定。記得當時因為各種原因，覺得很需要好好放鬆一下，規劃並實施一個遙遠的年度之旅。因為之前一直收聽一檔旅行播客，其中介紹了一 ...

約旦盛宴 Day 1 A380 飛往迪拜


下半年，至少會有兩次旅行。特別是第二次旅行，十分令人期待。但我又不敢抱太大的期望，畢竟旅行的方式與以往不同，結果要麼非常好要麼非常壞。

一直以來對攝影非常感興趣。但僅僅是停留在入門級別，我並不想讓自己沉迷在攝影本身，我希望更多的關注點在拍攝的對象和過程，以及影像後面帶出的故事以及回憶。之前用650D的時候，其實並沒有過多的關注器材，一個入門機身，一個萬用鏡頭，沒有壓力，沒有選擇困難，不用考慮，而且效果也很不錯。後來，受了Youtube上牛人們的荼毒，覺得不能沒有一個廣角鏡，因為廣角鏡頭照出來的效果很宏大，衝擊力強。當有了廣角鏡後，的確被他的效果震撼到，因此土耳其旅行全程都在使用廣角鏡頭。可後來發現有一個問題，廣角鏡是好，但是光圈小，景深不足，而且變焦能力差，無法拍攝遠景，於是乎，開始糾結，旅行的時候究竟要帶廣角鏡呢，還是萬用鏡呢？又過了一段時間，發現 Youtube上牛人們推薦50mm定焦鏡頭，大光圈，成像效果出色，價錢不貴，然後果斷買入，但拍了兩張就發現定焦實在是不適合自己，焦距太過固定，不能靈活捕捉周圍的景象。於是，又 受了Youtube上牛人們的荼毒，購入大光圈變焦Sigma 17-50 F2.8, 雖說整體感覺不錯，但有沒有了廣角鏡的宏偉效果以及萬用鏡頭的長焦效果。於是，旅行前又開始糾結，是帶萬用鏡呢，還是廣角鏡呢，還是Sigma呢，還是都帶呢，還是只帶兩個呢，帶哪兩個呢？為此，痛苦不堪。

最近，迷上了短片拍攝，因為發現短片的表現力，衝擊力，後期處理的樂趣以及對記憶的喚醒能力都強於照片數倍。特別是在剪輯的過程中，所能體驗到的那種回憶與創作的交融感，讓人著迷。上次緬甸旅行，算是第一次真正意義上拍攝短片，整個行程拍攝了大大小小幾百個片段，本以為已經足夠，但是回來剪輯的時候才發現原來遠遠不夠。但剪出來的一段視頻雖說很初級，但是自己感覺還OK，每每看到，都會喚起那段回憶。可是，話又說回來，若是想要好的拍攝效果，基本的裝備又多了幾件。首先相機是不能少吧；另外由於視頻的特殊性，三腳架不能少吧；為了更方便的捕捉畫面以及一些特殊的場合拍攝，GoPro不能少吧；帶了GoPro，那麼一系列的GoPro附件比如防水外殼，浮力棒，電池，充電器，遙控器，固定支架等等，不能少吧；由於GoPro沒有防抖功能，我又專門為他配置了一個G4S三軸穩定器，這個和GoPro價格接近的黑科技裝備也不能少吧；所以....也沒有所以了，我也不知道說什麼好了。

有人會很文藝的說，旅行就用眼睛，用心去感受，何必用相機記錄？不能說他說的不對，只是不同的人對旅行期望的不同罷了。我對旅行的期望，除了最重要的感受，體驗之餘，更希望去記錄，去定格那個畫面，以便日後能夠憶起，能夠有“滿滿的都是回憶”的感覺。


下半年，至少會有兩次旅行。特別是第二次旅行，十分令人期待。但我又不敢抱太大的期望，畢竟旅行的方式與以往不同，結果要麼非常好要麼非常壞。 一直以來對攝影非常感興趣。但僅僅是停留在入門級別，我並不想讓自己沉迷在攝影本身，我希望更多的關注點在拍攝 ...

旅行&攝影


Instagram突然換了新Logo，這本不值得特別去寫一篇Blog去說，但人們的反應有點出乎意料。

其實就Logo本身而言，我覺得還是很好看的。我完全不懷疑這個擁有全世界最大圖片庫的公司的設計能力，新Logo簡約大方，很符合現在的設計趨勢。

但網絡上的人不這麼認為。

![](/image/blog/voumf.png)

真的是新Logo太難看嗎？我看未必。長久以來，Instagram Logo 的形象早已深入人心，那個擬物化的Logo出現在人們生活的方方面面，可謂根深蒂固，甚至很多相機廠商都專門設計了類似的實體相機。所以，這麼一改，而且是在毫無準備的情況下突然一改，自然會引起反感。有時候設計這東西，就是這麼無法捉麼。設計本就是一個見仁見智的東西，每個人因為閱歷不同，對美醜的定義自然也就不同，記得之前設計某個網站，自我感覺良好，簡約，大方，但是偏偏是頂頭上司覺得不好，說是缺少文字，要加入更多的文字。於是整個網站就徹底淪落了，當然，這也自然只是我個人的見解。

再回到Instagram，現在網絡上罵聲一片，設計師們的壓力應該很大吧。但也有可能是我多慮了，這麼有氣質的公司，或者會說“我就是改了，怎麼樣吧，愛罵罵去，不喜歡別用啊”


Instagram突然換了新Logo，這本不值得特別去寫一篇Blog去說，但人們的反應有點出乎意料。 其實就Logo本身而言，我覺得還是很好看的。我完全不懷疑這個擁有全世界最大圖片庫的公司的設計能力，新Logo簡約大方，很符合現在的設計趨勢 ...

Instagram 新LOGO


寫在生日過後的第一天。香港到廣州的巴士上。

若不是朋友們的問候，我真的會忘記自己的生日。小時候，每快到生日，總是期待著，盼望著，自己又長大了一歲，另外在生日當天，或許會收到禮物，或者去遊樂園玩耍，然而踏過25歲之後，不知為什麼，總是想讓自己的生日就這樣平靜的度過。最好是能夠忘記，這個有點莫名其妙，但又有點與眾不同的日子。或許是因為一眨眼越過了而立之年，一切都是那樣的不知不覺，讓人有點恐懼，有點不知所措，有點不情願。生命中還有太多的缺憾，太多的沒有經歷過的東西，然而時間就這樣悄悄的流逝。

這個生日，過得算是冷清，但也充實。冷清是因為刻意低調，沒告訴任何人，沒有任何活動，沒有太多的問候，甚至是最重要的人的問候。但其實這也是我最希望的，甚至在心裡默念，不要記起，不要記起。晚餐，依然是少不了長壽麵，這個傳統的習慣，還是要遵守的，一邊吃，一邊默念，身體健康，生日快樂。一隻麻雀飛過身旁，停住，似乎在周圍尋找食物，悄悄的丟下一根麵，應該夠它飽餐一頓了。

說過的充實，是因為這天參加公司的新聞發佈會，見到了一些明星，然後一口氣讀完了《追風箏的人》，以及又馬不停蹄的看完了根據小說改編的同名電影。

這是一個關於地位，友情，愧疚，救贖，親情的故事。這貫穿全篇的風箏，是希望，是榮耀，更是主人公阿米爾渴望已久的解脫。兩個社會地位截然不同的孩子，成為了最好的朋友，但主人與僕人，普什圖和哈扎拉的分別，註定會慢慢給他們帶上面具，這或許就是哈桑一次次為阿米爾挺身而出，而阿米爾一次次懦弱逃避，甚至最後徹底被內心的怯懦吞噬的根本原因。

哈桑的結局有點令我意外，在讀到那一段時甚至有點不相信，不相信竟會是這樣一種方式。

多年後，阿米爾和索拉博在草地上放風箏，那句結尾的，也是哈桑曾經多次說給阿米爾的 “為你，千千萬萬遍”，徹徹底底的觸動到內心最柔軟的那塊地方。一個輪迴，一種解脫。

“為你，千千萬萬遍”。

回家後立即找出同名電影，看書後再看電影的感覺的確有點不一樣。電影用更有視覺衝擊力的方式演繹了整個故事，配合原著，更深的體感受了這個故事。

生活在現代社會，特別是一個大都市，書中描寫的場景，對我來說是那麼的遙遠。很難想象在阿富汗那個戰火紛飛的國家的同齡人們的生活，那甚至是連做夢都不會想到的一種場景。文中描寫的關於塔利班的統治，是那麼不可理喻的真實存在。閉上眼，真應該感謝命運，將我安排在這樣一個舒適自由的國度。

好了，轉眼快到家了。感覺這篇文字的基調有點沉，呵呵。明天約了朋友去溪頭村一探究竟，希望能拍些好看的照片回來。


若不是朋友們的問候，我真的會忘記自己的生日。小時候，每快到生日，總是期待著，盼望著，自己又長大了一歲，另外在生日當天，或許會收到禮物，或者去遊樂園玩耍，然而踏過25歲之後，不知為什麼，總是想讓自己的生日就這樣平靜的度過。最好是能夠忘記，這個有點莫名其妙，但又有點與眾不同的日子。

2016年的生日 追風箏的人


緬甸之旅，在不抱期望中開始，在充滿意外的驚喜以及無限懷念中結束。一如既往的，回來後好久不能適應香港的生活，好想就這樣旅行下去，感受這個世界，探索這無窮無盡的未知。

緬甸之旅，從開始計劃，就不是那麼的讓我嚮往。本來計劃去印度，但全因時間以及找不到同行的朋友而不能如願。後來在時間緊逼的情況下，考慮簽證，機票等問題，排除法選擇了緬甸。當得知緬甸蒲甘也是因佛塔著稱，心裡卻有一絲的哀歎，因為想起當時在柬埔寨烈日下奔波佛塔中的汗流浹背，想起那種仿若趕場一樣走馬觀花參觀一座座佛塔的感受。

然而，正是這沒有太大期望的旅程，竟成了我所有旅程中最值得回味的旅程之一。

這篇網誌，不會是一個旅行攻略，更多的是，是記錄自己的所見，所感，所想。而這次出行，留下最深印象的，有如下五個畫面。

1. 騎摩托穿梭在蒲甘的百萬佛塔中，爬上佛塔看日落。

蒲甘乃是一個有著成千上萬座萬佛塔的地方。這些佛塔散落在蒲甘平原上，每一座都有著超過2000年的歷史。而遊覽這些佛塔最好的方式，可以肯定地說，一定是租一架電動車，拿著Google Map，沒有目的的，隨著心情的，去探索，去感受。騎著摩托，穿梭在蒲甘平原，一座座佛塔就在你身邊擦身而過，言語無法形容個中的感受。日落時分，隨性找一座佛塔，爬上去，靜靜的等候太陽在不遠的天邊落下，沐浴在清風和夕陽的溫暖中，我只能說，那一刻，你會覺得你擁有了全世界。

![](/image/blog/epspw.jpeg)

2. 熱氣球，以及在熱氣球上求婚成功的 Jimmy ＆ Jamie. 

熱氣球是一個能讓人有無限感慨的地方。從充氣到騰空，每一刻，都是讓人驚歎的。在空中看這個世界，你會一下子有了不同的視角，會放下一切塵雜，靜靜的用心去感受，一切瑣事，都顯得已不再重要。而這次，更能有幸見證一次浪漫的求婚，當 Jamie 說 Yes 的那一刻，發自內心的覺得這個世界是有多麼的美好。

![](/image/blog/zejqz.jpeg)

![](/image/blog/eievm.jpeg)

3. 仰光的3小時環城火車。

火車之旅，本不在日程安排上。之所以會有這次火車之行，全因原本的行程因買不到車票的緣故而提前返回陽關所致。3小時的火車，環繞仰光一圈，看著上上下下的人，聽著完全聽不懂的談論，從繁華的鬧市，到僻靜的郊外，從人聲鼎沸的集市，到萬籟俱寂的田園，城市百態，就在這短短的三個小時，盡收眼底。

![](/image/blog/xsgia.jpeg)

4. 伊洛瓦底江的日落

這個行程，也是臨時決定，但卻和上次柬埔寨的遊船日落一樣讓我懷念。在等候登船的時候，坐在躺椅上，望向遼闊的江面，頭上樹木投下斑駁的陰影，不時有幾隻松鼠頑皮的在眼前溜過，聽著音樂，閉上眼，暖陽和清風交替的拂過臉頰，此情此景，直到現在還令我回味無窮。 而蕩舟伊洛瓦底江，在淋漓波光的映襯下，看著那一輪紅日漸漸隱去，整個內心都被徹底的放空。

![](/image/blog/or288.jpeg)

5. 這裡的人們。

每次旅行，最打動我的，總會是當地的人們。緬甸的人們，留給我的印象是淳樸，親切，誠實，友善，面帶微笑，樂於助人。似乎所有積極的字眼都可以用在形容這裡的人身上。他們樸素，卻散發著人性中的善，他們低調，卻能感受到人與人之間的信任和關愛。

![](/image/blog/r7zxa.jpeg)

這次，也第一次嘗試用視頻的方式記錄所見，以下便是回來後剪輯而成的一段視頻，多年後看起，定然還會記起這個令人無限回味的地方。

緬甸之旅已然結束，人生的旅程依然在繼續。


緬甸之旅，在不抱期望中開始，在充滿意外的驚喜以及無限懷念中結束。一如既往的，回來後好久不能適應香港的生活，好想就這樣旅行下去，感受這個世界，探索這無窮無盡的未知。

緬甸 - 意外的驚喜


當嘉莉在群中召集我們聚會的時候，我還在猶豫要不要去。一個是距離實在比較遠，再一個是怕這麼久沒有見面，各自的生活圈都不一樣，八年後再聚，恐怕沒有太多的共同語言。

可是當我現在坐在返程的火車上，靜下心來回憶這一天的經歷，才發現竟然很久都沒有這麼開懷過了。大學四年的最純真的友誼，再怎麼時過境遷，都不會改變。雖說一眨眼八年過去，大家很多已經成家立室，各有自己的事業，但是今天再聚首，竟覺得絲毫沒有因此而影響彼此之間心與心的距離。

![](/image/blog/lv2zo.jpeg)

![](/image/blog/7kpei.jpeg)

![](/image/blog/dijks.jpeg)

再聚首，也讓自己看到了當初同在一個屋簷下的同學們各自的成長。有的自己開公司做老闆，有的在企業做高管，有的準備移民開始新的生活，有的已經成為兩個孩子的家長，有的發展副業成為神秘的珠寶獵人，有的依然沒有放棄專業在研究領域繼續打拼...

雖說自己在眾星雲集的同學們中不是最亮的也不是最引人矚目的，但生活這個東西本就很難說熟好熟不好，見到大家開開心心的生活，各自有各自的成功，也各自有各自的煩惱。這次再聚首也給自己帶來了很多正能量，讓我在今後的道路上前行的更遠。

和超悅，楚群，在十年前的同一個地方拍了一張同樣姿勢的照片。百感交集。十年時間竟然就這樣不知不覺的過去了。十年間發生了太多的事情，我的生活圈也輾轉變化了幾個城市，但如今回到這裡，同樣的地方，同樣的人，感覺似乎什麼也沒有發生過一樣。大家還是504的好夥伴，等一下回宿舍做功課，談天說地。

![](/image/blog/vbiwh.jpeg)

![](/image/blog/tyb2t.jpeg)

當今天再次走過教二，經過一條條熟悉的道路，通往那個居住了三年的地方的時候，無數的一幕幕在腦海中閃過。看著這熟悉的宿舍，雖說周圍的景象有了一些改變，但依然感覺宛若時空穿梭一樣回到了八年前。多少次在這里出入，多少人在這裡相遇相識相知，多少畢生難忘的故事在這裡走入心裡，一時百感交集，竟有一絲傷感，過去的，真的就過去了，時間畢竟不能穿越，年齡畢竟不會再回到22歲，在這裡的所有，也已經隨著時間的流逝，成為回憶，甚至慢慢褪色，消逝于不知不覺之中。

![](/image/blog/wmjnp.jpeg)

![](/image/blog/todyt.jpeg)

![](/image/blog/rpjam.jpeg)

這次聚會，見到了好久沒有見到的最美的同學們。或許是因為放下了長期工作慢慢沉積在臉上的面具，用自己最真的一面去面對大家，面對自己，因而覺得特別開心。在農學院前面擺拍各種pose，在教三悄悄的混進教室自拍，在雨中漫步在校道上，在超市豪氣的買下一堆華農酸奶，因為見到這些可愛的同學們不自覺的就提高了嗓音，在地鐵裡面高聲喧譁，什麼素質啊，禮貌啊都拋之腦後，管他旁邊的人怎麼看，跟隨自己的內心，該說說該笑笑 .... 真是很久沒有這麼開懷，無所顧忌了，這些或許才是壓抑在內心中最真最自我的情感。

火車即將抵達紅磡站。在經歷了這穿越的一天後生活也即將繼續。希望自己今後能多多和這些可愛的朋友們見見面，說說話，他們，是生命中很重要而且無可替代的財富。

期待再聚首！


這次聚會，見到了好久沒有見到的最美的同學們。或許是因為放下了長期工作慢慢沉積在臉上的面具，用自己最真的一面去面對大家，面對自己，因而覺得特別開心。

時隔八年 華農再聚首


就這樣，期盼已久的土耳其之旅，劃上了句號。旅行網誌還沒有寫完，先記錄一下自己想到的一些東西。

9天的時間，宛如一場漫長的夢，到現在，閉上眼，這一幕幕依然在腦海回放。當自己再次回到這個熟悉的香港，我問問自己，去之前和去之後，除了一些新的體驗，除了看到一些之前沒有看過的人和事，自己得到了什麼。

旅行是一個很好的坦然面對自己的過程，踏上旅途的那一刻，你便拋下了一切面具，一切羈絆，帶著那個最真實的自己，開始了一場追求真我的旅程。除了經歷的新東西，其實更具價值的是這些東西讓你看到的真實的自己，以及這些一切的一切帶給你的心靈上的強化，昇華。旅行會讓你變得更懂得怎麼樣為人處世，更懂得怎麼樣去融入這個世界，在旅途的過程中你會懂得包容，懂得體諒，懂得換位思考，懂得接受自己本不能接受的真實存在，你會慢慢懂得放下自我，放空自我，因為在自己的那點事對於這個世界來說其實是那麼的不值一提。

有聲音告訴我我是一個有自我為中心傾向的人，旅行的過程中只要自己高興就可以，其他的一切都不Care，自己的責任就是自己。儘管自己不認同，但自己所表現出來的態度，氣場，行為，讓人有這樣的感受，也從一個側面印證著這些。有時候我看起來很沉默，待在自己的世界裡出不來，不想被干擾，不想去Care一些被我認為不在一個頻率的聲音，雖然至今我也不能準確的回答這些所謂自我為中心好還是不好，但慢慢的我會更加用心的去審視自己，是不是長期的獨立生活造就了自己對自己生活的掌控欲，自己是不是真的忽略了人與人之間的一些最原始的理解和體諒。

目前還沒有完全參透。

今晚去見了舅舅和舅媽一家。他們對我的寄語讓我從另外一個角度去審視自己當下的生活。也正是這些話讓我今晚靜下心來思考這個問題。

土耳其之旅，雖然沒有我預想中的那麼完美，但著實收穫了很多。還會再去麼？誰知道呢？


就這樣，期盼已久的土耳其之旅，劃上了句號。旅行網誌還沒有寫完，先記錄一下自己想到的一些東西。 9天的時間，宛如一場漫長的夢，到現在，閉上眼，這一幕幕依然在腦海回放。當自己再次回到這個熟悉的香港，我問問自己，去之前和去之後，除了一些新的體驗， ...

土耳其旅行後記（一）


Day 8 Tips:

 *  以弗所遺蹟附近並沒有酒店甚至餐廳，前往以弗所遺蹟參觀，可以考慮住在距離以弗所3公里處的賽爾丘克，又或者住在40公里開外的土耳其第三大城市伊茲米爾。
 *  以弗所最出名的世界七大奇跡之一的阿特米絲神殿以及聖母瑪利亞故居，並不在以弗所古城遺蹟內，若要前往參觀，需要另行規劃路線。
 *  前往參觀以弗所，因為遺蹟內基本沒有樹蔭遮擋，若是盛夏，會酷熱難耐，須做好防暑防曬措施，或者選擇下午或是傍晚參觀。否則不僅辛苦，更會影響參觀心情。
 *  最後也是最重要的，本人此次的慘痛教訓，前往以弗所之前，切記切記要先了解以弗所的歷史以及各個建築物的大概位置和意義之後才前往，否則，你不僅體會不到以弗所的神聖，根本不知道眼前這座建築的來龍去脈，甚至會覺得無聊，想快點離開。即便遺蹟內可以租借講解器，但相信我，如果你沒有事先了解，你根本無法靜下心來聽。

首先，以弗所是此次土耳其之行最為最為最為最為遺憾的一個地方。不為別的，全因為自己在踏足之前沒有了解這裡的歷史。萬萬沒有想到這裡背後的歷史是如此的厚重，這座古城在宗教歷史上的意義是如此的重大。雖然曾踏足這片土地，但是當時不僅錯過了世界七大奇跡之一的阿特米絲神殿，錯過了聖母瑪利亞的故居，錯過了被後人津津樂道的妓院，錯過了塞爾瑟斯圖書館中的密道，甚至，差點和克里斯特大街上的各種巔峰建築擦肩而過。不僅如此，當時由於完全不知道歷史，即使沒有錯過的地方，也全然沒有留下太多的印象，因為烈日炎炎，汗流浹背，受此影響甚至連照片都沒有留下幾張，層一度想盡快離開，回酒店好好休息。當時的心思，不是如何欣賞和敬仰這座偉大的古城遺跡，而是怎麼樣拍照時能夠拍出大片效果，怎麼樣能夠快點看完走人。現在想來，心中的悔恨，無以言表。很難說此生會不會再次來到這裡，而此次遊覽，可謂是留下了巨大的遺憾。所以，在這篇網誌的開篇，誠懇的奉勸將會前往參觀以弗所的朋友們，一定要花上一些時間，了解一下以弗所的歷史，了解一下這裡的著名建築和故事，只有這樣，當你親身踏足，才會懷著謙卑和恭敬的心情，才會真正不虛此行。

![](/image/blog/9zjh7.png)

以弗所(Ephesus)，又稱艾菲索斯，是一個始建於公元前10世紀的古希臘城市。從上面這幅Google Map截圖可以看出，以弗所(五角星位置處)距離海邊很近，其實古時其坐落於愛琴海的出海口，只是因為長期以來的河道淤塞，泥沙沉積慢慢填充了海岸線，使以弗所逐漸遠離海邊。以弗所當年是著名的港口城市，憑藉著便利的位置和海上貿易，成為極度繁榮的大都會，政治，宗教，經濟，文化，貿易中心。上面的截圖中能看到的那條長長的街道(五角星左側)，就是著名的海港大街。

隨便說說以弗所的背景，足以讓人仰視這個神聖的地方。這裏擁有世界七大奇蹟之一的阿特米絲神殿，這裏是使徒保羅撰寫聖經「哥林多前書」的聖城，這裏是聖母瑪利亞終老之地，這裏還是宗教史上著名的以弗所大會召開的地方。當你知道這些之後，親臨這片土地，你會覺得這裏的一磚一瓦，一草一木，一塊石一粒沙，都是歷史的化身，雖滿目瘡痍，但卻孤傲地，不可抗拒的散發著神聖，讓人景仰，讓人陶醉。

![](/image/blog/ixpwq.jpeg)

上面這幅摘自網路的圖片，便是以弗所目前最出名，最多人參觀的地方，要注意以弗所遺蹟附近並沒有酒店甚至餐廳，前往以弗所遺蹟參觀，可以考慮住在距離以弗所3公里處的賽爾丘克，又或者住在40公里開外的土耳其第三大城市伊茲米爾。前者會是眾多遊客的首選，因為距離以弗所很近，甚至走路都可到達；而後者則可以在伊茲米爾（izmir）觀光以及方便前往其他城市，考慮到次日就要返回香港，因此我們選擇停留在伊茲米爾。伊茲米爾的巴士總站有巴士前往賽爾丘克，車程接近一小時左右，而塞爾丘克去往以弗所則非常方便，所以交通還是不需要擔心的。

以弗所最出名的世界七大奇跡之一的阿特米絲神殿（Artemission Temple），是在公元前550年，由建築師薩摩斯(Samos)、喬西宏(Chersihon)及他的兒子梅塔傑那斯(Metagenes)設計興建的。神殿全由大理石建成，是當時世界上最大的建築物，面積廣達6050平方公尺，由127條約19到20米高的石柱支撐著，即使在現代，也算得上是極其大型的建築了。公元前356年7月21日，神殿被希臘人黑若斯達特斯縱火焚毀。後經多次重建，直至公元246年，神殿被哥特人損壞，便再無法考證其重修歷史。下面這張便是神殿的假想圖（源自Google Image）。

![](/image/blog/hdbyt.jpeg)

要特別注意的是，阿特米絲神殿並不在以弗所景區內，其位置在景區東北邊，塞爾丘克附近的公路邊上。若要前往參觀，需要留意路線。神殿由於毀壞嚴重，今日留存下來的，僅僅剩下一根石柱，孤獨的昭示著那段顯赫的歷史。是次我們由於準備不足，未能有幸得見，甚至，當時都不知道有這樣的驚世建築存在于我們附近。如今只能看看下面兩張從Google Earth中獲取的照片，來從腦海中敬仰這個神聖的地方。

![](/image/blog/bwzko.jpeg)

![](/image/blog/r3gui.jpeg)

了解以弗所的歷史，不得不提到以弗所作為使徒保羅第三次傳教之旅的基地，成為了基督教早期的一個重要基地和信仰中心。保羅在以弗所停留了約三年時間，並且在這裡撰寫了「哥林多前書」。據聖經記載保羅在此期間醫治眾人，驅惡逐魔，並把有組織的傳教活動帶入了羅馬帝國境內。

![](/image/blog/z3ylb.jpeg)

另外，聖母瑪利亞故居，距離塞爾丘克大約7公里路程，天主教說這裡是聖母瑪利亞最後的家，聖母瑪利亞在此終老。可以從地圖看到，聖母瑪利亞故居距離以弗所景區有一段距離，因而我們是次亦是遺憾未能得見。

![](/image/blog/y99fa.png)

步入以弗所景區，能見到的就是一片片亂石廢墟，放眼望去，找不到一點完整地建築物。見到的都是一些斷壁殘垣。

![](/image/blog/4rkka.jpeg)

要說最令人矚目的遺跡之一，要算是上面這個露天大劇場遺跡了。這座環形大劇場，座落在海港大街的盡頭，依山而建，面朝大海，據稱能夠容納兩萬多人。如果爬到最頂上，可以眺望到遠處的愛琴海。劇場始建於古希臘時期，除了演出音樂，戲劇，角鬥等之外也是政治活動和宗教儀式的舉行場所。如今，歷經兩千多年，劇場依然在使用當中，每年夏秋季節的藝術節，劇場內每天均會有演出。

坐在劇場的台階上，閉上眼，腦海中會浮現出古時劇場內繁華熱鬧的景象，穿著華麗的人們從熱鬧的海港大街前往劇場，有秩序的進場，入座，演員們開始表演古希臘戲劇，精彩之處，人們鼓掌歡呼... 睜開眼，眼前的這座劇場彷彿就是一個歷史的見證者，經歷過繁榮，衰敗，曾消失在歷史的川流中，又以藝術品的角色被發現，回到現代人的世界。

從露天劇場走出來，經過神聖大道，便來到了古城內的另外一個地標，被稱為史上最情色的圖書館-塞爾瑟斯圖書館。

塞爾瑟斯圖書館建於公元二世紀，以當時以弗所總督父親的名字命名。這個圖書館據稱是世界上第一座有雙層保暖保濕牆壁的建築，第一座憑索書單領取書籍的圖書館。之所以稱塞爾瑟斯圖書館是情色圖書館，是因為當時圖書館僅允許男性進入，圖書館內部有一條密道，通向不遠處的妓院。男人們以讀書為幌子進入圖書館，通過密道進入妓院娛樂，男人們可以欺騙妻子說是去圖書館讀書，而實際則是去了其他地方。圖書館不遠處的路面，有一個據稱是史上最早的情色廣告的雕刻，上面刻有一個腳掌，一個女人像以及一個方塊，據說腳掌代表著年齡，女人則代表著妓女，而方塊則代表著金錢交易。

![](/image/blog/yev5l.jpeg)

![](/image/blog/lo6ej.jpeg)

塞爾瑟斯圖書館的藏書量層號稱小亞細亞第二大，正面是兩層，而內部則是三層走廊環繞。圖書館的大門，歷經火燒，地震等人禍天災後仍然傲然挺立，門口的石柱後面可清楚看到四座代表仁慈，思想，學識和智慧的女神雕像，不得不讓人佩服當時工匠們的手藝之高。

![](/image/blog/ommj8.jpeg)

塞爾瑟斯圖書館因為它宏偉的外觀和不凡的意義，也是遊客們的首選目標之一，當時我們在圖書館拍了不少照片，遺憾的是由於沒有做足功課，對其歷史背景知識的匱乏使我們也只是拍照而已，甚至連通向妓院的密道，也沒有去尋找（因為不知道）。現在想起，實在覺得後悔，身處如此一個承載著厚重歷史的地方，因為無知，而錯過了很多本不應該錯過的東西。

從圖書館出來繼續往前走，便進入克里斯特大街，這條街道是以弗所最大最重要的街道，兩旁佈滿了各種重要的建築和設施，比如市政廳，哈德良神廟，行政廣場，劇場，以及古時作為社交場所的浴場和廁所等等。其實就算不說，當你走到這條大街上已然能夠感受到這條街道的重要性，因為兩旁佈滿各種遺跡，其中不乏各種製作精美的雕像，噴泉，大門等，無不昭示著當時這條大街的繁榮。

在克里斯特大街上首先映入眼簾的，是這個要另外收費參觀的古羅馬階梯住宅，在這裡可以看到當時人們的居所樣貌。我們參觀的當時此處還在修繕（發掘保護）當中，裡面可以看到很多精美的地磚以及壁畫。

![](/image/blog/lf7ix.jpeg)

在古羅馬階梯住宅的對面，便是哈德良神廟，克里斯特大街上最精美的建築。哈德良，是羅馬帝國第十四任皇帝，羅馬五賢帝之一。而哈德良神廟則是建造于公元前138年（或之前建成），用以獻給前來以弗所參觀哈德良大帝。其外墻是一個由四根石柱支撐的拱門，拱門中間雕刻著自由女神像。而內牆正面門上的雕像則（據稱）是蛇發女妖美杜莎。

![](/image/blog/xx4nw.jpeg)

克里斯特大街上的另一個吸引人的地方，要數人人都需要使用的古羅馬公眾廁所了（確切說應該是男廁所，因為據稱當時女性地位較低，甚至不會專為女性興建公廁）。 這座公眾廁所就坐落在哈德良神廟的旁邊。不進去看看還真想不到，古羅馬時期的廁所，竟會是這樣一種形式。一排的坐廁一字排開，中間沒有任何遮擋，人們就坐在上面，解決大小二事。據說當時如廁也是一種社交活動，因為以弗所當時是海港城市，很多有錢有地位的商人政客在城中活動，因此人們如廁的同時，也會談談生意，討論討論家事國事天下事。

![](/image/blog/8ti47.jpeg)

另外有趣的是，通過後來網上搜尋得知，當時的人們如廁之後，會用一根類似火把的棍子，前面有類似棉花一樣的東西沾水清潔污物。馬桶前面的洞，剛好可以將這根棍子伸進去，清潔完成後，將棉花丟棄在馬桶內的深渠內。馬桶渠內有水流過，可以將污物沖走。而廁所內有流動著清水的水道，人們如廁後可以在那裡清洗雙手。

![](/image/blog/rguek.png)

再往前走，便能夠看到圖拉真噴泉，這座為了紀念圖拉真皇帝的噴泉，建於公元104年左右，也是古城內保存較為完好的建築之一了。據以弗所網站介紹，噴泉中心有圖拉真帝的雕像，但似乎今日已經無從得見。

![](/image/blog/sfwsa.jpeg)

克里斯特大街的後半部，可以看到著名 的勝利女神 Nike雕 像，據說著名的運動品牌Nike的Logo設計靈感就是出自這裡。勝利女神Nike是泰坦巨神Pallas和海洋女神Styx的女兒，此處的勝利女神像一手拿著象征勝利的桂冠，一手挽著橄欖枝，雖說有點感覺孤零零的散落在此，但也掩飾不住她給人帶來的那種向上，積極，祥和的感覺。

說來尷尬，若不是為了尋找勝利女神像，或許我們此程會錯失更多的重要景點。因為第一次我們僅僅走了以弗所景區的一半，便以為已經完成了參觀準備返回，後來發現竟然沒有看到勝利女神像，以及手中加購的羅馬階梯建築參觀券也並未使用，所以才略為不情願的折回圖書館，後來才發現原來原來我們幾乎錯過了整條克里斯特大街。

![](/image/blog/5g5u2.jpeg)

克里斯特大街的尾端，是圖密善廣場，至此，以弗所古城算是基本遊覽完畢。記得當時走到 圖密善廣場，已然精疲力盡，因為烈日當空，古城內又基本沒有樹蔭可以遮擋，再加上拿著沉重的相機，心裡無比焦躁，只想著儘快結束行程，看看已經到了古城尾端，終於可以「無憾」而返。後來才得知，圖密善廣場附近，其實還有很多可以參觀的遺蹟，比如公共浴室，歌劇院等。印象中當時焦躁的走了幾處地方，拍了下面幾張照片，但是具體的印象已經很模糊，這又是是次遺憾之一。

![](/image/blog/g5qpf.jpeg)

![](/image/blog/njztp.jpeg)

最後，說說以弗所古城的沒落。

後來，通往愛琴海的河道嚴重淤塞，造成貿易中斷，加上地震頻仍，居民被遷至阿亞索魯克山一帶。以弗所又失去了貿易中心的地位，走向沒落。 元15世紀，被鄂圖曼帝國統治，自此以弗所從歷史舞臺上消失，被埋葬在滾滾的黃沙下，難以辨識，開始從人們的記憶中消失。（以上節選自網路）

離開以弗所之後，我們又乘搭小巴前往了著名的愛琴海，不得不說其實感覺就是一個普通的海灘，烈日下，更是和印象中的愛琴海聯繫不到一起。估計只是因為這個好聽的名字，才覺得會有所不同吧。

![](/image/blog/j12ne.jpeg)


以弗所是此次土耳其之行最為最為最為最為遺憾的一個地方。不為別的，全因為自己在踏足之前沒有了解這裡的歷史。萬萬沒有想到這裡背後的歷史是如此的厚重，這座古城在宗教歷史上的意義是如此的重大。雖然曾踏足這片土地，但是當時不僅錯過了世界七大奇跡之一的阿特米絲神殿，錯過了聖母瑪利亞的故居，錯過了被後人津津樂道的妓院，錯過了塞爾瑟斯圖書館中的密道，甚至，差點和克里斯特大街上的各種巔峰建築擦肩而過。

星月之國 Day 8 以弗所 世界上最大的古羅馬遺跡


第七天的行程，是最沒有行程的一天。

早上在酒店用畢早餐，便背著背包前往車站乘搭長途巴士前往下一個目的地伊茲密爾。因為要寄明信片的緣故，先輾轉前往附近的郵局，之後才乘搭的士前往車站。感受了土耳其的士車資的概念，大約10分鐘車程，收費20里拉。

去往伊茲密爾的巴士車程6小時左右，一路欣賞風景，倒也愉快。車上有一個胖胖的乘務員一路推個迷你小車派發飲品和食物，頗有空乘的感覺。雖說食物並不可口，但這麼好的服務也值得點贊。

![](/image/blog/dcfmt.jpeg)

6小時的車程後，抵達伊茲密爾巴士總站。下車後瞬間感到不知所措，因為這裡距離我們的酒店還有一段距離，而此時我們拖著疲憊的身軀，在這偌大的陌生車站，在語言完全不通的情況下，完全不知道要如何前往。硬著頭皮問車站的工作人員，但發現這裡的人英文能力基本為零，只能靠手舞足蹈加上一些地名發音來溝通，一番周折後，終於在好心人的帶領下找到了免費的接駁巴士，不知道是Eacho訂酒店時研究過車站位置還是真是幸運之神照顧，接駁巴士的終點站正好在我們酒店的旁邊。下車後稍走兩步即到。

酒店附近的街道上，全是土耳其當地人。不知道是不是因為齋月的原因，他們都是圍坐在街邊喝茶談話。 放眼望去似乎我們是唯一的外國人， 受之前經歷的影響，走在他們中間，也頗有一點不自在，不時的提醒自己，低調，低調。

![](/image/blog/tddx2.jpeg)

酒店給人的感覺不錯，頗有星級酒店富麗堂皇的感覺。但不知為什麼，可能是位置的原因，覺得這酒店有點說不出的陰森。服務生很友善的幫我們拿行李到房間內，并告訴我們如何使用冷氣，電視等。但頗為尷尬的是當時沒有反應過來給他小費，土耳其畢竟有小費文化，酒店服務生幫你做這些事情理應適當給予小費。服務生看我們沒什麼反應之後，也只有悻悻地離開了。酒店的房間不大，床位也很小，以致Eacho多次從床上掉下來。印象中土耳其的酒店頗有香港的感覺，價格貴，地方小。

晚餐我們在就近的當地餐廳解決。這次用餐也是全程印象最深的一次用餐經歷之一。老闆很客氣也很熱情，但因為他完全不會英文 ，溝通起來頗為幽默。他 不但熱情的給我們一路補充食物，示範給我們看怎麼吃“煎餅果子”，還在用餐結束後免費贈送土耳其茶，喝完一杯以後還叫他兒子出去再給我們送來一杯。說來慚愧，這個動作我竟然以為他是去找土耳其茶的店老闆來結賬，還和Eacho爭執了一番。最後證明我再一次用小人之心度君子之腹，其實他是再送我們一杯茶。因為語言不通的原因，和他們的溝通，靠動作之餘，Google Translate軟件也派上了用場，他們似乎沒見過類似的軟件工具，對此表現出十分的好奇，對著我的手機的待機界面哇啦哇啦說個不停，要知道這時候我還沒有啟動Google Translate程式，他們那時候說了什麼，也只能成為千古之謎了。

![](/image/blog/tgdxq.jpeg)

![](/image/blog/p2ikk.jpeg)

晚餐用畢，送了他們小禮物，然後就回酒店休息了。因為次日要前往以弗所，所以問了一下酒店前台，得知他們有以弗所一日遊的團，但要價80歐每人，這個價格仔細算算就知道其實貴的離譜。於是便決定第二天自行乘車前往。


去往伊茲密爾的巴士車程6小時左右，一路欣賞風景，倒也愉快。晚餐我們在就近的當地餐廳解決。這次用餐也是全程印象最深的一次用餐經歷之一。

星月之國 Day 7 出發 伊茲密爾


Day 6 Tips:

 *  滑翔傘基本上全是國人在參加，不想扎堆的要考慮清楚。
 *  滑翔傘不能自帶攝影設備。
 *  滑翔傘整個活動耗時大約三小時。

在費特希耶的經歷也算是此次土耳其之行印象最深刻的一天了。這裡集中了極好和極不好的印象。

費特希耶最出名的是死海，周圍的各種島嶼以及應運而生的極限運動﹣滑翔傘。這也是我們選擇這裡作為第六天的目的地的原因。很早前就希望能夠嘗試一下滑翔傘，但因為各種原因阻滯，竟在土耳其實現了這個由來已久的夢想。通宵巴士早上很早就到達費特希耶，巴士站距離我們住的酒店有一段距離。但是正如前文所述，我們剛下巴士正準備Google Map尋找前往酒店的方式時一個當地人竟然走了過來，問我們是不是某某某，於是我們就這樣神一般的被Pick Up了，雖然接送服務在預定中包括，但因為不報太大期望，能順利的和司機接頭，也是很意外的。

費特希耶的酒店是全程中最貴的，但不知是不是因為土耳其的物價高，酒店的質量也和我期望中的有一段差距。由於時間太早不能Check In，我們只得在大堂內等候，大堂小哥很好的送了我們早餐，所以等待的時間也是蠻輕鬆的。早餐不錯，環境很舒服，看的到美麗的海港，就這麼慢慢的坐著，也是一種享受。

![](/image/blog/yit5q.jpeg)

九點鐘，滑翔傘的公司準時來酒店Pick Up，大約半小時輾轉于各個酒店，一車人坐滿，前往滑翔傘公司。進了公司大堂等候，我也是徹底無言以對了。整個大廳估計幾百人，放眼望去95％都是同胞。感嘆祖國的強大。

待到裝備好GoPro等設備，竟然被告知不能自帶攝像設備，所謂安全考慮。失望之極，但也沒有辦法只得服從。很快聽到職員叫我們酒店的名子，然後就乘坐一架小車，出發！大約二十分鐘的車程，去到了山頂的一座平台，眾人下車，準備裝備。待到我準備完畢往後一望，竟然發現其他人都坐車離開了，說實話此時心頭略過一絲緊張，問教練得知他們因為氣流原因前往更高的地方起飛。哈哈，於是我就成了唯一的一個在這裡起飛的人。

滑翔傘最刺激的要屬起飛的那一剎那了。教練說我太胖，要我加速跑才行，當時還蠻擔心的，聽到他的一聲令下之後狂跑，但事實上其實基本無法控制，因為自己被綁在他身上，基本無法著地。還沒來得及想竟然發現已經騰空了。在滑翔傘上的視覺衝擊力無法用言語形容。風在耳邊呼呼的吹過，腳下就是藍的很透徹的死海。整個飛翔的過程很平穩，絕大多數時間都是在被這前所未見的景象震撼著，那一刻，真正屬於自己，能做的唯一事情，就是享受那一刻。在徵得你的同意後，教練會進行一些旋轉動作，那感覺就好像垂直過山車俯衝的那一剎那，失重感會另到身體很不舒服，頭暈，腸胃翻滾，但感覺很奇特，還是很值得一試的。飛翔過程中，教練會為你拍照，這些照片之後可以自費購買。大約15分鐘左右，滑翔傘平穩的降落在沙灘上，在沙灘上竟然遇到了之前節目中寧靜的教練，他自豪地向我展示他和寧靜的合影。很有趣的土耳其人。

![](/image/blog/jlx1q.jpeg)

滑翔傘結束後大約中午時分，在酒店辦理入住之後在酒店修整了一下，下午便出去吃晚餐。在海港附近遇到了一個很友善的大叔，向我們介紹了前往下一站 Izmir 的巴士站。

晚餐用畢，便準備在附近走走。碼頭附近有一條步行街，那裡有各式各樣的酒吧以及工藝品售賣小店。其中一家手工店鋪的老闆，在得知我們來自中國之後很嚴肅的問我們 “Why Chinese people are killing Muslims in China?”,當時有點意外會被問到這樣的問題，也只能說我們不知道有這樣的事情發生。現在想想看，也難怪他們會有這樣的問題。當新聞鋪天蓋地的報導著一些其他國家對自己的信仰不尊重的事情後，見到這個國家的人，自然或充滿疑問甚至心生氣憤。後來，又遇到另外一個店舖的人，看到了我脖子上掛著的十字架，又走過來問 “Do you know what is that? Are you Christian? Most of Chinese people are Buddhist so why you are Christian? If you are Christian you should help people, look at the boy over there, go help him!! Christian is not just wearing the cross in your neck … ”  這些問題，著實有些令人不舒服。信仰本是非常隱私的東西。我信什麼關你屁事，我也是出於禮貌有問必答的和他對話，現在想想看真是多餘。

費特希耶的一日就這樣結束。這一天除了滑翔傘之外過得似乎並不太有意義。既沒有好好的感受這個地方，也沒有與太多的人接觸，反倒是留下了一絲不愉快的經歷。想想看其實可以安排的更緊湊一點，滑翔傘結束後直接前往下一站，應該可以省下更多的時間。


費特希耶最出名的是死海，周圍的各種島嶼以及應運而生的極限運動﹣滑翔傘。這也是我們選擇這裡作為低第六天的目的地的原因。很早前就希望能夠嘗試一下滑翔傘，但因為各種原因阻滯，竟在土耳其實現了這個由來已久的夢想