月归档:五月 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 | 标签为 , , | 留下评论