[轉載] 為什麼分紅費用化對員工不好呢?

查資料時看到看到的，蠻好的解釋了分紅費用化的狀況。

重點：

1. 過去股票紅利是照面額計算 (Ex. 分紅10萬，相當10張股票，但是股票市值往往遠超過面額)
2. 依據上一點，「面額」及「市值」之間的成本便由小股東承擔了，也造成每股盈餘不明的情況
3. 費用化後，因員工配股張數是以「分紅金額」除以前一年最後交易日的股價

如何寫出 User Story

什麼是 User Story?

User Story 是一段簡單的功能敘述，以 客戶或使用者的觀點 撰寫下有價值的功能(functionality/feature)。與其說它是規格文件(documentation)，不如說它代表(represent)客戶的一個需求而已，因為實做細節將延後至開發時才會確定。

幾個 User Stories 的範例如下：

• 使用者可以在網站上張貼履歷
• 使用者可以搜尋有哪些工作
• 公司可以張貼新工作
• 使用者可以限制誰可以看到他的履歷

Deferred 與 Promise 的差異

在談Promise 之前，我們先來了解一下 CommonJS.org

CommonJS.org

CommonJS 是一個致力於將 JavaScript 生態圈標準化的計畫，尤其是針對瀏覽器以外的應用環境，也因此第一個版本的名字叫做 ServerJS。
CommonJS 的終極目標是制定一個像 C++ 標準庫一樣的規範，也就是介面，使得基於 CommonJS API 的應用程序可以在不同的環境下運行，就像用 C++ 編寫的應用程序可以使用不同的編譯器和運行時函數庫一樣。為了保持中立，CommonJS 不參與函式庫的實作，而是交給像 Node.js 之類的項目來完成。

而不少開發者向 CommonJS 提出 Promise 的規範草案，但是一直未被列入正式規範，有著 Promises/A, B, KISS, C, D 等版本。其中以 Promises/A 的提案最為簡單，也最常被大家提及。

值得一提的是：Promise/B, D 的提案人是知名流程控管套件 Q.js 的作者 Kris Kowal

滿有趣的一點是：Node 團隊在前年左右放棄繼續遵守 CommonJS 的規範。Isaac 指出 "Ryan basically always gave zero fucks about CommonJS anyway" ，並轉述了 Ryan 的一句重話 : "Forget CommonJS. It's dead. We are server side JavaScript."
有興趣可以看看這個Github的討論串：https://github.com/joyent/node/issues/5132#issuecomment-15432598
( Issac 是 NPM 的作者， Ryan 是 Node 之父 )

你還在為了UI-binding使用肥肥的Angular嗎？試試這些前端函式庫吧！

從 jQuery 到 Angular

從最早的 jQuery 以後，各種前端framework百花齊放：Backbone, Knockout, Ember, Angular....
其中 Angular 狹著 Google 的大名，可以說是在前端世界中呼風喚雨，但是許多人使用Anugular一段時間以後才發現入門容易但是深入難，而且隨著專案的複雜性增加，也開始踩到了各種地雷。因此也有人用這張圖來揶揄模擬Angular的學習曲線：

UI only

許多人開始發現，很多狀態下他們幾乎只需要 Data-UI binding 的功能，React.js 這個 facebook 御用、注重高效render 的 Library 就開始受到廣大的目光關注... React不是個完整的framework，只是專注於View的Library，因此更輕量、也更能與其他framework整合、相容。React官網是這麼說的：

Just the UI
Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.

但是！

React 推薦使用 JSX 在程式碼中勾勒 template，這點我就真的不行了，覺得髒髒的。所以我實在無法接受 React。

但是幸好這是一個前端技術大爆炸的時代，我們還有很多選擇....

手機網頁必會技巧！HTML meta viewport 屬性

什麽是Viewport

手機瀏覽器是把頁面放在一個虛擬的「窗口」(viewport) 中，通常這個虛擬的「窗口」(viewport) 會比螢幕寬，這樣就不用把每個網頁擠到很小的窗口中（這樣會破壞沒有針對手機瀏覽器優化的網頁的布局），用戶可以通過平移和縮放來看網頁的不同部分。移動版的 Safari 瀏覽器最新引進了 viewport 這個 meta tag，讓網頁開發者來控制 viewport 的大小和縮放，其他手機瀏覽器也基本支持。舉例來說，一個常用於RWD優化過的頁面上，常會有這樣的程式碼：

<meta name=”viewport” content=”width=device-width, initial-scale=1, maximum-scale=1″>

Viewport的屬性

• width：控制 viewport 的大小，可以指定的一個值，例如600或者其他的值，如 device-width 為設備的寬度（單位為縮放為 100% 時的 CSS 的像素）。
• height：和 width 相對應，指定高度。
• initial-scale：初始縮放比例，也即是當頁面第一次 load 的時候縮放比例。
• maximum-scale：允許用戶縮放到的最大比例。
• minimum-scale：允許用戶縮放到的最小比例。
• user-scalable：用戶是否可以手動縮放

其中特別需要注意的是 width這個屬性，比較不容易搞懂。
舉例來說，當你的頁面沒有經過RWD優化，最適合的解析度是960px寬，因此有些使用者拿著螢幕800像素寬的手機時，會無法看到右方160px的區塊，必須進行橫移或縮放。
而你希望使用者無論拿著多大的手機，看到你的網頁時都能夠從左到右完整顯示的顯示網頁內容。於是你就需要設定width為960px，此時無論是480px, 640px, 800px 甚至是 1280px寬的手機，都會調整顯示比例至能完整顯示800px的寬度。
當然，手機的解析度是不可能變的，於是小手機上看到的內容就會比較模糊不清，畢竟他是試圖使用480px來顯示960px的內容。

Reference:

穆乙's Blog: http://www.cnblogs.com/pigtail/archive/2013/03/15/2961631.html