航向新世界

第二個位置，很尷尬。
因為監考官一直站在前面...
如果位置和名次有正相關，那就^^

1. SGA Library cache hit ratio > 90
2. Data Dictionary cache hit ratio > 90
3. Data buffer cache hit ratio >90
4. Redo log cache. requests/entries 要小
5. Redo log 個數. 循環頻率. 在循環前需完成 archive
6. 大資料量表格獨立tablespace
7. 大資料量表格索引獨立tablespace
8. 存取頻繁的表格獨立tablespace
9. 避免多量的extents
10. 檔案可放在高速的硬碟上
11. Auto PGA

難過!   南懷瑾大師與世長辭

當我們已經確定了系統改進的目標之後，系統分析者需要將這些目標轉換成為為了達成目標所需的功能性需求與非功能性需求的大綱。
功能性需求經常以滿足系統改進目標所需的輸入、流程、輸出以及儲存資料與控制等觀點來確認。
非功能性需求的實例包括效能、容易了解與使用；預算與節省費用；安全性與審核控制等等。

系統擁有者
系統使用者
系統分析者
系統設計者

1.不要使用 malloc 動態宣告大塊記憶體
a.改用 calloc
2.不要一直 memset 大塊的動態記憶體
a.改用先 free 再 calloc
3.不要使用 fopen 來判斷檔案是否存在
a.改用 fstat 或 access 來判斷
4.不要額外使用 strlen 計算字元陣列長度
a.新的字元陣列產生當下順便得到新字元陣列的長度
5.不要使用 strcat 或 sprint 來串接字元陣列
a.改用 StringBuffer 或 指標串接
6.不要直接比較兩組字元陣列
a.改比較 int
7.不要在迴圈中重複計算不會改變的資料
a.先在迴圈外計算完畢
8.不要使用迴圈 one-by-one 的方式複製陣列內容
a.改用記憶體複製
9.不要在大型陣列中做查找行為
a.改使用 hashtable
10.不要讓大塊的記憶體被 swap 出去
a.可鎖住記憶體不被 swap
 

在 Scrum, 我們會在 Sprint 活動中讓團隊的成員對每一個 User Story 進行預估.
期間若對 User Story 的目的不清楚, 則須請 Product Owner 再說明。
瞭解後再進行細化、拆解。之後團隊成員再對 User Story 下的 Task 進行開發的認領.

MAGMA 好看, 超熱推薦 ^^
裡面有段對話, 記不是很清楚, 大概是說 "公司政策上..... , 以上是公司的意思; 我個人的意思, 我將賭上你的熱情 ..."
很有感覺, 有多久沒有遇到這樣的主管.
回想起來只有那位 IBM 主管呀 ...

這麼久了才注意到用 List<T> 裝未排序的資料.
若用 List.Contains(T) 來確認某個資料有沒有存在 List 中.
其所使用的是線性搜尋, 時間複雜度為  O(n) 

jdbc:oracle:thin:@
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ip)(PORT = xxxx))