[Vim] Vim installation on Windows and Mac

Windows (Use portable GVim)

1. Extract GVim_Portable.exe to Program Files
2. Rename GVimPortable.exe to vi.exe
3. Add path to environment variable PATH
4. Copy the pre-built cscope binary and related dll to folder where vi.exe exists
5. Put wombat.vim to C:\Program Files\GVimPortable\App\vim\vim71\colors
6. Add below at the top of vimrc

colorscheme wombat
set guifont=Monaco:h12

Note:
1. vimrc in C:\Program Files\GVimPortable\App\DefaultData\settings
2. put autoload_cscope.vim and cscope_maps.vim to C:\Program Files\GVimPortable\App\vim\vim71\plugin
3. Don't put the project root folder in path with spaces

MacOS (10.7.1)

1. Download macvim source from github: https://github.com/b4winckler/macvim
2. Download cscope from sourceforge: http://sourceforge.net/projects/cscope/files/
3. Refer the readme to build cscope, maybe you will get some errors like below:

if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT build.o -MD -MP -MF ".deps/build.Tpo" -c -o build.o build.c; \
    then mv -f ".deps/build.Tpo" ".deps/build.Po"; else rm -f ".deps/build.Tpo"; exit 1; fi
In file included from build.c:50:
/usr/include/ncurses.h:550:40: error: macro "cbreak" passed 1 arguments, but takes just 0
/usr/include/ncurses.h:575:44: error: macro "erasechar" passed 1 arguments, but takes just 0
/usr/include/ncurses.h:611:43: error: macro "killchar" passed 1 arguments, but takes just 0
make[2]: *** [build.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

4. How to fix it: Add the #undef and #define lines in the middle of this chunk of code in constants.h

#if (BSD || V9) && !__NetBSD__ && !__FreeBSD__
# define TERMINFO 0 /* no terminfo curses */
#else
# define TERMINFO 1
#endif

#undef TERMINFO
#define TERMINFO 1

#if !TERMINFO
# ifndef KEY_BREAK
# define KEY_BREAK 0400 /* easier to define than to add #if around the use */
# endif
# ifndef KEY_ENTER
# define KEY_ENTER 0401
# endif
# ifndef KEY_BACKSPACE
# define KEY_BACKSPACE 0402
# endif

# if !sun
# define cbreak() crmode() /* name change */
# endif

# if UNIXPC
# define erasechar() (_tty.c_cc[VERASE]) /* equivalent */
# define killchar() (_tty.c_cc[VKILL]) /* equivalent */
# else
# define erasechar() (_tty.sg_erase) /* equivalent */
# define killchar() (_tty.sg_kill) /* equivalent */
# endif /* if UNIXPC */
#endif /* if !TERMINFO */

5. Put the built cscope to usr/local/bin

...

[OO] association, aggregation and composition in UML

UML 描述類別彼此間的關係，有三種表達方式: Association(關連), Aggregation(聚合) and Composition(組成)。

簡單來說，Aggregation(聚合) 是 Association(關連) 的一種特化；而 Composition(組成) 是 Aggregation(聚合) 的一種特化。

Association(關連)：表達某類別中的方法參數是另一類別，或是某類別持有另一類別的指標/參考

Aggregation(聚合)：表達一種 "has-a" 的關係，但是不是獨佔的 (也就是說某類別擁有另一類別，但是其他類別也可以擁有該類別)

Composition(組成)：類似 Aggregation，但是更加嚴格。某類別擁有另一類別，並且掌管另一類別之生死。當該類物件被 delete，其所 "has-a" 類別也跟著死亡；並且是一種獨佔關係。


參考資料：
1. Design Codes: UML Class Diagram: Association, Aggregation and Composition
2. (原創) association,aggregation,composition有什麼差別?

... ...

[DP] 繼承或合成, composition 搭配 strategy pattern 範例

簡單明瞭的機器人遊戲範例，清楚說明了 composition 搭配 strategy pattern 的強大，推薦閱讀！

繼承關係在面臨父類 介面更動 需求時，顯得不堪一擊。採用繼承的關鍵是子類 "is-a" 父類，但 更重要的是，這個 "is-a" 的關係， 是否在開發週期間恆常不變 ，如果不是的話 composition 是更好的選擇！

Don't use inheritance just to get code reuse

Don't use inheritance just to get at polymorphism

當 上層類 依賴於 組件類 (composition)， 不讓 上層類 直接使用 組件 instance，而是使用一個抽象介面 ，那麼就可以達到 run-time 決定選用不同規格的組件 (因為他們都實現相同的介面)，更大增加了彈性，這就是 Strategy Pattern

參考資料

1. Inheritance versus composition: Which one should you choose?
2. Android Game Development - Design In-game Entities - The Strategy Pattern

... ...

[DP] Dependency Inversion Principle 依賴倒轉原則

1. 高階模組不應該依賴低階模組，兩者都應該依賴抽象

2. 抽象不依賴實作細節，實作細節依賴抽象

幾個網路上的文章說明的蠻清楚的，在這邊筆記一下！

1. 控制反轉（Inversion of Control）介紹 | Java頻道

2. Dependency Inversion Principle | Object Oriented Design

3. What is Dependency Inversion? Is it IoC? – Java Code Geeks

— EOF —

[Java] Access Modifier in Java and C++

物件導向主要精神之一就是封裝，於是牽涉到了 "public", "protected", "private" 這些存取權限控制的關鍵字。和 C++ 相比 ，Java 當中又多了 package scope 的概念。

C++ 的 namespace 和 Java 的 package 有什麼不一樣呢？我的理解是，namespace 只是將一群 class 打包起來，並不涉及 classes 彼此之間的存取權限；但是 package 在 Java 當中是預設的 scope，如果你不為 class member 指定 access modifier 的話，預設就是 package 存取權限 (即在相同 package 之內的所有 classes 都可以存取該成員)

今天在聽同事介紹 Java 繼承的時候，讓我產生了一些困惑。

在 C++ 當中使用繼承時，會在父類別前面加上一個 access modifier，這個 access modifier 定義了父類成員繼承至子類時，所能對外被存取的最大權限 (父類的 public 成員如果用 protected 繼承給子類，那麼子類從父類那邊得到的該成員對外被存取的最大權限就降至 protected)

但是 Java 當中的繼承似乎沒有 access modifier 這件事，就是單純的使用 extends。更令我驚奇的是，父類成員的存取權限到了子類當中竟然還可以變得更開放 (這不是跟 C++ 相反？)

請看以下頭的程式碼中，Base class 有四個不同存取權限的 method，繼承到 Derived 後，凡是將存取權限放寬者皆 OK，將存取權限降低者皆編譯不過。：



這不禁讓我想到，Java 有這種針對各個成員函式調變對外存取權限的能力，而 C++ 卻只能用 access modifier 定一個最高門檻？於是，Google 了一下竟發現，如果你是用 protected/private 繼承的話，是有辦法把部分因 access modifier 降級的成員函式提昇至 public 的，請看以下程式碼：



在 Test::test() 函式當中可以看到，Derived1 類是用 protected 繼承 Base (改成 private 也可)，所以對外是無法存取他的成員的，但是 Derived2 類利用 Base:: 的方式，讓因 protected 繼承而改變存取權限的成員，又成為 public 了。那會想說，可不可以連同把 Base 類當中的 private 成員也變成 public，可以看到在 Derived2 類當中的嘗試，是不行的！

雖然經過實驗大概比較清楚 C++ 和 Java 繼承對於成員物件的影響，但是我依舊不明白，C++ 越繼承對外權限越小，而 Java 越繼承對外權限越大，這兩個相反的設計思考是怎麼樣的考量？

石頭的回答：
這個我直覺的認為是基本上 C++ 跟 Java 的 objec​t model 的差異。在 C++ 中如果父類別的 public method 被子類別改成 private，client​ 只要轉型成父類別就可以操作 method。在 Java 中所有繼承都是虛擬繼承。

關於 C++ Namespace 和 Java Package 的討論可以參考：
1. C++ Namespaces, comparison to Java packages | Stack Overflow
2. Java packages vs. C++ libraries | Stack Overflow

關於 C++ access modifier 可以參考：
1. inheritance - C++ subclassing access modifier? | Stack Overflow
2. Inheritance: private and protected inheritance

關於 Java 類別成員存取權限可以參考：
1. Controlling Access to Members of a Class

[Note] Android 使用者介面設計競賽之賽前聚會 筆記

SPB Software

這家公司主力產品是一個 UI 的 3d Engine，一款產品叫做 SPB Shell 3D ($14.99)，研發總部在俄羅斯

UI Element

1. Speed
2. User Friendly
3. Stability
4. WOW

End User Viewpoint

1. Fancy
2. Fully Customized
3. Full Functions
4. Free

Branding Viewpoint

1. Engine (3D Engine)
2. SDK
3. Customized Version
4. Something Different

ODM Requirement (SPB UI Builder)

1. Customized Tool
2. Different Model
3. Cross Platform
4. Low Cost

遠傳 Roger Chen

1. Art is about expression, not UI, UI or UE
2. Design is about achieve goals and resolve problems
3. Designe (User Interface and User Interaction) for User Experience
4. 根據用戶的興趣、需求和「動機」提出「原創」且「巧妙」的回應，就是設計！
5. 對於可利用的「裝置」進行盤點，每個裝置都可以「行為」的思考模式跳脫裝置外在的用途，例如 (吹 -> 麥克風)
6. 音效很重要，配樂則讓用戶想像一個情境/舞台
7. 互動的兩個層次: 1. 故事性 2. 物理性

勤崴

UI 設計的一些 guidelines

1. 系統狀態的可視性
2. 系統和現實的相似性
3. 使用者控制和自由度
4. 一致性/標準化
5. 避免錯誤
6. 辨識而非記憶
7. 彈性以及使用的效率
8. 從錯誤中復原

工研院(莊國煜)

Open GeoSMS SDK 介紹：一個簡單的地理位置交換 protocol，以簡訊的方式傳遞，可以跨平台各種手機通用！

... ...