2012年4月1日

最近一个月一直要研究基于MSMediaServer与DRM 结合的问题，主要用途为架设一个流媒体网站，网站最重要的功能为对视频的保护。

于由我开始研究何种技术能对视频加密与解密。最初我确定的三种方案：

第一种：种用微软的DRM加密方式，该方式需要架设专门的证书服务器，其原理为用证书对视频进行加密打包，因为打包后的视频会在视频的头部加一个校验头，可以到固定的证书分发页面请求证书，这种方式原于很多年前算是一种过时了的技术，而且需要每年够买微软的证书，但对了视频的保护算是一种比较好的解决方式。不足之处是只能使用Media Player播放器，播放视频。

第二种：采用微软的PlayReadly方式，该方式应该是DRM的升级版。该服务比较强大可以支持移动视频加密而且可以和Silverlight完美结合。但是可惜的是目前我也没有看见过这东西。至少中国微软这边还没有开始买这东西，之前听说微软研究院那边之前用它为电信做了一个解决方案。

第三种：基于自己编码编码解码器，这种方式需要通过C或纯语言编写编码解码器，另外需要配合ActiveX让客户端在浏览器中能够解码。但是由于开发工期短，没有选择这种方式。

最终由于种种原因我们选择第一种方式：

在实施过程我们发现一个比较大的问题DRM证书服务器在分布证书响应时间是一个比较慢长的过程，应该是在S级吧。所以在一个大型视频网站同，这种的影响速度是肯定不行的，我通过做LB也不行，因为证书的加密解密是对称的，你通过那个证书加密就只能通过那个证书解密，解密的过程与解密服务器是有关系的。所以对于做LB是一个比较大的挑战。

最后我们分析DRM整个过程

打包：原始视频-》打包（添加证书的Challege到视频头部）-》生成DRM加密视频

解密：DRM加密视频通过Media Player播放器请求解密页面-》页面接收Challege字符串-》通过本地证书解密并生成Public Licesen-》返回客户端-》通过JS安装证书-》播放

由于我们开始在生成证书环节开始作文章，我用采用的预发证书方式与实施证书分发方式。

预发证书方式：我们通过Windows Services方式将证书预生成并存放在数据库中。用户访问时从数据读取。

实时方式：用户请求一次，分发一种证书方式。

最后通过这种方式解决了用户的需求与大用量的需求。

  2012年2月3日

     前段时间刚跳公司的SPM研发项目，在即将离别之际自己总结了在项目所得所失，感慨万千呀,虽然该项目在我个人心中应该算一个失败的项目（研发项目吗，都说是无底洞），但项目的一些规范与管理方式我个人认为还是可以借鉴，比如基于Team Fundation Server的Task项目管理！言归正传，首先简述一下什么是SPM(Software Procedure Manage)，SPM即软件过程管理，我在上一篇文章中提到过软件规范化生产，如果一个公司要实现软件规范化生产除了资金链和业务线以外，最重要的就是能支撑这些生产流水线的一个平台，更深层次应该包括对这些项目生产过程中的一些宏观与微观的管理。

　　Team Fundation Server:TFS（Team Foundation Server ）是一个工作流协作的引擎，它允许一个团队使用他们自定义的流程，并使用在项目历史中实时收集起来的一个集中的数据仓库。Team Foundation Server 和 Visual Studio Team System 中其它的部分一起，组成了软件开发过程中的核心部分。我们的方法是唯一的，因为前端的设计有良好的可用性，而后端的设计集成了整个生命周期。我们主要关注于可用性，以及为个人和团队以一种无缝的方式进入软件开发周期。客户关心的另外一个方面是灵活性和审核。Team Foundation Server 支持 Software Engineering Institute 的 CapaBIlity Maturity Model (CMMI) 的报表和审核的功能。通过 Team Foundation Server，组织可以自动收集必要的信息，并生成自定义的报表，它可以帮助在工业管理中定位增长点。

     Task:即工作项，我们在TFS中我们可以看到TFS是通过工作项来对不同工作项还区分软件过程的一些任务的，比如用户情景、Bug、任务等。

     上面简单的简介了，面下我们正式讨论是如何基于Team Fundation Server的Task进行软件生产与管理,首先我们把软件生产按敏捷开发的方式，以迭代进行划分。然后我们对软件的生产人员进行划分，我们初步定义为项目经理、程序经理、开发人员、测试人员等。而这人员在按照敏捷模式进行工作时或多或少的会接收到一些工作任务。比如分析需求、编写用户场景、进行设计、编码代码、测试功能点、修改bug等。我统统将这工作称为Task，并且这些Task可折分，可更改的。我可以对大的Task折分成小的Task,而这个折分过程实际上就是工作任务的细节，我对这此Task添加一些属性，比如：

　　标题:用来明确工作任务的人

      工分：量化工作任务的价值

      指派给：接收任务的人

      区域：附于的项目

      状态：标识任务的进展情况

     优先级别、预计开始时间、实际开始时间，工时等等属性。

     有了这些属性我们可以过些属性对项目的一些KPI值进行微观的调整，并能对通过对这些KPI调整使项目回归正式，另外我们可以统计这些属性很好的形成软件生产报告。

     下面以一个例子还描述：

      假如一个项目中有一个开发组长与一个开发人员，这里开发组长除了进行基本的开发工作外还负责一些项目的基本的管理：

      1、根上面的需求我们需要开发一个记事本。

      2、开发组长拿到需求后，对这些需进行折分，将其折分为能在短时间（这个时间应该根据公司的情况与客户的情况与界定）完成小Task.并将其指派给开发人员。当然所有Task属性均为初始状态。

     3、开发人员收到相应Task，根据需求进行相关的开发，并即时更改Task的状态，一直到任务完成。

     4、开发人员完成任务，并关闭这个Task，随之将后产生另一个task（测试人员的工作）,测试人员开始进行测试（如果测试完成就可以更改这个工作项的状态），如果测试过程产生bug,我们这些bug与这个开发人员的task进行连接。因为我们在修改bug过程中会使用工时，也是一种工作任务。

     5、项目进行到一定阶段后，我们可以对这些属性统计比如工时，我们共计使用的多少工时，项目的预工时是多少。

     6、最后形成的报告，不仅可以进行汇报也是使管理人员对软件生产与管理提供一个提导。

     当然这些功能我们完成可以由Project Server来做，但是我们知道Project Server主要是面向管理人员的提供项目的人员，资源，进度的管理。而Tfs除了面向管理人员进行基本的管理外，还面向工程人员进行软件生产的代码管理等功能。另外如果我们在外围开发一些功能，形成一个大的功能集功。这样就可做软件规模代生产的机器了，这上面提出的这种管理方式只是基于这种机器的一种模式。

     欢迎大家讨论！

  2012年1月29日

    前几天和几个同事讨论软件规模化生产的问题，觉得颇有意思。现在提出和大家共同讨论一下，目前我们熟知软件行业在全球进行了N年，但一直没有实现规模化生产，像制造行业或其它行业经过10-20年时间，能够形成流水线式的操作。我个人觉得可能与如下因素有关：

　　1、软件生产，软件的生产除了我们头脑风暴然后就是电脑，不存在其它原材料；

　　2、正是由于人的因素，软件行业在近期内无法实现规模化生产，行业的人员流动问题；

　　3、软件的开发模式，国内目前大型软件均为精英团队开发；

　　4、软件的个性化问题，无论是同行业的软件还是不同行业的软件与公司的业务联系的太紧密，不能实现通用化；

　　5、软件开发学术重于实践，我们不难看到某个成果在学术上已经很成熟了但至少要推后5-10年才能进入运行阶段；

　　6、软件开发技术的不断更新，为了不断提高开发效率与简易性，技术不断更新。以至于相关人员大部时间除了学习还是学习；

　　7、国内软件研发与外包的比例问题；

　　8、软件开发周期问题，我们经常跟进一个项目需要2-3年或更长的时间；

　　9、没有完整的标准；

　　等问题！

     当然这行年软件行业的发展也在慢慢的规范化，我初步设想的是软件要实现软件的规模化生产我们需要以行业作为分类，因为我们知道，我们开发软件都是根据需求来的，而同一个行业的需求应该是最相近的，比如我们以烟草行业为例，我们成立专门的烟草流水线（不会管开发工种或语言的问题），也就是我们通常所说的业务。我以此作为分类，对为不同行业形成不同的流水线（项目充足的前提下，如果我们开发成本足够低，质量高，周期短，项目应该不是问题）。配以软件工人，软件工人不需撑握过多的技术或业务，只需要对该行业的业务比较了解。这样不一来不仅可以降低我们的开发成要，人力成本等，也可以提高我们的开发效率。因为我们可以各司其职。我们将业务与需求的分析转移到专们的部门去，开发部只需要做开发，需求分析什么都不用管。将各自的责任分开，责任最小化，明确化。各行业按各行业的开发规范进行约束，行业与行业之类彼此独立！

　　当然上面只是一种设想，首先我们需要解决的是开发人精英化到平民化。国内的开发项目，特别是大型目项大部是精英化团队，而且此人员我个认为是没有发挥到精英的作用。因为的人对业务是精英可能不是技术的好手，是技术的好的不一定是业务的精英。所以我们应该尽化将精英化的团队转变为专业化的团队，行业化的团队。

　　其次IT行为人员流动的问题，我个人觉得之所以IT行业的人员流动会到20-25%之间，正是因 为软件开发的源材料的问题，其它软件开的重要原材料就是人，人不是机器，而公司过多的把人员机器化，不能对员工做到人性化，还是把制造业的经验搬到IT行业中，这样是不现实的。机器是死的人是活的。应该过多考虑人的因素。虽然很多开发模式提出的人的重要性，但基本上治标不治本。我们应该考虑心理学在IT行业中的运行。

    再次软件开发周期问题，我们的软件开发周期真的需要那么长时间吗？我个人认为得打个问号。我们经常很到五年前的需求，五年后还在开发。周期长这个问题也是软件不能规模化的重要因素。如果我们能做到软件流水线化。我相信很多问题都可以解决。与此类似的软件学术化，很多重要的理论经常在学术界讨论数年，还不如将其投到实践中去检验。

　 当然以上只是我个人观点，欢迎大家讨论！

  2011年2月25日

这几天正在试验sharepoint 2010 发送SMS功能，深入的了解一下。

一、先找到一个sms功能提供商，我们可以 在office online 找到相应的公司，一般的公司都会提供10条SMS免费发送。

二、我们开始 配置sharepoint server

　　sharepoint 管理中心-〉系统设置里面->移动

     我们进入里面会要求提供一个web services地址和用户名及密码。

     （我在office online找到相应的提供商）并用他们的提供的web services地址与相关信息测试了很久都不能成功。并不是相应信息的问题。之后我发现是还需要导入提供商的让书因为web serverice 你认真观察会发现是https的是经过ssl加密的。所以我们要导入提供商的证书。

三、我们现在开始导入证书

      首先从服务商网站中导出证书如下：

　　在IE中输入之前web services地址，你发看到下图：

     单击地址的按钮，单击查看证书，会所到如下图：

  导出现相关证书：

  然后将证导出的证书，导入到sharepoint 站点去

  管理中心的安全下面可以导入证书

然后我们重新配置管理中心-〉系统设置-〉移动。测试帐户你会发现能测试成功并能利用“通知我”功能发送SMS了.

(另外提到一点sharepoint sms 用到的是oms)