Category: Uncategorized

1990年代，我初次接觸網路時，那是一個屬於開放網路（Open Web）的黃金時代。無論是BBS的轉信板、Usenet，還是當時親手「烘培」的網頁（homepage），所有內容都沒有一個集中的儲存點，而是分散在網路的各個角落。

這樣的好處是，每個網路參與者都真正「擁有」自己的內容；但相對地，參與者需要具備一定的技術門檻才能儲存或創造內容。也因為內容是如此分散，「搜尋引擎」這項產品應運而生，讓使用者能更輕易地找到所需的資訊。Google也因此在這個開放網路時代，成為了無可爭議的霸主，直到AI時代的來臨。

事實上，Google搜尋的商業模式與開放網路緊密相連。在2000到2010年間，Google推出許多功能與產品，如AdSense、Google Reader、PubSub等，無不希望擴大開放網路的影響力。

封閉花園的崛起、開放和封閉的戰爭

然而，開放網路的局面從2000年代開始有了巨大轉變。隨著社群網路的興起，以及iPhone的橫空出世，「封閉花園（Walled Garden）」模式開始大行其道。這種模式讓服務提供者能更好地控制內容品質，對消費者而言，獲取內容也更加便利。因此，封閉花園模式不斷擴張，Facebook（Meta）和後來的TikTok便是其中的佼佼者。

以網路內容消費的生態系統來看，主要有四個角色：內容生產者、內容消費者、內容分發者和廣告商。由於一般內容消費者不會直接付費，大多數內容都是透過廣告模式來獎勵內容生產者，以維持優質內容的產出。不論是單純的展示廣告、導購連結，甚至是業配，本質上都是讓消費者認識廣告商產品的過程。封閉花園模式大大降低了生產者的製作成本（例如：不需懂架設網站），也降低了消費者的獲取成本（例如：打開App就有大量內容），因此深受生態系參與者的青睞。

AI浪潮下的內容生態巨變

如果沒有AI，或許開放網路還能抵抗這股潮流一陣子。尤其當區塊鏈（Blockchain）興起時，開放網路陣營不斷嘗試，是否能透過區塊鏈這個新技術，讓內容提供者在獲利時不必再被內容分發者抽成。但AI的出現徹底改變了這一切。當消費者可以直接提問，且AI能不厭其煩地給予答案時，誰還會想費力搜尋呢？人性本就懶惰，沒人會想點擊AI回覆下的腳註連回原始內容，那些依附在內容上的聯播網廣告，自然也無人問津，收入也將隨之消逝。

雖然內容依然是王道，但未來的優質內容，很可能將演變成各家AI服務商「付費」取得的局面，變成各家服務商的封閉花園。不再是1990年代那種內容創作者即是內容擁有者的時代了。

僅以此文，致那逝去的美好年代。
（本文在開放網路下的 Blog Software 寫作）

工作到現在，覺得還是需要把自己的管理觀點寫下來，但又覺得不太適合寫在這個 Blog 內（還是想把這個 Blog 維持比較技術、新產品類的分享）。所以另外開了一個 Substack 的平台：《技術管理觀點》電子報。

目前固定週一會推出一篇技術管理的文章，包含軟體工程師的面試、報到、培育、績效評估、晉升等。也有不定期出刊的閒聊文章，例如談技術債。

如果對管理有興趣，想與我討論的話，可以在平台內留言，或是到 Facebook 粉絲團：技術管理觀點 私訊唷！

QBQ：問題背後的問題
人月神話
目標
Clean Code
遊戲化實戰全書
鳳凰專案
商業思維 BUSINESS THINKING
薩提爾的對話練習
執行力的修煉
教出好幫手：想當好主管，先學會教人
奮鬥吧！系統工程師

實體的卡片照片，在台灣難得可以拿到的金屬卡

這是一張蠻特別的卡片，由加密貨幣交易所新創 crypto.com 發行。需要抵押 50 MCO（約新台幣 8,000）元六個月，即可取得一張「金屬」的 debit card。六個月後，可以把這 8,000 取回，可以直接刷卡花掉，或是透過 ATM 提領出來（國泰世華ATM不收手續費）。

我在 4 月申請的，因為疫情的關係，卡片五月中才到；但最近改用 DHL 寄送之後，通常兩三天就會到了。

到六月底為止，在家樂福（需用 line pay）、UberEats 消費，皆回饋 10%

你可以透過信用卡儲值（手續費1%）到卡片內，再透過卡片消費，或是將比特幣、以太幣換成法幣後再消費也可以。

如果透過我的連結申請 https://platinum.crypto.com/r/gbb3ut2h5g，當抵押完成後，我們雙方都可以獲得等值美金 50 元的 MCO 幣。你可以直接換成法幣然後在家樂福消費。

pt-stalk 是 Percona Toolkit for MySQL 裡面的其中一項工具。它會連到 MySQL Server，監控指定的數值，當超過指定的 Threshold 時，收集當時資料庫執行的資訊（包含正在進行的 transaction、vmstat、lsof，甚至 gdb stack trace），方便分析解決問題。

pt-stalk 需要以 root 權限執行。執行的方法如下：

pt-stalk --daemonize --variable Threads_connected --threshold 400 -- --defaults-file=/etc/mysql/my.cnf

當同時有 400 以上的 Threads 時，便會收集資料，存到 /var/lib/pt-stalk 內。收集的資料範例：

2014_01_13_00_25_09-df              2014_01_13_00_25_09-lock-waits      2014_01_13_00_25_09-netstat         2014_01_13_00_25_09-ps
2014_01_13_00_25_09-disk-space      2014_01_13_00_25_09-log_error       2014_01_13_00_25_09-netstat_s       2014_01_13_00_25_09-slabinfo
2014_01_13_00_25_09-diskstats       2014_01_13_00_25_09-lsof            2014_01_13_00_25_09-opentables1     2014_01_13_00_25_09-sysctl
2014_01_13_00_25_09-hostname        2014_01_13_00_25_09-meminfo         2014_01_13_00_25_09-opentables2     2014_01_13_00_25_09-top
2014_01_13_00_25_09-innodbstatus1   2014_01_13_00_25_09-mpstat          2014_01_13_00_25_09-output          2014_01_13_00_25_09-transactions
2014_01_13_00_25_09-innodbstatus2   2014_01_13_00_25_09-mpstat-overall  2014_01_13_00_25_09-pmap            2014_01_13_00_25_09-trigger
2014_01_13_00_25_09-interrupts      2014_01_13_00_25_09-mutex-status1   2014_01_13_00_25_09-processlist     2014_01_13_00_25_09-variables
2014_01_13_00_25_09-iostat          2014_01_13_00_25_09-mutex-status2   2014_01_13_00_25_09-procstat        2014_01_13_00_25_09-vmstat
2014_01_13_00_25_09-iostat-overall  2014_01_13_00_25_09-mysqladmin      2014_01_13_00_25_09-procvmstat      2014_01_13_00_25_09-vmstat-overall

然後看 InnoDB status，可以看到很多 transaction 正在等 query cache lock：

MySQL thread id 688253701, OS thread handle 0x7f6a591c9700, query id
19004545452 10.1.1.94 pixblog Waiting for query cache lock
SELECT * FROM `blogarticle` WHERE (`blogarticle_blogid` = 3835626) AND
(`blogarticle_date` < 1388605724) AND (`blogarticle_status` IN (2,3,5,7))
ORDER BY `blogarticle_date` desc, `blogarticle_id` desc LIMIT 1
---TRANSACTION 144B7B32FC, not started
MySQL thread id 688253702, OS thread handle 0x7f6a787bc700, query id
19004544621 10.1.1.191 pixblog Waiting for query cache lock
SELECT * FROM `blog` WHERE `blog_id` = 3126963
---TRANSACTION 144B7B32FD, not started
MySQL thread id 688253706, OS thread handle 0x7f6a887e2700, query id
19004544620 10.1.1.166 pixblog Waiting for query cache lock
SELECT * FROM `bloglayout` WHERE `bloglayout_id` = 3063007
---TRANSACTION 144B7B33C7, not started starting index read
mysql tables in use 1, locked 0


發生問題的當時確實有一個跑統計報表的 Slow Query 正在執行，於是要求該 Query 不使用 Query Cache¹ 來解決問題。

連結：AWS 推出 AutoScaling 管理介面

使用 IaaS 這類的服務，最方便的地方就是：當有緊急需求需要增加伺服器的時候，可以直接在網頁上點一點就完成增加的動作。但是，如果收到簡訊告警的時候，剛好在沒有網路的地方，就只好遠端電話遙控同事到網頁上操作，總覺得不是那麼方便。AWS 提供的 AutoScaling 服務，可以預先設定一些條件（例如 CPU 使用率超過多少，或是 Elastic Load Balance 的 Requests/sec 數量超過多少），當滿足這些條件時，自動增加（或減少）伺服器。原本這個功能只能透過 API 設定，今天終於有網頁版了…

使用 AutoScaling 網頁介面，除了可以開一般的 Instance 以外，還可以開 Spot Instance。對於需要大量運算資源，但是即時性要求不那麼高的服務來說，可以省下不少費用。

之前曾經提過 HandlerSocket – A NoSQL Plugin for MySQL，可以透過類似 NoSQL 的方式存取 InnoDB，效能會比普通 SQL 更好。後來 Oracle 在 MySQL 5.5 推出的時候，直接使用 Memcached Protocol，理論上應該是更方便（因為 Memcached Adapter 到處都有…）。

於是最近仔細的研究了一下，發現要使用 MySQL 5.5 的 InnoDB Memcached Plugin，要注意以下的地方：

1. 如果要使用自行指定的 Table，需要參考 Internals of the InnoDB memcached Plugin，在 innodb_memcache.containers 設定 key 與 column 的對應表。
2. 預設是使用 containers Table 裡面 name 為 default 的 Table。
3. 如果要指定 Table，要在 GET 或 SET 指令前，下 GET @@name 或 SET @@name 將之後的 Request 都切換到 name 這個 Table。
4. 如果需要 Replication，記得要設定 innodb_api_enable_binlog 這個值。

大概重點就這些了，如果還有玩到別的再來補充。

根據 Mixpanel 的統計資訊，在 iOS 7 開放下載三天後，市佔率已經超過 iOS 6 了。

先貼張圖：

我現在服務的公司 PIXNET 要徵求一名 System Administrator：

工作內容：

• 伺服器 (主要為 FreeBSD 與 Debian、Ubuntu 系統) 系統維護，包括套件 (ports 與 apt/deb) 維護
• 機房與辦公室網路設備 (Cisco/Juniper Router、Switch、VPN) 維護。

工作時間：9:30 ~ 18:30 (一～五)，特殊狀況時 (例如晚上處理緊急事件，或是凌晨停機等) 另外補休。
就職日：可馬上就職，或 2012 年二月到職即可。
地點：台北市中山區 (捷運行天宮站旁)，機房於台北市內湖區。
需求：熟悉 UNIX-like 系統，Script (Perl, Python 或 shell script 之一) 撰寫。熟 Cisco 網路設備操作者佳。
薪資：約 40k/month，其他技能面議另談。

有意者請聯絡 techjob@pixnet.tw。