#waveface

Just wrote a lightroom plugin for you to export your photos in Lightroom directly to your Stream account. 

Download the plugin here .

Decompress it, and you should get a folder name: stream.lrdevplugin. Don't change the name, and move it to the folder you keep all your lightroom plugins. 

Open Adobe Lightroom Plug-in manager (in the File menu) and hit "+" to add a new plugin, select the "stream.lrdevplugin" you just got. 

Then, it is done.

For everytime, when you want to export photos to your Stream account, just click Lightroom Export button, select "Waveface Stream" in the drop down menu, configure your exporting settings, and enter your Stream account ID, password, and the message you want to give for this post. 

Enter your Stream account ID and password here. (If you don't know your stream password, check Stream web site)

After it finishes, if no issue happen during the export, you can verify them in Stream web site. 

Feel free to let me know if you encounter any issue when using this plugin. 

Couple years ago, when I started to use Mac, I googled to know what is the best text editor in Mac. The answer comes with Text Mate and Text Wrangler. Until now, just yesterday, the company MicroMates, which develops Text Mate,  opened source it on github. No wonder why they want to open source it, that is because they already lose the marketshare when they used to have chance. But why they come it so long? My colleague Jamie shared me an interesting article: "Textmate 2 and why you shouldn't rewrite your code". 

A true lesson learn, just like the story of Netscape. 

And a more interesting thing is that we just had a conversation about the rewriting of our app during the lunch today. And it is fortunate that we concluded not to do it.

As a programmer, we all trust ourselves then anybody else. But I think the truth is that we all believe it would be easier to understand your own code then others'. Then we all want to choose an easy way, that is why most programmers would rather choose to rewrite the codebase at the first day when they took over the responsibility of maintenance. But when doing so, the end result usually comes with a failure. The reason is obvious, the old code is a collection of wisdom and experience from a lot of people. It would be extreme hard to rewrite all of these in just a few months. At the end, you would find out it wastes you for couple years and come out with nothing, but just a failure. In my pocket, I also had a lot of similar stories from my previous company.

Anyway, we all worked very hard to make our app better, come to download our app Waveface Stream, and give us feedbacks.

這段影片是 Linkedin Engineering Director Kiran Prasad 在 DevCon5 的演講，雖然是老印，但他的英文還不難聽懂，很值得一看的影片。

Linkedin 一向對於他們 service backend 所使用的技術毫不藏私(註)，但這段影片很特別的是 Kiran 幾乎是從頭到尾介紹了 Linkedin 如何建立起服務，內容涵蓋很廣，其中包含了 Visual design flow、service architecture、mobile architecture、API protocol、testing、release flow 等等，包羅萬象，雖然有些只提到皮毛，並未深入，但是確實給了一些 index 讓外人可以窺探 Linkedin 在於 engineering 方面特別的想法。

其中 Kiran 特別深入兩個主題，一個是 Linkedin 服務的 server architecture，另外一個是 client architecture。不意外的，Linkedin 也曾對外多次宣稱，Kiran 提到 Linkedin 背後的服務正是採用 Node.js，雖然目前還有部分的 Web 是掛在 Nginx 之上，但是 Kiran 也提到過不久會移除 Nginx，成為比較純粹的 Node.js。使用 Node.js 的好處不外乎高效能、非同步、單一 process 可以負擔上萬連線等等，Node.js 也提供了機會讓 Client side 工程師可以開發 server side 程式。Linkedin 使用 Node.js 於 Aggregation 與 Formation 上，這其實也類似於目前 Waveface 服務伺服器端的架構，目前 Waveface Stream 也一樣用 Node.js 於服務的前端，利用了 Node.js async 的特性撐大整條水管，再透過 message queue 將更多的高負載處理導給其他 biz logic 節點，這些節點有些需要大量運算，有些不用，有些需要連線資料庫，但不管為何，反正當負載不夠時，多加機器就好，而且要寫這些節點不用局限於何種語言。Node.js 與後端的節點就仰賴 Message queue 串連，而 Node.js 不管對 client side 的 HTTP request 或者後面的 message queue 都是用 async 的方式，Node.js 也負責 session management 跟 data aggregation。以影片中 Linkedin 的架構圖來看，雖然看不出來他們是怎麼串連 Node.js 與後面的節點，但是感覺起來相差並不遠，我想這應該會成為以後 server side architecture 的主流架構之一。

此外，Kiran 提到的 Screen-based JSON 也是很有趣的，API 的資料欄位是以 client side 的 UI 設計為取向，這麼做的好處是整個伺服器就等同於 MVC 架構中的 Model，當前面的 UI，不管是 Native 或者 HTML，取得 JSON 時，裡頭的 JSON structure 已經可以直接透過 backbone 等架構串成 View。 (Mojito 也是這樣嗎？)

最後，Linkedin 的 Mobile 架構設計也是相當引人注目的。Kiran 在一開始就宣稱 Linkedin 的 iOS app 只有 30% Native code！這不禁讓我再次下載 Linkedin app，再好好的玩一次！我相信很多人經歷過 PhoneGap 的慘痛經驗，以及 Facebook 的爛 UI，一定不敢相信 70% 的 Code 是用 HTML + JS，還能達到順暢的瀏覽介面！事實上，實際用過之後，一般使用者很難感覺出來裡頭用了很多 HTML 元件。用 HTML 寫 UI 有何麼好處？當然就是開發快！每次修改不用重新編譯！而且容易更新！一個 app 的開發時程可能都高達 3-4 個月，其中會歷經無數次介面的修修改改，每次修改都是痛苦的，採用 HTML 幾乎可以讓 designer 立刻看到改完的結果，甚至不需要直接載入到模擬器或者手機中就可以先對最後的呈現結果有個了解。但是以往，用 WebKit 跟 HTML 去呈現 UI 最讓人痛苦的就是效能不彰，雖然我個人是認為這是 problem solving 跟 performance tuning 的問題，但我也知道有兩派爭擾不休，有支持 Native code 的人，當然也有支持 HTML based 的人，而 Linkedin 的的確確讓所有人看到其中一種可能！

用 HTML 來寫 client side 程式另外一個好處是，大量的減少程式碼重複的問題，以 Linkedin release 的 iPad app 來說，同樣有相當大的比例是 HTML + JS，連 page-to-page 的 sliding 都是 CSS3 sliding 做成 (Waveface 同樣的效果是用 Objective-C native code)，實際用過之後，絲毫感覺不出這是 HTML based 的效果，而且同樣的程式碼可以直接放到 Web 上透過 browser 去操作，所以 Linkedin 有另外一個網站： https://tablet.www.linkedin.com ，我相信這網站有相當大比例的程式碼是與 iPad app 共用的！

附註：

- Linkedin Engineering blog [http://engineering.linkedin.com/]