首页 新闻 论坛 群组 Blog 文档 下载 读书 Tag 网摘 搜索 .NET Java 游戏 视频 人才 外包 数据库 第二书店 程序员

java060515/ 


共2268个网摘 [ 1  2  3  4  5  6 ... 76 ]  下一页  |  访问java060515的个人空间

ASP.NET中常用的26个优化性能方法

java060515收录,使用标签:.NET,时间:2008-7-17 15:43:59 | 相关网摘我也收藏

1. 数据库访问性能优化 
 
数据库的连接和关闭

访问数据库资源需要创建连接、打开连接和关闭连接几个操作。这些过程需要多次与数据库交换信息以通过身份验证,比较耗费服务器资源。ASP.NET中提供了连接池(Connection Pool)改善打开和关闭数据库对性能的影响。系统将用户的数据库连接放在连接池中,需要时取出,关闭时收回连接,等待下一次的连接请求。连接池的大小是有限的,如果在连接池达到最大限度后仍要求创建连接,必然大大影响性能。因此,在建立数据库连接后只有在真正需要操作时才打开连接,使用完毕后马上关闭,从而尽量减少数据库连接打开的时间,避免出现超出连接限制的情况。   

使用存储过程  
 
存储过程是存储在服务器上的一组预编译的SQL语句,类似于DOS系统中的批处理文件。存储过程具有对数据库立即访问的功能,信息处理极为迅速。使用存储过程可以避免对命令的多次编译,在执行一次后其执行规划就驻留在高速缓存中,以后需要时只需直接调用缓存中的二进制代码即可。另外,存储过程在服务器端运行,独立于ASP.NET程序,便于修改,最重要的是它可以减少数据库操作语句在网络中的传输。

优化查询语句
  
ASP.NET中ADO连接消耗的资源相当大,SQL语句运行的时间越长,占用系统资源的时间也越长。因此,尽量使用优化过的SQL语句以减少执行时间。比如,不在查询语句中包含子查询语句,充分利用索引等。   

2. 字符串操作性能优化 
 
使用值类型的ToString方法
  
在连接字符串时,经常使用"+"号直接将数字添加到字符串中。这种方法虽然简单,也可以得到正确结果,但是由于涉及到不同的数据类型,数字需要通过装箱操作转化为引用类型才可以添加到字符串中。但是装箱操作对性能影响较大,因为在进行这类处理时,将在托管堆中分配一个新的对象,原有的值复制到新创建的对象中。使用值类型的ToString方法可以避免装箱操作,从而提高应用程序性能。   

运用StringBuilder类   

String类对象是不可改变的,对于String对象的重新赋值在本质上是重新创建了一个String对象并将新值赋予该对象,其方法ToString对性能的提高并非很显著。在处理字符串时,最好使用StringBuilder类,其.NET 命名空间是System.Text。该类并非创建新的对象,而是通过Append,Remove,Insert等方法直接对字符串进行操作,通过ToString方法返回操作结果。   其定义及操作语句如下所示:


int num;   System.Text.StringBuilder str = new System.Text.StringBuilder(); //创建字符串   str.Append(num.ToString()); //添加数值num   Response.Write(str.ToString); //显示操作结果3. 优化 Web 服务器计算机和特定应用程序的配置文件以符合您的特定需要

默认情况下,ASP.NET 配置被设置成启用最广泛的功能并尽量适应最常见的方案。因此,应用程序开发人员可以根据应用程序所使用的功能,优化和更改其中的某些配置,以提高应用程序的性能。下面的列表是您应该考虑的一些选项。

仅对需要的应用程序启用身份验证。

默认情况下,身份验证模式为 Windows,或集成 NTLM。大多数情况下,对于需要身份验证的应用程序,最好在 Machine.config 文件中禁用身份验证,并在 Web.config 文件中启用身份验证。根据适当的请求和响应编码设置来配置应用程序。ASP.NET 默认编码格式为 UTF-8。如果您的应用程序为严格的 ASCII,请配置应用程序使用 ASCII 以获得稍许的性能提高。
  
考虑对应用程序禁用 AutoEventWireup。

在 Machine.config 文件中将 AutoEventWireup 属性设置为 false,意味着页面不将方法名与事件进行匹配和将两者挂钩(例如 Page_Load)。如果页面开发人员要使用这些事件,需要在基类中重写这些方法(例如,需要为页面加载事件重写 Page.OnLoad,而不是使用 Page_Load 方法)。如果禁用 AutoEventWireup,页面将通过将事件连接留给页面作者而不是自动执行它,获得稍许的性能提升。

从请求处理管线中移除不用的模块。

默认情况下,服务器计算机的 Machine.config 文件中 节点的所有功能均保留为激活。根据应用程序所使用的功能,您可以从请求管线中移除不用的模块以获得稍许的性能提升。检查每个模块及其功能,并按您的需要自定义它。例如,如果您在应用程序中不使用会话状态和输出缓存,则可以从 列表中移除它们,以便请求在不执行其他有意义的处理时,不必执行每个模块的进入和离开代码。

4. 一定要禁用调试模式  

在部署生产应用程序或进行任何性能测量之前,始终记住禁用调试模式。如果启用了调试模式,应用程序的性能可能受到非常大的影响。   

5. 对于广泛依赖外部资源的应用程序,请考虑在多处理器计算机上启用网络园艺  

ASP.NET 进程模型帮助启用多处理器计算机上的可缩放性,将工作分发给多个进程(每个CPU一个),并且每个进程都将处理器关系设置为其 CPU。此技术称为网络园艺。如果应用程序使用较慢的数据库服务器或调用具有外部依赖项的 COM 对象(这里只是提及两种可能性),则为您的应用程序启用网络园艺是有益的。但是,在决定启用网络园艺之前,您应该测试应用程序在网络园中的执行情况。   

6. 只要可能,就缓存数据和页输出  

ASP.NET 提供了一些简单的机制,它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据。另外,通过设计要进行缓存的页和数据请求(特别是在站点中预期将有较大通讯量的区域),可以优化这些页的性能。与 .NET Framework 的任何 Web 窗体功能相比,适当地使用缓存可以更好的提高站点的性能,有时这种提高是超数量级的。使用 ASP.NET 缓存机制有两点需要注意。首先,不要缓存太多项。缓存每个项均有开销,特别是在内存使用方面。不要缓存容易重新计算和很少使用的项。其次,给缓存的项分配的有效期不要太短。很快到期的项会导致缓存中不必要的周转,并且经常导致更多的代码清除和垃圾回收工作。若关心此问题,请监视与 ASP.NET Applications 性能对象关联的 Cache Total Turnover Rate 性能计数器。高周转率可能说明存在问题,特别是当项在到期前被移除时。这也称作内存压力。


7. 选择适合页面或应用程序的数据查看机制  

根据您选择在 Web 窗体页显示数据的方式,在便利和性能之间常常存在着重要的权衡。例如,DataGrid Web 服务器控件可能是一种显示数据的方便快捷的方法,但就性能而言它的开销常常是最大的。在某些简单的情况下,您通过生成适当的 HTML 自己呈现数据可能很有效,但是自定义和浏览器定向会很快抵销所获得的额外功效。Repeater Web 服务器控件是便利和性能的折衷。它高效、可自定义且可编程。   

8. 将 SqlDataReader 类用于快速只进数据游标  

SqlDataReader 类提供了一种读取从 SQL Server 数据库检索的只进数据流的方法。如果当创建 ASP.NET 应用程序时出现允许您使用它的情况,则 SqlDataReader 类提供比 DataSet 类更高的性能。情况之所以这样,是因为 SqlDataReader 使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。另外,SqlDataReader 类实现 IEnumerable 接口,该接口也允许您将数据绑定到服务器控件。有关更多信息,请参见 SqlDataReader 类。有关 ASP.NET 如何访问数据的信息,请参见通过 ASP.NET 访问数据。   

9. 将 SQL Server 存储过程用于数据访问  

在 .NET Framework 提供的所有数据访问方法中,基于 SQL Server 的数据访问是生成高性能、可缩放 Web 应用程序的推荐选择。使用托管 SQL Server 提供程序时,可通过使用编译的存储过程而不是特殊查询获得额外的性能提高。   

10. 避免单线程单元 (STA) COM 组件  

默认情况下,ASP.NET 不允许任何 STA COM 组件在页面内运行。若要运行它们,必须在 .aspx 文件内将 ASPCompat=true 属性包含在 @ Page 指令中。这样就将执行用的线程池切换到 STA 线程池,而且使 HttpContext 和其他内置对象可用于 COM 对象。前者也是一种性能优化,因为它避免了将多线程单元 (MTA) 封送到 STA 线程的任何调用。使用 STA COM 组件可能大大损害性能,应尽量避免。若必须使用 STA COM 组件,如在任何 interop 方案中,则应在执行期间进行大量调用并在每次调用期间发送尽可能多的信息。另外,小心不要在构造页面期间创建任何 STA COM 组件。例如下面的代码中,在页面构造时将实例化由某个线程创建的 MySTAComponent,而该线程并不是将运行页面的 STA 线程。这可能对性能有不利影响,因为要构造页面就必须完成 MTA 和 STA 线程之间的封送处理。


<%@ Page Language="VB" ASPCompat="true" %> Dim myComp as new MySTAComponent() Public Sub Page_Load() myComp.Name = "Bob" End Sub <% Response.Write(myComp.SayHello) %>


首选机制是推迟对象的创建,直到以后在 STA 线程下执行上述代码,如下面的例子所示。




<%@ Page Language="VB" ASPCompat="true" %> Dim myComp Public Sub Page_Load() myComp = new MySTAComponent() myComp.Name = "Bob" End Sub <% Response.Write(myComp.SayHello) %>

推荐的做法是在需要时或者在 Page_Load 方法中构造任何 COM 组件和外部资源。永远不要将任何 STA COM 组件存储在可以由构造它的线程以外的其他线程访问的共享资源里。这类资源包括像缓存和会话状态这样的资源。即使 STA 线程调用 STA COM 组件,也只有构造此 STA COM 组件的线程能够实际为该调用服务,而这要求封送处理对创建者线程的调用。此封送处理可能产生重大的性能损失和可伸缩性问题。在这种情况下,请研究一下使 COM 组件成为 MTA COM 组件的可能性,或者更好的办法是迁移代码以使对象成为托管对象。   

11. 将调用密集型的 COM 组件迁移到托管代码  

.NET Framework 提供了一个简单的方法与传统的 COM 组件进行交互。其优点是可以在保留现有投资的同时利用新的平台。但是在某些情况下,保留旧组件的性能开销使得将组件迁移到托管代码是值得的。每一情况都是不一样的,决定是否需要迁移组件的最好方法是对 Web 站点运行性能测量。建议您研究一下如何将需要大量调用以进行交互的任何COM 组件迁移到托管代码。许多情况下不可能将旧式组件迁移到托管代码,特别是在最初迁移 Web 应用程序时。在这种情况下,最大的性能障碍之一是将数据从非托管环境封送到托管环境。因此,在交互操作中,请在任何一端执行尽可能多的任务,然后进行一个大调用而不是一系列小调用。例如,公共语言运行库中的所有字符串都是 Unicode 的,所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式。另外,一处理完任何 COM 对象或本机资源就释放它们。这样,其他请求就能够使用它们,并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题。   

12. 在 Visual Basic .NET 或 JScript. 代码中使用早期绑定  

以往,开发人员喜欢使用 Visual Basic、VBScript. 和 JScript. 的原因之一就是它们所谓“无类型”的性质。变量不需要显式类型声明,并能够简单地通过使用来创建它们。当从一个类型到另一个类型进行分配时,转换将自动执行。不过,这种便利会大大损害应用程序的性能。Visual Basic 现在通过使用 Option Strict 编译器指令来支持类型安全编程。为了向后兼容,默认情况下,ASP.NET 不启用该选项。但是,为了得到最佳性能,强烈建议在页中启用该选项。若要启用 Option Strict,请将 Strict 属性包括在 @ Page 指令中,或者,对于用户控件,请将该属性包括在 @ Control 指令中。下面的示例演示了如何设置该属性,并进行了四个变量调用以显示使用该属性是如何导致编译器错误的。

<%@ Page Language="VB" Strict="true" %> <% Dim B Dim C As String ' This will cause a compiler error. A = "Hello" ' This will cause a compiler error. B = "World" ' This will not cause a compiler error. C = "!!!!!!" ' But this will cause a compiler error. C = 0 %> JScript. .NET 也支持无类型编程,但它不提供强制早期绑定的编译器指令。若发生下面任何一种情况,则变量是晚期绑定的:被显式声明为 Object,是无类型声明的类的字段,是无显式类型声明的专用函数或方法成员,并且无法从其使用推断出类型。   最后一个差别比较复杂,因为如果 JScript. .NET 编译器可以根据变量的使用情况推断出类型,它就会进行优化。在下面的示例中,变量 A 是早期绑定的,但变量 B 是晚期绑定的。

var A;   var B;   A = "Hello";   B = "World";   B = 0; 为了获得最佳的性能,当声明 JScript. .NET 变量时,请为其分配一个类型。例如,var A : String。

13. 使请求管线内的所有模块尽可能高效  

请求管线内的所有模块在每次请求中都有机会被运行。因此,当请求进入和离开模块时快速地触发代码至关重要,特别是在不使用模块功能的代码路径里。分别在使用及不使用模块和配置文件时执行吞吐量测试,对确定这些方法的执行速度非常有用。

14. 使用 HttpServerUtility.Transfer 方法在同一应用程序的页面间重定向  

采用 Server.Transfer 语法,在页面中使用该方法可避免不必要的客户端重定向。
  
15. 必要时调整应用程序每个辅助进程的线程数  

ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够 CPU 功率的应用程序,该结构将根据可用于请求的 CPU 功率,来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下,线程门控算法不是很有效。通过使用与 ASP.NET Applications 性能对象关联的 Pipeline Instance Count 性能计数器,可以在 PerfMon 中监视线程门控。当页面调用外部资源,如数据库访问或 XML Web services 请求时,页面请求通常停止并释放 CPU。如果某个请求正在等待被处理,并且线程池中有一个线程是自由的,那么这个正在等待的请求将开始被处理。遗憾的是,有时这可能导致 Web 服务器上存在大量同时处理的请求和许多正在等待的线程,而它们对服务器性能有不利影响。通常,如果门控因子是外部资源的响应时间,则让过多请求等待资源,对 Web 服务器的吞吐量并无帮助。为缓和这种情况,可以通过更改 Machine.config 配置文件节点的 maxWorkerThreads 和 maxIOThreads 属性,手动设置进程中的线程数限制。   

注意:辅助线程是用来处理 ASP.NET 请求的,而 IO 线程则是用于为来自文件、数据库或 XML Web services 的数据提供服务的。分配给这些属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机,最大数是设置值的两倍。对于四处理器计算机,最大值是设置值的四倍。无论如何,对于有四个或八个 CPU 的计算机,最好更改默认值。对于有一个或两个处理器的计算机,默认值就可以,但对于有更多处理器的计算机的性能,进程中有一百或两百个线程则弊大于利。注意进程中有太多线程往往会降低服务器的速度,因为额外的上下文交换导致操作系统将 CPU 周期花在维护线程而不是处理请求上。   

16. 适当地使用公共语言运行库的垃圾回收器和自动内存管理  

小心不要给每个请求分配过多内存,因为这样垃圾回收器将必须更频繁地进行更多的工作。另外,不要让不必要的指针指向对象,因为它们将使对象保持活动状态,并且应尽量避免含 Finalize 方法的对象,因为它们在后面会导致更多的工作。特别是在 Finalize 调用中永远不要释放资源,因为资源在被垃圾回收器回收之前可能一直消耗着内存。最后这个问题经常会对 Web 服务器环境的性能造成毁灭性的打击,因为在等待 Finalize 运行时,很容易耗尽某个特定的资源。   

17. 如果有大型 Web 应用程序,可考虑执行预批编译  

每当发生对目录的第一次请求时都会执行批编译。如果目录中的页面没有被分析并编译,此功能会成批分析并编译目录中的所有页面,以便更好地利用磁盘和内存。如果这需要很长时间,则将快速分析并编译单个页面,以便请求能被处理。此功能带给 ASP.NET 性能上的好处,因为它将许多页面编译为单个程序集。从已加载的程序集访问一页比每页加载新的程序集要快。批编译的缺点在于:如果服务器接收到许多对尚未编译的页面的请求,那么当 Web 服务器分析并编译它们时,性能可能较差。为解决这个问题,可以执行预批编译。为此,只需在应用程序激活之前向它请求一个页面,无论哪页均可。然后,当用户首次访问您的站点时,页面及其程序集将已被编译。没有简单的机制可以知道批编译何时发生。需一直等到 CPU 空闲或者没有更多的编译器进程(例如 csc.exe(C# 编译器)或 vbc.exe(Visual Basic 编译器))启动。还应尽量避免更改应用程序的 \bin 目录中的程序集。更改页面会导致重新分析和编译该页,而替换 \bin 目录中的程序集则会导致完全重新批编译该目录。在包含许多页面的大规模站点上,更好的办法可能是根据计划替换页面或程序集的频繁程度来设计不同的目录结构。不常更改的页面可以存储在同一目录中并在特定的时间进行预批编译。经常更改的页面应在它们自己的目录中(每个目录最多几百页)以便快速编译。Web 应用程序可以包含许多子目录。批编译发生在目录级,而不是应用程序级。

18. 不要依赖代码中的异常  

因为异常大大地降低性能,所以您不应该将它们用作控制正常程序流程的方式。如果有可能检测到代码中可能导致异常的状态,请执行这种操作。不要在处理该状态之前捕获异常本身。常见的方案包括:检查 null,分配给将分析为数字值的 String 一个值,或在应用数学运算前检查特定值。下面的示例演示可能导致异常的代码以及测试是否存在某种状态的代码。两者产生相同的结果。


 try   {   result = 100 / num;   }   catch (Exception e)   {   result = 0;   }   // ...to this.   if (num != 0)   result = 100 / num;   else   result = 0;

19. 使用 HttpResponse.Write 方法进行字符串串联

该方法提供非常有效的缓冲和连接服务。但是,如果您正在执行广泛的连接,请使用多个 Response.Write 调用。下面示例中显示的技术比用对 Response.Write 方法的单个调用连接字符串更快。




Response.Write("a");   Response.Write(myString);   Response.Write("b");   Response.Write(myObj.ToString());   Response.Write("c");   Response.Write(myString2);   Response.Write("d");20. 除非有特殊的原因要关闭缓冲,否则使其保持打开

禁用 Web 窗体页的缓冲会导致大量的性能开销。   

21. 只在必要时保存服务器控件视图状态  

自动视图状态管理是服务器控件的功能,该功能使服务器控件可以在往返过程上重新填充它们的属性值(您不需要编写任何代码)。但是,因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器,所以该功能确实会对性能产生影响。您应该知道在哪些情况下视图状态会有所帮助,在哪些情况下它影响页的性能。例如,如果您将服务器控件绑定到每个往返过程上的数据,则将用从数据绑定操作获得的新值替换保存的视图状态。在这种情况下,禁用视图状态可以节省处理时间。默认情况下,为所有服务器控件启用视图状态。若要禁用视图状态,请将控件的EnableViewState 属性设置为 false,如下面的 DataGrid 服务器控件示例所示。




您还可以使用 @ Page 指令禁用整个页的视图状态。当您不从页回发到服务器时,这将十分有用:


<%@ Page EnableViewState="false" %>

注意:@ Control 指令中也支持 EnableViewState 属性,该指令允许您控制是否为用户控件启用视图状态。若要分析页上服务器控件使用的视图状态的数量,请(通过将 trace="true" 属性包括在 @ Page 指令中)启用该页的跟踪并查看 Control Hierarchy 表的 Viewstate 列。有关跟踪和如何启用它的信息,请参见 ASP.NET 跟踪。

22. 避免到服务器的不必要的往返过程  

虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能,但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。通常,只有在检索或存储数据时,您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如,从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常,如果不需要将信息传递到服务器以将其存储在数据库中,那么您不应该编写导致往返过程的代码。如果您开发自定义服务器控件,请考虑让它们为支持 ECMAScript. 的浏览器呈现客户端代码。通过以这种方式使用服务器控件,您可以显著地减少信息被不必要的发送到 Web 服务器的次数。

使用 Page.IsPostBack 避免对往返过程执行不必要的处理

如果您编写处理服务器控件回发处理的代码,有时可能需要在首次请求页时执行其他代码,而不是当用户发送包含在该页中的 HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的。

使用 Page.IsPostBack 属性有条件地执行代码

例如,下面的代码演示如何创建数据库连接和命令,该命令在首次请求该页时将数据绑定到 DataGrid 服务器控件。


void Page_Load(Object sender, EventArgs e)   {   // Set up a connection and command here.   if (!Page.IsPostBack)   {   String query = "select * from Authors where FirstName like '%JUSTIN%'";   myCommand.Fill(ds, "Authors");   myDataGrid.DataBind();   }   }

由于每次请求时都执行 Page_Load 事件,上述代码检查 IsPostBack 属性是否设置为 false。如果是,则执行代码。如果该属性设置为 true,则不执行代码。注意 如果不运行这种检查,回发页的行为将不更改。Page_Load 事件的代码在执行服务器控件事件之前执行,但只有服务器控件事件的结果才可能在输出页上呈现。如果不运行该检查,仍将为 Page_Load 事件和该页上的任何服务器控件事件执行处理。   

23. 当不使用会话状态时禁用它  

并不是所有的应用程序或页都需要针对于具体用户的会话状态,您应该对任何不需要会话状态的应用程序或页禁用会话状态。   若要禁用页的会话状态,请将 @ Page 指令中的 EnableSessionState 属性设置为 false。例如:



<%@ Page EnableSessi %> 注意:如果页需要访问会话变量,但不打算创建或修改它们,则将@ Page 指令中的 EnableSessionState 属性设置为ReadOnly。还可以禁用 XML Web services 方法的会话状态。有关更多信息,请参见使用 ASP.NET 和 XML Web services 客户端创建的 XML Web services。若要禁用应用程序的会话状态,请在应用程序 Web.config 文件的 sessionstate 配置节中将 mode 属性设置为 off。例如:



24. 仔细选择会话状态提供程序  

ASP.NET 为存储应用程序的会话数据提供了三种不同的方法:进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。每种方法都有自己的优点,但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据,则建议您使用进程内提供程序。进程外解决方案主要用于跨多个处理器或多个计算机缩放应用程序,或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息,请参见 ASP.NET 状态管理。   

25. 不使用不必要的Server Control

ASP.net中,大量的服务器端控件方便了程序开发,但也可能带来性能的损失,因为用户每操作一次服务器端控件,就产生一次与服务器端的往返过程。因此,非必要,应当少使用Server Control。   

26. ASP.NET应用程序性能测试  

在对ASP.NET应用程序进行性能测试之前,应确保应用程序没有错误,而且功能正确。具体的性能测试可以采用以下工具进行:Web Application Strees Tool (WAS)是Microsoft发布的一个免费测试工具,可以从http://webtool.rte.microsoft.com/上下载。它可以模拟成百上千个用户同时对web应用程序进行访问请求,在服务器上形成流量负载,从而达到测试的目的,可以生成平均TTFB、平均TTLB等性能汇总报告。Application Center Test (ACT) 是一个测试工具,附带于Visual Studio.NET的企业版中,是Microsoft正式支持的web应用程序测试工具。它能够直观地生成图表结果,功能比WAS多,但不具备多个客户机同时测试的能力。服务器操作系统"管理工具"中的"性能"计数器,可以对服务器进行监测以了解应用程序性能。   

结论:

对于网站开发人员来说,在编写ASP.NET应用程序时注意性能问题,养成良好的习惯,提高应用程序性能,至少可以推迟必需的硬件升级,降低网站的成本。


IE8 Beta 2即将发布,您的网站准备好了吗?

java060515收录,使用标签:.NET,时间:2008-7-17 15:40:09 | 相关网摘我也收藏

在奥运会期间, IE8 Beta2将会发布,而且随着英文版的发布,中文版也会在第一波当中进行发布。

IE 8将会是Internet Explorer历史上最重要的一个版本发布,除了其带有中国传统的吉祥数字“8”以外,最主要的是其对标准的兼容性上得到了极高的增强,这对于网页开发人员来说,最大的便利就是不用再为每种浏览器(甚至某种浏览器的不同版本)开发不同的CSS来进行适应。以后网页开发人员只需要兼容W3C的标准即可,而不需要把过度的精力放在不同浏览器标准的相异性上。发布时间在即,那么您的网站是否已经准备好了呢?

1) 兼容性考虑

目前的网站由于各种历史原因,可能针对不同的浏览器设置了不同的CSS文件。而针对IE 8,可能大部分网站尚没有做好准备。可能很多朋友知道,IE 8带有一个“切换IE 7模仿模式”的按钮,而且在Beta 1以及Beta 2期间,这个按钮是设置在默认选中状态。但是在IE 8正式发布的时候,该按钮默认将会是非选中状态,这就表示着如果一个网站没有做任何准备功课,在IE 8下将会以严格模式来常解析CSS。

前段时间,我与合作伙伴见面时,曾经特意使用IE 8 Beta 2的严格模式浏览过大部分合作伙伴的网页,都会出现或多或少的显示变形的问题,使得网站无法进行正确浏览。如果您的网站尚未做过IE 8的兼容性测试,建议您尽快下载IE 8的Beta 1,并且将其切换到IE 8严格模式,对您的网站进行浏览。

如果您发现问题,并且感觉在短期内无法修复,您也可以通过在页面当中添加Meta标签,在服务器端强制IE 8使用“IE 7模仿模式”,做法很简单:

a. 针对全站页面: 您可以修改Web服务器(如Apache/IIS/Resin等)的HTTP头信息,在其中增加以下指令: X-UA-Compatible: IE=EmulateIE7。这个是我个人强烈推荐的做法,在您无法进行全站测试的情况下,可以先使用此方式使IE 8的严格模式暂时失效。

b. 针对单独页面:如果您的网站大部分页面在IE 8严格模式下显示正常,只有个别页面出现问题,建议在出现问题的页面的页首,即Head标签内添加以下Meta标签:



更多信息,请参考: http://support.microsoft.com/kb/952030/

2) 制作Activity以及WebSlice

IE 8在Beta 1期间曝光了两个新特性,即Activity(活动)以及WebSlice(源剪辑),目前国内很多网站已经基于Activity以及WebSlice制作了相关的内容,在IE 8 Beta 2期间,您会发现更多的网站会发布这些实用的小工具。以下是目前已经对外发布的一些网站:

a. 淘宝:http://ie8.taobao.com

b. 网易:http://ie8.163.com

c. 百度:http://stock.baidu.com/ie8/ie8.html

d. 腾讯:http://labs.qq.com/e/49/

甚至包括.NET开发人员常去的博客园也已经发布了其最新文章的Web Slice,有兴趣的话可以使用IE 8 Beta 1来访问博客园的首页。另外,如果您也使用Firefox 3,您可以发现已经有人开发了面向Firefox 3的Activity以及WebSlice插件。

Activity的使用场景:您的网站提供一系列的服务,允许贵网站的用户通过在其它网站的主动操作来调用此服务。比如假设您是一个财经网站,提供查询股票/基金信息的服务,通过Activity,您可以让您的用户在其它网站上浏览股评信息时,不需要跳转到贵网站,即可以通过右键菜单调用贵网站的相应服务。如果感兴趣,可以下载Activity开发白皮书。

WebSlice的使用场景:您的网站提供一些实时性信息,比如新闻、股票信息等,而希望用户可以在不返回相应页面的时候,当内容发生改动时,即可以推送给最终用户,您可以选择WebSlice。而开发代价仅仅只是将页面当中的某一个标签内的“Class”元素设置为“hslice”这个特殊名称即可,详细信息请阅读WebSlice开发白皮书。

另外,在IE 8 Beta 2发布时,微软将会发布一个面向IE 8全新的Gallery网站,用以搜索各个网站开发的WebSlice/Activity等面向IE 8新特性的组件,并且提供最终用户评估/下载,如果您希望您开发的WebSlices/Activity能够得到用户的青睐,那么就从现在开始吧:早起的鸟儿有虫吃。 :)

3) 其它

IE 8 Beta 2发布时,还将会带来一系列的新特性,在前段时期,已经面向国内一些领先的网站进行过交流,很多合作伙伴都非常感兴趣,并且正在开发此上的服务,相信在奥运会期间大家会看到此类的成果(依据NDA协议,此类网站也已经从微软拿到了IE 8 Beta 2的早期内部版本)。微软也将会举办一系列的市场活动,用以推广我们的合作伙伴所开发的各种面向IE 8的新的服务。

IE 8 Beta 2即将发布,无论您是企业网站的网页设计人员,还是个人网站的站长,都需要尽快为IE 8做好准备。 希望本文对您有帮助。



软件开发项目风险管理的几点体会

java060515收录,使用标签:项目管理,时间:2008-7-17 15:35:27 | 相关网摘我也收藏

参与过大型软件项目的人都会认识到许多事情都可能出错,一但出错就可能给项目带来危害、损失或其它不利影响。风险是在项目中发生的一系列事件或不利结果的可能性。软件开发是一项高风险的活动,在项目开发过程的任何一个阶段都可能存在风险。采取积极的风险管理方式,可以使项目进程更加平稳,可以获得很高的跟踪和控制项目的能力,可以规避、转移风险,或缓解风险带来的不利影响。风险管理是对项目风险进行识别、分析、应对和监控的过程,是项目管理中很重要的管理活动,有效的实施软件风险管理是软件项目开发工作顺利完成的保证。风险管理的达成必须包括三个要素:首先,在项目开发计划中必须制定风险管理计划;第二,在项目预算中必须包含解决风险所需的经费;第三,评估风险时,风险的影响也必须纳入项目计划中。

下面就软件开发过程中经常发生的风险,谈谈我们采取的预防措施。

2.需求不明确
需求不明确是软件开发过程中经常可能遇到的问题,这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过程的生命周期各阶段中,需求不明确所造成的浪费是最大的,必须尽早尽可能解决。确定用户需求是件非常困难的事情,我们常常从以下几个方面着手处理需求不明确问题:

(1) 让用户参与开发

提供一个协作开发环境,让用户参与开发过程。如果条件不允许,至少应该在每次迭代的需求分析和系统测试阶段,让客户能够参与开发。

在选择参与开发过程的用户时,一方面,要尽可能争取精通业务或计算机技术的用户参与。另一方面,如果开发的产品要在不同规模、不同类型的企业应用,应该选择具有代表性的用户参与。

仅仅让用户参与是不够的,应该采取一定的激励措施,提高用户参与的积极性。

(2) 开发用户界面原型

用户通常不善于精确描述自己的业务需求,系统分析员需要借助白板、白纸等沟通方式,帮助用户清楚表述需求。然后,开发一个用户界面原型,以便用户确认需求。用户界面原型的作用仅仅是收集用户需求,不应该再作它用,也不要给用户造成系统快要实现的错觉。

(3) 需求讨论会议

对于用户分布广、用户量大的项目,要全面收集用户需求,往往很困难,通常采取需求研计会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见,然后集中各地或各部门的用户代表,举办一次需求研讨会,通过会议方式收集需求。本方法适合于具有一定信息系统使用经验的用户。

(4) 强化需求分析与评审

首先,需求分析是项目成功的基础,需要引起足够的重视,并分配充足的时间和人力,要让有经验的系统分析员负责,切忌让项目新手或程序员负责。其次,要进行需求评审,尽可能让用户参与需求评审,不要让需求评审流于行式。第三,也是最重要的一点,通过评审的需求规格说明书,要让用户方签字,并作为项目合同的附件,对双方都具有约束力。在公司内部要将通过评审的需求规格说明书,纳入配置管理。

3.项目缺少可见性
当一个项目经理或一名开发者说已经完成了80%的任务,您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间,甚至永远都不能完成[1]。软件开发项目,往往在项目进度和软件质量方面缺少可见性,项目越缺少可见性,项目就越难以控制,项目就越有可能失败。我们可以通过迭代开发、技术评审、持续集成来增强项目的可见性。

(1) 迭代开发

采用迭代的开发模型,将产品的交付过程分为多个阶段,按照功能递增式交付。以下是一些典型的迭代:

一次简短的先期迭代,以建立规模和前景并确定商业理由;

一次精化迭代,其间将为稳定的构架划定基线;

一次构建迭代,其间将实现用例并充实构架;

几次产品化迭代,将产品转移到用户群。

每次迭代,都要充分接收用户的评审意见,以便为自我纠正。渐近式的功能交付,有利于降低开发人员的压力,增加用户的满意度,有利于增强项目的可见性,是最好的进展报告。

(2) 技术评审

技术评审是确保软件质量的重要环节,技术评审包括代码走查、会议评审和同行专家评审。代码走审可以是开发人员之间的交叉审查,或者是高级开发人员对普通开发人员的审查;会议评审一般应至少每两周进行一次,每次评审时间不宜太长;同行专家评审包括技术和业务两个方面的专家,经常性地让精通业务的用户专家参与项目评审,是项目成功的重要保证。

另外,充分利用质量审查的工具软件,也有利于提高代码质量。例如:在Eclipse开发环境中,可以集成Findbug、Checkstyle、PMD插件检查代码编写质量。

(3) 持续集成

持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度,并迅速发现集成过程中出现的问题并进行解决[1]。

开发小组应制定持续集成的制度,一般情况下每日构建一次,可以利用Ant等构建工具进行Java应用程序的构建。小组成员应在每个功能开发完成后,及时向版本控制系统(如CVS)提交代码,而且不应该向版本控制系统提交有问题(编译通不过)的代码。

每日构建、持续集成,让项目进度跟踪工作更加容易。当项目小组每天重新编译系统时,已完成与未完成的功能清楚可见,小组成员能够简单地从软件的表现知道距离整体完成还有多远。

4.新技术引入
技术创新是一种具有探索性、创造性的技术经济活动。在开发过程中引入新技术,不可避免地要遇到各种风险。通过T形软件开发、充分论证、多阶段评审、同行经验等措施可降低新技术风险。

(1) T形软件开发

在项目开发早期,开发小组应该建立系统的架构,解决关键技术难题、开发系统的基础构件,并对系统所需要应用的技术做深度探索。例如:基于JavaEE5构建全国联网售票系统,涉及到分布式事务处理、海量数据存储、异构平台互连等关键问题,应该优先处理这些问题;对开发所涉及到的EJB3、JSF、JBoss Seam、Eclipse RCP等技术,要做深度探索。




图1 在第一阶段以“T”形开发系统骨架[2]

越是技术复杂度高的项目,就越应该早地处理技术难题。如果在项目开发的中期或后期才发现架构有问题或是关键技术难题不能解决,则为时已晚。

(2) 充分论证

新技术开发是探索性很强的工作,潜在着许多失败的风险。在可行性分析阶段,要广泛搜集相关信息,设计多种可行方案,进行充分论证。在制定决策时,情报的数量和质量致关重要。掌握的信息越多、越准确,才能作出正确的的决策,项目失败的风险也就相对减少;反之,承担的风险就会增大。

(3) 同行经验

针对新技术,由于没有经验可借鉴,因此在探索过程中要充分利用互联网,通过搜索同行经验,往往事半功倍。要充分利用世界日益平坦化的优势,对于不能尽快解决的问题,可以先放一放,可能过不了几天,网上就有相类似问题的解决方案了。

5.技术兼容性风险
硬件产品之间、系统软件(操作系统、中间件、数据库管理系统)与主机设备之间、系统软件之间、应用软件与系统软件之间以及应用软件之间,都可能存在兼容性问题。往往系统集成的项目越复杂,兼容性问题就越有可能存在。

(1) 设计先行

在做系统的总体设计方案时,务必把好相关产品的选型关,确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题。在网络平台建设方案中,明确相关设备的技术参数和配置要求。

(2) 售前产品测试

在做项目招投标工作时,要求投标方在售前提供产品兼容性测试,以避免在项目实施过程中才暴露技术兼容性问题。涉及应用软件开发的集成项目,要在开发工作的早期,做技术兼容性测试,以避免在项目开发后期才暴露技术兼容性问题。

例如,我们在开发深圳市汽车客运站售票及站务联网调度系统时,为了确保技术兼容,在做硬件招标时要求小型机设备厂商提供售前技术兼容性测试工作,并将测试结果做为评标指标。在深圳市软件测试中心对IBM、SUN、HP三家公司提供的小型机进行测试时,暴露了许多应用软件、应用服务器、数据库和操作系统之间的技术兼容性问题,如果这些问题在系统实施时才暴露或处理,势必会拖延项目进度。

6.性能问题
由于先期设计不足,性能问题往往在系统切换或新系统使用一段时间后暴露。出现性能问题往往要进行大量的优化工作,甚至局部的或全面的重新设计。无论是用户还是开发者,谁都不希望出现性能问题。

(1) 性能规划

在系统设计时,应做好前期做性能规划,对可能出现性能问题的环节做到充足的估计。在做数据库设计时,应争取DBA参与。

另外,在技术方法方面,尽可能采取一些性能优化模式,如DTO、AJAX、延迟加载等,尽可能在开发过程中解决了性能问题。不至于到了项目后期才解决性能问题,既费钱又费时。

(2) 性能测试

在开发过程中,要重视性能测试和压力测试,尽可能模拟现实使用环境,搭建测试平台。另外,由于开发环境的计算机往往比生产环境的计算机配置高,在做测试时应尽量找一些配置低的机器、较小的网络带宽进行测试。

(3) 充足的调试时间

在项目开发计划中,为后期性能优化留有余地。在对系统进行性能优化后,要进行性能测试和压力测试,可能还要做几次回归测试。因此,应该留有充足的时间和人力。

7.仓促上线
在项目实施过程中,系统切换上线环节最容易出纰漏。项目好不容易开发完成了,却在最后最后时刻功溃一匮。如果项目小,影响面窄倒不怎么重要;如果是影响面大的项目,则千万不可出现问题。在系统切换前,应充分考虑各种可能出现的问题,做好风险对策。

(1) 应急预案

面对各种不可预知的风险,要做好应急预案。正常运行的车站售票系统在春运、旅游黄金周,都会做好应急预案。新系统切换时,更应该做好应急预案。应急预案中应做好最坏的打算,售票系统不能正常工作时,准备手工票就是最坏的打算。

(2) 分步切换

为了减少风险的影响,可以做系统分步切换的方案。例如:售票系统在切换时,往往用新系统售预售票,或者是用新系统售长途车站,用旧系统暂时售短程票。待新系统运行稳定后,再全面切换到新系统。针对多个用户单位的系统切换,也可分单位进行。

(3) 交叉培训

新旧系统切换过程中,用户都存在适应过程。除了在切换前做好操作培训外,还要在新旧系统切换过程中做好交叉培训。让用户提前一些时间上班,让早班的用户在交班时培训中班的用户,中班的用户培训晚班的用户。做好交叉培训能够让系统平衡过渡。

8.可用性问题
软件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人愉快、是否不易出错等诸多因素。往往由于软件的可用性差,导致用户不满意,甚至被市场淘汰。在项目开发中应注意可用性问题,避免软件出现可用性方面的风险。

(1) 了解用户

到用户工作现场,了解目标用户使用软件的真实目的,从用户的角度、从用户的立场出发,了解如何通过软件系统替代用户的业务处理流程中,最繁琐、最容易出问题、或者是大量重复劳动的环节,让软件提高用户的工作效能和效率。例如:售票系统中,使用频度最高的界面是售票界面,售票员最关心的是钱不要出错(多了没收、少了要赔),因此,应收款和找余字体的显示应该突出、醒目;同样,票价和到达站也应该较为突出显示。通过快捷键、一键复位、数字小键盘等设计,尽量减少售票员敲击键盘的次数。否则,在日发旅客流量达七、八万人次的大型客运站,如果用户界面设计得不好,售票员一天工作下来,手指都会敲麻木。

(2) 参与型设计

与用户协作,让用户参与用户界面的设计、评审与测试,确保用户能够全面地、及早地发现可用性等方面的问题,并及时纠正。

让客户参与设计,而不要让客户设计,项目经理或高级设计人员应该主导设计。

(3) 竞争性分析

通过对市场上同类竞争性产品进行分析,或者对这些产品进行实验性测试,了解这些产品的用户界面问题,从而对新系统的开发提供启发。竞争性分析并不意味着可以剽窃别人的设计,而是通过分析竞争产品的优势和弱点,能够比以前的设计做得更好[5]。

(4) 一致性

如果用户知道同样的命令或同样的操作总会产生同样的效果,那么他们在使用系统时就会更加自信,同时也鼓励他们进行探索性学习,因为他们已经具备了使用系统新部分的基础知识[Lewis er al.1989]。

开发团队应遵循公司或小组制定的用户界面标准,就可以在很多方面保持一致性,切忌不要一个系统存在多种不同的界面风格。

9.结论
在信息系统集成项目中,风险是多种多样的,是无处不在的。在项目管理活动中,要积极面对风险,要培养。越早识别风险、越早管理风险,就越有可能规避风险,或者在风险发生时能够降低风险带来的影响。特别是在项目参与方多、涉及面广、影响面大、技术含量高的复杂项目,应加强风险管理。如果不主动驾驭风险,就会面临风险。

- 弓满月的专栏 - CSDNBlog


需求工程系列(一)软件需求的困境 分析代替了需求

java060515收录,使用标签:项目管理,时间:2008-7-17 15:34:37 | 相关网摘我也收藏

十年来国内软件工程方面的进展有目共睹,在软件需求方面,我们看到在大多数组织中已经建立起了一级或两级需求体系(业务需求和软件需求);在某些组织中,需求分析员已经成为一种专门的职位;甚至在某个大型国有商业银行已经成立一个专门的部门来负责需求分析工作。应该来说,这是一些非常可喜的进步。

然而,目前大多数的项目参与者都对需求工程的现状不满,这又是为什么呢?首先,我们必须承认市场快速变化而带来的需求变化的确对项目带来了很大的挑战,为此许多项目应用了迭代化开发来应对这样的变化。但根据我们对客户的访谈,更多的需求变化是由于需求沟通不力造成的,也就是说,参与需求沟通的各方并没有达成真正的共识,这又是什么原因呢?根据我们的分析,这主要是由于缺少一个可以被各方真正理解和沟通、并可以被逐步精化的需求体系。

目前,大多数用户采用的需求体系基本上是沿袭了结构化分析的文档体系(包括数据流图,数据字典等)。这种文档体系起源于70年代,当时,软件的主要应用还是科学计算或信息处理,理解需求的人往往也受过结构化分析的相关教育,然而这些内容对今天的大多说业务人员或最终用户而言就是很难理解的了。这里的主要问题是分析代替了需求。为了解决这个问题,有的组织引入了非形式化、非结构化的业务需求,然而却很难在两种需求之间建立明确的对应关系,从而出现了业务人员/最终用户认可业务需求,但开发人员觉得不够详细;开发人员认可软件需求,但业务人员/最终用户无法给与确认。

那么,我们如何解决这一软件需求的困境呢? (待续)

- adwu73的专栏 - CSDNBlog


Silverlight 下换肤的实现

java060515收录,使用标签:.NET,时间:2008-7-17 15:30:47 | 相关网摘我也收藏

Silverlight 目前控件要改变外观一般都通过 Style="{StaticResource SomeStyle}" 来指定,而不能统一设置一个默认的 Style. 为了重用,一般把 Style 都放到 App.xaml 的 Resources 字典中去。而 Style 的定义往往非常冗长,这样 App.xaml 就会变得非常臃肿,修改维护都很麻烦。并且,还不能支持多个控件批量切换 Style 的,总之弊端非常多。

幸好 Nikhil Kothari 想了个办法解决了这个问题。在使用方式上,借鉴了 asp.net 的 Theme 机制。只要在 Silverlight 程序的根目录下定义一个 Themes 目录,并按要求往其中放入相关的皮肤文件即可。这里建议的方式是每一个控件一个单独的 xaml, 其中放了一个 UserControl. 之所以用 UserControl 的目的是为了能用 Expression Blend 进行可视化设计,非常直观。

主要实现思想:

1. 继承了一个自定义的 App 子类. 使用者需要将现有的 App.xaml 改成使用该类才行。
(同时这个 App 类还实现了根据 initParameters 在 xaml 中动态指定加载的 UserControl 和 Theme 的功能)
其中设置一个 ThemeName 属性来定义 Theme 名称。

2. 在 App 启动时,根据这个属性名动态去加载相关 xaml 的 xml 文件,并解析之。这些皮肤的 xaml 文件在 VS 里是要把 Build Action 设置成 Content 的。这样可以生成到 xap 包里去,以便于加载。

3. 在读取多个 xaml 文件并解析的过程中对同样的 Style 根据优先级做了相应的覆盖合并。最终形成一个总的 xaml 文件内容。

4. 用 XamlReader 的 Load 方法加载最终的文档。将其中的资源都抽取出来,并塞到 App.Resources 字典里去。

5. 然后正常的控件视觉树开始创建。其中的视觉元素指定了StaticResource样式,这时它就能从App的资源字典里获取到皮肤样式。


注意:这里自始至终没有动态对控件指定Style的机制。因为Silverlight目前不支持。这个解决方案的主要思想就是在视觉树加载之前,动态的修改了App中的资源,后续的样式应用机制仍然是 framework 默认的。

原文地址:http://www.nikhilk.net/Silverlight-Themes.aspx
- 木野狐(Neil Chen) - 博客园


IT项目管理十六字精华

java060515收录,使用标签:项目管理,时间:2008-7-17 15:29:12 | 相关网摘我也收藏

凡事预则立,不预则废。如果你不知道要到哪里?给你一张地图也没有用。目标驱动首先要有最基本的计划管理和时间管理能力。对于一个项目,我们过程中做的所有工作都是为了要达到项目目标,因此在项目各个阶段所有活动都需要考虑对达成目标的影响,当发现偏差后及时纠正。目标驱动让我们从无目的的事后应急变成了有计划有目的的事前预测。目标驱动不是要抛弃过程,项目的成功涉及到过程,人和方法工具技术。为了达到项目目标,我们要根据项目的实际情况采取一系列项目原来已经总结的最佳实践形成一套过程,高效的过程和积极心态的人是保证项目目标达成的关键。因此作为项目经理要时刻问自己,项目的目标是什么?项目当前状态和我达成目标的差距是什么?我如何解决和应对。

  项目的成功受到多方面的因素的影响,而且各个因素之间还存在正反作用力。系统思维就是要让我们能够清楚的认识到影响项目目标和成功的各个要素,以及它们之间存在的关系。形成一种适合项目的动态系统模型,通过这个动态模型去平衡项目各方干系人的利益,平衡项目四要素之间的关系,平衡项目的短期和长期的利益。项目经理的一个重要能力就是平衡,没有最优解,只有满意解,懂得了平衡就知道当项目出现变更和调整的时候如何更好的应对。从单要素最优的单向思维过渡到关注整个系统的全局思维模式上。

  风险意识简单来讲就是项目在执行过程中可能发生的各种问题我都事先预见到了而采取了适当的缓解措施,这样才能够真正的让项目能够按照预先制定的计划和目标进行。再简单点就是如果风险管理做得好,项目是不应该失败的。君子安而不忘危,存而不忘亡,治而不忘乱。风险管理的重点正是在于要形成风险意识,要能够通过历史经验的积累,能够把项目的关键风险识别出来,使项目能够从事后的救火转变到事前的防备,使项目能够在前面紧张后面轻松。

  要谈及量化管理首先应该要培训用数据说话的分析思维。在软件项目管理中我们做度量的目的,就是要收集和分析各种历史数据,通过对数据的分析来知道项目真正的效率,同时为后续项目提供各种估算参数数据。以数据说话让我们从全凭主观经验臆断转变到对事物的客观数据分析上。只有能够收集数据,分析数据我们才可能持续改进。有了数据意识后就是要有统计和量化管理方面的意识,利用统计学的思维和量化管理手段不仅仅是让我们的过程稳定和受控制,能够去发现项目执行过程中特殊原因引起的波动,针对特殊波动进行根源分析并采取纠正行动;还能够让我们能够根据预测模型更加准确的预测项目能够达成目标的程度和概率。

- 易天 - 博客园


利用SOA简化集成BI 企业使BI和SOA一拍即合

java060515收录,使用标签:SOA,时间:2008-7-17 15:25:03 | 相关网摘我也收藏

需求不断扩大、厂商重点投入、用户理解加深,商业智能(BI)软件应用的“躁动”日渐强烈,它已成为企业必备的关键工具,同时在企业中的需求也迅速增长。

  据调查,BI将不再被视为一种独立应用在企业里实施,它将与现有各种的复杂架构相融合。例如一些企业用户渴望BI能成为他们工作的一部分,与公司门户和企业搜索紧密集成,并且内嵌到企业业务流程及其它应用中,最后通过移动设备来访问。

  但在企业实践过程中,CIO们发现BI很难应对多种应用、平台和数据源,不能进行及时有效的管理,因此他们认为最好的方法就是SOA来简化集成BI。

  专家说,SOA架构所独有的特点能充分满足企业在BI解决方案上高效、可靠,灵活的需求,可以协助企业挖掘出BI部署的价值。针对SOA的特点,专家具体分析如下:

  1.利用SOA基于标准的开放式架构集成BI解决方案和其他程序

  SOA是基于标准兼开放的,他们为企业提供了BI解决方案所需的灵活性,协助他们调整现有的IT基础架构,避免了功能重复。一套基于SOA的BI解决方案可以在任何网络服务器上运行,并与现有的路由器和防火墙相匹配。统一的API也确保了解决方案能够轻松与其它程序集成。

  2.SOA架构灵活、位置透明 符合BI数据和用户分散的特点

  企业通过SOA可随时调整现有的基础架构,可以在现有的硬件、数据库和应用服务器上运行任何基于SOA的软件。同时,SOA也具备了位置透明的特点,即能够在网络上的任意位置定位服务。这类灵活性完全符合BI数据与用户的分散属性。譬如IT人员打算紧靠大型数据中心来提供查询服务,以避免在处理请求时所产生的延时。而通过位置透明的服务,IT人员就能采取最有效的部署战略,根据用户、数据与基础架构的具体情况来优化解决方案的绩效。

  3.SOA的点对点与松耦合性使BI数据集成

  企业在部署了SOA架构后,任何一种服务都能进行完整的容错,任何要求均可通过系统服务器上的同类服务来处理。在解决了单点故障问题后,IT人员会对BI部署更具信心,继而在用户社区建立信任,并由此扩大BI的过渡范围。

  这种点对点服务具有松耦合的属性,即无需了解其它服务在做什么,运行在哪里。商业逻辑被剥离到底部架构之外,从而保障了数据源的轻松集成。比如那些打算在数据处理高峰期保持稳定与可靠性的IT人员可以根据点对点服务来调整开发与测试环境,在满足服务等级承诺的同时,无需投资额外的硬件。

  4.基于界面与粗粒度服务使SOA和BI完美结合

  基于界面的SOA能让各服务之间进行通讯。通过使用SOAP和XML来进行服务互动,交换数据、参数与处理结果。随着从移动设备到企业搜索工具等对BI访问能力要求的不断提高,通讯协议的可用性和开放式API的重要性也在逐步抬升。

  粗粒度服务也是SOA与BI一拍即合的主要原因,它将服务定义在了商业层面,而非应用层面。这有效降低了网络流量,并简化了集成。粗粒度服务允许跨越各种流程和应用对这些服务进行循环使用,因此它是有效部署解决方案的关键要素。

  此外,粗粒度服务对BI的信息访问方式也有着举足轻重的作用。对用户而言,他们需要的是以最快的速度获取解答,不管该解答是来自于标准报表还是特殊查询,也不管信息是通过BI应用、移动设备,还是其它应用来访问。因此,在相应的层面建立通用服务是实现这一点的关键,这样就可避免在服务之间进行多次传递而提高延时。

  粗粒度服务同样也是企业BI灵活性的一大保障,为了在多种环境中提供广泛的BI访问能力,并让所有用户可用,就需要部署一套能对变革做出快速反应的架构。

  通过针对所有基于目的的BI功能建立一套常规的粗粒度服务,BI解决方案就可以对新需求做出快速反应。部署得当的SOA基架能确保新技术的快速可用,而无需作为一种单独的解决方案来进行建立及维护。

  该技术专家说,企业应当将基于SOA的BI解决方案视作为成功的重要条件。借助SOA基于标准、点对点和统一、开放式API的特点来让IT充分利用现有的平台、操作系统、硬件和安全控制。这种开放性也意味着需要部署及维护的活动组件将会减少,从而为公司营造一套有效、可靠,兼灵活的绩效解决方案。

  对IT人员而言,SOA所带来的高效可转化为易于部署、维护和变革。而对企业来说,用户可以在多种平台上访问数据源,基础架构的变更不会严重影响到他们获取信息的能力。解决方案可以更快地建立并运行,商业用户可以访问更多的信息,同时不会受到后台变更的制约。

作者: 徐蕊,  出处:IT专家网


八百客总裁李智:厂商合作与SaaS技术原则

java060515收录,使用标签:项目管理,时间:2008-7-17 15:23:03 | 相关网摘我也收藏

2008年7月10日,“2008 SaaS 在中国”——第二届中国软件运营服务大会在宁波开幕。用友、金蝶、微软、SAP、Oracle、WebEx、阿里巴巴、奥林科技以及IBM、Intel、浪潮、EMC等50家国际和国内知名的IT企业老总齐聚甬城,围绕SaaS的“切入与创新”展开了热烈讨论。国际知名的IT专家、美国斯坦福国际研究院主席William F.Miller发表了视频讲话并祝大会圆满成功。以下是八百客总裁李智在“企业应用SaaS的切入点”分论坛所做的主题演讲实录。

  李智:我今天谈的主题是OEM的合作供应。

  我们公司做SaaS已经做了很久,去年年初的时候提到了OEM,我们业务跟其他的公司也不一样,我们的业务主要是提供低成经营方法,我们公司产品打合作伙伴的标。我们有很多客户遇到一些手机的应用,一些VIP的电话应用。另外一点在互联网做OEM更容易,其他的产品设计各方面比较长,OEM非常快,快的话几小时就可以做出来。LOGO好象是合作伙伴自己做的一样。

  这个图是我在国外看到的图,是我们的一个产品,我们用两种方式提供OEM平台,第一种是PAAS平台,实际上这个平台是个技术平台,是一个研发平台,你在上面可以做研发,不需要代码。直接就可以开发,可以开发任何的商业应用、功能软件。它的价值费用比较低,给客户带来的价值最高,实际上可以看到,传统的有一个项目你要请程序员,要长期雇佣,这个比较高。企业软件都是标准化的,像金碟等等、像SaaS的组合是某一个点的应用组合在一。合作伙伴可以在自己的行业里面做应用,有自己的业务流程,有自己的模板,还有自己的知识库,比如服务行业可以跟其他的数据库集成起来,在上面开发一个自己流程的软件。目前来看已经签了几家比较好的公司,而且有排他性的,他不管硬件也不用管开发、数据中心,这是我们感觉比较不错的方式,我们感觉这种合作对双方都非常有利。开发软件可以在网站试一下,是免费注册的,里面有几个模块。我们的OEM封装也比较快,你告诉我行业流程,清晰的化一周之内就可以上线了。

  另外一种是协同开发,有是我们提供一套Websrvice API变成接口,我们的数据库和合作伙伴的可以充分互动,需要文档的话我可以发给大家看一下。

  OEM也有很多的合作伙伴,主要分几类,有一些是做软件集成的,自己没有软件帮客户做系统集成,这主要是通过CRB和OA,再个旅游航母的,他自己不是做旅游的,他可能给旅游提供信息服务,一些翻译服务公司,可以跟他们合作,他在他们的客户群里推广相关的产品。

  这也是一个案例,我们会和客户签一些比较严格的协议,比如保密协议,排他都可以签,我们主要希望跟一些比较专业的公司,他自己做得比较专,公司有一套管理方法,我们八百客比较适合做流程化的公司,我们成立的时候技术是国际标准的,是从国外带来的技术,技术是国外领先的理念,在国外有很多成功的案例,国内几乎是一片空白。

  我们公司进的比较久,很多的同行和其他的公司都很熟,我在这里提一些误区。现在这个行业工人是一个培育期,我觉得有许多误区,许多公司我看到已经倒闭了。公司成立四年多至少有10家公司做SaaS已经关门了,我发现有很多公司自己有一些资源,想利用这些资源进行SaaS,特别是有技术资源、客户资源的公司,他希望利用SaaS快速成长,另外是我提供服务器、客户、机房,你是软件厂商,我给你卖,是这种模式。公益软件还可以,对做企业管理软件我觉得难度很大,企业软件有一个单点登陆(音译),每个软件都也一个数,如果把很多厂商集中在一起,非常复杂,你如果做接口两三个还好,但超过10个以上就比较难。现在没有一个总线的概念。也跟一些厂商合作过,我们觉得几乎是不可能实现的任务。另外通过Mash-up集成,或者快递公司有数据库联系在一起,这都是比较简单的集成,我觉得这块很多公司都是忽略的,实际上产品稍微灵活一点儿这套很容易做。另外一点免费地价,吸引大量客户的方法,我发现有几家公司免费或者是把价格压得非常低,刚才跟同行聊天发现这个问题,有些企业产品不是很领先,就跟你打价格战,通过扫楼(音译)吸引客户,我也没有发现成功案例,我个人认为八百客提出的OEM方式是很好的方式,对厂商来说是机会。我们只做技术开发、运营、把成本降到最低,做到最后,运用到某一个行业、横向的运用,利用我们现有的资源,我们资源都是敞开的。可以充分利用。


SOA 推动商务流程管理的一种建筑风格

java060515收录,使用标签:SOA,时间:2008-7-17 15:21:06 | 相关网摘我也收藏

作者: 清茶,  出处:IT专家网

Software AG公司副总裁Bjorn Brauel说,推出SOA不仅仅是利用技术。SOA是用于推动商务流程管理(BPM)的一种建筑风格。

  Brauel说,虽然拥有构建应用程序的方法和标准并不是一个新概念,但是,我认为,SOA是没有前例的,因为它是观念、方法和技术的融合。

  要取得经营的灵活性和敏捷性,商务流程管理模型、自动化和变化等要根据机构考虑业务应该如何发展的思路进行处理,而不是根据IT功能进行处理。从IT的观点看,这就意味着提供灵活的基础设施去管理流程,对这些变化做出反应。

  Software AG公司亚太和日本地区高级副总裁Paul Henaghan对于定义SOA的问题谨慎地指出,部署一个带有符合SOA原则的服务能力的ERP解决方案并不能解释为整个机构范围内的SOA应用。

  Brauel赞成这个观点。他说,SOA不是你购买的产品,而是你所做的不断改善工作流程的一部分,这是符合机构目标的。SOA也许在开发Web 2.0服务为用户提供更丰富的在线体验方面还能发挥重要作用。

  Brauel称,首席信息官们在实施SOA时应该小心的一个陷阱是设法为SOA制作一个商务实例。显而易见,SOA本身是没有商务实例的。首席信息官们应该从商务流程管理的角度向机构的其他股东解释SOA。

  他强调指出,首席信息官们需要围绕商务流程管理建立SOA结构,采用一个直观的SOA路线图,首先定义一个为期三个月的商业计划作为实现更长远目标的第一步。这将保证机构的股东能够更迅速地看到商业价值,如SOA流程产生的节省成本的效果,而不用等待三年之后才看到投资回报的例子。

  Brauel说,虽然长期的关键业绩指标(KPI)还不能立即看到,但是,考虑到这个企业正在把现有的资产重新用于自动化的流程,三个月之后衡量短期的关键业绩指标是非常有可能的。以此为起点,这个路线图就能够预测更长远的关键业绩指标。

  Brauel表示,自由与治理之间的平衡对于服务开发是非常重要的。

  太多的自由意味着允许工作人员在任何时候为自己开发服务,不用考虑其他机构股东需求。这将导致以内部为重点的观点。这个观点认为可能提供商业价值的服务组件不用与机构的其他人共享。

  另一方面,太多的治理能够显著抑制工作人员的创造性。他们将想办法绕过规则和条例。Brauel补充说,提供正确水平的治理包括正确地定义目标,以及指示进行整个机构范围内的协作,同时允许服务开发方法的灵活性。

  此外,Brauel解释说,在平衡SOA的自由与治理方面,激励措施是很重要的。不应该根据编写代码的行数奖励工作人员,而要根据他们创建和共享了多少个能够让机构的其他人重新使用的服务进行奖励。

  Brauel指出,各个地区的首席信息官的观点是有区别的。在美国,首席信息官们议事日程的重点是商务流程管理,而不是SOA。另一方面,欧洲的首席信息官们主要关心IT部门的效率提高。因此,他们在考察商务流程管理之前首先用SOA的观点开始新的项目。

  Henaghan说,由于预算紧张,亚洲的首席信息官对于新的IT计划没有那样高的热情,因此,他们要设法尽可能多地从现有的基础设施中获得商业价值。因此,他们把更多的重点放在商务流程管理方面。

  Henaghan强调指出,虽然SOA也许会发展,甚至将来会叫不同的名字,但是,把观念、方法和技术融合在一起开发新服务的SOA的基本原则是不会改变的。

  Henaghan说,Software AG公司要在2010年达到10亿欧元的年销售收入。我们将与客户进行合作,帮助他们重复使用现有的IT基础设施以创建新的服务。

  他指出,亚太地区(包括日本)为该公司提供了巨大的商业机会。虽然我们在亚太地区一直是积极的和成功的,但是,我们到目前为止在亚太地区还一直没有达到我们的美国和欧洲业务的市场普及程度。

  Henaghan解释说,亚太地区商务流程管理软件市场还不太成熟,大多数企业仍在进行“教育讨论”,而不是与商务流程管理领域的厂商积极地合作。


PDM与ERP之间信息集成实现方法

java060515收录,使用标签:业务平台,时间:2008-7-17 15:20:09 | 相关网摘我也收藏

随着企业信息化的不断深化,许多企业已将产品数据管理(PDM,ProductDataManagement)系统作为产品工程信息管理与集成的平台,统一存储与管理产品设计、工艺及资源信息。这些信息是企业资源计划(ERP, Enterprise Resource Plan-ning)系统工作运行的重要输入信息。 PDM与ERP系统间有大量信息都存在共享现象。因此,在PDM与ERP系统之间实现信息集成,不仅能使产品的设计制造过程更加顺畅,而且能避免由于信息重复输入而可能带来的错误,精确地传递信息,促使整个企业设计制造部门之间协同工作。PDM与ERP系统间的集成是企业信息化应用的必然需求。

  PDM与ERP系统之间需要集成的信息包括产品信息、工艺信息及资源信息等内容。然而,2个系统中集成信息往往以不同的结构、不同的语义表现和储存,因而不能被对方直接识别读取,信息集成必须经过适当的转换才能完成。

  在制造业企业的生产运行管理中,通常以物料清单(BOM, Bill ofMaterials)的形式表达产品的设计信息、制造信息和各种管理信息。 PDM与ERP系统之间需要集成的信息也大量存在于BOM中。本文以BOM为信息载体,研究PDM与ERP系统之间的信息集成机制,提出一种基于信息转换的PDM与ERP系统间的信息集成方法。

  1 常用的信息共享实现方法

  目前,PDM与ERP系统之间比较流行的集成方式主要有3种,分别是接口式、直接访问数据库和间接式。然而,这3种集成方式并不能满足PDM与ERP系统间对于不同结构和语义信息的集成需求。

  为了保证从设计到生产整个过程的数据一致性,文献利用PDM工程变更流程技术,提出了一套通过工作流进行数据发布,由中间件将数据传输到ERP系统的集成方法。文献通过建立通用视图与功能视图,定义了产品信息的集成信息模型,并提出了基于集成信息模型的PDM与ERP集成方法。

  目前,PDM与ERP系统集成的研究中,比较关注两系统间的协同信息传递和驱动,而缺乏对异构系统间集成信息内容语义的统一规范和转换。如果需要集成的信息存在语义不同的现象,即使实现了PDM向ERP系统的信息传递,集成信息也很难被直接利用。因此, PDM与ERP系统间的集成信息必须完成转换和语义统一。

  BOM是PDM与ERP系统间集成信息的重要载体,它以树状层次结构表现了产品结构、产品配置状态、库存状态等产品相关信息,这些信息共同构成了连接产品设计和生产经营管理的桥梁。

  根据承载信息的不同,BOM信息可以分为设计BOM (EBOM, Engineering BOM)、工艺BOM(PPBOM, Process Planning BOM)和制造BOM(MBOM,Manufacturing BOM)等类型,分别是设计部门、工艺部门和生产制造部门组织和管理的信息,MBOM是ERP运算的重要输入信息。应用系统中,BOM信息的2种常见的存储方法是单层结构表示法和多层结构表示法。单层BOM结构采用“单父-单子”的数据结构,清晰定义了产品结构,易于反查零件,但在BOM分解时效率较低。多层BOM结构采用“单父-多子”的数据结构,详尽地记录了从产品到零部件的每个层次结构与零部件配置关系信息。该方法分解速度快,维护方便,但数据冗余度大,产品结构定义不清晰,零件不能反查。

  在目前的大多数ERP系统中,多依据单层结构存储BOM。PDM与ERP系统的信息集成中,也需要按ERP系统的要求拆分为单层BOM数据的格式。

  2 PDM与ERP集成信息内容

  PDM与ERP系统间共享的信息有很多,主要包括产品结构、零组件、工艺信息、原材料、设备、工装、组织结构等,这些信息可以归纳为物料信息、产品的层次结构类信息、资源信息3方面。

  1)物料信息是集成信息中的基础信息,主要包括零组件、产品、原材料等信息,是对物料基本属性内容的描述;

  2)产品的层次结构类信息是以层次结构进行存储的信息,包括产品结构、工艺过程结构等,层次结构类的制造信息是PDM与ERP系统实际运作中密切相关的内容,其表现形式通常为MBOM;

  3)资源信息包括组织结构信息及制造资源信息,组织结构信息中包含企业的部门结构与人员信息,制造资源信息包括设备、工装信息,用于具体的生产制造。

 PDM与ERP系统间, 3类集成信息与产品结构、工艺、资源等信息的逻辑关系如图1所示。按照PDM与ERP系统间需要集成的信息分类,分别定义零组件、产品结构、工艺计划、工艺规程、设备、工装、组织结构等信息实体,以及实体之间的关系、实体中的属性信息,建立以PDM与ERP系统间的集成信息IDEF1x模型。

  3 集成技术及原理

  3.1 集成信息的演变与转换

  PDM与ERP系统对信息管理的侧重点不同,PDM系统存储的信息不能直接为ERP系统所使用,两系统间的共享信息必须进行信息转换,以实现集成信息的语义一致。

  PDM与ERP系统间的集成信息转换过程可以分为BOM结构的转换和BOM属性信息的映射2部分。



微软"云计算"产品 Live Mesh英文帐户已开放使用

java060515收录,使用标签:.NET,时间:2008-7-17 15:03:07 | 相关网摘我也收藏

Live Mesh是微软进入发展迅猛的云计算市场的最新举措。所谓“云计算”是指通过网上的中央数据中心,实现PC上的各种应用与服务。目前,亚马逊、谷歌、Salesforce等数十家公司已经建立了计算中心,可以高效处理数据外包业务,并使之成为象电一样,企业可以轻松购买的商品。

北京时间2008年7月18日,微软"云计算"产品 Live Mesh 英文帐户已开放使用,注册地为英文的msn.com和live.com等用户已可以登录mesh。

访问:Mesh
http://www.mesh.com/


Win 7打动用户需要20项功能 放弃32位系统

java060515收录,使用标签:.NET,时间:2008-7-17 15:02:15 | 相关网摘我也收藏

7月16日消息,据国外媒体报道,微软的新一代操作系统Windows Vista让人既爱又恨。尽管在安全、CPU调用和稳定性方面有所提高,但由于存在兼容性等问题,还是遭到了业界的指责。并且,普及率也远远低于预期。目前,很大部分用户仍坚持使用Window XP系统。那么下一代操作系统Windows 7能否打动用户呢?答案是:必须!微软没有退路。以下为Windows 7必须包含的20项功能:

1. 简化和管理启动项,提升系统启动速度

2. 快速启动和关系

3. 集成诊断工具

4. 更好的刻录功能

5. 只开发64位系统,放弃32位

6. 准系统内核,如此前曝光的“MinWin”

7. 提供镜像恢复功能

8. 集成微软工具箱,列出已安装硬件和软件的所有驱动和补丁信息,避免出现兼容性问题

9. 程序缓存技术有待提高

10. 内置浏览器要符合业界标准

11. 尽早解决驱动问题

12. 新增家庭用户授权模式

13. WinFS文件系统应该得以体现

14. 系统版本不要太多,家庭、商业和服务器三个版本足已

15. 图形用户界面设计要能提高工作效率

16. 安装内容可定制

17. 支持游戏模式,好比当前的“安全模式”

18. UAC安全功能需重新设计

19. 虚拟机功能

20. 模块化设计


微软将于10月正式发表Silverlight 2

java060515收录,使用标签:.NET,时间:2008-7-17 15:01:05 | 相关网摘我也收藏

微软表示将于10月正式发表Silverlight 2,目前已释出Beta 2版,可以和Silverlight 1.0版兼容,档案大小仍维持在4.7 MB。

目前在Silverlight Beta 2版中的控制组件已增加到30几个,也更新了不少既有API的功能,例如按钮状态设定、文本块的中文输入选单、数据表单的多列排序等功能。微软表示在10月的正式版中,将会提供超过100个控制组件可供开发人员使用。不过,微软也提醒因为Beta 2新增功能过多,无法执行Beta 1的程序,必须用新版本重新开发.


哈佛管理论丛:谁背上了令人讨厌的猴子

java060515收录,使用标签:项目管理,时间:2008-7-10 11:02:34 | 相关网摘我也收藏

为什么经理们忙得不可开交,而下属却无所事事?这里我们将探究一下管理时间的内涵,因为这涉及经理们与他们的上司,同级人员以及下属之间的互动关系。具体地说,我们将讨论三种管理时间:

受上司支配的时间,用于完成上司下达的工作任务。对于这些工作,经理们不能掉以轻心,否则会立即受到直接处罚。

受组织支配的时间,用于满足同级人员提出的积极支持的要求,若置若 闻,也会招致惩罚,尽管惩罚并不总是直接的或迅速的。

由个人支配的时间,用于完成经理们自已想出的或者同意去做的事情,然而,其中一部份时间会被下属占用,称为受下属支配的时间。剩余时间属于经理自已,称为自已支配的时间。由个人支配的时间不会导致受罚,因为上司或组织压根不知道经理最初的打算做些什么,所以就无法对没有完成什么予以惩罚。

为了满足各方要求,经理需要控制好工作的时间安排和内容。即然完不成上司和组织交代的任务就要受罚,经理们绝不能忽视这两方面的要求。因此由个人支配的时间就成为他们主要考虑的方面,经理们应该努力通过最大限度地减少或消除受下属支配的时间,增加由个人支配的时间中的自由支配时间,然后利用所增加的时间更好地处理上司和组织布置的任务。然而,大多数经理没有意识到,他们把过多的时间花在解决下属的问题上。因此,我们将利用背上的猴子,这个比喻来分析受下属支配的时间是如何产生的,以及上司应当如何应对。

猴子在谁的背上?

让我们想象一下:一位经理正走在大厅里,这时注意到他的一们下属琼斯迎面走来。当两人相遇时,琼斯向经理问好:“早上好。顺便说一下,我们遇到了一个问题。你知道......"当琼斯继续往下说时,经理发现此次问题与他的下属向他提出的所有问题一样具有两个特点:其一,他知道需要参于解决问题;其二,他对情况还不够了解,无法如下属所愿当场拍板.最后,这们经理不得不说:"我很高兴你能提出这个问题.我现在很忙.让我考虑一下,我会给你答复的."随后,两人分手了.

让我们分析一下刚才发生的一切.两人碰面前,"猴子'在谁的背上?在下属的背上.两人分手后,猴子又在谁的背上?在经理背上.当猴子从下属背上跳到上司的背上时,受下属支配的时间就开始了,一直到该经理把猴子归还给真正的主人喂养为止.在接受猴子的时候,经理自愿地把变成自已下属的下属.也就是说,他允许琼斯把他变成她的下属,去完成一个下属通常要为上司做的两件事---经理从自已的下属那里接过了责任,并向下属承诺报告工作进展.

这位下属为确保经理不会忘记这件事,此后将会把头探进经理办公室,喜滋滋地问道:事情进行的怎么样了?(这叫监督).或者,让我们设想另外一个场景.在会谈结束时,这位经理对另一位下属约翰逊说:“好.把这个问题的备忘录给我送来."

让我们分析一下这个情景。猴子此刻还呆在下属的背上,因为下一步行动要由他采取,但猴子已经准备跳跃了。注意这只猴子。约翰逊尽职地写好备忘录,并把他放入文篮。此后不久那位经理从自已的收文篮拿到备忘录,并开始阅读。现在该谁行动了?是这位经理。如果不赶快行动,他就会从下属那里得到一份备忘录(这是另一种形式的监督)。这位经理拖延的时间越长,那位下属就越感到沮丧(他将无所事事),而这位经理就越感到愧疚(被下属支配的时间将大量增加)。

再想像一下同第三位下属史密斯见面的情景。这位经理要求史密斯起草一份公关计划书,并保证向她提供有必要的支持。临别时经理对他说:“需要帮助的话,尽管告诉我。”

现在,我们分析一下这个例子。猴子最初还是在下属的背上。但他还会呆多久呢?史密斯意识到,在计划书得到批准之前,他不可能“告诉”经理自已需要哪些帮助。而且根据以往的经验她还意识到,她的建议书要在经理的文件箱里放上好几个星期,最终才能被经理批阅。那么,究竟谁背上了猴子?谁将检查谁的工作?此时,无所事事的现象瓶颈效应又一次发生了。

第四位下属是里德,他刚从公司的另外一个部门调来,以便启动并最终管理一个新设立的一个业务项目。这位经理说,他们应尽快碰头,为这项新的任务敲定一糸列工作目标。他还补充道:“我将草拟一份初步方案,然后与你讨论。”

让我们也份析一下这种情况。这位下属拥有了新的工作,(经正式任命)和全部职责(正式授权).但是这位经理却要采取下一步行动.在任务完成前,他将背负着猴子,而下属则无事所所.

为什么会发生这一切?因为在每一种情况下,不论是有意还是无意,这位经理及其下属从一开始就认为问题是两个人的.在每一个例子中猴子最初横跨在两面个人的背上.它只需移动一下那只跨错的腿-"唰!"--下属就一下子消失了,留下经理照管这只猴子.当然,你可以训练猴子不要挪动那条腿,但更简单的办法是,从一开始就阻止它横跨在两个人的背上.

谁在为谁工作?

让我们来假设,这四位下属非常体贴他们的上司,为了不占用他的宝贵时间,每个人都竭力不让三个以上的猴子在一天之内跳到经理的背上.在五个工作日的一周中,这位经理将要背上60只尖叫的猴子数量太多,根本无法一个个地应付.因此,他把受下属支配的时间用于焦头烂额地处理那些"首要事务".

星期五下午晚些时候,经理把自已关在办公室里以免受到他人打扰,从而可以仔细考虑一下处境,而他的下属们正在门外等候,要抓住周末前最后的机会提醒他必须"快做决择".想象一下他们在等待时会怎样谈论经理:"总是卡在他这里!他就是拿不定主意.一个无法做出决断的人竟在公司占据高位,真是想不通!"

最糟糕的是,该经理无法采取任何"下一步行动",因为他把时间几乎都用在满足自已的上司和公司要求做的事情上,为了应付这些任务,他需要自由支配的时间,但是当他满脑子想的都是下属的猴子时,他根本没有自由支配的时间.这位经理人 入了一种恶性循环,然而,时间在白白流逝(这样说还是轻的).经理通过内线给秘书打电话,让他通知他的各位下属:他只能下星期限一下午见他们.晚上7点,他开车回家,打定主意第二天回办公室加班,在周末把一切处理完毕.第二天,他精神焕发地早早来到办公室,结果却透过办公室玻璃窗看到靠近高尔夫球场草坪上有四个人在进行双打比赛.猜猜他们是谁?

原来如此.他现在知道了究竞谁在为谁工作.此外,他还意识到,如果他按计划在周末完成要做的工作,他的下属就会士气大增,每个人将会放宽数量的限制,让更多的猴子跳到他背上.总之,如同登上山顶后眼前豁然开朗,他猛然醒悟过来:他越是往前赶,就越会落在后面。

他向逃避瘟疫一样迅速离开了办公室。他有何打算?他要抓紧去干一件多年来一直无暇顾及的事情:和家人共渡周末(这是自由支配时间的多种形式之一)。

周日晚上他酣睡了10个小时,因为他已经为星期一制定了一个明晰的计划。他打算摒弃受下属支配的时间。这样他将拥有与他们同样多的自由支配的时间,其中一部份时间他将花在下属身上,确保他们学会这门被称为“猴子的喂养”的难学有益的管理艺术。

这位经理还会剩有大量自由支配时间,也可以更好地管理受组织支配的时间,从而有效控制这两方面的时间安排和工作内容。这也需要几个月的时间,但与过去相比,回报却是很丰厚的。该经理的最终目标是管理好自已的时间。

摆脱背上的猴子

星期一上午,经理故意姗姗来迟,以便四位下属已经聚集在他的办公室外,等待他来讨论他们的猴子。他把他们一一叫进办公室,每次拿出一只猴子,摆在两人之间的卓面上,共同为下属确定下一步的行动。对于处理某些猴子来说,的确要费一番周折才行。如果无法确定下一步行动,经理就权且让猴子在下属的背上过夜,让他或她在第二天上午约定的时间带着猴子回来,继续为下属共同探求下一步行动。(猴子这一夜在下属的背上与在上司的背上一样睡得香甜)

每位下属起身离开时,经理欣慰地看到一只猴子趴在下属的背上离开了办公室。在随后的24小时里,不是下属等候经理,而是经理等待下属。

后来,似乎为了提醒自已中途进行一下有益的活动并不违反规定,经理踱着步子经过下属的办公室,从门外探进头去,喜滋滋问:“事情进行的怎么样了?”(在做这件事上耗费的时间,对经理来说是自由支配的时间,而对下属来说则是受上司支配的时间)

第二天,当这位下属(背着猴子)和经理在约定时间刻见面时,经理用大致如下的话解释了他的基本原则:

“任何时候我帮助你解决这个或那个问题,你的问题都不会变成我的问题。在你的问题变成我的问题的那一刻,你就不再有问题了。我不能帮助一个没有问题的人。”

“在这次会面结束时,你的问题将与进来时一样由你背着离开办公室。你可以在任何约定时间来请求我的帮助,我们会共同确定我俩中谁来采取下一步行动。”

“一般情况下采取下一步行动的人不会是我,万一是我的话,你也要和我一起做出决定。我是不会单独采取任何行动的。”

在与每位下属谈话时经理都遵循同样的思路,谈话一直持续到上午11点左右,这时他意识到他不必关门了,猴子已经离开了。当然,它们还会回来,但只有在约定的时间才会出现。他的日程表将确保这一点。


把主动还给下属

通过背上的猴子这个比喻,我们力求说明的是,经理们可以把行动的主动性还给下属,并使下属绐终保持这种主动性。我们试图强调一个显而易见而又什分微妙的道理:在发掘下属的主动性之前,经理必须保证下属具有主动性。一旦经理把这种主动性还回去,他自已就不在拥有,他就能减少受下属支配的时间,增加自已的自由支配时间。

经理和下属也不能同时具有同样的主动性。那句开场白“老板,我们有一个问题”就暗含与两人有关,而且就象前面所指出的那样,表示一只猴子横跨在两个人的背上,这样让猴子开始它的生涯是一种极其糟糕的方式。因此让我们花一点时间审视一下我们所说的“管理主动性的剖析”。

与上司和组织打交道时,经理可发挥的主动性分为五个层次:
1、等待别人吩咐(最低层次的主动性);
2、询问该做什么;
3、提出建议,然就采取相应的行动;
4、采取行动,但立即提出建议;
5、自已主动行事,然后定期汇报,(最高层次的主动性)。

显然,无论是与上司还是与组织打交道,经理人应该具有足够的职业精神,不能仅仅限于第一和第二层次的主动性。采取第一层次主动性的经理根本无法控制受上司和组织支配的时间---无论在日程安排上还是在工作内容上,因而也无权抱怨自已被要求做什么或何时去做。采取第二层次主动性的经理可以妥善安排时间,但是不能控制工作内容。采取第三、第四和第五层次主动性的经理,两者都能控制,而采取第五层次主动性的经理具有最大的控制力。

对于管理下属来说,经理的工作具有两重性。第一、要禁止下属们采取第一和第二层次的主动性,这样可以迫使下属别无选择,必须学习和掌握“员工的全部职责”。第二,要确保当下属带着问题离开经理办公室时,双方除了商定下次见面的时间和地点,还要对下属应采取的主动性层次达成一致。此外,经理应及时在日程表上标明见面时间和地点。

猴子的喂养

为了把背上的猴子与任务分派及控制流程之间的相似性讲得更清楚,我们参考一下经理的工作日程表。这种日程表要求遵循“喂养猴子”的五项严格的原则(违反这些原则将导致丧失自由支配的时间)。

原则一:要么给猴子喂食,要么开枪打死它。否则猴子会饿死,而经理则要浪费很多宝贵时间为猴子进行尸检,或者试图使猴子死而复生。

原则二:应该把猴子的数量控制在经理有时间喂食的极限之内.下属应尽量为经理提供足够多的猴子来喂食,但不能超过他或她的时间允许范围.给一只正常状态的猴子喂食不应超过5--15分钟.

原则三:只应在事先约定的情况下给猴子喂食,经理不应该四处捕捉饥饿的猴子,并不分青红皂白地抓到一只喂一只.

原则四:应面对面或通过电话给猴子喂食,但永远不要通过邮件来进行(记住:如果通过邮件喂食,采取下一步行动的人就是经理了).当然喂食过程可以包括文件记录,但不能取代喂食本身.

原则五:必须为每只猴子确定下一次喂食时间和主动性层次.只要双方同意,这些约定在任何时候都可以修改,但永远不能变成模糊或不确定的东西.否则,猴子不是饿死,就是最终落在经理的背上."对工作时间和工作内容加以控制"是关于时间管理的一条有益建议.第一步是,经理可以通过消除受下属支配的时间扩大自由支配的时间.其次,经理应该把增加的自由支配时间的一部分用来确保下属具有主动性,并加以发挥.第三步是:经理把另外一部分增加的时间用来控制上司和组织分派的任务.所有这些步骤都将增加经理控制时间的能力,使他们在管理"管理时间"上花费的每一个小时都能无限增值.


Gartner发布"云计算安全风险评估"

java060515收录,使用标签:项目管理,时间:2008-7-7 11:34:38 | 相关网摘我也收藏

2008年7月3日消息,据国外媒体报道,研究机构Gartner近日发布一份名为《云计算安全风险评估》的报告,列出了云计算技术存在的7大风险。

  亚马逊的EC2和Google的App Engine是典型的云计算平台。Gartner将这种类型的计算定义为“可大规模扩展的IT能力,通过互联网技术向外部客户提供服务”。 Gartner表示,云计算需要进行安全风险评估的领域包括数据完整性、数据恢复及隐私等。此外,还需对电子检索、可监管性及审计问题进行法律方面的评价。以下是Gartner列出的云计算7大风险:

  1.特权用户的接入

  在公司外的场所处理敏感信息可能会带来风险,因为这将绕过企业IT部门对这些信息“物理、逻辑和人工的控制”。企业需要对处理这些信息的管理员进行充分了解,并要求服务提供商提供详尽的管理员信息。

  2.可审查性

  用户对自己数据的完整性和安全性负有最终的责任。传统服务提供商需要通过外部审计和安全认证,但一些云计算提供商却拒绝接受这样的审查。面对这样的提供商,用户只能用他们的服务做一些琐碎的工作。

  3.数据位置

  在使用云计算服务时,用户并不清楚自己的数据储存在哪里,用户甚至都不知道数据位于哪个国家。用户应当询问服务提供商数据是否存储在专门管辖的位置,以及他们是否遵循当地的隐私协议。

  4.数据隔离

  在云计算的体系下,所有用户的数据都位于共享环境之中。加密能够起一定作用,但是仍然不够。用户应当了解云计算提供商是否将一些数据与另一些隔离开,以及加密服务是否是由专家设计并测试的。如果加密系统出现问题,那么所有数据都将不能再使用。

  5.数据恢复

  就算用户不知道数据存储的位置,云计算提供商也应当告诉用户在发生灾难时,用户数据和服务将会面临什么样的情况。任何没有经过备份的数据和应用程序都将出现问题。用户需要询问服务提供商是否有能力恢复数据,以及需要多长时间。

  6.调查支持

  在云计算环境下,调查不恰当的或是非法的活动将难以实现,因为来自多个用户的数据可能会存放在一起,并且有可能会在多台主机或数据中心之间转移。如果服务提供商没有这方面的措施,那么在有违法行为发生时,用户将难以调查。

  7.长期生存性

  理想情况下,云计算提供商将不会破产或是被大公司收购。但是用户仍需要确认,在发生这类问题的情况下,自己的数据会不会受到影响。用户需要询问服务提供商如何拿回自己的数据,以及拿回的数据是否能够被导入到替代的应用程序中。


微软SOA战略:避开大企业以小企业为重点

java060515收录,使用标签:SOA,时间:2008-7-7 11:29:37 | 相关网摘我也收藏

作者: 东缘,  出处:IT专家网

业内人士对微软本星期发布Hyper-V技术和微软介绍的其SOA进展情况留下个深刻的印象。除了“绿色技术”之外,你在技术领域很难找到第二个这样热门的领域。人们普遍认为微软在Hyper-V技术方面做得很好,但是,在SOA方面完全没有抓住要领。

  为什么呢? 这也许是定义的问题。微软也许没有把“它”当作SOA。分析师认为,他们得到的信息是SOA实际上是Web服务集成,并且认为这是一个两年的旧新闻。人们一直指责微软执行“MOA”(面向微软的架构)。也许这是微软保留自己的机会的权利。这个机会就是以较小、更专业的竞争对手做不到的方式把自己的庞大资源集成在一起。

  但是,ZapThink公司的Ron Schmelzer失望地指出,微软对开发人员的能力和需求的深入理解使它不愿意最大限度地发挥自己的潜力应用SOA,把SOA当作一个忘却的平台或者位置。

  微软连接系统部门产品管理经理Burley Kawasaki最近解释说,SOA不应该是技术推动的。SOA应该是机构的业务需求推动的。我们的方法肯定会受到关注和批评。这些批评一般都声称微软的SOA战略是围绕Web服务发展的和缺少高极性。

  Kawasaki继续解释说,的确,微软并不害怕坚持说Web服务仍然是服务部署的关键。开发人员感兴趣的是更快地开发应用程序。你对他的说法有问题吗?他用了同样多的时间谈了对所有其他股东的好处问题。

  这些信息归纳起来是这样地,Kawasaki顽固地定义SOA是为了实施一个灵活的商务解决方案而采用的暴露、组合和消费方法,而不是创建一个可使用的服务。微软的“现实世界SOA”方法是听从了一些客户劝告的结果。这些客户要把SOA应用到当前的商务流程和问题中,而不是创建一个勇敢的新世界。分析师不喜欢这样。尽管分析师们从来不赞扬微软的“技术创新”,但是,他们现在需要微软在SOA方面的技术创新。

  这会发生吗?Clive Longbottom在IT-Director.com网站发表一篇好文章深入讨论了微软与SOA和微软与虚拟化的问题。他感到有些困惑。但是,我们终于能够发现一些新东西。

  通过Oslo软件把SOA和虚拟化结合在一起,微软能够把目前IT领域的两个最重要的技术联系在一起。这肯定是机构正在寻找的东西。这是根据SOA功能创建动态混合应用程序栈的方法。然后根据动态虚拟镜像在动态应用服务器栈上配置这个动态混合应用程序栈。

  业内人士称,微软的虚拟化和SOA解决方案的进入点也是相同的,都是小企业,而不是大企业。微软没有与大企业厂商展开直接的竞争,特别是拥有SOA的厂商。据说微软甚至不想侵入IBM或者BEA/甲骨文的巨大的SOA市场。微软打算用商品价格的工具打入普及率不高和长期被忽略的小企业市场,并且从那里开始发展。

  业内人士称,微软将利用其OEM和渠道关系用Hyper-V和相关的管理平台猛攻中型企业市场。第一个版本Hyper-V缺少容错和高可靠性功能,使它很难成为大企业的选择。但是,对于首先把重点放在整合方面的小企业来说这个软件还是不错的。


设计模式初学者系列—重构到Bridge模式

java060515收录,使用标签:项目管理,时间:2008-7-7 11:27:27 | 相关网摘我也收藏

在这篇文章中,我将以记述我整个重构过程的方式来得到桥接模式,也许很多人学习设计模式都有我这样的历程,看过很多模式的书籍,但还是无从下手,很多人都说模式往往是重构得来的,但是如何重构?如何去思考?

在这个设计模式初学者系列里我将改变以前的风格,今后每一篇都以真实的项目重构例子来描述重构到模式,所有的描述都来源于现实,如果没有现实的案例那我宁愿不写。希望以这种方式记录能够给一些像我一样曾经很困惑的朋友帮助。

背景


PM:小Y,你看,这个Dundas的Chart(注1)控件效果很好,功能也很强大,但是使用的时候太麻烦了,你能不能将其封装一下,这样其他人使用的时候也简单多了

我:嗯,这个我看看吧,应该可以。

注1

Dundas Chart控件是一个既可以用在WinForm里又可以用在WebForm里的图表控件,可以绘制各种曲线图、柱状图和饼图等等,功能十分强大。在本文中我们要了解Dundas Chart的三个概念:Chart、ChartArea、Series

如是我拿起纸和笔去收集需求:

A:这个我觉得当这个控件上的一个Series的Enabled属性值变化的时候应该触发一个事件,这样我们就可以在这个事件触发时干些事情了,但是现在没有,我不得不做很多工作

B:和A一样的问题,我觉得控件上一个ChartArea的Visible属性值变化时也应该触发一个事件。

C: ………

我的头慢慢的大起来,需求收集了一大堆,怎么弄呢?我还是做了下面这样的个设计

第一次重构:使用继承封装Chart原生API,使其更好使用

我相信很多人第一个设计也许是这样,一下子就想到继承,这样我们可以复用Dundas Chart里面的很多东西了,以免重写很多东西。

下面只选取一段Code:

public class JurassicSeries : Series
{
//...更多扩展

public event EventHandler SeriesEnabled;

protected void OnSeriesEnabled()
{
if (SeriesEnabled != null)
SeriesEnabled(this, new EventArgs());
}

public new bool Enabled
{
get { return base.Enabled; }
set {
base.Enabled = value;
OnSeriesEnabled();
}
}

//.....更多扩展
}

使用继承扩展Series后,我们终于有了这个事件了,但是因为Dundas并没有将他们的一些属性加上virtual,没办法,我只好在这些属性前加上new了,看着总是挺别扭。然后我将新的控件发布给项目组成员,大家都很高兴,几乎不需要改什么代码就可以享受到更好的“服务”了。

但是问题也接着而来

A:使用你这个控件后,我将控件上的内容保存为xml的时候怎么和原来的xml模板不再一样了啊,而且有的时候还老出现一些怪异行为,控件好像工作的不怎么稳定

原来Dundas的保存xml文件功能是通过反射将属性一个个作为XmlNode的Attribute,在我扩展的时候我给控件添加了一些属性,这样保存的XML文件当然不同了,而且由于使用了继承这种白箱复用机制,有的地方改变了控件的默认行为,所以带来控件工作不稳定,怎么办?看来继承也不是灵丹妙药,我不得不再一次陷入思考,寻找别的良方。

本文来自于博客园—横刀天笑
更详细信息,请点击查看原文。


微软将以订阅方式销售Office 年费70美元

java060515收录,使用标签:.NET,时间:2008-7-7 11:17:04 | 相关网摘我也收藏

微软将从7月中旬开始以订阅方式向消费者销售Office程序,以便把Office软件普及到没有购买这个办公软件的节俭的PC用户。

此举也许还将建立一个平台,让微软把面向消费者的应用程序作为一项服务在网络上提供。据介绍,这个捆绑的软件还将包括微软的Live OneCare计算机安全软件,将在Circuit City的700家商店里出售,每年的服务费是70美元。

微软Office部门的产品经理Bryson Gordon在接受采访时表示,与Circuit City商店签署的协议不是独家协议。这个捆绑的软件还将在其它零售商那里销售,将来还会在戴尔等公司出售的PC中销售。

软件订阅价格在企业中很普通的。但是,这对于消费者还是一个比较新的概念。微软提供的Equipt捆绑软件以前的代号是“Albany”。这个捆绑软件包括Word、Excel、PowerPoint和OneNote、再加上OneCare和一些现有的免费的Windows Live应用程序。

采用传统的方式购买这些软件需要200美元。消费者将来还需要全价购买下一个版本的“Office 14”更换这些软件。据说Office 14将在2009年发布。根据新的订阅模式,升级新版本的费用都在每年的服务费中包括了。


视频软件开发商Gotuit起诉微软 称Silverlight侵权

java060515收录,使用标签:.NET,时间:2008-7-7 11:15:22 | 相关网摘我也收藏

近日,视频软件开发商Gotuit Media在旧金山美国联邦地方法院起诉微软的Silverlight多媒体软件侵犯了其3项专利,这些专利涵盖了视频内容在互联网上的搜索便利性。

去年发布的Silverlight技术是微软挑战Flash和QuickTime多媒体技术格式的撒手锏,经过微软的大力改进,使用Silverlight技术,Windows用户可以通过浏览器观看视频和动画。

Gotuit销售的软件能够让用户在视频片段中添加文本数据,便于用户在视频片断中搜索到自己需要的部分。Gotuit的软件已经为体育画报、美国全国曲棍球联盟等数家知名网站所采用。

Gotuit在起诉书中称,由于Silverlight也是通过键入关键字等资料向用户提供强化视频的方式━━搜索、导航自己需要的视频,并提供个性化的观看体验,所以说Silverlight侵犯了Gotuit的专利。Gotuit起诉书中还称,“微软已经侵犯了我们的专利,现在还在继续侵犯我们的专利。”

Gotuit还将微软NBCOlympics.com上有关2008年北京奥运会的视频点播片断列为侵权行为的证据,因为该站点利用Silverlight对视频片断进行标注,使其搜索性更高。

Gotuit要求法院禁止微软使用这一技术,并赔偿经济损失和诉讼费用。

Gotuit法律顾问斯潘塞·霍斯拒绝就这一诉讼案发表评论。截止到本周四,微软的代表还没有就这一诉讼发表评论。


微软七月安全公告预告:四个重要等级更新

java060515收录,使用标签:.NET,时间:2008-7-7 11:14:56 | 相关网摘我也收藏

微软公布了七月安全公告的预告,我们可以从安全通告中看到本月微软将发布四个重要等级的更新.

其中2个影响Windows,1个是SQL的提权漏洞,1个Exchange Server的提权漏洞.这些漏洞届时都可以被Baseline Security Analyzer检测并更新.下周8日的Patch Tuesday将公布这些更新.

查看原文:Microsoft Security Bulletin Advance Notification for July 2008
http://www.microsoft.com/technet/security/bulletin/ms08-jul.mspx


微软步入后盖茨时代 鲍尔默应作10件大事

java060515收录,使用标签:.NET,时间:2008-7-7 11:14:21 | 相关网摘我也收藏

随着创始人比尔·盖茨(Bill Gates)的退休,微软已经步入以CEO史蒂夫·鲍尔默(Steve Ballmer)为首的“后盖茨”时代.大多数分析师认为,由于交接工作准备得很充分,失去盖茨的微软仍将继续前行.但鲍尔默应该重点做好以下10件事情:

1. 把教育用户作为企业使命来抓

微软的Windows、Word和Excel等产品中功能丰富,但消费者却并不完全了解.其结果就是,消费者耗费大量的时间来解决一些微软产品已经攻克的问题.因此,鲍尔默应该在该领域投入一笔资金,以帮助用户了解微软产品的功能.

2. 不要把技术战略任务完全抛给奥兹

雷·奥兹(Ray Ozzie)对技术的发展趋势确实很敏感,但真正了解微软在未来10年希望给用户带来怎样用户体验的还是鲍尔默.

3. 把微软作为研究案例向其他企业高管开放

经营全球最大企业之一并不是件容易事情,因此,鲍尔默应该向其他企业的CIO和IT高管开放微软,让他们了解微软是如何把技术与商业目标结合起来的.

4. 不要痛骂竞争对手

目前,微软仍几乎垄断每一个市场,因此鲍尔默没有必要像以前那样痛骂谷歌和苹果等其他竞争对手.相反,微软应该把精力放在改善产品和发展业务上.

5. 微软应该推出一项开源项目

多年以来,微软一直在坚持同一种商业模式.事实上,微软应该推出一个开源项目,像Firefox或Linux那样,允