如何防禦 CSRF (Cross Site Request Forgery) 跨站請求偽造


client side 的 Double Submit Cookie

https://blog.techbridge.cc/2017/02/25/csrf-introduction/

https://security.stackexchange.com/questions/59470/double-submit-cookies-vulnerabilities


反思:
本文作者文末針對 SPA 的需求,提出由 client side 來生成 csrf token,
這部分恐怕是有疑慮的,因為由 client side 來生成 csrf token, cookie 的 HttpOnly 參數就只能設定為 false... 那麼,駭客就能拿到這個 csrf token 了 ?


以下為存檔備份,以防資料來源網站撤除資料,平時到出處網站閱讀在視覺體驗方面會比較舒適:

前言

最近剛好碰到一些 CSRF 的案例,趁著這次機會好好研究了一下。深入研究之後才發現這個攻擊其實滿可怕的,因為很容易忽略它。但幸好現在有些 Framework 都有內建防禦 CSRF 的功能,可以很簡單的開啟。
但儘管如此,我認為還是有必要瞭解一下 CSRF 到底在幹嘛,是透過怎樣的手段攻擊,以及該如何防禦。就讓我們先來簡單的介紹一下它吧!
CSRF 是一種 Web 上的攻擊手法,全稱是 Cross Site Request Forgery,跨站請求偽造。不要跟 XSS 搞混了,他們兩種是不同的東西,那到底什麼是 CSRF 呢?先從我自身的一個案例談起好了。

偷懶的刪除功能

以前我有做個一個簡單的後台頁面,就想成是一個部落格吧!可以發表、刪除以及編輯文章,介面大概長得像這樣:
delete
可以看到刪除的那個按鈕,點下去之後就可以把一篇文章刪掉。當初因為偷懶,想說如果我把這個功能做成 GET,我就可以直接用一個連結完成刪除這件事,在前端幾乎不用寫到任何程式碼:





1
<a href='/delete?id=3'>刪除</a>

很方便對吧?然後我在網頁後端那邊做一下驗證,驗證 request 有沒有帶 session id 上來,也驗證這篇文章是不是這個 id 的作者寫的,都符合的話才刪除文章。
嗯,聽起來該做的都做了啊,我都已經做到:「只有作者本人可以刪除自己的文章」了,應該很安全了,難道還有哪裡漏掉了嗎?
沒錯,的確是「只有作者本人可以刪除自己的文章」,但如果他不是自己「主動刪除」,而是在不知情的情況下刪除呢?你可能會覺得我在講什麼東西,怎麼會有這種事情發生,不是作者主動刪的還能怎麼刪?
好,我就來讓你看看還能怎麼刪!
今天假設小黑是一個邪惡的壞蛋,想要讓小明在不知情的情況下就把自己的文章刪掉,該怎麼做呢?
他知道小明很喜歡心理測驗,於是就做了一個心理測驗網站,並且發給小明。但這個心理測驗網站跟其他網站不同的點在於,「開始測驗」的按鈕長得像這樣:





1
<a href='https://small-min.blog.com/delete?id=3'>開始測驗</a>

小明收到網頁之後很開心,就點擊「開始測驗」。點擊之後瀏覽器就會發送一個 GET 請求給https://small-min.blog.com/delete?id=3,並且因為瀏覽器的運行機制,一併把 small-min.blog.com 的 cookie 都一起帶上去。
Server 端收到之後檢查了一下 session,發現是小明,而且這篇文章也真的是小明發的,於是就把這篇文章給刪除了。
這就是 CSRF,你現在明明在心理測驗網站,假設是 https://test.com 好了,但是卻在不知情的狀況下刪除了 https://small-min.blog.com 的文章,你說這可不可怕?超可怕!
這也是為什麼 CSRF 又稱作 one-click attack 的緣故,你只要點一下就中招了。
你可能會說:「可是這樣小明不就知道了嗎,不就連過去部落格了?不符合『不知情的狀況』啊!」
好,那如果我們改成這樣呢:





1
2
<img src='https://small-min.blog.com/delete?id=3' width='0' height='0' />
<a href='/test'>開始測驗</a>

在開啟頁面的同時,一樣發送一個刪除的 request 出去,但這次小明是真的完全不知道這件事情。這樣就符合了吧!
CSRF 就是在不同的 domain 底下卻能夠偽造出「使用者本人發出的 request」。要達成這件事也很簡單,因為瀏覽器的機制,你只要發送 request 給某個網域,就會把關聯的 cookie 一起帶上去。如果使用者是登入狀態,那這個 request 就理所當然包含了他的資訊(例如說 session id),這 request 看起來就像是使用者本人發出的。

那我把刪除改成 POST 不就好了嗎?

沒錯,聰明!我們不要那麼懶,好好把刪除的功能做成 POST,這樣不就無法透過 <a> 或是 <img> 來攻擊了嗎?除非有哪個 HTML 元素可以發送 POST request!
有,正好有一個,就叫做 form。





1
2
3
4
<form action="https://small-min.blog.com/delete" method="POST">
<input type="hidden" name="id" value="3"/>
<input type="submit" value="開始測驗"/>
</form>

小明點下去以後,照樣中招,一樣刪除了文章。你可能又會疑惑說,但是這樣小明不就知道了嗎?我跟你一樣很疑惑,於是我 Google 到了這篇:Example of silently submitting a POST FORM (CSRF)
這篇提供的範例如下,網頁的世界真是博大精深:





1
2
3
4
5
6
<iframe style="display:none" name="csrf-frame"></iframe>
<form method='POST' action='https://small-min.blog.com/delete' target="csrf-frame" id="csrf-form">
<input type='hidden' name='id' value='3'>
<input type='submit' value='submit'>
</form>
<script>document.getElementById("csrf-form").submit()</script>

開一個看不見的 iframe,讓 form submit 之後的結果出現在 iframe 裡面,而且這個 form 還可以自動 submit,完全不需要經過小明的任何操作。
到了這步,你就知道改成 POST 是沒用的。

那我後端改成只接收 json 呢?

聰明的你靈機一動:「既然在前端只有 form 可以送出 POST 的話,那我的 api 改成用 json 收資料不就可以了嗎?這樣總不能用 form 了吧!」
spring 的 document告訴你:這還是沒用的!





1
2
3
4
5
<form action="https://small-min.blog.com/delete" method="post" enctype="text/plain">
<input name='{"id":3, "ignore_me":"' value='test"}' type='hidden'>
<input type="submit"
value="delete!"/>
</form>

這樣子會產生如下的 request body:





1
2
3
{ "id": 3,
"ignore_me": "=test"
}

但這邊值得注意的一點是,form能夠帶的 content type 只有三種:application/x-www-form-urlencoded, multipart/form-data 跟 text/plain。在上面的攻擊中我們用的是最後一種,text/plain,如果你在你的後端 Server 有檢查這個 content type 的話,是可以避免掉上面這個攻擊的。
只是,上面這幾個攻擊我們都還沒講到一種情況:如果你的 api 接受 cross origin 的 request 呢?
意思就是,如果你的 api 的 Access-Control-Allow-Origin 設成 * 的話,代表任何 domain 都可以發送 ajax 到你的 api server,這樣無論你是改成 json,或甚至把 method 改成 PUT, DELETE 都沒有用。
我們舉的例子是刪除文章,這你可能覺得沒什麼,那如果是銀行轉帳呢?攻擊者只要在自己的網頁上寫下轉帳給自己帳號的 code,再把這個網頁散佈出去就好,就可以收到一大堆錢。
講了這麼多,來講該怎麼防禦吧!先從最簡單的「使用者」開始講。

使用者的防禦

CSRF 攻擊之所以能成立,是因為使用者在被攻擊的網頁是處於已經登入的狀態,所以才能做出一些行為。雖然說這些攻擊應該由網頁那邊負責處理,但如果你真的很怕,怕網頁會處理不好的話,你可以在每次使用完網站就登出,就可以避免掉 CSRF。
或者呢,關閉執行 js 或把上面這些 pattern 的程式碼過濾掉不要執行,也是一個方法(但應該很難判定哪些是 CSRF 攻擊的程式碼)。
所以使用者能做的其實有限,真的該做事的是 Server 那邊!

Server 的防禦

CSRF 之所以可怕是因為 CS 兩個字:Cross Site,你可以在任何一個網址底下發動攻擊。CSRF 的防禦就可以從這個方向思考,簡單來說就是:「我要怎麼擋掉從別的 domain 來的 request」
你仔細想想,CSRF 的 reuqest 跟使用者本人發出的 request 有什麼區別?區別在於 domain 的不同,前者是從任意一個 domain 發出的,後者是從同一個 domain 發出的(這邊假設你的 api 跟你的前端網站在同一個 domain)

檢查 Referer

request 的 header 裡面會帶一個欄位叫做 referer,代表這個 request 是從哪個地方過來的,可以檢查這個欄位看是不是合法的 domain,不是的話直接 reject 掉即可。
但這個方法要注意的地方有三個,第一個是有些瀏覽器可能不會帶 referer,第二個是有些使用者可能會關閉自動帶 referer 的這個功能,這時候你的 server 就會 reject 掉由真的使用者發出的 request。
第三個是你判定是不是合法 domain 的程式碼必須要保證沒有 bug,例如:





1
2
3
4
const referer = request.headers.referer;
if (referer.indexOf('small-min.blog.com') > -1) {
// pass
}

你看出上面這段的問題了嗎?如果攻擊者的網頁是small-min.blog.com.attack.com的話,你的檢查就破功了。
所以,檢查 referer 並不是一個很完善的解法

加上圖形驗證碼、簡訊驗證碼等等

就跟網路銀行轉帳的時候一樣,都會要你收簡訊驗證碼,多了這一道檢查就可以確保不會被 CSRF 攻擊。
圖形驗證碼也是,攻擊者並不知道圖形驗證碼的答案是什麼,所以就不可能攻擊了。
這是一個很完善的解決方法,但如果使用者每次刪除 blog 都要打一次圖形驗證碼,他們應該會煩死吧!

加上 CSRF token

要防止 CSRF 攻擊,我們其實只要確保有些資訊「只有使用者知道」即可。那該怎麼做呢?
我們在 form 裡面加上一個 hidden 的欄位,叫做csrftoken,這裡面填的值由 server 隨機產生,並且存在 server 的 session 中。





1
2
3
4
5
<form action="https://small-min.blog.com/delete" method="POST">
<input type="hidden" name="id" value="3"/>
<input type="hidden" name="csrftoken" value="fj1iro2jro12ijoi1"/>
<input type="submit" value="刪除文章"/>
</form>

按下 submit 之後,server 比對表單中的csrftoken與自己 session 裡面存的是不是一樣的,是的話就代表這的確是由使用者本人發出的 request。這個 csrftoken 由 server 產生,並且每一段不同的 session 就應該要更換一次。
那這個為什麼可以防禦呢?因為攻擊者並不知道 csrftoken 的值是什麼,也猜不出來,所以自然就無法進行攻擊了。
可是有另外一種狀況,假設你的 server 支持 cross origin 的 request,會發生什麼事呢?攻擊者就可以在他的頁面發起一個 request,順利拿到這個 csrf token 並且進行攻擊。不過前提是你的 server 接受這個 domain 的 request。
接著讓我們來看看另外一種解法
上一種解法需要 server 的 state,亦即 csrf token 必須被保存在 server 當中,才能驗證正確性。而現在這個解法的好處就是完全不需要 server 儲存東西。
這個解法的前半段與剛剛的相似,由 server 產生一組隨機的 token 並且加在 form 上面。但不同的點在於,除了不用把這個值寫在 session 以外,同時也讓 client side 設定一個名叫 csrftoken 的 cookie,值也是同一組 token。





1
2
3
4
5
6
7
Set-Cookie: csrftoken=fj1iro2jro12ijoi1
<form action="https://small-min.blog.com/delete" method="POST">
<input type="hidden" name="id" value="3"/>
<input type="hidden" name="csrftoken" value="fj1iro2jro12ijoi1"/>
<input type="submit" value="刪除文章"/>
</form>

你可以仔細思考一下 CSRF 攻擊的 request 與使用者本人發出的 request 有什麼不一樣?不一樣的點就在於,前者來自不同的 domain,後者來自相同的 domain。所以我們只要有辦法區分出這個 request 是不是從同樣的 domain 來,我們就勝利了。
而 Double Submit Cookie 這個解法正是從這個想法出發。
當使用者按下 submit 的時候,server 比對 cookie 內的 csrftoken 與 form 裡面的 csrftoken,檢查是否有值並且相等,就知道是不是使用者發的了。
為什麼呢?假設現在攻擊者想要攻擊,他可以隨便在 form 裡面寫一個 csrf token,這當然沒問題,可是因為瀏覽器的限制,他並不能在他的 domain 設定 small-min.blog.com 的 cookie 啊!所以他發上來的 request 的 cookie 裡面就沒有 csrftoken,就會被擋下來。
當然,這個方法看似好用,但也是有缺點的,可以參考:Double Submit Cookies vulnerabilities,攻擊者如果掌握了你底下任何一個 subdomain,就可以幫你來寫 cookie,並且順利攻擊了。
會特別提到 client side,是因為我之前所碰到的專案是 Single Page Application,上網搜尋一下就會發現有人在問:「SPA 該如何拿到 CSRF token?」,難道要 server 再提供一個 api 嗎?這樣好像有點怪怪的。
但是呢,我認為我們可以利用 Double Submit Cookie 的精神來解決這個問題。而解決這問題的關鍵就在於:由 client side 來生 csrf token。就不用跟 server api 有任何的互動。
其他的流程都跟之前一樣,生成之後放到 form 裡面以及寫到 cookie。或者說如果你是 SPA 的話,也可以把這資訊直接放到 request header,你就不用在每一個表單都做這件事情,只要統一加一個地方就好。
事實上,我自己常用的 library axios 就有提供這樣的功能,你可以設置 header 名稱跟 cookie 名稱,設定好以後你每一個 request,它都會自動幫你把 header 填上 cookie 裡面的值。





1
2
3
4
5
// `xsrfCookieName` is the name of the cookie to use as a value for xsrf token
xsrfCookieName: 'XSRF-TOKEN', // default
// `xsrfHeaderName` is the name of the http header that carries the xsrf token value
xsrfHeaderName: 'X-XSRF-TOKEN', // default

那為什麼由 client 來生這個 token 也可以呢?因為這個 token 本身的目的其實不包含任何資訊,只是為了「不讓攻擊者」猜出而已,所以由 client 還是由 server 來生成都是一樣的,只要確保不被猜出來即可。Double Submit Cookie 靠的核心概念是:「攻擊者的沒辦法讀寫目標網站的 cookie,所以 request 的 csrf token 會跟 cookie 內的不一樣」

browser 本身的防禦

我們剛剛提到了使用者自己可以做的事、網頁前後端可以做的事情,那瀏覽器呢?之所以能成立 CSRF,是因為瀏覽器的機制所導致的,有沒有可能從瀏覽器方面下手,來解決這個問題呢?
有!而且已經有了。而且啟用的方法非常非常簡單。
Google 在 Chrome 51 版的時候正式加入了這個功能:SameSite cookie,對詳細運行原理有興趣的可參考:draft-west-first-party-cookies-07。
先引一下 Google 的說明:
Same-site cookies (ne “First-Party-Only” (ne “First-Party”)) allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain.
啟用這個功能有多簡單?超級無敵簡單。
你原本設置 Cookie 的 header 長這樣:





1
Set-Cookie: session_id=ewfewjf23o1;

你只要在後面多加一個 SameSite 就好:





1
Set-Cookie: session_id=ewfewjf23o1; SameSite

但其實 SameSite 有兩種模式,Lax跟Strict,默認是後者,你也可以自己指定模式:





1
2
Set-Cookie: session_id=ewfewjf23o1; SameSite=Strict
Set-Cookie: foo=bar; SameSite=Lax

我們先來談談默認的 Strict模式,當你加上 SameSite 這個關鍵字之後,就代表說「我這個 cookie 只允許 same site 使用,不應該在任何的 cross site request 被加上去」。
意思就是你加上去之後,我們上面所講的<a href="">, <form>, new XMLHttpRequest,只要是瀏覽器驗證不是在同一個 site 底下發出的 request,全部都不會帶上這個 cookie。
可是這樣其實會有個問題,連<a href="..."都不會帶上 cookie 的話,當我從 Google 搜尋結果或者是朋友貼給我的連結點進某個網站的時候,因為不會帶 cookie 的關係,所以那個網站就會變成是登出狀態。這樣子的使用者體驗非常不好。
有兩種解法,第一種是跟 Amazon 一樣,準備兩組不同的 cookie,第一組是讓你維持登入狀態,第二組則是做一些敏感操作的時候會需要用到的(例如說購買、設定帳戶等等)。第一組不設定 SameSite,所以無論你從哪邊來,都會是登入狀態。但攻擊者就算有第一組 cookie 也不能幹嘛,因為不能做任何操作。第二組因為設定了 SameSite 的緣故,所以完全避免掉 CSRF。
但這樣子還是有點小麻煩,所以你可以考慮第二種,就是調整為 SameSite 的另一種模式:Lax。
Lax 模式放寬了一些限制,例如說<a>, <link rel="prerender">, <form method="GET"> 這些都還是會帶上 cookie。但是 POST 方法 的 form,或是只要是 POST, PUT, DELETE 這些方法,就不會帶上 cookie。
所以一方面你可以保有彈性,讓使用者從其他網站連進你的網站時還能夠維持登入狀態,一方面也可以防止掉 CSRF 攻擊。但 Lax 模式之下就沒辦法擋掉 GET 形式的 CSRF,這點要特別注意一下。
講到這種比較新的東西,相信大家一定都很想知道瀏覽器的支援度如何,caniuse告訴我們說:目前只有 Chrome 支援這個新的特性(畢竟是 Google 自己推的方案,自己當然要支持一下)。
雖然瀏覽器的支援度不太高,但日後其他瀏覽器可能也會跟進實做這個方案,不妨在現在就把 SameSite 加上去,以後就不用再為 CSRF 煩惱了。
我其實只是大略的介紹一下,draft-west-first-party-cookies-07 裡面講到很多細節,例如說到底怎樣算是 cross site? 一定要在同一個 domain 嗎?那 sub domain 行不行?
好奇的可以自己研究一下,或者是這篇:SameSite Cookie,防止 CSRF 攻击也有提到。
SameSite 相關的參考資料:
  1. Preventing CSRF with the same-site cookie attribute
  2. 再见,CSRF:讲解set-cookie中的SameSite属性
  3. SameSite Cookie,防止 CSRF 攻击
  4. SameSite——防御 CSRF & XSSI 新机制
  5. Cross-Site Request Forgery is dead!

總結

這篇主要介紹了 CSRF 的攻擊原理以及兩種防禦方法,針對比較常見的場景做介紹。一般在做網頁開發的時候,比起 XSS,CSRF 是一個比較常被忽略的重點。在網頁上有任何比較重要的操作時,都要特別留意是否有被 CSRF 的風險。
這次找了很多參考資料,但發現跟 CSRF 有關的文章其實都大同小異,想知道更細節的地方需要花很多的心力去找,但幸好 Stackoverflow 上面也有不少資料可以參考。因為我在資訊安全這塊沒有涉獵太多,如果文章有哪部分講錯的話,還麻煩各位在留言不吝指出。
也感謝我朋友 shik 的指點,告訴我有 SameSite 這麼一個東西,讓我補上最後一段。
希望這篇文章能讓大家對 CSRF 有更全面的認識。

參考資料

  1. Cross-Site Request Forgery (CSRF)
  2. Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
  3. 一次较为深刻的CSRF认识
  4. [技術分享] Cross-site Request Forgery (Part 2)
  5. Spring Security Reference
  6. CSRF 攻击的应对之道

Web API

2020年,預計全球有30萬個API生成;《財富》雜誌的100大公司,也都將要開放API;API驅動的行動應用,市場規模至2015年將增長到250億美元。大數據與雲端時代,API已成為串聯新應用的關鍵,將舊有服務加值,把商業模式更新,大企業、新創者,你不能不認識它。

何謂 Omni-Channel Retail 全通路零售 (全渠道零售):https://21st.each1.net/2018/07/omni-channel-retail.html


已經進入SaaS / PaaS / IaaS 時代已久,還在用舊時代想法規劃網站嗎?

「 以Google為例,透過 GoogleMapAPI,第三方開發者可以輕易的使用 Google Map 所提供的套件,串接Google的地圖資料,並鑲嵌在自己的網路。Twitter 利用 WebAPI 分享他們龐大會員的資訊。Amazon 則提供了一個代管主機的應用介面;微軟更是把傳統的Office變成了雲端服務的Office365 」

從上述案例來看,以雲端服務為導向的商業模式,正在這幾年蓬勃發展。但並非是透過網路就是所謂的雲端服務,從雲端機房到WebAPI,其中的學問可是大不相同,雲端服務的類型如下:


傳統方式:

過去的網路公司,主要都是以傳統方式建置產品和服務,不管是從Server硬體、網路、作業系統、機房等等,都由公司一手包辦。而為因應產品的類型,是否用多少頻寬的網路、作業系統、是否使用虛擬主機VM等...都會影響到產品的效能,這樣的建置方式不僅需要對每個技術環節,都有相當程度的了解和考究,投入的時間和人力成本也更是一大考量。

IaaS(Infrastructure as a Service),基礎建設即服務 :

將網路建置及server硬體採買、是否虛擬化過程交給廠商管理,而公司本身只要針對硬體設施以外的項目如作業系統、硬體上所需執行的服務及應用程式即可,或是我們可以解釋成僅和外部廠商租賃雲端機房、伺服器、網路環境等等,而不用像過去需要在公司內部自行建置機房,而大部分提供雲端機房的環境亦提供恆溫、24小時監控外、機房本身又具備高規格的防震等級,可以有效負擔掉企業內部機房的維運成本。

PaaS(Platform as a Service), 平台即服務:

除IaaS的項目之外,更把作業系統、開發程式環境都交給廠商管理,這樣公司只要專注在資料處理及服務(應用程式)的開發項目,就像Microsoft Azure所提供的Paas服務,像IaaS一樣提供包括基礎架構服務器,存儲和網路,而且還包括開發環境、開發工具,商業智能(BI)服務,數據庫管理系統等。以微軟Azure而言,PaaS旨在支援完整的Web應用程序生命週期:構建,測試,部署,管理和更新,並於Paas項目上提供更完善的維護及管理。


SaaS(Software as a Service),軟體即服務:

透過提供已經產品化的軟體服務是近年來營利的一大趨勢,使用者不再需要負擔自己的開發成本,只需要向廠商訂購該服務,就可以替企業省下大筆的資金。舉Google為例,它提供免費的電子郵件、日曆等服務給大眾使用外,還針對企業推出服務層級協定(SLA)較高的付費網路郵件服務,企業不需要另外採購應用電子郵件的軟體和硬體設備,只要訂購Google的Gmail服務,就能取代自建的電子郵件系統。

像Google Analysis & Adobe Sitecatalyst,也屬於SaaS的一種,提供以監控平台作為服務,透過Web方式登入並提供資料挖掘和商業數據分析。像是社群網站Facebook也可以算是SaaS的一種囉! (常見的SaaS例如 Gmail郵件、Zendesk線上客服、Codepen 線上程式編輯器)

補充說明:
這邊的SaaS與在網站開發CSS style 進階技術的Sass唸起來是一模一樣。
如果這口語上聽到這個詞必須要依照內容情境來推論對方在講什麼,商業上多半是講SaaS,網站開發規格則比較可能是Sass。

「從SaaS談到API,進入雲端產品的新世代」

以雲端產品為代表的新時代即將到來,大型企業在軟體上的開發、維護與消費上都出現了重大轉變,更代表著程式設計師在未來可以賦予產品上更高的服務價值,AWS,Facebook,Google,Twitter和數千家其他網路公司,都透過提供WebAPI的方式大打經濟戰,而服務與服務之間的互動,也從過去SaaS的接口,轉移到WebAPI身上,那API是什麼呢?

API全名叫做應用程式介面(英語:Application Programming Interface,簡稱:API),主要的概念就是把各家或是各種軟體系統的「服務」,做成一種可以「互相溝通」的一種介面,透過服務呼叫、串接的方式來進行產品與產品之間的合作與溝通,重點就在「服務」與「互相溝通」這兩個關鍵字上。

補充說明:
其實很多網路公司在內部討論的時候不用 WebAPI,而直接使用API來稱呼網路服務接口,但API 的全名 Application program interface 只是代表應用程式的使用介面/接口,遠在網際網路還不純熟的時代就已經存在,無論是C語言系列的header檔,到製作成動態函式庫,都可以使用這個名稱。因此本文以WebAPI來表達一般網站所提供的外部程式接口。

我們舉例來說吧

當我們要去大賣場買鞋子的時候,找到了心儀的鞋子卻找不到適合的尺寸,這時該怎麼作呢?

當然我們可以翻箱倒櫃的在賣場中去尋尋覓覓,但這通常不是一般人會做出的直覺選擇吧,其中花費的時間與體力都是無形中的一種成本,還未必可以找到想要的東西,所以我們通常都會選擇「請店員來協助我們」做為我們找鞋子的方式吧!

當你在呼喚了店員請他們協助時,無形中就是對「服務」的一種呼叫,而呼叫店員的這動作就是「API」,他提供的是一種服務,透過呼叫的方式來和另外一支服務「協助找尺寸」去做串接。

1.想找到想要的鞋子尺寸:服務的目的

2.呼叫店員請店員協助:與「協助找尺寸」 的服務進行呼叫與溝通

3.跟店員表示自己要的鞋子和尺寸:提出呼叫服務的需求與規格-我要什麼東西

4.拿到鞋子:完成你需要的服務

當然,主要透過Web作為介面的,就是WebAPI囉!


舉一個實際上在網站上的例子吧!

像 Uber 中使用 GoogleAPI 來當作地圖和導航的介面,不僅可以減少 Uber 團隊開發自己圖台及精算最佳路徑的成本,更可以把團隊的精力投注在優化產品服務及使用者體驗的項目上,無疑是對產品的一大助力。

而在一般我們看到的APP裡面,所有的動態資訊也都是透過WebAPI和後台DB去進行服務串接的,例如:連鎖咖啡店的會員APP,當你希望使用「檢視優惠」的服務時,就會透過WebAPI的方式,把APP後台上架的這些優惠活動、折扣等等,進行串接,而優惠活動更是動態且持續更新的,總不能每次都版本更新之後才把活動進行上架吧,光是 iOS 上架的那些繁瑣程序就會讓你心力交瘁了。

透過上述的例子,我們可以發現,一項集所有服務於一身的大型產品,不僅本身維運上的成本難以想象,其中對於所提供服務的彈性上更是較難突破,不如把服務切分成各種的WebAPI來做串接,不僅可以分散維護風險外,還可以透過「服務」來創造商機,例如以產品做接口來說,「電商網站」和「社群網站」就沒有達到有效的連想,但如果把電商網站的「搜索商品」、「推薦商品」做成一隻對外接口的廣告服務WebAPI,和Facebook的廣告WebAPI做對接,這樣不僅可以在瀏覽動態時做置入性行銷,透過社群間的串接後面產生的經濟效益,更是無法預期。

而一項項服務維護的費用,肯定比維護產品來的少許多,也許在產品草創的初期,有效的運用核心資源,把一些不必要的工作外包給這些雲端服務,並把軟體產品的功能「外包」給WebAPI,讓團隊專注在更快地創建和發布新的業務模式,來保持公司的業務彈性與競爭力,也許這也是快速開發的重要法則。

RESTful Web API

在HTTP協定中,定義了多種不同的method做為服務的請求方法,近年來由於行動裝置的普及化,越來越多的產品及網站,都提供了WebAPI服務,因此身為程式設計師的我們,在設計API為主的Web服務時,對於HTTP請求方式的認知,更是相當重要。

最常見的method,五種如下:
GET
POST
PUT
PATCH
DELETE

所有的字看起來既熟悉又陌生,因為在Http的協定下,每一種呼叫方式都會有一種他專屬的特殊定義,對於寫過網站的人來說,GET和POST絕對毫不陌生。

當Web service使用Web API進行介面介接時,每一串我們設計的URL,就會是一個專屬的服務『窗口』。

舉例來說,像是讀取及上傳的動作,就屬於完全不同的業務,所以當然也會用不同的呼叫方式來設計。

簡單說,不同的Method就是對同一件事情做不同的操作。

以搭買鞋子為例子做衍生吧!

GET:取得型錄,了解想要找的鞋子、型號、規格等。
POST/PUT:呼叫店員協助幫忙找鞋子,並買到想要的鞋子。
PATCH:結帳後向店員更換尺寸或加價購買其他配件如鞋帶、襪子等。
DELETE:跟店員說我不要了。

用生活化的例子講解完後,改以程式的角度來說明

GET:取得(想要的服務)的資料或是狀態。(safe & idempotent)
POST:新增一項資料。
PUT:利用更新的方式於"指定位置"新增一項資料。 (idempotent)
PATCH:在現有的資料欄位中,增加或部分更新一筆新的資料。
DELETE:指定資料刪除。 (idempotent)

這裡突然出現了兩個名詞 safe & idempotent,這兩個是HTTP狀態描述的專有名詞。

「safe」是指該操作不會改變原本的資源狀態,並且同樣的結果是可以被快取(Cache)的。

例如: 查看訂單是不會改變訂單本身紀錄。

「idempotent」是指該操作不管做1遍、2遍或多遍,都會得到同樣的資源狀態結果。

例如: 同一筆資料被DELETE了2次,雖然都是一樣的結果,但第二次發送會因為資料已經被刪除而失敗喔!

GET / POST 我們用得很多所以沒什麼問題,DELETE與字意上相符所以不難理解。

其中讓人困擾的是 PATCH & PUT,要解釋它們必須參考定義 (RFC 5789)。

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5

依照 RFC 5789,
POST/PUT 都可以用來新增,
PATCH/PUT 都可以用來修改,
但其中的差別在哪裡呢?

POST的定義上屬於將原先沒有的資料去做一筆新增的動作,
PATCH就是一般常見的修改,
所以真的有問題的其實是PUT。

PUT在定義上(idempotent)無論做多少次,回傳結果都會一樣。

以POST來說,我要一雙鞋,我就會得到一雙鞋;
但是如果再用POST發一次我要一雙鞋,會出現兩種可能;
一種是我"再"得到一雙鞋,而且這雙鞋跟上一雙是不一樣的(以資料庫來說,就是ID不一樣);
或是我只能有一雙鞋,所以他會跟我說"錯誤"!! 我已經得到一雙鞋了。

但以PUT來說,無論我發多少次,他都會回我,我有一雙鞋,而我並不會變成兩雙鞋;
當然如果商店沒鞋,則變成我沒有鞋。

這點在很多程式框架裡面都有不完全正確,像 Ruby On Rails 的 PUT 與 PATCH 看起來是一件事(當然你可以自己修正)。

定義是絕對的,但應用是彈性的,所以你可以說這些框架做的與 RFC5789 不一樣,但或許這樣比較好用。
這就看個人取捨,當然,考試的時候通常需要寫 RFC5789 的定義。

另外,PUT 除新增外亦可以做更新請求,假設使用 PUT 做更新,不管是既有的資料或是覆蓋原先的資料,都會利用覆蓋的方式去更新,但假如你的資料裡面有圖檔的話,每 PUT 一次,圖檔就必須要再重新上傳一次,是相當耗費資源的。

而 PATCH 則可以針對已經存在的資料欄位去做部分更新,例如:我們在更新履歷表時,使用PATCH 就可以僅更新裡面的資料,如年齡、工作經歷等欄位,而 PUT 就像是把整份改好的履歷表重新上傳。

PATCH 也可以更新本身一開始 PUT 資料內沒有的欄位,故 PATCH 是非屬於 idempotent 的操作。

所以如果我們以電腦操作檔案來譬喻,建立一個新檔案是POST,修改檔案是PATCH,從別的地方複製檔案貼上就是PUT (無論你貼上幾次都是同一個檔案)。

當然Web API沒有一定要照著上面的定義敘述建立,但如果你符合的話,你可以將它稱作Restful API
(Rest化 = Restful,如果常常不知道講述的時候該用 Rest 或是 Restful 可以這樣去記,被轉化成 Rest架構 的 Web API = Restful API)

REST全名 Resource Representational State Transfer ,可譯為具象狀態傳輸,若是把各個單字拆開來解釋的話即如下:

Resource:資源。
Representational:表現形式,如 JSON,XML...
State Transfer:狀態變化。即上述講到的可利用HTTP動詞們來做呼叫。

簡單的說,就是一個單從發出的HTTP要求裡面所包含的資訊,就可以直接預期這要求會收到怎樣類型的資料。再更白話一點,就是人眼看得懂。

REST指的是網路中Client端和Server端的一種呼叫服務形式,透過既定的規則,滿足約束條件和原則的應用程式設計,對資源的操作包括獲取、創建、修改和刪除資源,這些操作就是依照我們前面所提到的HTTP Method: GET、POST、PUT、PATCH和DELETE。這正好會對應到資料庫基本操作CRUD。

CRUD 為 Create(新增)、Read(讀取)、Update(更新)與Delete(刪除)的縮寫。

接著我們繼續舉例來說,如果我們正在寫一隻商品的WebAPI,讓工程師隨便寫可能會有以下方式來作interface:

獲得商品資料 GET   /getAllItems
獲得商品資料 GET   /getItem/11
新增商品資料 POST /createItem
更新商品資料 POST  /updateItem/
刪除商品資料 POST  /deleteItem/

若是以使用 RESTful API 開發的話:

獲取商品資料 /GET     /items
獲取商品資料 /GET     /items/1
新增商品資料 /POST   /items
更新商品資料 /PATCH /items/1
刪除商品資料 /DELETE /items/1

PUT 則是比較特別一點,其實它並不直接對應CRUD裡面的任何一項。

在這樣的風格中最有名的,應該就是 Ruby on Rails了吧!

透過 HTTP 為基礎來設計 RESTful API,不僅可行,更可以更簡單扼要呢!

最後要提醒大家,我們沒辦法直接在 HTML的<form>裡面使用GET 與 POST以外的Method,因為瀏覽器都還不支援,如果想要發送 Restful request 一般都要後台程式的支援,而且必須要在<form>裡面藏一個<input name="_method" value="你的HTTP Request方法"> 才有辦法送出去。


資料來源:
https://progressbar.tw/posts/51
https://progressbar.tw/posts/53




大前研一:提升GDP是無稽之談

一般人或許會認為景氣與失業率息息相關,以前確實是如此,但事實上,在日本這樣的「成熟國」,這兩者並無關聯。

舉例來說,英國失業率在一九八○年代為一○%左右,但現在降到五%以下,達史上最低標準。就總體經濟學來看,這和日本一樣,是處在近乎「完全雇用」的狀態,所以餐飲店等服務業皆人手不足,但大部分國民卻都覺得景氣差、外來移民搶走了工作,而決定脫歐。

美國的失業率現在處於四%,算是非常低,但在中西部到東北部的新英格蘭一帶,有許多夕陽產業的「鏽帶」(生鏽的工業地帶),景氣非常糟,所得也低。在鏽帶,有許多人稱「窮困白人」的低所得白人,這些人在二○一六年美國總統選舉中,強烈支持川普要將創造二千五百萬個工作機會及反移民政策加入公約中的政見。

從這樣的案例中我們可以明白,景氣好失業率就低、景氣差失業率就高,這樣的相互關係深植在許多國民心中,但實際上,在大部分的成熟國卻是不同的狀況。

下流老人恐慌症,拖累景氣

最近報紙和電視上常大幅報導「下流老人」和「老後破產」等問題,但日本的個人金融資產一千八百兆日圓當中,有一半以上是握在高齡者手中。也就是說,大部分高齡者都過著優渥的生活,而「下流老人」和「老後破產」,只是極少數的問題。

我並不是說「貧困者對策」這項政策沒有必要,但如果認為朝這裡投注稅金,減少失業者,就是「刺激景氣的方案」,可就大錯特錯。

就現實來看,日本的景氣還算「差強人意」,雖然稱不上有多好,但也沒多差。在選舉時所做的街頭訪問和問卷調查中,若是問到「對政治有什麼期望?」大部分人都會回答「希望景氣變好」。但如果真的來到景氣差的國家,會發現到處都是流落街頭的人,而在日本看不到這種景象。

由於政治家和媒體都只關心迎合少數人的政策,所以大部分國民會覺得「要是失業該怎麼辦」、「我該不會也變成下流老人或老後破產吧」,而漸感不安,就此成為內向、消極、退縮的「低欲望社會」,因此個人消費始終不會擴大。

因為景氣是由眾人的「感覺」和「心理」來決定,這會隨著媒體報導而擴大和擴散,日本的景氣之所以遲遲無法恢復,問題就出在感覺和心理。

為了擴大個人消費、提升日本景氣,應該將國民的感覺或心理轉往「花錢」的方向。尤其是高齡者,從根本將他們認為「儲蓄是美德」的文化,改變為「人生就是要享受才有價值」,同時創造一套可讓人放心的系統,讓淪為「死錢」的一千八百兆日圓投入市場。

這正是政府最該優先著手的課題,鎖定這點推出政策,才是真正刺激景氣的政策。

國家應發行「綠卡」吸移民

以總體經濟來看,GDP越高越好,但日本的生產年齡人口(十五至六十四歲的人口)逐年遞減。在生產年齡人口遞減的情況下,想提升GDP的想法是錯誤的,因為連要維持現狀都有困難。

提升GDP的方法有兩種。一是增加勞動人口,這是很單純的計算。假設創造出一定附加價值的勞動人口,一邊有一千人,一邊有一萬人,其GDP的數值自然就不同。勞動人口越多,GDP越高。

事實上,根據世界衛生組織整理的資料(二○一三年),在調查過「中央年齡」(上個世代與下個世代同樣人口的年代值)後得知,日本為四十五.九歲,在一百八十三個國家當中年紀最老。看了之後便可明白,日本人口別說增加了,甚至還會再減少。

只要勞動人口增加,就算放任不管,GDP一樣會增加,這即是「人口紅利」(因人口增加而促成經濟成長),中國GDP成長減緩,就是因為人口紅利所帶來的恩惠已結束。

既然無法仰賴新生兒的增加,那就只能靠「移民」了。就現狀來看,日本並未推動移民政策,就算轉換為積極的移民政策,但接下來得對移民投注大筆的教育費用,針對日語、社會習慣、商業習慣等展開教育。

我認為日本應該要推動移民政策。例如想在日本工作的外國人,曾在自己國家受過相當教育的人才,由日本政府負擔費用,讓他們在日本的學校用兩年時間學習日本法律、語言、社會習慣等基礎。之後接受畢業考,經判定可以在日本生活無礙後,就發行「日本版綠卡」(就算沒有國籍,也能永久居住的權利和資格證明書)。

取得綠卡的他們如果來到日本社會,勞動市場便會就此活化,可解決人力不足的問題。

這是其他國家史無前例的機制,能成為防止外國勞工的居住地淪為貧民窟的有效手段。一旦日本成功引進這套方法,也會博得全球的一致好評。

個人應評估:我有多少價值

提升GDP的另一個方法,是政府朝企業投入「補助金」。如果產業能就此發展,也是美事一樁,但受這筆補助金壓迫的,其實是勞工。

安倍首相反覆向企業要求「進一步擴大設備投資」,但設備投資會引發什麼?請試想看看,那就是業務會變得比現在更加機器人化,藉由進一步的效率化,企業的業績或許會提升,卻有大量的勞工被革職。也就是說,失業率將就此擴大。

當中占最大比例的,是定型業務的白領。日本企業在定型業務方面,還沒加以效率化,這個領域日後必定會引進機器人或AI,到時候,辦公職務的勞工會逐漸被淘汰。

為了救濟失業者,須花費龐大的稅金。最後不管對企業投注多大的補助金,企業業績提升所得到的稅金,結果都會用在失業救濟金上,根本就是白忙一場。而在日本,這樣的負面循環已持續將近二十年。

這樣大家應該明白,「提升GDP」的目標根本就是無稽之談。

但商務人士要各自意識到「個人的GDP」,這點很重要。

「個人GDP」就是一個人「能創造出多少附加價值」。這想法並非不管國家怎樣、社會怎樣,都和我無關,而是抱持「我有多少價值」的觀點,重新評估自己。

舉例來說,如果在日本國內已達到頂點,那就前往有「人口紅利」的國外好好拚一場,將過去在日本曾奏效的商業模式,帶往新興國家。或是在創意上一較高下,例如強勢的品牌,不管再高價,還是會有買家。

正因為現在已是無法將提升GDP當目標的時代,所以每個人的附加價值(賺錢力)才會更顯重要。


『郭台銘』是怎樣煉成的

中國中央電視台(央視)近日在《財經人物周刊》節目播出「『郭台銘』是怎樣煉成的」專訪,鴻海董事長郭台銘在訪問中回顧創業之初,連奶粉錢都擠不出來的艱辛,還有看朋友炒地皮大賺時的沮喪,但他不後悔當年選擇將資本投注在技術上,因為「房地產只能賺一次錢,技術可以賺無數次。」

郭董被稱為代工皇帝,協助開發iPhone是他登上事業高峰一大關鍵,專訪中他透露與蘋果(Apple)創辦人賈伯斯(Steve Jobs)結緣是因摩托羅拉(MOTOROLA)「RAZR」手機,而賈伯斯試用蘋果第1台iPhone時,有人用郭董手機拍下一段短短大約10秒鐘影片,此後無論換什麼手機,郭董一定保存這段影片隨身攜帶。

手機永存賈伯斯影片

2004年9月摩托羅拉推出「RAZR」大受歡迎,掀起超薄手機風潮,賈伯斯對RAZR興趣濃厚,追查之下是富士康的Terry(郭董英文名)代工,立刻吩咐部屬:「趕快叫他來見我!」郭董回憶說:「他(賈伯斯)剛要轉做iPhone時,是跟摩托羅拉合作,我當時做摩托羅拉的RAZR,摩托羅拉不願意把最好的技術給他,所以蘋果手機就沒有最好的技術,我聽裡面人跟我說,摩托羅拉給他二流的產品,他把它丟到牆角去。」「他覺得我富士康做得不錯,說有些新的工作請你做,但請你要保密,是比較高科技的,我們品質要求比較高、價錢要便宜,你能不能做?我們後來做到了,他就請我吃飯。他們每年最重要的產品線,都是由他自己定案,他都會找我去討論。」郭董就這樣包下了iPhone訂單。他回憶賈伯斯常提出高難度要求,「我說這樣不可能做到,他說你回去試,你沒有試,就不要講做不到,後來果然就做到了。後來我常跟人家講,沒有試過這件事,你就不要講做不到,我從他身上學到很多。」

電視旋鈕開代工大門

回到創業初期,1974年,郭台銘在24歲那年拿出10萬元與朋友合夥創業,成立鴻海塑膠公司,經營不到1年就遇到全球石油危機,原物料價格大幅飆漲,合夥的朋友都撤資了,郭台銘到處借錢,一個人把公司頂下來,後來拿到電視機旋鈕訂單,小小的旋鈕不僅打開了鴻海電子代工的大門,也扭轉了郭董的命運。郭董回憶說:「我在想,我都靠外面買模具,模具是個高精密的東西,要買很多設備,要花很多人力投資,大概要5年才能夠回收。那個時候我只有一筆錢,有一個很困難的決定,是買塊地、蓋工廠,去外面買模具,還是去租一個工廠,去買模具設備,自己學做模具?」當年台灣經濟剛剛起飛,房地產狂飆,看到身邊朋友炒地皮賺快錢口袋滿滿,郭董也曾非常猶豫,但深思熟慮之後,仍決定購買日本最先進的模具設備,發展技術實力,儘管這樣的決定一度讓他「沮喪」好多年。「我用沮喪兩個字,為什麼?因為當初我沒有決定買那個土地,結果它漲了10倍,而我租的廠房,房東要漲房租,可是我買了最新的設備,那時候還在學習階段,良率很低,我做出來的模具還不如買的好。那個時候是給我們考驗,讓我們覺得做模具廠是對的,等到3~5年後,房地產雖然漲了10倍,但是之後它就不動了,房地產只能讓我們賺一次錢,可是你用核心技術,可以賺無數次的錢。」

創業拿奶粉錢拼技術

那幾年郭董把所有錢都拿來買設備,一度連孩子的奶粉錢都付不出來。長子郭守正1976年出生,郭董有天晚上回家聽見兒子嚎啕大哭,生氣質問妻子怎麼回事,妻子林淑如含著淚說:「兒子太餓了,根本睡不著覺,你都多久沒有拿錢回家了!」郭董說:「那時候台灣有一條法律(編按:《票據法》),如果你跟銀行借錢不還,是要坐牢的,那時候真的有非常大的壓力,曾經3天不睡覺,為了把工作做好。」經過幾年堅持,郭台銘嚐到甜果,拿到第1筆來自美國跨國企業的訂單,又把賺到的每一分錢都投資擴充產能,依靠量大、低價的策略,很快地就打開了市場,卻馬上遇到創業初期最大一場危機,有1筆冰箱旋鈕訂單交貨之後被告知不合格,5萬個全部要退貨,郭董可能因此傾家蕩產。郭董說:「那個產品有電鍍,要做溫度循環試驗,要零下30度,可是在台灣長大的孩子,連零下3度、5度都沒見過,怎會想到30度?我就說這要求太過份了!」他一方面親自跟美國客戶協調,一方面讓工廠再生產一批,「他們用抽檢,抽檢1000個,換了2個,它就退貨。我說不是每個都壞啊,跟客戶交涉後,客戶答應給我換貨,後來那5萬個退了10分之1,換了5000個。如果當初5萬個都退了,今天就沒有富士康。」這件事讓郭董認清技術在工業製造領域有多重要,願意花鉅資建立檢測實驗室及材料研發實驗室,奠定日後拿下國際大單的基礎。郭董說:「我都是跟著全世界最好的客戶走,不管是當時的康柏、還是IBM、惠普、摩托羅拉、蘋果、思科,都是世界一流的,他們會告訴我市場是巨大的。」為了拿到康柏的訂單,郭台銘索性在康柏總部旁邊建了一個樣品廠,康柏只要有新設計,當天就能看到樣品,此舉為他贏得康柏長期合作。「當時我的營業額是幾千萬美金,人家(競爭對手)是20億美金,是我的千百倍,我要跟他競爭,我靠的是速度、靠的是品質、靠的是價錢。在這個時候接近客戶,客戶要我產品3個月交貨、2個月交貨,我說可以。客戶問我為什麼可以?我說我們的人可以24小時輪班啊。」郭董說。

鴻海近年致力轉型,積極推動工業互聯網,2011年提出「百萬機器人計畫」至今7年,郭董信心十足地說:「我們希望5年,目標把工人拿掉80%,如果5年做不到,10年一定做的到。」郭董引用海爾創辦人張瑞敏的話說:「雞蛋被外面打破,就是顆雞蛋,只能煮來吃,但若是從內打破,就是重生。」

給上一世代:抽回你偷資源的手;給這一世代:你要勇敢走出去

http://www.cheers.com.tw/article/article.action?id=5070532

一個人如果愈年輕接受過失敗的歷練,就等於給自己一本失敗存摺,累積愈多,體悟愈多。所以不要把失敗等同挫折、等同絕望,要相信它叫歷練。 

「迎合年輕人不是我的風格。」一貫直率、犀利本色,陳文茜曾在接受對岸媒體專訪時這麼說過。

話雖如此,這幾年來,陳文茜投入的不少工作,卻都與年輕人對話有關,不管是主持3年多、已超過20場的《中天青年論壇》,或是電視節目《文茜的世界周報》。前者,和不同世代領袖對談,萃取他們的人生菁華;後者,解讀國際動態,試圖在台灣缺乏世界觀的新聞環境中另闢蹊徑,陳文茜始終以她獨樹一幟的觀點與評論,對年輕族群發聲。

2015年陳文茜的兩本著作,分別是《我相信‧失敗》與《我害怕‧成功》,收錄了她在《中天青年論壇》中與蔡康永、周杰倫、五月天阿信、嚴長壽、林懷民、蔣勳、羅大佑、張忠謀等人的對談紀錄。每一個名字,都是台灣重量級的指標人物,透過剖析他們的心路歷程,彷彿也一次拆解了各種多元的典範方程式。 在他們身上,陳文茜發現什麼?對於台灣的青年與世代議題,陳文茜又有哪些洞察?

Q:妳最近出的兩本新書,說話對象都是年輕人,而且書名很有意思,一本叫《我相信‧失敗》,另一本叫《我害怕‧成功》。為什麼以書名顛覆一般人對於成功與失敗的理解,妳想藉此對年輕人說什麼?

A:這跟我的人生閱歷有關,是我看了很多人與事後得到的體悟。 一個人如果愈年輕就接受過失敗的歷練,等於給自己一本失敗存摺,累積愈多,體悟愈多。我見過太多人突然成功,一旦失敗,就從懸崖上摔下來。如果有過很多失敗歷練,就算摔跤,也有能力東山再起。所以不要把失敗等同挫折、等同絕望,要相信它叫歷練。

那成功呢?你要害怕成功,把它等同是「我運氣很好」。人生像爬山,爬的過程裡,沒有碰到暴風雨、土石流、心肌梗塞,只是成功給你的機會跟僥倖。很多人出發時抱著純潔的夢想,所以衝的力量非常大,但一旦目標完成了,他就瞬間像個崩解的柏林圍牆,啪啦啪啪就倒下了,為什麼?在鎂光燈跟掌聲中,非常容易迷失自己。這就是為什麼比爾.蓋茲(Bill Gates)的名言是「成功是最差勁的導師」。

Q:這是我好奇的下一個問題。妳在書裡採訪了橫跨不同領域、世代的人物,年紀最大的包括企業家張忠謀或郭台銘;年紀輕的有偶像阿信或周杰倫。妳觀察決定「過去∕未來」世代「成功∕失敗」的原因是否相同? 

A:我覺得是一樣的,兩個字,叫做「謙虛」。

譬如說周杰倫。周杰倫還沒出道前,在吳宗憲手下工作。當時我看到他在吳宗憲的店裡彈鋼琴,見過張學友、劉德華……很多人,每個人都說:「小孩子啊,琴彈得很好」,就走掉了,沒有一個人多看他一眼。

他當時寫了好多歌,卻一直被退,唯一選他歌的是江蕙。我問他,後來會不會覺得有些人有眼不識泰山,因為第一張專輯就大紅了。他說不,那些人退歌是理所當然,這些歌本來就是寫給自己的,只適合他自己唱。他從沒有恨過那些當時不賞識他的人。

我也問了一些跟他很多年的人,為什麼這麼喜歡周杰倫。他們說,很多天后、天王辦演唱會,根本不考慮幕後工作者的辛苦,只有周杰倫每一次會想到:全部總收入多少,你們每個人應該多少。至今為止他都是這樣,他不貪心,會留著給別人,因為他曾經苦過。

阿信也一樣,當我說我應該介紹你是五月天主唱、天團時,他說他不要,他說「我是公視董事」。當很多人在罵公視時,他願意承諾幫公視做事,雖然不見得有最好的專業能力,但他認真看待這個身分。

講年紀大的,江蕙也是。她把每一場演出都看成最後一場。本來今年要邀江蕙來青年論壇,她說等一切忙完了,身體好一點再來。她說她好像應該跟年輕人說說話,可是她是個沒念書的人,要說什麼,得準備一下。

他們都一樣,有種充滿謙虛的個性,不管在什麼位置上。

Q:為什麼妳都沒有提到「創意」、「顛覆」、「破壞式創新」這些時下熱門的字彙?或許很多人會認為,時代不同了,這個世代的成功之道也有別於過去?

A:它們也許是讓你暫時成功的條件之一,但不見得可以扮演讓成功持續十幾二十年的角色。

很多所謂的破壞式創新,可能滿足的是短暫的需求,一段時間後,需求就沒有了。像《壹週刊》,剛開始在台灣掀起風潮,但現在為什麼殞落?不是因為紙媒性質,而是初期它抓住人崇拜上流社會的心理,用狗仔隊幫人偷窺,釋放人被社會的壓抑,帶來快感。久了以後呢?大家覺得不再這麼想看這些了,需求自然就消失了。

安迪.沃荷(Andy Warhol)說過,每個人都有成名的15分鐘,換成現在這個快速傳播的時代,你很容易紅15秒、15小時,可是當你想把它變成15個月、15年,這就不容易,還是要回到踏實工作,踏實把自己的事做好。

Q:從20多場和年輕人對話的過程中,妳發現大家面臨最迫切的課題是什麼?

A:很多人問的問題都是:「我該學什麼?」、「我該做什麼?」

我想分享的是,有個年輕人提到,他念MBA,目前還在讀書,可是找不到工作,只好去開吊車,當吊車司機。一個吊車司機的月薪有新台幣4萬塊,再加班可以領到5萬塊,如果去做一般服務業,可能只有3萬多。他就問了張忠謀跟郭台銘,該繼續下去嗎?

郭台銘回答:你是研究所畢業的啊,那你跟本來開吊車的人是不一樣的。你應該不斷思考開吊車可以用什麼方法更有效率。

他就講了在中國很有名的三一重工的故事。它的創辦人梁穩根,因為不斷想怎麼把機械做得更好,後來變成大老闆。這個意思是,你有腦筋,不要覺得做這個工作委屈,你可以跟別人不同,有不同的出路。

張忠謀遇到這類問題時,他說起他的父親20幾歲就在南京、廣州當上銀行經理,後來是寧波財政局長。45歲抱著「美國夢」進入哥倫比亞大學讀企研所,當然是全班最老的學生。47歲碩士畢業,雖然還有雄心大志,卻抵不過大時代的殘酷,在異鄉只能無奈地與妻子開一家小店,維持生計。

於是他跟太太說,我們要替兒子著想,我如果接受別的工作,兒子就不能在美國最重要的城市接受教育。這也是為什麼張忠謀一直很了解什麼叫做「沒有國家就沒有自己」。

當時他用這個答案回答:我爸爸開雜貨店為什麼會賺錢?因為他曾經是財政局局長跟總經理,跟別人配貨取貨、談判價格、跟猶太人競爭,他都能獨樹一幟。

兩個人回答的角度不一樣,但講的都是同一件事:永遠不要覺得手上的工作低賤,如果你夠好。

Q:從妳的角度呢?妳認為台灣現在最重要的青年議題是什麼?

A:我覺得是年輕人在學校學的,出了社會發現沒有用,所以他們那麼徬徨、無助、絕望,也因此他們有些人很憤怒。

時代變得那麼快,可是學校、老師跟產業的結合是如此薄弱。大學既有科系的分類,不只沒有ahead of time(領先於時代),比現有需求還要落後。好不容易考進去,或是好不容易家人讓他去念昂貴的私立大學,出來卻什麼都不會,我覺得這是現在大學生最大的絕望,這個絕望讓他們害怕跟世界競爭。

他們痛恨低薪,不穩定性很高,但也不願意去做台灣最欠缺的製造業、勞動工作。所以製造業的勞工年齡偏高,服務業的年齡偏低,薪水也因為競爭激烈而漲不起來。

我曾經建議一個MBA學生去學家事管理。很多人被台灣的外勞政策整得半死,他們家裡需要幫手。我說,你只要腦筋一變,結合其他提供清潔、水電維修的服務,變成管家,據我所知,這種管家的薪水都是4萬5千塊起跳,那就脫離了月薪3萬塊的狀態。

並不是沒有薪水合理的市場,只是很多年輕人不願意進去薪水合理的市場。進去了,也不表示做的要跟以前一樣,你可以改變,就會成為奇貨可居的人。

Q:社會企業和社會參與,是近來吸引不少年輕人投入的兩個領域。妳對此又有什麼觀察?

A:關於社會企業,台灣的年輕世代在這點上是超越以前的世代。我們前面幾個世代的人,認同的世界只有自己的家庭,並沒有普遍關懷地球、關懷人類、關懷社會弱勢的態度。但現在台灣很多年輕人可能會說:「爸爸,我不想跟你一樣去製造業,我想有不一樣的人生,我願意去非洲做志工。」這是老一輩、上一輩不會做的,也是這個世代很大的特色。

另外是社會參與。我自己小時候就是個政治參與者,當時台灣在戒嚴體制下,我希望建立的是民主制度;但現在的年輕人,可能覺得社會的問題是不公平。不過,當兩件事同時存在,一是網路上要求絕對的「人人平等」,另一是「毫無節制的功利主義」時,這兩個結合,會變成怪獸。

很多人在網路上發動人身攻擊、網軍式的痛罵,並不是真的因為覺得不公平,而是他沒有得到他攻擊的對象所得到的利益。也因此,他的挫敗感不是真的來自結果公平不公平,他真正問的也不是公平不公平,而是「我為什麼不是那個獲勝者」。

社會參與,應該是一個改造社會制度的過程,不是個人因為自己不是功利主義下的獲益者,所以產生不滿而要發洩。

Q:不管怎樣,年輕人是台灣社會愈來愈珍貴的資產。對於如何開啟更多的世代互助或世代對話,妳有什麼建議?

A:先要求我們自己。我覺得老年人要有自知之明,如果享有過多的老年福利,要去想想:這個國家的財政還可以撐下去嗎?對得起下一代嗎?

對有權力的老年人,要愛國家大於自己,不要貪小便宜,把資源全都壓榨光。你現在炒房子,年輕人就買不起房子,他們很憤怒,就會攻擊社會體制。我們這些老年人把國家能吃的吃、能炒的炒,全部用光光,最終的結果,是年輕人沒有未來,台灣也會往下沉。

所以,這個問題我倒過來回答:老年人,不是請他把棒子交出來,而是請他把偷東西的手抽出來。

有權力的老年人,要愛國家大於自己,不要貪小便宜,把資源全都壓榨光。老年人,不是請他把棒子交出來,而是請他把偷東西的手抽出來。 

Q:年輕人呢?妳希望看完妳的書之後,最應該去做的事是什麼?

A:不要害怕一無所有,也不要以既有的環境限制自己,然後感到憤怒。

要不斷走出去。我們的祖先從福建過來,如果當時他們留在原地,根本沒有我們,他們就是一群不膽小、敢出走的人。

我有另外一本書寫到林語堂,他爸爸是漳州一個小漁村的牧師,以他的家庭背景,根本不可能培養出後來的他。但他爸爸就一句話:「你一定要離開這裡」,所以他8歲就寄住在牧師家裡,大學去哈佛,錢不夠還跟胡適借,後來去了德國萊比錫大學深造。

又比如像阿信,第一次到上海辦演唱會,只來了20個人。他在台灣已經是天團,這樣還要繼續唱嗎?通常一般沒骨氣的人,會氣得罵人,但阿信就一直唱一直唱,唱到在北京鳥巢辦20萬人的演唱會,從此變成大陸樂團裡頭的神。所以我給年輕人的建議就是:你要不斷走出去,不要把環境當做限制。


品牌的行銷預算

星巴克前執行長霍華.舒茲(Howard Schultz)曾說,如果人們相信自己與品牌共享相同的價值,他們就會忠於該品牌。這句話,正適合用來解讀今年的亞洲影響力品牌調查。人們明顯偏好更能夠詮釋自己生活品味的品牌,像是誠品、星巴克、愛迪達(Adidas)等品牌風格明確的企業,幾乎連年都是前20名的常勝軍,且名次持續在進步。

一般來說,品牌端的行銷預算會分成 3 種:


  1. 平台型:單純只做品牌形象,像是高大上的品牌宣傳影片或廣告等。
  2. 行銷活動類:遇到新品上市、季節性活動所採取的行銷方案,以促銷、主題性的內容為主。
  3. 頻繁互動式:透過臉書的粉絲專頁、Line@ 官方帳號或行動 App 等管道,搭配時事、獨家消息等議題,機動且靈活地與消費者溝通,保持品牌活躍度。


大多數品牌擅長以電視、平面廣告等傳統的方式來傳播,因此會將行銷預算分配為 3 成平台型、4 成行銷活動類、3 成頻繁互動式 。但隨著社群、數位興起,行銷人無時無刻都得要做品牌行銷時,就不能再仰賴傳統的行銷手法,「全世界的行銷趨勢幾乎都開始著重在頻繁互動式的行銷,占據 4 成至 5 成的行銷預算。」

蝦皮就十分善於將產品結合時事,創造社群互動,例如先前藝人徐乃麟在錄影中「飆罵」的事件,蝦皮趁勢運用奶油酥餅,搭配「酥不起」的文字標語,推出「乃油輸餅」,引發網友瘋傳。不過,王馥蓓建議,行銷人心中要有一把尺,不要為了跟風而做出不符合品牌調性的行銷操作,使用的素材也要慎選,避免因為議題敏感或玩笑開過頭而造成反效果。

奧美公關董事總經理王馥蓓提醒,要確立自己在消費者日常生活中扮演的角色,最大的考驗,是企業如何在既有的品牌個性之下,創造與品牌有連結的話題及互動。如果能做到有個性又有互動,就較不需擔心資訊碎片化的時代中,落得被遺忘的下場。

品牌影響力與年營收、銷售量並無直接相關,而是指它在社會上的地位,以及跟消費者互動的過程中,帶給人們的感受與體驗。

一般而言,消費者愈常接觸到的品牌,名次愈容易在前面,但是這只是基本條件。王馥蓓提到,面對影音和數位的時代,許多品牌主費心經營臉書上的粉絲專頁、社群互動,思考如何在網路上締造聲勢,都是為了透過網路,強化品牌在消費者心中的印象,藉此走進消費者的日常生活。

而無論是在實體世界還是網路平台,「最基本也最重要的,是釐清品牌想扮演的角色。」 品牌塑造的形象或傳遞的內容,必須貼近消費者的真實生活,或是有效解決生活上遇到的難題,才能拉近品牌跟顧客之間的距離感,用親近性發揮影響力。

像是一般人不會時常跑到家具店購物,對於家具的關注度也不會比飲料、食品等日常用品高,但IKEA卻能透過「改造計畫」的系列影片,像是傳統市場、老屋、空巢(小孩長大後離開家,留下父母在家)翻新,和不同族群和年齡層的消費者對話,透過一個個真實紀錄片,引發他們的共鳴及對「空間、收納」的重視,以此傳達「為大多數人創造更美好的生活」的品牌理念。

中國信託所建置的無障礙網路銀行,則是鎖定特定目標群眾的生活需求,進行開發。數位營運處處長何慶媛表示,無障礙網銀要符合政府認證機制不難,難的是真正做到讓視障朋友方便使用。「以人為本,才可能讓消費者對你的創新有感。」

為此,他們不但團隊身體力行,親自嘗試眼睛閉上後操作網路銀行的不便之處,也邀請視障朋友們實際參與開發過程,了解他們對於按鍵位置、語音朗讀等方面的困擾,耗費一年時間針對他們的反饋及需求進行調整,也讓這個網站在今年初上線後,成功取得認證標章,還有視障朋友特意致電前來致謝。

王馥蓓說,「當你對話的族群、互動的方式及時機都對了,你就能在關鍵時刻扮演舉足輕重的角色,並在消費者心中留下深刻印象。」


部屬嘗試新做法卻失敗,該罵嗎?柯文哲的管理心得:承認失敗比懲處更重要

花了台北市長柯文哲3年半的時間,才在他眼中小有成績的「政策」是什麼?他在 6 月 29 日舉辦的「敏捷高峰會」上,給出了答案:企業文化。

「我要建立一個不怕失敗的環境。」柯文哲心目中理想的企業文化,和敏捷(agile)式管理強調的不斷測試、取得回饋,擁有相同的精神。不過,在一般人印象中保守的公務員體系,少以企業管理的精神來思考,該怎麼導入敏捷的思維,做出改變?

讀《A到A+》,體認企業文化的重要

柯文哲在演講的開頭,先替政治下了定義:做對的事情,不做不對的事情。然而,台北市政府上下有多少員工,就會有多少種「對的事情」的不同定義,促使同一件事情,發展出不同的方向。大家的力量不僅無法結合,還有可能互扯後腿,最後回到原點。

只有讓組織具備一套企業文化,讓每個人從潛意識裡按照同一個方向前進,才是凝聚眾人共識的最好方式。

過去,他在台大醫院帶領葉克膜團隊時,每逢有新人加入,就會請對方念關於企業文化的短文,讓他們能清楚知道為什麼要認同團隊的價值,才有辦法留下來。原因是強烈的企業文化,足以形成團體共識,大家會有一套評斷對錯的標準,出錯時便能自我糾正,朝對的方向前進。

他也笑著回憶,想要觀察新人有沒有成功融入組織的文化,只要把新人交給曾擔任葉克膜小組主任的蔡璧如,如果對方 3 天之內把就手錶拆掉,那就成了。「因為我們只有上班時間、沒有下班時間,」他說,「所以根本不需要知道現在幾點。」

另外,他讀了管理學者吉姆‧柯林斯(Jim Collins)的著作之後,發現 卓越企業的高階主管,離職高峰點只有 2 種,要不是儘快離開,否則下一次就是直到退休。 反觀非卓越的企業裡,人事流動則相對頻繁,對企業會產生很大的負面影響,光是要重新找尋、培育人才,就得花上不少的成本。

柯林斯在另一本著作中也提到,一位好的員工,必須要認同組織的共同價值觀。柯文哲認為, 企業文化正是能夠找適合員工「上車」的最佳方法,如果能夠在一開始,就訂出明確的文化內容,組織自然就能快速篩選出適合的人選,也能減少因人事頻繁變動造成的陣痛期。

主管允許員工失敗,才會有下一次的創新

柯文哲認為打造強烈、具有影響力的企業文化,是身為領導人最重要的職責,而他想為台北市政府打造的是「不怕失敗的環境」,以此達成團隊的其中一個使命:為城市創新。

失敗和創新有什麼關係?

他有感於矽谷發展成全球創新重鎮,特意向一位教授請教台北是否也有這樣的潛力,卻得到「不可能」的答案。原因是,台灣人習慣追求提高成功機率的可能性,但根據經濟部統計,新創事業在 1 年內倒閉的機率高達 90%,前5年陣亡的比率則高達 99%。「如果整個城市只在意成功,卻不能容許任何的失敗,就沒有必要談創新。」

為了讓整個市府都願意包容失敗,柯文哲從這兩件事情開始做起:

1. 員工嘗試新的做法,做錯了先別懲處

「我們常常是不做不知道,做了才知道。」他指出,要能夠放手讓下屬去嘗試,才會知道一項政策到底怎麼規畫、怎麼執行,才有辦法步上軌道。像是台北市社會局的托育服務,原本是由 3 位專職人員照顧 10 位小孩,跑了半年後,才得出 4 位專職人員是最合適的配置。

柯文哲特別強調,要讓下屬願意嘗試,關鍵是你敢不敢「允許他失敗」。他舉例,去年重陽節舉辦的健行活動,發生了推擠受傷的事件,引發許多民眾不滿,他也數度道歉,承認這是個「失敗的活動」。

但事後他沒有懲處任何一個人, 「如果你的部下想要幫助老闆,事後卻被懲罰,就再也不會有人想出新點子。」 他解釋,因為整個環境、民眾的需求都在變,不變、就一定沒有創新。所以即使是政府單位,還是可以從小規模嘗試做起,即便失敗也能學到經驗,長久下來就能比較不害怕。

2. 成功只有一次,必須捨棄、而非複製

「我們在成功的時候,不可能放棄過去的模式,除非面臨失敗。」柯文哲以自己為例,在 2014 年勝選的那個晚上,就把所有的參選資料全部丟掉,因為成功不能被複製,下一次的選舉,不能再用一模一樣的方法。

「成功為失敗之母。」他強調這不是開玩笑, 並舉例一台 iPhone 手機的利潤,蘋果公司靠著研發、品牌與行銷得到大部分的獲利,而台灣的代工卻只能拿到個位數的利潤。這是整個台灣都必須面對的課題,產業要能夠從過去的成功中醒來,才有辦法走向更遠的一步。

程式語言編年史

程式語言編年史原文 下面這張圖片描繪了整個程式語言的歷史。包括各種程式語言的發明人、程式語言的特點和適用領域、被什麼網站或公司使用等 (檢視 完整高清圖 )。 之所以會有那麼多不同的程式語言是因為設計程式語言的初衷不同、對語言學習曲線的追求不同、不同程式之間的執行成本差異...