三重先嗇宮(台北縣古蹟)

http://blog.xuite.net/braid.lin/blog/23834831

這是一個古蹟修復工作者的Blog

剛好介紹的是三重的古蹟廟宇 --- 先嗇宮

身為三重人的我~ 真的是有好好的看一下文章的內容

只能說 太專業 太精闢了

若是對古蹟有興趣的話 建議可以看看這個Blog, 真的很讚 :)

閱讀全文...

Google Server / DataCenter (Google 伺服器 & 機房)

http://news.cnet.com/8301-1001_3-10209580-92.html

這篇文章，說明 google 自製的伺服器 以及 像貨櫃屋般的模組機房設計
強者~ 軟體、硬體 都找最 TOP 的人來做 :Q

- 為了省成本、省電、提升用電效率 在伺服器的設計上 使用PC等級的組件
- 沒必要、沒用到的零組件(e.g., 顯卡...) 絕對不會出現在google server上
- server吃電的電壓與供電電壓一致，以免電壓轉換時的能量秏損
- 自制獨家電池式、內建於server上的UPC不斷電系統
- 使用 software 來補足便宜硬體可靠度及穩定度的不足
- 貨櫃屋般的機房，易於模組化的安裝、移動
- 節能且利用自然能量的機房冷確系統

... 看了就知啦 :)

下面這一則，則是 Google Data Center 的影片
Inside A Google Data Center

閱讀全文...

MS SQL Table 佔用空間計算

同事提供的方法，
主要是利用到內建的 stored procedure: sp_MSforeachtable

---

CREATE TABLE #TableSizes
(
table_name SYSNAME,
row_count int,
reserved_size varchar(10),
data_size varchar(10),
index_size varchar(10),
unused_size varchar(10)
)
INSERT #TableSizes EXEC sp_MSforeachtable 'sp_spaceused ''?'''
SELECT table_name,row_count, replace(reserved_size,' KB','') reserved_size,replace(data_size,' KB','') data_size, replace(index_size,' KB','') index_size, replace(unused_size,' KB','') unused_size FROM #TableSizes ORDER BY table_name
drop table #TableSizes
go

閱讀全文...

Google Chrome 影音廣告

下面這隻廣告，是Google Japan Team弄的，會在TV上放送哦 :)


Chrome 廣告合輯(連結)

閱讀全文...

Google: The 2008 Founders' Letter

Serge Brin 在今年Google年報(annual report)內給投資者的一封信

這是從 2004年開始，每年Larry Page & Serge Brin 開始做的一件事

有點像華倫.巴菲特從1977年開始，每年寫給股東的一封信(Buffet Letters)

從這些信件裡面，可以看到公司經營的大狀況、大方向

以下，是針對 Google 2008 annual report 裡，一些有趣的東西:

------

Web & Search:

1990: CERN裡面的 Tim Bernes Lee 為了資訊的分享，發展了全世界的第一個Web Page http://info.cern.ch/

1992: 世界上有26個web sites 了

1993: 每個新增的Web Site 都會post在這個網址http://www.dejavu.org/prep_whatsnew.htm，這時 大概每天增加一個web site

1998: 世上已有以千萬計的web pages了，此時 也是 google 在standford 開始研究search、甚至成立公司的一個開始點

google 首頁，這幾年來愈來愈簡單化了: http://blogoscoped.com/archive/2006-04-21-n63.html.

Books: 可在線上檢索上千萬本的書籍

Geo: 2004年10月買下 Keyhole(Google Earth的前身)後，後續提供Google Earth, Google Maps等服務

Ads: AdWords於2000年發表，2007年4月以31億美元買下DoubleClick，廣告的呈現也從文字、到影像，每年為廣告主創造50億美元的交易

Apps: Gmail 於2001年於Google 內部開始使用，2004年開放對外並提供1G的信箱空間(有別於當時一般webmail提供的 MB級信箱), 後續的 Google Docs, Site, Calendars, ... 都是架設在cloud computing 環境下的應用

Youtube: 每分鐘 Youtube會有15小時的影片被上傳，相當於每週會有86,000部電影長度的影像被上傳

Chrome: 2008年推出了搭載v8 javascript engine的 Google Browser: Chrome

Android: google 在2005年時買下了這家startup公司，並在2007年將android OS release出來

Atificial Intelligence(AI, 人工智慧):

automatic machine translation: 在 1640 個language-pairs 中做語言的自動翻譯

voice recognition / voice search: 語音辦識, 如 GOOG-411(Google Local Search Search)

search quality improvement: 利用既有data使得search品質提升

閱讀全文...

.Net Connection Pooling 問題 - (.Net 1.1 一般網路錯誤/ .Net 2.0 在傳送要求至伺服器時發生傳輸層級的錯誤。 (provider: TCP 提供者, error: 0 - 遠端主機已強制關閉一個現存的連線。)

偉哉 微軟~

透過 .Net default Connection Pooling 機制存取 DB

會有問題，其實不是一天兩天的事了

網路上的論壇 也有提到 這樣的問題 已經三、四年了 但是 一點兒也沒有解決的辦法 亦無一通用的說明及解決方法

在 .Net framework 中，使用connection pooling機制存取DB，依不同 framework 版本 又分下列兩種一般的錯誤訊息:

.Net Framework 1.1 -> 一般網路錯誤
.Net Framework 2.0 -> 在傳送要求至伺服器時發生傳輸層級的錯誤。 (provider: TCP 提供者, error: 0 - 遠端主機已強制關閉一個現存的連線。)
System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) ....

其實，軟體本身就是 unreliable 的東西

若是一味的依錯誤訊息 斷定是硬體、網路的問題 這樣或許太偏執

以上述的訊息來看，一樣的senario 不一樣的 .net framework 居然丟出這樣不同的訊息
就是 .net framework 的一個問題

再者，明明不是網路問題 卻丟出網路錯誤的message 更是該打屁股

以下聽我道來:

* connection pooling 的美意是因為connection的建立cost非常的高，若能reuse 已建立好的connection，則可省下許多的運算資源

* .NET default 就會 by application domain, connection string 有自動的connection pooling機制

只要是在同一 Application Domain下、擁有相同connection string的 connection,

都會share同一connection pool (default: MIN Pool Size=0; MAX Pool Size=100)

* .Net connection pooling 並沒有檢查 connection pool 中 既有connections有效性的機制
透過以下lab實驗，可以證明這件事
a. 透過 .net client 程式透過connection pooling機制query db，可以讓 pool 中保持一定的connection
b. 在 SQL Server 端，將對應的connection 殺掉(透過 kill)
c. 再透過 .net client 程式透過connection pooling機制query db，偉大的.net 就會依framework版本，吐出上述兩種不同的訊息(都跟網路錯誤有關)

* 由以上小實驗可知，.net framework 的訊息 容易讓developer 誤解，以為 是網路的不穩定，但 實際的原因則是，connection pool 裡的connection 本來就不保證一定是可用、沒問題的

* .Net Framework 並不保證 也不會maintain connection pool 內的connection的正確性

其實，我也是深受其害 才會來做這些驗證的實驗的...

以下是當你遇到這個問題時，建議的解決方法:

1. handle sqlclient 的 exception 並適時加入 retry 或其它exception handling的作業

正解

software is unreliable, 既然有 exception 發生的可能性，為何不 catch 它，而要任由它throw出來

殊不知，thrown exception 的 cost 比 handle exception 的 cost 大上十倍以上

且，加上 exception handling code, 在不發生 exception 的狀態下，根本對程式的performance沒影響

百利而不一害~ 幻想偉大的programmer 們~ 為何不去 handle 它呢 ?

2. 避開它， 不使用connection pooling 機制

停用 connection pooling 的機制(在 connection string 上，加上Pooling=false)

既然不用該機制，當然也就不會有該問題發生啦 :)

不過，這是消極的做法，必竟 不做connection pooling 是會降低一些performance的，

尤其是您的系統是忙碌的線上系統時

3. 調整Connectoin String中 Connection Lifetime 參數 (default 是 0, 即 不主動回收)

透過connection lifetime，把一段時間未使用的connection 進行 release 可以降低 long connectoin可能造成的問題，亦可在 traffic burst(尖峰時段) 時段有pooling, reuse-connection的效果

BTW, 這個值 還要再試驗; 另外，exception 還是要handle 的啦~

Connection Lifetime

0

When a connection is returned to the pool, its creation time is compared with the current time, and the connection is destroyed if that time span (in seconds) exceeds the value specified by Connection Lifetime. This is useful in clustered configurations to force load balancing between a running server and a server just brought online.

A value of zero (0) causes pooled connections to have the maximum connection timeout.

下面是我做的另一個實驗，這更加深了我對 .Net connection pooling 機制的懷疑:

測試原理: 透過簡單的 test driver, 分別以 使用connection pooling、不使用connection pooling的狀況下，在一定的間隔，對Database做簡單的操作 (如: select N'ok')

測試設備: 3台

測試時間: 2天

測試架構: test driver -> web farm(3台設備) -> switch -> clustered DB Server

測試結果: 不用connection pooling 錯誤率 0%

使用connection pooling 錯誤率依測試間隔 往上飆高

以上~ 供各位參考

強調: 這只是在我的實驗環境裡的結果，或許有其它設定值的因素 導致這樣的結果

閱讀全文...

Software Testing - 談軟體測試

在軟體發展生命週期中，測試是相當重要的一環

整個測試的目的 是要做到驗證(verification)及確認(validation)的作業

以在下列兩個主要的構面，確認軟體成品的品質
驗證(verification): do the thing right - 把事情做好, 即 驗證軟體是否依技術規格開發
確認(validation): do the right thing - 做對的事情，即 驗證軟體是否滿足開發的初衷(intend)

就軟體價值而言，通過驗證以證明軟體的技術品質是最基本的事
但，能讓軟體發恢價值 則是透過確認的動作 ...

確認的作業，一般發生在需求發展(requirement development)及 使用者驗收階段(User Acceptance Testing, UAT)，在需求發展階段 是要透過各種不同的方法 將軟體的需求誘導出來，並儘可能在該階段 就將需求確認好，因為 在整個軟體生命週期中 需求發展 - 需求分析 - 系統分析 - 開發 - 系統測試 - 驗收 - 上線
越是在後期發現問題、修改需求 所需的effort/cost愈高
所以，這個階段 其實 是最最最重要的

在使用者驗收階段中，則是透過檢視、使用者操作測試的方法 來確認最終產品符合客戶需求

驗證的作業，則強調 軟體生命週期中的各項產出(artifact) 互相間的一致性
即 需求-設計 的一致性，設計-開發 的一致性.. 等
透過層層的驗證檢查，以確保 所有最初的需求都有被完善的被滿足

不論是 驗證(verification)、確認(validation)，我們都會在其中的部分活動面臨到軟體成品的測試

特別在 RUP(Rational Unified Process), XP(eXtreme Programming)等agile development process的概念風行之後

所倡導的 Continuous Integration觀念、Test Spec as requirement 觀念
都在在的強調測試的重要性!!

唯有讓程式(自動化的測試工具/腳本)來驗證程式，才是通往agile development & continuous integration的唯一途徑

否則，在快速且反覆的整合過程當中，若缺乏自動、快速的測式方法，而由人力進行測試的話，將會花費許多時間人力、難以掌握測試的品質及一致性、亦會扼殺了人類的價值 (讓人一直做重複的事情跟操作)

一般軟體的測試工具 不勝枚舉，個人知道的有下列的工具
做Unit Test的有: JUnit, NUnit, ...等 *Unit 系列
做Functional Test的: QTP, WebDriver, Selenium Core/IDE/RC, ... 等
做Performance Test的: Rational Robots, Load Runner, ACT, Selenium Grid, ... 等

其中，WebDriver, Selenium 是專門進行 Web 測試的工具
都是伴隨著 Web 2.0 的成長，所發展出來的 opensource 免錢軟體

因為，這兩個產品在 google 內部也被大量的使用到

所以，後續 將會有針對這些tools的一些的介紹

閱讀全文...