概念很簡單

1. 設定一個 Schedule trigger node，固定每幾分鐘跑一次
2. 加上一個 HTTP Node，去抓 Status Page，例如我這裡想抓 Anthropic 的 Status Page
3. 然後將結果丟給一個 HTML node 去剪出我需要的部分內容就好。因為後面會用 ChatGPT 去分析這個網頁目前是否有 Outage，如果我將整個 HTML source 丟進去，可能會花掉不少 token 費用，所以我先剪出部分內容就好。以這個例子，我用 CSS selector 來做篩選

4. 接下來是將篩選出來的結果丟給 ChatGPT 去判斷

我使用 4o，並強制要求 JSON 格式輸出，底下是我使用的 Prompt

底下是某個 API 服務的 status page HTML 程式碼，請幫我分析一下目前這個服務是否有 outage
 {{ $json[''] || '' }}

請以底下 JSON 格式回傳:

{
  outage: true,
  status: 'status text'
}

如果沒有提供 HTML ，則代表沒有 Outage，回傳:

{
  outage: false,
  status: ''
}

5. 最後，用一個 IF node 去判斷 outage 欄位是否為 true ，如果是 true 就串到 Slack node 去通知 Slack channel

此外，我想做個改良，當從有 Outage 到 Outage 結束時，我也想做個通知，這樣才能確定 Outage 是否已經結束了，所以我必須把狀態儲存下來。

但，n8n 是 stateless 的，如果要儲存狀態，需要安裝一個額外的套件。

如果你是自己架設的 n8n server，你可以安裝一個 community node: @telepilotco/n8n-nodes-kv-storage

這是一個在記憶體的 Key Value Storage，所以 n8n 重跑後就沒有了，但沒關係，夠我們使用了。我們將 outage 的狀態儲存在一個 Key anthropic_status 當中。

在第四步驟的同時，讀出 anthropic_status 目前的值，然後將 ChatGPT 的結果結合，並加上一個 Code Node，來做判斷:

程式碼:

let notify = false;
let color = ':large_green_circle:';
let outage = false;
let status = '';
for (const item of $input.all()) {
  if (item.json.message.content.outage) {
    notify = true;
    color = ':red_circle:';
    outage = true;
    status = item.json.message.content.status;
  } else if (item.json.val && item.json.val[0]) {
    notify = true;
    color = ':large_green_circle:';
    outage = false;
    status = 'No more outage';
  }
}

return {
  json: {
    notify,
    color,
    outage,
    status
  }
}

然後我們就在接下來的 IF node 去判斷 notify 的結果是否為 true，如果是 true 就通知到 Slack:

Slack 的 block code:

{
 "blocks": [
  {
   "type": "section",
   "text": {
    "type": "mrkdwn",
    "text": "{{ $json.color }} {{ $json.status }}"
   }
  }
 ]
}

最後的結果就像這樣:

結語，n8n 很好用! 我逢人都會推 n8n，尤其在加入眾多 AI 串接功能後，很多自動化變得很容易，很容易就可以達到 no-code 自動化境界。

Keynote 出來後果然引起了廣泛討論，正反觀點都有，但看了幾篇網路文章，目前主流觀點都是逐漸往「Apple 更重視用戶隱私與 AI 落地應用，不直接硬幹大模型火力比拼」 這個方向走。

我自己也看了幾篇 Apple blog 跟 video，目前的了解是

1. Apple 有自己的語言模型，他稱之為 Foundation Model，參數數量約不到 30 億。要用小模型主要是因為他要放到裝置裡頭去。
2. 在手機內有內建一個壓縮過的 on-device foundation model，這個模型採用 adapter 的技術來適配到不同的功能上，讓不同的功能如文字摘要、生成等可以達到最好的效果。
3. 不管是 On-device model 還是 server model ，評測下來都比同等級的模型來得好，不過是不是自吹自捧還是要等公開評測才知道。
4. 裝置 (包含 iPhone 跟 mac) 上有個 orchestration 模組，會根據用戶的指令，判斷該用 on-device model 還是送到 server 端去使用較大的模型
5. 另外，Apple 為了獲得更多 User 的 context 資料，來讓 AI 更聰明，能做的事情更多。內部有個模組 Semantic Index ，系統會透過 App Entities 來取得 App 內的資料，Semantic Index 則是適當的調用不同 App 間的資料來讓不同的 model 使用。另外 App 可以透過 App Intent 來定義 Action 讓 Siri 可以知道怎麼操作該 App
6. Apple 為了確保隱私問題，重新設計了他的伺服器架構 Private Cloud Compute

Introducing Apple's On-Device and Server Foundation Models

Private Cloud Compute

Private Cloud Compute: A new frontier for AI privacy in the cloud - Apple Security Research

1. OS 採用簡化過的 iOS 系統
2. 沒有 persistent storage，沒有資料被 log 下來的疑慮
3. 沒有 remote shell，無法遠端登入
4. Secure enclave 保護 encryption key 安全
5. Secure boot 只允許 verified / signed 過的 OS image 可以被啟動
6. Trusted Execution Monitor 只允許 signed / verified 過的程式可以被執行
7. Attestation: 裝置在送 request 到 server cluster 前會先驗證 cluster 的 identity 跟 configuration，每個 request 都是端到端加密，只有被選定的 Cluster 可以解密，其他 Cluster 無法解密，確保連 Apple 自己都無法看到用戶內容
8. OS Image 都是公開可被檢視，如果有被發現漏洞或者有任何 Apple 宣稱沒做到的隱私保護，都會發獎金

至於 Elon 出來嗆 Apple 要是跟 OpenAI 合作，揚言不會在自家公司內允許員工使用 Apple devices (這將包含 Mac，大概一堆 Elon 員工在哀嚎了)，我覺得是放入了太多對 OpenAI 的個人感情在裡頭。

Elon Musk on X (formerly Twitter): "If Apple integrates OpenAI at the OS level, then Apple devices will be banned at my companies. That is an unacceptable security violation. / X"

If Apple integrates OpenAI at the OS level, then Apple devices will be banned at my companies. That is an unacceptable security violation.

Elon Musk on X (formerly Twitter): "Apple using the words "protect your privacy" while handing your data over to a third-party AI that they don't understand and can't themselves create is *not* protecting privacy at all! / X"

Apple using the words "protect your privacy" while handing your data over to a third-party AI that they don't understand and can't themselves create is *not* protecting privacy at all!

以目前的資訊了解，ChatGPT 在 iOS 內有點像是預設搜尋引擎的感覺，例如 Safari 的預設搜尋引擎是 Google，使用者用 Safari 狀態列搜尋會先跑到 Google 去，但用戶是可以改掉預設搜尋引擎的。

iOS 18 應該是直接內建 ChatGPT 支援，用戶不需要再為 ChatGPT 付費，Apple 幫你付了。但在調用前，Apple 也會尋求你的同意，使用時他也會透過 UI 讓你很清楚目前是在使用 ChatGPT。所以不存在隱私問題，這就像即便 Apple 沒有整合，你還是會用 ChatGPT 一樣。我不認為是 OS level 的整合。

iOS 18 還是以自家的模型為主。且看目前Apple自家模型的效能評測，其實不差了，所以 ChatGPT 很可能是個過渡型整合，等自家模型更成熟了，可能就會放棄 ChatGPT ，畢竟每年的權利金也是不少錢。 (有沒有既視感? Apple 過去曾放棄 Google Map 自己跑去開發地圖服務，只是一路走得跌跌撞撞就是)

另外，就算 Elon 對員工使用 ChatGPT 有 Security 疑慮，其實是可以透過 MDM 去關掉這個功能的，老馬可能不知道，或者純粹在抒發對 OpenAI 的不爽罷了。

我個人認為 Apple 揭示了未來 AI 落地應用可能的走向：

1. 不需要一個特大、超聰明的模型
2. 不同小模型、不同模態模型協同運作，有些是 on-device ，有些放 cloud
3. 由一個 orchestration 來協同這些模型的運作
4. OS level 可以調用不同 app 內的資料，透過 intent 去操作 app 動作，但都已達到最好的 User experience 以及確保 User privacy 為考量。

Andrej Karpathy 也有類似的看法

Andrej Karpathy on X (formerly Twitter): "Actually, really liked the Apple Intelligence announcement. It must be a very exciting time at Apple as they layer AI on top of the entire OS. A few of the major themes.Step 1 Multimodal I/O. Enable text/audio/image/video capability, both read and write. These are the native... / X"

Actually, really liked the Apple Intelligence announcement. It must be a very exciting time at Apple as they layer AI on top of the entire OS. A few of the major themes.Step 1 Multimodal I/O. Enable text/audio/image/video capability, both read and write. These are the native...

另外，這真的只有 Apple / Google 能做，這是 OpenAI 的夢想，但如果他沒自家硬體、作業系統，很難達成這個願景。

原文連結: https://blog.samaltman.com/idea-generation

翻譯開始:

新創創辦人最常問的問題是如何獲得新創公司的想法。第二個最常見的問題是你是否對他們的創業公司有任何想法。

但由別人給創辦人一個想法這樣的做法是行不通的。能夠擁有想法是新創公司創始人最重要的素質之一 — 你需要在經營新創公司的過程中產生大量的新想法。

YC曾經嘗試過一個實驗，即資助沒有想法但看似優秀的創辦人。但在這個軌道上的每一家公司都失敗了。事實證明，優秀的創辦人對任何事情都有很多想法，因此，如果你想成為一名創辦人，卻無法為公司獲得一個想法，你也許應該先在產生好想法上下功夫。

你如何做到這一點？

重要的是要在正確的環境中，和正確的人在一起。你要和那些對未來有良好感覺的人在一起，他們會接受看似不可能的計劃，很樂觀，在創造性方面很聰明，並且有很高的想法產出量。這類人往往在思考時沒有多數人的約束，沒有很多過濾器，也不太在乎別人的看法。

最好的想法是脆弱的；大多數人甚至根本不開始談論它們，因為它們聽起來很傻。也許最重要的是，你想和那些不會因為提到一個壞主意而讓你感到愚蠢的人在一起，當然他們自己也不會因為這樣做而感到愚蠢。

遠離那些厭世和貶低你的野心的人。不幸的是，這就是世界上的大多數人。但他們堅守著過去，而你想生活在未來。

你希望能夠把自己的目光投向未來20年，然後從那裡向後思考。相信你自己 — 20年是一個很長的時間；如果你對它的想法看起來很激進也沒關系。

另一種方法是思考現在正在發生的最重要的構造性轉變。世界是如何從根本上發生變化的？你能確定一個變化的前沿和它所釋放的機會嗎？2008–2012年的移動裝置爆炸發展是這方面最近的重要例子 — 我們早就該再來一次了!

在這樣的構造性轉變中，世界變化如此之快，以至於大的在位者通常會被快速移動和專注的新創企業擊敗。(順便說一下，善於區分真正的趨勢和虛假的趨勢是很有用的。一個關鍵的區分因素是，新平台是被少數人大量使用，還是被很多人少量使用）。

任何時候，只要你能想到今年有可能，而去年不可能的事情，你都應該注意。你可能有一個偉大的創業想法的種子。如果明年就太晚了，那就更是如此。

當你可以說 “我確信這將會發生，我只是不確定我們是否會是做這件事的人”，這是一個好兆頭。Uber對我來說就是這樣 — 在我第一次使用它之後，很明顯我們不會再叫出租車了，但我不確定Uber是否會贏得這個空間。

在思考一個想法的早期，要問自己一個好問題，那就是 “如果它成功了，這能成為巨大的財富嗎？” 世界上有許多好的想法，但很少有能使新創公司獲得巨大成功的內在優勢。大多數企業在擴大規模時不會產生有價值的積累性優勢。盡早思考為什麽一個想法可能具有這種屬性。對於 Facebook 或 Airbnb 來說，它是顯而易見的，但它往往以更微妙的方式存在。

思考你適合做什麽也很重要。這一點很難用純粹的內省來做；理想情況下，你可以問問導師或一些與你合作過的人，你特別擅長什麽。我逐漸相信，創辦人/公司的適合性 (founder/company fit) 與產品/市場 (product/market fit) 的適合性一樣重要。

最後，對一個想法的良好測試是，如果你能闡明為什麽大多數人認為這是一個壞主意，但你明白它好在哪里。

這是我在2018年中國的一個YC活動中的演講筆記。感謝 Eric Migicovsky 鼓勵我把它貼出來!

我寫這篇文章時，我主要考慮的是新創公司；現在我主要考慮的是人工智慧發展。我對其中很多內容的適用性感到震驚，特別是第5–9段。

本文講解一下如何用 OpenAI API 快速打造自己的工具，本文以網路文章的摘要與翻譯產生器為例。原本這個是用來解決我自己的問題，但我想透過同樣的方式，你也快速打造自己的 OpenAI 工具。

先來看看最後成果長什麼樣子:

summarization · Streamlit

一開始先讓使用者輸入自己的 OpenAI API Key，再來是輸入文章網址，程式會自動抓取網頁的內文，透過 OpenAI 產生摘要。

整個 app 是透過 Streamlit 打造，Streamlit 原本是打造給深度學習AI 的一個工具，很類似 JupiterNotebook。透過它，你不需要了解前後端技術，只要會寫 Python，就可以寫出類似的 App，並且在 Streamlit 上執行完全不需要費用。

程式本身也不複雜，可以參考原始程式碼:

GitHub - syshen/summarization

只有約一百行程式左右。不過有點要注意的是，由於 GPT3 有 Token的上限，最高只允許 4096 個 Token，但是我們在分析一些長文時，很容易就超過這個上限，目前 OpenAI 建議的做法也是將文章拆成數個片段，依序去執行。

所以要拆文章時，可以用 pretrained 的 GPT2 切 Token 的方式來做估算，以兩千個 Token 為單位拆開，再個別丟給 OpenAI 就好。

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("gpt2")

def text_to_chunks(text, chunk_size=2000, overlap=100):
  tokens = tokenizer.encode(text)
  num_tokens = len(tokens)
    
  chunks = []
  for i in range(0, num_tokens, chunk_size - overlap):
    chunk = tokens[i:i + chunk_size]
    chunks.append(chunk)
    
  return chunks

因為是切出多個 Chunk，所以每個 Chunk 之間也保留 100 個 Token 的 overlap ，來避免有些資訊不見了。

OpenAI API 呼叫方式可以參考官方文件，但它是 Restful API，透過 SDK 使用很簡單:

def callOpenAI(prompt_request, max_tokens=500):
  response = openai.Completion.create(
            model="text-davinci-003",
            prompt=prompt_request,
            temperature=.5,
            max_tokens=max_tokens,
            top_p=1,
            frequency_penalty=0,
            presence_penalty=0
  )
  return response.choices[0].text

GPT 模型都是用 Prompt 去控制你要的結果，所以只要在文字前給予正確的指令就好，例如: Summarize text: <your article text>

兜在一起要做文章摘要程式會像這樣:

def summarize_text(full_text):
  chunks = text_to_chunks(full_text)
  summaries = []

  for i, chunk in enumerate(chunks):
    text = tokenizer.decode(chunks[i])
    summary = callOpenAI(f"Summarize: {text}")
    summaries.append(summary)    

  if len(summaries) > 0:
    final_summary = callOpenAI(f"Consolidate the summaries with paragraphs: {str(summaries)}", max_tokens=2000)
  return final_summary

每個 Chunk 個摘要組合起來，再請 OpenAI 做個最後總結就好了。

最後用 Streamlit 來控制程式執行流程，至於 Streamlit 怎麼用，可以參考一些網路上的中文說明，例如這篇。

你可以先在本機端跑 Streamlit 測試，測試好了，註冊 Streamlit 帳號，連結 Github ，然後就可以部署到 Streamlit 上去給別人用了。

記得不要隨便把 OpenAI API 直接放在程式裡讓別人使用，要不然你的 Quota 很快就爆了。

不過這篇文章不是要講什麼「我早就知道」「早說會這樣」的文章，但我比較想要聊這件事會怎麼影響未來技術的發展。

這幾天，包含 CZ 在內都拋出了 Proof of reserve (儲備證明 PoR) 的概念，基本上概念就是交易所要做自清，把資產攤出來給大家看，目前幾間交易所為了自清公佈自家金庫地址，並透過 Nansen porfolio 公佈出來以昭公信，其中包含

Bitfinex https://portfolio.nansen.ai/dashboard/bitfinex
Cyrpto.com https://portfolio.nansen.ai/dashboard/crypto.com
KuCoins https://portfolio.nansen.ai/dashboard/kucoin
Binance https://portfolio.nansen.ai/dashboard/binance
OKX https://portfolio.nansen.ai/dashboard/okx

大家可以看一下這些交易所內部的資產分佈，但他們事實上不能證明什麼，因為你不知道目前交易所是否有沒公佈的地址。另外根據 Nic Carter 的講法，你要符合底下公式:

Proof of Reserves + Proof of Liability = Proof of Solvency

Proof of Liability (PoL) 是指債務證明，兩者相加代表該交易所的償還能力，這要是正的才行，概念很簡單，就是資要能抵債。

所以最近幾天包含 CZ 在內紛紛出來鼓吹儲備證明，Chainlink 更是趕在這波新聞下推出了 Proof of reserve 服務。其實這個概念並不是最近才出來的，一兩年前就有人在提，交易所 Kraken 在今年年初就率先提供了相關服務給他的用戶，他的用戶可以看到自己的資產什麼時候被稽核過，以及被哪個單位稽核。

Nic Carter 推出了一個網站，條列了目前 PoR 的發展狀況，以及有哪些交易所或者 Fund 答應要支援或者已經支援 PoR。

目前被提出來的執行方式是透過 Merkle Tree 的方式來實作。Merkle Tree 經常被用在區塊鏈相關技術中，概念是將資料分段去做雜湊運算，再將個別雜湊組合起來再繼續算雜湊，就像一個樹倒過來，好處是可以個別資料做驗證，如果其中一部分有資料被變動過，也可以立刻知道是哪段資料有問題，也能節省整體的運算量。運用在 PoR 上，交易所會定期做 snapshot，計算 Merkle Tree，每個用戶可以在自己的帳戶資料下，知道屬於自己帳戶 balance 的雜湊，然後整個 Merkle Tree 會被保存下來，並交給稽核公司查核。每個用戶當然不能知道其他用戶的 balance，但是可以藉由知道自己的 balance 以及自己的雜湊來判斷整個 Root 雜湊是否有被串改過，或者交易所有沒有把你的 balance 算在他 Merkle Tree 內。

不過光只有 PoR 是不夠的，你還需要 PoL (Proof of Liability)，你的債務到哪去了？但我覺得未來很可能會走向不管交易所或者 Fund 都會需要整合 PoR，並公告金庫地址，由於區塊鏈特性，他們的資金流向會變得更透明。再進一步延伸，我認為未來 PoR 資料都會上鏈，可以被任何人檢驗，然後會有更多第三方的信評機構會出現，透過這些公開資訊給予信用評鑑，這些信評機構需要公開他們評鑑的方式，不同機構評鑑的方式不同，給予的信用分數也會不同，但交易所或投資公司可以將這些信用分數放在官網讓用戶參考。此外，信評機構透過區塊鏈 DID 技術 (Decentralized Identity)，為評鑑結果背書並上鏈。

透過透明的資金流向，這些交易所或者基金也必須要跟同樣標準有提供 PoR 的投資公司合作，如果資金流動到相對不透明的錢包，會進而影響到自己的信用分數，透過這樣的方式做到 Chain of trust。

所以說，並不是說交易所或者 Fund 不能拿用戶的錢轉投資，因為傳統金融也都會做類似的事情，只是你的投資方式要比以往更透明，投資人透過信用分數來評斷風險，風險與報酬能夠被更透明的機制評斷，如果風險承受度低，可以選擇信用評鑑分數高的投資公司，但相對地獲取報酬會比較低。但如果想要獲取較高的報酬，可以承受較高的風險，可以找尋報酬高但信用評鑑較沒那麼高的投資公司，但風險自負。

此外，由於資金流向會有可能影響到信用評鑑，所以未來像是 Binance 這樣什麼都做的交易所可能會開始拆分成不同的實體，有點像是傳統金融，銀行是銀行，投資公司是投資公司，兩者不能混在一起。Binance 這樣的龐然大物需要拆分「純交易所」跟「投資公司」，用戶存在交易所內的資金不能隨意被拿來做其他用途，如此一來用戶權益才能受到保障。

人類有個特性，會從犯的錯誤中學習，然後再忘記再犯錯，在一個又一個不斷犯錯學習改正的循環中前進。所以前面才會提到，FTX 事件像是另外一個雷曼兄弟翻版，人們可能早已忘了過去金融風暴中所犯的錯誤，又再痛了一次。類似的事情未來還是會繼續發生，人們畢竟是健忘的，但每次犯錯就會再往前一點點，逐步的改善讓環境越來越好。

這裡用的 CI 是 gitlab CI，TCMS 是 Kiwi 雲端版。Kiwi 因為有支援 RobotFramework 以及自動化測試，然後又便宜，所以我們公司目前採用 Kiwi 作為 Test Case Management System。

概念其實很簡單，分作兩部分，第一部份怎麼將 RobotFramework 的執行結果更新到 TCMS 系統中，第二部分則是怎麼讓 CI build 同時去觸發 RobotFramework 對新 build 執行自動化測試。

先講第一部分，怎麼將 RF 的執行結果更新到 TCMS 中。

1. 先安裝 RF 的 kiwitcms 套件 pip install --upgrade kiwitcms-robotframework-plugin
2. 在 Home directory 中，建立 ~/.tcms.conf 檔案，並輸入你的 Kiwi 網址與帳號密碼

[tcms]
url = https://<your_tenant_name>.tenant.kiwitcms.org/xml-rpc/
username = <login_account>
password = <your_password>

3. 將底下程式 (儲存為 tcmsTools.py)跟你的 RF 腳本放在一起

import os
from zealand.listener import KiwiTCMS
from zealand.listener import RFBackend

class PrivateTenantBackend(RFBackend):
    def default_tester_id(self):
        user_id = self.built_in.get_variable_value('${build_user_id}')
        return user_id

    def finish_test_run(self):
        self.rpc.TestRun.add_tag(self.run_id, 'automation')

class PrivateTenantKiwi(KiwiTCMS):
    backend_class = CuboBackend

為什麼要加這個程式，因為我們的 Kiwi 環境是直接跟 Kiwi 租用的，所以呼叫 tcms_api 的 User api 都會得到 403 Forbidden 的錯誤，為了避開這個錯誤，我在這段程式中多加個 build_user_id 來讓你可以直接輸入 tester 的 user id，而繞開 User API 的呼叫(如果你是自己架設 Kiwi 系統，應該是可以不用多加這段程式碼)。另外，這段程式也會在結束測試時，在該 Test Run 多加個 automation 的 tag，如此一來在 Kiwi 中搜尋 automated test runs 時會比較容易。

接下來在你的 RF 腳本中，要多帶幾個參數

*** Variables ***
${plan_id}                          11
${product}                          Cubo Ai Baby Camera
${build_user_id}                    9062

*** Test Cases ****
成功登入
    [Tags]              TC-1110     login
    #.....

• plan_id: 這個 Test suite 是要測試哪個 Test plan。我的習慣是會建立一個 Automation 的 Test plan，然後在這裡指定該 Test plan 的 ID
• product: 輸入你 Kiwi 中的產品名稱
• build_user_id: 輸入 tester 的 user id (如果你不是用我附加的程式碼，請在這裡換成 tester 以及該測試者的 email)

另外在每個 Test case 中，會多帶 [Tags] TC-1110 login ，其中 TC-1110 是某個 test case 的 ID，這裡是用 Tags 的指令來表示該 test case 對應到 Kiwi 中是哪個測試項目。

執行 RobotFramework 的方式改為:

export TCMS_PRODUCT_VERSION=2.0
export TCMS_BUILD=2377
robot  --listener tcmsTools.PrivateTenantKiwi  tcms_test.robot

執行完畢後，檢查 Kiwi，就會有筆 Test run 被建立出來:

如此一來，RobotFramework 與 Kiwi的串連就完成了。

但是你可能有注意到，上面在執行 RobotFramework 腳本時，有多帶個 TCMS_PRODUCT_VERSION 與 TCMS_BUILD ，這兩個參數從哪裡來，其實就是要從 CI build 而來。

什麼？你們公司還沒有 CI Build? 那要先檢討一下了

我們用 gitlab CI 來做範例，我們的做法是在公司放一台 Mac mini 執行 gitlab-runner 來跑 CI。所以當工程師把 Code commit 並 push 到 gitlab 時就會觸發 CI 流程。

.ios-build-task:
  stage: build
  tags:
    - ios-build
  only:
    - dev

.ios-test-task:
  stage: test
  variables:
    GIT_SUBMODULE_STRATEGY: recursive
  tags:
    - ios-build
  only:
    - dev

stages:
  - build
  - test
  - deploy

variables:
  LC_ALL: "en_US.UTF-8"

before_script:
  - pod repo update
  - pod install

build_project:
  extends: .ios-build-task
  script:
    - xcodebuild clean -workspace "Cubo.xcworkspace" -scheme "Cubo" | xcpretty
    - bundle exec fastlane beta_build
artifacts:
    paths:
      - build.xcarchive
      - build

automation-test:
  extends: .ios-test-task
  script:
    - export TCMS_PRODUCT_VERSION=$(bundle exec fastlane run get_version_number target:Cubo | grep Result | grep -oE '[0-9]+\\.[0-9]+\\.?[0-9]*')
    - export TCMS_BUILD=$(bundle exec fastlane run get_build_number | grep Result | grep -oE '\\s[0-9]+' | grep -oE '[0-9]+')
    - cd automation; robot --listener cubo_tools.CuboKiwi ios_test_cases.robot

deploy:
  stage: deploy
  script:
    - bundle exec fastlane beta_deploy

我們是用 fastlane 來 build app，fastlane 設定如下:

default_platform(:ios)

platform :ios do
  def install_pods
    cocoapods(
      clean: true,
      podfile: "Podfile",
      try_repo_update_on_error: false
    )
  end

	desc "Build app, and archive in ./build.xcarchive path"
  lane :beta_build do
    install_pods()
    xcode_select("/Applications/Xcode.app")
    increment_build_number({
      build_number: latest_testflight_build_number + 1
    })
    build_app(workspace: "Cubo.xcworkspace", scheme: "Cubo", archive_path: "./build", output_directory: "./build")
  end

  desc "Push a new beta build to TestFlight"
  lane :beta_deploy do
    upload_to_testflight(
        skip_waiting_for_build_processing: true
    )
  end
end

所以可以在 test stage 可以透過 fastlane 取得 app 版本與 build number (build number 是每次會自動遞增)。不過 fastlane 的輸出比較 fancy 會用控制碼帶上顏色，所以在設定給環境變數時，控制碼會造成跟 Kiwi server 溝通上的問題，這問題苦惱了我很久，最後還是寫出這樣很奇怪的處理方式，如果你有更好的解法請務必跟我說：

bundle exec fastlane run get_version_number target:Cubo | grep Result | grep -oE '[0-9]+\\.[0-9]+\\.?[0-9]*'

在 RF 腳本中，你會想要安裝這個剛 build 出來的 app ，你可以指定 app 或者 ipa 的檔案位置，例如在我的 Fastlane 腳本中，我將 app 的 archive 儲存在 build.xcarchive 下，所以在 RF 腳本中 app 可以直接寫死該檔案的絕對路徑，當 RF 腳本執行時，就會安裝這個新 build 出來的版本。

另外這裡有個小 trick，我們的自動化測試腳本是放在另外一個 gitlab repo 中，所以在 iOS repo 裡透過 submodule 的方式，讓 gitlab CI 也自動將另外一個 repo 也 checkout 下來 (automation 目錄下)。

所以當程式碼 push 上 gitlab 時，啟動 gitlab pipeline 會自動完成三個 stage: build, test 以及 deploy

執行完畢後，檢查 Kiwi，一樣會有筆 Test run 被建立出來:

整個設定過程你大概會面臨到很多 try and error 的機會，要設定好也不容易，但盡量是簡化設定，避免環境變動影響到自動化測試的結果，如果自動化測試三天兩頭損壞，那麼久了沒修理就慢慢失去它的意義了。

App 測試自動化: RobotFramework + Appium (3) was originally published in Cubo AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

先看底下範例

*** Settings ***
Documentation       A test suite with app tests
Library             AppiumLibrary
Test Teardown       Close All Applications

*** Variables ***
${APPIUM_URL}                       <http://127.0.0.1:4723/wd/hub>
${IOS_AUTOMATION_NAME}              XCUITest
${PLATFORM_NAME}                    iOS
${PHOTOS_APP_NAME}                  com.apple.mobileslideshow
${PLATFORM_VERSION}                 14.6
${DEVICE_NAME}                      your_iphone_name
${UDID}                             your_iphone_device_identifier
${XCODE_ORG_ID}                     your_team_id

*** Test Cases ***
Test another app
    開啟 iOS app    ${PHOTOS_APP_NAME}
    略過app介紹說明
    Sleep   2s
    Click Element    xpath=//XCUIElementTypeImage[@name="照片, 6月11日, 下午2:31"]
    Run Keyword And Ignore Error     Click Button       Got It  # 這邊會彈出一個視窗也是只有第一次使用 App 才會有，
                                                                    # 所以如果是第二次以後使用，Click Button 失敗，所以我們就 Ignore 這個錯誤
    Sleep                       1s
    Swipe    346    441    83    449
    Sleep                       1s
    Swipe    181    256    188    536        
    Sleep                       3s

*** Keywords ***
開啟 iOS app
    [Arguments]     ${app_name}
    Open Application    ${APPIUM_URL}       iOSApp
    ...  automationName=${IOS_AUTOMATION_NAME}
    ...  platformName=${PLATFORM_NAME}
    ...  deviceName=${DEVICE_NAME}
    ...  platformVersion=${PLATFORM_VERSION}
    ...  udid=${UDID}
    ...  xcodeSigningId=iPhone Developer
    ...  xcodeOrgId=${XCODE_ORG_ID}
    ...  clearSystemFiles=true
    ...  app=${app_name}

略過app介紹說明
    # App 介紹頁只有第一次使用該 App 時才會出現
    # 而且這個不是 Test case 要關注的點
    # 所以這邊會使用 RUN Keyword 來執行 Click Button，
    # 如果 Click Continue Button 有成功，就會 Sleep 2 兩，等待動畫結束
    # 如果這頁沒出現，Click Continue Button 就會失敗，所以我們就不用做 Sleep，直接到下個步驟
    Sleep               2s
    ${status}   Run Keyword And Return Status     Click Button    Continue
    IF  ${status}
        Sleep           2s
    END

RF 腳本跟其他程式語言比較不一樣的是由 Keyword 所組成，你可以自訂 Keyword 去擴充他，所以也有別人會寫 Keyword 來擴充原有功能，像是 Appium 的支援就是透過 AppiumLibrary 來引入。

Keyword 的用法是

<Keyword>    <param1>...

像是上面範例中的 Library 或者 Test Teardown 或者 Click Element 都是 Keyword，Keyword 與參數之間至少要間隔一個空白以上，如果只有一個空白就會被視為同一個 Keyword。你也可以自訂義 Keyword，像是上述範例中的 開啟 iOS app 就是我自行定義的 Keyword，你可以把它視為一個可以被重複利用的函示。

至於到底有哪些 Keyword 可以用，可以參考底下幾個常用的文件

• 內建的 Keyword: https://robotframework.org/robotframework/latest/libraries/BuiltIn.html
• Operating System: https://robotframework.org/robotframework/latest/libraries/OperatingSystem.html
• Appium: https://serhatbolsu.github.io/robotframework-appiumlibrary/AppiumLibrary.html
• Selenium: https://robotframework.org/SeleniumLibrary/SeleniumLibrary.html

如果要使用 AppiumLibrary，要先做安裝

pip install --upgrade robotframework-appiumlibrary

執行 App 是透過 Open Application 這組 Keyword，在執行前需要先把 Appium server 跑起來 (透過 Appium Desktop 或者 appium 命令都可以)，這個 Keyword 的參數包含 appium server url，以及上一篇提到的 Capabilities。

上面這個範例就是執行 Photos app (com.apple.mobileslideshow) ，並進行一些操作。

你也可以透過一些其他 Keyword 如 Element Should Be Visible <name> 來驗證符合 <name> 名稱的元件應該有出現，來作為 Test case 的驗證項目。

只要腳本執行有錯，這個 test case 就會被視為失敗。

下一篇我會介紹一下如何整合到 CI 環境中，讓他真的自動化被執行。

App 測試自動化: RobotFramework + Appium (2) was originally published in Cubo AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

第一篇會先介紹，什麼是 Appium，以及如何安裝與設定，第二篇會介紹，如何透過 RobotFramework 編寫 Test cases，第三篇則會進一步談到如何串聯 CI 與 TCMS 系統。

對了，我不是 QA，所以對於專業的 QA 經驗，我真的沒辦法提供太多見解。

先從 Appium 談起好了

要做網頁自動化，大家應該都會先想到 Selenium，但是如果是 App 呢？ Appium 提供一個相當優秀的框架，他是一個 Client/Server 的框架，提供一套完整的 Protocol 讓你可以去操控 iOS/Android/Windows app，不管是模擬器或者實體機器都可以運作，功能十分強大。

RobotFramework 則是一套自動化腳本程式框架，可以透過 Library 的引用擴充功能，所以可以串接 Selenium，當然也可以介接 Appium。我覺得 RobotFramework 最棒的是他的語法，他是 Keyword based 的邏輯，你可以透過引入 Library 擴充更多 Keyword，也可以自訂 Keyword，Keyword 可以是任何語言，像是中文。透過 Keyword 的設計，可以讓你寫 Test cases 像是在寫自然語言文章一樣。RobotFramework + Appium 是完美的組合。

我們先從 Appium 來安裝好了。

Appium 是由 Node.js 寫成，所以你要先安裝 Node.js，而且版本要新，安裝很簡單:

npm install -g appium

另外要裝 Appium Desktop，而且是非常強烈建議要裝，很重要，會省超多時間。Appium Desktop 就上它的 github 下載安裝就好。

接下來，我們先從 iOS Simulator 開始玩起，但想要有 iOS Simulator，得先裝 Xcode。Xcode 在 Mac App Store 上就可以下載了，但你還必須要有開發者帳號。

接下來，先開啟 Appium Desktop，按下 Start Server，這個意思跟你直接在命令列執行 appium 是一樣的，就是跑 appium server。

Appium server 跑在 4723 Port 上。接下來按右上角的 Start Inspector Section 按鈕(放大鏡那個)。

並在 Desired Capabilities 中輸入：

• platformName: iOS
• automationName: XCUITest
• platformVersion: 14.5 (要看你 Simulator 的 iOS 版本而定)
• deviceName: iPhone 12 Pro (看你想跑在哪個 Simulator 上，你也可以用 iPhone simulator 這個名稱)
• app: com.apple.mobileslideshow (這個內建 Photos app 的 bundle ID，你也可以指定你自己 app 的 bundle ID，或者 app/ipa/apk 檔案路徑)

將這組 Capabilities Save As 成你想儲存的名稱，未來可以重複使用。然後按下 Start Session。

記住 Appium 只是一個 Client，你是先透過它把 Appium Server 執行起來，然後在連上 Server，並提供你一個好用的介面，將命令送給 Server，再由 Server 透過底層的 Driver 去控制模擬器跟 App。

在 Start Session 後，你就會看到 Simulator 被叫起來，Photos app 被打開。

簡單介紹一下 Inspector UI。左邊是 App 畫面截圖，你把滑鼠游標移過去，會發現有些元件會被 Highlight 顯示，效果就像瀏覽器的 Inspector 一樣，這是讓你可以很容易鎖定某個特定 UI 元件。中間的部分是 UI 的樹狀階層關係，如果你從左邊的截圖還是很難鎖定你要的元件的話，你也可以從樹狀階層一層一層下去找，總是會找到的。最右邊是你選定元件的內容。基本上 Inspector 可以查看每個 app ，即便是 iPhone 內建的 app 也是。

然後上面有一排按鈕

這排按鈕提供一些功能像是重新載入、搜尋 UI 元件、錄製動作等等，也可以模擬 Swipe 或者 Click Element At Coordinates 動作。

最右邊視窗是 Selected Element，在這裡你可以取得元件的一些相關資訊，尤其是 Locator，這很重要，讓你之後在測試項目時，才有辦法在你的腳本中去定位元件的位置。

如果只能在模擬器上跑不太過癮，那麼 Appium 也能在真的 iPhone 上執行嗎?

不過相比於模擬器，要在 iPhone 上執行會稍微比較複雜一點。

1. 你必須要有個開發者帳號，在 Xcode 中登入你的開發者帳號，並取得 Team ID。
2. 在 Xcode 的 Devices and Simulators 中登錄你的手機，允許作為開發用機子，並取得手機的 identifier。

1. 用 Xcode 開啟 /usr/local/lib/node_modules/appium/node_modules/appium-webdriveragent/WebDriverAgent.xcodeproj (如果你找不到的話，代表你尚未用 npm 安裝 appium。此外，如果你是使用 nvm 安裝 node.js 的話，appium 安裝路徑應該會是在 ~/.nvm/versions/node/v14.17.0/lib/node_modules/appium/node_modules/appium-webdriveragent/WebDriverAgent.xcodeproj/ )
2. WebDriverAgent 的 xcode 專案被開啟後，修改 target WebDriversAgentLib、 WebDriverAgentRunner 的 Signing & Capabilities 設定，將 Team 切換為你的開發者帳號。
3. 將 WebDriverAgentRunner build 到你的手機中。
4. Build 成功後，你手機桌面會多出個 WebDriverAgentRunner app，不要刪除這個 app，接下來我們同樣用 Appium Desktop 來測試一下。

與模擬器連線不同，Capabilities 的參數有些改變。

多了幾個:

• udid: 在這裡輸入你手機的 identifier
• xcodeOrgId: 輸入你的 team ID
• xcodeSigningId: 輸入 iPhone Developer
• deviceName: 輸入你 iPhone 手機名稱
• clearSystemFiles: 型態設為 boolean，並設為 true

手機記得解鎖，Start Session 後就會看到你的 app 被執行起來了。

App 測試自動化: RobotFramework + Appium (1) was originally published in Cubo AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ben 的新書「你的行為決定你是誰」也是差不多，都不太適合在 0–1 階段去讀，不過如果說，我能夠在早期就先知道，對於日後成長為 1–100 時會更有幫助。

我相信「文化」對於一間公司的重要程度，現在應該沒有人會反對吧。我以前在趨勢科技服務，趨勢科技就是一間極端重視企業文化的公司，不過離開接近十年後回頭看，我反而認為當年趨勢所設計的文化比較像是領導人想要員工遵從的價值，而非從上到下的推行。

企業文化就是當你不在時，公司如何做出各式各樣的決定，就是員工每天用來解決問題的那套無形概念，以及他們私底下的行為

Ben 這本書通篇就在講一個想法，那個想法就是書名本身: What you do is who you are — 你的行為決定你是誰。

我相信很多企業領導人在導入公司文化、某種價值時，都喜歡引用他們所推崇(或喜歡)的其他領導人(或公司)的文化跟價值，例如有些人喜歡賈伯斯，喜歡蘋果的產品，但不是某間公司都能夠像蘋果一樣，甚至更少人真的能像賈伯斯一樣出色; 有些人推崇 Simon Sinek，將同理心引入到企業價值當中，但結果往往是

有些部屬會把同理心的價值觀當作武器，反擊說：「你給我這種回饋！表示你缺乏同理心！」

我還真的聽過這樣的例子。

企業文化應該來自於領導人本身的特質、信念、所相信的價值，當你每天遇到困難的問題時，下決定所依據的原則，就會是你公司的文化。

要讓文化穩固，文化必須與領導人真正信想的價值一致，而不是與他自以為激勵人心的價值一致。因為，領導人主要是透過行動與他親自設下的範例朔造文化。

文化沒有好或不好的分別，只有適不適合自己公司的差異。一個領導人在朔造公司文化的時候，要先誠實檢視自己，了解自己。自己有什麼優缺點，都會成為公司的文化一環。領導人過度膨漲自己並不會為公司帶來什麼好的文化。

企業領導人也得面臨同樣的挑戰，但是他們往往自認為「好人」，常常忽略自己的缺點，這會導致文化上的危險後果。

我想，在找尋一個適合自己公司文化的過程中，這個做法可能不錯，給大家參考：

1. 列出自己特質、相信的信念、價值，想要改進什麼缺點
2. 跟其他共同創辦人一起列出來，最大公約數便有可能會是你企業的文化精髓
3. 言行一至

要設計成功的文化，第一步就是做自己，但是這可不容易。

做自己很重要

如果你嘗試要當另外一個人，不只會無法領導眾人，面對跟你看齊、想要迎頭趕上你的人，你還會感到相當羞愧。

如果你沒有做自己，就連你都不會追隨身為執行長的你。

人無法每天活在面具下，在壓力下，你的言行會反映你的思緒，如果你的文化不是代表你自己，其他人都看得出來，領導人要了解，既然做為領導人，站在光環下，其他人都在看著你，言行要一致，文化才能經得起檢視。

請記住，你的員工會用你的文化美德測試你，不管他們是有意還是無意的，所以，在你把美德放進企業文化前，先問自己：「我願意通過這項測試嗎？」

文化也必須是你所相信的價值，如此一來你才會重視它，並不斷地砥礪它，要求自己也要求別人做到。

如果你看到某些事情低於標準切毫無反應，那你已經設下了新的標準。

如果你看到某些不符合文化的事情卻選擇忽略，那麼你已經創造了新文化。

另外，外在環境會改變，企業文化也要隨時做出修正。

文化就像創造文化的組織一樣，必須隨時演進以因應新挑戰。

在任何一家有規模的公司中，總是會出現違反文化的案例。但是，重點不在於完美，而是在於比昨天更好。

策略會演進，環境會改變，你會學到新的事物，所以當這些狀況發生時，你就必須改變企業文化，不然會被舊規矩牢牢的箝制住。

信任是雙向的，信任建構於坦誠，不管對員工、對其他共同創辦人皆然。

信任來自於坦誠，如果員工無法相信你，公司就會分崩離析。這裡的技巧在於，要有技巧地說實話但不摧毀公司。

事實是什麼就是什麼，最重要的是，公司裡的每一個人都知道事實跟你所知道的事實如出一徹

如果是你的領導造成公司受挫，不得不裁員，那就承認吧。

Strip CEO 神童 Patrick Collison 曾說過： (這段話很好，不過我找不到原文)

『我們顯然無法提供終生聘僱的保障，但是我希望我們能夠做到的是，當人們在十五年後回頭看的時候，他們會認為在這公司做的是生涯中最有意義的工作。我期待員工做好兩件事作為交換條件：一、道德的一致性; 二、為公司而不是為自己追求卓越。如果他們能夠達成這兩項期待，我們會珍惜、尊重員工，並且對他們忠誠。』

最後

文化始於你決定什麼是最重要的事，然後你必須協助組織裡每一個人，讓他們實踐能夠反映這些重要價值的行為

你得注意自己的行為，你的行為對企業文化有什麼影響？你是你想要成為的那個人嗎？

另外，一般來說我不太看引言，但是中文譯本引言來自於 Dcard CEO，我覺得他寫得蠻好的

把一個問題往上丟，得到的回應就是文化

創業過程，每個階段都是新的學習

You must unlearn what you learnt. Periodically.

今年開始我看了兩個多月的 Prime Video，這邊推幾部我喜歡的美劇，並附上 IMDb 的分數以及我自己給他的評分

Terror 極地惡靈

目前有兩季，第一季根據傳奇小說 Dan Simmons 的 Terror 改編，而小說則根據真實故事改編。在 1845 年，英國派出兩艘船 Terror 跟 Erebus 前往北極探勘新航道，但是卻受困在北極冰層中，後來從此音訊全無，兩艘船總共有129名船員卻無人生還，並且直到 2014 年跟 2016 年時才被加拿大政府發現。這件事最後因為無人生還，所以這之間到底發生什麼事情，沒人知道，但是在處於絕望，冰封且糧食短缺的高度壓力下，人類到底會做出什麼樣的事情，就是整部片最高度張力之處。

IMDb 8 分
爛番茄: 87% (真的不能再高了)
我給的評分: 4 顆半

歷史是最吸引我的部分了，在看得過程我會不斷去翻這兩艘船的歷史，他們都曾經歷過戰爭與南北極的探險之旅，充滿色彩，最後的下場也充滿神秘感。

The Expanse 太空無垠

這部由 SyFy 高成本拍攝的影集之前曾在 Netflix 上過，但後來 SyFy 一度要取消第三季，但是影迷實在太喜歡了，紛紛發起拯救活動，後來是 Amazon 出手相救，才會有現在的 1 ~ 4 季，而且從 Netflix 下架。

這部是我最喜歡的 sci-fi 影集，比 Star Trek 好，我喜歡他的故事背景設計，故事時間發生在第 23 世紀，人類的足跡已經廣佈到太陽系幾個主要行星與小行星上，並且分裂成火星、小行星帶、與地球三個不同的陣營; 因為根據地不同，人類長時間在太空中生活，也造就一些生理上的差異，以及民族性認知上的不同。像是小行星帶上的居民，經常物質短缺，且生活在低重力環境，身體構造異於其他星球上的居民，無法適應重力生活，也比較憤世忌俗，經常打游擊四處劫掠。而火星上的居民生活也不易，好不容易在火星上建立殖民地，一心想要將火星改造成另外一個地球，所以科技發展最為先進，擁有高科技武器。而地球則仰仗著豐富的資源，舒適的生活環境，人口多，武力強盛，有著大地球思維。所以簡單看，這是太空版的三國演義，影集的發展也從一個尋人事件發展，跨過四季逐漸變成一個跨越宇宙的事件，相當好看。

IMDb: 8.5
爛番茄: 93%
我的評分: 5 顆星

另外 The Expanse 中也相當考究一些物理現象，很多特效不是亂演的，非常精確也不浮誇，是劇中值得注意的亮點。

Star Trek: Picard 畢凱艦長

Star Trek 的全盛時期就是在 The Next Generation 的畢凱艦長，後來還可以看的就只有 Voyager。如果要拯救這系列，最終還是要靠畢凱艦長自己了。

這部雖然沒有企業號，也沒有漂亮的星艦，Starfleet 也從內部開始腐爛，但是 Patrick Steward 回鍋演 Picard 就很值得看了，更何況回鍋的還有 7 of 9、Data 上尉、永遠的副艦長Rick。

不過 Picard 就像 Professor X 一樣，真的老了， 不再像以往意氣風發的站在鑑橋喊出 Engage。

另外 Star Trek: Picard 的劇情結構有些鬆散，常常跳來跳去的，如果對 Star Trek 過往不熟悉的人，可能看得會有些辛苦，像我大概都快忘光羅慕倫人到底之前是發生了什麼事情。另外有些角色沒有好好花揮也有些可惜，像是全像投影醫生，以前在 Voyager，Hologram Doctor 可說是佔盡風頭。

IMDb: 8
爛番茄: 90
我的評價: 4 顆星

Tom Clancy’s Jack Ryan

Jack Ryan 改編自湯姆可蘭西的小說，以前福伯拍過(愛國者遊戲)，後來是另外一位 Enterprise 艦長 Chris Pine 也拍過，這次是噤界的 John Krasinski。

Jack Ryan 的故事情節多半都差不多，主角一開始是中情局中的小小分析師，後來立大功變成間諜的故事。

目前有兩季，第一季講中東，第二季則是前陣子蠻紅的委內瑞拉。這部美劇劇情緊湊，不小心一沒注意兩季就看完了，我自己是給他蠻高的評價。非常適合用來打發無聊的時間。

IMDb: 8.1
爛番茄: 71%
我的評價: 4.5 顆星

一些我還沒看完的

High Castle

評價很高，但我沒那麼愛。講的是虛構的歷史，假設當年不是聯軍贏得二次大戰，而是德日兩國聯軍贏了二戰，並瓜分美國領土，到底會是怎麼樣的光景。

Treadstone

Tredstone 同樣是改編自很有名的電影 Jason Bourne 系列，講的是一種強化人類的神秘藥物被用在一些特務上，並被拿來執行一些暗殺任務。是 Jason Bourne 的影子在裡面，但是劇情也是有些跳來跳去，有時候就比較難繼續發落下去。

一些在待看名單中的

• The Purge
• Homecoming
• Taken

看來 Amazon Prime Video 很愛把一些熱門的電影再改拍為影集，我猜是怕出錯，票房保證搞砸機率比較低，這部份跟 Netflix 有很大的不同。所以在影集的多樣化上，比 Netflix 差。但是當 Netflix 鬧劇荒時，倒是偶爾可以轉到 Prmie Video 這來找一些好片來看。