if … then … else 是基本上所有程式語言的最基本語句，當（if）引數滿足規定條件時（then）觸發特定函式（else）觸發另一函式，通俗理解這一語句就是程式裡的道道關卡，這些關卡將一個個小的程式碼片段銜接成執行有序的龐大程式，從而完成複雜的計算。所有的軟體、網站、移動應用的背後都是如此。而今天要介紹的這個真正 “神奇的網站”ifttt.com，則將 if … then … else 機制擴充套件到了整個網際網路。
ifttt的本意是 if this then that，它將Facebook、Twitter等各個網站或應用通過API銜接成一個跨網際網路的自動機器，像多米諾骨牌一樣完成種種不可思議的任務。但與if … then …語句不同的是，ifttt.com呈現給使用者的不再是程式碼，而是現成的服務，從而讓程式設計變得不再重要，每個人都可以成為整個網際網路的不用程式設計的“程式設計師”。
ifttt結構拆解 ifttt是一個神奇的服務，但卻非常簡單，主要由任務、觸發器、反應器三部分構成。
- 任務：ifttt 即 if this then that，它能完成什麼任務呢？只要你能將任何複雜的任務定義成“如果事件A（this）觸發，那麼事件B發生（that）”這樣的簡單結構，ifttt.com都能幫你搞定。
- 觸發器：this，例如“我在新浪發了條微博”，或是“我在人人網的某張圖片被圈了出來”，或是“iOS上的天氣應用提示明天有雨”。
- 反應器：that，例如（與上面的三個觸發器示例對應）“在人人網發一條狀態”，或是“給我傳送一條簡訊”，或是“給夢中情人發一條米聊訊息說‘我夜觀天象發現明天有雨可別忘了帶傘喲哈哈’ ”。
ifttt示例
ifttt支援的服務（還有更多）
ifttt的魔力：由簡單組成的複雜上面的3個例子可能稍顯單薄，而ifttt的真正魔力在於“由簡單組成的複雜”，也就是由眾多簡單的ifttt相互銜接成跨越整個網際網路、跨越多平臺、跨越多裝置的超級自動機器。
這就跟在自然界和人類社會普遍存在的分形理論一樣，無論多麼複雜的大尺度的地形地貌、股市行情、社會結構都是由自相似的小尺度幾何形狀組成的。
回到ifttt.com，一個簡單的複雜例子是，如 @hecaitou 在Twitter裡所說的，理想狀態下的ifttt應用場景：一旦老婆的推上出現“加班”字樣，立即啟用一條手機簡訊通知。同時，自動檢測谷歌日曆，找出幾個今晚沒有事情的老友。隨後，在FB上新建一個活動“今晚喝大酒”，一旦超過3人同意，觸發一條訂餐訊息給餐廳。餐廳查詢Evernote，找到這群人最喜歡的菜和酒。
ifttt發人深省：給使用者服務而不是產品和技術 ifttt解決了使用者的兩大問題：
一是之前的產品過於零碎、分散化，儘管雲服務已經解決了單個應用的跨平臺跨裝置同步問題，但卻不能解決產品之間的分散化問題，即單個產品只能解決使用者的單個問題。如果線上下很好搞定：請一個或者多個祕書就行了，祕書能幫著搞定各種繁多的瑣碎任務；但線上上反而會落後很多，各種產品間的通訊和協作非常困難，比如當你的某條微博轉發數達到10000次，就給你發條簡訊並截個圖分享到推圖和人人網，這樣一個簡單的事情都相當困難。
二是技術的複雜程度，RSS、API等為各種服務的整合提供了便利，比如Instagram就利用了Twitter的API，讓使用者在Instagram 拍攝的圖片也能分享到Twitter裡，但是這又陷入了第一條所說的分散化的老問題，單個產品也只能利用其它產品的API開發出有限的服務。如果使用者要自行整合各項服務以滿足自己的隨心所欲，那麼將面臨著相當複雜的技術難題，更何況沒有時間，因為每個人都是普通人，我們只是想要這樣隨心所欲的服務而不是自己親自動手，就這麼簡單。
ifttt的創始人 Linden Tibbets 和 Jesse Tane 正是遇到了這兩大問題，才決意開發ifttt。
ifttt憑藉著對使用者需求的深度洞察，將所有的API呼叫、服務整合都挪到了後臺，由ifttt的工程師和程式來處理，而面向前端使用者的，就只是現成的隨心所欲的服務，而且讓使用者像“程式設計”一樣地設定 if … then … 的條件，讓使用者以極簡的方式為整個網際網路“程式設計”，執行結果就是自動化的隨心所欲的服務。
事實上ifttt的理念也跟Apple前不久推出的iCloud雲服務有著某種暗合，即只給使用者呈現最簡單的現成服務，將其它一切使用者不關心的都挪到雲端或是後臺。
原文：cnbeta