MOOC算是我知道的80年代的电视大学的延伸。我记忆中的中国80年代是开放、蓬勃、纯真和好学的年代。那么多的人想读书并真正去读书。特别是80年代中后期，电视开始逐渐进入普通家庭，当时的电大教育给那时的小青年甚至中年人提供了接受高等教育的机会，其对个人和社会的整体效益不可低估。那时我只是个十几岁的孩子，没跟着电视上大学，但我知道有人听电视上的高等数学、物理、化学、文学等的授课，应当还有函授式的作业。

MOOC是在电大基础上的延伸和扩展，只不过由于是在网上以及互联网在全球的普及，其影响力更大。能上网的人都可以学，免费。以我有限的体会，我注意到的特点有：

1. 目前我了解到的网上电大有Coursera，Udacity，和edX。都不错；
2. 授课采用短小的录像。录像长度平均十来分钟，在线播放和下载都可以；
3. 一般每段录像都以一个主题为中心，中间会穿插些选择或填空题。这些题目用来测试你对刚刚讲过的概念、方法等的理解；
4. Coursera录像有字幕选项。如果理解英语有困难，按下字幕键后读字幕会有帮助；
5. 一般每周会有家庭作业。我上的都是电脑课，所以自动化程度高一些。作业都是些编程和回答数据相关问题，提交后的反馈很快；
6. 有的课程会有同学评分。由于学生来自全球各地，所以评分都是匿名，也很有意思；
7. 每个科目都有网上论坛。在此潜水、提问、回答问题等都非常有帮助。了解来自世界各地的人都观点是很有意思的事情；
8. 根据课程的不同，有的会有期中或期末考试。如上文所述，我选的都是和电脑有关，考试都是选择题，反馈很快；
9. 课程介绍里会告诉你如何算通过该课程。通过后一般有一张认证。
10. 深受世界人民欢迎的课程一般会重新上线。所以条件不允许而不能上（或不能坚持下去）某节课，以后很可能还有机会。

我个人以为这些课程对在职和在校的人士都很有帮助，这对大学里的老师也会有启发，也是学习、提高英语的好方法。如能抽出时间上这些课，应当很有收获。

我的建议：

1. 确保有时间。家庭、工作第一。如上所述，如果目前时机不成熟，以后还有机会；
2. 一般来讲上电脑课，有个虚拟机比较好。虚拟机给你除掉后顾之忧，在上面放心大胆地尝试，玩它个爽歪歪；
3. 要做作业。光听、光看不动手当然不如甩开膀子干一场的效果好；
4. 看录像时利用英文字幕。这对提高英语和了解专有名词术语有帮助。在Coursera的在线录像里，如有必要，你还可以放慢录像速度。如英语过关，也有加快速度功能；
5. 有同党和狐朋狗友一起学效果会更好。大家互相激励、分享和解难答疑就能共同提高。

推荐课程：
Introduction to Systematic Program Design – Part 1
这门课下周一正式开始，但今天老师已经公布了下两周的录像和作业。Gregor Kiczales老师来自加拿大的英属哥伦比亚大学，University of British Columbia。Kiczales是大牛，当然这不重要，因为大牛未必是好老师。但从我看过的录像和网站的准备工作来看，他是个好老师。力荐！

如你对编程感兴趣，Dan Grossman的Programming Languages非常好。现在已下线，但重新上线的可能性非常大。这门课很花时间。另外，Scala的作者，Martin Odersky的Functional Programming Principles in Scala也很好。我跟着学了一段时间，但由于其他事情太多没时间而放弃。等以后有时间会重修。

好，就写到这儿。比较晚了，按说早该上床睡觉了。咳，谁让我那么爱我遍及五湖四海的读者呢

I’ve written about using Vagrant and Veewee to make that process easier. I’ve since changed my strategy slightly:

• I don’t recommend using Veewee anymore, because silly Ruby compatibility issues. I like the idea of Veewee, but in my opinion jumping through hoops to get it to work with Vagrant is no longer worth it. It is often quicker to just build a VirtualBox vm and then create a Vagrant box out of it than taking the Veewee extra step and remembering those extra commands. I couldn’t find the link now, but I thought I read somewhere that Vagrant has plans to make VM box creation easier;
• I don’t use Vagrant for managing Windows VMs anymore. I tried but my effort was not too successful so far. Again, I read it somewhere that Windows support will be provided in future release of Vagrant. We will see.

My use cases in the past mostly involves single VM. For networking among Linux VMs, the instruction in my Vagrant post still works. But what if you want to build a Windows VM environment with domain controller, database servers, web servers, and other application servers based on a single VM image. So far I’ve built an environment with a domain controller and a seperate application server (I will soon install SQL Server on it). Here is my notes for reference. The host machine is Lenovo W520 running Linux Mint 14.

1. Download Windows 2012 ISO here;
2. Start creating a base Windows 2012 VM in VirtualBox. Use the vdi disk type to make it easier working with VirtualBox;
3. I could have installed the Data Center eval edition, but chose the standard instead. I didn’t choose the Core edition. Using the Core edition might make more sense in a real production environment, but I’d like to get something going quickly and also want to use the same image for all future VM needs, so the standard non-Core install works the best for now. I may come back and play with the Core edition down the road;

   Note: There are sites that talks about the possibility of activating Windows with an official license key, so that future VMs based on this image no longer need activation. My advice is: don’t bother with it. Licensing issue aside, my reasoning is that if you decide the VMs are going to be part of a domain, they then need to have their unique SID, which requires a separate Windows key, I think. Plus, I’ve run eval edition of Windows that has past its validation date but it still functions, probably in some limited capacity, but so far it hasn’t affected me. So I am hopeful that for my purposes, the eval edition of Windows 2012 will satisfy my need.

4. Build the base VM with NAT networking. It is convienient for the VM to have access to the web directly. We will add additional netword card(s) when we clone this base image.

   Once the base VM is built, copy that single vdi file somewhere else. Then remove/delete this base VM from your system all together;

5. Make the base vdi immutable by running this:

   VBoxManage modifyhd pathTo/myBase.vdi --type immutable
   

6. Build a domain controller based on this image. When creating a VirtualBox hard disk, use the base vdi file. At this point, add in a second network adapter, which should be type “Internal Network”. Take the VirtualBox default value for the rest of the fields;
7. Finish building the VM, change the VM to a proper name, such as DCServer or whatever you feel is appropriate;
8. Shutdown the VM, then run this command against the vdi file in your new VM’s Snapshots folder:

   VBoxManage modifyhd ~/Virtual Machines/myNewVM/Snapshots/{someName}.vdi --autoreset false
   

   This step is necessary, otherwise VirtualBox resets the VM to the base image after every reboot;

9. Now install the appropriate software and set this VM as a domain controller. Follow instructions here.
10. Configure the network card for the “Internal Network” by assigning a fixed IP address. If you’ve followed the instructions, the second network card should be called Ethernet 2. I didn’t bother with IPv6, and gave my VM the fixed IP address of 192.168.1.10. I left everything else to its default value. Note that after entering the IP address, the Subnet mask will be 255.255.255.0. I didn’t change that and didn’t touch the rest of the fields;
11. Turn off all Windows firewalls. In addition, open up “Group Policy Management”, expand to Domains->MyDomain->Default Domain Policy. Right click and choose “Edit…”. Group Policy Management Editor opens up. Under “Computer Configuration”, expand to Policies->Windows Settings->Security Settings->Account Policies. Change password policy accordingly.
12. Take a snapshot of the machine. Mark every disk file under the Snapshot folder so its autoreset is false.
13. Now build another VM. Add the second network adapter for “Internal Network”. When done, shut it down and change its vdi disk file’s autoreset property, described above;
14. Because this VM and the domain controller VM use the same base image, so by default they will have the same SID, which will prevent them to be in the same domain. Fix that by starting this new VM, then run sysprep. Follow the instructions here, if you need it.
15. Reboot the new VM again, configure its “Ethernet 2″ before it can join the domain we created earlier. Here is my configuration. Once again I didn’t touch IPv6:
    IP address: 192.168.1.11
    Subnet mask: 255.255.255.0
    Default gateway: 192.168.1.10
    Preferred DNS server: 192.168.1.10
16. Rename the VM to an appropriate name, for example, sql1. Then join the domain we created earlier. Obviously the other domain controller VM needs to be up and you’ve run sysprep on this second VM. If you haven’t assigned a different SID for this new VM, you will receive error message like “the domain join cannot be completed because the SID of the domain you attempted to join was identical to the SID of this machine …”
17. Repeat the process of building other VMs to join the domain, if you have the need.

Any comments/suggestions welcome. Good luck!

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SqlServer.SMO”)
$MyServer = new-object (‘Microsoft.SqlServer.Management.Smo.Server’) ‘HOME’
$MyDataBase = new-object (‘Microsoft.SqlServer.Management.Smo.Database’)
($Server, “MyDataBase”)

That’s a lot of typing and looks messy and cumbersome.

Since SQL Server 2008, Microsoft provides a sqlps shell which exposes a lot of SQL Server objects and functions for easy browsing and inspection, but one couldn’t import that into an existing scripts for easy automation. With the release of SQL Server 2012 Feature Pack, it is now possible to expose sqlps functions in your scripts by running:

Import-Module sqlps

Here is how to get sqlps installed so it is available to import as a module. I’ve tested this successfully on both Windows Server 2008 R2 and Windows Server 2012. To get some idea on how to use it, perhaps some of my scripts here can get you started

1. Go to SQL Server 2012 Feature Pack site

2. Download and install the 3 items below
Microsoft System CLR Types for Microsoft SQL Server 2012
Microsoft SQL Server 2012 Shared Management Objects
Microsoft Windows PowerShell Extensions for Microsoft SQL Server 2012

BeginDigression
Given a choice, I’d rather write automation programs on Windows with either Python and Perl, because both languages come with a comprehensive testing framework that supports TDD. With test cases and various testing harness, it is much easier to build solid, high quality software solutions.

However, if for whatever reason, it is difficult to use Python or Perl, then the natural choice on Windows is PowerShell, because it comes with the OS. Too bad PowerShell does not have a solid testing framework. I have been using PSUnit, which leaves a lot to be desired for people who are used to xUnit framework, but it is still worthwhile to use.
EndDigression

1. It was good catching up with a few friends. There are still a few old friends I missed, and a few that I really would have liked to talk longer.

2. Microsoft’s Hekaton announcement is interesting. A few years back I saw VoltDB demos and that was impressive. Microsoft’s announcement will accelerate in-memory transactional database developement and help bring this technology to a wider audience.

3. Solid state disks see more adaption but they are still pretty expensive. Hopefully its wider adaption will help to drive the cost down as time goes on. There are a few vendors that uses some creative ways to squeeze the most out of the investment by pairing mechenical disks with solid state disks, such as algo-based data movement: when it detects some data on spindle disks are “hot”, it moves them to solid state disks. That sounds interesting if done well.

4. It was really nice meeting a number of Chinese-speaking attendees. Great networking and fun discussions!

5. The mojito and bloody mary from Edge Grille is not very good in my opinion. Beer from Gordon Biersch is ordinary, nothing to write home about, ymmv.

稍具规模的软件开发，不管是商业或开源，一般是由一个团队来完成。团队写软件，必然会有一系列的分工。比方说，张三可能会写一些处理客户订单方面的library, class,和/或function；李四会写库存管理方面的代码；而王五负责物流和采购；等等。当然也不能排除张三发现李四代码内的问题进而修正的现象。我们在这里假定队里的工程师们已经统一使用一种单元测试机制并且会写单元测试。但最终我们要把这些代码通过代码库整合集中起来，确保作为一个整体，这些代码可以通过所有单元测试，没有冲突和编译错误，并且编译好的binary/executable符合事先订好的规范。这种源代码的整合、总体通过所有单元测试、代码链接和编译以及编译后的一些测试，即为集成测试，integration testing。

在团队开发环境里，各团队成员写的部件会有依赖性。如果我们数天、一周、甚至更长的时间里才做一次代码集成，就很可能会遇到以下情况：来自不同成员的代码部件可能有冲突，界面和生产环境的变化没能及时得到沟通和传达到每个队员，一部分的代码故障修复造成了其它部分的故障，等等等等。这会引进bugs，造成部分或全部的代码回滚，代码的不可编译，甚至拖延产品的发布或升级。为了解决这一常见问题，我们需要尽可能早、多次、自动化地运行集成测试。持续集成测试，即continuous integration testing，就应运而生。

自动化的持续集成测试由软件来完成。现在业界有不少continuous integration testing的工具，开源和商业的都有，像Buildbot（Python写成），Jenkins（Java写成），TeamCity，CruiseControl等。在本文底下我会给两个实战集成测试链接：一个是MariaDB的，用的是Buildbot；一个是Percona的，用的是Jenkins。读完本博后你可以到那两个网站看看，可以分析出他们的集成测试都做什么，有什么报告等，希望对你有所启发。集成测试机制一般有以下特点：

1. 和代码库挂钩。代码提交/check in/commit会自动触发集成测试；
2. 除了代码提交的自动激活测试外，一般可以安排时间定期来做集成测试，比如每天晚上一次；
3. 在编译和构建binary的同时或之后，该机制还可以和其它机制挂钩，如生成文档，给软件打包，做其它测试甚至生产发布，等等；
4. 有网页界面来回报集成测试结果。这结果包括集成测试状态，该集成包括哪些代码变化、bug fixes，新性能等，代码覆盖测试/code coverage报告等等。

一般情况下，如果队伍和产品有一定规模，可以考虑设置专门的build server来完成以上步骤。持续集成测试会给我们带来以下优势：
1. 尽早发现不同队员代码之间的冲突，减少甚至铲除难缠的由于不能尽快整合而对全局有负影响的问题；
2. 促进团队内部沟通；
3. 在紧急情况下，如果需要部署最新软件来解决生产环境中的燃眉之急，你有了可以直接部署的binary。

我个人以为建立持续集成测试机制对一个团队很重要。从我的理解和体会，我觉得以下几点值得注意：
1. 如上文所述，团队用统一的单元测试架构很重要。有了这个架构，工程师要写单元测试；
2. 养成多次从代码库拉下更新自己代码的习惯，每个工作日至少一次。一天可以多次提交代码；
3. 在代码提交之前，完整运行一次所有单元测试，包括组内其他成员的单元测试。测试不通过，不提交自己的代码。更何况，如果你的代码没通过单元测试而被提交，那集成测试机制会发现这个问题并在网页上公布出来，你会觉得很没面子。

好，这次就写到这儿。下次继续，可能会写下接收测试acceptance testing，stress/performan testing之类吧。如上文所述，这里是MariaDB的持续集成测试网站链接（Buildbot）；这里是Percona的持续集成测试网站链接（Jenkins）。

PS C:\Windows\system32> Import-Module ServerManager
PS C:\Windows\system32> Add-WindowsFeature RSAT-AD-PowerShell
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True    No             Success   {Active Directory module for Windows Power...

2. Link for newly added Active Directory cmdlets after installation, pretty useful;

3. There are two types of Active Directory groups: distribution and security. The former is for email distribution and the later is what most people had in mind: groups used for security and access management. So if you are not sure, use security group;

4. LDAP search string and DN (Distinguished Name) follow the convention of putting contained item in the front. Scope increases from left to right, in other words. For example, “CN=eastRegion,OU=Benefits,OU=HR,DC=research,DC=hardware,DC=acme,DC=com” can be a security/permission group called eastRegion that belongs to OU (OrganizationUnit) Benefits, which belongs to OU HR, under domain of research.hardware.acme.com. DC stands for Domain Component, by the way.

5. This site has info on filtering of Active Directory. Very useful. Below is an example of getting all security groups. You may need to run Import-Module ActiveDirectory first:
$a = Get-ADGroup -SearchBase “OU=Benefits,OU=HR,DC=research,DC=hardware,DC=acme,DC=com” -filter ‘groupcategory -eq “security”‘

6. Oh, dsa.msc, if you have installed, is a useful GUI tool. Good for verification and quick glances.

1. Put PowerShell functions in one file such as myBaseFunctions.ps1;
2. Create a test directory and under that directory, create a test case file called myBaseFunctions.Test.ps1;
3. Here is what the first two lines of the test case file:

. PSUnit.ps1
. "c:\properPath\myBaseFunctions.ps1"

4. A sample test case:

function Test.getFileName()
{
#Arrange
    	$expectedResult = "X:\somePath\someName.sql"
#Act
	$actualResult = functionBeingTested -Para1 "someValue" -Para2 "someValue"
#Assert
	Assert-That -ActualValue $actualResult -Constraint {$actualResult -eq $expectedResult}
}

5. Running tests on command line:
PS C:\myDirectory> PSUnit.Run.ps1 -PSUnitTestFile properPath\myBaseFunctions.Test.ps1

单元测试主要用来检测某class，function，method的正确性。我想绝大多数工程师在编程时都会做各种各样的单元测试。但直到约上世纪末和本世纪初，系统性、自动化的单元测试机制才被真正地建立起来^注,见下。说到这里，我们必须提到Kent Beck和Erich Gamma。

Kent Beck在90年代末用Smalltalk编程，在那段时期他写出SUnit，是用Smalltalk写出的给Smalltalk程序做单元测试的架构。在此基础之上，他和Erich Gamma携手创建了JUnit。JUnit是用Java写成的用来做Java单元测试的架构。从JUnit开始，统称为xUnit的测试架构以燎原之势传入到其它语言：Python（unittest），PHP（PHPUnit），NUnit（.Net语言如C#，VB.net）等。

xUnit的架构和基本思路实际上很简单：Arrange-Act-Assert：
1.把输入值和期望值安排好，必要时可以装逼（mock）。mock是当你的单元测试需要大、笨重、或复杂的外部资源支持时（如数据库，其它复杂API等等），你可以用个假模子mock来代替。这一步是Arrange，设定期望值；
2.调动要被测试的function/method/class，得到实际值，这是Act；
3.比较期望值和实际值，报出测试结果，这是Assert.

或许你会说，这有啥大不了的，我编程时所做的随机测试就是这么做的吗。没错，但像xUnit这样的测试机制提供了自动化、可重复性和方便性等特点。

1.自动化
良好的xUnit测试机制有所谓的test harness，即各种脚手架、工具等配套的捆绑机制。在按xUnit规范写出测试案例后，可以很方便地用该捆绑机制轻松调用全部或部分测试案例，不用笨手笨脚地做手动调节；

2.即时性
和上文紧密相关的是xUnit带来的即时性。在写出一个测试案例后，你可以很方便得用copy/paste/adjust来写出更多其它测试案例。因为有自动化机制，运行这些案例会很方便快捷，成功与否，结果立现。这样你就可以在思路、信息还停留在脑海之时，趁热打铁，迅速、有效地解决这个问题。顺便说一句，英语中也有这一俚语：strike while the iron is hot。不知该成语是否是翻译、借用来（中英或英中），我感觉自发生成的可能性大些。

单元测试是你的安全网。随着你单元测试的增多，你的安全网就变得越来越密集，漏网之鱼就会越来越少。测试给你的软件质量提供了足够的保障。

如果说我们对单元测试的重要性和自动化有了共识，我有以下想法和你共勉，让我们一起来学习和提高。弄好测试，如俗谚所说，磨刀不费砍柴工，会大大提高你的功力！

1.搜索出并安装适合你编程语言的xUnit测试框架。比方说你写PHP，那你可以用PHPUnit。如你用Python，如果是2.7以后的话，你可以用标准的unittest模块来做测试：注意要安装nose来做这个测试的harness，来方便地调用你的测试案例。像其它语言，大多数都会有xUnit，搜搜就可以找到；

2.花时间学习如何写单元测试案例和如何有效地调用单元测试。相关的tutorial，how to等应当不少；

3.在做新开发时，要给新function/method/class写单元测试。当有时间或需要修改已存在代码时，如那段代码没单元测试，逐步引进单元测试；

4.单元测试也是代码的一部分，当然要进入代码管理库；

5.用copy和paste，写出各种满足边缘参数、一般参数等各种情况下的测试案例。硬盘便宜，多存几个案例占不了多大空，注意好的文档和命名方式对案例的管理很有帮助；

6.如果在整合测试/integration test或质量检测/quality assurance甚至是生产环境中发现你的function/method/class出现问题时，请首先写出个单元测试案例来捕捉这条漏网之鱼，然后修改代码来让测试通过。这样你的安全网就会被织得更紧一些。
在完成这个修改之后，你要反思一下为什么一开始你没想到要写这个测试？为什么没有想到鱼会有这种形状和技巧来挣脱你已经编织的网？通过这种反思，你会慢慢增加你的编程洞察力、嗅觉、和敏锐。

好，先写到这里。下一篇继续。我可能会写integration testing和continuous integration testing。或者专门写一下单元测试的应用实例如Python。如有问题或评论，欢迎提出，我们一起切磋，共同前进。

注：Perl的TAP（Test Anything Protocol）值得专门提一下。早在1987年，即随Perl第一版发布，就有了自己的单元测试机制。这比SUnit（xUnit之前身）要早10年左右。之后大部分在CPAN上公布的模块都经过了Test：：More的符合TAP规格的单元测试。我个人以为这是Perl作为元老级脚本语言，至今仍威风八面、历久弥新的主要原因之一。所以如果你用Perl编程，我强烈建议你掌握Test::More和相关的Test::Harness模块。

1. 尽快制出原型产品（prototype）；
2. 尽快把原型产品拿到生产环境中做检测和获得反馈；
3. 尽快把在生产中得到的反馈数据和教训融入到下一步的故障修复和性能提升；
4. 把改进后的产品再次尽快拿到生产环境中做检测和反馈；
5. 循环以上步骤。

在这样的流程里，有以下几个方面特别值得注意：

1. 尽快做出原型产品并拿到实战中（或近可能类似于生产环境中）检验。
和用户互动，了解实战应用场景，检索、阅读、和了解业界同仁的文章和经验积累，搜索、阅读、分析网上网下的关于各种语言、解决方案的文档等都是很重要的过程。但把想法和了解到的信息付之与实践之前，那些理论、分析、和研究到头来只是纸上谈兵。把东西付诸与实践后，你会加深和巩固自己对已有知识的理解，碰到和解决自己和别人没有想象或碰到的问题，把学到的理论和步骤加以调整后运用到自己的环境中去。这是Kent Beck在极限编程/eXtreme Programming/XP中的一大重要、也是在实战中极端有效的一个原则。这一点和陆游在1199年写的《冬夜读书示子聿》里说得是同一个道理：

古人学问无遗力，少壮工夫老始成。
纸上得来终觉浅，绝知此事要躬行。

2. 快速的检测和反馈需要可靠、方便、和尽可能自动化的测试机制。
原型产品出来后肯定会有这样或那样的问题：有的地方需要改进和提高，有的地方需要添加新功能等等。我们在做改进和提高的同时还要做到已有功能不退化（regression bugs）。要能够实现这一目标，唯一有效的办法是建立起有效、系统、和自动化的测试脚手架。有了这种测试机制，并配有有效的源代码管理系统，我们就敢于去做代码改进和重构，就有足够的信心来保证代码的质量和可靠性。

前一段时间读Kent Beck的TDD（Test-Driven Development）书，他举了这样一个例子，我觉得挺贴切的。我们都知道用轱辘打水比从井里直接往上提省力，是打水的有效方法。假设水提到一半后你累啦或有别的情况而hold不住，你的努力就会前功尽弃。但如果你在轱辘上安装个齿轮机制来咬住你的进程而不至于让提上来的绳子后退，那你就会轻松、自信地打很多水。有效、自动化的测试机制就是你用轱辘打水的那个齿轮，它给你信心和回旋余地，让你大胆、放心地去修复、改进、重构、和添加新功能，让你有信心和实效来生产和提高产品，在保留既有功效的前提下扩大战果，打一场干脆利索、无后顾之忧（或担忧最小化）、不拖泥带水的漂亮仗！

在编程中，如果我们把每一个类/class、每一个函数/function都当作一个产品的话，根据上述“尽快做出原型产品并拿到实战中检验”的法则，我们就可以很容易地理解TDD的原理：
a.我们对某类或某函数的界面有初步打算，即脑中已经设计出原型；
b.在实施该类或函数之前，我们写出一个单元测试案例来在实战中应用该函数/类的原型；
c.我们运行该单元测试，那么这第一个测试应当失败；
d.好，接下来我们用代码来实施该函数或类的原型，直到该单元测试通过；
e.我们接着写更多的测试来强化该函数/类的代码，直至新的单元测试通过；
f.循环以上步骤，来搭建其它函数/类。

按照这种方式来写代码，这些单元测试就构建成咬定既有成果的齿轮和脚手架。它们给我们提供质量保证和信心，给整个产品的稳定、可靠、和高质量打下了坚实的基础。

先写到这儿，该系列的下一篇，我写一下单元测试。

后记：这些生产原型产品、实战测试和反馈、之后提高的良性循环经验过程，不仅仅可以应用到软件开发方面，个人以为在硬件、工业制造、能源和环保产品的设计和研发等很多方面也能派上用场。比方说关于节能型汽车的研发、改进和提高，关于高铁、大飞机各部件的研发和应用，关于能源产品如藻类/海藻产生能源和风能、地热能、太阳能方面的可行性研究和应用，关于很多产业向创新、高附加值型转型等等，这些对于中国和很多后发国家都有很现实的指导意义。有的东西你可以在网上、书里、和各种会议上学，有的东西别人会藏着、掖着不想让你学到，但你若不自己去应用和尝试，那永远都不会成为你自己的东西。不要自高自大，也不要妄自菲薄，一步步建立起完善的研发、测试、反馈、和提高机制，有勇气和实际行动去大胆尝试，踏踏实实地走稳每一步，那么最后领先的会是你。