product marketing

近代企業分工很細，讓很多人工作起來見樹不見林，只專注在手邊的那些事。分工形成的比較利益很重要，但自己那份工到底在大機器扮演什麼小齒輪，是個宗旨層級的命題，不可不察。

• 公司法開篇告訴大家，公司以營利為目的。也就是說，除非你是非盈利組織，不然公司這種法人的存在意義就是營利。
• 接下來要探討如何獲利，即方法。若將經商簡化為買賣，就是「賣」「東西」吧，那東西稱之為「產品」，可以是實體物質，虛擬商品或精神價值。
• 「產品」要製造，所以需要雇用工人與準備資本財。簡化為人力與金錢投入吧。
• 「賣」「東西」的另一要素就是「賣」，稱之為「銷售」。所以需要業務人員。
• 「賣東西」的基本架構成了。而公司是法人不是自然人，所以要再講究一個規模的問題。若需要擴大賣東西的規模，就要宣傳。所以需要行銷人員。
• 宣傳好，賣的多，「東西」就要流水線化的大量生產。所以資源的投入變成「工廠」。工廠就要再細分工頭，後勤單位，等等等等。
• 「東西」造多了，宣傳與販賣的活兒也增加，所以業務單位與行銷單位也開始大量分工，也有了自己的後勤，或是併用工廠的後勤。
• 這些邏輯因果通了之後，再看看你在哪裡。你的上下游缺了，得先補他。只專注在手邊那些事，法人營利不了，你的事終究會做不了。除非你其實不太在意自己做啥，打零工就OK了。

man month

軟體開發必須考慮後續維運。若打算使用超過一季，除MIS的長期支援之外，持續開發與更新也是必要考慮的成本。若開發團隊不足，後續MIS的維護問題容易逐年擴大，所以還是考慮具有持續開發力的 1) 商業公司 2) 開源專案，比較理想。又以後者在風雨飄搖的時局，更能持久。

business analytics

商業分析應屬資料分析在技術上比較初階，但詮釋上很有趣的一環，因為商業模式的變化沒有界線，可以對市場做出很多實驗與結果來。分析基礎不跳脫ETL。

• Extract. 提取。從紛擾的訊號中過濾有意義的資訊。
• Transform. 轉換。數值上做出矩陣轉換，最簡單的就是試算表的XY二維。
• Load. 載入。獲得結構化的矩陣後，載入他們就可以開始分析啦。

climate change

說現在的梅雨因為氣候變遷，而有所變化。之前沒有特別留意這個現象，昨天無意看到氣象局發布「午後對流」，才注意到四月期間竟有強對流發生，而非夏季! 深夜更又發生了強降水。

• 地面圖只顯示滯留鋒面，而且台灣上空鋒面還不明顯。是可以說有大環境的影響，但鋒面的機械與動力舉昇產生的對流，不應如此強吧。
• 「由文化部補助的紀錄片《黃梅行雨》，以記錄梅雨氣候及梅雨文化為主要內容，揭露了國內目前氣象研究的許多重點。歷經數年的採訪，發現一向在國人心目中象徵溫柔、婉約的梅雨季，已經風景不再，代之而來是疾風暴雨，以及晴即旱、雨即澇的極端現象。」或許這部片有闡述比較長期的觀測結果。
• 「中央研究院氣候變遷中心主任王寶貫，長期從事氣候周期性變化的研究，數十年的論證、比對，他也認為，由於全球增溫的現象，確實讓梅雨的絕對雨量有越來越大的可能。」現在的氣象資料也就是幾十年，要談氣候變遷，也只有幾個週期的觀測，勉強只能推測可能性吧。

REF: 氣候變遷 讓氣象人站到人類命運的前線

The Art of War

有句話說「半部論語治天下」，但孫子只看半部(虛實之前)，似乎侷限在戰略層面的思考。戰術執行應用面，更需要花時間讀下半部吧。

• 軍爭。以迂為直，以患為利。
• 九變。有所不為。
• 行軍。曹公曰：取其便利。
• 地形。地勢與兵勢。
• 九地。九天之上，九地之下。
• 火攻。有五，不可怒而興師。
• 用間。非微妙不能得間之實。

NVIDIA 2016 GCT

NVIDIA果不其然，要推VR與learning. Here are some highlights of 2016 GCT.

• a lot of VR talks.
• Announcement of 1st machine dedicated for deep learning: DGX1. 250 server power in one box, decrease learning time from 2 weeks to 2 hours. 
• Robo Race, similar to F1 race, are self driving cars running different AI nets with super high speed! Dave Net is one of them.

world mapping

把媒體產業標注於世界地圖上很酷。算是一種胸懷天下吧。

• 亞太區

1. 電視通路，如衛星，OTT等。(地理分佈)
2. 行動通路，如社交平台，App,  網站等。(平台分佈)

• 全球

1. Global Digital Network，媒體集團有的大平台一起賣。
2. 電視通路，整合所有local cable network，很可觀喔。

artificial intelligence

電腦剛開始發展的時候，人就想做人工智慧(AI, artificial intelligence)了，所以美國很早就設立了一堆AI Lab，LISP這個古典的AI語言也面世。只不過，搞了幾十年到今天，從IBM深藍到Google AlphaGo，好像發展仍頗為受限。

• 從LISP角度看，就是將方程式化為矩陣有效的運算，而方程組的好壞就是關鍵了。
• 七零到九零年代的遊戲AI就很能提供樂子，是沒有人腦聰明，但簡單的規則運算不錯。能上市販售，表示「擬真度」受市場接受，然而程式本身就幾百KB而已。
• 二十一世紀後，電腦更快了，乾脆用pattern matching做大量相關運算，但也跑不出基本統計法則。假如很幸運要模擬的對象分佈接近常態，那麼到八成以至九成以上的擬真，運算乘本會阧增。是比過去的AI好，但值那個錢嗎？
• 搞不好從大數據到機器學習(machine learning)，都是賣CPU跟GPU的產業自己推動了，不然人類實在不需要那麼快的運算啊。

vendor locking

昨天聽了NetApp的產品介紹，很酷。但跟EMC一樣啦，很貴，而且vendor locking。代理商回答的妙：你可以不被A代理綁，轉跟B代理買啊。我不是問這個啦，而是NetApp撐不住怎麼辦？EMC都賣給Dell了，老大哥storage營收逐年下滑，這才是憂心的。列舉不錯的特性如下。

• Auto support。偵測到硬碟(或其他模組？)問題，代理商於四小時內寄備品過來。
• force shutdown. 該換的硬碟沒換，短時間內強制關掉storage等候救援。
• redundant. 重要的元件如controller，至少雙備援。
• 4U chassis 可以塞 48個3.5"硬碟。 

value of quantity

流量價值作細起來，其實也會進入某種分眾概念，只是他是先聚眾再分眾。因為流量廣告效益要好，其實版位大小型態，都會分很細，Google DFP的複雜度不亞於Analytics，才會達到廣告效益極大。所以又可區分為：

• 先分眾再大眾。Analytics入手，抓一批分眾再抓另一批，資源投入比較按部就班，但規模成長限制大。這通常是內容主導產業。理想的王道。
• 先大眾再分眾。DFP入手，抓一大堆再來分批，資源投入大且猛，爆量快，但後續回收期要承擔爆量後的缺口。DFP專家也需要早期投入，否則垮的也快。通常是通路主導產業。一統的霸道。

quality vs quantity

質量兼備，這是做內容產業難顧的兩難。如何取得微妙平衡，是賺賠的關鍵。

• Content is King. 這多是從品質角度出發，鎖的是分眾。需確認分眾族群是否大到足以支持公司經營。
• 流量價值。抓的是大眾，包含多種分眾，TA分散。做的是影響力，從邏輯階層似乎事先發傳單(大眾)再到精緻化(分眾)，但產品力量分散快，目標游移。

Go language

最近接觸到Go這個語言，才知道Google竟在語言超多的現在，又推了一個東西出來。作為MIS，看了他的Tutorials並實作後：

• 不適合scripting。對懶人而言，剪貼perl, python, shell scripts 快多了。應該是對開發者比較有用。
• 跨平台超好用。在Linux與BSD上面，語言有套件可裝，也可以幾乎無腦編譯。之後整合抓git編譯想用的軟體也超級方便，編好後就是standalone binary，佈署超有利。 

GCP NEXT 2016

有空的話，GCP NEXT 2016的keynotes值得一看。老虛擬人Diane Greene講述了她從VMware到Google Cloud Platform的這段歷程，也提出了GCP的自我定位與願景。

• Security. Because sharing does matter in recent years.
• Machine Learning. Because Crowd Sourcing requires more efficient AI to simplify the flow, with those trained data. Just like AlphaGo.
• Cloud Transition. Helping enterprise to migration their traditional infra to cloud. 

The Innovator's Dilemma

最近讀到的文章引用了著名的The Innovator's Dilemma，這位商學院老師的研究很有趣，發現近世的科技帝國會重複以下循環，以蘋果為例，不到二十年就會面臨大危機。簡言之，可歸咎於1)創始人特性(特權)，與2)科技演變的短週期。

• 創始人有好的發想而創業，通常破壞性創造(顛覆過往的game changer)才會大成功。沒有歷史資料或數據可依循，靠的是天才創意。如發跡於1976的Apple。
• 經過幾年的生產，產品從粗略的構想日漸成熟，如Apple I, II, 直到1984的麥金塔。事業到達巔峰。
• 創新停滯，低價模仿貓紛紛跑出來。除了「啟發於」(2012年三星反駁蘋果抄襲控訴的經典詞彙，啟發，不是抄襲喔) 創始人的創意之外，也同樣走上「粗略」走向「成熟」的生產模式，幾年後產業大為蓬勃。
• 幾年後到了Windows 95，也有不錯的UI，軟體也夠多。無法繼續創新的Apple面臨危機。後繼的CEO們紛紛詢問市場的意見，倚賴大量MBA的操作。日漸沉重的營收壓力逼的他們只能盯好數據看，因為大家懷疑他們的「創意直覺」是否能超越創始人。悲哀的二代包袱。
• 賈伯斯於1997年回歸。整頓既有生產線，並於2001年推出顛覆唱片業的iPod生態圈。老牌的Sony完全錯失這個良機。Apple變成一家賣音樂賺大錢的公司，超快速的IT轉型。
• Apple繼續推出顛覆性產品，甚至顛覆到自己的生產線，以保持大幅領先的優勢，並由此繼續壟斷封閉生態圈賺大錢。iPhone衝擊了iPod，iPad衝擊了Mac。
• 庫克於2011年接手帝國。面對日漸失去的創意領先優勢，專業經理人於2012年開啟對三星的專利大戰，並由iPhone 5c一路降價到SE，6變大到6 Plus，「傾聽著市場需求」，對抗著群雄並起的模仿貓們。庫克講出了「..創意需要團隊合作...」的名言，並在2012年iOS map失敗之際，「請走了」不合群的iOS leader Scott Forstall。據說這老兄跟賈伯斯一樣的牛脾氣。Apple似乎走上了97年以前的循環，那榮景只有不到20年的週期啊。
• 二代領袖問市場看數據是情有可原。但如福特汽車的老大曾說：「我要問顧客想要什麼的話，他們要更快的馬」。

steady states

方程組投入初始與邊界條件後，若不收斂就會爆掉。除了方程組天生的本質外，適切的條件限制也可能保障其系統穩定。社會上的例子為：

• <<銀河英雄傳說>>這部考古翻新的架空作品，給出的條件是「帝國」：「同盟」：「費沙」= 48 : 40 : 12。這應該有些考究可經驗證的。
• 三國的孫吳與蜀漢只佔東漢十三州的長江以南三州+化外之地。但中原長經戰亂，北邊州郡不若荊襄與天府之國富庶，可能加減一下可以用上述條件解釋之。
• 桌面市占率 Windows : Unix-like = 90 : (9 : 1)。九成的勢利也是各家品牌割據，另10%的小勢力也形成均衡。
• 智慧市場 Android : iOS = 80 : 20 (各地區很不同，約略吧)，看小勢力遠超過10%，市場也形成均衡。 

direct and oblique

兵法云：「奇正相生」，與「戰勢不過奇正，奇正之變，不可勝窮也」<<勢篇>>。很有趣，因為考慮建模的時候，變數即維度的數量，會影響結果好壞與運作複雜度。聖賢流傳的智慧很有意義啊，孫武一輩子只打過一次滅楚戰爭，其十三篇卻影響後世甚遠，不很類似古哲先知啟悟世人的角色嗎？

孫子流傳千年的巨著，將戰爭勝負這種人類大事，化簡為奇正兩種狀態，可能源於道家太極衍生到八卦，走類似以二為基底羃次運算的機制。若運用在商戰，產品競爭的模型上，是否二維的羃次方程組就可以進行相當的推估呢？這樣可大幅減少不必要的數據運算與推估的資源投入啦。當然可能還是太簡化了，因為「善出奇者，無窮如天地，不竭如江河」，可比日月與四時，循環往復源源不絕啊。

OS Convergense

OS Convergense 是從Ubuntu在發展phone, tablet solutions的行銷口號聽來的。之前未曾聽過別家有這種概念或做法，最接近的應該是微軟家的Windows 10的desktop與tablet mode 整合在一個device上，但真要很漂亮的單介面多用途真的很難。

• Unity一開始的Dock左欄與選單上欄的設計，就可因應各種尺寸大小。從2010年的netbook到現在的phone, tablet都合適。左欄Dock真可算是Ubuntu介面的獨特風格。但至於這個風格的市場接受度與效益，還沒看到正式的評估。
• X到Mir的Window system轉換。目前多數軟體都在X上，要比拼現在App與Play Store一大堆app，就得把上個世紀七零年代到現在的好貨全挖出來，數量上勉強一較高下吧，雖然多數都是Desktop的設計。但從iPad Pro轉攻桌面市場來看，反而在目前純粹phone, tablet市場飽和的現況，Desktop app的老市場搞不好變成一條新路。
• Desktop vs. Mobile mode. 這個轉換與定位很重要。Windows 10有tablet mode，而Ubuntu touch 近期推出multi windowed  preview. 雙模式的轉換流暢度因應不同的消費者行為，目前都只能鎖住各自的小眾市場吧。Windows與Ubuntu還是以桌面市場為大宗。
• iOS與Android就不用談了，他們所有的概念都是mobile優化，做的非常好了。但也正因為單方面優化，不可能再優化另一面，那就四不像了。當然這就質疑到一個根本問題：OS Convergence有必要嗎？面面俱到的effort不少，能抓到多大的市場？只能說，大家還在try，至少手機跟平板的市場是飽和了，不try也賣不出更多。

hybrid backup

有效的資料備份之前，要落實資料分級。這樣，才能回答多重要的資料，備份頻率要多高，要用多少成本的方法備份。備份頻率與數量定下後，由各單位組長督導備份作業的落實。資料備份是有效對抗檔案綁架或損毀的方法。

• SAN, SDS array, Object Storage (Online)：相對昂貴，集中且架構強健的方案。
• RAID array (Nearline)：balanced, affordable. NAS型態的備份，承載適中，擴充適中。
• Single HDD：大家都會的單碟備份，技術與設備成本最低，但人力與行政成本最高。

混合式備份，可讓TCO降到最低，CP最佳化。

weather forecast

洪老師這篇概論可以看看。不過他著眼短期預測，所以初始條件的誤差對差分方程，具有決定性影響而造成一週以上天氣不可預報，也造成颱風這種幾日週期的預報很難做好。更長週期如季預報就是另一個尺度的故事且更慘，近期跟防災單位的學長聊，預測率還是只有四成左右，比躑銅板還差！！真是...雖然這讓研究單位有寫不完的論文可以發表，但也彰顯科學方法真是很無力。 http://mail.dali.tc.edu.tw/~earth/dali-earth/chapter/ch8/forecast1.htm http://mail.dali.tc.edu.tw/~earth/dali-earth/chapter/ch8/forecast2.htm

Device Repair

身處IT代工王國，就是只要可以拆解，品牌設備的零件基本都可以更換。畢竟很多品牌的零件就是這裡出來的嘛。這樣，進行公司的營運持續計畫(BCP)時，就可以考慮這個有利條件。

• 古老時代的compatible HDD model。
• 內建電池 /充電板。
• 面板，按鈕。林林總總。
• 而且，能進行維修服務的廠商可真多。Time Span可以拉長到十年吧。呵呵。

Nearline Backup

可以給用戶一對一的硬碟，定期做sync來進行Offline Backup。若是小型協作環境，需要Nearline近線存取，那這種一對一的架構就得建在伺服器端了。雖然架構不是很酷，但長遠看非常實用，因為很酷的管理架構的controllers, management這些元件，時間跑長了也得輪換，就多出額外的成本啦啦啦。

• 開NAS做share folders。
• 使用單碟進行對應。
• 仿照Offline進行backup。

Instant Articles

Facebook推出了Instant Articles。乍看之下很酷，用戶可以用超快的效率在臉書上獲得內容，出版商也能從文章廣告獲利。但其實在原理上，跟把影片上傳YouTube有同樣考量，就是把內容送給社交平台，然後雙方拆潤。那麼，來源內容的網站流量必然降低，這要如何平衡呢？ 測試是沒有問題的，如果變成趨勢那也得順潮流因應。

Instant Articles不會將內容重導至來源內容網站內。流量就是留在FB中，廣告我們能分到錢，GA可以嵌入，這沒得說的。但是，用戶就是留在FB看的很高興，不需要進入內容來源平台了。長遠看，需要考慮這個問題，就需要把FB視為內容平台的一部份來經營，而不只是行銷的平台。 然而，經營多平台最需要考慮的重點之一，就是這些平台互相可能爭搶用戶，所以平衡計算平台間露出的消長，讓總利益達到最大，就是之後會要面對的課題了。

prediction modeling

最近繼續在思考預測模型的根本，想到上學時期的理論，其實就是受到以下幾個條件影響。

• 方程組。就是控制預測的機制，複雜一點非線性就不好求得解析解，得靠數值方法來積分了。
• 初始條件。沒有解析解而要讓方程組動起來，就得代入第一套變數值才能開始動吧。但初始條件有偏差的話，預測結果就歪掉了，隨著時間的推移可能愈偏囉。
• 邊界條件。這通常也要給，例如在空間上有截斷的時候 (我喜歡週期函數就是不斷循環啊超棒)。而且長期穩定的系統，初始條件的影響就不重要了，時間跑長了就穩定了。

所以喔，以前就容易聽到，決定性因素就是邊界條件。但這是立基於法則也就是方程組不變的假設喔。如果造物主有意改變法則，像是大洪水或是「明天過後」天降大龍卷那種極大天災，就變成法則本身決定了最終結果。相位改變了，就像水有三相變化，每一相的法則不同，你就得跳躍到另一個phase才能繼續描述物體隨時空而變的狀態。
物理定律在空間上，如宏觀與微觀空間就有差異了，如測不準原理闡述一物多處的存在狀態，若我們把空間軸改拉向時間軸，那麼長時間的差異不也會造成如上差異？只是物質會隨時間風化，很多東西等不到那個差異發生(長週期)就已經結束了自身循環(短週期)。所以只能從文獻或考古得到一點點文明歷史的資料，也就很難建模。那沒有模型怎辦呢？從歷史文化的角度來看，法則是先天存在的，聖賢們傳達的規範或預言，「順天應人」似乎就是最佳解。古往今來，人要找尋的天命應該就是如此吧。

content data grouping

最近分析發現，愈有特色的內容，對應的分眾可能愈區隔。這樣，要吸引到不同群體，就更要下功夫在茫茫網海中找到他們。網路無所不在，數據到處都有，仍須我們發揮CSI的精神，更精準辨識出觀眾輪廓，才能找到對應的商業效益。

• LINE，在發送群體與內容要篩要驗證。
• Facebook，粉絲團勤開，內容區隔，廣告宣傳區隔。

Object Storage

最近發現Object Storage很有趣也方便，主要他不依賴於Compute node (aka. EC2 in AWS)而獨立存在，單獨用起來有他的方便性。

• 不像File Storage可以直接掛載，搭配Compute就比較不方便了。不過他的目標就是object I/O嘛，掛載來用就不對了。performance也會不好。
• 可以考慮跟File Storage搭配作為Near-line backup，或是Simple Web Service。因為是物件型態的，每個物件給出單獨網址挺方便。靜態網站很好用。
• 過去沒有IaaS的時候，大概就是用FTP/HTTP混搭的檔案管理方式，用戶會需要簡單HTTP協定下載。後來Dropbox, Google Drive這些服務都強化了這種檔案傳輸與管理的概念。

Check_MK RAW edition, part 6.

Check_MK前陣子釋出1.2.4p16的更新，包括Multisite跟agent的部份。雖然只是patch release (p16)，但agent部分的path更動與auto inventory又增加囉。這麼勤快的更新，值得密切注意新增功能，以及大量部署的時機。

• Multisite部分，由於已經有打包好的rpm/deb，理應照package upgrade流程就可完成更新。
• agent部分，手動更新挺費事，好在像EPEL這些repo也會更新check-mk-agent。所以，agent若能統一也用repo管起來，大量部署比較理想。

Patching from source, part 2

要自己編譯的東西，真要看時機看場合。還是總體C.I.A(保密，完整，可用)來評斷吧。

• 組織的大量部署，用大廠支援的打包驗證機制，至少兼顧I(較不易竄改)與A(部署快速)。
• 若部署的是自家的產品，I.A.就比較累了，需要常駐的機制或團隊維護，而C(不委外)是比較高些。但若I.A.顧不上，還是用大廠的現成包裹吧。
• 如果是大廠不支援，也不是自家獨門絕技，卻還要自己編的東西，那就不一定適合大量部署了，因為同時滿足上述兩者的缺點，I.A顧不上的情況，就只能小範圍使用。

kernel debugging

risk management做細了，發生頻率低的事件也會需要查，才能保證SLA達到99.9999999....%之類的。現在的OS kernel是都很穩定了，但偶爾在些機器上會發生。以前都就當作偶發硬體問題重開機了，或是記憶體之類的錯誤。但細緻些，kernel debugging最好做做...這樣的話，更動少，團隊強，穩定度高的kernel應該做起來比較happy一些。

• OS跑在實體硬體上，是可能為硬體問題。或是驅動不夠好造成。
• OS跑在VM上，這之前看OS hackers在抱怨，虛擬層也可能有不相容問題，而OS都是根據實體硬體來寫的。誰知道你虛擬技術「虛擬」的硬體，反應是否跟實體確實相同呢？這樣我其實不是debug我的OS，而是debug你的ESX或是KVM了。不過好在這些full virtualization的技術算是很成熟了，舊版OS真還有問題，升到新版OS與hypervisor應該就OK了。

Patching from source

資安三大法則C.I.A (Confidentiality保密性，Integrity完整性，Availability可用性)的兼顧，往往是互相衝突的。就拿OS或軟體patching來說吧，大量部署保障了可用性，但patching就得用package打包才來得及，而這些binaries是否會在過程中受到污染？進而影響了C與I？
另一個極端是保障C與I，乾脆每個patch都從源碼開始檢視，再加密簽署，自己編譯才部署。哇，效率大為降低，A就保障不了了。
所以看來，資安管理還是首要得做的，從風險評估來看，不同的系統得用不同的C.I.A來對待吧。

Cloud cost

其實雲服務不便宜。除了在自己機房或辦公室裝機器的帳面cost最低之外 (TCO不一定低)，還可以考慮租外面IDC放自己的機器，也會比租雲便宜一些。
而且資安的東西，資料完整性的保障，基本還是得自己做。雲服務只能說是提供很強悍的Infra，但你資源租不夠，DDoS還是擋不住，備份沒做好還是會lost資料。因此根本上的管理還是得做好，資料分好級，愈重要的資產用愈貴的投資才合算。

user local backup

Windows用戶的資料，若MIS少而用戶多，資料結構又不夠規範的話，從風險管理的角度，就直接讓他們進行local data backup吧。

• 一個硬碟備份一個硬碟。如同RAID-1的保護等級。
• 找個桌面sync軟體，讓用戶來做這件事。
• 定義備份週期，規定多久做一次。
• 利用用戶電腦閒置期間，例如休假日來跑。這樣能保障週期性備份，也不耽誤用戶工作時間。

risk periodicity

在學校時做分析時，就常用週期性函數來進行matching。世間萬物也確實是周而復始，或許週期性是現代科學最容易進行預測的手段吧，所以應用上就形成這樣的傳統，或許也是歸納演繹方法的衍生吧。當然，對於大型變動如天災的預測就很差，畢竟頻率低，樣本又少吧。

• 三角函數的Sine, Cosine這種協和函數很易懂。正弦餘弦又正交，但不容易只用前幾個項就很好matching到我們的pattern。解釋變異度可能不高吧，除非現象本身類似normal distribution之類的漂亮分布。
• 經驗正交函數EOF，用最小平方法找出一組組正交向量。理論上是找前幾項matching的好選擇。一個變數不夠，用兩個變數來SVD或多變數EOF之類的。

不過除非是複雜的自然界現象，社會或人事物之間的互動，用簡單的週期函數好像就能適配很好了。因為人際互動通常會遵循倫理或規範，物質的風化也通常遵循物理定序。

Cloud Storage

能夠協作的雲端儲存是專案團隊的最愛。這幾天比較了幾家的產品：

• Dropbox. for Business的權限管理功能夠完整的，又能跟個人帳號分開同步，只是有點貴，每個授權要US$15. 每個給1TB。你愛怎樣交錯組隊分享甚至遠端刪除都可以。
• Google App. 給30GB，要1TB月付十塊，比Dropbox支出彈性。同步功能不知道如何就是了，權限管理倒也夠強。
• AWS。用S3自架Owncloud之類的，價格會跟Google App差不多唷，只是S3 instance上限256TB，客製的彈性很大。