月歸檔:五月 2007

找一個網站流量統計系統

以前用過51yes在線統計,除了有一次感覺到它明顯拖慢了網站速度,平時還是不錯的。報告也很詳細。
用Ruby on Rails後,我找到了兩個相關的插件,SitealizerRail_stat,但兩個都是在服務器上即時統計的,要用佔用系統資源。於是想找個apache日誌分析器。一開在google上找counter,結果找到了大量九十年代的東西,很讓人懷舊。原來現在流行的關鍵詞是 Log Analysis/Web Statistics。找是我找到了AWStats,這是個用perl語言編寫的log免費分析器。從它的Demo來看報告還是比較詳細的。基於貨比三家的傳統想法,又搜索了一會,找到了ClickTracks, 看了它的Flash Overview, 大開眼界!!! 原來現在的網站流量分析思想和技術已經達到了如此之高的境界。。。這樣的軟件只賣995美元真是物超所值!參觀完了走人吧,現實點,再找個免費的。就在這時,Google出現了,Google Analytics!!! 我二話沒說就註冊了。這個和51yes幾乎是一樣的,這個比AWStats方便,不用安裝。註冊後我得到一段javascript代碼,然後要做的就是把代碼放到每個頁面上,以後找個吉日登錄Google Analytics頁面查看流量。。。

從51yes轉到了一圈,回到了原點,只不過換了個牌子。

發表在 站長文檔 | 2 條評論

網站作為一個信息供給系統

就目前為止,我對網站作為一個信息供給系統的看法。
當然,網站不止於信息供給功能,人們還可以發布信息和交流信息。

信息供給系統是指一個能向用戶提供有用信息的系統。
它是相對的。一個系統能提供的信息對一些用戶有價值,對於其他用戶可能沒有價值。
信息供給系統必需滿足兩個條件:
1.有價值的信息在系統中存在;

2.用戶可以通過某種實際可行的途徑得到這部分信息。

信息供給系統的評價標準
對於一個用戶,系統屬於信息供給系統的條件下,評價它的標準:
1.取得信息的難度(技術難度,視線難度。。)
2.取得信息的用時
3.信息價值的大小,用戶最後得到信息後對信息的滿意度。信息的相關性,信息的準確度,信息的時效,信息的完整程度。。。

信息供給的途徑
1.搜索
優點:直接,快速
缺點:要先得到關鍵詞,很難控制相關性。

2.索引
優點:系統化,用戶可以不知道關鍵詞,通過大概的感覺找到信息;可以瀏覽,讓用戶得到一片信息,而不是一點
缺點:比較費時(但如果能順利找到,用戶應該不介意)
網頁的分類,TAG,導航系統也可以看完一個索引系統。
要使用清晰準確易懂的關鍵詞作為分類名。不要給用戶任何“驚喜“
索引分類結構要合理,要讓用戶一眼能看出來他要的子分類藏哪一主分類之下。
一個終端類目下的條目不應該過多,過多的條目不方便挑選。
索引最好有合理排序功能,通過列表的條件關係,加速信息查找。

信息供給系統的最高目標:
立現你所需,不多,也不少。
立:速度快
現:不費力,主動“現”
你:個性化,針對性
所需:相關性
不多:無干擾信息,無不相關信息
不少:信息量完整。

發表在 信息處理, 站長文檔 | 標籤為 | 留下評論

女朋友

在嘉陵江邊的亂石灘上,伴着潺潺的江水,吹着讓人舒心的風,坐着的卻是一對沉默着的情侶--男孩低着頭,偶爾也會嘗試帶着笑臉看一眼女孩,但女孩瞪一眼男孩,把綳得緊緊的臉轉開一點,繼續不搭理他。。。於是男孩只得掃興地再次慢慢低下頭。。。

他們就坐着,坐着。。。寧靜得像這就是他們的世界盡頭。。。

突然一石子被投向了江里,“咚“的一聲,江面上散開了幾圈波紋。二人同時轉身,看到一個正在散步的人從腳下又拾起一石子,向江面投了出去。。。

女孩看了一會,站起來俯身探了幾步,也拾起一塊石子,然後隨手將它向江面擲了出去,但飛出的石子馬上墜落,落在僅幾步之遙的江面上。。。

這時男孩帶着一塊石子向移江邊和女孩並站到了一起,舉起手中的石子--他沒有把石子拋出,而是虔誠地把它送到女孩的前面。。

女孩看了他一眼,又看了一眼他手中的石子,停了一會,還是伸手接過了石子,把它向江面擲了出去。“啪“的一聲,石子被摔他們跟前的江邊上,濺了男孩一身的水珠。。。

“你太差勁了“,男孩一邊擦着臉,一邊隨手拾起一塊石子,“看我的!”
石子在天空划了一道長長的線,消失在了江心。。。

女孩呆了一會,然後馬上低頭翻了兩個大小一樣的石子,把其中一個遞給男孩,“你等我擲完了再擲,看看你。。。“
”比你遠多少?“面對即將到來的挑戰,男孩顯然有點激動。

男孩話音剛落,女孩剛有點平和的臉馬上又綳了起來,她恨恨地向男孩瞪了一眼,轉身後卻調皮地笑起來“我不要你投近了,也不要你投遠了,我要看看你投到的地方離我投的落點能有多近。“

兩塊石子一前一後落到了江面,泛起了幾圈波紋,波紋一邊向外擴散一邊隨着江水蕩漾,不一會就從江面上消失了。。。

發表在 某時雨集 | 留下評論

Extreme Programming and Test-Driven Development

Extreme Programming
Extreme Programming (or XP) is a software engineering methodology, the most prominent of several agile software development methodologies.

Extreme Programming Explained describes Extreme Programming as being:
    * An attempt to reconcile humanity and productivity
    * A mechanism for social change
    * A path to improvement
    * A style of development
    * A software development discipline


Test-Driven Development
The goal of TDD is to write clean code that works.

What is Test-Driven Development?
Test-Driven Development (TDD) is a software development technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. Test-driven development is a method of designing software, not merely a method of testing.

In addition to normal “did it pass?” testing, you can go the opposite route. By testing your application where the weak points are, you can fix it before it ever becomes an issue.

Test-Driven Development Cycle
1. Add a test
In order to write a test, the developer must understand the specification and the requirements of the feature clearly.
2. Run all tests and see the new one fail
testing the tests
3. Write some code
It is important that the code written is only designed to pass the test; no further (and therefore untested) functionality should be predicted and ‘allowed for’ at any stage.

KISS
Keep It Simple, Stupid.
Everything should be made as simple as possible, but no simpler.
                    –Albert Einstein

You Ain’t Gonna Need It
‘You Ain’t Gonna Need It’(YAGNI), is a reminder for programmers that one should never add functionality until it is necessary.

4. Run the automated tests and see them succeed
5. Refactor code

Refactoring
A code refactoring is any change to a computer program which improves its readability or simplifies its structure without changing its results.
List of refactorings

    * Encapsulate Field(e.g. providing methods that can be used to read/write to/from the field rather than accessing the field directly.)
    * Extract Method (to turn part of a larger method into a new method. By breaking down code in smaller pieces, it is more easily understandable. This is also applicable to functions)
    * Generalize Type (to making more general or more abstract some subset of the traits of a specific type. An example of generalizing a type would be moving a method from a child to a parent class for common use by all the parent class’ children, not just the original child.)
    * Pull Up (moving a method from a Subclass into a Superclass. )
    * Push Down (moving a method from a SuperClass into a SubClass.)
    * Rename Method (changing the name of a method into a new one that better reveals its purpose).

The cycle is then repeated, starting with another new test to push forward the functionality.

"Test-Driven Development Mantra" is known as red/green/refactor where red means fail and green is pass.

Benefits
By focusing on the test cases first, one must imagine how the functionality will be used by clients (in this case, the test cases). Therefore, the programmer is only concerned with the interface and not the implementation.
It allows a programmer to focus on the task at hand as the first goal is to make the test pass.
Ensuring that all written code is covered by a test.

Limitations
A test-driven development is only as good as its tests.

Reference
http://en.wikipedia.org/wiki/Test-driven_development
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
http://en.wikipedia.org/wiki/Refactoring

Related Resources
Test::Unit – Ruby Unit Testing Framework
A Guide to Testing the Rails
Test Driven Design for Ruby and Rails
Ruby, Rails, Test::Rails Cheat Sheet

發表在 Ruby on Rails | 標籤為 , , | 留下評論