Use Castle Windsor as IoC container in Microsoft.MVC

 

There are already some articles talking about how to use Unity IoC and StructureMap in Microsoft.MVC. I've used Windsor container for quite a while. Here I want to show you how to add the Castle Windsor IoC Container to an ASP.NET MVC Framework Application to create controllers and inject their dependencies.

1. First, let's implement our WindsorContainer, here we add each MVC controller as normal Component.

// *********************
// WebContainer.cs
// *********************

using Castle.Windsor;
using Castle.Windsor.Configuration.Interpreters;
using Castle.Core.Resource;

using Shop.Frontend.Controllers;

namespace Duplium.Shop.Frontend
{
    public class WebContainer : WindsorContainer
    {
        public WebContainer() //: base(new XmlInterpreter(new ConfigResource()))
        {
            AddFacilities();
            AddComponents();
        }

        private void AddFacilities()
        {

        }

        private void AddComponents()
        {
            base.AddComponent<DemoProductsDataContext>();

            base.AddComponent<ProductController>();
            base.AddComponent<HomeController>();
        }
    }
}

 

2. Then, implement a ControllerFactory class. It'll be used and replace MVC default controller factory.

// *********************
// ControllerFactory.cs
// *********************

using System.Web.Mvc;

using Castle.Core;
using Castle.Windsor;

namespace Shop.Frontend
{
    public class ControllerFactory : DefaultControllerFactory
    {
        protected override IController GetControllerInstance(Type controllerType)
        {
            if (controllerType == null)
                return (IController)null;

            IWindsorContainer container = null;
            try
            {
                container = ((GlobalApplication)(this.RequestContext.HttpContext.ApplicationInstance)).Container;
                return (Controller)container.Resolve(controllerType);

            }
            catch (Exception ex)
            {
                System.Diagnostics.Debug.WriteLine(ex.Message);
                throw;
            }
        }

    }
}

3. At last, assembly them together in Global.asax

 

// *********************
// Global.asax.cs
// *********************

using Castle.Core;
using Castle.Windsor;

namespace Shop.Frontend
{
    public class GlobalApplication : System.Web.HttpApplication, IContainerAccessor
    {
        private static IWindsorContainer container;

        #region IContainerAccessor

        public IWindsorContainer Container
        {
            get { return container; }
        }

        #endregion

        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute(
                "Default",                                              // Route name
                "{controller}/{action}/{id}",                           // URL with parameters
                new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
            );

        }

        protected void Application_Start()
        {
            container = new WebContainer();
            RegisterRoutes(RouteTable.Routes);
            ControllerBuilder.Current.SetControllerFactory(
                new ControllerFactory()
                );
        }

        protected void Application_End(object sender, EventArgs e)
        {
            container.Dispose();
        }
    }
}

ArrayList Collection

public class Products : ArrayList
{
public Products()
{
//
// TODO: Add constructor logic here
//
}

public new Product this[int intIndex]
{
get
{
return ((Product)base[intIndex]);
}
}
}

The Joel Test: 软件开发成功 12 法则

The Joel Test: 软件开发成功 12 法则

英文版

作者： 周思博 (Joel Spolsky)
译： 李国华 Frank Li
编辑： 孙雯辰 Rosemary Sun
2000年8月9日

有没有听说过SEMA？这可是衡量一个软件开发组好坏的很深奥的系统。别介，等一下！别按那个联接！ 给你六年你也搞不清这玩意。所以我自己随便攒了一套衡量系统，信不信由你，这系统，三分钟就可掌握。你可以把省下的时间去读医学院了（译注：美国的医学院可是要读死人的！）。

Joel 衡量法则 你们用不用源文件管理系统？ 你们可以把整个系统从源码到ＣＤ映像文件一步建成吗？ 你们每天白天都把从系统源码到ＣＤ映像做一遍吗？ 你们有软件虫管理系统吗？ 你们在写新程序之前总是把现有程序里已知的虫解决吗？ 你们的产品开发日程安排是否反映最新的开发进展情况？ 你们有没有软件开发的详细说明书？ 你们的程序员是否工作在安静的环境里？ 你们是否使用现有市场上能买到的最好的工具？ 你们有没有专职的软件测试人员？ 你们招人面试时是否让写一段程序？ 你们是否随便抓一些人来试用你们的软件？

“Joel 衡量法则”好就好在你只需照着逐条回答以上问题，然后把所答为“是”的问题算成一分，再加起来就可以了，而不需要去算什么每天写的程序行数或程序虫的平均数等等。但咱丑话说在前面，可别用“Joel 衡量法则”去推算你的核电站管理程序是否可靠。

如果你们得了１２分，那是最好，得了１１分还过得去，但如果只得了１０分或低于１０分，你们可能就有很严重的问题了。严酷的现实是：大多数的软件开发公司只能得到２到３分。这些公司如果得不到急救可就玄了，因为像微软这样的公司从来就没有低过１２分。

当然，一个公司成功与否不仅仅只取决于以上标 准。比如，让一个管理绝佳的软件公司去开发一个没有人要的软件，那开发出来的软件也只能是没有人要。或反过来，一帮软件痞子以上标准一条也达不到，没准照 样也能搞出一个改变世界的伟大软件。但我告诉你，如果不考虑别的因素，你只要能达到以上１２条准则，你的团队就是一个可以准时交活的纪律严明的好团队。

1. 你们用不用源文件管理系统？
我用过商业化的源文件管理系统，我也用过免费的系统，比如CVS，告诉你吧，CVS挺好用。但如果你根本就没有用源文件管理系统，那你就是累死了也没法让你的程序员出活：他们没法知道别人在改动什么源文件，写错了的源文件也没法恢复。

使用源文件管理系统还有一大好处是，由于每一位程序员都把源文件从源文件管理系统里提出来放到自己的硬盘里，几乎不会发生丢失源文件的事，最起码我还没听说过。

2. 你们可以把整个系统从源码到ＣＤ映像文件一步建成吗？
这句话问的问题是：从你们最新的源码开始到建立起能够交出去的最后文件，你们有多少步骤要做？ 一个好的团队应该有一个批处理程序一步便可将所有的工作做完，像把源文件提取出来，跟据不同的语言版本要求（英文版，中文版），和各种编译开关（#ifdef）进行编译，联接成可执行文件，标上版本号，打包成ＣＤ映像文件或直接送到网站上去，等等等等。

如果这些步骤不是一步做完，就有可能出人为差错。而且当你很接近产品开发尾声的时侯，你可能很急于把最后几个虫解决，然后尽快地交活。如果这时候你需要做２０步才能把最终文件制出来，你肯定会急得要命，然后犯一些很不该犯的错误。

正因为这个原因，我工作的前一个公司从用WISE改用InstallShield：我们必需要让我们的批处理程序完全自动化地，在夜里，被NT scheduler起动把最终文件制成，WISE不能被NT scheduler启动而InstallShield可以，我们只能把WISE扔掉。（WISE的那帮家伙向我保证他们的下一代产品一定支持在夜里自动运行.)

3. 你们每天白天都把从系统源码到ＣＤ映像做一遍吗？
你 们有没有遇到过这样的事情：一个程序员不小心把有毛病的源码放进源文件管理系统，结果造成最终文件没法制成。比如，他建立了一个新源文件但忘了把它放进源 文件管理系统，然后他高高兴兴锁机回家了，因为在他的机器上整个编译得很好。可是别人却因为这没法工作下去了，也只好闷闷地回家了。

这种造成最终文件没法制成的情况很糟糕，但却 很常见。如果每天在白天就把最终文件制一遍的话，就可以让这种事不造成太大危害。在一个大的团队里，要想保证有毛病的源码及时得到纠正，最好每天下午（比 如午餐时）制一下最终文件。午餐前，每个人都尽可能地把改动的源文件放到源文件管理系统里，午餐后，大家回来，如果最终文件已经制成了，好！这时大家再从 源文件管理系统里取出最新的源文件接着干活。如果最终文件制作出错，出错者马上修正，而别人还可接着用原有的没问题的源程序干活。

在我以前曾干过的微软Excel开发组里，我们有一条规定：谁造成最终文件制作出错，谁就得被罚去负责监视以后的最终文件制作过程，直到下一位造成最终文件制作出错的人来接任他。这样做不仅可以督促大家少造成最终文件制作出错，而且可以让每个人都有机会去了解最终文件制作过程。

如果想更多了解这个话题，可以读我的另一篇文章 Daily Builds are Your Friend.

4. 你们有软件虫管理系统吗？
不 论你有任何借口，只要你写程序，哪怕只是一个人的小组，如果你没有一个系统化的管理软件虫的工具，你写的程序的质量一定高不了。许多程序员觉得自己可以记 得自己的软件虫。没门！我从来记不住超过２到３个软件虫。而且第二天早上起床后忙着去买这买那，好不容易记住的软件虫早忘掉了。你绝对需要一个系统来管住 你的那些虫。

软件虫管理系统功能有多有少。但最少要管理以下几种信息：

• 如何重复软件虫的详细步骤
• 正常情况（无虫）应是怎样
• 现在情况（有虫）又是怎样
• 谁来负责杀虫
• 问题有没有解决

如果你觉得用软件虫管理系统太麻烦，可以简化一下，建立一个有以上５列的表来用就行了。

如果想更多了解这个话题，可以读我的另一篇文章Painless Bug Tracking.

5. 你们在写新程序之前总是把现有程序里已知的虫解决吗？
微软Windows Word的第一版的开发项目曾被认为是“死亡之旅”项目。好象永远也做不完，永远超时。所有人疯狂地工作，可怎么也完成不了任务。整个项目一拖再拖，大家都觉得压力大得受不了。最后终于做完了这个鬼项目，微软把全组送到墨西哥的Cancun去度假，让大家坐下来好好想想。

大家意识到由于项目经理过于强求程序员们按时交活，结果大家只能匆匆地赶活，写出的程序毛病百出。由于项目经理的开发计划并没有考虑杀虫的时间，大家只能把杀虫的任务往后推，结果虫越积越多。有一个程序员负责写计算字体高度的程序，为了图快，居然写一行“return 12;”了事。他指望以后的质检人员发现这段程序有毛病后报告他再改正。项目经理的开发计划事实上已变成一个列写程序功能的清单，而上面列的所谓程序功能迟早都会成为软件虫。在项目总结会上，我们称这种工作方法为“绝对劣质之路”。

为了避免再犯这个错误，微软制定了“零缺陷策略”。许多程序员嘲笑这个策略，觉得经理们似乎在指望靠行政命令来提高产品质量。而事实上“零缺陷策略”的真正含义是：在任何时候，都要把解决现有程序里的问题作为首要问题来抓，然后再去写新程序。

为什么要这样做呢？

一般说来，你越不及时地杀虫，杀虫的代价（时 间和金钱）就会越高。比如，你写程序时打错了一个字，编译器马上告诉你，你很容易就把它改正。你刚写好的程序在第一次运行时发现了一个问题，你也很快就能 解决它，因为你对你刚写的程序还记忆犹新。如果你运行你的程序时发现了一个问题，可这个程序是几天以前写的，你可能就需要折腾一会儿，还好，你还大致记 得，所以不会花太长时间。但如果你在你几个月以前写的程序里发现了问题，就比较难解决了，因为你已经忘了许多细节。这时候，你还没准儿正忙着杀别人程序里 的虫呐，因为这家伙到加勒比海阿鲁巴岛度假去了。这时候，解决这一堆问题的难度不亚于从事尖端科学研究。你一定得小心翼翼地，非常系统化地从事，而且你很 难知道多长时间你才能把问题解决。还有更糟糕的，你的程序已交到用户手里了，才发现问题，那你就等着套腰包吧。

总结起来，就一条：越早解决问题，越容易解决。

另外还有一个原因，刚写的程序里发现问题，你能够比较容易地估算解决它的时间。举个例子，如果我问你写一段程序去把一个列表排序需要花多长时间，你可以给我一个比较确切的估计。如果你的程序，在Internet Explorer 5.5安装以后，工作不正常。我问你要多长时间把这个问题解决，你恐怕都估计不出来，因为你根本就不知道是什么原因造成了这个问题。你可能要花三天时间才能解决，也有可能只花两分钟。

这个例子告诉我们，如果你的开发过程中有许多虫没有及时解决，那你的开发计划肯定不可靠。反过来，如果你们已经把已知的虫全部解决了，要做的事只是写新的程序，那你的开发计划就会比较准确。

把已知的虫全部解决，这样做还有一个好处：你 可以对竞争对手快速反击。有些人把这叫着“让开发中的产品随时处在可以交给用户的状态”。如果你的竞争对手推出一个新的功能想把你的客户抢走，你可以马上 在你的产品里加上这个功能，立刻将新产品交付用户，因为你没有一大堆积累下来的问题要解决。

6. 你们的产品开发日程安排是否反映最新的开发进展情况？
为什么我们需要开发日程安排？如果你的程序对公司的业务很重要，那公司就必须知道你的程序何时能写完。满世界的程序员都有一个通病，那就是他们都搞不清自己何时才能写完要写的程序。他们都只会对管理人员嚷嚷：“等我做好了就做好了！”

不幸的是，程序写完了，事远远没完。作为一个公司，在发行产品之前，还有许许多多的事情要做：何时做产品演示？何时参加展览会？何时发广告？等等。所有的这一且都依赖于产品的开发日程安排。

定下产品开发日程安排，还有一个很关键的好处：它逼着你只做叫你做的功能，甩掉那些可要可不要的功能，否则这些可要可不要的东西有可能把你缠住。请看featuritis 。

定下产品开发日程安排，按照它开发，这并不难做，请看我的另一篇文章 Painless Software Schedules ，这篇文章告诉你一种制订产品开发日程的好方法。

7. 你们有没有软件开发的详细说明书？
写软件开发的详细说明书就像是绣花：人人皆知是好东西，可没谁愿意去做。

我不知道这是为什么，也许是因为多数程序员天生就不喜欢写文章。其结果是，一个开发组里的程序员们，宁可用程序来沟通，也不愿写文章来表达自己。他们喜欢上来就写程序，而不是写什么详细说明书。

在产品的前期设计过程中，如果你发现了一些问题，你可以轻易地在说明书里该几行字就行了。一旦进入了写程序的阶段，解决问题的代价就要高得多了，不仅仅是时间上的代价，而且也有感情上的代价，因为没人愿意将自己做成的东西扔掉。所以这时候解决问题总有一些阻力。

没有产品开发详细说明书就开始写程序，往往会导致程序写的乱七八糟，而且左拖右拖不能交付使用。我觉得这就是Netscape遇到的问题。前四个版本的程序越写越乱，以至管理人员作出一个愚蠢的决定：把以前的程序统统扔掉，重新写。后来他们在开发Mozilla时又犯了同样的错误。产品越做越乱，完全失控，花了几年的时间才进入内部测试阶段。

我最得意的理论是：如果让程序员们接受一些写文章的训练如an intensive course in writing，他们就可能会改变一下不写说明书的坏习惯，而以上所说的糟糕的例子就有可能少发生。

另一个解决问题的办法是：雇一些能干的项目主任，专职写产品开发详细说明书。

不论采用以上哪种方法，道理只有一个：在没有产品开发详细说明书之前，决不可写程序。

如果想更多了解这个话题，可以读我的四篇文章。

8. 你们的程序员是否工作在安静的环境里？
当你让你的智囊们工作在安静，宽敞，不受人打扰的环境里，他们往往能更快地出活，这已是不争的事实。有一本经典的讲软件开发管理的书Peopleware 把这个问题阐述得很清楚。

问题在于，我们都知道最好不要打断这些智囊们的思路，让他们一直处于他们的最佳状态中，这样他们就能全神贯注，废寝忘食地工作，充分发挥他们的作用。作家，程序员，科学家，甚至篮球运动员都有他们的最佳状态。

问题还在于，进入这个最佳状态不容易。我觉得平均起来，需要１５分钟才能进入最佳状态，达到最高工作效率。有时侯，当你疲劳了或已经高效率地干了许多工作了，你就很难再进入这个状态，只好干点杂事打发时间，或上网，玩游戏等。

问题更在于，你很容易就被各种各样的事打扰， 被拽出你的最佳状态：噪音啦，电话啦，吃午饭啦，喝杯咖啡啦，被同事打扰啦，等等。如果一个同事问你一个问题，只花你一分钟，可你却被拽出你的最佳工作状 态，重新回到这个状态需要花半小时。你的工作效率因此而受到很大影响。如果让你在一个嘈杂的大房间里工作（那帮搞网站的家伙还就喜欢这样），边上的推销员 在电话里大叫大嚷，你就很难出活，因为你进入不了你的最佳工作状态。

作为程序员，进入最佳工作状态更难。你先要把方方面面的细节装在脑子里， 任何一种干扰都可能让你忘掉其中某些东西。你重新回来工作时，发现好些东西记不起来了（如你刚用的局部变量名，或你刚才的搜索程序写到哪里了等）你只好看看刚写的程序，回忆一下，慢慢地回到你刚才的最佳工作状态。

我们来做一个简单的算数。假设一个程序员被打扰一下，哪怕只有一分钟，他却需要花１５分钟才能回到最佳工作状态（统计资料显示如此）。我们有两个程序员：杰夫和愚夫， 坐在一个大办公区里工作。愚夫想不起来用什么函数去进行Unicode 字符串复制。他可以花３０秒查一下，或者花１５秒问杰夫。由于他坐在杰夫的旁边，他就选择去问杰夫。杰夫被打扰了一下，耽误了他１５分钟，节省了愚夫１５秒钟。

现在，我们把他们俩用墙和门隔开，让他们俩分 坐在不同的办公室里，愚夫又想不起来什么涵数名，自己查一下要花３０秒；问杰夫，要花４５秒，因为他要站起来走过去问（对这帮程序员来说，这可不是件简单 的事，看看他们的体质就知道为什么了）。所以他选择自己去查。愚夫损失了３０秒钟，可是杰夫少损失了１５分钟。哈哈！

9. 你们是否使用现有市场上能买到的最好的工具？
用可编译语言写程序恐怕是这世界上为数不多的还不能随便抓一个破计算机就可以做的事。如果你用于编译的时间超过几秒钟，你就应该换一台最新最快的计算机了。因为如果编译时间超过１５秒，程序员们就会不耐烦，转而去上网看一些无关的东西比如The Onion，弄不好一看就是好几个小时。

调试图形界面软件时，用只有一个显示器的计算机不仅不方便，有时甚至是不可能。用有两个显示器的计算机，要方便许多。

程序员们经常不可避免地要去画一些图标或工具栏图。多数程序员没有一个好的图形编辑器可用。用微软的“画笔”软件去画图标简直是笑话，可事实上大家还就在这样做。

在我的前一个工作，系统管理员成天给我发来自动警告，说我在服务器上使用了超过２２０兆的空间。我告诉他，按现在硬盘的价钱，超出这点空间的价钱远低于我用的厕纸的价钱。让我花１０分钟去清理我的文件绝对是我工作效率的莫大浪费。

一流的开发组绝不折腾它的程序员。工具落后会让人用起来觉得难受，一点点积累起来，会让程序员们成天叫苦，而一个成天叫苦的程序员绝对不会是一个高消率的程序员。

再添一句，要想使你的程序员高兴，最好的办法就是给他们买一些最新最棒的工具软件。用这种方法可以让他们乖乖地为你工作，这可比用高薪吸引他们来得便宜得多。

10. 你们有没有专职的软件测试人员？
如 果你的开发组里没有专职的测试人员，或没有足够的测试人员（两到三个程序员就应该配一个测试员），那你的产品就一定是毛病百出，或者你在花１００美元一小 时的代价去雇你的程序员去做３０美元一小时就可以雇到的测试员的工作。想在测试员身上省钱，绝对是打错了算盘。我真不明白为什么这么多人算不过来这笔帐。

我有另一篇文章专门讲这个，请看Top Five (Wrong) Reasons You Don't Have Testers。

11. 你们招人面试时是否让写一段程序？
我问你，让你去招一个魔术师，你是否连看都不看一眼他的魔术玩得怎样就要他？当然不会！

你举办婚宴，要请一个厨师，你是不是连嚐也不嚐他做的菜好吃不好吃就要他？我想也不会。

奇怪的是，几乎每天都有这样的事发生：在面试一个程序员时，简历写得漂亮，谈得热火朝天，问几个简单的问题（如CreateDialog()和DialogBox()有什么区别？这种问题，查一下帮助文件就知道了），人就招进来了。你真正应该关心的不是这人记不记得这些写程序的边边角角的东西，而是他能否出产品！更糟糕的是，许多问题是知道就知道，不知道，想死也不知道的问题。

不能这样下去了！在面试时，请一定要让写一段程序。在我的这篇文章里Guerrilla Guide to Interviewing，我有许多好建议。

12. 你们是否随便抓一些人来试用你们的软件？
这句话的意思是，让你从走道里走过的人中，随便抓几个人来，让他们试用你的软件。如果你抓五个人来用你的软件，那你就可能把你的程序中９５％的不方便使用的地方找出来。

要想让用户去买你的软件，你必须要设计好你的用户界面。这其实并不难。你可以读我的free online book on UI design打打基础。

用户界面设计的关键是，如果你让几个人去用你的软件（五六人可能就够了），你可能很快就找出最大的问题。想知道为什么吗，请读Jakob Nielsen's article。只要你坚持随便抓一些人来试用你的软件，你就能将你的用户界面设计得越来越好。

The Joel Test 软件开发成功12法则的四个实用领域

1. 用该法则来衡量你的软件开发组，告诉我你得的分数，让我来品头论足。
2. 如果你是开发组的经理，用该法则来使你的组提高效率。如果你们一上来就能得１２分，你就 别再打扰你的程序员了， 专心致志别让公司的管理人员来烦你的程序员吧。
3. 如果你在找一份程序员工作，问问你未来的老板他能得几分，如果分数很低，你一定要确信你进去后有足够的权力来改变这一切，否则，最好躲远点，不然，你在那儿会很难受的。
4. 如果你是投资者，正在决定是否向一个软件公司投资，或者你的软件公司正在决定是否兼并另一个软件公司，该法则可以帮你做决定。

USB Port Insert / Remove detection using WMI

We can use the Windows Management Instrumentation (WMI) which is a component of the Windows operating system that allows you to programmatically access management information in an enterprise environment.

First we should add the System.Management name space as a reference to our project

The add: using System.Management;

When a USB device is inserted a 'Win32_USBControllerdevice' record is added to the operating system's metabase and when the device is removed, that record will be deleted.

So we have to add two events to the same record and these events are "__InstanceCreationEvent" for insertion and "__InstanceDeletionEvent" for removal.

The following method "StartMonitoringPort()" adds an event handler that is fired when a USB device is inserted.

ManagementEventWatcher omewStartEventWatcher;
private void StartMonitoringPort()
{
WqlEventQuery q;
ManagementOperationObserver observer = new
ManagementOperationObserver();

// Bind to local machine
ManagementScope scope = new ManagementScope("root\\CIMV2");
scope.Options.EnablePrivileges = true; //sets required privilege

try
{
q = new WqlEventQuery();
q.EventClassName = "__InstanceCreationEvent";
q.WithinInterval = new TimeSpan(0,0,3);
q.Condition = @"TargetInstance ISA 'Win32_USBControllerDevice'";
omewStartEventWatcher = new ManagementEventWatcher(scope, q);
omewStartEventWatcher.EventArrived += new EventArrivedEventHandler(UsbEventArrived);
omewStartEventWatcher.Start();
}
catch(Exception ex)
{
if (omewStartEventWatcher != null)
omewStartEventWatcher.Stop();
throw ex;
}
finally
{
}
}

private void StopMonitoringPort()
{
if (omewStartEventWatcher != null)
omewStartEventWatcher.Stop();
}

public void UsbEventArrived(object sender, EventArrivedEventArgs e)
{
//Get the Event object and display it
foreach(PropertyData pd in e.NewEvent.Properties)
{
ManagementBaseObject mbo = null;
if(( mbo = pd.Value as ManagementBaseObject) != null)
{
SetText("USB device is inserted at " + DateTime.Now.ToString() + "\r\n");
foreach(PropertyData prop in mbo.Properties)
// lblStatus.Text = InputData;
// because of different threads this
// does not work properly !!
if (prop.Name == "Antecedent" || prop.Name == "Dependent" )
SetText(string.Format("{0}\r\n{1}\r\n{2}\r\n{3}\r\n", prop.Name, prop.Value, prop.IsArray,prop.IsLocal));
}
}
}

delegate void SetTextCallback(string text);
private void SetText(string text)
{
// InvokeRequired required compares the thread ID of the
// calling thread to the thread ID of the creating thread.
// If these threads are different, it returns true.
if (this.txtLead.InvokeRequired)
{
SetTextCallback d = new SetTextCallback(SetText);
this.Invoke(d, new object[] { text });
}
else this.txtLead.Text += text;
}

Important note: you should stop the watcher before exiting the application or else an excption is thrown

Now to add another handler for that fire when the USB device is removed all you have to do is just to set the EventClassName property of the WqlEventQuery object to “__InstanceDeletionEvent”.

Value Types vs Reference Types

Parameter passing in C#

Math For Programmers - 程序员怎样学数学

I've been working for the past 15 months on repairing my rusty math skills, ever since I read a biography of Johnny von Neumann. I've read a huge stack of math books, and I have an even bigger stack of unread math books. And it's starting to come together.

Let me tell you about it.

自从我读了Johnny von Neumann的传记,我已经为弥补我糟糕的数学技能花了15个月了.读了大量的数学书籍,不过呢,似乎我还有更多没有读.当然我会接着做的.
现在我就来告诉你这些.

Conventional Wisdom Doesn't Add Up
这并不包括传统的智慧

First: programmers don't think they need to know math. I hear that so often; I hardly know anyone who disagrees. Even programmers who were math majors tell me they don't really use math all that much! They say it's better to know about design patterns, object-oriented methodologies, software tools, interface design, stuff like that.

首先:程序员不认为他们需要了解数学.我常常听到这样的话;我不知道还有会不同意这个的.甚至于以前是主修数学的程序员也告诉我他们真的不是常常使用到数学!他们说 更重要的是要去了解

设计模式,面向对象原理,软件工具,界面设计,以及一些类似的东西.

And you know what? They're absolutely right. You can be a good, solid, professional programmer without knowing much math.

But hey, you don't really need to know how to program, either. Let's face it: there are a lot of professional programmers out there who realize they're not very good at it, and they still find ways to contribute.

你了解吗?他们完全正确.你不需要了解很多数学你就能做个很棒,很专业的程序员.

但是呢,同时你也不是真的需要知道如何来编程.我们要面对的是:有很多专业的程序员,他们认识到他们不是非常擅长数学,但他们还是寻找方法去提升.

If you're suddenly feeling out of your depth, and everyone appears to be running circles around you, what are your options? Well, you might discover you're good at project management, or people management, or UI design, or technical writing, or system administration, any number of other important things that "programmers" aren't necessarily any good at. You'll start filling those niches (because there's always more work to do), and as soon as you find something you're good at, you'll probably migrate towards doing it full-time.

如果你突然觉得自己好烂,周围的人都远远的超过你,你会怎么想呢?好,你可能会发现自己善于项目管理,或者人事管理,或者界面设计,或技术写作,或者系统 管理,还有许多其他程序员不必去精通的.你会开始堆积那些想法(因为工作永远干不完),当你发现一些你能掌握的东西时,你很可能会转移去全职的做这个工 作.

In fact, I don't think you need to know anything, as long as you can stay alive somehow.

So they're right: you don't need to know math, and you can get by for your entire life just fine without it.

实际上,我认为有些东西你不需要了解,当目前你还能够赖以生存.

所以他们是对的:你不需要了解数学,并且没有她你也能过的很好.

But a few things I've learned recently might surprise you:

1. Math is a lot easier to pick up after you know how to program. In fact, if you're a halfway decent programmer, you'll find it's almost a snap.


2. They teach math all wrong in school. Way, WAY wrong. If you teach yourself math the right way, you'll learn faster, remember it longer, and it'll be much more valuable to you as a programmer.


3. Knowing even a little of the right kinds of math can enable you do write some pretty interesting programs that would otherwise be too hard. In other words, math is something you can pick up a little at a time, whenever you have free time.


4. Nobody knows all of math, not even the best mathematicians. The field is constantly expanding, as people invent new formalisms to solve their own problems. And with any given math problem, just like in programming, there's more than one way to do it. You can pick the one you like best.


5. Math is... ummm, please don't tell anyone I said this; I'll never get invited to another party as long as I live. But math, well... I'd better whisper this, so listen up: (it's actually kinda fun.)
   
   
   但是最近我学到一些东西可能会让你也感到惊喜:
   
   在你知道如何编程之后,数学更容易学会.实际上,如果你先学数学,然后半路出家做程序员的话,你会发现编程简直就是小菜一碟.
   
   学校里教数学的方式都错了.仅仅是教学的方法错了,不是教数学本身错.如果你以正确 的方式学习数学的话,你会学的更快,记住这会更长,但对你作为一个程序员来说也更有价值.
   
   哪怕了解一点点相关的数学知识就能让你写出可爱有趣的程序,否则会有些小难度.换 句话讲,数学是可以慢慢学的,只要你有时间.
   
   没人能了解所有的数学,就是最棒的数学家也不是.数学领域正不断的扩展,当人们发明 新的形式去解决自己的问题时.一些给出的数学问题,也正如编程,不止一种方法可以去 解决他.你可以挑个你最喜欢的.
   
   数学是......嗯,请别告诉别人我说过这个哈;当然我也不指望谁能邀请我参加这样的 派对,当我还活着的时候.但是,数学其实就是......我还是小声的说吧,听好了:(她其 实就是一种乐趣啦!)

The Math You Learned (And Forgot)
你学到的数学(和你忘了的)

Here's the math I learned in school, as far as I can remember:

Grade School: Numbers, Counting, Arithmetic, Pre-Algebra ("story problems")

High School: Algebra, Geometry, Advanced Algebra, Trigonometry, Pre-Calculus (conics and limits)

College: Differential and Integral Calculus, Differential Equations, Linear Algebra, Probability and Statistics, Discrete Math

这儿是我能记得在学校学到的数学:

初中:数,数数,算术知识,初级代数("问题故事")

高中:代数,几何,高等代数,三角学,? (圆锥和极限)

大学:微积分,微分公式,线性代数,概率和统计,离散数学

How'd they come up with that particular list for high school, anyway? It's more or less the same courses in most U.S. high schools. I think it's very similar in other countries, too, except that their students have finished the list by the time they're nine years old. (Americans really kick butt at monster-truck competitions, though, so it's not a total loss.)

上面那个关于高中数学课程单子上所列的,怎么来着?美国高中几乎都是这样的课程设置.我认为其他国家也会很相似的,除了那些在9岁之前就掌握了这些课程的学生.(美国人同时却在热衷于玩魔鬼卡车竞赛,虽然如此,整个来说也算不上什么大损失.)

Algebra? Sure. No question. You need that. And a basic understanding of Cartesian geometry, too. Those are useful, and you can learn everything you need to know in a few months, give or take. But the rest of them? I think an introduction to the basics might be useful, but spending a whole semester or year on them seems ridiculous.

代数?是的.没问题.你需要代数.和一些理解解析几何的知识.那些很有用,并且在以后 几个月里,你能学到一切你想要的,十拿九稳的.剩下的呢?我认为一个基本的介绍可能 会有用,但是在这上面花整个学期或一年就显得很荒谬了.

I'm guessing the list was designed to prepare students for science and engineering professions. The math courses they teach in and high school don't help ready you for a career in programming, and the simple fact is that the number of programming jobs is rapidly outpacing the demand for all other engineering roles.

我现在意识到那个书单列表原是设计来准备给那些以后要当科学家和工程师的学生的.他们在高中里所教的数学课程并不是为你的编程生涯做准备的,简单的事实是多数的编程工作相比其他的工程师角色更加要求快速.

And even if you're planning on being a scientist or an engineer, I've found it's much easier to learn and appreciate geometry and trig after you understand what exactly math is — where it came from, where it's going, what it's for. No need to dive right into memorizing geometric proofs and trigonometric identities. But that's exactly what high schools have you do.

甚至于你打算当一名科学家或者一名工程师,我会发现这更加容易去学习和欣赏几何学和三角在你理解了什么是数学之后-- 数学它如何而来,如何而去,为何而生.不必去专研记住几何上的证明和三角恒等式.但是那确实是高中学校要求你必须去做的.

So the list's no good anymore. Schools are teaching us the wrong math, and they're teaching it the wrong way. It's no wonder programmers think they don't need any math: most of the math we learned isn't helping us.

所以这样的书单列表不再有什么用了.学校教了我们不是最合适的数学,并且方式也不对.不奇怪程序员认为他们不再需要数学:我们学的大部分数学知识对我们的工作没什么大的帮助.

The Math They Didn't Teach You
他们没有教到你的那部分数学

The math computer scientists use regularly, in real life, has very little overlap with the list above. For one thing, most of the math you learn in grade school and high school is continuous: that is, math on the real numbers. For computer scientists, 95% or more of the interesting math is discrete: i.e., math on the integers.

在真实的生活中,计算机科学家有规则的使用数学,对于上面单子里列的有点小小超过. 举个例子,你在中学里学的大部分数学是连续性的:也就是说,数学是真实的数字.而对于计算机科学家来说,他们所感兴趣的部分是占95%也许更多的离散性的:比如,关于整数的数学.

I'm going to talk in a future blog about some key differences between computer science, software engineering, programming, hacking, and other oft-confused disciplines. I got the basic framework for these (upcoming) insights in no small part from Richard Gabriel's Patterns Of Software, so if you absolutely can't wait, go read that. It's a good book.

我打算在我以后blog中再谈一些在计算机科学,软件工程,编程,hacking,和其他常常迷惑的管理的之间的关键差异.我已经从Richard Gabriel的软件的模式这本书中洞察到一个无关细节的基本框架.如果你明显的等不下去的话,去读吧.是本不错的书.

For now, though, don't let the term "computer scientist" worry you. It sounds intimidating, but math isn't the exclusive purview of computer scientists; you can learn it all by yourself as a closet hacker, and be just as good (or better) at it than they are. Your background as a programmer will help keep you focused on the practical side of things.

到现在为止,不要让"计算机科学家"这个词困扰到你.它听上去很可怕,其实数学不是计算机科学家所独有的领域,你也能作为一个黑客自学它,并且能做的和他们一样棒.你作为一个程序的背景将会帮助你保持只关注那些有实践性的部分.

The math we use for modeling computational problems is, by and large, math on discrete integers. This is a generalization. If you're with me on today's blog, you'll be studying a little more math from now on than you were planning to before today, and you'll discover places where the generalization isn't true. But by then, a short time from now, you'll be confident enough to ignore all this and teach yourself math the way you want to learn it.

数学,我们用来建立计算模型的,大体上是离散的整数.这是普遍化的做法.如果正好今天你在看这篇博客,从现在起你正了解到更多的数学,并且你会认识到那样的普遍化是不对的.更多的,你将有信心认为可以忽略所有这些,并以你想要的方式自学.

For programmers, the most useful branch of discrete math is probability theory. It's the first thing they should teach you after arithmetic, in grade school. What's probability theory, you ask? Why, it's counting. How many ways are there to make a Full House in poker? Or a Royal Flush? Whenever you think of a question that starts with "how many ways..." or "what are the odds...", it's a probability question. And as it happens (what are the odds?), it all just turns out to be "simple" counting. It starts with flipping a coin and goes from there. It's definitely the first thing they should teach you in grade school after you learn Basic Calculator Usage.

对程序员来说,最有效的离散数学的分支是概率理论.这是你在学校学完基本算术后的紧接着的课.你会问,什么是概率理论呢?你就数啊,看有多少次出现满堂 彩?或者有多次是同花顺. 不管你思考什么问题如果是以"多少种途径..."或"有多大几率的...",那就是离散问题.当他发生时,都转化成"简单"的计数.抛个硬币看看...? 毫无疑问在他们教你基本的计算用法后他们会教你概率理论.

I still have my discrete math textbook from college. It's a bit heavyweight for a third-grader (maybe), but it does cover a lot of the math we use in "everyday" computer science and computer engineering.


我还保存着大学里的离散数学课本.可能他只占了三分之一的课程,但是它却涵盖了我们几乎每天计算机编程工作大部分所使用到的数学.

Oddly enough, my professor didn't tell me what it was for. Or I didn't hear. Or something. So I didn't pay very close attention: just enough to pass the course and forget this hateful topic forever, because I didn't think it had anything to do with programming. That happened in quite a few of my comp sci courses in college, maybe as many as 25% of them. Poor me! I had to figure out what was important on my own, later, the hard way.

也真是够奇怪的,我的教授从没告诉我数学是用来干吗的.或者我也从来没有听说过.种种原因吧.所以我也从没有给以足够的注意:只是考试及格然后把他们都忘 光,因为我不认为她还和编程有啥关系.事情变化是我在大学学完一些计算机科学的课程之后,也许是25%的课程.可怜的人!我必须弄明白什么对于自己来说是 最重要的,然后再是向深度发展.

I think it would be nice if every math course spent a full week just introducing you to the subject, in the most fun way possible, so you know why the heck you're learning it. Heck, that's probably true for every course.

我想,如果每门数学课都花上整整一周的时间,而只是介绍让你如何入门的话,那将非常不错,这是最有意思的一种假设,那么你知道了你正学习的对象是哪种怪物了.怪物,大概对每一门课都合适.

Aside from probability and discrete math, there are a few other branches of mathematics that are potentially quite useful to programmers, and they usually don't teach them in school, unless you're a math minor. This list includes:

除了概率和离散数学外,还有不少其他的数学分支,可能对程序员相当的有用,学校通常不会教你的,除非你的辅修科目是数学.这些数目列表包括:

• Statistics, some of which is covered in my discrete math book, but it's really a discipline of its own. A pretty important one, too, but hopefully it needs no introduction.


• Algebra and Linear Algebra (i.e., matrices). They should teach Linear Algebra immediately after algebra. It's pretty easy, and it's amazingly useful in all sorts of domains, including machine learning.


• Mathematical Logic. I have a really cool totally unreadable book on the subject by Stephen Kleene, the inventor of the Kleene closure and, as far as I know, Kleenex. Don't read that one. I swear I've tried 20 times, and never made it past chapter 2. If anyone has a recommendation for a better introduction to this field, please post a comment. It's obviously important stuff, though.


• Information Theory and Kolmogorov Complexity. Weird, eh? I bet none of your high schools taught either of those. They're both pretty new. Information theory is (veeery roughly) about data compression, and Kolmogorov Complexity is (also roughly) about algorithmic complexity. I.e., how small you can you make it, how long will it take, how elegant can the program or data structure be, things like that. They're both fun, interesting and useful.

统计学,其中一些包括在我的离散数学课里,她的某些训练只限于她自身.自然也是相当重要的,但想学的话不需要什么特别的入门.

代数和线性代数(比如,矩阵).他们会在教完代数后立即教线性代数.这也简单,这但相当多的领域非常有用,包括机器学习.

数理逻辑.我有相当完整的关于这么学科的书没有读,是Stephen Kleene写的,Kleene closure 的发明者,我所知道的还有就是Kleenex.这个就不要读了.我发誓我已经尝试了不下20次,却从没有读完第二章.如果那位牛掰有什么更好的入门建议的 话可以给我推荐,给个回复.虽然,这明显是非常重要的一部分.

信息理论和柯尔莫戈洛夫复杂性理论.真不可思议,不是么?我敢打赌没哪个高中会教你其中任何一门课程.她们都是新兴的学科.信息理论是(相当相当相当相当 难懂)关于数据压缩,柯尔莫戈洛夫复杂性理论是(同样非常难懂)关于算法复杂度的.也就是说,你要把它压缩的尽量小,你所要花费的时间也就变的越长,同样 的,程序或数据结构要变得多优雅也有同样的代价.他们都很有趣,也很有用.

...

For More ...
全文在这...

iPhone - 谁为iPhone创造了价值

谁为iPhone创造了价值？

　　iPod和iPhone，都是由遍布多国的数十家公司分工制造而成，每一生产阶段都为最后的价值做出大小不一的贡献。三位Irvine加州大学的研究员在斯隆基金会的资助下完成了一项针对美国市场上一款零售价为299美元30GB的iPod供应链的研究。

　　三位教授的研究发现，iPod真正的价值不在于内含的零件，更不在于把零件组装起来的整合机，而是集中在iPod的构思与设计。苹果聪明在想出如何把451种普通零件，组装成一台高价值的产品。苹果未必亲手制造iPod，但他们是其创造者。这才是关键。

　　据报告的粗略分析，苹果借品牌和设计当仁不让地拿到了大头80美元；75美元分给美国的渠道商与零售 商；13美元由林林总总的美国国内零组件厂商瓜分；由东芝制造的最昂贵的硬盘，成本价约73美元；最末阶段的组装在中国大陆完成，每台约4美元。其余还有 54美元的构成说不清楚，韩国的三星该有不少进账。

　　组装生产的特殊性值得一提。留给中国的虽然只有4美元收入(要覆盖组装生产、库存、厂房租金、运输、水电、工资等所有工厂开支)，每一台iPod成品出口到美国，却要记入中国出口额150美元。这是目前美中贸易逆差巨大的重要原因之一。

　　iPhone同样是一个庞大的敏捷供应链生产。此前业内估计，iPhone带给苹果的利润率在20%至 50%之间，而根据分析公司iSuppli进行的拆卸确定，8GB iPhone的硬件物料清单和制造成本共为265.83美元，按照每个8GB iPhone以599.00美元的零售价进行出售，那么它的毛利润率超过了55%。当然，该估算成本中未包括专利权费、物流、销售等费用。

　　iSuppli的拆卸分析认为，在各部件供货商中，三星公司仍为最大的获利者。在8GB版iPhone 的成本里，三星公司提供的部件总计占了76.25美元，占BOM(物料清单)的30.5%，是最大的供货商；触摸屏模块的提供商为德国Balda参股的坐 落在中国的TPK制造厂，该模块估算成本为27美元，占8GB版iPhone BOM的10.8%；显示屏则来自包括EPSON、SHARP、Toshiba Matsushita等多家厂商，预估成本为24.5美元，占8GB版iPhone BOM的9.8%；德国的英飞凌是苹果家族供应商的新成员，为iPhone提供了包括数字基带、无线发射和电源管理等核心通信部件，预估总成本为 15.25美元，占8GB版iPhone BOM的6.1%；美国国家半导体公司提供的元件在BOM单中占的比例较小，仅为1.5美元，不到1%；iPhone由鸿海旗下的富士康负责组装。