OUTLOOK2007最小化到托盘显示

由于公司的提供邮箱实在是小,而且几乎可以说是没有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、通常表数据入口和领域模型很少一起使用,因为数据映射器更好地分离了领域模型和数据库。

二、行数据入口

行数据入口充当数据源中单条记录入口的对象,每行一个实例。行数据入口和单条记录机器相似的对象,如数据库中的一行。在该对象中数据库中每一列变成了一个域。行数据入口一般能实现从数据源类型到内存中类型的任意转换,这种转换很简单。这个模式保持一行中的数据以便客户可以直接访问行数据入口,行数据入口是每一个数据行的良好接口。这种方法尤其适用于事务脚本。

使用行数据入口通常非为两步:第一步是否真的需要用入口;第二步,是使用行数据入口还是表数据入口。

行数据入口能和数据映射其一起配合使用,尽管这样看起来有点多此一举,当行数据入口从元数据自动生成,而数据映射器由手动实现时,这种方法会很有效。

如果把事务脚本和行数据入口一起使用,可能会发现业务逻辑在多处脚本中重复出现,这些逻辑可能在行数据入口中有族谱那个,不断移动这些逻辑会使行数据入口演变成活动记录,活动记录很好,因为他减少了业务逻辑中的重复。

wordpress的nginx rewrite规则

由于godaddy不稳定和龟速,终于把博客搬到自己的VPS上,并且换了一套皮 :) ,最近日子过得比较快,可能因为事情比较多的缘故,最近两个月写的代码,超过我过去半年的写的代码的总和 :(
废话少说,直接上wordpress Nginx的rewrite规则,我的博客版本是2.8.5,一切正常,其他的不敢保证

if (-d $request_filename){
rewrite ^/(.*)([^/])$ $1$2/ permanent;
}
if (-f $request_filename/index.html){
rewrite (.*) $1/index.html break;
}
if (-f $request_filename/index.php){
rewrite (.*) $1/index.php;
}
if (!-f $request_filename){
rewrite (.*) /index.php;
}

第一条在很多Nginx主机上是默认就可以进行301 move的,意思是:如果请求的是目录,那么将请求rewrite到这个目录里面,不加这一条可能会导致二级或者三级目录无法访问,比如请求地址是http://www.abc.com/abc, abc是一个目录,abc中有一个index.html页面,还有一个名为style的目录,index.html 引用style中的css,js等文件,并且引用方式为相对地址,类似这样的结构:<script type=“text/javascript” src=”style/lib/jquery.js></script>,那么除index.html能被请求到之外,index.html中引用的所有文件的请求,都将是404

后面三条网上到处都是,如果你不是跟我一样,在Web根目录下放一些jquery,mysql之类的手册,后面三条就足够使用。包括你使用伪静态化

VPS上安装Centos的几个错误解决

error: C++ compiler cannot create executables….

安装相关开发包:

  • yum install gcc gcc-c++ gcc-g77 autoconf automake flex bison bzip2-devel zlib-devel ncurses-devel libjpeg-devel libpng-devel libtiff-devel freetype-devel pam-devel

Debian:

  • apt-get install gcc g++ build-essential

VPS为了保证效率和最小化安装,很多东西都没有所以出现上面的错误,有个偷懒的方法就是:

  • yum groupinstall ‘Development Tools’

这样和我们本地安装时勾选development tools的效果是一样的,什么编辑器啊,make,automake之类的都有了。

configure: error: *** libmcrypt was not found

安装libmcypt时,用默认的./configure && make && make install后,在下一步安装mcrypt会出现上面的错误,并不是libmcypt 没有安装好,而是没有加到默认的path中,做个软连接即可:

  • ln -s /usr/local/bin/libmcrypt-config /usr/bin/libmcrypt-config

编译PHP带上–with-xmlpr参数时出现:configure: error: XML configuration could not be found 错误

  • yum -y install libxml2 libxml2-devel

Notice: Following unknown configure options were used:

  • –enable-fastcgi
  • –enable-force-cgi-redirect
  • –enable-discard-path

php 5.3.0 发现在默认状态下,已经开始支持 fastcgi了,不用再费劲再写配置参数了,如果写了,会提示如上错误信息

undefined reference to libiconv_open错误

打开Makefile大约在85行的EXTRA_LIBS = ….. -lcrypt 在最后加上 -liconv,例如:EXTRA_LIBS = ….. -lcrypt -liconv然后重新再次 make 即可

《企业应用架构模式》笔记一

企业应用

  • 定义:  企业应用一般都涉及到持久化数据。
  • 企业应用一般都涉及大量数据
  • 企业应用还涉及很多人同时访问
  • 企业应用还涉及大量操作数据的用户界面屏幕。
  • 企业应用很少独立存在,通常需要与散布在企业周围的其他企业应用集成。(技术多样化,协议多样化)

可伸缩性:

  • 响应时间
  • 响应性
  • 等待时间
  • 吞吐率
  • 负载
  • 负载敏度
  • 效率

领域逻辑组织方式:

  • 1.事务脚本
  • 2.领域模型
  • 3.表模块

服务层:

  • 表现逻辑和领域逻辑之间的交互完全通过服务层,就像应用程序API一样。
  • 如果确实需要,使用最小化的服务层

映射到关系数据库:

  • 1. 为查询语句返回的每一行产生一个它的实例,种种行数据入口就行是面向对象方式来看待数据。
  • 2.许多环境提供记录集,这种表和数据行的一种通用数据结构,用来模拟数据库的表格属性。
  • 如果使用记录集,对于数据库的每个表只需要一个对象来管理。

并发:

  • 解决方案有两个,一个是隔离,一个是不变性
  • 隔离是学习操作系统分配内存的方式,让一个单元只允许一个进程访问
  • 只有共享数据可以被修改的情况下并发问题才会出现。

事务属性:

  • 1.原子性  在事务里面所有的动作要么全部完成,要么全部回滚
  • 2.一致性  在事务开始和结束的时候,所有的资源要保持一致
  • 3.隔离性  在事务完成之后,他的结果对于其他事务才是可见的
  • 4.持久性  已提交的事务必须是可持久性的,即任何崩溃都是可以保存下来的

事务资源:

  • 定义:用事务来控制并发的过程
  • 长事务:跨越多个事务请求的事务
  • 请求事务:在请求开始时启动,在请求结束时完成的事务
  • 延迟事务:在外界事务读取或加载完成时,启动的事务,即在更新时才启动的事务

事务建议:

  • 1.使用事务的时间应尽可能的短,尽量避免长事务,因为事务进行时间越长,锁定的东西越多,
  • 在没有任何并发控制的情况下,事务时间越长越有机会导致数据的不一致,造成事务的无效回滚,使用延迟事务能够提供事务的性能。
  • 2.使用事务时应该清楚的知道锁定的到底是什么,对于数据库来说,锁定的是被访问的行级数据。
  • 3.如果一个事务要求锁定的行数超过数据库最大可支持事务锁定,那么会上升为表级锁,即锁升级。锁升级显然对并发造成很大的影响。
  • 这也是为什么不能在领域层超类型级别上使用“对象”表的原因。
  • 4.尽可能的减少事务隔离

事务隔离级别(由低到高):

  • 1.读未提交
  • 2.读已提交
  • 3.可重复读
  • 4.可串行化

业务事务和系统事务

  • 系统事务:关系数据库系统和事务监视所支持的事务
  • 业务事务:业务事务是保证用户操作行为完整的事务

离线并发控制模式:

  • 1.应该尽可能让事务系统自己来处理并发问题。
  • 这样做会损失部分系统伸缩性
  • 2.乐观离线锁
  • 优点:易于编程实现,提供最好的灵活性
  • 缺点:只能在提交数据时才发现事务将要失败
  • 3.悲观离线锁:
  • 优点:尽可能早的发现错误
  • 缺点:不利于编程实现,丧失部分灵活性

应用服务器并发:

  • 1.显式多线程
  • 缺点:构建复杂,难以调试
  • 2.每个会话一个进程,配合进程池来提高效率
  • 3.每个会话一个线程,线程崩溃可能会导致整个进程垮掉
  • 4.中间层屏蔽,比如J2EE中的EJB