对于微软来说,wpf是失败的.winform也不算成功..net系列成功的只有asp.net和silverlight

silverlight对比asp.net的优点:

asp.net需要调用ajax才能实现页面无刷新.而silverlight原生支持无刷新.

silverlight 对快捷键的支持,

silverlight控件更灵活,所有控件都可定制

asp.net上的数据控件,对微软来说很失败.一味要实现傻瓜化开发,数据控件不伦不类,而silverlight的数据控件很强大.

silverlight的界面可复制.

silverlight可开发wp,等等.无需js的支持.

    在嵌入式产品上，如何让用户选择有线还是无线上网呢？如何让他们判断使用了哪种方式上网呢？我们是这样处理的：优先使用网线上网，稳定。即程序自动判断，如果查了网线，则使用网线上网，如果没有网线连接，则无线上网。

    所以，问题的重点是如何判断用户是否插了网线！下面介绍四种方法，仅供参考。

方法一：

/mnt/wifi$ cat /proc/net/dev

Inter-|   Receive                                                | Transmit

 face |bytes   packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carriercompressed

    lo:      0       0    0   0    0     0         0         0        0      0    0    0   0     0       0         0

  eth0:    3439     15   0   0    0     0         0         0        0      0    0    0   0     0       0          0   

    在开发板上/proc/net目录下，还有很多关于网络的信息的文件，我试了不少，觉得这个还算准确，但并非100%哦，如果启动开发板后，eth0中bytes、packets 不为0，那它一定插了网线，但此种方法只适合开机启动时判断，之后的话，就很麻烦了。   

    获取/proc/net/dev的信息，需要借助getline()函数和sscanf()函数。可链接：getline()函数

方法二：

   当插网线时，会打印PHY: 0:01 - Link is Up - 100/Full，拔出网线时，打印PHY: 0:01 - Link is Down，这些都由底层驱动触发，即网线插或拔，驱动都由处理，所以，我们可以在底层发出一个信号，上层接收。使用这种方法，个人认为最为准确，而且最有效。

方法三：

插网线：

/mnt/wifi$ ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 06:ED:B5:C3:AA:23

          UP BROADCAST RUNNING MULTICAST  MTU:1500 Metric:1

          RX packets:159 errors:0 dropped:0overruns:0 frame:0

          TX packets:0 errors:0 dropped:0overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:23822 (23.2 KiB)  TX bytes:0 (0.0 B)

          Interrupt:14

拔网线：

/mnt/wifi$ ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 06:ED:B5:C3:AA:23

          UP BROADCAST MULTICAST  MTU:1500 Metric:1

          RX packets:160 errors:0 dropped:0overruns:0 frame:0

          TX packets:0 errors:0 dropped:0overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:24055 (23.4 KiB)  TX bytes:0 (0.0 B)

          Interrupt:14

   区别在于红字的RUNNING。个人不太同意这种方法，如果在脚本(/etc/profile)运行，永远没有RUNNING，而拔掉网线时，时常打印PHY: 0:01 - Link is Up - 100/Full，PHY: 0:01 - Link is Down，而在PHY: 0:01 - Link is Up - 100/Full状态时，ifconfig eth0是RUNNING状态的。

    网上也有ethtoolseth0方法,我测试了一下，不准确。

方法四：

   1）udhcpc自动获取eth0的ip地址，可以限制次数。

   2）ioctl获取eth0的ip地址，如果获取ip地址成功，则插入了网线，如果失败，则未插入网线。

    我就是使用这种方法处理是否插入网线的，屡试不爽，最值得推荐的（仅限开机启动时哦，因为我就是用于此时）。

   可能有更多更好的自动判断是否插入网线的方法，由于本人知识和能力的限度，也就只能完成至此了，所以，如果大家有什么更好的办法来自动判断，欢迎来扰！！！

时至今日，还讨论这样一个老话题，是否感觉老调重弹？因为两年前（2010年底）时任谷歌中国测试经理的段念先生就写了一篇文章《什么是敏捷软件测试》（刊登在InfoQ网站上[1]）， 就已经谈到这个话题，“敏捷软件测试更多的是一种理念，而非过程”。在2011年，我自己也写了一篇文章《敏捷测试的思考和新发展》，刊登在《程序员》杂志上，谈到“在BDD、ATDD和TDD最根本的、共同的思想基础上，构成一个全新的、更完善的敏捷测试框架”[2]。而更早的时候（2010年10月），写了一篇《敏捷测试的方法和实践》（也刊登在《程序员》杂志上），开始的那一小节就在讨论 “什么是敏捷测试”，简单地说，“敏捷测试就是持续地对软件质量问题进行及时地反馈”[3]。不过，篇幅不多、匆匆而过，说得还不够明朗。如果再往前，早在2009年，Lisa Crispin和Janet Gergory就写了一本书《Agile Testing: A practical Guide for testers and Agile Teams》, 国内在2010年出了它的中文版本[4]，在第1章就论述了敏捷测试的定义，侧重从测试的敏捷形式和“敏捷测试”的实践等来彰显敏捷测试，对敏捷测试和传统测试的区别进行了分析（虽然作者把传统测试局限于瀑布模型，这显然是不对的），让我们看到一些敏捷测试的特点，如图1所示。但作者也承认“敏捷测试对不同的人意味着不同的含义”。

图1 传统测试与敏捷测试 [4]

这样看来，“敏捷测试（Agile Testing）”就不是一个新概念了，但为什么不少人还是不理解什么敏捷测试呢？现在偶尔还看到一些文章或微博帖子还在讨论什么是敏捷测试，但似乎云里雾里、不知所云，感觉“敏捷测试”在许多人的心目中还是比较模糊。估计是以前的文章，包括我的文章，没有把“敏捷测试”说透，所以有了再写一篇文章的想法，尽量一次把“敏捷测试”这个内涵给大家说清楚。以后，有机会再讨论传统测试团队如何转型、敏捷文化下测试团队如何建设等。

首先，可以明确的是，敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）。因为在敏捷测试中可以采用已有的各种方法，包括白盒方法、黑盒方法；在敏捷中也可以采用探索式测试（exploratory test），也可以采用基于脚本的测试（scripted test）。那敏捷测试是什么？敏捷测试应该是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。就像Scrum一样，Scrum可以理解为敏捷方法的具体实现的框架、一组实践或具体的解决方案。简单地说，敏捷测试就是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。让我们看看Wikipedia 是如何描述敏捷测试的：

Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace.

它强调敏捷测试是遵守敏捷开发方法原则之下的软件测试实践，由跨功能敏捷团队的所有人员参与（包括测试人员以其专业特长的特殊贡献）以保证持续的、快速的业务价值交付。所以要理解敏捷测试，我们还是要回过头来仔细看一下“敏捷宣言”背后所蕴含的12条原则。我相信，大家都已熟悉敏捷宣言，如果不熟悉，可以先认真阅读以下完整的敏捷宣言，不仅仅是那四句话。

先从敏捷开发这一方法论层次来讨论什么是敏捷测试，即敏捷测试有什么具体特征，或有哪些主要实践，然后再就目前非常热的敏捷具体框架Scrum来讨论Scrum中的敏捷测试（或称为Scrum Testing）。先研究一下敏捷宣言背后所蕴含的12条原则[5]：

1) 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

2) 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

3) 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

4) 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

5) 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

6) 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

7) 可工作的软件是进度的首要度量标准。

8) 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9) 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

10) 以简洁为本，它是极力减少不必要工作量的艺术。

11) 最好的架构、需求和设计出自自组织团队。

12) 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

这12条原则中没有一条直接谈到测试，那是否说明没有敏捷测试呢？有开发就有测试，只是原来参加敏捷宣言的17人，基本是清一色