google新的搜索界面显得更加靓丽和年轻，继续进一步和百度拉开差距，估计不久就应用到google 中国的的界面上，目前你还不能通过正常方式访问到这个界面，如果想感受一下新界面，方式如下：打开www.google.com页面，记得，是google.com页面，如果跳转到google.cn页面，只要点击搜索框下面的“Google.com in English”即可，然后复制下面的脚本到你的浏览器地址栏，然后敲回车，再刷新google.com页面即感受最新搜索界面。
javascript:void(document.cookie=”PREF=ID=20b6e4c2f44943bb:U=4bf292d46faad806:TM=1249677602:
LM=1257919388:S=odm0Ys-53ZueXfZG;path=/; domain=.google.com”);
关于google新搜索界面的更详细报道，请移步这个网站，E文的哦~~
这个url的正则表达式判断的JavaScript！比较全面的。它验证的情况包括IP，域名（domain），ftp，二级域名，域名中的文件，域名加上端口！用户名等等信息，貌似作者也是在网上找的，我从一个项目代码中扣出来的，是我见过的最强最全面的url验证方式！太猛了，贴在这里与大家共享先，以后不记得的时候来博客上找找，URL的验证实在是很频繁。
function IsURL(str_url){ var strRegex = "^((https|http|ftp|rtsp|mms)?://)" + "?(([0-9a-z_!~*'().&=+$%-]+: )?[0-9a-z_!~*'().&=+$%-]+@)?" //ftp的user@ + "(([0-9]{1,3}\.){3}[0-9]{1,3}" // IP形式的URL- 199.194.52.184 + "|" // 允许IP和DOMAIN（域名） + "([0-9a-z_!~*'()-]+\.)*" // 域名- www. + "([0-9a-z][0-9a-z-]{0,61})?[0-9a-z]\." // 二级域名 + "[a-z]{2,6})" // first level domain- .com or .museum + "(:[0-9]{1,4})?" // 端口- :80 + "((/?)|" // a slash isn't required if there is no file name + "(/[0-9a-z_!~*'().;?:@&=+$,%#-]+)+/?)$"; var re=new RegExp(strRegex); //re.test() if (re.test(str_url)){ return (true); }else{ return (false); } }
感谢收集者和原作者，虽然我不知道是谁，非常感激~~
个人觉得会话状态模式其实算不得一种模式，因为无非就两种，而且必须是其中的一种，一种存放在客户端，一种存放在服务端。两者都有风险和优点。
通常将会话保存在客户端是为了获得服务端的高度无状态特性，即服务端可以做到完全的无状态。Java中通常使用传输对象来进行数据传输，因为传输对象可以在网上进行序列化，即使是很复杂的数据也可以进行传输。当然序列化是有风险和代价的，不是所有的序列化数据都能够被反序列化回来，虽然出现反序列化回来的出错的概率很小。
如果使用HTML的话，选择相对多一点，URL参数，隐藏表单域和Cookie，URL对于较小数据量还是比较容易使用的，现代浏览放开了对URL长度的限制，但我们不得不考虑一些古董用户的需求，毕竟IE6及以下版本的浏览器还主导着WEB世界，而且URL过长，也不符合REST原则，更不美观。
隐藏表单域适合于POST方式的请求，POST方式可以避免因浏览器限制URL长度而导致的被截断的问题。隐藏表单域在我曾经的代码中经常使用，主要是为了跟踪和referer的referer，也就是跳转到一个页面之前的原来页面。
Cookie方式是最优争议的一种方式，PHPWind采用了这一种方法，从开发者口中得知，是为了减少服务器的负载，因为服务器不用维护session状态。通过把数据序列化或者加密后以文本方式放到Cookie中，我没有测试过，PHPWind这样做是不是真的能降低服务器的负载，根据我以前的测试，session维护成本对于服务器的影响是微乎其微的，还不如优化一条SQL来得更痛快，更有效，而且放在Cookie中会导致用户请求的流量变大，在很多上下带宽不对称的机房中，这是个严重的问题，比如blogbus之前存放在上海的**机房就是这样。而且为了获得Cookie中的数据还需要进行一些列运算，未必比维护session的成本小，而且会导致严重的安全问题。只要算法是可逆的，就一定能被人破解，何况我等庸人搞的算法。
服务器会话状态最简单的一种就是把会话数据放到应用服务器的内存中，可以将会话数据以会话标识号作为键标识放到内存映射表中，现在很多工具可以做到，比如memcache等key-value 的内存存储工具。
另一种是持久化，持久化也可以分为两种，一种以二进制序列化形式存放，但这样做的缺点是不容易阅读，更新起来成本有点高，如果每个会话都一个文件的话，在高并发的时候还得解决文件系统的巨量小文件查找效率问题。还有一种就是持久化到数据库，这个存放会话的模式，可能会因为维护会话状态而带来巨大的数据库开销问题，而且为了及时清除过期的会话，往往配合触发器来进行。
总结起来每种会话管理都有天生的缺陷，如果能多种结合能够提升一些效率，比如内存缓存配合持久化数据库，就是眼下很多高负载网站正在使用的模式，也许还有其他的更多的模式和方法有待探寻~~
由于公司的提供邮箱实在是小，而且几乎可以说是没有Web界面，出于有条件的情况下，一定使用正版和与大家保持一致的原则，选择了outlook 2007 ，这家伙居然默认不支持最小化到任务栏~~~ 
OUTLOOK启动后最小化总是在任务栏上占一个位置，工作起来碍事， 最后修改注册表解决之。
1.打开注册表 : 开始菜单 -> 运行, 输入”regedit”并回车
2.打开HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Preferences项目
3.建立一个DWord的值(双字节值),名称为”MinToTray”, 取值改成 1
4.关闭注册表编辑器, 如果Outlook 2007运行中，关闭.
5.启动Outlook2007, 此时系统托盘区已经有一个Outlook2007的小图标了, 当你把Outlook2007最小化的时候, 它就会自己缩到托盘区了.
最后不得不感叹一句，这年头，微软的东西也设计得不易用啊~~
数据源架构模式笔记
一、表数据入口
表数据入口半酣了用于访问单个表的或视图的所有SQL，如CRUD操作，其他代码调用它的方法来实现所有与数据库的交互。
表数据入口很简单，一般包括几个从数据库中干活去数据的查找方法以及更新删除放放风每个方法都将输入参数映射为一个SQL调用并在数据库链接上执行改语句。由于表数据入口用于数据读写，所以通常是无状态的。
使用时机：
1、可以和表模块一起很好的使用，它称身隔一个记录集数据结构由表模块处理。
2、特别适用于事务脚本。
3、通常表数据入口和领域模型很少一起使用，因为数据映射器更好地分离了领域模型和数据库。
二、行数据入口
行数据入口充当数据源中单条记录入口的对象，每行一个实例。行数据入口和单条记录机器相似的对象，如数据库中的一行。在该对象中数据库中每一列变成了一个域。行数据入口一般能实现从数据源类型到内存中类型的任意转换，这种转换很简单。这个模式保持一行中的数据以便客户可以直接访问行数据入口，行数据入口是每一个数据行的良好接口。这种方法尤其适用于事务脚本。
使用行数据入口通常非为两步：第一步是否真的需要用入口；第二步，是使用行数据入口还是表数据入口。
行数据入口能和数据映射其一起配合使用，尽管这样看起来有点多此一举，当行数据入口从元数据自动生成，而数据映射器由手动实现时，这种方法会很有效。
如果把事务脚本和行数据入口一起使用，可能会发现业务逻辑在多处脚本中重复出现，这些逻辑可能在行数据入口中有族谱那个，不断移动这些逻辑会使行数据入口演变成活动记录，活动记录很好，因为他减少了业务逻辑中的重复。