<?xml version="1.0" encoding="UTF-8"?><rss version="0.92">
<channel>
	<title>andery&#039;s blog</title>
	<link>http://www.zm17.com</link>
	<description>小小的天有大大的梦想 总有一天我有属于我的天</description>
	<lastBuildDate>Sat, 10 Jul 2010 06:10:53 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	<!-- generator="WordPress/3.0" -->

	<item>
		<title>PHP 截取字符串</title>
		<description><![CDATA[相信很多人都用PHP自带的substr();在截取中文字符串的时候遇到麻烦。 在这里贴一个把中文当作一个长度截取的函数 function cutstr($str, $len, $dot='...') { $i = $ti = 0; if (strlen($str) < $len) return $str; $charset = is_utf8($str); if ($charset) { while ($ti < $len) { $t = ord($str[$i]); if ($t >= 224) { $i += 3; } elseif ($t >= 192) { $i += 2; } else { $i++; } if [...]]]></description>
		<link>http://www.zm17.com/?p=307</link>
			</item>
	<item>
		<title>数据库设计原则-范式（2）</title>
		<description><![CDATA[第二范式（2NF） 1.在讲第二范式前，首先必须要保证符合第一范式的要求。 2.在前面文章中说到，每行都表示一个实体，不能重复，第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。比如我们前面给的电话本的例子，每个用户都有一个ID，这个ID是唯一的，因此每个用户可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。 3.属性完全依赖于主键。 例子：这个表设计符合第一范式，但是不符合第二范式。 OrderId Company ContactPerson Money 1 东明企业 andery 2347.00 2 德商网络 jack 5893.00 3 东明企业 andery 1506.00 4 东明企业 andery 6503.00 上表中订单号(OrderId)是主键，这里公司名字(Company)和订单金额(Money)都依赖于订单号。但是联络人(ContactPerson)则是依赖于公司名称的。 这样会出现的问题： 1.数据冗余，加入一个公司下了100个订单，联络人就会重复出现100次。 2.更新异常，若某公司的联络人有调整，相应的ContactPerson值都要更新，这么多重复的数据都需要更新，产生不需要的消耗。 这里就不符合第二范式，我们就需要分成2个表。 OrderId Company Money 1 东明企业 2347.00 2 德商网络 5893.00 3 东明企业 1506.00 4 东明企业 6503.00 Company ContactPerson 东明企业 andery 德商网络 jack 这样符合第二范式了，某公司联络人变更只需要更新第二张表中相应公司的联络人信息就可以了。]]></description>
		<link>http://www.zm17.com/?p=290</link>
			</item>
	<item>
		<title>数据库设计原则-范式（1）</title>
		<description><![CDATA[下面是八个范式的英文全称： 1NF : First normal form 2NF : Second normal form 3NF : Third normal form BCNF : Boyce-Codd normal form 4NF : Fourth normal form 5NF : Fifth normal form DKNF : Domain/key normal form 6NF : Sixth normal form 第一范式（1NF） 在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。 第一范式具体分为下面5个条件： 1.数据表内的的每行没有前后之分。 2.数据表内的每列没有左右之分。 3.没有内容相同的重复行。 4.每个行和列交叉的地方只有一个适用的值，不会出现多个值。 5.每个列的作用都是固定的。 例子：一个电话本的数据表设计 Uid UserName TelNumber 1 [...]]]></description>
		<link>http://www.zm17.com/?p=238</link>
			</item>
	<item>
		<title>PHP设计模式之观察者模式</title>
		<description><![CDATA[先抛出一个问题，你的网站有一个新用户注册，假设你需要给用户发送一条站内信，一封电子邮件，给用户分配一个宠物。 那么假定程序需要4个类，分别是用户类(User)，电子邮件类(Email)，站内信息类(Message)，宠物类(Pet)。 那么要解决上面的问题，我们可以直接在 用户对象中用户注册成功后面计入其他3个对象相应的处理方法。这样目的达到了，是否合理呢？ 试想，现在用户类需要改动，有可能就会导致注册成功后的动作不能正常启动，或者我改动了其他3个类，我就必须回到User类中寻找到相应的代码进行修改。这样会造成很多不必要的麻烦，如果是团队协作，那就真是头疼了。 在OOP编程中，我们一直在说一个东西就是避免组件之间紧密耦合。上面给出的解决办法就违反了这一原则。观察者模式提供了避免组件之间紧密耦合的一种方法。 用观察者来分析以上问题： User一个被观察的对象； Email，Message，Pet是观察者； 首先观察者需要注册为User的观察者。 一当被观察者有相应的动作，观察者就会作出相应的反映。 代码清单： //先定义一个用户注册观察者接口 interface IObserver{ public function onChanged(); } //同上我们需要定义一个被观察者抽象类 abstract class Observable{ //观察者集合 private $_observers; public function addObserver($observer) { $this->_observers=[] = $observer; } //通知各个观察者 public function notify(); } //用户类 class User extends Observable{ public function register() { //注册过程省略，这里假定注册成功返回用户ID号($uid); if($uid) $this->notify($uid); } public function notify($uid) [...]]]></description>
		<link>http://www.zm17.com/?p=236</link>
			</item>
	<item>
		<title>PHP设计模式之工厂模式</title>
		<description><![CDATA[在讲之前先做一个比喻，现在我需要生产一批货。 我首先需要2000件上衣，那么我发单上写的是： 代工工厂名称：XX上衣厂 货物需求数量：2000件 货物种类：上衣 联系人：李先生 电话：123 我还需要3000条牛仔裤，那么我发单上写的是： 代工工厂名称：YY牛仔裤厂 货物需求数量：3000条 货物种类：牛仔裤 联系人：洪小姐 电话：123 XX上衣厂和YY牛仔裤厂的地址是不一样的，需要把这2个文件送到 2个不同的地址。 假如我还需要鞋子，帽子，围巾，那我就需要联系更多的工厂，需要的成本也增加不少，还需要维持每个产的关系，要是有个厂关闭了，等等头痛的问题。 我会想，要是有一个工厂(Z工厂)可以又做上衣又做裤子，那么我可以节约很多成本，首先联系人只有一个了，电话只有一个了，地址只有一个了。 那么我就只需要直接告诉Z工厂信息：2000件上衣 或者 3000条牛仔裤，由他们厂来把不同的货物种类分配到不同的车间进行生产。 那么我发单上写的是： 货物需求数量：2000件 货物种类：上衣 货物需求数量：3000条 货物种类：牛仔裤 简单快捷的发送信息，返回给我的是一样的货物(2000件上衣 或者 3000条牛仔裤). 回到主题中来，设置模式中的工厂模式就可以解决我们在程序中遇到的同类型的问题。 通常工厂类返回的也是一个符合类似接口的类，根据参数的不同或者配置信息的不同来创建一种专门用来实例化并且返回其他类的事例的类。 在程序中我们比较常见的就是数据库的操作问题，我们程序可以操作很多数据库，但是每种不同数据的操作函数，参数等等都不一样。当我们一个项目的数据要移植到另一个不同的数据库上的时候，我们就需要修改很多代码来位置应用程序的正常工作。工厂模式就在这里很有用了，用工厂模式来设置数据库操作模块，我们可以做到只需要修改一下配置文件中数据库的配置文件，或者修改一下操作数据库函数的参数就可以很方便的切换到另一个种完全不同的数据库，不需要对程序代码进行任何的修改。 代码清单：使用工厂模式解决数据库可移植问题 interface Idatabase { //定义数据库类的契约 } class Mysql { //some thing } class Mssql { //some thing } //还可以有更多种数据库... class DbFactory { public static [...]]]></description>
		<link>http://www.zm17.com/?p=216</link>
			</item>
	<item>
		<title>memcache与memcached的区别</title>
		<description><![CDATA[memcache应该大家都很熟悉了。 但是经常会看到memcache和memcached，他们到底有什么区别呢？ 我们经常也会看到http，httpd，imap，imapd。 通常在linux中的应用，服务端被称为“守护”，守护进程一般的命名就是与客户端应用名称加上字母&#8221;D&#8221;。例如“imap”是一个客户端连接到“imapd”守护进程。 memcache作为php的扩展安装好之后，就可以访问memcached服务器。 但是到php的手册查看可以看到这两个扩展： http://php.net/manual/en/book.memcache.php http://php.net/manual/en/book.memcached.php 手册上memcached 会比 memcache 多几个方法，使用方式上都差不多。 搜索一下很多人给的答案都是我最开始说的那一段，没有其他的，然后找英文的，找到了一个 http://stackoverflow.com/questions/1825256/memcache-vs-memcached 按照他这里说的，首先肯定了我文章开头的是正确的。然后讲到其实有2个memcached。一个是服务端的守护进程。 还有一个可以看作是另一个版本的php扩展，和memcache一样作为客户端的角色，刚好又和 memcached同名，所以很容易让人弄糊涂。 memcached 的版本比较新，使用的是 libmemcached 库。libmemcached 被认为做过更好的优化，比 memcache 有着更高的性能。 附带一个他们2者的对比表：http://code.google.com/p/memcached/wiki/PHPClientComparison]]></description>
		<link>http://www.zm17.com/?p=212</link>
			</item>
	<item>
		<title>vsftpd 安装与配置</title>
		<description><![CDATA[第一步：安装 打开ftp://vsftpd.beasts.org/users/cevans/ 选择一个你需要的版本，我在这里选择了vsftpd-2.2.2.tar.gz vsftpd下载 wget ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.2.2.tar.gz 然后解压这个文件包：tar zxvf vsftpd-2.2.2.tar.gz 然后输入命令 cd vsftpd-2.2.2 make 我在这里遇到一个错误 gcc -o vsftpd main.o utility.o prelogin.o ftpcmdio.o postlogin.o privsock.o tunables.o ftpdataio.o secbuf.o ls.o postprivparent.o logging.o str.o netstr.o sysstr.o strlist.o banner.o filestr.o parseconf.o secutil.o ascii.o oneprocess.o twoprocess.o privops.o standalone.o hash.o tcpwrap.o ipaddrparse.o access.o features.o readwrite.o opts.o ssl.o sslslave.o ptracesandbox.o ftppolicy.o sysutil.o sysdeputil.o [...]]]></description>
		<link>http://www.zm17.com/?p=159</link>
			</item>
	<item>
		<title>PHP设计模式之单例模式</title>
		<description><![CDATA[有时候我们需要一个对象只做一个特定的事情，并且程序中只需要这一个对象，那么要保证这个对象只被实例化一次，很多情况下很多人的做事是用引用。这样整个程序在运行过程中只使用这一个对象。 在OOP中，这种做法可能不被允许，复杂的项目或者多人开发的应用中这样做可能会有很多头疼的问题，因为有可能在其他地方错误的将这个对象再次实例化，所以我们需要在这个对象本身就控制这个问题，这里就要将到一种常用的设计模式：单例模式。 见的比较多的就是数据库的访问，往往我们只需要并且只允许一个对象访问数据库，在任何时候，应用程序中都只会有这个类仅有的一个事例存在。这可以防止我们去打开数据库的多个连接或者不必要地使用多余的系统资源。在更加复杂的系统中，使用单例模式在维持应用程序状态的同步方面也尤其有用。 单例类至少拥有一下三种公共元素： 1.拥有一个构造函数，并且必须被标记为private（私有）。 2.拥有一个保存类的事例的静态变量。 3.拥有一个访问这个事例的公共静态方法。 因为构造函数被标记为私有，单例类不能在其地方直接被实例化，只能被自生实例化。 在限制外部实例化单例类的同时还必须防止此类被复制，所以必须在类中创建一个空的私有方法__clone()。 下面给个简单的例子： class Database ｛ private $_db; private $_instance; private function __construct() { $this-&#62;_db = mysql_connect('连接数据库参数'); } public static function getInstance() { if (!self::$_instance instanceof self) { self::$_instance = new self(); } else { return self::$_instance; } } //some code... private function __clone() {}; ｝]]></description>
		<link>http://www.zm17.com/?p=152</link>
			</item>
	<item>
		<title>URL缩短服务的实现(Bit.ly,j.mp,tinyURL,Go.ly&#8230;)</title>
		<description><![CDATA[我所知道的URL缩短服务是从Twitter使用tinyurl.com来缩短微薄中的域名开始流行起来的，国内的新浪，腾讯微薄都使用了。 Twitter最开始使用tinyurl.com，现在在用的是Bit.ly。 为什么需要URL缩短业服务？ URL缩短服务简单的说就是把一个很长的url地址做成一个很短的url来跳转。这样的好处就是可以把原本一长串的URL地址变成很少的字符。 比如：http://www.google.com.hk/search?hl=zh-CN&#38;newwindow=1&#38;safe=strict&#38;q=baidu&#38;btnG=Google+%E6%90%9C%E7%B4%A2&#38;aq=f&#38;aqi=g10&#38;aql=&#38;oq=&#38;gs_rfai= 经过缩短之后就是(本文用bit.ly做例子)：http://bit.ly/c9gnGZ 这样节省了不少空间，并且看起来也工整很多。 其实还有个很重要的作用就是可以根据域名的流量对网站进行统计和分析，这个很多服务器提供商已经在做了。 为什么微薄上开始流行？ 我们都知道一篇微薄的内容都是很简短的，一般都控制在150字以内，但是有的一个URL地址可能都大于150字了，所以无法发送出去，就算小于规定长度，一篇微薄被一个URL就占用了大部分的位置也会很不划算。所以URL缩短服务在微薄中的作用尤为重要。 怎么实现呢？ 首先需要一个很短的域名，这个优势很重要，tinyURL.com和Bit.ly明显的劣势就是域名太长。 不管域名，我这里讨论下功能的实现。 1.生成地址的API 在发表这个URL(如http://www.zm17.com/?p=152)地址的时候需要调用提供的API来生成一个独一无二的缩短域名，例如http://bit.ly/abc。 这里需要保证http://bit.ly/abc的唯一性。 我们可以设想一个数据表，有3个字段分别是：(也可以不用shorturl，每次请求都处理一次ID值) id 自增长编号 shorturl 缩短处理后的URL rawurl 原URL 在接受到原URL后，查看最大ID号（为了提高效率我们可以先不用数据库来获得这数字，用文件来保存，这里最大编号假设为maxid） 那么此URL的编号应该是thisid = maxid+1 通过处理thisid得到一个短的独一无二的字符串，这里是abc。实现的算法很多，这里就不啰嗦了。 然后保存在数据库中去。 2.实现跳转 有用户请求http://bit.ly/abc这个地址的时候，去数据库中查询shorturl同行的rawurl，然后重定向。]]></description>
		<link>http://www.zm17.com/?p=94</link>
			</item>
	<item>
		<title>47个令人瞠目结舌的 CSS3动画</title>
		<description><![CDATA[或许你已经看过很多关于CSS3动画的技术，包括前端观察之前发表的一些，那么现在就情看一看CSS3动画的魅力吧。这里是一辑47个令人瞠目结舌的 CSS3动画演示。他们演示了CSS3能给我们带来的巨大的可能性。]]></description>
		<link>http://www.zm17.com/?p=95</link>
			</item>
</channel>
</rss>
