rollenc拼博

Transplanted Real-World Business Models 现实世界的商业向互联网的转移

The mail-order model 以邮件，包裹的形式销售现实产品。 案例：amazon.com

The advertising based model 广告模式 许多的搜索引擎公司和一些免费站点 案例：yahoo, sina,

The subscription model 订购模式。在很多的音乐站点和成人站点的可以发现这种模式，付费购买之后，获得更多的信息。

The free trial model 免费试用。 即软件中的共享软件模型

The direct marketing model 直接的市场联系 以垃圾邮件，垃圾回复为代表，直接宣传实际市场的资料等，如培训，发票等

The real estate model 资产模型 如域名，Email名等

Incentive scheme models 坑蒙拐骗型 利用抽奖，优惠卷，“免费”服务等，诱导用户点击广告或者提供其私人信息 一些web调查机构使用此模式

Business to Business B2B模式

Combinations of the above models. 综合模式

Native Internet Business Models 纯粹的互联网模式

Unlike the real-world the native economy of the Internet is not based on scarcity but on abundance.
与real-world Model的区别：基于流量，而不是用户

The library model 图书馆模式 指企业站，大学信息站等

The freeware model 免费软件模式 当这个软件被广泛使用后，再发布一些其他的收费或增值版本。 案例：netscape

The information barter model 出卖信息模式 把本站的用户信息出卖给其他的公司 一些新闻资讯站精于此道

Digital products and the digital delivery model. 数字产品和数字产品发送。 数字资料是免费的，但当你需要它的实体时，你需要邮寄它们。利润就在这里。

The access provision model 访问入口提供商 即ISP

Web site hosting and other Internet services. 网站空间或其他服务提供，并在上面放置广告以盈利。


来源： A Taxonomy of Internet Commerce by Paul Bambury

作者 rollenc

Mark 一下。

---

作者 rollenc

Error-Handing Techniques

• 返回中立值 如：数值返回0
• 换用下一个正确的数据
• 返回与前次相同的数据
• 换用最接近的合法值 如经度设置为(-180,180)之间
• 把警告信息记录到日志文件中 兼用以上的处理，同时记录它。
• 返回一个错误码
• 设置一个状态变量的值（个人不推荐）
• 用状态值作为函数的返回值
• 用语言内建的异常机制跑出一个异常
• 调用错误处理子程序活对象 优点：能把错误处理的职责都集中到一起。代价：错误处理代码与整个程序紧密耦合。
• 当错误发生时显示出错信息 出错信息散布于整个应用程序中。
• 用最妥当的方式在局部处理错误 留给执行设计和实现的程序员来解决，灵活性强，但整体正确性和可靠性无法满足，风险显著
• 关闭程序 用于人身攸关的应用程序

知识来源：《代码大全2》

作者 rollenc

Verycd、豆瓣、EEmap

作者 rollenc

上一篇BLOG以及这一篇都是使用Performancing来发布的，感觉很不错。比FLOCK上的功能要强多了。wordpress上几乎所有的功能都可以使用到，比如Category选取，发布为草稿，也支持编辑以前发布的文章。
功能非常棒。赶快下载使用吧：
Firefox的Performancing插件下载地址

作者 rollenc

来源：http://www.developer.com/lang/php/article.php/10941_3604111_1
Part1:
PHP 5 made significant improvements on the Object Orientated programming model of PHP 4 bringing it more in line with languages such as Visual Basic .NET and Java. The improved object model in PHP 5 makes developing applications using OOP much easier and gives you the programmer, greater flexibility.

In this series of articles I will demonstrate the new features of the PHP 5 object and show you how to create a database abstraction layer similar to PEAR DB. I will also introduce you to a few design patterns that can be applied to common OOP related problems.

In this article, I introduce you to some of the features of the PHP 5 object model. You will see how to create a database abstraction layer similar to the Pear DB abstraction layer. You'll also learn how to adapt this abstraction layer for your own uses.

Introduction

One of PHP's stronger areas is its support for database connectivity. It is able to connect to and talk to just about any database server or interface you can imagine. However, with this comes a few inherent problems; each database system has its own features, functions and in most cases they have their own versions of SQL. Although the functions used to access these databases are similar they do vary subtly meaning that if you were to want to port an application written for MySql to MS SQL server, the refactoring would require manually changing all calls to mysql_query() to mssql_query().

While we are not going to go as far as developing a database independent version of SQL, the new features of PHP 5 will be us build a consistent database API with support for stored procedures (where it is not already present). This will then make switching from one database system to another as painless as changing one line of code.

Interfaces Abstract Classes and the Adapter Pattern

The first features new to PHP 5 to be covered in this article are abstract classes and interfaces. These concepts are nothing more than features added to OOP, which help the programmer follow good coding standards.

Abstract Classes

An abstract class is a class that is only partially implemented by the programmer. It may contain one or more abstract methods. An abstract method is simply a function definition that serves to tell the programmer that the method must be implemented in a child class.

To create an abstract class we use the code shown in Listing 1:

Listing 1: An Abstract PHP class

The abstract class in Listing 1 contains some of the methods required for a weapon. The fire() method however, cannot be implemented because each different weapons use different firing different mechanisms. The method is therefore declared as abstract, meaning it will be implemented in a more specific child class.

Because the class is abstract, an instance of it can never be created (remember, it is only a partial implementation). Instead a child class must be created using inheritance and implement the fire method in itself. Failure to do so will result in a fatal error. Listing 2 shows a child class being created from the Abstract Weapon class.

Listing 2: Extending the Abstract Weapons class

An instance of the Cannon and Gun classes can now be created because they now fully implemented subclasses of weapon.

Interfaces

An interface is similar to an abstract class; indeed interfaces occupy the same namespace as classes and abstract classes. For that reason, you cannot define an interface with the same name as a class. An interface is a fully abstract class; none of its methods are implemented and instead of a class sub-classing from it, it is said to implement that interface.

An interface will be used in the database abstraction layer you create. This ensures that every time you create a class for a particular database, the same API is exposed. When using an interface, you can then rely on the methods defined for the interface to be part of the class because, if they are not, PHP will not parse it.

The MySql functions will be used as an example because they are the most commonly used amongst PHP programmers. The most commonly used functions are:

• mysql_connect()
• mysql_error()
• mysql_errno()
• mysql_query()
• mysql_fetch_array()
• mysql_fetch_row()
• mysql_fetch_assoc()
• mysql_fetch_object()
• mysql_num_rows()
• mysql_close()

If all the database class APIs you create can expose the same methods with the same return types then you can be sure that changing from one database to another, such as from MySql to Postgre SQL, will be painless. As such, the interface in listing 3 can be determined for your API.

Listing 3: An Abstracted Database Interface

Any class implementing the interface must define each method that is declared in the interface, and each method must have at least the parameters identified in their interface definitions. It may have more parameters as long as they are optional, but it cannot have less.

Part2

Look at a class in Listing 4 that implements the database interface. You should recall that I mentioned the adapter pattern earlier. This is an example of the adapter pattern, which is used by programmers in order to adapt one API. The API you are adapting from could be another object-based API or as being done here, an adaptation from a modular API. If you want to read more about the adapter pattern, you can find a more detailed explanation and examples here.

Notice how the escape_string() method is included as a static method. This method does not require an active connection to a database and should not require and instance of any object which implements the DB interface. In my opinion, this is the single most important method of any database implementation; a poorly implemented escape string method could make your applications vulnerable SQL injection.

Listing 4: Implementing the database interface

You'll notice that there are many more mysql functions than methods that are adapted in the interface in listing 3. However, this small subset of functions is sufficient to meet the needs of most applications requiring trivial data storage and retrieval. The additional functions can be implemented and I have done this in the attached example file, you may also choose to add additional functionality to the class and the interface.

Listing 5: Creating a database class

As shown in listing 5, you can now create a class for each database you want and as long as it implements the DB interface, switching from one to another is as easy as changing one line of code:

[geshi lang=php]
$db = new MsSqlDb;
[/geshi

Conclusion

In this first article, you've seen how to create an abstraction layer to access a database. Using this, you saw how creating an interface helps you to isolate your application so that you can easily switch from one database to anther without rewriting your own applications.

Downloads

• db.php
• mysql_db.php

About the Author

Adam Delves is a university student and web programmer from the UK who is studying computing. He has been a PHP programmer for over 3 years and now runs two small websites and writes articles for PHP builder.com.

rollenc总结

将本文标题相对应，MySqlDb实现了DB接口（interface），也对mysql_*函数进行了适配（Adapter）（我就很喜欢进行这种适配，php中有很多带‘_’字符的函数（这也被PHP反对者们发现，并抨击PHP的一大有力证据），与我喜欢的骆驼编程风格很不协调，所以，为了隐藏它们，我常常进行适配）。
抽象类只在weapon上出现到了，为了增加代码的灵活性，建议使用接口，而不是继承。(完)

作者 rollenc

Test First Guidelines
Sean Shubin
01/25/2002
Sean Shubin has begun using Test-First development. He wanted to share these ideas and guidelines with us.

Contents:

This document is my attempt to filter out guidelines about Test First Design from the XP series of books. Thanks to Denise Phillips and Ron Jeffries for their input. It is not my intent to justify Test First Design, I just want summarize what martin Fowler's Refactoring and the XP texts have to say on the subject. If you see anything that you think contradicts these sources, please e-mail me with the book and page number. I am still working on samples for each of these guidelines. If you find any of them completely confusing, send me an e-mail to let me know which ones I need to work on. Send e-mail to Sean Shubin, (remove the "nospam" portion of the e-mail address).

The tests should drive you to write the code, the reason you write code is to get a test to succeed, and you should only write the minimal code to do so. Note that test-first-design is more than just unit testing. Unit testing by itself does not change the design of the code. In addition to documenting how code should be used, test-first-design helps you keep the design simple right from the start, and keeps the design easy to change.

As project complexity grows, you may notice that writing automated tests gets harder to do. This is your early warning system of overcomplicated design. Simplify the design until tests become easy to write again, and maintain this simplicity over the course of the project.
Guidelines for test first design:

* The name of the test should describe the requirement of the code
* There should be at least one test for each requirement of the code. Each possible path through of the code is a different requirement
* Only write the simplest possible code to get the test to pass, if you know this code to be incomplete, write another test that demonstrates what else the code needs to do
* A test should be similar to sample code, in that it should be clear to someone unfamiliar with the code as to how the code is intended to be used
* If a test seems too large, see if you can break it down into smaller tests
* If you seem to be writing a lot of code for one little test, see if there are other related tests you could write first, that would not require as much code
* Test the goal of the code, not the implementation
* One test/code/simplify cycle at a time. Do not write a bunch of tests, and try to get them working all at once
* Keep writing tests that could show if your code is broken, until you run out of things that could possibly break
* When choosing an implementation, be sure to choose the simplest implementation that could possibly work
* If you are unsure about a piece of code, add a test you think might break it
* A test is one specific case, for which there is a known answer
* If all of the tests succeed, but the program doesn't work, add a test
* Tests should be as small as possible, before testing a requirement that depends on multiple things working, write a test for each thing it depends
* Tests should not take longer than a day to get working, typical test/code/simplify cycles take around 10 minutes
* Don't test every single combination of inputs. Do test enough combinations of inputs to give you confidence that the any code that passes the test suite will work with every single combination of inputs
* Do not write a single line of code that doesn't help a failing test succeed. (Clarification for GUI's, some aspects of GUI's are impossible to test automatically, so it will have to be an acceptance test that drives you two write some GUI code. Use automated testing whenever possible)
* Do not fix a bug until you have written a test that demonstrates the bug

What is the simplest code? (Paraphrased from the "Extreme Programming" series of books)

* All of the tests run
* There is no duplicate code (any given code segment or structural pattern should appear "once and only once")
* Clarity. The code and tests communicate the intent as clearly as possible
* The code is minimal (no classes or methods unnecessary to get the tests to pass)

The Test-Code-Simplify cycle (Quoted verbatim from "Extreme Programming Applied", p159)

* Write a single test
* Compile it. It shouldn't compile, because you haven't written the implementation code it calls
* Implement just enough code to get the test to compile
* Run the test and see it fail
* Implement just enough code to get the test to pass
* Run the test and see it pass
* Refactor for clarity and "once and only once"
* Repeat

Online Examples of Test First Design:

Roman numeral converter example

http://www.differentpla.net/~roger/devel/xp/test_first/

Sample application that calculates bowling score

http://www.objectmentor.com/publications/xpepisode.htm

Books:

"Refactoring" and "Design Patterns" tell you how to maintain a simple design.

The "Extreme Programming" series explains test-first design in detail, and was the primary resource I used to put together this set of guidelines.

来源：http://xprogramming.com/xpmag/testFirstGuidelines.htm
最近感觉想翻译的东西太多了，有一些就纯粹转载了。有时间再翻译。

作者 rollenc

From: http://www.devshed.com/c/a/PHP/Unit-Testing/
Unit Testing
单元测试

Having a formalized unit testing infrastructure for your projects will save you time in the long run, especially when looking for bugs in code. This article introduces you to setting up a unit testing framework. It is excerpted from chapter 6 of the book Advanced PHP Programming, written by George Schlossnagle (Sams; ISBN: 0672325616).
�