易栈网-膘叔

说实话，如果不是必要，真不是特别推荐采用proxy方法。特别是在PHP中，采用proxy势必会造成include文件过多。IO的消耗非常恐怖，如果又采用openbasedir，那么还要恐怖 。性能会下降的很厉害。。。

下面是老王的文章：

模式是程序员之间的交流语言，代理（Proxy）和委派（Delegate）是模式中常见的词汇，不过很多人把他们混淆了，甚至等同起来，这会造成很多沟通交流上的误解，下面说说他们的区别，先看一个UML图：



图形已经表述的很直白了，如果还不清晰，可以看看下面的代码：

运行结果输出：Proxy::DoAction_RealSubject::DoAction_Proxy::DoAction

如果你还没有看出端倪，我就再废话几句：首先从词性来看，代理（Proxy）是名词，委派（Delegate）是动词，其次代理说明了若干个对象实现了一个共同的接口，而委派只是说明一个对象引用了另一个对象，并不牵扯接口。

既然说到这了，就再唠叨几句：什么时候适合使用Proxy模式呢？对PHP而言，一般是当需要给对象附加额外的逻辑时，而这些逻辑和原有逻辑又分属不同的 层次，此时就可以考虑使用Proxy模式。听起来有点拗口，说一个实际的例子，比如说我们实现了Article对象，里面封装了CRUD方法，现在我们要 加入权限判断，控制CRUD的访问限制，这些新加入的逻辑属于应用逻辑，而原有的逻辑属于持久化逻辑，从分层角度看它们不应该放在一个对象里，此时就可以 创建一个ArticleProxy代理对象，用来实现权限判断，至于CRUD操作，则通过委派给Article对象来完成。

当年的JIVE论坛大量使用了此类方法，不过现在JIVE论坛早已销声匿迹，但思想还是可以借鉴的。通过使用代理模式，可以把不同侧重点的逻辑分别封装到 不同的对象里去（和装饰模式有点像，至于如何区分就是另一个话题了），从而避免God Class的产生，不过这样设计的结果会产生大量的类，孰重孰轻还得视客观情况而定。
原文来自：http://hi.baidu.com/thinkinginlamp/blog/item/2297a7efcb52a31afdfa3cc2.html
老王一天到晚在研究新奇玩意，上次说在PC下安装object-C，也是我挺喜欢的。

 

正好看到这篇文章 ，而且他也是用PHP的。所以就转一下，而且我自己也有一些短域名，可以用来做尝试。就象最近，新浪的围脖上，如果你贴了网站，他都会转成sinaurl的，这样对于新浪来说又多了一个PV。

原文如下

     近来微博很火，因为字数的限制，出现了很多网址缩短这种服务，比如sina自己用了自家的sinaurl.cn，想到自己曾经也注册了一个很短的域名k6.hk很久了，一直闲着，不知道干嘛用，突然想到可以用来做网址缩短，还不错。说干就干,一会就写好了。比如我的博客地址就可以缩短成:http://k6.hk/u 

程序的设计很简单,下面说下原理，

    数据库只有两个字段seq(自增长数字)和url（数字的url地址，建立索引）。

    用户输入一个url地址，查询表是否包含此url，如果存在，则返回seq的数字，

    如果不存在，则插入数据库，得到一个新增加的自增seq数字，为了缩短数字占用的字符数，我们可以把abc等字母的大小写用上。这样10个数字，26个 小写字母，26个大小字母就组成了一个62进制了。比如数字10000000000(100亿)转换后就是aUKYOA,只有6位了，这样就能缩短很多的 网址了。

    下面是php的进制转换代码，来源于php手册（简单吧），当然其他语言实现也是很简单的，

    上面只是说了下实现的原理，如果要大规模的使用，后端可以抛弃数据，用key-value数据库存储，比如ttserver，将会有很高的性能提升。

      如果改下ttserver的源代码，通过ttserver的http接口直接跳转，那么性能将会非常高，一台机器一天提供上10亿次的中专都不是问题。用两台机器就可以实现高可用了，这种服务都不怎么耗费流量的。

 

--EOF--

我倒是不太清楚这个ttserver，但是我想，如果安装了memcached，也会很不错的。首次命中后直接存在memcached里，下次就可以直接访问了。当然更可以做的是，完全生成相应的跳转文件。这样就比较无耻一点了。

与文中写的内容类似，很多人都只在用addslashes来加反斜杠，这是很久前的作法了。不过却依然有人在用啦。
自从PHP5开始，mysqli类和PDO类都有了prepare功能，所以自动加反斜杠这个功能，很多人都忘了。但对于仍在使用老版本的mysql连接库的用户来说，mysql_real_escape_string和mysql_escape_string以及addslashes就是常用方法了。

以下就是摘抄原文：

本文介绍的是用 mysql_real_escape_string对用户提交数据进行整理处理和通过addslashes以及mysql_escape_string这 3个类似的功能函数的区别。经过转义的数据可以直接插入到数据库中。

很好的说明了addslashes和mysql_real_escape_string的区别，虽然国内很多PHP coder仍在依靠addslashes防止SQL注入（包括我在内），我还是建议大家加强中文防止SQL注入的检查。addslashes的问题在于黑 客可以用0xbf27来代替单引号，而addslashes只是将0xbf27修改为0xbf5c27，成为一个有效的多字节字符，其中的0xbf5c仍 会被看作是单引号，所以addslashes无法成功拦截。

当然addslashes也不是毫无用处，它是用于单字节字符串的处理，多字节字符还是用mysql_real_escape_string吧。

另外对于php手册中get_magic_quotes_gpc的举例：

最好对magic_quotes_gpc已经开放的情况下，还是对$_POST[’lastname’]进行检查一下。

再说下mysql_real_escape_string和mysql_escape_string这2个函数的区别：
mysql_real_escape_string 必须在(PHP 4 >= 4.3.0, PHP 5)的情况下才能使用。否则只能用 mysql_escape_string ，两者的区别是：
mysql_real_escape_string 考虑到连接的当前字符集，而mysql_escape_string 不考虑。


总结一下：

• addslashes() 是强行加；
• mysql_real_escape_string()  会判断字符集，但是对PHP版本有要求；
• mysql_escape_string不考虑连接的当前字符集。

原文来自：http://www.phpq.net/tutorial/addslashes-mysql_real_escape_string.html，使用原始mysql连接函数的人需要注意一下。
其实说起来也烦恼呀。现在还有多少人在自己用着自己写的数据库类？都是框架框架再框架了。恐怕已经没有多少人知道连接数据库的方式了。只知道DB::factory("PDO","connect string....");之类的了。不过也算是个笔记吧

读书的时候，偶尔也和同学们玩过xxx号是星期几的游戏。但那也是十几年前的事情了。
如今在程序时代，什么都用程序来解决。那当然是很方便的。因此，你问我2003年10月1日是星期几，我很可能就会直接用程序来告诉你。

但事实上，我们也都知道，PHP的date函数是有时间范围区间的，即只能从1970~2038年，因此在这个区间范围之外的算法都是不准的。那倒底怎么算呢？其实是有一个公式的：

蔡勒（Zeller）公式：w=y+[y/4]+[c/4]-2c+[26(m+1)/10]+d-1

公 式中的符号含义如下，w：星期；c：世纪-1；y：年（两位数）；m：月（m大于等于3，小于等于14，即在蔡勒公式中，某年的1、2月要看作上一年的 13、14月来计算，比如2003年1月1日要看作2002年的13月1日来计算）；d：日；[ ]代表取整，即只要整数部分。(C是世纪数减一，y是年份后两位，M是月份，d是日数。1月和2月要按上一年的13月和 14月来算，这时C和y均按上一年取值。)

算出来的W除以7，余数是几就是星期几。如果余数是0，则为星期日。

以2049年10月1日（100周年国庆）为例，用蔡勒（Zeller）公式进行计算，过程如下：
蔡勒（Zeller）公式：w=y+[y/4]+[c/4]-2c+[26(m+1)/10]+d-1
=49+[49/4]+[20/4]-2×20+[26× (10+1)/10]+1-1
=49+[12.25]+5-40+[28.6]
=49+12+5-40+28
=54 (除以7余5)
即2049年10月1日（100周年国庆）是星期5。

你的生日（出生时、今年、明年）是星期几？不妨试一试。

--EOF--

上面的公式和部分内容来自于http://www.cnblogs.com/chingho/archive/2010/03/26/1697282.html，只要有公式，什么都可以解决。

ThinkSNS是基于ThinkPHP框架开发的一款SNS程序，原本以为还是相对不错的程序，一些小的BUG也还能够接受，但听到这个消息（不再继续开发）后，心里哇凉哇凉的。

本来我也不知道的，但是在偶尔看discuz的uchome时，发现了这个投票，投票地址为：http://u.discuz.net/home/space-1293758-do-poll-pid-2017.html，内容大致如下：

 

看到这个投票，心里能不哇凉哇凉吗？看来以后更加不敢用这些个人作品了。除非是以公司运作的、或者开源但功能完整，BUG不多的。

因为相对于thinksns来说，我投入的精力和修改BUG也花了不少精力，当初thinksns说改用thinkphp2.0开发的时候，本来还想着激动一下，结果，干脆说不开发了。唉。。现在的百思家网站的用户中心就是采用了这个thinkSNS，改动了很多功能，不再一一列出，主要还是由于是商业网站不太适合改动，我仅说一点小小的吧，那就是博客的分类与相册的分类整合（而且还是用的另外的表，并非他原先的表结构）。

想来想去，最多到6月份左右，我想我还是会回到UCH上面吧？基于几个原因：

1. 官方不再开发，而小ＢＵＧ太多
2. 冗余代码太多，无法细细清除
3. theme更换的时候，必须要cleancache，否则无效（因此，在任何情况下，也只能拥有一套皮肤）
4. 原始模版写的有点糟糕，可能是赶时间写的。。。改一个小地方，都要同时改4、5个模版