2014年7月16日 星期三

永恆的愛情 – Based on Fourier Transform




每個人或多或少都會期待一段永恆的愛情,

想像某個人能帶給你各種不同的感受,

這個人可能包含很多種讓你心動的元素,

像是你覺得她可愛、有趣或是善解人意等等,

總之,她牽引著你各種情緒.

但若這樣的愛情如果不存在怎麼辦?



那麼我們仔細的去檢視所謂的愛情,

所謂的愛情是由許多不同的元素組成的,

可能是外表,也可能是聲音、動作.

或是你們想法接近,她能瞭解你,懂你在想什麼.

在這個時間區段內,你們之間擁有相同/或是你期望的頻率.



既然愛情是由那麼多複雜的原因所組成的,

而又具有時間影響的特性,讓我們難以觀察愛情的原貌.

那我們是不是能借用訊號分析的理論,

把愛情做傅立葉轉換(Fourier transform),

就能從頻率域去觀察愛情是什麼呢?

--------------------------------------------------------------------------------------------------------------------------


於是在此我們做個假設,假設我們透過量化,能得到組成愛情的基本元素/或是頻率值.




那麼是不是只要我們在每個不同的其他人身上,

找到部分的替代元素,

我們就能騙過自己,還原出那個她還在的假象?

那個永恆的假象?

這樣的我們生活就能繼續擁有意義了?

--------------------------------------------------------------------------------------------------------------------------



 這樣做有什麼好處呢?


試著想,我們在單一系統情況下所遇到的問題,

往往同一個系統若承載過多的工作量,

那麼不僅系統負荷會過重,

而且一旦失去這個系統,所影響的情況是非常的嚴重.

代表一次失去所有原本你所依賴的各種元素.



那麼分散式系統呢?

若是我們把所有的元素都分散在各個系統上,

那麼若是失去一個系統,

我們也僅止於失去一個元素,

且能在容忍的範圍內,

再尋找到一個替代的系統,

去彌補這個失去元素.

--------------------------------------------------------------------------------------------------------------------------


最後,

我們需要問的是,

各種替代的元素組合起來,

和讓你所動心的那個人所擁有的全部元素,

是等價的嗎?



假設 ( 特質 f + 時間 t + 空間 s ) = 心動的元素 ℮ ,

由於牽涉到時域的訊號難以處理,所以轉成頻域的訊號來看.

Fourier transform ( ) = f'  , 

而若我們在某個人( P )的身上所得到的總量為 ∑ f',

那麼只要我們能滿足 ∑P() = ∑ f' ,

那麼就能證明愛情是存在永恆的了.

2014年3月18日 星期二

溝通

在溝通的過程中, 我們要確保雙方理解的是同一件事情,
我們首先要確保的是我們所使用的言語形容詞是等價的. 

------------------------------------------------------
但很可惜的是, 由於生長環境與經歷的不同,
我們對於同一個形容詞所要描述的事物並不是完全相同的,
我們在對話的過程中, 希望傳遞的是整體的感受與思想,
但目前並不存在這樣的資訊傳遞方式,
而單單靠詞語所傳遞的訊息, 將會依造雙方背景的不同,存在一定程度的落差.

------------------------------------------------------
慶幸的是, 我們能利用不斷的瞭解與溝通,
設定每個感受的錨點, 去建立量化模型,
來彌補這樣的落差.
也可以根據語言的特性,
計算過去所建立的模型, 來推論未知的形容.

------------------------------------------------------
但即使我們建立了無數的模型,
也經過精密的推算,
若再溝通的當下, 採用了錯誤的模型去思考,
或是過度相信量化的精確度,
那麼仍然無法達到有效的溝通目的,
事情一樣無法解決

------------------------------------------------------
其實每個人都有基本的原型(Prototype)存在,
這使得我們有一些語言的本能, 能進行有效溝通.
但由於經歷與背景的不同,
我們各自建立了許多相似但又不完全相同的模型,
只要我們在溝通的時候,
記得選擇使用對方所建立出來的模型來理解對方所傳遞的訊息,
那麼就比較能達到真正的溝通與同理.
#但要記得確認所採用的模型是不是和對方所建立的一樣.

2014年3月1日 星期六

利用Dropbox當作Server進行遠端訊息傳輸與溝通

因為我的Dropbox 只有小小的空間,
所以每次用Dropbox傳完檔案的時候都要把資料搬到其他硬碟上.
後來就想到把Dropbox當成Server進行資料傳輸的概念.

概念如下圖:


只要把有安裝Dropbox的電腦, 放一個程式(sender/receiver)去monitorDropbox裡面特定的資料夾(command folder),當資料夾有變動的時候,就去讀取裡面的command file, 讀取完以後刪除.
由於為了避免自己讀取到自己設定的command, 所以程式在寫入檔案的時候,在檔名上加入一個GUID, 作為辨識.
而在接收到Sender送來的command以後,Receiver就能自動的將傳送過來的資料, 執行command的動作, 例如Movedata, 將Dropbox裡面的資料搬到Receiver所在的位置對應的硬碟空間.
這樣一來就能利用Dropbox進行分散式資料備份囉.
以下是小小的程式證明方法可行, 遠端電腦測試過.
證明可以利用Dropbox當作訊息傳輸的管道以後,
只要把程式執行Command的dll 檔案拆開來, 用動態的方式載入,
未來也可以做到線上更新囉.

2014年2月21日 星期五

在Windows 8上面執行Chrome OS

介紹在windows 8裡面可以重新啟動Metro的Chrome,
而且會以Chrome OS的模式出現,
所以就試試看囉.
    首先在Chrome的右邊選單選 "在windows 8模式中重新啟動Chrome",
    畫面就會跳到以Chrome OS模式出現的Chrome.

        Chrome OS模式

            接著來試試看OS該有的功能Chrome OS做了哪些,
            右下角Chrome的開始選單裡面放的是Chrome的extensions,
            並且這些extension app由於都是web技術為基礎的,
            因此儲存方式完全是走雲端功能.


              而該有的工作排程和多執行緒,Chrome也有做進去.
              我想最後會分不出來,現在執行的App到底是跑在Web Browser還是Native OS上面吧!



              而這次選測的App是Hobbit,
              看看Web based的App在3D圖形視覺效果的表現如何.
                Google極力扶持HTML5的技術,並且對這方面進行深入的分析
                而從瀏覽效果看起來似乎還不錯.
                我想因為視覺研究和攝影技巧的進步,
                光是平面圖片所創造出來的3D效果就已經有一定程度囉.

                    由於畫面是連續的,
                    就互動體驗來說想當不錯,
                    就擷取兩張圖片來示意一下.




                        結論: Google在Chrome投入的心力和技術已經慢慢成形了,
                        我想這真的是直接偷渡Chrome OS到Windows 8身上,
                        到時候Google真的很有可能因為一堆Cloud相關的產品,
                        而讓人直接在Windows 8上面跑Chrome OS,
                        Microsoft真的很令人擔心.

                        Native C++ and C# Bridge

                        C#有時候因為效能因素,需要和原生C++做溝通,這時候必須透過C++/Cli這個Bridge來做轉換,將受到Manage的Object轉換為Native的Object.
                        •  
                        如架構圖所示,C#可以透過C++/Cli的介面操作,而再由C++/Cli再將Manage的介面轉換為Native的介面.最後NativeC++再直接使用由C++/Cli所提供的Native介面 (此時C++/Cli所提供的Native介面就不能包含Manage的Code)
                        •  
                        下圖為架構圖:

                        Fig 1. 架構圖
                        而在實際的作法上,可以先使用C++/Cli Create一個Native的.h檔案,然後宣告一個無型別指標(Void*)用來存放C#的物件.再透過C++/Cli使用ManagePointer(^) new出一個C#的物件,並將Native Pointer(*)指向C# Object(^).
                        •  
                        這時候,不管Native C++要使用任何的C#function,只要先將NativePointer(*)轉換成ManagePointer(^)就可以操作C#了.
                        •  
                        而C#若要Send Event過去給Native C++,一樣需要先透過C++/Cli將C#的 EventHandle加入Manage的Event,然後在轉成Native的Event丟給Native C++.
                        •  
                        基本上轉換的過程中,都是透過ManagePointer和NativePointer互傳.
                        •  
                        下圖為運作架構圖:

                        Fig 2. 運作架構圖
                        最後附上簡易的 Bridge Sample Code
                        Sample Code
                        ------------------------Native C PlusPlus.h----------------------
                        define DECLSPECIFIER __declspec(dllexport)
                        define EXPIMP_TEMPLATE

                        typedef void(__stdcall *CallbackType)(void*, void*);
                        namespace NativeToMangeBridge
                        {
                             [event_source(native)]
                             class DECLSPECIFIER Bridge
                             {
                                  Public:
                                       void callCSfunction(std::stringmessage);
                                       __event void OnEventInvoke(CallbackType callback);
                                       void * m_ptr;
                             }
                        }
                        ----------------------------------------------------------------------

                        ------------------------Native/Cli.cpp-----------------------------
                        #include "Native C Plus Plus .h"
                        namespace NativeToMangeBridge
                        {
                              Bridge::Bridge()
                              {
                                      CSharpClass^ _CSInstances = gcnew CSharpClass();
                                      m_impl= GCHandle::ToIntPtr(GCHandle::Alloc(_CSInstances)).ToPointer();
                              }

                              voidBridge::callCSfunction(std::string message)
                             {
                                     GCHandle handle = GCHandle::FromIntPtr(IntPtr(m_ptr));
                                     CSharpClass^ _CSPtr = safe_cast<CSharpClass^>(handle.Target);
                                     String^ MgrMessage = gcnew String(message.c_str());
                                     _CSPtr->CSfunction(MgrMessage);
                             }
                        }
                        ----------------------------------------------------------------------

                        ------------------------Cli.cpp--------------------------------------
                        namespace NativeToMangeBridge
                        {
                             Cli::Bridge(Bridge _NativeCPlus)
                             {
                          _CSPtr->InfoChangeEvent += gcnew EventHandler<CSharpClass::EventHandler^>(this, &Cli::function);
                             }

                             Cli::function()
                             {
                                __raise NativeCPlus->OnEventInvoke(_Callbackfunction);
                             }
                        }
                        ----------------------------------------------------------------------

                        ChromeCast 分析 (2) – Launch and Play

                        在找到ChromeCast Device以後,
                        要Launch ChromeCast 內部的App (其實是一個Web),
                        所要做的通訊協定有以下四個步驟,如圖所示


                        在建立起Web Socket以後,
                        對於Multi-Media的控制狀態就由Web Socket來進行即時的雙向溝通
                        Receiver 所用到的Library
                        是放在google自己的空間裡,並且會定期更新和升級

                        而通訊協定的詳細內容與要傳送的資料,可以藉由WireShark這套網路封包分析軟體來擷取和觀察其中的資訊

                        最後,從整體架構來看,ChromeCast 是一個用於google 把數位內容輸出到TV的一個小型嵌入式系統,
                        根據http://www.androidcentral.com/chromecast-rooted-operating-system-detailed 所描述,ChromeCast裡面的OS是一個接近Android的系統
                        並且如果有USB OTG cable和flash的裝置,
                        可以把原本的OS燒入成有root權限的OS,
                        就可以直接透過Telnet連線
                        而ChromeCast所撥放的內容(web page)還是在其他Server上處理,
                        在ChromeCast OS上層應該還有一個類似Chrome的Browser,
                        負責瀏覽主要內容的網站


                        Chrome Cast 運作架構圖

                        ChromeCast 分析 (1) - Search

                        ChromeCast 介紹:
                        ChromeCast是一個USB大小的接收裝置,可以放在具有HDMI輸出的電視螢幕上.
                        它可以讓User從Client端選擇要播放的內容,像是影片或音樂,
                        也可以透過Chrome的Browser 鏡像映射畫面到ChromeCast的Device上.

                        ChromeCast 和 Chrome Browser 之間都是透過網頁的通訊協定再作溝通的.
                        我想是因為google是網頁技術起家的吧,而且透過Web的技術,
                        User experience 提升很多(在網路通順的情況下)

                        ChromeCast 硬體:

                        由於不論是成本或是架構,軟體和硬體的配合也很重要.
                        所以就順便看了一下ChromeCast 的硬體,
                        它是採用Marvell 88DE3005,但由於88DE3005 沒有公開的資訊,
                        因此可以拿88DE3100的架構圖來參考.


                        ChromeCast Browser:
                        ChromeCast本身是一個接收端,所以需要一個負責控制端,
                        如果選擇Chrome Browser當控制端,
                        需要另外下載Chrome extension才能使用

                        ChromeCast 模擬器(Android):
                        由於ChromeCast 在台灣還不容易買到,但上網搜尋了一下,
                        Android App 有模擬器可以用,叫做Cheapcast.
                        用起來跟實體的ChromeCast差不多,但Protocol接收的方式還是有些差別.
                        一開始可以先拿Cheapcast做開發測試.

                        ChromeCast protocol (DAIL):

                        搜尋一下ChromeCast 和 Chrome Broswer之間的通訊協定,
                        可以找到ChromeCast是使用一種叫做DAIL的通訊協定.
                        DIAL的全名叫做 DIscovery And Launch protocol specification,
                        從字義上來看,它是Chrome Broswer去搜尋和啟動ChromeCast的通訊協定.

                        DAIL通訊協定只負責到Launch 完ChromeCast裡面的APP就結束了.
                        剩下的控制部分是用Web Socket的RAMP協定做溝通.

                        DAIL是架構在SSDP (Simple Service Discovery Protocol)的基礎上,
                        在組合起來的通訊協定.
                        所以在一開始,Chrome Broswer是透過UPnP的M-Search做Broadcast,
                        透過Wi-Fi 對同網段的設備發出M-Search.

                        如果有ChromeCast的設備,在接收到M-search的封包時,
                        就會回應自身的資訊和IP位置給Chrome Broswer.回應的資訊裡面包含一些設備描述,和詳細資訊的XML檔案. Search的架構圖: 

                        M-Search的格式如下:

                        回應的XML描述如下:

                        這時候就完成對ChromeCast的搜尋,
                        並且可以得到ChromeCast的目標資訊,
                        接下來就是要Launch ChromeCast 內部的App.